客製化系統開發專案延遲完整指南：6 個延遲根因、4 條合約止血條款、5 個老闆止血決策、3 個換廠商觸發訊號——當外包進度跑不出來該怎麼辦

我們去年接過一個案子——前一家外包做了 8 個月、燒掉 270 萬、交出來的東西連登入都打不開。客戶老闆找上門時手上只有一份「進度 85%」的 Excel，問我們能不能 3 個月救回上線。這種「廠商說快好了、實際上沒救」的場景，過去 18 個月我們在中小企業客戶身上看了 11 次，每一次的劇本都驚人地相似。

客製化系統開發專案延遲不是技術問題，是治理失靈問題。多數老闆延遲到第 3 個月才警覺，這時候沉沒成本已經高到「停損還是繼續」變成情緒題、而不是商業題。本篇把我們處理過的 11 個救火案子歸納成 6 個延遲根因、4 條合約止血條款、5 個止血決策、3 個換廠商觸發訊號——目標是讓你在延遲第 30 天就能判斷下一步，不要拖到第 90 天才崩盤。

為什麼客製化系統開發專案延遲是中小企業數位轉型的高發災區

Standish Group 連續 25 年發佈的《CHAOS Report》顯示，企業軟體專案準時上線率長年維持在 30% 左右、預算超支率平均 27%、功能完成率平均 60%。資料來源見：Standish CHAOS Report 摘要

中小企業的數字通常更難看——我們手上的 11 個救火案子平均延遲 4.2 個月、平均超支 38%、平均完成率落在「廠商說的 85%」對應「實際可上線的 42%」。

中小企業延遲特別嚴重的根本原因有三：第一，採購方沒有專責 PM、老闆兼產品經理但每週只能花 2 小時對接；第二，合約多半用「總價包乾」單一里程碑、付完款後廠商沒有持續交付壓力；第三，需求變更沒有正式 change request 流程、需求一改廠商就用「需求變了所以延後」當免死金牌。這三條合起來，就會把一個「應該 4 個月做完」的案子拖到 8 個月、再從 8 個月拖到放棄。

6 個延遲根因拆解：把廠商「下週就好」翻譯成可決策的訊號

延遲原因表面上看起來百百種——「設計師離職」「客戶又改需求」「測試環境壞了」「第三方 API 出包」——但拆到底就是 6 種類型。我們把這 11 個救火案子的延遲原因歸納分類後，每個根因都對應不同的處理路徑。混在一起處理是無效的。

延遲根因	典型訊號	通常被誤診為	正確處理路徑
技術選型錯誤	改一個功能要重寫 3 個模組、效能怎麼調都跑不快	「工程師能力不足」	停下來重評架構、可能要砍重練
需求未凍結	每週都有新加入的功能、原本 30 個需求變成 67 個	「廠商效率差」	強制凍結需求、新需求進 phase 2
人力不足或抽走	原承諾 3 人團隊變 1.5 人、resource 被廠商挪去新案	「我們的案子優先級低」	合約加 resource lock、單方違約有罰則
第三方系統依賴	金流／物流／簡訊 API 文件不全、串接時才發現	「外部廠商不配合」	需求階段就要把第三方串接列風險清單
驗收標準模糊	「跑得起來」vs「上 production 沒問題」吵不完	「我們在挑剔」	簽合約時就要附 acceptance criteria 文件
專案管理失靈	沒有 Sprint review、沒有 burn-down chart、進度只有口頭	「進度看起來還好」	強制每週交付物 demo、視訊錄影

這張表的關鍵不是「找出是哪個原因」，而是「不要把多個原因綁在一起談」。我們處理過最痛的案子——延遲的真實原因是「需求未凍結」+「人力被抽走」，但廠商每次匯報只談「需求變更」。需求變更那條去談、人力那條也要去談，分開處理才能個別止血。把所有延遲都歸因到「需求變更」是廠商最常用的話術，老闆要學會拆開來看。

ℹ️我們自己跑過的內部專案延遲對照

