1. 课程导入与闭环工程认知

在制造现场，Andon（安灯）系统几乎已经成为异常响应的代名词。很多工厂都有物理拉绳、按钮盒或平板上的呼叫按钮，工人一按，看板亮灯、广播响起、班组长赶到现场。但如果追问一句：这次呼叫最后是怎么关闭的？是当场解决、临时对策、还是转成了工程变更？如果同样的问题明天再发生，系统里有没有留下可复用的判断依据？很多团队会发现，灯灭了，但问题并没有真正"闭环"。

本课程讨论的Andon呼叫到问题关闭闭环工程，指的是一套把"现场异常触发"与"问题彻底关闭"连接起来的工程化机制。它不是单纯部署一套安灯硬件，也不是把问题记录到Excel里就算完成，而是要让每一次呼叫都沿着可追踪的路径走完：触发、响应、升级、临时对策、根因分析、永久对策、效果验证、标准固化，最终形成可统计、可复盘、可预防的知识资产。换句话说，Andon解决的是"异常被看见"的问题，闭环工程解决的是"异常不再重复发生"的问题。

为什么"有Andon"不等于"有闭环"

我们可以用一条典型的响应链来理解两者的差距。假设某装配工位在拧紧工序发现扭矩报警，工人按下Andon。理想情况下，系统应记录：呼叫时间、工位、设备编号、报警代码、当班产品型号、操作员。班组长在3分钟内响应，判断是刀具磨损还是程序参数漂移。如果是刀具磨损，更换刀具并做首件确认，这是临时对策；但真正的根因可能是刀具寿命管理阈值设置过宽，需要调整PM周期，这才是永久对策。如果系统只记录"已处理"，那么下一次换刀周期到来时，同样的问题会再次触发。

因此，闭环工程的核心不是"响应快"，而是响应之后有没有把问题推到不可逆的关闭状态。这要求我们把Andon从"呼叫工具"升级为"问题生命周期管理工具"。

闭环工程的价值：从"救火"到"防火"

把上述链路跑通之后，现场会发生几个可观察的变化。第一，呼叫响应时间不再靠人盯，而是由系统按工位、班次、报警类型自动统计，班组长能清楚看到哪些工位是高频触发点。第二，临时对策和永久对策被分开管理，避免"换了刀就算解决"的假闭环。第三，关闭环节强制要求回写标准文件，使得每一次异常都变成一次标准升级的机会。

以一个真实感较强的教学示例来说明。某电子装配线在两周内记录了48次Andon呼叫，其中31次集中在同一台自动锁螺丝机，报警代码均为"扭矩超上限"。如果只看响应时间，平均4.2分钟，似乎表现不错。但把闭环链路打开后会发现：其中28次只做了"复位重启"，没有记录根因；只有3次进入了根因分析，最终发现是电批批头磨损周期设定为8000次，而实际在6200次左右就开始出现扭矩漂移。把PM周期改为6000次并增加首件扭矩点检后，接下来两周该工位呼叫降到4次。这个示例说明，闭环工程的价值不在于灯亮得多快，而在于把重复发生的异常压缩成一次性的标准改进。

适用场景与边界

Andon闭环工程最适合以下场景：多工位、多班次的离散制造或装配线；异常类型可分类、可编码的工序；已经有基本的信息化记录手段（MES、Andon系统、工单系统或至少是结构化表单）；管理层愿意把"问题关闭率"而不是"响应速度"作为核心指标。相反，如果异常本身无法分类、现场完全没有记录习惯、或者组织只考核"灯灭得快不快"，那么闭环工程很容易退化成填表运动。

需要特别说明的是，闭环工程并不要求一开始就上昂贵的软件。一个最小可行的闭环可以只用一张结构化的问题跟踪表加每日15分钟的异常复盘会来跑通。关键是字段完整、责任明确、验证有据、关闭有审批。软件只是让这条链路更快、更可统计。

本课程的学习地图

接下来的30章会沿着"认知—设计—运行—改进"的主线展开。前段帮助大家建立闭环工程的整体认知，明确Andon呼叫、响应、升级、根因、对策、验证、关闭各环节的定义与接口；中段进入工程实现，包括呼叫触发方式设计、分级响应规则、升级矩阵、问题编码体系、根因分析工具、对策跟踪与验证方法；后段聚焦运行与改进，包括数据看板、关闭率与复发率指标、复盘机制、横展与标准固化，以及常见失败模式的排障。

学习时建议带着自己现场的一个真实异常案例来对照。每学完一个环节，就问自己：这个环节在我的现场有没有？输入是什么？输出是什么？谁负责？如果缺失，会发生什么？这样比单纯记概念更容易形成可落地的闭环能力。