承認ワークフロー構成タスク
適切に設計された承認ワークフローにより、適切な担当者が適切なタイミングでトランザクションとドキュメントをレビュー、ルーティング、処理できるようになります。 次のステップは、Oracle Project Managementの推奨構成順序に従います。
各ステップについて、概要、関連要素に関する重要な詳細、実際的な例、および重要な考慮事項が記載されています。
1. 参加者
まず、承認およびワークフロー アクションに関与するユーザーを指定します。 通常、次の操作を行います。
- 特定の指名承認者である個々のユーザー。
- ロール。プロジェクト・マネージャや財務ディレクタなどのジョブ機能を表します。
- 承認グループ: 集団承認のために設定されたユーザーまたはロールのコレクションです。
例: プロジェクトABCのすべての要求をJohn Doeに割り当て、プロジェクト・マネージャに予算変更の承認を許可するか、プロジェクト・ファイナンス・レビュー・グループを使用して主要なプロジェクト・コストを設定します。
関係者のリストを確認して職務分掌を確実にすることで、関係者のデータを正確かつ最新の状態に保つことが重要です。
2. リスト・ビルダー
次に、ワークフローでタスクを選択し、参加者に割り当てる方法を決定します。 多くの場合、次のようなオプションがあります。
- 監督階層やポジション階層などのロジックを使用する事前定義済リスト・ビルダー。
- 組織構造または承認要件に合せたカスタム・リスト・ビルダー。
例: 監督ルーティングを使用して、ユーザーのマネージャにリクエストを送信するか、または価値の高い契約を法的レビューに送信するカスタム・リストを作成します。
選択したリスト・ビルダー・タイプが現在のビジネス・ニーズに適合していることを確認し、組織の変更後に再検討してください。
3. 承認ルール
承認ワークフローをトリガし、リクエストをルーティングする方法を形成するロジックおよび条件を定義します。 次の点を考慮します。
- ルール条件。ワークフローの開始時期(金額、ビジネス・ユニットまたはプロジェクト・タイプなど)を指定します。
- ルール アクション。条件が満たされた場合に次のステップを指定します。
- 評価に関連するルールをグループ化するルールセット。
例: プロジェクト・コスト調整が$10,000を超える場合は、承認を開始し、財務ディレクタに送信します。
ルールを定期的に確認、更新、テストして、現在のビジネスおよびコンプライアンスのニーズに確実に対応します。
4. ワークフロー・ステップ/ステージ
プロセスの各ステージをレイアウトして、承認の順序をグラフ化します。 手順には次のものが含まれます。
- 設定された順序での承認の順次ステップ。
- 複数のパーティによる同時レビューのパラレル・ステップ。
- ビジネス要件に基づいて含まれる、またはスキップされる条件ステップ。
例: プロジェクト・マネージャから財務ディレクタに承認を順番にルーティングするか、コンプライアンス・コントローラとコスト・コントローラの両方を並行してレビューします。金額が$1,000未満の場合は、財務ディレクタをスキップします。
ワークフロー構造がビジネスの現実を反映していることを確認し、複数のシナリオをテストして信頼性を確保します。
5. ルーティング・ロジック
承認タスクがワークフロー・ステップ間でどのように移動するかを検討します。 ルーティングは次の方法で処理できます。
- シリアル・ルーティング。タスクが1つずつ進行します。
- パラレル・ルーティング(同時レビュー用)。
- 条件付きルーティング。データまたは条件によって承認パスが決まります。
- フォールバック・ルーティング。ルートに沿って例外または障害を処理します。
例: プロジェクト・マネージャから財務(シリアル)へ、法令およびコンプライアンス(パラレル)へ、またはトランザクションがEMEA(条件付き)からのものである場合はEMEA承認グループへ。
ルーティングを明確かつ柔軟に保ち、要件が進化するにつれて定期的に検証することを忘れないでください。
6. 通知メカニズム
ワークフロー中に参加者に情報を提供し、応答性を維持する方法を設定します。 通知は次のようになります。
- ユーザーの受信ボックスにEメール通知が送信されます。
- Fusion Applicationsインタフェースに表示されるアプリケーション内通知。
- リマインダ。保留中または期限超過の処理に対してトリガーされます。
- 時間がかかる承認または遅延承認のエスカレーション・アラート。
例: 新しい承認割当をEメールで送信します。処理が2日後に期限超過した場合はリマインダを生成し、エスカレーションが発生した場合は監督者にアラートを生成します。
通知が確実に配信され、ユーザーに表示されることを再確認します。
7. エスカレーション/委任
ワークフローの遅延を回避するために、タスクの遅延または参加者が使用できない場合に代替を計画します。 次のような要素を検討します。
- 期限後にタスクをチェーン上に移動するエスカレーション・ルール。
- ユーザーが一時的に自分の職責を他のユーザーに割り当てられるようにする委任設定。
- 元の割当先がない場合は、承認者をバックアップできます。
例: 3日後にタスクを部門長にエスカレートするか、財務マネージャが離職中に承認を委任できるようにします。
これらのポリシーを明確に定義し、すべてのユーザーが自分の選択肢を理解できるように伝達します。
8. 承認処理
関係者が各承認ステージで実行できるアクションを指定し、プロセス・フローおよび監査可能であることを確認します。 通常のアクションは次のとおりです。
- ワークフローの進行または完了を承認します。
- 拒否: プロセスの送り返しまたは停止。
- 処理の前に詳細を明確にする情報を要求します。
- 再割当して、別の適格ユーザーにタスクを渡します。
- 決定を記録するための「コメント」または「ノート」フィールド。
例: 次のステージでプロジェクトを承認し、予算転送を否認して事由を指定し、さらに文書を要求するか、別のプロジェクト・マネージャに再割当します。
各ステップで必要なアクションのみを有効にし、コンプライアンスのための完全な監査証跡を確保します。