车间主任早上问一句「这批为什么晚了」，最省事的回答是打开 MES，指着某道工序的报工时间说「这里就慢了」。这句话没有说错，但它只描述了延误发生的位置，没有回答为什么。计划是不是被改过、料是什么时候才到齐、这道工序返工过几次、检验放行又等了多久，这些记录分别躺在 ERP、WMS、MES 和质量单据里。只查一个系统，能看到的通常是结果。这篇写一次延误排查该按什么顺序走、每一类原因要哪个系统作证、哪些结论不该让 AI 直接下，以及首个排查场景拿什么验收。
延误排查要做的，是把「哪一步慢了」变成「哪几笔记录彼此对不上」。受控范围内的跨系统查询负责把这批记录按同一张工单、同一条时间轴排到一起，给出可核查的线索清单；至于原因是否成立、要不要调计划或换料，仍由计划员、工艺和质量责任人判断。星云 PLUS 在这类场景里的角色，是让 AI 在员工已有的系统权限内完成跨系统查询与分析，不换系统、沿用员工权限、关键操作人确认、调用审计。
延误是结论，MES 里看到的往往是结果
MES 擅长记录工序现场：哪道工序什么时间开工、什么时间报工、由哪个班组完成、实际完成多少件。这些数据回答「做了什么」，却很少解释「为什么没能按时做」。
延误的起点经常在 MES 之外。客户改交期或临时插单，计划侧的排产顺序就变了；原料到货晚于计划用料时间，工位只能等；上一道工序被判返工，后面的工序跟着顺延。这些事件都真实发生，但它们未必在 MES 里留下完整痕迹。于是出现一个很常见的局面：同一次延误，MES 上是一串变晚的报工时间，ERP 上是一次计划变更，WMS 上是一条晚到的收货记录，三者时间上互相咬合，却被分别看在三个人的屏幕上。
| 在 MES 里看到的现象 | 可能的起点位置 | 说明 |
|---|---|---|
| 某工序报工时间整体后移 | 计划侧 | 工单本身被调整过顺序或日期，工序按新计划执行 |
| 工序之间出现长时间空档 | 物料侧 | 待料、批次不合格或备料未完成，工位在等 |
| 同一工序报工多次 | 执行或质量侧 | 返工重做，或设备短暂停机后的补报 |
| 完工时间晚于计划，但各工序耗时正常 | 计划或质量侧 | 计划开工时间已推后，或检验放行占用时间 |
这张表只列可能性，不代表其中任何一项已经发生。
四类原因，分别要哪个系统作证
把原因归类之后，查什么、到哪查就清楚了。下面四类涵盖了制造现场常见的延误成因；实际企业里字段归哪个系统保存，仍要看各自的系统建设情况。
| 原因类别 | 典型表现 | 主要作证系统 | 需要对齐的时间点或字段 |
|---|---|---|---|
| 计划类 | 交期变更、插单、工单改期、计划未及时下达到工位 | ERP 计划与订单、MES 工单派工 | 计划开工与完工时间的前后版本、变更时间 |
| 物料类 | 原料未到、批次不合格、备料未完成 | WMS 收货与备料、ERP 采购 | 实际到齐时间与计划用料时间的先后 |
| 执行类 | 报工延迟、返工、设备停机 | MES 报工与设备状态记录 | 各工序实际开始与结束时间、返工次数 |
| 质量类 | 检验未放行、判定返工或让步接收 | 质量检验单据 | 送检时间、判定时间与放行时间 |
四类记录有一个共同前提：只有在同一张工单、同一个物料、同一段计划时间下比较，时间点才有意义。把不同工单或不同批次的记录拼在一起，得到的只会是一张看起来很像证据、实际站不住的表格。
一次排查按什么顺序走
按固定顺序排查，每一步都建立在上一步已确认的事实上，不容易越查越乱。
- 先锁定范围：明确一张工单、一个物料、一段计划时间。范围不锁定，后面所有时间点都无从比较。
- 查计划侧：拉出这张工单的计划版本与变更记录，确认计划开工、计划完工时间是否被调整过，调整发生在什么时间。
- 查物料侧：对齐计划用料时间与实际到齐时间，核对是否存在批次状态不满足领用条件的情况。这一步要回答的是「工位当时有没有料可用」，只看仓库账面数量并不足以判断。
- 查执行侧：看各工序的实际开始与结束时间、是否存在返工报工、设备状态是否在同一时段有停机记录。
- 查质量侧：对齐送检、判定与放行时间，确认检验环节是否占用了等待时间。
- 汇总成清单：交付物应该是一份可核查清单，每一行写清任务、时间点、记录来源系统，并标明哪些已证实、哪些缺少权限无法核对。
这份清单同时是一份待办分工表：物料侧的时间差交给采购或仓储核实，执行侧的交车间和工艺核实，质量侧的交检验核实。AI 把该找谁、该核什么整理出来，核实动作仍由对应岗位完成。
哪些结论不能下，边界在哪里
延误归因往往牵涉考核与责任，这一层判断不适合交给模型。AI 能给出的是记录之间的对不上之处，不能替任何人认定哪道工序、哪个岗位该负责。
同样需要守住的是一条数据边界：员工账号看不到的采购价格、其他车间工单或未授权的质量结论，查询结果里应当写明「该部分证据缺失，需有权限的人补充」，不能用推算填满。星云 PLUS 采用两层权限判断，连接器只决定当前员工能否调用某项能力，功能权限与数据权限仍由目标系统按其账号规则最终判断，因此不同岗位拿到的同一份查询，数据范围本来就应该不同。
如果后续把延误处置也接入进来，比如由 AI 在原业务页面里预填调整工单或补录说明，那属于写操作，默认要求员工确认后才生效。页面预填只是把字段准备好，页面预填不等于提交成功，一切以页面回执或目标系统的实际结果为准。设备控制类动作不在本文范围，也不在已确认的产品能力内，是否需要该方向须结合 MES 能力与现场安全条件单独评估。
同一项能力，不同岗位看到的数据不同
计划员关心计划达成与交期风险，车间主管关心工序进度与人员设备，工艺与质量关注判定依据。用同一套查询能力服务这些角色时，最容易踩的坑是「一份结果发给所有人」。
按岗位收敛的做法是：把查询能力按员工、用户组或组织授权，同一项能力只发给需要它的角色；数据范围则继续由 MES、ERP、WMS 各自按员工账号判断。这样计划员看到的是计划与进度，质量员看到的是检验相关信息，跨范围的数据不出现在查询结果里，无需先查出来再在界面上隐藏。
首个排查场景怎么验收
不要一上来就覆盖全部产品线，也不必先接完所有系统。选一张工单、一个物料、一段时间的延误，先把这一条链路走通，再谈扩展。
| 验收项 | 要回答的问题 | 证据形态 |
|---|---|---|
| 结果可核查 | 查询结论与人工核对是否一致 | 取一组人工已核过的延误样本做对照，结论一致或差异有说明 |
| 权限与原系统一致 | 不同岗位通过 AI 看到的数据范围有没有被放大 | 与原系统中的可见范围逐项对照 |
| 确认机制到位 | 场景里的写操作是人工确认还是允许自动执行 | 逐项配置的记录，并以页面回执为准 |
| 审计可追溯 | 每次查询能否还原 | 能查出是谁、在什么入口、用了哪项能力、对哪个系统、结果如何，支持查询与导出 |
| 异常有表现 | 系统不可用、数据缺失或权限不足时是什么表现 | 结果明确提示，不静默返回空值 |
首个排查场景可按上述边界先行验证；正式项目周期应以场景范围和系统条件评估为准，不作为承诺。
结语
只查 MES 能回答「哪里晚了」，回答不了「为什么晚」，而车间要的往往是后者。可行的路径是把计划、物料、执行、质量四类记录按同一张工单排到一起，形成一份标明来源与待确认项的清单，让 AI 承担跨系统查找与整理，让责任人承担判断与处置。从一个工单的延误排查开始，把权限、确认、审计和异常一起验收，再逐步扩展到更多工序和更多系统。
常见问题
AI 能不能直接自动排产，或者调整设备参数？
不能。本文的场景范围是查询与分析，不涉及排产决策，更不涉及设备控制。已确认的产品能力不包含设备控制；是否需要往这个方向评估，要结合 MES 自身能力与现场安全条件单独判断。计划怎么调，仍由计划员决定。
没有完整 API，这个场景还能做吗？
可以先把只读数据和可用接口评估一遍，从结果容易核查的小范围查询开始。具体需要补哪些接口、要不要复用原业务页面，以项目评估为准。
计划员能通过 AI 看到其他车间的工单吗？
不能因为用了 AI 就扩大范围。连接器先判断当前员工能否调用这项能力，目标系统再按员工账号判断功能与数据权限；超出范围的部分应在结果里标明缺失，由有权限的岗位补充。
AI 会把延误原因直接定责吗？
不会。查询结果是一份待核查的线索清单，说明哪些记录之间存在时间差，不给出责任判定。是否构成责任事件，由企业内部流程与相应岗位认定。
相关阅读：AI 系统连接器 · MES 场景解决方案 · 库存与物料短缺核查 · 订单交期跨系统核查
从一个生产延误场景开始评估
明确工单范围、相关系统、员工权限与核查证据，再确定首个可验收的查询场景。
预约系统连接评估