融資プロセスデータテンプレート

アクティビティ名とは、「申請提出済み」、「信用調査完了」、「融資オファー生成済み」など、融資ワークフロー内の特定のステップまたはマイルストーンを指します。各アクティビティは、時間とリソースを消費するプロセス内の明確なポイントを表します。

これらのアクティビティの順序と頻度を分析することは、プロセスマイニングのコアです。これにより、実際のプロセス``フローを明らかにし、一般的な経路を特定し、ボトルネックを検出し、異なるステージの期間を測定するのに役立ちます。明確で一貫したアクティビティ命名は、理解しやすく正確なプロセス``マップを作成するために不可欠です。

プロセスのステップを定義し、プロセス``フローの可視化と分析、ボトルネックの特定、ステージ期間の測定を可能にします。

業務プロセス``ステップを記録するイベントログまたはトランザクション``テーブルで確認できます。

イベント開始時間は、アクティビティの開始を示す正確なタイムスタンプです。これはイベントログの基本的なコンポーネントであり、各ケースのプロセス``フローを再構築するためにイベントを時系列順に並べる上で不可欠です。

プロセス分析では、開始時間は全体のケース期間、アクティビティ間の経過時間、および終了時間も利用可能な場合の各ステップのアクティブな処理時間を計算するために使用されます。プロセスのタイミングを理解し、遅延を特定し、サービスレベル契約に対するパフォーマンスを評価するために使用される主要な時間的アトリビュートです。

このタイムスタンプは、イベントの順序付け、プロセスサイクルタイムの計算、およびアクティビティ間の遅延の特定に不可欠です。

あらゆるシステムのイベントログまたはトランザクション履歴テーブルにおける必須フィールド。

融資申請IDは、全ての融資申請が作成時に割り当てられる一意のキーです。これは主要なケース識別子として機能し、初回提出から最終的な融資実行またはクローズまでの関連する全てのアクティビティ、文書、意思決定を紐付けます。この一貫性は、各申請のエンドツーエンドのジャーニーを再構築するために不可欠です。

プロセスマイニングでは、この属性を使用して関連する全てのイベントを単一のケースにグループ化し、申請ごとにプロセスフロー、サイクルタイム、およびバリエーションの分析を可能にします。一貫性のある一意のケース識別子がなければ、プロセスを正確にマッピングしたり、そのパフォーマンスを分析したりすることは不可能です。

プロセスマイニングの根幹をなす要素です。関連するすべてのイベントを1つのケースに集約することで、ローン組成ジャーニー全体の分析が可能になります。

通常、融資申請のヘッダーまたはメインのトランザクションテーブルで確認されます。

ソースシステム名とは、融資実行システム (LOS)、CRM、文書管理システムなど、イベントデータを生成した元となるアプリケーションまたはプラットフォームを特定するものです。現代の企業では、融資実行のような単一のビジネスプロセスが複数の相互接続されたシステムにまたがることは珍しくありません。

各イベントのソースシステムを特定することは、データ検証、トラブルシューティング、およびプロセスの技術的ランドスケープを理解するために不可欠です。これにより、アナリストはデータをその起源まで遡って追跡し、異なるシステムが全体のプロセスフローと潜在的な遅延にどのように貢献しているかを評価できます。

データの起源を追跡するのに役立ち、データ検証と複数のIT``システムにまたがるプロセス``フローを理解するために不可欠です。

データ抽出の標準フィールドとして利用できることが多く、データエンジニアリングプロセス中に追加することもできます。

この属性は、ソースシステムからの最新のデータ抽出または更新のタイムスタンプを記録します。これは、データガバナンスと品質保証に不可欠なメタデータフィールドです。

データがいつ最終更新されたかを知ることは、アナリストがデータセットの鮮度を理解するのに役立ち、分析が最新の情報に基づいていることを保証します。これは、進行中のプロセスを監視する上で特に重要であり、プロセスビューがどれだけ最新であるかを示します。このタイムスタンプは、データパイプラインのデバッグや、データ取り込みスケジュールに関する潜在的な問題を特定する上でも価値があります。

データの鮮度を確認し、分析がタイムリーな情報に基づいていることを保証し、データ品質の管理に役立ちます。

通常、データ抽出、変換、ロード (ETL) プロセス中に生成され保存されます。

イベント終了時間は、アクティビティが完了した正確な瞬間を示します。一部のイベントは開始時間のみを持つマイルストーンですが、多くのアクティビティは明確な期間を持ちます。終了時間は、このアクティブな処理時間を直接計算することを可能にします。

アクティブな処理時間の分析は、リソース利用率の理解、特定のタスク内の非効率性の特定、およびケースに積極的に作業している時間と待機時間を区別するために不可欠です。例えば、融資審査が実際にどのくらいの期間かかったかを、申請が融資審査担当者のキューで待機していた時間とは別に判断するのに役立ちます。

