Plantilla de Datos: Procesamiento de Siniestros

Guidewire ClaimCenter
Plantilla de Datos: Procesamiento de Siniestros

Tu plantilla de datos para la gestión de siniestros.

Bienvenido a su recurso dedicado para optimizar el processing de claims. Esta template describe los data attributes esenciales que debe recopilar, las activities críticas a trackear y proporciona una **guía clara** para la data extraction. Utilícela para asegurarse de capturar toda la **información** necesaria para un **análisis integral de procesos**.
  • Atributos recomendados para recopilar
  • Actividades clave a monitorizar
  • Guía de Extracción para Guidewire ClaimCenter
¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Atributos de Procesamiento de Siniestros

Estos campos de datos recomendados son cruciales para construir un event log completo que permita analizar eficazmente sus workflows de gestión de siniestros.
3 Requerido 4 Recomendado 15 Opcional
NombreDescripción
Hora del Evento
EventTime
La fecha y hora precisas en que ocurrió la actividad.
Descripción

Este timestamp marca el momento exacto en que una activity fue registrada en el system. Es fundamental para todo análisis de procesos basado en tiempo.

El orden cronológico de EventTime para un único Claim ID permite la reconstrucción del process flow. La diferencia de tiempo entre events consecutivos se utiliza para calcular cycle times, waiting times y processing times, que son críticos para el performance analysis, bottleneck identification y SLA monitoring.

Por qué es importante

Este timestamp es esencial para ordenar events, calcular cycle times y durations, e identificar retrasos en el proceso.

Dónde obtener

Se encuentra junto a los datos de eventos o actividades en las tablas de historial o auditoría de Guidewire ClaimCenter, a menudo como un campo 'CreateTime' o 'UpdateTime'.

Ejemplos
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
ID de Siniestro
ClaimID
El identificador único para cada siniestro de seguro, que funciona como el identificador principal del caso.
Descripción

El ID de Siniestro es la piedra angular del análisis de procesos de siniestros, identificando de manera única cada caso desde su presentación hasta su cierre. Vincula todas las actividades, documentos, pagos y comunicaciones asociados, asegurando una visión completa y coherente del ciclo de vida de un siniestro.

En Process Mining, cada evento en el dataset está vinculado a un ID de Siniestro, lo que permite la reconstrucción del flujo de proceso de principio a fin. Esto es esencial para analizar los tiempos de ciclo, identificar variantes de proceso y rastrear el recorrido de un siniestro a través de diferentes departamentos y ajustadores.

Por qué es importante

Es la clave fundamental que vincula todos los eventos relacionados, permitiendo rastrear y analizar el recorrido completo de un único siniestro.

Dónde obtener

Esta es una primary key en Guidewire ClaimCenter, que se encuentra típicamente como Claim.ClaimNumber o un field similar en la entidad Claim principal.

Ejemplos
000-123-45678000-987-65432001-456-11223
Nombre de la Actividad
ActivityName
El nombre de la actividad de negocio o evento que ocurrió en un punto específico del ciclo de vida del siniestro.
Descripción

Este atributo describe un paso o hito específico en el proceso de gestión de siniestros, como 'Siniestro Creado', 'Investigación Iniciada' o 'Pago Emitido'. La secuencia de estas actividades para un ID de Siniestro determinado conforma el flujo del proceso.

Analizar la secuencia, frecuencia y duración entre actividades es el núcleo del Process Mining. Permite el descubrimiento de modelos de proceso, la identificación de cuellos de botella, la detección de ciclos de retrabajo y el análisis de desviaciones del proceso.

Por qué es importante

Define los pasos del proceso, permitiendo la visualización de mapas de procesos y el análisis del flujo del proceso y los cuellos de botella.

Dónde obtener

Esto se suele derivar de tablas de event o audit logs en ClaimCenter, a menudo mapeando events específicos del system o status changes a nombres de activity estandarizados.

Ejemplos
Siniestro CreadoDecisión de Responsabilidad TomadaPago EmitidoSiniestro Cerrado
Ajustador Asignado
AssignedAdjuster
El nombre o ID del usuario asignado para gestionar el siniestro o una actividad específica.
Descripción

Este atributo identifica al ajustador de siniestros individual responsable de un siniestro en un momento dado. Un ajustador puede ser asignado a todo el siniestro o a tareas específicas dentro de este.

