重點摘要
- ISO 19650 把資訊需求分四層：OIR（組織）→ AIR（資產）／PIR（專案）→ EIR（交換），由抽象到具體層層推導。
- 每一項要廠商交的資訊，都應該答得出「支持哪個決策」—答不出來的要求就是浪費。
- 本文用「市立醫院新建工程」把四層實際推一遍：從「降低維運成本」的組織目標，一路推到「空調主機須含 12 項維運屬性、竣工交 COBie」的具體交換需求。
- 常見斷鏈：沒有 OIR 直接抄 EIR 範本、AIR 缺席導致竣工模型維運不能用、EIR 要求對不回任何用途、BEP 回應與需求鏈脫勾。
- 2026 年修訂草案保留這條需求鏈的骨幹，僅重新表述—推導邏輯不會白學（見文末）。
為什麼要分四層
業主對廠商提的要求（EIR）不應該憑空冒出，而要能追溯到組織的長期目標。ISO 19650 因此把資訊需求分成四層，由抽象到具體層層推導，確保「為什麼要這份資訊」有源頭、不浪費、也不遺漏。
核心問題：每一項要廠商交的資訊，最終是為了支持哪個營運/資產/專案決策？答不出來的要求，就是浪費。
四層資訊需求
| 層級 | 全名 | 由誰提 | 回答什麼問題 |
|---|---|---|---|
| OIR | 組織資訊需求 | 業主組織高層 | 組織營運要做什麼決策、需要什麼資訊？ |
| AIR | 資產資訊需求 | 業主／資產管理 | 維運這項資產，竣工要交什麼資訊？ |
| PIR | 專案資訊需求 | 業主專案端 | 本專案各決策點（里程碑）需要什麼資訊？ |
| EIR | 交換資訊需求 | 業主（發給廠商） | 對這次發包，廠商要交什麼、何時交、什麼格式？ |
推導關係
OIR（組織為何要 BIM／資料）
├─→ AIR（維運要什麼竣工資訊）──┐
└─→ PIR（專案決策點要什麼資訊）─┴─→ EIR（對廠商的具體交付要求）
└─→ 廠商以 BEP 回應
- OIR 是源頭：組織層級的營運目標（如「降低維運成本、用模型管資產」）。
- AIR／PIR 是轉譯：AIR 把營運目標轉成「維運要的竣工資訊」；PIR 把它轉成「專案每個決策點要的資訊」。
- EIR 是末端：把 PIR／AIR 落成對「這次發包廠商」的具體、可驗收要求—這就是廠商實際拿到的那一份。
- 廠商收到 EIR，以 BEP（BIM 執行計畫書） 逐項回應。
完整範例：市立醫院新建工程，四層走一遍
抽象的推導關係，用一個案例走過一次就懂了。假設你是某市政府衛生局，要新建一棟市立醫院。
第一層：OIR—組織要做什麼決策
衛生局（組織）的長期目標，跟這棟醫院有關的有三條：
- 全市醫療設施的維運預算逐年可控—需要各院設備的維護成本與更換週期資料來編列預算。
- 醫療量能調度有據—需要各院空間使用與病床配置資訊。
- 公共安全申報合規—消防、電力安檢申報需要設備清冊與檢查紀錄。
注意：這三條都是「組織的營運決策」，一個字都沒提 BIM。OIR 的正確寫法就是這樣—先講決策，再談資訊。
第二層：AIR—維運這棟醫院要什麼竣工資訊
資產管理端把 OIR 轉譯成「這棟醫院竣工時必須拿到的資訊」：
- 支持預算決策 → 機電設備清冊：每台設備的廠牌、型號、供應商、保固起訖、建議維護週期、預估更換年限。
- 支持空間調度 → 空間資訊：各房間編號、用途分類、面積、所屬科別。
- 支持安檢申報 → 消防與電力設備的位置、規格、檢驗週期屬性。
- 格式面 → 以上資訊須能匯入衛生局既有的 CAFM 系統，故要求 COBie 格式交付。
第三層：PIR—專案各決策點要什麼資訊
專案端（工程科）盤點這個專案的關鍵決策點，訂出各里程碑要的資訊：
- 基本設計核定：量體與法規檢討模型、面積計算表—支持「設計方向核定」決策。
- 細部設計核定：全專業整合模型、重要衝突歸零的衝突報告—支持「可以發包施工」決策。
- 施工中查核點：進度對照模型、變更設計反映—支持「估驗計價與變更核定」決策。
- 竣工驗收：竣工模型＋AIR 要求的維運資訊—支持「驗收與移交維運」決策。
第四層：EIR—落成對廠商的可驗收要求
把 AIR 與 PIR 彙整，寫成發包文件裡的具體條款，例如：
- 「空調主機（IfcUnitaryEquipment 等）須含以下 12 項屬性：廠牌、型號、額定功率、…、建議維護週期。竣工交付以 COBie 2.4 格式匯出，欄位對應表如附錄。」
- 「細部設計階段結束前，結構與機電間重要衝突須歸零，檢核報告以約定格式提交。」
- 「模型交付格式：原生檔＋IFC4；命名依附錄命名規則；座標依測量基準點。」
到這一層，每一條都具體、可驗收、有交期。廠商以 BEP 逐項回應：用什麼軟體、誰負責、怎麼自檢。
回頭驗證這條鏈
現在反問：「為什麼要求空調主機填 12 項屬性？」→ 因為 AIR 要設備清冊 → 因為 OIR 要編維運預算。每條要求都能一路答回組織目標，這就是一條健康的需求鏈。反過來，如果有人提議「順便要求全部管線都建到 LOD 400」，問一句「支持哪個決策？」答不出來—刪掉。
常見斷鏈問題
實務上這條鏈最常在四個地方斷掉：
| 斷鏈 | 症狀 | 後果 |
|---|---|---|
| 沒有 OIR，直接抄範本 | EIR 從別的專案複製貼上，要求跟自己組織的決策無關 | 廠商交了一堆沒人用的成果，業主付了錢還要花人力點收 |
| AIR 缺席 | EIR 只管設計施工，沒人問維運要什麼 | 竣工模型屬性欄空白或格式不合，CAFM 匯不進去，「BIM 到竣工為止」 |
| EIR 要求對不回用途 | 「LOD 越高越好」「屬性越多越好」式的要求 | 建模成本暴增、交付延遲，廠商報價灌水或消極應付 |
| BEP 與需求鏈脫勾 | 廠商 BEP 寫得漂亮，但沒有逐項對應 EIR 條款 | 審 BEP 時看不出缺漏，執行到一半才發現某需求沒人負責 |
自我檢查方法很簡單：拿你的 EIR，隨機抽五條要求，每條問「這支持哪個 AIR/PIR 用途？」；再拿 AIR/PIR 抽三條，問「EIR 哪一條落實了它？」。往上答不出來的是浪費，往下找不到的是遺漏。
對應台灣公共工程
台灣公共工程多半直接從 EIR（業主需求書） 開始談—它就是 ISO 19650 這條鏈最末端、廠商實際看到的文件。但好的業主需求書，背後應該答得出：
- 這些要求支持哪些維運用途（AIR）？竣工模型要不要 COBie、要哪些屬性？
- 這些要求對應哪個決策點（PIR）？例如「設計階段衝突歸零」支持的是設計核定決策。
把 EIR 往上接回 AIR／PIR／OIR，業主才知道哪些要求是必要的、哪些是多餘的，避免「要一堆模型卻沒人用」。
業主/經理的實作要點
- 由上而下訂需求：先問組織/維運要什麼（OIR/AIR），再訂專案與發包要求（PIR/EIR），不要一開始就埋頭寫 EIR 細節。
- 每條 EIR 可追溯：每個交付要求都對得回某個 AIR/PIR 用途；對不回的，刪掉。
- AIR 決定竣工交付：維運要的資訊（資產屬性、COBie）在 AIR 講清楚，竣工模型才不會交了卻不能用。
- 結構化的需求考慮機器可讀：屬性層級的 EIR 要求可進一步寫成 IDS 規格檔，讓交付驗收自動化。
一個預告：ISO 19650 的 2026 年修訂草案保留了這條需求鏈的骨幹，僅把表述對齊「利害關係人目的」，而 EIR 一詞未來將改稱 IPR—推導邏輯完全不變，你現在學的不會白費。詳見 ISO 19650 2026 修訂動態。
ISO 19650 的四層不是更多文件，而是一條「需求可追溯」的鏈—讓資訊交付有目的、可被信任。相關落地見 ISO 19650 資訊交付落地 與 資訊交付驗證。