RELATÓRIO FINAL DE ESTÁGIO SUPERVISIONADO

Transcrição

1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DA PARAÍBA CAMPUS CAMPINA GRANDE COORDENAÇÃO DO CURSO SUPERIOR DE TECNOLOGIA EM TELEMÁTICA RELATÓRIO FINAL DE ESTÁGIO SUPERVISIONADO Fernando Felix do Nascimento Junior Campina Grande Dezembro de 2011

2 Instituto Federal de Educação, Ciência e Tecnologia da Paraíba Fernando Felix do Nascimento Junior Atacadão de Estivas e Cereais Rio Do Peixe Relatório Final de Estágio Supervisionado apresentado pelo aluno Fernando Felix do Nascimento Junior à Supervisão de Estágio do curso de Tecnologia em Telemática do Instituto Federal da Paraíba - Campina Grande. Ianna Maria Sodré Ferreira de Sousa Orientadora da Instituição João Paulo F. de Oliveira Supervisor na Organização Alex Sandro da Cunha Rego Coordenador de Estágios Campina Grande Paraíba - Brasil Dezembro de 2011

3 Aprovado em / /... Fernando Felix do Nascimento Junior Aluno... Ianna Maria Sodré Ferreira de Sousa Orientadora da Instituição... João Paulo F. de Oliveira Supervisor na Organização... Alex Sandro da Cunha Rego Coordenador de Estágios

4 Lista de Figuras Figura 1: Sistema de business intelligence, adaptado de Fortulan & Filho (2005)... 7 Figura 2: Modelagem dimensional de banco de dados utilizando o modelo estrela (autor)...9 Figura 3: Pilha de componentes Pentaho (BOUGMAN; DONGEN, 2009)...15 Figura 4: Ferramentas e componentes do Pentaho Data Integration (BOUGMAN & DONGEN, 2009) Figura 5: Steps, hops, e fluxo de registros (BOUGMAN & DONGEN, 2009)...19 Figura 6: Exemplo de calculo da tendência...23 Figura 7: Espiral do conhecimento e modelo espiral de desenvolvimento de software (MATHEUS & PARREIRAS 2004) Figura 8: Data Mart Bus, adaptado de Watson & Ariyachandra (2005) Figura 9: Data marts para apoiar o processo de gestão de estoques (autor) Figura 10: Transformação que povoa a tabela Tempo Figura 11: Transformação que povoa a tabela Fornecedor Figura 12: Transformação que povoa a tabela Cliente...39 Figura 13: Transformação que povoa a tabela Vendedor...39 Figura 14: Transformação que povoa a tabela Supervisor...40 Figura 15: Transformação que povoa a tabela Produto...40 Figura 16: Transformação que povoa a tabela Posicao Figura 17: Transformação que povoa a tabela Filial...41 Figura 18: Transformação que povoa a tabela Pedidos...42 Figura 19: Transformação que povoa a tabela Estoque...42 Figura 20: Transformação que povoa tabela Perdas Figura 21: Gráfico de barra vertical de todos os meses de Figura 22: Gráfico de pizza dos produtos, TOP Figura 23: Relatório de produtos vendidos, utilizando MDX + PRD...48 Figura 24: Trabalho para a povoação das tabelas dimensões Figura 25: Trabalho para povoação das tabelas fatos Figura 26: Trabalho para automatizar a geração e envio de relatórios... 49

5 Sumário 1 Introdução Motivação e Problema Objetivos Objetivo Geral Objetivos Específicos A Empresa... 3 Departamento de Tecnologia da Informação (TI) Descrição Geral das Atividades Fundamentação Teórica Business Intelligence Data Warehouse (DW) Extract, Transform and Load (ETL) On Line Analytical Processing (OLAP) Data Mining Pentaho Plataforma de Business Intelligence Integração de Dados e Aplicações Ferramentas e Utilidades Motor Repositório...18 Transformations e Jobs Transformações Trabalhos Pentaho Analysis (Mondrian) Pentaho Reporting Pentaho Data Mining (Weka) Métodos Quantitativos Giro de estoque Cobertura de Estoques...21

6 2.3.3 Custo de Estoque...22 Custo de Aquisição...22 Custo de Armazenagem...22 Custo de Falta Previsão da demanda Solução Business Intelligence Criação do Data Warehouse Criação de processos ETL com o Kettle Criação dos cubos OLAP Criação das consultas MDX Criação das apresentações Difusão das informações Especificação Técnica Servidor Ferramentas Pentaho Outros Sistema de arquivos Conclusão Sobre o estágio...34 Referências Anexo 1: Processos ETL...37 bi_time_dimension...37 bi_fornecedor bi_cliente...39 bi_usuario bi_supervisao bi_produto...40 bi_posicao... 41

7 bi_filial...41 bi_pedi_fact...42 bi_estoque bi_falta Anexo 2: Exemplos de análises OLAP...44 Perdas por falta de produtos em 2011, todos os meses...44 Perdas por falta de produtos em 2011, TOP Anexo 3: Exemplo de Relatório Criado...47 Anexo 4: Jobs...49 Anexo 5: Organização das Ferramentas Anexo 6: Cronograma...51

8 1 1 Introdução 1.1 Motivação e Problema O surgimento dos estoques nas organizações decorrem da necessidade de garantir o atendimento de um processo de demanda a partir de um processo de fornecimento, uma vez que tais processos não podem ser equilibrados de forma que sejam idênticos em cada instante (TRAJANO, 2008, apud BERTAGLIA, 2003). A gestão de estoques, portanto, consiste em agir, principalmente, sobre o processo de fornecimento, sendo que esta ação se baseia em decisões de o que fornecer, em que quantidade, em que momento e quando repor. No início do século passado, muito desenvolvimento acadêmico foi feito na aplicação de métodos quantitativos para tais decisões. No entanto, tem sido raro encontrar empresas brasileiras utilizando métodos quantitativos para apoiar à gestão de estoques; ao contrário, é comum o uso de métodos empíricos, qualitativos e baseados em intuição (GIANESI & BIAZZI, 2011). Um dos mais importantes princípios da gestão de estoques é como tratar itens diferentes de formas diferentes. Ao invés de determinar parâmetros de gestão individualizados para cada item, utilizando técnicas quantitativas eficazes, muitas empresas tendem a utilizar regras uniformes para tratar todos os itens da mesma forma. Um exemplo comum desse tipo de politica é manter estoque de segurança de um mês de demanda para todos os itens sem considerar as incertezas de demanda e fornecimento que são específicas de cada item (GIANESI & BIAZZI, 2011), tendo assim, por exemplo, mais probabilidades no aumento de valores imobilizados em estoque. Para a gestão de estoques, os sistemas de gestão empresarial (ou Enterprise Resource Plaining - ERP) oferecem uma boa vantagem em nível operacional/transacional, permitindo o tratamento adequado e individualizado a cada item nos estoques. No entanto, esses sistemas coletam e armazenam enormes quantidades de dados em seus bancos de dados ao longo do tempo, dificultando um planejamento, controle e gestão mais eficiente das informações armazenadas, e impedindo, consequentemente, que métodos quantitativos possam ser

9 aplicados facilmente. Para sanar esses tipos de necessidades, surgiram os sistemas de business intelligence (BI). 2 Quando implementado corretamente, o BI pode proporcionar informações confiáveis, no momento certo e para o gestor certo em uma organização. Uma definição detalhada de BI pode ser: Área de estudo interdisciplinar, ligada à tecnologia da informação, que tem como objeto de estudo a elaboração de sistemas de informação computacionais responsáveis por organizar grandes volumes de dados (data warehouse), analisar (online analytical processing) e facilitar a descoberta de relações entre tais dados (data mining) e oferecer interfaces (apresentações) que facilitem ao usuário o entendimento das relações entre os dados, a fim, por exemplo, de prover melhores informações para a tomada de decisão (MATHEUS & PARREIRAS, 2004; GOUVEIA, 2009; CAPUANO et. al, 2009; BISPO, 1998). Exemplo de um sistema de BI é o Pentaho Community 1 (ou apenas Pentaho), uma das ferramentas software livre de BI que mais se destaca. Ele reúne uma coleção de programas computacionais que trabalham juntos para criar e entregar soluções BI completas (BOUGMAN & DONGEN, 2009). As apresentações geradas pelas soluções Pentaho podem ser visualizadas de várias formas, inclusive por um simples navegador Web, o que significa que podem ser embutidas em alguma aplicação Web. 1.2 Objetivos Objetivo Geral O objetivo geral do estágio foi desenvolver uma solução BI feita com o Pentaho, para favorecer o processo de decisões estratégicas relacionadas a gestão de estoques no Atacadão de Estivas e Cereais Rio Do Peixe, utilizando o método quantitativo dos mínimos quadrados para prever a demanda dos produtos em estoque. 1 Pentaho Community <

