Odoo 承認: 承認ワークフローの構成

どの組織にも、行動の前に承認が必要な意思決定があります。しきい値を超える注文。限度額を超えた費用の払い戻し。割引の承認。資本支出の要求。採用、給与変更、一定期間を超えた休暇などの人事行動。構造化された承認システムがなければ、これらの決定は非公式の電子メールチェーンを通じて行われ、時間がかかり、一貫性がなく、文書化されておらず、監査も不可能です。 Odoo 19 Enterprise Approvals モジュールは、完全な文書化、モバイルアクセス、および実際に作業が行われるモジュールとの統合を備えた、組織全体の承認プロセスを標準化する構成可能なマルチレベルの承認ワークフローシステムを提供します。

このガイドでは、承認タイプ、承認者の構成、マルチレベルチェーン、要求者のエクスペリエンス、モバイル承認、他の Odoo モジュールとの統合、承認分析など、Odoo 承認の完全な構成について説明します。最終的には、非公式の承認プロセスを構造化された監査可能なワークフローに置き換える青写真が得られます。

重要なポイント

承認が必要なビジネスプロセスごとに承認タイプを設定する

条件付きルーティングを使用して、順次および並列のマルチレベル承認チェーンを設計する

承認が期限を過ぎた場合の自動エスカレーションを設定する

保留中の承認について電子メールとモバイルのプッシュ通知を有効にする

承認を購買、経費、人事、およびカスタムビジネスプロセスと統合する

コンプライアンスとガバナンスのための完全な承認監査証跡を維持する

申請者に承認リクエストのステータスをリアルタイムで可視化します。

レポートを通じて承認サイクルタイムとボトルネックの特定を分析します。

承認モジュールのアーキテクチャを理解する

Odoo 承認モジュールは、承認タイプ (承認できるもの)、承認リクエスト (個々の承認インスタンス)、および承認者 (承認できる人) の 3 つの概念を中心に構築されています。

テンプレートとしての承認タイプ: 各承認タイプは、承認が必要な意思決定のカテゴリを定義します。一般的な承認タイプには、購入リクエスト (5,000 ドル以上)、経費報告書 (500 ドル以上)、時間外労働の承認、割引承認 (15% 以上)、設備投資、新規ベンダーのオンボーディング、および従業員の給与変更が含まれます。承認タイプはテンプレートです。そのタイプの個々のリクエストはすべて、テンプレートで定義されているのと同じルーティングと基準に従います。

インスタンスとしてのリクエスト: 従業員が承認を開始すると、関連する承認タイプのインスタンスである「承認リクエスト」が作成されます。リクエストには特定の詳細 (金額、製品、従業員、日付) が含まれており、承認タイプテンプレートで定義されたルーティングに従います。各リクエストには独自のライフサイクルがあります: [ドラフト] > [送信済み] > [承認/拒否] で、各ステップにタイムスタンプとユーザー属性が含まれます。

承認者と承認チェーン: 承認者は、承認リクエストをレビューして承認 (または拒否) するユーザーです。承認チェーンでは、誰がどのような順序で承認する必要があるか、レベル内のすべての承認者が承認する必要があるのか、1 人だけが承認する必要があるのかなど、承認者の順序が定義されます。マルチレベルのチェーンは、部門マネージャー、部門ディレクター、CFO の順にルーティングでき、各レベルの承認が次の承認をトリガーします。

承認タイプの作成

[承認] > [構成] > [承認タイプ] > [新規] に移動して、新しい承認タイプを作成します。構成フォームは、承認ワークフローのあらゆる側面をカバーします。

基本構成:

名前: 明確で具体的な名前 (例: 単なる「購入リクエスト」ではなく「購入リクエスト - 5,000 ドル以上」)
カテゴリ: フィルタリングとレポートの承認タイプを分類します (財務、人事、運用、IT)
マネージャーの承認: 要求者の直属のマネージャーが承認する必要があるかどうかを切り替えます (組織階層に基づいて自動の第 1 レベルの承認を追加します)。
自動承認: 基準が満たされた場合にリクエストを自動承認できるかどうか (例: 2 番目のしきい値を下回る金額には承認が必要ありません)
有効期限: 承認リクエストが実行されなかった場合、設定された時間が経過すると承認リクエストが期限切れになるかどうか

