去年三季度，我在一家年产值40亿的汽车零部件工厂做OEE分析项目。工厂的BI大屏上，设备综合效率显示82%，看起来不错。但当我想深挖停机原因时，系统里73%的记录写的都是“设备故障”四个字。同一个车间，三台完全不同的设备，停机原因如出一辙。不是设备真的一直在坏，而是操作工在填报工单时，系统给他的第一个下拉选项就是“设备故障”，点一下就行，不用思考。
那82%的OEE是假的。不是因为数据采集不准，而是因为停机原因的分类标准从一开始就没建对，导致所有后续分析都建立在不可信的标签上。这个项目三个月后把OEE从“纸面上的82%”做到了真正可追溯的74%，而改善的第一刀，就砍在停机原因分类标准上。
这篇文章不是OEE概念的百科全书，你不需要我再讲一遍可用率、表现性、质量指数怎么算。我要讲的是那个让无数BI项目翻车的细节：停机原因到底该怎么分类，才能在BI平台上产生可行动的洞察，而不是一堆无意义的饼图。
先把这个判断说清楚。大多数企业做OEE分析时，把停机原因分类当成一个“数据字典”任务，找几个工程师坐下来，列一堆可能的原因，塞进BI系统，就以为完事了。这是最大的误解。
停机原因分类的本质，是在管理层、设备工程师、一线操作工之间建立一套共同的“问题描述语言”。这套语言必须满足三个条件：第一，每个原因标签都指向一个具体的、可执行的管理动作；第二，不同角色的人看到同一个标签，理解不会产生歧义；第三，标签体系能随着管理水平提升而逐步细化，而不是一开始就追求大而全。
我见过一家电子代工厂，他们的停机原因清单有200多项。听起来很精细，但系统上线半年后，排名前十的原因都是“其他”。为什么？因为操作工在200个选项里找不到他要的那个，就直接点了最后一个。精细不等于有效，分类的颗粒度必须匹配你当前的管理能力和数据采集手段。
去年在华南一家注塑工厂做诊断。他们的BI系统里，A注塑机、B注塑机、C注塑机三个月内的非计划停机记录分别是47次、52次、38次。但当我对比停机原因时发现，三台设备的“机械故障”占比分别是68%、71%、65%。
这个数据让车间主任很困惑：“感觉三台机器坏得差不多，但A机明明是新买的，C机已经用了八年。”问题出在填报界面上。操作工停机后需要在HMI上选择一个原因，第一页显示的前三个选项是：设备故障、模具问题、材料异常。大多数情况下，机器停了，操作工不确定具体原因，就选了第一个。这个“设备故障”就像一个黑洞，把大量本该细分的信号吸了进去。
我们后来做了一件事：把填报界面的默认排序改为按设备类型动态调整。对于注塑机，最常出现的前三个停机原因其实是：换模、清料、模温异常。机械故障被放到了第二页。三个月后再看数据，三台设备的停机原因分布出现了明显差异，A机（新机）主要是换模和清料，C机（老机）则在液压系统异常上有一个明显的峰。
这个案例告诉我一个道理：不是员工不认真填，而是你的系统设计默认他们在认真填。默认选项、排序、分组方式，这些UI细节决定了数据质量的下限。
一家食品包装厂的BI大屏上，白班OEE稳定在78%左右，夜班却只有63%。厂长第一反应是“夜班工人不熟练”。但当我们把停机原因按班次拆开看时，发现了一个有意思的模式：夜班的“短暂停顿”类停机比白班多了近一倍，而这些停顿大部分集中在前半夜的换产阶段。
进一步调研发现，夜班换产品规格时，需要调整封口机的温度参数。白班有一个经验丰富的调机师傅，他能在5分钟内搞定；夜班靠操作指南，来回调试平均要20分钟。但无论是白班还是夜班，系统里这条记录写的都是“工艺调整”。同样的停机原因标签，背后的能力差距被完全掩盖了。
这个案例说明：如果停机原因只记录“发生了什么”，不记录“发生在什么场景下”，BI分析就只能停在表面。在这个项目里，我们后来增加了一个辅助维度，“是否涉及换产”，让团队能够把换产相关的工艺调整单独拎出来分析，才锁定了夜班换产效率低这个真因。
TPM里的六大损失，设备故障、换模和调整、空转和短暂停机、速度降低、工艺缺陷、启动损失，是一套很好的理论框架。但我见过太多企业在BI系统里原封不动套用这六个类别，结果发现根本落不下去。
问题在于，六大损失是按“损失类型”分类的，而一线操作工是按“发生了什么现象”来认知停机的。当你让他选“这是设备故障还是短暂停机”，他需要做一个判断，如果滚轮堵了但一清就好，算故障还是短暂停机？这个判断本身就要经验，而且不同人判断标准不同。
正确的做法是：用六大损失做二级分类（给工程师和管理层做分析用），用现象描述做一级分类（给操作工填报用）。比如一级让操作工选“堵料”，后台自动映射到“短暂停机”这个二级类别。我将在第五节详细拆解这个分层模型。
2019年我参与过一个整车厂的总装车间OEE项目。项目启动时，设备部门花了两个月时间，拉出一份286项的停机原因清单，按设备部位、故障类型、责任归属三个维度交叉组合，看起来非常科学。上线第一个月，286项里实际用到的只有40多项，超过一半的记录集中在“其他”和“不明原因”上。
这个团队犯了两个错误。第一，他们把“原因库”当成了“故障字典”来建，试图覆盖所有理论上可能出现的故障，但忽略了现场填报的可行性。第二，他们没有考虑“可识别性”，很多原因（比如“轴承早期磨损”）在现场是无法直接判断的，需要停机拆解后才能确认，而操作工不可能等你拆完再报工。
我的经验是：停机原因清单的设计起点不是“设备有多少种坏法”，而是“操作工在不停机拆解的情况下能判断到什么程度”。超过这个判断能力的颗粒度，就是虚假精度。
“机械故障”在冲压机和装配机械手上，是完全不同的概念。前者可能指模具卡死、滑块异常，后者可能指夹爪不到位、气缸漏气。但如果你的BI系统里只有一个全局的“机械故障”标签，那么当你看到“机械故障导致停机占比30%”这个数字时，你完全不知道该去哪台设备上找问题。
这不是一个技术问题，是一个设计问题。BI系统应该在数据字典层面支持“设备类型关联的原因集”，不同设备类型加载不同的停机原因选项，而不是用一个万能的通用列表。这是很多BI平台的标准功能（比如九数云、FinBI的分级字典配置），但我在项目中至少见过一半的企业没有启用这个功能，因为他们“觉得先通用做起来，后面再细分”。
结果是，数据攒了半年之后，你发现根本没法分设备做对比分析，因为标签已经被污染了。半年后的清洗成本，比当初设计时多做一个设备关联字典高出十倍不止。
这是最隐蔽也最有害的一个误区。有些企业为了便于考核，直接在停机原因里区分“设备部责任停机”、“生产部责任停机”、“质量部责任停机”。这个设计看似方便，实际上是在鼓励信息隐瞒。
当一个停机原因被标记为“设备部责任”时，设备部的人就有强烈的动机去质疑这个标记的准确性，而不是去解决这个问题本身。你会陷入无休止的“归类争议”，这个到底是设备部没保养好还是生产部操作不当？争论一周，机器还在那儿停着。
正确的做法是：停机原因只描述客观现象或直接原因，责任归属作为独立维度另行维护，且在BI分析层面通过规则引擎自动判断。这样当两个部门有争议时，你可以回到原始数据去看“现象是什么”，而不是围绕一个已经被掺杂了立场的标签来吵架。
OEE的经典计算公式里，计划停机（如计划保养、换模、吃饭休息）通常不计入可用性分母。这在理论上是成立的，但很多企业把这个公式理解成“计划停机不重要，不用分析”，这就完全走偏了。
计划停机的效率改善，恰恰是OEE提升的一个重要来源。比如换模时间从45分钟降到25分钟，你的可用性分母不变，但额外释放了20分钟产能。如果你不在分类体系里追踪换模时间的趋势，你就丢了这张明牌。
所以我的建议是：OEE的正式计算可以按标准公式来，但停机原因分类必须完整覆盖计划类停机和非计划类停机，二者在BI系统里分开统计，分别呈现。计划停机中的“换模耗时”、“保养耗时”要单独拆成可追溯的指标，甚至可以进一步细分，内部换模时间、外部准备时间、调试首件时间。
这一层面向一线操作工和班组长，要求是：不用思考，直接描述看到的现象。设计原则有三条：选项数量控制在15个以内；用词必须是车间日常用语，不要出现技术术语；99%的常见停机情况能在3秒内找到对应选项。
基于我参与过的超过20个OEE项目，我推荐一个通用的操作填报层框架，按停机现象分为5大类15小类：
| 大类 | 小类（操作工看到的） | 典型场景 |
|---|---|---|
| 机器不动了 | 设备直接停机、卡料堵料、安全门触发 | 急停按钮被按下、光电保护被遮挡 |
| 机器在动但不干活 | 换产品规格、空转等待、调试中 | 换线后首件调试、等前道来料 |
| 干活但质量不行 | 连续出废品、首件不合格、尺寸偏移 | 刀具磨损导致超差 |
| 计划内停机 | 计划保养、吃饭休息、班前会 | 午休停机、周保养 |
| 其他 | 不明原因、外力影响 | 断电、压缩空气中断 |
注意，这个表里的“其他”是故意保留的。完全消除“其他”是不可能的，但我们可以通过制度来控制它的使用比例。我一般会和工厂约定一个规则：任一设备在任一周内，“其他”类原因占比超过15%，班组长必须在本周例会上解释原因。这比强行禁止“其他”有效得多。
这一层面向设备工程师、维修技师和工艺工程师。当操作工在第一层选了“卡料堵料”之后，维修人员在处理完成后，需要在系统里补充一个技术性归因：导致卡料的原因是什么？是模具表面粗糙度超标？还是送料机构同步异常？
这个层级的设计难点在于：它需要维修人员额外花时间填报，而维修人员在忙完后通常没有这个意愿。所以第二层的填报设计必须极简，我通常的做法是：在维修工单闭环的环节，强制要求从预设的技术原因列表中至少选择一个，且列表基于第一层的“现象”动态过滤，选了“卡料”之后，只显示与卡料相关的技术原因，不需要维修人员从200个选项里大海捞针。
第三层是给管理层和BI看板用的。前面两层的数据进入BI平台后，经过规则引擎的自动映射和聚合，生成管理层真正关心的分析维度。这个映射关系不需要人手动做，应该在系统配置时提前定义好。
举个例子，第二层的“模具表面粗糙度超标 → 导致卡料”在第三层可能被自动归入“模具维护不及时”这个管理分析类别。这样当厂长在BI大屏上看到“模具维护不及时导致非计划停机占比环比上升12%”时，他直接知道该找谁、该推动什么改善。
三层模型的完整映射关系如下：
| 分析层级 | 使用角色 | 分类逻辑 | 典型条目数 | 示例 |
|---|---|---|---|---|
| 第一层: 操作填报层 | 操作工、班组长 | 按现象分类，“我看到了什么” | 15项以内 | 卡料堵料 |
| 第二层: 技术归因层 | 设备工程师、维修技师 | 按因果关系，“为什么会发生” | 40-80项，动态过滤后展示 | 送料机构同步异常 → 卡料 |
| 第三层: 管理分析层 | 生产经理、厂长 | 按管理动，“我该做什么” | 8-15项 | 模具维护不及时 → 非计划停机 |
2023年我在华东一家瓦楞纸包装企业做OEE系统重构。他们之前用某MES自带的OEE模块，停机原因用的是厂商预设的通用模板，一共32项。问题是这个模板是按金属加工行业设计的，好多原因（比如“冷却液异常”）在这个纸板厂根本不存在，而他们真正头疼的问题（比如“瓦楞辊粘纸”、“纸板跑偏裁切对不齐”）反而不在列表里。
所以操作工习惯了随便选一个完事。系统里OEE显示79%，但厂长说实际感觉连60%都不到，因为“设备老在停，但系统里看不出来停在哪里”。
我们的改造分三步走：
第一步：重做操作填报层。我们在每个机台蹲了三天，记录操作工实际会遇到的所有停机场景，最后整理出14个现象级原因：
这14项全部用操作工日常说话的语言，没有一项需要解释。系统上线第一个月，“其他”的占比只有8%，远低于之前的40%。
第二步：建立技术归因映射。以“瓦楞辊粘纸”为例，我们在后台预置了7个可能的技术原因：胶水配比异常、辊面温度过低、纸张含水率过高、辊面磨损、清洁不彻底、来料克重不稳定、其他技术原因。维修人员处理完问题后，从这7个里选一个。这个动作被强制嵌入维修工单闭环流程，不填不能关闭工单。
第三步：配置管理分析层规则。在九数云BI平台上，我们把50多个技术归因映射到8个管理分析维度：设备基础维护、工艺参数管控、来料质量、操作规范、换产效率、计划管理、外部因素、待定。这些维度直接对应到不同的责任部门和改善行动。
系统稳定运行三个月后，数据发生了质变。OEE从“纸面上的79%”变成了“可追溯的71%”。虽然数字变低了，但厂长说这是他第一次真正相信系统里的数字。更重要的是，BI看板上能清晰地看到三条趋势线：
这个案例最让我触动的一点是：当数据变真了，很多以前“不存在”的问题突然就存在了。但这恰恰是BI的价值，不是为了把数字做好看，而是为了让你看到真实情况，哪怕真实情况不那么好看。
写到这里必须强调一句：没有一套通用的停机原因分类标准可以不经调整就在所有行业落地。我见过的最失败的案例，就是某个集团花了80万请咨询公司做了一套“行业通用标准”，试图在旗下电子、化工、食品三个事业部统一推行。结果三个事业部都不买账，因为每个行业的停机特征差异太大了。
下面是我基于亲自参与过的项目，对不同行业的分类侧重给出的建议。注意，这些不是“标准答案”，而是帮助你判断“该往哪个方向侧重”的参考框架。
核心特征：多品种小批量、换产频繁、单件价值较高、节拍较固定。
停机原因分类应重点关注的维度：
可以弱化的维度：流程中断（离散制造的上下游耦合相对松散，一台机停了对前后的影响有限，不像流程行业那样产生连锁反应）。
核心特征：连续生产、停机成本极高、计划停机和预防性维护是绝对重点。
停机原因分类应重点关注的维度：
可以弱化的维度：单机单部位的精细故障分类（流程设备多为整体性故障，拆到太细意义不大）。
核心特征：高速运转、短暂停机（微停）占比极高、节拍以秒计。
停机原因分类应重点关注的维度：
可以弱化的维度：复杂的机械部位定位分类（高速包装设备的模块化程度高，故障通常以模块为单位判断和更换，不需要拆到单个零件级别）。
理论讲完了，案例也拆了，下面是我在多个项目中反复验证过的执行清单。如果你的团队正在或者准备在BI平台上搭建OEE分析模块，以下六个动作建议按顺序执行。
不要坐在会议室里拍脑袋列停机原因。派一个工程师（或者你自己）到目标机台跟三天班，带上秒表和记事本，记录每一次停机的：发生时间、持续时间、操作工现场说的第一句话、处理动作、最终恢复方式。三天下来，你会拿到一份比任何模板都真实的“停机现象清单”。
我在包装厂跟机的那三天，最大的发现是：操作工口中的“机器跑偏了”，在设备日志里根本不会记录为“停机”，因为设备自己没停，是操作工手动停机调偏的。这种“人主动停、但设备认为自己在正常运行”的场景，在模板化的分类体系里完全没有覆盖。三天跟机，就能发现至少五个这种“隐藏模式”。
操作工从发现停机到完成原因填报，总操作次数不应超过三次点击或触屏。超过这个次数，数据质量就会断崖式下降。如果你的系统需要他在多个页面之间跳转、输入文字、或者从超过20个选项里滑动查找，那这个设计就是失败的。
具体做法：
这是很多人忽略的一个技术细节。以九数云为例，在做数据字典配置时，应该为每个设备类型（或者精确到设备型号）创建独立的停机原因集，而不是用一个全局字典覆盖所有设备。BI平台的后台配置逻辑大致是：
这个配置在前端用户看来毫无感知，但在后端数据分析层面的价值是巨大的。而且这个工作最好在系统上线前一次性配好，后期补配的成本会高很多。
让BI平台自动生成一份每周停机原因分布报告（不是人工手工汇总），并设置阈值告警。我常用的三条自动监控规则：
停机原因库不是一成不变的，设备老化、工艺调整、人员流动都会导致停机模式发生变化。我建议设定一个固定的节奏：每个月由设备主管牵头，拉上两个操作工代表和一个维修技师，花一小时复盘上月的停机原因使用情况。
复盘的重点不是看“哪个设备停了多久”，而是看“分类是否依然有效”：哪些原因从来没人用？哪些原因被用得太泛？有没有新的停机模式没有被现有分类覆盖？这一小时的投入，回报是一整年不用再为数据质量扯皮。
前面在误区四里提过这一点，这里给一个具体做法。在BI平台的ETL或数据加工环节，配置一套归因规则引擎：
这些规则不需要操作工关心，他们在填报时只看到“客观现象”。但管理层在BI看板上看到的，是已经被规则引擎翻译过的、可以直接驱动管理动作的分析维度。填报层和管理层的分离，是OEE分析从“数据收集”走向“数据驱动”的关键一步。
回到标题的问题：制造业BI平台分析设备OEE时，停机原因分类的标准到底怎么定？
我的回答是：没有标准答案，但有标准方法。这个标准方法就是：用分层模型替代单层列表，用现象填报替代责任归类，用设备关联替代全局通用，用持续迭代替代一次定稿。
如果你的团队正准备或正在优化OEE系统的停机原因分类，我建议你从今天就开始做三件事：
说到底，停机原因分类不是给系统看的，是给人看的。当一个操作工在凌晨三点、疲惫不堪、机器突然停掉的时候，他还能用三秒钟在系统里找到一个准确的描述，这个设计才叫成功。而这份成功，最终会反映在BI大屏上那些可追溯、可信赖、能指导行动的趋势线里。
如果你觉得这篇文章对你有帮助，最好的感谢方式就是把它转给你的设备主管和IT负责人，然后约一个会，开始做第一件事。
我刚上任生产主管，发现车间报上来的OEE数据里停机原因全是“设备故障”或“其他”，根本没法分析。我试过让工人填详细点，但大家嫌麻烦就随便填。到底什么样的分类体系才能既准确又不让一线员工反感？
你遇到的不是个例，我辅导过20多家制造业工厂，超过80%的OEE数据在第一周就失真。核心问题在于：分类不是越细越好，而是要有“防呆”机制。我的实战方法是“三明治分类法”： – 第一层：业务语言层（管理层看懂）。只设5个主类：计划性停机、非计划性停机、质量检查、节拍损失、其他。
每个主类明确一个动作导向。例如“计划性停机”对应“换模、保养、培训”，这些是必须发生的，不算浪费。- 第二层：技术归因层（工程师分析用）。每个主类下细分3-5个次类。比如“非计划性停机”下分：机械故障、电气故障、工艺异常、原材料问题。这一层需要和PLC信号、传感器数据打通，不能靠人填。
我曾在某汽配工厂落地后，OEE有效数据率从37%提升到92%，三个月内找到了两个隐性停机根因。
我所在的电子厂SKU多、换线频繁，目前分类只分到“换线”和“故障”，但根本看不出瓶颈。我想细化到零件级别，又怕操作工不填。到底分成几层才是最优解？有没有行业通用建议？
很多顾问会说“三层”，但我的判断是：层数取决于你的纠偏速度。我总结了一个“3-5-3”原则： – 最大层数不超过5层（从企业到具体动作）。因为人脑在5层后容易混淆，且BI仪表板展示效果会崩塌。- 最小层数至少3层（宏观-中观-微观）。低于3层等于没分。具体案例：去年帮一家包装印刷企业设计分类。
他们设备复杂，我来回改了4版。
最终采用：
| 层级 | 示例分类 | 数据来源 | 更新频率 |
|---|---|---|---|
| L1 (车间) | 生产部 | MES自动 | 实时 |
| L2 (停机大类) | 非计划停机 | PLC信号 | 实时 |
| L3 (根因组) | 电气故障 | 人工选择+传感器 | 每次停机 |
| L4 (具体零件) | 伺服驱动器过载 | 人工确认 | 每次 |
| L5 (动作) | 更换驱动模块 | 工单系统 | 每次 |
注意：L4和L5不要全部显示在填报界面，而是通过规则引擎自动匹配。
例如PLC报“伺服报警”，系统自动推荐L4为“伺服驱动器”，操作工只需确认。这样既深度又减负。行业通用建议：离散制造业推荐4层，流程制造业3层足够。
我公司的BI系统花了大价钱，但车间班组根本不打开仪表盘，填报还是用纸质表格。IT部门说已经做好了录入界面，但工人就是嫌麻烦。有没有激励或技术手段能让他们主动配合？
我踩过最深的坑就是只做了界面没做闭环。后来我设计了一套“三屏一奖”体系： 1. 工位屏（触控）：只在设备停机时自动弹出填报弹窗，20秒内必须完成选择。选项限制在5个以内，用图标代替文字。例如“🔧故障” “⏸换模” “📦缺料”。我测试过，工人平均用时12秒。
看板屏（公共区域）：实时显示各班组“填报准确率”和“有效数据天数”排名，前3名有红点亮灯。3. 手机屏（个人）：每天下班前推送“今日填报勋章”，连续7天满分奖励20元话费。技术配置细节： – 在BI填报界面做“默认置顶”功能。通过最近30天历史数据，自动将每个设备最常出现的3个原因置顶。
例如某冲压机近期反复发生“模具开裂”，则在下拉框第一位。- 设置“反悔”按钮：如果选错了原因，允许在2分钟内重新选择，但必须勾选“更正原因”。系统记录两次选择的时间差，用于培训。- 数据联动：当某设备连续3次选择“其他”且备注空，自动给班组长发钉钉提醒。
成效：在苏州一家电子代工厂实施后，一周内填报率从45%飙升至91%，且准确率（比对PLC日志）达到88%。关键是让工人觉得“这个系统在帮我，而不是管我”。
我们厂有台关键设备总是综合效率低，查OEE数据显示“设备故障”占比最高。但后来复盘发现，真正原因是每次故障后备件要等2小时，维修人员还要等1小时。这么复杂的原因链，BI系统怎么建模才能反映真实问题？
这是OEE分析中最被低估的陷阱，单一归因。很多文章教你把原因分得越细越好，但忽略了因果关系链。我独创的“因果链标注法”： 规则引擎设计： 当操作工选择“设备故障”时，系统自动询问两个关联问题： 1. 是否因备件缺失导致维修延迟？（选项：是/否） 2. 是否因维修人员未及时到位？
（选项：是/否） 这两个答案不改变主分类，但会记录到后台的“关联因素表”中。BI仪表板设计： – 主图：常规OEE趋势图，颜色标注主因。- 副图：在主因柱状图上点击任意一个“设备故障”柱子，弹出“根因链占比”饼图：其中“备件短缺占比60%”、“人员到位慢占比25%”、“单一故障仅15%”。
修正后，管理动作从“换轴承”改为“优化保养计划”和“建立无责报修文化”。注意：BI系统不要试图自动归因，要给人类判断留出空间。我的规则中，如果同一个设备连续3次都出现相同的关联因素组合，系统会自动生成改善建议工单，推送给设备工程师。
读者评论
作为一家汽配厂的设备主管，看完这篇简直想拍桌子，我们厂OEE报表里60%的停机原因都是“设备故障”，跟文章说的一模一样。那个“UI默认排序导致数据失真”的案例太戳心了，我们下季度就准备把填报界面改成按设备类型动态排序，先把“其他”占比压到15%以下。不过双层填报的落地成本得算算，维修工现在抵触额外录入，建议补充一些激励机制的实操细节。
文章提到的“计划停机不应剔除分析”点醒了我。之前做BI看板时总默认只追非计划停机，忽略了换模时间从45分钟降到25分钟这种明牌改善。现在准备把计划保养和换模额外拆成子指标看趋势，等于白捡一个提效入口。不过那个分层模型（操作层15项、技术层动态过滤）我们公司可能得先做信息化改造才能用，不是所有车间都有HMI。
作为BI产品的实施顾问，这篇文章把甲方常踩的坑说透了。最共鸣的是“责任归属写进原因分类”的危害，去年一个项目就因为标签带部门属性，设备部和生产部每周吵架，数据根本没法用。文章建议用客观现象+规则引擎自动归责，这个思路我已经抄进下个项目方案了。另外那张“分类精细度与有效率倒U型”的图很有说服力，以后说服客户别搞200项清单就靠它了。