Theory of Constraints Production Drum Buffer Rope

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

A Motor For Production

Drum-buffer-rope is the Theory of Constraints production application. It is named after the 3 essential elements of the solution; the drum or constraint or weakest link, the buffer or material release duration, and the rope or release timing. The aim of the solution is to protect the weakest link in the system, and therefore the system as a whole, against process dependency and variation and thus maximize the systems’ overall effectiveness. The outcome is a robust and dependable process that will allow us to produce more, with less inventory, less rework/defects, and better on-time delivery – always.

Drum-buffer-rope however is really just one part of a two part act. We need both parts to make a really good show. If drum-buffer-rope is the motor for production, then buffer management is the monitor. Buffer management is the second part of this two part act. We use buffer management to guide the way in which we tune the motor for peak performance.

In the older notion of planning and control, the first part; drum-buffer-rope, is the planning stage of the approach – essentially the overall agreement on how we operate the system. The second part, buffer management, is the control system that allows us to keep a running check on the system effectiveness. However, I want to reserve the word “planning” and the word “control” for quite specific and established functions within the solution, functions that we will investigate further on this page.

I want to propose that we step out a level and instead use the terms “configuration” and “monitoring.” Using this terminology the configuration is drum-buffer-rope and the monitoring is buffer management. Let’s draw this;

The way that we configure the solution, the way that we configure the; drum, the buffer, and the rope, will determine the characteristics and the behavior of the system as a whole. Buffer management allows us to monitor that behavior. The use of the terms configuration and monitoring will allow a more critical distinction to be developed once we introduce the concepts of planning and control. This, I hope, will also clarify some of the confusion that may exist over the dual role of buffer management.

Keep this model in mind as we will return to it. Now, however, we must return to our plan of attack and work through the development of the solution.

Interested? Then let’s go.

Our Plan Of Attack

On the measurements page we introduced the concept of our “rules of engagement” which is to define; the system, the goal, the necessary conditions, the fundamental measurements, and the role of the constraints. Then on the process of change page we introduced the concept of our “plan of attack” – the 5 focusing steps that allow us to define the role of the constraints. Let’s remind ourselves once again of the 5 focusing steps for determining the process of change;

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

Let’s also return to our simple system model which we have so far used in much more general terms and apply it to drum-buffer-rope. As you will recall it has 4 sections, or departments or whatever you would like to call them; a beginning, a middle, a near-the-end, and an end.

Our system has to interact with the outside world, so let’s draw in an input and an output. Raw material flows in and finished product flows out. In a for-profit situation sales flow in and expenses flow out, the difference – profit, is captured by the system. We showed these flows previously in the section on measurements.

Now we are ready for the next stage, the first step in the 5 step focusing method – identify the constraint.

Identify The System’s Constraints

In fact we know where the constraint is in our simple system presented here based upon the discussion in the earlier section on measurements. It’s located near the end of the process. This isn’t at all an unusual place to find a constraint. Think about it for a moment. If the constraint was located near the beginning, then all the downstream steps would always be waiting for work. In that situation management would most probably go about purchasing further capacity until they move the constraint further down the process and then bury it in work-in-process so that it is no longer visible.

Let’s draw the constraint in.

As we know from the previous section on production, the constraint, the slowest step, beats out the rate at which the whole process can work at. Therefore it becomes the “drum” of drum-buffer-rope.

Of course we forgot something – work-in-process. If our model system is to be anything like our own reality, then it is probably full to the gills of work-in-process. We had better add this to our model as well.

Work-in-process of course serves a useful purpose in such a system; it decouples each stage from the stages before and after. If you don’t know what to protect, then you might as well protect everything. However chances are that, even with all that protection, the work that was required at the time wasn’t the work that was waiting in the pile of work-in-process. And of course it means that the time required for any job to traverse the system is much longer than necessary. In any case we don’t need all of that work-in-process anymore if we are going to use drum-buffer-rope.

So we have completed Step 1 – identify the constraint. The next step, step two, is to decide how to exploit the constraint.

Exploit The System’s Constraints

