経費管理データテンプレート

汎用プロセスマイニングテンプレート
経費管理データテンプレート

経費管理データテンプレート

汎用プロセスマイニングテンプレート

これは経費管理向けの汎用プロセスマイニング用データテンプレートです。より詳しい手順については、システム別のテンプレートをご利用ください。

特定のシステムを選択
  • 必須データ属性の一覧
  • 経費処理の主なアクティビティとマイルストーン
  • 任意のシステムで詳細なプロセス分析を行うための基盤
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

経費管理の属性

この表では、経費管理プロセスを詳しく分析し、インサイトを得るためにイベントログに含めることを推奨するデータ項目(属性)を紹介します。
5 必須 8 推奨 4 任意
名前 説明
アクティビティ名
ActivityName
経費レポートのライフサイクルで発生した、特定の業務イベントまたはタスクの名前です。
説明

アクティビティ名は、経費管理プロセスにおける個々のステップやステータス変更を表します。例として、「経費レポートの作成」「マネージャーによる承認」「ポリシー違反のフラグ設定」「払い戻しの実行」などがあります。これらのアクティビティが連なり、各経費レポートのプロセスフローを構成します。

プロセスマイニング分析では、実際のプロセスモデルを把握するために欠かせない属性です。プロセスマップを可視化し、アクティビティに時間がかかるボトルネックを特定したり、「レポートの修正依頼」のような手戻りを見つけたり、標準から外れたプロセスのバリアントを特定したりできます。アクティビティ名が明確で、適切な粒度で設定されているかどうかは、得られるインサイトの質に直接影響します。

重要な理由

この属性によってプロセスの各ステップが定まり、プロセスマップの可視化やワークフローのパターンと逸脱の分析が可能になります。

入手先

イベントログ、ステータス変更テーブル、または経費レポートに関連する取引記録から取得します。

例
経費申請の提出上司による承認財務部門による却下払い戻しの実行
イベント時刻
EventTime
特定のアクティビティまたはイベントが発生した正確な日時を示すタイムスタンプです。
説明

イベント時刻、つまりタイムスタンプは、アクティビティが発生した時点を記録します。各経費レポートのイベントを時系列に並べるために使われ、プロセスの流れを正確に再構成するうえで欠かせません。

プロセスマイニングでは、タイムスタンプが時間に基づく分析の基礎となります。アクティビティ間のサイクルタイム、プロセス全体の処理時間、待ち時間などの重要業績評価指標(KPI)の算出に使われます。タイムスタンプを分析することで、組織は承認プロセスの遅延を特定し、払い戻し処理の効率を測定し、サービスレベル合意に対する実績を監視できます。

重要な理由

イベントを時系列に並べ、サイクルタイムやボトルネックなど、所要時間に基づく指標を算出するうえで重要なタイムスタンプです。

入手先

イベントログや取引データにあり、「作成日」「タイムスタンプ」「イベント日」などの名前が付いていることがよくあります。

例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z2023-11-02T11:05:42Z
経費レポートID
ExpenseReportId
経費レポートを一意に識別するIDです。関連するすべてのアクティビティをまとめ、主要なケース識別子として機能します。
説明

経費レポートIDは、従業員が提出する各経費レポートに割り当てられる一意のキーです。作成・申請から承認、却下の可能性、最終的な払い戻しまで、プロセスのすべての段階をつなぐ軸となります。

プロセスマイニングでは、ケースを再構成するための基本となる属性です。経費レポートIDごとに、経費管理プロセスの1つのケースを表します。IDごとの流れを分析することで、プロセスフローを可視化し、個々のレポートのサイクルタイムを算出するとともに、レポートごとの処理の違いを特定できます。

重要な理由

経費レポートのライフサイクルにおけるすべてのイベントを結び付ける、不可欠なケース識別子です。プロセス全体を追跡できます。

入手先

通常、経費レポートのヘッダーレベルのデータ、または経費プロセスのメイン取引テーブルにあります。

例
ER-2023-08-15-001EXP7891234500012345RPT-FY24-Q1-582
ソースシステム
SourceSystem
経費管理データの抽出元となるシステム、アプリケーション、またはプラットフォームです。
説明

