Theory of Constraints Handbook - James Cox Iii [503]
Once a Cloud is written, it provides several places for us to search for and locate the invalid assumption that is forcing the conflict—the perceived need for a contradiction (D and D′). If we could figure out that B is not really a necessary condition for A, then D is no longer necessary, and the conflict would be eliminated. Or, if we could figure out that D is not really a necessary condition for B, then it is no longer necessary, and the conflict could be eliminated. Or, if we could figure out that C is not really a necessary condition for A, then D′ is not needed and the conflict would be eliminated. Or, if we could figure out that D′ is not really a necessary condition for C, then it is no longer necessary and the conflict could be eliminated. Or, if we could figure out that D and D′ are not really contradictions to each other and could actually coexist, then the conflict could be eliminated!
Necessity is not an established fact, but an interpretation.
—Friedrich Nietzsche
The Cloud is used to articulate any problem as a conflict, find the erroneous necessary condition relationship, and establish an injection that creates the path for a solution in which the conflict is fully eliminated. Some of the generic situations in which a Cloud is used are:
Being caught between a rock and hard place—a decision needs to be made, and the only options available mean meeting the needs of one side and sacrificing the needs of the other.
Eliminating gaps between authority and responsibility (the main cause for “firefighting” in organizations).
Any argument between individuals, teams, organizations, and communities.
When TOC is implemented in operations, improving flow (reducing lead time) becomes an explicit, primary objective of the operation. Once the flow is put under control of the solutions such as Drum-Buffer-Rope (DBR) and Buffer Management (BM), the Process of Ongoing Improvement (POOGI) is put in place, in order to constantly improve the flow. The POOGI process for a make-to-order (MTO) manufacturer consists of documenting the answer to the question, “What is the order waiting for?” every time an order is delayed (not moving) for 10 percent of the production lead time. Periodically (e.g., weekly), a Pareto analysis is performed on the sources8 of all such delays that occurred for orders that the priority system (BM) indicated were at risk of becoming late. Teams are then put to the task of analyzing and eliminating the major sources of delay.9 The Cloud is a critical tool that teams use to analyze and solve the major source of delay. An example of this is provided as the steps to use an EC are described. You will also find detailed guidelines for using the Cloud on a day-to-day basis in Chapter 24.
TABLE 25-1 Examples of D and D′ Conflicts
1. Write the D and D′ entities of the Cloud. Write them in a way that it is obvious that they are mutually exclusive. Some examples are in Table 25-1.
Our example company makes heavy steel products. In order to form and machine the steel to their customer specifications, the process includes heat treat—putting the product in large ovens to heat the steel and then placing the product in a tank of liquid (quench tank) to cool it rapidly and bring it to possess the metallurgical properties needed. The weekly POOGI Pareto analysis revealed that the most frequent answer to “What is the order waiting for?” was “Waiting for heat treat.” A POOGI team was assigned to analyze and eliminate heat treat as a major source of delay. As they reviewed the data, they found that the vast majority of the delays could be further classified as “green10 orders waiting for the assigned quench tank to become available.” They began to construct the Cloud (Fig. 25-12).
2. Write the corresponding B and C entities.
B should answer the following questions:
For what is D needed?
What need will not