一、项目需求变更可能导致实施成本的增加。
项目需求变更往往伴随着企业CRM 项目实施成本的增加。如你可能想在客户信息上加一个字段，然后把这个字段带到销售订单上去。这用户想来可能比较简单，但是，其实一点也不简单。作为后台开发人员，要考虑这个字段的类型，如是数字类型还是字符类型;要考虑这个字段会不会参与后续的运算;要考虑这个字段时必填字段又或者是可选字段;要考虑在开立销售订单时，选择客户时，是否要判断客户信息上有否这个字段的内容，及销售订单是否允许更改这个字段的内容，若可以更改，则更改后是否允许其自动更新客户信息中的这个字段的内容。所以，看客户这么简单的一个需求变更，就要考虑这么多的因素，则代码的数量是很庞大的。若按代码量来考虑这个二次需求变更带来的成本，也是比较可观的一笔费用。可能一个需求变更的成本比较小，但是，需求变更多了，其累计的成本就非常大了。
二、项目需求变更可能延长项目的实施周期。
需求变更若只是成本的增加，企业可能还可以接受。但是，若其导致CRM项目无法按时上线，那对于企业来说，就不这么容易接受的了。
如我一次给客户实施CRM项目，其在系统双线并行阶段，提出需要变更一个客户投诉处理的相关需求，而这个需求光靠系统配置无法完成，需要通过二次开发来完成。而且，用户在项目实施过程中，还不能妥协，一定要等这个开发完成后，才能结束双线运行，放弃手工帐。后来经过我多次的劝说，用户才有所退步。除了客户服务部门外，其他部门在一个月后都放弃了手工帐，而客户服务部门，再二次开发完成后才放弃了手工帐，这比原先的计划整整推出了一个月。我们都知道，双线并行就相当于增加了一倍的工作量，那客户服务部门的人员，当然非常不满意了，对CRM系统的印象也就不好了，把气都出在这个系统上面。最后，项目虽然顺利竣工，但是，比预先的计划整整迟了一个月。
所以，项目需求的变更往往伴随着项目实施周期的延长。
三、项目需求变更会增加CRM项目的风险。
CRM作为一个大型的信息化企业管理系统，其实施风险本来就比较大。若在中途再有比较多的项目需求变更的话，那风险毋庸置疑，会成倍的增加。
不从技术上，就从员工对于需求变更所带来的不利影响，从而增加了他们对于系统的抵制，我们就可以看到需求变更对CRM项目的风险。如上面我遇到的这个需求变更，由于项目变更延长了双线并行的时间，给客户服务人员增加了成倍的工作量，虽然这个需求变更对于他们后续的工作，是非常有利的;但是，在中间这个过程中，他们是非常反感的，而且，很不配合。最后，要不是有上面的强制性要求，后果就不堪设想了，很肯能，CRM项目就会因为客户服务部门的抵制，而导致项目最终以失败告终或者影响其最终的实施效果。
可见，CRM项目需求变更，对CRM项目来说，是非常不利的。那我们如何才能把这个损失减少到最小，甚至是消除在项目实施过程中需求变更情况的产生呢?
一、需求变更要尽早，越到后面其成本、风险等影响越严重。
当需求变更情况发生后，我跟一些用户沟通，问他们为什么以前没有提出来呢?很大一部分用户说，他们之前也发觉了这个问题，只是那时候认为这个需求不是很重要，可有可无，就没有说了;但是，没想到，现在系统余越来越熟悉、越用越好，这个问题也慢慢变大了，觉得非要实现不可，否则的话，工作就进行不下去了。
其实，这个问题很多企业都存在。确实，手工作业跟系统自动作业存在比较大的差异，有些手工业下，可能不是什么大问题;但是，一到利用管理系统进行自动化作业的时候，就发现这个问题成为了信息化作业的大障碍了。这种情况不仅一个企业存在。
但是，从信息化项目角度来讲，这是一个很危险的信号。为什么呢?我们造房子，若在房子快造好时，发现原先设计不对，需要重新推翻重造，那成本与时间的浪费，是不可估量的了。对于CRM项目来说，也是类似的道理。若你项目快要完工时，才发现原先的需求有错误，需要变更，那损失就会很大。所以，项目越接近尾声，再进行需求变更的话，则给企业的损失会越大。
所以，我们要充分做好前期的需求调研、系统演示、系统培训工作，争取通过这些工作，最大程度的挖掘用户的潜在需求，发现可能要需求变更的地方，让用户尽快做出是否要进行需求变更。我在实施项目的过程中，一般把需求变更或者新需求的确认时间最迟定在系统培训阶段。也就是说，在系统培训完成后、开始准备双线并行前，企业用户还可以提出需求变更的申请;但是，当系统开始双线运行时，就不允许用户再提出需求变更等类似的请求了。这以后任何的新需求、需求变更等，都要放在项目上先后再进行。当然，这靠顾问一个人的力量是不够的，我一般在项目实施中，就会跟企业负责人协商，告诉他们需求变更可能带来的风险。让他来下这个死命令，这比我在台上上几百几千句要有效的多。
总之，需求变更越早发现越好。越迟发现的话，无论是项目的时间、成本还是项目风险，都会增加很多。
二、需求变更若无法在短时间内解决，要采取比较折中的方案。
当我们遇到有些需求无法在短时间内解决，需要花个把月才能解决的时候，那我们就不要占牛角尖，不要在一棵树上吊死，而要想一下，有否临时的折中方案可以先“应付”一下;一边使用系统一边进行二次开发。
这么做，主要是为了减少需求变更对于项目周期的影响，为了保证CRM系统可以按时上线。有时候，为了保证这个大目标的实现，我们，无论是实施顾问还是企业，做出这一点妥协都是值得的。
如很早以前我有一次遇到一个客户。在项目快培训完的时候，客户企业的销售总监问我我们的系统中有没有客户漏斗管理模型。客户漏斗管理工具在现在的CRM 系统中是比较普遍的，但是，在几年之前的CRM系统中，还是凤毛麟角的。因为客户漏斗管理模型的设计，不仅仅是功能上的区别，而且，对于后台的技术也有比较高的要求。以前多采用C/S(客户端/服务器)模式的CRM软件，无法实现这个功能。而我们虽然刚刚开始采用B/S(浏览器/服务器)模式，还没有考虑这个功能。
该怎么办呢?用户有两个选择，一是进行二次开发，实现漏斗管理模型，但是，这无疑会增加很多的实施成本，而且，这么复杂一个管理模型，也不是一两天可以做的出来的，没有个几个月的时间，很难实现。第二个选择就是先不用漏斗的图形化管理，而只提供一些报表数据，销售漏斗管理等我们下次系统升级时，优先帮企业升级实现这个功能。如此，这个升级因为属于版本的升级，企业不用花费一分钱。
该如何抉择呢?我给销售总监展示了模拟销售漏斗管理的相关报表、表单。他发现，虽然利用报标、表单没有像图形工具这么方便，但是，从时间、成本等多个因素考虑，这个“不方便”还是可以接受的。所以，接受了我们的第二种处理方案，先迁就一点用着，等到我们系统升级后，再利用销售漏斗来管理。
需求的变更，对于项目的影响是非常大的。但是，就如同天要下雨一样，我们无法从根本上加以消除。我们所能够做的，就是采取一些行之有效的工作，把这个几率降至到最低;或者采取一些补救措施，把需求变更给CRM项目带来的损失减到最小。