天下大势,合久必分,分久必合。公司架构近些年也变了几回，一些部门机构分分合合，SAP系统当然就跟着折腾了。最近SAP系统就进行了精简，合并了两个工厂，把B工厂并入A工厂。
当合并这个问题摆上议事日程的时候，某领导问，为什么当初上系统的时候就不这样做呢？非得到现在才又破土动工？然后，一个经理级的关键用户答道：当初咱公司的架构那两厂归属两个不同的事业部，还是您老人家设计的，要分两个工厂。呵呵呵呵……
那就并呗。
首先，是各模块的合并测试，用了5个各种类型的产品从基础数据维护开始，到SD，PP，MM，CO，FI。由于合并的两个工厂在同一公司，SD基本上没有什么变化。PP的变更最多。其次是MM。一轮测试下来，各模块对要做的事情都有了清单，风险也能预计出来。
然后，是成立合并项目，各模块安排变更资料整理的时间进度安排和人员安排。同时，确立系统切换的时间点和切换期间注意的事项。由于离目标完成的时间较紧，变更资料的整理各模块并行，并且决定不在测试系统试导全部变更资料，资料整理后直接导入生产机。
系统的合并变更操作，选择了系统停用三天，集中导入各模块变更资料和修改配置。
第1天，导入主数据，这时候发现，没有在测试系统整批试导的问题出现了，批导时有好些数据有问题，幸而都不是大问题，可以即时修正。但仅MM01的导入就花了近一天的时间。
第2天，导入物料清单和工艺路线，以及MM模块的采购数据。这时，又出现了一些异常，那些物料主数据从B工厂扩往A工厂时，被资料整理的关键用户去掉了一大片，但是后面的BOM/ROUTING和货源/信息记录却没有得到消息，按旧资料整理；还有是主数据的扩充有其它各种各样的错漏等等，导致后面的数据导入时出现了错误。要对扩充的主数据重新检查和对后面的批导数据进行匹配。而送导的资料，亦大都存在问题，是因为，没有做到足够的过滤和匹配。比如删除物料没有去除等等。
第3天，纷纷扰扰的数据导入终于完成，但是，在成本估算又发现了一些问题，将发现的问题查找更正后，第3天的夜幕已经降临。而在这三天里，合并的工厂提出，系统不能一次切换，原在B工厂的业务要维持一周，一周后清得差不多的时候再切清。所以，原本要批量转移的库存就没有在这3天里转移，让他们用301自个在上线后缺料时转来转去。
第4天的重开系统，前期的功夫就得到了考验，物料清单的错误，工艺路线的错误，新物料库位没有扩充，生产订单类型未配足，合并后流程变更的差异等，都在开系统后一个一个的修补，但大问题是没有的。总体感觉，还是没有大的失误。只是在一些细节的问题上出现了一些差异。
接下来的一周，是两个工厂同时运作的一周，A、B工厂会有一些物料完全相同的业务存在，而主要任务是努力清掉B工厂的业务数据。一周后，是星期天也是月末，B工厂的生产订单全部结清，整理出所有B工厂的库存，包括自有库存和供应商库存，全部在这一天批量移库到A工厂。B工厂所有物料的库存为0。从次日起，B工厂不再做业务。
又接下来的一周，是清理B工厂残留数据的时间，结掉所有未交清的采购订单，清掉所有被锁定的需求。
最后，停掉B工厂的MRP运算。项目结束。
而在FI模块，还会按自然运作，将未做发校验的PO做校验和应付等。
整个过程，从测试到结束，用了两个月，但在前期，由于项目缺乏全局的组织安排，测试完成后，数据整理很晚才开始，其实数据整理只用了20天。
做完合并，发觉这些改进相对于系统上线，是小儿科。但是儿科虽小，却是全科，哪一块没有照顾到，都会出问题，并影响后面的运作。而改进项目的成员，全部是在岗人员兼的，而且都是分头行事，往往会出现各家自扫门前雪的情况，只顾自己的要的资料，缺乏对整个系统的影响的考虑，在问题的沟通上出现欠缺。在合并的第一天，也才发现有很多人没有A工厂的权限，一批一批的给他们开。然后又发现有人错误操作，业务做在了B工厂，又一批一批的给他们除掉B工厂的权限，应该考虑的因素还是少了。
经一事，长一智，此记。
