第十一章：使用指標引導改善#

第十章討論了大量的改善方法，以及如何開始對流程進行變更以嘗試改善。作者將這些變更視為「尚未驗證的實驗」，因為在事前你無法真正知道是否正在改善。在進行這些實驗時，你需要某種方式來了解它們是否真的改善了你的流程。為此，你需要衡量你的工作方式。

本章涵蓋：

• 指標（Metrics）及其如何幫助你改善
• 看板團隊常用的指標與視覺化方法
• 如何為你的團隊找到好的指標

與看板的大多數事物一樣，你需要將指標視覺化，以便了解正在發生的事情。將指標做大、做得視覺化，放在牆上讓每個人都能看到並思考、提問。

11.1 常見指標（Common Metrics）#

本節介紹幾種常見的指標，這些都可以透過視覺化工作流程（如看板板）輕鬆擷取。這些指標能讓你了解流程的運作狀況、從構想到投入生產的速度等。

記得讓團隊參與選擇指標的過程，讓他們對什麼是好的指標有發言權。這裡的建議只是用來啟動討論的起點。同時，記得將這些「流程相關」的指標與展示業務影響力的指標混合使用。

11.1.1 週期時間與前置時間（Cycle Time and Lead Time）#

它們是什麼？ 衡量工作通過流程的速度，以及在哪裡變慢。

你能從這個指標學到什麼？ 透過衡量前置時間（Lead Time），你可以看到交付時間和可預測性的實際改善。你也能看到交期績效——某個項目是否如預期般準時。有了前置時間的資料，你還能分析工作項目的時間花在哪裡，並開始追蹤前置時間效率（Lead-Time Efficiency），了解工作項目是大部分時間在等待、被阻塞、返工，還是真正在被處理。

Cycle Time vs. Lead Time 的差異#

• 週期時間（Cycle Time）：指工作項目通過流程某一部分所花的時間，例如開發和測試階段
• 前置時間（Lead Time）：指完成整個流程所花的時間，從構想到功能上線

前置時間通常更值得追蹤，因為它展示了整個流程。週期時間只聚焦於部分流程，可能會遺漏其他能提供有價值資訊的環節。

案例： 作者 Marcus 參與的第一個 Scrum 專案中，開發團隊每三週交付可運作的軟體，開發的週期時間是三週。但「完成」六個 Sprint 後，還有三個月的測試階段在等待，又因為錯過了季度發布週期一週，需要再等三個月才能發布。更糟糕的是，需求早在一年半前就已經撰寫完畢。結果：單一功能的開發週期時間是三週，但前置時間卻是兩年四個月。這就是 Cycle Time 和 Lead Time 的差異——雖然縮短開發週期時間可能有用，但真正的大改善機會在別處。

擷取指標#

週期時間和前置時間的擷取非常簡單。在視覺化工作流程的看板上：

1. 當工作項目放上板時，在卡片上記下日期
2. 當工作項目到達最後一欄（如「完成」或「已上線」）時，再記下日期
3. 兩個日期之差就是你流程的週期時間（如果板上涵蓋從構想到上線的整個流程，就是前置時間）

要擷取特定階段的週期時間也同樣簡單——在工作項目進入和離開你感興趣的欄位時，分別蓋上日期戳記。

分析指標#

書中的範例顯示：前置時間 44 天，開發和測試的週期時間 8 天（僅佔總時間的約 20%）。有了這些數據，團隊可以開始提問：

• 這個數字（8 天）是上升還是下降了？
• 它應該是多少？
• 其餘的時間花在哪裡？
• 是否應該開始追蹤流程其他部分的週期時間？

個別的週期時間和前置時間本身並不那麼有趣，隨時間的趨勢才更有意義。第一個追蹤的項目可能特別快或特別慢，你需要更大的樣本才能看出是否正在改善。

有了追蹤資料後，你還可以進行以下分析：

• 預測：有了足夠大的樣本，你可以開始對進入板上的工作項目做出預測（類似迪士尼樂園的等待時間預估）
• 優先排序：例如一個中等工作項目通常需要 5-8 天完成，而有一個項目的截止日期在 6 天後，你可以根據這個資訊來調整優先順序
• 瓶頸分析：將前置時間拆解，看看實際時間花在哪裡——多少時間在等待或被阻塞？多少是返工？這能幫助你找到瓶頸並做出重大改善

視覺化指標#

