老大要做CRM – 解密IT需求调研的各种问题

标签:CIOCRM需求管理

访客:91058  发表于:2013-05-06 15:18:01

一家证券研究机构A的最大老大出去参加了一个会议,回来要求IT部门做一个客户关系管理 CRM系统,要求将公司里面所有人(销售、研究员、各级领导)的客户关系集中管理起来,实现如下目标:

  • 兵对兵、将对将,全员销售
  • 生成全面的客户关系图,让销售容易发现一切可以利用的客户关系
  • 不要因为人员离职丢失了客户关系

都说ERP、CRM等IT项目是一把手工程,现在一把手主动提出要做,再大的支持也没有了。CIO将CRM系统建设当成了当年最重要的事,找了很多CRM供应商来介绍,给业务部门普及CRM教育,开阔思路;也安排人手到各个业务部门调研需求。随着调研的深入,CIO发现需求越来越多,越来越细,感觉像是一个大拼盘,没有了一个主心骨。除了老大要求的从上至下的客户关系图(希望兵对兵、将对将,全员皆Sales)外、每年的研讨会安排、相关杂志的发放、研究报告邮件的发送和确认、研究员的工作时间统计等等不一而足。由于需求的独特性,同时内部有20多人的开发团队,CIO决定找一个外包商在其已有平台上共同来定制开发。一年多后,系统上线了,这样一个一把手主动要求的IT项目反响如何呢?没有表扬,一把手也没有再提全员销售,似乎忘了这件事情。当然,大家都懂的,CRM项目的价值没有得到肯定,该项目其实是失败了。

全员皆销售当然是有价值的,但现实吗?怎么才能做到呢?有什么激励措施来助推该策略呢?细化的场景是怎么样的呢?本人做过10多年的销售,当我和该CIO交流的时候,第一时间听到从上至下的客户关系图就感觉不靠谱。当时就问CIO,提出这个需求的老大,会把自己的人际关系贡献出来,录入这个系统吗?怎么录入呢?标明XXX是同学、以前的同事、铁哥们、亲戚、老领导、以前的下属吗?老大以下的各级领导会把自己的关系网贡献出来吗?销售会把自己的关系网贡献出来吗?其实,CIO只要和负责销售的VP交流一下,就会得到和我多年销售一样的体会:销售只会在Review的情况下把客户各方面的信息补充全;销售在报销各种费用、年节送礼的时候,如果将其和客户关联,是一个很好的机会在系统中固化其关系网;销售条线的各级领导会根据项目金额的大小和重要性倒排序,如果项目够大够重要,他们如果有关系帮助赢单,是会亲自跳进来一起去拜访客户的;研究员如果同样有业绩压力(如Team Quota),是会将其关系网告知其配合的销售的。所以,所谓的从上至下的客户关系图就是正常不过的CRM中的Account录入,任何一个CRM系统都可以满足要求,其质量由Review保证;领导只会在项目标的大到有足够价值且有影响力的项目中发挥其客户关系。所以,对于该老大的从上至下的客户关系图期望不能太高,同时需要其制定日常的Review制度,通过层层review来保证将客户信息流转公司系统中。

CRM通常由市场、销售、服务三大块组成,销售最主要的是一个销售漏斗管理,标准的CRM都有的功能,为什么A公司还要定制开发呢?我和CIO继续交流,得到的答复是:A公司其实不是像IDC一样卖报告赚钱,每份报告也没有价格,而是基金公司(A公司的主要客户)如果觉得A公司的报告有价值,就会将其股票交易量的一定百分比交给A公司,A公司靠其佣金赚钱。所以对A公司来说,没有所谓的销售漏斗,重要的是客户要觉得A公司的服务(行业研究报告、研讨会、委托研究)有价值,相比其他海内外的研究公司更有价值,从而获得客户交易量更大的百分比。

那如何衡量服务的价值以及突出差异化呢?A公司的业务高层是如何看这个问题的呢?继续和CIO交流,得到如下信息:由于各种海内外的研究公司不断涌入,本土的研究公司不断涌现,一把手感觉到了不断增加的竞争压力,如何从服务的基金公司每年购买研究报告的预算中获得更多的份额,如何提升公司的业绩成为了一把手的心头大事。因为通常不可能有所谓杀手级研究报告,可以指导客户直接赚钱,所以对于基金公司来说,研究公司都没有所谓的功劳,大家拼的就是苦劳。A公司一把手去拜访客户高层时就被问到一年来提供了哪些服务,因此该一把手很自然地想到了解决办法,即希望IT系统能提供一个针对客户统一的服务记录统计(包括销售人员和高层的拜访、研究员提交的报告和调研记录及反馈、每年举办的研讨会、定期发送的杂志等等),一方面在高层拜访时可以向客户的高层详细展现自己公司服务不断增加的“苦劳”(没有功劳也有苦劳),另一方面可以通过客户反馈报告,评估这些服务中哪些客户更满意、更有价值、客户更看重,这样有针对性地调整内部资源,以获得最大的投入产出比。

