標籤: Yes

在 CC3「BIM Uses & Processes」中，CIC 強調 BIM 應該被視為橫跨整個資產生命週期的資訊與流程框架，而不僅是某一階段的建模工具。在眾多階段銜接之中，由顧問設計模型過渡至承建商施工模型，是實務上最具爭議、亦最需要 BIM 經理主動介入管理的一環。

一、BIM經理處理的是合約文件中有關於BIM的地位

由顧問設計模型過渡至承建商施工模型，是實務上最具爭議

這個問題的本質從來不只是技術操作，而是牽涉三個層面的風險與安排：第一，是模型在合約中的定位與責任誰屬；第二，是設計方與施工方在軟件與平台上的相容性，以及資料傳遞過程中的損失與扭曲風險；第三，是施工方細化模型的同時，如何處理設計方持續更新所造成的衝突與浪費。以下會分別從這三個角度，說明 CCBM 應具備的理解與應對思路。

首先，從傳統合約架構來看，設計－招標－建造模式下，合約文件的核心是圖紙、規格書以及工程量清單。BIM 模型在這種結構下，多數只被視為協助理解設計意圖、進行協調與視覺化，以及作為工程量預估的輔助工具。問題在於，一旦 BIM 模型實際被用來支持招標和施工決策，它在法律上的地位如果仍未在合約中被清楚界定，就會立即出現責任灰色地帶。

從傳統合約架構來看，設計－招標－建造模式下，合約文件的核心歷來是圖紙、規格書以及工程量清單。

以模型錯誤為例，圖紙或規格書出錯時，可以透過 RFI 或 AI 之類的傳統機制去澄清與修正，並按合約條款調整責任與金額；但模型的情況不同。模型內往往包含暫定值或 dummy 資料，要在招標前徹底逐項檢查所有內容，在時間與成本上幾乎不可行。於是，便出現一連串關鍵問題：模型中的錯誤是否應被視為合約漏洞？可以完全依靠 RFI 或 AI 補救嗎？因模型錯誤引致的成本究竟由誰負責？如果合約又同時要求設計方提供 BIM 模型作為投標或施工依據，就更進一步引申出另一個層次：這個模型在詳度與資訊層面到底應達到什麼 LOD／LOIN，是否已在招標文件中明確？模型中的暫定資料或未完成部分是否有清晰標註與免責說明？從根本上說，設計方與施工方都不願意為「模型中所有錯漏」承擔責任，一旦缺乏明確規範，責任自然會變得模糊。

二、政府發展局大力推動的合約捆定模型

設計方與施工方都不願意為「模型中所有錯漏」承擔責任

發展局在 DEVB TC(W) No. 1/2025 中，正是嘗試回應這一類問題。該通告在第 12 段及 Annex 3、Annex 4 中，正式提出將設計 BIM 模型納入合約體系，同時釐清哪些模型內容具約束力、哪些只是參考。技術通告明確規定，對於 2025 年 4 月 1 日或之後招標、並採用 BIM 的公共工程合約，設計 BIM 模型須作為投標資料的一部分，其中與二維招標圖紙相對應的部分被視為 contractually binding，而超出圖紙所載、例如模型內額外的幾何或屬性資訊，原則上被視為參考。Annex 3 和 Annex 4 進一步透過標準條款說明，政府並不對這些 Reference BIM Contents 的準確性負責；如承建商選擇依賴這些內容，相關風險由承建商自行承擔；而模型內即使出現 clash 或 discrepancy，本身並不自動構成補償事件。同一套條款亦處理了模型檔案形式（native format或 open BIM 格式）哪一種作為具約束力的基準，另外，在 NEC 合約框架下，如果 BIM Contents 與其他合約文件不一致時，會以其他 Scope 文件（例如圖紙與規格）為準。

