3. 闭环工程总体架构设计

很多工厂的 Andon 系统“看起来能用”，但真正跑起来后常常出现三种断裂：呼叫发出去了没人接、问题处理完了没人验证、验证通过了数据没沉淀。根因往往不是某个环节做得差，而是缺少一张把角色、流程、数据、系统、制度五要素串起来的端到端架构。本节要解决的，就是让“一次呼叫”从触发到关闭，在架构层面有明确的归属、路径和证据。

一、五要素架构：不是五个模块，而是一条闭环链

闭环工程总体架构可以理解为五个相互咬合的要素层，它们不是并列的五个功能，而是同一条链上的五个约束面：

• 角色：谁触发、谁响应、谁处理、谁验证、谁关闭。角色不清，流程必然在交接处断掉。
• 流程：从呼叫触发到问题关闭的状态迁移路径，包括升级、挂起、退回、重开等分支。
• 数据：每一次状态变化留下的时间戳、责任人、原因分类、处理动作、验证结论。
• 系统：承载流程与数据的 IT/OT 载体，如 Andon 终端、MES、工单系统、看板、消息推送。
• 制度：响应时限、升级规则、关闭标准、复盘要求、考核口径，让流程“不靠人自觉”。

五要素的关系可以概括为：制度定义流程，流程约束角色，角色操作系统，系统沉淀数据，数据反哺制度。任何一环缺失，闭环都会退化成开环。

二、端到端状态链：一次呼叫的完整生命周期

把架构落到具体运行上，一次 Andon 呼叫会经历一条明确的状态链。以某电子装配线“工位缺料呼叫”为例，典型状态迁移如下：

1. 呼叫触发：操作员按下工位 Andon 按钮，选择“缺料”类型，系统记录工位号、触发人、触发时间（如 09:14:22）。
2. 响应确认：线长在 3 分钟内到达或远程确认，状态变为“已响应”，记录响应人、响应时间。若超时未响应，自动升级到车间主管。
3. 处理执行：物料员根据呼叫信息配送物料，记录处理动作与完成时间。若物料短缺无法立即解决，状态转为“挂起”，并触发采购或仓库协同。
4. 验证确认：操作员确认物料到位、生产恢复，状态变为“待验证”。由线长或质检确认问题确实消除，记录验证人与验证结论。
5. 关闭归档：验证通过后关闭工单，系统归档全过程数据，进入日/周复盘统计。

这条链的关键在于：每个状态都必须有明确的进入条件、责任角色和退出证据。例如“关闭”不能由处理人自己点，必须由验证角色确认，否则就是“自处理自关闭”，闭环形同虚设。

三、角色与职责边界：谁在什么状态下做什么

角色设计最容易犯的错误是“一人多角”导致责任模糊。建议按状态明确主责角色：

注意“验证确认”与“处理执行”必须由不同角色承担，这是闭环工程的一条硬约束。若产线人手紧张，至少也要做到“处理人不能同时是验证人”，可通过班组长或质检交叉验证实现。

四、数据与系统：让闭环有据可查

闭环工程的数据设计要围绕“可追溯、可统计、可复盘”三个目标。一次呼叫至少应记录以下字段：

• 标识类：呼叫编号、工位号、产线号、班次。
• 时间类：触发时间、响应时间、处理开始/结束时间、验证时间、关闭时间。
• 角色类：触发人、响应人、处理人、验证人。
• 内容类：呼叫类型、问题描述、原因分类、处理措施、验证结论。
• 指标类：响应时长、处理时长、闭环总时长、是否超时、是否升级。

系统层面，Andon 终端负责触发与状态展示，MES 或工单系统负责任务流转与数据存储，看板负责实时可视化，消息推送负责升级提醒。四者之间通过事件或接口联动，避免“终端按了、系统没记录”的断点。

五、制度：让架构“不靠人自觉”

制度是五要素中最容易被忽视、却决定闭环能否持续的一环。至少需要明确四类规则：

1. 响应时限：如“缺料类 3 分钟响应、设备类 5 分钟响应”，超时自动升级。
2. 升级规则：一级升级到线长，二级升级到车间主管，三级升级到厂长或值班经理，每级间隔明确。
3. 关闭标准：必须验证通过才能关闭，禁止处理人自关闭；挂起工单需设定最长挂起时限。
4. 复盘要求：每日统计超时与高频呼叫，每周对 Top 3 问题做根因分析并跟踪改善。

制度不是写在墙上的口号，而要嵌入系统：超时自动升级、关闭前强制验证、数据自动汇总。这样制度才从“要求”变成“默认路径”。

六、架构落地的检查要点

在推进闭环工程时，可以用以下问题快速自检架构是否完整：

• 每个状态是否都有唯一主责角色？是否存在“无人认领”的状态？
• 处理人与验证人是否分离？关闭是否有验证证据？
• 系统是否记录了完整时间戳与责任人？能否自动计算响应/闭环时长？
• 超时是否有自动升级？升级后是否有兜底角色？
• 数据是否进入日/周复盘？复盘结论是否反哺制度或流程优化？