至此,A公司一把手对于CRM的需求已经很清晰了,由于竞争的加剧,该老大要的是一个针对客户集中的服务记录统计(有统计数据,也要有亮点细节)和相关的满意度调查。把握住这一点,任何一个标准CRM(SaaS或On Premier都可以)有目的地配置一下,都可以满足。甚至连CRM都不用买或开发,用Window Server中内置的Sharepoint service配一个List(记录时间、本公司部门、人、客户公司、客户部门、客户人员、服务类别(研究报告、拜访、研讨会、杂志等)、服务内容、服务评级、服务反馈或证言、服务耗时、后续工作),让各部门的人(销售、研究员、满意度调查人员、其他服务人员等)在给客户提供服务时,在该List中记录一下即可。定期将该List数据导出到Excel,按照各个视角统计一下,排名,查找根源,就完全可以满足一把手的需求。如果用这种几乎零成本,半天即可完成的解决方案,相信一定会得到该老大的表扬。

大多数的IT项目估计都不可能得到如本案例一样的实质支持,一把手主动提出要CRM,但最终的结果仍然让人不满意,那么其他项目的结果更加可想而知。到底哪里出了问题呢?通过本案例,我们可以得到什么经验和教训呢?

1:一定要搞清楚真正的需求,即需求背后的需求(英文针对前一个需求用wants,即客户嘴里说出来的需求;针对后一个需求用needs,即客户心里真正想要的,甚至他自己还不清楚地知道。可惜,客户自己有时候对needs并不清晰,朦朦胧胧地有这种感觉,说出来就变成了wants;或者有些客户“爱思考”,他们会想我要的needs如何实现,要得到这个结果,我需要做1、2、3等几步,然后把123说了出来,成为他们的需求,却没有多说一句,把做123最终要达到的目的告诉你,我通常称这种行为为客户的需求翻译。而且可能由于认知的局限性,在需求翻译的过程中翻成了错误的123。总之,这两种情况都增加了你对客户真正needs把握的难度)。如何做到真正把握客户Needs呢?多问几个为什么,层层追问下去,直到发掘出其最本源的管理目的(针对企业应用而说)。本案例中经过层层追问,我们可以知道老大要做CRM的最终目的是竞争加剧的环境下获得更多的收入,方法有两个:(A)增加客户数量;(B)增加本公司在每个客户钱包中的百分比(share of wallet)。(A)需要增加更多的销售线索或项目盈率,所有要全员皆Sales;(B)要增加客户心中对A公司苦劳感知的占比,所以需要统计所有的服务记录。从更多的销售线索到从上到下全面的客户关系图这个说出来的需求wants就是一种有偏差的需求翻译。

2:搞清楚了真正的需求needs,也就了解了需求的价值。接下来要将needs层层分解成其实现的步骤wants,分解是否正确是一个关键问题,检验标准就是判断needs的价值是否可以实现。以本案例为例,从上到下全面的客户关系图能确保得到更多的销售线索吗?如果CIO本身有这种业务经验或知识,马上提出这种顾虑,相信一定会得到老大的肯定。如果CIO不清楚,可以去问销售副总裁或提出需求的老大(一个非常好的机会和业务沟通,取得一致理解和获得支持),也可以去Internet上查别人上CRM碰到的问题,相信销售不愿意贡献出来全部的销售线索和详细的客户信息是一个普遍的困扰。

