Chapter 06 - Four Dimensions
本章目標
看完本章後，你應該可以回答：
- Four Dimensions 是什麼？
- 為什麼管理 digital product / service 不能只看 technology？
- Organizations and People、Information and Technology、Partners and Suppliers、Value Streams and Processes 各自看什麼？
- PM 如何用 Four Dimensions 檢查 release、incident、AI chatbot、AWS 架構？
- 考試遇到「哪個 dimension 被忽略」時怎麼判斷？
Key Terms
- Four Dimensions：管理 product / service 時必須同時考慮的四個面向。
- Organizations and People：角色、責任、技能、文化、溝通和組織結構。
- Information and Technology：資料、知識、系統、工具、架構、安全和技術能力。
- Partners and Suppliers：內外部供應商、vendor、cloud provider、platform team 和支援夥伴。
- Value Streams and Processes：需求如何流向 value，中間有哪些流程、交接、等待、回饋和斷點。
- Holistic Thinking：不要只看單一工具或流程，而是看整個 service system。
Related: Chapter 05 的
Think and Work Holistically是原則；本章的 Four Dimensions 是檢查清單。遇到題目說「只看工具 / 只看流程 / 只看 vendor」時，通常是在考 Four Dimensions。
一句話
Four Dimensions 是 ITIL 用來提醒團隊做整體思考的框架：一個服務要創造 value，不能只靠技術，還要同時看人與組織、資訊與技術、合作夥伴與供應商、價值流與流程。
核心概念
為什麼需要 Four Dimensions
很多 digital product / service 失敗，不是因為單一技術壞掉，而是因為只看其中一個面向。
常見情境：
- 工具買了，但沒有人會用
- API 做了，但客服流程沒接上
- AWS 架構很漂亮，但供應商 SLA 沒確認
- AI chatbot 上線了，但 knowledge base 沒人維護
- incident dashboard 有 metrics，但沒有人負責處理 alarm
Four Dimensions 幫你避免這種「局部成功，整體失敗」。
Organizations and People
這個 dimension 看的是組織結構、角色、能力、文化、責任、溝通方式和人員技能。
要問：
- 誰負責這個 service？
- 誰有權決策？
- 誰要 on-call？
- 團隊是否具備需要的技能？
- 客服、營運、工程、PM 是否知道自己的角色？
- culture 是否鼓勵透明回報問題？
production incident 例子：
問題不是只有 API timeout。
如果沒有人知道誰要對外溝通、誰要決定 rollback、客服怎麼回覆，
Organizations and People 這個 dimension 就有問題。Information and Technology
這個 dimension 看的是 service 所需的資訊、資料、知識、系統、工具、平台、架構、安全和技術能力。
要問：
- 需要哪些資料才能完成 outcome？
- 資料是否正確、即時、安全？
- 使用哪些系統和工具？
- 架構是否支援 availability、security、scalability？
- monitoring、logging、trace 是否足夠？
- AI 使用的 knowledge base 是否可信？
線上服務例子：
- transaction status 是否一致？
- external gateway response 是否有被正確記錄？
- CloudWatch logs 是否能追 request id？
- 客服後台看到的資訊是否和使用者畫面一致？
Partners and Suppliers
這個 dimension 看的是外部或內部合作方、vendor、cloud provider、external gateway、outsourcing partner、support partner。
要問：
- 哪些 supplier 影響 service value？
- 合約、SLA、support window 是否符合需求？
- supplier incident 時誰負責協調？
- vendor API change 是否會影響我們？
- 成本、風險、責任分工是否清楚？
線上服務場景：
- external gateway 是關鍵 supplier
- AWS 是 infrastructure provider
- SMS / email provider 可能影響通知
- external risk detection service 可能影響交易審核
如果 external gateway 掛掉，service provider 不能只說「那是 vendor 問題」。從 service value 來看，consumer 感受到的是操作失敗。
Value Streams and Processes
這個 dimension 看的是工作如何從 demand 流向 value，以及中間的流程、活動、交接、等待、瓶頸和回饋。
Related: Chapter 07 會把 product and service lifecycle 拆成 Discover、Design、Acquire、Build、Transition、Operate、Deliver、Support。這裡先記得：value stream 關心 demand 到 value 是否真的流得通。
要問：
- 從需求到上線的流程是什麼？
- incident 從發現到恢復的流程是什麼？
- support ticket 如何進入改善 backlog？
- 哪裡有等待、重工、手動搬資料？
- 流程是否真的支持 outcome？
production incident 例子：
CloudWatch alarm
↓
on-call engineer receives alert
↓
incident channel opened
↓
PM / CS / 客戶營運 notified
↓
service restored
↓
RCA
↓
improvement item in backlog如果 alarm 有發，但沒有人處理；或 RCA 做完沒有進 backlog，value stream 就斷了。
PM 視角
PM 可以把 Four Dimensions 當成需求和專案檢查表。
假設要做「服務狀態查詢」：
Organizations and People:
客服會用嗎？誰維護資料？誰負責權限？
Information and Technology:
交易狀態來源是哪個系統？資料是否即時？是否安全？
Partners and Suppliers:
external gateway 狀態如何同步？vendor API delay 怎麼處理？
Value Streams and Processes:
使用者、客服、客戶查詢狀態的流程是否一致？異常會進入改善流程嗎？PM 的價值在於把這四個面向一起看，而不是只寫「新增狀態查詢頁」。
Developer / DevOps 視角
Developer / DevOps 常會直覺先看 Information and Technology，這很正常，但不夠。
例子：release Java 新版核心 API。
Information and Technology:
API、DB migration、CI/CD、CloudWatch、rollback
Organizations and People:
誰 approve？誰 on-call？客服是否知道新版錯誤碼？
Partners and Suppliers:
external gateway sandbox / production behavior 是否一致？
vendor maintenance window 是否衝突？
Value Streams and Processes:
PR → test → deploy → monitor → support → feedback → improvement 是否接起來？如果只看 deploy success，會漏掉 service value 的其他條件。
AWS 對照
以「提高核心服務穩定性」為例：
Organizations and People
- 誰是 service owner？
- on-call rotation 是否清楚？
- PM、DevOps、backend、CS 的 incident role 是否清楚？
Information and Technology
- ALB、ECS / Lambda、RDS、SQS、CloudWatch、X-Ray 是否支援觀測與復原？
- IAM、KMS、VPC security group 是否符合風險需求？
- retry、timeout、idempotency 是否設計好？
Partners and Suppliers
- AWS support plan 是否符合 production 需求？
- external gateway SLA 是多少？
- vendor outage 時如何 fallback 或溝通？
Value Streams and Processes
- alarm 到 incident response 的流程是否清楚？
- deploy 到 rollback 的流程是否可重複？
- post-incident improvement 是否進 backlog？
AWS 不是答案本身。AWS 是 Information and Technology 以及 Partners and Suppliers 的一部分，必須和人、流程、value stream 一起設計。
實務對照
團隊導入 AI chatbot 處理服務問題，可以用 Four Dimensions 這樣檢查：
Organizations and People:
誰維護 knowledge base？
客服如何接手 chatbot 無法處理的問題？
誰負責檢查 AI 錯誤回答？
Information and Technology:
chatbot 可以查哪些交易資料？
資料權限如何控管？
回答來源是否可追蹤？
Partners and Suppliers:
使用哪家 LLM provider？
資料是否會送到外部？
供應商 outage 或模型變更怎麼辦？
Value Streams and Processes:
使用者問題 → chatbot 回答 → 轉人工 → 工單 → knowledge update → 改善
這條流是否真的跑得通？如果只看「模型回答很流暢」，就是只看 technology。真正的 service value 需要四個維度一起成立。
常見誤解
誤解 1：Four Dimensions 只是設計階段用
不是。incident、release、AI 導入、supplier 管理、continual improvement 都能用 Four Dimensions 檢查。
誤解 2：Technology 做好，service 就會好
Technology 很重要，但如果人、流程、partner 沒接上，service value 仍然會失敗。
誤解 3：Partners and Suppliers 只看外部 vendor
內部 shared platform team、central security team、data team 也可能像 supplier 一樣影響 service。
誤解 4：Value Streams and Processes 就是 SOP
SOP 只是流程文件。Value stream 更重視 demand 如何真的流向 value，中間是否有等待、重工、斷點和 feedback。
Interview Angle
可能被問：
- What are the four dimensions of product and service management?
- How would you use the four dimensions to evaluate a production incident?
- Why is technology alone insufficient for service value?
- How would you assess an AI chatbot using the four dimensions?
回答方向：
- 先列四個 dimension
- 不要只背名詞，要用一個 service 例子說明
- 強調 holistic thinking
- 用 incident / release / AWS / chatbot 分析每個 dimension
Exam Tips
Four Dimensions 題目常問「哪個 dimension 被忽略」。
速查表：
| 題目線索 | 最可能的 dimension |
|---|---|
| role、skill、culture、responsibility、team structure | Organizations and People |
| data、tools、systems、security、knowledge、architecture | Information and Technology |
| vendor、supplier、contract、SLA、outsourcing、cloud provider | Partners and Suppliers |
| workflow、handoff、process、bottleneck、value stream、feedback loop | Value Streams and Processes |
考試陷阱：
- 看到 cloud / AI 就只選 Information and Technology，但題目可能在問 supplier risk 或 people readiness。
- 看到流程文件就以為流程已完成，但 value stream 可能沒有 feedback。
- 看到 vendor outage 就推給 supplier，但 service provider 仍要管理 consumer experience。
Summary
Four Dimensions 是 ITIL 用來避免局部思考的框架。Organizations and People、Information and Technology、Partners and Suppliers、Value Streams and Processes 必須一起被考慮，digital product / service 才能穩定創造 value。對 Technical PM 來說，這章最實用的地方是：每當你要做 release、處理 incident、導入 AI、設計 AWS 架構或改善 服務流程，都可以用四個維度檢查有沒有漏掉關鍵風險。
References
Quiz
請見 Chapter 06 Quiz。