Fatores críticos de implementação de data warehouse

Fatores críticos de implementação de data warehouse Samuel Stábile Edson Walmir Cazarini USP-EESC - Escola de Engenharia de São Carlos - Área: Engenharia de Produção e-mail: sstabile@ssnet.com.br, cazarini@sc.usp.br Abstract: Nowadays, the information is the most important resource in the conduction of organizations. They frequently seek forms of increasing their competitiveness through the strategic use of their information. The data warehouse is with no doubt, a powerful tool in the search of this objective for consolidating the organizational information in only one format and specific for strategic use. Even so, reports of failures are constant. This article lists some critical factors to be observed in the implementation of the data warehouse. Key words: data warehouse, critical factors, implementation, information management, competitiveness Resumo: A informação é atualmente, o recurso mais importante na condução das organizações. Estas freqüentemente procuram formas de aumentar sua competitividade através do uso estratégico de suas informações. O data warehouse é sem dúvida uma ferramenta poderosa na busca deste objetivo por consolidar as informações organizacionais em um formato único e específico para uso estratégico. Porém, relatos de fracassos são constantes. Este artigo lista alguns fatores críticos a serem observados na implantação do data warehouse. Palavras chave: data warehouse, fatores críticos, implementação, gerenciamento da informação, competitividade Introdução O data warehouse está na pauta de discussão da maioria das organizações, que em um mercado de acirrada concorrência, sabe que necessita utilizar estrategicamente suas informações para ganho de competitividade. O fato de o data warehouse integrar os dados espalhados pela organização, em um formato único e específico para consultas, certamente é motivo para que estas iniciem o projeto pelo grande potencial de benefícios possíveis. Porém, a implementação de um data warehouse é cara e complexa. Relatos de fracassos são constantes. Este trabalho aborda alguns fatores críticos a serem observados quando da implementação de um data warehouse. Avaliação inicial e foco estratégico De acordo com ADELMAN (1998), muitas organizações abraçam o projeto de data warehouse sem se perguntar o que realmente elas ganharão com isso. Uma avaliação completa, com estudos e levantamentos de benefícios deve ser executada antes de se dar início ao projeto, assim como todo o custo e o tempo que serão demandados. Segundo o mesmo autor, objetivos vagos são prejudiciais, e ainda, segundo CIPOLLA (1999), os objetivos organizacionais devem ser claros para guiar o projeto desde o início. De acordo com TAURION (1998), o primeiro passo é definir porque o data warehouse será desenvolvido. Segundo o mesmo autor, o projeto é caro e complexo de implementar, e mesmo após a implementação, demanda grandes esforços de desenvolvimento e de suporte, eliminando a possibilidade de não ser assistido. Segundo NIMER (1998), devido à grandiosidade do projeto, torna-se necessário um plano de implementação bem definido, além de justificativas reais dos benefícios aos negócios. A mesma afirmação é feita por VASCONCELLOS (1999). O data warehouse está diretamente ligado à estratégia da organização, e especial atenção deve