從 CCBM 的角度來看，這整套安排是在回應最初提出的幾個核心問題：如何避免出現「模型出錯誰埋單」的責任真空；如何界定哪些模型內容視為正式合約的一部分，哪些只是參考；以及如何在招標前，就在 Scope、PS 以及 Annex 3–4 這類文件中寫清楚，而不是等到工程進行期間才透過 RFI 或 AI 補救。對 BIM 經理來說，關鍵不是死記這些條文，而是理解技術通告想要解決的風險本質是合約定位與責任分配，並在項目早期的 EIR、合約草擬及 BEP 擬定階段，主動提醒業主方和合約團隊：模型的哪些部分應列為具約束力的 BIM Contents，哪些應被標示為 Reference；同時在 BEP 中對應這些條款，設計出具體的模型製作、審核與交付策略。在 CCBM CC3 面試裏，如果一方面能說清楚傳統以 drawing／spec 為主的合約制度在遇上 BIM 後出現的灰色地帶，另一方面又能引用 DEVB TC(W) No. 1/2025 第 12 段及 Annex 3–4 如何透過 Contractually Binding BIM Models 來處理相關問題，就能很有說服力地展示你既理解本地政策框架，又懂得把它轉化為實際流程設計與風險管理考慮，這正是 CC3 對 BIM Manager 視角的期待。

三、軟件與平台相容性 項目使用BIM的其中一大合約風險

其次，設計方與施工方之間的軟件與平台相容性，也是設計模型過渡施工模型時的一大關鍵。實務上，顧問設計團隊往往使用一套或多套 BIM／CAD 工具，例如 Revit、Archicad，或某些專用的結構、機電軟件；而承建商及其分判商在施工階段，可能改用其他施工詳圖工具、鋼筋或機電專用系統。若事前沒有規劃，檔案格式就容易在匯入與匯出過程中出現幾何扭曲、資料遺失或屬性無法正確對應的情況，施工方為了履行自身合約責任，最後往往被迫重建大量模型內容，造成成本與時間上的浪費。BIM 經理在 BEP 階段，理應主動處理這一部分，包括確認各方實際採用的軟件和版本，確定主要交換格式是使用原生檔案、IFC 還是其他開放格式，並了解各種選擇的限制。更重要的是，要在 BEP 中具體寫明設計模型將以何種格式交付給施工方，在交付時會保證哪些資料的完整性，哪些部分則預期由施工方基於自身施工責任重建或深化。這些都不是單純用技術可以解決的問題，而是事關風險管理與責任界線，若缺乏清晰約定，往往會在後期導致爭議。

施工方為了履行自身合約責任，最後往往被迫重建大量模型內容

最後，是設計持續更新與施工模型細化並行時，如何避免大量「白做」的問題。典型場景是，施工方基於設計模型開始進行細化，建立施工詳圖、臨時結構和安裝細節等，同一時間設計方因應優化、顧問要求或業主變更，持續更新設計模型。如缺乏良好的協調機制，施工方在模型上已投入的工作，很可能因設計方後續修改而需要重做，造成嚴重的返工和資源浪費。這裏對 BIM 經理的要求，是在 BEP 中主動提出並約定協調機制，例如設立凍結點和版本管理機制，明確某些區域或範圍在某一時間點後，不再接受大幅度設計改動，或者改動必須經過特定審批；在 CDE 和 BEP 中清楚定義版本命名與狀態，例如 WIP、Shared、Published，以避免施工方誤用仍在設計中的模型版本。同時，當設計方需要更新模型時，必須透過既定流程先通報受影響範圍，評估對施工模型和施工計劃的實際影響，如有必要，納入變更與商務處理機制。此外，最好在某些明確範圍內，約定由施工方完全接手模型維護，設計方只再就設計意圖與性能要求作確認，以免出現「雙方同時修改同一份模型」而缺乏統一協調的狀況。

