[原创]没完没了的ERP

作者：saily

2009/11/17 11:36:20

[ 案例一]黄工负责某公司ERP项目的实施工作，率领项目组进驻该公司进行实施一年了，按照计划项目应该进入收尾阶段，但项目从试运行那天起，用户就不断的提出新的需求，似乎总有新的需求需要做二次开发，客户方项目经理在使用系统时也总经常把自已的新思路讲给黄工听，要求黄工优化系统的功能，项目变成了一个无底洞，没完没了的往下做，黄工要求验收，但客户认为系统的功能没有满足需求为由推迟验收，要求继续完善，黄工查阅了项目合同，而合同中并没有对需求的详细描述。此时，该公司高层人事发生变动，原来的老总被调走，新来的老总上任后进行了一系列的管理改革，依据这些管理改革，系统的一些功能肯定又要做出比较大的修改，而且要命的是这些功能似乎仍在合同规定的范围之内，这些功能的需求开发需要大量的时间和人力。

1.本项目中存在的主要问题

2.怎么解决现在的问题

3.怎么防止类似的问题出现

[案例二]刘工承担了A公司的一个ERP项目，在项目实施过程中，系统需求似乎永远无法确定，用户说不清自已的需求，怎么做他们都不满意，功能不断增加，用户上周说要这个功能，今天说要这个功能，李部长说这个功能该这样做，而五总经理认为这样做不行，结果让刘工无所适从，项目已经进行了两年多了，项目何时结束还处于不明确的状态，因为用户不断的有新的需求提出来，项目组只有根据用户的新需求不断去开发新的功能，大家被这样的项目搞得疲惫不堪，痛苦万分。

1.造成这个烂摊子最主要的原因是什么？

2.而对这种混乱局面你会怎样处理？

3.很多ERP项目都在这上面栽过跟头，很多ERP文章都认为企业在上ERP之前应该先搞清楚需求再上ERP。你认为呢？

[案例三]周工承担了某公司ERP项目的实施工作，项目按计划推进，一年之后周工提出来要进行项目验收，客户认为系统没有达到当初软件销售人员所承诺的目标，还有很多功能模块没有实施，双方为系统的范围问题开始不断争论，周工通过了解得知当初销售人员为了尽快签单，口头承诺了很多现在系统并没有的功能，有的甚至实现起来困难非常大。周工认为如果按照客户所描述的目标再做上一年也不一定能完工。周工检查了ERP合同，合同中并没有客户所讲的功能目标。

1.你要是周工面对项目目前情况你怎么处理？

2.“买的没有卖的精”ERP销售人员关心的只是成交，而实施人员和客户更关注成功，成交与成功的矛盾怎么化解？

3.这种情况似乎永远存在，用项目管理方法怎么解决此类问题？

[案例初步分析]需求曼延是很多ERP没完没了最主要的原因之一，以上案例问题的根本原因是缺乏对项目范围的有效管理,项目范围管理包括对项目范围规划，项目范围的定义,工作结构的分解,范围验证,项目范围的变更控制,项目范围定义是建立在项目的需求上,目前很多ERP项目都是在需求不是很清楚的情况下就开始的,很多ERP在实施期间客户会提出大量的需求,必然会引起项目范围的频烦变化,如果不对项目的需求和范围进行有效管理,就会出现以上项目问题.

项目范围说明书详细描述了项目可交付物和产生这些可交付物所必须做的项目工作,项目范围说明书在所有项目干系人之间建立一个对项目范围的共识,描述了项目的主要目标,使团队可以更详细的规划,指导团队在项目实施期间的工作.所以项目从启动到最后收尾都需要进行项目范围进行全生命周期的管理.ERP项目在一开始确实很难搞清楚需求,其实软件项目都是如此,但不能因为很难搞清楚需求就不进行项目的需求和范围管理,恰恰相反越是这样越有必要进行项目的需求和范围管理,如果一个项目没有一个共识的目标和范围,那么这个项目一定不会取得成功,因为连成功的标准都没有.

做得最好的范围,最好的计划,在实施的过程中也会产生很多变化.我们对项目的范围和需求产生的变更进行管理并不是控制变化的产生,而是让变化按照预定的流程进行管理,降低变化给项目带来的影响,也使得变化在所有项目干系人之间达成一致.以我的经验ERP的实施,尤其是现场进行二次开发的ERP项目.对于需求的变化是相当随意的,为了极大的满足用户的需求,我们往往连最基本的变化记录都没有.这为项目的需求曼延创造了有利的条件。如果按照项目管理方法论，一个严格的范围变更流程是必须经过变更申请的提出，变更申请的评估，变更申请的批准，实施变更，变更验证，直至最后的归档。而且这些需要有一个对变更进行文档配置管理的平台。这需要我们认真考虑效率和效果之间的平衡。

一个成功的项目必然离不开对项目的范围,进度，成本，质量所进行的有效管理。一个成功的ERP公司必须将对项目管理的重视提升到公司的战略层面。建立一个项目管理体系和对所有员工进行项目管理知识的培训是公司提高生产率，改善客户关系管理，完成知识积累将起到决定性的作用。

责编：姜玲