根本原因分析（RCA）：别再用“操作失误”糊弄人了

那个让厂长失眠的故障

上周，一家注塑厂又停机了。液压系统压力不稳，产品全是废料。维修师傅换了个溢流阀，正常了两小时，又崩了。再换泵，还是不行。厂长打电话给我时，声音都是抖的：“老张，再停机下去，客户要砍单了！”我问了一句话：“液压油上次换油是什么时候？滤芯呢？”他愣了一下，查记录——两年前。油液里全是金属碎屑，泵早就被磨损颗粒打坏了。换阀换泵，全是治标不治本。根本原因分析（RCA）没做到位，就是烧钱。 说实话，搞了二十年设备管理，我见过太多人把“根本原因分析”理解为“找个替罪羊”。操作失误、元件老化、偶发故障……标签一贴，万事大吉。然后同样的故障，换个马甲再来一遍。这就是典型的“伪RCA”❗ 那么，真正的RCA该怎么做？没有八股套路。来点干货。

5Why：追问的艺术，不是数数

都知道5Why分析法，源自丰田。但很多人把它用成了“5个为什么”的填空题。机械地数数，问到第五个就停，简直荒谬。有一次，生产线机器人焊接臂突然停止动作，报警“通讯超时”。新手工程师上来就问： 为什么停机？ 通讯超时。 为什么通讯超时？ 网线松动。 为什么网线松动？ 插头卡扣断了。 为什么卡扣断了？ 插拔太频繁。 为什么频繁插拔？ 因为调试时要经常移动示教器。 这就停了？然后他们加固了网线插头。两个月后，又坏了。其实应该继续问：为什么调试时要频繁移动示教器？ 因为示教器接口位置设计不合理，靠近焊接工位，容易碰撞。再问：为什么设计不合理？ 因为没有考虑现场干涉，也没人反馈。真正的根本原因是设计评审流程缺失。所以，5Why的精髓不是几个W，而是追问到系统层面，直到你能看到流程、设计、管理上的漏洞💡

有一次，我带着团队做某个轴承频繁烧毁的RCA，问到第7个Why，才发现是仓库把两种润滑脂搞混了，因为标签褪色没及时更新。你看，这可能停在第4个Why吗？那个标签褪色问题，存在了三年！RCA做得好，能挖出陈年老病根。

鱼骨图 vs. 故障树：都能抓鱼，但姿势不同

刚接触RCA的人，常把鱼骨图（因果图）和故障树分析（FTA）搞混。其实区别挺大，虽然都用箭头。 鱼骨图适合团队头脑风暴，一群人围着白板，七嘴八舌，把所有可能的原因分门别类——人机料法环测。然后投票或数据验证，缩小范围。它像一张大网，先撒出去再说。但缺点也明显：容易主次不分，逻辑不严密。有次我们分析冲压件毛刺过大，鱼骨图列了20多个原因，从模具间隙到工人心情，最后发现是冲压油黏度因为气温下降而变化——这个因素在“环”里面，但最初被大多数人忽略了。幸好有数据支撑，不然就淹没在噪声里了。 故障树则是逻辑演绎，从上往下，用“与门”“或门”分析事件组合。比如“主轴过热”这个事件，可能是“冷却液流量不足”与“冷却液温度过高”同时发生，也可能是“轴承预紧力过大”。它更适合复杂系统，尤其安全性分析。不过，建造故障树需要深厚的系统知识，新手容易漏掉分支。我们厂用过一次故障树分析数控系统黑屏，最后追溯到PLC程序里的一个死循环条件，那个条件只在特定组合下触发，鱼骨图根本想不到这层。

两种方法没有优劣，看场景。紧急停机，我会先鱼骨图快速定位；涉及安全或高价值设备的彻底复盘，一定上故障树。✅ 另外，现在有些软件（比如TapRooT、Apollo RCA）能把两者结合，数字化引导分析，还能自动生成漂亮报告——不过别让报告掩盖了思考的本质。

问答：RCA实践中的挣扎与顿悟

问：根本原因分析（RCA）一定要找到绝对的根源吗？很多时候感觉没完没了。 答：绝了！这正是关键。很多同行掉入“无限回溯”的坑。比如一个螺丝松了，导致机器振动，螺栓疲劳断裂。你一直追溯：为什么振动没检测？因为传感器失效。为什么失效？因为坏了。为什么没换？因为没备件……一直问到采购流程、公司预算。理论上可以到宇宙大爆炸。但RCA需要边界。你得问自己：这个原因我们控制得了吗？解决它投入产出比合理吗？ 常见的做法是设定“根因”的标准：当原因属于可管理、可控制的范畴，并且纠正措施能预防复发，就可以停下了。比如前面的螺丝松动，如果从设计上加个防松垫圈就能解决80%的问题，那就可以定为根因，而不必去指责采购流程。RCA是实用主义，不是哲学思辨。❗ 问：现在我们厂也开始用RCA了，但每次分析完，措施很难落地，怎么办？ 答：啊，老毛病了。分析会开得热烈，行动计划写得花哨，三个月后翻出来一看，啥也没改。这种情况，问题不在RCA技术，在于组织文化和管理跟进。说实话，我得吐槽——很多公司把RCA当做一个政治正确的任务，填张表就算闭环。要解决落地，三招狠的：第一，让一线人员主导分析，不是工程师在办公室编原因，工人最清楚机器脾气。第二，纠正措施要SMART，有明确责任人、截止日，别用“加强巡检”这种虚词。第三，必须定期追踪验证，我见过最好的做法是，每个措施完成验证后，在设备履历表或数字管理系统里做个闭环标记，下次类似故障直接带出历史记录。这样才有个人的责任压力。如果条件允许，把RCA结果和措施执行情况跟绩效考核轻微挂钩——但别过度，否则大家会瞒报故障，反而更糟。💡

数字化时代的RCA：传感器、AI与人的洞察

现在提工业4.0，很多厂上了SCADA、OEE系统，数据采集密密麻麻。但数据多了，真的RCA更容易了吗？未必。我见过一家汽车零部件厂商，投资几百万做预测性维护，每天几百兆的振动频谱数据。结果呢？一台电机还是烧了，因为数据工程师看不懂频谱的异常模式，直到烧后复盘才明白那个小波动是征兆。工具再炫酷，最后做RCA的还是人。 不过，确实有些新实践值得借鉴。比如利用关联规则挖掘，把过去几年所有故障和上下文数据（换班时间、温湿度、操作员经验等）关联，找到隐藏的模式。有个案例，他们发现每当湿度超过85%且夜班期间，某种电子驱动器故障率飙升5倍。最终根因是空调在夜班会切换到节能模式，湿度失控，导致电路板结露。没有数据分析，靠人很难把夜班和空调模式关联起来。 还有根本原因分析的实时化——不是等故障发生再开复盘会，而是在数据监控中设置异常事件的自动触发分析流程。比如当设备效率低于阈值，系统自动把相关参数（电流、温度、振动）前后快照，导入分析模板，邀请相关人线上协作。这大大缩短了反应时间。我们厂正在试这个，效果还凑合，不过经常误报，需要人工过滤。✅ 最后提醒一点：RCA不是万能药。有些故障是复杂系统的“突发涌现”，没有单一根因。这时候强行找一个原因，反而误导。要接受“多重原因共同导致”，然后分别制定措施。永远记住，根本原因分析的目的是防止再发，不是为了一个漂亮的报告。漂亮的报告多了，事故还是会来。 好了，扯得有点多。该去车间转转了。