支払い処理のデータテンプレート

この属性は、特定の時点で行われた処理や、支払いの状態変化を表します。たとえば、依頼の作成、検証、承認、最終決済などがあります。

プロセスマイニングでは、この属性を使ってプロセスマップ上のノードを定義します。アクティビティの順序を分析すると、よく見られるバリアント、支払いの手戻りが発生するループ、処理が長時間滞留するボトルネックを特定できます。

プロセス全体を一貫して把握するには、異なるソースシステム間で名称を標準化する必要がある場合があります。たとえば、あるシステムでは「Auth」、別のシステムでは「Authorization」と呼ばれるステップを、データ変換時に同じ名称にそろえます。

プロセスマップ上のノードを定義し、プロセスの流れやバリアントを分析できます。

監査ログ、ステータス履歴テーブル、またはイベント追跡テーブルにあります。

この属性には、支払いシステムでイベントが発生した正確な日時が記録されます。プロセスの時系列を示す基準となり、ケース内のイベントを正しい順序に並べられます。

分析では、この日時をもとに時間に関する計算を行います。アクティビティ間の所要時間、エンドツーエンドのサイクルタイム、サービスレベル合意の達成状況を算出できます。ボトルネックの発生時点を特定するには、正確なタイムスタンプが欠かせません。

特に、高頻度取引や自動決済システムではミリ秒単位の差が重要になるため、精度の高い日時が望まれます。時刻を含まない日付しかない場合、同じ日に発生したアクティビティの順序を決めるため、別の並べ替えルールが必要になることがあります。

イベントの順序付けと、サイクルタイムなど所要時間に関する重要業績評価指標の算出に必要です。

取引ログ、履歴テーブル、またはシステム監査証跡にあります。

この属性は、レコードの技術的な発生元を示します。エンドツーエンドの支払いプロセスでは、フロントエンドのゲートウェイ、不正検知エンジン、バックエンドの台帳など、複数のシステムをデータが経由することがあります。

システム別にデータを分析すると、技術的な問題を切り分けられます。たとえば、台帳ではなく不正検知エンジンで一貫して遅延が見られる場合、原因を絞り込んで調査できます。また、複数のデータソースを統合する際のデータ整合性の確認にも役立ちます。

ソースデータに明示的な項目がない場合は、通常、抽出・変換の過程でこの項目を追加します。監査やデバッグの際に、データの来歴を確認するための目印になります。

複数システムにまたがる分析や、遅延・エラーの原因となっているコンポーネントの特定に欠かせません。

ETL処理で固定値として設定するか、システムのメタデータから取得します。

この属性は、分析に使うデータの鮮度を示します。データがプロセスマイニングツールに読み込まれた時点、またはソースデータベースでレコードが最後に変更された時点を表します。

データガバナンスと信頼性を保つうえで、この情報は欠かせません。分析担当者は、リアルタイムのデータを見ているのか、前日のスナップショットを見ているのかを確認できます。保留状態のまま滞留している支払いを監視する場合は、特に重要です。

プロセスの流れの計算に直接使う項目ではありませんが、ダッシュボードに支払い業務の最新状況が表示されているかを確認するためのメタデータ項目です。

データの鮮度を確認できるほか、データパイプラインの遅延に関する問題のデバッグにも役立ちます。

データの抽出またはETL処理時に生成されます。

この属性は、1件の支払いライフサイクルに含まれるすべてのアクティビティを関連付けるための中心的なキーです。プロセスマイニングツールは、このキーを使って、支払いの開始から最終的な決済または失敗までの流れを再構成できます。

分析では、このIDを使って個々のイベントを1つのケースにまとめます。プロセスの流れを可視化できるほか、取引ごとのサイクルタイムの算出にも欠かせません。一意のIDがなければ、システム内で同時に処理される何千件もの支払いを区別できません。

通常、この項目の値は支払いのライフサイクルを通じて変わりません。ただし、複数のシステムが関わる複雑なケースでは、複合キーを使うか、一意のエンドツーエンド参照番号から対応付ける必要があります。

プロセスモデルの作成と個々の支払いの追跡に必要な基本のケースIDです。

通常、取引ヘッダー、支払い指図テーブル、またはメイン台帳のログにあります。

この属性には、プロセスが失敗した技術的または業務上の理由が記録されます。支払いが拒否された場合、検証に失敗した場合、または送信エラーが発生した場合に値が設定されます。

エラーコードの分析は、「支払い失敗率」や「手戻り率」を下げるための主な方法です。よくあるエラーコードをまとめると、マスターデータの不備や外部の清算機関との接続問題など、システム全体に関わる問題を特定できます。

理想経路では、通常この項目は空欄です。値がある場合は、理想的なプロセスの流れから逸脱している可能性があり、例外処理のサブプロセスが開始されることがあります。

失敗や手戻りの根本原因を分析するための主要な属性です。

エラーログ、拒否メッセージ、または応答ペイロードにあります。

この属性は、支払いプロセスの特定のステップを実行した人またはシステムを示します。手作業で確認を行う担当者の場合も、自動タスクを実行するシステムアカウントの場合もあります。

リソースの利用状況やボトルネックを分析するうえで、このデータは重要です。自動処理（STP）と手作業による対応を区別できます。担当者が手作業で処理する割合が高い場合、コストの増加やサイクルタイムの長期化につながることがあります。

