Como implementar um processo de qualidade de dados

A qualidade de dados (DQ) em sistemas de data warehouse está se tornando cada vez mais importante. O aumento dos requisitos regulatórios, mas também a crescente complexidade das soluções de data warehouse, forçam as empresas a intensificar (ou iniciar) uma iniciativa de qualidade de dados.

O foco principal deste artigo será o armazenamento de dados “tradicional”, mas a qualidade dos dados também é um problema em conceitos mais “modernos”, como data lakes. Ele mostrará alguns pontos principais a serem considerados e também algumas armadilhas comuns a serem evitadas ao implementar uma estratégia de qualidade de dados. Ele não cobre a parte de escolher a tecnologia/ferramenta certa para construir uma estrutura DQ.

Um dos problemas mais obstrutivos de um projeto DQ é o fato de, à primeira vista, criar muito trabalho para as unidades de negócios sem fornecer nenhuma funcionalidade extra. Uma iniciativa de qualidade de dados geralmente só tem fortes defensores se:

• Existem problemas de qualidade de dados com um impacto severo nos negócios.
• Órgãos reguladores impõem padrões de qualidade de dados (por exemplo, BCBS 239 no setor financeiro).

O tratamento do DQ é semelhante ao do teste no desenvolvimento de software – se um projeto ficar sem tempo e/ou orçamento, essa parte tende a ser reduzida primeiro.

Isso, é claro, não é toda a verdade. Um bom sistema de qualidade de dados ajuda a detectar erros precocemente, acelerando assim o processo de entrega de dados de qualidade “suficientemente boa” aos usuários.

Definição de termos

Antes de discutir o tópico, um entendimento comum dos termos usados ​​é importante.

Data Warehouse (DWH)

Um data warehouse (DWH) é um sistema não operacional usado principalmente para suporte à decisão. Ele consolida os dados dos sistemas operacionais (todos eles ou um subconjunto menor) e fornece dados otimizados para consulta aos usuários do sistema DWH. O data warehouse deve fornecer “uma única versão da verdade” dentro da empresa. Um data warehouse geralmente é construído de estágios/camadas:

Os dados operacionais são armazenados praticamente inalterados em uma camada de teste . A camada principal contém dados consolidados e unificados. O próximo estágio opcional é uma área de derivação , fornecendo dados derivados (por exemplo, uma pontuação do cliente para vendas) e agregações. A camada de data mart contém dados otimizados para um determinado grupo de usuários. Os data marts geralmente contêm agregações e muitas métricas derivadas. Os usuários de data warehouse geralmente trabalham apenas com a camada de data mart.

Entre cada estágio, ocorre algum tipo de transformação de dados. Normalmente, um data warehouse é carregado periodicamente com extrações delta dos dados operacionais e contém algoritmos para manter os dados históricos.

Qualidade dos dados

A qualidade dos dados geralmente é definida como uma métrica de quão bem um produto atende aos requisitos do usuário. Diferentes usuários podem ter diferentes requisitos para um produto, portanto, a implementação depende da perspectiva do usuário e é importante identificar essas necessidades.

A qualidade dos dados não significa que os dados precisam estar completamente ou quase livres de erros – depende dos requisitos dos usuários. Uma abordagem “boa o suficiente” é uma boa escolha para começar. Hoje em dia, as empresas maiores têm “uma política governamental de dados (ou informações)”, e a qualidade dos dados faz parte disso. Uma política governamental de dados deve descrever como sua empresa lida com dados e como ela garante que os dados tenham a qualidade certa e que as regras de privacidade de dados não sejam violadas.

A qualidade dos dados é um tópico em andamento. Um loop de circuito DQ deve ser implementado (consulte o próximo capítulo). Requisitos regulatórios e regras de conformidade também afetam a qualidade dos dados necessários, como TCPA (US Telephone Consumer Protection Act) ou GDPR na Europa para questões de privacidade, mas também regras específicas do setor, como Solvência II para seguros na UE, BCBS 239 e outros para bancos, e assim por diante.

