Fortulan Tese Mestrado

Sistema de apoio deciso com base em Business Intelligence e
Data Warehouse na
OCP Portugal Produtos Farmacuticos, SA
Nuno Andr Domingues Ferreira Dias
Dissertao de Mestrado
Orientador na FEUP: Prof. Doutor Antnio Carvalho Brito

Orientador na OCP Portugal Produtos Farmacuticos, SA: Jos Miguel Silva
Faculdade de Engenharia da Universidade do Porto

Mestrado Integrado em Engenharia Industrial e Gesto
2013-07-15
Sistema de apoio deciso com base em Business Intelligence e Data Warehouse
Aos meus pais e amigos

Dont judge each day by the harvest you reap, but by the seeds you plant.
Robert Louis Stevenson (1850-1894)
ii
Resumo
A OCP Portugal, SA uma empresa distribuidora farmacutica, que no est alheia aos cortes
do Estado no setor da Sade e, por via disso, assume ainda mais importncia o bom
relacionamento com os clientes (CRM), a capacidade de resposta s suas exigncias e as
parcerias com os fornecedores.
neste contexto que o projeto Data Warehouse surge devido a essa necessidade da OCP
Portugal, SA ter um sistema de informao atualizado, acessvel, claro e completo, capaz de
ajudar os seus gestores a tomar decises de natureza ttica ou estratgica. Para a sua
implementao, a empresa socorreu-se do apoio da GEHIS para modelar a arquitetura do
Data Warehouse. O Data Warehouse consiste num repositrio central de dados que armazena
a informao existente nos sistemas de informao internos da organizao e permite a
integrao desses sistemas. A restituio da informao armazenada no Data Warehouse ser
assegurada por uma ferramenta de reporting o MicroStrategy. Este software de Business
Intelligence tem como objetivo fornecer informao correta pessoa certa, assegurando a
qualidade dos dados e promovendo a capacidade de integrao das diferentes aplicaes do
sistemas de informao.
Atravs do aproveitamento da capacidade de restituio de informao do MicroStrategy
concebeu-se ainda um projeto complementar de forecasting. Este projeto tem como objetivo
sensibilizar a organizao para uma melhor eficincia de compras a fornecedores de forma a
evitar ruturas e excessos de stock.
Em sntese, a implementao do projeto Data Warehouse possibilita que a empresa tenha
sua disposio uma ferramenta de software autnoma e flexvel que permite a apresentao de
relatrios da sua atividade em tempo-real, reduz o uso e o acesso ao ambiente operacional,
melhora a acessibilidade aos dados relevantes para o negcio, reduz o tempo de tomada de
decises e diminui os recursos necessrios para a elaborao dos relatrios obrigatrios.
iii
Decision support system based on Business Intelligence and Data

Warehouse
Abstract
Being OCP Portugal, SA a pharmaceutical wholesaler, which is not alien to the cuts of the
State in the health sector, this aspect assumes greater importance since it is known that the
customer relationship (CRM), responsiveness to their requirements and liaise with suppliers
are the basis of success of such organizations.
It is in this context that the Data Warehouse project arises due to the need of OCP Portugal,
SA to have an information system updated, accessible, clear and complete, able to help
managers to make tactical or strategic decisions. For its implementation, the company
resorted to the support of GEHIS to model the architecture of Data Warehouse. Data
Warehouse consists in a central repository that stores data from different information systems
that are integrated in the organizations. It allows the connection between those systems. The
information that is stored in the Data Warehouse is shown by a Business Intelligence
reporting tool called MicroStrategy. This tool aims to provide correct information to the right
person, ensuring data quality and promoting the ability to integrate different applications of
the information systems.
Resorting to the use of the potentials of MicroStrategy it was also conceived a complementary
project of forecasting. This project aims to improve the efficiency of the organization in order
to avoid stock-outs and overstocks.
In summary, the implementation of the Data Warehouse project enables that the company has
at its disposal an autonomous and flexible software tool that allows the reporting of its
activities in real time, reduces the use and access to the operating environment, improves the
data accessibility relevant to the business, reduces the time of decision making and reduces
the resources needed for the preparation of required reports.
iv
Agradecimentos
Gostaria de agradecer ao orientador da organizao, Jos Miguel Silva, pela orientao,

disponibilidade e apoio demonstrado ao longo do perodo do estgio.
A ajuda do colaborador Augusto Ribeiro do Departamento de TI da OCP Portugal, SA foi
essencial para a concretizao do projeto dado que este esteve envolvido no projeto desde a
sua conceo.
Gostaria de agradecer a todos os colaboradores da OCP Portugal, SA diretamente envolvidos
no projeto j que partilharam as suas opinies, pontos de vista e expetativas de reports que
pretendiam ter consultar.
Queria tambm agradecer ao colaborador e membro da GEHIS, Peter Autenrieth, que com o
seu apoio e disponibilidade foi resolvendo os problemas identificados e esclarecendo dvidas
sobre o software MicroStrategy.
Gostaria tambm de agradecer a todos os colaboradores da OCP Portugal, SA que, mesmo
no estando diretamente ligados ao projeto, tiveram um papel fundamental na minha
integrao pois fui muito bem recebido e sempre cordialmente tratado.
Um agradecimento especial ao orientador da Faculdade, Prof. Doutor Antnio Carvalho Brito,
pelo acompanhamento prestado na realizao da tese, partilhando as suas ideias e
contribuindo com o seu know-how no tema.
Por fim, gostaria de agradecer a empresa por ter aliado esta primeira experincia profissional
ao pagamento de uma bolsa de estgio, proporcionando um estmulo e motivao extra que
foram fundamentais para o sucesso do projeto.
ndice de Contedos
1 Introduo ........................................................................................................................................... 1
1.1 Apresentao da OCP Portugal, SA .................................................................................................... 1
1.2 Descrio do circuito interno de vendas............................................................................................... 1
1.3 O projeto Data Warehouse na OCP Portugal, SA ................................................................................ 2
1.4 Mtodo seguido no projeto ................................................................................................................... 3
1.5 Sntese dos objetivos do projeto .......................................................................................................... 3
1.6 Organizao e temas abordados ......................................................................................................... 4
2 Enquadramento Terico ...................................................................................................................... 5

2.1 A importncia da informao nas organizaes ................................................................................... 5
2.2 Necessidades das organizaes .......................................................................................................... 5
2.3 O conceito de Data Warehouse ........................................................................................................... 6
2.4 Modelao entidade-relao ................................................................................................................ 7
2.5 Modelao dimensional........................................................................................................................ 8
2.6 Arquitetura de um DW ........................................................................................................................ 10
2.6.1 Fontes externas de comunicao ...................................................................................................... 10
2.6.2 Data Staging Area .............................................................................................................................. 11
2.6.3 Data Presentation Area ...................................................................................................................... 11
2.6.4 Ferramentas de acesso aos dados .................................................................................................... 12
2.7 Objetivos do DW ................................................................................................................................ 13
2.8 Business Intelligence ......................................................................................................................... 14
3 Estado atual da OCP Portugal, SA ................................................................................................... 15

3.1 Sistemas de informao internos ....................................................................................................... 16
3.2 Identificao das necessidades ......................................................................................................... 16
3.3 Projeto Data Warehouse .................................................................................................................... 17
3.4 Arranque do projeto ........................................................................................................................... 18
3.5 mbito do projeto ............................................................................................................................... 18
3.6 Infraestrutura do DW .......................................................................................................................... 18
3.7 Data Governance ............................................................................................................................... 21
4 Implementao da soluo BI ........................................................................................................... 24

4.1 Objetivos do projeto ........................................................................................................................... 24
4.2 Soluo proposta ............................................................................................................................... 25
4.2.1 Arquitetura.......................................................................................................................................... 25
4.2.2 Definio dos processos .................................................................................................................... 26
4.2.3 Interpretao dos conceitos ............................................................................................................... 26
4.2.4 Implementao da aplicao.............................................................................................................. 27
4.3 Ferramenta de reporting MicroStrategy.............................................................................................. 27
4.4 Responsabilidades no projeto ............................................................................................................ 29
4.5 Metodologia seguida .......................................................................................................................... 30
4.5.1 Anlise ............................................................................................................................................... 31
4.5.2 Modelao.......................................................................................................................................... 32
4.5.3 Implementao................................................................................................................................... 33
4.5.4 Passagem a qualidade ....................................................................................................................... 34
4.5.5 Testes de aceitao ........................................................................................................................... 35
vi
4.5.6 Passagem a produo ....................................................................................................................... 35

4.6 Estrutura da soluo final ................................................................................................................... 35
4.6.1 Armazns ........................................................................................................................................... 37
4.6.2 Fornecedores ..................................................................................................................................... 38
4.6.3 Produtos ............................................................................................................................................. 39
4.6.4 Documentos ....................................................................................................................................... 39
4.6.5 Margens ............................................................................................................................................. 40
4.6.6 Stocks ................................................................................................................................................ 41
4.6.7 Vendas ............................................................................................................................................... 41
4.7 Definio de indicadores de performance .......................................................................................... 42
4.8 Forecasting ........................................................................................................................................ 45
5 Anlise crtica aos resultados obtidos e perspetivas de trabalho futuro ........................................... 47

Referncias ............................................................................................................................................ 50
ANEXO A:
Funcionamento do SSD................................................................................................ 53
ANEXO B:
Fases detalhadas do projeto na perspetiva da GEHIS ................................................ 54
ANEXO C:
Objetivos da reunio intermdia com a GEHIS e Celesio ............................................ 55
ANEXO D:
ndice e Introduo do Manual de utilizao desenvolvido no projeto ......................... 57
ANEXO E:
Exemplo de um grfico do MicroStrategy com informao omitida ............................. 60
ANEXO F:
Dados do caso prtico e formulao do problema ....................................................... 61
vii
Siglas
BI Business Intelligence
BSC Balanced Scorecard
CMV Custo das Mercadorias Vendidas
DW Data Warehouse
EDW Enterprise Data Warehouse
ERP Enterprise Resource Planning
ETL Extraction-Transformation-Loading
OLAP Online Analytical Processing
OLTP Online Transactional Processing
PVF Preo de Venda a Farmcias
PVP Preo de Venda ao Pblico
SSD Sistema de Suporte Deciso
TI Tecnologias de Informao
viii
ndice de Figuras
Figura 1 - Funcionamento simplificado do SSD. Fonte: GEHIS (2010) ................................... 2

Figura 2 - Fases do projeto Data Warehouse. Fonte: GEHIS (2010) ......................................... 3
Figura 3 - Diagrama de Gantt com as fases do projeto. Adaptado: OCP Portugal, SA (2013) .. 4
Figura 4 - Arquitetura do DW segundo a perspetiva de Inmon. Fonte:
http://www.dwhinfo.com/Technical/DWHApproach.html ........................................................ 7
Figura 5 - Arquitetura do DW segundo a perspetiva de Kimball. Fonte:
http://www.dwhinfo.com/Technical/DWHApproach.html ........................................................ 9
Figura 6 - Elementos que constituem um Data Warehouse. Fonte: Kimball and Ross (2011) 10
Figura 7 - Exemplo de um template do OLgA com valores fictcios ....................................... 16
Figura 8 Acesso direto base de dados. Fonte: GEHIS (2010) ............................................ 19
Figura 9 - Transferncia direta de dados. Fonte: GEHIS (2010).............................................. 20
Figura 10 Transferncia de dados por flat files. Fonte: GEHIS (2010) ................................ 21
Figura 11 - Responsveis do projeto e respetivas tarefas. Fonte: Celesio ................................ 23
Figura 12 - Necessidades a satisfazer ....................................................................................... 24
Figura 13 Arquitetura do DW................................................................................................ 25
Figura 14 - Framework do MicroStrategy ................................................................................ 29
Figura 15 - rea de criao de reports ..................................................................................... 29
Figura 16 Metodologia seguida do projeto ............................................................................ 30
Figura 17 - Exemplo de diagrama entidade-relao relacionado com a faturao. Fonte: OCP
Portugal, SA ............................................................................................................................. 31
Figura 18 - Exemplo de um modelo dimensional. Adaptado: Kimball and Ross (2011) ........ 33
Figura 19 - Teste de uma query com resultados fictcios ......................................................... 34
Figura 20 - Estrutura da soluo final ...................................................................................... 36
Figura 21 - Exemplo de um prompt ......................................................................................... 36
Figura 22 - Exemplo de um report com detalhe dos diferentes componentes com dados
fictcios ..................................................................................................................................... 37
Figura 23 - Mapa estratgico adaptado para a organizao...................................................... 44
Figura 24 - Quantidade procurada real e prevista com valores fictcios .................................. 46
ix
ndice de Tabelas
Tabela 1 - Anlise PEST do contexto nacional ........................................................................ 15

Tabela 2 - Anlise SWOT desenvolvida OCP Portugal, SA ................................................. 17
Tabela 3 Objetos tpicos de um repositrio de Metadata. Fonte: Sthr, Mller and Rahm
(1999) ....................................................................................................................................... 28
Tabela 4 - Componentes do Data Warehouse. Fonte: Kimball and Ross (2011) ..................... 32
Tabela 5 - Estrutura dos reports cujo objeto de anlise o armazm ...................................... 38
Tabela 6 - Estrutura dos reports cujo objeto de anlise o fornecedor .................................... 38
Tabela 7 - Report que avalia a expresso dos clientes de um determinado fornecedor ........... 39
Tabela 8 - Estrutura de reports cujo objeto de anlise o produto .......................................... 39
Tabela 9 - Estrutura de reports cujo objeto de anlise o tipo de documento e contrato ........ 40
Tabela 10 - Estrutura dos reports cujo foco so as margens de um determinado objeto de
anlise ....................................................................................................................................... 41
Tabela 11 - Estrutura dos reports cujo foco so os stocks remanescentes em armazm ao final
do dia ........................................................................................................................................ 41
Tabela 12 - Estrutura de reports cujo foco so as vendas de um determinado objeto de anlise
.................................................................................................................................................. 42
Tabela 13 - Indicadores de performance da organizao ......................................................... 43
Tabela 14 - Valores previstos para a procura de clientes ......................................................... 46
Introduo
No mbito da dissertao realizada no 2 semestre do 5 ano do Mestrado Integrado em

Engenharia Industrial e Gesto, o presente projeto visava o estudo e a aplicabilidade de uma
soluo de Business Intelligence (BI), denominada de Data Warehouse (DW). O projeto tinha
como principal objetivo o reporting, atravs de um software designado de MicroStrategy,
para o Departamento de Marketing e Vendas da empresa OCP Portugal, SA.
1.1
Apresentao da OCP Portugal, SA
A OCP Portugal, SA uma empresa de capital alemo, integrando o maior grupo europeu de
distribuio farmacutica Celesio , com sede em Estugarda. A Celesio faz parte do grupo
Haniel, que opera a nvel mundial em diversos setores de atividade. Atualmente, a Celesio
est presente em 15 pases e conta com cerca de 39.000 colaboradores, sendo lder na venda
de produtos farmacuticos na Europa e no Brasil.
A OCP Portugal, SA resultou da fuso das sociedades de distribuio farmacutica, J.C.
Crespo e Drogaria Castilho, operada em 1995. A estratgia adotada consistiu na aquisio de
empresas j instaladas no setor no sentido obter dimenso crtica bem como aumentar a sua
quota de mercado. Deste modo, a Diprofar e a C.F.R. foram adquiridas e integradas na OCP
Portugal, SA em 2000 e 2001, respetivamente. Em 2005, adquire nova empresa do setor, a
Soquifa Medicamentos, SA, passando a ser a segunda maior empresa de distribuio do setor
farmacutico a operar no mercado nacional.
No incio do milnio procedeu reestruturao da sua rede logstica, localizando
estrategicamente os pontos de distribuio no territrio nacional, de forma a obter economias
de escala e assegurar a melhor cobertura do territrio continental, atravs de equipamentos
mais modernos e tecnologicamente avanados. Foi neste contexto que investiu nos armazns
de Alverca, Setbal, Torres Novas, Rgua, Viseu, Braga e da Maia, onde tem a sua sede.
Para alm de se dedicar comercializao e distribuio de produtos farmacuticos, a
empresa tambm apresenta no seu mapa de vendas artigos de cosmtica, perfumaria, diettica,
medicina natural, dispositivos mdicos, acessrios para farmcia e matrias-primas
relacionadas, procurando assegurar a colocao dos seus produtos no cliente da forma mais
eficiente e segura.
1.2
Descrio do circuito interno de vendas
A empresa tem o seu Departamento de Compras centralizado no armazm da Maia, sendo este
Departamento responsvel pelo aprovisionamento dos produtos nos vrios armazns. Aps
anlise de stocks e de acordo com o grau de rotao dos produtos, o Departamento de
Compras gera as notas de encomenda ao fornecedor, com indicao de entrega por armazm.
Cada armazm tem um setor de encomendas, que deve atualizar informaticamente as suas
existncias em armazm. Os clientes podem encomendar os produtos de que necessitam
atravs de telefone, fax ou e-mail para o Call Center bem como atravs do site da empresa. A
maioria dos clientes tem um programa informtico que comunica com um modem/servidor
(SGG) indicando os produtos e as respetivas quantidades. Segue-se o processo de aviamento
onde se recorre a um processo sofisticado de recolha dos artigos solicitados. Os produtos so
expedidos e acompanhados dos respetivos documentos de transporte. A entrega das
1
encomendas a clientes feita de acordo com um sistema de distribuio, que tem em conta as
reas geogrficas de influncia de cada armazm e as janelas de entrega a cada cliente. Todo
este fluxo de informao monitorado e sujeito a constantes atualizaes, em cada rea de
atuao, no sistema de informao chave da organizao OLgA.
1.3
O projeto Data Warehouse na OCP Portugal, SA
Num mundo empresarial fortemente competitivo, cada vez mais a organizao tem
necessidade de conhecer bem os seus clientes, de forma a ir ao encontro das suas necessidades
e anseios, maximizando proveitos e reduzindo custos. A Celesio, atenta a estes fatores,
pretende que as empresas do grupo satisfaam os seus clientes de forma eficiente e eficaz e
antecipem eventuais alteraes do mercado com o auxlio do projeto Data Warehouse. Por
isso, investiu num sistema de base de dados designado de DW com capacidade para
armazenar informao de todas as empresas do grupo que estejam interessadas no projeto, na
expetativa de aumentar os seus ganhos e rendimentos. Os dados so armazenados num
servidor de uma das empresas do grupo, a GEHIS, que tem uma vasta experincia em
sistemas de BI. Aliada a esta soluo, a GEHIS negoceia licenas do software de BI
MicroStrategy, reduzindo os custos da soluo s empresas. Estas ferramentas de BI so
responsveis pelo reporting de informao proveniente dos sistemas operacionais.
O projeto Data Warehouse procurou responder a estas necessidades da OCP Portugal, SA
como objetivos principais a apresentao de reports da sua atividade em tempo-real, a
reduo da utilizao do ambiente operacional e a melhoria da acessibilidade aos dados
relevantes para o negcio. Atravs de uma correta interpretao da informao gerada pelos
reports do MicroStrategy, a organizao capaz de tomar decises de ordem ttica e
estratgica, podendo suport-las com o seu armazm de dados. A Figura 1 resume a forma
como o Sistema de Suporte Deciso (SSD) aplicado na OCP Portugal, SA.
Figura 1 - Funcionamento simplificado do SSD. Fonte: GEHIS (2010)
Antes da implementao deste projeto, a organizao consumia recursos desnecessrios para

