Skip to main content

組織を設定して要件を特定する

学習の目的 

この単元を完了すると、次のことができるようになります。

  • リベート管理でデータ処理エンジン定義がどのように機能するかを説明する。
  • ユーザーに権限と定義へのアクセス権を付与する。
  • 新しいリベートプログラムの要件と定義を特定する。

始める前に

このモジュールを受講する前に、「リベート管理の基本」を完了しておく必要があります。ここでの作業は、同モジュールでの概念や作業に基づいて行います。 

インセンティブモデルを強化する

Rayler Parts は、長年 Salesforce リベート管理を利用して、パートナーに最適なリベートプログラムを作成し、発生金額と支払金額を自動的に計算しています。また、このアプリケーションでは、パートナーはパートナー Experience Cloud サイトで取引と支払を参照することもできます。このように、プログラムに高い収益性があることを確認できるため、パートナーはビジネスを繰り返し行うようになります。

リベートプログラムは、インセンティブや報奨金に基づいて行われますが、どのインセンティブモデルも万能のソリューションではありません。パートナーの数が着実に増えていることから、Rayler Parts はリベートプログラムをカスタマイズして、パートナーのさまざまなニーズに対応したいと考えています。 

Rayler Parts のリベートプログラムマネージャーである Rishi とシステム管理者の Cindy については、皆さんもよくご存じだと思います。Rishi はリベート管理を使用して、Cindy の助けを借りながら Rayler Parts の最初のリベートプログラムを設計しました。このモジュールでは、リベート管理用に事前定義されたデータ処理エンジン (DPE) 定義をカスタマイズして、特殊なインセンティブモデルをサポートする方法を学習します。Cindy と Rishi が Rayler Parts 組織を設定し、新しいリベートプログラムを構築して DPE 定義をカスタマイズする様子を追っていきましょう。ですが、その前に DPE 定義がどのように機能するかについて説明します。 

DPE 定義の機能

皆さんは組立ラインに詳しいですか? 主に自動車産業で使用される組立ラインでは、自動車の製造は事前定義された順序で完了するステップに分割されています。自動車の製造に投入される部品は材料 (入力) として扱われ、順番に追加されます。仕掛品の製品は、すべての部品が追加されて完成車になる (変換される) まで、ワークステーションから別のワークステーションへと移動されます。これは、効率的でスケーラブルな方法です。 

まさに自動車の組立ラインのように、DPE 定義によってデータ入力 (部品) はクリーンな集計データにデータ (完成車) に変換されます。DPE 定義を作成して、データ入力の定義だけでなく、データ処理エンジンでさまざまなオブジェクトと項目をしてリベート支払のためにデータの抽出、絞り込み、集計を行う方法のロジックを定義します。また、データ処理エンジンで多様な項目とオブジェクトの結合、絞り込み、グループ化、集計を行う際の一連のステップも定義します。

データが変換されると、その結果は組織の新規または更新されたレコードとして書き戻されます。これにより、Rishi は何百万件もの取引に関する集計データを取得できます。また、メンバーごとに集計されたデータや、製品ごと、商品カテゴリごと、地域ごと、さらには取引ごとなどの詳細なレベルで集計されたデータを確認した上でリベート金額を支払うことができます。

Cindy と Rishi がリベートプログラムの DPE 定義をどのようにカスタマイズするかを見る前に、組織にデータ処理エンジンを設定するために、Cindy が何をする必要があるのかを確認しましょう。

組織の準備を整える

リベート管理には、事前定義された DPE 定義がいくつか用意されています。組織でリベートを有効にすると、その定義も自動的に利用できるようになります。ただし、定義を使用して実行するには、Cindy はデータパイプラインなど、いくつかの機能を設定する必要があります。データパイプラインを使用すると、Salesforce 組織内にあるデータの照会と計算を行うことができます。

メモ

このモジュールでは、受講者がリベート管理システム管理者またはリベートプログラムマネージャーであり、リベートプログラムとリベート計算の設定と管理を行うための適切な権限を有していると想定しています。ただし、リベート管理システム管理者でなくても問題ありません。このまま読み進み、本番組織でシステム管理者がこれらの手順をどのように実行するのか確認します。Trailhead Playground で次の手順を実行しないでください。Trailhead Playground ではリベート管理を使用できません。

[設定] でデータパイプラインを見つけるには、「データパイプラインベースユーザー」権限セットを自分に割り当てる必要があります。Cindy はシステム管理者なので自分に割り当てます。その手順は次のとおりです。

  1. 設定 をクリックし、[設定] を選択します。
  2. [クイック検索] ボックスに ユーザーと入力し、[ユーザー] を選択します。
  3. ユーザーの名前をクリックします。Cindy は [Cindy Jones] をクリックします。
  4. [権限セットの割り当て] をクリックし、[割り当ての編集] をクリックします。
  5. [データパイプラインベースユーザー] 権限セットを選択します。
  6. [追加] をクリックし、さらに [保存] をクリックします。

ユーザーに割り当てることができるリベートに必要な権限セットのリストが表示されている [設定] の [権限セット] ページ。

Cindy は、組織を更新し、データパイプラインを有効にする手順を進めます。

  1. 設定 をクリックし、[設定] を選択します。
  2. [クイック検索] ボックスにデータパイプラインと入力し、[Get Started (使用開始)] を選択します。
  3. [データパイプライン] を有効にします。

[データパイプライン] を有効にできる [設定] の [使用開始] ページ。

