保険金請求処理のデータテンプレート

Guidewire ClaimCenter
保険金請求処理のデータテンプレート

保険金請求処理のデータテンプレート

保険金請求処理の改善に役立つ専用リソースをご紹介します。このテンプレートでは、収集すべきデータ属性や追跡すべき重要なアクティビティを示し、データ抽出の手順を説明します。プロセスを詳しく分析するために必要な情報を漏れなく収集する際にお役立てください。
  • 収集を推奨する属性
  • 追跡すべき主なアクティビティ
  • Guidewire ClaimCenterからのデータ抽出手順
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

保険金請求処理の属性

これらの推奨データ項目は、保険金請求処理のワークフローを効果的に分析するためのイベントログを作成するうえで重要です。
3 必須 4 推奨 14 任意
名前 説明
アクティビティ名
ActivityName
保険金請求の処理過程における特定の時点で発生した業務上の活動またはイベントの名称です。
説明

この属性は、保険金請求プロセスにおける特定のステップや節目を表します。たとえば、「請求の作成」「調査の開始」「保険金の支払い」などです。同じケースIDに属するこれらのアクティビティの順序から、プロセスフローを把握できます。

アクティビティの順序、発生頻度、所要時間の分析は、プロセスマイニングの中核です。プロセスモデルの発見、ボトルネックの特定、手戻りの検出、プロセス逸脱の分析に役立ちます。

重要な理由

プロセスのステップを定義し、プロセスマップを可視化するとともに、プロセスフローやボトルネックを分析できるようにします。

入手先

通常はClaimCenterのイベントテーブルや監査ログから取得します。システムイベントやステータスの変更を、標準化されたアクティビティ名に対応付ける方法がよく使われます。

例
請求作成賠償責任の判断支払いの発行請求の終了
イベント時刻
EventTime
アクティビティが発生した正確な日時です。
説明

このタイムスタンプは、アクティビティがシステムに記録された正確な時刻を示します。時間に基づくプロセス分析に欠かせないデータです。

1つのケースIDに属するEventTimeを時系列に並べると、プロセスフローを再構成できます。連続するイベント間の時間差から、サイクルタイム、待ち時間、処理時間を算出できます。これらは、パフォーマンス分析、ボトルネックの特定、SLAの監視に欠かせません。

重要な理由

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

入手先

Guidewire ClaimCenterの履歴テーブルや監査テーブルで、イベントまたはアクティビティのデータとともに確認できます。「CreateTime」や「UpdateTime」などのフィールドが該当します。

例
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
請求ID
ClaimID
各保険請求を一意に識別するIDで、主要なケース識別子として使われます。
説明

請求IDは、提出から終了まで各ケースを一意に識別する、請求処理分析の基盤です。関連するすべてのアクティビティ、文書、支払い、連絡を結び付け、請求のライフサイクルを漏れなく一貫して把握できるようにします。

プロセスマイニングでは、データセット内のすべてのイベントが請求IDにひも付いているため、プロセス全体の流れを再構成できます。サイクルタイムの分析、プロセスのバリアントの特定、部門や査定担当者をまたぐ請求の経路の追跡に欠かせません。

重要な理由

関連するすべてのイベントを結び付ける基本キーです。1件の請求の全経路を追跡し、分析できます。

入手先

Guidewire ClaimCenterの主キーで、通常はClaimエンティティのClaim.ClaimNumberまたは同様のフィールドにあります。

例
000-123-45678000-987-65432001-456-11223
保険金請求のステータス
ClaimStatus
イベント発生時点での保険金請求全体のステータスです(例:受付中、完了、支払い拒否)。
説明

この属性は、保険金請求の大まかな状態を示します。主なステータスには、「受付中」「完了」「支払い拒否」「再開」などがあります。最終ステータスは、重要な結果指標です。

ステータスの変化を追跡すると、プロセスの節目や結果を定義できます。請求の最終的な解決状況の特定、拒否率の算出、完了後に請求が再開される頻度の分析に役立ちます。再開が多い場合、プロセス上の問題や顧客の不満が示されている可能性があります。

重要な理由

保険金請求の結果を示します。拒否率、完了の傾向、請求の再開頻度の分析に欠かせません。

