データテンプレート:請求処理

Guidewire ClaimCenter
データテンプレート:請求処理

保険金請求プロセス用データテンプレート

請求業務の最適化に特化したリソースへようこそ。収集すべき主要なデータ属性、追跡すべき重要アクティビティ、そして抽出手順のガイダンスをこのテンプレートにまとめました。網羅的なプロセス分析に必要な情報を漏れなく取得するためにご活用ください。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • Guidewire ClaimCenter データ抽出ガイド
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

保険金請求プロセスの属性

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

この属性は、請求プロセスの特定ステップ/マイルストーン(例:「Claim Created」「Investigation Started」「Payment Issued」)を表します。特定の Claim ID におけるこれらアクティビティの並びが、プロセスフローを構成します。

アクティビティ間の順序・発生頻度・所要時間を分析することが、Process Mining の中核です。プロセスモデルの発見、ボトルネックの特定、手戻りループの検知、逸脱の分析が可能になります。

その重要性

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

取得元

これは通常、ClaimCenterのイベントテーブルや監査ログから導出します。特定のシステムイベントやステータス変更を標準化したアクティビティ名にマッピングすることで得られるケースが一般的です。

請求作成責任判断完了支払命令発行請求のクローズ
イベント日時
EventTime
アクティビティが発生した正確な日時。
説明

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

単一のClaim IDにおけるEventTimeを時系列に並べることで、実際のプロセスフローを再現できます。連続するイベント間の時間差から、サイクルタイム、待ち時間、処理時間を算出し、パフォーマンス分析、ボトルネックの特定、SLA監視に活用します。

その重要性

このタイムスタンプは、イベントの順序付け、サイクルタイムや所要時間の算出、プロセス遅延の特定に不可欠です。

取得元

Guidewire ClaimCenter の履歴/監査テーブルで、イベントやアクティビティのデータに付随する 'CreateTime' や 'UpdateTime' として記録されていることが多い項目です。

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

Claim ID は請求プロセス分析の要であり、受付からクローズまで各案件を一意に識別します。関連するアクティビティ、文書、支払い、コミュニケーションをすべてひも付け、請求ライフサイクルを一貫して把握できます。

Process Mining では、データセット内のすべての event が Claim ID に結び付けられており、エンドツーエンドのプロセスフローを復元できます。これにより、サイクルタイムの分析、プロセスバリアントの特定、部門やアジャスター(損害調査員)をまたぐ案件の流れの追跡が可能になります。

その重要性

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

取得元

これはGuidewire ClaimCenterにおける主キーで、通常はコアのClaimエンティティ内のClaim.ClaimNumberなどのフィールドとして存在します。

000-123-45678000-987-65432001-456-11223
担当アジャスター
AssignedAdjuster
請求全体または特定アクティビティを担当するユーザーの名前またはID。
説明

この属性は、ある時点で請求を担当している個々のアジャスター(損害調査員)を識別します。アジャスターは案件全体に割り当てられる場合も、特定タスクのみに割り当てられる場合もあります。

Assigned Adjuster で切り口を分けた分析は、負荷分散、パフォーマンス管理、研修機会の特定に不可欠です。『どのアジャスターの抱える件数が最も多いか』『アジャスター間で成果にばらつきがあるか』『業務は均等に配分されているか』といった問いに答えられます。

その重要性

ユーザーの関与を追跡し、ワークロード分析、パフォーマンス比較、リソース起因のボトルネックの特定を可能にします。

取得元

ClaimCenter の Claim または Exposure エンティティで取得可能。多くの場合は User オブジェクトに紐づきます(例: Claim.Assignee)。

j.doem.smiths.jones
損害原因
LossCause
損害発生の具体的な原因(例:衝突、火災、水損)。
説明

この属性は、請求が発生した理由(損害原因)の詳細を示します。損害原因は、必要な調査手順や求められる専門家の種類、案件全体の複雑さを大きく左右します。

損害原因別にプロセスを分析すると、見えにくいパターンが浮かび上がります。たとえば「水濡れや水災」の案件は「盗難」に比べて再作業率が高かったり、より多くの専門家の関与が必要になる傾向があるかもしれません。こうしたインサイトは、より専門性が高く効率的な対応手順の策定に役立ちます。

