You printed the cards, laminated them, trained the operators, and mounted the boards. For the first few months it worked. Material moved, signals triggered replenishment, and the board reflected reality. Then the system began to drift.
Cards disappeared. Someone started pre-staging material ahead of the signal because they did not trust the system. A supervisor added extra cards just in case. The supplier started shipping in batch quantities that ignored the card count entirely. The pull system became a push system with Kanban cards attached for cosmetic purposes.
This is the Kanban paradox. It is the simplest Lean tool to explain and the hardest to sustain. The mechanics are trivial, but Kanban places a discipline demand on the organisation that most manufacturing cultures cannot meet. It requires you to wait, to not build ahead, and to trust a signal instead of your instinct to stockpile. Every person in the value stream, from the supplier's shipping dock to the customer's receiving bay, must follow the same rules with the same discipline. Most organisations cannot do this, so they fake it.
What Kanban Actually Demands
The original Kanban system was developed at Toyota as part of the Toyota Production System. The concept is straightforward: instead of pushing material through the factory based on an MRP-driven forecast, you pull material based on actual consumption. When a downstream process consumes a container of parts, the empty container or the card attached to it travels back upstream as a signal to produce or replenish exactly that quantity.
The rules are brutally simple. Downstream pulls from upstream. Upstream never pushes to downstream. Nothing moves without a Kanban signal. Only standard containers are used, the quantity per container is fixed, and the number of cards in circulation is fixed. You cannot add cards to solve a problem. You remove cards to expose problems.
The genius of Kanban is not in the cards. It is in the constraint. By limiting the number of cards in circulation, you limit the amount of work-in-process inventory. By limiting WIP, you expose problems that excess inventory normally hides: equipment failures, quality defects, long changeovers, supplier unreliability, scheduling chaos. The inventory reduction is not the goal. The problem exposure is the goal. Inventory reduction is the side effect.
This distinction matters because most organisations invert it. They focus on reducing inventory, the measurable outcome, and ignore the problem exposure, the cultural mechanism. They pull cards out too fast, before the underlying problems are fixed, and the line starves. Or they add cards back to buffer against problems they never actually solve, and the inventory creeps back up. Both responses miss the point entirely.
The Six Structural Failures of Kanban
After decades of implementing, auditing, and rescuing Kanban systems across automotive and aerospace plants, I have identified six failure patterns that account for virtually every broken pull system I have ever encountered. They are not independent. They compound each other. Where you find one, the others are already taking root.
Failure one is card discipline collapse. Cards are lost, duplicated, modified, or ignored. Operators forget to pass them back. Supervisors borrow cards to authorise extra production. Cards get photocopied because someone decided the card count was too restrictive. The discipline of one card, one container, one signal erodes until the relationship is meaningless.
I once audited a plant where a product family had 340 active cards in circulation. The system had been designed for 85 cards. Over three years, operators and supervisors had added 255 cards to solve recurring stockouts caused by a 47-minute changeover time they had never reduced. Instead of fixing the changeover, they flooded the system with inventory. The Kanban board showed green, the warehouse was bursting, and customer lead times had increased because finished goods could not flow through the clogged WIP.
Kanban Card Count Diagnostic
The Emergency Override and Supplier Boundary
Failure two is the emergency override culture. In a healthy Kanban system, when a card signals replenishment, upstream produces. When there is no signal, upstream does not produce. In a broken system, the organisation develops a parallel authorisation structure: verbal overrides, emergency expediting, hot job flags, production meetings where someone decides to build ahead just in case.
The Kanban card becomes one of several authorisation signals, and it is the weakest one because it carries no urgency. The hot job flag always wins. Upstream processes simultaneously try to respond to Kanban signals and human overrides. Material produced on Kanban sits idle while material produced on override flows through. The override material creates excess inventory that clogs the line, which causes stockouts elsewhere, which triggers more overrides.
Failure three is the supplier boundary problem. Kanban works beautifully within a controlled environment where processes are physically adjacent. The moment the signal crosses an organisational boundary to a supplier, discipline breaks down. Suppliers cannot see your Kanban board. They receive purchase orders, forecast schedules, and electronic Kanban signals, but they also receive your MRP-generated forecast, which contradicts the Kanban signal, and your verbal expediting, which contradicts both.
The supplier rationally responds to the loudest signal, which is usually the one carrying the most threat. They build to forecast, ship in batch, and ignore the Kanban quantity. This is a system design failure, not the supplier's fault. You cannot impose single-card Kanban discipline on a supplier who serves fifteen customers, runs economic batch quantities, and has a four-hour changeover. The signal must be translated into a structured replenishment agreement both sides can live with.
The MRP Conflict and Visualisation Theatre
Failure four is the MRP conflict. Most manufacturing plants run Material Requirements Planning for scheduling and purchasing. MRP is, by definition, a push system. It calculates requirements based on forecast demand and pushes production orders and purchase requisitions into the system based on lead times and bill-of-material explosions. Kanban is philosophically opposed to this.
In theory, MRP handles boundary conditions and long-lead items while Kanban handles high-frequency internal flow. In practice, the MRP system generates production orders that conflict with Kanban signals, and Kanban generates material demand that MRP does not anticipate. Planners spend their time reconciling two systems that should have been one. MRP usually wins because it is wired to the purchasing system, the financial system, and inventory valuation. Kanban becomes a shop-floor novelty operating in the margins of the real system.
Failure five is visualisation theatre. A well-designed Kanban board shows entire production status at a glance. Anyone walking the floor can see what is being made, what is waiting, what is running short, and what is overproduced. In a broken system, the board becomes theatre. It is mounted on the wall, colour-coded, labelled, and completely disconnected from reality. Cards are in the wrong columns. The board has not been updated since the last shift change. Nobody trusts it, so nobody uses it, so nobody maintains it.
The Improvement Paralysis
Failure six is improvement paralysis, the most insidious failure pattern because the system appears to work. Material flows. Inventory is controlled. The board looks organised. But the continuous improvement promise has been silently abandoned.
The most important rule of Kanban, the one that separates it from a simple inventory management technique, is that the number of cards should decrease over time. Each reduction tightens the system, reduces WIP, and exposes the next layer of problems. Fix those problems, reduce again. This is how Kanban drives continuous improvement.
You cannot add cards to solve a problem. You remove cards to expose problems. The inventory reduction is the side effect.
In practice, the card count is set once, during the initial implementation, and never changed. The improvement loop is never closed. The problems that the original card count was designed to buffer against are never addressed, because addressing them requires cross-functional effort. Changeover reduction, equipment reliability improvement, supplier development, quality at the source. The organisation is not structured to execute that effort, so the system runs at its original card count indefinitely.
The organisation has settled for the inventory management benefit and discarded the cultural transformation benefit. It simply exists as a static system that was supposed to be a dynamic improvement engine. Ask the plant manager when the Kanban card count was last reviewed and adjusted. If the answer is during implementation or I do not know, the system has been running in neutral since launch.
Rebuilding the System from Current Reality
Rebuilding a failed Kanban system is not about retraining operators on card discipline. It is about fixing the systemic conditions that made the card discipline impossible to sustain. You must follow a specific sequence, and skipping steps will reproduce the same failure.
Step one is stabilising demand. Kanban requires relatively stable demand to function. If demand is highly volatile, with a coefficient of variation above 1.0, a pure Kanban system will either stock out or overstock. Smooth demand through heijunka production levelling, or segment products into runners for Kanban, repeaters for min/max, and strangers for make-to-order.
Step two is reducing changeover time. Every Kanban loop has an economic batch quantity determined by changeover cost. If changeovers take four hours, the batch size will be large, the containers will be large, and the system will behave like a push system with cards attached. Single-Minute Exchange of Die is a prerequisite, not an option.
Step three is establishing quality at the source. Kanban assumes that material moving through the system is conforming. If defect rates are significant, the card authorises production of material that will be scrapped or reworked, and downstream will signal for replenishment of material it never actually received. Jidoka and in-process quality must precede Kanban deployment.
Kanban System Rebuild Sequence
- 01Stabilise demandSmooth volatility through heijunka or segment into runners, repeaters, strangers.
- 02Reduce changeoversSMED is a prerequisite. Long changeovers force large batches and kill pull flow.
- 03Quality at sourceJidoka and in-process controls must ensure material is conforming before Kanban.
- 04Recalculate cardsUse current demand and defect rates, not original design parameters.
- 05Lock the systemFix the card count and remove override authority. Accept short-term stockouts.
- 06Begin improvementRemove one card, observe what breaks, fix it. Repeat indefinitely.
The Leadership Discipline Test
Step four is recalculating card counts from current reality. Do not use the original design parameters. Use current demand, current changeover times, current defect rates, and current supplier lead times. The new card count may be higher than the original. That is acceptable. You are recalibrating the system to the truth, not to the aspiration.
Step five is locking the system. Fix the card count. Remove the override authority. Make it physically impossible to produce without a card. This requires management commitment, because the first few weeks will be painful. Stockouts will occur in the short term as the system finds its equilibrium. Leadership must resist the pressure to add cards back.
Step six is beginning the improvement cycle. Once the system is stable, remove one card. Observe what breaks. Fix it. Remove another card. This is the Kanban improvement engine, and it only works if you have the discipline to fix problems instead of adding cards. The moment someone is allowed to override a card, add a card, or ignore a card without consequence, the system begins its descent into theatre.
Kanban is not a tool. It is a discipline system disguised as a tool. It works not because the cards are clever but because the organisational commitment to the rules is absolute. The question is not whether your Kanban system works. The question is whether your organisation has the cultural maturity to let it work. Kanban does not fail. Organisations fail Kanban.