労働力管理と部門の概要
この記事では、部門が労働力管理でどのように機能するかについて説明します。
部門と労働力管理の重要な概念
このセクションでは、部門が労働力管理でどのように機能するか、エンティティとそれらがビジネスユニットレベルまたは管理ユニットレベルのどこに属するか、および部門内のユーザーアクセスについて説明します。
部門がどのように機能するかを理解する
- 労働力管理の部門を使用して、アクセス制御を分割します。 たとえば、部門は、選択した労働力管理ページの右上隅に表示されるリストに表示されるビジネスユニットと管理ユニットを制限するために使用するコントロールと考えてください。
- 労働力管理では、ユーザーが属する部門は、管理ユニット間でユーザーを移動する場合にのみ重要です。 ユーザーが管理ユニットに関連付けられた後、管理ユニットまたはビジネスユニットが属する部門を理解することが重要です。
- すべてのスーパーバイザー権限は部門に関連付けられていますが、すべてのエージェント権限は関連付けられていません。 エージェントは、部門に関係なく、エージェントに属するページまたはエンティティを表示できます。
- ビジネスユニットは1つの部門にのみ属することができます。 デフォルトでは、この部門はホームです。 管理ユニットは1つの部門にのみ属することができます。 デフォルトでは、この部門もホームです。 ただし、管理ユニットはビジネスユニットと同じ部門に属している必要はありません。
- 部門には、複数のビジネスユニットと複数の管理ユニットを含めることができます。
労働力管理のエンティティは、ビジネスユニットまたは管理ユニットレベルにあります
労働力管理のほとんどのエンティティは、一部の例外を除いて、ビジネスユニットレベルまたは管理ユニットレベルのいずれかにあります。
- 作業計画と休暇申請は、常に管理ユニットレベルに関連付けられています。 管理ユニットレベルのビルディングブロックで、これらの機能に関連する作業計画の権限を付与できます。 ビジネスユニットレベルに付与する権限は、すべての管理ユニットに権限を付与することと同じです。
- 予測は、ビジネスユニットレベルに関連付けられています。 ビジネスユニットレベルで予測に権限を付与することが重要です。 管理ユニットレベルで予測に権限を付与しても、ユーザーの予測へのアクセスには影響しません。
- スケジュールはビジネスユニットレベルに関連付けられているため一意ですが、従業員管理は管理ユニットレベルでのアクセス制御もサポートしています。 休暇申請へのアクセスを許可するのと同じ方法で、従業員管理スケジュールへのアクセスを許可します。 管理ユニットレベルでスケジュールアクセスを許可する場合、その管理ユニットへのアクセスのみを許可します。 ビジネスユニットレベルでスケジュールアクセスを許可すると、すべての管理ユニットへのアクセスも許可されます。 ただし、いくつかの小さな違いがあります。たとえば、ユーザーが初めてスケジュールを生成、再スケジュール、または公開するには、ビジネスユニットレベルで[Workforce Management]>[Schedule]>[Edit]権限が必要です。
部門のコンテキストでのユーザーアクセス
- 部門ビルディングブロックのコンテキストで、ユーザーに特定の権限へのアクセスを許可します。
たとえば、ユーザーに[労働力管理]>[スケジュール]>[部門1の表示権限]を付与すると、このユーザーは、スケジュールされた部門に関係なく、その部門に関連付けられているすべてのビジネスユニットと管理ユニットのすべてのスケジュールを表示できます。ユーザーが所属します。 別の例として、スーパーバイザーに、スーパーバイザーの部門であるディビジョン3で[Workforce Management]> [Schedule]> [Edit]権限を与えることができますが、会社の他の部門では[Workforce Management]>[Schedule]>[View]権限のみを付与できます。
- 必要なアクセス制御ビルディングブロックごとに、固有の部門が必要です。
たとえば、一部のユーザーが管理ユニット1の人のスケジュールにのみアクセスする必要がある場合は、管理ユニット1のみを含み、他の管理ユニットまたはビジネスユニットを含まない部門を作成します。 この部門の他のいかなるものも、労働力管理に影響を与えません。 または、ビジネスユニットレベルでアクセス制御を分離するだけの場合は、ビジネスユニットごとに1つの部門を作成するだけです。 これらの部門は、労働力管理のみに必要な部門ではないため、キューやフローなどを分離するために使用できます。
部門と労働力管理の通知
オブジェクトに作用できるスーパーバイザーのみが、オブジェクトに関する通知を受け取ります。
たとえば、タイムオフリクエストの承認通知は、[Workforce Management]> [Time OffRequest]>[リクエストしているエージェントが属する管理ユニットの編集権限]を持つスーパーバイザーまたはユーザーにルーティングされます。 同じシナリオがシフトトレード承認通知にも当てはまります。
送信エージェントまたはスーパーバイザーが属する部門は、これらの通知に影響を与えません。 2つの重要なポイントは、a)エージェントが属する管理ユニット、およびb)承認するスーパーバイザーがエージェントの管理ユニットを含む部門のWorkforce Management> Time OffRequest>Edit権限を持つ役割を持っているかどうかです。
例
この例には、販売とサポートの2つのビジネスユニットと、各管理ユニットのスケジュールリードが含まれています。
事業単位 | 管理単位 | 管理ユニットのスケジュールリード |
---|---|---|
営業 | セールス・イースト | サルイースターリー |
営業 | セールス・ウエスト | サルウェスタリー |
サポート | サポートウェスト | ハルイースターリー |
サポート | サポートウェスト | ハルウェスタリー |
会社には次の従業員も含まれています。
- セールスビジネスユニットのスケジュールリーダー、Sal Global
- サポートビジネスユニットのスケジュールリーダー、Hal Global
- 全社のスケジュールリーダー、ジョー・グローバル
この例では、目標は次のとおりです。
- 各管理ユニットのスケジュールリーダーは、自分の管理ユニットでスケジュールを編集するためのアクセス権を持っている必要があります。
- 各管理ユニットのスケジュールリードは、リードしていないビジネスユニット内の管理ユニットを表示するためのアクセス権を持っている必要があります。
- ビジネスユニットのリーダーシップであるSalGlobalとHalGlobalは、ビジネスユニットを編集するためのアクセス権を持っている必要があります。
- 会社のスケジュールリーダーであるJoeGlobalは、全員に編集アクセス権を持っている必要があります。
管理ユニットレベルのアクセス制御ビルディングブロックが必要なため、管理ユニットごとに分割する必要があります。 このシナリオを次のように構成します。
事業単位 | 部門内の管理ユニット | 部門内のビジネスユニット |
---|---|---|
セールスイースト部門 | セールスイースト(MU) | なし |
セールスウエスト事業部 | セールスウェスト(MU) | なし |
東部を支援する | サポートイースト(MU) | なし |
西部を支援 | サポートウェスト(MU) | なし |
そして最後に、これらの部門のユーザーに次の役割を割り当てます。
- WorkforceManagement>スケジュール>編集、追加、および表示の権限を持つスケジュール編集者の役割
- WorkforceManagement>スケジュール>表示権限を持つスケジュールビューアの役割
ユーザー | 役割 | アクセス区分 |
---|---|---|
サルイースターリー | スケジュールエディタ | セールスイースト部門 |
サルイースターリー | スケジュールビューア | セールスウエスト事業部 |
サルウェスタリー | スケジュールエディタ | セールスウエスト事業部 |
サルウェスタリー | スケジュールビューア | セールスイースト部門 |
ハルイースターリー | スケジュールエディタ | 東部を支援する |
ハルイースターリー | スケジュールビューア | 西部を支援 |
ハルウェスタリー | スケジュールエディタ | 西部を支援 |
ハルウェスタリー | スケジュールビューア | 東部を支援する |
サルグローバル | スケジュールエディタ | セールスイースト部門、セールスウェスト部門 |
ハルグローバル | スケジュールエディタ | 東部支援、西部支援 |
ジョーグローバル | スケジュールエディタ | セールスイースト部門、セールスウェスト部門、サポートイースト部門、サポートウェスト部門 |
この例には、セールスとサポートの2つのビジネスユニット、各ビジネスユニットのスケジュールリード、およびグローバルリードが含まれています。
事業単位 | 管理単位 | 管理ユニットのスケジュールリードの名前 |
---|---|---|
営業 | セールスイースト、セールスウェスト | サルグローバル |
サポート | 東をサポート、西をサポート | ハルグローバル |
この場合、より大きなアクセス制御ビルディングブロックを使用するため、単純化して2つの部門のみを使用します。
事業単位 | 部門内の管理ユニット | 部門内のビジネスユニット |
---|---|---|
営業部 | なし | セールス(BU) |
サポート部門 | なし | サポート(BU) |
そして最後に、これらの部門のユーザーに次の役割を割り当てます。
- WorkforceManagement>スケジュール>編集、追加、および表示の権限を持つスケジュール編集者の役割
- WorkforceManagement>スケジュール>表示権限を持つスケジュールビューアの役割
ユーザー | 役割 | アクセス区分 |
---|---|---|
サルグローバル | スケジュールエディタ | 営業部 |
ハルグローバル | スケジュールエディタ | サポート部門 |
ジョーグローバル | スケジュールエディタ | 営業部、サポート部 |
この例では、例2と同じ設定を使用しますが、営業チームが成長し、会社がSalWesterlyとSalEasterlyを採用するとします。 これらの2人のリードは、販売ビジネスユニットのスケジュール編集アクセスを分割したいと考えていますが、サポートビジネスユニットは分割したいと考えていません。
事業単位 | 管理単位 | 管理ユニットのスケジュールリードの名前 |
---|---|---|
営業 | セールス・イースト | サルイースターリー |
営業 | セールス・ウエスト | サルウェスタリー |
このシナリオでは、販売ユニットには管理ユニットレベルの制御が必要ですが、サポートユニットにはビジネスユニットレベルの制御が必要です。 セールスにはMUレベルの制御が必要ですが、サポートにはBUレベルの制御が必要です。 ここでは、2つのセットアップオプションを提供します。 どのオプションを選択するかは、既存の部門と、それらを使用して他の非労働力管理エンティティへのアクセスを分割する方法によって異なります。
分割設定オプション1
アクセス区分 | 部門内の管理ユニット | 部門内のビジネスユニット |
---|---|---|
セールスイースト部門 | セールスイースト(MU) | なし |
西部を支援 | セールスウェスト(MU) | なし |
サポート部門 | なし | サポート(BU) |
分割設定オプション2
アクセス区分 | 部門内の管理ユニット | 部門内のビジネスユニット |
---|---|---|
セールスイースト部門 | セールスイースト(MU) | なし |
西部を支援 | セールスウェスト(MU) | なし |
サポート部門 | サポートイースト(MU)、サポートウェスト(MU) | なし |
そして最後に、これらの部門のユーザーに次の役割を割り当てます。
- WorkforceManagement>スケジュール>編集、追加、および表示の権限を持つスケジュール編集者の役割
- WorkforceManagement>スケジュール>表示権限を持つスケジュールビューアの役割
ユーザー | 役割 | アクセス区分 |
---|---|---|
サルイースターリー | スケジュールエディタ | セールスイースト部門 |
サルイースターリー | スケジュールビューア | セールスウエスト事業部 |
サルウェスタリー | スケジュールエディタ | セールスウエスト事業部 |
サルウェスタリー | スケジュールビューア | セールスイースト部門 |
サルグローバル | スケジュールエディタ | セールスイースト部門、セールスウェスト部門 |
ハルグローバル | スケジュールエディタ | サポート部門 |
ジョーグローバル | スケジュールエディタ | セールスイースト部門、セールスウェスト部門、サポート部門 |