我們在 2025 年下半年自己內部開發報價單系統（後來變成報價單 CRM 系統服務頁），原本估 2 個月、實際做了 4.5 個月。延遲拆解後發現：技術選型錯了 1 次（從 Next.js Pages Router 換到 App Router、重寫 30% 程式碼）、需求未凍結 1 次（中途加了客戶簽核流程）、第三方依賴 1 次（電子簽章串接卡了 2 週）。我們自己做都會延遲一倍——當廠商說「下週就好、再給一週」時，老闆該預期的是「再多 50-100%」而不是「再多一週」。
這個教訓直接寫進我們現在自己對客戶的承諾規則：給客戶的時程表一律是內部估算的 1.4 倍、合約里程碑用 4-6 個短週期取代「期末交付」、超過里程碑 14 天觸發 weekly steering committee。

4 條合約止血條款：簽約前就要寫進去、延遲時才能有牌可打

延遲已經發生時，能用的牌取決於合約怎麼寫。多數中小企業客戶的軟體外包合約只有 3 種條款：總價、付款里程碑、智慧財產權歸屬——這三條對「廠商延遲」毫無治理力。我們建議發包前就把以下 4 條寫進合約，延遲時這 4 條就是止血武器。

條款 1：每階段交付物的客觀驗收標準（acceptance criteria）

不要寫「完成會員登入功能」，要寫「會員登入功能：支援 email + 密碼、密碼錯誤 3 次鎖定、Google OAuth 串接、登入後跳轉個人頁、登入失敗錯誤訊息中文化、附 5 筆測試帳號可重現」。每個 acceptance criteria 都是可以二元判斷「達成 / 未達成」的句子。寫到這個粒度，廠商交付時你才有客觀依據說「這條沒過、這 30% 款項暫不付」。

條款 2：階段性付款 + 延遲罰款（liquidated damages）

把總價拆成 4-6 個里程碑，每個里程碑對應 acceptance criteria。建議比例：開工 20% / 設計定稿 15% / Alpha 25% / Beta 20% / UAT 通過 15% / 上線 + 30 天穩定 5%。同時加延遲罰款條款：每延遲 1 週、扣當期款項的 2%（上限 30%）。這個罰款不是要罰廠商賺死，是要建立「延遲有實際成本」的訊號——沒有罰款的合約，延遲對廠商來說是免費的。

條款 3：原始碼存放與 Source Code Escrow 觸發條件

合約必須要求廠商每個 sprint 把原始碼推到客戶自己控制的 Git repository（例如 GitHub Org / GitLab self-hosted）、客戶有 admin 權限。同時建議簽 source code escrow（源碼託管）——當廠商發生「延遲超過 60 天」「破產」「失聯超過 14 天」等觸發條件時、託管方釋出最新版本給客戶。我們手上 11 個救火案子裡有 7 個前任廠商「拖延 + 不肯交檔案」，這 7 個如果簽過 escrow 救援成本可以省 40-60%（延伸閱讀建議見既有文）。

條款 4：人力鎖定（key person clause）與抽人罰則

簽合約時要把承諾投入的工程師、PM 姓名 / 經歷寫進合約附件，並加「key person clause」——這幾位被抽走、廠商必須 30 天內補上同等級替代並通知客戶確認、否則違約。許多中小企業案子延遲的真實原因是「廠商接了更大案、把資深工程師抽去新案、留實習生收尾」，沒有人力鎖定條款這件事完全合法、客戶連投訴的依據都沒有。

5 個老闆止血決策：延遲第 30 天 / 60 天 / 90 天該做什麼

延遲到不同階段、可選擇的止血手段完全不同。下面這張表是我們處理 11 個救火案子歸納的決策時間軸——關鍵是「不要等」，每個時間點都有對應該做的事，拖過去之後選項只會越來越少。

