Dados que não batem: como unificar métricas e criar uma fonte única de verdade na sua empresa

Toda segunda-feira de manhã, em alguma sala de reunião do Brasil, um CEO olha para dois relatórios e faz a mesma pergunta: "Por que esses números são diferentes?" O time de vendas mostra um crescimento de 12%. O time financeiro apresenta 9%. A área de marketing jura que o número certo é 11,3%. E os próximos quarenta minutos da reunião são desperdiçados não discutindo estratégia, mas tentando descobrir qual planilha está certa.

Esse cenário é mais comum do que parece. Em empresas que já atendem milhares de clientes, têm dezenas de sistemas e produzem terabytes de dados por mês, a inconsistência de métricas virou uma epidemia silenciosa. Ela não aparece no balanço, não tem linha no orçamento, mas corrói a capacidade de decisão das lideranças de forma sistemática. Ao longo de 20 anos trabalhando com empresas como BTG, B3, Bradesco e XP, vi esse problema destruir reuniões estratégicas, atrasar decisões críticas e, em alguns casos, levar companhias a apostarem em movimentos baseados em dados simplesmente errados.

A solução tem nome: fonte única de verdade. Mas chegar lá exige mais do que tecnologia. Exige governança, cultura e uma arquitetura pensada para servir ao negócio, não ao departamento de TI.

Por que os dados não batem — e por que isso é um problema de arquitetura, não de pessoas

O primeiro instinto de muitos líderes quando os números divergem é culpar alguém. O analista que "puxou errado", o sistema que "atualizou fora do horário", o time que "usou uma métrica diferente". Mas a verdade é que a inconsistência de dados raramente é falha humana isolada. Ela é sintoma de uma arquitetura que cresceu sem planejamento.

Imagine uma empresa de médio porte com um ERP para finanças, um CRM para vendas, uma plataforma de e-commerce, um sistema de logística e mais três ou quatro ferramentas de BI espalhadas pelos departamentos. Cada sistema tem sua própria definição de "cliente ativo", seu próprio critério de "receita realizada" e seu próprio ciclo de atualização. Quando alguém consolida esses dados em uma planilha — muitas vezes manualmente — as divergências são matemáticas. Não há como os números baterem porque eles nunca foram concebidos para conversar entre si.

Segundo pesquisa da Gartner, organizações perdem em média US$ 12,9 milhões por ano por causa de dados de baixa qualidade. No Brasil, onde a complexidade tributária adiciona camadas extras de conciliação contábil, esse custo tende a ser proporcionalmente maior. A unificação de dados não é um projeto de TI. É uma decisão estratégica com retorno financeiro mensurável.

O que significa, de fato, ter uma fonte única de verdade

O conceito de fonte única de verdade — ou Single Source of Truth (SSOT) — é simples na teoria: uma camada centralizada onde todas as métricas relevantes do negócio são calculadas da mesma forma, com os mesmos critérios, atualizadas com a mesma frequência e acessíveis para todos os tomadores de decisão.

Na prática, isso não significa jogar fora todos os sistemas existentes e partir do zero. Significa criar uma camada de dados que se alimenta dessas fontes diversas, padroniza as definições e serve como referência autoritativa para o negócio. Quando o time de vendas fala em "receita recorrente mensal", ele está usando a mesma definição que o time financeiro usa. Quando o CEO pede o número de clientes ativos, ele recebe o mesmo valor que o CTO veria se consultasse o dashboard de produto.

Isso parece óbvio, mas implica resolver questões que vão muito além da tecnologia:

• Quem define o que é "cliente ativo"? É quem comprou nos últimos 30 dias? Nos últimos 90? Quem tem contrato vigente mesmo sem transação recente?
• Quando a receita é reconhecida? No momento do pedido, da entrega, do pagamento ou da liquidação financeira?
• Qual é o critério de churn? Cancelamento formal, inatividade por período, queda abaixo de um ticket mínimo?

Essas perguntas precisam ser respondidas pelo negócio, não pela TI. A tecnologia executa o que as áreas decidem. Sem essa clareza conceitual, qualquer projeto de dados vai reproduzir a mesma babel de métricas em uma infraestrutura mais cara.

