如何才能把这个损失减少到最小

可见，CRM项目需求变更，对CRM项目来说，是非常不利的。那我们如何才能把这个损失减少到最小，甚至是消除在项目实施过程中需求变更情况的产生呢?

一、需求变更要尽早，越到后面其成本、风险等影响越严重。

当需求变更情况发生后，我跟一些用户沟通，问他们为什么以前没有提出来呢?很大一部分用户说，他们之前也发觉了这个问题，只是那时候认为这个需求不是很重要，可有可无，就没有说了；但是，没想到，现在系统余越来越熟悉、越用越好，这个问题也慢慢变大了，觉得非要实现不可，否则的话，工作就进行不下去了。

其实，这个问题很多企业都存在。确实，手工作业跟系统自动作业存在比较大的差异，有些手工业下，可能不是什么大问题;但是，一到利用管理系统进行自动化作业的时候，就发现这个问题成为了信息化作业的大障碍了。这种情况不仅一个企业存在。

但是，从信息化项目角度来讲，这是一个很危险的信号。为什么呢?我们造房子，若在房子快造好时，发现原先设计不对，需要重新推翻重造，那成本与时间的浪费，是不可估量的了。对于CRM项目来说，也是类似的道理。若你项目快要完工时，才发现原先的需求有错误，需要变更，那损失就会很大。所以，项目越接近尾声，再进行需求变更的话，则给企业的损失会越大。

所以，我们要充分做好前期的需求调研、系统演示、系统培训工作，争取通过这些工作，最大程度的挖掘用户的潜在需求，发现可能要需求变更的地方，让用户尽快做出是否要进行需求变更。我在实施项目的过程中，一般把需求变更或者新需求的确认时间最迟定在系统培训阶段。也就是说，在系统培训完成后、开始准备双线并行前，企业用户还可以提出需求变更的申请;但是，当系统开始双线运行时，就不允许用户再提出需求变更等类似的请求了。这以后任何的新需求、需求变更等，都要放在项目上先后再进行。当然，这靠顾问一个人的力量是不够的，我一般在项目实施中，就会跟企业负责人协商，告诉他们需求变更可能带来的风险。让他来下这个死命令，这比我在台上上几百几千句要有效的多。

总之，需求变更越早发现越好。越迟发现的话，无论是项目的时间、成本还是项目风险，都会增加很多。

二、需求变更若无法在短时间内解决，要采取比较折中的方案。

当我们遇到有些需求无法在短时间内解决，需要花个把月才能解决的时候，那我们就不要占牛角尖，不要在一棵树上吊死，而要想一下，有否临时的折中方案可以先“应付”一下;一边使用系统一边进行二次开发。

这么做，主要是为了减少需求变更对于项目周期的影响，为了保证CRM系统可以按时上线。有时候，为了保证这个大目标的实现，我们，无论是实施顾问还是企业，做出这一点妥协都是值得的。

如很早以前我有一次遇到一个客户。在项目快培训完的时候，客户企业的销售总监问我我们的系统中有没有客户漏斗管理模型。客户漏斗管理工具在现在的CRM 系统中是比较普遍的，但是，在几年之前的CRM系统中，还是凤毛麟角的。因为客户漏斗管理模型的设计，不仅仅是功能上的区别，而且，对于后台的技术也有比较高的要求。以前多采用C/S(客户端/服务器)模式的CRM软件，无法实现这个功能。而我们虽然刚刚开始采用B/S(浏览器/服务器)模式，还没有考虑这个功能。

该怎么办呢?用户有两个选择，一是进行二次开发，实现漏斗管理模型，但是，这无疑会增加很多的实施成本，而且，这么复杂一个管理模型，也不是一两天可以做的出来的，没有个几个月的时间，很难实现。第二个选择就是先不用漏斗的图形化管理，而只提供一些报表数据，销售漏斗管理等我们下次系统升级时，优先帮企业升级实现这个功能。如此，这个升级因为属于版本的升级，企业不用花费一分钱。

该如何抉择呢?我给销售总监展示了模拟销售漏斗管理的相关报表、表单。他发现，虽然利用报标、表单没有像图形工具这么方便，但是，从时间、成本等多个因素考虑，这个“不方便”还是可以接受的。所以，接受了我们的第二种处理方案，先迁就一点用着，等到我们系统升级后，再利用销售漏斗来管理。

需求的变更，对于项目的影响是非常大的。但是，就如同天要下雨一样，我们无法从根本上加以消除。我们所能够做的，就是采取一些行之有效的工作，把这个几率降至到最低;或者采取一些补救措施，把需求变更给CRM项目带来的损失减到最小。