S4HANA数据迁移大全之二

年前的最后一篇文章，值此新年之际，祝广大SAP从业者新年快乐，来年项目多多，经验涨涨，收入丰丰。

通过上篇文章我们对数据迁移有了一个整体的了解，本篇我讲聊聊在数据迁移中的一些最佳实践和常见问题。

• 一个项目需要做几次数据迁移测试？

一般来说测试的次数取决于项目本身的复杂度，可以从以下几个方面考量复杂度

S4HANA的版本：公用版本会比私有版本和本地部署版本简单很多，所以相对测试的次数就可以减少。

通往S4HANA的道路：如果是系统升级（system conversion），考虑到对FICO模块的影响很大也非常复杂，而且是一个系统里面的所有公司一起升级，一般是需要多轮测试的。如果是全新实施（New Implementation），因为流程和功能都是新的，所以也需要多轮测试来验证数据以及使用迁移后的数据执行流程测试。在全新实施的框架下有一种叫做推广（Rollout）项目，这种项目一般是全球性的企业有了全球化的流程后，到某一个国家的分公司上SAP的项目，这类项目会比全新实施相对简单一些，测试次数也可以相应减少。

迁移策略：与道路相对应的，如果是“全下注”或者是“大爆炸”，因为数据种类多范围广，测试次数就会相应增加。如果是“分阶段”，只有主数据，那么次数就可以减少。

集团结构和流程的复杂度：一个跨国（地区）性的企业和只有一个公司代码的企业，复杂度肯定不一样，另外流程的复杂度也会带来数据的复杂度，这些都是需要考虑的因素。

数据的复杂度：数据本身的复杂度，一方面可能是用到的数据表比较多，另外方面可能数据的相互关联性比较复杂。

现在我把上面的部分因素综合到下面的表格里面，当然这只是一个参考的标准，具体项目还需要具体分析（免责声明）。

一般来说，如果有3项及以上复杂度为高，那么就需要4-5次的测试；如果有1-2项高或者3项以上中，那么需要3-4次测试；如果只有1-2项中其他都是低，那么需要2-3次测试。2次测试是必须的，即使再简单，一次测试成功的概率很低，如果第二次就是直接迁移到正式系统，那么结果大概率是有问题的。

每次测试要遵循有简到难、数据量逐步增加、映射规则逐步完善的过程，不要期望一口气吃成个胖子，但是也不能做重复性的测试。一般第一次测试为IT内部的测试，我们成为技术测试（Technical Mock）,使用少量的数据来验证迁移程序的可行性。最后一次测试是上线的最佳演练，一般称为带妆彩排（Dress Rehearsal）,所有迁移都要模拟真实环境。

• 上线计划（Cutover Plan）是什么？

我们有一定SAP经验的人一定知道，SAP的数据创建（在数据迁移中我们称为上传）是有先后顺序的，比如先上传物料，然后才能上传物料清单。每个项目根据数据迁移的需求不同，顺序还会有所变化，这个需要经过多轮测试才能确定适合本项目的顺序，比如熟悉PP模块的顾问知道，如果迁移生产工单的时候要读取工艺路线，那么就需要先上传工艺路线；如果生产工单都已经开始和修改，不需要读取工艺路线，那么就要先上传生产工单。

我们再扩展一下，除了数据迁移有顺序，其他上线过程中的任务也有顺序，比如基本配置需要先传到生产系统，才能做数据迁移，还有些影响数据迁移的配置，比如采购订单审批的功能，那就需要在数据迁移完成后再传到生产系统。除此之外还有很多非技术性的任务，比如要通知供应商和客户、安排宾馆等等，这些也和其他任务都有前后关联关系。

所以，这个时候你大概能明白了什么是上线计划了，这是一部电视连续剧，剧情一直从决定上线开始一直到数据迁移结束，甚至还包括第一次月结，而且连续剧的叙事方式只有顺序，反映上线前后1-2个月的真实任务顺序。

你可能很好奇具体的上线计划中的数据迁移是怎么安排的？我用下面这张图给大家讲述一下一般的数据迁移顺序。

说明几点：

1.数据迁移顺序遵循数据关联关系，还考虑对业务影响最小，所以先迁移主数据，然后是业务数据。

2.上线周末主要迁移的是公司的业务数据，因为这些数据一旦开始迁移，公司的业务需要“停止”，当然不是100%停止，而是在正式上线前的这段实际发生的业务操作，临时用纸记录。一般我们都建议把上线周末的生产经营活动维持在最小限度，可以把周末需要做的提前做好，比如提前收发货等。

3.上线周末除了做数据迁移，在迁移完成确认后，一般还需要做一点业务“测试”，当然这不是测试，这是实打实的生产系统业务操作，为了就是保证迁移后的数据可用，基本业务操作没有问题。这些测试都是简单测试，比如创建一个新的采购订单、采购订单收货、工单报工等等。

4.一般考虑到工厂初次运行MRP会需要一点时间，所以上线周末的最后一天晚上会运行MRP。

5.FICO的数据迁移活动都一般都放在上线后。为什么？因为他们迁移的数据的记账期间是上个月，对当月的记账不会有任何影响。所以他们一般在旧系统结完账后，在新系统第一个月月结开始前结束就可以了。

• 典型的上线周末（Go-Live Weekend）都干点啥？

神秘的上线周末，不得不说上线周末的任务是非常紧张的，特别是对于一些推广项目，考虑到对其他国家的用户影响需要减到最小，必须充分考虑时区问题，一般中国的上线是等周五美国/巴西时区的人下班后开始的，周五晚上/周六凌晨做好系统准备，比如系统备份，系统备份的目的是万一周末迁移失败，系统可以恢复到迁移前的状态。周六一大早就要开始迁移工作，这里主要是几个模块的顾问和用户比较忙碌：SD:销售订单、计划协议；CS:服务订单；PP:生产工单；MM:库存；PU:采购订单、计划协议。其余的团队虽然没有直接的数据迁移工作，但是他们也要随时待命，因为万一迁移过程中出现了他们团队的配置或者数据问题，需要他们即使纠正，所以你经常能看到一批来的很早但是很闲的人。