ser dada ao início do projeto, quando os gerentes definem quais assuntos, quais informações e quais níveis de resumos dessas informações serão abrangidos. Erros nesta fase podem desviar totalmente o foco do projeto. Áreas críticas da organização, que são essenciais para a competitividade, devem ser enfocadas primeiramente, nunca perdendo de vista, as metas corporativas. Dessa forma, os benefícios do data warehouse serão maiores e prontamente percebidos, e o projeto ganhará crédito para prosseguir. O imediatismo e expectativas irreais devem ser gerenciadas desde o início do projeto. Devido à sua complexidade, o data warehouse demanda tempo, e tempo pode ser um problema na organização. O imediatismo, que prejudica muitos projetos, não só em informática, deve ser trabalhado desde o início do projeto. O patrocinador do projeto, ao difundir a idéia do data warehouse pela organização, deve deixar bem claro o tempo para que os resultados apareçam. Sempre que novos projetos surgem nas organizações, sejam da área de informática ou não, imediatamente cria-se uma expectativa muito grande, que pode ser prejudicial. Os potenciais benefícios do data warehouse devem ser claramente especificados desde o início do projeto. O discurso utilizado para difusão da idéia na organização também deve ser cuidadoso. A forma como um projeto é apresentado tem influência direta na sua aceitação ou não pelos usuários. O projeto deve ser guiado pelo negócio e não pela tecnologia Segundo TAURION (1998) e também CIPOLLA (1999), um data warehouse deve ser guiado pelo negócio, e não pela tecnologia. Com o objetivo de atender às necessidades estratégicas da organização, o projeto do data warehouse deve seguir claramente os requisitos dos usuários, que deverão ter suas necessidades - informações e formatos de consultas - plenamente atendidos. As decisões de projeto deverão ser tomadas com base nos requisitos do negócio, e não com base na tecnologia. A equipe de sistemas, somente após conhecer claramente as necessidades dos usuários, deverá oferecer soluções técnicas que atendam estas necessidades. Se for usado o caminho inverso, dificilmente os usuários terão suas necessidades corretamente atendidas, e o projeto cairá em descrédito. Segundo RADEN (1998), mesmo sendo o suporte ao processo decisório uma das áreas mais atuais da computação, o foco é sempre essencialmente técnico, sem muita atenção aos processos de negócios que devem ser melhorados. O mesmo autor afirma ainda que, o data warehouse deve ser focado para responder questões e resolver problemas com os quais as pessoas tem que lidar dentro da organização. De acordo com ABRAMSON (2000), na área de tecnologia da informação, todos querem vender soluções, mas ninguém quer saber quais são os problemas dos usuários. Segundo TAURION (1998), experiências mostram sempre que o sucesso de um data warehouse está diretamente relacionado com o atendimento às necessidades do negócio e nunca por tecnicismo, e ainda, que os projetos tocados somente pela área técnica estão condenados ao fracasso. Patrocínio para o projeto De acordo com TAURION (1998), BISCHOFF (1998) e com VASCONCELLOS (1999), o projeto deve ter um patrocínio forte e claro dento da organização, já que além do tempo e do gasto financeiro, o data warehouse provoca várias mudanças de ordem política e estrutural. Este patrocinador deve estar ciente das dificuldades que irá encontrar e deve difundir corretamente a idéia do data warehouse na organização. A alta administração deve manifestar constantemente apoio explícito ao projeto e auxiliar a equipe de sistemas na condução dos trabalhos. Integração da área de sistemas e os usuários Muito fala-se sobre o envolvimento dos usuários nos projetos de informática, mas os problemas surgem com freqüência. Nos projetos de data warehouse podemos observar basicamente os mesmos problemas que ocorrem com a implantação de outros projetos, porém aqui, este envolvimento é mais crítico. Os gerentes, futuros usuários, devem ser inseridos no processo desde o início e devem sentir-se co-responsáveis pelo sucesso. O data warehouse está em constante estado de desenvolvimento e segundo BISCHOFF (1998), uma correta integração do usuário é fundamental. Já TAURION (1998), define a palavra do usuário como sendo a mais importante. Segundo VECCHIA (1998), uma das árduas tarefas no desenvolvimento de data warehouse é o levantamento das necessidades dos usuários, o que depende de uma correta integração. De acordo com PEREIRA (1999), deve-se trabalhar em sintonia com o usuário final para entender suas necessidades. O pessoal de desenvolvimento deve ser composto por pessoas das áreas de negócios e de sistemas. A integração