總結而言，在 CC3 面試中，如果被問到「設計模型如何過渡到施工模型」或「模型在合約上的定位應如何處理」，可以先指出傳統以 drawing 和 spec 為主的合約模式在引入模型後產生的灰色地帶，說明模型錯誤與 dummy 資料的問題以及傳統 RFI ／AI 機制的局限，接着說明設計方與施工方在軟件相容性上的風險，以及你會如何在 BEP 中規劃交換格式與責任分工，最後再談設計持續更新與施工細化並行時，如何透過凍結點、版本管理、通報與影響評估、模型責任分界等安排，在 BEP 中提出具體方案。總結時，強調 BIM 經理的角色，是在項目早期協助釐清模型的合約定位與用途，設計出合理的流程與責任分工，從而減少後期因模型使用而產生的合約糾紛與返工。這樣的回答，能清楚顯示你不只是熟悉工具與流程名稱，而是真正在用管理層的視角思考 BIM 在整個合約與項目架構中的位置。

在準備 CCBM / CCBC 有關 BIM Software & Technologies 的核心能力時，考生很容易將重點放在「我用過哪些軟件」——例如 Revit、Navisworks、Civil 3D、Synchro 等。然而，從 CIC 的要求及 CCBM 過往面試題來看，考核重點其實更側重於：
你是否理解這些軟件在整個 BIM 流程中的角色、相容性、限制，以及它們如何支援數據驅動（data‑driven）的工程決策。

過往試題中，常見的相關問題包括：
「Can you introduce your familiar software and their function, and what distinguishes them?」
「What other software could be used in CDE? Which one used before?」
「How to coordinate between 3D and Revit?」

這些提問背後，都不是單純考你「認識多少軟件」，而是考你對軟件與技術的理解深度。

一、BIM 軟件的角色與相容性：不只是一套工具，而是整個系統的一部分

在專業應試及實務層面，介紹 BIM 軟件時，我會先回到一個基礎：任何單一軟件都只是一個「節點」，BIM 流程必然牽涉多套軟件之間的協同與相容性。

以常見情況為例，設計團隊可能在 Revit 或其他 modelling 工具中建立模型；協調會議時，使用 Navisworks 或類似平台進行 clash 檢查與視覺化；之後可能將模型轉化為 IFC，匯入其他分析軟件、4D 或 5D 工具，最後再把結果帶回 CDE 中，供各方查閱與決策。
在這種情景下，真正關鍵的並非「是否精通單一軟件」，而是你是否理解：

• 這些軟件在技術層面能否互相讀取檔案，是否支援開放格式（如 IFC、BCF、COBie 等）；
• 由於各家軟件的資料結構（data schema）不同，即使「表面上」相容，在實務上是否存在資訊遺失、幾何扭曲、屬性對應不完整等問題；
• 在項目早期，你是否就軟件與格式相容性作出清晰、前置的策略決定（例如：哪些情況使用原生檔案 (native file)，哪些情況使用 IFC 作為交換格式）。

能夠在面試中主動提及軟件相容性及格式策略，而不只是描述「我可以匯入／匯出」，會明顯顯示你已經從被指派工作的「使用者」提升至「流程設計」的管理者。

二、BIM 軟件的限制：理解「能做什麼」之前，先承認「做不到什麼」

很多工程人員在描述 BIM 軟件時，習慣強調它的功能與優勢，這似乎是老生常談。但在 CCBM 等級的能力要求下，重要的是：能否坦誠認識其限制。

以物理現象為例，現實世界中的超長鋼結構，在自重作用下會有輕微下墜或撓曲；但大多數 BIM 模型在軟件中，仍然以理想幾何表達，並不會自然體現這些物理變形。若將這類理想化模型直接視為「完全真實」，便可能在精細分析或施工工序設計時產生偏差。
同樣地，許多 BIM 軟件在處理大量元素或高細節模型時，會出現性能瓶頸：開啟時間過長、操作不流暢、協同困難等。這些都提醒我們：軟件對檔案容量大小、模型複雜度與細節，實際上存在一條「隱形上限」（hidden limitations）。

