Cuándo debe una aseguradora sustituir su sistema de reclamaciones

Una plataforma de siniestros no se estropea de golpe. Se va deteriorando poco a poco a causa de las señales de alerta que surgen en el día a día. Los peritos tienen que llevar hojas de cálculo paralelas porque las reservas no cuadran bien. Los supervisores no saben por qué se ha aprobado un pago sin haber consultado tres sistemas distintos. Un perito hace una pregunta básica sobre la cobertura y lo ponen en espera para que busque manualmente la póliza. Estas fricciones son las que importan cuando una aseguradora decide cambiar su software de siniestros, no si la lista de funciones del proveedor era o no poco atractiva.

Como director de sistemas de información (CIO) o responsable de aplicaciones empresariales, la cuestión no es si la plataforma de siniestros es antigua, sino si el modelo operativo de siniestros puede dar respuesta a la gama de productos de la aseguradora, los requisitos normativos, las integraciones con socios y las expectativas de nivel de servicio sin que ello suponga un riesgo inaceptable para el control. La sustitución del sistema de siniestros puede reducir el tiempo que transcurre desde la notificación inicial del siniestro (FNOL) hasta su asignación, mejorar los controles de pago y aumentar la aceptación por parte de los peritos, pero también implica años de exposición al riesgo de migración si no se gestiona bien el alcance del proyecto.

Sustituir el software de siniestros es una decisión de modelo operativo

Las aplicaciones de gestión de siniestros interactúan con la administración de pólizas, la gestión de documentos, los pagos, la investigación de fraudes, la subrogación, los litigios, las redes de reparación y las finanzas. Por eso, un sistema de gestión de siniestros que parezca estable en el inventario tecnológico puede ser, en realidad, una bomba de relojería. El núcleo de la gestión de siniestros funciona perfectamente, pero la toma de decisiones sobre los siniestros se lleva a cabo, en realidad, de forma dispersa a través de correos electrónicos, hojas de cálculo, unidades compartidas, un almacén de datos y portales para administradores externos.

Por eso, según la Norma Modelo de Auditoría de la NAIC, la dirección debe contar con controles sólidos sobre la información financiera. En el ámbito de los siniestros, esto significa tener un registro de quién realizó un ajuste en las reservas, quién aprobó un pago de indemnización, qué norma de autoridad se aplicó y si el sistema fue capaz o no de registrar esa información. Si la matriz de aprobación está tanto en la plataforma de siniestros como en las bandejas de entrada, no es que los usuarios tengan que lidiar con inconvenientes. El diseño del control es defectuoso.

Plataformas como Guidewire ClaimCenter o Duck Creek Claims son el punto de partida ideal si una aseguradora necesita funciones de gestión de siniestros contrastadas, configuración de productos y una vía de actualización a nivel empresarial. Salesforce Financial Services Cloud es el punto de partida ideal si la aseguradora quiere centrarse en los aspectos de servicio y relación del negocio, sobre todo si los asegurados, los corredores y las interacciones de servicio necesitan una visión unificada. Ninguna de estas categorías resuelve el diseño de los flujos de trabajo. Cuando una aseguradora traslada sus colas de siniestros heredadas, sus reglas de excepción y sus procesos de filtrado a una nueva plataforma, suele mantener las mismas limitaciones, solo que con un coste de implementación más elevado.

¿Cuándo hay que cambiar el software de gestión de reclamaciones?

No es la antigüedad de la plataforma de reclamaciones lo que debe indicar a una aseguradora que debe cambiar su software. Es cuando los cambios en el negocio chocan con las limitaciones del sistema. Esto podría significar que una aseguradora haya lanzado nuevos productos especializados que requieran cambios constantes en el código base. Podría significar que el personal de reclamaciones no pueda aplicar de forma coherente la autoridad de reservas por línea de negocio. Podría significar que los administradores externos envíen archivos que requieran volver a introducir los datos manualmente antes de poder tramitar un siniestro.

No te fijes solo en el tiempo de actividad, fíjate también en la tasa de excepciones

Una plataforma de reclamaciones puede tener un tiempo de actividad excelente, pero obligar a los equipos a recurrir a soluciones provisionales. Haz un seguimiento del porcentaje de reclamaciones que se salen del proceso habitual. Lleva un control del número de veces que se interviene manualmente en una reclamación entre la notificación inicial (FNOL) y la asignación. Controla el tiempo que se tarda en resolver una excepción de pago. Controla cuántas veces los peritos reabren reclamaciones por falta de documentación, información de la póliza o contexto de autoridad en la decisión inicial.

