如果不知道該從何處著手，答案只有一個：不要急於系統化。先思考什麼可以被消除。
先前我曾寫過一篇關於 系統開發失敗是結構性問題，而非缺乏管理知識 的文章。基於那個架構，本文將探討客戶應該採取的實際第一步。在猶豫不決時選擇「直接進行系統化」，是你所能做出的最昂貴的決定。 如果順序搞錯了，你只是在花錢自動化那些原本就低效的流程。
■ 誤解：「系統化 = 解決方案」
在與客戶諮詢時，最初的請求幾乎總是一樣的：「我們的營運效率低落，所以我們想導入系統。」然而，仔細檢視後會發現，大多數案例中都存在著在導入任何系統之前就能解決的浪費。
例如，考慮一家公司的報價流程。他們允許業務人員在新系統中建立報價單，但內部核准卻仍需列印紙本表單並實體流轉。核准後，員工必須手動將數位報價單上的金額重新輸入到紙本表單中。儘管已經「系統化」了，整體工作流程卻多出了一個步驟：「在系統中建置，再複製到紙本」。根本原因是，在建置系統之前，沒有人問過：「我們可以消除紙本核准流程嗎？」投入了數百萬資金，但 因為自動化了那些本應被削減的浪費，大部分的成本實際上等於打水漂。
■ 先刪減，再增加
商業改進有一個長久以來的原則，稱為 ECRS：Eliminate（能否移除？）、Combine（能否合併？）、Rearrange（能否重排順序？）、Simplify（能否簡化？）。只有在徹底考慮這四點之後，才應該考慮 Automate（系統化）。
許多專案經理跳過了這個順序，直接進入「自動化」。結果導致那些本應被消除的任務、可以合併的重複輸入、以及可以簡化的核准流程，都被直接內建到軟體中。最終產出的是 一個能更快、更準確地執行無用任務的系統。 諷刺的是，因為他們感覺自己已經「系統化」了，沒人注意到潛在的浪費。
這符合我先前提到的觀點：系統開發失敗是結構性的，並非由於無知。跳過 ECRS 序列正是這種缺陷結構的一部分。
■ 決策前的四個問題
在考慮系統化之前，請依序問自己這四個問題：
- 這個任務能否被 完全消除？ (Eliminate)
- 多個任務或部門的工作流程能否被 合併？ (Combine)
- 僅透過改變 順序或責任歸屬 能否進行改進？ (Rearrange)
- 方法本身能否被 簡化？ (Simplify)
只有在回答這些問題後仍然剩下的任務，才是系統化的候選對象。反之，如果在未考慮這四點的情況下就進入需求定義階段，失敗的种子就已經埋下了。
■ 回應對速度的渴望
你可能会爭辯說：「我們沒有時間深思熟慮；我們需要快速導入系統。」然而，ECRS 分析通常只需要幾天或幾週的時間。相比之下，如果倉促建置的系統後來需要重新定義需求，你會損失幾個月的時間。 試圖趕進度往往會導致走彎路。
另一個反對意見是：「我們的營運太複雜，無法套用外部框架。」但 ECRS 不需要深厚的營運知識。了解細節的人是第一線員工；ECRS 只是一系列問題，引導他們去問：「這能被移除嗎？」或「這能被合併嗎？」它可以在今天使用，無需專業專長。
■ 明天你可以做的事
不需要大規模的組織變革。挑選一個你目前想要「系統化」的任務，並回答上述四個問題。通常，第一個問題（Eliminate）就會揭示你未曾考慮過的選項。
「不知道從何處著手」的真正原因，通常不是關於是否要系統化，而是不知道在系統化 之前 該分析什麼。如果你遵循正確的順序，決策並不困難。
下次，我將處理高管們最普遍的痛點：「人才流失」。我們將討論離職率背後的組織結構。
如果有興趣，請透過 此連結 私訊我。
■ 相關過往文章