obter relatrios de negcio importantes com o prvio desenvolvimento de queries,
despendendo tempo e dinheiro. Era necessrio contactar o Departamento de Tecnologias de
Informao (TI) para programar essas queries no sentido de gerar os resultados para os
relatrios desejados. Deste modo, os relatrios surgiam sempre com algum atraso e, s vezes,
sem a totalidade da informao exigida.
2
Atravs desta soluo de BI e a conceo de um Manual de utilizao do MicroStrategy para

os utilizadores finais procuram-se simplificar procedimentos, reduzindo o nmero de
solicitaes de desenvolvimento de queries ao Departamento de TI.
1.4
Mtodo seguido no projeto
Aps um acordo estabelecido por parte das empresas que integram a Celesio e a mesma, ficou
definido que todos os dados das organizaes seriam migrados para a GEHIS. A GEHIS
uma empresa alem que opera ao nvel aplicaes empresariais, mas que tem uma vasta
experincia e know-how ao nvel de SSD e de BI. A GEHIS conta com 15 anos de experincia
na rea de BI e DW. Assim, a sua contribuio neste projeto tornou-se bastante til dado que
esta apresenta infraestruturas de TI sofisticadas.
A metodologia seguida pela GEHIS em projetos de DW bem definida e visa garantir a
qualidade da informao restituda aos utilizadores finais (Figura 2).
Figura 2 - Fases do projeto Data Warehouse. Fonte: GEHIS (2010)
Inicialmente foram realizadas entrevistas internas a vrios membros do Departamento de

Vendas e Marketing e analisaram-se documentos comerciais para avaliar criticamente a
informao recolhida e definir indicadores de performance adequados para apurar a eficincia
dos processos de negcio da empresa. Deste modo, tornou-se possvel o mapeamento e a
definio de modelos de report sentidos como essenciais pela organizao.
A fim de apurar a consistncia dos dados foi necessrio elaborar um conjunto de testes atravs
do desenvolvimento de reports no MicroStrategy e sua comparao com os resultados de
queries no SQL Developer. Aps o apuramento dos resultados eram discutidas as eventuais
diferenas obtidas e enviadas para a GEHIS que, em conjunto com o Departamento de TI da
OCP Portugal, SA, identificaram a origem e procediam posterior correo. Efetuada a
anlise qualidade dos dados, o foco incidiu em estabelecer a criao de reports. Nesta fase
final, definiu-se uma estrutura de disposio lgica dos elementos a analisar, onde foram
criados reports a fim de permitir ao utilizador a disponibilizao imediata da informao de
forma simples.
1.5
Sntese dos objetivos do projeto
Sendo a OCP Portugal, SA uma empresa que opera num setor altamente competitivo, torna-se
vital encontrar vantagens competitivas sustentveis face aos seus concorrentes. Uma boa
forma de obter essa vantagem passa por fazer uma anlise competente da informao
3
recolhida pelos seus sistemas de informao. Contudo, tal nem sempre fcil visto que
muitos sistemas de informao operacionais so independentes uns dos outros, no
permitindo uma anlise integral da informao. Atravs desta necessidade, surgiu o projeto
Data Warehouse.
A soluo de DW proposta permite a restituio da informao dos diferentes sistemas de
informao atravs de um sistema de BI designado de MicroStrategy. Os dados dos trs
sistemas de informao da organizao so armazenados numa base de dados nica DW.
Aps o tratamento dos dados no DW, o passo seguinte a representao da informao
requerida pelo utilizador atravs do MicroStrategy. Com o objetivo de representar a
informao de forma consistente, os gestores podem tomar decises de ndole ttica e
estratgica mais eficientes.
Para estruturar as diversas fases do projeto, foi elaborado um plano com os vrios objetivos e
respetivos deadlines (Figura 3).
Figura 3 - Diagrama de Gantt com as fases do projeto. Adaptado: OCP Portugal, SA (2013)
Inicialmente, a primeira etapa consistiu na interpretao e compreenso da estrutura e do

funcionamento geral da empresa. Esta etapa engloba o reconhecimento das diversas reas
departamentais e suas funes, a compreenso do funcionamento dos sistemas de informao
operacionais e a leitura de documentao relativa empresa e ao grupo. A fase seguinte
prendeu-se com a apresentao do projeto Data Warehouse, sendo evidenciados os
desenvolvimentos feitos at ao momento. Feito o enquadramento do projeto, os prximos
passos foram o da realizao de testes para averiguar a consistncia dos dados, a definio de
reports a elaborar, a anlise dos resultados obtidos e a conceo de um Manual de utilizao.
1.6
Organizao e temas abordados
Feita a Introduo do projeto com a sua caracterizao e definio dos objetivos pretendidos,
apresentam-se de seguida os restantes captulos.
O captulo 2 apresenta o enquadramento terico do projeto, onde se caracterizam os conceitos
subjacentes ao projeto, nomeadamente DW, BI, reporting, entre outros.
O captulo 3 dedicado exposio do problema relativo criao de uma arquitetura
relacional de dados e da respetiva ferramenta de reporting.
O captulo 4 contempla a metodologia seguida para a soluo do problema, descrevendo
pormenorizadamente as vrias etapas. De igual modo, explicam-se as tcnicas e ferramentas
utilizadas. So tambm apresentados os resultados obtidos e respetiva anlise crtica.
Por fim, no captulo 5 so retiradas ilaes sobre o trabalho realizado e perspetivas do
trabalho futuro.
4
Enquadramento Terico
No presente captulo so apresentados os conceitos que ajudam a compreender um ambiente

DW tpico. feita uma abordagem geral das tecnologias DW, enquadrando-as no mbito deste
projeto. No contexto empresarial, demonstra-se como a utilizao destas tecnologias pode
representar uma mais-valia. Por fim, refere-se como a utilizao de um sistema de reporting
serve para auxiliar a tomada de decises.
2.1
A importncia da informao nas organizaes
Um dos ativos mais importantes de qualquer organizao a sua informao (Kimball and
Ross 2011). Num ambiente fortemente competitivo, a informao um fator de excecional
importncia em qualquer empresa por ser um recurso indispensvel quer no seu contexto
interno, quer no seu contexto externo. A informao deve ser relevante, coerente e til, ou
seja, que facilite a planificao estratgica da empresa e que esteja disponvel em tempo-real.
Quanto mais fivel, oportuna e contnua for a informao, maior ser o grau de coeso interna
e de competitividade da empresa. Para isto ser alcanado, torna-se necessrio que na empresa
se crie uma cultura de informao, onde se reconhea a importncia de um correto fluxo de
informaes e se aproveite as oportunidades decorrentes da utilizao adequada das
tecnologias. O acesso informao e a capacidade de obter e aplicar conhecimentos so
cruciais para aumentar a capacidade competitiva e desenvolver as atividades comerciais num
mercado sem fronteiras. Hoje em dia, as vantagens competitivas so obtidas pela utilizao de
redes de comunicao e de sistemas tecnolgicos que interrelacionam empresas, clientes e
fornecedores com rapidez e a baixo custo.
Segundo Alter (1992), um sistema de informao uma combinao de trabalho,
informaes, pessoas e tecnologias de informao organizados para alcanar os objetivos de
uma organizao. Um sistema eficaz e eficiente tem um efeito multiplicador capaz de
dinamizar todos os setores de uma empresa. Deve envolver todos os colaboradores da
empresa, qualquer que seja o setor de atuao. Deste modo, qualquer mudana do
organigrama da empresa no interfere no fluxo de informaes. No entanto, devem existir
vrios canais de informao que possam estabelecer a ligao entre os diferentes
departamentos da empresa. A informao deve chegar ao destinatrio certo, no momento
certo. Verificou-se um incremento da utilizao dos computadores com recurso a programas
mais simples e que fornecem mais informao, contribuindo para o sucesso dos negcios.
2.2
Necessidades das organizaes
Novos desafios tm sido colocados nas organizaes devido globalizao, competio

feroz e ao aumento da complexidade dos processos de negcio. Isto tem conduzido a uma
nova postura por parte das organizaes. Num mundo de negcios que evolui rapidamente,
aquele que se atrasar no acompanhamento do processo evolutivo desaparece. um pouco
semelhana da Teoria de Darwin, em que apenas os mais aptos conseguem sobreviver. De
facto, as organizaes que no conseguirem evoluir tecnologicamente e no acompanharem o
ritmo de evoluo das concorrentes sero menos capazes e aumentam a sua probabilidade de
insucesso e, at mesmo, de falncia.
A necessidade de controlar a informao e interpretar a evoluo do negcio assume, nos dias

de hoje, um carter fundamental para os gestores de qualquer organizao. Segundo a
empresa MicroStrategy (1998), os analistas de deciso necessitam de sistemas que apresentem
as seguintes caractersticas:
2.3
viso concetual e multidimensional dos dados da organizao

suporte consolidao hierrquica dos dados
capacidade de criar conjuntos de critrios complexos que permitam o acesso pontual
da informao desejada
capacidade de aprofundar-se em detalhes que poderiam atingir, em ltima instncia, os
dados operacionais da organizao
rpidos tempos de resposta para as consultas submetidas
O conceito de Data Warehouse
O DW um sistema de BI baseado num banco de dados voltado para consultas complexas,

