Limpeza de dados: registro de tratamento, critério e exemplo preenchido

Limpeza de dados é a etapa que some do relatório final. O gráfico mostra o lead time médio, a apresentação mostra a causa provável. Quase ninguém pergunta quantas linhas saíram da base, quantos vazios ganharam um número ou qual regra decidiu que "CIM. VALE LTDA" e "Cimentos Vale" são a mesma empresa. Até o dia em que alguém pergunta. A resposta está só na memória de quem mexeu na planilha.

Este artigo trata da ferramenta que guarda essa resposta por escrito: o Registro de Tratamento e Limpeza, a P09 do Kit de Ferramentas de Análise de Dados. É uma folha de uma página, com uma linha por decisão. Cada linha cobra quatro coisas: o problema encontrado, a decisão acompanhada do critério, quantos registros ela tocou e o risco de viés que ela carrega.

Sou Master Black Belt e escrevi o Guia Prático Lean Seis Sigma Black Belt. O capítulo 10 do livro fecha com um resumo em que a confiabilidade dos dados aparece como fundamental no Seis Sigma, porque a abordagem é quantitativa e depende de ferramenta estatística. A P09 é o jeito prático de sustentar essa frase quando a base chega com defeito. Toda base chega. A gente trata essa folha como a caixa-preta da análise: ninguém a consulta enquanto o resultado convence, e ela vira a primeira página aberta quando alguém duvida.

Pela ordem, você vai ver as colunas da folha e as cinco ações de tratamento, cada uma com o critério escrito. Depois vêm o que o livro diz e o que ele não diz, e o caso da Distribuidora Norte Sul com as sete decisões comentadas. No fim ficam o antes e depois da base, os erros mais frequentes e o modelo em branco para baixar.

O que é limpeza de dados

Limpeza de dados é o conjunto de decisões que leva a base bruta a uma base analisável: excluir linhas inválidas, preencher nulos, unificar grafias, converter valores fora do domínio e juntar tabelas. Cada decisão só vale com o critério escrito e o número de registros afetados, para que outra pessoa refaça o caminho.

No dia a dia, tratamento e limpeza viram quase sinônimos. A própria folha do kit junta os dois no nome. O sentido aqui é estatístico: preparar a base para a análise. Não tem relação com o tratamento de dados pessoais da lei de proteção de dados, que é outro assunto e usa a mesma palavra.

A limpeza de dados começa depois que a base foi reunida e antes de qualquer conta. Numa análise de dados de verdade ela consome boa parte do tempo, porque a base real mistura texto livre, campo vazio, data impossível e cadastro digitado de três jeitos. Mesmo dados estruturados, com colunas e tipos definidos, chegam assim, porque o tipo da coluna não impede alguém de digitar errado.

Uma limpeza de dados confiável se distingue de uma apressada pelo registro que deixa para trás. Duas pessoas podem preencher nulos com a mediana. Só uma delas consegue explicar, três semanas depois, por que escolheu a mediana do fornecedor e não a mediana geral. É essa explicação que a P09 guarda.

Limpeza de dados também não é correção da origem. Ela ajusta a cópia usada na análise. O erro que gerou o problema continua no sistema até alguém tratar a causa. Por isso a P09 do caso manda para a Logística os SKUs com saldo negativo. A análise segue com a base tratada. A origem entra na fila de correção.

As colunas da P09 e o que cada uma pergunta

A folha de limpeza de dados tem um cabeçalho curto e uma tabela de decisões. O cabeçalho amarra o registro a uma análise específica; a tabela obriga cada decisão a declarar o que achou, o que fez, quanto tocou e quanto isso pode distorcer o resultado. Abaixo, cada coluna com o que ela pede e o exemplo tirado do caso preenchido.

Repare que a coluna de risco não pede só "alto, médio ou baixo". No caso, cada nível vem com o motivo: a mediana suaviza os valores extremos, o mapeamento manual introduz julgamento, o critério de desempate é objetivo. Um nível sem motivo não ajuda quem vai ler a análise a decidir se confia nela.

