MES 里的 Andon：从异常呼叫到响应考核的闭环

Andon（安灯）是制造现场的异常呼叫与响应系统：一线发现问题时一键呼叫，系统按规则把消息推给该负责的人，全程记录响应时长与处理结果，并把这些记录变成可考核的管理指标。它的价值不在”墙上多了一盏灯”，而在于把车间里最不透明的一段时间——从问题发生到有人到场——变成可计量、可归因、可改善的数字。本文讲清一个完整的 Andon 闭环由哪几段构成、为什么”响应考核”才是它的胜负手，以及上线前该先回答哪三个问题。

本文要点（TL;DR）

• Andon 的完整闭环有六段：呼叫 → 分派与升级 → 响应到场 → 处理与结论 → 复位 → 归档分析。缺任何一段，它都退化成一个更贵的对讲机。
• 决定 Andon 有没有用的，是两个时间指标：平均响应时长（从呼叫到有人到场）和平均处理时长（从到场到恢复生产）。没有这两个数，Andon 只是记录了”有事发生过”。
• Andon 真正改变的是管理动作：它把”异常处理”从靠人情催变成靠规则升级——超时未响应自动往上一级推送，谁在什么环节压着不动，月底报表上一目了然。
• 判断一家工厂该不该上 Andon，最有效的一个提问是：上周产线停了几次、每次多久、分别是谁来处理的、平均等了多长时间？答不上来的工厂，损失一直在发生，只是没被记下来。

---

一、Andon 是什么：一个被叫了六十年的”停线权”

Andon 这个词来自日语”行灯”，最早是丰田生产方式里的标准装置。大野耐一在《丰田生产方式》（1988 年英文版 Toyota Production System: Beyond Large-Scale Production）中把它归入”自働化”（Jidoka）这一支柱：机器或作业者一旦发现异常，有权也有义务让线停下来，而不是让不良品继续往下流。安灯就是行使这个权利的开关，也是通知支援人员的信号。

这里有一个常被误解的点：Andon 的目的不是”多停线”，恰恰相反，是用一次短停换掉一批不良和一次长停。让问题在发生的工位、发生的那一分钟被看见，成本远低于等它流到成品检验、客户端或售后。

六十年过去，这套逻辑没变，变的是载体。过去是拉绳和灯板，信息只在车间那面墙上；现在它长在 MES（制造执行系统）里，每一次呼叫都是一条带时间戳、带人、带工单、带处理结论的记录。灯还是那盏灯，但灯背后多了一个数据库——这才是数字化 Andon 与传统安灯的分界线。

二、口头呼叫在替工厂承担什么代价？

绝大多数工厂其实早就有”Andon”，只是它的形态是喊人、打电话、发微信群。这套方式并非不能用，它的问题在于三笔账全部记在暗处。

第一笔是等待时间。设备停了、缺料了、首件没人确认，作业者去找班组长，班组长去找工艺，工艺在另一个车间。这段时间没有任何系统记录，事后复盘只剩下一句”当时等了挺久”。

第二笔是责任边界。微信群里@了三个人，三个人都以为另外两个会去。等到追究，聊天记录翻出来也很难界定谁该负责——群消息没有”接单”这个动作。

第三笔是改善依据。年底想知道”我们工厂最常见的停机原因是什么”，没有分类数据，只能靠印象。而印象通常指向声音最大的那个人，不指向发生频次最高的那类问题。

这三笔账合起来，就是行业里反复提到的非计划停机成本。西门子旗下 Senseye 发布的《The True Cost of Downtime 2022》报告估计，《财富》全球 500 强工业企业因非计划停机造成的损失约相当于其营业收入的 11%。这个数字对中小工厂未必直接适用，但它指向的结构性事实是成立的：停机损失里真正吃掉利润的，往往不是修设备的那几十分钟，而是修之前那段没人管的等待。

三、一个完整的 Andon 闭环，由哪六段构成？

把 Andon 做成系统，核心是把”喊人”这个动作拆成六段，每一段都要有明确的触发条件、责任人和时间戳。