e a comunicação devem ser claras e constantes para o que data warehouse atenda plenamente o objetivo de apoiar satisfatoriamente os processos decisórios estratégicos. A área de sistemas é uma das áreas mais rejeitadas nas organizações. Com certeza, uma das maiores causas dessa rejeição é a comunicação incorreta desenvolvida pelos profissionais de informática e seu enfoque extremamente técnico. Quanto melhor for a comunicação entre as áreas de uma empresa, melhor será a implantação de uma tecnologia ou ferramenta. O fator humano geralmente é desprezado pela maioria dos projetos, e conseqüentemente, está entre as maiores causas de fracasso, seja em projetos de informática ou não. Quanto ao data warehouse, a maior parte dos fracassos dá-se por motivos não técnicos. Isto prova que por melhor que um projeto seja tecnicamente concebido, de nada valerá se as pessoas envolvidas não o utilizarem corretamente. Segundo ABRAMSON (2000), as pessoas precisam de tempo para mudar sua postura mental nas implantações de novas técnicas nas organizações. Política da organização O data warehouse provoca várias mudanças de ordem política e estrutural na organização, já que o projeto cruza barreiras departamentais, democratiza o acesso aos dados e modifica o processo decisório. Estas mudanças podem encontrar forte resistência de algumas pessoas na organização, já que tradicionalmente, o ser humano é avesso à mudanças. O processo de extração dos dados dos sistemas de informação tradicionais para o data warehouse pode revelar problemas escondidos durante anos nos departamentos. A exposição dos dados departamentais pode causar pavor a alguns funcionários, que por trabalharem muito tempo no departamento, sentem-se donos dos dados. Outro problema é que as pessoas divergem sobre as informações necessárias à uma decisão, sobre a forma de consultar estas informações e sobre a forma de decidir. O patrocinador e a equipe de sistemas devem estar cientes dessas dificuldades e ter habilidades para contorná-las sem prejuízo do projeto. Segundo CIPOLLA (1999), os diferentes departamentos podem falar diferentes línguas e possuírem objetivos próprios. As pessoas envolvidas devem ser treinadas para trabalharem juntas e colocarem as metas corporativas acima de tudo. A construção de um data warehouse demanda o envolvimento de vários profissionais, e mesmo após sua disponibilização para uso, essa demanda continua, pois seu desenvolvimento é constante e o data warehouse também requer monitoramento e gerenciamento. Segundo BISCHOFF (1998), isso requer uma clara definição de papéis e responsabilidades e também uma correta coordenação destes vários profissionais. De acordo com VASCONCELLOS (1999), as políticas de poder são barreiras poderosas de transpor quando você necessita acessar informações corporativas que estão em poder de outras divisões ou diretorias. Assim, se não houver um patrocínio forte acima de tudo isso, o projeto certamente será prejudicado. Ferramentas de consultas Apesar do vasto discurso de benefícios que serão possíveis com o data warehouse, sem ferramentas que proporcionem consultas e análises satisfatórias para os gerentes, o projeto pode ser um grande fracasso. Com o objetivo de prover acesso fácil e rápido aos dados desejados pelos gerentes, e sem a utilização de intermediários, as ferramentas de consultas devem ser bastante amigáveis, fáceis de usar, possuir recursos gráficos, interface intuitiva e desempenho satisfatório. De acordo com PEREIRA (1999), é extremamente necessário resolver os gargalos de desempenho antes de colocar o data warehouse em uso. Quando do projeto do data warehouse, os gerentes listam suas consultas inicialmente desejadas, e a equipe de sistemas deve prover, quando da colocação do data warehouse em funcionamento, essas consultas para os gerentes. Porém, com a utilização do data warehouse, os gerentes percebem seu grande potencial e rapidamente vão querer incrementar seu uso. Novas consultas serão solicitadas e a equipe de sistemas deve estar pronta para atendê-las rapidamente. Segundo ADELMAN (1998), um recurso valioso e produtivo é prover os gerentes com aplicações que lhes permitam criar suas próprias consultas. Dessa forma, o data warehouse ganhará cada vez mais crédito dos gerentes e sua utilização será maximizada. Um outro recurso interessante é a interatividade de certas ferramentas de consultas. O usuário interage com o aplicativo, e vai explorando as informações através de vários passos, recebendo apoio direto para sua decisão. Outra característica importante, é a possibilidade dos gerentes literalmente navegarem pelos vários níveis de resumos das informações. Por exemplo, em uma análise gráfica, com o simples clicar do mouse sobre um indicador de um gráfico, o gerente tem acesso aos dados que deram origem a aqueles resultados. Porém, convém salientar que isto depende da capacidade da ferramenta de consulta e dos níveis de