アクティビティのアクティブな処理時間の計算を可能にし、付加価値のある作業と待機時間を区別する上で重要です。

アクティビティ期間を追跡するシステムのイベントログまたはトランザクション``テーブルで、開始時間と並んで見つかることがよくあります。

融資申請の最終結果が「却下」の場合、却下理由は、その理由を説明するコードまたはテキスト記述を提供します。一般的な理由としては、「信用履歴不足」、「高債務対収入比率」、「不完全な申請」などがあります。

この属性は、申請失敗の根本原因分析にとって非常に貴重です。最も頻繁な却下理由を分析することで、組織は申請者プール、引受審査基準、または申請プロセス自体におけるシステム的な問題を特定できます。これらのインサイトは、マーケティング戦略、製品開発、および却下率を削減するために設計されたプロセス改善に役立ちます。

根本原因分析に不可欠なインサイトを提供し、申請が却下される理由を理解し、ターゲットを絞ったプロセス改善を可能にします。

最終決定イベントの一部として記録され、多くの場合「却下」の決定結果と関連付けられます。

担当ユーザーは、特定のアクティビティを実行した、または責任を負う個々の従業員またはシステム``ユーザーを特定します。これは、融資担当者、処理担当者、融資審査担当者、または融資実行担当者である可能性があります。

このアトリビュートは、チームおよび個人のパフォーマンス、ワークロード配分、およびリソース配分を分析するための基本となります。ユーザー別にアクティビティを追跡することで、企業は高パフォーマンスの個人を特定し、トレーニングニーズを正確に把握し、ワークロードを再調整して効率を最適化できます。また、異なるユーザーやチームがプロセスの結果とサイクル``タイムにどのように影響するかを分析することも可能になります。

ワークロードの配分、チームパフォーマンスの分析、およびプロセスにおけるリソース関連のボトルネックの特定に不可欠です。

通常、システム内のユーザーアクションを記録するトランザクションログまたはイベントログで確認されます。

決定結果は、融資申請が完全に処理された後の最終ステータスを示します。一般的な結果には、「承認済み」、「却下」、「申請者による取り下げ」、「カウンターオファー」などがあります。

このアトリビュートは、どのプロセス経路が成功した結果につながり、どの経路が失敗した結果につながるかを理解しようとする結果分析にとって不可欠です。プロセスのバリエーションと決定結果を関連付けることで、企業は承認率の向上につながるベストプラクティスや、却下につながる行動を特定できます。この分析は、プロセス効率とビジネス成果を改善するために極めて重要です。

結果分析に不可欠であり、どのプロセスの動作と経路が成功または失敗した融資申請と相関するかを特定するのに役立ちます。

通常、融資申請ステータスフィールドに記録されるか、トランザクション履歴における特定の決定イベントとして記録されます。

申請チャネルは、申請者が使用した最初のコンタクト``ポイントまたは提出方法を特定します。例としては、「オンライン``ポータル」、「モバイル``アプリ」、「支店」、「第三者ブローカー」などがあります。

異なるチャネルは、顧客体験と内部処理ワークフローが大きく異なる場合があります。チャネル別にプロセスを分析することで、企業は各提出経路の効率と有効性を理解できます。これにより、どのチャネルが処理時間が速いか、顧客満足度が高いか、データ品質が良いかなどが明らかになり、技術とオペレーションへの戦略的投資に関するインサイトを提供します。

オンライン、支店、モバイルなどの異なる提出チャネル間のプロセス``パフォーマンスと顧客体験の分析を可能にします。

申請プロセスの開始時に取得され、主融資申請テーブルに格納されます。

このブール属性は、自動信用照会や初期文書検証など、システムによって自動的に実行されるアクティビティと、人間ユーザーが手動で実行するアクティビティを区別します。

この区別は、プロセス内の自動化レベルとその効率への影響を理解する上で不可欠です。自動ステップと手動ステップを分析することで、さらなる自動化の機会を特定し、既存の自動化による時間節約を定量化し、人材のワークロードを理解するのに役立ちます。これにより、融資実行の全過程における人とシステムの相互作用を明確に把握できます。

システム主導のアクティビティと人間主導のアクティビティを区別するのに役立ち、自動化分析とリソース``ワークロードの理解において重要です。

イベントログ内のフィールドであるか、アクティビティ名またはイベントに関連付けられたユーザー（例: 「システム」ユーザー）に基づいて派生させることができます。

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

異なる融資商品は、それぞれ異なるプロセス、コンプライアンス要件、およびリスクプロファイルを持つことがよくあります。商品タイプ別にプロセスを分析することは、バリエーションを特定し、特定の製品ラインのワークフローを最適化するために不可欠です。このセグメンテーションにより、より的を絞った改善が可能になり、融資ポートフォリオ全体でのサイクルタイム、承認率、および手戻りの違いを説明するのに役立ちます。