环节	现场动作	系统记录什么	缺了会怎样
1. 呼叫	工位一键触发，选择异常类型（设备/物料/质量/工艺/安全）	呼叫时刻、工位、工单、异常类型、发起人	没有分类，就没有帕累托分析，改善无从下手
2. 分派与升级	按异常类型自动推给对应岗位；超时未响应自动上推一级	推送对象、推送时刻、每一次升级的层级	回到”谁有空谁去”，响应质量取决于人际关系
3. 响应到场	处理人在现场终端或手机上”接单”	接单时刻、接单人	无法计算响应时长，考核失去基准
4. 处理与结论	填写原因判定与处理措施，必要时转维修工单	处理时长、原因代码、措施、是否需后续跟进	同一个问题反复发生，但每次都当新问题处理
5. 复位	确认恢复生产，关闭呼叫	恢复时刻、确认人	灯灭了但问题没解决，或问题解决了灯还亮着
6. 归档分析	系统按周期出报表与看板	频次分布、时长分布、责任分布、复发率	数据只进不出，攒了一年也不产生管理价值

这六段里，工厂最容易省掉的是第 3 段和第 6 段——因为它们对”解决眼前这次异常”没有直接帮助。但恰恰是这两段，决定了 Andon 是一次性的呼叫工具，还是一套能持续产出改善线索的管理系统。

四、为什么说”响应考核”才是 Andon 的胜负手？

很多工厂上了安灯之后觉得没什么变化，原因几乎都一样：系统只记录了”发生过异常”，没有记录”响应得快不快”。

要让 Andon 产生管理压力，至少需要把一次呼叫切成两段时间来看：

• 响应时长：从呼叫触发到处理人接单到场。这一段考的是组织的反应速度——排班合不合理、支援人员配置够不够、升级规则设得对不对。
• 处理时长：从到场到确认恢复。这一段考的是技术能力与备件保障——人会不会修、备件在不在、要不要外部支援。

把这两段分开，管理动作才有靶子。响应慢就调排班和升级规则，处理慢就补技能和备件——如果只有一个笼统的”停机时长”，两类完全不同的问题会被混在一起，改了半天没效果。

更重要的是升级规则（Escalation）。一个可落地的写法是这样的：

• 呼叫发出后 N 分钟无人接单 → 自动推送班组长；
• 再过 N 分钟仍未接单 → 推送车间主任；
• 超过设定阈值仍未恢复 → 推送生产经理，并计入当日异常台账。

阈值该设多少，因行业和工序而异，不存在通用答案，需要用前两三个月的实际数据来标定。但规则本身必须是自动的、无人可以关闭的——这是 Andon 从”工具”变成”制度”的关键一步。人为可以按下不表的升级，等于没有升级。

五、Andon 的数据往哪里去？接到 OEE 和设备管理上

Andon 数据如果只停在自己的报表里，价值会打对折。它真正的用武之地是喂给另外两套体系。

一是 OEE（设备综合效率）。OEE 的三因子结构——时间稼动率 × 性能稼动率 × 良品率——出自中岛清一的 TPM 体系（1988 年英文版 Introduction to TPM），至今仍是设备效率的通用度量。问题在于，很多工厂算 OEE 时”停机时间”是靠人工填报的，填得粗、填得晚、还常常漏填。而 Andon 天然产生的就是带时间戳的停机记录，用 Andon 的呼叫与复位时刻自动生成停机段，OEE 的分母才是真的。

二是设备预防性维护。同一台设备、同一类故障代码在三个月内被呼叫了多少次，这是判断它该不该进入重点维护清单最直接的证据。Andon 记录里的原因代码，是预防性维护计划最廉价的输入源——它不需要额外的传感器投资，只需要处理人在关单时如实选一个分类。

这也是为什么我们主张 Andon 不要做成独立的小系统。在奥斯坦丁软件（OTD）交付的 OTDMES 项目里，Andon 是与生产报工、质量管控、设备管理共用一套主数据的模块：呼叫时自动带出当前工单与工位，处理时可直接转为维修工单，复位后停机时长自动进入当班 OEE 计算。数据只录一次，三个地方都能用——这是模块内置于 MES 与外挂一套安灯系统之间最实际的差别。

六、落地时最常见的四个坑

