What andon is — and the ladder of ways to build it
Andon (行灯 — the lantern) is the lean principle that problems must announce themselves immediately and visibly, so help arrives while the problem is small. In hardware terms, South African plants meet it at four rungs:
| Rung | What it is | Honest assessment |
|---|---|---|
| Stack lights | Red/amber/green towers per machine, wired to machine state or a switch | Cheap and instantly understood — but only as good as the line of sight and the response culture |
| Wireless andon / call buttons | Operators press for maintenance, materials, quality; receivers buzz or display | Good for help-calls people must initiate; adds radio reach; still manual, still unlogged in basic kits |
| Digital andon boards | Screens showing line status, calls and counts, fed manually or from machines | Powerful when machine-fed; when manually fed, they inherit every problem of manual dashboards — and die the same death |
| Data-driven andon | Machine signals trigger status automatically; escalation goes to phones with timers; every event logged | The version that survives — because the light, the alert and the downtime record are the same event |
Why andon projects decay — three predictable failures
- The unanswered light. A red lamp with no escalation path is a decoration. Within weeks the floor learns that red doesn't summon anyone, and the system is dead — still lit, but dead. Working andon has timers: unacknowledged calls escalate — station → supervisor's phone → maintenance manager — automatically.
- Manual triggering under pressure. When operators must stop to press the button, the busiest (worst) moments go unrecorded — precisely the moments andon exists for. Machine-triggered status (from counters, current, run signals — the same retrofit sensing that feeds OEE) fires whether or not anyone has a free hand. Buttons stay for what machines can't know: materials, quality, "come look at this".
- No memory. A light that turns green leaves no record — so andon events never become Pareto charts, and the same station calls for help every Tuesday forever. Logged events with response times turn the andon system into the front end of downtime analysis: the call is the reason code.
Andon in the South African context
Two local specifics change the design. Load shedding: an andon system that dies with the power tells you nothing during exactly the chaos of restart — edge-buffered, UPS-backed andon (like any monitoring surviving load shedding) keeps the record through the event. Distributed supervision: with lean staffing across big floors, ceiling lights alone assume someone is looking; escalation to WhatsApp/SMS reaches the supervisor wherever they are — which in practice is what converts response times from "when noticed" to minutes.
A sensible buying path
- Have nothing? Stack lights on the bottleneck line plus a written response rule. Cheapest possible start; teaches the culture.
- Lights ignored? Don't buy more lights — add escalation and logging. That's a monitoring-layer problem, not a lamp problem.
- Scaling up? Machine-triggered status with operator reason-tagging, digital boards fed from the same data, phones in the escalation chain. At this rung andon, downtime tracking and OEE are one system with three faces — which is exactly how we build it on addaNet.