大而全的CRM项目为什么容易失败

到今天，我们仍然可以看到这样的CRM需求：一份长达数十页的功能需求文档和铺满了整个屏幕的脑图。虽然整个需求看上去很系统，但细究下来，模块间少了耦合，数据缺乏关联，与其说这是一个系统，其实更像是强行组装的CEO（CRM、ERP、OA）。大多数情况来说，也正是因为这样的CRM项目，抬高了整体CRM的实施失败率。为了证明这一论据并非出自武断，我们将在下面给出观点，阐述这种大而全的CRM项目为什么很容易失败。

一、被打散了的擎天柱

数百个彼此不相关的功能、单纯只为收集数据而非提炼数据价值的模块、业务流程看似复杂但实则鸡肋，这种CRM的实施失败率通常在80%以上（只是保守估计）。更不用说，这样的CRM项目还可能存在以下陷阱：
1、甲方要求整体上线，一次实施完毕，项目复杂却不分期——让国人自豪的歼10都有可供迭代的初代型号。
2、需求多，预算少——这种反智的商业现像仍然存在。
3、甲方预算充足，但乙方的实力和资源配置是否能啃得下来（业务理解和开发难度大）——很香的山芋，但很烫手。

大黄蜂带着被打散了的擎天柱的零件来到焊接工的面前。
焊接工看着这些零件，问：“这安起来是个啥？”
大黄蜂：“你若安好，便是擎天。”

二、开发和实施难度大

“大而全”意味着甲方和乙方的工作负担“多而杂”，这其间，涉及到每个功能和模块的需求调研，开发人员需要时时和项目经理保持紧密的沟通，以使重要业务流程不致于“回炉改造”。但由于任务多，业务涉及面广，上线时间紧，很难保证开发工作和业务沟通工作的准确性，这很大程度上会产生以下不良后果：
1、乙方开发团队的实力或项目资源配置不足以实现销售人员或项目经理的承诺。
2、甲方的需求可能发生变更（对于大项目而言，这简直是一定的），这很容易增加开发成本，甚至造成工作停滞。
3、因为沟通问题导致业务理解和实现出现偏差，大面积存在很多需要重改的模块。
4、由于功能多，涉及到的业务层面更加复杂，实施起来双方都会浪费很多精力。

乙方：“一顿操作猛如虎！”
甲方：“实施结果……不说了，心里堵！”

三、橙汁还是橙子

经历了层层风险，我们终于走到这一步——项目顺利交付。接下来，就是使用的问题，即用户采用率，用户愿意使用就会产生数据（且不论过于复杂的系统是否会影响这点）。我们得承认，这种功能繁多的系统确实擅长存储数据（虽然是采用更严格和降低效率的方式来收集数据），但是它不一定能告诉我们数据的含义——信息价值。由于数据缺乏关联，报表只是浅层次的表格统计或是柱状图，除了简单的汇总，它难以带给决策者有效的信息和洞察力。是的，虽然我们不断的谈论数据，但产生了数据，就一定会有数据价值吗？

当我们渴望的是橙汁的时候，我们却在谈论橙子。

建议

作为十余年的CRM从业者，我们知道上面的话少了些粉饰，并不好听。说这些话，并非因为我们是局外人，恰恰相反，我们实施过一些百万级别的CRM项目。但由于我们的甲方更加英明，愿意主动或采纳我们的建议将复杂的系统进行拆分，所以在这类项目上，我们的总体实施成功率还算不错。但是，现在，商业模式和CRM这个行业已经发生了变化，公司越来越以客户为中心来思考战略问题，并更加强调短平快，而CRM也已经回到客户和销售管理的本源，正在用更直观的表现方式融入企业的业务。所以，我们建议您在选型或实施CRM时，遵循以下流程：