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

この属性は「Claim Submitted」「Initial Review Performed」「Payment Issued」のような、請求プロセスにおける個々のステップやマイルストーンを表します。各アクティビティは、請求に対して行われた固有のアクションです。

これらのアクティビティの順序や発生頻度を分析することが、Process Mining の土台です。実際のプロセスフローが明らかになり、作業が滞留するボトルネックを特定し、請求がたどる典型的または例外的な経路を可視化できます。

プロセスの各ステップを定義し、プロセスマップの可視化や、ワークフローのパターンと逸脱の分析を可能にします。

通常、FINEOS Claimsのイベントログ、タスクのステータス変更、あるいは監査証跡（Audit Trail）から導出します。

Event Time は、保険金請求処理の各アクティビティが実行された正確な日時を記録します。この時系列データは、イベントを正しい順序で並べ、請求のタイムラインを把握するうえで不可欠です。

分析では、このタイムスタンプを使って各工程の所要時間、サイクルタイム、工程間の待ち時間を算出します。遅延の特定、SLA に対するパフォーマンスの測定、プロセスの時間的な流れを理解するための基盤となります。

このタイムスタンプはイベントの時系列を与え、サイクルタイムの算出やボトルネックの特定など、時間系のすべての指標計算に不可欠です。

この情報は通常、FINEOS Claims内の各イベントやステータスレコードに紐づく作成または更新のタイムスタンプとして取得できます。

Claim IDは、請求のライフサイクル全体にわたって、すべてのアクティビティ、イベント、データポイントを結び付ける基本キーです。初回の申請から最終クローズまで、あらゆるタッチポイントを1つのケースとして一貫して追跡できます。

プロセスマイニングでは、各請求のエンドツーエンドの軌跡を再構築するうえで不可欠な属性です。プロセスフローの分析、解決までの総所要時間の算出、請求ごとの処理ばらつきの特定が可能になります。

関連するすべてのイベントを1つのプロセスインスタンスに結びつける中核の識別子で、請求ライフサイクルのエンドツーエンド分析を可能にします。

FINEOS Claimsの主要な請求ケース管理テーブルで用いられる主キーです。

この属性は、プロセスデータの出所を示します。本分析では一貫して「FINEOS Claims」ですが、マルチシステム環境ではデータリネージュ（来歴）の追跡やデータ品質の担保に不可欠です。

より広い分析の文脈では、複数システムにまたがるプロセスを区別し、出所に応じて正しく解釈できるようにします。

データの由来に関する重要なコンテキストを提供し、データガバナンスや検証、他システムとの統合に不可欠です。

これは一般に、データ抽出プロセスでデータセットの出所を示すために付与される静的な値です。

この属性は、データが直近で抽出／更新された日時を示します。分析対象データの鮮度と最新性を理解するうえで重要です。

この情報はデータガバナンスに不可欠であり、利用者が最新のプロセスデータを見ているかどうかを判断できます。データの遅延への期待値調整に役立ち、準リアルタイムなプロセスのレポーティングにも不可欠です。

データの鮮度を示し、分析が対象とする期間と最終更新日時をユーザーが把握できるようにします。

このタイムスタンプは、データ抽出やETLツールがデータロード処理の終了時に生成・保存するのが一般的です。

この属性は、請求をどの経路で受け付けたか（オンラインポータル、メール、郵送、代理店経由など）を記録します。受付チャネルの違いは、データ品質や初期処理時間に大きく影響します。

チャネル別にプロセスを分析すると、特定のチャネルが処理を速めるのか、再作業率（例：情報不足）を高めるのか、結果に差が出るのかを判断できます。得られた知見は、オンラインフォームの改善によるエラー削減など、チャネル最適化への投資判断に役立ちます。

特定の受付チャネルが処理効率や手戻り率にどう影響するかを把握でき、チャネル戦略や投資判断に役立ちます。

詳細は FINEOS Claims のドキュメントをご確認ください。これは通常、請求受付プロセスで取得され、メインの請求レコードに保存されます。