入手先

Claimエンティティの基本フィールドで、通常は「State」または「Status」という名前です。

例
受付中完了支払い拒否再開
保険金請求の種類
ClaimType
自動車、財物、賠償責任など、保険金請求の分類です。
説明

保険金請求の種類は、保険種目や損害の性質に基づいて請求を分類する基本的な属性です。種類によってプロセスや複雑さが異なり、適用される規制も変わることがあります。

保険金請求の種類ごとにプロセスを分けて分析すると、意味のあるインサイトを得られます。保険種目間のパフォーマンス比較、種類ごとのボトルネックの特定、各請求の特性に合わせたプロセス改善の検討に役立ちます。

重要な理由

保険金請求を種類別に分析できます。たとえば、自動車と財物ではプロセスやパフォーマンス目標が異なる場合があります。

入手先

ClaimCenterのPolicyまたはClaimエンティティから取得します。多くの場合、保険種目(LOB)コードに基づきます。

例
個人向け自動車保険企業向け財物保険一般賠償責任保険労働者災害補償保険
担当損害査定人
AssignedAdjuster
保険金請求または特定のアクティビティを担当するユーザーの名前またはIDです。
説明

この属性は、特定の時点で保険金請求を担当する損害査定人を示します。損害査定人は、請求全体を担当する場合も、請求内の特定のタスクを担当する場合もあります。

担当損害査定人ごとの分析は、業務量の調整、パフォーマンス管理、研修機会の特定に役立ちます。「担当件数が最も多い損害査定人は誰か」「損害査定人によってパフォーマンスに差があるか」「業務は均等に割り当てられているか」といった問いに答えられます。

重要な理由

ユーザーの関与状況を記録し、業務量の分析、パフォーマンスの比較、リソースに関するボトルネックの特定に役立ちます。

入手先

ClaimCenterのClaimまたはExposureエンティティで確認できます。多くの場合、Userオブジェクト(例:Claim.Assignee)に関連付けられています。

例
j.doem.smiths.jones
損害原因
LossCause
損害が発生した具体的な原因です(例:衝突、火災、水濡れ)。
説明

この属性は、保険金請求の原因を詳しく示します。損害原因によって、必要な調査の手順、専門家の種類、請求処理全体の複雑さが変わることがあります。

損害原因ごとにプロセスを分析すると、見えにくい傾向を把握できます。たとえば、「水濡れ」に関する請求は、「盗難」に関する請求よりも手戻りが多く、専門家の関与が必要になる可能性があります。こうしたインサイトは、より専門的で効率的な対応手順の作成に役立ちます。

重要な理由

請求の性質を把握するための情報を提供し、損害原因によるプロセスフローや所要時間の違いを分析できます。

入手先

Claimエンティティの標準フィールドで、通常は「LossCause」という名前です。

例
衝突火災水濡れ盗難
SLAステータス
SLAState
保険金請求が解決目標日までに完了したかどうかを示します。
説明

この計算属性は、完了した請求ごとにSLAの遵守状況を分類して示します。「請求の完了」アクティビティのタイムスタンプと「解決目標日」を比較して算出します。

「請求解決目標の遵守状況」ダッシュボードでは、「期限内」「期限超過」などの明確な分類を使って分析できます。フィルターや集計が容易になり、SLAの全体的な遵守率の算出や、遅延の原因のドリルダウンに役立ちます。

重要な理由

SLAの遵守状況を明確に分類して示すため、期限内の処理状況を簡単に絞り込み、集計、分析できます。

入手先

計算フィールド:IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late')。

例
期限内期限超過
ソースシステム
SourceSystem
データの抽出元となるシステムです。
説明

この属性は、イベントデータの発生元を示します。現在の企業環境では、保険金請求に関するイベントが、Guidewireなどの基幹システム、文書管理システム、顧客ポータルなど、複数のシステムから発生することがあります。

ソースシステムを指定すると、データガバナンスやデータの不整合の調査に役立ち、プロセスを支えるシステム構成も把握しやすくなります。また、プロセスの主要なステップと、周辺システムで行われる補助的な作業を区別できます。

重要な理由

