Organisations implement Kanban to eliminate overproduction and cap work-in-process. They print cards, train operators, draw floor markings, and set up supermarkets. For the first month, the pull logic holds: parts move only when consumed, signals trigger replenishment, and inventory stays within designed limits.
Then a supplier misses a delivery and someone bypasses the supermarket to keep the line running. A card slips behind a rack. A supervisor prints five temporary cards to bridge a quality quarantine. None of these actions get reversed. Within two quarters, the system runs on expediting, untracked inventory fills the aisles, and the cards sit unused in a drawer.
I have audited this failure pattern across automotive, aerospace, and electronics plants. The mechanics of Kanban are straightforward, but sustaining the discipline required to maintain signal integrity is where most organisations fail. The gap between the textbook pull system and the actual shop-floor execution is where all the waste hides.
Signal Integrity and the Mechanics of Pull
Kanban was developed at Toyota to make overproduction physically impossible. A downstream process removes a container of parts, which releases a signal—a physical card or electronic trigger—that travels upstream to authorise replacement production. Nothing gets built without an authorising signal. Inventory is capped by the number of cards in circulation.
The system depends entirely on signal fidelity. Physical cards get lost under machines, stuffed into operator pockets, or piled on desks. Electronic signals require scanning discipline that operators abandon under cycle-time pressure. Once signals go missing, upstream processes stop producing because they receive no authorisation, while downstream processes run dry and trigger emergency expediting.
Lost signals cascade quickly. At one automotive supplier, I tracked 340 missing Kanban cards in a single quarter from a system designed for 1,200 cards across a six-stage value stream. Losing nearly thirty percent of signalling capacity meant the pull logic could not function, yet nobody noticed the cumulative drift until customer shortages forced an audit.
By that point, the pull system had become a chaotic hybrid of guessed-at schedules and emergency production runs. The organisation was running a push system decorated with Kanban cards that no longer governed material flow.