A coluna de percentual também tem uma armadilha discreta: o denominador é o total da base de onde o campo saiu, não o total da análise. No caso há três bases com tamanhos muito diferentes. O mesmo número de registros afetados pesa muito mais numa planilha de 4.180 pedidos do que num extrato de 184.320 movimentações.

As cinco ações de limpeza de dados e o critério de cada uma

A primeira instrução da folha define o que conta como decisão: "Uma linha por decisão de tratamento: exclusão, preenchimento, deduplicação, conversão, junção". São cinco ações. Toda limpeza de dados que eu conheço cabe nelas. A tabela mostra cada ação escrita do jeito vago e do jeito que a P09 do caso escreveu.

Na coluna do meio fica o que costuma sobrar de uma limpeza de dados anotada de passagem. Ela descreve a ação e não permite repetir nada: quais datas estavam erradas, com que valor os vazios foram completados, qual versão do nome venceu. A coluna da direita responde a essas perguntas antes que elas apareçam.

A figura deixa visível uma coisa que a tabela da folha esconde: duas linhas fazem mais de uma ação. A linha 5 preenche 51 datas de entrega e exclui outras 96. O próprio registro reconhece que isso mistura dois tratamentos no mesmo campo. A linha 7 junta as duas bases e ainda exclui 9 pedidos empatados. Quando uma linha faz duas coisas, o número de registros afetados vira a soma de dois efeitos diferentes. Fica mais difícil saber qual deles pesa no resultado.

Critério, não ação: o teste de quem refaz

A segunda instrução é a mais importante da folha. Vale citar inteira: "Escreva o critério, não só a ação. 'Removi outliers' não é reproduzível; 'removi acima de Q3+1,5·IQR' é". A diferença entre as duas frases é que a segunda pode ser aplicada por outra pessoa, na mesma base, com o mesmo resultado.

O exemplo da instrução usa a regra do intervalo interquartil, a mesma que desenha os bigodes de um boxplot. Ela não é a única regra possível para valor extremo. O manual de estatística do NIST lista outras, cada uma com sua premissa. A P09 aceita qualquer uma delas, desde que a regra usada esteja escrita, com o limite numérico, para que alguém discorde dela com base em alguma coisa.

Quer saber se a sua limpeza de dados se sustenta sozinha? Faça um teste simples. Entregue a base bruta e a P09 a um colega que não participou do tratamento e peça que ele refaça a base tratada. Se ele precisar perguntar alguma coisa, a linha que gerou a pergunta está incompleta. "Mapeados ao valor mais próximo" passaria mal nesse teste se viesse sozinho; com a tabela de equivalência anexa e o exemplo de "ativo" virando A, passa.

Um critério escrito ainda pode ser subjetivo, e a limpeza de dados convive bem com isso. A linha 4 do caso admite, na coluna de risco, que o mapeamento manual introduz julgamento. Isso é honesto e é suficiente. O julgamento está exposto, a tabela de equivalência pode ser revista, e quem discordar sabe exatamente onde mexer. Critério escondido é o que não tem conserto.

Cada ação tem a sua pergunta de critério. Na exclusão, a pergunta é qual condição tira a linha. No preenchimento, é qual valor entra e sobre qual grupo ele foi calculado. Na deduplicação, é qual chave decide que dois registros são o mesmo. Na conversão, é qual tabela leva o valor antigo ao novo. Na junção, é o que acontece quando há mais de um candidato, e o que acontece no empate. Uma limpeza de dados que responde às cinco perguntas por escrito já passa no teste de quem refaz.

Registros afetados e risco de viés

A terceira instrução diz para que serve a contagem: "Registre quantos registros a decisão afetou. É o que dimensiona o risco de viés". Uma exclusão de 53 linhas num extrato de 184.320 movimentações não muda conclusão nenhuma. Uma decisão de limpeza de dados que toca 14,64% de uma planilha de pedidos muda, se estiver errada.

O raciocínio completo aparece na linha 1 do caso. Havia 334 nulos em 4.180 pedidos, 7,99% da base. Numa limpeza de dados feita às pressas, excluir era a saída mais rápida. A folha registra por que não foi a escolhida: excluir enviesaria contra quem preenche pior a planilha, deixando distorcido o atraso de cada fornecedor. Como a análise compara fornecedores, apagar os vazios tiraria da comparação justamente os pedidos dos compradores menos cuidadosos, e o lead time de alguns fornecedores ficaria medido com menos pedidos que o de outros.

