Andon System in Manufacturing: How It Works, Examples & KPIs

Andon in 30 seconds

An Andon call follows the same path every time: something departs from the standard, a signal makes it visible, someone acknowledges it, a responder arrives and contains the problem, the process is restored, and recurring calls feed learning.

An Andon management system is this whole chain, not only the light: call capture, routing, acknowledgement, response tracking and the record that supports later analysis.

1. Abnormality

   A condition departs from the known standard at the point of work.

2. Signal

   Expose the abnormal condition immediately.

3. Acknowledge

   Make ownership visible to the caller and team.

4. Respond

   The responder arrives and assesses the condition.

5. Contain

   Protect people, quality, equipment, and flow.

6. Resolve

   Return safely to a known standard.

7. Learn

   Investigate recurring high-impact patterns and verify action.

Define the abnormality and expected response

Lean Enterprise Institute defines Andon as visual management that shows operating status and signals abnormalities such as machine downtime, quality problems, tooling faults, delays, or material shortages. Translate that principle into specific conditions for each process.

For every signal, define who owns the first response, the expected arrival time, what can be contained at the station, when the line should stop, and how escalation works. A color without a response standard is decoration.

There is no single universal Andon color standard. Green, yellow and red are common, but the meaning of each must be defined explicitly by the plant and taught to everyone who sees it.

• Trigger that operators and sensors interpret consistently
• Location, asset, order, product, and time
• First responder and escalation path
• Safe containment and stop authority
• Closure evidence and follow-up owner

Design for psychological and operational safety

People must be able to call for help without being blamed for interrupting production. Leaders should treat a call as protection of the standard, not failure by the caller. If response is slow or punitive, teams learn to work around abnormalities.

Make the interface reachable, legible, keyboard- or glove-compatible where needed, and unambiguous. Avoid dozens of codes during the event. Capture the condition and summon help first; classify and investigate with evidence afterward.

Prevent alarm noise and abandoned calls

Use separate severities for awareness, assistance, and stop conditions. Deduplicate repeated machine events, expire stale signals, and route only to people who can act. Show whether a call is acknowledged, who owns it, and how long it has been open.

Measure response time, containment time, recurrence, unknown reasons, and calls that received no action. A high number of alerts is not proof of control; it may show poor thresholds or an unstable process.

Connect Andon data to downtime and root-cause learning

Preserve the trigger, acknowledgement, arrival, containment, restart, and confirmed-cause timestamps. Link the call to machine states, alarms, order, product, material, and quality evidence. This creates a useful timeline without asking the operator to diagnose under pressure.

Review recurring calls by impact and constraint context. Select patterns for structured root-cause analysis, verify countermeasures, and watch recurrence. Keep the Andon reason and confirmed cause separate.

Pilot where response can actually be supported

Choose one area with clear standards, available team-leader or support coverage, and recurring abnormalities. Observe the current help process before adding technology. A digital Andon cannot compensate for missing response roles or unclear stop authority.

Run the pilot across all relevant shifts. Adjust triggers and staffing from observed response, then connect selected signals to production analytics. The goal is faster recovery and fewer repeats, not more screens.