Circuito de Qualidade de Dados

Como acontece com todos os tópicos de qualidade, o DQ é uma atividade contínua projetada para manter uma qualidade satisfatória. Como resultado de um projeto DQ, um loop de circuito semelhante ao abaixo deve ser implementado:

As etapas dentro desse loop serão descritas nos próximos capítulos.

Papéis de qualidade de dados

Para implementar uma iniciativa de DQ bem-sucedida, são necessários os seguintes papéis:

• Proprietário dos dados. O proprietário dos dados é responsável pela qualidade dos dados, mas também pela proteção da privacidade dos dados. O proprietário dos dados “possui” um domínio de dados, controla o acesso e é responsável por garantir a qualidade dos dados e tomar medidas para corrigir as descobertas. Em organizações maiores, é comum encontrar vários proprietários de dados. Os domínios de dados podem ser, por exemplo, dados de marketing, dados de controle etc. Se houver mais de um proprietário de dados em uma empresa, deve haver uma pessoa (um proprietário de dados ou outra pessoa) responsável pelo processo geral de qualidade de dados. Um proprietário de dados deve ter uma autoridade forte para impor a qualidade dos dados e apoiar o processo de DQ; portanto, os proprietários de dados geralmente são partes interessadas seniores. Uma boa compreensão do domínio do negócio, juntamente com boas habilidades de comunicação são importantes.
• Administrador de Dados. Um administrador de dados ajuda a implementar a qualidade de dados em uma empresa, dando suporte aos usuários de dados em questões sobre como interpretar dados/modelo de dados, problemas de qualidade de dados etc. Os administradores de dados geralmente são a equipe do proprietário dos dados ou podem ser organizados em um centro de competência de qualidade de dados ou uma equipe DQ. Os administradores de dados podem ter experiência em TI ou negócios, mas devem conhecer os dois lados. Habilidades analíticas, juntamente com uma boa compreensão do domínio de negócios que eles suportam, combinadas com fortes habilidades de comunicação, são os principais pré-requisitos para um administrador de dados bem-sucedido.
• Usuário de dados. Esses são usuários de data warehouse que trabalham com dados. Os usuários de dados normalmente trabalham com a camada de data mart e são responsáveis ​​pelos resultados do trabalho com os dados. Os usuários de dados garantem que haja verificações de qualidade de dados adequadas para o nível de qualidade de que precisam. Os usuários de dados precisam de uma forte compreensão de seus dados, domínio de negócios e as habilidades analíticas necessárias para interpretar os dados. É razoável encontrar algumas pessoas entre os usuários de dados em cada unidade de negócios que serão responsáveis ​​pelos problemas de qualidade de dados.

Para garantir o sucesso, é importante ter essas funções claramente definidas e amplamente aceitas em sua organização nos estágios iniciais de seu projeto de DQ. É igualmente importante encontrar especialistas em dados competentes para essas funções que apoiem o projeto.

Defina as regras

Encontre e implemente verificações/regras úteis de DQ. A definição de regras DQ requer um bom entendimento de seu data warehouse e seu uso.

Como encontrar regras DQ?

Conforme discutido anteriormente, os usuários de dados (e o proprietário dos dados) são responsáveis ​​pelo uso dos dados e, portanto, também pelo nível necessário de qualidade dos dados. Os usuários de dados devem ter uma boa compreensão de seus dados para que possam fornecer a melhor entrada para regras úteis de qualidade de dados.

Também são eles que analisam os resultados das regras de qualidade de dados, por isso é sempre uma boa ideia deixá-los definir suas próprias regras. Isso aumenta ainda mais a aceitação para verificar e avaliar o resultado das regras DQ atribuídas a uma unidade de usuário de dados (consulte o capítulo “Analisar”).

