ERP 上線前檢查清單：切換當週不出事的 20 個項目

「廠商說都測完了，下週一直接上線，應該沒問題吧？」

這句話我在專案的最後一個月幾乎每次都會聽到。老闆講這句的時候通常是放鬆的，因為漫長的需求訪談、報價、開發、測試都過去了，終於要看到成果。但我心裡想的通常是另一件事：測完，只代表系統會動；不代表公司準備好換一種方式工作。

我是熊董，台灣川輝科技。我帶團隊做系統導入七年，經手超過 34 個案子、橫跨 14 個以上產業，現在一個人加 AI，一年交付 2,000 萬以上的客製系統。我的結論很直接：ERP 上線那一週出事，很少是因為程式有 bug，多半是因為切換當週該拍板的事沒人拍板——哪一天切、期初庫存與應收應付由誰簽字確認、舊系統哪一刻改成唯讀、出問題打給誰、什麼情況要退回舊系統。把這些拆成資料、人員、系統、應變四類，各五項，一共 20 個檢查點，切換前一週逐項打勾；有任何一項是空白，就延後上線，延一週的代價遠低於硬上之後收拾一個月。

先承認：想「一次切乾淨」的直覺沒有錯

很多老闆想要的是乾脆：週五下班關掉舊系統，週一早上大家打開新系統，從此只有一套。這個直覺是對的。兩套系統並存越久，資料越容易分岔，員工也越有藉口繼續用舊的那套，拖到最後誰都說不清哪邊的數字才算數。

問題不在「一次切」這個決定，而在大家以為一次切只是一個按鈕。實際上，系統切換是一連串交接：舊系統的最後一張單是哪一張、新系統的第一張單從幾號開始、月中還沒出完的訂單在哪一邊收尾、已經開出去還沒收回的票據怎麼掛。每一個交接點都需要一個人負責、一個時間點、一份簽過字的數字。

我看過的切換事故，大多是這個樣子：上線第二天，業務發現客戶的未出貨訂單在新系統裡找不到；會計發現期初應收少了一批，因為那批是切換前一天才開的發票；倉庫說新系統的庫存跟實際不一樣，但沒人知道是轉檔轉錯，還是本來就不準。三件事同時爆，每一件都不難，難的是沒人知道該先處理哪一件、誰說了算。

所以這份清單的重點不是技術，是把交接點一個一個釘死。

切換日怎麼選？避開月結、旺季與老闆不在的那一週

選日子是第一個決定，也是最常被隨便決定的一個。很多公司的上線日是從專案時程倒推來的，「合約寫三月底，那就三月最後一個週一」。這個邏輯對廠商有意義，對你沒有。

切換日該避開三種時間。第一是月結前後，會計一邊要關上個月的帳、一邊要學新系統開這個月的帳，兩件事都會做不好。比較理想的做法是在月初切，讓上個月在舊系統完整結完，新系統從一個乾淨的月份開始。第二是旺季，出貨量最大的那幾週，任何一個卡住的環節都會被放大成客訴。第三是關鍵人不在的那一週，包括老闆、會計主管、倉庫主管，以及廠商那邊真正懂系統的那位工程師。

還有一個常被忽略的條件：切換日後面至少要留五個工作天不排其他大事。不要同一週去參展、不要同一週盤點、不要同一週換辦公室。上線第一週是整個專案最需要注意力的時候，把注意力留給它。

ERP 上線前 20 個檢查項目：四類各五項

下面四張表是我在切換前一週會帶著客戶逐項確認的內容。每一項都要寫上負責人的名字，不是部門名稱；寫「財務部」等於沒人負責。

第一類：資料（期初數字對得起來）

項目	怎麼算完成
1. 主檔凍結	切換前兩週起，新增料號、客戶、供應商只能經一個人核准，並同步兩邊
2. 期初庫存	切換前做一次盤點，倉庫主管簽字確認數量，這份數字才是新系統的起點
3. 期初應收應付	逐家客戶、廠商列出未收未付明細，會計主管簽字，總額要跟舊帳相符
4. 未結訂單	已接單未出貨、已採購未進貨的單據，決定在哪一邊收尾，並列出清單
5. 轉檔抽查	隨機抽 20 筆以上資料，新舊兩邊並排比對，抽查結果留檔

