專案風險管理指引

1. 專案風險管理的定義與重要性

1.1 定義

專案風險管理是指在專案生命週期中，系統性地識別、分析、評估、應對和監控可能影響專案目標達成的不確定性事件或條件的管理過程。

1.2 風險管理的核心概念

風險（Risk）：可能對專案目標產生正面或負面影響的不確定性事件
風險事件（Risk Event）：具體可能發生的風險情況
風險影響（Risk Impact）：風險事件對專案造成的後果
風險機率（Risk Probability）：風險事件發生的可能性

1.3 為什麼風險管理很重要？

1.3.1 提高專案成功率

預先識別潛在問題，避免被動應對
減少專案延遲、超支或品質不佳的風險
提升專案交付的可預測性

1.3.2 優化資源配置

合理分配應急資源（時間、預算、人力）
避免資源浪費在不重要的風險上
提高投資報酬率

1.3.3 增強利害關係人信心

展現專業的專案管理能力
提升客戶對專案團隊的信任
促進透明化溝通

1.3.4 符合法規與合規要求

滿足金融業監管機關的要求
降低法律風險與合規成本
建立良好的企業治理形象

1.4 金融 IT 專案的風險特性

高度監管環境：需符合多項法規要求
系統複雜度高：涉及多個系統整合
安全性要求嚴格：資料保護與資安防護
業務連續性重要：不能中斷營運服務

1.5 實務案例

某銀行核心系統更新專案，初期未充分進行風險管理，導致：

資料遷移時間超出預期 3 倍
系統上線後發現效能問題，影響客戶服務
預算超支 40%，專案延遲 6 個月

教訓：如果事前進行完整風險識別與評估，制定適當的應對計畫，這些問題大多可以預防或減輕。

2. 風險分類

2.1 技術風險

2.1.1 定義

與專案所使用的技術、工具、平台或系統相關的風險。

2.1.2 常見技術風險類型

技術成熟度風險
- 新技術缺乏實務經驗
- 技術文件不完整
- 社群支援不足
系統整合風險
- 不同系統間介面複雜
- 資料格式不相容
- 第三方系統變更
效能風險
- 系統效能不符合需求
- 併發處理能力不足
- 資料庫效能瓶頸
安全性風險
- 資安漏洞
- 資料外洩
- 權限控管不當

2.1.3 識別指標

團隊對技術的熟悉程度
技術的市場成熟度
系統架構複雜程度
安全性測試覆蓋率

2.2 管理風險

2.2.1 定義

與專案管理流程、組織結構、人員配置相關的風險。

2.2.2 常見管理風險類型

人力資源風險
- 關鍵人員離職
- 技能不足或錯配
- 團隊溝通不良
時程風險
- 工作量估算不準確
- 任務相依性複雜
- 里程碑設定不合理
溝通風險
- 需求理解不一致
- 利害關係人期望落差
- 跨部門協調困難
決策風險
- 決策延遲
- 決策品質不佳
- 決策權責不清

2.2.3 識別指標

團隊成員穩定性
專案管理成熟度
組織變革頻率
溝通機制有效性

2.3 外部風險

2.3.1 定義

來自專案團隊無法直接控制的外部環境因素。

2.3.2 常見外部風險類型

供應商風險
- 供應商財務狀況不佳
- 交付品質不符合要求
- 供應商人員異動
市場風險
- 競爭對手行動
- 市場需求變化
- 經濟環境影響
法規風險
- 法規政策變更
- 監管要求加嚴
- 合規成本增加
天災人禍
- 自然災害
- 疫情影響
- 政治不穩定

2.3.3 識別指標

供應商評估報告
市場趨勢分析
法規變更預告
風險預警系統

2.4 合規風險

2.4.1 定義

與法律法規、行業標準、內部政策不符而產生的風險。

2.4.2 常見合規風險類型

資料保護合規
- 個資法遵循
- GDPR 要求
- 資料跨境傳輸
金融監管合規
- 銀行法規定
- 資本適足率要求
- 壓力測試規範
資訊安全合規
- ISO 27001 標準
- 資安法規定
- 內控制度要求
稽核合規
- 內部稽核要求
- 外部查核準備
- 文件完整性

2.4.3 識別指標

法規更新頻率
稽核發現事項
合規成本趨勢
罰款風險評估

2.5 實務案例

某金融科技公司開發新的行動支付系統時遇到的風險：

技術風險：區塊鏈技術應用經驗不足，導致開發進度延遲
管理風險：PM 中途離職，專案知識傳承不完整
外部風險：合作銀行系統升級，介面規格突然變更
合規風險：金管會新增洗錢防制規定，需要重新設計 KYC 流程

學習重點：不同類型的風險往往會相互影響，需要整體性的風險管理策略。

3. 風險識別方法

3.1 概述

風險識別是風險管理的第一步，目標是盡可能完整地找出所有可能影響專案的風險事件。有效的風險識別需要結合多種方法，並定期更新。

3.2 訪談法

3.2.1 專家訪談

目的：利用專家經驗識別專業領域的風險

實施步驟：

確定訪談對象（技術專家、業務專家、經驗豐富的 PM）
準備訪談大綱和風險分類架構
進行結構化訪談
整理訪談結果並分類

訪談問題範例：

基於您的經驗，這類專案最容易出現什麼問題？
哪些技術環節風險最高？
過去類似專案有哪些教訓？
您認為我們目前最應該關注哪些風險？

3.2.2 利害關係人訪談

目的：了解不同角色關注的風險點

對象包括：

專案贊助者（高階主管）
使用者代表
技術團隊成員
營運維護人員
合規與稽核人員

3.2.3 訪談技巧

開放式問題：避免引導性問題
情境模擬：「如果發生 X 情況，會有什麼影響？」
歷史回顧：「上次類似專案遇到什麼問題？」
腦力激盪：鼓勵創意思考，不要急於評判

3.3 檢核表法

3.3.1 標準風險檢核表

根據組織經驗建立的風險項目清單，適合快速識別常見風險。

技術風險檢核項目：

技術成熟度是否足夠？
團隊技術能力是否匹配？
系統整合複雜度是否可控？
效能需求是否明確且可達成？
資安防護措施是否完整？
災難復原計畫是否完備？

管理風險檢核項目：

