Question
It's been a long time since I read The Goal. My understanding is that Eli Goldratt, the book's author, was an Israeli physicist and that he had no actual direct experience in manufacturing. I could be wrong about that but for some reason that's the movie in my head.
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?
Forum Responses
(Business and Management Forum)
From contributor G:
For reading it a while ago, you remember most of it. The "Drum" was instrument setting the cadence, or work pace. The rope tied the processes together. In production the rope can be how you release material, and when. The buffer is placed in front of Herbie so that any problems in front of him don't unnecessarily slow his pace.
"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.
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.
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.
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.
