Tratamento de dados: como limpar a base antes de analisar
Os cinco problemas que aparecem em toda base de empresa, a ordem certa para corrigir cada um e por que análise em cima de dado sujo só erra mais rápido.
William MeloSócio-fundador da Maze Analytics
Tratamento de dados é o trabalho de pegar a informação do jeito que ela sai dos sistemas da empresa e deixá-la em condição de ser somada, comparada e cruzada sem erro: um registro para cada cliente, um formato para cada campo, uma unidade para cada medida e uma chave que liga o pedido do e-commerce ao faturamento do ERP. Sem isso, o relatório soma coisas diferentes como se fossem iguais, e a análise sai errada com cara de certa.
Os pontos-chave:
- Toda base de empresa chega suja, porque cada sistema foi feito para a sua função, e não para conversar com o vizinho.
- Cinco problemas se repetem em quase todo projeto: duplicidade, formato inconsistente, unidade misturada, data em formatos diferentes e chave que não bate entre sistemas.
- A ordem do trabalho importa: diagnosticar, padronizar, deduplicar, validar e só então automatizar a checagem.
- A limpeza é a maior parte do tempo de um projeto de dados, e quem promete o contrário está escondendo o custo em algum lugar.
- Análise ou IA sobre base suja acelera o erro. O modelo aprende a sujeira e devolve com convicção.
Por que a base de toda empresa chega suja?
Porque nenhum sistema foi comprado pensando em análise. O ERP existe para faturar, a plataforma de e-commerce para vender, o sistema de chão de fábrica para apontar produção. Cada um guarda a informação do jeito que serve à sua tarefa, com o seu código de produto, a sua regra de cadastro e o seu formato de data. Quando alguém tenta juntar tudo, as diferenças aparecem.
O problema é mais comum do que se admite. Um estudo publicado na Harvard Business Review pediu a gestores que avaliassem cem registros recém-criados da própria área: 47% dos registros tinham pelo menos um erro crítico, e só 3% das avaliações chegaram a um padrão aceitável, mesmo pelo critério mais frouxo do estudo.
O teste é simples de repetir antes de aprovar um projeto de BI ou IA: pegue cem linhas do cadastro de clientes e conte quantas passariam sem correção. O que vemos em cliente confirma o estudo: a base parece boa até o dia em que o financeiro tenta bater a venda do e-commerce com o faturamento do ERP.
Quais são os cinco problemas que aparecem em toda base?
Os cinco abaixo respondem pela maior parte do trabalho de tratamento de dados que fazemos. A tabela mostra como cada um se disfarça no relatório e o que fazer com ele.
| Problema | Como aparece no relatório | Correção |
|---|---|---|
| Duplicidade (mesmo cliente, produto ou pedido cadastrado duas vezes) | total de clientes maior que o real, ticket médio menor, venda contada duas vezes | definir o que identifica um registro único, juntar as cópias e manter só uma |
| Formato inconsistente (CNPJ com e sem pontuação, cidade escrita de três jeitos) | filtro que não acha o cliente, a mesma cidade separada em várias linhas | padronizar cada campo com regra escrita: só dígitos, só maiúsculas, lista fechada de valores |
| Unidade de medida misturada (peça, caixa, quilo e metro no mesmo campo) | estoque que não fecha, custo por unidade absurdo, ruptura falsa | escolher a unidade de referência de cada produto e converter tudo para ela, com o fator no cadastro |
| Data em formatos diferentes (dia/mês/ano num sistema, mês/dia/ano em outro, texto em vez de data) | venda de março em dezembro, gráfico com buraco, sazonalidade que não existe | converter para um único formato com fuso horário definido e rejeitar o que não converter |
| Chave que não bate entre sistemas (código do ERP diferente do SKU da loja, cliente sem CNPJ em um lado) | pedidos sem custo, custo sem pedido, margem por produto que não soma o total | criar tabela de correspondência entre os códigos e tratar o que sobra sem par como pendência, nunca como zero |
Os cinco têm algo em comum: nenhum deles trava o sistema de origem. O ERP fatura normalmente com dois cadastros do mesmo cliente. A loja vende normalmente com o SKU diferente do ERP. Por isso ninguém corrige na origem, e o problema só cobra o preço quando alguém tenta analisar.
A chave é o caso mais caro, porque a correspondência entre códigos precisa ser construída item por item ou por regra que deixe a exceção visível. É por isso que o cadastro de produtos costuma ser o primeiro lugar onde uma análise quebra.
Em que ordem fazer o tratamento de dados?
A ordem importa. Deduplicar antes de padronizar deixa passar cópias que só apareceriam depois ("LTDA" e "Ltda." parecem clientes diferentes até virarem maiúsculas). O caminho que seguimos em projeto:
- Diagnosticar. Medir a base antes de mexer: quantos registros, quantos campos vazios, quantos valores fora do esperado, quantas chaves sem par no outro sistema. Sem essa medida ninguém sabe se o tratamento funcionou.
- Padronizar. Aplicar uma regra escrita a cada campo: formato de documento, de data, de unidade, lista de valores permitidos. A regra fica documentada, porque vai ser questionada.
- Deduplicar. Só depois de padronizar, identificar os registros que representam a mesma coisa e escolher qual sobrevive.
- Validar. Conferir o resultado contra uma referência que a empresa confia: o faturamento do mês fecha com a contabilidade? O estoque fecha com a última contagem física? Se não fecha, a diferença precisa de explicação antes de qualquer painel ser publicado.
- Automatizar a checagem. Transformar as validações em testes que rodam toda vez que dado novo entra. CNPJ inválido, pedido sem SKU correspondente ou data fora do intervalo gera aviso no mesmo dia, não no fechamento do trimestre.
O quinto passo separa tratamento de dados de faxina. Faxina se faz uma vez e a sujeira volta no mês seguinte, porque a origem continua produzindo os mesmos erros. Checagem automatizada não impede o erro de nascer, mas impede que ele chegue ao relatório sem ninguém saber.
Quanto do tempo de um projeto de dados vai nisso?
A maior parte. Em pesquisa com profissionais de dados publicada em 2016, a CrowdFlower mediu que 60% do tempo ia para limpar e organizar dados e outros 19% para coletá-los, o que deixa cerca de um quinto para todo o resto, da análise à construção de modelos. Com mais de dois sistemas envolvidos, a proporção tende a piorar.
Isso tem consequência na hora de contratar ou planejar. Quando uma proposta de BI ou de IA reserva pouco tempo para tratamento e muito para painel e modelo, uma de duas coisas acontece: o prazo estoura quando a base revela os problemas, ou o painel é entregue em cima de dado que ninguém validou.
O guia sobre IA para análise de dados explica por que essa etapa vem antes de qualquer discussão sobre modelo.
Por que análise ou IA em cima de base suja só erra mais rápido?
Porque nenhuma ferramenta de análise questiona o que recebe. Se o mesmo cliente está cadastrado três vezes, o painel mostra três clientes com ticket médio baixo e o comercial planeja uma ação de recompra para quem já compra bem. Se a quantidade mistura caixa e peça, a previsão de demanda aprende um padrão que não existe e recomenda compra errada com aparência de precisão.
Com IA o efeito piora, porque a resposta vem com convicção e sem a planilha do lado. Um modelo de linguagem que lê a base e responde "o produto X caiu 30% no Sul" não avisa que metade das vendas do Sul está com a região vazia no cadastro. A Harvard Business Review publicou uma estimativa de US$ 3,1 trilhões por ano para o custo do dado ruim só na economia americana, e boa parte desse custo é o retrabalho de quem descobre o erro depois de ter decidido em cima dele.
A regra que usamos é curta: a análise só pode ser tão boa quanto a pior tabela que entra nela. É esse o motivo de a previsão de demanda começar pela qualidade do histórico, e não pelo método estatístico.
Como impedir que a sujeira volte?
Tratamento sem manutenção dura um ciclo. A base volta a sujar porque o cadastro continua sendo feito com pressa, o fornecedor troca o código do produto e o sistema novo chega com outro formato de data. Três práticas mantêm o ganho:
- Regra escrita para cada campo que decide dinheiro. Se "cliente ativo" tem uma definição, ela fica documentada e a checagem aponta o que fugiu dela. É o começo prático da governança de dados, sem comitê nem burocracia.
- Checagem em dimensões conhecidas. A documentação do Google Cloud sobre qualidade de dados organiza as verificações em dimensões como completude, validade, consistência, unicidade e atualidade. A lista serve de roteiro para saber o que medir em cada tabela, com qualquer ferramenta.
- Dono para cada fonte. Quando a chave do produto quebra, alguém do comercial ou do cadastro é avisado e resolve. Sem dono, o aviso vira ruído e o erro volta a passar.
Quando falar com a Maze Analytics
Faz sentido conversar quando dois ou mais sistemas precisam ser lidos juntos e ninguém dentro de casa tem tempo ou método para o trabalho descrito acima. É o que fazemos em dados e integrações: conectar as fontes, tratar e padronizar a informação, montar a estrutura que preserva o histórico e implantar as validações que avisam quando algo sai do padrão. Depois de pronta, acompanhamos os fluxos em operação e corrigimos o que falha.
Não faz sentido se o seu caso é uma planilha única com algumas centenas de linhas e um problema de cadastro conhecido. Aí um analista da casa com uma tarde livre e as regras deste artigo resolve, e nós dizemos isso na primeira conversa.
Perguntas frequentes
O que é tratamento de dados?
É o conjunto de etapas que deixa a informação dos sistemas da empresa em condição de ser analisada: diagnosticar os problemas, padronizar formatos e unidades, eliminar duplicidades, validar o resultado contra uma referência confiável e automatizar a checagem para que o erro não volte sem aviso. Vem antes de qualquer painel, previsão ou uso de IA.
Qual a diferença entre limpeza de dados e qualidade de dados?
Limpeza é a ação de corrigir o que está errado na base agora. Qualidade de dados é o estado que se quer manter, medido em dimensões como completude, unicidade, validade e atualidade, e sustentado por regras e checagens que rodam continuamente. Limpar sem cuidar da qualidade significa limpar de novo em poucos meses.
A IA pode limpar os dados sozinha?
Ela ajuda em partes do trabalho, como sugerir que dois cadastros são o mesmo cliente ou apontar valores fora do padrão. A decisão sobre qual registro sobrevive, qual unidade é a de referência e o que conta como cliente ativo é regra de negócio, e precisa ser definida por quem conhece a operação. IA sem essa regra padroniza errado com muita eficiência.