El análisis por Ajustador Asignado es fundamental para el equilibrio de la carga de trabajo, la gestión del rendimiento y la identificación de oportunidades de capacitación. Ayuda a responder preguntas como: '¿Qué ajustadores tienen la mayor carga de casos?', '¿Existen variaciones de rendimiento entre los ajustadores?' y '¿Está el trabajo distribuido de manera uniforme?'.

Por qué es importante

Registra la participación del user, lo que permite el workload analysis, performance comparison y la identificación de bottlenecks relacionados con los recursos.

Dónde obtener

Disponible en la entidad de Reclamo o Exposición en ClaimCenter, a menudo vinculado al objeto Usuario (p. ej., Claim.Assignee).

Ejemplos
j.doem.smiths.jones
Causa de la Pérdida
LossCause
El motivo o la causa específica del evento de pérdida (ej. Colisión, Incendio, Daños por Agua).
Descripción

Este atributo proporciona un contexto detallado sobre el motivo por el cual se presentó el siniestro. La causa de la pérdida a menudo dicta los pasos de investigación requeridos, el tipo de expertos necesarios y la complejidad general del siniestro.

El análisis del proceso por Causa de la Pérdida puede revelar patrones ocultos. Por ejemplo, los siniestros relacionados con 'Daños por Agua' podrían tener una tasa de retrabajo más alta o requerir una mayor participación de especialistas en comparación con los siniestros por 'Robo'. Estos insights ayudan a crear procedimientos de manejo más especializados y eficientes.

Por qué es importante

Proporciona contexto sobre la naturaleza del siniestro, permitiendo analizar cómo las diferentes causas de pérdida impactan el flujo y la duración del proceso.

Dónde obtener

Este es un field estándar en la entidad Claim, generalmente llamado 'LossCause'.

Ejemplos
ColisiónIncendioDaños por AguaRobo
Estado del Siniestro
ClaimStatus
El estado general del siniestro en el momento del evento (ej. Abierto, Cerrado, Denegado).
Descripción

Este atributo refleja el estado de alto nivel del siniestro. Los estados clave incluyen 'Abierto', 'Cerrado', 'Denegado' y 'Reabierto'. El estado final de un siniestro es una métrica de resultado crítica.

El seguimiento de los cambios en el Estado del Siniestro ayuda a definir los hitos y resultados clave del proceso. Se utiliza para identificar la resolución final de un siniestro, calcular las tasas de rechazo y analizar la frecuencia con la que los siniestros se reabren después del cierre, lo que a menudo indica problemas en el proceso o insatisfacción del cliente.

Por qué es importante

Indica el desenlace de un siniestro, lo cual es esencial para analizar las tasas de rechazo, los patrones de cierre y la frecuencia de reapertura de siniestros.

Dónde obtener

Este es un campo esencial de la entidad Claim, generalmente llamado 'State' o 'Status'.

Ejemplos
AbiertaCerradoDenegadoReabierto
Tipo de Siniestro
ClaimType
La categoría del siniestro de seguro, como Automóvil, Propiedad o Responsabilidad Civil.
Descripción

El Tipo de Siniestro es una categorización fundamental de un siniestro basada en la línea de negocio o la naturaleza de la pérdida. Diferentes tipos de siniestro a menudo siguen procesos distintos, tienen diferentes niveles de complejidad y están sujetos a diversas regulaciones.

Segmentar el análisis de procesos por Tipo de Siniestro es fundamental para obtener insights significativos. Permite comparar el rendimiento de los procesos en las distintas líneas de negocio, identificar cuellos de botella específicos de cada tipo y adaptar las iniciativas de mejora de procesos a las características únicas de cada categoría de siniestro.

Por qué es importante

Permite la segmentación de reclamos, ya que diferentes tipos (p. ej., Automóvil vs. Propiedad) a menudo siguen procesos distintos y tienen diferentes objetivos de rendimiento.

Dónde obtener

Derivado de la entidad de Póliza o Siniestro en ClaimCenter, a menudo basado en el código de Línea de Negocio (LOB).

Ejemplos
Automóvil ParticularPropiedad ComercialResponsabilidad Civil GeneralCompensación Laboral
Departamento
Department
La unidad de negocio o departamento responsable de gestionar la actividad del siniestro.
Descripción

Este atributo indica el departamento o equipo al que pertenece el ajustador asignado, como 'Siniestros de Automóviles', 'Siniestros de Propiedad' o 'Unidad de Investigaciones Especiales'. Proporciona un contexto organizacional para el proceso.

