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

Ao ler uma noticia lembrei-me do post inicial onde falava num problema de qualidade de dados na Dinamarca.

O assunto continua em cima da mesa porque muitas pessoas não sabem o que fazer, nem fazem ideia qual é o seu problema. Sabem que existe, sabem que têm de o resolver, mas como... não se faz a mínima ideia.

Neste caso da noticia a informação certamente que existe, os dados estão é espalhados por diferentes sistemas/ plataforma/ ficheiros e ninguém sabe o que fazer para resolver o problema. É supostamente uma operação herculana e com custos enormes para resolver. Nada mais errado.

Em primeiro lugar os dados não devem ser assim tantos quanto isso, estão é duplicados, triplicados... Segundo, depois de reunidos os dados todos (essa sim deve ser a operação mais complicada), em menos de uma semana certamente que os dados estão tratados e um problema que agora tem um custo que nem se consegue quantificar fica resolvido, por uma ínfima parte desse custo.

Quantos sistemas têm registos duplicados com custos enormes para as empresas e que continuam no dia-a-dia a alimentar as bases de dados com mais e mais duplicados? Há bases de dados em Portugal que devem ter mais registos que a população Portuguesa. É suposto? Dificilmente se consegue justificar que tal aconteça, mas há sempre quem consiga.

É sempre fácil dizer que não se faz porque os custos... mas em muitos casos logo após a implementação dos processos de qualidade de dados o investimento já está pago.

Relativamente à noticia em questão, pelo que mostra podem haver pessoas a usufruir de duas ou mais casas e ter até uma delas sub-arrendada e todos nós a pagar. Pode haver um sem numero de casos que apenas depois de se conseguir "arrumar a casa" é que se consegue ter uma noção mais concreta. Mas tal como disse anteriormente este é um dos casos que assim que o processo de qualidade de dados estiver em funcionamento já haverá retorno.

Para terminar vamos desenvolver um pouco o output e como obter esse output.

O resultado final, dependendo do fim pretendido, pode ter várias "formas". Pode ser apenas um ficheiro com os registos duplicados e respectivos masters, pode ser um ficheiro apenas com os limpos ou um ficheiro apenas com os duplicados.

O que o software faz é a criação de grupos de duplicados que com uma chave comum que permite o posterior tratamento das bases de dados como por exemplo, com a alteração dos históricos de todas as tabelas dos registos duplicados para o registo master.

Outro ficheiro final de output é um ficheiro apenas com os "limpos", ou seja todos os registos únicos, sem duplicados e com os masters, ou seja apenas um dos duplicados, que pode ser "eleito" tal como nas prioridades das listas.

Por fim temos o ficheiro final apenas com os duplicados.

De todos estes ficheiros e logicamente salvaguardando usos específicos, o mais importante é sem duvida o primeiro que contém todas as informações fundamentais para tratamento dos dados. Com este ficheiro temos os elementos que nos permitem: complementar um registo, alterar tabelas de históricos entre outros.

Com este post fica completo finalmente o tópico da deduplicação.

No fine tuning da deduplicação temos de ter em consideração o inicio, para encontrarmos o meio de alcançarmos o fim pretendido. Ou seja, temos de saber de onde vamos e para onde vamos. Tipicamente existem 3 tipos de deduplicação a Standard, Overkill e Underkill.

Se falarmos de uma deduplicação normal, a deduplicação standard, depois vamos afinar conforme os resultados que vamos obtendo. Mas podemos ter uma campanha para fazer em que à partida temos 1 milhão de registos, mas sabemos que apenas temos material para enviar para metade desses registos. Como tal poderemos optar por uma deduplicação overkill e dessa forma vamos de forma aleatória ou não, remover registos que à partida não deveriam ser considerados como duplicados, mas como temos excesso de registos, podemos "correr o risco".

Por outro lado, temos uma base de dados que deve ser enviada uma comunicação mesmo para todos os indivíduos, mesmo que um individuo receba mais que uma comunicação, é preferível que haver algum que não receba. Optamos por uma deduplicação underkill, que desta forma a segurança dos duplicados é de 100%.

Em qualquer uma destes tipos de fine tuning, podemos ajustar parâmetros de forma a conseguirmos os melhores resultados, ou aqueles que mais se ajustam ao nosso objectivo final.

