ディメンションの設計に関する考慮事項

アプリケーション構造を作成するためのディメンションの設計

ビジネス・プロセスをサポートする勘定科目、エンティティおよびその他のディメンションを追加します。

ディメンションで、データ値が分類されます。Planningには、勘定科目、エンティティ、シナリオ、バージョン、期間、年のディメンションが用意されています。複数の通貨を計画する場合、アプリケーションには通貨ディメンションもあります。

カスタム・ディメンションを使用して、製品、顧客、市場など、独自の値を定義することもできます。ディメンションの合計は最大32個です。ただし、ベスト・プラクティスとして、追加するのは12個未満にすることをお薦めします。ロード・ファイルを使用してディメンションを追加することも、Oracle Smart View for Officeでディメンションを構築することもできます。

ビデオ

ディメンションを識別するための当該プロセスの励行

このプロセスを使用して、アプリケーションに含めるディメンションを識別します。

1. 要件に基づいて一意のプランニング・プロセスを識別します。

   例: マーケティング・プランニング、販売プランニング、諸経費プランニング、資本プランニング、キャッシュ・フロー・プランニング、要員プランニング

2. 各プランニング・プロセスのディメンションを識別します。

   例: 製品、マーケット、チャネル、製品セグメント、顧客セグメント

3. ディメンション相互の関係を定義します。

   例: 製品とマーケットには多対多の関係があります。製品セグメントと製品には1対多の関係があります。労務リソースと材料リソースには関係がありません。

4. ディメンションをプランニングおよびレポートのバケットに分けます。

   例: 製品、マーケットおよびチャネルはプランニング・ディメンションで、製品セグメントおよび顧客セグメントはレポート・ディメンションです。

5. プランニング・プロセスをプランニング・モジュールにマップします。

   例: プロジェクトまたは財務を使用してマーケティング・プランニングを構成し、財務およびカスタム・キューブを使用して諸経費プランニングおよびキャッシュ・フロー・プランニングを構成します。

ディメンションの一般的なユース・ケースの検討

ディメンションの一般的なユース・ケースを確認し、それらの対処方法のガイドラインを理解します。

• 標準(必須)ディメンション

  高レベルで一般的な財務プランニングのほとんどのユース・ケースは、標準ディメンションで対処でき、名前も変更できます。

• カスタムまたはオプションのディメンション

  要件に応じて追加(有効化)または名前変更できるカスタムまたはオプションのディメンションを使用してディメンションを拡張します。

• ディメンション内での複数の階層

  ディメンション間の無関係性を回避するために、関連のない2つ以上のディメンションを単一のディメンションに結合します。

• プランニングまたはレポートに対する代替階層

  トップダウンの割当てまたはレポートの目的で、同じメンバーを異なる親の下にグループ化できる場合は、代替階層を使用します。

• レポートに対する属性ディメンション

  属性ディメンションは、1つのディメンションに関連しており、2つのディメンション間の関係が経時的に変化しない場合に、レポート要件を満たすのに役立ちます。

• レポートに対するスマート・リストおよびASOディメンション

  レポートに対するスマート・リストおよびASOディメンションの使用は、レポート・ディメンションと他のディメンションとの関係が経時的に変化する場合に役立ちます。

• プランニングに対するスマート・リストおよび複数キューブBSOディメンション

  この戦略は、プランニング・ディメンションがプランニング・プロセスのプライマリ・ディメンションではなく、サブプロセスに分割する必要がある場合に役立ちます。

このサンプル・ワークシートは、ディメンションの識別、そのユース・ケースのリストなど、ディメンションの計画方法の例を示しています。

設計戦略の例の確認

これらの例を確認し、ディメンションの追加の設計戦略を理解します。

レポートに対する属性ディメンションの使用

レポートに対する属性ディメンションの使用は、レポート要件を満たすのに役立ちます。属性は1つのディメンションに関連しており、2つのディメンション間の関係は経時的に変化しません。

