TOC and Complexity
There was a guy in the book named Herbie. As I recall, Herbie was the slow boy scout that kept everybody from getting to the campsite. The rest of the hikers took some of the weight out of Herbie's backpack to make his load lighter. They were also tied to Herbie with a rope so that Herbie would not get left behind. Somewhere there was a drum. Drum, rope, buffer. Where did the buffer come in?
If you arranged a group of workers for a bucket brigade, would the slow guy want to be at the beginning or the end of the line?
From contributor F:
Send the slow guy out to get coffee for the rest of the bucket brigade. They'll move faster without him and maybe the coffee will help motivate them.
From contributor V:
In TOC world, people try to deal with all sorts of variation, risks, uncertainty and resource conflicts/over-allocation in the system with the help of the single-constraint assumption and buffers based only on the variation within task durations. Wherever it works, we hear a success story.
From contributor G:
All of your concerns about TOC also haunted me for years. I first read the Goal back in 1999, and for years I tried to make sense of it. I've also read three of his other books (Critical Chain, It's not Luck, and his TOC summary book).
"In TOC world, people try to deal with all sorts of variation, risks, uncertainty and resource conflicts/over-allocation in the system with the help of the single-constraint assumption and buffers based only on the variation within task durations. Wherever it works, we hear a success story. "
You have to remember that TOC is a theory, it's far from an implementation plan. Its success largely depends on the implementation leaders intuition and knowledge of TOC, as well as how they connect the dots. The stories are also worth noting because typically they are a drastic change from the previous reality. It's also easy to forget that TOC doesn't apply to only production, but the entire "global" picture from the initial contact with the customer until that last payment is in your account. it has been my experience that most smaller shops don't have "herbie" in the shop, but rather in the sales/engineering/project management arenas.
Take my current position for example. I am a project manager/engineer for a commercial millwork firm. The output to the shop is done by my boss or myself. We constantly struggle to keep a steady flow of work out to the floor. I currently have 11 projects on my desk ranging from 1/2 million to 5,000 dollars, with lead times until production ranging just as far. Any scheduling software in this case (which is our norm) will only cause you problems, giving you false hope of order.
I'm beginning to believe that the only way to efficiently schedule a shop is to break our current constraint (PM/PE), and make a buffer of work orders for the shop floor, creating a pull flow methodology. Almost like Kanban. The simplest solution is often the best.
From contributor V:
Many small job shops cannot increase resource capacities without significant investment for the purpose of TOC subordination. These shops actually want to get the best out of the existing resources without adding resource capacities as required for TOC subordination. You said, "I currently have 11 projects on my desk ranging from 1/2 million to 5,000 dollars, with lead times until production ranging just as far. Any scheduling software in this case (which is our norm) will only cause you problems, giving you false hope of order".
I fully understand why you have a bad impression of scheduling software for job shops. A vast majority of the tools called scheduling software have very unsatisfactory performance. I guess many of these tools are the result of programmers' coding of somebody's common sense or the result of ridiculous MRP scheduling logic. Scheduling is a topic that can belittle even researchers at top universities. These tools caused such damage to the concept of computer-based scheduling that people like you believe that scheduling software can never be good. Therefore, they pushed people like you in custom production to Lean or TOC for production planning and scheduling. You may have a look at a brief demo at a web site, http://www.optisol.biz/demo.htm. In fact, the tiny example used in the demo pertains to woodworking industry.
From the original questioner:
At the heart of any scheduling effort, no matter what kind, is predictability of outcome. As long as you have random in the equation it doesn't matter what your strategy is, you will always have random in the result. Your software is very thought provoking in that it allows you to analyze the outcome of different (competing) strategies but it is still dependent on predictability. To get to predictability you're going to need standardization somewhere in the system and this is the underpinning of lean thinking.
From contributor V:
There are two kinds of variation in any production system: (1) the known variation among process and resource requirements of jobs / projects and (2) the unknown and uncontrollable variation due to randomness and uncertainty. TOC does not seem to make a serious distinction between the two. For example, the buffer for any job in the Drum-Buffer-Rope method ignores the existing heterogeneous workload which keeps changing always. This is mainly due to the assumption that you have sufficient capacity at every work center except one. I see many custom production units where this assumption does not hold or it is not economical to ensure it. The existing workload in custom production normally has a significant impact on lead time of a newly loaded job but TOC sees the workload only at one work center.
Due to randomness in the system, I would not advise shop floor people to strictly implement any detailed operational level schedule (precisely derived by a deterministic algorithm) at the level of minutes. For example, we can give a dispatch list to each resource as part of the schedule and ask the resource to follow the job sequence in chronological order as much as possible, taking start and finish times of operations only as guidelines. Since the actual workflow increasingly deviates from the schedule over time due to randomness (as we see in weather forecasts), we need to update the schedule using fresh job status information at some time point.
There is a lot of criticism about Finite Capacity Scheduling (deterministic scheduling) for not addressing randomness directly. If you see the schedule of a mix of diverse jobs / projects on Gantt chart, you would find jobs waiting and competing at some work centers. These waiting times definitely absorb some randomness in the system as the buffer does in DBR. We can use some parameters of the software to increase or decrease such waiting times to properly address the randomness. Trial runs of scheduling software on shop floor will actually reveal how effectively the randomness will be handled by updating schedules and implementing resource dispatch lists as explained above. It truly shows how bottlenecks keep wandering due to changing product mix. Standardization must be done wherever possible but it will not eliminate the complexity of scheduling heterogeneous workload on limited resources.
From contributor D:
"Standardization must be done wherever possible but it will not eliminate the complexity of scheduling heterogeneous workload on limited resources."
Presently, for some and not all, limited resources as in preferences, work, employees, and materials, are complicating our status quo management strategies. Sometimes MPS fails us, other times ERP sows discord and boxes you in with the non-competitive. Interestingly enough and strong managers who have tried CCPM have saved businesses from failure doing so, knowing how to lead renders much of the above meaningless when that leader is pushing and pulling. CCPM teaches task and task chains.
Would you like to add information to this article?
Interested in writing or submitting an article?
Have a question about this article?
Have you reviewed the related Knowledge Base areas below?