PROPOSTA DE DATA MART PARA ANÁLISE DE FATURAMENTO
Propaganda
PROPOSTA DE DATA MART PARA ANÁLISE DE FATURAMENTO DE EMPRESA DE VAREJO UTILIZANDO SOFTWARE LIVRE RESUMO Em mercados turbulentos, em que as decisões precisam ser cada vez mais rápidas, é necessário ter sempre escolhas certas e oportunas, tomadas de forma econômica e precisa. Esse é o mundo globalizado, aonde as mudanças no mercado são constantes e as empresas enfrentam enormes dificuldades para continuarem competitivas e em crescimento. Grandes corporações também passaram a competir fortemente com empresas de comércio local, especialmente através do e-commerce, tornando-se indispensável, a utilização de mecanismos que possibilitem aos gestores uma administração mais eficiente dos recursos empresariais. Diante desse contexto, este trabalho relata a implementação de uma solução de Business Intelligence, no caso um Data mart, com a utilização de software livre (Pentaho), objetivando o fornecimento de informações gerenciais da área financeira, mais precisamente do processo de faturamento de uma empresa do ramo varejista, que utiliza software de prateleira para controle de seus processos de negócio. Observouse, com base nos resultados da pesquisa, que o Data mart proposto possibilitou análises rápidas, fáceis, flexíveis e seguras, tendo aplicabilidade imediata e servindo de instrumento no apoio ao planejamento estratégico da organização. Além disso, este trabalho mostrou ser totalmente viável, em termos técnicos e financeiros, a implantação de ferramentas de BI do tipo software livre em pequenas empresas. PALAVRAS-CHAVES: Business Intelligence; Data mart; Software Livre; Financeiro; Faturamento. PROPOSAL OF A DATA MART FOR ANALYSIS OF A RETAIL SALES COMPANY USING FREE SOFTWARE ABSTRACT In turbulent markets, where decisions need to be ever faster, you must always select the appropriate and timely choices, made inexpensively and precisely. That's globalized world, where changes in the market are constant and businesses face enormous difficulties to remain competitive and growing. Large corporations also began to compete strongly with local trading companies, especially through ecommerce, making it essential to use mechanisms that allow managers to more efficient management of business resources. Given this context, this paper describes the implementation of a Business Intelligence solution, a Data mart, with the use of free software (Pentaho), aiming to provide the financial management information, more precisely the billing process of a company in the retail industry, which uses shelf software to control their business processes. It was observed, based on the survey results, the Data mart proposed enabled fast, easy, flexible and secure analysis, with immediate applicability and serving as an instrument to support the organization's strategic planning. Furthermore, this work pointed out that is entirely feasible, in technical and financial terms, the deployment of free BI tools for small businesses. KEYWORDS: Business Intelligence; Data mart; Free Software; Financial; Billing. Revista Brasileira de Administração Científica, Aquidabã, v.3, n.2, Ago 2012. ISSN 2179‐684X SEÇÃO: Artigos TEMA: Sistemas de Informação Anais do Simpósio Brasileiro de Tecnologia da Informação (SBTI 2012) DOI: 10.6008/ESS2179‐684X.2012.002.0011 Cleisson Fabricio Leite Batista Universidade Federal Rural de Pernambuco, Brasil http://lattes.cnpq.br/3704053393458026 [email protected] Ellen Polliana Ramos de Souza Universidade Federal Rural de Pernambuco, Brasil http://lattes.cnpq.br/6593918610781356 [email protected] Jorge da Silva Correia Neto Universidade Federal de Pernambuco, Brasil http://lattes.cnpq.br/6369240444943934 [email protected] Jairo Simião Dornelas Universidade Federal de Pernambuco, Brasil http://lattes.cnpq.br/3980081716191136 [email protected] Recebido: 10/06/2012 Aprovado: 15/08/2012 Avaliado anonimamente em processo de pares cegas. Referenciar assim: BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S.. Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre. Revista Brasileira de Administração Científica, Aquidabã, v.3, n.2, p.163‐180, 2012. Revista Brasileira de Administração Científica é uma pub. da Escola Superior de Sustentabilidade Rua Dr. José Rollemberg Leite, 120, Bairro Bugio, CEP 49050‐050, Aquidabã, Sergipe, Brasil Site: www.arvore.org.br – Contato: [email protected] – Telefone (79) 9979‐8991 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. INTRODUÇÃO No mundo globalizado as mudanças no mercado são constantes e as empresas enfrentam enormes dificuldades para continuarem competitivas e em crescimento. Nesse contexto, torna-se necessária a utilização de mecanismos que auxiliem os gestores a administrarem de forma eficiente os recursos empresariais. Empresas do ramo varejista têm crescido no Brasil. Segundo o IDV (2009), esse segmento de mercado representa 15,5% do PIB brasileiro e estima-se que nos próximos dez anos esse valor possa representar no mínimo 20%. Visando acompanhar esse crescimento, grandes empresas como Oracle, IBM e Microsoft investem fortemente no desenvolvimento de soluções proprietárias de business intelligence (BI). Essas soluções facilitam o processo de tomada de decisão e possibilitam vantagem competitiva, mas representam alto custo. Muitas empresas de pequeno e médio porte não possuem recursos financeiros para investir nessas soluções. No ambiente gerencial, o processo decisório pode ser visto como um fator determinante para a sobrevivência e crescimento das organizações, pois é através dele que os tomadores de decisão podem encontrar as respostas que necessitam para solucionar os desafios do negócio. Para suportar o processo decisório são necessárias informações. As informações estratégicas melhoram o processo decisório e o planejamento das organizações (SIQUEIRA, 2005). O planejamento estratégico representa as decisões tomadas pelo nível mais alto da organização, os reflexos das escolhas tomadas pelos gestores nesse nível englobam toda a organização. Nesse contexto organizacional, o processo de análise do faturamento facilita a identificação dos seguintes aspectos dentro da organização: Perfil dos clientes que mais geram receita; Perfil das regiões que mais geram receita; Formas de pagamento mais utilizadas por clientes e regiões; Média de tempo em que as contas são pagas; A evolução e comparação dos resultados de faturamento por filiais; A evolução e comparação dos resultados de faturamento por bairros ou cidades. Na maioria dos casos as empresas utilizam como ferramenta de suporte à tomada de decisão os sistemas transacionais, mesmo estes tendo como foco o controle das transações operacionais que ocorrem no âmbito empresarial. Operacionalmente o uso desses sistemas representa agilidade e comodidade, mas restringir-se à utilização desse tipo de ferramenta para a tomada de decisão no nível gerencial pode representar grandes deficiências. Segundo Kimball (2002), os sistemas transacionais são extremamente limitados nas suas consultas por informação. Como justificativa, os autores afirma que esses sistemas buscam em suas bases de dados registro individuais para chegar a um resultado, o que pode causar lentidão e até mesmo indisponibilidade temporária de acesso aos dados por parte dos sistemas que atuam no ambiente de produção; esses por sua vez, devem ser ágeis e estar disponíveis quando necessário para que as tarefas primordiais da empresa não parem de ser executadas. Para Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 164 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre solucionar essa problemática propõem-se um ambiente gerencial externo ao ambiente de produção que permita a realização de consultas fáceis, rápidas, seguras e flexíveis. Neste sentido, os sistemas de apoio à decisão (SAD), que são software interligáveis ao BI, ajudam os gestores no processo decisório. Entende-se por BI qualquer ferramenta informatizada utilizada pelos administradores para extrair informações importantes sobre o negócio (BAZERMAN, 2004). Nesse contexto, este trabalho propõe uma solução de BI para uma empresa varejista de pequeno porte com utilização de software livre. Vale ressaltar que, embora o software livre não necessariamente implique em software gratuito, seus custos são inferiores ao dos software proprietário. A solução proposta é um data mart, que deverá possibilitar uma variedade de consultas/análises através das ferramentas de on-line analytical processing, dashboards e relatórios ad-hoc. Para validação do data mart foi realizado um estudo de caso em uma empresa do ramo varejista, que utiliza para controle de suas transações um software do tipo Commercial Off-The-Shelf (COTS). REVISÃO TEÓRICA Sistemas Transacionais Os sistemas transacionais, que se posicionam como on-line transaction processing (OTLP), podem ser vistos como ferramentas indispensáveis para o crescimento das organizações. Essas ferramentas otimizam o controle, a performance e a eficiência com que os dados transacionais são armazenados e recuperados. Esses sistemas englobam amplo contexto e estão presentes em diversos tipos de organizações, com particularidades distintas em seus processos de negócio. Segundo Palmisano e Rosini (2003), esses sistemas devem atender às necessidades do nível operacional. Já Meireles (2001) afirma que as empresas necessitam dessas ferramentas em todos os níveis da organização, com propósitos diferentes. Na prática, esses sistemas visam controlar todos os departamentos da organização que necessitam automatizar seus processos. A construção desses sistemas pode ser justificada quando há processos de negócio que necessitam trabalhar com um grande volume de transações e quando essas são repetitivas (MEIRELES, 2001). Em empresas de varejo essas ferramentas aperfeiçoam as vendas através da automação de processos, otimizam o controle de estoque através da integração de todos os sistemas, e otimizam também o controle de contas a receber e a pagar a curto, médio e longo prazo. Em muitos casos, o sistema transacional poderá representar o requisito principal para funcionamento da organização. A indisponibilidade de ferramentas deste naipe poderá afetar diretamente no oferecimento dos produtos e serviços da organização. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 165 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. Assim como os sistemas transacionais são voltados para controle de transações, os repositórios de dados transacionais também refletem o mesmo objetivo. Como característica, os bancos de dados transacionais possuem estruturas fortemente normalizadas, visando otimizar o processamento dos dados. Segundo Turban e colegas (2004), a normalização tem como objetivo eliminar redundância proveniente de campos repetitivos dentro de um arquivo, otimizar o processo de manutenção e recuperação de dados e evitar erros provenientes de inclusão, remoção ou alteração de registros. Sistemas de apoio à decisão Os sistemas de apoio à decisão (SAD), também conhecidos como sistemas de suporte à decisão (SSD), visam oferecer recursos capazes de tornar o processo decisório das organizações rápido, fácil e seguro. Os sistemas de apoio à decisão são ambientes computacionais interativos que ajudam os usuários no processo decisório (DRUZDZEL; FLYNN, 2002). Com uma definição bastante parecida, Turban (1995) já afirmava que, além desses sistemas serem interativos, como dito anteriormente, também são adaptáveis e flexíveis. Os SAD são de uso analítico e podem ser utilizados em todos os níveis da organização, do estratégico ao operacional. Embora algumas organizações invistam no uso dessas ferramentas em níveis operacionais, esse por sua vez, ainda é pouco explorado. Para Druzdzel e Flynn (2002), os esforços na construção dessas soluções são normalmente voltados para os níveis estratégico e tático. Em geral, os SAD buscam responder perguntas de usuários, encontrar padrões, tendências e até mesmo realizar previsões com base em dados históricos, provenientes de diversas fontes, internas ou externas à organização. Data Warehouse e Data mart Data warehouse (DW) é um repositório que armazena dados históricos de toda a organização, de forma integrada e consolidada. Segundo Inmon (1997), o DW deve ser: orientado por assunto, integrado, variante no tempo e não volátil. Os dados a serem carregados no DW podem ser originados de fontes de dados distintas e possuir diferentes tipos. Para isso, os dados devem ser integrados e transformados antes de serem carregados. Diferentemente dos bancos de dados transacionais que permitem que usuários possam ler, escrever e alterar registros, no DW os usuários terão acesso restrito, podendo apenas ler os dados, devido a não volatilidade do mesmo. Além disso, os usuários de DW possuem necessidades diferentes dos usuários do banco de dados transacional, tanto que não se atêm À análise de itens de linha, ou seja, registros individuais, interessando-se somente por dados sumarizados. Segundo Kimball (2002), esses usuários costumam realizar consultas que englobam centenas e até mesmo milhares de linhas. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 166 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre Os data marts (DM), também conhecido como fragmento de DW, são estruturas de armazenamento de dados que visam servir a interesses específicos dos usuários. Segundo Barbieri (2001), essas estruturas representam depósitos de dados departamentais e devem atender áreas específicas da empresa. Numa organização poderão existir vários data marts, e cada um deles poderá atender departamentos específicos da organização, como marketing, finanças e recursos humanos. Os data mart são os repositórios de dados que serão utilizados pelos usuários finais. Esses repositórios devem possibilitar consultas fáceis e rápidas. Processo para construção de DW O processo para construção de DW envolve diversas etapas, dentre as principais, podemse citar: planejamento, levantamento das necessidades, modelagem, projeto físico e o processo de extração, transformação e carga. A etapa de planejamento descreve o roteiro do projeto, assim como as etapas subsequentes à mesma. Mais precisamente é nessa etapa que são definidos os patrocinadores do projeto, a justificativa do projeto e a metodologia. A fase de levantamento das necessidades faz uma análise de todos os níveis da organização, com o objetivo de identificar informações gerenciais. Segundo Kimball (2002), uma das principais técnicas para reunir requisitos é a entrevista, pois permite encontrar detalhes precisos sobre questões de negócio. A modelagem do DW é uma etapa de extrema importância e é implementada por alternativas como star schema e snow flake. A implementação star schema é uma estrutura de armazenamento de dados dimensional, composta por dois tipos de tabelas: de fatos e de dimensão. As tabelas de dimensão guardam dados qualitativos e as tabelas de fatos guardam dados quantitativos. Através das tabelas de dimensão é possível filtrar os resultados dos valores contidos nas tabelas de fatos. Os projetos de data mart que utilizam a técnica de modelagem em star schema não respeitam critérios de normalização nas tabelas de dimensão e possuem grande volume de dados redundantes nas mesmas, consumindo maior espaço de armazenamento que os projetos normalizados. Por outro lado, essa estrutura possibilita consultas rápidas e fáceis. Segundo Corey (2001), para alcançar os melhores índices de performance nas consultas deve-se limitar a quantidade de junções entre tabelas. Com relação às tabelas de dimensão, estas guardam poucos registros em relação à tabela de fatos, e sua normalização poderia produzir pouco ou até mesmo nenhum impacto no tamanho total do banco de dados (KIMBALL, 2002). A figura 1 mostra um exemplo de um data mart projetado em star schema. A tabela principal desse modelo é a tabela de fatos (vendas), que está no centro do modelo, e as tabelas localizadas nas extremidades (cliente, fornecedor, tempo, geografia e produto) são conhecidas como tabelas de dimensões. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 167 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. Figura 1: Modelo dimensional projetado em star schema. Fonte: Adaptado de JOHNSON (2007). A técnica de modelagem snow flake diferencia-se da técnica star schema por possuir tabelas de dimensão normalizadas. A utilização desse modelo gera consultas complexas e demoradas, pois envolve grande quantidade de junções entre tabelas. A figura 2 mostra um modelo dimensional projetado em snow flake. Caso o usuário final necessite gerar um relatório simples, que mostre as vendas de um produto por região em um determinado mês, serão necessárias seis junções entre tabelas ([região, cidade], [cidade, loja], [loja, vendas-diaria], [mes, periodo], [periodo, vendas-diaria], [produto, vendas-diaria]). Se o mesmo relatório fosse gerado a partir de um modelo star schema o número de junções seria três, mais simples e rápido. Figura 2: Modelo dimensional projetado em SnowFlake. Fonte: Adaptado de IBM (2010). Após a etapa de modelagem ter sido concluída, é possível iniciar a fase de projeto físico, que irá construir o depósito de dados que foi projetado na etapa de modelagem dimensional, com suas respectivas tabelas dimensão, tabelas fato, chaves artificiais, índices e as restrições de campos. A fase subsequente à etapa de projeto físico é a de extract, transform e load (ETL), que visa extrair dados dos repositórios de origem, transformá-los e carregá-los no DW. O processo de extração visa coletar dados de diferentes fontes e tipos de arquivos e transportá-los para a área de transformação dos dados. Aetapa de desenvolvimento de aplicações envolve os ambientes de consulta online analytical processing (OLAP), que são projetados para tornar o acesso aos dados mais simples, Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 168 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre rápido e dinâmico. Com essa ferramenta os usuários finais podem criar facilmente suas próprias consultas, sem a necessidade de um técnico ou de um analista de sistemas. Segundo Primak (2008), antes do surgimento do OLAP e do DW os usuários usavam ferramentas menos amigáveis e precisavam localizar os dados espalhados em diversos arquivos dentro da organização. METODOLOGIA A estratégia adotada para o desenvolvimento deste trabalho envolve as principais etapas do modelo proposto por Kimball (2002). A escolha desse modelo é justificada por esse ser completo, detalhado, visar à criação de incrementos, como os data mart, e possibilitar a interação do usuário final com o ambiente de negócio em um curto espaço de tempo. Figura 3: Modelo do processo de construção de DW proposto por Kimball. Fonte: Kimball (2002, p.35). O modelo completo envolve doze etapas, como apresentado na figura 3. Para esse projeto foram realizadas dez etapas: planejamento do projeto, definição de requisitos do negócio, projeto de arquitetura técnica, seleção e instalação de produtos, modelagem dimensional, projeto físico, projeto de desenvolvimento da organização dos dados, especificação de aplicações do usuário final, desenvolvimento de aplicações do usuário final e disponibilização do DW. Quadro 1: Etapas da metodologia da presente pesquisa. ETAPA Planejamento Definição dos requisitos do negócio Projeto da arquitetura técnica Seleção e instalação de produtos Modelagem dimensional Projeto físico Projeto de desenvolvimento da DESCRIÇÃO Teve como intuito identificar o patrocinador do projeto, a justificativa e a definição da metodologia. Concentrou-se na elaboração do entendimento das necessidades do negócio, nas técnicas a serem aplicadas para extrair o maior número de informações possível e nos meios de aplicação dessas técnicas. Definiu o modelo de arquitetura física do DW, ou seja, a forma com que cada componente envolvido no projeto seria estruturado. Levantou e preparou todas as ferramentas tecnológicas necessárias para realização do projeto Objetivou a elaboração do modelo projeto do DW, que serviria de base de sustentação para a etapa de projeto físico. Ficou encarregado de transformar o que seria um modelo de projeto, em um banco de dados físico. Fez todos os ajustes necessários, para que o DW não carregasse dados redundantes Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 169 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. organização dos dados Especificação de aplicações do usuário final Desenvolvimento de aplicações do usuário final ou errôneos. Levantou as necessidades iniciais de informações dos gestores. Responsável por transformar as necessidades iniciais e futuras de informações gerências, em relatórios e indicadores concretos. Como esse é o primeiro incremento de uma série de data marts, as etapas de gerenciamento do projeto e de manutenção e crescimento não foram abordadas. As demais etapas são explicadas nas seções a seguir. RESULTADOS Planejamento Como a empresa em questão é de pequeno porte, o patrocinador do projeto foi o proprietário da mesma. Por esse projeto não possuir fins econômicos, mas sim acadêmicos, para essa atividade o papel do patrocinador foi o de permitir a realização do projeto, disponibilizando-se a participar em todas as etapas do processo de construção do data mart. Segundo o proprietário, as únicas ferramentas disponíveis no apoio ao processo decisório eram os relatórios pré-montados e parametrizados, disponíveis no sistema transacional. Além de haver um número relativamente pequeno de relatórios, esses eram bastante limitados, ofereciam poucas opções para filtros e eram ineficientes no quesito disponibilização de acesso aos dados pela Web, ou seja, os dados poderiam ser consultados apenas dentro da empresa. Outro fator que influenciou na aprovação desse projeto foi o fato de esses relatórios não operarem com dados históricos, pois, para atingir melhor performance nas transações realizadas pelo ambiente de produção, os dados antigos eram eliminados e enviados para arquivos de backup. Os dados antigos também deveriam ser levados em consideração no processo de análise. Definição dos Requisitos do Negócio As atividades envolvidas nessa etapa englobaram elaboração de questionários, documentação e definição de prioridades. Para definição dos requisitos, quatro tipos de questionário foram elaborados: analítico, organizacional, infraestrutura e avançado. As questões trabalhadas nesse instrumento serviram de tópicos para aquisição de conhecimento sobre o negócio. O questionário analítico teve como objetivo identificar os mecanismos de consulta utilizados pelos gestores da empresa no processo decisório. Após a realização desse questionário foi possível identificar que a empresa utiliza como ferramenta de apoio no processo decisório relatórios pré-montados e parametrizados e que os relatórios disponíveis no sistema são categorizados em três tipos: financeiro, vendas e estoque. Apesar disso, foi constatado que os Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 170 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre relatórios gerados pelo sistema transacional possuem limitações nas opções de filtros, suas visualizações são estáticas, não são flexíveis e não possibilitam a geração de gráficos. O questionário organizacional teve como objetivo identificar os processos de negócio da empresa, entender quais desses eram controlados pelos sistemas transacionais e definir as prioridades da empresa no processo de construção do DW. Por meio desse, foi possível identificar os seguintes processos de negócio: processo de compra e venda de produtos, processos de faturamento, contas a receber e a pagar, processos de emissão de notas fiscais, processos de transferências de produtos entre filiais e processos de manutenção, troca e devolução de produtos. Além disso, esse questionário permitiu identificar também que apenas o processo de manutenção não era controlado pelo sistema de informação. O processo de negócio identificado como de prioridade foi o processo financeiro de faturamento. O questionário de infraestrutura permitiu identificar que, ao longo do tempo, mudanças ocorreram nos sistemas transacionais e consequentemente os bancos de dados também sofreram alterações. No período de realização desse projeto, o sistema transacional utilizado pela empresa era o Connect Story v3.8.1, e a empresa fornecedora do software é a ACSN. Esse sistema possui dois módulos distintos, um para loja e outro para central. O módulo loja é utilizado em todas as filiais do grupo, inclusive na loja sede da empresa, e o módulo central é utilizado apenas na sede. Cada filial possui um banco de dados interno e independente, e os dados correspondentes às transações ocorridas nessas filiais são enviados para o banco de dados do módulo central periodicamente. É do banco de dados central que serão extraídos os dados que alimentarão o DW. O questionário avançado foi elaborado com o intuito de coletar informações técnicas sobre as fontes de dados. Através da aplicação desse questionário, foi possível entender a dimensão do problema, pois, não se tratava de um projeto comum de DW, pois apesar do banco de dados está acessível, a empresa não possuía domínio sobre o mesmo, não entendia como as tabelas desse banco se relacionavam muito menos o que elas armazenavam, tornando-se necessário a realização de um processo de engenharia reversa do banco e criação de um dicionário de dados. Projeto da Arquitetura Técnica Para essa etapa, foi necessário entender o modo de funcionamento do sistema transacional, identificar os pontos de localização dos dados e criar uma arquitetura para o DW. Como o patrocinador foi o único envolvido no processo de levantamento de requisitos e por ele não possuir muito tempo disponível para auxiliar no entendimento do sistema, foi necessário instalar e configurar o software utilizado pela empresa num computador dedicado à pesquisa. Através do site do fornecedor do software foi possível fazer o download da ferramenta disponível para teste. A única limitação do software de teste para o software comercial é que o primeiro poderia realizar até no máximo cinquenta transações, tornando-se aplicável para o propósito de P á g i n a | 171 Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. entendimento. Com o sistema instalado e configurado foi possível validar todas as informações passadas pelo patrocinador e entender mais a fundo os recursos disponíveis nesse software. Com isso foi possível identificar o principal ponto de extração de dados. Apesar de a empresa possuir filiais em outras cidades, periodicamente os bancos de dados dessas filiais eram sincronizados com o banco de dados Central. O banco de dados Central possuía dados de todas as unidades de lojas, o que facilitou o processo de extração de dados, pois os dados foram extraídos de um único local. Para criar uma arquitetura sólida para o DW, o patrocinador do reservou uma máquina exclusiva para o projeto. Como ilustrado na figura 4, o DW possui duas camadas, a primeira representa o banco de dados transacional e as ferramentas de ETC; a segunda camada é representada pelo DW e pelas aplicações analíticas utilizadas pelos usuários finais. Figura 4: Arquitetura de DW em duas camadas. Seleção e Instalação de Produtos Para essa etapa foi feita a seleção das ferramentas necessárias para realização do projeto, tais como ferramentas para descaracterização de dados, ferramentas para engenharia reversa, ferramentas para modelagem dimensional e suites de BI. Como esse projeto visa propor um data mart com uso de software livre, nenhuma ferramenta proprietária foi selecionada. A tarefa de descaracterizar dados teve o intuito de inibir informações confidenciais, não permitindo o favorecimento de competidores externos. Assim, os dados trabalhados nesse projeto não possuem valores reais. Apesar da empresa se comprometer a realizar essa atividade, a mesma solicitou que fossem pesquisadas ferramentas para esse propósito. O único software livre encontrado para apoiar nessa tarefa de descaracterização dos dados foi o Generate Data. Apesar dessa ferramenta não possibilitar a criação de tabelas com integridade referencial, vários recursos importantes para esse trabalho foram disponibilizados pela mesma. Essa ferramenta possibilitou a geração de sequências numéricas e dados humanos, tais como, nome de pessoas, telefone/fax, data, e-mail, rua, cidade, estado e pais. Como a base de dados da empresa era em data base file (DBF), não foram encontradas ferramentas livres para realização da tarefa de engenharia reversa. Dessa forma, foi necessáriaa realização do processo de forma manual. Para modelagem do banco de dados dimensional, foi adotada a ferramenta DBDesign® Para esse projeto, a criação de diagramas de entidade e relacionamento era o único recurso que realmente interessava. Recursos como sincronização com banco de dados ou geração de scripts SQL não foram necessários para essa tarefa. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 172 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre Finalmente, ainda como requisito desse projeto, a suíte de BI deveria ser software livre e abordar todas as etapas do processo de construção de DW. Devido a esses requisitos, o Pentaho foi a única suite apta para o trabalho. Modelagem Dimensional Nessa etapa foi projetado o modelo do banco de dados dimensional. Para isso, foi necessário criar a matriz de barramento, realizar engenharia reversa do banco de dados, criar o modelo dimensional, elaborar o dicionário de dados e validar a etapa. A matriz de barramento tem o objetivo de identificar os possíveis data marts que irão compor o DW. Para elaboração da matriz foi necessário reunir as informações fornecidas pelo usuário final na entrevista do questionário organizacional, que definiu os seguintes processos de negócio: compra de produtos, venda de produtos, troca e devolução de produtos, transferência de produtos, faturamento, contas a receber e contas a pagar. As entidades relacionadas ao processo de negócio faturamento que caracterizaram as tabelas de dimensão foram: cliente, produto, fornecedor, funcionário, pagamentos, tempo, loja e conta. Em projetos de data mart, os processos de negócio representam tabelas de fatos e as entidades relacionadas a estes processos tornam-se tabelas de dimensões. A figura 5 apresenta a matriz de barramento da empresa. Cada linha da matriz representa um data mart. As células marcadas com “x” indicam uma relação entre tabelas de fatos e as dimensões. Figura 05: Matriz de barramento da empresa. A prioridade da empresa era o processo de negócio faturamento, do departamento financeiro, e a engenharia reversa deveria englobar todas as tabelas ligadas a esse setor. Como a base de dados da empresa não possuía compatibilidade com as ferramentas de engenharia reversa disponíveis, para realização desse processo foi necessário entendimento sobre a forma de armazenamento dos dados do sistema transacional. Com o sistema transacional instalado, foram executadas as operações utilizadas pela empresa, tais como realização compra e venda de produtos, cancelamento de vendas, dentre Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 173 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. outros. Essas operações serviram para entender como os dados eram armazenados no banco de dados. Após operações de vendas, foi constatado que as seguintes tabelas estavam relacionadas com o processo de negócio faturamento (parcelas, contas, subtip, tipcon, vendas, forcli e loja). Com relação à tabela parcelas, independente da venda ser parcelada ou não essa sempre será afetada. O número de registros que é inserido na mesma após cada operação de venda é idêntico à quantidade de parcelas optada pelo cliente, ou seja, caso uma venda seja parcelada em duas vezes, haverá dois registros desta na tabela parcelas, um para cada parcela. Foi constatado também que, para cada operação de venda, será sempre inserido um novo registro na tabela de contas. Diferentemente da tabela parcelas, que guarda registros de cada parcela, a tabela de contas guarda dados de vendas sumarizadas, ou seja, o total da soma das parcelas. Um registro armazenado na tabela contas possui relação com um ou mais registros da tabela parcelas. Outras constatações dessas operações foram: A tabela forcli armazena os clientes cadastrados na loja. Para cada registro dessa tabela, poderá haver um ou mais registros relacionados a essa, na tabela de contas; Para cada registro armazenado na tabela vendas, sempre haverá um registro relacionado a essa, na tabela de contas; Cada registro inserido na tabela loja possui relação com um ou mais registros na tabela de contas; Cada registro da tabela tipcon possui relação com um ou mais registros da tabela de subtip; As tabelas subtip e tipcon, unidas possuem relação com a tabela vendas. A partir dessas constatações, foi possível criar o modelo relacional do sistema transacional, apresentado na figura 6. Nesse modelo, a tabela forcli possui como chave primária o campo fccod. A tabela loja possui como chave a coluna icod. A chave da tabela parcelas é parctit. A tabela cfgpagto possui a chave primária codfpagto. A tabela contip possui dois campos chave, a coluna tcod e trop. A tabela subtip possui como campos chave, as colunas scod e sgru. Figura 06: Modelo relacional do banco de dados transacional da empresa. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 174 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre Para criar o modelo dimensional foi necessário definir o nível de granularidade, a estrutura e o esquema do banco de dados. Nesse projeto o nível granular escolhido foi parcelas, pois esse representava o menor nível de detalhe. A escolha do menor nível granular facilita o processo de integração dos dados e não impõe limites sobre as consultas que os usuários podem fazer. A partir do modelo do banco de dados transacional, foi desenhado o banco de dados dimensional (figura 7) do data mart de faturamento resumido. O modelo dimensional diferencia-se do modelo transacional, nos seguintes aspetos: A tabela dimensao_conta se formou a partir da junção das tabelas transacionais subtip, tipcon e contas; A tabela dimensao_pagamento se formou a partir da junção das tabelas transacionais parcelas e cfgpagto; A tabela dimensao_parcelas se formou a partir da junção das tabelas transacionais parcelas e contas; A tabela dimensao_loja se formou a partir da tabela transacional loja; A tabela dimensao_cliente se formou a partir da tabela transacional forcli; A tabela dimensao_tempo não surgiu do banco de dados transacional. Essa tabela foi gerada para apoiar o processo de análise dos dados históricos; A tabela fato_faturamento surgiu a partir da junção das tabelas transacionais parcelas e contas. Como as colunas das tabelas do repositório de dados transacional não possuíam nomes sugestíveis, foi necessário elaborar um dicionário de dados. O dicionário objetiva facilitar o processo de extração dos dados e melhorar a legibilidade do usuário final diante do data mart. Figura 07: Modelo dimensional resumido. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 175 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. Projeto de Desenvolvimento da Organização dos Dados e Projeto Físico Como o modelo dimensional foi projetado com sete tabelas (seis tabelas dimensão e uma tabela fato), para cada uma delas foi elaborado um plano de ETC. A figura 8 apresenta o plano de transformação da dimensão cliente: Através do step “forcli”, que utiliza o módulo de extração de dados “XBase Input”, é iniciado o processo de extração dos dados armazenados na tabela transacional forcli; O segundo step do plano é o “Selecionando e renomeando campos”, que utiliza o módulo “Selectvalues”. Através dele é feita uma seleção dos campos necessários para a dimensão cliente e renomeação dos mesmos de acordo com o dicionário de dados; O terceiro step do plano é o “Validando email e revendedor”, que utiliza o módulo JavaScript “Modified Java Script Value”. Nesse step foram feitas validações nos campos de e-mail e revendedor; O quarto step do plano é o “Validando categoria e tipo do cliente”, que utiliza o módulo JavaScript “Modified Java Script Value”. Nesse step foram feitas validações nos campos categoria e tipo de cliente; O quinto step do plano é o “Validando CPF e CNPJ”, que utiliza o módulo JavaScript “Modified Java Script Value”. Nesse step foram feitas validações nos campos de CPF e CNPJ; O sexto step do plano é o “validando telefone”, que utiliza o módulo JavaScript “Modified Java Script Value”. Nesse step foram feitas validações nos campos de telefone. O sétimo step do plano é o “Corrigindo nome de bairros e cidades”, que utiliza o módulo JavaScript “Modified Java Script Value”. Nesse step foram feitas correções nos valores de dados dos campos de cidade e estado. O oitavo step do plano é “Selecionando e renomeando campos 2”, que utiliza o módulo “Selectvalues”. Através dele foi feita uma seleção dos campos necessários para a dimensão cliente e renomeação dos mesmos de acordo com o dicionário de dados; O nono step do plano foi a “Dimensão cliente”, que utiliza o módulo “Dimension lookup/update”. Nesse step foram definidos, os campos que iriam para a tabela de dimensão_cliente do DW, as chaves artificiais e as configurações do versionamento de dados. Figura 08: Plano de transformação da dimensão cliente. O script de criação do projeto físico dessa dimensão foi gerado automaticamente no final do plano. Como apresentado na figura 9, além do script definir quais são as colunas que irão compor a tabela, ele também faz a indexação da mesma. Nesse script, as colunas indexadas foram: codigo_cliente e sk_cliente. O codigo_cliente é o identificador do registro na tabela transacional e o sk_cliente é a chave artificial. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 176 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre Figura 09: Script de criação do projeto físico da dimensão cliente. Especificação e Desenvolvimento de Aplicações do Usuário Final O processo de faturamento abrange as movimentações financeiras de contas recebidas pelo processo de vendas. Para que o faturamento possa ser analisado, é necessário que novas variáveis sejam incluídas no processo de consulta. Em se tratando de empresas varejistas, as novas variáveis poderão ser provenientes de informações sobre clientes, filiais, fornecedores e sobre formas de pagamento. A inclusão dessas variáveis irá detalhar o processo de faturamento, facilitando a identificação de informações estratégicas. No desenvolvimento dessas aplicações foi necessário criar e publicar o Cubo OLAP, criar Dashboards e relatórios ad-hoc. O Cubo OLAP equivale a um arquivo XML que é interpretado pelo Mondrian, servidor OLAP da SuitePentaho,e a construção desse cubo pode ser feita através de qualquer editor de texto. Para esse processo foi utilizada a ferramenta gráfica PentahoSchema Workbench. A figura 10 apresenta o schema do cubo faturamento, que é composto pelas dimensões loja, conta, pagamento, parcela, vencimento e cliente. Além disso, o cubo possui como métricas os campos Valor pago, Valor parcela e a métrica calculada diferença, que é a subtração do valor pago menos o valor da parcela. Figura 10: Schema do cubo faturamento. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 177 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. O banco de dados fornecido pela empresa limitou-se aos dados das atividades de janeiro a junho de 2011. Para o processo de análise das consultas solicitadas pelo usuário final foram também desenvolvidos dashboards e relatórios ad-hoc. A figura 11 apresenta o primeiro dashboard com dois painéis: no primeiro painel é apresentada a evolução do faturamento em dinheiro, segmentado por cidade, nos meses de janeiro a maio de 2011; o segundo painel mostra a evolução do faturamento segmentado por formas de pagamento, na matriz, nos meses de janeiro a maio de 2011; A figura 12 mostra os painéis do segundo dashboard. As consultas foram: evolução do faturamento, segmentado por cidade, nos meses de janeiro a maio de 2011, no painel à esquerda; e evolução do faturamento segmentado por formas de pagamento, na matriz e filial, nos meses de janeiro a maio de 2011 no painel à direita. Figura 11: Dashboard com gráficos de linha. Figura 12: Dashboard com gráficos de barra. A Figura 13 ilustra o terceiro dashboard com painéis de faturamento provenientes de pessoas física e jurídica, na matriz, nos meses de fevereiro e março de 2011, respectivamente. Figura 13: dashboard com gráficos de pizza. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 178 Proposta de Data Mart para análise de faturamento de empresa de varejo utilizando software livre Na Figura 14 é apresentado o quarto dashboard, com apenas um gráfico demonstrando a evolução do faturamento da loja matriz nos meses de janeiro a Junho de 2011, por bairro. Figura 14: Evolução de faturamento por bairro. A figura 15 apresenta um modelo de relatório ad-hoc que lista os dez clientes que mais favoreceram o faturamento da matriz, no mês de janeiro de 2011. Figura 15: Relatório ad-hoc com faturamento por clientes. Validação do Data Mart Para validar o data mart, o ambiente de BI foi implantado na empresa e um grupo de usuários testou as funcionalidades da ferramenta, analisou os relatórios pré-definidos, fez consultas OLAP e gerou relatórios ad-hoc. Conclui-se, através dessa etapa, que a ferramenta teve aplicabilidade imediata na empresa, sendo utilizada em ambientes de produção. Uma das consultas definidas como estratégicas pelo patrocinador do projeto foi o relatório de evolução do faturamento por bairro. Segundo o mesmo, através dessa informação é possível direcionar estratégias de marketing para o público-alvo correto. Outra vantagem seria o acompanhamento em tempo real do uso da estratégia, ou seja, se uma ação de marketing for direcionada para um determinado bairro, será possível acompanhar em tempo real o resultado da mesma. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 179 BATISTA, C. F. L.; SOUZA, E. P. R.; CORREIA NETO, J. S.; DORNELAS, J. S. CONCLUSÕES Diante da competitividade do mercado varejista, assim como a tendência de crescimento do mesmo, torna-se evidente a necessidade de tomar decisões baseadas em informações estratégicas. Conclui-se, que além da ferramenta possibilitar análises rápidas, flexíveis, fáceis e seguras, o data mart proposto também possibilitou encontrar informações oportunas. Mesmo com limitações, o data mart teve aplicabilidade imediata, servindo de instrumento no apoio ao planejamento estratégico da organização. Além disso, verificou-se que é totalmente viável, em termos financeiros, a implantação de técnicas e ferramentas de BI com a utilização de software livre, também em pequenas empresas. Como proposta para trabalhos futuros, pode ser sugerida a construção de outros data mart, como os de compras de produtos, vendas de produtos, troca e devolução de produtos, transferência de produtos, como também a criação de algoritmos de mineração de dados. Outra proposta seria a criação de um processo de desenvolvimento de DW para COTS, pois não foram encontrados registros na literatura sobre modelos de construção de DW nessas condições. REFERÊNCIAS COREY, M. J.. Oracle 8i Data Warehouse: Planeje e construa um data warehouse e uma solução de análise resistente. Rio de Janeiro: Campus, 2001. DRUZDZEL, M. J.; FLYNN, R. R.. Decision support systems: decision systems laboratory, school of information sciences and intelligent systems program. Pittsburgh: University of Pittsburgh, 2002. IBM. Informix warehouse accelerator: performance é tudo, 2010. Disponível: <http://www.iiug.org/library/warehouse/technical/InformixWarehouseAccelerator_Portuguese.pdf> Acesso: 07 Out 2011. IDV. Instituto para Desenvolvimento do Varejo. A maturidade do varejo brasileiro. 2009. Disponível: <http://www.idv.org.br/imprensa-artigo.aspx?IdArtigo=426>. Acesso: 08 Out 2011. INMON, W. H.. Building the data warehouse: getting started. 4 ed. New York: Wiley Publishing, 2005. INMON, W. H.. Como construir o data warehouse. 2 ed. Rio de Janeiro: Campus, 1997 JOHNSON, D. L. K.. Reporting with rational portfolio manager: version 7.1. 2007. Disponível: <http://www.ibm.com/developerworks/rational/library/07/0626_johnson/index.html> KIMBALL, R.. The data warehouse toolkit: guia completo para modelagem dimensional. Rio de Janeiro: Campus, 2002. MEIRELES, M.. Sistemas de informação: quesitos de excelência dos sistemas de informação. Arte & Ciência, 2001. PALMISANO, A.; ROSINI, A. M.. Administração de sistemas de informação e a gestão do conhecimento. Thomson Pioneira, 2003. SIQUEIRA, M. C.. Gestão estratégica da informação. Brasport, 2005. TURBAN, E.. Decision support systems and intelligent systems. 8 ed. Pearson Prentice Hall, 2007. Revista Brasileira de Administração Científica v.3 ‐ n.2 Agosto de 2012 P á g i n a | 180