除了数据迁移，数据校验也是周末的工作重点，因为下周就正式开始使用系统，所以数据需要校验完毕。另外就是前面提到的业务“测试”，验证迁移数据的可用性和系统配置的正确性。最后需要每个成员在项目迁移文档上签字确认，作为审计文档的一部分。

在项目经理得到每个团队的确认迁移结果后，经项目管理委员会同意，可以宣布系统正式上线，接下来就可以恢复系统接口和用户解锁。第一次MRP也可以运行起来，这个时候其实系统已经上线，唯一要注意的是，如果当天还在月底，所有的财务记账的日期必须改到下个月，不然就会对迁移结果产生影响，因为财务数据迁移的记账日期都是当月，而系统日常业务记账日期是下个月。

• 数据迁移技术和工具有哪些？

讲了这么多数据迁移的策略、概念，现在来讲讲技术，当然这里不是教大家怎么使用工具，这种可以看官方文档。这里主要是讲述各种技术和工具的适用场景。从前面的文章我们了解到数据迁移分为数据下载、数据转换和数据上传，我们先把目光聚焦在数据上传这里，因为数据下载根据旧系统的不同而不同，数据转换也不是所有的工具都支持。数据上传可以看作是数据的创建过程，S4HANA的数据上传有4种技术：

Transaction recording：事务码录屏创建，相信大家最熟悉不过的技术，LSMW就是其中的典型代表

BAPI/FM：通过SAP标准BAPI或者Function module创建，这种方式可以自己写程序调用，LSMW也支持BAPI，另外SAP Migration Cockpit的核心也是这种方式。

IDOC：通过IDOC创建，LSMW也支持IDOC创建，另外还有SAP Data Services。

Table:  直接写table的方式进行数据迁移，这种一般是大型的数据库级别的迁移，典型的工具有SAP自己的Software Update Manager(SUM) 和SNP的CrystalBridge等。

以下是这些主流迁移工具的比较

Software Update Manager(SUM) 和SNP的CrystalBridge都是用于大型项目中的迁移工具，这2个工具不但可以进行数据迁移，还可以拷贝系统所有的配置和开发等，所以有很多种适用场景，比如公司合并、并购等。运行这2个工具需要专业的培训，所以一般顾问很少能接触到，甚至有此类项目参与经历的顾问都不多。

Migration Cockpit是SAP在全新实施领域主推的数据迁移工具，特别是数据迁往Cloud Public Edition，只能使用Migration Cockpit。Data Services除了可以迁移数据，还可以进行数据清理。LSMW虽然是我们最常见的工具，但是SAP不提供后续更新支持，我们只能使用现有的版本。这就导致S4HANA上的一些变化比如银行主数据没有办法通过LSMW创建。

• 数据迁移有什么经验可以分享？

测试！测试！一定要测试！

未经测试的数据和程序直接上传和使用有巨大风险，有时候我们可能在上传前发现了新的数据或者修正了程序，然后就直接上传了。一般在短时间内重压之下我们难以保证没有问题，测试一下看起来拖慢了进程，但是如果上传结果错了，你可能需要几倍的时间来修正。

遵守上线计划的顺序和时间

有时候我们可能迫于压力或者盲目自信，没有完全按照上线计划的步骤来上传，或者提前上传了。带来的风险是可能前面的步骤没有完成导致数据创建失败或者错误。上线计划是根据过去的经验并且本项目的实践而完成的，每个人都应该尊重这个计划，如果有异议，应该找负责人提出修改，而不是直接忽略。

数据文件、用户设置

如果数据量大的文件，建议使用CSV文件，因为CSV文件中描述文件本身的字符很少，只有分隔符，可以减少文件大小，也不会对上传数据产生干扰。

如果是使用录屏方式的迁移，用户设置的日期格式、小数点等都需要和数据里面的格式保持一致。

数据准备工作要尽早开始

数据准备是一个繁琐很花时间的事情，所以要越早开始越好。有些人可能有疑问，新系统流程都没有确定，怎么准备数据。其实有一些工作与新系统无关，比如客户和供应商主数据重复、10多年前的订单还没有关闭等等，这些清理工作可以马上开始。总的来讲，数据准备越早开始越好，这样才能有足够的时间来准备高质量的数据。

数据的集中映射

什么叫集中映射？比如新旧物料的映射，不但物料清单迁移的时候会用到，采购订单、销售订单、生产工单等等都会用到，如果每个团队都自己拷贝一份映射表去做迁移，万一映射结果有改动，那么迁移就会出错。所以在这种关联数据映射的时候，一定要集中映射，最佳的是方法建立唯一映射表甚至是专门的API来让其他团队调用，这样可以保证映射的唯一性。

数据迁移文档

因为数据迁移过程是公司内部ERP系统切换的过程，整个过程是需要被公司内部审计部门和外部审计公司审计的。所以在项目开始后，需要与内审和外审团队就数据迁移策略达成一致。在每次数据迁移测试时，需要使用校验脚本来记录所有的数据校验结果，并要有问题列表以及问题的解决方案和解决时间等，前面提到的上线计划也是必须的，这些都是审计重点关注的文档。在正式上线的时候，还需要正式的项目团队的签字文档，已确认整个数据迁移过程完成。

今天就分享到这里，如果对数据迁移有疑问的小伙伴可以留言给我，我来答疑解惑。