2

我的组织刚刚开始涉足 Dynamics CRM,出现的问题之一是我们什么时候应该将各种应用程序组合到一个实例中,什么时候应该将它们分成多个实例?

我知道这个问题的答案取决于具体情况,所以我试图提出一个可以被问到的问题列表,以帮助确定哪个方向最有意义。

我很难在网上找到任何关于这个的讨论,所以我想在这里问。那么,在决定一个系统/一组功能是否应该在一个单独的实例中时,您会问什么问题?

编辑:我不太清楚我们的组织类型。我在一个有多个部门的城市工作,这些部门提供不同的服务并为不同的客户提供所需的功能通常非常不同。

我担心将所有这些具有不同功能并跟踪不同“客户”的不同系统放入一个系统中的冲动。我担心管理适用于不同系统的所有各种实体并确保来自一组用户的更改请求不会给另一组用户造成问题会出现问题。

我敢肯定,有时将多个系统组合到一个实例中是有意义的,但我认为可能有很多次我们不想将它们放在一起,所以我想提出一个问题列表问。

一些基本的问题是: 1) 系统是否共享公共数据(例如,相同的客户)?2) 系统是否共享通用功能?3) 系统是否收集相同类型的数据?4) 是否有要求报告来自这些系统的组合数据?5) 通过分离实例或通过用户角色来管理安全性会更容易吗?

4

1 回答 1

2

根据我的经验,一个例子是常态。在我看来,单个实例的好处非常显着。

您可能需要考虑以下几点:

  • 您想要孤岛中的数据吗?如果是这样,多实例提供了一种非常简单的方法来实现这一点。然而,具有适当安全建模的单个实例也可以实现这一点。
  • 您想将跨应用程序的数据合并到一个业务流程中吗?如果是这样,多实例意味着您必须在实例之间构建集成。单实例没有这个问题。
  • 您想在每个实例中使用自定义构建的功能吗?如果是这样,单个实例会立即提供此功能。多实例需要对每个实例进行单独的开发和部署,这可能会增加成本。
  • 你考虑过授权吗?我不是许可专家,但我相信如果你是在线多实例会吸引更高的许可成本。

根据经验,我会说单个实例是默认位置,因为它允许您轻松组合数据和流程。如果您想使用多实例,只需有一个充分的理由,并确保它不是单个实例可以提供的。

于 2016-05-13T07:48:45.713 回答