不只建好系統 更要人人識用

人數少，反而更明顯。十幾個人的公司通常一個人兼三份工作，重複輸入佔掉的比例比大公司更高，只是沒有人有時間停下來算。

做法是先只做最痛的一條流程，範圍小、價格也就小，跑順了再往外推。小公司最大的優勢是決策快，不必等三個月開完會才能動。

另外，現在很多 ERP 是月費訂閱制，入門門檻比想像中低，手機也開得到。先把底子理順，日後擴張時就不必從頭來過——重建資料比一開始就理順貴得多。

這取決於範圍，所以我們不會先報一個數字再慢慢加。順序是：先盤點現況、給出範圍與階段建議，報價跟著範圍走。

節奏上，Phase 00–02 約 3–6 週，只做決定、不動資料；Phase 03 試點約 4–6 週，是唯一會痛的階段；Phase 04 之後可以並行推進。

想先有個概念，可以自己填一次試算：輸入行政與內勤的員工人數、員工平均月薪、每人每日花在搬運與對帳的時間、每月因人工錯單與急單運費付出的金額，再加上平均存貨總額與 ERP 一次性建置預算。它會算出年度隱形流失（並拆成人力、錯誤、存貨三塊），再用建置預算得出預估回收期。數字是自己填出來的，比任何報價單上的說法都具體。

最快有感的是月結。多數客戶在第一個完整月結週期就發現天數下降；重複輸入與對帳工時通常在上線後兩至四週陸續消失。

真正需要時間的是習慣，大約一季。這也是我們把培訓按角色拆開、每人只學自己每天會碰到的畫面的原因。

導入後會改變的六件事：資料只輸入一次，抄錯、漏填與版本不一跟著消失；帳面與實物對得上，盤點從翻箱倒櫃變成照清單確認；月結從兩週縮到數天，這是多數客戶第一個注意到的改變；報價當下就算得出賺不賺，低於門檻要授權才送得出去；看到的永遠是今天的數字，要拆到客戶、產品、業務或月份直接切換；資料格式統一、有異動軌跡、可完整匯出。最後一項是日後談自動化或 AI 的前提，沒有它其他都免談。

不要只比軟件授權費，要跟「一年因資料錯誤造成的損失」比。這兩筆錢常常不是同一個量級，只是前者寫在報價單上，後者從來沒有人記帳。

把貴公司自己的人數、薪金與每日浪費在搬運對帳的時間填進估算器，它會先算出每年正在流失的金額，再除以建置預算得出預估回收期。親手算出來的數字，比任何人報給你的都有說服力；也可以把結果帶去預約諮詢，當作討論的起點。

因為軟件本身通常不是問題所在。這個行業的失敗案例，多數來自變革管理，而變革管理無法靠安裝程式解決。

如果只賣軟件就能成功，失敗率不會長期維持在五成以上。業界彙整的數字是：55–75% 的 ERP 專案未達預期（多數屬部分失敗，上線了但價值遠低於承諾），60% 失敗於變革管理而非技術，68% 出現資料遷移錯誤，只有約 16% 準時完成，平均成本超支約 120%。再看失敗模式：68% 的預算超支源於範圍膨脹，70% 的失敗歸因於員工抗拒。這些數字不是要嚇人，而是整套做法都是從它們反推出來的。

不必先讀完任何東西。先花十分鐘看一個茶餐廳落單的故事，比讀十頁功能清單更快建立概念。

那一頁從一間茶餐廳的落單流程講起：客人點餐、樓面落單、廚房收單、收銀埋單，同一張單要輸入四次，於是漏單、算錯、對不上帳。整頁刻意不出現「模組」和「資料庫」兩個詞，看完你會明白問題不在人不夠努力，而在同一筆資料被重複輸入。頁上還有可以親手操作的模擬器，能看見重複輸入怎樣一點一點吃掉利潤。

三件事，次序不要顛倒：先看導入後實際會改變什麼，再算一次不做要付多少，最後才看系統與方法。

那段對照用同一個工作日說明。導入前：客戶問交期要先問倉庫再問生產，半天後才回覆而且未必準；業務憑印象給折扣，月底才發現這張單虧本；帳上說有料、現場找不到，只好緊急採購再補一趟空運；月底跨系統人工對帳兩星期，整個辦公室一起加班；老闆手上的數字永遠是上個月的版本。導入後：交期在電話中就能答；毛利即時算出、低於門檻要授權；儲位與批號即時更新，揀貨單直接帶你走到正確位置；只覆核差異，幾天內收工；開機就是最新數字，要拆到多細自己點。同一天、兩種過法，比任何功能清單都具體。