A desvantagem dessa abordagem é que os usuários de dados normalmente conhecem apenas a camada do data mart, não as camadas anteriores do data warehouse. Se os dados foram corrompidos nos estágios “inferiores”, isso não será detectado verificando apenas a camada “superior” do seu data warehouse.

Lidando com Erros

Que tipo de erros conhecidos podem ocorrer em um data warehouse?

• Lógica de transformação errada no data warehouse
  • Quanto mais complexo for seu cenário de TI, mais complexa tende a ser a lógica de transformação. Esses são os problemas de DQ mais comuns, e o efeito de tais erros pode ser dados “perdidos”, duplicatas, valores incorretos, etc.
• Processo de carga instável ou manuseio incorreto de cargas
  • A carga de um data warehouse pode ser um processo complexo que pode incluir erros na definição da orquestração de trabalhos (trabalhos iniciados muito cedo ou muito tarde, trabalhos não executados etc.). Erros devido à intervenção manual (por exemplo, alguns trabalhos são ignorados, alguns trabalhos são iniciados com a data de vencimento errada ou com os arquivos de dados de ontem) ocorrem frequentemente quando o processo de carregamento fica sem banda devido a alguma interrupção.
• Transferência de dados incorreta de fontes de dados
  • A transferência de dados é frequentemente implementada como uma tarefa do sistema de origem. Anomalias ou interrupção nos fluxos de trabalho podem causar a entrega de dados vazios ou incompletos.
• Dados operacionais incorretos
  • Os dados no sistema operacional contêm erros não reconhecidos até o momento. Pode parecer estranho, mas é um lugar comum em projetos de data warehouse que a qualidade dos dados operacionais muitas vezes não é vista até que os dados sejam incluídos em um DWH.
• Interpretação incorreta de dados
  • Os dados estão corretos, mas os usuários não sabem interpretá-los corretamente. Este é um “erro” muito comum que não é estritamente um problema de qualidade de dados, mas algo que tem a ver com governança de dados e é uma tarefa para os administradores de dados.

Esses problemas geralmente são causados ​​por pessoas que não possuem o conhecimento e as habilidades apropriados para definir, implementar, executar e trabalhar com uma solução de data warehouse.

Dimensões de qualidade de dados

As dimensões DQ são uma maneira comum de identificar e agrupar verificações de DQ. Existem muitas definições e o número de dimensões varia consideravelmente: você pode encontrar 16 ou até mais dimensões. De uma perspectiva prática, é menos confuso começar com algumas dimensões e encontrar uma compreensão geral delas entre seus usuários.

• Completude: Todos os dados necessários estão disponíveis e acessíveis? Todas as fontes necessárias estão disponíveis e carregadas? Os dados foram perdidos entre os estágios?
• Consistência: Existem dados errôneos/conflitantes/inconsistentes? Por exemplo, a data de término de um contrato em um estado “Rescindido” deve conter uma data válida maior ou igual à data de início do contrato.
• Singularidade: Existem duplicatas?
• Integridade: Todos os dados estão vinculados corretamente? Por exemplo, existem pedidos vinculados a IDs de clientes inexistentes (um problema clássico de integridade referencial)?
• Pontualidade: Os dados estão atualizados? Por exemplo, em um data warehouse com atualizações diárias, eu esperaria que os dados de ontem estivessem disponíveis hoje.

Os dados gerados pelo processo de carregamento do data warehouse também podem ser úteis.

• Tabelas com dados descartados. Seu data warehouse pode ter processos para pular/atrasar dados que não podem ser carregados devido a problemas técnicos (por exemplo, conversão de formato, valores obrigatórios ausentes etc.).
• Informações de registro. Problemas notáveis ​​podem ser gravados em tabelas de log ou arquivos de log.
• Conta de entrega. Alguns sistemas utilizam “notas de entrega” para dados fornecidos por sistemas operacionais (por exemplo, número de registros, número de chaves distintas, somas de valores). Eles podem ser usados ​​para verificações de reconciliação (veja abaixo) entre o data warehouse e os sistemas operacionais.