To make sure that the constraint works as well as possible on the task of producing or creating throughput for the system we must ensure that we exploit it fully – essentially we are leveraging the system against the full capacity of the constraint. This means not only making sure that it is fully utilized, but also making sure that the utilization is fully profitable. If you remember back to the P & Q problem or the airline analogy, is quite possible to have everything utilized but not make as much profit as is possible.

If we increase the output of the constraint, then the output of the system as a whole will increase also. One of the most effective tactics for exploiting the constraint, once identified, and improving its output is to write a detailed schedule for that particular resource and that particular resource alone – and then to adhere to that schedule. This is the “plan” in this context. Our day-to-day planning “falls out” as a consequence of the decisions that we make while configuring the implementation. Let’s add this to our model.

We now have a local plan for just one point, the most important point, the drum. If, at the same time, we hold the input constant then the additional output from continued exploitation must come from work-in-process already in the system. As a consequence work-in-process and hence lead times must go down. In effect we begin to drain the system. Let’s show that.

Let’s be clear however, work-in-process does not have to decrease under drum-buffer-rope, but usually there are sound reasons for doing so – reduced lead times, increased quality, and increased throughput. We will investigate all of these sometime later under the heading of the role of inventory. The primary objective of Theory of Constraints however is always to move the system towards the goal, and usually that means increasing throughput first. Inventory reduction is secondary and often a consequence of increasing throughput.

If we continue to operate in this fashion we can reduce work-in-process considerably. Let’s show this before introducing some further drum-buffer-rope concepts.

In fact we have completed the second step; we have decided how to exploit the constraint. We used a simple example of writing a schedule, there are many more ways to exploit a constraint and some of these are mentioned in the next page on implementation details. However, we need to move on to the third step, subordination of the non-constraint resources.

Subordination – Protect The System’s Constraints

Sometimes using the word “protect” makes it easier to understand this step than using the correct term which is “subordinate.” In fact, we subordinate the non-constraint resources in order to protect the constraint and the system as a whole. Let’s examine this is a little more detail.

In the process of change page we described subordination as avoiding deviation from our plan, and the plan in this case is our constraint exploitation schedule in the previous step. We described deviation from plan as (2);

(1) Not doing what is supposed to be done.

(2) Doing what is not supposed to be done.

We can therefore describe subordination as;

(1) Doing what is supposed to be done.

(2) Not doing what is not supposed to be done.

By doing what is supposed to be done in accordance with our plan we protect the constraint and the systems as a whole. Moreover, by not doing what is not supposed to be done in accordance with our plan we also protect the constraint and the system as a whole. Let’s examine this with our simple model.

As we use up our supply of excess work-in-process, it is likely that the constraints will begin to “starve” from time to time. Work will not arrive in sufficient time for it to enter the constraint on schedule. We need to replace our local safety everywhere (our excess work-in-process) with some global safety right where it is needed, in front of the constraint. We need to buffer the constraint. We need to do what is supposed to be done in order to protect the constraint from shortages.

In fact we would normally have made our buffering decisions before we even began and therefore reduced our work-in-process and lead time in line with these pre-determined targets.

An Initial Buffer Sizing Rule

Let’s assume for a moment then that the lead time allowed for work to travel from the start of the process to the start of the constraint was 18 days prior to the implementation. Well, in fact, it could be 18 hours for electronics or the paper work in an insurance claim, or it might be 18 weeks for heavy engineering. But let’s use days in this example. The rule of thumb to apply is to halve the existing lead time (3). Therefore the new lead time becomes 9 days. If halving the lead time sounds horrendously short, it is not. Most of the time the current work-in-process is sitting in queues doing nothing. You can easily check this for yourself – got out and tag some work with a flag or a balloon or a bright color and then watch it. It will sit. This 9 day period becomes our buffer length.

To this 9 day buffer we apply a second rule of thumb and divide the buffer into zones of one third each (4). We expect most work to be completed in the first 2 thirds and be waiting in front of the constraint for the last third of the buffer time. Thus we expect our work to take about 6 days of processing (and waiting-in-process) and 3 days of sitting in front of the drum.