此外，某些軟件在參數化建模、API 擴充、開放格式標準支援等方面較為靈活，另一部分則相對封閉。這些差異既是功能上的限制，也是管理與採購決策的重要依據。
在面試或實務匯報中，能夠指出軟件限制，並解釋你如何在流程、標準或其他技術配合上作出補救與取捨，這正是業界對於CCBM 所期望的「專業判斷」。

三、工程人員為何需要學習 BIM 軟件：動力來自「數據與決策」，而非「單純可視化」

在推動 BIM 軟件應用時，一個經常被弱化的問題是：

工程人員學習這些工具的實際動機是什麼？
對多數工程師、測量師、施工管理人員而言，學習曲線陡峭的工具，若只能帶來「模型較好看」這種表面成果，很難構成長期動力。

真正能夠驅動工程人員投入時間學習的，是它們是否：

• 幫助更快、更準確地獲得工程量、成本及進度資訊；
• 減少重複工作、降低出錯，例如自動生成圖則、報表與清單；
• 讓使用者能利用模型與數據，更快作出工程決策，例如施工方案比較、臨時結構評估、施工順序模擬等。

當 BIM 軟件被明確定位為「數據與決策工具」，而不是純粹的「繪圖工具」，工程人員便會更容易理解其價值，學習動機會提高。這一點亦與 CCBM 面試中常見的「BIM awareness」類問題相呼應——考官希望聽到的是實際效率與決策改善，而非抽象口號。

四、軟件學習需要時間與策略：BIM 工具不是「即學即用」

另一個在培訓與面試準備時必須正視的事實是：BIM 軟件的學習有明確的學習曲線，不可能即學即用。
它不同於一般單一功能工具，而是將建模思維、資訊結構與協同流程同時綁定。這對工程人員的要求，遠高於「會用幾個按鈕」。

在規劃團隊學習與推行時，需認真考慮：

• 初階使用者需要多久時間，才能從「只會打開檔案」，過渡到「能整合資料」、以至「於模型及資料上留下設計及協調意見」；
• 何時、以何種形式引入標準化，例如命名規則、族／元件庫、模板等，以免每位使用者各自為政；
• 是否提供與實際項目緊密相關的情境練習，讓學習與日常工作直接連結；
• 團隊內是否有核心人員專責維護模板、族庫、標準及插件，以提升整體效能與一致性。

在 CCBM 能力水平上，理想的回答方式，是能夠說明你不僅知道如何使用軟件，還理解如何在組織內規劃學習與落地，承認學習曲線的存在，並提出相應對策。

五、軟硬件中的「數據驅動流程」：由模型到決策

CIC 在 Annex A 的多個章節中都強調：BIM 不只是三維幾何，而是一個以數碼資訊為核心的管理平台。BIM Software & Technologies 的真正價值，在於它們能否支援一個「數據驅動」（data‑driven）的流程，而非停留在視覺化層面。

從軟件角度看，BIM 工具負責建立、管理並輸出結構化資料；從硬件和系統角度看，各類伺服器、工作站、網絡與 CDE 才是這些數據得以被儲存、交換及分析的地方。當這兩者配合得當時，才有可能實現：

• 以模型與數據為唯一資料來源（single source of truth），減少重複輸入與版本混亂；
• 自動或半自動地生成工程量、成本估算、施工模擬報告等，支援管理層決策；
• 結合 IoT、感測器及 FM 系統，把營運階段的實際運行數據回饋到模型，形成持續優化的數據流。

在面試或專業文章中，若能清楚闡述你如何使用軟件與 CDE 建立這種「數據驅動流程」，而非只描述模型視覺效果，將更符合 CCBM 對 Software & Technologies 的預期層次。

六、結語：從軟件「工具」提升到 數碼化「系統」