permitindo a reduo ao acesso dos sistemas operacionais e a obteno de uma viso geral do
negcio da organizao (Turban et al. 2009).
O termo BI foi popularizado por Howard Dresner, em 1989, descrevendo-o como um
conjunto de conceitos e mtodos para melhorar a tomada de deciso do negcio atravs da
utilizao de sistemas de suporte deciso (Power 2007). Um sistema de BI um SSD
orientado aos dados, que suporta consultas (queries) sobre uma base de dados histrica, bem
como a produo de relatrios. O conceito de BI diz respeito gesto de negcio, usando um
conjunto de mecanismos que permitem tomar decises de negcio em curtos espaos de
tempo, visando uma estratgia que permite empresa alcanar uma vantagem competitiva,
face concorrncia (Almeida et al. 1999). BI um termo de gesto utilizado para descrever
aplicaes e tecnologias que so utilizadas para recolher, aceder, e analisar dados e
informao acerca da organizao, ajudando a tomar melhores decises (Liya, Barash, and
Bartolini 2007).
O DW , pois, um banco de dados utilizado para a elaborao de reports e anlise de dados.
William Inmon (1992) definiu o DW como a collection of integrated, subject-oriented, time
variant and nonvolatile databases designed to support the DSS (decision support) function,
where each unit of data is non-volatile and relevant to some moment in time. Trata-se de um
repositrio central de dados que criado por integrao de dados de uma ou mais fontes
diferentes. Um sistema de DW consiste num repositrio especialmente preparado de dados
destinados a suportar a tomada de decises (Reddy et al. 2010). O DW armazena tanto dados
atuais como os histricos provenientes dos sistemas operacionais, sendo usado para auxiliar o
processo de tomada de deciso dos gestores e analistas da organizao. Assim, a chave de
uma arquitetura tpica de um DW centra-se na construo de um repositrio de dados
histricos construdo a partir de um processo de integrao de dados oriundos de diferentes
bases de dados (Dell'Aquila et al. 2008).
Porm, o conceito de DW tem sugerido diferentes definies e interpretaes ao longo do
tempo. Mltiplas so as obras que tm surgido acerca deste tema. Destacando duas
abordagens dos autores mais conceituados nesta rea, possvel identificar algumas
diferenas nos seus pressupostos.
Bill Inmon (1996): Data warehouse is one part of the overall Business Intelligence
system. An enterprise has one data warehouse, and data marts source their information
from the data warehouse. () used to support the business decisions.
Ralph Kimball (2002): Data warehouse is the conglomerate of all data marts within
the enterprise. Information is always stored in the dimensional model.
importante referir que no existe nenhuma perspetiva correta ou errada. Tratam-se apenas
de duas filosofias distintas de interpretar o conceito de DW (Oketunji 2011). Contudo, as
organizaes devem escolher a perspetiva mais adequada tendo em conta as suas necessidades
analticas. Estas duas perspetivas abordadas descrevem assim, as duas tcnicas mais populares
de modelao dos dados no mbito do DW (Sen and Sinha 2005). A perspetiva de Kimball
aproxima-se mais das necessidades de informao em termos empresariais, focando-se
principalmente em aspetos ao nvel da arquitetura de referncia o modelo dimensional.
Inmon, considerado o pai do DW, salienta a necessidade de suporte s decises de negcio
(Gallas 1999). No entanto, ambos os autores concordam que o sucesso de um sistema DW
depende de um levantamento correto dos requisitos de negcio.
2.4
Modelao entidade-relao
Esta tcnica de modelao, defendida por Inmon, descreve o DW como sendo uma base de
dados integrada que usa tcnicas tradicionais de modelao entidade-relao (Sabherwal and
Becerra-Fernandez 2010).
Esta tcnica exige a criao de um repositrio central de dados. Com o objetivo de armazenar
a informao corporativa de negcio, este repositrio designado de Enterprise Data
Warehouse (EDW). usado o processo de extrao, transformao e carregamento da
informao (ETL) para remover as inconsistncias dos dados recolhidos pelos sistemas de
informao operacionais e para integrar e consolidar os dados antes de serem armazenados no
DW. Os dados provenientes dos sistemas de informao operacionais, tambm designados de
Online Transactional Processing (OLTP), so armazenados no repositrio na 3 Forma
Normal no sentido de evitar a sua redundncia (Boehnlein and Ulbrich-vom Ende 1999).
Figura 4 - Arquitetura do DW segundo a perspetiva de Inmon. Fonte:

http://www.dwhinfo.com/Technical/DWHApproach.html
7
Os dados so armazenados no EDW com um grande nvel de detalhe com o objetivo de

alavancar a flexibilidade da informao nos vrios departamentos e de aumentar a capacidade
de responder a necessidades futuras (Hellerstein, Stonebraker, and Caccia 1999). Contudo,
estes ndices de detalhe aumentam a complexidade do projeto e exigem uma maior capacidade
de armazenamento de informao, tornando os custos mais elevados (Jukic and Jukic 2009).
realizado um segundo processo de ETL que permite que os dados armazenados no repositrio
central sejam extrados para os vrios Data Marts que iro apoiar as consultas Online
Analytical Processing (OLAP). OLAP refere-se atividade geral de consulta e realizada a
partir de DWs e/ou Data Marts para fins analticos (Jukic, Jukic, and Malliaris 2008). Um
Data Mart consiste numa fatia da totalidade da organizao, sendo que cada Data Mart
apresenta os dados de um nico processo de negcio. Por outras palavras, o DW um
conjunto de Data Marts (Kimball et al. 2008).
O EDW funciona como a fonte de informao para os Data Marts (Jukic 2006). Uma vez
implementado o repositrio central, so criados Data Marts especficos que contm dados na
forma no-normalizada, tambm designada de esquema em estrela (Inmon 1996). Os dados
nos Data Marts so geralmente sintetizados com base nas necessidades analticas dos
utilizadores finais. A razo pela qual os dados no se encontram normalizados no Data Mart
a de fornecer um acesso mais rpido aos dados para os utilizadores finais.
Esta abordagem de modelao dos dados, tambm conhecida como abordagem top-down, tem
como vantagem a construo de um repositrio centralizado para fornecer uma verso nica
de verdade dos dados empresariais (Lujn-Mora and Trujillo 2005). Este aspeto revela-se
muito importante pois garante a fiabilidade dos dados e a sua consistncia em todas as reas
da organizao. Esta abordagem permite a granularidade dos dados e fornece uma grande
flexibilidade para a criao de Data Marts que vo de encontro s necessidades da
organizao. Porm, esta abordagem tem como desvantagens o facto de ser mais demorada e
exigir maior investimento inicial que a abordagem de Kimball.
Assim, esta abordagem enquadra-se numa perspetiva metodolgica de negcio, onde o
conceito de DW assume-se como uma estratgia que proporciona um ambiente favorvel
tomada de decises. O know-how dos gestores aliado aos SSD e reporting proporciona um
ambiente ttico que facilita a anlise e gesto de todas as informaes de mercado de uma
organizao.
Toda esta metodologia produz resultados sob a forma de relatrios financeiros. Estes
documentos so restitudos aos clientes de modo completamente transparente, ocultando
todos os detalhes de extrao e integrao da informao.
2.5
Modelao dimensional
Esta tcnica de modelao defendida por Ralph Kimball define o DW como sendo uma cpia
de dados de transao especificamente estruturada para consulta e anlise (Kimball and Ross
2002). Ao contrrio de Inmon, Kimball no aborda como o DW construdo, mas sugere que
o foco deve ser dado na sua funcionalidade.
Tal como na perspetiva de Inmon, a integrao e consolidao dos dados recolhidos pelos
sistemas de informao operacionais efetuada atravs do processo ETL. Porm, esta
abordagem implica que os Data Marts sejam modelados previamente, e s em seguida sejam
adicionadas as tabelas de factos, que se encontram ligadas a mltiplas dimenses e que podem
ser partilhadas por mais que uma tabela de factos (List et al. 2002). Como resultado desta
8
abordagem, o DW consiste na coleo de Data Marts interligados dimensionalmente.

Segundo Jukic (2006), a criao de estruturas dimensionais no exige a conceo e definio
de um repositrio central de dados, o que torna a construo de um DW mais simples e rpida.
Figura 5 - Arquitetura do DW segundo a perspetiva de Kimball. Fonte:

http://www.dwhinfo.com/Technical/DWHApproach.html
Esta abordagem, tambm conhecida como bottom-up, sugere uma abordagem incremental
para a construo do DW. Por outras palavras, os diversos Data Marts so construdos
separadamente em fases temporais distintas, quando as necessidades de cada rea
departamental forem esclarecidas (Bonifati et al. 2001). Os Data Marts so, assim,
combinados atravs do uso de dimenses e de factos conformes. Estas dimenses e factos
podem ser partilhados entre os diferentes Data Marts. Cada dimenso corresponde a um
conjunto de atributos que descrevem uma mesma propriedade da ocorrncia, apresentando um
conjunto de chaves, atributos descritivos e valores combinados entre os vrios Data Marts. Os
factos consistem em registos de ocorrncias que tendem a ser mensurveis, sendo muitas
vezes referidos como medidas. Cada facto possibilita a anlise a diferentes nveis de
granularidade e tipicamente so numricos e aditivos (Kimball and Ross 2011).
No sentido de criar dimenses e factos conformes, torna-se necessria a construo de uma
matriz, designada de bus matrix, com as linhas a corresponderem aos vrios Data Marts e as
colunas a corresponderem s tabelas de dimenses (Kimball 1996). Contudo, deve-se ter
cuidado na criao de uma bus matrix complexa pois necessrio identificar corretamente
todas as dimenses possveis para os Data Marts. A utilizao de uma arquitetura bus o
segredo para a construo de sistemas de DW (Kimball and Ross 2010). De facto, nem todas
as organizaes se podem dar ao luxo de construir um DW totalmente centralizado devido s
restries de oramento e tempo. Quando esta arquitetura bus usada como modelo, torna-se
possvel desenvolver um DW de forma descentralizada (e muito mais realista).
A abordagem bottom-up tem como vantagem o facto de no ser necessrio ter o conhecimento
de todas as necessidades da organizao. Basta haver total clareza de um Data Mart para se
poder iniciar a implementao desta abordagem. Em comparao com a abordagem top-down,
esta metodologia no requer elevados investimentos iniciais e mais rpida de implementar,
dado que a anlise da informao pelo utilizador final pode-se iniciar usando os Data Marts
que esto especificados no ambiente de DW.
2.6
Arquitetura de um DW
A indstria concluiu que a modelao dimensional a tcnica mais vivel para a entrega de
dados aos utilizadores de um DW. Caso aps caso, a partir de 1970, os stakeholders de uma
organizao de TI (developers, consultores, utilizadores finais e fornecedores) foram sendo
atrados para uma estrutura dimensional simples para responder necessidade humana.
Assim, a maioria das empresas que tm um ambiente de DW seguem a abordagem de
Kimball. Tal deve-se ao facto de a maioria dos DWs partirem de um esforo departamental,
resultando na criao de Data Marts. Como se viu, cada rea departamental relevante para o
DW origina um Data Mart. Apenas quando mais Data Marts vo sendo construdos e ligados
entre si que o sistema evolui para DW. Desta forma, a arquitetura em seguida descrita, e
subjacente a este projeto, segue a abordagem bottom-up de Kimball.
Um DW consiste num repositrio de dados integrados, no volteis e orientados a um assunto
(Rao et al. 2003). A definio de um modelo arquitetural de referncia suporta o processo de
ETL. Assim, a arquitetura de um DW define a estrutura e os elementos que compem um
ambiente deste tipo de sistemas de base de dados. Atravs da definio de um modelo
arquitetural que suporte todos os componentes necessrios ao processo ETL, torna-se possvel
restituir toda a informao aos utilizadores finais atravs de sistemas de reporting. Esta
restituio de informao efetuada de modo completamente transparente para os
utilizadores, ocultando todo o processo de transformao e integrao de informao nas
respetivas estruturas de dados (Raimundo 2007). A arquitetura de referncia de um DW um
fluxo de informao que contempla o DW e um conjunto de componentes correlacionados
(Kimball and Caserta 2004).
Na base deste sistema encontram-se as fontes externas de informao que alimentam a Data
Staging Area atravs de processos ETL. O processo ETL o responsvel pelo fornecimento de
dados a serem depositados no DW e/ou nos Data Marts. Por fim, aps o armazenamento da
informao, esta encontra-se apta a ser restituda sob a forma de reporting aos utilizadores
finais (Figura 6).
Figura 6 - Elementos que constituem um Data Warehouse. Fonte: Kimball and Ross (2011)
2.6.1
Fontes externas de comunicao
As fontes externas de informao so os sistemas operacionais (OLTP) de registo que

capturam as transaes de negcio da organizao. Estes sistemas devem ser considerados
10
como externos ao DW dado que os developers de uma arquitetura de DW tm pouco ou

nenhum controlo sobre o contedo e o formato dos dados que so armazenados nesses
sistemas (Chaudhuri and Dayal 1997). As consultas de informao nos sistemas operacionais
so limitadas e apresentam algumas restries. Tal deve-se sobretudo ao facto de estes
sistemas no serem capazes de manter dados histricos, conferindo uma performance de
menor qualidade quando comparada com a de consultas de um sistema DW. Enquanto os
sistemas operacionais focam-se nos dados atuais, a tomada de deciso envolve normalmente
comparaes temporais (Ballou and Tayi 1999). Da ser importante a existncia de um
sistema capaz de fornecer informao dos dados histricos do passado que apresente grande
fiabilidade em detrimento das consultas nos sistemas operacionais. Assim, os sistemas
operacionais de registo consistem em fontes iniciais que fornecem a informao Data
Staging Area e, consequentemente, ao DW (Kimball 2006). A informao fornecida em
bruto atravs de diversos formatos, sendo os mais comuns os ficheiros .txt e .csv.
2.6.2
Data Staging Area
A Data Staging Area de um DW consiste numa rea intermediria entre as fontes externas de
informao e a Data Presentation Area, sendo responsvel pelo armazenamento dos dados e
pela execuo de um conjunto de processos ETL (Wixom and Watson 2001). Num ambiente
de DW, os dados brutos provenientes dos sistemas operacionais so transformados para que o
utilizador possa consultar os dados com total confiana. A exigncia arquitetural da Data
Staging Area que esta esteja apenas acessvel a pessoal qualificado (developers), no sendo
visvel pelo utilizador final.
Um passo chave no desenvolvimento de um sistema DW a extrao e integrao dos dados
operacionais atravs do uso de ferramentas de software ETL (Sabherwal and BecerraFernandez 2010). Segundo Ponniah (2001), cerca de 50 a 70 % do tempo de desenvolvimento
de um projeto de DW consumido em atividades de ETL. A primeira etapa no processo de
obteno dos dados de um ambiente de DW a extrao. Esta etapa consiste na leitura e
interpretao dos dados provenientes das fontes externas e posterior reproduo dos dados
necessrios para a Data Staging Area (Vassiliadis et al. 2001). Uma vez extrados os dados,
so inmeras as potenciais transformaes que esses dados podem sofrer. So disso exemplo
a limpeza dos dados (correo de erros ortogrficos, resoluo de conflitos de domnio e de
elementos em falta, ), a ligao de dados provenientes de mltiplas fontes, a eliminao de
dados duplicados e de elementos pouco relevantes para o DW e a atribuio de chaves
substitutas do DW (Kimball et al. 2008). O passo final do processo de ETL o carregamento
de dados. O carregamento no ambiente de DW consiste normalmente na apresentao das
tabelas dimensionais de qualidade assegurada para as instalaes de carregamento de cada
Data Mart (Santos and Bernardino 2008). Os Data Marts devem ento indexar os dados
recm-chegados. Quando cada Data Mart tiver sido atualizado, indexado, fornecido com as
agregaes adequadas e com a garantia de qualidade, os utilizadores so informados de que os
novos dados foram carregados.
2.6.3
Data Presentation Area
A Data Presentation Area o local onde os dados so organizados, armazenados e

disponibilizados para consulta direta pelos utilizadores (Kimball et al. 2008). De um modo
geral, a Data Presentation Area pode ser vista como uma srie de Data Marts integrados.
11
Esta rea contm as ferramentas e processos necessrios para a leitura dos dados a partir de
um Data Mart/DW para posterior exposio ao utilizador final num formato grfico.
Na perspetiva de Kimball, os dados consultveis na rea de apresentao devem ser
dimensionais, detalhados e devem seguir a arquitetura bus do DW (Kimball and Ross 2011).
Tal como foi dito anteriormente, apesar da utilidade do modelo normalizado (3 Forma
Normal) de Inmon no desempenho de processamento operacional, este acaba por ser bastante
complexo e caro. O uso de modelao normalizada na rea de apresentao abate o objetivo
do DW, ou seja, a recuperao intuitiva e de alta performance dos dados. Contudo, a
modelao dimensional aborda o problema da excessiva complexidade dos esquemas na Data
Presentation Area. Ora, apesar de um modelo dimensional conter as mesmas informaes que
um modelo normalizado, os dados so armazenados num formato cujos objetivos so a
compreensibilidade do utilizador, o desempenho das consultas e a resistncia mudana
(Kimball et al. 2008).
Outra expectativa da rea de apresentao prende-se com o contedo dos Data Marts que
devem apresentar dados detalhados (ou atmicos). Os dados detalhados so necessrios para
resistir a ataques imprevisveis de consultas ad hoc por parte dos utilizadores. Para alm de
conterem dados resumidos ou agregados, os Data Marts devem apresentar os dados
granulares subjacentes na forma dimensional (Moody and Kortink 2000). Tal acontece para
satisfazer as necessidades imprevisveis e em constante mudana dos utilizadores, permitindo
assim o acesso a informao detalhada.
Por fim, esperada na Data Presentation Area uma grande fidelidade arquitetura bus. Sem a
existncia de dimenses e factos conformados e compartilhados, um Data Mart torna-se uma
aplicao obsoleta. A runa de um DW pode passar pela ausncia de ligaes entre Data
Marts. A construo de um DW robusto e integrado depende fortemente destas ligaes entre
Data Marts, devendo existir por isso, um compromisso com a arquitetura bus.
Se a rea de apresentao baseada numa base de dados relacional, essas tabelas
dimensionalmente modeladas so referidas como esquemas em estrela. Por outro lado, se a
rea de apresentao baseada em bases de dados multidimensionais ou em tecnologias
OLAP, os dados so, ento, armazenados em cubos (Kimball and Ross 2011).
Contrariamente ao conceito original de DW, os Data Marts modernos podem muito bem ser
atualizados (e at com bastante frequncia). A existncia de dados incorretos deve ser,
obviamente, corrigida.
2.6.4
Ferramentas de acesso aos dados
O componente final de um ambiente de DW a ferramenta de acesso aos dados. Estas

ferramentas possibilitam a consulta dos dados que se encontram armazenadas na Data
Presentation Area. Uma ferramenta de acesso aos dados pode ser to simples como uma
ferramenta de consulta ad hoc ou to complexa como uma ferramenta de Data Mining ou de
Forecasting (Nestorov and Jukic 2003). O utilizador final pode assim analisar a informao
referente sua consulta e fundamentar as suas decises com base nos dados do DW e
reportados pelo sistema de reporting.
12
2.7
Objetivos do DW
O DW surge assim como a necessidade de satisfazer alguns dos requisitos das organizaes.
Este um instrumento que tem sido valorizado e utilizado em larga escala a nvel empresarial.
Segundo Mangold (1998), a tendncia cada vez maior no sentido de que as organizaes
passem a ver os dados como um recurso cada vez mais precioso.
Tendo como objetivos a organizao, gesto e integrao da base de dados, o DW assume-se
como um instrumento arquitetural para o suporte tomada de deciso. Segundo Ralph
Kimball (2011), o DW permite:
tornar a informao transversal organizao facilmente acessvel. Os contedos

de um DW devem ser fceis de entender e intuitivos para o utilizador, e no apenas
para o developer. As ferramentas que permitem o acesso ao DW (sistemas de
reporting) devem ser simples e fceis de usar, gerando resultados em tempo til.
apresentar a informao da organizao de forma consistente. Os dados de um
DW devem ser credveis, sendo completos e de elevada qualidade. De facto, os dados
tm de ser agrupados a partir de uma variedade de fontes da organizao, devendo-se
proceder sua limpeza, de forma a assegurar a sua qualidade. Uma vez executado este
ciclo, os dados encontram-se em condies de serem visionados pelos utilizadores
finais.
o DW deve ser resiliente e adaptar-se mudana. As necessidades dos utilizadores,
as condies de negcio, os dados e as tecnologias esto sujeitos a mudanas
constantes ao longo do tempo. O DW deve estar desenhado para lidar com estas
mudanas. Os dados e aplicaes existentes no devem ser alterados nem corrompidos
quando novas questes se levantam ou novos dados so adicionados ao DW. Assim, o
DW deve conter informaes histricas de qualquer poca (tais como resumos dirios,
semanais ou anuais), apresentando-se como um depsito de informaes no volteis
que so regularmente renovadas mas no atualizadas pelos utilizadores.
assegurar a proteo dos ativos de informao. O DW deve controlar eficazmente o
acesso informao confidencial da organizao. Os ativos de informao encontramse armazenados no DW, contendo dados que podem ser perigosos se forem entregues
pessoa errada.
servir como instrumento para a melhoria da tomada de decises. O DW deve
conter a informao correta para fornecer informaes para os sistemas de apoio
deciso. O DW facilita a anlise a tendncias de mercado, constituindo uma verdadeira
fonte de gesto e anlise de dados. Existe apenas um verdadeiro output a partir de um
DW que so as diferentes decises que so tomadas aps o DW expor a informao
pretendida.
ser reconhecido pela comunidade da organizao como uma ferramenta com
grande potencial. As ferramentas de suporte tomada de deciso devem ser userfriendly para que os utilizadores sintam que o DW pode contribuir para o seu trabalho
e para o sucesso da organizao.
Presentemente, a tomada de decises cada vez mais difcil por duas razes: o nmero de
alternativas disponveis muito maior em virtude de melhores tecnologias e sistemas de
comunicao; e o custo com erros pode ser bastante grande em virtude da magnitude e
complexidade das operaes (Turban, McLean, and Wetherbe 1999). Atendendo a estes dois
aspetos, os benefcios podem ser extremamente amplos se for possvel tomar decises
corretas. Os desafios que se colocam s empresas so cada vez mais complexos. Por isso, a
13
tomada de decises deve ser um ato estruturado, refletido com base em dados concretos,
relevantes, fornecidos atempadamente e no decorrerem apenas do talento, da criatividade e
da intuio do gestor.
De facto, desde o incio da dcada de 90 que as tecnologias DW esto amplamente
disseminadas ao nvel das organizaes (Moody and Kortink 2000). Estes sistemas emergiram
de forma a garantir a melhoria do processo de tomada de deciso e o apoio s estratgias de
mercado. Esta contribuio advm da capacidade destes sistemas armazenarem e gerirem
grandes volumes de informao de gesto e da sua capacidade de resposta rpida. Isto quer
dizer que o DW muito mais que uma base de dados puramente tcnica. Com a
implementao de um DW, os dados inseridos nos sistemas operacionais ficam disposio
de todos utilizadores da organizao. Baseando-se na informao armazenada nos seus
sistemas de informao operacionais e, mais tarde processada no DW, os utilizadores tm
sua disposio um instrumento para analisar essa informao e tomar decises de ndole
estratgica e ttica. Estas decises, se tomadas com critrio e com uma base fundamentada,
podem conferir empresa uma vantagem competitiva perante os seus concorrentes.
2.8
Business Intelligence
No incio da dcada de 60, os computadores passaram a assumir um papel muito importante

nas organizaes. Desde ento, constantes desenvolvimentos tecnolgicos tm-se vindo a
registar, o que tem facilitado os processos de anlise de informao e tomada de deciso. Com
a grande expanso tecnolgica e o desejo feroz de aumento de competitividade das
organizaes, o uso do poder computacional tem permitido a produo de relatrios que ligam
diferentes vises num nico lugar (Moeller 2007).
Nos ltimos anos, acompanhando a evoluo tecnolgica, surgiram ferramentas no mbito de
BI, reporting e suporte tomada de deciso. Estas ferramentas so essenciais para auxiliar o
processo de restituio de informao de negcio, sob a forma de reports (Raimundo 2007).
Em qualquer ambiente organizacional so produzidos relatrios com as mais diversas
informaes de negcio. Organizaes que produzam relatrios de gesto de elevada
qualidade tm maior probabilidade de interpretar o contexto e de identificar tendncias,
obtendo com isso uma vantagem competitiva face concorrncia. A elaborao de relatrios
de elevada qualidade promove melhores tomadas de deciso internas (Markus and Benjamin
1997).
O reporting uma atividade fundamental em torno de qualquer sistema BI, podendo ser visto
como um SSD (Densham 1991). Existem ferramentas especializadas de reporting que
fornecem a informao aos utilizadores aps a garantia de que os dados enviados pelos
sistemas operacionais da organizao se encontram devidamente processados pelo DW.
Um sistema BI lida com o problema de extrao de informao a partir de dados sintticos,
usando diferentes tipos de software. Na realidade, a informao obtida pelo
desenvolvimento de aplicaes BI que consistem na execuo de queries com grande
quantidade de dados histricos e posterior exposio dos resultados dessas queries atravs de
tabelas e grficos (Moeller 2007). Aps a obteno da informao atravs da aplicao BI, os
gestores encontram-se aptos a estudar os resultados obtidos e a tomar medidas com base
nesses resultados. A aplicao procura tornar vivel o aproveitamento de informaes
oriundas dos sistemas de informao operacionais da organizao tais como a faturao,
quantidades vendidas, stocks, entre outros.
14
Estado atual da OCP Portugal, SA
Nos ltimos anos, o setor farmacutico em Portugal tem sofrido grandes alteraes. Tal devese ao envelhecimento da populao e ao aumento dos custos associados prestao de
servios de sade. Do mesmo modo, um dos grandes problemas que se tem vindo a registar
neste setor prende-se com as margens que so progressivamente mais baixas. Assim, preciso
saber gerir a carteira de clientes, procurando manter os atuais e seduzir novos; alargar o leque
de artigos disponveis em armazm, reforando contactos com fornecedores e procurando
garantir stock de diferentes tipos de produtos; e antecipar alteraes do contexto. A
distribuio farmacutica representa um elo facilitador do acesso ao medicamento, sendo por
isso, inimaginveis as consequncias de uma eventual quebra no setor. Em seguida
elaborada uma anlise PEST para perceber o contexto nacional e o impacto que este pode ter
na procura da indstria farmacutica.
Tabela 1 - Anlise PEST do contexto nacional
Contexto
Impacto
Poltico
Medidas
do
Governo
procurando
poupanas na Sade
Aumento da presso para a transparncia

quanto
ao
preo
praticado,
eliminando
eventuais descontos e incentivos
Proibio do uso de um determinado
Perda da boa relao existente com os

fornecedores e possvel stock de produtos
medicamento por parte do Governo
Econmico
Crise global
Diminuio do volume de vendas a farmcias
Diminuio do poder de compra
Diminuio do nmero de consumidores das

farmcias
Reduo do crescimento tecnolgico e de
Aumento da presso por parte dos acionistas
investigao do setor farmacutico
Sociocultural
Mudanas das expectativas do paciente
Aumento da presso no servio ao paciente
Aumento da necessidade de utilizao de
Aproveitamento
redes sociais
Envelhecimento da populao e aumento
das
redes
sociais
para
exposio dos produtos
da obesidade
Maior conscincia social com problemas

relacionados
com
sade
consequentemente, aumento da procura
Tecnolgico
Evoluo dos meios de comunicao
Aumento do contacto com os clientes
(Media)
15
3.1
Sistemas de informao internos
Atualmente, a OCP Portugal, SA composta por trs tipos de sistemas de informao:
OLgA Oracle Logistic Application baseado no Oracle Form Application

OFINA Oracle Financial Application baseado no Oracle Financials
Site Comercial CRM baseado no Oracle Apex
O OLgA o sistema de informao mais usado e que suporta praticamente todas as atividades
da organizao. Esta base de dados de logstica a principal fonte de anlise de informao,
funcionando como um sistema integrado de gesto empresarial (Enterprise Resource
Planning ERP).
Segundo Alexis Leon (2008), o ERP trata-se de um conjunto de tcnicas e conceitos para a
gesto integrada dos negcios como um todo, procurando o uso eficaz de recursos para
melhorar a eficincia da organizao. O objetivo principal de um ERP o armazenamento
centralizado de toda a informao que partilhada por todas as reas no sentido de suavizar o
fluxo de informao em torno da organizao.
Assim, o OLgA o software de gesto de negcio que permite organizao a utilizao de
aplicaes integradas para gerir o negcio. Integra, entre outros, as reas de compras, receo
das compras, aviamento, devolues e expedio.
Figura 7 - Exemplo de um template do OLgA com valores fictcios
3.2
Identificao das necessidades
Como qualquer outra empresa, a OCP Portugal, SA est extremamente dependente do volume
de vendas aos seus clientes. A OCP Portugal, SA procura satisfazer plenamente os seus
clientes pois estes so a fonte da sua receita. Neste tipo de atividade, por no existirem custos
associados mudana, h clientes que requerem uma ateno especial, no sentido de os
fidelizar.
A OCP Portugal, SA necessitava de um sistema que lhe permitisse reportar os dados de uma
forma mais eficiente do que a que se vinha registando at ento. Antigamente, sempre que
algum gestor pretendesse obter um relatrio de gesto, entrava em contacto com o
Departamento de TI e esperava que a query fosse desenvolvida no Oracle TOAD e
posteriormente, fossem exportados os resultados (aps terem sido gerados) para um ficheiro
Excel. Para alm disso, o problema que o Excel surge com os dados em bruto, sem qualquer
tipo de grafismo associado. Ora, como se pode imaginar, isto era um processo ineficiente e
16
que se repetia vezes sem conta. Era necessrio melhorar a eficincia do processo de
elaborao de reports de gesto e do mesmo modo, reduzir o tempo de tomada de decises
por parte dos gestores. Ao mesmo tempo, pretendia-se reduzir o nmero de recursos
necessrios produo de relatrios.
3.3
Projeto Data Warehouse
Reconhecendo uma clara necessidade de sensibilizar as empresas do grupo para tomadas de

deciso estruturadas, a Celesio procurou investir num projeto de DW. Este projeto visa o
aumento da competitividade das empresas no setor de distribuio farmacutica, tendo por
base os dados do passado para interpretar corretamente o contexto atual e definir abordagens
para o futuro. A Celesio tinha como objetivo incutir s empresas do grupo a necessidade de
analisarem internamente a sua informao. Ao terem mais dados concretos para poderem
fundamentar as suas medidas, as empresas agem em conscincia e tm maior probabilidade de
tomar decises que influenciem positivamente a sua posio no mercado.
Assim, a Celesio recorreu ao know-how da GEHIS em sistemas de BI e DW, no hesitando em
transferir este projeto para as mos do Departamento de TI da GEHIS, detentora de
infraestruturas capazes para implementar este tipo de soluo. Assim, poderia aliar a grande
experincia da GEHIS neste tipo de sistemas a um maior contacto entre empresas do grupo.
Outras vantagens que as empresas do grupo podem aproveitar desta sinergia de esforos
passam por uma melhor prtica de transferncia de dados, possibilidade de desenvolvimento
de novas perspetivas de otimizao dos processos de negcio e pela possibilidade de
aproveitar as potencialidades de um sistema de BI a menor custo do que se contratasse no
mercado. A OCP Portugal, SA demonstrou grande interesse neste projeto. Porm, como
hbito por parte das organizaes quando se estuda a viabilidade de um determinado projeto,
necessrio analisar os prs e os contras, bem como reconhecer quais so as capacidades
internas da empresa e estudar as perspetivas de evoluo do mercado e do meio envolvente
externo. Com esta finalidade, elaborada a anlise SWOT, uma ferramenta muito utilizada
pelas organizaes quando se pretende efetuar um planeamento estratgico (Tabela 2).
Tabela 2 - Anlise SWOT desenvolvida OCP Portugal, SA
Anlise SWOT
Foras
Fraquezas
Fora da marca conceituada
Vasta gama de produtos
No existe distanciamento e frieza entre
que suporte a tomada de deciso
Grande consumo de recursos e tempo para a

elaborao de reports
nveis hierrquicos
Necessidade de obter melhor informao
Centralizao de funes administrativas,

compras, call center e devolues
Oportunidades
Sinergias
Ameaas
com
GEHIS
para
desenvolvimento de uma soluo de BI
Expanso para novos mercados emergentes
Possibilidade de mudanas desfavorveis na

legislao e crise das farmcias
Cortes no setor da sade
17
Procurando aumentar a sua quota de mercado, a OCP Portugal, SA identificou neste projeto
uma excelente oportunidade para gerir eficazmente a relao com o cliente, reconhecer
tendncias e simultaneamente reduzir o acesso aos sistemas de informao operacionais.
3.4
Arranque do projeto
Ciente das necessidades de informao, a OCP Portugal, SA decidiu em finais de 2010

avanar com o projeto Data Warehouse. Demonstrado o interesse, foi estabelecido o contacto
com a Celesio para delinear uma reunio para saber as condies em que funciona esta
soluo. Nessa reunio de kick-off do projeto, foram apresentados pela Celesio e pela GEHIS
os conceitos inerentes soluo DW, foi explicada a estrutura dos sistemas operacionais da
OCP Portugal, SA por parte do Departamento de TI e abordados prazos, custos, equipa de
trabalho e mbito deste projeto. No fundo, foram identificados todos os pontos relevantes para
se obter uma viso geral acerca dos desafios e necessidades futuras para se estimar os
esforos, custos e viabilidade do projeto.
3.5
mbito do projeto
Estudada a soluo oferecida, a OCP Portugal, SA definiu que a melhor estratgia seria a de
dividir o projeto em fases distintas. Em cada uma dessas fases seriam desenvolvidas as
especificaes pela OCP Portugal, SA sobre os objetivos pretendidos para as vrias reas
departamentais. A GEHIS ficaria responsvel pelo cumprimento dessas especificaes,
havendo posteriormente uma fase de testes para garantir se os objetivos estavam a ser
alcanados e efetuar eventuais ajustes. Numa primeira instncia, ficou determinado que o foco
seria o tratamento da rea comercial, rea em que incidiu o projeto. Outro facto importante
prende-se com o histrico de informao que o DW capaz de fornecer ao utilizador final. O
utilizador tem acesso a informao relativa aos dois ltimos anos.
A OCP Portugal, SA identificou neste projeto uma tima oportunidade de guardar a vasta
informao comercial que dispe num repositrio de dados nico. A quantidade de
informao ao nvel comercial to grande e complexa que exigia a criao de uma soluo
de BI para se poder analisar de forma eficaz os dados atuais e histricos. Com isto, pretendiase que o processo de tomada de deciso da rea comercial fosse mais eficiente e preciso.
3.6
Infraestrutura do DW
Uma das primeiras decises a tomar por parte da OCP Portugal, SA em conjunto com a
GEHIS prendeu-se com a definio de um modelo de transferncia e integrao de dados.
Foram estudadas diferentes abordagens e as respetivas vantagens e desvantagens.
A possibilidade de criao de uma base de dados interna nica com a informao
devidamente integrada dos diferentes sistemas de informao foi encarada como uma soluo
pouco benfica para as aspiraes da organizao (Figura 8).
18
Figura 8 Acesso direto base de dados. Fonte: GEHIS (2010)
Esta soluo asseguraria organizao a confidencialidade e a rastreabilidade dos seus dados.

Dado que a informao proveniente da sua base de dados, a soluo no exige um servidor
com maior capacidade de armazenamento. Para alm disso, no precisaria de se preocupar
com a extrao dos dados do processo ETL pois os dados so lidos diretamente a partir da
base de dados. Contudo, esta alternativa exige a utilizao de uma nica base de dados que
armazene toda a informao. Neste caso, seria perdida a vantagem do DW que pode
armazenar informao de mltiplas fontes de dados. De facto, ao utilizar uma soluo em que
os dados so lidos diretamente a partir da base de dados, o sistema operacional reduz a sua
eficincia e as consultas na ferramenta de reporting tornam-se mais demoradas. Aliado ao
problema de desempenho das consultas requeridas pelos utilizadores, a organizao seria
responsvel pela totalidade do processo ETL.
Desta forma, a OCP Portugal, SA recusou esta soluo pois, apesar de ser vantajoso o facto de
a informao armazenada nos seus sistemas operacionais no ultrapassar os limites fsicos da
organizao, exigvel um elevado know-how na ferramenta de suporte deciso que garanta
a consistncia dos dados.
Uma outra alternativa consistia na transferncia direta dos dados provenientes dos mltiplos
sistemas de informao para um repositrio central de dados alocado na Alemanha. A GEHIS
no defendia muito esta abordagem e alertou a organizao para os problemas que levantavam
uma soluo deste tipo. A OCP Portugal, SA teria de se comprometer a tornar pblicos os
dados da organizao e a permitir o acesso s fontes de informao por parte do
Departamento de TI da GEHIS. Os dados seriam carregados atravs da leitura direta das bases
de dados internas da organizao (Figura 9).
19
Figura 9 - Transferncia direta de dados. Fonte: GEHIS (2010)
A organizao no necessitava de apresentar nas suas infraestruturas um servidor interno que

armazene a informao pois os dados so migrados para a Alemanha. Aproveitando um maior
know-how da GEHIS em sistemas de BI, a OCP Portugal, SA no necessitava de se preocupar
com a extrao, transformao e carregamento dos dados, recorrendo ao outsourcing destas
atividades. A GEHIS assumiria a responsabilidade do processo ETL aps ter acesso aos
sistemas de informao. Porm, a segurana da informao ficaria gravemente comprometida
pois ao fornecer o acesso s bases de dados empresa alem, estaria sujeita a quebras de
confidencialidade e a erros que poderiam comprometer as transaes do dia-a-dia da
organizao. Outros fatores que influenciaram negativamente a opo por esta soluo
passaram pela falta de rastreabilidade dos dados e a sobrecarga de utilizao dos sistemas de
informao, perpetuando ineficincias.
Surgiu assim uma alternativa considerada ideal para as intenes da OCP Portugal, SA e que
ia de encontro resoluo das suas necessidades a transferncia de dados por flat files.
Desta forma, de entre as trs formas possveis de transferncias de dados, a OCP Portugal,
SA, a conselho da GEHIS, optou pelo envio de ficheiros de formato unidimensional (tipo.
csv). O Service Level Agreement estabelecido entre a OCP Portugal, SA, Celesio e GEHIS
descreve como devem ser estruturados estes ficheiros de dados. Assim, a OCP Portugal, SA
responsvel pela extrao de dados dos sistemas de informao (OLgA, OFINA e Site
Comercial) para ficheiros de formato unidimensional por forma a serem enviados para a
GEHIS. A transferncia de ficheiros feita diariamente, s 6:00 horas, via FTP. Este um
caso especfico de transferncia de dados, uma vez que o processo ETL ocorre em duas
organizaes distintas. A extrao feita pelo Departamento de TI da OCP Portugal, SA, ao
passo que a transformao e atualizao dos dados ocorre na GEHIS.
O Departamento de TI desenvolveu um sistema que garante que todas as inseres,
eliminaes e alteraes de dados so enviadas diariamente. Este sistema consiste na
existncia de uma tabela aparte das outras tabelas do sistema de informao que guarda esses
dados. Todas as tabelas tm um trigger que ativado sempre que novos dados so inseridos,
alterados ou eliminados. Sempre que h dados novos que so inseridos ou alterados, os
20
registos so guardados e enviados com a informao completa para essa tabela. Quando se
trata de eliminao de dados, nessa tabela apenas ir constar o registo que foi eliminado. Estes
dados so posteriormente armazenados no servidor da GEHIS com uma capacidade de
armazenar 21 TB de informao, sendo de seguida, processados num outro servidor (IBM
P570 com 100 GB de memria). Este processamento dos dados ocorre diariamente s 13:00
horas locais, menos uma hora em Portugal. Aps o seu processamento, os dados so
carregados para o DW (Anexo A).
Esta forma de transferncia de dados tem como vantagens a definio de uma estrutura
especfica dos dados, a sua rastreabilidade, a elevada performance, uma maior segurana, o
outsourcing do processo ETL e a possibilidade de recalculo dos dados no sentido de controlar
a integridade dos mesmos. Por outro lado, a OCP Portugal, SA pode aproveitar as sinergias
desta transferncia com a GEHIS. Aliado grande experincia de sistemas de BI e de DW por
parte da GEHIS, a OCP Portugal, SA pode ainda beneficiar de outras regalias, tais como
aproveitar as negociaes de licenas e a possibilidade de otimizao de processos; beneficiar
do atual estado de arte e melhorar continuamente as suas operaes; e apresentar melhores
prticas de transferncia. Porm, esta soluo apresentada pela GEHIS obriga a OCP
Portugal, SA a extrair os dados dos seus sistemas de informao e a possuir um servidor FTP
para enviar ficheiros de dados. Alm disso, exige um espao local temporrio no disco rgido.
Figura 10 Transferncia de dados por flat files. Fonte: GEHIS (2010)
O utilizador final pode consultar a informao requerida atravs da ferramenta de reporting

MicroStrategy, tanto na verso Desktop como na verso Web. Tal como indica a Figura 10, o
utilizador aps requerer uma consulta ad hoc, ir ter acesso aos dados armazenados no DW e
prontamente disponibilizados por um servidor BI.
3.7
Data Governance
A OCP Portugal, SA contm dados dispersos pelos trs sistemas de informao internos.
Estes sistemas operacionais, apesar de independentes uns dos outros, contm dados
redundantes que necessitam de ser devidamente tratados. Com o objetivo de aumentar a quota
de mercado e a performance dos seus processos de negcio, a empresa sentiu que o projeto
DW seria uma mais-valia dado que permitia a restituio da informao atravs de uma base
21
de dados nica que alimentada pelos dados provenientes dos diferentes sistemas de
informao.
Tratando-se de um projeto que tem como objetivo a visualizao de informao em temporeal de modo a auxiliar o processo de tomada de deciso, essencial assegurar a qualidade e
integridade dos dados. Sem essa garantia de fiabilidade, de nada serve a criao de uma
soluo de BI. Consciente da crescente importncia da anlise da sua informao, a OCP
Portugal, SA procura analisar os riscos inerentes s suas operaes com o objetivo de obter
uma vantagem competitiva nas suas tomadas de deciso.
Assim, foi necessrio definir um conjunto de especificaes na fase inicial que suportassem e
garantissem o xito do projeto. A disciplina que garante isso designada de Data
Governance.
O Data Governance trata-se de um programa que engloba a definio de polticas de gesto
de dados, de processos de negcio e de risco em torno do tratamento dos dados numa
organizao para garantir a qualidade da informao. O Data Governance uma iniciativa de
controlo de qualidade para acesso, gesto, uso, melhoria, policiamento, manuteno e
proteo de informao organizacional que tem como finalidade tornar a organizao mais
eficiente (Wende 2007). Assim, os grandes objetivos do programa de Data Governance na
organizao passam por:
permitir processos de tomada de deciso mais fiveis

reduzir desgaste operacional
proteger as necessidades de informao dos stakeholders
incentivar a adoo de abordagens comuns por parte da gesto e do Departamento de
TI para os problemas relacionados com os dados
construir processos standard
reduzir custos e aumentar a eficcia atravs de coordenao de esforos
assegurar transparncia de processos
um sistema que define os direitos e deveres em torno do processo de tomada de deciso

executado segundo modelos acordados entre a GEHIS e a OCP Portugal, SA que descreve:
quem pode tomar as aes, qual a informao que pode utilizar e quando a pode utilizar (e sob
que circunstncias). O Data Governance descreve um processo evolutivo da organizao,
alterando a sua forma de pensar e de preparar os processos para lidar com a informao para
que toda essa informao possa ser utilizada pela totalidade da organizao (Thomas 2006). O
controlo dos dados assim assegurado por um conjunto de processos e mtodos
desenvolvidos pelos Data Stewards e Data Custodians (Weber, Otto, and sterle 2009).
Os Data Stewards so as pessoas responsveis pela manuteno dos dados nos registos da
Metadata. Tm assim de assegurar que os contedos dos dados e regras de negcio associadas
esto em conformidade. Os Data Custodians so responsveis pelo transporte e
armazenamento dos dados e pela implementao das regras de negcios. Posto isto, os Data
Stewards so responsveis pelos dados que constam nos vrios campos de dados, ao passo
que os Data Custodians so responsveis pelo ambiente tcnico e pela estrutura da base de
dados.
22
Figura 11 - Responsveis do projeto e respetivas tarefas. Fonte: Celesio
Em suma, o Departamento de TI da OCP Portugal, SA o responsvel pelo envio dos dados,

funcionando como o Data Steward, ao passo que o Departamento de TI da GEHIS acumula as
responsabilidades dos processos de armazenamento e tratamento da informao com a
construo da estrutura do DW (Data Custodian).
23
Implementao da soluo BI
Atravs da implementao de um SSD, a organizao pretende ter um acesso mais eficiente

informao. O objetivo passa por capitalizar esse acesso aos dados numa vantagem
competitiva que oferea um melhor desempenho dos seus processos de negcio e,
simultaneamente aumente o lucro.
Um SSD consiste num conjunto de aplicaes de software integradas e de hardware que
formam a estrutura do processo de tomada de decises de uma organizao. A finalidade de
qualquer sistema deste tipo prende-se com a anlise de dados recolhidos pelos sistemas de
informao internos da organizao.
A OCP Portugal, SA procura, ento, aplicar uma soluo de BI fivel que auxilie na resoluo
de questes empresariais do dia-a-dia.
4.1
Objetivos do projeto
O projeto surge para suprir as necessidades da organizao em termos de anlise de

informao. Competindo num mercado altamente competitivo, a OCP Portugal, SA procura
responder rapidamente s mudanas de negcio. A implementao de um bom SSD visa
alcanar vantagens competitivas sob os seus concorrentes.
No sentido de resolver as necessidades sentidas pela organizao foram procuradas solues
em diversos nveis que permitissem a aplicao de um sistema BI prtico e fivel. A Figura
12 esquematiza as principais necessidades que o projeto procurou satisfazer.
Figura 12 - Necessidades a satisfazer
Um dos objetivos passa por tornar a sua informao como um dos ativos mais importantes da
organizao. Neste nvel pretende-se desenvolver a anlise e gesto dos dados de forma a
atingir resultados consistentes, fiveis e que satisfaam as consultas dos utilizadores finais.
Na perspetiva de negcio a finalidade passa pela obteno de resultados que auxiliem a
tomada de deciso. Aqui, os utilizadores finais assumem um papel de destaque pois so eles
que iro analisar os resultados e definir os prximos passos a implementar pela organizao
para melhorar a posio da organizao no mercado. A componente analtica extremamente
importante para o sucesso deste projeto.
24
A nvel arquitetural, a implementao de um sistema BI exige a criao de um sistema que

seja alimentado pelos sistemas operacionais da organizao e que consiga transmitir a
informao em tempo-real aos utilizadores finais. Para isso, necessrio que, aps a criao
do ambiente DW sejam especificadas todas as particularidades das diferentes reas
departamentais e respetivas ligaes entre campos. Neste projeto, este nvel da maior
importncia dado que toda a gesto, anlise e explorao de informao dependem
diretamente do contexto arquitetural.
No que concerne ao nvel dos processos, so procuradas solues que automatizem a gerao
de reports de forma a facilitar o processo de tomada de deciso. A identificao do mbito
dos diferentes departamentos e a gesto do planeamento dos processos de negcio contribuem
para uma melhor robustez do SSD.
4.2
Soluo proposta
Identificadas as necessidades da organizao, a soluo proposta consiste numa abordagem

segmentada a diferentes nveis. Estes nveis, apesar de serem distintos, esto intrinsecamente
ligados entre si. A soluo proposta visa a ligao entre os dados num sistema DW,
posteriormente facultados aos utilizadores finais atravs da ferramenta de reporting, e
contempla aspetos ligados com os componentes arquiteturais, processos, conceitos e a
aplicao da soluo BI.
4.2.1
Arquitetura
Os sistemas operacionais contm os dados que alimentam os repositrios de DW e Metadata.

A informao armazenada nesses repositrios ir sofrer alteraes atravs do processo ETL,
com o objetivo de evitar duplicaes de informao, efetuar a limpeza dos dados, estabelecer
ligaes entre tabelas de fontes distintas e de atribuir chaves substitutas do DW. O processo de
transformao e carregamento dos dados da total responsabilidade da GEHIS. Aps a
integrao e consolidao dos dados, a informao pode ser restituda aos utilizadores finais
sob a forma de reports. Na vertente arquitetural, os repositrios que armazenam a informao
a ser consultada assumem um aspeto bastante importante no projeto e devem ser alvo de
especial ateno, sob pena de no se reproduzir informao fivel (Figura 12).
Figura 13 Arquitetura do DW
25
O conceito de Metadata assume particular importncia neste projeto pois refere-se a um

repositrio que define as especificaes da informao, sendo o principal responsvel pela
forma como os dados so tratados na Data Staging Area. Trata-se de um repositrio de dados
onde as tabelas do DW esto mapeadas, refletindo os conceitos de negcio. Neste caso, o
repositrio de Metadata reside no mesmo servidor do DW. Ao passo que o DW o repositrio
de dados que contm toda a informao de negcio, o repositrio de Metadata o que
possibilita a definio de processos de gesto e manipulao dos dados sobre o DW. Isto , o
Metadata engloba as especificaes das fontes de informao, o dimensionamento das tabelas
de origem e de destino no processo de migrao dos dados, as definies dos prprios dados,
entre outros. Esta uma rea em que o Departamento de TI incidiu especial ateno e, em
conjunto com a OCP Portugal, SA, definiu as especificaes necessrias para suportar a
informao.
Neste componente arquitetural, o objetivo final passa por explorar a informao existente num
processo analtico.
4.2.2
Definio dos processos
Os processos existentes no ambiente DW deste projeto foram planeados para aumentar o

desempenho, a fluidez e a coerncia do processo global de reporting.
No mbito deste projeto, desenvolveram-se processos ao nvel de tratamento de dados e da
anlise e gesto de informao de carter aplicacional. O processo ETL trata-se de um
exemplo de um esforo conjunto das duas organizaes de tratamento dos dados que
efetuado diariamente e que assegura a consistncia dos mesmos. Foi criado um processo pelo
Departamento de TI da OCP Portugal, SA em que os dados so extrados diariamente s 6:00
horas, ficando a GEHIS responsvel pela fase de transformao e carregamento. A integrao
dos dados fica completa por volta das 12:00 horas nacionais, ficando a informao referente
at ao dia anterior realizao deste processo disponvel para consulta pelos utilizadores
finais da ferramenta de reporting. Por outro lado, a GEHIS tambm criou processos de
filtragem de informao de acordo com regras de periodicidade. Esta filtragem serve para
garantir a atualizao dos objetos existentes no repositrio de Metadata. Por exemplo, no caso
deste projeto, o DW s pode fornecer informao dos dois ltimos anos, sendo por isso
necessria a constante atualizao do repositrio de Metadata para fornecer somente
informao desse perodo.
4.2.3
Interpretao dos conceitos
Para uma melhor perceo dos processos de negcio, foi necessria a explorao da estrutura
de dados existente nos sistemas de informao internos e no DW. Atravs do entendimento
decorrente da anlise e explorao da informao, tornou-se possvel a criao de regras e
mtricas que se iro refletir ao nvel dos processos e da ferramenta de reporting.
Uma das grandes exigncias deste projeto passava pela estruturao lgica das tabelas e da
informao na ferramenta de reporting e pela identificao de fluxos que permitisse a gerao
de reports capazes de auxiliar a tomada de deciso. Na estruturao das tabelas e da
informao, os conceitos principais foram agrupados de modo a formular uma soluo que
facilitasse a compreenso da disposio das tabelas na ferramenta. Esta estruturao procura a
reorganizao e eliminao de campos inutilizveis ou obsoletos.
26
4.2.4
Implementao da aplicao
No nvel concetual, a compreenso dos processos de negcio e dos elementos que compem
os sistemas de informao internos e, ao mesmo tempo, o DW permite a criao de regras e
mtricas com carter estatstico. Assim, ficam reunidas as condies para a implementao de
um SSD que devolva a informao pretendida pelos utilizadores finais, sob a forma de
reports.
A anlise de reports de gesto visa facilitar a tomada de deciso do utilizador final, sendo
uma ferramenta simples de gerar e que exige pouca formao tcnica. Os utilizadores finais
assumem um papel ativo no processo de anlise e gesto pois, com base na sua experincia,
podem rever os dados e identificar possveis inconsistncias dos dados. Todo o processo de
anlise passa, ento, por uma segunda anlise de pertinncia.
A informao aplicacional, representada como ligao dos utilizadores s estruturas de dados
do componente arquitetural, disponibilizada tendo em vista um ambiente organizado, mais
eficiente e caracterizado pela qualidade.
Desta forma, a metodologia de trabalho concretizada teve como finalidade esta componente
aplicacional, cruzando todos os restantes componentes: arquitetural, processual e concetual.
4.3
Ferramenta de reporting MicroStrategy
No sentido de responder s suas necessidades, a ferramenta de reporting MicroStrategy ser a

responsvel pela produo de reports e pelo controlo e anlise dos dados. Trata-se de um
sistema de construo e distribuio de reports com informao de negcio, de modo a
suportar a tomada de deciso dos utilizadores finais.
O MicroStrategy consiste numa poderosa ferramenta de reporting, amplamente usada em
ambientes empresariais. O software de reporting permite aos utilizadores aceder a dados
provenientes de diversas fontes. Diretamente ligado ao DW, o MicroStrategy fornece a
informao requerida pelo utilizador e que se encontra armazenada no repositrio de dados. O
MicroStrategy permite a todos os utilizadores aceder mesma informao e mesma verso
da verdade. Alm disso, possibilita a anlise contnua e a monitorizao da performance do
negcio, fornecendo aos utilizadores informao para auxiliar a tomada de deciso.
Os reports podem ser disponibilizados atravs de duas formas: via Web ou via Desktop. A
verso Web destina-se aos gestores que pretendam consultar rapidamente a informao
relativa a reports j existentes, sem possibilidade de edio. A verso Desktop no
recomendvel a utilizadores com pouca experincia pois esta verso para alm de apresentar
os reports existentes, permite aos utilizadores a elaborao de queries ad hoc, a criao de
filtros, mtricas e prompts sobre os dados existentes.
Concetualmente, um projeto consiste no ambiente em que todo o reporting relacionado
efetuado. Um projeto tpico contm a totalidade dos objetos, sendo estes filtros, mtricas,
prompts, atributos, tabelas, entre outros. Quando agregados, num mesmo report, resultam na
disponibilizao da informao pretendida, num formato organizado, intuitivo e exportvel
para outros formatos de ficheiro.
De forma sucinta, so apresentados alguns dos objetos presentes no repositrio de Metadata,
no mbito da ferramenta de reporting MicroStrategy (Tabela 3).
27
Tabela 3 Objetos tpicos de um repositrio de Metadata. Fonte: Sthr, Mller and Rahm (1999)
Objeto
Atributo
Facto
Filtro
Definio
Consiste na representao e agrupamento de categorias e de nveis de dados.
No so numricos e representam informao por assunto para caracterizar e
qualificar um conjunto de dados. Respondem a perguntas sobre um facto.
Os atributos so compostos pela Master Data que nunca ou raramente
modificada. A Master Data a informao-chave para a operao de um
negcio.
Concetualmente visto como uma medida de registo das ocorrncias de
negcio. Factos consistem numa situao nica, dada uma certa combinao de
atributos. Permitem o acesso a dados armazenados no DW e so, na sua maioria,
valores numricos.
Define condies lgicas que limitam o intervalo de dados numricos
apresentados num relatrio, isto , limita os valores numricos de um dado
atributo a um intervalo de valores.
Os filtros funcionam como restries para um report, podendo incluir ou excluir
determinados dados que se pretendam.
Mtrica
Consiste num clculo analtico obtido atravs de uma expresso construda a

partir de objetos existentes, sendo estes funes, atributos, factos ou outras
mtricas.
Compostos pela Movement Data (normalmente disponvel durante os ltimos
dois anos) que modificada diariamente, semanalmente ou mensalmente. As
mtricas devem ser sempre acompanhadas de um filtro temporal.
Reports
Consistem numa sntese e integrao de dados cujos resultados servem um vasto

conjunto de propsitos. Permitem a visualizao de informao de modo a
auxiliar a tomada de deciso. Os reports consistem numa query SQL cujos
resultados so apresentados numa forma grfica atravs das ferramentas de
reporting.
Tabela
Na perspetiva de sistemas de informao, consiste no componente fsico

primrio de um DW, constitudo por colunas e dados dos mais variados tipos.
O MicroStrategy possibilita o desenho e implementao de reports de gesto em modo

grfico, a visualizao e edio do cdigo SQL subjacente a um report e a definio de regras
(mtricas, filtros e prompts).
Em seguida expe-se uma panormica do ambiente MicroStrategy Desktop, atravs da
apresentao visual dos seus componentes (Figura 14).
28
Figura 14 - Framework do MicroStrategy
Para alm das caractersticas referidas para o Desktop, o MicroStrategy possui um

componente de implementao de reports (Figura 15).
Figura 15 - rea de criao de reports
Este ambiente de construo permite funcionalidades de drag-and-drop na escolha de

componentes de report. Alm disso, pode-se escolher o modo de visualizao do report,
definir mtricas, prompts e filtros, entre muitas outras funcionalidades. Os resultados dos
reports produzidos fornecem informao estatstica importante para o apoio tomada de
deciso.
4.4
Responsabilidades no projeto
A crescente necessidade de gesto de informao e a grande quantidade de dados existentes

da rea comercial dispersos pelos trs diferentes sistemas de informao internos da
organizao deram origem a este projeto. A implementao de uma ferramenta de reporting
visa disponibilizar, em tempo-real, a informao requerida pelo utilizador final.
Os requisitos iniciais a satisfazer prendiam-se com:
o enquadramento dos processos de negcio e dos sistemas operacionais da

organizao
29
o cumprimento das tarefas dentro dos prazos predefinidos

a anlise da informao disponibilizada pelo DW, atravs da ferramenta de reporting
a deteo e correo dos eventuais erros dos dados disponibilizados pelo DW
a anlise crtica da informao recolhida atravs de reunies, entrevistas e
documentao comercial para posterior desenvolvimento de reports
a obteno de um ambiente de reporting organizado, simples, automtico, reutilizvel
e eficiente que auxilie a administrao na tomada de deciso
No decurso deste projeto foram cumpridas as tarefas estipuladas no planeamento, sendo

considerada uma alocao de tempo a outras tarefas, que consistiram:
na familiarizao com a ferramenta de reporting

na explorao e aprendizagem dos sistemas de informao internos da organizao
na leitura de documentao tcnica
A natureza do projeto faz com que no tivesse sido desenvolvido de raiz uma vez que todos os
dados j se encontravam armazenados no DW. Contudo, a informao no estava a ser
restituda com qualidade pois no tinham sido realizados testes de verificao. Desta forma,
mltiplos testes tiveram de ser realizados e vrios erros foram detetados e prontamente
corrigidos.
Melhorar a acessibilidade aos dados relevantes para o negcio atravs da criao de um
ambiente de reporting de gesto comercial foi o grande foco deste projeto. Isto facilita aos
utilizadores finais pois estes deixam de recorrer aos diferentes sistemas operacionais para
consultar informao histrica. Atravs desta ferramenta torna-se possvel obter informao
combinada de trs sistemas de informao.
4.5
Metodologia seguida
Devido existncia de outros projetos na organizao e ao reduzido nmero de colaboradores

diretamente envolvidos no projeto DW, optou-se por seguir uma metodologia flexvel que
promova a realizao do projeto por fases. Esta metodologia rejeita a hiptese de que uma
fase s pode ser iniciada se a imediatamente anterior estiver totalmente concluda. De facto, o
carter dinmico de uma rea de negcios obriga a uma constante reviso dos requisitos. Da
mesma forma, as necessidades e exigncias dos gestores e utilizadores finais mudam
consoante as circunstncias, originando retrocessos nas diversas fases do ciclo de vida do
projeto. Visto que o projeto teve algumas paragens durante cerca de um ano por motivos
externos e internos, algumas especificaes que haviam sido mencionadas anteriormente
tiveram de ser modificadas.
De modo a cumprir com os objetivos e solues anteriormente mencionados, foi necessrio a
elaborao de um planeamento interno que garanta o sucesso do projeto (Figura 16).
Figura 16 Metodologia seguida do projeto
Como se pode verificar, a metodologia seguida foi segmentada em fases distintas. Muitas das
fases incluam tarefas com grande nvel de detalhe que, por no serem muito relevantes para a
descrio do projeto, so remetidas para anexo (Anexo B).
30
A nomenclatura e definio de cada passo pode variar mas o ciclo de vida comea com os
requisitos seguindo-se a fase de desenho, implementao, testes e por fim manuteno do
sistema.
Melhorias, comparaes e documentao intermdia foram desenvolvidas de acordo com as
necessidades existentes da organizao. Assim, conseguiu-se uma metodologia flexvel e
orientada a objetivos especficos, dependentes da fase que estava em curso. Nesta
metodologia procurou-se garantir a interao com os utilizadores finais e responsveis do
projeto e a adaptao da soluo s necessidades existentes ao longo do tempo.
4.5.1
Anlise
A fase inicial do projeto consistiu no levantamento dos requisitos e na anlise dos objetivos
com vista resoluo do problema. Esta primeira fase envolveu o enquadramento com os
processos de negcio da organizao e o estudo dos seus sistemas de informao internos.
Foram criados modelos informais (diagramas entidade-relao) que caracterizam a estrutura
da informao, permitindo a apreenso da arquitetura fsica e lgica subjacente ao ambiente
DW em questo. A anlise aos diagramas entidade-relao dos sistemas operacionais permitiu
uma melhor perceo dos campos, tabelas e respetivas ligaes (Figura 17).
Figura 17 - Exemplo de diagrama entidade-relao relacionado com a faturao. Fonte: OCP

Portugal, SA
A definio de especificaes e de regras a aplicar foi extremamente importante nesta fase e

exigiu um esforo conjunto da OCP Portugal, SA e da GEHIS para garantir a efetividade do
projeto. Ao longo das reunies existentes durante os ltimos dois anos, foram definidas
polticas de gesto de dados, de processos de negcio e de risco em torno do tratamento dos
dados de forma a assegurar a qualidade da informao. Atravs de um processo de anlise
contnuo e que teve por base os diagramas entidade-relao fornecidos pela OCP Portugal,
SA, a GEHIS realizou o levantamento categrico da totalidade dos objetos MicroStrategy
existentes, bem como a identificao das dependncias inter-objetos.
31
4.5.2
Modelao
A modelao foi a fase posterior fase de anlise e s comeou assim que a fase de
especificao de requisitos foi finalizada. Esta foi a fase onde se efetuaram os modelos
arquitetural e lgico do DW. Neste projeto, a anlise e a gesto de informao assumem um
papel importante, cuja eficincia depende do conhecimento da estrutura dos mesmos. A
criao do modelo arquitetural depende da estrutura dos diagramas entidade-relao dos
sistemas de informao. A partir destes diagramas construdos pela OCP Portugal, SA, a
GEHIS estabeleceu a arquitetura do DW. Estas duas primeiras fases j haviam sido realizadas
para a rea comercial. Os prximos passos do projeto envolvero refazer estas fases para
outras reas de negcio.
Em termos de desenho/modelao, a explorao de informao permitiu identificar o modelo
DW arquitetural e o de Modelao dimensional existentes. O modelo dimensional, usado no
ambiente DW subjacente a este projeto, caracteriza-se pela organizao, num arranjo peculiar,
que traduz as relaes ao nvel de tabelas distintas do modelo. Como componentes salientamse factos, dimenses e respetivas ligaes (Tabela 4).
Tabela 4 - Componentes do Data Warehouse. Fonte: Kimball and Ross (2011)
Componentes
do modelo
dimensional
Definio
Factos
Consistem em registos de ocorrncias. Tendem a ser mensurveis, sendo

tambm referidos como medidas. Permitem a anlise a diferentes nveis
granulares e tipicamente so numricos e aditivos. imprescindvel que
possam ser agregados.
Dimenses
Conjunto de atributos que descrevem uma mesma propriedade de

ocorrncia. Tipicamente, os atributos de uma dimenso so descritivos e
no mensurveis. So organizados segundo hierarquias bem definidas.
Possibilitam a anlise dos factos a diferentes nveis de granularidade.
Enquanto os factos registam as ocorrncias de um negcio, as dimenses
descrevem as condies do negcio.
Tabela de
Factos
Contm um ou mais atributos que ocorrem numa dada combinao de

registo das vrias dimenses. esta combinao de registos que identifica
univocamente cada facto, atravs do conceito de chave. Traduz sempre
uma relao de muitos para muitos, possuindo uma chave primria
composta por mltiplas chaves estrangeiras (uma para cada dimenso que
caracteriza a ocorrncia do facto).
Tabela de
Dimenses
Contm os diferentes atributos respeitantes dimenso e um identificador

unvoco para cada registo da tabela, permitindo assim, a ligao Tabela
de Factos.
O modelo dimensional representa o registo de dados em tabelas, relacionando factos e

dimenses. Esta forma de modelar a informao pode apresentar diferentes arranjos,
denominados esquemas. O modelo dimensional existente na forma de esquema em estrela,
em que existem tabelas centrais de factos ligadas a tabelas de dimenses, formando-se uma
32
modelao lgica das estruturas de dados. Esta configurao determina que no podem existir
relaes entre as tabelas de dimenses (Figura 18).
Figura 18 - Exemplo de um modelo dimensional. Adaptado: Kimball and Ross (2011)
Atravs do diagrama entidade-relao normalizado, a GEHIS procede arquitetura do DW. O

primeiro passo para convert-lo num conjunto de modelos dimensionais dividir o diagrama
por processos de negcio e, em seguida modelar cada um desses processos separadamente. O
passo seguinte selecionar, nos diagramas entidade-relao, as relaes muitos-para-muitos
que contm factos no-chave numricos e aditivos e design-las como tabelas de factos.
Finalmente deve-se desnormalizar todas as restantes tabelas em tabelas simples com chaves
nicas (tabelas de dimenso) que unem diretamente s tabelas de factos. Cada ligao entre as
tabelas de dimenso e as tabelas de factos no DW estabelecida atravs do uso de chaves
substitutas inteiras, artificiais e sem significado. Isto , as ligaes no devem ser efetuadas
diretamente pelos cdigos naturais dos sistemas de informao internos que alimentam o DW.
4.5.3
Implementao
A fase de implementao ou desenvolvimento seguiu-se s fases de anlise e modelao.

Nessa fase inclui-se a criao de todo o ambiente de reporting, mapeamento e listagem dos
dados. A definio de reports fulcrais para anlise foi estabelecida em conjunto com o
Departamento de Marketing e Vendas. Atravs de entrevistas realizadas e anlise de
documentos comerciais tornou-se possvel obter uma viso de que informao seria
interessante consultar na ferramenta de reporting. Deste modo, foram tambm realizados
indicadores de performance adequados para apurar a eficincia dos processos de negcio da
organizao.
Antes de passar fase seguinte, foram realizados testes a fim de garantir o cumprimento dos
objetivos inicialmente propostos e o bom funcionamento da soluo implementada. Estes
testes foram feitos recorrendo ferramenta de reporting MicroStrategy, sendo posteriormente
comprovados atravs de uma ferramenta que possibilita o acesso aos dados atravs da criao
de queries, o SQL Developer, Esta tarefa tem como objetivo assegurar a qualidade e
integridade da informao restituda.
33
Figura 19 - Teste de uma query com resultados fictcios
A realizao de testes revelou-se essencial pois foram detetados inmeros erros relacionados
com os dados disponibilizados pelo DW. Esta fase acabou por revelar-se bastante morosa,
consumindo cerca de 10 semanas do projeto, pois a identificao dos erros e sua correo no
foram simples. Contudo, s com a correo destes erros que foi possvel a obteno de uma
soluo fidedigna, na qual os utilizadores finais podem obter a informao que pretendem.
Quando os erros nos dados restitudos pelo MicroStrategy eram detetados, eram reportados
GEHIS atravs de ficheiros de formato .xls. Uma vez identificados, eram produzidos reports
at ao maior nvel de detalhe dos atributos (por exemplo, produto, nmero da fatura, dia,) e
comparados com os resultados obtidos para a mesma consulta no SQL Developer. Os
resultados de ambas as ferramentas eram exportados, e colocados lado a lado, para um mesmo
ficheiro Excel e enviados para a GEHIS. Verificaram-se erros que se prendiam com falhas na
execuo do processo ETL, resultando em diferenas na quantidade de registos enviados e
armazenados no DW. Por outras palavras, a soma do nmero de registos de algumas tabelas
dos sistemas de informao internos no coincidiam com a do DW. Assim, o processo ETL
teve de ser recriado para algumas datas. Aps a correo da totalidade dos erros relativos a
esta fase do projeto, foi marcada uma reunio com elementos da Celesio e da GEHIS para
averiguar o estado atual do projeto e os prximos passos a desenvolver (Anexo C).
Apesar de se avanar para as fases seguintes, o projeto exigiu o retrocesso constante a esta
fase para o estudo de novas possibilidades de report e para a correo de eventuais erros
detetados em fases posteriores. Da, a natureza deste projeto obrigar a aplicao de uma
metodologia flexvel.
4.5.4
Passagem a qualidade
Esta fase teve como finalidade a simulao da passagem a produo, segundo a perspetiva do
utilizador final. Assim, consistiu na tentativa de encontrar algum incumprimento que
comprometesse o funcionamento correto da soluo. Foi realizada uma reunio com o Diretor
do Departamento de Marketing e Vendas para apurar eventuais erros dos dados e refinar
alguns reports.
34
4.5.5
Testes de aceitao
Nos mesmos moldes da fase anterior, os utilizadores finais do projeto efetuaram testes de
aceitao e comprovaram a validade da soluo e das funcionalidades do projeto. Numa
reunio final, foram expostos os reports Direo e aos responsveis do projeto a fim de
expor a soluo desenvolvida e demonstrar os testes realizados.
4.5.6
Passagem a produo
A fase final do projeto foi a passagem da soluo para o ambiente de produo. Esta fase
serve para avaliar o desempenho do sistema depois de entrado em produo.
O utilizador final apresenta-se como um interveniente decisivo no processo de tomada de
deciso atravs da utilizao do MicroStrategy na verso Web. Para usar esta ferramenta e ter
acesso informao, o utilizador precisa de estar ligado Intranet da organizao. Na
produo de reports, foi tido em conta a pouca experincia do utilizador final com a
ferramenta. Deste modo, apenas exigido ao utilizador final que defina o intervalo temporal
que pretende analisar atravs da introduo da data no prompt.
A soluo final da resposta ao problema inicialmente existente foi entregue direo e
responsveis do projeto. Foi tambm realizada documentao tcnica que pode ser consultada
como Manual de utilizao do ambiente de produo. Este Manual serve para auxiliar o
utilizador final a orientar-se na ferramenta de reporting de forma a consultar informao para
posterior anlise e tomada de deciso (Anexo D).
4.6
Estrutura da soluo final
A soluo final foi idealizada com base na documentao analisada e nas necessidades
sentidas pela organizao.
A utilizao de uma ferramenta de reporting visa auxiliar a tomada de deciso
administrao e aos diretores das diversas reas de negcio da organizao. A restituio da
informao proveniente dos trs sistemas de informao internos permite estudar os processos
internos, avaliar melhorias de desempenho, estudar alternativas estratgicas, entre outros. A
criao de uma estrutura simples, organizada e reutilizvel um fator importante para a
anlise e controlo do negcio da organizao. Esta soluo fornece um conjunto de reports
ligados rea comercial que podem ser consultados por todos os colaboradores atravs do
MicroStrategy Web com conexo Intranet da organizao. Nesta primeira fase do projeto
Data Warehouse, a informao servir principalmente para o Departamento de Marketing e
Vendas e Quadros de Administrao.
Em seguida, representada a estrutura que o utilizador final pode aceder e consultar os
reports executados durante o projeto (Figura 20).
35
Figura 20 - Estrutura da soluo final
Os reports foram distribudos em diferentes pastas, numa disposio lgica baseada no

elemento de anlise definido pelo utilizador. Por exemplo, se o utilizador quiser analisar as
compras feitas pela organizao, ter de consultar a pasta Fornecedores que contm um
conjunto de reports com diferente informao e nvel de detalhe.
Atendendo pouca experincia dos utilizadores finais, os reports foram desenhados para
facilitar o processo de consulta e evitar a tentativa de edio. Para isso, foram criados prompts
em que o utilizador apenas ter de definir a(s) data(s) que pretende estudar (Figura 21).
Figura 21 - Exemplo de um prompt
Os reports foram construdos segundo uma lgica de identificar o objeto de anlise principal,
seguido de informao complementar que fornea mais alguns dados relevantes para anlise e
as mtricas mensurveis que reportam o nmero de ocorrncias dessa anlise, em unidades,
ou o valor respetivo dessas ocorrncias, em (Figura 22). Alguns filtros foram tambm
impostos dado que h restries exigidas pela rea comercial em determinadas consultas.
Todas as anlises necessitam de ser temporais, isto , foram criados prompts que permitem ao
utilizador definir a(s) data(s) a analisar.
36
Figura 22 - Exemplo de um report com detalhe dos diferentes componentes com dados fictcios
De referir ainda que o utilizador pode usar uma funo em todos os reports que permite a
navegao para diferentes nveis de informao a partir de um determinado report, designada
de Drill. possvel perfurar um nvel de informao para nveis de detalhe inferiores (DrillDown) ou superiores (Drill-Up). Por exemplo, o atributo Ms pode originar anlises a
nveis de informao superiores, como o ano ou o trimestre, ou nveis inferiores como semana
ou dia. Da mesma forma, a categoria de produto pode originar anlises a produtos atravs
desta funo (Drill-Down). Por esse motivo, ao longo do projeto sero sempre referidos
reports com a categoria do produto e no com o produto (apesar de tambm terem sido
criados esses reports) pois j se sabe que o utilizador pode analisar detalhadamente os
produtos.
O utilizador pode ainda consultar a informao atravs de informao tabelar, grfica ou sob o
formato de dashboards. Em anexo possvel observar um report representado de forma
grfica (Anexo E).
Em seguida so apresentados de forma esquemtica os reports desenvolvidos com maior
relevo. Nem todos so expostos por resultarem apenas de uma derivao de outros reports,
mas que apresentam mais restries de consulta de forma a tornar a experincia de consulta
mais acessvel e eficiente para os utilizadores. Foram desenvolvidos cerca de 150 reports dos
quais se destacam alguns, demonstrando as vrias possibilidades de anlise de informao
complementar. Essa informao pode ser vista como um todo num mesmo report ou ser
analisada separadamente e/ou com menos nveis de detalhe.
4.6.1
Armazns
Tratando-se de uma organizao que opera no setor de distribuio, o objetivo da OCP

Portugal, SA comprar produtos a fornecedores para posterior revenda aos seus clientes. O
Departamento de Compras encontra-se centralizado na Maia e distribui as suas compras para
os diversos armazns. Posteriormente, aps os pedidos dos clientes, a organizao vende e
distribui os produtos em stock. Assim, pode-se analisar se as exigncias dos clientes esto a
ser satisfeitas, podendo-se estudar quais os produtos que o Departamento de Compras deve
investir mais na sua aquisio e quais deve deixar de comprar. Foram efetuados, por isso,
reports com informao relativa s compras, vendas e stocks.
37
Tabela 5 - Estrutura dos reports cujo objeto de anlise o armazm

Objeto
de
anlise
Mtrica
Prompt
Detalhe
Informao
complementar
Valor das compras a fornecedores ()

Quantidade comprada (unidades)
Valor da faturao a clientes ()
Ms
Categoria do
produto
Quantidade vendida a clientes (unidades)

Regio
Valor em stock remanescente ()
Armazm
Quantidade em stock remanescente

(unidades)
Dia
Preo de custo em stock ()

Quantidade pedida pelos clientes (unidades)
Ms
Cliente
Quantidade vendida (unidades)

4.6.2
Fornecedores
A boa gesto dos relacionamentos com os fornecedores tem de ser uma das prioridades da
organizao no sentido de obter os melhores negcios com os mesmos em termos de prazos
de pagamento e descontos obtidos. Deste modo, analisar as vendas feitas pela OCP Portugal,
SA permite identificar quais os produtos mais procurados e quais os fornecedores mais
crticos. Esta anlise pode ainda identificar quais os fornecedores com maior taxa de
crescimento de procura. Outros reports foram realizados mas resultam da replicao dos
apresentados, apenas acrescentados de filtros relacionados com o fornecedor a visualizar (os
mais importantes).
Tabela 6 - Estrutura dos reports cujo objeto de anlise o fornecedor
Objeto de
anlise
Mtrica
Prompt

Devoluo ()
Quantidade vendida a clientes (unidades)
Informao
complementar
Tipo de
movimento
(compra)
Valor das compras a fornecedores ()
Fornecedor
Detalhe
Ms
Tipo de
documento
(venda)
Categoria do
produto
Cliente
38
Um outro report foi desenhado com o objetivo de analisar quais os clientes da OCP Portugal,
SA mais crticos de um determinado fornecedor. Do modo anlogo, tambm se pode analisar
os clientes com menor expresso de um dado fornecedor (Tabela 7).
Tabela 7 - Report que avalia a expresso dos clientes de um determinado fornecedor
Objeto de
anlise
Mtrica
Prompt
Detalhe
Classificao da
contribuio do
cliente

Fornecedor
Informao
complementar
Potencial do
cliente
Ms
Valor ilquido, descontos e IVA ()
Tipo de
documento
Cliente
4.6.3
Produtos
Os produtos so alvo de grande enfoque por parte do Departamento de Marketing e Vendas.

Perceber quais os produtos que so mais procurados pelos clientes torna-se fundamental para
conseguir alocar os vrios produtos pelos diferentes armazns a fim de melhorar a eficincia
de reposta aos pedidos dos clientes. Atravs do conhecimento dos seus produtos e dos seus
clientes, o Departamento de Marketing e Vendas pode criar campanhas focadas para
determinados segmentos de clientes. Tambm os comerciais podem aproveitar os reports para
identificar produtos com maior ou menor rotao e, assim, proporem novas ofertas aos
clientes.
Tabela 8 - Estrutura de reports cujo objeto de anlise o produto
Objeto de
anlise
Categoria
do produto
4.6.4
Mtrica
Prompt
Detalhe
Informao
complementar
Cliente

Ms
Princpio ativo
Documentos
Estes reports servem mais como um controlo estatstico dos tipos de documentos relacionados
com a faturao. Tambm so controladas as entradas por compras, transfer-orders, compras
em grupo e compras especiais.
39
Tabela 9 - Estrutura de reports cujo objeto de anlise o tipo de documento e contrato

Objeto de
anlise
Tipo de
movimento
(compras)
Mtrica
Valor das compras ()
Prompt
Detalhe
Informao
complementar
Ms

CMV, PVP e PVF ()
Contrato
Valor sujeito a desconto ()
Tipo de
documento
Valor ilquido, IVA, descontos ()
Ms
Cliente
Quantidade pedida pelos clientes

(unidades)
4.6.5
Margens
As margens so alvo de constante mudana imposta por medidas governamentais. Com a

reduo do Preo de Venda ao Pblico (PVP), as margens das farmcias e dos distribuidores
tambm sai afetada. As margens de comercializao das empresas distribuidoras e farmcias
tm vindo a diminuir e funcionam atualmente numa base regressiva e por escales de preos.
Isto , as margens de comercializao passaram a incorporar valores fixos para as farmcias e
grossistas. Assim, a organizao tem de evitar o aumento de custos operacionais, visto que as
margens de lucro tm vindo a diminuir. A reduo das margens obriga a organizao a
repensar os contratos estabelecidos com os fornecedores e a ser mais severa perante o
incumprimento do pagamento das encomendas dentro do prazo. Deste modo, devem tambm
ser analisados os clientes em questo. Algumas benesses quanto ao pagamento podem ser
concedidas aos melhores clientes em detrimento dos restantes.
Da a importncia destes reports pois permitem aos utilizadores comerciais identificar os
melhores clientes. Estes reports ajudam a entender tambm quais as margens por cliente e por
produto.
40
Tabela 10 - Estrutura dos reports cujo foco so as margens de um determinado objeto de anlise
Objeto de
anlise
Mtrica
Prompt
Detalhe
Cliente

Classe de
cliente
Valor ilquido, IVA e descontos ()
Classificao da
contribuio do
cliente
Ms
Margem de lucro ()
Margens
associadas
OCP Portugal,
categoria do
produto e ao
produto

Categoria
do produto
Ms
Margem de lucro ()
4.6.6
Informao
complementar
Stocks
Identificar os produtos, a sua quantidade e respetivo valor retidos no armazm ao final do ms

era uma das necessidades da organizao. Um dos projetos da organizao realizados em
paralelo consistia na anlise da rotao dos produtos nos armazns, o que exige o
conhecimento dos produtos existentes ao final do ms. Desta forma surgiu a oportunidade de
aproveitar as potencialidades do MicroStrategy para fornecer essa informao.
Tabela 11 - Estrutura dos reports cujo foco so os stocks remanescentes em armazm ao final
do dia
Objeto de
anlise
Armazm
Mtrica
Quantidade remanescente em stock

(unidades)
Valor remanescente em stock ()
Prompt
Detalhe
Informao
complementar
Categoria de
produto
Dia
Fornecedor
Lote
Preo mdio
de custo
4.6.7
Vendas
Esta pasta contm inmeros reports ligados com as vendas gerais analisadas em torno de
vrias vertentes. O utilizador final pode consultar toda a informao relativa s vendas de
acordo com os objetos de anlise pretendidos.
Contudo, foi colocado um pouco de nfase nos reports relacionados com a rea de crdito.
Face situao atual da reduo de margens, a prioridade dever passar por reduzir a
41
exposio a clientes de forma a diminuir as necessidades de fundo de maneio. Com estes

reports podem ser estabelecidos, controlados e analisados os plafonds de crdito concedidos
carteira de cliente.
Tabela 12 - Estrutura de reports cujo foco so as vendas de um determinado objeto de anlise
Objeto de
anlise
Mtrica
Prompt
Detalhe
Informao
complementar
Valor da faturao ()
Valor dos descontos ()
Valor ilquido ()
Volta
Valor do IVA ()
Ms
Armazm
Margem de lucro ()
Valor da faturao ()
Plafond de
crdito

Valor ilquido ()
Cliente
Valor do IVA ()
Ms
Forma de
pagamento
Margem de lucro ()
Valor da faturao ()
Valor ilquido ()
Comercial
Valor do IVA ()
Ms
Cliente
Margem de lucro ()
4.7
Definio de indicadores de performance
Um dos objetivos do projeto prendia-se com a criao de um conjunto de indicadores de

performance que permitissem avaliar o desempenho dos processos de negcio internos.
A implementao de uma ferramenta de apoio tomada de deciso permite definir
metodologias e estratgias para a melhoria da gesto dos processos de negcio. De facto, uma
organizao bem-sucedida aquela que consegue alinhar a sua estratgia com os interesses
dos seus vrios departamentos gesto estratgica. De modo a avaliar o desempenho
organizacional da OCP Portugal, SA foi criado um Balanced Scorecard (BSC). Este modelo
de avaliao de desempenho consiste num painel de gesto que permite acompanhar o
desempenho financeiro, controlando simultaneamente os progressos na construo de
capacidades e aquisio dos ativos intangveis necessrios para o crescimento futuro (Kaplan
and Norton 1996). Assim, a partir de uma viso balanceada e integrada da organizao, o BSC
42
permite descrever uma estratgia possvel de forma clara, por intermdio de quatro
perspetivas:
financeira
clientes
processos internos
aprendizagem e crescimento
Estas perspetivas esto todas interligadas entre si, formando uma relao de causa efeito. A
criao deste modelo visa alavancar o desempenho desejado pela organizao, gerando
consequentemente valor futuro. Atravs de um estudo analtico dos processos de negcio
foram definidos alguns indicadores de performance, que mais tarde foram convertidos em
mtricas no MicroStrategy (Tabela 13).
Tabela 13 - Indicadores de performance da organizao
Perspetiva
Indicadores
Financeira
Faturao total; Volume de vendas total; Faturao/cliente;

Quantidades de contratos novos; Prazo mdio de
cobranas/cliente; Margens de lucro/produto; Margens de
lucro/cliente; Descontos concedidos/cliente
Clientes
Satisfao da procura (nmero de produtos aviados/nmero de

produtos pedidos pelos clientes); Quantidade de voltas/armazm;
Tempo mdio de entregas/cliente; Tempo mdio de
pedidos/cliente; Nmero de reclamaes/cliente; Quantidade
vendida/categoria de produto
Processos internos
Nmero de linhas processadas/colaborador; Nmero de linhas

processadas/armazm; Nmero de produtos aviados/colaborador;
Tempo mdio de stockagem; Nmero de reclamaes por troca
de encomendas/cliente; Valor de reclamaes/volume de vendas
Crescimento e aprendizagem
ndices de motivao/colaborador; horas de formao/cliente;
Aps a identificao destes indicadores de desempenho, procurou-se sensibilizar a

organizao para a implementao desta metodologia para orientar os resultados ao seu
objetivo estratgico. Assim, a Administrao deve definir e implementar variveis de controlo
destes indicadores, metas a alcanar e iniciativas estratgicas para ir de encontro ao seu
objetivo estratgico. A organizao constri assim as bases para uma melhoria de
performance e de crescimento. Foi ento realizado um mapa estratgico para apreciao dos
Quadros administrativos e diversos departamentos. O mapa em questo refere-se a metas a
atingir para o prximo ano. A ttulo de exemplo representado na Figura 23 um possvel
mapa que representa um objetivo estratgico, assente em diversos indicadores com metas bem
definidas. Por questes de confidencialidade, no exposto o mapa estratgico realizado
durante o projeto para a organizao.
43
Figura 23 - Mapa estratgico adaptado para a organizao
44
4.8
Forecasting
Durante o projeto foram analisados os diversos processos de negcio, apesar do especial

enfoque na rea comercial que fazia parte do mbito da primeira fase do projeto DW da OCP
Portugal, SA. Aproveitando as potencialidades de restituio de informao de qualidade em
tempo-real por parte do MicroStrategy, foi idealizada uma anlise interessante para a
organizao. Tendo em vista a melhoria dos processos de negcio, identificou-se uma
possvel metodologia que a organizao deveria implementar. Esta metodologia surge como
um projeto complementar ligado anlise de previso de vendas e de quantidades requeridas
pelos clientes. No contexto de um processo de deciso sob incerteza ou risco, a previso
consiste em definir de uma forma mais precisa como se podero comportar, no futuro, as
variveis incontrolveis para o processo de deciso em causa.
Um dos principais problemas do setor de distribuio farmacutica tem a ver com a reduo
das margens dos produtos imposta pelo Governo. Por isso, a tendncia nos prximos anos
ser a da reduo de receitas. Isto conduz a que a organizao reduza os custos operacionais
praticados de forma a continuar rentvel. Assim, surge tambm a necessidade de evitar custos
desnecessrios de stockout e de manuteno de stock obsoleto.
O Departamento de Compras encontra-se centralizado na Maia e efetua as compras para os
sete armazns. Contudo, o procedimento de compras feito sem qualquer modelo de previso
da procura dos clientes. A experincia a base que define o nmero de compras a efetuar e
distribuir para os diversos armazns. Desta forma, a criao de modelos de previso visa
auxiliar o Departamento de Compras. Tambm os Departamentos de Marketing e Vendas e o
Financeiro podem aproveitar estes modelos para analisar as previses de vendas, e da
definirem algumas estratgias para ultrapassar as dificuldades e criar campanhas de marketing
aos seus clientes.
Atravs dos resultados histricos obtidos com a ferramenta de reporting, foram desenvolvidos
diversos modelos de forecast, com o objetivo de prever o volume de vendas e quantidades
procuradas totais, por armazm, por categoria de produto e por fornecedores especiais, nos
prximos meses. De referir que a indefinio constante dos valores das margens pode resultar
em outliers (grandes desvios cujas ferramentas de previso no so capazes de antever).
Contudo, sempre uma melhor prtica do que a atual que se baseia unicamente na
experincia. Espera-se que este projeto de forecast seja alvo de uma anlise mais cuidada e
incisiva por parte da organizao e tenha continuao no futuro.
Assim, ser exposto um exemplo prtico realizado com valores fictcios para assegurar o
direito de confidencialidade do negcio da organizao. No exemplo demonstra-se a previso
de quantidade procurada total.
Como foi dito, a grave crise e a reduo das margens tm conduzido a menores vendas da
organizao s farmcias. Assim, a constatao da tendncia negativa de requisies por parte
dos clientes uma realidade. Do mesmo modo, existe uma sazonalidade anual como se pode
comprovar na Figura 24. Assim, o modelo de forecast utilizado foi o de Holt-Winters, dado
que se trata de uma srie com tendncia e sazonalidade. Os dados deste caso juntamente com
a explicao do modelo em questo podem ser consultados no Anexo F.
45
Atravs da estimao de parmetros de amortecimento , e considerados (Anexo E),

possvel efetuar mtodos de previso. Estes parmetros so estimados com base no nvel,
tendncia e sazonalidade da srie temporal.
Figura 24 - Quantidade procurada real e prevista com valores fictcios
A linha azul indica os valores reais de quantidade procurada pelos clientes, enquanto a
vermelha corresponde previso dos valores a partir do final do primeiro perodo de anlise.
Esse perodo dita a sazonalidade da srie em estudo. A verde encontram-se os valores
previstos para os meses futuros. Como se pode constatar, este modelo ajuda a prever os
perodos mais crticos, isto , onde a procura aumenta. Neste caso so os meses de Vero.
Atravs deste modelo, a organizao consegue prever, com uma determinada margem de erro
associada, a procura dos prximos meses (Tabela 14).
Tabela 14 - Valores previstos para a procura de clientes
Data
Jun-13
Jul-13
Ago-13
Set-13
Out-13
Nov-13
Dez-13
Quantidades
pedidas
3.666.919
4.167.861
4.072.142
4.573.304
4.037.158
3.598.429
3.400.252
A anlise de forecast pode trazer inmeros benefcios organizao, dos quais se destacam:
reduzir a incerteza
melhorar o processo de comunicao e a criao de consensos
antecipar mudanas
aumento do conhecimento
auxiliar na tomada de deciso
Atravs deste mtodo, o Departamento de Compras pode analisar a informao histrica da
procura para identificar padres e implementar estratgias de compras mais precisas.
Como este exemplo podiam ter sido descritos muitos outros. Esta metodologia tem como
inteno sensibilizar a organizao para uma anlise cuidada s compras a efetuar de modo a
evitar excessos ou ruturas de stock, reduzindo assim os custos operacionais. Atravs desta
anlise, a organizao pode criar uma vantagem competitiva face aos seus concorrentes,
conseguindo antecipar mudanas, o que lhe confere a capacidade de responder de forma mais
rpida s exigncias dos clientes.
46
Anlise crtica aos resultados obtidos e perspetivas de trabalho

futuro
Num mundo empresarial cada vez mais competitivo, a conceo e utilizao de um sistema de
informao que suporte as atividades desenvolvidas pelas empresas determinante no seu
bom desempenho. Recorrendo sua base de dados, as empresas podem criar vantagens
competitivas face aos seus concorrentes. De facto, essas empresas podem usar essa
informao para interpretar a evoluo do mercado, antecipar comportamentos dos seus
clientes e responder de forma mais rpida e eficaz aos seus pedidos, estudar potenciais
clientes e fornecedores e reduzir tempos de tomada de deciso.
Nesse sentido, a OCP Portugal, SA viu no projeto Data Warehouse uma excelente
oportunidade de armazenar os dados dispersos pelos trs sistemas de informao internos num
nico repositrio. No caso em concreto, verificava-se uma elevada quantidade de informao
comercial espalhada pelos sistemas internos e que no estava a ser analisada na sua totalidade.
Atravs desta soluo BI, tornou-se possvel estabelecer a integrao dos diferentes sistemas,
algo que no acontecia anteriormente e que permite obter uma viso nica e integral dos
dados. A restituio da informao assegurada, sob a forma de reports, pela ferramenta de
reporting MicroStrategy.
Contactada a GEHIS para a implementao do projeto, foi necessrio atribuir responsveis do
projeto, bem como regras e procedimentos para o desenvolvimento de uma estrutura que
auxilie a tomada de deciso. Nesta fase, ficou estabelecido que a OCP Portugal, SA teria a
misso de definir as especificaes dos seus processos de negcio para o modelo arquitetural
do DW a ser construdo pela GEHIS. Contudo, a GEHIS definiu no oramento do projeto um
determinado nmero de horas alocados para a primeira fase do mesmo. Esta restrio implica
que todos os meses sejam imputadas as horas dispendidas numa determinada tarefa. Da que,
com a experincia obtida na primeira fase do projeto, a OCP Portugal, SA deve definir as
especificaes requeridas nas prximas fases sob risco de serem consumidos recursos
incorretamente e no ser possvel obter informao de qualidade relativa a uma determinada
rea de negcio (Data Mart).
Uma vez construda a arquitetura do DW, esto reunidas as condies para se iniciar a
conceo de reports no sentido de obter informao integrada de diversas fontes
(independentes entre si) resttuida por uma nica ferramenta. O conhecimento integrado dos
diversos processos de negcio permite identificar fluxos de negcio e necessidades de
informao por parte da organizao como um todo. Assim, este projeto incide sobretudo na
vertente analtica da informao, analisando os dados do passado para identificar padres e
perceber como o negcio se ir comportar no futuro. Esta anlise pode conduzir a organizao
a obter melhores desempenhos internos e responder rapidamente a mudanas do mercado.
Para formular reports que contribuam para identificar melhorias internas e que permitam
perceber a evoluo de desempenho necessria uma anlise a fundo pelos diversos
departamentos. Para o efeito muito contriburam as entrevistas realizadas internamente,
anlises a documentos e workflows para avaliar criticamente a informao recolhida e definir
indicadores de performance adequados para a medio da eficincia dos processos de negcio
da empresa.
47
Antes de implementar a soluo, a realizao de testes que afiram a qualidade da informao

um fator a ter em conta e que no pode ser descurado nas prximas fases do projeto, mesmo
que para isso seja consumido tempo precioso.
Chegou-se assim a uma soluo final que consiste num ambiente de trabalho lgico no
MicroStrategy, onde se apresenta informao repartida por diferentes ficheiros que contm os
reports a eles associados. Foram desenvolvidos cerca de 150 reports, com maior ou menor
detalhe, sempre numa perspetiva comercial e que permitia ao utilizador final a visualizao de
toda a informao relevante. O elevado nmero de reports deve-se ao facto de serem
realizados reports-base e, a partir destes introduzir nveis de detalhe crescentes com o
objetivo de evitar a edio por parte do utilizador final. A inexperincia do utilizador final
conduziu criao de um Manual de utilizao que procura auxiliar o processo de consulta.
A anlise do negcio da organizao permitiu definir um conjunto de indicadores capazes de
medir o desempenho sob vrias perspetivas: financeira, clientes, processos internos e
crescimento e aprendizagem. A identificao de indicadores exige que a organizao
estabelea as bases para que o objetivo estratgico seja alcanado. Assim, deve definir as
metas ou resultados que pretende atingir e quais as iniciativas estratgicas a implementar.
Tendo em vista uma futura anlise pela Administrao e posterior exposio dos resultados
pretendidos aos vrios departamentos, foi realizado um mapa estratgico com o objetivo de
comunicar a estratgia que permitir melhorar os resultados da organizao. Este mapa
estratgico visa alinhar todos os colaboradores em prol de um objetivo estratgico,
transmitindo-lhes a viso da organizao.
O setor de distribuio farmacutica vive momentos de incerteza quanto s consequncias que
as recentes medidas governamentais iro produzir. A quebra das margens imposta pelo
Governo, a fim de facilitar o acesso ao consumidor final, obriga a OCP Portugal, SA a reduzir
os custos operacionais. Daqui resulta que todos os departamentos da organizao devem
efetuar uma reflexo sobre quais os processos em que podem ser mais eficientes. Numa tarefa
complementar ao projeto, foi idealizado um modelo de forecast de vendas e quantidades
procuradas pelos clientes. Deste modo, a inteno deste modelo passa por incentivar a
organizao a abandonar a poltica de compras de produtos a fornecedores baseada na
experincia, incluindo um modelo que permita prever, com uma determinada margem de erro,
as quantidades requeridas pelos clientes. Alm disso, com esta anlise de forecast espera-se
que a organizao consiga antecipar eventuais mudanas da procura dos clientes, seja capaz
de gerar consensos e tenha mais uma ferramenta que auxilie o processo de tomada de deciso.
O objetivo estratgico definido pela Administrao, a ser divulgado a toda a organizao, e as
metas a atingir para as diversos indicadores de desempenho podem, por isso, ser baseadas nos
resultados previstos que so obtidos no modelo de forecast. A aplicao de um modelo de
forecast ir reduzir a incerteza quanto ao futuro e poder conduzir a ganhos de eficincia. Por
outras palavras, a definio de uma meta pode ser suportada pelos valores previstos para o
futuro. Simultaneamente, a antecipao a mudanas no futuro pode incentivar a organizao a
planear medidas que permitam obter uma vantagem competitiva face aos seus concorrentes.
Deste modo, este projeto contribuiu para a implementao de um SSD na OCP Portugal, SA
que possibilita aos gestores realizar consultas ad hoc em tempo-real. Ao consultar estes
reports, os gestores podem analisar e controlar a informao para serem capazes de tomar
decises tticas e estratgicas. Com a soluo proposta, os gestores iro encontrar um
ambiente de reporting simples e lgico. Foi desenvolvido um Manual de utilizao com os
procedimentos a realizar para consultar reports e com a descrio detalhada do contedo de
48
cada um desses reports. A quantidade de reports desenvolvidos possibilita aos gestores fazer
consultas mais ou menos detalhadas conforme a necessidade. Para o seu desenvolvimento,
revelou-se fundamental a realizao de reunies com o Diretor do Departamento de
Marketing e Vendas e a anlise aos processos de negcio e a documentao comercial. Ao
mesmo tempo, a implementao desta ferramenta reduz o acesso direto aos sistemas de
informao internos e diminui o tempo de tomada de deciso. A criao de indicadores de
desempenho contribuiu para incentivar a organizao a orientar a sua estratgia aos objetivos
dos diversos departamentos. Face s medidas implementadas pelo Governo, s atravs de um
esforo conjunto que a organizao poder continuar a aumentar a sua quota de mercado. A
definio de metas a atingir realizada pelos departamentos. Para sustentar as metas
propostas pelos departamentos, foi concebido um modelo de forecast que permite prever os
resultados. Com as informaes recolhidas do passado, o modelo procura prever os
comportamentos do futuro. Este modelo pode ser um grande auxlio para o Departamento de
Compras, no sentido de evitar situaes de stockout ou excesso de stock.
Este projeto serve de ponto de partida para a modelao arquitetural e anlise de informao
em outras reas de negcio, tais como reclamaes, logstica ou gesto do armazm. Estas so
as reas que a organizao j definiu para a segunda fase do projeto Data Warehouse. Mais
uma vez, a OCP Portugal, SA ser a responsvel pela especificao de requisitos de negcio
que a GEHIS ter que arquiteturar no DW. Aps a criao dos novos Data Marts, deve-se
seguir o mapeamento de novos reports relativos a essas reas de negcio.
A realizao do modelo de forecast durante o projeto tem como propsito a anlise contnua
da informao de modo a efetuar previses cada vez mais precisas e que possibilitem
melhorar a eficincia e eficcia dos processos de negcio da organizao. Por isso, a
organizao deve continuar a atualizar estes modelos e identificar outras anlises que possam
contribuir para a obteno de uma vantagem competitiva num mercado to competitivo como
o da distribuio farmacutica.
Assim sendo, o grande desafio passa por determinar quais os processos de negcio que
exigem maior nfase e que devem ser alvo de uma anlise mais cuidada para melhoria da
eficincia organizativa. Definidos os processos de negcio, deve-se analisar a informao
recolhida com as vrias ferramentas propostas pelo projeto e identificar padres de
informao. Estas ferramentas so apenas um suporte para a tomada de deciso, nunca a
deciso final. Essa cabe aos Quadros Administrativos e s diversas reas departamentais.
aqui que se evidencia a capacidade crtica e analtica dos gestores que tero um papel
fundamental para conduzir a organizao a melhores desempenhos. O sucesso da organizao
ser determinado pelas medidas que os gestores tomarem face s suas anlises e ser obtido
pelo esforo conjunto dos diversos departamentos que a constituem.
49
Referncias
Almeida, Maria Sueli, Missao Ishikawa, Joerg Reinschmidt, and Torsten Roeber. 1999.
"Getting Started with Data Warehouse and Business Intelligence." IBM redbooks.
Alter, S. 1992. Information systems: a management perspective: Addison-Wesley Pub. Co.
Ballou, Donald P, and Giri Kumar Tayi. 1999. "Enhancing data quality in data warehouse
environments." Communications of the ACM no. 42 (1):73-78.
Boehnlein, Michael, and Achim Ulbrich-vom Ende. 1999. Deriving initial data warehouse
structures from the conceptual data models of the underlying operational information
systems. Paper read at Proceedings of the 2nd ACM international workshop on Data
warehousing and OLAP.
Bonifati, Angela, Fabiano Cattaneo, Stefano Ceri, Alfonso Fuggetta, and Stefano Paraboschi.
2001. "Designing data marts for data warehouses." ACM Transactions on Software
Engineering and Methodology no. 10 (4):452-483.
Chaudhuri, Surajit, and Umeshwar Dayal. 1997. "An overview of data warehousing and
OLAP technology." ACM Sigmod record no. 26 (1):65-74.
Dell'Aquila, Carlo, Francesco Di Tria, Ezio Lefons, and Filippo Tangorra. 2008. "Business
intelligence systems: a comparative analysis." WSEAS Transactions on Information
Science and Applications no. 5 (5):612-621.
Densham, Paul J. 1991. "Spatial decision support systems." Geographical information
systems: Principles and applications no. 1:403-412.
Gallas, Susan. 1999. "Kimball Vs. Inmon." DM Direct Newsletter, September 1, 1999 Issue.
Hellerstein, Joseph M., Michael Stonebraker, and Rick Caccia. 1999. "Independent, open
enterprise data integration." IEEE Data Engineering Bulletin no. 22 (1):43-49.
Inmon, WH. 1996. Building the data warehouse. Wiley Computer Pub.(New York).
Inmon, William H. 1992. Building the Data Warehouse: John Wiley \\& Sons, Inc.
Jukic, Nenad. 2006. "Modeling strategies and alternatives for data warehousing projects."
Communications of the ACM no. 49 (4):83-88.
Jukic, Nenad, and Boris Jukic. 2009. Bridging the knowledge gap between operational
databases and data warehouses. Paper read at Information Technology Interfaces,
2009. ITI'09. Proceedings of the ITI 2009 31st International Conference on.
Jukic, Nenad, Boris Jukic, and Mary Malliaris. 2008. "Online analytical processing (OLAP)
for decision support." In Handbook on Decision Support Systems 1, 259-276.
Springer.
Kaplan, Robert, and David P Norton. 1996. The balanced scorecard: Harvard Business
School Press.
Kimball, R., and M. Ross. 2011. The Data Warehouse Toolkit: The Complete Guide to
Dimensional Modeling: Wiley.
Kimball, Raiph. 2006. The data warehouse toolkit: John Wiley & Sons.
Kimball, Ralph. 1996. "The Data Warehouse." Toolkit. John Wiley.
50
Kimball, Ralph, and Joe Caserta. 2004. The data warehouse ETL toolkit: John Wiley & Sons.
Kimball, Ralph, and Margy Ross. 2002. "The Data Warehouse Toolkit: The Complete Guide
to Dimensional Modeling."
Kimball, Ralph, Margy Ross, Warren Thorthwaite, Bob Becker, and Joy Mundy. 2008. The
data warehouse lifecycle toolkit: John Wiley & Sons.
Leon, A. 2008. Enterprise Resource Planning: Tata McGraw-Hill.
List, Beate, Robert M Bruckner, Karl Machaczek, and Josef Schiefer. 2002. A comparison of
data warehouse development methodologies case study of the process warehouse.
Paper read at Database and Expert Systems Applications.
Liya, Wu, G. Barash, and C. Bartolini. 2007. A Service-oriented Architecture for Business
Intelligence. Paper read at Service-Oriented Computing and Applications, 2007.
SOCA '07. IEEE International Conference on, 19-20 June 2007.
Lujn-Mora, Sergio, and Juan Trujillo. 2005. "A data warehouse engineering process." In
Advances in Information Systems, 14-23. Springer.
Mangold, J. 1998. "Turning straw into gold: How data mining transforms data from an
expense into an asset." DM Review no. 8.
Markus, M Lynne, and Robert I Benjamin. 1997. "The magic bullet theory in IT-enabled
transformation." Sloan Management Review no. 38 (2):55.
Microstrategy. 1998. Relational OLAP: an enterprise - wide data delivery architecture.
Moeller, Robert R. 2007. Coso enterprise risk management: understanding the new
integrated erm framework: Wiley.
Moody, Daniel L, and Mark AR Kortink. 2000. "From enterprise models to dimensional
models: a methodology for data warehouse and data mart design." DMDW00, Sweden
no. 5.
Nestorov, Svetlozar, and Nenad Jukic. 2003. Ad-hoc association-rule mining within the data
warehouse. Paper read at System Sciences, 2003. Proceedings of the 36th Annual
Hawaii International Conference on.
Oketunji, Temitope Adeoye. 2011. "Design of Data Warehouse and Business Intelligence
System."
Ponniah, Paulraj. 2001. "Data warehousing fundamentals."
Power, Daniel J. 2007. "A brief history of decision support systems." DSSResources. COM,
World Wide Web, http://DSSResources. COM/history/dsshistory. html, version no. 4.
Raimundo, Ldia Simes. 2007. "MetadataReporting de Gesto do GBES."
Rao, Fangyan, Long Zhang, Xiu Lan Yu, Ying Li, and Ying Chen. 2003. Spatial hierarchy
and OLAP-favored search in spatial data warehouse. Paper read at Proceedings of the
6th ACM international workshop on Data warehousing and OLAP.
Reddy, G Satyanarayana, Rallabandi Srinivasu, M POORNA CHANDER Rao, and Srikanth
Reddy Rikkula. 2010. "Data Warehousing, Data Mining, OLAP and OLTP
Technologies are essential elements to support decision-making process in industries."
International Journal on Computer Science and Engineering no. 2 (09):2865-2873.
Sabherwal, Rajiv, and Irma Becerra-Fernandez. 2010. Business intelligence: John Wiley &
Sons.
Santos, Ricardo Jorge, and Jorge Bernardino. 2008. Real-time data warehouse loading
methodology. Paper read at Proceedings of the 2008 international symposium on
Database engineering & applications.
Sen, Arun, and Atish P. Sinha. 2005. "A comparison of data warehousing methodologies."
Commun. ACM no. 48 (3):79-84. doi: 10.1145/1047671.1047673.
Sthr, Thomas, Robert Mller, and Erhard Rahm. 1999. An integrative and uniform model for
metadata management in data warehousing environments. Paper read at Proceedings
51
of the International Workshop on Design and Management of Data Warehouses,

Heidelberg, Germany.
Thomas, Gwen. 2006. "The DGI data governance framework." The Data Governance
Institute, Orlando, FL (USA).
Turban, Efraim, Ephraim McLean, and James Wetherbe. 1999. Information technology for
management (2nd ed.): making connections for strategic advantage: John Wiley
\\& Sons, Inc.
Turban, Efraim, Ramesh Sharda, Jay E Aronson, and David King. 2009. Business
Intelligence: um enfoque gerencial para a inteligncia do negcio: Bookman.
Vassiliadis, Panos, Zografoula Vagena, Spiros Skiadopoulos, Nikos Karayannidis, and Timos
Sellis. 2001. "ARKTOS: towards the modeling, design, control and execution of ETL
processes." Information Systems no. 26 (8):537-561.
Weber, Kristin, Boris Otto, and Hubert sterle. 2009. "One Size Does Not Fit All---A
Contingency Approach to Data Governance." Journal of Data and Information
Quality (JDIQ) no. 1 (1):4.
Wende, Kristin. 2007. A model for data governanceOrganising accountabilities for data
quality management. Paper read at 18th Australasian Conference on Information
Systems. The University of Southern Queensland, Toowoomba, Australia.
Wixom, Barbara H, and Hugh J Watson. 2001. "An empirical investigation of the factors
affecting data warehousing success." MIS quarterly no. 25 (1):17-32.
52
ANEXO A: Funcionamento do SSD
53
ANEXO B: Fases detalhadas do projeto na perspetiva da GEHIS
54
ANEXO C: Objetivos da reunio intermdia com a GEHIS e Celesio
Agenda OCPP-DWH
Follow Up:
Data Warehouse Implementation
OCP Portugal / Porto
29 April 2013
Participants
Name
Company / Department
Initials
Henrichs, Nicolai
Celesio / Group Sales
NH
Autenrieth, Peter
GEHIS / DWH
PA
Silva, Jos Miguel
OCPP / Controlling
JS
Silva, Miguel
OCPP / IT
MS
Ribeiro, Augusto
OCPP / IT
AR
Dias, Nuno
OCPP / IT
ND
Wednesday, 29 April 2013

#
Topic
Issue
Time
Who
Start:
09:30
am
NH, PA
1.
Introduction
2.
Status
OCPP
quo
Targets of the day, further steps, Open

Issues, organisational topics &
preferences, scheduling
Usage of OCPP-DWH
First experiences
Things to improve?
OCPP
55
Wednesday, 29 April 2013
3.
Status quo
GEHIS
Work
around
5.
Current organisational changes (ONE

IT)
Future of GEHIS / Situation Germany
Resources & Capacities
DWH Support
New Projects
PA, NH
New PSB (Project Charter)

New data tables to be implemented in
MSTR
SLA Draft
Next Steps how to work around
Communication structure
PA
NH
Invoices to be settled
Licences required (quantity / kind of?)
DWH Data Storage (Time / Size /
Tables)
PA, NH
Target of the meeting is to align OCPP

and GEHIS expectation in order to
agree on how processes,
communication, costs and issues can be
managed successfully in the future.
(Structure)
all
4.
Future
current
costs
&
6.
Agreement
Status of testing
Organisational Integration /
Responsibilities
Alignment between strategic and BI
topics
New Processes linked to BI?
Single Point of Truth?
56
ANEXO D: ndice e Introduo do Manual de utilizao desenvolvido no

projeto
ndice de Contedos
1 Introduo ........................................................................................................................................... 1
2 mbito do projeto Data Warehouse .................................................................................................... 2
3 Apresentao do Microsoft Strategy ................................................................................................... 3
4 Visualizao dos reports ..................................................................................................................... 4
5 Reports desenvolvidos e sua disposio ............................................................................................. 6
5.1 Armazns................................................................................................................................ 6
5.2 Fornecedores ........................................................................................................................ 13
5.3 Produtos................................................................................................................................ 24
5.4 Documentos.......................................................................................................................... 27
5.5 Margens ................................................................................................................................ 29
5.6 Stocks ................................................................................................................................... 32
5.7 Vendas .................................................................................................................................. 34
6 Pressupostos assumidos e cuidados a ter na consulta dos reports ..................................................... 48
7 Iniciao no MicroStrategy Desktop ................................................................................................. 49
8 Estrutura de um report....................................................................................................................... 51
8.1 Atributos e Mtricas ............................................................................................................. 52
8.2 rea de Filtro ....................................................................................................................... 53
8.3 Report View: Template ........................................................................................................ 53
9 Comandos prticos do MicroStrategy ............................................................................................... 55
10 View do Template ............................................................................................................................. 57
10.1 Design View ....................................................................................................................... 57
10.2 Grid View ........................................................................................................................... 57
10.3 Graph View ........................................................................................................................ 58
10.4 SQL View............................................................................................................................. 59
11 Exportao de resultados .................................................................................................................. 60
12 Como elaborar um report .................................................................................................................. 61
13 Objetos importantes para a construo de reports ............................................................................. 64
13.1 Filtros ................................................................................................................................... 64
13.2 Mtricas ................................................................................................................................ 67
57
13.3 Relatrios auxiliares ............................................................................................................. 71
58
Introduo
Atualmente, as melhores empresas so aquelas que conseguem aliar o seu Core Business a
uma forte estrutura ao nvel dos Sistemas de Informao. Os Sistemas de Informao revelam
dados importantes do passado e do presente, o que pode conferir uma vantagem competitiva
s empresas que melhor uso derem a esses dados. O sonho de qualquer organizao passa,
evidentemente, por antecipar a resposta dos clientes a determinadas medidas do Governo,
antecipar alteraes do mercado (variaes das margens, manifestaes de crise, ),
melhorar os contratos praticados com fornecedores e clientes, entre outros. Perante esta
necessidade crescente de interpretar o contexto de todos os agentes envolvidos no negcio e a
sua evoluo com base nos dados armazenados nos Sistemas de Informao da empresa
(OLgA, OFINA e CRM Management), a OCP Portugal, SA tem sua disposio um sistema
de reporting sofisticado o Microsoft Strategy.
Figura 25 - Logo do MicroStrategy
Sendo o OLgA o sistema de informao que garante a efetividade do negcio diariamente,

no se pode esperar que este seja preciso ao ponto de dar informao histrica. Desta forma, o
OLgA serve como sistema transacional da empresa que oferece informao diariamente para
o Data Warehouse, assegurando assim, a consistncia dos dados fornecidos pelo sistema de
reporting MicroStrategy. O Data Warehouse, sendo capaz de fornecer a informao
histrica, apresenta uma grande vantagem para os utilizadores finais pois estes podem fazer
anlises comparativas de diversos atributos.
Este Manual tem como objetivo a apresentao da ferramenta de reporting. So, tambm
explicados em detalhe os reports desenvolvidos at ao momento em que foi realizado o
Manual. O leitor ficar com uma ideia clara de como trabalhar nesses reports.
Para os leitores mais aventureiros e que pretendam criar novos reports, tambm explicado
o funcionamento do MicroStrategy Desktop (local onde podem desenvolver os reports) e a
rea onde podem guardar esses reports.
59
ANEXO E: Exemplo de um grfico do MicroStrategy com informao

omitida
60
ANEXO F: Dados do caso prtico e formulao do problema
Formulrio:
previso de
efetuada no instante t, aps ser conhecida a observao de
nt
estimativa do nvel da srie no instante t
bt
estimativa da tendncia da srie

estimativa da componente sazonal que prevalecer no instante
Previso:
61
Mtodo de Holt-Winters
01
01
01
para k = 1,2,,s
O processo adotado de uma grande simplicidade baseando-se nas primeiras s observaes

disponveis
i)
ii)
iii)
(j=1,,s)
Fonte: Bernardo Almada-Lobo, MQAD (2012)
Atravs da formulao do problema, pode-se constatar que:
Erro Percentual Absoluto Mdio (EPAM) = 4,2%
Desvio-padro = 210920 unidades
U-Theil = 0,65, o que determina que o mtodo naive menos eficiente que o mtodo
em avaliao pois inferior a 1
62

