> 継続的なプロセス改善 > 保険金請求処理 > Salesforce Financial Services Cloud > データテンプレート

クレーム処理データテンプレート

Salesforce Financial Services Cloud

保険金請求処理の属性 (23) 保険金請求処理のアクティビティ (15) 抽出ガイド (1)

クレーム処理データテンプレート

このテンプレートでは、クレーム処理ワークフローを効果的に分析するために必要なデータを体系的に整理しています。収集すべき主要な属性、追跡すべき重要なアクティビティ、Salesforce Financial Services Cloudからデータを抽出するための具体的な手順を確認できます。このリソースを使ってイベントログを準備し、詳細なプロセスマイニング分析につなげてください。

収集を推奨する属性
追跡すべき主要なアクティビティ
Salesforce Financial Services Cloudからの抽出手順

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

保険金請求処理の属性

保険金請求処理を詳細に分析するために、イベントログに含めることを推奨するデータ項目です。

5 必須 7 推奨 11 任意

	名前	説明
	保険金請求ID ClaimId	各保険金請求を一意に識別するIDであり、プロセス分析における主要なケースIDとして使用されます。
説明保険金請求IDは、1件の保険金請求に関する提出からクローズまでのすべてのアクティビティ、イベント、データポイントを結び付ける基本的なケース識別子です。プロセスマイニングでは、この属性を使って各保険金請求のエンドツーエンドの経過を再構成します。関連するすべてのイベントを1つの一貫したケースにまとめられるため、個々の保険金請求についてサイクル時間、プロセスバリアント、ボトルネックを分析できます。重要な理由これは、保険金請求のライフサイクルを追跡するために欠かせないキーです。一意の保険金請求IDがなければ、さまざまなプロセスステップを一貫した分析対象の経過として結び付けることはできません。入手先通常は、Caseオブジェクトの「CaseNumber」、または「Claim」（FinancialServicesCloud.Claim）オブジェクトのカスタム一意IDフィールドです。例 CL-00012345CL-00012346CL-00012347
	アクティビティ名 ActivityName	保険金請求のライフサイクルにおいて、特定の時点で発生した業務アクティビティまたはイベントの名称です。
説明この属性は、「Claim Submitted」、「Initial Review Performed」、「Payment Issued」など、保険金請求プロセスにおける1つのステップまたはマイルストーンを表します。プロセスマップの基盤となる属性です。アクティビティの順序と頻度を分析することで、最も一般的なプロセス経路（バリアント）を特定し、標準プロセスからの逸脱を見つけられます。また、頻繁に繰り返されるアクティビティを特定し、手戻りの発生を把握できます。重要な理由プロセスにおける「何を」を定義し、プロセスフローの可視化や、ボトルネック、手戻りループ、プロセスのばらつきの特定を可能にします。入手先 Claim／Caseオブジェクトの「Status」フィールドの変更、または関連するTaskやEventレコードの「Subject」から取得します。例請求受付初回審査完了追加情報の依頼保険金請求のクローズ
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した時点を示すタイムスタンプです。
説明イベント時刻は、保険金請求のライフサイクルにおける各アクティビティの正確な日時を示します。この時系列データは、イベントを時系列に並べ、期間を算出するために欠かせません。分析では、アクティビティ間のサイクル時間や待機時間、ケース全体の所要時間など、時間に関するすべての指標の算出にタイムスタンプを使用します。また、動的なプロセスアニメーションの作成や、遅延がいつ、どこで発生しているかの特定にも必要です。重要な理由各イベントの「いつ」を示し、期間の算出、時間の経過に伴うプロセスパフォーマンスの分析、時間に起因するボトルネックの特定を可能にします。入手先ステータス変更の場合は、オブジェクトのフィールド履歴（例：CaseHistory）にある「CreatedDate」です。タスクの場合は、「CompletedDateTime」または「CreatedDate」です。例 2023-04-15T10:22:05Z2023-04-16T14:05:10Z2023-04-18T09:00:00Z
	ソースシステム SourceSystem	イベントデータが記録された元のシステムを識別します。
説明データを抽出した元のアプリケーションまたはプラットフォームを示す属性です。このプロセスでは、一貫して「Salesforce Financial Services Cloud」となります。一見すると固定値に思えますが、特に複数のシステムからデータを統合する環境では、ソースシステムを明示的に記録することが推奨されます。データの出所を明確にし、データガバナンスや検証にも役立ちます。重要な理由データの出所を確認できます。データガバナンス、トラブルシューティング、複数のエンタープライズシステムからのデータ統合に欠かせません。入手先通常は、データ抽出・変換処理の際にデータセットの出所を示すために追加される固定値です。例 Salesforce Financial Services Cloud
	最終データ更新 LastDataUpdate	ソースシステムからデータを更新または抽出した直近の時点を示すタイムスタンプです。
説明 Salesforce Financial Services Cloudからデータが最後に取得された日時を示します。分析対象データの鮮度を把握するための情報です。ダッシュボードの利用者が、分析結果がどの時点の情報に基づいているかを理解するために重要です。データの適時性に関する期待値を管理し、データパイプラインが予定どおり実行されていることを検証するうえでも欠かせません。重要な理由データの鮮度に関する重要な情報を提供し、アナリストや業務ユーザーがプロセスビューの最新性を把握できるようにします。入手先抽出ツールまたはETL処理が実行された時点で、その処理によってデータセットに生成・記録されます。例 2023-10-27T02:00:00Z
	保険金請求ステータス ClaimStatus	イベント発生時点における保険金請求の現在のステータスです（例：Open、Under Review、Closed）。