ソースシステム属性は、プロセスデータの取得元を示します。現在の企業では、経費管理に複数の連携システムが使われることがあります。たとえば、従業員データを管理する人事システム、申請専用の経費管理ツール、財務計上を行うERPなどです。この項目を使うと、異なる取得元のデータを区別できます。

この情報は、データの検証やプロセスを支えるシステム環境の把握に役立ちます。特定のシステムのデータにプロセス上の問題が集中している場合、連携やアプリケーション自体に問題がある可能性があります。また、データの背景を把握し、プロセスの各段階でどの情報が信頼できる唯一の情報源なのかを分析担当者が理解する助けにもなります。

重要な理由

データの取得元を特定できます。データガバナンスや問題の調査、異なるプラットフォーム間でのプロセスの違いを理解するうえで重要です。

入手先

この情報は、データ抽出プロセスやメタデータに含まれていることが多く、データの準備時に追加される場合もあります。

例
SAP ConcurExpensifyCoupaBrexRamp
最終データ更新日時
LastDataUpdate
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明

最終データ更新日時のタイムスタンプは、ソースシステムからデータを最後に抽出または同期した時点を示します。分析対象データの明確な基準時点となり、関係者全員がデータの鮮度を把握できます。

プロセスマイニングでは、この属性がデータの整合性とレポートの信頼性を保つうえで重要です。リアルタイムの情報を見ているのか、過去の時点のスナップショットを見ているのかを確認できます。特に、データの即時性が重要な継続監視用ダッシュボードでは欠かせません。また、予定どおりにデータが更新されているかを確認できるため、データパイプラインの問題調査にも役立ちます。

重要な理由

データの鮮度を明確にし、プロセス分析や監視用ダッシュボードの正確性と関連性を保ちます。

入手先

通常、データの読み込み時にデータ連携ツールまたはETL(抽出、変換、読み込み)ツールによって生成・保存されます。

例
2024-05-20T02:00:00Z2024-05-19T02:00:00Z2024-05-18T02:00:00Z
ポリシー違反フラグ
PolicyViolationFlag
経費レポートに1件以上のポリシー違反があると判定された場合に真となる、真偽値の指標です。
説明

ポリシー違反フラグは、経費レポートが会社の支出ポリシーに準拠していないと自動または手動で判定されたかどうかを示す真偽値です。違反には、支出上限の超過、未承認の取引先の利用、必要書類の不足などがあります。

このフラグは、コンプライアンス分析の重要な要素です。組織全体のポリシー違反率を算出し、違反が多い部門、経費カテゴリ、従業員を詳しく調べられます。ポリシー違反の頻度と内容を把握することで、ポリシーの見直し、自動チェックの改善、対象を絞った研修を行い、ポリシーに準拠しない支出やプロセス上の例外を減らせます。

重要な理由

ポリシーに準拠しないレポートを特定してコンプライアンスの監視を支援し、ポリシー違反の測定と削減に役立ちます。

入手先

経費レポートのヘッダーまたは明細データにあるフラグや項目です。システムのルールエンジンによって設定されることがよくあります。

例
truefalse
ユーザー
User
記録されたアクティビティを実行したユーザー、従業員、またはシステムアカウントの名前またはIDです。
説明

ユーザー属性は、特定のプロセスステップを実行した担当者または自動処理を識別します。レポートを申請する従業員、承認するマネージャー、払い戻しを処理する財務チームのメンバーなどが該当します。

ユーザーごとにプロセスを分析すると、業務負荷の分布や個人の実績を把握し、遅延の原因となっている担当者を特定できます。たとえば、特定のマネージャーが承認経路のボトルネックになっているかどうかがわかります。また、リソース配分の分析や、プロセス全体の説明責任と監査可能性の確保にも役立ちます。

重要な理由

各ステップの実行者を特定できるため、業務負荷の分析や実績の比較、特定の個人やチームに起因するボトルネックの特定に役立ちます。

入手先

イベントログまたは取引履歴にあり、ユーザーIDや従業員IDに紐付けられていることがよくあります。

