設計ウォークスルーのベスト・プラクティス

次のベスト・プラクティスを使用して、アプリケーションの構築およびロールアウトに役立つ設計ウォークスルーを行います。

アプリケーションの構築

まず、基礎、つまり会社の勘定科目と組織構造を構築します。次に、プラン、実績、予測など、内部プロセスをサポートするシナリオを追加します。実績vsプランなど、レポートする差異メンバーを追加します。

ユーザーからデータを収集し、レビュー、分析およびレポートを実行するために使用するフォームを作成します。ビジネス・ロジックをサポートするために、Calculation Managerを利用して計算を構築できます。レポートを作成し、アクセス権限を適用してから、アプリケーションをユーザーにロールアウトすることもできます。

アプリケーション構造の作成

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

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

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

ビデオ

目的	視聴するビデオ
アプリケーションでデータをエクスポートおよびインポートする方法を学習します。	Oracle Planning and Budgeting Cloudでのデータのエクスポートおよびインポート
ファイルを使用してディメンションをロードする方法を学習します。	Oracle Planning and Budgeting Cloudでのメタデータのインポート

エンティティ・ディメンションについて

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

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

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

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

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

ロード・ファイルを使用したディメンションおよびメンバーの追加の詳細は、データとメタデータのインポートおよびエクスポートを参照してください。

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

勘定科目ディメンションについて

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

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

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

費用: ビジネスを行うコスト
収益: 収益源
資産: 会社のリソース
負債と資本: 残余請求権または債権者への債務
保存された仮定: アプリケーションで一貫性を確保する集中管理されたプランニング仮定

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

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

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

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

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

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

ベスト・プラクティス:

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

バージョン・ディメンションについて

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

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

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

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

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

作業中: ユーザーが、実績結果のレビューやプランおよび予測の開発など、各自のタスクを実行する場合。
最初のパス: プランの複数の反復を保持する必要がある場合、このバージョンにそのパスを保存できます。保存された反復が複数必要な場合は、他のメンバーを作成できます。「データのコピー」機能を利用して、このバージョンにデータを移動できます。「データのコピー」では、データおよびテキスト入力がコピーされます。
What If: ユーザーが仮定を変更し、結果を分析できるプレースホルダを提供します。

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

通貨ディメンションについて

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

その後、換算で使用される為替レートをシナリオおよび年別に定義できます。通貨換算を実行するための計算スクリプトが作成されます。為替レートを入力するには、「プラン」をクリックまたはタップし、プライマリ・レポート通貨に対する為替レート・フォームを開きます。

ベスト・プラクティス:

レポート通貨の数を制限します。通常は、顧客に1つのみです。複数ある場合、詳細は通貨の設定を参照してください。
シナリオと年の有効な組合せごとに為替レートを入力します。
この時点から、デフォルトで各フォームに関連付けられている「通貨の計算」ビジネス・ルールを実行して、通貨換算を計算できます。
勘定科目の為替レート・タイプは、「期末」から「平均」などに変更されます。

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

レポート通貨による更新されたローカル・データのレビュー
レポート通貨データによって異なる可能性がある特定の計算の実行

為替レートについて

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

為替レートは、平均および期末レートについて年別のシナリオごとに設定されます。ロード・ファイルを使用したディメンションおよびメンバーの追加の詳細は、データとメタデータのインポートおよびエクスポートを参照してください。

期間ディメンションについて

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

ベスト・プラクティス:

レポートおよび計算をサポートするには、このディメンションに代替変数を使用します。代替変数の候補はCurrMo、CurrQtr、PriorMoです。これらの変数は、毎月更新する必要があります。
年次累計(Y-T-D)や四半期累計などの期間計算を使用するには、期間ディメンションで動的時系列アイコンを選択します。その後、プロセスをサポートするために必要な期間計算を選択できます。
計算時間を短縮するために、四半期合計や年合計などのサマリー期間は動的計算に設定する必要があります。

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

年について

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

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

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

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

代替変数、説明

CurrY、現在の年

NextYr、予算(プラン)年

PriorYr、前の年

カスタム・ディメンションについて

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

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

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

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

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

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

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

履歴データのロード

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

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

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

アプリケーションに連結データを表示するには、集計ルールを作成する必要があります。集計ルールを作成するかを学習するには、集約オプションを参照してください。

有効な交差について

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

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

さらに学習するには、有効な交差の定義を参照してください。

フォームについて

データ入力やサマリー・レベル・レポートをサポートする様々なフォームを構築します。フォームの内容は、データの収集および計算に使用するテンプレートに類似しています。レイアウトは、スプレッドシートで現在使い慣れているものとは異なる場合があります。

