《ERP系统的切换》由会员分享，可在线阅读，更多相关《ERP系统的切换（31页珍藏版）》请在金锄头文库上搜索。
1、细心整理ERP系统切换ERP实施的过程好比构筑一座崭新的城市。这座城市干净干净，工商消遣教化一应俱全且功能强大，交通异样便捷 。你充溢盼望地构筑它，盼望早一天离开你此时此刻居住的早已拥挤混乱的村落。但是这座城市建在河的对岸，随着完工日期一每天地接近，你发觉隔在中间的河又宽又深，要让你的子民坦然地迁徙到新家去事实上远比想象的困难。从旧系统向ERP系统的切换就象渡河搬家。事实上很多ERP工程在始终走完系统配置和测试时看上去都还顺当，但在渡河搬家时被淹了个半死。难点概括地说，ERP系统切换有以下难点：1. 集成。ERP是一个集成的系统，销售，储运，选购，生产，会计，资金这些模块和功能不是简洁的加法，
2、它们之间是连接和连贯的。对于日常运作和企业管理，集成具有不行比较的优点。但是在系统切换时集成意味着更困难的切换准备和对指挥协调工作更高的要求。2. 多模块。作为上述难点的推论是：上线的模块和功能越多越困难，系统切换的困难也就越大，而且难度是成倍增加的。打个比方：2条线相交是1个交点，3条线相交就是3个交点，4条线就是6个交点，再往后是10，15，21 集成点会随着模块和功能成倍增加。而且即使运用同样的模块，由于ERP系统是可配置的，不同公司也会设计出不同的流程。再加上每家公司的实际状况都不一样，这就使得几乎每家公司的系统切换方式都会有所不同。包治百病的灵丹妙药是不存在的。3. 旧系统。旧系统的
3、数据一般质量较低也较分散这是可以确定的，否那么也不会有实施ERP的需求。但是在向ERP系统切换时须要的主数据和期初数据，相当大的局部须要通过加工旧系统数据获得。因此从这个方面说系统切换的难度完全取决于旧系统的质量。这里须要说明几个概念：旧系统，并不单指企业目前正在运用的计算机系统，假设你的仓储部门照旧在用手工做台帐，或者你的财务部没有运用任何会计软件，那么这些手工帐也是你的旧系统的一局部。主数据和期初数据，系统切换最重要的工作之一是数据的转换。这主要包含两大类数据。比方总帐科目G/L account master，物料主数据Material master，物料清单Bill of materia
4、ls，供应商主数据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系
5、统数据的起点。4. 旧流程。为什么旧的流程还会影响ERP系统？道理很简洁，因为旧的流程会影响期初数据。比方旧的流程是始终先发货，随后紧接着开票和入帐，还是允许先开票和入帐，以后再发货或客户提货？这会干脆影响期初销售定单和期初库存。旧流程越不标准统一，系统切换时就越麻烦。5. 指挥。困难都是相对的，它遇到卓越的指挥会变得很谦卑，而对于拙劣的指挥它会特殊强大。事实上ERP系统切换决不仅仅是实施工程组的任务，它涉及企业很多部门究竟有多少取决于实施的模块和功能，因此对于这场战役的指挥是否成功，取决于指挥官的权柄和实力，取决于部门间的责任和协作，也取决于整个公司的文化。但不幸的是旧系统和旧流程很混乱的企
6、业，在ERP实施中工程组得到的支持往往也较少。而企业管理高层的支持无疑是有效指挥的前提条件。6. 士气。我们内心深处都恐惊变更，除非这些变更能给我们看得见的好处。很明显的一点是：并不是全部的人都情愿搬到河对岸的新城市去。假设搬家意味着几个月加倍的劳动，艰辛的学习和适应，而自己连半句赞扬和确定都得不到，换了是你，你情愿吗？假设说在工程前期，实施主体是工程组包括参谋和关键用户，客户方的缺乏可以由实施参谋方弥补，在系统切换阶段，客户方的很多工作那么是外界无法替换的。此时士气低落意味着时间和数据质量上的失控，无论哪种状况，对于系统切换而言都是致命的打击。7. 并行。系统切换在时间上有严格的要求。在系统
7、切换的这段时间里，有三样东西可能是并行的：业务，旧系统和新系统。几乎没有公司会为了ERP上线停顿业务，因此业务的处理始终在进展之中。那么对于这段时间业务的记录是运用旧系统，还是新系统？这是一个困难的选择。假设选择新旧系统并行，那全部相关人员的工作就被加倍了，此外两套系统并行势必涉及到对帐的问题。此时系统切换的难度更增加了。这一点放在最终并不意味着它不重要，相反地，我们的个人观点是：并行问题成为困扰我国ERP系统切换的头号问题。我们在下文还会有特地的探讨。上面我们介绍了一下ERP系统切换面对的困难。就好比没有两片树页是完全一样的，每家企业的实际状况相差会很大。我们在制定上线准备时必需要对上述问题
8、有一个全面的了解，见招拆招，而不能生搬硬套。切换准备下面这个事例会有助于大家理解系统切换的过程：李明是ERP财务参谋，他目前正在实施的工程包括了几个主要的模块：财务，销售，库存，选购和生产。7月1日，工程经理召开工程组会议探讨系统切换准备。会议上明确了以下几个确定： 以8月1日作为本次切换点。 全部模块同时切换。鉴于客户方的猛烈要求，第一个月新旧系统需并行运行。由于看上去切换和财务的关系最大，所以工程经理要求李明在会议完毕后编制一个详细的切换准备。由于篇幅所限，我们下文的介绍只是整个准备的一局部：和销售相关联的切换准备。期初数据李明的准备首先从期初数据的准备工作入手。“状况稍稍有点困难，但是还
9、难不倒我”李明想。首先必需兼顾到以下一些问题：1 新系统的期初数据必需和旧系统的完全一样2 新系统的库存必需帐实相符3 7月31日仍在执行过程中的销售定单须要作为期初销售定单输入系统图一是从系统切换的角度来看业务，旧系统和新系统的关系。图一上方是在系统切换日，即7月31日仍未执行完毕的销售定单。假设某笔销售定单局部发货，那么在7月31日的期末库存中将不包括已经发货的产品。我们在7月31日必需进展一次完整的库存盘点，随后依据盘点的结果更新旧财务系统的存货及相关其他科目，图一中绿色的箭头代表了这一过程。由于ERP系统是分模块的集成系统，所以不同科目的期初余额是在不同的模块中分别输入的，随后系统自动
10、更新到总帐模块中，图一下方是本例中涉及的ERP库存管理模块，应收帐款模块和总帐模块。红色的箭头代表了自动更新总帐。由于是分模块的输入，所以我们特地设置“系统切换过渡科目”，作为全部科目输入时的对方科目。最终当期初数据全部输入完毕后，该科目的余额应当结平。当旧系统7月31日月末结帐完成后，我们将依据盘点的清单和财务上的商品价格，将库存的期初余额导入ERP系统的库存管理模块。同时应收帐款的明细科目明细到未清发票或预付款导入应收帐款模块。其他的科目也是分模块按各自的要求导入ERP系统。图一中兰色的箭头代表了这种导入的过程。由于旧系统的存货数据已依据实际盘点调整过，所以新系统的库存管理模块的启程点是帐
11、实相符的图一中的红色虚线。及此同时，对于7月31日未执行完毕的销售定单，也应当导入系统的销售模块。只是不能将整张定单导入，而是应当扣除7月31日以前已经发货的局部。图一左侧的兰色箭头代表了期初销售定单Open sales order的导入。好了，分析完期初数据的准备工作，李明觉得很满意，终归这看上去不太困难。接下来应当是详细的切换准备了。准备图二是李明设计的切换准备。首先在7月20日之前关于库存地点的系统配置以及全部的物料主数据必需都导入ERP系统。7月30日也就是系统切换前大盘点的前一天，盘点准备和盘点表格必需已下发无误。7月31日停产一天正式盘点。8月1日盘点完毕，财务人员汇总盘点结果，起
12、先7月份的旧系统月末结帐。月末结帐预料消耗15天，到8月15日旧系统月末结帐完毕。随后信息技术部和财务部再花2天时间将旧系统的期初数据整理和转化成符合ERP系统导入的格式。这项工作将在8月17日完成，随后再花3天将期初数据批输入ERP系统。这是已经是8月20日。由于第一个月，也就是8月，新旧系统必需并行运行，所以财务部从8月1日起就接着在旧系统中处理业务。这样和7月结帐的时间一样，旧系统在9月15日完成8月的月末结帐。及此同时从8月20日起先全部相关部门都起先在新的ERP系统中处理业务，这样经过31天到9月20日新系统8月也结帐完毕。随后用5天时间完成新旧系统的对帐。到了9月25日整个系统切换
13、工作将彻底完成。我们将完全在新的ERP系统中起先处理9月份的新业务，当然这时仍有25天的工作要追逐，但是经过了并行，加上ERP的强大功能，再加上一点努力，完全可以顺当地追上20多天的业务。李明的准备很顺当地通过了工程组的审定。激烈人心的系统切换就要起先了！切换7月20日 事情从一起先就不太顺当，这个工程的一个特点就是这家公司的物料主数据特殊多，而且各个部门的编码有很多是不同的。按准备今日是主数据导入系统的最终一天，但是别说物料清单BOM，目前连物料主数据还没有整理完。工程组和相关的部门领导开了紧急会议，最终制定了紧急准备：5天内完成物料主数据的整理工作，再用20天完成物料清单的整理，必需要在8
14、月20日新系统运行前导入系统。工程组的局部物流参谋和关键用户也放下了用户承受测试User Acceptance Testing，投入到数据的整理工作里。最终又晚了两天才强求把商品主数据批输入了系统，几个参谋和关键用户一连加了几天班。但是库存管理部门已经来不及按整理后的物料编码来准备全部的盘点表格了，几个变更最大的仓库只能干脆用整理之前的编码做出盘点表格，有些物料甚至没有编码，只写了名称和规格。7月31日 公司停产一天，起先全面的盘点。盘点进展得还算顺当，负责库存管理的参谋和关键用户也参与了监盘。他们回来后告知工程经理和李明：状况挺好，只是仓管员们对整理后的物料编码还不太熟悉，根本上都是按名称和
15、规格来盘的，而且发觉好多没有编码的物料，只好临时用名称来记录。盘点表已经整理完毕，不过估计财务部运用这些盘点表的时候会有困难。工程经理提示李明在财务部结帐的这段时间多去看看。8月14日 离预定的旧系统月末结帐完成还有一天，李明真有点着急了，财务部告知他，可能会来不及。这次上线把原来的一些问题全端到了台面上：比方说库存帐实不符，财务部和库存部门的物料编码不同等等。这次光是核对和整理盘点报告就多花了一周，新整理的物料编码错漏重复不少，而且两个部门都不太熟悉，特殊是对于参谋整理的相当大的局部，客户方颇有微词。同时财务经理告知李明，最终盘点结果，帐实不符的比例可能相当大，几乎占了总库存的20%。当李明
16、问起缘由时，财务经理面露难色，说：“不太好说。不过我们不赞成全部算盘盈盘亏，再说税务局也不会同意。所以最好是挂帐。”李明没有方法只好同意。不过为了挂帐的须要，他又建了几个科目，因为原来的存货科目是不允许财务手工更改的。8月17日 在晚了两天以后，财务部最终完成了旧系统7月份的结帐。客户的信息技术部把旧财务系统的数据导入了电子表格就交给了李明。这时是8月18日星期六，信息技术部的刘工还闹了个老大不快乐。李明找到工程经理，几个参谋协商了一阵，确定及其争吵奢侈时间，不如参谋自己做整理和导入。接下来的四天是没日没夜的。好在李明的准备工作做得不错，新旧科目参照表，新旧客户编码参照表，新旧供应商编码参照表等等都在关键用户的合作下准备好了。存货清单是财务部依据盘点结果和财务数据整理的，和财务帐面的差异的确很大，都转入了挂帐科
