In the process of consolidating the statements of each box, you may feel as if one of the three Clouds is "flipped." In other words, as if the B-D statements and C-D statements from this Cloud should swap their places to "match" the pattern we observe in the other two Clouds. If this has happened, then, for consolidation, just "flip back" these B-D sides and C-D sides to add them to their matching group of statements.

FIGURE 24-11 The Consolidated Cloud of the production manager.

Why does "flipping" happen?

The UDE Cloud is written from the point of view of the "owner" of the Cloud-the one who writes it. Thus, B reflects the need that is endangered for this person (or function).

Very often, the need in C-as recorded by this person-will be representing the need or views of another function of the organization.

However, if we are in a group consensus activity it may be that this "other function" is a member of the group doing the consolidation. He or she may see and agree with the same UDE, but from their point of view it endangers their B. Therefore, we can have the same need that appears in one Cloud in the C box and in another Cloud in the B box. Both needs have connections to their corresponding tactics. Hence, we have a situation that B-D is of the same pattern as the C-D of another Cloud. Knowing that this may happen, we have to review the three Clouds before starting the consolidation step.

Example: UDE #1 We often do not have sufficient capacity to meet all demands.

In Cloud #1, this UDE was perceived as endangering need: "Meet our production schedules" that was recorded in box B.

This is a valid need of the Production Manager who is measured against meeting the production schedules.