團隊可以在看板旁的白板上繪製簡單的散佈圖來追蹤前置時間和週期時間的趨勢，也可以使用堆疊柱狀圖來顯示各階段的時間分佈。

雖然聚焦於縮短前置時間是好事，但只關注部分流程的週期時間可能反而對整體前置時間有害。這稱為「局部最佳化」（Optimizing Locally）。例如，你已經將開發時間優化到只需幾天，但需求能寫得夠小嗎？測試人員能處理每隔一天就收到新項目嗎？有時候放慢開發人員的速度反而能讓工作更順暢地流過整個流程。

11.1.2 產出量（Throughput）#

它是什麼？ 衡量流程產出已完成工作項目的速率。

你能從這個指標學到什麼？ 你可以了解你為改善流動所做的努力——減少 WIP、拆分故事、投資自動化（如持續交付）等——是否正在見效。你是否真的在改善交付頻率，從而縮短回饋循環？

產出量的定義是「系統達成其目標的速率」（來自限制理論社群的定義），簡單來說就是「每個時間單位完成多少東西」。

擷取指標#

產出量的擷取非常簡單：計算每週（或每月）完成的工作項目數量。在視覺化看板上，你可以在每週五計算「完成」欄中的工作項目數量，然後清空該欄。

視覺化指標#

產出量可以輕鬆地視覺化為散佈圖或堆疊柱狀圖，顯示每週完成多少項目。

分析指標#

• 分析產出量可以幫助你聚焦於完成工作。作者曾見過「一切運作良好」但一個月都沒交付任何東西的團隊。加上一個簡單的視覺化圖表後，他們開始重新聚焦於交付。
• 產出量也可以作為前置時間改善的平衡指標。如果你正在降低前置時間但產出量下降，可能是 WIP 限制得太低了。

想像你為了追求最佳前置時間而將 WIP 限制設為 1。該工作項目確實無法更快完成了，因為團隊所有人都只在處理這一個項目。但這對產出量來說可能很糟糕，因為除了這個項目外什麼都沒有在進行。WIP 很可能設得太低了。

11.1.3 問題與被阻塞的工作項目（Issues and Blocked Work Items）#

它們是什麼？ 衡量阻礙流動的事項。

你能從這個指標學到什麼？ 被阻塞的工作項目如何影響你的前置時間和前置時間效率。你解除阻塞/解決問題的速度有多快？是否在改善？

問題（Issues）或缺陷（Defects）告訴你沒有在正確的品質水準上產出；阻塞（Blockers）則會停止工作的順暢流動。你希望清除這些阻塞，並確保它們盡可能少。

擷取指標#

在視覺化工作流程中，這兩個指標很容易擷取：

• 缺陷數量 = 任一時間點板上粉紅色便利貼的數量，或每週的計數
• 阻塞數量 = 附有阻塞標記的便利貼數量

視覺化指標#

可以繪製為散佈圖或堆疊柱狀圖來顯示趨勢。

分析指標#

• 阻塞數量值得分析，因為它們正是拖慢你並降低前置時間效率的因素
• 對於確實發生的阻塞，確保快速解決它們
• 一些團隊會用進度指示器追蹤工作項目被阻塞的每一天
• 追蹤問題可以作為平衡指標，確保流程不會跑太快而忽略品質

有了具體資料，討論會更有力。例如：「我們追蹤了等待你們的項目數量，過去一個月增加了 30%，這是顯示趨勢的資料」比起「我覺得我們等了很多你們的東西」要有說服力得多。

11.1.4 交期績效（Due-Date Performance）#

它是什麼？ 衡量承諾和截止日期被遵守的程度。

你能從這個指標學到什麼？ 你可以看到截止日期是否可能在預測的前置時間內達成，並建立一個讓你值得信賴和可靠的追蹤記錄。這反過來幫助你與利害關係人建立信任。

如果一個項目附有截止日期，你要確保準時完成。該日期通常存在是因為有商業機會或罰款。有些人將截止日期視為與周邊部門和利害關係人的服務等級協議（SLA）的一部分。

擷取與視覺化#

• 從板上記錄工作項目的完成日期並與截止日期進行比較
• 圓餅圖可能是最合適的視覺化方式，能快速顯示有多少工作項目準時、提前或延遲完成

分析指標#

