Qualidade de Dados / Data Quality

Sintomas semelhantes de má qualidade dos dados surgem repetidamente durante as nossas discussões com os clientes e com os funcionários das filiais especializadas e departamentos. Essencialmente relacionam-se  com baixos padrões de informações de contacto. Nós também achamos que os processos de negócio (ou seja a utilização prevista dos dados) são muitas vezes desconhecidas; e que estes apresentam novos desafios.

Outro problema comum que é mencionado é que os campos não são preenchidos corretamente com a informação desejada. A tabela abaixo dá uma visão geral dos sintomas típicos da má qualidade dos dados, juntamente com suas causas, medidas de optimização e o valor adicional de longo prazo resultante para sua empresa.

Encontre a nuvem certa para seus dados mestre de clientes no céu de Qualidade de Dados. Estes pré-requisitos básicos vão ajudar a fazer a escolha certa:

1. Os requisitos reais: Os requisitos reais são o principal critério de selecção para a solução de nuvem correcta. Os custos, desempenho e conforto de operação têm que formar um todo coerente para uma extensão maior do que em modelos convencionais, a fim de ser capaz de assumir as suas exigências e recursos precisamente em consideração.

2. Taxa fixa ou por utilização: Modelos de longo prazo de aluguer não têm lugar na nuvem. O serviço deve ser facturado apenas de acordo com a "utilização" e não como uma taxa fixa, de modo que uma solução de informática na nuvem pode ser usada da forma mais flexível em termos de custos como o leque de funções proporcionadas.

3. Transparência de custos: Como é o caso de todos os outros serviços, o volume utilizado deve ser facturado de forma transparente. Como resultado, pode ver o custo de uma acção individual de qualidade de dados num piscar de olhos e também os itens individuais que compõem o valor total da factura.

4. Dados correctos: A solução deve incluir as funções mais importantes para a limpeza de dados. A correcção e optimização dos endereços, incluindo a correcção de endereço e deduplicação, formam a base de todos os conceitos de gestão da qualidade de dados e de forma a garantir dados de alta qualidade ao cliente.

5. Dados actuais: A fim de manter os dados de seus clientes up-to-date, as aplicações na nuvem devem ser fornecidas com serviços de deduplicação de dados.

6. Valor acrescentado: Funções de enriquecimento de dados, por exemplo, anexar dados geográficos, também são práticos. Isso aumenta o valor dos dados para as actividades de vendas ou facilita a busca de clientes específicos.

7. Capacidade de integração: a possibilidade de integrar a solução de QD na nuvem em outras aplicações, a fim de ter acesso imediato às funções de qualidade de dados a partir da interface operacional actual e para monitorizar e optimizar a qualidade de dados logo na entrada, é particularmente útil.

8. Solução híbrida: a combinação de software instalado e Qualidade de Dados on Demand tem a vantagem de que as tarefas de grande volume são realizadas pelo software instalado enquanto que as tarefas especiais ou não-recorrentes ou trabalhos ad hoc podem ser executados na nuvem.

9. Interface do utilizador: A solução deve ser estruturada de forma clara e fácil de entender. Isto significa que todas as funções básicas e os custos / uso deve ser exibido na página inicial após o login pessoal. Todas as outras funções, as configurações de conta de utilizador e ajuda global deverá ser acessível através da página inicial com um único clique.

10. Protecção: Os dados só podem ser transferidos de forma criptografada. Além disso, o fornecedor de nuvem deve ser obrigado a manter o sigilo e receber os dados, seja num centro de processamento de dados in-house ou num centro de processamento de dados certificado de um fornecedor de serviço conhecido.

Muitas vezes é colocada a questão "Como posso medir a qualidade dos dados?"

Logo à partida a qualidade de dados não pode ser medida numa só dimensão, porque é multidimensional, existem inúmeras métricas que devem ser contempladas.

Se por um lado temos a validade dos dados, por outro temos a completude dos dados ou até mesmo a consistência desses dados entre outros aspectos.

Depois temos outro factor que entra na equação. Se tivemos a falar de moradas poderemos dizer que todos os registos têm os 7 dígitos do código postal, ou seja, supostamente existe 100% de completude nos códigos postais, mas quantos são válidos? Quantos são consistentes? Olhando muitas vezes para os dados, sem ser sequer necessário o recurso a qualquer aplicação, notamos que uma boa parte deles terminam em 000, ou mesmo em 999. Quando estes dois já foram "proibidos", detectamos uma grande numero de ocorrências de registos terminados em 001. Ou seja numa dimensão (completude) até temos valores bastante bons, mas se formos ver em termos de validade e consistência dos dados, a realidade é um pouco diferente. Se juntarmos a isto a consistência entre as ruas e as localidade indicadas, os valores finais relativos ao address management, vão ficar bem abaixo dos 100%.

Mas depois temos ainda os valores relativos aos nomes, aos duplicados entre muitos outros factores. Quantos nomes existem que não estão correctos? Quantos nomes existem que não têm sexo atribuído? Quantos registos existem que devido a algum dos erros anteriormente referidos não estão identificados como duplicados?

