Architecture Journal
企業架構實務（六）：從願景推導 SMART Goal、Target State、目標架構與差距分析方法
這篇要回答的問題
企業願景通常很容易說出口：更以客戶為中心、更敏捷、更資料驅動、更能支援創新。問題是，這些句子很難直接幫助專案做選擇。
當團隊問「所以這次要改哪個系統？資料要怎麼流？哪些能力要先建？」時，如果只能再重複一次願景，代表願景還沒有被轉成可分析的目標狀態。
願景提供方向；可觀察、可驗收的 target state，才能讓現況、缺口與行動計畫有對照基準。
先抓住四個核心概念
本文只需要先分清楚四件事：
- Vision：想往哪裡去。
- Outcome／SMART goal：希望改善什麼，以及何時算達成。
- Target state：達成目標後，組織應該具備哪些能力、行為與限制。
- Target architecture：應用、資料、整合與技術如何支撐這個目標狀態。
後面的 initiative 是靠近目標的變更，measure 則是驗證結果的方式；這兩者會在後文出現，不必先塞進這裡。
可以把這四個概念看成一條推導鏈：
Vision
→ Outcome／SMART goal
→ Target state
→ Target architecture其中，Outcome／SMART goal 說明要改善什麼、何時算達成；target state 把目標拆成後續可以分析、設計與驗收的能力和行為；target architecture 再回答要如何支撐這些目標。如果直接從 vision 跳到 target architecture，中間缺少結果、能力與行為的推導，最後很容易變成「先選一套技術，再想辦法把願景套上去」。
願景具象化的四步方法
可以透過四個步驟，把願景轉成具體、可衡量、可溝通的業務目標，再進一步整理成 target state：
- 讀懂願景：釐清 Why、Who、What、Where 與 When；技術方案的 How 延後到架構設計，但限制條件要及早記錄。
- 找出利害關係人：確認誰受益、誰直接使用、誰參與、誰提供支持，以及誰負責決策。[3]
- 轉成使用者故事或業務情境：用角色的語言描述需求與價值，不先把產品或技術當成答案。[4]
- 定義 SMART 目標：讓目標具體、可衡量、可達成、相關且有時限。[5] [6]
這四步先處理「為什麼值得做」與「誰會受影響」，再把需求轉成可驗證的結果；架構與方案則回答在這些條件下可以怎麼做。
1. 讀懂願景：先問 5W1H
EA 在讀懂願景時，可以先問：
| 問題 | 要釐清的內容 |
|---|---|
| Why | 為什麼現在要做？不做會怎樣？希望創造什麼價值？ |
| Who | 哪些客戶、員工、夥伴或其他利害關係人會受到影響？ |
| What | 要改善的業務問題是什麼？成功的樣子是什麼？ |
| Where | 問題發生在哪些流程、部門、系統或業務範圍？ |
| When | 有沒有期限、里程碑與優先順序？ |
| How | 暫不急著選技術方案；在架構階段再比較如何實現。 |
「延後 How」不是排斥技術，而是避免技術偏好過早決定問題邊界。不過，法遵要求、既有契約、服務水準、預算、團隊能力與不能中斷營運等限制，仍然要在這個階段留下紀錄。[1]
2. 找出利害關係人
「受益角色」與「利害關係人」不完全相同。前者關心誰得到價值，後者還包含受影響、參與、支援與決策的人。可以先用四類整理：
- Primary users：直接使用服務完成工作的主要使用者。
- Key participants：參與需求、設計、建置、測試或營運的人員。
- Supporters：提供平台、工具、教育訓練、資安或法遵支援的角色。
- Decision makers：負責策略方向、資源核准與風險接受的角色。
接著再標註每個角色是「受益者、受影響者、參與者」或「決策者」，避免把所有利害關係人都誤稱為受益者。分析時也要記錄角色的需求、影響力與重要性，而不是只列出職稱。[3]
3. 轉成使用者故事或業務情境
使用者故事可以先寫成：
作為 [使用者]
我希望 [功能或能力]
以便 [價值或好處]例如：
作為門市店長，我希望在訂單狀態不明時看見交易目前的處理階段與可採取的處置，以便在不重複接單的情況下完成出餐或聯絡客服。
這個故事描述的是使用情境與價值，不預先指定要使用哪個產品。它不是完整需求規格，但能把後續能力、資料、流程與驗收討論拉回實際工作。
4. 用 SMART 定義結果
SMART 在本文中只是目標書寫的檢查表；這是本文的使用界線，不主張它能取代完整的目標設定理論。Doran 1981 年的原始版本使用 Specific、Measurable、Assignable、Realistic、Time-related；本文採用常見的 Specific、Measurable、Achievable、Relevant、Time-bound 版本。[5] 這個版本也出現在 CDC 的評估指引中。[6]
如果還需要向決策者說明為什麼值得投入，可以另外問三個問題：目前的問題是什麼？解決後的價值是什麼？如何證明結果？這只是工作提示，不列入本文的四步方法。
以好味餐飲集團的成長情境為例，可以先寫出：
在兩年內，將新通路第一版上線時間由約四個月縮短至四週，同時維持既有門市的日常接單與出餐，不要求 ERP、金流、電子發票與外送平台同步改造。
這個目標至少交代了結果、時間、基準、限制與範圍。正式使用前，仍應補上「上線時間」的起訖定義、適用的新通路類型，以及資料來源。
把業務目標轉成 target state
四步方法產生的是目標；EA 還要把目標轉成可以拿來做差距分析的 target state。重點不是列出更多系統，而是固定未來要具備的能力、行為、責任與驗收方式。
1. 從結果描述目標能力，而不是先列系統
先列出達成結果所需要的 business capability，例如客戶與交易資料查詢、通路與服務編排、資料品質與 ownership 管理，以及權限、稽核與異常處理。這裡沿用 EA 常見的 business capability 概念：描述組織需要具備的能力，不等於特定系統或產品。[2]
2. 定義目標行為、品質與邊界
每個重要能力至少要補上四件事：誰在什麼流程中使用、資料與更新責任歸誰、需要什麼品質與例外處理，以及哪些限制、依賴與假設會影響落地。沒有責任、品質條件與限制的能力清單，仍然只是另一種口號。
3. 再映射到應用、資料與技術
能力與目標行為清楚後，才確認既有應用能否繼續支援、資料是否需要指定 system of record 或建立 read model、介面是否需要穩定契約，以及平台、安全、可觀測性與災難復原能力是否足夠。此時的 target architecture 是支撐目標行為的配置，不是脫離交付順序的理想藍圖。
4. 加上可觀察的結果
重要的目標狀態至少要有可觀察或可驗收的證據；不能量化時，也要說明判斷方式。記錄時至少要交代測量對象、baseline、target 或 threshold、適用範圍、觀察期間、資料來源與負責人。這裡借用方案評估對 inputs、activities、outputs 與 outcomes 的區分，避免把交付物誤當成業務結果。[7]
| 目標行為 | 可觀察結果 | 驗證方式示例 |
|---|---|---|
| 客服取得一致的客戶資料 | 重要欄位有明確來源、更新責任與品質門檻 | 欄位 ownership 對照表、資料品質檢查、缺陷關閉時間 |
| 新通路可以較快接入 | 在指定範圍內，從需求核准到第一批正式交易可用不超過四週 | 交付時間紀錄、核心系統變更數、contract test |
| 重要查詢不壓垮 legacy system | 尖峰期間查詢成功率與 p95 延遲達到預先設定的門檻 | latency、error rate、容量與壓測結果 |
| 敏感資料被正確保護 | 未授權角色無法取得資料，且所有敏感查詢都能追溯 | 權限測試、稽核紀錄、定期事件抽查 |
如果目標只有「可接受」「更快」或「更穩」，卻沒有門檻與測量方式，後續的 gap 仍會變成「目前還不夠好」這種無法排序的描述。
一個假想案例：從願景到目標狀態
以下沿用 好味餐飲集團的情境故事。完整的事故、現況與角色資料留在情境故事，本文只保留能說明推導鏈的摘錄：
| 層次 | 好味案例中的摘錄 |
|---|---|
| Vision | 持續開設新門市、測試新品牌與新通路；局部異常時，未受影響的門市與通路仍能營運。 |
| Outcome／SMART goal | 新通路第一版由約四個月縮短至四週；結果不明的交易在 30 分鐘內查明。 |
| Target behavior | 新通路沿用既有會員、訂單與營運能力；客服、營運與財務看見一致且可追查的交易歷程。 |
| Constraint | 金流、ERP、電子發票與外送平台維持既有整合；轉型期間不能停止接單。 |
| Measure | 上線時間、交易查明時間、狀態不一致事件、查詢成功率與 p95 延遲。 |
下面的圖只示範交易狀態查詢與資料更新的一個切片，表達一種待驗證的配置，不是預先決定的唯一方案：
flowchart LR
Channels["POS／App／官網／外送平台"] --> Auth["權限與稽核"]
Auth --> Query["交易查詢編排／API layer"]
Query --> ReadModel[("交易查詢 read model")]
Query -->|少量必要即時欄位| Source["既有來源系統<br/>OneFood／金流／外送平台"]
Source -->|資料更新事件或批次同步| ReadModel
Query -.-> Audit["查詢與交易稽核紀錄"]真正需要決定的還包括哪些欄位允許延遲、read model 如何更新、來源資料如何修正、介面由誰維護，以及錯誤與缺資料時如何呈現。同一個願景可以導出不同架構方案；具象化的目的，是讓方案對照相同的結果、品質門檻與限制。
實務上，target state 至少要寫清楚目標行為、驗收證據、責任人，以及限制與依賴；應用、資料與服務配置，則在確認這些條件後再補上。
目標狀態常見的失敗方式
最常見的問題有三個：
- 只寫形容詞或方案：「敏捷」「雲原生」「導入資料湖」都不能代替結果、目標行為與驗收方式。
- 只畫未來架構：架構圖能表達元件關係，卻不一定說明資料責任、團隊 ownership、營運模式與轉型順序。
- 把所有 How 延後，或只定義終點：技術選型可以延後，但既有契約、法遵、團隊能力與不能中斷的營運，應先成為 target state 的限制或假設。過渡狀態則留給後續 roadmap 設計。
小結
願景具象化不是提前選定一套技術，而是把結果、能力、行為、責任、限制與證據放在同一個可對照的 target state 中。之後才能用它做 gap analysis，再決定哪些變更值得投入、如何分階段抵達。這也接上專案管理與企業架構的分工，把目標狀態轉成可排程、可驗收的交付承諾。
參考資料
本文的推導鏈、四步方法、target state 定義與案例整理，都是本文的工作模型。以下資料只支撐各段明確標示的概念，不代表任何單一來源定義了整份模型。
- [1] The Open Group，〈Business Scenarios〉，TOGAF documentation。
- [2] The Open Group，〈TOGAF Business Architecture Level 1〉。
- [3] Larry W. Smith，〈Stakeholder analysis: a pivotal practice of successful projects〉，Project Management Institute，2000。
- [4] Agile Alliance，〈User Stories〉，Agile Glossary。
- [5] George T. Doran，〈There’s a S.M.A.R.T. way to write management’s goals and objectives〉，《Management Review》，70(11)，35–36，1981。
- [6] U.S. CDC，〈Step 4 – Gather Credible Evidence〉，Program Evaluation Framework Action Guide。
- [7] U.S. CDC，〈Step 2 – Describe the Program〉，Program Evaluation Framework Action Guide。