Introduction

In 2008, Dr. Eli Goldratt wrote his landmark article, “Standing on the Shoulders of Giants,” a history of production concepts versus production applications. In this article, Dr. Goldratt verbalized “the four concepts of flow,” based on the work of two industrial giants who came before him: Henry Ford and Taiichi Ohno. The article brilliantly explained the differences in conditions between the Ford and Toyota systems (stable environments) and the unstable manufacturing realities that drove him to develop TOC’s DBR (Drum, Buffer, Rope) solution.1

Dr. Goldratt concluded his article with a statement that the DBR application may not be adequate for all environments. DBR makes assumptions (sometimes hidden assumptions) about conventional production environments, and we should not expect the application to work in environments for which its assumptions are not valid. One of the primary assumptions of DBR is that product touch time is minimal (<10%) compared with the established lead time. This assumption is valid in many typical Make-To-Order (MTO) production environments. But, it is not suitable for a broad range of traditionally called project environments.  For these, Dr. Goldratt developed CCPM (Critical Chain Project Management). Over the years, the TOC community has also been introduced to the High Touch Time (HTT-DBR) application that deals with environments where some production processes are long and static (like metallurgy processes in the Steel industry).

In this article, I would like to share experience gained in a US$2 billion manufacturing company in Japan where reality forced us to add an additional layer to the original DBR application.  The company designs and manufactures technological system solutions for large markets’ industrial, financial, and public sectors. The demand for most products is non-standard (products are unique) and sporadic, and the lead times of components from international vendors can belong. In each work center (there are approximately 25 work centers), a team can work on several work orders simultaneously.

A work center in most production environments is a machine or a few machines, and in most cases, each machine is processing one order at a time. This is the environment assumed when DBR was created – each machine in each work center works in one order only. In our case, in each work center, we found that workers were using the space and equipment to process more than one order concurrently, sometimes working on two or three orders, but when the load (or the expected load) increased, this number could expand by two or threefold, causing much longer production lead time. This phenomenon can frequently happen in assembly plants, and therefore we believe a new, tailored approach should be developed.

We implemented TOC principles on one of the production lines by applying the four concepts of flow documented in the “Standing on the Shoulders of Giants” article:

1. Improving flow (or equivalently lead time) – is a primary objective of operations. We convinced the company’s management to focus on improving flow. The company set an ambitious KPI to reduce lead time by 20% within a six-month proof of concept period. The enormous positive impact of such an achievement on WIP, cash flow, level of service, and capacity is
2. Translate the primary objective into a practical mechanism that guides the operation when not to produce (prevents overproduction). Ford used space; Ohno used inventory; Goldratt used time. We prevented overproduction by choking the release of orders (limiting the allowed number of orders released) to the shop floor.
3. Local efficiencies must be abolished – Due to the limited time we had, the key measure we implemented was ensuring work does not start if a complete kit is not in place.
4. A focusing process to balance flow must be in place – due to the minimal time we had to prove the concept; we did not implement a balancing process apart from maintaining the order limits mentioned above.

The result was a reduction of production lead time by 40% in only four months!

The drastic reduction in lead time in the proof of concept drove the company to request the implementation of the solution for all production lines in the company.

During the detailed design of the complete solution, two new challenges emerged –

1. The need for a Dynamic Routing Mechanism. The company has approximately 25 work centers, and the routing of each product is set by client needs and is specific for each order (usually, this is done by ERP systems, but not in our case). We solved this by developing a dynamic routing solution in our software (not in the scope of this paper).
2. Realization of a fundamental difference in the production environment – such a difference that it called for a rethinking of the DBR application, adding a mechanism to bring the high results we expect from TOC solutions. It was clear to us from the beginning that the concepts of flow as defined by Ford, Ohno, and Goldratt are valid. We need to understand better the gap in the environment (mainly in the assembly plant) and stand on the “Giant’s Shoulders” to find the missing link.

 The difference in the environment

Although we followed the four concepts of flow when we implemented the solution, and despite the “too good to be true” results that we achieved in the proof of concept, there was constant pressure on the workers in the work centers to multitask. Rivers of words have been written about the devastating effect of multitasking on capacity. There are numerous group exercises that demonstrate that multitasking has a negative impact even on straightforward physical tasks. The practical question is, why does this happen, and how do we overcome it robustly?

The difference we found during the detailed solution design is not unique to this company. We believe that this is a generic phenomenon observed and verbalized by some of the leading forces of the TOC community over the last few years. Still, in this case, we had to address it and find a fast mechanism to solve it if we wanted to meet the very high expectations of the client.

A common explanation for the reason to multitask is the belief that “if I start early, I will finish early” by extension; if we start more, we will finish more. An even more common reason is the fundamental but false belief that multi-tasking by itself is more efficient, increasing the speed & capacity of workers. An additional phenomenon is “starvation” of work at a workstation. Employees at the station will start unnecessary work not to be seen as idle, thus appearing efficient in the eyes of their managers and peers. A worse version of this phenomenon is workers reducing the pace of their work not to be perceived as idle.

Mechanisms like full kitting are supposed to prevent these situations and prevent too much work from accumulating in a work center. But in our case, reality revealed that due to the buffer of work waiting before work centers, there was a tendency to “ease” the rules of full kitting and start more work. The core reason for the resulting multitasking is not the belief that starting early will produce more. Still, it is the devastating impact of the primary measurement on the production floor worldwide – Efficiency. This devastating shadow of efficiency is killing any genuine attempt to prevent multitasking. All operational levels (as opposed to top managerial levels, which are measured by overall organization effectiveness) are measured by efficiency measurements, and therefore, considerable pressure exists for multitasking.

The solution – application of DBR- Kanban  

TOC addresses unstable environments by using the concept of Drum-Buffer-Rope (DBR), where the bottleneck becomes the “Drumbeat” for order release. The ‘time buffer’ translates due dates into release dates and the action of choking the release becomes the ‘rope’ that ties the order to the release dates. But because this solution allows (and encourages) WIP to wait before some of the work stations (and always before the bottleneck), the pressure to work on more than the optimal resource allocation in specific work stations is enormous, and the path to bad multitasking is short.

The solution to prevent this was to go back in time and add, on top of the highly effective solution of DBR, an additional element in each work center that will solve this problem. We artificially constrained the number of orders in each work center available for processing. All the work orders for a specific work center arrive according to their routing, and the workers process them according to the same MTO priority system of colors. The only change is that the number of work orders “in process” for each work center is limited by the computer and is set according to the available resources and the optimal resource allocation in the work center.

Just as in a Kanban system, a new work order (according to the color priority) can be released from the waiting list to be processed only when a work order is finished. Like the original Kanban system of TPS, this method may need additional thought and tools for cases where the workloads in work centers are VERY different. Still, in most cases, the solution of DBR-Kanban will improve the flow and overcome the human tendency to multitask due to the wrong measurements. 

We believe that the best way to prevent overproduction and multitasking is by broad buy-in, education, and, most importantly, setting the correct measurements. But in production DBR environments, when in the work centers employees can work on several orders at the same time (such as in assembly plants), DBR-Kanban, aided by software, is the best method to improve flow and to prevent the human behavioral tendency to be “efficient” (and therefore, to multitask), and to hurt the effectiveness of the overall company.

 ___________

1) There can be confusion between the concepts of TOC and its applications. Dr. Goldratt uses DBR in the article, but DBR is a general principle derived from TOC thinking and concepts. The essence of the application was the one that is known as MTO (make to order). TOC has many additional applications using DBR concept such as CCPM (where you can find similar terminology as drum and buffer), but they are applied in different ways, and are therefore not identical in definition.