Esses parâmetros são as comparações executadas nos campos que podem ser comparações Fonéticas, de Similaridade, Equalização (Código Postal), Proximidade (Numero de porta) e Sinónimos.

Fonéticas o próprio nome é esclarecedor, de similaridade é tomada em conta uma série de factores como por exemplo um V e um U, se estivermos a visualizar algo manuscrito pode facilmente ser similar. Como tal, neste campo podemos aumentar ou diminuir o valor conforme a origem dos dados.

Equalização é usado especialmente no código postal. Temos em Lisboa códigos postais que vão do 1000-001 ao 1990-999, e muitas vezes como não se sabe o código exacto coloca-se simplesmente 1500-000. O que vai acontecer aqui é que todos os registos de Lisboa vão ficar com o mesmo código postal: 1000-000. Desta forma ajuda a encontrar duplicados, mesmo que não tenha sido possível fazer a normalização de algum registo.

Relativamente à proximidade um dos exemplos são os números de porta ou números de telefone. Pode haver pequenas diferenças por exemplo no numero de telefone e assim é possível também encontrar esses registos independentemente de pequenas diferenças nos números que possam existir.

Finalmente temos os sinónimos cujo nome também é esclarecedor.

Está complicado acabar este tema, mas está quase.

Neste post vou descrever os diferentes tipos de listas que são possíveis de deduplicar.

Tal como tinha dito no post inicial existem as listas Standard, Externas, Negativas e de Enriquecimento.

As listas Standard são as "nossas" listas, aquelas onde vai incidir o tratamento. Podemos ter uma ou várias listas com prioridades entre elas. Vamos assumir que temos a lista com os clientes da empresa, mas entretanto surgiram outras pequenas listagens de outros clientes porque foi feita a incorporação de outras empresa, ou seja passam a ser nossos clientes também, mas para que se possa ter uma noção concreta do valor desses clientes vamos fazer a incorporação dos mesmos numa listagem única e deduplicada.

Podemos então dizer que os clientes existentes têm prioridade máxima e prioritizar todas as outras listas. Dessa forma no final na listagem de duplicados o master dos duplicados será sempre aquele com a prioridade mais elevada.

O mesmo relativamente às listas externas, que como o nome indica são listas que são por exemplo registos do departamento financeiro e que queremos comparar com os registos do marketing, porque não existe integração entre as duas ferramentas. Mais uma vez as prioridades aqui são válidas.

Um pouco como estas listas externas temos as listas de Enriquecimento que são listas que contêm dados que necessitamos de incorporar nos nossos dados, mas que estão noutras listagens. Por exemplo termos uma lista de clientes sem numero de contribuinte e o departamento financeiro ter uma lista com os NIF's de todos os clientes. Vamos por isso enriquecer a informação inicial com os NIF's dos clientes.

Por fim temos as listas negativas que propositadamente deixei para o fim. Aqui temos os Robinson (pessoas que pediram para não serem contactadas novamente), os "terroristas" e por exemplo os devedores.

Quando se fala de terroristas é mesmo no pior sentido da palavra, mas essa temática já a desenvolvi em outros posts como por exemplo neste.

Vou finalmente iniciar pelos tipos de deduplicacão.

O mais habitual é a deduplicacão por indivíduo. Para a execução destas deduplicacões são utilizados os campos que possam de alguma forma distinguir os indivíduos entre si. Toda e qualquer referência pode e deve ser usada. Partindo dos mais comuns como o nome, morada, data de nascimento, BI, mas tudo o que possa ajudar a distinguir indivíduos pode ser utilizado, emails, telefones fixos ou móveis, tudo o que nos possa tornar únicos ou que nos possa distinguir de outros pode ser importante para uma deduplicação.

O output final deste processo será um ficheiro com uma chave que identifica os registos que são duplicados, ou que suspeita que sejam duplicados e uma percentagem de match entre eles. Ou seja, no exemplo abaixo encontramos um grupo de duplicados (234) que é composto por 3 registos em que 2 são precisamente iguais e existe um com uma percentagem de match de 80%.

Estes valores são meramente exemplificativo e não servem de referência porque dependendo dos pesos que forem colocados a cada um dos campos, teremos valores diferentes. Esses acertos que são uma das fases mais complicadas da deduplicação por norma é diferente de BD para BD. Existem as deduplicações genéricas, mas depois para termos maior precisão são necessárias várias tentativas para conseguirmos o ponto óptimo.

