Qualidade de Dados / Data Quality

Um dos pontos fundamentais para conseguir atingir uma qualidade de dados de bom nível é a identificação dos pontos de origem dos fluxos de dados errados dentro da organização. Durante anos as empresas foram aglutinando um numero elevadíssimo de registos defeituosos, inválidos ou incompletos, porque não existe uma real capacidade de verificação das informações. Como tal grandes quantidades de dados errados, imprecisos, redundantes foram-se acumulando até que em muitos casos o que existe é um conjunto incontrolável de bases de dados fragmentadas e com um enorme volume.

Em cima deste pântano, foram colocadas ferramentas de CRM, ERP, BI e como tal, em muitos casos os resultados dessas ferramentas ficaram aquém do esperado.

A criação de métricas de qualidade de dados é apenas um meio para melhorar a qualidade dos dados. A existência de processos de monitorização, a definição de metas é vital para o incremento da qualidade dos dados. A existência de ferramentas de qualidade de dados que ajudem logo no input dos dados, que ajudem na prevenção de entrada de dados errados no sistema, é sem duvida fundamental para que se possa melhorar a qualidade dos dados obtendo dessa forma reduções nos custos, no esforço e tempo gasto. Com isso podemos ter economias de escala, obtendo igualmente melhores resultados nos CRM´s, ERP´s e BI's, maximizando ainda os lucros que se podem retirar destas ferramentas.

Para isso todos os responsáveis pelas diferentes áreas da empresa têm de estar comprometidos com a execução dessas metas. Todos, desde a administração têm de ter consciência que os esforços para a melhoria da qualidade dos dados é uma prioridade-chave para o sucesso do negócio.

Nunca é de mais repetir que a falta de qualidade de dados é responsável por danos de milhões de Euros em muitas empresas por esse mundo fora. Em muitos casos as empresas entram em grandes projectos de CRM e de BI desperdiçando vastos recursos, uma vez que a qualidade dos dados que alimentam essas aplicações continua a ser baixa ou por vezes muito baixa.

Existem casos que a implementação de rotinas de qualidade de dados mascara um pouco os problemas, mas não fazem com que a qualidade dos dados fique a um nível aceitável, não permitem dar o salto em termos de qualidade que os projectos de CRM e de BI necessitam. Dados incorrectos, a longo prazo podem levar à insatisfação dos clientes, baixando a retenção de clientes.

A Qualidade dos Dados é frequentemente abordada sob a forma de funcionários e/ou consultores externos, sendo por norma responsável por 20 a 50% dos projectos de datawarehouse.
Por norma estes projectos ETL executados desta forma, duram semanas e na maior parte dos casos mesmo meses ou anos. Logicamente que esta duração de projectos depende em muito da dimensão da BD. Com estes tempos de tratamento dos dados o normal é que aquando da reintegração dos dados, estes já tenham sido actualizados e com isso não possam ser reintegrados. Outras vezes ainda na reintegração surgem problemas com formatos, tamanhos entre outros. Outra das dificuldades que surgem é que os dados são por norma partilhados por várias plataformas igualmente com diferentes formatos, o que faz com que se perda um pouco da eficácia no tratamento executado.

O tempo de execução pode ser igualmente um problema porque quando se demora seis meses a processar um ficheiro, o mais certo é que no final do processo já existam dados a necessitar novamente de atenção, o que leva a que este projecto seja um projecto infindável.

Existem três aspectos que são fundamentais que são a precisão, a consistência e a antiguidade dos dados. Por vezes as empresas mantêm em BD dados de clientes com os quais não existe nenhum contacto há mais de 5 anos. Estes dados podem não estar precisos, podem não ter consistência e certamente não estão actualizados. Em cerca de 85% dos casos, a insatisfação dos clientes é resultado de dados obsoletos existentes em vários departamentos como registos de cliente redundantes. Registos duplicados são outros dos motivos da fraca qualidade dos dados e ainda ajudam igualmente a aumentar o tamanho da BD.

Dados correctos, no tempo certo, para as pessoas certas são determinantes para a eficiência operacional de qualquer empresa. Devem ser dados correctos a base de tomadas de decisão a todos os níveis, operacional, táctico e estratégico. Qual deve ser então a abordagem a ter? Indo certamente repetir-me, mas considero que a abordagem que preconizo é certamente a abordagem mais correcta e que melhores resultados finais irá obter.