その重要性

請求の性質に関する文脈を提供し、損害原因の違いがプロセスの流れや所要時間に与える影響を分析できます。

取得元

これはClaimエンティティの標準フィールドで、一般に「LossCause」と呼ばれます。

衝突火災水濡れ・水損盗難
請求ステータス
ClaimStatus
その event 時点における請求の全体ステータス(例:Open、Closed、Denied)。
説明

この属性は、請求の大まかな状態を表します。代表的なステータスには「Open」「Closed」「Denied」「Reopened」などがあります。請求の最終ステータスは重要な成果指標です。

Claim Statusの変化を追跡することで、主要なマイルストーンや結果を定義できます。最終的な解決結果の特定、却下率の算出、クローズ後の再開頻度の分析に活用でき、これらはしばしばプロセス上の課題や顧客不満の兆候を示します。

その重要性

請求の結果を示します。却下率、クローズの傾向、請求再開の頻度の分析に不可欠です。

取得元

これはClaimエンティティのコアフィールドで、一般に「State」または「Status」と呼ばれます。

オープンクローズ否認再オープン
請求種別
ClaimType
保険金請求のカテゴリー(自動車、財物、賠責など)。
説明

請求種別は、保険種目や損害の性質にもとづく基本的な区分です。種別が違えば、たどるプロセスも複雑さも、適用される規制も異なります。

分析を請求種別ごとに分けて見ることは、有意義な示唆を得るうえで不可欠です。種目間でのプロセスパフォーマンス比較、種別特有のボトルネックの把握、各カテゴリの特性に合わせた改善施策の設計が可能になります。

その重要性

クレームをタイプ別にセグメントできます。たとえば自動車保険と財物保険ではプロセスや目標値が異なることが多いため、有効です。

取得元

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

自動車保険(個人)商業用財物保険一般賠償責任保険労災補償
SLAステータス
SLAState
請求が解決目標日内にクローズされたかどうかを示します。
説明

この計算属性は、クローズ済み請求ごとのSLA順守状況をカテゴリーで示します。「Claim Closed」のタイムスタンプと「Resolution Target Date」を比較して算出します。

この属性は「解決目標の順守」dashboardを直接支え、「On Time」「Late」といった明快な区分により分析を簡潔にします。フィルタや集計を容易にし、全体のSLA順守率の算出や遅延要因の深掘りに活用できます。

その重要性

SLA順守の可否を明確に区分化し、オンタイム実績のフィルタ、集計、分析を容易にします。

取得元

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

期日どおり遅延
ソースシステム
SourceSystem
データを抽出した元システム。
説明

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

ソースシステムを明示することは、データガバナンス、不整合の原因調査、プロセスの技術的な全体像の把握に不可欠です。中核のプロセスステップと、周辺システムによる補助的な活動を区別する助けにもなります。

その重要性

データの出所(来歴)を特定し、データガバナンスや複数統合システムをまたぐ分析に不可欠な情報を提供します。

取得元

これは通常、データの抽出・変換・ロード(ETL)処理の過程で付与される静的な値です。

Guidewire ClaimCenter v10カスタマーポータル APIDocumentum
事故発生日
LossDate
請求の原因となった事故・損害が発生した日。
説明

Date of Loss は、実際の事故や損害(例:交通事故、物損)が発生した日付です。これは、請求が報告・作成された日付とは異なります。

Date of Loss と「Claim Created」の間のタイムラグ(Reporting Lag)は重要なKPIです。これを分析することで、顧客行動や初動受付(FNOL)チャネルの有効性に関する示唆が得られます。

その重要性

請求の発生起点に関する重要な文脈を提供し、報告ラグ(事故発生から請求登録までの時間)の分析に役立ちます。

取得元

これはClaimエンティティにおける基本的な日付フィールドで、一般に「LossDate」と呼ばれます。

2023-05-102023-04-202023-05-28
保険種目
PolicyType
当該請求に適用される保険の種類(ポリシー種別)。
説明

Policy Type は Claim Type よりも細かな分類で、「火災・家財」「自動車(法人)」「サイバー賠償」など、特定の保険商品を指します。この粒度で見ると、商品ごとのプロセス差が見えてきます。