Tenha em mente que cada verificação de qualidade de dados deve ser analisada por pelo menos um usuário de dados (consulte o capítulo “Analisar”) caso sejam encontrados erros, para os quais você precisará de alguém responsável e disponível para cuidar de cada verificação implementada.

Em um data warehouse complexo, você pode acabar com muitas (às vezes milhares) regras DQ. O processo para executar as regras de qualidade de dados deve ser robusto e rápido o suficiente para lidar com isso.

Não verifique fatos que são garantidos pela implementação técnica. Por exemplo, se os dados estiverem armazenados em um SGBD relacional, não é necessário verificar se:

• As colunas definidas como obrigatórias contêm valores NULL.
• Os valores dos campos de chave primária são exclusivos em uma tabela.
• Não há chaves estrangeiras em uma tabela com verificações de integridade relacional habilitadas.

Dito isso, sempre tenha em mente que um data warehouse está em constante mudança e que a definição de dados de campos e tabelas pode mudar ao longo do tempo.

A arrumação é muito importante. As regras definidas por diferentes unidades de usuário de dados podem se sobrepor e devem ser consolidadas. Quanto mais complexa for a sua organização, mais tarefas domésticas serão necessárias. Os proprietários de dados devem implementar um processo de consolidação de regras como uma espécie de “qualidade de dados para regras de qualidade de dados”. Além disso, as verificações de qualidade de dados podem se tornar inúteis se os dados não forem mais usados ​​ou se sua definição for alterada.

Classes de regras de qualidade de dados

As regras de qualidade de dados podem ser classificadas com base no tipo de teste.

• Verificação da qualidade dos dados. O caso “normal”, verificando dados em uma camada de data warehouse (consulte a Figura 1) em uma tabela ou em um conjunto de tabelas.
• Reconciliação. Regras que verificam se os dados foram transportados corretamente entre as camadas do data warehouse (consulte a Figura 1). Essas regras são usadas principalmente para verificar a dimensão DQ de “Integridade”. A reconciliação pode usar uma única linha ou uma abordagem resumida. A verificação de linhas únicas é muito mais granular, mas você terá que reproduzir as etapas de transformação (filtragem de dados, alterações nos valores dos campos, desnormalização, junções etc.) entre as camadas comparadas. Quanto mais camadas você pulou, mais complexa lógica de transformação deve ser implementada. Portanto, é uma boa opção fazer a reconciliação entre cada camada e sua predecessora, em vez de comparar a preparação com a camada do data mart. Se as transformações tiverem que ser implementadas nas regras de reconciliação, use a especificação, não o código do data warehouse! Para reconciliação resumida, encontre campos significativos (por exemplo, sumarização, contagem de valores distintos, etc.).
• Monitoramento. Um data warehouse geralmente contém dados históricos e é carregado com extrações delta de dados operacionais. Existe o perigo de uma lacuna cada vez maior entre o data warehouse e os dados operacionais. Construir séries temporais resumidas de dados ajuda a identificar problemas como esse (por exemplo, comparar os dados do mês passado com os dados do mês atual). Os usuários de dados com um bom conhecimento de seus dados podem fornecer medidas e limites úteis para regras de monitoramento.

Como quantificar um problema de qualidade de dados

Depois de definir o que verificar, você terá que especificar como quantificar os problemas identificados. Informações como “cinco linhas de dados violam a regra DQ com ID 15” fazem pouco sentido para a qualidade dos dados.

Faltam as seguintes peças:

• Como quantificar/contar os erros detectados. Você pode contar “número de linhas”, mas também pode usar uma escala monetária (por exemplo, exposição). Tenha em mente que os valores monetários podem ter sinais diferentes, então você terá que investigar como resumi-los de forma significativa. Você pode considerar o uso de ambas as unidades de quantificação (contagem de linhas e resumo) para uma regra de qualidade de dados.
• População. Qual é o número de unidades verificadas pela regra de qualidade de dados? “Cinco de cinco linhas de dados” tem uma qualidade diferente de “cinco de 5 milhões”. A população deve ser medida usando a(s) mesma(s) quantificação(ões) dos erros. É comum mostrar o resultado de uma regra de qualidade de dados como uma porcentagem. A população não deve ser idêntica ao número de linhas em uma tabela. Se uma regra DQ verifica apenas um subconjunto dos dados (por exemplo, apenas contratos rescindidos na tabela de contratos), o mesmo filtro deve ser aplicado para medir a população.
• Definição do resultado. Mesmo que uma verificação de qualidade de dados encontre problemas, isso nem sempre precisa causar um erro. Para a qualidade dos dados, um sistema de semáforos (vermelho, amarelo, verde) usando valores de limite para avaliar as descobertas é muito útil. Por exemplo, verde: 0-2%, amarelo: 2-5%, vermelho: acima de 5%. Lembre-se de que, se as unidades de usuário de dados compartilharem as mesmas regras, elas poderão ter limites muito diferentes para uma determinada regra. Uma unidade de negócios de marketing pode não se importar com a perda de alguns pedidos, enquanto uma unidade de contabilidade pode se importar com até centavos. Deve ser possível definir limiares em percentagem ou em valores absolutos.
• Colete linhas de erro de amostra. Ajuda se uma regra de qualidade de dados fornecer uma amostra dos erros detectados—normalmente, as chaves (de negócios!) e os valores de dados verificados são suficientes para ajudar a examinar o erro. É uma boa ideia limitar o número de linhas de erro gravadas para uma regra de qualidade de dados.
• Às vezes, você pode encontrar “erros conhecidos” nos dados que não serão corrigidos, mas são encontrados por verificações úteis de qualidade de dados. Para esses casos, recomenda-se o uso de whitelists (chaves de registros que devem ser ignoradas por uma verificação de qualidade de dados).

Outros metadados

Os metadados são importantes para rotear o “Analyze” e monitorar as fases do loop de controle de qualidade dos dados.

• Itens verificados. Isso ajuda a atribuir a(s) tabela(s) e campo(s) verificado(s) a uma regra de qualidade de dados. Se você tiver um sistema de metadados aprimorado, isso pode ajudar a atribuir automaticamente usuários de dados e um proprietário de dados a essa regra. Por motivos regulatórios (como o BCBS 239), também é necessário comprovar como os dados são verificados pelo DQ. No entanto, atribuir regras automaticamente a usuários/proprietários de dados por meio da linhagem de dados (*) pode ser uma faca de dois gumes (veja abaixo).
• Usuário de dados. Cada regra DQ deve ter pelo menos um usuário de dados/unidade de usuário de dados atribuído para verificar o resultado durante a fase “Analisar” e decidir se e como uma descoberta influencia seu trabalho com os dados.
• Proprietário dos dados. Cada regra DQ deve ter um proprietário de dados atribuído.

(*) A linhagem de dados mostra o fluxo de dados entre dois pontos. Com a linhagem de dados, você pode encontrar todos os elementos de dados que influenciam um determinado campo de destino em seu warehouse.

Usar a linhagem de dados para atribuir usuários a regras pode ser problemático. Como mencionado anteriormente, os usuários de negócios geralmente conhecem apenas a camada do data mart (e o sistema operacional), mas não os níveis inferiores do data warehouse. Ao mapear por meio da linhagem de dados, os usuários de dados receberão regras com as quais não estão familiarizados. Para os níveis mais baixos, a equipe de TI pode ser necessária para avaliar uma descoberta de qualidade de dados. Em muitos casos, um mapeamento manual ou uma abordagem mista (mapeamento por linhagem de dados apenas dentro do data mart) pode ajudar.

Medindo a qualidade dos dados

