さまざまな階層方法の説明

計画者階層は組織に対して定義されているポジション管理体系図を参照し、報酬フォームはこの階層に基づいて生成されます。通常、これはコンサルタントによって導入ステージで設定され、計画中は一定に保持されます。

報酬計画者は、社員の報酬変更を推奨する責任があります。SAP SuccessFactors Compensation では、計画担当者を指定する以下の方法がサポートされています。

• 標準階層
• ロールアップ階層
• 報酬マネージャー階層

階層の変更の場合、管理者はプランの詳細→ ユーザーの管理に移動できます。報酬テンプレートを使用してすでに開始されているフォームがある場合、階層を変更することはできません。

これは、SAP SuccessFactors スイートで使用される階層であり、ユーザーデータファイルのマネージャー列に従うように構成されています。この構造は、組織図に表示される標準レポート構造です。これは、単に直属の部下を持つすべてのユーザーが計画担当者とみなされ、直属の部下の給与変更を推奨する責任があることを意味します。

以下の図は、標準階層が使用される場合のユーザデータファイルの例を示しています。MANAGER 列には、報酬プランナーのユーザー ID が含まれます。

• 最も単純な計画方法
• 追加設定なし
• 最も動的
• 完全なエンパワーメントにより、誰が計画を立てているかが制限されない

• 作成されたフォームの数が多すぎます
• 計画担当者は人事マネージャーでもあるため、この階層は組織変更に影響を受けやすくなります。
• 再編成の場合、報酬計画に影響があります。

集計階層により、特定のマネージャーが報酬プランナーとして識別されます。このシナリオでは、報酬プランナーとして指定されている個人は、直属の部下を持つ社員でもあります。ただし、必ずしもすべてのマネージャーが計画担当者であるとは限りません。

最も一般的なビジネスシナリオでは、報酬計画は直属の上司ではなく、取締役や店舗責任者などの上位レベルの管理職によって実行されます。そのため、ディレクターまたは店舗マネージャは報酬計画担当者として指定され、その下の従業員は報酬ワークシートにロールアップされます。計画担当者は、階層の下位レベルの責任者です。

報酬計画担当者は、管理インターフェイスまたはユーザーデータファイルで識別されます。

報酬ホームで、プランのセットアップ→ユーザーの管理に移動します。階層の責任者を検索し、ボックスにチェックマークを挿入することで、マネージャの中で誰が計画担当者とみなされるかを識別することができます。

上記の例では、5 人のプランナーではなく、Carla Grant と Richard Maxx のみが報酬フォームを持ちます。これらはプランナーとして識別されています。トーマス・クラークとシド・モートンの計画責任は、リチャード・マックスに編入されたドリス・ダグラスと同じくカーラ・グラントに編入された。

ユーザーデータファイルで集計計画者を特定するために、計画者列が追加されています。

• COMPENSATION_PLANNER_XX、XX はプランテンプレート番号に置き換えられます。

• プロフェッショナルサービスコンサルタントまたは顧客の関係者に適切なテンプレート番号を確認します。

• 計画担当者として識別されたマネージャは、この列の値が TRUE になります。

• ロールアップ階層は、すべてのワークシートを更新を使用して適用できます。

ワークシートにマネージャーのロールアップを含める集計階層オプションは、以下の選択に対して有効化されています。

• 新たに資格のある社員を報酬ワークシートに追加します。
• 社員の報酬データを以前のマネージャーから現在のマネージャーに移動します。
• 報酬ワークシートから無効な社員を削除します。
• 無効なプランナーの報酬ワークシートを削除します。

• 計画担当者の容易な割当を許可
• 複雑さ/使用中のフォーム数を削減できる

• 集計レポートは正しく機能しません

代替階層である報酬マネージャーは、報酬計画を組織変更、または一般的にその年に行われる管理職の異動から独立させたい企業によって使用されます。

この階層では、報酬固有の UDF 列である SECOND_MANAGER が使用され、誰が報酬計画者とみなされるかが定義されます。

各報酬プランナーには、報酬を計画する直属の部下が割り当てられます。

