套裝軟體最貴的成本，往往不是授權費，而是你為了配合它而扭曲的營運流程。
這句話在導入前三個月不會發生，但到了第二年、第三年，當業務規則越長越多、報表要拉的維度越拉越怪，你會發現整個組織花在「繞過系統限制」上的時間，早就超過當初省下的開發費。這不是套裝軟體不好，而是很多人一開始沒問對問題：這套流程是我的核心競爭力，還是可以標準化的後勤？
什麼時候該選客製化
判斷標準其實不複雜，可以從三個角度切入：
第一，流程本身是不是差異化來源。 假設你經營一家做代工外銷的中小型工廠，訂單走的是「客戶指定料號 + 內部替代料號 + 出口報關碼」三層對應，這種邏輯在任何 ERP 都不會原生支援。硬套進套裝軟體，只會逼員工開一堆 Excel 在系統外做二次加工。
第二，資料要不要跨系統流動。 電商後台、POS、金流、物流、會計，每一段都有現成方案，但接縫處往往才是問題。當你需要即時把線下庫存回寫到線上、又要處理退貨對帳，中間的整合層通常沒有現成產品，得自己寫。
第三，變動頻率有多高。 套裝軟體適合規則穩定的場景。如果你的商業模式還在演化，例如常常推新的促銷組合、新的分潤方式，那麼把邏輯鎖在別人家的產品裡，改一次動一次都要等原廠。
這三題如果有兩題答「是」，客製化的長期報酬率通常會勝過套裝。
規格書要寫的，不是功能清單
這是我們在報價階段最常提醒客戶的一件事：規格書不是「我要一個購物車、我要一個會員系統」，那種寫法工程師接到只能自由發揮，交付後雙方一定吵架。
真正該寫進規格書的，是業務規則與例外處理。舉個例子，「會員下單」聽起來很簡單，但背後可能牽涉：
- 未驗證 email 的會員能不能結帳？
- 購物車放了 30 天的商品，價格用哪一版？
- 同一張訂單裡混合了預購商品和現貨，出貨怎麼拆？
- 折價券用了之後退貨，券要不要退回？
這些問題如果規格書沒寫，開發時工程師會憑常識做決定，而工程師的常識跟你的業務直覺不一定一樣。我們的經驗法則是：規格書裡至少要有三成篇幅在寫「當 X 發生時，系統應該 Y」的條件式，剩下才是畫面與欄位。
另外一個常見地雷，是把「未來可能會做」的功能也塞進第一期。這會讓報價膨脹、時程延長，而且那些功能通常上線後也用不到。比較健康的做法，是把系統切成「這期一定要」「觀察後再決定」兩層，先上線、再迭代。
我們的觀察
客製化系統會不會踩雷，八成在合約簽之前就決定了。決策者願不願意花時間把業務規則講清楚、願不願意接受「先做少一點、上線後再擴充」的節奏，這兩件事比選哪個技術棧、找哪家廠商都更關鍵。技術問題有解，需求模糊沒解。