Para além da deduplicação normal por individuo podemos ter por household, ou seja conseguirmos ter a noção de quantas casas temos em BD, independentemente de termos o pai, a mãe e os filhos como nossos clientes, se necessitarmos de enviar uma comunicação dispendiosa para os clientes, podemos enviar apenas uma por casa, tendo essa indicação.

Estes são dois dos exemplos, mas podemos ainda ter a deduplicação por quadro de empresa, para além de deduplicações de outro tipo, tudo o que seja passível de ser deduplicado.

Desta vez vou iniciar uma série de post's relativos à deduplicação (foi este o termo que "aprendi" a usar e que uso com mais frequência) em modo batch.

Existem alguns acrónimos que por vezes importamos do Marketing para designar as diferentes deduplicações existentes, mais usualmente utilizadas. B2C, B2B e B2H, significando deduplicação por Individuo, por Empresa e por Household. No caso da deduplicação por Empresa pode ter incluída a deduplicação com individuo ou não.

Quanto às listas que podem ser incluídas nestas deduplicações, existem as listas Standard, Externas, Negativas e de Enriquecimento.

Depois podemos ter "afinações" diferentes em cada uma das deduplicações: Idênticos, Standard, Overkill e Underkill.

Dentro de cada uma destas "afinações" temos para cada campo várias formas de comparar os registos: Fonéticas, Similaridade, Equalização (Código Postal), Proximidade (Numero de porta) e Sinónimos.

Por fim temos as Listas de saída, numa deduplicação podemos gerar um ficheiro com os Limpos, um ficheiro com os duplicados e um ficheiro com a lista dos duplicados que inclui para alem dos duplicados os Master's desses duplicados.

Como resultado teremos vários tipos de registos: Único, Mestre, Duplicado e Ambíguo.

O registo Mestre pode ser definido por prioridade, que pode ter como origem: Categoria ou Prioridade da lista, Prioridade ou Completude do registo ou simplesmente pela ordenação.

Tudo assim de seguida pode parecer uma grande confusão, mas vou nos próximos posts desenvolver cada um dos pontos anteriores.

Tal como terminei o ultimo post vou continuar neste com uma noticia recente e que nos pode ajudar a mostrar um pouco a dificuldade que há na criação de métricas para aferir os danos na imagem de uma empresa.

Como muitos puderam ver na TV, existem várias queixas de carros de uma marca de topo que simplesmente arderão. Uma vez que a marca nunca conseguiu dar uma resposta definitiva, a dúvida vai manter-se e ainda que seja dada uma explicação cabal para todos os acontecimentos, esta imagem vai sempre pairar sobre os possíveis compradores de carros da marca. Tanto nos novos compradores da marca como nos que já são clientes e que querem trocar de carro, MAS existe uma dúvida que paira no ar.

Esta é talvez uma das formas mais evidentes de se demonstrar que mesmo que se prove de forma inequívoca que os acontecimentos não são responsabilidade da marca, a imagem pode ficar afectada. Há mesmo algumas marcas que ainda hoje sofrem porque existiu um produto com baixa qualidade e por muito que tenham feito para dar a volta a essa imagem, é muito complicado convencer totalmente todo o mercado.

O problema é a quantificar estes valores e é igualmente complicado quantificar os custos de imagem quando se enviam peças em duplicado, pela existência de registos duplicados, pela devolução de cartas que podem ser muito importantes para os clientes, mas que não chegaram ao destino. Até mesmo na prevenção de fraude com a inserção de moradas inexistentes, evitando assim desperdiçar dinheiro em envios de peças promocionais por vezes bastante caras, para moradas inexistentes. No próximo post vou falar continuar a falar do ROI da qualidade de dados.

Depois de uma interrupção, vou tentar retomar um ritmo de posts mais constante.

Existem uma série de questões que são recorrentes acerca do tema da qualidade dos dados, uma delas é o custo dos projectos de qualidade dos dados vs retorno do investimento.

