ERP系统的切换

ERP系统切换

ERP实施的过程好比构筑一座崭新的城市。这座城市干净整洁，工商娱乐教育一应俱全且功能强大，交通异常便捷… … 。你充满希望地构筑它，希望早一天离开你现在居住的早已拥挤混乱的村落。但是这座城市建在河的对岸，随着完工日期一天天地临近，你发现隔在中间的河又宽又深，要让你的子民安然地迁徙到新家去事实上远比想象的困难。从旧系统向ERP系统的切换就象渡河搬家。事实上很多ERP项目在一直走完系统配置和测试时看上去都还顺利，但在渡河搬家时被淹了个半死。

ERP系统

难点

概括地说，ERP系统切换有以下难点：

1. 集成。ERP是一个集成的系统，销售，储运，采购，生产，会计，资金这些模块和功能不是简单的加法，它们之间是衔接和连贯的。对于日常运作和企业管理，集成具有不可比拟的优点。但是在系统切换时集成意味着更复杂的切换计划和对指挥协调工作更高的

要求。

2. 多模块。作为上述难点的推论是：上线的模块和功能越多越复杂，系统切换的困难也就越大，而且难度是成倍增加的。打个比方：2条线相交是1个交点，3条线相交就是3个交点，4条线就是6个交点，再往后是10，15，21… … 集成点会随着模块和功能成倍增加。而且即使使用同样的模块，由于ERP系统是可配置的，不同公司也会设计出不同的流程。再加上每家公司的实际情况都不相同，这就使得几乎每家公司的系统切换方式都会有所不同。包治百病的灵丹妙药是不存在的。

3. 旧系统。旧系统的数据一般质量较低也较分散（这是可以肯定的，否则也不会有实施ERP的需求）。但是在向ERP系统切换时需要的主数据和期初数据，相当大的部分需要通过加工旧系统数据获得。因此从这个方面说系统切换的难度完全取决于旧系统的质量。这里需要解释几个概念：<1>旧系统，并不单指企业目前正在使用的计算机系统，如果你的仓储部门仍然在用手工做台帐，或者你的财务部没有使用任何会计软件，那么这些手工帐也是你的旧系统的一部分。<2>主数据和期初数据，系统切换最重要的工作之一是数据的转换。这主要包含两大类数据。比如总帐科目（G/L account master），物料主数据（Material master），物料清单（Bill of materials），供应商主数据（Vendor master），客户主数据（Customer master），工艺路线（Routings），采购信息记录（Purchase information records），销售定价记录（Condition records (pricing)）等等是属于主数据。而象期初采购申请（Open purchase requisitions），期初销售定单（Open sales orders），期初应收应付发票(Open A/R and Open A/P invoices)，期初总帐余额（Open G/L account balances），期初库存（Open stocks）都是期初数据。这两者共同构成了ERP系统数据的起点。

4. 旧流程。为什么旧的流程还会影响ERP系统？道理很简单，因为旧的流程会影响期

初数据。比如旧的流程是始终先发货，随后紧接着开票和入帐，还是允许先开票和入帐，以后再发货或客户提货？这会直接影响期初销售定单和期初库存。旧流程越不规范统一，系统切换时就越麻烦。

5. 指挥。困难都是相对的，它遇到卓越的指挥会变得很谦卑，而对于拙劣的指挥它会非常强大。事实上ERP系统切换决不仅仅是实施项目组的任务，它涉及企业很多部门（究竟有多少取决于实施的模块和功能），因此对于这场战役的指挥是否成功，取决于指挥官的权柄和能力，取决于部门间的责任和配合，也取决于整个公司的文化。但不幸的是旧系统和旧流程很混乱的企业，在ERP实施中项目组得到的支持往往也较少。而企业管理高层的支持无疑是有效指挥的前提条件。

6. 士气。我们内心深处都恐惧变化，除非这些变化能给我们看得见的好处。很明显的一点是：并不是所有的人都愿意搬到河对岸的新城市去。如果搬家意味着几个月加倍的劳动，艰苦的学习和适应，而自己连半句赞扬和肯定都得不到，换了是你，你愿意吗？如果说在项目前期，实施主体是项目组（包括顾问和关键用户），客户方的不足可以由实施顾问方弥补，在系统切换阶段，客户方的很多工作则是外界无法替换的。此时士气低落意味着时间和数据质量上的失控，无论哪种情况，对于系统切换而言都是致命的打击。

