为了使数据迁移项目能够成功实施,不仅必须去确保数据迁移本身的技术正确性,还必须能够保证迁移后数据的质量。
关于提到的一些名词的简单解释:
源系统(legacy system):遗留系统,也就是迁移数据的来源系统,后文中我都写成了源系统
目标系统(SAP) :未来要使用的S4系统,数据迁移到的目标系统。
历史数据(legacy data) : 遗留数据,是在源系统中存在的全部历史数据,可能需要迁移,也可能不需要。
休眠数据(dormant data):在源系统及目标系统的运营业务中不会使用的数据。
冗余的数据(Redundant legacy data):同一个数据重复出现,属于休眠数据的一种>。
自定义配置(customizing):IMG中根据公司蓝图进行的配置。(本人觉得书中提到的customizing是指IMG中进行的配置,而不是自开发程序,因为书中自开发通常使用的是custom program)
1.1 数据迁移作为独立子项目
在大部分的项目中,迁移并没有得到足够得重视.项目经理大部分时间也没意识到,迁移会占用项目资源及预算。当数据迁移的技术只掌握在一部分人范围内的时候,人员配置平静就会产生。因为,经常使用自开发数据传输程序,所以开发人员的缺乏是造成瓶颈的主要原因,因此要减少自开发,这样数据迁移就不仅仅是开发人员的责任,那些没有复杂开发能力的人员也可以引入到迁移项目,减少人员瓶颈。
另一个重要的方面是数据迁移的数据质量。例如未清项,不论是余额还是行项目,在源系统及目标系统都需要保持一致。因为数据迁移作为后续业务流程的基础,还需要迁移看上去不相关但可能是控制数据信息,以确保下游的流程能正常处理。
所以,仅仅确保迁移数据在数量上的完整是不够的,还需要调查迁移后的数据是否可以确保目标系统能够处理后续的运营交易,以及是否具有决策过程所需的信息。在未清项的这个例子中,意味着除了验证金额是否正确之外,还必须确保付款截至日期的计算正确,因为他可能直接影响企业的流动资金计划。缺少或者不正确的信息,可能会导致决策失误。
综上,我们建议数据迁移是一个迭代的过程。这意味着你可以在第一次从源系统抽取数据后就开始测试,并在目标系统中进行开发允许数据迁移(第三正会介绍细节)。基于初始迁移结果,可以在接下来的步骤中检查是否所有的数据都是后续流程运转必须的。这包含全面的系统测试和潜在的自定义配置。如果信息确实了,必须确认从哪获得这些信息,并重复迁移过程直到达成想要的结果。需要注意的是不能孤立的进行数据迁移和业务流程测试,这两个任务是密不可分的。
鉴于数据迁移在项目实施过程中的重要性,建议负责数据迁移的团队尽早处理源系统中的流程,并研究如何在目标系统中映射这些流程,特别如果在目标系统中进行业务系统流程重构。因为没有人比用户更了解源系统,所以他们应该从一开始就参与到项目中,以预防该领域的人员配置瓶颈。通过这种方法,用户部门的工作人员将熟悉目标系统,并能够更好地确定必须提供哪些数据以确保系统顺利迁移。
1.2 初步考虑
在项目开始时,可以根据源系统确定初步考虑因素,而无需详细了解目标系统。包括定义迁移的数据集,识别可能不需要迁移的历史数据,减少迁移数据 量可以采取的步骤,数据提取的准备工作,以及有关记账数据的一些特殊注意事项。
1.2.1 确定迁移的数据集
迁移的数据可以分为主数据和交易数据。
主数据
主数据包含了长时间保持不变,且为了相同的目的而需要的信息。当然只有迁移实际使用的主数据才有意义。那些休眠数据(详见1.2.2),即在运营过程中没有使用的数据,应该在源系统中标记为休眠,并且不进行迁移。
交易数据
交易数据的生命周期短,并且可以分配给特殊的主数据。交易数据有时也被称作过账凭证(posting document)。在迁移时,需要澄清源系统的历史数据需要迁移到目标系统的明细程度。具体而言,需要确定迁移的凭证是按照行项目还是余额。如果决定迁移行项目,需要确定迁移的会计年度,哪些已清项也需要迁移行项目;如果决定迁移余额,那么源系统在过渡阶段,需要保证可以查询历史的明细信息。<