做 ERP 這行最大的痛是什麼？不是技術難、不是加班多，而是每個客戶都覺得自己的流程「很特殊」。
「我們公司的採購流程跟別人不一樣」、「我們的簽核邏輯比較複雜」、「這個報表的格式一定要長這樣」— 聽了十幾年，我已經可以在客戶開口前就猜到下一句是什麼。標準功能明明覆蓋了八成需求，但客戶永遠只盯著那兩成的差異，然後跟你說：「這個客製化應該很簡單吧？」
客製化做到最後，維護成本吃掉利潤，團隊被綁死在舊案子裡，新功能永遠排不上。這就是我們這行的「客製化地獄」。但最近一兩年，AI 的進展讓我看到一些脫離地獄的可能性。
ERP 客製化的現實
先說說這個地獄到底有多深。
標準功能覆蓋 80% 的需求，這個數字聽起來很高對吧？但問題是，客戶不會因為那 80% 選你，他們會因為那 20% 的差異來決定要不要用你的系統。更慘的是，那 20% 往往涉及他們最核心的業務流程 — 採購審批的特殊邏輯、生產排程的獨家算法、品質檢驗的多層簽核。
客製化的成本不只是「開發」而已。寫 code 可能花一週，但後續的維護才是真正的黑洞。每次產品版本升級，你要確保客製化的邏輯還能正常運作。每次修 bug，你要小心不能影響到客製的部分。然後客戶會問你：「為什麼升級要這麼久？」因為你有三十個客戶，每個的客製邏輯都不一樣，升級等於要測三十次啊（內心吶喊）。
客製化的技術債暴雷現場
我見過最離譜的狀況是，某個客戶的系統裡有一段十年前寫的存儲過程，當初寫的人早就離開了，文件是零，註解也只有一行 -- 特殊處理。問題是這段 code 涉及月結的核心邏輯，每個月跑一次，跑不出來整間公司的帳就關不了。
你敢動它嗎？不敢。但它偶爾會出問題，出問題的時候你又必須碰它。這就是客製化的技術債 — 不只是 code smell，是真正的業務風險。
小團隊做 ERP 的日常就是：人少、客戶多、每個案子的客製邏輯都不同，然後永遠在救火。今天 A 客戶的報表跑不出來，明天 B 客戶的簽核流程卡住，後天 C 客戶說上個月改的功能又壞了。你以為今天可以寫新功能，結果一整天都在處理客戶的 support ticket。
而真正的地獄是什麼？是客戶說「這個很簡單吧」的功能。「我只是想在出貨單上多一個欄位」— 聽起來很簡單，但那個欄位的值要從採購單帶過來，經過 BOM 表的換算，還要根據客戶等級套用不同的計算邏輯。一個「簡單」的欄位，可能要動到三個模組的核心流程。
一個「簡單」需求的真實故事
某個客戶有一次提了一個需求：「出貨單列印的時候，品名後面要加上客戶的品號。」聽起來超簡單對吧？但一查才發現：
- 客戶品號存在另一個模組的對照表裡
- 同一個產品對不同客戶有不同的品號
- 有些產品是組合品，要顯示子件的品號
- 列印格式已經被客製過三次，report designer 的版本跟目前系統不相容
最後這個「簡單」的需求花了快兩週才搞定。客戶大概覺得我們很混，但我實在沒辦法跟他解釋這裡面的水有多深。
AI 帶來的改變：已經發生的
好了，抱怨完了。來說說好消息。
過去一兩年，AI 已經實實在在地改變了我們團隊的工作方式，雖然不是什麼驚天動地的革命，但確實讓日子好過了一些。
Code generation 是最直接的效益。客製功能裡有大量的 boilerplate — CRUD 的 API、表單的 validation、資料轉換的 mapping。這些重複性高但又不能出錯的 code，現在交給 AI 寫初稿，人只需要處理核心的業務邏輯。以前一個客製功能要寫三天，現在一天半就能搞定。不是因為 AI 寫的 code 完美無缺，而是它幫你把「不需要思考但必須寫」的部分先處理掉了。
舉個具體的例子。某個客戶需要一個「供應商評鑑」的客製模組。以前的做法是：
- 手動建 database table schema
- 寫 Entity class 和 DbContext 設定
- 寫 Repository 和 Service 層
- 寫 API Controller
- 寫前端表單和列表
- 寫 validation 和 error handling
現在？把需求文件丟給 AI，跟它說「參考 CLAUDE.md 裡的架構規範」，它可以一口氣把 1-5 的初稿全部產出來。我只需要 review 業務邏輯的部分 — 評鑑分數的計算方式對不對、權重的設定合不合理、狀態流轉有沒有遺漏。
但要讓 AI 有效幫忙，有個前提 — 你的 codebase 要夠標準化。如果每個專案的架構都不一樣、命名規則都不同，AI 也會一頭霧水。這點後面會再提。
需求分析 也是一個 AI 發揮很好的地方。客戶給的需求文件通常是一堆散亂的文字，夾雜著截圖和「如附件」。以前要花半天整理，現在丟給 AI 先做結構化 — 拆出 user story、列出影響範圍、標記不明確的地方。再拿這份結構化的結果和開發團隊 review，效率高了不少。
Bug 定位 可能是我最滿意的應用。客戶回報問題的時候，描述通常是「系統壞了」「報表跑不出來」這種超模糊的說法。以前要花很多時間問清楚、看 log、reproducing。現在把 error log 和客戶描述一起餵給 AI，它可以先幫你縮小範圍 — 可能是哪個 module、可能是什麼原因、建議從哪裡開始查。不一定百分百準確，但至少省了第一步的摸索時間。
文件撰寫 就更不用說了。操作手冊、API 文件、流程圖說明 — 這些以前總是拖到最後才寫（或根本不寫，別假裝你有寫）。現在讓 AI 根據 code 和 commit message 先產初稿，人再修正潤飾。文件的完成率從「隨緣」提升到了「至少有」。
AI 帶來的改變：正在發生的
除了開發端的改變，產品端也開始出現一些有趣的可能性。
自然語言查詢 ERP 資料 是我覺得最有潛力的方向。ERP 的報表功能通常很強大，但也很複雜 — 使用者要知道去哪個畫面、選哪些條件、怎麼設定篩選。如果使用者可以直接問「上個月出貨量前十大客戶」或「這個月應收帳款超過 90 天的有哪些」，不用學操作介面就能拿到答案，這對終端使用者來說是巨大的體驗提升。
當然，這裡面有很多細節要處理 — 資料安全（使用者能查到的範圍）、查詢效能（不能讓 AI 生出一個跑十分鐘的 SQL）、結果正確性的驗證。但方向是對的。
智能表單驗證 也很有意思。傳統的 validation rule 是寫死的 — 數量不能為負、金額不能超過多少。但 AI 可以根據歷史資料判斷「這筆訂單的數量是否異常」。比如某個客戶平常都下一百件，這次突然下一萬件，系統可以跳出提醒。這不是 bug，而是「你確定嗎？」的智能檢查。
釣魚郵件防護 是近期越來越重要的議題。做 ERP 的人都知道，企業最怕的資安事件之一就是偽裝成供應商的詐騙郵件 — 通知你匯款帳號變更、要求緊急付款。AI 在辨識這類釣魚郵件方面已經比傳統的 rule-based 方法好很多。
工作流建議 則是 AI 分析過去的審批紀錄，建議最佳的簽核路徑。哪些類型的申請通常要經過誰、平均要多久、哪個環節最容易卡住 — 這些 pattern 讓 AI 來挖掘，比人工分析快得多。
AI 如何改變 ERP 的售前流程
這是我最近特別有感的一點。以前做 ERP 的售前簡報，要花大量時間準備客戶的產業背景、競品分析、功能對照。現在把客戶的基本資料和需求丟給 AI，它可以快速產出一份產業分析報告，包括這個產業的常見 ERP 需求痛點、通常會要哪些客製功能、導入時最容易碰到的問題。
雖然 AI 產出的分析不能直接拿來用（每個客戶的實際情況還是要實地了解），但作為事前準備的起點，效率高了不只一個檔次。至少你去拜訪客戶之前，不會一片空白。
AI 還做不到的事
說了這麼多好話，也要說說 AI 目前還無法處理的部分，免得大家期望太高。
首先，AI 無法理解客戶的「政治」。ERP 的簽核流程表面上是邏輯問題，但實際上是人際問題。為什麼這張採購單要經過那個部門的主管？不是因為流程規定，是因為那個主管想要 control。為什麼報表要寄給不相關的人？因為老闆交代的。這種「潛規則」AI 讀不懂，你也很難用 code 來表達。
其次，跨系統整合 仍然是高度客製化的工作。ERP 要和 MES（製造執行系統）、WMS（倉儲管理系統）、CRM 串接，每家的 API 格式、資料定義、同步方式都不同。AI 可以幫你寫 API 的 boilerplate code，但整合的邏輯 — 什麼資料要對應到什麼欄位、衝突時怎麼處理、斷線時怎麼重試 — 這些還是需要人來設計。
再來，資料遷移 也是 AI 幫不太上忙的地方。每個客戶從舊系統搬到新系統，資料格式、欄位定義、歷史資料的清洗 — 這些高度客製的工作需要大量的人工判斷。AI 可以幫你寫一些資料轉換的 script，但「這個欄位在舊系統裡什麼意思」「這筆資料明顯是錯的但客戶堅持要保留」這類問題，AI 處理不了。
最後，AI 無法取代導入顧問。客戶需要的不只是一套系統，還有「被理解」的感覺。他們想要一個人坐在對面，聽他們講他們的痛點，然後告訴他們「我懂，我們可以這樣解決」。這個「被理解」的體驗，AI 暫時做不到。
給 ERP 同業的建議
如果你也在做 ERP，這是我這兩年摸索下來的一些心得。
先從內部工具 AI 化開始。不要急著在產品上加 AI 功能給客戶用。先讓你的開發團隊用起來 — code generation、文件生成、bug 分析。內部用順了，你才知道 AI 的能力邊界在哪裡，再來規劃客戶端的 AI 功能，就不會開出做不到的支票。
標準化你的 codebase。這是讓 AI 有效幫忙的前提。如果你每個專案的架構都不一樣、命名都不同、連 folder structure 都亂七八糟，那 AI 也救不了你。花時間建立 coding conventions、統一專案結構、寫好 onboarding 文件。這些工作對人有幫助，對 AI 更有幫助。我自己的做法是在每個專案根目錄放一份 CLAUDE.md，描述架構、coding conventions、常見 pattern，讓 AI coding agent 讀了就能上手。
記錄你的 domain knowledge。什麼是「帳齡分析」？「三聯式發票」的邏輯是什麼？「月結 60 天」在系統裡怎麼實現？這些 domain knowledge 是 AI 沒有的（或者說它有的是通用知識，不是你的行業 know-how）。把這些整理成文件，一方面團隊新人可以學，一方面 AI 也能參考。這是你的核心競爭力，不要讓它只存在於老員工的腦袋裡。
建立客製化的模組化框架。與其每次客製都從頭寫，不如設計一套模組化的架構 — 讓客製的部分可以像 plugin 一樣掛上去，不影響核心系統的升級。這不是新概念，但在 AI 時代特別重要，因為 AI 在標準化的框架裡寫 code 的效率遠高於每個案子都是 ad-hoc 的做法。
結語
ERP 不會被 AI 取代。客戶的流程太複雜、太多「政治」、太多跨系統的眉角，這些短期內 AI 處理不來。
但不用 AI 的 ERP 團隊，會被用 AI 的 ERP 團隊取代。
當別人的團隊可以用一半的時間完成客製功能、用 AI 幫忙寫文件和抓 bug、讓 AI 在標準化的 codebase 上高效工作的時候，還在用純人力硬扛的團隊就會發現 — 不是你技術不好，是你的效率跟不上了。
擁抱 AI 不需要什麼大革命。先從小的地方開始 — 讓 AI 幫你寫 boilerplate、讓 AI 幫你整理需求、讓 AI 幫你讀 log。然後標準化你的開發環境和 codebase，讓 AI 更容易參與你的工作流程。
客製化地獄不會消失，但有了 AI 這個隊友，至少地獄的溫度可以降低一些。在這個行業待了這麼多年，第一次覺得「改變」不是威脅，而是一個讓工作沒那麼痛苦的機會。