  　　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%的最佳实践后，通常会出现收益递减)。重新规划业务规则和业务流程时，需要精简找到可以合并或部分自动化的步骤，消除纸张和数据重新输入，而且要想办法让客户与你的系统来进行直接互动。
  　　有关这项策略可能会给业务带来最大的影响，同时也会带来关系复杂的部门冲突，所以千万不要做得过头。
  　　1. 追求完美，希望构建一个长期有用的CRM系统。
  　　CRM系统的业务需求往往会经常发生变化，导致系统的设计期限不足5年。这样短暂的设计期限就意味着需要迅速从系统中获得业务效益，在决大部分情况下，应在18个月之内获得投资回报，估计在5年后才获得回报是不靠谱的。
  　　对于某些行业来说，销售副总裁或首席运营官的任期只有18个月，连CEO也可能不到几年就换了。而每次换新的领导班子，市场战略、销售策略和产品重点都会因此而发生变化。就算在一段时间后继续使用同一个CRM平台，那么，在5年后完全有理由从头开始重新部署系统。因此追求完美是不根本没必要的。
  　　2. 目标过多。
  　　CIO是非常容易掉入“说人家喜欢听的话”这个陷阱，每个业务部门都听到了想听到的话，于是对CRM系统就会寄予厚望。即使CIO能每一个期望目标予以实现，项目的总成本当中也必将造成很大的浪费。这里的问题在于各种各样的目标而导致项目不明确、难于执行，项目成本昂贵的原因主要是在于业务流程或业务推动者方面的定义不够明确。
  　　最好是对系统设定数量较少的目标，每个目标都要有明确的项目负责人、衡量成功的指标和最后期限。还应该为每个目标确定优先级，要有先后之分。
  　　3. 错误的衡量标准。
  　　是不应该从部署了多少系统功能来评判项目进度，系统功能的本身是没有业务价值的空壳子。而应评估系统所含的数据资产具有的价值，首先就要看用户的使用率是多少，其次是看每个月通过系统的订单所具有的价值。还有，要确保衡量标准的内容明确、连贯一致、各方都达成共识。
  　　4. 一口气一次性交付。
  　　具体项目越庞大，造成延迟或超支的可能性就越大。而对软件来说，一下子推出整个系统(我们称为“大爆炸式项目”)效果不是很大，其中的隐患很多，比如: 项目里程碑少之又少、项目的交付成果庞大而复杂、很少会考虑到部门冲突或变更管理的问题、系统集成或历史数据范围方面的需求较多。
  　　最好就是逐步交付成果，至少每个季度要部署一次对业务有价值的项目部分。这样不但能得到基层员工和管理层的支持，而且下次增加系统扩展预算时，就可以赢。取不少的信任票。
  　　5. 只关注成本，不关注业务影响。
  　　对成本进行分析时应关注总体拥有成本，成本分析应控制在3～5年的时间范围内，如果是太长了就不现实，太短就会变得很愚蠢。
  　　关于分析成本应当只是为了能确保预算的合理分配，而不是改变系统范围的决策。合理部署的CRM系统带来的业务效益会完全超过成本。CRM系统的目的应该是提高盈利能力，降低客户获取成本，从而提高客户终生价值以及减低销售、支持和服务方面造成的浪费。


  上一篇：被沦为业务处理软件的CRM将怎么办
  下一篇：如何让CRM外包你的流程留住你的客户