Eliyahu Goldratt developed different methods on how to manage production systems. These methods are nowadays known as the Theory of Constraints, or TOC for short. One key method described is called Drum-Buffer-Rope, or DBM for short. Similar to Kanban or CONWIP, it aims to constrain the work in progress (WIP) in the system. There is much discussion on which method is better than the other, although the result often depends heavily on with which method the respective author earns its living. In this post I will present how Drum-Buffer-Rope works, and discuss its advantages and shortcomings.
Details about Drum Buffer Rope
Where the method came from
Drum-Buffer-Rope originated with the famous book by Goldratt “The Goal“, although it got its name only later in “The Race“. In “The Goal” Goldratt combines management science and romance novel. As a romance novel, the story is mediocre. As a science book, it is a nice collection of general wisdoms and good suggestions. In combination it was a bestseller, since it is one of the few management science books that almost everybody can understand. (However, in my opinion a much better production-management – novel – cross-over is The Gold Mine: A Novel of Lean Turnaround by Freddy and Michael Balle)
The Boy Scout Example in The Goal
A very illustrative example was how the protagonist of the book manages a boy scout outing, especially how to keep the group together while different boys walked at different speeds. The solution was to put the slowest boy scout Herbie at the front, and prohibiting all others from overtaking him. Additionally, he lightens Herbie’s backpack so that he can walk faster.
How Drum-Buffer-Rope Works
Taking these boy scouts as an analogy for a factory created the Drum-Buffer-Rope method. The drum is the bottleneck, defining the overall speed of the system. The system cannot go faster than the drum.Pretty much all sources on Drum-Buffer-Rope agree on that.
As for the buffer and the rope … well … that is where it gets a bit fuzzy.
Drum-Buffer-Rope for People
Many sources take the example of the boy scout literally. The drum is the slowest person. The rope extends to the first person in the line, which cannot walk faster than the drum. The buffer is the free space between the drum/bottleneck and the next person in front of him, allowing him to walk even if the next person is temporarily slowing down (for example to tie his shoe laces)
This may work for people, but it needs a fair bit of imagination to extend this version of Drum-Buffer-Rope to manufacturing systems. You have to remember that the people in this example are the processes, not the parts. The parts are actually the ground covered. In the image above the people walk from left to right, but the ground covered (the parts processes) would move from right to left. Hence, it looks more like the image below.
Therefore, let’s take this example and put it in a proper manufacturing setting.
Drum Buffer Rope for Manufacturing Systems
In manufacturing, the drum is still the bottleneck. The buffer is the material upstream of the bottleneck and has to make sure that the drum is never starved. The rope is a signal or information from the buffer to the beginning of the line. If the drum processes parts, the buffer moves forward. The rope is a signal when material is taken out, and gives an information to replenish another part at the beginning of the line as shown in the Illustration below.
Signal when material is taken out … information to replenish … I have heard something very similar before … Kanban! Yes, Drum-Buffer-Rope is similar to Kanban with the supermarket before the bottleneck. Whenever a part is taken out of the buffer/supermarket, a signal is sent via the rope/kanban to the beginning of the line/kanban loop to replenish material. A Drum-Buffer-Rope system as shown above is very similar to a kanban loop as shown below.
However, there are some differences which I would like to go into some detail below. But before that first for completeness sake another variant of Drum-Buffer-Rope, the Simplified Drum-Buffer-Rope:
Simplified Drum Buffer Rope (S-DBR)
Simplified Drum-Buffer-Rope is very similar to Drum-Buffer-Rope. The key to simplifying the approach is the assumption that the market or the customer is the largest bottleneck. I.e. in average your system always has enough capacity to satisfy demand. The rope then spans the entire length of the system.
Good Things about Drum Buffer Rope
Drum-Buffer-Rope has some underlying good ideas.
Prevents Overloading of the System
Most importantly, it does try to constrain the work-in-progress and aims to prevent an overloading of the system. As such it can be considered sort of a pull system like Kanban or CONWIP, and hence Drum-Buffer-Rope is superior to the traditional push systems.
Furthermore, the WIP in Drum-Buffer-Rope fluctuates less than with Kanban. A Kanban system defines the number of Kanban, which consists of the WIP, the supermarket stock, and the kanban without parts. Drum-Buffer-Rope (like CONWIP) is more precise as it limits only the physical parts (WIP and Stock), but dose not include the variation through fluctuation of kanban without parts.
Measuring Workload in the System as Time
Another good thing about Drum-Buffer-Rope is that it measures the work in the system not in pieces, but in time. Depending on how many hours worth of work are in the system the rope may release another part in the system.
In comparison, a Kanban system usually only counts pieces. In my view, counting pieces is fine if the pieces are similar, as in mass production. Measuring the workload in time may be beneficial if the items to produce have vastly different work content, as for example in a job shop. However, measuring time is also more difficult, as you need to determine the time for each product rather than merely counting them. In any case, a Kanban system can be adapted to measure time if needed, resulting in the same complexity as a Drum-Buffer-Rope system.
Flaws and shortcomings of Drum Buffer Rope
In my view, however, Drum-Buffer-Rope does have quite some shortcomings. For my daily work I therefore much prefer a Kanban system.
No Consideration for Shifting Bottlenecks
One of the major underlying assumptions of Drum-Buffer-Rope is the assumption of a fixed bottleneck. I.e. the bottleneck does not move. If the bottleneck shifts, then the drum is in a different place over time, which makes Drum-Buffer-Rope more difficult.
Goldratt claimed that in his experience this was not a problem in practice. However, Goldratt claimed many things if it benefited him. For example he claimed that his software MARS was able to find the optimal solution, until a judge ordered him to stop (He then rolled out hsi next software package with the most unfortunate name DISASTER).
In my experience, shifting bottlenecks are not the exception but the norm in most manufacturing systems, and simply assuming a fixed bottleneck will lead to problems. This problem may be confounded that his Theory of Constraints does not offer any good approach to find the bottleneck (see also my methods Bottleneck Walk and Active Period). Of course, increasing buffer sizes will lead to less shifting, but increasing buffers has a lot of disadvantages by itself.
Drum-Buffer-Rope considers only Starving of the Bottleneck, not Blocking
Drum-Buffer-Rope explicitly places a buffer in front of the drum to prevent starving. I.e. the buffer prevents the drum from running out of material. However, it completely omits the possibility of the drum being blocked by a downstream process, which may equally lead to bottleneck downtime. While the buffer after the bottleneck is usually near empty, it is necessary to provide the space in case a downstream process acts up and blocks the bottleneck.
To be fair, some sources of Drum-Buffer-Rope have recognized this problem and introduced a space buffer after the drum, although many other sources still omit this.
Only the Upstream Inventory matters in Drum-Buffer-Rope
Drum-Buffer-Rope controls not only the buffer in front of the drum, but the entire inventory upstream of the bottleneck. However, little or no consideration is given for the downstream inventory, not only the buffer immediately afterwards, but the entire value chain to the customer. Hence, the inventory is not limited and under the right circumstances can still lead to overproduction. Combined with shifting bottlenecks it is almost certain that the downstream inventory will at least temporarily spiral out of control.
Which Part to Produce next?
A Kanban pull system not only constrains the total inventory, but also helps deciding which part to produce next. In the simples case it is merely the next Kanban waiting in line that is produced. Hence at least for high-runners it is clear what to produce next. Drum-Buffer-Rope does not really offer much guidance. If there are multiple product variants in the system, Drum-Buffer-Rope leaves more decisions to humans with all its flaws. For example the bullwhip effect may lead to overproduction of some parts while others are short in supply.
Limited Flexibility in Line Management With only One Loop
Drum-Buffer-Rope has only one major loop between the bottleneck and the first process. However, there are many good reasons why you may want to use more than one loop, as for example differences in cycle time, merging or splitting material flows, or system boundaries. For an entire list see my Ten Rules When to Use a FIFO, When a Supermarket.
Hence, with Kanban the system is better controlled and maintained, whereas with Drum-Buffer-Rope some parts of the system may escape notice, while the other part is thrown together simply based on the (presumed) location of the bottleneck.
Popularity
Just out of curiosity, i also checked how popular Drum-Buffer-Rope was over time. Below are the percentages of books that mention either Drum-Buffer-Rope or Eliyahu Goldratt over time. It seems both terms started around 1980-1985, peaked around 2000-2005, and are since in decline. In comparison, the term Kanban is about 80 times as popular as Drum-Buffer-Rope, and with no significant decline.
Summary
Overall, i find a Kanban system (or alternatively a CONWIP system) much preferable to a Drum-Buffer-Rope approach. Both approaches have its merit, but I find Kanban much easier to use and less troublesome than Drum-Buffer-Rope. Another problem I faced when researching Drum-Buffer-Rope was that it was sometimes explained differently
The academic community seems to be split here in two camps. One side that reveres Goldratt and his methods, and the other side that tries to ignore him unless they criticize his ways. He did have a knack of making things easy to understand, but he was less skilled in giving credits to previous sources, while his methods often fall far short of his claims.
Overall, if you need to get on top of a manufacturing system that is out of control, a Kanban or CONWIP based pull system will probably give you faster and better results than Drum-Buffer-Rope. Now go out and Organize your Industry!
SOLD!! Earlier in my career I was entranced by TOC – the idea of the bottleneck is so elegant. Now I am learning about the Lean world, and this article has convinced me to put TOC on the back burner. It tool someone with real understanding to write this article.
Many thanks! Goldrath went in the right direction, but lean is much better 🙂
Hi there! Is it Goldratt or Goldrath? The spelling in the title or the content should be aligned, I think. 🙂
Dang, you’re right. It is Eliyahu M. Goldratt. Thanks for spotting that mistake!
There has been quite a lot of development in the TOC community beyond what Goldratt wrote and I think some measure of consolidation in that body of work. See https://www.tocico.org/default.aspx and https://tocpractice.com/. More importantly, TOC concepts apply to endeavors well beyond the production floor and are typically combined with LEAN, Agile, etc. as appropriate. I’ve not seen a need for TOC consultants to wall off other improvement opportunities.
Downstream cannot overproduce in a DBR setup when the bottleneck is feeding it. In case there is a separate line merge downstream, then DBR could be setup on that merging line separately.
The main advantage of DBR is that it lets the operations deliver near max Throughput with min WIP (in the Throughput vs WIP curve). This is made possible by buffering the variation of flow into the bottleneck and letting the bottleneck operate at near 100% utilisation.
True, if the bottleneck does not move. Unfortunately usually they do shift. Artificially fixing the bottleneck usually means waste elsewhere, which in my experience offsets the benefit of DBR.
I don’t think that any methodology is the only solution to every problem. ToC is simply the best starting point. For example, when trying to determine the constraint(s), significant enough variances in capacity between the bottleneck and the other work centers would lead me to using DBR, whereas insignificant differences would lead me towards a more Kanban approach as the bottleneck (s) would more likely move around. I see ToC as more of a prioritization tool overall, then I react accordingly.
Hi Jake. Is ToC truly the best starting point? I do a lot of bottleneck related research, but for example bottlenecks are a bad starting point if you have quality problems.
However, if it works for you, go for it!
Existen fórmulas para parametrizar el time buffer y el rope?
Estamos en un problema de DBR y cuellos de botella móvil ocupamos ayuda
Hi David, don’t use DBR, use Kanban instead. Also, I don’t speak spanish.
Interesting read, I was a Toyota employee for several years and am pretty familiar with the KANBAN methodology…I agree with you that it is a simpler system to implement…however…
Once there is a good system process defined….it is advantageous to implement DBR to further improve flow….the bottlenecks may jump slightly…which is normal..as the current bottlenecks are eliminated…more will occur…it’s natural…you should never stop improving the system. I would suggest hiring a good TOC consultant to implement DBR….I know of 2 or 3 that have made a huge difference at multiple companies…
Hi Matt, the problem I see is that in a good system, the stations are usually well balanced, and hence the bottleneck shifts quite a bit.I also observed many, many (good) lines with highly shifting bottlenecks. Hence, I advise against the DBR.
Balancing a system where interdepedence and uncertainty is reality then the system is out of control. Kanban is a way of adding capacity to systems that are inherently unbalanced. A bottleneck may shift some times but not contsantly. That is why the 5 focusing steps are applied. The problem is that every industry wants to cut costs and therefore tries to reduce capacity at no bottleneck stations. If you want on time delivery you need spint capacity. Lastly the fact that that TOC is less referred as does LEAN οr MRP is due to the fact that there is no big company like TOYOTA to back it up. Furthermore traditional costing still thrives. Does it mean it is correct?
Hi.
Some misunderstandings about DBR:
– the buffer is the time from the release until the constraint. Not the accumulated work in front of the constraint.
– shifting constraints can be handled easily with sDBR (CCRs) see Eli Schragenheim’s work on this
– DBR controls WIP before and after the constraint. And allow up to 3 ropes. sDBR controls everything with one rope
– There is also the scheduling of release done by DBR that follows the algorithms laid out in The Haystack Syndrome
– there is no mention os priorities nor POOGI in the text
Etc.
Despite any shortcomings Eli Goldratt may have, representing poorly the tools developed by him and others does not give enough credit to the proper sources nor value to the readers.
The missing ingredient in this discussion seems to be method/context fit. All of these methods have worked from someone, the question is which method is best for which context, and how should we characterize the relevant aspects of the context for making the decision.
For example, a high growth context might favor DBR with an intentionally unbalanced line to prevent unexpected constraint shifts because it responds better to increasing demand and Lean/Kanban might be better in a stable/low growth situation where the cost savings from balancing capacity are significant enough to justify the increase in management attention required to keep the line balanced when the unexpected happens.
Perhaps, some framework that includes level of variability in demand, product mix, quality, rate of product changes might help everyone focus on choosing the right method for the right context.
Hello Humberto and Alex, thanks for the input. Learned some new things (e.g. I have not heard of POOGI before). Nevertheless, i continue to believe that DBR is inferior to other pull systems (a view also shared by other researchers – but of course not all). Nevertheless, if it works for you, keep on using it.
TOC was a great concept if you wanted to micromanage one part number in your manufacturing process, but I don’t know a company in the world that only has one part number on the manufacturing floor. As soon as you have multiple top and sub assemblies TOC can get out of control. Kanbans are much better to create flow on the floor. That is my humble opinion.
Hi Michael, actually, TOC and DBR is supposed to measure the workload, and hence should work even for make-to-order production or generally for high mix low volume production.
As Joe Magid says above, the Theory of Constraints (TOC, DBR) and LEAN have been combined with Agile and other systems to address the development of software. How are these theories ill equipped to apply to software – both software products and when software is provided as a service (SaSS)?
I ask as a practitioner who has readily embraced these methodologies and seek wisdom where I can.
The theory of constraints is mostly used for manufacturing, where many processes are in sequence. For software development, you can have processes in parallel. In this case the critical path in a Gantt diagram may be more helpful.
TOC has its uses (I published quite a few academic papers on bottlenecks myself) , but DBR is in my view flawed.
Jeff/Christoph,
Critical Chain Project Management (CCPM) was developed starting from the TOC, and it’s about how to manage projects considering the real life constraints and therefore using a finite capacity approach and the concept of buffers.
Hi Paolo, knowing the bottleneck and working on improving it is a important point if you are short on capacity. But the bottleneck has very little relevance for the setup of a pull system, even if the bottleneck would not shift.
A fundamental of DBR. The issue of POOGI is not the improvement process itself, but rather how improvement priorities are clearly indicated by buffer zoning (eg Green, Orange, Red,) in front of the drum. Analysis of the data collected upstream by the Supervisor when orange is activated, points to the next potential constraint(s) – without delaying the drumbeat.
Small statistical fluctuations upstream are buffered by the green zone.
Kanban does not provide this improvement focus.
DBR also allows for a significant upstream decrease in WIP, so reducing lead time with all the related benefits.
POOGI is a bit ill defined. It is called improvement, but seems to be a form of prioritization. Both are just causes, but both of which which could also easily be done in a Kanban system. In fact, both kaizen and prioritization are often part of a kanban system.
Based on my sources I also doubt that DBR by itself reduces WIP more than kanban due to the limitation of DBR on the drum being bottleneck. If DBR works for you, keep on using it, but I much rather prefer any of the other ways to do pull.