SPECIFIC TOC TECHNIQUES Four specific TOC techniques are described in this chapter.

1. Shop floor planning method

2. Control system

3. Multiproject planning and control method 4. TOC management accounting approach

All these methods lend themselves to programming. Additional impacts of TOC have been added to other chapters. The Management Interactive Case Study Simulator (MICSS), a CD-ROM that accompanies this book (see back cover) can be used to get a

glimpse of the analytical power of TOC when applied to a typical, though small and simple, virtual manufacturing company using a simple ERP system.

TOC emerged from the shop floor. It is not surprising that the first TOC technique was directed at the shop floor. The Drum-Buffer-Rope (DBR) methodology is a shop-floor planning scheme that has replaced the OPT method on how to schedule the resources. Later, a control methodology called Buffer Management was developed to complement the planning mechanism. In the 1990s, a parallel effort was carried out to develop a TOC methodology for project management, called the critical chain. This methodology was expanded to project management the TOC way. The most important of all is the unique way TOC is treating the global financial measurement and its impact on management accounting. A TOC methodology for distribution networks was developed to establish a better solution that reduces both the overall inventories in the network and shortages, improving the service level as well as sales. The distribution solution is now developed into comprehensive supply-chain approach. A description of the distribution the TOC way appears in Chapter 11.

All basic TOC techniques can and should be part of any ERP package. Their description in this and other chapters should give a pretty good idea of the rationale and what features should be required from an ERP system to support implementation in the TOC way. As noted before, an alternative can be to add external modules to support the holistic approach. Obviously, the best solution is an integrated system.

The DBR Technique

What Should Dictate the Pace of Production?

TOC is looking for the weakest link in the chain. Let us first look only at the internal chain. The sequence of operations uses internal resources to turn raw materials into finished products. Later, external variables, such as market demand and availability of materials, should be considered as well. That weakest link of the internal chain defines the maximum possible output with the current resource availability. The reader might argue that many manufacturing floors resemble a net rather than a chain. When we speak about the weakest link in a net, we may find that in a net more than one weakest link can be found—each of those links imposes a practical limit to the output of the whole system. Only a very few weak links can be found in any net. In the shop floor the links are actually resources. Only very few resources, usually just one, put a true limit to the production pace. That means that any realistic planning should focus on that resource that lacks capacity the most. The rest of the system has excess capacity that helps to keep the planning of the critical resource intact.

When the market demand is lower than the capacity of the critical resource, the pace of the whole system should be fully dictated by the market demand. When the demand approaches the limit imposed by the most loaded resource, that particular resource becomes a capacity constraint resource (CCR). It is the balance between the demand and the CCR that dictates the actual pace of the system.

Sensible planning of the shop floor must adhere to both the market demand and the capacity of the CCR. This planning of the output of the system is called the Drum. The

name is taken from a great story in the The Goal, Dr. Goldratt’s first and most famous book. The name implies something that sets the rhythm for the whole system. The combination of the market demand and the limit imposed on the system by the CCR, leads to realistic planning of the CCR and its output.

The Drum must be protected from Murphy’s Law (whatever can go wrong will). Theoretically, all the other parts of the system have enough flexibility to support the Drum because of their excess capacity. However, temporary peaks of load and incidental delays may interfere and waste the precious capacity of the CCR or simply cause a shipment to miss the due date. In order to protect the CCR and the commitments to the market, a protection mechanism must be established. This is called a buffer. The TOC notion of a buffer is somewhat different than its common use. A buffer, according to TOC, is designed to protect only the critical areas, the areas that control the performance of the whole system. In the TOC terminology, they are the physical constraints of the system.

In a make-to-order environment the buffer is expressed in time units and is called time- buffer. Releasing the materials with time ahead of the planning for the CCR and/or delivery dates provides the necessary protection against uncertainty (Murphy). Once the materials are released they should flow as fast as possible in order to reduce the chance of missing the schedule of the CCR or delivery to the customer. The time-buffer is used to schedule the release of materials and to properly schedule the CCR. As the time-buffer takes into account the possible occurrences of delays, it should be longer than the average lead-time between the material release and the protected area. Most of the material will arrive to the protected area some time before its actual use. Some inventory is likely to pile up at that area. Note that this is different than a planned level of stock. It is not an inventory buffer. The protection is dependent on the time allowed for a batch of parts to go through a sequence of operations (maybe through several levels in the bill of material [BOM]). Since the time estimate contains safety time, some in-process inventory is accumulated in the queue of the CCR.

