Qualidade de Dados / Data Quality

Desta vez vou colocar alguns números provenientes da falta de qualidade dos dados.

Para ser mais simples vou dividir em dois grandes grupos, um apenas com os custos directos que podemos associar à falta de qualidade dos dados e um outro em que juntamos campanhas de marketing directo sobre os dados.

Para este cenário de custos directos e por uma questão de simplificação vamos adoptar um universo de 1 milhão de registos.

Neste 1.000.000 de registos estimamos a existência de um universo de 15% de duplicados, a existência de 5% de moradas em falta e 20% de moradas incorrectas (em muitos casos estes valores até são bastante conservadores).

Por fim vamos assumir um custo de 6€ por hora por trabalhador que até é um valor bastante baixo, porque o calculo dos custos com o trabalhador devem contemplar para alem dos vencimentos e dos custos com segurança social, os custos do "posto de trabalho", como a electricidade, o custo da infraestrutura e todos os outros custos associados directa e indirectamente. Este valor pode assim ser quase que considerado como um valor mínimo.

Se por cada criação de duplicado foram perdidos 2,5 minutos, nos 150.000 registos que foram criados indevidamente, foram gastos 37.500,00€ desnecessariamente. Juntando a este valor o tempo perdido em busca de uma morada correcta, o tempo de correcção de erros de morada, o tempo perdido com queixas de clientes, temos um valor final que facilmente justifica a existência de ferramentas de qualidade de dados. Somando tudo com muita facilidade de consegue chegar às centenas de milhares de €uros. Como tal o ROI de um projecto destes é facilmente comprovado e justificado. Em muitos casos no final do primeiro ano já temos esse retorno.

No link do titulo abre uma página com alguns cálculos, mas tenho um template que com facilidade se conseguem ter valores concretos adaptando aos valores reais de cada companhia.

No próximo post vamos abordar a segunda parte que será o envio de peças por correio, quer sejam peças promocionais, quer sejam peças de envio regular, como extractos ou facturas/recibos.

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.

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.

Nos dias que correm a qualidade dos dados está cada vez mais presente, porque quando as coisas correm bem, não se olha muito para o que corre menos bem, as coisas continuam o seu rumo sem qualquer problema. O pior é quando em fases como a que infelizmente estamos a enfrentar e qualquer pequena dificuldade que até aqui era considerada um pequeno incidente, passa a ter um impacto maior.

Explicando um pouco melhor, se até uma morada errada que gerava um devolvido era considerado um "incidente", agora alguns desses devolvidos são cartas que infelizmente "informam" o incumprimento de alguns clientes e se essa carta é devolvida, significa que a pessoa não foi notificada da sua "falta". Ou seja, se até aqui o que foi devolvido foi uma carta informativa, que tem um custo, mas que era negligenciado, a mesma devolução agora toma uma outra dimensão.

Pior ainda quando estamos a falar não da devolução de uma carta, mas da devolução de 10.000 ou de 100.000 cartas. Algumas empresas estão neste momento a perceber que existem moradas falsas e que não se consegue contactar aqueles clientes. E como agora tudo conta até o custo da devolução dessas cartas é valorizado. Muito rapidamente existe um ROI positivo de ferramentas de address management.

Torna-se por isso importantíssimo, urgente mesmo, a validação das moradas, dos duplicados e de outras acções de qualidade de dados que até agora tinham sido negligenciadas. Mais do que acções pontuais de qualidade de dados é necessário que seja feita a integração de soluções que melhorem, não apenas os dados, mas que impeçam a entrada de "lixo" para o sistema. Quando falo em "lixo" falo em moradas incorrectas ou inválidas, falo em registos duplicados, falo em registos que são erradamente atribuídos por troca de id's e com a não validação do resto da informação.

Depois de um interregno demasiado prolongado devido a falta de tempo, vou tentar voltar à cadencia anterior de colocação de posts, começando por desejar a todos um excelente 2012!

E para recomeçar, nada melhor que falar no novo acordo ortográfico e do impacto que certamente irá ter na qualidade dos dados. Se até aqui a introdução / alteração de dados já era um problema porque cada vez as pessoas escrevem com mais erros ortográficos, com a entrada do novo acordo ortográfico será ainda pior.

Se pensarmos em termos de nomes e de moradas, poderemos estar perante uma receita perfeita para uma autentica "caldeirada". Vão certamente gerar a criação de muitos duplicados, porque vão aparecer muito mais dados inconsistentes que vão aumentar a falta de qualidade nos dados. Nada melhor que dar alguns exemplos dos erros que se podem antecipar.

Em termos de moradas temos um exemplo que é muito frequente e que certamente vai trazer problemas, especialmente quando estivermos a falar na deduplicação, não existindo um programa que consiga contornar estas dificuldades, que é o "c" antes do "t". E são muitos os exemplos, aqui ficam alguns:
Arquitecto <-> Arquiteto
Projectada <-> Projetada
Inspector <-> Inspetor
Recta <-> Reta
Actor <-> Ator
Actriz <-> Atriz
Colectividade <-> Coletividade

Para juntar a estes temos ainda outros que presumo que se mantenham, porque não se vai mudar o nome às pessoas, ou seja um Octávio, não vai ser "renomeado" e passar a ter o nome escrito como Otávio o mesmo acontecerá ao Victor, ao Octaviano e mais alguns. Como tal um "Find Replace" para trocar todos os "CT" por "T" não deve ser de todo a melhor opção.

Se a falta de qualidade dos dados já se fazia notar em algumas bases de dados, esta será certamente a melhor altura para agir, porque daqui para a frente as coisas só podem piorar.