• 交期績效可用於與其他團隊和利害關係人的溝通，也能幫助你優先排序和激勵團隊
• 如果某個項目開始落後於預測的截止日期，可以提高它的優先順序：「我們不想破壞我們出色的準時記錄！」
• 長期且穩固的準時記錄往往能與周圍團隊和利害關係人建立信任
• 也能引導改善討論：「我們達到了 95% 的交期，除了與供應商 B 相關的項目。我們能怎麼處理？」

11.1.5 品質（Quality）#

它是什麼？ 衡量工作品質，以及是否在向利害關係人和客戶交付有價值的功能。

你能從這個指標學到什麼？ 品質很適合作為其他改善（如改善前置時間）的平衡指標。它也可以用來檢視品質改善努力（自動化測試、償還技術債等）是否正在見效。

品質的定義採用 Gerald Weinberg 的說法：「品質是對某人的價值」（Quality is value to some person）。一個無缺陷但沒人使用的產品並不是品質。

擷取指標#

容易擷取的品質指標包括：

• 每次建置或發布的缺陷/Bug 數量（最好以趨勢追蹤）
• 板上每個時間單位的缺陷工作項目數量（顯示多少資源用於修復 Bug）
• 可以為缺陷工作項目單獨追蹤前置時間、產出量等指標

但是——容易追蹤不代表追蹤它就有價值。正如 Alan Weiss 所說：「品質不是管理層眼中缺陷的缺少，而是消費者眼中價值的存在。」真正有價值的品質指標來自於詢問你想為其創造價值的人。方法包括：問卷調查、訪談、淨推薦值（NPS）、用戶行為分析等。

視覺化與分析#

• Google Analytics、Optimizely、Google Tag Manager 等工具可以監控流量並追蹤用戶互動方式
• 如果你能擷取為用戶創造的價值，就能進行 A/B 測試——發布同一功能的兩個版本，看哪個表現更好
• 書中範例：Marcus 的團隊對註冊表單的 CAPTCHA 進行 A/B 測試，結果「有 CAPTCHA」的版本在一週的實驗中以 5% 的優勢勝出——與所有人的直覺相反

11.1.6 價值需求與失敗需求（Value Demand and Failure Demand）#

它們是什麼？ 衡量有多少工作是由系統性失敗造成的——例如必須重做的工作。

你能從指標學到什麼？ 如何透過系統性地減少失敗需求來增加價值交付的產能。

失敗需求（Failure Demand） 是 John Seddon 教授提出的概念，指「因為沒有為客戶做某件事或沒有做對而產生的系統需求」。相反的是價值需求（Value Demand），即系統存在的真正原因——你希望系統做的事情。

失敗需求的例子包括：

• 因為規格不良而必須重做工作
• 因為彼此不理解而產出錯誤的東西
• Bug 和缺陷
• 因品質或說明不佳而使支援功能過載

擷取與視覺化#

• 分類有時很困難：實作搜尋功能的新面向——是價值需求（新功能）還是失敗需求（第一次就該包含的功能）？
• 建議不要過度複雜化，找一個簡單的分類方式，例如在工作項目結束時投票：這主要是失敗需求還是價值需求？
• 可以將趨勢視覺化為兩個圖表，或者直接在板上寫一個大百分比：「上週我們有 25% 的失敗需求——比前一週少了 10%」

分析指標#

這個指標對許多團隊（及其周圍的利害關係人）來說是一個大開眼界的時刻，讓大家看到團隊的時間真正花在哪裡。有了這些數字，你就可以開始研究失敗需求的根本原因並採取行動。

11.1.7 被丟棄的想法（Abandoned and Discarded Ideas）#

它們是什麼？ 衡量特定待辦清單（或收件匣欄）中有多少項目被丟棄而非進入開發流程，以及開發流程中有多少項目被丟棄。

你能從指標學到什麼？

• 被丟棄的想法太少代表你沒有太多選項，可能缺乏創新或冒險
• 開發欄中被丟棄的項目太多代表你正在啟動不該啟動的工作

擷取指標#

• 準備一個垃圾桶或籃子，將從板上取下的工作項目移入其中
• 記錄這些項目，並計算每個時間單位丟棄的想法數量

分析指標#

• 雖然直覺上覺得不斷移除板上的項目是壞事，但你確實需要丟棄一些項目。如果你從不丟棄任何東西，可能代表你缺乏創新
• 但如果丟棄太多項目，可能難以保持目標明確
• 如果你在開始工作後才丟棄大量項目，代表你啟動了很多不該啟動的工作。這可能意味著你應該在上游階段投入更多時間進行調查和探索