A decisão tomada também tem custo. A coluna de risco o declara: a mediana suaviza os casos de lead time atipicamente alto. É uma troca consciente. A análise perde um pouco da cauda e ganha a comparação completa. Sem o registro, quem lesse o resultado não saberia que essa troca foi feita.

Os percentuais do caso só fecham quando se olha a base de origem de cada campo. LEAD_TIME, DT_ENTREGA e FORNECEDOR vêm da planilha de 4.180 pedidos: 334, 147 e 612 dão 7,99%, 3,52% e 14,64%. DT_PEDIDO vem do ERP: 53 sobre 184.320 dão 0,03%. QTD_SALDO e STATUS_ITEM vêm do WMS, e o total dessa base não aparece na folha.

Na linha 7 a regra falha. É bom saber disso antes de copiar o modelo. Ela conta 312 pedidos com junção ambígua, mas o 0,17% ao lado é a conta sobre as 184.320 movimentações. Sobre os 4.180 pedidos, os mesmos 312 seriam 7,46%. O risco já não pareceria tão baixo. A folha do kit está assim. O que vale levar para o seu registro é a regra: o percentual usa o denominador da unidade que foi contada.

Um jeito rápido de conferir o denominador é refazer a conta de trás para frente. Se 334 registros são 7,99%, a base tem cerca de 4.180 linhas. Se o total que sai não é o de nenhuma base conhecida, o percentual está errado.

Na linha 6, a revisão por amostragem dos casos ambíguos é o que sustenta o risco médio. Normalizar 612 registros pelo CNPJ é mecânico quando o CNPJ existe; os casos em que a grafia não permitia decidir foram conferidos numa amostra. Esse detalhe também está escrito, no lugar certo.

O dado bruto fica intocado

A quarta instrução é curta: "Guarde o dado bruto intocado. Tratamento se faz em cópia, sempre". Ela protege a limpeza de dados inteira. Sem a base bruta, a P09 descreve decisões que ninguém pode refazer, porque o ponto de partida sumiu.

Na limpeza de dados feita no Excel, isso significa uma aba ou um arquivo de origem que ninguém edita, e a base tratada construída a partir dele. Ferramentas que registram os passos ajudam muito. No Power Query, cada transformação vira uma etapa aplicada. A sequência pode ser relida e refeita; o passo a passo de como tratar dados no Power BI mostra essa lógica aplicada.

O registro de etapas da ferramenta não substitui o registro da limpeza de dados. Ele diz o que foi feito, na linguagem da ferramenta; a folha diz por que foi feito e quanto isso pesa, na linguagem de quem vai decidir com o resultado. Num fluxo de ETL automatizado, a mesma separação vale: o código executa, o registro explica.

Guardar o bruto também permite desfazer uma limpeza de dados. Se a revisão mostrar que a mediana do fornecedor foi uma escolha ruim para um caso específico, a base tratada é refeita a partir do bruto, com a nova regra registrada numa linha nova. A versão anterior continua compreensível, porque o registro dela continua lá.

O que o livro diz sobre a confiabilidade dos dados

No livro, o capítulo 10, Seis Sigma, termina com um resumo em tópicos. Um deles está na página 82: "No Seis Sigma, a confiabilidade dos dados se torna fundamental, pois se trata de uma abordagem quantitativa e que utiliza ferramentas estatísticas para suas análises". É a frase que dá sentido à P09: se a análise é quantitativa, a base que alimenta a conta tem de ser defensável.

O mesmo capítulo abre, na página 75, com a lista de objetivos. Um deles é "Entender a importância da métrica e da confiabilidade dos dados". Confiabilidade, no livro, é premissa da abordagem inteira, e não etapa de uma ferramenta.

Para ser preciso sobre o alcance da citação: o livro não traz um roteiro de limpeza de dados, nem regra de imputação de nulos. O que ele oferece de mais próximo é a leitura estatística da base. No capítulo 24, o boxplot é apresentado com referência aos outliers da base de dados, "valores discrepantes", e a estatística descritiva dá as medidas que a P09 usa como critério, como a mediana e os quartis.