detalhamento dos dados contidos no data warehouse. De acordo com ADELMAN (1998), é de suma importância que os usuários tenham acesso fácil e imediato aos dados cruciais. Cabe salientar também que sem um correto treinamento e suporte possibilitados aos gerentes, o sucesso do projeto também fica comprometido. É somente através das ferramentas de consultas que os gerentes terão contato com o data warehouse, e se esse contato não for bem feito, rapidamente o projeto cai em descrédito. Segundo INMON (1997), um dos pressupostos básicos do data warehouse consiste no acesso flexível e imprevisível aos dados. Nível de granularidade Nível de granularidade é o nível de detalhamento dos dados e segundo INMON (1997), constitui a decisão mais importante do projeto. O nível de granularidade influi diretamente nas possibilidades de consultas e no desempenho do data warehouse. Quanto maior o nível de detalhamento dos dados, maiores as possibilidades de consultas e de navegação pelos vários níveis de detalhe, porém, utilizando um tempo maior de processamento, um espaço maior de armazenamento e acarretando maiores dificuldades de gerenciamento, já que o volume de dados crescerá mais rapidamente. Quanto menor o nível de detalhamento dos dados, menores são as possibilidades de consultas, porém, o tempo de resposta, o espaço requerido para armazenamento em disco e as dificuldades de gerenciamento também são menores. Cabe à equipe de sistemas, projetar corretamente o data warehouse para atender satisfatoriamente às consultas e análises dos gerentes, porém com tempos de respostas satisfatórios e com o tamanho e o crescimento do banco de dados do data warehouse, absolutamente gerenciáveis, o que constituem questões críticas. De acordo com PALMA(1998), torna-se necessário um equilíbrio entre a necessidade por dados analíticos em forma resumida e os dados detalhados. Extensibilidade, flexibilidade e integração O data warehouse, por ser um ambiente que integra várias ferramentas, tecnologias e processos, necessita de uma cuidadosa escolha de seus componentes, visando sempre a integração, o desempenho e a expansibilidade destes componentes. O data warehouse deve ser absolutamente extensível, visando a abrangência de novas áreas da empresa, novos dados, novos usuários, novas consultas, novas ferramentas e novas necessidades estratégicas do negócio. A gerência do projeto deve ter habilidade para avaliar e integrar as diversas ferramentas e tecnologias disponíveis. Segundo TAURION (1998), a extensibilidade é crítica, pois o data warehouse deve ser capaz de acomodar as mudanças cada vez mais rápidas dos negócios. De acordo com RADEN (1998), a flexibilidade é o principal objetivo do projeto, onde a habilidade de evoluir continuamente para atender às necessidades do usuário é mais crucial ainda do que a eficiência. Segundo TAURION (1998), o data warehouse não é um produto nem um conjunto de produtos, mas processos suportados por várias tecnologias. De acordo com SOBRAL (1998), um data warehouse pode dobrar de tamanho anualmente, sendo assim, torna-se muito importante a capacidade de crescimento do hardware adotado, como por exemplo, o banco de dados, que deve ter a robustez necessária para acompanhar o crescimento do data warehouse. Além disso, segundo BISCHOFF (1998), novas exigências dos usuários são constantes e o projeto deve ter a capacidade de integrá-las. As ofertas de componentes e ferramentas crescem bastante, assim como as promessas dos vendedores, que devem ser analisadas com cuidado. O projeto de um data warehouse é único para cada organização. Depende das áreas do negócio a serem incluídas no data warehouse, assim como as informações e seus níveis de detalhamento. A extração das informações dos bancos de dados dos sistemas de informação tradicionais para o data warehouse é bastante crítico e oneroso. É bastante difícil para um fornecedor ter soluções prontas e satisfatórias para todos os casos. Torna-se necessário às organizações, tomarem atitudes bastantes críticas e embasadas quando decidem pela implantação de um data warehouse. Os fornecedores de produtos e serviços de tecnologia de informação estão trabalhando para fornecer mais e melhores soluções a um mercado em expansão e bastante promissor. Por sua diversidade e necessidade de integração, segundo TAURION (1998), um data warehouse não pode ser simplesmente comprado e instalado. Segundo o mesmo autor, as soluções são únicas para cada projeto e torna-se necessário avaliar as propostas dos fornecedores com uma certa desconfiança. De acordo com SOBRAL (1998), poucos fornecedores estão capacitados para condução segura de um projeto de data warehouse. Segundo PALMA(1998), mesmo com bastante propaganda veiculada, nenhum vendedor consegue prover uma solução completa

