|
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 |
