系統上線三個月後，現場還是用原本的方法。這個情況在中小企業很常見，而且多半不是員工的問題。
允雷實際導入系統時看到的模式是這樣：老闆花了錢、廠商交付了功能、教育訓練也辦了，但幾個月後現場仍在用紙本、LINE 群組或個人的 Excel。老闆的結論通常是員工抗拒改變。
這個診斷經常是錯的。
為保護合作方，本文不公開公司名稱、實際交易量、內部商業規則與技術實作。公開內容只保留可驗證的設計原則、責任邊界與適用限制。
導入失敗多半不是現場不配合系統，而是系統從一開始就要求現場配合它。
公開原則、保留方法：本文說明設計取捨，不公開足以重建內部系統的細節。
這篇老闆 30 秒摘要：
- 常見誤診：把「員工不用系統」歸因為抗拒改變或訓練不足，於是加強訓練，但問題不會消失。
- 真正的斷點：系統要求現場一次全面切換，而現場的例外狀況沒有處理路徑。
- 可行的替代做法：讓新舊方式並行一段時間，並且事後分得出來源。
- 評估廠商時可以先問四個問題：見文末，這些問題比功能清單更能預測結果。
1. 誤診：把「不用系統」當成人的問題
當老闆說員工抗拒改變，通常隱含一個假設：系統是對的，人需要調整。
依這個假設會做的事是加強教育訓練、訂使用率 KPI、要求主管盯。這些動作短期會讓數字好看，但撤掉盯的力道之後，現場通常會回到原本的方法。
原因不難理解。現場人員選擇工具的標準是「這件事今天能不能做完」，不是「這個工具是不是比較先進」。 當系統在某些情況下讓事情做不完，回到原本方法是理性的選擇，不是情緒反應。
所以要問的不是「怎麼讓他們接受」，而是**「哪些情況下系統會讓事情做不完」**。
2. 三個讓系統做不完事的常見設計
以下三種情況允雷在不同案子裡都遇過。它們的共同點是：技術上都沒有錯，但都要求現場先改變才能使用系統。
要求一次全面切換
系統上線日之後，舊方法停用。這對開發方最單純，但對現場代表所有例外都要在同一天找到新解法。
實務上例外一定存在。臨時追加、口頭改單、熟客的特殊規則、系統還沒建的品項 — 這些在切換日不會消失。當它們沒有路徑，現場只能繞過系統。
例外情況沒有出口
系統只處理標準流程，非標準的一律擋掉。這在資料品質上是好設計，但如果沒有配套的例外處理路徑，現場遇到擋住就會停下來，或者改用系統外的方法完成，然後那筆資料就永遠不在系統裡。
擋下來不等於解決，只是把問題推到系統看不見的地方。
要求現場配合系統的資料結構
系統需要品項編號，但現場說的是俗稱。系統需要精確數量，但現場先估後補。系統要求下單前確認庫存，但現場的判斷是看貨況。
當系統的資料模型與現場的實際說法對不起來，中間那段翻譯工作會落到某個人身上。那個人做久了會變成瓶頸，而且他請假的時候整條線會停。
3. 共存設計：三個實際做法
允雷在系統設計裡實際採用的做法，共同前提是同一句話：系統要跟現場共存，不是要現場配合系統。
新舊編號分段，兩邊都能跑
在一個 B2B 補貨系統裡，客戶自助下單的單號從 201 開始跳，前面 1 到 100 號留給原本的人工單。
這個設計只有一行規則，但它同時做到三件事：
- 原本負責開單的同事不會因為系統上線就失去工作路徑，他還是可以照原本方式開單
- 兩種來源事後分得出來，要看自助下單的比例、要追某一筆是誰開的，都有依據
- 不需要在某一天強迫所有人切換，可以讓比例自然移動
導入的阻力常常來自「上線就代表我原本做的事被否定」。編號分段這種設計傳達的訊息相反：你的方式繼續有效，只是多了一條路。
例外要有明確窗口，不是擋住
系統可以辨識的已知例外，應該有一條明確的處理路徑與負責窗口，而不是回傳一個錯誤訊息就結束。
現場遇到系統擋住時，需要知道下一步找誰。沒有這個資訊，他們會自己找路，而那條路通常在系統外。
不搶既有系統的地盤
如果企業已經有 ERP 或既有核心系統，新加的收單入口不需要取代它。
允雷的做法是明確劃出不做的範圍：不做會計、不做發票、不做稅務、不做應收帳款。 那是 ERP 的責任範圍，新系統補的是它前面的入口。
這個邊界不只是禮貌。當一個新系統想同時取代所有東西，導入風險會隨範圍等比上升，而且企業必須同時改變太多習慣。縮小範圍是降低導入風險最直接的方法。
上述設計來自實際專案的取捨，但每個企業的作業與限制不同。這些原則不保證同樣結果，適用性必須依現況評估與正式驗收確認。現場作業與商業判斷仍由企業負責。
4. 評估系統廠商時可以先問的四個問題
功能清單通常比不上這四個問題能預測導入結果：
- 系統上線之後，原本的人工流程還能不能運作？ 如果答案是不能，要確認例外怎麼處理。
- 遇到系統沒有涵蓋的情況，現場走哪條路？ 這條路必須存在且有人負責，不能只有錯誤訊息。
- 資料進去之後發現錯了，誰能修正、要花多久？ 修正成本高的系統，現場會傾向不填資料。
- 需要更換現有的核心系統嗎？ 如果新增一個入口就要求換掉整套 ERP，範圍與風險都值得再評估。
這四個問題不需要技術背景就能問，而且答案通常在第一次會議就聽得出來。
5. 為什麼不能把所有方法寫在公開文章裡
本文說明的是設計原則與取捨邏輯，不包含實際的資料結構、規則設定、系統實作或客戶的內部流程。
原因有二：這些內容涉及合作方的營運資訊；而且脫離具體情境的實作細節，複製到不同企業通常無法運作，反而增加風險。
需要判斷自己的情況適用什麼，比較有效的方式是實際盤點現有流程，而不是照抄別人的設定。
結語：先問系統擋住了什麼，再問怎麼推廣
如果一個系統上線後使用率不如預期，加強推廣的效果通常有限。
比較有機會找到答案的順序是反過來的：先找出系統在哪些情況下讓事情做不完，把那些路徑補起來，使用率才有機會自己上升。
現場人員不是不願意改變，他們只是需要一條今天就能把事情做完的路。
相關閱讀
想評估自己的情況，可以從 ERP 整合服務 或 ERP 夥伴合作 了解合作方式。
