Theory of Constraints Production Alignment

A Guide to Implementing the Theory of Constraints (TOC)
PowerPoints	Preface	Introduction	Site Map	Contents	Next Step

Good Intentions Are Not Enough

“It is said that the way to hell is paved with good intentions. Good intentions are not enough to solve the problems that arise among people (1).”

Takashi Kawase a very successful and respected kaizen/JIT academic and consultant knows only too well when he says that good intentions are not enough to solve the problems that arise among people. In this section we will limit ourselves to some Theory of Constraint specific techniques that might help, in addition to good intentions, to align people within a manufacturing implementation.

Let’s break this down into two parts. The first dealing with the issues – conflicts – that arise out of detail complexity and how to reframe these in a way that they can be solved. In the second part we will deal with the issues – conflicts – that arise out of dynamic complexity and how they too can be solved.

Detail Complexity Issues

Let’s return to our departmentalized version of our system for a moment. The version that we previously drew for the section on people.

In this example there is a conflict between foreman A and foreman B. Let’s say for instance that foreman A want to speed the rate of work up in his department by reducing the tolerance on his parts. Forman B doesn’t want this because the larger tolerance will, he feels, cause his department to experience quality problems.

We can write this conflict as a “cloud”. A cloud is a very useful graphical mechanism for breaking conflicts. A detailed description of clouds is given in the thinking process section. However we will use it here in advance.

Let’ draw a cloud for this particular problem.

Let’s work through what we have done. The common objective here is to have a successful outcome (don’t worry if this sounds rather broad). Reading the top side of the cloud we can say that; in order to have successful outcome foreman A must get more output, and in order for foreman A to get more output he must reduce tolerances. Reading the lower side of the cloud we can say that; in order to have a successful outcome foreman B must get good quality, and in order for foreman B to get good quality he must maintain tolerances. Clearly reducing tolerances and maintaining tolerances are in conflict with one another.

The power of the cloud comes from the belief that there are no conflicts in nature – only erroneous assumptions (2). The assumptions “hide” under each of the arrows in the diagram.

Let’s draw some of them in.

Of course there will be assumptions under all arrows but we have limited ourselves in this example to the two arrows most likely to give rise to the conflict. We need to identify any assumptions which are erroneous, we will out a red cross through them, and also any which are valid but could be overcome by an injection – a new idea.

Let’s do that.

In this example, for instance, the injection might be an idea for increasing output without reducing tolerances. Certainly TQM/kaizen has taught us that the old trade-off analogy between output and quality doesn’t exist, so we shouldn’t be too surprised about this.

This is how our diagram now looks.

We broke a detail complexity conflict by addressing the hidden and erroneous assumptions. However, there is another way that we could approach this problem and that is by re-framing it in terms of the perspective at the next layer of management up from the layer at which the conflict exists. Let’s do that.

Reframing The Argument

Consider the situation now where foreman A and foreman B are both a part of the same supervisor’s area.

We can reframe the conflict from A versus B to; A versus the supervisor’s view and B versus the supervisor’s view.

Let’s draw that.

It is very likely that one of the sides of the argument, in this case B, is so similar to that of the higher level that it can be dismissed. That only leaves as before the conflict between A and the supervisor. Again we should try to break it by identifying erroneous assumptions or new injections that overcome and existing assumption. Let’s draw that.

It is possible that the final outcome may not be so different. However, by reframing detail complexity issues in terms of the next layer of responsibility it may mean that more intractable problems are resolved sooner.

Dynamic Complexity Issues

Dynamic complexity issues must be framed in terms of the whole system if they are to be satisfactorily resolved. And in our reality there is likely to be an internal constraint or at least an internal control point to consider. Let’s draw that.

In this example, let us suppose that there is an apparent conflict between foreman A and foreman B. The problem is whether to move people from area A to area B or not. A common problem? Absolutely.

Let’s suppose the conflict is something like this.

I think that you can guess that we should examine all the assumptions under the arrow between the foreman’s need and the foreman’s want. This is just an example, but it can’t be resolved by looking at area A and area B in isolation. It can only be resolved by knowing what is best for the system at that time. Perhaps better subordination would remove the need for B to request more personnel.

Lieutenant’s Cloud

