UNIVERSIDADE DO VALE DO ITAJAÍ - siaibib01.univali.brsiaibib01.univali.br/pdf/Ivo Jose Soares Junkes.pdf · Os gerentes e diretores, ... dos diretores de empresa consultados admitem

I

UNIVERSIDADE DO VALE DO ITAJAÍ

Ivo José Soares Junkes

SISTEMA DE APOIO GERENCIAL BASEADO EM OLAP APLICADO NA JUNIOR INDÚSTRIA E COMERCIO LTDA.:

Área de Sistema de Informação

Florianópolis (SC) 2006

ii

Ivo José Soares Junkes

SISTEMA DE INFORMAÇÃO GERENCIAL BASEADO EM OLAP

APLICADO NA JUNIOR INDUSTRIA E COMERCIO LTDA.: Área de Sistema de Informação

Trabalho de conclusão de curso apresentado como requisito parcial para obtenção do título de bacharel em Ciências da Computação na Universidade do Vale do Itajaí, centro de educação São José.

Prof. Msc.. Luiz Eduardo Perfeito Nunes

Florianópolis (SC) 2006

iii

RESUMO

Este trabalho teve por objetivo desenvolver um projeto de Sistemas de Apoio à Decisão Baseado em OLAP, com aplicação prática na empresa JUNIOR Indústria e Comercio. O trabalho utilizou conceitos de sistemas de informação e tecnologia OLAP aplicados em um banco de dados multidimensional, permitindo ao usuário/gestor elaborar e executar consultas de uma maneira simples. O projeto foi focado na área considerada mais importante pela empresa para tomada de decisão, a área comercial, utilizando informações geradas por meio da grande quantidade de dados obtidos diariamente, que, muitas vezes, são desperdiçados devido à falta de uma ferramenta adequada para transformá-los em informação. Os dados relacionais digitados serão exportados diariamente, conforme modelagem para um banco multidimensional. O acesso às consultas pré-formatadas foi feito por meio do banco multidimensional. Na fundamentação teórica deste trabalho, foram vistos conceitos de sistemas, banco multidimensional e Data Mart, que deram subsídios para a realização e modelagem dos Sistemas de Apoio à Decisão Baseado em OLAP da JUNIOR.

Palavras-chave: OLAP. Multidimensional, Data Mart, Cubo.

iv

ABSTRACT

This work has for objective to create a project of systems of support the decision based on olap with application practises in company JUNIOR Industria e Comercio LTDA. The work will use concepts of information systems and technology olap applied in a multidimensional data base, allowing the user to elaborate and to execute consultations in a simple way. The project will be acting in the area considered more important for the company for decision taking, the commercial area, using information generated through the great amount of gotten data daily that, many times, are wasted due to lack of an adjusted tool to transform them into information. The typed relationary data daily will be exported daily in agreement modeling to a multidimensional bank. The access the formatted consultations daily pay will be made by means of the multidimensional bank. In the theoretical recital of this work concepts of systems, multidimensional bank and mart date will be seen that will give to subsidies for the accomplishment and modeling of the systems of support the decision based on olap of the JUNIOR.

v

LISTA DE FIGURAS

FIGURA 1 – COMPONENTES DE UM SISTEMA.............................................................. 19

FIGURA 2 - CLASSIFICAÇÃO DOS PROBLEMAS DE DECISÃO.................................... 22

FIGURA 3 - DIAGRAMA DOS NÍVEIS HIERÁRQUICOS DA INFORMAÇÃO ............. 28

FIGURA 4 – MODELO DE DATA WATREHOUSE........................................................... 32

FIGURA 5 – NÍVEIS DE GRANULARIDADE .................................................................... 34

FIGURA 6 – TABELA DE FATO E DIMENSÕES............................................................... 38

FIGURA 7 – DIMENSÃO E NÍVEL ..................................................................................... 39

FIGURA 8 – CUBO COM AS DIMENSÕES PRODUTO TEMPO E VENDAS...... 40

FIGURA 9 – EXEMPLO DE OPERAÇÃO ROLL UP.............................................. 42

FIGURA 10 – EXEMPLO DE OPERAÇÃO DRILL DOWN.................................... 43

FIGURA 11 – EXEMPLO DE OPERAÇÃO SLICE.................................................. 44

FIGURA 12 – EXEMPLO DE OPERAÇÃO DICE................................................... 44

FIGURA 13 – MODELO INTEGRADO DE INFORMAÇÕES .......................................... 56

FIGURA 14 – METODOLOGIA PARA SISTEMA DE INFORMAÇÃO .......................... 57

FIGURA 15 – COMPONENTES DA FASE DE PLANEJAMENTO................................... 57

FIGURA 16 – OBJETIVOS DA FASE DE PLANEJAMENTO .......................................... 59

FIGURA 17 – OBJETIVOS DA FASE DE PROJETO ............................................... 64

FIGURA 18 – FASE DE IMPLEMENTAÇÃO ......................................................... 65

FIGURA 19 – MODELO GERAL PROPOSTO.......................................................... 68

vi

FIGURA 20 – ORGANOGRAMA FUNCIONAL DO SISTEMA.............................. 71

FIGURA 21 – USE CASE GENÉRICO ............................................................................... 73 FIGURA 22 – DESENVOLVIMENTO ............................................................................... 74 FIGURA 23 – ADMINISTRAÇÃO DO SISTEMA ............................................................ 74 FIGURA 24 – CONSULTAS DO SISTEMA ...................................................................... 75 FIGURA 25 – SHEDULE .................................................................................................... 75 FIGURA 26 – DTS DESENVOLVIDO PARA A JUNIOR ................................................ 76 FIGURA 27 – LIMPAR TABELA ...................................................................................... 76 FIGURA 28 – CUBO JUNIOR.............................................................................................. 81 FIGURA 29 – CONSULTA PREÇO MÍNIMO..................................................................... 82 FIGURA 30 – CONSULTA CRÉDITO................................................................................. 82

vii

LISTA DE ABREVIATURAS

DOLAP Database OLAP e Desktop OLAP DSS Decisions Support Services DTS Data Transformation Services ER Entidade-Relacionamento HOLAP Hybrid OLAP HTML Hypertext Markup Language MOLAP Multidimensional OLAP MROLAP Mobile and Remote OLAP OLAP On-Line Analytical Processing ROLAP Relational OLAP SAD Sistema de Apoio à Decisão SIGBO Sistema de Apoio Gerencial Baseado em OLAP SADBO Sistema de Apoio a Decisão Baseado em OLAP SGBD Sistema Gerenciador de Banco de Dados SGBDM Sistema Gerenciador de Banco de Dados Multidimensional SGBDR Sistema Gerenciador de Banco de Dados Relacional SI Sistemas de Informações SIE Sistemas de Informações Executivas SIG Sistemas de Informações Gerenciais SQL Structured Query Language TCC Trabalho de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí WOLAP Web OLAP BD Banco de Dados TI Tecnologia da Informação BI Business Intelligence EIS Sistemas de Informação Executiva

8

SUMÁRIO

1. INTRODUÇÃO 04 1.1 CONTEXTUALIZAÇÃO 04 1.2 PROBLEMA 05 1.3 JUSTIFICATIVA 05 1.4 PLANO DE TRABALHO 06

1.5 CRONOGRAMA 11 1.6 OBJETIVOS 12 1.6.1 Objetivo geral 12 1.6.2 Objetivos específicos 12

1.7 ESTRUTURA DO TRABALHO 13 2. CARACTERIZAÇÃO DA EMPRESA 14 2.1 HISTÓRICO 14 3. FUNDAMENTAÇÃO TEÓRICA 16 3.1 SISTEMAS DE INFORMAÇÃO 17 3.1.1 Sistemas de apoio às operações 19 3.1.2 Sistemas de apoio gerencial 20 3.2 PROCESSO DE TOMADA DE DECISÃO 20 3.3 BUSSINESS INTELLINGENCE 26 3.4 ESTRUTURA DOS BANCOS DE DADOS 29 3.4.1 Estrutura multidimensional 29 3.4.2 Armazéns de dados 30 3.4.3 Características de um Data Warehouse 33 3.4.4 Granularidade e particionamento 34 3.4.5 Data Mart 35 3.5 MODELO MULTIDIMENTSIONAL 37 3.5.1 Fatos e medidas 38 3.5.2 Dimensões 39 3.5.3 A Visualização de um modelo multidimensional 40 3.5.4 Agregação 41 3.5.5 Operação básica de OLAP 42 3.6 OLAP - ON-LINE ANALYTICAL PROCESSING 44 3.6.1 Exemplos de OLAP 45 3.6.2 Requisitos funcionais para OLAP 46 3.7 MICROSOFT SQL SERVER 48 3.7.1 DSS - Decisions Support Services 49 3.7.2 Assistentes do DSS 50 3.7.3 Componentes do DSS 51 4. PLANEJAMENTO 52 4.1 DIAGNÓSTICO PREVIO ÁREA DE INFORMÁTICA 53 4.2 DIAGNÓSTICO PRÉVIO DA ÁREA COMERCIAL 53 4.3 DIAGNÓSTICO PRÉVIO DA ÁREA ESTRATÉGICA 54

9

5. DESENVOLVIMENTO DO SISTEMA PROPOSTO 56 5.1 INTRODUÇÃO 56 5.2. METODOLOGIA DE DESENVOLVIMENTO 56 5.3 ESPECIFICAÇÃO TECNOLÓGICA ENVOLVIDA 66 5.3.1 Níveis de segurança 68 5.3.2 Carga de dados 68 5.3.3 Resultados esperados 69 5.4 ANÁLISE FUNCIONAL 70 5.4.1 Introdução 70 5.4.2 Organograma funcional do sistema 71 5.4.3 Análise dos riscos 5.4.4 Diagramas de caso de uso 5.4.5 Estrutura do DTS 76 5.4.6 Dimensões e consultas modeladas para o cubo JUNIOR 81 6. CONSIDERAÇÕES FINAIS 83

ANEXO I – QUESTIONARIO GESTORES 85

ANEXO II – TABELAS UTILIZADAS 86

REFERÊCIAS BIBLIOGRÁFICAS 96

10

1. INTRODUÇÃO

1.1 CONTEXTUALIZAÇÃO

Há alguns anos, já está consolidado nas grandes corporações o armazenamento dos dados da

empresa através de Banco de Dados (BD), os quais, na maioria das vezes, servem somente

como apoio ao trabalho operacional da empresa, não sendo aproveitado o registro histórico

das informações para uso na estratégia e tomada de decisão da empresa. (DWINF 2005)

Os gerentes e diretores, nessa situação, tomam suas decisões baseados em suas intuições

executivas, sem considerar a evolução da empresa registrada nos dados de seus sistemas. De

acordo com uma pesquisa realizada pela Aspect International Consulting (1997), 88% (oitenta

e oito por cento) dos diretores de empresa consultados admitem que dedicam 75% (setenta

cinco por cento) de seu tempo a tomadas de decisão apoiadas em análises subjetivas, sendo

que 100% (cem por cento) deles têm acesso a computadores. Inúmeros motivos podem levar a

esse desperdício. Por exemplo, o uso de sistemas diferentes por cada setor da empresa, o que

dificulta o cruzamento de informações e a consistência das mesmas. Outro motivo seria o fato

desses sistemas estarem focados, na maioria dos casos, para uso do operacional e não estarem

preparados para responder as questões gerenciais de cada empresa. Mesmo quando todas as

informações da corporação estão centralizadas em um único Banco de Dados, o enorme

volume de dados dificulta a análise dos mesmos.

Percebendo esse problema o conceito de Data Warehouse (DW) foi introduzido, visando

filtrar os dados e organizá-los em um outro Banco de Dados (BD), paralelo ao já utilizado

pela empresa. Neste outro BD, os dados corporativos são organizados para atender as

necessidades dos gerentes e diretores da empresa. Esse processo de organização dos dados

ocorre com novos métodos de armazenamento, estruturação e novas tecnologias para geração

e recuperação das informações. Segundo Kimball (1998), DW é um conjunto de ferramentas e

técnicas de projeto, que, quando aplicadas às necessidades específicas dos usuários e aos

bancos de dados específicos, permitirá o planejamento e construção de um DW. Essas novas

tecnologias já estão bem consolidadas no mercado na forma de diversas ferramentas para

cumprir todas essas etapas.

11

Como se relatou, a ferramenta utilizada na administração do Banco de Dados é o Microsoft

SQL Server, que apresenta suporte a OLAP (On-Line Trasaction Processing – Processamento

de Transações On-Line). OLAP será um dos conceitos estudados e implementados durante a

realização deste projeto. Segundo O´Brien (2001), OLAP é a capacidade dos sistemas de

apoio à decisão em permitir aos usuários manipular e examinar de forma interativa grande

quantidade de dados detalhados e consolidados a partir de várias perspectivas. Segundo

Pereira (1999), a aplicação de técnicas OLAP pode constituir um conjunto de atividades de

consulta e apresentação de dados provenientes do DW.

1.2 PROBLEMA

A JUNIOR, por ser uma empresa atuando em um mercado extremamente competitivo,

necessita tomar decisões, principalmente na área comercial, de forma rápida e o mais

confiável possível. Atualmente, as decisões são tomadas baseadas em relatórios relacionais

retirados do Sistema de Gestão MICROSIGA. Este processo é lento e burocrático, impedindo

os executivos de tomarem suas decisões baseadas em relatórios específicos ou dinâmicos.

Sendo assim este trabalho teve por objetivo desenvolver um sistema de informações baseado

nestas necessidades e focado na área comercial aonde o gestor verificará as informações

necessárias para a administração da área comercial , acessando o excel como ferramenta de

usuário.

1.3 JUSTIFICATIVA

Este trabalho se justifica em nível de Trabalho de Conclusão de Curso para o Curso de

Ciência da Computação por se tratar do estudo e implementação de conceitos de DW, DM

entre outros, que fazem parte das necessidades de grande parte das corporações que procuram

vantagens competitivas para melhorar ou assegurar um bom desempenho frente seus cliente e

ou concorrentes. Durante a execução deste trabalho, algumas tecnologias e ferramentas de

grande importância serão revisadas e estudadas como, por exemplo, MS SQL Server,

tratamento de dados, administração de BD entre outros. O desenvolvimento de um Data Mart

focado no comercial da empresa será de grande importância para análise em busca da

minimização de problemas e na geração de informações que auxiliam os gestores no processo

de tomada de decisão.

12

1.4 PLANO DE TRABALHO

Este projeto de pesquisa foi executado em cinco etapas: (1) estudo, (2) modelagem,

(3) desenvolvimento, (4) validação e (5) documentação. As etapas de estudo e de modelagem

serão efetivadas no TCC I, sendo que as etapas de desenvolvimento, validação e

documentação foram efetivadas no TCC II.

Etapa 1: Estudo. Durante essa etapa serão estudados os conceitos envolvidos no projeto e alguns exemplos de projetos já implementados a respeito de DW.

A t i v i d a d e 1.1 Descrição Estudar os conceitos e exemplos relacionados

à área Descrição do recurso Qtd.Recursos

necessários • Microcomputador PC com acesso à Internet 01

Pré-requisitos • Nenhum

Metodologia O estudo dos conceitos será feito através de livros de autores especializados no assunto e artigos científicos encontrados em anais de eventos e/ou sites da Internet. A mesma dinâmica será usada para buscar estudos de casos na área. Somente serão utilizadas informações de procedência segura e que apresentem características e qualidade necessárias para tanto.

Indicador físico Documento textual com os conceitos estudados. Duração 08 semanas Etapa 2: Modelagem. Esta etapa procura levantar os dados técnicos necessários para o Desenvolvimento do projeto, criando um modelo conceitual do mesmo.

A t i v i d a d e 2.1 Descrição Identificar as necessidades de informações

executivas para tomada de decisão Descrição do recurso Qtd.Recursos

necessários • Microcomputador PC com acesso à Internet 01

Pré-requisitos • Atividade 1.1

Metodologia Através de entrevistas com os gerentes e diretores da empresa serão definidas as necessidades executivas que devem ser respondidas pelo DM.

13

Indicador físico Documento textual com as informações colhidas e as necessidades definidas.

Duração 02 semanas A t i v i d a d e 2.2 Descrição Construir o Modelo Dimensional, baseado em

tecnologia OLAP Descrição do recurso Qtd.Recursos

necessários • Microcomputador PC • Microsoft SQL Server 2000 ou superior

01 01


Metodologia Definir a granularidade dos dados, as tabelas de dimensão e os fatos que darão suporte as informações gerenciais definidas na Atividade 2.1.

Indicador físico Documento textual com as informações desenvolvidas. Duração 04 semanas A t i v i d a d e 2.3 Descrição Identificar as fontes de dados

Descrição do recurso Qtd.Recursos necessários • Microcomputador PC

• Microsoft SQL Server 2000 ou superior 01 01


Metodologia Identificar as tabelas do sistema MICROSIGA que serão utilizadas no DM e descrição dos dados contidos nelas.

Indicador físico Documento Textual com as informações pesquisadas. Duração 02 semanas Etapa 3: Desenvolvimento. Esta etapa visa a busca dos dados, adequação dos dados e a carga dos mesmos no DM. Sucintamente, aqui serão executados os processos estudados para se chegar ao modelo final que será validado na próxima etapa.

14

A t i v i d a d e 3.1 Descrição Implementar o Modelo Físico do DM

Descrição do recurso Qtd.Recursos necessários Microcomputador PC

• Microsoft SQL Server 2000 ou superior 01 01


Metodologia Construção, através do SGBD SQL Server, das tabelas que representam as dimensões e os fatos do Modelo Dimensional.

Indicador físico Apresentar Modelo Físico. Duração 04 semanas A t i v i d a d e 3.2 Descrição Preparar a área de transição de dados

(Extração, Transferência, Carga) Descrição do recurso Qtd.Recursos


01 01


Metodologia Nessa etapa são realizadas atividades de preparação dos dados para o DM, onde são aplicadas técnicas de extração, transformação e limpeza de dados mapeados do sistema BSB. Serão também definidas regras de carga dos dados no DM.