異なる種類の融資に対するワークフローのパフォーマンスを比較し、バリエーションを特定するために、プロセスのセグメンテーションを可能にします。

融資申請書の標準フィールドであり、主要申請データ``テーブルに格納されます。

融資額は、申請者が希望する元金総額を表します。これは、融資申請に関連する複雑さとリスクにしばしば影響を与える重要な財務属性です。

融資額が大きくなると、より厳格な引受審査手続きが発動されたり、追加の承認レベルが必要になったり、異なる手数料体系が適用されたりする場合があります。融資額に基づいてプロセスを分析することで、その価値が処理時間、承認率、および適用される審査の厳しさにどのように影響するかを明らかにできます。これは、融資パイプラインの総価値や融資1ドルあたりのコストを計算するといった財務分析の主要なインプットでもあります。

この属性は、プロセスの複雑さとリスクの主要な要因であり、融資額がサイクルタイムと承認率にどのように影響するかを分析することを可能にします。

融資申請データの主要フィールドであり、通常、主融資情報テーブルに格納されます。

引受審査SLAターゲットは、融資申請の引受審査フェーズが完了すべき期待される期間を定義します。このターゲットは、タイムリーな処理を確実にするためにビジネスによって設定された主要業績評価指標 (KPI) ベンチマークです。

タイムスタンプから計算された引受審査ステージの実際の期間をこのターゲットと比較することで、組織はSLA遵守状況を測定できます。この分析は、引受審査のボトルネックを特定し、チームのパフォーマンスを評価し、顧客の期待を効果的に管理するのに役立ちます。

サービスレベル契約に対するパフォーマンスを測定するためのベンチマークとして機能し、遅延を特定し、運用目標を管理するのに役立ちます。

通常、ビジネスルール構成またはサービスレベル契約文書で定義され、ケースデータとともに保存される場合があります。

信用スコアは、申請プロセス中に信用情報機関から取得される、申請者の信用力を数値で表したものです。これは、リスク評価および融資審査決定における主要なファクターです。

信用スコアが高いほど、一般的にリスクが低いことを示し、より有利な融資条件や迅速な承認プロセスにつながる可能性があります。プロセスマイニングにおいて、信用スコアがプロセスにどのように影響するかを分析することで、さまざまなリスク``プロファイルを持つ申請者に対する異なる処理経路が明らかになります。例えば、スコアが低い申請は、より多くの手動審査を受けたり、追加書類を必要としたりするため、サイクル``タイムが長くなる可能性があります。

リスク評価における主要なファクターであり、プロセス経路、決定結果、および全体のサイクル``タイムに大きく影響する可能性があります。

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

地理的場所とは、物件の所在地、処理支店、申請者の地域など、融資に関連する場所を指します。

この属性は、プロセスにおける地域ごとの差異を分析する上で役立ちます。例えば、州によって独自のコンプライアンス要件があり、プロセスに手順が追加されたり、特定の支店が他の支店よりも効率的である場合があります。この地理的セグメンテーションにより、融資実行プロセスに影響を与える性能差、リソースの必要性、市場固有のトレンドが明らかになります。

プロセスのパフォーマンス、コンプライアンス要件、およびビジネス上の成果における地域的な違いを明らかにするための地理的データ分析を可能にします。

物件住所や申請が提出された支店など、申請データで確認できます。

この属性は、「融資処理」、「引受審査」、「クロージング」などの特定の部署または機能チームを識別し、ある時点でアクティビティを担当するか、ケースを所有するチームを示します。

部署間の引き渡しを追跡することは、組織のワークフローを理解し、部門横断的な遅延を特定するために不可欠です。部署別にプロセスを分析することは、異なるチームのパフォーマンスを測定し、彼らのワークロードを理解し、チーム間のコラボレーションと引き渡し手順を最適化するのに役立ちます。

機能チームによるプロセスの引き継ぎとパフォーマンスの分析を可能にし、部門横断的なボトルネックと非効率性を浮き彫りにします。

ワークフロー管理システムで確認できるか、タスクに割り当てられたユーザーまたはロールから派生させることができます。

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

このセグメンテーションは、このアトリビュートに基づいてプロセスが異なる可能性があるため重要です。既存顧客は、既存のデータにより合理化されたプロセスを持つ可能性がありますが、新規顧客は、より広範な本人確認と情報検証を必要とする場合があります。申請者タイプ別にプロセスを分析することで、これらの違いを浮き彫りにし、各セグメントの顧客ジャーニーを調整・最適化するのに役立ちます。

異なるワークフローやサービスレベルの期待を持つ可能性のある、異なる顧客セグメント間のプロセス比較を可能にします。

顧客関係管理（CRM）データから派生されるか、申請書に記載されます。