数据模板:理赔处理

Guidewire ClaimCenter
数据模板:理赔处理

您的理赔流程数据模板

欢迎使用您的专属资源,助您优化理赔流程。此模板概述了需要收集的关键 data 属性、要追踪的重要活动,并为 data 提取提供了清晰指导。请使用它来确保您捕获所有必要信息,以便进行全面的流程分析。
  • 建议采集的属性
  • 需追踪的关键活动
  • Guidewire ClaimCenter数据提取指南
不熟悉事件日志?了解 如何创建流程挖掘事件日志.

理赔处理属性

这些推荐的数据字段对于构建一个完整的 event log 以有效地分析您的理赔处理工作流至关重要。
3 必填 4 推荐 15 可选
名称描述
事件时间
EventTime
活动发生的精确日期和时间。
描述

此 timestamp 标志着活动在系统中被记录的确切时刻,是所有基于时间的流程分析的基础。

单个 Claim ID 的 EventTime 按时间顺序排列,可以重建流程流。连续 event 之间的时间差用于计算周期时间、等待时间和处理时间,这对于性能分析、瓶颈识别和 SLA 监控至关重要。

为何重要

此 timestamp 对于 event 排序、计算周期时间和持续时间以及识别流程中的延迟至关重要。

获取方式

通常在Guidewire ClaimCenter的历史记录或审计表中,与事件或活动数据一同出现,常表现为“CreateTime”或“UpdateTime”字段。

示例
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
活动名称
ActivityName
在理赔生命周期特定环节发生的业务活动或 event 的名称。
描述

此属性描述了理赔流程中的一个具体步骤或里程碑,例如“理赔创建”、“调查启动”或“付款发出”。特定理赔ID下这些活动的顺序构成了流程。

分析活动之间的顺序、频率和持续时间是Process Mining的核心。它有助于发现流程模型、识别瓶颈、检测返工循环,并分析流程偏差。

为何重要

它定义了流程的各个步骤,从而能够可视化流程图并分析流程流向和瓶颈。

获取方式

这通常源自 ClaimCenter 中的 event 表或审计日志,通常通过将特定系统 event 或状态变更映射到标准化的活动名称来得出。

示例
索赔已创建责任判定已完成付款已发出索赔已结案
索赔ID
ClaimID
每个保险理赔的唯一标识符,作为主要的案件标识符。
描述

Claim ID 是理赔流程分析的基石,它唯一标识了从提交到结案的每一个案件。它关联所有相关的活动、文档、付款和沟通,确保对理赔的整个生命周期有一个完整且连贯的视图。

在 Process Mining 中,数据集中的每个 event 都与一个 Claim ID 绑定,从而可以重建端到端流程。这对于分析周期时间、识别流程变体以及追踪理赔跨不同部门和理赔员的历程至关重要。

为何重要

它是连接所有相关事件的基础键,从而可以追踪和分析单个索赔的整个生命周期。

获取方式

这是 Guidewire ClaimCenter 中的一个 primary key,通常是 Claim.ClaimNumber 或核心 Claim 实体中的类似字段。

示例
000-123-45678000-987-65432001-456-11223
指派的理赔员
AssignedAdjuster
被指派处理理赔或特定活动的用户名称或 ID。
描述

此属性标识在给定时间点负责索赔的个人理赔员。理赔员可能负责整个索赔,或负责索赔中的特定任务。

按“指定理赔员”进行分析对于工作量平衡、绩效管理和识别培训机会至关重要。它有助于回答诸如:“哪些理赔员的案件量最大?”、“理赔员之间是否存在绩效差异?”以及“工作分配是否均匀?”等问题。

为何重要

追踪用户参与情况,从而能够进行 workload 分析、性能比较以及识别与资源相关的瓶颈。

获取方式

在 ClaimCenter 的理赔或风险敞口实体中可用,通常与用户对象关联(例如:Claim.Assignee)。

示例
j.doem.smiths.jones
损失原因
LossCause
损失事件的具体原因(例如:Collision、Fire、Water Damage)。
描述

此属性提供了关于理赔提出原因的详细背景信息。损失原因通常决定了所需的调查步骤、所需的专家类型以及理赔的整体复杂性。