客戶不是「有 ERP」與「沒有 ERP」兩種。我們用一份八題自我診斷，把公司分成四級：

那份診斷一共八題，大約九十秒做完，會依分數給出四級結果，並額外標出有沒有「補洞型」的傾向。建議讓不同部門各做一次，再對答案——差異本身就是最有價值的訪談素材，常常比訪談記錄更早指出問題真正落在哪一環。

因為這個問題一開始就問錯了。如果問「為什麼還在用 Excel」，答案永遠是「使用者抗拒」「教育訓練不夠」「系統不好用」——然後就卡住了。

換一個問法：Excel 到底在公司裡扮演什麼角色？這兩個問題看起來只差一點點，背後代表的 ERP 成熟度卻可能完全不同。

不一定。「ERP 上線後還在用 Excel」本身是中性的現象，它可能是健康的，也可能是嚴重的警訊。

ERP 擅長管理正式交易、主檔、權限與流程；Excel 擅長彈性模擬、臨時分析、跨表比對。兩者本來就該各司其職。

從 200 則留言歸納出來的「資料流三分法」：

表面上看起來一樣（大家都在用 Excel），意義卻天差地遠。分辨的關鍵在資料往哪個方向流：分析型的源頭在 ERP，Excel 只做下游的模擬與臨時報表，例如財務匯出銷售數據後試算「原料漲價 8% 毛利會變多少」——這份表消失三天，公司營運不受影響。補洞型是 ERP 沒給出使用者真正要的東西，於是每個需求都變成一張客製報表，IT 的報表累積到幾百張，永遠改不完。取代型最危險：訂單先記 Excel、部門之間靠 Excel 傳來傳去、某個公式只有一位資深同仁知道，公司開始出現「兩個版本的真相」。

不是 Excel 的數量，而是依賴的方式。一家公司可以有 200 份分析型 Excel 而非常健康；也可以只有 3 份取代型 Excel 而處於高危狀態。

分析型本身是健康的，但它有一條很容易跨過的線。三個護欄可以讓它留在安全區：

• 源頭必須是匯出，不是手打。資料一律從 ERP 匯出，不在 Excel 裡重新輸入一次。
• 擁有者要具名，邏輯不能只有一個人懂。做這份表的人請假，別人要接得起來。
• 定期做消失測試。這份 Excel 消失三天，公司營運不受影響——過了這一關才算分析型。

這是導入過程中最容易做錯的決定。照這個順序問三題，順序不要顛倒：

• ① 這個需求是交易還是分析？涉及正式交易、稽核與即時性的 → ERP 補；純看數字、做交叉比對的 → BI 補。
• ② 這個需求是常態還是臨時？只出現一兩次的 → 留在 Excel 就好，不必進系統。
• ③ 這個需求是不是在繞過一個本來就該修的流程？如果是 → 先改流程；補工具只會把問題固化。

不要先上報表模組。影子系統之所以存在，通常是因為某個環節在 ERP 裡比在 Excel 裡更麻煩；先做報表，只會讓那個環節更穩固。

正確的方向是往上游找：

• ① 找出「哪一筆交易最早被寫進 Excel」——那一筆通常就是源頭。
• ② 讓那筆交易在 ERP 裡比 Excel 更快：欄位更少、預設值更對、一次能做完。
• ③ 把 Excel 降級為查詢與分析用途，而不是資料入口。

能做的事其實很多——只要它是下游。Excel 最適合這三類工作：

• 假設模擬：「如果原料漲價 8%，毛利會變多少」——ERP 不該為這種一次性問題開欄位。
• 臨時比對：一次性的對帳、跨兩個來源的交叉檢查。
• 對外格式：客戶指定的特殊報價單或標籤格式。

不要一次全部消滅，那會引起全面抗拒。照「離錢的距離」排序，先處理最靠近錢的那一次：

• 第一順位：影響應收應付與庫存的。錯一次就是真金白銀，也最容易在月底變成加班。
• 第二順位：影響交期承諾的。錯一次掉的是客戶信任，而且客戶記得比你想像的久。
• 第三順位：影響管理報表的。重要，但它不會讓公司當天停擺。

