貴社のKYC顧客オンボーディングデータテンプレート

「活動名」は、顧客オンボーディングジャーニーにおける個別のステップやマイルストーンを記述します。例えば、「申請提出済み」、「コンプライアンスレビュー開始」、「申請承認済み」などです。各活動は、プロセス内で申請を進めるためにユーザーまたはシステムによって取られた特定の行動を表します。\n\nこの属性は、プロセスマイニングの中核をなすプロセス地図を可視化するための基本です。異なる活動の順序と頻度を分析することで、アナリストは実際のプロセスフローを理解し、一般的な経路を特定し、プロセスの逸脱を発見し、手戻りや繰り返しの領域を特定できます。活動名の明確さと一貫性は、意味のある理解しやすいプロセスモデルを構築するために不可欠です。

プロセスのステップを定義し、プロセスフロー、ボトルネック、およびバリエーションの可視化と分析を可能にします。

ビジネスプロセスステップを記録するイベントログ、監査証跡、またはトランザクションテーブルで見つかります。

イベント開始時刻は、活動の開始を示す正確な日時です。ケースIDと活動名とともに、プロセスマイニングの3つの不可欠な柱の一つです。このタイムスタンプ付きデータにより、各ケース内のイベントを時系列で順序付けでき、これは実際に発生したプロセスフローを再構築するために必要です。\n\nこの属性は、すべての時間関連分析の基礎となります。活動の期間（終了時刻が利用可能な場合）、活動間の待機時間（引き継ぎ時間）、およびオンボーディングプロセス全体の総サイクルタイムを計算するために使用されます。これらの期間を分析することは、ボトルネックを特定し、SLA遵守を測定し、全体的なプロセスパフォーマンスを監視するのに役立ちます。

イベントの時系列順を提供し、プロセスモデルの発見とすべての時間ベースのパフォーマンス指標の計算に不可欠です。

イベントログ、申請監査証跡、またはトランザクションテーブルにあり、多くの場合、「タイムスタンプ」、「作成日」、または「開始時刻」と表示されます。

顧客申請IDは、新規顧客オンボーディング要求が開始された時点から完了または終了するまでの各要求に割り当てられる一意のキーです。この識別子は、単一のオンボーディングジャーニーに関連するすべての個々の活動、イベント、データポイントを結びつける中心的なスレッドとして機能し、プロセスマイニングにとって最も重要な属性となります。\n\n分析において、このIDは各顧客のエンドツーエンドプロセスを再構築することを可能にします。これにより、申請の進捗状況の追跡、総サイクルタイムの計算、および他の申請との経路の比較が可能になります。すべてのプロセスバリアント、ボトルネック、およびパフォーマンス指標は、申請ごとに分析されます。これは、この属性をケースIDとして正しく識別し使用することによってのみ可能です。

すべての関連イベントを単一のエンドツーエンドプロセスにグループ化するために不可欠であり、すべてのプロセスマイニング分析の基礎となります。

通常、顧客申請またはケース管理システムのヘッダーまたは主となるテーブルにあります。

ソースシステム属性は、特定のアクティビティデータを生成したアプリケーションまたはプラットフォームを示します。複雑な環境では、KYCプロセスは複数のシステムにまたがる場合があります。例えば、申請受付にはCRM、リスク評価には専用のKYCプラットフォーム、口座開設には基幹系銀行システムなどが使われます。

プロセスをソースシステム別に分析することで、技術的ランドスケープとそれがプロセスに与える影響を理解できます。システム間の統合の問題、データの遅延、あるいは異なるシステムが情報を記録する方法の不一致などを浮き彫りにすることができます。この視点は、オンボーディングのジャーニーを支えるシステムアーキテクチャの合理化を目指すITチームやプロセス改善チームにとって貴重です。

各プロセスステップがどこで発生するかに関するコンテキストを提供し、システム間の非効率性やデータ統合の課題を特定するのに役立ちます。

データ抽出やイベントログに含まれることが多く、特に複数の統合システムを持つ環境で顕著です。