El análisis por Departamento es crucial para comprender el rendimiento del proceso a nivel organizacional. Ayuda a identificar retrasos en traspasos interdepartamentales, comparar la eficiencia entre equipos y asignar recursos de manera más efectiva en toda la organización de siniestros.

Por qué es importante

Proporciona contexto organizacional, permitiendo el análisis de rendimiento entre diferentes equipos y destacando los problemas de traspaso interdepartamental.

Dónde obtener

Esta información suele estar asociada al perfil del user o grupo asignado dentro de ClaimCenter.

Ejemplos
División de Reclamos de AutomóvilesUnidad de Siniestros PatrimonialesUnidad de Investigaciones Especiales (SIU)
Es Automatizado
IsAutomated
Un indicador que señala si una actividad fue realizada automáticamente por el sistema o por un usuario humano.
Descripción

Este atributo booleano distingue entre actividades ejecutadas por un sistema (por ejemplo, creación automática de reservas, correspondencia generada por el sistema) y aquellas realizadas manualmente por un ajustador.

Analizar este atributo es clave para comprender el nivel de automatización en el proceso de siniestros. Ayuda a identificar puntos críticos de intervención manual, medir la efectividad de las iniciativas de procesamiento directo y encontrar nuevas oportunidades de automatización al señalar tareas repetitivas y basadas en reglas que actualmente son realizadas por humanos.

Por qué es importante

Distingue entre actividades impulsadas por el sistema y actividades realizadas por humanos, clave para el análisis de automatización y la identificación de cuellos de botella manuales.

Dónde obtener

Esto a menudo necesita ser derivado. Por ejemplo, los events registrados por un user genérico de 'system' pueden ser marcados como automated.

Ejemplos
truefalse
Es Retrabajo
IsRework
Un indicador que señala si una actividad representa un ciclo de retrabajo, es decir, un retorno a una etapa previa del proceso.
Descripción

Este atributo calculado identifica actividades que forman parte de un ciclo de retrabajo o reprocesamiento. Por ejemplo, si el proceso regresa de 'Investigation Completed' a 'Investigation Started', la segunda actividad de 'Investigation Started' se marcará como retrabajo.

Detectar el retrabajo es fundamental para identificar ineficiencias y problemas de calidad en los procesos. El dashboard de 'Frecuencia de Retrabajo y Rechazo' utiliza esta métrica para cuantificar con qué frecuencia los claims se desvían de la 'ruta ideal'. Analizar las causas del retrabajo puede generar mejoras significativas en la calidad y velocidad del proceso.

Por qué es importante

Destaca las ineficiencias del proceso y los problemas de calidad al identificar explícitamente las actividades que forman parte de un ciclo de reelaboración.

Dónde obtener

Esto se calcula dentro de la herramienta de process mining al analizar la secuencia de activities para cada case.

Ejemplos
truefalse
Estado de Jurisdicción
JurisdictionState
El estado o la jurisdicción que rige el siniestro, el cual dicta los requisitos regulatorios.
Descripción

Este atributo especifica la jurisdicción legal (por ejemplo, el estado de EE. UU.) bajo la cual se está tramitando el siniestro. Las regulaciones de seguros pueden variar significativamente entre jurisdicciones, impactando los pasos de proceso requeridos, los plazos de comunicación y la documentación.

Este es un atributo vital para el monitoreo del cumplimiento. Analizar el proceso por jurisdicción asegura que se cumplan los requisitos reglamentarios específicos de cada estado. También puede explicar variaciones en los tiempos de ciclo o en las rutas del proceso que están impulsadas por restricciones legales y no por ineficiencia operativa.

Por qué es importante

Crucial para el análisis de cumplimiento, ya que diferentes jurisdicciones tienen regulaciones distintas que afectan al proceso de siniestros.

Dónde obtener

Un campo estándar en la entidad de Reclamo, típicamente llamado 'JurisdictionState'.

Ejemplos
CANYTXFL
Estado de SLA
SLAState
Indica si el siniestro se cerró dentro de su fecha objetivo de resolución.
Descripción

Este atributo calculado ofrece un estado categórico del cumplimiento de los SLA para cada claim cerrado. Se obtiene comparando el timestamp de la actividad 'Claim Closed' con la 'Resolution Target Date'.

