客製化系統開發交付驗收完整 SOP：8 個檢查項目、4 階段驗收節奏、3 條合約紅線、撞牆跳廠商指南

最近我們在處理一家客戶的客製化系統「接手案」時看到一個典型場景——他們 18 個月前發包給某家系統開發商做 ERP 客製化，前期需求書（BRD）寫得很細、報價也合理、開發中期 demo 過 3 次都看起來 OK，但到交付驗收這段開始出狀況：先是廠商主管失聯 2 週、接著 UAT 測試版本一直延、再接著合約定義不清的「上線後 3 個月免費維護」變成「我們再收一筆 80 萬」。客戶找我們時，已經是上線後 4 個月、系統跑得歪斜、code 拿不回來、廠商拒接電話的狀態。

這不是少數案例。我們在系統開發諮詢經驗中看到，客製化專案出問題的 60-70% 都集中在「合約簽完之後到上線前後 3 個月」這段時間——這正是 經濟部商業司商工登記查詢 看不到的「過程品質」段，也是中小企業老闆最常掉進去的灰色地帶。我們把過去 30+ 個客製化系統諮詢案的經驗整理成這篇——8 個交付驗收必查檢查項目、4 階段驗收節奏、3 條合約紅線、撞牆時跳廠商的具體 SOP。

這篇是 BRD 範本指南 #653 的後段配對文——前段教你怎麼寫需求書、找廠商；這篇教你「簽完之後怎麼把系統真的接回來」。

客製化系統開發 60-70% 出狀況都集中在這個階段

如果把客製化系統開發拆成 5 段——需求釐清、架構設計、開發、UAT 驗收、上線後維運——出狀況的機率分布非常不平均。前 3 段（需求 / 設計 / 開發）平均出問題率合計約 20-30%，但「UAT 驗收 + 上線後 3 個月」這 2 段合計出問題率達到 60-70%。原因有 5 個。

• 需求書（BRD）寫得再清楚，到實作階段都會有 20-30% 細節未定義——交付時雙方解讀不同
• 廠商在交付前的「最後一公里」承壓最大，工程師離職、轉案、加班成本都集中在這時期
• 中小企業客戶常缺乏專業 UAT 測試流程，驗收只看「能不能登入、能不能存檔」就放行
• 合約對「上線後維護期」的定義通常很模糊（90 天？180 天？bug 修補範圍？回應時間？）
• source code、資料庫、營運密碼的交付沒寫進合約 milestone，廠商有意無意「下次再給」

我們在過去客製化系統開發諮詢的真實案例中看到，這 5 個原因加起來造成的後果是——「上線後 6 個月內想換廠商」的客戶比例高達 35%，但實際能換的不到 10%（其他 25% 因為 code 拿不回來、文件不全、密碼缺失被綁住）。 勞動部薪資調查資料 顯示資深系統工程師的平均轉職週期約 18-24 個月——這代表開發中後期廠商工程師流動率高，交付期人員斷層是常態，不是意外。

我們的看法是——交付驗收這段的問題 90% 不是廠商惡意，是「合約沒寫清楚 + 客戶沒測仔細」兩邊都偷懶。重點不是抓壞人，是把流程做對、文件寫齊、節奏抓準。

8 個交付驗收必查檢查項目（每一項都要寫進合約 milestone）

這 8 項是我們在客製化系統開發諮詢中整理出的「最低安全網」，缺任何一項都會在 6-12 個月內反咬你。

4 階段驗收節奏：把驗收切段、不要一次驗

中小企業老闆最常踩的雷是「最後 1 次驗收全部一起驗」——廠商說「都做完了你來驗」，客戶花 2 週測試，發現 20 個問題、20 個都是基礎錯誤，整個專案延期 2-3 個月。正確做法是把驗收切成 4 階段、每階段都有書面交付物。

這 4 階段的關鍵不是「驗收動作多」，是「每階段都有退場機制」——前 3 個階段任何一個出狀況，你都可以選擇暫停付款 / 協商修改 / 換廠商，而不是被綁在「已經付了 80% 不能停損」的死巷裡。

3 條合約必寫紅線（簽合約前一定要加進去）

這 3 條我們看過太多客戶因為簽合約時沒加進去、後來付出 2-3 倍代價才能解套。任何一份客製化系統開發合約，沒這 3 條都不要簽。