Fortulan Tese Mestrado

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Fortulan Tese Mestrado

Hochgeladen von

Copyright:

Verfügbare Formate

Sistema de apoio deciso com base em Business Intelligence e

Orientador na FEUP: Prof. Doutor Antnio Carvalho Brito

Faculdade de Engenharia da Universidade do Porto

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Aos meus pais e amigos

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Decision support system based on Business Intelligence and Data

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Gostaria de agradecer ao orientador da organizao, Jos Miguel Silva, pela orientao,

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

2 Enquadramento Terico ...................................................................................................................... 5

3 Estado atual da OCP Portugal, SA ................................................................................................... 15

4 Implementao da soluo BI ........................................................................................................... 24

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

4.5.6 Passagem a produo ....................................................................................................................... 35

5 Anlise crtica aos resultados obtidos e perspetivas de trabalho futuro ........................................... 47

Fases detalhadas do projeto na perspetiva da GEHIS ................................................ 54

Objetivos da reunio intermdia com a GEHIS e Celesio ............................................ 55

ndice e Introduo do Manual de utilizao desenvolvido no projeto ......................... 57

Exemplo de um grfico do MicroStrategy com informao omitida ............................. 60

Dados do caso prtico e formulao do problema ....................................................... 61

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Figura 1 - Funcionamento simplificado do SSD. Fonte: GEHIS (2010) ................................... 2

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Tabela 1 - Anlise PEST do contexto nacional ........................................................................ 15

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

