A Guide to Implementing the Theory of
Constraints (TOC) |
|||||
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. 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. 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 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. 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. 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. 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. 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.
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. 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. (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. This Webpage Copyright © 2003-2009 by Dr K. J.
Youngman |