好开头未必好兆头

　　经过几个月的反复比较、挑选、论证，飞扬公司决定实施国外的一家大型软件公司提供的ERP管理软件。实施方是国内相当有实力的高成咨询公司。作为这家大型机械设备制造企业的CIO，陈先生终于可以松一口气了。领导的大力支持，同行业相对便宜的价格，国外著名ERP软件，实力强劲的实施公司，以及企业员工的计算机水平相对较高，所有这些看起来，ERP实施是开了个好头。

　　很快，高成公司根据合同派来了由资深顾问李先生为首的项目实施小组，项目开始实施。为了配合项目实施，飞扬公司也成立了ERP项目小组，除了电脑部的原有的实施人员外，还从业务部门抽调了熟悉财务、分销、制造的几名业务人员。双方的项目人员配合得相对还算不错，调研，需求分析，关键用户培训，一步一步按照项目计划在进行中。看到这么顺利的进展，陈先生不禁喜上心头，跟项目小组放言：年底前争取上线。

　　系统开发前的针锋相对

　　不久，项目进行到方案设计阶段。公司老总在ERP实施前就为实施定了调：现有的业务流程不能大改，只能逐步优化。飞扬公司业务相对复杂，有待改进和规范的业务流程不少，估计开发量不少，因此顾问在同业务部门讨论解决方案前采取了如下应对策略：培训客户尽快熟悉系统功能，劝说客户采用系统已有的相似功能，减少一些无谓的开发，系统没有的功能则考虑开发。

　　当项目小组同业务部门开始就方案进行讨论时，许多业务部门提出了开发需求。李先生极力反对对系统做大量开发，他认为该软件是在数万家企业使用的，它的管理思想是非常先进和合理的，而且大量开发不但会有开发的风险，延长了实施周期，还会对系统升级带来诸多不便。业务部门坚持开发的理由是：1，企业现有的流程支持公司快速发展，目前使用的流程是经过实践检验了的，只是需要更进一步完善;2，ERP的流程或许先进，但不可能因为实施ERP而大改，太大的调整将导致上下衔接不顺，就连正常的运转都难以维系，上ERP就是找死。处在中间的陈先生犯难了：开发吧，时间长、风险大;不开发吧，业务部门的需求在老总看来是理所当然的，而且如果现在开发了以后就可以不开发，陈先生在权衡后选择了开发。就这样，实施小组和业务部门讨论、协商、争论了个把月，一大堆的开发摆在李先生面前。令李先生为难的是，如果拒绝，实施方案没有业务部门的签字，飞扬公司将拒付实施费。在开发和项目停顿的两难中，李先生无奈的选择了前者。在承诺给予开发后，业务部门才陆续在实施方案上签字确认。

　　开发中的人员更替

　　在初步估算几百个工作日的开发量，李先生深知开发任务的艰巨，于是从公司将高级技术顾问刘先生以及另外两个技术顾问调入项目组，而在此时，飞扬公司的几名开发人员才刚刚从其他系统脱身介入ERP开发。按照李先生所拟定的实施计划安排，留给刘先生的开发时间是不多的， 刘先生经过几天的分析，拟定了开发了一个开发计划，没想到刚提交给李先生就遭到否决：“不行，开发的日期必须缩短!否则项目怎么上线啊”，但刘先生有他的苦衷，因为他比谁都明白自己所面临的难处：如此巨大开发量及紧张的开发时间安排，同时，他还要负责进行培训，对飞扬公司的几名开发人员进行知识转移，以及其它技术顾问的开发跟进。

　　在修改了开发计划后，刘先生投入了紧张的设计、开发过程中，并将一些简单的开发交给了飞扬公司的开发人员。然而，飞扬公司的开发人员以前都未接触该ERP软件的开发，同时还需要维护公司其他系统，人也三心二意，因此起步格外吃力，经常向刘先生请教开发的问题。这些问题在刘先生看来，不但简单而且如果有心的话应该很容易上手，因此不胜其烦，加上开发的困扰，对请教问题逐渐变得不耐烦，甚至有一次对飞扬公司的开发人员吼到：“这么简单的问题都不会，你们真是猪脑袋!”，双方开发人员关系开始紧张起来。

