记录停了多久是起点，记录为什么停才有价值
只记“停了 47 分钟”没有改善价值。停机原因码怎么设计、怎么让工人认真选、三个月后怎么调整，决定了这套数据能不能用起来。
按责任归属做一级分类
设备类、物料类、计划类、质量类、人员类、外部类——这样分，改善会上每一类都有明确的负责部门，不会开成互相推诿。完整的原因码设计方法 →
15 条起步，三个月后再调
超过 30 条，操作工不会认真选；少于 10 条，分析不出名堂。先上 15 条跑三个月，再按“其他”里的说明做词频统计调整。
停机即弹窗，不允许事后补填
下班前回忆一天的停机，得到的数据没有改善价值。同时要设阈值——短于 2 分钟不弹窗，否则一天点几十次，很快就会随便选。
最贵的停机是没被记录的停机
一台设备停了两小时，如果班组长晚上汇总时才发现，这两小时已经无法挽回；如果停机 3 分钟就推送到设备员手机上，性质完全不同。
这套做法能给到什么
- 停机原因帕累托与趋势
- MTTR 拆解：发现/响应/修复/验证
- 按责任部门归集
- 异常实时推送
- 改善措施跟踪闭环
系统怎么判定“停机”：状态、阈值与防抖
停机分析的第一步不是原因码，是先让机器对“什么叫停”给出稳定的判断。判断不稳，后面每一张帕累托图都会被现场质疑。
| 状态 | 典型判定依据 | 容易判错的地方 |
|---|---|---|
| 运行 | 运行信号为真，且在约定时间内有新的产量计数 | 只看“通电”或绿灯：设备空转也被算成运行 |
| 短停机 | 计数中断超过若干个节拍，但未达到弹窗阈值 | 阈值取固定秒数，换了慢节拍产品后正常生产被误判为停 |
| 停机 | 中断超过弹窗阈值，要求选择原因 | 信号抖动把一次停机切成十几段，操作工被连续弹窗 |
| 计划停机 | 班次日历、无排产、计划保养 | 日历没人维护，午休每天都被记成停机 |
两条实用的设置原则：短停机的判定用“节拍的倍数”而不是固定秒数，这样换产品不用重新调；状态切换加防抖，信号持续若干秒才认定为变化，避免继电器抖动或物料间隔造成的假停机。具体取值在数据校准阶段用秒表对着现场调，不要照抄别的产线。
停机帕累托图怎么看：一周数据的示例
示例（假设数据）：某线一周停机合计 600 分钟。换型 210 分钟（35%）、缺料 150 分钟（25%）、机械故障 90 分钟（15%）、待检 60 分钟（10%）、其他 90 分钟（15%）。前两项合计 360 分钟，占 60%，而且都不归设备部。如果这周的改善会只叫了设备部来，最大的两块损失就没有人认领。
看帕累托图时分开看两个排序：按总时长排，找的是最值得立项的损失；按次数排，找的是最烦人、最打断节奏的问题。一个原因时长不高但次数极多，通常是小停机，应该交给工艺或 IE 去查送料、夹具、传感器位置，而不是交给维修。
示例里“其他”占到 15%，已经到了该拆的时候：把说明文字拉出来读一遍，重复出现的内容提成正式原因码。模板可以直接用 《停机原因码设计模板》。
MTTR 怎么拆成四段，每一段的时间戳从哪来
维修慢，多数时候不慢在修。把一次故障停机拆成四段，每一段的起止都要有系统时间戳，否则只能靠回忆吵架。
| 阶段 | 起点 → 终点 | 时间戳来源 | 这一段长，说明什么 |
|---|---|---|---|
| 发现 | 设备停下 → 有人选了原因或发起呼叫 | 设备状态信号；终端操作记录 | 设备没人盯，或终端离工位太远 |
| 响应 | 呼叫发出 → 维修工到场签到 | 推送记录；现场扫码或终端签到 | 维修人手、排班或呼叫渠道有问题 |
| 修复 | 到场 → 设备恢复运行 | 签到记录；设备状态信号 | 备件、图纸、技能的问题 |
| 验证 | 恢复运行 → 首件合格、正常放行 | 设备计数；检验记录 | 首检排队，或修复质量不稳反复调 |
示例（假设）：一次故障停机 50 分钟，其中发现 8 分钟、响应 15 分钟、修复 22 分钟、验证 5 分钟。真正在修的时间不到一半，前两段合计 23 分钟，靠异常推送和明确的响应规则就能压缩，不需要买任何备件。MTTR 只报一个总数，这个结构就看不见。
停机改善周会怎么开：固定议程与角色分工
数据采上来之后，能不能变成改善，取决于每周这一个小时。建议的固定流程：
- 会前一天，系统导出上周 TOP 3 停机原因（时长与次数各一份），发给对应责任部门，要求带着初步原因来。
- 先过上周行动项：完成的看数据有没有变化，没完成的当场重定期限，不讨论借口。
- 逐条过本周 TOP 3：只问“这条归谁、下一步做什么、哪天完成”，技术细节会后解决。
- 每条行动项写明责任人、期限、预期减少的停机分钟数，录入系统或一张共享表。
- 四周后回看该原因码的时长趋势，没有下降就重新分析，不要默默关闭。
| 角色 | 会上负责什么 |
|---|---|
| 生产经理 | 主持，裁决归属有争议的停机 |
| 设备主管 | 设备类停机、MTTR 四段里的响应与修复 |
| 计划 / 仓储 | 缺料、无排产、换型排序 |
| 质量 | 待检、质量异常停线 |
| 工艺 / IE | 小停机、换型时间（SMED） |
| 班组长代表 | 确认数据与现场一致，反馈原因码不好选的地方 |
想让管理层持续支持这个会，把停机分钟数换算成钱最管用，可以用 停机损失与投资回报测算 做一版贵厂自己的数。
停机分析做不下去的常见原因，以及验收时该查什么
- 原因填了，没人看。操作工选了三个月原因，没见到任何一条被解决，之后就随手选。第一个月必须挑一两条现场最恨的问题快速解决并公开反馈。
- 用停机数据追责个人。一旦谁的班停机多谁挨批，“设备故障”会迅速变成“外部原因”。数据先用来找问题，不用来找人。
- 现象和原因混着列。“设备不动了”是现象，“传感器脏污”才是原因。一级按责任归属，二级写原因，现象不进码表。
- 推送太多。每次短停机都推到主管手机上，两周后所有人都关了通知。推送按持续时长分级，只把超时未处理的往上升级。
验收建议写成可核对的条目：抽查若干次现场停机，系统记录的起止时间与人工秒表记录相符；未选原因的停机时长占比、“其他”占比低于约定值；异常推送从停机到送达手机的延迟在约定秒数内；每周 TOP 3 报表可以一键导出且与明细对得上。阈值由双方在合同里商定。
停机数据与 MES、EAM 的边界
停机的起止时间和时长，以设备侧采集为准，不要在 MES 报工里再让人填一遍，两份数一定对不上。停机原因由操作工在终端上选一次，设备类停机自动在 EAM 或维修系统里生成工单，维修工在工单里补故障部位和处理措施；反过来，工单里的到场时间回写为“响应”段的终点，恢复运行的时间仍以设备信号为准。换型、无排产这类计划类停机，则应由排产数据自动标注，能不让人选的就不让人选。
常见问题
要不要先换设备再谈数字化？
不需要。判断该不该投的标准不是设备年份，而是这台设备是不是瓶颈工序。非瓶颈设备的效率提升不产生任何产能。
我们已经有 MES / ERP，还需要这一层吗？
看那套系统里的设备数据从哪来。如果是人工报工填的，小停机与降速这两类损失就系统性缺失。补一层设备侧采集通常比换系统划算，前提是现有系统有开放接口接收外部数据。
多久能看到第一张可用的报表？
硬件装好之后以天计；但让班组长每天真的用起来，现实周期是两到三个月。这两个里程碑建议在合同里分开写。
小停机要不要让操作工选原因？
停机原因选错了能不能事后改？
一次停机有两个原因，该怎么记？
最近更新：2026-09-21 · 出版：工厂数字化编辑部（TEEPTRAK）
微信：Teeptrak-SZ