この属性は、請求プロセスで特定のタスクを実行した個人またはチームを識別します。プロセスのアクティビティを人的リソースに結びつける主な手段です。

Assigned Adjuster（担当アジャスター）別の分析は、業務負荷の分布、個人のパフォーマンス、リソース効率を把握するうえで不可欠です。過重な担当者の可視化、パフォーマンス比較による育成機会の発見、負荷を平準化するためのリソース配分の見直しに役立ちます。

この属性は、各プロセスのステップを実行者に結びつけ、業務負荷の分析、リソース効率の評価、パフォーマンス比較を可能にします。

詳細は FINEOS Claims のドキュメントをご確認ください。この情報は、保険金請求のイベントに関連するタスク所有者やユーザー割り当てのフィールドに保存されるのが一般的です。

End Timeは、アクティビティが終了した正確な時刻を記録する属性です。Start Time（EventTime）と組み合わせることで、各ステップの完了までに要した正味の処理時間を正確に算出できます。

分析では、実作業時間と待ち時間（アイドル時間）の切り分けに不可欠です。どのアクティビティが時間を最も消費しているか、ステップ間のどこで滞留が発生しているかを示す詳細なボトルネック分析を可能にします。

各アクティビティの処理時間を正確に算出でき、非効率なステップの特定やリソース活用度の計測に直結します。

詳細は FINEOS Claims のドキュメントをご確認ください。イベントログで取得できるほか、後続イベントの開始時刻から導出することも可能です。

この属性は、SLAや法規制で定義された、請求処理を完了すべき期限を表します。実績を評価するベンチマークとなります。

実際のクローズ日と「Resolution Target Date」を比較することで、SLA遵守率の算出、SLA違反リスクの高い案件の特定、非遵守を招く遅延の原因分析が可能です。

SLA順守を測定するための基準値です。遅延した請求の特定や、遅れの要因分析に役立ちます。

詳細は FINEOS Claims のドキュメントをご確認ください。この日付は、請求の提出日や種類に基づくビジネスルールで算出されることが多い項目です。

Claim Status は、請求のライフサイクル上の状態（例：「Open」「Pending Information」「Approved」「Denied」「Closed」）を示します。この属性によって、その時点で請求がどの段階にあるかをひと目で把握できます。

プロセス分析では、ステータスの変化は多くの場合アクティビティの実行と直接対応します。ステータスの追跡は、請求結果の把握、特定のステータスに長期間とどまるボトルネックの特定、そして最終的に「Denied」や「Closed」となる理由の分析に不可欠です。

この属性は、請求の結果を把握し、アクティブ案件とクローズ済み案件を切り分け、停滞しているステージを特定するうえで重要な属性です。

詳細は FINEOS Claims のドキュメントをご確認ください。これはメインの請求レコード上の基本項目で、ライフサイクルを通じて更新されます。

請求の重大度（Severity）は、請求の複雑さ、緊急性、金銭的リスクを示す評価です。重大度が高い請求は、低い請求に比べて、追加のステップや専門的なレビューが必要になったり、処理時間が長くなったりする傾向があります。

重大度別にプロセスを分析すると、複雑さのレベルごとに資源配分やプロセス設計が適切かどうかを見極められます。高重大度の請求が過度に遅延していないか、逆に低重大度の請求に過剰処理が発生していないかを明らかにし、プロセスのセグメンテーションやリソース管理の最適化につながります。

重大度でセグメントすることで、影響の大きい請求が適切に優先されているかを検証でき、特定の複雑度がボトルネックの原因になっていないかを見極められます。

詳細は FINEOS Claims のドキュメントをご確認ください。専用のフィールドである場合や、推定損害額など他の属性から導出される場合があります。

Claim Type は、契約の種類や損害の内容に基づいて請求を分類します。タイプごとにプロセスのバリエーションや規制要件が異なり、専門的な対応が必要になることもあります。

比較分析における重要な切り口です。Claim Type でフィルターやセグメントをかけることで、タイプ特有のボトルネックを洗い出し、カテゴリ間のパフォーマンスを比較し、各タイプの特性に合わせた改善施策を立案できます。あるタイプの請求が本質的に処理効率が低いのかどうか、といった問いにも答えられます。

