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.

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.

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.

Uma discussão interessante que vai surgindo é o que é mais importante, se a Qualidade dos Dados (Data Quality) ou se Business Inteligence.

Antes de mais considero que a Qualidade de Dados deve existir mesmo sem BI, mas BI não deve existir sem Qualidade de Dados. Se tivermos uma base com dados de qualidade, normalizados, deduplicados, completos e precisos, certamente que com grande facilidade se retira informações pertinentes desses dados, mesmo sem ferramentas de BI. Ao contrario, se tivermos as melhores ferramentas de BI do mundo, mas a base de dados está sem qualidade porque os dados não estão normalizados, existem duplicados, os dados estão incompletos e são pouco precisos, nunca se conseguirá tirar informações válidas dessa informação.

No final e em conclusão não se deve fazer a discussão qual das ferramentas é mais importante, mas pelo contrário o que se deve é somar uma com a outra para que se possa assim ter melhores resultados. As ferramentas de DQ muito úteis, mas apenas em conjunto com as ferramentas de BI se consegue ter os melhores resultados, tal como o inverso também é válido. As ferramentas de Qualidade de Dados podem não ter resultados apresentações tão bonitas para enviar aos quadros superiores das empresas, podem até passar totalmente despercebidas em alguns casos, mas são fundamentais para se conseguir ter os melhores resultados.

Como ponto de partida temos de dividir os esforços para melhoramento da qualidade de dados entre projectos e soluções.

Nos projectos poderemos ter custos que dificilmente se consegue encontrar benefícios para eles, ou porque os projectos são mal concebidos, complexos e falham o ataque às causas da má qualidade dos dados.

Tradicionalmente as soluções de melhoramento de qualidade de dados têm retorno no investimento e impacto na organização com o aumento nos lucros tanto no aumento da facturação, como na redução de custos e redução de riscos vários.

Quando por exemplo num call center se reduz o numero de teclas necessárias para ter uma morada válida, ou para se encontrar um registo, isso tem um retorno visível e praticamente imediato nos custos. Se no final do dia se conseguir atender mais 10% das pessoas por que as ferramentas de qualidade de dados ajudaram na velocidade de atendimento, isso é facilmente detectável nas métricas do call center.

Por outro lado se nos devolvidos das campanhas, tivermos uma taxa de devolução reduzida relativamente aos dados anteriores, também representa valores mesuráveis e que ajudam a validar a implementação destas soluções.

Muitas vezes perguntam como consegue aferir a qualidade dos dados das empresas. Existem algumas ferramentas que o possibilitam, mas existe uma forma ainda mais simples. Ordenar os diferentes campos que compõem a base de dados e normalmente os erros aparecem de forma "natural". Provavelmente no campo do código postal podem aparecer em alguns casos códigos postais tipo "0000-000". Caso o sistema já esteja preparado para evitar estes casos podem existir muitos "X000-000" ou "X000-999". Os utilizadores encontram sempre forma de "dar a volta" ao sistema.

Por outro lado, ordenando os campos código postal e morada, vão encontrar muitos erros nas moradas, que estão escritas de formas totalmente distintas. Ruas como a Rua Calouste Gulbenkian devem existir versões de todas as formas. E é aqui que existe a distinção entre os projectos e as soluções de melhoria de qualidade de dados. Num projecto no dia seguinte os dados estão correctos, mas uma semana depois já existe "lixo" no sistema. É que se na Rua Calouste Gulbenkian pode não criar muitas duvidas na entrega da correspondência existem outros exemplos em que a escrita pode ser totalmente impeditiva da entrega da mesma.

Não estou com isto a dizer que os projectos de qualidade de dados não devem ser feitos, estou sim a dizer que devem ser complementados com a implementação de soluções de qualidade de dados. Apenas assim conseguimos assegurar a manutenção da qualidade dos dados e mais que isso, a redução dos custos.

Depois de uma semana um pouco complicada, aqui estou de volta já praticamente curado e com novidades.

Já está disponível o novo formulário para os testes online, embora ainda não esteja totalmente optimizado, ainda estamos com problemas com a ligação ao Google Maps.

Novidade mesmo é que agora se pode alterar o país de origem da morada que se quer normalizar directamente.

Estão disponíveis todos os países, embora com níveis de normalização totalmente diferentes. Logicamente que o ficheiro de arruamentos de Portugal é muito mais completo que o do Burkina Faso.

Nestes últimos dias tenho recebido de algumas de empresas, das quais sou cliente pedidos de actualização de morada e cartas com moradas que me fazem aumentar algumas preocupações.

Dos exemplos que tenho comigo, são 2 cartas, que só não foram devolvidas por "carolice" do carteiro, e uma outra empresa que me pede para reenviar os dados da morada, sinal que ou os perderam, que acho estranho com os processos de backup existentes e que as grandes empresas por norma têm, ou depois de um processo de qualidade de dados, com um normalização /tratamento /higienização de moradas, como lhe queiram chamar, foram adulterados de tal forma que já não é possível que as cartas cheguem ao destino.

Isto preocupa-me duplamente porque se por um lado existem empresas que estão a tratar os meus dados desta forma, a outra preocupação é a imagem que estes falsos processos de normalização /tratamento /higienização vão deixar nas empresas que os fizeram. Isto porque alguns destes até são executados por empresas bem cotadas na nossa "praça".

