OEE项目为什么失败:系统上了,屏也挂了,半年后没人看
OEE项目失败很少因为软硬件不行,多数败在五件事上:口径没统一就上系统,各线数字不可比;一线不填停机原因,“其他”占大头;数据只给领导看,班组用不上;把OEE当考核指标,数字被修饰;一次性全厂铺开,问题来不及修。预防办法:先定口径、先做试点线、先让班组用。
败在哪:很少是技术问题
设备综合效率(OEE)项目或者设备数字化项目失败,典型的样子是:系统验收通过了,车间大屏亮着,半年后数据没人信、原因没人填、屏没人看,OEE和上线前相比没有变化。回头复盘,软件功能和采集硬件通常不是主因,问题多出在五件事上:口径没统一就上系统、一线不填原因、数据只给领导看、把OEE当考核指标、一次性全厂铺开。
这五件事往往是连着发生的。下面这张表可以先用来对号入座,后面逐条讲症状和预防办法。
| 失败原因 | 现场能看到的症状 | 预防办法 |
|---|---|---|
| 口径没统一就上系统 | 两条同样的线OEE差二十个点,一问是换型一个算停机一个不算 | 上系统前先出一页纸口径说明,全厂一个版本 |
| 一线不填原因 | 停机原因里“其他/未知”排第一 | 原因列表由班组参与制定,机旁两次点击内选完,填了要有人回应 |
| 数据只给领导看 | 大屏在办公楼,班组长说不出昨天自己线的TOP1停机 | 数据先进班组日会,再进管理层报表 |
| 当考核指标导致造假 | OEE稳步上升,产量和交付没变化 | OEE作观察指标,考核数据完整率和行动项闭环率 |
| 一次性全厂铺开 | 几十台设备同时上线,问题清单越来越长,推进人疲于救火 | 先做一条试点线,30天验收后再推 |
口径没统一,系统算得再快也没用
OEE的公式只有一行,但每个输入都有选择余地:吃饭休息算不算计划停机,换型算不算停机,没有订单的停机怎么处理,理想节拍取设计值、历史最好值还是标准工时,返修后合格的件算不算合格品。这些问题如果在上系统之前没有定下来,实施时就会由各车间、甚至各个实施工程师各自决定。
后果是数字不可比,接着是数字不可信。厂长在月会上问“为什么A线比B线低这么多”,两位主任各讲各的口径,争论半小时没有结论,从此这份报表就没人当真了。
预防办法是把口径写成一页纸,项目启动时第一件事就是开会定稿:
- 计划停机只包括哪几项(逐项列出,列表之外的一律算损失);
- 换型计入停机损失;
- 每个品种的理想节拍取值及依据;
- 合格品只算一次通过的;
- 小停机的判定阈值。
通行的定法可以参考OEE计算公式和计划停机包括哪些。口径定了之后,一年内不要动;要动,就连同历史数据一起重算。
一线不填原因:别怪工人
自动采集解决了“停了多久”,解决不了“为什么停”。原因要靠操作工选。操作工不选或者乱选,项目就只剩下一条很精确但没法用的停机曲线。
现场常见的几种情况:
- 原因列表有四五十项,是设备部按故障树整理的,操作工在触摸屏上翻三页才找得到“卡料”;
- 列表里写的是“物料供应异常”,现场叫“等料”,对不上;
- 选原因的终端在线尾,操作工在线头,走过去要半分钟;
- 选了三个月“等检验”,检验流程没有任何变化,操作工的结论是“填了也白填”;
- 选了“操作失误”会被班组长问话,于是没人选这一项。
预防办法对应着来:原因列表让班组长和老操作工一起定,控制在十几项以内,用现场的叫法;终端放在操作位伸手够得到的地方;几分钟以下的小停机不要求逐次选原因;最要紧的一条,是一线报上来的原因要有人接。哪怕每周只解决一项,在日会上讲一句“上周大家报的等叉车,现在改成换模前30分钟预叫了”,填报质量就会明显好转。
可以把“其他/未知”在停机总时长里的占比当作项目健康度的体温计,每周看一次。占比上升,说明一线在用脚投票。
数据只给领导看
不少项目的交付物是一块领导驾驶舱:全厂OEE、各车间排名、月度趋势,挂在办公楼大厅或者会议室。这些汇总数字对厂长有参考价值,但OEE是在机台边丢掉的,也只能在机台边找回来。能采取动作的人是班组长、维修工、工艺员,他们需要的是“昨天白班3号机停了哪几次、每次多久、什么原因”,不是一个车间月平均。
只给领导看还有一个副作用:在一线眼里,这套系统就成了“上面用来盯我们的东西”,和自己的工作无关,配合度自然低。
预防办法是倒过来设计:先满足班组的使用场景,再往上汇总。具体做法见用OEE开班组日会:看板在车间,每班更新,10分钟日会看三项、TOP3停机和行动项。管理层的报表是班组数据的汇总,而不是另做一套。
一考核就造假
系统上线后,很自然的下一步就是“把OEE纳入车间KPI”。数字一旦和奖金、排名挂钩,变好看的办法比改善设备容易得多:把换型、等料改记为计划停机;把理想节拍调松;不良品先不录,返修好了算合格;自动采集的,把长停机选成“无订单”。每一种做法在系统里都是合规操作,审计也查不出来。
症状是OEE曲线稳步上升,但同期的产量、交付、加班时数没有变化。此时管理层如果还拿这条曲线做决策,项目比没有做还糟。
稳妥的做法是OEE只作为观察指标,考核放在过程上:数据完整率、原因填报率、行动项闭环率。展开的讨论见OEE该不该纳入考核。
一次性全厂铺开
全厂铺开的动机可以理解:设备和软件集中采购单价低,项目周期好看,汇报起来有规模。但OEE项目的工作量不在安装,而在安装之后。每一台设备上线后都要经历一轮数据核对:信号接得对不对、待机有没有被算成运行、计数倍率对不对、产量和入库数对不对得上。每一个班组都要经历一轮原因分类的磨合。
假设(示例)一位推进人要同时照顾40台新上线设备,每台设备头两周冒出5个问题,那就是200个问题同时压过来。现实结果是大部分问题没人处理,数据长期不准,班组试了两周发现数字不对就不再看了。第一印象一旦形成,后面再修好也很难把人拉回来。
预防办法是先做一条试点线:选瓶颈或接近瓶颈、班组长愿意配合的线,30天内把口径、原因分类、数据核对、日会全部跑通,验收标准定为“数据可信、班组在用”。做法和逐周任务见OEE改善从试点线开始,计划表可直接用OEE试点线30天计划表。试点过了再按同类设备逐步推开,采购可以分批,也可以一次签、分批装。
还有几个不那么显眼的坑
- 没有专人。项目经理是兼职的,系统上线后回到原岗位,数据核对和日会辅导没人做。至少要有一位能把一半以上时间放在现场的推进人,持续三到六个月。
- 只有数据,没有改善资源。数据明确指向换模时间长,但没有预算做快换夹具、没有人手做SMED快速换模,班组看到问题年年一样,对数据也就失去兴趣。
- 新旧数字直接对比。如实测量后的OEE通常比原来人工报表低不少,原因见人工报工与自动采集的OEE差多少。如果没有提前说明,管理层会得出“上了系统效率反而下降”的结论。
- 设备部单打独斗。设备部主推的项目容易只看故障停机,而换型、等料、等检验、小停机这些归生产和质量管的损失没人认领。
启动前的自查清单
| 检查项 | 是/否 |
|---|---|
| 有一页纸口径说明,生产、设备、质量、财务都签过字 | |
| 停机原因列表由班组长参与制定,不超过十几项 | |
| 第一批只上一条试点线,班组长本人愿意 | |
| 有一位推进人能每天到试点线现场 | |
| 明确承诺OEE不与班组奖金直接挂钩 | |
| 班组看板和日会的安排先于领导大屏 | |
| 管理层已被告知:如实测量后数字可能比现有报表低 | |
| 预留了针对TOP损失做改善的人手和少量预算 |
八项里有三项以上答“否”,建议先补齐再启动,晚一个月开工的代价远小于做废一次。
常见问题
OEE系统上线后数据没人看怎么办?
先别加功能,回到一个班组,把数据放进每天10分钟的日会:看昨日三项、停机TOP3、定一条行动项。数据只要连续两周帮班组解决了一两个具体问题(比如等叉车、等首检),就会有人主动看。没人看通常是因为数据和班组每天要做的决定没关系。
停机原因里“其他”占比很高说明什么?
说明原因列表不好用,或者一线觉得填了也没用。常见情况有:选项太多找不到、选项是办公室想出来的与现场叫法不一致、选原因要走到远处的电脑上操作、填了“等料”之后从没有人去处理等料。要从这几处改,而不是发通知要求认真填。
OEE项目应该由IT部门还是生产部门主导?
由生产或精益部门主导、设备部和IT配合比较稳。IT主导容易把目标定成“系统上线、接口打通”,验收完就结束了;而OEE项目真正的工作是上线之后的数据核对、原因分类调整和班组日会,这些只有生产一线的管理者推得动。
已经失败过一次的OEE项目还能重启吗?
能,但不要原样重来。先弄清上次败在哪一条,公开承认;然后缩小范围,只选一条线,换一位愿意配合的班组长,明确承诺不与奖金挂钩。已有的硬件和系统多半还能用,要重做的是口径、原因分类和使用方式。
接着看
本站由 TEEPTRAK 出版,正文保持厂商中立;商业关系见出版方声明。发现错误请发邮件至 yqf@teepchina.com。
微信号 Teeptrak-SZ