The following is a transcript of a presentation given by Dale Houle, General Partner of the Avraham Y. Goldratt Institute, at the Jonah^SM Upgrade Workshop/TOC Symposium in May 1998 in London, UK. It is available on video (JUK-4).

Introduction to the Theory of Constraints

What I'm going to try to do in the next 15 or 20 minutes is give you basically an introduction, and hopefully a fairly extensive yet high level overview of the Theory of Constraints.

First of all, let me start with "What is the Theory of Constraints?"

How many of you have read any of the books? The Goal, It's Not Luck, Critical Chain? So most of you are somewhat familiar.

Theory of Constraints is basically comprised of two components. One is the Thinking Processes themselves, and I'll explain those a little bit further. The second is the applications that have been derived from applying those applications to various areas in an organization, whether it be in production, project management, distribution, marketing.

Let me start first with the Thinking Processes themselves.

In many ways the Thinking Processes are not something that's very new. How many of you have in recent times seen little children, whether they're your own, grandchildren, or... How do they really learn? Okay, because when they're starting they don't have a whole wealth of experience and knowledge. What's the basic process they employ when they're learning? Asking questions. Checking whether "if I do this, that will happen. If I cry, I'll get fed." Things like that.

So basically they learn how and what's going on through cause and effect and many times through better understanding or developing and understanding of what's necessary. Then many times they start challenging that as well, right?

So, when you look at what underlies the Thinking Processes it's these two basic elements: One is causality, which is basically a very simple sentence used in many different ways. It's "if...then..."

The second is dealing more in the arena with necessity, which is basically "in order to have whatever it is, then I must do something or I must get something."

These are the two basic building blocks. So, in this sense, it's not something we're not familiar with. You may find as we go more into it, it's something we don't use quite as rigorously as we could, but it's certainly not something we're not familiar with.

Just to give us a couple of very simple, trivial examples. If we talk about causality, it might be as simple as "if I touch a hot stove, then I get burned." That's our understanding of reality. And if we want to change it, then we may look at some of the assumptions and alter the situation that says, for example, now "if I touch a hot stove and I'm wearing a pot mitt, then I don't get burned."

Instead of one reality, we have what we've put into place that alters that reality. This is utilizing this cause and effect.

Had we expressed it more in the realm of necessity, it might appear that "in order to avoid getting burned, I must not touch the stove." Why? "Because touching a hot stove might burn me."

So once again it provokes us in this way. If we want to alter the situation then we find ways to touch the stove without being burned. Okay? This is the basics of the Thinking Processes themselves.

If you put them together, there are two other components that start to help us in developing an understanding of what's going on in our environment, what's going on in our situation.

And you see these as trying to just represent the basic building blocks. So, if we go into the causality then basically what we find are things like "if A then B." That's the effect. If we'd like to clarify more of the connections between A and B then we'd just look at it in terms of "if A then B because." This will help surface some other assumptions that exist, and sometimes clarify the intermediate causalities, or the intermediate effects, thereby allowing us to better understand what's going on.

On the other side, you may see some things depicted here in necessity that says for example, "in order to have A, we must have B." And again, to clarify the basis of it we will say "in order to have A, we must have B, because..." And this helps us once again to surface our understanding of what underlies why that's necessary. Okay so far?

And sometimes you'll see the diagrams horizontally, and sometimes you'll see them expressed vertically; but it's the same basic structure. (Referring to overheads.)

How can all of this really start to help us in the things that we are trying to do? How many of your organizations are on a process of ongoing improvement? Or are deciding to go on a process of ongoing improvement? Or you think should be on a process of ongoing improvement? Yes? Okay.

If we really start to move into a process of ongoing improvement, it means whenever we talk about improvement, right, it says we're going to do it better than we were doing it before. True? Better means differently. Differently means change from what we were previously doing. Yes? So every time we talk about improvement, at the same time we are basically talking about change. Just like every time we talk about change, we're talking about improvement. No, right? It goes one way but it doesn't necessarily go the other way. Improvement means change. Change does not always mean improvement.

