SAP数据迁移--第三章 计划和组织数据迁移项目

第三章 计划和组织数据迁移项目
在本章中首先会简要定义不同类型的数据迁移项目。接下来会介绍不同的迁移阶段如何集成到实施项目的各个阶段。第三部分可以了解到哪些任务会在每个项目阶段都出现，及如何安排这些任务到工作组中。最后会提供一些建议，关于如何确定数据迁移对象及计算所需工作量

---

3.1 数据迁移项目的类型

所有数据迁移项目都处理的同一个问题，就是如何从一个系统获取数据转移到另一个系统，但是我们可以根据以下几点来区分不同类型的数据迁移项目，如下所述：

3.1.1 初始导入(Initial Load），也叫Green Field

这种initial load的项目也叫Green Field，是迁移数据到一个新实施的SAP系统中，此类项目的数据来自不同的源系统，这对于数据迁移项目来说是正常的。

3.1.2 升级项目（Upgrading an Existing System ）也叫Brown Field

这种需要升级已有系统的项目叫做Brown Field，一个已有的生产SAP系统可以将原有数据和业务流程进行扩展。同时也可以有不同的历史数据来源转移到目标系统。

3.1.3 分阶段推广项目（Phased Roll-Out）

分阶段推广项目是初始导入 (Initial Load） 和升级项目 （Upgrading an Existing System ） 的结合。如果IT生态系统 （IT landscape） 被重构，通常是推广类型的迁移项目。这通常用于合并和收购、系统集中化 （centralizing）、或将SAP 系统推广到本地或国际子公司。此类项目通常周期很长，持续数年。升级项目需要组织良好的项目管理来规划数据迁移的持续时间和质量，而分阶段推广可以在多年的基础上削减成本并提高质量。但是，这需要构建额外的接口，以将您仍然存在的系统连接到新的SAP生态系统。

3.1.4 Big Bang

Big Bang就是把集团内所有公司同一时间段完成roll-out，如果子公司的数量很少，或者它们和母公司使用相同或相似的流程，通常会使用这种方法。这种Big Bang实施失败的风险比分阶段推出的风险更高。因此，您需要更准确地规划和测试SAP系统的上线。通过Big Bang的方法，整个公司的IT布局和流程都会改变。如果数据质量或其他方面出现问题，整个公司的生产系统就会受到影响。

3.1.5 系统优化 (System Optimization)

如果流程和组织结构必须从一个SAP系统完全的迁移到另一个SAP系统，则必须使用特殊的法律合规技术和服务。这些服务和技术叫做生态系统优化。系统优化最常见的例子是将某些子公司或公司的部分业务出售给另一家公司，或者是收购其他公司。在第一种情况下，想要从SAP生产系统种剥离出流程、组织结构及其数据；在第二种情况下，想要将额外的流程和组织结构纳入到SAP生产系统。因为目标系统和源系统都是SAP，大多数情况下数据迁移可以在数据库表级别完成。这种方式很快，而且可以实现历史数据转移，然而这种类型的系统优化要受到财务审计和各国会计准则的制约，所以可能需要有相关资质服务的供应商，比如SAP’s System Landscape Optimization (SLO)。

3.1.6 云迁移

云迁移是将所有或部分流程迁移到SaaS (software-as-a-service) 提供的公有云，而不是私有云或托管云模型的过程。迁移到SAP Cloud for Customer, SAP SuccessFactors或SAP S/4HANA云版本等云系统与迁移到本地系统是有所不同的。SAP提供了工具和预构建内容来进行迁移。可以使用这些工具生成Excel/xml文件，将历史数据加载到云系统中。
在一些云方案中，可以直接链接到SAP源系统进行数据抽取。因为不能访问后端系统，所以比如LSMW和批量导入 （batch input），无法再使用。由于自开发和预构建内容有限，实现数据加载过程的工作量将较低。您必须以正确的格式提供文件，并维护值映射。关于SAP SuccessFactors会在第8章，SAP Business ByDesign 和 SAP Cloud for Customer会在第9章，SAP S/4HANA云版本会在第12章分别介绍。

【这本书的迁移类型分的很细，个人理解的迁移就是三种类型，第一种就是Green Field，也就是新实施项目，这个新的S4其实可以是使用总部推广的模板，或者公司重新设计的蓝图和架构，源系统即使是SAP，那些自开发的功能都不会迁移到目标系统中，只有历史数据会根据业务需求进行迁移；第二种是Brown Field，由旧的系统升级到S4,保留全部或大部分源系统的数据及功能，类似技术升级，但是这种情况下因为是带着数据进行的，所以很多配置是无法更改的，所以灵活性比较低，但是基本保留了原有的功能，当然S4已经不支持的t-code就无法再使用了；第三种就是选择性迁移，SNP管这种迁移叫做Blue Field，需要不带任何数据的拷贝一套原有的开发系统，然后根据新的业务需求进行配置，对自开发的代码进行分析和调整，之后再将历史数据选择性的（指年度上，如果数据量很大，不建议迁移全部的历史数据）迁移到目标系统，这种方式灵活性较高，保留了源系统的功能，同时也可以对配置进行更改。然后这三种基本类型还可以进行一些细分，根据项目上的实际需求去进行调整，但是本人觉得三个大类比较容易理解，也包含了迁移的各种场景，后续把相关教材啃完再考虑整理一篇文章出来。】

请注意，这些不同类型的数据迁移项目的数据迁移阶段通常是相同的，如下所述。

---

3.2 数据迁移项目的阶段

通常SAP的实施项目可以使用不同的实施方法，最常用的是ASAP。【SAP推出最新的方法论是Activity Methodology】数据迁移项目阶段一般不同于实施项目阶段，本节中将解释不同的数据迁移阶段，及这些阶段如何包含到ASAP的标准项目阶段中。
ASAP实施方法包含以下五个阶段：

1. 项目准备阶段 Project preparation
2. 业务蓝图阶段 Business blueprint
3. 实现阶段：包括测试 Realization (including tests)
4. 最终准备阶段 Final preparation
5. 上线及支持阶段 Go-live and support
   就像第一章描述的，最好的方式是将SAP迁移作为单独的子实施项目。与ASAP不同的是，SAP迁移包含7个阶段
   1.数据分析 Data analysis
   2.映射 Mapping
   3.实施 Implementation
   4.迁移测试 Data migration test
   5.数据验证 Data validation
   6.数据清洗 Data cleansing
   7.生产数据上载和支持 Productive load and support
   
   与ASAP对比，迁移的阶段没有严格的顺序。他们是重复的，可能与ASAP和其他数据迁移阶段重叠，后续阶段的结果会影响前面的阶段，这是必要的，因为它使项目人员能够以灵活的方式对错误和缺陷做出反应。当将真实数据加载到已配置的测试系统中时，通常会发现蓝图设计中的缺陷。业务蓝图，数据分析，映射（mapping）必须进行调整，以纠正这些缺陷，接下来的章节将更详细的介绍这些迁移阶段。

3.2.1 数据分析 (Data Analysis)

数据分析阶段通常与业务蓝图阶段 (BBP:Business blueprint phase) 是并行的，但是不用启动时间完全一致，可以再BBP进行到一半才开始。因为这个时候，大部分的业务流程已经已经在这个阶段完成了设计，所以会比较容易识别出迁移对象，哪个系统作为抽数的主导源系统。

业务对象与迁移对象 (Business Object vs. Migration Object)

• 业务对象标识对于业务流程建模的单个对象。它是一个语义的实体，用于标识参与业务场景的最小逻辑单元，比如物料，客户，采购订单，发票等。
• 迁移对象标识业务对象的一个实体，用于迁移业务对象的数据，比如从A系统迁移基本物料数据，从比系统迁移物料销售数据，这里的业务对象是物料，迁移对象是基本物料数据，物料销售数据。

业务对象和迁移对象间的关系是1：N。一个业务对象可以对应多个迁移对象，但每个迁移对象只能对应一个业务对象。

3.2.2 映射 (Mapping)

映射阶段和数据分析阶段会有一些重合，不要等到数据分析完成才开始映射,映射阶段应该尽早开始。比较好的开始点是在确定了第一个主数据对象，而且BBP基本完成了关于这个主数据对象的创建维护流程。
BBP文档包括建立转换规则 (conversion rules) 的规则和说明，映射阶段可能持续到迁移测试阶段。第一次迁移测试的结果常常对映射及转换规则产生重大影响。

3.2.3 实施阶段 (Implementation）

在项目的实现阶段 (realization phase) ,可以提前开始实施阶段和首次功能测试。实施阶段的最佳起点是在定义了大部分转换规则之后。然后开始抽取数据，并通过将数据加载到目标系统来测试转换规则。

3.2.4 数据迁移测试阶段 (Data Migration Tests)

测试是每个项目最重要的事情。你需要尽早开始首次功能测试。数据迁移越复杂，设计的目标系统，源系统，迁移对象和转换规则越多，测试就越关键。
除了更多的测试，没有其他东西能够取代测试。在项目上线之前，必须对整个数据迁移过程和上线本身进行至少一次演练。经验表明，一次测试时不够的。在与目标系统技术相同的SAP系统中，至少进行两次生产数据加载测试，在上线条件下，将对数据质量及遵循上线时间线产生积极影响。

测试降低成本
测试越多，数据质量越高，目标系统在上线前后需要进行的重复工作就越少，总成本也就越低。

3.2.5 数据校验阶段（Data Validation）

验证迁移的数据对于目标系统中业务流程的质量至关重要。高质量的主数据和交易数据是完美运行业务流程的基础。在某些行业，如制药业，验证时强制性的，并且必须进行精确的文档记录，如果没有做到，可能无法FDA的审计（影响美国市场销售药物产品或医疗器械）。
当你开始确定你的转换规则的时候也要开始确定你的校验规则。SAP Data Services的快速数据迁移包括预定义的验证规则，可帮助验证数据。自动验证能够通过检查验证结果来清理历史数据，并确定错误的数据记录和转换规则。
更多信息会在第八章，8.3.3和8.3.6中介绍。应该在集成测试阶段 (the integration tests phase) 和加载生产数据阶段 (after the productive load phase) 的早期阶段规划数据验证阶段 (Data Validation phase)。

3.2.6 数据清洗阶段 (Data cleansing)

数据清洗时迁移项目最容易低估的任务。如果可以，数据清洗应该在源系统完成。但确定的环境下，也可以在迁移工具中实现。例如，SAP Data Services有多种内置的数据质量程序和转换功能，可用于去重，地址清理，通过姓名检测性别代码等实用程序。通过使用定制的转换规则，可以将源数据记录中的错误可以转换为干净的转移数据。
你还应该使用自动验证的结果来清洗源系统中的数据，源系统中的数据越干净，目标系统中的数据就会越干净，流程也会运行的更顺畅。【