分類: CIC BIM interview

從常見合約風險理解 BIM 經理在商業與合約上的角色

在 CCBM 的核心能力當中，Commercial & Contractual Aspects 是一個相對獨立而關鍵的範疇：CCBC 並未涵蓋這部分，而 CCBM 則被期望在 BIM 被納入合約框架時，能識別和處理隨之而來的爭議與風險。考官通常會透過這一環，判斷你是否真正具備管理層視角——能否清晰說出 BIM 在合約中常見的風險類型、這些風險為何會出現，以及作為 BIM 經理在其中可以做什麼、不能替誰作決定。

以下將從幾類典型的 BIM 合約風險切入，整理出一套適合在 CC5 作答時運用的思考框架。

---

一、合約條文不清晰：LOD／LOIN 與 BIM Uses 沒有被寫清楚

最常見亦最根本的風險，是合約條文對 BIM 的要求寫得過於粗疏。例如合約只寫「須提交 BIM 模型」或「須進行 clash detection、4D、cost estimation」，卻沒有說明模型需要具備什麼詳度（LOD／LOIN）、在什麼階段達到什麼資料完整度、每一個 BIM Use 最終要交付什麼具體成果。

這種情況在香港並不罕見。很多業主方會直接將 CIC 標準、DEVB BIM Harmonisation Guidelines 甚至技術通告的部分內容，原封不動附入合約，卻沒有根據個別項目的風險分佈、規模與營運重點作出調整。結果，所有條文看起來「很齊全」，實際上卻沒有針對性，亦沒有足夠細節支撐真正的執行，日後發生爭議時，各方很難就「是否達標」達成共識。

亦沒有足夠細節支撐真正的執行，日後發生爭議時，各方很難就「是否達標」達成共識。

理論上，BIM 經理有責任去解讀業主方的要求，並且透過 BEP 會議、kick-off meeting等場合，協助引導出「對這個項目而言，何謂合理的 BIM 要求與交付成果」。多數情況下， BIM 經理是由設計方或施工方聘用，他並不掌握業主內部的資訊策略與營運考量，也不可能擁有「為業主最終資訊適用性負絕對責任」的角色。換言之，就算 BIM 經理提出一個在技術與流程上都合理的 LOIN 要求或資料結構方案，亦未必能從業主營運角度判斷是否真正適合其長期資產管理使用。

因此，這裡的風險不只在於合約寫得不夠清楚，而是在於「BIM 經理被期望解決一個業主方才有能力做的資訊策略問題」。在面試中，能夠坦誠指出這個結構性限制，同時說明自己會如何盡力透過溝通與建議減少模糊地帶，會比單純說「我會跟從 CIC 標準」來得成熟。

非業主方的BIM 經理也不可能擁有

「為業主最終資訊適用性負絕對責任」的角色

---

二、Data Ownership：誰可以讀、改、用模型中的資料

隨着 BIM 模型愈來愈多被用作工程量計算、施工決策、FM 應用甚至與 IoT、Digital Twin 整合，一個必然浮現的問題是：模型內的數據，到底屬於誰？誰有權讀取、修改、複製、再利用？

在傳統圖紙體系中，雖然也存在「文件擁有權」與「使用授權」問題，但圖紙通常是以合約文件或設計成果身份存在，角色比較明確。BIM 模型則兼具多重身份：既是設計者的工作成果，也是承建商施工與優化的基礎，更可能是日後資產管理資料庫的起點。不同階段的不同版本模型，很可能由不同公司、不同團隊製作或更新。

若合約沒有清楚寫明資料擁有權與使用權限，例如是否允許業主在合約完結後，把模型交給第三方再加工、是否允許用於其他項目參考、是否可作為訴訟證據等，往往會在事後引起爭議。對 CCBM 而言，不一定要成為法律專家，但需要意識到「data ownership 並非自然而然屬於某一方」，而是必須透過合約、顧問協議或特別條款加以界定。

---

三、IP right：由圖紙到模型，知識產權歸屬的模糊地帶

知識產權是另一個在 BIM 世代被放大的議題。傳統上，設計顧問出的是圖紙與規格，這些文件所體現的創作和專業判斷，其 IP 權通常明確屬於設計方，除非合約另有規定，業主多數擁有使用權而非完全所有權。

但當設計圖紙被交給建模團隊（可能在設計公司內部，也可能是第三方），由其建立 BIM 模型，然後再由這個模型生成新的圖紙、明細表、3D 視圖等，問題就出現了：模型本身的 IP 權屬於誰？由模型再生產出來的圖紙，其 IP 權是否仍然只屬於原設計方，還是建模團隊也有部份權利？如果承建商或分判商在施工階段基於設計模型作了大量優化與調整，他們對更新後模型及衍生文件的 IP 權是否有所主張？

