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

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

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

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

こちらは経費精算管理向けの汎用プロセスマイニングデータテンプレートです。より具体的なガイダンスが必要な場合は、システム固有のテンプレートをご利用ください。

特定のシステムを選択
  • 重要なデータ属性の包括的なリストです。
  • 経費処理における主要なアクティビティとマイルストーンです。
  • あらゆるシステムにおける詳細なプロセス分析のための基盤です。
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

経費精算管理属性

この表では、経費管理プロセスを包括的に分析し、より深いインサイトを得るために`イベントログ`に含めることが不可欠な、推奨される`データ`フィールド(`属性`)を詳しく説明しています。
5 必須 8 推奨 4 任意
名前 説明
アクティビティ名
ActivityName
経費精算書のライフサイクル内で発生した、特定のビジネス`イベント`またはタスクの名前です。
説明

アクティビティ名とは、経費精算管理プロセスにおける単一のステップまたはステータス変更を表します。例えば、「経費報告書作成済み」、「マネージャー承認済み」、「規定違反フラグ付き」、「精算実行済み」などがあります。この一連のアクティビティが、各経費報告書のプロセスフローを形成します。

プロセスマイニング分析において、この属性は実際のプロセスモデルを発見するために不可欠です。アナリストはこれにより、プロセスマップを視覚化し、アクティビティに時間がかかりすぎるボトルネックを特定し、「修正のために差し戻し」のような手戻りループを発見し、非標準的なプロセスバリエーションを正確に特定することができます。アクティビティ名の明確さと粒度が、プロセスインサイトの品質に直接影響を与えます。

その重要性

この属性はプロセスのステップを定義し、プロセスマップの可視化やワークフローパターン、および逸脱の分析を可能にします。

取得元

イベントログ、ステータス変更テーブル、または経費報告書に関連するトランザクションレコードから導出されます。

経費報告書提出済みマネージャー承認財務却下済み精算実行済み
イベント日時
EventTime
特定の`アクティビティ`または`イベント`が発生した正確な日時を示す`タイムスタンプ`です。
説明

イベント時刻、すなわちタイムスタンプは、アクティビティが発生した瞬間を記録します。これにより、各経費精算書のイベントが時系列で整理され、プロセスのタイムラインを正確に再構築するために不可欠なデータとなります。

プロセスマイニングにおいて、タイムスタンプはすべての時間ベースの分析の基礎です。アクティビティ間のサイクルタイム、エンドツーエンドの総処理時間、待機時間といった主要なパフォーマンス指標を算出するために利用されます。タイムスタンプを分析することで、組織は承認プロセスの遅延を特定し、払い戻し実行の効率を測定し、サービスレベルアグリーメント(SLA)に対するパフォーマンスを監視することが可能になります。

その重要性

このタイムスタンプは、イベントを時系列順に並べ、サイクルタイムやボトルネックなどの、すべての期間ベースのメトリクスを計算するために不可欠です。

取得元

イベントログまたはトランザクションデータ内で見つかり、しばしば「作成日」、「タイムスタンプ」、または「イベント日付」とラベル付けされています。

2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z2023-11-02T11:05:42Z
経費報告書ID
ExpenseReportId
経費精算書の一意の識別子です。このIDは、関連するすべての`アクティビティ`をグループ化し、主要な`ケース`識別子として機能します。
説明

経費精算書IDは、従業員が提出する各経費精算書に割り当てられる一意のキーです。作成、提出から承認、却下の可能性、そして最終的な払い戻しまで、すべてのプロセスステップを結びつける中心的な役割を果たします。

プロセスマイニングにおいて、この属性ケースの再構築に不可欠です。各一意の経費精算書IDは、経費管理プロセスの一ケースインスタンスを表します。各IDの経過を分析することで、プロセスフローの可視化、個々のレポートのサイクルタイムの計算、異なるレポートの処理方法におけるバリエーションの特定が可能になります。

その重要性

これは、経費精算書のライフサイクルにおけるすべてのイベントをリンクする必須のケース識別子であり、エンドツーエンドのプロセスを追跡することを可能にします。

