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.
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ão | Pergunta que responde | Exemplo de falha |
|---|---|---|
| Completude | Os dados que deveriam existir estão presentes? | 12% dos pedidos sem CNPJ do cliente preenchido |
| Acurácia | O dado reflete o mundo real? | Cidade cadastrada como "São Palo" |
| Consistência | O mesmo fato bate entre sistemas e relatórios? | Receita do ERP diferente da do CRM |
| Unicidade | Cada entidade aparece uma única vez? | Cliente "Fynx LTDA" duplicado em três registros |
| Tempestividade | O dado chega a tempo de ser útil? | Vendas de ontem só atualizam depois do almoço |
| Validade | O 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 regra | O que garante | Exemplo |
|---|---|---|
| Não nulo | Completude do campo crítico | Todo pedido tem forma de pagamento |
| Domínio de valores | Validade categórica | Status só pode ser "aberto", "pago" ou "cancelado" |
| Faixa numérica | Acurácia plausível | Idade entre 0 e 120 |
| Unicidade de chave | Sem duplicados | Nenhum CPF repetido na dimensão cliente |
| Integridade referencial | Consistência entre tabelas | Toda venda aponta para um produto existente |
| Formato e máscara | Validade estrutural | E-mail com padrão válido, data em formato ISO |
| Frescor | Tempestividade | A 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:
- Responsabilidade nomeada. Cada domínio de dado tem um nome de gente ao lado. Não "a área comercial", mas uma pessoa que responde.
- 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.
- 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 dados | Com qualidade de dados |
|---|---|
| Decisão tomada sobre número errado | Decisão sobre número auditável |
| Retrabalho constante de conferência manual | Confiança automatizada a cada carga |
| Planilhas paralelas competindo com o BI | Uma fonte da verdade que o time usa |
| Erro descoberto na reunião de resultado | Erro barrado no pipeline, invisível para a diretoria |
| Credibilidade do BI corroída aos poucos | BI 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