What If Some of the End Products Have Significantly Different Standard Lead Times?

As long as the planned load plus half of the production buffer is still at, or earlier than, the shortest standard lead time there is no problem-it is possible to quote the standard lead time. However, if the planned load stretches beyond the shortest standard lead time, what should we do? It could be the case that the short delivery can be promised because a substantial part of the orders have longer lead times, so just a little manipulation of priorities, which is naturally done by BM (short buffer orders change their color faster), would still ensure excellent due date performance. But, how can we tell?

The problem in determining a safe date based on the planned load is that we assume that at the time we calculate the safe date all orders that are supposed to be delivered before that date are known. If, when we determine a safe date, we are not certain whether we have all the orders to be delivered until that date, then we cannot rely on the planned load.

There are four cases where this possibility of having shorter-delivery orders is relevant.

1. The perception18 in the market is that for standard products the delivery time should be shorter than for products that are more complicated.

2. A strategic client requires faster delivery than the standard.

3. The "rapid response" type of service, meaning clients are given an optional service of very fast delivery for a considerable markup.

4. Items that are MTS. The problem here is that when orders to stock are released, the time those items will be needed is not known a priori. We'll deal with that case in another chapter dedicated to MTA.

All four cases have to be handled through the mechanism of reserving capacity for the "special" products that have to be completed faster. Suppose that on average the part of the "short-delivery items" requires about 25 percent of the capacity of the CCR. If we decide to assign only 70 percent of the CCR available capacity for the regular orders, so the planned load calculations consider only 70 percent of the available capacity of the CCR, then we actually delay the calculated safe date for the regular orders.

Let's view an example. The CCR has an available capacity of 16 hours a day. The short-delivery orders take, on average, 25 percent of the CCR's capacity. However, as this is just an average, let's dedicate 30 percent of the CCR capacity to those orders, leaving only 11.2 hours a day (70 percent of 16 hours) for processing the "regular" orders. The calculation of the main planned load, used to determine safe dates, for regular orders should be based only on the regular orders and according to capacity availability of 11.2 hours a day. If the current regular orders contain 100 hours of CCR work, plus 27 hours for "special" orders, then the next regular order received should get a safe date of 9 work days (100 hours of load/11.2 hours per day = 8.92 days rounded to 9 days) from now plus half of the production buffer expressed in work days. Of course, instead of the number of workdays from now, we should convert this to a specific date according to the calendar. This date is the earliest that could be given to the client as the safe date for completing the order.

What If a "Special Order" Is Received, What Safe Date Should It Get?

We assume the due date for a special order is not negotiable. It is solely dictated by the commitment to the market. This means that if the demand for special orders will grow beyond the reservation level, then the buffers of both the regular orders and the special ones would be consumed, which will cause a threat to the combined due date performance. In such a case adding capacity is definitely called for.

Should the Special Orders Get Higher Priority Than the Regular Ones?

The simple answer is no, all the orders compete on the capacity of the resources according to their color state (green, yellow, and red). If one wishes to be certain the special orders are on time, then increasing the production buffer for the special orders could be the right action.

An important point needs clarification: the CCR does not divide its time between the regulars and the specials according to the reservation percentage. The CCR works at all times based on BM priorities. When there are no special orders, then all 16 hours are dedicated to process regular orders.

Buffer Management *

The basics of BM for an MTO environment did not change with the move from DBR to S-DBR. However, the criticality of BM to the success of the implementation has been increased. Once an order is released, then the only control on that order is through BM. The additional flexibility given to the execution phase makes providing good priorities an absolute must for successfully following the planning directives.

The planning procedure of S-DBR is that every order is given a production time buffer and a due date. According to these due dates, the material release schedule (due date minus production time buffer) is determined. At any given point in time, the time left for the order until its due date constitutes the remaining time buffer. The buffer time minus the remaining buffer is the portion of the buffer consumed thus far. The percentage of the buffer consumed to the total buffer is the "buffer status." Recall: Buffer status of less than 33 percent is considered green. Buffer status between 33 and 67 percent is yellow. Above 67 percent the buffer status is red.

An Example

The operator of a resource (not necessarily the CCR) has four different orders right now at the site. There are more orders in the shop, but only those four are currently at the work center. Order A1 should be delivered in 5 days; the production time buffer is 8 days. Order B1 is to be delivered in 3 days and the production time buffer is 6 days. Order C1 due date is 10 days from now and the production time buffer is 8 days. Order D1 has to be completed in 8 days from now and the production time buffer (which is long due to a lot of manual processing, fortunately most of the manual work has been done already) is 35 work days.

