UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UM DATA MART PARA PREVISÃO DE VENDAS ANUAL DA EMPRESA QUIMISA S/A Área de Sistemas de Informação/Banco de Dados por Elton Adriano Pering Adriana Gomes Alves, M. Eng. Orientadora Itajaí (SC), novembro de 2010

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UM DATA MART PARA PREVISAO DE VENDAS ANUAL DA EMPRESA QUIMISA S/A Área de Sistemas de Informação/Banco de Dados por Elton Adriano Pering Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Adriana Gomes Alves, M. Eng. Itajaí (SC), novembro de 2010

3 AGRADECIMENTOS Nenhum homem alcança seus objetivos sem ter de alguma maneira apoio aos seus princípios. Dessa forma agradeço especialmente aos meus colegas e profissionais da Quimisa S/A Jeferson Heil e Rafael de Oliveira, que puderam contribuir de alguma forma com seus conhecimentos na jornada desse trabalho. A minha orientadora Adriana Gomes Alves, com sua nobreza pode conduzir-me nos mais diversos momentos para o esclarecimento das minhas dúvidas e anseios. Aos mestres, que com sua paciência, antes de me ensinarem, fizeram-me aprender. Aos meus colegas de classe Nilson Burg, Gustavo Gomes da Silva, Cláudio Eduardo dentre tantos outros, pelos diversos momentos de brincadeiras, ajuda mútua e cooperação. À Família. À Deus. Muito Obrigado! ii

4 SUMÁRIO LISTA DE ABREVIATURAS... v LISTA DE FIGURAS... vi LISTA DE TABELAS... vii RESUMO... viii ABSTRACT... ix 1. INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA SISTEMAS INTEGRADOS INFORMAÇÃO, DECISÕES E ADMINISTRAÇÃO SISTEMAS DE APOIO A DECISÃO Tipos de Sistemas de Apoio à Decisão DATA WAREHOUSE Processos básicos para o desenvolvimento de um Data Warehouse DATA MART Modelo Dimensional O Star Schema OLAP Operações básicas OLAP PRIME DECISION Comparativo com outras ferramentas APRESENTAÇÃO DA EMPRESA PROJETO O PROCESSO DE PREVISÃO DE VENDAS ANUAL DIAGRAMA ENTIDADE-RELACIONAMENTO DIAGRAMA DE ATIVIDADES ESPECIFICAÇÃO DE REQUISITOS PARA O DATA-MART Requisitos Funcionais (RF) Requisitos Não Funcionais (RNF) Regras de Negócios (RN) iii

5 3.5 MODELO STAR SCHEMA INTEGRAÇÃO COM O PRIME DECISION DESENVOLVIMENTO IMPLEMENTAÇÃO DO MODELO DE INTERFACE PARA O LANÇAMENTO DA PREVISÃO DE VENDAS CONSTRUÇÃO DO MODELO DO DATA MART Implementação do modelo físico do ETL INTEGRAÇÃO DO DATA MART COM O PRIME DECISION VALIDAÇÃO DO PROTÓTIPO Resultados comparativos CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS Apêndices iv

6 LISTA DE ABREVIATURAS BDE DDL DM DML DW ERP ETL MDB OLAP SAD SI SO SPT TCC TI UNIVALI Borland Database Engine Data Definition Language Data Mart Data Manipulation Language Data Warehouse Enterprise Resource Planning Extract Transform e Load Microsoft Data Base On-Line Analytical Processing Sistemas de Apoio a Decisão Sistemas de Informação Sistema Operacional Sistemas de Processamento de Transações Trabalho de Conclusão de Curso Tecnologia da Informação Universidade do Vale do Itajaí v

7 LISTA DE FIGURAS Figura 1. Modelo atual de geração de dados para o relatório de acompanhamento previsão Figura 2. Modelo proposto Figura 3. Sistemas Integrados Figura 4. Estrutura de decisão Figura 5. Arquitetura básica de um Data Warehouse Figura 6. Integração de dados com as mesmas informações Figura 7. Data Marts departamentais Figura 8. Exemplo de um modelo Star Schema Figura 9. Operação Drill Down Figura 10. Operação Roll Up Figura 11. Drill Across Figura 12. Visualizando uma dimensão Figura 13. Operação Slice Figura 14. Visualização do cubo Figura 15. Visualização do cubo Figura 16. Visualização do cubo Figura 17. Visualização do cubo Figura 18. Diagrama entidade-relacionamento da previsão de vendas Figura 19. Diagrama de Atividades Figura 20. Modelo star schema do data mart proposto Figura 21. Consulta do cubo previsão por estabelecimento Figura 22. Consulta do cubo previsão por estabelecimento mais a dimensão mês Figura 23. Consulta do cubo previsão por estabelecimento mais a dimensão região Figura 24. Tratamento da carga para os meses Figura 25. Interface de Lançamento da previsão de vendas com gráfico histórico Figura 26. Interface de Lançamento da previsão de vendas com gráfico Distribuição Períodos Figura 27. Systeam DBA Figura 28. Explosão das Quantidades Figura 29. Prime Decision Builder Figura 30. Editor de Fórmula Figura 31. Análise 1 - Qt Previsto X Qt. Realizado por Mês Figura 32. Análise 2 - Qt Previsto X Qt. Realizado por Região Figura 33. Análise 3 - Qt Previsto X Qt. Realizado por Estado Figura 34. Análise 4 - Ranking dos Vendedores pela Variação Qt. Previsto X Qt. Realizado Figura 35. Análise 5 - Qt. Previsto X Qt. Realizado por Vendedor, Linha, Produto e Mês vi

8 LISTA DE TABELAS Tabela 1. Diferença entre Banco de Dados operacionais X Data Warehouse Tabela 2. Comparativo entre as ferramentas Tabela 3. Necessidade da gerência Tabela 4 Principais botões da interface de lançamento da previsão de vendas Tabela 5 Resultados Comparativos vii

9 RESUMO PERING, Elton Adriano. Um Data Mart para previsão de vendas anual da empresa Quimisa S/A. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, A informação no meio corporativo tem um potencial valor se apresentada de maneira correta e concisa, e através dessas informações, gestores tem a capacidade de vislumbrar vários possíveis cenários. A capacidade de tomada de decisão pode ser auxiliada por meio de sistemas de apoio a decisão (SAD), os quais oferecem análises por meio da combinação de dados, modelos analíticos sofisticados e software amigável. Dentre esses modelos analíticos tem-se os de otimização, estatísticos e previsão. No presente trabalho, foi realizado um estudo de caso do processo de previsão de vendas existente na empresa Quimisa S/A e constatou-se que este apresenta uma deficiência durante o processo de carga para a previsão de vendas até a disponibilização dos dados, que é dispendiosa, em relatórios gerenciais utilizando uma visão bidimensional. O objetivo deste trabalho é oferecer a análise de previsão de vendas por meio de uma ferramenta OLAP (processo analítico on-line) o qual confere maior dinamismo por meio da análise multidimensional. As consultas na ferramenta OLAP partiram de um data mart (DM) implementado no modelo star schema conforme as necessidades gerenciais apresentadas. Com isso, resultou-se no aumento do nível de motivação dos executivos juntamente com a maior flexibilidade das análises e menor esforço por parte dos gestores da empresa. Palavras-chave: Data Mart. Sistema de Apoio a Decisão. OLAP viii