7. 并行。系统切换在时间上有严格的要求。在系统切换的这段时间里，有三样东西可能是并行的：业务，旧系统和新系统。几乎没有公司会为了ERP上线停止业务，因此业务的处理始终在进行之中。那么对于这段时间业务的记录是使用旧系统，还是新系统？这是一个艰难的选择。如果选择新旧系统并行，那所有相关人员的工作就被加倍了，此外两套系统并行必然涉及到对帐的问题。此时系统切换的难度更增加了。这一点放在最后并不意味着它不重要，相反地，我们的个人观点是：并行问题成为困扰我国ERP系统切换的头号问题。我们在下文还会有专门的探讨。

上面我们介绍了一下ERP系统切换面对的困难。就好比没有两片树页是完全一样的，每家企业的实际情况相差会很大。我们在制定上线计划时一定要对上述问题有一个全面的了解，见招拆招，而不能生搬硬套。

切换计划

下面这个事例会有助于大家理解系统切换的过程：李明是ERP财务顾问，他目前正在实施的项目包括了几个主要的模块：财务，销售，库存，采购和生产。7月1日，项目经理召开项目组会议讨论系统切换计划。会议上明确了以下几个决定：<1> 以8月1日作为本次切换点。<2> 所有模块同时切换。<3>鉴于客户方的强烈要求，第一个月新旧系统需并行运行。由于看上去切换和财务的关系最大，所以项目经理要求李明在会议结束后编制一个详细的切换计划。由于篇幅所限，我们下文的介绍只是整个计划的一部分：和销售相关联的切换计划。

期初数据

李明的计划首先从期初数据的准备工作入手。“情况稍微有点复杂，但是还难不倒我”李明想。首先必须兼顾到以下一些问题：

1． 新系统的期初数据必须和旧系统的完全一致

2． 新系统的库存必须帐实相符

3． 7月31日仍在执行过程中的销售定单需要作为期初销售定单输入系统

销售定单销售发货销售收款销售开票销售部ERP销售模块仓库 旧财务系统银行存款 XXX应收帐款 XXX存货 XXX ERP库存管理模块商品编码 数量 单价 总价 库存地点 ...WM625 500台 3,000 1,500,000元 金桥仓库001 …RF868 1,000台 4,000 4,000,000元 外高桥仓库011 …… …… … ERP应收帐款模块客户 发票号 金额 付款条款 ...AAA公司 No.11111 117,000 30天到期 ...AAA公司 No.11112 234,000 60天到期 ...BBB公司 No.22222 300,000 30天到期 ... ERP总帐模块银行存款 XXX应收帐款 XXX存货 XXX… …系统切换过渡科目 0… …图1：期初数据 图一是从系统切换的角度来看业务，旧系统和新系统的关系。图一上方是在系统切换日，即7月31日仍未执行完毕的销售定单。假如某笔销售定单部分发货，那么在7月31日的期末库存中将不包括已经发货的产品。我们在7月31日必须进行一次完整的库存盘点，随后根据盘点的结果更新旧财务系统的存货及相关其他科目，图一中绿色的箭头代表了这一过程。

由于ERP系统是分模块的集成系统，所以不同科目的期初余额是在不同的模块中分别输入的，随后系统自动更新到总帐模块中，图一下方是本例中涉及的ERP库存管理模块，应收帐款模块和总帐模块。红色的箭头代表了自动更新总帐。由于是分模块的输入，所以我们专门设置“系统切换过渡科目”，作为所有科目输入时的对方科目。最后当期初数据全部输入完毕后，该科目的余额应该结平。

当旧系统7月31日月末结帐完成后，我们将根据盘点的清单和财务上的商品价格，将库存的期初余额导入ERP系统的库存管理模块。同时应收帐款的明细科目（明细到未清发票或预付款）导入应收帐款模块。其他的科目也是分模块按各自的要求导入ERP系统。图一中兰色的箭头代表了这种导入的过程。由于旧系统的存货数据已根据实际盘点调整过，所以新系统的库存管理模块的出发点是帐实相符的（图一中的红色虚线）。