Policy Type 別に分析すると、商品特有の非効率を明らかにできます。たとえば、発売したばかりの商品はプロセスが未成熟で遅延しやすい、といった示唆です。これらの知見は、商品設計やプロセスの標準化に生かせます。

その重要性

保険商品ごとのプロセス分析を可能にし、ポリシーの条件に起因する取り扱いの差異を特定しやすくします。

取得元

この情報は、Claimに紐づくPolicyエンティティに格納されています。

住宅総合保険商用自動車賠償責任保険運送保険
最終データ更新
LastDataUpdate
ソースシステムからの最終更新または抽出日時を示す timestamp。
説明

この属性は、ソースシステムから直近でデータを取得したタイムスタンプを示します。分析の鮮度を把握するうえで不可欠なメタデータです。

dashboardや各種分析では、この情報を目立つ位置に表示し、ユーザーがデータの新しさを把握できるようにします。インサイトが現状のオペレーションを反映しているのか、過去データに基づくものかを判断する助けになります。

その重要性

データの鮮度を示し、プロセス分析がどの程度最新かを利用者に伝えます。

取得元

この値はETL処理の実行時に生成・保存され、データロードのタイムスタンプを表します。

2024-07-28T04:00:00Z2024-07-29T04:00:00Z
処理時間
ProcessingTime
アクティビティに対して実作業に費やした時間。
説明

Processing Time は、アクティビティに実作業が発生している時間で、Start Time と End Time の差として算出します。待ち時間も含むサイクルタイムとは異なります。

この算出指標は、待ちを除いた純粋な作業時間を切り出せるため、パフォーマンス分析に不可欠です。本当に時間がかかっているステップを正確に見極め、教育やツール改善、プロセス再設計といった施策に結び付けられます。

その重要性

アクティビティの実働時間を測定し、付加価値のある時間と待ち時間を切り分けるのに役立ちます。

取得元

計算フィールド: EndTime - StartTime。両方のタイムスタンプがソースデータに存在することが前提です。

PT8HPT15MP2D
情報再依頼
RepeatedInfoRequestFlag
同一クレームで 'Additional Info Requested' が複数回発生しているかを示すフラグ。
説明

このブールフラグは、1件の請求で「追加情報の依頼」活動が2回以上発生した場合にtrueになります。これは、初期の情報収集が非効率である可能性を示唆します。

この属性は「繰り返し情報依頼率」KPIを直接支えます。不十分な初期聞き取りが大幅な遅延や顧客不満につながる問題を定量化できます。このフラグが立った案件を分析することで、必要情報を一度で漏れなく依頼できるよう、担当者のチェックリストや手順を改善できます。

その重要性

初回の情報収集が不十分で、その後の遅延や手戻りを招いている非効率を特定します。

取得元

ケースごとの 'Additional Info Requested' アクティビティの発生回数をカウントし、Process Mining ツール内で算出します。

truefalse
手戻り
IsRework
前の工程に差し戻される再作業ループに該当するアクティビティかどうかを示すフラグ。
説明

この計算属性は、再作業ループに含まれる活動にフラグを付けます。たとえば、プロセスが「Investigation Completed」から「Investigation Started」に戻った場合、2回目の「Investigation Started」には再作業フラグが付きます。

再作業の特定は、非効率や品質問題を明らかにするうえでの基本です。「再作業・却下の頻度」dashboardはこの指標に依拠し、案件が理想的な処理フロー(happy path)からどの程度外れているかを定量化します。再作業の原因を分析することで、プロセスの品質とスピードを大きく改善できます。

その重要性

手戻りループに含まれるアクティビティを明示的にフラグ化し、プロセスの非効率や品質課題を浮き彫りにします。

取得元

これは、各ケースのアクティビティの順序を分析することで、Process Miningツール内で計算されます。

truefalse
支払金額
PaymentAmount
その支払いアクティビティで実際に支払われた金額。
説明

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

これはProcess Miningの文脈における財務分析に不可欠です。請求ごとの総支払額の把握、金額帯に応じた支払承認リードタイムの分析、プロセスの非効率と財務結果のひもづけに活用できます。たとえば、サイクルタイムが長い案件ほど総支払額が高くなる相関が見つかる場合があります。

