一个ERP系统切换的案例

一个ERP系统切换的案例 ERP EBP实施的过程好比构筑一座崭新的城市。这座城市干净整洁，工商、娱乐、 教育一应俱全且功能强大，交通异常便捷……你充满希望地构筑了它，希望早一天 离开你现在居住的早已拥挤混乱的村落。但是这座城市建在河的对岸，随着完工日 期一天天地临近你发现隔在中间的河又宽又深，要让你的子民安然地迁徒到新家去 事实上远比想象的困难。从旧系统向ERP系统的切换就像渡河搬家。事实上，很多 EHP项目在走完系统配置和测试时看上去都还顺利，但在渡河搬家时却被淹了个半 死。 ERP （l） ERP是一个集成的系统，它不是对销售、储运、采购、生产、会计、资金这些 模块和功能的简单加法，它们之间是衔接的连贯的。对于日常运作和企业管理，集 成具有不可比拟的优点。但是在系统切换时，集成意味着更复杂的切换计划和对指 挥协调工作更高的要求。 （2） 上述难点的推论是：上线的模块和功能越多、越复杂，系统切换的困难也就越大， 而且难度是成倍增加的。打个比方来说，两条线相交是1个交点，3条线相交就是3 个交点，4条线就是6个交点，再往后是10个、15个、21个……集成点会随着模块和功能的增加而成倍增加。即使使用同样的模块，但是由于ERP系统是可配置的，不同公司也会设计出不同的流程。再加上每家公司的实际情况都不相同，这就使得 几乎每家公司的系统切换方式都会有所不同。包治百病的灵丹妙药是不存在的。 （3） 旧系统的资料一般质量较低也较分散（这是可以肯定的，否则也不会有实施BR P的需求）。但是，在向ERP系统切换时需要的主资料和期初资料中，相当大的部 分需求要通过加工旧系统资料来获得，因此，从这方面来说，系统切换的难度完全 取决于旧系统的质量．这里需要解释几个概念： ?旧系统，并不单指企业目前正在使用的计算机系统，如果你的仓储部门仍然在 用手工做台账，或者你的财务部没有使用任何会计软件，那么这些手上账也是你的 旧系统的一部分。 ?主资料和期初资料，系统切换最重要的工作之一是资料的转换。这主要包含两 大类资料。比如总账科目（G／L account master）、物料主资料（Material master）、物料清单（Bill of materials）、供货商主资料（Vendor master）、客户主资料（Customer master）、工艺路线（Routings）、采购信息记录（Purchase information records）、销售定价记录（Condition records（pricing））等都属于主资料。而期初采 购申请（Open chase requisitions）、期初销售定单（Open salesorders）、期初应收应付发票（Open A／R and Open A/P invoices）、期初总账余额（Open G／L account balances）、期初库存（Open stocks）都是期初资料。这两者共同构成了ERP系统资料的起点。 （4） 为什么旧的流程还会影响BRP系统？道理很简单，因为旧的流程会影响期初资 料。比如旧的流程是始终先发货，随后紧接着开票和入账，还是允许先开票和入账， 以后再发货或客户提货？这会直接影响期初销售定单和期初库存。旧流程越是不够 规范统一，系统切换时就越麻烦。 （5） 困难都是相对的，它遇到卓越的指挥会变得很谦卑，而对于拙劣的指挥它会非常 强大。事实上，ERP系统切换绝不仅仅是实施项目组的任务，它涉及企业很多部门 （究竟有多少取决于实施的模块和功能），因此对于这场战役的指挥是否成功，取 决于指挥官的权柄和能力，取决于部门间的责任和配合，也取决于整个公司的文化。 但不幸的是，旧系统和旧流程很混乱的企业，在BRP实施过程中项目组得到的支持 往往也较少。企业管理高层的支持无疑是有效指挥的前提条件。 （6） 我们内心深处都恐惧变化，除非这些变化能给我们带来看得见的好处。很明显的 一点是——并不是所有的人都愿意搬到河对岸的新城市去。如果搬家意味着几个月 加倍的劳动，艰苦的学习和适应，而自己连半句赞扬和肯定都得不到，换了是你， 你愿意吗？如果说在项目前期、实施主体是项目组（包括顾问和关键用户），客户 方的不足可以由实施顾问方弥补，在系统切换阶段，客户方的很多工作则是外界元法替换的。此时士气低落意味着时间和数据质量上的失控，无论哪种情况，对干系 统切换而言都是致命的打击。 （7） 系统切换在时间上有严格的要求。在系统切换的这段时间里，有三样东西可能是 并行的：业务、旧系统和新系统。几乎没有公司会为了ERP上线而停止业务，因此业务的处理始终在进行之中。那么，对于这段时间业务的记录是使用旧系统，还是 新系统？这是一个艰难的选择。如果选择新旧系统并行，那所有相关人员的工作就 被加倍了，此外，两套系统并行必然涉及到对账的问题。此时系统切换的难度更增 加了。这一点放在最后并不意味着它不重要，相反地，我个人的观点是：并行问题 成为困扰我国 ERP系统切换的头号问题。在下文还会有专门的探讨。 上面我们介绍了一下ERP系统切换面对的困难。就好比没有两片树叶是完全一 样的，每家企业的实际情况也千差万别。我们在制定上线计划时一定要对上述问题 有一个全面的了解，见招拆招，而不能生搬硬套。 下面这个事例会有助于大家理解系统切换的过程。李明是ERP财务顾问，他目前正在实施的项目包括了几个主要的模块：财务、销售、库存、采购和生产。7月1 日，项目经理召开项目组会议讨论系统切换计划。会议上明确了以下几个决定： ? 以8月1日作为本次切换点； ? 所有模块同时切换； ? 鉴于客户方的强烈要求，第一个月新旧系统需并行。 由于看上去切换和财务的关系最大，所以项目经理要求李明在会议结束后编制一 个详细的切换计划。下面介绍的是转个计划的一部分——和销售相关联的切换计划。 李明的计划首先从期初资料的准备工作人手。“情况稍微有点复杂，但是还难不倒我”，李明想。首先必须兼顾到以下一些问题： * 新系统的期初资料必须和旧系统的资料完全一致 * 新系统的库存必须账实相符 7月31日仍在执行过程中的销售定单需要作为期初销售定单输人系统图l是从系统切换的角度来看业务以及旧系统和新系统的关系。图上方是在系统切换日，即 7月31日仍未执行完毕的销售定单。假如某笔销售定单部分发货，那么在7月31日的期末库存中将不包括已经发货的产品。我们在7月31日必须进行一次完整的库 存盘点，随后，根据盘点的结果更新旧财务系统的存货及相关其它科目，图中的粗 箭头代表了这一过程。 由于ERP系统是分模块的集成系统，所以不同科目的期初余额是布不同的模块 中分别输人的，随后系统自动更新到总账模块中，图下方是本例中涉及的ERP库存管理模块、应收帐款模块和总账模块。总账模块两边的箭头代表了自动更新总账。 由于是分模块的输入，所以我们专门设置“系统切换过渡科目”，作为所有科目输人 时的对方科目。最后,当期初资料全部输人完毕后，该科目的余额应该结平。 当旧系统于7月31日月末结账完成后，他将根据盘点的清单和财务上的商品价 格，将库存的期初余额导入ERP系统的库存管理模块。同时应收账款的明细科目（明 细到未清发票或预付款）导入应收账款模块。其它的科目也是分模块按各自的要求 导人ERP系统。图中从旧财务系统到库存管理模块和应收账款模块的箭头以及从销售定单到销售模块的箭头就代表了这种导入的过程。由于旧系统的存货资料已根据 实际盘点调整过，所以，新系统的库存管理模块的出发点是账实相符的（图中的虚 线）。与此同时，对子7月31日未执行完毕的销售定单，也应当导入系统的销售模 块。只是不能将整张定单导入，而是应当扣除7月31E以前已经发货的部分。图中 左土方的箭头代表了期初销售定单（Open sales order）的导入。 分析完期初资料的准备工作，李明觉得很满意，毕竟这看上去不太复杂。接下来 应该是具体的切换计划了。 图2是李明设计的切换计划。首先，在7月20日之前关于库存地点的系统配置 以及所有的物料主资料必须都学人ERP系统。7月30日也就是系统切换前大盘点 的前一天，盘点计划和盘点表格必须已下发无误。7月3L日停产一天正式盘点。8 月1日盘点结束，财务人员汇总盘点结果，开始7月份的旧系统月末结账。月末结 账预计耗费15天，到8月15日旧系统月末结帐完毕。随后，信息技术部和财务部 再花两天时间将日系统的期初资料整理和转化成符合ERP系统导入的。这项工 作将在8月17日完成，随后再花二天时间将期初资料批输入ERP系统。这时已经是8月20日。 由于第一个月，也就是8月，新旧系统必须并行运行，所以财务部从8月l日起继续在旧系统中处理业务。这样和7月结账的时间一样，旧系统在9月15日完成8月的月末结账．与此同时，从8月20日起，所有相关部门都开始在新的ERP系统中处理业务。这样经过31天，到9月20日，在新系统中8月的账目也结算完毕。 随后用5天时间完成新旧系统的对账。到了9月25日，整个系统切换工作将彻底完 成。客户将完全在新的ERP系统中开始处理9月份的新业务，当然这时仍有几天的 工作要追赶，但是经过了并行，加上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日 在随后的一个多星期里，项目组经历了真正的考验，输入工作从开始 就面临困难： （l）因为输入的都是8月份已经处理过的业务，所以这仅仅是输入，而不是业 务流程处理。部门问如何在这个过渡阶段衔接是原来没有考虑到的。比如财务部要 做销售定单开票，却发现仓管部门的该笔发货还没有追进去，而新的流程要求开票 必须有相关的发货记录。这时财务只能先跳过这笔业务。第一天李明坐在财务部的 赵强旁边，一连五六张票都是这样做不过去，赵强已经唉声叹气了，李明强作镇定， 换了一本费用的凭证，才得以开始。同样的，仓管部门在做发货时根本无法从旧的 发货单上知道是新系统中哪张销售定单的货，幸好新系统的查询功能还不错，可以 从销售的商品、客户等相关信息追踪查找销售定单，但是进度和准确性大打折扣。 同时也有很多发货中所对应的销售定单销售部尚未输入。 （2）期初销售定单的问题在第一天就发现了，按计划销售部门需要提供的期初 销售定单是必须扣除7月31日以前已发货部分的剩余未执行部分。但是销售部和财 务部不同，销售员们根本没有和财务人员一样严格的期间概念。很多的期初销售定 单都没有扣除已发货部分或者扣错了。结果是期初销售定单可能会被重复发货。和 期初销售定单相关的业务被暂停处理。销售员被要求适新检查期初销售定单，顾问 和关键用户也忙着帮助手工更正那些原来批输入的期初定单。仓管员们和财务部被 要求特别留神期初定单。但是错误看来还是难以避免的。 （3）当销售员开始录入新的销售定单时，客户主资料的问题暴露出来了。在准 备客户主资料的时候，曾要求销售员将现有客户档案报给风险管理都统一整理和编 号。但是很多销售员都没有报全。当然出于历史原因，该公司的客户档案被销售员 视做个人财产。在流程设计时考虑到了这种习惯，虽然公司管理层和风险管理部有 权限看到所有客户主资料，但是销售员之间是不共享客户资料的。但是，他们没想到销售员的抵触情绪仍然那么大，很多销售员除了7月底财务帐上有的客户外，其它客户则一律没有提供。现在要在新系统中管理销售定单了，可是很多客户的主资 料在新的ERP系统中都没有，货发不出去，销售员们怨声载道。没别的办法，项目 组重新要求销售员上报客户资料，风险管理部加班加点地输人客户资料，由于太零 散，也太急，批输入程序被放在一边，风险管理部的几个用户在销售员的催促下已 经输得眼冒金星了。很多资料不完整的只能用缺省值应付了。李明在系统中看了一 下客户清单，发现很多名称相近的，怀疑是重复编码了。他报告了项目经理和用户。项目经理叹了口气：“等过了这阵再清理吧。” （4）输入的第三天负责库存管理的顾问急冲冲地跑来找李明，仓管员发现很多 发货在系统中无法输入，原因是这样的：比如7月31日财务部已经开票，但是客户尚未提货或仓库尚未发货的情况下，财务已经在账上做了结转成本和确认收入，这 样，期初销售定单中应该已扣除了这笔账面上的发货。所以，现在实际要发货时找 不到任何对应的销售定单。李明立即去问了客户的财务经理，回答是：“确实存在这 种情况，而且数量是比较大的。此外相反的情况也是存在的，比如有些货已经发了， 但是发票还没有开，所以这些货在账上仍然存在。这些问题是造成库存账实不符的 重要原因。”李明说：“现在我们必须把这两种情况的数量都清理出来，重新调整期 初库存，开票未提的库存做无账面价值的处理，发货未开票的做虚拟库存商品。” 财务经理摇摇头：“不可能，现在根本没有时间和人手整理。”最后折衷的方案是：对于开票未提，在系统中另外配置一种物料移动类型，财务上的自动记账则设为直 接冲销期初盘点帐实不符的挂账科目。对于发货未开票的情况，实际结转成本时由 财务部直接从挂账科目中转出。等过一段时间这些历史情况都处理完毕后，如果挂 账科目的余额不显著，就认为是实际盘盈或盘亏结转费用，目前暂定为3个月。顾 问和关键用户们马不停蹄地更改系统配置，重新培训仓管员和财务。李明心中隐隐 的不安：“仓管员们如何区分哪些发货是期初开票未提，哪些是销售部还没来得及追 人系统的销售定单发货呢？再说，如果期初销待定单仍然包括了这些开票未提货， 那仓管员将错就错地发货，挂账科目企不是总也消不掉？”不过他实在太累了，只能把这些问题放在一边又去干别的了。 （5）这儿天还有另一件事令李明非常烦心：从流程上说，财务往往在最后阶段， 往往是如果前面的步骤出错，那么到了财务这里就过不去了，比如销售员追进去的销售定单及开票中请的价格错了，等财务追开票过账时被发现了，随后部寻不着是 哪个销售员，这又大大地影响了财务部的进度，财务部已经被批评了好几次了，真 是让人百口莫辩。最后，李明对财务说，“如果错误确定的话就直接改物流的单据吧”。 但是财务人员大都没有这样的权限也没有培训过物流模块。李明只好一边加权限， 一边教，大部分时间还自己直接改物流单据。项目经理对李明说最好不要自己改权 限，也不要自己改物流单据，应该走流程。李明只好苦笑。 （6）很多流程被发现存在问题，有些流程还被忽略了，各种配置和主资料中也 发现了各种各样的问题。本来有些配置和主资料的更改应该走流程解决，但是由于 关键用户和最终用户的训练不足，现在都直接反映到了顾问这里。一边支持用户， 一边更改配置，李明和他的同事们已经快坚持不住了。而用户们却都在抱怨朝令夕 改，令他们永远跟不上变化。 （7）不满的暗流在整个公司扩散。有些从一开始就有抵触情绪的销售员变得更 加肆无忌惮，不会操作或不愿操作新系统被光荣地挂在嘴边。连原来支持者此时也 禁声了。一个业务员发给李明一篇文章，标题是类似ERP实施成功率为零之类的，是从网上下载的，作者是某国际知名管理咨询公司的C什么O．据说这篇文章已经传遍了全公司。李明怒火中烧。 （8）吃午饭的时候，李明遇到了赵强，赵强是最早熟练操作系统的财务，所以 李明已经好多天没有去赵强那里了。李明问赵强情况怎么样。越强说：“苦死了，这个月从月初准备期初资料开始，几乎天天加班，周末也加班，屁股都像黏在凳子上 了。系统要输两套，工资倒不发两份，输慢了还要挨骂……”。李明无言以对，自己也不知道为什么竟然会感到内疚。….. 出现的问题几乎数不胜数，其它模块的情况也好不到哪里去，可能还更糟。负责 生产计划的顾问说，由于销售定单的问题和物料清单的不准确，现在运行MRP的 结果实在没法用，况且由于是在追资料，采购和生产目前也用不止新系统的结果， 照单据输就是了。 项目经理问李明目前的情况，将来对账会不会有问题。李明说：肯定有问题，不 过现在顾不了了。 9月3日 星期——早，项目组和各部门的负责人开会，讨论一个重要的决定：9 月份还要不要并行。几乎没有什么争论就做出了决定刊月份继续并行。理由很简单： 目前新系统8月的输入进展实在太缓慢了，什么时候能输完对完账谁都不敢说。现 在放弃旧系统，风险太大，没人负得起这个责任。 对于新系统大家已经不抱希望能够追上实际业务了，日前也只能把这次切换和上线作为对新系统的一次测试、验证和对人员的培训。最后决定在公司5个事业部中，挑选两个配合比较顺利的部门进行重点突击，争取尽快输完8月份的资料，进入对账。好在这5个事业部在内部都是相对独立核算的。 9月29日 差不多一个月的时间，项目组所有力量都投人到了两个选定的事业部。 终于赶在国庆节前完成了这两个事业部8月份的资料输人。但是其它3个事业部的输人工作几乎全放了羊。“算了吧，等放完假回来再对账吧。”李明收拾行李准备回家，“项目要做，命也得要。” 10月8日 对账正式开始了，财务部仍然没有人手可以提供，只好所有的财务顾 问都加人了对账。在开始之前，李明罗列了以下困难和注意事项： （1）因为所有模块同时切换，所以相当大的一部分财务凭证是通过集成自动生 成的，而且在产品成本的核算方法上新旧系统还存在不同，因此无法通过新旧凭证 的相互参照来进行自动核对（这种方式称为自下而上的方式），只能用自上而下的 方式核对，即以试算平衡表?科目?凭证分组?凭证的方式检查，对于有些科日如 产成品、主营业务成本等还要为对账开发额外的报表。 （2）新旧系统的资料下载到电子表格后进行核对，发现错误时不能直接更改系 统，而是在系统外编制调整分录，这主要是因为参与对账的人多，而且是分科目对 的，又因为不是记账的人本身在核对，所以如果直接更正系统，被有可能一个错误 被重复更正。调整分录的清单是共享的。 （3）对于新旧系统的差异如何处理是一个不折不扣的难题。如果差异是新系统 输人错误造成的，那最简单，只要调整新系统就行了。但是如果是旧系统输人错误 造成的，问题就来了，因为并行阶段一般是以旧系统为主，在这个项目中就更是如 此了，但是旧系统8月已经结账，按照规定对8月的调整应该做在发现错误的月份，只要还在本年度。所以对账时只能将错误记录下来，更正到旧系统的的月份，对账调整分录仍然是调整新系统。对干因为会计变更或核算方法调整造成的差异， 更正是不可行的，只能通过报告解释原因，随后编制调整分录调整新系统。此外， 由于凭证的数量巨大，而且又不是记账者自已对账，所以要找出所有差异的原因几 乎是不可能的。只能参考审计中的重要性原则，找出重要的差异，对于小差异则直 接编制调整分录了。 （4）对于调整分录如何处理，又是伤脑筋的问题。比如由于产品成本核算方式 不同造成的差异，通过报表可以解释差异和编制调整分录，但是在新系统中如何调 整呢？一种方法是根据旧系统的产品成本在新系统中重估库存，但是这样做的工作量是相当大的。另一种方法是直接在财务上调整，作类似商品成本差异科目处理， 但是这种做法在以后的月份中还是要考虑它的分摊，等于将工作量向后移了。此外 对于没有找到原因的小差异，直接调整新系统将受到内部和外部的质疑，毕竟所有 的凭证都应当有原始支持凭证。不过在这个项目中李明还不用太苦恼，因为并行已 经变成了测试，只要找到重要的差异，编制调整分录将新旧系统报表调平，对账报 告双方签字确认就可以了。 计划中的五天对账显然大大低估了对账的工作量，虽然5个事业部只对两个，项目组仍然花了3个星期才通过了对账报告。项目室里堆满了凭证，顾问和关键用户 显得虚弱而亢奋。 10月29日 在10月的最后几天，终于对平了两个事业部8月的账。接下来怎么 办？项目组决定用几个星期的时间重新整理流程和主资料，培训用户，随后清全系 统，做第二次切换和上线。当然这次的切换将是崭新的和成功的。ERP的彼岸就在 眼前了。 李明的项目只是千奇百怪的系统切换经验中比较有代表性的一种。事实上没有两 个项目是一样的，客户方的行业和文化不同，ERP软件不同，实施顾问方的不同， 实施的模块和功能不同，都会使项目的过程产生极大的不同。并不是所有的项国都 会经历这样的痛苦，个别跨国大公司在中国的推广项目（Rollout），比较而言就顺 利得多。但也有很多项目的情况比这更糟，有些项目因此而失败了。 从李明的项目中，相信大家已经能得到很多经验和教训。下面我们将着重提供一些 非常有用的经验供大家参考，当然实际的运用仍然要视项目的实际情况来灵活判断。 FIMM FI-MM方法实质上就是分步切换。这个名称实际土是两个经常率先切换的模块的缩 写。我们发现在我国这种分步切换的方法非常具有实际意义。我们首先让财务和库存管 理两个模块切换，随后销售、采购、生产等模块再跟进。这种方法至少有以下一些好处： （1）容易控制．相对于所有模块一起切换的大兵团作战，这种方式更容易控制。而 且财务和仓管部门一般较力严谨，第一个月先稳住这两个部门的阵脚，对于士气会是非 常大的鼓舞。 （2）速度加快。只有这两个模块进行切换，在操作上是大大简化了，系统操作的速 度和质量将大大提高。 （3）对账简化。如果第一个月仍然并行，那么只有财务和库存管理的新系统和旧系 统的对账工作就大大简化了，甚至可以用自动对账的工具从凭证直接核对。 （4）期初定单。不再需要准备期初定单了，所有和期初定单有关的错误和问题也可 以避免了。 （5）关注新定单、新流程。当其它模块跟进时，我们只关心崭新的业务，比如对于 完全新的销售定单，我们可以直接用新的流程处理这些定单。而对于期初定单，我们不 再关心处理它们的过程，而仅仅是在财务和库存管理上核算它就可以了，一段时间以后 它们的影响将自然地结束。 （6）大大降低了工作量。这一优势是显而易见的。 （l）最大的麻烦是：相当长的一段时间内，有些信息会丢失或不完整，这主要和期 初定单相关。比如盈利分析的资料将不完整，和期初销售定单相关的盈利分析资料就丢失了。不要低估这一点，因为上线后看不到完整的报表，会使不了解情况的领导们非常 不高兴。因此这个问题一定要在使用前就明确说明。 （2）切换期间拉长。这不能完全说是一个缺点，因为切换期拉长其实分散了工作量 也提高了成功率。但是对于某些条件好的公司，可能因为这一点而选择更快的全向切换 方法。 （3）更多的系统设置。比如要设置两套物料移动类型，一套是配合销售定单、采购 定单和生产定单的，一套是独立的。权限也需要做相应的设置。不过这个问题不大，几 个人的工作总好过几十上百个人的混乱。 总而言之，对于实施困难大、定单执行周期较短的项目，考虑FI－MM方法会有不 错的效果。 并行是一个困扰我国ERP实施的一个非常严重的问题。曾研究过几种主要的实施方 法论（Methodology），但定都没有发现关于并行的论述。从这个角度看，并行不是一种 理想的系统切换模式。并行所造成的痛苦我们从李明的项目中都看到了，但是为什么并 行在我国仍然是一种普遍的实践呢？理由只有两个字：风险。事实上，虽然在我国某些 地方财政部门仍强制要求实施ERP系统必须和原系统或手工系统并行一段时间，但是大 部分的并行是公司出于风险因素考虑的自主决定。对于这个问题目前仍然没有一个改之 四海皆准的真理。但是下面的分析可能会对决策有所帮助： （1）并行对于系统切换不利的原因 目的。并行的目的实质上是对新系统的测试，但是用并行来测试系统无疑是非常昂 贵的，同样性质的业务要重复地输入无数遍，最后查出的差异往往只是输入上的错误， 对于系统验证是毫无帮助的。 工作量。并行无疑加大了所有系统用户的工作量。巨大的工作负荷加上对于新系统 的陌生和恐惧，使得目标越追越远，最后不得不放弃。 对账对于两套有不同流程、不同概念的系统，即使不存在会计的变更，要完成 对账的难度也是可想而知的。而且对账不同于审计，如果并行期间以旧系统为准，那么 新系统最终必须和旧系统完全一致才行，这样根本无法使用审计中的重要性原则，而只 能是完全的核对。 审计。不并行并不意味着没有检查，新系统仍然必须接受内部和外部的审计。事实 上，ERP系统提供了比一般会计系统和手工系统更充分的审计轨迹。 总之，并行的目的是防止失败的风险，而事实是它本身成为造成失败的最重要因素 之一。 （2）不并行情况下防范切换失败风险的措施 测试。正如上面讲到并行的目的是对新系统的测试和验证，那么如果不并行就必须 强化测试。在李明的例子中，测试就是不充分的。实际上除了对于系统的测试，其它和 切换相关的测试也不容忽视：比如期初资料格式转换和批输入程序的测试，期初定单特 殊流程的测试等等。李明项目的并行实际上已经变成了一次实际资料测试，虽然测得非 常全面，但是成本太高了。 培训。在李明的项目中这次并行的另一个好处是培训了用户。所以如果不并行，一 定要非常关注切换前期的培训。 （3）必须选择并行时要注意的问题 FI—MM方法。虽然FI—MM方法无论是否并行都有用，但是如果选择并行，FI—M M方法将增加成功的机会。 明确的对账计划和手段。确保在切换开始之前，你已经准备好了对账的计划和可以 使用的了具。 (重要的一段） 系统切换是项目中第一个“混”不过去的阶段。你可以混过现有流程分析阶段！可以混 过业务蓝图设汁阶段，也可以混过系统配置和各种测试阶段，同样可以混过用户培训阶 段和主资料准备，但是系统切换是混不过去的。不但混不过去，而且前期正作的所有问 题在这个时候都会反映出来。因此要用务实的态度确实提高前期工作的质量，而不只是 做出一份文档或者交差了事，到了系统切换阶段才能够比较顺利。 在ERP项目中，对于客户方和实施顾问方而言成败是共同的，责任也是共同的。所以真诚而良好的合作和分工对于项目的全过程都有重要意义。但是合作和分工的问题往 往在系统切换前后会暴露的最为明显。在李明的项目中，顾问们为了追赶进度不得不简 化了用户接受测试，而去帮助用户准备主资料，结果系统测试不充分，资料的质量也成 了问题。同时，在本文的最后仍然要强调的是客户方管理高层的真正支持是ERP实施成 功的首要因素。