The Evaporating Cloud is one of the six Thinking Processes in the Theory of Constraints. The Evaporating Cloud (EC) - also referred to in the literature as "the cloud", or as a "conflict resolution diagram" - is a logical diagram representing a problem that has no obvious satisfactory solution.
The most commonly used of the TOC tools,[note 1] the EC was designed to address conﬂict or dilemma situations (trade-off situations where there is no acceptable compromise) by diagramming the logic behind the conflict and methodically examining the assumptions behind the logic. 
The EC has a set format with five boxes, labelled A, B, C, D, D’, that are usually laid out as follows:
[B] ← [D ] [A] / ↑ / \ [A] conflict OR [B] [C] \ ↓ ↑ ↑ [C] ← [D’] [D] ↔ [D’]
The boxes represent two opposing wants that represent the conflict (D, D’)[note 2], the needs that each want is trying to satisfy (B, C), and a common objective or goal (A) that both needs are trying to fulfil.[note 3]
The lines or arrows connecting the nodes represent the rationale or causal assumptions that are used to link the nodes. When communicating the cloud, the arrows should be read as “in order to” or “because” or “so that”. For example: “In order to achieve A we require B because there is no way we can have A without B.” Or: “There is no way we can have D and have D’ (read as "D-prime") at the same time.”
Origin of Name
- If you really want to remove a cloud from your life, you do not make a big production out of it, you just relax and remove it from your thinking. That’s all there is to it.
The Evaporating Cloud tool is intended to similarly "vapourize" difficult problems by resolving an underlying conflict.
- [Goldratt teaches] that every problem is a conﬂict, and that conﬂicts arise because we create them by believing at least one erroneous assumption. Thus, simply by thinking about the assumptions that enforce the existence of a conﬂict, we should be able to resolve any conﬂict by evaporating it with the power of our thinking.
Steps in problem solving
The general process for applying an EC to problem solving is described by Cohen (2010) as follows:(p676)
- Identify the type of problem (there are variations in the way the diagrams are constructed for different types of problems.)
- Write a storyline of this problem in a factual, objective way, even if the problem causes an emotional upset.
- Build the Cloud (see example guides below).
- Check the logical statements of the Cloud and make necessary corrections and upgrades.
- Surface the assumptions behind the logical connections to find the one that is supporting the conflict.[note 4]
- Construct your solution and check it for win-win.
- Communicate the solution to the people involved in dealing with the problem.
Clouds are "built" by filling in the appropriate boxes with statements about the situation. Both the wording of the statements and the sequence of filling the boxes can be important. Below is a guide to the recommended sequence and questions for building Day-to-day Conflict or Inner Dilemma clouds.(pp679, 689)
|D||What action does the other side want to do/do I feel under pressure to do?|
|D′||What is the action I want to do?|
|C||What need is satisfied by my action in D′?|
|B||What need is satisfied by their/my action in D?|
|A||What common objective will be achieved by meeting both need B and need C?|
Different types of problems have slightly different requirements when it comes to documenting and communicating the underlying conflict. Below is a summary of different types of problems, and the suggested sequence for building and communicating the cloud.(p711)
|Cloud||Sequence to Build||Sequence to Communicate|
|Inner Dilemma||D-D′-C-B-A||A-C-D′ A-B-D|
|Day-to-Day Conflict||D-D′-C-B-A||A-B-D A-C-D′|
|Fire-Fighting||B-D-D′-C-A||A-B-D A-C-D′[note 5]|
|UDE||B-D-C-D′-A||A-B-D A-C-D′[note 5]|
|Generic Cloud||A-B-C-D-D′||A-B-D A-C-D′[note 6]|
Goldratt has illustrated the use of the evaporating cloud technique in a discussion of the Economic production quantity model.(p43) The prerequisite wants are to run large batches (D) and yet to run small batches (D’). These are clearly in conflict. The required need that D is trying to meet is to reduce setup cost (B), whereas the D’ prerequisite needs to reduce carrying cost per unit (C). Both requirements are aimed at the objective (A): to reduce cost per unit.
Fedurko (2011) recommends checking the logic of the EC by reading the logical statements aloud, in the following sequence:(pp13, 22)
- In order to reduce cost per unit, we must reduce setup cost per unit.
- In order to reduce setup cost per unit we must run large batches.
- in order to reduce cost per unit, we must reduce carrying cost per unit.
- In order to reduce carrying cost per unit we must run small batches.
- Running large batches and running small batches are in direct conflict.
- Running large batches puts in danger the need to reduce carrying cost per unit.
- Running small batches puts in danger the need to reduce setup cost per unit.
According to Fedurko,
- Reading aloud ... is needed because it explicitly employs the auditory channel as an additional mechanism to process and check the logic.(p13)
Goldratt claims that each of the logical connections in the EC represent an (often hidden) assumption.
- One of the most basic fundamentals of logic is, that behind any logical connection there is an assumption.(p47)
The assumptions behind the above connections can be surfaced by again reading the statements with a "because" clause added.(p31) For example, Goldratt surfaces the following assumptions behind the 2nd statement in the example EC:
- In order to reduce setup cost per unit we must run large batches, because
- setup cost is fixed and can't be reduced.
- the machine being set up is a bottleneck with no spare capacity.(pp48-50)
And again, with the 5th statement:
- Running large batches and running small batches are in direct conflict, because:
- large is the opposite of small.
- there is only one meaning to the word "batch".(pp50-51)
The second assumption is challenged by distinguishing between production batch size (between setups) and transfer batch size (between workstations), and so allowing different sized batches for different purposes.
Core Conflict Cloud
The Core Conflict Cloud is an Evaporating Cloud that emerges from analysis of a current reality tree (CRT), which is one of the Thinking Processes. The CRT provides a way for analyzing many system or organizational problems at once, treating them as symptoms of a single core problem. If an easy solution to such a core problem has not already been implemented, it is likely there is some conflict in the organization that is blocking implementation. The role of the Core Conflict Cloud is to address this inherent conflict that is preventing the sorting out of the core problem.(p710)
- The EC is reported to be used in 77% of TOC case-studies, according to one report.
- The conflict can take the form of either "do this vs don't do this", or "do action 1 vs do action 2" where both actions can't be done at once.(p10)
- For example, a cloud based on an airlines case study has the conflict (D vs D’) stated as "minimize service costs" vs "do not minimize service costs." The needs (B, C) are stated respectively as "have the least cost" and "have superior service", with the common objective (A) being to "provide quality".
- Usually the best connections to examine are the ones between C-D′ or B-D. While addressing the D-D′ connection is ideal, it is not usually feasible.(pp681-684)
- The given sequence assumes that C-D′ represents your side (or your favorite side), which should be communicated last.
- The given sequence assumes that C-D′ represents the side least likely to be defensive. This side of the conflict should be communicated last.
- Dettmer, H,W. 1999. The conflict resolution diagram: Creating win-win solutions, Quality Progress,32(3):41
- Fedurko, Jelena. Behind the cloud: Enhancing logical thinking. TOC Strategic Solutions Ltd (2011)
- Kim, Seonmin, Victoria Jane Mabin, and John Davies. "The theory of constraints thinking processes: retrospect and prospect." International Journal of Operations & Production Management 28.2 (2008): 155-184.
- Victoria J. Mabin, Steve Forgeson and Lawrence Green. Harnessing resistance: using the theory of constraints to assist change management. Journal of European Industrial Training. 25/2/3/4  168±191
- Polito, Tony, Kevin Watson, and Robert J. Vokurka. "Using the theory of constraints to improve competitiveness: an airline case study." Competitiveness Review: An International Business Journal incorporating Journal of Global Competitiveness 16.1 (2006): 44-50.
- Bach, Richard, Illusions: The Adventures of a Reluctant Messiah. Dell Publishing, 1977.
- Scheinkopf, Lisa J. Thinking for a change: Putting the TOC thinking processes to use. CRC Press, 2002.
- James F. Cox III, Ph.D, CFPIM, CIRM; John G. Schleier, Jr.: Theory of Constraints Handbook. Daily Management with TOC, Chapter (McGraw-Hill Professional, 2010), AccessEngineering
- E.M. Goldratt. What is this thing called the Theory of Constraints and how is it implemented? North River Press: Crofton-on-Hudson NY, 1990.
- Eric Noreen; Debra Smith; James T. Mackey (1995). The Theory of Constraints and its implications for Management Accounting. North River Press. p. 165. ISBN 0-88427-116-1.