系統上線了、廠商就不理人？一份寫給老闆的維護預算與 SLA 實戰指南
上線後的第一通電話,為什麼沒人接？
系統做好了、驗收過了、廠商也拿到尾款,接下來應該就能安心用了吧？很多老闆是這樣想的,直到系統第一次出問題。
您打電話給開發商,對方說「現在沒維護合約,這次先幫您看,但要另外報價」。改個小功能,報價兩萬;修個 bug,又是一筆錢。每次都要重新談價、重新等排程,原本以為「做完就是您的」的系統,突然變成「每次動都要再付錢」的無底洞。
這不是廠商耍賴,而是您在上線前少談了一件事:維護合約與 SLA 條款。當系統開始為公司運作,維護不是可有可無的售後服務——它是您能不能「持續用下去」的生命線。
第一年維護預算怎麼抓？業界數字與台灣實務
<cite index="2-2">軟體維護成本通常是原始開發費用的 15% 至 25%,這是業界一致的基準數字</cite>。如果您的系統當初花了 50 萬開發,<cite index="2-4">第一年的維護預算大約落在 7.5 萬到 12.5 萬之間</cite>。
這筆錢涵蓋什麼？<cite index="4-15">包括 bug 修復、資安更新、效能改善、相容性更新,以及小幅度的功能調整</cite>。請注意:這還不包括「新功能開發」或雲端主機費用,那些是另外的預算項目。
實務上,台灣中小企業常見三種維護計價方式:
- 固定月費制:每月固定支付,廠商在約定範圍內提供維護服務,適合需要穩定支援的系統
- 按需計時制:每次修改按工時收費,適合使用頻率低、改動不多的系統
- 預付時數包:一次買斷若干小時,用完再加購,介於前兩者之間
建議您在上線前就談好維護合約,並把第一年預算編進系統總成本。<cite index="6-4">初期開發成本較低但維護成本高達 40% 的系統,長期下來比品質較好、維護成本僅 15% 的系統更貴</cite>。
SLA 條款裡真正重要的三項指標
SLA(Service Level Agreement,服務水準協議)不是「有寫就好」的合約附件,它定義了廠商承諾的服務水準,以及沒做到時您能主張的補償機制。
真正重要的是這三項:
1. 回應時間(Response Time)
<cite index="13-1,13-2">SLA 指標定義了廠商承諾的可量化項目,例如系統可用率百分比、回應時間與問題解決時限</cite>。這不是「有空再回」,而是「接到通知後多久內必須回覆」。
實務上建議區分嚴重程度:
- P1(系統停擺):15 分鐘內回應
- P2(重要功能異常):2 小時內回應
- P3(一般問題):8 小時內回應
2. 解決時間(Resolution Time)
回應不等於解決。<cite index="16-2">回應時間與解決時間是兩項不同的績效指標</cite>。合約應明訂「多久內必須修復」,而不是「盡快處理」這種模糊承諾。
3. 系統可用率(Uptime)
<cite index="12-13">服務可用率是服務供應商能提供服務的時間百分比</cite>。如果您的系統是電商網站或客服平台,停機一小時就是營收損失。合約應寫明「保證 99.5% 可用率」或其他具體數字,並約定未達標時的補償方式(例如退費或服務時數補償)。
記得:SLA 不只是廠商的承諾,也是您日後主張權利的依據。如果合約寫得太模糊,出問題時根本無從追究。
沒有維護合約時,出問題該怎麼辦？
如果系統已經上線、但當初沒簽維護合約,現在出問題了該怎麼辦？這是許多接手「做到一半專案」的老闆會遇到的真實處境。
以下是實際可行的處理流程:
第一步:聯繫原開發商,詢問能否簽訂維護合約
即使當初沒談,現在補簽還來得及。對方可能會要求「重新熟悉系統」的費用,這是合理的——前提是對方願意接手。
第二步:如果原廠商不接,準備完整的交接文件
包括原始碼、資料庫結構、API 文件、帳號密碼清單等。如果這些都拿不到,後續接手難度會大幅提高。
第三步:尋找願意接手維護的團隊
坦白告知系統現況,包括沒有文件、不確定程式碼品質等風險。專業團隊會先做程式碼健診,評估接手成本與風險後再報價。
第四步:如果只是小問題,可考慮按次計費的緊急修復
有些團隊提供「救火式」服務,針對單一問題快速處理,費用較高但能解燃眉之急。這不是長期方案,但能讓系統先動起來。
沒有維護合約不代表系統就廢了,但確實會讓後續成本與風險都變高。如果您現在正面對這個處境,建議先盤點手上有哪些資料、系統目前卡在哪裡,再決定下一步怎麼走。需要協助的話,可以直接聯繫我們討論您的具體狀況。
上線不是結束,而是另一段關係的開始。維護預算抓得準、SLA 談得清楚,您才真正擁有一套「能持續為公司運作」的系統,而不只是一個「做完就不管」的半成品。