Plantilla de Datos: Procesamiento de Reclamaciones
Plantilla de Datos para la Gestión de Siniestros
- Atributos recomendados para recopilar
- Actividades clave a monitorizar
- Guía de Extracción para Duck Creek Claims
Atributos de Gestión de Siniestros
| Nombre | Descripción | ||
|---|---|---|---|
Hora del Evento EventTime | El timestamp que indica cuándo ocurrió una actividad o event específico. | ||
Descripción La Hora del Evento proporciona la fecha y hora precisas para cada actividad registrada en el ciclo de vida de la reclamación. Esta información temporal es crítica para el análisis de rendimiento. En el análisis, esta marca de tiempo se utiliza para calcular los tiempos de ciclo entre actividades, identificar los tiempos de espera, medir la duración total del caso y analizar el rendimiento del proceso en diferentes períodos de tiempo. Es la columna vertebral de cualquier métrica de proceso basada en el tiempo. Por qué es importante Este timestamp es crucial para calcular todas las métricas basadas en el tiempo, como tiempos de ciclo y duraciones, lo que permite el análisis del rendimiento y la identificación de cuellos de botella. Dónde obtener Este es un campo de timestamp estándar asociado con logs de eventos o transacciones en Duck Creek Claims. Busque campos como 'CreateDate', 'Timestamp' o 'EventDate'. Ejemplos 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
ID del Siniestro ClaimId | El identificador único para un único siniestro de seguro, que sirve como el identificador principal del case. | ||
Descripción El ID de Siniestro es la clave fundamental que vincula todos los events y actividades asociados con un único siniestro de seguro, desde su presentación hasta su cierre. Asegura que todo el ciclo de vida de un siniestro pueda ser rastreado de forma coherente. En el análisis de Process Mining, este atributo es esencial para construir la vista de case, permitiendo a los analistas seguir el recorrido completo de cada siniestro, medir los tiempos de ciclo de extremo a extremo y analizar las variantes del proceso. Por qué es importante Este es el Case ID esencial que conecta todos los eventos relacionados en el proceso, permitiendo una visión completa y de extremo a extremo del ciclo de vida del siniestro. Dónde obtener Esta es una clave primaria en la entidad o tabla principal de siniestros dentro de Duck Creek Claims. Consulte la documentación del sistema para conocer el nombre específico de la tabla y del campo. Ejemplos CL-2023-001234CL-2023-005678CL-2024-009101 | |||
Nombre de la actividad ActivityName | El nombre de la actividad de negocio o event que ocurrió en un momento específico para un siniestro. | ||
Descripción Este atributo describe un paso o tarea específica realizada dentro del proceso de siniestros, como 'Siniestro presentado', 'Gestor asignado' o 'Pago emitido'. Cada actividad representa un punto distinto en el ciclo de vida del siniestro. Analizar la secuencia y frecuencia de estas actividades es el núcleo de Process Mining. Permite el descubrimiento de modelos de procesos, la identificación de cuellos de botella, la detección de retrabajos y el análisis de desviaciones del proceso respecto a un modelo estándar. Por qué es importante El nombre de la actividad define los pasos del flujo de proceso, lo cual es fundamental para descubrir, analizar y monitorear el proceso de siniestros. Dónde obtener Normalmente, se deriva de logs de eventos, nombres de transacciones o registros de cambios de estado dentro de Duck Creek Claims. Esto podría requerir el mapeo desde múltiples campos o tablas de origen. Ejemplos Siniestro PresentadoAjustador asignadoInvestigación IniciadaPago EmitidoSiniestro Cerrado | |||
Ajustador Asignado AssignedAdjuster | El nombre o ID del perito de siniestros responsable de gestionar el siniestro en una actividad determinada. | ||
Descripción Este atributo identifica al usuario o recurso que realiza una actividad. Puede cambiar a lo largo del ciclo de vida del siniestro a medida que el caso se transfiere entre diferentes gestores de siniestros o equipos. Esto es esencial para analizar el rendimiento de los recursos, la distribución de la carga de trabajo y las transferencias. Los dashboards centrados en el rendimiento del gestor, la variación de la carga de trabajo y la identificación de cuellos de botella suelen depender en gran medida de este atributo para comprender cómo se asigna y procesa el trabajo a nivel individual. Por qué es importante Permite el análisis del rendimiento de los recursos, el equilibrio de la carga de trabajo y los patrones de colaboración, ayudando a identificar cuellos de botella y necesidades de formación. Dónde obtener Consulte la documentación de Duck Creek Claims. Busque los campos de usuario, propietario o asignatario en las tablas relacionadas con tareas de reclamación, eventos o la entidad principal de la reclamación. Ejemplos John SmithJane DoeRobert Brownadjuster_1138 | |||
Departamento Department | El departamento o equipo responsable de la actividad o del siniestro en un momento dado. | ||
Descripción Este atributo especifica el grupo funcional o departamento, como 'Recepción Inicial', 'Unidad de Investigación' o 'Equipo de Liquidación', que está gestionando el siniestro. Proporciona un contexto organizacional al flujo del proceso. El análisis por departamento es clave para comprender el rendimiento del proceso a un nivel agregado. Ayuda a identificar cuellos de botella interdepartamentales, medir la eficiencia a nivel de equipo y entender cómo fluye el trabajo en toda la organización. Por qué es importante Permite el análisis de rendimiento por área funcional, resaltando las transferencias interdepartamentales y los cuellos de botella específicos del equipo. Dónde obtener Consulte la documentación de Duck Creek Claims. Esta información suele estar asociada con el perfil del usuario asignado o una asignación a cola/grupo de trabajo. Ejemplos Siniestros de AutomóvilesSiniestros de Propiedad - Grandes PérdidasUnidad de Investigaciones EspecialesProcesamiento de Pagos | |||
Estado del Siniestro ClaimStatus | El estado general del siniestro en un momento dado, como Abierto, Pendiente o Cerrado. | ||
Descripción El Estado del Siniestro representa el estado actual del siniestro en su ciclo de vida. Ofrece un resumen de alto nivel de la posición del siniestro en el proceso general. Este atributo es útil para crear vistas de alto nivel del inventario de siniestros y para filtrar casos. Es particularmente importante para identificar el resultado final de un siniestro (ej., 'Cerrado - Pagado', 'Cerrado - Denegado'), lo cual es esencial para el análisis de resultados y la comprensión de las tasas de rechazo. Por qué es importante Proporciona una instantánea del estado actual y el resultado final del siniestro, crucial para el análisis de resultados y el filtrado de casos. Dónde obtener Consulte la documentación de Duck Creek Claims. Este es un campo fundamental en el registro principal de la reclamación. Ejemplos AbiertoPendiente - Esperando InformaciónCerrado - LiquidadoCerrado - Denegado | |||
Gravedad del Siniestro ClaimSeverity | Una clasificación de la complejidad financiera u operativa del siniestro, como Baja, Media o Alta. | ||
Descripción La Gravedad del Siniestro proporciona una indicación del impacto o la complejidad anticipados de un siniestro. Puede basarse en la estimación inicial de la pérdida, la naturaleza del incidente u otras reglas de negocio predefinidas. Este atributo es vital para el análisis de rendimiento, ya que los siniestros de alta gravedad suelen requerir más pasos, tiempos de procesamiento más largos y recursos especializados. Segmentar los KPI por gravedad ayuda a establecer objetivos de rendimiento realistas y a comprender cómo la complejidad impacta la eficiencia y los resultados del proceso. Por qué es importante Ayuda a segmentar las reclamaciones por complejidad, permitiendo un análisis de rendimiento más matizado y un benchmarking realista de los tiempos de ciclo y los costos. Dónde obtener Consulte la documentación de Duck Creek Claims. Puede ser un campo dedicado o derivarse del importe de la reserva inicial de pérdidas. Ejemplos BajoMedioAltoCatastrófico | |||
Monto del Siniestro LossAmount | El monto financiero estimado o real de la pérdida reportada en el siniestro. | ||
Descripción Este atributo representa el valor estimado inicial de la pérdida asociada al siniestro. Es una métrica financiera clave que a menudo influye en la clasificación del siniestro, su gravedad y el nivel de investigación requerido. En el análisis, el monto de la pérdida se utiliza para segmentar los siniestros y comprender cómo el impacto financiero se correlaciona con el comportamiento del proceso. Por ejemplo, los siniestros de mayor valor pueden seguir rutas diferentes o tener ciclos de tiempo más largos. Proporciona un contexto financiero crucial a los data del proceso operativo. Por qué es importante Proporciona un contexto financiero al siniestro, permitiendo el análisis de cómo el valor de un siniestro impacta su ruta de procesamiento, duración y resultado. Dónde obtener Consulte la documentación de Duck Creek Claims. Este es un campo financiero fundamental en la reclamación, a menudo denominado 'Pérdida Reportada' o 'Reserva Inicial'. Ejemplos 1500.0025000.50125000.00 | |||
Tipo de Siniestro ClaimType | La categoría del siniestro de seguro, como Automóvil, Propiedad o Responsabilidad Civil. | ||
Descripción El Tipo de Siniestro clasifica los siniestros según la línea de negocio o la naturaleza de la pérdida. Esta es una dimensión fundamental para segmentar y analizar los datos de siniestros. Este atributo se utiliza para comparar el rendimiento del proceso entre diferentes tipos de siniestros. Por ejemplo, un siniestro de 'Automóvil - Pérdida Total' sigue un proceso muy diferente y tiene KPI distintos a un siniestro de 'Propiedad - Daño por Agua'. Analizar por Tipo de Siniestro proporciona contexto y permite comparaciones de rendimiento más significativas e iniciativas de mejora de procesos personalizadas. Por qué es importante Esta es una dimensión crítica para segmentar el análisis, ya que los diferentes tipos de siniestros suelen tener procesos, SLA y niveles de complejidad distintos. Dónde obtener Consulte la documentación de Duck Creek Claims. Este es un atributo clave en el registro principal de la reclamación. Ejemplos Automóvil Personal - ColisiónPropiedad Comercial - IncendioCompensación para TrabajadoresResponsabilidad Civil General | |||
Es Automatizado IsAutomated | Un indicador booleano que señala si la actividad fue realizada automáticamente por el sistema sin intervención humana. | ||
Descripción Este indicador distingue entre las Tasks completadas por usuarios humanos y aquellas ejecutadas por la automatización del sistema, como notificaciones automáticas, validación inicial de data o pasos de procesamiento directo. Analizar este atributo es clave para comprender el nivel de automatización en el proceso de siniestros. Ayuda a medir el impacto de las iniciativas de automatización, identifica oportunidades para una mayor automatización y asegura que los pasos automatizados se estén ejecutando según lo esperado sin generar problemas posteriores. Por qué es importante Ayuda a medir el impacto de la automatización en la eficiencia y el costo, e identifica oportunidades para el procesamiento directo. Dónde obtener Esta información puede inferirse del 'user' asociado a un Event (por ejemplo, 'SYSTEM' o 'BATCH'), o de un indicador específico en el registro del Event. Ejemplos truefalse | |||
Es Resolución a Tiempo IsOnTimeResolution | Un indicador calculado que indica si un siniestro se cerró en o antes de su fecha objetivo de resolución. | ||
Descripción Este atributo booleano se deriva al comparar el timestamp de la actividad 'Siniestro Cerrado' con la 'ResolutionTargetDate' de ese siniestro. Marca cada siniestro como a tiempo (verdadero) o con retraso (falso). Este atributo apoya directamente el KPI de 'Tasa de Resolución de Siniestros a Tiempo'. Permite una fácil agregación y visualización del cumplimiento de los SLA en dashboards, y posibilita un análisis detallado para identificar características comunes de los siniestros con retraso (por ejemplo, tipos de siniestro específicos, departamentos o rutas de proceso). Por qué es importante Mide directamente el cumplimiento de los SLA a nivel de reclamación individual, permitiendo un filtrado potente y un análisis de la causa raíz para las reclamaciones atrasadas. Dónde obtener Este no es un campo del sistema de origen. Se calcula durante la preparación de los datos comparando el timestamp de la actividad final con el campo 'ResolutionTargetDate'. Ejemplos truefalse | |||
Es Retrabajo IsRework | Un indicador calculado que señala si una actividad forma parte de un ciclo de reelaboración. | ||
Descripción Este atributo booleano se establece en verdadero si una actividad se repite para un siniestro después de que ya hayan ocurrido otras actividades diferentes. Por ejemplo, si el proceso pasa de 'Pérdida Evaluada' de nuevo a 'Investigación Iniciada'. Este atributo es esencial para cuantificar y analizar el retrabajo. Apoya el KPI de 'Tasa de Retrabajo de Siniestros' y el dashboard de 'Patrones de Retrabajo y Reprocesamiento de Siniestros' al permitir el filtrado y el resaltado directo de actividades y casos que implican retrabajo. Esto ayuda a identificar ineficiencias y problemas de calidad en el proceso. Por qué es importante Cuantifica el reproceso a nivel de actividad, facilitando la medición, visualización y análisis de las causas e impactos de las ineficiencias del proceso. Dónde obtener Este no es un campo del sistema de origen. Se calcula durante la preparación de los datos utilizando algoritmos que detectan secuencias repetidas de actividades dentro de un caso. Ejemplos truefalse | |||
Fecha objetivo de resolución ResolutionTargetDate | La fecha objetivo en la que se espera que el siniestro se resuelva, según los SLAs o los objetivos internos. | ||
Descripción Este atributo almacena la fecha límite para el cierre del siniestro. Esta fecha suele estar determinada por requisitos normativos, acuerdos de nivel de servicio (SLA) o indicadores clave de rendimiento (KPI) internos, y puede variar según el tipo o la gravedad del siniestro. Es la base para calcular el KPI de 'Tasa de Resolución de Siniestros a Tiempo' y para el dashboard de 'Adherencia al Objetivo de Resolución de Siniestros'. Permite el monitoreo proactivo de los siniestros en riesgo de incumplir su SLA y ayuda a priorizar el trabajo. Por qué es importante Permite la medición del rendimiento frente a los acuerdos de nivel de servicio (SLA) y los objetivos internos, lo cual impacta directamente la satisfacción del cliente y el cumplimiento normativo. Dónde obtener Consulte la documentación de Duck Creek Claims. Podría ser un campo de fecha SLA específico o calcularse en función de la fecha de presentación de la reclamación y las reglas de negocio. Ejemplos 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
Hora de Finalización EndTime | El timestamp que indica cuándo se completó una actividad. | ||
Descripción Este atributo marca la hora de finalización de una actividad. Mientras que StartTime indica cuándo comenzó una actividad, EndTime completa el cálculo de la duración de esa tarea específica. En Process Mining, disponer tanto de la hora de inicio como de la hora de fin de las actividades permite un análisis de rendimiento mucho más profundo. Facilita el cálculo preciso del 'Processing Time' (el tiempo de trabajo activo en una Task) frente al 'Waiting Time' (el tiempo transcurrido entre Tasks). Esta distinción es crucial para identificar con exactitud los cuellos de botella. Por qué es importante Permite el cálculo de tiempos de procesamiento precisos de actividades, distinguiendo el tiempo de trabajo activo del tiempo de inactividad/espera, lo cual es crítico para un análisis preciso de cuellos de botella. Dónde obtener Puede estar disponible como un campo de timestamp separado en los event logs o puede derivarse como el StartTime de la siguiente actividad en la secuencia para el mismo case. Ejemplos 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
Monto de liquidación SettlementAmount | El monto financiero final acordado para liquidar el siniestro. | ||
Descripción Este atributo registra el valor de la indemnización que se calculó y autorizó para el pago. Es una métrica clave basada en resultados para cada siniestro que culmina en un pago. Este atributo es crucial para el análisis financiero y para dashboards como 'Tiempo de Autorización y Emisión de Pagos'. Puede compararse con el 'Monto de la pérdida' inicial para analizar la precisión de las reservas y es fundamental para comprender los resultados financieros del proceso de siniestros. Por qué es importante Representa el resultado financiero clave de un siniestro, fundamental para la elaboración de informes financieros y el análisis de la exactitud de las estimaciones iniciales de pérdidas. Dónde obtener Consulte la documentación de Duck Creek Claims. Esta información se suele almacenar en tablas de transacciones financieras o relacionadas con pagos asociadas a la reclamación. Ejemplos 1450.7522000.00115800.20 | |||
Motivo de rechazo RejectionReason | El motivo específico por el que un siniestro fue denegado o rechazado. | ||
Descripción Cuando se toma la decisión de denegar un siniestro, este atributo proporciona la razón subyacente de dicha decisión. Esto se selecciona típicamente de una lista predefinida de códigos o descripciones. Analizar las razones de rechazo es fundamental para el dashboard 'Claim Decision & Rejection Insights'. Ayuda a identificar problemas comunes en las presentaciones, posibles patrones de fraude o áreas donde el lenguaje de la póliza puede no ser claro. Esta información puede impulsar mejoras en el proceso de admisión o en las reglas de suscripción. Por qué es importante Explica por qué se deniegan las reclamaciones, proporcionando información útil para mejorar el proceso de recepción, reducir las presentaciones no válidas e identificar oportunidades de formación. Dónde obtener Consulte la documentación de Duck Creek Claims. Este campo se suele completar cuando el estado de una reclamación cambia a 'Denegada' o a un estado similar. Ejemplos Riesgo No CubiertoPóliza VencidaReclamación DuplicadaFraude sospechoso | |||
Número de Póliza PolicyNumber | El identificador único de la póliza de seguro bajo la cual se presentó el siniestro. | ||
Descripción Este atributo vincula el siniestro con la póliza de seguro original. Proporciona contexto sobre la cobertura, los términos y el cliente asociado al siniestro. Aunque no siempre se utiliza directamente en el análisis del flujo de procesos, el Número de Póliza es invaluable para enriquecer los data del siniestro. Permite unirlos con los data de pólizas y clientes para analizar cómo varía el rendimiento del proceso según el segmento de cliente, el tipo de póliza o la antigüedad de la misma, ofreciendo así una visión de negocio más holística. Por qué es importante Vincula la reclamación al cliente y la póliza, lo que permite un análisis más amplio de cómo el rendimiento del proceso impacta a diferentes segmentos de clientes o tipos de póliza. Dónde obtener Consulte la documentación de Duck Creek Claims. Este es un campo de referencia estándar en la entidad principal de la reclamación. Ejemplos PA-987654321CP-123456789WC-555444333 | |||
Sistema de Origen SourceSystem | El sistema del que se extrajeron los datos de events. | ||
Descripción Este atributo identifica la aplicación de origen de donde provienen los datos del siniestro. En este contexto, será consistentemente 'Duck Creek Claims'. Aunque pueda parecer redundante si todos los data proceden de un único sistema, es crucial para la gobernanza y la trazabilidad de data, así como en escenarios donde los data podrían fusionarse de múltiples sistemas en el futuro. Proporciona contexto sobre el origen y la estructura de los data. Por qué es importante Proporciona un linaje de datos y un contexto esenciales, lo que es crítico para la data governance y la solución de problemas, especialmente en entornos con múltiples sistemas integrados. Dónde obtener Generalmente, es un valor estático que se añade durante el proceso de extracción y transformación de datos para etiquetar su origen. Ejemplos Duck Creek Claims | |||
Tiempo de Procesamiento ProcessingTime | La duración del trabajo activo para una actividad específica, calculada como Hora de finalización menos Hora de inicio. | ||
Descripción Tiempo de Procesamiento, también conocido como tiempo activo o tiempo de gestión, mide cuánto tiempo un recurso estuvo trabajando activamente en una tarea específica. Se calcula restando el StartTime del EndTime de una actividad. Esta métrica es un componente central del análisis de rendimiento. Ayuda a distinguir entre ineficiencias causadas por tareas de larga duración (alto tiempo de procesamiento) y retrasos debidos a la espera de recursos o información (alto tiempo de espera). Esto es crucial para identificar la verdadera fuente de los cuellos de botella. Por qué es importante Mide el tiempo de trabajo activo para una actividad, ayudando a diferenciar entre tareas ineficientes y largos tiempos de espera en el análisis de cuellos de botella. Dónde obtener Este no es un campo del sistema de origen. Se calcula durante la preparación de los datos restando el 'StartTime' del 'EndTime' para cada actividad. Ejemplos 360086400300 | |||
Última Actualización de Datos LastDataUpdate | El timestamp de la actualización de datos más reciente del sistema de origen. | ||
Descripción Este atributo indica cuándo se actualizó por última vez el dataset. Proporciona un punto de referencia para la vigencia de los data que se están analizando. En dashboards y análisis, esto se utiliza para informar a los usuarios sobre la actualidad de los insights. Ayuda a gestionar las expectativas sobre si las últimas transacciones están incluidas en la vista del proceso. Por qué es importante Informa a los usuarios sobre la actualidad de los datos, lo cual es fundamental para interpretar el análisis y tomar decisiones oportunas. Dónde obtener Este timestamp se genera durante el proceso de extracción, transformación y carga de datos (ETL) y normalmente se almacena en los metadatos del dataset. Ejemplos 2024-05-21T02:00:00Z | |||
Actividades de Gestión de Siniestros
| Actividad | Descripción | ||
|---|---|---|---|
Decisión sobre el Siniestro Tomada | Esta actividad representa la decisión oficial sobre el siniestro, como 'Aprobado', 'Aprobado Parcialmente' o 'Denegado'. Es un hito fundamental que se infiere de un cambio en el estado de decisión final. | ||
Por qué es importante Este es un hito crucial en la toma de decisiones. El tiempo previo a este punto y el resultado de la decisión son fundamentales para el análisis y la eficiencia del proceso. Dónde obtener Se infiere de un cambio en un campo dedicado de 'Decisión de Reclamación' o 'Estado de Reclamación' a un estado terminal como 'Aprobada' o 'Denegada'. Se captura la marca de tiempo de este cambio. Capturar Se infiere de una actualización en el campo de estado principal o de decisión de la reclamación. Tipo de evento inferred | |||
Pago Autorizado | Representa la aprobación formal del monto de liquidación calculado para su pago. Suele ser un paso diferenciado que involucra a un gerente o a una autoridad distinta, y se registra como una transacción de aprobación explícita. | ||
Por qué es importante Este es un punto de control clave y un potencial cuello de botella antes del pago. La duración desde la 'Decisión del Siniestro Tomada' hasta este punto se mide mediante el KPI de 'Tiempo Promedio de Aprobación del Siniestro'. Dónde obtener Normalmente, es un evento explícito en un workflow o módulo financiero donde un usuario con permisos específicos aprueba el pago. Se encontraría en un log de aprobaciones. Capturar Un evento de aprobación explícita registrado en un workflow o registro de transacciones. Tipo de evento explicit | |||
Pago Emitido | Esta actividad marca la ejecución de la transacción financiera para pagar el siniestro. Es un event claro y explícito que se genera cuando el pago se despacha mediante cheque, EFT u otros métodos. | ||
Por qué es importante Esto significa la culminación de la obligación financiera para un siniestro aprobado. El tiempo transcurrido desde 'Payment Authorized' hasta 'Payment Issued' revela la eficiencia del departamento de finanzas. Dónde obtener Capturado de la tabla de transacciones financieras en Duck Creek Claims, que registra todos los pagos salientes con un código de transacción y un timestamp específicos. Capturar Se crea una entrada discreta en el registro de transacciones financieras cuando se procesa un pago. Tipo de evento explicit | |||
Siniestro Cerrado | Esta es la actividad final, que marca el cierre administrativo del expediente del siniestro una vez que se ha emitido el pago o el siniestro ha sido resuelto. Se registra con la actualización del estado final a 'Closed'. | ||
Por qué es importante Esta actividad marca la finalización exitosa del proceso. Es el punto de referencia para calcular el 'Tiempo promedio de ciclo completo del siniestro' y otras métricas clave de duración. Dónde obtener Se infiere de la marca de tiempo del cambio de estado final a 'Cerrada' o 'Liquidada' en la tabla de datos principal de la reclamación. Capturar Se infiere de que el estado final de la reclamación se establece como 'Cerrada'. Tipo de evento inferred | |||
Siniestro Denegado | Esta actividad representa un final alternativo del proceso, donde el siniestro es denegado oficialmente. Esto se registra cuando el estado final del siniestro se establece como 'Denegado' o 'Rechazado'. | ||
Por qué es importante Este es un resultado crítico que requiere un análisis separado. Comprender por qué y cuándo se deniegan los siniestros ayuda a mejorar los procesos de admisión y a gestionar el cumplimiento normativo. Dónde obtener Se infiere de la marca de tiempo del cambio de estado final de la reclamación a un estado de 'Denegada', 'Rechazada' o 'Cerrada sin Pago' en la tabla de entidades de la reclamación. Capturar Se infiere de que el estado final de la reclamación es un motivo de denegación. Tipo de evento inferred | |||
Siniestro Presentado | Este es el primer evento, que representa la recepción de la Primera Notificación de Siniestro (FNOL) por parte de la aseguradora. Generalmente, se captura como una transacción explícita cuando un agente o tomador de póliza introduce la información inicial del siniestro en el sistema. | ||
Por qué es importante Esta actividad marca el inicio de todo el ciclo de vida del siniestro. Analizar el tiempo desde este evento hasta otros es crucial para comprender la duración total del procesamiento y la eficiencia en la gestión inicial. Dónde obtener Suele ser un evento explícito registrado en una tabla de log de siniestros o FNOL cuando se crea por primera vez un nuevo registro de siniestro en Duck Creek Claims. Capturar Evento registrado al crear inicialmente un nuevo registro de reclamación. Tipo de evento explicit | |||
Ajustador asignado | Este Event registra la asignación de un gestor o tramitador de siniestros al siniestro registrado. El sistema registra esta asignación, creando un punto de transferencia claro y estableciendo la responsabilidad sobre el ciclo de vida del siniestro. | ||
Por qué es importante Crucial para analizar la asignación de recursos, la carga de trabajo de los peritos e identificar retrasos en la asignación de reclamaciones. Es un punto clave de traspaso que puede introducir tiempos de espera. Dónde obtener Se rastrea mediante una actualización en el campo 'Assigned Adjuster' de la tabla principal de datos de siniestros. Un historial o log de auditoría para este campo proporciona el timestamp. Capturar Registrado en una pista de auditoría cuando se rellena o modifica el campo del ajustador. Tipo de evento explicit | |||
Información adicional recibida | Marca la recepción de la información solicitada, lo que permite que el procesamiento del siniestro continúe. Esto puede registrarlo manualmente el ajustador o de forma automática si la información se envía a través de un portal digital. | ||
Por qué es importante El tiempo entre 'Información Solicitada' e 'Información Recibida' es un período de espera crítico. Analizar esta duración ayuda a identificar dependencias externas y cuellos de botella en la comunicación. Dónde obtener Puede ser un Event explícito de una integración con un sistema de gestión documental, o una entrada de registro manual o un cambio de status realizado por el gestor de siniestros al recibir la documentación. Capturar Evento registrado al cargar un documento o al ser introducido manualmente por un ajustador. Tipo de evento explicit | |||
Información adicional solicitada | Esta actividad se produce cuando el gestor de siniestros determina que se necesita más información y envía una solicitud al asegurado o a un tercero. Este suele ser un evento explícito vinculado al módulo de comunicación o correspondencia del sistema. | ||
Por qué es importante Una alta frecuencia de esta actividad puede indicar problemas con el proceso inicial de recopilación de datos. También introduce un tiempo de espera significativo, lo que afecta el tiempo total del ciclo. Dónde obtener Capturado de registros relacionados con comunicaciones salientes (ej., cartas, correos electrónicos) o una transacción específica de 'Solicitud de Información' en Duck Creek Claims. Capturar Registrado cuando se genera una correspondencia o tarea para solicitar información. Tipo de evento explicit | |||
Investigación Completada | Representa la conclusión de las actividades de investigación, una vez recopilados todos los hechos necesarios. Esto suele inferirse cuando el estado del siniestro cambia de 'En Investigación' a un estado de toma de decisiones como 'Pendiente de Decisión'. | ||
Por qué es importante Completar la investigación es un hito crucial que desbloquea las fases de toma de decisiones y liquidación. Los retrasos en este punto tienen un impacto significativo en etapas posteriores. Dónde obtener Se infiere de la marca de tiempo de una actualización del estado de la reclamación de un estado de 'investigación' a un estado de 'revisión' o 'decisión'. Capturar Derivado de un cambio en el estado de la reclamación que indica el fin de las actividades de investigación. Tipo de evento inferred | |||
Investigación Iniciada | Esta actividad marca el inicio de la fase de investigación formal del siniestro. A menudo se infiere de un cambio en el estado del siniestro a 'En investigación' o un estado similar. | ||
Por qué es importante Esto marca el inicio de una fase intensiva en recursos. Medir la duración de la investigación es clave para el KPI 'Duración Media de la Investigación' y ayuda a gestionar una parte crítica del proceso. Dónde obtener Se infiere de la marca de tiempo de una actualización del estado de la reclamación a 'Investigación en Curso' o 'Inspección Pendiente' en el campo de estado principal de la reclamación. Capturar Derivado de un cambio en el estado de la reclamación que indica el inicio de las actividades de investigación. Tipo de evento inferred | |||
Liquidación calculada | Después de una aprobación, esta actividad calcula el monto final de la liquidación o pago. Puede ser un paso explícito o deducirse de la concreción de los pagos en el módulo financiero del sistema. | ||
Por qué es importante Esta actividad es crucial para medir el KPI de 'Tasa de Reprocesos de Liquidación'. Múltiples ocurrencias de este event para un único siniestro indican ineficiencias, errores o negociaciones en la fase de liquidación. Dónde obtener Puede ser una entrada explícita en el registro de transacciones o inferido de las actualizaciones del campo 'Monto de Liquidación' en los datos financieros del siniestro. Los registros de auditoría de este campo son la fuente principal. Capturar Evento registrado cuando se calcula y guarda el importe final del pago. Tipo de evento explicit | |||
Revisión Inicial Completada | Representa la finalización de la primera revisión exhaustiva del siniestro por parte del perito asignado. Esto suele inferirse cuando el estado del siniestro cambia después de la asignación, por ejemplo, de 'Asignado' a 'En Revisión' o 'En Investigación'. | ||
Por qué es importante Este hito ayuda a medir el tiempo hasta la primera acción de un perito y puede indicar posibles retrasos en su carga de trabajo. Es el primer punto de control importante impulsado por humanos. Dónde obtener Se infiere de un cambio de estado en el campo de estado de la reclamación, por ejemplo, una transición a 'Revisión Inicial Completada' o 'Información Pendiente'. Se utiliza la marca de tiempo de este cambio de estado. Capturar Se infiere del cambio en el campo de estado de la reclamación después de la asignación del perito. Tipo de evento inferred | |||
Siniestro Evaluado | Este hito marca el punto en el que se establecen o actualizan las reservas financieras basándose en los hallazgos de la investigación. Significa la estimación del impacto financiero del siniestro y se registra cuando se ingresan o ajustan los montos de reserva. | ||
Por qué es importante Este es un punto de control financiero crítico en el proceso. Analizar cuándo ocurre esto proporciona información sobre la velocidad y precisión de la evaluación financiera. Dónde obtener Con frecuencia, se trata de una transacción financiera explícita registrada en el log de transacciones financieras del siniestro o en la tabla de historial de reservas dentro de Duck Creek Claims. Capturar Transacción financiera registrada para establecer o actualizar las reservas del siniestro. Tipo de evento explicit | |||
Siniestro Registrado | Marca la aceptación formal y el registro del siniestro presentado, momento en el que se asigna oficialmente un ID de Siniestro único. Esto suele ser un evento de sistema automatizado tras la validación inicial de los datos. | ||
Por qué es importante Formaliza el inicio de la reclamación y activa procesos posteriores, como la asignación del perito. El tiempo entre la presentación y el registro puede indicar problemas iniciales de calidad de los datos o de carga del sistema. Dónde obtener Se infiere de la marca de tiempo en que se genera el ID de Reclamación principal y el estado de la reclamación pasa de 'pendiente' o 'enviada' a 'abierta' o 'registrada' en la tabla de entidades principal de la reclamación. Capturar Derivado de la marca de tiempo de creación del registro principal de la reclamación o de un cambio de estado a 'Abierta'. Tipo de evento inferred | |||
Guías de Extracción
Pasos
- Acceda a la utilidad de configuración de Duck Creek Data Hub: Inicie sesión en su entorno Duck Creek y diríjase a la aplicación Data Hub. Necesitará permisos adecuados para crear o modificar configuraciones de exportación de datos.
- Cree un nuevo trabajo de exportación de datos: Dentro de la utilidad Data Hub, inicie el proceso para crear un nuevo trabajo de exportación. Asígnele un nombre descriptivo, como ProcessMind_Claims_Event_Log_Export.
- Defina la fuente de datos: Configure el trabajo para conectarse a la base de datos SQL principal de Data Hub. Deberá proporcionar el nombre del servidor, el nombre de la base de datos y las credenciales de un usuario con acceso de lectura a los esquemas pertinentes.
- Introduzca la consulta de extracción: Diríjase a la sección de definición de consultas del trabajo de exportación. Copie el script completo de la sección query que se encuentra a continuación y péguelo en el editor de consultas.
- Configure los parámetros de consulta: Busque la sección de parámetros en la configuración. Defina y establezca los valores para los parámetros @StartDate y @EndDate referenciados en la consulta para especificar el rango de fechas de extracción deseado. Por ejemplo, '2023-01-01' y '2023-12-31'.
- Mapee las columnas de salida: Configure los ajustes del archivo de salida. Asegúrese de que las columnas definidas en la sentencia SELECT (ClaimId, ActivityName, EventTime, etc.) estén mapeadas correctamente a las columnas del archivo de salida. Los nombres de los encabezados en el archivo de salida deben coincidir con estos nombres exactamente.
- Configure el archivo de salida: Especifique el formato de salida como CSV. Establezca el delimitador en una coma (,) y la codificación de caracteres en UTF-8 para garantizar la compatibilidad con ProcessMind.
- Defina el destino: Especifique la ruta del archivo o la ubicación de red donde se guardará el archivo CSV generado. Asegúrese de que el sistema tenga permisos de escritura en esta ubicación.
- Programe el trabajo de exportación: Configure la programación del trabajo. Para un análisis inicial, puede ejecutarlo manualmente. Para un monitoreo continuo, establezca una programación recurrente (por ejemplo, diaria o semanal).
- Ejecute y recupere el archivo: Ejecute el trabajo para generar el archivo de registro de eventos. Una vez completado, recupere el archivo CSV desde el destino especificado en el paso 8.
- Prepare para la carga: Antes de subirlo a ProcessMind, abra el archivo CSV para realizar una verificación final. Verifique que los encabezados sean correctos, que el formato de fecha sea consistente (YYYY-MM-DD HH:MI:SS) y que los datos aparezcan como se espera.
Configuración
- Requisitos Previos: Se requiere acceso al módulo Duck Creek Data Hub. La cuenta de usuario o de servicio que ejecute el trabajo de exportación debe tener permisos de lectura sobre las tablas de la base de datos subyacente del Data Hub (por ejemplo, [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory]).
- Configuración del Rango de Fechas: La consulta utiliza los parámetros @StartDate y @EndDate. Es crucial establecerlos para definir la ventana de extracción. Para un primer análisis, se recomienda un período de 6 a 12 meses para capturar suficientes casos completados y en curso.
- Filtrado: La consulta incluye un marcador de posición /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ dentro de la Common Table Expression (CTE). Descomente y modifique esta línea para filtrar por líneas de negocio específicas (por ejemplo, 'Personal Auto', 'Commercial Property') para reducir el volumen de datos y enfocar el análisis.
- Ciclo de Actualización del Data Hub: Tenga en cuenta la latencia de los datos del Data Hub. Los datos no son en tiempo real y normalmente se actualizan según un cronograma (por ejemplo, cada noche). Los datos extraídos estarán tan actualizados como la última actualización exitosa del Data Hub.
- Formato de Salida: El trabajo de exportación debe configurarse para producir un archivo plano, preferiblemente CSV. Asegúrese de que el calificador de texto esté configurado en comillas dobles (") para manejar cualquier coma dentro de los campos de datos.
a Consulta de ejemplo config
`config
-- 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;
`