Em vez de se repetir o processo de ETL infinitamente com todos os custos que isso acarreta, deve ser executado esse processo de ETL num prazo relativamente curto, por norma uma a duas semanas, sendo que para grande volume de dados um mês será um valor com margem de segurança.
Simultaneamente a este processo de ETL fazemos a integração dos programas de normalização / actualização/ correcção (Firewall) em todos os pontos de contacto com a BD, para impedir na medida do possivel que "lixo" volte a entrar na BD. Estas ferramentas têm a vantagem de serem usadas transversalmente em toda a organização. Com isto todos os agentes que até aqui eram a principal fonte de erros, passam a ser a principal barreira que impede que dados "sujos" sejam incorporados em BD. Não existe outra forma de ter qualidade de dados, que não seja com o empenho de todos.

Limpeza de dados de clientes e empresas

O DQ Batch Suite contem as fundações para todos os processos e aplicações de negocio - no que diz respeito aos nomes e moradas ou dados financeiros, produto ou dados de pedidos.

As seguintes soluções fazem parte do portefólio de inovação e funcionalidades avançadas que estão disponíveis no DQ Batch Suite:

• Analise e formatação de Moradas
• Correspondência de duplicados e clustering (por exemplo a nível do household), verificação de compliance e Data Enhancement
• Verificação Postal
• Geo e Micromarketing
• Consolidação de dados
• Modulo de Scripting para funções especificas suplementares
• Reporting e processamento gráfico de valores característico para qualidade de dados

O DQ Batch Suite permite que sistematicamente possa usar as funções de qualidade que necessita, para que possa criar valor acrescentado com a qualidade de dados.

Com o DQ Batch Suite, colocamos ao dispor um sistema moderno que irá ajudar a mover-se fácil e rapidamente nos processos de limpeza de dados como resultado da aproximação inovadora que permite. O sistema combina o melhor de anos de experiência da Uniserv e dos seus utilizadores e garante segurança no investimento e um rápido ROI. Adicionalmente quase que não será necessário referir que o DQ Batch Suite é:

• Fácil de aprender devido ao seu design consistente e operacionalidade intuitiva
• Aberto e flexível porque pode ser livremente configurado e por sem complementado por funções especificas do utilizador.
• Facilmente integrado em sequências existentes e pode ser automatizado
• User-friendly como resultado de extenso suporte ao utilizador e uma parametrização ultra fácil
• Alta performance através de processos e algoritmos paralelizáveis e avançados e confiáveis
• Escalável através de uma arquitectura cliente/servidor "state of the art" - disponível em quatro versões diferentes:

Desde a versão workstation para implementação de pequenos projectos de limpeza com quantidades limitadas de dados executadas na workstation, até ao Enterperise Server para grandes companhias em projectos de limpeza transversais envolvendo vários funcionários ou grandes quantidades de dados têm de ser tratados com as mais altas demandas de performance, paralelização e integração e automatização.

O que oferece o DQ Batch Suite?
Com o DQ Batch Suite, pode trabalhar de acordo com um principio: one-stop shopping!
Isto significa que controla o processo de limpeza passo a passo ao longo de todos os passos de processamento e programas. Pode ainda comunicar com o servidor DQ Batch Suite num dialogo via um interface gráfico user-friendly standard.

Com o seu enquadramento especial, o DQ Batch Suite orquestra todas as funções necessárias para o processos de limpeza:

• Todos os módulos para verificação da qualidade dos dados e a sua limpeza automática
• Blocos de funções para definir as regras de verificação individuais para dados "não de clientes" e executar limpezas automatizadas em massa, por exemplo de dados financeiros, de produto ou de pedidos.
• Produto com capacidades e recursos especiais para compreensão da organização, simplificação, automatização e aceleração dos processos e sequências para optimização e assegurar a qualidade dos dados.

Descrição dos processos que foram criados usando o interface gráfico do DQ Batch Suite que pode ser manualmente executado (ad-hoc) ou a qualquer altura desejada com a função integrada de scheduling, e também automatizada, por exemplo uma vez por mês. A execução das descrições dos processos podem ser integradas em sistemas IT que tenham sido desenvolvidos, sem problemas via a opção de automatização.

Qualidade de dados a nível internacional
O DQ Batch Suite pode também ser usada com as mesmas capacidades funcionais por empresas que operam a nível internacional. Com a capacidade Unicode o sistema providencia as bases para uma qualidade de dados internacional e pode igualmente manipular diferentes scripts e caracteres nacionais. Adicionalmente a isto, providenciamos versões especificas por país de blocos de funções e das bases de conhecimento. Como resultado, o sistema satisfaz as mais altas demandas de qualidade de dados internacionalmente.

