实施CRM的感受:小系统的大问题

长宁+

CRM注重的是与客户的交流，企业的经营是以客户为中心，而不是传统的以产品或以市场为中心。

A公司是国内一家著名的证券公司，在信息化方面已经投入相当大，也取得了一定的成果。为了更好地为客户服务，公司决定上一套计算机系统。经过反复的接触之后，A公司选择了一家国内CRM厂商B，来为其总部实施一套SFA（销售自动化）系统。公司购买的只是B公司CRM产品的一个模块，而且该系统的实施对公司本身的业务流程并不产生很大的影响，双方都认为实施起来应该会很顺利。但是，作为A公司该项目IT负责人的姚先生，却对这个小系统实施过程中的一场风波至今记忆犹新。

平常的开端

起初，姚先生和技术部门的同事被召集起来，和公司新成立的机构部业务人员一起组成项目组，着手上一套小型系统。

进入项目组，姚先生很快发现机构部对这个小系统的期望和热情特别高，大有要借这个系统大干一番的意思。原来，机构部是公司专门针对核心客户——机构客户设立的，是所有后台业务部门服务的窗口。以前，公司的客户服务是围绕业务来走，因此同一个客户的信息由不同部门掌握着，如投资银行、理财或者基金等。公司对客户信息分散的、孤立的处理，导致沟通不畅，甚至发生“内讧”。很说明问题的一件小事是，到中秋节，一个大客户代表会收到来自公司不同部门的十几盒同样的月饼。客户就会抱怨：“你们就不会商量一下再送吗？”

随着行业的整顿，证券行业利润日益变薄，有些同行甚至已经倒闭，公司不能容忍大客户服务的这种局面，所以成立了机构部。机构部在怎么和业务部门协调、把后台的服务传递给客户方面，感到比较吃力，因此就希望借助一套系统来实现。

B公司是一家CRM软件的开发商，和A公司的某个营业部曾经有过合作。姚先生听说，B公司了解到机构部的需求后，很快地派出了阵容强大的咨询团队，包括公司的总经理和副总经理，一次次给机构部人员讲解客户关系、销售机会、营销管理等理念，以及本公司的系统架构和功能等。最后，机构部决定选用B公司CRM产品中的SFA模块。

姚先生和其他技术人员没有参与前期的培训，而是在业务部门确定了意向产品后，考察了B公司产品的技术水平，估算了项目时间。在姚先生看来，这不过是一个几十万元的小系统，和公司正在进行的数据大集中相比，实施难度实在不值一提。抱着这样的想法，双方很快签订了合同，信心十足地进入了实施阶段。按照合同规定，项目应该在6个月里全部完工。

痛苦的过程

项目进入实施阶段，B公司的开发小组花了相当长的时间用于需求调研和分析。作为客户方面的技术人员，姚先生在其中充当着沟通业务和技术的角色。虽然比预想的辛苦了很多，看到B公司提交的几乎具体到每个界面的设计报告，姚先生觉得还是值得的。

项目进入编码阶段后，姚先生听到更多的是机构部的抱怨，项目初期的热情和信心逐渐消失了。这时候，B公司项目组完全都由开发人员组成，咨询顾问们已经完全撤出去了。让业务部门感到气愤的是，开发人员对A公司的业务理解不透彻，在知识水平、言谈举止和交流技能上和咨询顾问相比实在有很大的差距，也不能对业务部门提出的需求做出及时的反应。而且，项目进行到一半的时候，B公司的项目经理跳槽，给项目进展造成了很不利的影响。项目开始前的期望和现实情况很快形成了落差，姚先生觉得这就给后来冲突的升级埋下了伏笔。

按照计划，项目在四个月后进入了试运行阶段。尽管初期的需求设计很详细，但看和说与真正操作起来有很大的不同。B公司以往的客户基本上没有证券行业的，因此一些细节问题就没有考虑到。比如，机构客户的信用卡账号，在B公司原来擅长的行业十分重要，但对重在服务而不是交易的机构部就没有必要放在基本信息栏和优先显示的位置。

