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

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

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

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

保険金請求処理の属性

保険金請求ワークフローを効果的に分析するための、完全なイベントログの作成に欠かせない推奨データ項目です。
3 必須 4 推奨 14 任意
名前 説明
アクティビティ名
ActivityName
請求ライフサイクルの特定の時点で発生した業務アクティビティまたはイベントの名称です。
説明

この属性は、「Claim Created」「Investigation Started」「Payment Issued」など、保険金請求プロセスにおける特定のステップやマイルストーンを示します。特定のClaim IDにおけるこれらのアクティビティの順序が、プロセスフローを形成します。

アクティビティの順序、頻度、間隔を分析することは、プロセスマイニングの中核です。プロセスモデルの発見、ボトルネックの特定、手戻りループの検出、プロセスの逸脱分析が可能になります。

重要な理由

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

入手先

通常はClaimCenterのイベントテーブルまたは監査ログから取得し、特定のシステムイベントやステータス変更を標準化されたアクティビティ名にマッピングします。

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

このタイムスタンプは、アクティビティがシステムに記録された正確な時点を示します。時間に基づくプロセス分析の基礎となります。

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

重要な理由

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

入手先

Guidewire ClaimCenterの履歴テーブルまたは監査テーブルで、イベントやアクティビティのデータとともに確認できます。通常は「CreateTime」または「UpdateTime」フィールドとして記録されます。

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

Claim IDは、提出から完了まで各ケースを一意に識別する、保険金請求プロセス分析の基盤です。関連するすべてのアクティビティ、書類、支払い、コミュニケーションを結び付け、請求ライフサイクルを完全かつ一貫して把握できるようにします。

プロセスマイニングでは、データセット内のすべてのイベントがClaim IDに紐づくため、プロセスの開始から完了までの流れを再構成できます。処理期間の分析、プロセスのバリエーションの特定、部門や担当者をまたぐ請求の流れの追跡に欠かせません。

重要な理由

関連するすべてのイベントを結び付ける基本キーであり、1件の請求の全体の流れを追跡・分析できます。

入手先

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

000-123-45678000-987-65432001-456-11223
保険金請求ステータス
ClaimStatus
イベント発生時点における保険金請求全体のステータスです。例として、Open、Closed、Deniedなどがあります。
説明

この属性は、保険金請求の大まかな状態を示します。主なステータスには、「Open」「Closed」「Denied」「Reopened」があります。請求の最終ステータスは、重要な結果指標です。

保険金請求ステータスの変化を追跡すると、プロセスの主要な節目と結果を定義できます。請求の最終的な解決状況の特定、却下率の計算、クローズ後に再開される請求の頻度の分析に利用できます。再開の頻度が高い場合、プロセス上の問題や顧客満足度の低下を示していることがあります。

重要な理由

請求の結果を示し、却下率、クローズの傾向、請求が再開される頻度を分析するうえで重要です。

入手先

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

オープンクローズ却下再開
保険金請求種別
ClaimType
保険金請求の区分です。例として、自動車、財物、賠償責任などがあります。
説明

保険金請求種別は、事業種別または損害の性質に基づいて請求を分類する基本的な項目です。請求種別によって、従うプロセス、複雑さ、適用される規制が異なる場合があります。

意味のある分析結果を得るには、保険金請求種別でプロセスを分けて分析することが欠かせません。事業種別ごとのパフォーマンスを比較し、種別固有のボトルネックを特定するとともに、各請求区分の特性に合わせて改善施策を調整できます。

重要な理由

請求を区分して分析できます。例えば、自動車と財物では、異なるプロセスに従い、パフォーマンス目標も異なる場合があります。

入手先

ClaimCenterのPolicyまたはClaimエンティティから導出され、通常はLine of Business(LOB)コードに基づきます。

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

この属性は、特定の時点で保険金請求を担当する個々のアジャスターを識別します。アジャスターは請求全体を担当する場合もあれば、請求内の特定のタスクを担当する場合もあります。

