该帖子同步发自：(riverstone的博客  访问该博客)

　　ERP项目的需求管理是项目成败的关键，因为ERP发展到今天，一些大众的功能各个ERP厂商已经没大的区别，所以，考验ERP的就是对个性的需求上。实施顾问能够最大程度的实现客户的需求，并不增大系统风险，就可以取得项目的成功和客户的认同。在ERP项目管理的中，需求贯穿了项目的整个生命周期。从ERP项目立项开始，需求就是所有项目经理的心头之痛。经验的增加、项目环境的变动，所有的因素都有可能使得员工对ERP、的要求不断改变。如果不能有效处理这些需求变更，项目计划必将一再调整，交付日期也会随之一再拖延，项目成员的士气也将越来越低落，所有这些都将直接导致ERP项目目标无法达到。所有这一切，决定了项目管理者必须拥有需求管理的技巧。

　　一、不要一下子满足所有新需求

　　对员工基础的需求，不要一下子就全部满足。这有些人会想不通，认为马上全部满足，不是会更好吗，员工不是更满意吗?从短时间来说这没错，但是从长久来看，不见得非常准确。

　　其实，这里我们利用了人的满足心理。我们先来假设一下，假设ERP实施一共要一年的时间，员工提出了十个需求，你其中8个需求在第一个月就全部实现了，而其他两个需求一拖再拖，到年底，你才把剩下的2个需求实现。那中间这10个月，项目经理的日子会很难过，员工的积极性会受严重打击，甚至会对你失去信心。

　　其实最好是平均一下，把这十个需求先按重要性排列一下，把重要的先实现。一般新需求，就算马上可以实现，也不要一起交付个员工。而应该平均一下，让员工每个月都感到有希望，有期盼。

　　其实，这个道理喜欢看连续剧的人非常了解。比如一部20集的电视剧，你今天看了第19集，明天就会感到非常牵挂，觉得还有事情要做。在项目实施中的目标就要达到这个效果，让员工对ERP项目有个牵挂。

　　二、新需求不能变更系统主流程

　　员工提出的任何需求，都不能变更系统主流程。系统主流程就象树的树跟，你想把树移个地方，很可能导致树的死亡。

　　笔者有同事给一家企业实施的时候，企业财务核算较简单，就把应付帐款流程省略了，直接从收货单跳到总帐。结果，造成付帐日期的混乱。最后，在同事的建议下，企业还是上了应收应付模块，先走应付流程，再入总帐。

　　我们上ERP最重要的一个目的就是通过ERP系统的标准流程来进行业务流程重组，若我们把主流程都改了，那还不如找个软件公司，来公司定制开发，来的省时、省力、省钱。

　　三、ERP实施顾问不能随便承诺

　　对员工提出的需求，实施顾问要仔细考虑，不能随口承诺，最后不能兑现时，会让员工失望。人的思想同计算机语言毕竟是有区别的。

　　如办公用品的管制。每个公司都会有办公用品，这些物品价值不是很大，并且种类繁多，有些还没有固定的供应商，甚至价格都不能确定。管制这些东西比管制生产物料还有困难。按照人的思维好象办公用品也是请购-采购-入库-付款这么简单，其实没有人想的这么简单。所以，当员工提出这个需求时，顾问要调查企业办公用品的月采量有多少，流程是否规范。若采购量很少，或则平时就很少规范，那就考虑建议企业不要把这个流程放入ERP，或者等到二期。

　　四、需求要分轻重缓急

　　业务流程重组和需求调研完成后，ERP实施顾问手里就会有一大堆的新需求。这时，最忌讳的就是哪个最简单的，就先实现拿一个。而应该是那个最重要，最有影响力，就要先实现它，以达到很好的短期效果。

　　五、需求需要沟通

　　ERP项目跟其他项目有一个重大的不同，就是更改难道比较大。所以，我们在确定一个需求前，要跟当事人充分沟通，最好能直接沟通，避免因传达失误所引起的重复工作。

　　在沟通时，双方对需求的认识要一致，不能模棱两可。笔者在此就有一个惨痛的教训。

　　那时，我给一家企业做实施。ERP实施成功后，我主要是跟他们IT主管联系。一次，他发给我一个需求，说是要根据“销售定单变更单”自动修改未审核的“生产单据”。但是，IT主管在传达的时候，没有传达清楚，把“未审核”去掉了，结果需求变为了根据“销售定单变更单”自动修改的“生产单据”。最后，销售定单不通知生产部门也可以随意更改，导致了生产的错误。

　　后来，他们向我反映问题时，我知道出问题了。我马上赶到公司，跟他们开会重新确认需求。原来他们的本意是：根据“销售定单变更单”自动修改未审核的“生产单据”，对已经审核的生产单据不能自动修改，而要销售部门通知生产部门在进行修改。

　　这个案例给我一个深刻教训，做二次需求，一定要“亲自上战场”，而不能听“奏折”。

　　六、需求要注意风险

　　为了降低ERP二次开发的风险,应仔细评估所有涉众的需求，确定开发风险,并对项目进行风险管理。有的项目人员仅仅重视自己感兴趣或觉得有挑战性的需求，而不是及早将精力投入降低项目风险或提高应用程序功能性方面。为确保尽早解决或降低项目中的风险，要慎重选择需求，以确保每次增加的需求都不会加大项目中的已知风险。要达到目的,你需要对项目进行风险评估，并在风险和重要性两个层面取得平衡。