例
john.doejane.smithapprover_team_leadsystem.batch.user
レポートのステータス
ReportStatus
「申請済み」「承認済み」「支払い済み」など、ライフサイクルにおける経費レポートの現在または最終のステータスです。
説明

レポートのステータスを見ると、プロセスのどの段階にあるか、または最終的にどうなったかを把握できます。通常、レポートが申請、承認、処理、支払いの各段階を進むにつれてステータスが変わります。

この属性を使うと、ケースを絞り込んで特定のグループを分析できます。たとえば、「却下」されたレポートだけに絞って却下理由を調べたり、「承認待ち」のレポートを対象に現在のボトルネックを調べたりできます。ダッシュボードでは、現在の業務量と処理中の経費レポートの状況を大まかに把握できます。また、プロセスマイニング用に生成されたアクティビティの順序を検証する際にも使えます。

重要な理由

レポートの状態を大まかに把握でき、ケースの絞り込みや現在の業務量を示す運用ダッシュボードの作成に役立ちます。

入手先

経費レポートのメインヘッダーテーブルにある項目で、ワークフローの進行に応じて更新されます。

例
承認待ち承認済み支払い済み却下取り下げ
却下理由
RejectionReason
経費レポートを却下、または修正のため差し戻した理由として、マネージャーや財務担当者が入力した内容です。
説明

却下理由は、経費レポートが承認段階を通過できなかった理由を説明するテキスト項目または定義済みコードです。よくある理由には、「領収書の不足」「カテゴリの誤り」「ポリシー違反の経費」などがあります。

この属性は、プロセスの手戻りの根本原因を分析するうえで非常に役立ちます。よくある却下理由を分析すると、組織全体に共通する問題を特定できます。たとえば、「領収書の不足」が最も多い場合、必要書類に関する周知を改善したり、領収書を添付しやすくしたりする必要があるかもしれません。こうしたインサイトをもとに改善策を絞り込み、初回承認率を高め、手戻りを減らし、全体のサイクルタイムを短縮できます。

重要な理由

プロセスで手戻りが発生する理由を明らかにし、却下率の低下と初回承認率の向上に向けた改善を可能にします。

入手先

承認者が「却下」または「差し戻し」の操作を行う際、コメント欄や選択リストから取得します。

例
領収書の不足経費カテゴリの誤り日当の上限超過経費の重複
合計金額
TotalAmount
払い戻しを申請した経費レポートの合計金額です。
説明

合計金額は、1件の経費レポートに含まれるすべての経費明細の合計です。この金額が承認と払い戻しの対象になります。

プロセスマイニングで財務分析を行ううえで欠かせない属性です。経費レポートを高額・低額などの金額帯に分けて分析できます。金額帯によって承認経路が異なることもあります。分析担当者は、この属性を使ってレポート1件あたりの平均コストを算出し、手戻りや却下による財務への影響を調べ、支出の傾向を特定できます。合計金額とサイクルタイムを照らし合わせれば、高額なレポートほど承認に時間がかかるかどうかもわかります。

重要な理由

財務への影響を分析し、支出の傾向を把握するとともに、レポートの金額に応じたプロセスの分類に役立ちます。

入手先

通常、経費レポートのヘッダーレベルのデータにあり、すべての明細金額の合計として算出されることがよくあります。

例
150.752500.0085.5012500.20
従業員の部門
EmployeeDepartment
経費レポートを申請した従業員が所属する事業部門または部門です。
説明

この属性は、申請した従業員が所属する「営業」「エンジニアリング」「マーケティング」などの組織単位を示します。経費を負担するコストセンターと紐付けられていることもよくあります。

従業員の部門は、比較分析の主な切り口です。部門で絞り込んでプロセスを確認すると、部門ごとの大きな違いがわかることがあります。たとえば、ある部門では別の部門よりポリシー違反率が大幅に高い、または承認のサイクルタイムが長いといった違いです。こうしたインサイトは、特定のチームを対象とした研修、プロセスの見直し、ポリシーの明確化が必要かどうかを判断するのに役立ちます。

重要な理由

事業部門間の比較分析ができ、部門固有の傾向やボトルネック、コンプライアンス上の問題を特定できます。