Este atributo es un pilar fundamental para el dashboard de 'Cumplimiento del Objetivo de Resolución de Claims', ya que simplifica el análisis en categorías claras como 'On Time' o 'Late'. Facilita el filtrado y la agregación para calcular la tasa global de cumplimiento de SLA y para desglosar las razones de los delays.

Por qué es importante

Proporciona un resultado claro y categórico para el cumplimiento del SLA, facilitando la filtración, agregación y análisis del rendimiento a tiempo.

Dónde obtener

Campo calculado: IF (ActualCloseDate <= ResolutionTargetDate, 'A Tiempo', 'Retrasado').

Ejemplos
A TiempoRetrasado
Fecha del Siniestro
LossDate
La fecha en la que ocurrió el incidente o la pérdida que desencadenó el siniestro.
Descripción

La Fecha de Siniestro es la fecha del evento real (ej. accidente automovilístico, daño a la propiedad) por el cual se presenta el siniestro. Esta es distinta de la fecha en que se reportó o creó el siniestro.

El desfase temporal entre la Fecha de Siniestro y la actividad 'Siniestro Creado' (conocido como retraso de reporte) es un KPI importante. Analizar esto puede proporcionar insights sobre el comportamiento del cliente y la efectividad de los canales de primera notificación de siniestro.

Por qué es importante

Proporciona contexto crucial sobre el origen del siniestro y ayuda a analizar el retraso en el reporte (tiempo desde el incidente hasta la presentación del siniestro).

Dónde obtener

Este es un campo de fecha fundamental en la entidad Claim, a menudo llamado 'LossDate'.

Ejemplos
2023-05-102023-04-202023-05-28
Fecha Objetivo de Resolución
ResolutionTargetDate
La fecha en la que se espera que el siniestro sea resuelto según los SLA internos o regulatorios.
Descripción

La Fecha Objetivo de Resolución es una fecha límite establecida para el cierre de un siniestro, a menudo determinada por factores como la jurisdicción, el tipo de siniestro y los términos de la póliza. Sirve como un punto de referencia para medir el rendimiento y el cumplimiento.

Este atributo es crítico para construir dashboards y KPIs de cumplimiento de SLA. Al comparar la fecha real de 'Siniestro Cerrado' con esta fecha objetivo, el análisis puede marcar automáticamente los siniestros atrasados, medir las tasas de rendimiento a tiempo e identificar qué tipos de siniestros o departamentos tienen dificultades para cumplir sus objetivos.

Por qué es importante

Este es el parámetro de referencia para medir el cumplimiento de los Service Level Agreement (SLA) y para identificar los claims en riesgo de sufrir delays.

Dónde obtener

Este puede ser un custom field o derivado según las business rules configuradas en ClaimCenter, posiblemente relacionado con metrics de claim específicas.

Ejemplos
2023-06-142023-07-202023-08-28
Hora de Finalización
EndTime
El timestamp que indica cuándo se completó una actividad.
Descripción

La Hora de Finalización marca la culminación de una actividad, especialmente para tareas con una duración medible, como 'Investigación' o 'Revisión de Documentos'. Aunque muchas actividades de Process Mining son instantáneas (el StartTime es suficiente), las actividades con un inicio y fin distintos se representan mejor con ambos timestamps.

Este atributo permite el cálculo preciso del tiempo de procesamiento de la actividad, distinto del tiempo de espera. Ayuda a identificar qué tareas específicas consumen mucho tiempo, en lugar de solo observar largos retrasos entre diferentes pasos.

Por qué es importante

Permite medir con precisión cuánto tiempo lleva completar una actividad, separando el tiempo de procesamiento del tiempo de espera.

Dónde obtener

Esto puede necesitar ser derivado al encontrar un event posterior que concluya lógicamente la activity (por ejemplo, un status change de 'In Progress' a 'Completed').

Ejemplos
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Monto del Pago
PaymentAmount
El monto real de dinero pagado por una actividad de pago.
Descripción

Este atributo registra el valor de cada pago individual realizado contra un siniestro. Un único siniestro puede tener múltiples pagos a lo largo de su ciclo de vida.

Esto es esencial para el análisis financiero dentro del contexto de Process Mining. Se puede usar para rastrear el desembolso total por siniestro, analizar los tiempos de aprobación de pagos según el monto y vincular las ineficiencias del proceso con los resultados financieros. Por ejemplo, los siniestros con largos tiempos de ciclo podrían correlacionarse con pagos totales más altos.