若沒有事先釐清，日後一旦涉及宣傳、比賽投稿、學術交流、甚至再利用於其他項目，就可能出現爭議。在面試談及這部分時，不需要給出「唯一正確答案」，但可以展示你理解「由 2D 圖紙過渡到 BIM 模型，使原有 IP 架構變得更複雜」，而這正是為什麼在 BIM 顧問協議、主合約或特別條款中，需要明確處理模型及其衍生物的 IP 權歸屬。

---

四、Liability：當錯誤資訊被另一方使用時，責任如何界定？

BIM 的一大特徵是「單一資訊來源」（single source of truth）的追求：不論是圖紙、清單、報表，理論上都來自同一套模型與資料。這雖然提高了一致性，但也放大了一個問題：若模型中的資料出錯，而另一方合理依賴該資料去製作圖紙、報告或施工決策，責任應如何分擔？

在沒有明確約定的情況下，很容易出現各方互相指責：提供資料的一方聲稱「模型只是參考，應以圖紙／BQ／Spec 為準」，使用者則認為「既然被放在 CDE 並標為 SHARED / PUBLISHED，就有權合理依賴」。

模型出錯只是一個事實，要成為申索基礎，通常還需要幾個條件同時成立，而這些條件往往要在合約或相關文件中事先約定。

---

在討論責任時，有一點必須說清楚：並不是所有模型中的錯誤，都自動構成申索的理據或賠償責任。 模型出錯只是一個事實，要成為申索基礎，通常還需要幾個條件同時成立，而這些條件往往要在合約或相關文件中事先約定。

可以用一個較具體的例子來說明。假設合約或 EIR／BEP 中已清楚訂明：甲方（例如設計方或業主代表）提供的「結構模型資訊」，將由乙方（例如承建商或造價顧問）用作「成本估算」之用。換言之，合約已明確記錄兩件事：第一，甲方有責任提供一定詳度及準確度的結構資訊；第二，乙方被授權且被期望合理依賴這些資訊來進行成本估算。

在這樣的前提下，如果後來發現甲方的結構模型存在明顯錯誤，而乙方又是基於這些錯誤資訊進行成本估算，導致工程價值偏差、投標失準或後期出現重大成本落差，那麼乙方便有相對清晰的理據主張：自己是「按合約約定合理依賴對方的 BIM 資訊」，因此甲方對因資訊錯誤所引致的損失，可能須承擔相應責任。

相反，如果合約並沒有明言某一方「必須」以模型作為成本估算、工程設計或施工決策的唯一或主要依據，模型只是被標示為「參考」，甚至合約中明確寫明「以圖紙或 BQ 為準」，那麼即使模型有錯，亦未必足以構成申索的充分理由。這時候，爭議的焦點就會轉移到：使用者是否已超出合約約定的合理依賴範圍，或者是否應自行進行額外核對。

所以，在 CCBM 面試談到 liability 時，重要的不只是說「模型錯誤會有風險」，而是要指出：究竟合約有否預先界定「哪一類 BIM 資訊被視為可以合理依賴、用於何種用途」，以及你作為 BIM 經理，會如何建議用 EIR、BEP、LOIN 及合約條款，把這些用途與責任關係寫清楚。只有在用途、責任和依賴關係被明確記錄下來時，模型錯誤才有機會成為具體而有根據的申索依據，而不是模糊的「有人畫錯模型」。

作為 BIM 經理的理解：
模型中的錯誤本身未必自動等同於某一方全責，關鍵在於合約如何界定模型的法律地位、各方合理依賴的範圍，以及是否已透過條文（例如 DEVB TC(W) No. 1/2025 所引入的「BIM Contents / Reference BIM Contents」概念）事前區分「具合約效力的模型內容」與「僅供參考的內容」。在面試中提及這些觀點，可以顯示你不單從技術看錯誤，而是從責任與風險的角度看。

---

五、PII：利用專業責任保險管理建模錯誤風險

既然 BIM 模型及其數據有機會被多方依賴，建模錯誤一旦造成損失，便可能被視為專業疏忽的一種形式。這正是「Professional Indemnity Insurance（PII）」在 BIM 環境下變得愈來愈重要的原因。

不論是設計顧問還是專門的 BIM 顧問，其工作內容若涉及提供專業判斷、設計建議或關鍵資訊，均可能被要求購買 PII，以保障因其專業過失而導致對方損失時的賠償能力。隨着 BIM 應用範圍擴大，不少保險產品亦開始明確涵蓋 BIM 模型錯誤或數據錯誤導致的風險。