この属性は、最新のデータ抽出または更新の日時を記録します。これはビジネスプロセス自体の一部ではありませんが、データ検証とガバナンスのための重要なメタデータです。分析されているデータの鮮度について透明性を提供します。

プロセス分析において、最終データ更新時刻を知ることは、生成される洞察の適時性を理解するために不可欠です。データがどれだけ最新であるかを確認することで、ユーザーがデータを信頼するのに役立ち、古い情報に基づく誤解を防ぎます。継続的なモニタリングのために、この属性はデータ更新が遅延したり失敗したりした場合にアラートを設定するために使用でき、プロセスマイニングダッシュボードの継続的な信頼性を確保します。

データセットの鮮度を示すことでデータ透明性を確保し、分析の関連性と正確性にとって非常に重要です。

データ抽出、変換、ロード（ETL）プロセス中に生成され、多くの場合、データセットのメタデータに含まれています。

ユーザー部署は、アクティビティを実行したユーザーが所属する機能グループまたはチームを指定します。例えば、「コンプライアンス」「顧客オンボーディング」「オペレーション」などです。これは、個別のユーザーIDと比較して、より高レベルの組織的なコンテキストを提供します。

部署の観点からプロセスを分析することは、部門横断的なコラボレーションを理解し、システム的なボトルネックを特定するために不可欠です。異なるチーム間の引き継ぎ（これはしばしば遅延や非効率性の主要な原因となります）を可視化するのに役立ちます。この情報は、チーム構造の最適化、責任の明確化、およびコミュニケーションチャネルの改善を通じて、よりスムーズなオンボーディングエクスペリエンスを創出するための鍵となります。

プロセスパフォーマンスとチーム間の引き継ぎ分析を可能にし、部門横断的な連携を改善する機会を浮き彫りにします。

ユーザーIDにリンクされたユーザープロファイルデータで利用できることが多く、またトランザクションに直接記録されることもあります。

イベント終了時刻は、活動が完了した正確な日時を示します。イベント開始時刻と組み合わせることで、各個別のタスクの処理時間を正確に計算できます。すべてのシステムが開始時刻と終了時刻の両方を提供するわけではなく、一部は完了を示す単一のタイムスタンプのみを提供する場合があります。\n\n終了時刻を持つことは、パフォーマンス分析において非常に価値があります。従業員がタスクに積極的に作業した時間（処理時間）と、タスクがキューで待機していた時間（待機時間）を区別することで、「平均コンプライアンスレビュー時間」のような詳細な指標の作成を可能にします。この詳細なレベルは、ボトルネックを正確に特定し、リソース容量またはプロセス引き継ぎのいずれかに改善努力を集中させるために不可欠です。

アクティビティの処理時間を正確に計算することを可能にし、実際の作業時間と待機時間の区別を助けます。

イベントログまたはトランザクションテーブルで開始時刻とともに見つかります。「終了時刻」、「完了日」、または「更新日」と表示される場合があります。

ユーザーIDは、プロセス内で特定のアクティビティを実行した人物またはシステムボットを識別します。これはコンプライアンスオフィサー、データ入力担当者、または自動化されたリスクスコアリングエンジンである可能性があります。ユーザー識別の一貫性は、正確なリソース分析のために重要です。

この属性は、プロセスの人間中心の視点を提供します。ワークロードの配分、個人およびチームのパフォーマンス、そしてリソース配分を分析するために不可欠です。プロセスマップをユーザーIDで絞り込むことで、マネージャーは異なる従業員がどのようにタスクを処理しているかを理解し、トレーニング機会を特定し、作業がバランスされていることを確認できます。また、異なる人々の間で作業がどのように引き継ぎされているかを明らかにするコラボレーション分析にも役立ちます。

ワークロード、リソースのパフォーマンス、およびコラボレーションパターンの分析を可能にし、より良いリソース管理とトレーニングを実現します。

システム監査証跡やトランザクションログで利用可能であり、多くの場合、レコードを作成または最終更新したユーザーと関連付けられています。

