The Real Cost Isn't the Stop. It's the Time Until Someone Knows
When a line goes down, most plants start by measuring repair time. But when you break a single stoppage into its parts, more time is often lost before the repair even starts. Response time has four segments:
Take a line producing 120 units per hour. If the supervisor learns of a stop 10 minutes late, 20 units of output are gone before anyone picks up a tool.
Plants that rely on stack lights and radios run into one structural limit: nothing gets recorded. There's no way to reconstruct who called, when, how long it took someone to show up, or how often the same issue came back this month. The stoppage survives only as a vague memory that the line "stopped a lot today."
Designing Andon Call Types: Who Gets Called?
If one button calls everyone, nobody comes. Each call reason needs a clear owner.
Keep the reason codes to a number an operator can choose from in three seconds. Go beyond four to six top-level categories and operators start hitting "Other," and the data stops being useful. A more practical split is to have the responder enter the detailed cause after the fix, not the operator at the moment of the call.
Time-Based Escalation Rules
Escalation should run on time rules, not on someone deciding to escalate. A sample set of thresholds:
Define "response" as confirmed arrival at the line (badge tap or terminal check-in), not just acknowledging the alert. That's the only way to measure detection time and travel time separately.
Automatic substitution for shift changes and days off is essential. Without a link to shift and attendance data, you end up with a night-shift call ringing the phone of someone who went home hours ago. Pick the alert channel to fit the role: andon boards for information the whole line needs to see, smartwatches for maintenance staff on the move, and mobile push for managers.
It Only Becomes Data When It's Connected to MES
If andon calls live in a standalone system, you won't get much beyond a call count. To analyze causes, the call history has to be tied to MES data:
With those links in place, you can look at detection, travel, and fix time separately for each reason. If a reason has short fix times but long travel times, the problem is how maintenance staff are deployed. If quality calls pile up on one part number, look at the process conditions. Rank issues by frequency × average downtime, and your improvement priorities become clear.
Where the Shop Floor Pushes Back, and How to Respond
The biggest resistance comes from the belief that "if I pull the cord, I'll get blamed." Once andon data starts showing up in performance reviews, operators stop calling and quietly fix things themselves. Make these principles official:
The right input device depends on the work environment. Physical buttons suit processes where operators wear gloves or have dirty hands. Tablet UIs work better in assembly and inspection, where operators need to select a reason or attach a photo. The safest rollout starts with one line that stops often, tunes the reason codes and escalation thresholds over two to four weeks, and then expands.
How POLYGLOTSOFT Builds Andon–MES Integration
POLYGLOTSOFT builds andon systems that keep your existing stack lights, andon boards, and PLC signals in place while connecting the call and escalation logic, plus the history data, to your MES. We roll it out in stages that fit how your floor runs: reason-code design, shift-data integration, mobile and smartwatch alerts, and downtime analytics dashboards. If you want to manage line stoppages as data instead of memories, talk to POLYGLOTSOFT.