その重要性

請求内の財務トランザクションを記録し、支払い額とプロセス内アクティビティとの関係を分析できます。

取得元

クレームに紐づく支払い関連エンティティ(トランザクションやチェックのテーブルなど)に存在します。

4500.00125000.00500.00
管轄州
JurisdictionState
請求を管轄する州/法域。適用される規制要件を定めます。
説明

この属性は、当該請求が処理される法域(例:米国の州などの管轄)を示します。保険規制は法域ごとに大きく異なり、必要な手順、連絡期限、必要書類に影響します。

コンプライアンス監視に不可欠な属性です。法域別にプロセスを分析することで、州ごとの規制要件を満たしているかを確認できます。また、法的制約によって生じるサイクルタイムやプロセス経路の違いを、運用上の非効率と切り分けて説明できます。

その重要性

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

取得元

Claim エンティティの標準フィールド(一般に 'JurisdictionState')。

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

End Time はアクティビティの完了時刻です。とくに「Investigation」や「Document Review」のように所要時間を計測できるタスクで重要になります。多くの Process Mining のアクティビティは瞬間的(StartTime だけで十分)ですが、明確な開始と終了があるものは両方の timestamp を持たせる方が適切です。

この属性により、待ち時間とは切り分けて処理時間を正確に算出できます。ステップ間の遅延を見るだけでなく、どのタスクが時間を要しているかを特定するのに役立ちます。

その重要性

アクティビティの完了までに要する時間を正確に測定し、処理時間と待ち時間を切り分けられます。

取得元

アクティビティの論理的な終了を示す後続イベント(例:ステータスが 'In Progress' から 'Completed' に変わる)を特定して導出する場合があります。

2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
自動化
IsAutomated
アクティビティがシステムによる自動実行か、人手による実行かを示すフラグ。
説明

このブール属性は、システムで実行された活動(例:自動引当の作成、システム生成の通知)と、査定担当者が手作業で行った活動を区別します。

この属性の分析は、請求プロセスの自動化レベルを理解する鍵となります。手作業が集中するホットスポットの特定、STP(straight-through processing/ノータッチ処理)の効果測定、現在人手で行っている反復的・ルールベース作業の自動化余地の発見に役立ちます。

その重要性

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

取得元

多くの場合は導出(推定)が必要です。たとえば、汎用の 'system' ユーザーによって記録されたイベントは、自動処理としてフラグ付けできます。

truefalse
解決目標日
ResolutionTargetDate
社内規定や法令上の SLA に基づく、請求の解決期限。
説明

Resolution Target Date は請求のクローズ期限で、法域、請求タイプ、ポリシー条件などに基づき設定されます。パフォーマンスとコンプライアンスを測る基準点となります。

この属性は、SLA順守の dashboard や KPI を構築するうえで不可欠です。実際の「Claim Closed」日と目標日を比較することで、遅延案件の自動フラグ付け、期限内達成率の計測、目標達成に苦戦している請求タイプや部門の特定が可能になります。

その重要性

これは、Service Level Agreement(SLA)の順守を測定し、遅延リスクの高い請求を特定するためのベンチマークです。

取得元

これはカスタム項目、またはClaimCenterで設定したビジネスルールから派生した値の場合があります。特定の請求指標に紐づくこともあります。

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

この属性は、請求者が報告した損害額(申告損害額)を表します。多くの場合は初期見積であり、調査や引当設定の進行に伴って変更されることがあります。

申告損害額の分析は、財務インパクトによる案件のセグメンテーションに役立ちます。高額案件は低額案件に比べ、より厳格で複雑なプロセスをたどるのが一般的です。金額帯ごとのプロセスを比較することで、小口案件の迅速化や大口案件への統制強化といった改善機会が見えてきます。

その重要性

高額クレームはより複雑なプロセスになる場合があるため、金額帯でのセグメンテーションを可能にします。

取得元

この情報は単一フィールドに存在せず、exposureに記録された初期損害見積から導出される場合があります。

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

この属性は、担当アジャスター(査定担当)が所属する部門・チーム(例:自動車保険金請求、火災・財物保険金請求、特別調査部門)を示し、プロセスの組織的な文脈を与えます。