The lieutenant’s cloud addresses the case were we want to do things that are necessary for the success system but we are unable (3). This arises because the people concerned have the responsibility for success but do not have the authority to carry out the needed action. Cohen also calls this a misalignment cloud or a firefighting cloud.

The construction and use of the lieutenant’s cloud is sufficiently important that it is addressed on a separate page. Please learn how to construct and use the lieutenants’ cloud and internalize the process.

Effective Subordination Is The Key To Successful TOC/DBR Implementation!

Think about it for a moment; we already recognize and understand the focusing steps “identify,” “elevate,” and “exploit.” We know them well from the world of local efficiency and product costing – the world of the reductionist/local optima viewpoint. But “subordination” is different. The concept of subordination doesn’t exist in the reductionist/local optima world; it only exists in the world of the systemic/global optimum viewpoint. We especially examined this concept in a number of different places in the page on process of change and again in the page on implementation details.

Effective subordination can be divided into two;

(1) Doing things that are necessary for the systems success.

(2) Not doing things that are not necessary for the systems success.

Subordination isn’t so much a problem of failing to do new things that are necessary, because this requires some sort of positive action. Subordination is more a problem of failing not to do things that are no longer necessary – especially no longer doing old things, things we have always done; because this doesn’t seem like a positive action any longer. Not doing old things, things that were so common in the past that they have become automatic, is a major cause of misalignment in TOC implementations.

Some Subordination Clouds

Whereas the lieutenant’s cloud most often addresses making sure we can do something that should be done, in many other instances we must also address not doing things that don’t need to be done – in a way addressing inertia.

In drum-buffer-rope the number of things that we must control is substantially reduced to those that are really important – material release date, divergent/convergent control points, drum schedule, and shipping/completion schedule. This can be quite different from current mode of operations, especially if the organization is using some variant of MRPII. Thus the subordination conflict becomes; do something that is not new and is required versus not doing something old and which is not required any further. In other words; don’t control everything, versus control everything. Let’s have a look at this.

We can read this cloud left to right and top arm then bottom arm as;

In order to be successful in our implementation we must protect the whole system, and in order to protect the whole system we must not control everything. On the other hand, in order to have a successful implementation we must protect each department in the system, and in order to protect each department we must control everything.

Hmm. There is a conflict between the desire to control everything and the desire not to control everything.

Because I personally see many system-wide needs as “dynamic complexity” problems and many departmental needs as “detail complexity” problems, I would like to also frame this conflict in terms of detail complexity and dynamic complexity

So, in order to maintain good local control, I have to control everything locally. And yet in order to get good system throughput I must not control everything – I must only control things that are necessary. To break this cloud we must invalidate the assumptions that give rise for the need to control everything. For the supervisors and foremen of local areas, this fear of losing control is a huge barrier to effective flow. Let’s develop this further.

In the past every time there was a problem, a new measurement would be introduced. Even when the problem went away, or even if the problem wasn’t particular to that area it is likely that the measurement is still in place. Inordinate amounts of time are consumed by line management recording data and preparing reports that are of little benefit, except that it gives a feeling of being in control – and to protect line management from blame if something should go wrong somewhere else.

You will see this cloud expressed again and again and again during an implementation. No one will say outright that they are scared of losing control of their area or of their performance; you have to say it for them. Once it has been verbalized – brought out into the open, and acknowledged, then progress will be made.

Often, the most effective way to break this cloud once it has been verbalized is ask for a trial with a set time frame. People who fear losing control of everything will welcome a trial to prove that matters will only get worse (as they suspect), and safe in the knowledge that it is for a limited period only. However, you will find that within a short while people will discover they didn’t need to control everything at all. They have learnt to control what is important. They will acquire a new confidence and at the end of the trial period you will find that the subject has been “forgotten” about. Indeed don’t even mention the matter again. Effectively the cloud is broken. We now have the following;

Another way to overcome initial resistance attributed to Debra Smith is described by Cole (4). Instead of “protecting” the change with a limited amount of time as in a trail, Smith protects the change with a little more of the old habit than is really necessary.

To break this cloud we must remove the old action that caused the problem. But remember there was an assumption that the old action answered. Let’s draw that in.

Lets clean it up a bit.

What Smith is suggesting is that although the new action for the solution answers the old assumption, people may still feel uneasy about doing it so at first. The answer is to “over-protect” the old assumption in the initial stages until people have confidence that the new solution does indeed answer the old assumption and fully satisfy the old need.

