印刷      PDFバージョンのオンラインヘルプを開く


前のトピック

次のトピック

ブック構造の設計について

効率的なブック構造をセットアップするには、ブック階層を慎重に計画する必要があります。会社のブック階層を設計および編集する際には、次の点に注意してください。

  • ユーザーブックを複製するカスタムブックを作成しない。
  • ビジネスデータに対する組織ポリシーとアクセスポリシーを決定する。
  • 社内構造とデータ管理間に関係があるかどうか判断する。
  • 社内データの関連付けを判断する。
  • ユーザーニーズに基づいてブックを設計し、ユーザーがブックを頻繁に使用するタスクについて検討する。
  • 企業プロファイルで[マネージャ表示が有効]チェックボックスにより提供される機能ができるだけ使用されないようにブックを設計する。
  • ブック階層内のレベル数を最小限にする。
  • できるだけ、ブック構造内のクロスリストの量を少なくする。クロスリストとは、複数のブック間でレコードが複製されることです。
  • ブックの管理を自動化するためにワークフロールールを使用する。また、ブック名を設計する際には、ブック名を解決する式を使用することで、単一のワークフローアクションを使用して異なるブックを異なるレコードに割り当てることができる機能を検討する。

ユーザーブック

ユーザーブックを複製するカスタムブックを作成することで生じる欠点は、カスタムブック内のデータとデフォルトユーザーブック内のデータを同期化しなければならないということです。この余分なタスクにより、サーバー処理時間が増え、レコード取得速度に影響が出ます。

:企業がユーザーブックの複製を検討する理由の1つとして、ユーザーに、別のユーザーのデータへの一時的なアクセスを許可する場合があります。このニーズを満たすためのより適した方法として、別のユーザーのデータにアクセスする必要があるユーザーを、そのデータを所有しているユーザーの委任ユーザーとして追加するという方法があります。

データアクセスのニーズ

ブック構造に、企業の社内階層を反映させる必要はありません。その代わり、ブック構造には、社内でのデータの管理方法を反映することをお勧めします。社内業務は、地域別に管理できるものもあれば、製品ラインまたは業種別に管理できるものもあります。次の場合については、特に注意が必要です。

  • 2つ(またはそれ以上)の部署が互いのデータにアクセスしてはならない
  • 2つ(またはそれ以上)の部署が互いのデータにアクセスできる必要がある

社内構造の関連性

多くの企業において、親組織は、子組織の全データに対して完全なアクセス権を持っています。このような親組織のメンバーは、通常、すべての子組織のデータに対してグローバルなアクセス権を持ちます。

このような構造の企業の場合、親組織レベルの組織構造を反映するブックのセットアップは行うことはお勧めしません。ただし、次の状況が考えられます。

  • 他のレベル(子組織レベルなど)の組織構造を反映するブックをセットアップする。
  • 親組織レベルで他のブック階層をセットアップする。たとえば、親組織レベルで、親組織のユーザーが、全子組織内の重要な潜在的収益のある商談を参照できるようにするブックまたはブック階層を作成することができます。

データの関連付け

ユーザーが部署を移動するときの手順について検討します。次に例を示します。

  • ユーザーが部署を移動するときに、データの関連付けを維持して、そのユーザーが管理するデータもユーザーとともに新しい部署に移動する場合は、レコードの所有権およびチームを介してデータを管理することをお勧めします。通常、アポイントとタスクはすべてのレベルにおいてユーザーとともに移動します。販売環境によっては、顧客データもすべてユーザーとともに移動します。このようなデータの関連付けは、中小企業または低販売量、高価値の販売を行う企業に当てはまります。
  • データの組織的所有権が存在するように、地域支社などの固定組織にデータが通常ある場合、組織構造を反映するブックを介してデータを管理することをお勧めします。
  • ユーザーが別の部署に移動してからしばらくの間、データの関連付けと組織的所有権をどちらも維持する場合、2つの階層を共存させることができます。

ユーザーのニーズとタスク