10 Objetivos Específicos Estudo do BI e conceitos relacionados; Estudo da suíte Pentaho: arquitetura e principais componentes; Estudo de alguns métodos quantitativos para gestão de estoques, principalmente sobre a previsão de demanda; Instalação e configuração dos componentes Pentaho e ferramentas auxiliares em uma distribuição Linux (Ubuntu) A Empresa O Atacadão de Estivas e Cereais Rio Do Peixe é uma rede brasileira de supermercados atacado varejista pertencente ao Grupo Rio do Peixe (GRP), que iniciou suas atividades em O GRP instituiu várias empresas em diversos ramos de atuação realizando um plano de ação que tem como bases principais aumentar o foco em linhas de produtos mais eficientes, consolidar parcerias, reduzir o portfólio, privilegiar marcas de maior valor agregado, instituir sistema de acompanhamento e incentivos e montar um trabalho voltado para o merchandising. Com a modalidade de Atacado para atender a supermercados, mercearias e pequenos consumidores, a bandeira Atacadão Rio do Peixe tem se destacado no cenário nacional contribuindo para o desenvolvimento do Nordeste do país através de políticas econômicas de desenvolvimento. A estratégia atualmente desenvolvida pelo Atacadão Rio do Peixe para manter e ampliar sua carteira de clientes e a abrangência de seus negócios está centrada na fuga do posicionamento de low price praticado por setores do mercado atacadista, buscando trabalhar com competência para atender com o máximo de eficiência seus clientes, maximizar os resultados para seus fornecedores, crescer e desenvolver seus próprios negócios. Departamento de Tecnologia da Informação (TI) O estágio foi realizado no departamento de TI, um dos departamentos mais importantes e sobrecarregados da empresa, contando atualmente com 7 funcionários e 5

11 estagiários (incluindo o autor). Suas responsabilidades são muitas, podendo ser divididas em pelo menos 5 setores: 4 Setor de banco de dados: setor de suporte ao ERP da empresa (Winthor) e os bancos de dados utilizados por esse ERP, na qual utilizam o sistema de gerenciamento de bancos denominado Oracle; Setor de segurança da informação: responsável pelo cumprimento das normas estabelecidas pela política de segurança vigente, sistemas de antivírus e mecanismos de proteção à rede; Setor de suporte: presta serviços, conserta equipamentos, etc. Setor de infraestrutura de redes: responsável pelos principais serviços da rede como SMTP, HTTP, SSH, proxy e backup dos dados. Todos os servidores e serviços são configurados e monitorados pela equipe desse setor. Setor de monitoramento: responsável pelo monitoramento do tráfego da rede através do aplicativo Nagius Descrição Geral das Atividades As atividades desenvolvidas no estágio foram divididas em quatro fases: 1. Estudo do conceito do BI e conceitos relacionados Estudo sobre data warehouse e suas arquiteturas; Estudo sobre o processo de extração, transformação e carga (do inglês extract, transform and load - ETL); Estudo sobre on-line analytical processing (OLAP); Estudo sobre a linguagem para consultas em cubos OLAP, o multidimensional expressions (MDX). 2. Estudo da suíte Pentaho: Arquitetura e principais componentes Estudo sobre o servidor do Pentaho, responsável por integrar todos os outros componentes e disponibilizar diversos serviços através de uma interface Web; Estudo sobre a ferramenta de integração de aplicações e dados, o Pentaho Data Integration (PDI, ou Kettle);

12 5 Estudo sobre a ferramenta Mondrian, responsável tanto por criar cubos OLAP, pelo mapeamento de tabelas de um banco de dados relacional, como para disponibilizar tais cubos, para serem consultados (analisados) através da linguagem MDX; Estudo sobre a ferramenta de criação de relatórios e gráficos Pentaho Report Designer (PRD). 3. Instalação e configuração dos componentes Pentaho e ferramentas auxiliares em uma distribuição Linux (Ubuntu) Instalação e configuração do servidor do Pentaho; Instalação e configuração do PDI; Instalação e configuração do Mondrian Schema Workbench, a ferramenta para criação de cubos do Mondrian; Instalação e configuração do PRD; Instalação e configuração do SQL Developer, ferramenta que permite o gerenciamento de tabelas e consultas SQL em um banco de dados Oracle; Instalação e configuração do SQL Power Architect, na qual permite a criação de tabelas visualmente através de modelos modelos dimensionais. 4. Desenvolvimento da solução BI Criação do modelo lógico/físico de um DW utilizando a arquitetura data mart bus, com a ferramenta Power Architect; Criação de processos ETLs com o PDI para povoar as tabelas do DW; Criação de cubos OLAP utilizando o Mondrian Schema Workbench; Criação de consultas analíticas dimensionais utilizando o MDX sobre o Mondrian, na qual, é integrado pelo servidor do Pentaho; Criação de relatórios dinâmicos (apresentações) com base nas consultas MDX, utilizando o PRD; Criação de processos automatizados de difusão das apresentações com o PDI.

13 6 2 Fundamentação Teórica 2.1 Business Intelligence O uso da inteligência militar, econômica, comercial, religiosa ou política tem existido na China por mais de cinco mil anos. Textos religiosos de anos descrevem situações em que a inteligência é utilizada em processos de tomada de decisão. Também no âmbito militar, estrategistas como Circa e Sun Tzu, há mais de anos já enfatizavam a importância da inteligência e o valor da informação (CAPUANO at al., 2009, p. 28). Sun Tzu, em seu livro A arte da guerra, prescreveu que: Aquele que conhece o inimigo e a si mesmo, lutará cem batalhas sem perigo de derrota; para aquele que não conhece o inimigo, mas conhece a si mesmo, as chances para a vitória ou para a derrota serão iguais; aquele que não conhece nem o inimigo e nem a si próprio, será derrotado em todas as batalhas (TZU, 2002, p.20). Um dos primeiros pesquisadores a estudar o ambiente como fonte de informação foi William Dill (MORESI, p. 40, 2001, apud CHOO, 1998a). Segundo o autor, existem duas perspectivas de se visualizar o ambiente de informações em relação a uma organização: ambiente de informações interno e ambiente de informações externo. Fazendo um paralelo com o modelo de sabedoria milenar de Sun Tzu, pode-se dizer que o conhecimento de si mesmo (da própria organização) seria a monitoração e analise do ambiente de informações interno, e o conhecimento do inimigo (concorrentes) seria a monitoração e analise do ambiente de informações externo. Portanto, para o ambiente de informações interno das organizações, pode-se fazer o uso do business intelligence como técnica de monitoração e análise. Howard Dresner definiu BI como conceitos e métodos que apoiam decisões empresariais fazendo o uso de sistemas de suporte baseados em fatos (BOUGMAN & DONGEN, 2009). No entanto, vale ressaltar que sistemas de BI não tomam decisões por si só.

14 7 Silveira (2007, apud VANTI, 2003) argumenta que BI é uma ferramenta capaz de automatizar a inteligência. Porém, a inteligência não é do BI, mas dos executivos que trabalham com os fatores macro e micro econômicos e que impactam no negócio. Grisi & Sobrinho (2000) listam algumas das aplicações onde podem ser empregados o business intelligence: Avaliação de investimentos; Avaliação de custos e benefícios; Análise de risco e gerenciamento (management); Avaliação de desempenho de vendas; Avaliação de ferramenta e produto; Etc. Existem várias ferramentas e técnicas em um sistema de BI, no entanto, os pacotes que compõe o seu núcleo são: ETL, DW, OLAP e data mining. A Figura 1 ilustra um sistema de BI genérico com esses pacotes. Observa-se que, embora os dados possam vir de vários lugares e com vários formatos, nesse caso, o ERP alimenta os bancos de dados operacionais, que por sua vez servirão de fonte para o DW. No entanto, antes de serem carregados para dentro do DW, os dados devem ser extraídos e transformados. Uma vez feito o processo ETL, podem-se aplicar ferramentas OLAP e data mining para a obtenção de informações e, assim, ter o ambiente de BI. Figura 1: Sistema de business intelligence, adaptado de Fortulan & Filho (2005)