データの発生元を示します。データガバナンスや、複数の連携システムにまたがる分析に欠かせません。

入手先

通常、データの抽出、変換、読み込み(ETL)の過程で追加される固定値です。

例
Guidewire ClaimCenter v10Customer Portal APIDocumentum
保険契約の種類
PolicyType
保険金請求の対象となる保険契約の種類です。
説明

保険契約の種類は、保険金請求の種類よりも詳細な分類で、「住宅所有者向け」「企業向け自動車」「サイバー賠償責任」など、具体的な保険商品を示します。この詳細な分類から、商品ごとのプロセスの違いがわかる場合があります。

保険契約の種類ごとにプロセスを分析すると、商品固有の非効率な点を見つけられます。たとえば、新たに発売された保険商品の請求では、プロセスが十分に確立されておらず、遅延が生じることがあります。こうした分析は、商品設計やプロセスの標準化に役立ちます。

重要な理由

保険商品ごとにプロセスを分析し、契約内容による対応の違いを特定できます。

入手先

Claimに関連付けられたPolicyエンティティに記録されています。

例
住宅総合保険企業向け自動車賠償責任保険内陸海上保険
最終データ更新日時
LastDataUpdate
ソースシステムからデータを最後に更新または抽出した日時を示すタイムスタンプです。
説明

この属性は、ソースシステムからデータを最後に取得した日時を示します。分析対象のデータがどの程度新しいかを把握するために欠かせないメタデータです。

ダッシュボードや分析画面では、この情報を目立つ位置に表示し、データがいつ時点のものかを利用者が確認できるようにします。インサイトが現在の業務状況を反映しているのか、古いデータに基づいているのかを判断するのに役立ちます。

重要な理由

データの新しさを示し、プロセス分析がどの時点の状況を反映しているかを把握できるようにします。

入手先

ETL処理中に生成、保存される値で、データの読み込み日時を示します。

例
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
情報の再依頼
RepeatedInfoRequestFlag
同じ請求について「追加情報の依頼」が複数回発生したかどうかを示すフラグです。
説明

同じ請求で「追加情報の依頼」アクティビティが2回以上発生した場合、この真偽値フラグがtrueになります。この状況は、初期の情報収集に非効率な点があることを示す場合があります。

この属性は、「情報再依頼率」の重要業績評価指標(KPI)に直接役立ちます。初回の事実確認が不十分な問題を定量化できます。不完全な情報収集は、大幅な遅延や顧客の不満につながることがあります。このフラグが付いた請求を分析すると、必要な情報を一度に依頼できるよう、損害査定人向けのチェックリストや手順を改善できます。

重要な理由

初回の情報収集が不十分なために遅延や手戻りが発生している箇所を特定できます。

入手先

プロセスマイニングツールで、ケースごとに「追加情報の依頼」アクティビティの発生回数を数えて算出します。

例
truefalse
手戻りかどうか
IsRework
アクティビティが手戻りを表すかどうかを示すフラグです。手戻りとは、プロセスの前の段階に戻ることです。
説明

この計算属性は、手戻りに含まれるアクティビティを示します。たとえば、プロセスが「調査の完了」から「調査の開始」に戻った場合、2回目の「調査の開始」アクティビティが手戻りとして記録されます。

手戻りの特定は、プロセスの非効率な点や品質上の問題を見つけるうえで欠かせません。「手戻りと拒否の頻度」ダッシュボードでは、この指標を使って、請求が理想経路から外れる頻度を測定します。手戻りの原因を分析すると、プロセスの品質や処理速度を大きく改善できる可能性があります。

重要な理由

手戻りに含まれるアクティビティを明示し、プロセスの非効率な点や品質上の問題を把握できます。

入手先

プロセスマイニングツールで、ケースごとのアクティビティの順序を分析して算出します。

例
truefalse
損害発生日
LossDate
保険金請求の原因となった事故または損害が発生した日付です。
説明

損害発生日は、保険金請求の対象となる実際の事故や損害(例:自動車事故、財物の損傷)が発生した日付です。請求が報告または作成された日付とは異なります。

損害発生日から「請求の作成」アクティビティまでの期間(報告遅延)は、重要業績評価指標(KPI)です。この期間を分析すると、顧客の行動や、事故受付窓口の有効性についてインサイトを得られます。