Indicador físico Área de transição de dados criada e as regras construídas. Duração 04 semanas A t i v i d a d e 3.3 Descrição • Executar os processos de carga e testes do modelo

dimensional Descrição do recurso Qtd.Recursos


01 01


Metodologia Implementar o processo de carga dos dados no DW estudado na atividade 2.3 e realizar testes de validação do modelo dimensional.

Indicador físico Exibição dos dados carregados no DM. Duração 04 semanas

15

A t i v i d a d e 3.4 Descrição • Construir as consultas ao DM


• MS Excel 01 01


Metodologia Construção das consultas para apresentar respostas às necessidades executivas, inicialmente, a serem apresentadas no MS Excel, por ser uma ferramenta padrão na empresa para visualização de informações gerenciais.

Indicador físico Apresentação do ambiente para realizar as consultas gerenciais. Duração 07 semanas Etapa 4: Validação. Esta etapa realiza experimentação e testes sobre a solução proposta, com

o objetivo de eliminar os erros existentes em sua modelagem ou desenvolvimento.

A t i v i d a d e 4.1 Descrição • Validar consultas pelos gestores


• MS Excel 01 01


Metodologia Apresentar o sistema aos gestores, mostrar o método de interatividade com o mesmo e validar se está atendendo as suas expectativas.

Indicador físico Documento Textual descrevendo a opinião dos gestores com algumas consultas realizadas.

Duração 04 semanas Etapa 5: Documentação. Esta etapa visa deixar registrado todo o processo pertinente à

pesquisa científica, desde a descrição do problema, a proposta de uma solução (modelagem),

o desenvolvimento dessa solução, os testes e validação da solução e os resultados finais. A

documentação deve permitir a outros pesquisadores reproduzir a solução e realizar os mesmos

experimentos e testes feitos para sua validação.

16

A t i v i d a d e 5.1 Descrição Redigir o texto do TCC I

Descrição do recurso Qtd.Recursos necessários • Microcomputador PC 01

Pré-requisitos • Nenhum

Metodologia A redação do TCC I se dará ao longo de todo o primeiro semestre de trabalho, através das produções textuais que são os indicadores físicos das atividades já planejadas. O texto final deve estar conciso, claro, bem apresentado e com boa cadência. O objetivo do TCC I é definir bem o tema/problema de pesquisa, justificar sua importância e abrangência e fornecer o referencial.

Indicador físico • Documento textual do TCC I a ser apresentado à banca avaliadora

Duração 04 meses

A t i v i d a d e 5.2 Descrição Redigir o texto do TCC II

Descrição do recurso Qtd.Recursos necessários • Microcomputador PC 01

Pré-requisitos • Etapas de estudo (1) e modelagem (2)

Metodologia A redação do TCC II se dará ao longo de todo o segundo semestre de trabalho, através das produções textuais que são os resultados das atividades já planejadas. O texto final deve estar conciso, claro, bem apresentado e com boa cadência. O objetivo do TCC II é documentar o desenvolvimento da solução proposta, de forma que possa ser reproduzida por outros pesquisadores, deve apresentar a verificação e validação do projeto, e finalmente os resultados alcançados e as conclusões tiradas.

Indicador físico • Documento textual do TCC II a ser apresentado à banca avaliadora

Duração 04 meses

Recursos necessários:

Os recursos necessários à correta execução deste projeto de pesquisa são listados a seguir:

17

Recursos de Hardware: td Disp Local Descrição Q

Microcomputador PC para desenvolvimento, testes e simulações. Configuração mínima: P4, 1.9 MHz, 256MB

AM, 40GB HD, 10/100Eth 01 SIM JUNIOR

R

Recursos de Software: Q Descrição td Disp Local

Ferramentas diversas para desenvolvimento/pesquisa: MS 01 SIM JUNIOR Office, navegador web. Sistema Operacional Windows 2003 Server 01 SIM JUNIOR Microsoft SQL Server 2000 01 SIM JUNIOR

Recursos humanos: ição Q Descr td Disp Local

Gestores da empresa JUNIOR 2 SIM JUNIOR

1.5 CRONOGRAMA

xidade das atividades, bem como o

prazo de cumprimento do TCC estabelecido pelo Curso.

smas, e colchetes indicam uma possível

flexibilidade no prazo de execução de uma atividade.

C a d olvim ra o Tidade 03 / 06 04 / 06 05 / 06 06 / 06

O cronograma de desenvolvimento deste projeto de pesquisa segue o plano de pesquisa

apresentado, e considera os requisitos, recursos e comple

O cronograma de desenvolvimento é separado em duas grandes etapas distintas, o TCC I e o

TCC II, sendo apresentado a seguir. No cronograma, uma seta entre duas atividades indica a

necessidade de precedência (pré-requisito) entre as me

ronogram e desenv ento pa CC I Ativ 07 / 061.1 x X x x x x x x x X x x x x x x x X x X 2.1 2.2 2.3 5.1

1.1 Estudar os conceitos de Data Warehouse, Data Mart, Sistemas de Apoio a Decisão, OLAP, Área de Negócios das empresas;

18

2.1 Identificar as necessidades de informações executivas para tomada de decisão;

2.2 Construir o Modelo Dimensional, baseado em tecnologia OLAP;

2.3 Identificar as fontes de dados;

Cronograma de desenvolvimento para o TCC II Atividade 08 / 06 09 / 06 10 / 06 11 / 06 12 / 06 3.1 x x x x x x x X x X x x X X X x x X x x 3.2 3.3 3.4 4.1 5.2

3.1 Implementar o Modelo Físico do DM;

3.2 Preparar a área de transição de dados (Extração, Transferência, Carga);

3.3 Executar os processos de carga e testes do modelo dimensional;

3.4 Construir as consultas ao DM;

4.1 Validar as consultas pelos gestores;

5.1 Documentar o Projeto. 1.6 OBJETIVOS

1.6.1 Objetivo geral

Desenvolver uma ferramenta de apoio a decisão baseada na tecnologia OLAP para a área

comercial da JUNIOR.

1.6.2 Objetivos específicos

• Estudar os conceitos de Data Warehouse, Data Mart, Sistemas de Apoio a Decisão,

OLAP;

• Estudar diferentes estilos de tomada de decisão;

• Identificar as fontes de dados;

19

• Executar os processos de carga e testes do modelo dimensional;

• Construir as consultas ao DM e

• Validar as consultas pelos gestores;

1.7. ESTRUTURA DO TRABALHO

Este TCC I está divido em quatro capítulos: Introdução, Fundamentação Teórica, Projeto e

Considerações Finais.

A Introdução apresenta uma descrição do contexto, motivação e justificativa do projeto, os

objetivos gerais e específicos, a metodologia e a estrutura do trabalho.

Na Fundamentação Teórica são descritos os conceitos necessários para a realização do

projeto. Neste capítulo, também são apresentadas as principais características que o projeto

deve apresentar.

O Projeto especifica a modelagem do sistema, através da análise funcional e de dados

envolvidos no projeto. Apresenta também a metodologia para a realização do TCC II.

O último capítulo, Considerações Finais, apresenta alguns tópicos relativos á montagem dos

cubos que ainda serão analisados e desenvolvidos durante o TCC II.

20

2. CARACTERIZAÇÃO DA EMPRESA

A JUNIORGPL Tecnologia, compete num mercado global de tecnologia de ponta e destaca-

se a cada dia de forma expressiva no segmento de sistemas para o condicionamento de energia

elétrica. Com sua fábrica instalada em São josé/SC, a empresa é detentora de um amplo Know

How em no-breaks, retificadores, inversores, conversores, fontes e estabilizadores.

A empresa catarinense tem sua posição de destaque consolidada também pelos investimentos

maciços em sistemas de manufatura, distribuição e atendimento, para o lançamento de

produtos cada vez mais inovadores. Tudo isso com o objetivo de atender, da melhor forma, as

necessidades e expectativas dos clientes.

A JUNIORGPL Tecnologia prima pelo compromisso nas relações comerciais plenas e

duradouras com clientes, parceiros e colaboradores, dominando e se responsabilizando por

todas as etapas das operações, abrangendo desenvolvimento, produção, comercialização e

assistência técnica.

2.1 HISTÓRICO

1988 - Início das atividades da JUNIOR Equipamentos Eletrônicos com a venda e assistência

técnica de equipamentos de condicionamento de energia elétrica. Surge a primeira empresa do

grupo JUNIOR.

1991 - A empresa passa a atuar também na área de engenharia elétrica/eletrônica, automação

bancária e terceirização de serviços de infra-estrutura.

1993 - Inauguração da sede própria em Campinas (São José) com 1050m².

1995 - Início das atividades da JUNIOR Indústria e Comércio, com a produção de

estabilizadores e no-breaks de pequeno porte.

1996 - Desenvolvimento e lançamento do Laboratório Didático Móvel. Nasce a

AUTOLABOR.

1997 - Firma acordo técnico com uma empresa americana para representação técnica no

Brasil e países do mercosul de equipamentos para sistemas de TV a cabo. Assim surge a

21

ECS.

Inauguração da 1º fase do complexo industrial em São José com 1500m² de um total previsto

de 6000m². - Prêmio catarinense de Design

1998 - A JUNIOR Indústria e Comércio inicia processo de expansão para os demais Estados

do Brasil, estruturando redes para comercialização e assistência técnica, culminando com a

inauguração de sua primeira filial em São Paulo.

1999 - Certificação ISO 9001. Inicia a comercialização de fontes para redes de Televisão a

cabo (HFC) e firma parceria com grandes empresas de turn Ky para distribuição dos produtos.

- Certificado Gestão do Design.

2000 - Inauguração da nova sede administrativa, 2º fase do complexo industrial. Domina o

mercado brasileiro de fontes e inicia programa de exportação.

2001 - Conquista o primeiro lugar em exportações de no-breaks, exportando seus produtos

para Argentina, Uruguai e Bolívia.

2002 - Apresenta ao mercado uma linha completa de no-breaks para uso externo, voltados

para aplicação em sistemas de telecomunicações e controle de tráfego. Adquiri uma fábrica de

transformadores e consolida seu sistema de qualidade, com a atualização do certificação da

ISO 9001 revisão 2000. - Certificado de Mérito Ambiental

2003 - Firma contrato de OEM com o maior fabricante de centrais telefônicas de pequeno

porte da América Latina e contrato de fornecimento na modalidade "guarda-chuva" com a

maior empresa de telecomunicações do Brasil. Promove o lançamento da Linha de no-breaks

Office e inicia as exportações para o Chile.

2004 - Consolida sua presença nos mercados Argentino, Boliviano e Chileno. Firma contrato

na Argentina com a maior operadora de TV a cabo da América Latina.

Adquiri a empresa GPL Eletro-Eletrônica S.A., empresa com mais de 25 anos de tradição no

fornecimento de no-breaks trifásicos, inversores, retificadores e conversores de frequência.

Nasce a JUNIORGPL Tecnologia. Inicia o processo de ampliação de seu complexo

industrial.

22

3. FUNDAMENTAÇÃO TEÓRICA

Na fundamentação teórica deste projeto busca-se dar embasamento aos conceitos, requisitos e

tecnologias necessárias para o desenvolvimento do SADBO (Sistema de Apoio á Decisão

Baseado em tecnologia OLAP). Para isso, foram selecionados como temas principais da

fundamentação os assuntos: Sistemas de Informação e Tomada de Decisão como Ferramentas

de Gestão, Estruturas dos Bancos de Dados, Modelo Multidimensional, OLAP e Microsoft

SQL Server. Os temas escolhidos são fundamentais para o desenvolvimento do sistema e

foram analisados com base nas suas aplicações para o SADBO.

No primeiro tema, Sistemas de Informação e Tomada de Decisão, apresentam-se os conceitos

necessários para o entendimento do conceito de sistemas de informação. Apresentam-se,

também, os conceitos e características dos sistemas de informação gerencial e sistemas de

apoio à decisão.

No segundo tema, Estruturas dos Bancos de Dados, são expostos os conceitos de bancos

relacionais e multidimensionais, enfatizando a estrutura multidimensional que será utilizada

no desenvolvimento deste projeto. Nesta seção, apresentam-se também os conceitos de data

warehouse e data mart e a importância desses conceitos para o projeto.

No terceiro tema, Modelo Multidimensional, são tratados os passos necessários para a

modelagem dos dados de um banco multidimensional. Na seção, incluem-se os conceitos de

cubos, hipercubos, fatos, medidas, dimensões, agregações e suas respectivas importâncias

para o sistema.

No quarto tema, OLAP, conceitua-se o termo OLAP, mostrando quando uma solução pode

ser considerada OLAP, quais os tipos de tecnologia OLAP existentes e os requisitos

funcionais de uma solução OLAP.

No quinto tema, Microsoft SQL Server, mostram-se as vantagens deste gerenciador de banco

de dados na implementação de bancos multidimensionais e apresenta-se a ferramenta DSS,

um assistente para a implementação de data warehouse e data marts.

23

3.1 SISTEMAS DE INFORMAÇÃO

Nesta seção da fundamentação teórica, abordam-se os conceitos necessários para classificar o

SADBO( Sistema de Apoio a Decisão Baseado em OLAP) como um sistema de informação e

identificar as informações possíveis de serem obtidas com esse sistema.

Os processos decisórios sustentados por Gestão por Resultados, onde Etzioni (1989) observa

que a grande quantidade de informações que os executivos recebem atualmente não refletem

em resultado para uma maior compreensão dos assuntos sobre os quais devem decidir.

Por esse motivo e, também, porque o comportamento dos executivos é mais informal do que

as teorias administrativas supõem (MINTZBERG; QUINN, 2001), questiona-se e investiga-

se, hoje, a eficácia dos Sistemas de Informações Gerenciais e sua efetiva capacidade de

otimizar o desempenho das organizações.

A construção de sistemas de apoio à gestão se dá pela análise da dinâmica organizacional na

perspectiva de seus atores intervenientes, e são esses que darão sentido à informação e não

somente a seus atributos técnicos.

Os profissionais de negócios se vêem constantemente á frente de tecnologias e conceitos que

nem sempre são fáceis de serem absorvidos, pois muitas vezes não possuem conhecimento

técnico na área de informática. Para O' BRIEN (2001), estes usuários devem concentrar seus

esforços em cinco áreas de conhecimento:

• Conceitos básicos. Conceitos comportamentais, técnicos e administrativos fundamentais

sobre os componentes e papéis dos sistemas de informações.

• Tecnologia da informação. Os principais conceitos, avanços e questões gerenciais na

tecnologia da informação.

• Aplicações empresariais. As principais utilizações dos sistemas de informação para as

operações, administração e vantagem competitiva de um empreendimento, incluindo e-

commerce e colaboração, utilizando a Internet, intranets e extranets.

• Processos de desenvolvimento. Como os profissionais de negócios ou especialistas em

24

informação planejam, desenvolvem e implementam os sistemas de informação para

atender as oportunidades de e-business e

• Desafios gerenciais. Os desafios de administrar de forma efetiva e ética as tecnologias,

estratégias e a segurança.

Segundo O' BRIEN (2001), um sistema de informações consiste em cinco recursos principais:

pessoas, hardware, software dados e redes. Afirma, também, que é possível identificar esses

cinco componentes em ação em qualquer tipo de sistema de informação presente no mundo

real. Abaixo apresentam-se exemplos de recursos e produtos destes componentes:

Recursos Humanos

Especialistas – analistas de sistemas, programadores, operadores de computador

Usuários Finais – todos os demais que utilizam sistemas de informação

Recursos de Hardware

Computadores, monitores de vídeo, unidades de disco magnéticos, impressoras

Mídias – formulários de papel, cd’s, dvd’s

Recursos de Software

Programas – programas de sistemas operacionais, programas de planilha eletrônica

Procedimentos – procedimentos de entrada de dados, procedimentos de correção de erros

Recursos de Dados

Descrição de produtos, cadastro de clientes, arquivo de funcionários,

Recursos de redes

Meios de comunicação, acesso a rede e software de controle.

Produtos de Informação

Relatórios administrativos e documentos empresariais utilizando texto e demonstrativos

gráficos.

25

Ambiente Recursos Componentes Objetivos Humanos

Funções Procedimentos Gestão

FIGURA 1 – COMPONENTES DE UM SISTEMA fonte: adaptado de REZENDE (2000)

A figura 1 apresenta exemplos de recursos e produtos dos componentes de um sistema.

Segundo O' BRIEN (2001), os sistemas de informações podem ser classificados ora como sistemas de apoio às operações, ora como sistemas de apoio gerencial.

Abaixo descreve-se as duas classificações de sistemas de informação.

3.1.1 Sistemas de apoio às operações

Os sistemas de apoio às operações não abastecem as necessidades dos gerentes, eles servem

para produzir informações das operações transacionais, eles abastecem os bancos de dados.

Para BRIEN (2001), os sistemas de apoio às operações podem ser divididos em sistemas de

apoio de processamento de transações, sistemas de controle de processos e sistemas

colaborativos.

• Sistemas de apoio de processamento de transações. Processam dados resultantes de

transações empresariais, atualizam banco de dados e produzem documentos empresariais;

• Sistemas de controle de processos. Monitoram e controlam processos industriais e

• Sistemas colaborativos. Apóiam equipes, grupos de trabalho, bem como comunicações e

colaboração entre e nas empresas.

26

3.1.2 Sistemas de apoio gerencial

Os Sistemas de Apoio Gerencial (SAG) são conceituados por O' BRIEN (2001) como

“aqueles que se concentram em fornecer informação e apoio aos gerentes em sua tomada de

decisão eficaz. A tarefa desempenhada por estes sistemas é um tanto complexa”.

Segundo O' BRIEN (2004), os sistemas de apoio gerencial podem ser divididos em três:

Sistemas de informação gerencial, Sistemas de apoio à decisão e Sistemas de informação

executiva.

• Sistemas de informação gerencial. Fornecem informações na forma de relatórios e

demonstrativos pré-estipulados para os gerentes;

• Sistemas de apoio à decisão. Fornecem apoio interativo para o processo de decisão dos

gerentes e

• Sistemas de informação executiva. Fornecem informações críticas elaboradas

