# 八階段顧問診斷工具表 / Eight-Stage Consulting Toolkit Templates

> Apache License 2.0 · Author: Morris Lu (盧業興) · Tiger AI 虎智科技
> Source: <https://github.com/MorrisLu-Taipei/GenAI-Consulting-Methodology-Toolkit>

本檔提供八階段顧問方法論的 **可直接使用工具表**：訪談題庫、盤點表、Reference Model 對應、矩陣、worksheet、checklist。每個 Stage 對應 1-5 個工具與一組 Output KPI。顧問可直接複製到 Notion / Google Docs / Word 開始用。

This document provides ready-to-use **toolkit templates** for the eight-stage consulting methodology: interview question banks, inventories, reference-model mappings, matrices, worksheets, and checklists. Each stage maps to 1-5 tools and a set of Output KPIs.

> **核心思維**：以營運模式轉型為中心，透過 80/20 原則精準投放資源，建立可持續進化的能力體系。
>
> **方法論主軸**（Rosemann BPM 學派）：As-Is 真相 → 國際標準座標 → 產業卓越特徵 → 客觀差距 → 核心問題 → 階段性可吸收目標 → 多階段藍圖 → 變革落地。

| Stage | 名稱 | Output KPI |
| --- | --- | --- |
| 1 | As-Is Snapshot 現況掌握 | 現況評估報告 (Assessment Report)、真實營運流程圖 (As-Is Process Maps) |
| 2 | Reference Model Alignment 標準模型引入 | 標準能力缺口檢核清單、營運結構完整度分析 |
| 3 | Best Practice Integration 產業最佳實務對標 | 產業標竿營運模型圖、卓越能力特徵定義 |
| 4 | Gap Analysis 差距分析 | 差距矩陣 (Impact × Effort) — **不作為風險評估** |
| 5 | Problem Definition 結論與核心問題定義 | 高階問題定義聲明 (Executive Problem Statement) |
| 6 | Benchmarking & Phased Goals 標竿對照與多階段目標設定 | 階段性目標定義與驗收標準 (Stage Gate Criteria) |
| 7 | To-Be Design 未來藍圖設計 | 分階段未來營運模型圖 (To-Be Operating Model)、未來流程圖 |
| 8 | Implementation & Change 執行導入與變革治理 | 轉型路徑圖 (Transformation Roadmap)、變革管理計畫、價值追蹤矩陣 |

---

## Stage 1：As-Is Snapshot / 現況掌握

> **目的**：透過訪談與數據盤點資訊流、決策流，識別人工密集與瓶頸節點。**回答「現在到底發生什麼事」，不評論、不建議。**
>
> **Output KPI**：現況評估報告 (Assessment Report)、真實營運流程圖 (As-Is Process Maps)。

### Tool 1.1 訪談問題庫 / Interview Question Bank (40 問)

#### A. 主管層 (CEO / COO / CIO) — 12 問

1. 您對 AI 在公司的「最理想未來樣貌」是什麼？/ What is your ideal future state of AI in the company?
2. 您過去 12 個月看到哪些 AI 成功與失敗案例？
3. 公司目前最大的營運痛點是什麼？AI 能不能幫上？
4. 您最擔心 AI 帶來什麼風險？(資安、合規、員工抗拒、ROI 不明)
5. 您願意每年投入多少預算在 AI 轉型？
6. 公司有 AI 推動的負責人嗎？(若無，誰可以承擔？)
7. 您覺得我們已經是 L1-L5 的哪一級？為什麼？
8. 您希望 12 個月後達到哪一級？
9. 哪個部門最先導入 AI 對公司影響最大？
10. 您有打算自建 AI 團隊還是依賴外部顧問？
11. 公司董事會 / 母公司對 AI 投資態度？
12. 您最想從這次顧問專案得到什麼具體成果？

#### B. 部門主管層 — 14 問

13. 部門目前的關鍵 KPI 與痛點？
14. 員工每天有多少時間花在重複性工作？
15. 哪些工作是「換誰來做都一樣」可以 AI 化？
16. 哪些工作極度仰賴特定資深員工？
17. 部門目前用了哪些 SaaS 工具？整合狀況？
18. 員工是否私下使用 ChatGPT / Claude？頻率？資料邊界？
19. 您部門的「黃金 SOP」有哪些？是否已書面化？
20. 跨部門協作最大障礙是什麼？
21. 您希望 AI 解放您的哪一段時間？
22. 您部門員工對 AI 的態度？(熱衷 / 中性 / 抗拒)
23. 部門新人 onboarding 多久？AI 能加速嗎？
24. 部門決策慢在哪？資料找不到還是溝通慢？
25. 過去 90 天有哪些值得記錄的 AI 嘗試？
26. 您部門有沒有「我希望可以自動化但一直沒空做」的願望清單？

#### C. 操作員 / 一線員工 — 14 問

27. 您每天最重複的 5 件工作是什麼？
28. 您每天會打開哪幾個系統 / 工具？
29. 哪些資料您找了很久都找不到？
30. 您會私下用 AI 工具嗎？用哪一個？做什麼？
31. 您覺得 AI 哪些地方幫上忙、哪些幫不上？
32. 寫報告 / email / 提案時 AI 能加速多少？
33. 您怕 AI 取代您的工作嗎？(若怕，怕哪部分)
34. 您希望主管別再叫您做哪些事？
35. 上次出錯的原因？AI 能避免嗎？
36. 您覺得自己的「核心專業」AI 應該不能取代的是？
37. 同事用 AI 哪些地方做得比您好？
38. 您願意花多少時間學 AI？
39. 哪些事情您「人工做反而比 AI 做更快」？
40. 給 AI 一個願望，您希望它幫您解決什麼？

> **使用方式**：訪談每場 60-90 分鐘；主管 12 題、部門 14 題、操作員 6-8 題（精選）。錄音 + 摘要 + 編碼。

---

### Tool 1.2 AI Usage Inventory / AI 使用盤點表

| # | 部門 / Dept | 目前 AI 工具 | 頻率 | 使用人數 | 是否經許可 | 機敏資料風險 | 月支出 | 備註 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | Marketing | ChatGPT Plus (個人帳號) | Daily | 8 | ❌ | High (品牌資料) | NT$24,000 | 私人信用卡 |
| 2 | Sales | Copilot for Office | Weekly | 15 | ✓ | Medium | NT$45,000 | 公司採購 |
| 3 | IT | Claude.ai (自己用) | Daily | 3 | ❌ | Medium (程式碼) | NT$9,000 | 私人帳號 |
| ... | ... | ... | ... | ... | ... | ... | ... | ... |

> **產出**：影子 IT 風險地圖 + 採購整合機會。

---

### Tool 1.3 Systems Inventory / 系統盤點表

| 系統名稱 | 廠商 / 版本 | 部門擁有者 | 使用人數 | 整合點 (in/out) | 資料敏感度 | API 可用？ | 雲/地端 | 備註 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Gmail Workspace | Google | IT | 全公司 250 | OAuth API | Medium | ✓ | 雲 | 已啟 SSO |
| Salesforce | SF Sales Cloud Pro | Sales | 35 | REST + Webhook | High (PII) | ✓ | 雲 | 12 月到期 |
| SAP B1 | 9.3 | Finance | 18 | DI API + ODBC | High | ✓ | 地端 | 老舊客製多 |
| Notion | Plus | All | 80 | API + Webhook | Medium | ✓ | 雲 | 部門自管 |
| ... | ... | ... | ... | ... | ... | ... | ... | ... |

> **產出**：系統地圖 + L3 Workflow PoC 候選清單。

---

### Tool 1.4 As-Is Process Map (Swimlane Template)

```
Process: 客戶詢價到出貨 / Quote-to-Ship
========================================
Actor / 角色   | Step / 步驟         | System / 系統 | Input         | Output        | Pain
---------------|--------------------|---------------|---------------|---------------|-------
客戶 Customer  | 寄詢價信           | Email         | 需求描述       | 詢價郵件       | -
業務 Sales     | 收信判斷           | Gmail         | 詢價郵件       | 內部分派       | 漏接 30%
業務 Sales     | 查 ERP 庫存價格    | SAP B1        | 料號           | 庫存價格表     | 慢 + 出錯
業務 Sales     | 寫報價單           | Word + Sheet  | 庫存價格       | 報價單草稿     | 重複
業務主管 Lead  | 審核報價           | Email         | 報價單         | 簽核 / 退回    | 等
業務 Sales     | 寄報價             | Gmail + PDF   | 簽核版         | 報價郵件       | -
客戶 Customer  | 確認下單           | Email         | 報價           | PO            | -
業務 Sales     | 開單 (SO)          | SAP B1        | PO             | SO 編號        | 重 key
倉儲 WMS Op    | 出貨備貨           | WMS           | SO             | 揀貨單         | 對單錯
出貨 Shipping  | 列印貨運單         | 物流系統        | 揀貨單         | 託運單         | -
========================================
總時間 / Total: 平均 4-7 個工作天
痛點 / Pain summary: 漏接、重 key、找價格慢、簽核等
AI 化候選 / AI candidates: L3 Gmail 分類、L3 SAP 報價自動草稿、L4 Agent 簽核摘要
```

> **產出**：每個 process 一張 swimlane；標註痛點密度（每 step 0-3 點）；交給 Stage 4 做 Impact × Effort。

---

## Stage 2：Reference Model Alignment / 標準模型引入

> **目的**：導入國際標準框架（如 APQC PCF、SCOR、eTOM、ITIL），建立營運結構的健康檢視座標。**這是 Rosemann BPM 學派的核心 —— 不是用顧問主觀判斷，而是用業界公認的「標準營運模型」來檢視公司結構是否完整。**
>
> **Output KPI**：標準能力缺口檢核清單、營運結構完整度分析。

### Tool 2.1 Reference Model 選用指引 / Reference Model Selection Guide

| Reference Model | 適用領域 | 涵蓋範圍 | 何時用 |
| --- | --- | --- | --- |
| **APQC PCF (Process Classification Framework)** | 跨產業通用 | 13 個 Category、1,000+ process | 全公司營運結構盤點（首選） |
| **SCOR (Supply Chain Operations Reference)** | 供應鏈、製造、物流 | Plan / Source / Make / Deliver / Return / Enable | 製造業、零售、物流 |
| **eTOM (Business Process Framework)** | 電信、訂閱服務 | Strategy / Operations / Enterprise | 電信、SaaS、訂閱 |
| **ITIL** | IT 服務管理 | Service Strategy / Design / Transition / Operation / CSI | IT、MSP |
| **CMMI** | 軟體開發、流程成熟度 | 5 級成熟度 | 軟體公司、研發單位 |
| **Tiger AI L1-L5** | AI 採用成熟度 | L1 個人 → L2 部門 → L3 跨部門 → L4 AI 自主 → L5 AI 團隊 | AI 轉型專屬（**本方法論的 AI 軸 Reference Model**） |

> **使用原則**：每個顧問案至少選 **1 個產業 Reference Model + Tiger AI L1-L5**。前者檢視「業務結構完整度」，後者檢視「AI 採用成熟度」。兩座標交叉，得出真實缺口。

### Tool 2.2 Reference Model Mapping Worksheet / 標準模型對應表

把 Stage 1 盤點到的真實 process / 系統 / 角色，對應到所選 Reference Model 的標準分類。

| 標準分類 (Reference Model Category) | 標準應有能力 | 公司現況 | 對應的 As-Is Process | 差距類型 |
| --- | --- | --- | --- | --- |
| APQC 4.0 Deliver Products and Services | 訂單管理、出貨、客服 | 部分有 | 「客戶詢價到出貨」 swimlane | 部分缺 (見 Stage 4) |
| APQC 8.0 Manage Information Technology | IT Governance、API 管理 | 弱 | (無) | Missing |
| APQC 11.0 Manage Knowledge | 知識沉澱、Skill Library | 完全沒有 | (無) | Missing — AI 機會點 |
| SCOR Plan | 需求預測、供需平衡 | Excel 手算 | (無正式 process) | Broken |
| SCOR Source | 採購、供應商評估 | 已成熟 | 「採購流程」swimlane | OK |
| Tiger AI L1 | 全員 Chat AI 入口 | 無 | (無) | Missing |
| Tiger AI L2 | 部門 Skill Library | 無 | (無) | Missing |
| Tiger AI L3 | n8n / Workflow 自動化 | 1-2 個試做 | (零散) | 部分缺 |
| ... | ... | ... | ... | ... |

> **使用方式**：兩條軸線交叉檢視 —— 縱軸為產業標準分類，橫軸為 Tiger AI L1-L5，把所有 As-Is process 落點到格內，沒落到的格就是「結構性缺口」。

### Tool 2.3 標準能力缺口檢核清單 / Standard Capability Gap Checklist

> 此表是 Stage 2 的核心 Output。給管理層看「依國際標準，您的公司結構是完整的嗎？」

| 能力領域 | 標準應有 | 公司有？ | 完整度 0-4 | 證據 / Evidence | 觀察（**不評論、不建議**） |
| --- | --- | --- | --- | --- | --- |
| 訂單管理 | APQC 4.2 | ✓ | 3 | SAP B1 SO 模組 | 流程存在但人工密集 |
| 知識管理 | APQC 11.x | ✗ | 0 | (無 SOP / Wiki) | 完全缺 |
| AI 治理 | (新興，無標準) | ✗ | 0 | (無 policy) | 完全缺 |
| Workflow 自動化 | APQC 8.x + Tiger AI L3 | 部分 | 1 | 1 個 n8n 試做 | 試點階段 |
| ... | ... | ... | ... | ... | ... |

> **紀律**：Stage 2 只回答「結構是否完整」，**不回答「為什麼不完整」**（那是 Stage 5）、**不回答「該做什麼」**（那是 Stage 6-7）。

### Tool 2.4 營運結構完整度雷達圖 / Operating Structure Completeness Radar

依 Tool 2.3 的完整度分數，畫出產業 Reference Model 各 Category 的雷達圖 + Tiger AI L1-L5 的雷達圖（雙圖）。

```
APQC 雷達 (滿分 4)              Tiger AI L1-L5 雷達 (滿分 4)
                                                
   1.0 開發策略                       L5 AI Team
        4                                  4
   3 ●                                3 ●
   2   ●  2.0 開發產品              2   ●  L4 Agent
   1     ●                          1     ●
      ●                                ●
   13.0 治理        4.0 交付產品     L1 Chat       L3 Workflow
   (虛線=產業標竿；實線=本公司)      (虛線=產業標竿；實線=本公司)
```

> **產出**：兩張雷達圖 + 文字說明「公司在哪幾個 Category 顯著低於標準」。

---

### Tool 2.5 Reference Model 條件檢核 — 用成熟度思維反推「什麼才算合格的 Reference Model」

> **核心邏輯**：成熟度模型（CMM / Rosemann BPM Maturity）本身就告訴我們「一個夠格的標準參照框架要長什麼樣」。把這套邏輯反向用，就能：(a) 判斷一個現成的 Reference Model 是否合格、(b) **在沒有現成 RM 的領域自製一個**（這就是 Tiger AI L1-L5 的誕生由來 —— 沒有 AI 領域的現成 RM，依條件自製一個）。

#### 10 大合格條件 / 10 Conditions for a Qualified Reference Model

| # | 條件 | 為什麼這條重要 | 不符合會出什麼問題 |
| --- | --- | --- | --- |
| 1 | **完整性 (Completeness)** | 覆蓋目標領域的全貌，沒有主要盲點 | 用了卻發現「我們做的事它沒收錄」→ 失去座標意義 |
| 2 | **互斥性 (MECE)** | Categories 不重疊；每項能力只有一個歸屬 | Mapping 時同一個 process 落到兩格 → 混亂、無法計分 |
| 3 | **階層性 (Hierarchical Decomposition)** | 至少 2-3 層分解（例：APQC 13 Cat → ~200 Process Group → ~1,000 Process）| 太粗：無法落點；太細：失焦 |
| 4 | **可量化 (Measurable Maturity Levels)** | 每項能力可用 0-4 / Initial→Optimizing 等級客觀評分 | 顧問主觀打分 → 客戶不服 → 信任崩塌 |
| 5 | **演進路徑 (Evolution Trajectory)** | 描述每項能力「從 0 到卓越」的階段順序，不只是「現況有/無」| 客戶問「那下一步怎麼走」無解 → 無法接 Stage 6 |
| 6 | **產業認可 (Industry Recognition)** | 由公認機構維護（APQC、SCC、TM Forum、ISACA...）或有大量案例佐證 | 顧問自編 → 客戶懷疑「這是不是你瞎掰的」 |
| 7 | **可移植性 (Cross-Organization Portability)** | 同一個 RM 能套用到多家公司，不是一家專屬 | 換家公司就不能用 → 無法累積經驗 |
| 8 | **實作中立 (Implementation-Independent)** | 描述 WHAT 不描述 HOW；不綁定特定技術 / 供應商 | 綁了 SAP / Salesforce 等 → 換系統就失效 |
| 9 | **可審核 (Observable Evidence)** | 每項能力的成熟度有可觀察的證據（log、文件、行為） | 評分變成「感覺」→ 不可重複 / 不可驗收 |
| 10 | **可維護 (Versioned & Updatable)** | 有 owner / 有版本 / 會跟著產業演進更新 | 用了 10 年沒更新 → 跟不上新興能力（如 AI） |

#### Reference Model 合格度評分表 / RM Qualification Scorecard

對任何候選 RM（包括自製的）跑這張表。**8 條以上達標才算合格**；任一條 0 分 = 不可用。

| Reference Model | 1 完整 | 2 MECE | 3 階層 | 4 量化 | 5 演進 | 6 認可 | 7 移植 | 8 中立 | 9 審核 | 10 維護 | 總分 | 結論 |
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | ---: | --- |
| **APQC PCF** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 10 | 合格（跨產業首選） |
| **SCOR** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 10 | 合格（供應鏈專用） |
| **eTOM** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | △ | ✓ | ✓ | ✓ | 9 | 合格（電信專用） |
| **ITIL** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | △ | ✓ | 9 | 合格（IT 服務） |
| **CMMI** | △ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 9 | 合格（軟體研發 / 流程成熟度） |
| **Tiger AI L1-L5** | ✓ | ✓ | ✓ | ✓ | ✓ | △ | ✓ | ✓ | ✓ | ✓ | 9 | 合格（AI 採用，新興；認可度隨時間累積） |
| 某顧問自編「AI 八步」 | ? | ? | ✗ | ✗ | ✗ | ✗ | ? | ? | ✗ | ✗ | < 5 | 不合格（無成熟度階段、無認可、無證據） |

> △ = 部分達標、✓ = 達標、✗ = 不達標。

#### 自製 Reference Model 的 7 步流程 / How to DIY a Reference Model When No Off-the-Shelf One Fits

當你進入一個「沒有現成 RM」的領域（AI、永續、ESG、新興產業等），就照這 7 步自製。**Tiger AI L1-L5 本身就是用這套邏輯做出來的**：

```
Step 1：定義領域邊界（Scope）
  └─ 例：AI 採用，不含傳統 IT 自動化、不含純科學運算
  └─ 條件 1（完整性）+ 條件 7（移植性）的前置

Step 2：列出該領域的所有「能力範疇」
  └─ 例：個人使用、知識沉澱、流程自動化、自主代理、團隊協作
  └─ 條件 2（MECE）：能力之間不重疊

Step 3：為每個範疇定義 3-5 個成熟度階段
  └─ 例：L1 個人 → L2 部門 → L3 全公司 → L4 AI 自主 → L5 AI 團隊
  └─ 條件 4（量化）+ 條件 5（演進路徑）

Step 4：每個階段定義可觀察的成熟特徵
  └─ 例：L1 = 全員帳號 + AI 使用規範 + Prompt Library ≥ 30 條
  └─ 條件 9（可審核）—— 不是「員工會用」而是具體可數的證據

Step 5：定義階段之間的依賴關係（前置條件）
  └─ 例：L4 必須以 L1-L3 為基礎，不能跳級
  └─ 條件 5（演進路徑）的依賴鏈

Step 6：跨產業驗證（≥ 3 家不同產業的試套）
  └─ 確保不是只在一家公司有效
  └─ 條件 7（移植性）

Step 7：建立 owner + 版本 + 更新機制
  └─ 例：放 GitHub、公開、Apache 2.0、社群回饋
  └─ 條件 10（可維護）+ 條件 6（認可度累積）
```

#### Tiger AI L1-L5 為什麼合格 / Why Tiger AI L1-L5 Qualifies as a Reference Model

| 條件 | 在 Tiger AI L1-L5 中的具體實現 |
| --- | --- |
| 1 完整 | 涵蓋個人到團隊的 AI 採用全光譜 |
| 2 MECE | L1-L3 為規模軸（人主導）、L4-L5 為 AI 自主軸（兩條軸正交，不重疊）|
| 3 階層 | 每個 L 級下都有「能力 / 工具 / 課程 / 產出物 / 階段驗收」5 層分解 |
| 4 量化 | 每級設計 5 個可觀察指標 × 0-4 分量尺 |
| 5 演進 | 明確的 L1 → L2 → L3 → L4 → L5 路徑，且 L3 → L4 是關鍵分界 |
| 6 認可 | 新興（2025 啟動），社群採用度與案例累積中（Apache 2.0 + GitHub）|
| 7 移植 | 已在製造 / 醫院 / 行銷 / B2B / 金融 / 政府 / 教育 7 產業驗證 |
| 8 中立 | 描述 WHAT（能力）不綁定具體 LLM 廠商或工具 |
| 9 審核 | 每級有明確 Stage Gate Criteria（L1-L5 Gate 各自驗收清單）|
| 10 維護 | 版本控制（GitHub）、定期更新、社群回饋通道 |

> **這就是反向操作的價值**：用成熟度思維檢視自己的方法論，不只是「我們有 L1-L5」，而是「我們的 L1-L5 符合 Reference Model 應有的 10 大條件」—— 這是把方法論升級為**可被學術與業界引用**的 Reference Model 的關鍵動作。

#### Tool 2.5 顧問實務用法

1. **客戶問「為什麼選 APQC / Tiger AI L1-L5」**：拿這張表給他看，10 大條件每條打勾。
2. **客戶用過某個顧問自編的「成熟度模型」覺得不對勁**：拿這張表幫他做合格度評分，通常會發現 4/5/9/10 條沒達標。
3. **進入沒有現成 RM 的領域（新興產業 / 客戶獨有的業務）**：跑 Step 1-7 自製。Tiger AI L1-L5 就是這樣做出來的。
4. **學術投稿 / 對外發表方法論**：用條件 1-10 替方法論做合格度自評，是論文 / 白皮書必備章節。

---

### Tool 2.6 Reference Model 元件圖 — 用成熟度思維推導「該有哪些 Component」

> **核心邏輯**：Tool 2.5 解決的是「**這個 Reference Model 合不合格**」（meta 層）；Tool 2.6 解決的是「**這個 Reference Model 該包含哪些元件 component**」（內容層）。
>
> 用成熟度思維推導應有元件 → 畫成一張**組件圖**（component map）→ 顧問拿這張圖跟客戶的真實組織做**格子對格子的比對**，缺哪格、空哪格、堆三套在哪格一目了然。
>
> 參考視覺典範：**Dragon1 Enterprise Architecture Reference Model** —— 它把 EA 領域應有的 component 全部攤平到一張圖上，從 Governance（上）→ Core Business Units（中）→ Information Services（中下）→ IT Infrastructure（下），左右兩側再掛 Supply Chain / Human Capital / Safety & Security / Finance 四條垂直能力。本工具的設計哲學一致：**先列全圖、再做比對、再找缺口**。

#### 用成熟度思維推導 component 的 5 個提問

對任何要做 Reference Model 的領域（AI、ESG、永續、新事業...）問這 5 題：

| 問題 | 推導出的 component 類型 | 範例（用在 AI 領域）|
| --- | --- | --- |
| **Q1：誰來治理？** | Governance Component | AI 政策、AI 倫理、合規（個資法/EU AI Act）、風險委員會、Audit Owner |
| **Q2：核心做什麼？** | Core Capability Component | L1 Controlled AI Access、L2 Knowledge Codification、L3 Workflow Automation、L4 Auto Agent、L5 Agent Team |
| **Q3：靠什麼支撐？** | Enabling Layer Component | 知識管理、資料管線、LLM 路由、Vector DB、Embedding、MLOps、Audit Log |
| **Q4：用什麼基礎建設？** | Infrastructure Component | GPU、推論伺服器、API Gateway、Identity (SSO)、Monitoring、Secret Mgmt |
| **Q5：跨層共用什麼？** | Cross-Cutting Component | 人才/AI 素養（左軸）、風險/安全（右軸上）、價值/ROI（右軸下）、變革管理（橫貫）|

> **這 5 題映射到 Dragon1 EA 圖**：Q1 = 上方 Enterprise Governance、Q2 = 中央 Core Business Units、Q3 = Information Services and Facilities、Q4 = IT Infrastructure、Q5 = 左右兩側垂直軸（Human Capital / Safety & Security / Finance）。

#### Enterprise AI Reference Model — Component Map（Tiger AI 自製，對應 Dragon1 視覺結構）

```
╔══════════════════════════════════════════════════════════════════════════════════╗
║                         AI Governance（上方治理層）                                ║
║ ┌──────────────┬──────────────┬──────────────┬──────────────┬──────────────┐    ║
║ │ AI Policy    │ AI Ethics    │ Compliance   │ Risk Committee│ Audit Owner │    ║
║ │ (規範+簽署)  │ (偏見/智財) │ (個資/AI 法) │ (董事會層)    │ (法遵+內稽) │    ║
║ └──────────────┴──────────────┴──────────────┴──────────────┴──────────────┘    ║
╠══════╦═══════════════════════════════════════════════════════════════════╦═══════╣
║ 人   ║                 Core AI Capabilities（核心 L1-L5）                ║ 風險  ║
║ 才   ║ ┌──────────────────────┐  ┌──────────────────────┐                ║ 安全  ║
║ 軸   ║ │ 規模軸（人監督 AI） │  │ AI 自主軸（AI 自主） │                ║       ║
║      ║ │ L1 Controlled AI Access           │  │ L4 Auto Agent        │                ║ DLP   ║
║ AI   ║ │ L2 Knowledge Codification          │  │ L5 Agent Team        │                ║ 機敏  ║
║ 素   ║ │ L3 Workflow Automation       │  │  (HITL 保留)         │                ║ Redact║
║ 養   ║ └──────────────────────┘  └──────────────────────┘                ║ Audit ║
║      ║                                                                    ║ Log   ║
║ Champion╠═══════════════════════════════════════════════════════════════╣ Incident║
║ 訓練  ║              Enabling Layer（支撐層）                             ║ 治理  ║
║      ║ ┌────────────┬────────────┬────────────┬────────────┬───────────┐ ║       ║
║ HR   ║ │ Knowledge  │ Data        │ LLM Router │ Vector DB  │ Skill Lib │ ║       ║
║ Onbd ║ │ Mgmt (Wiki)│ Pipeline    │ (litellm)  │ Embedding  │ Versioned │ ║       ║
║      ║ ├────────────┼────────────┼────────────┼────────────┼───────────┤ ║ 價值  ║
║      ║ │ MLOps /    │ Prompt Lib │ Evaluation │ Reviewer   │ Audit Log │ ║ ROI   ║
║      ║ │ Eval Suite │ Versioned  │ Suite      │ Workflow   │ (全鏈)    │ ║ 軸    ║
║      ║ └────────────┴────────────┴────────────┴────────────┴───────────┘ ║       ║
║      ╠═══════════════════════════════════════════════════════════════════╣ 時間  ║
║      ║              AI Infrastructure（基礎建設層）                       ║ 品質  ║
║      ║ ┌─────────────┬─────────────┬─────────────┬─────────────────────┐ ║ 規模  ║
║      ║ │ GPU / 推論  │ API Gateway │ Identity    │ Monitoring          │ ║ 風險  ║
║      ║ │ 伺服器      │ (Rate/Auth) │ SSO + RBAC  │ Grafana / Tracing   │ ║ 資產  ║
║      ║ ├─────────────┼─────────────┼─────────────┼─────────────────────┤ ║       ║
║      ║ │ Secret Mgmt │ Backup / HA │ 部署模式：  │ 變更管理 / CI/CD    │ ║       ║
║      ║ │ Vault       │             │ Cloud/Hybrid/On-Prem            │ ║       ║
║      ║ └─────────────┴─────────────┴─────────────┴─────────────────────┘ ║       ║
╚══════╩═══════════════════════════════════════════════════════════════════╩═══════╝
        ↑                                                                  ↑
   Human Capital                                                    Safety/Security
   人才/素養軸                                                        + Value/ROI 軸
```

**讀法**（仿 Dragon1）：

- **上方**（Governance）：誰負責 AI 的規矩、誰簽 policy、出事誰負責。
- **中央**（Core）：公司實際在做什麼 AI 工作；L1-L3 與 L4-L5 兩個方塊代表兩條軸（規模 + 自主）。
- **中下**（Enabling）：讓 Core 跑得起來的支撐服務（知識、資料、LLM、Eval、Audit Log）。
- **下方**（Infrastructure）：跑這一切的基礎建設（GPU、Gateway、SSO、監控、部署模式）。
- **左軸**（Human Capital）：人才、AI 素養、訓練、HR onboarding —— **跨所有橫向層**。
- **右軸**（Safety/Security + Value/ROI）：風險、安全、稽核、價值追蹤 —— **也是跨所有橫向層**。

#### 怎麼用這張組件圖跟客戶比對 / How to Compare Client's Reality Against This Map

**Step 1：影印一張空白組件圖給客戶**（A3 列印）。

**Step 2：依 Stage 1 As-Is 盤點，把每個現有元件「貼」到對應格子上**。用三色標記：

- 🟢 綠：完整且運作良好
- 🟡 黃：存在但運作不良 / 不完整（Broken）
- 🔴 紅：完全缺（Missing）
- 🔵 藍重複：同一格被多個系統占據（Redundant）

**Step 3：產出一張視覺化的 「公司 AI 現況組件圖 vs Reference Model 組件圖」**。

範例（M 公司 700 人封測廠）：

```
🟢 GPU / 推論伺服器        （已採購 H200）
🟢 Identity SSO            （Active Directory 已就位）
🟡 LLM Router              （只有一個 OpenAI key、無路由）
🔴 Knowledge Mgmt (Wiki)   （完全沒有 ← 80% 痛點來源）
🔴 Skill Library            （完全沒有）
🔴 Prompt Library           （完全沒有）
🔵 Workflow                 （Zapier + Power Automate + 手寫 Python 三套）
🔴 AI Policy                （沒有）
🔴 AI Champion              （沒有）
🟡 Audit Log                （部分系統有，未整合）
🔴 Reviewer Workflow        （無）
🔴 Eval Suite               （無）
```

**Step 4：缺口 → 直接連到 Stage 4 Missing/Broken/Redundant 表，連到 Stage 6 Phased Goals 排序。**

#### Tool 2.6 與 Tool 2.5 的關係

| Tool | 解決的問題 | 比喻 |
| --- | --- | --- |
| **Tool 2.5** | 「**這個 Reference Model 設計得對不對**」（10 大條件檢核 + 自製 7 步流程）| 蓋房子前，先確認「建築規範」是否合格 |
| **Tool 2.6** | 「**這個 Reference Model 該包含哪些 Component**」（5 個推導提問 + 組件圖 + 對比比對）| 規範合格後，畫出「房屋設計圖」逐項施工 |

**完整流程**：Tool 2.1 選 RM → Tool 2.5 確認 RM 合格 → **Tool 2.6 畫出 RM 組件圖** → Tool 2.2 把 As-Is 落點到組件圖 → Tool 2.3 缺口檢核 → Tool 2.4 完整度雷達。

#### 自製組件圖的 4 個檢核

每張自製組件圖出版前，必須通過：

- [ ] **MECE 檢核**：任兩個 component 不重疊
- [ ] **覆蓋檢核**：5 個推導提問（Q1-Q5）全部有對應 component
- [ ] **層次檢核**：至少 3-4 層（治理 / 核心 / 支撐 / 基建）+ 跨層垂直軸（≥ 2 條）
- [ ] **跨組織驗證**：拿 ≥ 3 家不同產業客戶試用，每家都能把 As-Is 落點進來

---

### Tool 2.7 4 層架構式 Reference Model — 用成熟度思維推導「為什麼是這 4 層」

> Tool 2.6 解決「**該有哪些 component**」（扁平組件圖）；Tool 2.7 升級為 **4 層堆疊菱形架構**（仿 Dragon1 Enterprise Architecture Reference Model），用成熟度思維推導「為什麼必須是這 4 層、不是 3 層或 5 層」。
>
> 4 層結構不是任意切的 —— 它符合 Rosemann BPM 成熟度的「**抽象 → 具象**」演化軸：上層決定「為什麼存在 + 想成為什麼」，下層決定「用什麼跑得起來」。層間靠 **Planning（往下計畫）** 與 **Alignment（往上對齊）** 鎖死。

#### 為什麼是 4 層 — 從成熟度思維推導

成熟度模型告訴我們：一個組織會在 4 種「**抽象度 / 變動頻率**」上同時運作，混在一起就會失焦。把它們強制分層，就是 Reference Model 必然 4 層的原因：

| 層 | 抽象度 | 變動頻率 | 回答的問題 | 一旦改動，影響什麼 |
| --- | --- | --- | --- | --- |
| **Layer 1 Governance Architecture** | 最抽象（哲學/策略） | 最慢（年）| 為什麼存在？要成為什麼？ | 影響下面三層的方向 |
| **Layer 2 Business Architecture** | 抽象（職能/流程） | 中慢（季-年）| 做什麼業務？如何組織？ | 影響下面兩層的服務需求 |
| **Layer 3 Information Architecture** | 中（服務/資料） | 中快（月-季）| 業務需要什麼資訊服務？ | 影響下面一層的技術選型 |
| **Layer 4 Technical Architecture** | 最具象（硬體/網路） | 最快（週-月）| 用什麼技術跑得起來？ | 影響執行成本與性能 |

**Planning ↓**：上層把意圖往下傳（Governance 訂目標 → Business 訂流程 → Information 訂資料 → IT 訂建設）。
**Alignment ↑**：下層把現實往上回報（IT 限制 → Information 限制 → Business 限制 → Governance 重新調整）。

#### Dragon1 Enterprise Architecture Reference Model（業界典範）

```
                          ◆ Layer 1：Enterprise Governance
                         ╱  Governance Architecture
                        ╱   Directing, Managing Risk and Compliance
                       ╱    
                      ◆ ──── 元件：Mission / Vision / Identity / Strategy / 
                     ╱        Enterprise Goals / Markets & Clients / 
                    ╱         Innovation / Plans / Quality / Finance /
              Planning↓       Philosophy / Decisions / Laws / Axioms /
              Alignment↑      Concepts & Principles / Developments / Trends
                      ╲       
                       ╲   ◆ Layer 2：Business(es)
                        ╲ ╱   Business Architecture  
                         ◆    Business Operations Delivering Value
                        ╱     元件：Business Goals / Product & Services Catalog /
                       ╱       Functions Processes Activities / Organization TVBR /
                  Planning↓    Resources / Employees Skills Competences /
                  Alignment↑   Business Strategy / Principles & Rules / Plan /
                       ╲       Finance Budgets / Starting Points & Preconditions /
                        ╲      Policy
                         ◆ ───
                        ╱   ◆ Layer 3：Information Facilities and Systems
                       ╱   ╱   Information Architecture
                      ╱   ╱    Delivering Information Facilities and Services
                 Planning↓     元件：Information Services / Information Objects /
                 Alignment↑     Information / Information Systems / Data /
                       ╲       Application Functions / Development / Messages /
                        ╲      Actors Triggers Events / Exchange / Management /
                         ◆ ──   Goals / Strategy / Plan
                        ╱    ◆ Layer 4：IT Infrastructure(s)
                       ╱    ╱   Technical Architecture
                      ╱    ╱    Delivering IT Facilities and Services
                            ╱   元件：Platforms / Networks / Storage / 
                                Devices & IoT / Software & Middleware /
                                Clients & Servers / Data Management /
                                Data Telecommunication / Application Components /
                                Internet / Security & Privacy / Services
```

> **每層四個角的軌道元件**（cross-layer concerns）：Changes / Transformations、Costs / Benefits、Capacity / Capability、Projects / Programs —— 這四件事**每一層都要管**，所以畫在每個菱形的四個角。

#### Tiger AI Enterprise AI Reference Model — 4 層架構（仿 Dragon1，AI 領域版）

把上述 4 層邏輯套到 AI 領域。注意每層的元件雲、層間的 Planning/Alignment、四角的軌道元件。

```
                          ◆ Layer 1：AI Governance Architecture
                         ╱  治理層 · Directing AI, Managing Risk & Compliance
                        ╱   
                       ◆ ──── 元件：AI Mission / AI Vision / Identity (誰是 AI Owner) /
                      ╱        AI Strategy / Enterprise AI Goals / AI Ethics /
                     ╱         AI Policy / Compliance (個資法/EU AI Act/AI 基本法) /
              Planning↓        Risk Committee / AI Champion / Sponsor /
              Alignment↑       Audit Owner / 第三方 AI 採用準則 / Decisions /
                      ╲        Laws (法規) / Principles & Rules / Trends
                       ╲   
                        ╲   ◆ Layer 2：AI Business Architecture
                         ◆ ╱  業務層 · AI Operations Delivering Value
                        ╱     元件：Business Goals with AI / L1-L5 Capabilities /
                       ╱       規模軸 (L1 Chat → L2 Skill → L3 Workflow) /
                  Planning↓    AI 自主軸 (L4 Auto Agent → L5 Agent Team) /
                  Alignment↑   人機分工 (HITL 節點) / Department AI Roles /
                       ╲       Skill Library / Workflow Library / Agent Library /
                        ╲      Stage Gate Criteria / ROI / 價值追蹤矩陣 /
                         ◆ ─── Resources / Employees AI Skills / Plan / Budgets
                        ╱   
                       ╱  ◆ Layer 3：AI Information Architecture
                      ╱  ╱   資訊層 · Delivering AI Information Services
                 Planning↓    元件：Knowledge Mgmt (Wiki) / Prompt Library /
                 Alignment↑    Skill Definitions / Workflow Specs / Agent Specs /
                       ╲       Data Pipeline / Vector DB / Embedding /
                        ╲      Evaluation Suite / Reviewer Workflow /
                         ◆ ─   Audit Log / Information Services for AI / 
                        ╱    ◆ Layer 4：AI Technical Architecture
                       ╱    ╱   技術層 · Delivering AI Infrastructure
                      ╱    ╱    元件：GPU / 推論伺服器 / LLM Router (litellm) /
                            ╱    API Gateway / Identity SSO + RBAC /
                                 Monitoring (Grafana/Tracing) / Secret Mgmt (Vault) /
                                 Storage / Networks / Backup HA /
                                 部署模式 (Cloud / Hybrid / On-Prem) /
                                 CI/CD / Security & Privacy / Devices
```

#### 每層四個角的軌道元件（Cross-Layer Concerns）

每一層的菱形四個角都要管這 4 件事 —— 它們不是某一層獨有，而是 4 層共同的「跨層關注點」：

