Oracle Fusion Applicationsセールス・ガイド 11g リリース1（11.1.4） B69964-01

目次

前へ

次へ

6 引合および商談の追跡

この章の内容は次のとおりです。

引合のフォロー・アップ

商談と引合の評価

商談の管理

商談割当の管理

商談の評価に関するよくある質問

販売収益の管理

商談パートナの管理

引合のフォロー・アップ

引合コンポーネントの仕組み

引合は、商談に変換されて終了するか、営業商談に変換される可能性がない場合は取り下げられて終了します。引合のライフサイクルには、最初に引合を取得し、次にスコアリングやランキング・プロセスを使用して販売契約のために引合の優先順位を付ける自動プロセスが含まれます。次に、引合は適切な営業リソースに配布され、引合の資格取得、フォロー・アップおよび変換が行われます。

引合のライフサイクル

引合はライフサイクルを進行する間、モニターされ、必要に応じて再割当されます。さらに、引合品質が継続してレビューおよび調整されます。マーケティング部門と営業部門は引合の所有権を共有し、引合ステータスに基づいて、引合の担当がマーケティング部門と営業部門の間でシフトします。次の各項で、引合のライフサイクルについて説明します。

• 引合生成

• 引合資格取得

• 引合配布

• 引合評価

• 引合変換

引合生成

引合は、次のような多様なソースから生成および取得されます。

• キャンペーン応答

• テレマーケティングによって処理するキャンペーン・ステージ

• サード・パーティの引合ソース

• 販売予測アプリケーションによる新規引合の作成

マーケティング引合の生成活動は、フレキシブルな引合インポート、顧客や担当者の作成、および重複除去によって最適化できます。たとえば、引合インポート・プロセスでは、引合が新規顧客を示すか、または既存の顧客を示すかがチェックされます。新規顧客の場合は、引合のデータを作成する必要があります。引合が既存の顧客の場合は、引合インポート・プロセスの中で、顧客と引合情報が重複していないことがチェックされます。

引合資格取得

マーケティング部門は、引合資格取得プロセスを使用して、適格引合のみを営業に渡します。通常、引合は「ホット」、「ウォーム」または「クール」にランク付けされます。さらに、会社固有の標準質問を使用して引合の資格を取得し、引合をスコアリングします。通常、引合スコアは1から100の範囲内の数値で、高いスコアは高い品質を表します。

古い引合を作成することはお薦めできません。引合資格取得のための標準条件を使用することによって、品質の高い引合が営業担当に渡され、引合から商談への変換率を最大限にできます。たとえば、組織では条件とプロセスを使用して、引合を進行させるか取り下げるかを30日以内に決定するとします。引合期間が30日を超えてランクがAまたはBの場合、マーケティングでは内部テレマーケティング・グループがフォロー・アップできるように、その引合を再割当します。引合の資格を取得できない場合、または引合を収益商談に進めることができない場合、却下された引合は手動で再割当するか、取り下げることができます。

引合配布

引合が資格取得から実際の潜在的見込み客に進むと、割当マネージャは式ベースのルールを使用して、1名以上の内部営業担当を各引合に関連付けます。引合が既存の販売アカウントに関連付けられている場合、割当マネージャはテリトリ定義を使用して、内部テリトリ（通常は1つ）を各引合に関連付けます。引合に新規に割り当てられた営業担当は、引合チームを使用して直接的に、または引合に関連付けられたテリトリを使用して間接的に、引合レコードに関連付けることができます。これらの営業担当は、割り当てられた引合を引合作業領域で表示して更新したり、引合の受入処理を使用して引合の所有権を要求できます。

その他の割当済リソースは、引合を表示して更新できますが、所有者になることはできません。その後に引合の資格を取得すると、たとえば、所在地を追加して販売見込み客が販売アカウントに変わったときは、次回の自動割当サイクル時に割当マネージャが自動的に起動します。引合は、割当ロジックに基づいて、別のテリトリまたは営業リソースに再割当できます。割当済の営業担当が引合に対して数日間何も処理を行わない場合は、その引合を別の営業担当に手動で再割当できます。

引合評価

営業担当は、引合に関して受け取った情報の品質を評価する必要があります。顧客と接触するための十分な詳細情報があるかどうかを判断し、事前設定された評価テンプレートを使用して、引合が追跡する価値があるかどうかを評価します。さらに、評価テンプレートを使用すると、次の方法で引合の資格を取得できます。

• キャンペーン中に顧客と共有するコンテンツをレビューする

• キャンペーンのコンテキストで引合を構成する

• 顧客にすでに送られた情報を営業担当が把握していることを確認する

引合評価では、引合が営業で受け入れられる可能性を判断するために事前定義された質問を使用して、引合をさらに評価できます。たとえば、Mikeという名前の営業担当は、引合の品質を評価するために、マーケティングおよび営業で作成された一連の質問を顧客に対して尋ね始めます。質問をするたびにMikeが回答を記録すると、引合評価ツールによって、その回答が引合の評価スコアに自動的に割り当てられます。この通話の終了後に、Mikeは引合の評価スコアが高いことに気づきます。彼は、その顧客の直接の営業チームに引合を割り当てるように要求します。引合スコアが低い場合、Mikeはその引合を取り下げることができます。また、引合の資格取得が必要な場合、Mikeは後日にフォロー・アップできるように引合リストにその引合を残すことができます。引合は良好だが、潜在的収益商談が事前定義された金額（たとえば、25000ドル）より低い場合、Mikeは引合を商談に変換して自分で処理できます。

引合変換

引合のライフサイクルは、引合が収益商談に変換されたとき、または引合が取り下げられたときのいずれかで終了します。商談ステージに変換することにより、営業担当は営業サイクル内でアカウントを追跡できるようになります。営業担当は、引合に可能性があると判断すると、その引合を商談に変換します。営業パイプラインに従って商談を進めるために、担当者が設定され、会議やプレゼンテーションがスケジュールされます。進捗を追跡するために、担当者ノートが顧客対応として取得され、担当者および商談に関連付けられます。

引合がライフサイクルを進行する間、次の状況に基づいて引合を取り下げる決定を行います。

• 顧客および引合の詳細を確認できない場合

• 顧客が引合を追跡することに関心を示さなくなった場合

引合処理: 説明

引合は、引合処理を使用して管理します。

通常、引合処理は次のカテゴリにグループ化されます。

• 標準的な作成、編集、削除およびエクスポート機能

• 引合の優先順位付けを支援するためのランキング、スコアリングおよび資格取得処理

• 引合を追跡対象として適切なキューに入れるための受入、却下、再割当および取下げ処理

• 販売追求を継続し、引合を販売予測に含めるための商談への引合の変換

各処理を実行できるかどうかは、ロールに割り当てられた権限、引合営業チーム・メンバーとしてのアクセス・レベル、および引合の現在のステータスによって決まります。

引合処理

次の表では、引合に固有の引合処理について説明します。

引合ステータス: 説明

引合のステータスは主として、ユーザーが引合に対して処理を実行したり、引合資格取得活動が正常完了したときに決まります。

引合が引合クオリファイアまたは関連する営業ロールに割り当てられると、引合フォロー・アップ活動が開始されます。引合に対して特定の処理が実行されると、それに応じて引合のステータスが変わります。

引合ステータス

次の表では、引合のステータスについて説明します。

引合資格取得: 説明

引合の資格取得は、営業引合を結論に導くための最初の重要ステップです。引合は、引合資格取得プロセスの最後に、商談に変換可能な適格引合として分類でき、引合の購買関心が確認できない場合は取り下げることもできます。引合資格取得プロセスは、内部マーケティングまたは内部営業グループのいずれかが実行できます。

適格引合の構成は会社によって異なります。

基本引合資格取得

会社によっては、引合クオリファイアによって収集された基本引合資格取得データ（顧客予算のステータス、時間枠など）が、引合資格取得ステータス値をルールに基づいて決定するスケジュール済自動処理で考慮されます。

追加引合資格取得

他の会社では、引合クオリファイアまたは営業担当は、引合処理メニューを使用して引合を「適格」ステータスに手動で設定するかどうかを決定するために、引合資格取得質問表のスコアをファクタとして使用します。アプリケーション管理者は、質問表を「引合資格取得テンプレート」プロファイルに割り当てます。入力された回答は加重スコアリング・モデルを使用して評価され、ステータス・バーからフィードバックを即時に返すことができます。

引合の資格取得: 例

引合資格取得プロセスは、引合を結論に導くための最初の重要ステップです。引合は、このプロセスの最後に、営業に対して変換可能な適格引合として分類でき、引合の購買関心が確認できない場合は取り下げることもできます。引合資格取得プロセスは、内部マーケティング、内部営業グループ、または外部サード・パーティのいずれかが実行できます。

引合の生成と同時に、引合品質が評価されます。新規に作成された引合の引合品質は、主に、その引合の顧客担当者の特性、生成される基になった応答のタイプ、およびキャンペーンの特徴に基づいて判断されます。引合がさらに拡充されると（通常は、資格取得前のテレマーケティング活動による）、引合品質は、追加された資格取得データ（プロジェクトの顧客ニーズ、緊急度、時間枠など）、および顧客がこのプロジェクトの予算を確保したかどうかに基づいて再評価されます。次のシナリオでは、いくつかの引合資格取得プロセスについて説明します。

ルール・ベースの引合資格取得

ルール・ベースの引合資格取得プロセスでは、資格取得ルールで肯定的な回答と評価された場合、「引合ステータス」属性の値を「適格」に設定する必要があります。たとえば、次のルールを考えてみます。

予算ステータスが「承認済」、時間枠が3か月、決定者が識別済、応答タイプが参加済イベント、これらすべてが該当する場合、ルールはパスします。該当しない場合、ルールは失敗します。

このルールがTRUEと評価された場合、「引合ステータス」の値は「適格」に設定する必要があります。

内部マーケティングの資格取得

内部引合クオリファイアまたは内部営業担当は、電話による会話によって引合に関する資格取得データを収集します。資格取得テンプレートを使用して、類似する引合に対して一貫性のある特定の資格取得条件を定義します。これらの資格取得の質問は、特定の製品、産業、および引合のソースに応じて調整されます。

引合ステータスを「適格」に更新する前に、引合に有効なプライマリ製品を関連付ける必要があります。ユーザーは、複数の引合を選択して資格取得処理を選択できます。引合資格取得の要件を満たす引合が処理されます。

引合管理ユーザー・インタフェースを使用して引合資格データを収集する際、引合クオリファイアまたは営業担当は引合を「適格」ステータスに手動で設定するかどうかを決定します。会社によっては、引合クオリファイアによって収集された引合資格取得データが、引合スコアまたは引合ランクを計算して営業チーム・テリトリスを割り当てるスケジュール済自動処理で考慮されます。このような会社の場合は、引合スコアが特定のしきい値に達すると引合が「適格」ステータスに移行する簡単なルールで十分です。

引合の基本属性によって製品の購買に関心があることが示されると、引合は資格を取得できます。たとえば、次のような基本属性を含めることができます。

• 製品イベントに参加した担当者

• 予算が承認済

• 購買の時間枠が1年未満

追加資格取得では、資格取得テンプレートにある質問を使用して、同じページで回答を入力できます。引合の資格取得に必要なほとんどのデータは「引合資格取得」タブで使用でき、サポート・データはコンテキスト領域で簡単に参照できます。

内部営業グループの資格取得

引合は、新規顧客を作成したり、すでに存在する引合を使用し、販売予測システムなど多様なソースから生成および取得されます。販売予測システムで生成された引合を営業担当が受け入れると、営業担当はその引合の品質および受け取った情報を評価できます。顧客と接触するための十分な詳細情報があるかどうかを判断し、事前設定された評価テンプレートを使用して、引合が追跡する価値があるかどうかを評価します。営業担当は、引合に可能性があり、適格としてマークできると評価すると、その引合を商談に変換します。営業パイプラインに従って商談を進めるために、担当者が設定され、会議やプレゼンテーションがスケジュールされます。

外部のサード・パーティの資格取得

会社は、最近90日以内に新車を購入した担当者のリストを入手したとします。そこで、テレマーケティング会社に依頼して各担当者に電話をかけ、自社の自動セキュリティ製品に関心があるかどうかを判断します。サード・パーティのテレマーケティング担当者は、毎週ファイルを提出します。引合インポート機能、および割当マネージャを使用して構成した資格取得ルールを使用して、テレマーケティング担当者の活動結果である顧客対応を引合としてインポートします。サード・パーティの資格取得活動は定期的に実施され、資格取得データが提供されます。マーケティング運用マネージャは、拡充された引合データが引合管理システムにインポートされると同時にルール・ベースの資格取得プロセスが実行されるようにスケジュールします。ルール評価が成功すると、その結果によって引合ステータスが「適格」に設定されます。

引合所有権および営業チーム・リソース: 説明

通常、市場は、顧客と見込み客で構成されるテリトリに編成されます。マーケティングは営業と密接に協調して、マーケティング活動を開始して引合を生成し、営業パイプラインの強さを維持します。

引合にアクセスするリソースには、次のような様々なロールがあります。

• 運用は、引合を取得して販売契約のために優先順位付けし、適切な営業チームまたはテリトリ・チーム・リソースに配布する自動プロセスをサポートします。

• マーケティングおよび引合クオリファイア・ロールには、引合のモニターと再割当、引合品質の継続的なレビューと調整が含まれます。

• 営業チームおよびテリトリ・チームは、引合資格取得を有効にし、フォロー・アップ引合活動を実行して、引合を商談に変換します。

この項の内容は次のとおりです。

• 引合、営業およびテリトリ・リソース

• マーケティングおよび営業リソースへの引合の割当

• 営業リソース・ロール

• リソースの権限とアクセス・レベル

引合、営業およびテリトリ・リソース

営業リソースは、複数のフレキシブルなチームに編成され、営業テリトリに関連付けられます。次に、これらの営業テリトリは、営業プロセスを実行するために顧客、引合および商談に割り当てられます。引合フォロー・アップ・プロセスには、主に引合資格取得ステージでアクティブな個々の営業リソースで構成される引合チームが含まれます。引合は適切な営業チームに割り当てられ、その引合に対してテリトリ・チームが作成されます。テリトリ・チームに割り当てられたすべての営業リソースは、引合を表示してフォロー・アップできます。

マーケティングおよび営業リソースへの引合の割当

適格引合は、営業テリトリに基づいて営業チームに割り当てられます。不適格な引合は、手動で、または割当マネージャで定義されたルールに基づいて、個々の引合クオリファイアに割り当てられます。

営業リソース・ロール

営業リソースは次の活動を実行します。

• 営業販促資料、マーケティング・コンテンツ、顧客担当者の顧客対応、および参照によって拡充された品質の高い引合をレビューします。

• カスタマイズされた評価テンプレートを使用し、引合の資格を取得して引合品質を評価します。

• リソース・ピッカーを使用し、チームに追加するリソースを手動で選択します。

  摘要を入力し、営業チームでのリソースのロールを示します。各引合には多数の営業チーム・メンバーがアクセスでき、各チーム・メンバーは内部リソース（営業担当）または外部リソース（チャネル・パートナ営業担当）のいずれかとして識別されます。各営業チーム・メンバーを特定のリソース・ロールに関連付けて、メンバーが引合に対して実行可能な操作を示すことができます。

• 引合が営業サイクルを進行するのに従って、さらに担当者および製品を追加します。

リソースの権限とアクセス・レベル

引合には、次の3つのアクセス・レベルがあります。

引合に所有者が設定されていない場合は、その引合を受け入れて、自分を引合所有者にする必要があります。引合所有者を変更できるのは、引合所有者、および引合所有者の管理チェーンのみです。

テリトリ・チーム・メンバーは、テリトリのアクセス・レベルを継承します。引合に割り当てられた営業テリトリのすべてのメンバーには、その引合へのフル・アクセス権があります。また、引合に割り当てられた全営業テリトリの上位テリトリの所有者にも、その引合へのフル・アクセス権があります。

営業チームの例

引合営業チームは、割り当てられたテリトリ、および個々のチーム・メンバーで構成されます。次の例では、引合営業チームが使用できるいくつかの機能について説明します。

• 引合テリトリ・チームへのテリトリの割当の自動化

• 営業チームへの個別営業担当の割当の自動化

• 営業チームへのアドホック・メンバーの追加

• リソースに基づいたアクセス権限の更新

• 引合所有者の変更

引合テリトリ・チームへのテリトリの割当の自動化

XYZ社に、西部リージョンの複数の州で大型風力発電機を50ユニット購入、という引合があるとします。西部リージョンの営業担当をその引合に割り当てるために、管理者は、割当マネージャを設定して、引合テリトリ・チームに「西部リージョン」テリトリを自動的に追加しました。

営業部門では、営業テリトリに基づいて営業担当を配置します。営業リソースは、複数のフレキシブルなチームに編成され、営業テリトリに関連付けられます。次に、これらの営業テリトリは、営業プロセスを実行するために顧客、引合および商談に割り当てられます。テリトリとは、一連の販売アカウント全体に対する営業担当の職責の範囲です。販売アカウントを作成すると、その販売アカウントにテリトリが割り当てられます。引合営業チームは、割り当てられたテリトリと、アドホック・ベースで手動で割り当てられた特別なリソースで構成されます。

