融資組成データテンプレート

アクティビティ名は、融資実行ワークフロー内の特定のステップやマイルストーンを示します。たとえば、「申請を提出」「信用調査を完了」「融資条件を提示」などです。各アクティビティは、時間とリソースを要するプロセス上の個別の時点を表します。

アクティビティの順序や頻度の分析は、プロセスマイニングの中核です。実際のプロセスの流れを把握し、よく見られる経路やボトルネックを特定し、各段階にかかる時間を測定できます。わかりやすく正確なプロセスマップを作成するには、アクティビティ名を明確かつ一貫して付けることが重要です。

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

業務プロセスの各ステップを記録したイベントログやトランザクションテーブルに含まれています。

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

プロセス分析では、開始時刻を使ってケース全体の所要時間やアクティビティ間の時間を算出します。また、終了時刻も記録されていれば、各ステップの実作業時間も計算できます。プロセスの所要時間を把握し、遅延を特定して、サービスレベル合意に照らしてパフォーマンスを評価するための主要な時間属性です。

イベントの順序付けやプロセスのサイクルタイムの算出、アクティビティ間の遅延の特定に欠かせないタイムスタンプです。

任意のシステムのイベントログやトランザクション履歴テーブルに必要な項目です。

融資申請IDは、融資の申請が作成されると割り当てられる一意のキーです。主要なケース識別子として、申請の提出から資金の支払いまたは終了まで、関連するすべてのアクティビティ、書類、判断を結び付けます。この一貫性は、各申請の一連の流れをエンドツーエンドで再構成するうえで欠かせません。

プロセスマイニングでは、この属性を使って関連するすべてのイベントを1つのケースにまとめ、申請ごとのプロセスの流れ、処理時間、バリアントを分析します。一貫性のある一意のケース識別子がなければ、プロセスを正確にマッピングしたり、パフォーマンスを分析したりできません。

関連するすべてのイベントを1つのケースにまとめる、プロセスマイニングの基本となるキーです。融資実行の一連の流れを分析できます。

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

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

各イベントのソースシステムを特定することは、データの検証や問題の調査、プロセスを支えるシステム環境の把握に欠かせません。データの出所をたどり、各システムがプロセスフロー全体にどう関わり、どこで遅延が生じる可能性があるかを分析できます。

データの出所をたどれるため、データの検証や、複数のITシステムにまたがるプロセスフローの把握に役立ちます。

データ抽出時の標準項目として含まれていることが多く、データエンジニアリングの工程で追加することもできます。

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

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

データが最新であることを確認できるため、適時性のある情報に基づく分析とデータ品質の管理に役立ちます。

通常、データの抽出、変換、読み込み（ETL）の工程で生成され、保存されます。

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

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

アクティビティの実作業時間を算出できるため、付加価値のある作業と待ち時間を区別するうえで役立ちます。

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

ローン商品タイプは、申請された金融商品に基づいてローン申請を分類します。たとえば、「一般住宅ローン」「FHAローン」「自動車ローン」「個人向け融資枠」などがあります。

ローン商品によって、プロセスやコンプライアンス要件、リスク特性が異なることがあります。商品タイプ別にプロセスを分析すると、違いを特定し、商品ごとのワークフローを改善できます。この分類により、改善の対象を絞り込み、ローンポートフォリオ内でサイクルタイムや承認率、手戻りに差が生じる理由を把握できます。

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

ローン申請フォームの標準項目で、通常は申請データのメインテーブルに保存されます。

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

ローン金額が大きい場合、より厳格な審査が必要になったり、追加の承認段階が設けられたり、手数料体系が異なったりすることがあります。ローン金額別にプロセスを分析すると、金額が処理時間や承認率、審査の厳しさにどう影響するかが分かります。また、ローン案件全体の総額や貸付額あたりのコストを算出するなど、財務分析にも役立ちます。

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

ローン申請データの基本項目で、通常はローン情報のメインテーブルに保存されます。

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

この属性は、申請が不成立となる根本原因の分析に役立ちます。否認理由の頻度を分析することで、申請者層や審査基準、申請プロセス自体にある構造的な問題を特定できます。分析結果は、否認率の低減を目指すマーケティング戦略や商品開発、プロセス改善に役立てられます。

根本原因の分析に役立ち、申請が否認される理由の把握と、対象を絞ったプロセス改善につながります。

最終審査イベントの一部として記録され、「否認」の審査結果に関連付けられることがよくあります。

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

この属性は、どのプロセス経路が成功または不成功につながるかを把握する結果分析に欠かせません。プロセスの違いと審査結果を関連付けることで、承認率の向上につながるベストプラクティスや、否認につながる行動を特定できます。プロセスの効率と業務成果を改善するうえで重要な分析です。

結果分析に欠かせない属性です。ローン申請の成否と関連するプロセスの進め方や経路を特定できます。

通常、ローン申請のステータス項目、またはトランザクション履歴内の審査イベントとして記録されます。

担当ユーザーは、特定のアクティビティを実行した、または担当する従業員やシステムユーザーを示します。ローン担当者、事務処理担当者、審査担当者、クロージング担当者などが該当します。

この属性は、チームや個人のパフォーマンス、業務量の分配、リソースの割り当てを分析するうえで基本となります。ユーザーごとにアクティビティを追跡することで、組織は高い成果を上げている担当者や研修が必要な分野を特定し、業務量を再配分して効率を高められます。また、ユーザーやチームの違いがプロセスの結果やサイクルタイムにどう影響するかも分析できます。

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

通常、システム内でのユーザー操作を記録するトランザクションログやイベントログに含まれています。

申請チャネルは、申請者が最初に問い合わせたり申請を提出したりした方法を示します。たとえば、「オンラインポータル」「モバイルアプリ」「支店窓口」「外部ブローカー」などがあります。

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

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

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

この真偽値属性は、自動信用照会や申請書類の初期確認など、システムが自動で実行したアクティビティと、人が手動で実行したアクティビティを区別します。

この区別は、プロセスの自動化の度合いと、その効率への影響を把握するうえで重要です。自動処理と手動処理を分析すると、さらなる自動化の余地を特定し、既存の自動化による時間短縮を測定し、人員の業務量を把握できます。ローン組成のプロセス全体を通じた、人とシステムのやり取りも明確になります。

システムによる処理と人による処理を区別できるため、自動化分析やリソースの業務量の把握に役立ちます。

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

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

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

リスク評価の重要な要素であり、プロセスの経路や審査結果、全体のサイクルタイムに大きく影響する可能性があります。

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

地理的な場所は、ローンに関連する所在地を示します。不動産のある州、処理を行う支店、申請者の居住地域などが該当します。

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

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

不動産の住所や申請を提出した支店など、申請データに含まれています。

審査SLA目標は、ローン申請の審査段階を完了するまでに想定される期間を定めます。適時に処理を進めるために、業務上の重要業績評価指標（KPI）として設定される目標です。

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

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

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

この属性は、「ローン事務処理」「審査」「クロージング」など、アクティビティを担当する、または特定の時点でケースを所管する部門や機能別チームを示します。

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

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

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

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

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

顧客層ごとにワークフローやサービスレベルへの期待が異なる場合があるため、プロセスを比較できます。

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