説明保険金請求ステータスは、「New」、「Investigation」、「Pending Customer」、「Closed」など、ライフサイクル上の現在位置を示します。プロセスの現在の状態を把握するための主要な属性です。「Open Claims Ageing Report」などの業務用ダッシュボードでは、この属性を使って現在の業務量を可視化し、特定のステータスに長く滞留している保険金請求を特定します。ステータス間の遷移を分析することは、プロセスマップ上のアクティビティを定義する主要な方法でもあります。重要な理由対応中の保険金請求の現在の状態をリアルタイムで把握でき、滞留案件の管理や処理が止まったケースの特定に役立ちます。入手先 CaseまたはClaimオブジェクトの標準「Status」フィールドです。例登録済み調査中示談金額の提示クローズ－支払い済みクローズ－却下
	保険金請求種別 ClaimType	自動車、財物、賠償責任など、保険金請求の分類です。
説明保険金請求種別は、保険金請求プロセスを分類・分析するための重要な軸です。種別によってプロセス、複雑さ、適用されるSLAが異なることがよくあります。保険金請求種別ごとにパフォーマンスを絞り込んだり比較したりすることで、種別固有のボトルネックを見つけ、対象SLAへのコンプライアンスを評価し、カテゴリー間のプロセスの違いを把握できます。「Claim SLA Compliance Overview」や「Claim Rejection Reason Analysis」などのダッシュボードで、より対象を絞った分析に利用します。重要な理由保険金請求を分類してプロセスを比較し、種別固有の問題を特定するとともに、改善施策を調整できます。入手先通常は、CaseまたはClaimオブジェクトの標準「Type」フィールド、またはカスタム選択リストフィールドです。例自動車住宅所有者保険企業財物保険一般賠償責任
	保険金請求総額 TotalClaimAmount	契約者が当初請求した金額の合計です。
説明プロセス開始時点で顧客が請求している損害または損失の総額を示します。この金額は、保険金請求の複雑さ、必要な審査レベル、適用される処理経路に影響することがあります。請求金額に基づいてプロセス指標を分析すると、重要な傾向を把握できます。たとえば、高額な保険金請求はサイクル時間が長くなったり、ステップ数が増えたり、専門チームに振り分けられたりする場合があります。現実的なSLAの設定や財務準備金の予測にも役立ちます。重要な理由各ケースの財務的な背景を示し、請求金額がプロセスの複雑さ、所要時間、結果に与える影響を分析できます。入手先 Financial Services CloudのClaimオブジェクトにあるカスタム通貨フィールドで、たとえば「ClaimedAmount__c」です。例 1500.0025000.50125.75
	割り当て済み査定担当者 AssignedAdjuster	保険金請求の処理を担当し、責任を負うユーザーまたは査定担当者の氏名です。
説明この属性は、アクティビティまたはケース全体を担当する個々の査定担当者を識別します。通常は、保険金請求ケースの所有者、または特定のタスクを完了した担当者から取得します。査定担当者別にパフォーマンスを分析することは、業務管理に欠かせません。「Adjuster Workload & Performance」などのダッシュボードでは、この属性を使って担当者ごとの保険金請求件数、対応中のケース数、サイクル時間を追跡し、業務量の適切な配分や育成機会の特定に役立てます。重要な理由チームおよび個人のパフォーマンス分析、業務量の管理、ベストプラクティスや研修ニーズの特定に欠かせません。入手先 CaseまたはClaimオブジェクトの「OwnerId」フィールドです。Userオブジェクトに関連付けられ、査定担当者の氏名を取得します。例 Alice JohnsonRobert SmithMaria Garcia
	提出チャネル SubmissionChannel	保険金請求が最初に提出された方法またはチャネルです。
説明保険金請求が最初に報告された方法を示します。たとえば、Webポータル、モバイルアプリ、電話、メールなどです。提出チャネルは、初期情報の品質やその後の処理ステップに大きな影響を与える場合があります。提出チャネル別に保険金請求を分析することで、需要の傾向や各受付方法の効率を把握できます。「Claims Throughput & Volume」ダッシュボードでは、この属性を使ってチャネルごとの保険金請求件数の推移を追跡し、リソース配分や技術投資の判断に役立てます。重要な理由異なる受付チャネルの効率を評価し、特定のチャネルで手戻りやサイクル時間の長期化が多く発生していないかを把握できます。入手先通常は、Claim／Caseオブジェクトのカスタム選択リストフィールドで、「Origin」または「Channel」と表示されます。例ウェブポータルモバイルアプリ電話メール
	終了時刻 EndTime	アクティビティの完了時点を示すタイムスタンプです。正確な期間の算出に使用します。
説明終了時刻属性は、アクティビティが完了した正確な時点を記録します。開始時刻（EventTime）が開始点を示すのに対し、終了時刻はアクティビティの所要時間を測定するためのもう一方の境界となります。開始時刻と終了時刻の両方があれば、アクティビティの処理時間を正確に算出し、アクティビティ間の待機時間と区別できます。これは、「Process Step Duration Breakdown」のようなダッシュボードを作成し、アクティビティ間だけでなく、個々のタスク内の非効率も特定するための基礎となります。重要な理由各アクティビティの実作業時間を正確に算出できるため、付加価値を生む時間と待機時間を区別するうえで重要です。入手先タイムスタンプデータから取得します。たとえば、「Initial Review Performed」がステータス変更によって発生する場合、EndTimeには次のステータス変更のタイムスタンプを設定できます。例 2023-04-15T11:05:30Z2023-04-16T17:20:00Z2023-04-18T09:45:12Z
	部門 Department	保険金請求の処理を担当する社内の部門またはチームです。
説明「Personal Lines」、「Commercial Auto」、「Special Investigations Unit」など、保険金請求に割り当てられた事業部門または部署を示します。部門別にプロセスを分析することで、チーム間のパフォーマンス差、業務量の配分、部門固有のプロセス逸脱やボトルネックを把握できます。「Claim SLA Compliance Overview」などのダッシュボードで、組織内の各部門のパフォーマンスを確認する際に役立つ軸です。重要な理由異なる事業部門間でパフォーマンスを比較でき、ベストプラクティスの特定やリソースのより効果的な配分に役立ちます。入手先 Claim／Caseオブジェクトのカスタムフィールド、またはUserオブジェクトにある割り当てユーザーのプロファイルや役割から推定できます。例個人自動車保険金請求企業財物保険不正調査部門
	SLAステータス SlaStatus	保険金請求が定められたサービスレベル合意（SLA）の期限内に解決されたかどうかを示します。