営業チームへの個別営業担当の割当の自動化

XYX社の引合営業チームは、引合にサポート人員を追加するとします。通常、サポート人員は営業テリトリに含まれません。引合製品と特定のサポート・チーム・メンバーを照合するルールに基づいて、サポート・チーム・メンバーを個別リソースとして割り当てるルール・セット・グループがあります。

営業チームへのアドホック・メンバーの追加

通常、営業チーム・リソースは、構成済の割当ルールに基づいて引当に自動的に割り当てられます。次のシナリオでは、引合を支援するために追加チーム・メンバーを手動で追加する例を示します。

XYZ社の引合へのフル・アクセス権がある引合所有者は、引合の追跡を支援するために、自社の契約エキスパートを1名、チームに追加します。引合所有者はリソース・ピッカーを手動で起動して、チームに追加するアドホック・リソースを選択します。

保険契約に関する引合の追跡中に、顧客担当者が保険項目の独特で複雑な組合せを要求したため、社内のエキスパートによるレビューが必要になりました。引合所有者は、製品とサービスの有効な組合せで引合を更新できるように、フル・アクセス権がある引合にエキスパート・リソースを追加し、必要に応じて、さらにチームに複数のチーム・メンバーを追加します。

最後の例として、営業担当は、国外に製品を輸出する必要がある引合を追跡しています。営業担当は、製品を輸出する際に法的問題がないことを確認する必要があるため、顧客に再度接触する前に、詳細をレビューするために自社の弁護士メンバーから1名を引合に追加します。

リソースに基づいたアクセス権限の更新

リソースがルール・ベースの割当を使用して初めて引合営業チームに追加されると、プロファイル・オプション設定によりメンバーのデフォルト・アクセス・レベルが決まります。新規に追加されたチーム・メンバーの管理階層内のリソースには、チーム・メンバーと同じ営業引合へのアクセス・レベルが設定されます。

引合に割り当てられた営業テリトリのすべてのメンバーには、その引合へのフル・アクセス権があります。また、引合に割り当てられた全営業テリトリの上位テリトリの所有者にも、その引合へのフル・アクセス権があります。

引合所有者の変更

引合所有者を変更できるのは、引合所有者、および引合所有者の管理階層内のリソースのみです。

引合評価: 説明

引合評価テンプレートを使用すると、引合全体で同一の評価を実施し、営業サイクルに従って引合が進行するように営業リソースをガイドできます。

引合評価を使用すると、次のことができます。

• 引合評価テンプレートの定義

• タスク・テンプレートと評価テンプレートの関連付け

• 引合の評価

引合評価テンプレートの定義

評価テンプレートは、産業のベスト・プラクティスを表す評価質問、販売方式、またはこれらの組合せを使用して定義できます。質問に対して様々な応答を入力すると、評価の進捗バーには、評価の定義に基づいて評価とフィードバックが即時に表示されます。また、評価テンプレートを使用して、引合フォロー・アップ手順を標準化することもできます。引合評価テンプレートを使用すると、ビジネス・ユニット内のすべての引合に対して一貫性のある予測可能な評価を行うことができます。

タスク・テンプレートと評価テンプレートの関連付け

評価に対する追加コンポーネントには、評価結果に基づいて追加タスクを推奨する機能があります。タスク・テンプレートが評価に関連付けられている場合は、評価の全体スコアに基づいて推奨済タスク・テンプレートのリストが表示されます。適用すると、協調した引合フォロー・アップ活動をサポートするために、タスクが引合に追加されます。

引合の評価

通常、引合評価は、引合が資格取得後に継続して進行する引合フォロー・アップ活動中に実施されます。管理者は、「引合の編集」ユーザー・インタフェースに「評価」タブが表示されるように、「引合評価使用可能」プロファイル・オプションを設定する必要があります。有効な場合は、引合の評価を支援するために収集された事前定義の質問と回答のセットを表示し、引合の「評価」タブから次の処理を実行できます。

• 新規評価の実行

• 評価の編集

• 未完了評価の削除

• 再評価

• 履歴パフォーマンスの表示

引合のフォロー・アップに関するよくある質問

応答、引合および商談の違いは何ですか。

次の表では、応答、引合および商談の主な違いについて説明します。

ディール・サイズが変更されたのはなぜですか。

ディール・サイズは、引合に対して入力された製品によって自動的に決まります。製品を追加または削除すると、ディール・サイズは再計算されます。計算された金額は、すべての製品を入力した後で上書きできます。たとえば、引合が値引に適格な場合は、ディール・サイズ合計を手動で変更して値引を適用できます。ただし、ディール・サイズを手動で調整した後に引合から製品を追加または削除すると、アプリケーションによってディール・サイズ合計が上書きされるため、手動による変更を再適用する必要があります。

自動的に割り当てられた引合ランクを手動で変更するとどうなりますか。

引合ランクによって、フォロー・アップする引合を選択する際の優先度が提示されます。引合が作成されると、割当マネージャは、ランキング・ルールに基づいて引合ランクを最初に計算します。別の引合ランク・コードまたは値をユーザー・インタフェースのリストから選択できますが、引合がさらに処理されると、拡充された引合データに基づいて別のランクが割り当てられたり、ルールによって引合が元のランクに戻される場合があります。

引合担当者はどのようにして自分の営業キャンペーンに追加しますか。

引合の「概要」リストから、対象の引合を選択します。引合詳細から「担当者」タブをクリックします。営業キャンペーンに追加する担当者を選択します。「処理」メニューから「営業キャンペーンに追加」を選択し、保存済キャンペーンを表示してキャンペーンを選択します。担当者には、営業キャンペーンの開始時、またはスケジュールされた次回の郵送時（営業キャンペーンを繰り返しスケジュールしている場合）に通知されます。

引合資格取得と引合評価の違いは何ですか。

引合資格取得によって、引合に予算がありプロジェクト・タイムラインが定義されているかどうかが判断され、購買決定権がある人物が特定されているかどうかが示されます。会社固有の標準質問、および関連するスコアリング・メカニズムを使用すると、引合の資格を取得するために重要な追加データを取得するのに役立ちます。通常、ニーズおよび購買関心が確認されると、引合は適格とみなされます。

引合評価は引合フォロー・アップ・プロセスで役立ちます。このプロセスでは、事前設定された評価テンプレートを使用して、営業担当が引合品質や引合変換の可能性を継続して評価します。営業担当は、「評価」タブから、新規評価の実施、完了した評価の表示、および質問に対する応答の表示を行うことができます。評価テンプレートで提供されるメカニズムによって、営業担当は引合を分析し、引合の全体の評価スコアやフィードバックに基づいて適切な次のステップを提示できます。

引合に関する顧客対応はいつ表示されますか。

顧客対応は、その顧客対応で引合が関連オブジェクトとして識別されると、引合の「顧客対応」タブに表示されます。「顧客対応」タブには、すべての顧客対応も表示されます。引合に顧客対応が作成されると、引合参照タイプおよび参照が関連オブジェクトとして自動的に設定されます。ただし、追加の関連オブジェクトを識別することもできます。たとえば、引合に顧客対応を作成し、別の引合と商談を同じ顧客対応に追加できます。「顧客対応」タブには、該当する引合に関連付けることができないすべての顧客対応も表示されます。特定の顧客に関する全オブジェクト・タイプの顧客対応は、顧客センターに表示できます。

引合に関する顧客参照が表示されるのはなぜですか。

顧客参照は、顧客産業および関連する引合製品、または特定の引合に関連する製品グループに基づいています。たとえば、顧客が類似する製品またはサービスを購入したことがある場合は、引合に関する顧客参照が表示されます。営業担当はこの参照詳細を利用して、効率的な引合フォロー・アップを行うことができます。

引合ユーザー・インタフェースは、営業担当の生産性を向上させ、できるだけ少ないクリック回数で関連する引合情報に簡単にアクセスできるように設計されています。各引合に関連するサポート・データはコンテキスト領域に表示されるため、簡単に参照できます。引合コンテキスト領域には、参照、引合顧客のすべてのオープン引合とオープン商談、およびサポートする販促資料が表示されます。この情報によって、引合営業チームは効率的な引合フォロー・アップを容易に行うことができます。

引合を商談に変換するとどうなりますか。

資格を取得し、販売契約への準備が整った引合は商談に変換します。引合を商談に変換するには、その引合を販売アカウントとプライマリ製品に関連付ける必要があります。変換が正常に完了すると、新規に作成された商談をOracle Fusion Opportunity Managementでレビューできます。レビュー時には、商談収益明細項目として追跡するいくつかの引合製品明細のみを選択して保持することが必要になる場合があります。変換プロセスではすべての引合明細から収益明細が自動的に作成されるため、「商談詳細」ページから不要な収益明細を削除できます。

引合を商談に変換するときは、会社の設定条件に応じて次のルールを適用できます。

• 引合を変換した個人は、商談のプライマリ営業チーム・メンバーになります。

• 商談では、元の引合への参照が保持されます。

• 関連する引合チーム・メンバーは、同じプライマリ・チーム・メンバーとともにコピーされます。

• 新規に作成された商談は、適切な営業テリトリに割り当てられます。

商談管理領域から引合に関連付けられた商談は、「引合 - 商談」タブにリストで表示されます。

1つの引合から複数の商談を作成できますか。

はい。同じ引合を別の商談に変換して、不要な収益明細を削除できます。たとえば、引合の変換によって作成された商談をレビューするときは、商談収益明細項目として追跡するいくつかの引合製品明細のみを選択して保持することが必要になる場合があります。変換プロセスではすべての引合明細から収益明細が自動的に作成されるため、「商談詳細」ページから不要な収益明細を削除できます。後続のステージでは、引合を商談に再度変換し、削除対象の収益明細のみを新規の商談に保持することによって、削除対象の引合収益明細から別の商談を作成できます。

変換した引合を商談のリストに表示できないのはなぜですか。

変換後に引合が商談のリストに表示されない場合は、その商談が別のテリトリに割り当てられたことを意味します。

商談と引合の評価

評価テンプレート: 考慮する点

評価テンプレートを使用すると、引合や商談などのビジネス・オブジェクトの状態を分析し、その診断に基づいて適切な次のステップを提示できます。評価テンプレートを最適に計画して作成するには、次の点を考慮する必要があります。

• 評価

• 質問、質問グループおよび質問の重み

• 返答およびスコア

• 関連付けられたタスク・テンプレート

評価

評価は「優秀」などの資格取得テキストです。評価テンプレートには、「優秀」、「平均」および「悪い」の3つの評価が用意されています。評価は、数値スコア以外に、評価の結果から資格を取得するためのメトリックとして使用されます。評価は、評価テンプレート作成プロセスの最初に作成されます。後で、テンプレート内の質問に対する可能な返答に適用され、各評価がスコアに関連付けられます。評価を発行すると、完了した評価のスコアに基づいて適切なフィードバックが表示されます。評価を設定して可能な返答に適用するときは、評価とその評価に関連付けられたフィードバック・テキストが、ビジネス・オブジェクトの全体評価状態の一部として最終的に表示されることに留意することが重要です。

質問、質問グループおよび質問の重み

質問は評価テンプレートの主要コンポーネントです。質問は、ビジネス・オブジェクトの状態を体系的に判断するのに役立つように記述され、質問グループと呼ばれる論理的なコレクションにグループ化されます。テンプレート内の各質問には質問の重みが割り当てられます。質問の重みは比率で表され、テンプレート内での質問の相対的な重要度を示します。評価テンプレートを使用して評価を実行するときは、質問に対して設定された返答の正規化スコアが質問の重みで乗算され、その質問の加重スコアが生成されます。質問、質問グループおよび質問の重みを設定するときは、組織内の特定のビジネス・オブジェクト（引合、商談など）の状態を判断するファクタを慎重に分析することが重要です。これらのファクタを使用して質問グループを作成し、たとえば、分析に従って重み付けをした3つから5つの質問を各グループに記述します。1つの質問グループに含めることができる質問の数に制限はありませんが、各質問グループには少なくとも1つの質問が必要です。

返答およびスコア

返答は、テンプレート内の質問に添付されています。自由書式専用の質問以外は、各質問に少なくとも2つの返答が必要です。複数の返答を同じ評価に関連付けることはできますが、自由書式専用の質問以外は、各質問に対するすべての返答の間で少なくとも2つの評価が存在する必要があります。たとえば、評価が「優秀」、「平均」および「悪い」の場合は、これらの評価の少なくとも1つ（例: 「平均」）に対応する返答を各質問に2つ含めることができます。少なくとも2つの評価（例: 「優秀」と「平均」）をカバーするための返答が必要です。質問に対する各返答にスコアを割り当てると、アプリケーションでは標準スコアリング・スケールに基づいてスコアが正規化されます。評価テンプレートを使用して評価を実行するときは、質問に対して設定された返答の正規化スコアが質問の重みで乗算され、その返答の加重スコアが生成されます。質問に返答を追加するときは、各返答に割り当てるスコアと評価が相互に関連するようにしてください。つまり、返答に高いスコアを割り当てる場合は評価も高くし、スコアと評価の間に適切な量的関係が維持されるようにします。また、テンプレート内の1つ以上の質問に対しては自由書式の応答を許可できますが、自由書式の応答はスコアリングされません。

関連付けられたタスク・テンプレート

タスク・テンプレートは、関連する活動のグループを生成するための指示です。タスク・テンプレートは、ビジネス・オブジェクトに対する評価の後に実行するタスクを提示するために、評価テンプレートに関連付けることができます。タスク・テンプレートを評価テンプレートに関連付けるときは、各タスク・テンプレートにスコア範囲を指定できるため、テンプレートを使用する評価の合計スコアに基づいて1つ以上のタスク・テンプレートがフォロー・アップ活動として提示されます。タスク・テンプレートを評価テンプレートに関連付けるには、そのタスク・テンプレートが評価テンプレートに割り当てられているタイプと同じビジネス・オブジェクト・タイプに割り当てられ、サブタイプが「評価」である必要があります。タスク・テンプレートを評価テンプレートに関連付ける前に、タスク・テンプレートが正しく設定されていることを確認してください。

評価テンプレートのスコア範囲: 計算方法

評価テンプレートのスコア範囲は、質問の重み、およびテンプレート内のすべての質問に対する可能な返答に割り当てられた評価とスコアを使用して計算されます。この項では、各スコア範囲に適用するフィードバック・テキストに関して最適な決定ができるように、スコア範囲が計算される時期、および計算で使用されるコンポーネントについて説明します。スコア範囲については、自動計算以外に、管理UIで手動で調整する方法もあります。

スコア範囲に影響を与える設定

アプリケーションによって評価テンプレートのスコア範囲を計算するには、次の操作が必要です。

• テンプレートのすべての質問に重みを適用します。

• 評価を構成してテンプレートのすべての質問に対する可能な返答に適用します。

• テンプレートのすべての質問に対する可能な返答ごとにスコアを適用します。

スコア範囲の計算方法

評価テンプレート内の各評価のスコア範囲の決定には、各質問に対する返答の最低と最高の加重スコアが使用されます。このため、各評価のスコア範囲については、下限が前の評価範囲の上限となり、上限がその評価に対して可能な最高加重スコアの合計となります。

次の表に、スコア範囲の計算で使用されるコンポーネントの簡単な例を示します。

次の表に、最初の表のコンポーネントに基づいたスコア範囲計算を示します。

評価テンプレートのコンポーネント: 仕組み

質問の重み、返答スコアおよび返答評価は、全体の評価スコア、評価およびフィードバック・テキストを計算して表示する評価テンプレートのコンポーネントです。

質問の重みが返答スコアで乗算され、評価テンプレートの返答の加重スコアが生成されます。すべての返答の加重スコアが合計され、合計評価スコアが決まります。このスコアは、返答評価およびフィードバック・テキストに関連付けられた事前計算済のスコア範囲内になります。したがって、合計評価スコアが含まれるスコア範囲に応じて、完了した評価に関して表示される評価およびフィードバック・テキストが決まります。

質問の重み

質問の重みは評価テンプレート内での質問の相対的な重要度を示し、比率で表されます。テンプレート内のすべての質問の重みは、合計が100になる必要があります。評価テンプレートを使用して評価を実行するときは、質問に対して設定された返答のスコアが質問の重みで乗算され、その返答の加重スコアが生成されます。

返答スコア

返答スコアは、テンプレート内の質問に対する可能な返答に割り当てられたスコアです。テンプレート管理者は上限や下限を決めずに返答スコアを設定し、各スコアはテンプレートを使用する評価を正確にスコアリングするために正規化されます。返答スコアの正規化では、最高の返答スコアにスコア100が割り当てられ、他のすべての返答には最高スコアに対する相対的な正規化スコアが割り当てられます。

評価テンプレートを使用して評価を実行するときは、質問に対して設定された返答の正規化スコアが質問の重みで乗算され、その返答の加重スコアが生成されます。

