Andon is on but nobody owns the stop? Downtime codes must close with the shift—not as “Other” later

Red lights look busy—the data dies in three months

Andon online: pull cord, light up, big screen. Three months later, operators found that even if they pulled it, no one came; team leaders discovered that reasons could be submitted blank; the maintenance hours of the equipment engineers were in another Excel sheet. The light is still on, but the data is dead.

Shutdown management should be able to answer four questions:Who responds, how long will it take, which category does the damage fall under, is there any prevention for recurrenceThe four Q&A modules do not integrate into the system, and the Andon screen is just for decoration. Hardware can be purchased later; if the dictionary, time limits, and shutdown rules are not established, even replacing with a larger screen won’t save the 'others'.

Call chain: put SLAs into rules

The night shift response time is configured according to the shift, and escalations go to the actual on-duty person, not the department's daytime email. If the duty roster is not entered into the organization, escalations will go to a dead number—this is a system issue, not entirely about attitude. Response timeouts must be recorded: without a 'timeout not answered' record, the weekly meeting can only scold people based on feelings.

Pseudo shutdown management: The roles of the person shutting down and the caller can be separated; key equipment requires production confirmation for restoration. Only the maintenance side is allowed to turn off the light, which may result in the light being off while the person has not arrived and the line has not been activated.

If “Other” exceeds ~15%, pause ranking first

Governance Signals:

• "Others" proportion;
• Secondary blank rate;
• Repeated defect codes on the same device;
• Deviation between downtime duration and maintenance work order duration.

"The 'other' category is often high because the dictionary cannot map the on-site language. First, co-create the dictionary with the team for two weeks, then discuss assessment. If assessment comes first, it will only train everyone to choose the easiest code to fill in."

Dictionary changes must have versions: clearly specify the announcement effective date and whether historical data is reclassified. Changing the dictionary while ranking will lead the site to believe the rules are negotiable. It is recommended that primary codes have 8–12 categories, and secondary codes expand according to devices. The more categories there are, the higher the 'others' category tends to be—expansion itself is a sign of failure.

Sample downtime-code skeleton (trim as needed)

This table is not the standard answer, but a reference scale for the 'Other' category when it expands. The on-site terminology is mapped into the second level, while the first level remains stable, so that history can be compared. Planned model changes must be checked against the system's planned window; retroactively changing overdue items to 'within plan' is a classic method of manipulating statistics.

Share one downtime record with OEE, dispatch, and labor booking

Availability loss must roll up from Andon/downtime records—no separate OEE “downtime pad sheet.” Microstops (e.g. <2 min) may merge under published rules; kicking all microstops out of the denominator is how definition wars start.

When waiting for materials causes a shutdown, try to automatically link it to line-side material shortage — otherwise, logistics losses may be recorded as equipment losses, causing the two departments to correct in the wrong direction. Long stoppages should be readable by the dispatch board: if equipment is unavailable, limit new dispatches, or have the shift leader confirm "repair while working" (explicit exception).

Mutual undercutting between reporting work completion: It is still allowed to report completion normally during downtime, causing both progress and OEE to lie. At least one of the two rules should be chosen: either completion reporting is prohibited during downtime for that equipment; or reporting work must include the 'repairing while working' exception code. If neither is set, the red light is just for show.

Long stop one-click conversion to maintenance order; maintenance closure backwrites stop end — recorded separately on both sides, MTTR must be false. There is a long-term deviation between downtime duration and maintenance hours, first check whether each records its own start and end times, then check whether anyone turned off the lights early.

Shift close: open downtime must not look “clean”

If there are still Andons not closed at the end of a shift: block or strongly remind the end-of-shift process. Otherwise, the next shift inherits the red light, and the reason is left for the next shift to guess. The shift-end report lists: number of unclosed Andons, number of overdue responses, and the proportion of 'others' — three figures go into the morning meeting, which is more useful than buying a bigger screen.

Top-level cause codes should be able to link to actions: maintenance countermeasures, process changes, and spare parts safety stock. If there is only a category without an action, filling in the code will be regarded as a discrepancy, and the data will collapse back to 'Other'. Duplicate defect codes should go to the equipment and process joint meeting, rather than only appearing in the shift leader's personal notes.

One line, two weeks, three metrics

Choose the most contested production line: enable overtime upgrades, disable mandatory reason codes, restrict 'Other'. Look at average response, the proportion of 'Other', and the downtime-maintenance correlation. If the three numbers don’t change, don’t replace hardware across the whole plant for now — hardware can be bought later, but the dictionaries and upgrade chain must be properly run first.

Acceptance sample one shift: pick three long stops and confirm responder, arrival, reason code, work-order ID, and production clear-to-run; also check that shift’s “Other” share and open count. If they do not line up, stop expanding lines—a bigger board is only decoration.

Link back to people, spares, and process changes

When the reason for downtime falls under 'personnel/skills,' it should be possible to pinpoint gaps in on-duty qualifications and authorizations—otherwise, the training plan will still be decided arbitrarily on an annual basis. When it falls under 'spare parts,' it should be possible to see whether there is a lack of safety stock or any open purchase requests; merely classifying it as 'equipment failure' without linking back to spare parts keeps improvements stuck at verbal commitments to replacing parts.

In the first week after a process change, changeover/setup overtime often increases. The dictionary should be able to distinguish between 'change implementation period' and 'steady-state overtime' to avoid permanently recording the implementation cost as poor team capability. The change order number can be attached to the downtime record, so that in weekly meetings, teams compete for resources rather than just passing the blame to each other.

The reason for being Top has remained unchanged for two consecutive weeks with no action orders, indicating that Andon is still stuck at 'code filling.' The action order can be rough, but it must have a responsible person and a due date; without action, code filling will revert to been considered delayed.

Planned downtime vs loss downtime

Planned shutdowns (maintenance, planned model changes, energy inspections) must have a planned target and a time window; activities within the window are recorded as planned, while those outside the window are recorded as losses. A 'planned shutdown' without a planned target is hiding losses behind the back door of the plan.

If maintenance exceeds the time and automatically reverts to the plan, the equipment department will lose the pressure to improve. Overflow minutes incur losses and allow associated maintenance order numbers — both retaining the plan semantics and not erasing the overtime.

Upgrade when multiple lines share maintenance resources

When two lines go red together, a per-line-only SLA pulls maintenance into “whoever yells loudest.” Shared pools need queueing and priority (safety stop > bottleneck > normal) with ETA on the Andon board. Without a visible queue, operators re-call, data fills with duplicate noise, and response time looks worse than it is.

Minimum gate for trustworthy data

Within two weeks of go-live, if codes can submit blank, close needs no arrival confirm, or OEE keeps a separate downtime sheet—any one of the three—turn off ranking boards first. Ranking on untrusted codes trains worse coding. Pass the gate before plant-wide benchmarking; until dictionary and escalation clear the gate, hardware spend can wait. Better buy the big board two weeks later than open rankings on untrusted codes.

• MES manufacturing solution
• OEE three rates
• Scan code to report work collection point
• Line-side logistics docking WMS