Existe uma segunda confiabilidade, que não é assunto da P09: a do instrumento que mede. Viés de medição, repetibilidade e reprodutibilidade são tema da análise do sistema de medição. A limpeza de dados trata o dado depois que ele foi medido; se o problema estiver no instrumento, nenhuma decisão de tratamento conserta.

Onde a P09 fica na fase de Preparação

O kit organiza as ferramentas em fases. A P09, a folha de limpeza de dados, fica na Preparação, entre o Plano de Coleta (P08) e a Folha de Verificação (P10). O guia descreve a fase numa frase: "O que foi coletado, o que foi tratado e com que critério. É a fase que torna a análise reproduzível por outra pessoa."

O plano de coleta de dados define o que falta coletar e como. A P09 registra o que se fez com o que já estava na base. A folha de verificação coleta, à mão, a contagem por categoria que o sistema não registra. As três juntas respondem à pergunta que derruba análise em reunião: de onde veio esse número?

O guia define assim a entrega esperada da P09: "Todo tratamento com o critério usado e o número de registros afetado, antes e depois". O erro comum que o guia aponta é o oposto: "Tratar o dado na hora e não anotar o critério, perdendo a rastreabilidade."

A P09 conversa com o checklist de qualidade da fase anterior, a E06. O checklist mede o problema; o registro decide o que fazer com ele e documenta a decisão. O guia fecha o kit lembrando que o painel final deve ser construído "com o mesmo critério de qualidade e rastreabilidade que E06 e P09 exigem". Em empresas com governança de dados formal, esse registro alimenta o que a área de gerenciamento de dados já documenta sobre cada base.

Como preencher o registro de tratamento em seis passos

O roteiro de limpeza de dados abaixo segue as quatro instruções da folha e acrescenta o que o caso ensina. A ordem importa, porque cada passo depende do anterior.

1. Congele a base bruta. Faça a cópia antes de qualquer limpeza de dados, anote a data e conte as linhas de cada base de origem. Esses totais são os denominadores de todos os percentuais que vêm depois.
2. Liste os problemas por campo, com contagem. Nulos, datas fora do período, valores fora do domínio, grafias diferentes, chaves ambíguas. Cada problema com o número, nunca com "muitos" ou "alguns".
3. Escreva uma linha por decisão. Se um campo pede dois tratamentos, como preencher parte e excluir parte, prefira duas linhas. O caso juntou os dois na linha 5 e teve de registrar isso como risco.
4. Escreva o critério como regra. A frase tem de permitir que outra pessoa aplique a decisão sem perguntar nada: qual valor, qual limite, qual fonte de referência, o que acontece no empate.
5. Conte os afetados e calcule o percentual certo. O percentual se calcula sobre o total da base de origem, na mesma unidade da contagem. Pedido se divide por pedidos; movimentação, por movimentações.
6. Classifique o risco e feche o antes e depois no mesmo dia. O nível vem com o motivo, e a caixa final mostra as contagens da base bruta e da tratada. Uma das armadilhas do guia é exatamente esta: registrado depois, o critério já foi esquecido.

O passo 2 fica mais rápido com uma estratificação prévia por base e por campo, porque problema concentrado numa só origem costuma ter uma só causa. A decisão de tratamento pode ser uma só também.

Exemplo preenchido da P09

O caso do kit é o da Distribuidora Norte Sul, uma empresa ilustrativa com sete centros de distribuição e ruptura de estoque acima da meta. A análise queria saber se o prazo dos fornecedores explicava a falta de estoque, e para isso precisou de uma limpeza de dados em três bases que não foram feitas para conversar. O registro abaixo é a folha que saiu desse trabalho, com a leitura de cada decisão.

1. Distribuidora Norte Sul: sete decisões de tratamento na base de lead time (caso ilustrativo)

A análise AN-2026-014 foi registrada em 10/08/2026 por quem conduzia o estudo no Planejamento. A pergunta era comparar o prazo de entrega dos fornecedores entre os centros de distribuição. As bases eram três. A planilha de Compras tinha 4.180 pedidos, com o lead time digitado à mão. O ERP Protheus trazia 184.320 movimentações, e o WMS Vertice, o saldo e o status de cada SKU por CD.