沒有團隊應該追蹤本節建議的所有指標。但對於你正在追蹤的指標，確保有明確的、視覺化的政策來幫助你記住在項目完成時要追蹤什麼。可以簡單到只是一個清單——「完成」欄的退出標準：「在項目移出板之前需要完成這些事項。」

11.2 兩個強大的視覺化工具（Two Powerful Visualizations）#

前面介紹了常見指標及其簡單的視覺化方式。這些簡單的散佈圖、圓餅圖和堆疊柱狀圖容易繪製和理解，但也有其局限——它們通常只顯示流程的一個面向，你需要交叉參考多個圖表才能全面了解狀況。

本節介紹兩個更進階但也更有資訊量的圖表。

11.2.1 統計過程控制（Statistical Process Control, SPC）#

統計過程控制（SPC）是一種品質控制方法。本書介紹的重點是 SPC 控制圖（Statistical Process Control Chart） 以及理解它所需的基礎理論——變異理論（Theory of Variation）。

變異理論#

John Seddon 透過四個簡單原則闡述了變異理論，說明你不能期望工作和工作者每次都達到你追蹤和衡量的平均結果。

原則 #1：你應該預期事情會變化——它們總是如此

每個系統都有自然變異。你不應該驚訝於不同的人、或同一個人在不同日子會得到不同的結果。使用 SPC 圖表，你可以看到變異是可預測的（在控制限內）還是不可預測的（在控制限外）。

原則 #2：理解變異會告訴你該期望什麼

假設一個團隊追蹤了過去幾週的前置時間：有上下控制限在位，告訴你團隊的結果有時會低至下限（例如 15 天），有時會高至上限（例如 38 天），但更常在平均值（例如 26.5 天）附近。

關於設定目標的陷阱： 如果你將目標設為平均值，團隊有時會超過（沮喪地回家）有時會低於（開心地回家）。你已經知道這會發生，因為流程中存在自然變異。如果將目標設向上控制限，團隊會經常錯過目標。團隊可能會開始作弊或操弄系統來達到目標。正如 W. Edwards Deming 所說：「如果你給管理者一個數字目標，他會達到它，即使他必須在過程中摧毀公司。」

在有變異的流程中，目標不會激勵人，但可能會打擊士氣。根據 Dan Pink 的研究，真正激勵人的不是目標，而是自主性（Autonomy）、精通（Mastery）和目的（Purpose）。

原則 #3：解決變異的原因，它們總是在系統中

「一個壞的系統會在任何時候擊敗一個好的人。」——W. Edwards Deming

績效變異的大部分原因都存在於系統本身，超出了在其中工作的個人的控制範圍。政策、角色、組織結構、程序、需求、資金和資訊等，都會造成自然變異。管理者應該努力透過解決系統中導致變異的因素來最小化變異。

原則 #4：理解變異告訴你何時發生了某事

在 SPC 圖表中，你可以看到單一值是特殊原因（位於控制限之外）還是普通原因（在控制限之內，屬於自然變異的結果）。你需要區分兩者，才不會把每個變異都當作特殊原因來處理。

案例： Joakim 通常開車上班需要 20-40 分鐘。某天他爆胎了，花了 1 小時 25 分鐘。這個單一事件應該改變他的開車方式嗎？應該買新車嗎？更可能的做法是將此視為一次性事件。如果他開始經常爆胎，才需要檢查駕駛習慣或輪胎品質。

SPC 控制圖#

SPC 控制圖（也稱為控制圖、執行圖或 Running Chart）顯示流程隨時間的趨勢。通常追蹤前置時間或週期時間，但也可用於追蹤其他指標。

需要什麼資料來繪製？

最基本的只需要每個工作項目的前置時間。但以下額外資料可以讓圖表更有用（都可從視覺化工作流程獲得）：

• 工作項目的識別碼或標題：讓你知道圖表上的某個點指的是哪個工作項目
• 開始和結束日期：用於計算前置（或週期）時間，也可用於縮小圖表範圍
• 工作項目類型：允許有趣的過濾和範圍設定（例如：「五月份缺陷的前置時間是多少？」）

如何繪製？

最簡單的版本是計算前置時間（完成日期減去開始日期）並建立散佈圖。加上趨勢線可以更容易分析資料。

要加入「統計」的部分，你需要計算以下公式：