If 3 days sitting in front of the constraint sounds terrible, then remember that prior to the implementation, the system allowed work to sit for at least another 9 days. Nine plus 3 is 12 days sitting. Which would you rather have 12 days or 3 days? More importantly, which would your customer prefer?

We now can protect our system constraint by ensuring that there is always work for it to do. Thus we ensure its effective exploitation – and with much less total material or lead time than before.

Let’s add the buffer to our diagram.

Let’s make sure we are clear about the definition of the buffer. “For all practical purposes the TIME BUFFER is the time interval by which we predate the release of work, relative to the date at which the corresponding constraint’s consumption is scheduled (5).”

Please be careful, on the diagram above we have drawn units of time – the zones and the buffer – as space on our diagram. Don’t let this confuse you. The zones equate to time allocated in the plant to protecting an operation whose position and function is critical to the timeliness and output of the whole process. The zones do not equate to the position of work in the plant. In fact we will return to this shortly and try and draw the diagram more realistically to represent time.

Why is this whole period from material release to the constraint considered as the buffer? Schragenheim and Dettmer consider that this is one of two unique aspects of buffering in Theory of Constraints. “The reason buffers are defined as the whole lead time and not just the safety portion is that in most manufacturing environments there is a huge difference between the sum of the net processing times and the total lead time. When we review the net processing time of most products, we find it takes between several minutes and an hour per unit. But the lead time may be several weeks, and even in the best environments several days. Consequently, each unit of product waits for attention somewhere on the shop floor for a much longer time than it actually takes to work on it.” “So it makes sense not to isolate the net processing time, but to treat the whole lead time as a buffer – the time the shop floor needs to handle all the orders it must process (6).”

The other unique point is that buffers are, as we have mentioned, measured in time. Firms in non-drum-buffer-rope settings consider a buffer to be a measure of physical stock; 6 jobs, or 6 orders, or 10 batches, or 4000 pieces, or whatever. In drum-buffer-rope a constraint buffer is a measure of time; hours or days of work at the constraint rate located between the gating operation (material release) and the constraint. In fact, there are two ways to look at a buffer, either from the perspective of a single job, or from the perspective of the system as a whole. Let’s consider this for a moment.

Let’s assume for the sake of simplicity that all of our jobs are of equal length. Let’s assume then that each one takes 1 day of constraint time. In this case each job has a 9 day buffer to the constraint. That is, it is released 9 days prior to its scheduled date on the constraint. This is the perspective of a single job. The constraint, looking back, will see 9 one-day jobs at various stages in the process; this is the perspective of the system as a whole.

What then, all else being equal, if all of our jobs now take half a day on the constraint? Each job sees a 9 day buffer, the constraint looking back will see 18 half-day jobs at various stages in the process, but the aggregate load is still 9 days, this is the perspective of the system as a whole.

Let’s do this one more time. Each job now takes quarter of a day on the constraint. Each job still sees a 9 day buffer, the constraint looking back will see 36 quarter-day jobs at various stages in the process, but the aggregate load is still 9 days from the perspective of the system as a whole. It is time that is the measure of the buffer.

Why Is The Constraint Buffer Size & Activity Determined By Time?

Let’s labor this point for a moment because it is so important. Measuring a constraint buffer in units of time is unique to drum-buffer-rope because acknowledgement of the existence of a singular constraint within a process is unique to drum-buffer-rope. We can apply this to both the constraint buffer size and the constraint buffer activity.

Let’s look at constraint buffer activity first.

By considering only one station, or step, or procedure, we need only to know one set of average times for that place or action for all of the different types of material units that pass through it. We could look at this as follows;

At a manufacturing constraint an hour is an hour but the number of units may differ

The number of physical units may differ because different types of material using the same constraint may use different amounts of constraint time. In fact, even the same type of material will display some variability unless the constraint is a totally automated procedure – but these will largely average out.

How about constraint buffer size then?