10 ABSTRACT Information at corporate environment has a potential value if presented correctly and concisely, and through that information, managers have the ability to envision several possible scenarios. The ability of decision making can be aided by decision support systems (DSS), which provide analysis by combining data, sophisticated analytical models and friendly software. Among these analytical models there is the optimization, statistical and forecasting ones. In this study, it was performed a case study in the sales forecast process for Quimisa S/A and it has been found that it has a deficiency from the sales forecast to the availability of data, which is costly in management reports using a two-dimensional view. The objective of this study is to provide analysis of sales forecast through an OLAP (online analytical process) which gives greater dynamism through multidimensional analysis. Queries in OLAP tool will start from a data mart (DM) model implemented in the star schema model according to the managerial needs presented. Thus, resulted in the increased level of motivation among executives along with the greater flexibility of analysis and less effort from company managers. Keywords: Data Mart. Decision Support Systems. OLAP ix

11 1. INTRODUÇÃO As constantes buscas por resultados e crescimento levam as corporações a investirem em informações para auxiliar na tomada de decisões. Para isso, existem os sistemas de informações (SI) aonde os dados são coletados e processados em informação. Conforme Magalhães e Gedres (2008), Sistemas de informação é uma série de elementos ou componentes inter-relacionados que coletam (entrada), manipulam e armazenam (processo), disseminam (saída) os dados e informações e fornecem um mecanismo de feedback. 1 Dentre as vantagens dos sistemas de informação, está a capacidade de processar grandes volumes de dados simultaneamente. Entretanto, em muitos casos, a informação está espalhada em sistemas operacionais separados, ou seja, pelo ERP (Enterprise Resource Planning), que são sistemas integrados dos mais diversos setores da empresa e segundo Laudon e Laudon (2004, p. 240), modela e automatiza muitos processos de negócios, de modo que podem fluir sem descontinuidade dentro da empresa. Diretores e executivos precisam tomar decisões muitas vezes a partir de dados correntes e históricos. Em muitas empresas, dados históricos só estão disponíveis através de relatórios, cuja consulta pode levar um tempo demasiado grande, pois estes dados estão fragmentados pelo ERP. O data warehouse (DW) ataca esse problema, integrando dados operacionais-chave de toda a empresa sob forma consistente, confiável e facilmente disponível para relatórios (LAUDON;LAUDON, 2004). Para Inmon (2005, p. 29), Data warehouse é uma coleção de dados organizados por assunto, integrados, não voláteis, históricos, cujo objetivo é fornecer apoio à tomada de decisão nas organizações. Como data warehouse são grandes repositórios de dados, podemos criar armazéns menores, descentralizados, denominados data mart. Conforme Kimball (2002, p. 362), Data mart é um 1 Feedback: expressão do inglês que significa comentários (sobre o trabalho de alguém).

12 subconjunto completo de um DW, possuindo as mesmas características. Um data mart representa processos de uma determinada área de negócio e a integração de vários DM's pode formar o DW da empresa. Com o data warehouse, podemos explorar a informação através de uma ferramenta OLAP (Online Analytical Processing). O OLAP é mais do que uma aplicação é uma solução de ambiente, integração e modelagem de dados. A maioria dos dados de uma aplicação OLAP, é originária de outros sistemas e fontes de dados. Conforme Souza (2003) OLAP é um software cuja tecnologia de construção permite aos analistas de negócios, gerentes e executivos analisar e visualizar dados corporativos de forma rápida, consistente e principalmente interativa. O projeto a ser desenvolvido neste TCC será aplicado na empresa Quimisa S/A, a qual utiliza um aplicativo OLAP, o Prime Decision, aonde existem diversos cubos, como rentabilidade, Estoque, Compras, contabilidade, telefonia etc, porém apresenta algumas carências, conforme descrito a seguir. A Quimisa S/A é uma empresa do ramo químico, com um faturamento de R$ 140 milhões anuais. Atua no mercado desde Sua manufatura está direcionada aos setores: metalúrgico, higiene e limpeza, papeleira, cerâmico, alimentício e principalmente o setor têxtil, que representa quase 70% do seu faturamento. Por volta do ano 2000, boa parte da base de dados da Quimisa S/A estava em MDB (Microsoft Access). No ano de 2003 começou-se a implantar o ERP SYSTEAM da empresa Dalmark com sede em Joinville SC (DALMARK, 2010), e com isso toda a base de dados migrouse para Oracle. Todavia alguma parte do legado ficou em MDB. Na época foi criada uma ferramenta desenvolvida na linguagem Delphi e rodando sobre a base de dados MSAccess (Microsoft Access), no qual chamamos de aplicativos legados. Essa ferramenta comporta diversos módulos e dentre esses módulos tem-se o aplicativo previsão de vendas anual que possui algumas funcionalidades como: cadastro da projeção anual, calendário, transferência de clientes (de um vendedor para outro), geração de preços e ajustes de preço médio. Sua principal funcionalidade é proporcionar uma interface para que os vendedores efetuem suas previsões de vendas para o ano subseqüente, e posteriormente essas informações são disponibilizadas para acompanhamento em uma ferramenta OLAP. 11

13 Todo ano, na época de fazer a previsão de vendas, ocorre um processo de carga que toma muito tempo e que se encontra obsoleto, sendo este o um dos gargalos a serem eliminados, o qual é descrito a seguir: Como o ERP está em Oracle, precisam-se extrair os dados para o aplicativo legado previsão de vendas anual, o qual é feito através de uma importação, convertendo a base Oracle para MSAccess. Tendo os dados em MSAccess, é feito todo o tratamento (carga dos dados históricos, lançamento da previsão pelos vendedores) utilizando a ferramenta previsão de vendas anual, e terminado esse processo, é feita exportação de volta para o Oracle, convertendo a base de dados MSAccess para Oracle. Isso é necessário, pois diretores, gerentes e supervisores necessitam fazer o acompanhamento dos valores faturados com os previstos através de relatórios, para a posterior tomada de decisões. A Figura 1 representa melhor esse processo: Figura 1. Modelo atual de geração de dados para o relatório de acompanhamento previsão Observando a Figura 1, nota-se que o processo de importação e exportação (converter a base Oracle para MSAccess e vice-versa) torna-se relativamente desnecessária com a tecnologia que disponibilizada hoje, pois podemos ter toda a base de dados num único repositório, sendo que a base de dados em MSAccess, como já comentando anteriormente se encontra obsoleta e sem a estrutura de um banco de dados com seus relacionamentos corretos. 12

14 Ainda observando a Figura 1, nota-se que as consultas no relatório são feitas diretamente no banco de dados do ERP, ou seja, extrai-se a informações dos dados operacionais tornando a consulta muito demorada e engessada. As consultas nos relatórios são muito limitadas, fazendo com que os gestores percam muito tempo analisando as informações. Diretores, gerentes e supervisores são sem dúvidas, os maiores prejudicados com a ausência de informações gerenciais mais elaboradas. Além de não conseguir compreender o seu negócio, sofrem por não ter flexibilidade e agilidade durante todo o processo de tomada de decisão. Abaixo destacamos algumas deficiências encontradas: Consultas e relatórios engessados; Falta de padronização nas informações; Lentidão na geração de relatórios complexos; Diferentes tipos de relatórios, gerando valores divergentes; Impossibilidade da detecção de desvios ou ineficiências; Impossibilidade de elaboração de gráficos; e Impossibilidade de realizar filtros complexos. Conforme o Anexo I tem-se um relatório de acompanhamento do faturamento, aonde gerentes analisam o faturamento realizado com o previsto, que estão agrupados por linha de produtos. Dessa forma, este TCC se propõe a melhorar e garantir a eficiência do processo acima descrito e proporcionar aos gerentes uma nova forma de acompanhar as previsões de vendas através de uma ferramenta OLAP a qual parte da utilização de um modelo multidimensional com a utilização de um data mart. Contudo, o aplicativo Previsão de Vendas foi construído como um protótipo a fim de validar o processo do modelo proposto, pois não é possível em um TCC concluir todas as funcionalidades que a ferramenta necessita oferecer. 13

