ローン組成データテンプレート

アクティビティ名は、「申請送信」、「信用調査完了」、「ローンオファー作成」など、ローン組成ワークフロー内の特定のステップやマイルストーンを表します。各アクティビティは、時間とリソースを消費するプロセス上の明確な地点です。

これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの中心的な作業です。実際のプロセスフローの把握、よくある経路の特定、ボトルネックの検出、各段階の所要時間の測定に役立ちます。理解しやすく正確なプロセスマップを作成するには、アクティビティ名を明確かつ一貫して付けることが欠かせません。

プロセスの各ステップを定義し、プロセスフローの可視化と分析、ボトルネックの特定、各段階の所要時間の測定を可能にします。

業務プロセスのステップを記録するイベントログまたは取引テーブルにあります。

イベント開始時刻は、アクティビティの開始を示す正確なタイムスタンプです。イベントログの基本要素であり、イベントを時系列に並べてケースごとのプロセスフローを再構築するために欠かせません。

プロセス分析では、開始時刻を使ってケース全体の所要時間、アクティビティ間の経過時間、終了時刻がある場合は各ステップの実作業時間を計算します。プロセスの時間配分を把握し、遅延を特定し、サービスレベル合意に対するパフォーマンスを評価するための主要な時間属性です。

イベントを時系列に並べ、プロセスのサイクルタイムを計算し、アクティビティ間の遅延を特定するために欠かせないタイムスタンプです。

任意のシステムのイベントログまたは取引履歴テーブルに必要な項目です。

ローン申請IDは、ローン依頼が作成された時点で各申請に割り当てられる一意のキーです。主要なケース識別子として、初回送信から最終的な資金実行または完了まで、関連するすべてのアクティビティ、書類、判断を結び付けます。申請ごとのエンドツーエンドの経路を再構築するには、この一貫性が欠かせません。

プロセスマイニングでは、この属性を使って関連するすべてのイベントを1つのケースにまとめ、申請単位でプロセスフロー、サイクルタイム、ばらつきを分析します。一貫した一意のケース識別子がなければ、プロセスを正確にマッピングしたり、パフォーマンスを分析したりすることはできません。

関連するすべてのイベントを1つのケースにまとめ、ローン組成の全行程を分析できるようにする、プロセスマイニングの基本キーです。

通常は、ローン申請のヘッダーまたは主要な取引テーブルにあります。

ソースシステム名は、イベントデータを生成した元のアプリケーションまたはプラットフォームを示します。たとえば、ローン組成システム（LOS）、CRM、文書管理システムなどです。現在の企業では、ローン組成のような1つの業務プロセスが、相互接続された複数のシステムにまたがることがよくあります。

各イベントのソースシステムを特定することは、データ検証、トラブルシューティング、プロセスを支える技術環境の把握に欠かせません。データを発生元まで追跡し、各システムがプロセス全体のフローや潜在的な遅延にどのように関わっているかを評価できます。

データを発生元まで追跡できるため、データ検証や複数のITシステムにまたがるプロセスフローの把握に役立ちます。

データ抽出時の標準項目として用意されているか、データエンジニアリングの工程で追加できます。

この属性は、ソースシステムからデータを最後に抽出または更新した時点のタイムスタンプを記録します。データガバナンスと品質保証に欠かせないメタデータ項目です。

データが最後に更新された時点を把握すると、データセットの鮮度を確認し、最新情報に基づいて分析できます。継続中のプロセスを監視する際には、プロセスビューがどの程度最新かを示すため、特に重要です。また、データパイプラインのデバッグや、データ取り込みスケジュールの問題特定にも役立ちます。

データの鮮度を確認し、適時性のある情報に基づく分析とデータ品質の管理を支援します。

通常は、データの抽出、変換、ロード（ETL）処理の中で生成・保存されます。

イベント終了時刻は、アクティビティが完了した正確な時点を示します。開始時刻だけを持つマイルストーンもありますが、多くのアクティビティには明確な所要時間があります。終了時刻があれば、この実作業時間を直接計算できます。

実作業時間を分析することは、リソースの利用状況を把握し、特定タスクの非効率性を特定し、ケースに実際に取り組んでいた時間と待機時間を区別するために重要です。たとえば、申請が審査担当者のキューで待機していた時間を除き、審査そのものにかかった時間を把握できます。

アクティビティの実作業時間を計算できるため、付加価値のある作業と待機時間を区別するうえで重要です。