The unique perspective brought about by the designation of a singular constraint allows us to define the length of the buffer in time also. Essentially the buffer is sized and “sees” the duration from the gating operation to the constraint due date. Moreover the buffer “sees” committed demand – work that has already been released to the system. Constraint buffers, divergent/convergent control point buffers, assembly buffers, and shipping buffers are all of the same basic nature.

Maybe it is much simpler to say that;

We protect time (due date) with a time buffer

There is, however, one other buffer type that we are likely to come across in manufacturing – a stock buffer. There are two places that these occur at in manufacturing; they are at raw material/inwards goods in all process environments and at finished goods in a make-to-stock environment. These are actually supply chain buffers; they represent the two places that the supply chain must interact with processing – before the beginning of the process and after the completion of the process. We need to ensure that we always have an adequate supply of raw material prior to the process to meet consumption and we need to ensure that we always have an adequate supply of finished goods post-production to meet demand. We will examine these types of buffers later on this page. They are also examined in more detail on the supply chain pages – especially the replenishment page. However, let’s confine ourselves at the moment to constraint buffers. We need to labor the issue that the constraint buffer is a measure of time. Let’s do that.

A Journey Through Time

Many, many, people say that they do understand the definition of a drum buffer or of a constraint buffer when the evidence is that they do not. Too often our prior experience causes us to think of buffers in terms of physical stock, and too often we consider zone 1 as “the buffer.” Let’s see.

The buffer is the whole of the duration of the part of the system that the buffer protects.

Did I overstress the point? I don’t think so. Check here for more discussion on continual mis-understanding of buffers in drum-bufffer-rope.

In part, this is due to our prior manufacturing experience with MRP II systems and push production which tends to blind-side our interpretation (see the sections on Buffer The Constraint and Local Safety Argument in the next page – Implementation Details – for further development of this aspect.) In part, the problem also lies in the way we try to draw time as space on our simple diagrammatic representations. The only way to draw time is to draw a sequence of diagrams. Let’s do that.

We will follow a slice of work – ones day’s worth – through the process to the drum. We will use our 9 day buffer as we derived above, so this slice of work is the drum’s work for one day 10 days out from the scheduled processing date. There are 5 products (units, jobs, batches, whatever) in our slice. The products are “lilac,” “red,” “green,” blue,” and “orange.” The time interval, for the sake of clarity in this example, is course – days – rather than finer divisions of hours or less that we might expect to find in reality.

Imagine that within the departments (“beginning” and “middle”) of our generic process we have the tools of our particular trade; be they desks in a paper trail, admission or beds or clinical units in a hospital, or work centers in a manufacturing system. The 5 products could be at any time waiting or moving between jobs or being worked upon. The resolution of this detail isn’t important to us here.

Probably in the day before the release date the planner knows what will be released. The planner might even have the orders “cut” and waiting but unreleased (and hopefully unknown to the floor – to avoid people working ahead of time). Let’s draw this.

The orders may exist on a plan but they are not yet released. We draw the units outside of the system even if they currently have no physical presence other than paper work or an entry on a scheduling system.

We have also drawn a timeline in. It is colored according the buffer zones. Zone 3 is the “green zone,” zone 2 is the “orange or yellow zone,” and zone 1 is the “red zone.”

On the first day of the schedule all the products are released (as scheduled) and are in zone 3 of our time buffer. Their physical location at the end of the day is as follows.

Lilac might be small batch or a simple process that is completed quickly, it moves forward further (and maybe faster) than the rest.

After another day we are at day 2 and still within buffer zone 3 the process looks like this.

We can see that red has moved quite quickly relative to the others and blue hasn’t moved at all. How does this happen? Different jobs travel through different routings, and have different wait times (because of other jobs in front of them) and different processing times (either because of different batch size or different work). And of course sometimes things don’t always go as planned; we have break-downs, people are absent, and “stuff happens.”

By day 4, one day into buffer zone 2 we see the work has evolved as follows.

Blue still hasn’t moved, however, the others are progressing well.

The next day, day 5 (buffer zone 2), the work looks like this.

The green and red jobs are complete, the lilac and orange jobs are progressing well and blue is moving forward at last.

At the end of day 6 – the last day of buffer zone 2 we see the following.