入手先

通常、経費レポートに紐付けられた従業員のマスターデータから取得します。

例
営業エンジニアリングマーケティング財務
申請者
Submitter
経費レポートを作成し、申請した従業員の名前またはIDです。
説明

申請者は、経費を負担し、経費レポートを作成して払い戻しプロセスを開始した従業員です。この属性は通常、1件の経費レポートに関連するすべてのイベントで共通です。

一般的な「ユーザー」属性が各ステップの実行者を示すのに対し、「申請者」はケース単位で一貫した属性となり、レポートの所有者である従業員の行動を分析できます。たとえば、レポートが頻繁に却下される従業員や、ポリシー違反を繰り返す従業員を特定し、従業員体験の観点から分析できます。こうした情報は、対象を絞った周知や研修に役立ち、プロセスの効率とコンプライアンスを申請時点から改善できます。

重要な理由

経費レポートの所有者を特定し、ポリシー違反を繰り返す従業員や手戻りの原因など、従業員の行動に基づく分析を可能にします。

入手先

通常、経費レポートのヘッダーデータにあり、レコードを作成した従業員に紐付けられています。

例
Alice JohnsonRobert WilliamsEMP10234s.chen
通貨
Currency
経費レポートの合計金額に使われる通貨コードです。USD、EUR、GBPなどがあります。
説明

通貨属性は、合計金額の通貨単位を示します。グローバルな組織では、従業員がさまざまな通貨で経費を申請するため、金額を正しく理解するうえでこの情報が必要です。

正確な財務分析、特に複数の国や地域をまたぐ分析には、この属性が欠かせません。金額を正しく解釈し、集計レポート用に共通通貨へ換算できます。この情報がなければ、円建てのレポートと米ドル建てのレポートの合計金額を比較しても意味がありません。地域ごとの支出合計、平均コスト、財務上の重要業績評価指標(KPI)を示すダッシュボードの基礎となる属性です。

重要な理由

すべての金額を正しく把握するための情報を提供し、地域や国をまたいだ正確な財務報告と比較を可能にします。

入手先

通常、経費レポートのヘッダーデータで金額項目とともに保存されます。

例
USDEURGBPJPY
承認者
Approver
経費精算書の承認を担当するユーザーの名前またはIDです。通常は、マネージャーや財務担当者が該当します。
説明

承認者属性は、ワークフローで承認または却下の手順を担当する人を示します。多くのプロセスでは、直属の上司の後に部門長や財務担当者が確認するなど、複数段階の承認が行われます。

「ユーザー」属性と同様に、承認者属性は、遅延の主な原因となることが多い承認段階の分析に役立ちます。承認者ごとの所要時間を測定し、ボトルネックを特定できます。ダッシュボードで承認者ごとの業務量や実績を確認すれば、リソースの調整や経費ポリシーに関する追加研修の必要性を判断できます。

重要な理由

承認を担当する人を特定し、承認の遅延、業務量、判断の一貫性を分析できます。

入手先

承認に関するアクティビティのイベントログまたは取引履歴に記録されます。

例
David ChenMGR1056財務承認キューsusan.g
支払い方法
PaymentMethod
「法人カード」や「立替払い」など、経費の支払い方法です。
説明

支払い方法は、従業員が経費をどのように支払ったかを示します。通常は、会社が発行した法人カードか、従業員が個人資金で立て替える方法のいずれかです。立替払いの場合は、従業員への精算が必要です。

この属性を使うと、主な2つのプロセスのバリアントを区別できます。法人カードでの取引はカード会社から直接データを取得できるため、確認手続きが比較的簡単な場合があります。一方、立替経費はより詳しい確認が必要で、従業員への直接の支払いも発生します。支払い方法別に分析すると、2つの流れのサイクルタイム、コンプライアンスの状況、処理コストの違いがわかります。法人カードの利用を促すことで効率を高められる可能性も見つけられます。

重要な理由

法人カードと個人資金による立替払いなど、リスク、効率、管理方法が異なる主なプロセスのバリアントを区別できます。

入手先

通常は経費明細単位で指定され、取引に使われた資金の種類を示します。