15 1.1 PROBLEMATIZAÇÃO Formulação do Problema Tendo em vista os avanços das mais novas tecnologias e novos paradigmas, a TI da Quimisa S/A busca incorporar ganhos através de seus processos de tomada de decisões. Com a implantação de um ERP em meados de 2003, a empresa começou a utilizar novas tecnologias, como banco de dados Oracle, e por consequência buscou se adaptar a essas novas tecnologias com os sistemas legados existentes. Essa adaptação tratou dos sistemas em que a empresa já utilizava antes do ano de 2003, refazendo e importando para o novo banco de dados Oracle. Um dos sistemas que precisa ser revisto é uma ferramenta que possui vários módulos, sendo um deles a previsão de vendas anual. Atualmente no processo de carga requer-se que os dados que estão no Oracle sejam importados para o MSAccess para que vendedores realizem suas previsões. Durante o processo de carga ocorrem conversões da quantidade em quilos, filtros de tipos de operações de vendas e desconsideração de devoluções e itens especiais. Após a etapa do lançamento da previsão de vendas, os dados são novamente exportados para o Oracle, aonde o sistema leva em torno 8 horas para concluir esse processo. Os dados são utilizados para consultas em relatórios gerenciais, os quais permitem aos diretores e gerentes terem o acompanhamento das vendas, verificando se estão dentro das metas previstas pelos vendedores. Porém as consultas de relatórios gerenciais são efetuadas diretamente nos dados operacionais fazendo com que a informação não seja disponibilizada de forma imediata, pois o tempo no seu processamento despende algum tempo para que seja apresentado o relatório na tela. Esses relatórios fornecidos estão restritos a uma visão bidimensional do negócio, não possibilitando aos gestores a flexibilidade que necessitam durante o processo decisório. 14

16 1.1.2 Solução Proposta Para resolver a situação apresentada no item anterior, propôs-se criar um Data-Mart, o qual deve comportar a sumarização de informações através de processos de carga, o chamado ETL (Extract Transform e Load). As informações dispostas no Data-Mart são exploradas pelo Prime Decision (Cubo), uma ferramenta OLAP desenvolvida pela TI da Quimisa S/A e que já se encontra em uso para outros fins. A Figura 2 apresenta a situação pretendida: Figura 2. Modelo proposto Observa-se na Figura 2 que o processo de importação e exportação para o lançamento de previsão de vendas será eliminado do modelo de dados MSAccess e refeito em uma base de dados relacional Oracle, facilitando e melhorando o tratamento dos dados até chegar ao data mart proposto. As outras funcionalidades e consequentemente o aplicativo legado previsão de vendas anual também terá que ser refeito e melhorado em um trabalho futuro. 15

17 Conforme a Figura 2 será eliminada as consultas do acompanhamento de previsão de vendas em relatórios gerencial. As consultas serão efetuadas pelo Prime Decicion o qual acessará as informações a partir do data mart. Assim pretende-se resolver o problema de lentidão das consultas da previsão de vendas por relatórios. Tendo em vista que a utilização do conceito Data-Mart já se encontra em operação em muitas corporações, busca-se informatizar o processo da melhor maneira possível, além do que informatizar, não é somente automatizar, é também estudar, analisar, melhorar e corrigir processos que se encontram obsoletos aonde estes geram gargalos em suas tarefas. 1.2 OBJETIVOS Objetivo Geral O objetivo geral deste projeto de pesquisa é desenvolver um Data-Mart no modelo Star Schema para apoio na tomada de decisões de previsão de vendas anual para a empresa Quimisa S/A, o qual será integrado com um sistema OLAP já existente Objetivos Específicos Os objetivos específicos deste projeto de pesquisa são: Estudar as técnicas e conceitos de Sistemas de Informação gerenciais, ERP, Data Warehouse (DW), Data-Mart, OLAP; Levantar os requisitos do modelo Data-Mart; Construir o Modelo conceitual do Data-Mart no modelo Star Schema; Implementar o Modelo físico do Data-Mart; Construir o Modelo conceitual do ETL; Implementar o ETL; Integrar o Prime Decision com o Data-Mart construído; e Documentar o Sistema desde o início do projeto. 16

18 1.3 Metodologia A execução deste trabalho foi realizada em cinco etapas principais. São elas: (i) fundamentação teórica; (ii) modelagem; (iii) desenvolvimento; (iv) validação; e (v) documentação. Na etapa de fundamentação teórica (i) foram pesquisados conceitos que envolvem sistemas de informação, ERP, Data Warehouses, Data Marts, conceitos e ferramentas OLAP's como o Prime Decision. A pesquisa se deu basicamente em bibliografias e monografias voltadas a áreas de sistemas de informação, sistemas integrados, banco de dados, implementação de Data Warehouses e também através da internet. A etapa de modelagem (ii), comprendeu a elaboração da análise e o projeto em si em três etapas. Primeiramente com a análise do data mart e seguindo com a análise do ETL e finalizando a integração com o Prime Decision. A análise incluiu o levantamento de requisitos, diagramas de caso de uso utilizando a ferramenta Enterprise Architect (EA) e o projeto do data mart (diagrama). A etapa de desenvolvimento (iii) corresponde a execução do projeto utilizando o DDL (Data Definition Language - Linguagem de Definição de Dados) e o DML (Data Manipulation Language - Linguagem de Manipulação de Dados) definidos no projeto. O DDL monta a estrutura (tabelas) do data mart no modelo star schema enquanto o DML monta o SQL do processo de ETL. Ainda na etapa de desenvolvimento, foi feita a integração do data mart com o Prime Decision, aonde é montada a estrutura para as consultas conforme as necessidades gerenciais. Com o desenvolvimento concluído, partiu-se para os testes e validações (iv), verificando se estão de acordo com os requisitos levantados garantindo a qualidade do processo. Verificou-se a estrutura do data mart e o processo ETL com testes de performance e validação dos dados extraídos. Durante toda a etapa de desenvolvimento deste trabalho, gerou-se a documentação (v), cujo foco foi a elaboração textual do TCC II. 17

19 1.4 Estrutura do trabalho Este projeto está estruturado em 5 capítulos: (1) Introdução; (2) Fundamentação Teórica; (3) Projeto, (4) Desenvolvimento e (5) Conclusões. A Introdução, Capítulo 1, destina-se a contextualizar o projeto sucintamente, descreve o problema encontrado e qual a solução proposta, expõe objetivos gerais e específicos a serem atingidos com o trabalho e a metodologia utilizada para o desenvolvimento do projeto. No Capítulo 2, (Fundamentação Teórica) são apresentados os conceitos relevantes à compreensão do processo de construção de um DM, e conceitos englobados ao seu contexto como Data Warehouse, OLAP, OLTP e Sistemas de Apoio a Decisão. O Capítulo 3 (Projeto) apresenta informações sobre o projeto detalhado a ser desenvolvido, mostrando as etapas necessárias para a conclusão do data mart e sua integração com o Prime Decision. O Capitulo 4, (Desenvolvimento) apresenta os resultados obtidos com a implementação da interface para o lançamento da previsão de vendas, construção do data mart, processos de carga, construção dos relatório no Prime Decision e validação do protótipo. Por fim, no Capítulo 5 (Conclusões) é apresentado o relato dos resultados obtidos, as ressalvas e os trabalhos futuros. 18