承認連絡先 (承認者): このタイプのリクエストを承認する必要がある特定のユーザーまたはユーザーグループを追加します。各承認者の構成オプション:

承認タイプ: 必須 (承認する必要があります)、オプション (承認できますが必須ではありません)、または拒否のみ (拒否できますが承認できません - コンプライアンスのレビュー担当者に役立ちます)
順序: 承認者が連続ワークフローでリクエストを受け取る順序。
電子メール通知: 承認が必要な場合に電子メールで通知するかどうか

承認製品とフォーム: このタイプの承認リクエストフォームにカスタムフィールドを追加します。購入リクエストのタイプでは、ベンダー名、ビジネス上の理由、予算コード、および見積書の添付が必要になる場合があります。資本支出タイプでは、プロジェクトコード、ROI 計算、マネージャーのサインオフステートメントが必要になる場合があります。カスタムフィールドはこのタイプのすべてのリクエストに表示されるため、レビュー前に完全な情報が確保されます。

順次承認チェーンと並行承認チェーン

承認チェーンの構造によって、リクエストが組織内をどのように流れるかが決まります。

順次承認: 承認者には一度に 1 人ずつ順番に通知が送信されます。レベル 1 (直属のマネージャー) が最初にリクエストを受け取ります。承認されると、レベル 2 (部門長) に通知されます。レベル 2 が承認されると、レベル 3 (CFO または CEO) に通知されます。各承認者は前のレベルが承認した後にのみ行動するため、通知のフラッディングを防ぎ、各承認者は前のレベルがリクエストをレビューしたことを確実に認識できます。

並行承認: あるレベルのすべての承認者に同時に通知されます。いずれか 1 つが承認できます (または全員が承認する必要があります (構成可能))。これは、承認が任意の順序で行われる可能性がある場合、または主承認者が不在の場合にバックアップ承認者が対応できる必要がある場合に適しています。 3 人の IT マネージャーが同時に通知される並行承認チェーンにより、2 人のマネージャーが出張中でもシステムアクセス要求を確実に承認できます。

混合チェーン: 同じチェーン内でシーケンシャルとパラレルを組み合わせます。レベル 1 は直属のマネージャーです (順次 - 必須)。レベル 2 は 2 人の IT セキュリティ担当者です (並列 - どちらかが承認可能)。レベル 3 は CISO (順次 — 必須) です。この柔軟性により、現実世界の複雑な認証要件に対処できます。

条件付きルーティング: ルーティングがリクエストの詳細に依存する承認タイプの場合、Odoo 自動化ルールを使用して、リクエストの値に基づいて承認チェーンを変更します。 $50,000 を超えるリクエストは、$5,000 ～ $50,000 のリクエストよりも長いチェーンにルーティングされます。研究開発部門からのリクエストは CTO に送られます。営業ルートから営業担当副社長へのリクエスト。この条件付きルーティングにより、単一の承認タイプをさまざまなシナリオにわたって柔軟に保つことができます。

リクエスターのエクスペリエンス

承認リクエストを作成および追跡するための従業員エクスペリエンスは、導入にとって非常に重要です。複雑でわかりにくい承認システムはバイパスされ、その目的が無効になります。

リクエストの作成: [承認] > [私のリクエスト] > [新しいリクエスト] に移動します。ドロップダウンメニューから承認の種類を選択します。フォームには、そのタイプに定義されたカスタムフィールドが事前に入力されます。必要な情報を入力し、添付書類（見積書、経費領収書、パフォーマンスの正当性）を添付して送信します。

リクエストステータスの追跡: 送信後、リクエストの送信者は、承認ダッシュボードでリクエストの現在のステータス (現在どの承認者がリクエストを持っているか、待機している時間、およびこれまでの承認履歴) を確認できます。マネージャーに「私のリクエストはもう承認されましたか?」とメールで問い合わせる必要はありません。 — ステータスが一目でわかります。

電子メール通知: 申請者は、提出の確認、承認者の名前とコメントを含む各承認または拒否、最終的な承認または拒否など、主要なステータス変更時に電子メール通知を受け取ります。通知メールには、クイックアクセスのリクエストへの直接リンクが含まれています。