与此同时，对于7月31日未执行完毕的销售定单，也应当导入系统的销售模块。只是不能将整张定单导入，而是应当扣除7月31日以前已经发货的部分。图一左侧的兰色箭头代表了期初销售定单（Open sales order）的导入。

好了，分析完期初数据的准备工作，李明觉得很满意，毕竟这看上去不太复杂。接下来应该是具体的切换计划了。

计划

图二是李明设计的切换计划。首先在7月20日之前关于库存地点的系统配置以及所有的物料主数据必须都导入ERP系统。7月30日也就是系统切换前大盘点的前一天，盘点计划和盘点表格必须已下发无误。7月31日停产一天正式盘点。8月1日盘点结束，财务人员汇总盘点结果，开始7月份的旧系统月末结帐。月末结帐预计耗费15天，到8月15日旧系统月末结帐完毕。随后信息技术部和财务部再花2天时间将旧系统的期初数据整理和转化成符合ERP系统导入的格式。这项工作将在8月17日完成，随后再花3天将期初数据批输入ERP系统。这是已经是8月20日。

旧财务系统银行存款 XXX应收帐款 XXX存货 XXX转换格式的期初数据完成… …旧系统月末结帐仓库盘点结束,汇总结果下发盘点计划和表格2001.07.202001.07.302001.08.012001.08.202001.08.152001.08.17ERP期初数据批输入完成旧系统数据输入完毕2001.09.152001.09.20ERP系统数据输入完毕2001.09.25对帐完成库存地点和商品主数据输入ERP ERP库存管理模块WM625 500台 3,000 金桥仓库001… ... ERP应收帐款模块AAA公司 No.11111 117,000… … ERP总帐模块银行存款 XXX应收帐款 XXX存货 XXX… …系统切换过渡科目 0图2：切换计划 由于第一个月，也就是8月，新旧系统必须并行运行，所以财务部从8月1日起就继续在旧系统中处理业务。这样和7月结帐的时间一样，旧系统在9月15日完成8月的月末结帐。与此同时从8月20日开始所有相关部门都开始在新的ERP系统中处理业务，这样经过31天到9月20日新系统8月也结帐完毕。随后用5天时间完成新旧系统的对帐。到了9月25日整个系统切换工作将彻底完成。我们将完全在新的ERP系统中开始处理9月份的新业务，当然这时仍有25天的工作要追赶，但是经过了并行，加上ERP的强大功能，再加上一点努力，完全可以顺利地追上20多天的业务。

李明的计划很顺利地通过了项目组的审定。激动人心的系统切换就要开始了！

切换

7月20日 事情从一开始就不太顺利，这个项目的一个特点就是这家公司的物料主数

据非常多，而且各个部门的编码有很多是不同的。按计划今天是主数据导入系统的最后一天，但是别说物料清单（BOM），目前连物料主数据还没有整理完。项目组和相关的部门领导开了紧急会议，最后制定了紧急计划：5天内完成物料主数据的整理工作，再用20天完成物料清单的整理，一定要在8月20日新系统运行前导入系统。项目组的部分物流顾问和关键用户也放下了用户接受测试（User Acceptance Testing），投入到数据的整理工作里。最后又晚了两天才勉强把商品主数据批输入了系统，几个顾问和关键用户一连加了几天班。但是库存管理部门已经来不及按整理后的物料编码来准备所有的盘点表格了，几个变化最大的仓库只能直接用整理之前的编码做出盘点表格，有些物料甚至没有编码，只写了名称和规格。

7月31日 公司停产一天，开始全面的盘点。盘点进行得还算顺利，负责库存管理的顾问和关键用户也参加了监盘。他们回来后告诉项目经理和李明：情况挺好，只是仓管员们对整理后的物料编码还不太熟悉，基本上都是按名称和规格来盘的，而且发现好多没有编码的物料，只好临时用名称来记录。盘点表已经整理完毕，不过估计财务部使用这些盘点表的时候会有困难。项目经理提醒李明在财务部结帐的这段时间多去看看。