20 2 FUNDAMENTAÇÃO TEÓRICA A fundamentação teórica deste trabalho trata dos seguintes temas: (i) Sistemas Integrados, o qual trata de mostrar os conceitos que envolvem um sistema ERP em uma corporação e sua importância para os gerentes e executivos da empresa; (ii) Informação, Decisões e Administração, aborda os níveis de gerência que existem em uma corporação e quem os envolvem, partindo para uma abordagem sobre tomada de decisões; (iii) Sistemas de Apoio a Decisão, onde são tratados os conceitos e os dois tipos básicos de SAD; (iv) Data Warehouse, que descreve seus conceitos e suas características seguindo por uma subseção que trata do processo ETL; (v) Data Mart, trata dos conceitos e sua diferença para um Data Warehouse e segue-se por duas subseções aonde a primeira define o modelo dimensional e a segunda o modelo Star Schema; (vi) OLAP, envolve a descrição do conceito, seguindo por uma subseção que descreve as operações básicas de um sistema OLAP; (vii) Prime Decision, finaliza a seção com a apresentação desse sistema OLAP desenvolvido pelo TI da Quimisa S/A, demonstrando suas características, recursos e algumas telas de consulta do Prime Decision. 2.1 Sistemas Integrados Denominados de sistemas de planejamento de recursos empresariais (Enterprise Resource Planning - ERP), têm como característica coletar dados de vários processos de negócio importantes de uma empresa, nos mais diversos módulos como: expedição, produção, financeiro, contabilidade, vendas, marketing e recursos humanos, para em seguida serem armazenados em um único repositório central de dados. Tendo os dados em um único repositório central evita-se a redundância de dados e obtém-se uma maior confiabilidade. Outro fator que caracteriza a utilidade de um ERP é que as informações trafegam pelos módulos em tempo real, ou seja, uma ordem de vendas dispara o processo de fabricação com o envio de informação para a base de estoque, por exemplo. Os sistemas integrados possibilitam agregar valor e eficiência operacional e fornecer informações sobre a empresa como um todo, as quais ajudam os gestores a tomar melhores decisões. 19

21 Segundo Laudon e Laudon (2007, p.53), Sistemas integrados podem reunir todos os principais processos de negócios de uma empresa em um único sistema de software que permite que a informação flua sem descontinuidade através da organização. Esses sistemas focam principalmente os processos internos, mas podem incluir transações com clientes e fornecedores. Através da Figura 3 pode-se visualizar de forma clara os módulos que compõem os sistemas integrados. Nota-se que existe uma área interna e uma área externa. Na área interna estão os mais diversos módulos do sistema como: Recursos Humanos, Finanças e Contabilidade, os quais compartilham informações com os processos de negócios. Já na área externa é apresentada a chamada fronteira organizacional, aonde existem fornecedores e clientes. Figura 3. Sistemas Integrados Fonte: Laudon e Laudon (2007) Os sistemas integrados aceleram a comunicação das informações através da empresa e, assim, tornam mais fácil coordenar as operações diárias e também oferecem muitas informações valiosas para melhorar a tomada de decisão gerencial. Como os dados se encontram e um único repositório de dados centralizado, gerentes e executivos da empresa têm muito mais recursos para fazer seu planejamento, diminuir gastos e repensar a cadeia de produção. 20

22 2.2 Informação, Decisões e Administração Para O'Brien e Moreira (2004, p.281), níveis de tomada de decisão ainda existem, mas seu tamanho, forma e participantes continuam a mudar à medida que evoluem as estruturas organizacionais de hoje. Para cada nível de tomada de decisões, existe um grau de estrutura nas situações de decisão que eles enfrentam. A Figura 4 mostra essa estrutura: Figura 4. Estrutura de decisão Fonte: O'Brien e Moreira (2004) Conforme a Figura 4, tem-se três níveis de tomada de decisão: a) Administração estratégica: Envolve diretores e executivos os quais desenvolvem e monitoram metas globais, estratégicas, políticas e objetivos da organização. b) Administração tática: Envolve gerentes e supervisores que desenvolvem planos de curto e médio prazo, programações e orçamentos. Especificam as políticas, procedimentos e objetivos de negócios para as unidades filiais da organização e também distribuem recursos e monitoram o desempenho de seus departamentos organizacionais na corporação. 21