Governança de dados: o alicerce que ninguém quer construir

A parte mais difícil da jornada rumo à fonte única de verdade não é técnica. É a governança de dados. E é exatamente por isso que a maioria das iniciativas falha antes de entregar valor.

Governança de dados é o conjunto de políticas, processos, responsabilidades e padrões que determinam como os dados são criados, armazenados, acessados e utilizados dentro da organização. Sem isso, você pode ter o melhor data warehouse do mercado e ainda assim ter cinco times usando definições diferentes de "margem bruta".

Na prática, uma estrutura mínima de governança para empresas que levam dados a sério precisa contemplar:

• Data owners por domínio: cada área tem um responsável formal pelas definições e pela qualidade dos dados que produz
• Dicionário de dados centralizado: um catálogo vivo com a definição oficial de cada métrica relevante para o negócio
• Processo de mudança controlada: qualquer alteração em uma métrica crítica passa por aprovação formal e comunicação estruturada
• Monitoramento de qualidade: alertas automáticos quando dados chegam fora do padrão esperado, com latência maior que o acordado ou com valores estatisticamente anômalos

Em uma fintech brasileira com quem trabalhei, a ausência de data ownership foi o principal vilão. Cada squad de produto definia suas próprias métricas de engajamento, sem nenhuma coordenação com o time de dados. O resultado era um dashboard de produto com doze gráficos diferentes de "retenção" — cada um usando uma janela de tempo distinta. A solução não veio de uma nova ferramenta. Veio da criação de um comitê de métricas com representantes de produto, tecnologia e negócio, que em três meses produziu um glossário com 47 definições oficiais e eliminou mais de 60 métricas redundantes.

Arquitetura moderna para unificação de dados: do data warehouse ao data mesh

Do ponto de vista técnico, o mercado evoluiu muito nas últimas duas décadas. As abordagens para construir uma arquitetura de unificação de dados eficiente hoje vão desde soluções mais tradicionais até modelos distribuídos mais modernos.

O modelo clássico de data warehouse centralizado — um repositório único onde todos os dados da empresa são consolidados e transformados — ainda funciona bem para empresas de pequeno e médio porte ou para negócios com domínios de dados relativamente homogêneos. Ferramentas como Amazon Redshift, Google BigQuery e Snowflake tornaram essa abordagem acessível e altamente escalável.

Para empresas maiores, com múltiplas unidades de negócio, equipes de dados distribuídas e domínios bastante distintos entre si — como um conglomerado financeiro com banco, seguradora e corretora — a centralização total pode criar um gargalo perigoso. É nesse contexto que o conceito de data mesh ganhou relevância.

O data mesh propõe uma descentralização organizada: cada domínio de negócio é responsável por seus próprios dados como se fossem um produto — com qualidade garantida, documentação, SLA definido e interface padronizada para consumo por outras áreas. A fonte única de verdade, nesse modelo, não é um servidor central, mas uma camada de contratos e padrões que garante interoperabilidade entre domínios autônomos.

A escolha entre data warehouse centralizado e data mesh não deve ser ideológica. Deve ser pragmática: qual modelo resolve o seu problema real, com o seu time atual, no seu horizonte de tempo disponível?

Na maioria das empresas brasileiras com quem trabalho, o problema não é a ausência de tecnologia sofisticada. É a ausência de fundamentos: pipelines confiáveis, transformações documentadas e um modelo de dados que reflete como o negócio realmente funciona. Antes de falar em data mesh ou lakehouse, é preciso garantir que os dados básicos chegam limpos, no prazo e com significado claro.

Como colocar isso em prática: um roteiro em três fases

Projetos de dados que tentam resolver tudo de uma vez geralmente não resolvem nada. A abordagem mais eficaz que vi funcionar em empresas como B3 e Livelo foi uma jornada estruturada em fases, com entrega de valor em cada etapa.