説明通常は「Met」または「Breached」などの値を持つカテゴリー型の結果です。保険金請求の実際の完了日（最後のアクティビティのタイムスタンプ）と「SlaTargetDate」を比較して算出します。「SLA Adherence Rate」KPIと「Claim SLA Compliance Overview」ダッシュボードの中心となる指標です。目標に対するパフォーマンスを明確に測定でき、コンプライアンス報告や業務管理に欠かせません。重要な理由処理時間の目標に対する実績を明確に示し、顧客満足度と規制上のコンプライアンスを支えます。入手先計算フィールド：最終イベントの「EndTime」が「SlaTargetDate」以下の場合は「Met」、それ以外は「Breached」とします。このロジックは、データ変換時またはプロセスマイニングツール内で適用します。例達成違反
	SLA目標日 SlaTargetDate	サービスレベル合意に基づき、保険金請求を解決する予定の期限日です。
説明 SLA目標日は、保険金請求の解決期限を示す、計算または手動設定された日付です。適時性を測定する基準となります。顧客や規制当局に対する約束に沿って業務を遂行できているかを監視するために欠かせません。「SLA Adherence Rate」KPIや「Claim SLA Compliance Overview」ダッシュボードの基準となり、期限内に解決された保険金請求の割合や、目標達成に苦戦している種別・部門を把握できます。重要な理由保険金請求の解決時間に関する目標を定義し、SLAコンプライアンスを直接測定できます。入手先通常はClaim／Caseオブジェクトのカスタム数式フィールドまたは日付フィールドで、提出日と保険金請求種別に基づいて算出されます。例 2023-05-15T23:59:59Z2023-06-20T23:59:59Z2023-07-01T23:59:59Z
	ケース所要時間 CaseDuration	1件の保険金請求について、最初のイベントから最後のイベントまでに経過した合計時間です。サイクル時間とも呼ばれます。
説明保険金請求ケースの提出から最終的なクローズまで、エンドツーエンドの所要時間を測定します。特定のClaim IDについて、最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを引いて算出します。プロセスパフォーマンスを示す最も重要なKPIの1つです。「Average Claim Cycle Time」KPIや「Claim End-to-End Cycle Time」ダッシュボードで直接確認できます。プロセス改善プロジェクトでは、この値の短縮が主要な目標になることがよくあります。重要な理由プロセス全体のエンドツーエンドの効率を測定し、顧客体験を示す重要な指標です。入手先計算フィールドです。各「ClaimId」について、最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを引いて算出します。プロセスマイニングツールが計算します。例 30日5時間15日10時間90日2時間
	保険証券番号 PolicyNumber	保険金請求に関連付けられた保険証券を一意に識別する番号です。
説明保険証券番号は、保険金請求を顧客の有効な保険証券に結び付けます。補償内容、限度額、契約者の履歴を把握するための重要な情報です。必ずしもプロセスフローを直接左右する情報ではありませんが、重要なコンテキストデータです。保険金請求データと保険証券データを結合し、特定の保険証券種別で請求が頻発していないか、複雑な請求が多くないかなど、より詳細な分析に利用できます。重要な理由保険金請求を基となる保険証券に結び付け、特定の保険証券や補償種別に関連する請求傾向をより広く分析できます。入手先 Financial Services Cloudの「InsurancePolicy」オブジェクトを参照する、Claimオブジェクトの参照フィールドです。例 POL-987654321POL-123456789POL-555444333
	再作業かどうか IsRework	アクティビティまたは一連のアクティビティが再作業に該当するかどうかを示すブール型フラグです。
説明クレームがプロセス内の前の段階に戻った場合、このフラグをtrueに設定します。典型的な例は、「Investigation Completed」から「Additional Information Requested」に戻るケースです。再作業を特定するロジックは、プロセスに関する知識に基づいて定義します。この属性は、「Claims Rework Loop Analysis」ダッシュボードと「Rework Rate」KPIの基盤となります。再作業の発生頻度と影響を直接数値化できるため、非効率化、コスト増加、サイクルタイム長期化の主な要因を把握できます。重要な理由非効率なプロセスループを直接特定し、再作業の量を簡単に数値化するとともに、根本原因を絞り込んで分析できます。入手先計算フィールドです。各ケースのアクティビティの順序を分析して算出します。たとえば、「Activity A」の後に「Activity B」が続き、その後に再び「Activity A」が発生した場合、2回目の「A」が再作業に該当します。例 truefalse
	却下理由 ReasonForRejection	保険金請求が不承認または却下された際に示される具体的な理由です。
説明保険金請求の最終判断が「Rejected」の場合、その根拠を示します。たとえば、「Not Covered by Policy」、「Fraud Suspected」、「Incomplete Information」などです。「Claim Rejection Reason Analysis」ダッシュボードの中心となる属性です。却下理由の頻度を、保険金請求種別や部門などの軸で分析することで、組織は引受審査の改善、保険証券の説明の明確化、情報収集プロセスの強化など、無効な提出を減らす機会を特定できます。重要な理由保険金請求が却下された理由を直接把握でき、引受方針の改善や無効な請求の処理にかかる無駄の削減に欠かせません。入手先通常はClaim／Caseオブジェクトのカスタム選択リストフィールドで、ステータスが「Rejected」または「Closed - Denied」に変更された際に入力必須となります。例補償期間終了補償対象外の損害不正の疑い重複請求
	所在地 Location	保険金請求または保険証券に関連する地理的な場所（国、州、地域）です。
