根本原因分析流程图（决策树模板）
以决策树绘制的根本原因分析流程图：九道判断把问题分流到 5 个为什么、鱼骨图、故障树、升级调查，或一次有记录的终止。
什么是根本原因分析流程图（决策树模板）流程
有两种截然不同的图都被叫作根本原因分析流程图。一种是流程地图：它回答接下来会发生什么、由谁来做——从问题被提出，经遏制、收集证据、分析与验证，直到交接给纠正措施。那是根本原因分析流程本身的独立模板。本页是另一种——决策树。它回答的是：面对眼前这个问题该用哪种方法，以及谁有权作出这个决定。
这个区分之所以重要，是因为这些方法并不能互相替代。5 个为什么沿着单一因果链往下走，适用于一个团队从头到尾掌握这条链的情形。鱼骨图，也就是石川图，把搜寻铺开到方法、机器、材料、人员、测量与环境这些类别，适合多个因素很可能同时起作用的问题。故障树从一个已定义的失效开始倒推，沿着组件与条件如何产生该失效的逻辑往回走，适合有规格可供比对的技术性失效。如果不刻意作出选择，方法就会默认成主持人上一次用过的那一种，而调查也就悄悄继承了那种方法的盲区。
下面这张图由九个问题和四个终点组成，分布在四条泳道上；泳道标示的是谁回答每个问题，而不是谁执行工作。问题依次是：问题是否已经界定清楚，证据是否已经存在、是否充分，这是一次单发事件还是反复出现的模式，以及失效属于技术性、人为还是系统性。各条分支通向四个具名结果：原因获接受并开出一条 CAPA、升级为正式调查、退回证据收集，以及带着一条有记录的数据局限结案。没有任何分支被汇拢回同一条顺利路径，因为真实的调查并不总是以一个已证实的原因收场。
本流程图涵盖的内容
本模板包含
- 四条按决策权划分的泳道——流程负责人、调查负责人、质量审核人与管理层——横跨五个阶段：界定问题、检查证据、选择方法、执行分析，以及验证并决定
- 在选定任何方法之前的两道入口关卡：“问题是否已清晰定义？”的“否”把流程送回“收窄问题描述”并重新提问；“证据是否已经具备？”把“已具备”与“需收集”分开，让收集成为一个步骤，而不是一项假设
- 由质量审核人把守的“数据是否足以分析？”关口，其“不足”分支终止于“退回证据收集”，而不是允许在薄弱数据上挑选方法——充分性的判定标准以备注形式写在该节点上
- 方法选择器本身：“单发事件还是反复出现？”把“反复出现”直接送往鱼骨图；“失效的性质？”把“技术性”导向故障树、“人为”导向 5 个为什么、“系统性”导向鱼骨图
- 5 个为什么之后的“是否到达一个可控的原因？”检查——“是”继续走向验证，“否”把问题改道到鱼骨图，而不是接受一条已经越过组织所能改变范围的因果链
- 收尾处的分叉：“原因是否有证据佐证？”把“已验证”与“仅为假设”分开，“是否还能取得更多证据？”要么回到收集、要么带着一条有记录的数据局限结案，而“原因是否在本地可控范围内？”则终止于“原因获接受，开出 CAPA”或“升级为正式调查”
何时使用本模板
- 调查用的是主持人碰巧熟悉的那种方法，而你们希望方法由问题决定，而不是由习惯决定
- 你们正在编写或修订根本原因分析或问题管理程序，需要把方法选择规则记录在流程步骤旁边
- 团队一再对多因素问题使用 5 个为什么，并停在第一个听起来说得通的答案上
- 你们需要一种明确的停止方式——一条有记录的数据局限或一次升级——而不是为了结案而写下一个猜出来的原因
- 你们希望预先约定升级的触发条件，让那些归属于供应商、另一处场地或某项政策的原因离开本地团队，而不是卡在团队内部
运作方式
把泳道改成你们真正的决策人
这里的泳道是决策权，不是部门：流程负责人、调查负责人、质量审核人、管理层。把它们换成你们组织里真正回答每个问题的角色，并在可能的情况下让调查负责人与流程负责人分开。由对流程负有责任的人主导的调查，往往会落在那些说出来比较舒服的原因上。
把问题描述的规则写在第一道关卡上
“问题是否已清晰定义？”只有在有人说清楚“定义”意味着什么时才起作用。通常的判定标准是：描述给出了什么失效了、发生在哪里、什么时候、多久一次，并且完全不提原因。一份已经包含原因的描述——最常见的是某种版本的“操作人员失误”——会把这棵树余下的部分变成一次确认练习。
在数据关口上设定充分性门槛
在你们真正需要之前，就先决定“数据是否足以分析？”要求什么：一条可以重建的时间线、仍在保存期内的留样或日志，以及至少一份第一手陈述。把易失的项目标记出来，因为它们决定了收集必须多快完成。没有成文门槛，“不足”这条分支就永远不会被走到，方法也就会依据手边碰巧有的东西来挑选。
把方法选择规则改成你们自己的
这张图里的分流——反复出现走鱼骨图、技术性走故障树、人为走 5 个为什么、系统性走鱼骨图——是一个站得住脚的默认设置，而不是一条法律。请按你们的人实际受过训练的方法来调整，并补上你们会用的其他方法，例如变更分析或屏障分析。真正重要的是这条规则存在，并且显示在图上，好让这个选择可以在评审中被质疑。
定义 5 个为什么的停止规则与出口
“是否到达一个可控的原因？”正是那个阻止 5 个为什么一路问到天气或宏观经济的节点。停在你们组织能够改变的最后一个原因上。如果因果链在此之前就断了，或者分岔成几个同样说得通的答案，那么这个问题就是多因素的，“否”分支会把它改道到鱼骨图，而不是放一条单薄的链条过关。
约定升级触发条件，并让两张图都保持版本受控
写下什么会迫使“原因是否在本地可控范围内？”走向“超出本地”这条分支：归属于另一处场地、某家供应商或本团队无法改变的某项政策的原因；须向监管机构或客户报告的事件；以及任何涉及安全或已发运产品的情形。然后把这棵决策树与端到端的根本原因分析流程图连起来，让两张图都处于版本控制之下并保留审批记录，好让调查人员与评审人依据同一个经授权的版本工作。
常见问题
根本原因分析流程图是流程地图还是决策树？
两者都可以，而它们回答的是不同的问题。流程地图回答接下来发生什么、由谁来做：提出问题、遏制、收集证据、分析、验证、交接给 CAPA。决策树——也就是本页——回答该采用哪种方法、由谁决定，它的分支通向不同的结果，而不是汇拢到同一条路径上。多数组织两者都需要：流程地图用于程序本身，决策树用于程序里面的那些判断。如果你们需要的是端到端的完整流程，请使用根本原因分析流程本身的模板。
我该如何在 5 个为什么、鱼骨图与故障树之间选择？
依据问题的形态，而这正是图中那两个方法决策所检验的。5 个为什么适合由一个团队掌握的单一因果链，每个答案变成下一个问题。鱼骨图，也就是石川图，适合可能涉及多个类别的问题——方法、机器、材料、人员、测量、环境——因为它迫使团队越过第一条听起来说得通的分支。故障树适合有可定义的顶事件、并且可以沿组件失效逻辑倒推的技术性失效。反复出现的模式几乎总是值得先做一次鱼骨图，因为复发通常意味着某些条件，而不是一次性的因果链。很多调查会同时用两种：先在鱼骨图上生成候选原因，再沿着证据支持的那条分支跑 5 个为什么。
当 5 个为什么没有到达一个我们能控制的原因时该怎么办？
这正是“是否到达一个可控的原因？”这个决策的用途。如果因果链越过了你们组织能够改变的一切，或者分岔成几个同样说得通的答案，“否”分支会把问题改道到鱼骨图，而不是把最后一环当作根本原因接受下来。这是实践中最常见的失效方式：一路追问下去，直到碰上一件无可辩驳却又无从下手的事情，例如市场压力或人性，然后照样针对它写下一条措施。
证据已经消失时，流程图该怎么处理？
给它一个具名的结果，而不是把它留成一个缺口。这棵树有两个。在分析之前，“数据是否足以分析？”可以把案子送到“退回证据收集”，那是暂停，而不是在薄弱数据上继续往下走。在分析之后，当一个原因仍然只是假设时，“是否还能取得更多证据？”要么回到收集，要么终止于“带着数据局限结案”。带着写明的局限结案是一个正当的结果，而且它通常本身就会产生一条措施：让缺失的数据下一次能够拿得到。
有没有哪项标准要求使用特定的根本原因分析方法？
常见的管理体系标准要求你们确定不符合项的原因并采取措施使其不再发生，但并不规定该怎么做。ISO 9001 第 10.2 条就是这样写的，ISO 13485 对纠正措施与预防措施也采取同样的做法。这就把方法的选择留给了你们——而这恰恰是它值得记录下来的原因。像这样一棵决策树，把判定标准写在节点上，可以向审核员表明方法是依据写明的准则选定的，而不是凭偏好，并且无论由谁来做调查，答案都保持一致。