15 Data Warehouse (DW) Na tradução literal, o termo data warehouse significa armazém de dados. Uma definição simples pode ser: Uma grande base de dados capaz de integrar as informações de interesse para a empresa (com a finalidade de dar suporte ao processo decisório), de forma concisa e confiável, que se encontram originalmente espalhadas em diversas fontes de dados, para a posterior utilização com ferramentas de análises (FELTES, 2010). O conceito de armazém de dados surgiu por duas razões: primeiro, pela necessidade de fornecer uma origem de dados única, limpa e consistente para fins de apoio à decisão; segundo, pela necessidade de fazê-lo sem causar impacto sobre os sistemas operacionais/transacionais (GOUVEIA, 2009). Willian H. Inmon, um dos precursores da ferramenta, a define da seguinte forma: Um data warehouse é um conjunto de dados baseado em assuntos, integrado, não volátil, e variável em relação ao tempo, de apoio às decisões gerenciais (BISPO, 1998, p. 35, apud INMON, 1997). A orientação por assunto significa que as informações armazenadas são agrupadas por assuntos de interesse da empresa que são mais importantes. Integrado porque os dados devem ser codificados em um formato consistente, seguindo a mesma regra para padrões de nome, valores, tipo de dados, unidades de medidas, etc. Não volátil porque os dados não se alteram após serem carregados no DW. Novos dados podem ser carregados de forma incremental. E por fim, variável em relação ao tempo pois representam resultados em um determinado momento no tempo. O DW, segundo a maioria dos modelos teóricos propostos pelos autores (Inmon, 1997, Brackett, 1996, Harrison, 1998, Meyer, 1998, dentre outros), utiliza as bases de dados do nível operacional (planilhas eletrônicas, documentos, dados transacionais de produção, marketing, recursos humanos, finanças, contabilidade, etc.) para construir um sistema de dados históricos (fatos) em forma bruta ou razoavelmente resumidos (CARVALHO et. al., 2006). Para se construir um DW também é necessário utilizar-se da modelagem dimensional para construção de tabelas. A modelagem dimensional permite visualizar os dados de várias

16 9 perspectivas, como por exemplo, tempo e o espaço, e foram criadas para modificar alguns conceitos tradicionais de banco de dados (FELTES, 2010, apud BARBIERI 2001). Algumas vantagens deste modelo de banco de dados sobre os modelos relacionais para aplicações de DW são citadas por Fortulan & Filho (2005, apud POE et al., 1998, BISPO, 1998) e descritas abaixo: Permite a criação de um projeto de banco de dados que fornecerá respostas rápidas, com menos tabelas e índices; Permite ao administrador do banco de dados trabalhar com projetos mais simples e assim produzir melhores planos de execução; Possui uma estrutura mais intuitiva, assemelhando o projeto do banco de dados com a forma como o usuário final pensa e usa os dados. Um dos tipos de modelagem dimensional é o modelo estrela. A Figura 2 ilustra o diagrama desse modelo: a tabela de fatos conecta-se as demais por múltiplas chaves primárias e as tabelas dimensões se conectam com apenas uma chave primária a tabela de fatos; essa tabela armazena grande quantidade de dados históricos, em função do tempo, obtidos a partir da interseção de todas as dimensões da estrela; a dimensão tempo é sempre integrante da chave primária e é na tabela de fatos onde se armazena os indicadores de desempenho do negócio. Figura 2: Modelagem dimensional de banco de dados utilizando o modelo estrela (autor)

17 10 A literatura fornece discussões e exemplos de uma variedade de arquiteturas de data warehouse. No entanto, os 5 principais são: independent data marts, data mart bus architecture with linked dimensional data marts, hub and spoke, centralized data warehouse, e federated (WATSON & ARIYACHANDRA, 2005; BOUGMAN & DONGEN, 2009) Extract, Transform and Load (ETL) Em um nível muito alto, o problema de povoação de um DW, e outras tarefas de integração de dados, consiste de apenas três tipos de processos: Extração - aquisição de dados de um ou mais sistemas fontes. Por exemplo, obtenção e carregamento de todos os registros de produtor que foram adicionados ou alterados desde o último carregamento de dados; Transformação - uma serie de regras de tratamento, limpeza e mapeamento nos dados adquiridos para ajustá-los a estrutura do banco de dados alvo, nesse caso, o DW; Carga - armazenar dados no alvo. Os dados usados nesses processos podem ser oriundos de qualquer fonte como por exemplo, aplicação ERP, arquivo de texto e planilha eletrônica. Dentro de cada processo principal, pode-se identificar outros processos de apoio (BOUGMAN & DONGEN, 2009), a exemplo de: Extração captura de dados, preparação de dados, etc.; Transformação - validação de dados, limpeza de dados, decodificação e renomeação, agregação, geração de chaves e gerenciamento, etc.; Carga carga e manutenção de tabelas fatos e dimensões, etc On Line Analytical Processing (OLAP) Conforme Bispo (1998), normalmente, decisões são tomadas baseando-se em comparações e em tendências; é necessário realizar análises em diversas perspectivas (dimensões) do negócio com o passar do tempo. O autor acrescenta ainda que é necessário a

18 11 construção de modelos de negócios para se realizar planejamentos, com base nos dados históricos disponíveis, ou seja, simular cenários a fim de se preparar para as incógnitas do futuro. No entanto, estes tipos analises e simulações não são funcionalidades do data warehouse, e sim do OLAP. OLAP são ferramentas baseadas em análise e orientadas à decisão. Segundo Silveira (2007, apud THOMSEN, 2002), o termo OLAP possui conceito ligado à linguagem de programação, ferramentas multidimensionais de análise de informações, além de ser considerado uma distinção do modo de processamento das informações. A autora ressalta que, normalmente, a quantidade de informações que esse tipo de ferramenta trata não poderia ser acessada por sistemas operacionais/transacionais sem problemas de performance nas consultas. Em um modelo de dados OLAP, a informação é conceitualmente organizada em cubos que armazenam valores quantitativos (medidas/fatos). As medidas são identificadas por duas ou mais categorias descritivas denominadas dimensões que formam a estrutura de um cubo. Uma dimensão pode ser qualquer visão do negócio que faça sentido para sua análise, como produto, departamento ou tempo. Este modelo de dados dimensional simplifica o processo de formular pesquisas ou consultas complexas, criar relatórios, efetuar análises comparativas, e visualizar subconjuntos de maior interesse. Esses cubos podem ser armazenados em modelos de bancos de dados ROLAP (Relacional OLAP), MOLAP (Multidimensional OLAP) ou HOLAP (Híbrido OLAP). Aplicações que utilizam esse tipo de ferramenta devem ter como características (FORTULAN & FILHO, 2005): Permitir visão multidimensional dos dados; Realizar cálculos complexos; Criar agregações e consolidações; Fazer previsões e análise de tendência; Construir cenários a partir de suposições; Fazer cálculos e manipular dados através de diferentes dimensões.

19 12 A ferramenta pode ser usada em diversas funções organizacionais (BISPO, 1998): Departamentos de Finanças, para planejar orçamentos e realizar análises financeiras; Departamento de Vendas, para fazer análises e estimativas de vendas; Departamento de Marketing, para realizar pesquisas e análises de mercado, estimativas, análises de clientes e segmentação de mercado; Manufatura, para realizar o planejamento, análises da produção e análises de falhas ou defeitos. A maioria das ferramentas OLAP são implementadas para ambientes multiusuário e arquitetura cliente/servidor, o que proporciona respostas rápidas e consistentes às consultas iterativas executadas pelos usuários, independentemente da complexidade da consulta (BISPO, 1998, FIGUEIREDO, 1998) e operações de analises utilizadas. As principais operações de analises permitidas por ferramentas OLAP são (FELTES, 2010, apud BARBIERI, MACHADO, SINGH, INMON, WELCH & GLASSEY): Drill-down: permite a movimentação da visão dos dados ao longo dos níveis hierárquicos de uma dimensão, permitindo navegação do nível mais alto até o dado detalhado; Drill-up/Roll up: tem o mesmo princípio da operação drill-down, mas permite a navegação inversa dos dados, ou seja, navega do nível de dados mais detalhado até o nível mais alto; Drill-across: permite a navegação da tabela dimensão passando de um nível para outro sem passar pelos níveis intermediários. Por exemplo, tabela dimensão tempo, que possui os campos ano, semestre, trimestre, mês, dia, passar da informação ano diretamente para dia; Drill-through: é quando há necessidade de uma informação em um nível de detalhe menor do que aquele armazenado na tabela fato, ou seja, é a operação que busca a informação além do nível de granularidade existente na estrutura dimensional;

