业务部门的设计注意事项
发布日期： 一月 1, 2008
具有已安装Microsoft Dynamics CRM 之后，下一步是创建组织结构。此任务包括定义业务部门、安全角色以及输入和配置用户帐户。业务部门包含用于创建两阶段安全模型的安全角色，此安全模型控制授予用户的特权以及他们要在自己所属业务部门和相关业务部门内使用这些特权而应拥有的访问权限。
业务部门的概念可以比作公司的组织结构图。但是，在 Microsoft Dynamics CRM 中创建组织结构并不是转换现有组织结构图的过程。这是一个设计过程，其中组织的需要决定结构。业务部门一经创建，便无法重命名或删除。
当前页内容
|
使用业务部门 |
|
|
设计因素 |
使用业务部门
当您创建组织结构时，可以通过业务部门控制对于用户所拥有实体中的数据的访问权限。Microsoft Dynamics CRM 中的大多数记录都分配了一个用户作为所有者。此用户与业务部门关联。您将使用安全角色为业务部门内的用户定义特权和访问权限。如果您将某个用户移到其他业务部门，则该用户所拥有的所有记录都将离开原业务部门而进入新的业务部门。
某些实体为业务部门所拥有。团队、队列、日历、设备、资源和资源组就是这样的例子。如果您的组织中有多个组独占这些实体，则应考虑创建一个业务部门来代表这些组的成员。
设计因素
当您设计组织结构时，必须考虑以下几个因素：
-
组织的规模
-
组织提供服务的客户群
-
保持安全性的复杂程度
-
存储在 Microsoft Dynamics CRM 中的信息的机密性
组织规模
规模自身并不构成一个关键因素。但组织规模通常意味着您的组织结构设计需要更多的业务部门和更深的层次结构。Microsoft Dynamics CRM 的设计可以满足这些复杂的需要；如果您的组织比较大，您可能需要使用较多的业务部门和较深的层次结构级别。
如果您的组织比较小，或者其他设计因素并没有指出上述这些要求，则保持简单的组织结构。如果根业务部门已足够，则无须创建任何其他业务部门。
然而，始终不要忘记，组织的规模可能会发生变化。尽管初始实施比较简单，但应考虑到规模扩大的情况。
提示
Microsoft Dynamics ISV 架构顾问 John O’Donnell 建议创建一个新的业务部门作为根业务部门的下属部门。然后，将这个第二级业务部门用作其设计的起点。这样，您就可以扩展业务部门结构，使之包含平行的业务部门或将来并购其他公司。
客户群
Microsoft Dynamics CRM 的核心概念之一是帮助用户更好地服务于各自的客户。这要求能够更好地了解客户数据，并能够加强与同一客户群打交道的 Microsoft Dynamics CRM 用户之间的相互协作。除非您的组织有特殊限制，否则应避免制造障碍来限制用户查看数据或满足客户需求。同时，不要对用户无访问需要的数据提供访问权限。
大型组织会分设服务组，它们需要特定的资源，如队列、日历和设备。组织中的销售部门则专门针对地理区域或细分市场。您的组织结构应允许用户查看数据并根据工作需要采取行动。尽管大型组织中的用户通常更为专业化，但应考虑如何控制人们可以执行的操作。为了为客户提供服务，有时用户可能必须超出自己通常充当的角色。
小型组织中的雇员通常服务于单一用户群，并且常常充当更广泛的角色。因此，您可能无须创建更多的业务部门。
复杂性
Microsoft Dynamics CRM 组织结构应尽可能保持简单以便于管理。复杂性级别应反映组织的安全性需要。最大程度地降低复杂性所带来的影响，可以有效地实施安全措施并完成必需的更改，同时将用户受到的影响降至最低。
做好相应的准备，以便在向 Microsoft Dynamics CRM 中输入数据之后，评估最初的组织结构。当 Microsoft Dynamics CRM 开始运行并且雇员开始使用、输入和访问数据时，您必须解决意料之外的安全性问题。
敏感信息
实施客户关系管理 (CRM) 时，要权衡向用户提供所需信息的需要以及错误使用信息的风险。
例如，对于某个客户服务代表 (CSR) 而言，了解某位不满意的客户目前是否具有开启的大额销售商机可能非常重要。之后，CSR 可能会优先解决该客户的问题，并希望在此商机上附上一份注释，以便与销售团队共同协作。这说明，CSR 无须查看客户的报价单。
确保仅向需要的用户授予对敏感信息的访问权限。有了业务部门安全角色，您便可以指定实体访问权限。敏感信息可以存储在单独的实体内，这样，您就可以通过分配的安全角色控制业务部门的访问权限。
敏感信息应在计划阶段早期确定。安装工作开始后，泄漏信息会对实施造成严重影响。