The color code for order A1 is (8 5)/8 100% = 37.5% Yellow The color code for order B1 is (6 3)/6 100% = 50% Yellow The color code for order C1 is (8 10)/8 100% = 25% Green (actually above the green) Note that this order may have been released early to keep the CCR from going idle.

The color code for order D1 is (35 8)/35 100% = 77.14% RED!

Certainly, the resource should immediately process the D1 order. What will be the next one? We don't know at this time. More orders could show up and one or two of them could be red. Buffers and buffer penetration percentages for each of these orders are seen in Fig. 9-4.

Several points regarding this example are worth discussion. Order D1 has the farthest due date from the current four candidates for immediate processing. However, because D1 has that long buffer, the assumption is that it needs that length of time as a buffer and thus the remaining 8 days signal the order is under pressure.

However, it is clearly written that the manual work in processing D1, which justified the especially long-time buffer, has already been dealt with. In such a situation, should we still look on order D1 as a "red order?"

It could be that at that point in the routing D1 is not truly urgent. However, we put a process in place that should yield good results in the vast majority of the cases. Can we really optimize the priority procedure to such a degree that in spite of the fluctuations in the shop and mistakes people make that better results would be achieved? Trying too hard to optimize within the "noise" (level of uncertainty) of the environment will actually increase the impact of the noise. This is one of the insights we have learned from Deming's funnel experiment.19 Suppose that D1 is stuck upstream of the relevant resource. Therefore, only three orders are at the site at this time. Which order should the operator choose? The buffer status of B1 is higher than A1, but the rule is to decide based on the color. The color of both orders is the same, yellow, and thus any choice of one of the two is acceptable. We assume the operator is aware of the buffer status, but might consider saving a setup, which is relevant only for orders with the same color code.

FIGURE 9-4 Buffer penetration shows priorities for processing.

Short-Term Planned Load

The main need for load control is for establishing the synchronization between Production and Sales, mainly by providing the estimates for safe dates as the earliest dates to be used by Sales for quotation. Thus, the horizon for that planned load is the expectation of the clients for response time. The planned load for this main horizon also provides signals for when to press Sales to bring more sales or restrain the sales to a degree.

What about the more immediate horizon, like the production buffer time? Every order that is now on the shop floor has to be delivered within the production buffer time (unless that order was released early to keep the CCR busy). The point of load control at this time is to ascertain that the capacity of the CCR is more than enough to deliver everything on time.

How could it be that S-DBR would find itself in a situation where it ran out of capacity and there is not much hope to deliver all the orders on time? After all, every single order was given a due date that was in line with the available capacity as assessed by the planned load.

There are several possible causes for such a case of capacity shortage in the very short-term. One is that enough capacity is available, but it is in the shape of overtime or outsourcing, which means that capacity costs extra money. That extra capacity was probably considered by the planned load (depending on how the planned load was modeled), but now a clear decision is required whether to actually utilize the overtime and how much of it. Therefore, a short-term load control mechanism must be in place to support the decision on using overtime and how much overtime has to be used.

There could also be other, more severe, causes for short-term lack of capacity. It could be that Murphy caused downtime of the CCR, and that lost capacity is now taking its toll. Another cause is that too many special orders, to be delivered in a very short time, have been received and now it seems one or more orders would be late unless a quick way to add capacity is found.

A planned load for the short horizon, which is targeted at checking the capacity requirements for the short-term, should include all the orders released to the floor; that is, the regular and the special orders together.

Other special uses of the planned load include checking the special orders, taking into account only the reserved part of the capacity. That type of partial planned load is targeted to check the validity of the reservation level and note the cases where the special orders would definitely "steal" capacity from the regular orders. Even if that situation is not problematic, like when the number of regular orders is not too high, the fact that the special orders have to steal capacity from the regular orders is meaningful enough to rethink the appropriate level of capacity reservation.

The Notion of "Slack"

As previously said, when the due date is set after the safe date given by the planned load plus half the production buffer, the order should still be released at the planned load minus half the production buffer. This creates an order with a larger production buffer than the regular one.

When the Sales regular policy is to quote the standard lead time unless the safe date is later than that date, then most of the orders would have larger time buffers. The software called Symphony, developed by Inherent Simplicity Inc., calls the time difference between the actual time buffer and the regular production buffer "slack." Having "slack" means that Production is capable of processing additional orders while still meeting the current due dates. Thus, the slack is a signal to Sales to push for more orders.