20 13 Slice-dice: é a operação utilizada para acessar os dados do DW utilizando qualquer uma das dimensões de forma equivalente. Pode modificar a posição de uma informação, alterar linhas por colunas, modificar a dimensão, para facilitar a compreensão dos usuários; Pivoting/rotate: é a mudança das linhas e colunas da consulta, rotacionando as mesmas a fim de se obter uma nova visão das informações Data Mining O termo data mining (também conhecido como mineração de dados ou ainda garimpagem de dados ) descreve uma variedade de ferramentas que processam dados e geram estratégias que aumentam a utilidade dos dados armazenados em bancos de dados corporativos (BISPO, 1998, apud DATASAGE, 1998). Segundo Bispo (1998) o data mining pode ser usado com uma boa variedade de fontes de dados, incluindo os bancos de dados dos aplicativos operacionais e os Sistemas de Apoio à Decisão específicos. Porém, o Data Mining pode ser visto, de acordo com Silveira (2007, apud Harrison 1998), como uma ferramenta e técnica que acrescenta inteligência ao Data Warehouse. Data mining é o termo usado para descrever a descoberta de informações em bancos de dados. Data mining é um processo que utiliza técnicas sofisticadas de procura, como algoritmos de Inteligência Artificial, Redes Neurais, Árvores de Decisões, Regras de Indução, ou ainda, combinações entre elas, para descobrir novos padrões e relações de informações uteis e conhecimento subsequente que dificilmente seriam descobertos pelo ser humano a olho nu. De acordo com Silveira (2007, p.116, apud BARBIERI, 2001), o Data Mining se diferencia da técnica da OLAP, pois esta objetiva trabalhar os dados existentes, buscando consolidações em vários níveis, trabalhando fatos e dimensões. Já o Data Mining visa a realizar inferências, tentando adivinhar possíveis fatos e correlações não explicitadas nos dados de um DW. Segundo Batista (2009, apud SHAMMAS, 2006) ultimamente o uso de data mining vem crescendo muito, devido ao aumento do volume de dados dentro das empresas e à

21 14 popularização da criação de data warehouses, assumindo um papel importante no suporte aos processos de tomadas de decisão, as ferramentas utilizadas para data mining ainda são complexas e exigem alto conhecimento de estatísticas e das ferramentas para as quais possam ser utilizadas. 2.2 Pentaho O Pentaho é uma suíte de software livre, ou seja, sua distribuição é livre e o seu código fonte também. Ele reúne uma coleção de programas computacionais que trabalham juntos para criar e entregar soluções de business intelligence. Todas as ferramentas são baseadas em programas Java, o que gera produtividade na criação da solução e das estruturas usadas pela suíte e facilidade de integração com a Web. Alguns desses componentes fornecem funcionalidades que são muito básicas, como autenticação de usuários ou gerenciamento de uma conexão de banco de dados. Outros componentes fornecem funcionalidades que operam em alto nível (BOUGMAN & DONGEN, 2009): visualização de dados usando gráficos e relatórios, criação de indicadores para decisões gerenciais, integração com georeferenciamento, etc. Frequentemente os componentes que oferecem uma funcionalidade de alto nível se apoiam em outros componentes que oferecem funcionalidades de baixo nível. Com isso, a coleção de programas que forma toda a suíte pode ser vista como uma pilha de componentes, onde cada nível traz funcionalidades mais próximas ao usuário final (BOUGMAN & DONGEN, 2009). A Figura 3 ilustra a Pilha de Componentes Pentaho BI. As principais camadas da pilha são claramente identificadas. A maioria dos usuários finais interage com a camada de apresentação (presentation layer). As áreas funcionais principais da pilha (reporting, analysis, dashboards, e process management) constituem a camada de meio (middle) da pilha, onde a plataforma de business intelligence (BI platform), por si só, fornece estruturas básicas para segurança e administração. A camada de integracao de dados e aplicações(data & application integration) completa a pilha, e é necessário por pegar dados de vários sistemas de fonte e integrar em um ambiente de data warehouse. A seguir são apresentados os principais componentes do Pentaho.

22 15 Figura 3: Pilha de componentes Pentaho (BOUGMAN; DONGEN, 2009) Plataforma de Business Intelligence Fornece a arquitetura e infraestrutura necessária para construir soluções de business intelligence. É um servidor que oferece serviços de núcleo como autenticação, logging, serviços web e motores de regras. A plataforma também inclui um mecanismo que integra os componentes de reporting, analysis, dashboards e data mining. O design modular e a arquitetura baseada em plugin permitem que a plataforma seja embutida em aplicações de terceiros (PENTAHO CORPORATION, 2011). É composto por diversos outros aplicativos de software livre como o Apache, Tomcat, Jetty, Spring Security, Quartz, etc. (AMBIENTE LIVRE TECNOLOGIA, 2011) Integração de Dados e Aplicações O termo integração de dados (data integration) descreve a coleção de processos que resulta em, ou contribui, para a povoação de data wherehouses e outras tarefas, sendo o ETL uma categorização genérica dessa coleção. O Pentaho oferece uma conjunto de ferramentas coletivamente conhecido como Pentaho Data Integration (PDI), ou Kettle, que são

23 16 responsáveis por suportar tarefas de integração de dados e aplicações (BOUGMAN & DONGEN, 2009). O PDI pode ser utilizado, além de povoamento de data warehouses, para propósitos de (ROLDAN, 2008): Migração de dados entre bancos de dados ou aplicações; Exportação de dados para arquivos texto; Carga massiva de informação em bancos de dados; Correção de erros e inconsistências nos dados; Integração de aplicações; Etc. As soluções PDI são criadas em um ambiente gráfico e intuitivo, com design drag & drop, e sem necessidade de escrever código para indicar como fazê-las, o que torna o PDI orientado a metadados (PENTAHO CORPORATION, 2011). As soluções podem ser construídas em dois diferentes tipos de objetos: transformações (transformations) e trabalhos (jobs). O coração do PDI é formado pelo motor (engine) Pentaho data integration. Esse motor é um componente que é capaz de interpretar e executar esses objetos. Em adição ao motor, o PDI oferece um numero de ferramentas e utilidades para criar, gerenciar, e executar transformações e trabalhos (BOUGMAN & DONGEN, 2009). A Figura 4 ilustra uma visão geral, em alto nível, do funcionamento do PDI. Como se pode ver, um tema culinário foi usado na nomeação das ferramentas e utilidades (tools and utilities). A seguir são descritos rapidamente as ferramentas e utilidades, o funcionamento do motor e formas de armazenamento do PDI, sendo abordados também o que são transformações e trabalhos.

24 17 Figura 4: Ferramentas e componentes do Pentaho Data Integration (BOUGMAN & DONGEN, 2009) Ferramentas e Utilidades O PDI compreende as seguintes ferramentas e utilidades: Spoon Ambiente de desenvolvimento gráfico para criar transformações e trabalhos; Kitchen Ferramenta não gráfica para executar trabalhos; Pan Ferramenta não gráfica pra executar transformações; Carte Servidor para executar trabalhos e transformações em um host remoto.

25 18 Motor O Motor Pentaho data integration é fisicamente implementado como uma biblioteca Java. As ferramentas front-end utilizam uma API pública para que o motor execute transformações e trabalhos em seus favores como resposta a interação do usuário. Portanto, o motor pode ser utilizado em qualquer aplicação (BOUGMAN & DONGEN, 2009). Repositório Transformações e trabalhos criados podem ser armazenados em um repositório de banco de dados, ou seja, as ferramentas de front-end podem se conectar ao banco de dados e carregar transformações e trabalhos armazenados no repositório. O uso de repositório também oferece a vantagem de múltiplos desenvolvedores colaborarem em uma solução PDI de maneira fácil. Quando não se está trabalhando com repositórios, transformações e trabalhos são armazenados como arquivos em um formato XML. As transformações são salvas com extensão ktr e os trabalhos com extensão kjb. Nesse caso, sistemas de controle de versões externos, como o Subversion e o Git, podem ser utilizados. Transformations e Jobs Transformações e trabalhos contêm informações sobre: os dados, os sistemas fontes, e os sistemas alvos. Quando uma transformação ou trabalho é executado, essas informações são utilizadas para efetuar operações necessárias para realizar um determinado resultado. Isto é feito sem gerar nenhum código de programa intermediário, o que torna o PDI orientado a metadados. O Spoon é a interface que permite a criação de transformações e trabalhos de forma altamente gráfica. Eles são criados arrastando e soltando elementos em uma tela e os conectando conjuntamente para formar um diagrama. Esse processo é parecido com o de desenho de um fluxograma. Transformações e trabalhos contêm elementos que podem invocar um script (Javascript e Shell Script), mas isto é um exceção e não uma regra. Transformações As transformações são orientadas a fluxo de dados, e possuem o proposito de extrair, transformar e carregar dados.

