あなたのKYC顧客オンボーディングデータテンプレート
あなたのKYC顧客オンボーディングデータテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- データ抽出のガイダンス
KYC顧客オンボーディング属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | オンボーディングプロセス内の特定の時点で発生したビジネスイベントまたはタスクの名前。 | ||
| 説明 Activity Name(活動名)は、「初期スクリーニング実施済み」や「申請承認済み」など、顧客オンボーディングジャーニーにおける単一のステップまたはマイルストーンを記述します。この活動のシーケンスがプロセスマップの基礎となります。 この属性を分析することで、プロセスフローの可視化、一般的および代替パスの特定、各ステップの頻度の測定が可能になります。どのようなアクションがどのような順序で実行されているかを理解するために不可欠です。 その重要性 この属性はプロセスのステップを定義し、プロセスマップの作成やプロセスフローとバリエーションの分析を可能にします。 取得元 この情報は通常、Fenergoのワークフローまたは監査ログテーブルに、ケースステートの遷移やタスク完了に関連付けられて見つかります。 例 データと書類を要求済みコンプライアンス審査開始申請承認済み | |||
| 開始時刻 EventStartTime | 活動またはイベントが正式に開始されたことを示すタイムスタンプ。 | ||
| 説明 この属性は、特定の活動が開始された正確な日時を記録します。プロセスフローを再構築するために必要な時系列順序を提供し、すべての時間ベースの分析に不可欠です。 プロセスマイニングでは、開始時刻は活動の期間、活動間の待機時間、およびケース全体のサイクルタイムを計算するために使用されます。これはイベントログの時間的な基盤を形成し、パフォーマンスとボトルネック分析にとって極めて重要です。 その重要性 このタイムスタンプは、イベントを時系列順に並べ、サイクルタイムや期間などのすべての時間ベースのメトリックを計算するために不可欠です。 取得元 Fenergoの監査証跡、イベントログ、またはワークフロー履歴テーブルにあり、しばしば「タイムスタンプ」、「開始日」、または「作成日」とラベル付けされています。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 顧客申請 CustomerApplication | 単一の顧客オンボーディングジャーニーの一意の識別子であり、主要なケース識別子として機能します。 | ||
| 説明 Customer Application(顧客申請)は、単一の顧客のKYCオンボーディングプロセスに関連するすべての活動とイベントをグループ化する中心的な識別子です。これにより、最初の提出から最終的な解決(承認、却下、または終了)までの申請のエンドツーエンドの追跡が可能になります。 プロセスマイニングにおいて、この属性は各申請の完全なジャーニーを再構築するための基本的なものです。これにより、申請ごとのプロセスフロー、サイクルタイム、バリエーション、およびボトルネックの分析が可能になり、個々のケースがどのように処理されているかを明確に把握できます。 その重要性 これは、関連するすべてのイベントを接続する不可欠なケースIDであり、エンドツーエンドの顧客オンボーディングプロセスを分析することを可能にします。 取得元 これは通常、Fenergoのコアケース管理またはクライアントライフサイクル管理エンティティにおける主キーです。 例 APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| ソースシステム SourceSystem | `データ`が抽出された記録システム。 | ||
| 説明 この属性は、イベントデータの発生元システムを識別します。このプロセスでは常にFenergoですが、結合されたデータセットではデータソースの区別を助けます。 分析における主な用途は、特定のシステムからのデータをフィルタリングしたり、データの出所を検証したりすることです。複数のシステムからのデータが統合され、全体的なプロセスビューが求められる環境で、明確性を確保します。 その重要性 データの出所を特定します。これはデータガバナンス、検証、そして分析が正しいソースに基づいていることを保証するために不可欠です。 取得元 これは通常、データ抽出プロセス中に、レコードの出所を示すために追加される静的な値です。 例 FenergoFenergo CLM | |||
| 最終データ更新 LastDataUpdate | この`プロセス`の`データ`が最後に更新または抽出された日時を示す`タイムスタンプ`。 | ||
| 説明 この属性は、最も新しいデータ更新の日時を記録します。分析されているデータの鮮度に関するコンテキストを提供し、洞察の適時性を理解するために重要です。 ダッシュボードやレポートでは、この情報はユーザーにデータの最新性について通知するために使用されます。分析がリアルタイムの運用を反映しているのか、それとも過去のスナップショットであるのかについて、期待値を管理するのに役立ちます。 その重要性 データの鮮度に関する重要なコンテキストを提供し、ユーザーがプロセスの分析がどれだけ最新であるかを理解できるようにします。 取得元 この値は、データ抽出およびロード(ETL)プロセス中にデータセットに生成され、スタンプされます。 例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| `ユーザー部署` UserDepartment | 開始ユーザーが所属する部署またはビジネスユニット。 | ||
| 説明 この属性は、「コンプライアンス」、「オンボーディング業務」、「営業」など、活動を実行したユーザーの組織的コンテキストを提供します。多くの場合、ユーザープロファイル情報から派生します。 このディメンションは、異なる部門間のプロセス引き渡しを分析し、部門横断的なボトルネックを特定するために重要です。チームまたは部門レベルでの作業の集計を可能にすることで、「スタッフ活動分布」ダッシュボードを直接サポートします。 その重要性 部門ごとのプロセスパフォーマンス分析を可能にし、部門間の引き継ぎ、遅延、ワークロードの分散を明確にします。 取得元 これは、「InitiatingUser」IDを使用して別のユーザーまたは人事マスターデータテーブルから結合する必要がある場合があります。Fenergoは、これをユーザーのプロファイルの一部として保存することもあります。 例 Compliance顧客オンボーディング品質保証 | |||
| SLA目標日 SlaTargetDate | 顧客オンボーディングケースが完了する予定日。 | ||
| 説明 SLA Target Date(SLA目標日)は、顧客申請のオンボーディングプロセス全体を完了するための合意された期限を表します。これは、実際のパフォーマンスを測定するための重要なベンチマークです。 この属性は、「SLAコンプライアンス監視」ダッシュボードと「SLA達成率」KPIの計算に不可欠です。SLA違反のリスクがあるケースをプロアクティブに管理し、作業の優先順位付けに役立ちます。 その重要性 SLA遵守の監視と期限切れケースの優先順位付けに不可欠な、目標完了日を定義します。 取得元 この日付は、多くの場合、申請提出日とFenergoのSLA管理モジュール内で設定されたビジネスルールに基づいて計算されます。 例 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| リスクスコア RiskScore | 顧客の計算されたリスクレベルを表す数値スコアです。 | ||
| 説明 Risk Score(リスクスコア)は、管轄区域、業界、スクリーニング結果など、さまざまな要因に基づいて計算される顧客に関連する潜在的リスクの定量的尺度です。Fenergoのルールエンジンが通常このスコアを計算します。 この属性により、リスクレベルとプロセス動作の相関関係を分析できます。例えば、高リスクの顧客がより長いサイクルタイムを経験したり、より多くの手動介入を必要としたりするかどうかを分析で明らかにでき、「リスク&コンプライアンスレビュー深掘り」ダッシュボードに役立ちます。 その重要性 顧客のリスクを定量化し、リスクレベルがプロセス期間、手戻り、結果にどのように影響するかを分析できるようにします。 取得元 これはFenergoのクライアントリスク評価モジュールの主要な出力です。ケースまたはクライアントエンティティに保存されます。 例 154585 | |||
| 申請ステータス ApplicationStatus | 顧客申請の現在または最終的な結果。 | ||
| 説明 この属性は、プロセスの終了時における申請の処理結果、または進行中の場合は現在の状態を示します。一般的な値には、「承認済み」、「却下済み」、または「進行中」が含まれます。 これは結果分析にとって重要なディメンションです。最終結果に基づいてプロセスフローをフィルタリングおよび比較することを可能にし、「申請手戻りおよび却下」ダッシュボードや申請却下率などのKPI計算に不可欠です。 その重要性 ケースの結末を定義し、承認された申請と却下された申請の経路を比較し、成功率を理解するための強力な分析を可能にします。 取得元 これは通常、Fenergoのケース管理システムにおけるケースエンティティに記録される最終ステータスです。 例 承認済み却下コンプライアンス待ちクローズ | |||
| 終了日時 EventEndTime | アクティビティまたはイベントが完了した時点を示すタイムスタンプ。 | ||
| 説明 この属性は、特定の活動が完了した正確な日時を記録します。これは開始時刻を補完し、タスクのアクティブな期間を定義します。 プロセスマイニングでは、終了時刻は開始時刻とともに使用され、各活動の処理時間を計算します。これは、プロセス内のどのステップが最も時間を消費しているかを特定し、リソース効率を分析するために不可欠です。 その重要性 アクティビティの処理時間の計算を可能にし、実行時間の長いタスクやパフォーマンスのボトルネックを特定するための基本的な情報となります。 取得元 Fenergoの監査証跡またはワークフロー履歴テーブルにあり、しばしば「EndDate」、「CompletionDate」とラベル付けされているか、後続イベントの開始時間から派生します。 例 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| 開始ユーザー InitiatingUser | そのアクティビティを実行した担当者のユーザーIDまたは氏名を示します。 | ||
| 説明 この属性は、特定のタスクまたはイベントを実行する責任のある特定の従業員またはシステムユーザーを識別します。一意のユーザーID、名前、または役割である場合があります。 ユーザーによる分析は、ワークロードの分散、個人のパフォーマンス、およびトレーニングニーズの特定を理解するのに役立ちます。これは「スタッフ活動分布」ダッシュボードにとって重要であり、特定の個人やチームによって実行された活動をドリルダウンするために不可欠です。 その重要性 どのユーザーがアクションを実行したかを追跡し、ワークロードの分散、チームのパフォーマンス、リソースの割り当ての分析を可能にします。 取得元 この情報は通常、Fenergoの監査ログまたはタスク履歴テーブルにイベント詳細とともに保存され、多くの場合「UserID」、「UserName」、または「ModifiedBy」として記録されます。 例 j.doea.smithSYSTEM | |||
| SLA準拠 IsSlaCompliant | ケースがSLA目標日内に完了したかどうかを示すブール値フラグです。 | ||
| 説明 この属性は、完了したケースのSLAパフォーマンスを示すバイナリインジケータです。最終的なクローズ活動のタイムスタンプがSlaTargetDate以前である場合は「true」に、それ以外の場合は「false」に設定されます。 この計算フィールドは、SLAの監視とレポート作成を簡素化します。全体の「SLA達成率」KPIを簡単に集計し、準拠ケースと非準拠ケースのプロセス特性を分析するためのフィルタリングを可能にします。 その重要性 SLAパフォーマンスを直接測定し、SLA遵守率KPIの簡単な計算と、非準拠ケースのフィルタリングを可能にします。 取得元 これは、最終ケース活動(例:「申請承認済み」、「申請却下済み」)のタイムスタンプとSlaTargetDateを比較することで導出されます。 例 truefalse | |||
| ケース所有者 CaseOwner | アプリケーションのライフサイクルを通じて管理する主要なユーザーまたはチーム。 | ||
| 説明 Case Owner(ケースオーナー)は、オンボーディングケースの主要な責任を割り当てられた個人またはグループです。通常、この担当者はケースの期限内での完了と成功に責任を負います。 この属性は、ケースマネージャーレベルでのワークロードとパフォーマンスを分析するのに役立ちます。特定のケースオーナーがより長いサイクルタイムや高い却下率を持っているかどうかを確認するために使用でき、トレーニングの必要性やリソースの不均衡を示している可能性があります。 その重要性 ケースの担当者またはチームを特定し、ケースマネージャーのパフォーマンス分析を可能にします。 取得元 これは通常、Fenergoの主要なケースエンティティ上の特定のフィールドであり、ケースの割り当てを示します。 例 s.jonesオンボーディングチームAm.chen | |||
| 処理時間 ProcessingTime | アクティビティに実作業として費やした時間。 | ||
| 説明 処理時間(アクティブタイムとも呼ばれる)は、単一のアクティビティの開始タイムスタンプと終了タイムスタンプの間の計算された期間です。これは、リソースがタスクに積極的に従事していた時間を表します。 この指標はパフォーマンス分析の基礎となります。ボトルネック分析ダッシュボードで使用され、どの特定のアクティビティが最も時間を消費しているかを正確に特定し、最大の効果が得られる改善努力に焦点を当てるのに役立ちます。 その重要性 この計算メトリックは、各活動のアクティブな作業時間を測定し、パフォーマンスのボトルネックを特定するのに不可欠です。 取得元 「EventEndTime」と「EventStartTime」の差(EndTime - StartTime)として計算されます。 例 86400000360000018000000 | |||
| 却下理由 RejectionReason | 申請が却下された理由を説明するコードまたは説明文です。 | ||
| 説明 申請の最終ステータスが「却下」の場合、この属性は具体的な理由を提供します。例としては、「バックグラウンドチェック失敗」、「書類不備」、または「高リスクプロファイル」などが挙げられます。 これは、失敗した申請の根本原因分析にとって不可欠な属性です。「申請手戻りおよび却下」ダッシュボードを直接サポートし、失敗を分類することで、ビジネスが共通の問題を特定し、初回パス率を向上させるための是正措置を実施するのに役立ちます。 その重要性 申請が失敗する理由に関する重要な洞察を提供し、却下率を削減するための根本原因分析を可能にします。 取得元 通常、Fenergoのケースワークフローにおける最終的な却下ステータスに関連付けられた理由コードまたは備考フィールドに見つかります。 例 制裁対象一致無効な書類ポリシー違反顧客が取り下げた | |||
| 国 Country | 顧客申請の居住国または管轄国。 | ||
| 説明 この属性は、顧客に関連付けられた国を指定します。これは多くの場合、オンボーディングプロセスに適用される特定の規制ルールとリスク要因を決定します。 国別にプロセスを分析することで、サイクルタイム、リスクレベル、プロセス複雑性の管轄区域ごとの比較が可能になります。これにより、地域差が運用パフォーマンスにどのように影響するかを理解し、現地の規制へのコンプライアンスを確保するのに役立ちます。 その重要性 地理に基づいたプロセスセグメンテーションを可能にし、規制の影響と地域ごとのパフォーマンスを分析するための鍵となります。 取得元 この情報は、申請プロセス中に取得され、Fenergoのクライアントエンティティに保存される顧客コアデータの一部です。 例 米国GBRSGPDEU | |||
| 手戻り IsRework | アクティビティが手戻りループの一部であるかを示すブール値フラグです。 | ||
| 説明 この属性は、「コンプライアンスレビュー」が既に開始された後に「書類レビュー」に戻るなど、プロセスにおける後戻りを表す活動、または「追加情報要請」の発生を特定します。 手戻りの特定は、プロセスの非効率性や摩擦を理解するために不可欠です。このフラグにより、「手戻りループ率」KPIを直接計算でき、プロセスフローにおける無駄な反復ステップの影響を可視化し、定量化するのに役立ちます。 その重要性 プロセス内の非効率な手戻りループを明らかにし、無駄を定量化し、初回正確率を高めるための改善領域を特定するのに役立ちます。 取得元 このフラグは、活動のシーケンスを分析するプロセスマイニング技術を使用して導出されます。例えば、「活動A」の後に「活動B」が続き、その後同じケースで再び「活動A」が現れる場合、2番目の「活動A」は手戻りです。 例 truefalse | |||
| 申請チャネル ApplicationChannel | 顧客の申請が提出されたチャネル。 | ||
| 説明 この属性は、オンラインポータル、支店、またはリレーションシップマネージャーを介してなど、申請の提出元を識別します。提出元は、データ品質と処理要件に影響を与える可能性があります。 このディメンションは、「申請元と種類別の効率性」ダッシュボードで使用され、異なるチャネルのパフォーマンスを比較します。これにより、企業はどのチャネルが最も効率的であるか、そしてどのチャネルがプロセス最適化を必要とするかを理解するのに役立ちます。 その重要性 申請の出所を特定し、チャネルの効率性、コスト、顧客体験の分析を可能にします。 取得元 この情報は、Fenergo内の初期データ入力フォームで取得されるか、または上流システムから渡される場合があります。 例 オンラインポータル拠点リレーションシップマネージャーモバイルアプリ | |||
| 自動化 IsAutomated | アクティビティが人間ではなくシステムによって実行されたかどうかを示すブール値フラグです。 | ||
| 説明 この属性は、システムによって自動的に実行されるタスク(例:初期スクリーニング、システムチェック)と、ユーザーによって手動で実行されるタスクを区別します。これは多くの場合、実行ユーザーがシステムアカウントかサービスアカウントかをチェックすることで決定されます。 このフラグの分析は、プロセスにおける自動化のレベルを理解するために非常に重要です。自動化が効率、コスト、速度に与える影響を定量化し、さらなる自動化の機会を特定するのに役立ちます。 その重要性 人間による活動とシステムによる活動を区別することで、自動化分析とリソースコストの理解に不可欠です。 取得元 これは通常、「InitiatingUser」フィールドに基づいて導出されます。既知のシステムユーザーIDのリストを使用して、このフラグをtrueに設定します。 例 truefalse | |||
| 追加情報要求回数 AdditionalInfoRequestCount | 申請に対して追加情報が要求された合計回数。 | ||
| 説明 このメトリックは、各ケースにおける「追加情報要求」活動の発生回数をカウントします。カウントが高いほど、より多くのやり取りが発生し、プロセスを遅延させ、劣悪な顧客体験につながる可能性があります。 この属性は、「追加情報要求のあるケース」KPIを直接サポートします。過剰な要求のある申請を特定するために使用され、初期データ収集の問題や複雑なケース要件を示す可能性があります。これを分析することで、情報収集の合理化に役立ちます。 その重要性 初期情報の不備によって生じる顧客の負担やプロセス遅延を定量化し、データ収集ステップの改善を支援します。 取得元 これは、「CustomerApplication」IDごとの「追加情報要求」イベントの数をカウントして導出される計算メトリックです。 例 013 | |||
| 顧客ID CustomerId | オンボーディングされる顧客または法人を表す固有の識別子です。 | ||
| 説明 Customer ID(顧客ID)は、マスターデータシステムにおけるクライアントエンティティの一意の参照です。申請番号がプロセスのケースIDである一方、顧客IDはオンボーディング活動を特定のクライアントにリンクさせます。 この属性は、単一の顧客のオンボーディング履歴を分析するのに役立ちます。例えば、顧客が時間の経過とともに複数のオンボーディングプロセスを経験している場合などです。また、プロセスデータと他の顧客関連データを結合して、より包括的なビジネスビューを実現することも可能です。 その重要性 オンボーディングプロセスを固有の顧客エンティティにリンクさせ、顧客中心の分析とデータエンリッチメントを可能にします。 取得元 このIDは、Fenergo内のクライアントまたは法人エンティティレコードに保存され、オンボーディングケースに関連付けられています。 例 CUST-98765CUST-98766CUST-98767 | |||
| 顧客タイプ CustomerType | オンボーディングされる顧客の分類。例:個人、法人、信託。 | ||
| 説明 この属性は、顧客を法的構造や金融機関との関係に基づいて異なるカテゴリに分類します。顧客タイプが異なると、オンボーディングパスも異なり、複雑さやデューデリジェンスの要件も様々です。 顧客タイプ別にプロセスを分析することで、セグメント間のパフォーマンスの違いを特定できます。これは「申請元と種類別の効率性」ダッシュボードにとって重要であり、サイクルタイムと承認率を比較して、個別のプロセス改善につながります。 その重要性 異なる顧客セグメント間でのプロセスパフォーマンスの比較を可能にします。これは、複雑さやSLAが異なることが多いため重要です。 取得元 この情報は通常、Fenergo内の顧客またはクライアントエンティティに保存され、申請ケースにリンクされます。 例 個人法人信託提携 | |||
KYC顧客オンボーディングアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| コンプライアンス審査完了 | コンプライアンス部門による正式な承認を示し、すべての規制要件が満たされたことを意味します。これはタスク完了、または「コンプライアンス承認済み」へのステータス変更から推測されます。 | ||
| その重要性 主要なマイルストーンとして、このアクティビティの完了は全体のサイクルタイムにとって非常に重要です。「平均コンプライアンス審査時間」を測定し、コンプライアンス機能内のボトルネックを特定するための終点となります。 取得元 Fenergoワークフロー内の「コンプライアンス審査」タスクの完了タイムスタンプ、またはケース履歴内のステータス更新イベントから推測されます。 取得 コンプライアンスレビュータスクの完了またはステータス更新のタイムスタンプを使用します。 イベントタイプ inferred | |||
| コンプライアンス審査開始 | この活動は、コンプライアンス部門によるレビューの開始を示します。これは重要でしばしば長期間にわたる段階です。ケースがコンプライアンスワークキューに割り当てられたり、そのステータスが「コンプライアンスレビュー保留中」に変わったりしたときに推測されます。 | ||
| その重要性 この活動は、「平均コンプライアンスレビュー時間」KPIを測定するための出発点です。コンプライアンスチームが実際に作業を開始するまでにケースがどれだけ待機するかを特定するのに役立ちます。 取得元 Fenergoケース監査ログから、「コンプライアンス審査中」へのステータス変更、またはケースがコンプライアンス担当者やチームに割り当てられた際のタイムスタンプをキャプチャして推測されます。 取得 「コンプライアンス審査中」へのステータス変更、または割り当てイベントのタイムスタンプを特定します。 イベントタイプ inferred | |||
| リスク評価完了 | 顧客にさまざまな要因に基づいてリスク評価が割り当てられる、内部リスク分類プロセスの完了を表します。これはステータス変更またはリスク評価フィールドへの入力から推測されます。 | ||
| その重要性 これは、その後のワークフローパスを決定することが多い重要な意思決定マイルストーンです。その期間を分析することで、重要なコンプライアンスステップを合理化し、リスク評価の一貫性を確保するのに役立ちます。 取得元 ケース履歴ログから、ケースが「リスク評価済み」のようなステータスに移行した時、または最終的な「顧客リスク評価」フィールドに値が入力された時を特定して推測されます。 取得 リスク評価フィールドが確定された、または関連するステータスが設定されたタイムスタンプを使用します。 イベントタイプ inferred | |||
| 書類審査完了 | 提出されたすべての顧客書類の真偽と正確性を検証する手動または自動プロセスの完了を示します。このイベントは通常、ワークフロータスクの完了またはFenergoでのステータス変更から推測されます。 | ||
| その重要性 これは多くの遅延が発生する重要なマイルストーンです。この活動の期間と結果を分析することで、書類処理におけるボトルネックを特定し、「初回パス率」などのKPIをサポートするのに役立ちます。 取得元 ケースワークフローにおける「書類確認」タスクの完了タイムスタンプ、またはケース履歴ログにおける「書類承認済み」へのステータス更新から推測されます。 取得 書類レビュータスクの完了タイムスタンプまたは関連するステータス変更を使用します。 イベントタイプ inferred | |||
| 案件クローズ | これは最終活動であり、オンボーディングケースがFenergoで事務的にクローズされ、それ以上の措置は不要であることを示します。承認済みおよび却下済みの両方の申請に適用され、最終的な「クローズ済み」ステータスから推測されます。 | ||
| その重要性 この活動は、プロセス全体の決定的な終点として機能します。結果に関係なく、すべてのケースの正確なサイクルタイム計算を保証し、プロセスが完了したことを確認します。 取得元 Fenergoケース監査ログから、ケースステータスが「クローズ済み」、「完了済み」、またはその他の最終状態に設定された際のタイムスタンプを特定して推測されます。 取得 最終ステータスの「クローズ済み」または「完了済み」への変更タイムスタンプを特定します。 イベントタイプ inferred | |||
| 案件作成 | この活動は、Fenergoで新規顧客申請が正式に作成された際にKYCオンボーディングプロセスの開始を示します。通常、ケースレコードが最初に保存されたときに特定のタイムスタンプとともに記録される明示的なイベントです。 | ||
| その重要性 開始イベントとして、このアクティビティは全体のオンボーディングサイクルタイムの計算とスループット分析に不可欠です。これは、その後のすべてのプロセス測定とSLA追跡のベースラインを提供します。 取得元 これは通常、Fenergoの主要なケースエンティティの作成タイムスタンプから取得され、多くの場合、クライアントオンボーディングケースまたはワークフローに関連するテーブルで見つかります。 取得 オンボーディングケースレコードの作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| 申請却下済み | この活動は、顧客の申請を却下するという最終決定を表す終端イベントです。ケースステータスが最終的な「却下」または「拒否」状態に変化することから推測されます。 | ||
| その重要性 主要なプロセス終点として、このアクティビティは「申請却下率」の計算と失敗理由の分析に不可欠です。これにより、一般的な却下ポイントを特定し、申請の品質を向上させるのに役立ちます。 取得元 ケース監査ログから、最終ステータスが「却下済み」に変わった際のタイムスタンプをキャプチャして推測されます。却下理由は関連フィールドに保存されていることが多いです。 取得 最終ステータスの「却下済み」への変更タイムスタンプを特定します。 イベントタイプ inferred | |||
| 申請承認済み | この活動は、顧客のオンボーディング申請を承認するという最終決定を表します。ケースステータスが最終的な「承認済み」または「オンボーディング承認済み」状態に変化することから推測されます。 | ||
| その重要性 この重要なマイルストーンは、最終的なアカウントアクティベーションステップの前の成功した結果を示します。承認率を計算し、正常にオンボーディングされた顧客の特性を分析するために不可欠です。 取得元 ケース履歴または監査ログから、「承認済み」または同様の最終的な肯定的なステータスへの変更のタイムスタンプを見つけることで推測されます。 取得 最終ステータスの「承認済み」への変更タイムスタンプを特定します。 イベントタイプ inferred | |||
| アカウント有効化済み | 承認後、顧客のアカウントがコアバンキングまたは関連する下流システムで正常に作成・有効化されたことを示します。これは、Fenergoでの承認後の最終ステータス更新から推測される場合があります。 | ||
| その重要性 この活動は、オンボーディングプロセスから顧客のアクティブステータスへの引き渡しが成功したことを確認します。承認からアクティベーションまでの時間を測定することで、運用設定の遅延が明らかになることがあります。 取得元 これは、「アカウント有効」や「オンボーディング完了」などのケースステータスから推測できます。また、ダウンストリームシステムとの連携によってログに記録された明示的なイベントである可能性もあります。 取得 承認後のステータス変更、または統合成功ログイベントを探します。 イベントタイプ inferred | |||
| データと書類を要求済み | このイベントは、システムまたはオンボーディングエージェントが顧客から必要な情報と書類を正式に要求したことを示します。通常、標準化されたコミュニケーションテンプレートが送信された際に明示的なイベントとしてキャプチャされます。 | ||
| その重要性 この活動は、顧客に依存するフェーズの開始を示します。この時点から書類が受領されるまでの時間を測定することは、顧客ジャーニーを分析し、コミュニケーションの遅延を特定するために重要です。 取得元 顧客とのコミュニケーションに関連するイベントログ、または「書類請求」のタスク完了ログから取得されます。「顧客情報待ち」へのステータス変更から推測される場合もあります。 取得 顧客コミュニケーションまたはタスク完了のログイベントを探します。 イベントタイプ explicit | |||
| バックグラウンドチェック開始済み | この活動は、外部のバックグラウンド、AML、または信用調査がトリガーされる時点を示します。これは多くの場合、サードパーティサービスとの連携が呼び出されたときに記録される明示的なイベントです。 | ||
| その重要性 これらのチェックの開始と完了を追跡することは、外部依存関係によって引き起こされる遅延を理解するために不可欠です。これにより、内部プロセス時間と外部待機時間を分離するのに役立ちます。 取得元 通常、外部スクリーニングプロバイダーへのAPI呼び出しを記録するシステムログ、またはFenergoケース内で特定の「バックグラウンドチェック」タスクが作成された際に取得されます。 取得 外部サービス連携のログ、または「スクリーニング」タスクの作成ログを探します。 イベントタイプ explicit | |||
| 初期スクリーニング実施済み | 基本的なデータ検証や制裁リストスクリーニングなど、事前の自動または手動チェックの完了を表します。これは多くの場合、Fenergoのケースワークフロー内でのステータス変更、例えば「新規」から「スクリーニング完了」への移行から推測されます。 | ||
| その重要性 この初期のマイルストーンを追跡することで、事前資格認定段階における初期のデータ品質問題やボトルネックを特定するのに役立ちます。これにより、最初の自動化されたフェーズを、より集中的な手動レビュープロセスから分離します。 取得元 ケース履歴または監査ログから、ケースステータスが「スクリーニング完了」を示す状態、例えば「スクリーニング通過」や「書類待ち」に移行した際のタイムスタンプを特定して推測されます。 取得 ケース履歴から「スクリーニング完了」またはそれに類するステータス変更を特定します。 イベントタイプ inferred | |||
| 書類受領 | この活動は、顧客が必要な書類をアップロードまたは提出し、現在Fenergoでレビュー可能になっていることを示します。これは通常、ケースステータスが「書類受領済み」または「レビュー保留中」に更新されたときに推測されます。 | ||
| その重要性 これは顧客の待機期間の終了と内部レビューサイクルの開始を示します。顧客の応答時間と内部処理キュー時間を測定するために不可欠です。 取得元 ケース監査証跡から、「書類受領済み」または同様のステータスへの変更のタイムスタンプを記録して推測されます。書類アップロードイベントに関連付けられる場合もあります。 取得 「書類受領済み」または「審査準備完了」へのステータス変更のタイムスタンプを特定します。 イベントタイプ inferred | |||
| 追加情報の依頼 | オンボーディングチームが顧客に説明や不足書類の確認のため再度連絡を取る手戻りのループを表します。これは通常、顧客へ連絡が送信された際に記録される明示的なイベントです。 | ||
| その重要性 この活動は、プロセスの非効率性と劣悪な顧客体験の主要な指標です。その頻度を追跡することで、手戻りの根本原因を特定し、「手戻りループ率」KPIをサポートするのに役立ちます。 取得元 顧客コミュニケーションのイベントログ、または「追加情報待ち」へのステータス変更から取得されます。前者は正確なリクエストの瞬間を捉える上でより精密です。 取得 記録された顧客コミュニケーションイベントまたは「顧客返答待ち」へのステータス変更を探します。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- レポートモジュールにアクセスする: Fenergoアプリケーションに、Reporting & Analyticsモジュールへの十分な権限を持つユーザーアカウントでログインします。通常、メインアプリケーションメニューにあるモジュールに移動します。
- 新規レポートを作成する: 新しいカスタムレポートの作成を開始します。レポートの目的を明確に示す名前と説明を選択します(例: 「プロセスマイニング用KYCオンボーディングイベントログ」)。
- 主要なデータソースを定義する: ケースのライフサイクル情報をキャプチャする主要なデータオブジェクトまたはビューを選択します。これはしばしば
[CaseWorkflowHistory]や[LifecycleEventsView]のような事前に設定されたビューです。このオブジェクトには、ケース識別子、イベント名またはステータス、タイムスタンプが含まれている必要があります。 - レポート列(属性)を設定する: レポートビルダーインターフェースを使用して列を追加します。Fenergoデータモデルのソースフィールドを、必要なイベントログ属性にマッピングします。例えば、Fenergoの
CaseIDをCustomerApplicationに、EventTimestampをEventStartTimeに、EventPerformerをInitiatingUserにマッピングします。 - アクティビティロジックを構築する: これが最も重要なステップです。レポートは、14の必須アクティビティそれぞれについて独立した行を生成するように設定する必要があります。これは、各アクティビティの論理ブロックまたはフィルターされたデータセットを作成し、レポートビルダー内でUNIONまたは同等の関数を使用してそれらを結合することで実現されます。
- 「ケース作成」ロジックを定義する: 最初のブロックを作成します。初期のケース作成イベントについてデータソースをフィルターします。これは、多くの場合、ケースに関連付けられた最も早いタイムスタンプ、または「Case Created」というイベントタイプに基づいています。
CreationDateをEventStartTimeにマッピングします。 - ステータスベースのアクティビティロジックを定義する: ステータス変更から推測されるアクティビティ(例: 「Documents Received」、「Application Approved」)については、個別のブロックを作成します。特定の
Statusフィールド値でデータソースをフィルターし、StatusChangeDateをEventStartTimeとして使用します。 - タスクベースのアクティビティロジックを定義する: ワークフロータスクに関連するアクティビティ(例: 「Compliance Review Completed」)については、
TaskNameとTaskCompletionDateでフィルターするブロックを作成します。完了日をEventStartTimeとして使用します。 - グローバルレポートフィルターを設定する: データ範囲を制限するためにレポートレベルのフィルターを適用します。過度に大きなエクスポートを避けるために、
EventStartTimeに特定の日付範囲を設定します。初期分析には3~6ヶ月の期間が推奨されます。「KYC顧客オンボーディング」のような特定のケースタイプでフィルターします。 - レポートを実行しプレビューする: Fenergo UI内でレポートを実行します。最初の100~200行をプレビューして、データ構造が正しいこと、すべての列が期待どおりに表示されていること、および異なるアクティビティが存在することを確認します。
- データをエクスポートする: レポートの全結果をCSVまたはExcelファイルにエクスポートします。これが生のイベントログファイルです。
- 最終データ準備: エクスポートされたCSVファイルを開きます。
SourceSystemとLastDataUpdate列がレポートによって直接生成できなかった場合は、手動で追加します。すべての行のSourceSystemを「Fenergo」に設定し、エクスポートタイムスタンプをLastDataUpdateとして設定します。
設定
- 前提条件: Fenergo Reporting & Analyticsモジュールへのアクセス権限を持つユーザーは、カスタムレポートを作成・実行できる必要があります。
- 主要なデータソース: レポートは主にFenergoのケース管理およびワークフロー履歴オブジェクトから構築する必要があります。一般的なソースには、
[CaseDetails]、[CaseStatusHistory]、[WorkflowTaskHistory]などがあります。正確な名称はFenergoの設定によって異なる場合があります。 - 日付範囲: パフォーマンスを管理するため、イベントタイムスタンプに日付範囲フィルターを設定することが重要です。直近3~6ヶ月の期間から始めましょう。履歴分析の場合は、レポートをバッチ(例: 四半期ごと、年ごと)で実行します。
- 主要なフィルター: 'KYC顧客オンボーディング'など、特定のプロセスまたはケースタイプで常にフィルターをかけ、無関係なデータを除外します。分析の目的に応じて、法人の種類や管轄区域でフィルターをかける必要がある場合もあります。
- アクティビティ定義: 各アクティビティは、
Status、TaskName、または専用のEventTypeフィールドのような特定のフィルター基準を使用して定義する必要があります。これらのフィールドに依存することが、プロセス内の各固有のイベントを分離する鍵となります。 - パフォーマンスに関する考慮事項: 多くのデータソースを結合したり、広範囲の日付をスキャンするレポートは遅くなる可能性があります。可能であれば、レポートはオフピーク時間に実行するようにスケジュールしてください。エクスポートに不要な列を含めると処理時間が増加するため、避けてください。
a クエリ例 config
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'