Posts Tagged ‘change’

Thinking of enrolling on an MBA program? Then these five books are essential reads (in no specific order):

1. Michael PorterCompetitive Strategy: Porter’s frameworks are covered on every quality MBA program. The three most commonly taught frameworks are the Value Chain, Porter’s Five Forces Analysis and Porter’s Generic Strategies. Read the rest of this entry »

Incoming search terms for this article:

Related posts

The Theory of Constraints (TOC) as offered by Eli Goldratt is a very powerful conceptual as well as practical tool of which every Business Analyst should be aware. Many MBA programs recommend the reading of ‘The Goal’ (authored by Goldratt) and cover the core elements of TOC in Operations Management modules.

Very simplistically, TOC is about identifying the core bottleneck in a system and then eliminating that bottleneck (something like ‘a chain is only as strong as it’s weakest link’). The bottleneck will then be somewhere else in the system so the process of identification and elimination continues.

ITIL and TOC

In relation to Quality Management and ITIL, the ITIL books refer primarily to The Deming Cycle (‘Plan, Do, Check, Act’) for process improvement (ITIL version 3 also describes a ‘7-Step Improvement Process’). TOC is conceptually very powerful and compliments the Deming Cycle. The power of TOC is it’s simplicity in illustrating that there is always a bottleneck (constraint) in any system. The challenge is to identify the primary bottleneck and eliminate it as the primary bottleneck. ITIL process maturity is all about eliminating the bottleneck at which time the bottleneck will move and during this removing of the bottleneck/constraint the ITIL processes mature. TOC therefore works very well with the Deming Cycle together in that TOC assists to identify the bottleneck whilst the Deming Cycle assists in eliminating it (we could also add in Lewin’s ‘Unfreeze Change Refreeze’ Change model as we are we unfreezing a stable state, effecting the Change and then moving to the next constraint).

As an example, suppose that we are continuously failing a Service Level where the Service Desk should be responding to all emails within ten minutes even although we employ two people to specifically respond to emails. We analyse our business process and discover that 40% of emails are received between 12 p.m. and 2 p.m. each day and that these are the hours where our two email responders take a lunch break. Our constraint is in the supply of services where demand exceeds supply during the two hours. We eliminate the bottleneck by changing the lunch break hours of the responders. Now we are free to look at the next bottleneck (please note that this is a very simplistic example).

External Article

Below is an article offering TOC as part of an ongoing Process Improvement initiative. The article may provide some benefit however doesn’t articulate well how TOC may be used for process improvement (I believe that the article was originally authored by Pink Elephant):

A system or a process cannot be more efficient than its limiting factor!

In “The Goal” Eli Goldratt presents the Theory Of Constraints (TOC). TOC introduces primary measurements for the analysis of systems based on productivity and ultimately, profit. The core truth of TOC is that every system or process has at least one constraint or bottleneck, and that the identification of this constraint should be the focus for any improvement activity.

TOC advocates that organizations take a three-dimensional view of three core business concepts, Inventory, Operating Expense and Throughput. To relate these financial terms to IT one needs to expand the definitions beyond their traditional concepts.

Inventory: All of the money, investment, outstanding issues, pending changes, unresolved incidents, excess capacity, etc. an organization has tied up in an un-sellable, unfinished, unresolved, undeliverable, or pending state.

  • Pre Process Inventory: stuff that is currently waiting in queue in a raw or input state. i.e.: Calls that are waiting in the ACD system or emails that have not been answered by the Service Desk.
  • Active Inventory: stuff that is currently within the system or process and is currently being transformed into a desired or sellable output state, i.e.: Change Management records that are currently being assessed, authorized and scheduled.
  • Post Process Inventory: stuff that has been successfully transformed into a desired output but has not been delivered to a client, sold, confirmed resolved, or generated profit, i.e.: The Service Desk’s feedback calls back to the users to confirm that an incident, which has been resolved, can be permanently closed.

In TOC, the concept of Inventory contradicts the conventional balance sheet definition of Inventory as an “asset” and redefines inventory as a “liability.”

Operating Expense: All of the money, time, energy, thought, resources, overtime, etc. tied up in the process of converting raw data or inventory into the output of the process.

