選錯套裝軟體的成本，往往比客製化貴。因為前者的沉沒成本會反覆出現：每次業務流程調整都要繞開系統的限制，每次匯出報表都要人工二次加工，每一年續約都在為用不到的模組付錢。
這不是套裝軟體的錯，是「合身度」的問題。ERP、CRM、電商平台這類產品之所以能標準化，就是因為它把八成企業的共通需求抽出來做成模組。但如果你的業態剛好落在剩下的兩成——例如需要特殊計價邏輯的批發、需要串接工廠 MES 的貿易商、或有獨特會員層級規則的品牌電商——套裝軟體的「彈性」通常只到欄位客製，動不到流程本身。
什麼情況該考慮客製
可以用三個問題自我檢查：
第一，核心競爭力是否綁在流程上？ 如果你的差異化來自獨特的訂單處理邏輯、報價方式、或跨部門協作節奏，這些恰恰是套裝軟體最難改的地方。用套裝軟體逼員工「就系統」，等於自願放棄差異化。
第二，你有沒有需要長期演進的資料資產？ 客戶行為、訂單歷史、生產參數這些資料的價值，隨時間累積會越滾越大。放在封閉的 SaaS 上，未來要抽出來做 AI 應用或跨系統整合，門檻通常比想像中高。
第三，外部整合點會不會越來越多？ 假設一家中型品牌，未來一年要接三家物流、兩個金流、一個 POS、一個會員 App，還想把資料回拋到 BI——這種情境下，一套能自由擴充 API 的自建系統，長期成本往往低於在套裝軟體上疊外掛。
規格書要寫的其實是「不做什麼」
很多失敗的客製化專案，問題不在工程，而在需求。以下是幾個經驗法則：
先寫使用情境，再寫功能清單。 「業務主管每週一早上要看到上週各通路的毛利排行」比「系統需具備毛利報表功能」有用一百倍，因為前者可以驗收，後者可以無限解讀。
明確列出「這次不做」的範圍。 規格書寫「未來可能會做行動 App」是災難的開始——工程師會為了這句話在架構上預留很多東西，結果都用不到。要做就寫進這期，不做就明確排除。
把整合對象的 API 文件先蒐齊。 舉個例子，假設你要串某個電子發票服務，光是它的驗證流程、錯誤重試機制、對帳檔格式，就可能讓開發時程差一大截。這些不是開發商能替你猜的。
驗收條件用資料，不要用感覺。 「速度要快」不是驗收條件，「後台訂單列表在正常負載下要在幾秒內載入」才是。具體的數字由雙方在需求訪談時一起訂，不要留到上線前才吵。
我們的觀察
客製化系統真正的價值，不在「什麼都能做」，而在「你想清楚要做什麼」的那個過程。我們在報價時通常會建議客戶：如果連自己內部都還沒對流程有共識，先不要急著開發，花時間把流程盤清楚，比多買幾個模組划算得多。系統只是把已經想清楚的事情自動化——沒想清楚的部分，寫成程式只會讓混亂跑得更快。