Qualidade de dados: por que correções isoladas não resolvem o problema de sua empresa 

Reconhecer o custo da baixa qualidade de dados é um passo importante. Divergências entre sistemas, cadastros incompletos, informações desatualizadas e conceitos interpretados de formas diferentes podem provocar retrabalho, conciliações manuais, decisões adiadas e perda de confiança. Esse reconhecimento, porém, não muda a operação por si só. 

Em muitas organizações, a resposta continua concentrada em mutirões de saneamento, ajustes em relatórios ou regras adicionadas após um incidente. As equipes corrigem o dado necessário para uma entrega imediata, mas o processo, o sistema ou a decisão que originou o problema permanece inalterado. Em algum momento, a inconsistência reaparece. 

A questão estratégica, portanto, não é apenas como melhorar determinado conjunto de dados. É como criar uma capacidade para definir expectativas, detectar desvios, priorizar problemas, corrigir causas e aprender continuamente. 

Essa mudança exige tratar qualidade de dados não como uma campanha temporária, mas como parte do modelo operacional da organização.

Por que as correções isoladas não resolvem o problema 

Um problema de qualidade pode se tornar visível em um dashboard, em um modelo analítico ou em uma integração. Isso não significa que tenha sido criado nesses pontos. 

Imagine uma situação em que o mesmo cliente aparece com identificadores diferentes em sistemas comerciais e financeiros. A divergência pode ser corrigida na camada de relatório, permitindo que uma apresentação seja concluída. Entretanto, se a origem da divergência estiver em regras distintas de cadastro ou na ausência de integração entre os sistemas, a correção analítica tratará apenas o sintoma. 

É comum que iniciativas de qualidade permaneçam reativas quando: 

• não está claro quem pode definir ou alterar uma regra; 
• a área de Dados recebe a responsabilidade por problemas originados em processos de negócio; 
• cada área utiliza critérios diferentes para avaliar o mesmo dado; 
• os problemas entram em uma fila sem critérios comuns de severidade; 
• as métricas mostram defeitos, mas não os usos e resultados afetados; 
• ferramentas são implantadas antes do desenho das responsabilidades; 
• a correção do registro substitui a investigação da causa; 
• exceções permanecem abertas sem prazo, responsável ou aceite de risco. 

Essas lacunas ajudam a explicar por que uma ferramenta de monitoramento, isoladamente, não constitui um programa de qualidade. Ela pode tornar os desvios visíveis, mas não determina quem deve decidir, qual problema merece prioridade ou que mudança precisa ocorrer no processo de origem. 

A própria Gartner apresenta a governança de dados e analytics como a especificação dos direitos de decisão e das responsabilidades necessárias para garantir comportamentos adequados na avaliação, criação, consumo e controle dos ativos de dados e analytics. A definição é importante porque desloca a governança da produção de documentos para o campo das decisões organizacionais.

 

Qualidade precisa ser definida em relação ao uso 

A norma ISO/IEC 25012 organiza qualidade de dados por meio de características como acurácia, completude, consistência, credibilidade e atualidade, entre outras. O modelo oferece um vocabulário útil, mas essas dimensões só se tornam acionáveis quando associadas a um contexto de uso. Você pode consultar a norma aqui.

Um endereço sem complemento, por exemplo, pode ser suficiente para uma análise agregada por município e inadequado para uma entrega. Um dado atualizado mensalmente pode atender a um relatório gerencial, mas não a uma decisão operacional tomada a cada hora. 

Por isso, qualidade não deve ser interpretada apenas como ausência abstrata de defeitos. Ela representa o grau em que os dados atendem às necessidades de um uso especificado. 

Esse princípio tem uma consequência prática: a organização não precisa aplicar o mesmo nível de controle a todos os dados. O primeiro recorte deve considerar aqueles associados a: 

• decisões relevantes; 
• processos críticos; 
• obrigações regulatórias; 
• riscos financeiros ou operacionais; 
• experiência de clientes; 
• produtos de dados amplamente utilizados; 
• fluxos com grande número de dependências. 

Algumas organizações denominam esses dados como Critical Data Elements, ou elementos críticos de dados. A nomenclatura é menos importante do que o critério. Um dado não é crítico por ser tecnicamente complexo ou estar em uma plataforma estratégica. Ele é crítico porque sua inadequação pode comprometer um uso que importa para a organização. 