Three of the five jobs are completed by the end of buffer zone 2, and two are lagging behind. Because the end of day 6 is the starting of day 7 and the first day of zone 1 (the red zone) we have a buffer penetration. Two jobs that ought to be finished by now have not been finished. They must be located and appraised to ensure that they will reach the constraint in the remaining time.

Let’s go out to the end of day 7 and see what happens.

Now 4 jobs have been completed. The lilac job was completed sometime on day 7. The blue job will have been located and checked to see that it will meet the schedule and be available at the drum by the end of day 9 – the last day of zone 1 – or preferably sooner. We would have preferred that most jobs were completed by the end of day 6, but sometimes “stuff happens” and not all jobs are complete at that time. The blue job might require some “assistance” to ensure its completion.

Let’s now look at the situation at day 8.

Phew! We find at the end of day 8 – with just one day to spare – that all of the jobs are completed and waiting to be processed on the constraint according to the schedule on day 10. Zone 1 – the red zone – of the buffer was penetrated by as much as 2 days by the blue job and as much as 1 day by the lilac job. However the drum is now fully protected and the drum schedule will not be compromised, our exploitation strategies are fully protected by adequate subordination of the other resources.

So, let’s reiterate once more; buffer zones equate to the time allocated in the plant to protecting operations whose position and function are critical to the timeliness and output of the whole process, buffer zones do not represent the physical location of work in the plant.

We know how to protect the constraint, now let’s see how to protect everything else.

Subordination – Protect Everything Else

So, we know now how to protect the constraint using a buffer, we therefore know how to do the first part of subordination – doing what we are supposed to do in order to protect the constraint. Now we need to examine the second part of subordination – not doing what we are not supposed to do.

First, let’s repeat the diagram that we first drew prior to our journey along the buffer.

The drum, gating operation, and shipping are all stable. That is they are now all operating at the same rate, the drum beat. If we were successful in exploiting the constraint and increasing the constraint rate and output, and demand increased as a consequence of the reduced lead time, then at this stage the input rate must be also be increased to match the drum beat so that work-in-process and the buffer remains stable.

In order to maintain stability in this system, the rate at which the gating operation allows the admission of new work to the system must be the same as the rate of consumption at the drum. What would happen then if our constraint breaks down for a short period? It has no spare capacity, so we can’t speed it up (allow it to work longer) to catch up to the work again. If we were to continue to admit work as though nothing had happened then work-in-process would increase a little. Probably not enough to notice, but over a couple of different instances it would begin to build up. Thus we need to make sure that we admit new work into the system at the same rate as the constraint is consuming it. The constraint as we know is the “drum” of our system, beating out the rate at which the whole system works, including the gating operation. The rate is communicated to the gating, or first, operation by the “rope.” We need to add this to our diagram.

If you like, the schedule of the gating operation is the schedule of the drum off-set by a rope length of time. The rope length is the same as the buffer duration; the gating rate is the same as the drum rate. “Tying” the rope between the drum and the gating operation ensures that excess work can not be admitted, or that normal work can not be admitted too soon. This is part of not doing what is not supposed to be done in order to protect the system from excess work-in-process. Excess work in process results in longer than necessary lead times and poorer quality. Ultimately excess work-in-process also impacts upon the throughput of the constraint.

Another way of looking at the rope is to consider it as a real time feedback loop between the drum and the gating operation.

Although the constraint can not recover from down-time, hence the need to exploit and protect it, the non-constraints can recover from down-time. Generally the non-constraint parts of our system don’t work at the same rate as the whole system – at least over short periods of time. The non-constraints have sprint capacity. They can and do process more work when necessary to catch-up after a “bump” in the system by operating at normal rates for longer periods. They can also process less work when not needed by operating at normal rates for shorter periods.

We might consider the increased duration of non-constraint processing (in order to catch up) as the “doing what is necessary” part of subordination, and the reduced duration of non-constraint processing (to avoid over-production) as the “not doing what is not necessary” part of subordination. It is critically important that we do this.