通过“损失原因”分析流程可以揭示隐藏的模式。例如,“水灾”相关的理赔可能比“盗窃”理赔具有更高的返工率或需要更多专家参与。这些洞察有助于制定更专业、更高效的处理程序。

为何重要

提供理赔性质的背景信息,有助于分析不同损失原因如何影响流程流和持续时间。

获取方式

这是 Claim 实体上的一个标准字段,通常称为“LossCause”。

示例
碰撞火灾水损盗窃
索赔状态
ClaimStatus
event 发生时理赔的整体状态(例如:Open、Closed、Denied)。
描述

此属性反映了理赔的高层状态。主要状态包括“开放”、“关闭”、“拒绝”和“重新开启”。理赔的最终状态是一个关键的结果metric。

追踪Claim Status的变化有助于定义关键流程milestone和outcome。它用于识别理赔的最终解决方式、计算rejection rates,并分析理赔关闭后被重新开启的频率,这通常表明流程存在问题或客户不满意。

为何重要

指示索赔的最终结果,这对于分析拒赔率、结案模式和索赔重新开启频率至关重要。

获取方式

这是 Claim 实体上的一个核心字段,通常命名为“State”或“Status”。

示例
未结已结案已拒绝已重新开立
索赔类型
ClaimType
保险理赔的类别,例如汽车险、财产险或责任险。
描述

索赔类型是根据业务线或损失性质对索赔进行的基本分类。不同类型的索赔通常遵循不同的处理流程,复杂程度各异,并受不同法规的约束。

按索赔类型划分流程分析对于获得有意义的洞察至关重要。这有助于比较不同业务线间的流程绩效,识别特定类型的瓶颈,并根据各类索赔的独特特征量身定制流程改进方案。

为何重要

允许对理赔进行细分,因为不同类型的理赔(例如:车险理赔与财产险理赔)通常遵循不同的流程,并有不同的绩效目标。

获取方式

源自ClaimCenter中的保单或理赔实体,通常基于业务线(LOB)代码。

示例
个人汽车商业财产险一般责任险工伤赔偿
SLA 状态
SLAState
指示索赔是否在目标结案日期内完成。
描述

此计算属性提供了每项已结案理赔的SLA合规性分类状态。它通过比较“Claim Closed”活动的时间戳与“Resolution Target Date”得出。

此属性直接支持“Claim Resolution Target Adherence”仪表板,将分析简化为“按时”或“逾期”等明确类别。它方便进行筛选和聚合,以计算总体SLA合规率并深入分析延迟原因。

为何重要

提供清晰的SLA合规性分类结果,便于过滤、汇总和分析准时履行情况。

获取方式

计算字段:IF (ActualCloseDate <= ResolutionTargetDate, '按时', '延迟')。

示例
及时逾期
保单类型
PolicyType
提出理赔所依据的具体的保险单类型。
描述

保单类型提供了比理赔类型更细致的分类,详细说明了具体的保险产品,例如‘房屋保险’、‘商业车险’或‘网络责任险’。这种详细程度有助于揭示与特定产品相关的流程差异。

通过按保单类型分析流程,可以发现产品特有的低效。例如,新推出的保单可能遵循一套尚不成熟的流程,从而导致延误。此类分析可以为产品设计和流程标准化工作提供重要参考。

为何重要

可对特定保险产品进行流程分析,帮助识别基于保单具体情况的处理差异。

获取方式

此信息位于 Policy 实体中,并与 Claim 相关联。

示例
房屋多险种商业汽车责任险内陆水运保险
最新数据更新
LastDataUpdate
指示数据最后一次从源系统刷新或提取的时间戳。
描述

此属性提供了从源系统最新data pull的时间戳。它是一个metadata field,对于理解分析结果的时效性至关重要。

Dashboards和分析报告应突出显示此信息,以便用户了解data的即时性。这有助于评估获得的insights是否反映了当前的运营状态,还是基于older data。

为何重要

指示数据的时效性,确保用户了解流程分析的实时程度。

获取方式

此值在 ETL 过程中生成并存储,表示 data 加载的 timestamp。

示例
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
处理时间
ProcessingTime
积极处理某项活动所花费的持续时间。
描述

处理时间衡量的是一项活动实际进行工作的时间,其计算方式是结束时间与开始时间之间的差值。这与包含等待期的周期时间有所不同。