請求カテゴリ別にプロセスをセグメントでき、パフォーマンスを比較して差異を特定できるため、より的確な改善に結びつきます。

詳細は FINEOS Claims のドキュメントをご確認ください。これは請求の中核属性で、通常は登録時に設定され、メインのケーステーブルに保存されます。

この属性は、「Initial Intake」「Investigation Unit」「Payments Department」など、特定アクティビティの責任部門や、ある段階で請求を所管する組織単位を示します。

部門別にプロセスを分析することで、遅延の原因になりやすい部門間ハンドオフを可視化できます。どの部門がボトルネックか、部門別の効率、組織横断でのリソース配分を評価するのに役立ちます。

組織単位別のパフォーマンス分析を可能にし、部門間の受け渡し遅延や部門内のボトルネックを可視化します。

詳細は FINEOS Claims のドキュメントをご確認ください。これは、担当査定者のユーザープロファイル、またはタスクの割り当て先キューに紐づけられます。

この属性は、各請求のSLA達成状況を「On Time」「Late」などのカテゴリで明確に示します。「Claim Closed」と「Resolution Target Date」を突き合わせて算出します。

日付そのものを扱う代わりに、この簡潔なカテゴリでSLA遵守状況をレポート・分析できます。SLA遵守率を示すdashboardの作成、遅延案件だけを抽出して共通特性を分析、経時的なSLAパフォーマンスのトレンド監視などに利用でき、SLA AdherenceのdashboardやKPIを直接支援します。

各ケースのSLA達成状況をひと目で把握できるシンプルな指標を提供し、SLA遵守率の測定・分析を容易にします。

各ケースごとに最終アクティビティのタイムスタンプと'ResolutionTargetDate'を比較して算出する計算フィールドです。

この属性は、「Closed」状態から再びアクティブに戻した理由を記録します。主な理由には、新たな情報の受領、請求者からの異議申立て、誤りの訂正などがあります。

再開理由の分析は、プロセスの品質と終局性を測る最も直接的な手段です。再開件数が多い、とりわけ特定の理由に集中している場合は、初回のクローズに問題があったことを示します。このデータは、調査や意思決定の各段階にある弱点を突き止め、初回で正しくクローズできるよう改善対象を明確にします。

早期または誤ってクローズされたケースなどのプロセス不具合を直接把握でき、初回解決率の改善機会を明確にします。

詳細は FINEOS Claims のドキュメントをご確認ください。通常、この理由はユーザーがシステムで「Reopen Claim」アクションを実行した際に記録されます。

Processing Time は、アクティビティの開始から終了までの経過時間を測る算出指標です。リソースがタスクに実際に従事していた「タッチタイム」を表します。

パフォーマンス分析の基本指標であり、能動的な作業時間と待機時間を切り分けることで、リソース効率を正確に評価し、本質的に時間を要する活動を特定できます。運用コストやアジャスターの稼働率を算出する際の重要な入力にもなります。

各アクティビティの実作業時間（タッチタイム）を計測し、どのタスクが時間を要しているかを特定し、リソース効率を正確に評価します。

各アクティビティのEndTimeからStartTimeを差し引いて算出します。

請求結果が'Denied'の場合、この属性に否認の具体的理由が入ります（例：'Not Covered by Policy'、'Fraud Suspected'、'Incomplete Information'）。

これは否認の根本原因分析に欠かせない情報です。理由別の発生頻度を分析することで、申請時の不備、補償範囲への誤解、査定担当者の教育ニーズなどを把握できます。結果として、否認率の低減や顧客満足の向上につながります。

失敗したプロセスの根本原因分析に不可欠で、請求否認の削減や受付品質の向上につながる機会の特定に役立ちます。

詳細は FINEOS Claims のドキュメントをご確認ください。これは通常、「Claim Denied」アクティビティの実行時に選択される構造化フィールドまたはコードです。