部門別の分析は、組織レベルでのプロセスのパフォーマンスを把握するうえで重要です。部門間の引き継ぎ遅延の特定、チーム間の効率比較、請求組織全体でのより効果的なリソース配分に役立ちます。

その重要性

組織的な文脈を付与し、チーム間のパフォーマンス比較や、部門間のハンドオフ課題を可視化します。

取得元

この情報は通常、ClaimCenter内の担当ユーザーまたはグループのプロファイルに紐づいています。

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

保険金請求プロセスのアクティビティ

正確なプロセスディスカバリーと分析のために、イベントログに記録すべき保険金請求プロセスの主要ステップと重要なマイルストーンです。
7 推奨 7 任意
アクティビティ説明
エクスポージャを作成
このアクティビティは Exposure の作成を示します。Exposure は、請求内の個別の潜在債務や損害タイプ(例:車両損害、傷害)を表します。Guidewire における明示的な event です。
その重要性

エクスポージャは、クレームのセグメンテーションと分析の基礎となる概念です。作成タイミングを追うことで、複雑さや損害種別に応じたプロセスの違いを把握できます。

取得元

cc_exposure テーブルに新規レコードが作成された際の CreateTime から取得します。各レコードは単一の Claim ID に紐づきます。

取得

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

イベントタイプ explicit
初期引当設定
エクスポージャに対する最初の引当取引が作成されたことを示し、請求の潜在コストを見積もります。これは重要な財務イベントであり、明示的に記録します。
その重要性

このマイルストーンは、財務分析や潜在負債の評価スピードを把握するうえで重要です。遅延は財務計画やレポーティングにも影響します。

取得元

このイベントは、請求のexposureに紐づく最初の cc_reserveline レコードが作成された時点を起点として取得します。トランザクションの CreateTime がイベントのタイムスタンプになります。

取得

対象クレームの各エクスポージャに紐づくすべての引当ラインの作成タイムスタンプの最小値を取得します。

イベントタイプ explicit
支払命令発行
このアクティビティは支払プロセスの最終ステップで、支払いが正式に発行され、財務システムへ送られます。明示的に記録される金融取引です。
その重要性

支払実行プロセスの効率を測るうえで重要なアクティビティです。承認の遅延と、実際の資金の発行遅延とを切り分けて評価できます。

取得元

IssueDate の値、または cc_check / cc_transaction エンティティでステータスが 'Issued' または 'Submitted' に変わった時点から取得します。多くの場合、明確なタイムスタンプが付いたイベントです。

取得

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

イベントタイプ explicit
支払承認
示談・支払いの正式承認を表します。重要な監査イベントであり、権限者がトランザクションを承認した時点で明示的に記録されます。
その重要性

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

取得元

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

取得

特定の支払トランザクションで、ステータスが 'Approved' に変わるイベントを追跡します。

イベントタイプ explicit
請求のクローズ
すべてのアクティビティと支払が完了した後に請求が正常にクローズしたことを示します。請求の主要ステータスの変更から推定する、主たる成功終了イベントです。
その重要性

主要な終了イベントとして、エンドツーエンドのリードタイム算出や SLA 遵守の測定に不可欠です。クレームライフサイクルの完了を示します。

取得元

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

取得

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

イベントタイプ inferred
請求の不承認
請求を不承認(否認)とする最終決定を表し、プロセスの終点となります。請求のステータスがクローズ状態になり、理由が 'Denied' に設定されたことから推定します。
その重要性

これは重要なアウトカムイベントです。却下に至る頻度・理由・プロセス経路を分析することで、受付、調査、約款解釈といった領域の課題を洗い出せます。

取得元

これは、cc_claim テーブルの State フィールドが 'Closed' に変わり、かつ CloseReason フィールドが 'Denied' などの値であることから推定します。イベントのタイムスタンプは CloseDate です。

取得

ステータスが 'Closed' に変更され、理由コードが否認を示すレコードを抽出します。

イベントタイプ inferred
請求作成
このアクティビティは First Notice of Loss(FNOL)にあたり、Guidewire ClaimCenter で新しい請求レコードが正式に作成されたことを示します。新規の Claim エンティティが初めてデータベースに保存されたときに明示的に記録されます。
その重要性

