A digital andon lets an operator call for help from the line with one tap, routes the call to the right responder instantly, timestamps every stage, and escalates automatically if nobody responds. Paper-era methods, log sheets, whiteboards, radios, and walking to find a supervisor, deliver help slower and leave no record you can improve from. The signal is the same idea either way. What changes is the speed of help and the existence of data.
Our andon system guide covers what andon means, where the cord came from, and how escalation should be designed. This post takes the narrower question plants actually face: you already have some way of flagging problems, so what specifically do you gain by making it digital? It is part of our paperwork digitization series, alongside digital production reporting and the paperless manufacturing guide.
What counts as a paper andon?
A paper andon is any manual method for flagging line problems and summoning help: a log sheet where operators note issues for the supervisor's next pass, a whiteboard column for problems, a radio call to whoever answers, or the oldest method of all, leaving your station to go find someone. Stack lights without any recording layer belong in this family too: the light is visible, but once the problem is resolved, no trace remains of when it turned on, who responded, or how long it burned.
These methods share two structural weaknesses. First, they depend on someone noticing: the supervisor has to walk past the board, hear the radio, see the light. Help latency is a function of foot traffic. Second, they leave no usable record. The issue was real, help eventually came, and afterward the plant knows nothing it did not know before. The same problem on the same machine can recur weekly for a year and never become a pattern anyone can see, which is exactly the trap described in machine downtime: the stops that hurt most are the frequent short ones nobody writes down.
What does a digital andon do differently?
A digital andon changes three mechanical things: the call goes to a person instead of into the air, escalation is automatic instead of dependent on someone noticing, and every stage is timestamped. The operator taps a reason on a line-side screen or presses a button. The system notifies the assigned responder directly, on whatever device they carry. If the call is not acknowledged within a set time, it escalates to the next tier on its own. When the issue is resolved, the record already exists: what was called, when, who came, how long each stage took.
None of this requires new machines. The andon layer sits beside whatever equipment already runs, which is the general pattern for connecting a plant without a rip-and-replace project; the Harmony AI platform overview shows where that layer fits.
Where does the time go between problem and help?
Most of the latency in a manual system is invisible, because it is made of small human steps nobody counts. The operator notices the problem, keeps running for a bit hoping it clears, then leaves the station, walks to wherever the supervisor might be, explains the issue, and waits while the supervisor finds the mechanic and explains it again, secondhand. Each step is short. The sum is routinely fifteen or twenty minutes before qualified help stands at the machine, and because none of it is recorded, the plant experiences the delay without ever seeing it.
The other cost of the walking method is that the operator, the one person watching the process, leaves it to go be a messenger. A one-tap call keeps eyes on the line during exactly the minutes something is going wrong, which matters as much as the response clock in quality-sensitive processes.
How do paper and digital andon actually compare?
Dimension by dimension, the comparison looks like this:
| Dimension | Paper andon (sheet, board, radio, walking) | Digital andon |
|---|---|---|
| Help latency | Depends on someone noticing; minutes to hours | Notification in seconds, direct to the responder |
| Escalation | Manual, memory-dependent, often skipped | Automatic, on a timer, every time |
| Record of the call | Usually none; a note if someone bothers | Timestamped automatically at every stage |
| Response accountability | Untrackable | Who acknowledged, who arrived, how fast |
| Pattern visibility | Tribal memory only | Pareto by station, reason, shift, time of day |
| Operator cost to use | Leave station, find someone, explain | One tap, stay at station |
| Failure mode | Call unseen, problem normalized | Alert fatigue if reasons are too broad |
The last row deserves honesty. Digital andon has its own failure mode: if every minor annoyance triggers a call, responders drown and start ignoring alerts, which recreates the paper problem with extra steps. The fix is the same discipline paper never enforced: a short reason list, clear response tiers, and periodic review of which calls deserved to exist. Our andon metrics guide covers what to measure to keep the system honest.
What does the andon record unlock over time?
The record is where the compounding value lives, because response is a cost and prevention is the payoff. A month of andon events answers questions no paper method can touch: which station calls most, which reason dominates, which shift waits longest for help, whether Tier 1 response times are drifting. That is the raw material for fixing causes rather than perfecting responses, and it connects directly to the escalation thinking in jidoka: stop, respond, then improve so the stop stops recurring.
Andon events are also downtime records wearing a different hat. Coded calls with start and end times feed the same analysis as a downtime tracking template, but captured as a side effect of asking for help instead of as a separate logging chore. Plants that struggle to get operators to log downtime often find andon adoption easier, because the operator gets something immediate in return: help arrives faster. To put a rough number on what faster response is worth, our calculators and tools include a downtime cost calculator.
How do you move from paper to digital andon?
The migration is small compared to most plant software projects, but order still matters:
- Define the escalation path on paper first. Who responds to each call type, how fast, and who is next if they do not. If this is undefined, digitizing it just automates confusion.
- Pick a short reason list. Five to eight call types per area: mechanical, quality, materials, safety, help. Broad enough to cover reality, short enough that choosing takes two seconds.
- Pilot one line with real response tiers. Put the trigger at the station, the notifications on the responders' devices, and the timers live. Resist the urge to start plant-wide; one line surfaces the routing mistakes cheaply.
- Review the first month of records with the team. Look at call volume, response times, and escalation frequency. Kill reason codes nobody uses, fix tiers that always escalate, and celebrate the patterns that got fixed.
- Expand and connect. Roll to the next lines, then let the andon record feed the daily report and downtime analysis so the same event never gets logged twice.
Where does AI fit in an andon system?
Once andon calls are events in a system, an AI-native MES can do more than route them. Harmony AI connects machines, software, and the paperwork layer, so its AI agents can spot that station 4 has jammed every Tuesday after the material change, surface repeat offenders before anyone runs a Pareto, and fold the night's calls into a morning report that writes itself from actual events. That loop, floor event to finished narrative with no typing in between, is the one documented in the CLS case study, and andon events slot into it the same way downtime and production counts do.
For the historical grounding and the standards context, the primary sources are worth a look: Toyota's own materials on the Toyota Production System describe andon as part of jidoka, the principle of stopping at abnormality, and ISO 22400 defines standard KPIs for manufacturing operations management, the family of measures a good andon record feeds. Neither requires software, but both assume the events get recorded somehow, and paper has had a century to prove it will not do the recording on its own.
Which should you choose?
If your plant is small enough that the supervisor can see every station and problems genuinely get help in minutes, a disciplined manual andon with a visible board can work; visual management is not obsolete. The case for digital is strongest when any of three things is true: responders are not within sight of the line, the same problems keep recurring without a record, or you are already digitizing reporting and want stops captured once instead of twice. Most plants past a single line hit all three. The honest summary: paper can signal, but it cannot remember, and the memory is where the improvement lives.