Os custos dos projectos de qualidade de dados podem ser muito rapidamente recuperados, se forem executados de forma correcta e principalmente de forma empenhada por toda a organização. É uma questão transversal a toda a empresa e que requer a atenção em todos os níveis da pirâmide organizacional. A recuperação financeira do investimento feito com um projecto de qualidade de dados, em muitos casos é facilmente mensurável, mas em muitos outros pode ser difícil de quantificar, porque alguns valores podem não ter valoração mensurável de forma directa.

Relativamente aos que são mensuráveis, temos aqui um pequeno exemplo onde o valor de recuperação de 20% entre registos duplicados e devolvidos está certamente muito abaixo do que será um valor "atingível", mas mesmo com um valor de referencia baixo as economias de custos são consideráveis.

O mesmo exemplo anterior pode ser usado para os que não têm valores mensuráveis. Clientes que recebem comunicações duplicadas por estarem duplicados na base de dados e os clientes que não receberam a comunicação por ter sido devolvida. Estes custos são custos de imagem, que podem custar clientes e que não podem de forma nenhuma ser quantificados porque não há forma de os quantificar, porque as reacções dos clientes podem não ser imediatas e mais que isso muitas vezes não há uma explicação do afastamento de um determinado cliente.

Como tal um projecto de qualidade de dados é facilmente recuperável em termos de investimento, o espaço temporal necessário é que é mais difícil de medir, podendo em alguns casos ter recuperação praticamente imediata.

São várias as procuras que aqui chegam com as keywords "definição/conceito de qualidade de dados/data quality". A qualidade de dados não é um atributo que se consiga definir com um simples sim ou não. É composto por vários parâmetros, uns mensuráveis outros totalmente subjectivos e todos eles podem ser alterados de empresa para empresa, embora existam alguns pontos que são comuns.

Como tal, alguns dos atributos que são mais usados quando se fala de qualidade de dados, são:
- Validade e integridade, os dados existentes estão correctos?
- Acessibilidade, quando são necessários os dados estão disponíveis, ou é necessário fazer vários pedidos até se poder ter acesso aos dados?
- Cobertura, os dados cobrem todos os aspectos do negócio? Podem existir valores absolutos, mas também podem existir valores relativos.
- Pontualidade, Os dados estão sempre disponíveis ou é necessário esperar algum tempo pela sua disponibilização?
- Contexto/Precisão, os dados reproduzem com precisão o que é suposto descreverem?
- Confiabilidade, a todo o momento pode haver confiança nos dados, ou existe alturas do ano em que essa confiança é maior e outras alturas em que é menor?
- Integralidade, os dados contêm toda a informação relevante?

Relativamente a estes atributos, são válidos para praticamente todos os tipos de dados de todos os tipos de industrias, mas aqui e por uma questão de facilidade, vou "puxar a brasa à minha sardinha" e vou centrar os exemplos na área onde tenho maior experiência e maiores exemplos, as moradas e as deduplicações.

Iniciando pela Validade e integridade dos dados, as moradas são um dos casos em que o problema é precisamente esse. Em Portugal muitas empresas têm em muitos registos apenas os 4 dígitos do código postal ou com os 3 últimos dígitos apenas com 000 ou com 999, e muitas vezes com problemas ainda maiores, que já dei como exemplo casos que agora me têm surgido com alguma regularidade, é com 4 dígitos que nada têm a ver com o Endereço Postal. Tenho pelo menos dois fornecedores que neste momento têm na minha morada pessoal, algo como, 2675 LISBOA, tal como dito num post anterior, o mais certo é que, infelizmente, isto foi resultado de um processo de qualidade de dados falhado.

A Acessibilidade é um dos pontos subjectivos. Apenas no dia-a-dia das empresas se pode ter noção da existência/inexistência de problemas de acesso a dados. Embora em algumas organizações seja muito fácil detectar estes problemas. Ainda não há muito tempo estava numa repartição publica e ficou tudo parado porque a pessoa que estava a ser atendida, não sabia o seu código postal e o funcionário não tinha acesso aos códigos postais.

Cobertura é outro dos aspectos subjectivos na maior parte dos casos. Um dos exemplos mais simples é a distribuição geográfica das áreas de negócio. Existem distribuições por Distrito, outras por Concelhos, outras por código postal e é aqui que muitas vezes os problemas de cobertura podem surgir. Novos códigos postais que surgem com novos clientes, podem não estar associados a nenhuma zona.