承認コメント: 承認者は、承認または拒否するときにコメントを追加できます。これらのコメントは要求者に表示され、承認監査証跡に保存されます。理由を説明するコメント付きで拒否されたリクエストは、リクエスト者に再送信のための実用的なフィードバックを与えます。

拒否後の再送信: リクエストが拒否された場合、要求者は根本的な問題を修正して再送信できます。再送信すると、新たな承認チェーンが開始されますが、前回の試行の履歴は維持されます。承認者は、これが再送信であり、何が変更されたかを確認できます。

承認者の経験

承認者には、保留中のリクエストを確認して対応するためのスムーズな方法が必要です。承認プロセスの遅れはビジネスの速度を低下させます。

承認ダッシュボード: [承認] > [承認するには] に移動して、承認を待っている保留中のリクエストをすべて表示します。リストには、リクエストのタイプ、リクエスト者、送信日、待機時間、概要情報が表示されます。ワンクリックでリクエストの詳細が開き、確認できます。

電子メールからの承認: 電子メール通知には、リクエストの概要と、[承認] と [拒否] の 2 つのボタンが含まれます。承認者は Odoo にログインせずに行動できます。電子メール内のボタンをクリックすると、最小限の承認インターフェイスが開きます (または、ワンクリック承認が設定されている場合は直接行動します)。これは、Odoo に住んでいない多忙な経営幹部にとって特に価値があります。

モバイルからの承認: Odoo モバイルアプリでは、通知センターに保留中の承認が表示されます。承認者は、新しいリクエストに注意が必要な場合にプッシュ通知を受け取ります。ワンタップで電話から直接確認して承認します。

承認の委任: 承認者が不在の場合 (休暇、旅行、医療休暇)、委任を構成します。定義された期間、別のユーザーが承認の責任を負います。代替は文書化され、承認が無期限に滞ることがないようにしながら説明責任を維持します。

一括承認: 同様のリクエストが複数保留されている場合 (月末の経費報告書など)、リストから複数のリクエストを選択し、一括で承認します。個別のレビューが必要ない日常的な承認の場合、一括承認により承認者の時間が大幅に短縮されます。

エスカレーションと期限切れの管理

承認リクエストが返答されないまま放置されると、リクエスト者をイライラさせ、ビジネスの速度を低下させるボトルネックになります。

エスカレーションのタイミング: 承認の種類ごとにエスカレーションポリシーを構成します。X 時間以内に対応されない場合は、承認者にリマインダーを送信します。 Y 時間が経過しても何も対応されない場合は、承認者のマネージャーにエスカレーションします。この自動エスカレーションにより、承認が黙って無視されることがなくなります。

期限超過の可視性: 承認マネージャーは、承認タイプ、承認者、または待機時間ごとにフィルタリングして、組織全体のすべての期限超過リクエストを表示できます。この可視性により、遅延が障害となる前に積極的な介入が可能になります。

SLA モニタリング: 承認タイプごとに SLA 目標を設定します (例: すべての経費承認は 24 営業時間以内に処理する必要があります。1,000 ドル未満のすべての購入リクエストは 4 時間以内に処理する必要があります)。承認レポートで SLA 準拠を追跡し、慢性的な遅延が発生している承認者または承認の種類を特定します。

休暇モード: ユーザーが Odoo で不在者として設定すると、ユーザーに割り当てられた承認リクエストを、指定されたバックアップ承認者に自動的に再ルーティングできます。これにより、計画的な欠勤中に承認キューがバックアップされるのを防ぎます。

他の Odoo モジュールとの統合

Odoo Approvals の真の力は、実際のビジネス上の意思決定が行われる運用モジュールとの統合です。

購入の承認: しきい値を超える注文に対して承認を要求するように購入モジュールを構成します。営業担当者または購入者が $5,000 を超える注文書を作成すると、その注文書は編集のためにロックされ、購入承認リクエストが自動的に生成され、定義されたチェーンを介してルーティングされます。発注書は、承認が得られた後にのみ実行可能になります。

