單元難度：★★☆☆☆
預計學習時間：10min
前置知識：
本單元使用範例下載
目的：
建立一個系統化、週期性的內部品質控管 (Internal QC) 流程，確保 BIM 模型在提交給外部合作夥伴或業主之前，已經過團隊內部的仔細檢查與修正，以達到專案所要求的品質標準。
學習目標：
- 理解一個典型的模型審查週期所包含的角色與主要活動。
- 了解在模型審查流程中，資訊（模型、報告）如何在不同角色之間流動。
- 掌握一個完整的「檢查 → 回饋 → 修正 → 再檢查」的品質控管循環。
說明：
此單元所呈現的是一個標準化的「品質保證 (Quality Assurance, QA)」工作流程示意圖。在 BIM 專案中，模型的品質直接影響到後續的圖說產出、碰撞檢查、數量計算等所有應用。因此，不能等到最後一刻才來檢查模型，而必須在專案過程中，定期（例如：每週或每月）進行系統性的審查。
這個流程圖將參與者分為兩個主要角色：
- 專案團隊 (Project Team)： 實際負責建模與設計的團隊成員。他們是模型的「產出者」。
- 檢核團隊 (Review Team)： 可能是專案的 BIM 經理、資深設計師或指定的品質控管人員。他們扮演的是獨立的「審查者」角色，負責從客觀的角度檢查模型是否符合標準。
整個流程就是一個在這兩個角色之間不斷循環的「 PDCA Cycle」：
- Plan (計畫)： 制定檢查的標準與時程。
- Do (執行)： 專案團隊進行建模與自我檢查。
- Check (檢核)： 檢核團隊進行審查並提出報告。
- Act (行動)： 專案團隊根據報告進行修正。
這個週期性的流程，確保了模型品質能夠在專案過程中持續地、迭代地提升。
學習內容
一. 內部模型審查流程說明
觀念介紹
- 本流程以建模者（專案團隊）跟審查者（檢核團隊）兩個角色示範，專案團隊要有一套標準自檢機制作為第一道關卡，檢核團隊除了檢核專案團隊是否依照標準執行，另外還要檢核是否有疏漏及依照專業判斷未考量的點。兩者的檢核過程都需要被記錄、追蹤跟管理，作為存證依據、品質量化依據及分析過程有無異常。
重點觀念
- 角色分離的重要性： 由獨立的「檢核團隊」來執行審查，可以避免「球員兼裁判」的盲點。實際的建模者往往會對自己的作品有先入為主的看法，而第三方審查能提供更客觀、更全面的視角。
- 文件化的回饋： 所有的審查意見都應該以「書面報告」的形式提出，而非口頭溝通。這不僅讓修正的依據更明確，也為專案留下了可供追溯的品質管理紀錄。
- 迭代循環是核心： 模型品質的提升不是一蹴可幾的。透過定期、反覆的「檢查-修正」循環，才能逐步消除錯誤，讓模型的成熟度（LOD）與可靠度（LOI）穩步增長。
- 自檢是第一道防線： 在將模型提交給他人審查之前，建模者自己進行的「自檢」是至關重要的第一步。這可以過濾掉許多低級的、明顯的錯誤，節省檢核團隊的時間，讓他們能專注在更深層次、更複雜的問題上。
- 延伸參考文件
- [延伸內容]
常見問題
Q1 為什麼這個流程需要分為「專案團隊」和「檢核團隊」兩個角色？讓建模的人自己檢查不是更有效率嗎？
A：區分角色的主要目的是為了確保審查的客觀性與品質。建模者在長時間專注於自己的工作後，很容易產生思維慣性或視覺盲點，忽略掉一些錯誤。由一個獨立的、未直接參與該部分建模的團隊或人員來進行檢查，更能以一個全新的、更宏觀的角度來發現問題。雖然看似多了一道溝通程序，但從整個專案的品質控管角度來看，這是更可靠且更專業的做法。
Q2 在 Week 2/4，檢核團隊提出的「審查報告」通常會包含哪些內容？
A：一份有效的審查報告通常會包含：
- 問題清單： 逐一列出所有發現的問題。
- 問題描述： 清楚說明每個問題的內容、發生的位置（例如：提供元素 ID、視圖截圖）。
- 嚴重性等級： 標示每個問題的嚴重程度（例如：嚴重、一般、建議）。
- 建議解決方案： 提出可能的修正方向或需要哪個專業團隊來協調。
- 責任歸屬： 指明該問題應由哪位團隊成員負責修正。
例如，一份干涉檢查報告 (Clash Report) 就是一種非常典型的審查報告。
Q3 這個範例是以一個月（4 週）為週期，是否所有專案都應該遵循這個時間線？
A：不一定。這個時間線只是一個「範例」。審查的頻率應該根據專案的規模、複雜度、進度以及合約要求來靈活調整。
- 在設計初期或概念階段，變動較快，審查週期可能可以拉長。
- 在設計發展或施工圖階段，跨專業協調最為密集，審查週期可能需要縮短至每週一次。
- 在專案接近交付里程碑時，也需要進行密集的全面審查。
最重要的是建立一個定期且可預期的審查節奏，讓團隊所有成員都能有所依循。