A orientação por domínios também ajuda a aproximar decisões de quem conhece a semântica e os processos que produzem os dados. A McKinsey, em suas publicações sobre transformação e governança de dados, enfatiza a necessidade de relacionar os esforços de dados a domínios, casos de uso e valor para o negócio, em vez de tratar governança como uma iniciativa inteiramente centralizada. Consulte mais aqui.

 

Os seis componentes de uma capacidade de qualidade de dados 

Transformar iniciativas isoladas em uma capacidade compartilhada requer mais do que reunir um conjunto de boas práticas. É necessário definir componentes que funcionem de maneira integrada. 

1. Direcionamento e escopo 

O programa deve começar por resultados e riscos concretos. Isso significa escolher domínios, processos ou produtos prioritários e explicitar por que a qualidade é importante em cada contexto. 

Essa delimitação evita dois extremos: tentar controlar todos os dados desde o início ou escolher o escopo apenas com base na disponibilidade técnica. 

O direcionamento também precisa estabelecer os princípios do programa, o nível de risco aceitável e os fóruns responsáveis por decisões que ultrapassam a autonomia de um domínio.

2. Accountability e direitos de decisão 

Todo dado prioritário precisa ter decisões atribuídas. Entre elas: 

• quem define a expectativa de qualidade; 
• quem aprova uma regra; 
• quem avalia o impacto de um desvio; 
• quem atua sobre a causa; 
• quem financia uma correção estrutural; 
• quem pode aceitar temporariamente uma exceção; 
• quem arbitra conflitos entre áreas. 

Accountability não significa que uma única pessoa executará todas essas atividades. Significa que a organização consegue identificar quem responde por cada decisão.

3. Regras e padrões comuns 

Termos como completude, consistência e atualidade precisam ser traduzidos em critérios verificáveis. Dizer que um dado deve estar “sempre atualizado” não é suficiente. É necessário determinar a frequência esperada, a tolerância aplicável, o uso protegido pela regra e a ação necessária quando houver um desvio. 

Os padrões corporativos ajudam a criar consistência, mas não devem eliminar o contexto. Uma dimensão pode ser essencial para um domínio e secundária para outro. 

4. Processos operacionais 

A qualidade precisa entrar no fluxo cotidiano de trabalho. Isso envolve detectar, registrar, classificar, investigar, priorizar, remediar e validar problemas. 

O processo também deve diferenciar: 

• correção pontual do registro; 
• correção de uma transformação ou pipeline; 
• alteração do sistema de origem; 
• mudança no processo de negócio; 
• revisão da própria expectativa; 
• aceite consciente de uma exceção. 

Sem essa diferenciação, o programa pode acumular evidências de problemas sem desenvolver capacidade para removê-los.

5. Habilitação tecnológica 

Profiling, catálogo, metadados, data lineage, observabilidade, workflows e automação de controles podem ampliar cobertura e velocidade. A escolha da tecnologia, contudo, deve resultar do modelo operacional. Uma plataforma pode detectar uma quebra de padrão, mas o valor surge quando esse alerta possui criticidade, contexto, responsável e caminho de resolução. 

Esse cuidado também evita a criação de centenas de regras sem owner, sem consequência operacional e sem relação clara com o uso do dado.

6. Métricas e evolução 

O programa precisa acompanhar tanto a condição dos dados quanto a capacidade da organização de responder aos problemas. 

Isso requer indicadores técnicos, operacionais e de resultado. Um score isolado pode mostrar melhora em uma dimensão, mas não demonstra automaticamente redução de risco, retrabalho ou interrupções. 

Os seis componentes são interdependentes. Regras sem responsáveis tendem a ser ignoradas. Responsáveis sem autoridade não conseguem alterar processos. Ferramentas sem priorização produzem alertas em excesso. Métricas sem contexto direcionam atenção para o que é fácil medir, não necessariamente para o que é mais importante. 

 

Responsabilidade compartilhada não pode ser responsabilidade difusa 