Por qué es importante

Registra las financial transactions dentro de un claim, permitiendo el análisis de los payment values y su relación con las actividades del proceso.

Dónde obtener

Se encuentra en entidades relacionadas con pagos vinculadas al siniestro, a menudo en una tabla de transacciones o cheques.

Ejemplos
4500.00125000.00500.00
Monto Reclamado
ClaimedAmount
El monto total reclamado inicialmente por el asegurado.
Descripción

Este atributo representa el valor de la pérdida tal como lo informa el reclamante. A menudo es una estimación inicial que puede cambiar a medida que se investiga el siniestro y se establecen las reservas.

El análisis del Monto Reclamado ayuda a segmentar los siniestros por impacto financiero. Los siniestros de alto valor a menudo siguen un proceso más riguroso y complejo que los de bajo valor. Comparar el proceso para diferentes rangos de valor puede revelar oportunidades para agilizar el manejo de siniestros más pequeños o aplicar controles más estrictos para los más grandes.

Por qué es importante

Permite segmentar los reclamos por valor financiero, ya que los reclamos de alto valor pueden seguir procesos diferentes y más complejos.

Dónde obtener

Esta información podría no ser un campo único, sino que se puede derivar de las estimaciones iniciales de pérdidas registradas en las exposiciones.

Ejemplos
5000.00150000.00750.50
Sistema de Origen
SourceSystem
El sistema del cual se extrajeron los datos.
Descripción

Este atributo identifica el origen de los datos del evento. En un entorno empresarial moderno, los eventos relacionados con siniestros pueden originarse de múltiples sistemas, como un sistema central tipo Guidewire, un sistema de gestión documental o un portal del cliente.

Especificar el sistema de origen es crucial para la gobernanza de datos, la resolución de problemas de inconsistencias de datos y la comprensión del panorama tecnológico del proceso. Ayuda a diferenciar entre los pasos centrales del proceso y las actividades de soporte de sistemas periféricos.

Por qué es importante

Identifica el origen de los datos, lo cual es crucial para el gobierno de datos y para los análisis que involucran múltiples sistemas integrados.

Dónde obtener

Este suele ser un valor estático que se añade durante el proceso de data extraction, transformation, and loading (ETL).

Ejemplos
Guidewire ClaimCenter v10API del Portal del ClienteDocumentum
Solicitud de Información Repetida
RepeatedInfoRequestFlag
Un indicador que señala si se ha solicitado 'Información Adicional' más de una vez para el mismo reclamo.
Descripción

Este flag booleano se establece en true si un siniestro tiene más de una actividad de 'Solicitud de Información Adicional'. Este escenario a menudo señala ineficiencias en la fase inicial de recopilación de información.

Este atributo apoya directamente el KPI de 'Tasa de Solicitudes de Información Repetidas'. Ayuda a cuantificar el problema de la investigación inicial incompleta, que puede conducir a retrasos significativos y frustración del cliente. Analizar los siniestros con este flag puede ayudar a mejorar las listas de verificación y los procedimientos para los ajustadores a fin de garantizar que toda la información necesaria se solicite de una sola vez.

Por qué es importante

Identifica ineficiencias donde la recopilación de información no se realiza de forma exhaustiva la primera vez, lo que genera retrasos en el proceso y reelaboración.

Dónde obtener

Calculado dentro de la herramienta de process mining contando las ocurrencias de la actividad 'Información Adicional Solicitada' por caso.

Ejemplos
truefalse
Tiempo de Procesamiento
ProcessingTime
La duración del tiempo invertido activamente en una actividad.
Descripción

El Tiempo de Procesamiento mide el tiempo en que una actividad se trabaja activamente, calculado como la diferencia entre su Hora de Finalización y Hora de Inicio. Esto es distinto del tiempo de ciclo, que incluye los períodos de espera.

Esta métrica calculada es vital para el análisis del rendimiento, ya que aísla el esfuerzo real requerido para una tarea del tiempo de inactividad o espera. Ayuda a identificar con precisión qué pasos son realmente lentos y dónde se pueden lograr ganancias de eficiencia mediante capacitación, mejores herramientas o rediseño de procesos.

Por qué es importante

Mide el tiempo de trabajo activo para una actividad, ayudando a distinguir el tiempo de valor añadido del tiempo de espera.