23 c) Administração operacional: Envolve os gerentes de operações que têm por finalidade desenvolver planos de curto prazo, como programa de produção semanal. Dirigem o uso dos recursos e o desempenho das tarefas de acordo com procedimentos e dentro dos orçamentos e programações que eles definem para as equipes da organização. Em qualquer desses níveis gerenciais existe a necessidade da tomada decisão, a qual envolve escolhas entre alternativas e comparações. Para Barbosa (2008) atualmente as corporações utilizam sistemas de apoio a decisão, que além de economizar tempo na decisão, dá ao administrador apenas as informações necessárias para a situação especifica. 2.3 Sistemas de apoio a decisão Segundo Laudon e Laudon (2007), sistemas de apoio a decisão (SAD), ajudam os gerentes de nível médio a tomar decisões não usuais. Em um sistema SAD, gerentes exploram a informação através da introdução de uma série de alternativas hipotéticas, as quais resultam em uma série de respostas a estas alternativas; diferentemente das respostas por demanda em sistemas de relatórios de informações (O'BRIEN; MOREIRA, 2004, p. 289). Através do sistema SAD, gerentes são auxiliados no processo de decisão através das combinações de dados, ferramentas e modelos analíticos sofisticados e software amigável. Tudo isso em um único e poderoso sistema que pode dar suporte à tomada de decisão semi-estruturada e não-estruturada. Somando ao usuário um conjunto flexível de ferramentas e capacidade para analisar dados importantes (LAUDON; LAUDON, 2004, p.358). Uma empresa pode passar por diversas perspectivas de mercado em um prazo médio de um ano, e podem surgir questionamentos como: A demanda dos produtos aumentou, devemos aumentar nosso estoque? A oferta por matéria-prima aumentou, vamos precificar nossos produtos em que patamar? Dessa forma um sistema SAD pode ajudar os gerentes a terem uma visão real da empresa no exato momento, auxiliando a tomarem suas decisões. Sistemas SAD podem utilizar (1) modelos analíticos, (2) banco de dados especializados, (3) as próprias percepções e julgamentos do tomador da decisão e (4) um processo de modelagem 22

24 computadorizado para apoiar a tomada de decisões empresariais (O'BRIEN; MOREIRA, 2004, p. 286) Tipos de Sistemas de Apoio à Decisão Laudon e Laudon (2004, p. 359) explicam que existem dois tipos básicos de sistemas de apoio à decisão: orientados por modelo e orientados por dados, conforme descrito a seguir: a) Orientados por modelos: referem-se a sistemas autônomos isolados dos principais sistemas organizacionais de informação e que usam algum tipo de modelo para executar análises se-então e outros tipos de análise. Frequentemente desenvolvidos por divisões ou grupos de usuários finais, esses sistemas não ficam sob o controle central do setor de informática. Sua capacidade de análise baseia-se em teoria ou modelo bem fundamentado, combinado com uma boa interface de usuário, que torna o modelo fácil de usar. b) Orientados por dados: diz-se a respeito de sistemas que analisam grandes repositórios de dados, encontrados em grandes sistemas organizacionais. Dão apoio à tomada de decisão pela permissão ao usuário de extrair e analisar informações úteis anteriormente ocultas em grandes bancos de dados. Frequentemente, dados provenientes de sistemas de processamento de transações (SPT) são coletados em Data Warehouses com essa finalidade. Cada Sistema de apoio a decisão é montado para um conjunto específico de finalidades e disponibilizará diferentes coletâneas de modelos dependendo dessas finalidades. Dentre os modelos mais comuns aparecem alguns como: estatísticos, otimização, previsão e sensibilidade. Esses modelos são assuntos por áreas de interesse da corporação, e que para termos isso disponível num ambiente SAD, necessitamos de um Data Warehouse. Segundo Paris (2007) as organizações criam data warehouses justamente para fornecer suporte aos tomadores de decisão, cujas informações precisas e confiáveis dos SADs, fornecem aos gerentes uma visão global da organização, permitindo uma tomada de decisão mais precisa. 23

25 2.4 Data Warehouse Data Warehouse é definido como um grande repositório de dados históricos que podem ser integrados para apoiar decisões. Um Data Warehouse contém uma coleção de ferramentas de apoio à decisão, associadas a banco de dados históricos com tamanhos significativos, permitindo que o usuário final tome decisões rápidas e seguras (TEOREY, 2007, p. 152). É também um banco de dados especializado, o qual integra e gerencia o fluxo de informações a partir dos bancos de dados operacionais corporativos. Permite a geração de dados integrados e históricos, auxiliando os diretores a decidirem embasados em fatos e não em intuições ou especulações (OLIVEIRA, 2002, p. 1). Os bancos de dados operacionais dão apoio ao processamento on-line de transações (Online Transaction Processing - OLTP), e a partir de um Data Warehouse obtemos o processamento analítico on-line (Online Analytical Processing OLAP). A Tabela 1 apresenta as diferenças entre banco de dados operacionais e Data Warehouse: Tabela 1. Diferença entre Banco de Dados operacionais X Data Warehouse Características Banco de Dados Operacionais Data Warehouse Objetivo Operações diárias do negócio Analisar o negócio Uso Operacional Informativo Tipo de OLTP OLAP processamento Unidade de trabalho Inclusão, alteração e exclusão Carga e consulta Número de usuário Milhares Centenas Tipo de usuário Operadores Comunidade gerencial Interação do usuário Somente predefinida Predefinida e ad-hoc Condições dos dados Dados operacionais Dados Analíticos Volume Megabytes - gigabytes Gigabytes terabytes Histórico 60 a 90 dias 5 a 10 anos Granularidade Detalhados Detalhados e resumidos Redundância Não ocorre Ocorre Estrutura Estática Variável Manutenção desejada Mínima Constante Acesso a registros Dezenas Milhares Atualização Contínua (tempo real) Periódica (em batch) Integridade Transação A cada atualização Fonte: Oliveira (2002, p. 9) Segundo Teorey (2007, p.153), DW devem apresentar alguns requisitos principais no qual orientam um projeto de data warehouses: 24

26 1. Organizados por áreas de interesse: engloba conjuntos por temas, envolvendo os principais processos da organização, como vendas, importação, marketing. 2. Capacidade de integração: devem ser projetados de modo que todas as diferentes representações individuais possam ser mapeadas. 3. Os dados são considerados não voláteis e devem ser carregados em massa: a decisão de quando e como atualizar é realizado pelo administrador do DW e depende das necessidades do usuário (necessidades do OLAP). 4. Níveis de granularidade: costumam ser de natureza histórica e com grande potencial de variarem com o passar do tempo. Entretanto, a granularidade pode variar de acordo com as diferentes dimensões e não apenas com o tempo; podem variar por região geográfica, tipo de produto manufaturado ou vendido etc. 5. Deve ser flexível: as definições de dados (esquemas) precisam ser suficientemente amplas para antecipar acréscimos de novos tipos de dados. 6. Ter a capacidade de reescrever a história: permitir que o administrador altere temporariamente os dados históricos com o objetivo de realizar análises hipotéticas ( o que acontece se ). 7. Interface de usuário útil para o DW: as principais escolhas hoje são a SQL, visões multidimensionais de dados relacionais, ou uma interface de usuário de uso especial. A linguagem da interface de usuário precisa ter ferramentas para recuperar, formatar e analisar dados. 8. Os dados devem estar centralizados ou distribuídos fisicamente: o DW deverá ter a capacidade de lidar com dados distribuídos em uma rede. Essa necessidade se tornará mais crítica à medida que o uso de DWs cresce e as origens dos dados expandem. 25

27 2.4.1 Processos básicos para o desenvolvimento de um Data Warehouse O principal processo, conforme Kimball (1998, p.23), para a formação de um DW é o ETL (Extract, Transform, Load) como descrito a seguir: a) Extract: primeira etapa onde são extraídos os dados de interesse. Esses dados são lidos e copiados para uma área de tratamento. b) Transform: uma vez que os dados são extraídos para área de tratamento, há muitas etapas de transformação possíveis, como: Limpeza dos dados através da correção de erros ortográficos, resolvendo conflitos de domínio (como um nome de uma cidade que é incompatível com um código postal), lidando com dados perdidos e análise para o formato padrão. Expurgar campos selecionados a partir de um banco legado que não são úteis para o Data Warehouse. Combinar fontes de dados, coincidindo exatamente em valores de chave ou através da realização de combinações fuzzy em atributos não-chaves, incluindo a observação de equivalentes textuais de códigos do sistema legado. Criação de chaves de substituição para cada registro de dimensão, a fim de evitar uma dependência sobre o legado de chaves definidas, onde o processo de geração da chave substituta impõe integridade referencial entre as tabelas dimensão e as tabelas de fato. Agregar valor para impulsionar o desempenho das consultas comum. c) Load: Ao final do processo de transformação, os dados estão na forma de carga, prontos para serem granularizados em um Data-Mart, em tabelas de dimensão e tabelas fatos. A Figura 5 demonstra a arquitetura básica do Data Warehouse, destaque para a área de preparação /transformação (ETL): 26

28 Figura 5. Arquitetura básica de um Data Warehouse Fonte: Teorey (2007) Para carregar e transformar os dados provindos do ERP é necessário que o processo de ETL seja feito de forma coerente, pois a falta de integração entre os sistemas da corporação fazem com que isso se torne um problema no momento do processo do ETL (OLIVEIRA, 2002). A Figura 6 ilustra o processo de integração de dados que tem o mesmo significado, mas que possui representações diferentes: 27

29 Figura 6. Integração de dados com as mesmas informações Fonte: Oliveira (2002) Outros problemas que surgem no momento do ETL são caracterizados pelo uso de diferentes tipos de dados para o mesmo campo, conforme descreve Oliveira (2002, p. 111): Diferenças de precisão: quando a precisão escolhida varia de um ambiente para outro (exemplo: custo do produto é armazenado com duas ou seis posições decimais); Diferenças em códigos ou expressões: quando o código utilizado difere um do outro (exemplo: sexo representado por M ou F e/ou 1 e 2); Diferenças de granularidade: quando os critérios associados a uma informação, embora utilizando uma mesmo unidade, são distintos (exemplo: horas trabalhadas correspondem às horas trabalhadas na semana ou às horas trabalhadas no mês); Diferenças de abstração: quando a forma de estruturar uma mesma informação segue critérios diferentes (exemplo: um endereço armazenado em um atributo único ou subdividido em rua e complemento.) Segundo Oliveira (2002, p.88), O Data Warehouse deve ser construído de forma interativa, seguindo uma abordagem evolucionária. Isto porque não é possível projetar da mesma forma como são construídos os sistemas baseados em requisitos, porém devem-se prever alguns requisitos iniciais. 28