especificamente para as necessidades de informação dos executivos.

3.2 PROCESSO DE TOMADA DE DECISÃO

Galbraith e Lawler (1995) concluem que a velocidade na tomada de decisão é particularmente

crítica nos ambientes nos quais os produtos têm uma rotatividade rápida e nas empresas de

serviços nas quais os clientes exigem atendimento imediato. As organizações, que dão poder

especial aos escalões inferiores, podem reagir mais rapidamente às mudanças ambientais e às

mudanças nas exigências dos clientes do que aquelas que são orientadas para o controle.

A forma como as organizações lidam com a informação tem sido considerada, hoje, um dos

principais instrumentos para aumento da velocidade nos processos de tomada de decisão. A

velocidade gerada pela integração das informações no SIGBO demanda das corporações e de

seus administradores novas posturas em relação à elaboração e execução dos atos decisórios.

A agilidade nas tomadas de decisões torna-se mais que fundamental, é responsável pela

sobrevivência de algumas empresas que atuam num mercado competitivo e que vivem de

inovações. Por meio das tecnologias de comunicação e informação foram criadas soluções

para a otimização das etapas de tomadas de decisão das empresas, desde a fase de

27

planejamento até o pleno desenvolvimento do projeto (GALBRAITH e LAWLER, 1995).

Drucker (2001) considera que os executivos eficazes não tomam muitas decisões,

concentram-se no que é importante. Tentam tomar as poucas decisões importantes no nível

mais alto do entendimento conceitual. Procuram localizar o que é invariável em uma situação,

pensar no que é estratégico e genérico, em vez de “resolver problema”. Querem saber do que

trata a decisão e quais as realidades subjacentes que ela tem que satisfazer. Querem impactos,

em vez de técnicas. A decisão eficaz é por si só baseada no mais alto nível do entendimento

conceitual, o compromisso com a ação deve estar o mais próximo possível da capacidade das

pessoas encarregadas em cumpri-la. Executivos eficazes sabem que a tomada de decisão tem

seu próprio processo sistemático e seus próprios elementos claramente definidos.

O conceito de decisão está bastante relacionado à solução de problemas (análise de

problemas). Para STRYKER (2001), problema é o desvio de algum padrão ou desempenho

desejado; a decisão é uma escolha do melhor caminho para corrigir a causa de um problema, e

todo problema tem somente uma causa; e o processo de gradação, partindo de um problema

até sua causa, a qual, por sua vez, pode ser também um problema a ser resolvido.

Sem uma especificação precisa e análise cuidadosa, apenas um exercício inútil de adivinhação

e sorte poderia ter chegado à explicação provável do problema. Cabe, ainda, discutir que as

análises tradicionais de sistemas gerenciais pautam-se, como cita STRYKER (2001), em

desvio de padrão ou desempenho, este resultado não necessariamente enquadra-se como

problema. Porém, poderá ser um resultado acima dos padrões estabelecidos, que neste caso

poderá ser uma oportunidade.

Portanto, leva-se tempo para transformar os hábitos de raciocínios de um gerente em uma

abordagem sistemática de análise de problemas. Um modelo de informações gerenciais, que

demonstre o processo de decisão da organização, vem facilitar o gestor na dinâmica de

solução dos diversos problemas e níveis de decisão. Assim, quanto aos tipos de problemas,

sob o ponto de vista da tomada de decisão, podem ser classificados em três categorias:

problemas estruturados, semi-estruturados e não-estruturados (TURBAN e ARONSON,

1998).

Um problema é considerado estruturado ou bem definido se sua definição e fases de operação

para chegar aos resultados desejados estiverem claros e sua execução repetida for sempre

28

possível. Os problemas semi-estruturados são problemas com operações bem conhecidas, mas

que contêm algum fator ou critério variável que pode influir no resultado. Nos problemas não-

estruturados, tanto os cenários, como o critério de decisão, não estão fixados ou conhecidos a

priori.

Além disso, a decisão sobre qualquer um dos três tipos de problemas (estruturados, semi-

estruturados ou não-estruturados) pode ser diferenciada por nível de decisão: estratégico (em

geral, decisão para dois a cinco anos); tático (decisão para alguns meses a até dois anos);

despacho ou liberação (decisão para algumas horas ou alguns dias) (SHIMIZU, 2001).

Existem superposições entre tipos de problemas e os níveis de decisão, mas a

responsabilidade de decisão cabe a grupos distintos de decisores (Figura 2).

FIGURA 2 - CLASSIFICAÇÃO DOS PROBLEMAS DE DECISÃO.

CCOONNFFLLIITTOO DDEE OOBBJJEETTIIVVOOSS EE AAMMBBIIGGÜÜIIDDAADDEE

IINNCCEERRTTEEZZAA

MMOODDEELLOO RRAACCIIOONNAALL RREEGGRRAASS EE RROOTTIINNAASS

BBEEMM EESSTTRRUUTTUURRAADDAASS MMOODDEELLOO PPOOLLÍÍTTIICCOO

OOBBJJEETTIIVVOOSS MMÚÚLLTTIIPPLLOOSS EE CCOONNFFLLIITTOOSS DDEE IINNTTEERREESSSSEE

MMOODDEELLOO PPRROOCCEESSSSUUAALL MMÚÚLLTTIIPPLLOOSS CCEENNÁÁRRIIOOSS,,

OOBBJJEETTIIVVOOSS EE AALLTTEERRNNAATTIIVVAASS PPRROOCCEESSSSOO SSEEMMII--

EESSTTRRUUTTUURRAADDOO OORRIIEENNTTAADDOO AA OOBBJJEETTOO

MMOODDEELLOO AAMMBBÍÍGGUUOO PPRROOBBLLEEMMAA AANNÁÁRRQQUUIICCOO

IIMMPPRREECCIISSOO ((FFUUZZZZYY))

MMAALL FFOORRMMUULLAADDOO

Fonte: Adaptado de CHOO, C. W. The knowing organization. Oxford: Oxford University Press, 1998. As classificações de problemas de decisão passam por representação em modelos. O

entendimento de modelo para o estudo define-se como um processo de racionalização e

simplificação de uma realidade. Então, modelo não é um mapa da realidade, mas modelos

permitem mapear realidade (MURAKAMI, 2003).

Modelo Racional - Decisão com certeza; Decisão com otimização; Decisão que usa

heurísticas e meta-heurísticas; Decisão na Administração da Produção; Decisão em

planejamento de cadeia de suprimentos.

29

Modelo Processual - Decisão em situação de incerteza ou risco; Decisão que usa

processos estocásticos.

Modelo Político - Decisão com incerteza, múltiplos objetivos e múltiplos cenários;

Decisão com competidor ou com conflito: Teoria do Jogo, Jogo de Guerra e Jogo de

Empresas Virtuais; Decisão em Portifólio de Ações; Decisão em Problemas da TI.

Modelo Ambíguo - Modelo da Lata de Lixo: decisão por vista grossa e por passagem;

Decisão pelo voto; Decisão que usa Sistemas Especialistas Difusos.

O posicionamento do Modelo de Informações em estudo nessa pesquisa, diante da

classificação dos problemas decisão, enquadra-se nos conceitos do Modelo Racional. Ainda,

esses modelos são sustentados por um processo de tomada de decisões estruturado, onde

Drucker (2001) define as seguintes etapas envolvidas no processo de tomada de decisões:

1. Classificar o problema - O responsável pela tomada de decisões eficazes pergunta: esse é

um sintoma de uma desordem fundamental ou um acontecimento isolado? O que for

genérico precisa ser respondido por uma regra, um princípio. E acontecimentos

excepcionais só podem ser encarados como tal, e à medida que aparecem.

2. Definir o problema – Uma vez que um problema tenha sido classificado como genérico ou

único, é normalmente muito fácil de definir. “de que se trata?”, “o que é pertinente aqui?”,

“qual é a explicação para essa situação?” Questões como essas são familiares, mas

somente os verdadeiros tomadores de decisão eficazes estão atentos para o fato de que o

perigo, nesta etapa, não é a definição incorreta; é aquela definição plausível, mas

incompleta. Há apenas uma garantia para não se tornar prisioneiro de uma definição

incompleta: checá-la novamente e mais uma vez em relação a todos os fatos que possam

ser observados, e descartar uma definição no momento em que ela deixar de abranger

qualquer um deles. Finalmente, voltam e repensam os problemas sempre que identificam

algo atípico, quando se deparam com fenômenos inexplicados, ou quando o curso dos

acontecimentos se desvia, mesmo que em detalhes das expectativas.

3. Especificar a resposta ao problema - Definir as especificações que a decisão tem que

consumar. Quais são os objetivos que a decisão tem que alcançar? Quais as metas

mínimas que deve obter? Quais são as condições que ela tem que satisfazer? Em ciência,

essas condições são conhecidas como “condições-limite”. Uma decisão, para ser

30

eficaz, precisa satisfazer às condições-limite.

4. A decisão - Decidir o que é “certo”, em vez do que é aceitável, de modo que atenda às

condições-limite;

5. A ação - Incorporar à própria decisão a ação, para que ela seja cumprida;

6. O feedback - Testar a validade e a eficácia da decisão em relação ao rumo verdadeiro dos

acontecimentos. A monitoração e a transmissão das informações têm de vir embutidas na

decisão para facilitar verificações contínuas, diante dos reais acontecimentos, das

expectativas que estão por trás das decisões. Os tomadores de decisão precisam de

informação organizada como feedback, eles precisam de relatórios e de estimativas.

Afirma, ainda, Drucker (2001), que a tomada de decisão é apenas uma das tarefas de um

executivo. Geralmente, consome uma pequena fração do seu tempo. Mas tomar as decisões

importantes é tarefa específica dos executivos. Somente um executivo toma esse tipo de

decisão.

Um executivo eficaz toma essas decisões como um processo sistemático com elementos

claramente definidos e em uma seqüência de etapas distinta. Na verdade, esperar que ele tome

decisões significativas e de impacto positivo na organização como um todo, seu desempenho

e seus resultados, caracteriza o executivo eficaz.

Na abordagem de Russo e Schoemaker (1993), quanto aos elementos do processo de tomada

de decisão, dividem em quatro elementos principais, onde os mesmos afirmam que todo bom

tomador de decisões deve conscientemente ou não, passar por cada uma deles, ou seja:

1. Estruturar – definir o que deve ser decidido e determinado que critérios o fariam preferir

uma opção em relação à outra;

2. Colher informações – procurar fatos reconhecíveis como estimativas razoáveis sobre os

“não-reconhecíveis”, necessários para tomar a decisão;

3. Conclusões – uma estruturação perfeita e boas informações não garantem uma decisão

correta. As pessoas não podem tomar conscientemente boas decisões usando critérios

intuitivos, mesmo tendo dados excelentes;

4. Aprender com feedback – manter o acompanhamento daquilo que se esperava

31

que acontecesse, resguardando-se sistematicamente das explicações egoístas e

assegurando-se de rever as lições produzidas pelo feedback na próxima vez que surgir

uma decisão semelhante.

O que se destaca nessa abordagem em relação às demais são os elementos de estruturação e o

aprendizado com o processo de feedback.

Hammond (1998), ressaltam “as armadilhas ocultas na tomada de decisão”. Ou seja, as más

decisões geralmente podem ser explicadas pela maneira como as decisões são tomadas. Onde

as alternativas não estão claramente definidas, a informação correta não foi conseguida, os

custos e benefícios não avaliados com precisão. Mas às vezes a falha não está no processo de

tomada de decisão, mas sim na mente do responsável pela tomada de decisão. A maneira pela

qual o cérebro humano funciona pode sabotar as escolhas que fizemos. John Hammond,

Ralph Keeney e Howard (1998) examinam oito armadilhas psicológicas que são

particularmente possíveis de afetar o modo como tomamos decisões de negócios, são elas:

1. Armadilha da ancoragem leva-nos a atribuir um peso desproporcional à primeira

informação que recebe-se;

2. Armadilha do status quo impele-nos a manter a situação atual – mesmo quando existem

alternativas melhores;

3. Armadilhas dos fundos perdidos nos levam a perpetuar erros do passado;

4. Armadilha da confirmação das evidências faz com que procuremos informações para

sustentar uma preferência já existente e para descartar informações contraditórias;

5. Armadilhas do enquadramento ocorrem quando se descreve de forma inapropriada um

problema, minando o processo de tomada de decisão;

6. Armadilha da confiança excessiva faz com que superestimemos a exatidão de nossos

prognósticos;

7. Armadilha da prudência torna-nos supercautelosos ao fazer avaliações sobre

acontecimentos incertos; e,

8. Armadilha da recordação leva-nos a atribuir pesos indevidos aos acontecimentos recentes

32

mais impressionantes.

A melhor proteção contra as armadilhas psicológicas – isoladamente ou combinadas – é a

prevenção. Ou seja, não negligenciar a existência dessas armadilhas no contexto das decisões.

Pois, esses fatores poderão influenciar no uso de um modelo de informação focado para o

processo de decisão. Uma forma coerente de se proteger e tomar decisões sem a preocupação

das armadilhas psicológicas é utilizar ferramentas de BI (Business Intelligence) que baseadas

em informações técnicas e exatas podem ajudar o executivo a tomar decisões calçado em

bases sólidas.

3.3 BUSINESS INTELLIGENCE

A história do Business Intelligence, segundo Serra (2002), teve início na década de 70,

quando alguns produtos de BI foram fornecidos para os executivos. O problema destes

produtos era que exigiam muito esforço de programação, além de não disponibilizar

informação em tempo hábil nem de forma flexível, além de um custo elevado de implantação.

O’Brien (2001) amplia a discussão, e considera que sistemas de informações para aplicações

gerenciais combinam os trabalhos teóricos: de ciência da computação, ciência da

administração e pesquisa operacional com uma orientação prática para construção de sistemas

e aplicações. Ainda, o autor ressalta a adoção de questões de comportamento, levantadas pela

sociologia, economia e psicologia.

Portanto, o conceito de BI em síntese, passa pelo desafio da disponibilização de ferramentas e

dados, para que o nível gerencial de uma organização possa detectar tendências e tomar

decisões eficientes no tempo correto.

Assim, Laudon e Laudon (1999) destacam que a revolução do conhecimento e da informação

começou na virada do século XX e evolui gradativamente. Os autores observam que com o

crescimento da economia da informação, vem ocorrendo um declínio no número de

trabalhadores rurais e de operários de fábricas. E paralelamente, ocorre aumento dos

trabalhadores de escritório, que produzem valor econômico usando conhecimento e

informação. Ou seja, conhecimento e informações estão se tornando à base para novos

serviços e produtos.

A tendência da mudança do perfil do trabalhador tem ampliado o escopo de sistemas de

33

informação, conforme apresenta o Quadro 1.0. Observa-se que com a evolução do tempo, os

sistemas de informação passaram a ter um papel de maior apoio nas organizações. Assim,

expandindo-se de um papel mais técnico inicialmente para afetarem o controle e o

comportamento administrativo, impactando mudanças sobre os usuários finais e gerentes de

uma organização.

PPEERRÍÍOODDOO CCAARRAACCTTEERRÍÍSSTTIICCAASS DDOOSS SSII PPAAPPEELL DDOOSS SSII NNOOSS NNEEGGÓÓCCIIOOSS

1950 a 1960

Processamento de Dados (ênfase Mudanças Técnicas)

Sistemas de Processamento Eletrônico de Dados - Processamento de transações, manutenção de registros e aplicações contábeis tradicionais.

1960 a 1970

Relatórios Administrativos (ênfase Controle Gerencial)

Sistemas de informação gerencial - Relatórios administrativos de informações pré-estipuladas para apoio a tomada de decisão.

1970 a 1980

Apoio à Decisão (ênfase Controle Gerencial)

Sistemas de Apoio à Decisão - Apoio interativo e ad hoc ao processo de tomada de decisão gerencial.

1980 a 1990

Apoio Estratégico ao Usuário Final (ênfase Atividades Institucionais Essenciais)

Sistemas de computação do usuário final – Apoio direto à computação para a produtividade do usuário final e colaboração de grupos de trabalho. Sistemas de informação executiva (EIS) – Informações críticas para a alta administração. Sistemas especialistas – Conselho especializado baseado no conhecimento para os usuários finais. Sistemas de informação estratégica – Produtos e serviços estratégicos para vantagem competitiva.

a partir de 1990

Empresa e Conexão em Rede Global (ênfase Atividades Institucionais Essenciais)

Sistemas de informação interconectados – Para o usuário final, a empresa e a computação, comunicações e colaboração interorganizacional, incluindo operações e administração globais na Internet, intranets, extranets e outras redes empresariais e mundiais.

Quadro 1.0: Evolução do Papel dos Sistemas de Informação nos Negócios. Fonte: Adaptado de Laudon e Laudon (1999) e O’Brien (2001).

As organizações impulsionadas pelos avanços tecnológicos e novas necessidades passam a

desenvolver um novo tratamento da informação, onde Barbieri (2001) destaca as abordagens:

Gerência do Conhecimento (KM - Knowledge Management), que objetiva estabelecer

uma aproximação integrada e colaborativa para capturar, criar, organizar e usar todos os

ativos de informação da empresa. O BI é mais compartimentada, objetiva e focada em

estruturas definidas. Já o KM trabalha o ativo de informações, independentemente a sua

forma, estrutura e domínio (em suma, ênfase nos documentos);

Inteligência Competitiva (CI – Competitive Intelligence), cuja idéia básica é explorar

informações detalhadas sobre concorrentes e o mercado, buscando a atração do cliente

para sua corporação. De forma simples, pode-se entender CI como um BI aplicado ao

mundo fora das fronteiras empresariais, focado em informações textuais e factuais a

respeito dos movimentos do mercado e dos concorrentes.

Desta forma, o processo de inteligência segue os níveis hierárquicos, conforme a Figura 3.

34

Assim é nesse cenário de dados e novas estirpes (informações e conhecimentos), trabalhadas

interna e externamente na empresa através de redes corporativas, que o processo de decisão se

fundamenta, ou seja, voltado para inteligência apoiando a vantagem competitiva.

Ou seja, voltado para inteligência apoiando a vantagem competitiva.

