A crescente importância das estratégias de relacionamento com o cliente está redescobrindo os projetos de DataWarehousing. Mas, investir em projeto desta natureza depende, é claro, de tecnologia, mas exige muita atenção ao próprio processo de construção, principalmente às disciplinas de dados.
Dois componentes fundamentais tendem a ser esquecidos nos projetos de DataWarehouse. O primeiro relaciona-se com a aquisição, limpeza e transformação dos dados. E o segundo com a construção do próprio DataWarehouse. Na prática, dá-se mais atenção ao componente de extração, pela beleza dos seus interfaces gráficos e visuais, que a sua parte mais importante: a qualidade e integridade dos dados. Um DataWarehouse é tão bom quanto seus dados.
Infelizmente, uma parcela significativa dos dados disponíveis na organização não tem a acurácia e qualidade desejadas para serem usados em decisões de negócio. Uma recente pesquisa efetuada pelo Meta Group mostrou que nos projetos de DataWarehouse cerca de 10% a 20% dos dados capturados nos sistemas transacionais não estavam corretos ou completos o suficiente para serem usados.
Sob uma ótica simplista, no processo de extração de dados é trivial identificar os dados que serão necessários e carregá-los ao DataWarehouse. Em alguns projetos aparecem com simples e quase desapercebida linha no cronograma.
Mas, analisando um pouco mais detalhadamente a questão identificamos alguns problemas sérios. Primeiro, as fontes de dados são inúmeras, variando desde antigos arquivos VSAM residentes em mainframes e diferentes bancos de dados em diversos servidores a arquivos DBF e planilhas Excel em estações de trabalho.
Depois, observamos que os dados nestes arquivos não estão necessariamente corretos. Algumas informações como nome, sobrenome, endereços, idade e telefone dificilmente passam por revisões e processos de crítica nos sistemas transacionais, e portanto sua qualidade é bastante ruim.
Existem também desavenças sérias quanto a própria definição dos dados. Não é incomum vermos definições inconsistentes sobre dados e mesmo pela multiplicidade de fontes, torna-se difícil identificar qual a versão mais correta, atualizada e adequada. Em alguns arquivos, determinado dado tem certa definição e formatação. Em outros, o tipo do dado pode ser diferente.
Alguns outros exemplos de inconsistências já foram observados, como:
a) Dados colocados em lugares errados, com nome no campo de endereço e vice-versa.
b) Campos em branco, quando deveriam estar preenchidos. É comum em cadastros de clientes, em campos como endereços, telefone, data de nascimento e assim por diante.
c) Siglas e abreviações inconsistentes.
d) Campos com limites de valores inadequados, como idade de 200 anos.
e) Codificações diferentes para o mesmo dado. Um exemplo é código de produtos que pode ter determinada codificação em um sistema e outra codificação em um segundo sistema.
f) Informações desatualizadas ou divergentes, como endereços de clientes em sistemas diferentes.
Um DataWarehouse voltado a estreitar relacionamentos com cliente e a desenvolver estudos de segmentação dos seus hábitos de compra deve trabalhar com dados corretos. Informações erradas podem distorcer as análises e prejudicar os esforços de marketing. Não se pode pensar em um marketing one-to-one se as informações sobre o cliente estiverem erradas!
De maneira geral, o que buscamos em um sistema desta natureza? Algumas análises como as abaixo:
a) Análises demográficas, baseados em dados como sexo, nível de educação, status marital e idade.
b) Análises geográficas baseadas em dados como endereços, cidades, bairros e número de telefone.
c) Análises comportamentais baseados em dados de freqüência de compras, valor destas compras e meios de pagamento.
d) Análises psicográficas baseadas em dados sobre hobbies e interesses pessoais.
Além disso, se buscarmos análises mais sofisticadas, envolvendo o conceito de inter-relacionamentos entre clientes, como householding, por exemplo, devemos garantir que as informações armazenadas no DataWarehouse estejam adequadas a este nível de sofisticação. Por exemplo, para identificar dois ou mais membros de uma mesma família, devemos ter certeza que os sobrenomes e endereços estão corretamente armazenados.
O que existe em comum nestas análises? A premissa que os dados a serem usados estão corretos. Mas, são tipicamente dados que os sistemas transacionais não se preocupam em garantir em termos de qualidade e integridade.
Corrigir estes dados não é uma tarefa simples. Podem envolver muito tempo e esforço, inclusive trabalho manual de redigitação, contato com os clientes, e com a aquisição ou desenvolvimento de softwares que automatizem a correção.
A primeira lição aos projetos de DataWarehouse é “não subestimar a etapa de aquisição, transformação e limpeza dos dados”.
Um DataWarehouse pode ser considerado, simplismente, um database, com algumas características básicas: tende muitas vezes a ser extremamente grande; existe um alto grau de interdependência entre a maioria das suas tabelas; a principal forma de acesso é ad-hoc, ou seja, não pré-definida e estruturada; e como armazenam a dimensão tempo (dados históricos) tendem a crescer significativamente. Temos aí uma combinação altamente tóxica para qualquer banco de dados.
Outra preocupação que tende a ser subestimada é a freqüência e modalidade de atualização do DataWarehouse. Por exemplo, os dados estarão vindo de um ERP? Como serão extraídos e carregados no DataWarehouse e em que freqüência e horários? Recriar todas as tabelas a cada noite pode ser inviável em termos de tempo e demanda de recursos computacionais. E inclusive, nem sempre se pode perturbar o desempenho do ERP, gerando alta demanda de acesso a ele em determinados períodos do dia ou do mês… E muito menos tirá-lo do ar para carregar o DataWarehouse!
Ou os dados estarão vindo de diversas fontes, com o processo de limpeza e transformação sendo executado a cada vez? Além disso, existe a preocupação com backup e restore. Nem sempre é viável recriar-se do zero todo um DataWarehouse com seus vários Gigabytes de informação. A questão do armazenamento do DataWarehouse não pode de maneira nenhuma ser deixada em segundo plano.
Um DataWarehouse não é estático. É inteiramente dinâmico por natureza. Novas funcionalidades e novas demandas aparecem continuamente, e geralmente mais rápido que o inicialmente previsto. E todas as demandas de acesso convergem para o mecanismo de armazenamento. O DataWarehouse é mecanismo de perguntas e repostas. Se ele não suportar a demanda, não temos as respostas, e ele tenderá a fracassar, com milhões de reais indo pelo ralo.
Claro que não devemos começar um DataWarehouse com uma infra-estrutura dez vezes maior que a inicialmente necessária, mas também não podemos ficar restritos em termos de escalabilidade à determinada tecnologia subdimensionada.
Isto significa dimensionar adequadamente os recursos de infra-estrutura, considerando inclusive tecnologias de armazenamento inteligentes, como as disponibilizadas por empresas como a EMC. Temos aí a segunda lição para um projeto bem sucedido de DataWarehouse. “A questão da infra-estrutura e do armazenamento deve ser vista e revista com muita atenção”.
Muitas empresas já estão percebendo que ter enfoque estratégico no cliente é fundamental para sua sobrevivência. E estão partindo para projetos de relacionamento com o cliente, baseados em DataWarehousing.
Mas, para o sucesso destes empreendimentos precisamos de softwares adequados, processos ajustados a esta nova visão e informações corretas, íntegras e atualizadas. Os componentes de aquisição de dados, infra-estrutura e armazenamento são pilares fundamentais para o sucesso de qualquer investimento empresarial nesta direção. Um DataWarehouse cujos projetistas não se detiveram em analisar o suficiente como garantir a qualidade dos dados a serem disponibilizados, com certeza estão gerando um projeto que tenderá ao fracasso. Infelizmente só descobriremos isso depois de gastar muito tempo e dinheiro!
Cezar Taurion é consultor da Pricewaterhouse Coopers
[email protected]
