Modernizar o core: o caso para o comitê, não o guia técnico

Imagine um comitê que autoriza o início da substituição do sistema central da instituição durante um fim de semana. Há mais de quatro anos de planejamento por trás, ensaios, um piloto interno e as garantias dos fornecedores. No papel, a preparação parece completa.

Foi, em essência, o que ocorreu em um banco britânico: o conselho do TSB e o subcomitê do conselho autorizaram, entre 18 e 19 de abril de 2018, o início da migração, executada no fim de semana de 20 a 22. Quase de imediato surgiram falhas sérias, e a segunda-feira seguinte mostrou que preparação e garantia suficiente não são a mesma coisa.

Por «core» entendemos aqui o sistema de registro do qual dependem operações críticas: clientes, contas, apólices, pedidos, estoque, cobranças, conciliações ou relatórios, conforme o setor, e com ele os demais sistemas (canais, pagamentos, contabilidade). Este artigo não é um guia técnico. É o caso para quem tem de decidir: o que um comitê pode aprender com o caso público do TSB quando a migração de dados e funções críticas se concentra em um único evento, que alternativa existe e como apresentá-la a um comitê que pergunta por risco, por custo e por datas. Foi escrito para quem responde pela operação, pelo orçamento ou pelo risco em um banco, uma fintech, uma seguradora, uma rede de varejo ou uma empresa regulada.

O que o TSB e a PRA publicaram sobre o caso

O TSB, um banco britânico, executou a migração principal para uma plataforma nova em abril de 2018. O próprio banco descreveu o programa como a mudança mais complexa que já havia empreendido e «uma das mais complexas da história da banca britânica», com mais de quatro anos de planejamento [2]. Segundo o banco, o conselho autorizou o evento principal de migração com base em «um volume significativo de evidência objetiva»: atestações da direção, garantias escritas e orais de fornecedores, nove ensaios gerais e eventos de transição bem-sucedidos e um piloto com mais de 1.600 funcionários [2]. A migração tampouco foi um único evento do início ao fim: segundo o TSB, foi feita por etapas (caixas eletrônicos, pagamentos com cartão, hipotecas e o app móvel, entre outras), e o que ocorreu de uma vez foi o evento principal de migração dos dados dos clientes [2].

Ou seja, não foi improviso. Houve planejamento, ensaios e garantia de qualidade. Ainda assim, segundo o regulador prudencial britânico (PRA) [1] (o próprio TSB discorda de alguns aspectos da revisão independente [2][5]):

• Todas as agências do TSB e uma proporção significativa dos 5,2 milhões de clientes foram afetadas pelos problemas iniciais.
• O TSB levou até dezembro de 2018 para voltar à operação normal.
• O banco pagou 32,7 milhões de libras em compensações [1] a clientes que sofreram prejuízo.
• Em dezembro de 2022, a PRA e a FCA impuseram conjuntamente ao TSB uma multa de 48,65 milhões de libras [4].
• Em abril de 2023, a PRA multou em 81.620 libras [1] o diretor de informática da época, por não ter assegurado que o banco supervisionasse de forma adequada a terceirização do programa de migração de 2018. Entre outras coisas, segundo o regulador, ele não reavaliou suficientemente as capacidades do terceiro nem obteve a garantia necessária sobre a prontidão da plataforma antes de dar garantias ao conselho.

Há duas lições para um comitê, e nenhuma é técnica.

A primeira: a preparação declarada não substitui a garantia suficiente. O conselho tinha muita documentação. O que o regulador questionou foi a solidez da garantia por trás dela: segundo a PRA, o responsável não tomou medidas razoáveis para que o banco obtivesse garantia suficiente do terceiro sobre a prontidão dele, nem considerou o bastante se era preciso investigar mais antes de dar garantias ao conselho [1]. Um «tudo verde» em uma apresentação não é o mesmo que essa garantia.

A segunda: a responsabilidade pode chegar às pessoas, não apenas às empresas. A multa ao diretor de informática decorre do regime britânico de responsabilidade individual de executivos; no México o marco aplicável é outro, e cada instituição deve verificá-lo. O caso mostra que, sob o regime britânico aplicável, a supervisão de um terceiro pode levar à responsabilização individual além das sanções à instituição; não permite transferir automaticamente essa consequência ao marco mexicano.

O que este artigo não faz também importa. O comitê de uma instituição mexicana poderia perguntar se aqui acontece o mesmo, mas aqui não se comparam sanções nem incidentes mexicanos. Para uma decisão concreta, a instituição deve identificar o marco setorial que lhe cabe e validá-lo com as áreas jurídica, de compliance e de riscos.

Por que o corte único concentra o risco