• 平均前置時間：所有前置時間之和除以項目數量。例如 (31+23+19+24+22+21)/6 = 24 天
• 一個標準差（One Sigma）：用於消除異常值的影響。根據 68-95-99.7 法則，68% 的值落在平均值的一個標準差之內。在試算表中可用 STDEVP 公式計算，例如結果約為 3.4
• 上控制限：平均值 + 一個標準差 = 24 + 3.4 = 27.4 天
• 下控制限：平均值 - 一個標準差 = 24 - 3.4 = 20.6 天

如何解讀？

從 SPC 圖表中你可以獲得以下資訊：

• 超出上控制限的資料點是異常值，不需要過度關注
• 控制限之間的差距大小代表你的前置時間準確度——差距越大，項目大小差異越大，預測越困難
• 觀察趨勢是上升還是下降——為什麼？是特殊的工作項目，還是你改變了工作方式？如何強化好的趨勢或阻止壞的趨勢？

11.2.2 累積流程圖（Cumulative Flow Diagram, CFD）#

累積流程圖（CFD）充滿了對流程改善討論有用的資訊。經過初步介紹後容易閱讀，指標也容易從視覺化工作流程中擷取。CFD 在敏捷社群中越來越受歡迎，被稱為 Scrum 燃盡圖的繼承者。

需要什麼資料來繪製？#

你需要知道每天板上每個步驟的工作項目數量。可以透過計數輕鬆追蹤，但關鍵是你無法在取下便利貼後才回溯擷取這些資料——需要每天記錄。

範例資料表：

最後一欄（Deployed）是累積的——隨著越來越多項目被部署到生產環境。

記得每天收集資料——在每日站會後或其他固定時間點。使用試算表追蹤很簡單，圖表類型選擇「堆疊面積圖」（Stacked Area Diagram）。注意要按照板上的欄位順序排列區域，而非依字母順序。

如何解讀 CFD？#

CFD 之所以受歡迎，是因為它能在一個圖表中顯示大量資訊：

1. 前置時間：在任何給定日期，圖表中彩色區域的總水平長度
2. 週期時間：特定區域的水平長度（例如開發時間）
3. 待辦清單大小：頂層區域的高度（即 Inbox 中的項目數量）。同樣的測量可以對任何區域進行，以查看該欄位的 WIP
4. 總 WIP：在任何給定日期，所有區域（直到 Deployed/Done 步驟）的總高度

其他有趣的資訊：

• WIP 與前置時間的關係：在製品越多（總高度越高），前置時間就越長（水平長度越長）。這是一個很好的討論點，讓團隊看到較低的 WIP 如何使工作項目更快地流過流程
• Deployed 區域（底部）的增長顯示了隨時間交付的功能數量
• Inbox 區域（頂部）顯示了尚未被處理的項目數量。如果 Inbox 與其他區域一起移動，表示新東西不時被加入。如果專案的待辦清單已經確定，Inbox 區域會隨時間縮小

CFD 可以回答許多關鍵問題：開始結對程式設計後 WIP 是上升還是下降？同時對開發的週期時間有什麼影響？這是否也影響了前置時間？所有這些問題都可以用 CFD 來回答。

11.3 指標作為改善指南（Metrics as Improvement Guides）#

談了很多不同的指標、圖表和視覺化方法後，你可能覺得很難選擇適合你和團隊的。記住：指標本身通常並不重要，它是改善工作的指南。指標幫助你知道是否正在改善。有了指標，你可以採取更實驗性的方法來學習和改善。

指標就像是改善的視覺化。它們幫助你判斷你為了改善而做的變更是否真的帶來了改善，還是你應該嘗試其他方法。有了好的視覺化指標，你可以開始基於資料而非直覺或信念（軼事證據）進行討論。

讓它視覺化（Make It Visual）#

視覺化你的指標不會直接改善流程，但它確實會啟動基於資料而非直覺的討論。問題被提出，實驗被嘗試，效果可以被追蹤。

如果你還沒被說服，試試本章中最簡單的事——例如追蹤前置時間。讓指標大且視覺化，放在板上。在討論中引用它。很快人們就會開始談論、質疑和討論。在這些討論中，團隊會談到流程的改善。

你是否在產生業務影響？（Are You Making a Business Impact?)#

在尋找指標時，你應該從對你和你的業務重要的東西開始。你試圖達成什麼目標？你如何知道是否朝那個方向前進？

