Optimització de processos actuarials i HPC
Una gran asseguradora europea amb processos actuarials crítics s'enfrontava a temps de càlcul insostenibles i una infraestructura HPC estàtica incapaç d'adaptar-se a la demanda.
Repte
Infraestructura HPC estàtica i codi legacy sense documentació. Els cicles de tancament mensual consumien dies de càlcul, amb colls d'ampolla en els processos actuarials més crítics.
Solució
Diagnòstic detallat de l'entorn actuarial, optimització HPC progressiva per fases i refactorització modular del codi. Desplegament sense interrompre els cicles de negoci crítics.
Tecnologies
- HPC / Grid Computing
- Optimització de codi actuarial
- Infraestructura híbrida
- Monitoratge de rendiment
Contexto
Una gran aseguradora europea operaba sus procesos actuariales y colectivos sobre un stack Oracle heredado (Oracle 10g, Oracle Forms, PL/SQL, Pro*C). Los cálculos clave requerían hasta 36 horas, la lógica de negocio estaba embebida en código sin documentación y, sin el equipo original, cada intervención resultaba más costosa. A eso se sumaba un ROI prolongado: inversiones que tardaban hasta tres años en recuperarse.
El objetivo acordado fue triple: acelerar y simplificar los procesos actuariales y colectivos, modernizar el sistema sin interrumpir la operación diaria, y garantizar precisión y cumplimiento normativo con mayor eficiencia. Todo ello con reportes exactos al cierre de mes como restricción innegociable.
El reto
Los procesos actuariales y colectivos estaban frenados por una infraestructura desactualizada. Las operaciones, esenciales para la evaluación de riesgos y el cumplimiento normativo, sufrían cuellos de botella que afectaban tanto a la eficiencia como a la fiabilidad de los resultados:
- Procesos obsoletos: código antiguo y tecnología desactualizada.
- Altos tiempos de procesamiento: hasta 36 horas para calcular los colectivos y los actuariales.
- Cumplimiento normativo: requisitos estrictos que exigían reportes precisos al cierre de mes.
- Deuda tecnológica: sin el equipo original, mantener el sistema era cada vez más complicado.
- Impacto financiero: un ROI prolongado, con inversiones que tardaban hasta tres años en recuperarse.
Enfoque por fases
La intervención se estructuró en fases, lo que facilitó una implementación ordenada, controlada y alineada con los ciclos operativos de la aseguradora. Tres principios la guiaron: estabilidad operativa (actuar sobre los sistemas sin alterar su disponibilidad), enfoque gradual (priorizar los procesos actuariales y colectivos más críticos) y visión técnica y de negocio (conocimiento técnico profundo con comprensión del entorno regulatorio y de riesgos).
-
01
Fase de estudio
Análisis del código, revisión de los procesos actuariales y colectivos y levantamiento de información de negocio.
-
02
Identificación de problemas
Cuellos de botella en cuatro funciones principales, código histórico sin documentación y procesos lentos e inflexibles.
-
03
Diseño de la solución
Planificación por fases, reestructuración modular y priorización de las tareas críticas.
-
04
Implementación y validación
Subidas por etapas sin interrumpir las operaciones y validación funcional continua.
-
05
Cierre
Resultados validados, entorno optimizado y reducción drástica del tiempo de procesamiento.
Arquitectura y estrategia
La estrategia se construyó sobre cuatro pilares. Diagnóstico detallado del entorno actuarial y colectivo: se levantó la infraestructura existente, la lógica del negocio, el código y los procesos más críticos, identificando cuellos de botella, duplicidades y procedimientos sin documentar. Refactorización modular del código: se trabajó sobre los procedimientos más demandantes, reescribiendo funciones, eliminando redundancias y reorganizando la lógica; la refactorización se concentró en los cuatro procesos (pólizas, asegurador, capital y reserva) que acumulaban más del 90 % del tiempo de cómputo.
Optimización de infraestructura HPC: ajuste de los recursos según la carga real y validación de la precisión de los cálculos en cada iteración. Mejora progresiva por fases: subidas por etapas con validaciones intermedias, garantizando la continuidad operativa sin afectar a los ciclos de cierre mensual. En paralelo se desacopló la arquitectura hacia microservicios (frontend ReactJS, backend API .NET, motor de cálculo actuarial y microservicios de base de datos), con caché Redis y compatibilidad dual Oracle/SQL Server durante la transición, hasta eliminar por completo la dependencia de Oracle en favor de .NET, Python, SQL Server y Azure SQL.
Resultados medibles
Durante la fase inicial se detectó qué procesos consumían más tiempo, lo que permitió centrar la primera iteración exclusivamente en los más críticos y lograr un impacto inmediato en el rendimiento.
| Indicador | Antes | Después |
|---|---|---|
| Aceleración de los procesos actuariales | Cálculos clave de hasta 36 h | +80 % (refactorización modular) |
| Mejora en el proceso optimizado | Proceso de mayor consumo de cómputo | 98,62 % |
| Tiempo total de la 1.ª iteración crítica | 1.080 minutos | 370 minutos |
| Dependencia de Oracle (PL/SQL, Pro*C, Forms) | Total | Eliminada (.NET / Python / SQL Server / Azure SQL) |
| Continuidad durante la migración | Riesgo en cada cierre mensual | Sin interrupciones (subidas por etapas con validación) |
| Puntuación de seguridad M365 (refuerzo de accesos) | 11,48 % | +30 % sobre la base, con MFA en roles críticos |
Cifras agregadas y anonimizadas por acuerdo de confidencialidad. Fuente: proyectos de Vermont Solutions.
Lecciones aplicables
- Priorizar por concentración de carga: atacar primero el 90 % del tiempo de cómputo da impacto inmediato.
- Desacoplar la lógica del motor propietario reduce la dependencia y habilita escalabilidad real.
- La compatibilidad dual durante la transición equivale a cero interrupciones en los cierres mensuales.
- Avanzar la seguridad por fases de bajo impacto (MFA en roles de administración primero) mejora la postura sin fricción para los usuarios.
Marco regulatorio
Los cálculos actuariales alimentan reportes al supervisor con plazos fijos. La modernización se diseñó para reforzar el cumplimiento, no para ponerlo en riesgo.
- Solvencia II: exigencias de cálculo de reservas y de reporte al supervisor, con reportes entregados a tiempo y sin riesgo de sanciones.
- DORA (Art. 28): resiliencia operativa y gestión de terceros tecnológicos en la nueva arquitectura.
- Sistema documentado y fácil de mantener: reducción de la deuda tecnológica como evidencia de control interno.
Preguntas frecuentes
¿Cómo se garantizó que los resultados actuariales seguían siendo correctos tras la refactorización?
Validando la precisión de los cálculos en cada iteración y con validación funcional continua antes de cada subida. Ningún cambio llegó a producción sin comparar sus resultados con los del proceso original.
¿Hubo que detener los cierres mensuales?
No. Las subidas se hicieron por etapas, con compatibilidad dual Oracle/SQL Server durante la transición, de forma que los ciclos de cierre nunca se vieron afectados.
¿Por qué concentrarse solo en cuatro procesos?
Porque pólizas, asegurador, capital y reserva acumulaban más del 90 % del tiempo de cómputo. Atacarlos primero produjo el 98,62 % de mejora en el proceso optimizado y redujo la primera iteración crítica de 1.080 a 370 minutos.
¿Puedo conocer la aseguradora y las cifras completas?
El caso está anonimizado por acuerdo de confidencialidad. El detalle de arquitectura y las cifras completas se comparten previa firma de NDA.
Contenido relacionado
Última actualización: 2026-09-12