这项计算指标对于绩效分析至关重要,因为它能将完成任务所需的实际投入与空闲或等待时间区分开来。这有助于准确识别哪些步骤确实耗时,以及可以通过培训、优化工具或流程再设计来提升效率。

为何重要

衡量某项活动的实际工作时间,有助于区分增值时间与等待时间。

获取方式

计算字段:EndTime - StartTime。要求源数据中同时包含这两个时间戳。

示例
PT8HPT15MP2D
损失日期
LossDate
引发理赔的事件或损失发生的日期。
描述

损失日期是指造成理赔的实际事件(例如汽车事故、财产损失)发生之日。这与理赔报告或创建日期不同。

损失日期与“Claim Created”活动之间的时间差(称为报告滞后)是一个重要的 KPI。分析此项可以深入了解客户行为和首次损失通知渠道的有效性。

为何重要

提供理赔来源的关键背景信息,并有助于分析报告延迟(从事件发生到理赔提交的时间)的问题。

获取方式

这是 Claim 实体上的一个基本日期字段,通常命名为“LossDate”。

示例
2023-05-102023-04-202023-05-28
支付金额
PaymentAmount
为支付活动实际支付的金额。
描述

此属性记录了针对每项理赔所支付的每笔单独款项的金额。一项理赔在其生命周期内可能涉及多笔支付。

这对于Process Mining背景下的财务分析至关重要。它可以用于追踪每项理赔的总支出、根据金额分析支付审批时间,并将流程效率低下与财务结果关联起来。例如,周期时间长的理赔可能与更高的总支付额相关联。

为何重要

追踪理赔内的财务 transaction,从而能够分析支付金额及其与流程活动的关系。

获取方式

可在与理赔相关的支付实体中找到,通常在交易或支票表中。

示例
4500.00125000.00500.00
是否自动化
IsAutomated
一个标志,指示某活动是由系统自动执行还是由人工用户操作完成。
描述

此boolean属性区分了由系统执行的活动(例如,automatic reserve creation、system-generated correspondence)和由理赔员手动执行的活动。

分析此属性是理解理赔流程自动化水平的关键。它有助于识别人工干预热点,衡量直通式处理方案的有效性,并通过找出目前由人工执行的重复性、基于规则的任务来发现新的自动化机会。

为何重要

区分系统驱动和人工驱动的活动,这对于自动化分析和识别人工瓶颈至关重要。

获取方式

这通常需要派生。例如,由通用“system”用户记录的 events 可以被标记为自动化。

示例
truefalse
是否返工
IsRework
一个标志,指示某活动是否代表返工循环,即返回到之前的流程阶段。
描述

此计算属性会标记属于返工循环的活动。例如,如果流程从“调查完成”回溯到“调查开始”,则第二次“调查开始”活动将被标记为返工。

识别返工是发现流程效率低下和质量问题的基础。“返工和拒绝频率”仪表板依赖此指标来量化理赔偏离理想“顺利路径”的频率。分析返工原因可以显著提升流程质量和速度。

为何重要

通过明确标示属于返工循环的活动,揭示流程效率低下和潜在的质量问题。

获取方式

Process Mining 工具会通过分析每个 case 的活动序列来计算此值。

示例
truefalse
源系统
SourceSystem
数据提取来源系统。
描述

此属性标识了event data的来源。在现代企业环境中,与理赔相关的event可能来源于多个系统,例如像Guidewire这样的核心系统、文档管理系统或客户portal。

明确源系统对于data governance、解决data不一致问题以及了解流程的技术架构至关重要。它有助于区分核心流程步骤与来自外围系统的支持性活动。

为何重要

识别数据的来源,这对于数据治理以及涉及多个集成系统的分析至关重要。

获取方式

这通常是在 data 提取、转换和加载 (ETL) 过程中添加的静态值。

示例
Guidewire ClaimCenter v10Customer Portal APIDocumentum
管辖州
JurisdictionState
管辖理赔的州或管辖区,它决定了监管要求。
描述

此属性指定了理赔处理所依据的法律管辖区(例如,某个国家或地区的行政区划)。不同管辖区之间的保险法规可能差异很大,从而影响所需的流程步骤、沟通时间表和文档。

