有些事你不該自動化:先別急著上系統的判斷清單
賣鏟子的人叫你先別買鏟子。這篇不談怎麼選系統,只談哪些流程不該自動化:頻率低到養不起維護成本的、規則還在變的、出錯代價極高又難回復的,以及本質上是關係而不是流程的事。給你四把尺,加上一組可以當場問自己的問題,讓你在花任何一毛錢之前,先把不該做的那些從清單上劃掉。

「熊董,我們想把公司所有流程都自動化。」
這句話我每年都會聽到好幾遍。通常出現在第一次見面的第二十分鐘,老闆講完營收規模、講完人手不足、講完某個同業上了什麼系統,然後身體往前傾,講出這一句。他期待我點頭。我通常不點頭。
我是熊董,台灣川輝科技。我帶團隊做導入七年,經手 34 個案子、橫跨 12 個產業。講白了,我這行就是賣鏟子的,照理說老闆愈想挖,我愈該高興。但我在現場看太多次:一件本來只要有人花二十分鐘處理掉的事,被做成一套要三個月才建得起來、每個月都要有人顧的機制,半年後那個人比原來還累,而且沒人敢動它。
所以先講結論:該不該自動化,跟這件事「難不難做」無關,而是跟四件事有關——頻率、規則的穩定度、出錯的代價、以及這件事的本質到底是不是「流程」。頻率太低的不要做,因為你養不起維護成本;規則還在變的不要做,因為你會把一個錯的規則焊死在系統裡;出錯代價極高又難回復的不要做成全自動,只能做成「系統算、系統提醒、人按下確認」;而本質上是關係、不是流程的事,自動化只會讓你慢慢失去客戶。你在上任何系統之前,先拿這四把尺量一次,能省下的錢跟時間,比你選對廠商還多。
你想自動化的直覺,多半是對的
先站在你這邊講幾句。老闆想自動化,通常不是因為看了什麼趨勢報告,而是因為他真的痛。他看到業助每天下午三點半開始對帳,看到出貨單被抄了三次,看到同一份資料在 Excel、LINE 群、跟一本手寫簿之間來回搬。他知道這樣不對,這個直覺沒有錯,而且比很多顧問的分析都準。
錯的地方在於,「這件事讓我很煩」跟「這件事該用系統解決」中間,並不是等號。煩,可能是因為流程本身設計錯了;煩,可能是因為這件事根本不該由這個人做;煩,也可能只是因為它一個月只發生兩次,但每次都卡在最忙的那天。這三種煩,解法完全不同,只有第三種靠自動化才划算,而且還得看代價。
我遇到的案子裡多半是這樣:老闆把「痛」直接翻譯成「要上系統」,然後開始比較廠商、看功能表、談規格。這一段跳過的是最重要的那一步——先判斷這件事到底該不該進系統。跳過這一步,你買到的通常不是解法,是一個更貴、更難改的版本的同一個問題。
第一種:一年跑不到幾次的事
自動化真正的成本不在建置,在維護。這是老闆最常算錯的一筆帳。你付出去的是一次性的建置,但你真正要扛的是:每次規則變了要有人去改、每次人員異動要重新設權限、每次系統升級要重測、每次它壞掉要有人知道去哪裡看。這些成本不會出現在報價單上,但它們每個月都在發生。
所以判斷標準很簡單:這件事一年發生幾次?如果是每天發生、每天佔掉一個人兩小時,那自動化幾乎穩賺。如果是一年做三次、一次半天,那你花三個月做出來的東西,可能要跑十年才回本,而十年之後那套東西早就沒人記得怎麼用了。年度盤點的某些環節、少數幾家特殊客戶的專屬報表、一年開一次的股東會資料,這類東西你認真做一份好用的範本、寫清楚步驟、指定誰做,比任何自動化都划算。
這裡有個常見的反駁:「可是它每次都很痛苦啊。」痛苦跟頻率是兩回事。低頻高痛的事,解法是把它「準備好」而不是「自動化」——把資料放在固定的地方、把上次怎麼做的記下來、把要問誰列出來。下次做的時候痛苦會少一半,而你一毛錢都沒花。
第二種:規則還在變的事
系統的本質是把規則固定下來。這是它的優點,也正是它在這種情況下的致命傷。如果一件事的規則你自己這三個月已經改過兩次,那它現在不該進系統。
我看過最典型的例子是新的獎金制度、新的定價邏輯、新開的通路。這些東西剛上路的時候,老闆自己都還在試:這個級距對不對、那個折扣要不要留、退貨要怎麼算。這時候硬做進系統,會發生兩件事。第一,開發成本會翻倍,因為每改一次規則就是一次修改工單。第二,也更麻煩的是,一旦規則被寫進系統,它就變得難改,於是你會開始遷就系統——明明覺得這個級距不合理,但改一次要等兩週,算了就先這樣吧。你的商業判斷被系統綁架了,這是最貴的一種代價。
規則穩定的定義沒那麼玄:連續三到六個月沒有人提出要改,執行的人可以不看文件就講得出來,例外狀況你數得出來而且不超過三種。達到這個程度再進系統,開發會快、驗收會順、上線之後也不會天天有人來吵。在那之前,讓它待在 Excel 或一張白板上,那不是落後,那是刻意保留彈性。
第三種:錯了很貴、而且回不去的事
有些流程出錯,你隔天改一改就好;有些流程出錯,錢已經匯出去了、貨已經上車了、藥水已經打進去了。這兩種東西不能用同一套標準看。
判斷方式是問兩個問題:這件事做錯的最大損失是多少?發現之後,回復要花多久、要幾個人?如果答案是「損失可能吃掉一整個月的利潤」,而且「要三個人花兩天才追得回來」,那這件事就不該做成全自動。注意,我不是說它不該進系統。系統該做的是把資料算好、把異常標紅、把該看的人叫出來,但最後那個「送出」的動作,留給人。付款、對外報價、庫存的實體異動、跟客戶身體或安全有關的動作,我一律建議這樣做。
老闆聽到這裡常常會說:那不就等於沒自動化嗎?不是。差別在於,原本那個人要花四十分鐘核對才敢按,現在他花三分鐘看系統標出來的三個異常點就敢按。你自動化掉的是「查」,不是「決定」。這一刀切在哪裡,是我在現場最常花時間跟客戶談的一件事,也是最能決定這套系統上線之後有沒有人信任它的關鍵。做過幾年之後我的體會是,這種地方寧可保守,因為系統的信任只要崩一次,之後大家就會回去開 Excel 私下再算一遍,那你等於白做。
第四種:那不是流程,那是關係
這是四種裡面最容易被忽略、也最傷的一種。有些事情長得很像流程——有步驟、有時間點、可以寫成 SOP,但它的價值根本不在步驟上,在「是誰做的」跟「對方感覺被怎麼對待」。
最常見的是催款。做成自動發信,成本趨近於零,聽起來完美。但那個拖了三十天的老客戶,收到一封系統罐頭信的反應,跟接到業務電話說「王哥,那筆我幫你看了一下,是不是對帳單有問題」的反應,是天差地遠的。同樣的還有:客訴的第一次回應、報價的最後一次讓步、老客戶的關懷、資深員工離職前的那次談話。這些事你自動化了,短期看起來效率變高,長期你會發現熟客一個一個不見了,而且你不會知道是為什麼,因為系統的報表上不會有「他覺得你變得很冷淡」這一欄。
分辨方法其實不難:如果對方知道這件事是機器做的,他會不會不高興?會,那就不要自動化。你可以自動化「提醒業務今天該打這通電話」,可以自動化「把這個客戶的歷史紀錄整理好放在他面前」,但那通電話本身要人打。這是自動化跟人力最好的分工——讓系統負責記得、負責整理、負責不漏掉,讓人負責那三分鐘的溫度。
判斷完之後,你該做什麼
把上面四把尺量過一輪,你手上那張「想自動化的清單」通常會少掉一半。剩下的那一半才值得往下談。這時候要處理的問題就變成順序——哪一個先做,我在該先自動化哪個流程那篇裡講得比較細,簡單說就是找頻率高、規則穩、出錯代價可控、而且能讓最多人有感的那一個,先做完、先讓它上線、先讓大家相信這件事會成功。
被劃掉的那些也不是丟著不管。下面這張表是我在現場常用的處理方式:
| 情況 | 不要做的事 | 該做的事 |
|---|---|---|
| 一年跑不到幾次 | 開發專屬功能 | 做一份好用的範本,寫下步驟跟負責人 |
| 規則還在變 | 寫進系統的邏輯層 | 先用 Excel 或白板跑三到六個月,把例外收斂 |
| 錯了很貴、難回復 | 全自動執行 | 系統算、系統標異常,人按最後那一下 |
| 本質是關係 | 罐頭訊息、自動群發 | 自動化「提醒與整理」,把接觸留給人 |
還有一句話要講在前面:忍住不做,比多做一項難得多。老闆看到廠商的功能表,很難不想全都要,畢竟看起來只多一點錢。但每多一個模組,就多一份要維護的東西、多一份要教會員工的負擔、多一個上線日期往後推的理由。這件事我在少即是多裡面講過,導入這行做久了會發現,做得少而且做完的公司,幾乎都贏過想做很多但只做了七成的公司。
明天可以做的一件事
明天早上,拿一張紙,把你這半年想過「這個應該可以自動化」的事,全部寫下來,不用整理,想到什麼寫什麼。寫完之後,在每一項後面標四個數字或記號:一年發生幾次、規則最近三個月改過幾次、做錯的話最壞損失大概多少、以及對方會不會介意這是機器做的。
標完你就有答案了。頻率個位數的劃掉,規則改過兩次以上的先放著,最壞損失你賠不起的改成「人工確認」而不是全自動,對方會介意的整欄劃掉。剩下的排個順序,從第一名開始談,其他的先不要碰。這件事你自己一個下午就能做完,不用找顧問,也不用花任何一毛錢,但它可能是整個導入過程裡投報率最高的一步。
如果你現在手上正好卡在現金流、人手都調不出來的狀態,那我建議連這張清單都先放一邊,先把公司撐住,把順序搞對比什麼都重要——自動化是拿來放大一件本來就成立的生意,不是拿來救一件本來就不成立的。真的想找人一起看你那張清單怎麼排,川輝有一個免費 30 分鐘的診斷,帶著你寫好的那張紙來就行。
Does this sound like your company?
Spend 30 minutes telling Johnny Yang how you do it now, and you get told where hours are leaking, where the risk is buried, and whether this is worth paying to fix. No pitch, no course to sell — if it is not a fit, that is fine too.
Pick a slot online · with Johnny Yang himself · 34 implementations behind it
