Constraint Exploitation Plan: Turn One Diagnosed Bottleneck Into a Pilot Worth Running

The Constraint Exploitation Plan applies Theory of Constraints to maximise throughput at the binding constraint. It asks you to work three steps in order: exploit what you already have, subordinate everything else to the constraint, then elevate capacity only if the first two steps leave a gap.

You use it in the Improve phase of RDMAICS, after Analyse has told you where the flow actually stops. That order matters. The tool assumes you already know which step is binding. If you are still guessing, go back and measure. A plan built on the wrong constraint moves effort away from the place that governs output.

The output is a structured improvement plan. Each row names a constraint, a Theory of Constraints step, an action, an expected effect and an owner. That is enough to brief a pilot. It is also enough to argue about honestly, which is the more useful property.

Everything below uses the sample data that ships with the tool. The case is fictional. It exists to show the shape of a good plan, not to report a real result.

The case concerns an invoice process. The binding constraint is an approval step. Work arrives faster than approvals clear, so queues build in front of the approval and starve the steps behind it. A second constraint sits behind the first: data entry, marked as the next constraint in line.

Four rows carry the whole plan. Three of them attack the approval step through exploit, subordinate and elevate. The fourth looks ahead to data entry. That is the discipline the tool enforces. You do not spread four actions across four different problems. You concentrate them on one constraint and keep one eye on what becomes binding next.

The worksheet has five columns. Constraint, TOC Step, Action, Expected Effect and Owner. Fill them in that order, because the order carries the logic.

Name the constraint plainly and mark the binding one. The sample uses "Approval step (binding)" on the first row and plain "Approval step" on the two that follow. The data entry row is labelled "Data entry (next)". Those labels do real work. Anyone reading the plan can see which problem is live and which is queued.

Choose the TOC Step before you write the action. If you write the action first, you will almost always write an elevate action, because adding capacity is the easiest thing to imagine. Forcing the step first makes you ask the cheaper questions earlier.

Write the expected effect as a claim, not a hope. The sample rows claim "Reduce approvals 70%", "Smooth flow", "Throughput +50%" and "Eliminate constraint". Three of those are testable. One, "Smooth flow", is softer. More on that later.

Row one is the exploit move. Finance eliminates low-value approvals via a threshold, with an expected effect of reducing approvals by 70 per cent. No new people. No new system. The constraint simply stops being asked to process work that never needed its attention.

Row two is the subordinate move. AP matches the upstream and downstream rate to the approval rate, with an expected effect of smooth flow. This row adds no capacity at all. It stops the rest of the process from overloading the constraint and from idling behind it. Subordination is the row teams most often skip, and skipping it is why exploit gains often fail to show up in the end-to-end measure.

Row three is the elevate move. Finance adds parallel approvers for exceptions, with an expected effect of throughput plus 50 per cent. This is the row that costs money. It sits third deliberately. You only buy capacity for the work that survives rows one and two.

Row four steps outside the current constraint. IT introduces OCR to remove manual entry at the data entry step, with an expected effect of eliminating that constraint. It is marked as next, not binding. It belongs in the plan so the team knows where the queue moves once approvals clear.

The tool produces a structured improvement output built from the worksheet. The sample case shows four populated worksheet rows, with the first four shown. Each action becomes a headed card carrying its constraint, TOC step, expected effect and owner.

That restructuring is the point. The worksheet is good for drafting. The result is good for reading aloud in a review. A sponsor can scan four cards and see that Finance owns two actions, AP owns one and IT owns one. They can also see that three cards share a single constraint.

The tool also offers an AI review that explains the result in plain language. Treat it as a second reader. It will not know your process, but it will tell you how your plan reads to someone who was not in the room.

The first decision is sequencing. The plan tells you to pilot the threshold change before you add parallel approvers. If reducing approvals by 70 per cent lands, the capacity you were about to buy may not be needed at the size you assumed.

The second decision is sizing the gain before you commit. You have two quantified claims on the same constraint: reduce approvals 70 per cent and throughput plus 50 per cent. Those are the two numbers to test. Run the exploit row first, measure against the 70 per cent claim, then revisit whether the elevate row still clears your threshold for spend.

The third decision is where to look next. The data entry row with its OCR action tells you the plan does not end when approvals clear. Throughput will rise only until the next constraint binds. Having that row written down stops the team declaring victory too early.

The fourth decision is ownership. Finance carries two rows, AP one, IT one. If one function carried all four, that would be a scheduling problem worth raising before the pilot starts.

The most common mistake is jumping straight to elevate. Adding people or systems is visible and satisfying. It is also the step that converts a flow problem into a cost problem. In the sample, elevate sits behind a 70 per cent reduction in approval volume. Do that work first.

The second mistake is writing soft expected effects. "Smooth flow" on the subordinate row is honest but hard to test. If you use that row in your own plan, pair it with something you can observe, such as queue length in front of the constraint. A plan where every effect is vague cannot be reviewed.

The third mistake is spreading rows across unrelated problems. Four rows against four different constraints is not a constraint plan. It is a wish list. The sample keeps three of four rows on the approval step for a reason.

The fourth mistake is treating the plan as finished work. Every expected effect in the sample is a claim awaiting evidence. The plan tells you what to pilot. It does not tell you the pilot succeeded.

The tool will not find your constraint. It assumes the binding step is already identified and labelled. If Analyse was thin, the plan will be confidently wrong. The sample marks the approval step as binding because that conclusion was reached earlier, not because the tool worked it out.

It will not validate your expected effects. The figures of 70 per cent and plus 50 per cent are inputs, not calculations. The tool restructures what you typed. Anyone can type an optimistic number. Only a pilot can test one.

It will not cost your actions or schedule them. There is no field for effort, spend or date. Parallel approvers and OCR both carry real cost in practice, and neither appears here. You will need a separate pilot plan and a Control phase measure to carry the work forward.

It will not tell you when the next constraint binds. The data entry row flags what is next, but the timing is yours to watch. Expect to return to this tool after the first pilot, relabel which constraint is binding, and build the next four rows. That loop is the tool working as intended.