先消滅第一順位，使用者一週內就會感覺到差別——這正是後面談流程規範的本錢。先給甜頭，再談紀律。

不用，也不該。涉及交易、稽核與即時性的流程搬進系統；分析與推演留在試算表，兩邊用匯出對接。

一次消滅所有試算表，只會逼出更多看不見的影子檔案——它們照樣存在，只是沒有人知道。

不是要否定試算表，它是最好的分析工具之一。問題在於它同時承擔了「正式流程」的角色。

用一句話測試：這份表如果三天打不開，公司會不會停擺？做這份表的人明天離職，下一個人接得起來嗎？兩題只要有一題答不出來，它就不是分析工具。

不需要，也不建議。多數公司從進銷存加財務起步，跑順一個月再往外推。第一批建議控制在 10–14 個模組。

一次全上會把風險集中擠在同一段時間，出問題時很難判斷是哪一塊造成的，士氣也容易一次被打掉。第一批的原則是優先處理最靠近錢的流程，其餘按階段補上：貿易批發從第三方、產品與服務、客戶訂單、客戶發票、庫存、複式會計起步；製造業再加上 BOM、工單與含批號序號的庫存；服務業則不必硬開庫存與製造模組。多幣別、付款條件與信用額度這一類設定要在第一批就設好，後面補救的成本極高。

會痛，我們不否認。硬說「一切照舊、完全沒感覺」，只會讓人更不信任。真正該問的是三件事：痛在哪個環節、會痛多久、出了狀況能不能退。

做法是把風險關在一個部門或一條產線裡，並事先把切換期的規則講死：並行幾週、異常由誰即時接手、出現什麼狀況就回退。先讓人看到出口，才願意往前走。

主檔清理也有固定順序，順序錯了會白做：先客戶與供應商（去重、統一編碼、補齊聯絡人與付款條件、信用額度），再產品與服務（編碼規則、單位、稅率、定價與折扣），製造業接著 BOM 與製程，然後期初庫存（含批號序號與儲位，建議配合一次實地盤點）、期初應收應付（逐筆、含帳齡）、科目表與開帳分錄（與會計師事務所對齊），最後才是使用者、角色與權限。先建交易、後補主檔，等於重新來一次。

不要比軟體授權費，改比「一年因資料錯誤造成的損失」。把估算器拿出來，讓他自己填參數——他親手算出來的數字，比你報給他的任何數字都難反駁。

同時強調可以只做核心模組（例如先做進銷存＋財務），不必一次全上。把一筆大金額拆成可分期的小承諾，決策門檻立刻下降。

大多數抗拒不是因為討厭新東西，而是因為「我又多了一份工」。所以順序要顛倒過來：先砍掉基層最煩的那幾項重複輸入，讓第一週就嚐到甜頭，之後才談流程紀律。

培訓按角色設計，每人只學自己每天會碰到的畫面，並留下專屬文件與影片。另外要找各部門配合度高的同仁當種子使用者，讓抗拒者看到的是「隔壁組變輕鬆了」，而不是「上面又推一個新規定」。

各角色該學什麼、不該學什麼，其實有一份對照：老闆學儀表板解讀、毛利與現金流報表、權限與簽核設計，不學日常單據操作；財務主管學結帳流程、應收應付帳齡、成本歸集與稽核軌跡，不學前端銷售操作；業務主管學報價與定價規則、信用額度控管、可用庫存與交期查詢，不學會計分錄與總帳；倉務主管學收發料、儲位、批號序號與盤點；生管與廠長學工單、領料、完工入庫與異常處理；IT 主管學模組啟用、使用者管理、備份還原與完整匯出。每一項都對應一份交付物（操作卡、SOP、流程圖或維運手冊），不是上完課就算——種子使用者另外要學「怎麼教別人」，那本內部講師手冊才是整個體系的重點交付。

不一定，兩種情況要分開看。有時候是習慣，有時候是他真的知道某個流程在現場跑不動。

成熟的專案不能只問「為什麼你不照系統操作」，也要問「你為什麼不願意照這個流程操作」。答案可能是抗拒改變，也可能是設計真的忽略了現場。

兩個極端都有代價：