26 19 Uma transformação é uma unidade de execução composta por elementos, conhecido como steps, conectados por meio de hops. Esses steps e hops formam caminhos por onde os dados passam: entram, se transformam e saem; ou seja, uma step denota um operação particular sobre um ou mais fluxos de registro e pode ser conectado por hops. Um hop é como um pipeline na qual registros podem fluir de um step para outro step. Por isso se diz que uma transformação é orientada a fluxo de dados (BOUGMAN & DONGEN, 2009). Uma coisa importante a se notar é que os steps trabalham simultaneamente e assincronamente. Quando uma transformação é executada, steps que sabem como gerar linhas de registro (extrair e transformar) baseado em alguma fonte de dado externa irá iniciar, gerando linhas até que a fonte de dados se esgote. Os registros que são transformados em um step fluem imediatamento para um ou mais steps inferiores (downstream), onde são processados na velocidade em que eles chegam, ou seja, os steps inferiores não esperam os seus respectivos steps superiores finalizar para iniciar seus processamentos (BOUGMAN & DONGEN, 2009), como ilustra a Figura 5. Trabalhos Figura 5: Steps, hops, e fluxo de registros (BOUGMAN & DONGEN, 2009) Tipicamente, os trabalhos são compostos por uma ou mais transformações. Por exemplo, para carregar um modelo estrela de um data mart, poderia se construir uma

27 20 transformação para extrair, transformar e carregar registros para cada tabela dimensão e e também para a tabela de fatos. Um trabalho poderia ser utilizado para colocar todos essas transformações em uma sequencia adequada para serem executados. Como nas transformações, os trabalhos consistem de um numero de elementos (steps) interconectados por hops, mas as semelhanças terminam ai. Os trabalhos são orientados a procedimentos e tarefas em vez de serem a fluxo de dados. Cada step denota a execução de um serviço especial. Uma conexão entre steps em um trabalho denota a ordenação sequencial desses serviços Pentaho Analysis (Mondrian) É um servidor OLAP que possibilita usuários de negócios analisar grandes quantidades de dados em tempo real (PENTAHO CORPORATION, 2011). Suas funcionalidades são: camada de metadados, linguagem MDX, cache em memória, tabelas agregadas, etc Pentaho Reporting É uma suíte software livre de ferramentas de relatórios que permite a criação de relatórios baseadas em consultas relacionais (SQL) e analíticas (MDX) de uma ampla gama de fonte de dados e tipos de saídas como PDF, Excel, HTML, CSV, etc. As expressões Open Formula/Excel formula contribuem para a criação de relatórios dinâmicos. A arquitetura aberta, a API e pontos de extensão garantem que esse sistema possa crescer conforme os requerimentos do usuário (PENTAHO CORPORATION, 2011) Pentaho Data Mining (Weka) É um abrangente conjunto de ferramenta para machine learning e mineração de dados. Sua ampla suíte de classificação, regressão, regras de associação e algoritmos de agrupamento pode ser usado para ajudar uma organização a entender melhor o seu negocio, e também ser explorados para melhorar a performance, futura, através de analises de predições (PENTAHO CORPORATION, 2011).

28 Métodos Quantitativos Segundo Viana (2002, p.108), os estoques representam componentes extremamente significativos, seja sob aspectos econômicos financeiros ou operacionais críticos. Diante desse cenário, os gestores de estoques se veem obrigados a atualizar seus conceitos e utilizar métodos estratégicos eficazes que apoiem a tomada de decisões. Para proporcionar informações exatas e atualizadas, é necessário que se faça a avaliação dos estoques utilizando métodos quantitativos, pelos seguintes motivos: Assegurar que o capital imobilizado em estoque seja o mínimo possível; Assegurar que estejam de acordo com a política da empresa; Garantir que o valor desse capital seja uma ferramenta de tomada de decisão; Evitar desperdícios como obsolescência, roubos, extravios etc. Alguns métodos quantitativos são apresentados a seguir Giro de estoque O giro indica o número de vezes que os itens em estoque giram, em um determinado intervalo de tempo, ou seja, quantas vezes, por unidade de tempo, o estoque se renovou. Fórmula: Giro de estoque = Valor consumido no período / Valor do estoque médio no período Cobertura de Estoques Dias que o estoque médio será suficiente para cobrir a demanda média. Fórmula: Cobertura (em dias) = (número de dias do período em estudo) / Giro de estoque

29 Custo de Estoque Uma das principais preocupações do gestor de estoques é saber quais são os custos relacionados ao(s) estoque(s) que ele gerencia. Os métodos de quantização de custos relacionados aos estoques são: custo de aquisição, custo de armazenagem e custo de falta. Custo de Aquisição Custo de aquisição é o valor pago pela empresa compradora pelo material adquirido. Fórmula: Custo de Aquisição = Preço Unitário x Quantidade Adquirida Custo de Armazenagem O custo de armazenagem de uma empresa comercial deve ser o mínimo possível, pois se trata de um dos itens que tem mais relevância dentro da empresa no momento de calcular sua lucratividade. Fórmula: CAmi = EM x PM x TE x CAmu onde CAmi = custo de armazenagem; EM = estoque médio; PM = preço médio; TE = tempo em estoque; CAmu = custo de armazenagem unitário. Custo de Falta Custo de falta de um item em estoque pode causar diversos e, muitas vezes, grandes prejuízos á empresa compradora. Duas formas de calcular os custos de falta de estoques são: por meio de lucros cessantes devidos a incapacidade de fornecer e perdas de lucros com cancelamento de pedidos Previsão da demanda Segundo Moreira (2002), é necessário saber quanto a empresa planeja vender de seus produtos ou serviços no futuro, pois essa expectativa é o ponto de partida para praticamente

30 23 todas as decisões. Esse trabalho foca apenas no método quântico dos mínimos quadrados (MMQ) para a previsão da demanda, na qual, envolve a análise numérica dos dados passados, isentando-se de opiniões pessoais ou palpites. O MMQ é usado para determinar a melhor linha de ajuste que passa mais perto de todos os dados coletados, ou seja, é a linha de melhor ajuste que minimiza as diferenças entre a linha reta e cada ponto levantado, na qual, pode ser chamada de linha de tendência linear. Essa linha é definida pela equação Y = a + bx. Nas séries temporais, Y é o valor de tendência em um índice x, que representa um determinado tempo (meses, anos, etc.), a partir de um índice base. O objetivo é determinar a, o valor de Y e b, a inclinação da reta. Para determinar os coeficientes a e b, utilizam-se as seguintes equações: Y = Na + b X XY = a X + b X2 Essas duas equações são denominadas equações normais. As quatro somas necessárias à resolução das equações são obtidas de forma tabular, onde N é o número de índices (distância) entre x e a base, e X é igual aos índices dos períodos a partir do ano base. Depois da obtenção das quatro somas, estas são substituídas nas equações normais, onde os valores de a e b são calculados e substituídos na equação da linha de tendência linear para obtenção da formula que encontrará o valor de tendência. Exemplo: Uma empresa quer calcular a tendência de vendas (por quantidade) de um certo produto para o ano de O Gráfico da Figura 4 ilustra a linha de tendência. As Figura 6: Exemplo de calculo da tendência

31 vendas dos cinco anos anteriores foram conforme a Tabela da Figura 4, de onde resultam as seguintes equações baseadas nas equações normais (respectivamente): = 5a + 15b 5442 = 15a + 55b Para encontrar o coeficiente b: 5a + 15b = 1767 (-3) 15a + 55b = a - 45b = a + 55b = 5442 Substituindo b na primeira equação normal: 10b = 141 b = 14, = 5a + (15 x 14,1) 1767 = 5a + 211, = 5a + 211,5 a = 311,1 Logo a tendência para 2005 é: Y = 311,1 + (14,1 x 6) Y = 395,7 = 396 unidades

32 25 3 Solução Business Intelligence Segundo Matheus & Parreiras (2004), é possível associar cada fase do processo espiral de engenharia de software a um processo de conversão da espiral do conhecimento de Nonaka e Takeuchi para construção de uma solução de business intelligence. A Figura 7 ilustra essa associação. Figura 7: Espiral do conhecimento e modelo espiral de desenvolvimento de software (MATHEUS & PARREIRAS 2004). Na fase de análise, o conhecimento tácito do analista de negócios ou do tomador de decisão tem que ser socializado com o analista de sistemas, responsável pelo desenvolvimento da solução de BI. Posteriormente, na fase de desenvolvimento, o conhecimento socializado deve ser externalizado (conceitualizado e codificado) na solução que está sendo desenvolvida, através da elaboração de tabelas de dados, desenvolvimento (ou aplicação) de algoritmos adequados para cada problema organizacional, etc. No momento em que o sistema de BI está em operação, grandes massas de dados são combinadas e analisadas, transformando-as em informações uteis, ou seja, convertendo o conhecimento explícito em conhecimento explícito. Finalmente, o usuário final, ao participar da análise da solução BI, e principalmente ao fazer uso da solução, é capaz de criar novos perspectivas sobre o negócio da organização. Nesta