返答評価

返答評価は、テンプレート内の質問に対する可能な返答に割り当てられた評価です。評価は「優秀」、「悪い」などの資格取得テキストで、数値スコア以外に、評価の結果から資格を取得するためのメトリックとして使用されます。返答評価は返答スコアに直接関連するため、この関係は、高いスコアが高い評価に変換されるように設定する必要があります。

管理者は、テンプレート作成プロセスの初期の段階で評価を構成して返答に割り当てます。次に、管理者がスコアと評価を返答に割り当てると、それらのエントリに基づいてスコア範囲が計算されます。各評価がスコア範囲に割り当てられと、管理者は評価とスコア範囲の組合せに対してフィードバック・テキストを適用できます。

評価テンプレートを使用して評価を実行すると、すべての返答の加重スコアが合計されて、合計評価スコアが決まります。そのスコアは計算済のスコア範囲内にあり、そのスコアによって、評価に割り当てられる評価、および表示するフィードバック・テキストが決まります。合計評価スコアは最大100です。

評価テンプレートとタスク・テンプレート: 仕組み

評価テンプレートの作成ステップの1つに、タスク・テンプレートの関連付けがあります。このステップは、テンプレートを使用して評価を行った後に実行するタスク・セットを提示する場合に実行します。評価テンプレートのスコア範囲にタスク・テンプレートを関連付け、その範囲内に全体の評価スコアが含まれていると、評価後に実行するように提示されるタスクが決まります。

評価テンプレート

評価テンプレートは重み付けされた質問と可能な返答のセットで、ビジネス・オブジェクト（商談や引合など）の状態を評価するために使用します。評価テンプレートは、評価の結果に基づいて提示される1つ以上のタスク・テンプレートに関連付けることができます。

タスク・テンプレート

タスク・テンプレートは、関連する活動のグループを生成するための指示です。タスク・テンプレートのサブタイプを「評価」にマークすると、そのタスク・テンプレートを評価テンプレートに関連付けることができます。タスク・テンプレートのビジネス・オブジェクト・タイプは、評価テンプレートに割り当てられたタイプと同じである必要があります。タスク・テンプレートが関連付けられた評価テンプレートを使用して評価を実行すると、その評価の合計スコアに基づいて1つ以上のタスク・テンプレートが提示されるため、それらのタスク・テンプレートを使用して、実行する活動のリストを生成できます。

たとえば、「事業開発マネージャの手配」というタスク・テンプレートを「Win-Winの可能性」という評価テンプレートに関連付けるとします。このタスク・テンプレートをスコア範囲86〜100に関連付けると、評価テンプレート「Win-Winの可能性」を使用した評価のスコアがこの範囲内の場合は、「事業開発マネージャの手配」タスク・テンプレートが提示され、このテンプレートに基づいてフォローアップ活動のリストを生成できます。

評価テンプレート・ステータス・コード: 説明

評価テンプレートの全工程を通して、複数の異なるステータス・コードを割り当てることができます。

ステータス・コードは、評価テンプレートに対して実行可能な処理を制御します。

• 進行中

• アクティブ

• 取下げ済

進行中

これは、評価テンプレートの初期ステータスです。評価テンプレートがこのステータスの場合は、評価テンプレートのすべての箇所を編集できます。テンプレートを削除できるのは、このステータスの場合のみです。テンプレートが削除されていない場合は、次の「アクティブ」ステータスに移行します。

アクティブ

これは、評価テンプレートが汎用目的でデプロイされたときに割り当てられるステータスです。評価テンプレートがこのステータスの場合は、テンプレート摘要、質問テキストの修正、質問順序の変更、返答摘要、スコア範囲フィードバックを含めて（ただし、これに限定されません）、小規模なテキストの編集のみが可能です。テンプレートは、このステータスから「取下げ済」に移行できます。テンプレートは削除できません。

取下げ済

このステータスの評価テンプレートは、汎用目的で使用できません。評価テンプレートのすべての箇所は編集できず、他のステータスに移行することはできません。ただし、コピーすることはできます。アクティブなテンプレートが削除されると、このステータスに戻ります。

商談と引合の評価に関するよくある質問

質問グループとは何ですか。

質問グループは評価テンプレート内の質問の論理グループで、質問のカテゴリ・ヘッダーとして限定的に使用されます。質問グループを適切に命名すると、テンプレートのユーザーが各グループ内の質問のタイプをおおまかに把握するのに役立ちます。

質問に対して自由書式の応答を含めるとどうなりますか。

自由書式の応答にはスコア0が割り当てられます。

自由書式応答オプションは、全体の評価スコアに影響を与えません。自由書式の応答には、評価テンプレートで提供される事前入力の返答に準拠せずに、質問に対する応答テキストを入力できます。

質問の重みを再入力するように求められるのはなぜですか。

このステップでは評価テンプレートのすべての質問が1箇所にリストされ、必要に応じて、すべての重みの合計が100になるように重みを編集できます。

商談の管理

商談の保存済検索: 説明

いくつかの保存済検索を使用すると、商談の検索に役立ちます。

営業ステージ: 説明

営業ステージは、商談が最終的な結論（受注または失注のいずれか）まで進行する間のフェーズです。通常、1つの販売方法には複数営業ステージのコレクションが含まれています。たとえば、1つの販売方法に5つの営業ステージが含まれている場合、各営業ステージには独自の属性があり、商談の進行に従ってそれぞれが異なる役割を果たします。

営業ステージの属性

営業管理者は、通常、営業ステージを設定するときに次の属性を定義します。

• フェーズ: 営業サイクル内での営業ステージのフェーズを示し、営業ステージのグループを定義します。たとえば、商談の販売方法の第1フェーズが「検出」フェーズの場合、営業担当はこのフェーズで顧客のニーズを調査し、顧客への販売計画を策定し始めます。

• 順序: 販売方法内のステージの順序を指定します。たとえば、営業ステージの第1フェーズを「検出」フェーズにし、最終フェーズを「結論」フェーズにすることができます。

• 期間: 商談が営業ステージにとどまる見積平均日数。

• ディール中断期限: 商談が特定の営業ステージにとどまることが許容される日数。この期限を超えた商談は、中断とみなされます。

管理者は、提供されている営業ステージを使用したり、ビジネスに固有の新規営業ステージを作成できます。また、管理者は営業コーチを追加して、プロセス・ステップを定義したり、各営業ステージで営業担当をガイドするリソースを提示することもできます。

販売方法と営業ステージ: 仕組み

販売方法と営業ステージは1対多の関係です。通常の実装では、1つの販売方法に複数の営業ステージが含まれます。販売方法の各ステージは商談の進行を表します。

販売方法

販売方法は、営業プロセスで営業ステージを取得するために使用する形式化された方法です。販売方法には、見込から予測および商談のクローズまで、営業プロセス中の様々な営業ステージに関連付けられたすべてのアクティビティを含めることができます。販売方法によって、販売組織全体にわたるベスト・プラクティスを実装できます。

営業ステージ

1つの販売方法には、通常、複数の営業ステージが存在します。営業ステージによって、商談は結論に向けて進行します。商談が作成されると、使用する販売方法の最初の営業ステージにその商談が設定されます。

営業コーチ: 説明

営業コーチは、販売向上のためのベスト・プラクティス情報を提示する指導ツールおよび方法です。

営業コーチの次の特性を活用すると、商談を成功クローズに導く活動を支援できます。

• プロセス・ステップ

• 推奨文書

• タスク・テンプレート

• 評価テンプレート

• 必須フィールド

プロセス・ステップ

プロセス・ステップは、特定の営業ステージで実行するベスト・プラクティス・プロセスをガイドします。たとえば、会社は「検出」営業ステージで、可能性がある顧客にインタビューし、製品リストを作成して、商談を次の営業ステージに進めるかどうかの決定を提示できます。

推奨文書

推奨文書（顧客レター・テンプレート、関連するWebサイト、研修資料など）は、コーチング戦略、ベスト・プラクティス情報、他の使用方法を提供します。

タスク・テンプレート

タスク・テンプレートは、特定の営業ステージに関連する必須タスクまたは推奨タスクのリストを提供します。推奨タスク・テンプレートはオプションです。商談が特定の営業ステージに移行すると、その営業ステージのタスク・リストには自動生成されたタスク・テンプレートが自動的に適用されます。

評価テンプレート

評価テンプレートを使用すると、商談オブジェクト（製品、競合相手、商談全体など）を分析したり、スコアリングすることができます。評価タイプを選択した後は、一連の返答を入力して加重スコアを生成します。このスコアは、商談の成功率を判断するのに役立ちます。

評価テンプレートはタスク・テンプレートと同様に、商談に自動的に適用したり（評価テンプレートが営業ステージで必須とマークされている場合）、手動で適用することができます。

必須フィールド

管理者は、営業ステージごとに、商談が次の営業ステージに進行する前に入力する必要がある、商談ヘッダーのフィールドを指定できます。

商談のデフォルト販売チャネル: 説明

商談の販売チャネルは、商談が内部営業担当によって直接処理されるか、または外部パートナ（販売業者や再販者など）によって間接的に処理されるかを示します。正しい販売チャネル値を指定することによって、正しいテリトリと営業担当が商談に割り当てられます。販売チャネルはテリトリ定義のディメンションの1つであるため、直接チャネルと間接チャネルの両方で販売を行う会社は、テリトリ・メトリックを使用して収益データを販売チャネル別に分割できます。この項では、販売チャネルのサポート、および販売チャネル・フィールドのデフォルト設定を商談に実装する方法について説明します。

販売チャネルのサポート

商談では、商談ヘッダー・レベルと収益明細レベルの両方で販売チャネルの追跡をサポートします。商談の保守を簡単にするために、販売ステータス・カテゴリが同一のヘッダーと明細の販売チャネルは、自動的に同期化されます。商談および収益明細の販売チャネルのデフォルト設定は、「パートナ商談のデフォルト属性の管理」設定ウィンドウで行います。この設定により、パートナ引合の引合登録タイプを使用して、引合登録が承認されて商談に変換されたときの商談のデフォルト販売チャネルが決まります。Oracle Fusion Partner Management機能が実装されていない場合、すべての商談の販売チャネルは「ダイレクト」に自動的に設定されます。追加情報については、「パートナ引合属性: 説明」を参照してください。

商談作成時のデフォルト販売チャネル

営業担当が商談UIで商談を作成する場合、商談にはパートナおよび引合登録タイプが関連付けられていないため、ヘッダー・レベルの販売チャネル・フィールドは「ダイレクト」に設定されます。営業担当が商談の作成時に収益明細を作成する場合、それらの明細の販売チャネルはヘッダーと同じ販売チャネルに設定されます。

引合変換から商談を作成する場合も、商談に引合登録タイプがないため、販売チャネルは「ダイレクト」に設定されます。

承認済の引合登録から商談を作成する場合、適切なヘッダー・レベルの販売チャネル値は、引合登録タイプを使用して決定されます。たとえば、「再販」引合登録から作成した商談は、デフォルト販売チャネルが「間接」になります（デフォルト構成を使用）。次に、ヘッダー・レベルの販売チャネル値を使用して、商談の収益明細のデフォルト販売チャネルが決定されます。

引合登録が引合UIから商談に手動でリンクされている場合、引合登録タイプに基づいた販売チャネルのデフォルト設定ロジックは適用されません。

収益明細作成時のデフォルト販売チャネル

収益明細が作成されるとき、収益明細の販売チャネルのデフォルト値はヘッダー・レベルの販売チャネル値と常に一致しています。収益明細の販売チャネルのデフォルト設定では、「パートナ商談のデフォルト属性の管理」ウィンドウでマップしたデフォルト設定は使用されません。

商談と収益明細の販売チャネル間の同期化

収益明細と商談ヘッダーの一般的な同期化の場合は、ユーザーが明細レベルで販売チャネルを明示的に上書きしないかぎり、ステータス・カテゴリがヘッダー・レベルのステータス・カテゴリと同じ収益明細では、同じ販売チャネル値が自動的に使用されます。

営業担当がヘッダー・レベルの販売チャネル値を変更すると、販売チャネル値とステータス・カテゴリがヘッダーと同じすべての収益明細は新しい値に同期化されます。たとえば、ヘッダー・レベルの商談ステータスが「オープン」で、販売チャネルが「ダイレクト」の場合、営業担当が販売チャネルを「間接」に変更すると、販売チャネルが「ダイレクト」のすべてのオープン収益明細は「間接」に自動的に変更されます。これらの条件に一致しない収益明細は変更されません。

商談のクローズ: 説明

クローズ済を示すいずれかの営業ステージまたはステータス（「受注済」、「失注済」、「販売なし」など）に商談を移行すると、商談のクローズが開始されます。

商談のクローズ・プロセスを必須ステップとして有効にした場合は、このプロセスの開始後に、クローズする商談に関するデータを「商談のクローズ」画面に入力する必要があります。必須データには、競合相手、製品、収益、および商談を受注または失注した事由に関する情報を含めることができます。

商談をクローズするには、商談の編集画面内から「商談のクローズ」処理または「保存してクローズ」ボタンを選択します。次に、商談のクローズに必要なデータを入力するように要求されます。

商談をクローズするには、次の3つの方法があります。

• 「商談のクローズ」UIを使用した商談のクローズ -- 詳細は、「「商談のクローズ」UIを使用した商談のクローズ」を参照してください。

• 「商談の編集」UIを使用した商談のクローズ -- 詳細は、「「商談の編集」UIを使用した商談のクローズ: 説明」を参照してください。

• 「商談の一括更新」UIを使用した複数の商談のクローズ -- 詳細は、「「商談の一括更新」UIを使用した複数の商談のクローズ: 説明」を参照してください。

専用の商談クローズ・フローの利点: 説明

専用の商談クローズ・フローおよび必須の要約画面を実装すると、次に説明する点で当該組織に大きな利点をもたらします。

• 当該組織は、拡張性を使用して、クローズ時のみ表示可能なカスタム・フィールドを追加できます。

• 商談のクローズには結論が必要であるため（変更を元に戻すことは可能）、商談のクローズ処理はトランザクションの発行に似ています。一般的なUI動作では、最後の発行ステップの前に、要約UIに該当するオブジェクトの主要属性が表示されます。

• 営業担当は包括的なUIを使用して商談の主要属性をすべてレビューし、必要な場合は、クローズ・プロセスを進める前に迅速に変更を行うことができます。

• 特定の必須フィールド（「受注/失注事由」、「競合」など）は、クローズ中に対処する必要があります。専用のUIを使用すると、商談をクローズする直前に、担当がこれらのフィールドに注意を向けることができます。

• 「商談の編集」UIでの検証を優先して専用のクローズUIをスキップすると、次の理由でユーザーの作業に支障が生じる場合があります。

  • 一部の検証は、すべての収益項目を展開しないと表示されない場合があります。たとえば、クローズ時には競争相手の入力が必須です（要約レベルと収益項目レベルの両方）。

  • 「商談の編集」UIで商談をクローズする場合は、クローズの検証が繰り返され、担当は明示的に保存を繰り返す必要があるため、マウスを何度もクリックする必要があります。このような保存操作の総コストは、アプリケーションの使用性に対して大きな負荷になる場合があります。

「商談のクローズ」UIを使用した商談のクローズ: 説明

営業担当が商談をクローズするときは、Oracle Fusion Opportunity Managementに要約画面が表示され、担当は、商談をクローズする前にこの画面で商談に関する情報をレビューして入力する必要があります。商談をクローズ・プロセスに発行する前に、担当は要約画面を使用して、商談ヘッダーおよび収益項目に対する最後の変更を入力できます。要約画面の次の動作に注意してください。

• 収益項目の競合相手フィールドを除いて、「商談の編集」ページの適用可能なすべてのUIフィールド（ステータス・コードを含む）および対応するステータスは、「商談のクローズ」UIに継承されます。たとえば、ユーザーが「商談の編集」ページでステータスを「クローズ済」カテゴリに変更し、受注/失注事由フィールドが使用可能になると、これらの変更も「商談のクローズ」ページに継承されます。元のページでステータスが「オープン」の場合は、「商談のクローズ」UIが起動すると、同じステータスが要約画面に継承されます。

• 商談レベルで競合相手が1社以上存在する場合は、競合相手が設定されていないすべての収益項目にヘッダーのプライマリ競合相手が伝播されます。ユーザーが「商談のクローズ」ページ内でプライマリ競合相手を変更すると、新しいプライマリ競合相手は、同期化している収益明細に伝播されません。

• ユーザーが「商談のクローズ」ページから変更を取り消すと、「商談の編集」ページに戻り、「商談のクローズ」ページで行ったすべての変更が消去されます。「商談の編集」ページの保留中の変更（「商談の編集」ページで最後に設定されたステータスを含む）は保留のままです。

• （「商談のクローズ」UIの確認処理を使用して）商談を正常に検証してクローズした後、ユーザーは「商談の編集」ページに戻ります。このページでは、「保存」または「保存してクローズ」をクリックして、すべての商談クローズ検証を処理し、商談のクローズに関連する変更をコミットします。

「商談のクローズ」ページのトランザクション管理

