No coração do core (passe a redundância)

Na era em que a adaptabilidade e a eficiência são fundamentais para o sucesso das empresas, a indústria seguradora enfrenta um desafio próprio na renovação dos seus sistemas core para se manter competitiva.
Neste contexto, e quando a opção passa por integrar uma solução externa, a modularidade é frequentemente um conceito quase “mágico” que se apresenta como uma alavanca prometedora, oferecendo a possibilidade de atualizar e melhorar componentes individuais sem necessidade de substituir sistemas completos. Neste artigo, descrevo os módulos funcionais que podem considerar-se como o “núcleo duro” ou o “coração” de um core de seguros, distinguindo-os daqueles que têm uma função mais auxiliar, e apresento de forma sucinta as estratégias a adotar no momento de decidir entre integrar uma solução completa versus atualizar apenas alguns módulos, avaliando as respetivas vantagens e desvantagens.

Existe alguma confusão no que diz respeito ao alcance funcional esperado de um sistema core para a área seguradora. Este transformou-se gradualmente num sistema que “serve para tudo”, pelo que me parece relevante não perder de vista os terrenos que devem naturalmente fazer parte do seu alcance e os que funcionam mais como satélites que se foram criando à sua volta (adicionando valor, em alguns casos). Cada um pode definir os limites onde bem entender, mas permitam-me contribuir com a minha visão.

Dentro do “núcleo duro”: Aqui reside aquilo que constitui a coluna vertebral das operações da seguradora. Assim, podemos incluir aqui o configurador de produtos e as regras de negócio, a subscrição, a gestão da carteira e a sua renovação, a gestão de sinistros e a faturação. Estes módulos são críticos para o funcionamento diário e para a viabilidade de uma seguradora a longo prazo, e a sua robustez e fiabilidade são de suma importância.

Módulos auxiliares: Movemo-nos na periferia do core, em funcionalidades que, embora não sejam essenciais para as operações centrais, têm um papel importante na melhoria da eficiência e da experiência do cliente. Estes módulos podem incluir sistemas de gestão documental, ferramentas de BI e reporte, CRM de clientes, liquidação de comissões de mediadores, resseguro, portais de clientes/mediadores e solução de BPM. É comum que em cada uma destas áreas existam fornecedores especializados com soluções de nicho.

É importante definir bem estes limites antes de iniciar um projeto de renovação de um core de seguros. É frequente encontrar, na vastíssima lista de requisitos funcionais, uma mistura confusa de casos que podem cair num ou noutro âmbito. Isto pode fazer com que se perca de vista aquilo que é verdadeiramente relevante no momento de escolher a solução mais adequada, que será aquela que melhor resolve a problemática própria daquilo a que chamámos “núcleo duro”.

Referindo-nos agora às duas estratégias no momento de escolher a solução:

• a) manter módulos do sistema legado (isto é, configurador de produtos, sinistros…) e integrar módulos de uma solução externa;
• a) adotar uma solução completa de um fornecedor.

A abordagem a) permite às seguradoras atualizar ou mudar um ou mais módulos sem afetar o resto do sistema, o que contrasta com os sistemas monolíticos tradicionais, em que qualquer alteração pode implicar uma revisão total. Aqui refiro-me mais precisamente ao perímetro que definimos anteriormente como “núcleo duro”.

A abordagem b) pressupõe adotar uma solução de um único fornecedor de forma integral, abandonando todo o sistema legado.

É interessante observar que, embora possa soar bem (e também agrada àqueles grupos que sempre existem nas seguradoras muito ciosos e apegados à “sua” funcionalidade, que construíram com carinho ao longo do tempo), a estratégia a) ignora sempre algo que geralmente leva ao fracasso deste tipo de projeto: custos de integração elevados, devido a uma maior complexidade do projeto, em grande parte dos casos. Já para não falar de como se torna difícil gerir o diálogo e a responsabilidade quando existe, não um, mas vários sistemas em funcionamento, cada um com a sua equipa.

With strategy b), it may be frightening to leave something so critical as the core system in the hands of an external vendor. Also, it may be difficult to let go of legacy modules that have been working reasonably well so far. To address the first problem, there are many solutions, including contractual ones, which offer enough guarantees. For the second, it may be necessary to objectively analyse if there is any reason to keep those parts of the legacy system, or if it is just aversion to change, fear of losing something to which we are accustomed.

Na abordagem b), pode ser assustador deixar nas mãos de um fornecedor externo algo tão crítico como o core. Pode também ser difícil desligar-se de módulos legados que funcionaram relativamente bem até ao momento. Para enfrentar o primeiro problema existem muitas soluções, incluindo contratuais, que oferecem garantias suficientes. Quanto ao segundo, muitas vezes é necessário analisar objetivamente se existe alguma razão para manter essas peças do sistema legado, ou se se trata de aversão à mudança, medo de perder algo a que estamos habituados.