紅線 1：Source code 與帳號歸屬條款

合約必寫：「本系統所有 source code、設計文件、資料庫 schema、API 規格、第三方服務帳號、營運密碼，自交付日起 100% 歸屬甲方（客戶），乙方（廠商）不得保留任何 owner 權限。」這條看起來理所當然，但我們看過 60% 的中小企業合約都沒寫清楚——「擁有」跟「能拿到」是兩件事，「現在拿到」跟「未來不能要回去」更是兩件事。

紅線 2：分階段付款與退場條款

合約必寫：「付款比例分為 30% 簽約金 / 30% 階段 2 完成 / 30% 階段 3 通過 / 10% 上線後 30 天驗收完成。任一階段未通過驗收，甲方有權暫停付款並啟動 30 天協商期，協商不成可終止合約，乙方需返還已交付物之相應比例。」這條把「廠商失聯怎麼辦」「驗收不過怎麼辦」一次寫進去。

紅線 3：上線後維護期書面化

合約必寫：「上線後 90 天為免費維護期，期間內 P0（系統不能用）24 小時內回應、P1（核心功能異常）3 工作天內修復、P2（次要問題）2 週內修復、P3（優化建議）不在維護期保證範圍。維護期結束後若雙方持續合作，年度維護費為合約金額之 12-18%。」沒寫這條，「上線後 3 個月免費維護」會變成「我們再收一筆」。

撞牆怎麼辦：4 條跳廠商 SOP

如果上述前置工作沒做齊、現在已經卡在「合約簽了、付了 60-80%、廠商失聯或交付不齊」的處境，這節給 4 條跳廠商 SOP。

SOP 1：先寄存證信函、不要先翻臉

第一步永遠是書面、不要打電話。直接寄存證信函（透過郵局），列出（1）已付款項與比例（2）合約 milestone 對應交付項目（3）已交付與未交付清單（4）給對方 14 天書面回覆期。這份存證信函在後續法律程序中是關鍵證據。

SOP 2：14 天內找 2-3 家「接手評估」廠商

不要等廠商回應、平行進行。找 2-3 家中立評估廠商（含我們）做「接手可行性評估」——把現有 source code、文件、資料庫給他們看 1 小時，問三個問題：（1）這個 code 接得起來嗎？（2）接手成本估多少？（3）如果重寫成本估多少？這份評估會決定你要花錢買回現狀、還是停損重來。

SOP 3：談判桌上分清楚「找回 source code」與「繼續開發」

跟原廠商談判時，把目標明確分成兩件事——（1）拿回 source code、文件、資料庫、密碼（這是無條件的，跟「繼續不繼續開發」無關）（2）剩餘工程是否繼續由他們做（這是可談的）。中小企業老闆最常犯的錯是把這兩件綁在一起談，最後兩件都拿不到。

SOP 4：如果走到法律程序，準備這 3 份文件

• 原合約全文 + 所有附件 + 變更同意書
• 全部 milestone 對應交付物清單（已交付 / 部分交付 / 未交付）+ 時間軸
• 雙方所有書面 / Email / Slack / Line 紀錄（截圖存檔、不要只靠平台）

通常走到這一步前，多數案例會在存證信函 + 接手評估的階段就解決——廠商看到客戶有備選方案，談判態度會明顯改變。 TIPO 智慧財產局對軟體 source code 著作權的說明 也明文支援客戶的 source code 歸屬權主張，這條法律基礎在台灣是清楚的。

結語：把「合約簽完」當起點、不是終點

客製化系統開發出狀況的 60-70% 集中在交付驗收這段，根本原因是中小企業老闆把「簽合約」當成「事情搞定」——其實簽合約只是工程開始，真正的考驗在 8 項檢查、4 階段驗收、3 條紅線能不能落地。這篇的清單不是要你學會所有技術細節，是要你在下一個專案開始前——拿這份清單去問廠商：「這 8 項你願意寫進 milestone 嗎？」廠商怎麼回答，比他們的提案漂亮 10 倍重要。

如果你目前正在客製化系統的撞牆狀態、或想在下個專案開始前先把驗收 SOP 設計好，跟我們聊聊——我們可以從 1 小時免費「驗收可行性評估」開始，幫你把合約紅線跟交付清單對到實際專案規模。