關鍵人員是否穩定？
時程安排是否合理？
資源配置是否充足？
溝通機制是否有效？
變更管理流程是否完善？
品質管控標準是否明確？

3.3.2 客製化檢核表

根據特定專案特性調整的檢核表。

金融業專用檢核項目：

法規合規要求是否完整識別？
個資保護措施是否到位？
資料備份與復原是否測試？
稽核軌跡是否完整記錄？
壓力測試是否規劃？

3.3.3 使用技巧

定期更新：根據新的經驗教訓更新檢核表
多人檢核：不同角色分別進行檢核
量化評估：為每個項目設定風險等級
追蹤改善：針對高風險項目制定改善計畫

3.4 歷史資料分析法

3.4.1 專案歷史資料

資料來源：

過往專案的風險登錄表
專案結案報告
變更請求記錄
問題單與缺陷報告
專案檢討會議記錄

3.4.2 組織經驗資料庫

建立方式：

統計常見風險類型與發生頻率
分析風險影響程度與應對效果
建立風險知識庫
制定風險應對標準作業程序

3.4.3 產業標竿分析

參考來源：

同業公開的專案資訊
顧問公司的研究報告
產業協會的最佳實務
學術機構的研究成果

3.5 其他識別方法

3.5.1 腦力激盪法

適用時機：專案初期，團隊成員熟悉專案內容後

實施原則：

不批評任何想法
鼓勵自由發想
追求數量而非品質
結合他人想法產生新點子

3.5.2 德爾菲法

適用情況：專家意見分歧，需要取得共識

實施步驟：

選定專家小組
設計問卷進行多輪調查
匯總分析專家意見
回饋結果給專家再次評估
重複直到達成共識

3.5.3 情境分析法

方法說明：設想不同情境下可能發生的風險

情境範例：

最佳情境：一切順利進行
最可能情境：遇到預期內的挑戰
最差情境：多重風險同時發生

3.6 風險識別的組織與文件化

3.6.1 風險識別會議

會議準備：

邀請相關利害關係人
準備風險分類架構
收集相關背景資料
設定會議目標與議程

會議進行：

說明風險管理目的與流程
使用多種識別方法
記錄所有識別出的風險
初步評估風險重要性

3.6.2 風險登錄表建立

建立風險登錄表記錄所有識別出的風險，包含：

風險編號
風險描述
風險分類
風險原因
潛在影響
識別日期
識別人員

3.7 實務案例

某銀行數位轉型專案的風險識別過程：

第一階段：專家訪談

訪談資深 PM：識別出系統整合風險
訪談技術架構師：識別出效能風險
訪談合規主管：識別出法規風險

第二階段：檢核表評估

使用標準檢核表：識別出 15 項常見風險
客製化金融業檢核：額外識別出 8 項合規風險

第三階段：歷史資料分析

分析過去 3 年同類專案：識別出供應商風險
參考業界案例：識別出資安風險

結果：共識別出 45 項風險，為後續風險評估與應對奠定基礎。

關鍵成功因素：

多元化的識別方法
廣泛的利害關係人參與
系統性的文件記錄
定期的識別更新

4. 風險評估

4.1 風險評估概述

風險評估是在風險識別之後，對每個風險進行量化或定性分析，以確定其對專案的潛在影響程度和發生可能性，為風險應對策略的制定提供依據。

4.2 風險機率評估

4.2.1 機率評估方法

定性評估法：

很低（Very Low）：0-10%，幾乎不可能發生
低（Low）：11-30%，不太可能發生
中（Medium）：31-60%，有可能發生
高（High）：61-80%，很可能發生
很高（Very High）：81-100%，幾乎確定發生

定量評估法：

使用歷史資料統計
專家判斷法
蒙地卡羅模擬
機率分佈分析

4.2.2 機率評估考量因素

歷史經驗：

過往類似專案的發生率
組織內部的經驗資料
產業統計資料

目前環境：

專案複雜度
團隊能力
技術成熟度
外部環境穩定性

趨勢變化：

技術發展趨勢
市場環境變化
法規政策走向

4.3 風險影響評估

4.3.1 影響評估維度

時程影響：

很低：延遲 < 1 週
低：延遲 1-2 週
中：延遲 2-4 週
高：延遲 1-2 個月
很高：延遲 > 2 個月

成本影響：

很低：增加成本 < 1%
低：增加成本 1-5%
中：增加成本 5-10%
高：增加成本 10-20%
很高：增加成本 > 20%

品質影響：

很低：不影響主要功能
低：影響次要功能
中：影響重要功能
高：影響核心功能
很高：系統無法使用

範圍影響：

很低：不影響專案範圍
低：影響小部分功能
中：影響重要功能模組
高：影響多個核心模組
很高：專案目標無法達成

4.3.2 綜合影響評估

選擇最高的影響等級作為該風險的整體影響等級，或使用加權平均方式計算。

4.4 風險優先級矩陣

4.4.1 風險矩陣建立

建立 5x5 的風險矩陣，橫軸為機率，縱軸為影響：

影響 ↑
很高 │ M   H   H   VH  VH
高   │ L   M   H   H   VH
中   │ L   L   M   H   H
低   │ VL  L   L   M   H
很低 │ VL  VL  L   L   M
     └─────────────────→ 機率
      很低 低  中  高  很高

風險等級說明：

VH（Very High）：非常高風險，需要立即處理
H（High）：高風險，優先處理
M（Medium）：中等風險，需要管理
L（Low）：低風險，監控即可
VL（Very Low）：極低風險，接受

4.4.2 風險分級管理

極高風險（VH）：

需要高層主管關注
制定詳細應對計畫
每週檢討進度
必要時調整專案範圍或時程

高風險（H）：

PM 重點管理
制定具體應對措施
每兩週檢討一次
準備應急計畫

中等風險（M）：

指派專人負責
定期監控狀態
每月檢討一次
必要時升級處理

低風險（L）：

列入風險清單監控
每季檢討一次
狀況變化時重新評估

極低風險（VL）：

記錄在案即可
半年檢討一次
通常可接受此風險

4.5 定量風險分析

4.5.1 預期貨幣價值（EMV）

計算公式：EMV = 機率 × 影響金額

範例：