總結而言，針對 BIM Software & Technologies 的核心能力，CIC 與 CCBM 並不僅僅要求考生列出熟悉的軟件名稱，而是期望你能夠：

• 將軟件放回整體 BIM 流程與 CDE 架構中理解；
• 認識並坦誠面對軟件在相容性、物理模擬、性能等層面的限制；
• 理解工程人員學習軟件的真正動力來自「數據與決策」，而非僅是「視覺效果」；
• 意識到 BIM 軟件存在實際的學習曲線，需要透過策略與標準化來支援團隊成長；
• 清楚說明軟硬件如何共同支援一個數據驅動的工程管理流程。

當你的敘述能從以上角度出發，BIM 軟件不再只是「我會用的工具清單」，而會呈現為一套你能設計、管理與優化的數碼系統，這正是 CCBM 對「BIM Software & Technologies」能力要求。

在準備 CCBM / CCBC 核心能力之一的 CC1：BIM Initiation 時，許多考生會集中在「BIM 定義」與「3D vs BIM」的區別。然而，若對照 CIC 的指引及過往 CCBM 面試題目，可以發現另一些同樣屬於基礎、卻經常被忽略的關鍵概念：
EIR（Exchange Information Requirements）、BEP（BIM Execution Plan）、以及 LOIN（Level of Information Need）。

這三個概念構成了 BIM 項目由 「資訊需求 → 實施計劃 → 資訊深度」 的基本框架，也是回答 CC1 類問題時，展示結構化思維的關鍵。

一、EIR（Exchange Information Requirements）：由「究竟需要什麼資訊」開始

1. 定義與角色

EIR（Exchange Information Requirements，資訊交換要求） 源自 ISO 19650 的資訊管理框架。在 CIC 的 BIM 標準及相關文件中，EIR 被視為業主方（Appointing Party）在工程項目中，對「需要什麼 BIM / 資訊交付成果」的正式說明文件。

EIR 通常涵蓋：

• 需要哪些資訊（內容及屬性）；
• 以什麼格式交付（例如 IFC、原生模型、COBie、報表等）；
• 於什麼時間點交付（階段、里程碑、審批節點等）；
• 由誰負責提供多少資訊（不同參與方的職責分工）。

2. 與 OIR / AIR / PIR 的關係

在 ISO 19650 架構下，各層次的資訊要求關係大致如下：

• OIR（Organisational Information Requirements）：組織層面的資訊要求；
• AIR（Asset Information Requirements）：資產層面的資訊要求；
• PIR（Project Information Requirements）：項目層面的資訊要求；
• EIR（Exchange Information Requirements）：
  將上述需求轉化為具體「需要何種資訊、由誰、於何時、以何種形式交換」的要求文件。

在 CC1 面試層次，能清楚說明：

EIR 是業主方用來定義 BIM / 資訊交付要求的文件，是後續 BEP 的主要依據之一，
並知悉 CIC 亦提供 EIR 的標準範本，已屬清晰的基礎回答。

二、BEP（BIM Execution Plan）：將 EIR 轉化為「可執行的計劃」

1. 定義與功能

BIM Execution Plan（BEP） 是說明項目團隊將如何滿足 EIR 的實施計劃文件。
它回答的關鍵問題是：

在明確客戶需要什麼資訊（EIR）之後，項目團隊將如何組織 人員、流程、工具及標準 去交付這些資訊？

在實務上，BIM 經理一般會：

1. 根據 EIR 起草 BEP 草稿；
2. 與各持份者（設計、承建、顧問等）磋商角色與責任分工；
3. 在提交業主方前，於項目團隊內部達成共識；
4. 待業主方審批後，按獲批 BEP 開展 BIM 相關工作；
5. 隨項目進展及需求變化，定期檢視與更新 BEP。

由於 BEP 會隨項目發展持續修訂，以保持與實際情況一致，因此常被視為一份 「活文件（live document）」。
在更新時，原則上不應超出 EIR 所規定的範圍與方向。