取得元

通常、経費精算書のヘッダーレベルデータ、または経費プロセスの主要なトランザクション``テーブルに格納されています。

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

ソースシステム属性は、プロセスデータの発生源を特定します。現代の企業では、経費管理は複数の統合システム、例えば従業員データ用のHRシステム、提出用の専用経費ツール、財務計上用のERPなどが関与する場合があります。このフィールドは、これらの異なるソースからのデータを区別するのに役立ちます。

この情報は、データ検証とプロセスの技術的ランドスケープを理解する上で貴重です。もしプロセス上の問題が特定のシステムからのデータに集中している場合、それは統合の問題やそのアプリケーション内の問題を示している可能性があります。また、データの文脈を提供し、アナリストが異なるプロセスステップにおける信頼できる情報源を理解できるようにします。

その重要性

データの出所を特定します。これはデータガバナンス、トラブルシューティング、および異なるプラットフォーム間のプロセスバリエーションの理解にとって重要です。

取得元

この情報は、データ抽出プロセスまたはメタデータの一部であることが多く、データ準備中に追加される場合があります。

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

最終データ更新タイムスタンプは、データがソースシステムから最後に抽出または同期された時刻を示します。これにより、あらゆる分析に含まれるデータの明確な区切り点が提供され、すべてのステークホルダーがデータの鮮度を認識できるようになります。

プロセスマイニングにおいては、この属性データの整合性とレポート作成に不可欠です。ユーザーがリアルタイムデータを見ているのか、それとも過去のスナップショットを見ているのかを理解するのに役立ちます。特に、リアルタイム性が重要な継続的な監視ダッシュボードにおいては非常に重要です。また、データの更新がスケジュール通りに行われていることを確認することで、データパイプラインのトラブルシューティングにも貢献します。

その重要性

データの鮮度に関する透明性を確保し、あらゆるプロセス分析やモニタリングダッシュボードの正確性と関連性にとって不可欠です。

取得元

通常、データロードプロセス中にデータ統合ツールまたはETL(Extract, Transform, Load)ツールによって生成・保存されます。

2024-05-20T02:00:00Z2024-05-19T02:00:00Z2024-05-18T02:00:00Z
ユーザー
User
記録されたアクティビティを実行したユーザー、従業員、またはシステムアカウントの氏名またはIDです。
説明

ユーザー属性は、特定のプロセスステップを実行する担当者、または自動エージェントを特定します。これには、レポートを提出する従業員、承認を行うマネージャー、あるいは払い戻しを処理する経理チームメンバーなどが含まれます。

ユーザー別にプロセスを分析することは、作業負荷の分散状況、個々のパフォーマンス、および遅延を引き起こしている可能性のある特定の担当者を把握するために不可欠です。例えば、特定のマネージャーが承認チェーンのボトルネックになっているかどうかを明らかにできます。また、リソース配分分析を支援し、プロセス全体における説明責任と監査可能性を確保する上でも役立ちます。

その重要性

各ステップの担当者を特定し、ワークロード分析、パフォーマンス比較、特定の個人やチームに起因するボトルネックの特定を可能にします。

取得元

イベントログまたはトランザクション履歴で利用可能で、多くの場合、ユーザーIDまたは従業員IDにリンクされています。

john.doejane.smith承認者_チームリーダーsystem.batch.user
却下理由
RejectionReason
マネージャーまたは経理担当者が経費精算書を却下したり、修正のために差し戻したりする際に提示される理由です。
説明

却下理由は、経費精算書が承認ステップを通過しなかった理由を説明するテキストフィールド、または事前定義されたコードです。「領収書なし」、「カテゴリー間違い」、「ポリシー外支出」などが一般的な理由として挙げられます。

この属性は、プロセス手戻りの根本原因分析にとって非常に貴重です。最も頻繁な却下理由を分析することで、企業はシステム的な問題を特定できます。例えば、「領収書なし」が主な理由である場合、会社は文書化要件に関するコミュニケーションを改善したり、領収書の添付プロセスをより簡単にしたりする必要があるかもしれません。これらのインサイトは、初回承認率の向上、手戻りの削減、そして全体のサイクルタイム短縮につながるターゲットを絞ったプロセス改善をもたらします。