Dónde obtener

Campo calculado: EndTime - StartTime. Requiere que ambos timestamps estén disponibles en los datos de origen.

Ejemplos
PT8HPT15MP2D
Tipo de Póliza
PolicyType
El tipo específico de póliza de seguro bajo la cual se presentó el siniestro.
Descripción

El Tipo de Póliza proporciona una clasificación más granular que el Tipo de Siniestro, detallando el producto de seguro específico, como 'Seguro de Hogar', 'Automóvil Comercial' o 'Ciberseguro'. Este nivel de detalle puede revelar variaciones en los procesos vinculadas a productos específicos.

Analizar el proceso por Tipo de Póliza ayuda a descubrir ineficiencias específicas de cada producto. Por ejemplo, los siniestros de una póliza recién lanzada podrían seguir un proceso menos maduro, lo que generaría retrasos. Este análisis puede informar el diseño de productos y los esfuerzos de estandarización de procesos.

Por qué es importante

Permite el análisis de procesos para productos de seguros específicos, ayudando a identificar variaciones en la gestión basadas en las particularidades de la póliza.

Dónde obtener

Esta información se encuentra en la entidad Policy, la cual está vinculada al Claim.

Ejemplos
Seguro Multirriesgo de HogarResponsabilidad Civil de Vehículos ComercialesMarítimo Interior
Última Actualización de Datos
LastDataUpdate
El timestamp que indica la última vez que se actualizaron o extrajeron los datos del sistema de origen.
Descripción

Este atributo proporciona el timestamp de la extracción de datos más reciente del sistema de origen. Es un campo de metadatos esencial para comprender la actualidad del análisis.

Los dashboards y análisis deben mostrar esta información de forma destacada para que los usuarios sean conscientes de la vigencia de los datos. Ayuda a evaluar si los conocimientos reflejan el estado actual de las operaciones o se basan en datos más antiguos.

Por qué es importante

Indica la vigencia de los datos, asegurando que los usuarios comprendan lo actualizado que está el análisis del proceso.

Dónde obtener

Este valor se genera y almacena durante el proceso ETL, representando el timestamp de la data load.

Ejemplos
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Requerido Recomendado Opcional

Actividades de Procesamiento de Siniestros

Estos son los pasos clave del proceso y los hitos importantes a registrar en su event log para el descubrimiento y análisis precisos de la gestión de siniestros.
7 Recomendado 7 Opcional
ActividadDescripción
Exposición Creada
Esta actividad significa la creación de una exposición, que representa una responsabilidad potencial específica o un tipo de pérdida bajo el siniestro (por ejemplo, daños al vehículo, lesiones). Este es un evento explícito en Guidewire.
Por qué es importante

Las exposiciones son fundamentales para la segmentación y el análisis de siniestros. Rastrear su creación ayuda a comprender las variaciones del proceso basándose en la complejidad del siniestro y el tipo de pérdida.

Dónde obtener

Capturado del CreateTime de un nuevo registro en la tabla cc_exposure. Cada registro está vinculado a un único Claim ID.

Capturar

Identificar la marca de tiempo (timestamp) de creación de un nuevo registro en la tabla de entidad Exposure.

Tipo de evento explicit
Pago Aprobado
Representa la aprobación formal de un pago de liquidación. Este es un evento de auditoría crítico y se captura explícitamente cuando un usuario con autoridad aprueba la transacción.
Por qué es importante

Este hito clave desbloquea el paso de payment final. Analizar el tiempo antes y después de esta activity ayuda a aislar los retrasos causados por los workflows de aprobación o la disponibilidad de los managers.

Dónde obtener

Este suele ser un event explícito registrado en la tabla cc_history relacionado con una entidad cc_check o cc_transaction, que anota un cambio de status de 'Pending Approval' a 'Approved'.

Capturar

Seguir el event de status change a 'Approved' para una payment transaction específica.

Tipo de evento explicit
Pago Emitido
Esta actividad marca el paso final en el proceso de pago, donde el pago se emite oficialmente y se envía al sistema financiero. Se trata de una transacción financiera explícita y registrada.
Por qué es importante

Esta actividad es crucial para medir la eficiencia del proceso de desembolso de pagos. Ayuda a diferenciar entre los retrasos en la aprobación y los retrasos en la emisión de fondos.

Dónde obtener

