老旧的内部系统，是修着用还是重新建

企业当前面对的处境

拥有使用超过十年的内部系统的企业，大多处在同样的处境：系统依然在跑，也没有大故障。只是一个小小的需求要花两周，而公司里能处理这个需求的人只有一位。

这种状态之所以危险，是因为问题是渐进恶化的。突然停摆的系统会立刻获得预算；但一点一点变慢、一点一点更费工的系统，每年都以"今年也勉强撑过来了"带过。这样带过的年份累积起来，三件事会同时降临。

第一，熟悉系统的负责人离职，未曾文档化的业务规则也随他一起消失。第二，底层技术的安全支持终止——已停止支持的语言或数据库版本，即使发现漏洞也不会再有补丁。第三，新需求再也挂不上去。移动端支持、外部服务串接、数据分析之类的需求，会不断以"那件事现有系统做不到"被驳回。

三者同时到来的时间点，选项就只剩下全面重建了。而全面重建是最贵、也最危险的选项。

应该检讨更换的五个信号

若符合下列项目中的三项以上，就是开始检讨更换的时候了。

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 阶段 — 缩减既有系统

已迁移的功能，请从既有系统中移除。若留着不动，部分业务人员会继续用旧画面，最后演变成永久维持两套系统。拖延这一阶段，是分阶段迁移失败最常见的原因。

若难以移除，至少请阻断访问并改为只读，并且用日期订下何时完全下线。没有日期的清理计划不会被执行。

该选择哪一边

全面重建并非总是错的。若范围小、业务规则有文档留存，且能容许数小时的中断，一次换过去会更快也更便宜。判断基准不是系统的年龄，而是规则记录在哪里。

数据迁移中真正会出问题的地方

进度延后的原因，大多不在功能开发，而在数据。老旧系统里会累积下列状态。

• 同一家客户以不同写法重复登录了好几笔
• 日期、电话号码、营业执照号码的格式因时期而异
• 明明是必填项目却存在空白的数据行
• 残留着引用已消失代码值的数据
• 混杂着仅标记删除、实际上仍存在的数据行

这些问题若在迁移阶段才发现，必然会拖延进度。请在启动前先行调查，并率先决定要整理的范围与要舍弃的范围。 若想把所有历史数据都完美整理干净，迁移本身就永远结束不了。只整理最近几年份，其余以只读方式保存，在许多情况下更为务实。

重新设计安全与访问权限的机会

更换也是难得的整顿安全体系的机会。老旧系统的权限区分大多宽松，多数负责人都能看到超出所需的数据。请在迁移过程中一并确定下列项目。

访问权限的最小化。 请按角色区分，只让必要的数据可见。若把既有系统的权限结构原封不动搬过去，旧的问题也会一并搬过去。

个人信息的存放位置与保存期限。 请厘清哪些个人信息存放在何处、何时销毁。若要迁往云端，还须一并确认数据储存于哪个国家。

处理记录的保存。 请留下谁在何时变更了什么。许多老旧系统正因为没有这项记录，出问题时才追查不出原因。

说服管理层的方法

更换预算大多无法靠技术逻辑通过。"结构老旧""技术支持已结束"这类说明，传达不出让决策者感受到的急迫性。请改以下列三点提出。

现在正在流失的金额。 也就是前面算出的延迟、绕道、差错成本的合计。关键在于：即使不更换，这笔钱也已经在支出。

做不到的事。 请把过去一年间以"现有系统做不到"为由被驳回的需求列成清单。其中若有与营收或客户流失相关的项目，请排在前面。机会损失是比维持成本更有力的依据。

最坏的情况。 请试算唯一的负责人离职、或已终止支持的组件发生事故时，修复所需的时间与成本。即使概率不高，只要规模够大，就足以撼动决策。

提出这三点之后，请只为分阶段迁移的第一阶段申请批准。一次要求全部预算，审议期间就会拉长，而在这期间情况只会更糟。

进度与人力该如何安排

分阶段迁移中最常失准的就是进度。请预先反映三件事。

把业务部门的时间纳入进度。 迁移项目中最稀缺的资源不是开发人员，而是熟悉业务规则的业务负责人。他们是一边做本职工作一边参与的，若不事先就可投入的时间达成共识，每到验证阶段进度就会延后。

把并行运行期间纳入计算。 功能迁移之后，仍须有一段时间同时运行两套系统。这段期间的运营负担反而会增加。若未反映在进度与预算中，最后阶段就会人力不足。

另行安排数据整理期间。 后文提及的一致性问题虽可与开发并行进行，但需要独立的时间与负责人。若把它埋在开发进度里，必定延后。

与外部厂商合作时应确认的事

很多情况下，光靠内部人力难以完成迁移。若考虑委托外部厂商，请在签约前确认下列事项。

交付物是否包含文档。 若只拿到代码，几年后同样的问题会再次上演。业务规则定义书、数据结构说明、运营流程手册都应纳入交付物。

迁移之后的交接方式是否已确定。 建设完成后，内部人力必须能够接手运营。请在合同中明订交接期间与培训范围。

能否分阶段签约。 若一次签下全部，中途就难以调整方向。先执行第一阶段再决定后续，这样的结构对双方都更安全。

对我方数据的权限是否明确。 若开发过程中会使用真实数据，请以书面订明哪些数据会移动到何处、结束后如何销毁。

启动前应准备的事

无论采取哪种方式，都请在启动前备妥下列三件事。

现行业务规则的文档化。 只存在于代码中的规则，在迁移过程中必然会被遗漏。不必是完美的规格书，至少请把例外处理与核准条件写成文字。

数据一致性检查。 请依前面整理的项目调查现况，并决定整理范围。

回退计划。 请为每个阶段订下"出问题时要如何回退"。无法回退的阶段，本身就代表切得太大，是应该再细分的信号。

总结

老旧系统的成本不会以故障的形式出现，而是以延迟与依赖的形式出现。所以才会被太晚察觉。

• 请检查变更成本、人力集中、技术支持终止、数据可及性、绕道作业这五项。
• 请把维持成本拆成延迟、绕道、差错、风险四项来计算，使其成为可与更换成本比较的数字。
• 若规则只存在于代码中，全面重建就是危险的。
• 请从查询功能开始迁移，而且迁移完的功能务必从既有系统中移除。
• 数据一致性请在启动前调查，并预先决定整理范围。
• 请藉这个机会，一并重新设计访问权限与个人信息保存政策。

比起要不要更换，更重要的是不要拖延判断。若符合五个信号中的三项，在今年内开始检讨，会比明年做全面重建来得便宜。