「商談の編集」ページから「商談のクローズ」ページに入力すると、「商談の編集」ページで商談に加えられて保存されていない変更は保持され、「商談のクローズ」ページに表示されるデータに反映されます。

「商談のクローズ」ページで「取消」ボタンをクリックすると、このページに入力した後に商談に加えられた変更がすべてロールバックされて「商談の編集」ページに制御が戻され、商談は「商談のクローズ」ページに入力する前のステータスに戻ります（「商談のクローズ」ページへの入力時にセーブポイントが発行され、取消時にそのセーブポイントへのロールバックが発行されます）。

「商談のクローズ」ページで「OK」ボタンをクリックすると、「商談のクローズ」ページに入力した後に加えられた保存されていない変更は保持され、変更を保存しないまま「商談の編集」ページに制御が戻されます。この後は、「商談の編集」ページで保存処理を行い、「商談の編集」ページと「商談のクローズ」ページで加えられた変更をコミットする必要があります。

検証および同期化動作

専用の「商談クローズ・フロー」UIを使用した商談のクローズは、すべての検証、および商談ヘッダー属性と収益明細属性の間の相関動作に準拠します。「商談のクローズ」UIの同期化動作は、商談ヘッダーと収益項目の間の相関動作から導出されます。

「商談のクローズ」ページの保存および取消動作: 説明

商談クローズ・フローは、トランザクション管理の標準動作に準拠します。主なポイントは次のとおりです。

• 「商談の編集」ページから「商談のクローズ」ページに入力すると、「商談の編集」ページで商談に加えられて保存されていない変更は保持され、「商談のクローズ」ページに表示されるデータに反映されます。

• 「商談のクローズ」ページで変更を取り消すと、クローズ・ページに入力した後に商談に加えられた変更がすべてロールバックされて「商談の編集」ページに制御が戻され、商談は「商談のクローズ」ページに入力する前のステータスに戻ります（「商談のクローズ」ページの入力時にセーブポイントが発行され、取消時にそのセーブポイントへのロールバックが発行されます）。

• 「商談のクローズ」ページで「OK」ボタンを選択すると、「商談のクローズ」ページに入力した後に加えられた保存されていない変更は保持され、変更を保存しないまま「商談の編集」ページに制御が戻されます。この後は、「商談の編集」ページで保存処理を行い、「商談の編集」ページと「商談のクローズ」ページで加えられた変更をコミットする必要があります。

「商談の編集」UIを使用した商談のクローズ: 説明

営業担当は、「商談の編集」ページを使用して商談をクローズできます。編集ページでは、「商談クローズ・フローの使用可能」プロファイル・オプションが有効かどうかに関係なく、商談をクローズするオプションを使用できます。

この方法では、ユーザーは商談ステータスをクローズ済ステータス・カテゴリの1つに設定します。これによって、同期化しているすべての収益項目のステータスが、ヘッダーのクローズ済カテゴリ・ステータスに設定されます。さらに、次の動作が発生します。

• 商談および収益項目の受注/失注事由が使用可能になります。ユーザーは、収益項目レベルで受注/失注事由を個別に設定するか、商談ヘッダーの受注/失注事由を変更できます。ユーザーがヘッダー・レベルで受注/失注事由を入力すると、受注/失注事由が設定されていないすべての収益項目にその事由が伝播されます。

• ユーザーは、ヘッダー・レベルと収益項目レベルの両方で競合相手を商談に追加するように要求されます（まだ追加していない場合）。

• ユーザーが「保存」または「保存してクローズ」を選択すると、トランザクションのコミット前に、一連の商談クローズ検証が実行されます。

検証および同期化動作

「商談の編集フロー」UIを使用した商談のクローズは、すべての検証、および商談ヘッダー属性と収益明細属性の間の相関動作に準拠します。「商談の編集」UIの同期化動作は、商談ヘッダーと収益項目の間の相関動作から導出されます。

例外

「商談の編集」UIを使用して商談をクローズする場合は、通常の商談の同期化動作および検証について次の例外に注意してください。

• 商談の受注/失注事由に対する更新は、「受注/失注事由」属性が同期化しているすべての商談収益明細に伝播されません。

• 商談のプライマリ競合相手が定義されている場合は、商談のステータスを「オープン」ステータスから「クローズ済」ステータスに更新しても、「競合相手」属性が定義されていないすべての商談収益明細について、収益明細の「競合相手」属性は更新されません。

「商談の一括更新」UIを使用した複数の商談のクローズ: 説明

営業担当は、商談リストから複数の商談を選択し、それらの商談内の特定のフィールドまたは属性を一括更新できます。「一括更新」ダイアログ・ボックスには、一括更新が可能な属性の名前-値ペアが表示されます。営業担当はフィールドの選択を確認して任意の値を入力し、変更をコミットして、選択したすべての商談を更新します。ダイアログ・ボックスが終了して商談リストが更新され、新しい値が表示されます。

検証

「商談の一括更新」UIを使用した商談のクローズは、すべての検証、および商談ヘッダー属性と収益明細属性の間の相関動作に準拠しますが、次の項で説明するようにいくつかの例外があります。

一括更新時には、次の属性によって収益項目に関する特別な相関動作が発生します。

• 受注確度

• クローズ日

• 「予測に含む」設定

• ステータス

• 受注/失注事由

一括更新プロセスでは、更新対象として有効ないくつかのフィールドをマークし、それらのフィールドに対して適切な更新値を入力して、すべての変更を一度にコミットします。ユーザーの観点から見ると、これは単純なプロセスです。ただし、次の理由から、実際にこのプロセスを使用するには複雑な側面があります。

• （「商談の編集」UIを使用した）通常の商談の更新で実行されるすべての検証は、一括更新の対象としてマークしたすべての商談向けに保守する必要があります。

• （「商談の編集」UIを使用した）通常の商談の更新でサポートされているすべての同期化動作は、一括更新の対象としてマークしたすべての商談向けに保守する必要があります。これには、一括更新の対象として選択したすべての商談に対する、商談ヘッダー・フィールドの更新と同期化している基礎となる収益項目への更新の伝播が含まれます。

• （「商談の編集」UIまたは専用の「商談のクローズ」UIを使用して）商談をクローズする際に基礎となる収益項目に対して実行されるクローズ・フローの検証と相関更新のほとんどは、「クローズ済」ステータスに一括更新されるすべての商談向けに保守する必要があります。

同期化動作

一括更新の同期化動作は、商談ヘッダーと収益項目の間の相関動作から導出されます。詳細は、「商談属性と収益明細属性の同期化動作: 説明」を参照してください。

例外

「商談の一括更新」UIを使用して商談をクローズする場合は、通常の商談の同期化動作および検証について次の例外に注意してください。

• 1つ以上の「クローズ済」ステータスの収益明細がある商談を保存するときは、収益明細の「競合相手」属性が定義されていないために検証チェックが失敗する場合があります。この理由で商談保存の検証が失敗したときに、商談のプライマリ競合相手が定義されている場合は、エラー・ダイアログが表示され、「競合相手」属性が定義されていないすべての収益明細に商談のプライマリ競合相手をコピーして、この検証の失敗を修正するオプションが示されます。この動作は、商談の編集フローと商談クローズ・フローの両方に適用されます。

• この動作は、商談の一括更新とフローには適用されません。収益明細の必須の「競合相手」属性が欠落しているために検証が失敗すると、検証の失敗を修正する方法がないことを示すエラー・メッセージが表示されます。

商談の一括更新のビジネス・ロジックの要約

一括更新機能を使用すると、次のいずれかが更新された場合に、商談の属性値が収益明細の属性値にコピーされます。

• 受注確度

• クローズ日

• 「予測に含む」設定

• ステータス

• 受注/失注事由

次の表で、一括更新時に商談が従う設定動作を説明します。

商談の管理に関するよくある質問

営業ステージを変更するといくつかのフィールドが変更されるのはなぜですか。

商談を次の営業ステージに移行すると、その商談の進捗を反映して、商談レベルの受注確度が上がります。商談レベルの受注確度と同期化しているすべての収益項目の受注確度も、商談レベルの受注確度と一致するように変更されます。

管理者は、設定時に、各営業ステージに対してデフォルト受注確度を指定できます。

受注確度を変更するとどうなりますか。

商談レベルで受注確度を変更すると、同期化しているすべての商談収益明細の受注確度が更新されます。さらに、収益項目レベルで受注確度を更新すると、予測生成エンジンは、明細が予測条件と一致するかどうかに基づいて、予測に参加している明細を変更する場合があります。

商談の予定クローズ日は最初にどのようにして設定されますか。

管理者は、販売方法を定義するときに、販売方法の平均クローズ・ウィンドウを入力できます。販売方法が指定されると、この値を使用して商談の予定クローズ日がデフォルト設定されます。

テリトリはどのようにして商談に追加しますか。

Oracle Fusion Opportunity Managementでは、テリトリを商談に明示的に追加することはできません。テリトリは、Oracle Fusion Work Managementに含まれる割当マネージャによって、商談収益明細のディメンション属性とテリトリのディメンション・メンバーが照合され、商談収益明細に自動的に割り当てられます。収益明細に適用可能なテリトリのディメンションは、「地理」、「顧客規模」、「販売チャネル」、「製品」、「アカウント・タイプ」（「指定」または「指定なし」）、「産業」、「組織タイプ」および「勘定科目分類」です。

商談にテリトリ（プライム・テリトリ、オーバーレイ・テリトリなど）を割り当てるには、スケジューラ・ページから収益テリトリ割当実行バッチ・プロセスをスケジュールするか、商談内から「商談の割当」処理を使用できます。これらのオプションを使用してテリトリ・ベースの割当を実行するには、「商談割当モード」プロファイル・オプションを設定する必要があります。また、「保存時の割当発行の使用可能」プロファイル・オプションを「はい」に設定すると、レコードが保存されるたびにテリトリを商談に割り当てることができます。

ディール保護とは何ですか。

ディール保護機能を使用すると、営業担当は、受け取る収益明細から販売実績を削除されたり、テリトリの再編成が行われたときに商談チームから削除されたりしないように、自動的に保護されます。ディール保護は、割当マネージャのテリトリ・ベースの割当機能によって、実績受取者として収益項目に自動的に割り当てられる営業リソース、または商談チームに適用されます。営業担当が保護されるデフォルト日数は、リソースのディール保護期間プロファイル・オプションで指定します。フル・アクセス・レベルの商談チーム・メンバーは、保護がアクティブになる日付を上書きできます。

ロック割当とは何ですか。

ロック割当によって、営業担当が商談から自動的に削除されるのを割当エンジンを介して防ぎます。営業チーム・メンバーのロック割当フラグを選択または選択解除できるのは、商談へのフル・アクセス権があるユーザーのみです。

プロセス・ステップはどのようにして営業サイクルを支援しますか。

プロセス・ステップは、特定の営業ステージで実行するベスト・プラクティス・プロセスをガイドします。たとえば、会社は「検出」営業ステージで、可能性がある顧客にインタビューし、製品リストを作成して、商談を次の営業ステージに進めるかどうかの決定を提示できます。

推奨文書とは何ですか。

推奨文書は、コーチング戦略、ベスト・プラクティス情報、他の使用方法を入手できるリソースを提供します。推奨文書には、顧客レター・テンプレート、関連するWebサイト、研修資料などが含まれています。

プロセス・ステップとは何ですか。

プロセス・ステップは営業コーチ機能の一部で、管理者が設定します。プロセス・ステップは、営業担当が特定の営業ステージで、最も効率的かつ効果的にディールを進行させて結果を成功に導くために準拠する推奨手順です。

割当マネージャとは何ですか。

Oracle Fusion Work Managementの割当マネージャ・モジュールは、特定のパラメータに基づいて営業チーム・メンバーを商談に割り当てます。割当エンジンを起動する様々な方法については、「商談チーム割当: 説明」を参照してください。

商談割当の管理

商談チーム割当: 説明

商談割当は次のいずれかの方法で実行されます。チーム・メンバー（リソース）は、Oracle Fusion Work Managementに含まれる割当マネージャによって商談に自動的に割り当てられるか、十分な権限があるユーザーがOracle Fusion Opportunity ManagementのUIを使用して営業チームに追加します。

次のシナリオでは、チーム・メンバーを商談に割り当てる方法を説明します。

バッチ方法

チーム・メンバーを割り当てるための推奨方法は、バッチ・プロセスを使用する方法です。次に説明する2つのプロセスは、個別にまたは組み合せて使用できます。

• 収益テリトリ割当要求: このプロセスは、商談収益明細に対するテリトリ・ベースの割当を起動する際に使用します。このプロセスでは、商談バッチのすべての収益明細が個別に評価されます。次に、ディメンションが特定の収益明細のディメンション属性と一致するテリトリが、該当する明細に割り当てられます。割り当てられたテリトリの所有者または全メンバーのいずれかが、「テリトリ・ベースのリソース割当スタイル」プロファイル・オプションの設定に応じて商談チームに追加されます。

• 商談リソース割当要求: このプロセスは、商談に対するルール・ベースの割当を起動する際に使用します。このプロセスでは、「営業チーム・メンバー割当ルール・セット・グループ」プロファイル・オプションの定義に従って、割当マネージャが一連のルールを実行し、商談に対して一致する候補を検索します。一致する候補が検出されると、その候補は営業チームに追加されます。ロック割当が無効のチーム・メンバーは、割当ルールに一致しない場合、置換されることに注意してください。

手動方法

商談へのフル・アクセス権があるユーザーは、営業チーム・メンバー（商談所有者を含む）を手動で割当または再割当できます。新しい所有者に商談が手動で再割当されると、元の所有者は、営業チームから手動で削除されないかぎり、非プライマリ・チーム・メンバーとして営業チームに残ります。

リソース推奨

ユーザーは、商談内から「推奨の表示」処理を選択して、事前定義の割当ルールに基づいて割当マネージャが営業チーム・メンバーの推奨を取得するように要求できます。次に、このユーザーは推奨リストから営業チームに候補を追加できます。すでに商談営業チームに属しているリソースは推奨されません。

リソースを推奨する際に使用される割当ルール・セット・グループは、「営業チーム・メンバー推奨事項ルール・セット・グループ」プロファイル・オプションで指定します。

即時方法

営業担当は、商談内から「商談の割当」処理を使用して割当マネージャを起動し、リソースを商談にリアルタイムで自動的に割り当てることができます。割当マネージャは、「商談割当モード」プロファイル・オプションの設定に基づいて、テリトリ・ベースの割当、ルール・ベースの割当、またはその両方を起動できます。

商談の保存

「保存時の割当発行の使用可能」プロファイル・オプションを「はい」に設定すると、保存時に割当マネージャが起動して商談全体を割り当てます。即時方法と同様に、割当マネージャは、「商談割当モード」プロファイル・オプションに基づいて、テリトリ・ベースの割当、ルール・ベースの割当、またはその両方を起動できます。

テリトリ提案のアクティブ化

Oracle Fusion Sales BPELのイベント・リスナーは、変更されたテリトリおよび影響を受ける商談を識別し、テリトリ提案のアクティブ化に従って自動的に割り当てます。この時点で、テリトリ・ベースの割当が起動し、テリトリを商談収益明細に割り当てます。ここでも、「テリトリ・ベースのリソース割当スタイル」プロファイル・オプションの設定に応じて、割り当てられたテリトリの所有者または全メンバーのいずれかが商談チームに再度追加されます。

ルール・ベースの割当は、テリトリ提案のアクティブ化では起動されないことに注意してください。

ルール・ベースのフィルタリングによるテリトリ・ベースの割当の使用: 例

この例では、販売アカウントを持つ営業引合に、1つ以上のテリトリおよび追加の引合チーム・リソースを割り当てます。見込引合には、1名以上のリソースを割り当てることができます。割当マネージャを使用して、一致するテリトリと一致するリソースを判断します。Oracle Fusion Partner Relationship Managementの実装では、指定の引合に一致するすべてのテリトリ（プライム、オーバーレイ、パートナなど）を識別できます。次に、ルール・フィルタリングを使用して、割り当てられているテリトリのタイプ（パートナまたはプライム）を、特定の属性値（販売チャネル、ディール・サイズなど）に基づいて引合に反映します。

シナリオ

Acme社では、新しい引合を適切なテリトリに割り当て、次にその引合を適切な営業引合に割り当てます。販売チャネルが割り当てられていない場合は、ディールをパートナが処理するか、または内部で処理するかを決定します。ディールを内部で処理する場合は、プライム・テリトリのみが割り当てられます。ディールをパートナが処理する場合は、そのディールを監視するためにチャネル・マネージャも割り当てられます。

トランザクション詳細

割当エンジンで処理される主要なマーケティング・ビジネス・オブジェクトは引合です。テリトリの割当は、適切な営業担当を引合に割り当てる主要な手段です。販売チャネルが指定されていない場合は、ルール・フィルタリングを使用してテリトリをフィルタ処理することもできます。見込引合は、引合に関する情報（ディール・サイズなど）に基づいて追加リソースを識別するために、割当エンジンによって処理されます。