在 CC5 的語境下，作為 BIM 經理，你不一定要熟悉保單細節，但至少要意識到：「當 BIM 顧問或建模團隊承擔一定程度的專業責任時，PII 是風險管理工具之一」，而不是只依賴合約上的免責條款。這同時亦提醒你，在建議 BIM 用途或數據應用時，要注意自己的專業建議可能帶來的責任範圍。

---

六、申索及爭議解決：最終仍回到合約與爭議機制

最後，即使各種標準與技術通告逐步納入 BIM 條款，當糾紛發生時，解決途徑仍然是「以合約為本」的爭議處理機制。無論是採用 CIC BIM Services Agreement、還是在主合約中加入與 BIM 有關的 special conditions of contract，若發生與模型、數據、責任相關的爭議，多數仍會被視為合約爭議或專業服務爭議，以既定的 dispute resolution 機制處理，例如爭議磋商、調解、仲裁或訴訟。

這意味著：BIM 本身並不創造新的爭議處理路徑，只是把更多技術與資訊層面的問題納入原有的法律／合約框架之中。因此，在 CC5 面試中，若能表達出這樣的理解——你明白所有上述風險最終都必須透過適當的合約起草、專業責任界定、保險安排及爭議機制來處理，而 BIM 經理的角色是在技術實務與商業合約之間提供清晰、專業的橋樑——會讓考官對你在商業與合約方面的成熟度留下深刻印象。

從「上載模型」到「設計資訊流程」的能力轉型

在 CIC 的核心能力架構中，Digital Information Management, Collaboration & Integration 被視為高階能力，因為在CCBM的評核中，考生最難通過面試的一個課題，對應 Annex A 第 4 節的主題包括：

• 資料價值與管理；
• Common Data Environment（CDE）的選擇、設計與管理；
• 資料質量控制與審核。

在 CCBM 評核，考官不再只看你會否使用某一個 CDE 平台，而是看你是否能夠：

• 理解數碼資訊在整個 BIM 流程中的角色；
• 設計並管理 CDE 的結構與 workflow；
• 建立系統化的資料質量控制機制，而非純靠人手檢查。

本文聚焦三個層面：

1. Digital Information Management 的核心概念；
2. CDE 的設計與協同流程；
3. 資料質量控制（Data Quality Control & Assurance）。

---

一、Digital Information Management：先理解「數據本身」的價值與限制

根據 Annex A（4.1），Digital Information Management 的起點並不是某個平台，而是對「資料本身」的理解，包括：

資料作為資產（data as asset）：

BIM 模型中的幾何與屬性，並不只是為了出圖，而是會被重複用於協調、造價、施工模擬、維修管理等不同環節；每一次在資料結構、命名、屬性定義上的決定，都會影響日後能否順利重用。跨系統互通的前提：不同 BIM 軟件、分析工具、FM 系統、IoT 平台的資料結構與格式各不相同；無論是 IFC、COBie、BCF，還是自家定義的資料格式，本質上都是為了建立可預測的「資料對應關係」，以支援跨系統傳遞。軟件在資訊管理上的限制：大部分 BIM 軟件的資料結構是為建模與協同而優化，未必適合長期作為企業級資料庫；單靠某一套 BIM 工具，往往不足以支撐資產全生命週期的所有資訊需求。

在 CCBM 面試中，若被問及「Digital Information Management」或「資料標準化」，建議回應不止停留在「用某平台／某 format」，而是示範你理解：

為何要先界定資料結構與標準，
才能談 CDE、互通與後續自動化。

---

二、CDE（Common Data Environment） 至少有三個必須掌握的要點：

1. CDE 流程由四個狀態構成：WIP、SHARED、PUBLISHED、ARCHIVED；
2. CDE 平台的三大核心功能：EDMS、Workflow Management、2D & 3D Coordination；
3. 文件的 Meta Data 標準：Status Code、Approval Code、Revision / Version Code。

在 CCBM 面試中，若能圍繞這三點清楚表達，會比單純回答「我們用某某 CDE 平台」更能展現你對 CC4 的理解深度。

---

四個狀態（WIP / SHARED / PUBLISHED / ARCHIVED）：

CDE 的流程骨幹，而非單純資料夾名稱

根據 CIC BIM 標準，CDE 並不只是「雲端硬碟」，而是一套以 四個狀態 為骨幹的流程管理框架：

