Uma recente conversa com um analista de pesquisa de mercado nos mostrou um fato curioso. Ele tinha recém concluído uma pesquisa para uma empresa de hardware sobre o mercado CRM e os investimentos em Business Intelligence/Data Warehouse voltados a estas iniciativas. O resultado foi surpreendente: quase que 100% responderam a pergunta “Você tem um DataWarehouse em casa” com um vibrante “sim”. Mas, como ele conhece bem seu mercado (não foi a primeira pesquisa deste gênero), ele visitou pessoalmente algumas destas empresas. E comprovou que na verdade o que diziam ser sistemas de Business Intelligence/Data Warehouse eram planilhas Excel com gráficos muito bonitos, sem dúvida, ou ferramentas OLAP em cima de bases de dados operacionais, sem processo de coleta e manuseio de informações históricas.
Na verdade, fala-se muito de Data Warehouse (DW) nos projetos CRM (os CRM analíticos), mas são realmente poucos os casos concretos. Mas, desenvolver Data Warehouse não é tão simples assim. É muito mais um processo que um projeto, pois não tem início, meio e fim, mas fases de implementação e manutenção contínua. A constante mudança nos dados, a introdução de novos dados, o volume crescente de informações armazenadas, a capacitação e conseqüentemente maior nível de exigência dos usuários e mesmo as mudanças no próprio negócio afetam sensivelmente o Data Warehouse. Mantê-lo atualizado e útil para a organização não custa barato…
Os insucessos, muitos por sinal, não freqüentam as páginas da mídia, o que é muito compreensível… Mas, quais são as principais causas de falhas?
Antes de mais nada é fundamental que as expectativas do projeto de criação do CRM analítico e seu Data Warehouse sejam as mais realistas possíveis. O “timing” do projeto deve ser bem analisado. Se a empresa estiver em pleno processo de efervescência, com mudanças e transformações organizacionais e tecnológicas afetando as mentes e agendas dos executivos, será difícil achar alguns minutos para se falar sobre o assunto e muito menos obter sua atenção por um tempo razoável.
Não devemos nos esquecer que um CRM afeta toda a empresa e, por conseqüência, a camada gerencial da organização. Identificar claramente as necessidades dos usuários é fator crítico de sucesso. Para isso é necessário dedicação e tempo para entrevistas.
Sem o envolvimento e comprometimento do pessoal de decisão, é perda de tempo começar o projeto. Se os futuros usuários não estiveram anteriormente expostos a decisões baseadas em telas/relatórios gerenciais e não tem uma clara visão do potencial e restrições do Data Warehouse, o caminho será bem mais árduo. Talvez nem saibam o que exigir de um DW…
O prazo deve ser realista. Todos nós queremos resultados rápidos, mas quão rápido nem sempre é imediato…
O tempo do projeto de criação do Data Warehouse e seu custo depende de diversas variáveis, que incluem expertise interna e externa, tecnologias adotadas, identificação e qualidade dos dados necessários, nível de envolvimento dos usuários, diversidade de tecnologias envolvidas no processo de obtenção dos dados, e assim por diante.
Dispor de expertise é importante. Um projeto de Data Warehouse apresenta muitas diferenças em relação aos projetos tradicionais de desenvolvimento de sistemas. Se os profissionais envolvidos não tiverem experiência (mas, apenas teorias fornecidas pelos vendedores dos softwares) a chance de sucesso é próxima de zero.
O projeto deve ter um objetivo de negócio perfeitamente visível. Que resultados serão alcançados? Quem será beneficiado pelo Data Warehouse e como? Sem este beneficiado (o executivo patrocinador) as coisas não andarão bem.
O modelo de relacionamento com os clientes deve estar bem representado no Data Warehouse. Ou seja, que dimensões queremos? Quais os atributos e o nível de granulosidade (detalhamento) adequado? Quais as séries históricas que serão armazenadas? Muitos dos insucessos se devem a pouca atenção dispensada a esta fase. Há uma certa tendência de se mergulhar direto na preparação das telas e gráficos (o lado lúdico do Data Warehouse), deixando-se em segundo plano a base estrutural do projeto: seu modelo de negócios e informações.
Uma crise potencial aparece na hora de coletar os dados. Onde eles se encontram? Em que tecnologias são armazenadas? Qual o grau de qualidade destes dados? Muitas vezes são encontradas informações em sistemas em tecnologias mais díspares possíveis, variando de arquivos Clipper a bases de dados Oracle e DB2. Como conciliar estas diversas tecnologias e quais informações estão mais corretas e atualizadas?
Muitos projetos de Data Warehouse dispensaram pouca atenção a esta etapa. Já vimos projetos com estimativas de apenas duas semanas para esta fase, e levarem muitos meses!
Assim, quando uma série de bandeirinhas vermelhas começarem a se agitar, é tempo de se repensar o projeto de Data Warehouse.
Para auxiliar as iniciativas de Data Warehouse criamos um rápido check list que aborda as principais etapas de sua construção, que pode servir para identificar pontos de atenção, aqueles detalhes em que as vezes passamos por cima e que podem criar problemas mais a frente.
Preencher o check list abaixo é bastante simples. É recomendado que seja feito pelo responsável pelo projeto de Data Warehouse e não exige preparação prévia. O produto final será uma maior visão do processo como um todo e eventualmente a identificação de pontos de atenção que merecerão ações preventivas e/ou corretivas.
1. O projeto Data Warehouse tem um usuário patrocinador?
2. Os objetivos e expectativas com relação ao Data Warehouse estão claramente identificados?
3. O nível gerencial que está apoiando o projeto é decisório?
4. Os orçamentos para o projeto estão claramente identificados e disponíveis?
5. Na ótica do patrocinador, o nível de importância para o negócio é alto e estratégico?
6. A equipe alocada ao projeto tem experiência e capacitação em atividades similares?
7. O mix de perfis profissionais que compõem a equipe está adequada ao tipo de projeto?
8. Os usuários tem a necessária capacitação para tirar proveito de um Data Warehouse?
9. O tempo alocado ao projeto é adequado à tarefa em mãos?
10. Todas entidades/dimensões de dados que comporão o cubo estão perfeitamente identificadas e claramente definidas?
11. Todos os relacionamentos entre estas entidades/dimensões estão claramente identificadas?
12. O nível de granulosidade está perfeitamente identificado?
13. Os itens acima (10 a 12 ) foram aprovados pelos usuários que usarão o Data Warehouse?
14. Os dados que irão para o Data Warehouse já estão claramente localizados?
15. Os dados que irão para o Data Warehouse podem ser facilmente transformados, de maneira automática?
16. Os procedimentos para a conversão dos dados que irão para o Data Warehouse são simples de serem implementados?
17. Foram definidos procedimentos adequados para “cleansing” dos dados?
18. Os metadados serão gerados automaticamente?
19. Atualizações no desenho do Data Warehouse serão refletidos automaticamente no metadados?
20. As ferramentas de consulta selecionadas usarão automáticamente o metadados?
21. O banco de dados que suportará o Data Warehouse tem capacidade comprovada para processar o volume de dados e transações estimados?
22. A organização tem experiência prévia com este banco de dados?
23. Existe suporte técnico adequado e disponível à organização para este banco de dados?
24. A plataforma de hardware escolhida para acomodar o Data Warehouse tem capacidade comprovada para suportar o volume de trabalho estimado?
25. Foi efetuado um trabalho de “capacity planning” para dimensionar a capacidade computacional?
26. Existe experiência prévia, na organização, com esta plataforma?
27. Existe suporte técnico adequado e disponível à organização para esta plataforma?
28. Foi estimada a taxa de crescimento do Data Warehouse (em volume de dados e número de usuários) para um, dois e três anos à frente?
29. A escalabilidade da plataforma foi analisada?
30. Os períodos de pico de uso do Data Warehouse (hora, dia, semana ou mês do ano) foram identificados?
31. Consultas muito demoradas terão tratamento à parte?
32. O tempo reservado à manutenção do Data Warehouse (“refresh” dos dados, reorganização, backup, etc.) foram estimados?
33. O tempo reservado à manutenção do Data Warehouse é adequado?
34. O ciclo de “refreshment” e “update” do Data ‘Warehouse foi definido e aprovado pelos usuários?
35. O volume de armazenamento de dados para o Data Warehouse (dados do Data Warehouse, “index storage”, áreas de trabalho, classificação, etc.) foi estimado e reservado?
36. O armazenamento está adequadamente dimensionado para suportar a demanda de trabalho?
37. Foi definido nível de serviço para o Data Warehouse (tempo de resposta, nível de disponibilidade, rapidez de atualização dos dados, etc.)?
38. Os procedimentos de backup e recovery foram definidos?
39. O tempo de recuperação do Data Warehouse, em caso de problemas, está de acordo com os anseios da organização?
40. Existem procedimentos e ferramentas de monitoração da performance do Data Warehouse?
41. O nível de segurança do Data Warehouse está de acordo com a política de segurança da informação adotado pela empresa?
42. Os riscos de segurança ao Data Warehouse foram identificados e discutidos?
43. Existem (ou existirão) procedimentos e profissionais alocados à manutenção do Data Warehouse?
44. Dados que serão acessados freqüentemente terão tratamento à parte?
45. Dados que forem identificados como inativos terão tratamento à parte?
46. Existem procedimentos para “archiving” dos dados inativos?
47. Os itens 44 a 46 foram discutidos e aprovados com os usuários?
48. As ferramentas de consulta estão adequadas ao nível de exigência dos usuários?
49. Os usuários foram adequadamente treinados nas ferramentas?
50. Existe suporte técnico adequado e disponível à organização com relação às ferramentas de consulta?
Quanto maior for o número de respostas “NÃO”, maiores deverão ser as preocupações. Mas, agindo-se preventivamente, no ponto certo, com certeza os projetos de Data Warehouse alcançarão seus objetivos. E nem pense em começar o projeto se:
a) Não haver um executivo de linha de negócio patrocinador (Não vale o executivo de informática, pois ele não será beneficiado diretamente pelas informações do Data Warehouse);
b) A empresa estiver em ebulição, com implantações de outras tecnologias (um ERP, por exemplo) e mudanças organizacionais;
c) Não houver objetivos de negócio claramente definidos;
d) Não haver comprometimento dos gerentes e executivos de negócio, em tempo e interesse;
e) Não houver orçamento adequado (sem patrocinador e dinheiro, não se faz nada…);
f) Não houver expertise adequada (interna e externa);
g) Não houver um gerente de projeto experiente e com tempo dedicado (gerenciar por poucos minutos por dia será insuficiente para resolver as inevitáveis crises que aparecerão…);
h) Os usuários não estão demandando um sistema de DW (inclusive por desconhecimento ou mesmo falta de capacitação);
Não houver um planejamento adequado, inclusive com projeto piloto e implementações graduais.
Cezar Taurion é consultor da Pricewaterhouse Coopers [email protected]
