2. The major reason for an obstacle to be a show stopper is the lack of an important resource. This is the blocking factor: "We do not have money, time, manpower, willingness of our employees etc."

3. Develop the IO to overcome the blocking factor.

TABLE 24-10 Obstacles, Show Stoppers, Injections, and Blocking Factors Example: Obstacle 3: How do we know the system will be acceptable to all parties?

Blocking factor: Consensus on the new system (lack of consensus).

IO-3: There is a top management resolution that is based on the consensus of all stakeholders. See Table 24-11.

Step 6: Review the whole list of IOs and Deliverables and if there are many, then split them into groups related to the same topic. An example of grouping lOs is provided in Fig. 24-19.

Step 7: Sequence the lOs to create an IO Map.

Review and check the resulting implementation plan.

The IO Map

By now, we have a list of (grouped) IOs for accomplishing the injection. The IO Map is a plan that determines the sequence of IOs to be achieved in the transition to implement the Injection.

The logic of the sequence is that one IO has to be in place before the next IO can be achieved. There is a dependency based on tangible deliverables that each IO produces as shown in Fig. 24-20.

TABLE 24-11 Overcoming the Blocking Factor FIGURE 24-19 Example of grouping the IOs for the RIS.

FIGURE 24-20 An example of an IO map.

The IO Map is simple and easy to construct as it is based on logic and intuition.

Sequencing the IO Map is done by stating the relationships between the IOs. Some IOs are dependent on the completion of others.

This is due to a tangible deliverable that is the outcome of one IO and is necessary for the other IO.

In the case that several actions need to be taken in order to achieve the IO, we can list them and insert them into the plan.

Here is a suggested process for sequencing the IOs: Task 1: Copy the recorded IOs17 onto Post-Its.

Task 2: Sequence the IOs.

Start with the ambitious target on the right of the page.

Insert the IOs moving from the end (right) back to the start (left) to establish the logical dependency.

Use the method of checking the dependency between them by reading: "Before we can have (later IO) we must have completed (earlier IO)."

If there is no dependency, the IOs can be achieved in parallel.8 Task 3: Present the sequence to your team that has intuition about the environment. Collect the feedback and make the necessary corrections to the diagram. Check with the team that all IOs that need to be there are on the IO Map.

Task 4: Record the IO Map on an Excel file (some people tend to record the IO map on a project plan file as a PERT structure).

Implementing a Solution of Several Injections

When you have a solution that contains more than one injection, you should implement them in logical order according to the internal dependencies between them.

The sequence for creating the IO map: 1. Build the Injection Map.

2. Determine Intermediate Objectives (IOs) for each injection (as per Steps 4 or 5 of the process of addressing obstacles).

3. Sequence the IO map for each injection.

Please note: If the process is done by a group, then task 2 is done by a group check of the dependency between every two IOs as we progress for every Post-It that we introduce with an IO. The PRT is used in the full TP work for capturing the logical connection between the IOs and the obstacles as well as the reasoning for the sequencing.

4. Integration of the individual IO Maps into the Injection Map.

5. Check the integrated map to ensure that it is logically sound and complete.

Injection Map: When the solution contains several injections, the overall plan is built by combining several IO Maps into the Injection Map of the solution.

We first build an Injection Map stating the sequence we plan to put the injections in reality. Some injections are implemented one after another; some can be implemented in parallel. Examples of an Injection Map, a fully integrated IO Map, and a Multi-Injection IO Map are provided in Fig. 24-21.

The Multi-Injection IO Map can be translated into a project plan. The project plan contains deliverables and tasks.

Deliverables (IOs) are major milestones in the implementation of the injection. They are tangible and can be measured. In the plan to implement the injection, they are the intermediate objectives marking the steps toward the completion of the implementation.

Tasks are all the activities to be taken by the project team in order to achieve the deliverables. They are actions performed by specific resources and estimated time duration.

Example: Injection: Throughput Dollar Days (TDD) is used as the prime measurement for on-time delivery of projects. An example of a mini-project plan for implementing an injection is provided in Fig. 24-22.

We can conclude that the IO Maps provide the manager with a planning tool for the implementation of the solution. Involving relevant people in the process of building the maps can create ownership and enhance the involvement and support in making the solution a reality.

Conclusion-Problem Solving the TOC Way

The TOC approach is based on the managers' self-commitment to improve the performance under their responsibility. The TOC way is to work systematically by answering the three questions of improvement (what to change, what to change to, and how to cause the change). Not every problem and challenge demands a thorough analysis and developing a breakthrough solution. Managers do make good decisions (and sometimes "pay" for their bad decisions). The purpose of this chapter was to enhance the ability to make decisions by providing tools to handle problems systematically and support in developing the skills to use them. The tools described in this chapter can be added to your personal toolbox. Practice and use them when you feel it is appropriate.

FIGURE 24-21 Example of an Injection Map and Multi-Injection IO Map.

FIGURE 24-22 Example of mini-project plan for implementing an injection.

For addressing a problem systematically and explicitly, we propose the comprehensive process that we have outlined in this chapter. The flow of the process covers the three questions for improvement.

There are two inputs to the planning process: Necessary deliverables are encountered in the course of the injection implementation and must be achieved to make sure that the injection becomes the reality. These entities are usually obtained by you or other people, stating that if you want this injection to work you must do . . . Experience or logic suggests these clear steps for achieving such changes in reality.

