身為一個在PM界打滾20年的產品長，我深深體會到企業在數位轉型過程中面臨的最大挑戰之一：老舊系統的維護與更新。
在台灣的上市櫃公司中，我們經常可以看到一個有趣的現象：系統的年齡往往與管理層的年資成正比。這些系統就像是一位資深的員工，雖然經驗豐富，但技術架構與程式語言都已顯得過時。更令人擔憂的是，這些系統的複雜程度往往超乎想像，就像一棵盤根錯節的老樹，每個分支都牽連著無數的業務流程。
最令人頭痛的是，當我們試圖理解這些系統的完整功能時，往往會遇到一個根本性的問題：沒有人能夠完整地說清楚系統究竟肩負著什麼樣的責任。這就像是一個傳承了數代的家族企業，每個人都只知道自己的那一部分，卻沒有人能夠完整地描繪出整個企業的運作脈絡。
在這種情況下，系統的維護人員往往只能扮演”急救員”的角色，他們的任務就是確保系統能夠繼續運作，而不是進行深度的優化或改進。這就像是一個老舊的機器，我們只能不斷地進行維修，卻無法進行全面的升級。
當我們試圖進行系統重構或更新時，面臨的挑戰更是巨大。我們必須以現有系統的功能為基礎進行盤點和規劃，但在沒有人完全了解系統全貌的情況下，這個任務就像是在解一個巨大的拼圖，而每一片拼圖都可能牽動著整個企業的運作。
更令人困擾的是，在這種情況下，使用者往往會提出許多天馬行空的需求，這些需求可能與現有系統的架構完全不兼容，但又確實反映了業務發展的需要。這就像是在一棟老舊的建築物上不斷加蓋新的樓層，既要保持原有的結構穩定，又要滿足新的使用需求。
面對這些挑戰，我認為企業需要採取以下幾個關鍵步驟：
- 現在就開始調查，記錄現有系統的功能和業務邏輯
- 培養跨部門的技術團隊，確保知識的傳承和共享
- 制定漸進式的系統更新策略，避免一次性的大規模改造
- 加強與業務部門的溝通，確保新系統能夠真正滿足業務需求
數位轉型不是一蹴而就的過程，而是需要耐心和智慧的長期工程。只有正視這些挑戰，並採取適當的策略，我們才能幫助企業在數位時代保持競爭力。
身為一位在PM界打混二十年的產品長，我經常需要面對一個艱難的抉擇：當核心系統面臨更新時，究竟該選擇重寫（Rewrite）還是翻修（Refactor）？
在數位轉型的浪潮中，企業往往能夠透過新技術快速解決許多問題。然而，當涉及到核心系統（如交易系統、帳務系統、ERP）時，我們經常會遇到一個共同的困境：老舊的程式碼與業務邏輯，就像一棵盤根錯節的老樹，其影響範圍往往超出我們的想像。
根據 Software Engineering Radio 最新一期（2025年2月）對資深軟體顧問 Ivett Ördög 的專訪，她提出了幾個值得深思的觀點：
重寫 V.S 翻修
重寫的開發成本可能是翻修的 2~3 倍。(另: 根據 Mobilize.Net 的研究，重寫應用程式的成本約為每行程式碼 30 美元。以目前的物價水準計算，每行程式碼的成本高達約 2,000 台幣。這個數字足以讓任何管理層三思。)
重寫的失敗率：最常見的失敗原因並非技術問題，而是「完成後才發現沒有足夠的時間和資源進行完整的交付與導入」。這提醒我們，專案預算的合理規劃至關重要。
有趣的是，從心理層面來看，開發團隊往往傾向於選擇重寫。畢竟，沒有人願意承擔前人的技術債務，而且參與核心系統重寫的經驗在履歷上確實非常亮眼。這種心態很容易理解：與其修補別人的坑，不如創造一個屬於自己的全新開始。
然而，作為管理層，我們需要更全面的分析工具和知識來做出正確的決策。讓我們來看看什麼情況下適合選擇重寫或翻修：
🧩 什麼時候考慮「重寫」？
- 現有系統架構無法支持需求擴張
- 系統過於複雜，難以理解和維護
- 技術堆疊已經過時，無法滿足現代需求
- 原系統是 MVP，無法應對業務規模擴張
🔨什麼時候適合「翻修」？
- 有穩定的使用者和收入來源
- 團隊具備理解現有系統的能力
- 資源有限但希望逐步改善
- 希望降低風險，保持持續交付
這個決策過程需要管理層具備深厚的技術理解力和業務洞察力。我們必須平衡短期成本和長期收益，考慮團隊能力，評估業務風險，並確保決策符合企業的整體戰略目標。
系統重寫的隱性成本
系統重寫不僅僅是一個技術專案，更是一場全面的組織變革。在決定進行系統重寫之前，企業主和專案經理必須深入理解各種隱性成本，這些成本往往遠超出單純的開發與硬體投入。
在系統重寫的過程中，最容易被低估的就是業務邏輯的重新梳理。由於現有系統已運行多年，各種業務規則早已形成錯綜複雜的網絡。新系統重寫不僅需要技術團隊的參與，更需要大量的人力與時間進行業務訪談、詳細的流程記錄與分析，以及跨部門的協調與共識形成。這是一項需要全組織共同參與的重大任務，而非單純的技術工作。
新系統的導入必然伴隨著全面的教育訓練需求。從業務、客服到財務人員，每個人都需要重新學習操作流程。這個過程不僅會造成暫時性的效率降低，更可能在短期內影響整體業務運營。同時，系統重寫後，企業必須重新審視資料處理方式的合規性、權限控管機制的調整、流程稽核需求的更新，以及相關認證的重新取得，這些都可能帶來額外的法務、稽核與管理成本。
資料轉移是重寫過程中最關鍵的環節之一。企業需要處理數年甚至數十年的歷史資料，確保資料格式與結構的正確轉換，開發專門的 ETL 工具與流程，並進行大量的測試與驗證。如果企業與外部系統有大量介接，重寫過程還需要重新設計並建置 API 接口，與合作夥伴進行協調與溝通，進行全面的測試與驗證，並制定應急方案與回滾(Roll Back)機制。
最容易被忽視但影響最深遠的是組織文化的變革。舊系統多年來已深刻融入企業的運作習慣與人員的日常操作中。重寫之後新系統與新流程的推行，將打破人們既有的習慣與舒適圈，引發大量的抵觸、焦慮甚至抗拒。這種文化層面的變革若沒有妥善溝通與逐步適應，可能導致嚴重的人力流失與士氣下滑，甚至影響企業營運的整體穩定性。
以我目前正在進行中的新核心替換為例，系統重寫過程中的種種挑戰。在將核心系統逐步分拆成微服務的過程中，每一步都可能成為系統中斷的導火線，團隊成員承受著巨大的壓力。當系統出現效能問題時，專案團隊往往成為眾矢之的，而操作人員因難以適應新流程而選擇離職的情況也屢見不鮮。在這種情況下，PM 不僅要處理技術問題，更要同時擔任團隊的心理輔導員。
因此，在進行系統重寫決策時，企業主必須謹慎考慮。切勿為了討好工程團隊或追求技術創新而貿然重寫，而是要在決策前進行全面的成本效益分析，制定詳細的變革管理計劃，確保高層管理團隊的支持與參與，並建立清晰的溝通機制與時程表。同時，也要為專案團隊提供充分的心理支持，建立明確的責任歸屬機制。
系統重寫是一項需要全組織共同參與的重大工程，其成功與否不僅取決於技術能力，更取決於組織的準備程度與執行力。在做出重寫決策之前，企業必須充分理解並準備好面對這些隱性成本，才能確保專案的順利進行。
