Qualidade de Dados / Data Quality

Ao ler um post "humorístico" do Jim Harris, demonstra quanto é verdadeiro a utilização do placebo no tratamento dos dados. Acrescentando a isso a origem da palavra, Placebo (do latim placere, significando "agradarei").

Existem tratamentos de dados que não fazem mais nada menos do que isso... agradam, porque não fazem nada aos dados. Quando muito melhoram a percepção da qualidade dos dados, mas a "doença" continua activa e a minar todos os dados novos e os existentes, durante o dia a dia.

Em alguns tratamentos temos a possibilidade de através de um processo de ETL, colocar os códigos postais actualizados, mas os que sejam inseridos nos dias seguintes a esse processo de ETL? Têm de esperar um ano, ou mesmo em alguns casos mais tempo para que possam ser validades e/ou corrigidos. O mesmo se passa relativamente aos duplicados. Existem muitos duplicados em BD, faz-se um processo de qualidade de dados com uma deduplicação, mas no dia seguinte aparece um novo registo e como não existe forma de automaticamente ter acesso a uma lista de possíveis duplicados, são criados novos registos e o Single View of Customer é apenas uma miragem.

As ferramentas online são por isso essenciais para resolver a doença, porque trabalham lado a lado com todos os intervenientes, a todo o momento na inserção/alteração de dados, impedindo assim validar e corrigir quando necessário todos os dados.

Desta vez vou colocar alguns números provenientes da falta de qualidade dos dados.

Para ser mais simples vou dividir em dois grandes grupos, um apenas com os custos directos que podemos associar à falta de qualidade dos dados e um outro em que juntamos campanhas de marketing directo sobre os dados.

Para este cenário de custos directos e por uma questão de simplificação vamos adoptar um universo de 1 milhão de registos.

Neste 1.000.000 de registos estimamos a existência de um universo de 15% de duplicados, a existência de 5% de moradas em falta e 20% de moradas incorrectas (em muitos casos estes valores até são bastante conservadores).

Por fim vamos assumir um custo de 6€ por hora por trabalhador que até é um valor bastante baixo, porque o calculo dos custos com o trabalhador devem contemplar para alem dos vencimentos e dos custos com segurança social, os custos do "posto de trabalho", como a electricidade, o custo da infraestrutura e todos os outros custos associados directa e indirectamente. Este valor pode assim ser quase que considerado como um valor mínimo.

Se por cada criação de duplicado foram perdidos 2,5 minutos, nos 150.000 registos que foram criados indevidamente, foram gastos 37.500,00€ desnecessariamente. Juntando a este valor o tempo perdido em busca de uma morada correcta, o tempo de correcção de erros de morada, o tempo perdido com queixas de clientes, temos um valor final que facilmente justifica a existência de ferramentas de qualidade de dados. Somando tudo com muita facilidade de consegue chegar às centenas de milhares de €uros. Como tal o ROI de um projecto destes é facilmente comprovado e justificado. Em muitos casos no final do primeiro ano já temos esse retorno.

No link do titulo abre uma página com alguns cálculos, mas tenho um template que com facilidade se conseguem ter valores concretos adaptando aos valores reais de cada companhia.

No próximo post vamos abordar a segunda parte que será o envio de peças por correio, quer sejam peças promocionais, quer sejam peças de envio regular, como extractos ou facturas/recibos.

Tudo o devemos ter em conta relativamente à qualidade dos dados:
- Os dados assim que entram no sistema já estão desactualizados
- A conversão de dados é um dos maiores problemas de qualidade de dados
- Convencer os responsáveis que a qualidade de dados é um problema é um desafio.
- Tem sempre de haver num€ros para se poder fundamentar um projecto de DQ
- O projecto de DQ tem de ser um projecto global, envolvendo TODA a empresa.
- Nada se compara a uma validação dos dados logo no seu input. Todos os projectos posteriores de ETL vão ter sempre resultados muito inferiores.
- A chave para termos os melhores dados é pensarmos que os dados nunca estão tão bons como pensamos.
- Não existe perfeição, não existe 100% de dados correctos, mas podemos ficar perto.
- Quem é responsável pela qualidade dos dados na empresa? O Marketing? As Vendas? Os Serviços ao Cliente? O departamento de TI's? Nenhum dos anteriores? Deve haver sempre um responsável e quanto mais alto esse responsável estiver dentro da hierarquia da empresa melhor.
- Todo o "lixo" que entrar, vai ser "lixo" que vai para a rua. O envio desse "lixo" tem custos. O ideal é ter um filtro na entrada dos dados que faça a limpeza desses dados para evitar a entrada do "lixo".

Cloud, nuvem, ASP, SaaS, Software como Serviço e muitas outras designações que se vão ouvindo para definir o mesmo conceito. O conceito poderemos definir de forma muito simples como o aluguer de um software sempre via internet.