Oracle Fusion Lead Managementは、割当マネージャを呼び出し、テリトリ・ベースの割当の割当タイプを使用して、引合を作業オブジェクトとして指定し、テリトリを候補オブジェクトとして指定します。これによって、テリトリのリストが決定します。次に、割当処理では、ルール・フィルタリングを使用して、テリトリ・ベースの割当のルールが含まれたルール・セット・グループを呼び出します。

テリトリ・ベースの割当によってテリトリのリストが提供されると、次のルールを使用して割当プロセスを調整できます。

1. SALES CHANNEL != NULLの場合のルール

   1. SalesLead.Sales Channel =!NULL

   2. 処理: 一致する候補を返す

2. SALES CHANNEL = NULLで、チャネル・マネージャを割り当てる場合のルール

   1. Sales Lead.Sales Channel = NULL

   2. Sales Deal.Deal SizeAttribute < 1,000,000

   3. Territory.Territory Type = パートナ、販売チャネル・マネージャ

   4. 処理: 一致する候補を返す

3. SALES CHANNEL = NULLで、プライムを割り当てる場合のルール

   1. Sales Lead.Sales Channel = NULL

   2. Sales Deal.Deal SizeAttribute > 1,000,000

   3. Territory.Territory Type = プライム

   4. 処理: 一致する候補を返す

分析

発生した引合は、テリトリに割り当ててフォロー・アップする必要があります。前述のルールに基づいて、この引合がパートナ（および監視する販売チャネル・マネージャ）が処理できる小規模なディールか、または内部の営業担当によるフォロー・アップが必要な大規模なディールかを判断できます。

割当の結果

割当エンジンは、最初に、引合に対するテリトリのリストを識別します。次に、ルールを使用して、ディールの担当が決まります。

1. 最初のルールでは、販売チャネル値が存在するかどうかが判別されます。存在する場合は、（テリトリ・ベースの割当を使用して）識別したすべてのテリトリが割り当てられます。

2. 2番目のルールでは、販売チャネルが割り当てられておらず、ディールが100万ドル未満の場合、引合はパートナおよび販売チャネル・マネージャに割り当てられます。

3. 最後のルールは、販売チャネル値が存在せず、ディールが100万ドルを超える場合に適用され、引合はプライム（内部）テリトリに割り当てられます。

商談割当マネージャ・オブジェクトの管理

割当オブジェクトのコンポーネント: 仕組み

作業オブジェクト、候補オブジェクトおよび属性は、ルール・ベースおよびテリトリ・ベースの割当で使用する割当オブジェクトの作成に必要なコンポーネントです。作業オブジェクトは、割当が必要なビジネス・オブジェクト（引合、商談など）です。候補オブジェクトは、作業オブジェクトに割り当てられるビジネス・オブジェクト（リソース、テリトリなど）です。

候補オブジェクトを作成するときは、後でルールやマッピングで使用する属性を選択できます。これらの候補オブジェクトは、作業オブジェクトを作成するときに関連付けが可能な候補にもなります。作業オブジェクトを作成するときは、属性を選択する他に、1つ以上の候補を関連付けることもできます。

作業オブジェクト

作業オブジェクトは、割当が必要なビジネス・オブジェクト（引合、商談など）です。作業オブジェクトを作成するときは、アプリケーション情報の入力、割当で使用する属性の選択、および1つ以上の候補の関連付けを行います。

候補オブジェクト

候補オブジェクトは、最終的な割当で1つ以上の作業オブジェクトに関連付けられるビジネス・オブジェクト（リソース、テリトリなど）です。候補オブジェクトを作成するときは、アプリケーション情報の入力、およびルールやマッピングで使用する属性の選択を行います。分類オブジェクトは、特別なタイプの候補オブジェクトです。このタイプの候補オブジェクトは、作業オブジェクトに割り当てられるビジネス・オブジェクトを表しません。これは、分類ルールでのみ使用され、主に引合のランキングまたは資格取得で使用されます。

管理者は、作業オブジェクトと候補オブジェクトの間の関連を定義する必要があります。たとえば、引合作業オブジェクトは、テリトリ候補オブジェクトとリソース候補オブジェクトの両方に関連付けることができます。これは、割当マネージャを使用すると、テリトリとリソースを引合に割り当てることができることを意味します。

管理者は、収益作業オブジェクトの関連する「候補」タブで、作業オブジェクトと候補オブジェクトの間の関連を定義できます。たとえば、収益作業オブジェクトは、テリトリ候補オブジェクトと実績割当テンプレート候補オブジェクトの両方に関連付けることができます。この関連は、割当マネージャを使用すると、テリトリと実績割当テンプレートの両方を収益明細に割り当てることができることを示します。

関連候補

候補オブジェクトを作業オブジェクトに関連付けるには、次のフィールドを使用します。

• 候補の割当: 割当マネージャが割当を実行することを示します。設定されていない場合は、割当マネージャを使用して一致する候補が検索され、その候補が呼出しアプリケーションに渡されて作業オブジェクトが更新されます。

• カスタム・ロジック: 割当マネージャが割当の一致の結果を作業オブジェクトのコールバック機能に渡すことを示します。たとえば、商談管理では、営業チームをテリトリ・メンバーで更新するカスタム・ロジックが使用されます。これによって、テリトリが収益明細に割り当てられ、テリトリ・チーム・メンバー（リソース）が商談営業チームに追加されます。

• 割当候補のマージ: 各マッピング・セットの処理で識別された一致する割当候補をマージするかどうかを制御します。これは、複数のマッピング・セットを割当処理で使用するときに、一致する候補をマージする場合に使用します。このチェック・ボックスを選択すると、候補がマージされます。デフォルトでは選択されていません。

• 手動候補の維持: 手動で割り当てられた候補を割当処理時に維持することを示します。このオプションを使用して、手動で追加された候補が再割当時に削除されるのを防ぎます。販売アカウントおよび商談管理では、独自のロック割当機能が実装されます。

• 候補の置換: 不適格な候補を、割当の実行時にチームから削除するかどうかを決定します。たとえば、割当マネージャを初めて実行したときに、営業引合にテリトリが割り当てられたとします。テリトリ提案のアクティブ化に続いて再割当プロセスが実行されると、そのテリトリは無効になります。「候補の置換」が設定されている場合、そのテリトリは営業引合から削除されます。

• 候補除外: 営業引合には、各営業引合から除外された候補を保存する関連オブジェクトがあります。割当マネージャはこの情報にアクセスして、除外された候補に作業オブジェクトが割り当てられるのを防ぎます。

• 親属性: テリトリ・ベースの割当で使用し、一致するテリトリの階層を判別してすべての親テリトリを削除して、一致するリーフ・ノード・テリトリのみを返して割り当てます。この属性を使用しない場合は、一致するすべてのテリトリ（親またはリーフ）が返されて割り当てられます。

• 候補差別化属性: 一致する候補の差別化に使用される候補オブジェクトの属性を保存します。たとえば、収益明細割当では、この属性によって、複数のテリトリ・タイプ（プライム、チャネル営業マネージャなど）の一致するリーフ・テリトリが割当可能になります。候補差別化属性はテリトリ・ベースの割当にのみ関連し、親属性が選択されている場合のみ選択できます。

• カバレッジ属性: 一致する候補リスト内の候補に、通常のカバレッジ、包含または除外されたカバレッジがあるかどうかを示すために使用するテリトリ属性。

• 最大候補数: 作業オブジェクトと候補オブジェクトの組合せに対して返される最大候補数。デフォルト値は100です。

• 手動属性: 候補が（システムによる割当ではなく）手動で割り当てられたことを識別する属性。この属性は「手動候補の維持」属性とともに使用されます。

• 手動候補の維持: 手動で割り当てられた候補を、作業オブジェクトの割当または再割当時に維持することを示すフラグ。このオプションは、手動属性が定義され、割り当てられた候補オプションが選択されている場合のみ有効です。

• 候補の置換: 一致しない候補を、作業オブジェクトの再割当時に削除するかどうかを示します。たとえば、割当を初めて実行したときに、テリトリAが営業引合に割り当てられ、テリトリ定義に変更があったとします。この営業引合が再割当されると、テリトリAは無効になります。このオプションが選択されている場合は、そのテリトリAが営業引合から削除されます。

• スコア属性: 計算済スコアが保存されるスコア属性。

• システム属性: 候補が（手動による割当ではなく）システムによって割り当てられたことを識別する属性。

属性の選択

属性は、割当オブジェクトに対して定義されたビュー・オブジェクトの要素です。各割当オブジェクトには、割当ルールや割当マッピングの構成時に使用する1つ以上の属性を選択できます。たとえば、販売アカウントなどの作業オブジェクトには、指定アカウント・フラグ、「顧客規模」および「組織タイプ」の各属性を選択できます。販売アカウント作業オブジェクトに割当マッピングを構成するときは、選択した属性を使用できます。販売アカウントのマッピングは、指定アカウント・フラグ属性を使用して作成できます。

候補オブジェクトの属性を選択するときは、その候補オブジェクトが含まれる割当ルールや割当マッピングの構成時に使用する属性以外に、割当マネージャの実行後に推奨候補が表示される画面に表示する候補オブジェクトの属性も選択します。たとえば、候補オブジェクトがリソース（営業担当）で、割当処理で営業担当が推奨されたときに名、姓および電話番号を表示する場合は、その名、姓および電話番号に対応するリソース候補オブジェクトの属性を選択し、それらの属性を推奨候補画面に表示する順序を指定する必要があります。

割当オブジェクトの追加

「割当オブジェクトの管理」ページでは、作業オブジェクトや候補オブジェクトを定義および編集し、テリトリ・ベースのマッピングを定義できます。前述の図は、作業オブジェクトと候補オブジェクトの間の関連、および作業オブジェクトへの一致する候補のマッピングを示しています。

作業オブジェクトや候補オブジェクトを追加または編集するときは、次の主要情報が定義に必要になります。

• 名前: オブジェクトの一意の名前とオプションの摘要。

• コード: オブジェクトの処理で使用される一意のコード。

• 「作業オブジェクト」/「候補オブジェクト」チェック・ボックス: オブジェクトが作業オブジェクト、候補オブジェクト、またはその両方であることを示します。

• アプリケーション・モジュール: Oracle Application Development Framework（ADF）のビジネス・コンポーネント。このコンポーネントは、エンド・ユーザー・タスクに関連する作業の論理ユニットについて、ビジネス・サービス・メソッドおよびUIで認識されるデータ・モデルをカプセル化します。コンシューマ・アプリケーションの「アプリケーション・モジュール」の完全修飾定義名を入力します。トップ・レベルの作業オブジェクトと候補オブジェクトに対して有効です。子オブジェクトは、この値を親から自動的に継承します。

• アプリケーション・モジュール構成: 分類候補オブジェクトを除き、トップ・レベルの作業オブジェクトと候補オブジェクトに対して有効です。子オブジェクトは、この値を親から自動的に継承します。

• ビュー・オブジェクト・インスタンス: アプリケーション・モジュール（商談など）の設計時に、ビュー・オブジェクト・コンポーネントのデータ・モデルの定義で使用します。分類候補オブジェクトを除き、すべてのレベルの作業オブジェクトと候補オブジェクトに対して有効です。

  • ビュー・オブジェクト・コレクションの行に関する情報は、表示基準を定義してフィルタ処理できます。分類候補オブジェクトを除き、トップ・レベルの作業オブジェクトと候補オブジェクトに対して有効です。

• 主キー属性1: オブジェクトの主キーを構成する最初または唯一の属性。分類候補オブジェクトを除き、トップ・レベルの作業オブジェクトと候補オブジェクトに対して有効です。

• リフレッシュ間隔: 候補オブジェクトのデータをリフレッシュする間隔（分単位）。デフォルト設定は0分です。分類候補オブジェクトを除き、トップ・レベルの候補オブジェクトに対して有効です。

• 初期キャッシュ: オブジェクトを処理する際のキャッシュの初期サイズ。この値が使用されるのは、エンジンがオブジェクトを初めて処理したとき、またはサーバー・バウンスの後です。デフォルト値は2で、最大値は20です。分類候補オブジェクトを除き、トップ・レベルの候補オブジェクトに対してのみ有効です。スコアリングで使用されるすべての作業オブジェクト（引合など）では、スコアリング・ルールのプロファイル・オプション値に製品レベル（MOW_SCORING_INITIAL_CACHES）の初期キャッシュが使用されます。

• 最大キャッシュ: オブジェクトを処理する際のプール/キャッシュの最大サイズ。デフォルト値は5で、最大値は25です。トップ・レベルの候補オブジェクトに対してのみ有効です。

  注意

  スコアリングで使用されるすべての作業オブジェクト（引合など）では、スコアリング・ルールのプロファイル・オプション値に製品レベル（MOW_SCORING_MAX_CACHES）の最大キャッシュが使用されます。

• スコア属性: 割当要求が処理された後に計算済合計スコアを保存するオブジェクトの属性。トップ・レベルの作業オブジェクトに対してのみ有効です。

• 割当日属性: 割当要求の処理後に割当日を保存するオブジェクトの属性。トップ・レベルの作業オブジェクトに対して有効です。

• 割当除外属性: 割当から作業オブジェクトを除外するための設定を保存するオブジェクトの属性。トップ・レベルの作業オブジェクトに対して有効です。

割当オブジェクト属性の追加

ユーザーは割当マネージャを使用して、割当オブジェクトのビュー・オブジェクトから、割当評価の際に使用される一連の属性を指定できます。割当エンジンは、主キーまたは割当属性に加えて、各割当オブジェクトのビュー・オブジェクト行からこれらの割当オブジェクト属性をロードします。これは、割当評価に使用されない属性はロードしないことによって、パフォーマンスが向上するように設計されています。

割当オブジェクト属性は、各作業オブジェクトとすべての子オブジェクト、および割当エンジンで使用される各候補オブジェクトに対して定義します。

• ビュー・オブジェクト属性: 割当オブジェクトに対して定義されるビュー・オブジェクトの各属性の名前。これらの属性を使用すると、割当ルールまたは割当マッピングを構成できます。候補オブジェクトの場合は、対話型の割当UIに表示する属性も選択する必要があります。

• 候補情報順序: この属性が対話型の割当UIに表示される順序。

割当マッピングの設定

テリトリ・ベースの割当は、割当マッピングによって導出されます。このマッピングでは、テリトリ・ベースの割当処理で使用されるディメンション、属性およびテリトリ・フィルタリングを識別します。ディメンション・マッピングおよび一部の属性マッピングには順序があり、テリトリの照合時にこれらのマッピングが使用される順序を制御します。順序がないマッピングは、照合プロセスの最後にまとめて使用されます。マッピングのデフォルト・セットはシードされています。このシードは、商談、引合および販売アカウントが同じテリトリ階層を使用することを前提にしています。

割当マネージャの関連する「候補」リージョンには、マッピングの各セットを処理して識別された一致する割当候補をマージするかどうかを制御するインジケータがあります。このインジケータは、複数のマッピング・セットを割当処理で使用するときに、一致する候補をマージする場合に使用します。このボックスを選択すると、候補がマージされます。デフォルトでは選択されていません。

次の割当マッピングを使用できます。

• 属性マッピング: たとえば、テリトリ・パートナ・プログラムIDが営業引合パートナ・プログラムIDと同じ場合に、テリトリを営業引合に割り当てるとします。この場合、テリトリ・プログラムIDが営業引合属性プログラムIDと同じになると、テリトリが照合されます。

• ディメンション・マッピング: たとえば、収益明細に関連付けられた製品に基づいて、テリトリを商談収益明細に割り当てるとします。この場合は、マッピング・タイプとして製品ディメンションが選択されます。候補オブジェクトの低い属性と高い属性は、テリトリにおける製品の下限と上限の連番属性の名前に対応しています。作業オブジェクトの低い属性と高い属性は、収益明細にある製品の下限と上限の連番属性の名前に対応しています。

• 代替属性を使用したマッピング: 同じシナリオで、収益明細に製品ではなく製品グループが割り当てられている場合は、作業オブジェクトの低い代替属性と高い代替属性に対して入力された製品グループの下限と上限の連番属性を追加します。

• デフォルト値を使用したマッピング: 同じシナリオで、特定の収益明細にある製品の下限と上限の連番属性に値が含まれていない場合は、すべての収益明細に対して製品属性の低いデフォルト値と高いデフォルト値が使用されます。

• リテラル・マッピング: テリトリ属性の特定の値に基づいて、一致するテリトリをフィルタリングする方法です。たとえば、販売アカウント中心カバレッジ・モデルが指定されているテリトリのみを照合します。たとえば、テリトリ・カバレッジ・モデルがSALES_ACCOUNT_CENTRICと等しい場合です。

割当マネージャの構成: 重要な選択

