停机追踪软件:撬动 OEE 的 8 个停机原因码
停机追踪软件从每月 200 欧元到每月 20,000 欧元不等。从价格上你看不出这样的事:周一早上产线停下来,班组长只有 30 秒在平板上输入,下一个零件就要走到传送带上了,这时候软件到底有多大用处。
真正重要的是:软件能不能帮一线操作员选对停机原因。这就是关键。原因码太模糊,月底 OEE 报告里只会写着 "产线停了 14 个小时",没人知道为什么。原因码太细,操作员就放弃了,80% 的时候按 "其它"。最后你花了钱,得到一个什么都没记下的系统。
这份指南讲实战。在中小规模工厂里真正撬动 OEE 的 8 个停机原因码、可以忽略的 30 多个码、iPhone 信号源在班次中长什么样、以及怎么挑选停机追踪软件而不被演示带偏。
为什么大多数停机追踪都偏了方向
审计新客户的停机数据时,同样三种模式会反复出现。
第一是 "其它" 项目膨胀。有一家工厂用着 24 个原因码,频次前三是 "非计划停机"、"轻微问题"、"其它",合起来占记录停机的 62%。这种数据没法做根因分析。你知道产线停了,但完全不知道要修什么。
第二是重复记账。操作员在 MES 里记一次停机,在维护系统里又记一次,为了交班还在纸质日志上记第三次。数字永远对不上。厂长就在生产会上挑符合自己想要论点的那个信息源。
第三是输入延迟。产线 9:12 停的,操作员 11:47 才回到平板上记。这时记的是 "大约 20 分钟",不是真实的 8 分 14 秒。实时监控就变成了事后追忆。
解决办法不是加更多原因码,而是减少原因码,并且在产线停下的那一刻,把足够让下一个责任人能行动的上下文一起记下来。
重要的 8 个原因码(以及可以忽略的 30 个)
在过去 18 个月里,我们和大约 40 家工厂合作,同样这 8 个原因码占了总停机时长的 85% 到 92%。供应商想塞进默认模板里的其余 30 多个码,只占剩下那一小块。追踪这 8 个,其余的让自由填写或者归到 "其它" 就够了。
真正撬动 OEE 的 8 个码如下:
- 物料缺货。 入料端没有零件。要么上游工序比我们这条产线慢,要么套件没有按时备好。
- 物料卡住或上游来料质量不良。 入料端有零件,但是错的零件、损坏的零件、或者卡住了。和缺货是不同的原因和处理。
- 换刀或换配方。 SKU 之间的计划切换。单独追踪,免得把非计划停机弄脏。
- 机器故障。 机器的物理部件坏了。轴承、皮带、气路这类,需要技术员上手的东西。
- 电气或控制系统故障。 机器部件没问题,但是 PLC、传感器、驱动器报错了。排查路径不一样。
- 操作员缺岗或休息。 产线能跑但工位上没人。交班之间的空档或非计划休息都算。
- 质量挂起。 最近几个零件被检验判为不合格,产线停下来等人决定怎么处理。
- 上游或下游阻塞。 我们这条线没问题,但是包装慢了导致传送带堆满,或者仓库收不下额外的托盘。
就这些。这 8 个码能抓住绝大部分撬动 OEE 数字的因素。其它的要么是这些类别下的子项,要么是一个月一次自由填写、在 OEE 复盘里翻一翻就够的末端事件。
之所以这套行得通,是因为这 8 个码每一个都对应不同的行动。物料缺货要找计划员,机器故障要找维护,质量挂起要找质量。如果原因码不能告诉操作员 "该联系谁",那就是错的原因码。
iPhone 信号源长什么样
如果你读过OEE 计算指南,就知道停机数据直接挂到可用率,而可用率是 OEE 三大支柱之一。数据只有在产线停下来那一刻被记下来,才有意义。
传统做法是接到 PLC 的平板。PLC 触发停机事件后弹窗,提示操作员选原因码。能用,但硬件加集成每条产线 4,000 到 8,000 欧元,而且会绑定到你最早选的那家 PLC 供应商。
iPhone 信号源彻底跳过 PLC 集成。在每个工位放一台翻新 iPhone,跑一个 App。摄像头看着产线,零件流停下来超过设定阈值(通常按节拍 8 到 15 秒),App 就感知到,操作员在屏幕上从 8 个原因码里选一个。全程不到 5 秒。
五年前做不到、现在能做到的原因有三个。一是 iPhone 摄像头在没有专用传感器的情况下,也能在工厂照明下可靠识别节拍停顿。二是端上处理,数据不出厂、不绕云、没有往返延迟。三是操作员对这个界面已经熟悉。除了 "点一下原因" 之外,没有培训成本。
用这套方法让一条产线跑起来,硬件每个工位低于 1,000 欧元。一台翻新 iPhone、一个支架、一盏环灯、一个用来传数据的以太网转接头。3 条产线的停机信号源,半个下午就能拉起来。
从记录到行动:班次级停机工作流
记录数据只是一半工作。另一半是让这些数据在班次结束前就触发动作。
在 OEE 改进真正有进展的工厂里,稳定有效的工作流是这样的。最近 1 小时记下的所有原因码都上到共享班次仪表盘。班组长在 15 分钟的现场巡线时一眼扫过去。两个小时里物料缺货记了 3 次,午餐前一条 Slack 消息就发给计划员了,而不是等到周四下次计划会。一台机器上集中出现机器故障,那就立刻呼维护,不等下一个排好的 PM 时段。
仪表盘不需要花哨。8 个原因码、当前班次的次数和分钟合计、对比上周的趋势 sparkline,一页放下就够。重要的是班组长真的在看,而看本身就在引发对话。
每个班次结束时,班组长在交班里写两句话。最大的停机源是什么、对它做了什么。这就是周五生产会上真正会用到的数据。墙上的 OEE 数字是滞后指标。两句话交班是先行指标。
这个工作流的摄像头版本可以参考摄像头生产监控这篇,把视觉管线讲得更细。配合这份数据的交班模板可以参考工艺工程师交班那篇。
如何挑选停机追踪软件
评估停机追踪软件时,大多数演示会用仪表盘、AI 助手、预测性维护模块来吸引你。演示可以忽略。只问五个问题就够。
第一,从产线停下来到停机被记下来,要多少秒?如果每个事件占用操作员超过 10 秒,一个月内数据就会充满延迟和遗漏。
第二,默认配多少个原因码,能不能缩到 8 个?如果供应商不肯放弃 40 个码的分类体系,那他没理解现场的真实机器停机追踪。
第三,系统在没有 PLC 连接的情况下能不能跑?如果记下停机的唯一路径是控制系统集成,意味着你还没看到数据,就得先买一个 3 个月的导入项目。基于摄像头或基于按钮的记录应该是基础功能,不是升级选项。
第四,原始数据长什么样?让供应商把一个现有客户一周的匿名化停机事件用 CSV 导给你。如果 5 分钟内做不到,那数据就被锁在仪表盘里了,以后你想自己分析时会很难取出来。
第五,头一年每条产线的总拥有成本是多少,硬件、集成、培训、订阅都算进去?很多团队预算里只列许可证,其它就忘了。每月 200 欧元的订阅加上 12,000 欧元集成费,那就不是一年 2,400 欧元的决定。
好的停机追踪软件,是班组长不用催就会用的,是维护团队会信任的数据,是 CFO 在第二年不用做减值的那种软件。
常见问题
停机追踪和 OEE 软件有什么区别? OEE 软件用可用率、性能、质量来算出整体 OEE 值。停机追踪软件通过记录产线停下的原因,专门强化可用率这一支柱。许多团队两边都需要,但你可以单独运行停机追踪,以后再补上性能和质量的部分。完整计算请参考OEE 计算指南。
原因码要拆到多细? 8 到 10 个是最优区间。少于 6 个就分不开计划问题和机器问题。超过 12 个,两周内操作员就开始按 "其它"。每次会议上有人提议就加一个码,这种冲动要忍住。
没有 PLC 也能做停机追踪吗? 能。装好的 iPhone 用摄像头记录,是没有现代 PLC 的工厂、或者老线后期补装的最清爽选择。在工位放物理按钮、产线停时让操作员按一下的按钮记录也可以,但每个事件多占操作员约 2 秒。
停机追踪软件多快能跑起来? 用 iPhone 信号源,一条产线半个下午就能跑起来,8 到 12 条产线规模的工厂全厂一周内能上线。PLC 集成系统通常每条线要 6 到 12 周,含测试。
停机追踪软件会替代 CMMS 吗? 不会。CMMS 管工单、备件库存、PM 排程。停机追踪管实时事件记录和原因码标注。两边应该打通,产线上记下的机器故障应该在 CMMS 里自动生成工单草稿。但解决的问题不同。
经常会有人问的一个框架问题是,停机追踪软件如何接到更宽的整体设备效率(OEE)报告。停机信号源就是进入 OEE 的可用率数据。如果非计划停机和计划停机两边都没有干净的信息源,周报里的可用率数字就是猜的,团队会去争哪条产线最差,而不是去修。有了干净的信号源,同样的数字就成为所有根因分析的起点,周复盘从问责转向学习。带原因码的事件让班组长可以从最大的损失源开始优先处理,按季度把可用率拉起来。
稳定下来的报告节奏是一份每周停机报告,接到原因码的帕累托图上,把平均修复时间(MTTR)和 OEE 分数与每条产线的产量损失放在同一时间轴上。配置的原因码应分别处理设备故障、节拍下降、质量问题、计划维护,这样周复盘能看清哪个类别增长最快。用这种数据驱动的持续改进项目,会持续聚焦在最大的损失源上,而不是声音最大的问题上。靠干净信号源把周复盘肌肉练起来的团队,一个季度内就能感受到差距。
本周就让停机追踪跑起来
如果你想这周五就让一条产线的停机信号源跑起来,最快路径是一台翻新 iPhone、一个支架、一个免费 Enao 账户。挑出适合你工厂的 8 个原因码,把摄像头对准产线,一个小时内数据就开始流。没有 PLC 集成,没有 12 周项目,没有五位数账单。