Pelo volume e pelo alcance, a decisão mais pesada da folha está na linha 1. Faltava o lead time em 334 dos 4.180 pedidos, 7,99%. A equipe escolheu imputar pela mediana do fornecedor em vez de excluir. O motivo está escrito. A exclusão pesaria contra os compradores que preenchem pior, e a comparação sairia torta. Eu gosto muito dessa linha: nenhuma outra protege tanto a conclusão, porque a comparação entre fornecedores é o objetivo da análise inteira.

Em DT_ENTREGA, na linha 5, a mesma mediana cobre 51 datas nulas. Outras 96 linhas saem porque a entrega aparecia antes do pedido. São 147 registros, 3,52%. O risco ficou médio porque o campo recebeu dois tratamentos diferentes. Eu separaria em duas linhas, uma para os nulos e outra para as datas impossíveis; o registro ficaria mais longo e a leitura, mais direta.

Volume pequeno ou efeito contido marca as linhas 2, 3 e 4. A 2 exclui 53 movimentações sem data de pedido válida, 12 nulas e 41 fora do período de janeiro a junho de 2026. A 3 zera 218 saldos negativos sem apagar a linha e marca o SKU e o CD para a Logística corrigir a causa. A 4 converte 1.642 status de texto livre para os quatro valores válidos por tabela de equivalência.

O saldo negativo merece um comentário à parte. Zerar o saldo resolve a análise, mas o saldo negativo nasceu de erro de lançamento no WMS. A folha não deixa isso morrer ali: o SKU e o CD vão para a Logística. É o tipo de decisão que trata o sintoma na base e abre a correção na origem ao mesmo tempo.

No cadastro de fornecedores, a folha unifica 612 registros, 14,64% da planilha, usando o CNPJ do cadastro do ERP como referência. Exemplos como "Cimentos Vale" e "CIM. VALE LTDA" mostram o problema. Os casos ambíguos foram revisados por amostragem. Isso segurou o risco em médio numa linha que toca uma de cada sete linhas da base.

Por último vem a junção entre WMS e ERP, que só compartilham código de SKU e CD, sem número de pedido. Dos 312 pedidos com mais de um candidato, ficou o de menor diferença entre a data do pedido e a movimentação, e os 9 empatados saíram. O critério é objetivo e o risco foi dado como baixo, com a ressalva do denominador que comento na seção de viés.

Repare na proporção entre esforço e visibilidade, que é o ponto que a gente mais subestima numa limpeza de dados. Sete decisões, uma página, e nenhuma delas aparece no gráfico final que foi para a diretoria. Mesmo assim, é a folha que permite defender o lead time médio quando alguém pergunta de onde ele veio.

Se você for usar o caso como modelo, copie a forma e fique atento às duas inconsistências que ele carrega: o denominador da linha 7 e a contagem de pedidos da caixa de antes e depois, que a seção seguinte detalha.

Antes e depois: o que a base tratada ganhou e perdeu

A caixa final da P09 resume a limpeza de dados em duas contagens. A base bruta tinha 184.320 movimentações e 4.180 pedidos com lead time; a tratada ficou com 184.267 movimentações, depois de sair as 53 com data de pedido inválida, e os pedidos completos, com os 334 vazios de lead time preenchidos.

A frase que fecha a caixa explica o ganho melhor que qualquer número: "Sem o ajuste, 8% dos pedidos ficariam fora da comparação, favorecendo quem preenche melhor a planilha, não quem entrega mais rápido". Numa avaliação de fornecedores, esse viés inverteria o que se quer medir: a nota passaria a refletir a disciplina do comprador.

Há uma inconsistência que vale declarar. A caixa diz que a base tratada tem "os mesmos 4.180 pedidos", mas a linha 5 registra 96 linhas excluídas na mesma planilha. A linha 7 exclui 9 pedidos empatados na junção. A folha não explica se essas exclusões valem só para o cálculo de cada campo ou para a base inteira. Num registro seu, a caixa de antes e depois deveria somar todas as linhas da tabela, sem exceção.

