TOC Thinkers

Eli Schragenheim and Bill Dettmer - Supply Chain Management at Warp Speed

It's not every day you get to chat with two of your heroes ...

I've just completed a fascinating interview with two of the TOC Worlds most brilliant and innovative thinkers. Bill Dettmer and Eli Schragenheim. Although the focus of the interview is on their new book "Supply Chain Management at Warp Speed" we also wander off into some other fascinating areas. They've got some great book recommendations between them, for example. Plus they talk about their next publishing efforts. Oh, and Bill mentions the key reason why you'd want to buy the book - it's the first public viewing of the TOC solution to ************** (you'll have to listen to find out). I can't tell you how pleasurable this session was for me - to chat with two of my heroes. 

You can order the book here: http://www.amazon.com/Supply-Chain-Management-Warp-Speed/dp/1420073354/ref=sr_1_2?ie=UTF8&s=books&qid=1239384783&sr=1-2

You're probably best to download the file files directly.  Here's Part 1  and here's Part 2.  Why two parts?  'coz computers suck and my recording software went a little wonky.  You'll miss about 30 seconds worth of conversation but Bill revisits that near the start of part 2.  I hate computers.

The recordings last about an hour and a quarter all up.

Video Review of Bill Dettmer's Strategic Navigation.

http://kallokain.blogspot.com/2008/07/book-review-webcast-logical-thinking.html

Q&A with Bill Dettmer - Q6 - What is next book?

Q: What is your next book going to be about Bill?

Hmmm...why does anybody assume that there will be a "next book?" When I finished writing Strategic Navigation, I thought that I'd said all I had to say. Then three years later, my publisher persuaded me to write a "second edition" of Goldratt's Theory of Constraints, which turned out to be so different from the original version that it warranted a new title.

When that happened, I had been gradually collecting the research material for "the next book." I have a 3-cubic-foot book box nearly filled with research papers, books, and a rough outline. My intention is to write (eventually) a book on systems thinking and the systems approach to management. It will be far more than Senge's The Fifth Discipline, though it will incorporate some of that.

Most people don't realize that systems thinking/management predated Senge by a couple of decades, dating back to Churchman's and Checkland's writings about it in the 1960s, and E.S. Quade's work on systems analysis for the Rand Corporation. I got my masters degree in systems management from the University of Southern California through a program that had been conceived in 1964. I later taught for seven years in that same program. Even that program, though it aspired to be a "whole systems" wrap-around, had to make do with piecemeal, patchwork subjects-topics-tools all stitched together under the rubric of "systems management." There was no single text book that addressed the overall philosophy of managing systems, rather than just gluing together optimized processes.

So my magnum opus, which I would like to start on sometime next year, will be that wrap-around text book on systems thinking/management. I want to try to integrate such diverse thinkers as Kuhn, Diamond, Argyris, Kotter, Ackoff, Churchman, Checkland, Senge, Boyd, etc., and---yes---Goldratt. I want to try to create a kind of "unified field theory" on understanding systems. All that said, this is a big undertaking, and I may not get to it next year---or maybe not ever. Before I do anything else, Eli Schragenheim and I have to finish our sequel to Manufacturing at Warp Speed (tentatively titled Supply Chain Fulfillment at Warp Speed), which is due to our publisher in mid-2008.

Clarke: Great, I'll have plenty of new questions when both of these questions come out. 

Q&A with Bill Dettmer - Q5 - What is the big deal about Boyd?

Q: You know, Bill, I've never really been all that attracted to the Boyd loop and yet a lot of TOC people are.  For some reason I find myself nodding off whenever I read about it (not in your Strategic Navigation book specifically, but in general). 

Can you take one last shot at convincing me why I should learn more?

Well, when you nod off, I certainly hope that you're getting some quality rest! I've often said that I thought my books could be a sure cure for insomnia, but now I have first-hand testimony confirming it!

Far be it from me to force any kind of thinking on anyone. If it doesn't intrigue you, then it probably wouldn't be worth your time and effort to study it. I can suggest one reason why that might be the case, however. From what little I've seen, most people come directly to the OODA loop (observe-orient-decide-act) without any foundation for how or why it was developed, or what it can (and has) done. So let me make just three points about Boyd and his OODA loop.

First, the OODA loop is like the tip of an iceberg. It's a potential entry point into something much larger in scope than TOC alone---systems thinking. It forces one to consider factors well beyond what one typically focuses one's attention on. This happens primarily in the "observe" and "orient" steps. The OODA loop is just an expression of a larger philosophy that Boyd propounded called maneuver warfare. Don't be deceived by the term "warfare." Though Boyd's application of his philosophy (and the OODA loop) was primarily military-oriented, it didn't take long for perceptive people to see the transferability to ANY competitive environment at all, for example business or even sports. (I recently wrote a white paper on the application of maneuver warfare to the sport of American football.) So, what intrigues me about Boyd and the OODA loop is that they represent a gateway to a meta-level consideration of systems, of which TOC is only a part. A really excellent book---relatively short, easy-to-read, and full of valuable information advice---is Certain to Win, by Chet Richards. Chet was one of Boyd's early colleagues and understands the Boyd philosophy as well as anyone out there. More importantly, he can express it in an eminently readable way.

Second, Boyd's personal history alone is fascinating. I first learned about him when a friend and respected colleague recommended the book Boyd: The Fighter Pilot Who Changed the Art of War, by Robert Coram. Owing to my former military career, it piqued my interest. The story of how Boyd evolved his philosophy through his life experiences was so engaging that I read the whole book in three sittings over two days. Perhaps the most fascinating part for me was that as he was evolving the philosophy, he was using it in an organizational setting---the Pentagon---to beat the defense bureaucracy at its own game! The part describing how then-Secretary of Defense Dick Cheney called Boyd in secretly in November 1990, after General Schwarzkopf had presented his battle plan for Operation Desert Storm, was a revelation to me. Apparently, Schwarzkopf had proposed a frontal assault on the Iraqi Army in Kuwait that anticipated 10,000 or more casualties. For Cheney, this was unacceptable. He called in Boyd, who essentially steered the battle planning toward maneuver-thinking, and the result was the famous "left hook" that bagged the entire Iraqi Army and half of the Republican Guard (with only 179 casualties). After reading Boyd's story and Richards' book, the relevance to TOC and the thinking process popped out at me so vividly that I could not ignore it. I was already 3/4 through the draft of Strategic Navigation at that point, and I went back a rewrote much of it to incorporate the Boyd philosophy.

Third, Boyd was a "prophet without honor in his own land." He was an Air Force officer---and independent thinker---reviled by most of his Air Force colleagues...but embraced with a passion by the U.S. Marine Corps! In one of the strangest turns of fate, at Boyd's funeral, when he was interred in Arlington National Cemetery, there were only two Air Force officers present---one a major from the Pentagon who had known of Boyd only by reputation, the other a 3-star general who was the "designated Air Force representative" at the funeral. There were dozens of Marines and Army officers there, and a Marine Major General delivered a eulogy for an Air Force colonel---unheard of! What's more, the Marines have erected a life-size bronze statue of John Boyd in the entryway of their "Marine University" at their Quantico, Virginia, base where all warfare doctrine is taught. A statue of an Air Force officer in a hallowed Marine hall---heaven forfend! There had to be something special about Boyd for that to happen---and in truth, there was.

So, rather than try to send you diving back into MY words on Boyd, let me suggest that you enter the building on the ground floor. Go directly to the source first---Coram's book. Then read Richards' book. And, Clarke, if you're half as sharp as I think you are, you'll see an immediate, resonating connection between Boyd's philosophy and TOC...and especially with the thinking process and the OODA loop.

Q&A with Bill Dettmer - Q4 - The life of a TOC trainer / consultant

Some more questions with TOCthinker Bill Dettmer ...

Q4:  Thanks for answering the earlier questions Bill.  The generated a lot of interesting feedback.  I want to move away from the book now and ask you about your training courses.  To start with, can you tell me a little more about the people who come to the courses?  What do they hope to achieve?  Are they already converts to TOC?  What do you learn from giving the courses?

It's an interesting mix of people from private and public sectors. In my last course I had a strategic planner for a county in New Mexico, and an information technology project manager from a large German conglomerate. Most of those who contact me about training already have some familiarity with TOC. A few don't but they may have read my book Strategic Navigation and have come to awareness about the thinking process more from a need to develop strategy than because of any real familiarity with TOC and its tools.

I will say, however, that although I still teach courses in the TOC tools, over the past 5-6 years that's become a secondary part of my professional work. It took me about eight years (1993-2001) to realize that I didn't really subscribe to Goldratt's philosophy of "teaching to fish, rather than providing a fish." Yes, from a purely philosophical standpoint, it's much more noble to teach people to be self-sufficient. I know I personally like that better. I enjoy "seeing the lights come on," which is the one thing I found most gratifying about my graduate teaching for the University of Southern California.

But after eight years of frustration ("Why don't more people want to learn this great stuff? Why don't they use it more after they learn it?"), I've come to two conclusions about teaching fishing versus distributing fish. The first is that the large majority of people, especially those at more influential levels in the organization, don't want to learn how to fish for themselves. They're too busy to take the time for it---they just want the fish, and they want it now! If they want another fish at some later time, they'll call me back again. So, I've learned that you can lead a horse to water, but you can't make him drink. Unless you hold his head under and...never mind---let's not go there. :-)

The second thing I've learned is that you can't make much money selling training. The biggest training-only company in the U.S. grosses only about $20 million per year, and they run open seminars in all major cities several times a year. It's training on a mass-production scale, ultimately it probably doesn't result in much real impact, and it's not all that productive Throughput-wise. So my training is just an adjunct to my consulting. I find as much gratification in going into an organization and leading them through the process of building their strategies or solving complex system problems. They see the tools in action, but they don't learn much about them, except by "osmosis." After they've seen the results, maybe one in ten says, "I'd like to learn how to do that..."

Those are two major lessons I've learned from conducting courses. The third is more general. With each course I teach, I'm exposed to different people in different industries or life-situations. There are subtle differences in the way the thinking process is applied in each case. As I watch my students construct their trees, I learn a lot about "the outside world." In addition, because people absorb learning in different ways and at different rates, I find myself forced to come up with new ways of expressing the same learning points. That's good for me personally, because it deepens my understanding of the thinking process and systems in general.

Q&A with Bill Dettmer - Q3 - Where've the Transition Tree's gone?

Q3: I've always felt guilty for not using the Transition Tree. I tried a few times but it just didn't work for me. I'm relieved to see that you no longer recommend it. Can you tell me a bit your rationale for that?

The original concept of the Transition Tree was to "flesh out" the Prerequisite Tree. As Goldratt originally conceived it, the Prerequisite Tree's purpose was only to identify obstacle to implementation and determine ways to overcome them. But besides overcoming obstacles, there are many more activities that usually take place in most implementations. So Goldratt created the Transition Tree to add all that detail. The repeating-structure nature of the Transition Tree (reality, unfulfilled need, action, leading to new reality) made for some ponderously detailed trees. They also inevitably included detail required to satisfy logical requirements that was obvious to most implementers. Moreover, very few FRT injections requiring Prerequisite Trees involved completely new kinds of creative activities---things that had never been done before. In most cases, overcoming obstacles involved doing things that most professionals already knew how to do. They didn't need the "work-task instruction" detail---and the rationale for why they should do each step.

All this became clear to the students to whom I was teaching the thinking process. As I scrutinized their Prerequisite Trees, I found them including some of these necessary-condition task detail that had no particular obstacle associated with it. But to satisfy the format of the Prerequisite Tree, they were contriving "obstacles that weren't really obstacles" just so they could have an obstacle-IO pair for an activity that they intuitively knew needed to be done. And they were reluctant to replicate all that detail AGAIN in the Transition Tree.

So I bowed to the inevitable---or the practical. I started building (and teaching) Prerequisite Trees that had IOs with no associated obstacles, but there were many more total IOs this way. I concluded that if the "new" Prerequisite Tree included IOs to over come real obstacles, plus IOs that were crucial to successful implementation that did not have an obstacle associated with them, most people could execute the Injection directly from the Prerequisite Tree, without needing a Transition Tree at all. Because my students were almost exclusively professionals, they didn't need a Transition Tree to tell them how to do their jobs, or why. All they needed to know was what to do---and the Prerequisite Tree gave them all of that.

Moreover, there was an additional benefit to a "more robust" Prerequisite Tree. If it included ALL the key tasks and activities that needed to be done to implement an injection, the IOs in total represented all the tasks, in sequence, required to manage implementation as a project---in other words, the activity network that forms the basis for a project schedule. This makes the natural follow-on to a Prerequisite Tree NOT a Transition Tree, but a Critical Chain project network.

However, I should emphasize that the "more robust" Prerequisite Tree approach to project network-building is NOT intended for traditional complex technical project tools. It won't replace a Work Breakdown Structure in a construction or development project, for example. But for organizational change? That's another matter. Most organizational policy change---which is really the purpose of the thinking process in the first place---is not conceived by professional project managers, nor is it managed by people with project management experience. It's usually managed by non-project-oriented people with little or no exposure to Work Breakdown Structures, or any of the traditional project management tools. For such people---at whom the thinking process is primarily aimed--converting the "more robust" Prerequisite Tree into a Critical Chain project network, and managing the change as a project, can be an ideal approach.

Q&A with Bill Dettmer - Q2 - Why the new book?

Q2: Your new book arrived yesterday and since then I've only been able to spend a couple of hours reading through it. It looks good. Can you tell us why you decided to write it?

In 1996, when I wrote Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement, I intended to write the "how-to" for those interested in learning the logical thinking process. Though the first chapter laid the foundation in constraint theory (of which the thinking process was a part), the balance of the book described the "state of the art" in the thinking process at the time. But as with any such book, it could only be a "snapshot in time." The thinking process was not fully matured when I wrote GTOC. I used it as the primary text in my seminars and workshops on the thinking process. But over the next several years, I found that I was having to supplement the original material with newer, improved instructions and explanations in order to see better results from my seminar participants. By 2005, I had a fairly thick three-ring binder that I was distributing with the GTOC text. And I was telling students to disregard certain parts of GTOC and use the material in the binder instead.

In 2006, my publisher, Quality Press, asked me if I would be interested in updating GTOC to a second edition. I saw the opportunity to incorporate a lot of the three-ring binder into the original text, delete the material that I considered no longer relevant, and simplify the learning process. But as I became involved in the modification of the original, I realized that the manuscript was turning into a completely new book. It had substantial overlap with GTOC, but is was different enough that it warranted a change in the title and structure, rather than merely being labeled GTOC, second edition. My later thinking about the thinking process was also strongly influenced by my writing of Strategic Navigation in 2003.

Additionally, the passage of 11 years has afforded me the opportunity to replace outdated examples with newer ones and to improve the quality of the graphics. Ad added benefit (not a rationale for writing a new book in the first place) was the opportunity to include tree-drawing software with it. That wasn't possible when I wrote GTOC.

Q&A with Bill Dettmer - Q1 - who are you?

Q1: Your new book arrived in the post yesterday but before I ask you any questions about the new book could you tell me a little about yourself, in particular, your interest in Theory of Constraints?

I discovered constraint theory in 1992, while I was teaching in the Master of Science in Systems Management program at the University of Southern California. A colleague (fellow professor) had gone to the Goldratt Institute in New Haven, Connecticut, for the Jonah Program, back when it was mostly a DBR course. I was intrigued enough to read The Goal, and I subsequently decided that I would go to AGI for the Jonah Program, too. I was surprised to find when I arrived that the Jonah Program had been completely restructured. The DBR part was out, and the entire course was devoted to the thinking process.

Having come to the theory and tools from an already-established deep involvement in systems approach to management, I immediately recognized the potential of the theory and tools to enhance and support the systems management. So for me, constraint theory has not been the "terminal outcome"---it's been an integral part of a larger concept called "systems thinking." And it's one reason why most of my books have the subtitle "The Systems Approach to..."

Q&A with Bill Dettmer - author of "The Logical Thinking Process - A systems approach to complex problem solving"

Bill Dettmer has recently published The Logical Thinking Process - A systems approach to complex problem solving which is a significant update to his earlier text, "Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement" (GTOC).

 

I've learned a lot from Bill's books over the last decade so I'm delighted that he has agreed to answer a few questions here on the tocthinkers.com blog.  I'll post the first three questions shortly and more will follow.  If you got any questions you'd like to ask Bill then please send them on to me and I'll post them to the blog if they seem appropriate.

Bill Dettmer on the “3 Cloud Method”

Bill Dettmer is a hero of mine.  I learned much of my early TOC thinking from Bill's early books and I love him for sharing details of how to use the TOC thinking with mere mortals, too cheap to invest in the training like Bill did.

He is currently immersed deep down in the final stages of editing his latest book on the TOC Thinking Processes.  Bill described the new book as a "quantum leap forward in the thinking process".  I  truly can't wait. 

In order to help us kick start this blog, Bill has kindly shared one of the appendices from his book.  It is the controversial one where he states why he believes the 3-cloud method of constructing Current Reality trees is fundamentally flawed.  Funny thing is – a lot of very clever people agree with him; a lot of very clever people don't.  It reminds me of the dire straights song which goes "Two men say they're jesus, well one of them must be wrong".

APPENDIX E. THE 3-UDE CLOUD

At some point in your experience with the thinking process, some of you will undoubtedly encounter a way of attacking the problem-solving phase known as the 3-UDE Cloud, or sometimes as the Core Problem Cloud. Some of you reading this book may have elsewhere learned this as the preferred way of doing problem analysis. In both cases, it's worth exploring the differences between the 3-UDE Cloud method and the way described in this book—what I call the modified traditional approach. As the name implies, the traditional approach preceded the 3-UDE Cloud method by about six years.

 

The Basic Differences

The differences between the two approaches (traditional and 3-UDE Cloud) can be summarized this way:

 

Traditional

The traditional approach follows the scientific method: identify the problem, develop possible solutions, test the candidates, and select the best one. So, in applying the thinking process to the challenge of problem solving in complex systems, we start with the IO Map to determine the standards of required system performance, then prepare a Current Reality Tree to define the root causes of deviations in real-world performance, resolve any possible change dilemmas with an Evaporating Cloud, and finally move on to the Future Reality Tree to design and logically test the solution.

 

3-UDE Cloud

The 3-UDE Cloud approach assumes that all system problems are the result of an underlying core conflict. This method seeks to ferret out that conflict first (that is, without actually establishing the causal connections), then uses that conflict to construct a "core" or "communication" Current Reality Tree to show how this conflict leads to the observed systemic undesirable effects.

 

Why Are There Two Methods?

The astute observer might well ask, "Why are there two methods? Why isn't the traditional approach enough?" It would seem logical to assume that if something is working the way it was intended, it shouldn't need to be changed unless it's found to be deficient. In fact, W. Edwards Deming saved some of his most critical comments for those who tampered with a stable process without proper understanding of what they were doing and why. [2] So it would seem reasonable to ask what was wrong with the traditional approach that caused some people to move away from it.

    Since we'd prefer not to speculate or resort to hearsay, its reasonable to look for some kind of documented history. Unfortunately, not much is available in the public domain. It's limited to three sources, a paper in conference proceedings by Button [1], a book published later the same year by Lepore and Cohen [4], and a book by Scheinkopf [5]. We'll examine all three.

 

Why Replace the Traditional Approach?

Lepore and Cohen don't provide a rationale for jettisoning the traditional method, but Button does.

 

Experience with CRTs has uncovered two undesirable elements. One is that

the core problem often reflects poorly on management practices. When a CRT

is presented to those responsible for the core problem, this tends to immediately

activate their defense mechanism. Further productive dialogue may be very difficult.

 

The other is that in my experience, a CRT that is well constructed can take from

5 to 10 hours to develop. Few individuals have the stamina to undertake this effort

on a regular basis. [1:31]

 

    If I interpret this line of reasoning correctly, Button finds two faults with traditional CRTs. The first is that management is frequently too insecure to "swallow the medicine" (that is, bad news that may be their responsibility). The second is that traditional CRTs are "too tough to do" in most people's attention span. In other words, it might actually take up to 10 hours to identify a particularly challenging problem, and complex problems with profound system-level impact should be definable in much less time.

 

Core Problems and Core Conflicts

Both Button and Lepore and Cohen explain the 3-UDE approach in some detail, though there are some minor procedural differences between the two. (Scheinkopf addresses "communication" Current Reality Trees, but doesn't mention the 3-UDE Cloud idea.) Button's explanation is also more pedagogical while Lepore's and Cohen's is more conceptual. Lepore and Cohen begin with the introduction of something called the core problem cloud. The presumption in their discussion of the CRT [4:124] is that a core problem cloud can be used to explain the existence of the UDEs in a CRT:

 

One of the popular ways to construct a CRT is to base it on the Core CRT that

is using the core problem cloud. [4:124]

 

    Now we have two apparently different terms: CRT and core CRT. Unfortunately, Lepore and Cohen don't make clear the distinction between the two. They do, however, address the concept of a core problem cloud in some detail. [4:122-124]. According to Lepore and Cohen:

 

The core problem cloud describes the conflict that prevents us from finding a solution

to the core problem. There are three major types of core problem clouds:

 

1. Conflict with the "rules" of the system

2. Personal dilemma of the leader

3. Conflict between functions, management levels, or individuals (chronic conflict)

 

    There are a couple of unstated assumptions that require examination, and an interesting implication of Lepore's and Cohen's perspective on systems that follows from it. The first assumption, which I have personally heard Goldratt express, is that conflict underlies all core problems. And the second is that a large majority of a system's undesirable effects (Goldratt has said 70 percent or more) are accounted for by this core problem. The implication for Lepore's and Cohen's system perspective is that all possible conflicts perpetuating core problems are reducible to one of these three categories: rules, personal leadership dilemmas, or functional/management/personal conflict. In other words, no allowance is made for core problems resulting from incomplete knowledge (ignorance of causal connections), insufficient resources, or factors external to the system itself.

    The second is even more interesting: that a large majority of a system's undesirable effects result from a core problem. This idea is somewhat easier to accept when we consider that since its inception (and until this second edition), an undesirable effect has been imprecisely defined as just about anything that's happening in your system that you or others don't like. Because that opens the door to virtually everything, it's easy to see how a single core problem might cause a large percentage of UDEs, maybe even a large majority. Lepore and Cohen confirm this:

 

These UDEs cover a fairly large span; they originate from different sources

and have different "weights." [4:124]

 

    This represents an important and fundamental difference between the modified traditional approach to the thinking process described in this book and the core problem cloud method. The latter suggests that not all UDEs are created equal, and that there are a lot of them in any system. The modified traditional method described in this book suggests that there are relatively few real UDEs in a system, and they are clearly identifiable with respect to the system's goal and critical success factors—of which there are probably no more than three to five. And because each of these critical success factors is, by definition, a necessary condition to attaining the system goal, the absence of any one compromises goal attainment. This makes the few real UDEs any system might experience relatively equal in weight, and not a matter of one person's opinion versus another's.

    So, to summarize briefly, the 3-UDE Cloud method, or core problem cloud (as Lepore and Cohen refer to it), is based on the following assumptions:

 

• UDEs are subjectively determined
• Most system UDEs result from a single core problem
• Conflict underlies all core problems
• Core-problem conflicts fall into only three archetypes (Boy, that sure makes complex problem identification easy!)

 

    On the other hand, the modified traditional approach to the thinking process is based on the following assumptions:

 

• All UDEs are objectively defined with respect to non-negotiable system-critical success factors (refer to Chapter 3)
• There are relatively few real UDEs in any system
• All UDEs result from a few critical root causes (true core problems are relatively rare)
• Critical root causes are not limited to a few common archetypes ("generic")

 

Basics of the 3-UDE/Core Problem Cloud

The 3-UDE, or Core Problem, Cloud works essentially like this. First, you identify an UDE pertaining to the system. (Remember, almost anything you don't like can qualify as an UDE.) Then you determine its opposite condition—a corresponding desired effect. Repeat this process two more times, so that you have three UDEs and matching opposite desired effects. These pairs become the conflicting prerequisites in three different Evaporating Clouds. [1, 4]

    To construct the rest of the cloud, the usual right-to-left procedure is employed (refer to Chapter 5). In each case, however, the requirements and objective are established by determining the direct and immediate reason for existence—what outcome each conflicting prerequisite (the UDE and the desired effect) is aimed at achieving. The overall objective is then determined as some overarching condition that both requirements are intended to satisfy.

    Clearly, the product of this part of the process is three discrete Evaporating Clouds, the only common thread of which may be that they are inherently part of the same larger system. These three clouds are then consolidated into a single "generic" cloud.^* [7]

    The process of consolidation, as described both by Button and by Lepore and Cohen, is purely inductive in that it attempts to reach a "general rule" conclusion from three component elements. And therein lies one of the logical fallacies with the 3-UDE/Core Problem Cloud method.

 

Inductive Reasoning

Why is a conclusion arrived at inductively not logically sound? The answer lies in the nature of inductive reasoning itself.

Induction or inductive reasoning, sometimes called inductive logic, is the process of reasoning in which the premises of an argument are believed to support the conclusion but do not ensure it. It's used to ascribe properties or relations to broader types based on tokens (that is, on one or a small number of observations or experiences), or to formulate laws based on limited observations of recurring phenomenal patterns. [3] Basically, it induces the universal from the particular. However, the conclusion is far from certain.

What, then, is the process of "genericizing" three discrete clouds into a single consolidated one, inducing a universal conclusion from particular details? It's inductive reasoning. And why is this a problem? The answer is that conclusions drawn in this manner are usually over-generalizations. Consider, for example:

 

I always hang pictures on nails; therefore, all pictures hang from nails.

                or:

Teenagers are given many speeding tickets; therefore, all teenagers speed. [3]

 

As mentioned earlier, Lepore and Cohen don't offer any specific examples, only conceptual directions. But Button does. Here's an example of generic cloud elements (in this case, the conflicting prerequisites) induced from particular, specific ones [1]:

 

Specific cloud #1 = Don't work overtime vs. Work overtime

Specific cloud #2 = Buy a component vs. Make a component

Specific cloud #3 = Build only on demand vs. Build to stock

Generic cloud = Take action for good department performance vs. Take action for good system performance

It's not obvious how any of these components produces its respective conclusion, and in some cases an argument could be made that the conclusion could actually require an opposite component. (for example, taking action for the good of a department might actually require working overtime.) Without beating this particular example to death, the other "UDE Cloud" elements constitute equally weak inductions. [3]

 

The Fundamental Problem with Inductive Reasoning

Formal logic, as most people learn it, is deductive rather than inductive. Some philosophers claim to have created systems of inductive logic, but it's a matter of some controversy whether a logic of induction is even possible. Karl Popper adamantly maintains that it is not. [6]

    In contrast to deductive reasoning, conclusions arrived at by inductive reasoning do not necessarily have the same degree of certainty as the initial premises. For example, a conclusion that all swans are white is false, but may have been thought true in Europe until the settlement of Australia. Inductive arguments are never binding, but they may be cogent (let's not even go into cogency!).

    Inductive reasoning is deductively invalid. (An argument in formal logic is valid if, and only if, it's not possible for the premises of the argument to be true while the conclusion is false.) In induction, there are always many conclusions that can reasonably be related to certain premises. Inductions are open; deductions are closed. Here's an example (somewhat ludicrous, perhaps, but the extreme case clearly demonstrates the potential invalidity of inductive reasoning):

 

A group of men regularly took birth control pills for three years.

None of the men got pregnant.

Therefore, birth control pills are effective at keeping men from getting pregnant. [6:38]

 

    What's the problem with this, logically speaking? It's the proposed conclusion (the "therefore" part)—it's not valid. Because this is not a deductive statement, the conclusion a) doesn't have the same degree of certainty as the two initial premises, and b) it is only one of several possible conclusions that may be drawn. By accident or by design, the risk is higher of drawing an erroneous conclusion with inductive reasoning.

    It is possible, however, to derive a true statement using inductive reasoning if you already know the conclusion. (This has implications for what is typically done with the generic cloud later.)

    The only way to have an efficient argument by induction is if the known conclusion is true only when an unstated external conclusion (in thinking-process parlance, an additional predicted effect) is also true. That external conclusion has certain criteria to be met in order to be true (separate from the primary conclusion). By substitution of one conclusion for the other, you can inductively find out what evidence you need in order for your induction to be true.

    For example, let's say you have a window that opens only one way, but not the other. Assuming that you know that the only way for that to happen is that the hinges are faulty, inductively you can postulate that the only way for that condition to change would be to fix the window (that is, apply oil, or whatever will fix the unstated conclusion). From there on you can successfully build your case.     However, if your unstated conclusion is false (which can only be proven by deductive reasoning!), then your whole argument by induction collapses. Thus, ultimately, pure inductive reasoning does not exist. [3]

 

Transitioning to the CRT

Setting aside for a moment the argument about whether the inductive (generic) cloud is a valid one or not, let's move ahead to what practitioners of the 3-UDE/Core Problem Cloud do with it.

    Since one of the underlying assumptions behind the 3-UDE/Core Problem Cloud is that a core conflict underlies all UDEs—in other words, the idea that an ultimate root cause of an UDE might not have a conflict associated with it is excluded—a conflict of some kind, no matter how logically supportable, must be incorporated somewhere in the bottom of the CRT.

    The procedure described by both Lepore/Cohen and Button calls for the generic evaporating cloud elements to be rotate 90 degrees counterclockwise, placing the objective of the cloud at the bottom and the conflicting prerequisites at the top. The arrows are then reversed, the wording is modified to support an "if-then" (sufficiency) verbalization, and additional entities (assumptions) are incorporated with ellipses to translate the former generic cloud into the bottom portion of a CRT.^*

    Additional layers of cause-and-effect are then extrapolated upward from there until broader system-level UDEs are reached. (Remember, though, that consistent with one of the assumptions underlying the3-UDE Cloud method, UDE determination is highly subjective.) [1, 4]

 

Bottom-Up Versus Top-Down

    There's another difference between the traditional CRT approach and the 3-UDE/Core Problem Cloud methods. In the traditional method, the CRT is constructed from the top down, like peeling the layers of an onion. Each lower layer of causality is hypothesized and then checked for validity using the Categories of Legitimate Reservation. This is inherently a deductive process, which is able to establish validity.

    The 3-UDE/Core Problem Cloud method, on the other hand, builds upward from the presumed core conflict to the undesirable effects. In other words, it starts from a presumed (not validated by deductive logic) cause to a preconceived conclusion. Now, think back to the preceding discussion on inductive reasoning [3]: Inductions are open; deductions are closed. It is, however, possible to derive a true statement using inductive reasoning if you already know the conclusion...The only way to have an efficient argument by induction is if the known conclusion is true only when an unstated external conclusion is also true...By substitution of one conclusion for the other, you can inductively find out what evidence you need in order for your induction to be true.

    There's another way to express this: When you start from a point you arbitrarily determine, build toward a predetermined destination, and know what supporting evidence you need to get there, it's almost amazing how often the cause-and-effect will turn out to be exactly what's needed to reach that destination.

    What's more, building upward deliberately excludes the search for additional causes (the fourth of the Categories of Legitimate Reservation)—a pitfall of inductive logic that's avoided with deductive logic.

 

Why the Change? (Redux)

A substantial percentage of thinking-process users have switched away from a method that is deductive and sound and that separates the resolution of conflict from the logically supportable determination of cause and effect. They've gone instead to a method that muddles the line between problem definition and conflict resolution, that doesn't offer the same degree of logical certainty, and that can't be evaluated for soundness. Why would anyone deliberately choose to do this?

    I believe the answer lies in the rationale offered by Button—concern for defensiveness on the part of those in authority and ease of CRT construction.

    At about the time the 3-UDE Cloud made its appearance, Goldratt was much involved with the idea of resistance to change. Some thinking-process practitioners observed seemingly irrational behavior by decision makers: in the face of persuasive CRT logic, they denied or ignored the analysis of the identified core problem. Recognizing that presenting the logic in palatable way wasn't the same as constructing it, Goldratt conceived of the idea of a "communication" Current Reality Tree.^* In her book, Thinking for a Change, Scheinkopf devotes a whole chapter to the idea.

 

What if the party to whom you need to communicate the content of the current reality

tree is someone who is, or thinks he is, directly responsible for the environment described

in the current reality tree? How do you go about communicating the issues to him with-

out putting him on the defensive?...The communication current reality tree (CCRT) com-

bines the evaporating cloud with the current reality tree in a way that avoids the defensive

response. [5:235]

 

    In other words, the CCRT is a way of avoiding a negative reaction to "bad news" by a decision maker. But a little farther on, Scheinkopf provides an equally important but conveniently overlooked prescription:

 

When you begin to create the communication current reality tree, you have already

completed a current reality tree and evaporating cloud. (Emphasis added) [5:235]

 

    This distinction is important, and it's relevant to what apparently happened later. It implies that the use of a CCRT for persuasion does not relieve one of the responsibility to conclude a thorough, deductively logical analysis first by the traditional approach: a CRT followed by an Evaporating Cloud. The use of the CCRT comes afterward, only when the traditional analysis is complete, and only for the purpose of making that analysis persuasive and non-threatening. In a video tape in 1995 (no longer widely available), Goldratt himself confirms this line of thinking.

    So the second half of the 3-UDE/Core Problem Cloud method has a firm basis in rationality. As originally conceived, it applied the only aspect of inductive logic that is admitted to be valid: It is, however, possible to derive a true statement using inductive reasoning if you already know the conclusion...[3]  The CCRT, as originally conceived, does this, that is, operates from an already known conclusion. The traditional CRT and Evaporating Cloud on which it should be based were developed using sound deductive logic; thus, the conclusion is known in advance. And this is not only okay, it's required for efficient inductive reasoning!

    The disconnect came later, when someone decided that the traditional CRT and Evaporating Cloud could be dispensed with. Instead the process could be "short-cut" by inducing a generic cloud from three discrete ones. Then using that generic cloud as the basis for a CCRT would be a good idea. In other words, they eliminated the only thing that made the bottom-to-top logical construction of the CCRT a logically robust process!

    From our earlier examination, we know that the 3-UDE Cloud part of this process is fatally flawed because it depends on inductive reasoning for the analysis in the first place, rather than having the induction follow from a verified, validated deductive analysis. Button's second observation above (takes too long and too much effort) provides a clue to why this "shortcut" was adopted. Why would someone seek a shortcut in the first place? Two possible reasons:

 

• They aren't adept enough at constructing the deductive logic of the CRT to do it any faster. This could be a deficiency in either teaching or just intellectual laziness.

 

• The traditional method wasn't complete or logically "tight" enough to be easily translatable to the real world by most people—in other words, a deficient method.

 

    The latter difficulty is an acknowledged problem with the original method of constructing a CRT initially taught by the A.Y. Goldratt Institute. I encountered the problem with clients of my own repeatedly over the first six years of applying the thinking process. The CRT was difficult to construct well and expeditiously. But that isn't the case anymore. Readers of this book know that Chapters 3 and 4 explain in detail how to construct a sound, logical CRT by starting with an Intermediate Objective Map first. CRTs may have taken up to 10 hours when Button and others first learned them. There's no reason that most of them should take longer than about four hours now.

    Unfortunately, rather than refining and perfecting the traditional method of CRT construction, people looked for an easy way out. And a general deterioration in the quality of CRTs and problem analyses has resulted. Yes, there are those who would say that they have been successful using the 3-UDE/Core Problem Cloud approach. I don't deny this. Rather I would observe that even a blind pig finds an acorn once in a while. Even with a faulty method, some level of success can be expected, though it may not be consistent or always optimal.

 

Predetermined Causes to Preconceived Problems

How many times have you heard the expression, "When your only tool is a hammer, all problems tend to look like nails"? This is an indication of an insidious trap that many people fall into. Whether your "hammer" is the Theory of Constraints, Six Sigma, Lean, or any number of other worthy methodologies, if you have an emotional or intellectual commitment to it, there is a real risk of partitioning and arranging reality to fit the tool. This is especially true when one assumes that most underlying problems fall into a limited number (say, three) archetypes. [4:122] How easy it becomes to say, "The reason must be this, because it fits our model so nicely!"

    Because there is so much "semantic maneuvering room" in the inductive process of 3-UDE/Core Problem Cloud, it's so easy to make the presumed problem fit the details of the situation. And with no provision (or even thought) to validate the induction with deductive verification, the induced conclusion becomes the problem, in spite of the known deficiencies inherent in inductive reasoning. Why bother with a deductive thinking process when you already know what the problem is?

    The insidious part of the thinking process is that it can be used to justify the existence of a preconceived cause—if (and only if) the Categories of Legitimate Reservation are not conscientiously applied. All of them, including additional cause. The reason the CLR safeguard against subversion of the thinking process is that they are part of a deductive reasoning routine, not inductive.

    Yet in spite of the fallacies of inductive reasoning, the kind of "communication" current reality tree described by Scheinkopf [5:235] makes perfect sense—for presentation and persuasion, but not for logical analysis. Thus, as Scheinkopf recommends, the traditional (deductive) CRT should be the basis for—and the only logical justification for—the inductive "communication" CRT. And the 3-UDE/Core Problem Cloud does no more than exacerbate the inductions in a "communication" CRT.

 

Summary and Conclusion

As Lepore and Cohen said, the 3-UDE/Core Problem Cloud is one of the popular ways of constructing a CRT. The other one is the traditional method, as originally conceived by Goldratt and modified in this book.

 

The traditional method:

• Starts with a few objectively determined system-level UDEs
• Is deductive, and therefore its validity is logically verified
• Terminates in a few actionable critical root causes not confined to a few arbitrary archetypes
• Accommodates whatever valid additional causes might occur

 

The 3-UDE/Core Problem Cloud method:

• Starts with three subjectively chosen random data points (perceived localized UDEs)
• Uses inductive reasoning (less certain, not binding) to generalize (really, speculate—unlike in a traditional CRT, no attempt is made at verification using the CLR) five elements of an Evaporating Cloud
• Uses the inductively developed cloud as a starting point for a cause-effect journey to a predetermined conclusion (subjective system-level UDEs)
• Ignores potential valid additional causes

 

Of course, you're free to use whichever method you choose. Which one would you choose?

 

 

ENDNOTES:

1. Button, Scott. "Genesis of a Communication Current Reality Tree: The Three-Cloud Process," 1999 Constraints Management Symposium Proceedings, APICS, March 22-23, 1999.

2. http://www.qualityamerica.com/knowledgecente/articles/CQEIVH3f.html

3. http://en.wikipedia.org/wiki/Inductive_reasoning

4. Lepore, Domenico, and Oded Cohen. Deming and Goldratt: The Theory of Constraints and the System of Profound Knowledge. Great Barrington, MA: The North River Press, 1999.

5. Scheinkopf, Lisa. Thinking for a Change: Putting the TOC Thinking Processes to Work. Boca Raton, FL: St. Lucie Press, 1999.

6. Stokes, Geoff. Popper: Philosophy, Politics and Scientific Method. Malden, MA: Blackwell Publishers, 1998.

7. Thesaurus.com.: "generic." Roget's New Millennium? Thesaurus, First Edition (v 1.3.1), Lexico Publishing Group, LLC. (http://thesaurus.reference.com/browse/generic) Accessed: November 05, 2006).