経費の承認: 経費モジュールには承認統合が組み込まれています。経費レポートは、送信時に自動的に承認リクエストを生成します。多額の経費報告書に対してマルチレベルの承認を設定します (例: 1,000 ドルまでの金額についてはマネージャーの承認、1,000 ドルから 5,000 ドルまでの場合はディレクターの承認、5,000 ドルを超える場合は CFO の承認)。

人事承認: 承認モジュールを人事アクションに接続します。残業が週 10 時間を超えると、人事マネージャーへの承認リクエストがトリガーされます。連続 5 日を超える休暇にはマネージャーと人事部長の承認が必要です。給与変更リクエストには部門長と人事部長の承認が必要です。

カスタム承認: ネイティブ Odoo モジュール統合のないビジネスプロセスの場合は、承認モジュールをスタンドアロンプロセスとして使用します。専用のモジュールワークフローを持たないビジネス上の意思決定については、従業員であれば誰でもカスタム承認リクエストを送信できます。この柔軟性は、承認が組織のユニバーサルガバナンス層になることを意味します。

監査証跡とコンプライアンス

正式な承認システムの中核となる価値の 1 つは、それによって作成される監査証跡です。

完全な承認履歴: すべての承認リクエストには、誰が、いつ、どのような情報を使用して作成したかという完全な履歴が保持されます。各レベルで誰に通知されたか。誰が承認または拒否したか、いつ、どのようなコメントが追加されたか。そして最終的な結末。この履歴は不変であり、事後に編集することはできません。

監査用にエクスポート: 規制遵守、財務監査、または SOX 準拠のために、承認記録を PDF または Excel としてエクスポートします。期間、承認タイプ、または承認者でフィルターして、必要な証拠パッケージを正確に作成します。エクスポートには、すべてのリクエストの詳細と完全な承認チェーン履歴が含まれます。

職務分掌の証拠: 職務分掌を必要とする財務管理 (購入リクエストを作成する人がそれを承認する人と同じであることはできません) の場合は、承認チェーンからリクエスト者を自動的に除外するように承認タイプを構成します。承認履歴は、必要な分離が維持されたことを示す証拠を提供します。

ポリシーの遵守: 時間の経過とともに、承認ポリシーが一貫して遵守されているかどうかが承認履歴に表示されます。発注書が権限のない個人によって定期的にしきい値を超えて承認される場合、承認モジュールはこれを捕捉し、単にポリシーが存在するだけでなくポリシーを適用できるようにします。

承認の分析とレポート

承認量レポート: [承認] > [レポート] > [承認分析] に移動します。リクエストの数をタイプ、期間、リクエスト者の部門、ステータスごとに表示します。ボリュームをタイプごとに理解すると、どのプロセスが最もアクティブであり、最適化に最も影響を与えるかを特定できます。

サイクルタイム分析: リクエストが各承認レベルを通過するのにかかる時間を測定します。ボトルネック、つまりサイクル時間が一貫して長い承認タイプまたは特定の承認者を特定します。このデータは、会話のコーチング (頻繁に遅延する承認者)、プロセスの再設計 (関連するリスクに対して長すぎる承認チェーン)、または人員配置の決定 (1 人の能力を超える承認負荷) に使用します。

拒否分析: 承認タイプおよび承認者ごとに拒否率を追跡します。高い拒否率は、要求者が準拠していない要求を提出しているか (トレーニングまたは明確さの問題)、または承認基準がビジネスニーズに対して厳しすぎる (ポリシーのレビューが必要) ことを示しています。拒否率が低いということは、承認者が要求に有意義に関与していないというゴム印を示している可能性があります。

よくある質問

部門ごとに承認の種類を異なるように設定できますか?

はい。部門ごとに承認タイプのバリアントを作成するか、条件付きルーティングルールで単一のタイプを使用します。たとえば、「出張リクエスト」承認タイプでは、要求者の部門を検出し、それに応じて承認者チェーンを変更する自動化ルールを使用して、IT 部門のリクエストを IT ディレクターにルーティングする一方で、営業部門のリクエストを営業担当副社長にルーティングできます。

しきい値を下回る小さなリクエストを自動承認するように承認を構成できますか?

