為什麼要分四層

業主對廠商提的要求（EIR）不應該憑空冒出，而要能追溯到組織的長期目標。ISO 19650 因此把資訊需求分成四層，由抽象到具體層層推導，確保「為什麼要這份資訊」有源頭、不浪費、也不遺漏。

核心問題：每一項要廠商交的資訊，最終是為了支持哪個營運/資產/專案決策？答不出來的要求，就是浪費。

四層資訊需求

層級全名由誰提回答什麼問題
OIR組織資訊需求業主組織高層組織營運要做什麼決策、需要什麼資訊？
AIR資產資訊需求業主／資產管理維運這項資產，竣工要交什麼資訊？
PIR專案資訊需求業主專案端本專案各決策點（里程碑）需要什麼資訊？
EIR交換資訊需求業主（發給廠商）對這次發包，廠商要交什麼、何時交、什麼格式？

推導關係

OIR（組織為何要 BIM／資料）
   ├─→ AIR（維運要什麼竣工資訊）──┐
   └─→ PIR（專案決策點要什麼資訊）─┴─→ EIR（對廠商的具體交付要求）
                                          └─→ 廠商以 BEP 回應
  • OIR 是源頭：組織層級的營運目標（如「降低維運成本、用模型管資產」）。
  • AIR／PIR 是轉譯：AIR 把營運目標轉成「維運要的竣工資訊」；PIR 把它轉成「專案每個決策點要的資訊」。
  • EIR 是末端：把 PIR／AIR 落成對「這次發包廠商」的具體、可驗收要求——這就是廠商實際拿到的那一份。
  • 廠商收到 EIR，以 BEP（BIM 執行計畫書） 逐項回應。

對應台灣公共工程

台灣公共工程多半直接從 EIR（業主需求書） 開始談——它就是 ISO 19650 這條鏈最末端、廠商實際看到的文件。但好的業主需求書，背後應該答得出：

  • 這些要求支持哪些維運用途（AIR）？竣工模型要不要 COBie、要哪些屬性？
  • 這些要求對應哪個決策點（PIR）？例如「設計階段衝突歸零」支持的是設計核定決策。

把 EIR 往上接回 AIR／PIR／OIR，業主才知道哪些要求是必要的、哪些是多餘的，避免「要一堆模型卻沒人用」。

業主/經理的實作要點

  • 由上而下訂需求：先問組織/維運要什麼（OIR/AIR），再訂專案與發包要求（PIR/EIR），不要一開始就埋頭寫 EIR 細節。
  • 每條 EIR 可追溯：每個交付要求都對得回某個 AIR/PIR 用途；對不回的，刪掉。
  • AIR 決定竣工交付：維運要的資訊（資產屬性、COBie）在 AIR 講清楚，竣工模型才不會交了卻不能用。

ISO 19650 的四層不是更多文件，而是一條「需求可追溯」的鏈——讓資訊交付有目的、可被信任。相關落地見「ISO 19650 資訊交付落地」與「資訊交付驗證」。