时间:2009-9-4
CRM系统与其他大多数企业应用系统不一样。尽管有些需求是没有商量余地，但以逐步的方式来重新定义需求及部署功能还是大有余地。这意味着，CRM系统可使用“按杯数计费”的投资模式(by-the-drinkmodel)，而不是像传统企业软件特有的“赌上全部家当”的投资模式(bet-the-farmmodel)。
基于SaaS模式的CRM系统所具有的灵活性更大，因为它没有任何硬件或严重的操作问题要处理——只须打个电话，就可以增加容量和增加模块。Web服务应用编程接口(API)稳定可靠的CRM系统(比如Salesforce.com的CRM系统)在开发和部署周期方面的灵活性更大。
本文介绍了克服范围的几个办法，从几门学科领域借鉴而来。
为业务部门不断带来细小价值
逐步进行工作开展不是错误，而是现代CRM系统的一大特点。由于Web服务具有松散耦合性，所以完全有理由确保交付的功能细小、简单、可分离。有时候，迫切需要的功能只需要几个工时就能开发及测试完成，那样每个季度就可以部署两次，甚至更频繁。
在这基础上更进一步：最好只部署一部分功能，把部分功能留到以后去开发可以简化学习难度，让企业适应比较小、这样可以频繁的交付成果，并且可以为IT部门提供了下一个部署周期所需的“现金储备”(消除范围渐变的终极武器就是拿出交付成果!)
严格控制需求
由于防止范围渐变的第一道防线是避免虚假需求，所以要运用“敏捷”项目概念(即使你并不使用具体的敏捷方法)。用户也许不知道自已的真正需求有多重要。即便用户坚决要求的某项功能，也很少能量化该功能所具有的商业价值。所以致力于核心系统——如果明确需要“下一项功能”，必要的功能只会迅速增加，不断添加到核心系统上。
当你用新CRM系统替换现有系统时，往往会遇到麻烦。用户的预期目标会被之前的系统所框定，如何来保证出现的范围渐变。这可能需要在会上据理力争，但你必须弄清楚以下几个问题：

你果真想要新系统就具有旧系统的数据质量和功能吗?

用户和客户已熟悉旧系统的使用习惯，因此切换需要尽量平稳。而从一个系统“直接切换”到另一个系统可能会带来迁移问题，分阶段、分步骤的切换则比较稳妥。

系统中的数据(交易事务和不断变化的客户关系)绝对不能面临风险。新系统中的核心数据和功能必须稳定下来，之后才可以成为更高级系统功能的基础。有一段时期出现“并行运行”(冗余系统操作)或者功能减少是不可避免的，应当考虑到计划当中。

CRM系统的影响与客户方面的合作情况。要是缺少用户，你添加再多的功能也无济于事，也不会给业务带来更大的影响。此外，为系统增添更多的复杂功能实际上不利于易用性和用户采用。注重用户采用的这种观点也许能成为控制范围渐变的一个限制因素(gatingfactor)。
逼对方摊牌
用户请求的有些功能实施起来很简单也很直接。其他“简单的要求”会涉及到成本高昂的数据改写和外部系统集成。如果对功能清单上某项“可有可无”的功能产生怀疑，就要用预算逼请求方摊牌。好好估算一下开发这部分功能需要多少成本，告诉请求方：一旦有关方提供预算，就会开始开发这部分功能。只有搞清楚具体的费用数字或在部门之间调拨预算，才会开始开发。
每隔六个月就重新确定CRM需求的优先级
在某些行业，销售或营销副总裁的任职期只有短短18个月。CRM项目开始阶段确定的优先级可能因企业内部政策或业务规则出现变化而不适用。此外，竞争对手、合作伙伴和客户不断变化，可能意味着CRM和相关系统方面的重点会出现变化。参加这类优先级讨论会时，要根据实际成本和商业价值来比较功能。避免不再必要的需求是控制范围渐变的最有效方法之一。

文章来源       www.51Callcenter.com
销能咨询 培训部编辑