OEE 为什么总算不准：公式没问题，数据采集才是问题

很多工厂一谈 OEE，第一反应就是公式：可动率乘性能乘质量，逻辑看起来很清楚，表格也不复杂。可真到了现场，大家最常遇到的不是“不会算”，而是同一台设备、同一班、同一天，算出来的 OEE 谁都不完全信。

一、公式只是壳，底层数据才是根

OEE 要成立，至少要有三类基础数据：设备到底什么时候在跑、什么时候在停；运行时到底按什么节拍产出；产出里哪些是良品、哪些是异常。

只要这些底层数据口径不统一，后面的 OEE 不管怎么算，都只是一个看起来很完整的结果。

很多工厂 OEE 失真，不是因为产量没采，而是停机没采清。短暂停机算不算、换模算不算、待料算不算、人工干预算不算，不同班组口径一变，OEE 就跟着漂。

同样，计划时间如果没有定清楚——哪些时间属于排产、哪些属于非计划、哪些属于保养——最后 OEE 看起来是在比较设备，实际上是在比较各班组怎么填。

OEE 真正有价值，不是给领导看一个百分比，而是让团队知道低在哪里、为什么低、该谁处理。

如果系统里只有一个“停机了”的结果，没有原因分类、责任归属和损失时间，后面就算 OEE 真的偏低，团队也只能围着数字吵，而不知道该改哪一步。

更稳的 OEE 不是靠一个设备采集盒就能搞定。设备状态、人工补充、报工事件、良品判定，这几条链必须能对上。

因为现场真正复杂的地方就在于：设备知道它停了，但不知道为什么停；人工知道为什么停，但不一定及时录；MES 知道工单在推进，但不一定知道停机和质量影响。

OEE 想算准，就必须让这几条链在关键节点接上。

最稳的起步方式，是先把采集点设计清楚：停机事件谁触发、原因谁确认、产量谁回写、良品谁判定、计划时间谁维护。

这些点一旦清楚，公式自然能算；这些点不清，公式写得再漂亮，最后也只是把不准的数据乘了一遍。

OEE 为什么总算不准，核心不是公式，而是数据采集。先把停机、节拍、产出、良品和计划时间这些底层采集点设计清楚，OEE 才会从“墙上的数字”变成真正能指导改善的管理工具。

如果你也在梳理 OEE、停机采集和 MES 事件边界，欢迎交流。

如果你准备继续往下推进，建议把当前流程、字段口径、异常场景、角色分工或系统截图一起带上，这样更容易快速判断问题到底卡在对象、状态、规则还是接口。

如果项目还在早期，也可以先从目标边界、关键节点、证据字段和实施顺序四个维度做最小梳理，先把口径讲清，再谈系统联动和自动化。

更稳的推进方式通常不是一上来全量改造，而是先挑最影响交付、结算、追溯或监管的关键链路做小闭环，拿到第一轮稳定证据后再扩范围。

先把问题讲清、把边界定清，再推进系统动作，后面的投入和协同成本会低很多。

企微二维码

企微联系：系统规划 / 内容合作 / 业务沟通