Theory of Constraints Handbook - James Cox Iii [169]
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