Fase 1 — Diagnóstico e priorização (4 a 8 semanas): mapeamento das fontes de dados existentes, identificação das métricas mais críticas para decisões executivas, levantamento das inconsistências mais frequentes e mais custosas, definição dos data owners por domínio. O objetivo dessa fase não é resolver nada ainda. É entender exatamente o que está quebrado e quanto isso custa.

Fase 2 — Construção da camada de verdade para métricas prioritárias (3 a 6 meses): em vez de tentar unificar 100% dos dados da empresa de uma vez, a recomendação é focar nas 10 a 15 métricas que aparecem em toda reunião de diretoria. Construir os pipelines, as transformações e o dicionário para essas métricas primeiro. Entregar um dashboard executivo que todas as lideranças reconheçam como a referência oficial. Esse momento de adoção cultural é tão importante quanto o técnico.

Fase 3 — Expansão e maturidade (ongoing): com a base funcionando e a confiança das lideranças estabelecida, a expansão para outros domínios e métricas se torna mais simples. Nessa fase, também se implementam os mecanismos de monitoramento de qualidade, o catálogo de dados corporativo e os processos formais de governança.

Uma métrica que uso para avaliar o sucesso desse tipo de iniciativa é simples: quanto tempo a empresa levaria para responder, com confiança, a uma pergunta estratégica não planejada? Se hoje a resposta é "precisamos de dois dias para consolidar os dados", o objetivo é chegar em "temos o número agora, com contexto". Empresas que chegam lá tomam decisões mais rápidas, com menos reuniões de alinhamento e muito menos retrabalho.

O papel da liderança executiva: por que esse projeto não pode ser só da TI

Por mais que a unificação de dados seja viabilizada por tecnologia, ela fracassa quando é tratada como projeto de TI. O motivo é simples: as decisões mais importantes nesse processo são organizacionais, não técnicas.

Definir que o financeiro tem autoridade sobre a definição oficial de receita — e que o time de produto precisa adaptar seus relatórios a essa definição — é uma decisão de governança corporativa. Aprovar orçamento para um time dedicado de engenharia de dados é decisão do CFO e do CEO. Criar o hábito de consultar o dashboard centralizado em vez de pedir para o analista "puxar um dado rápido" é uma mudança cultural que só acontece se a liderança dá o exemplo.

Os projetos de dados que geraram mais impacto nas empresas que acompanhei tinham uma coisa em comum: um executivo sênior — geralmente o CTO ou o CDO — funcionava como patrocinador ativo, não apenas como aprovador de budget. Ele participava das definições de métricas, cobrava consistência nas reuniões e vetava iniciativas que criavam silos paralelos de dados.

As decisões baseadas em dados reais começam antes do dashboard. Começam quando a liderança decide que dados confiáveis são uma prioridade estratégica — e age de acordo com essa decisão.

Dados que batem criam empresas que avançam

Quando uma empresa finalmente constrói sua fonte única de verdade, algo interessante acontece nas reuniões executivas: o tempo gasto discutindo "qual número está certo" cai para perto de zero. E esse tempo vai para onde deveria ir desde o início — para discutir o que fazer com o que os dados mostram.

Em uma das implementações que acompanhei em uma empresa do setor financeiro, o tempo médio de uma reunião de resultados caiu de noventa para quarenta minutos após a unificação das métricas principais. Não porque as pessoas passaram a falar mais rápido, mas porque eliminaram a etapa de reconciliação manual que consumia metade de cada encontro. Multiplicado por cinquenta semanas e dez reuniões executivas por semana, o resultado é centenas de horas de liderança sênior redirecionadas para decisão estratégica.

Esse é o retorno real de um projeto de dados bem feito. Não é glamouroso como inteligência artificial ou arquiteturas de última geração. Mas é o fundamento sem o qual nenhuma dessas tecnologias vai funcionar de verdade na sua empresa.

Se os dados da sua empresa não batem, o problema não vai se resolver sozinho com o tempo — vai crescer à medida que os sistemas se multiplicam e as equipes aumentam. Se você quer entender como construir essa fundação de dados na sua realidade específica, entre em contato. Esse é exatamente o tipo de desafio que resolvo com executivos que já perceberam que a inconsistência de métricas está custando mais do que parece.