説明保険金請求に関する地理的な背景を示します。たとえば、損害が発生した州や契約者が所在する国などです。契約者の住所や損害の詳細から取得できます。地理的に分析することで、保険金請求の種別、頻度、処理時間に関する地域傾向を把握できます。また、地域拠点間のパフォーマンス評価や、所在地固有の規制へのコンプライアンス確認にも利用できます。重要な理由保険金請求を地理的に分析でき、地域ごとのパフォーマンス差、詐欺の傾向、地域の出来事による影響を明らかにできます。入手先通常は、関連するAccountまたはContactオブジェクトの住所フィールド（例：「BillingState」、「BillingCountry」）から取得します。例 USAカリフォルニア州英国
	損害発生日 LossDate	保険金請求の原因となった事故または損害が発生した日付です。
説明保険証券の補償対象となる事象が発生した日付を記録します。保険金請求が提出された日付とは異なります。この属性はコンプライアンスや、事故発生から報告までの遅延時間の分析に重要です。期間が大きく空いている場合、問題の可能性を示したり、異なる処理手順が必要になったりすることがあります。イベント全体の時系列を把握するための重要な情報です。重要な理由事故発生から報告までの遅延を分析でき、調査や示談にかかる期間の把握に役立ちます。入手先 Claimオブジェクトのカスタム日付フィールドで、例として「DateOfLoss__c」があります。例 2023-04-122023-05-202023-06-01
	示談金額 SettlementAmount	保険金請求の解決時に請求者へ支払われる最終的な金額です。
説明保険金請求がクローズされ、示談が成立した際に請求者へ実際に支払われた金額を記録します。査定、免責金額、保険証券の限度額により、当初の請求金額とは異なる場合があります。示談金額を当初の請求金額と比較して分析することで、損害評価の精度や示談交渉の結果を把握できます。保険金請求の総コストを理解するための重要な財務指標です。重要な理由保険金請求が最終的に与えた財務的影響を示し、財務分析、準備金の設定、初期損害評価の精度検証に欠かせません。入手先 Financial Services CloudのClaimオブジェクト、または関連するPaymentオブジェクトにあるカスタム通貨フィールドです。例 1450.0022500.000.00
	自動処理かどうか IsAutomated	アクティビティが人ではなく自動化システムによって実行されたかどうかを示すブール値のフラグです。
説明人の査定担当者が完了したタスクと、自動化されたワークフロー、ルール、システム連携によって実行されたタスクを区別します。たとえば、保険金請求の初回登録が完全に自動化されている場合があります。自動化の分析は、プロセス効率を把握するうえで重要です。自動化施策の成果を測定し、今後の自動化に適したステップを特定するとともに、自動処理と手動処理の速度や一貫性を比較できます。重要な理由人が行ったアクティビティとシステムが実行したアクティビティを区別でき、自動化の効果や成果を評価するうえで重要です。入手先通常は推定値です。イベントに関連付けられたユーザーが汎用の「System」ユーザーまたは「Integration」ユーザーの場合、このフラグをtrueに設定します。例 truefalse
	顧客ID CustomerId	保険金請求を提出した顧客または契約者を一意に識別するIDです。
説明顧客IDは、保険金請求を提出した個人または組織に結び付けます。Salesforceでは、通常AccountまたはContactオブジェクトへの参照です。この属性により、顧客を中心に保険金請求プロセスを分析できます。顧客ごとの請求履歴の分析、頻繁に請求する顧客の特定、サービスの個別化に利用できます。また、CRMの他の顧客データと保険金請求データを結び付け、事業全体を把握するためにも欠かせません。重要な理由顧客を中心とした分析が可能になり、個々の顧客の請求傾向や、保険金請求プロセスが顧客関係に与える影響を把握できます。入手先 Claim／Caseオブジェクトの参照フィールドで、AccountまたはContactオブジェクトを参照します（例：「AccountId」または「ContactId」）。例 0018d00000abcdeFAA0018d00000fghijKLM0018d00000mnopqrSTU

必須推奨任意

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

保険金請求処理を正確に発見するために、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 9 任意

	アクティビティ	説明
	保険金請求のクローズ	支払いを含むすべてのアクティビティが完了した後、システム上で保険金請求が最終的に正常終了したことを示します。「Claim」オブジェクトの最終ステータスが「Closed」に変更された時点で取得されます。
重要な理由これは、プロセスが正常に完了したことを示す主要な終了イベントです。エンドツーエンドのサイクル時間を算出し、プロセス全体の処理量を測定するために欠かせません。入手先「Claim」オブジェクトの「Status」フィールドに対するField History Trackingから推定し、「Closed」への変更時点のタイムスタンプを記録します。取得「Status」フィールドが「Closed」に変更された時点のタイムスタンプ。イベントタイプ inferred
	保険金請求の判断完了	保険金請求を承認または却下する正式な判断を示します。「Approved」や「Rejected」など、最終判断のステータスに変更されたことから推定される重要なマイルストーンです。
重要な理由この判断は、その後のプロセス経路を決める重要な分岐点です。判断までの時間を分析することで、査定担当者の業務効率とSLAコンプライアンスを測定できます。入手先「Claim」オブジェクトの「Status」フィールドが判断ステータス（例：「Approved」、「Rejected」）に変更された時点のタイムスタンプから推定され、Field History Trackingを通じて取得されます。取得「Status」が「Approved」または「Rejected」に変更された時点のタイムスタンプ。イベントタイプ inferred
	初回審査完了	割り当てられた査定担当者が請求の詳細について最初の総合的な審査を完了したことを示します。通常は、「Claim」オブジェクトのステータス変更から推定します。たとえば、「New」から「Under Review」または「Initial Assessment Complete」への変更です。
重要な理由このマイルストーンは、初期の待機期間が終わり、実際の処理が始まったことを示します。このステップに到達するまでの時間は、査定担当者の業務量と受付の効率を示す重要な指標です。入手先 Field History Trackingで取得した、「Claim」オブジェクトの「Status」フィールド変更時のタイムスタンプから推定します。取得「Status」フィールドが「Under Review」または同等の値に変更された時点のタイムスタンプ。イベントタイプ inferred
	支払い実行	請求者への資金の実際の支払いを示します。保険金請求に関連する支払いレコードが「Paid」または「Issued」として記録された時点で取得される、重要な財務イベントです。
