ITPub博客

首页 > Linux操作系统 > Linux操作系统 > CRM的低成本策略

CRM的低成本策略

原创 Linux操作系统 作者:无聊岁月 时间:2009-06-10 11:53:10 0 删除 编辑

CIO经常面临这样的处境: 领导层已经承认公司业务需要一个新的CRM系统,但CFO一想到高昂的成本就紧张不安,并与CIO商谈希望能尽量节减开支。这时的CIO就要采用一切有望降低成本的策略,不然CRM项目就注定要失败。

节省成本的关键在于: 密切关注业务目标。
第一个策略: 确定项目需求的优先级。

 

大多数公司都存在部门冲突的现象,确定项目需求的优先级就成为了一件不大可能完成的事情。但CIO要认清现实,即便没有人愿意确定项目优先级,也要制定一项客观面对现实的计划。在这方面,CFO的成本分析工具或许是CIO的好帮手。

第一步就是把所有项目需求都列到一张电子表格上。一定要关注成本的所有组成部分,包括: 直接人力、间接人力、采购、实施、管理费用,甚至还有团队士气等,所有主要需求都要按可比口径进行评估。www.SFDC-secrets.com上有一大批涉及该方面的免费电子表格(如果提示要求你在下载前输入密码,请输入“CIO”。)

第二步,评估某项需求有着怎样的业务价值。让一群公司主管就这个问题达成一致,并确定优先级。这是一项很有意义的工作,有许多投票表决和达成共识的工具可供使用。虽然没有哪个方法是十全十美的,但总会找到一个方法让大家达成共识。

第三步,就是审查项目需求的“约束条件”,根据“约束条件”确定优先级,“约束条件”越少意味着越容易实现。在“业务价值”的基础上,约束条件最少的需求应当优先予以满足(因为它们最容易实现)。如果某些需求所需的特定资源目前无法获得,它们将被列在需求列表上靠后的位置(可以直接不予考虑)。有时,单单凭借“约束条件”就能神奇地缩短确定项目优先级的会议。
第二个策略: 质疑需求。

 

项目需求很容易明确,但一些不是很重要的需求容易被过度描述。著名的市场研究机构Standish Group在《混乱报告》(《Chaos Reports》)中表明,需求表述有误是导致大型IT项目失败的最常见原因。那么,如何检验项目需求的表述是否正确呢?方法很简单,就是回答一个问题——这样表述果真会改变业务部门的决定或业务结果吗?要是没有实际例子,就应当认真分析需求,并且换一种会改变业务结果的方式重新表述。要把精力集中在表明业务运行状况的直接指标上,在长期比较时更是如此。

表述夸大的需求令人烦恼,但无形的需求才是项目预算的隐形杀手,如果很晚才发现这种需求,危害更大。有些关键需求在CRM系统中不会得到充分如实的表述,甚至被想当然地认为是一种“已知情况”。
第三个策略: 确保从小处入手,易于取得具体成果。

 

有一种CRM部署方式叫“大爆炸式”,也就是“一蹴而就”式的部署,这对CRM系统来说是相当糟糕的。用户使用才是真正衡量CRM系统好不好的标准。

就SaaS模式下的CRM而言,实行敏捷项目是从Salesforce.com获得最大价值的方法。因为敏捷项目极易配置、极易集成,所以你很快就能把某项功能交到需要它的业务团队手里。这种“迅速成功”会让你在企业内部获得信赖,而且便于添加更多的用户和特性。

敏捷项目的适应性较强,能够灵活适应业务变化,以跟踪迅速变化的业务需求、项目优先级和企业内部冲突。敏捷项目的逐步交付方式需要项目经理及全面了解情况的管理人员投入更多的工作,当然,这会显著改善CRM系统的投资回报率。

如果确实不很重要(或优先级下降)的需求自动往后顺延,敏捷项目的优点就会体现出来,这有助于减少资源浪费。
第四个策略: 运用价值工程。


 

这个经典概念应当运用于CRM。价值工程致力于找到一种成本最低的方法来实现经营目标,而不是在实施费用方面“如何削减几个百分点”。价值工程应当运用于如下四个层面。