30 2.5 Data Mart Conforme Oliveira (2002, p. 100), Data Marts são subconjuntos de dados da empresa armazenados fisicamente em mais de um local, geralmente divididos por departamento. A Figura 7 exemplifica esta situação: Figura 7. Data Marts departamentais Fonte: Oliveira (2002) Na arquitetura observada na Figura 7, segundo Oliveira (2002), grupos de usuários acessam diretamente os Data Marts de seus respectivos departamentos. Somente análises que necessitam de uma visão global da empresa são realizadas sobre o DW. Para Oliveira (2002), os Data Marts se diferenciam do Data Warehouse pelos seguintes fatores: São personalizados: Atendem às necessidades de um departamento específico ou grupo de usuários; Menor volume de dados: Por atenderem a um único departamento, armazenam um menor volume de dados; Histórico limitado: Os Data Marts raramente mantém o mesmo período histórico que o DW, já que, geralmente, o Data Warehouse mantém um histórico que abrange de 5 a 10 anos; e 29

31 Dados Sumarizados: Os Data Marts, geralmente, não mantém os dados no mesmo nível de granularidade do DW, ou seja, os dados são, quase sempre, sumarizados quando passam do Data Warehouse para os Data Marts Modelo Dimensional Oliveira (2002, p.60) define dimensão como diferentes perspectivas envolvidas em questões de análise dos negócios de uma empresa. Por exemplo, deseja-se saber o desempenho de vendas através de uma visão histórica sob múltiplas perspectivas como: volume de vendas por produtos, volume de vendas por marca, volume de vendas por filial, volume de vendas por período de tempo. Oliveira (2002, p.62) cita ainda dimensões como hierarquias, por exemplo, um produto, que é de uma marca ou categoria, que por sua vez pertence a uma subcategoria, etc. A forma como estas agregações são armazenadas pode ser vista em termos de dimensões e coordenadas, dando origem ao termo multidimensional (OLIVEIRA, 2002). Dados multidimensionais podem ser armazenados e representados em estruturas relacionais, para isso é necessário utilizar formas específicas de modelagem como o modelo Estrela - Star Schema - e o modelo Floco de Neve - Snow Flake (OLIVEIRA, 2002). O modelo a ser estudado e implementado nesse projeto, será o modelo Star Schema, o qual fornece um acesso rápido aos dados. Este não necessita de normalização para garantir unicidade de valores textuais (OLIVEIRA, 2002, p. 95) O Star Schema Segundo Teorey (2007, p. 158), o Star Schema (modelo estrela) é uma organização que consiste em uma grande tabela de fatos central e muitas tabelas de dimensão menores. Para Oliveira (2002, p.61), o modelo Star Schema tem a vantagem de ser simples e intuitivo, mas também faz uso de novos enfoques de indexação e união de tabelas. 30

32 A Figura 8 mostra essa representação: Figura 8. Exemplo de um modelo Star Schema Fonte: Adaptado de Teorey (2007) Conforme Oliveira (2002, p. 61), a Tabela de fatos contém milhares ou milhões de valores e medidas do negócio da empresa, como transações de vendas ou compras. Cada uma destas medidas é tomada segundo a interseção de todas as dimensões. Segundo Teorey (2007, p. 158), a tabela de fatos também contém medidas, que contêm valores a serem agregados quando as consultas agrupam linhas. Como exemplo de medidas, tem-se na Figura 8 Preço de Custo e Preço de Venda. Já as Tabelas de dimensão, segundo Oliveira (2002), armazenam as descrições textuais das dimensões do negócio. Cada uma dessas descrições textuais ajuda a definir um componente da respectiva dimensão. Uma das principais funções dos atributos de Tabelas de dimensão é servir como fonte para restrições em uma consulta ou como cabeçalhos de linha no conjunto de resposta do usuário. Tabelas dimensões tendem a utilizar tipos caracteres ao invés de numéricos, de forma que suas linhas são muito mais longas, mas em pouca quantidade ocupando uma pequena percentagem de espaço em disco. As Tabelas de fatos podem utilizar até 95 % da área destinada ao Data Warehouse. 31

33 Vantagens do modelo Star Schema O modelo Star Schema possui várias vantagens a respeito de sua utilização em um data mart, dentre estas conforme Oliveira (2002, p.64), possui: Arquitetura padrão e previsível. As ferramentas de consulta e interfaces do usuário podem se valer disso para fazer suas interfaces mais amigáveis e um processamento mais eficiente; As dimensões do modelo equivalentes, ou seja, podem ser vistas como pontos de entrada simétricos para a Tabela de fatos. Flexibilidade para suportar a inclusão de novos elementos de dados, bem como mudanças que ocorram no projeto. 2.6 OLAP Na visão de Teorey (2007) OLAP (On-line Analytical Processing) - Processamento Analítico On-Line - é um serviço que sobrepõe o data warehouse aonde se explora ocasionalmente informações resumo com base em grandes quantidades de dados. Para Oliveira (2002) OLAP refere-se a um conjunto de tecnologias voltadas para acesso e análise ad-hoc 2 de dados, no qual são capazes de transformar dados em informações de modo que ofereçam suporte a decisões gerenciais de forma amigável e flexível ao usuário e em tempo hábil. Segundo Thomsen (2002, p.29): Os principais requisitos centrais para OLAP são estrutura dimensional rica com referências hierárquicas, especificação eficiente de dimensões e cálculos, flexibilidade, separação de estrutura e representação, velocidade suficiente para oferecer suporte à análise ocasional e suporte para multiusuários. Conforme Machado (2004) através das dimensões pode-se descobrir tendências e cenários, e com isso transformar os dados de um Data Warehouse em informação estratégica. 2 Ad-hoc é uma expressão latina cuja tradução literal é "para isto" ou "para esta finalidade". 32

34 2.6.1 Operações básicas OLAP Para Machado (2008, p.86), a funcionalidade de uma ferramenta OLAP é caracterizada pela análise multi-dimensional dinâmica dos dados. Para realizar essas análises multi-dimensionais, utilizam-se operações como: Drill Down 3, Roll Up 4, Drill Across 5 e Slice and Dice 6. Drill Down e Roll Up Segundo Machado (2008), Drill Down e Roll Up são operações para movimentar a visão dos dados ao longo dos níveis hierárquicos de uma dimensão. Operações de drill down caracterizam-se quando o usuário aumenta o nível de detalhe da informação, diminuindo o nível de granularidade, ou seja, pode navegar do mais alto nível até o dado detalhado. Na Figura 9 há um exemplo de operação de drill down que acontece sobre a dimensão localização geográfica. Na primeira tabela tem-se a produção de produtos por região geográfica e pelos estados da região. Ao realizar um drill down, estamos ampliando o nível de detalhe da dimensão localização geográfica, visualizando somente um estado da região anterior, e abrindo os valores para as cidades desse estado. 3 Expressão do inglês que significa perfurar abaixo. 4 Expressão do inglês que significa voltar pra cima, ou chegar. 5 Expressão do inglês que significa perfurar ao lado. 6 Expressão do inglês que significa fatiar e cortar em cubos. 33

35 Figura 9. Operação Drill Down Fonte: Machado (2008) Operação de roll up é o contrário. Caracterizam-se quando o usuário aumenta o nível de granularidade, diminuindo o nível de detalhamento da informação, ou seja, pode navegar do nível de detalhe até o mais alto nível de sumarização de dados. Na Figura 10 há uma operação roll up que acontece sobre a dimensão tempo. Na primeira tabela têm-se os valores de produção globais independente de produto na região sul nos estados do Rio Grande do Sul e Santa Catarina distribuídos por trimestre de Ao realizar um roll up, estamos saindo de um nível mais baixo de detalhe (um trimestre específico de um ano) para um nível mais alto (todos os trimestres de um ano). 34