風險：關鍵人員離職
機率：30%
影響：延遲 2 個月，成本增加 100 萬
EMV = 0.3 × 100 萬 = 30 萬

4.5.2 蒙地卡羅模擬

使用統計模型模擬專案在不同風險情境下的可能結果：

步驟：

定義風險變數的機率分佈
進行大量隨機抽樣模擬
計算專案結果的機率分佈
分析風險對專案的累積影響

4.5.3 敏感度分析

分析各風險因素對專案目標的敏感程度：

龍捲風圖（Tornado Diagram）：

橫軸顯示對專案的影響程度
縱軸列出各風險因素
長條越長表示影響越大

4.6 風險評估工具與技術

4.6.1 專家判斷法

德爾菲法：

多輪匿名專家意見調查
逐步收斂達成共識
適用於缺乏歷史資料的情況

三點估算法：

樂觀估算（O）
最可能估算（M）
悲觀估算（P）
期望值 = (O + 4M + P) / 6

4.6.2 資料分析技術

回歸分析：

分析風險因素與專案結果的關係
建立預測模型
量化風險影響

決策樹分析：

視覺化風險決策過程
計算各路徑的期望值
選擇最佳應對策略

4.7 風險評估文件化

4.7.1 風險評估報告內容

執行摘要：

主要風險概述
整體風險等級
關鍵建議事項

詳細評估結果：

每個風險的評估詳情
風險優先級排序
影響分析結果

建議行動：

高風險的應對建議
資源需求評估
時程安排建議

4.7.2 風險登錄表更新

在原有風險登錄表中增加：

機率評估結果
影響評估結果
風險等級
預期貨幣價值
評估日期
評估人員

4.8 實務案例

某銀行核心系統升級專案的風險評估：

風險 1：資料遷移失敗

機率：中（40%）
時程影響：高（延遲 6 週）
成本影響：高（增加 15%）
品質影響：很高（核心功能受影響）
綜合影響：很高
風險等級：VH（非常高風險）
EMV：40% × 500 萬 = 200 萬

風險 2：第三方系統介面變更

機率：低（20%）
時程影響：中（延遲 3 週）
成本影響：低（增加 3%）
品質影響：中（部分功能受影響）
綜合影響：中
風險等級：L（低風險）
EMV：20% × 80 萬 = 16 萬

評估結論：

資料遷移風險需要立即制定詳細應對計畫
第三方介面風險可以透過監控管理
總體風險準備金建議：300 萬（考慮其他風險）

5. 風險應對策略

5.1 風險應對策略概述

根據風險評估結果，針對不同等級的風險採取適當的應對策略。風險應對的目標是將風險對專案的負面影響降到最低，同時考慮成本效益。

5.2 規避（Avoidance）策略

5.2.1 定義

完全消除風險發生的可能性或將風險影響降為零。

5.2.2 適用情況

風險等級為極高或高等級
風險影響嚴重且難以承受
有可行的替代方案
規避成本相對較低

5.2.3 常見規避方式

技術風險規避：

選擇成熟穩定的技術方案
避免使用未經驗證的新技術
採用標準化的系統架構
選擇有豐富經驗的技術團隊

管理風險規避：

調整專案範圍，排除高風險功能
延長專案時程，降低時間壓力
增加資源投入，確保充足人力
簡化專案複雜度

外部風險規避：

選擇可靠的供應商合作
避免依賴單一供應商
不在高風險時期啟動專案
避免跨國專案的政治風險

5.2.4 規避策略範例

案例：核心銀行系統升級專案

風險：新資料庫技術不穩定，可能影響系統效能
規避策略：改用已在組織內使用多年的成熟資料庫技術
效果：完全消除技術不穩定風險
代價：放棄新技術帶來的效能提升

5.3 轉移（Transfer）策略

5.3.1 定義

將風險的所有權或責任轉移給第三方，由第三方承擔風險後果。

5.3.2 適用情況

組織缺乏處理該風險的專業能力
第三方具備更好的風險管控能力
轉移成本低於自行承擔風險
風險具有可保險性質

5.3.3 常見轉移方式

保險轉移：

專案責任保險
資訊安全保險
關鍵人員保險
設備財產保險

契約轉移：

固定價格契約
效能保證條款
罰則條款
損害賠償條款

外包轉移：

技術開發外包
系統維運外包
測試服務外包
資安服務外包

5.3.4 轉移策略範例

案例：電子支付系統開發專案

風險：PCI DSS 合規要求複雜，內部缺乏專業知識
轉移策略：委託專業資安公司負責合規設計與驗證
契約條款：要求供應商承擔合規失敗的法律責任
效果：將合規風險轉移給專業機構

5.4 減輕（Mitigation）策略

5.4.1 定義

採取預防或準備措施，降低風險發生的機率或減少風險發生時的影響程度。

5.4.2 適用情況

風險無法完全規避或轉移
中等到高等級風險
有可行的減輕措施
減輕成本合理

5.4.3 常見減輕方式

降低機率的措施：

加強教育訓練
建立標準作業程序
實施品質管控
定期檢討與改善

降低影響的措施：

建立備援系統
準備應急計畫
分階段實施
設置檢核點

5.4.4 技術風險減輕策略

系統整合風險：

建立完整的測試環境
進行漸進式整合測試
建立介面規格文件
設置整合專責團隊

效能風險：

進行效能基準測試
建立效能監控機制
設計效能調校計畫
準備硬體擴充方案

資安風險：

實施多層次防護
定期進行滲透測試
建立資安事件應變程序
加強員工資安意識

5.4.5 管理風險減輕策略

人力風險：

建立關鍵知識文件
實施交叉訓練
建立人才備援機制
提供具競爭力的薪酬

溝通風險：

建立定期會議機制
使用協作平台
制定溝通標準流程
指定溝通窗口

時程風險：

設置緩衝時間
建立關鍵路徑監控
準備加班或外包計畫
調整里程碑安排

5.4.6 減輕策略範例

案例：行動銀行 APP 開發專案

風險：iOS/Android 版本相容性問題
減輕策略：
- 建立多版本測試環境（降低機率）
- 準備快速修復流程（降低影響）
- 分階段發布不同版本（降低影響）
效果：將相容性問題從高風險降為中等風險

5.5 接受（Acceptance）策略

