Otimização de processos atuariais e HPC
Uma grande seguradora europeia com processos atuariais críticos enfrentava tempos de computação insustentáveis e uma infraestrutura HPC estática incapaz de se adaptar à procura.
Desafio
Infraestrutura HPC estática e código legado sem documentação. Os ciclos de fechamento mensal consumiam dias de computação, com gargalos nos processos atuariais mais críticos.
Solução
Diagnóstico detalhado do ambiente atuarial, otimização HPC progressiva por fases e refatoração modular do código. Implantação sem interromper os ciclos de negócio críticos.
Tecnologias
- HPC / Grid Computing
- Otimização de código atuarial
- Infraestrutura híbrida
- Monitoramento de desempenho
Contexto
Uma grande seguradora europeia operava os seus processos atuariais e de seguros de grupo sobre um stack Oracle herdado (Oracle 10g, Oracle Forms, PL/SQL, Pro*C). Os cálculos-chave exigiam até 36 horas, a lógica de negócio estava embebida em código sem documentação e, sem a equipa original, cada intervenção saía mais cara. A isso somava-se um ROI prolongado: investimentos que demoravam até três anos a recuperar.
O objetivo acordado foi triplo: acelerar e simplificar os processos atuariais e de seguros de grupo, modernizar o sistema sem interromper a operação diária, e garantir exatidão e conformidade regulatória com maior eficiência. Tudo isto com reportes exatos no fecho do mês como restrição inegociável.
O desafio
Os processos atuariais e de seguros de grupo estavam travados por uma infraestrutura desatualizada. As operações, essenciais para a avaliação de riscos e a conformidade regulatória, sofriam gargalos que afetavam tanto a eficiência como a fiabilidade dos resultados:
- Processos obsoletos: código antigo e tecnologia desatualizada.
- Tempos de processamento elevados: até 36 horas para calcular os seguros de grupo e os cálculos atuariais.
- Conformidade regulatória: requisitos estritos que exigiam reportes precisos no fecho do mês.
- Dívida tecnológica: sem a equipa original, manter o sistema era cada vez mais complicado.
- Impacto financeiro: um ROI prolongado, com investimentos que demoravam até três anos a recuperar.
Abordagem por fases
A intervenção foi estruturada em fases, o que facilitou uma implementação ordenada, controlada e alinhada com os ciclos operacionais da seguradora. Três princípios orientaram-na: estabilidade operacional (atuar sobre os sistemas sem alterar a sua disponibilidade), abordagem gradual (priorizar os processos atuariais e de seguros de grupo mais críticos) e visão técnica e de negócio (conhecimento técnico profundo com compreensão do ambiente regulatório e de riscos).
-
01
Fase de estudo
Análise do código, revisão dos processos atuariais e de seguros de grupo e levantamento da informação de negócio.
-
02
Identificação de problemas
Gargalos em quatro funções principais, código histórico sem documentação e processos lentos e inflexíveis.
-
03
Desenho da solução
Planeamento por fases, reestruturação modular e priorização das tarefas críticas.
-
04
Implementação e validação
Passagens a produção por etapas sem interromper as operações e validação funcional contínua.
-
05
Fecho
Resultados validados, ambiente otimizado e redução drástica do tempo de processamento.
Arquitetura e estratégia
A estratégia assentou em quatro pilares. Diagnóstico detalhado do ambiente atuarial e de seguros de grupo: fez-se o levantamento da infraestrutura existente, da lógica de negócio, do código e dos processos mais críticos, identificando gargalos, duplicações e procedimentos sem documentar. Refatorização modular do código: trabalhou-se sobre os procedimentos mais exigentes, reescrevendo funções, eliminando redundâncias e reorganizando a lógica; a refatorização concentrou-se nos quatro processos (apólices, segurador, capital e reserva) que acumulavam mais de 90 % do tempo de computação.
Otimização da infraestrutura HPC: ajuste dos recursos consoante a carga real e validação da exatidão dos cálculos em cada iteração. Melhoria progressiva por fases: passagens a produção por etapas com validações intermédias, garantindo a continuidade operacional sem afetar os ciclos de fecho mensal. Em paralelo, a arquitetura foi desacoplada em microsserviços (frontend ReactJS, backend API .NET, motor de cálculo atuarial e microsserviços de base de dados), com cache Redis e compatibilidade dual Oracle/SQL Server durante a transição, até eliminar por completo a dependência da Oracle a favor de .NET, Python, SQL Server e Azure SQL.
Resultados mensuráveis
Durante a fase inicial detetou-se que processos consumiam mais tempo, o que permitiu centrar a primeira iteração exclusivamente nos mais críticos e obter um impacto imediato no desempenho.
| Indicador | Antes | Depois |
|---|---|---|
| Aceleração dos processos atuariais | Cálculos-chave de até 36 h | +80 % (refatorização modular) |
| Melhoria no processo otimizado | Processo com maior consumo de computação | 98,62 % |
| Tempo total da 1.ª iteração crítica | 1.080 minutos | 370 minutos |
| Dependência da Oracle (PL/SQL, Pro*C, Forms) | Total | Removida (.NET / Python / SQL Server / Azure SQL) |
| Continuidade durante a migração | Risco em cada fecho mensal | Sem interrupções (passagens a produção por etapas com validação) |
| Pontuação de segurança M365 (reforço dos acessos) | 11,48 % | +30 % sobre a base, com MFA nos perfis críticos |
Números agregados e anonimizados por acordo de confidencialidade. Fonte: projetos da Vermont Solutions.
Lições aplicáveis
- Priorizar por concentração de carga: atacar primeiro os 90 % do tempo de computação dá impacto imediato.
- Desacoplar a lógica do motor proprietário reduz a dependência e permite uma escalabilidade real.
- A compatibilidade dual durante a transição equivale a zero interrupções nos fechos mensais.
- Avançar a segurança por fases de baixo impacto (MFA nos perfis de administração primeiro) melhora a postura sem fricção para os utilizadores.
Enquadramento regulatório
Os cálculos atuariais alimentam reportes ao supervisor com prazos fixos. A modernização foi desenhada para reforçar a conformidade, não para a pôr em risco.
- Solvência II: exigências de cálculo de reservas e de reporte ao supervisor, com reportes entregues a tempo e sem risco de sanções.
- DORA (art. 28.º): resiliência operacional e gestão de prestadores terceiros TIC na nova arquitetura.
- Sistema documentado e fácil de manter: redução da dívida tecnológica como evidência de controlo interno.
Perguntas frequentes
Como se garantiu que os resultados atuariais continuavam corretos após a refatorização?
Validando a exatidão dos cálculos em cada iteração e com validação funcional contínua antes de cada passagem a produção. Nenhuma alteração chegou a produção sem comparar os seus resultados com os do processo original.
Foi necessário parar os fechos mensais?
Não. As passagens a produção foram feitas por etapas, com compatibilidade dual Oracle/SQL Server durante a transição, de forma que os ciclos de fecho nunca foram afetados.
Porquê concentrar-se apenas em quatro processos?
Porque apólices, segurador, capital e reserva acumulavam mais de 90 % do tempo de computação. Atacá-los primeiro produziu os 98,62 % de melhoria no processo otimizado e reduziu a primeira iteração crítica de 1.080 para 370 minutos.
Posso conhecer a seguradora e os números completos?
O caso está anonimizado por acordo de confidencialidade. O detalhe da arquitetura e os números completos são partilhados após assinatura de um NDA.
Conteúdo relacionado
Última atualização: 2026-09-12