その重要性

プロセスの手戻りの「なぜ」を説明し、却下率を低減し、初回承認率を向上させるための的を絞った改善を可能にします。

取得元

承認者が「却下」または「差し戻し」アクションを実行した際に、コメントフィールドまたは選択リストに記録されます。

領収書不足不正確な経費カテゴリー日当限度額超過重複経費
合計金額
TotalAmount
払い戻しのために提出された経費精算書の合計金額です。
説明

合計金額は、単一の経費精算書に含まれるすべての個別の経費明細の合計を表します。これは、承認および払い戻しの対象となる総額です。

この属性は、プロセスマイニングにおける財務分析に不可欠です。これにより、経費精算書を高額なものと低額なものなどの金額帯でセグメント化することが可能となり、これらはしばしば異なる承認経路をたどります。アナリストはこの属性を用いて、レポートあたりの平均コストを計算し、手戻りや却下の財務的影響を調査し、支出トレンドを特定できます。合計金額をサイクルタイムと関連付けることで、高額なレポートほど承認に時間がかかるかどうかを明らかにできます。

その重要性

財務影響分析を可能にし、支出パターンを特定し、報告書の値に基づいてプロセスをセグメント化するのに役立ちます。

取得元

経費報告書データのヘッダーレベルで利用可能で、多くの場合、すべての明細金額の合計として計算されます。

150.752500.0085.5012500.20
報告書ステータス
ReportStatus
経費精算書のライフサイクルにおける現在または最終のステータスです。「提出済み」、「承認済み」、「支払い済み」などがあります。
説明

報告書ステータスは、ある時点での経費報告書のプロセス内での位置、またはその最終結果のスナップショットを提供します。ステータスは通常、提出、承認、処理、支払いなど、報告書が異なる段階を進むにつれて変化します。

この属性は、特定のコホートを分析するためのケースフィルタリングに役立ちます。例えば、「却下済み」報告書のみに焦点を当てて却下理由を理解したり、「承認保留中」報告書に焦点を当てて現在のボトルネックを調査したりするのに使用できます。ダッシュボードでは、現在のワークロードと進行中のすべての経費報告書の状態に関する概要を提供します。また、プロセスマイニングのために生成されたアクティビティのシーケンスを検証するためにも使用できます。

その重要性

報告書のステータスの概要を提供します。これは、ケースのフィルタリングや現在のワークロードに関する運用ダッシュボードの作成に役立ちます。

取得元

経費報告書がワークフローを進むにつれて更新される、主要な経費報告書ヘッダーテーブルのフィールドです。

承認待ち承認済み支払い済み却下取り消し済み
従業員部門
EmployeeDepartment
経費精算書を提出した従業員の事業部門または部署です。
説明

この属性は、「営業」、「開発」、「マーケティング」など、経費精算書を提出した従業員が所属する組織単位を特定します。多くの場合、経費を担当するコストセンターに紐付けられています。

従業員部署は、比較分析のための主要なディメンションです。部署別にプロセスをフィルターして表示することで、行動における顕著な違いを浮き彫りにできます。例えば、ある部署が他の部署よりもポリシー違反率が著しく高かったり、承認サイクルタイムが長かったりする場合があります。これらのインサイトは、経営陣が特定のチームに対するターゲットを絞ったトレーニング、プロセス調整、またはポリシーの明確化の必要性を特定するのに役立ちます。

その重要性

事業部門間の強力な比較分析を可能にし、部門固有の行動、ボトルネック、またはコンプライアンス上の問題を特定するのに役立ちます。

取得元

通常、従業員のマスターデータレコードから取得され、これは経費精算書にリンクされています。

営業エンジニアリングマーケティング財務
提出者
Submitter
経費精算書を作成し提出した従業員の氏名またはIDです。
説明