重要な理由

請求の発生状況を把握するための情報を提供し、事故発生から請求提出までの報告遅延を分析できます。

入手先

Claimエンティティの基本的な日付フィールドで、通常は「LossDate」という名前です。

例
2023-05-102023-04-202023-05-28
支払金額
PaymentAmount
支払いアクティビティで実際に支払われた金額です。
説明

この属性は、保険金請求に対する個々の支払い額を記録します。1件の請求に対して、処理期間中に複数回の支払いが発生することがあります。

プロセスマイニングで財務分析を行ううえで欠かせないデータです。請求ごとの支払総額の追跡、金額に応じた支払い承認時間の分析、プロセスの非効率な点と財務上の結果との関連付けに利用できます。たとえば、サイクルタイムが長い請求では、支払総額も高くなる傾向があるかを分析できます。

重要な理由

請求に伴う金銭のやり取りを記録し、支払額とプロセス内のアクティビティとの関係を分析できます。

入手先

Claimに関連付けられた支払い関連エンティティに記録されています。取引テーブルや小切手テーブルにある場合がよくあります。

例
4500.00125000.00500.00
管轄州
JurisdictionState
保険金請求を管轄する州または地域です。適用される規制要件を決定します。
説明

この属性は、請求処理に適用される法的管轄区域(例:米国の州)を示します。保険規制は管轄区域によって大きく異なり、必要なプロセスのステップ、連絡期限、文書化に影響します。

コンプライアンスの監視に欠かせない属性です。管轄区域ごとにプロセスを分析すると、州ごとの規制要件が満たされているかを確認できます。また、サイクルタイムやプロセス経路の違いが、業務上の非効率ではなく法的な制約によるものかを判断するのにも役立ちます。

重要な理由

管轄区域ごとに保険金請求プロセスに影響する規制が異なるため、コンプライアンス分析に欠かせません。

入手先

Claimエンティティの標準フィールドで、通常は「JurisdictionState」という名前です。

例
CANYTXFL
終了時刻
EndTime
アクティビティが完了した日時を示すタイムスタンプです。
説明

終了時刻は、アクティビティが完了した時点を示します。「調査」や「文書の確認」のように、所要時間を測定できるタスクで特に役立ちます。プロセスマイニングでは、開始時刻だけで表せる瞬時のアクティビティも多くありますが、開始と終了が明確なアクティビティは、両方のタイムスタンプで記録するのが適切です。

この属性を使うと、待ち時間と区別してアクティビティの処理時間を正確に算出できます。ステップ間の遅延だけでなく、時間がかかっている個々のタスクも特定できます。

重要な理由

アクティビティの完了にかかる時間を正確に測定し、処理時間と待ち時間を区別できます。

入手先

アクティビティの完了を示す後続イベントを特定して算出する必要がある場合があります。たとえば、ステータスが「進行中」から「完了」に変わった時点を使います。

例
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
自動処理かどうか
IsAutomated
アクティビティがシステムによって自動的に実行されたか、人が実行したかを示すフラグです。
説明

この真偽値属性は、システムが実行したアクティビティ(例:支払備金の自動作成、システムによる通知の作成)と、損害査定人が手作業で行ったアクティビティを区別します。

保険金請求プロセスの自動化の度合いを把握するうえで重要な属性です。手作業による介入が集中する箇所の特定、エンドツーエンド処理の取り組みの効果測定、人が行っている反復的でルールに基づくタスクを特定したうえで、自動化の新たな候補を見つけるのに役立ちます。

重要な理由

システムによるアクティビティと人によるアクティビティを区別します。自動化分析や、手作業に関するボトルネックの特定に欠かせません。

入手先

多くの場合、データから判定する必要があります。たとえば、汎用の「system」ユーザーによって記録されたイベントを、自動処理として分類できます。

例
truefalse
解決目標日
ResolutionTargetDate
社内または規制上のSLAに基づき、保険金請求の解決が見込まれる期限です。
説明

解決目標日は、保険金請求を完了する期限です。管轄区域、請求の種類、保険契約の条件などに基づいて設定されます。パフォーマンスやコンプライアンスを測定する基準となります。