Medir a qualidade dos dados significa executar as regras de qualidade dos dados disponíveis, o que deve ser feito automaticamente , acionado pelos processos de carregamento do data warehouse. Como vimos antes, pode haver um número notável de regras de qualidade de dados, de modo que as verificações serão demoradas.

Em um mundo perfeito, um data warehouse seria carregado apenas se todos os dados estivessem livres de erros. No mundo real, isso raramente é o caso (realisticamente, quase nunca é o caso). Dependendo da estratégia geral de carregamento de seu data warehouse, o processo de qualidade de dados deve ou não (o último é muito mais provável) controlar o processo de carregamento. É um bom projeto ter processos de qualidade de dados (redes de trabalho) paralelos e vinculados aos processos de carregamento de data warehouse “regulares”.

Se houver acordos de nível de serviço definidos, certifique-se de não impedir as cargas do data warehouse com as verificações de qualidade de dados. Erros/abends nos processos de qualidade de dados não devem interromper o processo de carregamento regular. Erros inesperados nos processos de qualidade de dados devem ser relatados e apresentados para a fase “Analisar” (veja o próximo capítulo).

Lembre-se de que uma regra de qualidade de dados pode falhar devido a erros inesperados (talvez a própria regra tenha sido implementada incorretamente ou a estrutura de dados subjacente tenha sido alterada ao longo do tempo). Ajudaria se o seu sistema de qualidade de dados fornecesse um mecanismo para desativar essas regras, especialmente se sua empresa tiver poucos lançamentos por ano.

Os processos DQ devem ser executados e relatados o mais cedo possível — idealmente, logo após o carregamento dos dados verificados. Isso ajuda a detectar erros o mais cedo possível durante o carregamento do data warehouse (algumas cargas complexas do sistema de warehouse têm uma duração de vários dias).

Analisar

Nesse contexto, “analisar” significa reagir às descobertas da qualidade dos dados. Esta é uma tarefa para os usuários de dados atribuídos e o proprietário dos dados.

A maneira de reagir deve ser claramente definida pelo seu projeto de qualidade de dados. Os usuários de dados devem ser obrigados a comentar uma regra com descobertas (pelo menos regras com luz vermelha), explicando quais medidas estão sendo tomadas para lidar com a descoberta. O proprietário dos dados precisa ser informado e deve decidir em conjunto com o(s) usuário(s) dos dados.

As seguintes ações são possíveis:

• Problema sério: O problema precisa ser corrigido e a carga de dados repetida.
• O problema é aceitável: tente corrigi-lo para futuras cargas de dados e lide com o problema no data warehouse ou no relatório.
• Regra DQ com defeito: corrija a regra DQ problemática.

Em um mundo perfeito, todos os problemas de qualidade de dados seriam corrigidos. No entanto, a falta de recursos e/ou tempo geralmente resulta em soluções alternativas.

Para poder reagir a tempo, o sistema DQ deve informar os usuários de dados sobre “suas” regras com descobertas. Usar um painel de qualidade de dados (talvez com o envio de mensagens de que algo aconteceu) é uma boa ideia. Quanto mais cedo os usuários forem informados sobre as descobertas, melhor.

O painel de qualidade de dados deve conter:

• Todas as regras atribuídas a uma determinada função
• Os resultados das regras (semáforo, medidas e linhas de exemplo) com a capacidade de filtrar regras por resultado e domínio de dados
• Um comentário obrigatório que os usuários de dados devem inserir para descobertas
• Um recurso para “anular” opcionalmente o resultado (se a regra de qualidade de dados relatar erros devido a uma implementação defeituosa, por exemplo). Se mais de uma unidade de negócios tiver a mesma regra de qualidade de dados atribuída, a “anulação” será válida apenas para a unidade de negócios do usuário de dados (não para toda a empresa).
• Mostrando regras que não foram executadas ou que terminaram de forma anormal

O painel também deve mostrar o status atual do processo de carregamento do data warehouse recente, dando aos usuários uma visão de 360 ​​graus do processo de carregamento do data warehouse.