BEP 一般包括（但不限於）：

• 項目中各方在 BIM 方面的角色與責任；
• 將採用的 BIM 軟件、CDE 平台及相關技術；
• 模型分工（按專業、樓層、區域等）及協同機制；
• 模型命名規則、坐標系統及共享標準；
• BIM 用途（BIM Uses）及相應交付成果；
• 與 LOIN / LOD 相關的要求（於不同階段模型需達到的資訊深度）。

2. Pre-BEP 與 Post-appointment BEP 的區分

在 Annex A（3.3.1、3.4.1）中，CIC 將 BEP 分為兩個階段版本：

• Pre-appointment BEP（Pre-BEP）
  • 一般於招標或委任前提交；
  • 由潛在供應方說明「若獲委任，將如何運用 BIM 滿足 EIR」；
  • 性質較偏向「方案建議」；
  • 為業主方進行 投標評核（tender assessment） 的其中一項重要依據。
• Post-appointment BEP（BEP）
  • 委任確定後，由實際項目團隊根據 EIR 及最終合約條款進一步細化；
  • 包含更具體的執行細節、資源配置及實際時間表；
  • 為後續模型建立、協同及交付的主要操作依據；
  • 雖不一定單獨構成合約文件，但通常被視為具合約效力的關鍵參考文件之一。

在 CC1 的基礎層次上，能夠清楚表述：

EIR 是客戶的資訊要求，BEP 是團隊回應 EIR 的執行計劃；
Pre-BEP 是投標階段的建議版本，Post-appointment BEP 則是落實及執行版本。

已可充分展示對概念與實務關聯的理解。

三、LOIN（Level of Information Need）：「需要多少資訊」的精準定義

1. 從 LOD 到 LOIN 的演進

傳統上，行業常使用 LOD（Level of Development / Detail） 形容模型在不同階段應達到的細節程度。
然而，ISO 19650 引入 LOIN（Level of Information Need） 概念，目的是更準確地定義：

在特定使用目的之下，模型應具備哪些幾何及非幾何資訊。

2. LOIN 的核心思路

LOIN 的關鍵在於 「just enough information」，即：

為支援某一特定決策或 BIM 用途，所需的 最小但足夠 的資訊組合。

通常包括：

• 幾何層面：模型外形、細節程度、位置精度等；
• 非幾何層面：屬性、編碼、性能參數、維修資訊等；
• 文件 / 文件化資訊：說明書、證書、測試報告等相關文檔。

以 CC1 基礎層次而言，能夠闡明：

• LOIN 是在「項目階段 × BIM 用途」的角度下，規定模型所需的資訊深度；
• LOIN 的設定依據來自 EIR 和 BEP 中已界定的需求；
• 過高的 LOIN 會造成資源浪費，過低則可能導致資訊不足及決策風險。

已足以應對多數初階概念／認知類的面試問題。

四、三者之間的關係：由「需求 → 計劃 → 資訊深度 → 交付成果」的邏輯

從 CC1（BIM Initiation）的角度來看，理解 EIR、BEP、LOIN 之間的關係，比單純背誦定義更為重要。可用以下邏輯總結：

1. EIR（客戶提出：需要什麼資訊）
   • 業主方基於組織、資產及項目層面的目標，訂立資訊交換要求。
2. BEP（團隊回應：如何達成這些要求）
   • 項目團隊根據 EIR 制定 BIM 執行計劃，說明如何組織流程、工具、資源及協同方式。
3. LOIN（對每個用途與階段，定義資訊深度）
   • 針對不同項目階段及 BIM 用途，具體規定模型在幾何與資訊層面應達到的深度與完整性。
4. BIM deliverables（透過 BIM 模型與 BIM Uses 產生的交付成果）
   • 項目團隊依循 EIR、BEP 及 LOIN，利用 BIM 模型及相關流程，交付支援項目目標的各類成果。