KYCプロセスにおいて、リスクレベルは顧客の業界、地理、取引パターンなどの要因に基づいて分類する重要な成果です。この分類により、申請に対する審査やデューデリジェンスの厳格さが決まります。

プロセスマイニングでは、この属性はコンフォーマンス分析やバリアント分析のための強力なデータとなります。高リスク顧客に対するプロセスは、設計上、低リスク顧客のものとは異なり、より厳格であるべきです。異なるリスクレベルの実際のプロセスフローを期待される手順と比較することで、組織は社内ポリシーや規制へのコンプライアンスをチェックできます。「高リスク顧客は常に強化されたデューデリジェンスを受けているか？」「低リスク顧客に時間をかけすぎていないか？」といった疑問に答えるのに役立ちます。

コンプライアンスとリスク管理に不可欠であり、デューデリジェンスプロセスが異なるリスクプロファイルに対して適切に異なるかどうかを分析できます。

リスクエンジンによって計算されるか、コンプライアンス担当者によって手動で割り当てられます。主要な顧客または申請記録に保存されます。

「申請ステータス」は、申請の最終的な処理結果、例えば「承認済み」、「却下済み」、「取り下げ済み」を示します。これはプロセスのビジネス成果を表し、パフォーマンス測定のための重要な要素です。\n\nこの属性は、成果ベースの分析に不可欠です。成功した結果につながるプロセス経路と、却下につながるプロセス経路を比較できます。アナリストはこれを使用して、高い却下率に関連するプロセスパターンを特定し、「申請却下率」のようなKPIを計算し、申請者がどこで離脱するかを確認するための「オンボーディングファネル分析」を構築できます。申請が失敗する理由を理解することは、成功率を高めるためにプロセスを改善するための最初のステップです。

各ケースのビジネス成果を定義し、申請が却下される理由や承認率を改善する方法の分析を可能にします。

通常、主要なケースまたは申請テーブルにあり、記録の最終状態を示します。

顧客タイプは、申請者を「個人」、「法人」、「信託」、「非営利団体」などの明確なカテゴリに分類します。異なる顧客タイプは、しばしば大きく異なるオンボーディング要件とプロセスの複雑性を持ちます。\n\nこれは分析のための主要なセグメンテーション属性です。プロセス地図とKPIを顧客タイプでフィルタリングすることで、組織は significantなバリエーションを発見できます。例えば、法人顧客のオンボーディングは、受益者所有権の確認など、個人には不要なより複雑なステップを含むのが一般的です。この分析により、各プロセスバリアントがその特定のセグメントに対して可能な限り効率的であることを保証し、プロセス改善の調整に役立ちます。

プロセスのセグメンテーションを可能にし、異なるタイプの顧客のオンボーディングジャーニーを比較・最適化します。

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

サービスレベルアグリーメント（SLA）目標日は、顧客のオンボーディングプロセスを完了するための期限です。この日付は、しばしば社内ポリシーや契約上の義務によって決定され、適時性を測るための基準となります。

この属性は、「SLAパフォーマンスモニタリング」ダッシュボードの基盤となります。申請の実際の完了日をSLA目標日と比較することで、「SLA遵守率」を算出できます。SLAを遵守できなかったケースを分析することで、遅延の原因となっている特定の活動や部署を特定できます。これにより、ワークキューのプロアクティブな管理やリソース配分が可能となり、SLA違反を最小限に抑え、顧客満足度を向上させることができます。

パフォーマンスベンチマークを提供し、SLA遵守率の測定と遅延のリスクがあるケースの特定を可能にします。

ケースが作成された際に、申請タイプまたはその他の基準に基づいて、主要な申請記録に計算され保存されることがよくあります。

申請のステータスが「却下」の場合、却下理由は、「書類不備」「高リスクプロファイル」「制裁対象一致」などの具体的な原因を提供します。この属性は、失敗したプロセスに決定的なコンテキストを追加します。