割当は、候補をオブジェクトとして選択し、作業オブジェクトに関連付けるプロセスです。割当は2つのフェーズで構成されています。1番目のフェーズは照合フェーズで、可能な候補のリストから適切な割当先を検出するために、照合ルールまたはマッピングが評価されます。2番目のフェーズは処分フェーズで、一致する候補が処分されます（つまり、割り当てられます）。割当マネージャは、割当が必要なビジネス・オブジェクトを設定し、リソースとテリトリの選択と割当を指示するルールとマッピングを作成するために使用するツールです。候補は、作業オブジェクトに対する潜在的な割当先です。作業オブジェクトは、割当マネージャ内のアプリケーション・ビジネス・オブジェクトを表します。作業オブジェクトは、マッピング目的で使用するビジネス・オブジェクトおよび関連する子オブジェクトの属性を取得します。割当マネージャを最適に計画して構成するには、次の点を考慮する必要があります。

• ビジネス・オブジェクト

• 属性

• リソースおよびテリトリ

• 割当処分

• マッピング・セットおよびマッピング

• ルール

ビジネス・オブジェクト

ビジネス・オブジェクトは、販売アカウント、商談、引合など、ユニットとして処理されるデータ・エンティティまたはデータのコレクションです。割当の実行が必要なビジネス・オブジェクトは、割当マネージャでは作業オブジェクトとみなされます。作業オブジェクトはビジネス・オブジェクトを表し、マッピングおよびルールは候補（テリトリ、リソースなど）を作業オブジェクトに正確かつ適時に割り当てるために作成されます。割当マネージャを構成するときは、割当が必要なビジネス・オブジェクトを慎重に検討し、該当するビジネス・オブジェクトに対してのみ作業オブジェクトを作成します。

テリトリやリソースを販売アカウント、商談および引合に割り当てるために、一連のビジネス・オブジェクト（つまり、割当オブジェクト）がシードされています。

割当処分

割当が必要なビジネス・オブジェクト（作業オブジェクト）と、それらに割り当てる候補オブジェクトを決定した後は、一致する候補の割当処分の実行方法を決定する必要があります。次の質問を検討してください。

• 1つのリソースを割り当てますか、または複数のリソースを割り当てますか。

• 一致する候補を自動的に割り当てますか、または一致する候補に対してカスタム・ロジックを実行しますか。

• 一致する候補のスコアを作業オブジェクトに記録しますか。

• 手動で割り当てられた候補を割当処理時に維持しますか。

• 不適格な候補を割当処理時に置換しますか。

属性

候補が適切に作業オブジェクトに割り当てられるように、マッピングおよびルールを作成します。これらのマッピングおよびルールでは、属性を使用して最適な割当を決定します。割当マネージャで作業オブジェクトと候補オブジェクトを設定するときは、マッピングおよびルールで使用するオブジェクトの属性も選択します。たとえば、商談のリスク・レベルに基づいて、リソース（特定の営業担当など）をビジネス・オブジェクト（商談など）に割り当てるとします。この場合は、商談作業オブジェクトと営業担当候補オブジェクトを作成するときに、リスク・レベルに対応する商談の属性と、スキル名やEメール・アドレスに対応する営業担当の属性を選択します。属性を選択すると、それらの属性がマッピングおよびルールの条件で使用可能になるため、候補オブジェクトと作業オブジェクトの照合で使用する条件を反映した属性を確実に選択できます。

マッピング・セットおよびマッピング

テリトリ・ベースの割当は、割当マッピング・セットおよび関連するマッピングによって導出されます。マッピング・セットは、マッピングの順序、およびテリトリ・ベースの割当で使用されるマッピングを決定します。マッピングでは、割当処理で使用されるディメンション、属性およびテリトリ・フィルタリングを識別します。デフォルトのマッピング・セットおよび関連するマッピングはシードされています。このシードは、商談、引合および販売アカウントが同じテリトリ階層を使用することを前提にしています。

すでに作成した作業オブジェクト、候補オブジェクトおよび属性を使用して、マッピングを作成します。マッピングを設計するときは、テリトリ構造で使用するディメンションと属性、およびテリトリ候補と作業オブジェクトを照合する方法を慎重に検討してください。

ルール

ルールは、ルール・ベースの割当の実行に対して定義します。ルールは、候補が一連の条件に一致しているかどうか、定義されたスコア範囲内かどうか、特定の分類に属しているかどうかに基づいて、候補を返すように設計されています。

すでに作成した作業オブジェクト、候補オブジェクトおよび属性を使用して、ルールを作成します。ルールを設計するときは、候補と作業オブジェクトを照合する方法を慎重に検討してください。たとえば、リソースを割り当てる際は、リソースの地域、製品知識、オブジェクトのステータスやスコア、またはこれらの属性の組合せを基準にしますか。候補の照合のみを行いますか、または候補を照合してスコアリングしますか。複数の候補を対象にする場合は、一致するすべての候補を割り当てますか、または特定のスコアを超える候補のみを割り当てますか。ルールを作成する前に、これらの質問を検討してください。

割当マッピングの作成: 例

テリトリ・ベースの割当の場合は、割当オブジェクトの作成時に、作業オブジェクトから候補オブジェクトへのマッピングを作成します。これらのマッピングを使用して、候補の割当を行います。割当に対して複数タイプのマッピングを作成できます。次のシナリオでは、様々なマッピングについて説明します。

• 属性マッピングの作成

• ディメンション・マッピングの作成

• リテラル・マッピングの作成

属性マッピングの作成

テリトリ・プログラムIDが営業引合プログラムIDと同じ場合に、テリトリを営業引合に割り当てるとします。この場合は、作業オブジェクトが営業引合で、候補オブジェクトが営業引合テリトリのマッピングを作成します。テリトリ属性のプログラムIDが営業引合属性のプログラムIDと同じになると、テリトリが選択されます。

別の例では、テリトリの手動によるアカウント包含または除外が営業引合のアカウントと同じ場合に、テリトリを営業引合に割り当てるとします。この場合は、作業オブジェクトが営業引合で、候補オブジェクトが営業引合テリトリのマッピングを作成します。テリトリ属性のアカウント・ノード統合ID（AccoutnNodeIntgId）が営業引合属性のパーティIDと同じになると、テリトリが照合されます。

ディメンション・マッピングの作成

収益明細に関連付けられた製品に基づいて、テリトリを商談収益明細に割り当てるとします。この場合は、作業オブジェクトが商談収益明細で、候補オブジェクトがテリトリのマッピングを作成します。マッピング・タイプとして製品ディメンションを選択します。候補オブジェクトの低い属性と高い属性は、テリトリにおける製品の下限と上限の連番属性の名前に対応しています。作業オブジェクトの低い属性と高い属性は、収益明細にある製品の下限と上限の連番属性の名前に対応しています。たとえば、ProdSeqLowは収益明細にある製品の下限の連番属性名の例です。

• 代替属性を使用したマッピング: 収益明細に関連付けられた製品に基づいてテリトリを商談収益明細に割り当てる同じシナリオで、収益明細に製品ではなく製品グループが割り当てられている状況が発生する場合があります。この場合は、ディメンション・マッピングのシナリオで作成したマッピングと同じマッピングを作成し、作業オブジェクトの低い代替属性と高い代替属性に対して、製品グループの下限と上限の連番属性の名前を追加します。たとえば、ProdGrpSeqLowは収益明細にある製品グループの下限の代替連番属性名の例です。

• デフォルト値を使用したマッピング: 収益明細に関連付けられた製品に基づいてテリトリを商談収益明細に割り当てる同じシナリオで、割当処理時に、収益明細にある製品の下限と上限の連番属性に値が含まれていない状況が発生する場合があります。この場合は、ディメンション・マッピングのシナリオで作成したマッピングと同じマッピングを作成し、収益明細に対して製品属性の低いデフォルト値と高いデフォルト値を追加します。

リテラル・マッピングの作成

リテラル・マッピングは、テリトリ属性の特定の値に基づいて、一致するテリトリをフィルタリングする方法です。たとえば、確定したテリトリ（テリトリ・ステータスが「確定済」など）のみを検索できます。

処分ロジック: 処理方法

Oracle Fusion Work Managementに含まれる割当マネージャは、2ステップのプロセスを使用して候補を割り当てます。1番目のステップでは、割当マネージャ・アプリケーションを使用して候補を選択します。作業オブジェクトに割り当てる候補は、テリトリ・ベースのマッピング、ルール・ベースのマッピング、またはルール・ベースのフィルタリングを使用したテリトリ・ベースのマッピングによって決まります。

2番目のステップは処分です。選択した処分ロジックに基づいて、選択した候補が作業オブジェクト表またはその子表に書き込まれます。処分の結果は複数ありますが、2つの主要ロジック機能に基づいています。1番目は「候補の割当」ロジックです。2番目は「カスタム・ロジックの実行」で、これは候補オブジェクトの割当処分を定義する方法です。たとえば、特定の候補リストをEメールで送信したり、選択した候補を特定の表に書き込みます。「カスタム・ロジックの実行」は「候補の割当」ロジックと組み合せて使用できます。

処分に影響を与える設定

「候補の割当」を指定すると、割当マネージャは、選択プロセスで返された1つ以上の候補を使用できます。

• 単一の候補が返された場合: 割当マネージャは、作業オブジェクト表に対して入力する必要がある主キー属性フィールドに基づいて、候補をその作業オブジェクト表に書き込みます。

• 複数の候補が返された場合: 作業オブジェクトの子表が指定され、返された候補が記録されます。次に、主キー・フィールドとして機能する属性を1つ以上、最大3つまで指定します。返された候補を書き込む方法には、「候補の置換」および「手動候補の維持」の2つの選択肢があります。

  • 候補の置換: 「候補の割当」ロジックが実行されると、その結果が作業オブジェクトの子表内の既存の結果と比較されます。「候補の置換」が選択されている場合は、既存の候補が作成され、新しい結果に置換されます。手動で入力した候補は影響を受けません。

  • 手動候補の維持: 割当マネージャを使用する一部のアプリケーションでは、候補の手動入力が可能です。候補を手動で入力すると、手動入力を示す属性が「Y」（つまり、「はい」）に設定されます。「手動候補の維持」が選択されて手動属性が設定された場合、「候補の割当」ロジックでは、作業オブジェクトの子表に書き込むときにこれらの候補が無視されます。

「カスタム・ロジックの実行」を選択すると、独自のコードを作成し、選択プロセスで返された候補に対して、またはその候補を使用して、特定の処理を実行できます。このオプションが選択されると、選択プロセスの後に、割当マネージャは、カスタム・ロジック・コードを呼び出して選択プロセスから受け取った情報を渡すアプリケーション・モジュールのコールバック機能を使用します。

処分ロジックの処理方法

割当マネージャは、候補を選択して、選択フェーズからの結果を候補の割当、カスタム・ロジックまたはその両方に渡します。

ユーザー・インタフェースの「カスタム・ロジックの実行」と「候補の割当」の両方を選択した場合、割当エンジンは最初に「候補の割当」ロジックを起動し、次にカスタム・ロジックを実行します。

商談割当マネージャ・ルールの管理

ルール・セットのコンポーネント: 仕組み

ルール・セット・タイプ、フィルタ設定およびルール処理は、作業オブジェクトに対するルール・ベースの割当の処理方法を割当マネージャ・エンジンに指示するために必要なルール・セットのコンポーネントです。

ルール・セット・タイプはルール・セット・レベルで設定され、スコアリングとの候補の照合と候補照合の2つのルール・セット・タイプには追加のフィルタ設定が必要です。ルール・セット内のルール・レベルでは、ルールがtrueと評価された場合に実行する処理を決定するための処理設定が入力されます。ルール処理は、ルール・セット・タイプと組み合せて使用します。

ルール・セット・タイプ

実行するルール・ベースの割当処理のタイプは、ルール・セットのルール・セット・タイプによって決まります。たとえば、ルール・セット・タイプが候補照合の場合は、割当エンジンがルールの条件と照合してtrueと評価した候補が、作業オブジェクトに割り当てられます。作業オブジェクトに割り当てられる一致候補数は、ルール・セットのフィルタ設定によって決まります。

フィルタ設定

フィルタ設定は、候補照合とスコアリングとの候補の照合の2つのルール・セット・タイプと組み合せて使用します。フィルタを使用すると、作業オブジェクトに割り当てる一致候補数を指定できます。「すべての最小超過スコア」に設定すると、特定のスコアを超過するすべての一致候補が作業オブジェクトに割り当てられます。スコアは「最低スコア」フィールドに設定します。

「上位x」に設定すると、指定した数の上位スコアの一致候補が作業オブジェクトに割り当てられます。割り当てる上位一致候補の数は、「候補数」フィールドを使用して指定します。

ルール・セット・タイプが候補照合の場合は、フィルタが「ランダム」に設定されると、一致候補がランダムに選択されて作業オブジェクトに割り当てられます。ルール・セット・タイプがスコアリングとの候補の照合の場合は、フィルタが「ランダム」に設定されると、上位スコアの一致候補がランダムに選択されて作業オブジェクトに割り当てられます。割り当てるランダム一致候補の数は、「候補数」フィールドを使用して指定します。

処理

ルールがtrueと評価された場合に実行される処理は、処理設定によって決まります。処理設定は、ルール・レベル（ルール・セット・レベルではなく）で設定されるコンポーネントの1つですが、ルール・セット・タイプと組み合せて使用します。ルール・セット・タイプが「分類」の場合、可能なルール処理は「次として候補値を返す: <値>」のみです。たとえば、ルール・セットの作業オブジェクトが引合で、候補オブジェクトが「引合資格取得」という分類オブジェクトであるとします。この場合は、ルール・セット・タイプが「分類」に設定されると、そのセット内のいずれかのルールの処理は「次として候補値を返す: 適格」になります。このルールがtrueと評価されると、分類される引合の引合ステータスは「適格」に設定されます。

ルール・セット・タイプが候補照合の場合、可能なルール処理は「一致する候補を返す」のみです。この処理を設定したルールがtrueと評価されると、そのルールの条件に一致する候補が割り当てられます。ルール・セット・レベルのフィルタ設定によって、すべての一致候補が割り当てられるか（「すべて」）、またはランダムな数の一致候補が割り当てられるか（「ランダム」）が決まります。

ルール・セット・タイプがスコアリングとの候補の照合の場合、可能なルール処理は「次の単位で一致候補のスコアを増やす: <値>」のみです。この処理を設定したルールがtrueと評価されると、そのルールの条件に一致する候補のスコアに値が追加されます。たとえば、ルール・セットの作業オブジェクトが商談で、候補オブジェクトがリソースであるとします。この場合は、ルール・セット・タイプがスコアリングとの候補の照合に設定されると、そのセット内のいずれかのルールの処理は「次の単位で一致候補のスコアを増やす: 10」になります。そのルールがtrueと評価されると、そのルールの条件に一致するリソースのスコアに10が追加されます。スコアは累積されるため、この例でルールの条件に一致したリソースが、セット内でtrueと評価された別のルールの条件にも一致すると、そのテリトリの現在のスコアにさらに値10が追加されます。ルール・セット・レベルのフィルタ設定によって、すべての一致候補が割り当てられるか（「すべて」）、指定したスコアを超過するすべての一致候補が割り当てられるか（「すべての最小超過スコア」）、上位スコアの一致候補がランダムに選択されて割り当てられるか（「ランダム」）、指定した数の上位スコアの一致候補が割り当てられるか（「上位x」）が決まります。

ルール・セット・タイプが「スコアリング」の場合、可能なルール処理は「次の単位でスコアを増やす: <値>」のみです。この処理を設定したルールがtrueと評価されると、ルール・セットに関連付けられた作業オブジェクトのスコアに値が追加されます。たとえば、ルール・セットの作業オブジェクトが引合であるとします。この場合は、ルール・セット・タイプが「スコアリング」に設定されると、そのセット内のいずれかのルールの処理は「次の単位でスコアを増やす: 20」になります。そのルールがtrueと評価されると、引合のスコアは20の単位で増加します。

商談割当の管理に関するよくある質問

割当マネージャとは何ですか。

Oracle Fusion Work Managementの割当マネージャ・モジュールは、特定のパラメータに基づいて営業チーム・メンバーを商談に割り当てます。割当エンジンを起動する様々な方法については、「商談チーム割当: 説明」を参照してください。

候補はどのようにして割当から除外しますか。

割当プロセス中に候補を除外するには、「候補」タブにナビゲートします。「候補の除外」セクションをスクロール・ダウンします。除外する候補を制御するビュー・オブジェクトを入力し、キー・フィールド（最大3つ）の選択条件を入力します。

分類候補オブジェクトはどのようにして識別しますか。

「アプリケーション・モジュール」フィールドに「分類」と入力します。これによって、分類タイプのルール（例: 引合の資格取得またはランキングを行うルール）の設定時に使用できる候補オブジェクトが作成されます。

割当オブジェクトまたはその属性の1つを非アクティブとマークするとどうなりますか。

割当オブジェクトの「非アクティブ」ボックスを選択すると、選択した作業または候補の割当オブジェクトが割当処理で使用不可になります。割当属性の「非アクティブ」ボックスを選択すると、選択した作業または候補のオブジェクト属性が割当処理で使用不可になります。

リテラル・マッピング、ディメンション・マッピングおよび属性マッピングの違いは何ですか。

