如何標準化業務流程
如何在多個團隊或多個地點之間標準化一條業務流程：先梳理各個變體，把真實差異與習慣分開，議定一條帶有明確例外的流程，並管住版本。
運作方式
按實際運作的樣子，把每個變體畫出來
每個地點或每個團隊一張圖，畫的依據是實際做這件事的人，而不是當地的程序文件。根據文書資料整理出來的變體看上去全都一模一樣，因為大家抄的是同一份範本——分別在實際做法裡。
把各個變體對齊到一條共同的主線上
找出每個版本都有的步驟，再把每個變體逐一對上去。正是這一次比對，把「我們做法都不一樣」這種籠統感覺變成一份具體的差異清單，而後者是一場短得多、也不容易吵起來的對話。
把每一處差異歸入必需、受限或習慣
必需，是指監管機構、合約或法律令它成為必要。受限，是指某個本地系統或資源目前迫使它如此。習慣，是指沒有人記得為甚麼。請擁有這處差異的地點為每一條給出理由——單是這一次歸類，通常就能在無需任何人做決定的情況下化解掉一半的差異。
圍繞必需的差異來設計標準
建立一條流程，在差異確實成立的地方設置明確的變體分支。一條無視某個地區法律要求的標準，在那個地區必然是失效的，並且會令整件事在其他所有地方都失去公信力。
把例外通道寫下來
每條流程都有一條緊急通道。把它畫出來，給它加上判定準則，指明誰有權授權，並要求把理由記錄下來——就像示例中的加急分支那樣。沒有文件紀錄的例外通道會不斷擴張，直至它就是流程本身。
發布一個獲批版本，並覆核偏離情況
只保留一張已獲審批的圖表，把各個變體具名標在上面，幾個月後再回頭覆核期間必然出現的偏離。標準化不是一個會完結的項目；它是一個需要持續維護的版本，而失敗的第一個徵兆，就是某個地點手上有了自己更新過的副本。
常見問題
如何在多個地點之間標準化一條流程？
把每個地點實際的跑法畫出來，把各個變體對着一條共同的主線做比對，然後把每一處差異歸入必需、受限或習慣。圍繞必需的差異來設計標準，把出於習慣的差異去掉。次序很重要：一條看得出來照顧了自身真實約束的標準，團隊會接受；而一條看上去是在別處設計好、再壓下來的標準，無論設計得多好，團隊都會抗拒。
標準化與集中化有甚麼分別？
標準化是指所有人都遵循同一條流程；集中化是指由一個團隊代所有人執行它。這是兩個各自獨立的選擇，卻經常被混為一談，把本來不必這麼難的對話變得更難。你們完全可以把一條仍由各地點自行執行的流程標準化，而這往往是更好的第一步——它拿到了一致性帶來的大部分好處，卻不必承受動盪和本地經驗的流失。
某個地點確實必須做得不一樣，應該怎麼辦？
把這處差異作為一條具名的變體分支畫進標準裡，而不是給它一次豁免。分支會一直可見，會和流程的其餘部分一起被覆核，並且在底層約束消失之後可以被移除。豁免是看不見的、不會被覆核的，而且是永久的——它同時還在邀請其他每一個地點也來要一個。
怎樣防止一條已經標準化的流程又漂回去？
一個人們找得到的已獲審批版本、一位具名負責人，以及一次定期的偏離檢查。漂移通常不是反抗；它是針對一個真實問題的本地修補，只是從來沒有回流到標準裡。給各個地點一條提出變更的通路，並且真的對它作出回應，否則他們會在本地直接改，而標準就變成一份關於過去的文件。