Pular para o conteúdo
Fynx
Business Intelligence13 min de leitura

Qualidade de dados: como garantir números confiáveis

Qualidade de dados na prática: dimensões, profiling, regras de validação, testes automatizados no pipeline e dono do dado para números confiáveis.

F
Fynx

O número certo por acaso é pior do que o número errado sempre

Existe um problema que quase nenhuma empresa admite em voz alta na reunião de diretoria: ninguém confia plenamente no número que está na tela. O diretor financeiro olha a receita do painel, faz uma careta e pede para "o pessoal conferir na planilha". O gerente comercial mantém um Excel paralelo porque "o dashboard nunca bate". E o time de dados passa metade da semana explicando por que dois relatórios mostram margens diferentes para o mesmo mês. Qualidade de dados é exatamente isso que está faltando ali, e a ausência dela custa caro: decisão adiada, credibilidade queimada e um BI bonito que ninguém usa para valer.

Vou ser direto: sem qualidade de dados, o dashboard mente com confiança. Ele mostra um número preciso, formatado, com a cor certa, e esse número está errado. E o pior tipo de erro não é o gritante que salta aos olhos. É o silencioso, o que parece plausível, o que passa no olhômetro e vira base de uma decisão de milhões. Este artigo é sobre como sair desse jogo. Vou cobrir as dimensões que definem qualidade, o profiling que revela o estado real dos seus dados, as regras de validação e os testes automatizados que pegam o erro cedo, e a cultura de dono do dado que sustenta tudo isso no tempo. Prático e honesto, sem vender bala de prata.

Qualidade de dados não é uma coisa, são seis dimensões mensuráveis

O primeiro erro de quem tenta "melhorar a qualidade" é tratar isso como um sentimento. "Nossos dados estão ruins" não é acionável. O que torna acionável é quebrar a qualidade em dimensões, cada uma com uma pergunta objetiva e uma forma de medir. As seis dimensões clássicas são completude, acurácia, consistência, unicidade, tempestividade e validade. Elas não são invenção de consultoria: são o vocabulário padrão da disciplina de gestão de dados.

DimensãoPergunta que respondeExemplo de falha
CompletudeOs dados que deveriam existir estão presentes?12% dos pedidos sem CNPJ do cliente preenchido
AcuráciaO dado reflete o mundo real?Cidade cadastrada como "São Palo"
ConsistênciaO mesmo fato bate entre sistemas e relatórios?Receita do ERP diferente da do CRM
UnicidadeCada entidade aparece uma única vez?Cliente "Fynx LTDA" duplicado em três registros
TempestividadeO dado chega a tempo de ser útil?Vendas de ontem só atualizam depois do almoço
ValidadeO dado obedece ao formato e às regras esperadas?Data de nascimento em 30/02/2025

A grande vantagem de pensar assim é que cada dimensão vira uma métrica com número. Você não diz "o cadastro está ruim", você diz "a completude do campo CNPJ é de 88% e a meta é 99%". Isso muda a conversa. Vira algo que a diretoria entende, que o dono do processo pode perseguir e que a engenharia consegue monitorar. Sem essa quebra, qualidade de dados fica no campo da reclamação genérica, e reclamação genérica nunca virou plano de ação.

Nem toda dimensão vale o mesmo para o seu negócio

Aqui entra a honestidade que falta em muito material sobre o tema: você não vai perseguir 100% em todas as dimensões, e nem deveria. Perfeição em dados é cara e, em boa parte dos casos, desnecessária. O que importa é priorizar pela dor real. Para um banco, unicidade e validade em CPF são inegociáveis. Para um e-commerce que decide reposição de estoque, tempestividade pesa mais do que acurácia perfeita na casa decimal. Definir a meta de cada dimensão por domínio de dado é trabalho de governança, não de gosto pessoal do analista.

Profiling é o exame de sangue dos seus dados

Ninguém trata uma doença sem diagnóstico. Profiling é o diagnóstico. É o processo de varrer os dados como eles realmente estão, não como você imagina que estão, e produzir um retrato do estado atual. E quase sempre esse retrato é desconfortável, porque revela o que todo mundo fingia não ver.

Um bom profiling responde perguntas concretas, coluna por coluna:

  • Quantos nulos existem em cada campo e onde eles se concentram.
  • Quantos valores distintos um campo tem, o que denuncia duplicidade ou categorias fora de padrão.
  • Qual a distribuição dos valores, mínimos, máximos e outliers absurdos como um pedido de valor negativo.
  • Quais padrões os campos seguem, por exemplo se todo CEP tem oito dígitos ou se metade veio com máscara e metade sem.
  • Quais relações entre tabelas estão quebradas, como vendas apontando para clientes que não existem no cadastro.

O ponto que quero deixar claro: profiling não é uma etapa que você faz uma vez e arquiva. É a primeira coisa a rodar quando uma fonte nova entra no pipeline e algo que vale reexecutar periodicamente, porque as fontes se degradam. Um sistema de origem muda um campo, alguém abre um cadastro manual sem regra, uma integração começa a truncar texto, e a qualidade que estava boa apodrece em silêncio. Descobrir isso no profiling é barato. Descobrir isso na reunião de resultado é caro. É nesse trabalho de mapear o estado real das fontes que a engenharia de dados entrega o maior valor: sem base confiável, tudo que vem depois é maquiagem.

