根本原因分析
根本原因分析是一种不断追问事情为什么出错、直到答案不再变化的方法。修好根源，其上的症状也随之消失；只修症状，问题还会回来。质量管理、IT 事故响应、患者安全和航空领域都要求在故障之后做一次根本原因分析。各种方法的主要区别在于由谁来推理。
各种方法
五个为什么对故障问“为什么”，再对答案问“为什么”，问五次。一个人或一个小团队。快速、便宜，能找到一条因果链——提问者本来就怀疑的那一条。适合只有单一机制的单个事件；在原因相互作用的地方就很弱。
鱼骨图（石川图）把原因分门别类——人员、流程、设备、材料、环境——画成从脊骨伸出的鱼骨。由一位引导者根据小组的建议填写。求广而不求深：它列出候选原因，却完全不说明哪些原因影响哪些。
故障树分析从故障出发，经过与门 / 或门（AND/OR）一直到基本事件的自上而下的逻辑树。对于组件及其故障模式已知的工程系统，它很严谨。由分析师构建；需要社会领域很少具备的数据。
帕累托分析按类别统计事件，修复占了大多数事件的那些类别。它说明痛点在哪里，而不是什么导致了它——是一种分诊工具，不是找原因的工具。
结构化民主对话与问题朝夕相处的人写下候选原因，澄清它们，然后一次一对、以 75% 的门槛判断每个原因是否显著影响另一个原因。这些回答由一个算法组装成一张影响地图（解释结构模型，interpretive structural modelling），位于地图底部的原因就是根源。五十年的实践，数百场有记录的对话。这就是本网站运行的方法。
小组何时胜过分析师
一个问题就能决定。房间里有没有人知道原因？如果是一台机器出了故障，一位拿着日志的工程师会比十五个人投票更快找到原因。如果是送货延误、病人久等、一所学校留不住教师或者一座城镇失去信任，原因就分散在相关的人身上——夜班知道一个，调度员知道另一个，客户知道第三个——没有哪位分析师能全部掌握。这时，方法必须从每个人那里收集原因，让每个人判断其间的关联，否则它只能找到分析师原本就相信的东西。
研究中的两项发现解释了为什么普通的小组讨论也做不到这一点。如果在审视原因之间的关联之前就让人们按重要性给原因排序，他们会排错——这就是错误优先效应；而让一个小组发表看法，看法会分散得没有任何一项获得多数——这就是分散思维。结构化对话正是围绕这两点建立的：在判断关联之前不排序，关联一次判断一对，并要求绝大多数同意。
一次好的根本原因分析产出什么
- 一张地图，而不是一份清单：哪些原因影响哪些，根源位于底部。
- 每条关联都附有其背后的同意程度，让读者看清哪些已定、哪些未定。
- 争议留在记录中，而不是被平均掉。
- 行动对照根源来判断，而不是对照声音最大的症状。
七阶段模板 · 一个附有真实数字的完整示例 · 本网站如何为任意数量的小组运行它