経費管理データテンプレート
経費管理データテンプレート
これは経費管理向けの汎用プロセスマイニング用データテンプレートです。より具体的なガイダンスについては、システム別テンプレートをご利用ください。
特定のシステムを選択- 必要なデータ属性を網羅した一覧です。
- 経費処理における主要なアクティビティとマイルストーンです。
- 任意のシステムで詳細なプロセス分析を行うための基盤です。
経費管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 経費レポートのライフサイクル内で発生した特定の業務イベントまたはタスクの名称です。 | ||
| 説明 アクティビティ名は、経費管理プロセスにおける個々のステップまたはステータス変更を表します。例として、「経費レポート作成」、「マネージャー承認」、「ポリシー違反フラグ設定」、「精算実行」などがあります。これらのアクティビティの連続が、各経費レポートのプロセスフローを形成します。 プロセスマイニング分析では、この属性が実際のプロセスモデルを発見するうえで重要です。プロセスマップを可視化し、アクティビティに時間がかかるボトルネックを特定できます。また、「レポート修正依頼」のような手戻りループを発見し、標準外のプロセスの違いを明らかにできます。アクティビティ名の明確さと粒度は、プロセス分析結果の品質に直接影響します。 重要な理由 この属性によってプロセスのステップが定義され、プロセスマップの可視化やワークフローのパターンと逸脱の分析が可能になります。 入手先 イベントログ、ステータス変更テーブル、または経費レポートに関連する取引記録から取得されます。 例 経費申請を提出マネージャーが承認財務部門が却下精算を実行 | |||
| イベント時刻 EventTime | 特定のアクティビティまたはイベントが発生した正確な日時を示すタイムスタンプです。 | ||
| 説明 イベント時刻、つまりタイムスタンプは、アクティビティが発生した時点を記録します。各経費レポートのイベントを時系列に並べるため、プロセスのタイムラインを正確に再構成するうえで欠かせません。 プロセスマイニングでは、タイムスタンプが時間に基づく分析の基盤になります。アクティビティ間のサイクルタイム、プロセス全体の処理時間、待ち時間などの主要業績評価指標の計算に使われます。タイムスタンプを分析することで、承認プロセスの遅延を特定し、精算処理の効率を測定するとともに、サービスレベル合意に対する実績を監視できます。 重要な理由 このタイムスタンプは、イベントを時系列に並べ、サイクルタイムやボトルネックなど、期間に基づく指標を計算するうえで重要です。 入手先 イベントログまたは取引データにあり、「作成日」、「タイムスタンプ」、「イベント日」などの名称で記録されることがよくあります。 例 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つ以上のポリシー違反があるとしてフラグ設定された場合にtrueとなるブール値です。 | ||
| 説明 ポリシー違反フラグは、経費レポートが会社の支出ポリシーに適合していないと自動または手動で判定されたかどうかを示す、trueまたはfalseの値です。支出上限の超過、承認されていない取引先の利用、必要書類の不足などが違反に該当します。 このフラグは、コンプライアンス分析の重要な基準です。組織全体のポリシー違反率を計算し、違反が多い部門、経費カテゴリ、従業員を詳しく調べられます。違反の頻度と内容を把握することで、ポリシーの見直し、自動チェックの改善、対象を絞った研修につなげ、ポリシーに適合しない支出と例外処理を減らせます。 重要な理由 ポリシーに適合しないレポートを示すことで、コンプライアンス監視を直接支援し、ポリシー違反の測定と削減に役立ちます。 入手先 経費レポートのヘッダーまたは明細データにあるフラグまたは項目です。通常は、システムのルールエンジンによって設定されます。 例 truefalse | |||
| ユーザー User | 記録されたアクティビティを実行したユーザー、従業員、またはシステムアカウントの名前またはIDです。 | ||
| 説明 ユーザー属性は、特定のプロセスステップを実行した担当者または自動処理エージェントを示します。レポートを提出する従業員、承認するマネージャー、精算を処理する財務チームの担当者などが該当します。 ユーザー別にプロセスを分析することで、作業負荷の分布や個人のパフォーマンスを把握し、遅延の原因となっている担当者を特定できます。たとえば、特定のマネージャーが承認チェーンのボトルネックになっているかどうかを確認できます。また、リソース配分の分析を支援し、プロセス全体の責任追跡と監査可能性を高めます。 重要な理由 各ステップの担当者を特定し、作業負荷の分析、パフォーマンスの比較、特定の個人やチームに起因するボトルネックの特定を可能にします。 入手先 イベントログまたは取引履歴にあり、ユーザーIDまたは従業員IDと関連付けられていることがよくあります。 例 john.doejane.smith承認者_チームリーダーsystem.batch.user | |||
| レポートステータス ReportStatus | 経費レポートのライフサイクルにおける現在または最終的なステータスです。「提出済み」、「承認済み」、「支払い済み」などがあります。 | ||
| 説明 レポートステータスは、任意の時点で経費レポートがプロセスのどこにあるか、または最終的にどうなったかを示します。通常、レポートが提出、承認、処理、支払いなどの段階を進むにつれて変化します。 この属性を使ってケースを絞り込み、特定の集団を分析できます。たとえば、「却下」レポートだけに絞って却下理由を調べたり、「承認待ち」レポートを対象に現在のボトルネックを調査したりできます。ダッシュボードでは、現在の作業量と処理中の経費レポートの状態を概観できます。また、プロセスマイニングで生成されたアクティビティの順序を検証するためにも使えます。 重要な理由 レポートの状態を概略的に把握できるため、ケースの絞り込みや現在の作業量を示す業務用ダッシュボードの作成に役立ちます。 入手先 主要な経費レポートヘッダーテーブルにある項目で、レポートがワークフローを進むにつれて更新されます。 例 承認待ち承認済み支払い済み却下取り下げ済み | |||
| 却下理由 RejectionReason | 経費レポートを却下した、または修正に戻したマネージャーや財務担当者が記載する理由です。 | ||
| 説明 却下理由は、経費レポートが承認ステップを通過しなかった理由を説明するテキスト項目または定義済みコードです。「領収書不足」、「カテゴリ誤り」、「ポリシー対象外の経費」などが一般的な理由です。 この属性は、プロセスの手戻りの根本原因分析に役立ちます。よくある却下理由を分析することで、組織的な問題を特定できます。たとえば、「領収書不足」が最も多い理由であれば、必要書類に関する周知を改善したり、領収書の添付を簡単にしたりする必要があるかもしれません。こうした分析結果を対象を絞ったプロセス改善につなげることで、初回承認率を高め、手戻りを減らし、全体のサイクルタイムを短縮できます。 重要な理由 プロセスの手戻りが発生する理由を明らかにし、却下率を下げ、初回承認率を高めるための改善を可能にします。 入手先 承認者が「却下」または「差し戻し」の操作を行う際に、コメント項目または選択リストへ記録されます。 例 領収書不足経費カテゴリが不正確日当上限超過経費の重複 | |||
| 合計金額 TotalAmount | 精算対象として提出された経費レポートの合計金額です。 | ||
| 説明 合計金額は、1つの経費レポートに含まれるすべての経費明細を合計した金額です。承認と精算の対象となる総額を表します。 この属性は、プロセスマイニングにおける財務分析に欠かせません。経費レポートを高額・低額などの金額帯に分けられ、金額帯ごとに異なる承認経路をたどるケースを分析できます。平均的なレポート処理コストの計算、手戻りや却下による財務影響の調査、支出傾向の把握にも役立ちます。合計金額とサイクルタイムを関連付けることで、高額なレポートほど承認に時間がかかるかどうかも確認できます。 重要な理由 財務影響の分析、支出パターンの把握、レポート金額に基づくプロセスの分類が可能になります。 入手先 経費レポートデータのヘッダーレベルにあり、通常はすべての明細金額を合計して算出されます。 例 150.752500.0085.5012500.20 | |||
| 従業員部門 EmployeeDepartment | 経費レポートを提出した従業員が所属する事業部門または部署です。 | ||
| 説明 この属性は、提出した従業員が所属する「営業」、「エンジニアリング」、「マーケティング」などの組織単位を示します。経費を負担するコストセンターと関連付けられていることもよくあります。 従業員部門は、比較分析における主要な切り口です。部門でプロセスを絞り込むことで、行動の大きな違いを明らかにできます。たとえば、ある部門では別の部門よりポリシー違反率が高い、または承認のサイクルタイムが長い場合があります。こうした分析結果は、特定のチームを対象とした研修、プロセスの見直し、ポリシーの明確化の必要性を判断するのに役立ちます。 重要な理由 事業部門間の比較分析を可能にし、部門固有の行動、ボトルネック、コンプライアンス上の問題を特定できます。 入手先 通常は、経費レポートに関連付けられた従業員マスターデータから取得されます。 例 営業エンジニアリングマーケティング財務 | |||
| 申請者 Submitter | 経費レポートを作成して提出した従業員の名前またはIDです。 | ||
| 説明 申請者は、経費を負担し、経費レポートを作成して精算プロセスを開始した従業員です。この属性は通常、1つの経費レポートケースに関連するすべてのイベントで共通します。 一般的な「ユーザー」属性が各ステップの担当者を示すのに対し、「申請者」はケースレベルで一貫した属性として、レポートの所有者の行動を分析するために使います。従業員体験に焦点を当て、レポートが頻繁に却下される従業員や、ポリシー違反を繰り返す従業員を特定できます。こうした分析は、プロセスの初期段階から効率とコンプライアンスを高めるための、対象を絞った周知や研修に役立ちます。 重要な理由 経費レポートの所有者を特定し、ポリシー違反を繰り返す従業員や手戻りの原因を特定するなど、従業員の行動に基づく分析を可能にします。 入手先 経費レポートのヘッダーデータにあり、レコードを作成した従業員と関連付けられています。 例 Alice JohnsonRobert WilliamsEMP10234s.chen | |||
| 通貨 Currency | 経費レポートの合計金額に使用される通貨コードです。USD、EUR、GBPなどがあります。 | ||
| 説明 通貨属性は、合計金額の通貨単位を示します。グローバルな組織では、従業員がさまざまな通貨で経費を申請するため、すべての金額を正しく解釈するうえで必要な情報です。 特に多国籍の環境で正確な財務分析を行うには、この属性が欠かせません。金額を正しく解釈し、集計レポート用に共通通貨へ換算できます。この情報がなければ、JPYのレポートとUSDのレポートの合計金額を比較しても意味がありません。地域ごとの支出総額、平均コスト、財務KPIを表示するダッシュボードの基盤となる項目です。 重要な理由 すべての金額に必要な背景情報を提供し、地域や国をまたぐ正確な財務レポート作成と比較を可能にします。 入手先 通常は、経費レポートのヘッダーデータで金額項目とともに保存されます。 例 USDEURGBPJPY | |||
| 承認者 Approver | 経費レポートの承認を担当するユーザーの名前またはIDです。通常はマネージャーまたは財務担当者です。 | ||
| 説明 承認者属性は、ワークフローで承認または却下のステップを実行した担当者を示します。多くのプロセスでは、直属のマネージャー、部門責任者、財務チームの担当者など、複数の承認レベルがあります。 「ユーザー」属性と同様に、「承認者」は遅延の主な原因になりやすい承認段階の分析に役立ちます。承認者ごとの承認時間を測定し、ボトルネックを特定できます。承認者ごとの作業量やパフォーマンスを示すダッシュボードを作成すれば、リソース管理や経費ポリシーに関する追加研修の必要性を判断できます。 重要な理由 承認を担当する個人を特定し、承認の遅延、作業量、判断の一貫性を分析できます。 入手先 承認に関連するアクティビティのイベントログまたは取引履歴に記録されます。 例 David ChenMGR1056Finance_Approval_Queuesusan.g | |||
| 支払い方法 PaymentMethod | 経費の支払い方法です。「法人カード」や「立替払い」などがあります。 | ||
| 説明 支払い方法は、従業員が元の経費をどのように支払ったかを示します。通常は、会社発行の法人カードを使った支払いか、個人資金による「立替払い」のいずれかです。立替払いの場合は、従業員への直接精算が必要になります。 この属性によって、主要な2つのプロセスパターンを区別できます。法人カードの取引は、カード発行会社から直接データが届くため、確認プロセスがより簡単になることがあります。一方、立替払いの経費は、より詳しい確認と従業員への直接支払いが必要です。支払い方法別にプロセスを分析すると、これら2つの経路におけるサイクルタイム、コンプライアンス率、処理コストの違いが明らかになり、効率向上に向けた法人カード利用の促進につながる可能性があります。 重要な理由 主要なプロセスパターン(法人カードと個人資金)を区別します。これらはリスク、効率、管理の水準が異なることがよくあります。 入手先 通常は経費明細レベルで指定され、取引に使われた資金の出所を示します。 例 法人カード立替払い日当会社負担 | |||
| 監査結果 AuditOutcome | 経費レポートに対して実施した手動または自動監査の結果です。 | ||
| 説明 監査結果は、プロセス内の監査ステップで確認された内容を記録します。コンプライアンスルールを確認する自動システム監査の場合もあれば、財務チームや監査チームによる手動レビューの場合もあります。結果には通常、「合格」、「不合格」、「例外付き合格」などがあります。 この属性は、内部統制の有効性を直接測定する指標です。監査結果を分析することで、リスクへのさらされ方や申請内容の品質を評価できます。また、統制が機能していない領域や、ポリシーが繰り返し誤解されている領域を特定できます。プロセスマイニングでは、監査結果を他の属性と関連付け、特定の経費カテゴリや部門で監査不合格率が高いかどうかを明らかにできます。 重要な理由 コンプライアンスと内部統制のチェック結果を直接測定し、リスクと監査ルールの有効性を評価するのに役立ちます。 入手先 自動ルールエンジン、またはレビューを完了した監査チームや財務チームの担当者が更新する項目です。 例 合格不合格:書類不足確認が必要例外付きで合格 | |||
| 経費カテゴリ ExpenseCategory | 「出張」、「会食」、「ソフトウェア」、「事務用品」など、経費の分類です。 | ||
| 説明 経費カテゴリは、経費レポートの支出の種類を分類するための切り口です。複数の明細が含まれる場合、1つの経費レポートに複数のカテゴリが含まれることがあります。 経費カテゴリ別にプロセスを分析すると、支出パターンを把握し、カテゴリごとのプロセス上の特徴を特定できます。たとえば、「海外出張」の経費は「事務用品」より承認プロセスが複雑で、時間もかかる場合があります。この属性によってコンプライアンスをより細かく分析し、特定のカテゴリでポリシー違反が多いかどうかを確認できます。財務計画と予算管理にも欠かせない項目です。 重要な理由 支出パターンを分析し、経費の種類によって異なるプロセス経路やコンプライアンス率になるかどうかを特定できます。 入手先 通常は経費レポートの明細レベルにあります。ケースレベルで分析する場合は、集計値または主要カテゴリを使うことがあります。 例 航空運賃飲食・接待ソフトウェアサブスクリプション事務用品ホテル | |||
経費管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| マネージャーが承認 | 従業員の直属のマネージャーまたは一次承認者が経費申請を確認し、承認したことを示します。申請をワークフローの次の段階へ進める重要な意思決定ポイントです。 | ||
| 重要な理由 一次承認段階の所要時間と効率を測定します。承認サイクル全体の時間を算出するための重要な節目です。 入手先 承認者の操作とタイムスタンプを記録する承認履歴または監査証跡テーブルに保存されます。 取得 承認履歴から、マネージャーの役割を持つユーザーによる最初の「承認」操作を抽出します。 イベントタイプ explicit | |||
| 会計に計上 | 経費データが会社の総勘定元帳またはERPシステムに正常に計上された最終段階を示します。これにより、経費申請の財務上の照合が完了します。 | ||
| 重要な理由 財務会計の観点で、プロセスが実質的に終了したことを示します。精算からこのイベントまでの時間により、決算業務の効率を把握できます。 入手先 ERP連携ログ、または会計システムとの同期が完了したことを示す経費申請の最終ステータスから取得します。 取得 総勘定元帳への計上が正常に完了したことを確認する連携ログのタイムスタンプを使用します。 イベントタイプ explicit | |||
| 精算を実行 | 従業員への支払いが正常に実行された時点を示します。従業員の視点では、プロセスが正常に完了したことを意味します。 | ||
| 重要な理由 プロセスの重要な終点を定義し、精算にかかった総時間を測定できるようにします。従業員満足度を測る重要な指標です。 入手先 通常、支払い処理ログ、または連携した支払いシステムから送信される「支払済み」や「精算済み」などの最終ステータス更新から取得します。 取得 経費申請に関連付けられた金融取引レコードから、支払い実行日を使用します。 イベントタイプ explicit | |||
| 経費申請を作成 | 従業員が新しい経費申請レコードを作成した時点で、プロセスが開始されたことを示します。最初に記録されるイベントであり、追跡に使用するケース識別子を設定します。 | ||
| 重要な理由 エンドツーエンドのプロセスの開始点を定義し、作成から最終精算までの総サイクルタイムを正確に測定できるようにします。 入手先 通常、経費申請のヘッダーデータにある作成タイムスタンプから取得します。 取得 経費申請の主要テーブルまたはオブジェクトにあるレコード作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 経費申請を提出 | 従業員が完成した経費申請を正式に提出し、承認ワークフローが開始される時点で発生します。申請のステータスが下書きから承認待ちに変わります。 | ||
| 重要な理由 データ入力の終了と承認サイクルの開始を示す重要な節目です。この時点までの遅延はユーザーに起因し、その後の遅延はプロセスに起因します。 入手先 ステータス変更ログ、または申請履歴に記録された明示的な提出イベントのタイムスタンプから取得します。 取得 申請のステータスが「下書き」または「オープン」から「提出済み」または「承認待ち」に変わるイベントを特定します。 イベントタイプ explicit | |||
| 財務部門が承認 | 財務または監査チームが経費申請の確認を完了し、最終承認を行ったことを示します。多くの場合、精算処理前の最後の承認ゲートです。 | ||
| 重要な理由 最終承認の節目です。提出からこのイベントまでの時間が総承認サイクルタイムとなり、重要なパフォーマンス指標になります。 入手先 承認者の詳細とともに、承認履歴または監査ログテーブルの明示的なイベントとして記録されます。 取得 承認履歴から、通常は財務または監査の役割を持つユーザーが行った最後の「承認」操作を抽出します。 イベントタイプ explicit | |||
| ポリシー違反を検出 | 自動システムチェックまたは手動レビューにより、経費が社内ポリシーに違反する可能性を特定します。申請に特定のポリシー違反フラグや警告が設定された時点で、このイベントを記録します。 | ||
| 重要な理由 コンプライアンス上の問題を明らかにし、やり直しや却下の主な要因を示します。これらのフラグを分析することで、分かりにくいポリシーや従業員研修が必要な領域を特定できます。 入手先 システムログ、例外テーブル、または申請や経費明細に初めて違反フラグが付いた時点を追跡して取得します。 取得 ポリシー例外レコードが作成された時点、または違反フラグがtrueに設定された時点のタイムスタンプを使用します。 イベントタイプ explicit | |||
| マネージャーが却下 | 一次承認者であるマネージャーが経費申請を確認し、最終的に却下したことを示します。通常、この操作で申請の処理は停止し、新しい申請の作成が必要になります。 | ||
| 重要な理由 一次承認段階でのプロセス上の失敗を特定します。却下率が高い場合、ポリシーの理解不足や申請品質の問題が考えられます。 入手先 承認履歴ログ、またはマネージャーによる「却下」への最終ステータス変更として記録されます。 取得 監査証跡から、一次承認者による最終的な「却下」操作のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 申請を修正のため差し戻し | 通常はマネージャーまたは財務担当のレビュアーである承認者が、最終却下ではなく、修正のために申請を従業員へ戻します。この操作によりやり直しのループが始まり、申請は下書きの状態に戻ります。 | ||
| 重要な理由 このアクティビティは、プロセス内のやり直しループを示す主な指標です。頻度と原因を分析することで、プロセスの非効率や改善領域を明らかにできます。 入手先 承認履歴ログ、または「承認待ち」から「下書き」や「オープン」へのステータス変更を検出して取得します。 取得 「差し戻し」イベント、または申請者への返却を示すステータス遷移を探します。 イベントタイプ explicit | |||
| 申請を取り下げ | 経費申請を提出した従業員が、完全に承認される前に申請を取り消します。この操作により、申請は有効な承認ワークフローから外れます。 | ||
| 重要な理由 エンドユーザーが開始したプロセスのキャンセルを示します。申請が取り下げられた理由を把握することで、ユーザー体験とプロセスの分かりやすさを改善できます。 入手先 通常、申請の監査証跡に明示的なイベントとして記録されるか、ステータスが「取り下げ」または「キャンセル」に変わったことから取得します。 取得 元の申請者が申請を取り消す操作を行ったイベントを特定します。 イベントタイプ explicit | |||
| 精算を予定 | 最終承認を受けた後、経費申請が次回の精算バッチで支払われるようキューに入ります。このイベントは、承認段階から支払いシステムへの引き継ぎを示します。 | ||
| 重要な理由 支払いプロセスへの引き継ぎの効率を測定します。ここでの遅延は、バッチ処理の非効率や支払いシステム連携の問題を示します。 入手先 最終承認の記録後に、ステータスが「支払い待ち」または「支払い承認済み」に変わったことから推定します。 取得 申請が支払いバッチに割り当てられた時点、または支払い準備完了を示すステータスに変わった時点のタイムスタンプを使用します。 イベントタイプ inferred | |||
| 経費申請をクローズ | すべての処理が完了した後、システム上で経費申請が正式にクローズされたことを示します。これが最後の終端ステータス更新となり、以後の変更が予定されていないことを意味します。 | ||
| 重要な理由 プロセスの明確な終点を設定し、技術的にはオープンのままでも実質的に動いていない申請が分析に含まれるのを防ぎます。 入手先 通常、「クローズ」や「アーカイブ済み」などの終端ステータスが最後に記録され、その後にアクティビティがないことから推定します。 取得 「クローズ」などの終端状態への最後のステータス変更のタイムスタンプを特定します。 イベントタイプ inferred | |||
| 財務レビューを開始 | 経費申請が最終確認と監査のために財務部門または経理部門のキューに入った時点を示します。通常、マネージャー承認後のステータス変更から推定します。 | ||
| 重要な理由 財務チームが作業を開始するまでのキュー時間や待ち時間を測定できます。キューでの待ち時間が長い場合、プロセスに隠れた大きなボトルネックがある可能性があります。 入手先 申請のステータスが「財務レビュー待ち」または同様の状態に変わったことを示すステータス変更ログから推定します。 取得 申請が財務または監査のキューに割り当てられた時点のステータス変更タイムスタンプを使用します。 イベントタイプ inferred | |||
| 財務部門が却下 | 財務部門が、重大なポリシー違反、コンプライアンス上の問題、または証憑不足などを理由に経費申請を却下したことを示します。通常は最終却下となり、処理が停止します。 | ||
| 重要な理由 重大なコンプライアンス違反やプロセス上の問題を特定します。マネージャーによる却下とは異なり、財務部門による却下は、より深刻な問題を示すことが多いです。 入手先 承認履歴ログ、または財務ユーザーによる「却下」への最終ステータス変更として記録されます。 取得 監査証跡から、財務または監査の承認者による最終的な「却下」操作のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 領収書を添付 | 領収書やその他の証憑をアップロードし、経費明細に紐付けるユーザー操作を示します。通常、添付する書類ごとに個別のイベントとして記録されます。 | ||
| 重要な理由 ユーザーの行動と証憑提出の遅延を追跡します。これは、申請を提出できる状態になるまでの一般的なボトルネックになることがあります。 入手先 通常、システムの監査ログ、または書類と経費申請を紐付ける専用の添付ファイルテーブルに記録されています。 取得 書類または添付ファイル関連のテーブルで、新しいレコードごとのタイムスタンプを取得します。 イベントタイプ explicit | |||
抽出ガイド
準備はできましたか?
システム別の抽出ガイドを選択して、プロセスマイニングを始めましょう。あるいは、この汎用テンプレートを使って、任意のソースから経費管理データを準備できます。データから価値ある発見を得られるよう、サポートします。
今日から経費管理を改善する
経費管理プロセスに潜む非効率を明らかにし、すべての経費処理でコンプライアンスを確保します。
クレジットカード不要・5分でセットアップ