Finding the Constraint is the Hard Part

Every operations leader knows the Theory of Constraints. Find the bottleneck. Exploit it. Subordinate everything else to it. Elevate it. Repeat.

The framework is elegant, and it works. Goldratt gave operations teams a mental model that cuts through complexity and focuses investment where it matters. Most leaders who run complex operations learned TOC years ago. Many have applied it successfully.

The trouble starts when the system gets complex enough that "find the constraint" stops being a straightforward instruction.

TOC assumes you can identify the constraint. In a simple linear process, you usually can. Measure throughput at each station, find the slowest one, focus there. But most real operations are not simple linear processes. They involve shared resources, variable demand, interdependent steps, and competing objectives across functions. In those systems, constraints behave in ways that make the five focusing steps harder to execute than they sound.

TOC acknowledges this. Drum-Buffer-Rope protects throughput at the constraint and subordinates everything else to it. The framework accounts for the concept of a moving constraint. What it does not provide is a way to predict where the constraint moves under conditions you have not yet seen, or how relieving one constraint loads a different resource three steps downstream.

Constraints move

A food processing plant runs multiple fillers fed by shared cleaning systems, ingredient tanks, and upstream pasteurizers. At 6 AM, the constraint is the CIP system because one cleaning cycle locks out three fillers for six to eight hours. By midday, the constraint has shifted to ingredient tank capacity because cream production overwhelmed available storage. By afternoon, a new high-speed filler is running below rated capacity because upstream and downstream processes cannot keep pace.

Ask the planning team where the bottleneck is, and the honest answer changes depending on when you ask. The constraint moves within a single shift, and each movement changes which intervention would actually improve throughput. Running TOC's five steps against the morning bottleneck might do nothing for the afternoon bottleneck. The team invests in fixing one pinch point and discovers the system didn't speed up because a different constraint was already binding by the time the fix took effect.

Constraints interact

A manufacturer operates seven production facilities, each with distinct machine configurations, and allocates orders across the network based on proximity and available capacity. On paper, each plant has a clear constraint: the machine or line that limits throughput for a given product.

When cutting constraints at individual machines entered a network optimization model, the answers changed completely. A plant that looked like the obvious choice for an order based on geography turned out to be the highest-waste producer for that product width. Another facility that would never have received certain orders under proximity logic turned out to produce them with the least material loss. A third plant appeared profitable in isolation but became structurally unprofitable once trim loss was visible at the network level.

The constraint was never any single machine. It was the interaction between product mix, machine configuration, and allocation logic across the full network. Every plant had run its own constraint analysis. Every plant had optimized against its own bottleneck. And the network was still leaving $20 million on the table because the real constraint lived between the plants, not inside them.

Constraints cross boundaries

An airport operation involves three organizations with separate P&Ls: the airline, the ground handler, and the airport authority. Each one controls resources that constrain the others. The airline owns maintenance decisions and crew scheduling. The ground handler owns turnaround staffing. The airport owns the gate layout and taxiway infrastructure.

When overnight maintenance runs long on two narrowbodies, the airline creates a gate shortage. The ground handler's turnaround crew, staffed for cost efficiency rather than the arrival pattern that actually shows up, compounds the delay. By early afternoon, the airline's connection bank arrives into a gate crunch that started eight hours earlier in someone else's operation, and the resulting misconnects trigger rebooking costs, crew legality pressure, and reportable delays that fall entirely on the carrier.

The organization paying the cost did not cause the constraint. And no single organization can run TOC's five steps against a bottleneck it does not control. Static capacity models flag the tightest resource within one organization's scope. They do not model how pressure in one operation creates backpressure that loads another's.

What changes when you model the system

Simulation runs the full operation with interactions intact. Instead of finding one constraint, it reveals the constraint map: which resources bind under which conditions, what happens when you relieve one, and where the next bottleneck emerges before you commit capital to the current one.

The planning team that applies TOC with spreadsheets and experienced judgment identifies the obvious pinch point, builds a case, and commits capital. Sometimes the constraint they fixed only bound under certain demand conditions. Sometimes the fix shifted the bottleneck to a resource nobody was watching. Sometimes the interaction effects across a network changed which facility was optimal in the first place. The investment was sound in isolation. The system did not cooperate.

Modeling the system changes the output from "here is the bottleneck" to "here are your options, here are the tradeoffs, and here is what holds under stress." Leaders can test interventions against realistic scenarios and see whether the improvement survives contact with the rest of the operation.

TOC gave operations leaders a powerful mental model. The gap is not in the framework. The gap is in the tools most teams use to apply it.

When constraints move, interact, and cross organizational boundaries, "where is the constraint?" becomes the wrong question. The better question is "how does the constraint system behave?" That question requires a model that runs.

Related reading:

When constraints move: How simulation helped a mining company invest in the right equipment, where variable ore grades, maintenance windows, and equipment capacity shifted the bottleneck across the full load-and-haul operation.

When constraints cross boundaries: How a mining operation synchronized rail, stockpile, and vessel scheduling, where no single link in the chain could be optimized without modeling the others.