Com o DQ Batch Suite, pode verificar os dados e na maior parte dos casos fazer a limpeza dos mesmos de forma totalmente automática.

Efeitos de uma pobre qualidade de dados
A limpeza dos dados é apenas um passo no processo de qualidade de dados, mas é um passo essencial. No que diz respeito a isto, não faz diferença se consideramos a limpeza dos dados no antigo sistema, nos projectos de migração de dados, nos dados master, gestão de risco ou compliance ou na implementação de dados orientados ao cliente, com o uso primariamente operacional dos dados dependendo da área, quer seja, na retenção de clientes, comunicação ou dialogo personalizado e direct maketing. A limpeza dos dados cria uma optimização da qualidade dos dados no que diz respeito à sua actualização, fiabilidade e grau de detalhe e como tal assenta fundações nos bons resultados de analise e processos de negocio - e finalmente para que se consigam melhores conteúdos de informação.

DQ Batch Suite: Funções "all-in-one"
O DQ Batch Suite integra todas as sequências de funções importantes e típicas para a limpeza de dados agrupados. O sistema leva-nos interactivamente através de todos os passos de processamento com uma interface gráfica. Com o assistente do software para que possamos controlar o processo batch, o DQ BatchSuite é o agregador de todos os projectos de limpeza. Podemos usa-lo para verificar a qualidade dos dados de cliente e limpa-los de forma totalmente automática, na grande parte dos casos e fazer igualmente limpezas em massa de outros dados, isto é podemos corrigir os erros que tenham sido automaticamente detectados pelo DQ Explorer ou automaticamente reportados pela solução da Uniserv, DQ Monitor.

O DQ Batch Suite permite criar consistência de dados necessária para os seus processos e aplicações!

Antes de continuar ir à parte prática do CRM, vou colocar um outro tópico onde falo da ferramenta que nos permite fazer a limpeza inicial dos dados.
As palavras-chave que ouvimos nos clientes
"Estou a procurar uma ferramenta de ETL!"
"Estamos a planear um projecto de Data-Migration!"
"Eu sou o CDI-Manager, o que nos pode oferecer?"
"Eu sou responsável pelos fluxos de trabalho MDM , nunca ouvi falar do DQBT ..."

O que é ETL?

E - EXTRACT
- Analisar e compreender a estrutura de dados do cliente
- Criar uma "entrada em degrau" para estes dados em DQBT
- Dentro do DQBT, importa-se os dados num formato mais geral

T - TRANSFORM
- Lista de pedidos e serviços exigidos pelo cliente:
- Telefone separado e números de fax
- Converter o país em formato ISO-2-Char
- Validação postal dependendo do país
- Check-dedup ao nível da pessoa
- Agregação de ID's de registos duplicados em cabeçalho- Nomes de pessoas divididos

L - LOAD
Saída de dados processados no formato desejado

O DQBT faz ETL sem qualquer problema

E - EXTRACT
- Flat Files em qualquer formato
- Diversas bases de dados através de conectores (VarChar-Campos)
- UTF-8
- Dados da Organização: lista de nomes por fonte, Prioridades, Atributos, ...

T - TRANSFORM
DQBT é "um sonho" no que diz respeito à transformação:
- Selecciona, classifica e agrupa registos em cada etapa
- Funções que operam por coluna: Shuffle, combinar, catálogos, ...
- Há um conjunto completo de funções: post, dedup, freestyle-match, convert, ...
- Consolidação dos grupos: agregação, enriquecimento de/com outros registos, ...
- Por coluna: Pequenos padrões PERL para transformação menores
- Programas "completos" PERL para regras de transformação avançadas

L - LOAD
Transformação por exemplo, a empresa relacional - + registos da pessoa (incluindo criação de novas chaves primárias ...)

O que é Data-Migration?

E - EXTRACT
- Dados sem tratamento em categorias diferentes (Cidade, Bairros, Ruas, ...)
- Extracção por categoria
- Importação para formatos mais genéricos dentro do DQBT

(T - TRANSFORM)

L - LOAD
- Combinação dos registos contendo as ruas, bairros, códigos postais, endereços postais.

O que é CDI (Customer Data Integration)?

Definição: CDI é o processo de consolidação e gestão da informação do cliente
- De todas as fontes disponíveis
- incluindo os detalhes dos contactos
- avaliação dos dados do cliente
- informação reunida através de interacções

CDI é o que o DQBT sempre fez