「収益」、「報酬費用」、「その他費用」などの主要カテゴリにフォームを分類します。データ入力をサポートするフォームや、サマリーおよびレビュー用のフォームを作成できます。ユーザーが結果を分析する際に役立つチャートを挿入することもできます。

ユーザーは、テキストおよびデータを入力できます。また、該当する交差をフォームで選択し、「サポート詳細」をクリックして、その交差に関する追加詳細を入力できる新しい入力フォームを開くことにより、サポート詳細を入力することもできます。

フォームのパフォーマンスは、ネットワークおよび環境要因、構造、レイアウトなど、様々な要因に基づきます。

ベスト・プラクティス:

勘定科目や期間などの密ディメンションをフォームの行および列に配置します。エンティティなどの疎ディメンションをページ軸に配置します。
シナリオ、バージョン、年などのディメンションは、POV、列または行に配置できます。ユーザーがフォームを開いたときに列または行がどのように返されるかを適切に判断することが重要です。

入力フォームの構築

ユーザーが収益、費用、仮定などの情報を入力できるようにフォームを作成します。

ベスト・プラクティス:

勘定科目を論理的にグループ化しますが、1つのフォームに含まれる勘定科目が多くなりすぎないようにします。
入力フォームの数を、エンド・ユーザーの負担にならない量に制限します。1つのフォーム上の勘定科目の数とプロセスをサポートするために必要なフォームの数の間で微妙なバランスを取る必要があります。
詳細フォームを使用して、ユーザーがすべての関連情報を入力できるようにします。入力を必要とするすべての勘定科目がフォーム上にある必要があります。勘定科目を複数の異なるフォームに分割できます。
フォームを構築する際には、フォームの設計を向上させるための適切なオプションをすべて選択していることを確認します。たとえば、精度、表示およびメニューを制御したり、適切なルールをフォームに関連付ける設定を使用します。
年などのディメンションを参照するには、代替変数を使用します。
「無効なシナリオ時間/期間の抑制」オプションで、フォーム上の行または列の期間をシナリオに設定された開始および終了期間に設定します。この機能は、年の代替変数のかわりに使用できます。
有効な交差を設定して、様々なディメンション間の関係を設定することを検討します。有効な交差のみがエンド・ユーザーに表示されるように、無効な組合せの抑制を行または列で設定できます。ページの選択でディメンションが設定されている場合、デフォルトでは、有効な交差のみがエンド・ユーザーに表示されます。
メンバーを個々に選択するかわりに、関係を使用してメンバーをフォームに組み込みます。
エンド・ユーザーのディメンション選択を軽減できるように、エンティティやシナリオなどのディメンションにユーザー変数を使用することを検討します。
アプリケーションで複数通貨がサポートされている場合、ユーザーが基本通貨を定義できるようにユーザー変数を設定することを検討します。
フォームをフォルダに編成します。
代替変数により、フォームの保守が軽減します。

詳細収益フォームと詳細費用フォームの構築

詳細フォームでは、ユーザーが収益および費用関連のすべての情報を入力できることが必要です。入力を必要とするすべての勘定科目がフォーム上にある必要があります。

ベスト・プラクティス:

勘定科目を論理的にグループ化しますが、1つのフォームに含まれる勘定科目が多くなりすぎないようにします。
入力フォームの数を、エンド・ユーザーの負担にならない量に制限します。1つのフォーム上の勘定科目の数とプロセスをサポートするために必要なフォームの数の間で微妙なバランスを取る必要があります。
詳細フォームを使用して、ユーザーが収益関連のすべての情報を入力できるようにします。入力を必要とするすべての勘定科目がフォーム上にある必要があります。勘定科目を複数の異なるフォームに分割できます。
フォームを構築する際には、フォームの設計を向上させるための適切なオプションをすべて選択していることを確認します。たとえば、精度、表示およびメニューを制御したり、適切なルールをフォームに関連付ける設定を使用します。
フォームの構築を反復的に行うことで、ユーザーとプロセスをサポートできます。

フォームへのルールの関連付け

フォームにルールを関連付けることにより、適切なアクセス権を持つユーザーは、関連付けられたビジネス・ルールをフォームから起動し、値を計算して導出できます。

キューブによって、複数のビジネス・ルールをフォームに関連付けることができます。

フォームを開いたときまたは保存したときに、フォームに関連付けられたビジネス・ルールが自動的に起動するように設定できます。「フォームのメンバーを使用」を選択すると、ルールの起動時にユーザーに入力を求めるプロンプトを表示するかわりに、現在のフォームから実行時プロンプトに値を移入できます。

ベスト・プラクティス:

実行に時間がかかるルールについては、アクション・メニューから起動するか、単にフォームへの関連付けによって起動するように設定します。
ビジネス・ルールに実行時プロンプトがある場合、ユーザーの作業を簡単にしておくためにプロンプトの数を制限します。

フォームへのメニューの追加

フォームにメニューを関連付けることができます。アクション・メニューを使用すると、ユーザーはフォーム内の行または列をクリックし、メニュー・アイテムを選択して次の操作を実行できます。

実行時プロンプトの有無にかかわらず、ビジネス・ルールを起動
別のフォームへの移動
「承認の管理」への事前定義済のシナリオとバージョンをともなった移動

メニューはコンテキスト依存です。表示されるメニューは、フォームの設定や、ユーザーがフォームで右クリックした場所によって異なります。

ベスト・プラクティス:

フォームの設計時に、「その他オプション」を使用して、フォームのメニュー・アイテム・タイプに可能なメニューを選択します。
アプリケーションを更新するとき、それに適切なメニューが更新されます。たとえば、メニューで参照されているビジネス・ルールを削除する場合は、そのルールをメニューから削除します。

データ検証フォームの構築

データ検証は、ビジネス・ポリシーに適合していることをユーザーが確認するための視覚的な手がかりとして使用できます。条件に応じた色コーディングをフォームに追加したり、入力したデータが検証ルールに違反している場合や条件を満たした場合に検証メッセージを生成できます。

データ検証ルールの定義には、次のメイン・タスクがあります:

条件を満たしたときに検証メッセージとともに表示したり別の色で表示するデータのセルまたは場所を指定します。
ルールの評価に関与させる必要があるセル、列または行を指定し、適切にルールを定義します。
指定した場所におけるデータ検証ルールを作成します。

フォルダへのフォームの編成

アプリケーションでフォームを整理するための手段としてフォルダを使用します。プロセスまたはユーザー・タイプ別に、あるいは単にユーザーがフォームをすぐに見つけられるように、フォームをフォルダにグループ化できます。フォームをフォルダに移動したり、フォルダ階層を作成できます。また、フォルダを作成すると、割り当てられたアクセス権限がフォルダ内のすべてのフォームに継承されるため、アクセス権の割当てが容易になります。

ダッシュボードの作成

ダッシュボードを使用すると、情報をグラフィカルに表示したり、複数のフォームを同時に表示できます。ユーザーが各自のプランまたは予測データを分析できるように、対話型の複数チャート・ダッシュボードを設計することもできます。別のオプションとして、グリッドとグラフを一緒に表示したり、複数のグリッドを組み合せることもできます。

ダッシュボードを作成するには:

フォームをダッシュボードにドラッグ・アンド・ドロップします。設定の歯車を使用して、各グリッドに必要なチャート・タイプを選択します。
任意の数のフォームをドラッグ・アンド・ドロップし、コンポーネントの高さや幅を設定して、表示のサイズを設定できます。
ダッシュボード設定を設定して、ディメンションを共通のPOVに組み合せます。
ベスト・プラクティスとして、ユーザーにとって視覚的にわかりやすくなるようにダッシュボード上のコンポーネントの数を調整してください。

サマリー・レベル・フォームの構築

通常、サマリー・レベル・フォームにはユーザーのプランまたは予測のすべての部分がまとめられます。ユーザーは、これを使用して結果をレビューおよび分析できます。

さらに、ユーザーが結果を効果的に分析するための方法として、ダッシュボードを使用することもできます。

財務諸表の構築

財務諸表を使用すると、ユーザーはパフォーマンスを分析し、各自の仮定を確認できます。財務諸表には、損益計算書、貸借対照表、キャッシュ・フローなどが含まれます。

財務諸表には通常、ユーザーが差異を分析できるように比較情報が含まれます。一般に、財務諸表にはサマリー・レベルの情報が組み込まれ、メニューを使用してフォームをリンクすることにより、詳細データを表示できます。

ビジネス・ロジックの組込み

ビジネス・ロジックをアプリケーションに組み込むために、Calculation Managerを使用して計算を構築できます。これを使用すると、ビジネスの問題を解決する高度な計算を作成、検証、デプロイおよび管理できます。

通常、ビジネス・ルールおよびルールセットは次の目的で作成します:

収益モデリングの実行
費用モデリングの実行
KPIの計算
配賦の実行

Calculation Managerには次のオブジェクトが用意されています。

ルール: コンポーネントとテンプレートを含みます
コンポーネント: ルールの構築を支援します
ルールセット: 同時または順次に計算できるルールを含みます

計算の作成についてさらに学習するには、Calculation Managerのドキュメントを参照してください。

集約の構築