アクティビティの所要時間を追跡するシステムのイベントログまたは取引テーブルで、開始時刻とともに記録されていることがよくあります。

ローン商品タイプは、申請された金融商品に基づいてローン申請を分類します。例として、「通常型住宅ローン」、「FHAローン」、「自動車ローン」、「個人信用枠」などがあります。

ローン商品ごとに、プロセス、コンプライアンス要件、リスク特性が異なることがよくあります。商品タイプ別にプロセスを分析することは、ばらつきの特定や商品ラインごとのワークフローの最適化に欠かせません。この分類により、より対象を絞った改善が可能になり、ローンポートフォリオにおけるサイクルタイム、承認率、手戻りの違いも説明しやすくなります。

プロセスを分けて分析できるため、ローンの種類ごとにパフォーマンスを比較し、ワークフローの違いを特定できます。

ローン申請フォームの標準項目であり、主要な申請データテーブルに保存されます。

ローン金額は、申請者が希望する元本の額です。ローン申請の複雑さやリスクに影響する重要な財務属性です。

ローン金額が大きい場合、より厳格な審査手続き、追加の承認階層、異なる手数料体系が必要になることがあります。ローン金額に基づいてプロセスを分析すると、金額が処理時間、承認率、審査の厳格さに与える影響を把握できます。また、ローンパイプラインの総額や融資1ドル当たりのコストなど、財務分析にも使う重要な入力値です。

プロセスの複雑さとリスクを左右する主要因であり、ローン金額がサイクルタイムや承認率に与える影響を分析できます。

ローン申請データの中核項目であり、通常は主要なローン情報テーブルに保存されます。

判断結果は、ローン申請が処理を完了した後の最終ステータスを示します。一般的な結果には、「承認」、「否認」、「申請者による取下げ」、「条件変更提案」などがあります。

この属性は、結果分析に欠かせません。成功または失敗につながるプロセス経路を把握できるためです。プロセスのばらつきと判断結果を関連付けることで、承認率を高めるベストプラクティスや、否認につながる行動を特定できます。この分析は、プロセス効率と業務成果の改善に重要です。

結果分析に欠かせない属性であり、どのプロセス上の行動や経路がローン申請の成功または失敗と関連するかを特定できます。

通常は、ローン申請のステータス項目、または取引履歴に記録された特定の判断イベントとして保存されます。

ローン申請の最終結果が「否認」の場合、否認理由には理由を説明するコードまたはテキストが記録されます。一般的な理由には、「信用履歴不足」、「債務返済比率が高い」、「申請不備」などがあります。

この属性は、申請失敗の根本原因分析に非常に役立ちます。否認理由の頻度を分析すると、申請者層、審査基準、申請プロセス自体にある構造的な問題を特定できます。こうした分析結果は、否認率を下げるためのマーケティング戦略、商品開発、プロセス改善に役立ちます。

根本原因分析に必要な情報を提供し、申請が否認される理由の把握と、対象を絞ったプロセス改善を可能にします。

最終判断イベントの一部として記録され、通常は「否認」という判断結果に関連付けられます。

担当ユーザーは、特定のアクティビティを実行した、または担当している従業員やシステムユーザーを識別します。ローン担当者、処理担当者、審査担当者、契約担当者などが該当します。

この属性は、チームや個人のパフォーマンス、業務量の配分、リソースの割り当てを分析するための基本項目です。ユーザー単位でアクティビティを追跡すると、高い成果を上げている担当者の特定、研修ニーズの把握、業務量の再配分による効率化が可能になります。また、ユーザーやチームの違いがプロセスの結果やサイクルタイムに与える影響も分析できます。

業務量の配分、チームのパフォーマンス、プロセス内のリソースに起因するボトルネックの特定を分析するために欠かせません。

通常は、システム内のユーザー操作を記録する取引ログまたはイベントログにあります。

申請チャネルは、申請者が最初に接触した窓口または申請方法を示します。例として、「オンラインポータル」、「モバイルアプリ」、「支店」、「外部ブローカー」などがあります。

チャネルによって、顧客体験や社内の処理ワークフローが大きく異なることがあります。チャネル別にプロセスを分析すると、各申請経路の効率と有効性を把握できます。処理時間が短いチャネル、顧客満足度が高いチャネル、データ品質に優れたチャネルを明らかにし、テクノロジーや業務への戦略的な投資判断に役立てられます。

