Faça do trabalho completo aqui.

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
BUSINESS INTELLIGENCE NA GESTÃO DE
ESTOQUES
FERNANDO FELIX DO NASCIMENTO JUNIOR
Orientadora: Ianna Maria Sodré Ferreira de Sousa
Campina Grande, junho de 2013
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
BUSINESS INTELLIGENCE NA GESTÃO DE
ESTOQUES
FERNANDO FELIX DO NASCIMENTO JUNIOR
Trabalho
de
conclusão
de
curso
a
ser
apresentado à Coordenação do Curso de
Telemática do IFPB - Campus Campina Grande,
como requisito parcial para conclusão do curso
de Tecnologia em Telemática.
Orientadora: Ianna Maria Sodré Ferreira Sousa
Campina Grande, junho de 2013
BUSINESS INTELLIGENCE NA GESTÃO DE
ESTOQUES
_______________________________
Fernando Felix do Nascimento Junior
Aluno
_____________________________
Ianna Maria Sodré Ferreira Sousa
Orientadora
_____________________________
Francisco Dantas Nobre Neto
Membro da Banca
_____________________________
Anderson Fabiano Batista Ferreira da Costa
Membro da Banca
Campina Grande, Paraíba, Brasil
Junho de 2013
A minha querida filha Rebeca Vitória,
Que faz meu coração transbordar de alegria.
"Não adianta olhar pro céu, com muita fé e pouca luta ..."
Gabriel Contino
Agradecimentos
Agradeço a Deus pela sua maravilhosa graça que sempre me faz seguir em frente.
A minha família que me apoiou.
A minha orientadora Ianna pelo acompanhamento pontual e competente.
A João Paulo, gerente de Tecnologia da Informação do Grupo Rio do Peixe, pela
oportunidade de conhecer e trabalhar com Business Intellingence.
Ao Grupo Rio do Peixe por ter fornecido a estrutura necessária para o desenvolvimento
deste trabalho.
Aos colegas de classe e de trabalho pelo companheirismo e amizade que tiveram comigo.
A todos que, direta ou indiretamente, contribuíram para a realização deste trabalho.
Resumo
Os sistemas de gestão empresarial coletam e armazenam uma enorme quantidade de
dados, dificultando que determinados gestores possam ter informações confiáveis e no tempo
certo. Por esse motivo, surgiram os sistemas de business intelligence (BI), que, quando
implementados com os corretos sistemas informatizados permite, de forma mais simples reunir,
organizar e armazenar, analisar e facilitar descoberta de relações em todos os dados corporativos
reunidos pela empresa ao longo de sua história. As informações provenientes desses sistemas
passam a apoiar a tomada de decisões, ou seja, indicar caminhos e mudanças benéficas a serem
seguidos, possibilitando que a empresa tenha vantagens competitivas. Portanto, neste trabalho, o
foco é na gestão de estoques utilizando o BI, no qual é apresentado uma solução utilizando
métodos quantitativos. Com essa solução, pretende-se que o processo de decisões estratégicas a
respeito de estoques, como “o que fornecer? em que quantidade? em que momento? e quando
repor?”, por parte dos gestores seja favorecida.
Palavras-chave: Business Intelligence, Gestão de estoques, Métodos Quantitativos
Abstract
The enterprise management system collect and store a huge amount of data, preventing
certain managers have reliable information at the right time. For this reason, there are business
intelligence (BI) systems, which, when implemented with the correct computer systems is
simpler to gather, organize and store, analyze and facilitate discovery of relations in all corporate
data gathered by the company over its history. The information from these systems begin to
support decision making, ie, indicate paths and beneficial changes to follow, enabling
competitive advantages. Therefore, in this work, the focus is on inventory management using the
BI, in which a solution is presented using quantitative methods. With that solution, it is intended
the strategic decisions process about inventory, such as "what we provide? in what quantity? at
what time? and when reset?", by managers to be favored.
Keywords: Business Intelligence, Inventory Management, Quantitative Methods
Sumário
1 Introdução.....................................................................................................................................1
1.1 Objetivos............................................................................................................................... 3
1.1.1 Objetivo Geral................................................................................................................3
1.1.2 Objetivos Específicos.................................................................................................... 3
1.2 Delimitação do Estudo.......................................................................................................... 3
1.3 Metodologia.......................................................................................................................... 5
1.4 Organização do trabalho....................................................................................................... 5
2 Fundamentação Teórica................................................................................................................7
2.1 Business Intelligence.............................................................................................................7
2.1.1 Data Warehouse (DW)................................................................................................... 9
2.1.2 Extract, Transform and Load (ETL)............................................................................ 11
2.1.3 On Line Analytical Processing (OLAP)...................................................................... 12
2.1.4 Data Mining.................................................................................................................15
2.2 Pentaho................................................................................................................................16
2.2.1 Plataforma de Business Intelligence............................................................................17
2.2.2 Integração de Dados e Aplicações ............................................................................. 17
2.2.3 Pentaho Analysis (Mondrian)..................................................................................... 22
2.2.4 Pentaho Reporting.......................................................................................................22
2.2.5 Pentaho Data Mining (Weka)......................................................................................23
2.3 Gestão de Estoques............................................................................................................. 23
2.3.1 Métodos Quantitativos................................................................................................ 26
3 Estudo de Caso........................................................................................................................... 33
3.1 A Empresa...........................................................................................................................33
3.2 Sistemas de Gestão Empresarial......................................................................................... 33
3.3 Departamento de Tecnologia da Informação (TI) ..............................................................33
3.4 Solução Business Intelligence ........................................................................................... 34
3.4.1 Criação do Data Warehouse ....................................................................................... 36
3.4.2 Criação de processos ETL com o Kettle..................................................................... 40
3.4.3 Criação dos cubos OLAP............................................................................................40
3.4.4 Criação das consultas MDX........................................................................................40
3.4.5 Criação das apresentações...........................................................................................41
3.4.6 Difusão das informações............................................................................................. 41
4 Conclusão................................................................................................................................... 42
Referências.................................................................................................................................... 43
Anexo 1: Processos ETL................................................................................................................47
Tempo........................................................................................................................................47
Fornecedor................................................................................................................................ 48
Cliente.......................................................................................................................................49
Vendedor................................................................................................................................... 49
Produto......................................................................................................................................49
Status.........................................................................................................................................50
Filial.......................................................................................................................................... 50
Pedidos......................................................................................................................................50
Histórico de Produtos................................................................................................................51
Perdas por Falta de Produtos.....................................................................................................51
Anexo 2: Exemplos de análises OLAP..........................................................................................52
Perdas por falta de produtos em 2011, todos os meses..............................................................52
Perdas por falta de produtos em 2011, TOP 10......................................................................... 53
Anexo 3: Exemplo de Relatório Criado.........................................................................................55
Anexo 4: Jobs.................................................................................................................................57
Anexo 5: Organização das Ferramentas........................................................................................ 59
Lista de Figuras
Figura 1: Estrutura analítica............................................................................................................ 5
Figura 2: Sistema de business intelligence, adaptado de Fortulan & Filho (2005)......................... 9
Figura 3: Modelagem dimensional de banco de dados utilizando o modelo estrela (autor).........11
Figura 4: Pilha de componentes Pentaho (BOUGMAN; DONGEN, 2009)..................................17
Figura 5: Ferramentas e componentes do Pentaho Data Integration (BOUGMAN & DONGEN,
2009) ............................................................................................................................................. 19
Figura 6: Steps, hops, e fluxo de registros (BOUGMAN & DONGEN, 2009) ............................21
Figura 7: O efeito da maximização em um dos objetivos da gestão de estoques (GIANESI &
BIAZZI, 2011)............................................................................................................................... 24
Figura 8: Exemplo de calculo da tendência...................................................................................27
Figura 9: Espiral do conhecimento e modelo espiral de desenvolvimento de software
(MATHEUS & PARREIRAS 2004)............................................................................................. 34
Figura 10: Data Mart Bus, adaptado de Watson & Ariyachandra (2005)..................................... 36
Figura 11: Data marts para apoiar o processo de gestão de estoques (autor)................................ 37
Figura 12: Transformação que povoa a tabela Tempo................................................................... 48
Figura 13: Transformação que povoa a tabela Fornecedor............................................................ 48
Figura 14: Transformação que povoa a tabela Cliente...................................................................49
Figura 15: Transformação que povoa a tabela Vendedor...............................................................49
Figura 16: Transformação que povoa a tabela Produto..................................................................50
Figura 17: Transformação que povoa a tabela Status.....................................................................50
Figura 18: Transformação que povoa a tabela Filial...................................................................... 50
Figura 19: Transformação que povoa a tabela Pedidos.................................................................. 51
Figura 20: Transformação que povoa a tabela Histórico de Produtos........................................... 51
Figura 21: Transformação que povoa tabela Perdas Por Falta de Produtos................................... 51
Figura 22: Gráfico de barra vertical de todos os meses de 2011................................................... 53
Figura 23: Gráfico de pizza dos produtos, TOP 10....................................................................... 54
Figura 24: Relatório de produtos vendidos, utilizando MDX + PRD............................................56
Figura 25: Trabalho para a povoação das tabelas dimensões........................................................ 57
Figura 26: Trabalho para povoação das tabelas fatos.................................................................... 57
Figura 27: Trabalho para automatizar a geração e envio de relatórios.......................................... 58
1
1 Introdução
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 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
avaliação de estoques. No entanto, tem sido raro encontrar empresas brasileiras utilizando
métodos quantitativos para apoiar tais decisões; ao contrário, é comum o uso de métodos
empíricos, qualitativos e baseados em intuição (GIANESI & BIAZZI, 2011).
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 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.
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
2
item, 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 aplicados
com facilidade e agilidade. Para sanar esses tipos de necessidades, surgiu o business intelligence
(BI), que pode ser definido como:
Área de estudo interdisciplinar, ligada à tecnologia da informação, que tem como
objeto de estudo a elaboração de sistemas de informação computacionais (soluções)
responsáveis por organizar grandes volumes de dados (data warehouse), analisar
(on-line 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 de prover informações confiáveis, no momento certo,
para a tomada de decisão (MATHEUS & PARREIRAS, 2004; GOUVEIA, 2009;
CAPUANO et al., 2009; BISPO, 1998).
Portanto, uma solução BI pode permitir o acesso a informações de maneira rápida e
segura, com possibilidades de integrações e escalabilidade que permitam aos gestores
visualizarem a informação sob diferentes óticas, para que consigam, de uma forma eficiente e
eficaz, controlar, avaliar, mensurar, simular e abrir novos caminhos para a gestão de estoques.
3
1.1 Objetivos
1.1.1 Objetivo Geral
Desenvolver uma solução de business intelligence para favorecer o processo de tomada de
decisões estratégicas relacionadas à gestão de estoques utilizando métodos quantitativos.
1.1.2 Objetivos Específicos

Estudo do BI e conceitos relacionados;

Estudo da suíte BI Pentaho: arquitetura e principais componentes;

Estudo do conceito de gestão de estoques;

Estudo de métodos quantitativos para gestão de estoques, com foco na previsão da
demanda;
1.2 Delimitação do Estudo
A logística exerce a função de responder pela movimentação de materiais (produtos), no
ambiente interno e externo da empresa, desde a chegada da matéria-prima (no caso de fábricas)
até à entrega do produto final ao cliente (ALMEIDA, 2006). Suas atividades podem ser
distribuídas conforme a Tabela 1.
4
Atividades primárias
Essenciais ao cumprimento da função logística, contribuem com
o maior montante do custo total da logística.
Transportes
Refere-se aos meios utilizados para movimentar os produtos até
os clientes: que podem ser via rodoviária, ferroviária, aeroviária e
marítima. O gerenciamento desta atividade é de grande
importância, em virtude do peso desse custo em relação ao total
do custo da logística.
Gestão de estoques
Dependendo do setor em que a empresa atua e da sazonalidade, é
necessário um nível mínimo de estoque que aja como
amortecedor entre oferta e demanda.
Processamento de pedidos
Determina o tempo necessário para a entrega de bens e serviços
aos clientes.
Atividades secundárias
Exercem a função de apoio às atividades primárias na obtenção
de níveis de bens e serviços requisitados pelos clientes, a saber:
armazenagem, manuseio de materiais, embalagem de proteção,
programação de produtos.
Tabela 1: Atividades da logística
O desenvolvimento da solução, que se dá no Grupo Rio do Peixe, foca na gestão de
estoques, mais especificamente em seus métodos quantitativos, excluindo as demais atividades e
áreas da empresa.
É importante ressaltar que o estudo limitou-se à análise de estoques de produtos
acabados, não envolvendo definições para matérias-primas e produtos em processos, já que a
especialidade da empresa é apenas de distribuição.
Software livre, ou free software, conforme a definição criada pela Free Software
Foundation, é o software que pode ser usado, copiado, estudado, modificado e redistribuído sem
restrição (FREE SOFTWARE FOUNDATION, 2012). Por ser software livre, e uma das que mais
se destaca, será estudado e utilizado a suíte Pentaho para desenvolver a solução, que reúne uma
coleção de programas computacionais que trabalham juntos para criar e entregar soluções
business intelligence completas (BOUGMAN & DONGEN, 2009).
5
1.3 Metodologia
O trabalho terá a estrutura analítica conforme a Figura 1. A Tabela 2 descreve cada uma
das fases da metodologia.
Figura 1: Estrutura analítica
Levantamento bibliográfico
Levantamento bibliográfico sobre os conceitos relacionados ao
tema e sobre a suíte de business intelligence Pentaho.
Definição do cenário
Apresentação do cenário do estudo de caso, identificando a
empresa e o(s) problema(s) que são acarretados pela gestão
inadequada de estoques.
Desenvolvimento da solução
Implementação da solução conforme o cenário/problema do
estudo de caso, aplicando os métodos quantitativos de gestão de
estoque.
Elaboração do relatório
Escrita do documento final, apresentando o desenvolvimento da
proposta.
Tabela 2: Descrição das fases.
1.4 Organização do trabalho
Para desenvolvimento do tema, o trabalho obedecerá a uma sequência normal, com cinco
capítulos apresentando as seguintes características, respectivamente: o capítulo 1 visa criar um
6
suporte e interligação entre a fundamentação teórica e o estudo de caso, consiste da motivação e
contextualização do estudo, seus objetivos, delimitações e metodologia empregada; o capítulo 2
Faz o elo principal e a base para o estudo de caso, consiste da fundamentação teórica sobre
business intelligence, arquitetura e principais componentes do Pentaho, gestão de estoque e seus
métodos quantitativos, consiste também da identificação dos problemas que podem ser
acarretados pela gestão inadequada dos estoques; o capítulo 3 apresenta o estudo de caso em si.
Consiste da identificação da empresa onde foi realizado o estudo e da solução proposta com suas
características; o capítulo 4 consiste das considerações finais e das sugestões para futuros
estudos sobre assuntos similares ao tema.
7
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 3.000 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 2.500 anos já enfatizavam a importância da
inteligência e o valor da informação (CAPUANO et 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, 2001, p. 40, 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 análise do ambiente
de informações interno, e o conhecimento do inimigo (concorrentes) seria a monitoração e
análise 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.
8
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ó. 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 pode ser empregado 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.
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: Extração Trasnformação e Carga (em inglês Extract Transform and
Load - ETL), Data Warehouse (DW), On-line Analytical Processing (OLAP) e data mining. A
Figura 2 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 de extração transformação e carga (do inglês Extract Transform and Load - ETL),
podem-se aplicar ferramentas OLAP e data mining para a obtenção de informações e, assim, ter
o ambiente de BI.
9
Figura 2: Sistema de business intelligence, adaptado de Fortulan & Filho (2005)
2.1.1 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 do DW, 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).
10
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
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 3 ilustra o
diagrama desse modelo: a tabela de fatos conecta-se às demais por múltiplas chaves primárias e
as tabelas dimensões se conectam com apenas uma chave primária à tabela de fatos; essa tabela
armazena grande quantidade de dados históricos, em função do tempo, obtidos a partir da
11
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 3: Modelagem dimensional de banco de dados utilizando o modelo estrela
(autor)
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).
2.1.2 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;
12

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.
2.1.3 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
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 análises 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.
13
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.
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.
14
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;
 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