ディメンション・マッピング: 比較対象の作業オブジェクト属性と候補オブジェクト属性がディメンション属性（「地理」、「製品」、「アカウント」など）の場合は、ディメンション・マッピングを使用する必要があります。マッピングを作成するときは、「機能コード」フィールドを使用して、ディメンションの一意の識別子を指定します。複数のディメンションで同じ関数が使用されている場合は、この識別子が変換関数に渡されます。

属性マッピング: このマッピングを使用すると、作業オブジェクト属性と候補オブジェクト属性の間で属性値を比較および照合できます。候補オブジェクト属性の値が作業オブジェクト属性と一致すると、その候補が選択されます。比較対象の作業オブジェクト属性と候補オブジェクト属性がディメンション属性でない場合は、属性マッピングを使用する必要があります。たとえば、プログラムID属性を持つ引合作業オブジェクトと、プログラムID属性を持つテリトリ・オブジェクトがあるとします。選択条件は、「Sales Lead Territory.ProgramIDがSales Lead.LeadProgramIDと等しい営業引合テリトリを選択」です。割当エンジンは、このマッピング・データを使用して、選択条件に一致する候補オブジェクトに対する問合せを作成します。マッピングを作成するときに、変換関数を使用する場合、必要なのは機能サービスと機能コードのみです。「機能コード」フィールドを使用して属性の一意の識別子を指定すると、この識別子が変換関数に渡されます。

リテラル・マッピング: リテラル・マッピングは、ほとんどの場合、候補オブジェクトのフィルタ処理で使用されます。この形式のマッピングを使用すると、候補属性を、ユーザーが選択した特定の値と照合して比較できます。割当エンジンは、マップされた候補オブジェクト属性を、指定されたリテラル値と照合して比較します。たとえば、TerrStatusCode属性の値がFINALIZEDのテリトリ候補オブジェクトを選択します。

ルール・ベースの割当とテリトリ・ベースの割当の違いは何ですか。

テリトリ・ベースの割当は、CRMオブジェクトを割り当てる主要な手段です。テリトリ・ベースの割当の場合は、割当オブジェクトの作成時に、候補の割当で使用される作業オブジェクトから候補オブジェクトへのマッピング・セットを作成します。

ルール・ベースの割当は、追加リソースを識別したり、一致するテリトリをフィルタ処理するために使用されます。ルールは、作業オブジェクトのスコアリングや分類にも使用できます。ルール・ベースの割当の場合は、ルール・エディタを使用して、割当エンジンが候補の割当に使用する式ベースのルールを作成します。

テリトリは、Fusion CRMで主要な役割を果たします。属性を使用して、会社が市場に進出する方法を定義します。つまり、会社が顧客への販売活動のために営業担当をどのように配置するかです。すべての販売アカウント、引合および商談には、1つまたは複数のテリトリが割り当てられます。多くの場合、顧客は、任意の粒度でこれらの機能および販売計画/テリトリ編成機能を使用可能にするために、個々の営業担当レベルまでテリトリを実装します（つまり、各営業担当に独自のテリトリを設定します）。

テリトリ・ベースの割当の場合は、通常、適切な候補の割当を行うために、作業オブジェクトと候補オブジェクトの間にマッピング・セットを作成します。このマッピング・セットは、作業オブジェクト属性と候補オブジェクト属性の間の1つ以上のマッピングで構成できます。

テリトリ・ベースの割当設定の簡単な例には、商談収益明細作業オブジェクトとテリトリ候補オブジェクトの間の簡単なマッピング・セットがあります。このマッピング・セットには、商談（収益明細の親）の事業所属性をテリトリの地理属性にマップする1つの簡単なマッピングが含まれます。地理値が親商談の事業所に一致するテリトリが照合されて、商談収益明細に割り当てられます。別の例として、引合作業オブジェクトとテリトリ候補オブジェクトの間に定義された2つのマッピング・セットを考えてみます。1番目のマッピング・セットでは、引合の顧客産業とテリトリの産業ディメンションの間のマッピングに基づいて、各引合へのテリトリの割当が決定します。このマッピングは、ステータスが「確定済」のテリトリをフィルタ処理するリテラル・マッピング、および販売中心カバレッジ・モデルがあるテリトリをフィルタ処理するリテラル・マッピングに該当します。2番目のマッピング・セットは条件付きで、パートナ・チャネル・マネージャ・テリトリの割当を決定します。このマッピング・セットは、引合のプライマリ・パートナの地理とテリトリの地理ディメンションの間の1つのマッピングで構成されます。このマッピングは、ステータスが「確定済」のテリトリをフィルタ処理するリテラル・マッピング、およびパートナ中心カバレッジ・モデルがあるテリトリをフィルタ処理するリテラル・マッピングに該当します。

ルール・ベースの割当の場合は、適切な候補の割当のために満たす必要がある条件を使用してルールを作成します。たとえば、作業オブジェクトを照合して割り当てるには候補オブジェクト（リソース）の製品スキル評価が中級以上、という条件を使用してルールを作成します。

次の表では、テリトリ・ベースの割当とルール・ベースの割当の機能および長所/短所を比較します。

商談の評価に関するよくある質問

タスク・テンプレートとは何ですか。

タスク・テンプレートは、特定の営業ステージに関連する必須タスクまたは推奨タスクのリストを提供します。

評価テンプレートとは何ですか。

評価テンプレートを使用すると、特定のビジネス・オブジェクト（商談製品、商談競合相手、商談全体など）の状態を評価できます。評価テンプレートは、重み付けされた質問、およびスコアリングされた可能な返答のセットで構成されます。適切な評価タイプを選択した後に、評価テンプレート内のすべての質問に対する返答を入力して、評価が発行された際のスコアを生成します。このスコアは、ビジネス・オブジェクトの状態を評価するために使用します。たとえば、スコアは親商談の成功率を判断するのに役立ちます。

販売収益の管理

販売収益の管理: 概要

販売収益には、会社の潜在的な収入が反映されます。販売収益を効率的に管理することは、商談を管理する際の重要なポイントです。会社は商談収益データを使用して、営業パイプラインや受注/失注トレンドの分析、リソースの実績の管理、および収益予測の生成を行います。

Oracle Fusion Opportunity Managementは、販売収益を管理するための強力な機能を備えています。販売収益を管理するためのUIは、商談の編集画面から使用可能で、使いやすく複数の機能を備えています。収益UIには、次の一般的な営業担当タスクが含まれます。

• 顧客が関心を示す商談製品および製品グループの追加。これは、販売カタログ（統合されている場合）を使用したり、在庫から直接選択して追加します。

• 項目の収益金額（通常は、ユニット数に価格を乗算した額）の入力。これは予測収益になります。

• 収益明細項目の属性（予測包含、価格、数量、クローズ日、受注確度など）の設定。

• 経常収益項目（サービス、研修プランなど）の管理。

• 商談チーム・メンバーが受け取る販売実績金額の割当と管理。

• 収益明細の一括更新。この機能を使用すると、営業担当は1つの画面で、商談内の複数の収益明細を選択し、すべての収益明細に共通する変更を適用できます。

収益明細項目: 説明

製品または製品グループは、商談に追加されると商談収益明細項目として認識されます。

収益明細項目は、次の主要属性で構成されます。

• 顧客が購買に関心を持っている製品

• 数量、単位、単価（見積価格とも呼ばれる）、収益などの価格設定情報

• 商談クローズ日

• 販売の受注確度

• 予測属性

収益明細の収益金額は要約収益に合計またはロールアップされ、商談ヘッダー・レベルで表示されます。

収益項目の価格設定フィールド

収益明細項目の数量、見積価格（単価）および収益金額は、商談UIで入力できます。製品または製品グループを商談に追加するときは、数量および見積価格を追加できます。アプリケーションによって見積価格に数量が乗算されます。金額は直接入力することもできます。

注意: 収益金額を更新した場合、収益明細項目の数量や見積価格は自動的に更新されません。

商談収益の使用: 説明

Oracle Fusion Opportunity Managementは、営業担当が販売収益を管理および追跡できる強力なインタフェースを備えています。この項では、収益UIの主要機能について説明します。

「収益」リージョンの使用

収益項目を追加、削除および管理するには、「商談の編集」UIの「収益」リージョンを使用します。

収益項目を追加するには、収益表に行を追加します。表の製品領域で、項目またはグループのいずれかを選択します。グループを選択した場合は、製品グループ名のリストから製品グループを追加します。項目（1つの製品）を選択した場合は、製品のリストから製品を追加します。販売カタログから製品グループまたは個別の製品項目を選択するには、その販売カタログを参照して目的のグループまたは項目を検索し、収益表に行として追加します。必要に応じて、他の編集可能フィールドを変更します。次のフィールドの動作に注意してください。

• クローズ日: 収益項目の予定クローズ日を示します。初期値は商談レベルのクローズ日です。

• 予測: 収益項目が予測条件と一致した場合に、チェック・マークが表示されます。次の属性は、変更と同時に、レコードの保存を待たず即時に更新されます。「製品グループ」、「数量」、「見積価格」、「収益」、「受注確度」、「収益タイプ」、「予測収益」および「ステータス」。

• 製品: タイプに「項目」または「グループ」のいずれかを選択し、次に関連するグループまたは製品を選択します（詳細は、後述の「製品選択」を参照）。

• 数量: 初期値はnullまたはゼロです。

• 見積価格: ユーザーが入力するか、当該会社が外部の価格設定エンジンを使用できます。

• 単位: 選択した製品または製品グループに基づいた初期値。リスト内の項目の最初の単位が選択されます。

• 収益: 上書きしないかぎり、アプリケーションによって価格に数量が乗算されます。

• 通貨: 初期値は商談レベルの通貨です。

• ステータス: 初期値は、オープンを示すカテゴリ内のステータスです。カテゴリに属するステータスの中からアルファベット順に最初のステータスが選択されます。

• 受注確度: 初期値は商談レベルの受注確度です。

• 最良ケース（収益）: 初期値は項目またはグループの収益です（収益が最良ケースを超える場合）。

• 最悪ケース（収益）: 初期値はnullです。

• 販売チャネル: 商談が生成された販売チャネル。通常は「ダイレクト」または「間接」です。

• 予測に含む: 最初は「予測条件と一致した場合」に設定されますが、「常時」または「なし」に上書きできます。

• ロック所有者: 値が選択されている場合は、テリトリ再編成時に収益所有者を再割当できず、ディール保護も適用されないことを意味します。

• パートナ: 収益明細の販売活動に参加している組織。

• テリトリ: 製品ディメンションに一致して自動的に割り当てられたテリトリが表示されます。

• 競合相手: 初期値はnullです。

• 事由: 販売を失注した事由を入力するために使用します。

• 実績クローズ日: ユーザーがステータスを「クローズ済」ステータスに設定すると、自動的に設定される読取り専用フィールド。

製品選択

製品選択によって、適切な製品を適切な顧客に販売できます。顧客の多様な要件に応じるために豊富な製品ラインを持つ組織では、競争を優位に進めるために、顧客に焦点を絞った製品が必要になります。製品選択の最大の目的は最適な製品を推察することで、これにより、情報に基づいて製品を選択できます。

Oracle Fusion Opportunity Managementでは、次の2つの方法のいずれかを使用して製品を選択します。

• 製品セレクタまたは製品グループ・セレクタ: 販売する製品を正確に把握している場合は、製品セレクタを使用して製品を選択します。販売する製品を正確に把握していない場合は、製品を選択せずに、製品グループ・セレクタを使用して製品グループを選択します。製品セレクタは製品の固定リストで、階層やツリーのナビゲーションはありません。製品は、製品名および摘要に基づいて検索できます。製品名をドリルダウンすると、製品に関する詳細情報を表示できます。製品グループ・セレクタには、販売カタログで使用可能な製品グループと同じセットがデフォルトで表示されます。

• 販売カタログ: 販売カタログを参照すると、製品詳細の確認、製品の検索、または製品の比較を行うこともできます。販売カタログの詳細は、Oracle Fusionのドキュメントで販売カタログに関する項を参照してください。

ここで説明したすべての製品選択メカニズムは、適格性ルールと統合されています（実装済の場合）。適格性ルールによって、営業担当は、顧客が購買するのに適格な製品のみをオファーできます。

収益項目に製品を指定するのはオプションです。初期の営業ステージでは、販売する製品を正確に把握できていない場合があります。ただし、収益明細項目には製品または製品グループのいずれかを指定する必要があります。これらの属性のいずれかが欠落している場合は、エラー・メッセージが表示されます。収益明細項目に製品と製品グループの両方は指定できません。

複数製品の一括追加

複数の製品を一括で追加するには、製品セレクタで複数の製品を選択して「収益」リージョンに追加します。

製品がデータベースにコミットされるのは、商談を保存またはクローズした場合のみです。

製品セレクタをフィルタ処理すると、営業テリトリ内の製品項目または製品グループのみを表示できます。

数量、見積価格および収益の入力

収益明細項目の数量、見積価格（単価とも呼ばれる）または収益金額を入力できます。当該組織は、自動価格設定のために外部の価格設定システムと統合できます。

アプリケーションによって見積価格に数量が乗算され、収益金額が決まります。デフォルトの収益金額は変更できますが、変更した場合、収益明細項目の数量や見積価格は自動的に更新されません。

製品単位の指定

通常、収益明細には、販売する製品の単位（UOM）を指定します。たとえば、製品は分単位、日単位またはケース単位で請求できます。

製品セレクタまたは販売カタログから製品を選択すると、その項目のデフォルトUOMが自動的に入力されます。ただし、別のUOMを入力することもできます。その場合、その製品に関連付けられた数量や見積価格は自動的に更新されません。

UOM値リストには、製品に適用可能なUOMのみが表示されます。

製品適格性

製品セレクタおよび製品グループ・セレクタで適格性ルールを実施することによって、顧客が購買するのに適格な製品のみを販売できます。たとえば、顧客の地域で使用できない無線プランは販売できません。会社の実装に応じて、不適格な製品をUIに表示できる場合とできない場合があります。

販売実績の割当: 説明

会社は、販売実績割当を使用して営業担当の実績およびクオータ達成に関するレポートを作成して、販売報酬計算のファクタの決定に役立て、テリトリ別の販売予測を容易にします。販売実績受取者および収益金額は、パイプライン・レポート作成およびクオータ達成のためにリソース階層にロールアップされます。

販売実績は、販売実績の割当ダイアログ・ウィンドウを使用して収益明細に対して手動で入力したり、実績割当テンプレートを使用して自動的に生成することができます。収益明細が初めて作成されるとき、収益明細作成者は収益販売実績の100%受取者として常にデフォルト設定されます。

収益販売実績

収益販売実績を割り当てるときは、次の点に注意してください。

• 収益実績受取者として適格なのは、内部リソースのみです。

• 収益販売実績は合計が100%になる必要があります。

• 予測テリトリを設定できるのは、「収益」または「収益および収益外」の予測参加がある収益明細に割り当てられている任意のテリトリです。

収益外販売実績

収益外販売実績を割り当てるときは、次の点に注意してください。

• 外部リソース（パートナなど）と内部リソースの両方が収益外実績受取者として適格です。

• 収益外販売実績は合計が100%になる必要はありません。

• 選択した割当スタイルが「収益に比例」の場合は、収益明細金額が変更されると、販売実績金額がそれに比例して自動的に調整されます。

• 選択した割当スタイルが「非定型金額」の場合は、収益明細金額が変更されても販売実績金額は変更されません。

• 予測テリトリを設定できるのは、「収益外」または「収益および収益外」の予測参加がある収益明細に割り当てられている任意のテリトリです。

販売実績受取者および予測テリトリのデフォルト設定ロジック: 説明

販売実績受取者および予測テリトリの情報は、デフォルト設定ルールに従って入力されます。この項では、デフォルト設定ルールについて説明します。

収益明細が初めて作成されるとき、収益明細作成者は販売実績の100%受取者として設定されます。デフォルトの実績割当は編集して、必要に応じて別の収益受取者を追加できます。実績割当テンプレートを使用しないかぎり、収益外実績受取者はデフォルトで設定されないため、手動で追加する必要があります。

商談割当が実行されると、割り当てられた収益明細ごとに既存の実績割当が処理され、適格なテリトリのみが予測テリトリとして設定されていること、および実績受取者が予測テリトリからの適格なリソースであることが確認されます。収益明細が予測済とフラグ付けされている場合、収益販売実績または収益外販売実績の金額はテリトリの予測に自動的に組み込まれるため、このプロセスは重要です。

予測テリトリのデフォルト設定のロジック

通常、予測テリトリのデフォルト設定では次のロジックが使用されます。

• ユーザーが選択した予測テリトリが収益明細に割り当てられ、その予測参加が販売実績タイプと一致する場合は、その予測テリトリが保持されます。

• 予測テリトリの導出には、既存の実績受取者を使用します（可能な場合）。

• 「収益」、「収益外」および「収益および収益外」の予測参加があるテリトリは、デフォルト設定ロジックでは同等に処理されます。

具体的には、予測テリトリのデフォルト設定時に次のロジックが使用されます。