はい。人間によるレビューを行わずに、しきい値を下回るリクエストを承認する自動承認ルールを構成します。 50 ドル未満の経費は自動承認できます。 50 ドルから 500 ドルまでのリクエストにはマネージャーの承認が必要です。 500 ドルを超えるリクエストにはディレクターの承認が必要です。自動承認はリクエスト履歴に記録されるため、監査証跡が維持され、日常的でリスクの低いリクエストに対する不必要な摩擦が排除されます。

承認者が休暇中の場合、Odoo は承認リクエストをどのように処理しますか?

ユーザーの設定で不在時の委任を構成します。ユーザーが自分自身を不在としてマークすると、すべての保留中の承認リクエストが、不在期間中に指定された代理人に自動的に転送されます。通常はデリゲートにルーティングされる新しいリクエストも、この期間中はデリゲートにルーティングされます。ユーザーが戻って不在ステータスをキャンセルすると、ルーティングは通常に戻ります。

リクエスト値ごとに異なるドキュメントを必要とする承認ワークフローを設定できますか?

はい。承認リクエストフォームの条件付き必須フィールドを使用します。ルールを設定します。要求された金額が $10,000 を超える場合、[ベンダー見積 (3 つ必須)] フィールドが必須になります。このしきい値を下回る場合はオプションです。これにより、小規模なリクエストに不必要な事務処理の負担を負わせることなく、価値の高いリクエストに対して適切な文書化が保証されます。

組織全体の保留中の承認の合計値を確認する方法はありますか?

はい。承認分析レポートは、「保留中」リクエストのみを表示するようにフィルター処理したり、承認タイプごとにグループ化したりできます。承認タイプに金額フィールド (財務上の承認に必要) が含まれている場合は、保留中のリクエスト全体の値を合計して、承認を待っている合計財務エクスポージャーを確認できます。この集計ビューは財務およびキャッシュフローの予測に役立ちます。

Odoo は電子メールの代わりに WhatsApp や Slack 経由で承認通知を送信できますか?

電子メールとプッシュ通知 (モバイルアプリ経由) が標準の通知チャネルです。 WhatsApp 通知の場合、Odoo 19 Enterprise の WhatsApp 統合は、このチャネルを好む承認者に WhatsApp 経由で承認通知を送信するように構成できます。 Slack の場合、新しい承認が作成されるとカスタム自動化ルールが Slack Webhook に投稿され、Slack メッセージがトリガーされます。これらの統合には追加の構成が必要ですが、Odoo の自動化および Webhook 機能によってサポートされます。

承認された決定が実際に正しく実装されていることを確認するにはどうすればよいでしょうか?

Odoo の承認は、下流のアクションを制御するように設計されています。モジュールに統合された承認タイプ (購入、経費) の場合、基になるレコードは承認が付与されるまでロックされます。それ以外の場合は単純に処理できません。スタンドアロンの承認リクエストの場合、実装はプロセス設計によって異なります。承認後のリクエストに対して「次のアクション」アクティビティを構成し、実装タスクを関連者に割り当て、フォロースルーの責任を負います。

次のステップ

Odoo Approvals は、非公式の電子メールベースの承認プロセスを、構造化され文書化されたモバイルからアクセス可能なワークフローに置き換え、官僚的な遅延を引き起こすことなく組織に必要なガバナンスを提供します。承認プロセスが自動化され、測定可能になり、作業が行われるシステムと統合されると、組織はより迅速に、より適切な制御のもとで行動できるようになります。

ECOSIRE は、より広範な Odoo 実装の一部として Odoo Approvals を構成し、ガバナンス要件と承認階層に一致する承認ワークフローを設計します。当社の実装には、すべての主要なビジネスプロセスの承認タイプの設計、既存の Odoo モジュールとの統合、承認者と要求者の両方に対するトレーニングが含まれます。

承認ワークフローの実装については、Odoo サービスページにアクセスしてください。または、Odoo 19 Enterprise の高度な条件付きルーティング、外部承認者アクセス、コンプライアンスレポートダッシュボードなどの承認拡張機能については、マーケットプレイスモジュールを参照してください。

Odoo Approvals: Configuring Approval Workflows