Capturado del IssueDate o un cambio de estado a 'Issued' o 'Submitted' en la entidad cc_check o cc_transaction. Esto suele ser un event explícito con timestamp.

Capturar

Identificar la IssueDate o la marca de tiempo (timestamp) del cambio de estado a 'Issued' en el registro de pago.

Tipo de evento explicit
Reserva Inicial Establecida
Marca la creación de la primera transacción de reserva financiera para un riesgo, estimando el costo potencial del siniestro. Este es un evento financiero crítico y se registra explícitamente.
Por qué es importante

Este hito es clave para el análisis financiero y para comprender la rapidez con la que se evalúa la liability potencial. Los retrasos pueden impactar la financial planning y el reporting.

Dónde obtener

Este event se registra con la creación del primer registro cc_reserveline asociado a una exposición en el claim. El CreateTime de la transaction es el event timestamp.

Capturar

Encuentre el timestamp de creación mínimo de todas las líneas de reserva para las exposiciones de un siniestro dado.

Tipo de evento explicit
Siniestro Cerrado
Marca el cierre exitoso de un siniestro después de que todas las actividades y pagos se han completado. Este es el evento final exitoso principal, inferido de un cambio en el estado principal del siniestro.
Por qué es importante

Como evento final principal, esta actividad es esencial para calcular el tiempo de ciclo de principio a fin y medir el cumplimiento de los SLA. Significa la finalización del ciclo de vida del reclamo.

Dónde obtener

Inferido a partir de un cambio en el campo State de la tabla cc_claim a 'Closed'. La marca de tiempo (timestamp) del evento es la CloseDate en el registro del siniestro.

Capturar

Identificar cuándo el campo de estado maestro del siniestro se actualiza a 'Closed'.

Tipo de evento inferred
Siniestro Creado
Esta actividad marca el primer aviso de siniestro (FNOL) y la creación oficial de un nuevo registro de siniestro en Guidewire ClaimCenter. Se captura explícitamente cuando una nueva entidad de siniestro se guarda en la base de datos por primera vez.
Por qué es importante

Como evento de inicio principal, esta actividad es esencial para medir el tiempo de ciclo completo del reclamo. Proporciona la base para todos los KPI de rendimiento y duración posteriores.

Dónde obtener

Este es un event explícito registrado desde el CreateTime de la tabla cc_claim. La creación de un nuevo record con un Claim ID único sirve como disparador del event.

Capturar

Identificar la marca de tiempo (timestamp) de creación del nuevo registro en la tabla de entidad base Claim.

Tipo de evento explicit
Siniestro Denegado
Representa la decisión final de denegar un siniestro, sirviendo como punto final del proceso. Este evento se infiere del cambio de estado del siniestro a 'Cerrado' con un motivo de 'Denegado'.
Por qué es importante

Este es un event de resultado crítico. Analizar la frecuencia, las razones y las rutas del proceso que conducen a las denegaciones ayuda a identificar problemas en la recepción del claim, la investigación o la interpretación de la policy.

Dónde obtener

Inferido a partir de un cambio en el campo State de la tabla cc_claim a 'Closed', combinado con el campo CloseReason siendo 'Denied' o un valor similar. La marca de tiempo (timestamp) del evento es la CloseDate.

Capturar

Filtre los cambios de estado de siniestro a "Cerrado" donde el código de motivo indique denegación.

Tipo de evento inferred
Decisión de Responsabilidad Tomada
Significa el punto en el que se ha determinado una decisión sobre la responsabilidad o la culpa para una exposición. Este evento se infiere típicamente de un cambio de estado en la entidad Exposición.
Por qué es importante

Este es un hito de decisión crítico que da paso a las fases de settlement y payment. Analizar el tiempo hasta esta decisión ayuda a identificar bottlenecks en las etapas de investigación y evaluación.

Dónde obtener

Inferido de la tabla cc_history al rastrear un cambio en el campo State o un campo de estado de responsabilidad personalizado en la entidad cc_exposure. La marca de tiempo (timestamp) del registro de historial indica la hora del evento.

Capturar

Monitorear los registros de auditoría o las tablas de historial en busca de actualizaciones en el estado del riesgo o el estatus de responsabilidad.

Tipo de evento inferred
Información Adicional Recibida
Marca la finalización de una solicitud de información adicional. Esto se registra cuando la 'Actividad' (tarea) correspondiente a la solicitud de información se marca como 'Completada'.
Por qué es importante

