Theory of Constraints

A throughput-limited system has one binding constraint. Improve only that constraint; local optimization of non-constraints wastes effort and often grows WIP.

When to Use

• Latency or throughput goal where one stage dominates time or rate.
• Work piles up before one stage; downstream idles.
• Adding capacity/workers elsewhere does not raise end-to-end output.
• Need ordered plan: exploit cheaply before spending to elevate.

When NOT to Use

• Load is spread; no stage dominates—use systems for interactions.
• Problem is correctness/fault, not flow rate—debug the fault.
• Bottleneck hops every run due to coupling/contention without a stable stage—systems or concurrency design, not five focusing steps.
• Constraint already known and a cheap fix is ready—apply it without ceremony.

Procedure