Why Kanban cards let downstream demand control the line — instead of a forecast that's guessing at it.
Every production stage has to decide when to make the next unit. There are only two fundamentally different ways to answer that question. A push system answers it with a forecast: make units on a schedule, then send them forward whether or not the next stage is ready. A pull system answers it with a signal: make a unit only when the downstream stage has actually used one and asks for a replacement. That single difference — schedule-driven vs. signal-driven — is the entire reason Kanban and Just-In-Time production exist, and it has direct, measurable consequences for how much work-in-process inventory piles up between stations.
Push — produce to a forecast, then send it on.Each stage is given a schedule (derived from a demand forecast, a production plan, or an MRP run) and produces to that schedule regardless of what's happening downstream. Output is pushed forward the moment it's finished. If the forecast is right, this works fine. If actual downstream demand is slower than predicted — which it almost always is, to some degree — upstream stages keep producing anyway, because the schedule told them to, not because anyone downstream asked for more.
Pull — produce only when a real signal says to. Each stage produces only after receiving an actual signal from the downstream stage — traditionally a physical Kanban card, today often an electronic equivalent — indicating that stage just consumed a unit and needs a replacement. Production is triggered by real, already-happened consumption, never by a prediction of consumption. Because the number of Kanban cards in circulation is fixed, upstream production physically cannot get ahead of what downstream has actually signaled it needs — the card count sets a hard ceiling on work-in-process.
Push systems are only as good as the forecast driving them, and real demand almost never matches a forecast exactly. When actual demand runs slower than predicted, a push system doesn't notice — upstream stages keep producing on schedule, and the gap between what was made and what was actually needed accumulates as work-in-process inventory sitting in buffers. Pull systems sidestep the whole problem by never producing from a prediction in the first place: a Kanban card only exists, and only travels backward, when a real unit was really consumed. Because the number of cards in the system is fixed, the maximum WIP the system can ever hold is capped by that card count — production upstream is physically incapable of outrunning real downstream need. This is exactly the mechanism behind Kanban and Just-In-Time (JIT) production: not a scheduling preference, but a structural limit on overproduction.
False, and it's not a small distinction. Push systems are fundamentally exposed to forecast error: production is based on a prediction of demand, and when reality deviates from that prediction — which it almost always does to some degree — the system either overproduces (excess work-in-process inventory, tied-up capital, obsolescence risk) or underproduces (stockouts, missed demand). Pull systems don't make that bet at all. They're self-regulating against actual downstream consumption, which directly caps work-in-process inventory and — just as importantly — makes problems visible immediately: if a downstream station stalls or a quality issue stops consumption, the Kanban signal simply stops arriving and upstream production naturally stops with it, rather than continuing to pile more inventory into an already-backed-up system. This is a genuine structural difference in how the two systems respond to real-world demand variability — not an equivalent choice of bookkeeping convention.
Push and pull are the two fundamentally different ways a production stage can decide when to make the next unit. A push system produces to a forecast or predetermined schedule and sends output forward regardless of whether the next stage is actually ready for it — if the forecast is wrong, work-in-process inventory piles up between stations. A pull system produces only when it receives an actual signal, traditionally a Kanban card, that the downstream stage has consumed material and needs a replacement — production is triggered by real consumption, never a prediction, so work-in-process is capped by the number of Kanban cards in circulation.
A push system's entire output is only as good as its forecast. Every forecast has error, and that error doesn't announce itself — a push system has no built-in way to detect that actual demand has diverged from plan. When demand runs slower than forecast, upstream stages keep producing on schedule anyway, because the schedule — not real downstream need — is what's driving them. The gap between what was produced and what was actually needed accumulates as work-in-process inventory sitting in buffers between stations, tying up capital, floor space, and carrying real risk of obsolescence if conditions change before that inventory is consumed.
A Kanban card is a physical (or electronic) authorization to produce exactly one unit, and it only enters circulation for a downstream station backward toward the upstream station when that downstream station has actually consumed a unit. Because the total number of cards in the loop is fixed by design, there is a hard mathematical ceiling on how much work-in-process the loop can ever contain: upstream production simply cannot happen without an available card, and a card only becomes available through real consumption. This is the mechanism, not a side effect — it's why Kanban systems are self-limiting on inventory in a way that scheduling to a forecast never can be.
Just-In-Time production philosophy is built entirely on pull logic: make nothing until something downstream actually needs it. This does more than control inventory cost — it makes production problems immediately visible. In a push system, a stalled or defective downstream station doesn't stop upstream production; excess inventory just keeps piling up in front of the problem, often masking it. In a pull system, a stall stops the Kanban signal from arriving, which stops upstream production almost immediately — surfacing the problem right where and when it happened, instead of burying it under more inventory.
Not always — push (MRP-driven scheduling) can work well when demand is genuinely stable and forecastable, or for components with long lead times that must be started well ahead of firm orders. But push is structurally exposed to forecast error in a way pull is not, which is why most lean systems use pull wherever variability and short lead times make it feasible, often blending the two (e.g., push far upstream, pull near the customer).
Traditionally a small card or ticket attached to a container or batch of parts, marked with what to produce, how much, and where it goes. It travels with the material to the downstream consuming station; once that material is used, the card is detached and sent back upstream as the authorization — and only authorization — to produce a replacement. Electronic Kanban systems replicate the same signal digitally, without a physical card.
Each card represents permission for exactly one unit (or one standard container) of work-in-process to exist between two stages. If there are N cards circulating in a given loop, there can never be more than N units of WIP in that loop at any moment, because a unit can't be started without an available card, and a card only becomes available after a unit downstream is actually consumed.
No — it caps it at a deliberately chosen level (set by the number of Kanban cards, which is usually sized using formulas that account for demand rate, replenishment lead time, and a safety margin), rather than eliminating it. The goal isn't zero inventory; it's inventory that's bounded and directly tied to real consumption, instead of unbounded and tied to a forecast's accuracy.
In a pull system, production only continues when the Kanban signal keeps arriving. If a downstream station stalls (breakdown, quality issue, changeover), the signal stops, and upstream production stops almost immediately with it — surfacing the stall right away. In a push system, upstream stages have no such feedback and keep producing on schedule, so the stall is hidden behind a growing pile of inventory until someone notices the buffer overflowing.
Try our Industrial & Systems Engineering Studio
More calculators, simulators, and guides for this discipline.