重要な理由このアクティビティは、保険金請求の履行プロセス終盤を測定する重要なマイルストーンです。承認から支払いまでの時間を分析することで、財務業務を改善できます。入手先関連する「Claim Payment」カスタムオブジェクトのステータス変更から推定します。ステータスが「Paid」または「Sent」に変更された時点のタイムスタンプが、このイベントを示します。取得関連する「Claim Payment」オブジェクトのステータス変更時点のタイムスタンプ。イベントタイプ inferred
	請求受付	新しい請求がSalesforceに初めて入力された時点で、保険金請求処理の開始を示します。通常は、新しい「Claim」オブジェクトのレコード作成から取得します。
重要な理由プロセスの主要な開始イベントです。受付から次のステップまでの時間を分析すると、初期受付の遅延を特定でき、全体のサイクルタイムを測定する基準にもなります。入手先「Claim」標準オブジェクトの「CreatedDate」タイムスタンプから取得します。すべての請求ケースについて、正確で信頼性の高い開始点になります。取得「Claim」オブジェクトのレコード作成タイムスタンプ。イベントタイプ explicit
	追加情報の依頼	査定担当者が契約者または第三者から追加情報を得る必要があると判断した時点を示します。「Pending Customer Information」へのステータス変更、または関連する「Task」や「EmailMessage」レコードの作成から推定できます。
重要な理由やり直しのループを特定するうえで重要なアクティビティです。このイベントの頻度が高い場合、初期のデータ収集に問題があり、プロセスの遅延やサイクルタイムの長期化を招いている可能性があります。入手先「Claim」オブジェクトの「Status」フィールドが「Pending Information」に変更されたことから推定します。または、特定のタイプに該当する関連「Task」または「EmailMessage」レコードの作成日から取得します。取得「Status」が「Pending Info」に変更された時点、または関連するコミュニケーションレコードが作成された時点のタイムスタンプ。イベントタイプ inferred
	保険金請求の却下	却下された保険金請求の最終結果を示します。「Claim」オブジェクトのステータスが「Rejected」または「Denied」に更新された時点で取得される終了イベントです。
重要な理由これは、成功裏に完了したケースとは異なる、プロセスの最終状態です。却下された保険金請求とその理由を分析することで、引受審査や初期スクリーニングの改善につながる情報を得られます。入手先「Claim」オブジェクトの「Status」フィールドが「Rejected」に変更された時点のタイムスタンプから推定します。「Reason for Rejection」属性は、対応するフィールドから取得できます。取得「Status」フィールドが「Rejected」に変更された時点のタイムスタンプ。イベントタイプ inferred
	損害評価完了	損害による金銭的影響が評価され、記録されたことを示します。このイベントは、「Claim」オブジェクトの「Loss Estimate」または「Settlement Amount」フィールドに初めて値が入力された時点から推定できます。
重要な理由このアクティビティは、重要な財務上のマイルストーンです。発生時点を追跡することで、最終判断前の財務評価における遅延を把握できます。ここがボトルネックになる場合もあります。入手先「Claim」オブジェクトの通貨フィールド（例：「Loss_Estimate__c」）に対するField History Trackingから推定し、nullまたはゼロの値から初めて更新された時点のタイムスタンプを使用します。取得財務評価フィールドに初めて値が入力された時点のタイムスタンプ。イベントタイプ inferred
	支払い承認	示談金額について社内承認が完了し、支払い可能になったことを示します。関連する「Payment Request」オブジェクトから明示的なイベントとして取得するか、「Approved for Payment」などへのステータス変更から推定できます。
重要な理由これは重要な内部統制ポイントです。判断から支払い承認までの遅延は、財務承認ワークフローにおけるボトルネックを示す場合があります。入手先「Claim」オブジェクトの「Status」フィールドが変更された時点のタイムスタンプから推定します。より確実な方法として、関連する「Claim Payment」または同様のカスタムオブジェクトの「CreatedDate」を使用します。取得「Claim Payment」オブジェクトのレコード作成時点のタイムスタンプ。イベントタイプ explicit
	示談金額の提示	請求者に対して示談金額が正式に提示されたことを示します。「Settlement Offered」へのステータス変更、または連絡記録の作成によって取得できます。
重要な理由このアクティビティは、最終的な交渉または受諾フェーズを開始します。請求者の回答にかかった時間を分析することで、コミュニケーション方法を改善し、プロセス終盤の期間を短縮できます。入手先「Claim」オブジェクトの「Status」フィールドの変更から推定します。また、提示書を表す関連する「EmailMessage」または「Document」レコードの作成日から取得することもできます。取得「Status」が「Settlement Offered」に変更された時点のタイムスタンプ。イベントタイプ inferred
	調査完了	保険金請求に関する証拠の収集と分析フェーズが完了したことを示します。通常は、「Investigation in Progress」から「Pending Decision」または同様の状態へステータスが変更されたことから推定されます。
重要な理由このマイルストーンは、調査サブプロセスの終了を示します。調査サイクル時間を正確に測定できるため、この重要なフェーズの改善に役立ちます。入手先「Claim」オブジェクトの「Status」フィールドに対するField History Trackingから推定され、調査中のステータスから変更された時点のタイムスタンプを記録します。取得「Status」フィールドが「Investigation」から変更された時点のタイムスタンプ。イベントタイプ inferred
	調査開始	保険金請求の詳細な調査フェーズが正式に始まったことを示します。このイベントは通常、「Claim」オブジェクトのステータスが「Investigation in Progress」などに変更されたことから推定されます。
重要な理由このアクティビティは、重要で、長期化することも多いサブプロセスの開始点です。調査サイクル時間を測定することで、証拠の収集や分析におけるボトルネックを特定しやすくなります。入手先 Field History Trackingで取得した、「Claim」オブジェクトの「Status」フィールド変更時のタイムスタンプから推定します。取得「Status」フィールドが「Investigation」に変更された時点のタイムスタンプ。イベントタイプ inferred
	請求割り当て	請求が特定の査定担当者またはチームに割り当てられ、処理を開始できる状態になったことを示します。「Claim」オブジェクトの「OwnerId」フィールドに値が入力された時点、またはキューからユーザーに変更された時点を追跡して取得します。