例
法人カード立替払い日当会社負担
監査結果
AuditOutcome
経費精算書に対して手動または自動で行われた監査の結果です。
説明

監査結果には、プロセス内の監査手順で確認された内容が記録されます。コンプライアンスルールを確認する自動システム監査の場合もあれば、財務チームや監査チームによる手動確認の場合もあります。結果には通常、「合格」「不合格」「例外付きで合格」などがあります。

この属性は、内部統制の有効性を直接測る指標になります。監査結果を分析することで、企業はリスクの状況や申請内容の品質を評価できます。統制が機能していない領域や、ポリシーが繰り返し誤解されている箇所の特定にも役立ちます。プロセスマイニングでは、監査結果とほかの属性を関連付け、特定の経費カテゴリや部門で監査の不合格率が高いかどうかなどを確認できます。

重要な理由

コンプライアンスと内部統制の確認状況を直接測定し、リスクや監査ルールの有効性を評価できます。

入手先

自動ルールエンジン、または確認を終えた監査チームや財務チームの担当者が更新する項目です。

例
合格不合格:文書の不足確認が必要例外付きで合格
経費カテゴリ
ExpenseCategory
「出張」「食事」「ソフトウェア」「事務用品」など、経費の分類です。
説明

経費カテゴリは、経費精算書の支出内容を分類するための属性です。複数の明細がある場合、1つの経費精算書に複数のカテゴリが含まれることがあります。

経費カテゴリ別にプロセスを分析すると、組織の支出傾向やカテゴリごとのプロセスの違いを把握できます。たとえば、「海外出張」の経費は、「事務用品」よりも承認に時間がかかり、手順が複雑になる場合があります。この属性を使うと、カテゴリごとのコンプライアンスを詳しく分析し、特定のカテゴリでポリシー違反が起きやすいかどうかを確認できます。財務計画や予算編成にも役立つ重要な項目です。

重要な理由

支出傾向を分析し、経費の種類によってプロセスの流れやコンプライアンスの状況に違いがあるかを確認できます。

入手先

通常は経費精算書の明細単位で記録されます。ケース単位で分析する場合は、集計するか、最も多くを占めるカテゴリを使用します。

例
航空運賃食事・接待費ソフトウェアのサブスクリプション事務用品宿泊費
必須 推奨 任意

経費管理のアクティビティ

経費処理のプロセスを正確に把握し、可視化するために記録する主な手順とマイルストーンを紹介します。
6 推奨 9 任意
アクティビティ 説明
上司による承認
従業員の直属の上司、または最初の承認者が経費申請を確認して承認した状態です。申請をワークフローの次の段階へ進める重要な判断点です。
重要な理由

最初の承認段階にかかる時間と効率を測定します。承認全体のサイクルタイムを算出するうえで重要な節目です。

入手先

承認者の操作とタイムスタンプを記録する、承認履歴または監査証跡のテーブルに記録されています。

記録

承認履歴から、マネージャーの役割を持つユーザーによる最初の「承認」アクションを抽出します。

イベントタイプ explicit
会計システムへの計上
経費データが会社の総勘定元帳またはERPシステムに正常に計上されたことを示す最終段階です。これにより、経費レポートの財務照合が完了します。
重要な理由

財務会計の観点から見たプロセスの実質的な終了点です。払い戻しからこのイベントまでの時間から、決算業務の効率を把握できます。

入手先

ERP連携ログ、または経費レポートが会計システムと同期されたことを示す最終ステータスから取得します。

記録

総勘定元帳への計上が正常に完了したことを示す連携ログのタイムスタンプを使用します。

イベントタイプ explicit
払い戻しの実行
従業員への支払いが正常に完了した時点を示すアクティビティです。従業員の視点では、これをもってプロセスが正常に完了します。
重要な理由

プロセスの重要な終了点となり、払い戻し全体にかかる時間を測定できます。従業員満足度を測るうえで重要な指標です。

入手先

通常、支払い処理ログ、または連携先の支払いシステムから送信される「支払い済み」や「払い戻し済み」などの最終ステータス更新から取得します。

記録

経費レポートに関連付けられた金融取引記録から、支払い実行日を使用します。