例:

• プロジェクト・ディメンションで「プログラム」という属性を定義します。
• 次に、プログラム・ディメンションにメンバーの階層を作成できます。プログラム・ディメンションの最上位レベルのメンバーは自動的に集約されます。
• 「プロジェクトの追加」Groovyルールで、各プロジェクト・メンバーをプログラム・ディメンションのリーフ・レベルのメンバーに関連付けます。
• これにより、プログラムでプロジェクトをフィルタできます。
• レポート・フォームでは、プログラム・レベルである費用と収益を表示できます。

レポートに対するスマート・リストおよびASOディメンションの使用

この戦略は、レポート・ディメンションと他のディメンションとの関係が経時的に変化する場合に役立ちます。

例:

• ASOにスキルセット・ディメンションを追加し、スキルセット・スマート・リストをスキルセット・ディメンションにマップします。
• BSOからASOキューブにデータを移動するためのデータ・マップを作成します。
• データ・マップはバッチ・プロセスとして実行することも、フォームまたはGroovyルールにスマート・プッシュを実装することもできます。
• ASOキューブのレポート・フォームを使用して、プロジェクト全体のスキルセット別労務要件を表示できます。

スマート・リストおよび複数キューブBSO設計の使用

この戦略は、プランニング・ディメンションがプランニング・プロセスのプライマリ・ディメンションではなく、サブプロセスに分割する必要がある場合に役立ちます。

例:

• 従業員とジョブは、プロジェクト・プランニングの要員およびスマート・リストのディメンションです。
• プロジェクト・プランニングでは、ライン・アイテムを使用して、ジョブおよび従業員レベルで労務費用を計画します。

ディメンション内での複数の階層

ディメンションでは複数の階層を使用できます。ディメンション間の無関係性を回避するために、関連のない2つ以上のディメンションを単一のディメンションに結合します。

例:

• プロジェクトでは、ジョブ、設備および材料は無関係であるため、単一のリソース・クラス・ディメンションに結合されます。
• 財務では、利益センターとコスト・センターは無関係であるため、単一のエンティティ・ディメンションに結合できます。

プランニングおよびレポートに対する代替階層

トップダウンの割当てまたはレポートの目的で、同じメンバーを異なる親の下にグループ化できる場合は、代替階層を使用します。

例: ブランドおよび製品カテゴリ別にプランニングおよびレポートするために、製品ディメンションに代替ロールアップを作成します。

ディメンションに関する上位10のベスト・プラクティスの把握

ディメンションを設計する際は、次の重要なベスト・プラクティスに従ってください。

1. ディメンションの順序は、変更された砂時計フォーマットに従います。

   このフォーマットでは、最も密度の高いディメンションが最初のディメンションとなり、より密度の低いディメンションが後に続きます。その後に疎ディメンションが続きますが、その際は、集約する疎ディメンションが前で、その後に集約しない疎ディメンションが続きます。疎ディメンション内では、最も密度の高い疎ディメンションが前で、最も密度の低い疎ディメンションが後ろです。

   ハイブリッドBSOでは、動的疎ディメンションの前に非動的疎ディメンションを配置する必要がありますが、それ以外の順序は同じです。

   密ディメンションと疎ディメンションについてさらに学習するためのチュートリアル: Cloud EPMでのディメンションの管理。

2. 大きいブロック・サイズはパフォーマンスに大きな影響を与えます。

   ブロック・サイズは、密ディメンションの数およびその密ディメンションのメンバーによって決まります。最適なブロック・サイズは8 KBから500 KBです。密ディメンションの数を最大3までに減らします。密ディメンションのレベル1以上は、ラベルのみまたは動的計算にしてください。

3. テキスト、スマート・リスト、日付および保管されたパーセンテージ・タイプの勘定科目では、連結プロパティを「なし」に設定します。

   集約スクリプトで勘定科目が明示的に除外されていない場合、これらの値を集約すると、無用なデータが作成されます。