SLAの遵守状況を示すダッシュボードや重要業績評価指標(KPI)の作成に欠かせない属性です。実際の「請求の完了」日と目標日を比較すると、期限を過ぎた請求を自動的に特定し、期限内に完了した割合を測定できます。また、目標達成が難しい請求の種類や部門も把握できます。

重要な理由

サービスレベル契約(SLA)の遵守状況を測定し、期限に遅れる可能性のある請求を特定するための基準です。

入手先

カスタムフィールドの場合や、ClaimCenterで設定した業務ルールに基づいて算出する場合があります。特定の請求指標に関連付けられていることもあります。

例
2023-06-142023-07-202023-08-28
請求金額
ClaimedAmount
契約者が当初請求した金額の合計です。
説明

この属性は、請求者が申告した損害額を表します。通常は初期見積額であり、調査や支払備金の設定に伴って変わることがあります。

請求金額を分析すると、金額の規模に応じて請求を分類できます。高額請求は、少額請求よりも厳格で複雑なプロセスを経ることがよくあります。金額帯ごとにプロセスを比較すると、少額請求の対応を効率化する機会や、高額請求に対する管理を強化する必要性が見えてきます。

重要な理由

金額に応じて請求を分類できます。高額請求では、より複雑なプロセスが必要になる場合があります。

入手先

単一のフィールドではなく、Exposureに記録された初期損害見積額から算出する場合があります。

例
5000.00150000.00750.50
部門
Department
保険金請求に関するアクティビティを担当する事業部門または部門です。
説明

この属性は、担当損害査定人が所属する部門またはチームを示します。たとえば、「自動車保険金請求」「財物保険金請求」「特別調査部門」などです。プロセスを組織の観点から捉えるために役立ちます。

部門ごとの分析は、組織全体のプロセスパフォーマンスを把握するうえで重要です。部門間の引き継ぎによる遅延を特定し、チーム間の効率を比較して、保険金請求を担当する組織全体でリソースをより適切に配分できます。

重要な理由

組織内のチームごとにパフォーマンスを分析し、部門間の引き継ぎに関する問題を把握するための情報を提供します。

入手先

通常、ClaimCenterに登録された担当ユーザーまたはグループのプロフィールに関連付けられています。

例
自動車保険金請求部門財物保険金請求チーム特別調査部門(SIU)
必須 推奨 任意

保険金請求処理のアクティビティ

保険金請求プロセスを正確に把握・分析するため、イベントログに記録する主なステップと重要な節目を示します。
7 推奨 7 任意
アクティビティ 説明
初回準備金の設定
補償対象に対する最初の準備金取引が作成されたことを示し、請求にかかる費用を見積もります。重要な財務イベントであり、明示的に記録されます。
重要な理由

このマイルストーンは、財務分析と潜在的な賠償責任の評価速度を把握するうえで重要です。遅延は財務計画や報告に影響する可能性があります。

入手先

請求の補償対象に関連付けられた最初のcc_reservelineレコードの作成から取得します。取引のCreateTimeがイベントのタイムスタンプです。

記録

特定の請求に含まれる補償対象について、すべての準備金明細の作成タイムスタンプの最小値を特定します。

イベントタイプ explicit
支払いの承認
示談金の支払いが正式に承認されたことを示します。重要な監査イベントであり、権限を持つユーザーが取引を承認した時点で明示的に記録されます。
重要な理由

この重要なマイルストーンを経て、最終的な支払いに進めます。このアクティビティの前後にかかる時間を分析すると、承認ワークフローや管理者の対応状況による遅延を切り分けられます。

入手先

多くの場合、cc_checkまたはcc_transactionエンティティに関連するcc_historyテーブルの明示的なイベントとして記録され、「承認待ち」から「承認済み」へのステータス変更を示します。

記録

特定の支払い取引について、ステータスが「承認済み」に変わったイベントを追跡します。

イベントタイプ explicit
支払いの発行
このアクティビティは、支払いプロセスの最終段階を示します。支払いが正式に発行され、財務システムに送られます。明示的に記録される財務取引です。
重要な理由