In order to support the proper flexibility of the nonconstraint resources, no material is allowed to be released to the floor prior to the time determined by the Drum minus the buffer time. This is called the Rope—a mechanism that guards that no materials will be released before the scheduled time (which already considers the amount of uncertainty). Implementing the Rope means to knowingly underutilize the resources that are non- constraints (having excess capacity). TOC logic points out that there is no point to fully utilize resources that have excess capacity.

Figure 2.1 describes the main planning mechanism. The due dates of the customer orders constitute the MPS. These shipping requirements are first scheduled on the CCR. The scheduling algorithm tries to keep the full shipping buffer intact (5 working days in the example) for the last part of the order completed by the CCR. Because of the limited capacity of the CCR this cannot always be achieved. In this particular schedule, Order 1 and Order 5 were grouped together to save setup time. This grouping caused

Figure 2.1 The DBR planning essentials.

Order 5 to be processed much earlier than required for the downstream operations, but because of lack of capacity this was found to be the best solution. Once the schedule for the CCR is done, the material release schedule (MRS) is constructed so the released parts would have the full CCR buffer time (10 days in the example) to go through the upstream operations to the CCR. Note that no schedule is provided for Ml, M2, and M4 in the example.

In the DBR methodology, buffers are also used at assembly points where parts that go through a CCR are assembled with parts that do not go through a CCR. These buffers actually protect the delivery dates by allowing the Rope to schedule the appropriate time for those items that are assembled with CCR parts. The items that go directly to the CCR and/or the shipping area (meaning no CCR operations for that product) are scheduled by the Rope using the shipping buffer or the CCR buffer. The full buffering structure is described in Figure 2.2. Material-constraints

Figure 2.2 The full buffering system for DBR.

only exist in rare cases. Most of the time we expect that proper planning of the purchasing side will not allow stock-outs to choke the CCR or the commitments to the market.

An important point in describing the DBR methodology is to emphasis that it is very different from the advanced planning and scheduling (APS) modules. It is certainly the simplest APS in the market. This characteristic of TOC is one of its greatest assets. In a complex environment, and with a lot of uncertainty around, only simple processes can really work. The position of TOC regarding optimization is that the system can be optimized only up to the natural noise of uncertainty. As the level of uncertainty is fairly high in the vast majority of the organization, not much good can be achieved from oversophisticated algorithms. Please note that this conclusion arrived at by Dr. Goldratt is the result of developing the OPT package, certainly one of the more complex algorithms for finite-capacity scheduling.

DBR is certainly different from material requirements planning (MRP). First of all it does consider finite capacity within the planning. It does not use lead-times between any levels in the BOM. Instead it uses time-buffers to cover all the way from material release

to the CCR and from the CCR to completion. While the concept of the time-buffer is similar to the MRP concept of lead-time, the actual use is quite different. DBR strives to have the MPS as simple as possible—only the shipping dates of the firm orders are required. Recognizing that make-to-stock is quite necessary, DBR has been adjusted to deal with stocked products. This is described in Chapter 8.

What is the impact of DBR on the information system? Certainly a production manager who believes DBR is the right planning scheme would like the ERP package to support the DBR logic. In itself it is not too hard to maneuver MRP to imitate DBR. The real difficulty is to integrate the control mechanism of TOC, called Buffer Management, with the DBR planning within an MRP software module. The other difficulty is to sustain the understanding of how such a simple mechanism is able to produce a realistic schedule and at the same time draw the maximum capacity from the system when the market demand requires it. DBR actually provides a protection mechanism against fluctuations and Murphy.

DBR makes a clear distinction between planning and execution. DBR actually plans only a part of the whole system and leaves the other part to react to whatever is happening on the floor. DBR may schedule few resources that are CCR’s, and it always schedules the material release where the schedule means never before time. True DBR does not schedule the non-constraints, not because it cannot do finite-capacity scheduling, but because this is the wrong thing to do as uncertainty is bound to disrupt all this planning anyway. The right way to plan is to schedule in detail only the material release and the CCR’s activities. Such planning that is protected by the buffer has a very good chance to be executed as planned.

Buffer Management—A Unique, Simple, and Effective Control Mechanism TOC uses time-buffers as a protection mechanism against common variations of uncertainty, but they are not enough. There is a need to identify problematic situations and respond with corrective actions. Buffer Management is a true control mechanism. The point of controlling the execution is not to gather data for comparison between the actual state and the planning. Such a mechanism processes and stores huge amounts of data and the ability of the manager to draw a clear conclusion is diminished. An effective control system should provide a reactive mechanism to handle uncertainty by monitoring information that points to a threatening situation then recommends taking corrective actions accordingly. If an order was supposed to be processed on Wednesday and was actually processed on Friday, this is probably only one small detail that adds nothing to the execution of the planning. If it is very important that every order will be shipped on time, then in the vast majority of the cases work should be completed a significant amount of time before the actual date. When most of safety time has been exhausted, only then is there a need to be worried.