Quanto à Pontualidade está relacionada não apenas com a acessibilidade como também com a duplicação de registos que existem. Quantas vezes já aconteceu dentro da organização ser necessário uma contagem de registos de uma zona especifica do país e não ser possível fazer essa contagem? Ou porque os dados estavam incorrectos porque essas zonas não estavam atribuídas a todos os registos, ou porque existiam muitos registos duplicados.

Contexto/Precisão, um dos exemplos é o campo da morada que em muitos casos contem outras informações fora de contexto, como o contacto (exemplo: "entregar à D. Alexandra"). Em termos de moradas é possível ter uma noção da precisão dos registos. Dependendo do software, deverá existir um campo em que está colocada a precisão da normalização efectuada e com este campo poderemos saber qual a percentagem total de dados que está normalizado. Temos em Portugal com os nossos softwares clientes a trabalharem com percentagens de qualidade acima dos 93%, o que é um valor excelente. Logicamente que o objectivo é aproximar-mo-nos mais dos 100%, embora sabendo que esse valor é impossível de atingir. Casos como moradas "Casa amarela ao lado da escola Primária" não há street file que resista a estes casos, não sendo como tal possível ter um valor de qualidade como correcto, embora seja um registo que é entregue sem problemas.

Relativamente à Confiabilidade um dos exemplos que me é mais familiar, é se houver a necessidade de enviar uma carta urgente de extrema importância para o cliente, mas não há a certeza que a morada está correcta, porque apenas tem o código postal de 4 dígitos e não se tem a certeza que a morada existe e se a carta irá chegar ao destino. O mesmo relativo aos duplicados, imaginemos um caso extremo em que existe uma queixa já em tribunal de um cliente, mas como existem dois registos em base de dados vai ser feito um contacto com o cliente para lhe oferecer o mesmo produto que motivou a queixa, mas com os dados do outro registo, sem que se tenha noção dessa queixa. Desse momento em diante esse departamento nunca mais vai ter confiança nos dados.

A Integralidade está um pouco relacionada com os pontos anteriores, em que se for necessário por exemplo aceder aos dados de um cliente até que ponto se pode ter a certeza que os dados existentes são de confiança e estão completos. Imaginemos que existe uma queixa por parte do cliente que entretanto já foi resolvida, mas ainda não foi lançada no sistema e é necessário fazer um contacto. Não havendo dados no sistema e não tendo a certeza que essa resolução foi executada com a satisfação do cliente, esse contacto vai ser um contacto sempre feito a medo.

No próximo post vou tentar mostrar como podemos minimizar ao máximo estes problemas.

Lucre com todas Soluções de Qualidade de Dados da Uniserv para e-commerce e portais da Internet, incluindo:

• Óptima qualidade dos dados através do acompanhamento permanente na criação inicial de dados e alterações (Data Quality Firewall)
• Revisão confiável dos dados (Data Cleansing) de acordo com as regras definidas e combinando-a contra os dados de referência (por exemplo, endereço, dados geográficos, o índice de número de telefone) no processamento em batch ou em tempo real.
• Entregas rápidas e confiáveis de bens com os clientes satisfeitos, criando laços fortes.
• Baixa os custos de postagem para correspondência em massa por meio de dados de alta qualidade endereço
• Extensas análises do comportamento do consumidor para o uso eficiente dos potenciais upselling e cross-selling numa base up-to-date, corrigida e livre de clientes duplicados e de dados de transacções fiável.
• Fluxo de caixa com receitas de confiança, planeável e uma minimização dos riscos de atrasos nos pagamentos ou não pagamentos por meio de dados precisos de pedido e de clientes

Qualidade de Dados no e-commerce mantém o fluxo de caixa em movimento

As aplicações de negócios em e-commerce ou aplicações Web portal têm uma grande diferença de outras aplicações de negócios: a operação e entrada de dados são realizadas directamente pelo cliente ou potencial cliente e não por pessoal treinado. Erros de entrada - intencionais ou acidentais - são uma ocorrência diária. Esses erros afectam a qualidade dos dados e podem ter um impacto significativo nas transacções rápidas, sem sobressaltos e num fluxo de caixa confiável.

DESAFIOS
Endereços incorrectos ou não entregues - os custos sobem, as vendas caem

