Su Template de datos para la gestión de reclamaciones
Su Template de datos para la gestión de reclamaciones
- Atributos recomendados para recopilar
- Actividades clave que debe registrar
- Guía para extraer datos de Duck Creek Claims
Atributos de la gestión de reclamaciones
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | Marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específicos. | ||
| Descripción La hora del evento proporciona la fecha y hora exactas de cada actividad registrada durante el ciclo de vida del siniestro. Esta información temporal es fundamental para analizar el rendimiento. En el análisis, esta marca de tiempo se utiliza para calcular los tiempos de ciclo entre actividades, identificar tiempos de espera, medir la duración total de cada caso y analizar el rendimiento del proceso en distintos periodos. Es la base de cualquier métrica de proceso relacionada con el tiempo. Por qué es importante Esta marca de tiempo es fundamental para calcular todas las métricas relacionadas con el tiempo, como los tiempos de ciclo y las duraciones, y permite analizar el rendimiento e identificar cuellos de botella. Dónde obtenerlo Es un campo de marca de tiempo estándar asociado a los registros de eventos o transacciones de 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 | Identificador único de un siniestro, que sirve como identificador principal del caso. | ||
| Descripción El ID del siniestro es la clave fundamental que vincula todos los eventos y actividades asociados a un mismo siniestro, desde su presentación hasta su cierre. Permite hacer un seguimiento coherente de todo el ciclo de vida del siniestro. En el análisis de Process Mining, este atributo es esencial para crear la vista del caso. Permite a quienes analizan los datos seguir el recorrido completo de cada siniestro, medir los tiempos de ciclo totales y analizar las variantes del proceso. Por qué es importante Es el ID del caso esencial que conecta todos los eventos relacionados del proceso y permite obtener una visión completa del ciclo de vida del siniestro, de principio a fin. Dónde obtenerlo Es una clave principal de la entidad o tabla principal de siniestros de Duck Creek Claims. Consulte la documentación del sistema para identificar el nombre específico de la tabla y del campo. Ejemplos CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Nombre de la actividad ActivityName | Nombre de la actividad o el evento de negocio que tuvo lugar en un momento determinado durante la tramitación de un siniestro. | ||
| Descripción Este atributo describe un paso o una tarea específicos del proceso de siniestros, como «Siniestro presentado», «Perito asignado» o «Pago emitido». Cada actividad representa un momento concreto del ciclo de vida del siniestro. Analizar la secuencia y la frecuencia de estas actividades es la base de Process Mining. Permite descubrir modelos de proceso, identificar cuellos de botella, detectar ciclos de retrabajo y analizar las desviaciones respecto a un modelo estándar. Por qué es importante El nombre de la actividad define los pasos del flujo del proceso y es fundamental para descubrir, analizar y supervisar la tramitación de siniestros. Dónde obtenerlo Por lo general, se obtiene de los registros de eventos, los nombres de las transacciones o los registros de cambios de estado de Duck Creek Claims. Puede ser necesario asignar datos de varios campos o tablas de origen. Ejemplos Siniestro presentadoPerito asignadoInvestigación iniciadaPago emitidoSiniestro cerrado | |||
| Departamento Department | Departamento o equipo responsable de la actividad o del siniestro en un momento determinado. | ||
| Descripción Este atributo especifica el grupo funcional o departamento que tramita el siniestro, como «Recepción inicial», «Unidad de investigación» o «Equipo de liquidaciones». Aporta contexto organizativo al flujo del proceso. Analizar los datos por departamento es clave para entender el rendimiento general del proceso. Ayuda a identificar cuellos de botella entre departamentos, medir la eficiencia de los equipos y comprender cómo fluye el trabajo en la organización. Por qué es importante Permite analizar el rendimiento por área funcional y destacar los traspasos entre departamentos y los cuellos de botella específicos de cada equipo. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Esta información suele estar asociada al perfil de la persona asignada o a la asignación a una cola o grupo de trabajo. Ejemplos Siniestros de automóvilesSiniestros de propiedad: pérdidas de gran cuantíaUnidad de investigaciones especialesTramitación de pagos | |||
| Estado de la reclamación ClaimStatus | Estado general de la reclamación en un momento determinado, como Abierta, Pendiente o Cerrada. | ||
| Descripción El estado de la reclamación refleja su situación actual dentro del ciclo de vida. Ofrece una visión general de la fase en la que se encuentra dentro del proceso. Este atributo resulta útil para crear vistas generales del inventario de reclamaciones y filtrar casos. Es especialmente importante para identificar el resultado final de una reclamación (por ejemplo, «Cerrada: pagada» o «Cerrada: denegada»), algo esencial para analizar los resultados y comprender las tasas de rechazo. Por qué es importante Ofrece una instantánea del estado actual y del resultado final de la reclamación, fundamental para analizar los resultados y filtrar casos. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Es un campo fundamental del registro principal de reclamaciones. Ejemplos AbiertaPendiente: a la espera de informaciónCerrada: resueltaCerrada: denegada | |||
| Gravedad del siniestro ClaimSeverity | Clasificación de la complejidad financiera u operativa del siniestro, por ejemplo, baja, media o alta. | ||
| Descripción La gravedad del siniestro indica el impacto o la complejidad previstos. Puede basarse en la estimación inicial de la pérdida, la naturaleza del incidente u otras reglas de negocio predefinidas. Este atributo es fundamental para analizar el rendimiento, ya que los siniestros graves suelen requerir más pasos, tiempos de tramitación más largos y recursos especializados. Segmentar los KPI por gravedad ayuda a fijar objetivos de rendimiento realistas y a entender cómo afecta la complejidad a la eficiencia y los resultados del proceso. Por qué es importante Permite segmentar los siniestros por complejidad y realizar análisis de rendimiento más precisos, así como establecer referencias realistas para los tiempos de ciclo y los costes. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Puede tratarse de un campo específico o de un valor derivado del importe de la reserva inicial por pérdida. Ejemplos BajaMedioAltoCatastrófico | |||
| Importe de la pérdida LossAmount | Importe económico estimado o real de la pérdida declarada en la reclamación. | ||
| Descripción Este atributo representa el valor inicial estimado de la pérdida asociada a la reclamación. Es una métrica financiera clave que suele influir en la asignación, la gravedad y el nivel de investigación requerido. En el análisis, el importe de la pérdida permite segmentar las reclamaciones y comprender cómo se relaciona el impacto financiero con el comportamiento del proceso. Por ejemplo, las reclamaciones de mayor importe pueden seguir rutas distintas o tener tiempos de ciclo más largos. Este dato aporta un contexto financiero fundamental a los datos operativos del proceso. Por qué es importante Aporta contexto financiero a la reclamación y permite analizar cómo influye su importe en la ruta de procesamiento, la duración y el resultado. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Es un campo financiero básico de la reclamación, que suele denominarse «Pérdida declarada» o «Reserva inicial». Ejemplos 1500.0025000.50125000.00 | |||
| Perito asignado AssignedAdjuster | Nombre o ID del perito responsable de tramitar el siniestro durante una actividad determinada. | ||
| Descripción Este atributo identifica a la persona o el recurso que realiza una actividad. Puede cambiar a lo largo del ciclo de vida del siniestro cuando el caso pasa de un perito o equipo a otro. Es esencial para analizar el rendimiento de los recursos, la distribución de la carga de trabajo y los traspasos. Los Dashboards sobre el volumen de trabajo de los peritos, las variaciones en la carga de trabajo y la identificación de cuellos de botella suelen depender en gran medida de este atributo para mostrar cómo se asigna y tramita el trabajo. Por qué es importante Permite analizar el rendimiento de los recursos, equilibrar la carga de trabajo y entender los patrones de colaboración, lo que ayuda a identificar cuellos de botella y necesidades de formación. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Busque campos de usuario, propietario o persona asignada en las tablas relacionadas con tareas, eventos o la entidad principal del siniestro. Ejemplos John SmithJane DoeRobert Brownadjuster_1138 | |||
| Tipo de siniestro ClaimType | Categoría del siniestro, como automóvil, propiedad o responsabilidad civil. | ||
| Descripción El tipo de siniestro clasifica los casos según el ramo de actividad o la naturaleza de la pérdida. Es una dimensión fundamental para segmentar y analizar los datos de siniestros. Este atributo se utiliza para comparar el rendimiento del proceso entre distintos tipos de siniestro. Por ejemplo, un siniestro de «Automóvil: pérdida total» sigue un proceso muy distinto y tiene KPI diferentes a los de un siniestro de «Propiedad: daños por agua». Analizar los datos por tipo de siniestro aporta contexto y permite comparar el rendimiento con mayor precisión y adaptar las iniciativas de mejora del proceso. Por qué es importante Es una dimensión clave para segmentar el análisis, ya que los distintos tipos de siniestro suelen tener procesos, acuerdos de nivel de servicio y niveles de complejidad diferentes. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Es un atributo básico del registro principal del siniestro. Ejemplos Automóvil particular: colisiónPropiedad comercial: incendioIndemnización por accidentes laboralesResponsabilidad civil general | |||
| Es automatizada IsAutomated | Indicador booleano que señala si el sistema realizó la actividad automáticamente, sin intervención humana. | ||
| Descripción Este indicador distingue las tareas realizadas por personas de las ejecutadas mediante automatización del sistema, como las notificaciones automáticas, la validación inicial de datos o los pasos de procesamiento directo. Analizar este atributo es clave para comprender el nivel de automatización del proceso de reclamaciones. Ayuda a medir el impacto de las iniciativas de automatización, detectar nuevas oportunidades y comprobar que los pasos automatizados funcionan según lo previsto sin generar problemas posteriores. Por qué es importante Ayuda a medir el impacto de la automatización en la eficiencia y los costes, e identifica oportunidades para procesar reclamaciones de principio a fin sin intervención manual. Dónde obtenerlo Esta información puede deducirse del «usuario» asociado a un evento (por ejemplo, «SYSTEM» o «BATCH») o de un indicador específico del registro del evento. Ejemplos truefalse | |||
| Es retrabajo IsRework | Indicador calculado que señala si una actividad forma parte de un ciclo de retrabajo. | ||
| Descripción Este atributo booleano se establece en verdadero si una actividad se repite para una reclamación después de que ya se hayan realizado otras actividades distintas. Por ejemplo, si el proceso pasa de «Pérdida evaluada» a «Investigación iniciada». Este atributo es esencial para cuantificar y analizar el retrabajo. Permite calcular el KPI «Tasa de retrabajo de reclamaciones» y crear el Dashboard «Patrones de retrabajo y reprocesamiento de reclamaciones», ya que facilita el filtrado y la identificación directa de las actividades y los casos con retrabajo. Así se pueden detectar ineficiencias y problemas de calidad en el proceso. Por qué es importante Cuantifica el retrabajo en cada actividad y facilita la medición, visualización y análisis de las causas y los efectos de las ineficiencias del proceso. Dónde obtenerlo No es un campo del sistema de origen. Se calcula durante la preparación de los datos mediante algoritmos que detectan secuencias de actividades repetidas dentro de una instancia. Ejemplos truefalse | |||
| Fecha objetivo de resolución ResolutionTargetDate | Fecha prevista para resolver la reclamación, según los SLA o los objetivos internos. | ||
| Descripción Este atributo registra la fecha límite para cerrar la reclamación. Suele determinarse según los requisitos normativos, los acuerdos de nivel de servicio (SLA) o los indicadores clave de rendimiento (KPI) internos, y puede variar en función del tipo o la gravedad de la reclamación. Este dato sirve para calcular el KPI «Tasa de resolución puntual de reclamaciones» y respaldar el Dashboard «Cumplimiento del objetivo de resolución de reclamaciones». Permite supervisar de forma proactiva las reclamaciones que corren el riesgo de incumplir el SLA y ayuda a priorizar el trabajo. Por qué es importante Permite medir el rendimiento frente a los acuerdos de nivel de servicio (SLA) y los objetivos internos, lo que repercute directamente en la satisfacción del cliente y el cumplimiento. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Puede tratarse de un campo específico con la fecha del SLA o de una fecha calculada a partir 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 | Marca de tiempo que indica cuándo se completó una actividad. | ||
| Descripción Este atributo indica cuándo se completó una actividad. Mientras que StartTime señala cuándo comenzó, EndTime aporta el otro dato necesario para calcular la duración de esa tarea. En Process Mining, disponer de las horas de inicio y finalización de las actividades permite analizar el rendimiento con mucho más detalle. Así se puede calcular con precisión el «Tiempo de procesamiento» (el tiempo de trabajo activo en una tarea) y el «Tiempo de espera» (el tiempo transcurrido entre tareas). Esta distinción es fundamental para identificar cuellos de botella con precisión. Por qué es importante Permite calcular con precisión los tiempos de procesamiento de las actividades y distinguir el tiempo de trabajo activo del tiempo de inactividad o espera, algo esencial para analizar correctamente los cuellos de botella. Dónde obtenerlo Puede estar disponible como un campo de marca de tiempo independiente en los registros de eventos o calcularse a partir del StartTime de la siguiente actividad de la misma instancia. Ejemplos 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Importe de la indemnización SettlementAmount | Importe final acordado para resolver la reclamación. | ||
| Descripción Este atributo registra el importe de la indemnización calculado y autorizado para el pago. Es una métrica clave de resultados para cada reclamación que termina en un pago. Este atributo es fundamental para el análisis financiero y para Dashboards como «Autorización del pago y tiempo de emisión». Permite comparar el importe con el «Importe de la pérdida» inicial para analizar la precisión de las reservas y es esencial para comprender los resultados financieros del proceso de reclamaciones. Por qué es importante Representa el principal resultado financiero de una reclamación y es esencial para los informes financieros y el análisis de la precisión de las estimaciones iniciales de pérdidas. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Esta información suele almacenarse en tablas de transacciones financieras o de pagos asociadas a la reclamación. Ejemplos 1450.7522000.00115800.20 | |||
| Motivo del rechazo RejectionReason | Motivo concreto por el que se denegó o rechazó una reclamación. | ||
| Descripción Cuando se decide denegar una reclamación, este atributo indica el motivo de la decisión. Por lo general, se selecciona de una lista predefinida de códigos o descripciones. Analizar los motivos de rechazo es fundamental para el Dashboard «Análisis de decisiones y rechazos de reclamaciones». Ayuda a detectar problemas frecuentes en las solicitudes, posibles patrones de fraude o aspectos de las pólizas que podrían no estar claros. Esta información puede impulsar mejoras en el proceso de recepción o en las reglas de suscripción. Por qué es importante Explica por qué se deniegan las reclamaciones y aporta información útil para mejorar el proceso de recepción, reducir las solicitudes no válidas e identificar necesidades de formación. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Este campo suele completarse cuando el estado de una reclamación cambia a «Denegada» o a un estado similar. Ejemplos Riesgo no cubiertoPóliza vencidaReclamación duplicadaPosible fraude | |||
| Número de póliza PolicyNumber | Identificador único de la póliza de seguro con la que se presentó la reclamación. | ||
| Descripción Este atributo vincula la reclamación con la póliza de seguro de origen. Aporta contexto sobre la cobertura, las condiciones y el cliente asociados a la reclamación. Aunque no siempre se utiliza directamente para analizar el flujo del proceso, el número de póliza es muy valioso para enriquecer los datos de las reclamaciones. Permite combinar estos datos con los de pólizas y clientes para analizar cómo varía el rendimiento del proceso según el segmento de clientes, el tipo de póliza o su antigüedad, y obtener así una visión más completa del negocio. Por qué es importante Vincula la reclamación con el cliente y la póliza, lo que permite analizar de forma más amplia cómo afecta el rendimiento del proceso a distintos segmentos de clientes o tipos de póliza. Dónde obtenerlo Consulte la documentación de Duck Creek Claims. Es un campo de referencia estándar de la entidad principal de reclamaciones. Ejemplos PA-987654321CP-123456789WC-555444333 | |||
| Se resolvió a tiempo IsOnTimeResolution | Indicador calculado que señala si la reclamación se cerró en la fecha objetivo de resolución o antes. | ||
| Descripción Este atributo booleano se obtiene al comparar la marca de tiempo de la actividad «Reclamación cerrada» con la «ResolutionTargetDate» de esa reclamación. Indica si se resolvió a tiempo (verdadero) o con retraso (falso). Este atributo respalda directamente el KPI «Tasa de resolución puntual de reclamaciones». Facilita la agregación y visualización del cumplimiento de los SLA en los Dashboards y permite analizar los datos con más detalle para identificar características comunes de las reclamaciones atrasadas, como tipos de reclamación, departamentos o rutas del proceso específicos. Por qué es importante Mide directamente el cumplimiento del SLA para cada reclamación y permite filtrar y analizar las causas raíz de los casos vencidos. Dónde obtenerlo No es un campo del sistema de origen. Se calcula durante la preparación de los datos, comparando la marca de tiempo de la actividad final con el campo «ResolutionTargetDate». Ejemplos truefalse | |||
| Sistema de origen SourceSystem | Sistema del que se extrajeron los datos de eventos. | ||
| Descripción Este atributo identifica la aplicación de origen de los datos del siniestro. En este caso, siempre será «Duck Creek Claims». Aunque pueda parecer redundante si todos los datos proceden de un solo sistema, es fundamental para la gobernanza de datos y la trazabilidad, así como para situaciones futuras en las que se combinen datos de varios sistemas. Aporta contexto sobre el origen y la estructura de los datos. Por qué es importante Proporciona información esencial sobre el linaje y el contexto de los datos, aspectos fundamentales para la gobernanza de datos y la resolución de problemas, sobre todo en entornos con varios sistemas integrados. Dónde obtenerlo Por lo general, es un valor estático que se añade durante la extracción y transformación de datos para indicar su origen. Ejemplos Reclamaciones de Duck Creek | |||
| Última actualización de los datos LastDataUpdate | Marca de tiempo de la actualización más reciente de los datos del sistema de origen. | ||
| Descripción Este atributo indica cuándo se actualizó el conjunto de datos por última vez. Permite saber si los datos analizados están actualizados. En los Dashboards y los análisis, informa sobre la actualidad de la información disponible. También ayuda a determinar si la vista del proceso incluye las transacciones más recientes. Por qué es importante Informa sobre la actualidad de los datos, algo fundamental para interpretar el análisis y tomar decisiones a tiempo. Dónde obtenerlo Esta marca de tiempo se genera durante el proceso de extracción, transformación y carga de datos (ETL) y suele almacenarse en los metadatos del conjunto de datos. Ejemplos 2024-05-21T02:00:00Z | |||
Actividades de la gestión de reclamaciones
| Actividad | Descripción | ||
|---|---|---|---|
| Decisión sobre el siniestro tomada | Esta actividad representa la decisión oficial sobre el siniestro, por ejemplo, «Aprobado», «Aprobado parcialmente» o «Denegado». Es un hito decisivo que se infiere a partir de un cambio a un estado de decisión final. | ||
| Por qué es importante Es un hito clave en la toma de decisiones. El tiempo hasta este punto y el resultado de la decisión son aspectos centrales para analizar el proceso y su eficiencia. Dónde obtenerlo Se infiere a partir de un cambio en un campo específico de «Decisión sobre el siniestro» o «Estado del siniestro» a un estado final, como «Aprobado» o «Denegado». Se registra la marca de tiempo del cambio. Capturar Se infiere a partir de una actualización del estado principal o del campo de decisión del siniestro. Tipo de evento inferred | |||
| Pago autorizado | Representa la aprobación formal del pago del importe calculado de la liquidación. A menudo, es un paso independiente que requiere la intervención de un gerente u otra autoridad y se registra como una transacción de aprobación explícita. | ||
| Por qué es importante Es un punto de control clave y un posible cuello de botella antes del pago. El KPI «Tiempo medio de aprobación de siniestros» mide el tiempo transcurrido desde «Decisión sobre el siniestro tomada» hasta este punto. Dónde obtenerlo Suele ser un evento explícito en un flujo de trabajo o módulo financiero, donde una persona con permisos específicos aprueba el pago. Se encuentra en un registro de aprobaciones. Capturar Evento de aprobación explícito registrado en un flujo de trabajo o en un 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 evento explícito que se genera cuando se envía el pago mediante cheque, transferencia electrónica u otro método. | ||
| Por qué es importante Señala que se ha cumplido la obligación financiera correspondiente a un siniestro aprobado. El tiempo entre «Pago autorizado» y «Pago emitido» permite evaluar la eficiencia del departamento financiero. Dónde obtenerlo Se obtiene de la tabla de transacciones financieras de Duck Creek Claims, que registra todos los pagos salientes con un código de transacción y una marca de tiempo específicos. Capturar Al procesar el pago, se crea una entrada independiente en el registro de transacciones financieras. Tipo de evento explicit | |||
| Siniestro cerrado | Esta es la actividad final y marca el cierre administrativo del expediente del siniestro, una vez emitido el pago o liquidado el siniestro. Se registra con la actualización final del estado a «Cerrado». | ||
| Por qué es importante Esta actividad marca el fin satisfactorio del proceso. Es el punto final para calcular el KPI «Tiempo de ciclo total medio del siniestro» y otras métricas de duración clave. Dónde obtenerlo Se infiere a partir de la marca de tiempo del cambio final de estado a «Cerrado» o «Liquidado» en la tabla principal de datos del siniestro. Capturar Se infiere cuando el estado final del siniestro se establece como «Cerrado». Tipo de evento inferred | |||
| Siniestro denegado | Esta actividad representa un desenlace alternativo del proceso: el siniestro se deniega oficialmente. Se registra cuando el estado final del siniestro se establece como «Denegado» o «Rechazado». | ||
| Por qué es importante Es un resultado crítico que debe analizarse por separado. Entender por qué y cuándo se deniegan los siniestros ayuda a mejorar los procesos de recepción y a gestionar el cumplimiento. Dónde obtenerlo Se infiere a partir de la marca de tiempo del cambio final de estado del siniestro a «Denegado», «Rechazado» o «Cerrado sin pago» en la tabla de la entidad de siniestro. Capturar Se infiere cuando el estado final del siniestro indica que se ha denegado. Tipo de evento inferred | |||
| Siniestro presentado | Este es el primer evento y representa la recepción por parte de la aseguradora del primer aviso de siniestro (FNOL). Por lo general, se registra como una transacción explícita cuando un agente o titular de la póliza introduce en el sistema los datos iniciales del siniestro. | ||
| Por qué es importante Esta actividad marca el inicio de todo el ciclo de vida del siniestro. Analizar el tiempo transcurrido entre este evento y los siguientes es fundamental para entender la duración total de la tramitación y la eficiencia de la recepción inicial. Dónde obtenerlo Suele ser un evento explícito que se registra en una tabla de siniestros o de FNOL cuando se crea por primera vez un nuevo registro de siniestro en Duck Creek Claims. Capturar Evento registrado al crear por primera vez un nuevo registro de siniestro. Tipo de evento explicit | |||
| Información adicional recibida | Marca la recepción de la información solicitada, lo que permite reanudar la tramitación del siniestro. El perito puede registrarla manualmente o el sistema puede hacerlo automáticamente 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 periodo de espera clave. Analizar su duración ayuda a detectar dependencias externas y cuellos de botella en la comunicación. Dónde obtenerlo Puede ser un evento explícito procedente de la integración con un sistema de gestión documental, una entrada manual en el registro o un cambio de estado que el perito realiza al recibir los documentos. Capturar Evento registrado al cargar un documento o cuando un perito introduce los datos manualmente. Tipo de evento explicit | |||
| Información adicional solicitada | Esta actividad se produce cuando el perito determina que necesita más información y envía una solicitud al titular de la póliza o a un tercero. A menudo, es un evento explícito vinculado al módulo de comunicaciones o correspondencia del sistema. | ||
| Por qué es importante Una frecuencia elevada de esta actividad puede indicar problemas en la recopilación inicial de datos. También genera un tiempo de espera considerable que afecta al tiempo de ciclo general. Dónde obtenerlo Se obtiene de los registros de comunicaciones salientes, como cartas o correos electrónicos, o de una transacción específica de «Solicitud de información» en Duck Creek Claims. Capturar Se registra cuando se genera una correspondencia o una 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 datos necesarios. Por lo general, se infiere cuando el estado del siniestro pasa de «En investigación» a un estado de toma de decisiones, como «Decisión pendiente». | ||
| Por qué es importante Completar la investigación es un hito importante que permite avanzar a las fases de toma de decisiones y liquidación. Las demoras en esta etapa tienen un impacto considerable en las fases posteriores. Dónde obtenerlo Se infiere a partir de la marca de tiempo de una actualización del estado del siniestro, que pasa de «En investigación» a un estado de revisión o decisión. Capturar Se obtiene de un cambio en el estado del siniestro que indica el fin de las actividades de investigación. Tipo de evento inferred | |||
| Investigación iniciada | Esta actividad señala el inicio de la fase formal de investigación del siniestro. A menudo, se infiere a partir de un cambio de estado del siniestro a «En investigación» o a un estado similar. | ||
| Por qué es importante Marca el inicio de una fase que requiere muchos 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 obtenerlo Se infiere a partir de la marca de tiempo de una actualización del estado del siniestro a «Investigación en curso» o «Inspección pendiente» en el campo de estado principal. Capturar Se obtiene de un cambio en el estado del siniestro que indica el inicio de las actividades de investigación. Tipo de evento inferred | |||
| Liquidación calculada | Tras la aprobación del siniestro, esta actividad representa el cálculo del importe final de la liquidación o del pago. Puede ser un paso explícito o inferirse a partir de la finalización de los importes de pago en el módulo financiero del sistema. | ||
| Por qué es importante Esta actividad es fundamental para medir el KPI «Tasa de retrabajo de liquidaciones». Si se produce varias veces para un mismo siniestro, puede indicar ineficiencias, errores o negociaciones durante la fase de liquidación. Dónde obtenerlo Puede ser una entrada explícita en el registro de transacciones o inferirse a partir de las actualizaciones del campo «Importe de la 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 | |||
| Pérdida evaluada | Este hito marca el momento en que se fijan o actualizan las reservas financieras a partir de los resultados de la investigación. Representa la estimación del impacto financiero del siniestro y se registra cuando se introducen o ajustan los importes de las reservas. | ||
| Por qué es importante Es un punto de control financiero crítico del proceso. Analizar cuándo se produce permite conocer la rapidez y la precisión de la evaluación financiera. Dónde obtenerlo A menudo, se trata de una transacción financiera explícita registrada en el historial de transacciones financieras del siniestro o en la tabla del historial de reservas de Duck Creek Claims. Capturar Transacción financiera registrada al fijar o actualizar las reservas del siniestro. Tipo de evento explicit | |||
| Perito asignado | Este evento registra la asignación de un perito o gestor de siniestros al siniestro registrado. El sistema guarda esta asignación, establece un punto claro de traspaso y determina quién se hace cargo del siniestro durante su ciclo de vida. | ||
| Por qué es importante Es fundamental para analizar la asignación de recursos y la carga de trabajo de los peritos, así como para detectar demoras en la asignación de siniestros. Es un punto clave de traspaso que puede generar tiempos de espera. Dónde obtenerlo Se registra mediante una actualización del campo «Perito asignado» en la tabla principal de datos del siniestro. El historial o registro de auditoría de este campo proporciona la marca de tiempo. Capturar Se registra en el historial de auditoría cuando se completa o modifica el campo del perito. 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. Por lo general, se infiere 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 permite medir el tiempo hasta la primera actuación del perito y puede revelar posibles acumulaciones de trabajo. Es el primer punto de control importante en el que interviene una persona. Dónde obtenerlo Se infiere a partir de un cambio en el campo de estado del siniestro, por ejemplo, al pasar a «Revisión inicial completada» o «Información pendiente». Se utiliza la marca de tiempo de ese cambio. Capturar Se infiere a partir de un cambio en el campo de estado del siniestro después de asignar al perito. Tipo de evento inferred | |||
| Siniestro registrado | Marca la aceptación y el registro formal del siniestro presentado, momento en que se asigna oficialmente un ID de siniestro único. A menudo, se trata de un evento automatizado del sistema que se produce tras validar los datos iniciales. | ||
| Por qué es importante Formaliza el inicio del siniestro y activa procesos posteriores, como la asignación de un perito. El tiempo entre la presentación y el registro puede revelar problemas de calidad de los datos iniciales o de carga del sistema. Dónde obtenerlo Se infiere a partir de la marca de tiempo en que se genera el ID de siniestro principal y el estado cambia de «pendiente» o «presentado» a «abierto» o «registrado» en la tabla principal de la entidad de siniestro. Capturar Se obtiene de la marca de tiempo de creación del registro principal del siniestro o de un cambio de estado a «Abierto». 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 el entorno de Duck Creek y vaya a la aplicación Data Hub. Necesitará los permisos adecuados para crear o modificar configuraciones de exportación de datos.
- Cree un nuevo trabajo de exportación de datos: En 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 que se conecte a la base de datos SQL principal de Data Hub. Deberá indicar el nombre del servidor y de la base de datos, así como las credenciales de un usuario con acceso de lectura a los esquemas pertinentes.
- Introduzca la consulta de extracción: Vaya a la sección de definición de consultas del trabajo de exportación. Copie el script completo de la sección de consultas que aparece a continuación y péguelo en el editor de consultas.
- Configure los parámetros de la consulta: Busque la sección de parámetros en la configuración. Defina los parámetros @StartDate y @EndDate de la consulta y asígneles valores para especificar el intervalo de fechas que desea extraer. Por ejemplo, '2023-01-01' y '2023-12-31'.
- Asigne las columnas de salida: Configure los ajustes del archivo de salida. Compruebe que las columnas definidas en la instrucción SELECT (ClaimId, ActivityName, EventTime, etc.) estén correctamente asignadas a las columnas del archivo de salida. Los encabezados del archivo deben coincidir exactamente con estos nombres.
- Configure el archivo de salida: Especifique CSV como formato de salida. Establezca la coma (,) como delimitador y UTF-8 como codificación de caracteres 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. Compruebe que el sistema tenga permisos de escritura en esa ubicación.
- Programe el trabajo de exportación: Configure la programación del trabajo. Para el análisis inicial, puede ejecutarlo manualmente. Para el seguimiento continuo, programe ejecuciones periódicas, por ejemplo, diarias o semanales.
- Ejecute el trabajo y recupere el archivo: Ejecute el trabajo para generar el archivo del registro de eventos. Cuando termine, recupere el archivo CSV del destino especificado en el paso 8.
- Prepare el archivo para cargarlo: Antes de cargarlo en ProcessMind, abra el archivo CSV y haga una última comprobación. Verifique que los encabezados sean correctos, que el formato de fecha y hora sea uniforme (YYYY-MM-DD HH:MI:SS) y que los datos tengan el aspecto esperado.
Configuración
- Requisitos previos: Se necesita acceso al módulo Duck Creek Data Hub. El usuario o la cuenta de servicio que ejecute el trabajo de exportación debe tener permisos de lectura en las tablas de la base de datos subyacente de Data Hub (por ejemplo, [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory]).
- Configuración del intervalo de fechas: La consulta utiliza los parámetros @StartDate y @EndDate. Es fundamental asignarles valores para definir el periodo de extracción. Para el primer análisis, se recomienda un periodo de entre 6 y 12 meses que permita incluir suficientes casos completados y en curso.
- Filtrado: La consulta incluye el marcador /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ dentro de la expresión de tabla común (CTE). Quite los comentarios de esta línea y modifíquela para filtrar por líneas de negocio específicas, por ejemplo, 'Personal Auto' o 'Commercial Property'. Así reducirá el volumen de datos y centrará el análisis.
- Frecuencia de actualización de Data Hub: Tenga en cuenta la latencia de los datos de Data Hub. No son datos en tiempo real y, por lo general, se actualizan según una programación, por ejemplo, cada noche. Los datos extraídos estarán actualizados hasta la última actualización correcta de Data Hub.
- Formato de salida: Configure el trabajo de exportación para generar un archivo plano, preferiblemente CSV. Establezca las comillas dobles (") como calificador de texto para gestionar las comas que puedan aparecer dentro de los campos.
Consulta de ejemplo sql
-- 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; ¿Todo listo para empezar?
Con este Template, dispone de todo lo necesario para empezar a optimizar la gestión de reclamaciones. Comience hoy mismo a trabajar con sus datos y descubra información valiosa.
Ponga fin a la acumulación de reclamaciones: optimice ahora su tramitación
Alcance un 70 % de procesamiento directo para reducir costes y retrasos.
Prueba gratuita de 14 días, sin necesidad de tarjeta de crédito.