Teoricamente em termos de vantagens é uma relação win-win. O comprador tem como vantagens não necessitar de fazer a manutenção do sistema, não necessitar de se preocupar com os upgrades e tem ainda a vantagem crucial, que é o baixo custo de investimento inicial. Existe ainda a vantagem de que o investimento total fica sempre muito aquém, em caso de uma utilização moderada, do preço total da compra da aplicação. Existem ainda muitas outras vantagens, como por exemplo poder ter sempre um controle sobre os custos, ter acesso imediato a actualizações/alterações, serem sempre soluções flexíveis e evolutivas.

Por outro lado, para o fornecedor, a principal vantagem é poder chegar a mercados que de outra forma lhe estariam inacessíveis.

No caso da qualidade de dados é possível aceder aos processos de normalização de dados, falados anteriormente via SaaS. Em vez de aceder ao servidor local para poder normalizar a morada, com o SaaS esta normalização vai ser efectuada num servidor via web. Esta possibilidade está disponível, e pode ser uma solução não apenas para clientes que tenham um volume de dados que não justifique a compra das aplicações, mas também para clientes que tenham moradas estrangeiras em numero mais reduzido, mas que pretendam fazer a normalização das mesmas. Desta forma localmente fazem a normalização das moradas nacionais e via SaaS fazem a normalização das moradas estrangeiras. Neste serviço podem ser incluídas as coordenadas geográficas.

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.

Estão cada vez mais na voga as aplicações de BI, mas para que elas vinguem têm de ter boa informação.

Como podemos dizer que a informação da sua empresa é boa? Aqui ficam uma série de perguntas, que caso possa responder afirmativamente a todas as questões, pode acreditar que as suas ferramentas de BI vão fazer a sua função correctamente e certamente que lhe vão ser muitíssimo úteis. As perguntas que devem ser feitas relativamente à informação disponibilizada pelas ferramentas de BI são:
- Conseguimos encontrar o que procuramos?
- Está disponível quando necessitamos?
- Inclui tudo o que necessitamos?
- Conseguimos perceber?
- Está correcta?
- Podemos confiar?
- Podemos usar?
Muitas vezes chegamos à conclusão que a informação não é boa e ouvimos queixas, causa conflitos, perdas de tempo, custos elevados e fraco nível de decisão.

“90% dos gestores de topo sentem que não têm a informação necessária para decisões críticas de negócio; 50% deles têm medo que estejam a tomar decisões pouco acertadas devido a isso” Economist Intelligence Unit.

Mais uma vez tudo isto se resume à qualidade dos dados. Embora muitas vezes o que se ouve seja "deitem tudo fora e comecem de novo", isso não é de todo a solução porque caso não estejam incorporadas na empresa medidas que possam assegurar a qualidade dos dados, o que rapidamente vai acontecer à nova base de dados é ficar precisamente com os mesmos problemas que a anterior.

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.

Quem devem ser os intervenientes num processo destes?

No final do projecto, toda a empresa deve ter participado no processo porque tal como foi dito, isto afecta todos os departamentos da empresa sem excepção. Numa fase inicial apenas o departamento de informática tem um maior envolvimento no projecto, mas numa fase posterior todos os departamentos são chamados a participar, especialmente se forem colocados a funcionar os softwares que funcionam em real time. Nesta fase todos os colaboradores da empresa que tenham interacção com os dados vão ser chamados a normalizar os dados. Este processo vai apenas simplificar e em muitos casos permitir poupar tempo nas rotinas de introdução/ alteração de dados.

Mesmo que existam vícios de introdução de dados, o que vai acontecer no final é que todas os colaboradores da empresa sem excepção, vão colocar os dados da mesma forma no sistema.

No link podem tentar colocar alguns dados de formas diferentes e como se pode ver no final o resultado é sempre o mesmo.

Quanto tempo demora a ter um projecto destes em funcionamento?

O tempo de implementação de um projecto de qualidade de dados depende de muitos factores: da quantidade de registos existentes, dos sistemas existentes (SO e SGBD), da qualidade actual da BD. Tudo isto são factores que podem interferir no tempo de implementação do projecto de qualidade d e dados.

Vamos então por partes. Relativamente à quantidade de registos existentes, como facilmente se compreende é totalmente diferente normalizar 5.000 registos que normalizar 5.000.000 de registos, não apenas em termos de tempos de processamento máquina, como em termos de tempos de verificação dos resultados e respectivos acertos que sejam necessários efectuar. Especialmente em termos de deduplicação. Todas as BD’s são diferentes e como tal têm de ser efectuados acertos. Não existe nenhuma fórmula mágica que sirva para todas as bd’s e estes acertos, são dos processos mais melindrosos dentro de qualquer projecto de qualidade de dados. Pode ser a diferença entre, ter uma base de dados em que se misturaram clientes que nada têm a ver um com o outro ou então onde ficaram muitos duplicados por encontrar.

