Qualidade de Dados / Data Quality

A percepção que existem problemas na qualidade dos dados é em muitos casos uma realidade nas empresas, a maior dificuldade é a percepção da dimensão do problema.

Aqui surgem dois aspectos que normalmente impedem a percepção da dimensão: uma é a forma e a outra é a vontade de conseguir quantificar problema.

É sempre complicado conseguir uma forma de medir a qualidade ou falta de qualidade dos dados porque não existem métricas exactas que possam ser aplicadas directamente, embora como mostrei nos posts relativos ao conceito, definição de qualidade de dados (Data Quality) e na segunda parte do mesmo, há sempre formas de conseguir quantificar, todos conhecem sintomas que surgem quando a qualidade dos dados não está em condições, porque há sempre qualquer coisa que corre mal devido a essa falta de qualidade de dados. Casos em que uma resposta demora mais tempo que o deveria ser suposto porque houve necessidade de "limpeza" dos dados. Um exemplo simples, uma simples contagem por Concelho é adiada porque afinal nem todos os registos tinham Concelho atribuído, ou porque existiam muitos em que os Concelhos atribuídos estavam errados. E para tal, em vez de se esperar 5 minutos por uma contagem, os dados chegam uma semana depois. Em casos urgentes em que sejam necessários esses dados na hora, quando chegam, já é tarde demais. Depois sim é "ordenada" uma vistoria a todos os dados dos Concelhos, para que não volte a ocorrer tal situação.

Mas muitas vezes o mais complicado é mesmo a vontade de conseguir quantificar o problema. Porquê? Porque isso implica o assumir da existência de um problema. Devido aos afazeres do dia-a-dia, estar a "criar" mais um problema é sempre complicado. Quando aparece um problema especifico fazem-se as necessárias correcções. É um exemplo que dou vezes sem conta, mas é uma pergunta que faço invariavelmente e que tem a mesma resposta também invariavelmente. Para se saber o estado da base de dados pergunto o numero de devolvidos que são recebidos e a resposta é sempre um rotundo "não fazemos a mínima ideia".

Volto a referir para que não tirem conclusões precipitadas das minhas palavras. A perfeição em termos de qualidade de dados é impossível de alcançar, mas é possível minimizar os problemas nos dados numa base permanente e constante, evitando grandes alterações nas condições dos dados.

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.

Infelizmente recomeçamos a ouvir falar no falhanço dos projectos de BI por esse mundo fora, tal como no final dos anos 90 até ao inicio do século se foi ouvindo falar do falhanços dos projectos de CRM, nos quais se investiram milhões e se retiraram tostões. Esta frase foi utilizada no primeiro post aqui deste blog já lá vão quase dois anos e mantém-se actual.

Tenho andado a adiar este post, mas ontem depois de mais algumas mensagens relacionadas com o tema, decidi que finalmente era hora de falar deste tema.

Os valores ainda são muito dispares e vão desde os 70 a 80% apontados pela Gartner, penso que poucos podem duvidar da independência dos estudos da Gartner. Quando falamos de previsões, falham como todos, mas em termos de estudos. por norma são a grande referencia internacional.

Outros ainda falam de 50%, mas são sempre valores elevados que estamos a falar e mais elevados ainda se tivermos em consideração os valores monetários.

Do muito que se pode ler relacionado com o tema por esses sites e blogs, um tema é comum. A Qualidade dos Dados está sempre no top dos motivos que levam ao falhanço dos projectos de BI.

Como estou a colocar números, vamos a mais alguns, pena que já tenham alguns anos, mas continuam certamente muito actuais. Num estudo de 2005 da Business Week chegou-se à conclusão que 43% dos utilizadores dizem não ter a certeza que os dados internos estão correctos, que 77% dizem que más decisões foram tomadas devido à falta de informação e 4 em cada 5 não acredita nas estatísticas das apresentações. Um outro estudo do Data Warehousing Institute diz que a falta de qualidade nos dados dos consumidores custaram às empresas Norte Americanas $611 mil milhões de dólares por ano. No entanto quase metade das empresas inquiridas admitiram que não têm planos para incrementar a qualidade dos dados.

O incremento da qualidade dos dados não é a solução final e absoluta para o sucesso dos projectos de BI, mas ajuda significativamente para evitar o falhanço dos projectos de BI. Não querendo de forma nenhuma colocar a foice em seara alheia, diria que o principal factor para o sucesso, será o factor humano, seguido pela qualidade dos dados.

Tal como prometido no post anterior aqui ficam algumas soluções para minimizar os problemas de qualidade de dados.

Vamos ver se consigo abranger todos os tópicos colocados, mas tenho desde já de fazer uma ressalva. A limpeza dos dados é tudo menos um processo estético. Não se deve fazer uma limpeza de dados apenas para que fiquem "mais bonitos", até porque a isso não se deve chamar limpeza de dados, muito menos processo de qualidade de dados. Isto vem na sequência de uma mensagem que recebi e como não quero que restem duvidas acerca deste aspecto venho aqui reiterar a importância dos processos de qualidade de dados.

Vou tentar mostrar como os processos de qualidade de dados podem ajudar a melhorar, não apenas os dados em si, mas especialmente conseguir em primeira analise a melhoria imediata dos dados, de forma a rentabilizar os mesmos, podendo dessa forma ter um retorno no investimento rapidamente.

Muitos são os estudos e todos apontam para valores assustadores de custos. Vamos desde os 5% do PIB Norte-Americano, aos 10% das receitas das empresas Australianas e da Nova Zelândia para alem de muitos outros valores todos eles como foi dito... assustadores.