5.5.1 定義

主動決定接受風險，不採取特殊的預防措施，但可能準備應急計畫。

5.5.2 適用情況

低等級風險
應對成本超過風險影響
風險發生機率極低
組織有足夠能力承受風險

5.5.3 接受策略類型

主動接受：

建立應急資金
準備應急計畫
設置監控機制
定期重新評估

被動接受：

不採取任何預防措施
風險發生時再處理
適用於極低風險
需要文件記錄決定原因

5.5.4 接受策略範例

案例：企業入口網站專案

風險：第三方廣告服務中斷
接受原因：影響有限，替代方案成本過高
主動接受措施：準備 2-3 個備用廣告服務商清單
監控指標：服務可用性監控

5.6 風險應對計畫制定

5.6.1 應對計畫要素

基本資訊：

風險識別編號
風險描述
風險等級
負責人員

應對策略：

選擇的策略類型
具體執行方法
預期效果
所需資源

執行安排：

執行時程
檢核點
成功標準
監控方式

5.6.2 應對計畫範本

## 風險應對計畫

**風險編號**：R001
**風險描述**：核心開發人員離職
**風險等級**：高

**應對策略**：減輕
**具體措施**：
1. 建立技術文件庫
2. 實施交叉訓練計畫
3. 提升薪酬待遇
4. 建立人才儲備

**資源需求**：
- 預算：50 萬
- 人力：HR 專員 1 名
- 時間：3 個月

**執行時程**：
- 第 1 個月：文件整理
- 第 2 個月：交叉訓練
- 第 3 個月：評估改善

**成功標準**：
- 關鍵技術文件完成率 100%
- 團隊成員滿意度 > 85%
- 離職率 < 10%

**負責人**：專案經理
**監控頻率**：每週

5.7 風險應對策略選擇原則

5.7.1 成本效益分析

評估要素：

策略實施成本
預期風險降低程度
實施的可行性
對專案目標的影響

選擇原則：

優先選擇成本效益比最佳的策略
考慮組織的風險承受能力
評估策略實施的可行性
確保與專案目標一致

5.7.2 多重策略組合

對於重大風險，可以採用多種策略組合：

範例：資料中心災難風險

轉移：購買災難恢復保險
減輕：建立異地備援中心
接受：承擔部分業務中斷風險
規避：使用雲端服務避免自建風險

5.8 實務案例

某保險公司數位轉型專案的風險應對：

高風險：法規遵循要求變更

策略：轉移 + 減輕
轉移措施：委託法務顧問公司負責法規追蹤
減輕措施：建立法規變更快速回應機制
效果：風險等級從「很高」降為「中等」

中風險：客戶資料遷移錯誤

策略：減輕
措施：分批遷移、完整測試、回滾機制
效果：風險等級從「中等」降為「低」

低風險：第三方服務中斷

策略：主動接受
措施：準備替代供應商清單
監控：每月檢視服務狀態

關鍵學習：

不同風險需要不同策略
重大風險可採用組合策略
成本效益是重要考量因素
定期檢討策略有效性

6. 風險監控與更新流程

6.1 風險監控概述

風險監控是風險管理的持續性活動，目的是追蹤已識別的風險、監控殘餘風險、識別新風險，並評估風險應對策略的有效性。

6.2 風險監控機制

6.2.1 定期監控活動

每週風險檢視：

檢視高風險項目狀態
更新風險指標數據
評估應對措施執行進度
識別新出現的風險徵兆

每月風險評估：

重新評估所有風險的機率和影響
檢討風險應對策略有效性
更新風險登錄表
向專案指導委員會報告

每季風險審查：

全面檢討風險管理策略
評估風險管理流程效果
更新風險管理計畫
進行風險趨勢分析

6.2.2 風險指標監控

領先指標（Leading Indicators）：

團隊士氣調查結果
技術債務累積程度
供應商績效評分
法規變更預告數量

落後指標（Lagging Indicators）：

實際發生的風險事件數量
風險事件造成的損失
專案延遲天數
預算超支比例

6.2.3 風險警示機制

風險閾值設定：

綠燈：風險指標正常範圍
黃燈：風險指標接近警戒值
紅燈：風險指標超過安全範圍

警示觸發條件：

風險機率或影響顯著增加
風險應對措施執行困難
出現新的高風險事件
多個風險同時惡化

6.3 風險監控工具

6.3.1 風險儀表板

關鍵風險指標（KRI）顯示：

風險等級分佈圖
風險趨勢變化圖
應對措施執行狀態
風險事件發生統計

視覺化元素：

顏色編碼（紅、黃、綠）
趨勢線圖
長條圖和圓餅圖
警示燈號

6.3.2 風險報告

風險狀態報告：

新增風險概述
風險等級變化
應對行動進度
需要關注的議題

風險趨勢報告：

風險數量變化趨勢
風險等級分佈變化
風險類別分析
預測性分析

6.3.3 監控工具選擇

專案管理工具：

Microsoft Project
Jira
Asana
Azure DevOps

風險管理專用工具：

GRC 平台
Monte Carlo 模擬軟體
風險登錄表範本
客製化 Excel 工具

6.4 風險更新流程

6.4.1 風險資訊更新

觸發更新的情況：

專案環境發生重大變化
風險應對措施完成執行
發現新的風險或機會
利害關係人提出新需求

更新內容：

風險描述修正
機率和影響重新評估
應對策略調整
負責人員變更

6.4.2 風險管理計畫更新

定期檢討週期：

專案里程碑完成時
重大風險事件發生後
組織政策變更時
外部環境顯著改變時

更新範圍：

風險管理流程
風險分類架構
評估標準調整
應對策略模板

6.5 風險溝通管理

6.5.1 內部溝通

專案團隊溝通：

每日站立會議風險快報
週會風險狀態更新
月會風險評估報告
季會風險策略檢討

管理層溝通：

高風險事項立即報告
月度風險摘要報告
季度風險趨勢分析
年度風險管理檢討

6.5.2 外部溝通

客戶溝通：

重大風險影響通知
風險應對進度報告
里程碑風險評估
專案收尾風險總結

供應商溝通：

風險分擔責任確認
應對措施協調配合
風險資訊共享
合約風險條款執行

6.6 風險學習與改善

6.6.1 風險事件檢討

