劳动力管理和部门概述
本文介绍了劳动力管理。
部门和劳动力管理的关键概念
本节介绍各部门在劳动力管理中的工作方式、实体及其在业务部门级别或管理单位级别中的所属位置,以及部门内的用户访问权限。
了解部门的工作原理
- 使用劳动力管理部门划分访问控制。 例如,将部门视为用于限制哪些业务单位和管理单位出现在劳动力管理页面右上角的列表中的控件。
- 在劳动力管理中,用户所属的部门仅在管理单元之间移动用户的情况下才起作用。 用户与管理单元关联后,了解管理单元或业务部门所属的部门非常重要。
- 所有主管权限都与部门关联,但不是所有座席权限。 代理可以查看属于他们的页面或实体,无论分区如何。
- 业务部门只能属于一个部门。 默认情况下,此分区为 Home。 管理单位只能属于一个部门。 默认情况下,此分区也是 Home。 但是,管理部门不必与业务部门属于同一个部门。
- 一个部门可以包含多个业务部门和多个管理部门。
分区环境中的用户访问权限
- 您可以在部门构建基块的上下文中授予用户访问某些权限的权限。
例如,当您授予用户在部门 1 中的 Workforce Management > 日程安排 > 查看权限时,该用户可以查看与该部门关联的所有业务部门和管理单位中的所有计划,而不管这些计划用户属于哪个部门。 再举一个例子,您可以授予主管在部门 3(主管所在部门)的 “劳动力管理” > “计划” > “编辑” 权限,但只能授予主管在公司其他部门的 “劳动力管理” > “计划” > “查看” 权限。
- 您需要为所需的每个独特的访问控制构建块都有一个独特的部门。
例如,如果某些用户只需要访问管理单元 1 中人员的日程安排,则创建一个只包括管理单元 1 而不包括其他管理单位或业务单位的部门。 该部门的其他任何事物都不会对劳动力管理产生影响。 或者,如果您只想在业务部门级别分开访问控制,则只需为每个业务部门创建一个部门即可。 您可以使用这些部门来分离队列、流程等,因为您不需要仅用于劳动力管理的部门。
部门和劳动力管理通知
只有可以对对象进行操作的主管才会收到有关该对象的通知。
例如,休假请求批准通知会发送给对提出请求的座席所属的管理单位拥有 “劳动力管理” > “休假申请” > “编辑” 权限的主管或用户。 同样的情况也适用于轮班行业批准通知。
提交代理或主管所属的部门对这些通知没有影响。 两个关键点是 a) 座席所属的管理单位;b) 审批主管是否具有包含座席管理单位的部门的 “劳动力管理” > “休假申请” > “编辑” 权限的角色。
示例
此示例包括两个业务部门(销售和支持)以及每个管理部门的一名计划主管。
业务单元 | 管理单位 | 安排管理单位的负责人 |
---|---|---|
销售 | 东部销售 | Sal Easterly |
销售 | 西部销售 | Sal Westerly |
支持 | 支持 West | Hal Easterly |
支持 | 支持 West | 哈尔·韦斯特利 |
该公司还包括以下员工:
- Sal Global,销售业务部门的日程安排负责人
- Hal Global,支持业务部门的日程安排负责人
- Joe Global,整个公司的日程安排负责人
在此示例中,目标如下所示:
- 每个管理单元的日程安排主管都必须有权在自己的管理单元中编辑计划。
- 每个管理单位的日程安排主管都必须有权查看其业务部门中未领导的管理单元。
- 业务部门领导层 Sal Global 和 Hal Global 必须有权编辑其业务部门。
- 公司的日程安排负责人Joe Global必须拥有每个人的编辑权限。
因为我们需要管理单元级别的访问控制构建块,所以我们需要每个管理单元都有一个分区。 按如下方式配置此场景:
分部 | 分部的管理单位 | 部门中的业务部门 |
---|---|---|
东部销售部 | 东部销售 (MU) | 无 |
西部销售部 | 西部销售 (MU) | 无 |
支持东部赛区 | 支持东部 (MU) | 无 |
支持西部赛区 | 支持西部 (MU) | 无 |
最后,将以下角色分配给这些部门的用户:
- 具有 “员工管理” > “计划” > “编辑、添加和查看” 权限的计划编辑者角色
- 具有 “员工管理” > “计划” > “查看” 权限的 “计划查看者” 角色
用户 | 角色 | 分部 |
---|---|---|
Sal Easterly | 计划编辑器 | 东部销售部 |
Sal Easterly | 计划查看器 | 西部销售部 |
Sal Westerly | 计划编辑器 | 西部销售部 |
Sal Westerly | 计划查看器 | 东部销售部 |
Hal Easterly | 计划编辑器 | 支持东部赛区 |
Hal Easterly | 计划查看器 | 支持西部赛区 |
哈尔·韦斯特利 | 计划编辑器 | 支持西部赛区 |
哈尔·韦斯特利 | 计划查看器 | 支持东部赛区 |
萨尔全球 | 计划编辑器 | 销售东部分部、西部销售部 |
哈尔全球 | 计划编辑器 | 支持东部分区,支持西部分部 |
乔·格洛巴 | 计划编辑器 | 销售东部分部、西部销售部、支持东部分部、支持西部分部 |
此示例包括两个业务部门,即销售和支持部门、每个业务部门的计划主管以及一个全球销售线索。
业务单元 | 管理单位 | 管理单位的日程安排负责人姓名 |
---|---|---|
销售 | 东部销售、西部销售 | 萨尔全球 |
支持 | 支持东部,支持西部 | 哈尔全球 |
在这种情况下,由于我们使用更大的访问控制构建块,因此我们简化了并且仅使用两个分区。
业务单元 | 分部的管理单位 | 部门中的业务部门 |
---|---|---|
销售部 | 无 | 销售额 (BU) |
支援部 | 无 | 支持 (BU) |
最后,将以下角色分配给这些部门的用户:
- 具有 “员工管理” > “计划” > “编辑、添加和查看” 权限的计划编辑者角色
- 具有 “员工管理” > “计划” > “查看” 权限的 “计划查看者” 角色
用户 | 角色 | 分部 |
---|---|---|
萨尔全球 | 计划编辑器 | 销售部 |
哈尔全球 | 计划编辑器 | 支援部 |
乔·格洛巴 | 计划编辑器 | 销售部,支持部 |
在此示例中,我们使用与示例二相同的设置,但假设销售团队不断壮大,公司雇用了 Sal Westerly 和 Sal Easterly。 这两位销售线索希望拆分销售业务部门的时间表编辑权限,但不希望拆分支持业务部门的计划编辑权限。
业务单元 | 管理单位 | 管理单位的日程安排负责人姓名 |
---|---|---|
销售 | 东部销售 | Sal Easterly |
销售 | 西部销售 | Sal Westerly |
支持 | 支持东部,支持西部 | 哈尔全球 |
在这种情况下,我们希望对销售部门进行管理部门级别的控制,而对支持部门进行业务部门级别的控制。 我们想要对销售人员进行 MU 级别控制,但希望对支持部门进行 BU 级别控制。 在这里,我们提供两种设置选项。 您首选哪个选项取决于您拥有的现有部门以及如何使用它们来划分对其他非劳动力管理实体的访问权限。
分区设置选项 1
分部 | 分部的管理单位 | 部门中的业务部门 |
---|---|---|
东部销售部 | 东部销售 (MU) | 无 |
支持西部赛区 | 西部销售 (MU) | 无 |
支援部 | 无 | 支持 (BU) |
部门设置选项 2
分部 | 分部的管理单位 | 部门中的业务部门 |
---|---|---|
东部销售部 | 东部销售 (MU) | 无 |
支持西部赛区 | 西部销售 (MU) | 无 |
支援部 | 支持东部 (MU)、支持西部 (MU) | 无 |
最后,将以下角色分配给这些部门的用户:
- 具有 “员工管理” > “计划” > “编辑、添加和查看” 权限的计划编辑者角色
- 具有 “员工管理” > “计划” > “查看” 权限的 “计划查看者” 角色
用户 | 角色 | 分部 |
---|---|---|
Sal Easterly | 计划编辑器 | 东部销售部 |
Sal Easterly | 计划查看器 | 西部销售部 |
Sal Westerly | 计划编辑器 | 西部销售部 |
Sal Westerly | 计划查看器 | 东部销售部 |
萨尔全球 | 计划编辑器 | 销售东部分部、西部销售部 |
哈尔全球 | 计划编辑器 | 支援部 |
乔·格洛巴 | 计划编辑器 | 东部销售部、西部销售部、支持部 |