However, from the point of view of the Sales Manager, the same UDE may endanger a different need (that is currently recorded in box C in UDE Cloud #1): "Satisfy customers, increasing demands."

And thus while building the UDE#1 Cloud the Sales Manager may put in B the current wording from C, and in D the current wording from D and thus his Cloud will look "flipped."

For the Production Manager, the need that is endangered is the production schedule and the other need to be considered is to satisfy the customers' demands. The Production Manager's view is shown in Fig. 24-12 However, when this Cloud is written from the point of view of the Sales Manager, the same UDE "We often do not have sufficient capacity to meet all demands" endangers the need to satisfy the customers and hence it will appear on the Sales Manager's B-D side of the Cloud. The Sales Manager's view of the endangered need is shown in Fig. 24-13.

In order to consolidate the views of both managers, we have to "flip back" the sides of the flipped Cloud.

While observing the Cloud before consolidating, we can identify the nature of the needs in the Cloud. One is dealing with the needs of production and the other with the needs of the customers and presented by the sales function.

FIGURE 24-12 Example-UDE #1 Cloud from the production manager's point of view.

FIGURE 24-13 Example-the endangered need from the sales manager's point of view.

The Relationships between the Consolidated Cloud and the Core Cloud

The Consolidated Cloud explains the existence of three (or sometimes more) of the chosen UDEs in an area. The role of the Core Conflict13 Cloud is to explain the existence of the majority of the UDEs and the inherent conflict that prevents sorting them out.

Although the Consolidated Cloud points us in the direction of the core Cloud, the analytical work that was done to reach the Consolidated Cloud may not be enough to guarantee that it is the core Cloud because the outcome of the consolidation process may be skewed by the selection of the UDEs.

The following process can be used to verify that the Consolidated Cloud can serve as a Core Cloud: 1. Take another UDE, develop the UDE Cloud for it, and check if the Cloud fits the pattern of the Consolidated Cloud. A fit means that A, B, and C are about the same verbalization and D and D are of the same nature of the D and D' of Consolidated Cloud.

2. Repeat the same step for all the other UDEs.

3. If a fit is found, the Consolidated Cloud can be used as a core Cloud (if at least 70 percent of the UDEs are represented by the Core Cloud).

4. If in the previous steps a UDE Cloud (or several UDE Clouds) does not fit the Consolidated Cloud, then a further consolidation is done by repeating the consolidation process for the UDE Clouds that do not fit together with the Consolidated Cloud. The result of this step can be called "double Consolidated Cloud."

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 to the TOC Way. Every TOC-based solution must use one of the conceptual entities of the pivot such as: The concept of the constraint The Five Focusing Steps (5FS) for constraint management FIGURE 24-14 The detailed structure of the U-Shape.

The three basic concepts of TOC, also known as the three basic assumptions of TOC: convergence, win-win, and respect15 The process of ongoing improvement (BM, 5FS, What, to what, and how) The U-Shape process allows the designer, the implementer, the sponsors, and the people supporting the initiative to go through a proper decision-making process that is based on a true consensus. As such, it allows the team to agree on the problem, the direction of the solution, the elements of the solution, and their corresponding benefits.

U-Shape and the Three Basic Assumptions of TOC

The U-Shape is based on the three basic assumptions of TOC. As such, we can state what is unique about the TOC Way.

Basic Assumption 1-Convergence-reality, and specifically human based systems, are governed by cause-and-effect relationships. Hence, it is always possible to find a root cause that affects the system. The convergence is presented in the left side of the U-Shape.

Basic Assumption 2-No conflict between local and global exists. As conflicts are caused by people's perceptions or by systems, there must be a solution for every conflict. The implication of this assumption is that there should be a win-win solution for every conflict. The win-win solution is comprised of the injections on the right side of the U-Shape.

Basic Assumption 3-Handle people with respect. The entire U-Shape represents this basic assumption. It contains the respect of the managers for themselves. It reflects the seriousness in which they take their jobs. Respect for other people is demonstrated through the sharing of the work done and the willingness to ascertain and integrate inputs and views expressed by people who are relevant to the work.

The way these assumptions are incorporated on the U-Shape is given in Fig. 24-15.

The overall structure of the U-Shape contains several major blocks regarding the system under study.

Current Reality-reflected in the left side of the U-Shape: The unsatisfactory level of performance The problem Future Reality-reflected in the right side of the U-Shape: The solution Checking and removing risks The desired outcomes The improved performance The essence of the approach for the solution point-the pivot-is the turning point from the left side to the right side of the U-Shape.

FIGURE 24-15 The U-Shape and the three basic assumptions of TOC.

The Use of the U-Shape for Solving Daily Problems

Due to its generic structure of moving from the problem to the solution through the pivot, the U-Shape is valid for describing the approach for solving one problem as well as for the entire system.

The process outline used for all the daily problems corresponds to the U-Shape: Step 1: Identify the problem-the desire to deal with the problem stems from the unsatisfactory performance revealed by the problem and the need to improve the situation.

Step 2: The Storyline-helps to unleash the intuition about the current reality explaining why the problem has caused the low performance. This is similar to identifying the UDEs and explaining how they cause the low performance.

Step 3 and Step 4: Build, Check, and Upgrade the Cloud- are the manifestation of the convergence and result in a Cloud that explains why under the current conditions it is impossible to find a workable solution.

Step 5: Surface the assumptions-is a part of working with the Cloud, in preparation for constructing the solution.

Steps 6: Construct the solution-corresponds to the whole right side of the U-Shape: 1. The pivot-in search for injections that can break the Cloud.

2. The direction of the solution-when the solution contains a change in the mindset or a system change (like in the multi-problem case).

3. The injections themselves.

4. Stating the logic that the solution will bring the benefits-the achievement of the Needs B and C of the Cloud. These benefits are equivalent to the DEs-the desired effects. The logical connection between the satisfied needs B and C and the objective A of the Cloud leads to the improved performance of the area affected by the problem.

5. Checking and addressing potential negative effects by using the NBR process.

Step 7: Communicate the solution-The U-Shape provides an approach to communication. It captures all the knowledge that is relevant for the suggested solution. A manager who has done all the homework and has the understanding of the U-Shape can handle all comments and reservations from any person whose collaboration and support is needed. The U-Shape provides the base for a justifiable confidence of the manager in the suggested solution.

We can conclude that the process that was suggested for solving problems using the Cloud method is parallel to the methodology presented in the U-Shape. Yet there is one more element to add to constructing the solution-the NBR. This is covered in the next section.

Strengthening the Solutions-Dealing with NBRs