How to Use Theory of Constraints in a Business Process

Theory of Constraints started as a way of thinking about factory output, but its core claim applies just as well to a claims process, a hiring pipeline, or an invoice approval chain: a process can only move as fast as its slowest constrained step, and improving any other step does nothing to change that. A team can speed up data entry, reduce a form's field count, and streamline a notification email, and still see no change in overall cycle time, because none of those steps were the constraint in the first place.

This is a hard lesson for teams that are eager to show progress, because it means some genuinely good improvements will produce no visible result at the process level. The five focusing steps exist to stop that wasted effort by directing improvement work at the one place it can actually change the outcome.

Step one: identify the constraint

The constraint is the step that limits how many cases the whole process can complete in a given period, regardless of how much capacity exists elsewhere. It is usually the step with the longest queue, the highest utilization, or the one where cases consistently wait the longest before being picked up. It is not necessarily the step people complain about most, because complaints tend to follow visibility and frustration rather than actual delay. A claims team might complain loudly about a clunky document upload tool while the real constraint is a three-day wait for a supervisor's sign-off on anything above a routine value, a step that produces no complaints because it happens quietly in someone's inbox.

Identifying the constraint properly usually requires looking at how a realistic volume of cases actually flows through the process, not a single example case walked through by hand. A single case rarely encounters the queue that forms when dozens of cases compete for the same limited approval capacity at once.

Step two: exploit the constraint

Exploiting the constraint means getting the maximum output from it without spending any money or adding any capacity. If the constraint is a supervisor's approval queue, exploiting it might mean making sure the supervisor never sits idle waiting for the next case, that cases are batched or prioritized sensibly, that lower-value approvals that do not truly need supervisor attention are removed from the queue entirely, and that the supervisor is not being pulled into unrelated work during their approval window.

This step is frequently skipped because it feels less impressive than adding headcount or new technology, but it is usually the cheapest and fastest source of improvement available. A constraint that is fully exploited before anything else changes often reveals that the real gap was smaller than it first appeared.

Step three: subordinate everything else to the constraint

This is the step most organizations get wrong instinctively, because it asks every other part of the process to slow down or adjust to match the constraint's pace, rather than each step optimizing for its own local efficiency. If the approval queue can only clear forty cases a day, then having the intake team process eighty cases a day just builds a bigger pile in front of the constraint. It does not speed anything up. It makes the queue longer and the average wait worse.

Subordination often means deliberately not maximizing throughput at a non-constrained step, which runs against most teams' instincts and incentive structures. A team measured purely on how many cases it processes per day will resist slowing down, even when slowing down does not change how quickly cases actually complete the full process, because the constraint elsewhere was always going to gate the pace regardless.

Step four: elevate the constraint

If exploiting and subordinating still leave the constraint limiting overall throughput below what the business needs, the next step is to add capacity at the constraint itself. This might mean adding a second approver, redistributing approval authority so more cases can clear without a single person's sign-off, or introducing automation or an AI agent for the specific portion of the constrained step that is repetitive or rule-based enough to support it.

Elevating the constraint is the step that costs money or requires organizational change, which is exactly why it should come after exploiting and subordinating, not before. Adding a second approver to a queue that was mostly sitting idle between batches, because exploitation had not yet been tried, is capacity spent on a problem that a scheduling fix could have solved for free.

Step five: go back to step one

Once a constraint is elevated enough that it is no longer the limiting factor, the constraint moves somewhere else in the process. This is not a failure of the previous work, it is the expected outcome. A process that gets faster at its old bottleneck will always reveal a new one, because some step was always going to be the current limit. Theory of Constraints is a cycle, not a one-time fix, and treating it as a single project rather than a habit is why some improvement efforts produce a burst of progress that then stalls.

Testing each step before committing resources

Because elevation usually involves cost, whether that is headcount, a system change, or an automation build, it is worth testing the expected effect before committing. Simulating the process with a proposed change, such as a second approver or a reduced set of cases requiring sign-off, shows whether the constraint would actually move and by how much, before any budget is spent. It also tests whether the new constraint that emerges afterward is somewhere the business is prepared to address, since elevating one constraint only to reveal a harder one immediately behind it is not always worth the cost.

The answer is not always AI

Elevating a constraint does not automatically mean introducing AI. Sometimes the right move is redistributing decision authority, adding a person, or removing a rule that forces unnecessary cases into the constrained step. AI is worth considering only where the constrained step genuinely involves judgment or language interpretation that a fixed rule set cannot handle well, and only after exploitation and subordination have already been tried.

How Processfix supports this discipline

Processfix's case explorer and simulation make the constraint visible by running a discrete-event Monte Carlo simulation across hundreds of realistic cases, showing where queues form, which step has the highest utilization, and where cases actually wait longest. Once a locked baseline exists, a team can test Improve and Add AI scenarios that exploit, subordinate around, or elevate the constraint, and compare the results against the baseline on P50, P90, throughput, utilization, and estimated labor impact before deciding what to implement.