如何创建根本原因分析流程图
如何画一张替你选方法的根本原因分析流程图：排在所有方法之前的证据关口、区分一条因果链与多个原因的分岔，以及每种方法各自停在哪里。
运作方式
列出团队真正会用的方法
写下这里有人受过训练的那四五种方法——5 Why、鱼骨图、故障树、变更分析、FMEA——每一种配一句话，说明它需要什么样的证据。一棵最后指向没人会用的方法的决策树，等于把人转介给一个陌生人，它只会被无视。
为每种方法写下入口条件
写明选中每种方法的条件：5 Why 要有一条可以复原的时间线，鱼骨图要有几个说得通的类别，故障树要有几个必须同时成立的条件，变更分析要满足昨天还好好的、今天就坏了。这些条件会变成菱形，所以它们必须可核对，而不是凭品味。
问句写成行，答案写成分支
每个菱形就是一行：问题填在“方框文字”里，“形状”设为决策，去向的行号填进“连线至”，答案按同样的顺序填进“连线文字”。三向的那一行带三个行号和三个标签，一旦这两份清单错位，整张图当场就读不下去了。
给每个方法行都定一条停止规则
一个只写着执行某种方法的方框，会一直执行到调查人厌倦为止。把停止条件写进这一步的备注里——这个组织能够改变的最后一个原因——并紧随其后画一个决策，让分岔了的因果链有地方可去。
把两个不算结论的结局画出来
一棵能用的树需要一个证据用尽的出口，和一个原因超出本地控制的出口。前者的“形状”设为拒绝，后者设为结束。少了前者，记录已经散失的调查人还是会去跑最近的那种方法，而它的入口条件根本不成立——这正是选择器存在的意义。
拿三次已结案的调查检验它
取三份已经结案的分析，各自从它的问题表述开始走一遍这棵树，看它是否落在当初真正用过的方法上。落不上的地方，先判断错的是哪一边再动手：一条会把案子引错的入口条件是树的缺陷，而一次用错方法的调查是一件要重开的事。
常见问题
根本原因分析该用哪种方法？
取决于证据的形状，所以这个选择属于一棵决策树，而不属于一份制度。单次失效、时间线又可以复原的，适合 5 Why。反复出现、原因可能落在材料、方法、设备或人员上的问题，适合鱼骨图。需要几个条件同时成立才会发生的失效，适合故障树。一直好好的，直到某次已知变更之后才坏的，适合变更分析。如果问的是什么可能会失效、而不是什么已经失效了，那是 FMEA，不是根本原因分析。
5 Why 和鱼骨图有什么区别？
5 Why 沿着一条因果链往回走；鱼骨图把待选原因铺开在若干类别上。真正重要的差别在结构上：5 Why 只能表达一个序列，装不下两个必须同时存在的原因；鱼骨图装得下几十个待选项，却说不出其中哪一个真的起了作用。两者配合使用时，鱼骨图是发散的那一步，5 Why 是收敛的那一步，在范围收窄之后沿着某一根鱼刺往下跑。
5 Why 到底要问几个为什么？
五是个便于记忆的说法，不是规则。因果链停在这个组织能够改变、并且会认可它是一个原因的最后一处：一项规范、一道控制、一份工作量、一个设计选择。有时两个为什么就够了，有时九个还嫌短。越过可控范围一路问进哲学的链，是多问了一个为什么；分岔成好几个都说得通的答案的链，已经不再是一条链——这说明失效是多因素的，而这种方法到头了。
人为差错算不算根本原因？
几乎从来不算，至少从针对它采取措施能不能改变什么的意义上说不算。一个人把任务做得和程序不一样，本身就是一个有原因的事件：一份和设备对不上的指导书、并排摆着的两个相似容器、排在一个班次第十一个小时的检查。可用的检验方法是问同一个班次上下一位有胜任能力的员工会不会做同样的事；答案是会的时候，报告里的那个名字只是给这次失效盖了个时间戳，而不是对它的交代。