Theory of Constraints Simulation
Finding a Constraint That Moves

Goldratt’s five focusing steps begin with “identify the constraint.” On a whiteboard that’s one step. On a line with breakdowns, buffers and a changing product mix, the constraint rarely sits still long enough to be identified once. So in practice it makes sense to simulate the constraint instead of assuming it.

The five focusing steps

Theory of Constraints (TOC) comes from Eliyahu Goldratt’s The Goal. Its premise is that one constraint at a time limits a system’s output, so improving anything that isn’t the constraint doesn’t improve output. The method is five steps, repeated:

1. Identify the constraint, the resource that limits the throughput of the whole system.
2. Exploit it. Get the most out of it as it stands, with no idle time, no wasted capacity and no defective work reaching it.
3. Subordinate everything else. Run every other resource to the constraint’s pace, not to its own local efficiency.
4. Elevate it. If it’s still binding, add capacity: another machine, a faster one, more hours.
5. Repeat. Once a constraint is broken, something else becomes the constraint. Go back to step one, and don’t let inertia (rules written for the old constraint) become the new one.

None of that is controversial. The hard part is almost entirely step one, and whatever goes wrong there carries into the other four.

The assumption hidden in step one

The five steps read as though the constraint is a fixed property of the line: one machine, found once, then managed. On a paced line with reliable equipment, that’s close to true. On a high-speed packaging or process line it usually isn’t, for three reasons.

Downtime moves it

When a machine stops and the storage beside it runs out, that machine limits the line, whatever its rated speed. Minutes after it restarts, something else is. Which machine is limiting output at any moment depends on what failed last and how much storage sat between it and its neighbors.

Product mix moves it

Different formats run at different rates on different machines. Change the package size and the machine that was binding on one SKU may have slack on the next.

The schedule moves it

Changeovers, sanitation windows and staffing each take a resource out of the flow for a period, and for that period the constraint is whatever they took out.

Two plants where step one went wrong

The constraint that moved with the package

A quality initiative added a stage to an existing Make-Store-Pack coffee operation. The problem turned out to be scheduling, not the new stage. As packaging sizes changed, the bottleneck moved, because a different format draws from the store at a different rate and shifts which stage is binding. The plant’s Advanced Planning System was optimizing against a constraint that wouldn’t hold still.

A discrete rate model that reproduced the moving bottleneck, rather than assuming it away, let the team test and verify a new scheduling algorithm across a range of demand scenarios before deploying it. In TOC terms, the model made step one honest, because the constraint was identified per format instead of once. It also let step three be tested before it was trusted. The account is qualitative, from our project record. See The Shifty Bottleneck.

The constraint everyone could see

At a specialty olive packer, the pitting machines take about two hours to change over between olive sizes. They are a known bottleneck. A capacity model of the whole plant confirms it and finds other choke points downstream, in packaging after the cans are filled and retorted. Scheduling rules tested in the model, including a Theory of Constraints-based daily schedule, recover 15% more throughput with no new equipment. That work predates ReliaSim as a product. The same team did it with the same rate-based method, and it’s written up in the olive plant case study.

Step 1 by simulation: identify

Simulation replaces the walk-around with a measurement. Build the line with each machine’s rate and its real interrupts (time to failure and time to repair for each failure mode), plus the buffers and conveyors between machines. Run it over a horizon long enough to include the rare events as well as the common ones. Then read three things:

• Starved and blocked time per machine. The constraint is the machine that’s neither, the one still running while everything around it waits. See Starved vs Blocked.
• Buffer levels. A buffer that runs chronically full points to a constraint downstream. One that runs chronically empty points upstream. See The Hidden Bottleneck.
• When each machine holds the role. The constraint timeline shows whether you have one dominant constraint or several machines trading it.

If one machine holds the role most of the time, classic TOC applies almost as written. If several share it, the steps apply to the set, and the “drum” has to be chosen deliberately.

Step 2: exploit it by ranking losses on what comes back

Exploiting the constraint means not wasting its time. On a production line most wasted constraint time is its own interrupts, plus the starvation and blocking its neighbors impose on it. The tempting shortcut is to attack the biggest downtime bar on the report. The measurement that holds up is to remove one failure mode in the model, re-run the whole line, and read how much output comes back.

Those two numbers routinely disagree. Two failure modes with nearly identical direct losses can return very different amounts of output, as micro stops vs breakdowns shows on our bottling line. Which loss to fix first covers the method in full.

Step 3: subordinate with drum, buffer, rope

Drum–Buffer–Rope is TOC’s scheduling form of subordination. The drum is the constraint’s pace, which sets the rate for the whole line. The buffer protects the drum. It’s stock placed ahead of the constraint so upstream stoppages don’t starve it, and in TOC it’s sized and managed in time rather than in units. The rope ties material release to the drum, so the rest of the system doesn’t overproduce into inventory the constraint can’t use.

On a continuous or high-speed line the buffer is physical, such as an accumulation table, a surge tank or an accumulating conveyor. That has two consequences, and simulation earns its keep on both.

• Protect both sides. A constraint loses time by being starved from upstream or blocked from downstream. Stock ahead of it covers the first; free space after it covers the second.
• Size on the stoppage distribution, not the average. A buffer covers a stoppage only while it has stock to give.

Plot efficiency against buffer capacity and the curve always bends, steep at first and then flat. Where the knee falls is specific to the line, so buffer size should be swept rather than guessed. How big should a buffer be? runs that sweep.

Step 4: elevate, then see where the constraint goes next

Elevation is where static TOC analysis is most likely to over-promise. Add capacity at the constraint and output rises only until the next-most-limiting resource starts to bind. After that, extra capacity at the old constraint produces nothing except more starved and blocked time elsewhere. The gain from elevating is the distance to the next constraint, not the size of the upgrade.

A model shows that distance before you pay for it. Raise the constraint’s rate or remove its dominant interrupt, re-run, and take the step-one readings again: which machine is now the constraint, how often, and how much output came back. If the next machine takes over almost immediately, the proposal is a two-machine project or a smaller one.

Step 5: repeat, and keep the model current

Goldratt’s warning about inertia is the step most often skipped. Product mix changes, a machine is rebuilt, or a buffer is removed to free floor space, and the constraint moves without anyone announcing it. A line model kept current turns step five into a re-run rather than a new study.

That only works if the model is validated against the line’s own history, per failure mode rather than only in aggregate. See the salad dressing plant case study.

Why dice games and spreadsheets stop short

TOC is usually taught with a dice game or a capacity spreadsheet, and both teach the principle well. Variability in a chain of dependent steps loses output, and the constraint governs. Neither can tell you about your line. A capacity spreadsheet takes each machine’s average rate and finds the minimum, which assumes the constraint is fixed and the variability averages out. A dice game has the right mechanism but none of your machines, failure modes or buffers.

Simulation keeps the mechanism and adds the specifics (each machine’s rate, each failure mode’s distribution, each buffer’s capacity), played forward through time. ReliaSim uses discrete rate simulation, which models flow as rates rather than individual items, so sweeps of thousands of runs finish in seconds.

Frequently asked questions

Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck.