第 9 课 上线之后，去现场看他们到底用没用

假设第 7 课的只读试点达到了事先约定的标准，负责人决定先让一个班组在日常工作中使用；如果还要写入工单，也已经按第 8 课完成审批和安全检查。功能能打开、人员会登录，这时只能说明系统“上线”了，不能说明它改善了工作。

班组长可能看过 AI 建议，仍照旧拿起对讲机派人；也可能把建议抄进交接本，系统里却没有处理记录。这一课要回到现场，分别检查建议有没有被看到、有没有影响判断，以及设备异常的处理结果有没有变好。

分三层看

第三层最有说服力，也最容易被误读。如果试点期间设备状态恰好不错、告警少，结果"变好"未必是 AI 的功劳。所以用来对比的老数据（基线），要取自试点前同一条产线、相近时段的记录。

站在旁边看，不打断

具体做法是：带着本子，站在一线旁边看完一个班次，不教、不纠正。这种做法的标准叫法是跟岗观察。

至少选一个白班、一个夜班。两个班次的人手和压力不一样，看到的情况也会不一样。

观察结束后，可以照着下面这几句问：

• "刚才那条告警，你是先看屏幕，还是先打电话？"
• "建议里哪一句你直接跳过了？"
• "有没有哪次你觉得它说得不对，但懒得点驳回？"
• "要是明天把它关掉，你会觉得少了什么？"
• "你自己另外记的本子或表格里，有哪些内容是系统里没有的？"

最后一个问题，常常能问出大家私下维持的另一套做法，这种做法通常叫影子流程。它的存在说明，工具还缺了一线需要的东西。

验收清单

验收标准最好在上线前就和业务负责人定好。如果当时没定，现在补上并签字，避免事后按结果倒推"合格"。

【试点验收清单】范围：试点产线 ____  班次 ____  时间 ____ 至 ____
□ 到达：告警后建议被一线查看的比例达到 [待确认：与设备主管约定的阈值]
□ 采纳：驳回原因已分类，排在前几位的原因各有对策
□ 结果：告警到开单的时间与基线相比 [待确认：约定的改进幅度]
□ 安全：没有越权写入；每次写入都能在日志里追到发起人和批准人
□ 回滚：撤销流程真实用过，或完整演练过
□ 负担：跟岗观察确认，一线没有因此多出重复录入
□ 停用：停用开关可用，关闭后能回到原流程
结论：扩大范围 / 调整后再试 / 暂停 / 停止
签字：业务负责人 ____  一线代表 ____  项目负责人 ____

"停止"也是合格的结论。试点本来就是用小代价，看清一件事值不值得做。

使用衰退与复盘

头几周大家还有新鲜感，之后可能慢慢就没人用了。这种现象叫使用衰退，来源一第 5 章也谈到过。

应对办法是定期回看：每周看一次采纳和驳回记录，每月再跟岗一次。发现使用量下滑，先去现场问原因，别急着加提醒、加功能。

复盘会开 30 分钟就够，按下面的顺序：

1. 5 分钟：用日志摆事实。这段时间有哪些告警，建议分别被怎样处理。
2. 10 分钟：请一线讲讲驳回最多的场景。
3. 10 分钟：决定改什么。数据、判断、动作、流程，一次只改一处。
4. 5 分钟：定下次复查的时间和负责人。

今天先做一步

约一位班组长，在他的班次里旁听 30 分钟。至少填满观察表的三行，并问出那个关于"另外记的本子"的问题。

本章产物

• 至少两个班次的跟岗观察记录。
• 一份签过字的验收清单。
• 一页复盘纪要，写清结论，以及下一轮只改的那一处。

常见错误

• 把登录次数、生成条数当成效果。
• 只访谈支持项目的人。主管说好用，不代表班组长真的在用。
• 验收标准等到上线后才定。
• 发现没人用，就忙着加功能，却没去问大家为什么绕开。
• 把一线绕开工具当作"不配合"。绕开往往说明，工具让某件事变慢了。