Kanban — Japanese for "signboard" or "card" — is the signaling mechanism behind a pull production system. Instead of an upstream process producing to a forecast and pushing output downstream regardless of whether it's needed yet, a pull system only produces when a kanban card, freed up by actual downstream consumption, authorizes it. Taiichi Ohno developed the system at Toyota after observing how American supermarkets restocked shelves: only what a customer actually took off the shelf got reordered, in the quantity taken, not according to a separate forecast for the warehouse.
The practical effect is a hard cap on work-in-process. A loop with 20 kanban cards can never have more than 20 containers' worth of inventory in it, no matter what happens upstream — which is exactly the point: overproduction, one of the classic Lean wastes, becomes structurally impossible rather than something to catch after the fact.
Why Kanban Matters
Caps Work-in-Process by Design
The number of cards in a loop is a hard, physical limit on inventory — overproduction can't happen quietly the way it can in a push system.
Simplifies Scheduling
Upstream stations respond to a visible signal instead of needing a separate, continuously updated production schedule.
Makes Problems Visible Fast
A pile of waiting kanban cards, or an empty card rack, is an immediate, visual signal that something upstream or downstream has stopped.
Supports Continuous Improvement
Deliberately removing cards over time tightens the loop and exposes the next bottleneck, a classic Kaizen use of a Kanban system.
Core Terms
| Term | Meaning |
|---|---|
| Pull System | Production is triggered only by an actual downstream consumption signal, not a forecast. |
| Push System | Production is triggered by a forecast or schedule, independent of whether downstream is ready for the output. |
| Production Kanban | A card that authorizes an upstream process to produce one more container of a specific part. |
| Withdrawal Kanban | A card that authorizes moving one container of parts from a supplying process to a consuming process. |
| Kanban Loop | The closed cycle a card travels through: attached to a container, detached on consumption, returned to trigger replenishment. |
| Heijunka | Production leveling, often used alongside Kanban so the pull signal doesn't itself create erratic upstream demand. |
How a Kanban Loop Works
- A downstream workstation consumes the last part from a container and removes the kanban card attached to it.
- The card is placed in a visible collection point — a rack, a board, or a digital queue.
- The upstream (supplying) process sees the card and produces exactly one replacement container, no more.
- The new container, with its card attached, is delivered to the downstream point of use.
- The cycle repeats, and at no point does total inventory in the loop exceed the number of cards in circulation.
Sizing a Kanban Loop
The Kanban Quantity Calculator runs this formula directly. The worked example below shows exactly where each input comes from.
Worked Example: Brakeline Assembly's Fastener Kanban
A sub-assembly line consumes an average of 480 fasteners per day from a supplying process. The supplying process has a lead time of 1.5 days to replenish a container, the team wants a 20% safety factor to cover normal demand variability, and each container holds 60 fasteners.
- Average Daily Demand = 480 fasteners/day.
- Lead Time = 1.5 days.
- Safety Factor = 20% (0.20).
- Container Quantity = 60 fasteners.
- Total coverage needed = 480 × 1.5 × 1.20 = 864 fasteners.
- Number of Kanbans = 864 / 60 = 14.4, rounded up to 15 cards.
Fifteen cards means the loop can hold at most 15 × 60 = 900 fasteners at any time — enough to cover demand through the 1.5-day replenishment lead time plus the agreed buffer, and not a single container more. As the team improves and shortens the supplying process's lead time, this same formula tells them exactly how many cards to remove.
A Kanban Loop on the Floor
The most common physical implementation is a two-bin system: one bin is in use at the workstation while a second, identical bin sits in reserve. When the in-use bin empties, it (or its card) goes back to trigger replenishment, and the reserve bin takes its place — no separate card is even strictly required if the empty bin itself is the signal.
Self-Assessment Questions
Before trusting a Kanban loop to run itself, a team should be able to answer yes to each of these:
- Is demand for this part stable enough for a pull system, or does it need leveling first?
- Was the card count calculated from real demand and lead-time data, not a guess?
- Does everyone upstream understand that producing without a card is not allowed, even to "get ahead"?
- Is there a scheduled date to re-check the sizing as demand or lead time changes?
- Would a card go missing be noticed the same shift it happens?
Common Mistakes
Sizing the Loop Once and Never Revisiting It
Demand and lead times change; a card count set a year ago is either starving the line or hiding excess inventory it no longer needs to.
Adding Cards to Solve a Shortage
A chronic shortage is usually a lead-time or capacity problem; adding cards masks it by growing the inventory buffer instead of fixing the cause.
Running Kanban on Highly Erratic Demand
A pull system assumes reasonably stable, repeating demand; a leveling practice like Heijunka is usually needed first if demand swings widely.
Treating Cards as Optional
A supplying process that produces without waiting for a card — "getting ahead" — reintroduces the exact overproduction Kanban is meant to prevent.
Quick Reference
Setup Checklist
- Confirm demand is stable enough for a pull system, or level it first.
- Measure actual average daily demand and current lead time.
- Agree on a safety factor with the team, not just management.
- Choose a container quantity that's practical to handle and count.
Using the Result
- Re-size the loop whenever demand or lead time shifts meaningfully.
- Never let a supplying process produce without a card.
- Treat a chronic shortage as a lead-time problem, not a card-count problem.
- Remove cards deliberately over time to tighten the loop and expose the next bottleneck.
Sources and Further Reading
- Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production.
- Taiichi Ohno, Workplace Management.
- Yasuhiro Monden, Toyota Production System: An Integrated Approach to Just-In-Time.
- ASQ Certified Quality Engineer Body of Knowledge.