8月14日 离预定的旧系统月末结帐完成还有一天，李明真有点着急了，财务部告诉他，可能会来不及。这次上线把原来的一些问题全端到了台面上：比如说库存帐实不符，财务部和库存部门的物料编码不同等等。这次光是核对和整理盘点报告就多花了一周，新整理的物料编码错漏重复不少，而且两个部门都不太熟悉，特别是对于顾问整理的相当大的部分，客户方颇有微词。同时财务经理告诉李明，最后盘点结果，帐实不符的比例可能相当大，几乎占了总库存的20%。当李明问起原因时，财务经理面露难色，说：“不太好说。不过我们不赞成全部算盘盈盘亏，再说税务局也不会同意。所以最好是挂帐。”李明没有办法只好同意。不过为了挂帐的需要，他又建了几个科目，因为原来的存货科目是不允许财务手工更改的。

8月17日 在晚了两天以后，财务部终于完成了旧系统7月份的结帐。客户的信息技术部把旧财务系统的数据导入了电子表格就交给了李明。这时是8月18日星期六，信息技术部的刘工还闹了个老大不高兴。李明找到项目经理，几个顾问商量了一阵，决定与其争吵浪费时间，不如顾问自己做整理和导入。接下来的四天是没日没夜的。好在李明的准备工作做得不错，新旧科目对照表，新旧客户编码对照表，新旧供应商编码对照表等等都在关键用户的合作下准备好了。存货清单是财务部根据盘点结果和财务数据整理的，和财务帐面的差异的确很大，都转入了挂帐科目。销售部门也提供了未清销售定单的数据，负责销售模块的顾问在负责导入新系统。8月22日凌晨，所有的期初数据终于都批输入了系统，系统切换过渡科目也对平了。此时几乎所有的顾问都已是精疲力竭，不过大家都很高兴，成功仿佛就在眼前。当然，在导入的过程中，碰到了不少问题，有些得不到的信息在输入时只能用“虚拟资产”，“虚拟物料”“虚拟利润中心”等等方式临时解决。不过到目前为止，只落后计划两天，大家都很有信心。

8月22日 从凌晨开始新系统停机做全备份，上午大部分的顾问都在睡觉。下午李明到财务部转了一圈，大家都忙着在旧系统中处理业务。财务经理说，新系统期初数据完成已经宣布了。不过大家今天都很忙，所以没空在新系统中处理业务，再说对新系统也不熟，培训是几个星期前做的，现在都还给老师了。李明问了一下负责物流的顾问们，情况也是如此。

8月23日 项目经理召集项目组和各部门负责人，重申根据项目计划我们现在已经落后了，新系统的输入必须立刻开始，9月20日前必须结束。但是各部门都抱怨说，最终用户实在没有技能也没有信心操作新系统，况且当初的培训和现在的实际操作是两码事。最后平衡的结果是：大部分的顾问都放下手头的事，全面投入用户支持，挑选一部分接受能力强的用户先开始新系统的输入，随后再推广到和支持其他用户。项目经理又召集了顾问们：必须强行推进项目，明天一定要开始输入，哪怕以后这段时间天天坐在用户旁边。

8月24日 在随后的一个多星期里，项目组经历了真正的考验，输入工作从一开始就面临了困难：

1． 因为输入的都是8月份已经处理过的业务，所以这仅仅是输入，而不是业务流程处理。部门间如何在这个过渡阶段衔接是原来没有考虑到的。比如财务部要做销售定单开票，却发现仓管部门的该笔发货还没有追进去，而新的流程要求开票必须有相关的发货记录。这时财务只能先跳过这笔业务。第一天李明坐在财务部赵强旁边，一连五六张都是这样做不过去，赵强已经唉声叹气了，李明强作镇定，换了一本费用的凭证，才得以开始。同样的仓管部门在做发货时根本无法从旧的发货单上知道是新系统中哪张销售定单的货，幸好新系统的查询功能还不错，可以从销售的商品，客户等等查找销售定单，但是进度和准缺性大打折扣。同时也有很多发货单所对应的销售定单销售部尚未输入。

