Theory of Constraints Handbook - James Cox Iii [487]
5. The “Double Consolidated” Cloud can be used as the Core Cloud as it represents the majority of the UDE’s of the system.14
Now that we have built the Consolidated Cloud, we move on with the process.
Step 4: Check and upgrade the Consolidated Cloud.
Step 5: Surface the assumptions underlying the Consolidated Cloud.
To be done the same way it is done for every type of Cloud.
Step 6: Construct the solution and check it for win-win.
It is unlikely that one injection can solve multiple problems and UDEs. The solution is developed in two tiers:
TABLE 24-9 Summary of the Key Points for Each Cloud
1. Breaking the Consolidated Cloud—the chosen injection provides the direction for the solution as it deals with the general problem. This injection usually provides the necessary mindset for the solution.
2. Breaking the individual Clouds—identify injections that solve the specific UDEs to remove the specific causes for the UDEs. Therefore, we may find that one injection is not enough to solve all the UDEs and the solution will contain several injections.
Step 7: Communicate the solution.
Follow the communication guidelines as described before.
With the Consolidated Cloud procedures, we have covered the popular usages of the Cloud as a stand-alone thinking process.
Summary
Thus far, we have described five types of Clouds—the first three are for daily use to deal with one-off problems, the UDE Cloud is used for nagging problems that do not go away, and the generic (consolidated) Cloud is used for finding and addressing deeper problems and is used periodically as needed, especially for a POOGI.
A summary view covering the suggested sequence of building the Cloud, sequence of communicating it, and the recommended arrow to break is provided in Table 24-9.
In the next section we will review the processes that we have used as reflected by the overall TOC methodology for problem solving—the U-Shape.
From a Problem to the Solution Implementation
The TOC process (Goldratt, 1990, 20) for identifying the problem to implementing the problem solution generally centers on responding to the following three questions:
1. What to Change?
2. To What to Change to?
3. How to Cause the Change?
The following approach is an alternative and works well on using a single Cloud to frame and solve a problem or on much larger system problems.
The TOC Methodology for Problem Solving—the U-Shape
We have covered the use of the Cloud method extensively. The suggested process for the solving problems is a derivative of the full TP methodology. Presenting the U-Shape will put all the elements together and demonstrate the way that all elements of the process are interconnected.
In a simple schematic way, the U-Shape records the logic of the relevant components that participate in the analysis of an existing current reality of a system under study (What to Change), the direction of the solution, the necessary elements of the detailed solution, and the expected benefits and impact on the performance of the system. It covers the majority of what is necessary in order to develop a full conceptual improvement solution that is viable and contains very little risk to the existing system. The structure is shown in Fig. 24-14.
The U-Shape provides evidence of what is claimed to be the “inherent simplicity” of every system. Through the logic of cause-and-effect relationships, it allows the individual to better comprehend large amounts of data, to store the logical structure, and to be able to retrieve and use it when needed. It contains the TOC specially defined data elements of the system such as low performance measurements, system problems (the UDEs), the core problem, the direction of the solution, the elements of the solution (the injections), the potential risks (negative branches), and the expected benefits from the solution, the desired effects leading to high performance measures.
The U-Shape connects the problem with the solution through the pivot—the conceptual shift from the current mode of managing