当企业开始进行系统实施时，最重要和最有风险的一个步骤就是数据迁移——也就是，从旧的遗留系统到新系统的数据移动。

　　企业资源计划(ERP)、企业资产管理(EAM)和任何其他企业应用系统的选型、实施和运行必然包含技术因素，但是技术背景不是系统实施的全部。

　　所有与企业应用系统实施和运行相关的活动还需要商业管理技能背景。具备这些管理背景的人员必须与负责配置和实施系统的技术人员进行有效的沟通，并密切监督他们的实施过程。 这就意味着高级管理层必须紧密地参与实施，一直到把数据从遗留系统迁移到新系统。

　　为什么数据迁移需要管理层的监督? 迁移不就是把表格数据从一个系统转移到另一个系统吗?

　　数据迁移相关案例

　　在实施团队完成数据迁移的第二天，大家正在为超越85%的项目成功率目标而欢呼雀跃。 此时，98%的数据已被成功地从遗留系统迁移到IFS Applications系统中。

　　就在这时，当我们执行数据质量检查时，我们的喜悦之情很快就转为担心。因为，我们发现一个负责迁移的技术人员修改了数据定义。 他的初衷是从技术角度来顺利完成数据迁移。其结果是数据格式被修改了。 另外，为了更快捷地把数据转移到新系统，某些数据没有被导入到既定字段。 虽然这些修改有助于把数据迁移到新系统，但是修改后的格式与我们在IFS Applications预先设定的业务逻辑和工作流有冲突。

　　此时，我们不能把所有问题都归咎于这个技术人员。他这样做的原因也是为了优化数据转移的成功率。 但是，由于评判数据迁移成功的标准不仅是从技术角度——更多是从商业角度，我们从一开始就不应把迁移任务完全交给信息技术专家。

　　虽然我们可以通过第二次迁移来纠正这些问题，但是最初的监管缺乏使我们的项目延迟了好几周的时间。 在这期间，我们从管理人员中指定了一个负责人。他接管了原来那个技术人员负责的数据修改职责。

　　事后，当我反思这段经历时，它激励我撰写了这篇关于数据迁移的6个理解误区的文章。

　　误区1 —— 数据迁移是IT部门的工作职能

　　诚然，IT人员具备提取旧数据以及把它们导入新数据库的技能。但是，迁移过程中的其他职责应由实施团队来完成。这个团队包括实施新应用系统环境所涉及的所有职能领域的资深代表。 这些代表了解如何在旧系统以及新系统中使用这些数据。

　　上面的例子就是最好的说明。 技术专家不一定知道实施过程的哪个环节需要运营和管理指导。 又或者，当一个新的IT技术人员急于通过执行一个成功率高的迁移项目来证明他/她的能力时，修改数据格式可使整个迁移过程更容易。

　　根据数据类别或职能指定决策负责人，并在迁移过程中为IT人员提供运营和管理指导。

　　误区2 —— 内部的IT部门具备提取和导入数据所需的技能

　　很多中小型企业的IT部门只有一到两个员工。即使是人员规模更大的部门也不一定具备正确完成迁移所需的技术层面技能。 由于遗留系统的使用年限问题，数据提取过程可能需要软件编码和使用其他软件包。 不是所有的IT人员都具备从遗留系统中导出数据的技术以及应用这些技术的能力。

　　在最近的一个项目实施中，用户公司的遗留系统需要基于Cobol语言的软件代码开发，以便以正确的格式把数据导入到迁移表格中。 但是，该公司只有一个IT人员了解Cobol语言。在没有别人协助的情况下，他一个人是无法在实施日程规定的时间内完成所有的编码开发的。 这种情况就需要培训现有的内部人员，或者把这部分流程外包。 这两种选择各有其代价和优势。

　　面对这种情况，管理层不应就现有员工是否能处理迁移这个事宜公开发表意见，因为技术专家大多不愿承认他们不具备这些必要的技能;但同时他们又乐于迎接挑战，接受新的和不同的工作。

　　不要想当然的认为公司内部的IT人员一定具备所有技能或工作负荷能力来进行数据迁移。 兼顾现有IT人员的技术背景和工作负荷(记住：IT人员可能在实施过程中还需要支持遗留系统)可避免阻碍项目完成的瓶颈现象。