提出者とは、経費を発生させ、経費精算書を作成することで払い戻しプロセスを開始した従業員を指します。この属性は、通常、単一の経費精算書ケースに関連するすべてのイベントにおいて一貫しています。

一般的な「ユーザー」属性が各ステップの実行者を特定するのに対し、「提出者」はレポート所有者の行動を分析するための、一貫したケースレベルの属性を提供します。これにより、頻繁にレポートが却下される従業員や、一貫してポリシーに違反する従業員を特定するなど、従業員体験に焦点を当てた分析が可能になります。この分析結果は、プロセス全体の効率とコンプライアンスを最初から改善するための、ターゲットを絞ったコミュニケーションやトレーニングイニシアチブに役立てることができます。

その重要性

経費報告書の所有者を特定し、従業員の行動に基づいた分析を可能にします。例えば、頻繁な規定違反者や手戻りの原因を特定できます。

取得元

経費報告書のヘッダーデータ内で見つかり、記録を作成した従業員にリンクされています。

Alice Johnsonロバート・ウィリアムズEMP10234s.chen
規定違反フラグ
PolicyViolationFlag
経費報告書が1つ以上の規定違反としてフラグ付けされた場合にtrueとなるブール値のインジケーターです。
説明

ポリシー違反フラグは、経費精算書が会社の支出ポリシーにコンプライアンス違反していると自動的または手動で識別されたかどうかを示す、単純な真偽値です。違反には、支出限度額の超過、未承認ベンダーの使用、適切な文書の不足などが含まれる場合があります。

このフラグは、コンプライアンス分析の主要な指標となります。組織はこれにより全体のポリシー違反率を計算し、どの部署、経費カテゴリー、または従業員が最も多くの違反をしているかを詳細に把握できます。ポリシー違反の頻度と性質を理解することは、ポリシーの改善、自動チェック機能の強化、そして不適合な支出やプロセス例外を減らすためのターゲットを絞ったトレーニングの提供に役立ちます。

その重要性

規定に準拠しない報告書にフラグを立てることでコンプライアンス監視を直接サポートし、規定違反の測定と削減に貢献します。

取得元

経費報告書ヘッダーまたは明細データ内のフラグまたはフィールドで、多くの場合、システムが持つルールエンジンによって設定されます。

truefalse
通貨
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)である総承認サイクルタイムを表します。

取得元

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

取得

承認履歴から最終的な「承認」アクションをフィルタリングします。これは通常、財務または監査担当者のユーザーによって実行されます。

イベントタイプ explicit
マネージャー却下済み
一次マネージャーが経費精算書を審査し、最終却下を発行した状態です。このアクションにより、通常このレポートのプロセスは停止し、新しいレポートの作成が必要となります。
その重要性

一次承認段階でのプロセス失敗を特定します。高い却下率は、規定の理解度や申請品質に問題があることを示唆する可能性があります。

取得元

承認履歴ログまたはマネージャーによる「却下」への最終ステータス変更として見つかります。

取得

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

イベントタイプ explicit
報告書修正のために差し戻し
承認者(通常は管理者または財務担当者)が最終的な却下ではなく、修正のために報告書を従業員に差し戻します。このアクションにより手戻りループが開始され、報告書は下書き状態に戻されます。
その重要性

このアクティビティは、プロセスにおける手戻りループの主要な指標です。その発生頻度と原因を分析することで、プロセスの非効率性や改善すべき領域が明らかになります。

取得元

承認履歴ログから、または「承認保留中」から「下書き」または「オープン」へのステータス変更を検出することで取得されます。

取得

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

イベントタイプ explicit
報告書取り下げ済み
経費精算書を提出した従業員が、完全に承認される前にその申請を取り消すことです。このアクションにより、当該レポートはアクティブな承認`ワークフロー`から削除されます。
その重要性

エンドユーザーによって開始されたプロセスの中止を表します。報告書が取り下げられる理由を理解することは、ユーザーエクスペリエンスとプロセスの明確さに関する洞察を提供できます。

取得元

これは通常、レポートの監査トレイルに記録される明示的なイベント、またはステータスが「取り消し済み」や「キャンセル済み」に変更された際に取得されます。