para o problema, e ainda, segundo o mesmo autor, o produto tem que ser flexível com relação à mudanças na estrutura de informação. De acordo com PEREIRA (1999), o usuário perceberá novas necessidades constantemente, pois seu conhecimento dos dados será gradual. Assim, o projeto deve ser flexível o bastante para acomodar essas novas necessidades. Data mart Alguns autores como SOBRAL (1998), NIMER (1998), KONDRATIUK (1998) e VASCONCELLOS (1999), justamente pelo data warehouse ser caro e complexo, defendem a implantação inicial de um data warehouse departamental, o data mart. O data mart é um data warehouse menor, específico para um departamento, onde as facilidades de implantação são maiores, e os riscos e custos menores. Com um data mart, o retorno sobre o investimento aparece bem mais cedo, e torna-se mais fácil ganhar crédito e confiança na organização para um projeto maior, que englobe os demais departamentos posteriormente. Se uma das características principais do data warehouse é integrar os diversos bancos de dados da organização, quanto mais bancos de dados este englobar, teoricamente, maior será o benefício alcançado. Mas, como o data warehouse é específico para cada organização, pode ser que apenas um data mart seja suficiente para apoiar corretamente o processo decisório estratégico e permitir aumento de competitividade. Isso quem deve decidir são os gerentes usuários. Mesmo em apenas um departamento, vários sistemas de informação podem ter sido desenvolvidos ao longo do tempo, e o acesso à essas informações que tem várias idades é praticamente impossível. O data warehouse resolve o problema integrando corretamente, e da forma desejada pelos gerentes, todas as informações deste vários bancos de dados, permitindo consultas e análises satisfatórias, independente do cruzamento com informações de outros departamentos. Porém, se a organização decidir por implementar um data mart, desde o início do projeto, a futura integração de outros departamentos deve ser focada. Se um data mart é projetado isoladamente, quando a organização decide expandi-lo, ou integrá-lo com outros data marts, inúmeros problemas poderão surgir e o projeto estará condenado ao fracasso. Extração e carregamento dos dados O processo de extração dos dados dos bancos de dados dos sistemas de informação tradicionais e seu carregamento para o data warehouse, é bastante crítico e oneroso. Segundo PALMA (1998), o processo de aquisição de dados é caro e complexo. De acordo com BOHN, apesar desta complexidade, o processo de conversão de dados com qualidade é a base para um data warehouse bom e funcional, e já que o data warehouse contém as informações mais importantes para a tomada de decisão de uma corporação, pode ser considerado bastante crítico. Realmente é bastante complicado rastrear e mapear informações de vários bancos de dados, projetados por diferentes profissionais, em diferentes épocas, que podem estar em diferentes formatos, plataformas e tecnologias, espalhados por toda a organização, às vezes sem documentação e geralmente redundantes. Segundo WILLIAMS, o carregamento dos dados para o data warehouse é uma das etapas mais importantes do projeto, e muitas organizações a subestimam. De acordo com VASCONCELLOS (1999), os dados dos clientes, por exemplo, podem figurar em diversas fontes e quase sempre de maneiras diferentes. Segundo o mesmo autor, erros básicos de definição e preenchimentos de campos são encontrados nas bases operacionais. De acordo com BOHN, esta etapa pode revelar vários problemas nos dados de origem e quase sempre os usuários acusam o processo de extração como causador dos problemas. Assim, a equipe de sistemas, com o apoio do patrocinador do projeto, deve ser hábil o suficiente para contornar os problemas deste tipo. Um outro problema é que a equipe de sistemas pode gastar grande parte de seu tempo neste processo e não consegue atender satisfatoriamente às consultas desejadas pelos usuários, o que pode condenar o projeto ao fracasso. Segundo CIPOLLA (1999), a equipe de sistemas pode gastar 80% do tempo na preparação dos dados. É necessário um correto planejamento, coordenação e execução deste processo, porém sem perder de vista as demais demandas do projeto. Segundo MANNI & DORSA (1998), uma providência extremamente importante é centralizar o desenvolvimento dos sistemas de informações tradicionais e do data warehouse. Dessa forma, os dados dos novos sistemas de informação, que futuramente irão preencher o data warehouse, já serão do conhecimento da equipe de desenvolvimento deste, o que facilita imensamente o processo de extração e contribui para a qualidade dos dados.

