疑義失控的典型劇本

廠商用 Excel 記、業主用 email 追、監造在 LINE 上問——三個月後開會，同一個問題有三種狀態、沒有一個有結案證據。疑義管理的目標很單純：每個問題單一編號、單一狀態、單一時鐘，任何人隨時能回答「還有幾件沒關、最老的一件卡多久了」。

三段式描述：讓疑義可處理

一句「這裡怪怪的」不是疑義。可處理的疑義固定三段：

  1. 現況：客觀描述（位置＋圖說版本＋截圖）——「B1F 機房，結構版 v3 與風管模型 vC2，樑下淨高 2.1m」。
  2. 影響：不處理會怎樣——「低於需求書 2.4m 淨高要求，影響設備吊裝」。
  3. 要求行動：希望誰、在何時前、做什麼——「請結構於 3 個工作日內確認樑深可否調整，或由機電改管」。

三段缺一，收件方就要花一輪往返把資訊補齊——時效就是這樣被吃掉的。

四級嚴重度與時效 KPI

等級定義回應時效（台灣常見）
緊急影響即時施工或安全1 個工作日
重要影響里程碑交付或多專業介面3 個工作日
一般單一專業可處理、不影響時程7 個工作日
資訊週知性質、無需行動不計時效

時效是需求書 6.6 與契約 KPI 的量測對象：逾時件數與平均回應天數會進審查管理的風險儀表。要能量測，前提是每筆疑義都有「提出日、期望回覆日、實際回覆日」三個日期欄——用對話軟體追議題之所以失控，就是因為沒有時鐘。

狀態流：Open → In Review → Closed →（Reopen）

  • Open：提出並指派責任方，時鐘開始走。
  • In Review：責任方已回覆處理方案，等提出方驗證——「回了」不等於「解了」。
  • Closed：提出方確認解決（附複驗證據）才能關閉——誰提出、誰關閉，責任方不能自己關自己的單。
  • Reopen：結案後復發即重開並保留歷史——Reopen 率高代表「假解決」，是審查要盯的訊號。

平台與工具的分工

疑義的發生地多半在協作平台（ACC Issues、BCF 交換），治理紀錄則要進專案管理層：本平台的疑義模組（執行期 M5）記錄三段式內容、嚴重度、時效與狀態流，逾時自動進待辦與風險儀表；BCF 格式交換見ACC 平台基礎。BEP 第八章要承諾的正是這套「與業主端一致的單一流程」——廠商內部另起一套系統，資訊必然不同步。

自檢四題

  1. 隨機抽一筆疑義：三段式齊全嗎？有三個日期欄嗎？
  2. 結案是否由提出方確認（而非責任方自關）？
  3. 逾時件數現在能不能「一鍵撈出來」？
  4. Reopen 的紀錄有沒有保留（假解決抓得到嗎）？

延伸閱讀