Shop-floor Management
Andon Response Loop: From Abnormality Calls to Review and Improvement
The direct answer for an Andon response loop is to give every abnormality a clear type, owner, status and escalation path, then complete discovery, calling, acknowledgment, arrival, treatment, recovery, closure and review in sequence. Lights and dashboards are only information entry points. Andon effectiveness depends on clear response ownership, consistent timing definitions, and whether abnormalities become evidence for sustained improvement.
Andon Is Not a Light; It Is an Event State Chain
Traditional signal lights are effective for rapidly highlighting an abnormality, but without subsequent acknowledgment, treatment and closure records, they only prove that someone may have seen it. Closed-loop Andon creates a unique event for each call and links the location, equipment, work-order or product context, call type and current owner.
Status design should reflect actual shop-floor work rather than maximize the number of statuses. States such as unacknowledged, acknowledged, in treatment, awaiting collaboration, recovered and closed need clear entry conditions. Temporary recovery must be distinguished from root-cause closure; otherwise, closing an event may amount to nothing more than stopping a timer.
| Stage | Question that must be answered | Recommended records | Common break in the loop |
|---|---|---|---|
| Discovery and call | What happened and where? | Source, location, type and occurrence time | A light activates without creating an event |
| Acknowledgment and arrival | Who owns it and when did they take over? | Owner, acknowledgment time and arrival time | Nobody explicitly accepts a broadcast call |
| Treatment and collaboration | What conditions are missing, and is escalation needed? | Treatment notes, supporting roles and pending-parts status | Waiting is merged into treatment and cannot be analyzed |
| Recovery and closure | Has production recovered, and has the root cause been closed? | Recovery confirmation, temporary countermeasure and closure basis | Resetting equipment closes every issue |
| Review and improvement | Why did it happen, and how will recurrence be prevented? | Cause, countermeasure, owner and verification | Only event counts are reviewed; standards are never updated |
Abnormality Classes Should Map to Ownership, Not Accumulate Codes
Classification should first cover frequent, real shop-floor scenarios, such as equipment, quality, material, process, staffing and safety-related calls. Every class needs a default response group, optional supporting groups and escalation conditions; color coding alone is not enough.
Automatic equipment alarms and manual Andon calls must also be distinguished. A PLC fault code can trigger an event, but the business cause still requires on-site confirmation. One root cause may generate several equipment signals; these should be linked and consolidated for analysis rather than sending multiple notifications that dispatch different people to duplicate work.
| Abnormality type | Default response role | Required context | Escalation clue |
|---|---|---|---|
| Equipment abnormality | Equipment or maintenance role | Equipment, fault code, status and product | Cannot recover, recurring fault or external support required |
| Quality abnormality | Quality and process roles | Product, lot, defect and originating workstation | Impact is spreading, or segregation or disposition judgment is required |
| Material abnormality | Logistics or warehouse support role | Workstation, material, demand and current inventory | Continuous supply is threatened or lot identity is unclear |
| Process abnormality | Responsible process role | Process version, parameters and work steps | Parameter excursion, unclear standard or change required |
| Safety-related abnormality | According to the plant safety responsibility chain | Location, event and protective action already taken | Follow site emergency and line-stop rules immediately |
Define the Meaning of Response Timers Before Discussing Speed
Common timers include call to acknowledgment, call to arrival, arrival to recovery and call to closure. They reflect acceptance, response, treatment and root-cause management respectively. Keeping only one total duration makes it impossible to tell whether the bottleneck lies in dispatch, waiting for parts, technical treatment or approval.
Rules for pausing timers must be strict. Waiting for parts or a quality decision can be a separate status, but should not be used arbitrarily to improve response metrics. Responsibility transfer across shifts, at night and during unattended periods must also be explicit. Original timestamps must never be overwritten when statuses are revised.
- Occurrence time: use the equipment or system event time where possible, and retain the entry time for manual calls.
- Acknowledgment time: a specific responsible role accepts ownership, not merely the moment a message is broadcast.
- Arrival time: on-site work or an approved remote response actually begins, using one consistent definition.
- Recovery time: the line or equipment is confirmed to have recovered its specified function, which does not imply a permanent repair.
- Closure time: treatment records and necessary cause confirmation are complete; follow-up improvement may become a separate task.
Escalation Manages Risk and Resources; It Is Not Just Nagging
Escalation conditions can combine event severity, elapsed time, scope of impact and recurrence. When a condition is met, the system should escalate the event together with its existing treatment context so the new owner does not have to request every detail again. Escalation does not immediately release the original owner from responsibility.
Notification channels should fit plant network and device conditions and may include shop-floor audible and visual signals, LEDs, web displays or approved mobile messages. The number of channels is not the key; delivery, acknowledgment and failure fallback must be verifiable. A successfully sent message does not mean a person has responded.
| Mechanism | Purpose | Design point | Acceptance scenario |
|---|---|---|---|
| Severity-based escalation | Route high-risk events to the appropriate responsibility chain | Severity is confirmed by process and operations roles | Are high-severity events routed correctly? |
| Timeout-based escalation | Prevent unacknowledged or stalled events | Set separate acknowledgment and treatment conditions | Are the original owner and history retained after timeout? |
| Impact-based escalation | Respond when an abnormality extends to multiple workstations or critical delivery | Link equipment, product and work-order context | Is the event reassessed when its impact changes? |
| Recurrence-based escalation | Turn recurring abnormalities into improvement issues | Link the same equipment and failure mode | Do repeat events automatically surface previous countermeasures? |
| Notification-failure fallback | Prevent dependence on a single failed path | Retain delivery status and alternative channels | What happens when the network or device is unreachable? |
How Andon Connects with SCADA, OEE and Maintenance Workflows
SCADA provides equipment status and raw alarms. Andon routes abnormalities into the human response process. OEE uses consistent downtime events to analyze efficiency losses. Maintenance workflows take on tasks requiring further repair or improvement. The four can share event identifiers, but each has different primary responsibilities and closure conditions.
Interfaces must avoid bidirectional overwriting. Resetting equipment should not automatically delete Andon treatment records, and closing Andon should not automatically rewrite raw OEE status. If a maintenance system already exists, Andon can create or link tasks according to rules rather than defaulting to a separate, independent TPM product.
- Equipment events state facts; authorized roles add the business cause.
- Andon and OEE share start, end and cause mappings while retaining their respective analytical definitions.
- Events requiring repair are linked to equipment, failure mode, treatment, parts and related information.
- Recurring abnormalities enter the improvement backlog, and standards and thresholds are updated only after countermeasures are verified.
Roll Out in Stages Using Real Abnormality Drills
Start implementation with one area and a small set of frequent abnormalities. Validate the full path from call to recovery before extending to automatic triggers, mobile notifications and analytics. Before launch, separately rehearse normal operation, no acknowledgment, waiting for collaboration, shift handover, network loss and repeated alarms.
Review metrics should cover event counts, the response chain, recurrence and improvement execution rather than assessing teams only by average duration. Averages hide extreme events and encourage premature closure. Effective improvement requires examining actual event distributions and the main causes of loss.
- Inventory abnormalities: consolidate synonymous types and assign ownership and a default treatment entry point to each class.
- Define statuses: write observable criteria for acknowledgment, arrival, recovery and closure.
- Test scenarios together: verify behavior when equipment, people, networks and existing systems behave abnormally.
- Pilot with a team: check whether calls are easy to make, notifications are accurate, and records avoid unnecessary burden.
- Review regularly: close recurring problems and adjust routing and standards instead of merely publishing rankings.
Turn Every Call into Accountability and Organizational Learning
The essence of Andon is not how many colors it displays, but how it turns an abnormality into an event with context, ownership and status. Calling, acknowledgment, arrival, recovery and closure each have distinct meanings; escalation and notification merely keep that chain intact.
When Andon maintains clear boundaries with SCADA, OEE and maintenance workflows, shop-floor data can support both response and long-term improvement. Start by rehearsing the complete loop for a small set of frequent abnormalities, and measure value through recurrence and countermeasure verification rather than faster closure numbers alone.
Frequently asked questions
If equipment already has an alarm screen, is Andon still necessary?
It depends on whether alarms already enter a clearly owned response and treatment loop. If equipment only displays a prompt with no acknowledgment, escalation or review, Andon can add the accountability workflow. If the existing system already covers this completely, integration should take priority over duplicate construction.
Is a shorter response time always better?
It cannot be judged independently of event severity and treatment quality. Acknowledging or closing too early may improve the numbers without solving the problem. Arrival, recovery, root-cause closure and recurrence should be examined together.
Does Andon require a mobile app?
No. Shop-floor lights, LEDs, workstation terminals and web dashboards can all form an effective chain. Whether to use mobile notifications depends on network, device, security and job conditions; the key is that calls can be acknowledged and tracked.
Can Andon downtime be used directly for OEE?
It can be an important source, but the relationship among actual equipment status, call time and recovery time must first be calibrated. A manual call may occur after the actual stop, and production recovery may precede event closure, so common definitions and original timestamps are required.