Qualidade dos dados A qualidade dos dados que chega aos usuários é de suma importância. Segundo VECCHIA (1998), as principais causas de insucesso em projetos de data warehouse incluem a qualidade dos dados e o potencial de utilização destes pelos usuários. De acordo com TAURION (1998), o critério básico de sucesso é a qualidade da informação disponibilizada, e ORR (1998) compartilha a mesma afirmação. O processo de extração e carregamento é complexo, e se os usuários perceberem qualquer problema ou dados inconsistentes, deixarão de utilizar o sistema. É necessário conquistar a confiança do usuário desde o início, com dados confiáveis, no formato e no momento desejado. Segundo WILLIAMS, os dados não confiáveis podem resultar em decisões mal tomadas que tem efeitos adversos e que afetam diretamente o lucro, e os dados devem ser precisos para garantir que as decisões tomadas com base neles, sejam boas decisões de negócios. Monitoramento Após sua disponibilização para uso, o data warehouse requer um monitoramento constante. Tarefas importantes são a verificação do crescimento do volume de dados e o desempenho dos tempos de respostas. Porém, outro aspecto importante a ser monitorado é a freqüência de utilização dos dados. Certos dados poderão apresentar uma utilização bem mais freqüente que os demais. Dessa forma, a equipe de sistemas deverá trabalhar para melhor disponibilizar estes dados e verificar com os usuários a possibilidade de consultas mais sofisticadas sobre estes dados. Por outro lado, com o monitoramento de utilização, pode-se verificar também quais dados são menos utilizados ou mesmo não são utilizados. Segundo ORR (1998), estes dados representam custos, por ocuparem espaço e dificultarem o acesso aos dados realmente necessários. Deve-se discutir a possibilidade destes dados sofrerem resumos gradativos, serem alocados em meios de armazenamento alternativos ou até mesmo serem eliminados. O monitoramento deve resultar em indicadores que possibilitem buscar sempre a otimização do acesso aos dados mais utilizados. Ciclicidade dos dados Segundo INMON (1997), este fator crítico do projeto refere-se ao tempo que uma alteração nos bancos de dados operacionais leva para refletir no data warehouse. Este tempo pode ser crucial em tipos de negócios mais agressivos, em que os decisores necessitem dos dados atualizados com maior rapidez. Porém, quanto mais rápida esta atualização, mais cara e complexa será a tecnologia empregada. Por outro lado, se os decisores não tiverem as informações necessárias no momento necessário, o data warehouse perde seu sentido. Conteúdo do data warehouse A característica principal do data warehouse é integrar os diversos bancos de dados desenvolvidos ao longo dos anos nos diversos departamentos da organização, reunindo-os em um formato único e específico para consultas. Partindo-se desta idéia, pode-se chegar a casos em que o data warehouse torna-se um grande papa-dados inútil. Todas as bases operacionais vão sendo englobadas sem um objetivo definido, e o data warehouse cresce rapidamente. As dificuldades de gerenciamento também aumentam e o desempenho, quando se faz uma consulta à informações realmente necessárias, diminui consideravelmente. O excesso de dados sem objetivos reais também pode esconder os dados que são realmente necessários aos usuários. Com o objetivo de apoiar satisfatoriamente o processo decisório de áreas estratégicas da organização, o data warehouse deverá conter somente as informações julgadas necessárias pelos usuários. Segundo WILLIAMS, as informações devem ser relevantes para as necessidades do negócio. Ferramenta automática de manutenção dos metadados Os metadados são os dados sobre os dados do data warehouse. Eles contém toda a descrição do data warehouse, de sua estrutura, dos dados contidos e dos históricos das extrações e carregamentos de dados. Essas informações são de suma importância para o gerenciamento do data warehouse e devem estar constantemente atualizadas. Porém, segundo INMON & HACKATHORN (1997), sem uma ferramenta automática de manutenção dos metadados, estes rapidamente estarão defasados, em relação ao progresso que o data warehouse sofre, comprometendo seu gerenciamento eficaz.