例如，如果你的業務目標是獲取更多網站用戶，將這個數字追蹤和視覺化在板的附近，你就可以隨時查看你的努力是否影響了這個數字，思考接下來要做的工作會對業務目標產生什麼影響。

你衡量什麼就得到什麼（You Get What You Measure）#

「衡量什麼就得到什麼。衡量錯誤的東西就會得到錯誤的行為。」——John H. Lingle

設定一個目標或指標，你很快就會看到人們改變行為來達成它。乍看之下這似乎是你想要的，但仔細想想也有危險。如果你開始衡量客服中心每通電話的時長，你會發現人們開始提前結束通話，而非專注於幫助客戶。

「你衡量什麼就得到什麼」也可以為你所用。一種技巧是在「完成」欄設定限制，有時稱為蛋糕限制（Cake Limit）。當限制達到時，產品負責人帶蛋糕來給團隊。這可能驅動什麼行為？團隊可能開始拆分出更小的故事，更快完成，更快填滿「完成」欄。而這正是好事：更小的故事、更快地移過板。

平衡你的指標（Balance Your Metrics）#

不要將所有精力集中在一個指標上。這可能讓你忽略流程中其他重要的面向。

例如只關注產出量，團隊可能會過度疲勞，或犧牲程式碼品質導致更多技術債。建議找到相互平衡的多個指標，例如同時關注前置時間和品質（如生產環境中的 Bug 數量），確保不會為了降低前置時間而走捷徑。

讓指標容易擷取（Make Them Easy to Capture）#

確保收集指標不需要太多努力。如果指標很難收集，你最終會面臨在收集流程資料和「做實際工作」之間做選擇的困境，風險是根本不會追蹤。你也希望指標能隨著流程的變化而變化——如果你在收集資料上投入過多，就會不願改變。

偏好真實資料而非估算資料（Prefer Real Data Over Estimated Data）#

真實資料是你可以從衡量工作方式、工作品質、產品使用方式等方面獲得的資料。與估算資料不同，真實資料無法被爭辯。你總是可以質疑估算的方式和數字的來源，但面對真實資料，你是在直接面對事實。

Spotify 的案例： Spotify 有一個消防隊負責處理後端系統的緊急事件。團隊需要追蹤時間花在主動性工作還是反應性工作上。與其使用工時表或估算，團隊想出了一個簡單的方法：每天結束後，在板上貼一張便利貼表示當天（主要）的時間花在哪裡。收集一週的資料後進行彙總就能看到趨勢。資料不完美，但足夠好。

用指標來改善，而非懲罰（Use Metrics to Improve, Not to Punish）#

指標是強大的激勵工具，可以幫助你看到和追蹤邁向更好結果的進度。但如同所有強大的工具，它們可能被濫用。

一個常見的誤用是為團隊設定目標，然後讓他們為結果負責——但這裡的意圖不是激勵而是懲罰。關鍵區別在於：誰設定了目標？ 是團隊自己設定並承諾的目標？還是由外部人員（如管理者或利害關係人）指派給團隊的指標？確保讓團隊參與指標的制定，建立承諾感和「這是我們的」而非「這是他們的」的感覺。

11.4 練習：量測起來！#

坐下來與團隊討論哪些指標可以幫助你了解流程的狀態：

• 你已經有任何指標了嗎？它們好嗎？它們幫助你了解正在發生什麼嗎？
• 建議的指標中有哪些可以嘗試和實驗？這會如何幫助你？
• 有沒有其他你想引入的指標？
• 你想鼓勵什麼樣的行為？指標會幫助達成嗎？

從簡單和容易開始。記住指標一旦開始衡量就很難停止。確保每個人都知道指標的目的，不要將指標強加給團隊。它們應該來自團隊。「現在不需要指標」也是討論的有效結果。

11.5 本章摘要#

• 為了知道你是否正在改善，你需要衡量流程行為並分析這些指標
• 指標就像流程健康狀況的視覺化
• 常見指標：

• 常用圖表：
  • SPC 控制圖——前置時間和週期時間的視覺化，包含統計分析
  • 累積流程圖（CFD）——基於每天流程中每個階段的項目數量，顯示大量流程資訊
• 尋找好指標的原則：
  • 你衡量什麼就得到什麼
  • 不要聚焦於單一指標——使用平衡的指標
  • 使用容易擷取的指標，或使其容易擷取
  • 偏好真實資料而非估算
  • 使用指標來改善——而非懲罰