Common mistakes of TOC practitioners in well-known TOC applications

I think that none of the  TOC applications are in the stage of just following a recipe for implementation.  There are certainly recipes for SDBR, Make-to-availability, Replenishment and CCPM, but in too many occasions in reality there is a need to deviate from the recipe.

There are two different categories of basic, sometimes hidden, TOC assumptions behind the TOC recipe for a successful implementation.

1.  Invalid necessary assumptions about the reality of the organization.
2. Invalid assumptions about the clients of that organization.

All TOC applications have several necessary assumptions that define the boundaries where the TOC application is effective.  Here are some examples where failing to notice that one necessary assumption is not valid causes problems in the implementation.

Basic SDBR assumption: The total touch-time is less than 10% of the total production lead-time. When that assumption is not valid the problem lies mainly with buffer management that might not show penetration into the Red at the appropriate time when the user can still expedite.  In such a case certain changes to buffer management are required, taking into account the touch-time that still lies ahead of the order. When the touch time is 50% or more of the lead-time then the problem is wider than just buffer management.  Such environments either have very high amount of idle capacity or have to be planned according to CCPM.

Comment:  Touch time also include necessary wait time, like drying, even when no resource capacity is required.

Basic SDBR assumption: From material release until completion the order is under full control of the organization.  This is not valid when one or more of the processes are done by outsourcing. The contractor usually does not commit to follow buffer management priorities. The whole batch is going to and from the contractor. In a way this is similar to long touch-time process, but not being in control during that time adds to the problem.  The situation calls for protecting the intermediate due-date when the order should go to the contractor.  This means having two back-to-back time buffers, one until going to the contractor and the other covering the route from that time until completion. 

TOC common assumption for manufacturing organizations:  The common practice is to release orders as early as possible. In one striking case this almost automatic assumption about the organization was proven wrong!  The plant was very careful, actually too careful, in releasing orders, causing very low WIP throughout the plant.  Can you imagine what happened when the production lead-time was cut by half and orders were not allowed to be released earlier?

Basic CCPM assumption: The project could earn a lot from quick completion and loses a lot from slow completion.  When this assumption is not valid then the whole concept of the ‘critical chain’ (or the ‘critical path’) loses its impact.  While it is always true that completing the project fast is valuable and being slow causes some damage, the important question is whether the value from being fast or the loss of being late are such that the organization is ready to invest efforts and money to complete the project fast!  The reason that in manufacturing the concept of critical chain is not known is that the value of fast delivery is lower than keeping high efficiency of the expensive resources.  When some resources are highly loaded then tasks have to wait for the resource to become available.  TOC, which challenges the value of efficiency for non-constraints, does not challenge the manufacturing concept of orders waiting for loaded resources, certainly for the constraint.  Thus, in manufacturing the lead-time is much longer than touch-time, while in projects special efforts are put to prevent the project from standing idle.  Recognizing when fast completion is critical should be part of the definition of a ‘project’ that should be planned using CCPM.

A common assumption in CCPM:  Professionals intentionally inflate the time to complete a job in order to be always on-time.  This assumption might be invalid in software and in sophisticated technology organizations where the professionals are not bothered by being on-time, and are more interested in getting the green light to develop something new and exciting.  For that end they might intentionally reduce the time it takes to do the job!  Cutting to half this kind of time assessment is a major mistake!

TOC assumption in Distribution:  The TOC solution would dramatically cut the inventory levels.  This is a common expectation and sometimes the success of the implementation is based on the amount of reduced inventory.  The real aim of the TOC solution is to provide excellent availability.  In most cases trying to do so without the TOC insights ends up holding too much inventory.  So, in most cases the expectations are met.  But, when many slow movers are maintained for perfect availability the required inventory, according to the TOC model, might be higher than the current practice.  Should the organization commit to keep those slow movers in perfect availability?  This questions leads us to the second category of invalid assumptions.

Here are some common examples for failing to understand the clients of the organization.

A common assumption in make-to-availability and distribution: the market suffers from frequent unavailability of every item.  There are two devastating results stemming from this assumption:

1. All the items are held for availability, including slow movers that require large stock buffers to maintain availability, even when the clients are ready to wait some time for delivery. Another related problem is offering availability for items with unstable supply. 
2. All clients like to be offered perfect availability. Well, perfect availability is always nice, but:

Do the clients truly suffer from unavailability?

Many times the suffering is real and it is beneficial to offer perfect reliability that the clients can rely on.  But, sometimes the missing items have obvious replacements, so the damage is minimal.  In other cases the client carries enough stock and is not bothered by short-time unavailability.  When the value to the client is low then providing perfect availability is merely “nice”.  For instance, offering perfect availability to wholesalers, which base their competitive advantage on low prices and do not offer availability of specific items, is bound to fail.

A hidden assumption in CCPM:  The original due-date, which is important to the client, does not change.  An important planning principle in CCPM is keeping the planning intact. However, the critical due-date might often slide later because of other needs of the client.  When this happens it does not add value to complete the project on the original time.  Showing the project in Red when the client can easily wait adds unnecessary pressure and tension.  It could also make project managers suspect buffer management when the project is Red and they know it is not. When the change of the due-date is small, then the project buffer can get extra time until the new due-date, relieving the pressure on delayed chains.  When the change is considerable re-planning is recommended.  The main point is: check frequently with the client whether the original due-date is still on.

We all make mistakes.  We need to learn from our mistakes, and even better, learn from the mistakes of others.  The key learning from mistakes is the ability to generalize the case, so it becomes a new insight.  It bothers me that most TOCICO case presentations take the usual approach of showing successful results, without revealing the mistakes and hurdles on the way, as if someone needs to be ashamed of the mistakes and by that also hide the achievement of identifying the mistake and fixing it.  There was one great presentation I remember from the Canadian CMS group that came up with lessons learned from mistakes in an implementation.  The implementation apparently ended well after the new understanding.  I think we all should learn the lessons from mistakes, made by us and by others.