KPIs que o financeiro cobra e a operação ignora

Dentro de muitas empresas, existe um conflito silencioso que ninguém gosta de assumir: o financeiro cobra números, enquanto a operação toca o dia a dia como se esses indicadores fossem um problema “do outro departamento”. Esse desalinhamento não aparece em uma reunião específica, nem vira um conflito explícito. Ele se manifesta nos resultados. O sintoma é conhecido: faturamento cresce, margem aperta, caixa sofre e a sensação recorrente é de que a empresa trabalha muito para avançar pouco. Quando o financeiro começa a questionar os números, a operação reage com justificativas. Quando a operação pede mais liberdade, o financeiro responde com restrições. No fim, ninguém ganha. O problema não está nos KPIs em si. Está no fato de que eles são tratados como ferramentas de cobrança, e não como instrumentos de gestão compartilhada. O erro clássico: KPI visto como “controle do financeiro” Em empresas com baixa maturidade, os indicadores financeiros são vistos como algo punitivo. O financeiro cobra, a operação se defende. O KPI vira sinônimo de pressão, não de orientação. Já em empresas mais maduras, o KPI é entendido como um termômetro operacional. Ele mostra onde a operação está eficiente, onde está vazando dinheiro e onde decisões precisam ser ajustadas antes que o problema vire estrutural. Quando a operação ignora os KPIs, ela não está sendo “mais prática”. Está apenas operando às cegas. Margem de contribuição: o número mais ignorado da operação O financeiro acompanha de perto a margem de contribuição por produto, serviço ou contrato. A operação, na maioria das vezes, olha apenas para volume. Vender mais parece sempre uma boa notícia. O problema é quando ninguém avalia o que está sendo vendido. Produtos de baixa margem, contratos mal precificados e descontos concedidos para “fechar negócio” corroem o resultado silenciosamente. A operação celebra metas batidas. O financeiro fecha o mês com margem menor. Esse desencontro cria a falsa impressão de que o problema está nos custos fixos, quando na verdade está nas decisões comerciais e operacionais do dia a dia. Custo operacional: o invisível que destrói resultado Outro KPI que o financeiro acompanha com lupa é o custo operacional por pedido, por venda ou por serviço entregue. A operação, por sua vez, costuma normalizar ineficiências. Retrabalho, erros de lançamento, correções manuais, processos paralelos e dependência excessiva de pessoas específicas viram parte da rotina. O problema é que cada “pequeno ajuste” soma tempo, horas e dinheiro. Quando o financeiro aponta o aumento de custos, a resposta padrão é: “o volume aumentou”. Só que o custo não cresceu proporcionalmente ao volume. Cresceu por ineficiência. Sem esse KPI integrado à operação, o crescimento deixa de ser saudável e passa a ser apenas mais cansativo. Prazo médio de recebimento: venda boa que quebra caixa Para o financeiro, prazo médio de recebimento é questão de sobrevivência. Para a operação comercial, muitas vezes, é detalhe negociável. Condições fora do padrão, exceções recorrentes, promessas feitas sem validação financeira e liberações sem critério criam um descompasso perigoso. No papel, a empresa vende bem. No caixa, falta dinheiro. Esse é um dos erros mais comuns em empresas em crescimento: confundir faturamento com liquidez. Quando a operação ignora o impacto do prazo de recebimento, ela transfere o problema diretamente para o financeiro — que precisa lidar com capital de giro, crédito e pressão bancária. Inadimplência: quando o “cliente estratégico” vira risco O financeiro acompanha inadimplência como um indicador de risco. A operação, muitas vezes, relativiza. Frases como “esse cliente sempre paga”, “é um parceiro antigo” ou “depois a gente cobra” são comuns. O problema é que inadimplência recorrente não é exceção. É padrão mal gerenciado. Cada cliente inadimplente consome caixa, energia e tempo. Quando a operação ignora esse KPI, ela está, na prática, financiando o cliente com dinheiro da empresa — sem juros e sem garantia. Giro de estoque: dinheiro parado não aparece no relatório de vendas Estoque é outro ponto clássico de atrito. O financeiro vê estoque como capital imobilizado. A operação vê como segurança. Compras acima da necessidade, falta de análise por curva ABC e decisões baseadas em “feeling” criam estoques inchados. O problema não aparece imediatamente. Ele surge no caixa, nos custos de armazenagem e na necessidade de descontos para girar mercadoria parada. Quando o giro de estoque não é acompanhado pela operação, a empresa perde eficiência sem perceber. E o financeiro fica com a ingrata missão de explicar por que falta dinheiro mesmo com vendas constantes. Retrabalho: o KPI que ninguém quer medir Poucas operações gostam de medir retrabalho. Afinal, isso expõe falhas de processo, não esforço. O financeiro, porém, vê retrabalho como custo direto. Cada correção de pedido, reemissão fiscal ou ajuste manual consome horas que poderiam estar gerando valor. Empresas que ignoram esse KPI vivem a ilusão da produtividade. A equipe está ocupada o tempo todo, mas não é eficiente. O financeiro sente no custo. A operação sente no cansaço. Acuracidade da informação: a base de tudo Talvez o KPI mais subestimado seja a acuracidade dos dados. O financeiro depende de informações confiáveis para fechar mês, projetar fluxo de caixa e tomar decisões. A operação, muitas vezes, aceita dados incompletos ou lançamentos feitos “depois”. Quando os dados não são confiáveis, o KPI perde valor. Relatórios passam a ser questionados e decisões voltam a ser tomadas no improviso. A empresa deixa de ser orientada por dados e passa a ser guiada por percepção. O problema não é cultural. É estrutural. É tentador dizer que o conflito entre financeiro e operação é cultural. Na prática, ele é estrutural. Sem processos integrados e sem uma base única de dados, cada área trabalha com sua própria versão da realidade. O financeiro vira o guardião dos números. A operação vira a executora sem visibilidade de impacto. Esse modelo funciona enquanto a empresa é pequena. Quando cresce, ele quebra. Onde a gestão moderna entra Empresas com maturidade operacional entendem que KPI não é relatório de fim de mês. É ferramenta de gestão diária. Um sistema de gestão integrado elimina o jogo de empurra. Quando operação e financeiro enxergam..

