請求処理データテンプレート
請求処理データテンプレート
- 収集を推奨する属性
- 追跡する主なアクティビティ
- Duck Creek Claimsからのデータ抽出ガイド
請求処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 請求について、特定の時点で発生した業務上のアクティビティまたはイベントの名前です。 | ||
| 説明 この属性は、「保険金請求を受け付け」「損害査定担当者を割り当て」「支払いを実行」など、請求プロセスで実行された具体的な手順やタスクを表します。各アクティビティは、請求の全過程における個別の時点を示します。 アクティビティの順序や頻度の分析は、プロセスマイニングの中核です。プロセスモデルの発見、ボトルネックの特定、手戻りループの検出、標準モデルに対するプロセス逸脱の分析が可能になります。 重要な理由 アクティビティ名はプロセスフローの各ステップを定義するもので、請求プロセスの発見、分析、モニタリングの基礎となります。 入手先 通常、Duck Creek Claims内のイベントログ、トランザクション名、またはステータス変更記録から取得します。複数のソースフィールドやテーブルからのマッピングが必要になる場合があります。 例 保険金請求を受け付け損害査定担当者を割り当て調査を開始支払いを実行保険金請求を終了 | |||
| イベント時刻 EventTime | 特定のアクティビティまたはイベントが発生した日時を示すタイムスタンプです。 | ||
| 説明 イベント時刻には、請求の全過程で記録された各アクティビティの正確な日時が示されます。この時間情報は、パフォーマンス分析に欠かせません。 分析では、このタイムスタンプを使ってアクティビティ間のサイクルタイムを算出し、待ち時間を特定し、ケース全体の所要時間を測定し、期間ごとのプロセスパフォーマンスを分析します。時間に基づくプロセス指標の基礎となるデータです。 重要な理由 サイクルタイムや所要時間など、時間に基づくすべての指標の算出に欠かせないタイムスタンプです。パフォーマンス分析やボトルネックの特定に役立ちます。 入手先 Duck Creek Claimsのイベントログまたはトランザクションログに関連付けられた標準的なタイムスタンプフィールドです。「CreateDate」「Timestamp」「EventDate」などのフィールドを確認してください。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 請求ID ClaimId | 個々の保険金請求を識別する一意のIDで、主要なケース識別子として使われます。 | ||
| 説明 請求IDは、提出から終了まで、1件の保険金請求に関連するすべてのイベントとアクティビティを結び付ける基本キーです。これにより、請求の全プロセスを一貫して追跡できます。 プロセスマイニング分析では、この属性を使ってケースビューを作成します。分析担当者は各請求の全過程を追跡し、エンドツーエンドのサイクルタイムを測定し、プロセスのバリアントを分析できます。 重要な理由 関連するすべてのイベントを結び付ける基本的なケースIDです。請求の全プロセスをエンドツーエンドで把握できます。 入手先 Duck Creek Claimsのメインの請求エンティティまたはテーブルにある主キーです。具体的なテーブル名とフィールド名は、システムの文書をご確認ください。 例 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| 割り当て済み損害査定担当者 AssignedAdjuster | 各アクティビティで請求を担当する損害査定担当者の名前またはIDです。 | ||
| 説明 この属性は、アクティビティを実行するユーザーまたはリソースを示します。請求の全過程で、別の担当者やチームに引き継がれるたびに値が変わる場合があります。 リソースパフォーマンス、業務量の配分、引き継ぎを分析するうえで欠かせません。担当者ごとの処理件数や業務量の差、ボトルネックを確認するダッシュボードでは、この属性を使って個人ごとの業務の割り当てや処理状況を把握します。 重要な理由 リソースパフォーマンス、業務量の配分、連携の傾向を分析し、ボトルネックや研修が必要な領域の特定に役立ちます。 入手先 Duck Creek Claimsの文書をご確認ください。請求タスク、イベント、またはメインの請求エンティティに関連するテーブルで、ユーザー、所有者、担当者の各フィールドを探してください。 例 John SmithJane DoeRobert Brownadjuster_1138 | |||
| 損害額 LossAmount | 請求で報告された損害の推定額または実際の金額です。 | ||
| 説明 この属性は、請求に関連する損害の初期推定額を示します。重要な財務指標であり、請求の振り分け、重大度、必要な調査レベルに影響することがよくあります。 分析では、損害額を使って請求を分類し、金銭的な影響とプロセスの動きとの関係を把握します。たとえば、高額の請求では異なる経路をたどったり、サイクルタイムが長くなったりする場合があります。業務プロセスのデータを理解するための重要な財務情報です。 重要な理由 請求の金銭的な背景を把握し、金額が処理経路、所要時間、結果に与える影響を分析できます。 入手先 Duck Creek Claimsの文書を参照してください。請求に関する主要な財務項目で、「報告損害額」や「初期準備金」と呼ばれることもあります。 例 1500.0025000.50125000.00 | |||
| 請求ステータス ClaimStatus | 特定の時点における請求の全体的な状態です。オープン、保留中、クローズなどがあります。 | ||
| 説明 請求ステータスは、ライフサイクルにおける請求の現在の状態を示します。プロセス全体のどの段階にあるかを大まかに把握できます。 この属性は、請求在庫の概要を確認したり、ケースを絞り込んだりする際に役立ちます。特に、請求の最終結果(例:「クローズ・支払い済み」「クローズ・却下」)を特定するうえで重要です。結果分析や却下率の把握に欠かせません。 重要な理由 請求の現在の状態と最終結果を把握できます。結果分析やケースの絞り込みに役立ちます。 入手先 Duck Creek Claimsの文書を参照してください。メインの請求レコードにある基本項目です。 例 オープン保留中・情報待ちクローズ・解決済みクローズ・却下 | |||
| 請求の重大度 ClaimSeverity | 低・中・高など、請求の金銭的または業務上の複雑さを分類したものです。 | ||
| 説明 請求の重大度は、想定される影響や複雑さを示します。初期の損害見積もり、事故の性質、または事前に定めた業務ルールに基づいて決まる場合があります。 重大度の高い請求は、通常、処理手順が多く、所要時間が長くなり、専門的なリソースを必要とするため、この属性はパフォーマンス分析に欠かせません。重大度別に重要業績評価指標(KPI)を区分すると、現実的な目標を設定し、複雑さがプロセスの効率や結果に与える影響を把握できます。 重要な理由 請求を複雑さで区分し、より詳細なパフォーマンス分析や、サイクルタイムとコストの現実的なベンチマークに役立ちます。 入手先 Duck Creek Claimsの文書をご確認ください。専用フィールドがある場合と、初期の損害準備金額から算出する場合があります。 例 低中程度高壊滅的 | |||
| 請求種別 ClaimType | 自動車、財物、賠償責任など、保険金請求の分類です。 | ||
| 説明 請求種別は、保険種目または損害の性質に基づいて請求を分類します。請求データを区分して分析するための基本的な切り口です。 この属性を使うと、請求種別ごとにプロセスパフォーマンスを比較できます。たとえば、「自動車・全損」の請求は、「財物・水濡れ損害」の請求とはプロセスも重要業績評価指標(KPI)も大きく異なります。請求種別ごとに分析することで、比較に必要なコンテキストが得られ、より適切なパフォーマンス比較や、状況に応じたプロセス改善に役立ちます。 重要な理由 請求種別によってプロセス、サービスレベル合意(SLA)、複雑さが異なることが多いため、分析を区分するうえで重要な切り口です。 入手先 Duck Creek Claimsの文書をご確認ください。メインの請求レコードにある基本属性です。 例 個人向け自動車保険・衝突企業向け財物保険・火災労働者災害補償一般賠償責任 | |||
| 部門 Department | 各時点でアクティビティまたは請求を担当する部門やチームです。 | ||
| 説明 この属性は、「初期受付」「調査部門」「示談チーム」など、請求を担当する機能別グループまたは部門を示します。プロセスフローを組織の観点から把握できます。 部門別の分析は、プロセスの全体的なパフォーマンスを理解するうえで重要です。部門間のボトルネックを特定し、チーム単位の効率を測定し、組織内で業務がどのように進むかを把握できます。 重要な理由 機能別のパフォーマンスを分析し、部門間の引き継ぎやチーム固有のボトルネックを明らかにできます。 入手先 Duck Creek Claimsの文書をご確認ください。この情報は、割り当てられたユーザーのプロフィール、またはキューやワークグループの割り当てに関連付けられていることがよくあります。 例 自動車保険金請求大規模損害の火災保険金請求特別調査部門支払い処理 | |||
| ソースシステム SourceSystem | イベントデータの抽出元となるシステムです。 | ||
| 説明 この属性は、請求データの発生元であるソースアプリケーションを示します。この場合、値は常に「Duck Creek Claims」です。 すべてのデータが1つのシステムから取得される場合は不要に見えるかもしれませんが、データガバナンスや追跡可能性の確保に欠かせません。また、将来、複数のシステムからデータを統合する場合にも役立ちます。データの発生元と構造を把握するためのコンテキストを提供します。 重要な理由 データの来歴とコンテキストを把握できます。データガバナンスや問題の調査に欠かせず、特に複数のシステムを連携する環境で役立ちます。 入手先 通常、データの発生元を示すラベルとして、データの抽出・変換時に追加する固定値です。 例 Duck Creek Claims | |||
| 保険証券番号 PolicyNumber | 請求の対象となる保険契約を識別する一意の番号です。 | ||
| 説明 この属性によって、請求を元の保険契約に関連付けます。請求に関係する補償内容、契約条件、顧客の情報を把握できます。 プロセスフロー分析で直接使わない場合もありますが、保険証券番号を加えることで請求データを充実させられます。保険契約や顧客のデータと結合し、顧客セグメント、保険契約の種類、契約期間によってプロセスの実績がどう異なるかを分析できます。これにより、事業をより広い視点から捉えられます。 重要な理由 請求を顧客と保険契約に関連付け、顧客セグメントや保険契約の種類ごとにプロセスの実績を分析できます。 入手先 Duck Creek Claimsの文書を参照してください。メインの請求エンティティにある標準的な参照項目です。 例 PA-987654321CP-123456789WC-555444333 | |||
| 最終データ更新日時 LastDataUpdate | ソースシステムからデータを最後に更新した日時を示すタイムスタンプです。 | ||
| 説明 この属性は、データセットが最後に更新された日時を示します。分析対象のデータがどの程度新しいかを確認する基準になります。 ダッシュボードや分析では、インサイトがいつ時点のデータに基づくかを利用者に伝えるために使います。最新のトランザクションがプロセスビューに含まれているかどうかを判断する際にも役立ちます。 重要な理由 データの新しさを利用者に伝え、分析結果の解釈や適切なタイミングでの意思決定に役立ちます。 入手先 データの抽出、変換、ロード(ETL)処理中に生成され、通常はデータセットのメタデータに保存されます。 例 2024-05-21T02:00:00Z | |||
| 却下理由 RejectionReason | 請求が却下または拒否された具体的な理由です。 | ||
| 説明 請求を却下する決定が下された際、この属性にその理由が記録されます。通常、あらかじめ定義されたコードや説明から選択します。 却下理由の分析は、「請求判断と却下に関するインサイト」ダッシュボードで重要な役割を果たします。申請に共通する問題、不正の可能性があるパターン、保険契約の文言が不明確な箇所を特定できます。こうした分析結果は、受付プロセスや引受ルールの改善に役立ちます。 重要な理由 請求が却下された理由を明らかにし、受付プロセスの改善、不備のある申請の削減、研修機会の特定につながる具体的なインサイトを得られます。 入手先 Duck Creek Claimsの文書を参照してください。通常、請求ステータスが「却下」などに変更された際に、この項目が入力されます。 例 補償対象外の事故保険契約の期限切れ重複請求不正の疑い | |||
| 手戻りあり IsRework | アクティビティが手戻りループの一部かどうかを示す計算済みフラグです。 | ||
| 説明 他の異なるアクティビティが発生した後に、同じ請求でアクティビティが繰り返された場合、この真偽値属性はtrueになります。たとえば、プロセスが「損害評価」から「調査開始」に戻る場合です。 この属性は、手戻りの定量化と分析に欠かせません。「請求の手戻り率」KPIや「請求の手戻りと再処理パターン」ダッシュボードで、手戻りが発生したアクティビティやケースを直接絞り込み、強調表示できます。プロセスの非効率や品質上の問題を特定するのに役立ちます。 重要な理由 アクティビティ単位で手戻りを定量化し、プロセスの非効率が生じる原因と影響を測定、可視化、分析できます。 入手先 ソースシステムの項目ではありません。ケース内でアクティビティの並びが繰り返されていることを検出するアルゴリズムを使い、データ準備時に算出します。 例 truefalse | |||
| 期限内解決 IsOnTimeResolution | 請求が解決目標日までにクローズされたかどうかを示す計算済みフラグです。 | ||
| 説明 この真偽値属性は、請求の「請求クローズ」アクティビティのタイムスタンプと「ResolutionTargetDate」を比較して算出します。各請求が期限内(true)か期限超過(false)かを示します。 この属性は、「期限内の請求解決率」KPIを直接支えます。ダッシュボードでSLAの達成状況を簡単に集計・可視化できるほか、期限を超過した請求に共通する特徴(請求の種類、部門、プロセス経路など)を特定するためのドリルダウン分析にも役立ちます。 重要な理由 請求ごとのSLA遵守状況を直接測定でき、期限超過の請求を絞り込んで根本原因を分析できます。 入手先 ソースシステムの項目ではありません。データ準備時に、最終アクティビティのタイムスタンプと「ResolutionTargetDate」項目を比較して算出します。 例 truefalse | |||
| 示談金額 SettlementAmount | 請求の解決にあたり、最終的に合意した金額です。 | ||
| 説明 この属性には、算出され、支払いが承認された示談金額が記録されます。支払いが発生する請求ごとの重要な結果指標です。 財務分析や、「支払い承認から支払い実行までの時間」などのダッシュボードに欠かせません。初期の「損害額」と比較することで準備金の精度を分析でき、請求プロセスの財務的な結果を把握するうえでも重要です。 重要な理由 請求に関する重要な財務結果を示します。財務報告や初期損害見積もりの精度分析に欠かせません。 入手先 Duck Creek Claimsの文書を参照してください。通常、この情報は請求に関連付けられた財務取引または支払い関連のテーブルに保存されています。 例 1450.7522000.00115800.20 | |||
| 終了時刻 EndTime | アクティビティが完了した時刻を示すタイムスタンプです。 | ||
| 説明 この属性は、アクティビティの完了時刻を示します。StartTimeがアクティビティの開始時刻を示すのに対し、EndTimeはそのタスクの所要時間を算出するための終了時刻を示します。 プロセスマイニングでは、アクティビティの開始時刻と終了時刻の両方があると、実績をより詳しく分析できます。タスクの実作業時間である「処理時間」と、タスク間に費やされた「待機時間」を正確に算出できます。この区別は、ボトルネックを正確に特定するうえで欠かせません。 重要な理由 アクティビティの処理時間を正確に算出し、実作業時間と待機時間を区別できます。ボトルネック分析の精度向上に役立ちます。 入手先 イベントログに独立したタイムスタンプ項目がある場合はそこから取得できます。また、同じケース内で次に発生するアクティビティのStartTimeから算出することもできます。 例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| 自動処理 IsAutomated | 人の介在なしにシステムがアクティビティを自動実行したかどうかを示す真偽値です。 | ||
| 説明 このフラグは、人が完了したタスクと、システムが自動実行したタスクを区別します。自動通知、初期データ検証、人手を介さずに処理が完了する工程などが該当します。 この属性を分析すると、請求プロセスの自動化の度合いを把握できます。自動化施策の効果を測定し、さらなる自動化の機会を見つけるとともに、自動処理が後続工程に問題を起こさず、想定どおりに動作しているかを確認できます。 重要な理由 自動化が効率やコストに与える影響を測定し、人手を介さずに処理を完了できる工程を見つけるのに役立ちます。 入手先 イベントに関連付けられた「ユーザー」(例:「SYSTEM」や「BATCH」)から推定するか、イベントレコードの専用フラグから取得できる場合があります。 例 truefalse | |||
| 解決目標日 ResolutionTargetDate | SLAまたは社内目標に基づき、請求の解決が見込まれる目標日です。 | ||
| 説明 この属性には、請求をクローズする期限が記録されます。日付は、規制要件、サービスレベル契約(SLA)、社内の重要業績評価指標(KPI)などに基づいて設定され、請求の種類や重大度によって異なる場合があります。 この日付は、「期限内の請求解決率」KPIの算出と、「請求解決目標の達成状況」ダッシュボードの基礎となります。SLA違反のリスクがある請求を事前に把握し、作業の優先順位を決めるのに役立ちます。 重要な理由 サービスレベル契約(SLA)や社内目標に対する実績を測定できます。顧客満足度とコンプライアンスに直接影響する指標です。 入手先 Duck Creek Claimsの文書を参照してください。専用のSLA日付項目がある場合と、請求の申請日および業務ルールに基づいて算出する場合があります。 例 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
請求処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 保険金請求を却下 | 請求が正式に却下される、プロセスのもう1つの終了パターンを示すアクティビティです。請求の最終ステータスが「却下」または「拒否」に設定されたときに記録されます。 | ||
| 重要な理由 個別に分析すべき重要な結果です。請求が却下される理由や時期を把握することで、受付プロセスの改善やコンプライアンスの管理につながります。 入手先 請求エンティティテーブルで、請求の最終ステータスが「却下」「拒否」または「支払いなしで終了」に変わった時刻から推定します。 記録 請求の最終ステータスが却下理由に設定されたことから推定します。 イベントタイプ inferred | |||
| 保険金請求を受け付け | 保険会社が事故の第一報(FNOL)を受け取ったことを示す、最初のイベントです。通常、代理店または契約者がシステムに請求の初期情報を入力した際に、明示的なトランザクションとして記録されます。 | ||
| 重要な理由 このアクティビティは、保険金請求の全プロセスの開始を示します。このイベントから後続のイベントまでの時間を分析することは、処理全体の所要時間や受付業務の効率を把握するうえで重要です。 入手先 通常、Duck Creek Claimsで新しい請求レコードが初めて作成されたときに、請求またはFNOLのログテーブルに明示的なイベントとして記録されます。 記録 新しい請求レコードの初回作成時に記録されるイベント。 イベントタイプ explicit | |||
| 保険金請求を終了 | 支払いの実行後、または請求の示談成立後に、請求ファイルを事務的に終了する最終アクティビティです。最終ステータスが「終了」に更新されたときに記録されます。 | ||
| 重要な理由 プロセスが正常に終了したことを示します。「エンドツーエンドの平均請求サイクルタイム」など、主要な所要時間指標を算出する際の終点です。 入手先 請求のメインデータテーブルで、最終ステータスが「終了」または「示談成立」に変わった時刻から推定します。 記録 請求の最終ステータスが「終了」に設定されたことから推定します。 イベントタイプ inferred | |||
| 支払いを実行 | 請求の支払いに関する財務トランザクションが実行されたことを示すアクティビティです。小切手、電子資金振替(EFT)などで支払いが送金された際に生成される、明確なイベントです。 | ||
| 重要な理由 承認された請求に対する金銭的な支払いが完了したことを示します。「支払いを承認」してから「支払いを実行」するまでの時間から、財務部門の処理効率を把握できます。 入手先 Duck Creek Claimsの財務トランザクションテーブルから取得します。ここには、特定のトランザクションコードと時刻を伴うすべての送金が記録されます。 記録 支払い処理時に、個別の財務トランザクションログが作成されます。 イベントタイプ explicit | |||
| 支払いを承認 | 算出した示談金額の支払いを正式に承認したことを示します。管理者または別の権限者が関与する独立した手順であることが多く、明示的な承認トランザクションとして記録されます。 | ||
| 重要な理由 支払い前の重要な管理ポイントであり、ボトルネックになる可能性もあります。「請求の決定」からこの時点までの期間は、重要業績評価指標(KPI)である「平均請求承認時間」で測定します。 入手先 通常、ワークフローまたは財務モジュールで、特定の権限を持つユーザーが支払いを承認した際に明示的なイベントとして記録されます。承認ログで確認できます。 記録 ワークフローまたはトランザクションログに記録される明示的な承認イベント。 イベントタイプ explicit | |||
| 請求の決定を行う | 「承認」「一部承認」「却下」など、請求に対する正式な決定を示すアクティビティです。最終決定のステータスへの変更から推定される、重要なマイルストーンです。 | ||
| 重要な理由 意思決定における重要なマイルストーンです。この時点までにかかる時間と決定結果は、プロセスの分析や効率を評価するうえで中心となります。 入手先 専用の「請求決定」または「請求ステータス」フィールドが「承認」や「却下」などの最終状態に変わったことから推定し、その変更時刻を記録します。 記録 請求の主ステータスまたは決定フィールドの更新から推定します。 イベントタイプ inferred | |||
| 保険金請求を登録 | 提出された請求が正式に受理・登録され、一意の請求IDが割り当てられたことを示します。通常、初期データの検証後に発生する自動システムイベントです。 | ||
| 重要な理由 請求の開始を正式に記録し、損害査定担当者の割り当てなど、後続のプロセスを開始します。提出から登録までの時間は、初期データの品質やシステム負荷の問題を示す場合があります。 入手先 メインの請求エンティティテーブルで、主請求IDが生成された時刻と、請求ステータスが「保留中」または「提出済み」から「オープン」または「登録済み」に変わった時刻から推定します。 記録 主請求レコードの作成時刻、またはステータスが「オープン」に変わった時刻から算出します。 イベントタイプ inferred | |||
| 初回レビューを完了 | 割り当てられた損害査定担当者が、請求の最初の詳細なレビューを完了したことを示します。通常、割り当て後に請求ステータスが「割り当て済み」から「レビュー中」や「調査中」などに変わったことから推定します。 | ||
| 重要な理由 このマイルストーンから、担当者が最初の対応を行うまでの時間を測定でき、業務の滞留を把握する手がかりになります。担当者が関与する最初の主要な確認時点です。 入手先 請求ステータスフィールドが「初回レビュー完了」や「情報待ち」などに変わったことから推定します。ステータス変更の時刻を使用します。 記録 担当者の割り当て後に請求ステータスフィールドが変更されたことから推定します。 イベントタイプ inferred | |||
| 損害査定担当者を割り当て | 登録済みの請求に損害査定担当者または処理担当者が割り当てられたことを記録するイベントです。システムに割り当てが記録され、明確な引き継ぎ時点と請求処理の担当者が定まります。 | ||
| 重要な理由 リソース配分や担当者の業務量を分析し、請求の割り当てに遅れがないかを特定するうえで重要です。待ち時間が発生する可能性のある、主要な引き継ぎ時点でもあります。 入手先 メインの請求データテーブルにある「Assigned Adjuster」フィールドの更新から追跡します。このフィールドの履歴または監査ログに時刻が記録されます。 記録 担当者フィールドへの入力時、または値の変更時に監査証跡へ記録されます。 イベントタイプ explicit | |||
| 損害額を評価 | 調査結果に基づいて支払準備金が設定または更新された時点を示すマイルストーンです。請求による金銭的影響の見積もりを表し、準備金額が入力または調整されたときに記録されます。 | ||
| 重要な理由 プロセスにおける重要な財務上の確認時点です。いつ行われたかを分析することで、金額の評価にかかる時間やその精度を把握できます。 入手先 通常、Duck Creek Claims内の請求の財務トランザクションログまたは準備金履歴テーブルに、明示的な財務トランザクションとして記録されます。 記録 請求の準備金を設定または更新した財務トランザクションの記録。 イベントタイプ explicit | |||
| 示談金額を算出 | 承認後、最終的な示談金額または支払額を算出するアクティビティです。明示的な手順として記録される場合と、システムの財務モジュールで支払額が確定したことから推定される場合があります。 | ||
| 重要な理由 このアクティビティは、重要業績評価指標(KPI)である「示談の手戻り率」の測定に欠かせません。同じ請求で複数回発生している場合、示談段階での非効率、ミス、または交渉が考えられます。 入手先 明示的なトランザクションログへの記録、または請求の財務データにある「示談金額」フィールドの更新から推定できます。このフィールドの監査ログが主な情報源です。 記録 最終的な支払額を算出して保存したときに記録されるイベント。 イベントタイプ explicit | |||
| 調査を完了 | 必要な事実がすべて集まり、調査活動が終了したことを示します。通常、請求ステータスが「調査中」から「決定待ち」などの意思決定段階に変わったことから推定します。 | ||
| 重要な理由 調査の完了は、意思決定と示談の段階に進むための重要なマイルストーンです。ここでの遅れは、後続のプロセスに大きく影響します。 入手先 請求ステータスが「調査」状態から「レビュー」または「決定」状態に更新された時刻から推定します。 記録 調査活動の終了を示す請求ステータスの変更から算出します。 イベントタイプ inferred | |||
| 調査を開始 | 請求の正式な調査段階が始まったことを示すアクティビティです。多くの場合、請求ステータスが「調査中」などに変わったことから推定します。 | ||
| 重要な理由 リソースを多く必要とする段階の開始を示します。調査期間の測定は、重要業績評価指標(KPI)である「平均調査期間」の算出に欠かせず、プロセスの重要な部分の管理にも役立ちます。 入手先 メインの請求ステータスフィールドが「調査進行中」または「検査待ち」に更新された時刻から推定します。 記録 調査活動の開始を示す請求ステータスの変更から算出します。 イベントタイプ inferred | |||
| 追加情報を依頼 | 損害査定担当者が追加情報を必要と判断し、契約者または第三者に依頼したときに発生するアクティビティです。通常、システムの通信または連絡管理モジュールに関連付けられた明示的なイベントです。 | ||
| 重要な理由 このアクティビティの頻度が高い場合、初期のデータ収集に問題がある可能性があります。また、大きな待ち時間が生じ、全体のサイクルタイムにも影響します。 入手先 送信した連絡(書簡、メールなど)のログ、またはDuck Creek Claimsの「情報依頼」トランザクションから取得します。 記録 情報依頼の連絡またはタスクが作成されたときに記録されます。 イベントタイプ explicit | |||
| 追加情報を受領 | 依頼した情報を受け取り、請求処理を再開できる状態になったことを示します。担当者が手動で記録する場合と、デジタルポータルから情報が提出された際に自動で記録される場合があります。 | ||
| 重要な理由 「情報を依頼」してから「情報を受領」するまでの時間は、重要な待ち時間です。この期間を分析すると、外部への依存や連絡上のボトルネックを特定できます。 入手先 文書管理システムとの連携による明示的なイベント、担当者による手動のログ入力、または書類の受領時に担当者が行うステータス変更から取得できます。 記録 書類のアップロード時、または担当者による手動入力時にイベントとして記録されます。 イベントタイプ explicit | |||
データ抽出ガイド
ステップ
- Duck Creek Data Hub Configuration Utilityへのアクセス:Duck Creek環境にログインし、Data Hubアプリケーションを開きます。データのエクスポート設定を作成または変更するには、適切な権限が必要です。
- 新しいデータエクスポートジョブの作成:Data Hubユーティリティで、新しいエクスポートジョブの作成を開始します。ProcessMind_Claims_Event_Log_Exportなど、内容がわかる名前を付けます。
- データソースの定義:ジョブがプライマリのData Hub SQLデータベースに接続するよう設定します。関連するスキーマへの読み取りアクセス権を持つユーザーのサーバー名、データベース名、認証情報を入力します。
- 抽出クエリの入力:エクスポートジョブのクエリ定義セクションを開きます。下記のクエリセクションにあるスクリプト全体をコピーし、クエリエディターに貼り付けます。
- クエリパラメーターの設定:設定画面でパラメーターセクションを開きます。クエリ内の@StartDateおよび@EndDateパラメーターに値を設定し、抽出する期間を指定します。例:'2023-01-01'および'2023-12-31'。
- 出力列のマッピング:出力ファイルの設定を行います。SELECT文で指定した列(ClaimId、ActivityName、EventTimeなど)が、出力ファイルの列に正しく対応していることを確認します。出力ファイルのヘッダー名は、これらの名前と完全に一致させます。
- 出力ファイルの設定:出力形式にCSVを指定します。ProcessMindとの互換性を確保するため、区切り文字をカンマ(,)、文字エンコードをUTF-8に設定します。
- 保存先の指定:生成したCSVファイルを保存するファイルパスまたはネットワーク上の場所を指定します。システムにその場所への書き込み権限があることを確認します。
- エクスポートジョブのスケジュール設定:ジョブの実行スケジュールを設定します。初回の分析では手動で実行できます。継続的に監視する場合は、定期実行(毎日または毎週など)を設定します。
- ジョブの実行とファイルの取得:ジョブを実行してイベントログファイルを生成します。完了したら、手順8で指定した保存先からCSVファイルを取得します。
- アップロード前の準備:ProcessMindにアップロードする前にCSVファイルを開き、最終確認を行います。ヘッダーが正しいこと、日付形式が統一されていること(YYYY-MM-DD HH:MI:SS)、データが想定どおりに表示されていることを確認します。
設定
- 前提条件:Duck Creek Data Hubモジュールへのアクセスが必要です。エクスポートジョブを実行するユーザーまたはサービスアカウントには、Data Hubの基盤データベーステーブル(例:[DataHubSchema].[FactClaimTransaction]、[DataHubSchema].[DimClaim]、[DataHubSchema].[DimStatusHistory])への読み取り権限が必要です。
- 期間の設定:クエリでは@StartDateおよび@EndDateパラメーターを使用します。抽出期間を指定するため、これらの値を必ず設定してください。初回の分析では、完了済みと進行中のケースを十分に含めるため、6~12か月の期間を推奨します。
- フィルタリング:クエリには、共通テーブル式(CTE)内に/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */というプレースホルダーが含まれています。特定の事業分野(例:'Personal Auto'、'Commercial Property')に絞り込んでデータ量を減らし、分析対象を明確にするには、この行のコメントを解除して内容を変更します。
- Data Hubの更新サイクル:Data Hubのデータには遅延がある点にご注意ください。データはリアルタイムではなく、通常は定期的(例:毎晩)に更新されます。抽出データは、最後に正常に完了したData Hubの更新時点の内容になります。
- 出力形式:エクスポートジョブは、CSVなどのフラットファイルを出力するよう設定します。データ項目内のカンマに対応できるよう、テキスト修飾子を二重引用符(")に設定してください。
クエリの例 sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; 始める準備はできていますか?
このテンプレートを使えば、請求処理の最適化に必要な準備を整えられます。今日からデータ分析を始め、価値あるインサイトを見つけましょう。
保険金請求の滞留を解消:請求処理を今すぐ最適化
ストレートスルー処理率70%を達成し、コストと遅延を削減します。
14日間の無料トライアル。クレジットカードは不要です。