ブック構造を設計する際には、ユーザーが頻繁にブックを使用するタスクについて検討します。たとえば、リストからの作業、レコードの検索、レポートの作成や使用などです。

リストの使用

ユーザーが必要とするリストを識別するために、頻繁に使用されるリストのタイプと、ユーザーにとって理想的なリストを判断します。このためには、社内ユーザーに入力を依頼します。ブック構造内に、理想的なリストに必要なすべてのレコードが含まれるブックがない場合、そのブック構造に階層がない可能性があります。たとえば、地域別階層と製品別階層の両方をセットアップすることができます。

1つのブックの特定のサブセット内で長時間作業する場合、そのサブセット用のサブブックを作成します。そのサブブックには、ユーザーが識別可能な名前を付けます。また、ユーザーが毎回適切なブックを選択する必要がないように、サブブックを[ブック]セレクタのデフォルトとして設定することもできます。[ブック]セレクタのデフォルトの設定方法については、「ユーザーおよびユーザー役割に対するブックの有効化」を参照してください。

レコードの検索

社内ユーザーの検索ニーズを判断するために、ユーザーに特定のレコードを検索するシナリオについて尋ねます。ブック構造とブックサイズは、ユーザーが頻繁に実行する検索と検索基準を反映する必要があります。

注:既にブック構造が配置されており、それを編集している場合は、特定のレコードがその階層内の特定のブックに存在していることを確認できるかどうかをユーザーに尋ねてください。ユーザーが一様に、より高いレベルのブックしか確認できないと答える場合には、そのブック構造に別のサブセットがあれば、この検索範囲を絞ることができるかどうか確認してください。高いレベルのブックの検索は、通常の検索の例外としてのみ行うようにしてください。

検索で使用されるフィールドも、検索速度に影響します。

  • インデックス付きフィールドを使用してブック内のレコードを検索すると、パフォーマンスが最適化されます(インデックス付きフィールドは、検索セクションで緑色のテキストで示されます)。
  • インデックス付きフィールドではなく、インデックスが付いていないフィールドを使用してブック内のレコードを検索する場合、検索速度は遅くなり、検索するレコード数に応じて、パフォーマンスも影響を受けます(インデックスが付いていない検索フィールドは検索セクションで黒色のテキストで示されます)。

たとえば、ユーザーがインデックス付きフィールドを使用して担当者レコードを検索する場合は、最下位レベルのブック(リーフノードブックと呼ばれます)のレコード数は、各レコードタイプにつき最大100,000です。ただし、ユーザーがインデックスの付いていないフィールドを使用して担当者レコードを検索する場合は、リーフノードブックのサイズをレコード数20,000から30,000におさえることができます。

データ構成は会社によって異なります。ブックのレコード数について推奨値はありません。ブックのサイズは継続して管理することが必要です。ブックを使用すると検索するレコード数を減らすことができ、検索速度が上がります。

レポートの作成と使用

管理者以外のユーザーは全員、レポート用のデータ表示ルールに従います。ユーザーブックまたはカスタムブックがレポートの[ブック]セレクタで指定された場合、レポート対象とみなされるデータは次のとおりです。

  • 履歴分析(レポートタブとダッシュボードタブ、およびレコードのホームページに埋め込まれたレポートからアクセスされた履歴分析を含む)内の全コンテンツは、そのブックに限定され、指定されたブックの全サブレベルを含みます。そのユーザーが所有するレコード、またはそのユーザーがチームメンバーとなっているレコードでも、選択されたブックまたはサブブックにもそれらのレコードが含まれていない限り、含まれません。
  • リアルタイムのレポートは、[ブック]セレクタで選択されたブック(カスタムブックまたはユーザーブック)に直接関連付けられているデータに制限されます。選択されたブックにサブブックまたは部下が含まれる場合、そのサブブックや部下のデータはリアルタイムのレポートでは無視されます。

注:通常、ブック構造はセットアップ後に変更する必要はありませんが、変更することもできます。このような変更を行う場合、ダウンタイムは必要なく、変更もすぐに適用されます。ただし、この変更は、リアルタイプレポート内のデータにはすぐに反映されません。

