Preciso revisar qualidade dos meus dados
Resposta rápida
Revisão de qualidade de dados é o trabalho que separa decisão informada de decisão tomada com base em planilha errada. O ritual periódico cobre cinco dimensões: completude (campos críticos preenchidos onde precisam estar), unicidade (sem duplicação de cliente, produto, transação), consistência (mesma informação igual em sistemas diferentes), validade (dado no formato e domínio esperados — CPF válido, e-mail com formato, data no range razoável) e atualidade (fonte refrescada conforme prometido). Defina conjuntos de dados prioritários (mestre de cliente, catálogo de produto, base de vendas) e nele rode verificações de qualidade mensais com plano de correção priorizado. Não basta encontrar o problema — precisa ser corrigido na origem e ter prevenção (validação no momento da entrada). Dado sujo é causa silenciosa de decisão ruim.
Na empresa pequena, o volume de dados é menor e a revisão cabe em uma a duas horas mensais — geralmente focada nos mesmos suspeitos: cadastro de cliente (duplicação, dados incompletos), cadastro de produto, base de vendas, contas a receber. A ferramenta é a planilha ou o próprio sistema (filtro, consulta SQL básica). O ponto focal de TI ou administrativo passa a fazer parte do mês a mês. O risco é assumir que está limpo porque "é pouco dado" — mesmo em pequena, duplicação de cliente bate dois cadastros de uma só empresa, e o relatório financeiro mistura. Disciplina mínima: revisar cadastros novos do mês para duplicação, validar e-mail e CPF/CNPJ na entrada do sistema (configuração do ERP costuma permitir), corrigir o que apareceu e seguir adiante. Sem virar projeto eterno de limpeza.
Na empresa média, qualidade de dados ganha relevância — múltiplos sistemas, múltiplas equipes inserindo, integrações que propagam erro. Ferramenta dedicada (Great Expectations open source, Talend Data Quality, OpenRefine, ou módulo do próprio BI) começa a fazer sentido. Conjuntos de dados prioritários ganham regras de qualidade escritas e checagem automatizada. O risco característico é o "limpa anual": projeto pontual que limpa o dado, mas sem correção da origem o problema volta em meses. Defesa: cada problema encontrado vira correção do dado existente mais correção da origem (validação no momento da entrada, regra de integridade, processo da área usuária). Data steward por domínio (uma pessoa de negócio responsável por cada conjunto de dados crítico) é o que sustenta no longo prazo.
Na empresa grande, qualidade de dados é função formalizada com programa estruturado (data governance), data quality framework, ferramenta enterprise (Informatica, Collibra, Talend, Ataccama), data stewards por domínio, KPIs de qualidade rastreados. Verificações de qualidade rodam de forma automatizada no pipeline (validação na ingestão, monitoramento contínuo, alerta de desvio). MDM (Master Data Management) gerencia dados-mestre (cliente, produto, fornecedor) com governança única. O risco aqui é o programa virar artefato burocrático sem dono efetivo de negócio — relatório de qualidade rico mas correção não acontece porque não há accountability. Modelo maduro inclui escalation: problema de qualidade que persiste vira matéria para comitê de governança com decisão executiva.
- Cliente importante aparece duplicado em relatórios financeiros
- Mesmo dado tem valor diferente em sistemas diferentes
- Campos críticos do cadastro estão vazios em parte da base
- Decisão recente foi tomada com base em número que depois se revelou errado
- Não há quem responda por qualidade dos dados de um domínio
- Limpeza de dado já virou projeto várias vezes sem resolver na raiz
As cinco dimensões de qualidade
Qualidade de dados não é um conceito monolítico. Cinco dimensões cobrem o essencial, e cada conjunto de dados crítico precisa ser avaliado em cada uma.
Completude: os campos críticos estão preenchidos onde precisam estar? E-mail do cliente, CNPJ do fornecedor, código do produto, data da transação. Campo crítico vazio compromete uso.
Unicidade: não há duplicação? Mesmo cliente cadastrado duas vezes com pequenas variações no nome; mesmo produto com dois SKUs; mesma transação contabilizada dobrada.
Consistência: a mesma informação é igual entre sistemas? Cliente X tem CNPJ Y no ERP e CNPJ Z no CRM. Sem alinhamento, integração propaga erro.
Validade: o dado está no formato e domínio esperados? CPF válido (não apenas onze dígitos), e-mail com formato válido, data dentro de range razoável, valor numérico positivo onde só pode ser positivo.
Atualidade: a fonte está refrescada conforme prometido? Painel diz "atualizado em tempo real" mas o pipeline está com 6 horas de atraso.
Defina conjuntos de dados prioritários
Tentar revisar tudo é impossível e desperdiça esforço. Comece pelos conjuntos críticos: mestre de cliente (duplicação aqui afeta vendas, financeiro, marketing), catálogo de produto (afeta estoque, vendas, fiscal), base de transações (vendas, pedidos, faturas), mestre de fornecedor (afeta compras e financeiro). Em programa maduro, qualidade rola em todos os conjuntos relevantes; em programa inicial, três a cinco já cobrem 80% do impacto.
- Atualize as métricas de qualidade. Para cada conjunto prioritário, rode as checagens nas cinco dimensões. Em programa maduro, automatizado; em inicial, manual com SQL.
- Identifique problemas críticos. Problema que afeta processo crítico (faturamento, cobrança, atendimento ao cliente) entra na lista urgente.
- Priorize correções. Impacto (quantos registros, qual processo afetado) versus esforço (limpar manualmente, ajustar fonte, automatizar regra).
- Corrija o dado existente. Para o que está claramente errado — duplicação, formato inválido, vazio em campo obrigatório.
- Corrija a origem. Cada problema corrigido sem correção da origem volta em meses. Validação na entrada do sistema, regra de integridade, processo da área usuária.
- Defina dono por domínio. Cada conjunto crítico tem data steward — pessoa de negócio que responde pela qualidade no longo prazo, não TI sozinho.
- Comunique resultado. Métricas de qualidade compartilhadas com áreas usuárias — sem visibilidade, ninguém prioriza correção da origem.
Correção é remédio; prevenção é vacina
Limpeza de dado é trabalho repetitivo e ingrato. Sem prevenção na origem, o problema volta. Prevenção tem três camadas:
Validação no momento da entrada: sistema não aceita CPF inválido, e-mail mal formado, data fora de range, campo obrigatório vazio. Maior parte dos ERPs e CRMs aceita regra de validação em campo crítico.
Detecção em fluxo: pipeline de ingestão verifica qualidade antes de gravar no destino. Registro fora da regra vai para fila de exceção, não para a base de produção.
Processo da área usuária: conferência cruzada (segundo par de olhos para cadastro de alto impacto), check periódico (amostragem mensal), educação contínua (área usuária entende o impacto do que está cadastrando).
Quando MDM faz sentido
MDM (Master Data Management) é o investimento em centralizar gestão de dados-mestre — cliente, produto, fornecedor — em uma plataforma única que distribui versão canônica para todos os sistemas. Resolve consistência entre sistemas e duplicação na fonte. Custa investimento significativo (plataforma + implantação + governança contínua).
MDM faz sentido quando: a empresa tem múltiplos sistemas críticos manipulando os mesmos dados-mestre, inconsistência entre sistemas causa impacto recorrente em decisão ou processo, integrações ponto a ponto não conseguem manter sincronia, programa de governança formalizado já tem condição de operar a plataforma. Para empresa pequena ou início de jornada de qualidade, MDM costuma ser overkill — boa disciplina em cada sistema resolve.
Limpa anual sem correção da origem. Projeto pontual limpa, mas em meses o problema volta. Toda correção precisa de correspondente correção da origem (validação, processo).
Sem dono de negócio. Quando TI é o único responsável, área usuária não prioriza correção. Data steward por domínio é o ingrediente que falta.
Tentar revisar tudo. Programa que abraça o universo paralisa. Comece por três a cinco conjuntos críticos e expanda conforme matura.
Métrica sem comunicação. Relatório de qualidade que fica em TI não move comportamento. Compartilhar com áreas usuárias com nome e impacto é o que pressiona correção.
- Conjuntos de dados prioritários estão definidos com data steward
- Métricas das cinco dimensões foram rodadas para os conjuntos críticos
- Problemas críticos estão classificados por impacto e prazo
- Correções de dado existente foram executadas no que se justifica
- Correções da origem estão planejadas — não basta limpar sem prevenir
- Métricas foram compartilhadas com áreas usuárias responsáveis
- Validações no momento da entrada foram ativadas onde possível