Architecture Journal
企業架構實務（七）：功能缺口不一定是少一個功能
這篇要回答的問題
完成現況分析與願景具象化後，下一步通常會列出一張 gap list。最直覺的寫法是：
- 缺一個資料平台
- 缺一組 API
- 缺一個報表功能
- 缺一套工作流工具
但這些多半已經是解法，不一定是缺口本身。真正需要回答的是：
目前的能力和目標行為之間，差距究竟在哪裡？這個差距造成什麼影響，又需要補哪一種能力？
如果一開始就把 gap 寫成產品或技術，後續的優先順序會變成比較採購項目，企業真正要處理的問題反而會被藏起來。
Feature gap 與 capability gap
| 層次 | 描述 | 例子 |
|---|---|---|
| Feature gap | 缺少一項明確的功能或行為，通常接近產品 backlog。 | 客服畫面無法查詢案件歷程。 |
| Capability gap | 缺少持續完成某種結果的組織能力，可能同時涉及 People、Process、Technology 與 Information。 | 沒有可靠地管理跨系統客戶資料的能力。 |
兩者可以同時成立。Feature 可能是補足 capability 的手段，但分析時要先知道自己正在描述哪一層。Business capability 描述組織需要具備的能力，不等於某個系統或產品。[1]
缺口識別的四個步驟
- 定義目標條件：根據前一階段的 target state，列出目標能力與可觀察的 target behavior。
- 比較 current 與 target：用證據確認現況已具備什麼、尚未具備什麼，以及哪些地方不一致。
- 寫出 gap 與原因：說清楚差異造成的影響、責任與依賴，不把第一個解法直接當成答案。
- 提出改善選項：針對關鍵缺口保留多個可行方向，交給後續的影響力、優先順序與 roadmap 分析。
這四步的產出不是「系統要換掉」的清單，而是可以被證據支持、被責任人確認、也能連到後續決策的 gap register。TOGAF 也把 baseline、target architecture 與 gap report 放在同一條架構分析流程中。[2]
先定義目標條件，再寫 gap
目標能力仍然太抽象時，要先拆成可觀察的 target criteria。例如「開發與工具整合能力」可以拆成：
- Repo 與版本管理有一致的使用方式
- CI/CD 接入同一套驗證與部署流程
- 技術文件可以被搜尋、引用與維護
- 變更可以留下可回查的驗證紀錄
接著找 baseline evidence，逐項比較符合程度，再寫 gap statement：
現況已有多套開發與交付工具，但 Repo、CI/CD 與技術文件尚未形成一致的整合流程，因此變更驗證依賴人工轉述與個別經驗，影響交付速度與品質。
這種寫法把焦點放在缺少的能力，工具只是後續可能採用的方案。
Gap statement 要寫什麼
一個可用的 gap statement 至少要交代：
| 部分 | 要回答的問題 |
|---|---|
| Current state | 現在發生什麼事？依據哪個證據？ |
| Target behavior | 未來需要能做什麼？如何驗收？ |
| Gap | 中間少了哪個能力、約束或責任？ |
| Impact | 這個差異造成什麼業務、技術、交付或營運後果？ |
| Owner／dependency | 誰需要確認或處理？依賴哪些其他缺口？ |
例如，不要只寫「缺少客戶資料平台」，可以寫成：
目前三個系統各自保存客戶聯絡資料，更新後需要人工對帳；目標是讓客服在可接受延遲內取得可信任的資料，且有明確的來源與修改責任。因此目前缺少的是資料 ownership、欄位語意與跨系統同步能力，平台只是後續可能採用的方案。這個缺口影響客服作業、資料品質、個資稽核與後續通路接入。
這種寫法仍然可以導向平台方案，但不會預先把平台當成唯一答案。
缺口類型與原因
分類的用途是幫助團隊快速定位缺口，不需把它變成另一套評分標準。可以先用以下七種類型分類：
| 類型 | 判斷重點 |
|---|---|
| 業務功能 | 目標流程缺少必要的申請、查詢、核准、通知或追蹤行為。 |
| 流程與交付 | 從需求到上線、營運或事故改善，無法穩定完成結果。 |
| 資料與資訊 | 資料的語意、品質、來源、責任或使用限制不清楚。 |
| 整合 | 系統之間缺少穩定契約、錯誤處理、觀測性或相容性驗證。 |
| 品質屬性 | 效能、可用性、安全性、可維護性或復原能力不符合目標情境。 |
| 治理與責任 | 缺少 owner、決策紀錄、生命週期管理或例外處理機制。 |
| People 與能力 | 缺少技能、決策權、協作方式或維護關鍵能力的人員。 |
如果原因不明，可以從策略與價值、組織治理、流程、資料、應用、技術、資安、人才與衡量等角度快速檢查，再收斂成兩到三個主要原因。這九個角度只是工作提示，不是固定標準，也不用每次填滿。
若需要表達差距程度，可以用 0 至 3 級作為工作分級；但分級描述的是差距大小，不等於優先順序。優先順序仍要另外看影響、急迫性、依賴與執行可行性。
Gap register
Gap register 不必收進所有分析細節；只要能讓缺口被追蹤、確認，並接到後續決策即可：
| 欄位 | 要記錄的內容 |
|---|---|
| Gap | gap id、類型，以及阻礙的 capability 或 outcome |
| Current／Target／Evidence | 現況、目標行為，以及支持判斷的文件、指標、紀錄或訪談 |
| Impact | 業務、風險、交付或營運影響 |
| Owner／Dependency | 責任人，以及相依的能力、系統、專案或決策 |
| Decision | 改善選項、重要假設與處理狀態 |
若目前的 workaround 會影響判斷，可以補在 Current 或 Impact 中；不必為每個 gap 另外建立欄位。
從 gap 走到改善方案
完成缺口與原因分析後，才提出多個改善選項。每個選項至少說明適用範圍、預期效益、成本、整合與治理風險，以及尚未驗證的假設。方案比較要先建立候選集合，讓後續能比較價值、風險、可行性與投資順序。
在送進優先順序評估前，可以先問四個問題：
- 這是目標狀態必要的能力，還是某個人偏好的方案？
- 如果不處理，哪個具體結果會持續失敗？
- 有沒有量測、紀錄或跨角色訪談支持這個判斷？
- 有沒有低成本、可逆的方式先取得更多證據？
Gap 的處理不必一律從大型轉型開始。有些問題可以先透過 instrumentation、contract test、資料盤點或小範圍流程改善取得更多證據。
一個案例：沿用好味餐飲的情境故事
本節沿用〈情境故事：好味餐飲的數位轉型起點〉。這個案例先看不同通路的顧客、門市、客服與財務能否取得一致、可追查的交易狀態，以及能否在 30 分鐘內查明結果不明的交易，再決定是否需要建置平台。
根據故事中的目標、訪談與營運證據，可以先整理出：
| Gap | 類型 | 目前問題 | 目標差異 | 可能影響 |
|---|---|---|---|---|
| G-01 | 資訊／治理 | 訂單、付款與廚房各自有狀態說明，沒有共同資料 owner；每月約 320 筆交易需要人工核對 | 不同角色看到一致且可追查的交易歷程 | 對帳成本、客服處理時間與狀態誤判 |
| G-02 | 整合 | 重送請求無法穩定對回同一次結帳；付款、訂單與廚房單的關聯不完整 | 能辨識同一次交易，並在跨通路間維持一致狀態 | 重複訂單、付款成功但訂單狀態不明 |
| G-03 | 品質／技術 | 目前主要監控主機、JVM 與資料庫，看不到交易走到哪一步；共用資料庫也可能被批次與報表拖慢 | 局部異常不會拖垮所有通路，結果不明的交易可在 30 分鐘內查明 | 全面中斷、事故診斷延遲與人工清查 |
| G-04 | 流程／交付 | 正式版平均六週發布，跨模組回歸需 4 至 5 個工作天；異常案件常靠電話、群組或試算表協調 | 一般活動與規則變更可在 10 個工作天內完成驗證並上線 | 交付速度慢、變更風險高、責任不清 |
| G-05 | People／能力 | 14 名相關人員中只有 2 人能獨立追查跨模組問題，且沒有指定備援 | 關鍵交易能力有足夠的維護與事故處理能力 | 知識集中、處理等待與單點風險 |
這張表把既有情境中的業務目標與證據接成 gap register，也沒有預設產品或平台方案。若 G-01 與 G-04 尚未處理，先建平台可能只是把不一致的資料集中到另一個地方。
小結
Gap analysis 要先說清楚現況與目標之間少了什麼，以及這個差距造成什麼影響。當 gap 有證據、責任與候選處理方向後，才適合進入優先順序與 roadmap 分析。
參考資料
本文的 gap 分類、四步流程、0 至 3 分級、九個分析角度與 gap register 欄位，都是本文的工作模型。以下資料只支撐 business capability 與 baseline／target／gap analysis 等概念，不代表任何單一來源定義了整份模型。
- [1] The Open Group，〈TOGAF® Series Guide: Business Capabilities, Version 2〉。
- [2] The Open Group，〈ADM Input and Output Descriptions〉，TOGAF documentation。