オンライン、支店、モバイルなど、申請チャネルごとのプロセスパフォーマンスと顧客体験を分析できます。

申請プロセスの開始時に取得され、主要なローン申請テーブルに保存されます。

このブール型属性は、自動信用調査や初回書類検証など、システムが自動的に実行したアクティビティと、人間のユーザーが実行したアクティビティを区別します。

この区別は、プロセスの自動化レベルと効率への影響を把握するために重要です。自動処理と手動処理を分析すると、さらなる自動化の機会、既存の自動化による時間短縮効果、人員の業務量を明らかにできます。ローン組成の全行程における人とシステムの関わりを明確に把握できます。

システム主導のアクティビティと人が行うアクティビティを区別できるため、自動化の分析やリソースの業務量把握に役立ちます。

イベントログの項目として記録されるか、アクティビティ名やイベントに関連付けられたユーザー（例：「system」ユーザー）に基づいて導出できます。

信用スコアは、申請プロセス中に信用情報機関から取得する、申請者の信用力を数値で表したものです。リスク評価と審査判断における主要な要素です。

信用スコアが高いほど一般にリスクは低く、より有利なローン条件や迅速な承認につながる可能性があります。プロセスマイニングで信用スコアがプロセスに与える影響を分析すると、リスク特性の異なる申請者に対する処理経路の違いを把握できます。たとえば、スコアが低い申請では手動確認が増えたり、追加書類が必要になったりして、サイクルタイムが長くなる場合があります。

リスク評価における主要因であり、プロセス経路、判断結果、全体のサイクルタイムに大きな影響を与える可能性があります。

外部の信用情報機関から取得し、申請者のプロファイルデータとともに保存します。

地理的位置は、ローンに関連する場所を示します。物件の所在州、処理を担当する支店、申請者の地域などが該当します。

この属性は、プロセスにおける地域ごとの差異を分析する際に役立ちます。たとえば、州によって異なるコンプライアンス要件によりプロセスに手順が追加される場合や、特定の支店が他の支店より効率的に処理している場合があります。地域別に分けて分析することで、パフォーマンスの差、必要なリソース、ローン組成プロセスに影響する市場ごとの傾向を明らかにできます。

地域別に分析することで、プロセスのパフォーマンス、コンプライアンス要件、業務成果の違いを明らかにできます。

物件住所や申請を受け付けた支店など、申請データで確認できます。

審査SLA目標は、ローン申請の審査段階を完了すべき想定期間を定義します。適時処理を確保するために業務側が設定する、主要業績評価指標（KPI）の基準値です。

タイムスタンプから算出した審査段階の実際の所要時間とこの目標を比較することで、SLAの遵守状況を測定できます。この分析は、審査におけるボトルネックの特定、チームのパフォーマンス評価、顧客の期待値管理に役立ちます。

サービスレベル合意に対するパフォーマンスを測る基準となり、遅延の特定と業務目標の管理に役立ちます。

通常は、業務ルールの設定またはサービスレベル合意の文書で定義され、ケースデータとともに保存される場合があります。

この属性は、「Loan Processing」「Underwriting」「Closing」など、特定の時点でアクティビティを担当する、またはケースを管理する部門や機能チームを識別します。

部門間の引き継ぎを追跡することは、組織のワークフローを理解し、部門横断的な遅延を特定するうえで重要です。部門別にプロセスを分析すると、各チームのパフォーマンスや業務量を測定し、チーム間の連携や引き継ぎ手順を改善できます。

機能チーム別にプロセスの引き継ぎとパフォーマンスを分析し、部門間のボトルネックや非効率を明らかにします。

ワークフロー管理システムで確認できるほか、タスクに割り当てられたユーザーやロールから導出できます。

申請者タイプは、金融機関との関係に基づいてローン申請者を分類します。たとえば、「新規顧客」または「既存顧客」です。

この属性によってプロセスが異なる場合があるため、重要な分類です。既存顧客は登録済みのデータがあるため処理が簡略化される一方、新規顧客には本人確認や情報検証をより広範に行う必要がある場合があります。申請者タイプ別にプロセスを分析すると、こうした違いを明らかにし、各顧客セグメントに合わせて顧客体験を調整・改善できます。

顧客セグメントごとにプロセスを比較できます。セグメントによってワークフローやサービスレベルへの期待が異なる場合があります。

顧客関係管理（CRM）データから導出するか、申請フォームで指定します。