却下理由の分析は、「申請却下分析」ダッシュボードの基本です。これは、ビジネスが根本原因分析を実行し、オンボーディングプロセスにおける最も一般的な失敗箇所を理解するのに役立ちます。これらの理由を分類・定量化することで、組織は改善を優先できます。例えば、「書類不備」が主要な理由である場合、企業は顧客への指示を明確にしたり、書類提出ポータルを改善したりすることに注力するかもしれません。

失敗した申請の根本原因を提供し、却下率を低減し、顧客体験を向上させるためのターゲットを絞った改善を可能にします。

通常、主要な申請またはケーステーブルに保存され、ステータスが「却下」に設定されたときにデータが入力されることがよくあります。

この属性は、「Webポータル」「モバイルアプリ」「店舗」など、顧客が申請を提出した方法を識別します。異なるチャネルでは、データ取得プロセスや顧客エクスペリエンスが異なる場合があります。

チャネル別にプロセスを分析することで、各顧客タッチポイントのパフォーマンスと効率を評価できます。「モバイルアプリケーションはウェブアプリケーションよりも速く処理されるか？」や「店舗で提出された申請の手戻り率は高いか？」といった疑問に答えることができます。これらの洞察は、すべてのチャネルにおけるカスタマージャーニーを最適化し、リソースを効果的に配分するために貴重です。

ウェブ、モバイル、対面など、異なる提出チャネル間でのプロセス効率と顧客体験の比較を可能にします。

通常、申請が最初に作成されたプロセスの冒頭で記録されます。

このブール属性は、ソフトウェアまたはボットによって実行されるタスクと、人間のユーザーによって実行されるタスクを区別します。自動化された活動には、初期データ検証、制裁スクリーニング、または標準化された通信の送信などが含まれる場合があります。

この属性の分析は、自動化イニシアチブの有効性を評価するために不可欠です。自動化されたステップと手動ステップの速度と結果を比較することで、ビジネスはさらなる自動化の機会を特定し、コストとサイクルタイムを削減できます。また、自動化システムのパフォーマンスを監視し、エンドツーエンドのプロセス内で期待どおりに機能していることを確認するのにも役立ちます。

プロセスにおける自動化の影響と効率を測定するのに役立ち、さらなるロボット化または体系的な改善の機会を特定します。

イベントログ内の専用フィールドであるか、ユーザーIDに基づいて派生されることがあります（例：IDが「SYSTEM」や「BOT」の場合）。

顧客IDは、複数のインタラクションや申請にわたって保持される顧客の一意の識別子です。顧客申請IDが単一のオンボーディングジャーニーを追跡するのに対し、顧客IDは同じ顧客の複数のオンボーディング試行やその他のプロセスをリンクさせることができます。\n\nこの属性は、単一のケースを超えた顧客中心の分析を提供します。リピート申請者の理解、顧客との長期的な関係の分析、「ローン申請」や「口座維持」のような他のプロセスへのオンボーディングプロセスの接続に役立ちます。単一プロセスのビューには必須ではありませんが、より複雑なオブジェクト指向のプロセスマイニングのためのデータを豊かにします。

同一顧客に関連する複数のオンボーディング試行や異なるプロセスをリンクさせ、顧客中心の視点での分析を可能にします。

通常、中央の顧客マスターデータシステムにあり、申請記録にリンクされています。

顧客国は、申請者の地理的位置を特定します。これは、KYCプロセスにおいて非常に重要な情報であり、規制やリスク要因が国によって大きく異なる可能性があるためです。\n\n地理的分析は、もう一つの重要な洞察層を提供します。オンボーディングプロセスは、国固有の法的要件に基づいて異なる場合があります。顧客国でフィルタリングすることで、企業はこれらの管轄区域固有のバリアントが正しく遵守されていることを確認できます。また、高リスク国からの申請のサイクルタイムが長くなるなど、パフォーマンスの違いを明らかにすることもできます。これは強化されたデューデリジェンス要件のために予期される可能性があります。

地域に基づいたプロセスバリエーションとパフォーマンスの分析を可能にし、現地の規制へのコンプライアンス確保に不可欠です。

申請プロセス中に顧客から取得され、顧客記録または申請記録に保存されます。