VVAANNTTAAGGEEMM

CCOOMMPPEETTIITTIIVVAA

Elaboração

Aprendizagem

Experiência

DDAADDOOSS

IINNTTEELLIIGGÊÊNNCCIIAA

SS ÍÍ NN TT EE SS EE

CCOONNHHEECCIIMMEENNTTOO

AANNÁÁLL II SSEE

IINNFFOORRMMAAÇÇÃÃOO

PP RR OO CC EE SS SS AA MM EE NN TT OO

FIGURA 3: DIAGRAMA DOS NÍVEIS HIERÁRQUICOS DA INFORMAÇÃO.

Fonte: Adaptado Herring apud Wanderley (1999) e Moresi (2000).

A inteligência é o resultado de um processo que começa com a coleta de dados. Esses dados

são organizados e transformados em informação, que, depois de analisada e contextualizada,

transforma-se em inteligência. Esta, por sua vez, aplicada a processos de decisão gera

35

vantagens competitivas para a organização. Os dados são armazenados e estruturados em

ferramentas denominadas banco de dados.

3.4. ESTRUTURAS DOS BANCOS DE DADOS

Neste ítem abordam-se as principais diferenças entre a estrutura relacional de um banco de

dados e a estrutura multidimensional. Por tratar-se de uma estrutura complexa e fundamental

para a realização deste projeto, aborda-se a estrutura multidimensional com um pouco mais de

profundidade, mostrando-se os detalhes necessários para a implementação deste tipo de

estrutura.

Desde a introdução dos bancos de dados relacionais, os analistas estão acostumados a

construir bancos de dados normalizados para sistemas operacionais/transacionais,

decompondo os dados no seu menor nível, evitando assim a duplicidade da informação, ou

seja, o foco da normalização é a eficiência do armazenamento. Quando se trata de data

warehouse é necessária uma mudança na forma de modelar os dados, uma vez que, o objetivo

passa a ser a performance das consultas, isto é, o acesso e recuperação dos dados.

O modelo relacional, também conhecido como modelo ER (Entidade-Relacionamento), é a

mais popular estrutura de bancos de dados. O’Brien (2001) explica que, neste modelo, todos

os elementos dos dados dentro do banco de dados são armazenados na forma de tabelas

simples. Os pacotes de sistemas de gerenciamento de bancos de dados baseados no modelo

relacional podem vincular elementos de dados de várias tabelas para fornecer informações

para os usuários. Esta estrutura de dados é bastante propícia para solucionar problemas de

espaço em disco e também de performance.

A questão fundamental é que as novas tecnologias de consulta e análise de dados requerem

recursos que a estrutura relacional não podem oferecer.

3.4.1 Estrutura multidimensional

A estrutura multidimensional de bancos de dados, que também pode ser chamada apenas de

estrutura dimensional, é uma variação do modelo relacional que utiliza estruturas

multidimensionais para organizar os dados e expressar as relações entre os dados. É possível

visualizar as estruturas multidimensionais como cubos de dados e cubos dentro de cubos de

36

dados. Cada face do cubo é considerada como uma dimensão dos dados (O’BRIEN, 2001).

Para Kim (1995), não existem segredos ou soluções mágicas para que se converta um modelo

ER em um modelo dimensional. O gerenciador de banco de dados utilizado no modelo

dimensional é bastante diferente do tradicional que gerencia modelos ER, sendo que no

primeiro são facilitadas a navegação e as consultas. O número de tabelas é reduzido pelo fato

de existirem dimensões ligadas a uma tabela de fatos central, logo o gerenciador pode

trabalhar com um número menor de chaves.

Kim (1995) cita ainda, que é útil ter uma análise de ER antes de embarcar em um projeto

dimensional porque a equipe de data warehouse entenderá melhor os dados desta forma.

Porém, a equipe tem que fixar à parte o diagrama ER durante o processo de projeto do data

warehouse porque a modelagem dimensional tem que proceder de uma perspectiva de

usuário, em lugar de uma perspectiva de dados.

O’Brien (2001) cita uma vantagem dos bancos de dados multidimensionais:

“Um dos maiores benefícios dos bancos de dados multidimensionais é que eles são uma maneira compacta e inteligível de visualizar e manipular elementos de dados que possuem muitas inter-relações. Por isso, os bancos de dados multidimensionais se tornaram a estrutura mais popular para os bancos de dados analíticos que suportam aplicações OLAP, nas quais se esperam respostas rápidas para consultas comerciais complexas” (O’BRIEN, 2001).

3.4.2 Armazéns de dados

Segundo Laudon e Laudon (1999) , um grande problema que as empresas enfrentam é o

armazenamento de dados em muitos sistemas diferentes, o que a gera a incapacidade de

proporcionar uma visão consolidada de informações utilizáveis por toda a empresa. Para ele, a

solução para este problema é construir um armazém de dados (data warehouse).

Para Petkovic (1999), o Data Warehouse é um armazém de dados em que os usuário finais

podem executar consultas ad-hoc e relatórios para analisar dados existentes, sendo que as suas

propriedades mais importantes são:

• Operações de gravação (carga) periódicas com consultas baseadas em um grande

número de linhas;

• Pequeno número de usuários e

37

• Tamanho grande de dados armazenados em um banco de dados.

Laudon e Laudon (1999) , complementa com a seguinte afirmação:

“Um armazém de dados é um banco de dados que consolida dados extraídos de diversos sistemas de produção e operacionais em um grande banco de dados que pode ser utilizado para relatórios e análises gerenciais. Os dados dos sistemas de processamento das principais transações da organização são reorganizados e combinados com outras informações, inclusive dados históricos, de modo que possam ser usados para a tomada de decisões e análise gerenciais” (LAUDONE LAUDON, 1999).

Machado (2000) corrobora esta idéia, afirmando que um data warehouse representa uma

grande base de dados, capaz de integrar, de forma concisa e confiável, as informações de

interesse para a empresa, que se encontram espalhadas pelos sistemas operacionais e em

fontes externas, para posterior utilização nos Sistemas de Apoio à Decisão.

Laudon e Laudon (1999) explica que os data warehouse muitas vezes dispõem de recursos

para remodelar os dados. Um banco de dados relacional permite visões em duas dimensões,

como vendas por região. Uma visão multidimensional de dados permite que os usuários

vejam os dados em mais de duas dimensões (vendas por região por trimestre, por exemplo). A

Figura 4 apresenta uma representação de um data warehouse.

38

FIGURA 4 - MODELO DE DATA WAREHOUSE

Fonte: Adaptado de Machado (2000)

A FIGURA 4, apresentada anteriormente, mostra como os dados de um data warehouse

devem ser cuidadosamente montados a partir de diferentes origens. Segundo Petkovic (1999),

os dados extraídos são convertidos para um esquema intermediário e movidos para uma área

de trabalho temporária. Para a extração dos dados, são necessárias ferramentas que extraiam

exatamente os dados que devam ser armazenados no data warehouse. No próximo passo, a

limpeza dos dados garante a integridade daqueles que serão armazenados no banco de dados

alvo. A limpeza deve ser feita em entradas incorretas nos campos de dados. O último passo

envolve um processo de validação que especifica os dados de acordo com a maneira pela qual

o usuário final deverá vê-los e acessá-los.

Petkovic (1999) explica que, além de ter carregamento de dados executados em intervalos

regulares (normalmente, diariamente), os data warehouse são de somente leitura. Os dados

são reunidos de diferentes fontes, limpos (tornados coerentes) e carregados em um banco de

39

dados chamado data warehouse ou data mart (que será explicado na próxima seção).

Petkovic (1999) afirma ainda que, como os sistemas de data warehouse são usados para obter

informações, o número de usuários que utilizam simultaneamente tal sistema é relativamente

pequeno. No entanto, como os data warehouse devem controlar dados históricos (os sistemas

de data warehouse fazem comparações entre dados reunidos em diferentes períodos de

tempo), o volume de dados armazenados é muito grande (Alguns contêm até 500GB ou mais).

Além disso, como os data warehouse devem abranger a empresa, normalmente a

implementação leva de dois a três anos.

3.4.3 Características de um Data Warehouse

Segundo Inmon (1997), Data Warehouse é um conjunto de dados baseados em assuntos,

integrado, não-volátil, e variável em relação ao tempo e de apoio às decisões gerenciais. De

acordo com Oliveira (1998) estas características poderão ser descritas de forma mais

detalhada:

a) Orientados por assunto: os dados devem se orientar para os maiores assuntos da

organização, como por exemplo: clientes, produtos, atividades, contas. O DW é criado

baseando-se em algum tema específico que a empresa precisa analisar. Estes assuntos

podem ser subdivididos para uma melhor compreensão ou diminuir a complexidade;

b) Integrados: segundo Oliveira (1998), o DW recebe os dados de um grande número de

fontes. Cada fonte contém aplicações, que tem informações que são incompatíveis com

aplicações encontradas em outras fontes. O filtro é a tradução necessária para

transformar as muitas fontes de dados consistente em uma base, este processo de

extração é chamado de integração. Pode-se tomar como exemplo o dado sexo. Enquanto

um determinado sistema do financeiro armazena sexo Masculino como 1 e Feminino

como 2, um outro sistema do faturamento na mesma empresa pode armazena-los como

M e F. Faz-se necessário, portanto, integrá-los conforme um dos dois modos;

c) Não-voláteis: define que os dados no sistema operacional são manipulados e acessados

um de cada vez. Já em um DW é diferente, os dados são carregados e acessados em

massa, e as atualizações ocorrem de tempos em tempos;

d) Histórico: Os dados do sistema operacional podem ou não conter algum elemento de

tempo, já para o DW, o elemento tempo é fundamental. Enquanto em sistemas

operacionais, os dados permanecem por um curto prazo de tempo, um DW armazena

40

informações de vários anos (5 a 10 em média). Este histórico é que possibilita uma

análise gerencial do comportamento do negócio.

3.4.4 Granularidade e particionamento

Segundo Oliveira (1998), granularidade envolve o nível de detalhe para sumarização de cada

unidade de dado. Mais detalhe é caracterizado por um baixo nível de granularidade, enquanto

menos detalhes caracteriza um alto nível de granularidade. A decisão sobre o nível de

granularidade afeta tanto o volume de dados contido no DW, quanto o tipo de pesquisa que

pode ser respondida.

Em um projeto de DW com um baixo nível de granularidade, pode-se responder a qualquer

consulta, contudo será necessário a utilização de uma grande quantidade de recursos para

armazenar e percorrer todos os registro até atingir a resposta solicitada. Em um DW com um

nível mais alto de granularidade, são necessários bases de dados menores, sem contar a

redução de tempo e processamento para atender determinada solicitação. Porém, à medida

que o nível de granularidade aumenta, há uma diminuição da possibilidade de utilização dos

dados para atender às consultas, fato que pode ser verificado na figura 5. No entanto, no

ambiente de DW é mais comum ocorrer a utilização de uma visão de conjunto dos dados,

pois, dificilmente um evento isolado é examinado.

41

FIGURA 5 – NÍVEIS DE GRANULARIDADE Fonte: INMON (1997)

Quando uma organização possui grandes quantidades de dados no DW, faz sentido pensar em

dois (ou mais) níveis de granularidade. De acordo com Inmon (1997), com a criação de dois

níveis de granularidade é possível atender a todos tipos de consultas, pois a maior parte do

processamento analítico dirige-se aos dados levemente resumidos que são compactos e de

fácil acesso. Para ocasiões em que um maior nível de detalhe deve ser investigado, existe o

nível de dados históricos. O acesso aos dados do nível histórico é caro, incômodo e complexo,

mas caso haja necessidade de alcançar esse nível de detalhe, ele existirá.

Segundo Inmon (1997), depois da granularidade o particionamento é a questão mais

importante em um projeto de DW. Refere-se à repartição dos dados em unidades físicas

separadas que podem ser tratadas independentemente

De acordo com Oliveira (1998), quanto menores as unidades físicas, mais rápido o acesso.

Uma unidade de dado é única para cada partição. Particionamento é acompanhado da

aplicação dos seguintes critérios: data, linha de negócios, geografia, unidade organizacional e

todos os anteriores. Inmon (1997) acrescenta que no DW, as questões referentes ao

particionamento de dados não enfocam a necessidade de o particionamento ser feito ou não,

mas como ele deve ser feito.

3.4.5 Data Mart

Devido às desvantagens da implementação de um data warehouse, muitas empresas começam

com uma solução menor, chamada de data marts.

Machado (2000) explica que os Data Marts são subconjuntos de dados de um data

warehouse. Nesta arquitetura, os dados do data mart são direcionados a um departamento ou

a uma área específica do negócio.

Para Petkovic (1999), os data marts são armazenamentos de dados que incluem todos os

dados departamentais, portanto, permitem aos usuários acessar dados relativos apenas a uma

parte de sua organização. Por isso, um data mart tem várias vantagens em relação a um data

42

warehouse:

• Área de aplicação mais restrita;

• Tempo de desenvolvimento e custo menores;

• Manutenção de dados mais fácil;

• Desenvolvimento de baixo para cima (Bottom-Up).

Petkovic (1999) afirma ainda que, o tempo gasto no desenvolvimento de um data mart é, em

média, de três a cinco meses. Por esses motivos, o desenvolvimento de um data mart é

preferido, especialmente se esse for o primeiro projeto de data warehouse de uma

organização.

Dentre vários tipos de implementação das arquiteturas dos data marts, Machado (2000)

também cita a implementação de um data mart no modelo Bottom-Up:

“Este tipo de implementação permite que o planejamento e o desenho dos Data Marts possam ser realizados sem esperar que seja definida uma infra-estrutura corporativa para Data Warehouse na empresa. Essa infra-estrutura não deixará de existir, só que ela poderá ser implementada incrementalmente conforme forem sendo realizados os Data Marts” (MACHADO, 2000).

Petkovic (1999) explica que, se uma organização projetar e desenvolver vários data marts,

será possível unificá-los em um grande data warehouse.

Machado (2000) ressalta que um dos grandes problemas desta implementação é a falta de um

gerenciador que garanta padrões únicos de metadados(responsáveis pela definição das

estruturas e dos processos de transformação desejados), mesmo com a independência dos data

marts:

“A dificuldade em garantir essa padronização é responsável pela falha na elaboração incremental do Data Warehouse. Podem ocorrer redundâncias de dados e inconsistências entre os Data Marts, que podem ser minimizadas por um planejamento, monitoração e estabelecimento de regras de desenvolvimento (metodologias). Com uma estrutura de múltiplos Data Marts, o processo de extração pode tornar-se crítico na interferência junto aos sistemas transacionais” (MACHADO, 2000).

Machado (2000), lembra da importância de escolher o tipo correto de implementação:

“A abordagem da implementação escolhida é uma decisão que pode causar dramáticos impactos quanto ao sucesso de um projeto de Data Warehouse.

43

Muitas variáveis afetam a escolha da implementação e arquitetura, entre elas o tempo para a execução do projeto, o retorno do investimento a ser realizado, a velocidade dos benefícios da utilização das informações, a satisfação do usuário executivo e os recursos necessários à implementação de uma arquitetura” (MACHADO, 2000).

Petkovic (1999) explica que como o desenvolvimento de data warehouse tem por base as

consultas que operam em um grande volume de dados, que não são simples e levam grandes

períodos de tempo para serem implementados, tabelas altamente normalizadas não são

convenientes para o projeto de data warehouse, pois o objetivo desses sistemas é

significativamente diferente, ou seja existem poucas transações concorrentes, e cada transação

acessa um número muito grande de registros. Assim, Petkovic (1999) afirma que, os data

warehouse não podem usar o modelo ER, pois este é usado para projetar bancos de dados que

não sejam redundantes. O modelo lógico usado para o projeto de data warehouse é chamado

de modelo dimensional (ou multidimensional).

3.5 MODELO MULTIDIMENSIONAL

Nesta seção, aborda-se os passos necessários para a modelagem multidimensional dos dados,

outro ponto fundamental para o desenvolvimento do SIGBO. Mostra-se também, como este

modelo pode ser apresentado e as operações que ele deve oferecer.

Petkovic (1999), comenta a grande diferença entre a modelagem ER e a modelagem

multidimensional:

“Em contraste com os bancos de dados operacionais que usam modelos ER para seu projeto, o projeto dos data warehouse é melhor realizado usando-se um modelo dimensional. Esses dois modelos apresentam diferenças significativas: se você já estiver familiarizado com o modelo ER, a melhor maneira de aprender e usar o modelo dimensional será esquecer tudo sobre o modelo ER e começar o modelagem desde o início” (PETKOVIC, 1999).

Petkovic (1999) explica que, na modelagem multidimensional, todo modelo é composto de

uma tabela que armazena medidas e várias outras que descrevem as dimensões. A primeira é

chamada de tabela de fatos e as últimas, tabelas de dimensão.

Machado (2000) corrobora essa idéia, afirmando que um modelo multidimensional possui três

elementos básicos: Fatos, Dimensões e Medidas.

44

Petkovic (1999) explica que, cada tabela de dimensão normalmente tem uma chave primária

de uma parte e vários outros atributos que descrevem detalhadamente essa dimensão. Por

outro lado, a chave primária da tabela fato é a combinação das chaves primárias de todas as

tabelas da dimensão. Por esse motivo, a chave primária da tabela de fato é constituída de

várias chaves estrangeiras (o número de dimensões também especifica o número de chaves

estrangeiras na tabela de fato).

3.5.1 Fatos e medidas

Segundo Machado (2000), em um modelo multidimensional, fato é uma coleção de itens de

dados, composta de dados de medidas e de contexto. Cada fato representa um item de

negócio, uma transação de negócio ou um evento de negócio, e é utilizado para analisar o

processo de negócio de uma empresa. Um fato é evolutivo, muda suas medidas com o tempo,

podendo ser sempre questionado sobre esta evolução ao longo de um espaço de tempo.

Para Petkovic (1999), outra diferença na natureza dos dados em uma tabela de fato e nas

tabelas de dimensão correspondentes é que a maioria das colunas da primeira são numéricas e

aditivas, pois tais podem ser usados para executar os cálculos necessários. Por outro lado, as

