Drum-Buffer-Rope in PlanetTogether Galaxy

Size: px
Start display at page:

Download "Drum-Buffer-Rope in PlanetTogether Galaxy"

Transcription

1 Drum-Buffer-Rope in PlanetTogether Galaxy This document provides background on Theory of Constraints and Drum-Buffer-Rope scheduling. It describes how to assess whether the DBR approach is appropriate for a company and how Galaxy DBR functions. Finally, it provides suggestions for implementing Galaxy s Drum-Buffer-Rope successfully. Background Introduction to Theory of Constraints (TOC) (source [1]) Source [1] Theory of Constraints (TOC) is an overall management philosophy introduced by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal, that is geared to help organizations continually achieve their goals. Dr. Eliyahu M. Goldratt adopted the concept with his book Critical Chain, published The concept was extended to TOC with respectively titled publication in An earlier propagator of the concept was Prof.h.c. Wolfgang Mewes in Germany with publications on power-oriented management theory (Machtorientierte Führungstheorie, 1963) and following with his Energo-Kybernetic System (EKS, 1971), later renamed Engpasskonzentrierte Strategie as a more advanced theory of bottlenecks. The publications of Wolfgang Mewes are marketed through the FAZ Verlag, publishing house of the German newspaper Frankfurter Allgemeine Zeitung. However, the paradigm Theory of Constraints was first used by Dr. Eliyahu M. Goldratt. Key assumption The underlying premise of Theory of Constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Throughput is the rate at which the system generates money through sales. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput. "The Goal" itself is to "make money". All other benefits are derived, in one way or another, from that single primary goal. 1

2 The five focusing steps Theory of Constraints is based on the premise that the rate of goal achievement is limited by at least one constraining process. Only by increasing flow through the constraint can overall throughput be increased. Assuming the goal of the organization has been articulated (e.g., "Make money now and in the future") the steps are: 1. Identify the constraint (the resource or policy that prevents the organization from obtaining more of the goal) 2. Decide how to exploit the constraint (get the most capacity out of the constrained process) 3. Subordinate all other processes to above decision (align the whole system or organization to support the decision made above) 4. Elevate the constraint (make other major changes needed to break the constraint) 5. If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint. The five focusing steps aim to ensure ongoing improvement efforts are centered on the organization's constraints. In the TOC literature, this is referred to as the "Process of Ongoing Improvement" (POOGI). These focusing steps are the key steps to developing the specific applications mentioned below. Constraints A constraint is anything that prevents the system from achieving more of its goal. There are many ways that constraints can show up, but a core principle within TOC is that there are not tens or hundreds of constraints. There is at least one and at most a few in any given system. Constraints can be internal or external to the system. An internal constraint is in evidence when the market demands more from the system than it can deliver. If this is the case, then the focus of the organization should be on discovering that constraint and following the five focusing steps to open it up (and potentially remove it). An external constraint exists when the system can produce more than the market will bear. If this is the case, then the organization should focus on mechanisms to create more demand for its products or services. Types of (internal) constraints Equipment: The way equipment is currently used limits the ability of the system to produce more salable goods/services. 2

3 People: Lack of skilled people limits the system. Mental models held by people can cause behavior that becomes a constraint. Policy: A written or unwritten policy prevents the system from making more. Please note: Organizations have many problems with equipment, people, policies, etc. (A breakdown is just that - a breakdown - and is not a constraint in the true sense of the TOC concept). The constraint is the thing that is preventing the organization from getting more Throughput (typically, revenue through sales). Buffers Buffers are used throughout Theory of Constraints. They often result as part of the EXPLOIT and SUBORDINATE steps of the five focusing steps. Buffers are placed before the governing constraint, thus ensuring that the constraint is never starved. Buffers are also placed behind the constraint to prevent downstream failure to block the constraint's output. Buffers used in this way protect the constraint from variations in the rest of the system and should allow for normal variation of processing time and the occasional upset (Murphy) before and behind the constraint. Buffers can be a bank of physical objects before a work center, waiting to be processed by that work center. Buffers ultimately buy you time, as in the time before work reaches the constraint and are often verbalized as time buffers. There should always be enough (but not excessive) work in the time queue before the constraint and adequate offloading space behind the constraint. Buffers are not the small queue of work that sits before every work center in a Kanban system although it is similar if you regard the assembly line as the governing constraint. A prerequisite in Theory of Constraints is that with one constraint in the system, all other parts of the system must have sufficient capacity to keep up with the work at the constraint and to catch up if time was lost. In a balanced line, as espoused by Kanban, when one work center goes down for a period longer than the buffer allows, then the entire system must wait until that work center is restored. In a TOC system, the only situation where work is in danger, is if the constraint is unable to process (either due to malfunction, sickness or a "hole" in the buffer - if something goes wrong that the time buffer cannot protect). 3

