老舊的內部系統，是修著用還是重新建

企業當前面對的處境

擁有使用超過十年的內部系統的企業，大多處在同樣的處境：系統依然在跑，也沒有大故障。只是一個小小的需求要花兩週，而公司裡能處理這個需求的人只有一位。

這種狀態之所以危險，是因為問題是漸進惡化的。突然停擺的系統會立刻獲得預算；但一點一點變慢、一點一點更費工的系統，每年都以「今年也勉強撐過來了」帶過。這樣帶過的年份累積起來，三件事會同時降臨。

第一，熟悉系統的負責人離職，未曾文件化的業務規則也隨他一起消失。第二，底層技術的資安支援終止——已停止支援的語言或資料庫版本，即使發現漏洞也不會再有修補程式。第三，新需求再也掛不上去。行動端支援、外部服務串接、資料分析之類的需求，會不斷以「那件事現有系統做不到」被駁回。

三者同時到來的時間點，選項就只剩下全面重建了。而全面重建是最貴、也最危險的選項。

應該檢討汰換的五個信號

若符合下列項目中的三項以上，就是開始檢討汰換的時候了。

1. 變更成本不對稱。 在畫面上加一個欄位要花好幾天。如果在使用者眼中瑣碎的需求與重大需求，開發工期相差無幾，那就代表結構已經承受不住變更了。

2. 維護人力只有一位。 只有特定人物才能動手的系統，那個人的休假與離職就等同事業風險。這不是人事問題，而是結構問題。

3. 底層技術的支援已終止。 請確認正在使用的語言執行環境、框架、資料庫的官方支援終止日。若已經過期，資安事故只是時間問題。

4. 資料取不出來。 若取得經營判斷所需的數字，得由負責人親自寫查詢語法，或是要開啟好幾個畫面手工加總，那就是系統把資料關起來了。

5. 繞道作業在增加。 若業務單位不用系統而改用 Excel 管理的範圍正在擴大，就表示系統無法反映實際業務。這些繞道作業不會記錄在任何地方，所以光看系統是看不出問題的。

請試算一下維持成本

汰換的討論之所以推不動，原因大多是「現在不是還能跑嗎，為什麼要花錢」。要回答這個問題，必須用數字呈現維持這一邊也正在發生成本。請合計下列四個項目。

前三項是已經在支出、卻沒有記入任何科目的成本。第四項則是尚未發生、但會按機率累積的成本。

以下是為說明計算方法而設的虛擬範例，實際數值會因各企業的條件而異。若年度變更需求為 30 件、每件平均等待 10 天，等待造成的每日機會成本以 15 萬 KRW 計，光是延遲成本一年就有 4,500 萬 KRW。若再加上兩個部門各自每週花 5 小時做 Excel 雙重管理，以每小時總人事成本 25,000 KRW 計，一年再追加 1,300 萬 KRW。

若合計為一年 5,800 萬 KRW，三年就是 1 億 7 千萬 KRW。到這個時點，才首次出現了可以與汰換成本相比較的數字。維持並非免費，而是一筆不會寄來帳單的支出。

全面重建為何危險

決定汰換之後，最先浮現的方法就是全面重建：停掉舊的、做出新的，然後某一天一次換過去。這很直觀，卻帶著三個風險。

在專案結束之前，效益是零。 若是為期 12 個月的重建，前 11 個月組織只付出成本，卻感受不到任何改善。這段期間若經營環境變化，專案就會承受中止的壓力。

需求會在中途過時。 啟動時整理的需求，與一年後業務單位的需求並不相同。反映這個落差，進度就會延後；不反映，完成的就是一套過時的系統。

風險集中在切換時點。 由於所有功能一次換掉，切換當天一旦出問題，就沒有妥當的回復方法。而問題幾乎總是會出現——因為舊系統裡必然殘留著沒有人記得的例外規則。

分階段移轉這個替代方案

除了全面汰換，還有一種做法：保留既有系統，以功能為單位逐步移轉。順序如下。

第 1 階段 — 劃定邊界

把現有系統切成功能區塊。雖然按訂單、庫存、結算、人事這樣的業務單位來分，但請以資料由誰擁有為基準來劃線。若有多個區塊在直接修改同一張資料表，那個地方日後會成為最大的絆腳石。

劃定邊界時請依循資料流向，而非組織圖。即使分屬不同部門，只要共同修改同一批資料就屬於同一個區塊；而即使在同一個部門內，只要資料完全分離就可以切開。

第 2 階段 — 先分離讀取

最安全的第一個課題是查詢功能。儀表板、統計、報表這類只讀取資料的功能，就算在新系統裡做，也不會影響既有系統。即使失敗，舊畫面仍然在，容易回復，而業務單位也能立刻感受到改善。

這一階段還有一個附帶效果：在做查詢功能的過程中，既有資料的問題會浮現。重複的客戶資料、格式損壞的日期、代碼值為空的資料列，都會在此被發現。在移轉寫入功能之前先知道這些問題，非常重要。

第 3 階段 — 移轉寫入功能

查詢驗證完成後，就移轉登打與修改功能。此時會有一段時間兩個系統同時處理同一批資料，因此請只指定其中一邊為正本。若放任兩邊都能同時修改，就會產生不一致，而找出這些不一致所花的時間，往往比移轉本身還多。

移轉順序從使用頻率低、影響範圍窄的功能開始比較安全。不過若從根本沒人用的功能開始移轉，就得不到驗證，所以實際有人在用、但停一天也無妨的功能才是最好的起點。

第 4 階段 — 縮減既有系統