事件發生時：

立即啟動應急計畫
記錄事件詳細資訊
評估實際影響程度
檢討應對措施效果

事後檢討會議：

分析事件發生原因
評估預防措施是否充分
檢討應對流程是否適當
提出改善建議

6.6.2 經驗教訓整理

建立知識庫：

風險事件案例集
應對策略效果評估
最佳實務分享
常見問題與解答

持續改善：

更新風險識別檢核表
改善風險評估方法
優化應對策略模板
強化監控機制

6.7 實務案例

某電子商務平台升級專案的風險監控：

監控機制設計：

建立風險儀表板，每日更新關鍵指標
設定自動警示，風險等級變化時發送通知
每週召開風險檢討會議
每月產出風險趨勢報告

關鍵風險監控：

技術風險：API 回應時間監控，設定閾值 < 200ms
業務風險：使用者滿意度調查，目標 > 85%
合規風險：個資保護稽核，每月檢查一次

監控效果：

提前 2 週發現效能瓶頸問題
避免了可能的系統當機風險
專案按時完成，無重大風險事件

學習要點：

有效的監控機制能提早發現問題
自動化監控工具提高效率
定期檢討會議確保團隊關注風險
量化指標比主觀判斷更準確

7. 附錄：風險登錄表模板與範例

7.1 風險登錄表模板

7.1.1 基本風險登錄表

風險編號	風險描述	風險分類	機率	影響	風險等級	應對策略	負責人	目標日期	狀態
R001	[風險描述]	[技術/管理/外部/合規]	[很低/低/中/高/很高]	[很低/低/中/高/很高]	[VL/L/M/H/VH]	[規避/轉移/減輕/接受]	[負責人姓名]	[完成日期]	[進行中/已完成/已關閉]

7.1.2 詳細風險登錄表

## 風險登錄表

### 基本資訊
- **風險編號**：R001
- **風險標題**：核心開發人員離職風險
- **識別日期**：2024-01-15
- **識別人員**：專案經理
- **最後更新**：2024-02-01

### 風險描述
**風險事件**：核心開發人員（資深後端工程師）可能在專案關鍵階段離職

**風險原因**：
- 市場薪資水準上升
- 工作壓力較大
- 職涯發展考量

**潛在影響**：
- 專案進度延遲 4-6 週
- 技術知識流失
- 團隊士氣受影響
- 額外招募和訓練成本

### 風險評估
- **發生機率**：中（40%）
- **時程影響**：高（延遲 6 週）
- **成本影響**：中（增加 8%）
- **品質影響**：中（需要重新熟悉代碼）
- **整體風險等級**：H（高風險）

### 應對策略
**策略類型**：減輕

**具體措施**：
1. 建立完整技術文件
2. 實施交叉訓練計畫
3. 提供留任獎金
4. 建立知識分享機制

**資源需求**：
- 預算：30 萬元
- 時間：8 週
- 人力：HR 1 名，技術主管 1 名

### 監控計畫
- **監控指標**：員工滿意度調查、離職意向調查
- **監控頻率**：每 2 週一次
- **負責人員**：專案經理、HR 經理
- **警示條件**：滿意度 < 7 分或明確表達離職意向

### 應急計畫
**如果風險發生**：
1. 立即啟動知識移交程序
2. 聯繫外包廠商支援
3. 調整專案時程
4. 加強其他團隊成員培訓

**所需資源**：
- 外包預算：100 萬元
- 延長時程：4 週
- 額外人力：2 名工程師

### 執行記錄
| 日期 | 行動項目 | 執行結果 | 下一步行動 |
|------|----------|----------|------------|
| 2024-01-20 | 員工滿意度調查 | 滿意度 6.8 分 | 安排個別面談 |
| 2024-01-25 | 技術文件整理 | 完成 60% | 繼續完善文件 |
| 2024-02-01 | 留任獎金提案 | 已提報核准 | 等待主管批准 |

7.2 不同風險類型範例

7.2.1 技術風險範例

### 風險：API 整合失敗
- **編號**：R002
- **分類**：技術風險
- **描述**：與第三方支付 API 整合時發生相容性問題
- **機率**：中（50%）
- **影響**：高（核心功能無法使用）
- **等級**：VH（非常高風險）
- **策略**：減輕 + 準備
- **措施**：
  - 提早進行 API 測試
  - 準備備用支付方案
  - 與供應商建立技術支援機制

7.2.2 管理風險範例

### 風險：需求變更頻繁
- **編號**：R003
- **分類**：管理風險
- **描述**：客戶可能頻繁變更需求，影響專案進度
- **機率**：高（70%）
- **影響**：中（延遲 2-3 週）
- **等級**：H（高風險）
- **策略**：減輕
- **措施**：
  - 建立變更管理流程
  - 設定需求凍結期
  - 與客戶簽署需求確認書

7.2.3 外部風險範例

### 風險：供應商交付延遲
- **編號**：R004
- **分類**：外部風險
- **描述**：硬體供應商可能因供應鏈問題延遲交付
- **機率**：中（30%）
- **影響**：高（專案無法如期上線）
- **等級**：H（高風險）
- **策略**：轉移 + 減輕
- **措施**：
  - 在合約中加入延遲罰則
  - 準備備用供應商
  - 提前下訂單建立緩衝時間

7.2.4 合規風險範例

### 風險：個資法規變更
- **編號**：R005
- **分類**：合規風險
- **描述**：個資保護法規可能在專案期間修訂
- **機率**：低（20%）
- **影響**：很高（需重新設計系統）
- **等級**：M（中等風險）
- **策略**：監控 + 準備
- **措施**：
  - 定期關注法規動態
  - 設計彈性架構
  - 建立快速調整機制

7.3 風險評估工作表

7.3.1 風險機率評估表

描述	機率範圍	評分	評估依據
很低	0-10%	1	幾乎不可能發生，歷史上極少見
低	11-30%	2	不太可能發生，但有先例
中	31-60%	3	有可能發生，需要關注
高	61-80%	4	很可能發生，應該預防
很高	81-100%	5	幾乎確定發生，必須處理

7.3.2 風險影響評估表