Throughput: Defined as the speed at which inventory is moved through the end-to-end process, and delivered to the customer in order to realize the goal of profit, resolution, deployment, etc.

Goldratt observes that these three core principles are inseparably linked and that a change in any one of these three dimensions will automatically result in a proportionate change in the others. The perspective taken by TOC is that the biggest gains are realized by increasing throughput. However, to increase throughput the bottlenecks to the process need to be identified and eliminated.

Question: What occurs when you remove a bottleneck?
Answer: Another bottleneck appears elsewhere in the process.
Result: The identification of the next area for improvement to increase throughput, and the cycle of continuous improvement continues.

Conclusion

In conclusion, Goldratt’s Theory of Constraints places a practical tool in the hands of individuals involved in the ongoing management and improvement of business processes.

Incoming search terms for this article:

Related posts

“Leading Change: Why Transformation Efforts Fail” published in the Harvard Business Review and authored by John Kotter is the definitive guide to the few steps critical to transformation success. Below are five specific additional steps which will greatly improve an organizations ITIL implementation.

  1. The process designers must have working experience of ITIL and general IT experience (and general business experience if possible): All too often ITIL process designers have no experinece of working in IT environments. The problem with this is that processes get designed that are idealistic rather than practical and workable.
  2. ITIL Foundation training is not good enough: Unfortunately ITIL v3 Foundation training (the most basic ITIL official training) is just so broad and covers so much that it is more than likely that participants will leave the training being more confused about ITIL than when they started the training. My advice would be to send relevant people on the Foundation training but also have tailored training specific to certain areas of interest e.g. for Incident Management specifically and Problem Management specifically etc.
  3. Try to keep things simple: ITIL generally receives a groan when mentioned to people. This is because it is often made overcomplicated and people don’t sufficiently understand the benefits. Try to keep ITIL simple and use practical examples when explaining ITIL; for example sum up Incident Management as ‘getting the customer working as quickly as possible even if there is not a permanent solution to the error’.
  4. Reduce Fear: There is normally a significant ‘unknown’ attached to ITIL implementations for those who will be using the processes on a day-to-day basis. Once implemented, and if implemented correctly, the processes become second-nature for those interacting and using them. It is important to stress to those involved that ITIL is not something to fear. What is often helpful to alleviate the fears is to reinforce the positives (such as reduced workload once the processes are embedded) and even get in Service Desk personnel from other companies who have gone through an ITIL implementation to explain the difference the processes made to their work.
  5. Continuous reinforcement that ITIL is evolutionary: ITIL processes should not get implemented and then forgotten. The processes will need revisiting and amendment as time progresses. No one should be under the illusion that the processes implemented will be correct and final on day one of the ‘go live’.

Incoming search terms for this article:

Related posts

ITIL is a set of IT service related processes which define a common language and methodology of providing IT service to organizations. ITIL has been around since the 1980′s when the U.K. government made the great decision to standardise IT Service Processes. ITIL was originally called the Information Technology and abbreviated to ITIL. ITIL has undergone two refreshes since it’s introduction and we are now at ITIL version 3.

ITIL Misconceptions

The two basic misconceptions of ITIL is that it is a set of ridgit processes and that an organization implements ITIL and then may forget about the processes;

  • Ridgid Processes: ITIL is a framework therefore nearly every implementation of ITIL will include differing processes (however a commonality will exist due to the processes being ITIL aligned).
  • Implement and Forget: ITIL implementations are expensive and are evolutionary. One needs regular assessment of the implemented ITIL processes and updating of those processes when required. ITIL books reference the Deming Cycle in describing how process improvement should be ongoing.

Benefits of ITIL

From my experience, the following are the most significant benefits organizations experience by using ITIL processes:

  • Vendor and Customer Alignment: If you outsource, offshore or deliver IT services then, with so many IT related contracts now using ITIL terminology and processes, your supplier or customer is more than likely to be using similar processes and language.
  • Reduced Cost: ITIL is costly to implement but the Return on Investment (ROI) is significant through the cost benefits realised by the reduction of IT downtime, improved reaction times to Errors and Service Requests and so on.
  • Improved Service: Even basic implementations of ITIL deliver significantly improved service to customers.

All sorts of organizations implement ITIL whether IT related or not. Implementing ITIL is a costly and time consuming process but the benefits are considerable .

Related posts