| 軌道元件 | 在 Governance 層 | 在 Business 層 | 在 Information 層 | 在 IT Tech 層 |
| --- | --- | --- | --- | --- |
| **Changes / Transformations** | 公司 AI 戰略換軌 | 業務模式因 AI 重組 | Skill/Workflow 版本演進 | LLM 廠商換、地端遷移 |
| **Costs / Benefits** | 整體 AI 投資 ROI | 部門 AI 業務價值 | 知識資產化效益 | LLM token 成本 / GPU 折舊 |
| **Capacity / Capability** | 公司 AI 戰略能力 | 部門 AI 能力盤點 | 知識管理能力 | GPU/網路頻寬容量 |
| **Projects / Programs** | AI 轉型 Program | 部門 PoC 專案 | Wiki 建置專案 | 推論伺服器導入專案 |

> **這就是為什麼 4 層架構比扁平組件圖強**：扁平圖只回答「該有什麼」；4 層架構還回答「**每件事在每層怎麼變形**」。

#### Planning ↓ 與 Alignment ↑ 的具體應用

每一個跨層動作都要回答：

- **Planning ↓ 由上而下**：Governance 的「2026 公司知識資產化」戰略 → Business 層拆解成「每部門 5 條核心 Skill」→ Information 層具體化為「Wiki + Prompt Library 上線」→ IT 層採購「Vector DB + SSO 整合」。
- **Alignment ↑ 由下而上**：IT 層發現「現有 GPU 不夠跑 L4 Agent」→ Information 層回報「需要降模型大小或排隊」→ Business 層調整「Phase 2 推遲」→ Governance 層更新「年度 AI Roadmap」。

**4 層必須雙向鎖死**，缺一向都會失敗：

- 只有 Planning ↓ 沒 Alignment ↑：上層活在幻想，下層做不到。
- 只有 Alignment ↑ 沒 Planning ↓：技術部門自嗨，業務不買單。

#### Tool 2.7 操作流程（顧問實作）

**Step 1**：把空白 4 層菱形圖列印 A2（彩色），放會議室桌上。

**Step 2**：跟客戶從 **Governance 層往下** 依序填：

```
Day 1 上午：Governance 層 —— CEO + Sponsor + 法遵
Day 1 下午：Business 層   —— COO + 部門長 + AI Champion
Day 2 上午：Information   —— AI Champion + 知識長 + IT Lead
Day 2 下午：IT Tech       —— CIO + IT Admin + 資安
```

每層每格用三色貼紙標：🟢 完整 / 🟡 部分 / 🔴 缺。

**Step 3**：跑 **Alignment ↑** 反向驗證 —— 從 IT 層往上問「我們真的能撐住上一層的需求嗎？」常常發現 Governance 的雄心被 IT 層的現實打回。

**Step 4**：4 層各拍一張照，產出**完整 4 層 As-Is 組件圖**。直接拿到 Stage 4 Gap Analysis、Stage 6 Phased Goals 用。

#### Tool 2.5 / 2.6 / 2.7 三者的關係 — 完整方法論閉環

| Tool | 解決層次 | 比喻 |
| --- | --- | --- |
| **Tool 2.5** | **Meta 層**：這個 RM 設計得對不對？（10 條件 + 自製 7 步流程）| 建築規範是否合格 |
| **Tool 2.6** | **內容層（扁平）**：該有哪些 component？（5 推導提問 + 組件圖）| 房屋設計圖逐項列出 |
| **Tool 2.7** | **架構層（立體）**：為什麼必須這幾層？怎麼連？（4 層菱形 + Planning↑↓）| 建築總圖 + 樓層關係 |

**完整流程**：
Tool 2.1 選 RM → Tool 2.5 確認合格 → **Tool 2.6 列扁平組件清單** → **Tool 2.7 提升到 4 層架構**（含 Planning/Alignment）→ Tool 2.2 把 As-Is 落點 → Tool 2.3 缺口檢核 → Tool 2.4 完整度雷達。

#### 為什麼 Tiger AI 方法論需要 4 層架構

最初版的 Tiger AI L1-L5 只有「Core Capability」一個維度（Business 層）。加上 4 層架構後：

- **Governance 層**補上：AI Ethics、Compliance（EU AI Act / 個資法 / 台灣 AI 基本法）、AI Champion 角色定義、Sponsor 究責邊界
- **Information 層**補上：Knowledge Management（最大的缺口）、Prompt/Skill/Workflow/Agent Library 的版本治理、Evaluation Suite、Audit Log 全鏈
- **IT Tech 層**補上：LLM Router（litellm）、Vector DB、Identity/SSO、Monitoring、地端 / 雲 / Hybrid 三種部署模式

**這就是把「AI 採用方法論」升級為「Enterprise AI Reference Model」的關鍵動作** —— 從一個維度（L1-L5）→ 4 個維度（4 層架構）× L1-L5 = 完整可治理的 AI 轉型框架。

```
APQC 雷達 (滿分 4)              Tiger AI L1-L5 雷達 (滿分 4)
                                                
   1.0 開發策略                       L5 AI Team
        4                                  4
   3 ●                                3 ●
   2   ●  2.0 開發產品              2   ●  L4 Agent
   1     ●                          1     ●
      ●                                ●
   13.0 治理        4.0 交付產品     L1 Chat       L3 Workflow
   (虛線=產業標竿；實線=本公司)      (虛線=產業標竿；實線=本公司)
```

> **產出**：兩張雷達圖 + 文字說明「公司在哪幾個 Category 顯著低於標準」。

---

## Stage 3：Best Practice Integration / 產業最佳實務對標

> **目的**：把產業領先模式作為**輸入素材**，協助**客戶自己展開出他的 Ideal Practice（理想實務）**。**Stage 2 用標準框架檢查「是否完整」，Stage 3 不是顧問把 best practice 塞給客戶，而是讓客戶自己挑選、自己具體化他的「想成為的樣子」**。
>
> **Output KPI**：產業標竿營運模型圖、**客戶 Ideal Practice 定義表**（這份表是 Stage 4 Gap Analysis 的目標基準）。
>
> ⚠️ **關鍵設計**：產業 Best Practice 是**素材**，客戶 Ideal Practice 才是**目標**。為什麼這個分別重要？因為：
>
> - 若顧問直接說「依產業標準你該做到 X」→ 客戶可以否認「我們不一樣」
> - 若客戶自己說「我想做到 X」→ 客戶**無法否認自己的目標**
> - 後續 Gap = (客戶 Ideal Practice − 客戶 As-Is)，這個算式客戶不會吵
>
> **這就是顧問報告「科學辯論能力」的關鍵動作之一**：把「目標來源」從顧問權威轉移到客戶決策。

### Tool 3.1 Industry Best-Practice Profile Template / 產業最佳實務檔案

| 欄位 | 說明 |
| --- | --- |
| Industry | 產業 |
| Company size | 員工數 / 營收 |
| Their L-level start | 開始時 L 級 |
| Their L-level today | 目前 L 級 |
| Time taken | 月數 |
| 對應 Reference Model 的卓越作法 | 在 APQC / SCOR 哪幾項做到領先？具體做了什麼？ |
| Key wins | 三個關鍵成果 |
| Key failures | 兩個失敗教訓 |
| 可移植性 | 哪些可借鏡到本公司？哪些受限？ |
| Sources | 公開新聞 / 訪談 / 案例 |

### Tool 3.2 卓越能力特徵定義表 / Excellence Capability Profile

把產業領先模式翻譯成 **本公司具體可衡量的卓越成熟度特徵**。

| 能力領域 | 「卓越」的具體特徵（可量化） | 領先案例佐證 | 本公司目前 vs 卓越差距 |
| --- | --- | --- | --- |
| 客服回應 | 90% 客訴 1 hr 內 AI 分流 + 24 hr 內人工回覆；客訴 root cause 自動歸類 | A 公司 (產業 1) | 5 天 vs 1 天；無 root cause 系統 |
| 報價產出 | 詢價 → 報價 ≤ 4 hr；報價 80% AI 草稿 + 業務微調 | B 公司 (產業 2) | 4 天 vs 4 hr |
| 知識沉澱 | 每月 ≥ 30 條 Skill 入庫；每位員工每月貢獻 ≥ 1 條 | C 公司 (產業 3) | 0 vs 30/月 |
| ... | ... | ... | ... |

> **使用方式**：每個產業 Reference Model 的 Category 都對應 ≥ 1 條「卓越特徵」。Stage 6 會把這些特徵拆解成階段性目標。

### Tool 3.3 五個現成 Benchmark Stub / Five Ready-to-Use Benchmark Stubs

#### Manufacturing — 半導體封測 700 人

- L1 → L3 in 9 months
- 對應 SCOR：Plan / Make / Deliver 全 AI 化
- Wins: 製程異常摘要 Agent、SPC 自動分析、客訴根因 Agent Team
- Failures: 早期跳過 L1 全員，靠 IT 一人撐；資料權限沒打底

#### Hospital — 醫學中心 1,200 人

- L1 → L4 in 12 months
- 對應 APQC：4.0 Deliver、11.0 Knowledge
- Wins: 病患 onboarding RAG、HIS / EMR 整合 Agent、行政摘要
- Failures: 第一階段忽略護理 frontline 抗拒；後補了 L1 課

#### Retail — 連鎖品牌 800 人

- L1 → L4 in 14 months
- 對應 SCOR Deliver + APQC 3.0 Marketing
- Wins: 商品文案 Skill Library、社群輿情 Workflow、新品上市 Agent Team
- Failures: 早期沒設計 Reviewer，AI 文案誤用品牌字眼

#### Financial Services — 區域銀行 2,500 人

- L1 → L3 in 18 months
- 對應 APQC 4.0 + 13.0 Compliance
- Wins: KYC 文件摘要 Workflow、客服分流 Agent
- Failures: 法遵審核耗時；地端 LLM 效能不足

#### Government — 都市政府 5,000 人

- L1 → L2 in 24 months
- 對應 APQC 13.0 Governance + 11.0 Knowledge
- Wins: 公文摘要、市民服務 FAQ
- Failures: 採購程序拖；缺 AI Champion

### Tool 3.5 Cases-as-Benchmarks — 把案例故意寫成可比對的基準

> **核心洞察**：**成熟度 ≡ Benchmarking**。兩者本質都是「**測量現況相對於參考點的距離**」 —— 成熟度模型用抽象的 L1-L5 當參考點；benchmarking 用具體的同業案例當參考點。
>
> 把這兩件事融合：**案例若被刻意寫成「結構化基準格式」，它就同時是「故事」和「尺」** —— 客戶讀完不只是「我看到別人怎麼做」，而是「**我可以立刻算出我跟它的差距 + 預估補上要多久**」。

#### 案例 → 基準 的轉換規則

一般案例是敘事性的（「某公司做了 AI 質檢 PoC，後來成功了」）—— 讀完只有靈感，沒有可比性。

**Benchmark 化的案例**強制以下 9 個欄位俱全，才能被客戶直接拿來算差距：

| # | 必填欄位 | 為什麼這欄是「可比性」的關鍵 |
| --- | --- | --- |
| 1 | **產業 + 規模 (員工數/營收)** | 同產業同規模才有可比意義 |
| 2 | **起點 L-level + 證據** | 給定起點，差距才能算 |
| 3 | **終點 L-level + 證據** | 給定終點，目標才能對齊 |
| 4 | **跨越期間 (月)** | 客戶可估自己需要多久 |
| 5 | **跨越的關鍵能力（對應 RM Category）** | 不是「他們很厲害」，是「他們在 APQC 4.x 從 1 升到 3」 |
| 6 | **每階段投入（人月 + NT$）** | 客戶可估自己預算夠不夠 |
| 7 | **Key wins（3 個可量化）** | 「客訴回應 5 天 → 1 天」不是「客戶滿意度提升」 |
| 8 | **Key failures（2 個踩過的雷）** | 失敗教訓比成功經驗值錢 |
| 9 | **適用條件（什麼樣的公司能複製）** | 不是所有公司都能複製，必須講清楚前提 |

> **缺欄位 ≠ Benchmark**。少一欄就退化回「故事」，無法計算差距。

#### Benchmark-grade 案例範本（M 公司 700 人封測廠 ── ⚠️ AI 模擬虛構案例）

> ⚠️ **本範本為 AI 模擬產生的虛構案例**，並非真實客戶資料。所有數字皆為示例，僅供方法論教學示範用。真實 longitudinal cases 需 Pilot Study 完成後才會替換。詳見 [`../04_Scenarios/README.md`](../04_Scenarios/README.md) 開頭學術誠信聲明。

```
產業 / 規模：    半導體封測，700 人，年營收 NT$ 12 億
起點 L-level：   L0 (全員無公司帳號) + APQC 11.x = 0
終點 L-level：   L3 + APQC 11.x = 3
跨越期間：       9 個月（分 Phase 1 0-6m + Phase 2 6-9m）
跨越的 RM Cat：  
  ├ APQC 4.0 Deliver：     1 → 3（客訴回應 5 天 → 1 天）
  ├ APQC 11.0 Knowledge：  0 → 3（Wiki + Skill Lib 上線）
  ├ Tiger AI L1：          0 → 4（全員 OpenWebUI + 規範簽署 92%）
  ├ Tiger AI L2：          0 → 3（Skill Library 18 條）
  └ Tiger AI L3：          0 → 2（n8n Workflow 5 條上線）
每階段投入：
  ├ Phase 1 (0-6m)：       12 人月 + NT$ 280 萬（含教育訓練）
  └ Phase 2 (6-9m)：       8 人月 + NT$ 180 萬

Key wins（可量化）：
  1. 客訴回應：5 天 → 1 天 (-80%)
  2. 業務提案產出：4 天 → 1 天 (-75%)
  3. 不良率：3.2% → 2.4%（朝 2.0% 目標前進）

Key failures（踩過的雷）：
  1. 第一個月忽略產線 50 位老師傅的抗拒 → 一度全廠停課抗議，
     後改為「升級為 AI 監督者」角色重新溝通才解開。
  2. n8n 試做 PoC 沒走 GitHub 備份 → 一次主機重灌全沒了，
     後補上 Workflow Git 備份 SOP。

適用條件：
  ✓ 300-1500 人製造業
  ✓ 製程資料須地端（合適 Hybrid 部署）
  ✓ 有 IT 協理可兼 AI Champion（0.5-1 FTE）
  ✓ 預算 NT$ 400-800 萬可接受
  ✗ 不適用：< 100 人（規模不經濟）
  ✗ 不適用：完全雲端政策禁止地端的金融業（須改 Variant A）
```

