1. 车间大屏上的OEE数字为什么总有人不信如果你在制造业待过几年大概率见过这样的场景车间墙上挂着一块大屏上面滚动显示着当天的OEE——85.3%、87.1%、83.6%数字挺好看。但只要你走到产线边上问一句当班班长今天这条线到底跑得怎么样对方多半会撇撇嘴大屏那个数看看就行。这个场景我见过太多次了。OEEOverall Equipment Effectiveness设备综合效率这个概念本身并不复杂一句话就能说清楚它衡量的是设备在计划生产时间内真正创造价值的比例。公式也简单OEE 时间稼动率 × 性能稼动率 × 良品率。三个乘数小学生都能算。但问题恰恰出在这里——公式越简单落地越难。我接触过几十家不同规模的工厂从几十台设备的小厂到上千台设备的集团工厂真正能把OEE算准、并且让车间上下都认这个数的比例低得可怜。大部分工厂的OEE系统本质上就是一个数据化妆间该停的机不算停该算的废品不算废最后得出一个皆大欢喜的数字贴在墙上给参观的人看。为什么算不准很多人第一反应是采集不到位数据不准工人不配合。这些都对但都是表象。真正的原因在于大部分工厂把OEE当成一个计算问题而它实际上是一个结构问题。你没有一个合理的设备效率系统结构采集再多的数据也只是在制造噪音。这篇文章我想把这件事聊透。我会从OEE算不准的根因讲起然后拆解一套完整的设备效率系统应该有的四层结构每一层解决什么问题、层与层之间怎么衔接、实际落地时哪些地方最容易翻车。不管你是设备工程师、生产主管还是正在选型OEE系统的IT负责人看完应该都能对号入座找到自己工厂卡在哪一层。2. 算不准的根因不在采集而在三个口径从来没对齐过2.1 时间口径什么算计划生产时间三个人有三个答案OEE的第一个乘数是时间稼动率分母是计划生产时间。听起来很明确但你去问车间主任、设备科长、财务三个人能给你三个答案。车间主任认为计划生产时间就是排班表上的时间比如两班倒每班8小时那就是16小时。设备科长认为得扣掉交接班、吃饭、计划保养这些实际可用时间可能只有14小时。财务则可能认为只要设备没在产出合格品所有时间都是损失计划生产时间应该按订单需求倒推。这三个口径没有谁对谁错但它们算出来的OEE能差出十几个百分点。更麻烦的是很多工厂在系统上线时压根没把这个口径定义清楚导致不同部门各算各的最后谁也不认谁的数。我见过一个典型案例某注塑厂上线OEE系统三个月设备部报的OEE是78%生产部报的是65%老板一看两个数差这么多直接把项目停了。后来复盘发现分歧就出在换模时间算不算计划停机上。设备部认为换模是计划内的应该从计划生产时间里扣掉生产部认为换模是损失应该算进停机时间里。一个口径差异让整个项目黄了。所以第一件事不是买系统不是装传感器而是把时间口径定义清楚并且让所有相关部门签字确认。这个定义要细到什么程度细到计划保养提前完成剩余时间算不算计划生产时间这种级别。2.2 性能口径设备铭牌速度到底该不该当基准性能稼动率 实际产量 / 理论产量。理论产量 设备理论节拍 × 实际运行时间。问题就出在设备理论节拍上。大部分工厂直接拿设备铭牌上的最大速度当理论节拍。但铭牌速度是设备在理想条件下的极限值实际生产中来料批次差异、模具磨损、环境温湿度变化都会让实际能跑到的速度低于铭牌值。你拿铭牌速度当基准算出来的性能稼动率永远偏低工人觉得冤枉久而久之就不信这个数了。另一种做法是拿历史最佳连续运行速度当基准。这个更合理但需要系统能自动识别并更新这个基准值。很多工厂的系统没有这个能力基准值设一次就再也不改了设备老化后性能稼动率越来越难看但没人知道是基准该调了。我个人的经验是性能基准应该分设备类型来定。对于标准化程度高的设备比如SMT贴片机可以用铭牌速度的85%到90%作为初始基准然后根据实际运行数据动态修正。对于非标设备或者受来料影响大的设备比如某些装配线最好用同型号设备群组的最佳实践值作为基准而不是单台设备的历史值。2.3 质量口径返工品到底算不算良品良品率的定义看起来最没争议合格品数 / 总产出数。但实际操作中合格的定义可以很模糊。比如一个零件生产出来后检测不合格但经过返工后合格了。这个零件算不算良品如果算那返工消耗的时间算不算性能损失如果不算那返工后合格的产品又该怎么统计大部分工厂的系统在这里是糊涂账。有的把返工件直接算进良品有的算进废品有的单独统计但不在OEE里体现。更常见的是返工发生在生产之后OEE系统采集不到这个数据导致良品率虚高。这三个口径的问题本质上不是技术问题而是管理问题。但很多工厂在选型OEE系统时只关注能不能采集数据能不能出报表忽略了系统是否支持灵活的口径配置。结果就是系统上线了数据也有了但算出来的数没人认。3. 四层结构拆解从信号到决策每一层都在解决一个特定问题聊完口径问题我们来看结构。一套能算准OEE的设备效率系统我把它拆成四层信号层、状态层、指标层、决策层。这四层不是简单的技术堆叠而是层层递进、各司其职。很多工厂的系统只做了前两层就急着出OEE报表结果自然是空中楼阁。3.1 信号层不是所有数据都值得采先搞清楚最小信号集信号层是系统的最底层负责从设备上采集原始数据。这一层最容易犯的错误是贪多——觉得数据采得越多越好恨不得把设备所有能读的参数都读上来。我见过一个工厂在一台注塑机上采了200多个信号点从温度、压力、流量到螺杆转速、锁模力应有尽有。结果呢数据存了半年没人看因为不知道这些数据跟OEE有什么关系。正确的做法是先定义最小信号集。对于OEE计算来说你至少需要三类信号运行/停止信号设备是在运行还是在停止。这是最基础的信号通常从设备的运行指示灯、主电机电流或者PLC的运行位读取。产出信号每生产一个产品给一个脉冲。这个信号可以来自设备的计数器、光电传感器或者从PLC的产量寄存器读取。良品/不良品信号这个信号往往不在设备上而在检测工位或者MES系统里。如果设备本身有自动检测功能可以直接读取如果没有就需要人工录入或者从下游系统对接。这三类信号是OEE计算的最小可行集。其他信号比如温度、压力、振动属于增强信号可以在最小信号集跑通之后再逐步加入用于做更深入的分析比如预测性维护、工艺优化。信号层还有一个关键问题采集频率。运行/停止信号需要高频采集因为一次短暂的停机可能只有几秒钟如果采集频率太低就会漏掉。产出信号则可以用事件触发的方式每来一个脉冲记一次。良品/不良品信号通常是批次级的频率最低。实操心得在信号层我建议先用能算OEE这个最低标准来筛选信号而不是用能分析一切这个最高标准。先把最小信号集跑稳再逐步扩展。否则项目周期会无限拉长还没看到成果就黄了。3.2 状态层把原始信号翻译成设备在干什么信号层采集的是原始数据比如电流大于5A或者计数器从100变成101。状态层的任务是把这些原始信号翻译成有业务含义的设备状态。设备状态通常分为几大类运行、待机、故障、换型、计划停机、无订单。每一类下面还可以细分比如故障可以分为机械故障、电气故障、模具故障、来料等待等。状态层的核心是状态判定逻辑。这个逻辑不是简单的有电流就是运行没电流就是停机因为设备在待机时也可能有电流故障时也可能有电流。你需要结合多个信号来综合判断。举个例子一台加工中心主电机电流大于3A且进给轴在移动判定为运行主电机电流大于3A但进给轴静止超过30秒判定为待机主电机电流为0且报警灯亮判定为故障主电机电流为0报警灯不亮且当前有工单判定为换型或待机。这个判定逻辑需要跟车间有经验的操作工一起梳理因为他们最清楚设备在不同状态下的表现。我通常的做法是先让操作工口述设备一天里会经历哪些状态每个状态有什么特征然后把这些特征翻译成信号逻辑。状态层还有一个重要功能状态持续时间计算。系统需要记录每个状态的开始时间和结束时间并计算出持续时间。这个数据是后续计算时间稼动率的基础。很多工厂的系统在这里做得不够细状态分类太粗比如只分运行和停机导致后面算出来的OEE没有分析价值。你只知道设备停了但不知道是故障停、换型停还是没订单停就没法采取针对性的改善措施。3.3 指标层OEE不是唯一指标但必须是一级指标指标层是大家最熟悉的就是算OEE、算时间稼动率、算性能稼动率、算良品率。但这一层的关键不是算出来而是算得让人信服。首先指标层需要支持多口径计算。同一个OEE可以按班次算、按设备算、按产品算、按工单算。不同角色关注的口径不同班组长关注本班次的OEE设备科长关注单台设备的OEE趋势生产经理关注整条线的OEE。系统需要能灵活切换这些口径而不是只给一个全局数字。其次指标层需要可追溯。当OEE数字异常时用户能一层层下钻看到是哪个时间段、哪台设备、哪个状态导致的。比如OEE从85%掉到78%点进去一看是下午2点到4点之间3号机因为模具故障停了2小时。这个追溯能力比OEE数字本身更重要。第三指标层需要区分结果指标和过程指标。OEE是结果指标它告诉你好不好但不告诉你为什么。过程指标包括平均故障间隔时间MTBF、平均修复时间MTTR、换型时间、待机时间占比等。这些指标才能指导具体的改善行动。我见过一些工厂只盯OEE数字OEE低了就开会骂人但没人去分析是哪个过程指标出了问题。结果就是骂完了下个月OEE还是那样。正确的做法是把OEE作为一级指标挂在墙上把过程指标作为二级指标放在系统里日常改善盯过程指标月度总结看OEE趋势。3.4 决策层从看数到用数差的是一个闭环决策层是四层结构的最上层也是最容易被忽略的一层。很多工厂的系统做到指标层就结束了报表能看大屏能显示但然后呢没有然后了。决策层要解决的是看到OEE异常后系统能自动触发什么动作。比如当某台设备的OEE连续三个班次低于目标值系统自动给设备科长推送一条消息并附上该设备的主要损失项是故障多、换型慢还是待机长。设备科长收到消息后可以在系统里直接创建一个改善任务指派给维修班组并设定完成时限。任务完成后系统自动跟踪该设备的OEE是否回升。这个闭环看起来简单但大部分工厂的系统做不到。原因是OEE系统往往是一个独立系统跟工厂现有的OA、MES、维修管理系统没有打通。消息推不出去任务建不起来改善跟踪不了。决策层的另一个功能是模拟和预测。比如如果我把换型时间从30分钟压缩到15分钟OEE能提升多少如果我把某台设备的故障率降低一半整条线的OEE能提升多少这种what-if分析能帮助管理者排优先级把有限的改善资源投到回报最高的地方。注意决策层不是要替代人的决策而是要给人的决策提供依据和工具。系统负责发现异常、推送信息、跟踪闭环人负责判断原因、制定方案、执行改善。两者分工明确才能让OEE系统真正产生价值。4. 层与层之间的衔接数据流断了OEE就是一笔糊涂账四层结构讲完了但真正决定系统成败的是层与层之间的衔接。我见过太多系统每一层单独看都还行但连在一起就各种断点。4.1 信号层到状态层时间同步是最大的坑信号层采集的数据往往来自不同的硬件模块有的走PLC有的走传感器网关有的走人工录入。这些数据的时间戳如果不统一状态层就没法准确判断。比如运行信号的时间戳是10:00:00产出信号的时间戳是10:00:03如果系统不做时间同步就会认为设备在10:00:00到10:00:03之间是运行的但没有产出可能误判为待机。解决这个问题需要在信号层就做统一时钟源。所有采集模块都从同一个NTP服务器对时时间戳精度至少到秒级。对于高速产线可能需要毫秒级。另一个坑是信号抖动。设备在运行过程中电流可能会有瞬间波动导致运行信号短暂断开。如果状态层直接按信号判断就会产生大量秒级停机把OEE拉低。解决方法是加防抖逻辑比如信号断开超过3秒才判定为停机3秒以内的波动忽略。4.2 状态层到指标层状态分类的粒度决定分析深度状态层输出的状态分类直接决定了指标层能算出什么。如果状态层只分运行和停机指标层就只能算出时间稼动率没法细分停机原因。我通常建议状态分类至少到两级。一级分类运行、停机。二级分类停机下面再分故障、换型、待机、计划保养、无订单。如果条件允许故障下面还可以再分机械、电气、模具、来料等。但分类也不是越细越好。分类太细操作工记录负担重数据质量反而下降。我的经验是二级分类足够满足80%的分析需求三级分类只在关键设备上做。4.3 指标层到决策层阈值设定需要动态基准决策层的自动触发依赖于指标层的阈值设定。但阈值设多少合适设高了天天报警大家麻木设低了该报的不报失去意义。很多工厂的阈值是拍脑袋定的比如OEE低于80%就报警。但不同设备、不同产品、不同班次合理的OEE水平是不一样的。用同一个阈值必然导致误报和漏报。更好的做法是动态基准。系统根据设备的历史数据自动计算出一个期望OEE范围比如过去30天同班次的OEE均值加减一个标准差。当实际OEE低于这个范围的下限时才触发报警。这样阈值会随着设备状态、产品结构的变化自动调整报警的准确性大大提高。5. 落地时最容易翻车的四个地方结构讲清楚了但知道结构和能落地是两回事。我复盘过多个OEE项目发现翻车的地方高度集中基本就这四个。5.1 把OEE当成IT项目而不是生产项目这是最致命的错误。很多工厂上OEE系统主导部门是IT部或者信息化部生产部只是配合。结果就是IT部关心的是数据能不能采上来、系统稳不稳定生产部关心的是这个数对我有什么用、会不会给我增加工作量。两边目标不一致项目必然拧巴。正确的做法是生产部主导IT部支撑。生产部负责定义口径、梳理状态、设定阈值、推动改善IT部负责选型、部署、对接、运维。项目负责人应该是生产经理或者设备科长而不是IT经理。5.2 追求全自动忽略了人工补录的价值很多工厂希望OEE系统100%自动采集不需要人工干预。这个目标很美好但现实中总有一些数据是自动采集不到的比如换型开始和结束的时间、故障的具体原因、返工的数量。如果强行追求全自动要么这些数据缺失导致OEE算不准要么用一些间接信号去推断但推断逻辑往往不准。我的建议是自动采集为主人工补录为辅。在关键节点设置人工确认比如换型开始时操作工在终端上点一下换型开始系统自动记录时间。这个动作只需要几秒钟但数据准确性大大提高。5.3 大屏只给领导看不给车间看OEE大屏挂在车间但显示的内容是给领导看的——全局OEE、月度趋势、排名对比。车间班组看了除了知道自己排第几没有任何指导意义。车间需要的大屏应该显示本班次、本产线、本设备的实时状态以及当前最大的损失项。比如3号机当前状态故障停机已持续12分钟主要原因是模具卡料建议动作通知模具组。这样的信息才能指导车间采取行动。5.4 上线即终点没有持续运营很多工厂的系统上线后验收通过项目组解散然后就没有然后了。系统还在跑数据还在采但没人看、没人分析、没人改善。半年后系统就成了一个数据坟墓。OEE系统的价值不在上线那天而在上线后的持续运营。需要有人定期看数据、分析损失、推动改善、验证效果。这个角色通常是设备工程师或者生产主管需要把OEE分析纳入日常工作。我建议的做法是每周开一次OEE分析会不超过30分钟只看三个数本周OEE、最大损失项、上周改善措施的验证结果。坚持三个月系统的价值就能显现出来。6. 一套能跑起来的OEE系统最小可行配置长什么样聊了这么多问题和结构最后给一个落地的参考。如果你现在要从零开始搭一套OEE系统或者改造现有的系统我建议按这个最小可行配置来。信号层每台设备至少采集运行/停止、产出计数两个信号。运行/停止信号从PLC的运行位读取产出计数从设备的计数器或者加装光电传感器。良品/不良品信号如果设备没有自动检测先通过人工在终端上录入频率可以是每批次一次。状态层定义六个一级状态运行、待机、故障、换型、计划保养、无订单。每个状态有明确的判定逻辑判定逻辑由设备工程师和操作工共同确认。状态切换时系统自动记录时间戳。指标层计算OEE、时间稼动率、性能稼动率、良品率。支持按班次、按设备、按产品三个维度查看。提供下钻功能能从OEE下钻到具体的时间段和状态。决策层设置动态阈值当OEE低于期望范围时自动推送消息给设备科长。消息中包含主要损失项和建议动作。设备科长可以在系统里创建改善任务跟踪闭环。这套配置不需要很贵的硬件也不需要很复杂的软件。关键是口径定义清楚、状态判定准确、数据有人用。我见过用Excel加人工录入也能把OEE算得八九不离十的工厂也见过花了几百万上系统但没人看的工厂。工具不是决定因素结构和使用才是。最后分享一个小技巧在系统上线初期不要急着全厂推广。先选一条产线或者一个车间做试点跑三个月把口径、状态、阈值都打磨好再逐步推广。试点期间每周跟车间开一次短会收集反馈快速迭代。这样上线成功率会高很多。这套四层结构不是理论模型是我从多个项目中总结出来的实战框架。每一层都有它存在的理由每一层的缺失都会导致OEE算不准或者用不起来。如果你正在为OEE算不准发愁不妨对照这四层看看自己卡在哪一层。大多数时候问题不在最上面而在最下面。 OEE算不准的根因不在采集，而在四层结构缺失
1. 车间大屏上的OEE数字为什么总有人不信如果你在制造业待过几年大概率见过这样的场景车间墙上挂着一块大屏上面滚动显示着当天的OEE——85.3%、87.1%、83.6%数字挺好看。但只要你走到产线边上问一句当班班长今天这条线到底跑得怎么样对方多半会撇撇嘴大屏那个数看看就行。这个场景我见过太多次了。OEEOverall Equipment Effectiveness设备综合效率这个概念本身并不复杂一句话就能说清楚它衡量的是设备在计划生产时间内真正创造价值的比例。公式也简单OEE 时间稼动率 × 性能稼动率 × 良品率。三个乘数小学生都能算。但问题恰恰出在这里——公式越简单落地越难。我接触过几十家不同规模的工厂从几十台设备的小厂到上千台设备的集团工厂真正能把OEE算准、并且让车间上下都认这个数的比例低得可怜。大部分工厂的OEE系统本质上就是一个数据化妆间该停的机不算停该算的废品不算废最后得出一个皆大欢喜的数字贴在墙上给参观的人看。为什么算不准很多人第一反应是采集不到位数据不准工人不配合。这些都对但都是表象。真正的原因在于大部分工厂把OEE当成一个计算问题而它实际上是一个结构问题。你没有一个合理的设备效率系统结构采集再多的数据也只是在制造噪音。这篇文章我想把这件事聊透。我会从OEE算不准的根因讲起然后拆解一套完整的设备效率系统应该有的四层结构每一层解决什么问题、层与层之间怎么衔接、实际落地时哪些地方最容易翻车。不管你是设备工程师、生产主管还是正在选型OEE系统的IT负责人看完应该都能对号入座找到自己工厂卡在哪一层。2. 算不准的根因不在采集而在三个口径从来没对齐过2.1 时间口径什么算计划生产时间三个人有三个答案OEE的第一个乘数是时间稼动率分母是计划生产时间。听起来很明确但你去问车间主任、设备科长、财务三个人能给你三个答案。车间主任认为计划生产时间就是排班表上的时间比如两班倒每班8小时那就是16小时。设备科长认为得扣掉交接班、吃饭、计划保养这些实际可用时间可能只有14小时。财务则可能认为只要设备没在产出合格品所有时间都是损失计划生产时间应该按订单需求倒推。这三个口径没有谁对谁错但它们算出来的OEE能差出十几个百分点。更麻烦的是很多工厂在系统上线时压根没把这个口径定义清楚导致不同部门各算各的最后谁也不认谁的数。我见过一个典型案例某注塑厂上线OEE系统三个月设备部报的OEE是78%生产部报的是65%老板一看两个数差这么多直接把项目停了。后来复盘发现分歧就出在换模时间算不算计划停机上。设备部认为换模是计划内的应该从计划生产时间里扣掉生产部认为换模是损失应该算进停机时间里。一个口径差异让整个项目黄了。所以第一件事不是买系统不是装传感器而是把时间口径定义清楚并且让所有相关部门签字确认。这个定义要细到什么程度细到计划保养提前完成剩余时间算不算计划生产时间这种级别。2.2 性能口径设备铭牌速度到底该不该当基准性能稼动率 实际产量 / 理论产量。理论产量 设备理论节拍 × 实际运行时间。问题就出在设备理论节拍上。大部分工厂直接拿设备铭牌上的最大速度当理论节拍。但铭牌速度是设备在理想条件下的极限值实际生产中来料批次差异、模具磨损、环境温湿度变化都会让实际能跑到的速度低于铭牌值。你拿铭牌速度当基准算出来的性能稼动率永远偏低工人觉得冤枉久而久之就不信这个数了。另一种做法是拿历史最佳连续运行速度当基准。这个更合理但需要系统能自动识别并更新这个基准值。很多工厂的系统没有这个能力基准值设一次就再也不改了设备老化后性能稼动率越来越难看但没人知道是基准该调了。我个人的经验是性能基准应该分设备类型来定。对于标准化程度高的设备比如SMT贴片机可以用铭牌速度的85%到90%作为初始基准然后根据实际运行数据动态修正。对于非标设备或者受来料影响大的设备比如某些装配线最好用同型号设备群组的最佳实践值作为基准而不是单台设备的历史值。2.3 质量口径返工品到底算不算良品良品率的定义看起来最没争议合格品数 / 总产出数。但实际操作中合格的定义可以很模糊。比如一个零件生产出来后检测不合格但经过返工后合格了。这个零件算不算良品如果算那返工消耗的时间算不算性能损失如果不算那返工后合格的产品又该怎么统计大部分工厂的系统在这里是糊涂账。有的把返工件直接算进良品有的算进废品有的单独统计但不在OEE里体现。更常见的是返工发生在生产之后OEE系统采集不到这个数据导致良品率虚高。这三个口径的问题本质上不是技术问题而是管理问题。但很多工厂在选型OEE系统时只关注能不能采集数据能不能出报表忽略了系统是否支持灵活的口径配置。结果就是系统上线了数据也有了但算出来的数没人认。3. 四层结构拆解从信号到决策每一层都在解决一个特定问题聊完口径问题我们来看结构。一套能算准OEE的设备效率系统我把它拆成四层信号层、状态层、指标层、决策层。这四层不是简单的技术堆叠而是层层递进、各司其职。很多工厂的系统只做了前两层就急着出OEE报表结果自然是空中楼阁。3.1 信号层不是所有数据都值得采先搞清楚最小信号集信号层是系统的最底层负责从设备上采集原始数据。这一层最容易犯的错误是贪多——觉得数据采得越多越好恨不得把设备所有能读的参数都读上来。我见过一个工厂在一台注塑机上采了200多个信号点从温度、压力、流量到螺杆转速、锁模力应有尽有。结果呢数据存了半年没人看因为不知道这些数据跟OEE有什么关系。正确的做法是先定义最小信号集。对于OEE计算来说你至少需要三类信号运行/停止信号设备是在运行还是在停止。这是最基础的信号通常从设备的运行指示灯、主电机电流或者PLC的运行位读取。产出信号每生产一个产品给一个脉冲。这个信号可以来自设备的计数器、光电传感器或者从PLC的产量寄存器读取。良品/不良品信号这个信号往往不在设备上而在检测工位或者MES系统里。如果设备本身有自动检测功能可以直接读取如果没有就需要人工录入或者从下游系统对接。这三类信号是OEE计算的最小可行集。其他信号比如温度、压力、振动属于增强信号可以在最小信号集跑通之后再逐步加入用于做更深入的分析比如预测性维护、工艺优化。信号层还有一个关键问题采集频率。运行/停止信号需要高频采集因为一次短暂的停机可能只有几秒钟如果采集频率太低就会漏掉。产出信号则可以用事件触发的方式每来一个脉冲记一次。良品/不良品信号通常是批次级的频率最低。实操心得在信号层我建议先用能算OEE这个最低标准来筛选信号而不是用能分析一切这个最高标准。先把最小信号集跑稳再逐步扩展。否则项目周期会无限拉长还没看到成果就黄了。3.2 状态层把原始信号翻译成设备在干什么信号层采集的是原始数据比如电流大于5A或者计数器从100变成101。状态层的任务是把这些原始信号翻译成有业务含义的设备状态。设备状态通常分为几大类运行、待机、故障、换型、计划停机、无订单。每一类下面还可以细分比如故障可以分为机械故障、电气故障、模具故障、来料等待等。状态层的核心是状态判定逻辑。这个逻辑不是简单的有电流就是运行没电流就是停机因为设备在待机时也可能有电流故障时也可能有电流。你需要结合多个信号来综合判断。举个例子一台加工中心主电机电流大于3A且进给轴在移动判定为运行主电机电流大于3A但进给轴静止超过30秒判定为待机主电机电流为0且报警灯亮判定为故障主电机电流为0报警灯不亮且当前有工单判定为换型或待机。这个判定逻辑需要跟车间有经验的操作工一起梳理因为他们最清楚设备在不同状态下的表现。我通常的做法是先让操作工口述设备一天里会经历哪些状态每个状态有什么特征然后把这些特征翻译成信号逻辑。状态层还有一个重要功能状态持续时间计算。系统需要记录每个状态的开始时间和结束时间并计算出持续时间。这个数据是后续计算时间稼动率的基础。很多工厂的系统在这里做得不够细状态分类太粗比如只分运行和停机导致后面算出来的OEE没有分析价值。你只知道设备停了但不知道是故障停、换型停还是没订单停就没法采取针对性的改善措施。3.3 指标层OEE不是唯一指标但必须是一级指标指标层是大家最熟悉的就是算OEE、算时间稼动率、算性能稼动率、算良品率。但这一层的关键不是算出来而是算得让人信服。首先指标层需要支持多口径计算。同一个OEE可以按班次算、按设备算、按产品算、按工单算。不同角色关注的口径不同班组长关注本班次的OEE设备科长关注单台设备的OEE趋势生产经理关注整条线的OEE。系统需要能灵活切换这些口径而不是只给一个全局数字。其次指标层需要可追溯。当OEE数字异常时用户能一层层下钻看到是哪个时间段、哪台设备、哪个状态导致的。比如OEE从85%掉到78%点进去一看是下午2点到4点之间3号机因为模具故障停了2小时。这个追溯能力比OEE数字本身更重要。第三指标层需要区分结果指标和过程指标。OEE是结果指标它告诉你好不好但不告诉你为什么。过程指标包括平均故障间隔时间MTBF、平均修复时间MTTR、换型时间、待机时间占比等。这些指标才能指导具体的改善行动。我见过一些工厂只盯OEE数字OEE低了就开会骂人但没人去分析是哪个过程指标出了问题。结果就是骂完了下个月OEE还是那样。正确的做法是把OEE作为一级指标挂在墙上把过程指标作为二级指标放在系统里日常改善盯过程指标月度总结看OEE趋势。3.4 决策层从看数到用数差的是一个闭环决策层是四层结构的最上层也是最容易被忽略的一层。很多工厂的系统做到指标层就结束了报表能看大屏能显示但然后呢没有然后了。决策层要解决的是看到OEE异常后系统能自动触发什么动作。比如当某台设备的OEE连续三个班次低于目标值系统自动给设备科长推送一条消息并附上该设备的主要损失项是故障多、换型慢还是待机长。设备科长收到消息后可以在系统里直接创建一个改善任务指派给维修班组并设定完成时限。任务完成后系统自动跟踪该设备的OEE是否回升。这个闭环看起来简单但大部分工厂的系统做不到。原因是OEE系统往往是一个独立系统跟工厂现有的OA、MES、维修管理系统没有打通。消息推不出去任务建不起来改善跟踪不了。决策层的另一个功能是模拟和预测。比如如果我把换型时间从30分钟压缩到15分钟OEE能提升多少如果我把某台设备的故障率降低一半整条线的OEE能提升多少这种what-if分析能帮助管理者排优先级把有限的改善资源投到回报最高的地方。注意决策层不是要替代人的决策而是要给人的决策提供依据和工具。系统负责发现异常、推送信息、跟踪闭环人负责判断原因、制定方案、执行改善。两者分工明确才能让OEE系统真正产生价值。4. 层与层之间的衔接数据流断了OEE就是一笔糊涂账四层结构讲完了但真正决定系统成败的是层与层之间的衔接。我见过太多系统每一层单独看都还行但连在一起就各种断点。4.1 信号层到状态层时间同步是最大的坑信号层采集的数据往往来自不同的硬件模块有的走PLC有的走传感器网关有的走人工录入。这些数据的时间戳如果不统一状态层就没法准确判断。比如运行信号的时间戳是10:00:00产出信号的时间戳是10:00:03如果系统不做时间同步就会认为设备在10:00:00到10:00:03之间是运行的但没有产出可能误判为待机。解决这个问题需要在信号层就做统一时钟源。所有采集模块都从同一个NTP服务器对时时间戳精度至少到秒级。对于高速产线可能需要毫秒级。另一个坑是信号抖动。设备在运行过程中电流可能会有瞬间波动导致运行信号短暂断开。如果状态层直接按信号判断就会产生大量秒级停机把OEE拉低。解决方法是加防抖逻辑比如信号断开超过3秒才判定为停机3秒以内的波动忽略。4.2 状态层到指标层状态分类的粒度决定分析深度状态层输出的状态分类直接决定了指标层能算出什么。如果状态层只分运行和停机指标层就只能算出时间稼动率没法细分停机原因。我通常建议状态分类至少到两级。一级分类运行、停机。二级分类停机下面再分故障、换型、待机、计划保养、无订单。如果条件允许故障下面还可以再分机械、电气、模具、来料等。但分类也不是越细越好。分类太细操作工记录负担重数据质量反而下降。我的经验是二级分类足够满足80%的分析需求三级分类只在关键设备上做。4.3 指标层到决策层阈值设定需要动态基准决策层的自动触发依赖于指标层的阈值设定。但阈值设多少合适设高了天天报警大家麻木设低了该报的不报失去意义。很多工厂的阈值是拍脑袋定的比如OEE低于80%就报警。但不同设备、不同产品、不同班次合理的OEE水平是不一样的。用同一个阈值必然导致误报和漏报。更好的做法是动态基准。系统根据设备的历史数据自动计算出一个期望OEE范围比如过去30天同班次的OEE均值加减一个标准差。当实际OEE低于这个范围的下限时才触发报警。这样阈值会随着设备状态、产品结构的变化自动调整报警的准确性大大提高。5. 落地时最容易翻车的四个地方结构讲清楚了但知道结构和能落地是两回事。我复盘过多个OEE项目发现翻车的地方高度集中基本就这四个。5.1 把OEE当成IT项目而不是生产项目这是最致命的错误。很多工厂上OEE系统主导部门是IT部或者信息化部生产部只是配合。结果就是IT部关心的是数据能不能采上来、系统稳不稳定生产部关心的是这个数对我有什么用、会不会给我增加工作量。两边目标不一致项目必然拧巴。正确的做法是生产部主导IT部支撑。生产部负责定义口径、梳理状态、设定阈值、推动改善IT部负责选型、部署、对接、运维。项目负责人应该是生产经理或者设备科长而不是IT经理。5.2 追求全自动忽略了人工补录的价值很多工厂希望OEE系统100%自动采集不需要人工干预。这个目标很美好但现实中总有一些数据是自动采集不到的比如换型开始和结束的时间、故障的具体原因、返工的数量。如果强行追求全自动要么这些数据缺失导致OEE算不准要么用一些间接信号去推断但推断逻辑往往不准。我的建议是自动采集为主人工补录为辅。在关键节点设置人工确认比如换型开始时操作工在终端上点一下换型开始系统自动记录时间。这个动作只需要几秒钟但数据准确性大大提高。5.3 大屏只给领导看不给车间看OEE大屏挂在车间但显示的内容是给领导看的——全局OEE、月度趋势、排名对比。车间班组看了除了知道自己排第几没有任何指导意义。车间需要的大屏应该显示本班次、本产线、本设备的实时状态以及当前最大的损失项。比如3号机当前状态故障停机已持续12分钟主要原因是模具卡料建议动作通知模具组。这样的信息才能指导车间采取行动。5.4 上线即终点没有持续运营很多工厂的系统上线后验收通过项目组解散然后就没有然后了。系统还在跑数据还在采但没人看、没人分析、没人改善。半年后系统就成了一个数据坟墓。OEE系统的价值不在上线那天而在上线后的持续运营。需要有人定期看数据、分析损失、推动改善、验证效果。这个角色通常是设备工程师或者生产主管需要把OEE分析纳入日常工作。我建议的做法是每周开一次OEE分析会不超过30分钟只看三个数本周OEE、最大损失项、上周改善措施的验证结果。坚持三个月系统的价值就能显现出来。6. 一套能跑起来的OEE系统最小可行配置长什么样聊了这么多问题和结构最后给一个落地的参考。如果你现在要从零开始搭一套OEE系统或者改造现有的系统我建议按这个最小可行配置来。信号层每台设备至少采集运行/停止、产出计数两个信号。运行/停止信号从PLC的运行位读取产出计数从设备的计数器或者加装光电传感器。良品/不良品信号如果设备没有自动检测先通过人工在终端上录入频率可以是每批次一次。状态层定义六个一级状态运行、待机、故障、换型、计划保养、无订单。每个状态有明确的判定逻辑判定逻辑由设备工程师和操作工共同确认。状态切换时系统自动记录时间戳。指标层计算OEE、时间稼动率、性能稼动率、良品率。支持按班次、按设备、按产品三个维度查看。提供下钻功能能从OEE下钻到具体的时间段和状态。决策层设置动态阈值当OEE低于期望范围时自动推送消息给设备科长。消息中包含主要损失项和建议动作。设备科长可以在系统里创建改善任务跟踪闭环。这套配置不需要很贵的硬件也不需要很复杂的软件。关键是口径定义清楚、状态判定准确、数据有人用。我见过用Excel加人工录入也能把OEE算得八九不离十的工厂也见过花了几百万上系统但没人看的工厂。工具不是决定因素结构和使用才是。最后分享一个小技巧在系统上线初期不要急着全厂推广。先选一条产线或者一个车间做试点跑三个月把口径、状态、阈值都打磨好再逐步推广。试点期间每周跟车间开一次短会收集反馈快速迭代。这样上线成功率会高很多。这套四层结构不是理论模型是我从多个项目中总结出来的实战框架。每一层都有它存在的理由每一层的缺失都会导致OEE算不准或者用不起来。如果你正在为OEE算不准发愁不妨对照这四层看看自己卡在哪一层。大多数时候问题不在最上面而在最下面。