需求变更

ERP实施中最恐怖的事情：需求变更

Posted by compsoft on 2009-4-22 14:47:24View 259Comments2

辛辛苦苦熬了几个月的通宵，终于确立了ERP需求，规范了工作流程，系统配置也完成了，正准备按部就班ERP系统上线时，企业用户突然改变了需求，不想这么做了，提出了新的需求。这对于ERP实施顾问来说，正如晴天惊雷，这也是所有ERP顾问最感到恐怖的事情。因为有时候，用户只是简单的一句话，但是对于系统的调整来说工作量是非常大的。

一．需求变更：迁就or拒绝？

从ERP项目立项开始，需求就是ERP实施顾问的心头之痛。随着对ERP的深入认识、项目环境的变动，企业内外部多种因素都可能使客户对ERP的需求不断改变。如果不能有效处理这些需求变更，项目实施进度必将一再调整，上线日期也会随之一再拖延，项目成员的士气也将越来越低落，严重的还会直接导致ERP项目失败。

需求变更，本应是客户的权力，但也是实施顾问的为难之处。如果确需变更，当然要满足客户需要。问题是不能让变更权力滥用，把一些无关痛痒的变更宠惯养成堂而皇之的变更。例如，我曾经在某ERP项目中属于“谦虚型”，对于客户提出的变更，无论大小都给予解决，客户对此非常满意。然而，项目进度却拖得很长，项目一再延期。相比之下，在另一个项目上我显得稍有些“盛气凌人”，对于客户提出的需求变更，大多都不予理睬，客户对此不是很满意。不过，该项目的进度控制得较好，基本能按期完成项目。

按后一种“盛气凌人”的做法，对客户的要求一概不理，自顾自地按照最初的需求和计划实施，很可能会由于没有用户的参与，使得ERP系统与用户的需求相差甚远，导致验收通不过，收不回尾款而使公司利益受损。对于客户来说，达不到需求的满足也浪费了投资。事实上，客户不满意，则项目就不算成功，实施顾问辛勤劳动最后就只能落得个“没有功劳，只有苦劳”的份。

但按前一种“谦虚型”做法，完全顺着客户的意见走，客户满意度就一定会高吗？其实也不一定。由于需求变更会带来工作量的大量增加，甚至可能会出现大量的无效劳动。而且，频繁变动的需求也会导致实施质量下降，留下许多隐患。因此，一味的迁就用户将会使进度一拖再拖，实施方案一改再改，变更越来越多，士气越来越疲，公司越来越不满意，用户越来越急。

二．需求变更为什么总是做不完？

在ERP实施过程中，实施顾问所要面对的将是一系列和多方面的考验。经常发生而又最令人头疼的恐怕就是需求变更了。客户变更需求是ERP项目与生俱来的特性，也是一个无法避免的事实。需求变更的表现形式是多方面的，如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。它会导致ERP实施过程中成本增加、进度拖延等风险，而且越往后的变更产生的风险将越大。

以笔者参与的多个ERP实施项目的实际经历来看：需求变更泛滥是非常可怕的事，尤其是到了项目实施后期，客户不断对移交的ERP系统提出修改意见，甚至有时刚刚重新完成的更改，客户又要求改回去或改成另一种模式。需求变更越来越多，实施顾问只能疲于应付。“无底洞”是大部分实施顾问进行ERP项目的共同感觉。

实施顾问作为项目的承担者，在规定时间内利用有限资源保质保量的完成项目，让客户和公司都满意是最终目标。但是让客户满意就是不断满足客户无穷无尽的需求吗？我们分析一下出现需求变更的根源。

ERP实施最恐怖的事情：需求变更2

（1）合同签订马虎，没有真正明白客户需求

签订合同时缺乏对客户需求认真对待，导致需求描述不清，为后期的实施工作带来困惑。ERP销售顾问为使客户能够快速的签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，往往是销售顾问一看“应该”只是一个小小的修改，没有太大的影响，所以直接答应能变更。

该问题的关键是合同签署的太烂，没有把需求明确再签合同，而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚，后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围，可以为以后各项实施工作的开展奠定深厚的基础。

（2）调研时没有深入理解客户需求

在ERP上线前的需求调研分析阶段，项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进行。更严重的是，实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案，没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导一拍脑袋提出新的需求时，实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分，双方对需求的理解就会产生差异，就会导致移交 ERP系统时才使问题暴露出来，客户只能频繁的提出需求变更。

（3）没有明确的需求变更管理流程

没有明确的需求变更管理流程，就会使需求变更变得泛滥。并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。比如ERP界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改没有严格把关流程，有些小需求看起来工作量不大，但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。

（4）没有让客户知道需求变更的代价

对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对实施顾问的辛苦就会难以体会。在评估代价过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。

三．如何有效控制需求变更？

需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。例如授权、审核、评估和确认，在实施过程还要进行跟踪和验证。有句通俗的话说得非常好：“需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”

用户需求的变更总是不可避免的，所以我们要以积极的心态去接受和控制用户的需求，而不仅仅是埋怨。对待客户频繁的需求变更，应采取有效办法应对，避免事态蔓延，不