套裝軟體填不滿的那 20%，才是關鍵

套裝軟體不是不好，是它假設你和別人一樣。 當你的業態剛好落在它預設的流程裡，套裝軟體會是最划算的選擇；但如果你的營運差異就是你的護城河，那把流程硬凹進套裝軟體，等於親手把差異化磨平。

判斷客製化與否，我們的經驗法則是問三個問題：這個流程是不是你賺錢的關鍵？調整它的頻率有多高？供應商願不願意為你動核心？三題有兩題答「是」，就該認真考慮客製。

需求釐清，比寫程式更難

多數客製化專案翻車，不是輸在技術，是輸在一開始沒把需求講清楚。常見的坑有幾種：

• 只描述介面，不描述行為：客戶說「我要一個訂單列表」，但沒說搜尋條件優先序、匯出時要不要含未結案、跨月統計怎麼算。
• 把例外當小事：主流程只佔工時的一半，退貨、換貨、部分出貨、跨幣別這些例外邏輯才是真正吃預算的地方。
• 假設對方懂你的行話：傳產說的「單」可能是報價單、訂購單、出貨單、對帳單四種東西的統稱，工程師若沒追問，寫出來的資料模型就會歪。

釐清需求時，我們通常會建議客戶做兩件事。第一，把「一天的工作流」從早到晚描述一遍，包含誰在什麼時間點做什麼事、用什麼工具、資料從哪來到哪去。第二，把「上個月最麻煩的三個例外」拿出來當測試案例。這比抽象討論「我要什麼功能」有用得多。

規格書要寫到什麼程度

規格書不是為了保護誰、告誰，是為了讓雙方對「完成」有一致定義。以下是幾個實務建議：

1. 每個功能都要有驗收條件：不是「能新增訂單」，而是「當使用者填完必填欄位並按送出，系統應該回傳訂單編號，且在後台列表 5 秒內出現」。
2. 資料規則寫在規格裡，不要藏在程式：什麼欄位必填、什麼情境下唯一、金額精度到幾位，這些都是規格層級的事。
3. 明確標示未涵蓋範圍：講清楚「這個版本不做什麼」，比列出「做什麼」更能避免爭議。
4. 介面圖與流程圖分開：介面會改，流程動不了。把兩者混在一起，任何一邊變動都會牽連。

舉個例子，假設一家做進口食品的中盤商要客製進銷存，如果規格書只寫「支援多倉」，那到底是每張出貨單只能綁一個倉、還是可以跨倉出貨、跨倉出貨時毛利怎麼算，都是後續吵架的火種。這種細節在規格階段花一小時討論，比上線後花好幾天補救便宜太多。

幾個常見地雷

• 報價階段就要求鎖死總價，卻不願意花時間做需求訪談：這種案子註定會在中後期爆炸，因為未知數會被吸收到「後續變更」裡。
• 老闆一句話，全部重做：專案要有明確的變更管理機制，否則規格書寫得再細都沒用。
• 上線就是專案結束：客製化系統的價值在持續演進，選供應商時要看的是後續維運能力，不是初次開發報價。

我們的觀察

客製化不是「比較貴的套裝軟體」，而是一種對業務理解的投資。真正省錢的做法，是在需求階段就把時間花夠、把例外流程攤開來談。規格書寫得好，程式反而是最輕鬆的部分；規格書含糊，再強的團隊也只能一路救火。願意在前期慢下來的專案，後期通常都會快起來。