• 報酬計画者は人事マネージャーとは異なるため、通常は組織変更の影響を受けません。

• 管理作業を維持する必要があり、他の 2 つの方法よりも中断しやすくなります。
• ルートマップロール (EA、EAA など) などの追加の設定が必要です。
• 代替ポジション管理体系図の責任者を特定するには、セカンドマネージャ列を空白にする必要があります。

これは、SAP SuccessFactors スイートで使用される階層であり、マネージャー列に従うように構成されています。

集計階層により、特定のマネージャーが報酬プランナーとして識別されます。このシナリオでは、報酬プランナーとして指定されている個人は、直属の部下を持つ社員でもあります。ただし、必ずしもすべてのマネージャーが計画担当者であるとは限りません。

最も一般的なビジネスシナリオでは、報酬計画は直属の上司ではなく、取締役や店舗責任者などの上位レベルの管理職によって実行されます。そのため、ディレクターまたは店舗マネージャは報酬計画担当者として指定され、その下の従業員は報酬ワークシートにロールアップされます。計画者は自分の階層のラインを落とす責任がある。

ユーザーの管理計画者の定義計画者の方法ドロップダウンメニューで報酬プランに使用する→→プランナー階層を選択して、選択します。

選択すると、選択した階層をナビゲートすることができます。階層のヘッダまたは特定の計画担当者を検索して、計画階層をドリルダウンします。各計画担当者の横にある三角形を使用して、階層を展開または折りたたみます。

階層内のブレークにより、フォームが作成または開始されない場合があります。階層内のブレークをチェックするには、以下のいずれかの方法を実行します。

1. 報酬ホーム管理インターフェイスからトラブルシューティング情報をエクスポートします。

   報酬ホームに移動し→、テンプレートを選択→プランの設定 Def→ine Planners→の計画者検索を選択し、マネージャーおよび資格のないユーザーをエクスポートします。

2. チェックツールは、設定の不整合をチェックするためにすべてのモジュールで利用できる機能です。報酬と変動給では、ツールを使用して以下を検証することができます。
   • 周期依存の計画階層チェック

     このチェックを使用して、報酬プラン階層で計画担当者に依存関係の循環があるかどうかを判別します。依存関係の循環は、社員 A が社員 B の計画担当者であり、社員 B が社員 A の計画担当者である場合です。その場合、フォームの生成を続行できません。

   • 無効な計画担当者の計画階層チェック

     このチェックを使用して、報酬プラン階層内の無効なプランナーを決定します。階層が正しく定義されていない場合、無効なマネージャーには引き続き直属の部下が存在する可能性があります。無効なマネージャーに対してフォームが作成されないため、これらの社員はレビューされません。

   • プランナーのいないユーザーのプラン階層を確認

     このチェックを使用して、システムで計画担当者が割り当てられていないユーザーを特定します。報酬マネージャー階層を使用する場合、このフィールドには値 NO_MANAGER を含めることができます。その場合、階層の責任者にその値が定義されている場合、会社全体のフォームを開始することはできません (単一のフォームを開始することはできません)。

   • 計画テンプレートの無効な設定のチェック

     このチェックを使用して、プランテンプレートで無効な設定を特定します。たとえば、顧客がフィールドでカスタム計算式を定義し、これらの計算式で参照テーブルから取得された値を使用する場合などです。これらのチェックでは、値が正しく表示されるように、数値または文字列への関数が必要です。括弧がないため、論理式構文が正しく定義されない場合もあります。

   • リロード可能なユーザ定義項目の計画テンプレートのチェック

     このチェックを使用して、プランテンプレートで設定されたすべての再読み込み可能なカスタムフィールドを決定します。最も繰り返されるインシデントの 1 つは、顧客がフォームをすでに開始している場合です。特定のカスタムフィールドでは、ワークシートの進行中に新しい値がインポートされます。フォームでの変更は動的に行われることを想定していますが、これらのフィールドはリロード可能 = "true" として定義されていないため、フォームには引き続き古い値が反映されます。この問題には回避策がなく、すべての進行中のフォームを削除し、再開してカスタムフィールドを新しい値で更新する必要があります。再読み込み可能なカスタムフィールドの数を示すチェックを定義すると、お客様は、再読み込み可能として定義されているフィールドを特定し、不足している項目を確認し、フォームを開始する前にそれらを変更することができます。

   • レポート可能なカスタムフィールド用のプランテンプレートのチェック

     最も繰り返されるインシデントの 1 つは、顧客が報酬フォームを完了し、アドホックレポートで特定のカスタムフィールドを表示する必要がある場合ですが、これらのフィールドはレポート可能 = "true" として定義されていないため、レポートでは選択できません。この問題には回避策がなく、フォームを削除および再実行する必要があります。レポート可能なカスタムフィールドの数を示すチェックを定義すると、レポート可能として定義されているフィールドを特定し、不足している項目を確認し、フォームを開始する前にそれらを変更することができます。

   • 明細設定のプランテンプレートのチェック

     このチェックを使用して、報酬プランテンプレートの設定中に発生した明細設定に関する設定の問題を特定します。たとえば、プランテンプレートで明細固有の XML 属性を "true" に設定する必要がある場合などです。ワークシートの給与、ボーナス、およびストックタブで報酬明細を表示するには、テンプレートで includeSalaryStatement、includeBonusStatement、および includeStockStatement 属性をそれぞれ "true" として設定する必要があることに注意してください。

   • 計算の追加チェック

     このチェックを使用して、参照テーブルが存在するかどうかを判断し、カスタムフィールドと標準フィールドのデータタイプの一致を検証し、重複したフィールド ID の大文字と小文字を区別してチェックします。

   • 階層の先頭が、設定された階層タイプに対して適切に設定されています。

     報酬プランの各階層長のマネージャー ID をレビューします。

   • UDF レコード内のすべての日付フィールドが正しく書式設定されています

     報酬テンプレートの日付フィールドが正しく書式設定されていることを確認します。