这是合规性监控的一个重要属性。通过按“管辖区”分析流程,可以确保符合特定地区的监管要求。它还可以解释由法律限制而非运营效率低下导致的周期时间或流程路径的差异。

为何重要

对于合规性分析至关重要,因为不同司法管辖区有不同的法规会影响理赔流程。

获取方式

理赔实体上的一个标准字段,通常命名为 'JurisdictionState'。

示例
CA纽约TXFL
索赔金额
ClaimedAmount
投保人最初索赔的总金额。
描述

此属性表示索赔人报告的损失金额。这通常是一个初步估算,可能随着理赔调查和准备金的设置而发生变化。

分析“索赔金额”有助于根据财务影响对理赔进行分段。高价值理赔通常遵循比低价值理赔更严格、复杂的流程。比较不同价值范围的流程可以揭示简化处理小额理赔的机会,或对大额理赔施加更严格的控制。

为何重要

允许根据理赔的财务价值进行细分,因为高价值理赔可能遵循不同且更复杂的流程。

获取方式

此信息可能并非单一字段,而是可以从 exposures 中记录的初始损失估算中派生出来。

示例
5000.00150000.00750.50
结束时间
EndTime
指示活动完成时的时间戳。
描述

End Time 标志着一项活动的完成,特别是对于具有可衡量持续时间的任务,例如“Investigation”或“Document Review”。虽然许多 Process Mining 活动是瞬时的(StartTime 足矣),但具有明确开始和结束的活动最好同时用两个时间戳表示。

此属性允许精确计算活动处理时间,这与等待时间不同。它有助于识别哪些具体任务是耗时的,而不仅仅是观察不同步骤之间的长时间延迟。

为何重要

它能够精确测量一项活动所需完成的时间,并将处理时间与等待时间区分开来。

获取方式

这可能需要通过查找逻辑上结束该活动的后续 event 来派生(例如,状态从“In Progress”变为“Completed”)。

示例
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
解决目标日期
ResolutionTargetDate
根据内部或监管 SLA,预期理赔解决的截止日期。
描述

Resolution Target Date 是为理赔结案设定的截止日期,通常由管辖范围、理赔类型和保单条款等因素决定。它作为衡量绩效和合规性的基准。

此属性对于构建 SLA 合规性仪表板和 KPI 至关重要。通过比较实际的“Claim Closed”日期与此目标日期,分析可以自动标记逾期理赔,衡量准时履约率,并识别哪些理赔类型或部门难以达到目标。

为何重要

这是衡量 Service Level Agreement (SLA) 合规性并识别有逾期风险理赔的基准。

获取方式

这可能是一个自定义字段,或是根据 ClaimCenter 中配置的业务规则派生而得,可能与特定的理赔 metrics 相关。

示例
2023-06-142023-07-202023-08-28
部门
Department
负责处理理赔活动的业务单位或部门。
描述

此属性指明了负责理赔的理赔员所属的部门或团队,例如“汽车理赔部”、“财产理赔部”或“特别调查组”。它为流程提供了组织层面的背景信息。

通过“部门”进行分析对于从组织层面理解流程绩效至关重要。它有助于识别跨部门移交延迟、比较团队间的效率,并更有效地在整个理赔机构中分配资源。

为何重要

提供组织背景信息,支持跨不同团队的绩效分析,并突出显示部门间的交接问题。

获取方式

此信息通常与 ClaimCenter 中指定用户或用户组的 profile 关联。

示例
车险理赔部门财产理赔部门特别调查组(SIU)
重复信息请求
RepeatedInfoRequestFlag
一个标志,指示针对同一理赔案件是否发生过不止一次的“请求补充信息”活动。
描述

如果一项理赔有多个“请求额外信息”活动,则此布尔标记设为true。这种情况通常表明初步信息收集阶段存在效率低下。

此属性直接支持“重复信息请求率”KPI。它有助于量化初步事实调查不完整的问题,这可能导致显著的延迟和客户不满。分析带有此标记的理赔案件有助于改进理赔员的检查清单和流程,以确保一次性请求到所有必要信息。

为何重要

识别由于首次信息收集不完整而导致的流程延迟和返工问题。

获取方式