So if we want to be on a process, we want to be able to do more of it, better, faster, then there are probably some very basic questions we have to be able to answer.

First of all, probably the first question is "What are we really going to change?"

Once we have a pretty good answer to that question, the next thing is "ok, good, now what are we going to change to?"

Not any less important is "how do we cause the change to happen?" Which means, what you see is at least here in terms of Theory of Constraints it starts to translate into some more specific objectives, like, for example, "if we're really talking about change, change means we want to resolve a certain set of problems, so we would like to be able to focus more on what really underlies those problems.

We'll call it "Identifying the Core Conflict." That conflict that underlies so many of the problems we want to eliminate. How can we identify that?

Next would be, "let's construct a complete solution." Make sure it really delivers everything we'd like, and then lastly, "how do we devise an implementation plan, action plan, that will enable us to effectively bring that change about."

What you'll probably see throughout some of the different presentations as Oded was saying is the use of different tools; tools to help in addressing those questions.

In terms of the first question of "what to change," you may see some people's presentations containing something called the Generic Cloud Process. There certainly will probably be some of them having Current Reality Trees, which is simply taking the logical structures we've touched on earlier and putting them into a more comprehensive picture, thus describing the current reality.

When we'll move into the second question of "what to change to," there are tools here that can help us find breakthroughs called Evaporating Clouds; Future Reality Trees, which can help us make sure we're going to really get what we want from the change before we initiate it.

Negative Branch Reservations. How many times when you put change in your organization do people have concerns about it? Ever? How can we more effectively deal with those concerns and use them in a more positive way? As opposed to becoming more resistant.

Lastly, "how do we cause the change?" You'll see elements here called Prerequisite Trees, Transition Trees that enable us to utilize things like the obstacles that stand in our way as a vehicle for really devising a proper implementation plan. And, lastly, things that deal with the whole arena of "how do we more effectively deal with buy-in."

So these are the major components under these three questions.

Now, if I take the same components and look back to the two basic structures that we've talked about, causality and necessity, this is where these tools fall.

Current Reality Trees, Future Reality Trees, Negative Branch Reservations, Transition Trees are all making use of causalities. In order to understand what is going on and in order to determine what we really want to have going on.

In the context of the necessity, you'll find things like the Generic Cloud Process, the Evaporating Cloud, the Prerequisite Tree is simply the utilization of those processes to address more specific questions.

And if you put it all together, you end up with something that looks like that (looking at overhead slide). Okay? Which is basically saying, "how will these structures appear?"

So if we're talking about in the first question of "what to change?," we might find that the definition of an underlying conflict will appear something like this, where it's clear what the objective is, what are the real necessary conditions, and where is exactly the conflict, so we can address it more effectively.

If you look at current reality, what we are claiming is the problems, ahhh, you see another three-letter word -- UDE (referring to overhead). Okay, it's UnDesirable Effect. Another name for problem. Okay? Do they all really stem from this core conflict. So that we can be sure that when we solve that problem it will give us good access to solving all of the other problems.

If you move into the second question of "what to change to?," sometimes we have a good understanding of the problem, but we don't see just how to solve it. We don't have a good idea yet of how do we really break out of this conflict and provide for ourselves a solution.

So what you see is the same cloud that was used here is also used here, except now this process of surfacing assumptions that underlie the conflict is what's used to help us, to provoke us to come up with ideas of how we can really break out of this box.

As you know, an idea is not a solution. Right? An idea is just an idea. First of all we have to have the idea. Secondly, let's then before we run to implement it, let's make sure with our understanding of reality that it will allow us to really solve the problem. This is called the Future Reality Tree. Let's do the logic of it before we build it in reality.

By the way, how many of you have ever built Future Reality Trees that are here just for the symposium? Anybody?