#### 客戶用法：30 分鐘自助算出自己跟基準的差距

把上述範本印給客戶。讓他自己在表格右側填一欄「**我們公司現況**」：

| 欄位 | M 公司 (Benchmark) | 我們公司 | 差距 |
| --- | --- | --- | --- |
| 規模 | 700 人 | 1,200 人 | 規模相近，可比 |
| 起點 APQC 11.0 | 0 | 0 | 一樣 |
| 終點 APQC 11.0 | 3 | 目標 3 | 一樣 |
| 期間 | 9 個月 | 預估 9-12 個月 | 規模較大略長 |
| 預算 | NT$ 460 萬 | 預估 NT$ 700 萬 | 規模較大略多 |
| 必過的雷 | 抗拒 / 備份 | 兩條都要避開 | — |

**讀完此表，客戶 30 分鐘自助完成**：

1. 確認自己的起點
2. 看到具體可達的終點
3. 估出時間與預算
4. 知道必踩的雷
5. 確認自己「適用條件」是否符合（不符合就要客製）

這比顧問花 3 週做訪談給出建議**更具說服力** —— 不是顧問說，是同業案例說。

#### 為什麼這個設計這麼重要

| 一般案例庫 | Benchmark-grade 案例庫（Tiger AI 做法）|
| --- | --- |
| 客戶讀完得到「靈感」 | 客戶讀完得到「差距估算」 |
| 顧問靠經驗解釋差距 | 案例本身就是尺，自帶差距計算 |
| 不可重複（每次都要靠顧問翻譯）| 可重複（客戶 / 新顧問都能算）|
| 7 個案例 = 7 個故事 | 7 個案例 = 7 把尺，跨產業矩陣 |
| Sales 階段難自助 | Sales 階段客戶能 30 分鐘自診 |
| 從卓越到階段拆解要靠顧問 | 案例本身就有 Phase 1/2/3 投入分布 |

#### 跟 Stage 1-8 的銜接 — 案例餵養四個階段

```
Stage 1 As-Is         →  客戶自己的起點 L-level 與 RM Category 分數
                                       ↓
Stage 3 Best Practice →  Benchmark-grade 案例提供「終點 + 期間 + 投入」
                                       ↓
Stage 4 Gap           →  差距 = (案例終點 - 客戶起點)，自帶可量化值
                                       ↓
Stage 6 Phased Goals  →  直接借用案例的 Phase 1/2/3 投入分布做時程拆解
                                       ↓
Stage 8 Risk Register →  案例的 Key failures 直接編進客戶的 Risk Register
```

**整套方法論在這裡形成閉環** —— 案例不只是 Stage 3 的素材，而是同時餵 Stage 1（自診）、Stage 4（差距計算）、Stage 6（時程拆解）、Stage 8（風險預警）。

#### 操作守則 — 案例 → Benchmark 的 5 條紀律

寫每個 `04_Scenarios/SAMPLE_CLIENT_CASE_*.md` 時必須遵守：

- [ ] **9 欄位俱全**（缺一欄就退回作者補）
- [ ] **可量化證據**：「客訴回應 5 天 → 1 天」✓；「客戶滿意度提升」✗
- [ ] **失敗 ≥ 2 個**：只講成功的案例不可信
- [ ] **適用條件明寫**：包括「適用」與「不適用」
- [ ] **匿名但保留可比性**：用代號（M / B / F / E / G）替代真實名稱，但規模 / 產業 / 時間數據必須真實可比

---

### Tool 3.6 客戶 Ideal Practice 共創 Workshop — 讓客戶自己展開「想成為的樣子」

> **核心邏輯**：產業 Best Practice 是**輸入素材**（Tool 3.1-3.5 都是素材）；客戶 Ideal Practice 是**目標基準**。Stage 3 的最終 Output 必須是「客戶**自己選、自己具體化**的 Ideal Practice」，而不是顧問拍給他的「應該做到」。
>
> **為什麼一定要客戶自己展開**：
> 1. **客戶不會否認自己的目標**（顧問訂的目標客戶可以推翻）
> 2. **Gap = (Ideal − As-Is) 的算式中，分子分母都是客戶說的**（科學辯論能力鎖死）
> 3. **後續 Stage 4-8 的整套推理鏈基礎變得無可動搖**（沒人能改變自己當初挑的目標）

#### 共創 Workshop 流程（半天，3-4 小時）

**參與者**：CEO + 部門長 + AI Champion + IT Lead（≥ 5 人）
**主持人**：顧問
**事前準備**：列印 Tool 3.1 產業 Best-Practice Profile（≥ 3 家）、Tool 3.3 五個 Benchmark Stub、Tool 3.4 L1-L5 卓越長相
**場地**：白板 + 便利貼 + Tool 2.7 4 層架構圖列印 A2

#### Step 1：素材展示（30 min）

顧問**只展示、不推薦**：

- 「這是同產業 3 家領先公司的做法」→ 讀 Tool 3.1 profile
- 「這是 5 個現成 Benchmark Stub」→ 讀 Tool 3.3
- 「這是 L1-L5 各級別卓越在實務中長什麼樣」→ 讀 Tool 3.4
- 「這是 4 層架構應有的元件圖」→ 攤開 Tool 2.7 圖

> **紀律**：本階段顧問**禁止說「我建議...」**，只說「同業是這樣...」「業界看到的是這樣...」。

#### Step 2：客戶單獨投票挑「想要成為的樣子」（45 min）

每位參與者**獨立**在便利貼上寫：

- 「**我希望 12 個月後我們公司在哪幾項做到什麼程度**」
- 對應到 Tool 2.7 4 層架構的具體格子
- 每項用「**動詞 + 量化指標**」（例：客訴回應 5 天 → 1 天）

**為什麼要獨立寫不討論**：避免高管定錨效應；讓部門長真實想法浮現。

#### Step 3：集體展開 + 共識化（60 min）

把所有便利貼貼到 4 層架構圖對應格子。顧問引導：

- 哪些格子大家都貼了 → **共識目標**（直接進 Ideal Practice）
- 哪些格子只有一兩張便利貼 → **討論是否要保留**
- 哪些格子完全沒人貼 → **問：是不重要還是被遺忘了**

形成 v1 客戶 Ideal Practice 草稿。

#### Step 4：可行性 reality check（45 min）

對 v1 草稿，顧問**首次主動介入**用 Tool 6.3 組織吸收力評估（6 維度：預算、AI Champion、IT FTE、權限治理、員工 AI 素養、變革容量）反問：

- 「您預算上限 NT$ 800 萬，能撐得起這些目標嗎？」
- 「您 IT 只有 2 FTE，第二季要加 ERP 整合做得到嗎？」
- 「12 月母公司審計，您敢承諾這些目標 6 個月內出 Quick Win 嗎？」

讓客戶**自己**砍掉做不到的、保留做得到的。形成 v2 Ideal Practice。

#### Step 5：客戶 Ideal Practice 定義表（30 min）

把 v2 落定為以下表格（**這張表就是 Stage 3 的 Output KPI，直接餵 Stage 4 Gap Analysis**）：

| # | 能力領域 | 對應 RM Category | 客戶 Ideal Practice（具體可量化）| 12 個月後想到的程度（L 級）| 證據條件（達到的觀察標準）|
| --- | --- | --- | --- | --- | --- |
| 1 | 客訴回應 | APQC 4.4 + Tiger AI L3 | 90% 1hr 分流 + 24hr 人工回 | L3 = 3 | n8n Workflow 連到 Gmail + Reviewer 簽核率 ≥ 95% |
| 2 | 知識沉澱 | APQC 11.x + Tiger AI L2 | 每月 ≥ 20 條 Skill 入庫（先不追求 30 條）| L2 = 3 | Skill Library Git repo + Owner + IPOE 文件 |
| 3 | 製程根因 | SCOR Make + Tiger AI L4 | 異常 → 假設 ≤ 1hr（先不追求 30min）| L4 = 2 | Hermes Agent + 5 個任務 Reviewer 通過 |
| ... | ... | ... | ... | ... | ... |

**每一列都是客戶簽過名的承諾**。Stage 4 Gap Analysis 直接拿這張表做減法。

#### Step 6：客戶簽名（15 min）

CEO / Sponsor / AI Champion 三方簽署 Ideal Practice 定義表。這個簽署是**整個顧問案的轉折點** —— 後續任何「我們其實不要這樣」都要回來改這張表，**不能憑空否認結論**。

#### 為什麼這 6 步驟的順序不可顛倒

| 順序 | 為什麼必須這樣 | 顛倒會怎樣 |
| --- | --- | --- |
| 1. 素材展示 → 2. 獨立投票 | 先看素材再寫，避免空想；獨立寫避免高管定錨 | 先討論後投票會被 CEO 一句話定調 |
| 2. 投票 → 3. 共識化 | 先有差異才有共識的價值 | 跳過獨立投票會以為一致其實沒共識 |
| 3. 共識 → 4. Reality check | 先有理想再被現實磨 | 先磨現實會自我設限 |
| 4. Reality → 5. 定義表 | 確認可行後才寫成 commit | 直接寫表會跳過可行性 |
| 5. 定義表 → 6. 簽名 | 簽名前必須有具體文字 | 沒文字的簽名是空頭 |

#### Tool 3.6 跟 Stage 4-8 的鎖死關係

```
Tool 3.6 客戶 Ideal Practice 定義表
        │
        ▼
Stage 4 Gap Analysis
  Gap = (客戶 Ideal − 客戶 As-Is)  ← 兩端都是客戶說的，無法否認
        │
        ▼
Stage 5 Problem Definition
  80/20 收斂的對象是「客戶自己挑的目標」  ← 無法說「這不是我們要的」
        │
        ▼
Stage 6 Phased Goals
  把客戶 Ideal 拆 Phase 1/2/3       ← 無法否認終點
        │
        ▼
Stage 8 價值追蹤矩陣
  追蹤標的 = 客戶當初簽的指標         ← 無法否認量測
```

> **這就是顧問報告「科學辯論能力」的底層機制**：所有後續推理的起點 Y（Ideal）和終點 X（As-Is）都是客戶說的，顧問只負責計算 Gap = Y − X 和 Roadmap 拆解。**結論可被客戶反證的唯一方式是回去改自己當初簽的 Ideal Practice 定義表** —— 而那是高度公開、有簽名的文件。

#### 顧問常犯的錯誤（Anti-Patterns）

- ❌ **直接拿 Tool 3.4 的 L1-L5 卓越描述當作客戶目標**：「我們建議您 12 個月達到 L4」→ 客戶可以說「我們不一樣」推翻
- ❌ **拿 Tool 3.2 卓越能力特徵當作客戶 Ideal**：客戶沒參與設定 → 後續不買單
- ❌ **跳過 Step 6 簽名**：沒有簽署的 Ideal 隨時可被修改 → 整套推理鏈崩塌
- ✅ **正確做法**：把 Tool 3.1-3.5 全部當素材，跑完 6 步驟讓客戶簽出他的 Ideal Practice

---

### Tool 3.4 L1-L5 卓越在實務中看起來像 / What Excellence Looks Like at Each Level

| Level | 在實務中看起來像 | 客戶常說的話 | 常見誤解需澄清 |
| --- | --- | --- | --- |
| L1 Controlled AI Access | 全員有公司帳號、會用、有規範 | 「我們有買 ChatGPT」 | 買 ChatGPT ≠ 全員會用、≠ 有治理 |
| L2 Knowledge Codification | Skill Library + 版本控制 | 「我有寫 Prompt 庫」 | Prompt 庫 ≠ 可被別人重用 |
| L3 Workflow Automation | n8n PoC 在跑 + 串到系統 | 「我們有自動化」 | RPA / Zapier ≠ AI Workflow |
| L4 Autonomous Agent | Agent 通過階段驗收 + 有 Wiki | 「我們在用 Agent」 | Demo Agent ≠ 受控 Agent |
| L5 Multi-Agent Organization | 多 Agent 完成跨部門任務 | 「我們在做 AI 團隊」 | Chatbot 群 ≠ Agent Team |

---

## Stage 4：Gap Analysis / 差距分析

> **目的**：結構化比對「Stage 1 現況」與「Stage 2 標準 + Stage 3 卓越」，分類為 Missing / Broken / Redundant 三類缺口。
>
> **Output KPI**：差距矩陣（Impact × Effort）。
>
> ⚠️ **核心紀律**：Gap Analysis 是「客觀差距盤點」，**不是風險評估**。風險屬於 Stage 8 的 Risk Register。差距分析只回答「差什麼、差多少、做了影響多大」，**不回答「不做會出什麼事」**。混在一起會讓 Stage 4 變成主觀判斷。