已移轉的功能，請從既有系統中移除。若留著不動，部分業務人員會繼續用舊畫面，最後演變成永久維持兩套系統。拖延這一階段，是分階段移轉失敗最常見的原因。

若難以移除，至少請阻斷存取並改為唯讀，並且用日期訂下何時完全下線。沒有日期的清理計畫不會被執行。

該選擇哪一邊

全面重建並非總是錯的。若範圍小、業務規則有文件留存，且能容許數小時的中斷，一次換過去會更快也更便宜。判斷基準不是系統的年齡，而是規則記錄在哪裡。

資料移轉中真正會出問題的地方

進度延後的原因，大多不在功能開發，而在資料。老舊系統裡會累積下列狀態。

• 同一家客戶以不同寫法重複登錄了好幾筆
• 日期、電話號碼、營業登記號碼的格式因時期而異
• 明明是必填項目卻存在空白的資料列
• 殘留著參照已消失代碼值的資料
• 混雜著僅標記刪除、實際上仍存在的資料列

這些問題若在移轉階段才發現，必然會拖延進度。請在啟動前先行調查，並率先決定要整理的範圍與要捨棄的範圍。 若想把所有歷史資料都完美整理乾淨，移轉本身就永遠結束不了。只整理最近幾年份，其餘以唯讀方式保存，在許多情況下更為務實。

重新設計資安與存取權限的機會

汰換也是難得的整頓資安體系的機會。老舊系統的權限區分大多寬鬆，多數負責人都能看到超出所需的資料。請在移轉過程中一併確定下列項目。

存取權限的最小化。 請按角色區分，只讓必要的資料可見。若把既有系統的權限結構原封不動搬過去，舊的問題也會一併搬過去。

個人資料的存放位置與保存期間。 請釐清哪些個人資料存放在何處、何時銷毀。若要移往雲端，還須一併確認資料儲存於哪個國家。

處理紀錄的保存。 請留下誰在何時變更了什麼。許多老舊系統正因為沒有這項紀錄，出問題時才追查不出原因。

說服管理層的方法

汰換預算大多無法靠技術邏輯通過。「結構老舊」「技術支援已結束」這類說明，傳達不出讓決策者感受到的急迫性。請改以下列三點提出。

現在正在流失的金額。 也就是前面算出的延遲、繞道、差錯成本的合計。關鍵在於：即使不汰換，這筆錢也已經在支出。

做不到的事。 請把過去一年間以「現有系統做不到」為由被駁回的需求列成清單。其中若有與營收或客戶流失相關的項目，請排在前面。機會損失是比維持成本更有力的依據。

最壞的情況。 請試算唯一的負責人離職、或已終止支援的元件發生事故時，修復所需的時間與成本。即使機率不高，只要規模夠大，就足以撼動決策。

提出這三點之後，請只為分階段移轉的第一階段申請核准。一次要求全部預算，審議期間就會拉長，而在這期間情況只會更糟。

進度與人力該如何安排

分階段移轉中最常失準的就是進度。請預先反映三件事。

把業務單位的時間納入進度。 移轉專案中最稀缺的資源不是開發人員，而是熟悉業務規則的業務負責人。他們是一邊做本職工作一邊參與的，若不事先就可投入的時間達成共識，每到驗證階段進度就會延後。

把並行運作期間納入計算。 功能移轉之後，仍須有一段時間同時運作兩套系統。這段期間的營運負擔反而會增加。若未反映在進度與預算中，最後階段就會人力不足。

另行安排資料整理期間。 後文提及的一致性問題雖可與開發並行進行，但需要獨立的時間與負責人。若把它埋在開發進度裡，必定延後。

與外部廠商合作時應確認的事

很多情況下，光靠內部人力難以完成移轉。若考慮委託外部廠商，請在簽約前確認下列事項。

交付物是否包含文件。 若只拿到程式碼，幾年後同樣的問題會再次上演。業務規則定義書、資料結構說明、營運流程手冊都應納入交付物。

移轉之後的交接方式是否已確定。 建置完成後，內部人力必須能夠接手營運。請在契約中明訂交接期間與教育訓練範圍。

能否分階段簽約。 若一次簽下全部，中途就難以調整方向。先執行第一階段再決定後續，這樣的結構對雙方都更安全。

對我方資料的權限是否明確。 若開發過程中會使用真實資料，請以書面訂明哪些資料會移動到何處、結束後如何銷毀。

啟動前應準備的事

無論採取哪種方式，都請在啟動前備妥下列三件事。

現行業務規則的文件化。 只存在於程式碼中的規則，在移轉過程中必然會被遺漏。不必是完美的規格書，至少請把例外處理與核准條件寫成文字。

資料一致性檢查。 請依前面整理的項目調查現況，並決定整理範圍。

回復計畫。 請為每個階段訂下「出問題時要如何回復」。無法回復的階段，本身就代表切得太大，是應該再細分的信號。

總結

老舊系統的成本不會以故障的形式出現，而是以延遲與依賴的形式出現。所以才會被太晚察覺。

• 請檢查變更成本、人力集中、技術支援終止、資料可及性、繞道作業這五項。
• 請把維持成本拆成延遲、繞道、差錯、風險四項來計算，使其成為可與汰換成本比較的數字。
• 若規則只存在於程式碼中，全面重建就是危險的。
• 請從查詢功能開始移轉，而且移轉完的功能務必從既有系統中移除。
• 資料一致性請在啟動前調查，並預先決定整理範圍。
• 請藉這個機會，一併重新設計存取權限與個人資料保存政策。

比起要不要汰換，更重要的是不要拖延判斷。若符合五個信號中的三項，在今年內開始檢討，會比明年做全面重建來得便宜。