• WIP（Work in Progress）各團隊仍在內部編輯、未完成審核的工作區。模型與文件在這個區域中仍然可以大幅修改，不應被其他團隊視為可依賴的依據。
• SHARED　經過該 discipline 的負責人（leader）檢查與批准後，確認已達到約定的 LOIN／格式／完整度要求，
• PUBLISHED　一般對應「已正式發行」的交付物，例如：Issued for Tender / Construction / Information 等。
• ARCHIVED已被較新版本取代，但需保留作溯源或合約追蹤的版本。透過 ARCHIVED，可以在爭議或回溯分析時查明：

BIM 經理的責任 不只是知道這四個狀態，而是要在 BEP / CDE 規則中清楚規定：

• 什麼情況下可以由 WIP 推到 SHARED？
• 誰有權批准？
• 各團隊在日常工作中，只能從哪個狀態撈取資料作為協調與決策依據？

在面試中，如果你可以解釋：

「我不會讓團隊直接用別人 WIP 的模型／文件作為決策依據，
而是只採用對方 leader 已批准、升級到 SHARED 或 PUBLISHED 的版本，
這樣可以在協同上建立明確的信任基線。」

會比單純說「我們有用 CDE」具體得多。

---

為何 Google Drive / OneDrive 不能視為 CDE？

CDE 的三項核心功能：EDMS、Workflow、2D & 3D 協調

在項目中，有時有人會問：「既然我們已有 Google Drive / OneDrive，為何還需要專門的 CDE 平台？」從 CIC 標準與實務角度來看，關鍵在於 CDE 至少需要具備三個核心功能：

1. EDMS（Electronic Document Management System）不只是存檔，而是要具備：
   • 權限管理（誰可以上載、修改、批核、只讀）；
   • 版本控制（每次修改都有完整版本歷史）；
   • 狀態與 Meta Data 控制（Status / Approval / Revision Code，見下一節）；
   • 可審計性（誰在何時上載了什麼、修改了什麼）。
2. Workflow Management（流程管理）
   • 能夠把文件／模型的狀態流轉（WIP → SHARED → PUBLISHED → ARCHIVED）映射成系統內的 workflow；
   • 並對應到具體的負責人與審批步驟；例如：建築 discipline 的模型，由 BIM Coordinator 上載至 WIP；由建築 leader 在系統內完成檢查與簽核；系統自動把該版本標記為 SHARED，供其他 discipline 使用。
   • 單純的雲端硬碟雖可分享檔案，但不具備原生的 workflow 管理與審批功能。
3. 2D & 3D Coordination（協調與檢視）
   • 能在瀏覽器或客戶端中直接檢視 2D 圖紙與 3D 模型，
     • 支援多模型疊加、查詢屬性、量度、標註等；
     • 能以 issue / mark‑up 形式記錄問題與決議，並與文件／模型版本關聯。
   • 一般的檔案儲存平台並沒有針對 2D/3D BIM 協調設計的功能，
     • 使用者需要另行下載、手動管理版本，增加錯用舊版本的風險。

總結一句：

CDE = EDMS + Workflow + 2D/3D Coordination
而不只是「雲端硬碟 + 手動命名」。

在 CCBM 面試中，當被問到「你認為什麼是 CDE？」或「為何不能用一般雲端儲存取代 CDE？」時，
如果你能清晰指出這三個功能，而不是只說「那個平台比較專業」，會顯得更有說服力。

---

文件 Meta Data 的標準化：Status Code、Approval Code、Revision / Version Code

在 CIC 標準中，CDE 內的每一份文件 / 模型，除了檔名與存放位置，Meta Data（後設資料） 同樣重要，尤其是：

1. Status Code（狀態碼）用於表達文件目前在流程中的狀態，例如：
   • S0 / WIP：仍在工作中，不供外部依賴；
   • S1 / SHARED for coordination：用於協調；
   • S2 / SHARED for information：供參考；
   • S3 / PUBLISHED for tender / construction 等。
   • 透過 Status Code，可以讓所有團隊快速判斷：「這份文件／模型現在可否作為決策或合約依據？」
2. Approval Code（批核狀態碼）標示該文件是否已被相關負責人審批，以及審批結果：
   • A：Approved；
   • B：Approved with comments；
   • C：Not approved 等。
   • 在協調與審核流程中，Approval Code 有助區分：哪些文件可直接採用；哪些需在修正後才可再次提交。
3. Revision / Version Code（修訂／版本碼）
   • 清楚標示文件／模型由初版到各次修訂的版本序列（如 Rev 0, Rev 1, Rev A, Rev B 等）；有利於：回溯某一時點實際使用的是哪一版；在合約或爭議情境中，證明某工作是依據當時最新而已批准的資料進行。