重要な理由割り当てを追跡すると、リソースの業務量を分析し、査定担当者が作業を始める前の遅延を特定できます。請求がキューで待機し、実際に管理されるまでの時間を測定するのにも役立ちます。入手先「Claim」オブジェクトの「OwnerId」フィールドに対するField History Trackingから取得します。キューから特定のユーザーへ変更された時点のタイムスタンプが、このイベントを示します。取得「OwnerId」フィールドがキューからユーザーに変更された時点のタイムスタンプ。イベントタイプ inferred
	請求登録	初期データ入力後、システム上で請求が正式に受け付けられ、登録されたことを示します。通常は、「Claim」オブジェクトのステータス変更から推定します。たとえば、「Draft」から「New」または「Submitted」への変更です。
重要な理由請求が正式に処理キューへ入ったことを確認するアクティビティです。受付から登録までの時間によって、初期データ検証や受付チームのバックログを把握できます。入手先「Claim」オブジェクトの「Status」フィールドについて、Field History Trackingで登録済みステータスへの変更時刻を取得して推定します（例：「New」、「Open」）。取得「Status」フィールドが「New」または「Registered」に変更された時点のタイムスタンプ。イベントタイプ inferred
	追加情報の受領	依頼した情報を受け取り、請求処理を再開できる状態になったことを示します。「Claim」オブジェクトのステータスが「Pending」状態から「Under Review」などのアクティブな状態に戻った時点から推定します。
重要な理由「Information Requested」から「Information Received」までの時間は、大きなボトルネックになることがあります。この期間を分析すると、外部依存関係とコミュニケーションの有効性を把握できます。入手先「Claim」オブジェクトの「Status」フィールドについて、Field History Trackingで「Pending Information」からアクティブなステータスに変更された時点のタイムスタンプを取得して推定します。取得「Status」フィールドが保留状態から変更された時点のタイムスタンプ。イベントタイプ inferred

推奨任意

抽出ガイド

Salesforce Financial Services Cloudからデータを取得する方法

ステップ

前提条件の準備：Python 3.6以降がインストールされていることを確認します。次のコマンドで必要なライブラリをインストールします：pip install simple-salesforce pandas。
Salesforce APIアクセス：APIアクセスを有効にしたSalesforceユーザーアカウントがあることを確認します。ユーザー名、パスワード、セキュリティトークンが必要です。セキュリティ上、API専用のユーザーを用意することを強く推奨します。
Pythonスクリプトの準備：新しいPythonファイル（例：extract_claims_log.py）を作成し、クエリセクションに記載された完全なスクリプトをコピーします。
スクリプトパラメーターの設定：スクリプトを開き、先頭にあるプレースホルダー変数を変更します。Salesforceの認証情報（SF_USERNAME、SF_PASSWORD、SF_TOKEN）、抽出期間（START_DATE、END_DATE）、Salesforceのオブジェクトと項目のAPI名（例：CLAIM_OBJECT_API_NAME、STATUS_FIELD_API_NAME）が含まれます。
アクティビティのマッピング定義：スクリプトのSTATUS_TO_ACTIVITY_MAP辞書を確認します。Salesforce固有のステータス値を、プロセスマイニングに必要な標準アクティビティ名へ変換するための重要な設定です。キー（Salesforceのステータス）をシステムの設定に合わせて調整します。
スクリプトの実行：ターミナルで次のコマンドを実行します：python extract_claims_log.py。スクリプトがSalesforceに接続し、必要なSOQLクエリを実行してデータ処理を開始します。
実行状況の確認：スクリプトには、取得したクレーム数や生成したイベント数など、進捗を表示するprint文が含まれています。データ量が多い場合は数分かかることがあります。
出力ファイルの確認：スクリプトが正常に完了すると、同じディレクトリにclaims_event_log.csvというCSVファイルが生成されます。
データ検証：CSVファイルを表計算ソフトで開きます。アップロード前に、validationStepsセクションに記載された確認を行い、データが完全かつ正確であることを確認します。
アップロードの準備：生成されたCSVは、プロセスマイニングツールへ直接アップロードできる形式です。列見出し（ClaimId、ActivityName、EventTimeなど）が対象システムの要件と完全に一致していることを確認します。

設定

Salesforce Connected App：本番環境では、ユーザー名とパスワードによる認証ではなく、OAuth 2.0認証に対応したSalesforce Connected Appの使用を推奨します。セキュリティを高めるため、スクリプトをこの方式に変更できます。
APIユーザー権限：抽出を実行するSalesforceユーザーには、スクリプトで指定するすべてのオブジェクトと項目への少なくとも「Read」アクセス権が必要です。主クレームオブジェクト（例：Claim__c）、その履歴オブジェクト（Claim__History）、Userなどの関連オブジェクトが含まれます。
日付範囲（START_DATE、END_DATE）：データ量を管理するため、具体的で適切な日付範囲を設定します。初回分析では3～6か月分のデータを抽出するのが一般的です。APIのガバナ制限や長時間の実行を避けるため、範囲を広げすぎないでください。
オブジェクトと項目のマッピング：スクリプトではCLAIM_OBJECT_API_NAME、STATUS_FIELD_API_NAMEなどのプレースホルダーを使用しています。Salesforce Financial Services Cloudインスタンスで実際に使用しているAPI名に置き換える必要があります。正しいAPI名はSalesforceのSetupにある「Object Manager」で確認できます。
APIバージョン：simple-salesforceライブラリではAPIバージョンを指定できます。スクリプトの既定値は新しいバージョンですが、連携要件に応じて特定のバージョンに設定できます（sf = Salesforce(..., version='58.0')）。
バッチ処理：数百万件のレコードなど、データセットが非常に大きい場合は、メモリ使用量を管理し、APIのタイムアウトを避けるため、クレームをバッチ単位で処理するようスクリプトを変更する必要があります。