Um modelo federado é especialmente adequado para equilibrar consistência corporativa e conhecimento local. Nesse modelo, as políticas, padrões e mecanismos comuns podem ser coordenados por uma função de Data Governance ou Data Office, enquanto as decisões sobre significado, criticidade, risco e prioridade permanecem próximas dos domínios que produzem e utilizam os dados. 

Uma distribuição possível inclui: 

Data Owner: responde pelas principais decisões relativas aos dados de um domínio, incluindo requisitos, prioridades, riscos e exceções. 

Data Steward: ajuda a transformar políticas e decisões em práticas, coordenando definições, regras, indicadores e incidentes. 

Data Producer: atua nos processos, sistemas ou pipelines que criam e transformam os dados. 

Data Consumer: explicita a finalidade de uso, os requisitos necessários e o impacto de um desvio. 

Data Governance ou Data Office: estabelece padrões, facilita decisões, consolida métricas e acompanha a aderência ao modelo. 

Times de plataforma e engenharia: fornecem mecanismos escaláveis de monitoramento, rastreabilidade, integração e automação. 

Fóruns de governança: arbitram conflitos e prioridades que envolvem diferentes domínios. 

Esses títulos não são universais. O DAMA-DMBOK, referência amplamente utilizada em gestão de dados, reúne práticas de data governance e data quality, mas cada organização precisa adequar papéis à sua estrutura. O ponto essencial é preservar as responsabilidades, mesmo quando os nomes são diferentes. 

A centralização excessiva transforma Governança em gargalo e afasta decisões do contexto. A descentralização sem padrões, por outro lado, cria interpretações incompatíveis. O desenho federado procura combinar autonomia nos domínios com regras de integração e escalonamento.

 

Do incidente à eliminação da causa 

A governança se torna concreta quando um problema percorre um fluxo conhecido: 

Detecção: o desvio é identificado por uma regra automatizada, observabilidade, usuário ou incidente operacional. 

Contextualização: são identificados os dados, processos, produtos, sistemas e decisões afetados. 

Classificação: o problema recebe uma avaliação de severidade, alcance, urgência e risco. 

Priorização: o impacto é comparado com recorrência, dependências e esforço de tratamento. 

Investigação: a causa é localizada na captura, no processo, no sistema, na transformação ou na interpretação do dado. 

Remediação: os registros afetados e o mecanismo responsável pelo erro são tratados de forma proporcional. 

Validação: a organização confirma se a expectativa voltou a ser atendida. 

Prevenção: controles, processos, regras ou responsabilidades são atualizados para reduzir recorrência. 

Aprendizado: indicadores e padrões são revistos a partir do incidente. 

O fluxo não deve terminar automaticamente quando os dados voltam a passar em uma regra. Em alguns casos, uma correção manual resolve a urgência sem evitar reincidência. Em outros, a causa não pode ser eliminada naquele momento, mas o risco pode ser explicitamente aceito por prazo determinado. 

Uma experiência publicada pela DB ajuda a visualizar a relação entre dados e processo operacional. Em nosso case Inteligência de dados na intralogística, o contexto apresentado é o de uma operação de manufatura, e o aprendizado particularmente relevante é que iniciativas de dados ganham significado quando associadas ao funcionamento de um processo real. Na qualidade de dados, isso implica avaliar não somente tabelas e indicadores, mas também como as informações são geradas, movimentadas e utilizadas ao longo da operação. 

Esse exemplo não deve ser interpretado como comprovação de um modelo universal, mas ele ilustra por que o conhecimento do processo e do domínio é indispensável para transformar dados em uma capacidade operacional. Leia o case completo aqui.

 

Como priorizar sem criar uma fila infinita 

Um programa não conquista credibilidade por registrar todos os problemas. Ele conquista credibilidade quando consegue explicar por que determinado problema merece ser tratado antes de outro. 

Uma matriz de priorização pode considerar quatro eixos: 

Criticidade do uso: Qual processo, decisão, produto ou obrigação depende do dado? Que consequência surge se a expectativa não for atendida? 

Magnitude do impacto: O desvio afeta clientes, continuidade operacional, resultado financeiro, conformidade ou qualidade de uma decisão? 

Exposição: Quantos usuários, produtos, registros e processos são afetados? Com que frequência o evento ocorre? 