Regras de validação transformam expectativa em contrato

Profiling mostra como os dados estão. Regras de validação definem como eles deveriam estar, e passam a barrar o que foge disso. A diferença é fundamental. Sem regra, você depende de alguém notar o problema. Com regra, o próprio pipeline nota.

Uma regra de validação é uma afirmação verificável sobre o dado. Pense nelas como cláusulas de um contrato que a fonte assinou:

Tipo de regraO que garanteExemplo
Não nuloCompletude do campo críticoTodo pedido tem forma de pagamento
Domínio de valoresValidade categóricaStatus só pode ser "aberto", "pago" ou "cancelado"
Faixa numéricaAcurácia plausívelIdade entre 0 e 120
Unicidade de chaveSem duplicadosNenhum CPF repetido na dimensão cliente
Integridade referencialConsistência entre tabelasToda venda aponta para um produto existente
Formato e máscaraValidade estruturalE-mail com padrão válido, data em formato ISO
FrescorTempestividadeA carga de ontem existe e não está vazia

O segredo aqui é onde a regra roda e o que ela faz quando falha. Regra de validação que vive num documento de Word não protege ninguém. Ela precisa estar codificada dentro do pipeline, executando a cada carga, e com uma decisão clara para o caso de falha: bloquear a carga, mandar o registro problemático para uma área de quarentena, ou deixar passar mas registrar e alertar. Essa escolha depende da criticidade. Um CPF inválido numa base regulatória bloqueia. Um campo de observação vazio provavelmente só gera um aviso. Definir esse comportamento por regra é parte do desenho de governança de dados, não um detalhe técnico solto.

Testes automatizados no pipeline pegam o erro antes da diretoria

Se tem uma ideia que quero que fique desta leitura, é esta: qualidade de dados não se garante conferindo relatório no final. Se garante testando o dado no meio do caminho, de forma automática, toda vez que ele se move. É o mesmo princípio que a engenharia de software aprendeu há décadas com testes automatizados de código, aplicado ao dado.

Na prática, isso significa embutir os testes de qualidade nas etapas do pipeline. Uma arquitetura em camadas ajuda muito aqui, e por isso a arquitetura medalhão, com suas camadas bronze, silver e gold, casa tão bem com qualidade. Os dados brutos chegam na camada bronze. Ao promover para silver, você aplica os testes de validação: completude, tipos, unicidade, integridade. Só o que passa avança. Na camada gold, onde moram as métricas de negócio que a diretoria vê, você testa regras de negócio, como "a soma da receita por região tem que bater com a receita total".

O que muda com testes automatizados no lugar de conferência manual:

  • O erro é pego cedo, na origem, quando ainda é barato de corrigir, e não três dias depois quando já virou base de decisão.
  • A falha é reproduzível, o teste diz exatamente qual regra quebrou e em quais registros, em vez de "o número tá estranho".
  • A confiança é contínua, cada carga bem-sucedida é uma carga que passou por dezenas de verificações, não uma torcida para que esteja tudo certo.
  • A cobertura não depende de humano cansado, o teste roda igual às três da manhã e no fechamento de trimestre.

Ferramentas do ecossistema, seja em pipelines de orquestração, em notebooks no Fabric ou em frameworks dedicados de teste de dados, todas suportam essa lógica. A tecnologia não é o gargalo. O gargalo é a decisão de tratar dado com o mesmo rigor com que se trata software em produção. E essa decisão é cultural antes de ser técnica.

Sem dono do dado, a qualidade sempre volta a cair

Aqui está a parte que ferramenta nenhuma resolve. Você pode montar o melhor profiling, escrever centenas de regras e automatizar todos os testes, e ainda assim ver a qualidade despencar em seis meses. Por quê? Porque falta dono.

Dono do dado é a pessoa, ou o papel, responsável por um domínio de dados específico: cadastro de clientes, dados de vendas, informações de produto. Não é o time de TI. É alguém da área de negócio que conhece o dado, sabe o que significa "cliente ativo", entende por que aquele campo existe e responde quando a qualidade cai. Sem esse dono, todo problema de dado vira "problema do BI", e o time de dados passa a apagar incêndio de um cadastro que ele nem controla.

A cultura de dono do dado se sustenta em três coisas simples e difíceis de manter:

  1. Responsabilidade nomeada. Cada domínio de dado tem um nome de gente ao lado. Não "a área comercial", mas uma pessoa que responde.
  2. Métricas visíveis. As dimensões de qualidade daquele domínio ficam num painel que o dono acompanha. Completude do cadastro caiu? O dono vê antes da diretoria reclamar.
  3. Poder de corrigir na origem. De nada adianta o dono ver o problema se ele não pode ajustar o processo que gera o dado ruim. Qualidade se conserta na fonte, não com remendo no relatório.