15
2.1.4 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 é 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 à 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.
16
2.2 Pentaho
O Pentaho Community1 (ou apenas Pentaho), é uma das suítes de software livre de BI que
mais se destaca. Ele reúne uma coleção de programas computacionais que trabalham juntas 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/integradas em qualquer
aplicação Web.
Todos os componentes são baseados em programas Java. Alguns desses 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 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 georreferenciamento, 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 4 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, em que a
plataforma de business intelligence (BI platform), por si só, fornece estruturas básicas para
segurança e administração. A camada de integração 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.
componentes do Pentaho.
1 Pentaho Community <http://community.pentaho.com/>
A seguir são apresentados os principais
17
Figura 4: Pilha de componentes Pentaho (BOUGMAN; DONGEN, 2009)
2.2.1 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).
2.2.2 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 de integração,
18
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
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 5 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.
19
Figura 5: Ferramentas e componentes do Pentaho Data Integration (BOUGMAN &
DONGEN, 2009)
Ferramentas e Utilidades

Spoon – Ambiente de desenvolvimento gráfico para criar transformações e trabalhos;

Kitchen – Ferramenta não gráfica para executar trabalhos através de terminais/consoles
de comando;
20

Pan – Ferramenta não gráfica pra executar transformações através de terminais/consoles
de comando;