資料這一類最容易被交給廠商「幫忙轉一轉」。轉檔可以交給廠商，但簽字不能。期初數字一旦錯了，之後每一張報表都是錯的，而且錯得很安靜。舊資料到底要搬多少、怎麼搬，我在ERP 資料轉移的真實成本那篇有拆過，切換前一週要做的只是確認：搬過來的那份數字，有人願意簽名負責。

第二類：人員（每個人知道週一要做什麼）

項目	怎麼算完成
6. 每個角色的第一天任務	業務、倉管、會計各有一張紙，寫週一早上第一件事在新系統怎麼做
7. 關鍵使用者	每個部門指定一位種子人員，部門內的問題先問他
8. 帳號與密碼	每個人在切換前登入過一次，確認帳號能用、權限看得到該看的畫面
9. 用真實資料練過	每個角色至少用自己上週的真實單據，在測試環境完整跑過一遍
10. 舊習慣的替代方案	原本靠 LINE 或 Excel 做的事，新系統裡對應在哪一個畫面，寫清楚

第 9 項是我最堅持的一項。教育訓練用示範資料上課，大家都會點；換成自己昨天那張複雜的訂單，一半的人會卡住。卡在測試環境，是學習；卡在上線第一天，就是客訴。訓練怎麼排才有用，可以參考ERP 教育訓練上線前後的四週的做法。

第三類：系統（環境、權限、單據都就位）

項目	怎麼算完成
11. 正式環境備妥	正式機與測試機分開，正式機已完成最後一次部署並記錄版本
12. 權限設定	依角色設定，誰能改單價、誰能刪單、誰能調庫存，逐一確認
13. 對外單據格式	報價單、出貨單、發票相關單據列印出來，請業務與會計確認格式
14. 周邊設備與串接	印表機、條碼機、電商或會計軟體串接，在正式環境實際跑過一筆
15. 備份與還原	確認備份排程在跑，而且實際還原過一次，不是只看到設定畫面

第 13 項常常在上線當天才被發現：出貨單的欄位客戶看不懂、發票抬頭跑版、報價單少了公司章的位置。這些都不是系統壞掉，但每一件都會讓業務覺得「新系統比舊的難用」，然後偷偷改回原本的方式。

第四類：應變（出事時知道找誰、怎麼退）

項目	怎麼算完成
16. 問題回報管道	一個固定的群組或表單，所有問題都從這裡進，不接私訊
17. 問題分級	事先定義哪種叫「停線級」、哪種叫「當天修」、哪種叫「排進下週」
18. 支援名單與時段	廠商工程師與內部窗口在切換週的值班時間，寫上手機號碼
19. 退回條件	寫下什麼情況要退回舊系統、誰有權決定、最晚哪一天決定
20. 舊系統處置	舊系統在切換後改為唯讀，保留多久、誰還能登入，事先講好

新舊系統要不要並行？並行查詢可以，並行輸入不要

這是切換前最常被吵的問題。保守的主管會希望新舊系統一起跑一個月，兩邊都輸入，數字對得起來再關掉舊的。聽起來很安全，實際上很少成功。

原因很現實：同一張單要輸入兩次，第一週大家還願意，第二週開始就會有人只輸入一邊，通常是比較熟的舊系統。到了月底兩邊對不起來，沒人知道是新系統算錯，還是有人漏打。你花了雙倍的人力，換來一份沒辦法判斷的比對結果。

我比較建議的做法是「並行查詢，不並行輸入」。切換日之後，所有新單據只進新系統；舊系統改成唯讀，保留查詢歷史資料的功能。這樣員工不會失去過去的紀錄，但也沒有退路可以偷偷回去開單。

例外是金額計算邏輯特別複雜的部分，例如分潤、獎金、成本分攤。這類東西可以在切換前，用上個月的真實資料讓新系統算一次，跟舊方式的結果逐筆比對。比對是在切換前做完的事，不是上線後兩邊一起輸入。

上線第一週的作戰室怎麼排？

切換日當週，我會要求成立一個臨時的作戰室。不一定是實體房間，可以是一個固定的會議時段加一個問題清單，但規則要清楚。