イベントタイプ explicit
経費申請の作成
従業員が新しい経費申請レコードを作成した時点で、プロセスが始まったことを示します。最初に記録されるイベントであり、追跡に使うケース識別子が確定します。
重要な理由

一連のプロセスの開始点を定め、作成から最終精算までのサイクルタイムを正確に測定できるようにします。

入手先

通常、経費申請のヘッダーデータに記録された作成時刻から取得します。

記録

経費申請のメインテーブルまたはオブジェクトに記録されたレコード作成時刻を使用します。

イベントタイプ explicit
経費申請の提出
従業員が完成した経費申請を正式に提出し、承認ワークフローが始まった時点で発生します。この操作によって、申請のステータスが下書きから承認待ちに変わります。
重要な理由

データ入力の終了と承認サイクルの開始を示す重要な節目です。この時点までの遅れはユーザー側で発生し、それ以降の遅れはプロセス側で発生します。

入手先

申請の履歴にあるステータス変更ログ、または明示的に記録された提出イベントのタイムスタンプから取得します。

記録

申請のステータスが「下書き」または「オープン」から「提出済み」または「承認待ち」に変わるイベントを特定します。

イベントタイプ explicit
財務部門での承認
財務または監査チームが確認を完了し、経費レポートを最終承認します。多くの場合、これは払い戻し処理の前に行われる最後の承認ゲートです。
重要な理由

最終承認の節目です。申請からこのイベントまでの時間が承認全体のサイクルタイムとなり、重要業績評価指標(KPI)の1つです。

入手先

承認者の詳細とともに、承認履歴または監査ログのテーブルに明示的なイベントとして記録されます。

記録

承認履歴から、通常は財務または監査の役割を持つユーザーが実行した最後の「承認」アクションを抽出します。

イベントタイプ explicit
ポリシー違反の検出
自動システムチェックまたは手動確認によって、経費が社内ポリシーに違反している可能性が特定されます。申請にポリシー違反のフラグや警告が設定された時点で、このイベントを記録します。
重要な理由

コンプライアンス上の問題を明らかにし、手戻りや差し戻しの主な原因を示します。フラグを分析することで、分かりにくいポリシーや従業員研修が必要な領域を特定できます。

入手先

システムログや例外テーブルで確認するか、申請または明細に違反フラグが初めて設定された時点を追跡します。

記録

ポリシー例外のレコードが作成された時刻、または違反フラグが「true」に設定された時刻を使用します。

イベントタイプ explicit
マネージャーによる却下
一次承認者であるマネージャーが経費レポートを確認し、最終却下します。通常、この操作によって当該レポートのプロセスは終了し、新しいレポートの作成が必要になります。
重要な理由

一次承認段階でのプロセス上の問題を特定します。却下率が高い場合、ポリシーの理解や申請内容の品質に問題がある可能性があります。

入手先

承認履歴ログ、またはマネージャーによる「却下」への最終的なステータス変更から確認できます。

記録

監査証跡から、一次承認者による最終的な「却下」アクションのタイムスタンプを取得します。

イベントタイプ explicit
レポートの修正依頼
承認者(通常はマネージャーまたは財務担当者)が、最終却下ではなく、修正のためにレポートを従業員へ差し戻します。この操作によって手戻りが発生し、レポートは下書きの状態に戻ります。
重要な理由

このアクティビティは、プロセスで手戻りが発生したことを示す主な指標です。発生頻度と原因を分析すると、プロセスの非効率な点や改善すべき箇所がわかります。

入手先

承認履歴ログから取得するか、ステータスが「承認待ち」から「下書き」または「オープン」に戻ったことを検出します。

記録

申請者への差し戻しを示す「差し戻し」イベント、またはステータスの遷移を確認します。

イベントタイプ explicit
レポートの取り下げ
経費レポートを申請した従業員が、最終承認の前に申請を取り消します。この操作によって、レポートは進行中の承認ワークフローから除外されます。
重要な理由

エンドユーザーが開始したプロセスの取り消しを示します。レポートが取り下げられる理由を把握すると、ユーザー体験やプロセスのわかりやすさに関するインサイトが得られます。

