chundev
日期：2026-05-01 對象：PM / 業務 / 主管，不需要懂程式
把政府採購案的規劃表（PBS）做成「源頭」，一處填好，從標前的服務建議書、履約期程、報價估算，到執行期的履約紀錄表、完工測試表、驗收報告，整套 Word 文件包自動長出來。一個 6 大項的採購案，8 份對外／對內 docx 從同一份規劃表推導；下個類似案件，新做一份履約紀錄表只要 5 分鐘調整內容。
PRINCE2 全名 PRojects IN Controlled Environments，是英國政府訂的專案管理方法論，1996 年發布，現在全球廣泛採用，特別在歐洲、亞洲的政府機關專案幾乎是標配。
它跟 PMP（美式）的最大差別：
| 對比 | PMP（美式） | PRINCE2（英式） |
|---|---|---|
| 核心關注 | 流程與技術 | 產品交付與品質 |
| 適用 | 各行各業 | 特別適合結構化、有合規要求的專案（政府、IT、營造） |
| 方法論性質 | 知識體系（PMBOK） | 實作方法論（直接告訴你「怎麼做」） |
| 臺灣常見場景 | 民間 IT、新創、跨國 | 政府標案、公部門、ISO 27001 體系 |
因為政府採購案的本質就是「交付明確的產品」：
PRINCE2 的核心方法 PBS 跟政府採購結構天然對齊，不需要硬套；而且 PRINCE2 強調的「風險登錄、決策紀錄、品質驗收」等管理機制，本來就是政府專案要交的文件。
PBS = Product Breakdown Structure（產品分解結構）
PRINCE2 的核心方法。把專案拆成「要交付的產品」，而不是「要做的工作」。
很多人混淆 PBS 和 WBS（Work Breakdown Structure）：
| PBS | WBS | |
|---|---|---|
| 問題 | 要交付什麼東西？ | 要做什麼工作？ |
| 角度 | 名詞（product） | 動詞（task） |
| 順序 | 先做 | 後做 |
| 範例 | 「NAS 36 臺」、「驗收報告」 | 「下單」、「上架」、「寫報告」 |
PRINCE2 強調先想清楚要交什麼，再想怎麼做。先 PBS，後 WBS。這個順序在政府採購案特別重要 — 因為合約寫的是「交付物」，不是「工作」。
某政府機關 IT 採購續約案，PBS 第一層拆出來：
專案：某政府機關網路儲存伺服器及資安軟體汰換暨續約案
├── 交付產品（specialist products）
│ ├── NAS 硬體 36 臺
│ ├── 全國巡迴安裝服務（30 站）
│ ├── 零信任軟體訂閱（3 年）
│ ├── Fidelis 續約 + 駐點（3 年）
│ ├── CyberArk 續約（1 年）
│ ├── BigFix 續約 + 月派送（3 年）
│ └── BPM 平台同等品 + 舊資料移轉（3 年）
└── 管理產品（management products，每案必含）
├── 風險登錄冊
├── 決策紀錄
└── 產品流程圖
每個交付產品再描述：內容（composition）、品質條件（quality criteria）、驗收方式、依賴關係。
把 PBS 變成「文件自動化的源頭」 — 一處填，多處生。
1. 收到 RFP / 招標草案
↓
2. 對話填 PBS（30 分鐘）
↓
3. PBS 自動展開出文件包：
↓
┌─────────────────┬─────────────────┐
│ 標前對外 │ 標前對內 │
├─────────────────┼─────────────────┤
│ 服務建議書骨架 │ 報價人天估算書 │
│ 履約期程規劃書 │ ⚠ 機密 │
│ 應交付項目一覽表 │ │
└─────────────────┴─────────────────┘
↓（得標後）
┌─────────────────────────────────────┐
│ 執行期文件 │
├─────────────────────────────────────┤
│ 履約紀錄表（規格符合聲明書） │
│ 完工測試表（30 站每站一份） │
│ 驗收完整性報告 │
│ 月例會紀錄（駐點 36 次） │
└─────────────────────────────────────┘
改一處，所有相關文件都重新長出來。
同一份 PBS 可以推導出對外（給客戶看）和對內（給業務 / 主管看）兩種文件，自動脫除內部術語。
| 對內 | 對外 |
|---|---|
| 含 PBS product id（P-NAS-HARDWARE） | 直接寫「NAS 硬體 36 臺」 |
| 含人天分項與利潤公式 | 只給總額 + 範圍 |
| 含風險加成 | 隱藏 |
| 含內部 milestone 代號 | 改成 M1, M2… |
標楷體、橫式表格、政府編號（壹、貳、參／一、二、三／（一）（二）（三））、全形符號（～：（）等）— 這些公文細節都自動處理，不用每份文件再 review 一次。
下個類似案件不用從上一案 copy 改 .docx。新案接到後，PBS 一填，文件包就跟著出。樣式不漂移、術語不混雜。
某政府機關 IT 採購續約案，6 大交付項：
履約期限 6 個月（180 天）。30 個外點巡迴安裝。
| 階段 | 文件 | 受眾 | 頁數 |
|---|---|---|---|
| 標前對外 | 服務建議書骨架（11 章節） | 投標主交付 | 11 |
| 標前對外 | 履約期程規劃書（含視覺化甘特圖） | 客戶 / 業務 | 4 |
| 標前對外 | 應交付項目一覽表 | 提前對齊承辦科 | 2 |
| 標前對內 | 報價人天估算書（⚠ 機密） | 業務部門 / 主管 | 4 |
| 執行期 | 規格符合履約紀錄表 | 進貨點交驗收 | 2 |
| 執行期 | 完工測試表（單站，30 站每站一份） | 各外點完工驗收 | 3 |
| 執行期 | BPM 移轉完整性與並行測試報告 | BPM 驗收 | 5 |
| 執行期 | 月例會紀錄（駐點累計 36 次） | 機關內部 | 1-2 |
| 項目 | 傳統做法 | PBS 驅動 |
|---|---|---|
| 接新案做文件 | 從上一案 copy 改 .docx | PBS 改完文件自動跟著生 |
| 樣式漂移 | 不同 PM 不同習慣，視覺不一 | 公司樣式統一 |
| 對外混入內部術語 | 常見，事後才發現 | 工具自動擋 |
| RFP 規格 ↔ 佐證文件對應 | 靠 PM 記憶 | PBS 內建追溯 |
| 新人接手 | 要 reinventing | 看 PBS 就懂全案結構 |
| 改規格 | 翻好幾份 docx 改 | 改 PBS，相關文件一起重生 |
RFP 看完 → 對話 30 分鐘 → PBS 出來 → 標前文件包跟著生
不用再「投標前一週熬夜寫服務建議書」。
每方拿到的是「他需要看的版本」，不會看到別人不該看的內容。
規範要求改了 → 履約紀錄表自動跟著更新。 新外點加入 → 完工測試表自動多 N 份。 不需要手動同步多份 docx。
每案的設計選擇（驗收方式、佐證文件、風險識別、決策理由）都記在 PBS 裡，是公司的 knowledge base，下個案參考用。離職人員的隱性知識變成顯性結構。
最有價值的副產品：拿「應交付項目一覽表」標前就去和承辦科對齊「驗收會看哪幾份證據」 — 避免驗收日才發現我方準備的不被接受。這在最低標案件特別重要（規格寫死後不可改）。
/pm-init 起 PBSworking/<客>/<案>/docs/templates/ 找PRINCE2 PBS 把採購案的本質講清楚了：交付產品，不是做工作。先想交什麼，再想怎麼做。
「文件自動化」的關鍵不是 Word 模板，是「源頭結構化」。模板只解決排版，源頭結構化才能解決「規格-期程-驗收」的對應關係。
對內 vs 對外要分清楚。同一份規劃可推不同術語層級的文件。對外不能有 P-NAS-HARDWARE 這種內部代號 — 客戶看到會覺得是「廠商內部備忘」，傷害專業形象。
中文公文細節是品味，不是迷信。標楷體下半形 ~ 跟全形 ～、半形 : 跟全形 ： 視覺差很大。一份「對外文件」的專業度從這些細節判斷。
提前跟客戶對齊驗收項目 是最低標案件最大的風險管理。應交付項目一覽表不是事後產，是標前就要拿去找承辦科溝通。
想看技術實作細節（helpers 怎麼設計、踩過哪些坑、self-verify SOP），等之後另外寫一篇「工程篇」。本篇給 PM / 業務看，先到這裡。