Quem já alguma vez tentou retirar duplicados de uma base de dados sabe a dificuldade que esse processo acarreta, porque muitas vezes mesmo estando a olhar para dois registos parecidos, não conseguimos dizer se são duplicados ou não. Fazer isto de forma automática, aumenta a dificuldade. Como tal, apenas com técnicos altamente experimentados conseguimos ter os melhores resultados num processo tão sensivel.

Qual é o budget necessário?

Tal como referido no ponto anterior a solução depende muito da quantidade de dados existente. Existem soluções para todos os budgets. Quanto maior a quantidade de dados, maior será a utilidade das ferramentas que funcionam real time.

Embora existam outras possibilidades, a possibilidade de se fazerem limpezas de dados com alguma regularidade, existem ainda os serviços SAAS, que começam agora a ganhar força, e que permitem que se tenha uma solução a preço reduzido.

Depois logicamente e para organizações de maior dimensão, existem as ferramentas que funcionando em real time permitem que se tenham dados com muita qualidade a todo o momento, por um custo por registo muito bom.

Porque vamos fazer este projecto? Este projecto é realmente necessário?

A resposta ao porquê, já foi anteriormente respondida no post inicial deste blog, mas é sempre bom reforçar argumentos. Tal como foi dito anteriormente os dados são as fundações de qualquer empresa. Não tendo dados de qualidade, os custos operacionais podem ser enormes, embora ninguém saiba muito bem quantificar o real valor destes custos nas respectivas empresas.

Por norma estes custos estão dispersos pelos diferentes departamentos da empresa. Se pensarmos em termos do departamento de informática, passam horas incontáveis a tentar resolver problemas de integridade de dados, porque por exemplo, quando lhes é pedida uma contagem simples ao número de clientes de uma determinada zona. Como não têm capacidade imediata para dar resposta, vão verificar, muitas vezes manualmente e sem ferramentas adequadas, os registos que não têm distrito, concelho ou freguesia associada, ou até quem sabe um código postal de 7 dígitos de forma a poder cruzar com a tabela que faz a associação com os respectivos vendedores. Este é apenas um pequeno exemplo.

Depois no departamento de distribuição, por não terem as moradas normalizadas, nem com coordenadas geográficas, os carros têm de parar para pedir informações porque a rua como está escrita, não aparece no GPS, ou quem sabe andarem perdidos com os respectivos custos associados.

No departamento de Marketing, não se contabilizaram as devoluções que existem relativas à última campanha. Que têm associados custos não apenas de portes de correio, mas de criatividade da peça, desenvolvimento, impressão e envelopagem. Tudo isto são custos que se deveriam associar a cada uma daquelas peças que vieram devolvidas. Juntando a isto, temos ainda os clientes que receberam peças em duplicado ou triplicado, com os custos de imagem que isso implica.

No departamento de vendas por vezes podem não ter uma real noção dos gostos/necessidades dos respectivos clientes porque as vendas estão dispersas por mais que um registo. Como tal perdem oportunidades de vendas apenas porque o vendedor ao olhar para a ficha do cliente não tinha nesse registo a informação que ele era consumidor de um produto que por acaso nessa altura estava em promoção, de entre outros que o vendedor destacou.

Estas são apenas algumas das implicações que a falta de qualidade de dados pode trazer para dentro da organização, sendo que contabilizar todos estes valor é quase uma missão impossível.

Por norma o primeiro passo a dar antes de qualquer processo de qualidade de dados é o processo em que se auditam os dados, detectando assim quais os problemas que existem dentro da BD.

Há duas abordagens que podemos ter para a detecção destes problemas, sendo que das primeiras coisas que devemos ter em mente é que quantos mais problemas forem detectados nesta fase, melhor qualidade terá o processo de limpeza dos dados. Como tal temos a abordagem convencional, que implica um esforço de recursos humanos significativo, uma vez que todas as áreas da empresa têm de estar envolvidas, porque existem detalhes que são específicos de cada uma das áreas e dificilmente outras áreas os vão detectar.

A outra abordagem, embora necessite de esforço em termos de recursos humanos, requer muito menos tempo, e consiste na utilização de softwares que façam a detecção de “desvios” dos valores padrão e apenas precisam de verificar esses, não necessitando assim ter passar tanto tempo a verificar a BD.

Este processo é essencial porque apenas assim se evita que alguns dos erros existentes persistam na BD, mesmo depois do processo de limpeza. Quanto mais pormenorizado for este processo de detecção dos erros na BD, melhor será o resultado final em termos de limpeza da BD. Existem outros softwares que fazem a monitorização dos dados depois do processo de limpeza, mas mais uma vez a sua fiabilidade depende em muito do processo de detecção de problemas na BD. Se conseguir detectar todos os erros que deram entrada na BD, mais facilmente se consegue monitorizar e evitar novas entradas.

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.