2． 期初销售定单的问题在第一天就发现了，按计划销售部门需要提供的期初销售定单是必须扣除7月31日以前已发货部分的剩余未执行部分。但是销售部和财务部不同，销售员们根本没有象财务这样严格的期间概念。很多的期初销售定单都没有扣除已发货部分或者扣错了。结果是期初销售定单可能会被重复发货。和期初销售定单相关的业务被暂停处理。销售员被要求重新检查期初销售定单，顾问和关键用户也忙着帮忙手工更正那些原来是批输入的期初定单。仓管员们和财务部被要求特别留神期初定单。但是错误看来还是难以避免的。

3． 当销售员开始录入新的销售定单时，客户主数据的问题暴露出来了。之前在准备客户主数据的时候，曾要求销售员将现有客户档案报给风险管理部统一整理和编号。但是很多销售员都没有报全。当然出于历史原因，该公司的客户档案被销售员视做个人财产。在流程设计时考虑到了这种习惯，虽然公司管理层和风险管理部有权限看到所有客户主数据，但是销售员之间是不共享客户数据的。但是没想到抵触仍然那么大，很多销售员除了

7月底财务帐上有的客户外，其他一律没有提供。现在要在新系统中管理销售定单了，可是很多客户的主数据在新的ERP系统中都没有，货发不出去，销售员们怨声载道。没别的办法，项目组重新要求销售员上报客户数据，风险管理部加班加点地输入客户数据，由于太零散，也太急，批输入程序被放在一边，风险管理部的几个用户在销售员的催避下已经输得眼冒金星了。很多数据不完整的只能用缺省值应付了。李明在系统中看了一下客户清单，发现很多名称相近的，怀疑是重复编码了。他报告了项目经理和用户。项目经理叹了口气：“等过了这阵再清理吧。”

4． 输入的第三天负责库存管理的顾问急冲冲地跑来找李明，仓管员发现很多发货在系统中无法输入，原因是这样的：比如7月31日财务部已经开票，但是客户尚未提货或仓库尚未发货的情况下，财务已经在帐上做了结转成本和确认收入，这样期初销售定单中应该已扣除了这笔帐面上的发货。所以现在实际要发货时找不到任何对应的销售定单。李明立即去问了客户的财务经理，回答是：“确实存在这种情况，而且数量是比较大的。此外相反的情况也是存在的，比如有些货已经发了，但是发票还没有开，所以这些货在帐上仍然存在。这些是为什么库存帐实不符的重要原因。”李明说：“现在我们必须把这两种情况的数量都清理出来，重新调整期初库存，开票未提的库存做无帐面价值的处理，发货未开票的做虚拟库存商品。”财务经理摇摇头：“不可能，现在根本没有时间和人手整理。”最后折衷的方案是：对于开票未提，在系统中另外配置一种物料移动类型，财务上的自动记帐设为直接冲期初盘点帐实不符的挂帐科目。对于发货未开票的情况，实际结转成本时由财务部直接从挂帐科目中转出。等过一段时间这些历史情况都处理完毕后，如果挂帐科目的余额不显著，就认为是实际盘盈或盘亏结转费用，目前暂定为3个月。顾问和关键用户们马不停蹄地更改系统配置，重新培训仓管员和财务。李明心中隐隐的不安：“仓管员们如何区分哪些发货是期初开票未提，哪些是销售部还没来得及追入系统的销售定单发货。再说如果期初销售定单仍然包括了这些开票未提货，那仓管员将错就错地发货，挂帐科目企不是总也消不掉？” 不过他实在太累了，只能把这些问题放在一边又去干别的了。

5． 这几天还有另一件事令李明非常烦心：从流程上说，财务往往在最后阶段，往往前面的步骤出错到了财务这边就过不去了，比如销售员追进去的销售定单及开票申请的价格错了，等财务追开票过帐时被发现了，随后遍寻不着那个销售员，这又大大地影响了财务部的进度，财务部已经被批评了好几次了，真是百口莫辩。最后李明对财务说如果错误确定的话就直接改物流的单据吧。但是财务人员大都没有这样的权限，也没有培训过物流模块。李明只好一边加权限，一边教，大部分时间还自己直接改物流单据。项目经理对李明说最好不要自己改权限，也不要自己改物流单据，应该走流程。李明只好苦笑。