33 26 fase, o conhecimento é internalizado. Quando ocorrem as manutenções ou alterações na solução de BI todo o ciclo se repete em um processo iterativo. (MATHEUS & PARREIRAS 2004). Os autores acrescentam ainda que, em cada fase do processo de engenharia de software, existe em si espirais do conhecimento, como representado nos círculos nos quais está escrito BI na Figura 7. Portanto, o objetivo deste capitulo é apresentar as 5 etapas que foram necessárias para se desenvolver a solução business intelligence com o Pentaho, para favorecer o processo de decisões estratégicas relacionadas a gestão de estoques no Atacadão de Estivas e Cereais Rio Do Peixe. Ressaltando que o contexto de cada etapa apresentada relaciona-se principalmente com a fase de externalização- desenvolvimento de sua respectiva espiral. 3.1 Criação do Data Warehouse Para criação do data warehouse, o primeiro passo foi escolher a arquitetura que iria ser utilizada. A arquitetura escolhida, e a mais popular, foi a data mart bus (ilustrada na Figura 8), por ser mais simples de entender, fácil de implementar e ter uma boa escalabilidade (BOUGMAN & DONGEN, 2009). Com essa arquitetura, as dimensões e medidas criadas para um data mart, de um processo de negócio específico, podem ser utilizadas em outros, resultando em data marts integrados. Neles, dados atômicos e sumarizados podem ser utilizados, e são organizados com o modelo estrela para possibilitar uma visão dimensional dos dados (WATSON & ARIYACHANDRA, 2005). Figura 8: Data Mart Bus, adaptado de Watson & Ariyachandra (2005) O segundo passo foi fazer o modelo lógico do negócio. A Figura 9 ilustra o modelo lógico dimensional dos data marts criados. As tabelas fatos que compõe o modelo são: Pedidos, Estoque e Perdas por Produto.

34 27 Figura 9: Data marts para apoiar o processo de gestão de estoques (autor) Na tabela Pedidos são registrados valores das vendas realizadas, que são sumarizados por dia de pedido, status (se está bloqueado, faturado, cancelado, etc.), filial da empresa, cliente, vendedor, supervisor do vendedor, produto e fornecedor do produto. Cada processo de venda da empresa é identificado por meio de um único código que sirva para toda a empresa ou filial, que é o código do pedido.

35 28 Na tabela de estoques, é registrado, para cada código de produto, o estoque disponível, giro dia, giro mês, dias disponíveis do estoque conforme o giro mês, valor do estoque e a quantidade da última entrada. Os registros são sumarizados apenas pela filial. Na tabela de Perdas por Produtos, é registrado, para cada código pedido, a quantidade (qt) de produtos que não foram vendidos por falta em estoque e o preço unitário (pvenda) desse produto, onde o valor perdido para tal pedido é igual qt * pvenda. Os registros são sumarizados por dia de pedido, filial da empresa, cliente, vendedor, supervisor do vendedor, produto e fornecedor do produto. Apesar de parecer simples, esses data marts podem responder muitas questões, tanto relacionadas a gestão de estoques como outros tipos de negócios. Algumas questões: Quanto foi a quantidade de produtos vendidos em um determinado período? Qual a margem de lucro do produto (preço uni. fornecedor x preço uni. de venda)? Qual foi a taxa de crescimento de um determinado período em relação ao anterior? Qual o estoque disponível, e qual o custo desse estoque? Qual o giro do estoque? Quanto a empresa perdeu por falta de um determinado produto no estoque (pedido cancelado)? Quantos clientes compraram um determinado produto em um certo período? Qual a margem de lucro de um vendedor em relação a um período passado? Etc. Para se ter uma ideia da possibilidade de consultas deste modelo, basta calcular quantas combinações de consultas são possíveis de se efetuar a partir de cada tabela de Fato em função de seus atributos e valores medidos: Tabela de Pedidos: 9 atributos e dois valores ( 9 i=1 C 9,i ) * 2 = 1022 Tabela de Estoque: 2 atributos e 6 valores

36 29 ( 2 i=1 C 2,i ) * 6 = 18 Tabela de Perdas por Produto: 8 atributos e 2 valores ( 8 i=1 C 8,i ) * 2 = 510 Total = 1550 combinações possíveis, sem considerar os possíveis subníveis de cada dimensão. Após ter sido criado o modelo lógico, foi feito o modelo físico dimensional, para implementar os data marts em um banco de dados. Nessa tarefa, o Power architect 2 foi utilizado, que é uma ferramenta de modelagem que facilita a tarefa de criação de tabelas fatos e tabelas dimensões e gera scripts necessários para a implementação do modelo em diversos bancos diferentes (Oracle, Postgres, SQL Server, MySQL, Derby e HSQLDB). 3.2 Criação de processos ETL com o Kettle Quando o modelo dimensional do data warehouse foi estabilizado, foram modelados processos ETL para povoar o DW com dados. A ferramenta utilizada para realizar tais processos foi o Pentaho Data Integration, através de transformações, que por sua vez, foram salvos em um repositório de banco de dados. Os modelos ETLs criados no PDI estão no Anexo Criação dos cubos OLAP Foi utilizado o servidor ROLAP do Pentaho, o Mondrian, como sendo o servidor de cubos da solução. Os cubos, baseados no data marts ilustrados pela Figura 9, foram feitos utilizando a ferramenta de construção de cubos do Mondrian, o Mondrian Schema Workbench, que permite a criação de esquemas de cubos visualmente. Esses esquemas são modelos de metadados XML criados em uma estrutura especifica para mapear as tabelas dimensões e tabelas fatos de um data warehouse (que nesse caso, devem estar em um banco de dados relacional) e são renderizados pelo Mondrain, para que consultas MDX possam ser modeladas e executadas. 2

37 Criação das consultas MDX Foram criadas consultas MDX para obtenção das informações necessárias para criação das apresentações. A ferramenta utilizada foi o Mondrian, na qual, permite que consultas MDX sejam processadas dinamicamente com praticamente todas as operações de analises OLAP em uma interface Web, além de gerar gráficos baseados nas consultas. Alguns exemplos de consultas são apresentados no Anexo Criação das apresentações As apresentações foram baseadas em consultas MDX e foram modeladas utilizando o Pentaho Report Designer. No Anexo 3 pode ser encontrado um exemplo dos relatórios criados. 3.6 Difusão das informações Para automatizar o processo de geração e difusão das informações foram criados Trabalhos PDI. Sendo que os relatórios criados são enviados por para os gestores interessados. O Anexo 4 apresenta alguns trabalhos criados. Para fazer o agendamento de execução dos trabalhos, foi utilizado o agendador de tarefas e rotinas do Linux (Cron).

38 31 4 Especificação Técnica Este capítulo apresenta a especificação técnica da solução criada, apresentando o sistema operacional utilizado, as versões das ferramentas utilizadas e como elas foram organizadas no sistema de arquivos. 4.1 Servidor Memoria Ram: 2 GB SWAP: 2GB Kernel: Linux pentaho generic-pae #55-Ubuntu SMP Mon Jan 10 22:34:08 UTC 2011 i686 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu LTS Release: Codename: lucid 4.2 Ferramentas Pentaho configuradas: As seguintes ferramentas Pentaho, com suas respectivas versões, foram instaladas e

39 32 Business Intelligence Server (administration-console & biserver-ce), stable 3 Pentaho Data Integration (data-integration), stable 4 Pentaho Design Studio (design-studio), stable 5 Pentaho Report Designer (report-designer), stable 6 Mondrian Schema Workbench (schema-workbench), Outros As seguintes ferramentas de suporte/pré-requisito, com suas respectivas versões, foram instaladas e configuradas: Oracle JDBC Driver (ojdbc14.jar), 1.4 Java Development Kit (jdk1.6.0_16), 1.6.0_16 SQL Power Architect Community Edition (power-architect-1.0.0), Oracle SQL Developer (sqldeveloper), SQLeonardo (sqleonardo rc1), rc Sistema de arquivos O Anexo 4 apresenta a estrutura em que as ferramentas foram instaladas e configuradas no sistema de arquivos do servidor