　　误区3—— 数据迁移是新系统上线前的最后一个步骤

　　因为企业用户需要新系统提供最新的信息，所以大家通常认为应在上线前进行数据迁移。 非也! 事实是，应尽早并经常进行数据迁移。 在对实施团队培训完毕后，在项目初期进行迁移应是最先执行的措施之一。 这种初期迁移可帮助你了解数据源在哪儿，数据的质量和情况，以及应把数据迁移到新系统的哪些字段。 初期迁移的结果还可以帮助实施团队了解新系统的运作方式，以便他们做出更好的决定。 一个企业可能需要经历多个迁移步骤才能达到要求，从而在新系统中进行业务流程测试。

　　迁移是一个循序渐进的过程，而不是一蹴而就;它应被视为实施流程的一个中心环节。 合理规划迁移步骤可帮助你确定实施所需的时间。

　　误区4——修改数据是必需的而且是可取的

　　当在迁移过程中遇到与数据有关的问题时，修改数据不一定是最佳的解决方法。 对于最初的几次迁移，修改是必要的。 实施多个数据迁移步骤的主要原因是要持续地修改和完善数据、表格和代码，直到把遗留数据正确地转移到新系统。 但是，在过程后期，你必须控制变量的数量。也就是说，减少修改的数量。 修改可能导致的问题在于大多数数据与其他数据相互关联。

　　因此，应尽可能避免对数据和数据定义进行修改，因为任何修改都可能对其他数据造成指数级的影响。 对一个数据元素(数据元素、字段、代码或表格)进行“细微”的修改可能对很多数据和流程造成影响。 例如，把度量单位从“单个”改为“磅”可影响现有的数量、单位成本、销货成本和总存货价值。

　　应密切监控对数据、表格或编码的任何修改。距离上线时间越近，越是如此。 项目经理必须清楚地了解要做哪些修改和修改的好处是什么。更重要的是，他们还要知道这些修改可能带来的风险。 基于上述原因，制定一个可行的数据修改审核和审批流程是十分必要的。

　　误区5——我们的数据迁移成功率很高，现在是我们检测流程的时候了

　　如果你认为你已成功完成迁移并该直接进入测试业务流程的环节了，那么你就错了。 数据迁移从来没有像计划的那么准确。 每次迁移都可能发生意想不到的事情和小事故——即便是最后一次也不例外。 必须逐屏逐字段地审核导入到新系统中的数据，以确保以正确的格式转移适当的数据。 每个数据都可能出现问题。如果发现不及时，日后它可能给你带来大麻烦。

　　一个相关的例子就是，一家公司的遗留系统综合生成客户和供应商地址信息。 也就是说，一个地址字段中包含街道名称、城市、省(州)和邮编等所有相关信息。 在新系统中，每个地址元素有不同的字段对应。 当数据被迁移到新系统中时，地址信息被完整地导入到街道名称字段中。结果，城市、省(州)和邮编等字段都是空白。 这种情况就要求实施团队作大量的格式调整。

　　我们都知道那个关于假设的古谚语。 在处理与数据有关的事宜时，你不能作任何想当然的假设。 在迁移完成后，你需要检查和审核每个数据和字段。 只有确定无误时，才能进入下一步流程测试的环节。

　　误区6——上线后，我们总有机会进行修改

　　大多数时候，由于过于强调新系统的预期上线日期，企业总想走捷径，等到系统上线后，才对数据进行必要的修改。 这样做的后果就是可能进一步推迟修改的时间。 在新系统上线前，实施团队会十分忙碌。这个时候，它应把精力主要放在确保新系统正常运行上。 上线后，实施团队会更专注于常规的实施前任务，因而会无暇处理这些修改事宜。 另外，那些专业的外部资源，如：咨询顾问或软件供应商，在系统上线后就可能无法提供及时的帮助。 限制上线后的咨询时间是降低企业应用系统总体拥有成本的最佳方法之一。

　　在上线前就把修改工作完成。 上线后进行修改会更困难，成本也更高。

　　系统实施可能会是一件艰巨的事情。但是如果能从一开始就以正确的方法进行数据迁移，就可避免很多阻碍新系统成功实施的问题。 一个行之有效的办法就是规划足够的时间和资源。这对应用新系统和支持新业务流程十分有帮助。每个项目参与人也将从一开始领会到这种方法的益处。