Carte – Servidor para executar trabalhos e transformações em um host remoto.
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
21
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 propósito de extrair,
transformar e carregar dados.
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 uma 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).
Figura 6: Steps, hops, e fluxo de registros (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
22
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 6.
Trabalhos
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 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.
2.2.3 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.
2.2.4 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,
23
a API e pontos de extensão garantem que esse sistema possa crescer conforme os requerimentos
do usuário (PENTAHO CORPORATION, 2011).
2.2.5 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 negócio, e também ser
explorados para melhorar a performance, futura, através de análises de predições (PENTAHO
CORPORATION, 2011).
2.3 Gestão de Estoques
Os investimentos não são dirigidos por uma organização somente para aplicações diretas
que produzam lucros. Outros tipos de investimentos, aparentemente, não produzem lucros. Entre
estes estão as inversões de capital destinadas a cobrir fatores de risco em circunstâncias
imprevisíveis e de solução imediata. É o caso dos investimentos em estoque, que evitam que se
perca dinheiro em situação potencial de risco presente (MARTINS, 2012).
Brito (2010, apud BALLOU, 2006) assinala que se a demanda for previsível não é
necessário manter estoques, isto é, quanto mais precisa for a previsão de demanda, mais simples
de controlar os estoques. No entanto, como praticamente não existe previsão de demanda exata,
as empresas utilizam estoques para reduzir os efeitos causados pelas variações de oferta e
procura.
Segundo Vaz & Gomes (2011, apud BALLOU, 1993), os estoques possuem uma série de
objetivos, que são: melhorar o nível de serviço; incentivar economias na produção; permitir
economia de escala nas compras e no transporte; agir como proteção contra aumentos de preços;
proteger a empresa de incertezas na demanda e no tempo de ressuprimento; servir como
segurança contra contingências.
24
As empresas tem como meta principal maximizar seus lucros sobre o capital investido,
sendo assim busca pelo estoque ideal é imprescindível (VAZ & GOMES, 2011, apud DIAS,
1993). A gestão de estoques tem como objetivo tornar viável aos empresários o armazenamento
das mercadorias sem causar grandes investimentos desnecessários, ou seja, a empresa vai estocar
somente os materiais que realmente forem necessários, evitando assim, o custo desnecessário de
estoque.
Para Gianesi & Biazzi (2011), os objetivos principais para a gestão de estoques são:

Maximizar o nível de serviço ou maximizar atendimento da demanda através da
disponibilidade do material em estoque;

Maximizar o giro de estoques ou minimizar o investimento em estoques e seus custos
correspondentes;

Maximizar a eficiência operacional, minimizando os custos do processo de suprimento,
consistindo este de aquisição, transferência ou produção dos materiais.
Como pode-se observar na Figura 7, esses objetivos são conflitantes entre si, ou seja, ao
se tentar maximizar o desempenho de um deles, o desempenho dos demais (ou pelo menos num
dos demais) é prejudicado (GIANESI & BIAZZI, 2011, apud ROSS, 2003).
Figura 7: O efeito da maximização em um dos objetivos da gestão de estoques (GIANESI &
BIAZZI, 2011)
25
Os conflitos são exemplificados na Tabela 3. Isto significa que saber quais são os
objetivos da gestão dos estoques não é o bastante. É necessário saber quais objetivos priorizar e
em que medida, ou seja, é necessário definir em que posição o triângulo que representa os
objetivos deve ser posicionado.
A maximização do ...se faz às custas do desempenho de...
...e/ou às custas do desempenho de...
desempenho de...
Nível de Serviço
Giro de estoques – pode-se maximizar o Eficiência Operacional – pode-se maximizar o
nível de serviço mantendo-se altos níveis de nível de serviço através do aumento da
estoque que garantam a disponibilidade, agilidade do processo de suprimento. Esta
mesmo sob altos níveis de incerteza sobre a agilidade, geralmente leva a custos adicionais,
demanda futura. Quanto maior o nível de seja em função de um transporte mais rápido,
serviço desejado, maior deverá ser o nível fornecedor com menor prazo de entrega, maior
de estoques, consequentemente menor o frequência
giro.
Giro de Estoques
de
pedidos
ou
mudança
de
prioridade na sequência de produção.
Nível de Serviço – para maximizar o giro Eficiência Operacional - pode-se maximizar o
de estoques, ou seja, reduzir o investimento giro de estoques, ou seja, minimizar os
em estoques, pode ser necessário abrir mão estoques através do aumento da agilidade do
do
nível
reduzidos,
de
não
serviço.
se
Com
pode
estoques processo
garantir
de
suprimento.
Esta
agilidade,
a geralmente leva a custos adicionais, seja em
disponibilidade de materiais que permitirá função
de
um
transporte
mais
rápido,
atender a demanda sobre a qual não se tem fornecedor com menor prazo de entrega, maior
informação
perfeita
a
respeito
de frequência
quantidade e momento.
de
pedidos
ou
mudança
de
prioridade na sequência de produção.
Eficiência Operacional Giro de estoques – para maximizar a Nível de Serviço - para maximizar a eficiência
eficiência operacional, deve-se buscar o operacional, deve-se buscar o transporte mais
transporte mais eficiente, o fornecedor de eficiente, o fornecedor de menor custo (o que
menor custo (o que geralmente significa geralmente significa maior prazo de entrega) e
maior prazo de entrega), pedir com menor manter fixa a sequência de produção, sem
frequência e manter fixa a sequência de alterações no curto prazo. Isto significa reduzir
produção, sem alterações no curto prazo. a agilidade do processo de suprimento. Nessas
Isto significa reduzir a agilidade do condições, a menos que os estoques estejam
processo de suprimento. Nessas condições, altos, não se pode garantir o atendimento da
a menos que se pretenda abrir mão do nível demanda, prejudicando o nível de serviço.
de serviço, devem-se manter estoques altos,
reduzindo o giro de estoques.
Tabela 3: Exemplificando os conflitos entre os objetivos da gestão de estoques (GIANESI
& BIAZZI, 2011)
26
Independentemente dos objetivos de gestão de estoques que uma organização determina,
é necessário que se tenha informações corretas para apoiar a tomada de decisões para atingir tais
objetivos. A próxima seção apresenta alguns métodos quantitativos para obtenção dessas
informações.
2.3.1 Métodos Quantitativos
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
todas as decisões. O método quântico dos mínimos quadrados (MMQ) é uma das técnicas
utilizadas 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.
27
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 2005. O Gráfico da Figura 8 ilustra a linha de tendência. As vendas
dos cinco anos anteriores foram conforme a Tabela da Figura 8, de onde resultam as seguintes
equações baseadas nas equações normais (respectivamente):
Figura 8: Exemplo de calculo da tendência
1767 = 5a + 15b
5442 = 15a + 55b
Para encontrar o coeficiente b:
5a + 15b = 1767 (-3)
15a + 55b = 5442
-15a - 45b = -5301
15a + 55b = 5442
10b = 141 → b = 14,1
Substituindo b na primeira equação normal:
1767 = 5a + (15 x 14,1)
Logo a tendência para 2005 é:
1767 = 5a + 211,5
Y = 311,1 + (14,1 x 6)
1767 = 5a + 211,5 → a = 311,1
Y = 395,7 = 396 unidades
Estoque médio
O estoque médio (EM) é definido como a quantidade média em estoque de um ou mais
itens, em um determinado intervalo de tempo. Compreende a quantidade de produtos
28
normalmente mantidos em estoque. Para Martins (2012), é o nível médio de estoque em torno do
qual as operações de compra e consumo se realizaram. A seguir é apresentado as três formas
básicas para o calculo do estoque médio (PEREIRA, 2012), considerando que o período em
análise seja de 12 meses:

Forma aproximada – utiliza-se apenas os valores constantes do balanço atual e do
balanço do ano anterior:
EM = ESTOQUE INICIALESTOQUE FINAL ÷ 2

Forma usual – utiliza-se os valores dos estoques no final de cada um dos meses,
constantes dos balancetes mensais. ( EF = estoque final ):
EF = EF1EF2 EF3...EF11EF12 ÷ 12

Forma correta – permite uma apuração exata do estoque médio do ano, calculando-se as
médias de cada mês:
EM = EM1EM2EM3...EM11EM12 ÷ 12
Estoque de segurança
O estoque de segurança determina a quantidade mínima que deve existir no estoque,
destinada a cobrir eventuais atrasos no suprimento e objetivando a garantia do funcionamento
eficiente do processo produtivo, sem o risco de faltas (BRITO, 2010, apud GARCIA;
LACERDA; AROZO, 2001).
Pascoal (2008, apud FRANCISCHINI, 2002) aponta que as falhas mais críticas no
procedimento de reposição de estoque ocorrem em três pontos principais: aumento repentino de
demanda, demora no processo do pedido de compra e atrasos de entrega pelo fornecedor.
No entanto, um estoque de segurança que supra qualquer variação do sistema implica
custos elevadíssimos e que talvez a empresa poderá não suportar. Então a solução é determinar
um estoque de segurança que possa otimizar os recursos disponíveis e minimizar os custos
envolvidos (POZO, 2010).
29
O método com grau de atendimento definitivo (MGAD) é uma das formas para calcular o
estoque de segurança (ES) eficientemente, que, baseia-se em um consumo médio do produto
durante certo período e um atendimento da demanda não em sua totalidade, mas em determinado
grau de atendimento. Pode-se, então, comparar em termos percentuais e financeiros as diversas
alternativas de grau objetivando a garantia do funcionamento de atendimento, decidindo-se pelo
que melhor atender à política da empresa (POZO, 2010). Passos para o calculo do ES:
1. Calcular o consumo médio (Cmd)
C md =∑ C : n
2. Calcular o desvio padrão (δ)
δ=

n
∑ C−C md 2
i =1
n−1
3. Calcular o estoque de segurança (ES)
ES =δ ×k
Onde:

Cmd = Consumo médio mensal;

C = consumo mensal;

n = numero de períodos;

δ = desvio padrão;

k = coeficiente de risco (ver Tabela 4). Uma função da distribuição normal acumulada
que indica a probabilidade de haver uma demanda maior que o estoque de segurança
projetado, considerando-se um determinado nível de serviço ao cliente.
30
Risco %
k
Risco %
k
Risco %
k
52
0,102
80
0,842
90
1,282
55
0,126
85
1,036
95
1,645
60
0,253
86
1,085
97,5
1,960
65
0,385
87
1,134
98
2,082
70
0,524
97,5
1,159
99
2,326
75
0,674
88
1,184
99,5
2,576
78
0,775
89
1,233
99,9
3,090
Tabela 4: Valores do coeficiente k para graus de atendimento com riscos percentuais
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
A cobertura de estoque, também conhecida como período de renovação dos estoques ou
ainda prazo médio de estocagem, indica quantos dias em média os produtos ficam armazenados
até o momento de sua venda (KOXNE et al., 2003).
Para Pereira (2012), indica o número de unidades de tempo (meses ou dias) durante os
quais poderá o estoque movimentar-se sem que haja necessidade de nova encomenda, ou seja, o
tempo que o estoque médio será suficiente para cobrir a demanda média (KOXNE et al., 2006,
apud MARTINS et al., 2003).
Vale salientar que quanto maior a cobertura, maior é o tempo de permanência dos
estoques nos armazéns, em que os estoques correm os riscos de perder a validade e tornar-se
obsoletos. Fórmula, considerando número de dias:
Cobertura=número de dias do período emestudo÷ giro de estoque
31
ROA
Retorno sobre o ativo (ROA – Return Over Assets), retorno sobre o investimento, o
retorno sobre o patrimônio líquido e a rentabilidade das vendas são alguns dos indicadores de
rentabilidade financeira. Entre eles, o ROA é o que está mais relacionado aos estoques,
porquanto engloba a totalidade dos ativos (BARON, 2009).
O ROA significa taxa de retorno gerado pelas aplicações realizadas por uma empresa em
seus ativos e é calculado pela seguinte fórmula:
ROA=Lucro Operacional÷ AtivoTotal Médio
Segundo Angotti (2010), a decomposição do índice de retorno dos ativos pode ser vista
através da margem líquida (ML) e do giro dos ativos (GA):
ROA
lucro liquido
lucro liquido
vendas
= ML 
 x GA

ativototal
vendas
ativo total
O uso do ROA pode proporcionar alguns benefícios (VIEIRA, 2011, apud WERNKE,
2008): a identificação de como a margem do lucro aumenta ou se deteriora; a possibilidade de
medir a eficiência dos ativos permanentes em produzir vendas; possibilidade de avaliar a gestão
do capital de giro por intermédio de indicadores mensurados em dias; faculta o estabelecimento
de medidas que aferem a habilidade do gestor para controlar custos e despesas em função do
volume de vendas; propicia a comparação das medidas de eficiência citadas anteriormente e
estabelece o patamar máximo de custo de captação de recursos que a empresa pode suportar.
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.
32
Custo de Aquisição
Custo de aquisição é o valor pago pela organização compradora pelo material adquirido.
Fórmula:
Custo de Aquisição = Preço Unitário x Quantidade Adquirida
Custo de Falta
Custo de falta de um item em estoque pode causar diversos e, muitas vezes, grandes
prejuízos para as organizações, seja de forma operacional ou financeira, considerando que uma
empresa pode parar o seu processo de produção ou atrasar um pedido de um cliente (VAZ, 2011,
apud SILVA, 2001).
Duas formas de calcular os custos de falta de estoques são:

Por meio de lucros cessantes devidos a incapacidade de fornecer;

Perdas de lucros com cancelamento de pedidos.
33
3 Estudo de Caso
3.1 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
1979.
3.2 Sistemas de Gestão Empresarial
O sistema de gestão atual, denominado Winthor, é utilizado pela empresa desde 2003.
Este sistema foi uma solução concebida especialmente para atender às necessidades da empresa e
as particularidades do negócio de distribuição de alimentos. Hoje o Winthor atende a todos os
requisitos relacionados aos sistemas de informação no nível operacional, ou seja, o sistema
atende perfeitamente as situações do dia-a-dia da empresa (cadastro de clientes, cadastro de
produto, lançamentos de pedidos, cadastro de vendedores, impressão de relatórios, lista de
preços, pedidos, nota fiscal e controle de estoque).
3.3 Departamento de Tecnologia da Informação (TI)
A escolha da TI como departamento a ser estudado se dá ao fato de as iniciativas para a
implantação de um BI partirem desse departamento. O departamento conta atualmente com 8
funcionários e 3 estagiários. Suas responsabilidades são muitas, podendo ser divididas em pelo
menos 5 setores:
34

Banco de dados: setor de suporte ao ERP da empresa (Winthor) e os bancos de dados
utilizados por esse ERP, que utilizam o sistema de gerenciamento de bancos Oracle;

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;

Suporte: presta serviços, conserta equipamentos, etc.

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.

Monitoramento: responsável pelo monitoramento do tráfego da rede através do aplicativo
Nagius.
3.4 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, como ilustra a Figura 9.
Figura 9: Espiral do conhecimento e modelo espiral de desenvolvimento de software
(MATHEUS & PARREIRAS 2004).
35
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 úteis,
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 novas perspectivas sobre o negócio da organização. Nesta 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 9.
O objetivo deste capítulo é apresentar as 6 fases que foram necessárias para se
desenvolver a solução business intelligence com o Pentaho. Ressalta-se que o contexto de cada
etapa apresentada relaciona-se principalmente com a fase de externalização- desenvolvimento de
sua respectiva espiral. Descrição geral:

Criação do modelo lógico e físico de um DW utilizando a arquitetura data mart bus, com
a ferramenta Power Architect;

Criação de processos ETL com o Pentaho Data Integration 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 no Mondrian, que é
integrado pelo servidor do Pentaho;

Criação de relatórios dinâmicos (apresentações) com base nas consultas MDX, utilizando
o Pentaho Report Designer;
36

Criação de processos automatizados de difusão das apresentações, por meio de trabalhos,
no Pentaho Data Integration.
3.4.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 10),
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 10: Data Mart Bus, adaptado de Watson & Ariyachandra (2005)
O segundo passo foi elaborar o modelo lógico do negócio. A Figura 11 ilustra o modelo
lógico dimensional dos data marts criados. As tabelas fatos que compõe o modelo são: Pedidos,
Histórico de Produtos e Perdas por Falta de Produto. As tabelas dimensões são: Cliente, Status,
Tempo, Filial, Fornecedor, Vendedor e Produto.
Na tabela Pedidos são registrados valores como vendas, custos e quantidade dos produtos.
Os dados são sumarizados por filial da empresa, dia de pedido, fornecedor, cliente, vendedor,
supervisor, produto e status do pedido (se está bloqueado, faturado, cancelado, etc.). Cada
processo de venda/pedido da empresa é identificado por meio de um único código que sirva para
toda a empresa ou filial, que é o código do pedido.
37
Figura 11: Data marts para apoiar o processo de gestão de estoques (autor)
Na tabela de Histórico de Produtos (HISTORICO_PRODUTO), são registrados a
quantidade/data da última entrada, preço/custo custo unitário médio, estoque disponível, estoque
médio, giro de estoque, cobertura de estoque e margem de lucro. Os registros são sumarizados
por dia e filial.
Na tabela de Perdas por Falta de Produtos (PERDAS_FALTA_PRODUTO), são
registrados as quantidades de produtos que não foram vendidos por falta em estoque e o preço
unitário 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.
38
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.
Na tabela Status 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 (status) e é armazenado a
legenda desse tipo: faturado (F), bloqueado (B), montado (M), etc.
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.
Na tabela Filial são armazenadas apenas os códigos das filiais com suas respectivas
razoes sociais.
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.
Na tabela Vendedor são registrados os vendedores 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.
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 e data de cadastro.
Apesar de parecer simples, os data marts apresentados podem responder muitas questões,
tanto relacionadas a gestão de estoques como outros tipos de negócios. Por exemplo:

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)?
39

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
(∑9i=1 C9,i ) * 4 = 2044

