失敗的樣子
先描述一下典型的失敗長什麼樣，因為它不太像失敗：
專案照計畫完成了，系統建好了，教育訓練辦過了，大家上課時也覺得不錯。然後三個月後你發現，除了當初最積極的那一兩個人，其他人都回去用原本的方法了。
沒有人反對，也沒有人說它不好用。它就只是慢慢消失了。
以下是我們看過導致這個結果的六個原因。
一、先選工具，再找用途
最常見的一個。看到某個工具很紅、或是同業在用，就決定要導入，然後回頭找可以用它的地方。
這樣做出來的東西通常解決的是不太痛的問題，所以沒有人有動力改變習慣。
預防方法：從盤點流程開始，不是從研究工具開始。先問「團隊每週花最多時間在什麼重複性工作上」，痛點清楚了，工具只是解法之一。詳細做法在導入 AI 的第一步。
二、一次規劃太大
想一口氣把整個公司的流程都自動化。做了完整的藍圖、分了五個階段、預計半年完成。
結果第四個月還沒有任何東西上線，團隊已經失去耐心，決策層開始懷疑這筆投資。
預防方法：先做一個明確的痛點，兩到四週內要有東西能用。做出成果、有人真的在用之後，再談擴大。
小而完成，勝過大而未竟。
三、流程本身是亂的
這一項是最根本的。
自動化的前提是流程本身清楚。如果目前的工作方式是靠口頭交辦、資料散在各人電腦裡、每個人的做法都不一樣，那沒有東西可以自動化。
強行導入的結果是把混亂自動化，然後混亂變得更快。
預防方法：先把流程整理出來。這一步是顧問工作，不是技術工作，而且省不掉。
通常會從建立知識庫開始，因為資料結構化是所有後續工作的地基。
四、沒有人負責維護
系統建好之後，資料沒有人更新、規則沒有人調整、有問題沒有人修。
三個月後資料過期，大家發現「問它得到的答案是舊的」，然後就不問了。
預防方法：導入時就要指定一個具體的人，不是「大家一起維護」。並且訂一個固定的檢查時間，例如每月最後一個週五。
這個人不需要是技術背景，需要的是他在意這件事。
五、想用自動化取代判斷
把需要承擔責任的決策交給系統。
出事的時候沒有人能解釋為什麼會這樣，而且通常是在客戶面前發現的。這種事發生一次，整個團隊對自動化的信任就沒了。
預防方法：自動化處理執行，判斷留給人。規則明確且錯了代價高的工作，流程可以自動化，但最後一關要人按確認。
判斷哪些該交、哪些不該交的框架，在這篇。
六、沒有讓實際使用的人參與
這一項很微妙但很致命。
由主管或顧問決定要導入什麼、怎麼設計，然後交給第一線的人使用。
問題是設計的人不知道實際操作中的細節。那些「其實我們遇到 X 狀況時會另外處理」的例外，沒有被考慮進去。第一線的人發現系統處理不了他們真實的工作，就繞過它。
預防方法：從盤點階段就讓實際做那件事的人參與。不是問他們「你覺得好不好」，是問「你現在實際怎麼做，包括那些不在 SOP 上的部分」。
一個判斷成功的標準
導入完成兩個月後，問一個問題：
如果現在把這個系統關掉，會有人抗議嗎？
會 → 成功了。 不會 → 不管當初做得多完整，它已經失敗了。
這個標準很殘酷，但它直接反映了系統有沒有真的被納入工作流程。
什麼時候不該導入
誠實說，不是每家公司現在都需要。
如果盤點之後發現沒有明顯的重複性工作、每件事的流程都不一樣、或團隊規模小到溝通成本本來就很低，那現在導入的效益有限。
規模不是關鍵，流程有沒有重複性才是。 五個人的公司如果每週花八小時做同樣的整理，那就值得。一百人的公司如果每件事都不同，能自動化的空間反而有限。
重點整理
- 從流程痛點出發，不要從工具出發
- 小而完成，兩到四週要有東西能用
- 流程本身亂的話，先整理流程
- 導入時就指定維護負責人
- 自動化處理執行，判斷留給人
- 讓實際使用的人從一開始就參與
- 成功標準：關掉會不會有人抗議
想把自己的流程盤一遍，我們用 30 分鐘陪你做，包括「你現在還不需要導入」這種結論。