机构部提出的修改意见，都通过姚先生提交给了对方的开发人员。但是，B公司的开发基地设在另外一个城市，一般至少要一星期之后，姚先生才能收到B公司开发中心用特快专递发来的修改后的编码。急于把系统尽快用起来的机构部十分不满，这也给姚先生带来了很大的压力，因此便对B公司开发小组正面提了出来，但是问题始终得不到解决。眼看6个月就快过去了，姚先生和机构部负责人都觉得，问题已经到了无法忍受的地步了。

在项目小组会议上，姚先生听到的是一片愤怒之声，大家纷纷列举了A公司在项目实施中的种种问题，主要是对业务理解不透、回馈周期太长等。会议讨论的结果就是将向B公司的高层进行投诉，将问题都摆出来。根据会议结果，姚先生主笔拟了一份多页的直接面向B公司老总的措辞激烈的信件。

在信中，姚先生指出，B公司在项目前后期行为很不一致，大有“欺骗”的嫌疑,且一一历数了B公司的“罪状”。项目确定之前，B公司派出一批又一批的教授、博士和行业专家，天花乱坠地描述了客户关系管理的先进思想，大谈销售机会和价值等理念；在项目的需求分析阶段，也派出了经验丰富的顾问人员，对用户所需要的系统的功能也进行了详细的规划；而到了项目后期，就只有开发人员负责，而这些人“离我们的期望值太远了”。

投诉信交到对方客户经理手中，在B公司引起了很大的反响。姚先生后来听说，这封信很快转到研发部门负责人和公司老总的手中。B公司召开了紧急会议，对问题进行了讨论，并制定相应的对策。

问题的解决

B公司调整后的结果很快就有了反应。按照原来的流程，对客户提出的问题，修改结果是刻盘后再通过特快专递送到用户手中，前后需要大约一周时间。针对这种情况，B公司为A公司设立了客服终端，姚先生这下可以直接提交和管理自己的需求。开发中心修改完成后，通过电子邮件发送，响应周期一下子就缩短了3-4天；此外，B公司把咨询顾问重新调回到项目组，而且以后都要对项目进行全程跟踪。另外，对开发人员的工作也进行了一番调整。首先要求他们和咨询顾问一样统一着装，对言行举止都制定了统一的准则，最为关键的是，研发人员对客户递交的文档都有了严格和统一的规范。

经过仔细认真的讨论和沟通，并做出实质的努力之后，大家的火气消下来了，项目继续进行，并最终并在预期的6个月里通过客户的最终验收。

平静后的反思

这个原本认为很简单的项目，却发生了这么不愉快的一段插曲。在系统投入运行后的半年，姚先生和对方谈起这一幕，大家都有很多的感触。

姚先生觉得，沟通是项目成功最关键的要素。在整个过程中，机构部一直显得相当急躁，恨不得系统买来后很快就可以用起来。在实施才一两个月后，机构部就要求先将已完成部分投入使用，而没有想到不完整的系统是发挥不了有效作用的。对于B公司的工作态度和工作方式，姚先生还是十分认可，特别赞同的一点是，B公司在项目前期的需求分析阶段花费了相当长的时间，也投入了很多的人力，可以说，最重要的工作都在编码之前得到了很好的安排。

之所以最后出现试运行阶段的问题，主要也因为还有一些问题不到真正使用阶段是发现不了的。对于B公司后来的快速响应和调整，姚先生还是相当满意的。问到机构部使用的情况，姚先生得到的回答是“过程是痛苦的，结果还可以”。

最近，公司又打算在其他方面上一个辅助性的信息系统，也继续在与B公司沟通。姚先生感觉到，过去的冲突现在看来不一定是件坏事，起码大家增进了解了，以后的合作会更加顺畅一些了。

endprint