2013年客户关系管理需求收集和扩展，最佳做法

Question

我对CRM 2013相当陌生，我一直在阅读和观看很多关于这一主题的视频。我希望网上有人，能提供一些提示或建议，将与我解释和理解这些材料的方式产生共鸣。

我有一个常规的MS Access DB，它有几个不同的表，用于存储人事记录。从我到目前为止所了解到的情况来看，CRM似乎是一个很好的选择，可以从Access转向CRM。

我的问题是，在收集和扩展CRM 2013环境中的需求时，有哪些最佳实践？

即(为了简单起见)

有两个表。

• 表A存储员工姓名。
• 表B存储员工最喜欢的食物。
• 每个表应该有自己的实体(Table_A 1:N，Table_B N:1)，还是应该在单个实体下组合多个表？
• 把所有东西都放在一个实体下被认为是不好的形式吗？

- If it is bad form, how do you determine when to split the information into multiple entities?

​

• 业务流程似乎让我想起了SharePoint工作流。你什么时候应该依赖BP？

我希望这是有意义的，我还在努力弄清楚这一切。任何帮助都是感激的，谢谢！

Answer 1

Dynamics是由SQL Server支持的，所以考虑一下SQL表，还有什么更好。在大多数情况下，拆分为具有单一责任的较小对象更好，但这可能会影响连接记录的性能。老实说，我们正在从云中的CRM中移开，因为它是不可扩展的，不可靠的(如果它下降了，您需要等待它上升时--没有第二个副本)，没有对底层SQL数据或Server实例大小(DTU)的控制，很难测试，而且对一个大项目来说是痛苦的。我们将用代码替换所有业务流程，因为它们也是不可测试的--您不能编写单元测试。

Answer 2

虽然@sergeSemenov有一些优点，但您必须开始使用CRM。CRM是一个客户关系管理套件，建立在Xrm之上，一个RADP，快速应用程序开发平台。

Xrm不是为了成为世界上最灵活、最具表现力的平台而设计的。如果使用速度和使用任何特定技术/服务器拓扑以满足您的需求的能力是应用程序的要求，那么不要从XRM开始。

如果开发速度、市场速度、通过让非开发人员做开发人员所要求的定制应用程序开发环境中的工作，或者甚至希望在第一天进入云端而降低成本，那么Xrm就更有价值了，因此CRM是一个很好的起点。

至于你的问题，这一切都取决于。数据的规范化程度越高，每个关系的多个实体就越少，确保它们都是同步的工作就越少，但通常情况下，最终用户处理信息越困难。它们必须导航到多个表单以进行数据输入，并在报表中配置大量联接。

我通常试图尽可能地保持数据的规范化，但是如果任何事情都是1:1的关系，那么将其合并到单个实体中。或者你知道这将是一种1:2或1:3的关系(例如，见联系人和帐户上的地址)

基本上，这是一个需要对应用程序需求和个人体验进行独特研究的答案。我强烈建议找一位有CRM经验的顾问。平台的另一个优点是，有一个完整的开发人员资源库，并且基础已经了解该框架，并且可以在第一天为业务提供价值，而不是花上2到3周的时间来了解您的特定架构。

祝好运!