價值流圖

🎯 什麼情境該想到我

當你「想改善交付速度，卻說不清楚工作到底卡在哪一段」的時候。

意圖：把「從想法到上線」的整條流程攤在同一張圖上，用數字找出真正拖慢交付與製造返工的環節。

先選試點價值流：

綠地 vs 棕地：綠地是全新專案，限制少、常被拿來示範公有／私有雲與部署自動化的可行性（例：National Instruments 2009 年的 Hosted LabVIEW，新團隊被允許在既有 IT 流程外運作，上市時間只花平常的一半）。棕地是已服務客戶多年甚至數十年的既有產品，常帶著沒有測試自動化、跑在不支援平台上的技術債。（L2671–2696）
不要因為是棕地就跳過：2014 年 DevOps Enterprise Summit 分享的轉型故事中，超過 60% 是棕地專案；2015 State of DevOps Report 也驗證「應用的年齡不是績效的顯著預測因子」，真正的預測因子是應用是否為可測試性與可部署性而架構（或能否被重新架構）。（L2698–2709）
拒絕 bimodal IT：Gartner 把系統分成 systems of record（Type 1，聚焦 “doing it right”）與 systems of engagement（Type 2，聚焦 “doing it fast”）。書中主張這條線該被打破——CSG 的 Scott Prugh 說他們採取的哲學是拒絕 bi-modal IT，因為每一位客戶都值得速度與品質。而且改變任何系統的能力都受限於「最難安全變更的那個系統」，那幾乎總是 system of record。（L2745–2787）

再畫圖：

開一場多日工作坊，把關鍵成員從日常工作的干擾中抽離；理想上請進有權限改動自己那段價值流的人。（L3019–3029）
第一輪只畫高階 process blocks：即使是複雜的價值流，一群人通常也能在幾小時內畫出 5 到 15 個 process blocks。（L3049–3051）
每個 process block 標三個數字（L1200–1220、L1275–1283）：
- lead time：時鐘從請求發出開始、到被滿足為止（客戶的體感）。
- process time：時鐘只在「開始動工」才起算，不含工作排隊等待的時間。
- %C/A：問下游消費者，有多少比例的時間他們收到的產出是 “usable as is”——不必修正、不必補漏、不必再澄清就能直接工作。
調查重點只放兩處（L3042–3047）：
- 工作必須等待數週甚至數月之處（取得類生產環境、變更審批流程、資安審查流程）。
- 產生或收到大量返工之處。
用圖上的指標決定要改什麼。Nordstrom 的案例就是盯上「部門經理送出的申請表因為缺員工編號而 %C/A 偏低」。（L3063–3066）
選定要改的指標後做下一層的觀察與量測，再畫一張理想化的未來價值流圖當作 target condition，訂一個達成期限——通常是 3 到 12 個月。（L3071–3074）
之後由領導層定義未來狀態，團隊腦力激盪假設與對策、做實驗驗證、解讀結果，反覆迭代。（L3076–3080）

原文：「Typically, even for complex value streams, groups can create a diagram with five to fifteen process blocks within a few hours.」（L3050–3051）

原文：「the %C/A can be obtained by asking downstream customers what percentage of the time they receive work that is ‘usable as is,’」（L1279–1280）

目標不是記錄每一步與所有細枝末節，而是「足以理解價值流中哪些區域危害了快速流動、短前置時間與可靠客戶成果」。畫太細會畫不完。（L3025–3027）
沒把「有權限改動」的人請進工作坊，圖畫得再漂亮也改不動。（L3027–3029）
改善注意力應該放在 lead time（客戶體感）而不是 process time；不過 process time 佔 lead time 的比例是重要的效率指標——縮短 lead time 幾乎總是要靠減少排隊等待。（L1217–1221）
棕地轉型會遇到真實阻礙：沒有自動化測試、緊耦合架構讓小團隊無法獨立開發測試部署。要有心理準備。（L2716–2720）