I think all of us have done it. We may not have sat down and done it on paper, but how many of you have launched new ideas into your organizations? That's building Future Reality Trees. The only difference is it's not on paper, it's built in the organization. So we do have experience with this.

Then we get into the last questions of "how to cause the change," the other tools that help us are Prerequisite Trees, Transition Trees that allow us to more clearly define our action plan, implementation plan.

Again, two very sample structures ­ causality and necessity ­ how do we utilize those structures to help us get better answers to questions like "what do we really need to change?," "what are we really going to change to?," and "how can we be more effective in causing that change?"

If you take all of that, and then you apply it to organizations, the main component that comes out is that we should acknowledge and we should manage better the interdependencies that exist. Interdependencies that exist within our organizations, whether it's between functions, departments, various resources, as well as those that exist between our organization and other organizations like our suppliers, vendors, customers, etc. And how do those interdependencies effect our ability to really move the flow through our organization? Once we look at it and recognize interdependencies, we might find a different view that we take when we look at our organization.

We can look at it probably one of two ways, maybe some others. One is it's an assemblage of various resources, capabilities and so forth. True? The other is if we acknowledge and deal with the linkages that exist between this assemblage of resources then basically it starts to look more like a chain as opposed to an assemblage of linkages. True? Some of you have heard things that say about things like cost world, throughput world perhaps versus if we look at our links, what are we really concentrating on in most cases? All the links in our chain, do they cost our organization money? We have to pay wages, salaries, fringe benefits, and so forth? So it's more focusing on one aspect. If you look at the linkages together with the links, then basically what we're looking at is what effects how much we can really move through that chain. True? Now all of you know in a chain, how many weakest links exist? One. Okay, so if we really want to improve the strength of the chain we should concentrate our efforts where? On the weakest link.

Now, when we look at our organizations and the flow, well the weakest link might reside in our vendors or suppliers. It might reside in the market in terms of we don't have enough demand for what we're able to do. It might reside internally in terms of we do have demand, but we're unable to do it on time or our lead-time is too long, or our projects are too late, or some things like that; which means the constraint may be in any one of those areas.

So, when we really look at affecting more the flow, sometimes the question is how do we create a bigger pull from our market ­ which means increase demand?

Sometimes the question is "how do we get our suppliers to provide us more of what we need?" Sometimes the question is "how do we produce the orders we have right now, on time?"

And what you'll find is constraints start to break down, that some of them you can classify more as organizational constraints, related to policies, measurements, behaviors, sometimes the structure of the organization itself. That's what's constraining us from putting more through that chain.

How can we start to better address what needs to be changed, what should we change to, how do we cause the change? Here it's probably most effectively addressed with the Thinking Processes.

If you talk about market constraints, where we don't have enough demand, then there is something that exists today­ it's called the Implementable Unrefusable Offer. How do we make our markets, our customers offers they basically cannot refuse? And as a result, they increase the demand on our organization for what we have to offer.

If you look at constraints that exist within suppliers, then sometimes it means we have to take a similar approach. As we also have to think about "how can we make our suppliers an offer they cannot refuse, so they will give us the materials, resources, whatever it is that we need which we cannot get?

If it's in the area of sales, which means we have an offer, but, we are not able to effectively sell it, what you'll see here is something called the Six Phases of Buy-In that can help us, along with the Thinking Processes to effectively elevate or address that particular constraint.

In Distribution there is already an application derived from these processes. It's basically a concept of replenishment as opposed to pushing our products into the market.

In Production, if you've read The Goal, it's called Drum-Buffer-Rope.

In Projects, whether they be single-projects or multi-project environments, there is a solution. It's called Critical Chain in this type of approach.

So you'll see from the various presentations, different aspects, different applications, what they've done, how they've worked.

That I hope gives you a framework in order to put what you're going to see, experience, discuss in the next two days. Okay? Thank you.