系統被前一家廠商做爛了怎麼辦？接手救援的評估步驟

「已經做了兩年，還是上不了線。廠商說再給他三個月，可是這句話他去年就講過了。」

這是我在診斷時很常聽到的開場。老闆手上有一套「快好了」的系統，錢付了大半，員工被叫去測試過好幾輪，每次都卡在不同的地方。想換人做，又怕前面的錢全部白費；不換，又不知道還要等多久。

我是熊董，川輝科技創辦人，帶團隊做系統導入七年，超過 34 個案子、14 個以上產業。這些年我接過不少「別人做到一半」的系統。一個醫美品牌，系統被前廠商建了好幾年，從來沒有上線過；一個影音平台，原本的廠商交付不了，我們接手後三個月做完 18 項功能。這類案子我的結論很一致：系統救援的第一步不是修，是先把東西拿回來。原始碼、資料庫、主機、網域和各種第三方帳號，只要有一樣不在你手上，任何評估都是空談。拿回來之後，再用兩個問題決定修還是重做——程式碼接不接得下手、資料結構還能不能用。順序錯了，你花的第二筆錢很可能步上第一筆的後塵。

先承認：想再給原廠商一次機會，不一定是錯的

很多人聽到爛尾，第一反應是「趕快換掉」。我不這麼看。

換廠商的成本是真的。新的人要花時間理解舊的程式、舊的需求、舊的決定，這段時間你什麼新功能都拿不到。如果原廠商其實只差最後一哩，而且你們之間的問題是需求一直在變、窗口換了好幾個人，那雙方坐下來把剩下的範圍講清楚，可能比換人更快。

專案卡住也不一定是廠商的錯。需求在中途大改、公司內部沒有人能拍板、驗收標準從頭到尾沒寫，這些都會讓任何一家廠商做到動彈不得。換一家，同樣的問題還是會跟過去。

所以判斷要不要換，我會先看三件事：剩下的工作有沒有一份雙方都同意的清單、每一項有沒有日期、過去幾次承諾的日期有沒有至少兌現一半。三件都沒有，那再給三個月也只是再延三個月。

但不管你最後決定留還是換，下面第一步都要先做。

第一步：先把東西拿回來

我遇到的救援案，最常卡住的不是程式寫得好不好，而是「東西根本不在客戶手上」。程式碼在廠商的電腦裡，主機用廠商的帳號開的，網域登記在廠商的名下，簡訊和金流服務綁的是廠商的信箱。老闆以為自己買了一套系統，實際上手上只有一個登入網址。

那個醫美品牌就是這樣，我們做的第一件事不是看程式，是陪他們把散在各處的東西一樣一樣拿回來，確認全部在自己名下之後，才開始談要怎麼重做。

下面這張表是我會請老闆逐項確認的資產：

資產	要確認什麼	拿不回來的風險
原始碼	完整、最新版、放在你名下的程式碼倉庫	只能從頭重寫
資料庫	能自己匯出完整備份，含結構與資料	客戶與交易紀錄被綁住
主機與雲端帳號	帳號擁有者是公司，帳單寄給公司	對方停付，系統直接下線
網域與 DNS	登記人是公司，管理權限在公司手上	網址被轉走或過期
第三方服務	簡訊、金流、LINE、Email 服務的管理權	通知與收款中斷
文件與規格	需求、架構、部署方式、帳密清單	新廠商要花大量時間猜

如果一次拿不齊，順序也有講究：先拿資料庫備份和網域管理權，再拿主機帳號，最後才是原始碼和文件。資料和網址一旦出事，影響的是每天在跑的生意；程式碼晚幾週拿到，頂多是評估晚幾週開始。

要拿這些東西，態度要客氣，但要具體。不要說「把系統給我們」，要列出清單、指定格式、約好日期。很多時候對方不是刻意不給，只是從來沒人要過，也沒整理過。如果合約裡有寫原始碼歸屬，就照合約來；沒寫的話，這是下一次簽約一定要補的條款，客製化系統開發要注意什麼那篇有列出我建議寫進去的項目。

第二步：盤點現況，看它到底「做到哪」

東西拿回來之後，才開始評估。這一步我會分成四層看。

第一層：能不能在乾淨的環境跑起來

把原始碼和資料庫放到一台新的主機上，照文件把它跑起來。這一步聽起來很基本，但它能篩掉很多問題：如果連跑都跑不起來，代表有東西沒交出來，或是部署方式只存在某個工程師的腦子裡。

第二層：程式碼接不接得下手

不用逐行審查。我會看幾件事：結構有沒有基本的分層、同一段邏輯是不是複製貼上到處都是、有沒有任何測試、最近一次修改是什麼時候、用的框架和套件是不是還有人在維護。這些看完，大概就知道一個新的工程師接手要花多久才敢改東西。

第三層：資料結構對不對

這一層最常被忽略，但它往往才是關鍵。程式寫得醜可以重構，資料結構設計錯了，所有東西都會跟著歪。我會拿公司真實的一張單據，看它在資料庫裡怎麼存：客戶、訂單、品項、狀態之間的關係對不對，有沒有同一份資料存在三個地方、改了一處另外兩處不會跟著動。

第四層：有沒有人真的用真實資料跑過

這一層不看程式，看人。找兩三個會實際使用這套系統的員工，請他們拿上週真實的單據，在測試環境從頭操作一次。不要用廠商準備的示範資料，示範資料永遠會過。