影響面向	很低(1)	低(2)	中(3)	高(4)	很高(5)
時程	<1週	1-2週	2-4週	1-2月	>2月
成本	<1%	1-5%	5-10%	10-20%	>20%
品質	不影響	次要功能	重要功能	核心功能	無法使用
範圍	不變	小調整	模組調整	大幅修改	目標改變

7.4 風險應對計畫範本

# 風險應對計畫範本

## 基本資訊
- **風險編號**：[R###]
- **風險名稱**：[簡要描述]
- **風險等級**：[VL/L/M/H/VH]
- **制定日期**：[YYYY-MM-DD]
- **計畫負責人**：[姓名]

## 應對策略
- **策略類型**：[規避/轉移/減輕/接受]
- **策略說明**：[詳細描述選擇該策略的原因]

## 執行計畫
### 階段一：[階段名稱]
- **目標**：[階段目標]
- **行動項目**：
  1. [具體行動 1]
  2. [具體行動 2]
- **所需資源**：[人力、預算、設備]
- **完成期限**：[日期]
- **成功標準**：[可衡量的標準]

### 階段二：[階段名稱]
[重複上述格式]

## 監控與評估
- **監控指標**：[KPI 或關鍵指標]
- **監控頻率**：[每日/每週/每月]
- **報告對象**：[相關利害關係人]
- **檢討機制**：[定期檢討安排]

## 應急計畫
- **觸發條件**：[何時啟動應急計畫]
- **應急措施**：[具體應急行動]
- **所需資源**：[應急資源需求]
- **負責人員**：[應急負責人]

## 成本效益分析
- **實施成本**：[預估成本]
- **預期效益**：[風險降低程度]
- **投資報酬率**：[計算說明]

參考資料

書籍文獻

《專案管理知識體系指南》(PMBOK Guide) - Project Management Institute
《風險管理：理論與實務》- 台灣金融研訓院
《IT專案風險管理實務》- 資策會教育研究所

國際標準

ISO 31000:2018 風險管理原則與實務指引
COSO ERM 2017 企業風險管理整合框架
BS 31100:2011 風險管理實務守則

線上資源

工具與模板

8. 風險管理工具與技術

8.1 風險管理軟體工具

8.1.1 企業級風險管理平台

GRC（Governance, Risk & Compliance）平台：

ServiceNow GRC：整合風險、合規與稽核管理
MetricStream：企業風險與合規管理
NAVEX Global：合規與風險管理解決方案
LogicGate：敏捷風險管理平台

優點：

整合性風險管理
自動化工作流程
即時風險儀表板
合規報告自動生成

缺點：

成本較高
導入時間長
需要專業訓練
客製化複雜

8.1.2 專案管理工具的風險功能

Microsoft Project：

內建風險登錄表
風險影響分析
蒙地卡羅模擬
風險緩解追蹤

Jira：

風險問題追蹤
自訂風險欄位
風險工作流程
報告儀表板

Asana：

風險任務管理
風險標籤分類
風險進度追蹤
協作討論功能

8.1.3 試算表工具應用

Excel/Google Sheets 優勢：

成本低廉，易於取得
彈性高，可客製化
學習門檻低
與其他工具整合容易

推薦功能：

風險登錄表範本
自動風險評分計算
條件格式化警示
圖表化風險趨勢

8.2 風險分析技術

8.2.1 定量分析技術

蒙地卡羅模擬：

應用場景：時程與成本風險分析
工具軟體：@RISK、Crystal Ball、Risk Solver
分析步驟：
1. 定義不確定性變數
2. 設定機率分佈
3. 執行模擬運算
4. 分析結果統計

敏感度分析：

識別關鍵風險因子
評估變數影響程度
建立龍捲風圖
制定重點管控策略

情境分析：

最佳情境（Best Case）
最可能情境（Most Likely）
最差情境（Worst Case）
壓力測試情境

8.2.2 定性分析技術

風險矩陣法：

5x5 標準矩陣
客製化評估標準
顏色編碼分級
動態更新機制

專家判斷法：

德爾菲法
名義群體技術
腦力激盪法
親和圖法

根本原因分析：

魚骨圖（Ishikawa）
5 個為什麼
故障樹分析
事件樹分析

8.3 風險監控技術

8.3.1 關鍵風險指標（KRI）

技術風險 KRI：

系統可用性（%）
平均故障時間（MTBF）
平均修復時間（MTTR）
安全事件數量
程式碼品質指標

專案管理 KRI：

進度變異指數（SPI）
成本績效指數（CPI）
團隊離職率（%）
變更請求數量
客戶滿意度分數

合規風險 KRI：

稽核發現事項數
法規更新影響評估
合規訓練完成率
政策違規事件數
罰款風險金額

8.3.2 風險儀表板設計

即時監控面板：

上層區域：風險總覽
- 風險總數統計
- 風險等級分佈
- 趨勢變化圖表

中層區域：關鍵風險
- Top 10 高風險項目
- 新增風險清單
- 逾期應對行動

下層區域：詳細資訊
- 風險類別分析
- 部門風險分佈
- 應對措施進度

警示機制設計：

紅燈：立即需要行動
黃燈：需要關注監控
綠燈：狀況正常
藍燈：已結案風險

8.4 AI 與數據分析在風險管理的應用

8.4.1 預測性分析

機器學習應用：

風險事件預測模型
異常行為偵測
趨勢分析與預警
自動化風險評分

自然語言處理：

合約風險條款分析
新聞與社群媒體監控
法規文件自動分析
風險報告自動生成

8.4.2 大數據風險分析

資料來源整合：

內部營運資料
外部市場資料
法規政策資料
社群媒體資料

分析技術：

關聯規則分析
集群分析
時間序列分析
網路分析

9. 風險管理最佳實務

9.1 組織層面最佳實務

9.1.1 建立風險管理文化

高階主管支持：

風險管理政策制定
資源投入承諾
身教重於言教
定期檢討改善

全員參與機制：

風險管理教育訓練
風險識別獎勵機制
跨部門風險分享
員工風險意識調查

組織架構設計：

設立風險管理委員會
指派專職風險管理人員
建立風險管理三道防線
明確角色與責任

9.1.2 風險管理制度建置

政策與程序：

風險管理政策
標準作業程序
風險評估標準
應對策略指引

治理機制：

風險容忍度設定
風險報告機制
決策授權層級
績效考核連結

9.2 專案層面最佳實務

9.2.1 專案啟動階段

風險管理計畫制定：

根據專案特性調整
明確風險管理目標
設定風險容忍度
分配風險管理資源

利害關係人參與：

識別關鍵利害關係人
了解風險偏好
建立溝通機制
取得管理承諾

9.2.2 專案執行階段

持續風險監控：

建立監控機制
定期更新評估
即時應對調整
經驗學習記錄

整合專案管理：

風險與進度整合
風險與品質整合
風險與成本整合
風險與溝通整合

9.2.3 專案收尾階段

風險管理檢討：

風險管理效果評估
應對策略檢討
經驗教訓整理
最佳實務萃取

知識移轉：

風險資料庫更新
經驗分享機制
標準程序改善
人員能力提升

9.3 技術實施最佳實務

9.3.1 風險識別最佳實務

多元化識別方法：

結合不同識別技術
涵蓋各種風險類型
考慮不同時間階段
包含正面與負面風險

持續性識別：

定期識別更新
環境變化觸發
利害關係人輸入
歷史資料學習

9.3.2 風險評估最佳實務

客觀化評估：

使用歷史資料
多人獨立評估
標準化評估流程
定期校準調整

動態化更新：

定期重新評估
觸發條件設定
版本控制管理
變更追蹤記錄

9.3.3 風險應對最佳實務

策略組合運用：

多策略並行
成本效益考量
可行性評估
持續性監控

應對計畫具體化：

明確行動步驟
設定時程目標
分配責任人員
準備所需資源

9.4 產業特定最佳實務

9.4.1 金融業最佳實務

監管合規重點：

法規更新追蹤
合規風險評估
稽核準備機制
監管報告自動化

資安風險管控：

多層次防護架構
即時威脅偵測
事件應變機制
第三方風險管理

9.4.2 製造業最佳實務

供應鏈風險管理：

供應商評估機制
多元化供應策略
庫存緩衝管理
替代方案準備

營運風險控管：

設備預防保養
品質管制系統
環境安全管理
人員安全訓練

9.5 成功關鍵因素

9.5.1 領導與文化

高階主管領導：

以身作則的風險意識
充分的資源投入
持續的支持與關注
適當的授權與決策

組織文化建立：

開放的溝通環境
學習型組織建立
失敗容忍文化
持續改善精神

9.5.2 流程與工具

標準化流程：

清楚的流程定義
標準化的工具使用
一致的評估標準
有效的監控機制

適當的工具選擇：

符合組織需求
使用者友善介面
整合性考量
成本效益評估

9.5.3 人員與能力

專業能力建立：

風險管理知識
分析技能培養
溝通協調能力
決策判斷能力

團隊協作機制：

跨功能團隊合作
知識分享機制
經驗傳承制度
持續學習文化

10. 常見問題與解答

10.1 風險識別相關問題

Q1：如何確保風險識別的完整性？

A1：建議採用以下方法：

多元化識別技術：結合訪談、檢核表、歷史分析等方法
多角度參與：邀請不同部門、不同層級的人員參與
分階段識別：專案不同階段重複進行風險識別
外部觀點引入：邀請外部專家或顧問參與
標竿學習：參考同業或類似專案的風險經驗

Q2：風險識別會議經常流於形式，如何改善？

A2：改善建議：

會前準備充分：提供背景資料、風險類別清單
結構化引導：使用風險分解結構（RBS）引導討論
創造安全環境：鼓勵開放討論，不批評任何想法
具體化描述：要求參與者提供具體的風險情境
即時記錄整理：會議中即時記錄並確認風險描述

Q3：技術風險難以識別，有什麼建議？

A3：技術風險識別策略：

技術專家深度訪談：與資深技術人員進行專業討論
架構檢視法：從系統架構各層面檢視潛在風險
技術成熟度評估：評估所使用技術的成熟程度
相依性分析：分析技術元件間的相依關係
效能瓶頸分析：識別可能的效能限制點

10.2 風險評估相關問題

Q4：風險機率難以量化，如何處理？

A4：機率評估方法：

歷史資料統計：收集類似專案的歷史發生率
專家判斷法：結合多位專家的經驗判斷
三點估算：提供樂觀、最可能、悲觀三種估算
相對比較法：與已知風險進行相對比較
定性描述：使用文字描述取代精確數值

Q5：不同人員對風險影響評估差異很大，如何統一？

A5：統一評估標準：

建立評估量表：制定詳細的影響程度描述
提供評估範例：使用實際案例說明各等級影響
校準會議：組織評估者進行標準校準討論
多人評估平均：採用多人評估結果的平均值
定期檢討調整：根據實際結果調整評估標準

Q6：如何處理風險之間的相互影響？

A6：風險相關性處理：

相關性分析：識別風險間的影響關係
風險網路圖：繪製風險相互影響的網路圖
情境分析法：考慮多個風險同時發生的情境
蒙地卡羅模擬：在模擬中考慮風險間的相關性
整體影響評估：評估風險組合的整體影響

10.3 風險應對相關問題

Q7：資源有限時如何選擇風險應對策略？

A7：資源分配策略：

風險優先級排序：專注處理高風險項目
成本效益分析：選擇投資報酬率最高的策略
階段性實施：分階段實施風險應對措施
資源共享機制：多個風險共享應對資源
外部資源整合：考慮外包或合作夥伴支援

Q8：風險應對計畫執行困難，如何改善？

A8：執行改善建議：

具體化行動計畫：將應對策略分解為具體行動
明確責任分工：指定明確的負責人和時程
定期檢視進度：建立定期檢視和報告機制
障礙識別處理：主動識別並處理執行障礙
適時調整策略：根據執行狀況調整應對策略

Q9：如何說服管理層投入風險應對資源？

A9：管理層溝通策略：

量化風險影響：用數字說明風險的潛在損失
成本效益分析：展示風險應對的投資報酬
競爭優勢角度：說明風險管理帶來的競爭優勢
法規合規要求：強調法規要求和合規成本
成功案例分享：提供其他組織的成功經驗

10.4 風險監控相關問題

Q10：風險監控指標設定困難，有什麼建議？

A10：指標設定原則：

SMART 原則：具體、可測量、可達成、相關、有時限
領先與落後指標並重：預警指標與結果指標結合
量化與質化並用：數值指標與描述性指標結合
簡單易懂：避免過於複雜的計算或解釋
可操作性：確保能夠實際收集和分析數據

Q11：風險狀態變化頻繁，如何有效管理？

A11：動態管理方法：

自動化監控：使用工具自動收集和更新數據
閾值警示機制：設定自動警示觸發條件
簡化更新流程：設計簡單的狀態更新流程
異常管理：重點關注異常變化的風險
趨勢分析：關注風險變化趨勢而非單點數據

Q12：風險報告過於冗長，如何改善？

A12：報告優化建議：

分層報告：針對不同層級提供不同詳細程度
視覺化呈現：使用圖表替代大量文字描述
重點突出：強調需要關注的關鍵風險
例外報告：只報告有變化或需要行動的風險
標準化格式：建立一致的報告格式和結構

10.5 工具與技術問題

Q13：組織規模小，無法導入專業風險管理工具，如何處理？

A13：輕量化解決方案：

Excel 範本：使用功能豐富的 Excel 風險管理範本
免費工具：使用 Google Sheets、Trello 等免費工具
雲端服務：使用低成本的雲端專案管理服務
分階段導入：從簡單工具開始，逐步升級
外部支援：考慮顧問服務或培訓支援

Q14：如何選擇適合的風險管理工具？

A14：工具選擇考量：

組織需求評估：明確功能需求和預算限制
擴展性考量：考慮未來成長的需要
整合性評估：與現有系統的整合能力
使用者友善性：介面易用性和學習曲線
供應商評估：供應商穩定性和支援服務

Q15：定量風險分析何時使用？如何實施？

A15：定量分析應用：

適用情況：大型專案、高風險專案、需要精確分析
準備條件：有足夠歷史資料、團隊具備分析能力
實施步驟：
1. 識別關鍵風險變數
2. 收集歷史資料建立分佈
3. 建立數學模型
4. 執行模擬分析
5. 解釋結果並制定策略
工具推薦：@RISK、Crystal Ball、Monte Carlo 模擬

關鍵提醒：常見問題的解答應該根據組織的具體情況進行調整，沒有一體適用的解決方案。建議在實施過程中持續學習和改善。

文件版本：v2.0
最後更新：2024年8月29日
文件負責人：專案管理辦公室
審核狀態：已審核通過

版本記錄：

v1.0 (2024-08-13)：初版發布，涵蓋完整風險管理流程與實務範例
v2.0 (2024-08-29)：重大更新，新增工具技術章節、最佳實務、常見問題解答，並完善目錄結構

主要更新內容：

新增第8章：風險管理工具與技術
- 企業級風險管理平台介紹
- 專案管理工具風險功能
- 定量與定性分析技術
- AI與大數據應用
新增第9章：風險管理最佳實務
- 組織層面最佳實務
- 專案層面最佳實務
- 技術實施最佳實務
- 產業特定最佳實務
新增第10章：常見問題與解答
- 風險識別相關問題
- 風險評估相關問題
- 風險應對相關問題
- 風險監控相關問題
- 工具與技術問題
改善既有內容
- 更新目錄結構，增加詳細子章節
- 補強實務案例與範例
- 優化文件結構與可讀性

適用範圍：本指引適用於各類型專案，特別是金融IT專案、大型系統開發專案，以及具有複雜風險特性的專案。

使用建議：

新手建議從第1-7章開始，循序漸進學習
有經驗者可重點參考第8-10章進階內容
實務應用時可直接使用第7章模板與範例
定期檢視更新，確保與組織實際需求對接

專案風險管理指引#

目錄#

1. 專案風險管理的定義與重要性#

1.1 定義#

1.2 風險管理的核心概念#

1.3 為什麼風險管理很重要？#

1.3.1 提高專案成功率#

1.3.2 優化資源配置#

1.3.3 增強利害關係人信心#

1.3.4 符合法規與合規要求#

1.4 金融 IT 專案的風險特性#

1.5 實務案例#

2. 風險分類#

2.1 技術風險#

2.1.1 定義#

2.1.2 常見技術風險類型#

2.1.3 識別指標#

2.2 管理風險#

2.2.1 定義#

2.2.2 常見管理風險類型#

2.2.3 識別指標#

2.3 外部風險#

2.3.1 定義#

2.3.2 常見外部風險類型#

2.3.3 識別指標#

2.4 合規風險#

2.4.1 定義#

2.4.2 常見合規風險類型#

2.4.3 識別指標#

2.5 實務案例#

3. 風險識別方法#

3.1 概述#

3.2 訪談法#

3.2.1 專家訪談#

3.2.2 利害關係人訪談#

3.2.3 訪談技巧#

3.3 檢核表法#

3.3.1 標準風險檢核表#

3.3.2 客製化檢核表#

3.3.3 使用技巧#

3.4 歷史資料分析法#

3.4.1 專案歷史資料#

3.4.2 組織經驗資料庫#

3.4.3 產業標竿分析#

3.5 其他識別方法#

3.5.1 腦力激盪法#

3.5.2 德爾菲法#

3.5.3 情境分析法#

3.6 風險識別的組織與文件化#

3.6.1 風險識別會議#

3.6.2 風險登錄表建立#

3.7 實務案例#

4. 風險評估#

4.1 風險評估概述#

4.2 風險機率評估#

4.2.1 機率評估方法#

4.2.2 機率評估考量因素#

4.3 風險影響評估#

4.3.1 影響評估維度#

4.3.2 綜合影響評估#

4.4 風險優先級矩陣#

4.4.1 風險矩陣建立#

4.4.2 風險分級管理#

4.5 定量風險分析#

4.5.1 預期貨幣價值（EMV）#

4.5.2 蒙地卡羅模擬#

4.5.3 敏感度分析#

4.6 風險評估工具與技術#

4.6.1 專家判斷法#

4.6.2 資料分析技術#

4.7 風險評估文件化#

4.7.1 風險評估報告內容#

4.7.2 風險登錄表更新#

4.8 實務案例#

5. 風險應對策略#

5.1 風險應對策略概述#

5.2 規避（Avoidance）策略#

5.2.1 定義#

5.2.2 適用情況#

5.2.3 常見規避方式#