高度な取引先販売予測を調査する
学習の目的
この単元を完了すると、次のことができるようになります。
- マルチエンタープライズビジネスの取引先販売予測要件を説明する。
- 取引先販売予測フレームワークと高度な取引先販売予測フレームワークを比較する。
- 高度な取引先販売予測の利点を挙げる。
- 高度な取引先販売予測を有効化して適切な権限セットを割り当てる。
始める前に
このモジュールを始める前に、「Sales Agreements and Forecasting in Manufacturing Cloud (Manufacturing Cloud での販売計画と売上予測)」を完了しておく必要があります。ここでの作業は、同モジュールでの概念や作業に基づいて行います。
Rayler Parts は成長している!
Rayler Parts のビジネスは拡大し続けており、変化する要件に後れを取らないように S&OP (Sales and Operations Planning) を拡張する必要があります。S&OP を成功させるための鍵の 1 つが正確な販売予測です。会社が成長しているため、注文、商談、販売計画などビジネスの全容を常に可視化しておく必要があります。完全な可視化なしに、360 度の販売予測ビューは得られません。
これまで Rayler Parts は Manufacturing Cloud の取引先販売予測を使用していました。シンプルな取引先-商品-期間の組み合わせによる販売予測は、会社の黎明期にはぴったりだったのですが、成長に伴い不足する部分が出ています。どうすればよいか見ていきましょう。
Rayler Parts では最近、ビジネスのやり方を変え、重機と産業機器を 2 つの主要なビジネスユニットを通じて販売しています。
- 産業ビジネスユニットでは、高価な商品に絞って厳選した産業取引先に販売しています。
- 消費者ビジネスユニットでは、2 つの主要なチャネル (eコマースポータルとパートナーネットワーク) を通じて幅広い商品を多種多様な取引先に販売しています。
2 つのビジネスユニットの販売予測要件は異なり、現在の取引先販売予測フレームワークでは対処できない要件があります。
Rayler Parts のお客様とパートナーは複数の国と地域に分散しています。まさにグローバル企業です。商品はさまざまなロケーションから同じ取引先に出荷され、流通センターごとに販売予測データを評価する必要があります。現在、出荷元ロケーションは取引先の販売予測ディメンションとして使用できません。
また、すべての関係者が販売予測データに関してコラボレーションする効果的な方法がありません。パートナー、取引先マネージャー、地域営業マネージャーは一元的な情報源である取引先販売予測データ内でそれぞれが行う調整を追跡したいと考えています。
Rayler Parts のシステム管理者である Cindy Jones はアカウントエグゼクティブと話し合い、こうした全般的な要件をメモします。Badger Parts では高度な設定と拡張が可能な販売予測ソリューションを探しています。Cindy はこの課題に向けて張り切っています。
比較して違いを理解する
Cindy は Salesforce の Rayler Parts 担当営業から Manufacturing Cloud に高度な取引先販売予測という新しい販売予測フレームワークが追加されたことを聞きました。うわさでは、複雑で設定可能なマルチエンタープライズ販売予測を求めているなら最適な選択肢だということです。
次の短い動画で、高度な取引先販売予測の概要をご覧ください。
Cindy は 2 つの販売予測ソリューションを比較してすべての関係者が違いを明確に理解できるようにしたいと考えています。
Cindy は次のレポートを作成して、Rayler Parts の経営陣にプレゼンテーションします。
比較条件 | 取引先販売予測の制限 | 高度な取引先販売予測の優位性 |
---|---|---|
モジュール式の販売予測 | 組織全体で同じ販売予測設定が使用されます。さまざまな取引先のセットに対して複数セットの販売予測を作成できません。 |
|
複雑な計算 | 数式は商談、販売計画、注文の項目のみに基づきます。これらのオブジェクトのデータを販売予測数式に追加する前に変換する方法はありません。計算プロセスのスケジュールやオーケストレーションの方法はありません。 |
|
ユーザー定義のディメンション | 販売予測は、取引先-商品-期間レベルの粒度でのみサポートされます。 |
|
販売予測プロセス | 販売予測プロセス (生成、再生成、ロールオーバー、再計算など) は、システム管理者が設定した会計年度と組織レベルのデフォルトによって決まります。取引先のセットまたはさまざまな期間に対してパラメーターを設定することはできません。 |
|
販売予測期間 | 計算頻度の値とロールオーバー頻度の値は組織のすべての取引先に適用されます。 |
|
基準と数式 | 承認、共有セット、リストビューなどの標準のプラットフォーム機能は、取引先販売予測では機能しません。 |
|
コラボレーション | どの販売予測基準を調整できるかをシステム管理者が指定することはできません。また、調整期間は組織のすべての取引先のすべての関係者で同じです。 |
|
ユーザーエクスペリエンス | 取引先販売予測は商品でのみ絞り込むことができます。カスタムビジネスロジックやユーザープロファイルに基づいて販売予測レコードをリストビューにグループ化することはできません。 |
|
このレポートはすばらしく、Badger Parts の高度な販売予測要件にとって高度な取引先販売予測が最適な選択肢と考えられるという点について経営陣の同意を得ることができました。
高度な販売予測を始める
Cindy は Salesforce の営業担当に、高度な取引先販売予測を Rayler Parts 組織に追加するように依頼します。高度な取引先販売予測には「データパイプライン」権限が付属するため、データ処理エンジン (DPE) 定義の作成と実行ができます。DPE 定義を使用すると、データの絞り込み、結合、追加、集計や、変換したデータを任意のオブジェクトに書き戻すことができます。いくつかの定義済み DPE 定義も高度な取引先販売予測に付属します。これはいい話です! Cindy は必要に応じてデータパイプラインの追加処理機能を購入できます。
次に、Cindy は Rayler Parts 組織で高度な取引先販売予測とデータパイプラインを有効化する必要があります。
このモジュールでは、受講者が Manufacturing Cloud システム管理者であり、高度な取引先販売予測を設定するための適切な権限を有していると想定しています。ただし、Manufacturing Cloud の管理者でなくても問題ありません。このまま読み進み、本番組織でシステム管理者が手順をどのように実行するかを学んでください。Trailhead Playground で次の手順を実行しないでください。Trailhead Playground では、高度な取引先販売予測機能を使用できません。
- をクリックし、[設定] を選択します。
- [クイック検索] ボックスに
Manufacturing
と入力し、[Manufacturing] を選択します。 - [機能設定] の下で [高度な取引先販売予測] をクリックして、この機能を有効化します。
- [クイック検索] ボックスに
データパイプライン
と入力し、[データパイプライン] を選択してから [使用開始] を選択します。 -
[データパイプライン] を有効にします。
次に Cindy は必要な権限セットを自分自身に割り当てます。手順は次のとおりです。
-
をクリックし、[クイック検索] ボックスに
権限セット
と入力し、[権限セット] を選択します。 - [高度な製造取引先販売予測] 権限セットリンクをクリックします。
- [割り当ての管理] を選択します。
- この権限セットが割り当てられているすべてのユーザーのリストが表示されます。ユーザーを追加するには、[割り当てを追加] をクリックします。
- 必要なユーザーを選択して [割り当て] をクリックします。
- [データパイプラインベースユーザー] 権限セットに対して、ステップ 2 ~ 5 を繰り返します。
以下は、高度な取引先販売予測に付属する定義済みデータ処理エンジンテンプレートです。
- 取引先販売予測を生成
- 取引先販売予測を再生成
- 取引先販売予測をロールオーバー
- 取引先販売予測を再計算
テンプレートをコピーしてカスタマイズし、独自の計算ロジックを定義できます。たとえば、地域別の取引先販売予測を生成する場合、地域ディメンションのデータソースノードを追加して地域オブジェクトからデータを取得します。ある取引先のセットに対してのみ販売予測を再生成する場合はどうすればよいでしょうか? 関連する取引先 ID のみを入力変数として追加し、「取引先販売予測を再生成」定義を実行します。数式を作成して確度別に商談を含め、状況別に販売計画を絞り込むこともできます。
データ処理エンジンを使用したデータ変換についての詳細は、「Data Processing Engine」(データ処理エンジン) を参照してください。
もうひとつ、Cindy はバッチ管理ジョブを使用して販売予測レコードを一括処理することもできます。販売予測数式が複数の取引先販売予測に適用されると、バッチ管理ジョブでレコードが 200 レコードずつのバッチに分割されて順次処理されます。システム管理者はフローを使用してこれらのジョブを自動化し、スケジュールできます。詳細は、「Batch Management」(バッチ管理) を参照してください。