担当アジャスター別の分析は、業務量の平準化、パフォーマンス管理、研修機会の特定に欠かせません。「最も多くの案件を抱えているアジャスターは誰か」「アジャスター間でパフォーマンスに差があるか」「業務は均等に配分されているか」といった問いに答えられます。

重要な理由

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

入手先

ClaimCenterのClaimまたはExposureエンティティで利用でき、通常はUserオブジェクト(例:Claim.Assignee)に関連付けられています。

j.doem.smiths.jones
損害原因
LossCause
損害事象の具体的な理由または原因です。例として、衝突、火災、水濡れなどがあります。
説明

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

損害原因別にプロセスを分析すると、隠れた傾向を明らかにできます。例えば、「Water Damage」に関する請求は、「Theft」に関する請求よりも手戻りが多く、専門家の関与が必要になる割合も高い場合があります。こうした分析結果は、より専門的で効率的な処理手順の整備に役立ちます。

重要な理由

請求の性質を把握するための情報であり、損害原因の違いがプロセスの流れや所要時間に与える影響を分析できます。

入手先

Claimエンティティの標準項目で、通常は「LossCause」という名前です。

衝突火災水濡れ損害盗難
SLAステータス
SLAState
請求が解決目標日までにクローズされたかどうかを示します。
説明

この計算属性は、クローズ済みの請求ごとにSLA遵守状況を区分して示します。「Claim Closed」アクティビティのタイムスタンプと「Resolution Target Date」を比較して導出します。

この属性は、「Claim Resolution Target Adherence」ダッシュボードを直接支援し、「On Time」や「Late」などの明確な区分に分析結果を整理します。フィルタリングや集計が容易になり、SLA遵守率全体の計算や、遅延理由の詳細な分析が可能になります。

重要な理由

SLA遵守状況を明確な区分で示すため、期限内処理のフィルタリング、集計、分析を容易に行えます。

入手先

計算項目:IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late')。

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

この属性は、イベントデータの発生元を示します。現代の企業システム環境では、請求関連のイベントがGuidewireのような中核システム、文書管理システム、顧客ポータルなど、複数のシステムから発生する場合があります。

ソースシステムを指定することは、データガバナンス、データの不整合の調査、プロセスを支える技術環境の把握に欠かせません。中核プロセスのステップと、周辺システムで行われる補助的なアクティビティを区別するのにも役立ちます。

重要な理由

データの発生元を示します。データガバナンスや、複数の統合システムにまたがる分析に欠かせない情報です。

入手先

通常は、データの抽出、変換、ロード(ETL)処理の際に追加される固定値です。

Guidewire ClaimCenter v10顧客ポータルAPIDocumentum
保険契約種別
PolicyType
請求が行われた保険契約の具体的な種別です。
説明

保険契約種別は、保険金請求種別よりも細かな分類であり、「Homeowners」「Commercial Auto」「Cyber Liability」など、具体的な保険商品を示します。この粒度で分析すると、特定の商品に結び付いたプロセスの違いを把握できます。

保険契約種別でプロセスを分析すると、商品固有の非効率を明らかにできます。例えば、新しく発売された保険契約ではプロセスが十分に確立されておらず、遅延が発生する場合があります。この分析結果は、商品設計やプロセスの標準化に役立ちます。

重要な理由

特定の保険商品を対象にプロセスを分析でき、契約内容に応じた処理の違いを特定するのに役立ちます。

入手先

この情報は、Claimに関連付けられたPolicyエンティティにあります。

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

この属性は、ソースシステムから直近にデータを取得した日時を示します。分析対象データの鮮度を把握するうえで欠かせないメタデータ項目です。

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

重要な理由

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

入手先

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

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

このブール型フラグは、1件の請求で「Additional Info Requested」アクティビティが複数回発生した場合にtrueになります。この状況は、初期の情報収集段階に非効率があることを示す場合があります。

この属性は、「Repeated Info Request Rate」KPIを直接支援します。初回の事実確認が不十分であることによる問題を定量化でき、結果として大きな遅延や顧客の不満につながる可能性があります。このフラグが付いた請求を分析すると、必要な情報を一度に依頼できるよう、アジャスター向けのチェックリストや手順を改善できます。