There is another use for slack. What if an order is received with the request to deliver it sooner than the safe date? Normally we would expect that such a case is handled by the capacity reservation, but sometimes no capacity reservation has been accounted for, or the capacity reservation is fully utilized. However, if there are several orders with slack, then maybe they can be placed a little later on the timeline and thus provide an opportunity to deliver the new order at the requested time. What such software can do is simulate the updated planned load by inserting the capacity required for the new order in a place that would support the requested date, and thus pushing some of the orders later in time, checking that all the orders still have the appropriate half-buffer between their assumed schedule in the planned load and their due dates.

Where S-DBR Fits Nicely

The original idea of applying S-DBR instead of DBR was that it fit the simpler environments. Certainly, it fits the case where no active capacity constraint is involved. As time went on, the understanding expanded to include within S-DBR cases where an active CCR existed but no sophisticated scheduling of the CCR was required. The assumption at that time was that when the detailed schedule of the CCR was straightforward, then it was enough to sequence the CCR according to BM priorities on the shop floor, but the more complicated cases should be handled by DBR and its three buffers. A good example of such an intricate case is one CCR operation feeding another CCR operation. The relatively complicated procedure for it is described in The Haystack Syndrome (Goldratt, 1990a).

The paradigm the author of this chapter had to fight with was that when the environment is truly complex, then detailed planning is a must. After all, there are many variables to take into account, so in order to achieve the required synchronization sophisticated planning has to take place.

Frequently inertia prevents one from breaking a paradigm. It was a startling experience to realize that such a common sense paradigm that a complex situation requires sophisticated planning has to be reversed!

Two meaningful citations of Goldratt, said at different times, have contributed to the change of paradigm: 1. In reality, we have both complexity and uncertainty and we are fortunate for having them both together.

2. The more complex the problem is, the simpler the solution should be.

The first saying means that when uncertainty is added upon complexity, then it is not possible to come up with an optimal solution that is also practical. When too many variables impact the output, then an "optimal solution" is usually a "sensitive solution," meaning even a small deviation from the precise optimal solution would lead to a significant drop in the output. In an uncertain environment, there is no way to implement a multivariable solution without any deviation.

The following example should demonstrate the flaw in looking for the "optimal solution" to a complex and uncertain situation.

Suppose you live in Tel Aviv, Israel, and you need to arrive in Phoenix, Arizona, for a meeting with the board of directors of an important potential client. You would like to leave home as late as possible and spend the minimum time waiting for your connecting flights.

As the story goes, your agent has found exactly what you have asked for. You are booked on three legs of flights with 30 minutes between landing and takeoff. This time should be just enough to walk to the gate where the next flight is taking off. The agent included detailed calculations of the distance between the gates and the security and passport control in-between to show that it is an exact match to your capability to walk with your carry-on luggage. Eventually you are going to land at Phoenix Airport, 72 minutes before the meeting. The planning takes into account the traffic on the hour following the landing, showing that you will arrive at the meeting on the minute.

What do you think of such optimal planning? Isn't it ideal? It is great to be just on time without wasting precious time.

Even if we ignore most of the uncertainty and assume all flight schedules are truly precise, we need a lot of luck to arrive on such a nice optimal plan. Usually, the airlines and the availability of seats are not so generous and thus you'd need to waste some time waiting for flights or arrive significantly earlier than in the imaginary ideal solution. Yet, there are many alternatives to connect between Tel Aviv and Phoenix, so your agent should look for all of them until the best one is chosen.

Now, let's acknowledge the uncertainty. Flights are not always on time, queues for security and immigration fluctuate widely, and you can never rely on the traffic flow. At the end of the day, you realize not only do you need to consider buffering your plan, but also that there is no sense in checking too many options because once buffers are included in the planning the difference between alternative routings is negligible.

This is the insight emerging from the first citation of Goldratt: The inclusion of uncertainty within the complexity of the environment makes the sensible plan to be fairly simple. Focus only on the minimal requirements that are clearly critical and make sure those key requirements are properly protected.

This understanding leads to the second citation: solutions for complex situations must be simple; otherwise, they do not stand a chance in reality. Any small deviation in one of the many inputs (the number of inputs is what makes the environment complex) would cause too large a deviation in the output.

What does this have to do with S-DBR in a complex environment? The current understanding is that in the vast majority of the complicated cases, the use of S-DBR is even more sensible than the use of DBR. In the cases where there is a problem in using S-DBR, the use of straightforward DBR is also problematic.

Take the case of a CCR operation feeding another CCR operation mentioned before as a re-entrant line. One has to assume a minimal time difference between the two CCR operations of the same order. This time difference is required to make sure the parts that finished processing by the previous CCR operation will reach the next CCR operation. In this way, several back-to-back time buffers have to be included in the planning, forcing long total lead time. When S-DBR is implemented in such an environment, there is no predetermined schedule for CCR. The practical consequence is that whenever the parts for the next operation reach the CCR they become available for immediate processing based on the priorities at that time. This allows the total length of the production buffer to be shorter than the total of the back-to-back buffers used in DBR.