• 完全要求使用者適應系統 → 每個人說一句「以前不是這樣做」就改 ERP，最後變成一套極度客製、難以維護的系統。
• 完全不修改系統 → 永遠只回答「標準系統就是這樣，請配合」，最後使用者在系統旁邊重建自己的工作方法。

答案從來不是二選一。真正該問的是：哪些流程該標準化、哪些差異構成競爭力、哪些需求值得進系統，哪些交給試算表或 BI 反而更合理。

使用者說「我要一張報表」，IT 就做了一張報表。但他真正需要的，也許不是報表，而是某個流程的資訊太晚出現。

困難的不只是把使用者的話記下來，而是繼續往下問：「你為什麼需要它？」而這個追問，常常在上線前的忙碌中被跳過了。

很多在正式上線之前就埋下了。專案通常花大量時間確認程式有沒有 Bug、介面通不通、資料轉檔正不正確、權限對不對——這些都測得到。

但有一種問題很難測：我們當初解決的，是不是真正的問題？

對應的做法是七條不可妥協的原則：先盤點、後報價；先做核心、不求一次到位（第一階段控制在 10–14 個模組）；範圍要寫死，也要寫明「不做什麼」；資料源頭只能有一個；先給甜頭、再談紀律；每一階段都要能停；交付完成的標準是團隊能獨立運作。這七條的共同點，都是為了讓錯誤早一點、小一點被發現——第一條正是「先盤點，後報價」。

可以。通常不是因為系統壞了，而是續約價一次跳太多，或者發現資料只能一頁一頁匯出，才決定換。

但先不要談搬遷。先做一次健康度診斷，分清哪些試算表可以留、哪些必須把源頭拉回系統，再決定搬遷範圍。順序是主檔 → 期初 → 交易，分批進行。

三個層次。第一，交付後由我們提供支援。第二，這套系統有全球社群與官方文件，問題不是只有我們能解。第三，原始碼公開，任何合格的開發者都能接手。

封閉系統的問題是只有原廠能解；開源的問題是誰都能解。對你來說，後者的風險更低。

是你的。開源授權、一次性交付，資料庫放在你自己的主機上，隨時可以完整匯出。

這一條不是口號，是合約寫得出來、也驗收得到的東西。四條承諾各附查證方式：範圍寫死並明列「不包含」，簽約前索取範圍說明書逐條確認；每一階段都能停，合約載明停損條件與退出方式；系統與資料都是您的，可以要求現場示範完整匯出一次；交付完成等於團隊能獨立運作，第二次驗收後由您的員工在我們不介入的情況下跑一次完整月結。做不到時怎麼處理，也一併寫在合約裡。

規模小是我們的選擇，不是弱點。大廠的專案最後由誰執行？通常是外派顧問——你簽的是品牌，來的是人。

我們的專案由同一位負責人從盤點做到第二次驗收，中間不換人。更實際的一層保障是：原始碼與資料都在你手上，即使我們明天消失，任何懂這套系統的團隊都能接手。

不會，前提是範圍寫死。變更需要雙方書面同意後另立階段。

我們也遇過客戶中途想加功能，答案通常是「這屬於下一階段」——這是紀律，不是刁難。反過來說，如果範圍一開始就含糊，後面一定會吵。

雲端 ERP 像把帳目放進保險庫：電腦壞掉、火災漏水，資料都還在，而且會自動備份。

重點是挑信譽良好的供應商，並為帳戶設定強密碼。另外，你也可以選擇把資料庫放在自己的主機上——這一項我們兩邊都做得到。

一般的驗收發生在上線前後：功能完成、測試完成、資料轉換完成、系統上線、專案結案。

但 ERP 還應該有一次上線後的驗收，也許是半年後，甚至一年後。那時候要問的已經不是專案進度，而是現場的人現在怎麼工作。

第一次驗收的項目是：範圍說明書裡的模組全部可運作、主檔與期初資料經客戶書面確認、權限與簽核依設計生效、各角色完成培訓並通過實操、切換期規則（並行多久、異常處理人、停損線）已確認、維運手冊與匯出方式已交付。

第二次驗收則回填六個成效指標，並產出下一階段的優化清單、模組擴充建議與範圍提案——那是一份要拿去排下一輪工作的東西，不是打分數用的。

不是打分數，而是決定下一輪做什麼。把六個問題的答案分成三類：