Tratabilidade: Qual é o esforço necessário? Existem dependências? A intervenção corrige somente os registros atuais ou reduz a probabilidade de recorrência? 

A prioridade não deve ser determinada apenas pela quantidade de erros ou pela área que reclama com maior intensidade. Um problema de baixo volume pode ser crítico se afetar uma obrigação regulatória. Da mesma forma, um grande número de campos vazios pode ser irrelevante quando esses campos não são necessários para nenhum uso vigente. 

Também é útil separar incidentes urgentes de melhorias estruturais. Os primeiros preservam a operação, já as melhorias desenvolvem a capacidade. Se todo o investimento for consumido por urgências, a organização continuará corrigindo os mesmos sintomas. 

 

Métricas que mostram capacidade, e não apenas defeitos 

As métricas podem ser organizadas em três níveis. 

Condição dos dados 

• completude; 
• validade; 
• consistência; 
• unicidade; 
• atualidade; 
• acurácia, quando houver uma referência confiável para verificá-la. 

Eficiência operacional 

• incidentes por severidade; 
• tempo para detectar; 
• tempo para resolver; 
• taxa de recorrência; 
• percentual de dados críticos monitorados; 
• percentual de problemas com causa identificada; 
• exceções abertas, vencidas ou sem responsável. 

Resultado para o negócio 

• redução de retrabalho; 
• diminuição de conciliações manuais; 
• redução de interrupções associadas ao dado; 
• estabilidade dos processos dependentes; 
• confiança dos consumidores; 
• redução de exposição a riscos previamente definidos. 

É importante evitar uma relação causal automática. A melhora de um indicador técnico não garante, isoladamente, um resultado financeiro. A organização precisa demonstrar a conexão entre a regra, o uso protegido e o efeito observado.

 

Uma implementação pequena, mas desenhada para escalar 

Um programa sustentável pode começar em um único domínio, desde que seu desenho produza aprendizado reutilizável. 

Alinhar resultado e patrocínio: Escolha um processo, produto ou decisão relevante. Delimite o problema, nomeie o Data Owner e estabeleça os resultados esperados. 

Explicitar expectativas e responsabilidades: Identifique os dados críticos, defina regras essenciais e registre quem decide, acompanha e atua sobre cada tipo de problema. 

Colocar a operação em funcionamento: Implemente controles proporcionais, forme um backlog priorizado, estabeleça rituais e acompanhe indicadores técnicos, operacionais e de negócio. 

Escalar por padrões reutilizáveis: Incorpore os aprendizados às políticas, automatize controles recorrentes, integre metadados e workflows e expanda gradualmente para outros domínios. 

O piloto não deve servir apenas para provar uma ferramenta. Deve provar que a organização consegue atribuir decisões, resolver conflitos, tratar causas e medir resultados. 

Também não é necessário começar por uma política extensa, uma plataforma implantada em toda a empresa ou centenas de regras. Esse tipo de abrangência inicial pode aumentar o custo antes que o modelo tenha demonstrado utilidade.

 

Qualidade de dados como disciplina operacional 

Iniciativas isoladas se transformam em uma capacidade contínua quando a qualidade passa a integrar o modelo operacional.  Isso ocorre quando a organização: 

1. prioriza dados em função de usos e impactos; 
2. atribui responsabilidades e autoridade; 
3. transforma expectativas em regras verificáveis; 
4. estabelece um fluxo recorrente de tratamento; 
5. corrige causas nos processos e sistemas que as produzem; 
6. usa tecnologia para ampliar uma prática já definida; 
7. mede condição, resposta e resultado; 
8. aprende com os incidentes e reutiliza padrões. 

Maturidade não significa eliminar definitivamente todos os problemas. Significa poder detectá-los, contextualizá-los, decidir sobre eles e reduzir sua recorrência de maneira previsível. 

O próximo passo, portanto, não é ampliar indiscriminadamente o número de regras. É escolher um domínio relevante e responder com clareza a quatro perguntas: 

1. Qualidade para qual uso?  
2. Sob responsabilidade de quem? Medida de que forma?  
3. Tratada por qual processo? 

Quando essas respostas deixam de depender de esforços individuais e passam a fazer parte da operação, qualidade de dados deixa de ser uma sucessão de correções e se torna uma capacidade compartilhada pela organização.