集約によって、エンティティやその他の疎ディメンションなど、ディメンション内のサマリー・レベル・メンバーにアプリケーションがロールアップされます。

Calculation Managerには、集約の構築に役立つテンプレートが用意されています。「集約」システム・テンプレートには複数のタブがあります。テンプレートの使用方法に関するいくつかの提案を次に示します。

視点の設定

視点を設定すると、選択されたメンバーのみに対してルールが実行されます。ディメンションの実行時プロンプトを使用すると、ユーザーは、ルールの起動時にそれらのディメンションのメンバー値を指定できます。これにより、ユーザーは、Calculation Managerでルールを変更しなくても、様々な年、シナリオおよびバージョンについてルールを複数回起動できます。

完全な密の集約

密ディメンションの親の値が動的計算に設定されていない場合、このセクションに入力します。通常、このタブは空のままです。

完全な疎の集約

集約する必要がある疎ディメンションを選択します。選択したディメンションの順序は関係ありません。

部分的なディメンション集約 - 密

密ディメンションの親の値が動的計算に設定されていない場合、このセクションに入力します。通常、このタブは空のままです。

推奨される設定:

データを現地通貨で集約します: いいえ

データベースの欠落値を集約します: はい

疎ディメンションの計算を最適化します: オフ

計算機キャッシュの値を選択します: デフォルト

このウィザードのデバッグ・モードをアクティブ化しますか?: 「デバッグ・ウィザード・オン」または「デバッグ・ウィザード・オフ」。このテンプレート内の一部の設計時プロンプトの選択内容を表示するために生成されたスクリプトを確認する場合は、「デバッグ・ウィザード・オン」を選択します。

ベスト・プラクティス:

エンティティ、シナリオ、バージョンなどのメンバーの実行時プロンプトを利用します。これにより、ユーザーの入力に基づいてルールを動的に実行できます。
通常、勘定科目や期間などの密ディメンションを集約する必要はありません。この場合、親メンバーを動的計算に設定できます。ただし、密ディメンションに関するメンバー式があり、それらが動的計算に設定されていない場合は、Calc Dimルールが必要です。

詳細な計算の構築

Calculation Managerを使用して、ビジネスの問題を解決する高度な計算の作成、検証、デプロイおよび管理を行います。

Calculation Managerで計算できるオブジェクトには3つのタイプがあります:

ルールセット: 同時または順次に計算できるルールを含みます(ルールの管理を参照してください。)
ルール: コンポーネントとテンプレートを含みます(ルールの管理を参照してください。)
コンポーネント: 式コンポーネント、スクリプト・コンポーネント、条件コンポーネント、範囲コンポーネントおよび固定ループ・コンポーネントを含みます(ルールの管理を参照してください。)

ベスト・プラクティス:

ルールを構築する際の最初のステップとして、ビジネス・ロジックと、ルールが適用されるエンティティまたは部署を確実に理解しておきます。たとえば、ルールに含まれる勘定科目を把握しておいてください。
ソース勘定科目と宛先勘定科目を確実に把握しておきます。
計算のドライバを十分に理解してから、適切なオブジェクト・コンポーネントまたはテンプレートを使用してルールを構築します。コンポーネントおよびテンプレートによってメンバーの選択が容易になり、ルールを簡単にデプロイできます。

エンティティ、シナリオ、バージョンなどのメンバーの実行時プロンプトを利用すると、ユーザーの入力に基づいてルールを動的に実行できます。

レポートの構築

レポートを構築すると、財務情報を経営陣に報告できます。このステップでは、経営陣がレビューするのに慣れている適切なフォーマットで損益計算書やその他の詳細レポートを構築します。

レポート・フォーマットでは、行および列に配置する要素など、レポートのレイアウトを指定します。レポート・フォーマットを使用して、コスト・センター別や部門別など、様々なレポートを作成できます。

ベスト・プラクティス:

レポートを構築する前に、必要なレポート・フォーマットの数を確認します。
レポートを容易に構築できるように、必要なレポートのタイプごとにレポート・フォーマットを指定します。
レポートを構築する際には、まず、ディメンションを正しく配置します。次に、レポートにデータが取り込まれるようにします。最後に、フォーマットを適用します。

タスク・リストの構築

タスク・リストはタスク、手順および期限を一覧表示し、プランニング・プロセスを通してユーザーをガイドします。タスク・リストにより、ユーザーは手順に沿ってアプリケーションを操作し、プロセスに従っていることや、適切なデータがすべて収集されていることを確認できます。

様々なタイプのユーザーおよびプロセス・フローをサポートするタスク・リストを開発する必要があります。タスクは、ユーザーが次のような様々なタイプのタスクを実行する場合に役立ちます。

