The theory of constraints

Eliyahu M. Goldratt · 1984

Every system has one bottleneck at a time, and improving anything else changes nothing.

Its place in the frameworkBusiness Core›Operational Systems

What it does

Find the constraint, get everything possible out of it, subordinate the rest of the system to it, then lift it — and when it moves, start again. The counter-intuitive part is subordination: deliberately running other parts below capacity, which looks like waste on every local measure and is the only thing that raises throughput.

Reach for it when: When a process has been optimised in many places and the output has not moved.
Where it stops: It assumes a system with a stable, findable bottleneck. In knowledge work the constraint moves, is often a person’s attention, and does not sit still to be measured.

Eliyahu M. Goldratt & Jeff Cox, The Goal, North River Press, 1984.

Why it sits at Operational Systems

How the work actually gets done — the processes, tools and standards that turn intention into output without requiring a decision every time.

A model is only useful when you reach for it at the right moment. This one answers a question that arises here — so it is filed here, and nowhere else. These are the working areas it serves:

Process designProcess mapping and value stream analysis, which distinguish steps that add value from steps that merely add time.
ToolingWork on the fit between technology and process, and the recurring finding that implementing a system without redesigning the process encodes the old inefficiency.
Standards and qualityStandard work in lean practice, and quality management’s distinction between inspecting defects out and designing them out.
Continuous improvementDeming’s plan-do-check-act cycle, and kaizen practice on small changes made by the people doing the work.

All of Operational Systems

What it touches elsewhere

Nothing in a business is decided on its own. A conclusion reached with this model at Operational Systems lands in these other cores, whether or not anyone follows it there.

Goal CoreMost tactical goals land on an operational system, whether or not they say so.
Omni CoreWhat the customer experiences is produced by these systems, not by intentions about service.
Data CoreProcess measures are what tell you whether a system is working before customers do.
Business CoreSystems, people and assets are the three things every operation runs on.

Filed at the same place

These answer questions that arise at Operational Systems too. Where they disagree with this one, the disagreement is the useful part.

Lean thinkingDefine value from the customer’s side, then remove everything in the flow that does not create it.
Porter’s value chainBreak the business into the activities it actually performs, and ask which of them the customer is paying for.
The McKinsey 7S frameworkSeven things that have to agree with one another for an organisation to work: strategy, structure, systems, shared values, style, staff and skills.

Elsewhere in Business Core

These are other people’s models, named here so you can go to the source and use them properly. The Omnigoal is not affiliated with their authors and is not endorsed by them; nothing of theirs is reproduced here — no canvas, no diagram, no wording. Each is described in our own words, with the originator credited, because the framework is a place to put thinking, not a replacement for the people who did it. Model names and trademarks belong to their respective owners and are used here only to refer to the work itself.

All 125 models