a サンプルクエリ python

import pandas as pd
from simple_salesforce import Salesforce
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Salesforce Credentials (use environment variables or a secure vault in production)
SF_USERNAME = class="hl-string">'[your_salesforce_username]'
SF_PASSWORD = class="hl-string">'[your_salesforce_password]'
SF_TOKEN = class="hl-string">'[your_salesforce_security_token]'

class=class="hl-string">"hl-comment"># Date Range for Extraction (ISO 8601 format)
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'

class=class="hl-string">"hl-comment"># Salesforce Object & Field API Names (REPLACE with your FSC configuration)
CLAIM_OBJECT_API_NAME = class="hl-string">'Claim__c' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'Case', class="hl-string">'Claim__c'
CLAIM_ID_FIELD = class="hl-string">'Name' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'CaseNumber', class="hl-string">'Name'
STATUS_FIELD_API_NAME = class="hl-string">'Status__c' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'Status', class="hl-string">'ClaimStatus__c'
OWNER_ID_FIELD = class="hl-string">'OwnerId'
CREATED_DATE_FIELD = class="hl-string">'CreatedDate'
LOSS_ESTIMATE_FIELD = class="hl-string">'Loss_Estimate__c' class=class="hl-string">"hl-comment"># Field for class="hl-string">'Loss Assessed' event
CLAIM_TYPE_FIELD = class="hl-string">'Claim_Type__c'
SUBMISSION_CHANNEL_FIELD = class="hl-string">'Submission_Channel__c'
TOTAL_CLAIM_AMOUNT_FIELD = class="hl-string">'Total_Claim_Amount__c'

