中小企業客製化系統「上線後 90 天驗證」完整指南：4 階段穩定 SOP、6 個 KPI 對賭、5 條合約微調訊號——老闆撐過 production 第一季的決策手冊

我們最近在一個中型製造業客戶的 ERP 上線後案子裡，親眼看到一件事：驗收書簽了、尾款也收了，但上線後第 14 天，財務部門打電話來說「訂單狀態怎麼一直跑錯」。查下去才發現，UAT 階段只測了主流程，一個邊緣條件在真實訂單量衝上來後才顯形。沒有人的錯——但這件事告訴我們，合約上的「驗收完成」跟系統真正穩定，中間有一段距離，那段距離就是 production 第一季。

這篇文章寫給剛簽完約、正準備上線，或剛過驗收、進入 production 第一個月的中小企業老闆。我們把它拆成四個階段——上線前 72 小時、第 1-30 天、第 31-60 天、第 61-90 天——搭配六個可以對賭的 KPI 指標，以及五條讓你在最短時間判斷「現在要不要調整合約」的訊號。這不是理論框架，是我們在 30+ 企業客製案落地後，歸納出來的實際操作節奏。

為什麼「上線後 90 天」是真正的關鍵驗收

Standish Group 的 CHAOS Report 長期追蹤企業 IT 專案，數據指向一個令人不舒服的事實：軟體交付後 3 個月內，發現的缺陷佔整個生命週期所有缺陷的 60% 以上。這不是因為廠商不認真，而是因為 UAT 的測試量永遠小於真實業務量。

我們的看法是：真正的關鍵驗收不在合約上的「簽收驗收書」那一刻，而是在 production 第 90 天。那一天之前，系統一直在用實際業務壓力測試自己——而你的角色，是在這段期間保持監控、快速反應，並且清楚知道「什麼狀況算正常磨合、什麼狀況需要調整合約」。

四階段穩定 SOP：從上線前 72 小時到第 90 天

Production 第一季的節奏不是線性的。壓力最大的不是第 30 天，而是上線後的頭三天，以及第一次業務高峰（月底結帳、季度盤點、促銷活動）。以下四個階段，每個階段有各自的核心任務。

上線前 72 小時：回滾計畫先於一切

上線那一天，最重要的文件不是操作手冊，而是回滾計畫（Rollback Plan）。你需要確認三件事：資料備份的最後一個 checkpoint 在哪裡、如果 production 出問題 24 小時內可以回到哪個狀態、業務流程的臨時應急方案是什麼（例如：系統停擺期間訂單怎麼記？）。沒有回滾計畫就上線，等於拿公司營運賭博。

這個階段要特別確認的還有：正式環境的 server 規格是否真的跟 staging 一致？第三方 API 的正式授權是否到位？SSL 憑證、DNS 切換時間是否確認？這些通常在 checklist 裡，但真正的問題往往出在「確認了但沒有測試」。

第 1-30 天：穩定優先、紀錄一切

上線後第一個月，你的任務是把所有異常都記錄下來，而不是馬上要求修改。區分兩種狀況：「使用者不習慣」（使用者教育問題）vs「系統邏輯有誤」（開發問題）。混淆這兩種，會讓廠商疲於奔命、也會讓你自己搞不清楚問題的根源。

這個階段建議用一個共享的 issue tracker（Google Sheet 或 Notion 都行），每天記錄：發生什麼、哪個功能、影響多少人、是否阻塞業務。30 天後你手邊會有一份比任何技術報告都有說服力的「問題清單」，這是後續合約重談的原始依據。

第 31-60 天：從穩定走向優化，KPI 開始有意義

如果前 30 天沒有出現阻塞業務的嚴重問題，第 31 天開始你可以轉換心態：從「監控異常」轉到「追蹤效率」。這個階段 KPI 才開始有真正的比較基礎——因為使用者已度過學習曲線，系統在標準操作下的表現才是真實的基準線。

這個階段也是發現「未明需求」的黃金窗口。真實業務跑起來之後，使用者會開始說「如果這個功能可以這樣就好了」——這些需求當中，有些是真的值得追加開發（因為它影響核心業務），有些則是「習慣改變」就能解決的偽需求。第 31-60 天的任務是把這兩類分清楚，並且評估追加開發的 ROI。

第 61-90 天：決策窗口——合約結構是否需要調整

第三個月是一個決策節點。到這個時間點，你手邊有 60 天以上的真實數據、一份問題清單、以及一份已優化的 KPI 報告。現在可以做三個判斷：系統是否達到你當初的業務目標、廠商的 SLA 回應是否符合合約約定、以及未來的維運模式（維護合約、T&M 追加、或切換廠商）應該選哪一條路。