In the Toyota production system, kanban perform both of these functions. In drum-buffer-rope this is performed by the “roadrunner” concept. When we have work to do, we do it. When we don’t have work to do, we don’t do it. We saw this in the form of the traffic light analogy earlier in the page for process of change. Non-constraints should never “slow down,” they should either be fully-on or fully-off (maybe that should be normally-on or normally-off). Either creating throughput or protecting throughput. We will revisit this theme on the next page; implementation details.

We have seen how we now have 9 days of work in process in our example – down from the initial 18 days. There are 6 days of work in process in zones 3 and 2 and three days in zone 1. But we can think about it in another way. By halving the work-in-process we have removed 3/6ths of the work from the system. We have another 1/6th sitting in front of the constraint, so in effect we have just 2/6ths or 1/3rd of our previous work-in-process actually on the floor being actively worked on or sitting in queues. Imagine your process at it stands today but with just 1/3rd of the work actively being worked on by the non-constraints or waiting-in-process; wouldn’t things really begin to flow in that situation?

Nevertheless, in order for that material to flow, it is critically important to protect sprint capacity by proper subordination. Sprint capacity interacts with overall buffer size and hence manufacturing lead time. We will investigate sprint capacity more in the next section. Protecting sprint capacity means that we never admit work into the process just to keep people busy – never.

Of course you will have noticed that we have so far used the departmentalized version of our system model. To some extent this was intentional because when you first approach a drum-buffer-rope implementation, the process will be departmentalized. However, what we would like to see after a short while is a better appreciation of the system as a whole.

Conceptually it should look more like this;

Until now we have ignored that part of the process after the constraint – usually from the constraint to shipping in make-to-order, or to the warehouse in make-to-stock. This part of the process is tied to the shipping date by a second rope most often referred to as the “shipping rope.” It is via this rope that the drum is tied to the market demand. So now we can be sure that just enough new material is allowed to enter the system to protect and satisfy the drum consumption, which in turn supplies the market demand. We don’t admit work for which there is no demand. Therefore, we have indeed subordinated everything else to the constraint.

For the shipping buffer, we again apply the same rules of thumb as we used for the constraint buffer. Let’s assume, for the sake of the ease of the mathematics, that the process downstream from the constraint to shipping currently takes 6 days. We halve that to give us a new lead time of 3 days. And then we divide that into buffer zones of thirds and expect almost all work to be completed after 2 days and either waiting for shipment or already shipped 1 day prior to the shipping date.

This is what we arrive at;

Now our shipping date, or delivery date, is protected as equally well as the constraint is. We should therefore expect very good on-time delivery or due date performance. This of course is especially important for make-to-order firms and is most often a definite competitive advantage.

Thus our original 24 day process becomes a quoted delivery time of 12 days. The system should be able to produce more because we will have made every effort to exploit the constraint, and the non-constraints only work on material that is required to support the constraint schedule.

So, to summarize, subordination is the instruction to the non-constraints. It has two main components.

Firstly; in order to protect the system as a whole we must not starve the constraint – we must not underload the system. This will ensure maximal output as per the exploitation strategy of the constraint. Of course we could make the buffer quite large and never have to worry about starving the constraint, but that is where most systems are today (and they still starve the constraint). So we need to do something else as well. Secondly; in order to protect the system as a whole we must not flood the non-constraints – we must not overload the system. This will ensure adequate sprint capacity to ensure maximal output as per the exploitation strategy of the constraint and high due date performance. It will also ensure a much reduced lead time.

Thus we have covered all three aspects; the drum, the buffer, and the rope. We have also covered the first three steps of the 5 focusing steps; identify, exploit, and subordinate.

If we have fully exploited the leverage point, and subordinated everything else, then the next thing to do is to elevate the constraint. But first, let’s examine an alternative initial buffer sizing rule.

An Alternative Initial Buffer Sizing Rule

So far we determined our initial buffer sizes by taking 50% of the existing lead time over the part of the system that we wished to protect. There is another lesser-known rule that we can also use. We can take 3 times the back-to-back time for a job to transverse that part of the system that we wish to protect.

