経費管理データテンプレート
経費管理データテンプレート
- 収集を推奨する属性
- 記録すべき主なアクティビティ
- Rampからの抽出手順
経費管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
経費管理プロセスの中で、特定の時点に発生したイベントまたはタスクの名前です。 | ||
|
説明
この属性は、「経費申請」「上長承認」「払い戻し実行」など、経費報告書のライフサイクルにおける個々のステップを表します。これらのアクティビティがプロセスマップ上のノードとなり、プロセスフローの可視化と分析を可能にします。 アクティビティを分析すると、頻度の高いステップやボトルネックの発生箇所、ワークフローごとの違いを特定できます。業務の順序を把握し、各段階のパフォーマンスを測定するための基本要素です。
重要な理由
プロセスマップ上のステップを定義し、開始から終了までのプロセスフローを可視化して分析できるようにします。
入手先
通常、Rampの各経費報告書に関連するイベントログまたはステータス変更記録から取得します。
例
経費申請上長承認経理部門の確認待ち払い戻し実行
|
|||
|
イベントのタイムスタンプ
EventTimestamp
|
アクティビティが発生した正確な日時です。 | ||
|
説明
プロセス内の各アクティビティには、発生時刻を記録するタイムスタンプがあります。この時刻データを使ってイベントを時系列に並べ、時間に関する分析を行います。 プロセスマイニングでは、タイムスタンプを使ってアクティビティ間のサイクルタイムやケース全体の所要時間を算出し、遅延を特定します。パフォーマンスのモニタリングやプロセス改善の機会を見つけるうえで欠かせない情報です。
重要な理由
イベントの時系列を示す属性であり、所要時間の算出やパフォーマンス分析に欠かせません。
入手先
通常、Rampのイベントログまたは取引データにあるアクティビティ記録やステータス記録とともに保存されています。
例
2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
|
|||
|
経費報告書ID
ExpenseReportId
|
各経費報告書を一意に識別するIDで、プロセスの主なケース識別子として使われます。 | ||
|
説明
経費報告書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
|
経費レポートが少なくとも一度、修正のために差し戻されたことを示す計算済みフラグです。 | ||
|
説明
この真偽値属性は、対象ケースで「経費レポートを修正のため差し戻し」アクティビティが発生したかどうかを確認して算出します。少なくとも一度修正されたレポートにはtrueが設定されます。 このフラグを使うと、「経費レポート修正率」の重要業績評価指標(KPI)を簡単に算出できます。また、初回で承認されたレポートと手戻りが発生したレポートを簡単に絞り込み、比較できます。2つのグループを分析すると、修正による時間と費用への影響が明らかになります。
重要な理由
手戻り分析の対象を簡単に分類し、修正のために差し戻されたレポートの頻度と影響を定量化できます。
入手先
これは計算フィールドです。データ変換時に、ケース内に修正アクティビティがあるかどうかを確認して算出します。
例
truefalse
|
|||
|
払い戻し方法
ReimbursementMethod
|
ACHや電信送金など、払い戻しの支払いに使用する方法です。 | ||
|
説明
この属性は、従業員への払い戻しに使用された支払い方法を示します。方法によって処理時間や費用が異なる場合があります。 方法別に払い戻しの実績を分析すると、効率のよい支払い方法を特定できます。「払い戻し方法別の実績」ダッシュボードでは、このデータを使ってサイクルタイムと信頼性を比較し、支払い方法の見直しに役立てられます。
重要な理由
支払い方法ごとの実績を比較し、処理速度と信頼性の向上に役立てられます。
入手先
この情報は、Rampの支払い記録または払い戻し記録で確認できます。
例
ACH送金法人カードのクレジット口座振込
|
|||
|
承認した上長
ApprovingManager
|
承認ステップを実行した上長の名前です。 | ||
|
説明
この属性は、従業員の経費報告書を確認して承認する上長を示します。報告書を申請したユーザーとは別の情報です。 承認した上長の追跡は、「上長承認サイクルタイム」ダッシュボードに欠かせません。承認業務の量やパフォーマンスを分析し、迅速に承認する上長と、ボトルネックになっている上長を把握できます。業務量の調整や追加支援にも役立ちます。
重要な理由
承認者ごとのパフォーマンスを分析し、承認ワークフローのボトルネックを特定して対処できます。
入手先
この情報はRampの承認ワークフローのデータの一部で、マネージャーがレポートに対して操作した際に記録されます。
例
ジェーン・ドウジョン・ミラースーザン・チェン
|
|||
|
承認ステップ数
ApprovalStepCount
|
経費レポートが通過した正式な承認ステップの合計数です。 | ||
|
説明
この計算指標は、1件の経費レポートで発生した「マネージャー承認」「財務承認」など、異なる承認アクティビティの数を数えます。承認ワークフローの複雑さを把握できます。 この属性は、「レポートあたりの平均承認ステップ数」の重要業績評価指標(KPI)や「簡易な経費承認経路」ダッシュボードに使用します。レポートの金額やカテゴリとあわせて分析すると、少額で単純な経費に過度に複雑な承認プロセスが適用されていないかを特定できます。
重要な理由
ワークフローの複雑さを定量化し、特にリスクの低いレポートについて、手順を簡素化できる箇所を特定できます。
入手先
イベントログ内の各ケースについて、承認に関連する特定のアクティビティの発生回数を数えて算出します。
例
123
|
|||
|
提出方法
SubmissionMethod
|
モバイルアプリやウェブポータルなど、経費レポートの提出に使用した経路です。 | ||
|
説明
この属性は、従業員が経費レポートをどのように提出したかを示します。一般的な方法には、モバイルアプリ、デスクトップのウェブブラウザー、メール転送があります。 提出方法を分析すると、ユーザーの行動やテクノロジーの利用状況を把握できます。たとえば、特定の経路から提出されたレポートで修正が多い場合、その画面の使いやすさに問題がある可能性があります。
重要な理由
ユーザーの行動を把握し、特定の提出経路でエラーや遅延が多く発生していないかを確認できます。
入手先
この情報は、Rampのシステムログにある提出イベントのメタデータに記録されている場合があります。
例
モバイルアプリウェブポータルメール
|
|||
|
監査結果
AuditOutcome
|
経費レポートに対する内部監査または外部監査の結果です。 | ||
|
説明
正式な監査を受けた経費レポートについて、最終結果を記録します。結果には「承認済み」「一部否認」「追加情報が必要」などがあります。 このデータは「経費監査の実績」ダッシュボードの基礎となります。監査プロセスの有効性を評価し、結果ごとの発生頻度や監査指摘による財務上の影響を把握できます。
重要な理由
監査プロセスの有効性と結果を測定し、コンプライアンスや統制上の弱点を把握できます。
入手先
詳細な経費監査にRampの監査モジュールまたは連携システムを使用している場合は、そこで記録されます。
例
合格指摘事項付きで合格却下エスカレーション
|
|||
|
財務承認者
FinanceApprover
|
経費レポートを承認した財務チームのユーザーです。 | ||
|
説明
財務部門による確認を含むワークフローでは、最終承認を行った担当者またはチームを示します。 この属性を使うと、個人またはチーム単位で実績を分析でき、「財務確認の効率」ダッシュボードに役立ちます。ボトルネックの特定、業務量の配分状況の評価、財務確認段階の有効性の測定が可能です。
重要な理由
財務確認段階の実績を詳しく分析し、プロセスの重要な統制ポイントの改善に役立てられます。
入手先
Rampで財務確認を行う際、経費レポートの承認履歴に記録されます。
例
財務チームAデビッド・リー財務自動化ボット
|
|||
経費管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
上長承認
|
上長が経費を確認して承認し、経理部門の確認や払い戻しなど、次のステップに進める状態です。ユーザーが明示的に行う操作として記録されます。 | ||
|
重要な理由
最初の承認段階が完了したことを示す重要な節目です。承認ワークフローの分析やボトルネックの特定に役立ちます。
入手先
上長が「承認」をクリックしたとき、経費の承認履歴にイベントとして記録されます。イベントログには、承認者のIDとタイムスタンプが含まれます。
記録
上長権限を持つユーザーが「承認」操作を行うと、イベントが記録されます。
イベントタイプ
explicit
|
|||
|
会計システムと同期
|
経費取引データがNetSuite、QuickBooks、Xeroなどの連携済み会計システムに正常に計上された状態です。このイベントは、プロセスのうち財務記録の処理が完了したことを示します。 | ||
|
重要な理由
エンドツーエンドのプロセスにおける最後のアクティビティです。ここで遅延が発生すると、財務報告の正確性や決算のスピードに影響する可能性があります。
入手先
連携ログ、またはRampの経費オブジェクトのステータス更新として記録されます。「同期済み」「計上済み」「エクスポート済み」などのステータスを確認してください。
記録
データの同期が正常に完了すると、会計連携サービスによってログに記録されます。
イベントタイプ
explicit
|
|||
|
払い戻し実行
|
払い戻しが正常に処理され、従業員に送金された状態です。通常、従業員にとっての最終ステップであり、支払いサイクルの終了を示します。 | ||
|
重要な理由
払い戻しプロセスの主な終了イベントです。申請からこの時点までの所要時間は、従業員の満足度とプロセス効率を測る重要業績評価指標(KPI)です。
入手先
支払い処理ログ、または決済プロバイダーとの連携から取得します。Rampの経費ステータスは「払い戻し済み」または「支払い済み」に更新されます。
記録
支払いシステムが送金の成功を確認した時点でイベントが記録されます。
イベントタイプ
explicit
|
|||
|
経費申請
|
従業員が経費に必要な情報をすべて入力したことを確認し、承認プロセスに申請します。ユーザーが明示的に行う操作で、経費の状態が「下書き」または「要対応」から「承認待ち」に変わります。 | ||
|
重要な理由
承認と払い戻しのサイクルが正式に始まる重要な節目です。承認と払い戻しのSLAを測定する際のベースラインになります。
入手先
経費オブジェクトのステータス履歴から取得します。取引を確認に回すユーザー操作に該当します。
記録
ユーザーが「送信」ボタンをクリックし、ステータスが変わった時点で記録されます。
イベントタイプ
explicit
|
|||
|
経費発生
|
経費が発生した時点を示します。通常、法人カードの利用時に自動で記録されるか、従業員が立替経費の記録を手動で作成したときに発生します。このイベントは、取引データのフィードやユーザーインターフェース上の操作から記録されます。 | ||
|
重要な理由
経費ライフサイクルの主な開始イベントです。このイベントからの経過時間を分析すると、申請の遅れやプロセス全体の処理速度を把握できます。
入手先
Rampのカード取引ログ、または手動で入力した経費オブジェクトの作成日時から取得します。経費テーブルまたは取引テーブルで、最初のレコード作成イベントを確認してください。
記録
カード取引の処理時、またはユーザーが新しい経費項目を作成した時点で直接記録されます。
イベントタイプ
explicit
|
|||
|
ポリシーチェック実施
|
システムが設定済みの社内ポリシーに照らして経費を自動で監査し、違反の可能性がある項目にフラグを付けます。通常、申請後まもなく発生するシステム生成イベントです。 | ||
|
重要な理由
自動コンプライアンスチェックの効率と、プロセスへの影響を測定します。よくあるポリシー違反や、従業員向けのトレーニングが必要な領域の特定に役立ちます。
入手先
経費取引に関連する監査証跡またはログに記録されている可能性があります。「policy_check」や「compliance_scan」に関連するシステムイベントを確認してください。
記録
自動ポリシーエンジンが取引をチェックした後、システムログに記録されます。
イベントタイプ
explicit
|
|||
|
上長の確認待ち
|
経費の申請が完了し、従業員の直属の上長による確認を待っている状態です。申請後に経費のステータスが「上長承認待ち」などに変わった場合、この状態と判断できます。 | ||
|
重要な理由
上長による承認段階の開始を示します。この状態の継続時間を分析することで、上長の承認サイクルタイムを測定し、改善できます。
入手先
経費オブジェクトのステータスが「承認待ち」などに変わり、上長のキューに割り当てられたことから判断します。ステータス履歴の追跡が必要です。
記録
経費のステータスが「上長承認待ち」になった時点のタイムスタンプから取得します。
イベントタイプ
inferred
|
|||
|
払い戻し手配完了
|
立替経費の場合、承認された金額が支払い処理のキューに登録された状態です。すべての承認が完了し、支払いの準備が整ったことを示します。 | ||
|
重要な理由
この節目を境に、承認プロセスと支払い実行プロセスが分かれます。承認と支払い処理のどちらで遅延が発生しているかを切り分けるのに役立ちます。
入手先
最終承認後に経費のステータスが「払い戻し待ち」または「支払い準備完了」に変わったことから判断できます。支払いが一括処理される場合は、明示的なイベントとして記録されることもあります。
記録
ステータスが「支払い準備完了」に変わった時点、または支払いバッチテーブルにレコードが作成された時点から取得します。
イベントタイプ
inferred
|
|||
|
経理承認
|
経理チームが経費を確認し、最終承認を行った状態です。払い戻しと会計システムとの同期に進めます。経理チームのメンバーが明示的に行う操作として記録されます。 | ||
|
重要な理由
支払い前の最終承認段階を示します。このアクティビティを分析すると、承認サイクル全体と経理チームの効率を把握できます。
入手先
経費の承認履歴にイベントとして記録されます。経理部門のユーザーに紐付いた承認イベントを確認してください。
記録
経理権限を持つユーザーが「承認」操作を行うと、イベントが記録されます。
イベントタイプ
explicit
|
|||
|
経理部門の確認待ち
|
承認済みの経費が上位の確認段階に進み、経理または会計チームの確認を待っている状態です。通常、高額な経費やポリシー上のフラグが付いた経費で発生します。ステータスの変更から判断されます。 | ||
|
重要な理由
経理部門による確認サイクルの開始を示します。この段階の所要時間を測定すると、経理チームの業務量や効率を把握し、自動化の機会を特定できます。
入手先
上長の承認後、経費オブジェクトのステータスが「経理承認待ち」に変わったことから判断します。経費のステータス履歴へのアクセスが必要です。
記録
経費のステータスが「経理確認待ち」に更新された時点のタイムスタンプから取得します。
イベントタイプ
inferred
|
|||
|
経費を修正のため差し戻し
|
上長または経理担当者が経費を却下し、修正のため従業員に差し戻した状態です。ステータスが「要修正」または「却下」に変わったことで記録されます。 | ||
|
重要な理由
このアクティビティは、サイクルタイムを直接延ばす手戻りを示します。イベントを追跡すると、申請でよくある誤りを特定し、初回申請での承認率を高められます。
入手先
経費オブジェクトのステータスが「要修正」などに変わったことから判断します。イベントは、操作を行った承認者に紐付けます。
記録
経費のステータスが「要修正」または「却下」になった時点のタイムスタンプから取得します。
イベントタイプ
inferred
|
|||
|
領収書添付
|
領収書が経費に紐付けられた時点を示します。OCRによる照合で自動的に紐付けられる場合と、ユーザーが手動で添付する場合があります。領収書ファイルが取引レコードに正常に紐付けられたときに記録されます。 | ||
|
重要な理由
このアクティビティを追跡すると、文書の不足による遅延を特定できます。コンプライアンスの確保と監査への備えに欠かせないステップです。
入手先
領収書のアップロード時または照合時に、経費履歴または取引履歴に記録されます。添付ファイルの作成イベント、または「receipt_attached」を示すフラグを確認してください。
記録
システムが領収書の画像またはファイルを経費レコードに紐付けたときにイベントが作成されます。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使って経費管理プロセスを見直し、業務の効率化と承認の迅速化を目指しましょう。今すぐ業務の改善に取り組めます。
効率を高める:Rampの経費管理を今すぐ最適化
非効率な箇所を特定し、承認を効率化して、サイクルタイムを30%短縮します。
クレジットカードは不要です。数分で設定できます。