在流程挖掘工具中计算,方法是按每个案件统计“请求补充信息”活动的发生次数。

示例
truefalse
必填 推荐 可选

理赔处理活动

这些是您在 event log 中需要记录的关键流程步骤和重要里程碑,以便进行精确的理赔流程发现和分析。
7 推荐 7 可选
活动描述
付款已发出
此活动标志着支付流程的最后一步,即付款正式发出并发送至财务系统。这是一笔明确且有记录的财务交易。
为何重要

此活动对于衡量支付分发流程的效率至关重要。它有助于区分审批延迟和实际资金发放的延迟。

获取方式

从 cc_check 或 cc_transaction 实体中的 IssueDate,或状态变更为“已签发”或“已提交”时捕获。这通常是一个明确的时间戳事件。

捕获

识别支付记录中 IssueDate 或状态变为“已签发”的时间戳。

事件类型 explicit
付款已批准
代表正式批准和解款项。这是一个关键的审计 event,并在有权限的用户批准该 transaction 时明确记录。
为何重要

这一关键里程碑开启了最终支付步骤。分析此活动之前和之后的时间,有助于隔离由审批 workflow 或经理可用性造成的延迟。

获取方式

这通常是一个明确的 event,记录在 cc_history 表中,与 cc_check 或 cc_transaction 实体相关,表示状态已从“Pending Approval”变更为“Approved”。

捕获

追踪特定支付 transaction 状态变为“已审批”的 event。

事件类型 explicit
初步储备金设置
此事件标志着为风险敞口创建了第一笔财务准备金交易,用于估算理赔的潜在成本。这是一个关键的财务事件,会被明确记录。
为何重要

此里程碑对于财务分析和了解潜在负债评估速度至关重要。延迟会影响财务规划和报告。

获取方式

此事件是从创建第一个与理赔的风险敞口关联的cc_reserveline record时捕获的。事务的CreateTime是事件时间戳。

捕获

查找给定理赔的风险敞口中所有准备金行的最小创建时间戳。

事件类型 explicit
索赔已创建
此活动标志着首次损失通知(FNOL),以及在Guidewire ClaimCenter中正式创建新的理赔记录。当新的理赔实体首次保存到数据库时,此事件会被明确记录。
为何重要

作为主要的开始事件,此活动对于衡量端到端理赔周期时间至关重要。它为所有后续绩效和时长KPI提供了基准。

获取方式

这是一个从 cc_claim 表的 CreateTime 捕获的明确 event。创建带有唯一 Claim ID 的新记录即作为 event 触发器。

捕获

识别基础Claim实体表中新记录的创建时间戳。

事件类型 explicit
索赔已拒绝
代表拒绝理赔的最终决定,作为流程的终点。此 event 通常通过理赔状态变为“已关闭”且原因为“Denied”来推断。
为何重要

这是一个关键的结果 event。分析导致拒绝的频率、原因和流程路径,有助于识别理赔受理、调查或保单解释方面的问题。

获取方式

从 cc_claim 表中 State 字段更改为“已结案”,并结合 CloseReason 字段为“已拒绝”或类似值推断得出。事件时间戳是 CloseDate。

捕获

筛选理赔状态变为“已关闭”且原因代码表明拒绝的记录。

事件类型 inferred
索赔已结案
此事件标志着所有活动和付款完成后,理赔成功结案。这是主要的成功结束事件,通常通过理赔主状态的变化来推断。
为何重要

作为主要的结束事件,此活动对于计算端到端周期时间和衡量SLA合规性至关重要。它标志着理赔生命周期的完成。

获取方式

从 cc_claim 表中 State 字段更改为“已结案”推断得出。事件时间戳是索赔记录上的 CloseDate。

捕获

识别索赔主状态字段更新为“已结案”的时间。

事件类型 inferred
风险已创建
此活动表示创建了一项风险敞口,这代表理赔项下特定的潜在责任或损失类型(例如,车辆损坏、人身伤害)。这是Guidewire系统中的一个明确事件。
为何重要

风险敞口对于理赔的细分和分析至关重要。跟踪它们的创建有助于理解基于理赔复杂性和损失类型的流程差异。

获取方式

从 cc_exposure 表中新记录的 CreateTime 字段捕获。每条记录都关联到一个独立的索赔ID。