Este es el endpoint para el KPI de 'Additional Info Gathering Cycle Time'. Las duraciones prolongadas entre la solicitud y la recepción son fuentes comunes de retraso en el proceso de claims.

Dónde obtener

Capturado del CloseTime de un registro cc_activity donde el ActivityPattern se relaciona con una solicitud de información. El estado de la actividad debe ser 'Completed'.

Capturar

Identificar la marca de tiempo (timestamp) de finalización de una tarea para solicitar información externa.

Tipo de evento explicit
Información Adicional Solicitada
Representa una solicitud enviada al reclamante o a un tercero para obtener más información o documentación. Esto se registra típicamente como una 'Actividad' (tarea) explícita creada en ClaimCenter.
Por qué es importante

Esta actividad es el punto de partida para medir el KPI de 'Tiempo de Ciclo de Recopilación de Información Adicional'. Las ocurrencias frecuentes pueden indicar procesos de Primer Aviso de Siniestro (FNOL) incompletos o una recopilación de información ineficiente.

Dónde obtener

Capturado del CreateTime de un registro cc_activity donde el ActivityPattern está relacionado con la solicitud de documentación o información a una parte externa.

Capturar

Identificar la creación de una tarea para solicitar información externa.

Tipo de evento explicit
Investigación Iniciada
Indica el inicio formal de la fase de investigación para un siniestro o exposición. Esto se infiere a menudo de la creación de la primera 'Activity' (tarea) relacionada con la investigación en Guidewire.
Por qué es importante

Esta actividad marca el inicio de una fase clave, a menudo prolongada. Analizar el tiempo hasta que comienza la investigación y la duración de la investigación en sí revela importantes cuellos de botella.

Dónde obtener

Inferido del CreateTime de un registro cc_activity donde el ActivityPattern está relacionado con la investigación (por ejemplo, 'Initial Investigation', 'Contact Witness').

Capturar

Identificar la primera creación de una tarea con un patrón o asunto relacionado con la investigación.

Tipo de evento inferred
Liquidación Calculada
Esta actividad representa el punto en el que se ha determinado un monto de liquidación, pero aún no ha sido aprobado para el pago. Puede inferirse de la creación de un pago en estado de 'Aprobación Pendiente'.
Por qué es importante

Marca la transición de la evaluación al pago. Es el punto de partida para medir el KPI de 'Tiempo de Autorización de Pagos', revelando retrasos en la cadena de aprobación.

Dónde obtener

Inferido del CreateTime de un registro cc_check o cc_transaction donde su estado inicial es 'Pending Approval' o un estado similar antes de 'Approved'.

Capturar

Identificar la creación de un registro de pago o transacción en un estado preaprobado.

Tipo de evento inferred
Siniestro Asignado
Representa la asignación de un siniestro a un usuario específico (ajustador) o grupo para su gestión. Esto se infiere típicamente monitoreando los cambios en los campos de asignación en la entidad Siniestro.
Por qué es importante

Monitorizar las asignaciones es crucial para analizar la carga de trabajo de los peritos, identificar bottlenecks en el routing y medir el time-to-first-action por parte del handler asignado.

Dónde obtener

Inferido de la tabla cc_history al rastrear cambios en los campos AssignedUser o AssignedGroup asociados con un ID de siniestro específico. La marca de tiempo (timestamp) del cambio indica cuándo ocurrió el evento.

Capturar

Monitorear los registros de auditoría o las tablas de historial en busca de actualizaciones en los campos de asignación de siniestros.

Tipo de evento inferred
Siniestro Reabierto
Representa un siniestro que pasa de estado 'Cerrado' a 'Abierto' nuevamente para realizar trabajo adicional. Este evento se infiere de una secuencia específica de cambios de estado.
Por qué es importante

Esta actividad indica retrabajo. Un alto volumen de siniestros reabiertos señala problemas con la liquidación inicial, daños no detectados u otras fallas en el proceso, lo que conlleva a un aumento de costos e ineficiencia.

Dónde obtener

Inferido de la tabla cc_history al identificar un cambio en el campo State de la entidad cc_claim de 'Closed' a 'Open' o a otro estado activo.

Capturar

Monitorear el campo de estado principal del siniestro para una transición de un estado cerrado a uno abierto.

Tipo de evento inferred
Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Guidewire ClaimCenter