- Limpa, actualiza e completa os dados de contacto
   -> Post, Convert, ...
- Consolida os registos correctos, elimina duplicados, liga registos (...)
   -> Mail, Consolidate, PERL-scripting
- Enriquece registos internos e transaccionais com conhecimento externo e segmentação
   -> Geocodifica com coordenadas, compara com BD's externas, dados comportamentais...
- Assegura o cumprimento da supressão de contactos (...)
   -> Gere listagens de dados de fontes diversas: Blacklists, RIP, listagens de email...

O que é Master-Data-Management?

Definição: MDM envolve um conjunto composto por tecnologia, ferramentas, workflows e processos que mantêm e apresentam uma visão consistente e unificada dos dados.
- Actividades MDM (para criar um repositório MDM)
   -> Profiling: Analise dos dados
   -> Normalização
  -> Data Stewardship: Data Steward designa o modelo de dados, decidindo que entidades, relações e atributos devem ser guardados no modelo.
Este modelo torna-se o "single version of the truth"
    -> Matching & deduplicação
  -> Enterprise Data Mashup: (...) pode ser descrita como uma agregação de fontes heterogéneas (...) para um espaço único integrado (...)

Papel fundamental em Master-Data-Management com DQBT

Como criar um repositório MDM:
- extrair os dados relevantes das aplicações fonte
- Mapear estes dados para o modelo Master-Data
   -> Para que se possa executar, irá necessitar de uma ferramenta ETL como o DQBT
   -> DQBT pode ser parte dos MDM workflows

Conclusão:
"O DQBT é uma poderosa ferramenta ETL!"
"Projectos de Data-Migration não constituem problema para o DQBT!"
"CDI workflows devem ser constituídos com o DQBT!"
"O DQBT ajuda nos MDM workflows!"

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.

Hoje em dia já existem várias hipóteses para que se possa assegurar a manutenção da qualidade dos dados em níveis elevados. Não apenas com a compra das mais avançadas ferramentas de qualidade de dados, mas igualmente adoptando as mais modernas e económicas versões de Saas. Dependendo do numero de registos a serem tratados, existem inúmeras hipóteses: desde a compra da normalização de um valor predeterminado de registos, quer sejam 10.000 anuais quer sejam muitos milhões. Tudo isto num "tratamento" que é feito no momento mais importante de qualquer operação que envolve dados. O momento da inserção/alteração/modificação.

Imaginemos que na inserção de um registo é colocado apenas "Liberdade, 14 3 Esq" e que nessa cidade existem a Rua a Travessa e o Largo da Liberdade. Este registo muito dificilmente ficará correcto na Base de dados. Sendo que o mais certo é que venha a trazer custos para a empresa com a devolução de toda a correspondência que for enviada. Por outro lado e mesmo que seja feito um trabalho de ETL em cima desta BD, não há software nenhum que possa normalizar esta rua e caso algum o faça tem apenas 33% de hipóteses de acertar na "correcção". Mas por norma é assinalado e não é corrigido.

Tudo isto poderia ser evitado, caso no momento de inserção dos dados o utilizador recebesse uma mensagem que dissesse: "Existem 3 hipóteses de normalização: Rua da Liberdade, Travessa da Liberdade e Largo da Liberdade". Com estas hipóteses e com a possibilidade de perguntar directamente ao cliente, caso estejamos a falar de um Call Center, ou de um atendimento directo ao publico, o problema seria de imediato resolvido.

Neste caso estamos mais uma vez a falar de moradas, mas o mesmo se aplica relativamente aos duplicados e a muitos outros campos em que temos erros mais ou menos frequentes, mas que estão certamente identificados. Sempre que um determinado erro frequente ocorra há a hipótese de criar um alerta para que imediatamente se possa resolver o problema.

Existem como foram sendo descritas ao longo dos posts anteriores várias formas de normalização, correcção, actualização e validação das moradas, sendo o tratamento em modo batch sem dúvida o mais económico, para quem não tem volume de dados que comporte a compra das aplicações que funcionam logo na entrada dos dados. Embora seja essa a forma em que sem dúvida vamos ter os melhores resultados, nem sempre é possível fazer esse investimento.

Esta forma de tratamento obriga a um ciclo de tratamentos, mais ou menos frequentes consoante o volume de dados e de alterações que existam nos dados.