### Tool 4.1 Missing / Broken / Redundant 表

| 領域 / Area | 類型 (M/B/R) | 描述 / Description | 對應 Reference Model | 對應卓越特徵 | 嚴重度 1-5 | 擁有者 / Owner |
| --- | --- | --- | --- | --- | --- | --- |
| 客服信件分類 | **Missing** | 完全沒有 AI 分類 | APQC 4.4 客服 | 卓越=1hr 分流 | 4 | 客服長 |
| 報價系統 | **Broken** | 業務手動 copy-paste | SCOR Source + Deliver | 卓越=4hr 報價 | 5 | IT 協理 |
| 工單系統 | **Redundant** | Notion + Trello + Email 三套 | APQC 8.x | (無對應卓越) | 3 | COO |
| 知識管理 | **Missing** | 無 Wiki、無 SOP | APQC 11.x | 卓越=每月 30 條入庫 | 5 | HR + AI Champion |
| ... | ... | ... | ... | ... | ... | ... |

#### M / B / R 三類定義

- **Missing**：應有但完全沒有（對照 Stage 2 標準框架找出來的空格）
- **Broken**：有但運作不良（人工撐、出錯、慢、無法稽核）
- **Redundant**：重複、多餘、低價值（多套系統做同一件事、人工搬資料）

### Tool 4.2 Impact × Effort 矩陣

```
            Low Effort                   High Effort
           ┌──────────────────────┬──────────────────────┐
High       │  ★ Quick Wins        │  Big Bets            │
Impact     │  - Gmail 分類          │  - ERP Agent          │
           │  - Sheet 自動計分      │  - 跨部門 Team         │
           ├──────────────────────┼──────────────────────┤
Low        │  Fill-ins            │  ✗ Avoid              │
Impact     │  - 內部 FAQ          │  - 大客製 chatbot      │
           │  - 簡報模板           │                       │
           └──────────────────────┴──────────────────────┘
```

**置入規則**：

- Impact 計分：直接 NT$ 影響 × 受益人數 × 戰略重要度，得 1-5
- Effort 計分：人天 × 系統整合難度（**不含風險，風險屬 Stage 8**），得 1-5
- ≥3 為 High

### Tool 4.3 Prioritization Worksheet

| 候選案 | Impact (1-5) | Effort (1-5) | Strategic Fit (1-5) | Score = (I × SF) / E | 排名 |
| --- | ---: | ---: | ---: | ---: | ---: |
| 客服信件分類 PoC | 4 | 1 | 5 | 20 | 1 |
| 業務提案 Skill | 4 | 2 | 4 | 8 | 4 |
| ERP Agent | 5 | 5 | 5 | 5 | 5 |
| Sheet 自動計分 | 3 | 1 | 3 | 9 | 3 |
| 跨部門 Team | 5 | 4 | 5 | 6.25 | (Big bet 入後段) |

> **產出**：差距矩陣 + 優先級排序。**全部交給 Stage 5 用 80/20 收斂為核心問題**。

---

## Stage 5：Problem Definition / 結論與核心問題定義

> **目的**：運用 80/20 原則收斂議題，鎖定具槓桿效應的核心病灶，區分症狀與真因。
>
> **Output KPI**：高階問題定義聲明（Executive Problem Statement）。

### Tool 5.1 80/20 收斂工作表 / 80/20 Convergence Worksheet

從 Stage 4 一堆差距中，找出「**改善 20% 的差距，能解決 80% 的痛**」的核心病灶。

```
Step 1：列出 Stage 4 全部差距（M/B/R 不分類混排）
Step 2：每個差距標註「影響的 process 數量」、「影響的部門數量」、「影響的 KPI 條數」
Step 3：找出「影響面積最大」的 3-5 個差距 → 這些是「核心病灶候選」
Step 4：對每個核心病灶問「為什麼？」往下追 5 層 → 找真因
Step 5：真因若有 1-2 個被反覆提到 → 這就是核心問題
```

#### 範例（製造業）

```
高影響差距：
A. 客服回應慢   → 影響：3 個 process、4 部門、客戶滿意度 KPI
B. 報價慢       → 影響：5 個 process、3 部門、營收 KPI
C. 知識無沉澱  → 影響：所有部門、新人 onboarding KPI
D. 製程異常慢 → 影響：2 個 process、1 部門、不良率 KPI

5 Whys（C 知識無沉澱）：
  Why? → 沒人寫
  Why 沒人寫？ → 寫了沒人用
  Why 沒人用？ → 散在各處找不到
  Why 找不到？ → 沒中央 Wiki
  Why 沒中央 Wiki？ → **沒人 own 這件事 + 沒工具 + 沒誘因** ← 真因

核心問題（候選）：
公司沒有「知識資產化」的角色、工具與誘因，導致 80% 的差距（A/B/C/D）
都源於「同樣的事重複做、無人沉澱、無人重用」。
```

### Tool 5.2 Problem Statement Worksheet (5 sections)

```
1. CONTEXT / 情境
   過去 12 個月發生了什麼讓 AI 變成優先議題？

2. TENSION / 張力
   目前的「現實」與「期望」差距是什麼？具體量化（引用 Stage 3 卓越特徵）。

3. COST OF INACTION / 不行動的代價
   不做 AI 12 個月後會發生什麼？金額？

4. DESIRED FUTURE / 期望未來
   12 個月後成功長什麼樣？三個可量化指標（對齊 Stage 3 卓越特徵）。

5. CONSTRAINTS / 限制條件
   預算？人力？合規？時程？哪些選項已被排除？
```

### Tool 5.3 Common Pitfalls Checklist (10 anti-patterns)

- [ ] 把 AI 寫成科技議題（應寫成業務議題）
- [ ] 沒有量化「不行動的代價」
- [ ] 把「導 AI」當目標（應該是業務 KPI）
- [ ] 把所有部門都列為高優先（無聚焦）
- [ ] 只談機會、避談風險
- [ ] 用「資安」當擋箭牌阻止任何嘗試
- [ ] 把治理寫成 IT 議題（應全公司議題）
- [ ] 期望時程過短 / 過長
- [ ] 沒有 sponsor / 沒有 champion
- [ ] 沒有失敗退場機制

### Tool 5.4 Sample 完整問題定義（製造業）

```
CONTEXT:
過去 12 個月，三家直接競爭對手導入 AI 質檢與客訴 Agent，公司客戶開始質疑為何
我們交期慢、客訴回應慢。客戶 A 季度訂單下降 18%。

TENSION:
公司目前不良率 3.2%（業界領先 1.8%），客訴平均回應 5 天（業界 2 天），
業務提案產出 4 天（業界 1.5 天）。

COST OF INACTION:
若 12 個月內無顯著改善，預計流失客戶 A、B、C，年營收影響約 NT$ 1.8 億。
另招募 8 位品保與業務的招募成本約 NT$ 1,200 萬。

DESIRED FUTURE:
12 個月後：不良率降至 2.0%、客訴回應 ≤ 1 天、業務提案產出 ≤ 1 天。
建立 1 個製程改善 Agent Team 與 1 個業務 Skill Library。

CONSTRAINTS:
- 預算上限 NT$ 800 萬 (含教育訓練 + 平台 + 顧問)
- 製程資料須地端處理（不能上雲）
- IT 人力 2 FTE 不可再增
- 12 月母公司審計，第一個 Quick Win 須在 6 個月內展現
```

---

## Stage 6：Benchmarking & Phased Goals / 標竿對照與多階段目標設定

> **目的**：將 Stage 3 的「終極標竿」拆解為多個「**組織可吸收**」的階段性目標（如基礎穩固期、效能優化期、標竿卓越期），並定義每階段的驗收標準（Stage Gate Criteria）。
>
> **Output KPI**：階段性目標定義與驗收標準。
>
> **核心思維**：終極標竿一次到位 = 失敗。組織有「吸收上限」 —— 文化、人力、IT、預算都吃不下太大跳躍。Stage 6 的工作是把卓越拆成 3-4 段每段都消化得了的小台階。

### Tool 6.1 終極標竿 vs. 階段性目標拆解表 / Ultimate Benchmark → Phased Goals Decomposition

| 能力領域 | 終極標竿（Stage 3 卓越特徵） | Phase 1：基礎穩固期 (0-6m) | Phase 2：效能優化期 (6-12m) | Phase 3：標竿卓越期 (12-24m) |
| --- | --- | --- | --- | --- |
| 客服回應 | 90% 客訴 1hr 分流 + 24hr 回覆 | 全員 Chat AI 入口 + Prompt 模板 | n8n 客訴自動分類 + Reviewer | Hermes Agent 自動回覆草稿 + 根因 |
| 報價產出 | 詢價→報價 ≤ 4hr | 業務 Skill 寫提案 | n8n 報價草稿 Workflow | Agent 自動讀 ERP + 產報價 |
| 知識沉澱 | 每月 30 條 Skill 入庫 | 5 條核心 Skill + Owner | 15 條 + 跨部門複用 | 30 條 + Wiki 自動引用 |
| 全公司 AI 治理 | 完整 Audit + ROI 儀表板 | 規範文件 + Admin Panel | 部門 Skill 治理 | 全公司治理儀表板 |

> **使用方式**：每個 Stage 3「卓越特徵」必須對應一條 Phase 1→2→3 的拆解路徑。任何「Phase 1 直接到 Phase 3」的計畫都是組織吸收力的紅旗。

### Tool 6.2 階段性目標定義與驗收標準 / Stage Gate Criteria

#### Phase 1 驗收（基礎穩固期）

- [ ] **L1 Gate**：OpenWebUI 全員帳號開設完成
- [ ] AI 使用規範文件簽署率 > 90%
- [ ] Prompt Library 收集 ≥ 30 條
- [ ] Admin Panel 權限矩陣設定完成
- [ ] 5 個核心 Skill 上架（含 Owner、版本、IPOE）
- [ ] L2 候選 Skill 名單 ≥ 5
- [ ] **HITL 設計確認**：所有對外輸出（客戶、合規）皆有人工審核節點

#### Phase 2 驗收（效能優化期）

- [ ] **L2 Gate**：Skill Library 上架 ≥ 15 個 Skill
- [ ] 每個 Skill 有 Owner、版本、IPOE 文件
- [ ] Antigravity / Claude Code artifacts 提交
- [ ] **L3 Gate**：n8n Workflow PoC ≥ 3 個上線
- [ ] Sub-workflow Library 結構完成
- [ ] Data Tables Schema 確定
- [ ] GitHub Backup SOP 執行
- [ ] L4 Workflow Contract 與 Hermes 對接規格

#### Phase 3 驗收（標竿卓越期）

- [ ] **L4 Gate**：Hermes Agent 通過子驗收 4A-4E
- [ ] Wiki ingest/query/update 都跑通
- [ ] briefing 模板與實際 brief 案例
- [ ] Evidence 追溯：input → process → output → log
- [ ] **L5 Gate**：ClawTeam Role Cards 完成
- [ ] Task allocation table 含依賴鏈
- [ ] 1 次跨部門 Agent Team 演練成功
- [ ] Reviewer + HITL 設計
- [ ] ROI tracking matrix 啟動

### Tool 6.3 組織吸收力評估 / Organizational Absorption Capacity Assessment

避免設定「組織吃不下」的階段目標。每階段啟動前評估這 6 項：

| 維度 | Phase 1 需要 | Phase 2 需要 | Phase 3 需要 | 本公司目前 |
| --- | --- | --- | --- | --- |
| **預算** (年) | NT$ 50-150 萬 | NT$ 150-400 萬 | NT$ 400 萬+ | `[填]` |
| **AI Champion** | 1 位（兼） | 1 位（專） + 部門 lead | 2-3 位專職團隊 | `[填]` |
| **IT FTE** | 0.2 | 0.5-1 | 1-2 | `[填]` |
| **資料權限治理** | 規範 + Admin | 部門權限矩陣 | Audit Log 全公司 | `[填]` |
| **員工 AI 素養** | 70% 會用 Chat | 30% 會寫 Skill | 10% 會設計 Workflow | `[填]` |
| **變革容量** (同時專案數) | 1-2 | 2-3 | 3-5 | `[填]` |
| **Prior Knowledge** 先備知識 *(新)* | 過去 BPM/Lean/Six Sigma + 1 次 AI/RPA 嘗試 | + 軟體開發內部能力 | + 跨產業參訪 / 學術合作 | `[填]` |
| **Internal Knowledge Flow** 內部知識流動 *(新)* | 部門共享文件平台 | + 跨部門 review 例行 | + 內部 mentor / 講師制度 | `[填]` |

> **吸收力不夠 → 拉長該階段時程，或縮減該階段目標**。不要硬推。
>
> **理論依據**：Cohen & Levinthal (1990) Absorptive Capacity Theory；Prior Knowledge + Internal Knowledge Flow 是組織能否「吸收」新能力的決定因素。詳見 [`../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md`](../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md) §3。

#### Tool 6.3-Extension: Task-Technology Fit (TTF) Assessment（任務-科技適配度）

**不是每個部門都該走到 L5**。依任務特性決定該部門合適的 L 級終點：

