Qualidade de Dados / Data Quality

Existem algumas ferramentas de qualidade de dados que dizem funcionar em Portugal. Algumas dizem ser muito avançadas por terem um dicionário de sinónimos com muitos milhões de entradas. Outras dizem que têm ferramentas internacionais que funcionam para Portugal, apenas necessitam de pequenos ajustamentos consoante a BD a tratar. Mas na realidade quais a diferenças entre as ferramentas existentes no mercado Português?

Vamos por partes, as que referi em primeiro lugar, são ferramentas que facilmente se percebe as suas limitações. Todos sabemos que a quantidade de erros que é possível dar é totalmente ilimitada. Ou seja por cada BD que seja tratada, certamente que novas "versões" das diferentes ruas vão ser criadas. Isto apenas para referir as já existentes. Porque se houver um trabalho de actualização com novas ruas e alterações de ruas, todo um histórico de "versões" de erros tem de ser criado. Nunca se conseguem grandes resultados com estas ferramentas, porque simplesmente as actualizações são diárias e virtualmente infinitas.

Depois existem ainda outras de origem normalmente Americana ou Anglo-Saxónica e às quais foi "anexado" um street file (ficheiro com os arruamentos) e que supostamente, trabalham sem problemas. Aqui temos um outro problema, que são as especificidades de um país como Portugal. Nestes mercados não existem a Rua, Travessa, Largo e Beco da Liberdade, tudo na mesma cidade. Logo aqui em muitos casos existem problemas na identificação/normalização das ruas.

Conheço este problema muito bem porque há pouco mais de 10 anos, andei a fazer um estudo para a "importação" de ferramentas disponíveis no mercado internacional e foram estes alguns dos problemas com que me deparei e hoje mais de 10 anos depois, continuam actuais como nesse tempo.

Então no final qual a solução?

A solução é um misto das duas, ou seja uma ferramenta que consiga "gerar" automaticamente esse histórico de erros, contando com mais de uma dezena de algoritmos internos, entre os quais o fuzzy logic, Patricia structure, Levenshtein distance e muitos outros, mas que por outro lado esteja adaptado ao mercado Português. Essa adaptação demorou quase dois anos, mas os resultados finais que conseguimos obter falam por si.

A confiança neste software é tão grande que o disponibilizamos na internet para que se possa testar. Mais nenhum outro está disponível desta forma e isso diz um pouco da confiança que se tem nos produtos. Para comprovar o que digo basta fazer um teste aqui, onde podem testar com uma morada com erros e por exemplo apenas com o código postal de 4 dígitos.

Por vezes quando se está a fazer comunicação B2C (business-to-consumer) o que deveria ser feito realmente era comunicação B2H (business-to-household).

O dinheiro que se gasta desnecessariamente sempre que é feita uma comunicação offline em criatividade, produção, handling e portes, em material que vai duplicado e triplicado para a mesma casa é um valor que todas as empresas deveriam ter em consideração. A estes custos ainda podemos juntar os devolvidos por moradas mal endereçadas por falta de um software que faça a normalização dos dados.

Com a existência de uma chave de household ficamos com a possibilidade de fazer envios, personalizados segundo o target que pretendemos. Se tivermos uma peça que será dirigida apenas às mulheres de uma casa, podemos assim evitar fazer o envio da peça para mãe e filha que constem da nossa BD, mas apenas para aquela que mais se adequar à peça a enviar.

A deduplicação feita por household não é fácil de executar, encontramos inúmeras dificuldades, das quais destaco, households que são constituídos por indivíduos com nomes de família diferentes, a existência de moradas que podem ser moradas de trabalho ou residências partilhadas.

Quais são os limites de tolerância que deve ter o projecto?

Por norma todas as aplicações são parametrizáveis e estes limites devem ser tomados em conta, não de uma forma genérica, mas mais uma vez, com a experiencia adquirida. Tal como foi dito nos pontos anteriores todas as BD's são únicas e como tal têm de ter tratamentos diferenciados. Imaginemos que temos uma BD na qual temos uma deduplicação já testada e experimentada, em que o valor de match tem um valor ideal. Mas entretanto foi criado mais um campo que ajuda na deduplicação dos registos, como tal deveremos mudar os limites para termos a certeza que os duplicados são encontrados.

O mesmo se passa relativamente aos parâmetros dos softwares real time. Ao longo do tempo poder-se-á verificar que é necessário fazer acertos porque os utilizadores por exemplo usam mais uma variável que outras para fazer pesquisas. Como tal temos de na parametrização evidenciar essa variável para que os resultados sejam totalmente satisfatórios. Com isto apenas se demonstra que embora os limites devam existir, existe com estas ferramentas sempre a possibilidade de fazer afinações.

No video que se segue podem ver como funcionam as ferramentas de qualidade de dados. Neste caso, podemos ver a versão integrada em SAP(R), em que a Uniserv foi a primeira empresa a nível mundial a receber esta certificação SAP(R). Para além desta versão, estão disponíveis módulos de integração para as mais diferentes configurações, desde o mainframe a módulos de cliente nos mais variados sistemas operativos.

Um dos primeiros processos necessários para termos qualidade de dados é a Limpeza dos dados (Data Cleansing). Consiste essencialmente na detecção e correcção (ou remoção) de registos que estejam incompletos, incorrectos, sejam irrelevantes, que estejam corrompidos ou imprecisos. Outro dos termos que se podem igualmente aqui aplicar é validação dos dados (Data validation). Embora possam e devam ser usados em conjunto, na maior parte dos casos a validação dos dados é pouco ou nem sequer é usado. Isto apenas faz aumentar os custos de limpeza de dados, uma vez que se os dados forem validados logo na sua entrada é muito mais simples, barato e fiável, que posteriormente normalmente num processo batch.