4 Introduction to Drum-Buffer-Rope (DBR) Source [2] When there is an internal constraint, there are very few resources (people, machines, equipment, materials) dictating the output of the system. The most limiting resource is referred to as the Drum as it determines the pace or beat of the entire system. Following Step 2 - Decide how to Exploit the System s Constraint(s), the constraint resource cannot be allowed to waste one moment of its capacity. This means that it should never be stopped waiting for parts and should not use capacity producing anything other than the parts required to fulfill sales orders. To ensure this we finitely schedule the Drum creating a Drum Schedule. The Drum schedule should maximize the Throughput of the Constraint and provide a detailed plan for just this one area. The Drum Schedule must be derived from the Shipping Schedule. Following step 3 - Subordinate everything else to the above decisions, there are a number of actions that have to be met by the non-constraints in the system in order to meet the Drum Schedule and ultimately the shipping schedule. As discussed earlier, variation and Murphy cause, from time to time, pieces of plant to break down. Understanding that we have to protect the constraint from lost capacity due to these breakdowns, a Buffer of time is used. The Constraint buffer is a pre-determined length of time; we must release the order into the system before the order is due on the Drum Schedule. As all other resources have more capacity than the constraint (by definition), the effect of introducing parts a buffer time before they are due at the constraint is that work builds up in front of the constraint and protects it from breakdowns on preceding operations. To ensure that too much inventory is not introduced into the system, it is important to start a new order only as the constraint finishes one. To ensure this, a Rope is tied to the first (gating) operation of the system. This is calculated by the date the order appears on the Drum Schedule minus the Constraint Buffer time giving a schedule for material release into the system. We have now choked the release of work into the system. To ensure the Shipping Schedule is met after meeting the Drum Schedule a rope is tied from the Drum to the Shipping Schedule. The rope length is a buffer of time to ensure the shipping schedule is always met; this is called the shipping buffer. 4

5 This choking of release results in excess capacity being revealed in the non-constraints in front of and behind the Drum. This can have negative ramifications and must be properly handled in implementation; otherwise non-constraint resources will slow down to protect themselves from perceived negative consequences of not being busy all the time. This will of course impact Throughput and delivery performance. Buffer Management Source [2] Buffers are used to protect against disruptions and to identify blockages very visibly and early enough in execution for recovery actions to be taken to ensure that the delivery commitment is still met. The information is collected on the reasons for delays. This is analyzed, and focused actions are put in place to address them, continually improving the execution process and driving the lead time down. The Buffers, the Constraint Buffer and the Shipping Buffers are effectively divided into three equal time periods. For example if the Shipping Buffer was 12 days then each of the three zones would be four days long. If the order was nine days away from the date required on the shipping schedule it would be in the first zone which is colored green. If the order was five days away from the date required on the shipping scheduled then the order would be in the second zone and colored yellow. If the order was two days away from the date required on the shipping schedule then the order would be colored red. Buffer Management then becomes the priority system on the shop floor. A resource must always work upon a red in preference to a yellow or green and upon a yellow in preference to a green. In order to ensure the red orders are expedited through the system and delivered on time Buffer Meetings are held to focus everyone s time and action on the very few important things in the system. These meetings have all relevant staff and are held for 10 minutes each day or shift. Actions from the previous days meeting are checked to ensure they were completed and actions assigned to the relevant people for today s reds. 5