How Exception Handling Inflates Inventory
Kanban systems limit inventory through a fixed number of containers. This works when demand is stable and supply is reliable. The moment either condition breaks—and in real manufacturing, both break constantly—organisations face a binary choice: hold firm and accept production stops, or add temporary inventory to bridge the gap.
Almost everyone chooses the bridge. Extra cards get printed. Safety stock gets quietly added without updating the baseline. A supplier goes down for a week, so procurement orders triple the normal quantity. Each individual exception carries legitimate urgency. Each seems reasonable in isolation.
But exceptions accumulate without a mechanism to retire temporary cards. I reviewed an electronics manufacturer that started with 800 Kanban cards and, three years later, had 2,100 in circulation. Demand had grown roughly twenty percent. The remaining increase—over 1,100 extra cards—was pure inventory inflation through unmanaged exceptions. Their warehouse, originally designed for lean storage, was overflowing.
The Kanban system existed on paper but functioned as a push system. The inventory cap had eroded permanently because nobody owned the authority—or the discipline—to remove exception cards once the disruption passed.
Recalculating Card Quantities for Current Demand
Kanban card quantities are snapshots. They reflect demand patterns, cycle times, supplier lead times, and container sizes at the moment of calculation. When any of these factors change—and they change constantly in dynamic manufacturing—the card count must be recalculated. This recalibration almost never happens.
The standard formula for card count is straightforward: Number of Kanban equals average daily demand multiplied by lead time multiplied by a safety factor, divided by container quantity. Each variable demands scrutiny. Average daily demand should be calculated from recent actuals, not annual forecasts divided by working days. Lead time must reflect real replenishment cycles, including variation.
The safety factor—often called the alpha factor—should be driven by data on demand variability and supply reliability, not by someone's comfort level. I have reviewed systems where demand shifted forty percent from baseline, yet card quantities remained untouched for three years. Cards representing obsolete demand patterns created systematic overproduction of some parts and chronic shortages of others.
Container quantity itself is a strategic decision. Large containers mean fewer cards and simpler management but coarser inventory control. Small containers provide precise pull signals but multiply administrative overhead. The right answer depends on part value, consumption rate, and physical handling constraints at the point of use.
| Formula Variable | What Teams Get Wrong | Consequence |
|---|---|---|
| Average Daily Demand | Using annual forecast divided by working days instead of recent actuals | Overproduction during demand declines |
| Lead Time | Using quoted lead time rather than measured replenishment cycle | Insufficient buffer, chronic stockouts |
| Safety Factor (Alpha) | Setting based on comfort rather than demand and supply variability data | Hidden inventory inflation |
| Container Quantity | Defaulting to supplier packaging instead of right-sizing for consumption | Coarse signals or excessive admin overhead |
Visual Management and Escalation Triggers
The purpose of Kanban is visual clarity: anyone walking through the area should immediately understand the production state. This requires more than cards in bins. Functional systems use colour-coded containers, marked floor locations, signal boards showing card status, and clearly displayed limits at each pull point.
A well-designed Kanban supermarket looks like organised transparency. You can see at a glance which parts are in stock, which are being consumed, and which have triggered replenishment. In the typical failed implementation, cards sit in unmarked bins scattered across shelves and nobody can answer how much WIP exists without a spreadsheet lookup.
Healthy Kanban systems also define what happens when normal flow breaks down. What should an operator do when the card rack is empty? When a bin stays in the supermarket past its aging limit? When a supplier signal goes unanswered for longer than the expected lead time? Without predefined escalation rules, abnormal conditions become invisible.
Inventory ages silently. Supplier delays go undetected until shortages hit production. Functional systems build in visual alerts: an empty card slot turns red, an aging bin gets flagged with a marker, an unanswered signal generates an automatic notification. The abnormal state must be as visible as the normal state, or the system degrades without anyone noticing.
Digital Kanban and the Scanning Discipline Problem
Electronic Kanban systems promise to solve the physical card problem by moving signals into software. RFID tags, barcode scanning, and automated ERP integration should eliminate lost cards, enable real-time visibility, and generate data for continuous improvement. In principle, this is the right direction.
In practice, digital systems introduce their own failure modes. Systems that require manual scanning still depend on operator discipline—a barcode scanner is just a card that beeps. If operators skip scans under time pressure, the electronic system generates the same garbage data as a manual one, but with false confidence in its accuracy because the software reports a number.
Over-automated systems that remove human judgment entirely create rigidity at critical moments. I audited one automotive plant where an e-Kanban system automatically triggered supplier orders based on consumption signals. When a quality issue required quarantining an entire batch, the system continued reordering replacement parts for the quarantined inventory. Nobody had designed an exception protocol.
The automation faithfully executed its logic straight into a warehouse full of parts nobody could use. The best digital implementations maintain human oversight at critical decision points—quality holds, supplier deviations, engineering changes—while automating routine signal flow. They track compliance metrics electronically: scanning rates, signal age, exception frequency.
Sustaining the System Through Audits and Ownership
Organisations that sustain Kanban effectively treat it as a living system requiring periodic maintenance. Monthly audits verify card counts match actual inventory, confirm scanning compliance, check for orphaned or duplicated cards, and assess whether demand patterns justify recalculation. These audits take a few hours per area and prevent the slow drift that kills most implementations.
The ones that break through to sustained performance share a common trait: they assign explicit ownership of Kanban system health as a defined performance objective.
Without that ownership, the system degrades because nobody has the authority—or the accountability—to enforce rules under production pressure. Supervisors look the other way when operators skip scanning. Engineers design workaround procedures that bypass the pull logic. Managers who never fully understood the system cannot recognise when it is being circumvented.
Most organisations cycle through drift, breakdown, and crisis repeatedly without ever reaching sustained performance. Kanban is not self-sustaining. Every long-term implementation I have observed includes dedicated resources for system maintenance, regular audits, and proactive recalibration. The cost is trivial compared to the inventory inflation that unchecked drift produces.
The Kanban Maturity and Decay Cycle
- 01LaunchCards printed, training delivered, initial compliance high. System functions as designed for 1 to 3 months.
- 02DriftExceptions accumulate, scanning discipline slips, temporary cards are not retired. Inventory begins to inflate.
- 03BreakdownSystem exists on paper but operates as push with decorative signals. Expediting replaces pull logic.
- 04RecognitionAudit or customer crisis reveals the gap between designed and actual state. Leadership is forced to act.
- 05RecoveryHonest recalculation, rule enforcement, and system recalibration over 2 to 6 months.
- 06SustainmentPeriodic audits, compliance metrics, ongoing recalibration. Requires assigned ownership to hold.