捕获

识别Exposure实体表中新记录的创建时间戳。

事件类型 explicit
和解金已计算
此活动代表赔付金额已确定但尚未获批支付的环节。它可以通过在“待审批”状态下创建的支付记录来推断。
为何重要

此事件标志着从评估阶段过渡到付款阶段。它是衡量‘付款授权前置时间’KPI 的起点,旨在揭示审批链中的延迟。

获取方式

从 cc_check 或 cc_transaction 记录的 CreateTime 中推断得出,其中其初始状态为“待批准”或在“已批准”之前的类似状态。

捕获

识别处于预批准状态的支付或交易记录的创建。

事件类型 inferred
已收到补充信息
此事件标志着额外信息请求已完成。当相应的信息请求‘活动’(任务)被标记为‘已完成’时,即会记录下来。
为何重要

这是“额外信息收集周期时间”KPI 的终点。请求与接收之间时长过长,是理赔流程中常见的延迟来源。

获取方式

从 cc_activity 记录的 CloseTime 中获取,其中 ActivityPattern 与信息请求相关。活动的状态必须为“已完成”。

捕获

识别请求外部信息任务的完成时间戳。

事件类型 explicit
已请求补充信息
代表向索赔人或第三方发出的,要求提供更多信息或文件的请求。这通常会在ClaimCenter中以明确的“Activity”(task)形式进行记录。
为何重要

此活动是衡量“额外信息收集周期”KPI的起点。如果此活动频繁发生,可能预示着FNOL流程不完整或信息收集效率低下。

获取方式

从 cc_activity 记录的 CreateTime 字段捕获,其中 ActivityPattern 与向外部方请求文件或信息有关。

捕获

识别请求外部信息任务的创建。

事件类型 explicit
索赔已分配
代表将理赔案件分配给特定用户(理赔员)或小组进行处理。这通常通过监测Claim entity上分配字段的变化来推断。
为何重要

追踪任务分配对于分析理赔员 workload、识别路由瓶颈以及衡量指定处理员的首次行动时间至关重要。

获取方式

从 cc_history 表中,通过追踪与特定索赔ID相关的 AssignedUser 或 AssignedGroup 字段的变化推断得出。更改的时间戳指示事件发生时间。

捕获

监控审计日志或历史表中的理赔分配字段更新。

事件类型 inferred
索赔已重新开启
此事件表示理赔从‘关闭’状态重新转为‘开放’状态,以便执行额外工作。该事件通常通过特定的状态变更序列推断得出。
为何重要

此活动代表返工。大量重新开启的理赔案件表明初次赔付存在问题、有遗漏的损失或其他流程故障,这会导致成本增加和效率低下。

获取方式

从 cc_history 表中,识别 cc_claim 实体 State 字段从“已结案”更改回“开放”或其他活动状态推断得出。

捕获

监控理赔的主状态字段,以识别从关闭到开放状态的转换。

事件类型 inferred
调查已开始
表示索赔或Exposure的正式调查阶段开始。这通常从Guidewire中首次创建与调查相关的“活动”(任务)推断出来。
为何重要

此活动标志着一个关键且通常耗时较长的阶段的开始。通过分析从事件发生到调查启动的时间,以及调查本身的持续时长,可以发现主要的流程瓶颈。

获取方式

从 cc_activity 记录的 CreateTime 中推断得出,其中 ActivityPattern 与调查相关(例如,“初步调查”、“联系证人”)。

捕获

识别首次创建具有调查相关模式或主题的任务。

事件类型 inferred
责任判定已完成
标志着已确定某项 exposure 的责任或过错。此 event 通常通过监测 Exposure entity 状态变化来推断。
为何重要

这是一个关键的决策里程碑,是理赔和支付阶段的入口。分析做出此决策所需的时间,有助于识别调查和评估阶段的瓶颈。

获取方式

从 cc_history 表中,通过追踪 cc_exposure 实体上 State 或自定义责任状态字段的变化推断得出。历史记录的时间戳指示事件时间。

捕获

监控审计日志或历史表中的风险敞口状态或责任状态更新。

事件类型 inferred
推荐 可选

提取指南

如何从Guidewire ClaimCenter获取数据