Pull flow and kanban

Definition

Pull flow reverses the logic of replenishment: nothing moves until something has been consumed. Kanban is its best-known implementation, where a card travelling with a container becomes the authorisation to reproduce or replenish. Its deeper value is not in the card but in what the card imposes: the number of cards in circulation caps work in process, and that cap governs both throughput and cycle time.

Page signature
The WIP cap governs everything
Boucle kanban : les cartes plafonnent l’encours P1 P2 bottleneck P4 Débit, en part de la capacité du bottleneck 100% 0 ideal actual Cycle time critical WIP 1 card 30 cards
Cards in the loop
·
Throughput, actual
·
Cycle time
·
Slide: past critical WIP you no longer buy throughput, only cycle time.

Why it matters

A cap, not a forecast.

Every policy seen so far shares one assumption: you anticipate demand, compute a threshold or a target level, and order accordingly. Pull flow works differently. It does not try to forecast but to react: actual consumption releases a signal, and that signal alone authorises replenishment. Nothing moves forward without being called by the downstream stage.

Kanban makes that signal physical through a card attached to a container. When the container is opened or emptied, the card detaches and travels back: it becomes the order to remake or deliver. The device is disarmingly simple, often visual, understood by everyone on the floor, and it runs without daily calculation.

But the essential point lies elsewhere, and standard presentations usually miss it. Since you can only produce or order while holding a card, the total number of cards in circulation is a hard cap on work in process. The system can never accumulate more. That cap is not a side effect: it is the real control parameter, and it simultaneously determines achievable throughput and cycle time.

This is what radically separates pull from push. Under push, you release according to a plan, and work in process is whatever remains when reality departs from the plan: nothing bounds it. Under pull, work in process is decided in advance, and performance is what adjusts. You choose the constraint instead of enduring it.

Business impact

The signature above is what queueing theory calls the throughput versus work-in-process curve. It shows three regimes. Below a certain level, the line starves: the bottleneck waits for work, throughput is capped by too few cards rather than by capacity. Around critical WIP, throughput approaches bottleneck capacity while cycle time is still short. Beyond it, throughput plateaus but cycle time keeps growing, in a straight line.

That last zone is the most poorly exploited opportunity in industry. Adding cards is reassuring: you see stock, stations never run dry. But the curve is unambiguous, you no longer buy any throughput, you buy only cycle time, hence tied-up capital, long cycles and degraded responsiveness to change.

The expert lesson: treat the number of cards as a leadership decision, not a shop-floor setting. Set it near critical WIP, then reduce it deliberately, step by step. Each card removed tightens the system and exposes the next problem, a breakdown, a changeover that is too long, unstable quality. This is the virtue the Japanese school identified: kanban does not solve problems, it makes them visible in the order in which they should be tackled.

The mechanism

Count the cards, read Little’s law.

Sizing a kanban loop answers a simple question: how many containers are needed to cover consumption while the loop closes? You therefore need average consumption, the total duration of the card cycle from detachment to reintegration, and the capacity of one container. The number of cards is the ratio between what is consumed during the cycle and what a container holds, plus a margin for uncertainty.

The second equation runs deeper and connects to everything else on this page. Little’s law states that average work in process equals throughput times cycle time. This relationship is an identity, valid with no assumption about the nature of the process. It means that if throughput is constrained by the bottleneck, then any increase in work in process converts entirely into longer cycle time. Nothing else is possible.

The second panel of the signature makes that consequence visible. The cycle-time curve grows strictly linearly beyond critical WIP, precisely because throughput no longer moves. The two curves must be read together: the first states what you gain, the second what you pay. The gap between the ideal and the actual case measures the price of variability, breakdowns, quality issues, changeover times.

One caution on scope. Pull flow assumes consumption regular enough for the signal to travel around the loop in time. On references with erratic or highly seasonal demand, the card arrives too late or sits idle too long: the device drifts out of tune. This is why it is reserved for steadily moving items, with the rest steered another way.

K = D · Tc · ( 1 + α ) / C       I = T · Dt
K the number of cards, D average consumption, Tc the full duration of the card cycle, α the safety margin and C the capacity of one container. The second relationship is Little’s law: work in process I equals cycle time T times throughput Dt. Its reach is considerable, because it is an identity rather than a model: as soon as throughput is capped by the bottleneck, any extra work in process turns entirely into cycle time. That is the mathematical reason why adding cards beyond critical WIP never buys performance.

The traps

Three pull-flow errors.

01

Adding cards for reassurance

When a stoppage occurs, the reflex is to add cards. Beyond critical WIP this no longer raises throughput and lengthens cycle time, degrading precisely the responsiveness you were trying to recover. The right question is the cause of the stoppage, not the number of containers.

02

Applying it to erratic demand

Pull flow lives on a regular signal travelling around the loop. On intermittent or strongly seasonal references, the card returns too late or sleeps too long. The device loses its meaning and a computed threshold policy performs better.

03

Freezing the card count

A sizing established once ages like any other parameter. Volumes change, cycle times shrink, suppliers improve. A loop that is never retightened keeps work in process calibrated on conditions that no longer exist, and hides the gains made in the meantime.

The rollout

Five steps to tighten a loop.

Select eligible references

Reserve pull flow for items with regular consumption and steady movement. Cross volume and regularity to rule out erratic profiles from the start, since they belong to a different policy.

Measure the real card cycle

Time the full loop: detachment, transmission, waiting, replenishment, reintegration. It is this total time, often far longer than production time, that drives the number of cards.

Size near critical WIP

Compute the card count then test it against the throughput versus WIP curve. Aim near the critical point rather than at a comfortable margin that would buy only cycle time.

Remove cards in steps

Deliberately reduce work in process, one notch at a time, and fix the problem each removal exposes. This is the continuous-improvement mechanism built into the device, and its real value.

Revise with volumes

Recompute loops as consumption or cycle times evolve, and take out references that have become irregular. A living loop follows its product, a frozen loop betrays it.

Neighboring concepts

Read next.

From knowledge to action

Have your pull loops been retightened since go-live?

Work in process calibrated on old conditions costs cycle time and buys no throughput. Our Inventory & distribution file resets your loops on critical WIP and organises their tightening.