主要な開始イベントとして、保険金請求のエンドツーエンドのリードタイム測定に不可欠です。以降のパフォーマンスや所要時間に関する KPI の基準となります。

取得元

これは cc_claim テーブルの CreateTime から取得する明示的なイベントです。ユニークなClaim IDを持つ新規レコードの作成がイベントのトリガーになります。

取得

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

イベントタイプ explicit
Additional Info Received
追加情報の依頼が完了したことを示します。対応する情報依頼の 'Activity'(タスク)が 'Completed' に更新された時点で記録します。
その重要性

これは「追加情報収集のサイクルタイム」KPIの終点です。依頼から受領までの時間が長いことは、請求プロセスにおける典型的な遅延要因です。

取得元

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

取得

外部情報を依頼するタスクの完了時点のタイムスタンプを取得します。

イベントタイプ explicit
Additional Info Requested
請求者または第三者に対して、追加情報や書類を求める依頼を表します。通常、ClaimCenter で作成される明示的な 'Activity'(タスク)として記録されます。
その重要性

「Additional Info Gathering Cycle Time」KPI の起点となるアクティビティです。発生頻度が高い場合、FNOL の不備や情報収集の非効率が疑われます。

取得元

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

取得

外部情報を依頼するタスクの作成を検出します。

イベントタイプ explicit
支払額を算出
支払金額は確定したが、まだ承認されていない時点を表します。「Pending Approval」状態の Payment が作成されたことから推定できます。
その重要性

査定から支払への移行を示します。承認チェーンの遅延を可視化する 'Payment Authorization Lead Time' KPI の測定起点になります。

取得元

これは、初期ステータスが 'Approved' 前の 'Pending Approval' などである cc_check または cc_transaction レコードの CreateTime に基づきます。

取得

事前承認ステータスの支払いまたはトランザクションレコードが作成されたことを検出します。

イベントタイプ inferred
調査開始
請求またはエクスポージャの調査フェーズの正式な開始を示します。これは多くの場合、Guidewire で最初の調査関連の 'Activity'(タスク)が作成されたことから推定します。
その重要性

重要で、しばしば長期化するフェーズの開始を示します。調査開始までの時間と、調査そのものの所要時間を分析することで、主要なボトルネックが明らかになります。

取得元

これは、ActivityPattern が調査関連(例: 'Initial Investigation', 'Contact Witness')の cc_activity レコードの CreateTime に基づきます。

取得

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

イベントタイプ inferred
請求の再開
追加作業のため、請求が「Closed」から「Open」に戻されることを表します。このイベントは特定のステータス変更の並びから推定します。
その重要性

このアクティビティは手戻りを意味します。再オープンする請求が多い場合、初期対応や支払判断の不備、見落とし、その他のプロセス不全が疑われ、コスト増と非効率につながります。

取得元

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

取得

クローズからオープンへの遷移を検知できるよう、請求のマスターステータスを監視します。

イベントタイプ inferred
請求の割り当て
請求が特定のユーザー(アジャスター)またはグループに割り当てられることを表します。通常は、Claim エンティティ上の割り当てフィールドの変更を監視して推定します。
その重要性

アサインの追跡は、担当者のワークロード分析、ルーティングのボトルネック特定、割り当て担当者の初回対応までの時間計測に不可欠です。

取得元

これは、cc_history テーブルで特定の Claim ID に紐づく AssignedUser または AssignedGroup フィールドの変更を追跡することで推定します。変更のタイムスタンプがイベント発生時刻です。

取得

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

イベントタイプ inferred
責任判断完了
個別の損害(Exposure)について、過失や賠償責任の判断が確定した時点を表します。通常は Exposure エンティティのステータス変更から推定します。
その重要性

これは、示談および支払いフェーズへのゲートとなる重要な意思決定のマイルストーンです。この決定に至るまでの時間を分析することで、調査・査定段階のボトルネックを特定できます。

取得元

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

取得

エクスポージャの状態や責任ステータスの更新を、監査ログや履歴テーブルで監視します。

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

抽出ガイド

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