O número que vai para a gestão de fornecedores depois dessa análise é o lead time médio de 14,2 dias contra a meta de 9, que o guia do kit apresenta como o indicador mais distante da meta. É o registro da limpeza de dados que permite dizer, com base em alguma coisa, que esse número compara fornecedores em condições iguais.

Erros comuns na limpeza de dados

Os erros de limpeza de dados abaixo aparecem no guia do kit, na própria folha ou na leitura do caso. Quase todos têm a mesma raiz: tratar a base como tarefa técnica e esquecer que ela é uma decisão sobre o resultado.

• Tratar e não anotar. É o erro que o guia aponta para a P09. A limpeza fica certa e impossível de defender, porque ninguém consegue reconstruir o que foi feito.
• Anotar depois. Uma das armadilhas listadas no guia pede o registro no mesmo dia do tratamento, porque, feito depois, o critério já foi esquecido.
• Escrever a ação no lugar do critério. "Removi outliers", "corrigi datas", "padronizei nomes". Nenhuma dessas frases permite repetir o tratamento.
• Excluir por padrão. Apagar a linha com problema é a saída mais rápida e a que mais enviesa quando os problemas não se distribuem por igual, como os nulos do caso.
• Juntar dois tratamentos numa linha. A soma dos afetados esconde qual decisão pesa mais.
• Percentual com denominador errado. Pedido dividido por movimentação dá número pequeno e risco aparente baixo.
• Tratar o dado original. Sem a cópia, o registro descreve um caminho sem ponto de partida.

Para quem já tratou uma base sem registrar, o guia dá uma saída realista: "Reconstrua o que der no Registro de Tratamento (P09), assumindo por escrito o que não for mais possível recuperar". Um registro parcial e honesto vale mais do que uma base limpa sem explicação, e uma cultura baseada em dados se constrói com esse tipo de franqueza.

Limpeza de dados no Excel, no Power BI ou em código

A P09 não depende da ferramenta de limpeza de dados. Ela registra decisões. Um critério de exclusão vale igual em qualquer lugar onde a base for tratada. O que muda é o quanto a ferramenta ajuda a manter o bruto intocado e a repetir os passos.

No Excel, a junção do caso seria feita com PROCV ou função equivalente. É aí que a chave ambígua aparece: o PROCV devolve o primeiro candidato, não o de menor diferença de data. A regra de desempate da linha 7 teria de ser montada à parte. A validação de dados do Excel ataca o problema antes, na digitação, e evitaria boa parte dos status fora do domínio da linha 4.

No Power BI, o tratamento acontece no Power Query. As etapas ficam registradas. Os dados no Power BI chegam ao modelo já tratados. A P09 documenta por que cada etapa existe. Em código, a lógica é a mesma. O artigo Tidy Data, de Hadley Wickham, no Journal of Statistical Software é uma boa referência para a forma que a base tratada deve ter: uma variável por coluna, uma observação por linha.

Seja qual for a ferramenta, a limpeza de dados pede os mesmos três cuidados: a base bruta fica guardada, a tratada é derivada dela, e cada decisão tem uma linha na folha. Por mais que a ferramenta automatize, só essa folha faz com que outra pessoa confie no resultado sem ter estado lá.

Modelo de registro de tratamento em branco para baixar

O modelo em branco traz o cabeçalho de análise, responsável e data, a tabela de decisões com as sete colunas e a caixa de antes e depois. As quatro instruções ficam no topo da folha, para quem preenche ter a regra à vista.

No arquivo está a folha de uma página, com as instruções de preenchimento, o cabeçalho da análise, a tabela de decisões com campo, problema, critério, afetados, percentual e risco, e a caixa final de antes e depois.

Abrir e baixar a P09 em branco (PDF)

O melhor jeito de começar é meter a cara: pegue uma limpeza de dados que você já fez e tente registrá-la de memória. As linhas que você não conseguir completar mostram exatamente onde o seu processo atual perde rastreabilidade.

Para seguir as fases do kit em sequência, da preparação à apresentação, a formação em análise de dados da Voitto trabalha esse caminho com o mesmo caso. Se o seu projeto for Lean Seis Sigma, as certificações ficam reunidas na Academia de Certificação da Voitto.