40 33 5 Conclusão Os ERPs geram uma grande quantidade de dados diariamente. Com tal volume de dados, fica praticamente impossível para o gestor de estoques obter informações relevantes e em tempo hábil, se não estiver disponível uma ferramenta que sistematize e organize a recuperação dos dados, de modo a aplicar métodos quantitativos. É justamente para este foco que o estágio foi voltado, onde este relatório por sua vez, apresentou a solução BI criada durante o estágio para prover informações uteis aos gestores de estoque do Atacadão de Estivas e Cereais Rio do Peixe. No presente relatório foi apresentado os data marts integrados que foram criados para a empresa utilizando a arquitetura Data Mart Bus. Para construção e analise de cubos OLAP foi utilizado a ferramenta Mondrian, onde foi possível verificar a facilidade e flexibilidade do Pentaho. Para criação do relatório de apresentação das informações do estoque foi utilizado o Pentaho Report Designer. Embora o foco do estágio tenha sido na previsão da demanda/consumo, pode-se constatar que a solução criada pode ser uma base muito forte para outros métodos quantitativos como custo do estoque, custo de armazenagem, giro do estoque, estoque de segurança, cobertura de estoques, etc. Portanto, de modo que o gestor possua ainda mais informações corretas, rápidas e uteis para embasar suas decisões estratégicas, os próximos passos desse trabalho podem ser a exploração de outros métodos quantitativos, de melhores formas para apresentar as informações como gráficos e painéis de controle, e da aplicação do Weka, a ferramenta Pentaho para o data mining.

41 34 6 Sobre o estágio A realização desse estágio teve uma contribuição extremamente positiva para ambos os lados, estagiário e empresa, pois através dele o estagiário pode obter uma grande experiência de como funciona todos os processos que envolvem uma empresa. Além disso, observar e conhecer um pouco mais sobre as estratégias e lógicas de outros negócios da empresa. Outrossim, disciplinas como Algoritmos e Logica de Programação, Probabilidade e Estatística, Programação Orientada a Objetos, Desenvolvimento de Aplicações Web e Administração de Sistemas, puderam ser utilizadas na prática. O conhecimento teórico destas disciplinas foi fundamental para o sucesso do estágio e sem as quais a realização do estágio teria sido muito difícil. No entanto, vale ressaltar também que outras disciplinas, que não estão na matriz curricular do curso superior de tecnologia em telemática, foram também de muita importância como Banco de Dados, Business Intelligence, Gestão da Informação e Comunicação, e Inteligência Competitiva. O aprendizado das mesmas ratifica a capacidade do estagiário de aprender novas tecnologias e conceitos. O estágio possibilitou adquirir uma visão crítica, análise do ambiente e capacidade de visualizar perspectivas futuras e sugerir melhorias, tornando-se uma experiência rica, tanto profissional como pessoal.

42 35 Referências AMBIENTE LIVRE TECNOLOGIA. Conhecendo o Pentaho BI Server - Arquitetura e infraestrutura. Disponível em < Acesso em: 22 abril, BATISTA, M. Integração de soluções de "Business Intelligence" e Geoprocessamento para o agronegócio. Trabalho de conclusão de curso de especialização, Especialização em Analise, Projeto e Gerência de Sistemas, Universidade Estadual de Londrina, Londrina, BISPO, C. A. F. Uma análise da nova geração de sistemas de apoio à decisão. Dissertação de mestrado, Pós-graduação em Engenharia de Produção, Universidade de São Paulo, São Carlos, BOUGMAN, R.; DONGEN, J. Pentaho Solutions, Business Intelligence and Data Warehousing with Pentaho and MySQL. WILEY, Indianapolis, CAPUANO, E. A.; CASAES, J.; JESUS, M. S.; COSTA, J. R.; MACHADO, M. A. Inteligência competitiva e suas conexões epistemológicas com gestão da informação e do conhecimento. Ci. Inf., v. 38, n. 2, p , Brasília, maio/ago, CARVALHO, F. B. A. CASTRO, J. E. E. CAGNIN, C. H. ABREU, A, F. Proposta de metodologia para desenvolvimento de Data Warehouse vislumbrando atingir metas parciais FELTES, L. H. Desenvolvimento de uma Solução de BI para o ERP SIGER. Trabalho de Conclusão de Curso, Graduação em Ciências da Computação, Universidade FEEVELE, Novo Hamburgo, FORTULAN, M. R. FILHO, E. V. G. Uma proposta de aplicação de Business Intelligence no chão-de-fabrica. Gestão & Produção v.12, n.1, p.55-66, GIANESI, I. G. N. & BIAZZI, J. L. Gestão Estratégica dos Estoques. Insper Working Paper,

43 GOUVEIA, R. M. M. Mineração de Dados em Data Warehouse para Sistema de Abastecimento de Água. Dissertação de mestrado, Pós-graduando em Informática, Universidade Federal da Paraiba, João Pessoa, GRISI, E. R.; SOBRINHO, H. B. L. Transformando Informação em Vantagem Competitiva. Monografia de especialização, Pós-graduação em Administração, Universidade Federal da Bahia, Bahia, MATHEUS, R. F.; PARREIRAS, F. S. Inteligência empresarial versus Business Intelligence: Abordagens complementares para o apoio à tomada de decisão no Brasil. Congresso anual da sociedade brasileira de gestão do conhecimento, v. 3, São Paulo, PENTAHO CORPORATION. Pentaho Community Home Disponível em < Acesso em: 22 abril, SILVEIRA, F. C. S. Construção de modelo de Business Intelligence para a controladoria evidenciar informações estratégicas: O caso do SESI - Serviço Social da Industria do Estado do Rio Grande do Sul. Dissertação de mestrado, Pós-graduação em Ciências Contábeis, Universidade do Vale do Rio dos Sinos, São Leopoldo, TRAJANO, B. A. Aplicação do Calculo de Lote Econômico de Produção: Estudo de Caso de uma Empresa do Ramo Siderúrgico. Trabalho de Conclusão de Curso, Graduação em Engenharia de Produção, Universidade Federal de Ouro Preto, Ouro Preto, WATSON, H. J. & ARIYACHANDRA, T. Data Warehouse Architectures: Factors in the Selection Decision and the Success of the Architectures

44 37 Anexo 1: Processos ETL bi_time_dimension Na tabela Tempo são registrados um conjunto de datas, que são sumarizados por dia no mês, dia na semana, dia no ano, mês, trimestre, ano, etc. Cada data é identificada por meio de um único código (day_id) de modo a facilitar consultas que estejam relacionadas a um determinado período. A Figura 10 ilustra o processo ETL que foi modelado para povoar a tabela Tempo (BI_TIME_DIMENSION, no modelo físico) com datas. O primeiro step define a data base (base_date) para a geração das datas (ex. 31/12/2004). O segundo step define um loop que inicia de 1 até um valor desejado, e servirá para gerar os códigos das datas (ex. para que um conjunto de datas seja referente ao ano de 2005, o valor final seria 365; para 2005 e 2006, seria 730; etc.). O terceiro step soma o day_id (gerado na etapa anterior) mais o date_base e realiza cálculos básicos de datas (dia no mês, mês, ano etc.) baseados na soma (day_date = day_id + date_base; ex. para day_id = 1, a soma será igual 01/01/2005, que por sua vez é a data inicial da tabela Tempo) e armazena os resultados em alguns campos. O quarto step gera mais alguns campos baseados no day_date, como o nome do dia na semana (weekday_name), o nome do mês (month_name), semana no ano (week_yyyyww), etc. O quinto step verifica se o day_date é final de semana ou não e salva a resposta no campo is_weekend. O sexto step calcula o semestre do day_date e salva no campo quarter. O último step inseri o day_id e todos os seus campos nos campos correspondentes na tabela Tempo.

45 38 bi_fornecedor Figura 10: Transformação que povoa a tabela Tempo Na tabela Fornecedor são registrados os fornecedores da organização, onde dada fornecedor é identificado por meio de um único código (codfornec) e um campo que identifica se o mesmo faz parte dos fornecedores principais ou não. Figura 11: Transformação que povoa a tabela Fornecedor

46 39 bi_cliente Na tabela Cliente são registrados os clientes da organização, onde cada cliente é identificado por meio de um único código (codcli) e são apontados informações sobre o mesmo como nome, código do seu vendedor, data da ultima compra, código da cidade, etc. O processo ETL modelado para povoar a tabela Cliente é ilustrado na Figura 12: o primeiro step extrai do banco de dados do ERP da empresa as informações necessárias sobre os clientes por meio de uma consulta SQL; em seguida os nomes do clientes são normalizados; para então os campos extraídos e transformados serem inseridos/atualizados na tabela Cliente. Figura 12: Transformação que povoa a tabela Cliente bi_usuario Na tabela Usuario são registrados os vendedores/rcas da organização, onde cada um é identificado por meio de um único código (codusur) e são apontados informações sobre o mesmo como nome, código do seu supervisor, data da ultima venda, clientes ativos desse vendedor, etc. O processo ETL modelado para povoar a tabela Usuario é ilustrado na Figura 13: o primeiro step extrai do banco de dados do ERP da empresa as informações necessárias sobre os vendedores por meio de uma consulta SQL; em seguida os nomes do clientes são normalizados; para então os campos extraídos e transformados serem inseridos/atualizados na tabela Vendedor. Figura 13: Transformação que povoa a tabela Vendedor