取得

元の申請者が報告書をキャンセルするアクションを実行するイベントを特定します。

イベントタイプ explicit
精算スケジュール済み
最終承認後、経費報告書は次回の精算バッチでの支払いキューに追加されます。このイベントは、承認段階から支払いシステムへの引き渡しを表します。
その重要性

支払いプロセスへの引き渡しの効率性を測定します。ここでの遅延は、バッチ処理の非効率性や支払いシステム統合の問題を示します。

取得元

最終承認が記録された後、「支払い保留中」または「支払い承認済み」へのステータス変更から推測されます。

取得

レポートが支払いバッチに割り当てられたタイムスタンプ、またはそのステータスが支払い準備完了を示すように変更されたタイムスタンプを使用します。

イベントタイプ inferred
経費報告書クローズ済み
すべての処理が完了した後、経費精算書がシステム上で正式に「クローズ済み」としてマークされる状態です。これは最終的なステータス更新であり、それ以上の変更がないことを意味します。
その重要性

プロセスの決定的な終点を提供し、技術的にはオープンだが非アクティブな報告書が分析に含まれないようにします。

取得元

最後に記録されたステータスが「クローズ済み」や「アーカイブ済み」のような最終状態であり、その後のアクティビティがないことから推測されます。

取得

「クローズ済み」のような最終状態への最終ステータス変更のタイムスタンプを特定します。

イベントタイプ inferred
規定違反がフラグ付けされました
自動システムチェックまたは手動レビューにより、会社規定に違反する可能性のある経費が特定されます。このイベントは、報告書に特定の規定違反フラグまたは警告が設定されたときに記録されます。
その重要性

コンプライアンス問題を強調し、手戻りや却下の主要な原因となります。これらのフラグを分析することで、分かりにくい規定や従業員研修が必要な領域を特定できます。

取得元

システムログ、例外テーブル、または報告書またはその明細項目に違反フラグが最初に適用された時期を追跡することで見つかります。

取得

ポリシー例外レコードが作成されたタイムスタンプ、または違反フラグtrueに設定されたタイムスタンプを使用します。

イベントタイプ explicit
財務レビュー開始
経費報告書が最終レビューと監査のために財務または会計部門のキューに入る時点を示します。これは通常、マネージャー承認後のステータス変更から推測されます。
その重要性

財務チームが作業を開始するまでのキュー時間または待機期間を測定するのに役立ちます。長いキュー時間は、プロセスの重大な隠れたボトルネックとなる可能性があります。

取得元

報告書のステータスが「財務レビュー保留中」または同様の状態に移行するステータス変更ログから推測されます。

取得

レポートを経理または監査キューに割り当てるステータス変更のタイムスタンプを使用します。

イベントタイプ inferred
財務却下済み
経理部門が経費精算書を却下した状態です。通常、重大なポリシー違反、`コンプライアンス`違反、または不備な`データ`が理由となります。これは通常、プロセスを停止させる最終的な却下を意味します。
その重要性

重要なコンプライアンス違反やプロセス中断を正確に特定します。マネージャーによる却下とは異なり、財務による却下はより重大な問題を示すことがよくあります。

取得元

承認履歴ログまたは財務ユーザーによる「却下」への最終ステータス変更として見つかります。

取得

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

イベントタイプ explicit
領収書添付済み
領収書またはその他の裏付け文書を経費明細項目にアップロードし、リンクするユーザーアクションを表します。これは通常、各添付ファイルについて個別のイベントとして記録されます。
その重要性

ユーザーの行動や文書提出における潜在的な遅延を追跡します。これは、レポートが提出準備完了となる前によく発生するボトルネックとなる可能性があります。

取得元

通常、システム監査ログ、またはドキュメントを経費精算書にリンクする専用の添付テーブルで確認されます。

取得

文書または添付ファイル関連テーブルの各新規レコードのタイムスタンプをキャプチャします。

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

抽出ガイド

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

抽出方法はシステムによって異なります。詳細な手順については、

ETLガイドを読む

または 特定のプロセスとシステムを選択.