レポート内のレコードの表示の詳細は「レポート」を参照してください。

マネージャ表示

ブック階層を設計する際には、次の原則に基づいてください。

  • 企業プロファイルの[マネージャ表示が有効]チェックボックスによって提供される機能は、できるだけ使用しないようにします。
  • [サブ項目を含める]オプションは、データ量が大きい検索では基本的に使用しないようにします(データ量が大きくなるレコード数は会社および検索パターンによって異なります)。

    [サブ項目を含める]オプションを使用することが必要な場合があります。部下が互いに共有できないため、部下を含むユーザーブックに対して管理者がリストを実行する場合などです。データ量が大きい場合、検索時間は長くなります。パフォーマンスを最適化するには、必要な場合に限り、[サブ項目を含める]オプションを有効にするようにします。

階層レベル

すべてのレベルにレコードがあり、レベル数が多いブック階層は、管理者表示が有効になっているチーム機能と似た動作になります。このような階層では、データセットが小さいとパフォーマンスが向上します。データ量が大きくなるにつれて、階層内のレベル数が少ない方が(または、階層レベルがない方が)チーム機能よりはるかにパフォーマンスが良くなります。

ブック階層内のあるレベルが、データセキュリティまたはデータ組織にとって付加価値のないものである場合には、冗長ブックとそのサブブックをマージしてください。あるレコードが、同じ親ブック内の2つのサブブックのうちどちらに含まれているのかを識別できるかどうか、ブックユーザーに尋ねてください。識別できない場合には、その2つのサブブックを親ブックに折りたたむのが最適な方法です。

ブック階層内のレベル数を減らす簡単な方法は、サブブックに親ブック名を接頭辞として付けるという方法です。たとえば、North Americaという名前の親ブックを持つNorthという名前のサブブックがある場合、親ブックを削除して、サブブックの名前をNA – Northにします。

クロスリスト

クロスリストとは、複数のブック間でレコードを複製することです。クロスリストは同期化が必要で、その結果サーバーのパフォーマンスに影響する読み書き処理が増大するため、ユーザーが管理するための諸経費がかかります。クロスリストの使用は最小限にしてください。

ブックの管理の自動化

通常、ブック割当基準はレコードタイプの1つ以上のフィールドにマップされます。これらのフィールドのうち1つが変わると、ブック割当を自動的に認識するワークフロールールを作成できます。

たとえば、Territoryというブック階層があった場合、あるレコードタイプ内のあるフィールド(たとえば、取引先のTerritoryフィールド)を監視するワークフロールールを作成し、次に、取引先のTerritoryフィールド値が変わると、そのレコードのTerritoryブックを新しいブックに更新するブック割当アクションをルールに設定することができます。

ブック名を設計する際には、ブック名を解決する式に基づいて単一のワークフローアクションで異なるブックを異なるレコードに割り当てることができるような方法で[ブックを割り当て]ワークフローアクションを使用する必要があるかどうかを検討します。

たとえば、北アメリカに取引先があり、EMEAに拠点を置く取引先もあるとします。それらの異なる所在地のために2つの別個のブックを設定し、取引先所在地に応じて適切なブックを取引先に割り当てる必要があります。この構成を設定するには、2つのブックを作成し、一方を「North America」、他方を「EMEA」という名前にします。次に、「Sales Location」という名前の、値が「North America」および「EMEA」であるカスタムピックリスト項目を作成し、そのカスタム項目を適切な役割の[取引先]レコードタイプのページレイアウトに追加します。その後、取引先レコードの更新時に以下のことが実行される、[ブックを割り当て]ワークフローアクションを作成します。

  • 取引先レコード上の[Sales Location]フィールドで選択されている値を判断する式を評価します。
  • 取引先レコードを、その式で返された値と名前が一致するブックと関連付けます。

関連トピック

関連情報については、次のトピックを参照してください。


公開日 2017 年 9 月 Copyright © 2005, 2017, Oracle. All rights reserved. Legal Notices.