重要な理由

情報収集を初回で完了できず、プロセスの遅延や手戻りにつながる非効率を特定します。

入手先

ケースごとに「Additional Info Requested」アクティビティの発生回数を数え、プロセスマイニングツール内で計算します。

truefalse
手戻りかどうか
IsRework
アクティビティが手戻りループ、つまり以前のプロセス段階への戻りを表すかどうかを示すフラグです。
説明

この計算属性は、手戻りループに含まれるアクティビティを示します。例えば、プロセスが「Investigation Completed」から「Investigation Started」に戻った場合、2回目の「Investigation Started」アクティビティが手戻りとして識別されます。

手戻りの特定は、プロセスの非効率や品質上の問題を明らかにするうえで基本となります。「Rework and Rejection Frequency」ダッシュボードでは、この指標を使って、請求が理想的な「happy path」からどの程度逸脱しているかを定量化します。手戻りの原因を分析すると、プロセスの品質と処理速度を大きく改善できる場合があります。

重要な理由

手戻りループに含まれるアクティビティを明示的に示し、プロセスの非効率や品質上の問題を明らかにします。

入手先

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

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

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

損害発生日から「Claim Created」アクティビティまでの時間差は、報告遅延と呼ばれる重要なKPIです。これを分析すると、顧客の行動や、損害の第一報を受け付けるチャネルの有効性を把握できます。

重要な理由

請求の発生経緯を把握するための重要な情報であり、報告遅延(事故発生から請求提出までの時間)の分析に役立ちます。

入手先

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

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

この属性は、請求に対して行われた個々の支払いの金額を記録します。1件の請求に対して、ライフサイクル全体で複数回の支払いが発生する場合があります。

プロセスマイニングで財務面を分析するうえで欠かせない項目です。請求ごとの支払総額の追跡、金額に応じた支払承認時間の分析、プロセスの非効率と財務結果の関連付けに利用できます。例えば、処理期間が長い請求では、支払総額も高くなる傾向が見られる場合があります。

重要な理由

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

入手先

請求に関連付けられたPayment関連エンティティにあり、通常は取引テーブルまたは小切手テーブルに記録されています。

4500.00125000.00500.00
管轄州
JurisdictionState
請求を管轄し、規制要件を定める州または管轄区域です。
説明

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

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

重要な理由

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

入手先

Claimエンティティの標準項目で、通常は「JurisdictionState」という名前です。

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

終了日時は、アクティビティの完了時点を示します。特に、「Investigation」や「Document Review」のように、所要時間を測定できるタスクで使用します。プロセスマイニングのアクティビティの多くは瞬時に完了するため、StartTimeだけで十分な場合もありますが、開始と終了が明確に分かれるアクティビティでは、両方のタイムスタンプを記録する方が適切です。

この属性により、待ち時間とは分けて、アクティビティの処理時間を正確に計算できます。単にステップ間の遅延が長いことを確認するだけでなく、どのタスクに時間がかかっているのかを特定できます。

重要な理由

アクティビティの完了までにかかった時間を正確に測定し、処理時間と待ち時間を分けて把握できます。

入手先

「In Progress」から「Completed」へのステータス変更など、アクティビティの完了を示す後続イベントを特定して導出する必要がある場合があります。

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

このブール型属性は、システムが実行したアクティビティ(例:準備金の自動作成、システムが生成した通知)と、アジャスターが手動で実行したアクティビティを区別します。

この属性を分析すると、請求プロセスの自動化レベルを把握できます。手動介入が集中する箇所を特定し、ストレートスルー処理の取り組みの効果を測定できます。また、人が現在行っている反復的でルールベースのタスクを特定し、新たな自動化の機会を見つけられます。

重要な理由

システム主導のアクティビティと人が行うアクティビティを区別でき、自動化の分析や手作業によるボトルネックの特定に役立ちます。

入手先

導出が必要になることが多くあります。例えば、汎用の「system」ユーザーが記録したイベントを自動処理として識別できます。

truefalse
解決目標日
ResolutionTargetDate
社内SLAまたは規制上のSLAに基づき、請求を解決する予定の日付です。
説明

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