4. 世代2のすべてのメンバーを「無視」に設定します。

   これらのルート・メンバーにはセキュリティを定義できないため、それらのメンバーをフォームに含めることはできません。したがって、世代2のメンバーをルートに集約することは無意味です。これによってアプリケーション内のブロック数も増加することになります。

5. 長いまたはフラットなディメンションは、集約のパフォーマンス上の問題につながります。

   親メンバーの下に200を超えるメンバーがある場合は、中間の親を追加します。

6. 複数のキューブのディメンション・メンバーを有効にすると、動的な相互参照が作成され、パフォーマンス上の問題につながります。

   動的な相互参照の作成を回避するには、HSP_NOLINK UDAを使用します。キューブ間でデータを移動するには、データ・マップまたはスマート・プッシュを使用します。

7. 単純な計算には、メンバー式を記述するかわりにアウトライン計算を活用します。

   単純な計算は、たとえば、Account C = Account A – Account Bなどです。

8. 可能な場合は、1つの子の親のメンバーは回避します。

   親メンバーが「共有しない」になっている場合、1つの子の親メンバーは、暗黙的な共有またはディスク上のブロックとデータの重複につながります。

9. 可能な場合は常に、BSOではなくASOに大規模なディメンションを集約します。

   これにより、キューブ・リフレッシュ時やメンテナンス時間などのパフォーマンスが向上します。

10. 2年を超える履歴データはBSOではなくASOに保存します。

    過去5年または10年の履歴データがある場合、すべてのデータが計算に必要とはかぎりません。必要な場合は、計算用に数年分の履歴データをBSOキューブに確保し、他の履歴データをASOキューブに移動できます。最適なパフォーマンスのためには、BSOキューブを軽くして、データ入力の計算に集中できるようにすることがベスト・プラクティスです。

エンティティ・ディメンションの計画

エンティティ・ディメンションは、コスト・センター、部署、事業部門、部門などの組織構造を表します。

組織の表示方法を反映するために、親と呼ばれるロールアップ・メンバーを作成してコスト・センターをグループ化できます。たとえば、事業部門、部門またはその他の機能構造別にロールアップできます。例として、部門にロールアップされる事業部門にロールアップされるコスト・センターを作成できます。

複数のレポート構造も作成できます。たとえば、地域レポートをサポートする代替構造を作成できます。複数の通貨を計画する場合は、各エンティティの基本通貨を設定します。

エンティティ・ディメンションは、予算策定プロセスに使用されるプライマリ・ディメンションの1つです。シナリオおよびバージョン・ディメンションとともに、エンティティ・ディメンションは、承認ユニット(ユーザーの同僚による承認またはレビューを受けるために上位または下位へ移動できる個別コンポーネント)を定義するために使用されます。

承認ユニット外のすべてのディメンションのメンバーが、承認ユニット自体とともに上位および下位へ移動されます。たとえば、承認ユニットが上位へ移動される際には、12か月すべてが一緒に上位へ移動されます。個々の月を個別に上位へ移動することはできません。

各ディメンションをロードまたは更新したら、アプリケーションをリフレッシュすることをお薦めします。

勘定科目ディメンションの計画

勘定科目ディメンションは勘定体系の場所です。これには、計画または予測するメンバーを含める必要があります。勘定体系のすべての勘定科目が含まれるとはかぎりません。

たとえば、損益計算書、貸借対照表およびキャッシュ・フローの勘定科目を勘定科目ディメンションに含めることができます。または、KPIや比率の勘定科目を含めることもできます。場合によっては、勘定科目にサブ勘定科目がありますが、これは一般的ではありません。

勘定科目ディメンションには財務情報が含まれます。次の勘定科目タイプがサポートされています。

• 費用: ビジネスを行うコスト

• 収益: 収益源

• 資産: 会社のリソース

• 負債と資本: 残余請求権または債権者への債務

• 保存された仮定: アプリケーションで一貫性を確保する集中管理されたプランニング仮定