對 CCBM 而言，掌握 Meta Data 的意義在於：

• 你可以設計與管理一套 可機器判讀、可篩選、可報表化 的文件狀態系統；
• 你作為管理人，可以隨時透過 CDE 或報表查到：
  • 某一 BIM Use（如 clash coordination、出圖、handover）目前使用的是哪一批資料；
  • 哪些文件仍在 WIP、尚未審批；
  • 哪些已批准可作為正式依據。

在面試中，若你能主動提到 Status / Approval / Revision Code，並解釋：

「這些 Meta Data 並非形式，而是讓 CDE 變得可篩選、可追蹤、可管理的關鍵。
我可以透過它們監測整個 BIM 流程現時停在哪個步驟、卡在哪位負責人手上。」

便能很好地展示你對 CC4 的實務理解，而不僅是工具層面的認識。

---

整體而言，若在 CCBM 面試被問及 Digital Information Management 或 CDE，你可以用這三點作為答題主軸：

1. 四個狀態（WIP／SHARED／PUBLISHED／ARCHIVED）及其在信任與協同上的意義；
2. 三項核心功能（EDMS、Workflow、2D & 3D Coordination），說明為何一般雲端硬碟不能視為 CDE；
3. Meta Data 標準（Status／Approval／Revision Code）如何支撐整個流程的可見性與可管理性。

這樣的回答深度與結構，非常符合 CC4 對 CCBM 的期望。上載模型」，會顯得偏淺；
若能描述自己在實際項目中如何參與 CDE 結構與 workflow 的設計與執行，則更貼近 CCBM 的期待。

---

三、資料質量控制：從 CIC 的 Model Checking Steps 到 BIM Manager 的 QA 機制設計

在 CIC 的 BIM 標準中，Model Checking / Model Audit 是多個具體檢查步驟。

一般包括：

• Visual Check（視覺檢查）：以肉眼檢視模型的整體合理性，例如是否有明顯幾何錯亂、遺漏、位置明顯錯置等。
• Interface Check（介面檢查）：檢查不同系統／元素之間的介面關係，例如樓板與牆體收口、結構與建築包層、機電設備與建築結構開孔等。
• Model Integrity Check（完整性檢查）：檢視模型是否存在孤立元素、重疊元素、未關聯的物件，或屬性資料是否出現明顯空白／不一致的情況。
• Standard Check（標準符合性檢查）：檢查模型是否符合既定的建模標準與命名規則，例如：族／型號命名、樓層代碼、分類編碼、屬性名稱等。
• Doc Check（文件對應檢查）：比對模型與圖紙、規格書等文件是否一致，確保模型未偏離已批准的設計文件。
• Model Audit（模型審核／審計）：屬於更高層次的檢查，會綜合上述各項結果，並以報告形式呈現，

在實務上，執行這些日常檢查工作的人是 BIM Coordinator，例如：

• 使用檢查工具或手動方法，按 Visual / Interface / Integrity / Standard / Doc Check 等步驟進行；
• 在每次檢查後，填寫對應的 checklist 或紀錄表格；
• 針對發現的問題，在 CDE 或 issue 管理工具中建立記錄、分派責任人並跟進。

而在 CCBM 的層次，BIM Manager 的工作重點不同：

1. 設計整體品質保證（QA）機制由 BIM Manager 制定「檢查做法與頻率」：例如每個 discipline 在提交至 SHARED 前須完成哪些檢查步驟；在重要里程碑（如招標前、施工前），需進行哪些層級的 Model Audit。確定哪些檢查可以由 BIM Coordinator 例行執行，哪些則屬於抽查或獨立審核層級。
2. 透過抽查方式，確認機制有效運作　BIM Manager 不必、也不可能重做所有檢查工作，而是以抽查方式，檢視 BIM Coordinator 填寫的 checklist、issue log，以及實際模型狀況；若發現某類錯誤反覆出現，可能需要檢討建模標準、培訓內容或流程設計。
3. 在適當情況下，引入自動化檢查工具　對於規則清晰、重複性高的檢查項目，BIM Manager 應考慮建議使用 rule‑based checking 工具或自動化腳本，以減少人手時間與主觀錯漏。例如：尺寸、樓層命名、屬性欄位是否填寫；某類元素是否均包含指定參數等。
4. 向業主方負責，提交 BIM Audit Report　作為管理層與業主的主要對口人，BIM Manager 需要：定期或在重要里程碑，整理 BIM Audit Report；報告現時團隊所使用模型與資訊的整體質量狀況；說明已執行的檢查步驟（可附上 BIM Coordinator 的 checklist 摘要）、發現的主要問題類型、已採取的改善行動。這份報告不僅是「查錯清單」，更是向業主方展示「BIM 質量是被系統性管理與審核」的重要憑證。