6 Applicability of DBR Before deciding to implement DBR it s important to assess whether the business and production process are well suited to this approach. The following requirements should be met before DBR is implemented: Verify that the company s limiting constraint is internal that is that there is more demand than there is capacity to satisfy that demand. Determine if there are relatively few Resources that are consistently the constraint to throughput. These are typically Resources that are expensive, have less capacity than other Resources, and tend to accumulate work-in-process inventory before them. DBR is better suited to environments with known, predictable constraints as opposed to job shop type environments where constraints can vary widely. How Galaxy DBR Functions Figure 1 below illustrates how Galaxy performs the DBR functions in a simple example as described. Resource 1 Operation 10 Resource 2 Drum Release Date Buffer Constraint Buffer Rope Operation 20 Shipping Buffer Job Need Date Ship Date Figure 1 6

7 Inputs These are the data values that are input into Galaxy in order to control the DBR calculations: 1. Ship Date: This is the date when the order should ship to the customer. This can be based on sales orders or forecasts. 2. Shipping Buffer: This duration can be subtracted from the Ship Date to calculate the Need Date. A larger Shipping Buffer increases the likelihood of delivering an order on-time -- at the expense of incurring more finished goods inventory cost. 3. Job Need Date: This is the date by which manufacturing should be complete. 4. Operations: Each operation in the routing has time standards such as setup, run, and postprocessing times. These are used in the scheduling of capacity and calculating of the Rope as described below. 5. Buffers: Each Resource can have a Buffer, defined as a duration, to be used in the calculating the Rope as described below. 6. Constraint Buffer: The Buffer in front of the Drum. DBR Algorithm These are the basic calculations performed by Galaxy during an Optimization when using DBR: 1. A DBR Start Date is calculated for each Operation on the critical path. The DBR Start Date is the date and time (to the minute) when the Operation must start in order to complete the Job by the Need Date while leaving slack based on the prescribed Buffers. 2. The DBR Release Date is set based on the earliest DBR Start Date for all Operations. 3. The schedule is created based on the new DBR Release Date constraints that have been calculated for each Job, along with all material and capacity constraints plus the Optimization rules that have been defined. In addition to this simple example, Galaxy also has the ability to take the following into consideration in the DBR algorithms: The Drum Resource can occur anywhere in the Path it does not have to occur at the end. If using Alternate Paths, DBR is calculated for each Path so that Alternates can be used while at the same time using the DBR release rules. 7

8 Jobs that have non-linear paths such as V (one to many) or A (many to one) operation flows Successor Manufacturing Orders of any depth are used to determine the DBR Release Dates as if they are an extension of the Path. Operation Transfer Spans are taken into account to further extend the DBR Release Date setback. DBR Release Date calculations adapt for Finished and Omitted Operations. If a further overall slack is desired to increase the likelihood of on-time delivery (at the tradeoff of more inventory) then the JIT Slack Days can be set in the Optimize Options. If multiple Resources are eligible for an Operation then the most conservative Resource Buffer Span is used automatically. Warning colors in the Gantt (white=early, green=on-time, yellow=almost late, orange=late, red=bottleneck) are helpful in Buffer management, to see where schedules are slipping with respect to the target DBR dates. Implementation Considerations When setting up Galaxy to use the DBR functionality the following should be carefully analyzed, adjusted, and refined to achieve the best outcome. Shipping Buffer: To allow for sufficient time for preparation for shipping activities it s recommended that Job Need Dates are set sufficiently ahead of the desired Ship Date or that a shipping Operation is scheduled to account for this time. Sequence-Dependent Setup Times: If a Drum Resource has significant setup times that depend upon the sequence of Operations then better results may be achieved by increasing the Constraint Buffer to allow for greater opportunities for grouping. If the Rope is too short then the Resources will not have enough flexibility in trying to batch similar work. Non-Drum Resources can be set to Finite or Infinite Capacity. If the non-drum Resources should never be constraints to the Drum then by setting them to Infinite the Drum will have maximum flexibility to follow its Optimization Rule. Any conflicts on non-drums can be resolved manually by the planner. When determining the values to use for the Resource Buffers, the variability and reliability of the Resource should be taken into account. The more uncertain the process is the larger the Buffer will have to be in order to avoid late completions. Operation lengths can also be set to durations that are likely to be achieved taken variability into account. 8

9 References and further reading [1] [2] 9