1. 首页
  2. 互联网资讯

CRM项目需求变更带来的麻烦

  有位英国学者说过,任何变更,即使是向好的方向变更,也总是伴随着挫折与痛苦。这句话,真是金玉良言呀,一语道破了项目需求变更过程中的烦恼。这个烦恼不仅是我们实施顾问所有的,企业客户也照样有这烦恼。

  一、项目需求变更可能导致实施成本的增加。

  项目需求变更往往伴随着企业CRM 项目实施成本的增加。如你可能想在客户信息上加一个字段,然后把这个字段带到销售订单上去。这用户想来可能比较简单,但是,其实一点也不简单。作为后台开发人员,要考虑这个字段的类型,如是数字类型还是字符类型;要考虑这个字段会不会参与后续的运算;要考虑这个字段时必填字段又或者是可选字段;要考虑在开立销售订单时,选择客户时,是否要判断客户信息上有否这个字段的内容,及销售订单是否允许更改这个字段的内容,若可以更改,则更改后是否允许其自动更新客户信息中的这个字段的内容。所以,看客户这么简单的一个需求变更,就要考虑这么多的因素,则代码的数量是很庞大的。若按代码量来考虑这个二次需求变更带来的成本,也是比较可观的一笔费用。可能一个需求变更的成本比较小,但是,需求变更多了,其累计的成本就非常大了。

  二、项目需求变更可能延长项目的实施周期。

  需求变更若只是成本的增加,企业可能还可以接受。但是,若其导致CRM项目无法按时上线,那对于企业来说,就不这么容易接受的了。

  如我一次给客户实施CRM项目,其在系统双线并行阶段,提出需要变更一个客户投诉处理的相关需求,而这个需求光靠系统配置无法完成,需要通过二次开发来完成。而且,用户在项目实施过程中,还不能妥协,一定要等这个开发完成后,才能结束双线运行,放弃手工帐。后来经过我多次的劝说,用户才有所退步。除了客户服务部门外,其他部门在一个月后都放弃了手工帐,而客户服务部门,再二次开发完成后才放弃了手工帐,这比原先的计划整整推出了一个月。我们都知道,双线并行就相当于增加了一倍的工作量,那客户服务部门的人员,当然非常不满意了,对CRM系统的印象也就不好了,把气都出在这个系统上面。最后,项目虽然顺利竣工,但是,比预先的计划整整迟了一个月。

  所以,项目需求的变更往往伴随着项目实施周期的延长。

  三、项目需求变更会增加CRM项目的风险。

  CRM作为一个大型的信息化企业管理系统,其实施风险本来就比较大。若在中途再有比较多的项目需求变更的话,那风险毋庸置疑,会成倍的增加。

  不从技术上,就从员工对于需求变更所带来的不利影响,从而增加了他们对于系统的抵制,我们就可以看到需求变更对CRM项目的风险。如上面我遇到的这个需求变更,由于项目变更延长了双线并行的时间,给客户服务人员增加了成倍的工作量,虽然这个需求变更对于他们后续的工作,是非常有利的;但是,在中间这个过程中,他们是非常反感的,而且,很不配合。最后,要不是有上面的强制性要求,后果就不堪设想了,很肯能,CRM项目就会因为客户服务部门的抵制,而导致项目最终以失败告终或者影响其最终的实施效果。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

发表评论

登录后才能评论