重點摘要
- 風險登錄（Risk Register）把可預見的 BIM 風險事先列出、評估、指派負責人、訂應對措施，讓 BIM 經理從救火轉成防火。
- 常見風險分四類：技術、流程、人員、契約—多數專案的爆點其實在後兩類，卻最常只登錄前兩類。
- 用機率 × 衝擊矩陣分級（紅/黃/綠），紅色項目優先投入資源，別被一堆綠色風險淹沒。
- 風險登錄附於 BEP，是計畫書「如何管風險」的承諾；高風險項目綁進里程碑關卡查核。
- 節奏：開工會議（KOM）建初版，每次協調會議滾動更新、每個里程碑總檢，風險發生就轉成疑義（Issue）處理。
為什麼要有風險登錄
BIM 專案會出狀況：廠商建模能力不足、軟體版本不相容、交付延遲、模型品質不達標、人員流動。這些不是「會不會發生」而是「發生了怎麼辦」。風險登錄（Risk Register） 就是把這些可預見的風險事先列出、評估、指派負責人、訂應對措施，而不是等爆了才救火。
風險登錄是 ISO 19650 交付規劃的一部分—和 EIR/BEP/MIDP 一起，回答「資訊交付可能出什麼錯、怎麼防」。
風險登錄的標準欄位
| 欄位 | 說明 |
|---|---|
| 風險描述 | 具體事件（如「機電廠商無 Revit MEP 經驗」） |
| 類別 | 技術／流程／人員／契約 |
| 可能性 | 高／中／低 |
| 衝擊 | 高／中／低（對交付/品質/時程的影響） |
| 風險等級 | 可能性 × 衝擊（紅/黃/綠） |
| 應對措施 | 降低/移轉/接受/迴避，具體做法 |
| 負責人 | 具名追蹤者 |
| 狀態 | 開放／監控中／已關閉 |
寫風險描述的訣竅：寫成「事件」，不要寫成「主題」。「軟體」不是風險；「各廠商 Revit 版本不一致導致模型無法整合」才是風險—有主詞、有後果，才能訂應對。
常見風險類型：技術、流程、人員、契約
| 類別 | 典型風險 | 典型應對 |
|---|---|---|
| 技術 | 軟體版本不相容、IFC 匯出屬性遺失、CDE 權限設錯、座標基準不一致、硬體效能不足開不了整合模型 | BEP 訂死軟體版本與交付格式、首次交付驗座標、CDE 權限矩陣、試交付演練 |
| 流程 | TIDP 交付落後拖累整合、命名規則沒人遵守、衝突改了沒回寫模型、版本混亂用錯圖 | 里程碑關卡查核、交付前自檢表、衝突追蹤矩陣、工作中(WIP)→協作(Shared)→送審核定(Published) 狀態管制 |
| 人員 | 關鍵建模人員離職、廠商缺特定專業（如機電六系統）能力、業主端沒人看得懂交付成果、新人上手慢 | 投標資格要求、備援人力與交接文件、教育訓練、業主端 PCM 或委外審查支援 |
| 契約 | EIR 要求模糊導致驗收爭議、分包介面權責未定（開孔/套管誰建）、著作權與模型再利用權未約定、變更設計的模型更新費用沒編 | EIR 寫成可驗收條件、BEP 明定介面權責、契約載明智財與再利用條款、變更程序含模型更新 |
多數團隊的登錄表上滿滿是技術風險—因為那是工程師最熟的。但回顧實際出事的專案，爆點多半在人員與契約：人走了沒人接、驗收標準各自解讀。建登錄表時，四類都要強迫自己各列幾條。
風險評估矩陣：機率 × 衝擊
每條風險評兩個值：發生的可能性、發生後的衝擊。兩者相乘決定等級與處理優先序：
| 可能性 ＼ 衝擊 | 低衝擊 | 中衝擊 | 高衝擊 |
|---|---|---|---|
| 高可能性 | 黃 | 紅 | 紅 |
| 中可能性 | 綠 | 黃 | 紅 |
| 低可能性 | 綠 | 綠 | 黃 |
分級對應的管理動作：
- 紅色：立即訂應對措施並執行，每次協調會議追蹤，里程碑關卡必查，未緩解可影響放行。
- 黃色：訂好應對措施備援，狀態列「監控中」，定期檢視是否升級。
- 綠色：登錄即可，接受風險，不投入額外資源—敢於接受小風險，資源才留得住給紅色。
評估時常見兩個偏誤要提防：一是「什麼都評高」導致滿版紅色、失去鑑別度；二是把「衝擊」只想成時程—品質衝擊（竣工模型不能用於維運）與契約衝擊（驗收爭議）往往更貴。
台灣公共工程常見 BIM 風險
- 能力風險：廠商或分包缺特定專業（如機電六系統）建模能力 → 應對：投標資格要求、教育訓練、外包專業建模。
- 介面風險：結構開孔與機電套管對不上 → 應對：EIR/BEP 明定權責（開孔結構建、套管機電建，須可關聯）。
- 時程風險：TIDP 交付落後拖累整合 → 應對：里程碑關卡（gate）查核、緩衝期。
- 品質風險：LOD/屬性不達標 → 應對：自主檢查表、PCM 抽查、退件機制（見 資訊交付驗證）。
- 平台風險：CDE 權限設錯、版本混亂 → 應對：權限矩陣、工作中(WIP)→協作(Shared)→送審核定(Published) 流程。
與 BEP 的關係
風險登錄不是獨立文件孤島，它在 ISO 19650 的文件體系裡有明確位置：
- 投標階段：廠商在投標 BEP 的能力評估中，就該辨識自身交付風險（能力缺口、時程壓力）並提初版應對—這是業主評選時判斷「這家廠商知不知道自己會在哪裡跌倒」的重要線索。
- 簽約後：風險登錄附於執行版 BEP（品質/執行管理章），成為計畫書承諾「如何管風險」的依據；EIR 可直接要求「BEP 須含風險登錄並定期更新」。
- 執行中：BEP 是靜態承諾、風險登錄是動態儀表—BEP 寫「我們會這樣管」，登錄表記「現在哪裡有火苗、誰在看著」。
- 里程碑關卡：高風險項目在每個 gate 查核，未緩解可能影響放行（見 ISO 19650 資訊交付落地）。
滾動檢視的節奏
風險登錄最常見的死法是「開工建一版，然後再也沒人打開」。要活著，就要綁進既有會議節奏，而不是另開一個「風險會議」：
- 開工會議（KOM）：建初版登錄表，四類風險各至少列出主要項目，紅色項目當場指派負責人。
- 每次協調會議（雙週/每月）：固定議程保留五到十分鐘—紅色項目逐條過狀態，有沒有新風險要入表、有沒有舊風險可關閉。
- 每個交付里程碑：總檢一輪。里程碑是風險兌現的時刻—交付遲了、品質不達標，都在這裡現形；同時預判下一階段的新風險（如進入機電高峰期，介面風險升級）。
- 風險發生時：轉成疑義（Issue） 進入處理流程，登錄表上該項標記關閉並記錄實際處理結果—這些紀錄是下個專案登錄表的最好起點。
風險是「事前」，疑義是「事後」。登錄表管前者，疑義追蹤管後者，兩邊要能對得起來。
BIM 經理的實作要點
- 早建、滾動更新：專案啟動（KOM）就建初版風險登錄，每次協調會議/里程碑更新。
- 每項有負責人與應對：沒有負責人與具體應對的「風險」等於沒管。
- 分級聚焦：紅色（高可能×高衝擊）優先處理，不要被一堆綠色風險淹沒。
- 四類都要列：技術、流程之外，強迫檢視人員與契約風險—爆點常在你沒列的那兩類。
- 綁進既有節奏：不另開會，塞進協調會議固定議程，登錄表才活得下去。
風險登錄讓 BIM 經理從「救火」轉成「防火」—把可預見的問題在發生前就佈好應對。相關見 ISO 19650 資訊交付落地 與 資訊交付驗證。