このアクティビティは、支払いの送金プロセスの効率を測定するうえで重要です。承認の遅れと、実際の資金発行の遅れを区別できます。

入手先

cc_checkまたはcc_transactionエンティティのIssueDate、またはステータスが「発行済み」か「送信済み」に変わった時点から取得します。多くの場合、タイムスタンプ付きの明示的なイベントです。

記録

支払いレコードのIssueDate、またはステータスが「発行済み」に変わったタイムスタンプを特定します。

イベントタイプ explicit
補償対象の作成
このアクティビティは、請求に含まれる特定の潜在的な賠償責任または損害の種類(車両の損傷、負傷など)を表す補償対象の作成を示します。Guidewireで明示的に記録されるイベントです。
重要な理由

補償対象は、請求を分類して分析するうえで基本となる要素です。作成を追跡すると、請求の複雑さや損害の種類によるプロセスの違いを把握できます。

入手先

cc_exposureテーブルに新しいレコードが作成された時点のCreateTimeから取得します。各レコードは1つのClaim IDに関連付けられています。

記録

Exposureエンティティテーブルで、新しいレコードが作成されたタイムスタンプを特定します。

イベントタイプ explicit
請求の却下
請求を却下する最終判断を示し、プロセスの終点となります。請求のステータスが却下理由を伴う終了状態に変わったことから推定します。
重要な理由

これは重要な結果を示すイベントです。却下の頻度や理由、そこに至るプロセス経路を分析すると、請求受付、調査、保険契約の解釈に関する問題を特定できます。

入手先

cc_claimテーブルのStateフィールドが「終了」に変わり、CloseReasonフィールドが「却下」または同様の値になったことから推定します。イベントのタイムスタンプはCloseDateです。

記録

請求のステータスが「終了」に変わり、理由コードが却下を示すレコードを抽出します。

イベントタイプ inferred
請求の終了
すべてのアクティビティと支払いが完了し、請求が正常に終了したことを示します。請求のメインステータスの変更から推定する、主要な正常終了イベントです。
重要な理由

主要な終了イベントであるこのアクティビティは、開始から終了までのサイクルタイムの算出とSLA達成率の測定に欠かせません。請求のライフサイクルが完了したことを示します。

入手先

cc_claimテーブルのStateフィールドが「終了」に変わったことから推定します。イベントのタイムスタンプは請求レコードのCloseDateです。

記録

請求のメインステータスフィールドが「終了」に更新された時点を特定します。

イベントタイプ inferred
請求作成
このアクティビティは、事故の初回通知(FNOL)と、Guidewire ClaimCenterでの新しい請求レコードの正式な作成を示します。新しいClaimエンティティが初めてデータベースに保存された時点で、明示的に記録されます。
重要な理由

主要な開始イベントであるこのアクティビティは、請求の開始から終了までのサイクルタイムを測定するうえで欠かせません。以降のパフォーマンス指標と所要時間の重要業績評価指標(KPI)のベースラインになります。

入手先

これは、cc_claimテーブルのCreateTimeから取得する明示的なイベントです。一意のClaim IDを持つ新しいレコードの作成が、イベントの発生を示します。

記録

基底のClaimエンティティテーブルで、新しいレコードが作成されたタイムスタンプを特定します。

イベントタイプ explicit
示談金額の算出
支払い承認前に示談金額が決定した時点を示します。「承認待ち」状態の支払いが作成されたことから推定できます。
重要な理由

評価から支払いへの移行を示します。「支払い承認リードタイム」の重要業績評価指標(KPI)を測定する起点となり、承認プロセスの遅延を明らかにします。

入手先

初期ステータスが「承認待ち」、または「承認」前の同様の状態であるcc_checkまたはcc_transactionレコードのCreateTimeから推定します。

記録

承認前のステータスで支払いまたは取引レコードが作成された時点を特定します。

イベントタイプ inferred
調査開始
請求または補償対象の調査段階が正式に始まったことを示します。多くの場合、Guidewireで最初の調査関連の「アクティビティ」(タスク)が作成された時点から推定します。
重要な理由

このアクティビティは、重要で長期化しやすい段階の開始を示します。調査開始までの時間と調査自体の所要時間を分析すると、主なボトルネックが見えてきます。

