自動化不會修正流程，它只會放大流程原本的樣子。好的流程被放大是效率，壞的流程被放大是災難。
導入自動化工具的提案通常很容易通過，因為它的敘事很吸引人：這件事現在要花三小時，導入之後只要十分鐘。這個計算沒有錯，但它假設了一件事，就是目前這三小時所做的事情本身是對的。實際上很多耗時的流程之所以耗時，正是因為它們的設計有問題，而不是因為缺少工具。
我們看過的案例裡，最常見的失敗模式是把一個充滿例外的流程自動化。原本人工處理時，同事會在遇到例外時自己判斷並繞過去，整個流程看起來運作正常。自動化之後，例外無法被繞過，於是不是卡住就是產生錯誤，最後演變成一套自動化系統加上一群人在旁邊手動修正的局面，總工時反而增加。
第三步的價值往往最高卻最少被執行。我們協助整理過的流程裡，有相當比例在刪掉冗餘步驟之後，處理時間就已經減少一半，而這個改善不需要任何工具或預算。先做這一步的另一個好處是，你自動化的是一個比較簡單的流程，導入成本與日後的維護成本都會低很多。
第四項最常被忽略。團隊常常自動化那些最讓人煩躁的工作，而不是那些最花時間的工作，兩者未必相同。合理的排序方式是把每項工作的單次耗時乘上月發生次數，得出月總工時，然後從高的開始處理。這個簡單的計算經常會推翻原本的直覺。
自動化不是一次性支出，它會產生持續的維護成本，包含規則變動時的調整、串接的服務改版時的修正、以及例外發生時的處理。這些成本在導入時的評估裡幾乎從來不會出現，但它們真實存在，而且通常落在某一位同事身上而沒有被計入他的工作量。
另一個隱形成本是知識流失。當一個流程完全自動化之後，新加入的同事不再需要理解它為什麼這樣設計，於是幾年之後可能沒有人說得出這套規則的依據。等到需要修改時，團隊只能從程式碼反推，而反推出來的理解未必正確。避免的方式是在自動化的同時保留一份說明文件，記錄每一條規則的理由。
建議的順序是先整理、再半自動、最後才全自動。半自動的意思是讓工具處理重複的部分，但保留人類確認的環節。這個中間階段通常可以取得七成的效益，卻只需要三成的複雜度，而且它會讓你在實際運作中發現剩下的例外，再決定要不要繼續往全自動走。
很多團隊跳過中間階段直接追求全自動，理由是既然要做就做徹底。實務上這種做法的失敗率明顯較高，因為你在還不完全理解例外的情況下就把規則寫死了。而且半自動階段所累積的資料，正是你日後決定要不要全自動的依據。
最後想說的是，自動化本身沒有問題，問題在於把它當成流程改善的替代品。真正的順序永遠是先想清楚這件事為什麼要做、該怎麼做最合理，然後才問哪一部分可以交給工具。把這個順序顛倒過來的團隊，通常會在一兩年後發現自己維護著一套沒有人喜歡、又不敢關掉的系統。
下次有人提出自動化的提案時，可以先問四個問題：這個流程過去六個月改過幾次規則、過去三個月裡有多少比例的案例需要人工介入、如果把工具拿掉我們還知道該怎麼做嗎、以及未來誰負責維護這套設定。四題都答得出來且答案不令人擔心的提案，通常值得往下走；有兩題以上答不出來的，就代表現在該做的是先把流程搞清楚。
這四個問題的好處是它們不需要技術背景就能問，而且不會顯得在反對。多數提案者在被問到第二題時就會意識到自己還沒有實際統計過，於是自然會回頭去做那份統計，而那份統計本身往往就會改變提案的內容。用問題推動比用反對推動有效得多。
人力有限的團隊特別容易被自動化的敘事吸引，因為省時間對你們最有價值。但也正因為人力有限，維護的成本對你們的相對負擔最大。務實的原則是：只自動化那些規則穩定、發生頻率高、而且即使壞掉也不會立刻影響客戶的環節。符合這三個條件的通常是資料整理、通知提醒與報表產出，而不是與客戶直接互動的部分。
另外建議每半年檢視一次目前運作中的所有自動化，逐一確認它是否仍然被需要、是否仍然正確、以及是否有人知道怎麼修。這個檢視經常會發現一兩套已經沒有人在用卻仍然在跑的設定，而關掉它們本身就是一種效率改善。
最後補一句關於團隊感受的話：流程改善經常被視為枯燥的工作，而導入新工具則有明顯的成就感，這是為什麼順序容易被顛倒。如果你希望團隊願意先做整理，最有效的方式是讓整理的成果被看見，例如把刪掉的步驟數與省下的時間明確記錄並公布。當整理也能被量化，它就不再是沒有人想做的雜事。