Existem muitas razões para a existência de endereços incorrectos ou não entregues. Todos têm uma coisa em comum: custos adicionais desnecessários e perda de vendas para as empresas de catálogos por Internet e os operadores das lojas online com entregas pelos correios.

• Evitar erros de digitação que evitem que a mercadoria chegue ao cliente fazendo com que haja elevados custos de pesquisa adicional. Descontos nos portes postais podem ser reduzidos ou cancelados pelo transportador porque os mails em massa incluem um grande número de endereços incorrectos.
• Erros de entrada de dados causados por máscaras de entrada incertas ou não disponíveis que tornam mais difícil a entrada correcta ou forneçam dados de forma incorrecta - este é um problema particular em aplicações internacionais, com estruturas de endereço diferente. Estes têm de ser limpos manualmente com um alto investimento de tempo e custos operacionais. A satisfação do cliente e retenção de clientes também são afectados.
• Entradas incorrectas deliberadamente (endereços fictícios) iniciando processos de expedição, que custam dinheiro e que tem de ser revertido com grande esforço.
• A mercadoria não pode ser entregue como resultado de endereços antigos que não são actualizados pelo cliente, gerando altos custos para devolução e reenvio.

Duplicados - custos adicionais desnecessários, não utilizando up / cross-selling
Vários registos de dados (duplicados) também são problemáticos:

• Logons aos portais da Web são executados sem querer várias vezes e levam à duplicação de dados.
• Criação intencional de novas contas, por exemplo, para comentários indesejados ou ilegais em fóruns, auto-promoção, SPAM ou pedidos que são regularmente não aceites ou não pagos.

Eles não só causam custos para a limpeza dos dados, mas também falsificam a visão única do cliente. Análises por exemplo, em aplicações de CRM são executadas mais dificilmente, e potenciais upsellings e cross-sellings não podem ser usadas de forma rentável.

A qualidade dos dados faz o seu Customer Relationship Management (CRM) mais eficaz

Fortalecer o relacionamento com os clientes existentes e angariação de novos clientes de forma rentável, é o alfa e o omega para garantir uma fatia maior do bolo das vendas. A base para isso é um Customer Relationship Management (CRM) forte com os dados do cliente correctos e completos, que possam ser usados no marketing, vendas, call centers e serviço pós-venda, mas a qualidade dos dados é precisamente onde a porca torce o rabo em muitas empresas.

Endereços incorrectos - vendas menores, custos maiores
Endereços de correio não entregues fazem com que campanhas de mailing descarrilem e causam custos desnecessários com portes e pesquisas. As facturas não podem ser entregues, o que resulta no não-pagamento, para não mencionar a perda de oportunidades de vendas, porque a sua mensagem promocional não atingem os potenciais compradores.

Duplicados - clientes insatisfeitos, planeamento incerto, up / cross-selling não são utilizados
Vários registos de dados (duplicados) são, possivelmente, ainda mais problemáticos:

• Os importantes dados dos clientes estão incorrectos durante uma chamada de serviço ao cliente. O cliente fica desapontado e pode ir para a concorrência. Perda nas vendas são o resultado inevitável aqui.
• O planeamento de vendas e marketing sofre, porque duplicados evitam uma classificação automática e correcta de clientes e exigem uma correcção manual cara.
• As previsões são distorcidas, o que pode levar a decisões de negócios atrasado ou incorretas que atingiu a sua empresa rígido.
• A selecção de endereços para as campanhas de marketing torna-se extremamente complicada, que é por isso que só consegue colocar suas ofertas depois da concorrência.

Falta de confiança - o sinal de partida para ter cada vez uma qualidade dos dados mais pobre
A prática tem demonstrado que, se os utilizadores não podem aceder às informações necessárias no sistema de CRM de forma rápida e com alta qualidade, a quantidade de cuidados tomados durante a entrada de dados e manutenção é normalmente reduzida. O resultado é uma espiral descendente de uma diminuição constante da qualidade dos dados, que só pode ser interrompida por um completo - e caro - relançamento do sistema de CRM, num caso extremo. Não deixe as coisas chegarem a esse ponto e começar a fazer o processo de melhorias necessárias antes que seja tarde demais.