延遲階段	老闆該做的事	該避免的事	預期效果
延遲 0-14 天	1. 開 weekly steering / 把延遲列正式議題；2. 廠商要交修正後 timeline + 風險清單	口頭接受「下週就好」、不做書面記錄	讓廠商知道你在認真追蹤
延遲 15-30 天	1. 引入第三方技術顧問做 code / progress audit；2. 啟動 acceptance criteria 逐條檢核	把進度款項先付清「給廠商鼓勵」	拿到客觀進度評估（多半比廠商說的差 30%）
延遲 31-60 天	1. 觸發合約延遲罰款條款；2. 強制 freeze 需求、新需求一律進 phase 2；3. 派客戶自己的 PM 駐點	再追加預算「給廠商加 resource」	把廠商的延遲成本內部化、把需求變更停損
延遲 61-90 天	1. 評估換廠商成本 vs 繼續修成本；2. 觸發 source code escrow 取得原始碼；3. 開啟與 backup 廠商的接洽	繼續無條件付款	為下一階段（換廠商 or 強迫收尾）準備好籌碼
延遲 90+ 天	1. 做出換 / 不換決策；2. 換的話走法律程序止損；3. 不換的話重簽合約 + 新里程碑	繼續用原合約原 timeline 拖	結束「拖」的狀態、進入「決」的狀態

這個時間軸最常見的錯誤是「在 60 天才開始考慮換廠商」——多數案子的合理停損點是 30-45 天就要備好 backup 計畫。等到第 60 天才找下一家廠商評估、再等 2-3 週對方報價、再簽約 30 天才能 onboarding——這中間 3-4 個月原專案已經爛得無法接手。

3 個換廠商觸發訊號：從「考慮」到「決定」的客觀判準

「要不要換廠商」是延遲處理裡最痛的決策。多數老闆會卡在「沉沒成本」「換了會不會更慘」「重新找廠商要 3 個月」這 3 個情緒題，最後拖到不得不換、但已經多燒 6 個月成本。我們建議用以下 3 個客觀訊號來轉成「不換才有風險」的決策。

訊號 1：weekly steering 連續 3 週「同一張延遲清單」

這個訊號最簡單也最強——每週開會時廠商說的「下週要解掉」清單，3 週後還是同一份清單、連順序都沒變。這代表廠商根本沒在解、只是在拖延戰術。這時候不是「再給一週」，是「上 escrow 條款 + 開始找 backup」。

訊號 2：第三方 code audit 報告顯示「進度真實值 < 廠商宣稱值 50%」

這是花錢買到的客觀真相。第三方技術顧問做完 audit 後、如果「廠商宣稱 80%、實際 35%」——這個落差 45% 通常意味著「不重做就無法上線」。這時候繼續讓原廠商做，他們已經沒辦法在合理時程內補上這個落差，換廠商的成本反而比繼續做低。Audit 費用 5-15 萬、能省下 50-200 萬的決策錯誤，絕對划算。

訊號 3：關鍵人力流失 + 廠商拒絕補人

如果合約裡簽了 key person clause、約定的工程師離職或被抽走、廠商在 30 天內沒補上同等級替代——這已經是違約。即使沒簽 key person clause、只要原承諾的 3 人團隊被砍到 1.5 人、廠商說「資源緊張」，這個案子已經沒救——廠商已經把這個案子定位成「邊收尾邊讓客戶自己放棄」的長尾單。這時候不換廠商，是讓客戶損失最大化的選擇。

換廠商的實務操作 SOP：30 天交接、4 條保命動作

一旦決定換廠商、SOP 跟「啟動新專案」完全不同——重點是「把舊系統的可救部分搶救出來、把不可救部分快速重做」。我們協助過的換廠商案子平均用 30 天完成交接、再花 60-90 天把延遲段落補完。下面是 4 條保命動作。