Essa estrutura é o que separa uma iniciativa de qualidade que dura de uma que morre no primeiro trimestre. E ela se conecta diretamente com governança e com privacidade: quem cuida da qualidade de um dado sensível também é quem precisa cuidar do tratamento dele, um ponto que aprofundamos em governança de dados, Power BI e LGPD. Manter isso vivo ao longo do tempo é trabalho contínuo de sustentação, não de projeto com data para acabar.

O custo de não fazer é maior do que o de fazer

Vale encarar a conta pelo outro lado. Investir em qualidade custa tempo de engenharia, disciplina de processo e alguma paciência. Não investir também custa, só que a fatura vem disfarçada e parcelada.

Sem qualidade de dadosCom qualidade de dados
Decisão tomada sobre número erradoDecisão sobre número auditável
Retrabalho constante de conferência manualConfiança automatizada a cada carga
Planilhas paralelas competindo com o BIUma fonte da verdade que o time usa
Erro descoberto na reunião de resultadoErro barrado no pipeline, invisível para a diretoria
Credibilidade do BI corroída aos poucosBI vira ativo de decisão

Repare que nenhuma linha da coluna da esquerda aparece num relatório de custo. Ela aparece em decisão ruim, em hora de gente qualificada gasta conferindo Excel e na erosão lenta da confiança que, uma vez perdida, custa muito para reconstruir. Um projeto de Power BI só entrega retorno de verdade quando o número que ele mostra é confiável. O visual é a ponta. A qualidade é a fundação.

Perguntas frequentes

Por onde eu começo se nunca cuidei de qualidade de dados? Comece pelo profiling da fonte mais crítica para o negócio, não de tudo ao mesmo tempo. Escolha o domínio que sustenta a decisão mais importante, meça as seis dimensões nele e mostre o resultado para o dono do processo. O desconforto do primeiro retrato costuma ser o melhor argumento para o investimento. A partir daí, você prioriza as dimensões e as regras que mais doem.

Qual a diferença entre qualidade de dados e governança de dados? Governança é o guarda-chuva: define papéis, políticas, propriedade, catálogo e regras de acesso. Qualidade de dados é uma das disciplinas que a governança abriga, focada em garantir que o dado esteja completo, acurado, consistente, único, tempestivo e válido. Na prática elas andam juntas: sem governança para nomear donos e políticas, a qualidade não se sustenta no tempo.

Preciso de uma ferramenta cara para garantir qualidade? Não. A maior parte do trabalho é de método, não de licença. Profiling, regras de validação e testes automatizados podem ser feitos com o que já existe no seu stack, seja SQL, Power Query, notebooks ou pipelines de dados. Ferramentas dedicadas ajudam a escalar e a padronizar, mas nenhuma delas substitui a decisão de tratar dado com rigor e de nomear donos. Ferramenta sem cultura vira software parado.

Dá para chegar a 100% de qualidade? Não, e perseguir isso é desperdício. Qualidade perfeita em toda dimensão é cara e raramente necessária. O objetivo é definir metas realistas por domínio e por dimensão, de acordo com a criticidade para o negócio, e monitorar para que o dado fique dentro da meta. Um CPF em base regulatória exige rigor quase absoluto. Um campo de observação livre, nem de longe.

De quem é a responsabilidade pela qualidade, do time de dados ou do negócio? Dos dois, com papéis distintos. O negócio é dono do dado: define o que é correto, conhece as regras e corrige a causa na origem. O time de dados constrói e opera os mecanismos: profiling, validações, testes e monitoramento. Quando a qualidade vira "problema só do BI", ela falha, porque o time de dados não controla o processo que gera o dado ruim.

Com que frequência devo rodar profiling e testes? Testes de validação rodam a cada carga do pipeline, de forma automática, sem exceção. Profiling mais profundo vale reexecutar de tempos em tempos e sempre que uma fonte nova entra ou uma fonte existente muda de comportamento. Fontes se degradam sozinhas, então tratar qualidade como algo contínuo, e não como projeto de uma vez, é o que mantém a confiança de pé.

O número que a diretoria confia é o número testado

Qualidade de dados não é perfeccionismo nem burocracia. É a diferença entre um BI que a diretoria usa para decidir e um painel bonito que todo mundo confere na planilha por precaução. As seis dimensões dão o vocabulário, o profiling dá o diagnóstico, as regras e os testes automatizados barram o erro cedo, e o dono do dado sustenta tudo no tempo. É trabalho, mas é o trabalho que faz o número parar de mentir com confiança.

Se você reconheceu a sua empresa em algum ponto deste texto, o cadastro furado, as planilhas paralelas, o dashboard que ninguém confia, esse é o momento de agir. Para sair desse jogo, fale com a gente e monte um diagnóstico de qualidade dos seus dados e transformar seus painéis em fonte de decisão confiável.

Quer aplicar isso na sua empresa?

A Fynx implementa BI, Power BI e Power Platform de ponta a ponta. Conte seu cenário e devolvemos um diagnóstico direto ao ponto.

Falar com um especialista

Vamos transformar seus dados em decisão?

Conte seu cenário. Devolvemos um diagnóstico e uma proposta com faixa de investimento em poucos dias úteis, sem folheto, direto ao ponto.