　　事情发展下去越来越糟，飞扬公司将刘先生告到了高成公司上层，李先生不得不警告了刘先生，要求他必须保持耐心。不久，鉴于刘先生在项目中被客户投诉，高成公司在例行的加薪中没有给刘先生加薪，这些令刘先生怒不可遏，本来开发就挺累的，累了还不值，公司没有重视他的价值，于是萌生了跳槽的想法。在后来的开发中，他没有象开始那么积极和负责了，整个项目的开发开始陷入了不正常中。

　　项目就在双方开发人员的三心二意中继续，本来确定的上线日期却因为开发的未完成和项目方案的反复调整而一拖在拖。眼看如果再不上线，整个项目将严重滞后，李先生不得不强行上线，留下一堆尚未开发完善的程序等待测试。此时，刘先生收到了一家猎头公司发来的邀请，于是向公司提出辞职，尽管公司竭力劝阻和利诱，但去向已定的刘先生没有动心，坚决辞职。高成公司不得不从其它项目抽调技术人员来接刘先生的手。项目上线后，业务部门在使用中，相关的开发程序逐渐暴露出了问题，不是今天这个报表运行出错，就是明天那个功能计算有误，整个项目小组陷入救火当中，尽管开发人员对前期由刘先生开发的程序进行了修修补补，但问题还是层出不穷，陈先生不时接到业务部门的抱怨和不满，整个企业迷漫了对ERP失败的看法，原来美好的愿望在现实中被击的粉碎。

　　项目开发彻底瘫痪

　　面对如此尴尬局面，不得已，陈先生将电脑部开发所有的开发力量集中于ERP项目，并要求开发人员加班加点，指望能够扭转颓势。但是，电脑部的一些开发人员变的不满，本来开发待遇就低，做相同的工作拿的比研发部门少的多，现在又加班，又没什么激励措施，干多干少一个样，有的人开始消极怠工，一张报表做个十天八天，稍有难度的开发就推给顾问。不久，高成公司的顾问逐步撤出项目，双方开始了邮件打仗，你推给我，我推给你，一个问题解决需要很长时间。

　　随着时间的推移，飞扬公司开发人员逐步变得熟练起来，开发的程序慢慢变得完善。但没过多久，随着业务部门对系统的熟悉，一些新的需求被提了出来，面对这些需求，除了继续开发还能有什么办法吗?电脑部的一些开发人员变的更加不满，开发后又改来改去，感觉工作没什么意义，有的人开始考虑跳槽，提出了辞职。在这个节骨眼上提出辞职，陈先生当然不会批准，只有拖延，整个项目开发再次陷入停顿。

　　故事剖析

　　通过对上面的项目实施开发情况分析，哪些是可以借鉴的经验呢?

　　首先，作为一个项目来说，保持相对稳定的开发队伍是非常关键的。如果人员频繁的流动，没有相应的奖惩措施，那么无法调动积极性，也就无法进行持续的开发;

　　其次，作为实施相对成熟的ERP系统，开发可以带来相对方便的功能，但如果是没有足够的开发和实施力量，那么软件被改的面目全非，正常的功能不能使用，而且开发的新功能不完善，出现问题频频，严重影响使用;

　　再次，企业需要知道开发什么，如何开发。作为实施ERP来说，改善企业的管理是一个逐步的过程，需要一定的积累，如果由于使用的不便等原因而对系统改这改那，很容易犯了拆东墙补西墙的错误，导致软件开发了客户却不能用不愿用的尴尬局面。

　　那么，如何判断开发需求呢?以下有几个原则需要注意：

　　系统中不能提供功能需要开发：例如系统不提供生产线员工的生产统计，而只能粗放的管到生产线，这时，系统就需要进行开发。

　　涉及到流程的可以缓改：某些无关痛痒的流程的完善，如某些单据的审核流程可以缓改，或用手工的方式去控制。

　　涉及到报表开发，需要分情况处理：报表的改动是最多的，几乎70%的定制开发工作量都在报表的修改上，许多用户很多情况下不了解系统中提供什么样的报表或者是不习惯系统中的报表就提出开发。这时，判断是否需要开发的依据是：影响业务流程报表就需要及时开发，如：供应商入库报表、销售统计报表等，这些报表能够连贯企业的流程，是业务管理所必须的。而有些报表则属于锦上添花，不影响业务流程，这时就需要根据开发力量和时间安排合适的时间开发。

　　对于界面的调整，可以缓改或者不改：常见问题就是用户对系统的界面不满意，例如录入的金额没有千位符，想改，录入框没有按录入顺序排列，想改成按顺序等等。