保命動作	30 天內具體要做的事	新廠商要交付什麼	風險與停損點
原始碼 + 文件取得	觸發 escrow / 走法律 letter of demand 要求交付	完整 git history + DB schema + 部署文件	若 7 天內拿不到、走法律程序
第三方系統權限轉移	金流 / 物流 / 簡訊 / 寄信服務的 admin 帳號收回	新廠商接手所有第三方服務	原廠商可能還持有金流分潤、需斷
既有功能盤點 + 砍可救度評估	新廠商做 1-2 週 technical audit	「可救 30% / 重做 70%」的清單	若可救率 < 20%、考慮整個重做
客戶端使用者通知	如果系統已部分上線、要決定停機策略	新廠商出停機 / 平行運作計畫	客戶體驗中斷時間 < 7 天為佳

換廠商最容易被忽略的一條是「第三方系統權限轉移」——金流商、簡訊商、寄信服務常常綁在原廠商的帳號下，原廠商不交、新廠商接不了。我們處理過一個案子是金流綁在原廠商的某員工個人 LINE Pay 商家、那位員工離職後完全聯絡不上、最後客戶花 3 個月重新走藍新金流申請。這條從合約簽約時就該寫——「所有第三方服務必須使用客戶名義開戶、admin 權限歸客戶」。

預防勝於救火：發包前 5 條防延遲檢核清單

如果你還沒發包、本篇真正能幫到你的是這份「發包前防延遲檢核清單」。我們把 11 個救火案子的「如果當初有做到、就不會延遲」反推回去，整理成 5 條發包前必檢項目。

檢核項目	為什麼重要	怎麼判斷廠商是否合格	若廠商不肯做的解讀
要求廠商提供 3 個過去案子的「真實上線時程 vs 原訂時程」對照	看廠商歷史延遲率、低於 30% 才考慮	提供 3 個案子且老闆能匿名訪談	廠商不敢面對自己的延遲歷史
要求合約附 acceptance criteria 範本	驗收有客觀依據、不能扯皮	廠商主動提供 + 願意逐條對齊	廠商習慣靠「跑得起來」交付
要求合約有延遲罰款 + key person clause	建立延遲成本 + 人力穩定性	廠商接受 + 寫進附件	廠商預期會延遲 / 預期會抽人
要求 git repo 是客戶的、廠商是 contributor	原始碼歸客戶、不被廠商綁架	廠商接受	廠商想用原始碼當談判籌碼
要求每週 demo + 錄影歸檔	進度透明 / 不能假進度	廠商接受 + 提供 demo 範例	廠商不敢被持續檢視

這 5 條檢核裡，廠商會拒絕第 3 條（延遲罰款）的比例最高——大約 60% 的廠商會說「我們公司不做這種合約」。這個拒絕本身就是訊號：如果一家廠商連「延遲了罰一點點」都拒絕，他們對自己的時程信心很低、合作之後延遲的機率也高。我們建議直接把這條當「篩廠商」的紅旗，不肯簽就換家評估。

延遲案子救火 / 發包前合約檢視 — 30 分鐘免費諮詢

預約諮詢：/services

⚠️我們怎麼看：延遲處理的時間複利效應

延遲處理最違反直覺的一點是——「再給一週看看」幾乎永遠是錯的決策。我們把 11 個救火案子的時間軸畫出來後發現：在延遲 30 天內介入、平均額外成本是原預算的 20%；延遲 60 天才介入、額外成本變成 50%；延遲 90 天才介入、平均額外成本飆到 110%。「再等等」不是中性選擇，是每週都在燒錢的選擇。
對中小企業老闆來說，這意味著「延遲第 14 天就要開始準備止血、第 30 天就要做出第一個強硬決策」。不是要你立刻換廠商、是要你建立可以強硬的籌碼——audit、escrow、罰款條款、backup 廠商名單——這些籌碼準備好之後，多數時候原廠商會自動加速、根本不用換。怕被換的廠商會自己跑、不怕被換的廠商才需要真的被換。

下載：客製化系統開發專案延遲救火 30 天 SOP（含合約檢核 + 換廠商成本評估表）