この属性は、SLA遵守状況のダッシュボードやKPIを作成するうえで重要です。実際の「Claim Closed」日と目標日を比較することで、遅延した請求を自動的に特定し、期限内処理率を測定できます。また、目標達成に苦労している請求種別や部門を明らかにできます。

重要な理由

サービスレベル合意(SLA)の遵守状況を測定し、期限超過のリスクがある請求を特定するための基準です。

入手先

カスタム項目である場合や、ClaimCenterで設定された業務ルールに基づいて導出される場合があります。特定の請求指標に関連付けられている可能性もあります。

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

この属性は、請求者が申告した損害額を示します。多くの場合、初期見積額であり、請求の調査や準備金の設定に伴って変わる可能性があります。

請求金額を分析すると、金銭的な影響に応じて請求を区分できます。高額請求は、低額請求よりも厳格で複雑なプロセスを経ることが多くあります。金額帯ごとにプロセスを比較すると、少額請求の処理を効率化する機会や、高額請求に対してより厳格な管理を適用する機会を見つけられます。

重要な理由

金額に応じて請求を区分できます。高額請求では、異なる、より複雑なプロセスが適用される場合があります。

入手先

単一の項目ではなく、Exposureに記録された初期損害見積額から導出する場合があります。

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

この属性は、担当アジャスターが所属する部門またはチームを示します。例として、「Auto Claims」「Property Claims」「Special Investigations Unit」などがあります。プロセスを組織の観点から捉えるための情報です。

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

重要な理由

組織上の位置付けを示し、チーム間のパフォーマンスを分析するとともに、部門間の引き継ぎに関する問題を明らかにできます。

入手先

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

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

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

保険金請求プロセスを正確に発見・分析するために、イベントログに記録する主要なプロセス手順と重要なマイルストーンです。
7 推奨 7 任意
アクティビティ 説明
Exposureを作成
このアクティビティは、請求に含まれる特定の潜在的負債または損害の種類(車両損傷や負傷など)を表すExposureの作成を示します。Guidewireで明示的に記録されるイベントです。
重要な理由

Exposureは、請求を分類・分析するための基本単位です。作成を追跡することで、請求の複雑さや損害の種類に応じたプロセスの違いを把握できます。

入手先

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

取得

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

イベントタイプ explicit
初期Reserveを設定
Exposureに対する最初の財務Reserveトランザクションの作成を示し、請求にかかる可能性のある費用を見積もります。重要な財務イベントであり、明示的に記録されます。
重要な理由

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

入手先

請求のExposureに関連付けられた最初のcc_reservelineレコードの作成から取得します。トランザクションのCreateTimeがイベントのタイムスタンプになります。

取得

特定の請求のExposureに紐づくすべてのReserve lineについて、作成日時の最小値を取得します。

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

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

入手先

通常は、cc_checkまたはcc_transactionエンティティに関連するcc_historyテーブルに明示的なイベントとして記録され、「Pending Approval」から「Approved」へのステータス変更を示します。

取得

特定の支払いトランザクションが「Approved」に変更されたイベントを追跡します。

イベントタイプ explicit
支払いを発行
支払いプロセスの最終ステップであり、支払いが正式に発行され、財務システムへ送信されたことを示します。明示的に記録される財務トランザクションです。
重要な理由

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

入手先

cc_checkまたはcc_transactionエンティティのIssueDate、またはステータスが「Issued」もしくは「Submitted」に変更された時点から取得します。通常はタイムスタンプ付きの明示的なイベントです。

取得

支払いレコードのIssueDate、またはステータスが「Issued」に変更された時点のタイムスタンプを特定します。

イベントタイプ explicit
請求を却下
請求を却下する最終判断を示し、プロセスの終端となります。請求のステータスが、理由「Denied」を伴うクローズ状態に変更されたことから推定します。
重要な理由

重要な結果イベントです。却下の頻度、理由、却下に至ったプロセス経路を分析することで、請求受付、調査、ポリシー解釈に関する問題を特定できます。

入手先

