The Critical Information behind the Planned-Load

When I developed the concept of the Planned-Load I thought it would be a “nice-to-have” additional feature to my MICSS simulator.  MICSS provided me with the opportunity to check different policies and ideas relevant for managing manufacturing. It took me years to realize how important the planned-load is.

Actually, without the use of the planned-load it is impossible to use Simplified-Drum-Buffer-Rope (S-DBR), which replaced the much more complex DBR. Still, it seems most people in the TOC world, including those who develop TOC software, are not aware of its importance and certainly not its potential value, not yet fully materialized.

The planned-load for a critical resource is the accumulation of the time it would take to complete all the work that is firmly planned. The objective is to help us understand the connection between load, available capacity and response time!

Let’s use the justice system as an example. Imagine a judge examining the work he has to do: sitting in already scheduled trial-sessions for the total of 160 hours.  On top of that he needs to spend 80 hours on reading protocols of previous sessions and writing verdicts.  All in all 240 hours are required for completing the existing known work-load.

Assuming the judge works 40 hours a week then all the trials currently waiting for the judge should theoretically be completed in six weeks. We can expect, with reasonable certainly, that a new trial, requiring about 40 hours net work from the judge, would be finished no later than ten weeks.  I have added three weeks as a buffer against whatever could go wrong, like some of the trials requiring additional sessions or that the judge becomes sick for few days. This buffer is required in order to reasonably predict the completion of a new trial.

However, in reality we could easily find out that the average lead-time of a new trial is fifty (50) weeks – how can that be explained?

When expectations based on the planned-load do not materialize we have to assume one of the following explanations:

1. The resource we are looking at is a non-constraint and thus has a lot of idle time. In the judge case, the real bottleneck could be the lawyers that ask and get long delays between sessions.
2. While the resource is a constraint, the management of the resource, specifically the efforts to exploit its capacity, is so bad that substantial capacity is wasted.
3. The actual demand contains high ratio of urgent cases, not planned a-priori and thus not part of the current planned-load. Those cases frequently appear and delay the regular planned work already registered in the system.

The importance of the planned-load of the “weakest-link” in operations is quick rough estimation of the net queue-time of work-orders and missions.  When the queue time is relatively long the planned load gives an estimation of the actual lead-time provided there is no major waste of capacity.  In other words the planned-load is a measure of the potential responsiveness of the system to new demand.

Have a look at the following picture depicting the planned-load (the red-bar) of six different resources of a manufacturing organization. The numbers, on the right side of the bar denotes hours of work, including average setups.

Assuming every resource works 40 hours a week, we see one resource (PK – the packaging line) that has almost three weeks of net work to do.

The green bars represent the amount of planned-work that is already at the site of the resource. In production lines, but also in environments with missions that require several resources, it could be that a certain work is already firm, but it has not, yet, reached the specific resource.  That work is part of the planned load. It is NOT part of the green-bar.  PK is the last operation and most of the known work-orders for it reside at upstream resources or maybe even not released, yet, to the floor.

The truly critical information is contained in the red-bars – the Planned-Load. To understand the message you need an additional piece of information:  the customer lead-time is between 6-7 weeks.

The above information is enough to safely conclude that the shop floor above is very poorly handled.

The actual lead-time should have been three-weeks on average. So, quoting four weeks delivery time might bring more demand.  Of course, when the demand goes sharply up, then the planned-load should be carefully re-checked to validate that the four-week delivery is safe.

Just to illustrate the power of the planned-load information – here is planned-load of the same organization four months after introducing the required changes in operations:

The customer lead time is now four weeks. The demand went up by 25%, causing work-center MB to become an active capacity constraint. As the simulation is now using the correct TOC principles, most of the WIP is naturally gathered at the constraint.  Non-constraint resources that are downstream of the constraint have very little WIP residing at their site.

The longest planned-load is three weeks (about 120 hours of planned work for MB). The four weeks quotation includes the time-buffer to allow getting over problems in MB itself, and having to go through downstream operations.

This is just the basic understanding of the criticality of the planned load information. Once Dr. Goldratt internalized the hidden value of that information, he based the algorithm for quoting “safe-dates” on the planned-load plus a part of the time-buffer.

A graph of the behavior of the planned-load through time could be revealing. When the graph goes up – it tells you there is more incoming new demand than demand delivered, which means a risk of having an emerging bottleneck.  When the graph goes down it means excess capacity is available allowing faster response.  Both Sales and Production should base their plans accordingly.

Other important distinction is to look for the immediate short-term impact of the planned-load in order to manage overtime to control the reliable delivery. The time horizon is the time-buffer – making sure the capacity is enough to deliver all orders within that horizon. It identifies problems before buffer management warning of “too much red”.  One should always look on BOTH planned-load and buffer management to manage the execution. 

SDBR, and its planned-load part, certainly applies to manufacturing. But, SDBR, including both the planned-load and buffer-management should be used to manage the timely completion of missions in almost all organizations.

There is a tendency in TOC circles to assume that any big enough mission, for whom several resources are required, is a project that should be manage according to CCPM.  While it is possible to do so and get positive results, this is not necessarily the best way, certainly not the simplest way, to manage such missions.

I think we should make the effort and distinguish clearly when SDBR can be effectively used for missions and when CCPM is truly required.   And, by the way, we can all think how the capacity of key resources should be managed in multi-project environments.  Is there a way to use the Planned-Load as a key indicator whether there is enough capacity to prevent too long delays or there is an urgent need to increase capacity?