Como fiz a adaptação de um software para Portugal, sei quais são as principais dificuldades com que nos fomos deparando ao longo desse processo e que vou tentar aqui resumir um pouco para que se possa ter noção do porquê da existência destes problemas. Já lá vão mais de 10 anos mas até aqui pouco mudou. O que existia eram bases de dados de moradas com o histórico de erros. No que consiste esta técnica? Cada vez que se encontra uma rua escrita de forma diferente, essa forma é anexada ao histórico e na próxima vez que surja é corrigida automaticamente. Logicamente que isto é um processo muito complicado e muito falível, como tal não seria uma solução para o problema, mas um remendo. Existia a hipótese de desenvolver internamente uma ferramenta, mas se a roda já foi inventada... Como solução existia a colocação de ferramentas internacionais, mas aí chegados outros problemas surgiram:
- A primeira dificuldade encontrada aquando da busca de um software no mercado internacional foi a disponibilidade de adaptação à realidade Portuguesa. Se por um lado temos especificidades que não se encontram em mais nenhum país da Europa e algumas mesmo do mundo, por outro temos uma dimensão de Portugal que nem sempre permite às grandes multinacionais investir uma vez que podem não ter grandes possibilidades de retorno.
- A falta de informação existente em Portugal relativa a esta matéria. Não existe um organismo ou instituição responsável pelas moradas em Portugal. Assistimos a "crimes" como a numeração que foi colocada na zona da Expo, que não se compreende como é possível num país europeu se permite que tal exista na sua capital. Somos talvez o unico país na Europa que tem na mesma localidade a Rua, Travessa e o Largo da Liberdade entre muitos outros.

Por tudo isto e muito mais, o que recomendo é que antes de investirem em processos de normalização/ tratamento / higienização de moradas, é que peçam um teste a um numero razoável de dados, numero que apenas possa tratado de forma automatizada.

Desta forma, consegue-se separar o trigo do joio, uma vez que já existem algumas empresas a apregoar a normalização /tratamento /higienização de moradas, mas que tem por base pseudo-ferramentas desenvolvida em cima do joelho e que são testadas com os dados dos clientes, com todos os problemas que isso acarreta.

Para finalizar tenho ainda que esclarecer a diferença entre vários conceitos que andam misturados neste tema.

Normalização de dados: A normalização de dados é uma definição um pouco subjectiva. Se por um lado poderemos considerar a Normalização de dados como todo o processo qualidade de dados, existe ainda quem pense que a normalização de dados é colocar todas as Ruas como R., todas as Avenidas como Av. etc.
A normalização /tratamento /higienização de moradas é mais que isso, este processo até acaba por ser o processo mais simples. O mais complicado é a parte da comparação/correcção da morada com o ficheiro de arruamentos de referencia. Aqui sim existem inúmeros problemas que podem surgir. Como exemplo, ruas Alfredo da Costa em Sintra existem 3 ruas diferentes, se não existir um software preparado para estas situações, o mais certo é haver problemas no final.

Como tal, volto a alertar para o teste dos softwares antes de colocarem os dados dos Vossos clientes em risco. São poucas as empresas que têm confiança no seu software, de forma a colocarem no site um demo do mesmo.

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

O Data Quality Solutions modular da Uniserv ajudá-lo-à a transformar o Customer Relationship Management num factor de sucesso para a sua empresa com dados correctos, completos e livres de duplicados em vez de ser um causador de custos.

As soluções da Uniserv aumentam o sucesso do CRM analítico, operacional, de comunicação e colaboração. Soluções especiais B2B e B2C asseguram a aplicação eficaz das suas necessidades específicas. E mesmo se você usar um eXtended Relationship Management System (xRM) em vez de um sistema convencional de CRM, as soluções mensuráveis da Uniserv oferecem-lhe um valor acrescentado para os seus dados e processos.

Data Quality Batch Suite para CRM: A suite completa de produtos para a verificação em batch totalmente automatizadas e limpeza de dados de clientes em sistemas de relacionamento com o cliente.

Data Quality Real-Time Services para CRM: Para obter qualidade de dados dos seus registos directamente na entrada dos dados e na alteração de dados de clientes em sistemas de CRM.

A nossa contribuição para o seu sucesso no CRM: Pesquisa rápida, tolerante ao erro, o reconhecimento automático de duplicados e de agrupamentos de dados por nome e morada, validação de dados e aumento ou sincronização com outros sistemas são apenas algumas das funções do DQ Batch Suite e do DQ Real-Time Services - a nossa contribuição para o sucesso do uso do seu sistema de CRM .

VANTAGENS
Lucre com todas as Soluções de Qualidade de dados para CRM da Uniserv, incluindo:

• Óptima qualidade dos dados no sistema de CRM através da análise dos dados durante a transferência de fontes de dados existentes e através do acompanhamento permanente de novas entradas e mudanças (Data Quality Firewall)
• Revisão dos dados (limpeza de dados) de acordo com regras definidas e combinando - a contra os dados de referência (por exemplo, endereço, ...) no processamento em batch ou em tempo real
• Ambiente "Anti - envelhecimento" para os dados do seu cliente / prospect através da integração automática de informações sobre as mudanças de endereço ou de empresa renomeando tanto no B2B e B2C
• A geração automática de uma visão da família (Household) no mercado de B2C
• Os clientes satisfeitos e laços mais fortes com o cliente através de serviço de alta qualidade com base em informações de confiança de clientes.
• Optimizando vendas e planeamento de marketing e as decisões empresariais através informações de up- to-date e a elaboração de relatórios precisos.
• Extensas análises do comportamento do consumidor para o uso potencial e eficaz de upselling e cross-selling
• Campanhas de marketing eficientes e eficazes, através de selecção de endereços orientados ao objectivo e correctos, dados completos para campanhas de mailing.