From time to time jobs are expedited for a number of reasons, therefore people will know from direct experience, or will have good intuition, for the back-to-back time and from that a buffer duration can be obtained.

Elevate The System’s Constraints

Elevation may require that some additional investment be made to purchase additional capacity that will produce additional throughput, preferably at more than pro-rata. Remember we are trying to decouple throughput from operating expense thereby driving productivity and profitability up;

We also know that elevation is most often the place where reductionist/local optima proponents start, however elevation is the place where systemic/global optimum proponents get to last. It costs you less doing it this way, of course you have to think – but then it’s just common sense – and you make more money or more output. If we don’t decouple throughput in for-profit organizations and output in not-for-profit organizations from operating expense and investment then we simply are not doing a very good job.

If A Constraint Has Been Broken, Go Back

If at any time a constraint is broken then we must look for the next constraint. In fact we should know from buffer management where it will be before we even get there. However, many times an initial physical constraint is broken and a policy issue takes its place. Goldratt’s admonishment not to let inertia become a system constraint is a plea to look at which policies block us from moving forward even further. Really this is a plea to Don’t Stop!

Some Definitional Subtleties

There are a few traps for those of us who are new players. Some of the definitions have changed over time. In this case to be forewarned is to be forearmed, let’s do that. Here we have used the term “drum” to describe the entity that determines the rate at which the whole system works – be that an internal constraint, or as we will see, an external market demand. However the term “drum” is also used to describe the drum schedule, in fact some insist that the drum is the schedule. Clearly when the constraint is in the market this definition makes more sense. Both are in use, some would argue that these different definitions are simply different manifestations of the same concept. If we accept this, then that ought to keep everyone happy.

Likewise, the “rope” has been used here to describe the off-set between the drum and the gating process; however, it too is subject to a more restrictive definition of the “gating schedule.” Once again these are different manifestations of the same concept. They are not mission critical.

Buffer Management – Make-To-Order

We have so far examined the development of the drum-buffer-rope solution – our motor for production – and we have done that within the framework of our 5 step focusing process. We also presented a model for the configuration and monitoring of this solution, to this we have added a local planning aspect; our schedule for the exploitation of the drum. Let’s repeat the model here and note that we are looking at the specific case of make-to-order.

We now need to develop the monitoring part of his model; we need to address buffer management. We now know what buffers are and we know their purpose, however we still need to know better how to interpret and utilize the information that they can provide. And in order to do that I believe that we must subdivide their impact into two distinct functions. They are as follows;

(1) Local Control; the day-to-day exception reporting that indicates when there may be a potential due date violation.

(2) Global Feedback; longer term trend-reporting that suggests a particular buffer needs to be resized to be fully effective.

Buffer management is crucial; it filters important signals from the day-to-day noise of the system thereby alerting us to potential problems before they become real problems and it provides a self-diagnosis that neither too much and nor too little protection is made available for each case. The self-diagnosis feeds back into our configuration and guides improvements in the overall dynamics of the implementation.

Let’s modify our model to incorporate this.

Thus we still have planning and control, but it is local and within the context of the overall design of the implementation. Schragenheim & Dettmer have an important definition of control, lets repeat it here (7);

“A reactive mechanism that handles uncertainty by monitoring information that indicates a threatening situation and taking appropriate corrective action before the threat is realized.”

The subdivision of buffer management into local control and global feedback will, I hope, make it easier to understand this important concept.

Let’s now investigate the various stages of local control and then global feedback in a make-to-order environment.

Local Control – Buffer Status

We release work a rope length ahead of the due date at the point that the buffer protects. In most cases that is more than sufficient to insure that the work arrives in good time. But as we know sometimes stuff happens. We need some local control to ensure that when stuff does happen we know the correct priority to return the system to one of stability. We need to know the status of the current make-to-order work orders that are already released to the system to be worked upon.

Schragenheim defines the buffer status as follows (8);

Buffer Status = (Buffer Duration – Remaining Duration) / Buffer Duration

The buffer status is synonymous with buffer consumption.

Let’s look at an example. Here we have the buffer status for 6 jobs due in the next 5 days.