從「上載模型」到「設計資訊流程」的能力轉型
在 CIC 的核心能力架構中，Digital Information Management, Collaboration & Integration 被視為高階能力，因為在CCBM的評核中，考生最難通過面試的一個課題，對應 Annex A 第 4 節的主題包括：
- 資料價值與管理；
- Common Data Environment（CDE）的選擇、設計與管理；
- 資料質量控制與審核。
在 CCBM 評核，考官不再只看你會否使用某一個 CDE 平台，而是看你是否能夠：
- 理解數碼資訊在整個 BIM 流程中的角色；
- 設計並管理 CDE 的結構與 workflow；
- 建立系統化的資料質量控制機制，而非純靠人手檢查。
本文聚焦三個層面：
- Digital Information Management 的核心概念；
- CDE 的設計與協同流程；
- 資料質量控制（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） 至少有三個必須掌握的要點：
- CDE 流程由四個狀態構成：WIP、SHARED、PUBLISHED、ARCHIVED；
- CDE 平台的三大核心功能：EDMS、Workflow Management、2D & 3D Coordination；
- 文件的 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 至少需要具備三個核心功能：
- EDMS（Electronic Document Management System）不只是存檔，而是要具備：
- 權限管理（誰可以上載、修改、批核、只讀）；
- 版本控制（每次修改都有完整版本歷史）；
- 狀態與 Meta Data 控制（Status / Approval / Revision Code，見下一節）；
- 可審計性（誰在何時上載了什麼、修改了什麼）。
- Workflow Management（流程管理）
- 能夠把文件／模型的狀態流轉（WIP → SHARED → PUBLISHED → ARCHIVED）映射成系統內的 workflow；
- 並對應到具體的負責人與審批步驟；例如：建築 discipline 的模型，由 BIM Coordinator 上載至 WIP；由建築 leader 在系統內完成檢查與簽核；系統自動把該版本標記為 SHARED，供其他 discipline 使用。
- 單純的雲端硬碟雖可分享檔案，但不具備原生的 workflow 管理與審批功能。
- 2D & 3D Coordination（協調與檢視）
- 能在瀏覽器或客戶端中直接檢視 2D 圖紙與 3D 模型，
- 支援多模型疊加、查詢屬性、量度、標註等；
- 能以 issue / mark‑up 形式記錄問題與決議，並與文件／模型版本關聯。
- 一般的檔案儲存平台並沒有針對 2D/3D BIM 協調設計的功能，
- 使用者需要另行下載、手動管理版本，增加錯用舊版本的風險。
- 能在瀏覽器或客戶端中直接檢視 2D 圖紙與 3D 模型，
總結一句：
CDE = EDMS + Workflow + 2D/3D Coordination
而不只是「雲端硬碟 + 手動命名」。
在 CCBM 面試中，當被問到「你認為什麼是 CDE？」或「為何不能用一般雲端儲存取代 CDE？」時，
如果你能清晰指出這三個功能，而不是只說「那個平台比較專業」，會顯得更有說服力。
文件 Meta Data 的標準化：Status Code、Approval Code、Revision / Version Code
在 CIC 標準中，CDE 內的每一份文件 / 模型，除了檔名與存放位置，Meta Data（後設資料） 同樣重要，尤其是：
- Status Code（狀態碼）用於表達文件目前在流程中的狀態，例如：
- S0 / WIP：仍在工作中，不供外部依賴；
- S1 / SHARED for coordination：用於協調；
- S2 / SHARED for information：供參考；
- S3 / PUBLISHED for tender / construction 等。
- 透過 Status Code，可以讓所有團隊快速判斷：「這份文件／模型現在可否作為決策或合約依據？」
- Approval Code（批核狀態碼）標示該文件是否已被相關負責人審批，以及審批結果：
- A：Approved；
- B：Approved with comments；
- C：Not approved 等。
- 在協調與審核流程中，Approval Code 有助區分：哪些文件可直接採用；哪些需在修正後才可再次提交。
- 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，你可以用這三點作為答題主軸：
- 四個狀態（WIP／SHARED／PUBLISHED／ARCHIVED）及其在信任與協同上的意義；
- 三項核心功能（EDMS、Workflow、2D & 3D Coordination），說明為何一般雲端硬碟不能視為 CDE；
- 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 的工作重點不同：
- 設計整體品質保證（QA）機制由 BIM Manager 制定「檢查做法與頻率」：例如每個 discipline 在提交至 SHARED 前須完成哪些檢查步驟；在重要里程碑（如招標前、施工前），需進行哪些層級的 Model Audit。確定哪些檢查可以由 BIM Coordinator 例行執行，哪些則屬於抽查或獨立審核層級。
- 透過抽查方式，確認機制有效運作 BIM Manager 不必、也不可能重做所有檢查工作，而是以抽查方式，檢視 BIM Coordinator 填寫的 checklist、issue log，以及實際模型狀況；若發現某類錯誤反覆出現，可能需要檢討建模標準、培訓內容或流程設計。
- 在適當情況下，引入自動化檢查工具 對於規則清晰、重複性高的檢查項目，BIM Manager 應考慮建議使用 rule‑based checking 工具或自動化腳本，以減少人手時間與主觀錯漏。例如：尺寸、樓層命名、屬性欄位是否填寫；某類元素是否均包含指定參數等。
- 向業主方負責，提交 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 的期待。
