|
A Guide to Implementing the Theory of
Constraints (TOC) |
|||||
|
How Do
We Implement Drum Buffer Rope? In the
previous section we examined the mechanics of drum-buffer-rope in a rather
basic form – an idealized framework. In this section let’s try to flesh out this
framework with a little more implementation detail. Of course the best way to learn this detail
is to just to go out and do it.
Drum-buffer-rope and the Theory of Constraints is a robust methodology
so long as we keep the rules of engagement and plan of action in mind. We will use
the 5 focusing steps – our plan of attack – as our template. We probably can’t repeat these steps too
many times so let’s repeat them again right here; (1) Identify the system’s constraints. (2) Decide how to Exploit the system’s constraints. (3) Subordinate everything else
to the above decisions. (4) Elevate the system’s constraints. (5) If in the previous steps a constraint has been broken Go back to step 1, but do not allow inertia to cause a system
constraint. In other words; Don’t
Stop. OK then, let’s
start at the start. In any normal
production process, either manufacturing or service based, there will be
work-in-process everywhere, especially if the plant is run as a balanced
line. Even more so if you use some
form of MRP or ERP. How do we find the
weakest link? In this situation every
step looks like the weakest link with large amounts of working waiting to be
done at each stage. There are 3
ways; (1) Find the step with the longest waiting time for work to be completed. (2) Find the step that most often causes disruption downstream. (3) Nominate something. Doing
something, anything, might seem counterintuitive, but if you haven't chosen
the real constraint, then it will make its presence felt very quickly. This
is a process of on-going improvement; don't be scared to do something –
anything – because each step will take you closer to your company's goal. No, no. Please don’t do this. Collecting data and writing a report should
not be considered as doing something, at least not something that effective
people do. Most likely it should be
considered as doing nothing. Data
collection is usually a stalling tactic.
The data is never good enough to make a decision on – which means you
will need to collect even more data.
Remember this is a dynamic complexity problem, so don’t go and use
detail complexity solutions such as searching for more accurate data on
it. Normally with drum-buffer-rope you
should have demonstrable results in the same amount of time as others would
have spent collecting data. So it
becomes a choice, take an action, or collect data. Moreover,
report writing usually doesn’t generate ownership or understanding of the
real problem, it might generate an understanding of the symptoms, but not
usually of the underlying core problem or core conflict. Reports generally do not involve all the
needed people and are usually perceived to apportion blame. Note, perceived to apportion
blame. So even the most neutral and
factual report will be perceived by some people – usually the people in the
problem area, to be apportioning blame.
There is usually only one response to this by the people involved,
defensiveness and deflection of the perceived blame onto another area. Naturally enough this will not help to
improve things at all. The Thinking
Process graphical trees are the tool of choice for generating buy-in and
understanding of the problem and then seeking consensus on the solution. In addition
don’t be afraid to go and stand in the middle of your process and just watch
what is happening. People will get
used to you being there fast enough.
And you are in good company, Taiichi Ohno the inventor of Toyota’s
just-in-time once said; “We can talk about work improvement, but unless we
know production thoroughly we can accomplish nothing. Stand on the production floor all day and
watch – you will eventually discover what has to be done. I cannot emphasize this too much (1).” It is likely
that people with an affinity for understanding flow will naturally spend
considerable time on the floor; don’t be afraid to do this just because no
one in the company has done it before.
This is the reality check between what people tell you is happening in
production and what really is happening.
The Japanese have a saying; go to the actual place, see the actual
problem, and speak to the actual people.
Just common sense really. Almost all
implementations in the pre-drum-buffer-rope stage claim to have wandering
bottlenecks. Don’t worry, there will
almost certainly be work-in-process everywhere as well, and this is the cause
of the impression. However, later – as
things begin to flow – there may still be the impression that there are
wandering bottlenecks from time to time.
In this instance it is most likely a case of wandering large
batches. Large batches will hold
themselves up at slow process stages.
Reduce the maximum batch size and the problem will go away. Usually the
people in the process have the best idea of where the constraint might
be. If all else fails then just
nominate something, and the real constraint will make itself known within a
short space of time. Initially the
constraint is protected by a large pile of work-in-process; there is always
something to do. But is the constraint
always doing something productive? Is
the constraint sometimes doing things that are unproductive? The best way to find this out is to write a
plan, a schedule for the constraint.
If you already have schedules for the plant in place, this might be
the very first time that you write a schedule in detail for one
resource. This can be as simple as a
whiteboard on the production floor.
The important thing is to write a plan of how to exploit the
constraint over the next short period.
Then we have a basis to evaluate our actions and our results. The schedule will let you peel away the
obstacles to proper exploitation one by one. Exploitation
tactics on the constraint in manufacturing include; making sure automated
machines run during breaks, making sure set-ups are staggered, fixing
break-downs quickly (or preventing them completely), replacing absent workers
quickly, avoiding downtime during shift changes, avoiding multitasking of
set-up personnel, keeping faulty work or unnecessary work off the constraint. Of course
people will have always tried to do this; it is just that they didn't know
where to focus on in the past. Now
they do. The focusing itself will
greatly improve the constraint. For
example when management sees the set-up man on the constraint waiting for a
laptop to program a machine and that the laptop is currently at some
non-constraint machine on the other side of the plant, they will take
action. Whereas one week prior the
only action would have been to ask the constraint operator to be patient. This doesn’t
have to be sophisticated – especially if your operation isn’t particularly
complex. Even if your operation
appears complex prior to drum-buffer-rope, you might be surprised how it
looks with in a few short weeks. A
constraint schedule might be written on a white board on the work shop floor,
or a sheet of graph paper, or travelers/paperwork hung in sequence on a rope
near the constraint. The
synchronization might not be anything more than one job finished at the constraint
means one job admitted by the gating operation. The important thing is that is understood
and that it works. More complex
operations in all likelihood already have an infinite capacity MRP-based
scheduling system in place and then it is a matter of adjusting this to work
in a finite capacity drum-buffer-rope environment. There are drum-buffer-rope schedulers
available, for instance see Manusync in the links and resources, however it
is infinitely better to get the organizational understanding and behavioral change accomplished first and then
look at more automated options and to leverage off the automation. Automation before understanding is like
putting the cart before the horse and it is not known to be effective. What if, for
some reason, the actual constraint is difficult to schedule? No matter, you could consider nominating a
shadow constraint somewhere else – just make sure that it is “hobbled” by the
schedule so that it can’t exceed the throughput of the real constraint (2). When the schedule
and reality deviate for whatever reason, then schedule reality. Generally this means re-synchronizing the
current constraint sequence to a new time.
Of course proper buffer management should avoid such resynchronization
– but stuff happens.
We must ensure
that we subordinate our local actions to that of the goal (global outcome) of
the system. For actions read;
decisions, behaviors, measurements, and policies. Normally we do that via the plan we write
for exploiting the constraints – the schedule. When we have a
written exploitation plan in place we can quickly compare actual results
obtained with the planned results. We
will soon see deviations. As we saw in
the section on process of change, these deviations from the plan results from (12); (1) Not
doing what was supposed to
be done. (2) Doing what was not
supposed to be done. The deviations
from plan result from our failure to properly subordinate. Let’s have look at some the more common
subordination issues in more detail. Then we will look at two local performance
measurements that we can use to align and monitor our subordination efforts
with. We will also consider a pivotal
role in subordination; the role of the buffer manager.
It is not
enough to write a schedule, we must also protect the constraint to make sure
the correct material is always ready and waiting for processing in good time
before the start date at the constraint.
We can achieve this by ensuring that we release material a rope-length
in time prior to the scheduled consumption on the constraint. Previously we
applied a rule of thumb which was to make the rope length half the current
lead time from gating release to the constraint start time. We then divided this rope length into 3 equal
buffer zones. Essentially we expect
most jobs to be ready and waiting at the buffer origin (a place in front of
the constraint) within 2/3rds of the buffer time available. But just how much is most? It seems to vary; original estimates seemed
to be of the order of 90% (4). More
recent estimates suggest 95% (5). It
seems much more likely that the actual percentage is best determined by the
volume of jobs in each situation. Even
though zone 1 was called the expediting zone initially, more recent terminology
seems to favor dropping this term and simply calling it zone 1. Expediting has such negative connotations
in manufacturing. There is some confusion however in the literature
over the definition of the buffer. In
fact this confusion arises more as a consequence of the difference in
interpretation between the buffer and zone 1 of the buffer. The total buffer time is divided into 3
parts. The zone closest to the buffer
origin should normally “be full.” Some
authors then call this zone 1 component of the entire buffer as “the buffer.” Schragenheim and Dettmer, Stein, Caspari and Caspari
follow Goldratt’s lead and take a total lead time approach to the buffer
definition (6-8). Woeppel, Cox and
Spencer, and Umble and Srikanth take a zone 1 definition of a buffer (9-11),
that is they treat it as a discrete addition of time in front of the
constraint. It seems that those who
relate more closely to MRP environments prefer the zone 1 definition of a
buffer. Sometimes a zone 1 definition of the buffer helps
people to understand the local versus global safety argument. Let’s have a look at that next. Umble and
Srikanth were perhaps the earliest to publish on the detail of
drum-buffer-rope independent of Goldratt.
They chose a Zone 1 definition of the buffer (11). Basically this develops out of an argument
for local safety everywhere versus safety as strategic buffers in a few key
places. Probably few
managers would deny the importance of a special buffer in front of an
identified constraint – many more, however, would be hugely reluctant to give
up their local safety everywhere else.
They would prefer to keep all their local safety and create some
additional safety in front of the constraint. Because the
concept of local safety everywhere is second nature to manufacturers it is
sometimes difficult for managers to see the important characteristics of
global buffers. As previously
mentioned, if an MRP or ERP system has been implemented, the local safety
values might be quite explicit. If you are
interested the argument for moving from local safety everywhere to global
safety in a few key places is here. Proper
subordination not only means making sure that we use the right measures, but
also means making sure that the right measures are continuously communicated
to the line. The most important global
measure is physical output and/or financial throughput. If the constraint is internal then this
should go up, if the constraint is external then it may initially stay
constant, but it too should go up. These results should be visible to
everyone and updated as frequently as possible. Updating once a day is good and is not too frequent. But having visible results is not
enough. The line management must
reinforce positive results with a few well chosen words to the right people
at the right time. That reinforcement,
like water, will filter down to all levels and in all directions. Reluctance to
praise will be viewed as failure to support the initiatives. You would be amazed how some managers are
reluctant to praise significant results.
You can be almost sure that the manager concerned does not fully
support the implementation. It is a
very passive way of communication, do everything requested but say
nothing. Such managers can block
praise from the leadership meant for the line by failing to pass it on. It happens. By the same
token the leadership must reinforce positive results with a few well chosen
words to the right managers at the right time. Without that feed-back the managers may
decided that leadership support is lacking. All
implementations develop speed wobbles.
The analogy is a child who has just learnt to ride a bicycle, maybe
straight-off, or maybe for the first time without dummy wheels or stabilizers
or what ever you wish to call them. As
the child goes a little faster, at some stage they will decide that if they
go any faster they will fall off – and they do. Our people may never have produced as much
output before without some sort of assistance (overtime maybe), they
certainly won’t have done it with less inventory as well – they will convince
themselves that they can’t continue to do it and things will come unstuck for
a few days. And then we just pick
ourselves up again and go straight past the point where we thought we
couldn’t go past before. What is
really happening is that people are learning to subordinate properly for the
first time. We have
mentioned many times of the need to reframe the environment from one of a
reductionist/local optima approach to one of a systemic/global optimum
approach. One of the most important
aspects of this reframing in a processing setting is the perceived value of
work-in-process held by the guys on the floor. It is the epitome of local optima. A large pile of work-in-process in front of
each work center in the morning is a measure of importance and security to
the members of that work center.
Seeing that work-in-process moved to the next work center by the end
of the day is a measure of success and satisfaction to the members of the
work center who processed it. If we
reduce work-in-process in this setting then we must “unhook” these measures
of security, success, and satisfaction and “rehook” them to the global
measures of the system. People will
get used to the new reduced inventory way quite quickly, they will develop
pride in how “the work I started this morning is now way over there,” but it
needs careful nurturing and the positive reinforcement mentioned above during
the transition. If managers
find the importance of work-in-process hard to believe, then try operating
with a clean desk policy (a really clean desk) for a couple of days and count
the number of people who will question whether you have any work to do. These pressures are pervasive and very powerful and can undo an implementation. To properly
subordinate the process to the constraint we must pace new material release
to the pace of the constraint. To do
more only builds work-in-process. Many
times early on there are likely to be pressures to admit extra work. Often there are not-so-subtle pressures from
sales people to favor certain clients – always their clients and not anyone
else’s clients. It requires good
leadership in both sales and manufacturing to avoid this. Another reason for using the holistic
approach prior to the implementation. An important
part of subordination is to make sure that the “drumbeat” is relayed to the
start or gating operation and is observed. This means that new scheduled work should
not be admitted into the system any sooner than scheduled. Again in the early stages there is a great
temptation to admit work early to keep the next several stages “busy” and to
“get ahead” at little. Doing this will
result in non-constraints at some stage working on work that is not needed to
be worked on and not working on work that is needed to be worked on. Local work-in-process will go up, local
lead times may increase, and if this is a consistent policy, holes in the
buffer will surely arise, and throughput will go down. The
subordination challenge for gating operations and all other non-constraints
is to keep work-in-process and lead time low and constant and the buffer full
(downstream). To do this we must
protect their sprint capacity. The capacity
that all non-constraints have above and beyond the capacity of the
constraints is often termed protective capacity and sometimes called sprint
capacity (13). Sprint capacity seems
to be a good description of this factor.
It is a description of the ability of non-constraints to speed up
(actually working longer at their normal rate) as the situation requires in
order to get work to the constraint on time after some variability in the
system has intervened such as; worker absence, machine downtime, rework
issues, or material supply. Sprint
capacity is a fundamental and absolute component of drum-buffer-rope. Let’s examine this in more detail. All systems
have 3 elements in common (14); (1) Finite Capacity. (2) Variability. (3) Dependency. This much we
know already. However, for a
given set of dependencies, there exists a dynamic relationship amongst; (1) Sprint capacity. (2) Variability. (3) Inventory (work-in-process). So, the better
the sprint capacity, the more likely we can handle variability and maintain
our work-in-process. If we reduce our
sprint capacity without reducing variability, the work-in-process must go up
(and lead times will go out). If we
can maintain or increase our sprint capacity and/or reduce our variability
through total quality management, kaizen, or whatever, then work-in-process
can go down. Argued from a
different perspective; increases in sprint capacity can allow decreases in
buffer capacity. Conversely decreases
in sprint capacity will require increases in buffer capacity. The latter is very important where demand
grows as a consequence of implementing drum-buffer-rope. Increased demand on the non-constraints
decreases their sprint capacity and may cause holes in the buffer to emerge. There are two options; increase the sprint
capacity of the non-constraints or increase the buffer capacity of the
constraint. In fact sprint capacity,
cross training of employees, duplication of capabilities, having more that
one supplier, are all cases of buffering the system (15). Whether the buffering is explicit or
implicit the effect is the same. Ideally, we
must continually hunt out additional sprint capacity. We saw in the section on accounting for
change the strategic implications of near-capacity constraints and we will
repeat the argument at the end of this page.
Fortunately buffer management gives us the control mechanism to stay a
couple of steps ahead of eroding sprint capacity. There is, however, one issue that will
destroy sprint capacity faster than anything else – poor road runner ethic. The kanban in
just-in-time gives workers permission to work only when there is work to be
done, and permission not to work when there isn’t work to be done. Of course in processes where there is total
quality management or total preventative maintenance the chance that there is
nothing to do at all is pretty slim indeed.
In fact these systems need slack built in so that such activities can
take place (16). This is in fact how
additional sprint capacity is built although it is not called that in these
methods. Theory of
Constraints drum-buffer-rope uses the road runner ethic instead. The analogy is that the road runner (both
fictional and in real life) has just two speeds, fully-on, and fully-off, and
this is how non-constraints should work in drum-buffer-rope. If there is work; work on it at normal
pace, if there isn’t work; don’t work on it.
However, it seems that some people take the cartoon interpretation too
literally and believe it to mean working at more than normal pace. This is not the case. The road runner ethic says just two things; (1) When there is work, complete it promptly. (2) When there is no work, find something else to do. Implementations
get into trouble when there are reluctant road runners. Reluctant road runners are a management or
leadership issue; it is not a worker issue. Another way of
looking at this situation is through the terminology of activation and
utilization (17). Activation at its
most basic interpretation means working for the sake of appearing to be
busy. Utilization means working only
to create or protect throughput. We
saw previously that one of the synchronous manufacturing principles was: Resources must be utilized, not simply activated
(17). This is a re-verbalization of
the need for adequate subordination. If there are
local efficiency measurements still in place then don’t expect to see
roadrunner. Don’t expect to get the
same results either. Implementing
roadrunner while having another older and stronger counter measurement will
cause it to fail. Timesheets broken
down by job or task for non-constraints is a powerful signal to be busy all
the times. Even when the system owner
in such an environment includes a code for “Roadrunner” on the time sheets –
which in effect means “I’m idle” – do not expect to see it used. Believe me. There is quite
an old term used in manufacturing to describe the practice where people work
just as slow as necessary and no faster – soldiering (18). Taylor sought to a large As we reframe
the situation from a reductionist/local optima approach to a systemic/global
optimum approach we must be aware of not only the presence of new
measurements and behaviors, but also of the presence of old measurements
which continue to underline old behaviors.
If you have reluctant roadrunners then look for “legacy” measurements
that are causing that behavior. I have seen
the so-called “laziest” group in a factory embrace roadrunner, and use the
spare time to maintain their gear – something that previously they had been
hard pressed to do. To understand
this, just think back to the section on people. People will make the best decision that
they can based upon their map of reality.
If you change the map of reality you will change the behavior as well. If you measure
people based on local efficiency you will get soldiering – guaranteed. If you measure people globally, you will
get roadrunner – guaranteed. You can “wing”
a large amount of improvement in a process just from improved exploitation
without necessarily utilizing full subordination such as roadrunner. For instance you can obtain impressive and
rapid improvements in output where time sheets are still in force, but the result
will be soldiering in several departments and the illusion within middle
management that it is impossible to improve any further – after all the guys
are fully busy. It really depends
whether we want a process of on-going improvement or a one-off gain. Let’s
complement our understanding of the roadrunner ethic with the traffic light
analogy that we developed in the section on process of change. When a non-constraint is working it is
creating throughput, and when a non-constraint is not working it is creating
protection for throughput.
Batch sizing
is an important part of subordination.
Sufficiently important that we will give it a page of its own. Obtaining agreement to modify batch-size is
a major part of most process implementations. As work-in-process
decreases there are going to be a lot of devices left around that the work
used to sit on and also maybe moved on.
Remove these at a healthy and proactive rate as they become free. If there is somewhere for people to put
work down on, then people will find work to put down on it. When there is insufficient work available
to cover the “empty” spaces people become uncomfortable. Remove the cause of the discomfort – the
empty and unnecessary pallets, trolleys, or what-have-you that is in excess. Clean them up and make sure people know they
have been put away for safe keeping.
We don’t expect to ever use them again; but most others will be
expecting that they will be used again shortly. This way everyone is happy until we all
forget that it was ever an issue. This one
requires patience, persistent patience.
Let’s go back a step or two.
Many drum-buffer-rope implementations will have previously had some
sort of MRP scheduling system in place, or in its absence some sort of
“hands-on” method of expediting. The
whole rationale of the scheduling component of MRP in a job shop or
repetitive batch environment is that it is able to reschedule any process
stage by reprioritizing the sequence that work waits in queues prior to each
stage of the process (21). Drum-buffer-rope
removes the need for queuing everywhere but not the bad habit of
reprioritizing work in the queue. Some
jobs may simply float for a day or two until they are done – continuously
passed by more recent jobs that have arrived.
In cultures where seniority is highly respected, and there are senior
operators, it may be extremely difficult to get first-in-first-out operating
initially. Persist. Because
material is released to the system in the sequence that it will be processed
on the constraint, then in most cases simple first-in-first-out will preserve
the constraint schedule sequence.
Failure to observe this will quickly lead to holes in the buffer. Work that is passed over at a
non-constraint will be detected as late at the buffer. Work that is favored will be detected as
unusually early at the buffer.
Everyone knows which are the “sweet” jobs, if they start to turn up
early then be paranoid. At
non-constraints; “The method of determining priority is first in first out
(FIFO). Since the schedule for the
constraint and the amount of protection required determines the release date,
the sequencing of orders has already been determined and should be by arrival
data/time to the non-constraints.
Unless there is a problem causing an order to penetrate zone one in
buffer management, no effort is made to change this rule (22).” In large
volume conditions however we need to note the following for non-constraints;
“In the case of a shop that has many jobs arriving in a day, a method has to
be devised to determine the sequence in which the jobs arrive. This will dictate the sequence of
processing. The procedure addresses
two things – how to know what arrived first, and how to make sure people work
in that sequence (23).” Even in the
very best systems, occasionally “stuff happens” and we can’t always deliver
on time or ex-stock as we initially promised.
Material shortages are probably the number one cause for this. Over-promising by non-manufacturing
personnel is probably the number two reason.
As a consequence usually the IT guys get given a project to do to
build some meaningful measure of lateness.
Why the IT guys? Well it has
numbers in it and uses the MRP system so it must be an IT job. Of course the IT guys come up against the
age-old problem of whether to measure in units of time or units of sales
value. Do we measure the number of
days late and under-report a big job that was just a day late or do we
measure sales value and under-report the small job that was held up for
several weeks while we waited for a part from the outsourcer? The answer is
that we measure both, using the value of throughput-dollar-days (12). On any given day we multiply any late
order’s throughput by the number of days that it is late and sum for all the
late orders. Of course it should be
zero but sometimes it won’t be. For
orders whose lateness impinge upon our customers we should measure from the
original required delivery date for make-to-order and the order date for
make-to-stock (goods should be availably ex-stock at the time the order is
placed). However, Goldratt suggests
that in order to avoid this most undesirable situation we should also “tie”
the lateness to buffer holes (12). "Sometimes an action by the
organization is triggered due to a deviation in a local department. This occurs whenever a task does not arrive
at its buffer‑origin even though enough time had elapsed since its release,
enough time to cause us, in quite high probability (let's say over 90
percent), to expect the task's arrival.
Thus, we might start to count the days from the point in time when the
task penetrated into the expediting zone, rather than from the order due‑date. This will give us time to correct the
situation before damage to the entire company is fait
accompli." We might
consider this to be a tactical
application. Thus a work order that is
late to zone 1 of any buffer should have in the buffer report a value for
throughput-dollar-days. Let’s draw
that.
Lateness
= Rope Length – One Zone Length – Actual Duration Using the
example from the section on drum-buffer-rope.
Our rope length was 9 days and each buffer zone is 3 days. Therefore any work not at the buffer origin
in (9 - 3 =) 6 days should be located and any apparent cause for the delay
recorded. If the job actually takes
6.5 days then the hole in the buffer is 0.5 days long. Note once
again that the buffer end time, the zone length, and the buffer checking time
are all measures of time which we have drawn in space on our diagram. Viewing buffers like this is a major source
of confusion caused by the limitations of our two dimensional representation. The only
person who needs to know the buffer checking time for a job is the buffer
manager. Don’t add it to the plant
schedule or else it will immediately become an intermediate schedule date and
people will leave work until the last minute – and it will be late. In effect having such a date on the
schedule creates a “concrete” zone 1 buffer in most people’s minds. This is not correct; the buffer extends
from material release until the scheduled beginning on the constraint. Using buffers
to manage in this way we not only have information on the probable location
of the problem and the frequency of incidence but we also have some measure
of the severity from the system’s viewpoint.
The more days late, and the more throughput at stake, then the more
severe the problem. This information
is currently missing from most buffer reports. Stein advocates exactly this when preparing
a buffer hole Pareto chart (25, 26).
Let’s try and show Stein’s argument graphically. Currently a
Pareto chart of buffer hole incidence might look something like this;
Severity
= Throughput x Lateness This can
change the way that we view the information.
For instance the graph might now look like this;
This is valid
information for the 5-10% of orders that we have to expedite. But what if the order is no longer at the
resource that caused the lateness. How
can we know what to improve in this instance?
The answer comes back that we must deepen the statistic (27). A more satisfactory concept might be that
of a “tracking zone” established expressly for this purpose (27). Stein advocates extending the buffer
checking point out to zone 2 (25, 26).
It is now far more likely that an order will be found at the location
that is causing it to be “late” and it is also far more likely that emergent
problems will be found before they become critical. We might view this to be a strategic application of buffer management. Let’s draw that.
Tracking
Hole = Rope Length – Two Zone Lengths – Actual Duration Again using
the example from the section on drum-buffer-rope. Our rope length was 9 days and each buffer
zone is 3 days. Therefore any work not
at the buffer origin in (9 - 3 - 3 =) 3 days should be tracked and its
location recorded. If the job actually
takes 4.5 days then the tracking hole is 1.5 days long. I don’t think
the intent is that tracking should be undertaken for every job, even though
our manufacturing system might be able to show us every hole in the tracking
zone. It is unlikely however that we
will know where the job is without physical inspection, and so this type of
data analysis should be periodic at best – sampling the system performance
from time to time in other words. A process is
like a sponge; we go about squeezing the excess work-in-process out of it,
then let it rebound to its original shape and put it back down on the
bench. WARNING, if there is any water
on the bench the sponge will simply soak it up again. If you don’t have the vigilance of a hawk
your system will start to build inventory as soon as possible. The previous best way to keep a tag on this
is either by a measure of work-in-process or a measure of lead time.
Moreover, as a
drum-buffer-rope implementation begins to give increased sales the volume of
work in the process will have to increase unless the rate of flow (the lead
time) decreases. Use
inventory-dollar-days as a way of continually driving the system to better
levels of performance. Don’t let the
value rise because it indicates that your process is becoming slower –
customers don’t like that. At a
departmental level, inventory-dollar-days is a good way to keep a handle on
aging work if sweet jobs are queue jumping other jobs. Failing this, then at least have a daily
graph of local work-in-process versus output.
From this you can derive an indication of local departmental lead
time. Why do this? Well, as work-in-process goes down, people
often slow down too. This graph will
focus on the positive of the decreasing lead time and warn whenever it is rising. It also removes the focus from the total
work-in-process. Remember that maybe
just a few weeks earlier a large work-in-process was a measure of how busy
and important a department was. We
have to replace that measure of importance with another – short lead times. The concept of
a buffer manager is pivotal to the smooth execution of drum-buffer-rope. The actual person who occupies the position
will depend upon the size of the firm.
For a small firm the buffer manager may well be the owner or a foreman
– indeed the foreman if the firm is not too large. In larger firms it might be a senior
planner or the production manager.
Whoever it is, they must have the vested authority to determine the
priority of work in the non-constraint areas. Buffer
management has two functions which we have seen; strategic
and tactical. The tactical function is to enable the
limited expediting of jobs that might not otherwise reach the constraint on
time. The strategic use is to monitor
the size of the buffer and conversely the aggregate sprint capacity of the
non-constraints. This will identify
potential emergent constraints. We now
have sufficient system-wide vision to decide whether to invest in additional
capacity, or better subordination, or longer buffers. Buffer
management reporting is the subordination control mechanism that replaces
legacy efficiency reporting. Buffer management reporting is a replacement, not
an add-on mechanism (29).
“If anyone
adjusts a stable process to try to compensate for a result that is
undesirable, or for a result that is extra good, the output that follows will
be worse than if he had left the process alone (3).” The process of interfering in a stable system
is often known as tampering. It is the
epitome of a combination of people wanting to do their best, and the effects
of dynamic complexity. A local action
(in time) that is perceived to be positive may have negative ramifications
for the system as a whole at some later time.
We mentioned the impact of this – the failure to “learn from
experience” in the introduction. Essentially
the stages of identification, exploitation, and subordination seek to
stabilize the system around the goal, usually maximal throughput in
manufacturing or output in a not-for-profit organization. Be careful however, just because you have
removed expediting from the shop floor for instance, there will be other
people who will “tamper” with the resulting stable drum-buffer-rope process
with the best of intents. However they
will cause harm. Again it arises from
failure to learn from experience because the feedback is blocked by distance
and time. Consider for a
moment the example where the sales function “forgets” to tell manufacturing
about a promotion in good time – has that ever happened? And then the sales function panics and
interferes with the schedule. Sales
meet their short term objective of getting additional promotional stock, but
harm other orders. It is much better
to allow the buffer manager to deal with the problem as best possible within
the existing system. It is absolutely
essential that the harm caused by tampering is highlighted to everyone. Better still make sure the holistic
approach has been used so that all parts of the process are aware of the
constraint and the effect of tampering before the implementation begins. Elevation is
so system specific that it isn’t possible to address it here. It may however be some considerable time
until we need to elevate if the exploitation and subordination stages are
approached as a true process of on-going improvement. If a
constraint is elevated sufficiently that it is broken, then we must go back
to the first step and identify the next constraint. Well, that is if we are not to allow
inertia to take over as satisfaction with the current status. Of course we would expect that buffer
management would have identified the next physical constraint. It may not however adequately identify the
policy constraints that give rise to physical constraints. So we shouldn’t forget to expose our
investigation to the rigors of the Thinking Process current reality tree when
we begin to identify a new constraint. There is
another aspect to this stage of the process.
We can make it quite proactive rather than passive by selecting a
strategic constraint. Indeed as
knowledge of the way the business generates throughput or output improves it
is very likely that a strategic constraint will be selected and managed. Let’s look at this further. In the first
stages of an implementation people are going to raise the issue of “if we
exploit this constraint, we may in fact elevate it above something else and
the constraint will move to there.”
“AND if we begin to exploit the new constraint, it too, might be
elevated above something else and the constraint will move once again.” Exactly right. It could sound
like a weak excuse to do nothing, in reality it is peoples’ intuition telling
them that, yes, if we know where to focus we can break constraints
easily. And at the same time that same
intuition is telling people that they really don’t know where the next
constraint will be and with that there is a feeling of powerlessness or loss
of control. After we begin
to dry a process out we can begin to make conscious decisions about where we,
the management, want the constraint to be.
In effect we are choosing a strategic constraint; we are making a
decision to always build sprint capacity ahead of building capacity on the
constraint. There are good reasons for
this. The constraint dictates the way
in which the firm will make money – and capital investment, product
development, marketing and sales. Newbold, using
the language of leverage points rather than constraints; reworded the 5
focusing steps to accommodate this strategic perspective (30). (1) Select the leverage points. (2) Exploit the leverage points. (3) Subordinate everything else to the above
decision. (4) Elevate the leverage points. (5) Before making any significant changes, Evaluate whether the leverage points
will and should stay the same. The new key
words are; select and evaluate. This requires
a more focused approach to non-constraints and near-capacity constraints. Near-capacity resources must be removed
(30). Therefore; (1) Identify near-capacity constraints. (2) Evaluate their significance. (3) If necessary, remove their impact. Essential this
is a type of “subroutine” loop for near-capacity constraints running within
the subordination step above. We drew
this on a sub-page off the page on evaluating change. Let’s draw a similar diagram here.
The
identification and evaluation of near-capacity constraints is of course a
strategic function of buffer management.
Using the tracking zone from time to time will help to answer these
strategic questions. Don’t ever
underestimate the power of being on the floor or wherever the real work is
done. Things will go wrong. You will be able to solve problems with
direct management involvement in 15 minutes on the floor that you will not
have been able to solve with the same management in 55 minutes of “office”
meetings. Let’s repeat a
useful trinity from the beginning of this page. Go to
the actual place See the
actual problem Talk to
the actual people If you can’t
do this with the management then you are being stonewalled. Don’t worry, the management will be
surprised at the new found speed of problem resolution and will grow to like
it. Where does
this trinity come from? Well, I learnt
it from TQM but could never track the source down despite the smoking gun of
Ohno’s admonishment to stand all day until you understand the flow of the
process. It does, however, indeed come
from Toyota and is a verbalization of the Toyota principle of genchi genbutsu (31).
It is really an acknowledgement that the required knowledge can only
be gained tacitly rather than explicitly. We have seen
in the previous section the basics of drum-buffer-rope. In this section we have seen some
additional implementation detail.
However, there are some issues that need to be addressed further. Therefore, over the next 4 pages we will look
at; batch issues, quality, alignment, and the time required for implementation. Let’s have a
look at batch issues next. (1) Ohno, T.,
(1978) The Toyota production system: beyond large-scale production. English Translation 1988, Productivity
Press, pg 78. (2) Woeppel.
M. J., (2001) Manufacturer’s guide to implementing the Theory of
Constraints. St. Lucie Press, pg 87. (3) Deming, W.
E., (1982) Out of the crisis.
Massachusetts Institute of Technology, pg 327. (4) Goldratt,
E. M., (1990) The
haystack syndrome: sifting information out of the data ocean. North River Press, pg 131. (5) Caspari, J. A., and Caspari, P., (2004) Management Dynamics: merging
constraints accounting to drive improvement.
John Wiley & Sons Inc., pg 180. (6)
Schragenheim, E., and Dettmer, H. W., (2000) Manufacturing at warp speed:
optimizing supply chain financial performance. The St. Lucie Press, pg 124. (7) Stein, R.
E., (1996) Re-engineering the manufacturing system: applying the theory of
constraints (TOC). Marcel Dekker, pp
112-115. (8) Caspari,
J. A., and Caspari, P., (2004) Management Dynamics: merging constraints
accounting to drive improvement. John
Wiley & Sons Inc., pg 175. (9) Woeppel.
M. J., (2001) Manufacturer’s guide to implementing the Theory of
Constraints. St. Lucie Press, pg 140. (10) Cox, J.
F., and Spencer, M. S., (1997) The constraints management handbook. St Lucie Press, pg 86-87. (11) Umble,
M., and Srikanth, M. L, (1996) Synchronous manufacturing: principles for
world-class excellence. Spectrum
Publishing, pp 186. (12) Goldratt,
E. M., (1990) The haystack
syndrome: sifting information out of the data ocean. North River Press, pp 146-155. (13) Smith,
D., (2000) The measurement nightmare: how the theory of constraints can
resolve conflicting strategies, policies, and measures. St Lucie Press/APICS series on constraint
management, pg 67. (14) Smith,
D., (unpublished) Gain more speed and predictability through adequate
protective capacity. Chesapeake
Consulting Inc., 4 pp. (15)
Schragenheim, E., and Dettmer, H. W., (2000) Manufacturing at warp speed:
optimizing supply chain financial performance. The St. Lucie Press, pg 175-176. (16) Kawase,
T., (2001) Human-centered problem-solving: the management of
improvements. Asian Productivity
Organization, pg 111-119. (17) Umble,
M., and Srikanth, M. L, (1996) Synchronous manufacturing: principles for
world-class excellence. Spectrum
Publishing, pg 74. (18) Kanigel, R., (1997) The one best
way: Frederick Winslow Taylor and the enigma of efficiency. Viking, pp 141-142, 163-166, & 203-210. (19) Goldratt, E. M. (1996) Production the TOC way,
Tutor guide. Avraham Y. Goldratt
Institute, pp 46-48. (20) Goldratt, E.
M., (1990) The
haystack syndrome: sifting information out of the data ocean. North River Press, pp 88-89. (21) Cox, J.
F., and Spencer, M. S., (1997) The constraints management handbook. St Lucie Press, pg 90-91. (22) Stein, R. E., (1994) The next phase of
total quality management: TQM II and the focus on profitability. Marcel Dekker, pp 99-100. (23) Woeppel.
M. J., (2001) Manufacturer’s guide to implementing the Theory of
Constraints. St. Lucie Press, pp
128-129. (24) Goldratt,
E. M., (1990) The
haystack syndrome: sifting information out of the data ocean. North River Press, pp 130 & 129. (25)
Stein,
R. E., (1994) The next phase of total quality management: TQM II and the
focus on profitability. Marcel Dekker,
pp 92-99. (26) Stein, R.
E., (1996) Re-engineering the manufacturing system: applying the theory of
constraints (TOC). Marcel Dekker, pp
141-151. (27) Goldratt,
E. M., (1990) The
haystack syndrome: sifting information out of the data ocean. North River Press, pp 139-140. (28) Goldratt,
E. M., (1990) Essays on the Theory of Constraints, Chapter 3. North River Press. (29) Caspari,
J. A., and Caspari, P., (2004) Management Dynamics: merging constraints
accounting to drive improvement. John
Wiley & Sons Inc., pp 187-188. (30) Newbold,
R. C., (1998) Project management in the fast lane: applying the Theory of
Constraints. St. Lucie Press, pp
152-155. (31) Liker, J.
K., (2004) The Toyota Way: 14 management principles from the world’s greatest
manufacturer. McGraw-Hill, pp 223-236. This Webpage Copyright © 2003-2009 by Dr K. J.
Youngman |