For example, reduced work-in-process will meet a new system need for reduced lead times, but people worry that it will cause the constraint to slow down; because of an old assumption that work-in-process waiting causes people to work faster. The solution here is to reduce work-in-process more gradually than is necessary so that people can gain confidence that the new need, short lead times and the old need, keep the constraint busy are both met.

Both of these alignment methods are really trying to bring about effective subordination.

Let’s restate this.

Effective Subordination

We could rewrite the clouds that we drew above as a slightly more generic case.

This is how most people will initially see the implementation – falsely. Their experience from TQM, TPM, kaizen, ABC, ISO900 and many other detail complexity methods will be that the sum of the local improvements equals the global improvement. We know that this is not so. We have to change the wording of the second need – “protect the local optimization is incorrect.

Let’s do that.

Now we see the real needs, we must protect the global optimization and subordinate the local optimization. To do that we must not control everything and once again we can break the conflict.

Let’s repeat is one more time, effective subordination is the key to successful TOC/drum-buffer-rope implementation.

Other Broader Alignment Issues

Dettmer shows a powerful cloud that must also be satisfied in a manufacturing environment – and all other environments for that matter (5). Let’s have a look at it.

What is it telling us? In order to be successful we must satisfy the good of the system, and in order to satisfy the good of the system we must implement changes. On the other hand in order to be successful we must satisfy the good of the individual, and in order to satisfy the good of the individual we must maintain the status quo. Clearly implementing changes and maintaining the status quo are in conflict with one another.

Let’s look at the assumptions underlying the arrow between “good of the individual” and “maintain status quo.” How do we raise these assumptions? Well try reading the cause and effect to yourself and at the end add “because.” For instance; in order to satisfy the good of the individual we must maintain the status quo because…

Dettmer lists a number of generic assumptions; assumptions about the status, security and authority of the individual. Let’s draw these in.

Remember that the individuals concerned are intelligent, motivated, etc., and will have tried to improve the process in the past and failed. They have rationalized that the problems lie beyond their control – most likely in another section or department, or factory, or company. Conversely, they will have rationalized that they are doing the very best they can and will strongly anchor their current status, security etc., to positive aspects of their current reality. You have to break the cloud by anchoring those assumptions with the change you are implementing. Let’s draw that.

Let’s take a very good example of a line worker who starts each day with a pile of WIP waiting to be worked upon, and at the end of the day has another pile of now completed WIP ready for the next operation. Even though there is probably a nearly constant pile of work both in front of and after the worker, he will partition “a day’s worth or work” according to his experience, or the local schedule, and will derive a great deal of satisfaction from meeting that target.

If the work-in-process is reduced throughout the plant, then this visual indicator before and after the work center will be reduced. So too will the feedback and feel-good factor that the line worker experiences even though he is working just as well or even better. To break this cloud you must hook up the job security and job satisfaction in some way to the global objective or else the security and satisfaction of the worker is threatened and no improvement will take place.

In some countries, lack of work-in-process is indicative of upcoming lay-offs, there is no reason for anyone to believe at first that this is any different from the past (except that the decrease in WIP is a consequence of proper scheduling rather than decrease in sales demand). So you must tie the status and satisfaction to the new conditions and reinforce these whenever you can.

Summary

Theory of Constraints is not like TQM or kaizen where everyone everywhere can make a positive contribution by doing new or better things. Everyone is still making a contribution in Theory of Constraints; however, often it is passive – by not doing old things. This brings us back to where we started. Effective subordination is the key to successful Theory of Constraints implementation.

References

(1) Kawase, T., (2001) Human-centered problem-solving: the management of improvements. Asian Productivity Organization, pg 209.

(2) Goldratt, E. M., (1999) How to change an organization. Video JCI-11, Goldratt Institute.

(3) Lepore, D., and Cohen, O., (1999) Deming and Goldratt: the theory of constraints and the system of profound knowledge. The North River Press, pp 140-143.

(4) Cole, H., (1998) Implementing distribution – layers 4-5. Video JMT-16, Goldratt Institute.

(5) Dettmer, H. W., (1998) Breaking the constraints to world class performance. ASQ Quality Press, pp 207-225.