この計算属性は、同一請求で2回目の「Additional Information Requested」のような、手戻りに当たるアクティビティをフラグします。通常は、同一アクティビティの繰り返しや、プロセスフローの後戻りループを検出して特定します。

手戻りを明示的にフラグ化すると、非効率に着目した分析が容易になります。手戻り率という重要なKPIを簡単に定量化でき、dashboardで頻度や影響度を可視化して、非効率ループの根本原因を特定しやすくなります。

非効率なプロセスループを直接ハイライトし、手戻り率の算出や繰り返し作業の要因分析を容易にします。

同一ケースで同じアクティビティが繰り返されているかを特定する、プロセスマイニングの分析で導出します。例: 'Investigation Started'の2回目の発生をフラグ化します。

Loss Dateは、実際の事故・傷害などの発生日時を示します。これは請求の提出日とは異なり、請求の正当性や処理において重要な要素になり得ます。

この属性は重要な文脈情報を与えます。Loss Dateと『Claim Submitted』日との時間差（報告ラグ）は主要な指標になり得ます。ラグを分析することで、報告プロセス上の課題や請求ライフサイクル全体への影響を明らかにできます。

重要な文脈を提供し、事故発生から申請までの遅延（reporting lag）の算出を可能にします。これは請求の複雑性や結果に影響します。

詳細は FINEOS Claims のドキュメントをご確認ください。この日付は、「First Notice of Loss（事故第一報）」または請求登録時に記録される標準項目です。

Loss Amountは、請求に対して計上する初期見積額または引当金を指します。調査・査定の進行に応じて更新されることがあります。

この財務データは、請求をセグメント化し、財務的な影響とプロセスの動きの関係を理解するうえで不可欠です。たとえば「高額請求ほど処理に時間がかかるのか」「手戻りが増えるのか」といった問いに答える助けになります。また、財務予測やリスク管理の主要な入力でもあります。

プロセスに財務的な文脈を与え、請求額が処理時間・複雑性・経路に与える影響を分析できるようにします。

詳細は FINEOS Claims のドキュメントをご確認ください。この情報は、請求に関連する財務テーブルや引当金テーブルに格納されているのが一般的です。

Payment Amount は、支払承認と示談確定後に実際に支出された最終的な金額を指します。分割払いや複数回払いの請求では、個々の支払取引を指す場合があります。

この属性は、財務突合やプロセスの金銭的な結果を分析するうえで不可欠です。初期の推定損害額と最終の支払額を比較でき、プロセス分析では各プロセスバリアントや意思決定がもたらす財務インパクトを把握するのに役立ちます。

プロセスの金銭的な結果を追跡します。財務パフォーマンスの測定や請求価値の分析に不可欠です。

詳細は FINEOS Claims のドキュメントをご確認ください。このデータは、保険金請求ケースに関連付けられた支払いトランザクションテーブルに格納されています。

Policy Numberは、その請求をカバーする保険契約を識別するIDです。特定の顧客、契約条件、補償内容と請求を結び付けます。

プロセス属性そのものではありませんが、重要なビジネス文脈を提供します。契約や顧客単位で請求データを集計でき、請求頻度や顧客体験の分析、複雑な請求を多く生む契約の特定などに役立ちます。

請求を特定の顧客契約にひも付け、顧客中心のプロセス分析を可能にする重要なビジネス文脈を提供します。

詳細は FINEOS Claims のドキュメントをご確認ください。これは請求登録時に取得され、メインの請求レコードに保持される基本的なデータです。

この属性は、請求に紐づく地理情報（請求者の住所や事故・損害の発生地点など）を示します。

地域別に分析することで、請求タイプや発生頻度、処理効率の地域差が見えてきます。特定の拠点のパフォーマンスが優れているか、規制や気象などの地域固有要因が請求プロセスに影響しているかを把握でき、より的確なマネジメントとリソース配分につながります。

地域別のセグメンテーションにより、地域ごとのパフォーマンス差、コンプライアンスの違い、地域特有のボトルネックを把握できます。

詳細は FINEOS Claims のドキュメントをご確認ください。この情報は、システムに保存された契約者または請求人の住所情報から判定されるのが一般的です。