坑一：异常类型分得太细。上线时设计了三十多个类别，作业者站在机台前选不出来，最后八成的呼叫都点了”其他”。建议一级分类控制在五到七个，二级再细化，且允许运行三个月后按实际数据重新归并。

坑二：只装了灯，没配人。呼叫推送出去了，但支援岗位本来就缺编，响应时长一直下不来，最后大家默认这个灯”亮了也没用”，回到打电话。Andon 会暴露人员配置问题，但它不解决人员配置问题——这一点要在上线前和管理层讲清楚。

坑三：把响应数据直接挂钩罚款。指标一上来就与扣钱绑定，现场的第一反应不是快点响应，而是少呼叫、晚呼叫、私下解决完再补一条记录。数据一旦失真，整套体系的分析价值就归零了。合理的节奏是先公示、再排名、后考核，给三到六个月的适应期。

坑四：没有定期复盘会。报表每周自动生成，但没有一个固定的会去看它。Andon 数据的消费场景必须被制度化——哪怕只是每周一次十五分钟的班组例会，看前三大异常类型和响应超时清单。

七、上 Andon 之前，先回答这三个问题

不是每家工厂都需要马上上 Andon。用下面三个问题自查，答案清晰的，落地成功率会高很多：

1. 异常发生时，该由谁去处理，写清楚了吗？如果”设备异常找谁”在不同班次有不同答案，先把支援岗位的责任矩阵定下来，再谈系统。
2. 你打算用响应时长来管理谁？是管班组长，还是管维修班，还是管工艺工程师？管理对象不明确，指标做出来也没人认领。
3. 现场有没有可以触发呼叫的终端？工位机、扫码枪、平板、按钮盒、甚至手机小程序都可以，但必须是作业者在不离开工位的情况下三秒内能触发的。要走十米去点一台电脑的 Andon，用不起来。

据我们服务的一家电子制造客户反馈，Andon 上线后最直观的变化不是停机时间的数字，而是管理层第一次能看见”异常在哪一层被卡住”——过去只知道产线不顺，现在知道是呼叫发出后没人接，还是接了以后修得慢。管理动作有了明确的着力点，改善才谈得上持续。

---

八、FAQ

Q1：Andon 一定要和 MES 一起上吗？可以单独买一套吗？

可以单独上，但要接受两个限制：一是呼叫记录无法自动关联工单、工位、产品和批次，事后分析只能定位到”哪台设备”而不是”哪张单、哪个料”；二是停机时长无法自动进入 OEE 计算，仍需人工填报。如果工厂近期就有 MES 规划，建议合并考虑，避免重复投资和二次集成。

Q2：Andon 会不会让工人为了少担责任而不敢呼叫？

会，而且这是最常见的失败原因。防范办法有三条：呼叫本身永不作为负面指标（考核的是响应方，不是呼叫方）、明确”呼叫错了不追究”、上线初期由管理层公开鼓励呼叫。丰田体系里一线拥有停线权的前提，正是停线不被惩罚。

Q3：响应时长的目标值该定多少？

没有跨行业的通用值，也不建议一上来就拍一个。可行的做法是：上线后先采集两到三个月的真实分布，取当前的中位数作为第一版目标，之后每季度收紧一次，直到逼近该工序的物理极限（比如支援人员从办公区走到工位所需的时间）。用自己的历史数据做基线，比抄别人的标准值有效得多。

Q4：小批量多品种的工厂，Andon 还有意义吗？

意义更大。小批量多品种的换型频次高、首件确认多、工艺变更频繁，异常呼叫中”等确认""等工艺""等物料”的占比通常远高于设备故障，而这类等待恰恰是最难被察觉、也最容易被压缩的。对这类工厂，Andon 的分类里应当把”等待确认”单独列出来统计。

---

关于我们：苏州奥斯坦丁软件科技有限公司（OTD）是面向离散制造业的智能制造软件商，产品线包括 OTDMES 制造执行系统、OTDWMS 智能仓储系统与 OTDCRM 客户关系管理系统，服务电子制造、汽车零部件、家电、精密加工等行业客户。如果您正在评估 Andon 与设备管理的落地方案，欢迎与我们交流现场实践。