一个看似完美无缺的系统切换计划，很有可能将系统切换导向失败。
李明是ERP财务顾问，他目前正在实施的项目包括了几个主要的模块：财务、销售、库存、采购和生产。7月1日，项目经理召开项目组会议讨论系统切换计划。会议上明确了以下几个决定：1.8月1日新系统开始运行，在这之前结束仓库盘点;2.所有模块同时切换;3.鉴于客户方的强烈要求，第一个月新旧系统并行。由于看上去切换和财务的关系最大，所以项目经理要求李明在会议结束后编制一个详细的切换计划。
确定期初数据准备计划
图1 新旧系统的关系图
李明计划从期初数据的准备工作入手。李明想："情况稍微有点复杂，但还难不倒我。"他为期初数据处理确定了3个基本原则：1.新系统的期初数据必须和旧系统的数据完全一致;2.新系统的库存必须账实相符;3.切换前一天仍在执行过程中的销售订单需要作为期初销售订单输入系统。
按以上原则，李明整理出了旧系统和新系统的关系图。假如某笔销售订单只有部分发货，按账实相符的原则，在7月31日的期末库存中不应包括已经发货的产品。因此，在7月3l日，项目组必须进行一次完整的库存盘点，以检查出已发货却未入账的部分，随后根据盘点的结果更新旧财务系统的存货及相关其他科目。
由于ERP系统是分模块的集成系统，所以不同科目的期初余额是在不同的模块中分别输入的，系统自动更新到总账模块中。图1涉及到ERP库存管理模块、应收账款模块和总账模块。总账模块两边的箭头代表了自动更新总账。由于是分模块的输入，所以项目组专门设置了系统切换的过渡科目，作为所有科目输入时的对方科目。最后，当期初数据全部输入完毕后，该科目的余额应该结平。
当旧系统7月31日月末结账完成后，项目组将根据盘点的清单和财务上的商品价格，将库存的期初余额导入ERP系统的库存管理模块，同时将应收账款的明细科目导入应收账款模块，其他的科目也是分模块按各自的要求导入系统。图1中从旧财务系统到库存管理模块和应收账款模块的箭头以及从销售订单到销售模块的箭头就代表了这种导入的过程。由于旧系统的存货数据已根据实际盘点调整过，所以新系统的库存管理模块是账实相符的。
与此同时，对于7月31日未执行完毕的销售订单，也应当导入系统的销售模块，只是不能将整张订单导入，而是应当扣除7月31日以前已经发货的部分。图1左上方的箭头代表了期初销售订单的导入。
分析完期初数据的准备工作，李明觉得很满意，毕竟这看上去不太复杂，接下来应该是具体的切换计划了。
制定新旧系统切换计划
图2 计划的系统切换时间表
图2是李明设计的切换计划。在7月20日之前，关于库存地点以及所有的物料主数据必须都导入ERP系统。7月30日，也就是系统切换大盘点的前一天，盘点计划和盘点表格必须下发无误。7月31日停产一天正式盘点。8月1日盘点结束，财务人员汇总盘点结果，开始在旧系统上进行7月份的月末结账。月末结账预计耗费15天，到8月15日旧系统月末结账完毕。随后，信息技术部和财务部再花两天时间将旧系统的期初数据整理和转化成符合ERP系统导入的格式。这项工作将在8月1 7日完成，随后再花3天将期初数据批输入ERP系统。这时已经是8月20日。
由于在新系统上线的第一个月，也就是8月，新旧系统必须并行运行，所以财务部同时在两个系统中处理业务。与7月的月末结账的时间一样，旧系统在9月15日完成8月的月末结账。与此同时，从8月20日起，所有相关部门都开始在新的ERP系统中处理业务。这样经过一个月的时间，到9月20日，新系统8月也结账完毕。随后用5天时间完成新旧系统的对账。到了9月25日，整个系统切换工作将彻底完成。用户将完全在新的ERP系统中开始处理9月份的新业务。当然这时仍有25天的工作要追赶，但李明认为，经过了并行加上ERP的强大功能，再加上一点努力，完全可以顺利地追上20多天的业务。
李明的计划很顺利地通过了项目组的审定。激动人心的系统切换就要开始了。
主数据最先暴露出问题
事情从一开始就不太顺利。这个项目的一个特点就是，这家公司的物料主数据非常多，而且各个部门的物料编码规则是不同的。按计划，7月20日是主数据导入系统的最后一天，但是别说物料清单了，连物料主数据都没有整理完。为了在新系统运行前把主数据导入系统，项目组的部分物流顾问和关键用户也放下了用户接受程度测试工作，投入到数据的整理工作中。最后，项目组晚了两天才勉强把商品主数据批输入了系统，几个顾问和关键用户为此一连加了几天班。
7月31日，公司停产一天，开始全面的盘点。盘点进行得还算顺利，负责库存管理的顾问和关键用户也参与了监盘工具。他们回来后告诉项目经理和李明：情况挺好，只是仓管员们对整理后的物料编码还不太熟悉，基本上都是按名称和规格来盘的，而且发现很多没有编码的物料，只好临时用名称来记录。
8月14日，离预定的旧系统月末结账完成还有一天，李明真有点着急了。财务部告诉他，可能会来不及。这次上线把原来的一些问题全暴露出来了，比如说库存账实不符，财务部和库存部门的物料编码不同等。
8月17日，在晚了两天以后，财务部终于完成了旧系统7月份的结账。公司的信息技术部把旧财务系统的数据导成电子表格就交给李明，而没有做整理和导入。李明找到项目经理，几个顾问商量了一阵，决定与其争吵浪费时间，不如顾问自己做整理和导入。接下来的四天是没日没夜的。8月22日凌晨，所有的期初数据终于都批输入了系统，系统切换过渡科目也对平了。当然，在导入的过程中，碰到了不少问题，有些得不到的信息在输入时只能用虚拟资产、虚拟物料、虚拟利润中心等方式临时解决。不过到目前为止，只落后计划两天，大家都很有信心。
8月22日从凌晨开始，新系统停机做全备份，上午大部分的顾问都在睡觉。下午李明到财务部转了一圈，大家都忙着在旧系统中处理业务。财务经理说，新系统期初数据准备工作已经宣布完成了。不过大家今天都很忙，所以没空在新系统中处理业务。
8月23日项目经理召集项目组和各部门负责人开会，重申了时间要求：根据项目计划，我们现在已经落后了，新系统的输入必须立刻开始，9月20日前必须结束。但是各部门都抱怨说，最终用户实在没有技能也没有信心操作新系统，况且当初的培训和现在的实际操作是两码事。最后平衡的结果是：大部分的顾问都放下手头的事，全面投入用户支持工作，挑选一部分接受能力强的用户先开始新系统的输入，随后再推广到其他用户。
问题全面爆发
在8月24日之后的一个多星期里，项目组经历了真正的考验。
因为输入的都是8月份已经处理过的业务，所以这仅仅是输入，而不是业务流程处理。各部门在这个过渡阶段的衔接工作是原来没有考虑的。比如财务部要做销售订单开票，却发现仓管部门的该笔发货还没有追进去，而新的流程要求开票必须有相关的发货记录。这时，财务只能先跳过这笔业务。同样的，仓管部门在做发货时根本无法从旧的发货单上知道是新系统中哪张销售订单的货，幸好新系统的查询功能还不错，可以从销售的商品、客户等信息追踪查找销售订单，但是进度和准确性大打折扣。
期初销售订单的问题也很大。按计划，销售部门需要提供的期初销售订单是必须扣除7月31日以前已发货的剩余未执行部分。但是销售部和财务部不同，销售员们根本没有像财务人员这样严格的期间概念。很多的期初销售订单都没有扣除已发货部分或者扣错了，结果是期初销售订单可能会被重复发货。
当销售员开始录入新的销售订单时，主数据的问题暴露出来了。之前在准备客户主数据的时候，公司曾要求销售员将现有客户档案报给风险管理部统一整理和编号，但是很多销售员都没有报全。出于历史原因，公司的客户档案被销售员视做个人财产，在流程设计时考虑到了这种习惯。公司管理层和风险管理部有权限看到所有客户主数据，销售员之间是不共享客户数据的。除了7月底财务账上有的客户外，很多销售员没有提供其他客户的数据。现在销售员要在新系统中管理销售订单了，可是很多客户的主数据在新的ERP系统中都没有，因而货发不出去，销售员们怨声载道。没别的办法，项目组重新要求销售员上报客户数据，风险管理部加班加点地输入客户数据，由于太零散，也太急，批输入程序被放在一边，风险管理部的几个用户在销售员的催促下已经眼冒金星了。很多不完整的数据只能用缺省值应付了。
9月3日一早，项目组和各部门的负责人开会，讨论一个重要的决定：9月份还要并行。理由很简单：目前新系统8月的输入进展实在太缓慢了，什么时候能输完对完账谁都不敢说。现在放弃旧系统风险太大，没人负得起这个责任。
对于新系统大家已经不抱希望能够追上实际业务了，目前也只能把这次切换和上线作为对新系统的测试、验证和培训。最后决定在公司5个事业部中，挑选两个比较配合的部门进行重点突击，争取尽快输完8月份的数据，进入对账阶段。
总结对账难题 准备二次上线
10月8日对账正式开始了，财务部仍然没有人手可以提供，项目经理只好让所有的财务顾问都加入了对账。在开始之前，李明罗列了一下困难和注意事项。
1.因为所有模块同时切换，所以相当大的一部分财务凭证是通过集成自动生成的，而且在产品成本的核算方法上新旧系统还存在不同，因此无法通过新旧凭证的相互参照号来进行自动核对，只能用自上而下的方式核对，即试算平衡表→科目→凭证分组→凭证的方式检查。
2.项目组新旧系统的数据下载到电子表格后进行核对，发现错误不能直接在系统上修改，而要在系统外编制调整分录。这主要是因为参与对账的人多，而且是分科目对账的，不是记账的人自己在核对，所以如果直接更正系统，极有可能出现一个错误被重复更正的情形。
3.新旧系统的差异如何处理是一个不折不扣的难题。如果差异是新系统输入错误造成的，那最简单，只要调整新系统就行了。如果差异是旧系统输入错误造成的，问题就麻烦了。此外，由于凭证的数量巨大，而且又不是记账者自己对账，所以要找出所有差异的原因几乎是不可能的。因此，项目组只能参考审计中的重要性原则，找出重要的差异，对于小差异则直接编制调整分录。
4.如何处理调整分录，是一个伤脑筋的问题。比如由于产品成本核算方式不同造成的差异，通过报表可以解释差异和编制调整分录，但是在新系统中如何调整呢?一种方法是根据旧系统的产品成本在新系统中重估库存，但是这样做的工作量是相当大的;另一种方法是直接在财务上调整，作类似商品成本差异科目处理，但是这种做法在以后的月份中还是要考虑它的分摊，等于将工作量向后移了。不过在这个项目中李明还不用太苦恼，因为并行已经变成了测试，只要找到重要的差异，编制调整分录将新旧系统报表调平，对账报告双方签字确认就可以了。计划中的五天对账显然大大低估了对账的工作量，虽然5个事业部只对两个，项目组仍然花了3个星期才完成了对账报告。
在10月的最后几天，终于对平了两个事业部8月的账。接下来怎么办?项目组决定用几个星期的时间重新整理流程和主数据，培训用户，随后清空系统，准备做第二次切换和上线。希望第二次切换将是崭新的和成功的。
(本文中提到的人名为化名。)
数据导入的策略
数据导入的策略是指采用什么方式进行数据的导入。结合不同的导入方法，主要有一次导入、分次导入、先录后迁、先迁后补等几种方式可供选择。
一次导入是通过数据导入工具或导入程序，将需要的历史数据一次性全部导入到新系统中。一次导入的优点是导入实施的过程短，相对分次导入，导入时涉及的问题少，风险相对比较低。其缺点是工作强度比较大，由于实施导入的人员需要一直监控导入的过程，如果导入所需的时间比较长，工作人员会很疲劳。
分次导入是通过数据导入工具或导入程序，将需要的历史数据分几次导入到新系统中。分次导入可以将任务分开，有效地解决了数据量大和宕机时间短之间的矛盾。但是分次切换导致数据多次合并，增加了出错的概率，同时为了保持整体数据的一致性，分次导入时需要对先切换的数据进行同步，增加了导入的复杂度。分次导入一般在系统切换前先导入静态数据和变化不频繁的数据，例如代码、用户信息等，然后在系统切换时导入动态数据，例如交易信息。
先录后迁是在系统切换前，先通过手工把一些数据录入到新系统中，系统切换时再导入其他的历史数据。先录后迁主要针对新旧系统数据结构存在特定差异的情况，即对于新系统启用时必需的期初数据，无法从现有的历史数据中得到。对于这部分期初数据，就可以在系统切换前通过手工录入。
先迁后补是指在系统切换前通过数据导入工具或导入程序，将原始数据导入到新系统中，然后通过新系统的相关功能，或为此专门编写的配套程序，根据已经导入到新系统中的原始数据，生成所需要的结果数据。先迁后补可以减少导入的数据量。
