Improving every step of a process by 10% often changes nothing. Output is set by the slowest step, the constraint. Improving anything else just builds a bigger pile in front of it.
Where it comes from
Eliyahu Goldratt's Theory of Constraints, made famous by his 1984 novel The Goal, gives five focusing steps:
- Identify the constraint.
- Exploit it: make sure it never waits and never works on things that aren't needed.
- Subordinate everything else to it: no step produces faster than the constraint can take.
- Elevate it: add capacity, only after the first three.
- Repeat, because the constraint moves.
Two numbers go with it. Takt time is the available time divided by customer demand: how often one unit must finish to keep up. Little's Law (John Little, 1961): in a stable process, average lead time = average work in progress ÷ throughput.
How a bot helps
From the system's timestamps, a bot can compute for each step how many items arrive, how many finish, how long each takes, and how long each waits. The constraint is usually the step whose capacity is closest to demand and with the most consistent queue in front of it.
A big queue is a clue, not proof. The queue might be in front of a step that's starved by an earlier problem, or batched on purpose. A person confirms by watching the step.
On the bots' own work
In a bot team, the constraint is almost always the person's review. Bots produce drafts faster than anyone can read them. Exploiting the constraint means making each review count: smaller, clearer, already checked. Subordinating means bots don't produce more than can be reviewed. See WIP limits.
When to use it
When lead times are long and adding effort doesn't help. Medium.
Where bots differ
Timestamps show when a record changed, not when work happened. Before computing anything, a bot should check that the timestamps mean what it assumes.
Sources: The Goal (novel); Little (1961), A proof for the queuing formula L = λW.
Back to Engineering tools for bots.
Short outline
Capacity and bottlenecks: short outline
What it's for
Capacity analysis finds the step that limits output (the constraint) from arrival, finish and wait times per step, compares it with takt time, and applies the five focusing steps there first.
Columns
| Column | What goes in it |
|---|---|
| Step | One row per process step, in order |
| Arrivals per period | Items arriving at the step |
| Finished per period | Items leaving the step |
| Work time per item | Time actually spent working, with its source |
| Wait time per item | Time in the queue before the step |
| Capacity | Items the step can finish per period |
| Load vs. capacity | Demand as a percent of capacity |
| Constraint? | Yes, no, or suspected, with what confirmed it |
| Takt time | Available time divided by demand |
Steps, each with its "done when"
- Check what the timestamps mean. Done when each timestamp used is confirmed to mark a real start or finish of work.
- Measure every step. Done when every step has arrivals, finishes, work time and wait time for the same period.
- Compute capacity, load and takt. Done when each step shows capacity and load, and takt time is calculated from demand.
- Find and confirm the constraint. Done when one step is named the constraint, and a person has watched it to confirm.
- Apply the focusing steps in order. Done when actions are listed for exploit and subordinate before any for elevate, each with an owner.
Common mistakes
- Improving steps that aren't the constraint.
- Treating the biggest queue as proof of the constraint.
- Adding capacity before exploiting what is there.
- Timestamps that mark a record change, not the work.