Em Portugal nunca foi feito nenhum estudo concreto dos valores que a falta de qualidade dos dados nas nossas empresas representam. Provavelmente porque é um problema que se vai adiando, porque os custos não são medidos, como tal não existem. Os devolvidos são colocados num armazém e nem sequer são contados e quando são contados por norma não se faz contas ao custo total desses devolvidos. Fiz uma pequena "calculadora" onde se pode calcular o custo aproximado total destes devolvidos, com valores a que tive acesso de uma campanha de um prospect. Não é nada muito elaborado nem tenta ser. É apenas para que se possa ter uma forma simples de ter uma noção dos custos.

Estes processos de qualidade de dados podem ser mais ou menos complexos dependendo muito não apenas dos problemas existentes, mas também da disponibilidade de mudança da empresa. Idealmente estes processos deveriam iniciar-se com um data profiling.

Nesta primeira fase, será feita uma representação das fontes de dados, com os nomes dos campos, a sua descrição, os máximos e mínimos. Ter uma representação dos valores, mostrando os padrões, com as frequências para que rapidamente se possam detectar erros nos dados existentes. Verificar a informação das tabelas ligadas, a existência de registos órfãos, detecção de sobreposições, verificação dos dados dos campos por entradas válidas, detecção de tabelas não normalizadas, entre outras verificações de todos os campos existentes permitindo assim que se tenha uma noção rapida e concreta de todas as dificuldades existentes. Este trabalho pode ser executado manualmente, mas com a execução destes softwares o tempo de execução é reduzido para 15% em norma.

Numa segunda fase temos os processos batch. Para alem da correcção dos problemas nos dados que tenham sido encontrados anteriormente deverão ser igualmente executadas a normalização de moradas e a procura de duplicados, que são uma ajuda fundamental para incrementar a qualidade dos dados, mas apenas servem para melhorar no imediato essa qualidade. Depois são necessários softwares que mantenham essa qualidade. Caso contrario passados uns meses já se perdeu novamente a confiança nos dados.

Essa terceira fase que deve ser colocada em implementação conjuntamente com esta segunda fase, é constituída pela implementação de softwares online que permitem que todas as interacções entre os utilizadores e a base de dados sejam feitas de forma a manter os dados limpos.

Este processo tem 3 vertentes, uma a normalização/correcção das moradas, impedindo que moradas erradas entrem no sistema, outra vertente a deduplicação/desduplicação dos registos, evitando que registos duplicados entrem em BD e por fim uma monitorização de todos os outros campos da BD, impedindo que erros já detectados voltem a ocorrer.

Todos estes processos já foram de alguma forma aqui demonstrados neste blog. Temos por exemplo o profiling, os processos batch, a parte da normalização/correcção de moradas e finalmente a monitorização.

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.

Curiosamente depois do post de ontem chegou-me um email com um artigo que acaba por reiterar o que disse.

Resumidamente o que a Gartner vem mostrar são os 10 mitos que o conceito de gestão de dados (MDM) que se iniciou como uma forma de manter as informações actualizadas e uniformes em toda a organização, mas que durante o tempo tem existido alguns equívocos sobre a sua necessidade e implementação. No ponto 9 fala-se precisamente de qualidade de dados.

Mito 1: O MDM é implementar uma tecnologia
Realidade: MDM é muito menos sobre tecnologia e muito mais sobre a compreensão de como os processos de negócios é suposto trabalharem.

Mito 2: MDM é um projecto
Realidade: MDM é implementado como um programa que muda para sempre a maneira como a empresa cria e gere os seus dados. No entanto, para adoptar o MDM vai exigir numerosos projectos distintos.

Mito 3: Não necessitamos de MDM, temos um Enterprise Data Warehouse (EDW)
Realidade: MDM deve / irá abranger a organização em todas as unidades de negócios e processos (incluindo os armazéns de dados operacionais e analíticos).

Mito 4: Implementação de ERP significa que não necessita de MDM
Realidade: Geralmente o Enterprise Resource Planning (ERP), significa uma estratégia empacotada de aplicações de negócio, na maioria das vezes centrada num único grande fornecedor. Está implícito no ERP, mas raramente é realizado para a organização do utilizador, um único processo e modelo de dados em toda a organização.

Mito 5: O MDM é apenas para empresas grandes e complexas
Realidade: O princípio da MDM é aplicada sempre que dois ou mais processos de negócio devem exibir ou partilhar dados. Isto significa que a maioria das organizações têm uma necessidade para a disciplina de MDM, mesmo que não lhe chamem assim, ou se implementaram uma tecnologia separada chamada MDM.

Mito 6: Os metadados são 'a' Chave para MDM
Realidade: Os metadados são essenciais para MDM (e muitos esforços fora do MDM), mas como metadados é aplicado no contexto do MDM difere por domínio, a indústria, forma de uso e estilo de implementação.

Mito 7: MDM é um esforço de TI
Realidade: MDM deve ser conduzido pela empresa, um caso de negócio, e apoiados / habilitados por TI.

Mito 8: MDM é simplesmente muito grande para fazer
Realidade: MDM pode ser e está sendo adoptado por um domínio ou uma província de cada vez, e um caso de uso de cada vez.

Mito 9: MDM é separado da Data Governance e Data Quality (Qualidade de dados)
Realidade: MDM inclui a gestão (dos dados) e a qualidade (de dados) - MDM não pode ser estabelecida sem eles.

Mito 10: Não importa qual fornecedor de tecnologia utilizado - They All 'Do' MDM
Realidade: MDM é complexa, raramente duas organizações têm programas de MDM parecidos. Vendedor de MDM tem a capacidade, de focar na especialização em domínio de dados, na indústria, forma de uso, organização e estilo de execução. Por conseguinte, a seleção do fornecedor é crítica em organizações que buscam encontrar o parceiro certo.

Fonte