フォームを開きます
指定したビジネス・ルールを起動します
指定されたシナリオとバージョンでレビュー・プロセスを開始します
現在のフォームのデータのバージョンをコピーします
指定されたURLを開きます

タスクは、ユーザーにプランニング・プロセスの手順を示します。タスクは、ユーザーが様々なタイプのタスクを実行する場合に役立ちます。これにより、ユーザーは手順に沿ってアプリケーションを操作し、プロセスに従っていることや、適切なデータがすべて収集されていることを確認できます。

様々なタイプのユーザーおよびプロセス・フローをサポートするタスクを構築してください。

ナビゲーション・フローの設定

ナビゲーション・フローでは、ユーザー画面の上部に表示されるクラスタやカードを設定します。カードは通常、収益の計画や費用の計画など、ビジネス・プロセスのアクションに関連します。各カード内に、垂直タブを作成して、そのビジネス分野のプロセスをユーザーに示すことができます。フォームを垂直タブにリンクして、プロセス内でユーザーをガイドすることもできます。垂直タブには、フォームまたはダッシュボードにリンクする1つまたは多数の水平タブを追加できます。

アプリケーションには、デフォルトのナビゲーション・フローが付属しています。組織にあわせてカードやフローをカスタマイズするには、デフォルトをコピーした後、それを使用して独自のものを作成できます。

「設定」、「ナビゲーション・フロー」の順にタップまたはクリックします。「アクション」、「コピーの作成」の順にタップまたはクリックします。

アクションのカードを含めることができる、ビジネス・プロセス全体を表すクラスタを作成することも、単に新しいカードを作成することもできます。カードは、単一ページとして設計することも、複数のタブを追加することもできます。タブ形式として設定されたカードの場合、複数のタブを追加して、コンテンツを水平タブとしてエンド・ユーザーに表示できます。各タブのコンテンツ・タイプを指定し、アーティファクトにリンクします。

たとえば、次のものにカードを関連付けることができます。

ダッシュボード
フォーム
ルール
承認

アクセス権限の設定

アクセス権限によって、製品が起動した後のユーザーの権限が決まります。ほとんどの場合、ユーザーを編成できるようにグループが設定されます。定義によれば、ユーザー・グループは、同様のアクセス権限を持つユーザーのセットです。

グループおよび個々のユーザーのアクセス権限は、次のアプリケーション要素に対して割り当てることができます。

シナリオ
バージョン
勘定科目
エンティティ
カスタム・ディメンション・メンバー
フォーム
ビジネス・ルール

ユーザーは、次のグループに所属できます。

サービス管理者
パワー・ユーザー
ユーザー
参照者

ベスト・プラクティス:

デフォルトで保護されているディメンションについては、必要に応じてアクセス権限を変更します。
ディメンション・メンバー、フォーム、ルールなどのアプリケーション要素に対するアクセス権限を割り当てます。ユーザーは、アクセス権を持つアプリケーション要素のみを表示または使用できます。

ユーザーとグループについて

アプリケーション内のいずれかの要素に対するアクセス権限を取得するには、会社のユーザーがOracle Identity Management Systemに追加されている必要があります。アクセス権限によって、製品が起動した後のユーザーの権限が決まります。

定義によれば、ユーザー・グループは、同様のアクセス権限を持つユーザーのセットです。ユーザーを編成し、アクセス権限を割り当てる方法としてグループを使用することをお薦めします。

ユーザーの追加

ユーザーを環境に追加し、権限を割り当てて、アプリケーションに対するアクセス権を付与する必要があります。

ユーザーの役割は、次のいずれかのタイプとして定義されます。

サービス管理者: ディメンション、フォーム、計算などを含め、アプリケーションを作成および管理します。サービス管理者はアクセス権限を管理し、予算プロセスを開始します
パワー・ユーザー: フォーム、Smart ViewワークシートおよびFinancial Reportingレポートを作成および維持します。ユーザーのすべてのタスクを実行できます。
ユーザー: プランの入力および承認のための送信、ビジネス・ルールの実行、他のユーザーが作成したレポートの使用、およびタスク・リストの表示と使用を行います。Smart Viewを利用してデータを入力し、アド・ホック分析を実行します。
参照者: データ・フォームとライセンスを所有するデータ・アクセス・ツールを使用して、データを表示および分析します。参照者は、アプリケーション内のいずれのデータも変更できません。典型的な表示ユーザーは予算プロセスの期間中および最後にビジネス・プランを参照する必要のある経営者です。

ユーザー、パワー・ユーザーおよび参照者は、サービス管理者によって割り当てられた権限に基づいて、フォーム、タスク・リストおよびビジネス・ルールにアクセスできます。