Voltando ao processo de limpeza, mais tarde iremos falar no processo de validação, é um processo que deve envolver a remoção de erros que são comuns, como por exemplo, erros de digitação, fonéticos e outros que possam ocorrer aquando da inserção dos dados em BD. Isto sempre feito comparando os registos contra tabelas de referência, ou através da delimitação de valores, ou com métodos estatísticos, ou outros processos que validem esses dados. Esta validação pode ser mais ou menos restritiva, invalidado por exemplo registos que não tenham código postal.

Numa fase posterior temos a remoção de duplicados das BD’s que é outro dos processos fundamentais na limpeza de dados. Esta parte é das partes mais sensíveis uma vez que não existe uma “receita” que sirva todas as BD’s. Todas as BD’s são únicas e como tal o processo de parametrização tem sempre de ser igualmente único. É um processo muito sensível, porque podemos estar a deixar muitos duplicados por encontrar, ou por outro lado podemos estar a dar como duplicados registos que não são de todo duplicados. Esta afinação é dos processos mais morosos e que requer mais conhecimentos em todo o processo de limpeza de dados. Mais uma vez, tudo isto se simplifica quando esta remoção de duplicados é feita aquando da introdução dos dados na BD. Prevenir é sempre melhor que remediar.
Depois de assinalados os duplicados há um processo muitíssimo importante que é o processo de complementarização. Consiste na “associação” de todos os campos, segundo regras pré estabelecidas, a um único registo. Imaginemos que temos 5 duplicados de um dado registo e que apenas em um deles temos o número de telemóvel. Esse dado não pode ser pedido, temos de ter forma de o poder colocar no registo master, que no final do processo irá ter TODAS as informações dispersas por todos os registos duplicados.

Depois de cada um destes processos há sempre um outro que tem de decorrer em paralelo que é o processo de verificação da consistência dos dados. Este processo de verificação é de extrema importância para que não se percam dados em nenhuma das fases deste processo.

Perfeição não existe na qualidade dos dados. Este é o princípio que temos de nos capacitar antes de tudo. Não existe 100% de qualidade de dados porque todos os dias, há alterações nos dados, quer seja por mudanças de morada por parte de clientes/potenciais clientes, quer seja porque a rua foi renomeada, quer seja porque passou de Lote a número de polícia definitivo, e tantos outros factores que podem fazer com que os dados deixem de ser dados válidos.

Quanto menos lixo entrar na sua base de dados melhor, especialmente nos dias de hoje em que existem ferramentas que impedem entrada de dados “sujos” fazendo a limpeza, normalizando e corrigindo os dados ainda antes de entrarem na BD, sempre que isso seja possível, ou assinalar aqueles que não tendo possibilidades de serem corrigidos automaticamente, suscitem dúvidas relativamente à sua validade.

Prevenir é bem melhor que remediar. É muito mais vantajoso e eficiente manter uma base de dados normalizada, e sem duplicados no dia-a-dia, do que anualmente fazer a extracção de TODOS os dados para que se execute um processo de qualidade de dados, para depois voltar a fazer a reintegração dos dados com todos os custos que esse processo envolve. Custos não apenas monetários elevados, mas custos em termos da operação em si, que necessita de um cuidado extremo, para que não se reponham dados que entretanto foram alterados.

Por tudo isto a qualidade dos dados é uma coisa que é partilhada pelo marketing, apoio, vendas e quase todos dentro da empresa. Todos são responsaveis pela qualidade dos dados da empres e a todos se deve pedir responsabilidades, mas tem de haver alguém responsável final pela qualidade de dados dentro da empresa e quanto mais acima estiver na pirâmide organizacional da empresa, melhor. Porque esse, por sua vez, tem de ir pedir responsabilidades a quem esteja a falhar.

Bem-vindos. Vou tentar mostrar porque a Qualidade dos dados é tão importante nos dias que correm, especialmente em Portugal onde nunca houve a mínima atenção a este problema, excepto em algumas honrosas excepções.

Iniciamos esta viagem no passado, quando as empresas descobriram coisas como o CRM, Data Mining e muitos outros conceitos em que investiram milhões e daí retiraram... tostões.

E aconteceu porquê? Faltava-lhes as fundações, o essencial para que todos estes projectos possam pelo menos ter hipóteses de terem sucesso. QUALIDADE DE DADOS.

Sem uma base de dados normalizada e sem duplicados é impossível que qualquer destes projectos tenha o mínimo de hipóteses de ter sucesso. Isto ainda se torna mais complicado quando existem vários repositórios de dados que fazem com que os dados estejam dispersos por várias bases de dados e em vários sistemas. Desta forma nunca vão ter uma visão única e unívoca de cada um dos seus clientes ou potenciais clientes. Quantos de nós já recebemos cartas duplicadas de uma instituição a fazer publicidade a um mesmo produto, ou por outro lado fizemos um pedido de informação e a resposta nunca chegou.

Tudo isto se deve a estes problemas de qualidade de dados. Ainda recentemente nas eleições europeias, houve um “escândalo” de bradar aos céus na Dinamarca, em que os eleitores receberam indicações para irem votar em moradas incorrectas, outros para irem para outros locais de votação que não os deles, outros ainda tinham dois locais diferentes para irem votar, outros nem sequer receberam indicações onde se deveriam dirigir para votar. Tudo isto devido à inexistência de qualidade de dados. E nem sequer estamos a falar de um qualquer país subdesenvolvido ou de terceiro mundo.

Por este exemplo e por muitos outros que todos encontramos no nosso dia a dia podemos ver a importância da qualidade de dados.