Em abril de 2018, o TSB Bank tentou migrar 1,3 bilhão de registros de clientes de uma plataforma de processamento legado para um novo sistema construído por sua empresa-mãe espanhola. A migração não foi responsável por interdependências não documentadas entre estruturas de dados. Dentro de horas, 1.9 milhões de clientes foram bloqueados fora de suas contas. Alguns viram os saldos de outros clientes. Os casos de fraude aumentaram. A interrupção durou semanas.
O custo total: £330 milhões em reparação, compensação e receita perdida (O Independente). O CEO Paul Pester renunciou sob pressão (Notícias da BBC). O Comité do Tesouro do Reino Unido lançou um inquérito parlamentar. A Autoridade de Conduta Financeira cobrou 48,65 milhões de libras em coimas (Reuters). 80 mil clientes deixaram o banco.
O conselho da TSB não entendeu completamente o risco até que se tornou um título. Esse é o cenário que este guia ajuda a prevenir. Seu conselho não precisa entender como funciona a infraestrutura de transação legada. Eles precisam entender o que acontece quando falha, o que custa não fazer nada, e como é um investimento estruturado. Este artigo dá-lhe o idioma, os dados, e um modelo de apresentação pronto para usar para fazer esse caso.
Sobre o que o Conselho realmente se importa
Os quadros não pensam em linguagens de programação. Eles pensam em três categorias: responsabilidade, resiliência e agilidade. Todos os argumentos que faz precisam de aterrar num desses baldes.
Responsabilidade e exposição regulamentar
Os órgãos reguladores tratam cada vez mais as falhas do sistema como falhas de governança. A multa de £48,65 milhões do TSB veio não por causa de um bug de software, mas porque o FCA descobriu que o banco "falhou em planejar para a migração de TI corretamente" e não tinha "sistemas de gerenciamento de risco adequados" (Notícias da BBC). Nos termos de quadros como o DORA na UE e as regras de resiliência operacional da ACF no Reino Unido, os conselhos de administração são responsáveis pelo risco tecnológico. Um sistema que funciona com código que ninguém pode manter não é um problema de tecnologia. É uma responsabilidade fiduciária.
Os padrões modernos de relatórios de risco reforçam esta mudança. SegundoVComply 2025 análise das expectativas do conselho, os diretores agora esperam relatórios de risco que sejam "claros, voltados para o futuro e diretamente ligados ao impacto dos negócios". Se seus sistemas legados não aparecerem em seu registro de risco empresarial com exposição financeira quantificada, você tem uma lacuna de governança.
Resiliência operacional e risco de receita
Os principais sistemas de processamento lidam com as transações que geram receita. Quando falham, a receita pára. AGuia de avaliação do risco de CTOdocumentos que um aumento de 100 milissegundos na latência da plataforma de comércio eletrônico podem reduzir as taxas de conversão em 7%. Para sistemas que processam milhares de transações por hora, mesmo uma degradação menor acarreta um custo mensurável. Uma falha total é catastrófica.
A carga de manutenção compõe o problema. As organizações que executam infra-estruturas de transacções herdadas gastam até 80% do seu orçamento de TI para manter os sistemas existentes em funcionamento, deixando a capacidade mínima para novas capacidades (Guia de Risco Legado do CTO). Isso não é uma queixa de tecnologia. Trata-se de um problema de repartição de capital que o Conselho pode ver num balanço.
Agilidade competitiva
Cada recurso que sua equipe de engenharia não pode construir porque eles estão mantendo o código de processamento de transações de 40 anos é um recurso que seus navios concorrentes primeiro. SegundoGuia de Risco Legado do CTO, 62% das organizações continuam a operar software desatualizado, apesar dos riscos conhecidos. A principal razão para atraso? "Ainda funciona" (citado por 50% das organizações). Essa frase é a frase mais cara na TI empresarial. O sistema funciona até não funcionar, e o custo do fracasso cresce a cada trimestre da organização atrasa.
Os dados que você precisa antes de entrar
Uma apresentação do conselho sem números duros é uma conversa. Uma apresentação do conselho com números duros é uma decisão. Antes de solicitar uma reunião, reúna estes seis pontos de dados:
| Métrico | Por Que o Conselho Se Importa |
|---|---|
| Idade do sistema (anos de produção) | Estabelece a escala da responsabilidade. Sistemas federais marcados pelo GAO variam de 23 a 59 anos. |
| Última data de alteração importante | Revela quanto tempo o sistema esteve em modo somente de manutenção. Nenhuma mudança = ninguém disposto a tocá-la. |
| Pessoal que o pode manter | 71% das equipas de mainframe já estão sem pessoal. Se o seu número é um único dígitos, o tabuleiro precisa de saber. |
| Prazo de aposentação desse pessoal | O GAO descobriu que alguns especialistas que mantiveram sistemas federais críticos são "aposentados ou falecidos". Mapeia a tua própria linha do tempo. |
| Custo por incidente (últimos 3 anos) | Converte risco abstrato em uma figura de dólar que o CFO pode validar. |
| Custo estimado do tempo de inatividade por hora | Ancora a matriz de risco. Se o sistema processa $1.2M por hora, uma interrupção de 4 horas é de $4.8M. |
Se não consegues reunir os seis, começa pelo que tens. Dados incompletos apresentados honestamente são mais credíveis do que estimativas polidas. O objetivo é mudar a conversa de "acreditamos que isso é arriscado" para "aqui está o que nos custa".
O que não dizer (e o que dizer em vez)
O idioma que você usa determina se o conselho ouve um pedido de tecnologia ou um risco de negócio. Cada termo na coluna esquerda desencadeia o filtro "este é um problema de TI". A coluna direita reformula cada conceito em linguagem que se conecta à responsabilidade, receita e posição competitiva.
| Em vez de dizer... | Diga isto |
|---|---|
| "COBOL" | "Sistemas de processamento de transações core (cerca de 40 a 60 anos)" |
| Dívida técnica | "Responsabilidade operacional diferida" |
| "Cobertura do teste único" | "Detecção de falha variável" |
| "Estado compartilhado" | "Interdependências não documentadas" |
| Modernização | "Investimento em resiliência operacional" |
| "Refactoração" | "Reduzir pontos únicos de falha" |
| "Migração de legados" | "Transição controlada para infra-estrutura suportada" |
| "Congelar código" | "Sistema que não pode aceitar mudanças com segurança" |
| Fim da vida | "Operação além do suporte do vendedor sem rede de segurança" |
| Velocidade de impressão | "Velocidade de entrega do produto" |
Pratique este vocabulário antes da reunião. Um único deslize no jargão dá ao conselho permissão para categorizar seu pedido como "IT quer mais dinheiro" em vez de "o negócio tem uma responsabilidade não oculta."
A Matriz de Risco
Se a sua apresentação tem um slide que conduz uma decisão, é isso. A matriz de risco plota cada sistema central em dois eixos: probabilidade de falha (baixa a alta) e impacto empresarial se ocorrer falha (baixa a catastrófica). O resultado é uma grade de quatro quadrantes.
Como marcar probabilidade de falha. Atribua a cada sistema uma pontuação baseada em: idade da base de códigos, número de pessoas que podem mantê-la, frequência de incidentes recentes e se tem vulnerabilidades de segurança conhecidas. O GAO descobriu que 7 de 11 sistemas federais críticos têm vulnerabilidades de segurança conhecidas (FedGov hoje). Se seus sistemas compartilham essas características, a probabilidade não é teórica.
Como marcar o impacto do negócio. Use o valor de receita por hora para cada sistema. Camada sobre exposição fina regulatória, custos de notificação de violação e estimativas de danos de reputação. Um sistema que processa folha de pagamento para 50.000 funcionários tem um perfil de impacto diferente de um painel de relatórios.
O que pousa no quadrante superior direito. Sistemas com alta probabilidade de falha e impacto de negócios catastrófico requerem ação imediata. Estes são os sistemas que o conselho precisa para financiar primeiro. Tudo o resto pode ser sequenciado em fases posteriores. Este quadrante é a sua pergunta.
Apresentar este slide em cores. Vermelho para o quadrante superior direito (ação imediata), âmbar para quadrantes adjacentes (ação planejada), verde para sistemas de baixa probabilidade/baixo impacto (monitor). Os membros do conselho processam o risco visual intuitivamente.
Matriz de risco visual orienta prioridades de ação do conselho.
Lidar com Objeções
Cada conselho levanta as mesmas três objecções. Preparem-se para todos.
"Ainda funciona."
Esta é a objeção mais comum e mais perigosa. De acordo comGuia de Risco Legado do CTO, 50% das organizações atrasam a ação porque "o sistema ainda funciona". A resposta: "O sistema funciona, mas não pode ser alterado com segurança, não pode ser equipado, e não pode ser segurado contra o fracasso. Um edifício com uma fundação rachada ainda está de pé. Isso não significa que seja seguro ocupar."
Faça backup disto com os seus dados do incidente. Quantos quase desaparecidos nos últimos 24 meses? Quanto tempo levou a última interrupção não planeada para resolver? Qual foi a causa raiz, e foi corrigido? Se as respostas são desconfortáveis, são exatamente o que o conselho precisa ouvir. No contexto da crise do pessoal do lado da oferta que está por detrás deste risco, os dados relativos à mão-de-obra são inequívocos.
"É muito caro."
Esta objecção pressupõe que a alternativa às despesas é a poupança. Não é. A alternativa é gastar mais, lentamente, sem redução de risco. As organizações já consomem até 80% de seus orçamentos de TI na manutenção do legado (Guia de Risco Legado do CTO). Os sete sistemas legados críticos não fixados do governo federal dos EUA consomem $337 milhões anualmente em custos operacionais (FedScoop).
Emoldurar o investimento como uma redução do custo líquido durante 3 a 5 anos, não uma despesa adicional. Mostrar ao conselho uma comparação: custo de manutenção anual atual mais custo de incidente projetado versus o custo amortizado do investimento de resiliência mais a manutenção contínua reduzida. Os números quase sempre favorecem a ação.
"Tentamos antes e falhamos."
Esta é uma preocupação legítima. Os dados confirmam: 74% dos projectos de modernização legados são iniciados mas nunca concluídos (Guia de Risco Legado do CTO). A resposta não é dispensar a preocupação, mas explicar o que será diferente. Falhas anteriores normalmente compartilham causas comuns: tentaram substituir tudo de uma vez, faltaram patrocínio executivo, ou não definiram marcos mensuráveis.
A sua proposta dirige-se aos três. A fase 1 visa apenas os sistemas de maior risco (o quadrante superior direito). O próprio conselho fornece supervisão de governança através de revisões trimestrais. Cada marco tem um resultado mensurável. Isto não é uma repetição dos esforços do passado. É um investimento estruturado e limitado. Para uma visão técnica do que uma migração realmente implica, incluindo a abordagem incremental que reduz o risco de entrega, consulte nosso guia técnico.
O Que Pede
Não entre na sala de reuniões pedindo "orçamento para corrigir código antigo". Esse enquadramento garante a rejeição. Em vez disso, enquadrar o pedido em três partes:
- Redução de risco. "Solicitamos um investimento de $X para reduzir uma responsabilidade operacional anual atualmente estimada em $Y. Esta responsabilidade inclui custos de inatividade projetados, exposição fina regulatória, gastos crescentes de manutenção e o custo de oportunidade da capacidade de engenharia bloqueada na manutenção do legado."
- Desbloquear capacidade. "Este investimento libertará Z% da nossa capacidade de engenharia atualmente consumida pela manutenção do legado, permitindo-nos entregar [capacidades específicas de produto ou integrações] que estão atualmente bloqueadas."
- A analogia do prémio de seguro. Os quadros entendem de seguros. Você não compra seguro contra incêndio porque seu prédio está pegando fogo. Você compra porque o custo do prêmio é uma fração do custo da perda. Um investimento de resiliência operacional funciona da mesma forma. O investimento anual é uma fração da exposição que elimina. Se o conselho não operar sem seguro de propriedade, eles não devem operar sem cobertura de resiliência para os sistemas que geram sua receita.
Seja específico. "Estamos pedindo US$ 2,4 milhões em 18 meses para reduzir uma exposição de risco anual de US$ 12 milhões e desbloquear US$ 3 milhões em capacidade de desenvolvimento de produtos" é uma proposta de financiamento. "Precisamos modernizar nossos sistemas" não é.
Seu conselho não precisa entender a arquitetura. Eles precisam entender a exposição. Dê-lhes os dados, fale sua língua, e mostre-lhes um caminho que é faseado, financiado e mensurável. O risco de inação já não é teórico. A única questão é se a sua organização o aborda em sua própria linha do tempo ou na linha do tempo ditada pela próxima falha, a próxima auditoria, ou a próxima carta de aposentadoria.