6． 很多流程被发现存在问题，有些流程还被忽略了，各种配置和主数据也发现各种各样的问题。本来有些配置和主数据的更改应该走流程解决，但是由于关键用户和最终用户的训练不足，现在都直接反映到了顾问这里。一边支持用户，一边更改配置，李明和他的同事们已经快不行了。而用户们都在抱怨朝令夕改，永远跟不上变化。

7． 不满的暗流在整个公司扩散。有些从一开始就抵触的销售员变得更加肆无忌惮，不会操作或不愿操作新系统被光荣地挂在嘴边。连原来支持的此时也禁声了。一个业务员发给李明一篇文章，标题是类似ERP实施成功率为零之类的，是从网上下载的，作者是某国际知名管理咨询公司的C什么O。据说这篇文章已经传遍了全公司。李明怒火中烧。

8． 吃午饭的时候，李明遇到了赵强，赵强是最早熟练操作系统的财务，所以李明已经好多天没有去赵强那里了。李明问赵强情况怎么样。赵强说：“苦死了，这个月从月初准备期初数据开始，几乎天天加班，周末也加班，屁股都象黏在凳子上了。系统要输两套，工资倒不发两份，输慢了还要挨骂… …”。李明无言以对，自己也不知道为什么竟然会感到内疚。

… …

出现的问题几乎数不胜数，其他的模块情况也好不到哪里去，可能还更糟。负责生产计划的顾问就说由于销售定单的问题和物料清单的不准确，现在运行MRP的结果实在没法用，况且由于是在追数据，采购和生产目前也用不上新系统的结果，照单据输就是了。

项目经理问李明照目前的情况，将来对帐会不会有问题。李明说：肯定有问题，不过现在顾不了了。

9月3日 星期一一早，项目组和各部门的负责人开会，讨论一个重要的决定：9月份还要不要并行。几乎没有什么争论就做出了决定：9月份继续并行。理由很简单：目前新系统8月的输入进展实在太缓慢了，什么时候能输完对完帐谁都不敢说。现在放弃旧系统，风险太大，没人负得起这个责任。

对于新系统大家已经不抱希望能够追上实际业务了，目前也只能把这次切换和上线作为一次新系统的测试，验证和培训。所以最后决定在公司5个事业部中，挑选两个比较配合比较顺利的重点突击，争取尽快输完8月份的数据，进入对帐。好在这5个事业部在内部都是相对独立核算的。

9月29日 差不多一个月的时间，项目组所有力量都投入到了两个选定的事业部。终于赶在国庆节前完成了这两个事业部8月份的数据输入。但是其他3个事业部的输入工作几乎全放了羊。“算了吧，等放完假回来再对帐吧。”李明收拾行李准备回家，“项目要做，命也得要。”

10月8日 对帐正式开始了，财务部仍然没有人手可以提供，只好所有的财务顾问都加入了对帐。在开始之前，李明罗列了一下困难和注意事项：

1． 因为所有模块同时切换，所以相当大部分的财务凭证是通过集成自动生成的，而且在产品成本的核算方法上新旧系统还存在不同，因此无法通过新旧凭证的相互参照号用自己开发的工具软件自动核对（这种方式称为自下而上的方式），只能用自上而下的方式核对，即试算平衡表->科目->凭证分组->凭证的方式检查，对于有些科目如产成品，主营业务成本还要为对帐开发额外的报表。

2． 新旧系统的数据下载到电子表格后进行核对，发现错误时不能直接更改系统，而是在系统外编制调整分录，这主要是因为参与对帐的人多，而且是分科目对的，而且又不是记帐的人本身，所以如果直接更正系统，极有可能一个错误被重复更正。调整分录的清单是共享的。

3． 对于新旧系统的差异如何处理是一个不折不扣的难题。如果差异是新系统输入错误造成的，那最简单，只要调整新系统就行了。但是如果是旧系统输入错误造成的，问题就来了，因为并行阶段一般是以旧系统为主，在这个项目中就更是如此了，但是旧系统8月已经结帐，按照规定对8月的调整应该做在发现错误的月份，只要还在本年度。所以对帐时只能将错误记录下来，更正到旧系统的10月份，对帐调整分录仍然是调整新系统。对于因为会计制度变更或核算方式调整造成的差异，更正是不可行的，只能通过报告解释原因，随后编制调整分录调整新系统。此外，由于凭证的数量巨大，而且又不是记帐者自己对帐，所以要找出所有差异的原因几乎是不可能的。只能参考审计中的重要性原则，找出重要的差异，对于小差异直接编制调整分录了。