O proprietário dos dados é responsável por garantir que cada descoberta tenha sido comentada e que o status da qualidade dos dados (original ou anulado) seja pelo menos amarelo para todos os usuários de dados.

Para uma visão geral rápida, ajudaria a criar um tipo de KPIs simples (indicadores-chave de desempenho) para usuários/proprietários de dados. Ter um semáforo geral para os resultados de todas as regras associadas é bastante fácil se cada regra receber o mesmo peso.

Pessoalmente, acho que calcular um valor geral de qualidade de dados para um determinado domínio de dados é bastante complexo e tende a ser cabalístico, mas você poderia pelo menos mostrar o número de regras gerais agrupadas por resultado para um domínio de dados (por exemplo, “100 regras DQ com resultados 90% verdes, 5% amarelos e 5% vermelhos”).

É tarefa do proprietário dos dados garantir que as descobertas sejam corrigidas e a qualidade dos dados melhorada.

Melhorando processos

Como os processos de data warehouse mudam frequentemente, o mecanismo de qualidade de dados também precisa de manutenção.

Um proprietário de dados deve sempre cuidar dos seguintes pontos:

• Mantenha-o atualizado. As mudanças no data warehouse precisam ser capturadas no sistema de qualidade de dados.
• Melhorar. Implemente novas regras para erros que ainda não são cobertos pelas regras de qualidade de dados.
• Linha de fluxo. Desative as regras de qualidade de dados que não são mais necessárias. Consolide regras sobrepostas.

Monitorando os Processos de Qualidade de Dados

O monitoramento de todo o processo de qualidade de dados ajuda a melhorá-lo ao longo do tempo.

Coisas que vale a pena assistir seriam:

• A cobertura de seus dados com regras de qualidade de dados
• A porcentagem de descobertas de qualidade de dados nas regras ativas ao longo do tempo
• O número de regras de qualidade de dados ativas (Fique de olho nisso - eu vi usuários de dados resolvendo suas descobertas simplesmente desabilitando mais e mais regras de qualidade de dados.)
• O tempo necessário em uma carga de dados para que todas as descobertas sejam classificadas e corrigidas

Conclusão

Muitos dos pontos a seguir são importantes em qualquer tipo de projeto.

Antecipe a resistência. Como vimos, se não houver um problema urgente de qualidade, a qualidade dos dados geralmente é vista como um fardo adicional sem oferecer novas funcionalidades. Lembre-se de que isso pode criar carga de trabalho adicional para os usuários de dados. Em muitos casos, as exigências regulatórias e de conformidade podem ajudá-lo a convencer os usuários a ver isso como um requisito inevitável.

Encontre um patrocinador. Conforme observado acima, o DQ não é um item de venda rápida, portanto, é necessário um patrocinador/interessado poderoso – quanto mais alto na gestão, melhor.

Encontre aliados. Assim como acontece com o patrocinador, qualquer pessoa que compartilhe a ideia de uma forte qualidade de dados seria muito útil. O circuito DQ é um processo contínuo e precisa de pessoas para manter o circuito ativo.

Comece pequeno. Se não houver uma estratégia de DQ até agora, procure uma unidade de negócios que precise de melhor qualidade de dados. Construa um protótipo para mostrar a eles o benefício de melhores dados. Se sua tarefa é melhorar ou até mesmo substituir uma determinada estratégia de qualidade de dados, observe as coisas funcionando bem/sendo aceitas na organização e mantenha-as.

Não perca de vista toda a imagem. Embora comece pequeno, tenha em mente que alguns pontos, principalmente os papéis, são pré-requisitos para uma estratégia de DQ bem-sucedida.

Uma vez implementado, não deixe ir. O processo de qualidade de dados precisa fazer parte do uso do data warehouse. Com o tempo, o foco na qualidade dos dados tende a se perder um pouco e cabe a você mantê-lo.