colunas de tabelas dimensão são strings que contêm descrições textuais da dimensão.

Medidas são os atributos numéricos que representam um fato, representam à performance de

um indicador de negócios relativo às dimensões que participam desse fato. Uma medida é

determinada pela combinação das dimensões que participam de um fato, e estão localizadas

como atributos de um fato (MACHADO, 2000).

A figura 6 demonstra um exemplo de uma tabela de fato com suas ligações as devidas

dimensões.

45

FIGURA 6 – TABELA DE FATO E DIMENSÕES Fonte: RUBINI (1999)

3.5.2 Dimensões

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 multidimensional simplifica para os

usuários o processo de formular pesquisas ou "queries" complexas, criar relatórios, efetuar

análises comparativas, e visualizar subconjuntos (slice) de maior interesse.

As dimensões são agrupadas em hierarquias, cada hierarquia possui níveis e cada nível possui

atributos.

Dentro de cada dimensão de um modelo OLAP, os dados são organizados em uma hierarquia

que define diferentes níveis de detalhe. Por exemplo, dentro da dimensão tempo, você poderá

ter uma hierarquia representando os níveis anos, meses, e dias. Da mesma forma, a dimensão

região poderá ter os níveis país, região, estado e cidade. Assim, um usuário visualizando

dados em um modelo OLAP irá navegar para cima (drill up) ou para baixo (drill down) entre

níveis para visualizar informação com maior ou menor nível de detalhe sem a menor

dificuldade.

A Figura 7 demonstra um exemplo de uma dimensão dividida em vários níveis, como por

exemplo o município dentro da dimensão estado.

FIGURA 7 – DIMENSÃO E NIVEL

Como querem ver as informações?

46

Dimensões:

Data Competência (Total Período, Ano, Trimestre, Mês, Dia)

Procedimento (Total Procedimento, Procedimento)

Fonte Pagadora (Total Fonte Pagadora, Grupo, Fonte Pagadora)

3.5.3 A Visualização de um modelo multidimensional (Cubo)

Modelos Multidimensionais são freqüentemente representados na forma de um cubo. Cada

face do cubo representa uma dimensão da empresa e cada célula contém os dados. O dado é

armazenado de forma que possa ser facilmente sumarizado através de uma estrutura

específica da empresa ou o relacionamento de várias estruturas da empresa (dimensões).

Cubo é um conjunto estruturado de dimensões, hierarquias, níveis e membros.

FIGURA 8 – CUBO COM AS DIMENSÕES PRODUTO TEMPO E VENDAS

Uma base de dados Multidimensional é freqüentemente construída a partir de uma base de

dados relacional (Data Warehouse).

Fatiar o cubo é uma outra forma de falar que o modelo está sendo pesquisado.

Petkovic (1999) explica que os sistemas de data warehouse oferecem suporte a diferentes

47

tipos de armazenamento de dados. Alguns desses tipos têm por base uma banco de dados

multidimensional, que também é chamado de cubo.

“Um cubo é um subconjunto de dados de um data warehouse, que pode ser organizado em estruturas multidimensionais. Para definir um cubo, primeiro você seleciona uma tabela de fato no esquema dimensional e identifica as colunas numéricas de interesse dentro dela. Então você seleciona as tabelas de dimensão que fornecem descrições para o conjunto de dados a ser analisado” (PETKOVIC, 1999).

O cubo é a representação mais popular de um modelo dimensional. No entanto, Machado

(2000) explica que usualmente, um modelo dimensional consiste de mais de três dimensões e

isto é definido como um hipercubo. Visualizar graficamente um hipercubo é muito difícil,

desta forma utiliza-se a referência a cubo para qualquer modelo multidimensional.

Thomsen (2002) lembra que, a noção de um hipercubo é fundamental para o entendimento do

software multidimensional que utiliza hipercubos da mesma forma que as planilhas usam

pastas de trabalho e os bancos de dados usam tabelas. Toda navegação, relatórios e análise são

feitas em termos de hipercubos.

3.5.4 Agregação

Petkovic (1999) explica que os dados são armazenados na tabela de fato em sua forma mais

detalhada, portanto, os relatórios correspondentes podem fazer uso deles. Por outro lado, uma

consulta típica em uma tabela de fato busca milhares ou mesmo milhões de linhas por vez e, a

única operação útil em tal volume de linhas é aplicar uma função agregada (soma, máximo,

média).

Machado (2000), complementa essa idéia afirmando que cálculos simples, como totais de

vendas e médias aritméticas, já são previstas pelo banco de dados multidimensional ao

processar as informações, conforme a configuração da estrutura de dados que for modelada.

O número de agregações em um SGBDM (Sistema Gerenciador de Banco de Dados

Multidimensional) é uma função que depende proporcionalmente do número de dimensões e

dos níveis de hierarquias, os quais influem mais diretamente no volume de dados que teremos

no nosso servidor (MACHADO, 2000).

Machado (2000) lembra ainda que, ao ascender em uma hierarquia dentro de um SGBDM

qualquer, os valores estarão cada vez mais agregados. Sendo assim, um banco de dados

48

multidimensional é composto por um grande conjunto de células com valores referentes aos

cruzamentos de dimensões e medidas. Uma pequena célula de um cubo, por exemplo, poderá

ter o valor de venda para a Região Sul, Vendedor X, dia 22/07/96, Produto 9, Valor de Venda

Bruta.

3.5.5 Operação básica de OLAP

Machado (2000) explica que, assim como para um modelo ER temos que conhecer as

operações básicas de álgebra relacional, no modelo de dados multidimensional temos as

operações OLAP. São quatro operações que o modelo deve suportar: Drill Down, Roll Up,

Slice e Dice.

Machado (2000) afirma que, Drill Down e Roll Up são operações para movimentar a visão do

usuário dos dados ao longo dos níveis hierárquicos de uma dimensão. Com a capacidade de

Drill Down o usuário pode navegar do nível mais alto até o dado mais detalhado. Enquanto

que, com a capacidade Roll Up, o usuário pode navegar do nível mais detalhado até o mais

alto nível de sumarização de dados. Exemplos de Roll Up e Drill Down são apresentados

respectivamente na FIGURA 9 e na FIGURA 10.

FIGURA 9. EXEMPLO DE OPERAÇÃO ROLL UP

49

Fonte: Adaptado de Machado (2000)

FIGURA 10. EXEMPLO DE OPERAÇÃO DRILL DOWN Fonte: Adaptado de Machado (2000)

Slice e Dice são operações para realizar navegação por meio dos dados na visualização de um

cubo. Slice é a operação que corta o cubo, mas mantém a mesma perspectiva de visualização

dos dados. Enquanto que Dice, é a mudança de perspectiva de visão (MACHADO, 2000).

Exemplos de Slice e Dice são apresentados respectivamente na FIGURA 11 e na FIGURA 12.

50

FIGURA 11. EXEMPLO DE OPERAÇÃO SLICE – FATIAMENTO DE UM CUBO

FIGURA 12. EXEMPLO DE OPERAÇÃO DICE Fonte: Adaptado de Machado (2000)

3.6 OLAP – ON-LINE ANALYTICAL PROCESSING A necessidade de receber um grande número de dados de um grande banco de dados são os

motivos de existir o OLAP (não é um aplicativo, é uma arquitetura de aplicação).

Quando temos a necessidade de um sistema multidimensional precisamos de um OLAP. É

51

uma forma diferenciada de armazenamento dos dados privilegiando a performance e a

flexibilidade de consultas.

Em um modelo de dados OLAP, a informação é conceitualmente organizada em cubos que

armazenam informações, por exemplo, um cubo contendo informações de vendas poderá ser

composto pelas dimensões tempo, região, produto, cliente e medidas. Medidas seriam valor

de venda, unidades vendidas, custos, margem, etc.

O termo OLAP (On-Line Analytical Processing) possui vários significados. Esta variedade de

significados se deve ao fato de que os principais elementos presentes no OLAP são

manifestáveis em diversas camadas de tecnologia, desde armazenamento e acesso até as

camadas de linguagem.

Segundo Thomsen (2002), é possível diferenciar conceitos OLAP, camadas de produtos

OLAP e produtos OLAP completos:

• Camadas de produtos OLAP normalmente residem em cima dos bancos de dados

relacionais e geram SQL como saída da combinação. O armazenamento e o acesso aos

dados são tratados pelo banco de dados

• Produtos OLAP completos precisam incluir um compilador e métodos de armazenamento

e acesso, são otimizados para acesso a dados e cálculos rápidos, sendo usados para

modelagem descritiva de dados, derivada de sistemas de suporte à tomada de decisão.

3.6.1 Exemplos de OLAP

É possível encontrar variantes para o termo OLAP, normalmente é acrescentada uma

consoante na frente do termo para classificar a ferramenta quando à sua arquitetura.

Thomsen (2002) afirma que os usuários originais das variações do termo OLAP foram

empresas que estavam vendendo camadas de produtos OLAP em cima dos sistemas de banco

de dados relacional, elas emitiam SQL ao banco de dados em resposta à entrada do usuário,

oferecendo somente capacidades secundárias de cálculo OLAP, utilizando o termo ROLAP

(Relational OLAP). Assim, os vendedores não ROLAP, passaram a ser rotulados como

MOLAP, para indicar OLAP Multidimensional. Desde então, surgiram os termos DOLAP

(usado para Desktop OLAP e Database OLAP), HOLAP (Hybrid OLAP), WOLAP

52

(Web OLAP) e MROLAP (Mobile and Remote OLAP).

“A maioria das organizações precisa de alguma mistura de capacidades que, se precisasse de uma qualificação por letra, seria HOLAP. Mas, como qualquer conhecimento apropriado de OLAP distinguiria entre a linguagem ou aspectos lógicos do OLAP e sua implementação física, tal conhecimento apropriado do OLAP revela que, fisicamente, ele pode ser de qualquer espécie. Assim, o conceito do H já está incluído nas características físicas do OLAP e nenhuma espécie de letra adicional é necessária” (THOMSEN, 2002).

Para O’Brien (2001), o OLAP fornece respostas rápidas para consultas complexas colocadas

por gerentes e analistas, permitindo a análise e manipulação interativa de enormes

quantidades de dados detalhados e consolidados a partir de múltiplas perspectivas, utilizando

sistemas de informação gerencial, apoio à decisão e sistemas de informação executiva.

A grande vantagem das soluções que utilizam OLAP é que o usuário não precisa ter

conhecimento técnico sobre o modelo de dados ou da linguagem de consulta para produzir a

informação desejada, o acesso aos dados passa a ser transparente. O usuário tem apenas que

lidar com os termos do negócio ao qual ele já está habituado (Leitão, 2000).

3.6.2 Requisitos funcionais para OLAP

Uma solução para ser considerada como OLAP, deve possuir alguns requisitos, que Thomsen

(2002) definiu da seguinte maneira:

“Os requisitos centrais, raiz, necessários ou mínimos no lado lógico, incluem suporte para múltiplas dimensões, hierarquias, fórmulas dimensionais e a separação de estrutura de dados e representação. Fisicamente, o principal requisito é velocidade suficiente para oferecer suporte à análise ocasional. Qualquer linguagem ou produto que não aceite pelo menos esses requisitos não pode, com seriedade, ser classificado como oferecendo suporte a OLAP” (THOMSEN, 2002).

Principais Requisitos Lógicos: Thomsen (2002) explica que, o reconhecimento de que

vivemos em um mundo caracterizado por conjuntos altamente multidimensionais de

subsistemas em interação, cada qual com muitos níveis de dados, detalhe, realidade ou

abstrações, é uma percepção fundamental. A capacidade das ferramentas OLAP de

modelarem com eficiência essa complexidade é uma de suas contribuições fundamentais, por

isso o modelo deve possuir uma estrutura dimensional rica com referência hierárquica.

Necessita de uma especificação eficaz de dimensões e cálculos, pois a maior parte das

informações importantes a serem colhidas resulta da comparação inteligente entre razões e

53

tendências deduzidas com o tempo e outras dimensões. Em um sistema OLAP, os cálculos

precisam ser tão simples de se definir quanto de dizer. Para oferecer funcionalidade OLAP

verdadeira, a ferramenta precisa conter uma linguagem de cálculo sofisticada (THOMSEN,

2002).

Para Thomsen (2002), flexibilidade é outro componente crucial da funcionalidade OLAP.

Existe visualização flexível, definição flexível e interface flexível. Os sistemas precisam ser

flexíveis em todas essas maneiras.

• A flexibilidade da visualização significa que o usuário pode escolher facilmente ver

informações na forma de gráficos, matrizes ou diagramas. O usuário pode selecionar

como a informação é mapeada para o formato de visualização;

• Em termos de definições, quem tiver a autoridade relevante deverá ser capaz de mudar

os nomes dos descritores, a formatação dos números e as definições de fórmulas, os

gatilhos para processos automáticos ou o local dos dados de origem sem incorrer em

qualquer penalidade indevida.

• A flexibilidade ou facilidade de uso da interface, que afeta a capacidade do usuário de

definir rapidamente o que ele deseja fazer. Não há vantagem em se ter um sistema

rápido e poderoso se o usuário não puder entender o que ele está dizendo. Para atrair o

usuário é necessário que o sistema seja amigável.

Necessita de separação de estrutura e representação. Ter essa separação significa que os

modos de exibição podem ser reorganizados por um usuário final sem que se façam quaisquer

mudanças estruturais nos dados (THOMSEN, 2002).

Principais Requisitos Físicos: Thomsen (2002) afirma que, velocidade é um componente

crucial do OLAP. Significa manter a linha de pensamento. OLAP precisa oferecer suporte a

consultas analíticas ocasionais, algumas delas podendo exigir cálculos realizados no ato.

“O desafio hoje é que os sistemas ofereçam um tempo de resposta muito rápido para pedidos de acesso e cálculo, enquanto trabalham com grandes conjuntos de dados em um ambiente multiusuário distribuído em uma rede. Algumas ferramentas oferecem isso pré-calculando todas as agregações. Mesmo que alguém pudesse armazenar todos os resultados pré-calculados, o aumento no tamanho do banco de dados pode realmente impedir quaisquer ganhos feitos ao tempo de resposta da consulta por meio do pré-cálculo. Para que haja um acesso com o máximo de eficiência, as ferramentas precisam oferecer a combinação certa de resultados pré-calculados e calculados no momento da consulta” (THOMSEN, 2002).

54

Thomsen (2002) não considera que o suporte para multiusuário seja um requisito necessário,

mas acha importante destacar este recurso devido à preponderância de servidores OLAP e à

praticidade do suporte multiusuário.

3.7 MICROSOFT SQL SERVER

Existem várias ferramentas que podem ser utilizadas para construção de cubos e

armazenamento de dados, porém para este trabalho de conclusão de curso será visto apenas o

SQL SERVER, pois será a ferramenta utilizada para armazenagem dos dados já modelados e

construção dos cubos na empresa JUNIOR.

Neste ítem, enfatiza-se a importância do SQL Server dentro do SIGBO. Mostram-se as

vantagens da utilização deste gerenciador de banco de dados em um sistema

multidimensional.

Petkovic (1999) explica que o SQL Server é um SGBDR (Sistema de Gerenciamento de

Banco de Dados Relacional) para computação cliente-servidor distribuída. Assim como todos

os outros sistemas de gerenciamento de banco de dados, ele fornece os seguintes recursos:

• Uma variedade de interfaces com o usuário;

• Independência física dos dados;

• Independência lógica dos dados;

• Otimização de consulta;

• Integridade de dados;

• Controle de concorrência;

• Backup e recuperação e

• Segurança e autorização.

Petkovic (1999) ressalta ainda, que as vantagens mais importantes do Microsoft SQL Server

em relação a outras ferramentas existentes no mercado são:

• O SQL Server funciona como uma extensão natural do Windows;

• O SQL Server é relativamente fácil de gerenciar, através do uso de um ambiente de

55

computação gráfico para quase todas as tarefas de sistema e administração de banco de

dados;

• O SQL Server usa serviços do Windows NT para fornecer recursos de bancos de dados

novos ou ampliados, como o envio e recebimento de mensagens e o gerenciamento de

segurança de login;

• O SQL Server é fácil de usar;

• O SQL Server pode passar de um laptop móvel para sistemas de multiprocessamento

simétrico e

• O SQL Server fornece recursos de armazenamento de dados que até então estavam

disponíveis apenas no Oracle e em outros sistemas mais caros.

3.7.1 DSS - Decisions Support Services

Petkovic (1999) explica que, é necessário diferenciar os sistemas usados para objetivos

operacionais (sistemas que exigem acesso rápido e transações curtas) dos sistemas usados

para objetivos analíticos (sistemas que usam operações de recuperação complexas em bancos

de dados enormes), pois essas duas tarefas não podem ser conseguidas da melhor forma

usando-se apenas um servidor de banco de dados. Por essa razão, o SQL Server (a partir da

versão 7) vem com os MS Decision Support Services (DSS). Assim, o SQL Server pode ser

usado para objetivos operacionais, enquanto os DSS são usados para objetivos analíticos.

Segundo Petkovic (1999), todos os componentes do DSS podem ser divididos em três grupos:

• MS Excel;

• Extensões SQL concernentes ao DSS

• Software-cliente de terceiros.

Petkovic (1999) explica que o SQL Server oferece algumas extensões para a declaração

SELECT que podem ser usadas especialmente para operações de apoio à decisão. Essas

extensões são:

• Operador CUBE;

• Operador ROLLUP e

56

• Cláusula TOP n.

Os dois operadores, CUBE e ROLLUP, são usados para incluir linhas de resumo no

resultado de uma declaração SELECT com a cláusula GROUP BY. A cláusula TOP n

fornece a recuperação das n primeiras linhas de um resultado de consulta (normalmente

classificado por meio de alguns critérios).

A cláusula GROUP BY define uma ou mais colunas como um grupo, de modo que todas as

linhas dentro de qualquer grupo tenham os mesmos valores dessas colunas. O operador CUBE

introduz linhas adicionais, chamadas linhas de resumo, no resultado de uma declaração

SELECT. Uma linha de resumo GROUP BY é retornada para cada combinação possível de