真實資料一進去，問題就會浮出來：某個欄位長度不夠、某種折扣算不出來、某個例外情況根本沒有入口。這些問題寫在任何規格書上都看不出來，只有實際操作才會發現。員工操作時卡住的每一個地方，都記下來，這份清單就是之後接手或重做時最準的需求。

順便觀察員工的反應。如果他們操作時一直說「這個以前討論過了」「這個上次就說要改」，代表需求其實早就講過，只是沒有被落實；如果他們連基本流程都不知道從哪裡開始，代表當初根本沒有讓使用的人參與。兩種情況，後面的處理方式完全不同。

四層看完，你手上會有一份很具體的現況：哪些功能真的能用、哪些看起來有但其實是假的、哪些根本沒做。

修還是重做？用兩個問題判斷

老闆最想知道的就是這題。我的判斷方式很簡單，只看兩個軸：程式碼的可接手程度，以及資料結構的可用程度。

兩個軸交叉，會得到四種情況：

• 程式可接手、資料可用：直接接手，把剩下的功能補完。這是最幸運的情況，通常卡住的是專案管理，不是技術。
• 程式難接手、資料可用：保留資料結構，重寫程式。資料是公司最值錢的東西，結構對了就值得留。
• 程式可接手、資料亂：先整理資料、修正結構，再接手程式。這段很枯燥，但跳過它，後面每個功能都會出包。
• 程式難接手、資料也亂：整套重做，舊系統只當成需求參考。這時候硬修，花的錢通常比重做還多。

醫美品牌那個案子，我們最後選擇的就是先拿回來、再重做。影音平台那個案子則是接手往下做，三個月內把 18 項功能交付出來。兩個案子走的路不同，差別就在評估時看到的東西不同——這也是為什麼我不會在看過程式和資料之前，就回答「修還是重做」。

這裡要提醒一件事：重做不等於前面的錢全白花。舊系統裡已經討論過的需求、測試時發現的問題、使用者抱怨過的地方，都是新系統最好的規格來源。如果牽涉到舊資料要搬進新系統，ERP 資料轉移的真實成本那篇講的原則同樣適用。

接手之後，頭三個月先做什麼？

決定接手之後，很多老闆會急著要新功能，因為已經等太久了。我理解，但我會先花一點時間止血。

第一，備份與監控。確認資料庫每天有自動備份，而且備份真的還原得回來；確認系統掛掉時有人會收到通知，而不是等客人打電話來才知道。

第二，收回權限。前一家廠商、離職員工、測試帳號，全部檢查一輪。該關的關，該改密碼的改。

第三，列出所有「還沒做完」的東西，排優先順序。不是照當初的規格書排，而是照現在公司最痛的地方排。這一步做完，你會發現原本規格裡有一部分其實已經不需要了。

第四，小步交付。每兩到四週交出一批可以實際用的功能，讓員工開始用、開始回饋。爛尾系統最大的傷害是信任，大家已經被「快好了」騙過太多次，唯一能修復信任的方式，就是讓他們真的用到東西。

救回來之後，怎麼避免再爛尾一次？

救援案做多了，我發現爛尾的原因很少是單一的技術問題，多半是幾件管理上的事疊在一起：沒有分段交付、沒有驗收標準、程式碼和帳號不在客戶手上、公司內部沒有一個能拍板的人。

所以系統救回來之後，下面幾件事要一起補上：

1. 所有資產登記在公司名下，並且留一份清單，每半年檢查一次。
2. 之後的開發分段交付、分段收款，每段交付都有可以操作的功能，不是只有進度報告。
3. 每一段都有書面的驗收條件，寫清楚怎樣算完成。
4. 公司內部指定一個能做決定的窗口，需求有變時由他拍板，而不是誰提了就改。

如果你正在評估要找哪一家來接手，系統開發外包怎麼找那篇的篩選問題可以直接拿來用。

常見問題

原廠商不肯交出原始碼怎麼辦？

先回去看合約有沒有寫原始碼與智慧財產權的歸屬，有寫就依合約書面要求。沒寫的話，先確認資料庫和各種帳號拿不拿得回來，因為資料比程式碼更重要。程式碼真的拿不到，就以資料為基礎重做，舊系統的畫面和流程當成需求參考。

系統救援要花多少錢？

要看評估結果落在哪一格，接手補完和整套重做的差距很大，沒有評估之前報的數字都只是猜。在川輝，別人做的系統我們會先做免費的診斷評估，看完現況再決定要不要接、用什麼方式接；如果要重做，客製開發從 NT$300,000 起，依書面規格報價。

接手後可以直接簽維護合約嗎？

我們的系統維護（NT$20,000／月）只接自己做過的系統。別人做的系統，要先經過評估，必要的部分整理或重做之後，才進入維護。原因很現實：沒看清楚的系統，誰都不敢保證維護得住。

舊系統還在跑，可以邊用邊救嗎？

可以，而且很多時候必須這樣做，因為公司不能停。做法是先做好備份和監控，讓舊系統穩定撐著，新的部分分段上線、分段切換。最怕的是兩套系統長期並行、資料兩邊都在改，所以每一段切換都要訂好日期，切完就關掉舊的那一段。

救援的關鍵不是技術，是先讓東西回到你手上

爛尾系統讓人最難受的，是你不知道自己手上到底有什麼。先把原始碼、資料、帳號拿回來，再用程式和資料兩個軸判斷修還是重做，接手之後先止血、再小步交付，這套順序走完，你至少不會再花第二筆冤枉錢。

如果你手上正有一套卡住的系統，不確定該修、該重做還是該停，可以先看看我們怎麼做系統維護與接手，帶著現況來，我們先幫你評估。