根本原因分析（RCA）：别让“找根因”沦为一场表演

上个月，产线上那台贴片机又停机了。

四个小时。

客户那边催货催得跟催命一样，所有人都盯着你呢——那种压力，懂的都懂。故障复现、换备件、恢复生产，一套动作行云流水。然后呢？填写《根本原因分析报告》。我亲眼见过不止一次，工程师在“根因”那一栏写下“操作失误”或者“传感器老化”就交差了。说实话，这叫啥根本原因分析？骗鬼呢。

RCA，全称根本原因分析（Root Cause Analysis），在工业界是个被说烂了的词。ISO 9001要求它，客户审核问它，出了大事故调查组第一件事就是做RCA。可真正做对的，少。大多时候它变成了填表游戏——一种让所有人暂时心安、却埋下更大隐患的仪式。毕竟，同样的故障再来一次，谁脸上都挂不住。

工具不是摆设，尤其是5 Why

5 Why大概是流传最广的RCA方法了。问五次“为什么”，听起来简单得可笑。但它的威力恰恰在于那种近乎冒犯的追问——像一个不依不饶的孩子，逼着你撕开第一层肤浅的答案。举个例子：轴承烧了。为什么？因为缺油。为什么没及时加？因为点检漏了。为什么漏检？因为新来的技工没收到排程。为什么没收到？因为ERP系统里他的权限设置错了。为什么设错？因为入职培训流程没有明确规定IT权限配置步骤。你看，从“轴承缺油”追到“培训流程缺陷”，这才是根儿。可现实中，太多人问到第二个“为什么”就停住了，要么是被生产压力逼着尽快结案，要么是潜意识里不敢再往下挖——再挖下去，搞不好就挖到自己部门了。

我特别想吐槽一种现象：把5 Why做成线性推导，然后得出一个唯一根因。复杂系统里，很少有单一原因能搞定所有事儿。这也就是为什么很多资深人士会搭配使用故障树分析（FTA）或因果图（鱼骨图）。鱼骨图其实特别适合在跨部门会议上用，人机料法环往那儿一摆，各说各话，最后总能揪出几个原本没人注意的交叉点。不过呢，鱼骨图也有个毛病：它容易变成一场集体甩锅的狂欢，每个分支都写上点不痛不痒的原因，结果主次不分，资源全撒胡椒面了。得有个明白人主持，死死抓住“哪些因素组合起来必然导致问题”这个核心逻辑。

问：什么时候该用5 Why，什么时候该拉鱼骨图？

答：这问题我被人问了不下十次。简单粗暴的经验法则是：如果问题相对单一，因果链比较直，比如设备直接停机、某个参数跳变，用5 Why顺藤摸瓜，效率高。一旦问题涉及多部门、多变量交叉，比如产品不良率突然波动，而且工艺、原料、环境都有嫌疑，马上转鱼骨图或者原因树分析。千万别死抱着一种工具不放。还有，别等到出了大事故才想起来RCA——日常的小故障、小偏差，做“轻量级”的事件因果分析，花二十分钟画个简易鱼骨，效果比事后兴师动众强十倍。预防嘛，永远是更省钱的。

那些会让你翻车的坑

第一个大坑，就是把RCA等同于“找出责任人”。一旦会议桌上弥漫着追责的味道，所有人都会本能地防御，信息就开始变形。你要找的是系统性的原因，不是替罪羊。第二个坑，过早地停止追问。很多人满足于找到一个“说得通”的技术原因，比如“密封圈材质不耐高温”，于是换个材质就完事。可你想过没有，为什么当初选材的时候没考虑到？是设计评审漏了？还是成本压得太低只能选这种？这种组织层面的底层原因，才是真正的金矿。第三个坑，纠正措施只有“培训操作员”五个字。培训是必要的，但它往往是管理懒惰的遮羞布。如果系统本身有缺陷，光靠人的警惕性是靠不住的，Poka-Yoke（防错法）才是正道。

再说个让人哭笑不得的真事儿：有家工厂做了个非常漂亮的RCA，鱼骨图画得密密麻麻，5 Why记录逻辑严密，根因直指“供应商来料硬度波动”。然后呢？整改措施竟然是：“加强来料检验，每批抽检比例从5%提高到20%”。这不是根因解决，这是把压力转嫁给检验部门。根因是要去和供应商一起改善工艺、或者换掉不靠谱的供应商。用抽检去堵一个系统性变差的窟窿，不翻车才怪。对吧？

问：RCA报告最难写的部分是什么？

答：依我看，不是分析过程，而是“验证根因”和“评估纠正措施有效性”那段。太多报告里这部分是空的，或者写个“措施已完成，跟踪一个月无复发”就蒙混过关。你得拿出数据来啊！措施实施前后的失效概率对比、MTBF（平均故障间隔时间）变化、过程能力指数对比——没数据，你的RCA就是一纸空文。而且，验证要有时间维度，有的措施短期有效，长期却引入新风险，需要设一个持续监控期。建议用帕累托图跟踪措施执行后的效果，那种“问题真被干掉了”的视觉冲击，比你写满两页纸都管用。再一个，写报告时多用照片、截图、趋势图，文字能少则少。事故分析不是写小说。

让RCA活进日常里

最后聊点实际的。想把RCA做好，光靠工程师的自觉性不行，你得在系统里下点功夫。比如，强制要求所有停机超过一小时的故障都必须启动RCA程序，并且把报告质量纳入绩效——不是看报告有多厚，而是看同类故障有没有减少。可以搞个“故障经验库”，把每次分析出来的系统漏洞、认知盲区放进去，新人入职当教材，老员工定期回顾。另外，千万别藏着掖着，好的RCA案例要全公司分享，特别是那些差点犯了大错但被及时揪出来的“未遂事件”，价值往往比已发生的故障更高。说到底，根本原因分析不是一种技术，而是一种文化——承认问题、拥抱复杂性、持续改进的文化。说起来很虚，但做起来，就是一次会议、一张图、一次真诚的追问。

哪怕今天这文章，能让你下次写报告时多追问一层，也就值了。