grupo e subgrupo no resultado (PETKOVIC, 1999).

Petkovic (1999) explica que, em contraste com o operador CUBE, que retorna cada

combinação possível de grupos e subgrupos, a hierarquia de grupo usando-se o operador

ROLLUP é determinada pela ordem em que o agrupamento das colunas é especificado.

3.7.2 Assistentes do DSS

Petkovic (1999) relata que o DDS oferece assistentes para quase todas as tarefas executadas

durante o projeto e a implementação de um data warehouse ou data mart. O Cube Wizard,

por exemplo, é usado para criar um cubo multidimensional no qual os dados agregados são

armazenados, enquanto o Dimension Wizard permite que sejam criadas tabelas de dimensão

compartilhadas ou privativas (As dimensões compartilhadas podem ser usadas por qualquer

cubo existente no sistema).

Petkovic (1999) explica ainda que, em contraste com a maioria dos outros servidores de data

warehouse, o DSS permite a utilização do modo de armazenamento mais adequado para um

sistema de data warehouse específico, possibilitando escolher entre MOLAP, ROLAP e

HOLAP.

Conforme já explicado na Seção 3.6.1 MOLAP é usado para armazenar dados de base e todas

as agregações em um cubo multidimensional, oferecendo o melhor desempenho para

consultas ad hoc. O ROLAP armazena todos os dados em tabelas relacionais, reduzindo assim

o volume de dados. Se os dados de base e todas as agregações forem separadas para que os

primeiros sejam armazenados em tabelas relacionais e as últimas, no cubo multidimensional,

57

o tipo de armazenamento será chamado HOLAP.

3.7.3 Componentes do DSS

Petkovic (1999) explica que o DSS possui três componentes que são usados para diferentes

propósitos:

• Repositório;

• OLAP Manager;

• Data Transformation Services (DTS).

Um repositório, segundo Petkovic (1999), é um armazenamento de dados (normalmente um

banco de dados) que contém informações a respeito de vários grupos de interesse para o

próprio sistema (essas informações são chamadas metadados). No caso do DSS, as

informações são armazenadas em um banco de dados relacional.

Os metadados constituem-se no principal recurso para a administração dos dados e assumem

uma maior impotância no ambiente de Data Warehouse. Em um ambiente operacional, os

metadados são importantes para o desenvolvedores e administradores do banco de dados. Por

outro lado, o ambiente de apoio à tomanda de decisão é bastante distinto, sendo que nele os

analistas de dados procuram por fatos não usuais. Seus usuários precisam examinar seus

dados e, para isso, devem conhecer sua estrutura e significado.

O OLAP Manager, segundo Petkovic (1999), é uma ferramenta que fornece uma interface

interativa para acessar os dados do DSS e o repositório. Os administradores de sistema e os

usuários finais podem usar o OLAP Manager para definir os bancos e dados e as origens dos

dados, definir e editar dimensões e gerenciar a segurança do servidor.

Petkovic (1999), relata também, que o DSS oferece o Data Transformation Services (DTS),

onde é possível extrair dados de diferentes origens de dados (como bancos de dados Access,

Oracle, SQL Server e arquivos de texto), transformá-los e carregá-los em um data warehouse:

“O DTS é a ferramenta de escolha para uma fase inicial do processo de construção de data warehouse, chamada de fase de consolidação dos dados. Nessa fase, os dados são extraídos de diferentes origens e convertidos para um esquema intermediário. Depois disso, os dados são limpos, isto é, todos os dados extraídos são verificados e os formatos e tipos diferentes dos mesmos dados são unificados. Finalmente, eles são verificados para ver se atendem aos requisitos já existentes” (THOMSEN, 2002).

58

4. PLANEJAMENTO

O levantamento de dados efetuado para o presente TCC buscou fundamentalmente analisar a

sistemática atual de trabalho da empresa e, mais especificamente, do Departamento Comercial

da JUNIOR, identificando critérios, regras de negócios, procedimentos utilizados, fluxo de

informações interno, documentos utilizados, forma de relacionamento entre si no tocante à

troca de informações, bem como as principais necessidades e dificuldades hoje existentes para

um melhor desempenho de suas funções.

O levantamento foi executado através de visitas às instalações e entrevistas junto aos diversos

setores, procurando identificar os principais objetivos e metas estratégicas da JUNIOR e o seu

impacto sobre os sistemas de informações existentes.

As áreas/funções envolvidas no levantamento foram:

Diretoria

Gerência de Vendas

Vendas Representantes

Gerência Administrativa/Financeira

Gerência Técnica

Informática

A elaboração deste planejamento deu-se com base nas informações obtidas junto aos usuários

consultados. Os resultados apresentados são estimativas compiladas a partir da adequação das

necessidades identificadas na JUNIOR, com soluções comumente encontradas no mercado de

informática. Com o desenrolar da execução deste planejamento, diversos fatores,

principalmente de ordem cultural, financeira e comercial, poderão resultar em desvios

positivos ou negativos da referência central, razão pela qual a revisão deverá ser permanente.

59

4.1 DIAGNÓSTICO PRÉVIO ÁREA DE INFORMÁTICA

* QUANTO AOS HARDWARES UTILIZADOS

- 2 servidores (1 servidor ORACLE e 1 servidor SQL SERVER)

- 38 estações de trabalho, assim segmentados:

- Fábrica - 06 microcomputadores.

- Escritório – 32 microcomputadores.

- Impressoras:

- 8 deskjet.

- 2 matriciais.

* QUANTO AOS SOFTWARES BÁSICOS UTILIZADOS - Controlador operacional de rede – Windows 2003 SERVER; - Softwares de apoio: MS-EXCEL (Planilha Eletrônica que será utilizada como ferramenta de navegação do usuário). - B. Dados ORACLE (banco relacional no qual estão inseridas as informações pelo usuário nas operações diárias da empresa, como nota fiscal, contas a pagar, contas a receber e outras) - B. Dados SQL SEVER (banco que receberá a carga do banco relacional ORACLE e fará a conversão para OLAP) - Sistema de Gestão MICROSIGA (sistema de gestão empresarial utilizada para realizar as

funções da área comercial)

4.2 DIAGNÓSTICO PRÉVIO DA ÁREA COMERCIAL

- Gerência de Vendas necessita de informações mais ágeis de Análise de Crédito, PCP e

Produção para Gestão Comercial (tomada de decisões e negociação com clientes).

- Alguns pontos identificados como gargalo no fluxo do Processo Comercial:

• Digitação dos Pedidos;

60

• Avaliação de Crédito;

• PCP/ Produção.

- Acompanhamento dos tempos de entrega dos pedidos.

- As informações sobre acompanhamento de vendas (Rentabilidade, Preço Médio) não estão

disponibilizadas em tempo hábil para decisões, ocorrendo após os fatos acontecidos.

- Representantes:

• Falta de comprometimento quanto às especificações dos produtos;

• Envio de pedidos de venda com informações incompletas.

4.3 DIAGNÓSTICO PRÉVIO DA ÁREA ESTRATÉGICA

Alguns pontos devem ser considerados quantos aos aspectos estratégicos/gerenciais da

organização, que foram observados, como segue:

• Os Sistemas de Informações Gerenciais, voltado para a alta administração e gerências

intermediárias, são basicamente elaborados de modo manual, buscando-se seus dados de

relatórios estáticos no Sistema de Gestão Microsiga.

• Observa-se que os dados oriundos dos sistemas informatizados sofrem alguns ajustes e

complementações, o que caracteriza deficiência de seus sistemas, que podem não ser

confiáveis. Portanto, para este trabalho, buscou-se modelar os dados já considerados

confiáveis, como notas de entrada, notas de saída, notas de devoluções, comissões pagas e

outras, garantindo a veracidade das informações.

• O problema atual, que resulta no objetivo deste trabalho, é o fato de existirem diferenças

entre os relatórios relacionais do MICROSIGA e os relatórios montados manualmente para a

gerência. Portanto, os dados gerenciais têm de possuir a mesma origem dos relatórios

relacionais.

• Devido à crescente necessidade de agilidade das informações, principalmente na área de

61

decisões das organizações, é fundamental que os dados sejam únicos e confiáveis,

provenientes diretamente dos sistemas, para que as empresas sejam competitivas num

mercado cada vez mais acirrado.

62

5. DESENVOLVIMENTO DO SISTEMA PROPOSTO

5.1 INTRODUÇÃO

Neste capítulo descreve-se toda a metodologia utilizada no desenvolvimento do sistema de

informação. Na primeira seção, contextualizam-se as fases de desenvolvimento, a

especificação tecnológica envolvida, os resultados esperados e algumas considerações

realizadas. A segunda e terceira seções apresentam, respectivamente, a modelagem funcional

do sistema e a modelagem entidade-relacionamento. Finalizando este capítulo, o sistema de

apoio à decisão é apresentado. Será feito uma referencia da parte teórica juntamente com a

parte pratica para facilitar o entendimento acadêmico.

5.2 METODOLOGIA DE DESENVOLVIMENTO

Conforme FURLAN (1994), a metodologia para desenvolvimento e elaboração de um sistema

de informação, apresentada na Figura 13, é composta pelas seguintes fases e estágios:

Planejamento, Projeto e Implantação.

FIGURA 13. METODOLOGIA PARA SISTEMA DE INFORMAÇÃO. Fonte: Furlan (1994).

Planejamento

A fase de planejamento tem por objetivo definir conceitualmente o sistema de informação por

meio da identificação das necessidades de informação e do estilo decisório do Executivo,

63

bem como da estrutura básica do sistema e do protótipo preliminar de telas, conforme

demonstrado na Figura 14.

FIGURA 14 : COMPONENTES DA FASE DE PLANEJAMENTO. Fonte: Furlan, (1994).

Esta fase é composta por cinco estágios, os quais podem ser observados na Figura 15: FIGURA 15: OBJETIVOS DA FASE DE PLANEJAMENTO.

Fonte: Furlan, (1994)

Estágio I

- Organização do Projeto: A equipe de trabalho foi treinada nas técnicas de levantamento de

dados e análise dos fatores críticos de sucesso, nas quais foram identificadas quais

informações os Executivos já recebem, por meio de questionário específico identificado no

anexo 01 deste trabalho. As tarefas deste estágio foram: estabelecer a equipe de trabalho;

conduzir reunião de abertura de projeto; anunciar o projeto à empresa; iniciar o levantamento

das informações que os Executivos recebem; finalizar o plano de trabalho; levantar as

64

necessidades dos sistemas e bases de dados que serão trabalhadas em duas etapas, a base

relacional para a qual será utilizado o banco de dados ORACLE e a base multidimensional

para a qual será utilizado o banco de dados SQL SERVER. Este estagio foi desenvolvido para

esta trabalho de conclusão de curso conforme reuniões destacadas no item 3.0,

fundamentação teórica.

Estágio II

- Definição de Indicadores: É neste estágio que o Executivo foi entrevistado individualmente

para pudesse ser identificado seus objetivos, fatores críticos de sucesso e necessidades de

informação em seguida, efetuada a documentação para submeter os resultados à revisão.

Antes das entrevistas, conduziu-se uma sessão de planejamento, a fim de rever os

procedimentos e, traçar uma linha mestra de ação. As tarefas deste estágio são: conduzir o

planejamento da pré-entrevista; conduzir entrevistas aos Executivos; revisar e documentar

entrevistas; obter aprovação da diretoria. Este estagio foi desenvolvido para esta trabalho de

conclusão de curso conforme destacado abaixo:

Premissas das Soluções

Consideram-se algumas premissas básicas, que servirão de norte para as soluções descritas a

seguir:

a) As soluções de informática devem ser independentes do crescimento e evolução da

empresa e de suas transações;

b) O objetivo das soluções é garantir um maior automatismo, reduzindo o volume operacional

manual;

O Modelo Integrado De Informações - Junior

A seguir, apresentam-se as características de integrações e algumas funções chaves do sistema

de gestão de empresas Microsiga, que foram implantadas na JUNIOR em março de 2002,

passando por acertos e ajustes, tendo seus dados mais confiáveis a partir do inicio de 2004,

portanto a empresa já esta apta para implantar uma ferramenta de apoio a decisão, pois já

possui um histórico no banco de dados.

Neste trabalho foi abordada apenas a área comercial, cabendo registrar que seria

65

recomendável implementar futuramente, no sistema de informações modelado neste trabalho,

todas essas áreas, com vistas a obter um diferencial para a JUNIOR.

O modelo Integrado de Informações, proposto a seguir, visa atender tanto o nível operacional

como os níveis Gerencial e Diretivo, com informações que possibilitam uma administração

com maior eficiência, integração, dinamismo e economicidade. Porém, para este trabalho de

conclusão de curso, serão focadas apenas a área comercial e suas variâncias, destacadas

ANÁLISE DECRÉDITO

ADMINISTRAÇÃODE VENDAS

ESTATÍSTICASDE VENDAS ENGENHARIA

PLANEJAMENTODE PRODUÇÃO

PLANO MESTREDE PRODUÇÃOFATURAMENTO

COMPRAS

CONTAS ARECEBER

CONTABILIDADEFISCAL

ESTOQUEMATÉRIA PRIMAE COMPONENTES

CONTABILIDADEPATRIMONIAL

FLUXO DECAIXA

CONTABILIDADEGERAL

CONTROLEDE CUSTOS

CONTROLEDE PRODUÇÃO

ESTATÍSTICASDE PRODUÇÃO

ADMINISTRAÇÃORECURSOSHUMANOS

FOLHA DEPAGAMENTO

CONTAS APAGAR

1

2

1

2

OUTROSINSUMOS

3

COMISSÕES

REPRESENTANTES

3

4

44

FABRICAÇÃO(CLP’s,Cod.Barra,Máq.Inteligentes)

LABORATÓRIO

EXPEDIÇÃO/PLANO

EMBARQUE

MANUTENÇÃOINDUSTRIAL

5

5

FIGURA 16 – MODELO INTEGRADO DE INFORMAÇÕES

O Sistema Proposto Atende Os Seguintes Requisitos Funcionais:

Gestão de Vendas

O processo de gestão de vendas constituído diretamente pelo sistema de controle de pedidos,

apóia-se no crédito, nos clientes, no faturamento, no estoque de peças em disponibilidade e

nas estatísticas. Clientes esta vinculado ao faturamento e crédito são ações baseadas nesse

66

cliente. O importante é que todas as informações necessárias para a gestão das vendas estejam

permanentemente disponíveis e atualizadas a todos os usuários do processo.

Deverá também permitir consultas consolidadas que demonstrem eventuais anomalias no

atendimento, além de estatísticas mensais sobre o comportamento geral das vendas. A carteira

de pedidos está nas regras de negócios, gerando informações sobre os cancelamentos, de

maneira a qualificar a atividade do setor de crédito e automatizar esse controle por ocasião do

faturamento.

* Faturamento

O sistema de faturamento da JUNIOR esta totalmente integrado à carteira de pedidos de

vendas e ao sistema de contas a receber. Desta forma, as regras de negócio destacadas nas

reuniões com os gestores define que um cliente que possua mais de dois títulos em atraso tem

suas novas vendas bloqueadas, excetuando se ocorrer um aval do gerente comercial, portanto

estas aprovações tem de estar em destaque nas consultas do sistema de informação.

Características Dos Sistemas De Vendas

De acordo com o estudo e levantamentos efetuados, observa-se que a sistemática das

operações de vendas segue as características citadas abaixo:

a) O representante, através de sua estação de trabalho, envia o pedido de venda por e-mail,.

citando valores, condições de pagamento, quantidades, códigos de clientes e código dos

produtos identificados através de tabela de preço regularmente atualizada. O pedido de venda

será digitado no sistema MICROSIGA por um funcionários da empresa JUNIOR;

b) O sistema, através de dispositivos internos previamente definidos, faz a avaliação de

crédito do cliente e o autoriza se estiver dentro dos limites aceitáveis, em caso negativo,

repassa à área Financeira para tratamento específico;

c) A equipe interna da JUNIOR verifica se o produto está previamente definido e avisa o

Representante para confirmar especificação. Caso seja produto novo, transfere à área de

desenvolvimento para sua especificação;

d) O MICROSIGA submete o pedido à avaliação para verificar se a data de entrega do

produto está dentro da capacidade de produção da fábrica, considerando as ordens já

67

colocadas, caso contrário, sugere novo prazo;

e) Superados todos estes quesitos, o sistema submete o pedido para planejamento da produção

e fabricação;

f) O MICROSIGA pode, automaticamente, emitir um e-mail ao cliente, confirmando as

condições acordadas e o prazo de entrega, bem como emiti-lo no momento do embarque.

Processo: Autorização de Crédito

a) Este módulo possibilita a JUNIOR manipular informações de Avaliação de Crédito,

permitindo ao sistema liberar pedidos de clientes automaticamente, desde que o cliente e o

pedido atendam a parâmetros pré-definidos pela empresa;

b) Somente serão avaliados manualmente pela área financeira aqueles pedidos e clientes que

fujam às regras pré-estabelecidas

Estágio III

- Análise de Indicadores: O objetivo deste estágio foi normalizar as informações levantadas

durante as entrevistas individuais dos executivos a fim de obter uma lista consolidada de

objetivos, fatores críticos de sucesso, problemas e necessidades de informação. Esta lista é

transformada numa matriz de inter-relacionamento entre os indicadores de desempenho e os

respectivos objetos de interesse dos Executivos. As atividades deste estágio são: consolidar

objetivos, fatores críticos de sucesso e necessidades de informação; classificar objetivos e

fatores críticos de sucesso; conectar fatores críticos de sucesso aos objetivos e às necessidades

de informação; classificar necessidades de informação. Para este trabalho de conclusão de

curso as análises foram feitas conforme destacado abaixo:

Quanto á disponibilidade de Informações

A política básica é de que o computador esteja voltado ao usuário das informações e, para tal,

os sistemas e seus dados deverão ser um importante veículo para se conseguir uma adequada

distribuição de informações nos vários níveis organizacionais da JUNIOR.

Os sistemas atualmente em uso pela JUNIOR, via de regra, contemplam as necessidades de