class=class="hl-string">"hl-comment"># Map your Salesforce status values to standardized Activity Names
class=class="hl-string">"hl-comment"># CRITICAL: This mapping must be configured for your specific Salesforce setup
STATUS_TO_ACTIVITY_MAP = {
    class="hl-string">'New': class="hl-string">'Claim Registered',
    class="hl-string">'Under Review': class="hl-string">'Initial Review Performed',
    class="hl-string">'Pending Customer Information': class="hl-string">'Additional Information Requested',
    class=class="hl-string">"hl-comment"># Use a generic class="hl-string">'Under Review' for info received, as SF history doesn't track the *reason* for a status change
    class=class="hl-string">"hl-comment"># The sequence will show class="hl-string">'Pending' -> class="hl-string">'Under Review', implying receipt of information.
    class="hl-string">'Investigation in Progress': class="hl-string">'Investigation Started',
    class="hl-string">'Pending Decision': class="hl-string">'Investigation Completed',
    class="hl-string">'Approved': class="hl-string">'Claim Decision Made',
    class="hl-string">'Settlement Offered': class="hl-string">'Settlement Offered',
    class="hl-string">'Approved for Payment': class="hl-string">'Payment Authorized',
    class="hl-string">'Paid': class="hl-string">'Payment Issued',
    class="hl-string">'Rejected': class="hl-string">'Claim Rejected',
    class="hl-string">'Denied': class="hl-string">'Claim Rejected',
    class="hl-string">'Closed': class="hl-string">'Claim Closed'
}

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Connecting to Salesforce...")
    sf = Salesforce(username=SF_USERNAME, password=SF_PASSWORD, security_token=SF_TOKEN)
    print(class="hl-string">"Connection successful.")

    class=class="hl-string">"hl-comment"># 1. Fetch all relevant claims to get base attributes and created date
    print(fclass="hl-string">"Fetching claims created between {START_DATE} and {END_DATE}...")
    claim_query = fclass="hl-string">"""
        SELECT 
            Id, {CLAIM_ID_FIELD}, {CREATED_DATE_FIELD}, {OWNER_ID_FIELD}, Owner.Name,
            {CLAIM_TYPE_FIELD}, {DEPARTMENT_FIELD}, {SUBMISSION_CHANNEL_FIELD}, {TOTAL_CLAIM_AMOUNT_FIELD}, {STATUS_FIELD_API_NAME}
        FROM {CLAIM_OBJECT_API_NAME}
        WHERE {CREATED_DATE_FIELD} >= {START_DATE} AND {CREATED_DATE_FIELD} <= {END_DATE}
    """
    claim_results = sf.query_all(claim_query)
    claims_df = pd.DataFrame(claim_results[class="hl-string">'records']).drop(columns=[class="hl-string">'attributes'])
    if claims_df.empty:
        print(class="hl-string">"No claims found for the specified date range. Exiting.")
        return

    class=class="hl-string">"hl-comment"># Create a lookup dictionary for claim attributes
    class=class="hl-string">"hl-comment"># Handle nested Owner.Name structure
    if class="hl-string">'Owner' in claims_df.columns:
        claims_df[class="hl-string">'AssignedAdjuster'] = claims_df[class="hl-string">'Owner'].apply(lambda x: x[class="hl-string">'Name'] if x else None)
        claims_df = claims_df.drop(columns=[class="hl-string">'Owner'])
    claims_lookup = claims_df.set_index(class="hl-string">'Id').to_dict(class="hl-string">'index')
    claim_ids = tuple(claims_df[class="hl-string">'Id'].unique())

    print(fclass="hl-string">"Found {len(claim_ids)} claims. Now fetching history...")

    class=class="hl-string">"hl-comment"># 2. Fetch all field history for the identified claims
    history_query = fclass="hl-string">"""
        SELECT ParentId, Field, OldValue, NewValue, CreatedDate
        FROM {CLAIM_OBJECT_API_NAME}History
        WHERE ParentId IN {claim_ids}
        ORDER BY CreatedDate ASC
    """
    history_results = sf.query_all(history_query)
    history_df = pd.DataFrame(history_results[class="hl-string">'records']).drop(columns=[class="hl-string">'attributes'])

    class=class="hl-string">"hl-comment"># 3. Generate event log from claims and history data
    event_log = []
    extraction_timestamp = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for claim_id, claim_data in claims_lookup.items():
        class=class="hl-string">"hl-comment"># Event: Claim Submitted
        event_log.append({
            class="hl-string">'ClaimId': claim_data.get(CLAIM_ID_FIELD),
            class="hl-string">'ActivityName': class="hl-string">'Claim Submitted',
            class="hl-string">'EventTime': claim_data.get(CREATED_DATE_FIELD),
            class="hl-string">'AssignedAdjuster': claim_data.get(class="hl-string">'AssignedAdjuster'),
            class="hl-string">'ClaimStatus': class="hl-string">'Submitted', class=class="hl-string">"hl-comment"># Initial status at creation
            class="hl-string">'ClaimType': claim_data.get(CLAIM_TYPE_FIELD),
            class="hl-string">'SubmissionChannel': claim_data.get(SUBMISSION_CHANNEL_FIELD),
            class="hl-string">'TotalClaimAmount': claim_data.get(TOTAL_CLAIM_AMOUNT_FIELD)
        })
        
        class=class="hl-string">"hl-comment"># Filter history for the current claim
        claim_history = history_df[history_df[class="hl-string">'ParentId'] == claim_id]

        for _, row in claim_history.iterrows():
            activity_name = None
            
            class=class="hl-string">"hl-comment"># Map status changes to activities
            if row[class="hl-string">'Field'] == STATUS_FIELD_API_NAME:
                activity_name = STATUS_TO_ACTIVITY_MAP.get(row[class="hl-string">'NewValue'])
                class=class="hl-string">"hl-comment"># Special handling for class="hl-string">'Additional Information Received'
                if activity_name == class="hl-string">'Initial Review Performed' and row[class="hl-string">'OldValue'] == class="hl-string">'Pending Customer Information':
                    activity_name = class="hl-string">'Additional Information Received'

            class=class="hl-string">"hl-comment"># Event: Claim Assigned
            elif row[class="hl-string">'Field'] == class="hl-string">'Owner':
                activity_name = class="hl-string">'Claim Assigned'
            
            class=class="hl-string">"hl-comment"># Event: Loss Assessed
            elif row[class="hl-string">'Field'] == LOSS_ESTIMATE_FIELD and row[class="hl-string">'OldValue'] is None and row[class="hl-string">'NewValue'] is not None:
                activity_name = class="hl-string">'Loss Assessed'

            if activity_name:
                event_log.append({
                    class="hl-string">'ClaimId': claim_data.get(CLAIM_ID_FIELD),
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': row[class="hl-string">'CreatedDate'],
                    class="hl-string">'AssignedAdjuster': claims_lookup.get(claim_id, {}).get(class="hl-string">'AssignedAdjuster'),
                    class="hl-string">'ClaimStatus': row[class="hl-string">'NewValue'] if row[class="hl-string">'Field'] == STATUS_FIELD_API_NAME else claims_lookup.get(claim_id, {}).get(STATUS_FIELD_API_NAME),
                    class="hl-string">'ClaimType': claims_lookup.get(claim_id, {}).get(CLAIM_TYPE_FIELD),
                    class="hl-string">'SubmissionChannel': claims_lookup.get(claim_id, {}).get(SUBMISSION_CHANNEL_FIELD),
                    class="hl-string">'TotalClaimAmount': claims_lookup.get(claim_id, {}).get(TOTAL_CLAIM_AMOUNT_FIELD)
                })
    
    if not event_log:
        print(class="hl-string">"No events generated. Check history tracking and status mappings. Exiting.")
        return

    class=class="hl-string">"hl-comment"># 4. Final Transformation and Export
    final_df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Add remaining required columns
    final_df[class="hl-string">'SourceSystem'] = class="hl-string">'SalesforceFSC'
    final_df[class="hl-string">'LastDataUpdate'] = extraction_timestamp
    final_df[class="hl-string">'EndTime'] = final_df[class="hl-string">'EventTime'] class=class="hl-string">"hl-comment"># Set EndTime equal to EventTime for point-in-time events
    final_df[class="hl-string">'Department'] = None class=class="hl-string">"hl-comment"># Placeholder - populate if available

    class=class="hl-string">"hl-comment"># Reorder columns to a standard event log format
    column_order = [
        class="hl-string">'ClaimId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AssignedAdjuster', class="hl-string">'ClaimStatus', class="hl-string">'ClaimType', class="hl-string">'Department',
        class="hl-string">'SubmissionChannel', class="hl-string">'TotalClaimAmount'
    ]
    final_df = final_df[[col for col in column_order if col in final_df.columns]]
    
    class=class="hl-string">"hl-comment"># Sort by case and time
    final_df = final_df.sort_values(by=[class="hl-string">'ClaimId', class="hl-string">'EventTime']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Export to CSV
    output_filename = class="hl-string">'claims_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
    print(fclass="hl-string">"Successfully generated event log with {len(final_df)} events.")
    print(fclass="hl-string">"File saved as: {output_filename}")

if __name__ == class="hl-string">'__main__':
    class=class="hl-string">"hl-comment"># Added placeholders for fields not explicitly requested but common and needed for the script logic
    DEPARTMENT_FIELD = class="hl-string">'[Your_Department_Field__c]'
    main()

準備はできましたか？

このテンプレートには、クレーム処理の最適化に向けて始めるために必要なものがそろっています。今日からデータの準備を始め、改善につながる発見と業務効率化を実現してください。

改善ガイドに戻るテンプレートをダウンロード

クレームの滞留を解消し、今すぐ処理を高速化

ストレートスルー処理率70％を実現し、顧客満足度を高めます。

無料トライアルを開始

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

クレーム処理データテンプレート

クレーム処理データテンプレート

保険金請求処理の属性

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

抽出ガイド

simple-salesforceとpandasを使ったPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

クレームの滞留を解消し、今すぐ処理を高速化

プライバシーを大切にしています