グループの作成

ユーザーにアクセス権限を割り当てる際にはグループを利用することを強くお薦めします。同様のユーザーのグループを作成すると、継続的なセキュリティの保守が容易になります。ユーザーがグループに追加されると、そのグループのアクセス権限を継承します。ディメンション・メンバー、フォーム、タスク・リストなどの要素に対するグループ・アクセス権限を割り当てることは、それらのアクセス権限を各ユーザーに個々に割り当てる必要がないことを意味します。

ベスト・プラクティス:

個々のユーザーがグループに割り当てられ、個々のユーザーのアクセス権限がそのグループのものと矛盾する場合、個々のユーザーのアクセス権限が優先されます。
同様のアクセス権限を持つユーザーのセットに対するグループの使用は、ユーザー・アクセス権を実装する前に明確に定義しておく必要があります。
個人の権限はグループの権限より優先されます。
個人が複数のグループに割り当てられている場合、最も高いアクセス権限を持つグループが優先されます。

ユーザーに直接割り当てられたアクセス権限は、ユーザーが所属するグループから継承されたアクセス権限より優先されます。たとえば、プランに対する読取りアクセス権をグループから継承しても、プランに対する書込みアクセス権を直接割り当てられている場合は、プランに対する書込みアクセス権を取得します。

グループへのユーザーの割当て

ベスト・プラクティスとして、保守を軽減し、同様のアクセス権をユーザーに割り当てる方法としてグループを利用します。適切なグループのアクセス権をユーザーに付与します。

ディメンションに対するアクセス権の割当て

ユーザーがデータを読み書きできるようにするには、次のディメンションに対するアクセス権限を割り当てる必要があります。

勘定科目
エンティティ
シナリオ
バージョン

カスタム・ディメンションでセキュリティが有効になっている場合は、それらのディメンションに対するセキュリティもユーザーに割り当てる必要があります。デフォルトで保護されているディメンションについては、必要に応じてセキュリティ・アクセス権を変更します。

勘定科目ディメンションに対するアクセス権の割当て

表示を許可されている勘定科目に対する読取りまたは書込みアクセス権のみをユーザーに付与します。「読取り」、「書込み」または「なし」としてアクセス権限を割り当てることができます。

ベスト・プラクティス:

継続的なセキュリティの保守を軽減するために、可能なかぎり、関係関数も利用する必要があります。関係関数は、「メンバー」、「子」、「子(含む)」、「子孫」および「子孫(含む)」です。たとえば、純利益の子孫に対する書込みアクセス権をグループに割り当てると、そのグループのすべてのユーザーは、純利益の子孫であるすべての勘定科目に対する書込みアクセス権を持つことができます。このようにすると、各勘定科目に対するアクセス権を個々に割り当てる必要がありません。
優先および継承のルールを十分に活用するには、例外ベースの手法を使用してセキュリティを管理します。セキュリティの基本的な割当てには、グループと関係を使用する必要があります。親レベルのメンバーに対するグループの権限を割り当て、関係を使用してその割当てを子または子孫にプッシュします。子に対する個々のユーザーの権限を例外に基づいて割り当てます。

エンティティ・ディメンションに対するアクセス権の割当て

表示を許可されているエンティティに対する読取りまたは書込みアクセス権のみをユーザーに付与します。「読取り」、「書込み」または「なし」としてアクセス権限を割り当てることができます。

シナリオ・ディメンションに対するアクセス権の割当て

シナリオに対するアクセス権は通常、「読取り」または「書込み」に設定します。たとえば、実績および差異シナリオに対するアクセス権を「読取り」として、プランおよび予測シナリオに対するアクセス権を「書込み」として割り当てることができます。

バージョン・ディメンションに対するアクセス権の割当て

バージョンに対するアクセス権は通常、「読取り」または「書込み」に設定します。たとえば、最終バージョンに対するアクセス権を「読取り」として、作業中バージョンに対するアクセス権を「書込み」として割り当てることができます。

カスタム・ディメンションに対するアクセス権の割当て

カスタム・ディメンションでセキュリティが有効になっている場合、ユーザーがアクセスできるようにするには、そのディメンションに対するセキュリティを割り当てる必要があります。

フォームに対するアクセス権の割当て

ユーザーがフォームを開くことができるようにするには、アクセス権限を割り当てる必要があります。

フォーム・フォルダに対するアクセス権を割り当てられているユーザーは、より詳細なアクセス権を割り当てられていないかぎり、そのフォルダ内のフォームにアクセスできます。