nível operacional, não levando em conta as chamadas necessidades de uso Gerencial e

Diretivo. Estas informações podem ser caracterizadas em dois níveis distintos: no

68

primeiro nível se inserem as de caráter estatístico, com dados consolidados que apresentam a

característica de serem de emissão ou consulta periódica (normalmente mensais), podendo ser

previamente definidas e estruturadas, sofrendo poucas variações ao longo do tempo e sendo

pouco afetadas por mudanças externas. No segundo nível, aparecem as necessidades de

consultas não estruturadas, eventuais, bastante diversificadas ao longo do tempo e bastante

dependentes das condições do momento. Para estas, o tratamento é bem diferenciado das

anteriores, pois não há como defini-las previamente, exigindo que se coloquem, à disposição

de seus usuários, ferramentas que lhes permitam manipular adequadamente tais necessidades,

acessando as Bases de Dados e obtendo respostas a seus questionamentos.

Outra questão a ser levada em conta é a que se refere ao nível de acesso às informações e

autorizações para a execução de determinados processamentos. Somente uma definição clara

e formal destes aspectos é capaz de evitar processamentos inúteis e onerosos para a empresa

sem que esta mantenha o controle e mesmo tenha conhecimento de que isto ocorre.

Quanto ao sistema de Informações Gerenciais

Com a evolução dos sistemas operacionais para um ambiente de banco de dados integrado e

com a crescente utilização de microcomputadores pelas diversas áreas da Empresa, a JUNIOR

possui condições favoráveis à implantação de um sistema de informações gerenciais que

pressupõe a utilização do "processamento cooperativo", ou seja, interligação total entre

microcomputadores e equipamentos centrais/servidores.

Desta forma, é chegada à hora de nutrir de informações os Gerentes e Diretores da Empresa,

cuja tarefa maior é a de controlar lucros e outras medidas de desempenho. Mas como realizar

estes objetivos sem perder de vista cada aspecto das operações sob seu controle, localizando

problemas ou oportunidades e adotando medidas mais adequadas? A resposta pode ser dada

pela informática, a serviço dos níveis estratégicos da JUNIOR.

A função básica de um EIS é de entregar as informações vitais, no momento oportuno, a

quem necessita dela para tomar uma decisão, pois informação que não pode ser acessada de

forma prática e rápida é inútil. Neste caso específico, informação trata de dados financeiros,

tendências, relatórios de exceção, comentários da gerência, índices operacionais chaves,

resumos dos principais cálculos, relatórios de controle de qualidade, números de participações

no mercado e informações sobre concorrentes.

69

O EIS da JUNIOR deverá estar calcado sobre quatro pontos básicos, a saber:

a) Análise de Resultados consolidados em vários níveis de detalhe, permitindo o grau de

agregação necessário a cada Executivo;

b) Análise de Tendências, permitindo ao Executivo verificar para qual direção os dados estão

se movendo;

c) Consultas de Exceção, permitindo a personalização dos dados de acordo com necessidades

individuais;

Estágio IV

- Consolidação de Indicadores: neste estágio foi realizada uma revisão dirigida com o grupo

de executivos entrevistados para rever os objetivos, fatores críticos de sucesso, problemas e

necessidades de informação, assim como confirmar a classificação desses objetivos. As

atividades deste estágio são: conduzir sessão de revisão dirigida; revisar fórmulas de controle

de exceção; revisar documento da sessão de revisão dirigida; Este estágio foi desenvolvido

para esta trabalho acadêmico conforme as reuniões destacadas no item 7.4

Estágio V

- Desenvolvimento de Protótipos: são realizadas as atividades de construção de consultas e

estruturas de navegação do sistema; é construído um protótipo para que os executivos possam

ter uma visão mais próxima possível do que será o sistema. As tarefas deste estágio são:

desenvolver protótipo; desenhar estrutura de drill-down; obter aprovação do protótipo. Este

estagio foi desenvolvido para esta trabalho acadêmico conforme as reuniões destacadas no

item 7.0

Projeto

Se a fase de planejamento teve como escopo a determinação de especificações do sistema sob

o enfoque das necessidades do usuário, a fase de projeto definiu a solução técnica para

implementar o projeto conceitual concebido. De um modo prático, foi definida, nesta fase, a

arquitetura tecnológica a ser adotada; foi escolhida a ferramenta de software; planejados os

critérios de integração e transferência de dados; modelada a base de dados do SI, sendo

detalhados os atributos das tabelas a serem criadas e consultas de arquivos a serem acessados.

70

Esta fase pode ser mais bem vista na Figura 17.

FIGURA 17: OBJETIVOS DA FASE DE PROJETO Fonte: Furlan (1994).

Esta fase é composta por três estágios, sendo que, no primeiro deles, é feita a decomposição

de indicadores; no segundo, é feita a definição da arquitetura tecnológica; e, no último

estágio, é onde ocorre o planejamento da implementação.

Na decomposição dos indicadores, atividades são envolvidas para detalhamento técnico dos

indicadores e modelagem da base de dados do SI, que suportará o atendimento das

necessidades de informação dos Executivos. É feita uma especificação de fontes para a

necessidade de informação, classificadas na fase anterior. Por meio dessa especificação,

identificam-se os sistemas e bases de dados que devem ser acessados para suprir as

necessidades de informação identificadas.

As tarefas deste estágio são: definir atributos das telas; identificar interfaces e racionalizar

fluxos de informação, definir fontes de informação; definir atualização das bases de dados;

modelar bases de dados SI.

Na definição da arquitetura tecnológica, as atividades visam implementar o sistema, sendo

determinada a localização física das bases de dados e a definição de parâmetros, como

investimentos necessários e instalações.

As tarefas deste estágio são: elaborar cenários alternativos; analisar cenários; definir

arquitetura de hardware e software; analisar viabilidade técnica e econômica; escolher a

melhor solução de arquitetura tecnológica.

No planejamento da implementação, busca-se determinar os recursos necessários para o

desenvolvimento da aplicação do SI. São planejados, além do cronograma de construção do

71

sistema, os seus demais requisitos, tais como instalação, criação das bases de dados e

realização de testes.

As tarefas deste estágio são: definir recursos necessários para o desenvolvimento do SI;

estabelecer cronograma de trabalho; definir base de dados de teste; obter aprovação dos

recursos e investimentos necessários.

Implementação

A última fase da metodologia de desenvolvimento de um SI é a implementação do mesmo,

cujas etapas podem ser vistas na Figura 18 e estão descritas a seguir:

FIGURA 18: FASE DE IMPLEMENTAÇÃO Fonte: Furlan (1994).

1. Construção dos Indicadores: As atividades desta etapas são mais técnicas. Nela foram

realizadas as etapas descritas no item 7.4 deste trabalho, com base nas informações da fase

de planejamento, definiram-se os indicadores necessários para realizar as consultas

propostas pelos gestores que são faturamento, quantidade, preço mínimo e crédito. Estes

indicadores tem de estar associados às dimensões de cliente, produto e vendedor para que

as informações necessárias para a tomada de decisão estivessem disponíveis e os mesmos

pudessem criar análises interligando estas dimensões e estes indicadores aproveitando-se

das vantagens que a criação de um cubo proporciona, sem ficar restrito aos relatórios

estáticos. Para que isto fosse possível utilizou-se como tabela de fato a tabela de

faturamento do sistema MICROSIGA, nela obteve-se todas as informações necessárias

para se construir o DTS conforme demonstrado abaixo, gerando a carga das informações

solicitadas pelos gestores, após a carga de dados inicial e a parametrização do DTS para

gerar cargas automáticas diariamente. Após utilizou-se a ferramenta do SQL Analysis

Manager para a construção do cubo e o processamento do mesmo permitindo que as

informações pudessem ser utilizadas por uma ferramenta de análise que neste caso foi

72

escolhido o EXCEL.

2. Instalação de Hardware e Software: Na parte definida como Hardware todos os

servidores já estavam instalados e configurados portanto não houve necessidade de

nenhuma intervenção. Na parte definida como software operou-se com três sistemas: o

banco de dados ORACLE que já estava instalado e funcionando perfeitamente por fazer

parte do MICROSIGA, o SQL SERVER que foi a ferramenta escolhida para montar e

armazenar o cubo desenvolvido para a JUNIOR, foi instalado e configurado para a

realização deste trabalho, o excel já estava instalado e devidamente configurado para as

necessidades dos gestores.

3. Treinamento e Implementação: É neste estágio que o sistema se torna disponível para os

Executivos e é incorporado ao seu cotidiano. Como o Excel foi a ferramenta escolhida para a

utilização e criação das análises gerados pelo cubo, não houve necessidade de treinamento,

pois os gestores já estavam acostumados com o manuseio da mesma.

5.3 ESPECIFICAÇÃO TECNOLÓGICA ENVOLVIDA

Este sistema de informação é uma abordagem de gerenciamento integrado, permitindo a

JUNIOR, não importando o grau de sua complexidade ou o seu tamanho, aplicar efetivamente

suas habilidades e alcançar seus objetivos estratégicos, constituindo-se em um importante

avanço na transformação da estratégia em ações, tornando a organização eficaz. Portanto, as

informações devem estar disponíveis no exato momento em que o gestor necessitar.

Optou-se durante a fase de planejamento pela utilização do aplicativo EXCEL, devido à

facilidade de utilização, à empresa já possuir este aplicativo instalado, e os Executivos já

possuírem habilidade em sua utilização.

O Sistema de Informação foi subdividido em etapas. As informações necessárias para a

composição de cada uma das perspectivas desejadas são:

1. Objetivos Estratégicos: Os gestores esperavam que com a construção do sistema de

informação pudessem verificar seus dados com segurança, confiança, agilidade, acesso via

internet, e com a possibilidade de gerar análises sem a necessidade de um programador,

gerenciando a empresa de qualquer parte do mundo;

73

2. Indicadores: descrevem as indicações de que um resultado foi alcançado. Os objetivos

confiança, agilidade, possibilidade de gerar análises sem a necessidades de um programador

foram alcançados, porém com a decisão de utilizar o Excel, a utilização da internet não foi

alcançada, ficando este item para uma próxima etapa;

3. Metas: descrevem as medidas dos indicadores. Para se conseguir as consultas desejadas

pelos gestores nas reuniões estratégicas utilizou-se as medidas faturamento, quantidade ,

preço mínimo e crédito;

4. Alinhamento Estratégico: verificam se as ações tomadas estão alinhadas à estratégia

empresarial. Todas a modelagem realizada no banco e a construção do cubo tiveram como

base as reuniões com os gestores, e após a conclusão do trabalho e apresentado aos gestores

verificou-se que as analises almejadas poderiam ser alcançadas.

Portanto, o Sistema de Informação foi formado por objetivos, metas, indicadores e

alinhamento estratégico. O modelo proposto foi baseado no levantamento realizado

juntamente com a diretoria da empresa. Cada um desses itens deverá ser aprovado pela

diretoria e divulgado aos seus colaboradores.

A visão geral do modelo proposto pode ser visto na Figura 19.

74

FIGURA 19: MODELO GERAL PROPOSTO

JUNIOR

metas