| 部門 | 任務特性 (Routine / Non-routine) | 合理 L 級終點 | 理由 |
| --- | --- | --- | --- |
| 客服 (FAQ + 標準問題) | 高度 Routine | L3-L4 | AI 適配度高、HITL 成本低 |
| 業務（提案 + 商機判斷）| 中度 Routine + 部分判斷 | L2-L3 + HITL | AI 草稿 + 人工確認 |
| 製程根因 | 中度 Routine（規則明確）| L3-L4 + Reviewer | 異常分類可自動 + 對策需人 |
| M&A / 策略決策 | 高度 Non-routine | L1-L2（個人助理）| AI 輔助、人主導；強推 L4-L5 反傷判斷品質 |
| 法律 / 醫療診斷 | 高合規敏感 | L2-L3 + 強 HITL | 法規風險高，不宜 L4-L5 |

> **理論依據**：Goodhue & Thompson (1995) Task-Technology Fit。Stage 3 客戶 Ideal Practice 共創 Workshop 中，每個部門的目標 L 級必須通過 TTF 檢核 → 不能盲目衝 L5。

---

## Stage 7：To-Be Design / 未來藍圖設計

> **目的**：設計具體可落地的「**多階段演進藍圖**」與「**人機協作架構**」，而不只是技術架構圖。每階段都有獨立的 To-Be Operating Model。
>
> **Output KPI**：分階段未來營運模型圖（To-Be Operating Model）、未來流程圖。

### Tool 7.1 分階段 To-Be Operating Model / Phased To-Be Operating Model

每個 Phase 畫一張 To-Be Operating Model 圖。包含：

```
Phase 1 To-Be Operating Model（基礎穩固期）
==========================================
[個人層]   全員 OpenWebUI 帳號 → 有規範、有 Admin Panel
[部門層]   每部門產出 5 條核心 Prompt / Skill
[流程層]   尚未自動化（人工 + AI 輔助）
[系統層]   Gmail / Sheets / Notion 已連接
[治理層]   AI 規範 + 權限矩陣 + 月度 review
[人機分工] 100% 人主導，AI 是個人助理

Phase 2 To-Be Operating Model（效能優化期）
==========================================
[部門層]   Skill Library 15+ 條
[流程層]   3-5 個高價值 Workflow 自動化（n8n）
[系統層]   Gmail/Sheets/CRM/ERP 雙向串接
[治理層]   部門 Owner + Workflow uptime 監控
[人機分工] 70% 人主導 + 30% Workflow 自動 + HITL 審核

Phase 3 To-Be Operating Model（標竿卓越期）
==========================================
[組織層]   1-2 個 Hermes Agent + 1 個 ClawTeam
[治理層]   全公司 Audit Log + ROI 儀表板
[人機分工] 50% 人主導 + 30% Workflow + 20% Agent 自主（含 HITL）
```

### Tool 7.2 人機協作架構 / Human-AI Collaboration Architecture

每個關鍵 process，明確定義「人做什麼、AI 做什麼、HITL 在哪、責任歸屬、心理安全」（社會技術系統設計）。

| Process | 人的角色 | AI 的角色 | HITL 節點 | **責任歸屬** *(新)* | **心理安全保障** *(新)* | 驗收標準 |
| --- | --- | --- | --- | --- | --- | --- |
| 客服回覆 | 審核草稿 + 主動關懷 | 分類、優先級、產草稿 | 寄出前 100% 人審 | AI 草稿責任 = AI Champion；最終回覆責任 = 客服員工 | 員工有權「我覺得 AI 答錯可不審直接退」不被責難 | 草稿可直接寄出率 ≥ 60% |
| 業務提案 | 客戶關係、議價、決策 | 產內容草稿、查歷史 | 提交前 100% 人審 | AI 草稿 = AI Champion；提案決策 = 業務 Lead | 業務有權拒用 AI 建議並 log 原因 | 提案產出 ≤ 1 天 |
| 月結異常 | 判斷、處置 | 找異常、產摘要 | 處置前 100% 人審 | AI 摘要 = Finance Agent Owner；處置決策 = 財務主管 | 拒用 AI 建議不影響績效評分 | 異常發現 ≤ 1 天 |
| 製程 root cause | 跨部門協調、決策 | 整理資料、產假設 | 採行對策前 100% 人審 | AI 假設責任 = Agent 開發者；採用對策 = 製程主管 | 主管有「拒絕採用 AI 建議」的正式 SOP | root cause 報告 ≤ 2 天 |

> **理論依據**：Sociotechnical Systems (Bostrom & Heinen, 1977) + Trust in AI (Glikson & Woolley, 2020) + Psychological Safety (Edmondson, 1999)。HITL 不只是「人審」，必須含**責任歸屬清楚** + **拒用 AI 不被責難**，否則演算法厭惡 / 過度依賴必然發生。詳見 [`../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md`](../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md) §6。

### Tool 7.2-Extension: Dynamic Capability Worksheet（動態能力檢核）

每個 To-Be 設計必須回答 Teece (2007) 三組微基礎；不答這 3 題的 To-Be 只是「自動化現狀」，不是真正的轉型：

| 動態能力 | 對 To-Be 的提問 | M 公司範例答 |
| --- | --- | --- |
| **Sensing 感知** | 這個 AI 設計幫公司「**感知**」什麼外部訊號？ | 客訴 Agent 監測客戶滿意度趨勢；製程異常 Agent 監測客戶質量規格變化 |
| **Seizing 捕捉** | 當訊號出現，公司能「**捕捉**」多快？ | Quick Win：客訴回應從 5 天降到 1 天，把客戶流失機會壓縮到最小 |
| **Transforming 重構** | 這套 AI 如何讓組織「**自我重構**」？ | L5 ClawTeam 跨部門 Agent = 不再依賴特定資深員工的知識壟斷 |

> **理論依據**：Teece, Pisano & Shuen (1997); Teece (2007) Dynamic Capabilities。詳見 [`../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md`](../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md) §5。

### Tool 7.3 Skill Map Template / Skill 地圖

| Skill | Owner | Inputs | Outputs | Tools used | L-level | Status |
| --- | --- | --- | --- | --- | --- | --- |
| 客戶提案草稿 | Sales Lead | 客戶資料 + 過往提案 | Word 提案 | Antigravity + Claude | L2 | Live |
| 客訴分類 | CS Lead | Gmail 信件 | 分類 + 優先級 | n8n + Claude | L3 | PoC |
| 月結異常摘要 | Finance | SAP 報表 | 異常表 + 行動 | n8n + GPT-4 | L3 | Build |
| ... | ... | ... | ... | ... | ... | ... |

### Tool 7.4 Workflow Map Template / Workflow 地圖

| Workflow | Trigger | Steps (n8n) | Systems | Skills called | Output | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| 客服信分類 | Webhook (Gmail) | Webhook → Set → OpenAI Chat → Switch → Gmail Label | Gmail | "客訴分類" | 標籤 + 通知 | CS Lead |
| 客戶月度報告 | Schedule (1st of month) | Schedule → SAP API → Sheet → Claude → Email | SAP, Sheets, Gmail | "月結摘要" | PDF + Email | Finance |
| ... | ... | ... | ... | ... | ... | ... |

### Tool 7.5 Agent Map Template / Agent 地圖

| Agent | Role | Skills used | Workflows used | Wiki | Reviewer | 階段驗收 |
| --- | --- | --- | --- | --- | --- | --- |
| 客服 Triage Agent | 客訴分流與草稿 | 客訴分類, 草稿產生 | 客服信分類 | FAQ + 過往案例 | CS Manager | L4 ✓ |
| 業務 Briefing Agent | 拜訪前 brief | 客戶研究, 商機摘要 | CRM 摘要 | 客戶 history | Sales Lead | L4 ✓ |
| ... | ... | ... | ... | ... | ... | ... |

### Tool 7.6 Integration Architecture / 整合架構 (3 variants)

#### Variant A: Cloud-first

```
[OpenWebUI Cloud] → [n8n Cloud] → [Hermes Cloud Agent] → [SaaS APIs]
                                       ↓
                                 [Notion / Sheets / Gmail]
LLM: OpenAI / Claude / Gemini API
適用：低敏感、快速 PoC、預算有限
```

#### Variant B: Hybrid

```
[OpenWebUI On-Prem] → [n8n Self-host] → [Hermes Local Agent]
                            ↓                  ↓
                      [SaaS APIs]      [本地 SQL / ERP]
LLM 路由：低敏感→雲、機敏→地端 Llama
適用：金融、醫療、製造機敏資料
```

#### Variant C: Full On-Prem

```
[OpenWebUI Local] → [n8n Local] → [Hermes Agent Local]
                       ↓                ↓
                 [Local APIs only]  [Local Llama 70B + Embedding]
無雲端 LLM 呼叫
適用：政府、國防、頂級金融
```

---

## Stage 8：Implementation & Change / 執行導入與變革治理

> **目的**：採取「**階段先行、逐步推廣**」策略，每一階段驗收皆需回頭核對 Reference Model（Stage 2）。除執行 Roadmap 外，還必須做變革管理、風險治理、價值追蹤。
>
> **Output KPI**：轉型路徑圖（Transformation Roadmap）、變革管理計畫、價值追蹤矩陣。
>
> **核心思維**：方法論前 7 階段都是「設計」，Stage 8 才是「組織真的會不會成功」的關鍵 —— 變革管理（人）、治理（規則）、追蹤（數據）三件事都要落地。

### Tool 8.1 Transformation Roadmap / 轉型路徑圖

| Quarter | Phase | Theme | Deliverables | Owner | 階段驗收 (對應 Stage 6) | KPI |
| --- | --- | --- | --- | --- | --- | --- |
| Q1 | Phase 1 | 診斷 + L1 啟動 | 全員 OpenWebUI、AI 規範、Prompt Library | IT + AI Champion | L1 Gate | 80% 員工每週使用 |
| Q2 | Phase 1→2 | L2 + L3 PoC | 5 個 Skill、3 個 n8n Workflow PoC | AI Champion + 部門 | L2 + L3 Gate | Skill ≥3、Workflow uptime 95% |
| Q3 | Phase 2 | L4 Pilot | 1 個 Hermes Agent | AI Champion + IT | L4 Gate | Agent 完成 5 任務、Reviewer 通過 |
| Q4 | Phase 2→3 | L4 Scale | 3 個 Agent、跨部門整合 | 部門 Lead | L4 ext. | 每月節省工時 ≥ 200 hr |
| Q5-Q6 | Phase 3 | L5 Pilot | 1 個 ClawTeam | Sponsor + AI Champion | L5 Gate | Team 完成 ≥ 1 跨部門任務 |

> **每個季度結尾必做**：回頭核對 Stage 2 的 Reference Model 完整度雷達圖 —— 雷達是否更圓？哪些 Category 還是空？這決定下一季是繼續推進還是回頭補。

### Tool 8.2 變革管理計畫 / Change Management Plan

| 維度 | Phase 1 (基礎) | Phase 2 (優化) | Phase 3 (卓越) |
| --- | --- | --- | --- |
| **Stakeholder Map** | Sponsor、AI Champion、IT、HR | + 部門 Lead | + 全公司 |
| **溝通計畫** | 月會 + 月報 + Wiki | 雙週站會 + 部門報告 | 季度全員大會 + 季報 |
| **訓練計畫** | L1 全員 4hr + L2 部門代表 8hr | L2 部門全員 + L3 IT/Champion | L4-L5 高階訓練 |
| **抗拒處理** | 主管以身作則 + 早期採用者表揚 | 績效 KPI 納入 | 文化內化 + 人才晉升 |
| **早期採用者** | 5-10 位 (跨部門) | 部門全員 | 全公司 |
| **慶祝里程碑** | L1 Gate Party | 第一個 Workflow 上線 | 第一個 Agent 通過 |

#### 抗拒處理 Playbook（依抗拒類型）

| 抗拒類型 | 典型訊號 | 處理方式 |
| --- | --- | --- |
| **怕被取代** | 「AI 會搶我的工作」 | 1:1 對話 + 重新定義角色（升級為 AI 監督者） |
| **不會用** | 「我學不來」 | 1對1 mentor + 簡化第一個成功經驗 |
| **不信任** | 「AI 會出錯」 | 先給「人審」場景 + 累積信任 |
| **怕擔責** | 「出事誰負責」 | 明確 HITL 節點 + 究責邊界文件 |
| **既得利益受損** | 「這影響我的部門控制力」 | Sponsor 介入 + 重新分配 KPI |
| **演算法厭惡 (Algorithm Aversion)** *(新)* | AI 一次出錯後集體拒用 | 透明化錯誤率（人 vs AI 對比）+ 漸進信任建立（先低風險場景）+ 員工有「拒用權」不被責難 |
| **演算法過度依賴 (Automation Complacency)** *(新)* | 員工不審核就 approve | Reviewer Workflow 強制隨機抽樣 + 錯誤偵測後重新教育 + KPI 含「審核品質」非只「審核速度」|

### Tool 8.3 RACI / Stakeholder Alignment Matrix

| 議題 / Topic | 高層 Sponsor | AI Champion | IT | 一線使用者 | 資料 Owner |
| --- | --- | --- | --- | --- | --- |
| 願景與 Roadmap | A | R | C | I | I |
| Reference Model 選用 | A | R | C | I | C |
| 工具選型 | A | C | R | C | C |
| 帳號 / 權限 | I | C | R | I | A |
| Skill / Workflow 建置 | I | A | R | R | C |
| 變革管理 | A | R | C | C | I |
| Audit / 治理 | A | C | R | I | R |
| 價值追蹤 / ROI | A | R | C | I | I |