The kernel of the idea behind the Buffer Management is to monitor the cases when the protection mechanism is nearly exhausted! Buffer Management looks at the areas protected by a buffer. It focuses on those incidents where most of the buffer has been used and then gives the almost late orders high priority, which can be translated to expediting. Of course, expediting should be done only sparingly, otherwise it has no

value.

Let us illustrate the Buffer Management activity. Suppose an order is due on 2/28. The materials are released on 2/14, assuming an average lead-time of a week and a maximum of 2 weeks considering the uncertainty. When should the production manager’s attention be attracted to that order? Certainly on 2/21 it is too early to react. On the other hand the production manager should not let the order sit unnoticed until the due date. If something has happened, like a human error, a temporary peak of load somewhere, or any other reason for delay, there should be some attention at a time when it is not too late to take an action and expedite that order.

The Buffer Management methodology speaks of three zones of the buffer. The earliest zone is where we do not really expect the order to show up at the protected area. This is the ignore zone, sometimes referred to as the green zone. The next one, called the monitor zone or the yellow zone, calls attention but no reaction as there is still enough time to expedite and it might not be needed. The most important zone is the emergency zone or the red zone. Here there is a need to react or the order will be late.

In the above example, we have a buffer of 10 days that includes all the operations from material release to the shipment without any CCR on the way. This maximum lead-time estimation of 10 days is divided into 3 parts. The first 4 days are certainly the ignore part. After all, there are several operations to be done. The next 3 days are the monitor zone. Most of the orders will be completed at that time. If an order is not completed within both previous zones, it should be located and expedited.

The time-buffer that is attached to the DBR planning methodology includes the net processing time. In a manufacturing environment the net processing time is a very small part of the actual lead-time. As a matter of fact, the time-buffer is a careful estimation of a fairly long lead-time to move the part from one protected area (the stockroom) to another protected area. The difference between the time-buffer and the lead-time in the MRP methodology is that MRP lead-time is defined for every level in the BOM, while TOC-buffer is defined for all the way from the material release area to the CCR or the shipping dock. In addition, Buffer Management suggests a practical way to control the smooth execution of the plan is to concentrate only on the exceptions—those orders which penetrate into the emergency zone or the red-line. Note that every operation in the shop floor is directed at one buffer, the CCR, shipping, or assembly. The buffers encompass the whole floor.

Buffer Management gains a lot from a computerized program. As a matter of fact, it is fairly easy to develop such a program. Search for the orders in the emergency zone, explode the bill of that order, and identify the resources where it might reside. In a shop floor that has online data retrieval, the exact location and work-order ID can be immediately traced. In other cases, the work orders should be identified and located. As a matter of fact, in a fully manufacturing execution system (MES) computerized shop floor, the foreman can get a sorted list every day of all the pending orders with their relative penetration into the buffer they feed. It is possible to know in advance the needs of the constraints and be able to organize the load much more effectively even when no formal sequencing is done for this work center. This aspect of Buffer Management is further discussed in Chapter 10.

for data accuracy, the data regarding setup and processing times are too dynamic to be measured properly. Any change in the engineering might change the timing. Many in situ improvements are done. Setup and processing times are very difficult to measure accurately because the operators are reluctant to be measured so precisely. Standard times cannot be accurate by definition—we have to live with less-than-perfect data accuracy on the shop floor. When we take into consideration the need to maintain a certain amount of excess capacity (protective capacity) and the devastating nature of uncertainty, we realize that when product-mix changes and/or market: demand goes up, the timely performance of the shop floor might be threatened.

What happens when a nonconstraint is losing its protective capacity? It turns out to be an interactive constraint. Managing interactive constraints is very difficult with constant threats on the satisfactory performance of the organization. If we know it in advance, we could look at various ways to reduce the pressure. Buffer Management is capable of giving an advanced warning that the protection mechanism is losing its effectiveness. When too many orders penetrate the emergency zone, this is a clear sign of a system under pressure. The identity of the new trouble maker can be revealed as the work center that holds more orders that have penetrated into the emergency zone than any other. The data regarding which work-center is holding those orders are collected and processed as a Pareto Chart.

As a true control mechanism, Buffer Management is relying on a different set of data than the one used for planning. Hence, it can point out a troublemaker that hardly looks this way when the capacity data are analyzed. Buffer Management can point out inconsistent data and send us to check the accuracy of those data items that seem both relevant and are suspected to be inaccurate.

Several ERP packages and/or external modules that hook into the existing ERP have