Objective
報酬プランは、各受取人に報酬を支払う方法を指定するルールセットを含むオブジェクトです。報酬プランには、さまざまなコンポーネントおよびエレメントが含まれています。報酬プランでは、これらのルールを使用して、取引およびオーダーの割当方法と、インセンティブ収入の計算方法および参加者への支払方法が決定されます。
参加者、ポジション、肩書を使用して組織データを作成する方法を示しました。
通常、報酬プランはタイトルに割り当てられますが、プランを個別のポジションに割り当てることもできます。データは常にポジションのコンテキストで計算されます。特定の計算に対して 1 つのポジションが検索され、これらのオブジェクトのデータにアクセスすることができます。その結果、たとえば、参加者レコードから基本給を取得し、ポジションレコードから職務コードを取得するルールを作成することができます。
報酬プランをタイトルに割り当てる理由つまり、一般的な報酬シナリオには多数の参加者が含まれるため、それぞれが一意のポジションに割り当てられます。
先ほど見てきたように、タイトルにより、同様の方法で報酬が支払われるポジションがグループ化されます。報酬プランをタイトルに割り当てると、参加者にカスケードされるため、全員がそのタイトルを保有している限り、全員に報酬が支給されます。
例を見てみましょう。Terry Callahan と Amy Whitton はどちらも営業担当者です。Terry は米国東部地域で販売し、Amy は英国で販売しています。それぞれに一意のポジションがありますが、どちらも営業員というタイトルを持ちます。
弊社の計画では、すべての営業員に報酬が支給されるため、計画をこのタイトルに割り当てることで、Terry と Amy の両方がこの計画で補償されるようになります。
困難 開発プロジェクトと同様、開発は慎重な計画と文書化から始まります。計画のさまざまなコンポーネントを確認すると、作成したレコードとオブジェクトがどのように連携して目的の出力を作成するかを確認できます。まず、計画を作成するための基本的なステップから始めましょう。
報酬プランは非常に複雑になる可能性があるため、計画を開始するのは困難です。適切な最初のステップは、要件の一覧から開始することです。
開始時に確認すべき質問は以下のとおりです。
たとえば、新契約に対して 5% の手数料を支払うものの、更新手数料は 2% のみ支払う場合があります。
先ほど説明したように、受取人間の関係を使用して、ある受取人から別の受取人への貸方のロール方法を決定することができます。たとえば、販売代理者が終了した取引からクレジットを受け取り、そのマネージャが販売代理店からクレジットを受け取るようにすることができます。これは、ロール済みクレジットまたは間接クレジットと呼ばれます。
クレジットをローリングする場合は、レポート階層を使用するか、カスタム合算関係を作成することができます。たとえば、プリセールスエンジニアが販売を支援した場合、クレジットを受け取ることを希望する場合もあります。
このコースの前半では、事業単位についての説明を思い出してください。小規模な組織であっても、常に少なくとも 1 つの事業単位を使用することをお奨めします。
取引は、テリトリまたはカスタム条件を使用して、取引ですでに識別されている受取人に貸方転記することができます。
これらの各タイプのインセンティブは、インセンティブルールで定義されます。
報酬プランは、報酬ルールで構成されます。各参加者に正確に報酬が支払われるように、これらのルールは順番に続きます。
計画で使用できるルールには、販売者と販売責任者、代理店、およびその他の受取人にクレジットを割り当てるクレジットルール、各受取人のクレジットを集計して達成、売上合計、ブッキング、またはその他の KPI を測定する測定ルール、測定に基づいて各受取人の収入額を計算するインセンティブルール、および各インセンティブ収入の支払条件を設定するディポジットルールの 4 つのタイプがあります。
次のセクションでは、これらの各ルールについて詳しく説明します。
インセンティブ管理では、クレジットルールを使用して、取引、オーダー、またはロールアップ可能なクレジットを分析し、販売に対してクレジットを受け取るポジションを決定します。必要に応じて、貸方は 1 つまたは複数の取引、カテゴリ、テリトリ、またはその他の条件に基づいて配分されます。
与信ルールには、直接与信ルールと間接与信ルールの 2 つのタイプがあります。
直接クレジットルールでは、販売を行った営業員、プロデューサ、または代理店にクレジットが割り当てられます。取引およびオーダーは、直接与信ルールへの入力です。
間接クレジットルールは、合算されたクレジットを割り当てるために使用されます。入力は、直接与信ルールの出力です。たとえば、マネージャーが部下によって実行された売却に基づいて報酬を受け取る場合に、間接クレジットルールを使用します。
報酬計画設計の 99% は、取引に基づく直接および間接クレジットのルールです。場合によっては、オーダーレベルの処理が行われるため、与信ルールはオーダーに基づきます。指図レベル処理は、計画設計の集中的で非効率的な方法であるため、ベストプラクティスではありません。オーダーレベルの処理では、複雑な計算を行うことができないため、カスタマイズ可能な報酬プラン開発アプローチではありません。
貸方を配分する方法は複数ありますが、取引に割り当てられた受取人に貸方を割り当てる簡単な例を見てみましょう。
まず、参加者またはポジションのいずれかが取引に関連付けられていることを確認します。上の図では、ポジション SR-C2 が事前に割り当てられています。この情報は CRM で発生し、トランザクションとともにインセンティブ管理に転送されました。
与信ルールで貸方ボックスをチェックします (トランザクションで特定されている場合)。
測定ルールは、各受取人の達成度を測定するために使用されます。計測ルールには、一次と二次の 2 つのタイプがあります。
一次測定ルールでは、単一のポジション割り当てのすべてのクレジットが集計されます。一次測定ルールは一般的に単純ですが、いくつかの方法で微調整することができます。たとえば、特定の基準を満たすクレジットのみを集計することができます。この場合、条件またはテリトリをルールに追加することができます。
二次測定ルールでは、ルール、ダッシュボード、および分析のデータをさらに管理するために、一次測定に基づいて追加の計算が実行されます。
二次測定の一般的な用途には、以下が含まれます。
与信タイプが製品収益のすべての貸方を集計する測定ルールの例を見てみましょう。まず、この履修単位タイプを含める条件のみを追加します。次に、計測値を Credit.Value に設定します。つまり、集計値が各貸方の値項目に含まれます。
インセンティブ規則により、営業員の収益が計算されます。単一測定を入力として使用して単一の出力を生成するという単純なものもあれば、複数の入力を使用して複数の出力を生成するという複雑なものもあります。
インセンティブルールには、基本または集計、ボーナス、およびクレジットごとのコミッションの 3 つのタイプがあります。
基本または集約インセンティブルールでは、固定レートまたはスライドレートを使用して手数料が計算されます。このタイプのルールでは、計測が入力として使用され、レートテーブル、固定値、ルックアップテーブル、または論理式を使用して、計測に基づいて手数料金額が生成されます。
ボーナスインセンティブルールは、コミッションではないボーナスまたはその他のインセンティブの計算に最適です。通常、ボーナスインセンティブルールは、測定に基づいてインセンティブ額を計算しないルールとして定義されます。
クレジットごとのコミッションのインセンティブルールでは、各クレジットの値が評価され、クレジットごとに個別のコミッション金額が生成されます。その後、これらの金額がルールによって集計され、インセンティブの形式で合計手数料が生成されます。
これで、測定ルールからの売上合計が得られ、インセンティブルールでのレートテーブルの適用方法を確認することができます。
以前は、固定値を使用してクォータを含める方法を確認しました。インセンティブルールでは、これを入力として使用して達成率を決定します。
先ほど見てきたレート表には、2 つの階層があります。営業予算の 100% を下回る売上は 3% のコミッションを支払い、販売枠を上回る売上は 5% のコミッションを支払います。その後、インセンティブルールでこのレートテーブルを参照することができます。
このインセンティブルールの結果は、収入です。つまり、各受取人がこのルールから獲得した金額です。
預金ルールにより、支払条件が決定されます。これにより、インセンティブ収入がどの程度預け入れられるか、およびいつ預けるかが決定されます。
ディポジットは、インセンティブがディポジットに利用可能である場合にのみ登録されます。たとえば、2 月の計算実行では、四半期インセンティブルールのディポジット出力は生成されません。
預金ルールには、基本預金と詳細預金の 2 種類があります。
この例では、インセンティブルールからの出力が預金ルールの入力です。図 " 預金ルールの例 " のインセンティブルールの出力名は IO_Monthly Product Sales Commission です。"営業員報酬プラン" の図に示されている預金ルールの金額フィールドでも、同じオブジェクトが使用されます。つまり、計算した収入の価値は、私たちが支払う金額と同じです。
また、給与計算チームの利益のために、支払いを製品コミッションとしてエンコードするようにシステムに指示する必要もあります。これは、預金ルールの収入コードフィールドで行います。
これまで、各受取人に対する報酬の計算において、各タイプのルールがどのように役割を果たすのかを確認しました。ただし、受取人の基本報酬構造は同じでも、テリトリまたはレートが異なる場合はどうすればよいですか。
この場合、複数のルールは必要ありません。インセンティブ管理には、プラン内の報酬要素のプレースホルダとして機能する、変数と呼ばれるタイプのオブジェクトがあります。
例を見てみましょう。Terry Callahan と Amy Whitton は、同じ計画に割り当てられている営業担当者です。どちらも販売テリトリがあり、月次コミッションと四半期ボーナスが支払われます。ただし、地域、料金、およびボーナスの金額が異なります。
これは、実際の報酬要素の代わりに変数を代入して、ルールを作成する際に解決します。たとえば、販売テリトリの入力を求められた場合は、代わりにテリトリ変数を挿入します。プラン全体を通してレートテーブルと固定値でも同じことが可能です。
報酬プランを作成すると、これらの変数は正しいオブジェクトにマッピングされます。
このセクションの内容に基づいて、導入の開始前に会社が行う必要がある導入決定の一覧をレビューし、ステークホルダ、プロジェクトチーム、および SAP 導入コンサルタントと話し合ってください。これにより、導入を開始する準備が整います。