cc_claimテーブルのStateフィールドが「Closed」に変更され、CloseReasonフィールドが「Denied」または同様の値になったことから推定します。イベント時刻はCloseDateです。

取得

請求ステータスが「Closed」に変更され、理由コードが却下を示すレコードを抽出します。

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

主要な終了イベントとして、このアクティビティは開始から完了までの処理期間の算出とSLA遵守状況の測定に欠かせません。請求ライフサイクルの完了を示します。

入手先

cc_claimテーブルのStateフィールドが「Closed」に変更されたことから推定します。イベント時刻は請求レコードのCloseDateです。

取得

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

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

主要な開始イベントとして、このアクティビティは請求の開始から完了までの処理期間を測定するうえで欠かせません。その後のすべてのパフォーマンスKPIと期間KPIの基準点になります。

入手先

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

取得

基盤となるClaimエンティティテーブルで、新しいレコードが作成された日時を特定します。

イベントタイプ explicit
精算額を算出
精算額が決定されたものの、支払い承認はまだ完了していない時点を示します。「Pending Approval」状態で支払いが作成されたことから推定できます。
重要な理由

査定から支払いへの移行点です。「支払い承認リードタイム」KPIの測定開始点となり、承認経路の遅延を明らかにします。

入手先

初期ステータスが「Pending Approval」または「Approved」になる前の同様の状態であるcc_checkまたはcc_transactionレコードのCreateTimeから推定します。

取得

承認前のステータスで支払いまたはトランザクションレコードが作成された時点を特定します。

イベントタイプ inferred
調査を開始
請求またはExposureの調査段階が正式に始まったことを示します。通常は、Guidewireで調査に関連する最初の「Activity」(タスク)が作成された時点から推定します。
重要な理由

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

入手先

調査に関連するActivityPattern(例:「Initial Investigation」「Contact Witness」を持つcc_activityレコードのCreateTimeから推定します。

取得

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

イベントタイプ inferred
請求を再開
追加作業を行うため、請求が「Closed」状態から「Open」状態に戻されたことを示します。特定のステータス変更の順序から推定します。
重要な理由

このアクティビティは手戻りを示します。再開される請求が多い場合、初回精算の問題、損害の見落とし、その他のプロセス上の不備が原因で、コストと非効率が増加している可能性があります。

入手先

cc_historyテーブルで、cc_claimエンティティのStateフィールドが「Closed」から「Open」または別のアクティブ状態に変更されたことを特定して推定します。

取得

請求のマスターステータスフィールドを監視し、クローズ状態からオープン状態への移行を特定します。

イベントタイプ inferred
請求担当者を割り当て
請求を処理する特定のユーザー(担当者)またはグループへの割り当てを示します。通常は、Claimエンティティの割り当て項目の変更を監視して推定します。
重要な理由

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

入手先

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

取得

請求の割り当て項目に対する更新を、監査ログまたは履歴テーブルで監視します。

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

精算と支払いの段階へ進むための重要な判断マイルストーンです。この判断までの時間を分析することで、調査・査定段階のボトルネックを特定できます。

入手先

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

取得

ExposureのStateまたは賠償責任ステータスに対する更新を、監査ログまたは履歴テーブルで監視します。

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

このアクティビティは、「追加情報収集処理期間」KPIの測定開始点です。頻繁に発生する場合、FNOLプロセスの不備や情報収集の非効率を示している可能性があります。

入手先

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

取得

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

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

「追加情報収集処理期間」KPIの終了点です。依頼から受領までの期間が長いことは、請求プロセスで遅延が発生する一般的な原因です。

入手先

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

取得

外部情報を依頼するタスクが完了した日時を特定します。

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

抽出ガイド

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

準備はできましたか?

このテンプレートを使って分析用のデータを準備し、保険金請求処理の改善点を見つけ出してください。今すぐワークフローの最適化を始めましょう。

保険金請求処理を迅速化し、今すぐ案件を早期解決

滞留を解消し、不正を防止し、70%のSTPを目指します。

無料トライアルを開始

クレジットカードは不要で、数分で設定できます。