承認の設計に関する考慮事項

正確なレポート、分析およびパフォーマンス管理を遂行するには、ディメンションを効果的に設計することが重要です。

承認を設計する際は、次のプラクティスに従ってください。

承認の構築

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

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

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

承認階層の設定

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

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

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

その後、階層をシナリオとバージョンの適切な組合せに割り当てます。

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

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

  • レビュー・プロセスは、プランニング・ユニットに対して所有者および確認者を選択したときに設定した移動パスに沿って行われます。ただし、イベントにより移動パスの変更がトリガーされた場合は異なります。

  • メンバー間の親/子関係はレビュー・プロセスに影響します

  • ユーザーが親を上位へ移動するか拒否すると、その親の子は承認されないかぎり上位へ移動されるか、拒否されます。親の所有者は子の所有者になります。

  • ユーザーが親を承認すると、その子は承認されます。

  • すべての子が同じ所有者に上位へ移動されると、親は所有者に移動されます。

  • すべての子のステータスが1つのステータス、たとえば「サインオフ済」に変更されると、親のステータスも同じステータスに変更されます。

  • 子に別の所有者がいる場合、ユーザーは親のステータスを変更できません。

  • 子が異なるユーザーによって上位へ移動、送信またはサインオフされた場合、親には所有者がなく、サービス管理者のみがそのステータスを変更できます。

  • 承認ユニットは、予算プロセスが完了するまで確認者間を移動します。

詳細は、承認の管理を参照してください。