Aquí no hay una cifra mágica. Los seguros de particulares, los de accidentes laborales y las reclamaciones comerciales complejas se gestionan de forma diferente. Lo que importa es la tendencia y la concentración. Si un pequeño número de excepciones supone una gran parte de los casos que se remiten a los supervisores, la solución podría ser rediseñar el flujo de trabajo de forma específica. Si las excepciones abarcan la recepción de reclamaciones, la verificación de la cobertura, los pagos, las recuperaciones y la elaboración de informes, puede que el modelo operativo se haya quedado pequeño para la plataforma.

Detectar la deuda de integración en el expediente del siniestro

En la mayoría de los casos, la sustitución de sistemas de gestión de siniestros se debe a problemas de integración, no a fallos en la funcionalidad. Los datos de las pólizas llegan tarde. El estado de los pagos no se muestra al perito. Hay notas y documentos duplicados. Los picos de recepción de siniestros catastróficos saturan un proceso por lotes diseñado para volúmenes normales de siniestros.

Antes de que una aseguradora elija una nueva plataforma de gestión de siniestros o reclamaciones, haz una lista de las integraciones de datos reales: administración de pólizas, facturación, contabilidad general, servicios de pago, datos geoespaciales, generación de documentos, redes de reparación, SIU, gestión de litigios y plataformas de datos corporativas. No te conformes con una matriz de interfaces que solo enumere aplicaciones. Para cada integración, averigua cuál es el evento desencadenante, quién es el propietario de los datos, la latencia, la lógica de reintentos y el control de conciliación. Es aquí donde muchas aseguradoras se dan cuenta de que algunas integraciones deberían eliminarse, mientras que otras deberían adoptar un enfoque basado en eventos en lugar de un archivo nocturno.

Sustituir el núcleo, la experiencia o ambos

La implantación más arriesgada en reclamaciones es la que toma los problemas de la plataforma actual como prueba de que ha llegado el momento de sustituir el núcleo. A veces, el límite está realmente en el núcleo. Otras, a la aseguradora le basta con rediseñar la recepción y la atención, agilizar la gestión del trabajo o sentar una base de datos gobernada. Por ejemplo, una aseguradora puede mantener ClaimCenter como núcleo de siniestros y reconstruir en Salesforce Financial Services Cloud los flujos de atención a agentes y tomadores. Un caso de Service Cloud puede gestionar las consultas, mostrar el estado aprobado del siniestro y derivar las excepciones, sin que los gestores tengan que lidiar con otro sistema de registro duplicado. MuleSoft puede actuar como capa de integración mediante API cuando la arquitectura lo requiera, pero disponer de APIs no sustituye tener claro quién es responsable de los datos de siniestros, personas, pólizas y pagos.

Por otro lado, una aseguradora con un código heredado de gestión de siniestros muy personalizado puede encontrar más ventajas en sustituir el núcleo del sistema cuando la configuración de productos, el mantenimiento de reglas y la cadencia de lanzamientos se vuelvan insostenibles. Aquí hay un coste y un beneficio reales. Cuando implementas un sistema de reclamaciones «listo para usar», limitas el comportamiento personalizado. Cuando tienes software a medida, permites un flujo de trabajo de siniestros diferenciado a costa de una carga de mantenimiento a largo plazo. Lo que más te convenga como aseguradora depende de si tu flujo de trabajo de siniestros es diferenciado o no y de la frecuencia con la que cambia. También depende de si tu aseguradora tiene o no la disciplina de producto e ingeniería necesaria para gestionar las funcionalidades personalizadas.

Priorizar el programa de siniestros en función del riesgo

No hay por qué optar por una conversión radical en el caso de un cartera de reclamaciones consolidada. Las reclamaciones pendientes pueden estar abiertas durante años. Hay que tener a mano su situación financiera, su situación jurídica y el historial de la documentación. La línea de negocio, la jurisdicción, el tipo de reclamación y si se trata de reclamaciones nuevas o pendientes son factores que permiten una conversión por fases, pero solo si se puede diseñar el sistema de informes y controles tanto en el sistema antiguo como en el nuevo mientras coexistan.

