停机这件事，为什么总是说不清
车间主任最常被问的一句话是"昨天那条线为什么停了两个小时"。回答往往是三句话拼起来的："上午跳闸了""下午等料""后面又调了下模具"。至于每个原因各占多久、上周是不是同一个原因反复出现、上个月提的改善到底有没有见效——大多停留在班组的记忆和交接本上。
停机记录做不起来，通常不是员工不愿意填，而是四件事没解决：
- 口径不统一。同样是"设备故障"，张三记成"机械故障"，李四记成"卡机"，王五记成"等维修"。口径一散，月度汇总就只能看总数，看不出该修哪台设备。
- 没有起止时间。只记"停了 2 小时"是一个结果，不是一条事件。没有开始与结束时间，就无法判断停机发生在计划时段内还是计划外，也算不准稼动率。
- 填报在纸上，汇总在 Excel。纸单当天不录，隔天补录的信息可信度递减；到了月底再手工抄进表格，错误和缺漏只能靠猜。
- 改善项没有下文。会开了、责任人定了、方案写了，但两周后没人回头验证"这个月的同类停机是不是少了"。
这套模块解决的就是这条链：现场把事件记准 → 系统按时长与原因汇总 → 高频原因转成改善项 → 改善项带验证期回看效果。它是生产工单与排程的下游搭档，如果你还没把工单和报工数字化，建议先看 /solutions/mes-production-workorder.html，本篇假定已经有了"哪条线、哪台设备、哪个班次"这套基础口径。
底表怎么建：四张表管住一条事件链
用 AI 构建器搭这套模块，不需要先画一堆字段。第一句话把业务讲清楚，剩下的表结构由构建器生成，你再按下面的判断去调整。四张表的骨架是：
1. 产线与设备台账（基础口径）
停机事件必须挂到确定的对象上，否则统计不出口径一致的排名。这里建议直接复用已有的设备台账；如果还没有，先建一张轻台账：设备编号、设备名称、所属产线、工序位置、状态（在用/停用）。
关键设计决定：产线与设备分两级，但停机事件挂设备、汇总看产线。因为一条线上往往有多台设备，班长报的是"3号线停了"，而维修记录针对的是具体那台贴标机。两级都留，才不会出现"设备维度统计不到、产线维度又太粗"的两难。
2. 停机事件表（主表）
这是整个模块的核心，字段不多但每条都要有用：
- 事件编号（系统生成）
- 产线、设备（用引用方式选已有台账记录，不要手打设备名）
- 停机开始时间、停机结束时间
- 停机时长（按起止时间算出，不让人手填，避免"填的数和算的数不一致"）
- 停机类型：计划内 / 计划外
- 停机原因（下拉，走统一口径）
- 责任归属：设备、物料、人员、工艺、外部（如停电、来料延迟）
- 影响数量：停线区间内的产出损失或未完成工单
- 现场照片、备注
- 登记人、登记时间
3. 停机原因字典（口径表）
原因必须做成下拉选项而不是自由填写。平台自带的数据字典能力可以把枚举值集中管理，AI 建的模块可以直接引用字典值，这样"设备故障/机械故障/卡机"这类同义表述就被收敛成同一项，详见 /docs/data-dictionary.html。
建议两级原因：一级粗分（设备、物料、人员、工艺、外部），二级细分（如设备下面再分机械、电气、气路、程序）。一级用于管理报表，二级用于改善立项——只做一级太粗找不到根因，一上来就做三层又没人愿意选。
4. 改善项表（闭环）
从停机事件派生出来的一张表，字段包括：改善主题、对应的高频停机原因、问题描述、责任部门与责任人、计划完成时间、状态（待分析/方案中/实施中/已验证/关闭）、验证期起止、验证结论。
表间关系是"停机事件 → 改善项"的多对一：多条同类停机可以并入同一个改善项，一个改善项也能在验证期里回看它覆盖的所有停机事件。这条关系决定了后面"改善有没有效果"能不能被自动算出来。
页面怎么用：四类人，四个视角
同一套数据，不同角色关心的事完全不同。构建器生成模块时可以按角色做不同的页面视图，权限体系控制谁能看哪些。
班组长：一条登记入口，越短越好
班长关心的是"别让我填表"。登记页只保留必要字段，起止时间用"现在开始/现在结束"一类的一键取值，原因走下拉，照片可选。历史列表默认只看本班组、本产线，避免误操作别人的记录。
一个实用设计：允许先开一条"进行中"的事件，结束时再补原因。真实现场是先停机、后追原因，如果要求一次填完，班长会等到修好才记，时长就失真了。
车间主任：日视图与原因排行
主任的页面是三个视图的拼装：
- 当日停机清单：按产线列出每条事件、时长、原因、影响工单，未结束的用进行中状态标出来。
- 停机时长趋势：按日或按周汇总，能看出总时长是在收敛还是反弹。
- 原因排行：按一级原因与二级原因分别排前几名，排名第一的那项就是本月改善候选。
这些视图用图表呈现比明细表更有说服力，趋势看走向、排行看占比、堆叠看构成，三种图形各自承担一件事，不要用一张图讲三个问题。
设备/维修主管：停机等待时间与维修响应
设备主管真正要看的是"我到场之前已经等了多久"。所以在停机事件里区分报修时间（班长上报的时刻）与开始维修时间，两者之差就是响应等待。这个差值往往比维修本身更值得优化。
维修主管页面还可挂上设备维保工单的联动：同一台设备本月已有几次报修、上次更换的备件是什么。维修工单本身的搭建方法见 /solutions/equipment-maintenance-workorder.html，两套模块用设备编号对齐即可。
厂长/生产经理：稼动率一页看全
管理层页面只放结论，不下钻到明细。核心指标是稼动率，定义要在上线前说死，常见口径是：
- 稼动率 = 实际运行时间 ÷ 计划可用时间
- 计划可用时间 = 排班工时 − 计划内停机（如计划保养、换型）
- 实际运行时间 = 计划可用时间 − 计划外停机时长
这里最容易被误用的是"换型算不算停机"。模块里把停机类型做成"计划内/计划外"的二分，口径就固定下来了：算稼动率时只用计划外，但换型时长单列一栏照样能看到，两边都不丢。
自动化怎么配：少让人做重复动作
平台的工作流、数据流规则与定时任务三件套，正好覆盖这条链上最容易被漏掉的动作。它们的用法分别在 /docs/workflows-scheduler.html 里有详细说明，这里只讲这套模块里的具体用法。
- 时长自动算。停机结束时间一填，时长按起止时间差自动生成，不用人再算一遍，也从根上杜绝"填的数和明细对不上"。这一步用数据流规则做字段变换即可。
- 超时未登记提醒。定时任务每天固定时刻扫一遍"开始时间超过 N 小时仍未填结束时间或原因"的事件，按责任人发站内消息或通知到手机。这类提醒比事后追查有效得多。
- 高频原因自动生成改善候选。定时任务按月（或按周）统计同一二级原因的停机次数与累计时长，超过阈值时把这条原因写进改善项表的待分析状态，责任人默认取设备主管。人只需要判断要不要做，不需要自己去翻报表找线索。
- 改善项审批与验证。改善项从"方案中"到"实施中"再到"已验证"，走一条简单的状态流转；如果涉及费用或跨部门投入，接一段审批流（工作流能力），把批准动作留在系统里。
- 验证期回看。改善项进入"已验证"状态时，系统按验证期区间反查该原因下的停机事件数与时长的变化，作为验证结论的依据填回。没有这一步，改善项就只是一张有始无终的表。
- 敏感操作留痕。停机记录被修改、删除，改善项被关闭，都要落审计日志（谁、什么时间、改了什么）。停机数据一旦用来考核，就一定有人去改，留痕是必要的。
移动端：报停机的人不在电脑前
停机登记发生在设备旁边，不在办公桌前。PC 端构建好的模块页面可以在手机上同步生成对应页面，工作台里能直接进，具体用法见 /docs/mobile-guide.html。
这套模块在手机上有三个高频用法：
- 一键开停机。班长在产线现场点开模块，选设备、点"开始停机"，时间自动取当前时刻；修好后点"结束"，填原因、补照片。全程十几秒，不需要回办公室补单。
- 拍照留证。设备故障、料件缺陷、模具损坏，用手机直接拍，图片随事件一起归档到附件里，后面复盘时不用再问"当时长什么样"。
- 待办与提醒。超时未填原因的提醒、改善项的分派与验证提醒，都推到手机通知里；主任早上在车间走一圈就能把待处理的几条点掉。
移动端不建议放全场稼动率大屏——手机上塞十几张图表，看一眼就要滑动五次。管理层的分析页面留在 PC，手机只承担"记录、审批、看单条"这三件事。
上线前查这几条
模块搭完之后先别急着全员推开，照着下面几条过一遍。构建器自带的预检与发布流程可以帮你把菜单挂载、权限和移动端同步这些机械动作跑通（见 /docs/module-test-publish.html），但业务口径只能由你确认：
- 原因字典是否收敛。把过去一个月的纸单或 Excel 停机记录拿出来，按新字典试归一遍，看看有多少条归不进去。归不进去的多半是二级原因还缺项，先补齐再上线。
- 稼动率口径是否书面确认。计划可用时间怎么算、换型算不算、计划保养算不算、节假日班次怎么处，这四句要写在一张纸上让生产经理签字。上线后再改口径，历史数据就不可比了。
- 时间精度是否够。停机事件按分钟还是按半小时记？按分钟准但填报负担重，按半小时省事但小停机全部丢失。折中做法：小停机（如十分钟以内）允许合并登记，但要标"已合并"，让统计时知道这部分是估算。
- 谁有权修改历史记录。建议只给车间主任与模块管理员修改权限，且全部留审计日志。考核类数据一定要有这道闸。
- 设备台账是否已对齐。停机事件引用的设备必须和维保工单、设备台账用的是同一个编号体系，三处各叫一个名字，后面做设备维保与点检的交叉分析就断了。
- 小范围试跑两周。选一条线跑两周，和纸单并行核对，两边差得最多的那几项就是表单设计或口径的问题所在。
之后可以怎么延伸
这条链搭好之后，接续的方向都很自然：
- 与排程联动。停机时长累计到一定程度，触发对当日排程的重排提示，让计划员知道哪批单要往后挪（排程侧可参考 /solutions/production-scheduling-board.html）。
- 与点检、维保打通。同一台设备故障频发时，反查它的点检记录与维修历史，判断是点检漏项还是备件质量（点检侧见 /solutions/mes-inspection-tour.html）。
- 与设备台账合并看设备健康度。把停机时长、维修次数、备件消耗放在一张设备视图上，采购与更新改造就有依据（台账侧见 /solutions/manufacturing-equipment-ledger.html）。
- 按班组出报表。同样的稼动率口径，按班次、班组切分，看差异是排班问题还是技能问题。
适用边界：什么情况下这套不够用
诚实地说几句不做什么，比罗列功能更有用：
- 不做设备数据自动采集。这套模块的停机数据靠人登记。设备联机、PLC 信号采集、传感器自动判别停机属于硬件与集成范畴，不在本模块的能力里。
- 不做排程优化计算。它可以为排程提供"这条线今天损失了多少可用时间"的输入，但不负责算出最优排产方案。
- 不替代设备 OEE 全套体系。这里讲的是停机与稼动这条线；速度损失、质量损失（良率折算）如果要一起算，需要在模块里额外补字段与公式，属于第二阶段。
- 不适合无人值守的连续流程行业做秒级停机判定。化工、冶金这类流程行业停机与降负荷的边界模糊，人工登记的口径很难精确，通常需要结合过程控制系统另做设计。
一句话总结：这套模块把"停机从口头汇报变成可查、可算、可验证的记录"——它不解决设备本身的问题，但能让每一次改善都有据可依。