第三部分完成了清理工作：名称已统一，日期使用同一种格式，数字成了真正的数字，过去靠单元格颜色表达的含义也变成了明确填写的字段。数据已经可以迁移了。剩下的是决定过渡能否平稳完成、还是演变成数周混乱的那个决策：先迁移什么？

这看起来像是负责实施的人要处理的技术细节。实际上它是一个运营决策，而且应由你来做。你的公司不会为了迁移而暂停。客户会下单，发票会开出，供应商会送货——而这一切都发生在你的数据一半在一个地方、一半在另一个地方的时候。正确的顺序能让这段时期变得可控，而不是让每个人都做两遍工作。

为什么一次性全部迁移行不通

这种本能可以理解：周末把所有东西搬过去，周日在新系统上开门营业，大功告成。这种设想通常会因为三个与系统质量毫无关系的原因而失败。

第一，迁移过程中你会发现比预期多得多的问题。每次迁移都会暴露出没人注意到的缺失数据：没有税号的客户、没有计量单位的商品、没有参考号的发票。如果把所有东西一起迁移，这些发现会在同一时间、在最紧张的时刻一齐涌来。

第二，你的团队是在使用系统的同时学习系统。没有人能在一天之内掌握一个新工具。一次性迁移要求所有人同时学会所有东西，所以当错误出现时，你无法判断它从何而来：是数据错了，是系统配置错了，还是员工只是还没看懂这个界面？

第三，它不给你留退路。如果两天后暴露出一个根本性缺陷，你唯一的选择就是硬着头皮推进或者全部回退，而这两者代价都很高。分阶段迁移始终让一部分业务站在稳固的地面上。这是在停滞不前的系统项目中反复出现的模式之一：问题很少出在工具上，通常出在试图在同一天改变一切。

先主数据后交易数据：整个顺序所依据的规则

你的数据分为两类。主数据：客户、供应商、商品或服务、员工、会计科目表。交易数据：发票、订单、采购订单、库存变动、收款。

两者的区别不在于重要性，而在于方向。交易数据总是指向主数据：每张发票指向一个客户和若干商品，每张采购订单指向一个供应商。反过来则永远不成立。所以顺序由依赖关系决定，而不是由偏好决定：先迁移主数据，因为交易数据无法建立在不存在的东西之上。

如果颠倒顺序，你就会遇到典型的失败：你导入三千张发票，系统为其中写到的每个名称自动创建一个新客户，最后你的客户列表里同一家公司以三种写法出现了三次。你会在系统内部重现第三部分花大力气清理掉的那种混乱——只是现在纠正起来更难。

实际操作中，顺序如下：

  • 第一：核心实体。客户、供应商、商品和服务。这些是简短的列表，迁移一次并人工逐项核对。这是其他一切所依托的基础层。
  • 第二：期初余额。每个客户欠你多少、你欠每个供应商多少、起始时刻的库存数量、各科目余额。这不是历史数据，而是系统起步的零点。为它选定一个具体日期，并坚持不变。
  • 第三：只迁移未结交易。当前仍在进行中的内容——尚未交付的订单、尚未收款的发票、尚未到货的采购订单。这是团队每天都要处理的部分，而且远比你想象的要少。
  • 最后，也可能永远不需要：历史归档。往年已结清的发票。

历史归档：能为你节省数周时间的问题

迁移中最耗费时间和金钱的单项，就是坚持要把公司的全部历史搬进新系统。在做这个决定之前必须先问一个问题：你实际上会用这些历史数据做什么？

如果答案是我们需要用它来查询或应对法定审查，那么归档本身就已经履行了这一功能——以原始格式保存在已知且可检索的位置。你的法定义务是保存发票和记录，并能在被要求时出示，正如天课、税务和海关总局（ZATCA）所规定的那样，而不是要求它们全部必须存放在新系统中。

如果答案是我们需要把今年与往年做对比的报表，那么你需要的是部分历史数据而不是全部，而且通常只需汇总层面的数据，不需要每一行发票明细。这两种迁移在工作量和成本上的差距都很大。

工作规则是：迁移那些你会据以做决策的历史数据，其余作为归档保留。不要把归档迁移作为上线的前提条件——它可以之后在没有压力的情况下完成，而上线却不能无限期推迟。

并行运行：必要，但如果不设期限就很危险

并行运行是指在一段确定的时间内，同时在新系统和旧文件中记录交易。它只有一个明确的目的：确认系统能产出与你已知结果相同的数据。你会对比本周的销售总额、客户余额、一两种商品的数量。如果数字吻合，说明系统运行正常；如果出现偏差，你能在有人依据错误数字做出决策之前就发现它。

但并行运行有实实在在的成本：你的团队要做两遍工作。这个成本持续两周可以接受，持续三个月则是破坏性的。危险不仅在于工作量。一段时间后，双重录入会开始松懈——有人在一处记录、另一处推迟——于是两份数据逐渐偏离，这项工作完全失去意义，因为你已经不知道哪一份是正确的。

所以这里唯一重要的规则是：并行运行必须从第一天起就向所有人宣布结束日期。把日期写下来，告诉团队，只有在做出明确决定并附上书面理由时才延期——绝不能任其拖延。没有期限的并行期不是谨慎，而是被推迟的决定，这也是新系统整整一年只被用了一半的最常见原因。这属于变革管理工作的一部分，我们在分阶段实施系统的指南中有详细论述。

Origami 的观点

当我们为一家依赖电子表格运营的公司构建定制系统时，我们把迁移计划视为设计的一部分，而不是项目结束时的执行步骤。原因在于，迁移顺序会迫使我们就系统本身的结构做出决定：哪些实体必须能够独立存在，哪些字段必须允许暂时不完整，以及在哪些地方需要可重复执行且不会产生重复记录的导入。

我们还会在开始之前与客户确定旧文件的关闭日期，因为正是这个日期把项目从一场并行实验变成真正的过渡。这与我们在分阶段数字化路线图中采用的方法相同，并贯穿于我们的服务：每个阶段都交付能正常运行的成果，而不是承诺到最后一切都会正常运行。

告诉你迁移已经成功的信号

你不会从完成报告或迁移百分比中得知过渡是否成功。你会从一个没人要求的行为中得知：员工在没人吩咐的情况下不再打开旧文件。当系统成为他们早上第一个打开的东西，因为它是获取所需信息的更快途径时，迁移才真正完成了。如果尽管所有内容都已迁移，他们每天早上仍在打开那个文件，那么无论进度数字怎么说，迁移都还没有真正发生。

关注这个信号，而不是那些数字。如果你发现大家又回到了旧文件，原因通常不是抵触——而是系统没有提供他们需要的东西，或者提供得很慢，或者步骤更多。这是可以解决的原因，但前提是你要尽早发现并询问。

接下来的几部分

数据已经按正确的顺序迁移完毕，一个在文件世界里不存在的问题随之出现：谁打开文件，谁就能看到其中的一切，而系统则决定谁能看到什么。下一部分讨论权限——工资、利润率和客户数据，以及谁可以查看其中每一项。之后我们将转向你过去每月手工制作的报表，并以迁移后的头三十天为本系列收尾。

参考来源