El proceso de tramitación de reclamaciones en el estado futuro debe ser lo suficientemente detallado como para poder configurarlo. Cómo se registra una reclamación inicial (FNOL). Cómo se verifica la cobertura. Cómo funcionan las reglas de asignación. Cómo se valida la autoridad de reserva. Cómo se aprueban los pagos. Cómo las reclamaciones o las retenciones por litigio modifican el flujo de trabajo. Los requisitos no funcionales, como los picos de volumen de reclamaciones por catástrofes, los objetivos de tiempo de recuperación, los periodos de retención, la accesibilidad, los registros de auditoría y la residencia de datos, suelen pasarse por alto. Hay que definirlos antes de que empiece el proyecto.

Para las aseguradoras afectadas por el Reglamento de Ciberseguridad del Departamento de Servicios Financieros de Nueva York (23 NYCRR 500), el programa de sustitución de reclamaciones no debe limitarse únicamente al perímetro de la red. Los controles de los proveedores de servicios externos, la gestión del acceso privilegiado, la respuesta ante incidentes y la clasificación de datos deben integrarse en el diseño de la arquitectura y el enfoque de implementación. Tener datos confidenciales de los solicitantes de indemnizaciones en entornos de prueba sin control antes de la puesta en marcha es un riesgo evitable que surge de la migración de las reclamaciones.

La migración de datos es la reconstrucción de pruebas

La migración de datos de siniestros no es un simple proceso de extracción, transformación y carga. El sistema de siniestros debe contar con suficiente contexto histórico para que los peritos puedan tomar decisiones fundamentadas sobre los siniestros, los equipos financieros puedan conciliar las reservas y los pagos, y los equipos jurídicos puedan responder a las solicitudes de presentación de pruebas o de reclamaciones. No todos los campos de datos heredados deben migrarse. Para cada campo que no se migre, hay que tomar una decisión sobre su conservación, recuperación y titularidad.

Conciliar a nivel de reclamación y a nivel financiero. Asegúrate de que el número de reclamaciones sea correcto. Asegúrate de que los importes pagados sean correctos. De que las reservas pendientes sean correctas. Que las recuperaciones sean correctas. Asegúrate de que el estado de pago sea correcto y de que las fechas clave del ciclo de vida también lo sean. En el caso de los archivos muestreados, asegúrate de que un supervisor pueda reconstruir el razonamiento que hay detrás de una decisión sobre una reserva o un pago sin tener que recurrir a un archivo desconectado. Aquí es donde deben participar los equipos de gestión de reclamaciones, finanzas, asuntos jurídicos, gestión de registros y auditoría interna, y no después de que se haya completado la lógica de conversión.

El diseño de la experiencia de usuario (UX) hay que plantearlo en el contexto del control. Un espacio de trabajo para peritos que no muestre el estado de las autorizaciones, los pagos anteriores o la documentación necesaria obligará a buscar soluciones alternativas, por muy sólidas que sean las reglas del sistema. Las pantallas basadas en roles deberían reducir el número de campos que ve un perito, al tiempo que garantizan que el contexto de la decisión sea visible. Las métricas de adopción deberían incluir las tasas de finalización, el tiempo de espera en cola, las tareas reabiertas y el tiempo dedicado a la formación, no solo las encuestas de satisfacción.

Usa la IA cuando la decisión pueda estar controlada

La IA puede ayudar a los equipos de siniestros con la clasificación de documentos, el resumen de la correspondencia, la extracción de datos de las solicitudes y la recuperación de información relevante sobre los siniestros. No debería determinar por su cuenta la cobertura, los importes de las reservas o los resultados desfavorables sin una autoridad definida, trazabilidad y revisión humana. En el caso de las operaciones reguladas, la cuestión práctica es si la organización puede mostrar las fuentes de entrada, los controles de prompts y modelos, el tratamiento de los resultados, las acciones de los revisores y la ruta de las excepciones.

Un primer caso de uso útil suele estar limitado: clasificar los documentos que llegan, extraer un conjunto conocido de campos, asignar una puntuación de confianza y derivar los casos con baja confianza a un usuario con experiencia. Eso aporta un valor medible sin convertir un modelo opaco en quien toma las decisiones sobre las reclamaciones. El diseño también debería tener en cuenta la conservación de datos, los controles de acceso, el riesgo de inyección de mensajes y si los datos de los solicitantes pueden enviarse al entorno del modelo elegido.

El mejor momento para cambiar de software de gestión de siniestros es cuando la aseguradora puede explicar, en términos operativos, qué va a cambiar desde el primer día: menos traspasos manuales, un historial de aprobaciones más claro, una asignación más rápida y un expediente de siniestro que resista cualquier escrutinio. La tecnología con un propósito claro empieza ahí: por el flujo de trabajo, las pruebas y las personas que van a utilizarlos.