• 還在痛的——當初要解決卻沒解決的，回頭檢查需求訪談哪裡沒追到真正的問題。
• 新出現的人工流程——優先處理。新長出來的步驟，代表某個環節沒被系統接住。
• 回流的試算表——先分類。分析型就讓它留著，取代型才需要把源頭拉回 ERP。

產出應該是一份下一階段的優化清單，而不是一份檢討報告。

不要從系統修，先從「最近一次有人繞過系統」開始查。偏離通常不是設計錯了，而是某個環節在現實中變得比設計更麻煩。

• ① 找出最近一次「先做 Excel、事後補登」的案例。不用普查，找一件就夠。
• ② 問當事人：當時是哪一步讓你覺得繞過去比較快？答案通常很具體，而且不會只是「系統難用」。
• ③ 那一點就是設計與現實的落差。修那一點，比重新導入一次便宜太多。

如果還在，代表當初的需求訪談沒有追到真正的問題。

這是六個問題裡最重要的一題，因為它同時檢驗了專案與需求訪談兩個環節。問的時候要找當初的專案章程與問題清單，逐條對。

回來的那些，是在做分析，還是在做正式流程？這是判斷健康度的分水嶺。

分析型可以安心留著，甚至值得鼓勵；取代型的要立刻處理。分辨時可以拿三組句子去對：分析型的特徵是資料源頭來自 ERP 匯出、這份表消失三天公司不會停擺、做表的人離職下一個人接得起來；補洞型的特徵是 Excel 存在的原因是 ERP 沒滿足需求、不同主管想從不同角度看同一批資料、需求永遠改不完；影子系統的特徵是訂單先記 Excel 月底才補進 ERP、部門之間靠 Excel 傳來傳去、某個公式只有一位資深同仁知道、主管真正相信的數字是某人桌上的那份表。三張清單檢查的是「現在的 Excel 角色」，值得在導入滿六到十二個月後再回頭跑一次。

新出現的人工步驟，通常代表某個環節沒有被系統接住。

這一類要優先處理。它不像「還在痛的」那樣明顯，但它會慢慢長成新的影子系統，而且是專案結束之後才長出來的，沒有人負責。

這是多數公司不願承認的單點故障，也是關鍵人風險的源頭。

那個人一請假，流程就卡住。解法不是叫他寫文件了事，而是把他的整理邏輯搬進系統或標準作業流程，讓它不再依賴任何一個人。

開會時第一個問題是「哪份才對」，就代表信任還沒建立。

信任不是靠宣導建立的，是靠源頭資料品質建立的。順序是：先修源頭，再談報表與 BI——順序顛倒只會加速失去信任。

業務會長大，流程也要跟著調整。這是持續優化的起點，不是失敗的證據。

如果答案是「已經不一樣了」，那不代表設計錯了，而是代表公司長大了——該做的是更新設計，而不是回到舊流程。

不是。未啟用的模組不會出現在選單，也不會干擾使用者——這是這套平台與封閉系統最大的差別之一。

反過來說，開了用不到的模組是有代價的：選單變長、使用者要多按幾下、訓練要講更多。第一批建議只開 10–14 個，優先處理最靠近錢的流程。

想知道某一個模組到底在做什麼，可以點進去看詳細說明，也可以用搜尋直接找功能名稱——在選型階段先把清單看過一遍，比等到上線後才發現某個需求沒被涵蓋便宜得多。

用情境反推，不要用功能清單反推。把貴公司的狀況勾一勾，就會得到一組建議啟用的最小組合。

例如貿易批發業的常見核心是：第三方、產品與服務、客戶訂單、客戶發票、庫存、複式會計；服務業則不必硬開庫存與製造模組，開了反而增加輸入負擔與抗拒。

情境可以複選，因為多數公司同時符合好幾種狀況。點結果中的任一項可以看詳細說明，方便判斷某個模組是「現在就要」還是「下一階段再說」。

先盤流程，再開模組。第一批優先處理最靠近錢的流程，其餘按階段補上。三個產業情境的建議批次：

除了上表三個情境，餐飲門店建議從產品、TakePOS、庫存與複式會計起步，重點是 POS 與庫存必須同步，否則帳實第一週就脫節，配方也要先整理好；已經有 ERP 要換的，先依健康度診斷決定搬遷範圍，順序是主檔、期初、交易，分批進行。第二批與第三批通常是採購與供應商發票、專案與任務、工作流程、報表與電商同步，按階段補上就好。