Tabela de historico de produto: 3 atributos e 9 valores
(∑3i=1 C3,i ) * 9 = 63

Tabela de Perdas por falta de produto: 8 atributos e 2 valores
(∑8i=1 C8,i ) * 2 = 510

Total = 2617 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
2 http://www.sqlpower.ca/page/architect
40
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.4.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 transformados. É nessa etapa que os métodos
quantitativos foram aplicados: primeiro foi extraido os dados da base do ERP; em seguida esses
dados foram transformados com os cálculos que foram abordados na seção 2.3.1 por meio de
consultas (SQL); finalmente esses dados transformados foram carregados e povoados nas tabelas
do DW.
A ferramenta utilizada para modelar tais processos foi o Pentaho Data Integration (PDI),
conhecidas como transformações PDI. As transformações criadas no PDI estão no Anexo 1.
3.4.3 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 11, 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.
3.4.4 Criação das consultas MDX
Para obtenção das informações necessárias para criação das apresentações, foram
modeladas algumas consultas MDX. A ferramenta utilizada foi o Mondrian, na qual, permite que
consultas MDX sejam processadas dinamicamente com praticamente todas as operações de
41
analises OLAP em uma interface Web, além de gerar gráficos baseados nas consultas. Alguns
exemplos de consultas são apresentados no Anexo 2.
3.4.5 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.4.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 e-mail 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).
42
4 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 este trabalho foi
voltado, onde este por sua vez, apresentou a solução BI criada para prover informações úteis aos
gestores do Atacadão de Estivas e Cereais Rio do Peixe.
No presente trabalho, foram apresentados os data marts integrados que foram criados
para a empresa utilizando a arquitetura Data Mart Bus. Para construção e análise de cubos
OLAP, foi utilizada a ferramenta Mondrian, em que 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.
Pode-se constatar que a solução criada pode ser uma base 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 deste 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 do Pentaho para o
data mining.
43
Referências
ALMEIDA, D. LUCENA, M. Gestão Estoques na Cadeia de Suprimentos. Revista ECCO 01.
Ano I - nº 1 - 2º semestre, 2006.
AMBIENTE LIVRE TECNOLOGIA. Conhecendo o Pentaho BI Server - Arquitetura e
infraestrutura. Disponível em <http://www.ambientelivre.com.br/>. Acesso em: 22 abril, 2011.
ANGOTTI, M. Análise DuPont como ferramenta de apoio às decisões de investimento em ações.
Dissertação de mestrado, Pós-graduação em Ciências Contábeis, Universidade Federal de
Minas Gerais, Belo Horizonte, 2010.
BARON, G. D. A influência do planejamento integrado com foco na gestão de estoques no valor
econômico agregado: estudo de caso Embraco. Dissertação de mestrado, Pós-graduação
Engenharia de Produção, Universidade Federal de Santa Catarina, Florianópolis, 2009.
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, 2009.
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, 1998.
BOUGMAN, R.; DONGEN, J. Pentaho® Solutions, Business Intelligence and Data
Warehousing with Pentaho and MySQL. WILEY, Indianapolis, 2009.
BRITO, T. L. Aplicação de modelos de gestão de estoques para controle de ressuprimento em
uma pequena empresa industrial: um estudo de caso. Trabalho de Conclusão de Curso,
44
Graduação em Engenharia de Produção, Universidade Federal de Juiz de Fora, Juiz de Fora,
2010.
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. 19-34, Brasília, maio/ago, 2009.
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.
2006.
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, 2010.
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, 2005.
FREE
SOFTWARE
FOUNDATION.
O
que
é
o
software
livre.
Disponível
em
<http://www.gnu.org/philosophy/free-sw.pt-br.html>. Acesso em: 26 de Maio de 2012.
GIANESI, I. G. N. & BIAZZI, J. L. Gestão Estratégica dos Estoques. Insper Working Paper,
2011.
GOUVEIA, R. M. M. Mineração de Dados em Data Warehouse para Sistema de Abastecimento
de Água. Dissertação de mestrado, Pós-graduação em Informática, Universidade Federal da
Paraíba, João Pessoa, 2009.
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, 2000.
KOXNE, D. C.; HAUSSMANN, D. C. S.; BEUREN, I. M. Um estudo do controle e dos custos
dos estoques: o caso de uma empresa comercial varejista importadora. III SEGeT – Simpósio
de Excelência em Gestão e Tecnologia, 2006.
45
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, 2004.
MARTINS,
E
F.
Gestão
de
Estoques.
Livro-texto.
Disponível
em
<http://www.administracao.ufcg.edu.br/>. Acesso em: 22 de maio de 2012.
MULLER, M. Essentials of Inventory Management. Team Fly. AMACON, American
Management Association. Estados Unidos, 2003.
PASCOAL, J. A. Gestão estratégica de recursos materiais: controle de estoque e armazenagem.
Monografia de graduação, Bacharel em Administração, Centro Universitário de João pessoa –
UNIPÊ, 2008.
PENTAHO
CORPORATION.
Pentaho
Community
Home.
2011.
Disponível
em
<http://community.pentaho.com/>. Acesso em: 22 de maio de 2011.
PEREIRA,
G.
R.
O
índice
de
rotação
de
estoque.
Disponível
em
<http://www.mackenzie-rio.edu.br>. Acesso em: 15 de outubro de 2012.
POZO, H. Administração de Recursos Materiais e Patrimoniais: Uma Abordagem Logística.
Editora Atlas, e. 6. São Paulo, 2010.
RAMOS, M. V. M. Controlando os Estoques com Inteligência. 2006. Disponível em
<http://www.biblioteca.sebrae.com.br/>. Acesso em 15 de Outubro de 2012.
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, 2007.
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, 2008.
46
VAZ, R. A. P. GOMES, S. Gestão de Estoques nas Micro e Médias Empresas: Um Estudo de
Caso na Empresa Madeireira Catalana LTDA. Revista CEPPG - CESUC - Centro de Ensino
Superior de Catalão, Ano XIV, Nº 24 - 1º Semestre, 2011.
VIEIRA, C. B. H. A.; VERDE, I. O. L.; BEZERRA, R. L.; RODRIGUES, P. N.; ISMAEL, V. S.
Índices de rentabilidade: um estudo sobre os indicadores ROA, ROI e ROE de empresas do
subsetor de tecidos, calçados e vestuários listadas na Bovespa. VIII Convibra Administração,
2011.
WATSON, H. J. & ARIYACHANDRA, T. Data Warehouse Architectures: Factors in the
Selection Decision and the Success of the Architectures. 2005.
47
Anexo 1: Processos ETL
Tempo
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.
48
Figura 12: Transformação que povoa a tabela Tempo
Fornecedor
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 13: Transformação que povoa a tabela Fornecedor
49
Cliente
O processo ETL modelado para povoar a tabela Cliente é ilustrado na Figura 14: 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 14: Transformação que povoa a tabela Cliente
Vendedor
O processo ETL modelado para povoar a tabela Vendedor é ilustrado na Figura 15: 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 15: Transformação que povoa a tabela Vendedor
Produto
O processo ETL modelado para povoar a tabela Produto é ilustrado na Figura 16: 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.
50
Figura 16: Transformação que povoa a tabela Produto
Status
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 17, que utiliza um arquivo simples
CSV como fonte de informações dos status (posição e legenda).
Figura 17: Transformação que povoa a tabela Status
Filial
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 18.
Figura 18: Transformação que povoa a tabela Filial
Pedidos
O processo ETL modelado para povoar a tabela Pedidos é ilustrado na Figura 19: 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
51
data do pedido corrente; para então os campos extraídos e transformados serem
inseridos/atualizados na tabela Pedidos.
Figura 19: Transformação que povoa a tabela Pedidos
Histórico de Produtos
O processo ETL modelado para povoar a tabela Histórico de Produtos é ilustrado na
Figura 20: 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, que realiza também calculos com
base nas informações; em seguida os campos extraídos e transformados são inseridos/atualizados
na tabela.
Figura 20: Transformação que povoa a tabela Histórico de Produtos
Perdas por Falta de Produtos
O processo ETL modelado para povoar a tabela Perdas por Falta de Produtos é ilustrado
na Figura 21: 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.
Figura 21: Transformação que povoa tabela Perdas Por Falta de Produtos
52
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 linhas3;

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 22 apresenta os dados gerados pela consulta com seu gráfico de barras verticais,
ambos gerados pelo Mondrian.
3 É possível especificar até 128 eixos em uma consulta MDX;
53
Figura 22: 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 4. 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 5. 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,
10
)
} ON ROWS
from [Perda]
[Measures].[Year], desc),
MDX 2: Consulta para pesquisar as perdas TOP 10 de 2011
4 http://msdn.microsoft.com/pt-br/library/ms145592.aspx
5 http://msdn.microsoft.com/pt-br/library/ms146017.aspx
54
A Figura 23 apresenta os dados gerados pela consulta com seu gráfico de pizza, ambos
gerados pelo Mondrian.
Figura 23: Gráfico de pizza dos produtos, TOP 10
55
Anexo 3: Exemplo de Relatório Criado
A Figura 24 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.
56
Figura 24: Relatório de produtos vendidos, utilizando MDX + PRD
57
Anexo 4: Jobs
A Figura 25 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 25: Trabalho para a povoação das tabelas dimensões
A Figura 27 apresenta o trabalho criado para povoar as tabelas fatos.
Figura 26: Trabalho para povoação das tabelas fatos
A Figura 27 apresenta o trabalho para gerar os relatórios e enviá-los por e-mail 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.
58
Figura 27: Trabalho para automatizar a geração e envio de relatórios
59
Anexo 5: Organização das Ferramentas
/opt/penataho/
3.5.2/
administration-console/
biserver-ce/
data-integration/
design-studio/
report-designer/
schema-workbench/
tools/
jdbc/
ojdbc14.jar
JVM/
jdk1.6.0_16/
sql/
power-architect-1.0.0/
sqldeveloper/
sqleonardo-2009.03.rc1/