4． 对于调整分录如何处理，又是伤脑筋的问题。比如由于产品成本核算方式不同造成的差异，通过报表可以解释差异和编制调整分录，但是在新系统中如何调整呢？一种方法是根据旧系统的产品成本在新系统中重估库存，但是这样做的工作量是相当大的。另一种方法是直接在财务上调整，作类似商品成本差异科目处理，但是这样做法在以后的月

份中还是要考虑它的分摊，等于将工作量向后移了。此外对于没有找到原因的小差异，直接调整新系统将受到内部和外部的质疑，毕竟所有的凭证都应当有原始支持凭证。不过在这个项目中李明还不用太苦恼，因为并行已经变成了测试，只要找到重要的差异，编制调整分录将新旧系统报表调平，对帐报告双方签字确认就可以了。

计划中的五天对帐显然大大低估了对帐的工作量，虽然5个事业部只对2个，项目组仍然花了3个星期才通过了对帐报告。项目室里堆满了凭证，顾问和关键用户显得虚弱而亢奋。

10月29日 在10月的最后几天，终于对平了两个事业部8月的帐。接下来怎么办？项目组决定用几个星期的时间重新整理流程和主数据，培训用户，随后清空系统，做第二次切换和上线。当然这次的切换将是崭新的和成功的。ERP的彼岸就在眼前了。

重要的说明

李明的项目只是千奇百怪的系统切换经验中比较有代表性的一种。事实上没有两个项目是一样的，客户方行业和文化不同，ERP软件不同，实施顾问方不同，实施的模块和功能不同都会使项目的过程产生极大的不同。并不是所有的项目都会经历这样的痛苦，个别跨国大公司在中国的推广项目（Roll-out），比较而言就顺利得多。但也有很多项目的情况比这更糟，有些项目因此而失败了。

经验和教训

从李明的项目中，相信大家已经能得到很多经验和教训。下面的篇幅我们将着重解释一些非常有用的经验供大家参考，当然实际的运用仍然要视项目的实际情况灵活判断。

FI-MM方法

FI-MM方法实质上就是分步切换。这个名称实际上是两个经常率先切换的模块的缩写。我们发现在我国这种分步切换的方法非常具有实际意义：我们首先让财务和库存管理两个模块先切换，随后销售，采购，生产等模块再跟进。这种方法至少具有以下一些好处：

1． 容易控制，相对于所有模块一起切换的大兵团作战，这种方式更容易控制。而且财务和仓管部门一般较为严谨，第一个月先稳住这两个部门的阵脚，对于士气会是非常大的鼓舞。

2． 速度加快，只这两个模块，在操作上是大大简化了，系统操作的速度和质量将大大提高。

3． 对帐简化，如果第一个月仍然并行，那么只有财务和库存管理的新系统和旧系统的对帐就大大简化了，甚至可以用自动对帐的工具从凭证直接核对。

4． 期初定单，不再需要准备期初定单了，所有和期初定单有关的错误和问题也可以避免了。

5． 关注新定单新流程，当其他模块跟进时我们只关心崭新的业务，比如完全新的销售定单，我们可以直接用新的流程处理这些定单。而对于期初定单我们不再关心处理它们的过程，我们仅仅是在财务和库存管理上核算它就可以了，一段时间以后它们的影响将自然地结束。

6． 大大降低的工作量。

当然这种做法的缺点也是明显的：

1． 最大的麻烦是：相当长一段时间内，有些信息会丢失或不完整，这主要和期初定单相关。比如盈利分析的数据将不完整，和期初销售定单相关的盈利分析数据就丢失了。不要低估这一点，因为上线后而看不到完整的报表会使不了解情况的领导们非常不高兴。因此这个问题一定要在使用前就明确说明。

2． 切换期间拉长，这不能完全说是一种缺点，因为切换期拉长其实分散了工作量也提高了成功率。但是对于某些条件好的公司，可能因为这一点而选择更快的全面切换方法。