3:如果最终对于需求或价值的把握还是朦朦胧胧的,其实对于该IT项目就应该放弃或者暂时搁置,等待以后需求和价值的明晰。如果不愿意放弃对其价值的追求,业务和IT都愿意赌一把,这时候科学地办法就是类似任何业务新产品的研发,做POC或原型去验证需求、验证价值。做POC或原型有两个关键,(1)是控制投入,尽可能用少的钱,尽可能聚焦在价值可能大的需求上;(2)迭代要快,最快地见到结果,完成验证,无论对错。软件开发中的Scrum方法的指导思想同样可以用于POC过程,一要快,最快时间见到结果去体验、去验证;二在每个spring迭代中怎么确定要实现的功能,价值大小就是一个主要依据。POC的过程应该发生在立项前,当然更是在和乙方签合同前。本案例中用Sharepoint service做一个POC系统,或者买2~3个用户的SaaS CRM应用来验证都是一种很好的对策,这也是CIO或IT部门价值最保守的体现,是其价值体现的自留地,因为这其中需要的专业知识正是CIO或IT部门的强项。

4:80/20原则同样适用于IT系统的建设,即80%的价值来源于20%的需求或功能,所以无论是在POC过程,还是POC成功后全系统的需求调研,都应该聚焦,其他需求无论是重要性还是紧迫性都应该居于次席。平均用力的结果增加了成本,也稀释了价值,影响了ROI,还降低了敏捷性,业务部门可以使用的系统上线的时间拖的越长,带来的需求变化的风险就越大。本案例中研究报告邮件的发送和确认做的很复杂,其实必要性不大,更大的可能性是相关部门想体现自己位子的重要性或保住自己的位子。

5:将4扩展一下,哪些需求属于聚焦的20%?其判断依据是价值大小,当然更科学的做法还有综合考虑重要性、紧迫性、成本、风险、难度等。当将每一个需求都从这些维度一一分析的时候,业务和IT都会首先选择价值大、风险小、成本小的需求,至于第二梯队的需求,就取决于各方的沟通、妥协和权衡。所以,价值等维度是一把尺子,时刻用来衡量需求在本IT项目中的取舍。按照这个原则,本案例中每年的研讨会安排、相关杂志的发放、研究报告邮件的发送和确认、研究员的工作时间统计等需求完全可以不做,或最简单地实现。

6:买钻头的目的其实是要墙上的洞。如果要的是大洞,买的是小钻头,还可以多钻几次,拼凑出一个大洞,但无疑要多花时间和力气;如果要的是小洞,买的是大钻头,这时要么干瞪眼,要么钻好的大洞再把不需要的地方堵上,也要多花力气和钱。最合适的是按照洞的大小买合适的钻头,很基本的常识。可是在IT项目上,这样的常识却经常被违背。对于一个IT管理系统,CXO或VP级别用的最多的其实是报表,尤其是分析型报表(技术上可能用通常的报表或BI技术实现)。可是大家经常会看到一期ERP、二期BI;一期BOSS,二期经分,理由是先要有数据,才能分析。似乎很有道理,可由此推导出实现的顺序应该是先数据,后分析就大错特错。因为CXO或VP等老大的需求才是最终的目的,所以需求设计的顺序应该是先分析,后数据,以终为始。当然,调研需求的时候,CXO或VP这一级一定不能漏掉,而且应该放到最前面,最重要的一环。本案例中搞清楚了老大为什么要CRM这个“终”,再碰到业务提出的邮件发送确认、研究员时间管理等需求的“始”,就可以很快判断出是否匹配。

7:国内IT项目需求调研时,常见的对象是基层骨干,因为他们是最容易调动来配合调研,且对实际操作流程熟悉的人员;中层经理也能够占用他们一些时间,主要是了解其报表需求。CXO或VP层通常只会在项目启动会上发表一番重视项目,设定一个要建成XXX范围最XX的XX系统的最高指示,未来可能偶尔出来听一下项目组进度报告、调配一下资源和矛盾。当然,基层和中层也会将他们过往领悟的高一层的需求说出来,但是否准确,是否是经过多层次翻译,是否是盲人摸象就不得而知了。基层最关心的是什么呢?使用最简便,最轻松,不要找麻烦让我加班,但一定要突出岗位的重要性,不能让我被取代。本案例中研究报告邮件的发送和确认非常复杂:邮件发送成功了吗?不成功是什么原因?是对方邮箱满了还是其他什么原因?不成功能否隔段时间再重发?重发要尝试几次?邮件客户打开看了吗?零零总总一系列的需求就是在服务好客户,提高满意度这个高层指示下,基层积极表现,同时体现本岗位重要性的需求。中层最关心的是什么呢?部门权利、部门价值、部门管理。本案例中有一个需求是研究员的工作时间管理。为什么要这个需求呢?因为对A公司的客户来说,最有价值的是分析报告的含金量,所以提升报告的含金量是老大的最高指示。可是提高含金量更多的是一种创造性的工作,没有什么好招来改善或者短期内见不到效果,而面对老大的要求能什么都不做吗?当然不可以,所以相关中层自然想到的解决方法是管理研究员的时间和工作内容,寄希望用时间的堆砌(更花功夫和心思)来提高报告的含金量,于是,经过了3层翻译的需求“研究员的工作时间管理”诞生了。我们知道真正的需求needs其实都是管理的目的,应该都是从公司战略分解下来的,而实际的需求调研对象集中在基层和中层,他们的需求并不天然就和公司战略吻合,甚至公司的战略都不是其最优先考虑的点。这一点需要CXO和VP级集体的介入和努力,从全局去考虑问题,优化调配,妥协权衡。所以,需求一定要和CXO和VP级沟通,和公司的战略紧密关联。