關於維運合約的選擇，可以參考我們另一篇深入分析：軟體維運合約模式與條款指南——裡面有各種維護合約結構的優缺對比，適合在這個時間點用來做決策。

六個可以對賭的 KPI：讓驗收標準說話

「KPI 對賭」的意思是：在合約或驗收文件裡，把這六個數字寫清楚——多少是合格線、多少是要觸發合約調整的警戒線。這不是為了挑廠商毛病，而是讓雙方都有清楚的共同語言。

Gartner 的企業應用軟體研究顯示，有明確量化 KPI 的系統導入專案，上線後 6 個月內的使用者滿意度比沒有設定 KPI 的高出 34%。這個差距的原因很直接：有了明確指標，廠商和客戶都知道努力的方向。

這六個 KPI 不是孤立的——它們有因果關係。如果「核心流程完成率」偏低，八成是「回應時間」或「資料正確率」有問題。先從這兩個源頭查起，比逐一排查省得多。更詳細的 KPI 量測方法，可以參考：AI Agent 評估方法論：6 個 KPI 對賭框架——雖然那篇以 AI Agent 為主，但 KPI 設計邏輯完全通用於一般客製化系統。

五條合約微調訊號：什麼時候該重談合約

很多中小企業老闆在系統上線後，即使遇到問題也不確定「這到底要不要去跟廠商談」。以下五條訊號，是我們從系統開發案例中歸納出來的警戒線——任何一條連續出現超過兩週，就值得正式提出合約層面的討論。

• 訊號一：P1 問題修復超過 SLA 約定時間 2 次以上（連續 2 週），且廠商未主動說明延遲原因

• 訊號二：同一個 bug 修了又出現 3 次以上（「幽靈 bug」現象），代表修復方式是 workaround 而非根治

• 訊號三：使用者採用率在第 60 天仍低於 50%，且原因指向系統設計而非使用者培訓不足

• 訊號四：第 1-30 天 issue log 超過 30 筆 P2 以上問題，且集中在同一個功能模組

• 訊號五：廠商回應窗口固定在「下個版本再處理」，但沒有明確的版本發布時間表

合約微調的範圍因問題類型而不同：如果是 SLA 未達標，可以要求廠商提供服務信用額度（Service Credit）或延長免費維護期；如果是需求範圍跑掉，需要重新確認 Change Order 的流程。需求變更這塊特別容易引發糾紛，建議先讀：客製軟體需求變更 3 段流程與 5 條合約紅線——了解哪些是正常的範圍蔓延、哪些是合約紅線。

使用者採用率：最容易被忽略的那個 KPI

在六個 KPI 裡，「使用者採用率」是最常被老闆忽略的一個——因為它看起來比較「軟」，而且責任歸屬不清楚（是廠商的系統設計問題？還是公司的培訓問題？）。

IDC 的企業軟體調查指出，中小企業客製化系統上線後 90 天，平均使用者採用率只有 62%——剩下 38% 的人要嘛還在用舊方法（Excel、Line 群組），要嘛只用了部分功能。這個數字很關鍵，因為系統的業務價值是建立在「所有應該用的人都在用」的前提上。

低採用率的根本原因通常有三個：系統流程跟現有業務習慣差距太大（設計問題）、培訓不足（執行問題）、或是少數關鍵使用者抗拒（組織問題）。確認是哪一個，決策路徑完全不同。如果是設計問題，要跟廠商談 UX 調整；如果是培訓問題，是你自己公司要處理的；如果是組織問題，換再好的系統也沒用。

Production 第一季最容易踩的三個坑

不管系統做得多好，production 第一季都會有意料之外的問題。以下三個坑，是我們在系統開發案例裡最常看到的，也是最容易讓老闆和廠商關係變緊張的地方。

坑一：環境差異在上線後才發現

開發環境、測試環境、production 環境三者的設定差異，是導致「測試沒問題但上線壞掉」的最常見原因。常見的差異點包括：資料庫版本不同、快取機制設定不同、第三方 API 的 rate limit 在正式環境更嚴格，以及檔案系統的權限設定。

這個坑的預防方法是在驗收 SOP 裡明確要求廠商提供「環境一致性確認清單」。詳細的 8 個驗收檢查項目，可以參考我們這篇：客製化系統驗收 SOP：8 個檢查項目與 3 條合約紅線。

坑二：資料遷移後的靜默錯誤