Diferentes estratégias, diferentes projetos Mesmo que organizações atuem em um mesmo ramo e possuam a mesma estrutura, dificilmente um data warehouse será igual a outro. Primeiro, pela diversidade dos sistemas de informação existentes que passarão pelo complexo processo de extração e carregamento dos dados. Segundo, e principalmente, pelo enfoque estratégico que o data warehouse possui. Cada organização decide quais áreas seu data warehouse irá englobar para apoiar seu processo decisório em busca de competitividade. Definidas as áreas, ainda devem ser definidos quais dados e em quais níveis de resumo estes serão carregados para o data warehouse. Assim, por mais que os fornecedores de ferramentas avancem, é sempre muito complexo o processo de escolha de soluções, mesmo porque o mercado de data warehouse é recente. Segundo NIMER (1998), o data warehouse não pode ser comprado pela organização como se fosse uma ferramenta, mas precisa ser construído como uma arquitetura. Dados externos Segundo INMON (1997), os dados cuja fonte são os sistemas existentes na organização formam os dados internos, e representam o maior conteúdo do data warehouse. Estes dados internos podem significar apenas parte dos dados necessários à condução da organização. Porém, o data warehouse também pode acomodar dados externos, como dados econômicos ou concorrenciais, que tornam-se bastante úteis em um mercado altamente competitivo. Conclusão Em um mercado altamente competitivo e de forte concorrência, as organizações sabem que informação é um recurso valioso. Porém, a dificuldade de acesso às informações estratégicas, enfrentada pelo alto escalão da maioria das organizações, é um paradoxo. O data warehouse, quando corretamente implementado, permite este acesso de forma satisfatória. Porém, devido à sua complexidade e surgimento recente, muitos projetos de data warehouse fracassam. Este trabalho listou alguns fatores críticos a serem observados quando da implantação do projeto com o intuito de aumentar os índices de sucesso. Referências bibliográficas A terceira idade dos BDs. Revista Computerworld. 16/Ago/1999. pp. 38-41 O desenho ideal. Revista Computerworld. Suplemento especial data warehouse. 29 Jan/1996. pp 8-12 Qualidade dos dados no centro das atenções. Revista Information Week. 20/Out/1999. pp. 26-29 Quality control for data on the move. http://www.dci.com/news/datawarehouse /articles/1998/05/05qualty.htm. Acesso em 04/05/2000 A inteligência do sistema. Revista Computerworld. Suplemento especial data warehouse. 29/Jan/1996. pp. 21-24 Um trabalho de equipe. Revista Computerworld. Suplemento especial data warehouse. 29/Jan/1996. pp. 25-26 ABRAMSON, G. Equilíbrio de prioridades. Revista HSM Management. Mai/Jun 2000. pp. 142-146 ABRAMSON, G. A TI muda tudo. Revista HSM Management. Nov/Dez 1999. pp. 102-106 ACKOFF, R. L. Gerência em pequenas doses. Rio de Janeiro, Editora Campus, 1988 ADELMAN, S. Establishing clear data warehouse objectives. http://datawarehouse.dci.com /articles/1998/07/07clear.htm. 07/Jul/1998. Acesso em 04/05/2000 ALBRECHT, K. A terceira revolução da qualidade. Revista HSM Management. Nov/Dez 1999. pp. 108-112 AMERICANO, A.C. O data warehouse que deu certo. Revista Information Week. 08/Dez/1999. pp. 44 BISCHOFF, J. Data warehouse readiness assessments http://datawarehouse.dci.com/articles/ 1998/06/23assess.htm. 23/Jun/1998. Acesso em 04/05/2000 BISPO, C. A. F. & CAZARINI, E. W. Transformando dados em informações via data mining. Revista Developers. Jan/1999. pp. 36-38

