警惕CRM系统软件范围渐变的应用陷阱

Rex

警惕CRM系统软件范围渐变的应用陷阱

Rex

严格控制需求 

　　由于防止范围渐变的第一道防线是避免虚假需求，所以要运用“敏捷”项目概念(即使你并不使用具体的敏捷方法)。用户也许不知道自已的真正需求有多重要。即便用户坚决要求的某项功能，也很少能量化该功能所具有的商业价值。所以致力于核心系统——如果明确需要“下一项功能”，必要的功能只会迅速增加，不断添加到核心系统上。 

　　当你用新CRM系统替换现有系统时，往往会遇到麻烦。用户的预期目标会被之前的系统所框定，如何来保证出现的范围渐变。这可能需要在会上据理力争，但你必须弄清楚以下几个问题： 

Rex

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

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

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

　　CRM系统的影响与客户方面的合作情况。要是缺少用户，你添加再多的功能也无济于事——也不会给业务带来更大的影响。此外，为系统增添更多的复杂功能实际上不利于易用性和用户采用。注重用户采用的这种观点也许能成为控制范围渐变的一个限制因素(gatingfactor)。

Rex

　　逼对方摊牌 

　　用户请求的有些功能实施起来很简单也很直接。其他“简单的要求”会涉及到成本高昂的数据改写和外部系统集成。如果对功能清单上某项“可有可无”的功能产生怀疑，就要用预算逼请求方摊牌。好好估算一下开发这部分功能需要多少成本，告诉请求方：一旦有关方提供预算，就会开始开发这部分功能。只有搞清楚具体的费用数字或在部门之间调拨预算，才会开始开发。 

　　每隔六个月就重新确定CRM需求的优先级 

　　在某些行业，销售或营销副总裁的任职期只有短短18个月。CRM项目开始阶段确定的优先级可能因企业内部政策或业务规则出现变化而不适用。此外，竞争对手、合作伙伴和客户不断变化，可能意味着CRM和相关系统方面的重点会出现变化。参加这类优先级讨论会时，要根据实际成本和商业价值来比较功能。避免不再必要的需求是控制范围渐变的最有效方法之一。