勘定科目タイプの設定は、四半期ごとおよび年合計の値のレポートや差異分析に使用されます。

Planningでは、階層構造を使用して、小計および合計をグループ化する勘定科目が作成されます。各勘定科目グループには、その親にロールアップされる方法を決定する集計演算子が割り当てられます。

例:

純利益 = 収益合計 - 費用合計

この例では、収益合計の集計演算子は「加算」で、費用合計の集計演算子は「マイナス」です。

勘定科目ディメンションは、データをロードして移入することも、Smart Viewを使用して移入することもできます。ファイルからデータをロードするには、ファイル・フォーマットが特定の要件を満たしている必要があります。

各ディメンションをロードまたは更新したら、アプリケーションをリフレッシュすることをお薦めします。

ベスト・プラクティス:

• 上位レベル・メンバーは、「動的計算」に設定する必要があります。

• 比率およびその他のタイプのKPIやパーセンテージの計算に使用されるメンバー式については、それらを「動的計算」、2パスに設定します。2パス設定により、上位レベルのパーセンテージが正しく計算されます。

バージョン・ディメンションの計画

バージョンを使用して、プランニング・プロセスの様々な反復を保存できます。バージョンは、データ・アクセスを読取りまたは書込みに制限する場合にも役立ちます。

次の2つのタイプのバージョンが使用可能です。

• 標準ターゲット: 入力データを上位レベルに入力できます。

• 標準ボトムアップ: 入力データをレベル0のみに入力できます。

承認およびワークフロー機能は、ボトムアップ・バージョンのみについて有効にすることができます。

ベスト・プラクティスとして、次のバージョンが推奨されます:

• 作業中: ユーザーが、実績結果のレビューやプランおよび予測の開発など、各自のタスクを実行する場合。

• 最初のパス: プランの複数の反復を保持する必要がある場合、このバージョンにそのパスを保存できます。保存された反復が複数必要な場合は、他のメンバーを作成できます。「データのコピー」機能を利用して、このバージョンにデータを移動できます。「データのコピー」では、データおよびテキスト入力がコピーされます。

• What If: ユーザーが仮定を変更し、結果を分析できるプレースホルダを提供します。

構築プロセスで各ディメンションをロードまたは更新したら、アプリケーションをリフレッシュすることをお薦めします。

通貨ディメンションの計画

アプリケーションで複数通貨を有効にした場合、計画およびレポートに使用する通貨を追加できます。

その後、換算で使用される為替レートをシナリオおよび年別に定義できます。通貨換算を実行するための計算スクリプトが作成されます。為替レートを入力するには、Planningの管理の為替レートの指定のプロセスに従ってください。

ベスト・プラクティス:

• レポート通貨の数を制限します。通常は、顧客に1つのみです。

• シナリオと年の有効な組合せごとに為替レートを入力します。

• この時点から、デフォルトで各フォームに関連付けられている「通貨の計算」ビジネス・ルールを実行して、通貨換算を計算できます。

• 勘定科目の為替レート・タイプは、「期末」から「平均」などに変更されます。

次の作業を行う前に、通貨換算計算スクリプトを実行します。

• レポート通貨による更新されたローカル・データのレビュー

• レポート通貨データによって異なる可能性がある特定の計算の実行

為替レートの計画

各アプリケーションには、アプリケーションの作成時に指定したデフォルトの通貨があります。為替レート表を設定する際には、すべてのソース通貨からデフォルトへの為替レートを入力します。他のすべてのレポート通貨への換算には、トライアンギュレーションが使用されます。

為替レートは、平均および期末レートについて年別のシナリオごとに設定されます。

期間ディメンションの計画

期間ディメンションは、月別など、特定の年のカレンダの範囲を設定する場合に使用します。

ベスト・プラクティス:

• レポートおよび計算をサポートするには、このディメンションに代替変数を使用します。代替変数の候補はCurrMo、CurrQtrおよびPriorMoです。これらの変数は、毎月更新する必要があります。