ユーザーおよびパワー・ユーザーは、アクセス権を持つフォームのみに対して表示またはデータの入力を行うことが可能です。アクセス権を持つメンバーのみを操作できます。

ヒント:

フォームに対するアクセス権を簡単に割り当てるには、フォームをフォルダに編成し、個々のフォーム・レベルではなく、フォルダ・レベルでアクセス権を割り当てます。アクセス権限は、「読取り」、「書込み」または「なし」に設定できます。
フォルダに対してアクセス権を割り当てる場合、そのフォルダ内にあるすべてのフォルダはそのアクセス権を継承します。
フォーム・フォルダに対する特定のアクセス権(「なし」や「書込み」など)を割り当てた場合、そのアクセス権限はその親フォルダのアクセス権限より優先されます。たとえば、ユーザーが「なし」権限を持っているFolder2を含むFolder1に対する「書込み」権限を持っている場合、そのユーザーはFolder1を開くことはできますが、Folder2を表示することはできません。
ユーザーが、「書込み」アクセス権を割り当てられているForm1というフォームを含むFolder1というフォーム・フォルダに対し、「なし」アクセス権が割り当てられている場合、ユーザーはFolder1とForm1の両方を見ることができます。

ビジネス・ルールに対するアクセス権の割当て

ユーザーがビジネス・ルールを起動できるようにするには、ルールに対するアクセス権限を付与する必要があります。

ベスト・プラクティスとして、同様のユーザー・アクセス権を持つビジネス・ルールをフォルダに編成し、フォルダにセキュリティを適用してください。個々のビジネス・ルールに対するアクセス権限を付与することもできますが、この方が少し時間がかかります。

ユーザーは、より詳細なアクセス権を割り当てられていないかぎり、アクセス権を割り当てられているフォルダ内のCalculation Managerビジネス・ルールに対する「起動」アクセス権を持ちます

タスク・リストに対するアクセス権の割当て

アプリケーションをナビゲートするには、個々のタスク・リストに対するアクセス権をユーザーに割り当てる必要があります。

ベスト・プラクティスとして、グループを使用してアクセス権を割り当ててください。これは、個々のタスク・リストにアクセス権を適用するよりも効率的です。

レポートに対するアクセス権の割当て

ユーザーがレポートを使用できるようにするには、それに対するアクセス権を割り当てる必要があります。

他のアーティファクトと同様に、レポートをフォルダに編成し、フォルダ・レベルでアクセス権を割り当てることをお薦めします。これにより、セキュリティに必要な保守が軽減します。レポートがフォルダに追加されると、そのフォルダからアクセス権が継承されます。

承認の構築

承認を使用して、予算を追跡し、ステータス、プランニング・ユニットの所有者およびプロセスの問題を確認します。これにより、プランニング・サイクルに要する時間が短縮されます。

承認を得るためにプランまたは予測がたどる必要がある経路を反映するように、組織構造から独立した承認経路を設定します。

ユーザーは、送信内容に関する注釈やコメントを入力できます。

プランニング・ユニット階層の設定

プランニング・ユニット階層の設定では、承認で使用する移動パスを定義します。プランニング・ユニット階層の基礎は、エンティティ、またはエンティティ・ディメンションの一部と任意のセカンダリ・ディメンションを組み合せたものです。

セカンダリ・ディメンションは、ワークフロー内の場所に応じて、様々なディメンションの組合せである場合があります。たとえば、特定のエンティティの移動パスではエンティティ・ディメンションを製品ディメンションと組み合せ、他のエンティティの移動パスではチャネル・ディメンションを使用できます。

所有者および確認者にプランニング・ユニットを直接割り当てることができます。検証ルールを作成して、データの状況に依存する条件付きの移動パスを処理することもできます。組織内のレビュー・プロセスをサポートする様々なプランニング・ユニット階層を作成します

その後、プランニング・ユニット階層をシナリオとバージョンの適切な組合せに割り当てます。

プランニング・ユニットはシナリオ、バージョンおよびエンティティまたはエンティティの一部の組合せです。シナリオとバージョンはレビュー・サイクルの基礎です。プランニング・ユニット階層には、レビュー・プロセスの対象となるプランニング・ユニットとその他の任意のディメンションが含まれます。

承認について次のことを理解しておく必要があります。