入手先

通常、レポートの監査証跡に明示的なイベントとして記録されるか、ステータスが「取り下げ」または「キャンセル」に変わったことで確認できます。

記録

申請者本人がレポートを取り消す操作を行ったイベントを特定します。

イベントタイプ explicit
払い戻しの予定設定
最終承認後、経費レポートは次回の払い戻しバッチで支払うためのキューに入ります。このイベントは、承認段階から支払いシステムへの引き継ぎを示します。
重要な理由

支払いプロセスへの引き継ぎの効率を測定します。ここで遅延が発生している場合、バッチ処理の非効率性や支払いシステムとの連携に問題がある可能性があります。

入手先

最終承認の記録後、ステータスが「支払い待ち」または「支払い承認済み」に変わったことから判断します。

記録

レポートが支払いバッチに割り当てられた時点、または支払い可能になったことを示すステータスに変わった時点のタイムスタンプを使用します。

イベントタイプ inferred
経費レポートのクローズ
すべての処理が完了すると、レポートはシステム上で正式にクローズされます。これが最終的な終了ステータスの更新であり、以降の変更が見込まれないことを示します。
重要な理由

プロセスの明確な終了点となるため、技術的にはオープンのままでも動きのないレポートが分析に含まれるのを防げます。

入手先

最後に記録されたステータスが「クローズ」や「アーカイブ済み」などの終了状態で、その後にアクティビティがないことから判断します。

記録

ステータスが「クローズ」などの終了状態に変わった最後のタイムスタンプを特定します。

イベントタイプ inferred
財務部門での確認開始
経費レポートが最終確認と監査のために財務・経理部門のキューに入った時点を示します。通常は、マネージャーの承認後に発生するステータス変更から判断します。
重要な理由

財務チームが作業を開始するまでのキュー時間、つまり待ち時間の測定に役立ちます。キュー時間が長い場合、プロセスに潜む大きなボトルネックとなっている可能性があります。

入手先

レポートのステータスが「財務確認待ち」などに変わったことを示すステータス変更ログから判断します。

記録

レポートが財務または監査のキューに割り当てられた時点のステータス変更のタイムスタンプを使用します。

イベントタイプ inferred
財務部門による却下
財務部門が経費レポートを却下します。通常、ポリシー、コンプライアンス、文書化に関する重大な問題が理由です。多くの場合、最終却下となり、プロセスは終了します。
重要な理由

重大なコンプライアンス違反やプロセスの破綻を特定します。マネージャーによる却下とは異なり、財務部門による却下は、より深刻な問題を示すことがよくあります。

入手先

承認履歴ログ、または財務担当者による「却下」への最終的なステータス変更から確認できます。

記録

監査証跡から、財務または監査の承認者による最終的な「却下」アクションのタイムスタンプを取得します。

イベントタイプ explicit
領収書の添付
ユーザーが領収書やその他の証憑書類をアップロードし、経費明細に紐付ける操作を示します。通常、添付ファイルごとに個別のイベントとして記録されます。
重要な理由

ユーザーの操作や文書の提出遅延を追跡します。申請を提出できる状態にするまでの、よくあるボトルネックを把握できます。

入手先

通常、システムの監査ログ、または文書と経費申請を紐付ける専用の添付ファイルテーブルで確認できます。

記録

文書関連または添付ファイル関連のテーブルに新しいレコードが作成された時刻を記録します。

イベントタイプ explicit
推奨 任意

データ抽出ガイド

プロセスマイニングに必要なデータの取得方法。

データの抽出方法はシステムによって異なります。詳しい手順は、

ETLガイドをご覧ください

または 特定のプロセスとシステムを選択してください.

利用を始めませんか?

システム別の抽出ガイドを選んで、プロセスマイニングを始めましょう。または、この汎用テンプレートを使って、任意のデータソースから経費管理データを準備できます。インサイトの発見をお手伝いします。

今日から経費管理の改善を始めましょう

経費処理全体に潜む非効率な部分を見つけ、コンプライアンスを確保しましょう。

無料トライアルを開始しましょう。

クレジットカード不要 • 5分でセットアップ