また、Cindy はデータ処理エンジンで支払集計に使用するデータを含む特定のオブジェクトと項目へのアクセスを制御する必要もあります。必要とされるアクセスの種別と、それによって有効になるアクションのリストを以下に示します。

必要な最小限のアクセス権
実行できるアクション
「すべてのデータの編集」権限と「アプリケーションのカスタマイズ」権限が必要です。
データ処理エンジン定義を作成して保存できます。
オブジェクトとその項目、および関連オブジェクトとその項目に対する「参照」アクセス権が必要です。
データ取得元ノードのオブジェクトやその項目、関連オブジェクトとその項目を表示して選択できます。
オブジェクトと項目に対する「作成」アクセス権が必要です。
書き戻しオブジェクトノードのオブジェクトまたはその項目を表示して選択できます。
書き戻しノードで書き戻しユーザーとして指定されているユーザーに、すべての取得先のオブジェクト、項目、関連オブジェクトに対する「作成」アクセス権が必要です。
書き戻しノードの取得先のオブジェクトと項目を定義し、関連項目の対応付けを定義できます。
Analytics Cloud インテグレーションのユーザープロファイルを持つユーザーに、データ取得元ノードで選択されたすべてのオブジェクトと項目に対する「参照」アクセス権が必要です。
定義の有効化を行えます。

「データパイプラインベースユーザー」権限セットでは、システム管理者は組織のデータ消費量を監視して、データ制限を超えないようにすることもできます。

組織の準備が整ったので、Rishi はリベートプログラムとそのデータ処理エンジンの要件に関する計画を立て始めることができます。

要件を計画する

AMER の取引先マネージャーは、地域のパートナー用に新しいリベートプログラムを提案しました。取引先マネージャーが求める要件は大きく分けて 2 つあります。

商品カテゴリ: 取引先マネージャーは、パートナーが注文した商品カテゴリに応じてリベートを分配する必要があります。すべての商品カテゴリに同じビジネス価値があるわけではありません。そのため、どのような商品が販売されても、パートナーへのリベートが一律であっては意味がありません。たとえば、ナット、塗料缶、ボルトなどの付属品に対するリベートは、ハンマーやコンパクターなどの主力商品に比べて少なくなります。

割引後の取引金額: 取引先マネージャーは、販売計画を設定する際に、特定の商品をパートナーに大幅に割引した価格で販売します。リベートは元の合計金額ではなく、割引後の注文金額に対して提供される必要があります。これは、取引先マネージャーが収益の漏出を最小限に抑えられるようにするためです。

Rishi は、取引先マネージャーに電話をかけて要件の詳細を確認し、以下の情報を収集します。

何を必要としているか?
仕様
リベートプログラム
AMER パートナーを対象とした 1 年間のリベートプログラム。各月の支払は翌月の初日に分配されます。
プログラムメンバー
AMER 地域で Rayler Parts 商品の販売と配布を行っているすべてのパートナー取引先。
リベート種別
数量ベースのリベート。パートナーは各月に販売した商品の合計数量に応じて報奨を得ます。
リベート種別の詳細

数量ベースのリベートの報奨金基準は、以下のようにする必要があります。

  • 報奨金資格対象項目: 報奨金階層の資格は注文の総取引額によって決定されます。
  • 基準項目: 資格対象となる各階層の実際のリベートは、注文の割引後の総取引額に基づいて分配されます。
  • 指標種別: リベート金額は、割引後の総収益に対する割合 (%) である必要があります。
  • 計算定義: 取引はメンバー別に集計され、商品カテゴリ別にグループ化される必要があります。
報奨金階層

以下の報奨金階層を適用する必要があります。

  • Bronze Rebate for Accessories (付属品に対するブロンズリベート): 取引金額が 10,000 ドルを超える場合、3% のリベート
  • Platinum Rebate for Compactors (コンパクターに対するプラチナリベート): 取引金額が 30,000 ドルを超える場合、8% のリベート
  • Silver Rebate for Hammers (ハンマーに対するシルバーリベート): 取引金額が 1,000 ドル ~ 10,000 ドルの場合、3% のリベート
  • Gold Rebate for Hammers (ハンマーに対するゴールドリベート): 取引金額が 10,001 ドルを超える場合、5% のリベート
その他の項目要件

リベートメンバー商品集計という集計オブジェクトと取引記録オブジェクトには、以下の項目を表示する必要があります。

  • Product Category (商品カテゴリ)
  • Total Discounted Transaction Amount (割引後トランザクション合計金額)

Rishi はすべての要件を収集しました。次は、使用する必要のある事前定義された DPE 定義を評価していきましょう。

必要な定義を決定する

「リベート管理の基本」で紹介したように、Cindy は Rishi に目的に応じて使用できる事前定義された DPE テンプレートや定義の概要を説明しました。 

Aggregate by Member (メンバー別集計) 定義を使用することで、Rishi は何千もの取引レコードをメンバーごとに 1 行に集計できます。各行には、メンバーの 1 つの支払期間における取引総額と注文総数が表示されます。Rishi は、各メンバーが注文した商品カテゴリや割引前と割引後の取引金額を可視化して、パートナーへの支払が公平に分配されるようにしたいと考えています。

ですが、取引記録オブジェクトとリベートメンバー商品集計オブジェクトには、[商品カテゴリ] 項目と [Total Discounted Transaction Amount (割引後トランザクション合計金額)] 項目がありません。 

Rishi は Cindy と連絡を取り、必要なカスタマイズについて相談します。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む