Andon System Design: How to Build One That Operators Actually Use

Key takeaways

• Andon system = the visual + escalation framework operators use to signal abnormalities.
• Good andon design ensures: easy to trigger, fast escalation, never punishing, audit-friendly.
• Most andon systems decay because operators stop signaling, usually because of punishment, slow response, or no follow-up.
• The right metric for andon health is response time, not signal frequency.
• Andon connects to OEE through reason-coded downtime: every red event is an Availability loss with cause.

Short answer: An andon system is the operator-driven signaling framework that surfaces abnormalities. Effective andon design makes signaling easy, escalates quickly, never punishes the signaler, and tracks response time as the health metric. Most andon systems decay because operators stop signaling, usually because of slow response, perceived punishment, or no follow-up. Designing against those three failure modes is the work. See also Andon Cord vs Andon Light.

What an andon system has to do

• Let operators signal abnormality in seconds.
• Escalate the signal to the right person fast.
• Capture the cause for analysis.
• Drive a response that resolves the issue.
• Feed the loss back into operations data (OEE, CMMS).

All five are necessary. Missing any one breaks the system.

Signal design

Two states minimum, often three:

• Yellow (or amber): need help, line still running.
• Red: line stopped, need urgent response.
• Green: normal operation (default).

Some plants add additional codes (blue for material, white for maintenance). Each additional code dilutes attention; resist proliferation.

Trigger design

Two principles:

• Easy to trigger. Button at hand reach, ideally with status visible from across the floor.
• Hard to miss accidentally. A button you brush against accidentally is bad design.

Digital triggers in OEE platforms work, but they should not require login or navigation. One tap.

Escalation design

What happens when yellow goes on:

1. Local supervisor notified within 30 seconds.
2. If unresolved within 5 minutes, escalate to area manager.
3. If unresolved within 15 minutes, escalate to plant manager.

Numbers vary by plant. The principle: escalation is automatic, not dependent on operator follow-up.

Response design

Response means going to the line, observing, helping. Not opening a meeting room. The response is at the workstation, with the operator.

Response time is the health metric. Track it. Display it. Make it visible.

No-punishment principle

The single most important andon design rule: never punish operators for signaling. The moment they perceive punishment for raising yellow or red, signaling drops to zero and the system dies.

This is hard culturally. Production pressure naturally creates frustration with stops. Leadership must protect the signal explicitly.

Common failure modes

1. Slow response. Yellow signals are ignored or take 10 minutes to respond. Operators stop signaling.

2. Punishment. Operators who trigger red get questioned aggressively. Future signals avoided.

3. No follow-up. Resolved at the moment but root cause never addressed. Same issue recurs.

4. Cluttered triggers. Too many color codes operators have to choose between. Defaults to "yellow" or "other."

5. No metric on response time. Health invisible until adoption collapses.

How to keep the system alive

1. Track response time visibly. Daily review.
2. Track signal frequency by cause. Pareto of why operators signaled.
3. Address recurring causes. If the same yellow appears five times this week, root cause it.
4. Protect the signal. Leadership makes clear that signaling is welcomed.
5. Celebrate good signals. Operator who flagged a safety issue gets thanks, not interrogation.

How andon connects to OEE

Every red signal is an Availability loss with a captured reason code. Every yellow is a Performance loss (line slowed during help). The data flows into the OEE Pareto.

Plants integrating andon with OEE see cleaner downtime reason-code data than plants that try to capture reasons after the fact.

Common mistakes

1. Andon without escalation. Signal exists; nobody responds.

2. Andon punished implicitly. "Why did you stop the line?" said the wrong way kills future signals.

3. Color proliferation. 8 colors with different meanings. Nobody remembers them.

4. No data trail. Signals happen; no record. Cannot improve.

How a modern OEE platform supports andon

A modern OEE platform supports digital andon triggers, automated escalation routing, response-time capture, and integration with reason-coded downtime in OEE Pareto.

In Fabrico, alerts reach the right technician by stop reason, and the reason codes feed the downtime Pareto. There is no automatic escalation or acknowledge step, so keep the escalation rule in your shift routine.

See how Fabrico captures this automatically, read our OEE guide or book a demo.

Related reading

• Andon Cord vs Andon Light
• Run Rate vs Design Rate
• Downtime Reason Code Design
• Line Design vs Line Balancing

Frequently asked questions

What is a good response time?

Yellow: under 60 seconds. Red: under 30 seconds.

How many color codes should I have?

Three (green, yellow, red) is the standard. Adding more dilutes.

Should every workstation have andon?

In high-mix or high-quality-risk operations, yes. In simple operations, line-level may be enough.

Can software replace physical andon lights?

Partly. Physical lights work without power or screens. Software complements with data capture.

What is the worst andon design mistake?

Punishing the signal. Once operators feel punished, they stop signaling and the system dies.