如何评估CRM平台应用

zhaomeiling

在CRM应用中，轻松改动、扩展和集成应用程序的功能比任何其他特性都要来得更重要。因为真正最佳的CRM系统是构建起来的，而不是购买过来的，平台优势比特性列表来得更重要。所以只要让平台变得更好，就可以让CRM变得更可靠、耐用。话虽如此，如果你有一个完美无瑕的平台，但用户极度讨厌这一界面，那么CRM系统还是会夭折。
在评估平台时，对于CRM应用，平台的哪些方面才是真正重要的呢？
• 应用编程接口（API）、语言和库的流行程度
一个拥有上百万开发人员的平台比另一个只有一小群忠实开发人员的平台重要得多。谁还记得ABAP编程语言？要是你无法围绕Ruby on Rails建立一支高效的开发团队，那么这个平台再漂亮都无关紧要。正是由于以一种注重实际的态度关注开发人员群体，而不是底层技术，VB.net、Java、PHP、PERL和Python等平台才备受青睐。
• 附件、工具和开发辅助手段的数量和用途
众多库有没有得到一大群用户（可能是开源用户）的审查，这确实很重要。它们会以适当的方式处理UTF-32字符吗？能够适当处理这种字符的库往往不是太多。你还要关注集成开发环境（IDE）的插件和扩展件（Eclipse或NetBeans）、测试用具（Test harness）以及构建环境。
• 该平台是一种考虑缜密、表现稳定的集成方式？还是一堆唬人的营销大话？
多年来，我常劝诫开发人员：别信以为真。使用云平台有两大理由：一是便于开发，二是便于与其他广泛应用程序集成。应当关注API的一致性和适用范围。你能获得CRM系统里面的所有重要对象吗？API是散布于17个动态链接库吗？还是它们是一组逻辑的Web服务？可以使用任何子系统的所有API吗？还是说平台被分隔开来？应用程序能从平台外面开始执行CRM事务或工作流吗？外部系统能够完全参与到CRM应用的触发器和工作流吗？
• 实际环境的可扩展性
每个月出现的停运时间有几个小时？在忙碌时段响应时间怎么样？平台拥有资源调控限制吗？还是仅仅为了方便CRM供应商，强行使用死板的代码结构？或者有没有简单直观的方法可以一下子处理1万个或10万个记录？你会惊讶地发现，CRM的API里面在可扩展性方面存在太多的局限性。
•为所有API操作而实施的一种细粒度的安全模型
需要考虑安全模型的三个级别：底层数据库的C/R/U/D权限；应用程序级别的角色、对象和操作；以及Web服务的方法。
正如以上显示的那样，魔鬼在于细节中。这是因为，比如有可能获得基于一种非常流行的语言的API，但CRM供应商可以增添专有扩展件，结果拥有再庞大的开发社区也没多大意义；或者有可能拥有完美无瑕的API，但只能适用于存储在CRM应用的数据库里面的那些数据。
因此，要真正知道你的CRM平台对你来说是否足够可靠、灵活，一个可行的方法就是以某个实际应用为对象，开展试点项目。当然，这么做可能需要高昂成本，但与选错平台造成的更大代价相比还是划算的。