1. 关注实现经营目标的其他方法,而不是局限在CRM系统内进行工作。

2. 确认及评估异常情况,从而确保它们能够在CRM系统内得到处理。

3. 不要过分设计或过分运用准确度最高的解决方案。追求完美并不值得,要舍得在易用性、准确性和数据“陈旧度”方面做出一点牺牲。

4. 自建、购买还是租用,需要灵活对待,综合考虑成本、技术、人员和技能等多种要素。比方说,如果你“租用”技术或技能,就要确保自己有能力在以后进行维护和小幅改动。
第五个策略: 改变规则。

 

这是成本控制方面最有效的策略,因为它影响了CRM系统的实施、用户和业务流程。

应当审视政策、业务规则和业务流程; 你在不断实施CRM项目时,需要对它们重新设计。弄清楚规模与你相当的竞争对手在做什么; 如果条件允许,应当尽量采用对方的最佳实践(运用了80%的最佳实践后,通常会出现收益递减)。重新规划业务规则和业务流程时,需要精简——找到可以合并或部分自动化的步骤,消除纸张和数据重新输入,并且设法让客户与你的系统进行直接互动。

这项策略可能会给业务带来最大的影响,当然也会带来关系复杂的部门冲突,所以不要做得过头。
链 接

CRM的五个陷阱

 

1. 追求完美,希望构建一个长期有用的CRM系统。

CRM系统的业务需求经常发生变化,以至于系统的设计期限不到5年。如此短的设计期限意味着需要迅速从系统中获得业务效益,大多数情况下,应在18个月内获得投资回报,预测5年后才获得回报是不靠谱的。

在某些行业,销售副总裁或首席运营官的任期只有18个月,连CEO也可能没过几年就换了。每次换新的领导班子,市场战略、销售策略和产品重点都会随之变化。就算一段时间后继续使用同一个CRM平台,5年后完全有理由从头开始重新部署系统。因此追求完美是不值得的。

2. 目标过多。

CIO很容易掉入“说人家喜欢听的话”这个陷阱,每个业务部门都听到了想听到的话,于是对CRM系统寄予厚望。即便CIO能兑现每一个期望目标,项目的总成本当中必然也会有很多浪费。这里的问题在于形形色色的目标导致项目不明确、很难执行,项目成本高昂的原因在于业务流程或业务推动者方面的定义不够明确。

最好是对系统设定数量非常少的目标,每个目标都要有明确的项目负责人、衡量成功的指标及最后期限。应当为每个目标确定优先级,要有先后之分。

3. 错误的衡量标准。

不该从部署了多少系统功能来评判项目进度,系统功能本身是没有业务价值的空壳子。而应评估系统所含的数据资产具有的价值,首先要看用户的使用率,其次看每个月通过系统的订单所具有的价值。另外,要确保衡量标准的内容明确、连贯一致、各方都达成共识。

4. 一口气一次性交付。

项目越庞大,延迟或超支的可能性就越大。对软件而言,一下子推出整个系统(我们称为“大爆炸式项目”)不是很有效,其中的隐患很多,譬如: 项目里程碑很少、项目交付成果庞大而复杂、很少考虑部门冲突或变更管理问题、系统集成或历史数据范围方面的需求较多。

最好是逐步交付成果,至少每个季度部署一次对业务有价值的项目部分。这样能得到基层员工和管理层的支持,而且下次增加系统扩展预算时,就能赢得信任票。

5. 只关注成本,不关注业务影响。

分析成本时应关注总体拥有成本,成本分析应着眼于3~5年的时间范围——太长了不现实,太短了很愚蠢。

分析成本应当只是为了确保预算的合理分配,而不是改变系统范围的决策。合理部署的CRM系统带来的业务效益应完全超过成本。CRM系统的目的应该是提高盈利能力,降低客户获取成本,提高客户终生价值以及减少销售、支持和服务方面的浪费。
  
 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13129063/viewspace-605792/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-06-05

  • 博文量
    677
  • 访问量
    674430