11g リリース1（11.1.4）
B69964-01
目次
|
Oracle Fusion Applicationsセールス・ガイド 11g リリース1（11.1.4） B69964-01 |
目次 |
 前へ |  次へ |
この章の内容は次のとおりです。
テリトリは、一連の販売アカウント全体に対して営業担当の職責の管轄を定義するために使用されます。営業マネージャは、テリトリ提案を使用してテリトリ定義を変更します。マネージャは、複数の提案を作成し、メトリックとグラフを使用して、提案したテリトリを妥当性、効果および配置について現在の販売目標と比較して分析します。次に、マネージャは最良のテリトリ提案をアクティブ化します。
この図は、テリトリを追加、変更および削除するためのテリトリ提案の使用を示しています。分析後、マネージャは最終テリトリ提案をアクティブ化します。
テリトリには、アクティブであるか、テリトリ提案の一部であるかに関係なく、いくつかの要素が含まれています。地理などの1つ以上のディメンションにより、選択したディメンション・メンバー（ヨーロッパやアジアなど）に従ってテリトリの境界が定義されます。すべてのテリトリには所有者が割り当てられるため、追加のテリトリ・チーム・メンバーを設定できます。
この図は、ディメンション・メンバーが異なる2つの同じディメンション使用して定義された2つのテリトリを示しています。各テリトリには所有者と営業チームが設定されています。
ディメンションは、テリトリの管轄の境界を定義する属性です。たとえば、地理ディメンションは、国または郵便番号でテリトリを定義するために使用できます。テリトリ・ディメンションは、販売アカウント、パートナ、引合および商談を正しいテリトリに割り当てるために使用されます。
各テリトリ定義は、割り当てられているオブジェクトの属性と照合されます。製品および販売チャネル・ディメンションは、引合と商談の属性と直接照合されます。残りのディメンションは、テリトリへの販売アカウントの割当時またはテリトリへの引合と商談の割当時に販売アカウントの属性と照合され、この場合は、トランザクションに対する販売アカウントが使用されます。すべてのディメンション値が結合されて、テリトリ境界が定義されます。たとえば、地理が米国で製品がGreen Serversの場合、テリトリ境界は米国AND Green Serversです。
テリトリの定義に使用できるディメンションは、次のとおりです。
アカウント
アカウント・タイプ
「指定」または「指定なし」
顧客規模
組織規模参照から取得
地理
産業
組織タイプ
組織タイプ階層は、顧客分類モジュールから取得されます。
パートナ
製品
販売カタログからの階層。引合と商談の割当に使用されますが、アカウントには使用されません。
販売チャネル
引合と商談の割当に使用されますが、アカウントには使用されません。
補助1、2、3
管理者は、テリトリを定義するために組織で使用するディメンションを使用可能にします。管理者は、テリトリ・ディメンションの定義時に、選択リストに表示するディメンション・メンバーも選択します。非表示のディメンション・メンバーはすべて、選択リストの「その他」カテゴリに表示されます。「未指定」ディメンション・メンバーは、照合値が不十分なオブジェクトを取得します。
ディメンション・メンバーは、ソース・データとの同期を介して移入されます。たとえば、製品は、製品カタログから同期します。ソース・データへの変更は、その変更がテリトリ・ディメンション・メンバーと同期化された後で、販売アカウント、引合および商談の割当に影響を与える場合があります。たとえば、「指定なし」と指定されていた販売アカウントが指定アカウントに変更された場合、または製品ラインが販売カタログから削除された場合などです。したがって、ディメンション変更の同期化後は、引合、商談およびアカウントに対して、完全な再割当処理を実行することをお薦めします。
販売アカウントとその階層は、Oracle Fusion Customer Centerアプリケーションで保守されます。
販売アカウントは、使用目的「販売アカウント」、およびパーティ固有の販売情報を含む販売アカウント・プロファイルを備えたパーティです。パーティに販売先所在地が1つある場合、そのパーティは販売見込み客ではなくなり、新規販売アカウントになります。パーティが何かを購入すると、そのパーティは新規販売アカウントから既存の販売アカウントに変わります。テリトリを定義するときは、通常のカバレッジに設定された境界と一致しない場合でも、テリトリに含める個々のアカウントを選択できます。また、該当するテリトリに対する通常のカバレッジ内のディメンション選択を満たす場合でも、テリトリから除外する個々のアカウントを選択できます。包含または除外の選択に、販売アカウントに対する階層は含まれません。
アカウントを、テリトリ定義に対する通常のカバレッジでアカウント・ディメンションを使用して指定アカウントとして選択するには、その前に、顧客センターで「指定」として指定する必要があります。テリトリを定義するときは、該当する階層に対する他のディメンション定義内に含まれる指定アカウントを選択できます。また、他のディメンション定義内に含まれていない指定アカウントでも、そのアカウントが、顧客階層で他のディメンション定義内に含まれている選択した指定アカウントより上位である場合は選択できます。
管理者は、次の選択肢を使用してアカウント・ディメンションを使用可能にできます。
通常のカバレッジ内の指定アカウントと選択した販売アカウントの包含および除外の両方を使用可能にします。
包含および除外に対する個々の販売アカウントの選択に対してのみ使用可能にします。指定アカウントは、通常のカバレッジでは使用できません。
アカウント・ディメンションを使用不可にして、通常のカバレッジでの指定アカウントの使用も、包含または除外に対する販売アカウントの使用もできないようにします。
地理は、地上に境界が設定された物理領域として定義されます。
地理タイプは、地理の分割グループ化であり、2つのタイプのいずれかです。
マスター: 世界中のすべての国において、番地が設定されているFusion内のレコードまたはオブジェクトでは、その所在地を定義するためにマスター参照地理タイプが使用されます。マスター参照地理データはアプリケーションにインポートされ、手動で設定されません。このインポート処理は、Oracle Fusion CRMクラウド・サービスを使用している場合は自動的に実行される場合があります。実行されない場合は、設定および保守の「ファイル・インポート・アクティビティの管理」設定タスクを使用してアプリケーションにインポートできます。
ゾーン: 便利なカスタマイズされた地理のグループ化。たとえば、いくつかの州を「北西」というゾーンにグループ化できます。ゾーンは手動で定義して作成する必要があるためオプションです。これらは、テリトリ管理以外の他のFusionアプリケーションでは使用されず、営業テリトリの境界が厳密にマスター地理体系に従っていない場合（つまり、地域的で国固有の正式な体系外である場合。たとえば、米国の場合は州-郡-市-郵便番号と異なる場合）は、ゾーンのみを使用して営業テリトリを定義します。
ゾーンはユーザー定義であるため、解釈が必要です。これらを使用するには、定義に対する会社全体の合意が必要です。これは、すべてのビジネス・ユニット、および同じアカウントに販売するすべての取扱商品全体にわたることを意味します。
マスター地理と組み合せたゾーンは、階層に体系化されます。テリトリ地理の管理を使用したテリトリ階層の設定は、ゾーンを階層に含めるかどうかに関係なく、地理ディメンションを使用可能にするための前提条件です。
産業階層は、顧客分類モジュールから取得されます。
産業ディメンションを使用可能にするには、「産業分類カテゴリ」プロファイル・オプションを、ディメンションのベースとして使用する分類カテゴリに設定する必要があります。使用可能な選択に含まれるのは、産業カテゴリ・グループに属する分類カテゴリのみです。
パートナは、パートナ・プロファイルが関連付けられ、「パートナ」使用目的が割り当てられた組織パーティです。パートナはパートナ・センターで定義されます。パートナ中心のテリトリの定義に含める個々のパートナを選択できます。パートナ中心のテリトリ・カバレッジから除外する個々のパートナを選択することもできます。
管理者は、手動による包含および除外に対してパートナ・ディメンションを使用可能にできます。パートナ・ディメンションは通常のカバレッジには使用できません。
販売チャネル・ディメンションでは、チャネル・パートナを介した間接販売がサポートされます。使用可能な他のディメンションに加え、販売チャネル・ディメンションによって体系化されたパートナ固有のテリトリを作成できます。使用可能な販売チャネルは、直接、間接およびパートナです。販売チャネル・ディメンションは引合と商談に適用されますが、販売アカウントには適用されません。
補助ディメンションは、顧客分類モデルに基づいて3つまで定義できます。分類カテゴリを最初に定義し、顧客カテゴリ・グループに関連付けます。
補助ディメンションを使用可能にするには、次の手順を実行する必要があります。
「分類カテゴリの管理」タスクを使用して、新規分類カテゴリを作成します。親コード割当を許可できます。複数区分コード割当を許可する場合は、顧客レコードで「プライマリ」と指定されている分類が、顧客をテリトリに割り当てるために照合される分類です。
新規カテゴリに対して分類コードを追加します。階層は、コードありまたはコードなしで作成できます。
「分類グループの管理」タスクを使用して、CUSTOMER_GROUPカテゴリ・グループ・コードを検索します。グループを編集し、新規分類カテゴリをグループに追加します。
設定タスク「補助ディメンション1（あるいは2または3）の分類カテゴリの定義」を使用して、いずれかのプロファイル・オプションの値を、作成した分類カテゴリを指すように変更します。この結果、この分類カテゴリは、補助ディメンションに対するディメンション・メンバーのソースになります。
テリトリ提案は、テリトリの変更をモデル化するために使用されるコンテナです。営業責任者およびマネージャは、テリトリ提案を使用して、テリトリを分割する様々な方法をモデル化し、アクティブなテリトリ定義に影響を与えずに結果を表示して、モデルの結果が適切であると判断した場合はテリトリ提案をアクティブ化します。
テリトリ定義は、引合、商談収益項目、販売アカウントなどの作業オブジェクトにテリトリを割り当てるために使用されます。通常は、提案の一部として定義およびアクティブ化された変更によって、新しい通常のカバレッジ定義に基づいてこれらの作業オブジェクトが再割当されます。
注意
提案のアクティブ化によって影響を受けるテリトリの自動再割当をオフにするには、「影響を受けたテリトリの識別使用可能」プロファイル・オプションを、設定および保守タスクの「部分再割当を使用可能にするかどうかを定義」を使用して「いいえ」に設定します。この場合、割当が発生するのは、割当プロセスの実行がスケジュールされるか、手動で起動されたときのみです。
次に、テリトリ提案で実行できる処理を示します。
提案の作成およびアクティブ化日の設定。
カバレッジおよびテリトリ・チームも含めた、テリトリ提案におけるテリトリの定義。
テリトリ継承の定義。
継承受取を更新するプロセスの開始。
別の営業マネージャが所有しているテリトリ階層に対するテリトリ定義の作成または変更。営業管理者は、集中型テリトリ管理モデルでこれらの処理を実行します。
提案内のテリトリをこれらの所有者と共有または公開。営業マネージャは、分散型テリトリ管理モデルでこれらの処理を実行します。この結果、子テリトリの所有者は、自分の子テリトリに必要な変更を反映できます。
必要な変更を実行し、提案を公開したマネージャに提案を発行。
所有者不在時の子テリトリに対する変更による提案の更新。親テリトリ所有者は、不在所有者の部下に変更を公開します。
提案で指定された定義以外の定義（アクティブ定義または履歴定義）へのテリトリの復元。
無効なディメンション・メンバー、ギャップおよび重複をチェックするための提案済テリトリの検証。
メトリックおよびグラフのレビューによる、各テリトリ内のアカウント数や営業商談数などに対する提案の分析。
提案済テリトリに対するアカウント、収益および引合の割当のプレビュー。
提案のアクティブ化。提案は、該当する日付に達するまではアクティブ化保留中ステータスのままです。
提案を更新する必要がある場合のアクティブ化保留中提案の再オープン。
次に、テリトリ提案で従うルールを示します。
テリトリに対してアクティブにできる定義は一度に1つのみです。
新規テリトリの作成または既存テリトリの更新には、テリトリ提案を使用する必要があります。
提案内のテリトリは、アクティブなテリトリ定義に影響を与えることなく自由に作成、編集および削除できます。
親テリトリの所有者は、提案に対するアクセス権がある場合、部下のテリトリに対する変更によって提案を更新できます。
特定のテリトリが2つの異なる提案で更新され、両方の提案がアクティブ化された場合は、最後にアクティブ化された提案の変更によって他の提案の変更が上書きされます。あるテリトリ提案に追加されたテリトリが、アクティブ化された2番目の提案から削除された場合は、最初の提案がアクティブ化されたときに復元されます。
提案に、現在削除されている親テリトリに追加されたテリトリが含まれている場合、新規テリトリは提案のアクティブ化時に削除されます。
テリトリ提案は、そのライフサイクルで様々なステータスを推移します。
次に、提案ステータスの説明を示します。
|
ステータス |
説明 |
|---|---|
|
ドラフト |
提案が初めて作成され、様々なユーザーがその子テリトリの変更に参加できます。または、管理者がテリトリを履歴定義に復元し、システムでは必要なすべてのテリトリの提案への追加が完了しています。 |
|
アクティブ化保留中 |
所有者が提案のアクティブ化を要求します。提案は、アクティブ化日までアクティブ化保留中ステータスです。 |
|
アクティブ化 |
所有者がアクティブ化を要求し、アクティブ化日に達した後、無効なテリトリがない場合は、提案がアクティブ化され、テリトリがアクティブになります。 |
|
処理中 |
階層を履歴定義に復元すると、提案に必要な変更を識別するプロセスが起動します。 |
|
失敗 |
この提案の一部としてテリトリに加えられた変更は適用されません。 |
ユーザーは、公開/取消処理を使用して、提案済子テリトリの所有者による提案への参加を希望するかどうかを示すことができます。子テリトリの所有者は、提案を再発行することによって、そのテリトリへの変更に対する評価が終了したかどうかを示すことができます。次のテリトリ・ステータスは、提案が各テリトリ所有者と共有されたかどうかを示します。
未公開: テリトリが提案内に初めて作成または編集され、そのテリトリの提案済所有者には公開されていません。
公開済: マネージャが、テリトリの提案済所有者とテリトリの変更を共有するために提案を公開しました。
発行済: 提案済テリトリ所有者は、テリトリ変更のレビューを完了し、提案をマネージャに発行します。
テリトリ・カバレッジは、テリトリに何を含めるかまたは何を除外するか、および何を販売できるかを定義する一連の関連ディメンションです。たとえば、製品および地理ディメンションは、北米でラップトップを販売するためのテリトリ・カバレッジを作成するために使用可能にできます。
3つのタイプのカバレッジがあります。
通常のカバレッジ: 1つ以上のテリトリ・ディメンションの組合せ。
包含カバレッジ: 包含販売アカウントまたはパートナのリスト。製品およびチャネル・ディメンションに特定の値を設定でき、他のすべてのディメンションは無視されます。アカウント階層は無視されます。販売アカウントは、包含に追加するために顧客センターで指定アカウントとして指定する必要はありません。製品およびチャネルの選択は、親テリトリの管轄内である必要があります。
除外カバレッジ: 除外販売アカウントまたはパートナのリスト。すべてのディメンションが無視されます。アカウント階層は無視されます。販売アカウントは、顧客センターで指定アカウントとして指定する必要はありません。
テリトリ提案をアクティブ化すると、通常のカバレッジの変更によって影響を受けるテリトリに対して、販売アカウント、引合および商談の収益明細の再割当が発生します。手動の包含および除外に対する変更の場合は、完全な再割当処理が必要です。
パートナは、パートナ・プロファイルが関連付けられ、「パートナ」使用目的が割り当てられた組織パーティです。
直接販売と同様に、チャネル・マネージャには、営業活動に関連する管轄を定義する、対応する営業テリトリがあります。一部のチャネル・マネージャは、特定のパートナに割り当てられます。また、一部のチャネル・マネージャは、パートナを伴う営業活動を管理および監視するために割り当てられます。チャネル・マネージャ・テリトリの管轄は、通常、次の1つ以上のカバレッジ・モデルによって定義されます。
最終顧客の特性によって定義されるカバレッジ
このカバレッジ・モデルでは、チャネル・マネージャの管轄は、トランザクションに関連付けられているパートナに関係なく、単に最終顧客の特性に基づいて定義されます。例として、チャネル・マネージャは、最終顧客がカリフォルニアにいるすべての間接商談をカバーするために割り当てられる場合があります。このカバレッジに対するテリトリは、販売アカウント特性を使用して定義し、特定の販売アカウントを包含または除外できます。
パートナの特性によって定義されるカバレッジ
このカバレッジ・モデルでは、チャネル・マネージャの管轄は、パートナの所在地またはタイプ（再販者、システム・インテグレータ、販売業者）など、パートナの一部の特性に基づいて定義されます。例として、チャネル・マネージャは、パートナがカリフォルニアにいるすべての間接商談をカバーするために割り当てられる場合があります。
このテリトリを定義するには、カバレッジ・モデルを販売アカウント中心ではなくパートナ中心に指定します。パートナ中心モデルでは、通常のカバレッジは、パートナ組織の次の属性を使用して定義されます。
パートナのプライマリ地域
パートナの組織タイプ（非公開、公開、政府所有、非営利）
パートナがサービスを提供する産業（ハイテク、製造、銀行、医薬）
パートナの規模
パートナ・オブジェクトに対して定義される、顧客カテゴリ分類モデルに基づいた3つの補助ディメンション
非パートナ・モデルは、製品および販売チャネル・ディメンションを使用して、販売トランザクション（引合および商談）からの属性を照合することもできます。
手動で包含されたパートナによって定義されるカバレッジ
このカバレッジ・モデルでは、チャネル・マネージャの管轄は、そのテリトリに直接割り当てられているパートナの明示的なリストに基づいて定義されます。例として、チャネル・マネージャは、AA Solutionsという名前のパートナに割り当てられます。このチャネル・マネージャのテリトリは、AA Solutionsがパートナであるすべての間接商談に割り当てる必要があります。パートナはパートナ・センターで定義されます。パートナ中心のテリトリの定義に含める個々のパートナを選択できます。パートナ中心のテリトリ・カバレッジから除外する個々のパートナを選択することもできます。
この管轄は、製品および販売チャネルによって追加でフィルタ処理されます。
テリトリ提案をアクティブ化したり、ステージ環境で「ステージおよび昇格」処理を実行してディメンション・メンバーを同期化すると、その処理は検証なしで実行されるため、無効なアクティブ・テリトリで終了する場合があります。検証を実行するには、テリトリ提案内から「テリトリの検証」処理を要求します。検証プロセスでは、提案とアクティブなテリトリの両方で、無効なテリトリおよび無効なディメンションが警告アイコンで識別されます。「次の無効」処理を使用して、次の無効なテリトリに移動します。
テリトリが無効になる方法は2通りあります。
テリトリまたはその子のいずれかに、削除されたディメンション・メンバーが含まれている場合。次に例を示します。
管理者が、ディメンション・メンバーが含まれていないソース・データと同期化した場合（例: 製品グループが製品カタログから削除された場合）。
削除されたディメンション・メンバーを含むアクティブな製品テリトリは、そのディメンション・メンバーがテリトリから削除されるまで無効です。
管理者がアクティブなテリトリで参照されているディメンションを使用不可にした場合。たとえば、顧客規模ディメンションによって定義されたテリトリは、顧客規模を使用不可にすると無効になります。
管理者がアクティブなテリトリで参照されているディメンション・メンバーを非表示にした場合。
テリトリは、境界がその親テリトリの境界を越える場合は無効になります。次に例を示します。
親テリトリからディメンション・メンバーを削除した場合。
親テリトリから削除されたディメンション・メンバーを含む子テリトリは、そのディメンション・メンバーが子テリトリからも削除されるまで無効です。たとえば、親および子テリトリに、顧客規模に対して「小」、「中」および「大」という定義が含まれているとします。親の定義を顧客規模「小」および「中」に変更した場合、子テリトリの定義からも「大」を削除するまで子は無効です。
管理者がディメンション・メンバーをディメンション階層の別の場所に移動した場合。たとえば、製品または製品グループを製品カタログ内の別の場所に移動した場合です。変更した階層内のディメンション・メンバーが含まれていたアクティブな子テリトリは、その親テリトリの定義内にはすでに存在しません。
親の境界を越える子テリトリを意図的に設定できるように、特定のテリトリに対する補助的な検証はオフにできます。これを実行するには、テリトリを編集して、「オプション検証の適用」を「いいえ」に設定します。この結果、検証では、テリトリがその親より大きいかどうか、テリトリにそのテリトリより大きい子が含まれているかどうかはチェックされません。
次に、オプション検証を使用する場合の例を示します。
チャネル・マネージャのテリトリ境界は西部リージョンの主要な職責を反映しているが、そのマネージャの職責下にあるパートナの一部は定義したリージョン外にあり、チャネル・マネージャのテリトリに対するオプション検証を使用不可にします。
営業マネージャは、通常以外の境界が設定されているテリトリを担当している何人かの営業担当を管理しています。営業マネージャの主要な管轄をカバーするようにマネージャのテリトリをモデル化して、オプション検証を使用不可にします。
メトリック情報は、削除されたディメンション・メンバーが原因で無効になっているテリトリに対しては使用できません。ギャップおよび重複レポートでは、テリトリ検証が実行され、テリトリが無効な場合は表示されません。親より大きい子を含むテリトリがレポートに表示されるのは、これらのテリトリに対するオプション検証がオフの場合です。
営業管理者は、テリトリを定義するために組織で必要なディメンションのみを使用可能にします。次の例は、定義されたテリトリを使用して、販売アカウント、引合および商談を正しい営業担当に割り当てるための様々なディメンションの使用を示しています。
ほとんどの営業活動については、市および郵便番号によって営業担当を割り当てます。
上位の営業担当が担当する必要がある得意先がいくつかあります。アカウント・ディメンションを使用して、個々の販売アカウントに対するテリトリを作成します。
主な販売アカウントを指定アカウント・テリトリに割り当てます。指定アカウント・テリトリには、地理などの他の条件によって識別される子テリトリを設定できます。また、階層内に主な指定販売アカウントを含まない、「指定なし」アカウント・タイプのテリトリも設定します。
ある製品ラインは、特定の規模を超える組織にのみ適しています。製品ラインに対して比較的規模の大きい顧客のみをターゲットとするには、顧客規模ディメンションを使用します。
あるタイプのサービスは通信会社に、別のサービスは公益事業に、3番目のサービスは保険会社に販売しています。産業ディメンションを使用すると、それぞれに対するテリトリを作成できます。
営業担当に高度な技術知識が必要な製品ラインを販売しています。この製品ラインに対しては別のテリトリを作成します。
規模の小さい販売アカウントは地理別にパートナ販売組織に委任します。
営業テリトリを分割する最も簡単な方法は、地理別です。次に、地理別にテリトリを割り当てる例を示します。
小規模な営業チームがあり、電話を使用して世界中に製品を販売しています。すべての営業担当には、すべての顧客にすべての製品を販売するための専門知識があります。テリトリを国別に定義することを選択します。米国内の顧客は1人の営業担当には多すぎるため、国に対しては1つの親テリトリがある異なる州別のテリトリを作成します。
会社では主に、北米およびヨーロッパのいくつかの主要都市にある会社を現地訪問することによって販売しています。都市の顧客にサービスを十分に提供するには、各都市に複数の営業担当を割り当てる必要があります。郵便番号別に定義され、国別に定義された親テリトリで階層が作成されたテリトリを作成することを選択します。割り当てた郵便番号内に含まれない場所にある販売アカウントは、親の国テリトリに割り当てられます。
次のシナリオでは、様々なディメンションの組合せを使用してテリトリの新規階層を定義する例を示します。
会社のテレスコープ部門では、特別なタイプの顕微鏡および関連アクセサリと消耗品を製造し、販売しています。現在は主に、米国中の医学研究所に販売し、他の産業への販売も少しあります。会社では最近、東部にある2つの大規模な総合大学といくつかの単科大学に顕微鏡の供給を開始しました。経営者は、この産業に何人かの営業担当を専任させ、総合大学を指定アカウントとして識別して、この新しい市場の拡大に重点を置こうとしています。
次の図は、部門に対する現在のテリトリ階層を示しており、部門は米国の東部と西部に分割され、米国内であると識別されていないアカウントを捕捉するための親テリトリがあります。会社のテレスコープ部門に対するすべてのテリトリの定義には、製品グループであるテレスコープ、アクセサリおよび消耗品が含まれています。
テレスコープの販売には、高い知識と経験を備えた営業担当が必要です。したがって、次の図に示すように、各USリージョン内では、テレスコープの販売をアクセサリと消耗品の販売から分離します。これを実行するには、テレスコープ製品に対応したテレスコープ・テリトリ、およびテレスコープ消耗品とアクセサリ製品グループに対応したテレスコープ消耗品テリトリを定義します。
テレスコープ東部テリトリは、次のように定義されます。
地理: 米国東部
製品: テレスコープ
産業: すべて
アカウント・タイプ: すべて
テレスコープ消耗品東部テリトリは、次のように定義されます。
地理: 米国東部
製品: テレスコープ・アクセサリおよび消耗品
産業: すべて
アカウント・タイプ: すべて
次の図に示すように、4年制の単科大学と総合大学、および2年制の単科大学に対して、産業ディメンション・メンバーによって定義された2つの子テリトリを追加します。4年制の単科大学と総合大学テリトリ内で、現在の顧客である2つの総合大学を指定アカウントとして追加すると、それらにサービスを提供するための専任営業担当が設定されます。
単科大学と総合大学東部テリトリは、次のように定義されます。
地理: 米国東部
製品: テレスコープ
産業: 単科大学と総合大学 - 4年制
アカウント・タイプ: すべて
コミュニティ・カレッジ東部テリトリは、次のように定義されます。
地理: 米国東部
製品: テレスコープ
産業: コミュニティ・カレッジ - 2年制
アカウント・タイプ: すべて
各総合大学指定アカウント・テリトリは、次のように定義されます。
地理: 米国東部
製品: テレスコープ
産業: 単科大学と総合大学 - 4年制
アカウント・タイプ: 指定
アカウント: ハーバード（ハーバード・テリトリ用）
アカウント: コーネル（コーネル・テリトリ用）
他の指定アカウントを必要に応じて追加できます。
次の図に示すように、同じ方法で米国西部のテリトリ階層を作成します。販売管理によって、テレスコープを購入していない3つの総合大学が指定アカウントとして指定されました。
テリトリ・カバレッジは、テリトリに対するディメンション値の単一の組合せです。カバレッジには、通常、包含および除外の3つのタイプがあります。通常のカバレッジは、1つ以上のテリトリ・ディメンションの組合せで構成されます。個々の販売アカウントまたはパートナは、通常のカバレッジのディメンション選択に関係なく、テリトリへの包含または除外を選択できます。次のシナリオでは、包含および除外テリトリ・カバレッジを使用する場合の例を示します。
2人の営業担当が、別々の地理領域であるテキサスとカリフォルニアで、指定アカウントを除くすべてのアカウントをカバーしています。Tomはテキサス・テリトリを、Sueはカリフォルニアを所有しています。Sueには、テキサスにあるA1販売アカウントと特別な関連があります。A1は、戦略的アカウントではないため指定アカウントではなく、指定アカウントに変更すると、Fusion内の他の営業チームや他の領域に影響を与えます。解決策は、A1をSueのテリトリに手動包含として追加し、Tomのテリトリには手動除外として追加することです。
営業担当は、10〜20の個別に割り当てられたアカウントに販売しています。通常のカバレッジは定義しませんが、アカウントを包含として手動で割り当てます。
得意先責任管理者が、いくつかの戦略的アカウント（指定アカウント）とそのアカウントのすべての子会社を担当しています。アカウント・ディメンションを使用して通常のカバレッジを定義し、各戦略的アカウントを選択します。さらに、アカウント・タイプ・ディメンションを「すべて」に設定すると、得意先責任管理者が、戦略的アカウントの指定子会社と指定なし子会社の両方に販売することを意味します。
テリトリ継承を使用すると、多数のテリトリ全体にわたってディメンション変更を伝播する作業が軽減されます。1つ以上の受取テリトリが、1つ以上の選択したディメンションを単一のソース・テリトリから継承します。ソース・テリトリに対するディメンション・メンバーの変更は受取テリトリに自動的に渡され、継承している受取テリトリを手動で変更する必要はありません。
ソース・テリトリと受取テリトリには異なるテリトリ所有者を設定でき、異なる階層に配置できます。次の図で、受取テリトリは、ソース・テリトリから3つのディメンションの中の2つを継承し、所有者はソース・テリトリと異なります。
ソース・テリトリ内の継承ディメンションに加えられた変更によって、そのソース・テリトリから継承したすべてのテリトリのディメンションも変更されます。次の図で、ソース・テリトリ内の製品ディメンションは、ラップトップからコンピュータに変更されています。受取テリトリでは、製品コンピュータに自動的に変更されます。
テリトリ提案のテリトリを編集するときは、ソースとして機能する2番目のテリトリを選択し、継承対象のディメンションを1つ以上選択して、提案をアクティブ化します。
受取テリトリは、指定したディメンションのみをソース・テリトリから継承します。ソース・テリトリ内のこれらのディメンションに加えられた変更によって、受取テリトリ内のディメンションも自動的に変更されます。テリトリ定義の自動継承を終了するには、ソース・テリトリを「なし」に変更します。
各テリトリの境界は個別に定義するか、ソース・テリトリからディメンション・メンバーを自動的に継承するようにテリトリを定義できます。ソース・テリトリはいずれの階層内でもかまいません。その後、継承ディメンションに対する手動更新が必要なのはソース・テリトリのみで、受取テリトリはディメンションの変更を継承します。
テリトリ継承の使用には、次の事項が適用されます。
すべての継承ディメンションは、同じソース・テリトリからのディメンションである必要があります。
テリトリBはテリトリAから継承し、そのテリトリBがテリトリCに対するソース・テリトリでもあるというような、テリトリ継承のチェーンは設定できません。
ソース・テリトリが削除されると、受取テリトリに対する自動更新は終了します。
テリトリ・メンバーの継承に加えて、受取テリトリは、ソース・テリトリの「クオータに適格」、「クオータの改訂」、「改訂事由」および「改訂摘要」によって更新されます。
あるソース・テリトリに対してディメンション変更を加え、これらの変更を、ソース・テリトリに対して継承関係がある受取テリトリに自動的に伝播するには、テリトリ継承を使用します。
会社では、包装用の箱を同様の箱を使用する様々な産業に販売しています。次の製品ラインを販売しています。
家庭用電化製品、玩具、ビスケット類および干菓子の製造業者向けの段ボール箱
飲料生産業向けのワックス箱
宝石用の装飾箱
それぞれの営業担当には異なる産業に関する知識があるため、産業ごとに別々のテリトリを定義します。
製品と製品ラインの名前は、製造と材料の変更によって頻繁に変わります。同じ段ボール箱ラインを使用する4つの産業があるため、製品名を更新するためのソース・テリトリに家庭用電化製品テリトリを選択し、他の3つの産業テリトリは製品の変更を継承します。
この図は、家庭用電化製品産業ソース・テリトリと、ソース・テリトリから製品名を継承する他の産業テリトリを示しています。
各産業テリトリは、変更の少ない、完全に同じ地理領域に分割されます。したがって、家庭用電化製品産業に対する地理テリトリをソース・テリトリとして使用し、各産業に対する地理テリトリは、この家庭用電化製品の地理から継承します。
この図は、家庭用電化製品産業の子テリトリから地理ディメンションを継承する、宝石産業テリトリの地理の子テリトリを示しています。
年内に、米国でビジネスを展開するため、テリトリを2つのテリトリに分割する時期です。米国ソース・テリトリを、北米に変更すると、他の産業テリトリに対する米国テリトリはこの変更を継承します。次に、各産業テリトリ階層に対して、中米および南米に対する新規テリトリを追加し、それぞれに継承を設定します。
様々なテリトリが、同じソース・テリトリから同じディメンションまたは異なるディメンションを継承できます。
この図は、製品ディメンションと地理ディメンションの両方の継承を示しています。宝石産業テリトリは地理のみを継承し、玩具産業テリトリは地理と製品の両方を継承します。
設定した目標を提案が達成するかどうかを判断するには、グラフを表示して、提案済テリトリの変更を既存のアクティブ・テリトリと比較します。新規テリトリはより公平で生産的ですか。複数の提案のテリトリ変更を評価したり、単一の提案内で行われたテリトリ変更の結果も確認します。
新しい地理境界による提案済テリトリ・バージョンとアクティブ・バージョンの間で変更された販売アカウントの数がどれくらいかを確認します。テリトリを選択し、現在の四半期に対する顧客数メトリックとバージョン比較、アクティブ・バージョン比較を選択します。提案済テリトリ内の販売アカウントがかなり多いことがわかります。
次に、選択したテリトリのすべての子テリトリを比較し、販売アカウント数に多数の変更があるのが1つの子のみであることを確認し、子テリトリを再編成する必要があると判断します。
テリトリの復元によって、テリトリ定義は特定の日付時点の状態に変更されます。
復元は、選択した日付が過去の日付か現在の日付か、選択したテリトリのみの復元か全テリトリの復元かの選択によって決定されます。
アプリケーションでは、選択した日付時点で次の変更が行われます。
削除されたテリトリは削除前に戻されます。
作成されたテリトリは削除されます。
変更されたテリトリは、以前の定義に戻されます。
復元の選択によって、復元されるテリトリが決まります。
選択復元: 選択したテリトリとその下位テリトリが復元されます。
すべて復元: 表示されているすべてのテリトリとその下位テリトリが復元されます。
現在の日付を選択した場合、テリトリ定義は現在アクティブな定義に復元され、提案内で行われた変更は破棄され、ユーザーは「提案」ページに戻って再度変更を行います。過去の日付を選択した場合は、提案ステータスが「処理中」に変わり、「テリトリ提案の管理」ページに戻ります。提案処理が完了すると、その提案には、選択したテリトリを復元するために必要な変更が含まれます。
営業マネージャは、割当済テリトリとその営業担当に関する知識があるため、テリトリを定義し、テリトリを最も公正に割り当てることができます。営業マネージャは、時間を節約するために、営業管理者にテリトリ定義活動を委任します。セキュリティを使用して、特定のテリトリ階層分岐を営業管理者に割り当てたり、すべてのテリトリに対するアクセス権を営業管理者に付与します。
メトリック値は、選択した1つ以上の期間に基づいて計算されます。
たとえば、2つの異なる年を選択した場合、「クローズ日ごとの」という収益項目メトリックには、クローズ日が2つの年のいずれかに含まれるすべての収益項目が含まれます。「期間終了日における」というメトリックでは、最も最近選択した年の最終日時点の金額が計算されます。平均は、選択した2つの年の情報をすべて使用して計算されます。
取扱商品は、特定の種類の営利事業に対するカテゴリです。テリトリは、そのテリトリに対して1つ以上の取扱商品を選択することによって変更します。たとえば、実装時にソフトウェア会社では、取扱商品に対して製品の広範な分類を使用し、教育、ライセンスおよびコンサルティングを取扱商品の選択リストに追加します。
指定アカウントのテリトリを複数の営業担当に分割するには、指定アカウントのテリトリを親として子テリトリを作成します。たとえば、IBM Corporationに対する販売アカウント階層があるとします。親は、地理をすべてとして定義した指定アカウントIBM Headquartersです。子テリトリは、同じ指定アカウントIBM Headquartersと、北米やEMEAなどの別々の地理を使用して定義します。この結果、北米にあるIBM Corporationのすべての子会社は、北米の子テリトリによってカバーされます。同様に、EMEAリージョンにあるIBM Corporationのすべての子会社は、EMEAの子テリトリによってカバーされます。
特定の日付より後にテリトリ設定に加えられた変更は、復元を使用してすべて元に戻します。テリトリ提案内の個々のテリトリに加えられた変更や、提案をアクティブ化したときにアクティブ化されたテリトリ定義内の変更を元に戻すことができます。
親が同じ2つ以上の子テリトリが、複数ディメンション・メンバーの同じ共通部分を参照している場合は、テリトリが重複しています。
「テリトリの検証」ウィンドウには、重複しているテリトリが同じ親テリトリの子である重複のみがリストされます。たとえば、ディメンション・メンバーのバージニアを含む子テリトリと、ディメンション・メンバーの米国を含む子テリトリは重複しています。
重複は、意図していない場合は問題です。結果として、2人の営業担当に同じ領域が誤って割り当てられた場合は、重複によって競合が発生し、販売クオータが正しく割り当てられません。
意図的な重複は、クオータがある営業担当がカバーしている同じ領域に、追加の営業担当または技術エキスパートを割り当てる場合に有効です。たとえば、同じ領域に、別々のテリトリを担当する4人の営業担当が必要であるが、技術エキスパートは1人のみ必要な場合があります。テリトリの1つにテリトリ・タイプとして「重複」を割り当てることをお薦めします。
テリトリのギャップは、1つのテリトリに属しているが、そのテリトリのいずれの子にも属さないディメンション・メンバーで構成されます。
この図では、親テリトリは顧客の規模で定義され、顧客規模に対して使用可能なディメンション・メンバーは小、中および大です。小規模と中規模の顧客に対する子テリトリはありますが、大規模の顧客に対するテリトリが欠落しており、ギャップが作成されます。
検証ルーチンは、ステージ環境の変更をアクティブ・テリトリと比較し、ステージ環境内のディメンション・メンバーが原因で発生したアクティブ・テリトリの問題を識別します。ステージ環境を実稼働環境に移行するには、生成されたエラー訂正提案を使用して、変更が必要なアクティブ・テリトリを訂正します。
ステージ環境の変更によって無効になるアクティブ・テリトリ・リスト内のすべてのテリトリの横に、「無効」アイコンが表示されます。エラー訂正提案の所有者は、無効なテリトリをエラー訂正提案に追加し、ステージ環境内のディメンション・メンバー変更に対応するように定義を変更する必要があります。たとえば、新たに使用不可にされたディメンションをテリトリから削除します。ステージ環境が実稼働環境に昇格すると、検証プロセスが再度実行され、すべて有効な場合は、エラー訂正提案内のテリトリがアクティブ化されます。