No mbito da dissertao realizada no 2 semestre do 5 ano do Mestrado Integrado em

Apresentao da OCP Portugal, SA

Descrio do circuito interno de vendas

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

O projeto Data Warehouse na OCP Portugal, SA

Figura 1 - Funcionamento simplificado do SSD. Fonte: GEHIS (2010)

Antes da implementao deste projeto, a organizao consumia recursos desnecessrios para

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Atravs desta soluo de BI e a conceo de um Manual de utilizao do MicroStrategy para

Mtodo seguido no projeto

Figura 2 - Fases do projeto Data Warehouse. Fonte: GEHIS (2010)

Inicialmente foram realizadas entrevistas internas a vrios membros do Departamento de

Sntese dos objetivos do projeto

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Inicialmente, a primeira etapa consistiu na interpretao e compreenso da estrutura e do

Organizao e temas abordados

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

No presente captulo so apresentados os conceitos que ajudam a compreender um ambiente

A importncia da informao nas organizaes

Necessidades das organizaes

Novos desafios tm sido colocados nas organizaes devido globalizao, competio

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

A necessidade de controlar a informao e interpretar a evoluo do negcio assume, nos dias

viso concetual e multidimensional dos dados da organizao

O DW um sistema de BI baseado num banco de dados voltado para consultas complexas,

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Figura 4 - Arquitetura do DW segundo a perspetiva de Inmon. Fonte:

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Os dados so armazenados no EDW com um grande nvel de detalhe com o objetivo de

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

abordagem, o DW consiste na coleo de Data Marts interligados dimensionalmente.

Figura 5 - Arquitetura do DW segundo a perspetiva de Kimball. Fonte:

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse

Fontes externas de comunicao

As fontes externas de informao so os sistemas operacionais (OLTP) de registo que

Sistema de apoio deciso com base em Business Intelligence e Data Warehouse