Neste tratamento de dados é feita a comparação dos dados existentes, com os dados existentes no ficheiro que contem as localidades, as respectivas ruas com, em muitos casos, os respectivos números de porta. Desta forma e recorrendo aos mais avançados algoritmos combinados, conseguimos ter resultados que são em muito superiores ao que por norma se consegue verificar. A segurança e qualidade dos dados e das aplicações é tal que é possível fazer testes neste demo online.

Esta é a melhor demonstração que podemos fazer da qualidade das nossas aplicações.

Na vertente Batch, vão existir no ficheiro final campos com uma descrição de todas as alterações que tenham sido efectuadas a cada um dos registos. Existem igualmente códigos que assinalam se os registos foram ou não alterados ou se não foi possível fazer a normalização / correcção / validação dos mesmos. Existem casos em que simplesmente não é possível fazer a normalização. Podem ser inúmeras as causas para essa não normalização, especialmente num país com as particularidades de Portugal. Mas mesmo com estas particularidades, estaremos sempre a falar em percentagens de normalização muito elevadas.

As ferramentas Real Time de qualidade de dados funcionam tal como foi já anteriormente referido a todo o momento permitindo assim que os dados estejam sempre actualizados e que a qualquer momento a qualidade dos dados possa ser assegurada de forma a que quando a informação seja necessária ela esteja correcta e actualizada.

Desta forma podemos confiar na informação existente nas nossas BD's evitando assim os picos que surgem nos processos de ETL que vimos anteriormente. Imaginado que o ciclo implementado para os processos de ETL era de um ano, se depois de nove meses de ter sido executado um processo de ETL fosse feita uma contagem, o que iria acontecer era que provavelmente os dados não seriam de todo fiáveis. Com as aplicações a funcionar em Real Time nunca chegamos a ter dados muito incorrectos. Podem haver algumas discrepâncias nos dados, mas será sempre valores residuais.

Este gráfico mostra a diferença entre as metodologias. Se a um dado momento nos for por exemplo pedido uma contagem de residentes numa determinada rua, com as aplicações Real Time em funcionamento não necessitamos de grandes esforços de normalização para conseguirmos dar esses valores porque sabemos que essa rua está sempre escrita da mesma forma e como tal não necessitamos de queries muito complexas para obter um resultado correcto. No exemplo dado anteriormente em que um processo de ETL tenha sido executado nove meses antes, o normal será procurar uma "Rua Principal"; "R Principal"; "R. Principal" e mesmo assim não existe a certeza de termos uma contagem com todos os registos da Rua Principal. Se no lugar da Rua Principal colocarmos uma Avenida Calouste Gulbenkian as hipóteses crescem exponencialmente.

A informação cada vez mais é um bem essencial a todas a empresas e não ter acesso a essa informação rapidamente pode ter consequências catastróficas.

Na grande maioria dos casos os projectos de limpeza de dados ou qualidade de dados, são projectos simples de ETL, em que existem várias abordagens.

Há projectos que são "simples". É feita a Extracção dos dados, o seu tratamento (Transform) e posteriormente o seu carregamento em BD (Load). Com estes projectos há uma aproximação a uma verdadeira qualidade de dados, mas se "olharem" com mais atenção vão verificar que na realidade, os dados nunca chegaram realmente a ficar limpos nos valores que são apresentados. Estes processos de ETL demoram algum tempo, e durante esse tempo, alguns dos dados que estão a ser tratados, estão a ser alterados pelos utilizadores. Ou seja, quando a BD é reposta, esses dados para alem de não poderem ser carregados, as alterações que entretanto foram efectuadas trouxeram mais "lixo" para o sistema.

E depois? Na semana seguinte a este projecto há novos dados, alterações e todo um conjunto de processos que fazem os dados voltar ao seu estado de falta de qualidade.

Existem outras abordagens, que já vi serem implementadas por grandes empresas em Portugal, que são ainda mais chocantes, que é a execução de projectos de ETL de forma progressiva. Ou seja, primeiro por exemplo tratam os registos que têm o código postal 1000. Depois os 1050 e assim sucessivamente. Este processo apenas permite que uma empresa fique eternamente a fazer a limpeza de dados, porque quando chegam ao fim do processo, estão os dados iniciais já totalmente "sujos". Apenas continuam o processo Ad aeternum.

Os processos ETL devem ser o principio de qualquer projecto de qualidade de dados. Durante o processo de ETL deve ser implementada uma solução online que permita a manutenção dos dados actualizados, evitando assim estar sempre a implementar processos ETL, com os elevados custos inerentes.

Aqui podem ver uma demonstração de como podem funcionar estas aplicações que em termos de moradas evitam a entrada de "lixo" para o sistema.