在 CCBM 面試中，若被問到：

• 「你如何確保模型與資料的質量？」
• 「你在項目中如何處理 BIM audit？」

一個具深度的回答應該能涵蓋：

• 你理解 CIC 所建議的 model checking steps（visual、interface、integrity、standard、doc check、model audit）；
• 你如何把這些步驟分配給 BIM Coordinator 執行，並透過 checklist 和 CDE 記錄；
• 作為 BIM Manager，你如何設計 QA 機制、以抽查方式監控其運作，
  以及在需要時引入自動化工具，最後向業主方提交 BIM Audit Report。

這樣能清楚顯示你已從「執行檢查的人」提升為「設計與管理整個質量保證機制的人」，完全符合 CC4 對 CCBM 的期待。

---

在設計 BIM Uses & Processes 時，一個關鍵問題是：誰負責什麼？
CIC 在 Annex A 多次提到「key personnels and their roles and responsibilities」，CC3 面試題亦經常從責任分工角度切入。

本文聚焦於：

• 在 BIM 流程中，不同角色應具備的能力與責任；
• 這些責任其實「即使沒有 BIM」亦必須存在，只是 BIM 令其更透明與可追蹤。

一、關鍵人物的角色 與 BIM衍生的額外責任

---

在設計 BIM Uses & Processes 時，一個無可迴避的核心問題是：誰負責什麼？CIC 在 Annex A 多次提到「key personnels and their roles and responsibilities」，不少 CC3 面試題亦是從責任分工的角度切入。真正要討論的，其實有兩層：一方面是在 BIM 流程之中，不同角色應具備哪些能力與承擔哪些責任；另一方面是要意識到，這些責任其實在沒有 BIM 的年代已經存在，只是 BIM 令它們變得更透明、更可被追蹤，而不是憑空創造或抹走責任。

這些責任其實在沒有 BIM 的年代已經存在，只是 BIM 令它們變得更透明、更可被追蹤，而不是憑空創造或抹走責任。

在沒有 BIM 的年代，專業角色的責任早已被行業共識及合約實務所界定。建築師和工程師負責設計意圖與合約圖則的準確性，確保方案符合法規和專業標準；承建商負責施工方法、安全管理、品質控制和工期履行；測量師與商務團隊負責工程量計算、變更處理與結算；業主代表或項目經理則負責整體項目的管理與重大決策。BIM 的出現，並沒有改變這些根本責任，而是把原本以二維圖則和文件呈現的資訊，升級成為三維加上結構化數據的形式，使溝通更立體、錯漏更容易被提前發現、決策的依據更完整。在 CC3 面試回答時，應避免給人一種「因為有 BIM，責任就由某一方轉移到另一方」的印象，更準確的說法應該是：BIM 是協助各專業更好地履行原有責任的工具和框架，它可以減少誤解與重工，卻不會自然消除或產生新的責任。

二、流程設計包括什麼?

若從流程設計的角度看，在 CCBM 的層次，「流程」不應只停留在 BEP 裏幾句高層次的描述，而是要具體到可以把一個 BIM Use 拆解成一連串可以列出、可以追蹤的事件。無論是 clash coordination、4D 模擬，還是出圖與條例檢核，每一個 BIM Use 實際上都是由一系列具體步驟組成，每一個步驟都應該有清楚的負責人和觸發條件，而不是籠統地說「由 BIM team 處理」或「交由顧問／承建商負責」。以碰撞檢查為例，如果只說「合併模型、做 clash、開會協調」，顯然是不足夠的。比較成熟的做法，是先定義誰在什麼時間點、從哪一個 CDE 資料夾收集最新模型並負責合併，誰根據事先商定的規則設定 clash 條件並執行檢查，誰負責對檢查結果進行初步分類和分流（例如區分 true clashes 和 digital clashes），然後再按照既定準則把問題自動或半自動分派給各個 discipline，由各自團隊在指定期限內回應和修正；只有那些未能在這個層次解決、或者具有高風險和跨界影響的 clashes，才會被升級至正式協調會議中處理。

只有那些未能在這個層次解決、或者具有高風險和跨界影響的 clashes，才會被升級至正式協調會議中處理。

