CRM（Customer Relationship Management）就是客户关系管理。从字面上来看，是指企业用CRM来管理与客户之间的关系。CRM是选择和管理有价值客户及其关系的一种商业策略，CRM要求以客户为中心的商业哲学和企业文化来支持有效的市场营销、销售与服务流程。如果企业拥有正确的领导、策略和企业文化，CRM应用将为企业实现有效的客户关系管理。
CIO 经常面临这样的处境: 领导层已经承认公司业务需要一个新的 CRM系统 ，但CFO一想到高昂的成本就紧张不安，并与CIO商谈希望能尽量节减开支。这时的CIO就要采用一切有望降低成本的策略，不然CRM项目就注定要失败。 节省成本的关键在于: 密切关注业务目标。
CIO经常面临这样的处境: 领导层已经承认公司业务需要一个新的CRM系统，但CFO一想到高昂的成本就紧张不安，并与CIO商谈希望能尽量节减开支。这时的CIO就要采用一切有望降低成本的策略，不然CRM项目就注定要失败。
节省成本的关键在于: 密切关注业务目标。
第一个策略: 确定项目需求的优先级。
大多数公司都存在部门冲突的现象，确定项目需求的优先级就成为了一件不大可能完成的事情。但CIO要认清现实，即便没有人愿意确定项目优先级，也要制定一项客观面对现实的计划。在这方面，CFO的成本分析工具或许是CIO的好帮手。
第一步就是把所有项目需求都列到一张电子表格上。一定要关注成本的所有组成部分，包括: 直接人力、间接人力、采购、实施、管理费用，甚至还有团队士气等，所有主要需求都要按可比口径进行评估。上有一大批涉及该方面的免费电子表格(如果提示要求你在下载前输入密码，请输入“CIO”。)
第二步，评估某项需求有着怎样的业务价值。让一群公司主管就这个问题达成一致，并确定优先级。这是一项很有意义的工作，有许多投票表决和达成共识的工具可供使用。虽然没有哪个方法是十全十美的，但总会找到一个方法让大家达成共识。
第三步，就是审查项目需求的“约束条件”，根据“约束条件”确定优先级，“约束条件”越少意味着越容易实现。在“业务价值”的基础上，约束条件最少的需求应当优先予以满足(因为它们最容易实现)。如果某些需求所需的特定资源目前无法获得，它们将被列在需求列表上靠后的位置(可以直接不予考虑)。有时，单单凭借“约束条件”就能神奇地缩短确定项目优先级的会议。
第二个策略: 质疑需求。
项目需求很容易明确，但一些不是很重要的需求容易被过度描述。著名的市场研究机构Standish Group在《混乱报告》(《Chaos Reports》)中表明，需求表述有误是导致大型IT项目失败的最常见原因。那么，如何检验项目需求的表述是否正确呢?方法很简单，就是回答一个问题 ——这样表述果真会改变业务部门的决定或业务结果吗?要是没有实际例子，就应当认真分析需求，并且换一种会改变业务结果的方式重新表述。要把精力集中在表明业务运行状况的直接指标上，在长期比较时更是如此。
表述夸大的需求令人烦恼，但无形的需求才是项目预算的隐形杀手，如果很晚才发现这种需求，危害更大。有些关键需求在CRM系统中不会得到充分如实的表述，甚至被想当然地认为是一种“已知情况”。
第三个策略: 运用价值工程。
这个经典概念应当运用于CRM。价值工程致力于找到一种成本最低的方法来实现经营目标，而不是在实施费用方面“如何削减几个百分点”。价值工程应当运用于如下四个层面。
1. 关注实现经营目标的其他方法，而不是局限在CRM系统内进行工作。
2. 确认及评估异常情况，从而确保它们能够在CRM系统内得到处理。
3. 不要过分设计或过分运用准确度最高的解决方案。追求完美并不值得，要舍得在易用性、准确性和数据“陈旧度”方面做出一点牺牲。
4. 自建、购买还是租用，需要灵活对待，综合考虑成本、技术、人员和技能等多种要素。比方说，如果你“租用”技术或技能，就要确保自己有能力在以后进行维护和小幅改动。
第四个策略: 确保从小处入手，易于取得具体成果。
有一种CRM部署方式叫“大爆炸式”，也就是“一蹴而就”式的部署，这对CRM系统来说是相当糟糕的。用户使用才是真正衡量CRM系统好不好的标准。
就SaaS模式下的CRM而言，实行敏捷项目是从Salesforce.com获得最大价值的方法。因为敏捷项目极易配置、极易集成，所以你很快就能把某项功能交到需要它的业务团队手里。这种“迅速成功”会让你在企业内部获得信赖，而且便于添加更多的用户和特性。
敏捷项目的适应性较强，能够灵活适应业务变化，以跟踪迅速变化的业务需求、项目优先级和企业内部冲突。敏捷项目的逐步交付方式需要项目经理及全面了解情况的管理人员投入更多的工作，当然，这会显著改善CRM系统的投资回报率。
如果确实不很重要(或优先级下降)的需求自动往后顺延，敏捷项目的优点就会体现出来，这有助于减少资源浪费。