每天早上十五分鐘、下午收工前十五分鐘，各部門的種子人員加廠商窗口一起過一次問題清單。早上確認今天哪些問題會修、誰修；下午確認修好了沒、有沒有新問題。所有問題都進同一份清單，每一筆有編號、回報人、分級、負責人、狀態。

問題分級要在切換前定好，不要在現場吵：

等級	定義	處理時限
停線級	不能開單、不能出貨、不能收款	立刻處理，必要時啟動人工替代方案
當天修	能做但很卡，或數字有疑慮	當天回覆處理方式
排進下週	操作不順、畫面想調整、報表想加欄位	集中到第二週評估

「排進下週」這一級特別重要。上線第一週一定會冒出很多「這邊可不可以多一個欄位」的需求，如果每一個都當場改，系統會在一週內被改得亂七八糟，而且真正的停線問題反而沒人力處理。先記下來，第二週一起看，很多需求到時候自己就消失了，因為大家已經學會原本的做法。

我在一家印刷廠的經驗可以說明人為什麼重要。他們前面花了超過百萬、買了兩套 ERP 都用不起來；第三套照他們自己的流程做，員工採用率從不到兩成到九成以上。差別不在功能多寡，而在上線時每個人知道自己的流程在新系統長什麼樣子。如果你的團隊已經出現抗拒的跡象，員工不用新系統怎麼辦那篇的救援做法可以先讀。

什麼情況該喊停、退回舊系統？

沒有人想在上線之後退回去，所以退回條件一定要在上線前寫，而且寫得越具體越好。上線後再討論要不要退，每個人都有立場：廠商不想退，專案負責人不想承認失敗，老闆捨不得已經投入的時間。

我建議寫成三條：第一，停線級問題持續超過約定的時間仍無法用人工替代方案撐過去；第二，期初數字被發現有大範圍錯誤，必須重新轉檔；第三，某個核心流程（開單、出貨、收款其中之一）在新系統完全走不通。任何一條成立，由事先指定的那個人決定退回，不開會投票。

同時要確定「退得回去」。舊系統在切換後幾天內不能被刪除、不能被停租、資料不能被清空。很多公司在上線當天就把舊系統的授權停掉，等到需要退的時候，才發現已經沒有地方可以退。

退回不等於失敗。退回之後把問題修好，再選下一個切換日，比硬撐著讓整間公司用一套沒人信任的系統，損失小得多。上線之後的驗收怎麼寫進合約，讓這些條件有依據，可以搭配ERP 驗收條款的五個條件一起看。

常見問題

ERP 上線前要先停止營業嗎？

通常不用。比較常見的做法是選週五下班後開始切換，週末完成期初資料匯入與最後確認，週一照常營業。真正需要的是切換前一兩天暫停新增主檔、盡量減少跨日未結的單據，讓切換點乾淨。

系統切換要留多少緩衝時間？

我的建議是切換日之後至少五個工作天不排其他大事，第二週再集中處理非緊急的調整需求。至於切換前，主檔凍結、彩排與期初確認大概需要兩週，這段時間要寫進專案時程，不要被壓縮掉。

期初庫存一定要重新盤點嗎？

最好要。舊系統的庫存數字如果本來就不準，直接轉過來只是把錯誤搬家，而且之後會被誤認為新系統算錯。切換前的盤點不用追求完美，但要有人簽字確認，這份數字才有資格當新系統的起點。

上線第一週問題太多，要不要先退回舊系統？

先看問題的等級，而不是數量。第一週冒出幾十個「操作不順」的回報很正常，那不是退回的理由；退回只看事先寫好的條件，例如開單、出貨、收款其中一項完全走不通，或期初數字大範圍錯誤。條件沒成立，就照作戰室的節奏一件一件處理。

結語：上線不是一個按鈕，是一連串簽過字的交接

ERP 上線那天看起來像是專案的終點，其實是公司開始用新方式工作的第一天。程式準不準備好，廠商會告訴你；公司準不準備好，只有你這份 20 項清單能告訴你。每一項寫上人名、每一個數字有人簽字、退回的條件事先寫死，切換當週就不會變成救火週。

如果你正在規劃導入，想先看整個過程從評估到上線怎麼排，可以參考ERP 導入怎麼做。