如何改善業務流程
如何改善業務流程：先為現狀建立基準，找出原因而不是徵狀，一次只改一件事，並在結案之前驗證這次改動確實起了作用。
改善業務流程，意思是為目前實際發生的情況建立基準，找出問題的原因而不是它的徵狀，一次只改一件事，並驗證這次改動是否真的起了作用。
簡而言之
- 先為現狀建立基準——面對一個無人認可過的流程，你無法證明有所改善。
- 圍堵只是止血；它不是解決辦法，而且應當分開記錄。
- 一次只改一件事，否則你不會知道是哪一次改動起了作用。
- 在約定的期限之後驗證成效，用的是你一開始採用的那個指標。
- 拿走一個步驟是改善。加一個審批人通常不是。
大部分改善都敗在診斷這一步
流程改善有一種眾所周知的失敗模式，而它與懶惰無關。它是由徵狀出發去做診斷：發票遲了付款，於是加一個審批人；工單被重開，於是加一份核對表。每一種都是對某個觀察結果的合理反應，但都沒有落在事情為甚麼會發生上。半年之後，指標紋絲不動，流程裏卻多了一個步驟——這才是略過診斷所累積起來的真實代價。
替代做法不是為分析而分析。它是一個特定的次序：把目前實際發生的情況描述到足以拿來討論的細緻程度；在不假裝圍堵就是解決辦法的前提下圍堵眼前的損害；找出一個有證據支持的原因；只改一件事；然後在宣布完成之前檢查它是否奏效。最後這一步是最常被略去的，也是唯一能把改善與瞎忙區分開的一步。
下面的示例是一個根本原因分析流程，它是任何改善工作底下的診斷引擎。它包含兩條令它保持誠實的路徑：一條證據不足的分支，可以帶着有紀錄的局限性結案，而不是憑空編出一個原因；以及一個驗證循環，會把未經證實的假設送回去重新分析。
改善底下的那次診斷
一個由問題提出到糾正措施獲批的根本原因分析流程。留意團隊通常在哪裏走捷徑。
先界定問題，再提出理論
按觀察到的樣子描述，就一份書面的問題陳述達成共識，實施圍堵，然後才組建調查團隊。在有人已經形成理論之後才寫的問題陳述，往往會把那個理論寫進去，接下來的分析也就只是印證它。
證據，以及沒有證據時的那條分支
一個有三條出路的充分性決定：繼續、擴大收集範圍，或者帶着有紀錄的資料局限性結案。正是第三條路，阻止了一次調查在日誌早已輪替之後憑空編出一個原因。
檢驗假設，而不是隨手挑一個
提出原因假設，用證據加以檢驗，在原因未獲證實時回到循環裏。然後把根本原因與促成因素分開——這是一個獨立的步驟，因為團隊否則就會針對最容易修正的那個因素去寫措施。
獲批並有資源配套的措施
記錄調查結論，提出措施，一次可以把措施退回的審批，最後生成一條指定了負責人的 CAPA 紀錄。改善正是死在措施已經談妥、卻沒有人為所需時間埋單的那一點上——這也是審批被畫成一道閘門的原因。
運作方式
為流程目前的樣子建立基準
和實際執行這項工作的人一起繪製現狀流程，把例外情況和變通做法都包括進去，並記錄一兩個指標：周期時間、返工率、每條分支上的業務量。沒有一條大家認可的基準，日後任何關於改善的說法都可能被質疑，而且一定會被質疑。
陳述問題時不要把原因寫進去
「發票遲了付款」是一個問題。「審批人慢」是一個穿着問題外衣的理論，任何由這裏出發的分析都會止步於這裏。用觀察結果和指標來寫這份陳述，然後讓證據去說明涉及的是誰或是甚麼。
圍堵，並把它記錄為圍堵
在問題正在造成實際損害的地方，先把它止住——但要把它登記為一項臨時措施，寫明負責人和結束日期。悄悄留在原地的圍堵會變成一個永久的額外步驟，同時還消解了去尋找真正原因的壓力。
找出一個有證據支持的原因
趁資料還在的時候收集，重建事件經過，提出多於一個假設並加以檢驗。停在第一個說得通的解釋上，是最常見的一種失敗，這也是示例裏的驗證決定會回到循環、而不是繼續往下走的原因。
只改一件事
挑出針對該原因的最小改動，界定甚麼算成功、到甚麼時候算，並且單獨推行。綑綁在一起的改動會令歸因變得不可能：指標動了，你不知道應保留哪一次改動；指標沒動，你不知道應回退哪一次。
在約定期限之後驗證，然後更新流程圖
等到跑過足夠多的周期、能看出訊號時再回來，與基準做比較。如果奏效了，就更新流程圖及其獲批版本，讓新的做法成為有文件紀錄的做法。如果沒有奏效，就重新展開分析，而不是在第一次改動之上再疊加第二次。
應避免的錯誤
沒有基準就做改善
沒有一份獲得認可的現狀，就沒有辦法證明這次改動有幫助——也沒有辦法察覺它其實沒有幫助。
把加一個審批人當成解決辦法
這是最順手的反應，它可靠地令流程變慢，卻完全沒有觸及錯誤為甚麼會發生。大部分真正的改善都是拿走一個步驟。
把多項改動綑綁在一起
一次改五項，只會得到一個含糊的結果。把它們排出先後次序，即使這令人覺得慢。
從不驗證
沒有人檢查過的改善，只是一個附了項目計劃的假設。驗證這一步，正是改善與瞎忙之間的分界。
改善你們自己的流程
把根本原因分析示例作為你自己的圖表開啟，或者先繪製你們的現狀流程，再由那裏往下做。
相關指南
常見問題
我該如何着手改善一個業務流程？
和實際做這件事的人一起，把目前實際發生的情況畫出來，例外情況也包括在內。幾乎每一個停滯下來的改善項目，都是因為它由一個假想的流程出發，而不是由有文件紀錄的流程出發，而假想的版本永遠都是順利路徑。一旦現狀存在並且大家認可，問題往往會自己浮現——無人負責的步驟、返工循環，以及接收方沒有被通知到的交接，在紙面上都看得見。
徵狀和根本原因有甚麼分別？
徵狀是你觀察到的現象：發票遲付、工單被重開、交付被遺漏。根本原因是你可以移除、從而令徵狀無法再次發生的那樣東西。改善工作在處理徵狀時會失敗，因為由此產生的改動——再加一個審批人、再加一份核對表——只增加成本，卻觸及不到機制。檢驗是否為根本原因的準則是：移除它是否本可以避免這個問題，以及證據是支持這一點，還是僅僅不排斥它。
改善流程一定要用精益或六西格瑪嗎？
不必，儘管兩者都提供了有用的術語。真正起作用的機制不依賴任何方法論：把目前的流程記錄下來，量度一些東西，找出一個有證據支持的原因，一次只改一件事，然後驗證。正式的項目體系帶來嚴謹性和共同語言，規模大時確實有幫助；它們也帶來管理成本，對單一流程而言這筆成本可能超過其價值。先由這個次序開始，如果改善工作的體量值得，再引入框架。
怎樣令一次改善持續下去？
更新有文件紀錄的流程及其獲批版本，通知受影響的人，並在一個季度之後再檢查一次。只活在項目報告裏的改動，幾個月內就會退回原樣，因為有文件紀錄的流程仍然描述着舊做法，新同事也是照着它接受培訓的。改善不是在改動做完時就結束；它是在流程圖、培訓和實際做法三者說法一致時才結束。