Major obstacles are perceived "show stoppers" that might completely block the ability to implement the injection. This input comes from the "Yes, but . . ." statements that indicate why it is going to be difficult to implement the solution. These blockages are used for building the PRT by determining IOs that overcome the obstacle.

What to Change to? Construct simple practical solutions.

Choose an injection that breaks the Cloud and supports both needs in the Cloud (win-win).

Deal with potential negative outcomes by using the NBR process as a part of the solution or as a part of the implementation.

How to Cause the Change? Induce the proper people to support and implement the solution (preferably by participating in the construction of the solution or by suggesting parts of the solution). To better facilitate the change, it is expected that the manager does the preparatory work ("homework") covering the first two questions-the problem and the solution. Then facilitate the next two steps: Achieve consensus and buy-in.

Develop the IO Map and implementation plan (for system changes).

If you want to be proficient with these tools, then you must continuously practice. The more you practice, the better you become and the quicker you are in using these tools, even to the extent that you can do most of the work in your head without any writing. Therefore, you must keep on practicing. Use every opportunity.

Warning: Do not push the TP on your people.

Ensure that the TP works for you but do not impose it on your subordinates. Some people may find the TP too deep, too demanding, and sometimes even threatening. Some people may feel uncomfortable with the tools themselves and the mechanics. The TP are the tools for the individuals. I suggest that you approach your staff in stages. First, use the TP for yourself and ensure that your staff gets benefits through the way you handle and solve problems. Later on, they may be interested to know how you address the problems systematically. In the later stages, some of the staff may be interested to learn these tools for themselves. You may teach them, point them to appropriate educational materials, or send them to a school.

Embarking on TOC is a personal choice. My view of TOC is that you do TOC seriously or you do not do it at all. The strength of TOC is its knowledge and the methodology for understanding and developing new knowledge. The processes suggested in this chapter are quite demanding in terms of the amount of personal preparatory work that the TOC practitioner is expected to do. The real joy in working with TOC is making it happen. It comes when you can see that the injection is alive and kicking in the system and the people are happy to testify that the injection has brought them real benefits, proving the Future Reality Tree (FRT) is valid!

Improving systems performance needs a blend of three ingredients: 1. A relevant win-win solution is a solution that is applicable for the specific situation of the system.

2. Leader and leadership are to point the direction and pave the way for others to be able to move in the new direction.

3. Supportive culture is to provide proper subordination to the direction and to actively participate and contribute in making the vision a reality.

The design of the solution is the responsibility of the manager who adopts TOC. The other two elements are a part of the culture of the manager's area and the overall company. My suggestion is that in dealing with the improved performance of the area under your responsibility, you should adopt the approach of being firm and fair and always showing respect for people. This means that you do your homework, develop the solutions, and then communicate them to the proper people. Listen to their feedback and suggestions but do not allow the discussion to deteriorate to "analysis paralysis." You should be firm and demand closure and actions.

Last comment-I hope that this chapter has given you enough knowledge for starting your personal journey with the TOC TP. By now, you may appreciate that I have covered only a part of the vast knowledge that is there on this subject. The Cloud deserves a book dedicated to it, which I intend to write in the near future.

References

Goldratt, E. M. 1990. What Is This Thing Called Theory of Constraints and How Should It Be Implemented? Croton-on-Hudson, NY: North River Press.

Goldratt, E. M. 1994. It's Not Luck. Great Barrington, MA: North River Press.

Goldratt, E. M. 2002. Necessary & sufficient CD-2: The basic assumptions of TOC, Goldratt Marketing Group.

Goldratt, E. M. 2009. The Choice. Great Barrington, MA: North River Press.

Goldratt, E. M. and Cox, J. 1984. The Goal: Excellence in Manufacturing. Croton-on-Hudson, NY: North River Press.

Sullivan, T. T., Reid, R. A., and Cartier, B. 2007. TOCICO Dictionary. http://www.tocico.org/resource/resmgr/files-public/tocico_dictonary_first_edit.pdf

About the Author.

Oded Cohen is one of the world's well-known names in Theory of Constrains (TOC). He has 30 years of experience in developing, teaching, and implementing TOC methodology, solutions, and implementation processes working directly with Dr. Goldratt all over the world. Among the countries to which Oded brings his expertise are the United States, Canada, Japan, India, China, the UK, Poland, Russia, Ukraine, Columbia, Chile, Peru, and many others.

Oded is an Industrial Engineer with an MSc in Operations Research from the Israeli Institute of Technology in Haifa, Israel. He was one of the developers of Optimized Production Technology (OPT-a registered trademark of Scheduling Technologies Group Limited, Hounslow, UK)-the logistical software for production scheduling, the TOC Thinking Processes, and the TOC management skills.

Oded has brought his expertise to educating a whole generation of TOC practitioners and implementers. He is known for his passion for working with people who love TOC.

Since 2001, Oded has been a part of the Goldratt Group as the International Director for Goldratt Schools-the organization that is committed to ensuring that the TOC knowledge is readily available for everyone who wants to learn TOC from a teacher. Goldratt Schools plays a major role in developing and supporting TOC Application Experts and TOC Consultants who are given the knowledge and the practical know-how for implementing TOC solutions.

Oded coauthored the book Deming & Goldratt: The Theory of Constraints and the System of Profound Knowledge-The Decalogue and is the author of the recently published book Ever Improve-A Guide to Managing Production the TOC Way.

CHAPTER 25.

Thinking Processes Including S&T Trees