安灯系统与停机响应：把“等人来”的时间量出来、压下去

安灯管的是停机里“等”的那一段

安灯（Andon）是一套现场异常的呼叫与响应机制：操作工发现问题，用一个动作发出呼叫；对应的责任人在规定时间内到场；超时没人响应或问题迟迟没解决，系统自动逐级上报。灯、绳、屏幕都只是载体，核心是“呼叫—响应—升级”这三段规则。

它解决的问题很具体。把一次故障停机拆开看，真正动手修的时间往往只占一部分，其余的是：操作工满车间找班组长、班组长打电话找机修、机修在另一条线上走不开、来了发现要找电工、备件要去库房领。这些“等”的时间在传统的停机记录里是看不见的，全都混在一个总时长里。安灯一方面用机制压缩它，另一方面用时间戳把它量出来。

呼叫、响应、升级：三段规则怎么定

呼叫：谁可以叫、叫什么、叫给谁

呼叫要分类别，每一类对应明确的责任角色。类别不要多，四到六类足够：

灯色各厂自定，全厂统一即可。有两点需要事先讲清楚：一是呼叫不等于停线，物料快用完时的呼叫是预警，设备还在转；二是哪些情形操作工有权直接停线（比如连续出现同一种不良），要成文，让人敢停。质量类呼叫与停线权限的关系，见质量异常停线。

响应：到场要有动作确认

“响应”必须是一个可记录的动作：责任人走到工位，在现场按下确认键或刷卡。在办公室电脑上点“已收到”不算，手机上点“已知悉”也不算。只有在现场确认，响应时间才是真实的“人到了”的时间。

升级：超时自动往上报

升级规则分两条线：没人来要升级，来了修不好也要升级。下面是一个示例，时间阈值请按自己工厂的实际情况设定：

升级的目的是调动更多资源，而不是追究第一响应人。机修没到场，多数时候是因为他正在处理另一台设备，这时候班组长收到升级通知，要做的是协调另一个人过去，或者决定先换产。升级阈值对瓶颈设备可以定得更紧，非关键设备放宽，避免管理层的手机被不重要的通知淹没。

响应时间怎么计入 MTTR

平均修复时间（MTTR）如果只从维修工动手那一刻算起，算出来的是“修理效率”；从设备停下到恢复生产算，才是生产一侧真正承受的停机。建议的口径是：MTTR 取停机到恢复的全过程，响应时间是其中的第一段，单独拆出来统计。有了安灯的几个时间戳，一次停机可以拆成三段：

拆开以后对策就清楚了：响应段长，问题在人员配置、呼叫方式和区域划分，第 2、4、6 次都发生在什么时段、当时机修在哪，值得查；诊断与修理段长，问题在技能、图纸资料和备件；恢复段长，问题在调机和首件确认流程。不拆开，只能笼统地说“维修太慢”。MTTR 的完整算法和口径见 MTBF 和 MTTR 怎么算。

还有一段时间安灯量不到：从设备停下到操作工按下呼叫之间的延迟。操作工常常先自己折腾十分钟，搞不定才叫人。如果同时有设备运行信号的自动采集，两边一对比就能看到这段延迟；也可以设成“设备停机超过若干分钟未呼叫则自动触发安灯”。

拉绳、按钮盒、平板：三种形态

选形态时守住一条：呼叫本身必须是一个动作、两秒钟完成。详细原因可以等人到场之后再补选，不要让操作工在设备冒烟的时候翻三层菜单。不少工厂采用混合方式：呼叫用按钮盒，关闭时在平板上由响应人补选原因和处理措施。

安灯记录就是停机原因数据

每一次安灯呼叫天然带着几个字段：哪台设备、哪个类别、几点呼叫、几点到场、几点关闭、谁响应的。这和一条停机记录需要的要素高度重合，而且时刻是系统自动打的，不存在事后回忆和取整的问题。用好它要注意三点：

1. 类别与原因码对齐。安灯的呼叫类别应当就是停机原因码的第一层（设备、质量、物料、工艺……），关闭时补选的具体原因对应第二层。两套编码各搞一套，后期数据对不上。编码的分层方法见停机原因码怎么设计。
2. 区分“呼叫”和“停机”。不是每次呼叫设备都停了，也不是每次停机都有人呼叫。最好的做法是把安灯记录和设备运行信号按时间合并：信号给出精确的停机起止，安灯给出类别和响应过程，这正是人工记录与自动采集相结合的一种落地方式。
3. 用响应数据看“等人”的损失。按类别、按班次、按区域汇总响应时间，能直接看出哪个时段支援力量不足——比如夜班只有一个电工、物料员午休时无人顶岗。这类损失在传统记录里往往被归进“设备故障”，实际上属于待人停机。

上线前对照检查

• 呼叫类别是否不超过六类，每类都有明确的第一响应人和替补？
• 操作工的停线权限是否成文并培训过？
• 响应确认是否必须在现场完成？
• 升级阈值是否区分了关键设备和一般设备？
• 夜班、周末、午休时段的响应人是否排了班？
• 关闭呼叫时是否要求补选原因和处理措施？
• 有没有人每周看一次响应时间和呼叫分布，并拿到早会上讲？

最后一条最要紧。灯亮了没人来，来了几次之后操作工就不再按了；数据收上来没人看，响应人也就不再认真确认。安灯能不能活下来，取决于管理层是不是真把每一次呼叫当回事。