36 Figura 10. Operação Roll Up Fonte: Machado (2008) Drill Across Conforme Machado (2008, p.89), essa operação acontece quando o usuário pula de um nível intermediário dentro de uma mesma dimensão. Por exemplo: a dimensão tempo é composta por ano, semestre, trimestre, mês e dia. Como pode ser visto na Figura 11 o usuário executa um drill across, e passa da dimensão ano para a dimensão mês. 35

37 Figura 11. Drill Across Fonte: Machado (2008) Slice and Dice Slice and dice, significa reduzir o escopo dos dados em análise, além de mudar a ordem das dimensões no qual os dados são visualizados. Slice and dice é o mesmo que filtrar (MACHADO, 2008, p.90). Na Figura 12 existe a dimensão localização geográfica demonstrando dois produtos: celulares e pagers por região geográfica e pelos estados dessa região: Figura 12. Visualizando uma dimensão Fonte: Machado (2008) 36

38 Ao fatiar ou realizar slice, visualizamos somente a produção de um tipo de produto, por exemplo, celulares. A Figura 13 ilustra o slice realizado: Figura 13. Operação Slice Fonte: Machado (2008) 2.7 Prime Decision O Prime Decision é um software com a tecnologia OLAP desenvolvido e utilizado para tomada de decisões na Quimisa S/A. Dentre suas principais características se destacam: Linguagem utilizada para o seu desenvolvimento: Borland Delphi 5.0 for Win32. Requisitos mínimos de SO (Sistema Operacional): Processador Intel Dual Core 1.6 c/ 1 GB RAM e 100 MB de HD. Tecnologia utilizada: Desktop OLAP, onde o processamento é feito na estação de trabalho do próprio usuário. Recursos Oferecidos: Criação de fórmulas e de algoritmos (ranking, máximo, mínimo, média, etc.) além de possibilitar a criação de gráficos e diversos indicadores. Ainda podem-se citar pontos fortes como: O sistema não utiliza servidor OLAP (o que é caro, moroso e custoso); possui interface intuitiva e limpa; permite exportações para o Word, Excel e HTML; e possibilita a criação e recuperação de cenários. Dentre seus pontos fracos tem-se: Sistema não dispõe de ajuda on-line; não permite entrada de dados para realização de simulações e projeções; e não possui dashboard (cookpit). 37

39 Atualmente a empresa possui os cubos de rentabilidade, transportes, qualidade, compras e contabilidade. O Prime Decision aborda as necessidades atuais dos executivos, fornecendo benefícios imediatos. Além disso, é totalmente flexível propiciando assim, maiores benefícios em relação à tomada de decisão. Através dessa tecnologia tem-se uma maior flexibilidade das informações analisadas através dos cubos multidimensionais. Além disso, é possível gerar visões informativas personalizadas, relevantes que entreguem recursos de consulta, relatório e análise que vão além dos recursos de relatório padrão de sistemas baseado em transações, ou seja, eleva-se potencialmente a compreensão do negócio para a tomada de boas decisões de maneira rápida. Podemos ainda citar outras características: Flexibilidade das análises: certamente o ponto forte da ferramenta, é a infinita possibilidade de combinações de dados para estudo; Possibilidade de trabalho em modo On-Line (conexão com o servidor) ou Off-Line (sem conexão alguma); Segurança total nas informações com possibilidade de liberar apenas o que for conveniente para cada usuário; Comunicação: possibilidade de envio de determinada análise (Lay-Out) já elaborada por ; Filtros: onde se seleciona apenas o universo que se deseja considerar na análise; Condensamento e expansão (drill-down/up): visando a facilidade de visualização, as linhas podem ser condensadas e expandidas, mantendo-se a seleção previamente determinada a fim de chegar ao grão da informação (maior detalhe possível); Elaboração de gráficos: facilidade em gerar gráficos a partir das informações já tratadas na tela, com dinamismo para personalizações dos tipos de gráficos; Arquivamento das informações: após montar o tipo de análise desejada, o usuário salva tudo o que foi feito (Lay-Out), incluindo seleções, filtros, gráficos, 38

40 possibilitando o acompanhamento daquela análise, dinamicamente, isto é, com informações atualizadas no decorrer do tempo; e Impressão: todas as informações da tela podem ser impressas, sem a necessidade de ajustes de margens ou fontes, sempre por meio da visualização de impressão anteriormente. Com a utilização constante do Prime Decision, tem-se resultados ainda maiores para a empresa, como: Melhoria na tomada de decisões, propiciando análises precisas e rápidas, com menor esforço e maior flexibilidade; Utilização e reutilização das informações em cenários diferentes; Extinção do acúmulo de diferentes tipos de relatórios departamentais, gerando sérios problemas de manutenção; Descoberta de tendências e fatos relevantes; e Aumento do nível de motivação dos executivos; Assim, a partir dos cubos gerados e do sistema, os gestores e diretores podem gerar e gerir informações úteis para a tomada de decisões, obtendo vantagem competitiva perante os seus concorrentes. A seguir é apresentado o poder de visualização das informações da ferramenta através de quatro exemplos. Algumas informações foram propositalmente desfocadas, por tratar-se de dados confidenciais da Quimisa S/A. Os valores são fictícios e servem apenas para demonstrar a visualização do cubo. a) Faturamento do grupo Quimisa por Cliente até outubro de 2005, agrupado por estabelecimento e cliente (Figura 14); 39

41 Figura 14. Visualização do cubo 1 Fonte: software da Quimisa b) Comparativo da quantidade faturada do estabelecimento Brusque por Cliente até outubro de 2005(Figura 15); 40

42 Figura 15. Visualização do cubo 2 Fonte: software da Quimisa c) Comparativo da quantidade faturada do grupo Quimisa até julho de 2005 por estabelecimento, mais o gráfico oriundo da planilha (Figura 16); 41

43 Figura 16. Visualização do cubo 3 Fonte: software da Quimisa d) Ranking da quantidade faturada do grupo Quimisa até julho de 2005 por produto (Figura 17). 42

44 Figura 17. Visualização do cubo 4 Fonte: software da Quimisa Comparativo com outras ferramentas As comparações (como demonstra a Tabela 2), foram realizadas em um computador com processador Pentium Dual Core 2.66 com 2,00 GB de memória RAM, aonde foi baixado a versão Trial que o concorrente disponibiliza em seu site. Como fonte de extração de dados, foi utilizado o BDE (Borland Database Engine) versão 5.02, acessando informações transacionais do ERP da empresa que utiliza Oracle 10g como banco de dados. Os testes foram realizando em um dia normal de trabalho, com várias transações ocorrendo simultaneamente. 43