(R=Responsible, A=Accountable, C=Consulted, I=Informed)

### Tool 8.4 Permission / Governance Matrix

| Role | Resource | Read | Write | Approve | Audit |
| --- | --- | --- | --- | --- | --- |
| 全員 | OpenWebUI 個人區 | ✓ | ✓ | ✗ | self |
| 部門 Lead | 部門 Skill Library | ✓ | ✓ | ✓ | dept |
| AI Champion | 全公司 Workflow | ✓ | ✓ | ✓ (≤ L3 階段) | all |
| IT Admin | 全部 + 模型 + Audit Log | ✓ | ✓ | ✓ (L4-L5 階段) | all |
| Sponsor / CIO | 全公司 read + Approve | ✓ | ✗ | ✓ (L5 階段) | all |
| 法遵 / 內稽 | Audit Log only | ✓ | ✗ | ✗ | all |

### Tool 8.5 價值追蹤矩陣 / Value Tracking Matrix

> 對應圖卡的「價值追蹤矩陣」，取代過去的「ROI Tracking」單一視角。價值不只是錢 —— 含時間、風險、知識資產、員工體驗。

| Initiative | 維度 | Baseline | Target | Actual | Period | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 客服信分類 | 時間 | 5 days | 1 day | 1.2 day | M3 | CS Lead | 🟡 95% |
| 客服信分類 | 風險 | 漏案 5%/月 | 1%/月 | 1.5%/月 | M3 | CS Lead | 🟡 |
| 業務提案 | 時間 | 4 days | 1 day | 0.8 day | M4 | Sales Lead | 🟢 |
| 業務提案 | 員工體驗 | 滿意度 6/10 | 8/10 | 8.5/10 | M4 | Sales Lead | 🟢 |
| 月結異常摘要 | 時間 | 3 days | 0.5 day | 0.6 day | M5 | Finance | 🟢 |
| Hermes Agent 任務 | 規模 | n/a | 50/月 | 38 | M6 | AI Champion | 🟡 |
| 知識資產 | 累積 | 0 條 | 30 條 | 22 條 | M6 | AI Champion | 🟡 |
| ClawTeam 跨部門 | 規模 | n/a | 1/季 | 0 | M9 | Sponsor | 🔴 (delay) |

#### 六大追蹤維度（含 Real Options 戰略選擇權）

1. **時間** — 處理時間縮短
2. **品質** — 錯誤率下降、重工減少
3. **規模** — 受惠人數、處理量
4. **風險** — 漏案、合規違規、機敏外流
5. **資產** — Skill 條數、Wiki 條目、Agent 數
6. **戰略選擇權 (Strategic Options)** *(新)* — 此投資**保留了什麼「未來行使的權利」**？
   - 例：L1 基礎 → 未來可快速擴 L4-L5 的選擇權
   - 例：L2 Skill Library → 未來多家 Agent 可 plug-in 的選擇權
   - 例：L3 Workflow → 未來可整合任何新系統的選擇權
   - 例：L4 Agent Pilot → 未來 L5 ClawTeam 的選擇權

> **理論依據**：Dixit & Pindyck (1994) + McGrath (1997) Real Options Theory。L4-L5 高度不確定投資**傳統 NPV / IRR 必然低估**；用 Real Options 邏輯說服 CFO「**今天投資是買未來的選擇權**」。詳見 [`../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md`](../00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md) §7。

### Tool 8.6 Risk Register / 風險登錄

> 從原 Stage 6 移到 Stage 8 —— 風險屬於 Implementation 階段（執行時可能出什麼事），不是 Gap Analysis 階段（盤點現在差什麼）。

| Risk | Likelihood | Impact | Mitigation | Owner | Trigger |
| --- | --- | --- | --- | --- | --- |
| 員工抗拒 | High | High | 變革管理 Playbook + L1 全員體驗 | HR + Sponsor | adoption < 50% in 30d |
| 機敏外流 | Medium | Critical | redact policy + audit log + Hybrid 部署 | CIO | DLP alert |
| LLM 幻覺造成決策錯誤 | High | Medium | Reviewer / HITL + evidence | AI Champion | 任一決策被推翻 |
| 預算超支 | Medium | Medium | 月度 KPI / 價值追蹤檢視 | CFO | 月支出 > 110% 預算 |
| AI 廠商失聯 / 漲價 | Medium | High | 多廠 LLM 路由 + 地端備援 | IT Admin | 廠商 outage > 4hr |
| 階段目標吃不下 | Medium | High | Stage 6 吸收力評估 + 拉長時程 | Sponsor | Phase 驗收延遲 > 30d |
| ... | ... | ... | ... | ... | ... |

### Tool 8.7 Audit Log Requirements / 稽核日誌要求

| Event Type | Captured by | Retention | Reviewer |
| --- | --- | --- | --- |
| LLM call (prompt + response) | n8n / OpenWebUI | 90 days hot, 1 year cold | AI Champion |
| Permission change | OpenWebUI Admin | 3 years | IT Admin + 法遵 |
| Skill / Workflow deploy | GitHub | 永久 | AI Champion |
| Agent task start/end | Hermes log | 1 year | AI Champion |
| Reviewer 簽核 | 系統內 | 永久 | 法遵 |
| 階段驗收通過記錄 | 顧問 + 客戶 | 永久 | Sponsor + 顧問 |
| 機敏資料 redact 觸發 | DLP | 1 year | 資安 + 法遵 |

### Tool 8.8 AI Ethics & Data Policy Checklist (15 items)

- [ ] 員工 AI 使用規範已書面、已簽署
- [ ] 客戶資料 / PII 不外送 LLM (或經 redact)
- [ ] 模型供應商之資料保留政策已審
- [ ] Audit Log 涵蓋所有 LLM 呼叫
- [ ] 員工有權知道哪些工作被 AI 處理
- [ ] AI 決策有 HITL（重大事項）
- [ ] AI 產出內容明示「AI 產生」標記
- [ ] 智財權歸屬已釐清 (員工 / 公司 / AI 廠商)
- [ ] 偏見 / 歧視風險評估 (HR / 客戶決策場景)
- [ ] 兒少 / 醫療 / 法律 等高敏感場景另設規範
- [ ] LLM 幻覺處理 SOP (誰負責檢核)
- [ ] AI 系統 incident response 流程
- [ ] 第三方 AI 工具白名單 / 黑名單
- [ ] 員工教育每年至少 1 次
- [ ] 政府法規追蹤 (EU AI Act, 台灣 AI 基本法, 個資法) by 法遵

---

### Tool 8.9 Evidence Hierarchy — 證據等級制度（跨 Stage 通用）

> **核心邏輯**：方法論強調「可審核 / Auditable」，但「審核了什麼證據」本身有強弱之分。本工具給所有 Stage 提供**統一的證據等級**，讓報告任何結論都能標註其證據強度，讓客戶 / 監管 / 學術都能評估可信度。

#### 證據 5 級（L1 弱 → L5 強）

| Level | 名稱 | 範例 | 可信度 | 偽造難度 |
| --- | --- | --- | --- | --- |
| **L1** | **自評問卷** Self-Report Questionnaire | 10/25/50 題 AI 成熟度問卷、CEO 自評 | 🟡 低 | 容易（受訪者主觀 / 樂觀偏誤）|
| **L2** | **文件 / 訪談歸納** Documents & Interviews | SOP 截圖、訪談錄音轉摘要、Skill Library 文件、會議紀錄 | 🟡 中 | 中等（可被準備 / 修飾）|
| **L3** | **系統 Log / 自動產生** System Logs | n8n Workflow 執行記錄、OpenWebUI Audit Log、Hermes Agent 任務 log、Git commit history、Slack/Email 時間戳 | 🟢 高 | 困難（需主動偽造系統紀錄）|
| **L4** | **第三方稽核 / 獨立驗證** Third-Party Audit | 內稽 / 外部會計師 / ISO 認證機構 / 法遵稽核出具的稽核報告 | 🟢 很高 | 極困難（涉及第三方背書）|
| **L5** | **縱貫 KPI 追蹤** Longitudinal KPI | 6-24 個月持續追蹤的業務 KPI（不良率、營收、客訴回應時間、員工流動率）+ before/after 對比 + 控制變項 | 🟢 最高 | 不可能（時間 + 統計 + 多變項驗證）|

#### Stage × 證據等級對應表

| Stage | 預設證據等級 | 建議補強到 |
| --- | --- | --- |
| Stage 1 As-Is | L1 + L2（問卷 + 訪談）| L3（拉系統實際 log）|
| Stage 2 Reference Model | L2（顧問 mapping）| L4（第三方 RM 認證機構）|
| Stage 3 Best Practice | L2 + L3（案例文件 + 案例 KPI）| L5（同業縱貫驗證）|
| Stage 4 Gap | L2（計算結果）| L3（系統 log 佐證 As-Is）|
| Stage 5 Problem Definition | L2 + L3（彙整證據）| L5（多年趨勢佐證）|
| Stage 6 Phased Goals | L1（客戶簽署 Ideal）| —（目標本身為 commitment，無法用過去證據）|
| Stage 7 To-Be Design | L2（設計文件）| —（未來，無證據）|
| **Stage 8 Implementation** | **L3 + L5 必須**（系統 log + KPI 縱貫追蹤）| L4（第三方稽核確認 ROI）|

#### 報告每結論必標註的格式

每段結論用 `[E:L#]` 標籤：

```
公司客訴回應從 5 天降為 1 天 [E:L3 — n8n Audit Log + Gmail 時間戳交叉驗證]
不良率從 3.2% 降為 2.0%       [E:L5 — 24 個月品保 ERP 縱貫資料]
員工 AI 規範簽署率 92%        [E:L2 — HR 系統文件統計]
員工對 AI 接受度提升          [E:L1 — 內部問卷，⚠️ 主觀，建議補 L3 使用 log]
```

#### 對外辯論時的應用

| 質詢 | 用 Evidence Hierarchy 回答 |
| --- | --- |
| 「你怎麼證明數字是真的？」 | 報告每筆結論都有 E:L# 標籤；客戶可逐條追溯到 L3 系統 log 或 L5 縱貫追蹤 |
| 「你的問卷自評不算數」 | 同意 —— 自評是 L1，本報告已標註；L3+ 證據在附錄 |
| 「同業 ROI 平均值不夠精準」 | 同意 —— 同業 KPI 是 L2-L3，僅供參考；本公司簽 SOW 時用本公司 baseline 為準 |

#### 跟學術 / 監管的對齊

- **學術**：對應 evidence-based medicine 的 Levels of Evidence (Sackett 1996)、social science 的 triangulation
- **AI Governance**：對應 NIST AI RMF "Measure" 階段 + EU AI Act Article 17 (post-market monitoring) + ISO/IEC 42001 "Performance evaluation"
- **顧問實務**：使這份報告**從「顧問說了算」進化到「證據說了算」**

---

## Closing：如何使用本工具表 / How to Use This Toolkit

### 6 週標準顧問專案排程 / 6-Week Standard Engagement

| 週 | Stage | 主要工具 | 客戶角色 | 顧問交付 |
| --- | --- | --- | --- | --- |
| W1 | Stage 1 | 1.1 訪談 / 1.2 1.3 盤點 / 1.4 As-Is Map | 主管訪談、IT 提供盤點 | Discovery Report + As-Is Maps |
| W2 | Stage 2+3 | 2.1-2.4 Reference Model / 3.1-3.4 Best Practice | IT + 部門 walkthrough | 標準缺口檢核 + 卓越特徵定義 |
| W3 | Stage 4+5 | 4.1-4.3 / 5.1-5.4 | 主管 review + 80/20 工作坊 | Gap Matrix + Problem Statement |
| W4 | Stage 6 | 6.1-6.3 階段拆解 + 吸收力評估 | 主管 + AI Champion + HR | Phased Goals + Stage Gate Criteria |
| W5 | Stage 7 | 7.1-7.6 To-Be Design | AI Champion + IT | 分階段 To-Be Operating Model |
| W6 | Stage 8 + 結案 | 8.1-8.8 | Sponsor + 法遵 + HR | Roadmap + 變革計畫 + 價值追蹤 + Final Report |

### 每週交付節奏

- 週一：上週工具 review + 本週 plan
- 週三：客戶訪談 / 工作坊
- 週五：交付草稿 + 客戶 review

### 顧問 onboarding (給新顧問)

1. 先讀 README + AI_TRANSFORMATION_STORY_AND_STRUCTURE
2. 讀 [`CONSULTING_FRAMEWORKS_LIBRARY.md`](CONSULTING_FRAMEWORKS_LIBRARY.md) 了解八階段背後的學派根源
3. 跑過一遍本工具表所有 sample
4. shadow 1 場 Stage 1 訪談、1 場 Stage 5 工作坊
5. 自己跑 1 場 Stage 4 Impact × Effort + 1 場 Stage 6 階段拆解
6. 通過 Tiger AI 內部 mock review

---

授權與引用 / License & Citation

本工具表為 Apache License 2.0；任何顧問、企業內部、衍生顧問方法論皆可使用、修改、商業利用，唯需保留 [`NOTICE`](../NOTICE) 檔之署名。

This toolkit is Apache License 2.0; consultants, in-house teams, and derivative methodologies may use, modify, and commercialize, provided the [`NOTICE`](../NOTICE) attribution is preserved.