• 年次累計(Y-T-D)や四半期累計などの期間計算を使用するには、期間ディメンションで動的時系列アイコンを選択します。その後、プロセスをサポートするために必要な期間計算を選択できます。

• 計算時間を短縮するために、四半期合計や年合計などのサマリー期間は動的計算に設定する必要があります。

• 各ディメンションをロードまたは更新したら、アプリケーションをリフレッシュします。

年および代替変数の計画

年は、フォーム、計算、レポート、Smart Viewなど、アプリケーションの様々場所に組み込まれます。今後何年にもわたってアプリケーションを使用するため、このディメンションを参照するには代替変数を使用することをお薦めします。

代替変数は定期的に変化する情報のグローバルなプレースホルダとして機能します。変数および値は年に対応し、値はいつでも変更できます。

代替変数の値は、プレースホルダとしてフォームおよびレポートに表示されます。これにより、アプリケーションの保守が軽減します。

ベスト・プラクティスとして、プロセスに含まれる年ごとに代替変数を作成してください。例:

• CurrY、現在の年

• NextYr、予算(プラン)年

• PriorYr、前の年

カスタム・ディメンションの設計

カスタム・ディメンションを使用して、データをさらに分類できます。たとえば、カスタム・ディメンションには製品や市場などがあります。

ディメンション・レベル(世代1とも呼ばれる)ではアクセス権限を付与できないことに注意してください。たとえば、すべての子孫について製品メンバーにアクセス権限を直接割り当てることはできません。カスタム・ディメンションでセキュリティを有効にする場合は、セキュリティ・アクセス権の割当てを考慮に入れて、セキュリティが適用されるすべてのカスタム・ディメンションの世代2を設計することをお薦めします。

各ディメンションをロードまたは更新したら、アプリケーションをリフレッシュすることをお薦めします。

その他のベスト・プラクティス

ディメンションを追加または更新した後、次のタスクを完了します。

• アプリケーションのリフレッシュ。

  アプリケーションの構造を変更したら、アプリケーションを必ずリフレッシュしてください。

  アプリケーションをリフレッシュするまで、アプリケーションの変更がユーザーによるデータの入力および承認タスクに影響を与えることはありません。

  たとえば、エンティティ・メンバーのプロパティの変更、シナリオの追加またはアクセス権限の変更を行った場合、これらの変更は、アプリケーションをリフレッシュした後でユーザーに反映されます。

• 履歴データのロード。

  勘定科目やエンティティなど、すべての構造をロードしたら、履歴データをロードできます。これには、前の年の実績結果や現在の年のプランと予算などが含まれます。

  履歴データをロードすると、ユーザーは結果を分析し、トレンドを確認して、有意義な比較を行うことができます。

  これは、アプリケーションに組み込んだ構造を確認する際にも役立ちます。たとえば、前に作成されたレポートにデータが関連していることを確認できます。データが照合されない場合は、その原因がデータの問題であるのか、構造に問題があるのかを確認する必要があります。

  アプリケーションに連結データを表示するには、集約ルールを作成します。

• 有効な交差の計画。

  サービス管理者は有効な交差を使用して、ユーザーがデータを入力したり実行時プロンプトを選択する際にディメンショナル交差をフィルタする、有効交差ルールと呼ばれるルールを定義できます。たとえば、特定の部署のみに特定のプログラムが有効になるように指定できます。有効な交差を利用して、有効な交差のみにデータ入力を制御します。

  フォームを設計する際は、有効な交差について次の点に注意してください。

  • 有効な交差で設定されているディメンションがページにある場合、メンバー・セレクタには有効な組合せのみが表示されます。
  • 有効な交差で設定されているディメンションが列または行にある場合、フォーム・デザイナでは無効な交差を完全に抑制できます。抑制オプションが選択されていない場合、無効な交差は読取り専用に設定されます。