🎯 什麼情境該想到我
當你知道「交付太慢」但講不出慢在哪一段，改善資源不知道該投哪裡時。
⚙️ 怎麼用
- 先找齊人：產品負責人、開發、QA、維運、資安、發布管理、以及有權改動自己那段流程的人。開一場多日工作坊，把他們從日常工作裡抽離。
- 第一輪只畫高階區塊：不要記錄每個細節。書中的判準是——即使是複雜的價值流，通常也能在幾小時內畫出 5 到 15 個 process block。
- 每個區塊標三個數字：
- 前置時間 lead time：從請求發出算到被滿足（客戶感受到的就是這個）
- 處理時間 process time：從實際開工才起算，不含排隊等待
- %C/A（完整且正確百分比）：問下游——你收到的東西有多少比例「拿到就能用」，不必補資料、不必澄清、不必更正
- 把調查火力集中在兩處：工作等待數週甚至數月的地方（拿類生產環境、變更審批、資安審查），以及產生或收到大量返工的地方。
- 畫出理想化的未來價值流圖當成 target condition，訂一個期限——書中給的是通常 3 到 12 個月。然後對每個假設做實驗、看結果、再迭代。
原文：「Typically, even for complex value streams, groups can create a diagram with five to fifteen process blocks within a few hours.」
算一次給你看（自寫範例）
以下數字為自寫範例；「流動效率」「累計 %C/A」兩個彙總公式是精實價值流圖的通用算法，DevOps手冊只要求每塊標 LT／PT／%C/A，沒有寫出彙總公式（推測）。
假設一張功能需求從提出到上線，第一輪只畫 4 個區塊：
| 區塊 | 前置時間 LT | 處理時間 PT | 其中在排隊 | %C/A（下游打的分數） |
|---|---|---|---|---|
| 需求分析 → 交給開發 | 10 天 | 1 天 | 9 天 | 70% |
| 開發 | 5 天 | 3 天 | 2 天 | 85% |
| 測試（等測試環境＋回歸） | 8 天 | 1 天 | 7 天 | 60% |
| 變更審批＋部署 | 4 天 | 0.5 天 | 3.5 天 | 90% |
- 總前置時間 = ΣLT = 10 + 5 + 8 + 4 = 27 天（客戶感受到的就是這個數字）。
- 總處理時間 = ΣPT = 1 + 3 + 1 + 0.5 = 5.5 天。
- 流動效率 = ΣPT ÷ ΣLT = 5.5 ÷ 27 ≈ 20.4%——一件工作有約 8 成時間在「等」，不是在「做」。
- 累計 %C/A（rolled %C/A） = 各區塊 %C/A 相乘 = 0.70 × 0.85 × 0.60 × 0.90 ≈ 0.321 → 約 32%——意思是只有約三分之一的工作能從頭到尾一次都不用返工就走完。
- 怎麼讀：
- 排隊最多的是「需求分析」（9 天）與「測試」（7 天）——正好是書中說要盯的「等數週」型區塊。
- %C/A 最低的是「測試」60%：下游（部署）收到的東西有 4 成要補資料或退回——是返工源頭。
- 這時候不該先去逼開發寫快一點：就算開發 PT 從 3 天壓到 1 天，ΣLT 只從 27 降到 25 天（−7%）；把測試環境改成隨選、排隊從 7 天降到 1 天，ΣLT 直接降到 21 天（−22%）。
🧪 我實際套用的紀錄
- 2026-08-02：（待填）
⚠️ 注意
- process time / lead time 的比值才是效率指標，但改善重點放在 lead time——因為那才是客戶感受到的。書中的 Nordstrom 例子裡，%C/A 低的根因只是「申請表沒填員工編號」，這種東西不畫圖永遠看不到。
- 什麼時候會失敗：
- 現場沒有能改流程的人：書中要求「理想上要把有權改動自己那段價值流的人找來」（“assembled those people with the authority to change their portion of the value stream”）。少了他們，圖畫得再準也只是一份「大家都知道但沒人能動」的報告——例如變更審批卡 3.5 天，但審批委員會沒人出席，就只能記錄、不能改。
- 畫完沒有後續實驗：書中的流程是「畫理想化未來圖 → 訂 3–12 個月期限 → 對假設做實驗、看結果、再迭代」，領導者要負責引導與支持這個循環。只畫現況圖、把它貼在牆上就結束，等於只做了診斷沒有治療；Damon Edwards 說畫圖常是「大開眼界」，但開眼界本身不會讓 lead time 變短（後半句為推測）。
- 細節太多讓工作坊卡死：書中明說目標「不是記錄每個步驟與瑣碎細節」，並在註腳強調要限制收集的細節程度，因為「每個人的時間都寶貴且稀少」。第一輪超過 15 個區塊、或開始爭論某步驟是 2 小時還是 3 小時，就是走偏了的訊號——先找出最大的等待與返工，細部量測留到選定要改的那一塊再做。
- %C/A 自己評自己（推測）：%C/A 必須由下游來打分（書中寫的是「as measured by the downstream consumers」），上游自評幾乎都會偏高，彙總出來的累計 %C/A 就失真。
🔗 相關工具
- 工具-找出並管理約束點 —— 接續動作，價值流圖告訴你哪裡慢，約束理論告訴你先修哪一個
- 工具-等待時間與閒置產能 —— 解釋為什麼「每個人都很忙」反而讓 lead time 爆炸
- 工具-三步工作法 —— 上位框架，畫價值流圖是第一步「流動」的起手式
- 工具-把業務目標接到IT風險 —— 把圖上的等待時間翻譯成老闆聽得懂的損失