風險升級決策樹範本
風險升級決策樹：容忍度、影響門檻、授權與緊急程度，由本地應對到即時按事故升級，每條路徑都有具名結果。
甚麼是風險升級決策樹流程
升級會朝兩個方向出問題。本應往上送的風險在登記冊裡躺了一個月，因為無人覺得自己有資格提出；而負責人本來就可以處理的風險卻被送到指導委員會的會議上，因為提出來比自己作決定更安全。這兩種失效來自同一個缺口：判斷準則長在人的腦裡，而不是寫在紙上。風險升級決策樹把每一道測試都變成明確的、可以憑證據回答的問題，從而堵上這個缺口——於是同一條風險，不論落在誰手裡，都會走上同一條路徑。
本頁是一棵決策樹，而不是一張流程圖。它回答的是哪一個選項才對、誰握有決定權，因此問題沿著中軸一路往下，各條分支停在不同的地方。流程圖回答的是接下來發生甚麼、由誰來做，因此步驟由左往右推進，最後匯入同一個完成點。如果你需要的是升級被提出之後那條端到端的流程，請使用 /yue/templates/事故管理流程 上的事故管理流程圖，它涵蓋事故登記、優先次序判定、重大事故宣布、SLA 違約與結案。本圖止於路徑判定；那一張由這裡接手。
本範本使用輕量泳道，命名的是誰來回答每個問題，而不是在描摹部門：風險負責人、專案經理、指導委員會和管理層風險委員會，橫跨由登記到升級途徑的五個階段。主幹上有八道決策，其中真正帶有門檻的那四道——安全、法律或監管篩查，容忍度測試，預算與授權測試，以及影響門檻——判斷準則被寫進了註釋裡。五個具名終點，取代了流程圖會使用的那一條順利路徑。
本流程圖涵蓋的內容
本範本包含
- 四條按決策權劃分的泳道，而不是一張部門圖——風險負責人、專案經理、指導委員會、管理層風險委員會——鋪在五個階段上：登記、篩查、容忍度測試、門檻與時機、升級途徑。
- 兩個直接繞過評分的篩查問題：「風險是否已經發生？」和「是否涉及安全、法律或監管方面的風險承擔？」。其中任何一個為「是」，都可能走到「損害或違規是否迫在眉睫？」，其「是」分支運行「啟動事故處理程序」並終止於「即時按事故升級」。
- 本地那條分支：「是否在負責人的風險容忍度之內？」通向「主動應對風險是否划算？」，其中「否」終止於「接受風險並記錄在案」，「是」則進入「應對措施是否在預算與授權範圍之內？」——「範圍之內」終止於「本地應對並持續監察」，「超出範圍」則把風險往上送，即使風險承擔本身是可以承受的。
- 「影響是否超出升級門檻？」上的途徑分流：「超出」直接走向「通知風險委員會主席」，「未超出」則落到時機測試，而不是單憑金額就升級。
- 把兩條升級途徑分開的時機測試：「是否需要在下次指導委員會會議之前作出決定？」把「是」送出會議節奏之外、交給風險委員會主席，把「否」經由「撰寫升級報告」送到「升級至指導委員會」。
- 五個各不相同的終點，而不是一個漏斗：本地應對並持續監察、接受風險並記錄在案、升級至指導委員會、升級至管理層風險委員會，以及即時按事故升級。
何時使用本範本
- 編寫風險管理計劃中的升級章節，其中判斷準則必須寫明而不是靠默契。
- 帶新的專案經理或風險負責人上手，令升級由寫下來的測試驅動，而不是由個人性格驅動。
- 了結一場關於決策權的爭論——泳道說明了誰來回答每個問題，而這通常才是真正的爭點。
- 提供保證或審核所需的證據，說明升級準則確實存在、已經議定，並且真的套用在某一條具體風險上。
- 在一次事後檢討中，某條風險升級得太遲，需要追溯是哪一道測試本應觸發卻沒有觸發。
運作方式
把泳道改成你們真實的決策權
把風險負責人、專案經理、指導委員會和管理層風險委員會，換成你們機構裡真正握有權限的組織。令泳道始終對應「誰來回答每個問題」。如果並不存在風險委員會，就把那條泳道併入指導委員會並寫明，而不是在圖裡留下一個從不開會的組織。
把升級門檻寫成一個金額和一個時長
在你們掛上數字之前，「影響是否超出升級門檻？」都是死的。大部分機構會設一個與獲授權採購權限掛鈎的成本數字，和一個與浮動時間或合約里程碑掛鈎的進度數字，然後以先被超出的那一個作為觸發條件。把兩者都寫在這個節點上，好讓任何人不必開口問就可以套用這道測試。
為每一位負責人分別定義容忍度
「是否在負責人的風險容忍度之內？」的前提是容忍度已經獲授予並且寫下來。按負責人或按風險類別來設定，而不是為整個專案設定一次，並用與你們為風險評分相同的單位來表述。如果某位負責人名下甚麼都沒有寫，誠實的答案就是「否」，風險往上走。
把預算與授權分開
「應對措施是否在預算與授權範圍之內？」刻意是兩項測試。一項補救可能出得起錢，卻仍然需要一個負責人無權作出的決定，例如更改一份合約、停用一家供應商，或者接受一次延期。把這兩條界線都寫明，好讓「超出範圍」這條分支因為正確的理由而觸發。
訂定事故觸發條件，以及誰可以按下它
決定甚麼才令「損害或違規是否迫在眉睫？」得到「是」，並寫明誰可以不等任何人就宣布它。這是唯一一條繞過管治的分支，因此它的判斷準則要客觀到在非辦公時間亦可以套用，而且它應該直接交接給你們現有的事故處理程序，而不是另外描述一套新的。
議定會議節奏之外的途徑，走一遍，然後發佈一個版本
「是否需要在下次指導委員會會議之前作出決定？」只有在真的存在一條會議節奏之外的途徑時才有用：一位具名主席、一個回應時限，以及一種記錄該決定的方式。拿你們登記冊裡三四條真實風險來測試這棵畫好的樹，修正那些把它們送到明顯錯誤位置的分支，然後把它作為一個經過簽署的版本發佈，好讓大家知道當前適用的是哪一版。
常見問題
風險升級決策樹和風險升級流程有甚麼分別？
決策樹回答的是一個途徑問題——給定這條風險，可選項中哪一個才對，以及誰有權作出選擇。它的形狀是一串測試，最終停在若干個不同的結果上。升級流程回答的是途徑選定之後會發生甚麼：通知誰、準備甚麼材料、接收方做甚麼、決定如何回來、又如何被記錄。它的形狀是一串步驟，最後匯入一個完成點。兩者你們都需要，而把它們做成兩張獨立的圖更容易維護。用這棵樹來選定途徑，用事故管理流程圖來處理其後那條端到端的流程。
一條風險甚麼時候該升級、而不是在本地處理？
這棵樹有四個彼此獨立的觸發條件，任何一個成立就足夠。風險承擔超出負責人寫下來的容忍度。應對措施的花費超出獲授權預算，或者需要一個超出負責人權限的決定。影響超出議定的金額或進度門檻。又或者這條風險帶有安全、法律或監管的維度——這種情況下它不論金額多少都會離開本地途徑，因為對這一類風險承擔的容忍度實際上是零。除此之外的，都可以本地應對並持續監察；如果任何應對都不划算，那就接受並記錄在案。
這裡的風險胃納和風險容忍度有甚麼分別？
胃納是機構在最初就願意去追求的風險數量與類型；容忍度是某一位具體負責人在必須讓其他人介入之前，可以自行工作的那條界線。這棵樹測試的是容忍度，因為那才是一位風險負責人在某個星期二下午真的答得上來的操作性問題。ISO 31000 對兩者都沒有規定門檻——它期望機構自行定義風險準則，並令它們與自身目標保持一致——所以這些節點上的數字必須來自你們的風險管理計劃，而不是來自某個標準。
如果風險已經發生了會怎樣？
它就不再是風險了。風險是一件有負責人、有應對措施的、可能發生的未來事件；一旦成真，它就是一個問題，而如果損害或違規迫在眉睫，它就是一宗事故。這正是「風險是否已經發生？」成為樹中第一個問題的原因：「是」會徹底離開風險途徑，啟動事故處理程序，並終止於「即時按事故升級」，不必等待一次評分練習或下一次指導委員會會議。PRINCE2 劃的是同一條線，把已經發生的風險當作問題來處理，而不是繼續在風險登記冊裡管理它。
每一次升級都必須等到既定的指導委員會會議嗎？
不必，而且這棵樹把它變成一道明確的測試，而不是一次臨場發揮。「是否需要在下次指導委員會會議之前作出決定？」會把一條低於影響門檻、但時間緊迫的風險送出會議節奏之外、交給風險委員會主席，而不是把它壓到會議周期趕上來為止。把這道測試寫下來的價值在於，它同樣令另一個答案變得正當：如果這個決定確實等得起，那就撰寫升級報告，風險走到下一次既定的指導委員會會議——不必有人再爭論這樣做是否合理。