45 Tabela 2. Comparativo entre as ferramentas Características Prime Decision Tableau Pentaho BI Suite Fornecedor: Quimisa S/A TI Tableau Software Pentaho URL: re.com Versão: Preço por site ou por usuário: - Site Site Necessita servidor OLAP: Não Não Não Necessita de Data Warehouse: Sim Não Não Extrai dados de diversas fontes: Sim (BDE, OLE DB, XML, Excel, CSV, Sim (ADO, BDE e OLE DB) Sim (ADO, BDE e OLE DB) entre outros) Tempo para gerar o cubo de 4 min. 13 min. 15 min. rentabilidade: Tamanho do cubo gerado: 8 Mb 15 Mb 18 Mb Taxa de compactação do cubo 99% 57% 53% gerado: Tempo para abrir o cubo gerado 3 seg. 12 seg. 16 seg. localmente: Tempo para abrir o cubo gerado, remotamente (via FTP - ADSL de 300 Kb) 4 min. Não conseguiu abrir. 20 min. Reposta para fatiar dados: Rápida Razoável Lenta Tempo para filtrar valores de Rápida Razoável Razoável dimensões: Permite criação de algoritmos de Sim Não Não agregação dinamicamente: Permite criação de fórmulas Sim Sim Não dinamicamente: Permite a utilização de funções: Sim Não Não Permite mais de uma visão dentro Sim Não Não do próprio cubo: Permite a criação de gráficos Sim Sim Sim dentro do próprio cubo: Permite alterar os dados do cubo: Não Não Não Permite exportar para Word, Excel Sim Sim Sim e HTML Permite suporte multiusuário Sim Sim Sim Permite a impressão da Sim Sim Sim visualização do cubo: Interface amigável: Sim Sim Sim Idioma da Ferramenta: Português Português Português Tecnologia utilizada: ActiveX/Win32/.NET Java Win32 Número limite de fatos: 64 Não informado Não informado Número limite de dimensões: 127 Não informado Não informado Resultado Final: Com o comparativo, podemos concluir que o Prime Decision da Quimisa S/A é a que mais rapidamente conseguiu gerar o cubo. Além disso, foi o que mais conseguiu compactá-lo. É um visualizador completo, com gráficos, possibilidade de criar várias visualizações (fatias), salvá-las e se preciso for, enviá-las via para qualquer usuário que tenha o Prime Decision instalado em seu computador. As fatias são instantaneamente executadas, filtros também são aplicados com uma velocidade excelente. 44

46 Sendo assim, a ferramenta Prime Decision foi a escolhida para auxiliar na análise estratégica de rentabilidade, entre outros cubos da Quimisa S/A. 2.8 APRESENTAÇÃO DA EMPRESA A QUIMISA S/A é uma empresa do ramo químico, com um faturamento de R$ 140 milhões anuais. Atua no mercado desde Sua manufatura está direcionada aos setores: metalúrgico, higiene e limpeza, papeleira, cerâmico, alimentício e principalmente o setor têxtil, que representa quase 70% do seu faturamento (QUIMISA, 2010). A empresa possui frota própria, compostas por 29 caminhões, sendo que 12 são tanques com capacidade de 215 ton. e 17 são carga seca com capacidade de 210 ton. Com 233 colaboradores (sendo que 81 % são funcionários e 19 % são terceirizados), administra duas filiais, uma em Sapucaia do Sul (RS) e outra em Jandira (SP) e também um escritório de vendas em Curitiba (PR). Atua diretamente no mercado com 17 vendedores (5 internos e 12 externos) controlando os mais diversos clientes. A empresa também conta com 6 engenheiros químicos e 6 técnicos têxteis. A matriz possui m² com m² de área construída, a filial de Sapucaia do Sul m² com 4.000m² de área construída e a filial Jandira m² com m² de área construída, sendo que capacidade em tanques ultrapassa m³. Possui 3 laboratórios, o Laboratório de Aplicação (que controla a parte de pigmentação, corantes e realiza testes de novos produtos), Desenvolvimento de novos produtos (realiza experiências, cria, altera e aperfeiçoa produtos) e Controle da Qualidade (realiza as análises em amostras de produtos). Seu parque industrial está dividido em 4 galpões. O G-1 para depósito, G-2 para produção e laboratórios, G-3 para almoxarifado de matéria prima e o G-4 para outros depósitos. A Quimisa devida sua ótima localização, atende a todo eixo têxtil (Brusque a Jaraguá/Joinville) em menos de 24 horas. 45

47 Dessa forma, a Quimisa é líder de mercado na região, pois além de oferecer produtos com qualidade a preços competitivos, fortalece os laços com seus clientes através da agilidade. Prova disso são os reconhecimentos formais de clientes como Cremer, Karsten e Coteminas. 46

48 3 PROJETO As seções seguintes destinam-se à especificação do Data-Mart desenvolvido, a fim de possibilitar uma visão proposta pelo modelo, contemplando uma explanação do processo de previsão de vendas da Quimisa S/A, além da análise de requisitos e regras de negócios e a elaboração do diagrama de dados do Data-Mart no modelo Star Schema. 3.1 O processo de previsão de vendas anual Todo final de ano a Quimisa S/A precisa fazer seu planejamento para o ano subsequente, e um desses planejamentos é ter sua previsão de vendas anual elaborada de forma que diretores e gerentes possam ter uma visão das metas a serem alcançadas, e sua posterior tomada de decisão. A previsão de vendas é feita pelos vendedores entre outubro e novembro de cada ano, baseando-se em dados históricos dos dois últimos anos, ano corrente e na experiência dos profissionais. O tempo de trabalho dos vendedores na Quimisa é acima de 5 anos e focado em seus clientes, dando ao processo de previsão uma boa confiabilidade. Sabe-se que alguns fatores podem comprometer a concretização da previsão, tais como declínios econômicos, mudança de funcionários, alterações na moda e tendências, maior competição, recall de fabricantes, entre outros fatores (ROOS, 2009). Dessa forma, faz-se necessário no mundo corporativo estabelecer metas que sirvam de referência para atingir determinado fim dentro de um período de tempo, os quais são o princípio para o crescimento e desenvolvimento de uma corporação. A previsão de vendas é feita por todos os vendedores da Quimisa S/A, sejam internos ou externos, em uma interface que apresenta os produtos vendidos por este vendedor, e os clientes de cada produto. Inicialmente o vendedor lança suas previsões com base nas quantidades históricas vendidas nos dois últimos anos. Tem-se para cada produto todos os clientes em que ele efetuou a venda, sendo possível lançar por percentual, quantidade direta do produto ou quantidade direta do cliente do vendedor X. A previsão de vendas também é feita pelo superintendente da empresa o qual, baseado em informações privilegiadas do mercado, sugere os preços das commodities 7 para o próximo ano. Além 7 Termo originário da língua Inglesa que significa produtos primários que possuem pouca ou nenhuma industrialização. 47

49 disso, o gerente de vendas revisa os preços dos produtos próprios (aqueles que a empresa fabrica) e informa os possíveis aumentos para o próximo ano. Esses são ajustes finos que devem ser feitos antes da carga final da previsão de vendas para o data mart. Essas informações que cada vendedor tem em particular para efetuar sua previsão, são geradas por meio de um processo de carga extraídos do ERP, aonde as quantidades e valores são sumarizados. Logo, as previsões são acompanhadas diariamente pelos gestores, os quais verificam se as metas levantadas estão sendo atingidas. Para tanto, é necessário que o processo que disponibiliza essas informações seja confiável, eficiente e ágil, a fim de fazer suprir as necessidades dos gestores da empresa. Como já exposto neste trabalho, o processo atual de previsão de vendas utiliza recursos computacionais que estão limitados em processos de extração e carga de dados até a disponibilização dessas informações por meio de relatórios gerencias em que se apresentam engessados, ao quais gestores estudam para realizar a tomada de decisão. Portanto, nos próximos itens deste capítulo é apresentado o projeto e protótipo de uma solução de software utilizando modernos recursos e conceitos de extração de dados, data-mart e OLAP. 48

50 3.2 Diagrama entidade-relacionamento Para realizar a previsão de vendas, são extraídos dados do ERP de maneira que os vendedores possam lançar suas previsões. O diagrama entidade-relacionamento da previsão de vendas é apresentado na Figura 18: Figura 18. Diagrama entidade-relacionamento da previsão de vendas 49