Most cases that seem to require sophisticated scheduling of the CCR should use S-DBR as a practical approach that leaves most of the complexity to the last minute decision by the people who know the rules well enough and who are exposed to the real-time priorities as set by BM. However, S-DBR also has some limitations.

The Cases Where S-DBR Does Not Fit *

S-DBR has two necessary conditions: 1. Arbitrary sequence of processing the orders does not significantly impact the capacity of the resources. In other words, the sequence as such does not cause any resource to become a bottleneck.

2. The ratio of the touch time to the production lead time is very small (less than 10 percent before S-DBR is implemented, less than 20 percent with S-DBR on). Touch time means the net processing time along the longest chain of operations. This definition is intended to exclude cases where assembly of thousands of parts, done on different sets of resources, might have a long processing time, but as the majority of the parts are assembled in parallel, the actual production lead time is not so long.

The environment where the first condition does not apply is where the length of the setup depends not only on what is going to be produced, but also on what has just been produced. Such a situation is usually called a sequence-dependent-setup.20 When the difference between the setup times is very large, then S-DBR implementation might be problematic because an arbitrary sequence of processing orders, as dictated by BM, could easily turn a non-constraint into a bottleneck. The situation forces the producer to follow a certain sequence through the various products. Assuming that going through the whole cycle of products is a very significant portion of the standard lead time, the unavoidable result is that lead times might be quite long. What is even worse is that there is not much practical possibility to expedite any order because the sequence should not be changed. In other words, BM is able to show priorities but it is very difficult to follow them.

From this, one can deduce that even in a sequence-dependent-setup environment S-DBR can be applied if the total cycle time, the time between producing a product until it is possible to produce that product again, is short relative to the standard lead time. Another case where S-DBR is still fully applicable even in a sequence-dependent-setup environment is when there are several production lines, which provide good enough flexibility to expedite an order without wasting too much capacity.

The second condition mentioned above makes us aware that manufacturing environments with relatively long touch times (more than 10 percent of the lead time before S-DBR is implemented) might pose certain difficulties in applying either DBR or S-DBR. In some of the cases, what is described as a manufacturing environment is actually a multi-project environment, where each single order is actually a project. In such an environment, the planning has to include sequencing of all resources within each project in order to define clearly the longest chain; otherwise, the lead time might be significantly inflated. Schragenheim and Walsh (2002) discuss the differences between manufacturing (DBR) and multi-projects (multi-project critical chain) and the appropriate planning and control systems for each. Critical Chain Project Management (CCPM) is the preferred method where the touch time is greater than 10 percent of the production lead time.

When the basic routing of every order is relatively simple, like a sequence of operations without parallel legs, S-DBR is still a valid option. However, having one or several very long operations poses some problems to BM to reflect the true state of urgency of the order. Let's use an example to demonstrate the problem.

Suppose the appropriate production buffer of an order is three weeks. The last operation is a long test that takes a whole week to go through. That one week is a fixed length of time. The sum of the previous net processing times is short, taking at most eight hours. If the test determines a problem, it usually requires the replacement of a purchased component, which is done in minutes. Therefore, all in all the touch time is approximately 35 percent of the production buffer, but the vast majority of it is accumulated at the very end. What is the appropriate priority of an order after two weeks? The regular priority would show an order just entered into the red. But, if the order testing has not started yet then actually the order is already late.21 On the other hand, if the order is already three days into the testing then it'd most certainly be on time.

In the previous example, only one operation is truly long, while the rest are normal manufacturing where the net processing time per piece (also per order) is very short. In this case, it is possible to introduce some changes to the way S-DBR and BM rules are implemented that would work. In the particular case of the example, all we need is to model the requirement to reach the testing no later than a week earlier than the customer's due date. By generating a fictional safe date not for the full completion of the order, but for entering the last operation one week before the due date, we force the right priorities in the system prior to the final testing.

In cases where the long operation is in the middle of the routing, there might be a need to implement back-to-back time buffers, creating a somewhat less simple solution, but still not requiring scheduling the CCR in detail, and most of the S-DBR procedures are in place.22 In the extreme case (such as firms in the process industry) where an order has several long operations that are spread through the routing, yet the routing itself is a simple 'I'-shaped structure,23 changes to the buffer management algorithm would still provide the right priorities. This feature, developed by Inherent Simplicity Ltd., is beyond the scope of this chapter.