這樣一來，每一個事件的責任人便清晰可見。如果某一個步驟長期沒有完成，CDE 或 issue 管理工具中的狀態顯示就會停留在該階段。作為 BIM 經理，你打開系統便可以看到流程目前卡在什麼位置，是哪一個角色或團隊尚未行動，從而有針對性地與該負責人討論阻滯原因，協助排除資源、資訊或決策上的瓶頸，而不必只是一味催促「大家快一點」。單有一張流程圖是不足以支撐這種管理的，真正關鍵是把流程映射到 CDE 或 issue 工具中，讓每一個步驟都有對應的狀態標籤，例如「待提交」、「待檢查」、「待回應」、「待確認」，再配合明確的 owner 與期限，才有可能做到可視化與可監控。

在 CCBM 面試時，如果你在回答 BIM Uses & Processes 的問題時，僅僅停留在「我們有 clash coordination」、「我們做 4D」、「我們用 BIM 出圖」，考官很難判斷你是否真的具備管理層視角。相反地，如果你能主動談到：你會為每一個 BIM Use 寫出具體的事件順序，為每一步指定清晰的責任人與狀態，並透過 CDE 或 issue 工具與簡單報表，主動監察工作目前停在哪一個環節、卡在誰身上，然後有計劃地與對方討論如何推進，這樣便能讓人感受到，你不只是懂得流程名稱，而是真正懂得設計和管理一條可以執行、可以度量、可以調整的 BIM 流程。這正是 CC3 想測試的能力所在。真正懂得 設計和管理一條可以執行、可監控的 BIM 流程，這正是 CC3 想測試的能力。

在 CC3 的評核，考官關心的不是「你知不知道有哪些 BIM 用途」，而是你是否懂得 為這些用途設計合理的 workflow 與協調機制。以下三個最常見在面試題目的 BIM Uses 為例：

• 碰撞檢查（Clash Detection）；
• 施工模擬（4D Simulation）；
• 圖紙生成（Drawing Generation）及其延伸 (Building code checking and validation)

在 CC3 的評核中，考官關心的從來不是你能否背出多少種 BIM 用途，而是你能否為這些用途設計出合理的工作流程與協調機制。以最常出現在面試題目的三個 BIM Uses 為例，每一項都牽涉到明確的步驟設計、責任分工和更新機制，而不只是操作某一套軟件。

如果你收到一個充滿 clashes 的模型，你會如何處理？

以碰撞檢查為例，面試中非常常見的一條問題是：「如果你收到一個充滿 clashes 的模型，你會如何處理？」在 CCBM 的層次，單純回答「我會用某軟件做 clash detection」是遠遠不夠的。BIM 經理真正需要處理的，是如何透過與各團隊溝通。

一、BIM經理需要處理，如何定義碰撞問題。

先定義何謂「clash」，確立分類與優先次序，再把電腦產出的龐大 clash 報告，轉化為一份真正需要協調的問題清單。實務上，通常會先把 clashes 分成兩類：一類是對實際施工構成真正困難或安全風險的 true clashes，例如預製牆體與梁柱位置重疊、管線在預留洞口以外與結構衝突、機房內設備布置令維修空間不足等；另一類則是純屬建模方法或幾何表達造成的 digital clashes，例如現場一體澆築的牆與樓板在模型中看起來互相穿插，或者某些細節因建模方式而被軟件標記為碰撞，實際上只需建模團隊參考圖紙稍作修正即可。

在此基礎上，BIM 經理還要事先為碰撞分流設計一套清晰的規則，而不是讓所有問題都湧入大型協調會議。通常會先根據系統類別和主次關係作初步分類，例如在結構與機電發生碰撞時，往往以結構為相對固定的基準，先由 MEP 團隊提出繞避方案，再由結構工程師判斷是否接受；建築裝飾與機電衝突時，則可能先由建築或室內團隊檢視能否調整天花或裝飾方案。對於已確認為 true clashes 的情況，原則上應先由較具調整彈性的一方（例如 MEP）提出解決建議，只有在建議方案對結構安全、功能或合約要求有影響時，才上升到為需要多方出席的協調會議，避免每個細節都要整隊人坐在會議室內等候決定。

二、為何需要承認及接受 digital clashes 的存在?

至於純屬 digital clashes 的問題，則宜直接交由相關 discipline 的建模團隊按圖則及建模標準修正，不必佔用正式協調會議的時間，只需在必要時匯報整體清理狀況即可。若能在 clash report 或 CDE 中，為每一項問題標明負責團隊、優先級和預期完成日期，BIM 經理便可以在宏觀層面管理協調資源，而不是親自陷入每一個技術細節之中。在面試回答時，如果你能說明自己會如何根據系統主次和可調整性預先定義「哪一類 clashes 應由哪個團隊先處理」，以及你會如何在報告和流程中加入負責人、優先級和處理方式，讓大部分問題在會議之外被有效解決，考官就會看到你不只是懂得用工具找 clashes，而是懂得設計與管理整個協調機制。