コンプライアンスの観点では、職務分掌の分析に役立ちます。支払いを作成した人と承認した人が同一でないことを確認できます。

自動処理率（STP）やリソースの生産性を分析できます。

監査ログまたは取引テーブルのメタデータ列にあります。

この属性は、電信送金、ACH、クレジットカード、即時決済など、支払いの実行方法を分類します。方法ごとに、通常は異なるプロセス経路、所要時間の目安、コストが設定されています。

この属性でデータを分類すると、異なる決済手段の処理状況を比較できます。たとえば、電信送金では、自動処理されるACH一括処理よりも手動承認のステップが多い場合があります。

支払い方法の構成を把握すると、キャパシティの計画や顧客行動の変化の特定に役立ちます。たとえば、従来の小切手からデジタル即時決済への移行を把握できます。

サービスレベル合意が異なるプロセスのバリアント（即時決済と電信送金など）を区別するうえで重要です。

支払い指図の詳細にあります。

この属性は、支払いの目標期限を表します。「期日どおりの支払い率」を測定し、サービスレベル合意（SLA）の達成状況を確認できます。

実際の完了日時と支払い期日を比較すると、プロセスのパフォーマンスを明確に評価できます。期日を過ぎて完了した支払いは遅延とみなされ、違約金が発生したり、取引先との関係に影響したりすることがあります。

この項目は、買掛金処理や、納期が契約上の義務となるサービス提供契約で特に重要です。

SLAの達成状況や期日どおりの支払い率の算出に必要です。

請求書ヘッダーまたは支払い依頼の指図にあります。

この属性は、送金される金額を表します。プロセスの非効率性による影響を金額で評価するための主要な数値指標です。たとえば、100万ドルの支払いの遅延は、10ドルの支払いの遅延よりも重大な影響を及ぼすことがあります。

分析では、取引量の集計、必要な流動性の算出、金額帯別の支払いの分類に使います。高額の支払いは、少額の支払いとは異なる承認ワークフローをたどることが多く、この属性によって経路を区別できます。

金額を正しく比較するには、通貨コードと組み合わせる必要があります。通貨を換算せず、または通貨別に分けずに金額を集計すると、財務報告に誤解を招く結果が生じるおそれがあります。

財務への影響を分析し、高額取引と少額取引を分類できます。

取引明細または財務計上テーブルにあります。

この属性は、支払い金額の通貨単位を示します。例として、USD、EUR、GBPがあります。正確な財務報告や、国境を越える取引のワークフローを適切に処理するうえで欠かせません。

地域ごとの業績や為替処理にかかる時間を把握するため、通貨で絞り込んで分析することがあります。通貨によって締め切り時刻、決済サイクル、規制要件が異なり、プロセスの流れにも直接影響します。

この属性がないと、「支払い金額」が何の通貨を指すのか分かりません。また、異なる通貨の金額を単一の報告通貨に換算し、グローバルなダッシュボードに表示できます。

財務データの基準をそろえ、国境を越えるプロセスの違いを特定するために必要です。

取引テーブルの支払い金額と並んで記録されています。

この属性は、不正検知エンジンやリスクモデルが算出する値です。スコアが高いほど、取引が不正または高リスクである可能性が高いことを示します。

プロセス分析では、このスコアを使って、一部の支払いで確認が長引く理由を把握できます。リスクスコアの高い支払いでは手動対応が発生しやすく、サイクルタイムが長くなることがあります。リスクスコアと最終結果（承認または拒否）を照合すると、リスクルールの効率を調整する際に役立ちます。

すべてのシステムが数値スコアを算出するわけではなく、ステータスフラグのみを提供する場合もあります。ただし、最新の決済ゲートウェイでは、判定に使う標準的な指標です。

不正チェックによる手動確認や保留など、プロセス逸脱の理由を把握できます。

不正検知システムまたはリスクエンジンの出力です。

この属性は、モバイルアプリ、ウェブポータル、API、ファイルアップロードなど、支払い指図の受付経路を示します。顧客の行動やチャネルの利用状況を把握できます。

チャネル別にプロセスのパフォーマンスを分析すると、技術的な差を特定できます。たとえば、API経由の支払いは即時に処理される一方、ファイルアップロードによる支払いは一括処理の時間帯まで待機することがあります。各プラットフォームでのユーザー体験を把握するのに役立ちます。

手入力やファクスなどの従来型チャネルからデジタルチャネルへの移行を分析し、デジタルトランスフォーメーションの取り組みに役立てることもできます。

受付経路別の取引量の傾向やパフォーマンスの違い（モバイルとウェブなど）の分析に役立ちます。

取引ヘッダーまたはセッションのメタデータにあります。

この属性は、支払い先を示します。企業間取引では仕入先、個人間取引では個人の受取人を指し、誰に支払うのかを把握できます。

受取人別に支払いを分析すると、高リスクの取引先への支払いが頻繁に発生している、特定の仕入先への依存度が高いといった傾向が分かることがあります。また、複数の少額支払いが、想定外の1つの受取人に集約されていないかを確認するなど、不正分析にも役立ちます。

「Inc.」と「Incorporated」のように表記が異なることが多く、データ品質の問題が起きやすい項目です。正確に集計するには、データのクリーニングが必要になる場合があります。

仕入先分析、不正検知、リスク評価に役立ちます。

支払い指図の受取人詳細にあります。