根本原因分析流程圖（決策樹範本）
以決策樹繪製的根本原因分析流程圖：九道判斷把問題分流到五個為甚麼、魚骨圖、故障樹、升級調查，或一次有紀錄的終止。
甚麼是根本原因分析流程圖（決策樹範本）流程
有兩種截然不同的圖都被叫作根本原因分析流程圖。一種是流程地圖：它回答接下來會發生甚麼、由誰來做——由問題被提出，經遏制、收集證據、分析與驗證，直到交接給糾正措施。那是根本原因分析流程本身的獨立範本。本頁是另一種——決策樹。它回答的是：面對眼前這個問題該用哪種方法，以及誰有權作出這個決定。
這個區分之所以重要，是因為這些方法並不能互相取代。五個為甚麼沿著單一因果鏈往下走，適用於一個團隊由頭到尾掌握這條鏈的情形。魚骨圖，也就是石川圖，把搜尋鋪開到方法、機器、材料、人員、量度與環境這些類別，適合多個因素很可能同時起作用的問題。故障樹由一個已定義的失效開始倒推，沿著組件與條件如何產生該失效的邏輯往回走，適合有規格可供比對的技術性失效。如果不刻意作出選擇，方法就會預設成主持人上一次用過的那一種，而調查也就悄悄繼承了那種方法的盲點。
下面這張圖由九個問題和四個終點組成，分佈在四條泳道上；泳道標示的是誰回答每個問題，而不是誰執行工作。問題依次是：問題是否已經界定清楚，證據是否已經存在、是否充分，這是一次單發事件還是反覆出現的模式，以及失效屬於技術性、人為還是系統性。各條分支通向四個具名結果：原因獲接受並開出一條 CAPA、升級為正式調查、退回證據收集，以及帶著一條有紀錄的資料局限結案。沒有任何分支被匯攏回同一條順利路徑，因為真實的調查並不總是以一個已證實的原因收場。
本流程圖涵蓋的內容
本範本包含
- 四條按決策權劃分的泳道——流程負責人、調查負責人、品質審核人與管理層——橫跨五個階段：界定問題、檢查證據、選擇方法、執行分析，以及驗證並決定
- 在選定任何方法之前的兩道入口關口：「問題是否已清晰定義？」的「否」把流程送回「收窄問題描述」並重新提問；「證據是否已經具備？」把「已具備」與「需收集」分開，令收集成為一個步驟，而不是一項假設
- 由品質審核人把守的「資料是否足以分析？」關口，其「不足」分支終止於「退回證據收集」，而不是容許在薄弱資料上挑選方法——充分性的判定準則以備註形式寫在該節點上
- 方法選擇器本身：「單發事件還是反覆出現？」把「反覆出現」直接送往魚骨圖；「失效的性質？」把「技術性」導向故障樹、「人為」導向五個為甚麼、「系統性」導向魚骨圖
- 五個為甚麼之後的「是否到達一個可控的原因？」檢查——「是」繼續走向驗證，「否」把問題改道到魚骨圖，而不是接受一條已經越過機構所能改變範圍的因果鏈
- 收尾處的分叉：「原因是否有證據佐證？」把「已驗證」與「僅為假設」分開，「是否還能取得更多證據？」要麼回到收集、要麼帶著一條有紀錄的資料局限結案，而「原因是否在本地可控範圍內？」則終止於「原因獲接受，開出 CAPA」或「升級為正式調查」
何時使用本範本
- 調查用的是主持人碰巧熟悉的那種方法，而你們希望方法由問題決定，而不是由習慣決定
- 你們正在編寫或修訂根本原因分析或問題管理程序，需要把方法選擇規則記錄在流程步驟旁邊
- 團隊一再對多因素問題使用五個為甚麼，並停在第一個聽起來說得通的答案上
- 你們需要一種明確的停止方式——一條有紀錄的資料局限或一次升級——而不是為了結案而寫下一個猜出來的原因
- 你們希望預先議定升級的觸發條件，令那些歸屬於供應商、另一處場地或某項政策的原因離開本地團隊，而不是卡在團隊內部
運作方式
把泳道改成你們真正的決策人
這裡的泳道是決策權，不是部門：流程負責人、調查負責人、品質審核人、管理層。把它們換成你們機構裡真正回答每個問題的角色，並在可能的情況下令調查負責人與流程負責人分開。由對流程負有責任的人主導的調查，往往會落在那些說出來比較舒服的原因上。
把問題描述的規則寫在第一道關口上
「問題是否已清晰定義？」只有在有人說清楚「定義」意味著甚麼時才起作用。通常的判定準則是：描述給出了甚麼失效了、發生在哪裡、甚麼時候、多久一次，並且完全不提原因。一份已經包含原因的描述——最常見的是某種版本的「操作員失誤」——會把這棵樹餘下的部分變成一次確認練習。
在資料關口上訂定充分性門檻
在你們真正需要之前，就先決定「資料是否足以分析？」要求甚麼：一條可以重建的時間線、仍在保存期內的留樣或日誌，以及至少一份第一手陳述。把易失的項目標記出來，因為它們決定了收集必須多快完成。沒有成文門檻，「不足」這條分支就永遠不會被走到，方法也就會依據手邊碰巧有的東西來挑選。
把方法選擇規則改成你們自己的
這張圖裡的分流——反覆出現走魚骨圖、技術性走故障樹、人為走五個為甚麼、系統性走魚骨圖——是一個站得住腳的預設，而不是一條法律。請按你們的人實際受過訓練的方法來調整，並補上你們會用的其他方法，例如變更分析或屏障分析。真正重要的是這條規則存在，並且顯示在圖上，好讓這個選擇可以在評審中被質疑。
定義五個為甚麼的停止規則與出口
「是否到達一個可控的原因？」正是那個阻止五個為甚麼一路問到天氣或宏觀經濟的節點。停在你們機構能夠改變的最後一個原因上。如果因果鏈在此之前就斷了，或者分岔成幾個同樣說得通的答案，那麼這個問題就是多因素的，「否」分支會把它改道到魚骨圖，而不是放一條單薄的鏈條過關。
議定升級觸發條件，並令兩張圖都保持版本受控
寫下甚麼會迫使「原因是否在本地可控範圍內？」走向「超出本地」這條分支：歸屬於另一處場地、某家供應商或本團隊無法改變的某項政策的原因；須向監管機構或客戶呈報的事件；以及任何涉及安全或已付運產品的情形。然後把這棵決策樹與端到端的根本原因分析流程圖連起來，令兩張圖都處於版本控制之下並保留審批紀錄，好讓調查人員與評審人依據同一個經授權的版本工作。
常見問題
根本原因分析流程圖是流程地圖還是決策樹？
兩者都可以，而它們回答的是不同的問題。流程地圖回答接下來發生甚麼、由誰來做：提出問題、遏制、收集證據、分析、驗證、交接給 CAPA。決策樹——也就是本頁——回答該採用哪種方法、由誰決定，它的分支通向不同的結果，而不是匯攏到同一條路徑上。多數機構兩者都需要：流程地圖用於程序本身，決策樹用於程序裡面的那些判斷。如果你們需要的是端到端的完整流程，請使用根本原因分析流程本身的範本。
我該如何在五個為甚麼、魚骨圖與故障樹之間選擇？
依據問題的形態，而這正是圖中那兩個方法決策所檢驗的。五個為甚麼適合由一個團隊掌握的單一因果鏈，每個答案變成下一個問題。魚骨圖，也就是石川圖，適合可能涉及多個類別的問題——方法、機器、材料、人員、量度、環境——因為它迫使團隊越過第一條聽起來說得通的分支。故障樹適合有可定義的頂事件、並且可以沿組件失效邏輯倒推的技術性失效。反覆出現的模式幾乎總是值得先做一次魚骨圖，因為復發通常意味著某些條件，而不是一次性的因果鏈。很多調查會同時用兩種：先在魚骨圖上生成候選原因，再沿著證據支持的那條分支跑五個為甚麼。
當五個為甚麼沒有到達一個我們能控制的原因時該怎麼辦？
這正是「是否到達一個可控的原因？」這個決策的用途。如果因果鏈越過了你們機構能夠改變的一切，或者分岔成幾個同樣說得通的答案，「否」分支會把問題改道到魚骨圖，而不是把最後一環當作根本原因接受下來。這是實踐中最常見的失效方式：一路追問下去，直到碰上一件無可辯駁卻又無從入手的事情，例如市場壓力或人性，然後照樣針對它寫下一條措施。
證據已經消失時，流程圖該怎樣處理？
給它一個具名的結果，而不是把它留成一個缺口。這棵樹有兩個。在分析之前，「資料是否足以分析？」可以把個案送到「退回證據收集」，那是暫停，而不是在薄弱資料上繼續往下走。在分析之後，當一個原因仍然只是假設時，「是否還能取得更多證據？」要麼回到收集，要麼終止於「帶著資料局限結案」。帶著寫明的局限結案是一個正當的結果，而且它通常本身就會產生一條措施：令缺失的資料下一次能夠拿得到。
有沒有哪項標準要求使用特定的根本原因分析方法？
常見的管理體系標準要求你們確定不符合項的原因並採取措施令它不再發生，但並不規定該怎樣做。ISO 9001 第 10.2 條就是這樣寫的，ISO 13485 對糾正措施與預防措施也採取同樣的做法。這就把方法的選擇留給了你們——而這正正是它值得記錄下來的原因。像這樣一棵決策樹，把判定準則寫在節點上，可以向審核員表明方法是依據寫明的準則選定的，而不是憑偏好，並且無論由誰來做調查，答案都保持一致。