8:本案例中,随着需求调研的进行,CIO觉得需求越来越多,“成为了一个大拼盘”,跟销售、客户服务相关的东西都往里装。由于项目是一把手提出的,大家都要积极表现,从各种渠道了解的CRM概念、场景、需求都想实现,再加上7分析的中层和基层的心理活动,CIO如何从这些需求中筛选出最重要,价值最大的20%呢?3介绍了基于价值大小的准则,这里进一步将其限制到A公司这个特定的企业。A公司老大在见到了不菲的预算以及一年多的项目周期后,为什么仍然最后同意了CRM项目的立项呢?除了是其主动提出这个原因外,从厂商、方案供应商、管理咨询公司、MBA教育、各种管理杂志、其他CRM成功案例等等渠道了解的CRM系统价值影响了其判断,似乎自己企业也可以享受这些价值,却没有将这些潜在价值具体实例化到自己这个企业、特定流程、特定管理模式、特定当前状态,只有实例化后才可以去检验这些价值是否实实在在,是否可以得到。

9:项目进行过程中,需求不断增加是一个我们面临的一个普遍现象。甲方通常认为理所当然,因为合同已经签订,合同金额的上限已经确定,需求多更占便宜。可是他们没有站在乙方的立场上去想问题。任何一个有经验的乙方,合同签订的时刻,就已经确定了合理利润率下能够提供服务的最大人天数,所以他们在需求调研阶段的一个重要任务是“控制客户需求的发散性思维”,在能承受的范围内接受客户的需求,在不能承受的时候要求客户取舍,或放入二期。可是,取舍的标准是什么呢?是按照针对客户价值的大小来取舍,还是自己的难易程度、实现的人天数量来取舍呢?即使在能承受的范围内,是花更多的人天来把价值最大的20%实现更好,还是平均分配到所有的需求上呢?显然,CIO也要在这些方面干预,以获得最大的价值。

评论(9)

您可以在评论框内@您的好友一起参与讨论!

    1. 苏茂金 分析得很到位噢。其实每个企业都需要客户关系管理系统。确实如您所说客户关系管理系统管理的内容包括,客户360管理,销售管理(商机,销售,回款),销售人员管理(日程,活动),分析功能及其他通用功能(邮件、短信),如果能再结合现有的手机版本,我觉得就不错了。

      回复[0] 2013/09/05 11:42

    1. 宫金伟 今天把这篇文章又仔细看了,朱老师把主要问题描述得很透彻,学习了。

      最大的问题找出问题,切重要害,才能促进项目的立项。让领导觉得下决心上系统是值得的

      回复[0] 2013/05/31 15:32

    1. Johnjiang 精华啊 学习 受用

      回复[0] 2013/05/28 12:57

    1. 滔滔 好文章,学习了

      回复[1] 2013/05/13 09:41

    1. 袁艾青 好文章哦。
      感觉CIO参与沟通太重要了。
      通过与各个层面的沟通,把握住企业的战略规划,跟踪执行的过程,这样才能使信息化建设成果满足企业发展需要。

      回复[1] 2013/05/11 21:09

    1. bsmi-申宏杰 对需求needs的挖掘,以及满足需求的方法、步骤,本文说到家了!

      回复[0] 2013/05/08 21:07

    1. 徐小棵 CIO不好做啊!

      回复[0] 2013/05/06 16:56

    1. 徐蕊 精华,已经推倒微博了。

      回复[0] 2013/05/06 15:38

    1. 姜稳 学习了!一会再好好看一遍!

      回复[0] 2013/05/06 15:33

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");