Martin Fowler, autor e referência em arquitetura de software, diz sem rodeios sobre a substituição de sistemas legados: «vimos esse plano de aparência simples naufragar na maioria das vezes» (tradução própria) [3]. O motivo que ele dá é de negócio, não técnico: substituir um sistema sério leva muito tempo, e enquanto isso os usuários não podem esperar novas funcionalidades [3].

Traduzido para a linguagem do comitê, um corte único reúne em um só momento três coisas que convém separar:

1. O valor tende a chegar no final. Durante anos investe-se e o negócio não recebe nada que possa medir. Se o projeto atrasa, não há nada parcial a mostrar.
2. O risco se concentra em um só dia. Os clientes, as agências, os canais digitais, os pagamentos e as conciliações mudam ao mesmo tempo. Se algo falha, pode falhar tudo junto.
3. A volta atrás costuma ser difícil ou inexistente. Quando os dados já migraram e as operações da segunda-feira foram gravadas no sistema novo, voltar ao anterior deixa de ser um botão e vira outro projeto.

Ver esses três pontos em uma folha ajuda o comitê a mudar a conversa. A pergunta deixa de ser «quando terminamos?» e passa a ser «o que acontece se algo der errado no dia do corte e quanto do negócio está exposto?».

A alternativa: por etapas, com volta atrás

Fowler deu um nome à alternativa, tirado de uma planta que cresce ao redor de uma árvore até substituí-la: a figueira-estranguladora (strangler fig). A ideia é simples de explicar a um comitê: em vez de desligar o sistema velho e ligar o novo, constrói-se ao redor do velho, peça por peça, e transfere-se uma função de cada vez. Enquanto uma função é transferida, o sistema anterior pode continuar atendendo as que ainda não foram transferidas, conforme o desenho dos dados, da operação e dos controles. Fowler, citando Ian Cartwright, Rob Horn e James Lewis, menciona quatro atividades (a ordem em que são listadas não implica uma sequência): entender os resultados que se quer alcançar, decidir como dividir o problema em partes menores, entregar essas partes com êxito e mudar a organização para que isso possa ocorrer de forma contínua [3].

E ele é honesto sobre o custo: construir essa camada transitória pode parecer um desperdício, mas «o menor risco e o valor mais precoce da abordagem gradual superam o custo dela» [3]. Essa afirmação é o critério dele, não uma medição universal; por isso convém que o comitê a coloque à prova com os próprios números, como se explica mais adiante.

A diferença prática em relação ao corte único se vê em uma comparação:

A última linha importa. O caminho por etapas não é gratuito, e quem o apresentar assim perde credibilidade diante de um CFO.

A volta atrás também não acontece sozinha. Que uma etapa possa ser revertida é uma propriedade que se desenha: qual função é transferida, quanto tráfego recebe, qual sinal indica que é preciso voltar e quem tem a autoridade para decidir. Existem etapas irreversíveis legítimas, mas elas mantêm uma exposição concentrada dentro do escopo delas e devem ser justificadas explicitamente ao comitê: o que as torna irreversíveis, como o dano é limitado e que controles compensam a falta de reversão.

Como se apresenta ao comitê

Para esta decisão, o comitê pode priorizar três coisas, nesta ordem, acima do detalhe técnico.

1. O risco, com a volta atrás

A pergunta que convém responder em uma página: qual é o pior que pode acontecer em cada etapa e como voltamos? Para cada etapa, três dados: que parte do negócio ela toca, qual indicador avisa que algo vai mal e quanto tempo leva para voltar ao estado anterior.

Cenário (ilustrativo, sem cliente). Uma seguradora com uma apólice de despesas médicas administrada em um sistema central de duas décadas atrás decide começar pelas cotações e não pelas apólices emitidas. A primeira etapa transfere o cálculo da cotação para uma peça nova, enquanto o sistema central segue emitindo. Se a cotação nova der resultados diferentes dos do sistema atual em um percentual que o comitê fixou de antemão, o tráfego volta ao cálculo anterior. O que fica exposto é uma função, não a operação completa.

2. O custo de não fazer nada

É a parte que com frequência se omite e que pode pesar mais. Um comitê que só vê o custo da modernização compara um número contra zero, e o zero costuma ganhar. Mas manter o sistema atual também custa, e convém fazer essa conta com dados próprios, não com cifras de terceiros. Não usamos aqui percentuais genéricos de mercado sobre a parcela do orçamento que vai para sistemas legados ou sobre o fracasso de substituições, porque não são necessários para decidir este caso. A conta do comitê deve sair da contabilidade da própria instituição, dos incidentes e dos prazos de mudança dela:

• quanto se gasta por ano para manter, remendar e operar o sistema atual;
• quanto tempo leva hoje para lançar um produto, uma tarifa ou uma mudança regulatória, e qual receita é adiada enquanto isso;
• quantas pessoas concentram o conhecimento do sistema e o que acontece se uma delas sair;
• quais incidentes ou fechamentos manuais são atribuídos hoje a limitações do sistema central.

Se o comitê não tiver essas cifras, esse é em si o primeiro achado e o primeiro entregável.

3. Marcos mensuráveis, não percentual de avanço

«Estamos em 60 %» é uma frase que um programa de substituição pode dizer até o dia em que falha. Os marcos de uma modernização por etapas podem ser medidos no negócio e não no projeto:

• que parte do tráfego ou das operações já roda pela peça nova;
• quanto tempo leva agora para sair uma mudança de tarifa, de produto ou de regra, em comparação com o que levava no início;
• quantas vezes a volta atrás foi exercitada e testada, e com qual resultado;
• quanto custa manter a camada de convivência e em que data se planeja retirá-la.

Este último ponto evita um risco conhecido das abordagens por etapas: que a camada transitória se torne permanente. Retirá-la deve estar no plano desde o primeiro dia, com data e responsável.

A parte regulatória não se deixa para o final

Se uma das etapas implica mover funções para a nuvem ou para um terceiro, os requisitos do regulador fazem parte do calendário, não são um trâmite posterior. No México, a resposta depende da entidade e do terceiro: as instituições de crédito, as instituições de fundos de pagamento eletrônico (IFPE), as seguradoras e as afiançadoras têm, cada uma, regras próprias sobre a contratação e a supervisão de terceiros, que podem prever aviso prévio ou autorização conforme o serviço e o local em que é prestado. Antes de autorizar uma etapa, as áreas jurídica e de compliance devem confirmar a obrigação, a autoridade, o processo e o prazo aplicáveis. Três perguntas concretas para levar a elas: esta etapa exige aviso ou autorização prévia perante a CNBV (comissão reguladora bancária e de valores do México) ou a CNSF (comissão supervisora de seguros e fianças do México)? Com quanta antecedência? Que evidência de garantia do terceiro o regulador espera ver documentada? A obrigação, a autoridade competente e o prazo dependem da entidade, da função, dos dados, da localização do serviço e do terceiro contratado. O caso do TSB ilustra que o regulador britânico não perguntou apenas se o sistema funcionava: perguntou quem garantiu, perante quem e com qual evidência [1].

Por isso convém que cada etapa, ao ser apresentada ao comitê, traga anexada uma página deste tipo: o que se move, quem é notificado, qual evidência de testes existe e quem responde.

Cinco perguntas para o próximo comitê

1. Quanto do nosso negócio ficaria exposto no pior dia da primeira etapa, e quanto tempo levaríamos para voltar ao estado anterior?
2. Temos quantificado o custo anual de não modernizar, com dados da nossa contabilidade e não de uma apresentação de fornecedor?
3. Que evidência independente de testes de carga e de dados temos hoje, e quem, diferente de quem constrói, a revisou?
4. Que marco do negócio, não do projeto, vamos ver nos primeiros seis meses? Por exemplo, uma função rodando pela peça nova com tráfego real.
5. Que órgão, função e pessoa responsável o marco aplicável indica para supervisionar o terceiro, e que evidência deve ser conservada?

Se várias respostas forem «não sei», provavelmente não falta um fornecedor: faltam informações para decidir.

Por onde começar esta semana

Antes de autorizar um programa maior, é possível começar por uma folha com uma única coluna de funções do sistema central (cadastro de cliente, cotação, emissão, cobrança, conciliação, relatórios regulatórios) e, ao lado de cada uma, três marcas: quanto muda por ano, quantos outros sistemas dependem dela e o que aconteceria se ela parasse por meio dia. O comitê pode avaliar cada função com cinco critérios: valor de negócio verificável, dependência de outros sistemas, reversibilidade, representatividade dos dados e da carga, e condição regulatória. A primeira etapa será a de melhor equilíbrio para o contexto, não necessariamente a mais fácil; uma função que não faz falta nenhuma se pausada pode render um piloto sem relevância. Com esse critério, o comitê tem uma ordem para defender.

O que a Hábil faz

A Hábil acompanha organizações que precisam decidir como modernizar sistemas centrais sem perder de vista continuidade, controle e rastreabilidade. Essa é a ideia da página Modernizar o core sem frear o negócio; para unir os sistemas e canais, a página Unificar a operação e os canais.

A primeira conversa de diagnóstico é sem custo e serve para delimitar o sistema, a decisão pendente e as informações de que o comitê precisaria para avaliá-la. Escreva para nós pelo WhatsApp.