Compartilhar:

Sistemas Legados: Viver com Eles Sem Enlouquecer

A Maturidade Final Entre Reescrever e Resignação Introdução: O Dilema Real Todo senior em tecnologia chega a um ponto na carreira em que enfrenta um sistema legado que funciona, mas incomoda. É o sistema que paga as contas, que processa transações críticas, que segura clientes importantes—e que, simultaneamente, paralisa a velocidade de inovação. Ele não está quebrado. Exatamente aí mora o problema: não está quebrado o suficiente para justificar um rewrite de 2-3 anos, mas está estável o suficiente para que a organização continue negligenciando-o. A decisão que enfrenta não é técnica, é estratégica. E ela define a maturidade final de um CTO, arquiteto ou engenheiro sênior: saber quando reescrever é erro catastrófico, e como evoluir sem parar o negócio. Este artigo coloca duas mentiras lado a lado e as queima. A primeira: “Devemos reescrever tudo do zero.” A segunda: “Devemos apenas refatorar incrementalmente para sempre.” A realidade que separa amadores de especialistas está nos degraus entre essas extremidades. Parte 1: Quando Reescrever é um Erro Catastrófico O Fantasma da Taxa de Falha Não existe consenso acadêmico sobre qual é exatamente a taxa de fracasso de rewrites completos. Mas existem evidências suficientes. McKinsey relata que 70% dos programas de transformação em larga escala não alcançam seus objetivos. A Thoughtworks e a comunidade de engenheiros documentam um padrão recorrente: rewrites sobreestimam o que conseguem fazer e subestimam o que perdem. Por que isso acontece? Porque um rewrite completo confunde “começar do zero” com “resolver o problema”. Na verdade, o que está acontecendo é muito mais sinistro: Você não está reconstruindo o sistema. Você está reconstruindo o conhecimento. Um sistema legado de 10-20 anos não é apenas código. É um repositório de decisões de negócio: casos extremos tratados em patches, integrações quirky que ninguém lembra por quê, dados limpos lentamente em triggers noturnos. Tudo isso é conhecimento tácito. Quando você reescreve, você tira esse conhecimento da base de código e o coloca na cabeça de engenheiros novos—ou, piores, em whiteboards onde ele é esquecido. Um engenheiro experiente que trabalhou em sistemas legados grandes conhece a história verdadeira. O rewrite não falha porque os engenheiros são incompetentes. Falha porque: O resultado é previsível: dois em cada três projetos assim não terminam, ou terminam com tempo e orçamento 2-3x maiores que planejado, com sêniors cassados, e equipes queimadas. O Caso Que Ninguém Quer Contar Há uma razão pela qual você vê mais artigos sobre “como fazer um rewrite direito” do que “aqui está a mensagem de erro que você vê quando um rewrite inteiro falha e precisa ser cancelado.” Os que falham não escrevem cases—eles silenciosamente desaparecem, e os líderes nunca falam sobre eles em conferências. Mas há sinais. Reddit tem threads de engenheiros experientes dizendo coisas como: “Big Bang rewrites têm uma taxa de fracasso tão alta que é provável você ver a equipe antiga ser demitida depois de 2-3 anos de não-entrega que a equipe nova conseguir sucesso.” Isso é raiva documentada, não especulação. Parte 2: O Custo Real de Não Fazer Nada Agora, antes que você conclua “então simplesmente deixamos o sistema legado em paz,” entenda o outro lado do dilema. Um sistema legado que apenas mantém o status quo é um dreno financeiro. Os custos são menos óbvios que um rewrite falhando, mas são muito mais devastadores ao longo do tempo. Dinheiro Que Você Não Vê Deixando Uma manufatura típica, por exemplo, paga até $260.000 por hora em custos de downtime não planejado. Se o seu sistema legado falha uma vez a cada trimestre por 2 horas (porque ninguém quer mexer nele, então acumula dívida técnica), você está perdendo $1 milhão por ano apenas em downtime—sem contar recuperação, perda de produtividade, ou reputação. Serviços financeiros? Até $9.000 por minuto. Se você tem um sistema crítico de processamento de reclamações que falha sem aviso porque ninguém teve coragem de refatorar aquela seção acoplada do código, uma falha de 1 hora custa $540.000. Várias dessas ao ano, e você está falando de múltiplos milhões. Mas os custos mais insidiosos são invisíveis: Um estudo da Flexera mostra que custos de manutenção para sistemas legados crescem ano a ano, enquanto capacidade produtiva cai. Isso é uma curva de morte. Em algum momento, custa mais manter a coisa do que reconstruir. A Bomba de Conhecimento O sistema legado também tem outro inimigo invisível: pessoas. O engenheiro que escreveu 60% da lógica aposentou. O outro está aceitando uma oferta melhor e sai. Você fica com um sistema que ninguém entende completamente, que ninguém quer mexer, e uma mudança simples vira arqueologia. Quando o conhecimento tácito sai, o risco explode. Mudanças pequenas introduzem bugs inesperados. Ninguém tem confiança para refatorar. Você entra em espiral KTLO (Keep The Lights On): apenas manutenção reativa, nunca estratégica. Parte 3: Quando Reescrever Faz Sentido (Muito Raramente) Agora, a honestidade: há casos em que um rewrite é a decisão certa. Apenas muito mais raros que as pessoas pensam. Um rewrite completo faz sentido quando: Fora desses cenários específicos—que afetam talvez 10-15% dos sistemas legados em produção—um rewrite é uma aposta, não uma estratégia. Mesmo nesses casos, ainda há alternativas. Mas essa é a transição para a parte que importa: como você realmente moderniza sem o risco catastrófico do rewrite, e sem a resignação confortável de nunca mudar. Parte 4: O Padrão Strangler Fig—A Maturidade Final Existe um padrão que chegou perto de resolver esse dilema. Não é perfeito. Mas é tão mais próximo de realista que torna outras abordagens parecerem práticas de cargo culto. Chama-se Strangler Fig Pattern. O nome vem da biologia: uma figueira estranguladora cresce lentamente ao redor de uma árvore hospedeira. Ela não mata a árvore de uma vez. Envolve-a gradualmente, intercepta a luz e a água, até que eventualmente a árvore hospedeira morre de inanição—mas a figueira nunca precisa de um “big bang” para vencer. A transição é invisível. Em sistemas de software, o padrão funciona assim: O Conceito Básico Ao fim de 3-5 anos, o “novo sistema” é na verdade um bando de microsserviços lean que substituíram gradualmente cada função do monolith..

Compartilhar: