Qualidade de Dados / Data Quality

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.

Depois de ter intercalado com o "placebo", volto ao tema dos custos com a qualidade dos dados, tal como prometido.

Numa simulação simples, continuando com o universo de 1 milhão de registos, e mantendo os mesmos pressupostos anteriores, ou seja:
- 15% de duplicados
- 5% de moradas em falta e
- 20% de moradas incorrectas.

Tendo como base um o custo de 0,25€ por cada peça enviada e um custo de envio de 0,25€, nestes 400.000 registos que são enviados "indevidamente", existe um custo total de 200.000€ por cada envio. Se nestes conseguirmos uma redução de 25% (presumivelmente, valor fácil de atingir) teremos uma redução de custos de 50.000€. Mas se tomarmos em consideração que com o tratamento de moradas, conseguimos assinalar as moradas que podem não estar totalmente correctas, poderemos ainda ter reduções mais significativas.

Como se pode ver pelos valores da taxa de leitura automática para descontos nos CTT os valores "normais" rondam os 60 e os 70%. Dos 70% para cima já é considerado um valor bom, tendo já direito ao desconto máximo, no caso em análise estamos com um erro de moradas a rondar os 25% ou seja já com o desconto máximo logo à partida. Mas em muitos casos certamente que não é esta a realidade, sendo possível aqui ter uma poupança considerável porque o desconto é de 1% entre os 60 e os 70% e de 3% acima dos 70%.

Relembrar apenas que o valor que considerei está longe dos 0,47€ que custa o envio de uma peça em formato normalizado até 20g. Seria necessário um desconto de quase 50%.

Juntando estes valores com os valores anteriores e a questão que fica é apenas porque é que a qualidade dos dados continua em muitos casos a ser negligenciada.

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.

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.

Parece que agora que os dados são mais requeridos a falta de qualidade e de ferramentas de controle de qualidade dos mesmos está a vir ao de cima. Aqui fica mais um exemplo da falta de qualidade, neste caso num banco.

Provavelmente, o que aconteceu foi que o Steve Smith se inscreveu numa campanha e como não estava para dar o nome coloca a expressão "F*** Off". O nome não aparece do nada, não é o "sistema" que coloca um nome. Caso tivesse havido trocas de nomes, não seria apenas ele a queixar-se mas provavelmente vinham as cartas todas devolvidas. Os nomes não iriam corresponder com as moradas.

Mas o que isto mostra é que a qualidade dos dados não foi assegurada e só assim se compreende que tal aconteça. Se por um lado ter qualidade nos dados tem custos, os custos directos e indirectos de não se ter qualidade nos dados é sempre muito superior como se pode ver neste caso.

Como custos directos há um futuro cliente que deixou de o ser, não se sabe se com ele vai arrastar mais clientes seus amigos e qual o "custo" que isto vai trazer para a empresa, é impossível saber. Mas para alem desses custos, há os custos de imagem, que esses são ainda mais difíceis de estimar.

Neste caso, para alem do impacto nos relacionamentos directos e indirectos da pessoa lesada, teve impacto em todos os que leram o jornal e eventualmente em muitos dos relacionamentos destes.

Como se pode evitar que isto aconteça? Simplesmente com normais procedimentos de qualidade de dados, que permitem identificar palavrões nos nomes e moradas. Esta é uma das funcionalidades que um projecto de qualidade de dados deve contemplar.

Juntando este post com o anterior podemos ver que a qualidade de dados engloba muitas vertentes, a verificação, a correcção, a deduplicação