我們把這篇文章的 4 條合約止血條款 + 5 個止血決策 + 3 個換廠商觸發訊號做成 18 頁 PDF，裡面附：
1. 發包前合約 18 項檢核 checklist（可勾選列印）
2. 延遲廠商 weekly steering 議程範本（含話術）
3. 第三方 code audit 評估費用 + 廠商推薦清單
4. 換廠商成本對照表（繼續做 vs 換廠商 18 個月 TCO 試算）
請寄信到 contact@foreverwebs.com、主旨「索取延遲救火 SOP」、我們會在 1 個工作天內回信附 PDF。

Q延遲多久才算「真的延遲」？廠商說「軟體本來就會 delay」是不是正常？

業界常見「軟體本來就會 delay」是事實、但 delay 程度有合理範圍。我們的經驗：合理延遲是原時程的 0-20%、值得警覺是 20-50%、危險區間是 50-100%、超過 100% 就是專案治理失靈。所以一個原訂 4 個月的案子、延遲到 5 個月內都可接受、延到 6 個月就要開 weekly steering、延到 8 個月以上就要評估換廠商。

Q已經付了 70% 款項才發現延遲嚴重、還能換廠商嗎？

可以換、但成本會比早換高。重點在於「沒付的 30% 是你最後的籌碼」——這 30% 不要在沒拿到完整原始碼、文件、第三方權限轉移前付出去。如果原合約沒寫延遲罰款，可以用「acceptance criteria 未達成」這條來扣款；如果連 acceptance criteria 都沒寫，剩下的籌碼只有「我們暫不付款並評估法律行動」這個立場——多數時候廠商會妥協配合交接、避免訴訟成本。

Q換廠商之後新廠商會不會推說「前家做得太爛、要全部重做」？

這是常見話術、但要區分「真的不能用」vs「不想接手別人的爛攤子」。我們建議在新廠商評估時要求「先做 2 週 paid technical audit、產出可救率報告」、報告裡每個模組都要列「可救 / 部分可救 / 必須重做」的判斷與理由。如果新廠商說「全部重做」、要他們白紙黑字寫出來——多數時候真實的可救率落在 30-60% 之間、新廠商會傾向高估重做比例（因為更好賺）。Audit 報告要的就是壓回客觀數字。

Q我們公司沒有 IT / 沒有 PM、怎麼跟廠商開 weekly steering？

中小企業沒有專責 PM 是常態。我們的建議是：(1) 老闆自己花每週 1 小時開 steering、議程固定 3 題（上週承諾 vs 實際 / 本週承諾 / 風險清單）；(2) 如果連 1 小時都擠不出來，外包一個 fractional PM（接案型 PM、月費 3-8 萬）；(3) 不要把 steering 委任給「不懂技術的行政助理」、容易被廠商話術帶過。記得 steering 不是要懂技術、是要逼廠商把「下週就好」翻譯成可驗證的具體任務。

Q如果原廠商失聯、原始碼也拿不到，最壞情況需要多久才能重做？

我們處理過最痛的一個案子是原廠商收完款 14 個月後 LINE 已讀不回、原始碼一行都沒拿到。新廠商從零開始用 AI 輔助開發 + 客戶側完整需求文件、5 個月完成功能等效的新系統、總成本是原本的 1.4 倍。所以最壞情況預估：時間 = 原預估時程 × 1.2-1.5 倍、成本 = 原預算 × 1.3-1.8 倍。這個數字也是「換廠商成本對照表」的基準——如果繼續修原系統的預估成本超過這個數字、直接重做反而省。

延伸閱讀

關於合約治理與發包前準備：（軟體 RFP 怎麼寫？老闆版需求書範本與 30 條必備欄位 checklist）（老闆找外包前必備的客製化系統需求書（BRD）完整寫法）

關於源碼託管與廠商鎖定：（客製化系統「源碼託管」(Source Code Escrow) 完整指南）（軟體外包驗收後的維運合約怎麼簽？3 種模式對比、12 條必看條款與換廠商決策樹）

關於 SaaS vs 客製化的決策框架：（SaaS vs 客製化系統：中小企業到底該選哪一個？完整比較與決策框架）（中小企業客製化系統『資料遷移』完整指南）