iniciativas Indicadores (Quantidade e

objetivo

ORACLE SQL SERVER OLAP

5.3.1 Níveis de segurança

A segurança do sistema será realizada via recursos do SQL SERVER. Este ambiente oferece

os controles de acesso a usuários, senhas e permissões.

O ambiente disponibiliza uma área onde o usuário realiza login no sistema, acessando a tela

de entrada do aplicativo ou, se pertencer ao grupo dos administradores, acessando um

ambiente para administração do sistema.

5.3.2 Carga de dados

A carga inicial dos dados do sistema foi realizada baseada nas reuniões e necessidades dos

diretores e alinhada com o planejamento estratégico. Neste trabalho serão realizadas,

primeiramente, somente as cargas relativas à área comercial. Assim, as entrevistas e

necessidades que foram realizadas, priorizam os responsáveis desta área.

A integração com o sistema de gestão da empresa foi realizada através da importação dos

dados do banco de dados ORACLE diretamente para o SQL, que, através da ferramenta DTS,

75

permite esta carga sem transformações em arquivos textos.

Para obter os resultados esperados verificados nas reuniões com os gestores foram realizadas

as cargas baseadas nos seguintes aspectos:

A tabela de fato é alimentada basicamente por informações da tabela de faturamento que

possuem dados como número da nota, quantidade de produto vendida, valor unitário faturado

e data de emissão da nota, informações necessárias para alimentar os indicadores base que

foram definidos nas reuniões - o indicador intermediário “valor mínimo” será conseguido

através da tabela de preço informada no pedido de venda, e o indicador “preço médio mensal”

será um indicador calculado com base no preço faturado do produto em um determinado mês,

indicador “comissão” será calculado pelo percentual informado de comissão e o valor unitário

de cada produto.

Na tabela de faturamento, consegue-se o vínculo com o cliente, com o produto vendido, com

a condição de pagamento utilizada, com o vendedor que realizou a venda e seu percentual de

comissão. Com estas informações, monta-se as dimensões base necessárias para montar as

consultas desejadas pelos gestores. As dimensões de crédito, estado, município serão obtidas

através da tabela de cliente, e as dimensões de grupo e família serão obtidas através da

dimensão produto.

As cargas deverão ser sempre completas desde o inicio do ano pré-definido, que em reuniões

optou-se por ano base 2003, pois a partir deste ano base a empresa já possui informações mais

confiáveis em seu banco de dados. O risco de fazer cargas incrementais seria que estas não

abordariam eventuais exclusões de notas.

5.3.3 Resultados esperados

O propósito deste trabalho é atender às bases fundamentais de montagem de um

DATAWAREHOUSE relacionadas com conceitos modernos de ferramentas de BI abordados

na revisão bibliográfica deste projeto, contemplando um espectro de formas de gerenciamento

e tecnologias que podem ser aplicadas no âmbito empresarial.

76

5.4 ANÁLISE FUNCIONAL

5.4.1 Introdução

A análise do sistema foi realizada utilizando-se a notação UML (Unified Model Language). A

UML é uma linguagem gráfica para visualização, especificação, construção e documentação

de artefatos de sistemas de software (BOOCH, 2000). A UML proporciona uma forma padrão

para a preparação de planos de arquitetura de projetos, incluindo aspectos conceituais, tais

como processo de negócios e funções do sistema, além de itens concretos como as classes,

banco de dados e componentes de software reutilizáveis. Nesta etapa de modelagem foram

identificadas as funcionalidades do sistema de informação executivo.

O propósito deste sistema é desenvolver um aplicativo utilizando a ferramenta Excel onde a

empresa possa acompanhar o alinhamento da estratégia, através dos indicadores, objetivos,

metas e planos de ação. O sistema permitirá flexibilidade quanto ao número de indicadores,

dimensões e níveis.

Este projeto está subdividido nos seguintes subsistemas:

1. Cadastro e alimentação dos dados;

2. Visualização gráfica;

3. Visualização personalizada;

4. Fluxo do sistema

5. Controle de acesso;

Os usuários que utilizarão o sistema serão somente os gestores da empresa. Para uma maior

segurança, cada colaborador terá um login, que lhe dará determinados privilégios no sistema

estabelecidos pelo Administrador.

77

7.4.2 Organograma funcional do sistema

Uma visão geral dos subsistemas e suas principais funcionalidades representadas em um

organograma são apresentadas na figura 20.

FIGURA 20 - ORGANOGRAMA FUNCIONAL DO SISTEMA

Pode-se descrever cada item do organograma como:

1 - Dados: Este subsistema possuirá os procedimentos para o cadastramento (inclusão,

exclusão e alteração) dos dados do aplicativo, para a realização da carga inicial do sistema e

para sua alimentação periódica que serão sempre cargas completas.

1.1 - Carga Inicial: Processo de implantação do sistema, no qual será realizada uma

importação dos dados existentes no sistema de gestão.

78

1.2 - Alimentação: Processo de realimentação periódica dos dados que possuírem

integração com o banco de dados relacional Oracle.

1.3 - Cadastro Usuário: O usuário com privilégio de administrador do sistema irá efetuar o

cadastro dos colaboradores da empresa. Será cadastrado o nome do usuário, senha e privilégio

de acesso.

2 - Consulta Personalizada: Este subsistema possuirá as consultas realizadas pelo

próprio usuário

2.1 - Por metas: Neste relatório o usuário poderá analisar as metas, verificando se foram

atingidas de forma top-down a empresa, os gerentes e os vendedores.

2.2 - Por Produto: Neste relatório o usuário poderá analisar todos os produtos vendidos em

um determinado período de tempo verificando por ranking quais produtos representam o

maior faturamento da empresa.

2.3 - Por valores: Neste relatório o usuário poderá verificar as consultas de vendas menores

que o preço mínimo, que, de acordo com o modelo de negócio, não são aceitas.

3 - Notificação do Sistema: Este subsistema possuirá os procedimentos relacionados as

regras de negócio existente na empresa, ou seja, dependendo dos números apontados nos

indicadores, o sistema assume um determinado comportamento, enviando um e-mail para o

responsável da área (diretoria ou presidência).

3.1 - Por preço mínimo: De acordo com as regras de negócio, os vendedores não podem

realizar mais de duas vendas abaixo do preço mínimo por mês. Caso isto aconteça, o sistema

informará com sim nas consultas.

3.2 - Por crédito do cliente: De acordo com as regras de negócio, as vendas não poderão

ser realizadas vendas acima do crédito pré-aprovado para o cliente. Caso isto aconteça, o

sistema informará como sim nas consultas.

5.4.3 Análise dos Riscos

Em relação à interface e funções, os riscos serão minimizados com a adoção de alguns

procedimentos: problemas com a queda do Banco de Dados ou falha na comunicação

79

resultarão na saída do sistema de funcionamento, representando um risco a tomada de decisão.

O processo do negócio também apresentará baixo risco, pois toda a logística da empresa será

aproveitada.

5.4.4 Diagramas de caso de uso

Conforme Furlan (1998), os diagramas de caso de uso apresentam-se como uma forma para

descrever uma visão externa do sistema, apresentando suas interações com o mundo exterior.

Os diagramas de caso de uso apresentam uma visão macro do sistema, representando uma

visão de alto nível de funcionalidade, mediante os diferentes tipos de requisições dos usuários.

O diagrama de casos de uso descreve as ações do usuário sob o sistema, bem como os

requisitos funcionais associados.

Os principais casos de uso do sistema estão representados nas figura 21 a 25.

FIGURA 21 – USE CASE GENÉRICO A figura 21 representa todos os processos do sistema, os atores envolvidos e as etapas para o desenvolvimento e manutenção do sistema.

80

FIGURA 22 – DESENVOLVIMENTO A figura 22 representa as etapas necessárias para o desenvolvimento do sistema.

FIGURA 23 – ADMINISTRAÇÃO DO SISTEMA

A figura 23 representa as permissões do ator Administrador

81

FIGURA 24 – CONSULTAS DO SISTEMA

A figura 24 representa as permissões do ator Usuário

FIGURA 25 – SHEDULE

A figura 25 representa as atividades dos atores SQL SERVER e Oracle.

82

5.4.5 Estrutura do DTS

DTS

FIGURA 26 – DTS DESENVOLVIDO PARA A JUNIOR

LIMPAR TABELA

FIGURA 27 – LIMPAR TABELA Conforme informado previamente pelos gestores, as notas podem ser deletadas a qualquer

momento pela equipe de faturamento, sem respeitar uma data especifica, portanto definiu-

83

se por realizar sempre a carga total, conforme demonstrado abaixo.

PARA GERAR A DIMENSÃO PRODUTO FOI REALIZADO O SEGUINTE SQL:

SELECT produto.B1_COD, produto.B1_DESC, NVL(TRIM(produto.B1_GRUPO),

'9999') AS GRUPO, NVL(TRIM(produto.B1_FAM), '99') AS FAMILIA, SUM

(estoque.B2_QATU - estoque.B2_RESERVA)

AS ESTOQUE_DISPONIVEL

FROM ADM_SIGA.SB1010 produto,

ADM_SIGA.SB2010 estoque

WHERE produto.B1_COD = estoque.B2_COD

AND (produto.D_E_L_E_T_ <> '*') AND (estoque.D_E_L_E_T_ <> '*')

GROUP BY produto.B1_COD, produto.B1_DESC, NVL(TRIM(produto.B1_GRUPO),

'9999'), NVL(TRIM(produto.B1_FAM), '99')

PARA GERAR A DIMENSÃO GRUPO FOI REALIZADO O SEGUINTE SQL:

SELECT BM_GRUPO, BM_DESC

FROM ADM_SIGA.SBM010

WHERE D_E_L_E_T_ <> '*'

UNION ALL

SELECT '9999', 'OUTROS'

FROM DUAL

PARA GERAR A DIMENSÃO GRUPO FOI REALIZADO O SEGUINTE SQL:

SELECT ZZ1_CODIGO, ZZ1_DESCRI

84

FROM ADM_SIGA.ZZ1010

WHERE (D_E_L_E_T_ <> '*')

UNION ALL

SELECT '99', 'OUTROS'

FROM DUAL

PARA GERAR A DIMENSÃO CLIENTE FOI REALIZADO O SEGUINTE SQL:

SELECT A1_COD, A1_LOJA, A1_NOME, A1_CGC, A1_PESSOA, A1_EST,

A1_TEL, A1_CONTATO, A1_EMAIL

FROM ADM_SIGA.SA1010

WHERE D_E_L_E_T_ <> '*'

UNION ALL

SELECT '999999'

A1_COD, '99' A1_LOJA, 'INDEFINIDO' A1_NOME, '' A1_CGC, '' A1_PESSOA,

'' A1_EST, '' A1_TEL, '' A1_CONTATO, '' A1_EMAIL

FROM DUAL

PARA GERAR A DIMENSÃO GERENTE FOI REALIZADO O SEGUINTE SQL:

SELECT A3_COD, A3_NOME


WHERE

A3_COD IN

(SELECT DISTINCT A3_GEREN

85


WHERE D_E_L_E_T_ <> '*') AND D_E_L_E_T_ <> '*'

UNION ALL

SELECT '900000', 'INDEFINIDO'

FROM DUAL

PARA GERAR A DIMENSÃO VENDEDOR FOI REALIZADO O SEGUINTE

SQL:

SELECT A3_COD, A3_NOME, A3_TEL, A3_EMAIL,

NVL(TRIM(A3_GEREN),'900000')

FROM

ADM_SIGA.SA3010

WHERE (D_E_L_E_T_ <> '*')

UNION

ALL

SELECT '900000', 'INDEFINIDO', '', '', '900000'

FROM DUAL

PARA GERAR A FATO FOI REALIZADO O SEGUINTE SQL:

SELECT ADM_SIGA.SD2010.D2_COD, ADM_SIGA.SD2010.D2_QUANT,

ADM_SIGA.SD2010.D2_TOTAL AS D2_TOTAL,

ADM_SIGA.SD2010.D2_PRUNIT AS PRECO_MIN,

ADM_SIGA.SD2010.D2_PRUNIT

* ADM_SIGA.SD2010.D2_QUANT AS MIN_TOT,

86

ADM_SIGA.SF2010.F2_CLIENTE, ADM_SIGA.SF2010.F2_LOJA,

ADM_SIGA.SF2010.F2_EMISSAO,

NVL(TRIM(ADM_SIGA.SF2010.F2_VEND1), '999999')

AS F2_VEND1, NULL AS QTD_DEVOL, NULL AS DEVOLUCAO,

DECODE(SIGN(ADM_SIGA.SD2010.D2_PRCVEN - ADM_SIGA.SD2010.D2_PRUNIT),

0, 1, 1,

1, - 1) AS IND_PRCMIN

FROM

ADM_SIGA.SD2010, ADM_SIGA.SB1010, ADM_SIGA.SF2010,

ADM_SIGA.SC5010,

ADM_SIGA.SF4010

WHERE ADM_SIGA.SD2010.D2_COD = ADM_SIGA.SB1010.B1_COD

AND ADM_SIGA.SD2010.D2_FILIAL = ADM_SIGA.SF2010.F2_FILIAL AND

ADM_SIGA.SD2010.D2_DOC = ADM_SIGA.SF2010.F2_DOC

AND ADM_SIGA.SD2010.D2_SERIE = ADM_SIGA.SF2010.F2_SERIE AND

ADM_SIGA.SD2010.D2_CLIENTE = ADM_SIGA.SF2010.F2_CLIENTE

AND ADM_SIGA.SD2010.D2_LOJA = ADM_SIGA.SF2010.F2_LOJA AND

ADM_SIGA.SD2010.D2_FILIAL = ADM_SIGA.SC5010.C5_FILIAL

AND ADM_SIGA.SD2010.D2_PEDIDO = ADM_SIGA.SC5010.C5_NUM AND

87

ADM_SIGA.SD2010.D2_TES = ADM_SIGA.SF4010.F4_CODIGO

AND (ADM_SIGA.SF4010.F4_DUPLIC = 'S') AND (ADM_SIGA.SF2010.D_E_L_E_T_

<> '*')

AND (ADM_SIGA.SD2010.D_E_L_E_T_

<> '*') AND (ADM_SIGA.SC5010.D_E_L_E_T_ <> '*') AND

(ADM_SIGA.SF4010.D_E_L_E_T_

<> '*') AND

(ADM_SIGA.SB1010.D_E_L_E_T_

<> '*')

5.4.6 Dimensões e consultas modeladas para o cubo JUNIOR

FIGURA 28 – CUBO JUNIOR Consultas realizadas pelo usuário

88

FIGURA 29 – CONSULTA PREÇO MÍNIMO Nesta consulta é verificado conforme documentado nas regras de negócio as vendas que tiveram seu preço de venda abaixo do preço mínimo estabelecido pela empresa, estes valores estão destacados no item regra preço mínimo igual a sim

FIGURA 30 – CONSULTA CRÉDITO Nessa consulta é verificado, conforme documentado nas regras de negócio, as vendas que

tiveram seu preço de venda acima do previsto no cadastro do cliente que indica o crédito de

cada cliente, ou seja, qual o máximo possível a ser vendido para este cliente.

89

6. CONSIDERAÇÕES FINAIS

O SADBO foi desenvolvido utilizando o conceito de data mart e construção de cubos, devido

a sua menor complexidade em função do prazo curto para a implementação do sistema e o

fato deste ser o primeiro projeto envolvendo OLAP, que será desenvolvido para a empresa

JUNIOR Indústria e Comércio Ltda.

A necessidade e a decisão de desenvolver este TCC, focado em tomada de decisão junto a

empresa JUNIOR, foram levadas em conta, principalmente, pelo fato da Empresa já possuir

há quatro anos um sistema de gestão (MICROSIGA), que ocasionou altíssimos investimentos

e gerou ganhos muito pequenos em relação ao investimento, ocasionando descrédito em

relação a investimentos em sistemas.

Na verdade, observou-se que o grande questionamento e o grande desejo dos gestores eram,

principalmente, relacionados à informação, acreditando-se tratar-se de um problema não só

dessa Empresa mas da maioria das empresas que investem verdadeiras fortunas em sistemas

de gestão e não conseguem dimensionar o ganho deste investimento. A maioria dos sistemas

de gestão de pequeno a médio porte tem sua parte de relatório extremamente fraca e estática,

gerando informações fracas e de difícil leitura. O resultado é que os relatórios do Microsiga

tinham que ser transferidos manualmente para o Excel e estruturados de uma forma que o

gestor necessitaria, porém, novamente, o relatório permanece estático, além de consumir

várias horas de um funcionário.

Dessa forma, o sistema de gestão está fazendo a sua parte, que é operacionalizar a empresa e

integrar as diversas áreas (compras, produção, financeiro, etc,). A falta de informação, embora

crítica, não é o foco dos sistemas de gestão, porém eles abastecem com riquíssimas

informações os bancos de dados. A dificuldade está em transformar esse verdadeiro tesouro

de informações em algo agradável, simples e dinâmico para os gestores, de forma que eles

possam fazer o que realmente é o seu foco, gerir a empresa e não decifrar dados.

Além de ser um trabalho de pesquisa/desenvolvimento para a conclusão de curso, o objetivo

foi iniciar o conceito de sistemas de informações dentro da empresa, com baixos custos de

investimento. Como o SQL utilizado foi o MSDE, que é gratuito e apresenta algumas

limitações que não impediriam a realização do trabalho, e a ferramenta de consulta utilizada

90

ter sido o Excel, que a maioria das empresas já possuem, a Empresa não precisou fazer

nenhum investimento inicial em software.

Nas primeiras demonstrações do produto já se pode perceber o entusiasmo por parte dos

gestores, mesmo sem a vantagem da internet. Consultas que levavam horas para serem

elaboradas e, ao final, já estavam desatualizadas, puderam ser confeccionadas pelo próprio

gestor em segundos.

Verificou-se que o Excel 2003, como ferramenta de consulta a cubos, possui algumas

limitações e dificuldades, porém ele já agregou grandes avanços na empresa, principalmente

cultural de utilização de ferramentas de BI. Com o sucesso do trabalho surgiu a necessidade

de explorar novas ferramentas de mercado e implementar novos cubos na área financeira e de

produção.

91

ANEXO 1

QUESTIONÁRIO GESTORES Foi entregue este questionário aos seguintes gestores: Carlos Aragão (Presidente) Eloir (Diretor Comercial) Roberto (Gerente de produção) Sandro (Supervisor comercial)

1) Quais as rotinas periódicas que são utilizadas para decisão na área comercial 2) Quais os indicadores mais importantes na empresa para tomada de decisão?

3) Quais as informações mais importantes dos concorrentes necessárias para tomadas de

decisão, sobre um negocio especifico e sobre as vendas de forma geral?

4) Quais mix de produtos de maior faturamento?

5) Quais itens de despesas comerciais mais representativos?

6) Quais são os clientes mais representativos e quais as diferenças de ações especificas para eles?

7) Quais fornecedores mais representativos?

8) Quais negócios com maior rentabilidade?

9) Quais são as metas de participação de mercados a serem atingidas?

92

ANEXO 2

TABELAS UTILIZADAS PARA A CARGA

93

94

95

96

97

98

99

100

101

102

REFERÊNCIAS BIBLIOGRÁFICAS

ALMEIDA, L.B. Sistemas de informações de gestão econômica. São Paulo: Atlas, 1999.

BEUREN, I. M. Gerenciamento da informação: um recurso estratégico no processo de gestão empresarial. São Paulo: Ed Atlas, 1998.

CHOO, C. W. The knowing organization. Oxford: Oxford University Press, 1998.

DRUCKER, Peter. Sociedade Pós-Capitalista. São Paulo: Pioneira, 1993. Coleção Novo Umbrais. Trad. Nivaldo Montingelli Jr. 186 p.

ETZIONI, Amitai. Organizações modernas. 8ª. Ed. São Paulo: Pioneira 1989.

FURLAN, J. D.; IVO, I. M.; AMARAL, F. P. Sistema de informação executiva. São Paulo: Makron Books, 1994.

GALBRAITH, Jay R; LAWER, Edward. Organizando para competir o futuro. 1995.

Wikipedia. Data Mart. Disponível em <http://pt.wikipedia.org>.Acessado em 16/08/2006.

HAMMOND, J. S.; KEENEY, R. L.; RAIFFA, H. The hidden traps in decision making. Harvard Business Review, Boston, v.76, n. 5, p. 47-58, sep./oct. 1998.

INMON, W.H. Como Construir o Data Warehouse. Rio de Janeiro: Editora Campus, 1997.

INFOBRAS: projetos e sistemas. 2004. Disponível em: <http//www.escelsanet.com.br/ usuarios/infobras/DataWarehouse.html>. Acesso em: 7 ago. 2004.

INMON, W. H. (1997). Como Construir o Data Warehouse. Rio de Janeiro, Campus.

KIM, R. Data warehouse toolkit. São Paulo: Makron Books, 1995.

KIMBALL, R. (1998). Data Warehouse Toolkit. São Paulo, Makron Books.

LEITÃO, C. N. Construção de aplicações com o uso de ferramentas OLAP: artigo científico. [2000]. Disponível em: <http://genesis.nce.ufrj.br/dataware/DataWarehouse/Proj_Finais/ Claudia_Nolla/Projeto%20Final.pdf > Acesso em 8 set. 2004.

LAUDON, K.; LAUDON, J. Sistemas de informação. Rio de Janeiro: Livros Técnicos e Científicos S.A., 1999.

MACHADO, F. N. R. Projeto de data warehouse – uma visão multidimensional. São Paulo: Érica, 2000.

MCLEOD, JR. Sistemas de informações gerenciais. São Paulo: Makron Books, 1993.

MINTZBERG, Henry; QUINN, JAMES A. O' BRIEN. O processo da estratégia. 3 ed. Porto Alegre: Bookman, 2001.

http://genesis.nce.ufrj.br/dataware/DataWarehouse/Proj_Finais/%20Claudia_Nolla/

http://genesis.nce.ufrj.br/dataware/DataWarehouse/Proj_Finais/%20Claudia_Nolla/

103

MOSIMANN, C. P.; ALVES, O. C.; FISCH, S. Controladoria: seu papel na administração de empresas. Florianópolis: UFSC, 1993.

MURAKAMI, Milton. Decisão estratégica em TI: estudo de caso. 2003. Tese (Doutorado em Administração) – Faculdade de Economia, Administração e Contabilidade, Universidade de São Paulo, São Paulo, 2003.

O’BRIEN, J. A. Sistemas de informação e as decisões gerenciais na era da Internet. São Paulo: Saraiva, 2001.

OLIVEIRA, D. P. R. Sistemas de informações gerenciais: estratégicas, táticas e operacionais. São Paulo: Atlas, 1992.

PETKOVIC, D. SQL Server 7 – Guia prático. São Paulo: Makron Books, 1999.

RCI: business intelligence integrator. 2004. Disponível em: <http//www.rci.com.br>. Acesso em: 21 ago. 2004.

REZENDE, Denis Alcides; ABREU, Aline França de. Tecnologia de informação aplicada a sistemas de informação empresariais. São Paulo: Atlas, 2000.

RUBINI, Eduardo R. C. OLAP – Transformando dados em informações estratégicas. Curitiba, [1999]. Disponível em: <http://www.treetools.com.br/artigos/warehouse.htm>. Acesso em: 16/03/2002.

SIA: sistemas de informática e automação. 2004. Disponível em: < http://www.sia.com.br/tm1/ indexolap.htm>. Acesso em: 4 ago. 2004.

SINGH, H. Data warehouse. São Paulo: Makron Books, 2001.

STAIR, R. M. Princípios de sistemas de informação: uma abordagem gerencial. Rio de Janeiro: Livros Técnicos e Científicos, 1998.

SPRAGUE JR, R. H. Estrutura para o desenvolvimento de apoio a decisão. Rio de Janeiro: Campus, 1991.

SHIMIZU, Tamio. Decisão nas organizações: introdução aos problemas de decisão encontrados nas organizações e nos sistemas de apoio a decisão. São Paulo: Atlas, 2001.

SERRA, J. América Latina: ensaios de interpretação econômica. Rio de Janeiro: Paz e Terra, 1976.

STRYKER, P. Você pode analisar este problema? In: Harvard business review: tomada de decisão. Rio de Janeiro: Campus, 2001. p. 93-106.

THOMSEN, E. OLAP – Construindo sistemas de informações multidimensionais. Rio de Janeiro: Campus, 2002.

TURBAN, E.; ARONSON, J. E. Decision support systems and intelligent systems. 5. ed. Englewood Cliffs: Prentice Hall, 1998

http://www.treetools.com.br/artigos/warehouse.htm

http://www.sia.com.br/tm1/

104

ASSINATURAS

______________________________________ Acadêmico: Ivo José Soares Junkes

___________________________________________________ Professor Orientador: Mest. Luiz Eduardo Pefeito Nunes

Documents

UNIVERSIDADE DO VALE DO ITAJAÍ - siaibib01.univali.brsiaibib01.univali.br/pdf/Ivo Jose Soares Junkes.pdf · Os gerentes e diretores, ... dos diretores de empresa consultados admitem