• 販売実績に対する現在の予測テリトリが、予測参加が一致する割当済テリトリの1つである場合、その予測テリトリは変更されません。

• 予測参加タイプが一致するテリトリが1つのみの場合は、そのテリトリが予測テリトリとして設定されます。

• 予測参加が一致するテリトリが複数ある場合、予測テリトリは次の優先順位で選択されます。

  • 既存の実績受取者が所有者のテリトリ

  • 既存の実績受取者がメンバーのテリトリ

  • 予測参加が一致し、有効開始日が最も遅いテリトリ

• 一致するテリトリがない場合、予測テリトリはnullに設定されます（これは、テリトリ階層にギャップがあることを意味します）。収益実績割当の予測テリトリがnullに設定され、UIから商談割当が起動されると、警告メッセージが表示されます。

実績受取者のデフォルト設定のロジック

通常、ユーザーが選択した実績受取者が適格な実績受取者である場合、その実績受取者はアプリケーションによって置換されません。次の場合、実績受取者は変更されません。

• 収益明細のロック所有者設定が有効な場合

• 現在の実績受取者がディール保護されている場合

• 現在の実績受取者が予測テリトリの所有者またはメンバーである場合

前述の各条件を満たさない場合は、予測テリトリ所有者が新しい実績受取者として設定されます。

販売収益およびテリトリ予測のメトリック: 説明

Oracle Business Intelligenceでは、指定のテリトリに割り当てられたすべての予測項目のリストを表示するテリトリ予測ビューを表示できます。テリトリ予測ビューには、未調整の予測、調整済予測など予測関連の主要メトリックが表示され、テリトリ所有者はこのビューを使用して、主要メトリックを収益ベース・メトリックのパイプラインおよびクローズ済収益累計と比較できます。両方の収益メトリックは、テリトリおよび予測期間/調整期間のコンテキストで表示され、データ・ウェアハウス内の収益ファクト表から取り込まれます。

クローズ済収益

クローズ済収益は、ステータス・カテゴリが「受注済」、予測テリトリがターゲット・テリトリ（予測対象）、クローズ日がターゲット予測期間内にある、すべての収益明細項目の合計収益金額です。

パイプライン

パイプラインは、ステータス・カテゴリが「オープン」、予測テリトリがターゲット・テリトリ（予測対象）、クローズ日がターゲット予測期間内にある、すべての収益明細項目の合計収益金額を表します。

Forecastingによるメトリックの更新

Oracle Fusion Sales Forecastingでは、リアルタイム情報に基づいて、クローズ済収益およびパイプラインが更新されます。これは、オンライン・トランザクション処理（OLTP）システムのリアルタイム・データに基づいて、未調整の予測、最良ケース、最悪ケースの予測などの予測メトリックが計算されるリアルタイムの予測方法と一致しています。この要件を満たすために、これらのメトリックはアクティブなテリトリ階層に沿ってロールアップされます。

販売予測では、予測項目の収益金額がトランザクション通貨（入力通貨）と企業通貨で保存されます。営業担当は、予測項目の収益金額をトランザクション通貨で編集できます。商談を保存すると、収益金額は入力通貨と企業通貨の両方で保存されます。また、ユーザーは、ページ・レベルの通貨切替機能を使用して、販売予測UIにすべての通貨値をどの通貨で表示するかを選択できます。

商談管理の収益明細項目の収益金額は入力通貨が異なる可能性があるため、テリトリのクローズ済収益およびパイプラインの収益金額を集計する前に、入力通貨を企業通貨に換算する必要があります。

これらのメトリックは、販売予測ワークベンチにのみ表示できることに注意してください。

収益明細と商談の受注確度との同期化: 例

受注確度のパーセントを商談レベルで変更すると、すでに同期化している収益明細が自動的に再同期されます。

シナリオ

次に例を示します。

• 商談の受注確度: 50%

• 収益項目1の受注確度: 50%

• 収益項目2の受注確度: 50%

• 収益項目3の受注確度: 40%

収益項目1と収益項目2は商談レベルの受注確度とすでに同期化しているため、商談の受注確度を60%に変更すると、収益項目1と収益項目2の受注確度は60%に変更されます。

収益項目3は商談レベルの受注確度と同期化していないため、収益項目3の受注確度はそのままです。

また、予測条件に応じて、受注確度が変更された後に項目が予測に含まれる場合と除外される場合があることに注意してください。

商談要約収益: 計算方法

要約収益は、商談ヘッダー・レベルの合計収益金額です。

要約収益に影響を与える設定

Oracle Fusion Opportunity Managementでは、ステータス・カテゴリが商談のステータス・カテゴリと同じ収益明細のみを合計して要約収益が計算されます。要約収益の小計も、商談とその収益明細のステータス・カテゴリに基づいて計算されます。要約収益の小計は、常に商談収益合計と等しくなります。

商談属性と収益明細属性の同期化動作: 説明

商談ステータスと収益（明細）ステータスはそれぞれ個別のエンティティですが、Oracle Fusion Opportunity Managementでは、特定の動作に基づいて、これら2つのエンティティのステータスが自動的に同期化されます。

別の商談属性と収益明細属性の変更による商談属性の変更

営業担当の利便性や商談収益データの正確性を向上させるために、商談と収益明細で共有する一部の属性では特殊な相関動作が発生するため、ある商談属性または収益明細属性を更新すると、別の商談属性または収益明細属性が更新される場合があります。特殊な相関動作が発生する共通属性は次のとおりです。

• 受注確度

• クローズ日

• 「予測に含む」設定

• ステータス

• 受注/失注事由

• 競合相手

同期化している商談属性と収益明細属性の更新

商談と収益明細の共通属性で発生する特殊な相関動作のタイプの1つとして、同期化している収益明細属性への商談属性の更新の伝播があります。商談と収益明細の値が同じで、収益明細のステータス・カテゴリがその商談のステータス・カテゴリと同じ場合、商談と収益明細の共通属性は同期化しているとみなされます。収益明細は、属性に関してその商談と同期化しているとみなされます。

商談属性を更新すると、収益明細が属性に関して同期化しているすべての商談収益明細に同じ属性更新が伝播されます。たとえば、オープン商談にある4つのオープン収益明細の内、3つの収益明細のクローズ日が商談と同じ場合は、商談のクローズ日を更新すると、同期化している3つの収益明細のクローズ日が更新されます。

商談から同期化している収益明細への更新の伝播は、次の商談属性に適用されます。

• 受注確度

• クローズ日

• 「予測に含む」設定

• ステータス（ステータス・カテゴリではありません）

たとえば、商談の受注確度を更新すると、「受注確度」属性に関して同期化しているすべての商談収益明細（つまり、収益明細の受注確度の元の値が更新前の商談と同じで、ステータス・カテゴリが商談と同じ）の受注確度に同じ更新が伝播されます。商談属性と収益明細属性の更新の同期化は、次の場合に適用されます。

• すべてのステータスおよびステータス・カテゴリの商談

• 通常の商談の編集フロー処理および商談クローズ・フロー処理

• 商談の一括更新処理

商談ステータス属性の更新

商談と収益明細の共通属性で発生する特殊な相関動作の別のタイプとして、商談ステータスの更新、およびその更新によって他の商談属性と収益明細属性に発生する二次的動作があります。商談ステータスの更新によって、次のような二次的動作が発生します。

• 同期化している収益明細への商談ステータスの更新の伝播（この項で後述）

• 商談ステータスが「受注済」に更新された場合

  • 商談の受注確度が100%に更新されます。受注確度の更新は、同期化している収益明細に伝播されません。

  • 営業ステージが商談販売方法の最後のステージに更新されます。

• 商談ステータスが「失注済」または「販売なし」に更新された場合

  • 商談クローズ日が現在の日付に更新されます。クローズ日の更新は、同期化している収益明細に伝播されません。

• 商談ステータスが「オープン」ステータスから「クローズ済」ステータスに更新された場合

  • 商談の「受注/失注事由」属性が使用可能になります。

  • 商談の編集フローおよび商談の一括更新フローの場合のみ

    • 商談のプライマリ競合相手が定義されている場合は、「競合相手」属性が定義されていないすべての商談収益明細について、収益明細の競合相手が商談のプライマリ競合相手に更新されます。

    • 競合相手に関連する収益明細の更新動作は、商談の編集フローおよび収益明細の一括更新フローには適用されません。

• 商談ステータスが「クローズ済」ステータスから「オープン」ステータスに更新された場合

  • 商談の「受注/失注事由」属性が使用不可になります。

  • 商談の「受注/失注事由」属性が未定義に更新されます。受注/失注事由の更新は、同期化している収益明細に伝播されません。

収益明細ステータス属性の更新

収益明細ステータスの更新によって、他の収益明細属性に次のような二次的動作が発生します。

• 収益明細ステータスが「受注済」ステータスに更新された場合: 収益明細の受注確度が100%に更新されます。

• 収益明細ステータスが「失注済」または「販売なし」ステータスに更新された場合: 収益明細クローズ日が現在の日付に更新されます。

• 収益明細ステータスが「クローズ済」ステータスに更新された場合: 収益明細の「受注/失注事由」属性が使用可能になります。

• 収益明細ステータスが「オープン」ステータスに更新された場合

  • 収益明細の「受注/失注事由」属性が使用不可になります。

  • 収益明細の「受注/失注事由」属性が未定義に更新されます。

商談の「受注/失注事由」属性の更新

商談と収益明細の共通属性で発生する特殊な相関動作の別のタイプとして、商談の受注/失注事由の更新があります。

商談が「オープン」ステータスの場合、商談の「受注/失注事由」属性は使用不可になります。

商談の受注/失注事由に対する更新は、「受注/失注事由」属性が同期化しているすべての商談収益項目に伝播されます。

「受注/失注事由」属性の同期化とは、次の状態を意味します。

• 収益項目の受注/失注事由の元の値が更新前の商談と同じです。

• 収益明細とその商談の両方で値が未定義の場合、収益明細とその商談は同じ値であるとみなされます。

• 収益明細のステータス・カテゴリがその商談と同じです。

これらは、商談クローズ・フローおよび商談の一括更新フローにのみ適用されます。商談の編集フローおよび収益明細の一括更新フローには適用されません。

収益明細の「受注/失注事由」属性の更新

収益明細が「オープン」ステータスの場合、収益明細の「受注/失注事由」属性は使用不可になります。

商談と収益明細の「競合相手」属性の更新

商談と収益明細の共通属性で発生する特殊な相関動作の別のタイプとして、商談の競合相手の更新があります。

商談のステータスが「オープン」ステータスから「クローズ済」ステータスに更新され、商談のプライマリ競合相手が定義されている場合、「競合相手」属性が定義されていないすべての商談収益明細について、収益明細の「競合相手」属性が商談のプライマリ競合相手に更新されます。

1つ以上の「クローズ済」ステータスの収益明細がある商談を保存するときは、収益明細の「競合相手」属性が定義されていないために検証チェックが失敗する場合があります。この理由で商談保存の検証が失敗したときに、商談のプライマリ競合相手が定義されている場合は、エラー・ダイアログが表示され、「競合相手」属性が定義されていないすべての収益明細に商談のプライマリ競合相手をコピーして、この検証の失敗を修正するオプションが示されます。この動作は、商談の編集フローと商談クローズ・フローの両方に適用されます。この動作は、商談の一括更新フローと収益明細の一括更新フローには適用されません。収益明細の必須の「競合相手」属性が欠落しているために検証が失敗すると、検証の失敗を修正する方法がないことを示すエラー・メッセージが表示されます。

販売収益の管理に関するよくある質問

販売実績受取者はどのようにしてロックしますか。

販売実績を割り当てるときは、明細で対応する「ロック所有者」チェック・ボックスを設定して、収益明細の販売実績受取者をロックできます。これによって、実績受取者のデフォルト設定のロジック実行時に、受取者が自動的に置換されるのを防ぎます。通常、受取者が販売実績に対して適格な予測テリトリの1つの所有者またはメンバーである場合、ロックは不要です。ただし、アドホック受取者またはテリトリ・ベースでない受取者（パートナ・リソースなど）は、実績受取者として削除されるのを防ぐためにロックすることを検討してください。

商談パートナの管理

商談のパートナ: 説明

Oracle Fusion Opportunity Managementのパートナ管理によって、当該会社は提携を利用して成長戦略や拡大戦略を早期に実現でき、拡大したテリトリ・カバレッジから売上を最大限に伸ばすことができます。

商談管理のパートナ関係機能は、ビジネス上の次の利点に重点を置いています。

• 直属の営業担当とパートナが1つのチームとして協調して業務を行い、情報を効率的に共有できます。

• パートナの進捗を量的に測定できるため、パートナの参加に基づいて公平に報酬を支払うことができます。

• ブランド所有者は、パートナ商談からの収益をより正確に予測できます。

営業担当は、商談管理を使用して、パートナを商談および収益明細に追加できます。アプリケーションのパートナ・ユーザーは、商談を受注するために、個別に、または内部営業チーム・メンバーとともに業務を行うことができます。

パートナを商談に追加する方法

通常、パートナは次のいずれかの方法で商談に参加します。

• パートナが登録した引合が商談に変換された場合: この場合、パートナは、ブランド所有者の営業担当自動化システムに引合を登録します。内部リソース（通常はチャネル・マネージャ）が登録済引合を承認すると、その登録済引合に基づいて商談が作成されます。これによって、登録済引合のパートナは商談に参加できます。

• パートナが内部商談に追加された場合: この場合、内部商談は、直属の営業担当が作成するか、引合から商談への変換で作成するか、またはその他の方法で作成します。パートナは販売プロセスに参加するとき、手動で商談に追加されます。

サポートされているパートナ機能

商談管理では、様々なシナリオを識別し、チーム割当や実績割当に関する適切な処理を実行できます。次に、サポートされている高度な機能を示します。

• 商談への、直属の営業担当およびチャネル・マネージャの自動テリトリ割当。

• 商談への、協力相手となるパートナの手動割当。

• ベンダー予測収益の連結（たとえば、パートナと直属の営業担当）予測に対するサポート。

• テリトリの予測には、そのテリトリのディメンション境界内にあるすべての収益項目のみが含まれます。

• チャネル営業によってパートナ商談の収益外予測を発行し、そのチャネル営業のクオータと比較できます。

• テリトリ管理の分析では、収益明細レベルで販売チャネルを取得して、直接収益と間接収益を区別できます。

• パートナが生成してクローズを支援する収益商談へのパートナ関係による貢献の追跡。

• パートナ販売チャネルからソースとして指定された引合は、直属の営業担当に割り当てられません。

重複商談の検索: 説明

パートナは、ディールを追跡する独占権を要求するために引合を登録します。引合の資格を取得して登録した後、パートナ・ユーザーはその引合をレビューのためにチャネル・マネージャに発行します。チャネル・マネージャは、チャネルの競合を最小限にするために、引合が重複していないことを確認します。

重複商談の検索

引合UIにある重複商談の検索機能を使用して、一致している可能性があるオープン商談を検索します。販売アカウント名、担当者名、製品グループ、製品などの検索基準を組み合せて使用できます。

検索動作

すべての検索フィールドでワイルドカードがサポートされています。さらに、製品グループが指定されている場合、検索では、製品階層内に指定の製品グループの下位または上位の製品グループがある商談も照合されます。同様に、製品項目が指定されている場合、検索では、その項目が含まれる製品グループがある商談も照合されます。パフォーマンス上の理由から、検索は、販売アカウント名、製品グループ、項目（または、ワイルドカードを使用した名前の一部）のいずれかを指定してから実行する必要があります。

商談のパートナ引合属性: 説明

引合は、パートナ引合登録が承認された後で商談に変換されます。変換プロセスでは、新しく作成された商談に引合属性（販売アカウント、製品、収益金額、プライマリ・パートナ担当者、登録タイプなど）が継承されます。この項では、引合管理アプリケーションと商談管理アプリケーションの間におけるこれらの属性のマッピングについて説明します。一部の属性のみがパートナ引合変換に固有の属性で、ほとんどの属性は引合から商談への標準的な変換にも適用されます。

次の表に、ヘッダー（商談）レベルで商談に継承される一般的な引合属性のマッピングを示します。

次の表に、引合担当者属性から商談担当者属性へのマッピングを示します。

次の表に、引合製品属性から商談収益明細属性へのマッピングを示します。

商談パートナの管理に関するよくある質問

パートナを収益明細に追加できないのはなぜですか。

パートナを「収益項目」リージョンで選択可能にするには、最初にパートナを商談ヘッダー・レベルで関連付ける必要があります。収益表で選択可能なパートナのリストは、商談レベルですでに追加されているパートナに制限されます。

パートナ・リソースを商談チームに追加できないのはなぜですか。

パートナ・リソースをチームに追加するには、最初にパートナを商談ヘッダー・レベルで関連付ける必要があります。商談チームに対して選択可能なリソースのリストには、組織が商談に関連付けられているすべての内部リソースとパートナ・リソースが含まれています。

前へ

次へ

Copyright ©  2011-2012, Oracle and/or its affiliates. All rights reserved. 法律上の注意点

目次