チェックツールには、役割ベースの権限とメタデータフレームワークが必要です。この機能を使用するには、以下の管理権限を付与します。

• チェックツールへのアクセスにより、ツールにアクセスする権限がユーザーに付与されます。
• 設定のエクスポートを許可により、チェックツール内からシステム設定データをエクスポートすることをユーザーに許可します。

両方の権限には対象範囲が必要です。

1. ワークシートの管理タブから、またはアクション検索を使用して、チェックツールを起動します。
2. アプリケーションドロップダウンから報酬を選択します。
3. 検証オブジェクトチェックの一覧から、実行する適切なオブジェクトを選択します。
4. 結果を表示します。以下のいずれかになります。
   • 正常終了 - メッセージは表示されません。
   • X の不整合が見つかりました。X は検出された不整合の数です。

不整合が見つかった場合は、黄色の警告アイコンまたは赤色のアラームアイコンが表示されます。黄色のアイコンは、問題が深刻すぎず、解決策が提案されることを示す警告です。赤いアイコンは、問題が深刻であることを意味します。アクションを実行する必要があります。これには、チケットの作成が含まれる場合があります。

• 階層選択およびナビゲーション: 報酬プランの計画者階層を選択して、シームレスなナビゲーションを確保し、階層ブレークが原因でフォームが失敗しないようにします。

• 検証ツール: チェックツールを使用して、報酬と変動給の設定の不整合 (周期的な依存関係、無効なプランナー、プランナーのいないユーザー、無効なプランテンプレートの設定など) を特定します。

• テンプレートチェック: 再読み込み可能/レポート可能なカスタムフィールド、明細設定の問題、および計算テーブルの存在についてプランテンプレートに対するチェックを実行し、すべての設定がレポートのニーズおよび報酬プロセスと一致していることを確認します。

• 階層長および日付書式: 階層長の正しい設定を確認し、UDF レコードの日付フィールドがシステムの整合性と機能を維持するために適切に書式設定されていることを確認し、検出された不整合に警告またはアラームアイコンで対処します。