Pode haver algum numero final que diga qual a percentagem de qualidade de dados? Dificilmente esse numero será um numero aceitável, porque o que pode e deve existir é uma métrica para cada uma das dimensões a cada um dos factores.

Como conclusão, sim pode ser medido em percentagem o valor de cada uma das dimensões.

Quanto à normalização é um processo que requer cuidados específicos, especialmente se estivermos a tratar registos sensíveis. Quando digo sensíveis, refiro-me a registos de clientes e/ou de fornecedores, que não devem ser confundidos com outros, apenas porque têm um nome parecido ou porque moram por vezes na mesma casa, mas são pai e filho. Se tivermos na nossa BD dois registos com ligeiras diferenças, mas que não sejam diferenciadoras para ficarmos com a certeza se são realmente dois registos distintos, ou que são realmente duplicados, na grande maioria dos casos o melhor é deixar os dois duplicados assinalados, para que o departamento competente possa fazer a respectiva validação.

Mas existem casos em as duvidas na deduplicação são aceites como duplicados, como por exemplo, se tivermos um envio de uma peça publicitária, mas apenas existem peças suficientes para 75% dos clientes, uma das soluções pode ser a remoção do envio precisamente destas registos duvidosos. Os softwares de deduplicação, têm precisamente esta capacidade de ajustar conforme o necessário com aumento/diminuição dos pesos, para que se possa ter a deduplicação pretendida. Existem deduplicações predefinidas, mas cada BD tem as características próprias e são essas características que muitas vezes têm de ser contempladas nos ajustes para que se consiga os melhores resultados. A perfeição nestes casos não existe, quando estamos a tratar milhões de registos, porque se por um lado podemos estar a deixar duplicados não identificados, se alterarmos os ajustes poderemos estar a dar como duplicados registos que não são duplicados, como tal, o que recomendo é ter uma deduplicação que seja "segura", que não esteja a identificar falsos duplicados e deixar a indicação da deduplicação mais apertada, alertando assim para deduplicações mais duvidosas, mas que podem ser resolvidas num posterior contacto com o cliente.

Uma deduplicação sempre importante é a deduplicação por household.

Para que se possa ter uma boa qualidade de dados é necessário em muitos casos fazer uma limpeza regular a esses dados. Se por um lado existem campos que facilmente conseguimos verificar a sua validade e qualidade, outros há em que é quase impossível tal tarefa.

Iniciando pelos nomes temos um bom exemplo da simplicidade e da dificuldade na limpeza dos dados. Em termos gerais tanto o nome, como o campo sexo são facilmente verificáveis, validados e corrigidos se necessário. Existem listas de referência com os nomes e com os respectivos sexos, fazendo o cruzamento entre estas listas de referência e os dados existentes e temos o tratamento executado. Depois temos as excepções. Desde nomes que simplesmente estão escritos de uma forma tão distorcida que impede a sua correcção, as abreviaturas não standartizadas, até nomes totalmente estranhos, não sendo necessário sequer dar como exemplo as famosas filhas de um casal do nosso burgo. Estes casos são os que têm se ser validados manualmente. Felizmente que estes casos são sempre casos residuais e por vezes nem sequer existem.

Depois temos os valores que derivam de regras existentes e que os utilizadores acabam por tornear inserindo outros valores, como nos 3 últimos dígitos do código postal serem em muitos casos "999", porque anteriormente já tinha sido impossibilitada a inserção do "000". Ou então no numero de porta porque é um campo que tem obrigatoriedade de preenchimento e como já se colocou a morada completa no campo do arruamento, voltam a colocar um valor no campo numero de porta. No final temos como resultado registos como:

Embora sejam problemas resolúveis é sempre arriscado simplesmente retirar o 9999, porque pode haver casos em que o 9999 é realmente o numero de porta.

No próximo post passamos à fase de deduplicaçaão.

Uma das grandes dificuldades das empresas é a integração de dados por haver diferentes integrações de dados, especificas para cada uma das empresas.

Um exemplo simples são os receios que existem aquando da transferência de dados entre sistemas e em eventuais alterações que possa haver nos dados. Essa transferência poderá esmagar alguma alteração que tenha sido efectuada no sistema de destino. Com o software de deduplicação isso pode ser facilmente evitado, criando inclusive níveis de alerta, conforme as diferenças entre os sistemas.

Conforme esses níveis de alerta são criados diferentes tratamentos para os dados. Esta abordagem permite facilitar e acima de tudo assegurar que os processos automatizados de transferência de dados entres sistemas são fiáveis e confiáveis, permitindo igualmente a automatização de praticamente todos os processos.

Por outro lado, caso existam chaves que tenham de ser criadas antes do processo de integração é assim igualmente possível a criação automática dessas chaves permitindo a sua criação previamente ao processo de integração, impedindo assim que haja problemas. Existe ainda a possibilidade de complementarização de registos, caso seja necessária dentro desse processo de integração de dados, que mais uma vez estas aplicações ajudam a simplificar.

A criação de trabalhos pré-definidos com horários de arranque e com encadeamento de acções, permite automatizar totalmente a integração de dados.