如何改善業務流程
如何改善業務流程：先為現狀建立基準，找出原因而不是徵狀，一次只改一件事，並在結案之前驗證這次改動確實起了作用。
運作方式
為流程目前的樣子建立基準
和實際執行這項工作的人一起繪製現狀流程，把例外情況和變通做法都包括進去，並記錄一兩個指標：周期時間、返工率、每條分支上的業務量。沒有一條大家認可的基準，日後任何關於改善的說法都可能被質疑，而且一定會被質疑。
陳述問題時不要把原因寫進去
「發票遲了付款」是一個問題。「審批人慢」是一個穿着問題外衣的理論，任何由這裏出發的分析都會止步於這裏。用觀察結果和指標來寫這份陳述，然後讓證據去說明涉及的是誰或是甚麼。
圍堵，並把它記錄為圍堵
在問題正在造成實際損害的地方，先把它止住——但要把它登記為一項臨時措施，寫明負責人和結束日期。悄悄留在原地的圍堵會變成一個永久的額外步驟，同時還消解了去尋找真正原因的壓力。
找出一個有證據支持的原因
趁資料還在的時候收集，重建事件經過，提出多於一個假設並加以檢驗。停在第一個說得通的解釋上，是最常見的一種失敗，這也是示例裏的驗證決定會回到循環、而不是繼續往下走的原因。
只改一件事
挑出針對該原因的最小改動，界定甚麼算成功、到甚麼時候算，並且單獨推行。綑綁在一起的改動會令歸因變得不可能：指標動了，你不知道應保留哪一次改動；指標沒動，你不知道應回退哪一次。
在約定期限之後驗證，然後更新流程圖
等到跑過足夠多的周期、能看出訊號時再回來，與基準做比較。如果奏效了，就更新流程圖及其獲批版本，讓新的做法成為有文件紀錄的做法。如果沒有奏效，就重新展開分析，而不是在第一次改動之上再疊加第二次。
常見問題
我該如何着手改善一個業務流程？
和實際做這件事的人一起，把目前實際發生的情況畫出來，例外情況也包括在內。幾乎每一個停滯下來的改善項目，都是因為它由一個假想的流程出發，而不是由有文件紀錄的流程出發，而假想的版本永遠都是順利路徑。一旦現狀存在並且大家認可，問題往往會自己浮現——無人負責的步驟、返工循環，以及接收方沒有被通知到的交接，在紙面上都看得見。
徵狀和根本原因有甚麼分別？
徵狀是你觀察到的現象：發票遲付、工單被重開、交付被遺漏。根本原因是你可以移除、從而令徵狀無法再次發生的那樣東西。改善工作在處理徵狀時會失敗，因為由此產生的改動——再加一個審批人、再加一份核對表——只增加成本，卻觸及不到機制。檢驗是否為根本原因的準則是：移除它是否本可以避免這個問題，以及證據是支持這一點，還是僅僅不排斥它。
改善流程一定要用精益或六西格瑪嗎？
不必，儘管兩者都提供了有用的術語。真正起作用的機制不依賴任何方法論：把目前的流程記錄下來，量度一些東西，找出一個有證據支持的原因，一次只改一件事，然後驗證。正式的項目體系帶來嚴謹性和共同語言，規模大時確實有幫助；它們也帶來管理成本，對單一流程而言這筆成本可能超過其價值。先由這個次序開始，如果改善工作的體量值得，再引入框架。
怎樣令一次改善持續下去？
更新有文件紀錄的流程及其獲批版本，通知受影響的人，並在一個季度之後再檢查一次。只活在項目報告裏的改動，幾個月內就會退回原樣，因為有文件紀錄的流程仍然描述着舊做法，新同事也是照着它接受培訓的。改善不是在改動做完時就結束；它是在流程圖、培訓和實際做法三者說法一致時才結束。