カスタマイズ計画を決定する

学習の目的

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

• データ処理エンジン定義の各種ノードの概要を説明する。
• データ処理エンジン定義をカスタマイズするための前提条件を挙げる。

ノードを考え、ロジックを考え、設計を考える

Cindy は、データ処理エンジン (DPE) 定義には何百もの相互にリンクされたノードがあり、非常に手ごわそうに見えることを知っています。一方で彼女は、ノードがどのように動作するかを知ることが重要であるとも気付いています。各ノードは変換条件であり、Cindy は彼女の新しい要件のためにどのような変換を追加する必要があるかを知っている必要があります。彼女は要件を書き留め、定義の視覚表現を作成します。各要件は DPE 定義のノード種別に幅広く対応付けることができます。各ノード種別の例は次のとおりです。

データソース

Rayler Parts は見積と見積品目を使用して新しいビジネスを管理しています。そこで、見積の日付、金額、数量、取引の性質などの詳細を取得することで販売予測を計算したいと考えています。そのために Cindy は、見積と見積品目をデータソースとして定義に追加する必要があります。

数式

Rayler Parts は販売計画数量を予測数量の評価指標の 1 つとして使用する前に、各期間の販売計画数量に 2 を掛けたいと考えています。そのために Cindy は定義に数式を追加する必要があります。

検索条件

Rayler Parts は計算に特定の価格表を使用する販売計画のみを考慮したいと考えています。そのために Cindy は定義に検索条件を追加する必要があります。

合流

Rayler Parts は商談に基づいて取引先販売予測を作成したいと考えています。この計算には、商談レコードの取引先 ID 項目と、販売予測が更新される高度な取引先販売予測結果レコードの取引先 ID 項目が一致することを特定する方法が必要です。そのために Cindy は結合を追加して、2 つのデータソースオブジェクトからの類似する項目を対応付ける必要があります。

グループと集計

Rayler Parts は一定期間のすべての商談の合計数量を 1 つの数値に集計したいと考えています。さらに、このデータは商談に関連付けられた商品別にグループ化する必要があります。そのために Cindy はグループ項目として [商品] を選択し、グループと集計ノードで種別が [合計] の [合計数量] の集計項目を作成する必要があります。

変数

Rayler Parts は $200 を超える注文のみを販売予測計算に含めたいと考えています。そのために Cindy は数値型の入力変数を定義し、必要な検索条件ノードや数式ノードで使用できます。 

書き戻し

Rayler Parts は計算されて DPE から取得された最終的な商談収益が [Probable Revenue (予定収益)] というカスタム項目に更新されるようにしたいと考えています。そのために Cindy は書き戻しノードで新しい対応付けを作成して、計算済みの商談収益が保存される項目をカスタム項目 [Probable Revenue (予定収益)] に対応付ける必要があります。

Cindy はノード種別を確かに理解できたと感じています。ただし、データ処理エンジン定義に具体的な変更を加える前に、確認すべきことがいくつかあります。 

DPE カスタマイズの前提条件を特定する

DPE 定義のカスタマイズは販売予測要件の最初のステップではありません。DPE 定義を実際に操作する前に、システム管理者が実行しなければならないステップが多数あります。Cindy は次のシンプルなチェックリストに従うことができます。

オブジェクトと項目の要件

• データソースとして追加された新しいオブジェクトがある場合、そのオブジェクトに対してすべての設定を有効にします。たとえば、Rayler Parts がデータソースとして見積を使用したい場合、[設定] で [見積] を有効にする必要があります。
• [Analytics Cloud Integration User] プロファイルを持つユーザーに、データソースノードで選択されたすべてのオブジェクトと項目に対する「参照」アクセス権が必要です。
• DPE 定義で使用されるすべての項目で項目レベルセキュリティがユーザーに正しく割り当てられていることを確認します。
• 書き戻しノードの対象オブジェクトと項目を定義し、関連項目の対応付けを定義するには、書き戻しノードでどのユーザーが書き戻しユーザーになるかを指定します。このユーザーに、すべての対象オブジェクト、項目、関連オブジェクトに対する「作成」アクセス権が必要です。

販売予測評価指標とディメンションの要件

• 新しい販売予測ディメンションが必要な場合、高度な取引先販売予測結果オブジェクトにそのディメンションを表すカスタム項目を作成します。次に、新しい項目を販売予測セットの販売予測ディメンションとして追加します。
• ディメンション項目は常に参照です。たとえば、Cindy はカテゴリオブジェクトへの参照関係を持つカスタム項目 [Product Category (商品カテゴリ)] を作成できます。
• 新しい販売予測評価指標が必要な場合、高度な取引先販売予測結果オブジェクトにその基準を表すカスタム項目を作成します。次に、新しいカスタム項目を販売予測セットの販売予測基準として追加します。
• 数量項目であるか収益項目であるかに応じて、カスタム項目のデータ型は数値または通貨にできます。たとえば、Cindy が販売予測結果オブジェクトにカスタム項目 [Sales Agreement Planned Revenue (販売計画の計画収益)] を作成する場合、データ型は通貨です。

その他の要件

• 基準を DPE 定義から派生させる場合は、販売予測セットの販売予測基準の計算方法として [Batch Process (一括処理)] を選択します。
• 最終的な [予測数量] と [予測収益] を数式によって計算する場合は、販売予測数式を作成します。基礎となる評価指標は DPE を介して計算されますが、最終的な値には数式が適用されます。
• 高度な取引先販売予測結果オブジェクトの項目として標準で含まれる高度な取引先販売予測表示から既存の基準を削除するには、次の方法を使用できます。
  • 項目レベルセキュリティを使用して値を非表示にする。
  • 昨年の注文数量と注文収益の項目のないカスタム結果テーブルを使用する。
  • データ処理エンジン定義のすべてのノードをトラバースして、属性が書き戻されていないことを確認する。

項目レベルセキュリティを使用する最初の方法では、取引先マネージャーには基準の値が表示されませんが、計算は実行され、データは書き戻されます。書き戻すデータが多いほど、組織内で使用するストレージが多くなります。そのため、必要ない基準の値は書き戻さないことをお勧めします。

• 事前定義された DPE 定義を詳しく調べます。各ノードが互いにどのようにつながっているかを理解します。各ノード内でハイパーリンク {1} 参照先ノード をクリックすると、構造内の次のノードが表示されます。定義内にすでに含まれている内容をしっかりと理解することで、加える変更の基礎を築くことができます。

準備完了

Cindy は高度な取引先販売予測の基礎と、データ処理エンジンが販売予測計算でどのような重要な役割を果たしているかについて理解しました。この知識をもとに、Rayler Parts の独自のビジネス要件を満たせるように、販売予測セットを設定し、定義をカスタマイズします。Manufacturing Cloud の販売予測の概念を理解できたところで、今度はこの知識を実務に活用していきます。