Evaporating cloud

The evaporating cloud is one of the six thinking processes in the theory of constraints (TOC). The evaporating cloud (EC) – also referred to in the literature as "the cloud", or as a "conflict resolution diagram"^[1] – is a logical diagram representing a problem that has no obvious satisfactory solution.^[2]

Overview

The most commonly used of the TOC tools,^[note 1] the EC was designed to address conflict 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. ^[3]

The EC has a set format with five boxes, labelled A, B, C, D, D’, that are usually laid out as follows:^[4]

   [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

According to Scheinkopf (2002) the evaporating cloud is so named in honor of Richard Bach. In Bach's 1977 book Illusions, the main characters remove storm clouds from the sky by thinking them away.

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.^[6]

The evaporating cloud tool is intended to similarly "vapourize" difficult problems by resolving an underlying conflict.

[Goldratt teaches] that every problem is a conflict, and that conflicts 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 conflict, we should be able to resolve any conflict by evaporating it with the power of our thinking.^[7]

Steps in problem solving

The general process for applying an EC to problem solving is described by Cohen (2010) as follows:^[8]: 676

1. Identify the type of problem (there are variations in the way the diagrams are constructed for different types of problems.)
2. Write a storyline of this problem in a factual, objective way, even if the problem causes an emotional upset.
3. Build the cloud (see example guides below).
4. Check the logical statements of the cloud and make necessary corrections and upgrades.
5. Surface the assumptions behind the logical connections to find the one that is supporting the conflict.^[note 4]
6. Construct your solution and check it for win-win.
7. 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.^{[8]: 679, 689}

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.^[8]: 711

Example

Goldratt has illustrated the use of the evaporating cloud technique in a discussion of the Economic production quantity model.^[9]: 43 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:^{[2]: 13, 22}

1. In order to reduce cost per unit, we must reduce setup cost per unit.
2. In order to reduce setup cost per unit we must run large batches.
3. in order to reduce cost per unit, we must reduce carrying cost per unit.
4. In order to reduce carrying cost per unit we must run small batches.
5. Running large batches and running small batches are in direct conflict.
6. Running large batches puts in danger the need to reduce carrying cost per unit.
7. 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.^[2]: 13

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.^[9]: 47

The assumptions behind the above connections can be surfaced by again reading the statements with a "because" clause added.^[2]: 31 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
  1. setup cost is fixed and can't be reduced.
  2. the machine being set up is a bottleneck with no spare capacity.^{[9]: 48–50}

And again, with the 5th statement:

• Running large batches and running small batches are in direct conflict, because:
  1. large is the opposite of small.
  2. there is only one meaning to the word "batch".^{[9]: 50–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.^[10] The role of the core conflict cloud is to address this inherent conflict that is preventing the sorting out of the core problem.^[8]: 710

See also

• Process decision program chart which is a visually similar diagramming method. The difference is that PDPC is used for planning contingencies, while evaporating cloud technique is for problem solving and conflict management.

Further reading

• Dettmer, H. William. (2007). The Logical Thinking Process: A Systems Approach to Complex Problem Solving. ISBN 978-0-87389-723-5.
• Fedurko, Jelena. (2011). Behind the cloud: Enhancing logical thinking. ISBN 978-9-94991-480-7.
• Fedurko, Jelena. (2013). Through clouds to solutions: Working with UDEs and UDE clouds. ISBN 978-9-94991-482-1.
• Goldratt, Eliyahu M. (1994). It's not luck. ISBN 0-88427-115-3.
• Scheinkopf, Lisa. (2002). Thinking For a Change: Putting the TOC Thinking Processes to Use. ISBN 1-57444-101-9.
• Schragenheim, Eli. (1998). Management Dilemmas: The Theory of Constraints Approach to Problem Identification and Solutions. ISBN 1-57444-222-8.
• Techt, Uwe. (2016). Win-Win Solutions: A workbook for solving dilemmas and conflict situations effectively. ISBN 978-3-83820-961-6.

Notes

References

This page was last edited on 26 November 2023, at 23:40