Common mistakes of TOC practitioners in well-known TOC applications

Let's make better mistakes tomorrow - handwriting on a napkin wi

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.


Published by

Eli Schragenheim

My love for challenges makes my life interesting. I'm concerned when I see organizations ignore uncertainty and I cannot understand people blindly following their leader.

9 thoughts on “Common mistakes of TOC practitioners in well-known TOC applications”

  1. Absolutely WONDERFUL, Eli! There is a reason that a necessary assumption lies on the top of every S&T element (except 1). We speed ourselves up to be able to do more by memorizing what to do. Is it really so much faster to not think through, every time, the conditions that must be present for a beneficial outcome? Context is critical.

    I have been having a debate with friends about whether promising perfect availability is a competitive edge in a commoditized niche. The nature of such an industry is one where there are competitors ready to fill in for almost all shortages. Likewise, net profits are contained in a tight range by competition, real or imagined. In such an environment, even a small competitive edge is decisive over time. When the competition earns 1% of sales, adding 1% of sales to net profits doubles the investments that can be made and the services that can be offered over time – a big difference in the end.

    Is a vendor-managed-inventory with guaranteed perfect availability of a commodity as good a “mafia offer” as Reliable – Rapid Response is to a make-to-order manufacturer whose customers are blighted by late delivery? No, of course not. Not when you compare the two competitive edges to each other. But, that is not the circumstance. Such a comparison is like apples to oranges. The VMI solution pulls a comparable upside gap for the distributor, in its own context, as RRR does for the MTO manufacturer in theirs.


  2. The last paragraph is insightful about the current reality of decorating presentations and gives an encouraging direction to take, for a win-win of the larger community as well as direct stakeholders.

    The write up is a good mirror to look at and start thinking about your next TOC presentation!


  3. Perfect post, Eli! I’ve met almost all that mistakes 🙂 And I’m going to tell about how we handled with them in St.Petersburg 🙂


  4. Eli,
    This is a thought-provoking post, and serves to remind the TOC community we learn from our mistakes. Thank you for sharing your insights.


  5. Thabks Eli for a great piece.

    Another client-side assumption, especially related to distribution is that clients vakue having one/few rather tham more suppliers. The model of the Aldi & Lidl supermarkets is they stock a limited range of (I assume) fast sellers. If you want something else, buy it from another store.

    Slow movers could be treated this way, or if the client does want a one-stop-shop, then buying from a competitor to resell is a valid option rather than carrying very slow moving inventory.


  6. “The key learning from mistakes is the ability to generalize the case”
    Excelent sentence. Remembers me the core message of “The Choice” from Eli Goldratt. Since I read (several times) that book, when I fail in anything (several times) I take some minutes to curse, and immediatly began to think what I must do next time to improve. I really rejoice from the fact that I add some new knowledge about the process (in the long way of deep understanding).


  7. Dear Eli, thanks for contributing such great insights. We have seen some mistakes in TOC implementation, such as providing “Mafia Offer” to the clients without building internal operational strength first, which is quite dangerous and risky to the clients as they might jump to elevate in the new markets, meanwhile there is lack of consolidated support in operation and might cause deeper chaos which they could not be able to deal with.
    People are negative to face the failure, but it’s more valuable to learn from the failure to avoid jumping into the same pitfall.
    Thank you again for your insightful article.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s