公司 ERP 系統改寫：我如何在維持公司資料的情況下重構 ERP 系統
前言：為什麼要重構？
一間公司成長到一定規模後，通常會開始引入 ERP 系統來管理物料、產品與帳務。從導入系統、建立資料，到公司職員熟悉系統，往往都要經過數年的磨合期。
然而程式業界發展得很快，尤其最近幾年，套件與框架可能一月一小版、半年一大版。流程可能都還沒跑熟，就又有新的技術框架面市。
再加上即使是同一間公司，不同時期也可能依照需求導入不同系統。可能 2000 年導入一套，2010 年又導入另一套，最終演變成系統大雜燴：各部門各自為政、缺乏統整架構，要嘛資料混亂，要嘛無人管理。
但舊系統能跑就放著不管也不是辦法。若長期缺乏維護，不僅會累積各種資訊安全風險，系統的可靠性和正確性也可能逐漸下降，就像一台慢慢老舊生鏽的機器。
因此，如何拆分系統功能，不是一口氣全面革新，而是一步一步將舊系統的功能重構，或導入成可升級、可維護的新系統，乃是當今 ERP 工程師的必修課。
常見的 ERP 系統背景
公司早期不一定有專業的程式人員管理 ERP 系統，但又需要配合公司的資料與流程進行客製化。例如哪裡要加一個單號、哪個客戶有特殊折扣之類的需求。
這些需求常常只是由稍懂技術的相關部門員工，或技術經歷不完全符合的工程師加減維護，難免會累積技術債。長期累積下來，最終就可能演變成錯誤百出又難以維護的現況。
此時若要導入新系統，會因為公司已經累積太多舊資料，而需要高度客製化，不僅金額驚人，風險也很高。
若要全系統重構，又很難找到一個同時懂業務流程、程式架構和資料結構的人做全面統整。非程式專業的公司也很難估量所需的人力和技術門檻，更不容易找到願意承擔整體風險的工程師。對個人來說，這往往不只是金額問題，而是風險過高。
重構需要具備的能力
所以具體來說，重構一個舊 ERP 系統，到底需要哪些能力？根據我幾年來的重構經驗，我認為有以下幾點：
- 懂軟體工程，具備獨立規劃可維護系統的能力：要自建一套能夠長期維護的 ERP 系統，這是不可或缺的項目。
- 分辨市面上各種前後端框架優缺點的能力：我們不需要自己造輪子，但要能夠區分什麼輪子適合跑什麼路。
- 分析公司業務流程的能力：若系統無法符合公司的業務流程，最終只會變成裝飾品。
- 分析公司舊資料結構的能力：資料結構不一定所見即所得，通常都與當年的設計有關。為了確保資料能夠延續，讀懂舊資料是必要項目。
重構流程
1. 業務流程及需求盤點
系統能不能用，取決於它是否符合實際業務需求，因此先盤點公司的所有必要業務流程非常重要。
接著可以藉由分析業務流程，推測公司的業務偏重和使用者習慣。先統整業務流程的數量，了解各項流程的特點和痛點後，系統才能真正解決問題，為公司帶來利益。
2. 整理舊資料結構
公司不可能為了迎合新系統而棄用舊有資料，因此如何留存舊資料，是很重要的前置課題。
有些結構比較單純的資料，例如基本物料資料、客戶資料等，可以考慮暫時沿用資料表。前期兩套系統平行運作時，也能省去資料同步的麻煩，等真的遇到問題，或重要流程都開發完成後，再檢討是否需要重建。
但天往往不從人願。有時候舊系統的資料來源很複雜，例如不同系統的功能曾經被合併成同一套；或是格式老舊，例如用單一字串儲存資料，再切分第 1～10 碼、第 11～20 碼分別代表什麼。
遇到這種情況，就需要建立格式正確的新資料表，將舊資料正規化，以利後續開發。
3. 建立基本框架和開發規範
此時已經對公司的資料和業務有足夠認知，可以開始劃定系統邊界。系統每個月要處理多少資料，是百筆還是萬筆？要產生哪種報表，是數字報表還是統計圖表？有哪些種類的使用者，是內網還是外網、手機還是電腦？這些條件都會影響框架和技術的選擇。
選定框架和技術後，接著就是制定開發規範。除了老生常談的需求規格書、命名原則與結構分層以外，這年頭還可以多訂一份 AI Rules 來規範 AI 助手，確保協作順利。
4. 排定重構順序
人力和時間都是有限的。如果能夠一口氣開發完整個系統，今天大概也不需要看這篇文章了。
因此，我們必須分清楚各流程的輕重緩急，再依照人力和時間制定開發順序，才能一步一腳印完成重構大業。這裡提供一些我個人的判斷標準：
- 舊系統已經存在，但是不敷使用，甚至可能導致資料異常卻難以修復的項目，通常最優先開發。
- 舊系統尚未有相關流程，資料仍然依靠手工作業的項目，如果資料會影響其他流程，建議優先開發，讓資料先進系統，以利後續作業。
- 舊系統尚未有相關流程，但是內容簡單、可以快速產生成果的項目，可以穿插著做，拿一些績效。
- 最後才是舊系統仍可支援且流程穩定的項目。這類通常先讓舊系統頂著用，最後再改。
5. 逐步搬移、測試
排程定好後，就是大家熟悉的流程：開發、測試、部署上線，然後驗證、收取使用者回饋、修正 Bug。
一個新流程在測試穩定可用之前，最好保留舊系統的流程。當新系統臨時發生異常時，仍可啟用舊流程作為備援。待新系統流程驗證穩定後，再停用舊流程，完成一個流程的重構。
結語
重構不是一件簡單的事，因為牽扯的層面太廣：舊系統的解析、資料庫的分析、流程的訪談、新系統的技術架構等等，原本都該由各自領域的專業人員負責，如今卻常常被要求由少數一兩人完成。
論合不合理，當然不合理，但現實總是不盡人意。
因此我寫了這篇文章，讓被迫成為一人軍團，和立志成為一人軍團的人，有個參考。