|
A Guide to Implementing the Theory of
Constraints (TOC) |
|||||
|
How Much Time Is Necessary? There are some very important issues that revolve
around the expectation of the necessary time required to implement an application
in Theory of Constraints. Let’s have a
look at these; (1) If you expect an implementation to
take a long time and cost a great deal – it will. (2) If you expect an implementation to
take a short time and cost a little – it will. Your expectations will determine how long it takes
to have an effective implementation. We are
conditioned by experience (and maybe management consultants) to expect that
our complex problems will require complex and expensive solutions. And besides, if the solution was so simple
we would have already implemented it – right? We naturally
expect complex solutions to take a long time (and management consultants to
cost a lot of money), in part because we tend to value things on basis of the
effort put in rather than the result that is obtained out of the effort. This seems to be part of the
reductionist/local optima heritage that we must deal with – “please break
down your budget into hours spent on this and hours spend on that.” We should really be asking how quickly –
how many weeks – will it take to pay back the investment? Think for
instance of the time required for business process reengineering (BPR) – and
did it work? Or the time required for
a complete activity based costing analysis (ABC) – it cost an arm and a leg
but did profit go up? Or the time
required implementing total quality management (TQM) or total productive
maintenance (TPM). How about the time
required to implement the balanced scorecard (BSC) or one of the ISO business
standards such as ISO 1400. We are not
talking about weeks, we are talking about years! Why is Theory
of constraints so rapid while other methods take so long? Well there are two reasons for this. Firstly, Theory of Constraints is rapid because
it addresses a dynamic complexity problem.
We learn how to isolated the few critical dimensions and address them
explicitly – dependency, variation, and the role of the constraint. Thus an apparently complex problem can be
resolved with a simple solution.
Moreover, the solutions are designed to be transferred, the education
is built into the solution, and the organizational knowledge within
constraint practitioners ensures that improvements in implementation
methodology are quickly disseminated. The second
reason is that the other methodologies mentioned, and including MRPII, all
focus on detail complexity. They
attempt to address everything, everywhere, all of the time; on the basis that
whole of the system is the sum of the parts.
If we do this then we miss the true leverage points completely or we
minimize our focus on them as we try to balance our focus on all the other
“important” things at the same time.
Detail complexity methods also require accuracy of data, rather than
robustness of data, and so considerable time and effort goes into data
collection and reporting. Robert Newbold
(1) has a cloud that expresses the dichotomy between having simple solutions
and complex solutions. It looks like
this;
And what is
his trim? Let’s have a look.
What sort of
durations can we expect? Well, from direct experience, how about increasing
output by 25% in 8 weeks in a system that was “capacity constrained,” and
further increasing the output to 45% by the 8th month. Imagine what that did to the
profitability. Or how about reducing
work-in-process by 2/3rds in 12 weeks and stabilising
it there? Imagine what that could do
inventory costs and lead times. The
first example had a staff of 40 people on the floor; the second example had a
staff of 400. The size of the implementation is not
important. However, the degree of
understanding and alignment is important.
Theory of Constraints can be a very rapid. If you are really between a rock and a hard place
and the issue isn’t one of “do we have to do it so quickly” to one of “we have
no choice but to do it very quickly,” then we should also look at utilizing
Critical Chain. Critical Chain is a Theory of Constraints logistical
solution for project management. Like
drum-buffer-rope for manufacturing, critical chain “rolls-up” all the local
safety into strategically placed global buffers. The net result is that projects can be
completed on-time and in full in about ½ of the normal duration (2, 3). If time is of the essence, what would you
do – critical chain or traditional critical path? Think about this a little more. Projects and manufacturing are really not
that different at all. One;
manufacturing, deals in multiple units of product per unit of time. The other;
project management, deals in multiple units of time per unit of product – the
project. In manufacturing we are
trying to maximize the number of units and we do that by protecting the
constraint, the slowest step. In
projects we are trying to minimize the units of time and we do that by
protecting the constraint, the longest dependent path in project. Theory of Constraints implementations are very rapid
compared to other approaches for a number of reasons; they address dynamic
complexity – the few critical leverage points, they are results or outcome
oriented, they are designed from the very beginning to be transferable, they
address the alignment issues and have the toolsets to deal with the technical
and organizational factors that will occur along the way. And last but not least, its all been done
before by many different people in many different places. (1) Newbold,
R. C., (1998) Project management in the fast lane: applying the theory of
constraints, pp 233-234. (2) Goldratt,
E. M., (1997) Critical chain. The
North River Press, 246 pp. (3) Newbold,
R. C., (1998) Project management in the fast lane: applying the theory of
constraints. St. Lucie Press, 284 pp. This Webpage Copyright © 2003-2009 by Dr K. J.
Youngman |