3． 更多的系统设置，比如要设置两套物料移动类型，一套是配合销售定单，采购定单和生产定单的，一套是独立的。权限也需要做相应的设置。不过这个问题不大。几个人的工作总好过几十上百个人的混乱。

总而言之，对于实施困难大，定单执行周期较短的项目，考虑FI-MM方法会有不错的效果。

并行和测试，培训的关系

并行是一个非常困扰我国ERP实施的问题。我们曾研究过几种主要的实施方法论（Methodology），但是都没有发现关于并行的论述。从这个角度看，并行不是一种理想的系统切换模式。并行所造成的痛苦我们从李明的项目中都看到了，但是为什么并行特别在我国仍然是一种普遍的实践呢？理由只有两个字：风险。事实上虽然在我国某些地方财政部门仍强制要求实施ERP系统必须和原系统或手工系统并行一段时间，但是大部分的并

行是公司出于风险因素考虑的自主决定。对于这个问题目前仍然没有一个放之四海皆准的真理。但是下面的分析可能会对决策有所帮助：

1． 为什么并行对于系统切换是不利的

 目的。并行的目的实质上是对新系统的测试，但是用并行来测试无疑是非常昂贵的，同样性质的业务要重复地输入无数遍，最后查出的差异往往只是输入上的错误，对于系统验证是毫无帮助的。

 工作量。并行无疑加大了所有系统用户的工作量。巨大的工作负荷加上对于新系统的陌生和恐惧，使得目标越追越远，最后不得不放弃。

 对帐。对于两套有不同流程，不同概念的系统，即使不存在会计政策的变更，要完成对帐难度也是可想而知的。而且对帐不同于审计，如果并行期间以旧系统为准，那么新系统最终必须和旧系统完全一致才行，这样根本无法使用审计中的重要性原则，而只能是完全的核对。

 审计。不并行并不意味着没有检查，新系统仍然必须接受内部和外部的审计。事实上ERP系统提供了比一般会计系统和手工系统更充分的审计轨迹。

总之，并行的目的是防止失败的风险，而事实是它本身成为造成失败的最重要因素之一。

2． 如果不并行如何防范切换失败的风险

 测试。正如上面讲到并行的目的是对新系统的测试和验证，那么如果不并行就必须

强化测试。在李明的例子中，测试就是不充分的。实际上除了对于系统的测试，其他和切换相关的测试也不容忽视：比如期初数据格式转换和批输入程序的测试，期初定单特殊流程的测试等等。李明项目的并行实际上已经变成了一次实际数据测试，虽然测得非常全面，但是成本太高了。

 培训。在李明的项目中这次并行的另一个好处是培训了用户。所以如果不并行，一定要非常关注切换前期的培训。

3． 如果必须选择并行要注意什么

 FI-MM方法。虽然FI-MM方法无论并不并行都有用，但是如果选择并行，FI-MM方法将增加成功的机会。

 明确的对帐计划和手段。确保在切换开始之前，你已经准备好了对帐的计划和可以使用的工具。

前期工作的质量

系统切换是项目中第一个“混”不过去的阶段。你可以混过现有流程分析阶段，也可以混过业务蓝图设计阶段，也可以混过系统配置和各种测试阶段，同样可以混过用户培训阶段和主数据准备，但是系统切换是混不过去的，不但混不过去，而且前期工作的所有问题在这个时候都会反映出来。因此用务实的态度确实提高前期工作的质量，而不只是做出一份文档或者交差了事，到了系统切换阶段才能够比较顺利。

合作和分工

在ERP项目中，对于客户方和实施顾问方成败是共同的，责任也是共同的。所以真诚而良好的合作和分工对于项目的全过程都有重要意义。但是合作和分工的问题往往在系统切换前后会暴露的最为明显。在李明的项目中，顾问们为了追赶进度只能简化了用户接受测试去帮助用户准备主数据，结果系统测试不充分，而数据的质量也成了问题。同时，在本文的最后仍然要强调的是客户方管理高层的真正支持是ERP实施成功的首要因素。

文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，

只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！

文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成

功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文

档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！文档附件上传成功，但与已有文档重复，只能自己阅读！