那是一個週五下午，某間做了十幾年的物流公司，老闆打電話給我。

「我們的系統……是十年前一個工程師弄的，他離職之後沒有人敢動。現在很多功能都跑不順，但又不敢改，怕整個壞掉。」

我問他：「那你們現在怎麼辦？」

他嘆了口氣：「我們就……繞過去。客服手動補，主管用 Excel 再跑一次，出錯了再打電話修。」

這個故事，我聽過不只一次。

「不敢動」的背後，其實是三種恐懼

老系統之所以變成公司裡的燙手山芋，通常不是因為它真的不能動，而是因為沒有人敢負責。細問下去，會發現是這三種恐懼在作祟：

第一種：不知道它在做什麼。 原始工程師走了、沒有文件、沒有測試，只知道「它在跑、不能壞」。誰都不敢動，因為不知道動了之後會發生什麼事。

第二種：怕改壞線上服務。 系統一天到晚在用，根本沒有「維護時間」。改一個地方，可能客戶那邊就報錯。失敗的代價太高，所以選擇不動。

第三種：怕做了一半沒人收尾。 上次找人改，改到一半外包跑路；或是花了錢，結果只是把問題搬到別的地方。傷過一次，就不敢再試。

這三種恐懼都合理。但問題是，「不動」本身也是有代價的。

你以為不動是保守，其實是在慢慢失血

每多一個人工補救流程，就多一個出錯機會。每多一份 Excel，就多一個資料不一致的風險。每晚一天決定，系統就再老一天、再難動一天。

而且，市場不會等你。競爭對手如果先把流程自動化，他們就能接更多單、犯更少錯、花更少人力成本。你還在靠人工撐的時候，差距已經在拉開了。

老闆最後問我那個問題：「那我現在要怎麼辦？」

我跟他說：「不是要你今天就把系統整個翻掉，而是先搞清楚你在怕什麼、哪些其實可以動、哪些才是真正的地雷。」

老系統翻新，正確姿勢是這樣的

這幾年我做過幾個老系統翻新的案子，摸索出一套不容易出事的方式：

第一步：先讀懂它，再決定要不要動。 在還沒寫任何一行新程式之前，先把現有系統的行為摸清楚。它在做什麼、資料怎麼流、哪些地方是核心、哪些是邊緣功能。這個階段花一到兩週，但之後所有決定都會更有把握。

第二步：先加測試，再動邏輯。 很多老系統沒有測試，導致沒有人知道「改了之後有沒有壞掉」。在動主要邏輯之前，先補上關鍵路徑的測試，讓每次修改都有安全網。

第三步：不砍掉重練，只「逐步替換」。 最常見的錯誤是「讓我重寫一個新的」。這條路通常比想像中長三倍，而且最後反而更難落地。比較安全的方式是把舊系統一塊一塊地用新方式替換，每次只動一個範圍，確認沒問題再繼續。

第四步：部署策略要有保底。 每一次上線，都要有「壞了怎麼辦」的方案。可能是功能開關（Feature Flag）、可能是藍綠部署、可能是回滾機制。不是每次都會用到，但有的話就能安心動。

最後回到那位物流公司老闆

我們花了三週讀懂他的系統，找出真正的核心邏輯，把那些「繞過去」的手動流程一個一個搬進系統裡。第一個月，客服手動補的量掉了六成；第三個月，那份主管在用的 Excel 終於可以退休了。

系統沒有壞掉。業務也沒有停。

他說：「早知道幾年前就動了。」

老系統不一定要砍掉重練，但它需要有人願意先讀懂它、再謹慎地動它。

如果你現在也有一個「不敢動的系統」，歡迎跟我聊聊，說不定沒有你想的那麼複雜。
原文