套裝軟體最大的成本不是授權費，是繞著它改業務流程的那幾年。如果你的業態跟主流市場長得不太一樣——例如報價邏輯是業務憑經驗喊、出貨單要對接三家不同貨運的格式、或客戶要求每張發票備註欄都得帶批號——那套裝軟體省下來的開發費，往往會在「人工補洞」這件事上慢慢還回去。
但這不代表所有東西都該客製。判斷標準很簡單：這個流程是不是你的競爭力？ 如果是，客製化能讓你把 know-how 沉澱進系統；如果只是會計、HR、文件管理這類後勤，買成熟工具通常划算得多。
需求釐清比寫程式還難
大多數失敗的客製案不是死在技術，是死在「需求其實沒講清楚」。客戶說「我要一個訂單系統」，但訂單系統可以從一張 Google 表單長到一個 ERP，中間差的是兩個數量級的成本。
我們在報價時通常會建議客戶，先回答三個問題，再談功能：
- 誰會用？用的人技術熟悉度如何？ 給倉管阿姨用的介面跟給 RD 用的，設計成本差很多。
- 這個系統壞掉一天，業務會停擺嗎？ 答案會直接影響架構、備援、測試的投入規格。
- 未來兩年，業務量大致會怎麼變？ 不需要精確預測，但要知道是「穩定」、「會翻倍」還是「不確定」。
這三題答不出來就先別急著畫流程圖。舉個例子，假設一家做工業零件的中小企業想做線上報價系統，乍聽很單純；但如果報價要參考即時匯率、客戶分級、料件庫存與業務手動折讓，那它其實是四個子系統。在動工前釐清這件事，跟動工三個月後才發現，成本完全不同。
規格書要寫到什麼程度
規格書的目的不是把每個按鈕都畫出來，而是讓雙方對「做完長什麼樣」有一致的理解。實務上至少要涵蓋：
- 使用者角色與權限矩陣：誰可以看、誰可以改、誰可以刪。
- 核心流程的 happy path 與例外路徑：正常下單怎麼走，付款失敗、庫存不足、客戶取消又該怎麼走。例外路徑常常比主流程多。
- 資料介接的格式與頻率：跟金流、物流、ERP、會計系統的串接點，要寫到欄位等級。
- 驗收標準：什麼條件達成才算「做完」。
常見地雷有幾個。第一個是「先做再說，邊做邊改」——彈性聽起來很美好，但沒有基準線的專案，最後通常會吵架。第二個是把 UI 畫面當規格——畫面只是表象，背後的狀態機跟資料流才是真正要對齊的東西。第三個是忽略資料遷移——舊系統的歷史資料怎麼搬、髒資料怎麼清，這部分被低估的比例極高。
還有一個容易被忽略的：離場條件。系統交付後，原始碼歸誰、文件在哪、未來換廠商要怎麼接手。這些寫進合約，比事後吵架便宜太多。
我們的觀察
客製化系統真正的價值，不在於它「功能多」，而在於它能不能跟你的業務一起長大。願意在需求釐清階段慢下來的客戶，後面通常走得比較快；急著看到畫面、跳過討論的，多半會在驗收前回頭重做。技術從來不是瓶頸，對齊認知才是。