経費管理データテンプレート
経費管理データテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- Rampからの抽出手順
経費管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
経費管理プロセス内のある時点で発生した、特定のイベントまたはタスクの名前です。 | ||
|
説明
この属性は、「経費提出」「マネージャー承認済み」「経費精算実行」など、経費報告書のライフサイクルにおける1つのステップを示します。これらのアクティビティがプロセスマップのノードとなり、プロセスフローの可視化と分析を可能にします。 アクティビティを分析すると、頻度の高いステップ、ボトルネックが発生する箇所、ワークフローごとの違いを特定できます。業務の順序を理解し、各段階のパフォーマンスを測定するための中核的な要素です。
重要な理由
プロセスマップ上のステップを定義し、開始から終了までのプロセスフローを可視化・分析できるようにします。
入手先
通常、Rampの各経費報告書に関連付けられたイベントログまたはステータス変更レコードから取得します。
例
経費提出マネージャー承認済み経理確認待ち経費精算実行
|
|||
|
イベントタイムスタンプ
EventTimestamp
|
アクティビティが発生した正確な日時です。 | ||
|
説明
プロセス内の各アクティビティには、発生日時を記録するタイムスタンプが対応します。この時系列データによってイベントを時系列に並べられ、時間に関するすべての分析の基礎になります。 プロセスマイニングでは、タイムスタンプを使ってアクティビティ間の処理時間やケース全体の所要時間を計算し、遅延を特定します。パフォーマンスの監視とプロセス改善の機会を見つけるうえで重要な情報です。
重要な理由
イベントの時系列を示す属性であり、所要時間の計算とパフォーマンス分析に欠かせません。
入手先
通常、Rampのイベントログまたは取引データで、アクティビティやステータスのレコードとともに確認できます。
例
2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
|
|||
|
経費精算書ID
ExpenseReportId
|
各経費報告書を一意に識別するIDであり、プロセスにおける主なケース識別子です。 | ||
|
説明
Expense Report IDは、1件の経費提出に関連するすべてのイベントとアクティビティをまとめます。経費申請の最初の入力から最終的な支払いまでを、時系列で追跡できます。 プロセスマイニングでは、この属性が各経費報告書のエンドツーエンドの流れを再構成するために欠かせません。ケースIDとして使用することで、処理時間を正確に計算し、ボトルネックを特定し、承認プロセスで報告書がたどるさまざまな経路を可視化できます。
重要な理由
関連するすべてのアクティビティを1つのプロセスインスタンスに結び付ける基本属性であり、エンドツーエンドの分析を可能にします。
入手先
通常、Rampの主要な経費報告書テーブルまたは取引テーブルで確認できます。
例
ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
|
|||
|
ポリシー違反フラグ
PolicyViolationFlag
|
経費レポートがポリシー違反としてフラグ付けされたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、システムの自動チェックによって、支出上限の超過や重複経費の申請など、会社の経費ポリシーに違反する可能性が検出された場合にtrueになります。 このフラグは、「ポリシー違反検出」ダッシュボードと関連KPIに欠かせません。ポリシー管理の有効性を測定し、コンプライアンス違反が起きやすい領域を特定できます。その結果を、ポリシーの更新や従業員トレーニングに役立てられます。
重要な理由
ポリシーの遵守状況を直接測定し、コンプライアンスに反する支出と関連リスクの特定・削減に役立ちます。
入手先
通常、Ramp内でシステムが生成するフラグです。申請または承認プロセス中に、自動ポリシーチェックによって設定されます。
例
truefalse
|
|||
|
ユーザー名
UserName
|
アクティビティを実行したユーザーの名前またはIDです。経費を提出した従業員や承認者などが該当します。 | ||
|
説明
この属性は、経費報告書の提出、承認、確認など、プロセス内の特定のイベントを担当した個人を識別します。従業員の名前または一意のユーザーIDを指定できます。 ユーザー別に分析すると、業務負荷の分布を把握し、成果の高い担当者を特定し、追加研修が必要な担当者を見つけられます。承認パフォーマンスやリソース管理に関するダッシュボードにも欠かせません。
重要な理由
プロセスアクティビティを特定の個人に紐付け、担当者単位でのパフォーマンス分析と研修ニーズの特定を可能にします。
入手先
通常、Rampの各経費報告書の監査証跡または取引履歴に記録されます。
例
Alice JohnsonBob SmithCharlie Brownシステム自動化
|
|||
|
修正理由
RevisionReason
|
経費レポートが修正のため従業員に差し戻された際に入力された理由です。 | ||
|
説明
承認者が経費レポートを却下または差し戻す際には、通常、理由を入力します。この属性には、「領収書不足」、「カテゴリ間違い」、「ポリシー対象外」などの理由が記録されます。 この情報は、「経費修正率と原因」ダッシュボードにとって非常に有用です。手戻りの主な理由を分析することで、申請プロセスにある構造的な問題を特定し、エラーを減らすための対象を絞ったトレーニングやシステム改善を実施できます。
重要な理由
手戻りの根本原因を直接把握できるため、初回申請の品質を高めるための対策を具体化できます。
入手先
Rampで「経費レポートを修正のため差し戻し」アクティビティが発生した際、コメントまたは却下詳細として記録されます。
例
明細付き領収書不足経費がポリシー上限を超過経費カテゴリの選択が不正確取引の重複
|
|||
|
報告書合計金額
ReportTotalAmount
|
経費報告書の合計金額です。 | ||
|
説明
この属性は、1つのレポートに含まれるすべての経費の合計額を表します。支出パターンを把握するための主要な財務指標です。 プロセス分析では、レポート金額を使ってケースを分類し、高額なレポートが異なる承認経路をたどるか、処理に時間がかかるかを調査できます。支出分析ダッシュボードや、コスト削減の機会を見つけるための分析に欠かせません。
重要な理由
分析における重要な財務軸となり、金額別にレポートを分類し、支出全体を追跡できます。
入手先
Rampの経費レポートオブジェクトにおける主要フィールドです。
例
150.752500.0089.99
|
|||
|
従業員の所属部門
EmployeeDepartment
|
経費報告書を提出した従業員の所属部門です。 | ||
|
説明
この属性は、経費を提出した従業員が所属する事業部門または部署を示します。たとえば、「営業」「エンジニアリング」「マーケティング」などです。 さまざまな組織領域のプロセスパフォーマンスを絞り込み、比較できるため、分析における重要な切り口になります。部門間の承認時間、差し戻し率、ポリシー遵守状況の違いを明らかにし、対象を絞った改善施策を支援できます。
重要な理由
異なる事業部門間でプロセス指標を比較し、効率、コンプライアンス、支出の違いを明らかにします。
入手先
通常、Rampの従業員ユーザープロファイル、または連携済みの人事システムに関連付けられています。
例
営業マーケティングエンジニアリング財務
|
|||
|
経費カテゴリ
ExpenseCategory
|
経費に割り当てられたカテゴリです。例として「出張」、「ソフトウェア」、「食事」などがあります。 | ||
|
説明
この属性は、経費をあらかじめ定義したカテゴリに分類し、会社の支出を追跡・管理しやすくします。1つの経費レポートに複数のカテゴリの明細が含まれる場合があります。 経費カテゴリ別の分析は、「支出カテゴリ分析」ダッシュボードに欠かせません。財務チームは、どの分野に支出しているかを把握し、予算の遵守状況を確認し、時間の経過に伴う支出の傾向や異常を見つけられます。
重要な理由
詳細な支出分析が可能になり、主なコスト要因や予算を最適化する機会を特定できます。
入手先
通常、Rampの経費レポートにおける明細レベルの情報です。分析によっては、レポート単位に集計する必要があります。
例
航空運賃飲食・接待ソフトウェアサブスクリプション事務用品
|
|||
|
イベント終了時刻
EventEndTime
|
所要時間のあるアクティビティが終了した時刻を示すタイムスタンプです。 | ||
|
説明
多くのアクティビティは瞬時に完了しますが、「ポリシーチェック実行」のように、測定可能な所要時間を持つものもあります。この属性は、そのようなアクティビティの終了時刻を記録し、StartTimeを補完します。 開始時刻と終了時刻の両方があれば、アクティビティの処理時間を正確に計算できます。「平均ポリシーチェック時間」などのKPIや、プロセス全体の中で自動タスクまたは手動タスクにかかった時間を正確に特定するために必要です。
重要な理由
個々のアクティビティの所要時間を正確に計算できるため、非効率なプロセスステップの特定に役立ちます。
入手先
所要時間のあるアクティビティでは、Rampのイベントデータに記録されます。瞬時に完了するイベントでは、StartTimeと同じ値にできます。
例
2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となったアプリケーションを識別します。 | ||
|
説明
プロセスデータの記録元システムを示す属性です。この場合はRampです。複数のシステムからデータを統合する環境で、データの出所を明確にするのに役立ちます。 分析では、特定のソースからのデータを絞り込んだり、データの検証やガバナンスに利用したりできます。
重要な理由
データの出所に関する情報を提供します。データガバナンスや、複数のシステムからデータを統合する際に重要です。
入手先
通常、データの抽出・変換処理中に追加される固定値(「Ramp」)です。
例
Ramp
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからデータが最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
直近のデータ抽出日時を記録する属性です。分析対象データの鮮度を把握できます。 どの分析でも、データがいつ更新されたかを知ることは、結果を正しく解釈するうえで重要です。この属性によって、最新の情報を確認しているかどうかを判断できます。
重要な理由
データの適時性を示し、最新かつ関連性のある情報に基づいて分析できるようにします。
入手先
通常、データの抽出処理中に生成・追加されるタイムスタンプです。
例
2023-11-01T06:00:00Z
|
|||
|
手戻りあり
IsRework
|
経費レポートが少なくとも1回、修正のため差し戻されたかどうかを示す計算済みフラグです。 | ||
|
説明
このブール型属性は、対象ケースで「経費レポートを修正のため差し戻し」アクティビティが発生したかどうかを確認して算出します。少なくとも1回の修正サイクルを経たレポートではtrueになります。 このフラグを使うと、「経費レポート修正率」KPIを簡単に計算でき、初回で承認されたレポートと手戻りが発生したレポートを容易にフィルタリング・比較できます。この2つのグループを分析すると、修正による時間とコストへの影響を把握できます。
重要な理由
手戻り分析の対象を簡単に分類し、修正のために差し戻されたレポートの頻度と影響を定量化できます。
入手先
データ変換時に、ケース内に修正アクティビティが存在するかを確認して算出するフィールドです。
例
truefalse
|
|||
|
払い戻し方法
ReimbursementMethod
|
払い戻しの支払いを実行する方法です。ACHや電信送金などがあります。 | ||
|
説明
この属性は、従業員への払い戻しに使われた支払いチャネルを示します。方法によって、処理時間や費用が異なる場合があります。 方法別に払い戻しの処理状況を分析すると、最も効率的な支払いチャネルを特定できます。「払い戻し方法のパフォーマンス」ダッシュボードでは、このデータを使って処理時間と信頼性を比較し、支払い方法の改善につなげられます。
重要な理由
異なる支払いチャネルの処理状況を比較し、速度と信頼性の向上に役立てられます。
入手先
Rampの支払いまたは払い戻しレコードで確認できる情報です。
例
ACH送金法人カード入金口座振込
|
|||
|
承認ステップ数
ApprovalStepCount
|
経費レポートが通過した正式な承認ステップの合計数です。 | ||
|
説明
この計算指標は、1つの経費レポートで発生した「マネージャー承認」や「財務承認」など、個別の承認アクティビティの数を数えます。承認ワークフローの複雑さを定量化できます。 「レポートあたりの平均承認ステップ数」KPIと「シンプルな経費承認経路」ダッシュボードで使用します。特にレポート金額やカテゴリとの関係を分析すると、金額の小さい単純な経費に対して、承認プロセスが過度に複雑になっていないかを確認できます。
重要な理由
ワークフローの複雑さを定量化し、特にリスクの低いレポートについて、簡素化できる箇所の特定に役立ちます。
入手先
イベントログ内の各ケースについて、承認に関連する特定のアクティビティの発生回数を数えて算出します。
例
123
|
|||
|
承認マネージャー
ApprovingManager
|
承認ステップを実行したマネージャーの名前です。 | ||
|
説明
この属性は、従業員の経費レポートを確認・承認したマネージャーを特定します。レポートを申請したユーザーとは異なります。 承認マネージャーの追跡は、「マネージャー承認サイクルタイム」ダッシュボードに欠かせません。承認業務の負荷と処理状況を分析し、承認が速いマネージャーとボトルネックになっているマネージャーを把握できます。業務量の調整や追加支援にも役立ちます。
重要な理由
承認者ごとの処理状況を分析し、承認ワークフローのボトルネックを特定して解消できます。
入手先
Rampの承認ワークフローデータの一部であり、マネージャーがレポートに対して操作した際に記録されます。
例
Jane DoeJohn MillerSusan Chen
|
|||
|
申請方法
SubmissionMethod
|
経費レポートを申請したチャネルです。モバイルアプリやWebポータルなどがあります。 | ||
|
説明
この属性は、従業員がどのように経費レポートを申請したかを示します。一般的な方法には、モバイルアプリ、デスクトップのWebブラウザー、メール転送があります。 申請方法を分析すると、ユーザー行動やテクノロジーの利用状況を把握できます。たとえば、特定のチャネルから申請されたレポートで修正率が高い場合、そのチャネルの画面に使いにくさがある可能性があります。
重要な理由
ユーザー行動を理解するための背景情報となり、特定の申請チャネルでエラー率や遅延が高くなっていないかを確認できます。
入手先
Rampのシステムログにある申請イベントのメタデータに記録される場合があります。
例
モバイルアプリWebポータルメール
|
|||
|
監査結果
AuditOutcome
|
経費レポートに対する内部監査または外部監査の結果です。 | ||
|
説明
正式な監査を受けた経費レポートについて、最終結果を記録します。例として「承認」、「一部否認」、「追加情報が必要」などがあります。 このデータは、「経費監査パフォーマンス」ダッシュボードの中心となります。監査プロセスの有効性を評価し、結果ごとの発生頻度を追跡し、監査指摘事項による財務上の影響を把握できます。
重要な理由
監査プロセスの有効性と結果を測定し、コンプライアンスや統制上の弱点を把握できます。
入手先
詳細な経費監査にRampの監査モジュールまたは連携システムを使用している場合、そこに記録されます。
例
合格注記付きで合格却下エスカレーション済み
|
|||
|
財務承認者
FinanceApprover
|
経費レポートを承認した財務チームのユーザーです。 | ||
|
説明
財務レビューのステップを含むワークフローでは、財務部門内で最終承認を行った個人またはチームを特定します。 この属性を使うと、「財務レビュー効率」ダッシュボードで、個人またはチーム単位の処理状況を分析できます。ボトルネックの特定、業務量の配分評価、財務レビュー段階の有効性測定に役立ちます。
重要な理由
財務レビュー段階の処理状況を詳細に分析し、プロセス上の重要な統制ポイントを改善できます。
入手先
Rampの経費レポートの承認履歴に、財務レビュー段階の記録として保存されます。
例
財務チームADavid Lee財務自動化ボット
|
|||
経費管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
マネージャー承認済み
|
マネージャーが経費を確認して承認し、経理確認や経費精算などの次のステップへ進められる状態にします。明示的なユーザー操作によって記録されます。 | ||
|
重要な理由
最初の承認段階が正常に完了したことを示す重要な節目です。承認ワークフローの分析やボトルネックの特定に欠かせません。
入手先
マネージャーが「Approve」をクリックした際に、経費の承認履歴にイベントとして記録されます。イベントログには承認者のIDとタイムスタンプが含まれている必要があります。
取得
マネージャー権限を持つユーザーが「Approve」を実行した時点でイベントが記録されます。
イベントタイプ
explicit
|
|||
|
会計システムと同期済み
|
NetSuite、QuickBooks、Xeroなどの連携済み会計システムに、経費取引データが正常に計上された状態です。プロセスにおける財務記録作成の完了を示します。 | ||
|
重要な理由
エンドツーエンドのプロセスにおける最後のアクティビティです。ここでの遅延は、財務報告の正確性や決算のスピードに影響する可能性があります。
入手先
連携ログ、またはRampの経費オブジェクトのステータス更新として記録されます。「同期済み」「計上済み」「エクスポート済み」などのステータスを確認してください。
取得
データの同期が正常に完了すると、会計連携サービスによってログエントリが作成されます。
イベントタイプ
explicit
|
|||
|
経費提出
|
従業員が経費に必要な情報がすべて揃っていることを確認し、承認プロセスに提出します。これは、経費を「下書き」または「要対応」の状態から「承認待ち」の状態へ移す、明示的なユーザー操作です。 | ||
|
重要な理由
承認と経費精算のサイクルが正式に始まる重要な節目です。承認と経費精算のSLAを測定する際の基準点になります。
入手先
経費オブジェクトのステータス履歴から取得されます。取引を確認のために提出するユーザー操作に対応します。
取得
ユーザーが「Submit」ボタンをクリックし、ステータスが変更された時点で記録されます。
イベントタイプ
explicit
|
|||
|
経費発生
|
経費が作成されたことを示します。通常は、法人カードの利用時に自動で記録されるか、従業員が立替経費を手動で登録した際に発生します。このイベントは、通常、取引データフィードまたはユーザーインターフェース上の操作から取得されます。 | ||
|
重要な理由
経費ライフサイクルの主な開始イベントです。このイベントからの経過時間を分析することで、提出の遅れやプロセス全体の処理速度を把握できます。
入手先
Rampのカード取引ログ、または手動で入力された経費オブジェクトの作成日時から生成されます。経費テーブルまたは取引テーブルで、最初のレコード作成イベントを確認してください。
取得
カード取引が処理された時点、またはユーザーが新しい経費を登録した時点で直接記録されます。
イベントタイプ
explicit
|
|||
|
経費精算実行
|
経費精算の支払いが正常に処理され、従業員に送金された状態です。通常、従業員側では最後のステップとなり、支払いサイクルの終了を示します。 | ||
|
重要な理由
経費精算プロセスの主な終了イベントです。提出からこの時点までの所要時間は、従業員満足度とプロセス効率を測る重要なKPIです。
入手先
支払い処理ログ、または支払いプロバイダーとの連携から取得します。Rampの経費ステータスは「精算済み」または「支払済み」に更新されます。
取得
支払いシステムが送金の成功を確認した時点でイベントが記録されます。
イベントタイプ
explicit
|
|||
|
ポリシーチェック実行
|
システムが設定済みの会社ポリシーに照らして経費を自動監査し、違反の可能性がある項目にフラグを付けます。通常、提出直後にシステムが生成するイベントです。 | ||
|
重要な理由
自動コンプライアンスチェックの効率と、プロセスへの影響を測定します。よくあるポリシー違反や、従業員研修が必要な領域の特定にも役立ちます。
入手先
経費取引に関連付けられた監査証跡またはログに記録される可能性があります。「policy_check」または「compliance_scan」に関連するシステムイベントを確認してください。
取得
自動ポリシーエンジンが取引を処理した後、システムログのエントリが作成されます。
イベントタイプ
explicit
|
|||
|
マネージャー確認待ち
|
経費が提出され、従業員の直属のマネージャーによる確認を待っている状態です。提出後に経費のステータスが「マネージャー承認待ち」または同様の値に変わった場合に、この状態を推定できます。 | ||
|
重要な理由
マネージャー承認段階の開始点を示します。この状態にかかった時間を分析することは、マネージャーの承認時間を測定・改善するうえで重要です。
入手先
経費オブジェクトのステータスが「承認待ち」などに変更され、マネージャーのキューに割り当てられたことから推定します。ステータス履歴の追跡が必要です。
取得
経費のステータスが「マネージャー承認待ち」になった時点のタイムスタンプから算出します。
イベントタイプ
inferred
|
|||
|
経理承認済み
|
経理チームが経費を確認して最終承認し、経費精算と会計システムとの同期に進められる状態にします。経理チームのメンバーによる明示的なユーザー操作として記録されます。 | ||
|
重要な理由
支払い前の最終承認ゲートを示します。このアクティビティを分析することで、承認プロセス全体の所要時間と経理チームの効率を把握できます。
入手先
経費の承認履歴にイベントとして記録されます。経理部門のユーザーに関連付けられた承認イベントを確認してください。
取得
経理権限を持つユーザーが「Approve」を実行した時点でイベントが記録されます。
イベントタイプ
explicit
|
|||
|
経理確認待ち
|
承認済みの経費がエスカレーションされ、経理または会計チームによる確認を待っている状態です。高額な経費やポリシーフラグが付いた経費で発生することが多く、ステータスの変更から推定します。 | ||
|
重要な理由
経理確認サイクルの開始点を示します。この段階にかかった時間を測定することで、経理チームの負荷と効率を評価し、自動化の機会を特定できます。
入手先
マネージャー承認後、経費オブジェクトのステータスが「経理承認待ち」に変更されたことから推定します。経費のステータス履歴へのアクセスが必要です。
取得
経費のステータスが「経理確認待ち」に更新された時点のタイムスタンプから算出します。
イベントタイプ
inferred
|
|||
|
経費の差し戻し
|
マネージャーまたは経理担当の承認者が経費を却下し、従業員に修正を求めて差し戻した状態です。ステータスが「要修正」または「却下」に変更されたことから取得します。 | ||
|
重要な理由
プロセス内の手戻りループを示すアクティビティであり、処理時間を直接増加させます。これらのイベントを追跡することで、提出時によくある誤りを特定し、初回承認率を高められます。
入手先
経費オブジェクトのステータスが「要修正」または同様の状態に変更されたことから推定します。イベントには、この操作を開始した承認者を関連付ける必要があります。
取得
経費のステータスが「要修正」または「却下」になった時点のタイムスタンプから算出します。
イベントタイプ
inferred
|
|||
|
経費精算予定
|
立替経費の場合、承認済み金額が支払い処理のキューに登録された状態です。すべての承認を通過し、支払い可能になったことを示します。 | ||
|
重要な理由
承認プロセスと支払い実行プロセスを分ける節目です。承認による遅延と支払い処理による遅延を切り分けるのに役立ちます。
入手先
最終承認後、経費のステータスが「経費精算待ち」または「支払い準備完了」に変更されたことから推定します。支払いが一括処理される場合は、明示的なイベントとして記録されることもあります。
取得
ステータスが「支払い準備完了」に変更されたこと、または支払いバッチテーブルにレコードが作成されたことから算出します。
イベントタイプ
inferred
|
|||
|
領収書添付
|
領収書が経費に関連付けられた時点を示します。OCRによる照合で自動的に関連付けられる場合と、ユーザーが手動で添付する場合があります。領収書ファイルが取引レコードに正常にリンクされた時点で記録されます。 | ||
|
重要な理由
このアクティビティを追跡すると、必要書類の不足による遅延を特定できます。コンプライアンスの確保と監査への備えに欠かせないステップです。
入手先
領収書がアップロードまたは照合された際に、経費履歴または取引履歴に記録されます。添付ファイルの作成イベント、または「receipt_attached」を示すフラグを確認してください。
取得
システムが領収書の画像またはファイルを経費レコードにリンクした時点でイベントが作成されます。
イベントタイプ
explicit
|
|||
抽出ガイド
始める準備はできていますか?
このテンプレートを使って経費管理プロセスを変革し、業務効率を高め、承認を迅速化してください。今すぐ業務の最適化を始めましょう。
効率化を実現:今すぐRampの経費管理を最適化
非効率な箇所を特定し、承認を効率化して、処理時間を30%短縮します。
クレジットカードは不要で、数分で設定できます。