入手先

調査に関連するActivityPattern(例:「初期調査」「目撃者への連絡」)を持つcc_activityレコードのCreateTimeから推定します。

記録

調査に関連するパターンまたは件名を持つタスクが最初に作成された時点を特定します。

イベントタイプ inferred
請求の再開
追加対応のため、請求の状態が「終了」から「オープン」に戻ったことを示します。特定のステータス変更の順序から推定します。
重要な理由

このアクティビティは手戻りを示します。再開された請求が多い場合、最初の示談、見落とされた損害、その他のプロセス上の問題が考えられ、コストと非効率の増加につながります。

入手先

cc_historyテーブルで、cc_claimエンティティのStateフィールドが「終了」から「オープン」または別の有効な状態に戻ったことを特定して推定します。

記録

請求のメインステータスフィールドを監視し、終了状態からオープン状態への変更を確認します。

イベントタイプ inferred
請求の割り当て
請求を特定のユーザー(査定担当者)またはグループに割り当て、対応を依頼したことを示します。通常は、Claimエンティティの割り当てフィールドの変更を監視して推定します。
重要な理由

割り当てを追跡すると、査定担当者の業務負荷や振り分けのボトルネックを分析し、担当者が最初に対応するまでの時間を測定できます。

入手先

cc_historyテーブルで、特定のClaim IDに関連付けられたAssignedUserまたはAssignedGroupフィールドの変更を追跡して推定します。変更のタイムスタンプがイベントの発生時刻を示します。

記録

監査ログまたは履歴テーブルで、請求の割り当てフィールドの更新を監視します。

イベントタイプ inferred
賠償責任の判断
補償対象について、賠償責任または過失に関する判断が確定した時点を示します。通常はExposureエンティティのステータス変更から推定します。
重要な理由

これは、示談と支払いの段階に進むための重要な判断のマイルストーンです。判断までの時間を分析すると、調査や評価の段階にあるボトルネックを特定できます。

入手先

cc_historyテーブルで、cc_exposureエンティティのStateまたはカスタムの賠償責任ステータスフィールドの変更を追跡して推定します。履歴レコードのタイムスタンプがイベントの発生時刻を示します。

記録

監査ログまたは履歴テーブルで、補償対象の状態または賠償責任ステータスの更新を監視します。

イベントタイプ inferred
追加情報の依頼
請求者または第三者に、追加情報や文書を依頼したことを示します。通常はClaimCenterで作成された明示的な「アクティビティ」(タスク)として記録されます。
重要な理由

このアクティビティは、「追加情報収集サイクルタイム」の重要業績評価指標(KPI)を測定する起点です。頻繁に発生する場合、事故の初回通知(FNOL)のプロセスが不完全、または情報収集が非効率である可能性があります。

入手先

外部関係者への文書または情報の依頼に関連するActivityPatternを持つcc_activityレコードのCreateTimeから取得します。

記録

外部情報を依頼するタスクが作成された時点を特定します。

イベントタイプ explicit
追加情報の受領
追加情報の依頼が完了したことを示します。情報依頼に対応する「アクティビティ」(タスク)のステータスが「完了」になった時点で記録されます。
重要な理由

これは「追加情報収集サイクルタイム」の重要業績評価指標(KPI)の終点です。依頼から受領までの長い期間は、請求処理の遅延につながる一般的な要因です。

入手先

情報依頼に関連するActivityPatternを持つcc_activityレコードのCloseTimeから取得します。アクティビティのステータスは「完了」である必要があります。

記録

外部情報を依頼するタスクが完了したタイムスタンプを特定します。

イベントタイプ explicit
推奨 任意

データ抽出ガイド

Guidewire ClaimCenterからデータを取得する方法

準備はできましたか?

このテンプレートを使って分析用のデータを準備し、保険金請求処理に関するインサイトを見つけてください。今すぐワークフローの改善に取り組みましょう。

保険金請求処理を迅速化し、案件の早期解決へ

滞留を解消し、不正を防止して、70%のストレートスルー処理を目指します。

無料トライアルを開始しましょう。

クレジットカードは不要です。セットアップは数分で完了します。