47 40 bi_supervisao Na tabela Supervisor são registrados os supervisores dos vendedores da organização, onde cada um é identificado por meio de um único código (codsupervisor) e são apontados informações sobre o mesmo como nome, tipo de supervisão, código como vendedor, etc. O processo ETL modelado para povoar a tabela Supervisor é ilustrado na Figura 14: o primeiro step extrai do banco de dados do ERP da empresa as informações necessárias sobre os supervisores por meio de uma consulta SQL; em seguida seus nomes são normalizados; para então os campos extraídos e transformados serem inseridos/atualizados na tabela Supervisor. Figura 14: Transformação que povoa a tabela Supervisor bi_produto Na tabela Produto são registrados os produtos que a organização oferece/ofereceu, onde cada um é identificado por meio de um único código (codprod) e são armazenados informações sobre o mesmo como descrição, código do fornecedor, data de cadastro, etc. O processo ETL modelado para povoar a tabela Produto é ilustrado na Figura 15: o primeiro step extrai do banco de dados do ERP da empresa as informações necessárias sobre os produtos por meio de uma consulta SQL; em seguida suas descrições/nomes são normalizadas; para então os campos extraídos e transformados serem inseridos/atualizados na tabela Produto. Figura 15: Transformação que povoa a tabela Produto

48 41 bi_posicao Na tabela Posicao são registrados os tipos de status que os pedidos dos clientes podem estar, onde cada tipo é identificado por meio de um único código (posicao) e é armazenado a legenda desse tipo. Por ser simples e ter valores fixos, essa tabela só foi utilizada uma vez, onde para povoá-la foi utilizado o processo ETL ilustrado na Figura 16, que utiliza um arquivo simples CSV como fonte de informações dos status (posição e legenda). Figura 16: Transformação que povoa a tabela Posicao bi_filial razoes sociais. Na tabela Filial são armazenadas apenas os códigos das filiais com suas respectivas O processo ETL criado apenas copia as informações necessárias do banco de dados do ERP para a tabela Filial, como ilustra a Figura 17. Figura 17: Transformação que povoa a tabela Filial

49 42 bi_pedi_fact O processo ETL modelado para povoar a tabela Pedidos é ilustrado na Figura 18: o primeiro step extrai do banco de dados do ERP da empresa as informações necessárias sobre os pedidos por meio de uma consulta SQL; em seguida o campo day_id é configurado, com base na data do pedido corrente; para então os campos extraídos e transformados serem inseridos/atualizados na tabela Pedidos. Figura 18: Transformação que povoa a tabela Pedidos bi_estoque O processo ETL modelado para povoar a tabela Estoque é ilustrado na Figura 19: o primeiro step extrai do banco de dados do ERP da empresa as informações necessárias sobre o estoque dos produtos por meio de uma consulta SQL; em seguida os campos extraídos e transformados serem inseridos/atualizados na tabela Estoque. Figura 19: Transformação que povoa a tabela Estoque

50 43 bi_falta O processo ETL modelado para povoar a tabela Perdas é ilustrado na Figura 20: o primeiro step extrai do banco de dados do ERP da empresa as informações necessárias sobre as perdas de vendas dos produtos por falta em estoque, através de uma consulta SQL; em seguida o campo day_id é configurado, com base na data da perda; para então os campos extraídos e transformados serem inseridos/atualizados na tabela Perdas. Figura 20: Transformação que povoa tabela Perdas

51 44 Anexo 2: Exemplos de análises OLAP Perdas por falta de produtos em 2011, todos os meses Na linguagem MDX, a instrução SELECT especifica um conjunto de resultados que contém um subconjunto de dados multidimensionais retornados a partir de um cubo. O exemplo a seguir apresenta uma consulta MDX básica que usa a instrução SELECT. Ela retorna um conjunto de resultados que contém os valores da perda que a empresa sofreu nos meses de 2011 por falta de produtos. select NON EMPTY {[Time].[2011].CHILDREN} ON COLUMNS, NON EMPTY {[Measures].[vlperda]} ON ROWS from [Perdas] MDX 1: Consulta para pesquisar as perdas nos meses de 2011 Na consulta MDX 1, são definidas as seguintes informações do conjunto de resultados: A cláusula SELECT define, no eixo das colunas, a função MDX Children para retornar os membros filhos (meses) de 2011 da dimensão tempo e usa a medida valor da perda (VLPERDA), no eixo das linhas 11 ; A cláusula FROM indica que a fonte de dados é o cubo Perdas; A palavra-chave NON EMPTY, usada antes das definições configuradas, é uma maneira fácil de remover todas as tuplas vazias de um eixo. A Figura 21 apresenta os dados gerados pela consulta com seu gráfico de barras verticais, ambos gerados pelo Mondrian. 11 É possível especificar até 128 eixos em uma consulta MDX;

52 45 Figura 21: Gráfico de barra vertical de todos os meses de 2011 Perdas por falta de produtos em 2011, TOP 10 Na linguagem MDX, um membro calculado é aquele resolvido pelo cálculo de uma expressão MDX para retornar um valor. Essa simples definição abrange uma quantidade enorme implicações. A capacidade de construir e usar membros calculados em uma consulta MDX proporciona uma grande capacidade de manipulação de dados multidimensionais 12. Se um membro calculado for necessário para uma única consulta da linguagem MDX, é possível defini-lo usando a palavra-chave WITH. O membro calculado criado com a palavra-chave WITH deixará de existir ao fim da execução da consulta 13. O exemplo MDX 2 retorna um conjunto de resultados que contém os TOP 10 valores da perda por produtos e faz o uso do WITH. with MEMBER [Measures].[Year] as SUM( PERIODSTODATE([Time].Year, [Time].[2010]), [Measures].[VLPERDA] ) select NON EMPTY { [Measures].[Year]} ON COLUMNS, NON EMPTY { HEAD( ORDER([Produto2].[Produto].Members, [Measures].[Year], desc), 10 ) } ON ROWS from [Perda] MDX 2: Consulta para pesquisar as perdas TOP 10 de

53 A Figura 22 apresenta os dados gerados pela consulta com seu gráfico de pizza, ambos gerados pelo Mondrian. 46 Figura 22: Gráfico de pizza dos produtos, TOP 10

54 47 Anexo 3: Exemplo de Relatório Criado A Figura 23 ilustra um exemplo de relatório criado utilizando uma consulta MDX e o Pentaho Report Designer. O relatório apresenta ao gestor de estoques todas as informações fundamentais para apoiar suas decisões como: Quantidade de produtos vendidos (Qt. Vendidos); A tendência da quantidade de produtos que irão ser vendidos naquele mês (Qt. Tendência), baseando-se nos 12 meses anteriores; A margem de contribuição da venda do produto em relação preço de venda para cliente vs. preço de compra do fornecedor (M. Contrib.); Estoque que ainda tem disponível para cada produto (Estoque Disp.); O valor do estoque em reais (R$); Dias em que o estoque ainda estará disponível, baseando-se no giro mensal calculado pelo ERP da empresa; Etc.

55 Figura 23: Relatório de produtos vendidos, utilizando MDX + PRD 48

56 49 Anexo 4: Jobs A Figura 24 apresenta o trabalho criado para povoar todas as tabelas dimensões criadas, nela, todos os steps (exceto o primeiro, que é o step que da inicio a execução do trabalho) são transformações criadas para realizar os processos ETLs (ver Anexo 1). Figura 24: Trabalho para a povoação das tabelas dimensões A Figura 26 apresenta o trabalho criado para povoar as tabelas fatos. Figura 25: Trabalho para povoação das tabelas fatos A Figura 26 apresenta o trabalho para gerar os relatórios e enviá-los por aos usuários. O primeiro step é um trabalho que define as configurações básicas como a lista de e- mails que receberão os relatórios, o banco de dados que irá ser utilizado, os relatórios que vão ser gerados, os formatos dos relatórios, etc. O segundo trabalho gera os relatórios. O terceiro envia os relatórios gerados. Figura 26: Trabalho para automatizar a geração e envio de relatórios