Kanban is one of those Lean concepts that appears deceptively simple.
Create a signal.
Define a container quantity.
Establish a supermarket.
Trigger replenishment when downstream consumption occurs.
The system becomes visual. The shopfloor appears organised. Cards move. Containers circulate. Boards display status.
And yet inventory continues to increase.
Shortages still occur.
Operators request material just in case.
Supervisors override replenishment priorities when production pressure rises.
Emergency deliveries become routine.
Additional containers appear.
Unofficial buffers develop beside the formal supermarket.
Eventually, the organisation has not created effective pull.
It has created inventory with Kanban signals attached to it.
The distinction matters because Kanban is not primarily a visual-management technique.
Kanban is a control mechanism that authorises replenishment and limits the amount of work or material permitted within a defined pull loop.
When those limits and authorisation rules stop governing behaviour, the cards become little more than visual administration.
Installing Kanban does not create pull
A pull system is based on a demanding operational principle:
upstream activity should respond to downstream consumption rather than produce simply because equipment capacity is available, a local schedule encourages it, or somebody wants additional protection against uncertainty.
The principle is simple.
The behaviour required to sustain it is not.
Many production systems contain incentives that work in the opposite direction.
Machines are kept running because stopping them appears inefficient.
Supervisors create buffers because material shortages threaten output.
Planning releases additional work because future demand is uncertain.
Logistics delivers early because internal transport is unreliable.
Production builds ahead because equipment availability cannot be trusted.
Quality problems encourage extra stock because first-pass yield is unstable.
Then Kanban is introduced on top of these conditions.
The signals change.
The underlying operating behaviour does not.
The result should not be surprising.
A pull mechanism cannot indefinitely compensate for an unstable operating system.
Kanban may expose instability.
It cannot solve instability merely by existing.
The signal is not the system
A card, empty container, electronic message, barcode event, or empty supermarket location is only a signal.
Its function is to communicate an authorised replenishment requirement.
For that signal to control flow, the organisation must understand:
- what quantity each signal represents;
- what event authorises replenishment;
- where material belongs;
- who is responsible for replenishment;
- what replenishment time is expected;
- how many signals are authorised in the loop;
- which assumptions determined that quantity;
- what constitutes an abnormal condition;
- who may change the loop;
- what happens when the normal rule cannot be followed.
Without these rules, the physical Kanban artefact may remain while the control mechanism disappears.
If signals are added whenever the system becomes uncomfortable, replenishment is accelerated for whoever escalates most strongly, and production continues without downstream authorisation, the pull system is no longer governing flow.
Daily pressure is governing the pull system.
That is how a Lean mechanism becomes theatre.
Inventory is protection against uncertainty
One of the most useful lessons from pull systems is that inventory is not merely material waiting between processes.
It is also protection against uncertainty.
Factories hold inventory because something else cannot be trusted completely.
Equipment availability.
Cycle-time stability.
Changeover duration.
Supplier performance.
Internal logistics.
First-pass yield.
Schedule adherence.
Process capability.
Recovery time.
Demand behaviour.
Inventory can therefore be economically and operationally justified.
The Lean question is not whether all inventory is bad.
The more useful question is:
What uncertainty is this inventory protecting us from, and is that protection still justified?
Kanban makes that protection explicit by limiting how much material should exist in the loop and linking replenishment to consumption.
That is precisely why problems become visible.
If a supermarket repeatedly empties sooner than expected, something deserves investigation.
Perhaps consumption has changed.
Perhaps replenishment is slower than the design assumption.
Perhaps upstream availability has deteriorated.
Perhaps scrap has increased.
Perhaps a changeover now requires more time.
Perhaps internal logistics is missing its defined frequency.
Perhaps the original Kanban calculation no longer represents the current product mix.
The shortage is not automatically proof that Kanban has failed.
It is evidence that actual operating conditions and design assumptions may no longer agree.
The management response determines whether the pull system learns or merely accumulates protection.
Adding Kanban may be correct — but it should never be automatic
When a shortage occurs, the easiest response is understandable:
increase the number of containers or signals.
The immediate probability of another shortage decreases.
Inventory increases.
That response is not necessarily wrong.
Demand may genuinely have increased.
Replenishment time may have changed permanently.
Product mix may have become more variable.
Supplier or transport conditions may require a different level of protection.
A Kanban loop should be resized when its operating assumptions materially change.
The problem begins when additional signals are repeatedly introduced as compensation for unresolved abnormalities.
Another container protects against equipment instability.
Another protects against poor changeover performance.
Another protects against variable quality.
Another protects against unreliable logistics.
Eventually, each additional Kanban becomes a small insurance policy against a problem the organisation has decided to tolerate.
The supermarket expands.
FIFO lanes overflow.
Temporary locations become permanent.
Material appears outside the designed system.
And nobody can explain why the current number of signals exists.
That is a critical governance test:
Can the organisation explain the operational assumptions behind the current Kanban quantity?
If not, the number of cards may no longer represent deliberate pull-system design.
It may simply represent accumulated organisational anxiety.
Unofficial inventory creates an unmanaged second system
Formal Kanban quantities are only meaningful if material outside the loop is controlled.
Suppose the authorised supermarket contains six containers.
Production then creates two additional emergency containers.
Logistics stores another two nearby as protection.
Operators hide one more container at the line because previous shortages stopped production.
The official system still contains six Kanban.
The physical system contains eleven containers.
At that point, the WIP limit exists only administratively.
The factory has created two systems:
the formal pull system;
and an informal protection system.
The second system is usually less visible, less governed, and more difficult to improve.
This is why audits that simply count Kanban cards can be misleading.
The more useful Gemba question is:
How much material actually exists in the loop, and what authorises each unit of that inventory to be there?
A practical factory example
Consider an assembly line supplied by an internal machining operation.
The Kanban design authorises six containers between the two processes.
Each container holds a fixed quantity.
Under expected conditions, assembly consumption creates the replenishment signal and machining replaces what has been withdrawn.
Initially, the system performs reasonably well.
Then machining develops intermittent equipment problems.
Nothing catastrophic occurs.
A sensor fault.
A tooling problem.
Several short maintenance interventions.
Daily production is usually recovered, but replenishment time becomes less predictable.
Assembly experiences two shortages.
Management responds by adding two containers.
The shortages disappear.
Several months later, machining changeovers become less stable as product mix grows more complex.
Another shortage occurs.
Two further containers are introduced.
At the same time, a quality issue creates occasional sorting activity.
Logistics responds by holding unofficial safety stock outside the supermarket.
The nominal system now contains ten Kanban containers plus an informal buffer.
Management can still see cards moving and may therefore conclude that the Kanban loop is functioning.
Operationally, the organisation has used inventory to absorb:
- equipment instability;
- changeover losses;
- quality variation;
- replenishment uncertainty.
The Kanban did not solve those problems.
It made them easier to tolerate.
That difference matters.
A healthy pull system creates management tension
Kanban should create a certain amount of constructive operational tension.
Not chaos.
Not permanent material shortages.
But sufficient sensitivity to expose when actual conditions depart from the assumptions under which the loop was designed.
If expected replenishment requires four hours and repeatedly takes seven, somebody should investigate.
If FIFO is routinely bypassed, the reason should be understood.
If emergency material deliveries become frequent, the pattern should trigger problem-solving.
If the supermarket remains permanently full, upstream production may be operating without genuine consumption.
If it is frequently empty, replenishment capability, variability, or sizing assumptions may be inadequate.
If operators maintain unofficial buffers, the organisation should ask why they no longer trust the designed system.
Kanban can therefore become more than a material-control mechanism.
It can function as a diagnostic mechanism for flow stability.
But only if abnormalities retain their authority.
When every exception is normalised, the system stops teaching the organisation anything.
Production discipline matters because overproduction breaks pull
One of the most difficult behaviours to change is overproduction.
A machine completes the authorised requirement.
Capacity remains available before the end of the shift.
The instinct is familiar:
Keep running. We may need the parts later.
From the perspective of local utilisation, that can appear sensible.
From the perspective of value-stream flow, it may be exactly the wrong decision.
Producing without downstream authorisation creates inventory that the pull system did not request.
That inventory consumes:
space;
material;
handling;
containers;
working capital;
inspection effort;
and management attention.
It may also protect the process from abnormalities that should remain visible.
This is why pull requires leadership discipline.
When no authorised downstream requirement exists, stopping production can be the correct operational decision.
That can be difficult in organisations where equipment utilisation is treated as an unquestioned objective.
The problem is not utilisation itself.
The problem is local optimisation overriding the control logic of the value stream.
Logistics discipline is part of pull
Kanban also deteriorates when internal logistics cannot execute reliably.
If routes, frequencies, and replenishment sequences are not dependable, people begin to protect themselves.
Material is delivered early.
Extra containers are placed near the line.
Routes are changed for whichever problem escalates most loudly.
Supervisors bypass standard logistics and make direct requests.
The formal pull loop gradually becomes an informal expediting system.
The loudest shortage receives attention first.
That is not pull.
It is reactive prioritisation.
A robust Kanban system therefore requires disciplined logistics execution:
defined routes;
defined frequencies;
standard handling quantities;
clear abnormalities;
stable replenishment responsibilities;
and escalation when standard execution cannot be maintained.
Pull is not a card between two processes.
It is an end-to-end operating behaviour.
Maintenance affects the inventory required for flow
Kanban is often treated as a production-and-logistics topic.
That is incomplete.
Equipment reliability directly affects replenishment capability.
If an upstream asset is unstable, the pull loop has only a limited number of possible responses.
The organisation can improve reliability.
It can increase protection.
It can accept greater shortage risk.
Or it can redesign the flow.
What should not happen is for the consequence to remain invisible.
Additional Kanban inventory often represents the physical cost of reliability problems elsewhere in the value stream.
That creates a useful management question.
Instead of asking only:
How much inventory do we need?
ask:
Which reliability losses are forcing us to carry this inventory?
The same principle applies to changeovers.
Poor or highly variable changeover performance does more than reduce equipment availability.
It may also increase the inventory required to maintain downstream continuity.
This creates a direct connection between Kanban, TPM, maintenance strategy, SMED, and flow.
Operational instability has an inventory consequence.
The supermarket often reveals it.
Quality instability also becomes inventory
A pull system based on expected yield will behave poorly when actual first-pass yield is materially different.
If production regularly requires sorting, rework, or additional replacement units, the physical replenishment requirement no longer matches the nominal model.
The usual defensive response is more material.
Inventory again absorbs process instability.
A mature pull system therefore needs to understand actual operating performance:
actual first-pass yield;
actual replenishment time;
actual changeover behaviour;
actual logistics performance;
and actual demand characteristics.
Not merely optimistic standards.
The objective is not to abandon standards.
It is to use standards as explicit assumptions that can be challenged when reality repeatedly differs.
Kanban mathematics requires honest assumptions
Kanban sizing typically depends on variables such as demand, replenishment time, container quantity, and some form of protection against variability.
The calculation is useful.
It is not self-validating.
A mathematically correct result based on unrealistic inputs remains operationally weak.
If replenishment is modelled as two hours but routinely varies far beyond that assumption, the issue is not primarily the formula.
The issue is the input.
If average demand hides significant mix-dependent behaviour, the supermarket may not perform as expected.
If quality loss is ignored while actual first-pass yield is unstable, replenishment may repeatedly fall short.
If transport frequency is assumed but rarely achieved, nominal lead time has little operational meaning.
A good Kanban calculation should therefore make the assumptions visible.
What demand pattern was assumed?
What replenishment time?
What variability?
What yield?
What container quantity?
What protection?
What service or shortage risk is being accepted?
When should those assumptions be reviewed?
The objective is not mathematical elegance.
It is a transparent relationship between actual consumption, replenishment capability, deliberate protection, and improvement priorities.
The spreadsheet calculates the loop.
The Gemba validates whether the loop describes reality.
Electronic Kanban can automate weak pull logic
Digital Kanban can provide significant advantages.
Signals can move faster.
Lost cards can be reduced.
Replenishment status can become traceable.
Integration with MES/MOM, WMS, and ERP can improve coordination.
Exceptions can become visible in near real time.
But digitalisation does not repair flawed operating logic.
If replenishment rules are poorly designed, electronic Kanban executes those rules more efficiently.
If quantities are inappropriate, the system digitises the wrong quantities.
If exceptions are routinely tolerated, dashboards visualise the same instability more elegantly.
If production is permitted to replenish without genuine consumption, integration can automate overproduction.
Digital Lean still requires Lean discipline.
Technology should reinforce the operating principle.
It cannot substitute for it.
Visual management must preserve the meaning of abnormality
A good Kanban system should make abnormal conditions difficult to ignore.
Missing signal.
Late replenishment.
Overfilled supermarket.
FIFO violation.
Emergency delivery.
Unauthorised production.
Repeated shortage.
Unofficial inventory.
These conditions should be visible.
More importantly, they should trigger a defined response.
That is the difference between visual management and visual decoration.
When the same red condition remains visible every day without action, the signal gradually loses authority.
People learn that red is normal.
The same thing happens with Kanban.
A visual signal governs behaviour only when the organisation respects what that signal means.
Do not blame operators before examining the system
When pull systems deteriorate, operators are often blamed.
They keep extra stock.
They do not return the cards.
They call logistics directly.
They ignore FIFO.
Sometimes behavioural discipline genuinely needs correction.
But mature Lean leadership also asks why rational people concluded that violating the formal system was safer than following it.
Perhaps previous shortages stopped the line and the causes were never resolved.
Perhaps replenishment routes are unreliable.
Perhaps supervisors reward hidden buffers because they protect output.
Perhaps the authorised quantity no longer reflects actual conditions.
Perhaps escalation produces no meaningful response.
People adapt to the operating system around them.
If shortages are punished but excess inventory is tolerated, the organisation will create inventory.
If local utilisation is rewarded while pull is discussed rhetorically, equipment will overproduce.
If management ignores recurring abnormalities, workarounds become standard practice.
Respect for people includes creating an operating system in which following the standard is rational.
Kanban requires governance
A mature pull system needs explicit governance.
Someone should know:
- who owns each Kanban loop;
- who may change the authorised quantity;
- which assumptions define the current sizing;
- what triggers recalculation;
- how shortages and excess inventory are investigated;
- how temporary protection is approved;
- when temporary protection must be reviewed;
- how obsolete physical or electronic signals are removed;
- how actual inventory is audited against the authorised limit.
This is particularly important because temporary countermeasures have a habit of becoming permanent design.
Additional inventory is introduced during a product launch.
The launch stabilises.
The inventory remains.
A supplier problem requires temporary protection.
The supplier recovers.
The protection remains.
Extra containers compensate for unreliable equipment.
Reliability improves.
The containers remain.
The factory solves yesterday’s problem but continues paying for yesterday’s uncertainty.
A disciplined Kanban governance process should prevent this accumulation.
Every temporary buffer should have an owner, a reason, and an exit condition.
Pull is a management system, not a material-handling technique
A mature Kanban system connects multiple operational disciplines:
production stability;
standard work;
takt and flow;
equipment reliability;
SMED;
quality performance;
internal logistics;
visual management;
problem-solving;
and leadership behaviour.
This is why Kanban is more demanding than its visible mechanics suggest.
Creating the card is easy.
Maintaining the conditions under which the card has meaning is difficult.
A functioning pull system continuously requires the organisation to:
respect actual consumption;
limit authorised WIP;
expose abnormalities;
make protection explicit;
and reduce the instability that makes additional inventory attractive.
When that discipline disappears, the cards can remain in circulation for years.
People still move them.
Boards still display them.
Auditors still see them.
Lean assessments may still record their existence.
But the signals no longer govern the flow.
They merely document a push system more neatly.
That is one of the most dangerous forms of Lean deterioration:
the visible tool survives after the operating principle has disappeared.
The strongest test of Kanban maturity is therefore not whether cards, bins, or electronic signals exist.
It is whether the organisation can explain:
what each signal authorises;
what inventory it limits;
which assumptions justify that limit;
and what management action occurs when reality no longer matches those assumptions.
Three questions are worth asking:
If your Kanban signals disappeared tomorrow, would upstream production behaviour materially change—or are the signals simply documenting inventory that already exists?
When shortages recur, does the organisation distinguish between a genuinely incorrect Kanban design and instability that additional inventory is merely hiding?
Who has authority to increase protection in the pull system—and who is accountable for removing it when the reason for that protection disappears?
#LeanManufacturing #Kanban #OperationalExcellence #ContinuousImprovement #ManufacturingExcellence #TPM #IndustrialMaintenance #SmartFactory #MES #SupplyChain