資料遷移是另一個高風險點。很多老闆在系統上線後一週才發現「歷史訂單裡有幾筆資料跑錯了」——這類問題通常不是遷移腳本完全錯誤，而是邊緣格式（特殊字元、空值、舊系統的自訂欄位）在遷移時被靜默跳過或轉換錯誤。

資料遷移的 5 個階段與成本陷阱，在這篇有完整的分析：中小企業客製系統資料遷移：5 階段 4 策略 3 成本陷阱——特別是「驗證」階段，很多廠商在時程壓力下會簡化，建議老闆主動要求提供驗證 SQL 結果。

坑三：第一個業務高峰前沒有壓測

如果你的業務有週期性高峰（月底結帳、季度盤點、雙十一），那個高峰才是系統真正的壓力測試。在高峰到來之前，務必要求廠商跑一次壓力測試（Load Test），確認系統在 2-3 倍正常並發量下的回應時間和錯誤率。如果廠商說「UAT 都過了應該沒問題」——這是一個需要追問的時刻。

合約裡應該早就寫進去的條款——90 天視角回看

如果你現在正在規劃第一個客製化系統，或者正在和廠商討論下一期合約，這些條款在簽約時就該要求進去，而不是等到 production 出問題才來補。

以下條款清單，是從「90 天驗證」的角度往回看，最容易在第一季讓雙方起摩擦的地方：

• Production 第一季的 SLA 明確定義：P1/P2/P3 的定義、回應時間、修復時間，以及 SLA 未達標的補償機制（不能只寫「盡力服務」）

• Bug 修復 vs 需求變更的邊界：哪些算廠商應修的 bug、哪些算追加需求、Change Order 的流程和費用怎麼計算

• 資料備份與回滾責任：備份頻率、保存週期、回滾時間目標（RTO）和恢復點目標（RPO）由誰負責執行

• 使用者培訓的範圍和次數：合約裡只有「上線後培訓一次」往往不夠，第 30 天 follow-up 培訓應該是標準配備

• 第三方服務的費用與責任歸屬：如果系統依賴第三方 API（金流、簡訊、地圖），那些費用誰出、如果第三方服務中斷由誰承擔 SLA

如果你的系統是用 AI 驅動的某個功能（例如自動分類、預測模型），在採購階段的合約防線設計有更多細節需要考慮，可以參考：中小企業 AI 採購 3 道防線：POC 合約退出機制與 KPI 對賭。

第 90 天的分岔口：三條路各自的代價

90 天到了，你應該面對一個清醒的選擇。不是「繼續走下去」這種模糊答案，而是三條路中選一條：

• 繼續合作（維護合約 or T&M）：系統已穩定、廠商回應良好、未來需求持續存在 → 簽一個長期維護合約，約定未來的優先權和費率

• 功能封存（進入低維護模式）：系統核心功能穩定、近期沒有大規模新需求 → 只簽一個「緊急修復」等級的低成本維護合約，等需求具體再重啟

• 廠商切換評估：如果前 90 天的問題清單顯示廠商能力或態度有明顯問題，這是切換成本最低的時機（有完整問題紀錄、系統文件還算新）

切換廠商這件事，比很多老闆想的複雜，尤其是如果系統文件不完整的情況。如果你在考慮這個選項，可以先讀：AI 採購 60 天治理框架：POC 退出機制與廠商切換——裡面的評估框架對一般客製化系統同樣適用。

成本控制這塊，也需要有清楚的觀念。系統上線後的 TCO（總持有成本）往往比老闆預期的高，尤其是如果系統依賴 AI 功能的話：AI Agent 6 個月成本飆 3 倍的真相：Token 架構與監控隱藏帳單。

如果你正在規劃第一個客製化系統，或者已經上線但對 90 天驗證的節奏還不清楚，我們提供客製化網站與系統開發諮詢——可以把你的系統現況丟過來，我們陪你一起看哪些地方需要特別留意。也歡迎參考我們的AI 顧問服務，如果你的系統裡有 AI 功能整合的計畫。

延伸閱讀：如果你的系統在上線過程中涉及大量歷史資料遷移，建議搭配這篇一起看——中小企業客製系統資料遷移 5 階段完整指南，了解遷移階段最常見的成本陷阱和紅線。

Production 第一季從來不是廠商單方面的責任，也不是你單方面可以搞定的事。它需要雙方有清楚的 KPI 定義、有紀錄問題的工具、有明確的升級路徑，以及有一份合約在兩造之間提供共同的遊戲規則。這份手冊的目的，就是把這些東西提前想清楚。