如何创建根本原因分析流程图
如何画一张替你选方法的根本原因分析流程图：排在所有方法之前的证据关口、区分一条因果链与多个原因的分岔，以及每种方法各自停在哪里。
根本原因分析流程图是一棵决策树：它按手上的证据，把调查人引向真正撑得住的那种方法——5 Why、鱼骨图或故障树——并写明每一种停在哪里。
简而言之
- 只有一个输出：该打开哪种方法，而不是一段调查经过。
- 5 Why 预设只有一条因果链，一旦不止一条，它会悄无声息地失效。
- 原因可能落在好几个类别里的时候，才轮到鱼骨图。
- 只有当几个条件必须同时成立时，故障树才值回它的成本。
- 点到某个人的名字，是分析提前停下的地方，不是它做完的地方。
这是选方法的图，不是调查日记
搜索根本原因分析流程图，返回的几乎都是调查日记：界定、收集、分析、验证、采取措施。它没错，也没用，因为从来没有人卡在这五个词的先后顺序上。调查人卡住的地方是该打开哪一种方法，而一张不回答这个问题的图，只画了这件事里容易的那一半。
对一起需要三个条件同时成立才会发生的失效做 5 Why，它照样会给出五行工整的因果链——错的、笃定的，而且已经落在纸上。鱼骨图预设了类别，表达不了依赖关系；故障树表达得了依赖关系，却需要一个已定义的顶事件。所以必须有一道分岔排在这三者之前：手上的证据描述的是一条事件链，还是几个待选的原因？把它放在那个位置上，选方法就不再是个人口味的事。
下面的示例判断多于叙述：十九行里有九行是问句，四个结局里有三个止步于原因之前。真正要看的是那些回头的箭头。“是否找到可改变的原因？”把已经分岔的因果链送回“用鱼骨图梳理原因”——这是在分析中途承认方法选错了——而“能否取得更多证据？”回到“收集文档与访谈记录”，不让一个假设被当成结论归档。
从证据走到选定的方法
五个阶段，第三个阶段之前不选方法——看“失效属于哪一类？”把“技术性”“人为”“系统性”分别送往三种不同的方法。
界定是回路，不是一步
三行，树还没开始：“问题是否已明确定义？”在“收窄问题陈述”把范围压紧之前不放行。下游每一次选择都依据那句表述，所以一句点了嫌疑原因的表述，等于在读证据之前就选好了方法。
先有证据，后有方法
这里还什么都没选：“证据是否已经存在？”和“数据是否足以支撑分析？”都排在每一个方法框之前。“不充分”落到“返回继续收集证据”上，因为一条谁也复原不了的时间线，说不清在场的是一条链还是几个类别。
选定方法的那一行
先看结构：“单次发生还是重复发生？”通向“失效属于哪一类？”，后者的三个出口才是全图的要点——“技术性”去“构建故障树”，“人为”去“对因果链做 5 Why 分析”，“系统性”去鱼骨图。重复发生的一律直接进鱼骨图。
两个不是原因的结局
验证有三个出口，其中两个不是原因。“能否取得更多证据？”走“已经穷尽”到“以数据受限为由结案”，此时没有任何方法的入口条件还成立；“原因是否在本地可控范围内？”走“超出本地”到“升级为正式调查”。
运作方式
列出团队真正会用的方法
写下这里有人受过训练的那四五种方法——5 Why、鱼骨图、故障树、变更分析、FMEA——每一种配一句话，说明它需要什么样的证据。一棵最后指向没人会用的方法的决策树，等于把人转介给一个陌生人，它只会被无视。
为每种方法写下入口条件
写明选中每种方法的条件：5 Why 要有一条可以复原的时间线，鱼骨图要有几个说得通的类别，故障树要有几个必须同时成立的条件，变更分析要满足昨天还好好的、今天就坏了。这些条件会变成菱形，所以它们必须可核对，而不是凭品味。
问句写成行，答案写成分支
每个菱形就是一行：问题填在“方框文字”里，“形状”设为决策，去向的行号填进“连线至”，答案按同样的顺序填进“连线文字”。三向的那一行带三个行号和三个标签，一旦这两份清单错位，整张图当场就读不下去了。
给每个方法行都定一条停止规则
一个只写着执行某种方法的方框，会一直执行到调查人厌倦为止。把停止条件写进这一步的备注里——这个组织能够改变的最后一个原因——并紧随其后画一个决策，让分岔了的因果链有地方可去。
把两个不算结论的结局画出来
一棵能用的树需要一个证据用尽的出口，和一个原因超出本地控制的出口。前者的“形状”设为拒绝，后者设为结束。少了前者，记录已经散失的调查人还是会去跑最近的那种方法，而它的入口条件根本不成立——这正是选择器存在的意义。
拿三次已结案的调查检验它
取三份已经结案的分析，各自从它的问题表述开始走一遍这棵树，看它是否落在当初真正用过的方法上。落不上的地方，先判断错的是哪一边再动手：一条会把案子引错的入口条件是树的缺陷，而一次用错方法的调查是一件要重开的事。
应避免的错误
对多因失效用 5 Why
这种方法表达不了两个必须同时存在的条件，于是它会悄悄挑中其中一个往下走。产出的是一条读起来很有说服力的单一因果链，而它拿掉的只是原因的一部分。
先选方法
方法跟着被指派的那个人一起到场，之后证据就被读成它想要的样子。把充分性和结构这两个问题放在每个方法框之前，让事实来做选择。
停在某个人的名字上
一份以某人把事做错收尾的分析，找到的是最后一个事件，不是原因。要问的是什么让这样的执行变得很可能发生：指导书、布局、工作量、交接。
打开一种方法却没有终止条件
没有写明停止规则，一条为什么链会一路问到哲学或问到追责，而鱼骨图会变成一份所有人对这个流程的不满清单。把规则写到步骤本身上。
搭建自己的 RCA 决策树
把这棵方法决策树打开成你们自己的图表，写入你们的调查人在各种方法之间做选择时所用的判定条件。
相关指南
常见问题
根本原因分析该用哪种方法？
取决于证据的形状，所以这个选择属于一棵决策树，而不属于一份制度。单次失效、时间线又可以复原的，适合 5 Why。反复出现、原因可能落在材料、方法、设备或人员上的问题，适合鱼骨图。需要几个条件同时成立才会发生的失效，适合故障树。一直好好的，直到某次已知变更之后才坏的，适合变更分析。如果问的是什么可能会失效、而不是什么已经失效了，那是 FMEA，不是根本原因分析。
5 Why 和鱼骨图有什么区别？
5 Why 沿着一条因果链往回走；鱼骨图把待选原因铺开在若干类别上。真正重要的差别在结构上：5 Why 只能表达一个序列，装不下两个必须同时存在的原因；鱼骨图装得下几十个待选项，却说不出其中哪一个真的起了作用。两者配合使用时，鱼骨图是发散的那一步，5 Why 是收敛的那一步，在范围收窄之后沿着某一根鱼刺往下跑。
5 Why 到底要问几个为什么？
五是个便于记忆的说法，不是规则。因果链停在这个组织能够改变、并且会认可它是一个原因的最后一处：一项规范、一道控制、一份工作量、一个设计选择。有时两个为什么就够了，有时九个还嫌短。越过可控范围一路问进哲学的链，是多问了一个为什么；分岔成好几个都说得通的答案的链，已经不再是一条链——这说明失效是多因素的，而这种方法到头了。
人为差错算不算根本原因？
几乎从来不算，至少从针对它采取措施能不能改变什么的意义上说不算。一个人把任务做得和程序不一样，本身就是一个有原因的事件：一份和设备对不上的指导书、并排摆着的两个相似容器、排在一个班次第十一个小时的检查。可用的检验方法是问同一个班次上下一位有胜任能力的员工会不会做同样的事；答案是会的时候，报告里的那个名字只是给这次失效盖了个时间戳，而不是对它的交代。