BIM 經理還要事先為碰撞分流設計一套清晰的規則，而不是讓所有問題都湧入大型協調會議。

施工模擬（4D simulation）則是另一個常被使用的 BIM 用途。4D 的價值並不在於製作一段好看的施工動畫，而在於能夠及早看出施工順序上的衝突與風險，支援暫建設施佈置、吊運及場地物流安排、現場空間佔用規劃，並成為現場團隊與管理層溝通施工策略的有力工具。要令 4D 真正發揮作用，BIM 經理首先要確保資料收集是完整而準確的：整體工程計劃（master programme）和短期滾動計劃是否已有清晰的工作分解結構，哪些構件或區段需要納入 4D 模擬，哪些可以適度簡化處理，這些都要先講清楚。其次，是模型畫法與施工邏輯的一致性。如果模型在建模時把整層樓板視為單一物件，而實際施工是按區域、分段澆築，那麼即使 programme 寫得再好，也很難建立有意義的時間連結。最後，是更新機制的問題。若 4D 只在投標或開工前做一次，之後不再隨工程計劃更新，其決策價值會迅速降低。理想情況下，應在 BEP 中寫明 4D 模型與 master programme 的更新頻率（例如每月一次，或每當關鍵里程碑改動時），同時界定由誰維護 programme、由誰負責更新 4D 連結，以及 4D 模擬的結果應如何反饋回現場計劃和風險管理中。在面試談及 4D 時，若你能指出成敗關鍵在於前期資料與建模結構是否適配，以及是否建立了制度化的更新安排，而不只是「我們曾經做過 4D」，會讓人更相信你有 CCBM 層級的流程視角。

由誰負責更新 4D 連結，以及 4D 模擬的結果應如何反饋回現場計劃和風險管理中。

三、圖紙生成 及 建築規範自動化檢驗

至於圖紙生成與自動化條例檢查，則可以從「圖紙要求 → 模型資訊 → LOIN」這條鏈來理解。圖紙生成是 BIM 最普及的用途之一，但在 CC3 的評核裡，重點不在於你會按哪個按鈕出圖，而在於你是否明白：圖紙上被要求顯示的資訊，會反向決定模型在幾何與屬性層面必須具備什麼內容；而這些要求應該如何在 EIR、BEP 和 LOIN 裡面被寫清楚。舉例來說，為 BD 入則而生成圖紙時，法規和技術通告已經列明了入則圖必須顯示的資訊，例如各樓層面積、淨高、消防設施配置、逃生路線和距離等。如果打算以 BIM 模型為唯一圖紙來源，這些資訊就必須在模型內完備且以適當的資料結構儲存，否則到出圖階段，只能靠大量手工標註補回，既失去「single source of truth」的優勢，也大大增加出錯機會。因此，BIM 經理有責任在 BEP 和 LOIN 中預先界定：為支持 BD 入則，模型在何時、由誰為哪一部分元素提供甚麼屬性和標註基礎資料。

如果打算以 BIM 模型為唯一圖紙來源，這些資訊就必須在模型內完備且以適當的資料結構儲存

同樣地，當項目計劃使用 BIM 進行 building code checking and validation（無論是全自動還是半自動），檢查規則其實都是建立在模型中的幾何與屬性之上，例如高度、淨距、面積、走火距離等。這意味着，在啟動自動化檢查之前，模型必須已在指定階段達到相應的資訊深度，而且要清楚指定由哪一個專業或哪一個角色負責輸入和驗證相關資料。這些內容不能只以「LOD 300」之類籠統描述帶過，而是要在 LOIN 中具體化，寫出每一類元素在特定用途和階段下的資料要求。

總結來說，無論是碰撞檢查、施工模擬，還是圖紙生成與自動化條例檢查，真正的關鍵從來不在於工具名稱，而是在於：在用途發生之前，你是否已經清楚界定了「何時、由誰、在模型中提供哪些資訊」，並將這些規則寫入 EIR、BEP 和 LOIN 之中。只有這樣，到了要實際使用這些 BIM Uses 時，才不會後知後覺地發現模型缺乏必要資料，或協調與決策機制無法有效運作。這正是 CCBM 在 CC3 中希望看到的能力：你不僅知道有哪些 BIM 用途，更懂得為每個用途設計一條完整且可執行的 workflow，並對其中的責任分工與時間節點有清晰掌握。