レビュー・プロセスは、プランニング・ユニットに対して所有者および確認者を選択したときに設定した移動パスに沿って行われます。ただし、イベントにより移動パスの変更がトリガーされた場合は異なります。
プランニング・ユニット階層メンバー間の親/子関係はレビュー・プロセスに影響します
ユーザーが親を上位へ移動するか拒否すると、その親の子は承認されないかぎり上位へ移動されるか、拒否されます。親の所有者は子の所有者になります。
ユーザーが親を承認すると、その子は承認されます。
すべての子が同じ所有者に上位へ移動されると、親は所有者に移動されます。
すべての子のステータスが1つのステータス、たとえば「サインオフ済」に変更されると、親のステータスも同じステータスに変更されます。
子に別の所有者がいる場合、ユーザーは親のステータスを変更できません。
子が異なるユーザーによって上位へ移動、送信またはサインオフされた場合、親には所有者がなく、サービス管理者のみがそのステータスを変更できます。
予算プロセスが完了するまで、プランニング・ユニットは確認者間を移動します。

テスト

テストは、アプリケーション開発の重要なステップです。すべての計算、アクセス権およびレポートをテストして、適切に動作することを確認する必要があります。

ユニット・テストについて

ユニット・テストは、形式化されたテストの最初のステップであり、テスト環境の主要なビルディング・ブロックです。ユニット・テストでは、アプリケーションの各機能領域を独立した単位としてテストして、予期したとおりに動作することを確認します。

たとえば、あるテストでは、データ・ロードが最後までエラーなしで実行されることを確認できます。他のテストでは、フォームやレポートにアクセスできることや、計算が完全であることなどを確認できます。

通常は、アプリケーションを構築または構成した人物がユニット・テストを実施します。

システム・テストについて

システム・テストでは、システムがエラーなしで動作し、必要な機能を備えていることを検証します。

主な重点は、アプリケーションがどのように構成されているかをテストすることと、チームがビジネス・プロセスおよびレポートをどのように構築しているかを検討することです。システム・テストでは、固有のパラメータ構成、使用されるすべての機能、機能強化など、システム全体のテストに焦点が置かれます。

また、システム・テストでは、ソフトウェアの先に目を向けて、手動手順、フォームおよびコントロールの有効性を検証します。これは、構築しているシステム内の機能のあらゆる側面を網羅する、正式な機能テストの完全なセットです。

多くの場合、このタイプのテストは次のものと組み合せて実施されます。

セキュリティ・テスト: システム全体および特定の各ユーザーについてシステム・セキュリティとデータベース・セキュリティが適切であることをテストします。
統合テスト- 統合された他のシステムとの間のデータのやり取りなど、ビジネス・ソリューション全体をテストします。ここでは、システムのすべての側面が統合されたときにも機能が有効なままであることを確認します。
ユーザー承認テスト: システムが正しく動作し、要件を満たしていることをユーザーが検証します。ユーザーが正式なシステム・テストに関与していない場合や詳細なテストを要求した場合、さらに承認テストが必要になることがあります。ただし、ユーザーがシステム・テストおよび統合テストを承認のために十分であると認めていれば、ほとんどの場合、このタイプのテストはそれらのテストの一部として実施されます。

ロールアウト

ロールアウト時に、エンド・ユーザーに対してシステムのトレーニングを行い、ナビゲート方法や機能の使用方法を示すことができます。ベスト・プラクティスとして、必要に応じて他のユーザーが管理を引き継げるようにシステムを文書化してください。

トレーニング

システムのすべてのユーザーがアプリケーションのトレーニングを受ける必要があります。ユーザーは、アプリケーションを快適にナビゲートする方法を学習し、各自に割り当てられたタスクを理解する必要があります。トレーニングには、アプリケーションへのログイン、タスク・リストのナビゲート、データの入力、ルールの実行、Smart Viewの使用およびアプリケーション内のツールの使用が含まれている必要があります。トレーニングは通常、ユーザーがアプリケーションに初めて触れる機会となるため、十分に計画され、考えられたトレーニング・セッションにより、第一印象をよくすることができます。

システムおよび管理情報の文書化

アプリケーションを構築したら、アプリケーションに関するシステムおよび管理ドキュメントを作成することをお薦めします。

ベスト・プラクティス:

構築プロセスが終わると、情報が新しいときにこのドキュメントを作成します。
データのソース、アプリケーション構造、計算の仕組み、アプリケーションに必要な保守などの情報を含めます。

月次保守や年次保守など、保守タスクを時間枠に分割してリストします。これにより、必要に応じて他のユーザーが後でシステムを引き継ぐことができます。

ユーザーに対するアプリケーションの有効化

エンド・ユーザーに対してアプリケーションを有効にするには、システムを解放して使用できるようにする必要があります。さらに、プランニング・ユニットを開始してプ承認を有効にします。

プランニング・ユニットの開始

ユーザーがシステムにアクセスしてレビュー・プロセスを開始できるようにするには、プランニング・ユニットを開始する必要があります。プロセスが開始されると、プランニング・ユニットは、プロセスが完了するまで確認者間を移動します。