As opções extensas do DQ Batch Suite são especialmente convincentes. A Uniserv oferece aos utilizadores do DQ Batch Suite uma solução de TI com definições de trabalho integrado, que podem ser adaptados às necessidades de negócio existentes como característica standard. Estes incluem tarefas como a validação, correcção, actualização e aprimoramento de endereços e dados. Todos os processos e operações podem ser facilmente manipulados intuitivamente numa interface gráfica de utilizador.

O novo Hostconnector para o DQ Batch Suite significa que este está agora disponível para os utilizadores do sistema mainframe z /OS. Aqui a master data é mantida no host, como de costume, enquanto o Job Control Language cuida das transferências de dados entre o host e o DQ Batch Suite e controla as operações de processamento no DQ Batch Suite.

Isso significa o seguinte para os utilizadores do z/OS:

• Disponibilidade das funções de qualidade de dados do DQ Batch Suite para a master data no mainframe - portanto o uso contínuo de novos produtos, versões de outros países, até mesmo uma melhor qualidade de deduplicação em processos batch
• Nenhum trabalho de apoio in-house por parte do utilizador - Os processos fundamentais permanecem no mainframe
• Grande facilidade de uso - definição das operações de tratamento por meio da interface gráfica do utilizador.
• Alivio do sistema host das operações de processamento de batch de grande intensidade, por exemplo em períodos de pico de carga.
• ganho de flexibilidade para o trabalho de programação e economia no uso de recursos do host
• Uso dos fluxos de processos de alta performance do DQBT em sistemas Windows e Unix

Se tiver alguma dúvida sobre a interface batch DQ Hostconnector da Uniserv, entre em contacto connosco!

Circulante aos processos de qualidade de dados
Alta qualidade de dados é critica para o sucesso da sua empresa, independentemente de pertencer ao sector industrial ou comercial e das suas aplicações.
É importante ainda que se diga que não se deve esperar por uma actualização anual porque necessitamos todos os dias de ter os dados actualizados e não apenas uma vez por ano. Uma gestão de qualidade consistentemente tem como objectivo permanente submeter a verificação da qualidade dos dados num ciclo em que há uma verificação automática, matching, enhancing e possível consolidação dos dados logo no input.

Construa uma firewall de qualidade de dados
O modo mais eficaz e eficiente de eliminar problemas de qualidade de dados é a prevenção antes que os problemas surjam. Contaminação "rastejante" dos dados pode ser evitada com a implementação de verificações de qualidade directamente nos pontos de entrada no sistema. O utilizador recebe feedback directo dos problemas e pode directamente intervir nos casos em que uma intervenção automática não seja possível.

Para alem de verificar se os dados estão completos e de uma validação contra listas de referencia, a manutenção permanente deve ser providenciada verificando todos os inputs contra os dados existentes na base de dados de forma a prevenir o aparecimento de duplicados. Dependendo do modelo de negocio, complementar com dados internos ou e externos é igualmente recomendado.

Encontrar em vez de procurar
No dia a dia do negocio, pedidos de informações de clientes, o serviço ao cliente ou a aceitação de pedidos via telefone, frequentemente geram situações, em que as informações do cliente e do fornecedor, dados de conta ou de contrato tem de ser acedida rapidamente e com segurança sem que existam referencias disponíveis. No que diz respeito a isto o desafio é encontrar dados específicos numa base de dados, ainda que em grande parte dos casos apenas informação parcial está disponível ou que a soletração seja pouco clara.

O DQ Real-Time Services da Uniserv fornece-lhe a informação necessária no pressionar de um botão, mesmo que as palavras de procura estejam incompletas, imprecisas ou incorrectamente soletradas. No fim de tudo, o seu staff deve ser especialistas nos seus processos de negocio e não na procura em bases de dados.

Qualidade de dados e e-Business
O input de dados incorrectos e incompletos é uma questão recorrente em e-Business. Atenção especial deve ser prestada a este aspecto da qualidade de dados num ambiente no qual os clientes colocam eles próprios os seus dados. Frequentemente apenas dados abreviados, desestruturados ou dados totalmente incorrectos são introduzidos, ou ainda com erros não intencionais de digitação.

Funções adequadas para garantir a consistência da qualidade dos dados não foi ainda integrada nas aplicações web de muitas empresas. Isto é indispensável, contudo, porque o sucesso do negócio online anda de mãos dadas com a qualidade dos dados.