BISPO, C. A. F. (1998). Uma análise da nova geração de sistemas de apoio à decisão. Dissertação de mestrado. EESC-USP BOHN, K. Convertendo dados para warehouses. Revista DBMS. v 1. n 3. pp. 32-37 BROOKS, P. Procurando dados em todos os lugares errados. Revista DBMS. Nov/1997. pp. 29-35 CIPOLLA, V. Four tips to better warehouse value. http://datawarehouse.dci.com/articles/ 990323tips.htm. 23/03/1999. Acesso em 04/05/2000 CORRÊA, L.H. A informação na ponta dos dedos. Revista Computerworld. Suplemento especial data warehouse. 29/Jan/1996. pp. 4-6 DALFOVO, O. & GRIPA, R. Data warehouse: usando a técnica de cubo de decisão. Revista Developers. Abr/1999. pp. 12-17 FORESTI, N. Um business intelligence fácil de usar. Revista Information Week. 08/Dez/1999. pp. 50-51 GOLDBACH, R. Gestão corporativa: a informação a serviço da competitividade. Revista Developers. Abr/1998. pp. 20-21 INMON, W. H. Como construir o data warehouse. São Paulo, Editora Campus, 1997 INMON, W. H. & HACKATHORN, R. D. Como usar o data warehouse. Rio de Janeiro, Editora Infobook SA. 1997 KIMBALL, R. O que faz a equipe central de data warehouse. Revista DBMS. v 1. n 3. pp. 64-66 KOCHANSKI, D. Onde devem estar as informações? Revista Developers. Nov/1998. pp. 66 KONDRATIUK, E.R. Data warehouse: detalhes que fazem a diferença. Revista Developers. Fev/ 1998. pp. 22 LACHTERMACHER, S. Momento de decisão. Revista Information Week. 02/Jun/1999. pp. 30-36 MANNI, L.C. & DORSA, L.F.A.- Data warehouse: gerenciando a qualidade dos dados. Revista Developers. Fev/1998. pp. 20 MERCHAN, M. O desenho ideal. Revista Computerworld. Suplemento especial data warehouse. 29/ Jan/1996. pp. 8-12 MIMNO, P. Mistakes to avoid in defining data warehousing architectures. http://datawarehouse. dci.com/articles/1998/07/21error.htm. 21/Jul/1998. Acesso em 04/05/2000 MONTARROYOS, L. Agilidade e eficiência na tomada de decisões na empresa. Revista Developers. Abr/1998. pp. 22-23 NIMER, F. Analisando o retorno sobre o investimento de data warehouse. Revista Developers. Fev/ 1998. pp. 16-17 ORR, K. Assuring data quality in data warehouses and data marts. http://datawarehouse.dci.com/ articles/1998/07/07assure.htm. 07/Jul/1998. Acesso em 04/05/2000 PALMA, S. Os componentes funcionais do data warehouse. Revista Developers. Fev/1998. pp. 18-19 PENTEADO, S. O coração da companhia.revista Information Week. 02/Jun/1999. pp. 20-24 PEREIRA, M.R. Data warehouse: otimizando seu desempenho. Revista Developers. Abr/1999. pp. 22-26 RADEN, N. Um impulso na tecnologia push. Revista DBMS. n 9. Fev/Mar 1998. pp. 38-42 RENNHACKKAMP, M. Diversidade de sistemas. Revista DBMS. v 1. n 3. pp. 20-29 SOBRAL, F. Data warehouse: os limites entre a fantasia e a realidade. Revista Developers. Fev/1998. pp. 66 TAURION, C.- Data warehouse: vale a pena gastar milhões investindo em um? Revista Developers. Fev/1998. pp. 10-11 TAURION, C. O Data warehouse será útil para sua organização? Revista Developers. Fev/1998. pp. 26-27 VASCONCELLOS, J.M. Implementando um data warehouse departamental. Revista Developers. Abr/1999. pp. 18-20 VECCHIA, M. A infra-estrutura na construção de um data warehouse. Revista Developers. Mar/1998. pp. 46-47 VILAROUCA, J. J. Acerte nos dados. Revista Information Week. 26/Jan/2000. pp. 44-49 WILLIAMS, J. Ferramentas para a transformação de dados. Revista DBMS. v 1. n 3. pp. 40-46 XAVIER, M.P.T. & GOMES, S.B. A informação como vantagem da empresa competitiva. Revista Developers. Fev/1999. pp. 26-29