ads:
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO
PUC-SP
Manuel Pier Sobrido
Fatores Críticos de Sucesso de Aplicações
de Business Intelligence Baseadas em Sistemas ERP
MESTRADO EM ADMINISTRAÇÃO
SÃO PAULO
2008
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO
PUC-SP
Manuel Pier Sobrido
Fatores Críticos de Sucesso de Aplicações
de Business Intelligence Baseadas em Sistemas ERP
Dissertação apresentada à Banca
Examinadora da Pontifícia Universidade
Católica de São Paulo, como exigência
parcial para obtenção do título de Mestre
em Administração, sob orientação do
Professor Doutor Onésimo de Oliveira
Cardoso.
SÃO PAULO
2008
ads:
BANCA EXAMINADORA
__________________________________
__________________________________
__________________________________
__________________________________
DEDICATÓRIA
Dedico este trabalho ao meu pai (in memoriam).
AGRADECIMENTOS
Ao professor Onésimo de Oliveira Cardoso, por sua orientação, dedicação e
apoio, em todas as etapas desta dissertação.
Aos professores Antonio Vico Mañas e Belmiro do Nascimento João, pelas
sugestões inestimáveis e oportunas, na qualificação deste trabalho.
Aos professores do programa de pós-graduação em administração, pela
dedicação e pelos preceitos transmitidos.
À Rita, secretária da pós-graduação que por sua preciosa ajuda, principalmente
nos momentos mais críticos.
Aos colegas de trabalho cujo apoio, solidariedade e incentivo traduziram em
ações o sentido da palavra “amizade”.
À empresa Petrom, em especial ao Jefferson, José Roberto, José Luiz, Luciano
e Sidnei pela atenção, participação, disponibilidade e total apoio a esta pesquisa.
A minha mãe, pela sua presença valiosa e fundamental, sou eternamente grato.
Ao meu irmão por suas sugestões que contribuíram muito, especialmente nos
momentos de incerteza.
A minha irmã, sobrinhos e cunhados, pelas orações e preocupação.
Aos meus amigos pela solidariedade e compreensão por minha ausência.
Enfim a todas as pessoas que contribuíram de alguma forma para a realização
deste trabalho.
RESUMO
SOBRIDO, Manuel Pier. FATORES CRÍTICOS DE SUCESSO DE
APLICAÇÕES DE BUSINESS INTELLIGENCE BASEADAS EM SISTEMAS
ERP. São Paulo, 2008. (Dissertação de Mestrado em Administração) – Programa
de Estudos Pós-graduados em Administração de Empresas da Pontifícia
Universidade Católica de São Paulo.
Business Intelligence (BI) é uma solução de suporte à decisão que ajuda
administradores e gerentes a transformar imensos volumes de dados
transacionais em informações úteis, que, ao serem disponibilizadas no momento
e no formato adequado, oferecem apoio em processos decisórios. Quando essa
tecnologia é empregada em conjunto com o sistema ERP (Enterprise Resource
Planning), elas se potencializam e os resultados ficam ainda melhores, pois o
ERP forma uma base de dados integrada, contendo dados consistentes de
várias áreas da organização. A exploração dessa base de dados corporativa
pode oferecer um conjunto valioso de informações, que são extremamente úteis
ao processo decisório da organização. Contudo, muitas empresas, ao
implementarem bons projetos de BI do ponto de vista técnico, acabam não
obtendo os resultados esperados de suas aplicações. Isso ocorre, pois o BI não
diz respeito apenas a uma questão tecnológica, mas exige também atenção a
outros fatores importantes, tais como: criatividade, cultura e pessoas que vejam
a informação como um recurso estratégico. O presente trabalho procura
entender o papel desses fatores que devem ser levados em consideração, pois
podem fazer a diferença entre o sucesso ou apenas o resultado medíocre de um
projeto. Para dar suporte à argumentação desse problema de pesquisa, realiza-
se, nesta dissertação, um estudo de caso na empresa PETROM – Petroquímica
Mogi das Cruzes S.A. Os resultados obtidos a partir das pesquisas bibliográficas
e do estudo de caso demonstram que os fatores críticos para o sucesso de
aplicações de BI analisados, podem exercer influência decisiva para o êxito de
projetos de BI, em especial os fatores que tratam da importância do apoio
executivo e do alinhamento das aplicações de BI com o negócio da empresa.
Palavras-chave: Sistema ERP, Sistema de Gestão Integrado, Business
Intelligence.
ABSTRACT
SOBRIDO, Manuel Pier. CRITICAL FACTORS OF SUCCESS IN BUSINESS
INTELLIGENCE APPLICATIONS BASED ON ERP SYSTEMS. São Paulo,
2008. (Master’s Degree Business Administration Dissertation) – Pontifícia
Universidade Católica de São Paulo - Business Administration Graduate Studies.
Business Intelligence (BI) is a support solution to decision-making that helps
business managers turn huge volumes of transactional data into useful
information, which, when timely available in the appropriate format offers support
to decision making. When this technology is applied together with the ERP
(Enterprise Resource Planning) system, it builds up and enhances results, since
ERP forms an integrated database containing consistent data from many areas of
the organization. The exploitation of this corporate database can offer valuable
information, which is extremely useful to the organization decision making
process. However, many companies, while implementing good BI projects from
the technical viewpoint, end up not obtaining the expected results from their
applications. This occurs because BI does not involve technological issues only,
but also requires special attention to other important factors such as: creativity,
culture and people who understands the full value of information as a strategic
resource. The purpose of this study is to show the factors that should be taken
into consideration, since they can make a difference between the project’s
success and its mediocre result. To support the reasoning of this research
problem, a case study of the company PETROM – Petroquímica Mogi das
Cruzes S.A. was carried out. The results obtained from bibliographical research
and the case study demonstrate that the critical factors for BI application success
analyzed, can decisively influence the success of BI projects, especially factors
dealing with the importance of executive support and BI applications alignment
with company’s business.
Keywords: ERP systems, Enterprise Systems, Business Intelligence.
LISTA DE FIGURAS
Figura 1 – Requisitos de informação para os tomadores de decisão....................2
Figura 2 – As duas ondas do ERP e seu impacto nas organizações ....................6
Figura 3 – Inteligência empresarial........................................................................7
Figura 4 – Os níveis hierárquicos da informação.................................................15
Figura 5 – Importância dos aspectos técnicos para o sucesso do BI..................22
Figura 6 – Conhecimento, construção, criação e comparação............................34
Figura 8 – Cadeia da qualidade da decisão ........................................................43
Figura 9 – Funções de um sistema de informação..............................................47
Figura 10 – Os três principais papeis dos sistemas de informação.....................50
Figura 11 – Os papéis em expansão dos sistemas de informação .....................53
Figura 12 – Evolução do ERP .............................................................................60
Figura 13 – Estrutura típica de funcionamento de um sistema ERP....................63
Figura 14 – Mudança de gestão empresarial para implantação do ERP.............64
Figura 15 – O impacto do ERP sobre as variáveis estratégicas..........................73
Figura 16 – Arquitetura possível, incluindo sistemas da empresa e de troca......79
Figura 17 – Juntos ERP e tecnologia Web expandem um grupo empresarial.....82
Figura 18 – Alternativas de integração do ERP no e-business............................83
Figura 19 – Arquitetura típica de uma aplicação de Business Intelligence..........99
Figura 20 – Exemplo de modelo de entidades e relacionamento......................109
Figura 21 – Exemplo de um modelo dimensional equivalente ao modelo entidade
relacionamento da figura 20 ..................................................................111
Figura 22 – Exemplo de dashboard...................................................................118
Figura 23 – Etapas de um projeto de BI............................................................120
Figura 24 – Medidas do sucesso ou falhas do BI..............................................132
Figura 25 – Relação entre a ferramenta de BI e o nível de êxito da aplicação..143
LISTA DE QUADROS
Quadro 1 – Resumo dos atributos da qualidade da informação..........................20
Quadro 2 – Qualidades de decisões e processos de decisão.............................45
Quadro 3 – Fatores críticos de sucesso para implantação do ERP ....................70
Quadro 4 – Principais vantagens e desvantagens dos sistemas ERP ................75
Quadro 5 – Exemplos de CRM analítico versus operacional...............................88
Quadro 6 – Comparação entre o banco de dados transacional e o DW/DM.....107
Quadro 7 – Nível de complexidade das alterações no BI..................................140
LISTA DE TABELAS
Tabela 1 – Fatores críticos de sucesso de aplicações de BI.............................147
Tabela 2 – Princípios do manifesto pelo desenvolvimento ágil identificados na
Petrom...................................................................................................180
Tabela 3 – Fatores críticos de sucesso de aplicações de BI.............................187
LISTA DE ABREVIATURAS E SIGLAS
ASP - Appllication Service Provider
BA - Business Analytics
BI - Business Intelligence
BPO - Business Process Outsoursing
BSC - Balanced Scorecards
CIO - Chief Information Officer
CRM - Customer Relationship Management
DM - Data Mart
DW - Data Warehouse
DSS - Decision Support System
EAI - Enterprise Application Integration
EDI - Electronic Data Interchange
EIS - Executive Information Systems
ERP - Enterprise Resource Planning
ES - Enterprise System
ETL - Extract, Transform and Load
KM - Knowledge Management
LOFT - Luck, Opportunity, Frustation e Threat
MIS - Managment Information System
MRP - Material Requirements Planning
MRP II - Manufacturing Resources Planning
OLAP - On Line Analytic Processing
ROI - Return on Investment
SAD - Sistema de Apoio à Decisão
SCM - Supply Chain Management
SOA - Service Oriented Architecture
TI - Tecnologia da Informação
TPS - Transaction Processing Systems
XML - Extensible Mark-up Language
SUMÁRIO
INTRODUÇÃO ......................................................................................................1
Problema da pesquisa.....................................................................................8
Objetivo geral...................................................................................................9
Objetivos específicos.......................................................................................9
Justificativa....................................................................................................10
Referencial teórico.........................................................................................11
Estrutura da dissertação................................................................................13
1 FUNDAMENTAÇÃO TEÓRICA ......................................................................14
1.1 Dados e informações...............................................................................15
1.1.1 A qualidade dos dados e das informações.....................................19
1.2 O conhecimento.......................................................................................24
1.2.1 O conhecimento organizacional......................................................26
1.3 Modelos e conhecimento.........................................................................32
1.4 Inteligência..............................................................................................37
1.5 Tomada de decisão ................................................................................39
1.5.1 O processo de tomada de decisão e de resolução de problemas........39
1.5.2 A qualidade das decisões...............................................................42
1.6 Sistemas de informação ..........................................................................45
1.6.1 Sistema de apoio às operações......................................................50
1.6.2 Sistema de apoio gerencial.............................................................51
2 SISTEMA ERP E BUSINESS INTELLIGENCE...............................................56
2.1 ERP – Enterprise Resource Planning......................................................57
2.1.1 ERP: um breve histórico.................................................................59
2.1.2 Ciclo de vida do ERP nas empresas...............................................67
2.1.3 O ERP e as informações úteis para o processo decisório..............70
2.1.4 Vantagens e desvantagens do sistema ERP..................................74
2.1.5 ERP: principais tendências dessa revolução..................................78
2.1.6 CRM – Customer Relationship Management..................................84
2.1.7 SCM – Supply Chain Management.................................................89
2.1.8 Conhecimento organizacional e ERP .............................................91
2.2 Business Intelligence...............................................................................94
2.2.1 Definição do Business Intelligence .................................................96
2.2.2 Arquitetura típica de uma aplicação de Business Intelligence ........97
2.2.3 ETL – Extrair, transformar e carregar dos dados............................99
2.2.3.1 Extração dos dados.............................................................101
2.2.3.2 Transformação dos dados...................................................102
2.2.3.3 Carga dos dados..................................................................104
2.2.4 Data Warehouse...........................................................................105
2.2.4.1 Data Warehouse – modelagem de dados............................108
2.2.4.2 Data Mining e predictive analysis.........................................111
2.2.5 Ferramentas de BI: front-end........................................................114
2.2.5.1 Gerador de relatórios e queries ...........................................114
2.2.5.2 OLAP...................................................................................115
2.2.5.3 Microsoft Office....................................................................117
2.2.5.4 Dashboards .........................................................................118
2.2.5.5 Scorecards...........................................................................119
2.2.6 Etapas de um projeto de Business Intelligence ............................119
2.2.7 Business Intelligence Competency Centers (BICC)......................124
2.2.8 ERP e Business Intelligence: soluções complementares .............125
2.2.9 Fatores para o sucesso de uma aplicação de BI..........................128
2.2.9.1 Principais fatores que contribuem para o sucesso de uma
aplicação de Business Intelligence..................................................129
2.2.10 Modelo teórico padrão................................................................146
3 METODOLOGIA............................................................................................149
3.1 Procedimentos metodológicos...............................................................149
3.2 O protocolo para o estudo de caso........................................................151
3.2.1 Visão geral do projeto do estudo de caso.....................................151
3.2.2 Procedimentos de campo.............................................................153
3.2.3 Questões da pesquisa..................................................................155
3.2.4 Avaliação dos resultados..............................................................155
4 ESTUDO DE CASO .......................................................................................158
4.1 Setor da indústria química.....................................................................158
4.2 Histórico e estrutura da empresa...........................................................159
4.3 Histórico do sistema ERP e Business Intelligence na empresa.............162
4.4 Análise dos dados e discussão dos resultados obtidos.........................165
4.5 Resumo dos resultados obtidos da análise do caso estudado..............186
CONSIDERAÇÕES FINAIS ..............................................................................188
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................192
ANEXOS ...........................................................................................................201
1
INTRODUÇÃO
As transformações nas empresas ocorrem de maneira rápida, e,
dessa forma, uma estratégia bem sucedida no passado recente pode não ter
mais a mesma eficiência hoje, em virtude de alterações ocorridas no mercado.
Para que se mantenham competitivas, as empresas devem se atentar às
mudanças ambientais, tecnológicas, comportamentais, mercadológicas, legais,
entre outras, de forma a responder, de maneira adequada, a essas mudanças,
efetuando alterações na condução de suas estratégias, ou mesmo alterando as
estratégias em curso.
Esse cenário de constantes mudanças faz com que os
administradores de uma organização sejam forçados a tomar decisões em um
volume cada vez maior, de forma mais rápida e precisa. Para auxiliá-los nesse
processo, existem os sistemas de informação. Segundo Laudon e Laudon
(2007, p. 9) um sistema de informação é definido como
um conjunto de componentes inter-relacionados que coletam (ou
recuperam), processam, armazenam e distribuem informações
destinadas a apoiar a tomada de decisões, a coordenação e o
controle de uma organização.
Um dos objetivos de um sistema de informação é o de dar apoio
ao processo decisório. No entanto, existem diferentes tipos de decisões a
serem tomadas dentro de uma organização que vão das mais simples e
rotineiras, às estratégicas. Essa variação depende do nível hierárquico de
quem toma decisões e do grau de complexidade da decisão, o que faz com
que a necessidade de informações requerida pelos tomadores de decisões
também seja diferente. De acordo com Laudon e Laudon (2007), as decisões
podem ser classificadas em três tipos:
2
• decisões não estruturadas – aquelas em que o responsável pela
tomada de decisão deve usar seu bom senso, sua capacidade de
avaliação e sua perspicácia na definição do problema. Cada uma dessas
decisões é inusitada, importante e não rotineira, e não há procedimentos
predefinidos para tomá-las.
• decisões estruturadas – são repetitivas e rotineiras e envolvem
procedimentos predefinidos de modo que não precisam ser tratadas
como se fossem novas.
• decisões semi-estruturadas – são aquelas para as quais parte do
problema tem uma resposta clara e precisa, dada por um procedimento
aceito.
A figura 1 ilustra a relação entre os requisitos de informação para os
tomadores de decisão e os tipos de decisões.
Figura 1 – Requisitos de informação para os tomadores de decisão
Fonte: adaptado de O’Brien (2004, p. 281)
Os sistemas integrados de gestão ou sistemas ERP (Enterprise
Resource Planning), como são mais conhecidos, atendem de forma natural às
3
decisões estruturadas, sendo essa uma de suas funcionalidades prontamente
utilizadas quando o ERP entra em operação.
O ERP é um sistema de informação adquirido no mercado, sob a
forma de pacotes comerciais de software, cujo propósito é a integração dos
dados e dos processos de negócio de uma organização. Segundo Norris et al.
(2001), o que o ERP faz é organizar, codificar e padronizar os processos e
dados de negócio de um grupo empresarial.
No mercado nacional, a disseminação do uso de sistemas ERP
ganhou força a partir de meados dos anos 90, e se tornou um fenômeno na
gestão da Tecnologia da Informação (TI). O seu crescimento foi possível
devido a uma conjuntura de fatores tais como: exploração a necessidade de
rápido desenvolvimento de sistemas integrados, a fim de atender às novas
necessidades empresariais; o avanço do processo de terceirização de todas as
atividades que não pertencem ao foco principal de negócios da empresa; o
amadurecimento das opões disponíveis; a evolução da tecnologia utilizada por
esses pacotes (bancos de dados relacionais, processamento cliente/servidor e
mais recentemente a Internet); além de algumas histórias de sucesso de
empresas que os adotaram no início dos anos 90 (ZWICKER & SOUZA, 2003).
Vale à pena acrescentar também a esse conjunto de fatores a aproximação do
ano 2000, e com ele o chamado bug do milênio. Além disso, na Europa, a
adoção do EURO também teve forte influência.
A implantação de um sistema ERP exige a revisão de processos,
com forte interferência em aspectos organizacionais, estruturais e culturais das
empresas que optam por sua adoção. Muitas aproveitam esse momento para
reorganizarem seus processos, com o objetivo de extrair o máximo de proveito
que o ERP pode oferecer. Para Mañas (2003), se a organização fizer
mudanças profundas em seus processos de gestão, obterá maior grau de
satisfação com o uso de seus sistemas. Para isso, os gestores devem ter
claras as suas necessidades de informação e do processo decisório existente,
atuando para a consecução de transformações que visem à integração, com
garantias da existência da ética como palavra de ordem. Ao gestor, cabe ser
4
suprido pelas informações necessárias e também estabelecer a integração
pertinente nas áreas estratégicas, tecnológica e, principalmente, humana, entre
outras. Ao ERP cabe ‘apenas’ facilitar essas atividades.
Em decorrência desse processo de reorganização, quando da
implantação de um sistema ERP, a empresa que estiver consciente do
potencial transformador desses sistemas, pode construir, a partir desse evento,
uma nova plataforma de TI (Tecnologia de Informação), que não só atenda aos
processos operacionais, mas também que disponibilize informações que
possam contribuir no processo decisório estratégico. Com a utilização do ERP,
uma empresa pode criar uma nova fundação para a informação, substituindo
sistemas legados, pertencentes a diferentes épocas, que acumulam dados de
maneiras diferentes. A gerência sênior pode usar o ERP para conseguir
controle sobre a informação para melhorar o apoio à tomada de decisões
(NORRIS et al. 2001).
Para a Deloitte Consulting (1998), a melhora na capacidade de
tomada de decisões, resultante da implantação de um sistema corporativo
como o ERP, pode ajudar uma organização a rever inteiramente sua estratégia
de negócios.
Ocorre, porém que muitos administradores e gerentes
perceberam que ao fim da implantação desses sistemas os processos internos
haviam sido revistos e que novas práticas operacionais haviam sido
incorporadas às rotinas da empresa, melhorado significativamente seu
desempenho. Entretanto, estavam, de certa forma, desapontados, pois suas
expectativas em relação à obtenção de informações gerenciais eram
extremamente elevadas e não se concretizaram de imediato com a entrada em
operação do ERP. Essa frustração tem origem no fato de que muitos
executivos, ao adquirirem um sistema ERP, acreditam que com a entrada em
operação do sistema o processo de implantação está encerrado, bastando,
assim, usufruir imediatamente dos benefícios prometidos quando da sua
aquisição.
5
Essa frustração é compreensível, pois quando o ERP surgiu,
tratava basicamente dos processos internos das organizações, com outras
funções tais como as que tratam do relacionamento com os clientes,
fornecedores e ferramentas para suporte ao processo decisório, que eram
vendidas separadamente pelos fornecedores do ERP ou por outros
fornecedores independentes.
Dessa forma, administradores e gerentes perceberam que a
entrada do ERP em operação significava o fim da primeira etapa de um
processo e o início da segunda, marcada por ações que permitem às empresas
utilizarem plenamente as capacidades do ERP, beneficiando-se delas.
A Deloitte Consulting (1998) chamou a fase da pós-implantação
de ‘Segunda Onda’. Sendo assim, a “Primeira Onda” corresponde às
mudanças necessárias pela qual uma empresa deve passar para que o ERP
entre em operação, ou seja, as mudanças relacionadas com o planejamento da
implantação, revisão de processos, mudanças tecnológicas e treinamento dos
recursos humanos.
Já a ‘Segunda Onda’ corresponde ao que ocorre na pós-
implantação, quando o sistema se estabiliza, criando as condições necessárias
para a implantação de funções complementares, tais como o e-Business, as
melhorias na cadeia de suprimentos, o gerenciamento no relacionamento com
os clientes e as ferramentas de suporte à decisão. Nesse momento, o ERP
atinge sua maturidade, por meio da disponibilidade de novas competências,
agilidade nos processos, redefinição da operação de negócios, acesso à
informação, podendo, dessa forma, contribuir para o desempenho da empresa
de forma mais eficiente. A figura 2 ilustra essa evolução.
6
Figura 2 – As duas ondas do ERP e seu impacto nas organizações
Fonte: adaptado de Deloitte Consulting (1998)
Os fornecedores desses sistemas, mediante essa constatação,
passaram a incorporar essas funções complementares ao ERP. Segundo
Haberkorn (2007), o ERP está ‘engordando’, com novas funcionalidades, uso
da Internet e maior suporte à decisão. Essa ampliação de funções é conhecida
como EAI (Enterprise application Integration), um ecossistema que contempla o
CRM (Customer Relationship Management), o SCM (Supply Chain
Management) e o BI (Business Inteligence).
Na ‘Segunda Onda’, as empresas passaram a consolidar suas
revisões em processos e, efetivamente, a aplicar alguns dos preceitos trazidos
pela idéia de processos interdepartamentais integrados. Assim, é possível
afirmar que os sistemas ERP se tornaram um dos principais componentes dos
sistemas de informação de empresas de grande e médio porte no Brasil e no
mundo (SOUZA & SACCOL, 2003). No entanto, para maximizar os benefícios
que os sistemas integrados podem oferecer ao longo do tempo é necessário
que as equipes responsáveis pelas diversas áreas de uma organização usuária
do ERP, explorem as capacidades do software e saibam quais são as
necessidades da empresa.
Uma das maneiras de fazer com que o ERP contribua no
processo decisório, em especial no estratégico, é construindo aplicações de
inteligência de negócios ou Business Intelligence ou simplesmente BI. Para
LAUDON e LAUDON (2007, p. 150), o conceito de inteligência relacionada aos
A Ferramenta
ERP
Primeira Onda
Implantação do
ERP
Entrada em
operação
Segunda Onda
Otimização de
Processos
O Destino
Crescimento
Agilidade
Rentabilidade
A Jornada: Transformação da Empresa
7
seres humanos pressupõe a capacidade de combinar o conhecimento
adquirido com novas informações, alterando o comportamento, com a
finalidade de executar determinada tarefa ou adaptar-se a novas situações.
Para eles,
(...) a inteligência empresarial confere às empresas a capacidade
de acumular informações; adquirir conhecimentos sobre clientes,
concorrentes e operações internas; e mudar o comportamento de
tomada de decisões a fim de alcançar maior lucratividade e outras
metas corporativas.
O Business Intelligence não é um sistema nem um produto; é uma
arquitetura que engloba o Data warehouse (DW), ferramentas de OLAP (On
Line Analytic Processing), EIS (Executive Information Systems), Data mining e
DSS (Decision Support System). O propósito do Business Intelligence é o de
permitir a tomada de decisões, disponibilizando informações adequadas aos
negócios no momento e no formato apropriado. A figura 3 ilustra essa
arquitetura.
Figura 3 – Inteligência empresarial
Fonte: adaptado de Laudon e Laudon (2007, p.151)
8
Implementar aplicações de BI, porém, exige que certos fatores
entrem em ação, pois os fundamentos que o ERP oferece podem contribuir em
muito, mas não é o suficiente. Outros componentes devem ser trabalhados
também, tais como conseguir o apoio da direção da empresa, a seleção de
softwares, a composição da equipe de BI, entre outros.
Partindo-se dessas considerações, o objetivo deste trabalho é o
de identificar quais são os fatores críticos de sucesso na implantação de
aplicações de Business Intelligence, cujo desenvolvimento é baseado no ERP.
A reflexão sobre o tema deste trabalho surgiu da vivência deste
pesquisador como consultor e usuário de um desses sistemas, ao longo de 14
anos, com participação ativa em todas as fases de um projeto de implantação
de um sistema ERP, em todos os seus estágios. Essa vivência fomentou no
pesquisador questionamentos em relação à exploração das interações entre os
sistemas ERP, os aplicativos de BI e o processo decisório.
Problema da pesquisa
As organizações devem usar as informações de que dispõem
para criar significado, construir conhecimentos e tomar decisões. A informação
e o conhecimento são fundamentais no processo decisório, sendo assim, deve-
se entender o papel desempenhado por uma solução de suporte à decisão
como o Business Intelligence, principalmente, quanto este conta com o suporte
e a solidez de dados que um sistema ERP oferece.
O banco de dados formado pelo ERP pode fornecer um conjunto
significativo de informações sobre diversas áreas da empresa, permitindo aos
seus administradores gerar conhecimentos que darão subsídios para uma
maior eficiência do processo de tomada de decisões. Com ele, é possível,
também, combinar as informações oriundas do ERP com informações
provenientes de outros sistemas e de fontes externas às organizações,
9
formando, assim, uma poderosa base de dados. Segundo a Deloitte Consulting
(1998), é na fase de pós-implantação que o processo de utilização do ERP no
processo decisório estratégico ocorre, pois é nessa fase que novas
funcionalidades e ferramentas passam a ser utilizadas, criando-se o ambiente
propício para a exploração da base de dados corporativa.
O tempo e a pressão por resultados faz com que algumas
empresas passem a explorar os recursos e funcionalidades que o ERP oferece,
maximizando seus benefícios. Nesse sentido, o business intelligence
representa a arquitetura que permite que esse conjunto imenso de dados
formado pelos processos transacionais do ERP se transforme em informações
úteis, disponibilizadas no formato e no momento adequado para a tomada de
decisões.
O ERP disponibiliza uma base de dados consistente e integrada
enquanto o Business Intelligence oferece os meios de explorar esse recurso.
Assim, o problema de pesquisa deste texto consiste em estudar como algumas
empresas alcançam o sucesso em explorar essa estrutura, enquanto outras
não, mesmo quando baseadas em projetos bem estruturados tecnicamente. O
entendimento dessa diferença pode ocorrer por meio da análise dos fatores
críticos que determinam o sucesso de aplicações de BI, no caso deste estudo
em particular, as baseadas em sistemas ERP.
Objetivo geral
Para se responder a pergunta problema, neste texto objetiva-se
identificar os fatores críticos de sucesso de aplicações de Business
Intelligence, baseadas em sistemas ERP.
Objetivos específicos
Para se alcançar este objetivo, estuda-se, aqui, o caso específico,
da PETROM – Petroquímica Mogi das Cruzes S.A, visando saber:
10
• as razões que levaram a empresa a utilizar o BI;
• como a empresa conduziu o projeto de BI;
• como foi o processo de construção das aplicações de BI;
• os fatores críticos que possibilitaram a implantação das aplicações de BI
na Petrom;
• estudar a avaliação que a empresa tem de suas aplicações de BI;
• analisar os benéficos que as aplicações de BI trazem para a empresa; e
• verificar o que a empresa pretende no futuro em relação ao BI.
Justificativa
Este estudo se justifica, no fato de que, nos últimos anos, muitas
empresas têm se esforçado para implantar sistemas ERP, com o objetivo
imediato de melhorar suas operações, padronizar dados, controlar processos,
tornar a empresa mais ágil, conectada com a Internet e com outras empresas.
Porém, o objetivo maior é o de usufruir de informações que as ajudem a
melhorar o seu conhecimento sobre assuntos relacionados aos negócios da
empresa e, assim, efetuar um processo decisório mais ágil, seguro e eficiente.
Passada a fase de implantação e de acomodação do ERP, algumas empresas
iniciam um processo de maximização da obtenção de benefícios que esses
softwares podem proporcionar.
Segundo Davenport (2002), as empresas precisam começar a
transformar os grandes investimentos que fizeram nos sistemas ERP, em
melhoria de desempenho, aperfeiçoamento na tomada de decisões e em
vantagem competitiva. Uma das maneiras de obter esses tipos de benefícios
de um sistema ERP é o da construção de uma aplicação de Business
Intelligence, que concretize o tão esperado acesso às informações ágeis,
interativas, multidimensionais e exatas que darão apoio ao processo decisório.
Porém, a má notícia, segundo Atre (2003), é que mais da metade dos projetos
de Business Intelligence não são concluídos ou não conseguem cumprir aquilo
que foi acordado quando de seu início.
11
Mesmo as empresas que aplicam uma metodologia para a criação
de uma aplicação de BI têm grandes chances de serem mal sucedidas, se
concentrarem seus esforços apenas nas questões técnicas, financeiras e
burocráticas, como é de praxe com outros projetos da área de TI. O
responsável por um projeto de BI precisa se atentar e se associar à
metodologia a ser utilizada, e a outros fatores que podem ser decisivos para o
êxito de aplicações de Business Intelligence. Tais fatores estão relacionados: a
falhas do alinhamento do projeto com o negócio da empresa; a não contar com
um executivo patrocinador do projeto; a não levar em consideração aspectos
culturais; a falhas na divulgação do projeto; a falhas na composição da equipe
do BI; entre outras.
A maioria dos problemas que fazem com que muitos projetos de
BI não obtenham o êxito esperado tem origem na adoção de uma abordagem
errada, excessivamente técnica para se tratar de um algo que deve ter
direcionamento nos negócios da empresa, como é o caso do Business
Intelligence.
Todas essas considerações justificam a realização deste estudo,
pois a resposta para a pergunta problema trará subsídios para melhor
entendimento sobre o processo em discussão.
Referencial teórico
Posto que o objetivo central deste trabalho é o estudo de fatores
críticos de sucesso na aplicações de Business Intelligence, que apóiem o
processo decisório estratégico, a abordagem que melhor oferece apoio para a
compreensão desta arquitetura é a que trata da transformação dos dados em
conhecimento útil para a inteligência de negócios da empresa.
Para fundamentação desta dissertação, serão analisados
conceitos relacionados a dados, informações, sistemas, modelos,
conhecimento e inteligência. A proposta é a de uma abordagem diferenciada
do papel que o ERP desempenha em uma organização, não apenas como um
12
sistema de caráter operacional, mas também como plataforma para a
construção de uma aplicação de inteligência de negócios. Essa abordagem é
possível se tomar-se por análise o sistema ERP sob a ótica da geração do
conhecimento, ou seja, o ERP pode fornecer informações que geram
conhecimentos, e esses conhecimentos combinados à experiência criam a
inteligência necessária para a tomada de decisões e conseqüente vantagem
competitiva.
Segundo Moresi (2000), a atividade máxima de um executivo
dentro de uma organização é o processo de tomada de decisões, e é isto que
justifica a sua existência dentro dela, tendo como processo decisório o
resultado de um processo de reflexão, investigação e análise. No processo
decisório, o volume de dados e informações deve acontecer na medida certa,
pois dados e informações importantes para a solução de um problema podem
se perder no meio de outros sem relevância. Para tanto, é necessário ter clara
a diferença entre dados, informação, conhecimento e inteligência; pois elas
possuem importâncias diferentes no processo decisório.
No que tange à criação do conhecimento, este trabalho
fundamenta-se nos estudos de Polanyi (1966) e Nonaka e Takeuchi (1997).
Para entender a importância da utilização do ERP como o eixo
principal em torno do qual novas funcionalidades são utilizadas para suportar
estratégias de negócios da empresa, consultam-se os estudos de Norris et al.
(2001) e Davenport (2002).
Sobre sistemas de informação e seus componentes, são
referenciados os trabalhos de Laudon e Laudon (2007), O’brien (2004) e Stair e
Reynolds (2008).
Sobre os aplicativos de Business Intelligence, referenciam-se o
trabalho de Inmon (2002), considerado o ‘pai’ da dataware house; Moss e Atre
(2003), por sua abordagem mais pragmática e técnica; Turban et al. (2007),
pela visão que oferece do BI dentro de um contexto de aplicativos de suporte à
13
decisão; e, por fim, Howson (2008), que contribui com sua visão holística para
o sucesso de aplicações de BI e de cujas pesquisas extrai-se o padrão teórico
aplicado ao estudo de caso deste trabalho.
Estrutura da dissertação
Esta dissertação está, assim, organizada: Capítulo 1, em que se
apresentam os conceitos de Dados, informações, conhecimento,
conhecimento organizacional, modelos, inteligência, sistemas e sistemas
de informação; Capítulo 2 – Sistemas integrados de gestão – ERP e
Business Intelligence – em que se apresentam os conceitos do sistema ERP,
Business Intelligence, seus componentes, as características relevantes
relacionadas ao processo de tomada de decisões, e onde se avalia o padrão
referencial teórico a ser utilizado para a análise dos dados do estudo de caso;
Capítulo 3 – Metodologia – define a metodologia utilizada na pesquisa, é
efetua-se uma explanação pela escolha do método qualitativo de pesquisa, em
seguida são apresentados os métodos de coleta e análise dos dados; Capítulo
4 – Estudo de caso – em que se analisa o estudo de caso único,
apresentando a caracterização da organização pesquisada e a análise dos
resultados baseados na adequação do caso estudado em relação ao padrão
teórico; as Considerações finais, com a retomada das proposições iniciais
disponibilizadas na introdução da dissertação, observadas com base no
desenvolvimento do trabalho, além de sugestões para pesquisas futuras; e, por
fim, as Referências e os Anexos.
14
1 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta e reflete sobre a teoria que oferece apoio
ao tema desta pesquisa, tais como: dados, informações, modelos,
conhecimento, conhecimento organizacional, inteligência, processo de decisão,
sistemas e sistemas de informação, com ênfase naqueles pertinentes ao
objetivo deste trabalho.
Para que seja possível dar suporte ao processo de inteligência,
por meio de um aplicativo de suporte à decisão, mais especificamente o
Business Intelligence, é necessário que os dados sejam coletados por
processos organizacionais no ambiente interno e externo de uma organização.
Esses dados, quando processados, se transformam em informações que ao
serem interpretadas, combinadas e analisadas juntamente com outros dados
geram o conhecimento. Esse conhecimento, por sua vez, associado ao
julgamento e à intuição (experiência), permitem, ao tomador de decisões, uma
visão completa sobre uma determinada situação ou ambiente, o que o capacita
para atuar com vantagem nesse ambiente (MORESI, 2000). A figura 4 ilustra
essa hierarquia da informação e os processos envolvidos em cada etapa.
Como o objetivo deste trabalho é estudar os elementos que
devem atuar para a implementação de aplicativos de BI baseados em sistemas
ERP, enfatiza-se os dados estruturados com origem nas funcionalidades do
ERP. A partir do momento em que uma aplicação de BI se concretiza isso
viabiliza a tarefa de acrescentar, também, dados externos, como descritos por
Garvin (2002), o que complementa a aplicação de BI e permite efetuar
comparações entre informações internas e externas à organização.
15
Figura 4 – Os níveis hierárquicos da informação
Fonte: Moresi (2000)
1.1 Dados e informações
É comum constatar-se que dados e informações são tratados,
muitas vezes, como sinônimos, porém não são, pois existem diferenças
conceituais entre eles. Dados são seqüências de fatos brutos sobre eventos
que ocorrem nas organizações antes de terem sido organizados e arranjados
de uma forma que possam ser entendidos e usados. Já a informação significa
16
dados apresentados em uma forma significativa e útil (LAUDON & LAUDON,
2007).
O’Brien (2004) define dado como fatos ou observações crus,
normalmente, sobre fenômenos físicos ou de negócios. Os dados são medidas
objetivas dos atributos (as características) de entidades (como pessoas,
lugares coisas e eventos). A informação, por sua vez, pode ser definida como
dados colocados em um contexto, o que lhe confere valor para usuários finais
específicos.
Para Stair e Reynolds (2008), dados são fatos básicos enquanto
informação é o conjunto de fatos organizados, de modo a terem valor adicional,
além do valor dos fatos propriamente ditos. O tipo de informação gerada
dependerá das relações entre os dados existentes, assim também como o seu
valor.
Existe um grande número de definições possíveis para a
informação, dependendo da abordagem que se queira dar. Dessa forma,
Moresi (2000) define a informação sob o ponto de vista de seu valor para uma
organização, em que, por este viés, é caracterizada por estruturas significantes
com a competência de gerar conhecimento no indivíduo e na sua organização.
Para exemplificar a diferença de conceitos entre dados e informações, pode-se
considerar uma transação comercial que costuma gerar muitos dados. Assim,
nomes, endereços, datas, quantidades, valores, produtos, local de venda e
vendedores, são dados que, quando tomados isoladamente, não dizem nada.
Para transformá-los em informação é preciso que sejam
manipulados, agrupados e classificados, conferindo-lhes um contexto, ou seja,
na linguagem da informática, eles devem ser processados. Assim, se um
gerente de vendas precisa saber o volume mensal de vendas de um
determinado produto por região terá que receber essa informação a partir do
processamento dos dados existentes. Neste trabalho, dados e informações são
utilizados de forma alternada, porém, respeitando-se a diferença conceitual
existente entre eles.
17
Os dados são transformados em informação, por meio de
modelos, pois um sistema de informação é um modelo. Dados podem se
transformar em informações que, por sua vez, se transformam em outras
informações e assim sucessivamente. Dessa forma, pode-se dizer que as
entradas de um sistema podem ser feitas tanto por dados, quanto por
informações.
Os dados podem ser classificados como formais ou estruturados
e informais ou não-estruturados. Os dados formais são aqueles com estrutura
definida previamente, cuja freqüência é conhecida, e correspondem a números,
datas, pequenos textos de tamanho fixo ou variável. Os antigos arquivos e os
bancos de dados relacionais são baseados, frequentemente, nos dados
estruturados. Segundo Pozzebon (1998), os dados informais, além de não
possuírem um formato previsível (textos longos sem estrutura definida,
imagens e áudio), não possuem também uma freqüência conhecida,
apresentam componentes tácitos e, muitas vezes, não são registrados.
Os dados e as informações podem ser classificados também
quanto à sua fonte: interna ou externa à organização. Os sistemas de
informação originalmente ofereciam apenas dados internos e estruturados, o
que vem dando lugar a sistemas cada vez mais flexíveis, que disponibilizam
informações de diferentes formatos e origens. Os dados e informações
externas sobre concorrentes, clientes, mercado, tecnologias, regulamentos e
tendências auxiliam as empresas a compreender o ambiente onde estão
inseridas, auxiliando-as no processo de tomada de decisões. A preocupação
com os dados e informações externas deve ser no sentido de que tenham
relevância estratégica para que possam contribuir para o processo de
inteligência de negócios da empresa. Segundo Garvin (2002), normalmente,
essas informações se concentram em dados publicamente disponíveis,
informações que podem ser coletadas diretamente (e legalmente) de indivíduos
e organizações. Os dados externos podem ser colhidos de três maneiras: por
meio da busca, da inquirição ou da observação.
18
Deve-se considerar também que os dados podem se classificados
como atuais ou históricos, pois um sistema de informação deve tratar também
de dados e informações históricos que são relevantes e críticos, pois são
cruciais para permitir diferentes abordagens dentro de uma organização,
principalmente, as que estudam a evolução de determinados fenômenos, que
somente podem ser compreendidos com análise de seu comportamento com o
passar do tempo.
O’Brien (2004) afirma que dados são mais do que mera matéria-
prima dos sistemas de informação, pois devem ser encarados como recursos
que precisam ser administrados para beneficiar os usuários finais de uma
organização. Os recursos de dados dos sistemas de informação podem ser
armazenados em:
• bancos de dados que guardam dados processados e organizados; e em
• bases de conhecimento que o guarda em uma multiplicidade de formas,
como fatos, regras e exemplos ilustrativos sobre práticas de negócios
bem-sucedidos.
Deve-se, também, ter atenção para as diferenças entre os termos
‘informação’ e ‘conhecimento’, que são utilizados, muitas vezes, como
sinônimos, embora seus conceitos sejam distintos. Nonaka e Takeuchi (1997)
fazem três observações para destacar as semelhanças e as diferenças entre
informação e conhecimento:
1. o conhecimento, ao contrário da informação, diz respeito a crenças e
compromissos, e é uma função de uma atitude, prospectiva ou intenção
específica;
2. o conhecimento, ao contrário da informação, está relacionado à ação
humana, sempre apresentando uma finalidade ou propósito;
3. o conhecimento, assim como a informação, diz respeito ao significado, é
relacional e específico ao contexto.
19
Se levarem-se em conta as estratégias baseadas em recursos, a
informação pode ser considerada um recurso estratégico como descrito por
Cronin (1990), para quem a informação é um recurso que pode ser explorado
com características semelhantes às de um produto, havendo uma preocupação
maior em relação ao seu uso mais eficiente e eficaz. Se a informação pode ser
considerada um recurso então ela também pode ser valorizada, o que não é
uma tarefa fácil. Segundo Cronin (1990), a informação é classificada em
relação ao seu valor em:
• Valor de uso – baseia-se no uso final que se faz da informação;
• Valor de troca – aquilo que o usuário está preparado para pagar, e que
pode variar de acordo com as leis de oferta e demanda;
• Valor de propriedade – que reflete o custo substitutivo de um bem em
particular;
• Valor de restrição – surge no caso de informação secreta ou de
interesse comercial.
É muito complicado definir o valor de uma informação por se tratar
de algo intangível e abstrato. Dessa forma, deve-se sempre levar em
consideração o contexto no qual essa informação será utilizada, e isso tem a
ver também com a qualidade da informação.
1.1.1 A qualidade dos dados e das informações
A construção de uma aplicação de Business Intelligence de
sucesso depende de componentes organizacionais e técnicos, em que os
dados representam os tijolos dessa construção. Assim, a qualidade dos dados
é um elemento de fundamental importância para o sucesso de uma aplicação
de BI. Para que dados e informações tenham validade e possam ser úteis para
uma organização é necessário que possuam três características ou atributos
20
fundamentais: tempo, conteúdo e forma, o Quadro 1 demonstra esses
atributos.
Informações importantes, que são obtidas tardiamente,
disponibilizadas em um formato inadequado ou inexato, além de não
contribuírem para o processo decisório, podem prejudicar uma organização ao
invés de ajudá-la. Em relação a essa questão, Davenport (2007) afirma que é
fundamental que uma empresa atente para a qualidade dos dados que são
inseridos no seu sistema de informação, pois dados inseridos por pessoas que
não têm a qualificação ou a atenção necessária podem causar danos em
algum momento para a organização.
Quadro 1 – Resumo dos atributos da qualidade da informação
Fonte: Adaptado de O’Brien (2004, p. 15)
Os problemas com a qualidade de dados e informações,
freqüentemente, têm origem nos sistemas de informação, pois a necessidade
de agrupar dados originários de diferentes sistemas, normalmente, causa
problemas de qualidade da informação. Nesse sentido, o sistema ERP contribui
muito para a qualidade da informação, particularmente, em relação às
Dimensão de Tempo
Prontidão,
Aceitação,
Freqüência,
Período
Dimensão do Conteúdo
Precisão,
Relevância,
Integridade,
Concisão,
Amplitude,
Desempenho
Dimensão de Forma
Clareza,
Detalhe,
Ordem,
Apresentação,
Mídia
A informação deve ser fornecida quando for necessária
A informação deve estar atualizada quando for fornecida
A informação deve ser fornecida tantas vezes quantas forem necessárias
A informação pode ser fornecida sobre períodos passados, presentes e futuros
A informação deve estar isenta de erros
A informação deve estar relacionada às necessidades de informação de um
receptor específico para uma situação específica
Toda a informação que for necessária deve ser fornecida
Apenas a informação que for necessária deve ser fornecida
A informação pode ter um alcance amplo ou estrito, ou um foco interno ou externo
A informação pode revelar desempenho pela mensuração das atividades concluídas,
progresso realizado ou recursos acumulados
A informação deve ser fornecida de uma forma que seja fácil de compreender
A informação deve ser fornecida em forma detalhada e resumida
A informação pode ser organizada em uma seqüência predeterminada
A informação pode ser apresentada em forma narrativa, numérica, gráfica ou outras
A informação pode ser fornecida na forma de documentos em papel impresso,
Monitores de vídeo ou outras mídias
21
dimensões de tempo e conteúdo. Sua base de dados disponibiliza informações
em tempo real, de forma consistente, padronizada, integrada e flexível para
que possa ser utilizada pelo BI. Vários problemas são causados quando não
existe um sistema ERP em uma organização para padronizar os dados, assim
não é difícil imaginar, por exemplo, os problemas que uma empresa pode
enfrentar quando necessita combinar informações de bases de dados
diferentes sobre um mesmo cliente, que possuam códigos diferentes
dependendo da origem da base de dados. A fonte dos dados será tão boa
quanto à execução dos processos de qualidade existente nos sistemas
transacionais.
Isso, normalmente, é uma das premissas em sistemas ERP, a de
que a origem dos dados sofra um processo de validação severo quando de sua
entrada no sistema e de seu processamento, além de que uma determinada
entidade deva ter sempre o mesmo código primário, por exemplo, um cliente
deve ter sempre o mesmo código, não importando o módulo dentro do ERP.
Um processo de qualidade de dados consistente, obrigatoriamente, incluirá
regras e verificações nos programas, e se esses processos não são realizados,
normalmente, ocorrerão falhas nos dados, não importando se o dado resida em
um banco de dados relacional ou num antigo arquivo VSAM (MOSS & ATRE,
2003).
A qualidade dos dados é o quesito técnico mais importante para o
sucesso do BI, apesar de não despertar tanto interesse nos usuários quanto
outros itens relacionados ao BI, como suas ferramentas, sua aparência ou a
performance de uma pesquisa. A responsabilidade pela qualidade dos dados é,
geralmente, vista como um problema de competência da área de TI, quando na
verdade é de responsabilidade das áreas de negócios que geram esses dados
e informações, e que devem procurar corrigi-las sempre que ocorrerem falhas.
As regras de negócio e políticas sobre a geração da informação
são estabelecidas pelas diversas áreas de uma empresa, sendo assim, são
diretamente responsáveis por sua qualidade. Essa é uma das mudanças de
22
comportamento que devem ser operadas em uma organização que usar a
informação e o conhecimento a seu favor.
Sobre a visão da importância dos dados pelas organizações, vale
citar Howson (2008), que realizou uma extensa pesquisa envolvendo empresas
de todos os tamanhos e continentes. De acordo com esta pesquisa, a
qualidade dos dados é apontada como o aspecto técnico mais importante para
o sucesso do BI. A figura 5 ilustra, por ordem de importância, os aspectos
técnicos citados na pesquisa.
Figura 5 – Importância dos aspectos técnicos para o sucesso do BI
2,13
2,68
2,79
2,84
3,02
3,05
3,18
3,30
0,00 1,00 2,00 3,00 4,00
Atualização próxima ao tempo real do Data warehouse
Incorporar o BI ao processo operacional
A melhora constante do sistema de BI (dados e ferramentas)
Velocidade no tempo de respostas das pesquisas
Ferramentas de BI apropriadas e eficiente
Disponibilidade de assuntos sobre temas relevantes
Confiabilidade no sistema de BI
Qualidade dos dados
4-Essencial 3-Muito importante 2-Importante 1-Não muito importante
Fonte: adaptado de Howson (2008, p. 100)
Uma empresa que pretenda implantar uma aplicação de BI,
porém enfrente problemas com a qualidade dos seus dados pode optar em
resolver essa situação de duas formas diferente: a primeira é solucionar seus
problemas de qualidade de dados e informações para somente após isso
pensar em implantar uma aplicação de BI ou pode fazer o oposto,
disponibilizando o aplicativo de BI e dessa forma expondo a desordem causada
pela baixa qualidade dos dados e informações e assim sensibilizar a
organização para as causas desse problema.
A resposta para a seleção da melhor opção não é simples, pois,
num primeiro momento, pode-se dizer que não há sentido em implantar uma
solução de BI sabendo-se que os dados e informações não têm consistência,
possuem erros, não são regidos pelas regras do negócio, não permitem o
23
relacionamento de informações com origens diferentes, entre outros
problemas. Porém, isso ocorre com muita freqüência, motivado por dois
motivos: o primeiro é que, normalmente, as empresas não dão muita
importância para a qualidade dos dados e não têm consciência das
conseqüências que esse comportamento pode trazer. Em segundo lugar,
muitas empresas pressionam as equipes de BI para que disponibilizem
transações o mais prontamente possível, sem dar muita atenção aos
problemas da qualidade dos dados. Para enfrentar esse desafio, Howson
(2008) sugere que as equipes de BI digam para os responsáveis pela
organização onde existem problemas com a qualidade dos dados e quais
problemas a empresa pode enfrentar se basear suas aplicações de BI nesses
dados. Devem também sugerir o que pode ser feito para resolvê-los e não
apenas reclamar sem propor soluções. Uma das mais importantes soluções
para esses problemas é a adoção de um sistema ERP para suportar os
processos operacionais da empresa.
Outro problema referente a dados e informações é relacionado ao
seu excesso, pois, freqüentemente, administradores e gerentes se vêem
inundados por quantidades absurdas de dados e informações que ao invés de
ajudar no processo decisório acabam na verdade por prejudicar a sua análise e
interpretação. Dessa forma, o grande desafio é o de conseguir distinguir, entre
as informações disponíveis, aquelas que são relevantes e geram conhecimento
daquelas que não têm interesse para o processo decisório. Saber distinguir
entre a informação que agrega valor daquela que não acrescenta nada é
fundamental para a economia de tempo e de recursos. Segundo Moresi (2000),
muitas empresas reconhecem o valor da informação e de sua importância e,
por esse motivo, deixam de ser sensíveis aos excessos na busca e na
manutenção da informação. Uma organização deve se esforçar para buscar e
manter informações que sejam importantes, críticas, mínimas e
representativas, evitando o desperdício de tempo e de recursos na busca e
manutenção de informações que não são interessantes para a organização.
24
Os Segundo Garvin (2002), mesmo que as organizações
pudessem fazer esse trabalho, de adquirir todas as informações essenciais
para o negócio, elas somente passam a ter sentido a partir de um processo de
interpretação por parte de gerente e diretores. Dessa forma, fatos em estado
bruto têm valor limitado, e devem ser classificados, agrupados ou colocados
em um contexto mais amplo, para que, dessa forma, possam ser interpretados,
sendo que a interpretação é entendida como o processo de traduzir esses
eventos, de desenvolver modelos de compreensão, de extrair significados
deles e de montar esquemas conceituais, enfim, de gerar conhecimento sobre
algo para que, dessa maneira, seja possível se tornar útil no processo
decisório.
1.2 O conhecimento
As reflexões sobre o significado do conhecimento são profundas,
e têm origem na Filosofia e permeiam todas as demais ciências. A
epistemologia ou teoria do conhecimento procura entender o que está por trás
do processo de obtenção do conhecimento. Dessa forma, conceituar o
conhecimento não é tarefa das mais fáceis.
Quando se estuda a origem do conhecimento depara-se com
duas grandes correntes filosóficas que tratam da natureza da origem do
conhecimento, que são, o ‘racionalismo’ e o ‘empirismo’, e seus principais
pensadores, a saber, Locke e Descartes, respectivamente. Essas duas
correntes surgiram nos séculos XVII e XVIII e influenciam os demais
pensadores sobre o conhecimento até os nossos dias.
Segundo o empirismo, a alma é como uma tábua rasa, desprovida
de idéias, e todo conhecimento surge das experiências que um indivíduo tem
em relação ao mundo que o rodeia, e que fomentam as idéias, sendo que
essas experiências se dividem em: a sensação e a reflexão. A sensação diz
25
respeito ao que se percebe de forma sensorial, e a reflexão é o processo
operado na mente, frente aos estímulos e que provê o entendimento de outra
série de idéias que não poderiam ser obtidas apenas das experiências
externas. Locke (apud ANDERY et al., 2004) faz, entretanto, a ressalva de que
o conhecimento só é real quando as idéias estão em conformidade com a
realidade das coisas. Dessa maneira, nem toda idéia é conhecimento e sua
veracidade depende, além da relação entre as idéias, da relação entre as
idéias e as coisas, origem do conhecimento científico.
No racionalismo, o conhecimento tem origem na utilização correta
da razão, por meio da utilização de recursos metodológicos, de forma a obter
idéias claras e evidentes. Descartes (apud ANDERY et al., 2004) utiliza a
dúvida como princípio para descobrir verdades e contornar falsas evidências
que os nossos sentidos podem proporcionar. Utiliza, ainda, a matemática como
procedimento metodológico, em virtude das certezas e evidências que ela
possibilita.
Segundo Andery et al. (2004), Descartes considera que a
observação e a experiência estão subordinadas à razão, na medida em que se
restringiam, praticamente, as funções comprobatórias. Assim, Descartes (apud
ANDERY et al., 2004, p. 204), enuncia quatro regras:
• na primeira, estabelece jamais acolher alguma coisa verdadeira
se não a reconhecer evidentemente como tal, sendo que
evidência é o que resiste a todas as provas da dúvida, aquilo que
tem clareza, certeza;
• na segunda, dividir as dificuldades em tantas parcelas quantas
possíveis para melhor resolvê-las;
• na terceira, a regra da síntese, “a de conduzir por ordem meus
pensamentos, começando pelos objetos mais simples e mais
fáceis de conhecer, para subir, pouco a pouco, como por
degraus, até o conhecimento dos mais compostos”.
26
• na quarta e última, o de fazer em toda parte enumerações tão
completas de forma a ter a certeza de nada omitir.
Ocorre que nem o empirismo nem o racionalismo ofereciam
respostas completas a todos os problemas que pretendiam resolver. A doutrina
empírico-racionalista, cujo maior representante é Kant (apud ANDERY et al.
2004), tenta conciliar as duas vertentes, afirmando que o conhecimento é fruto
da razão e da experimentação.
Para Kant, o conhecimento surge da experiência e da razão. É
por meio da experiência que o homem tem contato com a realidade e cria
conhecimento que, por sua vez, deve ser reconhecido universalmente como
válido e verdadeiro, com base na razão, que é o vetor que observa os meios e
condições do conhecimento. Assim, conceitos e intuições são necessários para
a formação do conhecimento, não tendo um, preponderância sobre o outro.
Pensamentos sem conteúdo são vazios, intuições sem conceitos
são cegas. Portanto, tanto é necessário tornar os conceitos
sensíveis [isto é, acrescentar-lhes o objeto na intuição] quanto
tornar as suas intuições compreensíveis [isto é, pô-las sob
conceitos] (
KANT, apud ANDERY et al. 2004, p. 347).
1.2.1 O conhecimento organizacional
Para o racionalismo, o conhecimento é adquirido por meio da
dedução. Já para o empirismo, o conhecimento é obtido pela indução.
Contudo, independentemente de sua conceituação, o conhecimento é centrado
no indivíduo. Assim, o estudo do conhecimento organizacional apresenta um
desafio, pois se o conhecimento se desenvolve nos indivíduos por meio de
processos de dedução racional ou de indução, é necessário saber como
transformá-lo em algo coletivo. Nonaka e Takeuchi (1997) respondem a essa
questão, ao afirmar que o conhecimento se inicia com o indivíduo (explícita e
tacitamente), dissemina-se pelo grupo, pela interação, até permear a
27
organização como um todo. Nonaka e Takeuchi (op. cit.) retomam a distinção
entre o conhecimento tácito e o explícito, explorada por Polanyi (1966),
segundo a qual o conhecimento tácito é pessoal, específico ao contexto e,
assim, difícil de ser formulado e comunicado. Já o conhecimento explícito ou
‘codificado’ se refere ao conhecimento transmissível em linguagem formal e
sistemática. Segundo os autores, o conhecimento é criado por meio da
interação entre o conhecimento tácito e o conhecimento explícito. Eles
postulam quatro modos diferentes de conversão do conhecimento –
socialização, externalização, combinação e internalização –, apresentados com
detalhes a seguir.
• A socialização é um processo de compartilhamento de experiências e, a
partir daí, da criação de conhecimento tácito, como modelos mentais ou
habilidades técnicas compartilhadas. Nela, ocorre a transferência de
conhecimento diretamente do outro sem que este seja explicitado, como
no caso de um aprendiz, que ao trabalhar com o seu mestre, aprende
sua arte sem necessariamente explicitar este conhecimento por meio da
linguagem, mas sim pela imitação e pela prática. A socialização
consiste, pois, no compartilhamento de experiências e de modelos
mentais.
• A externalização é um processo de articulação do conhecimento tácito
em conhecimento explícito. Para tanto, utiliza a metáfora, a analogia e o
modelo. Segundo os autores, ela é a chave para a criação do
conhecimento, pois cria conceitos novos e explícitos, a partir do
conhecimento tácito. O conhecimento é compartilhado pelo uso de
metáforas, analogias, conceitos, hipóteses ou modelos.
• A combinação é um processo de conversão do conhecimento explícito
em conhecimento explícito, em que os indivíduos o trocam e o
combinam, por meios documentais tais como: documentos, reuniões,
conversas ao telefone ou redes de comunicação computadorizadas.
28
• A internalização é um processo de incorporação do conhecimento
explícito no conhecimento tácito. Está intimamente relacionada ao
‘aprender fazendo’. Para que o conhecimento explícito se torne tácito é
necessária a verbalização e a diagramação do conhecimento, sob a
forma de documentos, manuais ou histórias orais.
A criação do conhecimento organizacional é um processo em
espiral, que começa no nível do individual e vai subindo, ampliando
comunidades de interação que cruzam fronteiras entre seções, departamentos,
divisões e organizações (NONAKA & TAKEUCHI, 1997, p.82).
Para os autores, a função das organizações no processo de
criação do conhecimento é o de fornecer o contexto apropriado para facilitação
das atividades em grupo e para criação e acúmulo de conhecimento em nível
individual. Krogh et al. (2001) faz afirmação semelhante ao definir que não se
gerencia o conhecimento e sim se criam condições para que ele possa ser
desenvolvido e compartilhado pela empresa. A criação do conhecimento deve
ser amparada por uma série de atividades que sejam capazes de criar
condições propícias para a sua ocorrência, as quais ele chamou de
capacitadores do conhecimento, em que entre os mais importantes estão:
1. instilar a visão do conhecimento – definir claramente a visão do
conhecimento que se deseja e o seu conteúdo;
2. gerenciar as conversas – já que elas proporcionam o compartilhamento
do conhecimento tácito dentro das empresas, o autor defende que elas
devam ocorrer obedecendo a certos princípios para que sejam
produtivas;
3. mobilizar os ativistas do conhecimento – são os personagens que ajudam
a promover o contexto capacitante adequado (espaço e os
relacionamentos essenciais que permitem a liberação do conhecimento
tácito);
29
4. criar o contexto adequado – envolve estruturas organizacionais que
fomentem relacionamentos sólidos e colaboração eficaz;
5. globalizar o conhecimento local – envolve a disseminação do
conhecimento, por meio dos níveis organizacionais.
Para Davenport e Prusak (2003), é interessante refletir sobre
alguns dos componentes básicos do conhecimento como forma de clarear a
visão sobre o tema. Para eles, os componentes básicos do conhecimento são:
a experiência, a verdade, o discernimento, normas práticas e valores e
crenças.
1. A experiência se refere àquilo que foi feito por um sujeito, e àquilo que
aconteceu ele no passado. A experiência proporciona uma perspectiva
histórica a partir da qual é possível entender novas situações e
reconhecer padrões familiares, o que permite uma inter-relação com
aquilo que está acontecendo de forma mais adequada.
2. A verdade fundamental é a experiência que possibilita a transformação
de idéias e conceitos em conhecimento daquilo que realmente acontece
na vida real, com toda a sua complexidade e sutilezas.
3. A complexidade: embora seja tentador buscar respostas simples para
situações complexas, o que geralmente ocorre nessas situações é que
se está ignorando fatores essenciais sobre o tema analisado, o que pode
levar ao erro. O conhecimento permite lidar com a complexidade de uma
maneira abrangente, ou seja, ele permite que tenha-se uma visão mais
ampla sobre determinado assunto, pois não foge à comparação, ao
questionamento e a certezas baseadas em fontes únicas de dados.
4. Discernimento: por meio do discernimento é possível julgar novas
situações à luz daquilo que já é conhecido, julgar a si mesmo e se
aprimorar em resposta a novas situações e informações.
30
5. As normas práticas e a intuição podem ser descritas como atalhos para
solução de problemas novos, baseados em problemas previamente
solucionados, ou seja, na experiência. Muitas vezes, esses atalhos são
percorridos tão rapidamente que não nos damos conta de que o fizemos.
É a chamada intuição, que nada tem de místico, mas que significa
apenas que se absorvem tão completamente os passos a serem dados
que se torna algo automático.
6. Os valores e crenças das pessoas exercem forte influência sobre o
conhecimento organizacional, e determinam à forma como se observa e
se reage a determinadas situações. Uma mesma situação observada por
diferentes pessoas pode ter significados completamente diferente,
dependendo de suas crenças e valores. O que para alguns pode parecer
uma situação de risco, para outros pode significar novas oportunidades,
dependendo como este indivíduo valoriza o risco e lida com mudanças.
Segundo Sveiby (1998), o conhecimento possui quatro
características: é tácito, é orientado para a ação, é sustentado por regras, e
está em constante mutação.
Para ele, o conhecimento é tácito, pois é pessoal e não
propriedade da organização, embora seja construído e transmitido socialmente,
confundindo-se com a experiência que o individuo tem da realidade.
O conhecimento é orientado para a ação, pois, freqüentemente,
geram-se novos conhecimentos, por meio da análise das impressões
sensoriais que são recebidas, perdendo-se os antigos. Confere-se sentido à
realidade, por meio de sua categorização em: métodos, sentimentos, valores e
habilidades, que podem ser utilizadas de forma válida. Essa ação é algo que
não pode ser reproduzida mediante um procedimento formal ou um sistema
artificial de inteligência, mediante ao fato de que essas associações de
conhecimentos são uma habilidade pessoal e intransferível, ou seja, cada
pessoa deve desenvolvê-la. Polanyi (1966) chama a isso de processo de
saber.
31
O conhecimento é sustentado por regras, que também têm um
componente tácito, pois surgem durante o processo de saber atrelado ao
resultado das ações como um padrão para a correção. As regras nos poupam
energia, pois funcionam como padrões que agem como regras inconscientes
de procedimentos, párea a todo tipo de situação concebível. As regras agem
como filtros para o conhecimento, por serem, em grande parte, adotadas de
forma automática e inconsciente, e por isso, podem ser limitadores frente a
novas situações que requerem uma nova abordagem.
O conhecimento está em constante mutação, e pode ser
apresentado por meio da linguagem, o que permite que seja distribuído,
criticado e, com isso, aumentado, apesar de que o conhecimento, quando é
explicitado, não expressa na totalidade aquilo que sabemos, portanto, não é
suficiente para torná-lo explícito.
Alavi e Leidner (2001) reuniram diferentes enfoques sobre
conhecimento, e cada qual permite que seja tratado de forma distinta. Sendo
assim, o conhecimento pode ser: (1) um estado da mente, (2) um objeto, (3)
um processo, (4) uma condição de acesso à informação, e, por último, (5) uma
capacidade. As perspectivas 2 e 4, que tratam o conhecimento como um objeto
que pode ser armazenado e manipulado, dão base à gestão do conhecimento
e, por não contemplar a amplitude do tema, talvez expliquem a incapacidade
de cumprir as promessas a que se propõe (Wilson, 2006). Já as demais
perspectivas enfocam o conhecimento, respectivamente, sob a óptica das
habilidades pessoais (1), da aplicação do expertise (3) e, por último, como uma
capacidade.
Assim, o conhecimento não é bem a capacidade para uma ação
específica e sim a capacidade para usar a informação aprendendo e testando
os resultados da habilidade de interpretar informações de forma a escolher
aquelas que dão suporte à tomada de decisão.
Segundo Moresi (2006), o conhecimento de uma organização
compreende as experiências de seus recursos humanos, as lições
32
apreendidas, seus manuais, entre outros. DAVENPORT e PRUSAK (2003, p.
6) propõem uma conceituação mais ampla do conhecimento organizacional,
em que o conhecimento é tido como
uma mistura fluida de experiência condensada, valores, informação
contextual e insight experimentado, a qual proporciona uma estrutura
para a avaliação e incorporação de novas experiências e informações.
Ele tem origem e é aplicado na mente dos conhecedores. Nas
organizações, ele costuma estar embutido não só nos documentos ou
repositórios, mas também em rotinas, processos, práticas e normas
organizacionais.
Stair e Reynolds (2008) afirmam que conhecimento é a
consciência e o entendimento de um conjunto de informações, e de formas de
torná-las úteis para apoiar uma tarefa específica ou tomar uma decisão. Esta
definição é a mais adequada para o contexto deste trabalho, pois traduz a
relação existente entre informação, conhecimento e tomada de decisão.
1.3 Modelos e conhecimento
De acordo com Stair e Reynolds (2008), um modelo pode ser
definido como uma abstração ou aproximação usada para representar a
realidade. Os modelos nos permitem explorar e melhor entender situações do
mundo real.
Segundo Michaud (2006), sobre a relação entre conhecimento e
modelos mentais, afirma que o conhecimento é o resultado de sua
receptividade mental para o que o circunda e envolve. Para tanto, os indivíduos
criam representações ou modelos mentais que os permitem dar sentido à
realidade e, dessa forma, poderem agir sobre ela. Os indivíduos utilizam os
modelos mentais, ou representações simplificadas da realidade, como
instrumento para compreender situações e ambientes, que servem como
mapas, permitindo aos indivíduos compreender o contexto, além da percepção
imediata, ou seja, permitem inferir situações que, num primeiro momento, não
33
são percebidas. O conhecimento não constitui uma cópia do real, mas um
processo de assimilação das estruturas cognitivas anteriores. O processo de
criação do conhecimento faz uso dessas estruturas cognitivas, tanto para
encontrar significados à sua ocorrência, quanto no momento em que é
necessário agir sobre o que interpreta e que é real. Conhecer, nesse sentido,
não é apenas a cópia do real, mas sim agir para transformá-lo.
Michaud (2006) sugere uma nova abordagem da percepção da
realidade para o conhecimento, decisão e ação, por meio de modelos.
Segundo esta abordagem, os modelos servem de instrumento para entender a
realidade e, dessa forma, gerar conhecimento, que, por sua vez, permite ao
indivíduo modelar uma realidade futura a ser alcançada. Dessa forma, o
conhecimento tem, fundamentalmente, dois objetivos:
1 – fazer entender partes de realidades diversas, tanto no domínio tácito,
quanto no explícito, com o objetivo da compreensão destas partes da
realidade;
2 – através da modelagem, construir alterações de partes das realidades
diversas, com o objetivo de alcançar uma nova realidade futura desejada.
Nesse sentido, o modelo serve para a tomada de decisão e ação. Um dos
exemplos desse tipo de modelo são as teorias.
A figura 6, mais adiante, ilustra a transformação de dados da
realidade em informação que, por sua vez, permite a criação do conhecimento
sobre esta realidade. De posse desse conhecimento, o observador cria em sua
mente uma nova realidade, e, por meio de comparação entre a realidade
existente, a realidade projetada toma novas decisões e ações. Todas essas
interações entre realidade existente e realidade projetada ocorrem por
modelos, sejam eles tácitos ou explícitos.
Essa recursividade entre dado, informação e conhecimento leva
alguns autores, como Tuomi (1999), a inverterem a clássica hierarquia, que diz
que dados geram informações que, por sua vez, geram conhecimentos. O
34
autor afirma que o conhecimento deve vir antes da informação, para que esta
possa ser formulada; e que a informação deve vir antes dos dados, para que
possam ser mensurados para formar a informação. Segundo o autor, dados
brutos não existem, posto que foram influenciados pelo processo de
conhecimento que conduziram a sua coleta e o seu processamento. Assim, é
possível somente fazer uso da informação, com base nas necessidades e
estoques de conhecimentos anteriores ao do conhecedor.
Figura 6 – Conhecimento, construção, criação e comparação
Fonte: adaptado de Michaud (2006, p. 222)
Na verdade, o autor afirma que para gerarmos dados é
necessário desfragmentar as informações, transformando-as em dados e
estruturas de dados para que seja possível processá-los em um sistema de
informação, ou seja, o que é arquivado em nossos computadores são
informações descontextualizadas. Ao recuperarmos essas informações uma
boa quantidade de conhecimento é recuperada. Segundo Tuomi (1999),
quando se elaboram sistemas de informação muito conhecimento contextual é
necessário, porém grande parte deste não é armazenado em arquivos de
Alteração
Realidade
Dados
Informações Conhecimento
Observador
Ficção
Construção
Criação
Alteração
Comparação
35
computadores, pois confia-se que quem ira utilizar aquele dado recuperando-o
como informação útil possui o conhecimento necessário para tal.
Michaud (2006) utiliza os quatro modos diferentes de conversão
do conhecimento definidos por Nonaka e Takeuchi (1997), para explicar como
os modelos de transformação fazem com que dados passem ao estágio de
informação. O autor divide os modelos de transformação em implícitos e
explícitos ou formais, como se observa a seguir.
• Os Modelos implícitos de transformação se estendem da fronteira
entre os modelos mentais perceptivos até os modelos racionais mais
complexos, de separação, ordenação, classificação e associação, até a
transformação das informações em conhecimento;
• Nos Modelos explícitos ou formais, o objetivo é o de dar uma ‘forma’
às informações, sejam elas construídas a partir de dados brutos, de
outras informações ou ainda de conhecimentos. Neles, encontram-se os
modelos teóricos, os matemáticos, os filosóficos, os cognitivos, os
organizacionais, os sociais, os políticos e muitos outros.
Para Alavi e Leidner (2001), a informação é convertida em
conhecimento quando é processada na mente dos indivíduos. Para elas,
conhecimento se torna informação quando é articulado e apresentado na forma
de textos, gráficos, palavras ou outras formas simbólicas. Segundo as autoras,
o conhecimento é informação personalizada, relacionada a fatos,
procedimentos, conceitos e julgamentos, ou seja, informação se transforma em
conhecimento quando ocorre um processo de combinação na mente do
indivíduo, visão que concorda com a de Michaud (2006).
As empresas lançam mão dos modelos, sejam eles implícitos ou
explícitos, durante o ciclo de vida de sistemas informatizados que dão suporte
à realidade de seus respectivos negócios. Segundo Rosemann (2003), os
36
modelos de processos fazem parte das quatro principais etapas do ciclo de
vida de um sistema, que são: a engenharia do negócio, a seleção de um
sistema, sua implementação na empresa; e o seu uso e manutenção. A
principal vantagem da utilização de modelos reside no fato de que eles
permitem que todos os envolvidos tenham a mesma visão sobre o problema e
compartilhem uma mesma terminologia. A figura 7 ilustra a transformação de
dados e informação em conhecimento através dos modelos.
Fonte: adaptado de Michaud (2006)
Os sistemas ERP podem ser considerados modelos
transformadores na medida em que convertem dados em informações úteis, o
que os habilita, pelo menos teoricamente, a suportar a criação de
conhecimento. Cabe ressaltar aqui a importância do preparo da empresa para
o uso da informação que sistemas como o ERP proporcionam na geração de
conhecimento, caso contrário o ERP não serviria para nada além de agilizar e
automatizar processos.
Dados
implícitos
Dados
explícitos
Informações
implícitos
Informações
explícitos
Externalização
Internalização
Coisas e fatos
Modelos de dados Modelos formais
Modelos mentais Modelos racionais
Conhecimento
implícito
Modelos conceituais
Socialização
Combinação
Combinação
Figura 7 – Dados e informação: os modelos em ação
37
A tecnologia da informação acelera atividades como o acréscimo
de uma série de linhas e colunas de números, mas uma empresa
se torna verdadeiramente voltada para o conhecimento quando se
conscientiza e se envolve no ‘nível mais profundo’, onde se busca
a informação por seu próprio valor intrínseco e não apenas para
automatizar e transmitir outras atividades.
(STEWART, 1998, p.
20).
1.4 Inteligência.
Existem muitas definições para a inteligência, assim como
existem muitas definições para o significado do conhecimento. No entanto, no
contexto empresarial, o significado da inteligência consiste na capacidade de
utilizar corretamente o conhecimento adquirido de forma a tomar decisões
estratégicas ou de negócios. Gerentes e diretores conscientes tomam decisões
baseadas em informações, e utilizam a experiência e a capacidade de análise
dos riscos e oportunidades para o entendimento mais amplo de uma
determinada situação.
Moresi (2000), afirma que o processo de transformação de
conhecimento em inteligência é realizado por meio de síntese, sendo esta uma
habilidade puramente humana baseada em experiência e intuição, que vai
muito além da capacidade de qualquer sistema especialista ou de inteligência
artificial. Síntese simplesmente não pode ser reduzida a procedimentos ou
regras, por não considerarem o complexo.
A definição de Moresi (2000) é mais abrangente e procura definir
o processo de inteligência de uma maneira global, que contribui muito para o
entendimento do conceito de inteligência. Porém, para o contexto das
organizações, a definição descrita por Wanderley (1999) é mais apropriada,
apesar de que, em sua definição, o conhecimento se mistura ao conceito de
inteligência. Para ele, a inteligência pode ser definida como o resultado que
começa com a coleta de dados. Esses dados são organizados e transformados
em informação, que depois de analisados e contextualizados, se transformam
38
em inteligência que, por sua vez, aplicada a processos de decisão, gera
vantagens competitivas para a organização.
Nesse contexto, a inteligência tem por objetivo monitorar o
ambiente tanto interno quanto externo, baseando-se na aquisição, avaliação e
produção de informação como forma de fornecer aos responsáveis pela
tomada de decisão os conhecimentos necessários para a compreensão do
ambiente e, dessa forma, ajustar as estratégias das organizações, minimizando
riscos e aproveitando oportunidades.
A utilização do processo de inteligência nas organizações se
originou na Inteligência Econômica e foi apropriado pelas grandes
organizações anglo-saxônicas, britânicas e, sobretudo, americanas nos anos
60, passando a se denominar Inteligência de Negócios, e, mais tarde,
Inteligência Competitiva. Assim, segundo Tarapanoff (2006), Inteligência
Competitiva é entendida como a busca de qualquer informação na ambiência,
de caráter científico, tecnológico, social ou político, sobre os seus competidores
e também clientes, fornecedores e parceiros, que possibilite melhor
posicionamento da organização na ambiência. Ela busca identificar e conhecer
aspectos que podem causar impacto nos pontos fortes e fracos da
organização, levantar o perfil dos concorrentes e, essencialmente, monitorar o
ambiente (interno e externo), com o objetivo de captar sinais de mudança.
Alguns autores, entretanto, afirmam que há uma distinção entre
Inteligência de Negócios e Inteligência Competitiva, sendo que Inteligência de
Negócios se refere à análise dos dados internos da organização, enquanto a
inteligência Competitiva se dedica à análise dos dados de mercado e da
concorrência.
Há, também, uma distinção a ser enfatizada, especialmente, no
contexto deste trabalho, que diz respeito às expressões Business Intelligence e
Inteligência de Negócios (pode se traduzir também como Inteligência
Empresarial). Apesar de em alguns casos a Inteligência de Negócios ser
realmente apenas a tradução para Business Intelligence, essas duas
39
expressões têm significados diferentes no Brasil. Matheus e Parreiras (2004)
afirmam que a Inteligência de Negócios busca entender os fatores e processos
humanos e organizacionais envolvidos na busca de informações,
principalmente, externa à organização e na posterior tomada de decisões. Já o
Business Intelligence se relaciona com a tecnologia da informação e tem por
objetivo criar aplicações que, baseadas em grandes volumes de dados, são
capazes de prover aos administradores e gerentes as melhores informações
para o processo de tomada de decisões, por meio de interfaces amigáveis que
facilitam o entendimento do relacionamento entre dados e informações. Assim,
no Brasil, o termo Inteligência Empresarial ou Inteligência de Negócios é mais
amplo e não é focada na tecnologia, mas no ser humano e nas organizações.
1.5 Tomada de decisão
1.5.1 O processo de tomada de decisão e de resolução de problemas
O objetivo principal de atuação de gerentes e diretores, dentro de
uma organização, é a sua capacidade de tomada de decisões com agilidade e
eficiência, de forma a conduzir a empresa em direção às metas estabelecidas.
Turban et al. (2007) definem a tomada de decisão como o processo de escolha
entre dois ou mais cursos de ação, com o objetivo de alcançar uma ou várias
metas.
O processo de tomada de decisão está relacionado à solução de
problemas, e, para Turban et al. (2007), um problema ocorre quando um
sistema não alcança as metas estabelecidas, não produz os resultados
previstos, ou não funciona como planejado. Muitas vezes, o que se imagina ser
um problema é apenas um sintoma do problema real. Isso ocorre, pois a
realidade é muito complexa e possui muitos fatores inter-relacionados, o que
dificulta a sua identificação.
40
A resolução de problemas pode lidar também com a identificação
de novas oportunidades. Uma maneira de diferenciar os termos ‘tomados de
decisão’ e ‘resolução de problema’ é examinar os estágios do processo de
tomada de decisão desenvolvidos por Herbert Simon (1960), que os apresenta
como: (a) informação, (b) concepção e (c) seleção. Posteriormente, foi
acrescentada o estágio de (d) implementação e monitoramento. Todas esses
estágios serão apresentados com detalhes a seguir.
a) Estágio da informação
Nesse estágio, o ambiente é monitorado visando-se identificar
problemas ou oportunidades, informações relacionadas à causa, a abrangência
e o proprietário do problema. As restrições relativas ao ambiente e aos
recursos envolvidos são, também, investigadas. Turban et al. (2007) afirmam
que classificar os problemas pode ajudar a solucioná-los, pois, com a
classificação, o problema é catalogado em uma categoria, o que,
possivelmente, pode ajudar a encontrar uma solução padrão para problemas
do mesmo tipo.
Além disso, os problemas podem ser programados ou não
programados. Os programados são aqueles que ocorrem com uma freqüência
conhecida, são rotineiros e para os quais existem modelos padrões que já
foram definidos, como exemplo, a escala de funcionários que irá trabalhar no
final de semana. Já os problemas não programados são aleatórios e não
recorrentes, como exemplo, a elaboração de uma pesquisa ou o
desenvolvimento de um novo projeto.
b) Estágio da concepção
Neste estágio, o objetivo é procurar entender o problema e testar
soluções que sejam factíveis. Um modelo simplificado do problema com
poucos dados pode ajudar a definir a sua extensão, compreender a relação
41
entre as variáveis e facilitar o entendimento do problema. Os tomadores de
decisões podem também recorrer a modelos mentais para ajudar na solução
de problemas, especialmente, quando existe a pressão do tempo para a
solução de problemas urgentes. Esses modelos podem ser elaborados de
forma simplificada, o que facilita sua manipulação e acelera o processo de
entendimento do problema. Por outro lado, não se pode deixar de levar em
conta que quanto mais simplificado for o modelo, menor será sua
representatividade da situação real, o que pode levar à conclusões errôneas
acerca problema.
Após a construção do modelo, ele é validado para se ter certeza
de que representa a situação real, ainda que de forma simplificada. Em
seguida, por meio de critérios de escolhas, define-se qual será a abordagem
utilizada para a escolha da solução. Geralmente, o processo de modelagem
permite identificar soluções alternativas.
c) Estágio da seleção
O estágio de escolha é o mais crítico do processo decisório, pois
é nele que se decide entre as várias alternativas discutidas, e também onde as
partes se comprometem a seguir a escolha efetuada. Segundo Motta e
Vasconcelos (2002), a economia clássica se baseia em uma concepção
absoluta da racionalidade. Assim, parte do pressuposto de que o tomador de
decisões tem conhecimento absoluto de todas as opções disponíveis e que,
dessa forma, tem condições de escolher a solução ‘ótima’, de acordo com
critérios e objetivos por ele mesmo estabelecidos. Segundo Simon (1970), na
maioria das vezes, o tomador de decisões não tem acesso a todas as
informações disponíveis e nem conhecimento de todas as possibilidades de
ação possíveis. Desse modo, o tomador de decisões se contenta com um nível
satisfatório de informações que permite a identificação dos problemas e de
possíveis soluções. Agindo dessa forma, o tomador de decisões não busca o
42
modelo racional perfeito e sim aquele que apresente uma solução satisfatória e
razoável.
d) Estágio da implementação e monitoramento
Este estágio corresponde à implementação da alternativa de
solução escolhida e do monitoramento de seu sucesso, que resultará na
solução do problema. Caso isso não ocorra, será necessário retornar às fases
anteriores.
1.5.2 A qualidade das decisões
Segundo Matheson e Matheson (1998), as decisões de qualidade
possuem seis dimensões que correspondem a elos em uma cadeia, que estão
intimamente relacionados, em que o grau de qualidade da decisão corresponde
ao elo mais fraco da cadeia. Se uma decisão é boa em todas as dimensões,
exceto na estrutura, então ainda será uma decisão de baixa qualidade. Por
exemplo, criar alternativas novas e desafiadoras nunca garantirá o futuro da
empresa se o comprometimento não for alcançado. A figura 8 ilustra a cadeia
da qualidade da decisão, e cada dimensão corresponde a um elo da cadeia,
explicadas nas alíneas a seguir.
43
Figura 8 – Cadeia da qualidade da decisão
Fonte: adaptado de Matheson e Matheson (1998, p. 25)
• Dimensão 1 – Estrutura apropriada – é o contexto adequado para uma
decisão, formado após o entendimento da situação. É obtido por meio
da aplicação das seguintes questões: fizemos as perguntas corretas?
Os pressupostos estão claramente definidos? As diferentes áreas da
empresa foram ouvidas sobre esse assunto? As ações adotadas estão
alinhadas com a estratégia da empresa? A estrutura apropriada é sutil,
definida por questões, pressupostos, objetivos do negócio e pelas
pessoas envolvidas. A estrutura apropriada é a janela pela qual se olha
o problema, evita-se resolver problemas errados e, geralmente, é a que
leva às idéias inovadoras.
• Dimensão 2 – Alternativas criativas e factíveis – é a pré-condição
para qualquer decisão. Se não há alternativas não há decisão. Essa
dimensão exige que se recorra a alternativas desconhecidas. É
44
necessário verificar se todas as alternativas foram avaliadas, se existem
planos, no caso delas falharem, e se sua execução é factível.
• Dimensão 3 – Informação significativa e confiável – esta dimensão
necessita que a informação correta seja trazida para sustentar a
decisão. As empresas são especialistas em obter informações sobre o
que sabem, porém, nesse caso, o mais importante é obter informações
sobre aquilo que não sabe, para criar conhecimento.
• Dimensão 4 – Valores e trade-offs claros – são fundamentais para
estabelecer critérios e medir o valor das alternativas. A empresa deverá
avaliar, dentre as alternativas, aquela que trará melhor relação de risco e
retorno.
• Dimensão 5 – Pensamento lógico – essa dimensão requer que se
agrupem as informações obtidas, para que possa ser encontrada a
alternativa que ofereça o maior valor. Como normalmente as situações
reais são muito complicadas para se confiar apenas em intuição, é
aconselhável a elaboração de um modelo. Ao final da avaliação, o
resultado final é a elaboração de recomendações claras e
compreensíveis.
• Dimensão 6 – Comprometimento com a ação – o comprometimento
com a ação significa transformar as decisões em ações. Por melhor que
seja uma decisão, ela é inútil se não for implementada. A melhor
maneira de obter comprometimento com as ações é que as demais
dimensões tenham qualidade e que as pessoas certas estejam
envolvidas no processo decisório.
Após a tomada de decisões, é necessário avaliar se as medidas
adotadas estão surtindo o efeito desejado. Nesse sentido, Laudon e Laudon
(2007) sugerem a utilização de alguns critérios para identificar se o processo
de tomada de decisões ‘melhorou’, em que a utilização do critério mais
adequado depende de cada caso, das variáveis envolvidas e de critérios
45
pessoais. O quadro 2 demonstra algumas das dimensões da qualidade na
tomada de decisão que podem ser utilizadas para avaliar sua qualidade.
Quadro 2 – Qualidades de decisões e processos de decisão
Fonte: adaptado de Laudon e Laudon (2007, p. 307)
1.6 Sistemas de informação
A tomada de decisões, dentro de uma organização, decorre de
um processo de inteligência nos quais gerentes e diretores se baseiam no
conhecimento adquirido por meio da análise de dados e informações oriundas
de fontes internas e externas à organização. Porém, o volume de dados e
informações existentes em uma organização é grande e sua utilização é
impraticável se não se contar com sistemas de informação como uma primeira
etapa para viabilizar seu emprego no processo decisório. Sendo o ERP um
sistema de informação, é importante para o contexto do presente trabalho a
46
conceituação dos sistemas de informação, expor os objetivos a que se
propõem e analisar seus componentes.
Na visão de Laudon e Laudon (2007, p. 9), um sistema de
informação pode ser definido como
um conjunto de componentes inter-relacionados que coletam (ou
recuperam), processam, armazenam e distribuem informações
destinadas a apoiar a tomada de decisões, a coordenação e o
controle de uma organização. Além de dar apoio à tomada de
decisões, à coordenação e ao controle, esses sistemas também
auxiliam os gerentes e trabalhadores a analisar problemas,
visualizar assuntos complexos e criar novos produtos.
O’Brien (2004) define um sistema de informação como sendo um
conjunto organizado de pessoas, hardware, software, redes de comunicações e
recursos de dados, que coleta, transforma e dissemina informações em uma
organização.
Stair e Reynolds (2008) definem um sistema de informação como
um conjunto de componentes inter-relacionados que coletam, manipulam e
disseminam dados e informações, para proporcionar um mecanismo de
realimentação para se atingir um objetivo.
O objetivo de um sistema de informações é, pois, disponibilizar
informações de uma maneira tal que seja possível aos administradores analisar
assuntos complexos, entender problemas e tomar as decisões mais
adequadas. Os seus componentes principais são: entradas, processamento,
saídas e feedback, entendidos como:
• as entradas envolvem a captação de dados brutos dentro e fora da
organização;
• o processamento transforma esses dados em informações de forma a
dar sentidos a eles, por meio de um processo de organização, análise e
manipulação efetuada por cálculos, comparações, resumos e
classificações;
47
• as saídas correspondem à transferência dessas informações
processadas às pessoas que as devem utilizar. Essas saídas podem ser
apresentadas de formas variadas, tais como: relatórios, consultas
internas e Web, dados a serem enviados a outros sistemas, etc;
• a realimentação ou feedback corresponde às informações que, muitas
vezes, retornam como entradas para corrigir, complementar ou servir de
entrada para novos processamentos.
A figura 9 ilustra as funções de um sistema de informação.
Figura 9 – Funções de um sistema de informação
Fonte: Adaptado de Laudon e Laudon (2007, p.10)
Segundo Stair e Reynolds (2008), os componentes de um sistema
de informação são:
• hardware – consiste no equipamento físico usado para efetuar
atividades de entrada, processamento, saída e realimentação; podem
ser computadores de vários tipos e formatos; diferentes dispositivos de
entrada, saída e armazenagem; e o meio físico que interliga todos esses
elementos.;
• software – são os programas de computador, compostos por instruções
detalhadas pré-programadas que controlam os componentes de
hardware de um sistema de informação. Existem os softwares
chamados ‘Sistemas Operacionais’ que controlam quais recursos
48
computacionais serão utilizados para a execução de uma determinada
tarefa, sua freqüência e a prioridade de atividades e administração de
problemas. Existem, também, os softwares ‘aplicativos’ e as ‘linguagens
de programação’, que são utilizados pelos usuários para resolver ou
administrar uma tarefa específica;
• bases de dados – é uma coleção organizada de fatos e informações. É
o repositório onde os dados são armazenados e onde se administra o
acesso aos dados;
• telecomunicação é a transmissão eletrônica de sinais para
comunicações que permitem às organizações executar seus processos
e tarefas, por meio de redes eficazes de computadores. As redes são
utilizadas para conectar computadores em um edifício, em um país ou
pelo mundo, para permitir comunicações eletrônicas. Já a Internet é a
maior rede de computadores do mundo, composta de milhares de redes
interconectadas, as quais trocam informações;
• pessoas – são os elementos mais importantes de um sistema de
informações. Uma empresa é tão boa quanto as pessoas que a formam.
Assim, um sistema de informação será tão bom quanto as pessoas que
o desenvolveram e as que o utilizam para atingir os objetivos de uma
organização;
• procedimentos – incluem estratégias, políticas, métodos e regras para
a utilização de um sistema de informação.
Para entender melhor o papel de um sistema de informação em
uma organização e a sua importância, basta lembrar que antes dos sistemas
de informação serem computadorizados, o que ocorreu a partir dos anos 60, os
registros das informações das empresas e seu fluxo eram impressos. Pode-se
imaginar a complexidade desse trabalho e a mão de obra que isso demandava,
especialmente em empresas de grande porte ou multinacionais. A partir do
advento dos sistemas de informação, as empresas passaram a investir para
49
atender a alguns objetivos organizacionais. Segundo Laudon e Laudon (2007),
esses objetivos são os seguintes:
• atingir a excelência operacional (produtividade , eficiência, e agilidade);
• desenvolver novos produtos e serviços;
• estreitar o relacionamento com o cliente e atendê-lo melhor;
• melhorar a tomada de decisão (em termos de precisão e velocidade);
• promover a vantagem competitiva;
• assegurar a sobrevivência.
O’Brien (2004) sintetiza a definição dos objetivos dos sistemas de
informação em três papeis fundamentais para qualquer tipo de organização
conforme ilustra a figura 10 e que são os seguintes:
• suporte de seus processos e operações;
• suporte na tomada de decisões de seus funcionários e gerentes;
• suporte em suas estratégias em busca de vantagem competitiva.
50
Figura 10 – Os três principais papeis dos sistemas de informação
Fonte: Adaptado de O’Brien (2004, p.18)
Com o passar do tempo, os sistemas de informação foram se
especializando de forma a atender aos diferentes níveis hierárquicos da
organização, que necessitam de diferentes tipos de informação. É possível
encontrar na literatura nomenclaturas um pouco diferenciadas, mas que, de
maneira geral, possibilita a divisão dos sistemas de informação em dois grupos
principais, conforme classificação de O’Brien (2004): sistema de apoio às
operações e sistema de apoio gerencial, ambos apresentados a seguir.
1.6.1 Sistema de apoio às operações
O sistema de apoio às operações tem por objetivo tratar os
processos de negócios efetuados pela empresa, processar e armazenar os
dados gerados por essas transações, efetuar a comunicação dessas
informações e gerar produtos de informação destinados ao controle das
atividades que o sistema abrange. Dessa forma, objetiva oferecer suporte
operacional, com dados e informações que permitam monitorar as atividades
51
cotidianas e rotineiras da empresa. Normalmente, não oferece uma visão
global das ações e sim detalhada, o que não é tido como o ideal para o
processo decisório estratégico. Essa categoria pode ser subdividida em:
a) sistemas de apoio de processamento de transações (TPS –
Transaction Processing Systems), que processam dados
resultantes de transações empresariais, atualizam bancos de
dados e produzem documentos empresariais, e podem processar
as transações em lotes ou em tempo real. Exemplos: sistema de
vendas, suprimentos e sistema de contabilidade;
b) sistemas de controle de processos, que monitoram e controlam
processos industriais. Exemplos: sistema de refino de petróleo,
sistema de produção de aço e de geração de energia;
c) sistemas colaborativos, que apóiam equipes, grupos de trabalho e
colaboração entre empresas. Exemplos: e-mail, chat e sistemas
de videoconferência.
1.6.2 Sistema de apoio gerencial
Tem por objetivo fornecer aos administradores e gerentes
informações para o processo de tomada de decisões para a administração da
empresa. Podem, também, ser subdivididos em categorias, dependendo da
necessidade e do nível hierárquico para o qual a informação se destina. Assim
tem-se:
a) sistemas de informação gerencial (MIS – Managment Information
System), que fornecem informações de caráter gerencial em
formatos pré-definidos, gerados com dados e informações do
sistema de processamento de transações para solução de
problemas com características mais estruturados, ou seja, mais
52
rotineiros, mais simples e conhecidos. Exemplos: análises de
vendas e relatórios de tendências de custos;
b) sistemas de apóio à decisão (DSS - Decision Support System),
que fornecem suporte interativo aos administradores e gerentes
no processo decisório para solução de problemas não
estruturados, ou seja, não tão freqüentes, complexos e únicos.
Enquanto o MIS auxilia o gerente a ‘fazer as coisas
corretamente’, o DDS auxilia o gerente a fazer ‘a coisa certa’.
Exemplos: sistemas de análise de risco e simulações de fluxo de
caixa. Segundo Stair e Reynolds (2008), os sistemas de apoio à
decisão possuem um conjunto de características específicas que
fazem deles ferramentas de apoio administrativo, que, de maneira
geral, apresentam as seguintes características:
• lidam com grandes volumes de dados, provenientes de diferentes
fontes;
• apresentam flexibilidade na elaboração e apresentação de
relatórios;
• oferecem apresentação das informações, tanto gráfica quanto
textual;
• permitem análises detalhadas;
• desempenham análises e comparações complexas e sofisticadas,
por meio de pacotes de software avançados;
• fornecem apoio a abordagens otimizadoras, satisfatórias e
heurísticas.
c) Sistemas de informação executiva (EIS - Executive Information
System) são sistemas de informação que combinam
características dos sistemas de informação gerencial e dos
sistemas de apóio à decisão, disponibilizando o acesso a
53
informações estratégicas de fácil visualização e manuseio,
adaptadas às necessidades de executivos e de outros
funcionários que tomam decisões. Exemplos: análises de
desempenho da empresa, ações dos concorrentes e
desenvolvimento econômico para apoio ao planejamento
estratégico.
A figura 11 ilustra a expansão dos papéis desempenhados pelos
sistemas de informação ao longo do tempo.
Figura 11 – Os papéis em expansão dos sistemas de informação
Fonte: adaptado de O’Brien (2004, p.20)
Existem, também, outras categorias de sistemas que podem dar
apoio tanto operacional quanto gerencial, Stair e Reynolds (2008) classificam
54
esses sistemas como sistemas de informação para negócios de uso especial, e
destacam, nessa categoria, a inteligência artificial, os sistemas especialistas e
os sistemas de realidade virtual. Apesar da importância desses sistemas dentro
da realidade de cada empresa, não serão abordados nesta dissertação, por
não serem pertinentes ao alcance dos objetivos estabelecidos neste trabalho.
Sendo assim, as atenções recaem, especificamente, nos sistemas de apoio de
processamento de transações, por ser tratar da finalidade principal dos
sistemas ERP e dos sistemas DSS devido ao Business Intelligence, que
engloba também os sistemas do tipo EIS.
As empresas que não contam com um sistema ERP, em muitos
casos, possuem vários sistemas de informação operacionais e de apoio
gerencial, que foram desenvolvidos ao longo do tempo para atender à empresa
ou que foram adquiridos como pacotes isolados. Esses sistemas, em muitos
casos, utilizam bases de dados diferentes e possuem estruturas internas de
dados diferentes. Para que se comuniquem de uma maneira minimamente
eficiente é necessário que se desenvolvam programas de interface que
resolvem alguns problemas e criam outros tantos, tais como a falta de
padronização entre códigos. Assim, em um determinado aplicativo, um cliente
pode ter uma determinada codificação e em outro aplicativo, pode ter uma
codificação diferente.
Dessa maneira, os programas de interface devem contar com as
tabelas ou arquivos de tradução, os famosos ‘de-para’, que caracterizam uma
fonte constante de inconsistências, visto que, uma vez que uma informação é
enviada para o outro sistema, este deve ter o código presente no ‘de-para’,
para que ela possa ser aceita, caso contrário, uma inconsistência será criada
até que seja resolvida. Esses sistemas isolados também criam re-trabalho,
pois, muitas vezes, quando não é possível a criação de uma interface para
exportar os dados, eles devem ser digitados novamente no outro sistema de
informação. Segundo Laudon e Laudon (2007), uma arquitetura de sistemas de
informações diferentes, operando em uma mesma empresa, pode ocasionar
dificuldades para a reunião das informações, como por exemplo, saber a
55
posição exata do estoque para atender a um pedido de vendas. Essa
fragmentação de dados em diversos sistemas separados pode prejudicar a
eficiência organizacional e o desempenho da empresa.
Com o ERP, a arquitetura de ‘colcha de retalhos’ é eliminada,
permitindo a empresa trabalhar baseada em um banco de dados integrado,
com padronização e consistência dos dados, o que faz com que todos da
organização passem a falar a mesma linguagem.
Segundo Davenport (2002), o ambiente de informação de estilo
‘Torre de Babel’ da maioria das grandes organizações, no qual uma palavra
tem os mais variados significados em partes diferentes de uma mesma
empresa, pode ser inteiramente superado mediante a pura e simples utilização
de um sistema de gestão empresarial, o que facilita o desenvolvimento de uma
aplicação de Business Intelligence.
Assim, neste capítulo, buscou-se conceituar os principais
elementos que compõem a estrutura básica dos sistemas de informação, tais
como dados, informações, modelos, conhecimento, inteligência, o processo de
decisão e sistemas. Estes elementos constituem a base dos sistemas ERP e
das aplicações de Business Intelligence e ajudam a compreender suas
operações e finalidades, que serão analisadas no próximo capítulo.
56
2 SISTEMA ERP E BUSINESS INTELLIGENCE
Este capítulo tem por objetivo apresentar um panorama dos
sistemas ERP, bem como do Business Intelligence. Juntas, estas duas
soluções se complementam e se potencializam, de forma a atender, com
informações, grande parte das necessidades de uma organização.
O ERP provocou, a partir de meados dos anos 90, uma revolução
silenciosa ao mudar a forma como as organizações se relacionavam com os
seus sistemas de informação, forçando-as a rever suas operações, seus
conceitos de armazenagem e distribuição das informações e preparando-as
para uma maior conectividade pela Internet. Com o advento dos sistemas ERP,
poupou-se muito dos esforços que as empresas eram obrigadas a aplicar para
criar, manter, adquirir e integrar uma série de módulos estanques, que
utilizavam plataformas tecnológicas diferentes. Nesse sentido, a ERP liberou a
empresa de uma série de atividades complexas que não tinham relação direta
com o seu negócio. Em contra partida, a relação das empresas com os
sistemas de informação convencional mudou, sendo que novas abordagens
são necessárias para que esses sistemas possam, enfim, cumprir sua
finalidade de forma integral.
Essa nova postura é necessária para lidar com as novas
habilidades que o ciclo de vida do sistema ERP exige das organizações, tais
como seleção de um sistema, sua implantação, suas customizações, sua
maturação e o uso do sistema ERP, como plataforma para outras soluções em
informática.
57
Ao adquirir um desses sistemas, as empresas percebem que sua
gestão necessita de novas habilidades que devem ser desenvolvidas para lidar
com os fornecedores, com o software, com os usuários, com os consultores, e
para explorar todas as possibilidades de recursos que o ERP pode oferecer. As
promessas para o futuro são muitas, como uma maior conectividade com a
Internet, com outros sistemas e uma maior terceirização de suporte no uso do
ERP. Segundo Haberkorn (2007), o ERP está se expandindo, com novas
funcionalidades, integrações, uso da Internet e maior suporte à decisão, tanto
que, segundo o autor, muitos já começaram a chamar a Tecnologia da
Informação de Tecnologia de Negócios.
Para melhor compreender esse cenário, apresenta-se,
primeiramente, neste capítulo, o histórico do ERP, sua abrangência, suas
vantagens e desvantagens, além de opiniões críticas sobre esses sistemas,
para, assim, criar um contraponto.
Na seqüência deste capítulo, apresenta-se, também, um perfil das
aplicações de Business Intelligence, seu conceito, sua abrangência, seus
componentes, suas funcionalidades e sua interação com o ERP. Enquanto o
sistema ERP prepara a infra-estrutura necessária para a efetiva integração da
empresa, em relação a seu sistema de informação, as aplicações de BI
permitem que se explorem essas informações e as transformem em
conhecimento, oferecendo, como conseqüência, apoio ao processo decisório.
No final do capítulo é apresentado, também, o modelo teórico
padrão que será utilizado para analisar as informações levantadas no estudo
de caso.
2.1 ERP – Enterprise Resource Planning.
Os sistemas ERP surgiram como sistemas de back-office,
efetuando o processamento das rotinas de retaguarda, que, quando falham,
58
podem deixar clientes insatisfeitos, fornecedores reticentes e auditores ou
representantes de organismos reguladores desconfiados. No entanto, mais
recentemente, eles foram, aos poucos, sendo utilizados na linha de frente dos
negócios, incorporando funcionalidades que antes eram tratadas como
sistemas complementares. Assim, passaram a dar suporte à cadeia de
suprimentos, ao relacionamento com os clientes, e à automação da força de
vendas. Davenport (2002), que prefere chamar os sistemas ERP de SGE
(Sistemas de Gestão Empresarial) ou ES, sigla em inglês para Enterprise
Systems, afirma que a Internet veio apagar, em grande parte, a distinção entre
retaguarda e linha de frente. Para ele, a Internet não é adequada para o
processamento da informação e sim para o acesso à informação, enquanto o
ERP é perfeito para o seu processamento. NORRIS et al. (2001, p. XXI) tem
discurso semelhante ao afirmar que
a tecnologia baseada na Web dá vida e fôlego à tecnologia do
ERP que é pesada, tecnologicamente difícil de implementar e que
nem sempre revela com facilidade o seu valor. Ao mesmo tempo,
o ERP permite que o e-business floresça totalmente, colocando
fatos reais por trás das luminosas páginas da Web.
Assim, os sistemas ERP passaram a permitir a interligação entre
uma unidade e outra de uma empresa, ou de uma empresa com outra.
Segundo Davenport (2002), pela primeira vez desde a criação dos imensos
conglomerados de negócios, os administradores podem controlar as atividades
de suas empresas, praticamente, em tempo real, sem a necessidade de
aguardar os famosos relatórios de final de mês, que, em geral, eram conferidos
com outros relatórios, quase todos desatualizados.
Segundo o autor, a combinação de sistemas empresariais como
plataforma primária para as informações organizacionais com a tecnologia da
Internet para prover acesso a essas informações será o selo de qualidade das
organizações líderes no novo século. Vale lembrar que a maioria das
ferramentas de BI pode ser acessada via Web.
59
2.1.1 ERP: um breve histórico
Antes de apresentar o histórico dos sistemas ERP, faz-se
necessária a apresentação de seu conceito.
Segundo Souza e Saccol (2003), o ERP é um sistema de
informação adquirido na forma de pacotes comerciais de software, que
permitem a integração de dados dos sistemas de informação transacionais e
dos processos de negócios, ao longo de uma organização.
Segundo Norris et al. (2001), o ERP organiza, codifica e
padroniza os processos e dados de negócio de um grupo empresarial. O
software transforma dados transacionais em informação que pode ser
empregada pelas empresas para apoiar decisões de negócios.
Para Davenport (1998), o ERP é um software que promete a
integração das informações que fluem pela empresa. Esse sistema impõe sua
própria lógica à estratégia, à cultura e à organização da empresa. É uma
solução genérica que procura atender a todo tipo de empresa, e seu projeto
reflete uma série de hipóteses sobre como operam as organizações. O ERP é
desenvolvido para refletir as melhores práticas de negócio, sendo que a
decisão sobre a melhor prática é de responsabilidade do cliente.
Corrêa et al. (2001) enfatizam o apoio no processo de tomada de
decisão pretendida pelo ERP, que tem a pretensão de suportar todas as
necessidades de informação para a tomada de decisão gerencial de um
empreendimento como um todo.
Os sistemas ERP surgiram em decorrência da evolução dos
sistemas MRP (Material Resource Planning) e MRP II (Manufacturing Resource
Planning). O MRP surgiu na década de 1970 e foi criado para auxiliar grandes
empresas a planejarem suas necessidades de materiais (o que, quando e
quanto), a partir de demandas futuras, sejam eles comprados ou produzidos.
60
Já o MRP II surgiu como uma evolução do MRP, incluindo-se nele, além das
funcionalidades anteriores, as decisões de como produzir.
Na verdade, o MRP II é mais do que apenas o MRP com cálculo
de capacidade. Há uma lógica estruturada de planejamento
implícita no uso do MRP II, que prevê uma seqüência hierárquica
de cálculos, verificações e decisões, visando chegar a um plano
de produção que seja viável, tanto em termos de disponibilidade
de materiais como de capacidade produtiva (CORRÊA et al.,
2001, p. 139).
A figura 12 ilustra as ondas da evolução do ERP a partir do início
dos anos 50, e descreve os principais componentes dessa evolução, conforme
legenda e textos a seguir.
Figura 12 – Evolução do ERP
Fonte: adaptado de Deloitte Consulting (1998)
61
Início dos anos 50: surge o sistema de controle de inventário,
desenhado para controlar os níveis de estoque e a sua localização.
Ganhou popularidade, e foi uma das primeiras aplicações de negócios
fora da área financeira e de contabilidade.
1950 – 1960: o primeiro sistema para manufatura – Materials
Requirements Planning (MRP) – foi desenvolvido. Este sistema ajudava
as empresas a planejar os seus pedidos de compras e manufatura de
produtos. Entretanto, o sistema era processado apenas em Mainframes,
o que os tornava difíceis de se gerenciar e de se manter.
1970 – 1980: os sistemas de MRP continuavam focados na manufatura
industrial, mas evoluíram para o MRP II – Manufacturing Resource
Planning. A integração com a área financeira permitia ao MRPII ser
usado como uma ferramenta de planejamento.
Meados dos anos 80: as melhorias no processo de manufatura, como o
Just-in-Time, combinado com a queda de preços do processamento de
dados, criaram ilhas de automação. Com os sistemas de controle de
produção e o mercado de automação, as fábricas puderam automatizar
o controle de produção e os de processos, colaborando, com isso, com
o crescimento acelerado do mercado de sistemas de automação.
Final de 1980 até 1990: com o desenvolvimento da tecnologia cliente-
servidor, o MRP II evoluiu para o Enterprise Resource Planning. O ERP
expandiu os limites do MRP II, para englobar outros recursos essenciais,
particularmente, os recursos humanos e financeiros.
Final de 1990: as empresas estavam focadas no uso do ERP, que,
nesse momento, já havia se tornado a escolha tecnológica que dava
sustentação para a criação e sustentação das vantagens competitivas.
Ao final desse período, tecnologias complementares, tais como a
otimização da cadeia de suprimentos e o gerenciamento do
62
relacionamento com o cliente, começaram a expandir as funcionalidades
dos sistemas integrados de gestão.
A partir do ano 2000: as empresas começaram a expandir seus
sistemas para fora de seus domínios, por meio de soluções de e-
business para se conectarem com clientes e fornecedores. Nos anos
seguintes, os ERP passaram a se tornar os facilitadores para o
crescimento das empresas, deixando de ser apenas sistemas de
controle de recursos e de custos.
Com o objetivo de ampliar a abrangência dos produtos vendidos,
os fornecedores de sistemas desenvolveram mais módulos, integrados aos
módulos de manufatura, mas com escopo que ultrapassava os limites da
manufatura. Por exemplo, foram criados os módulos de gerenciamento dos
recursos humanos, de vendas e distribuição, de finanças e controladoria, entre
outros. Esses sistemas, capazes de suportar as necessidades de informação
para todo o empreendimento, são denominados sistemas ERP, que
apresentam as seguintes características:
• são pacotes comerciais de software;
• incorporam modelos de processos de negócios (as chamadas
best practices);
• são sistemas de informação integrados e utilizam um banco
de dados corporativo;
• são modulares, com grande abrangência funcional;
• requerem procedimentos de ajuste, para que possam ser
utilizados em determinada empresa.
Os módulos citados na figura 13 estão presentes na maioria dos
sistemas ERP. Além deles, alguns sistemas ERP possuem módulos adicionais,
tais como gerenciamento de qualidade, gerenciamento de projetos,
gerenciamento de manutenção, entre outros.
63
Figura 13 – Estrutura típica de funcionamento de um sistema ERP
Fonte: Davenport (1998)
A implantação do ERP em uma organização interfere nos
processos organizacionais, culturais e de negócio. Quando uma empresa
decide pela aquisição de um sistema ERP, ela é forçada a rever seus
processos de negócios em, pelo menos, dois momentos críticos.
No primeiro momento, quando da seleção do ERP a ser adquirido,
ocorre um processo chamado de ‘análise de aderência’. Por meio dessa
análise, a empresa busca entre as opções disponíveis no mercado aquela que
melhor ‘adere’ às suas necessidades, com o menor grau de modificação do
sistema ou, como se diz comumente, sem a necessidade de ‘customizar’ o
ERP. Para fazer a análise de aderência, é necessário que a empresa efetue
um levantamento de seus principais processos de negócios, pois, de outra
forma, a análise fica baseada apenas nas experiências empíricas e naquilo que
os participantes da análise lembrarem, durante o processo.
64
O segundo momento ocorre após a aquisição do sistema, quando
os consultores do ERP, juntamente com a equipe de implantação da empresa,
efetuam o ‘mapeamento’ das operações das diversas áreas da empresa que
serão suportadas pelo ERP. Para tanto, é necessário estudar a funcionalidade
de cada processo, seu objetivo, suas integrações e utilidade. A necessidade de
observação de tais requisitos faz com que, caso forem ignorados ou sua
importância diminuída, os reflexos apareçam no decorrer do processo de
implantação ou logo após, como ressaltado por Ronamo (2001).
A figura 14 apresenta dados da pesquisa realizada por Martins
(2002), que procurou identificar o impacto nos processos empresariais com a
implantação do ERP. Oitenta por cento das empresas pesquisadas relataram
ter efetuado grandes mudanças nos processos operacionais razoáveis nos
processos estratégicos. A mesma pesquisa constatou que 60% das empresas
analisadas efetuaram mudanças nas estruturas organizacionais e tecnológicas.
Figura 14 – Mudança de gestão empresarial para implantação do ERP
60% 40%
20% 60% 20%
60% 40%
80% 20%
80% 20%
0% 20% 40% 60% 80% 100%
Intensidade
Organizacional
Pe ssoal
Tecnológico
Estratégico
Operacional
MUDANCA NOS PROCESSOS EMPRESARIAIS
grande razoável pequena
Fonte: Martins (2002, p. 80)
65
No início dos anos 90, quando os primeiros sistemas ERP
surgiram, as empresas, em sua grande maioria, processavam sistemas
desenvolvidos domesticamente. Ao final da década, impulsionado por uma
série de circunstâncias favoráveis, o ERP já tinha se tornado algo que tinha
vindo para ficar e não apenas um modismo. Segundo dados da pesquisa
realizada em 2007 pelo Comitê Gestor da Internet no Brasil (2008), os pacotes
de software ERP para integração de dados e processos em um sistema único
eram utilizados por 47% das empresas, percentual que aumentou em 30%, em
relação ao ano anterior.
Muitas consultorias transformaram o ERP em sua principal fonte
de negócios. Entre os fatores que deram grande impulso aos sistemas ERP,
pode-se citar o movimento de downsize, que no início dos anos 90 fez com que
muitas empresas abandonassem a plataforma ancorada nos mainframes,
impulsionadas por facilidades tecnológicas e por significantes reduções de
custo. Ao final do milênio, novo impulso foi dado para que as empresas
migrassem de seus antigos sistema, visto que o custo de atualizá-los, em
relação à aquisição de um ERP, não compensava o esforço. Somada a tudo
isso estava a possibilidade das empresas de centrar esforços em seus
respectivos negócios, ao invés de despender recursos em uma atividade meio.
Segundo Ross et al. (2003), os seis principais motivos alegados
para a adoção de um sistema ERP, são:
1. necessidade de uma plataforma única – uma das principais motivações
que levam uma empresa a adotar um sistema ERP é a possibilidade de
adoção de uma plataforma única que permite maior gerenciamento dos
recursos e flexibilidade para novos processos de negócio. Além dessas
vantagens, a plataforma única auxilia na geração de informações, visto
que o cruzamento de dados é facilitado;
2. melhoria dos processos – com a adoção do ERP, muitas empresas
esperam melhorar processos específicos, tais como a logística, o
planejamento e controle de produção ou os serviços prestados a seus
66
clientes. Muitos administradores, no entanto, entendem que o ERP
provocará uma melhora generalizada dos processos;
3. visibilidade dos dados – pode ser classificada, também, como
disponibilidade de acesso aos dados. Como o ERP é extremamente
integrado, ele oferece a possibilidade de fornecer informações
atualizadas, em tempo real para a tomada de decisões;
4. redução dos custos operacionais – a padronização da plataforma reduz
custos. Basta imaginar uma empresa que possui, além do seu sistema
legado, sistemas periféricos em plataformas distintas para atender
departamentos específicos de uma empresa, tais como recursos
humanos, ativo fixo, contabilidade, entre outros, cada qual com seu
repositório de dados e diferentes fornecedores;
5. melhor atendimento do cliente – demanda por respostas mais ágeis e
confiáveis, no que diz respeito ao atendimento ao cliente, tais como a sua
satisfação, posições dos estoques, tempo de entrega, precisão na
entrega, entre outras coisas mais;
6. melhora na tomada de decisões estratégicas – ocorre em decorrência de
uma maior disponibilidade de informações precisas, atualizadas e
disponíveis, o que dá apoio à tomada de decisões estratégicas com
maior embasamento.
Atualmente, o ERP é considerado, por muitos, uma commodity,
ou seja, está padronizado, e os diferentes produtos oferecem recursos
semelhantes. Segundo Haberkorn (2007), o diferencial está na implantação, na
capacitação, na usabilidade, no suporte, na documentação, na estabilidade, na
evolução de novas versões, na flexibilidade e na aderência à cultura de cada
país.
Os principais fornecedores desses sistemas no mundo são a
SAP, a Oracle e a Microsoft. No Brasil, destaca-se a Totvs, a maior empresa
67
latino-americana de software de gestão, fruto da fusão das empresas
Microsiga, Logocenter, Datasul e RM sistemas.
2.1.2 Ciclo de vida do ERP nas empresas
Os sistemas ERP possuem um ciclo de vida dentro das
organizações, que segundo Zwicker e Souza (2003), é constituído das
seguintes etapas: seleção, implementação, adaptação e utilização, descritos a
seguir.
Seleção: as empresas que optam pela adoção de um sistema
ERP têm que selecionar um fornecedor, considerando-se a adaptabilidade da
empresa ao ERP (aderência), a arquitetura técnica do produto, custo de
implementação, qualidade do suporte pós-venda, saúde financeira e visão de
futuro do fornecedor. Alguns autores dividem esta fase em outras duas fases, a
saber, decisão da adoção e aquisição.
Implementação é o processo pelo qual os módulos são colocados
em funcionamento na empresa. Esta etapa envolve a adaptação dos processos
de negócio ao sistema, eventuais customizações, carga dos dados legados,
configuração de hardware e software de suporte, treinamento dos usuários e
gestores e a disponibilidade de suporte e auxílio. Acrescenta-se, aqui, a esta
lista, a elaboração do protótipo, ferramenta fundamental para fixar o
conhecimento adquirido nos treinamentos, além de validar os processos e as
customizações realizadas, ao simular situações reais. Nesta etapa, as
discrepâncias entre a funcionalidade do pacote e os requisitos da empresa são
resolvidas, por meio de uma das quatro soluções possíveis: altera-se o ERP,
ou altera-se o processo, ou alteram-se ambos ou não se opta por conviver com
a discrepância gerenciando-a.
68
A adaptação do software à empresa pode ser efetuada de
diferentes maneiras, dependendo da situação e da necessidade. Entre elas
podem-se citar a parametrização, a customização, a adequação de lay-outs, a
adequação de regras de negócio.
Cabe aqui uma observação oportuna em relação às
customizações. Muitas vezes, um sistema ERP somente se torna atrativo para
uma organização mediante sua adequação aos seus requisitos. Normalmente,
isso ocorre quando o negócio da empresa tem particularidades não previstas
em pacotes comerciais, e, nesses casos, somente após ter-se esgotado todas
as possibilidades de adequação da empresa para se adaptar ao sistema é que
a customização é recomendada. Essa recomendação é importante, pois
quando se opta por customizar o sistema ERP, é necessário levar em
consideração o tempo e o custo que isso irá exigir para a empresa, visto que se
trata da adaptação de uma funcionalidade já existente ou de uma
funcionalidade nova em contrate com as funções do ERP já sedimentadas e
testadas em várias organizações.
A utilização é a etapa mais crítica, devido ao fato de que envolve
mudanças organizacionais que afetam as tarefas e responsabilidades dos
indivíduos e departamentos, e às transformações nas relações entre os
diversos departamentos. Zwicker e Souza (2003) fazem uma ressalva em
relação à necessidade do comprometimento e participação da alta direção da
empresa nessa fase, visto a complexidade e os conflitos que ela desperta, e
também que, em muitos casos, a gestão da mudança não leva em
consideração esses aspectos.
O ponto principal nessa fase é o do início da utilização efetiva do
sistema, quando diversos módulos interdependentes iniciam o seu
funcionamento simultaneamente, ou como é mais comumente chamado ‘BIG-
BANG’. A implementação é completada posteriormente com a entrada em
operação de outros módulos de apoio.
69
A entrada em operação do ERP e seu conseqüente
amadurecimento, em decorrência de sua utilização, permitem aos participantes
explorar as potencialidades do sistema, o que demanda novas necessidades,
realimentando a etapa de implementação. Manutenções também são
necessárias para adequar o sistema à legislação, e, por solicitação dos
usuários, para melhorias e correções, etc.
Esteves e Pastor (2001) acrescentam às fases já citadas, outra
fase, que é a da obsolescência. Não é rara, entre as empresas, a necessidade
da troca de um sistema ERP por outro. Isso ocorre por diversos motivos, entre
eles pode-se citar a obsolescência do sistema atual, frente ao crescimento da
empresa, à aquisição da empresa por uma maior que impõe o uso do ERP por
ela usado, à insolvência do fornecedor, entre outras coisas. A principal
preocupação nessa fase é a de preservar o histórico existente, por meio da
migração dos dados ou da manutenção do sistema anterior por um período de
tempo para consultas históricas.
De acordo com pesquisa realizada por Esteves e Pastor (2001),
que analisaram 189 artigos acadêmicos publicados em journals e conferências,
sobre o ciclo de vida de sistemas ERP, as pesquisas sobre o tema se
concentram, predominantemente, na fase de implementação, sendo que
apenas nove artigos se debruçam sobre o tema conhecimento organizacional.
Outro tema pouco abordado é o uso da modelagem de negócio na seleção e
implantação do ERP. A modelagem dos processos de negócio ou operacionais
podem ser importantes ferramentas para o mapeamento dos processos e apoio
nas diversas fases do ciclo de vida do ERP.
O projeto de adoção de um sistema ERP por uma empresa é um
projeto complexo que envolve muitas variáveis, portanto não surpreende que
um dos aspectos mais bem documentados na literatura são os chamados
‘Fatores Críticos de Sucesso’ ou FCS. Essa informação, para quem está
envolvido em um projeto desses, ajuda a minimizar os riscos e ensina lições
importantes derivadas de experiências realizadas por outras empresas.
70
Esteves e Pastor (2000) coletaram todas as FCSs citadas na
literatura e estabeleceram similaridades e padrões existentes, para, então,
elaborarem uma matriz reproduzida na quadro 3.
Quadro 3 – Fatores críticos de sucesso para implantação do ERP
Fonte: Esteves e Pastor (2000)
2.1.3 O ERP e as informações úteis para o processo decisório
Este estudo analisa os fatores de sucesso de aplicações de BI
baseados no ERP, pois considera-se que o ERP possui os dados necessários
ESTRATÉGICOS TÁCITOS
ORGANIZACIONAL
• Suporte gerencial contínuo.
• Gerenciamento de mudanças
organizacionais efetiva.
• Bom gerenciamento do
escopo do projeto.
• Composição adequada da
equipe do projeto.
• Reengenharia dos processos
de negócios.
• Definição adequada do papel
do líder do projeto.
• Confiança entre parceiros.
• Participação e envolvimento
do usuário.
• Versão adequada do ERP.
• Equipe e consultores
dedicados.
• Forte comunicação interna e
externa.
• Cronograma e plano de
projetos formalizados.
• Programa de treinamento
adequado.
• Redução de problemas.
• Uso apropriado dos
consultores.
• Fortalecimento dos
tomadores de decisão.
TECNOLÓGICO
• Estratégia adequada de
implementação do ERP.
• Evitar customização.
• Versão adequada do ERP.
• Configuração do software.
• Sistema legado.
71
que transformados em informações podem apoiar o processo decisório. Assim
é oportuno analisar as evidências de que o ERP efetivamente possui dados
relevantes e abrangentes sobre os processos de negócio da empresa que
possam suportar a tomada de decisão estratégica de uma organização que
opte por utilizar essa arquitetura de informação.
O ponto de partida dessa análise é que o ERP e a Internet são,
provavelmente, as duas mais importantes tecnologias de informação que
surgiram nos anos 90, cuja revolução que provocaram persiste e continua a
evoluir até nossos dias.
Sendo assim, explorar as possibilidades que o ERP pode oferecer
para o apoio ao processo de tomada de decisões estratégicas implica em
maximizar os benefícios obtidos com sua adoção, indo além dos óbvios
benefícios operacionais desses sistemas, o que é de interesse de todas as
empresas que utilizam o sistema ERP e que pretendem utilizar o conhecimento
que oferece como fator de vantagem competitiva. Trata-se de um recurso com
grande potencial e que precisa ser explorada de forma metodológica e
estruturada para que possa gerar frutos. Segundo pesquisa realizada em 2007
pelo Comitê Gestor da Internet no Brasil (2008), 47% das empresas no Brasil
utilizam o ERP, o que demonstra a abrangência da adoção dessa tecnologia
pelas empresas no Brasil.
Mesmo estando presente em uma parcela significativa de
empresas, pode-se questionar se o ERP possui os dados necessários que
quando processados podem se transformar em informações úteis e, assim,
contribuir para o processo de tomada de decisões estratégicas. Para tanto,
recorre-se à pesquisa realizada por Saccol et al. (2003) que avaliou o impacto
dos sistemas ERP sobre 10 variáveis estratégicas agrupadas em sete blocos,
em algumas das maiores e melhores empresas localizadas no Brasil. As
variáveis utilizadas foram definidas por Mahmood e Soon (1991) e adaptadas
por Sacool et al. (2003) à realidade brasileira. Os blocos de variáveis são os
seguintes:
72
1. clientes e consumidores – avalia a contribuição do ERP para o
relacionamento da empresa com clientes e consumidores;
2. rivalidade competitiva – analisa se o ERP contribui para uma investida
contra os competidores da empresa;
3. fornecedores – avalia se o ERP contribui como facilitador no
relacionamento com os fornecedores;
4. mercado – verifica como o ERP impacta a relação da empresa com o seu
mercado de maneira geral;
5. produção – analisa a contribuição do ERP em relação à produção da
empresa, ao gerenciamento de custos e da capacidade produtiva;
6. eficiência e eficácia organizacional – avalia o impacto do ERP na
eficiência e eficácia organizacional, em especial, sua contribuição para a
gestão organizacional;
7. eficiência interorganizacional – avalia o impacto do ERP como facilitador
dos relacionamentos entre organizações, sejam elas outras unidades da
própria empresa ou outras empresas que a cercam.
Os resultados dessas pesquisas indicaram que o ERP oferece
poucas contribuições quanto às variáveis estratégicas clientes e consumidores,
rivalidade competitiva e mercado, porém impactam significativamente nas
variáveis: fornecedores, produção, eficácia organizacional e eficácia
interorganizacional. A questão de a pesquisa ter detectado pouca contribuição
em relação às variáveis relacionadas ao ambiente externo das empresas
(mercado, concorrentes, cliente/consumidores) é atribuída por Sacool et al.
(2003) ao fato de que é necessário o complemento do ERP com mais
funcionalidades para atender a essas variáveis, tais como: CRM, SCM, DW, BI
e KM ou seja, as funcionalidades que foram agregadas ao ERP na ‘Segunda
Onda’.
Quando se considera o ERP com funcionalidades expandidas,
esse quadro se altera. Essa constatação pode ser verificada por Santana
(2006), que realizou pesquisa semelhante à de Sacool et al. (2003),
envolvendo 20 empresas da Região Metropolitana de Curitiba, porém
73
considerando, também, as funcionalidades do CRM, SCM, DW, BI e KM.
Nessa situação, os resultados encontrados demonstraram haver impacto do
ERP sobre todas as variáveis estratégicas analisadas. Vale notar que Santana
(2006) considerou também as customizações realizadas nos sistemas de
gestão para atender às necessidades específicas de determinados clientes. Os
resultados constam da figura 15, em que se pode verificar que, ao contrário da
pesquisa de Sacool et al. (2003), as variáveis estratégicas clientes e
consumidores, rivalidade competitiva e mercado, também passam a ser
afetadas pelo ERP.
Figura 15 – O impacto do ERP sobre as variáveis estratégicas
9%
23%
29%
42%
48%
50%
62%
0% 10% 20% 30% 40% 50% 60% 70%
Competição
Mercado
Operações e custos
Fornecedores
Eficiência organizacional
Clientes
Efetividade
Fonte: Adaptado pelo autor a partir de Santana (2006, p.128)
As pesquisas de Sacool et al. (2003) e a de Santana (2006)
evidenciam que o ERP tem impacto sobre variáveis estratégicas. Desse modo,
se o ERP impacta essas variáveis, isso oferece um forte indício de que o ERP
possui dados e informações relevantes sobre essas variáveis e que, portanto,
podem ser processadas, transformando-se em informações úteis ao processo
de tomada de decisões estratégicas.
74
Quanto ao fato do uso de informações para o processo de tomada
de decisões, Davenport (2007) defende que a tomada de decisões deve ser
baseada na análise de informações, a chamada ‘Inteligência Analítica’. Para
ele, os CIOs (Chief Information Officer) devem se preocupar, primeiramente,
com a informação ao invés da tecnologia, pois a tecnologia funciona como um
veículo através do pelo qual a informação chega aos usuários. Isso não quer
dizer que a tecnologia deva ser abandonada, mas fazendo-se uma analogia
com o encanamento de água, CIOs focados em tecnologia estão mais
preocupados com canos e válvulas do que com a qualidade da água que jorra
desses canos. Para dar suporte a tal ambiente, Davenport (2007) defende o
uso do ERP pela quantidade de dados que gera, o data warehouse para reunir
os dados e o business intelligence para acesso e analise desses dados.
Então, é possível presumir que o sistema ERP possui
informações úteis sobre variáveis estratégicas que podem e devem ser
utilizadas no processo decisório estratégico e que, portanto, a utilização de
aplicações de BI pode, efetivamente, trazer essas informações presentes no
ERP para o âmbito do processo decisório, contribuindo com a tomada de
decisões, inclusive as estratégicas.
2.1.4 Vantagens e desvantagens do sistema ERP
Apesar dos sistemas ERP estarem consolidados como uma
solução eficiente, e de serem uma tecnologia amplamente difundida entre as
empresas, eles possuem uma série de vantagens às quais vale à pena
relacionar, para que seja possível ter uma visão mais abrangente de seus
benefícios, sem deixar de relacionar, porém, as suas desvantagens,
completando, assim, esse panorama.
Sacool (2003) analisou o discurso dos vendedores de pacotes
ERP e os comparou com resultados de pesquisas de vários autores. O
resultado está no quadro 4 que demonstra, lado a lado, as principais vantagens
e desvantagens na utilização do sistema ERP.
75
Quadro 4 – Principais vantagens e desvantagens dos sistemas ERP
Vantagens Desvantagens
Impõe a visão integrada dos processos
organizacionais. Cada setor passa a
compreender melhor o seu papel nas
operações da organização em sua totalidade.
A utilização do ERP, por si só, não torna uma
empresa verdadeiramente integrada. O sucesso
da implantação de um sistema ERP dependerá
muito de seu histórico, cultura e clima interno.
Possibilita a criação de uma plataforma única
para a integração e a expansão da empresa,
interligando unidades organizacionais ou
subsidiárias em diferentes locais.
O sistema, muitas vezes, é imposto às diferentes
unidades organizacionais e subsidiárias, o que
aumenta a resistência à mudança.
Aumenta a importância atribuída à qualidade
dos dados inseridos no sistema, pela
independência entre processos.
Essa mudança exigirá outras, de ordem
comportamental e cultural, as quais nem todas as
empresas serão capazes de realizar.
Foco na atividade principal da empresa e na
atualização tecnológica permanente, por
conta do fornecedor do pacote.
Dependência do fornecedor do pacote, uma vez
que a empresa não domina essa tecnologia. Da
mesma forma, a empresa não controla os custos
e a velocidade de atualização da tecnologia.
Ganho de escala no uso do software. Abandonar antigos sistemas feitos sob medida de
acordo com as necessidades da organização e
ter que se ajustar ao pacote, que nem sempre
disponibiliza os dados e relatórios de acordo com
as necessidades específicas da empresa. Isso
envolve tempo muito grande de aprendizagem do
novo sistema e possibilidade de perda de alguns
recursos importantes.
Adoção de padrões de negócios e de dados,
baseados em boas práticas utilizadas por
outras empresas.
O redesenho de processos e padrões impostos
pelo sistema podem gerar perda de práticas
específicas da empresa que ofereciam bons
resultados, gerando a perda de motivação
interna. A adoção das best practices aumenta o
grau de imitação e padronização entre as
empresas de um segmento.
A solução de sistema de informações para
processos internos pode ser única em toda a
organização, evitando a existência de vários
sistemas isolados.
Qualquer dado que seja incorretamente
registrado no sistema (exemplo: pedido de venda)
repercutirá em todos os demais processos que
vêm na seqüência; um módulo indisponível
afetará todos os demais. Se o sistema parar,
param todas as operações da empresa.
Informação, em tempo real, o que facilita o
processo de tomada de decisão.
A disponibilidade e o volume de informações no
sistema são grandes. Contudo, a geração de
relatórios gerenciais customizados não é um
processo fácil em boa parte dos pacotes hoje
disponíveis. É preciso a capacitação e tempo por
parte dos usuários para que se possa usufruir de
fato das possibilidades que o sistema oferece.
Redução de retrabalho e redundância de
dados; redução de custos com pessoal.
Cortes de pessoal, o que gera problema social.
Maior controle sobre as operações da
empresa; o sistema permite rastrear onde
ocorrem os erros e quem são os
responsáveis.
Excesso de controle sobre as pessoas, que
aumenta a resistência à mudança e pode gerar a
perda de motivação.
Fonte: Sacool (2003, p. 329)
76
Uma relação semelhante de vantagens e desvantagens foi
elaborada por Stair e Reynolds (2008), em que aparecem relacionados tópicos
já descritos por Sacool (2003), além de outros novos. Nessa relação constam
como vantagens:
• eliminação de sistemas legados, custosos e inflexíveis – a adoção do
sistema ERP permite que se eliminem muitos sistemas legados, por um
único conjunto integrado de aplicações. Muitos desses sistemas legados
têm décadas de existência. Sua manutenção é cara, as pessoas que os
elaboraram provavelmente já não estão mais na empresa, a
documentação é precária e sua adaptação às novas necessidades da
empresa é demorada. Esses sistemas acabam atrapalhando a
flexibilidade das empresas e sua competitividade, apesar de que alguns
benefícios dos sistemas legados podem oferecer algumas vantagens,
como citadas por Sacool (2003). Acredita-se que, na maioria dos casos,
nesse quesito, as vantagens superem as desvantagens;
• aperfeiçoamento dos processos de trabalho – os sistemas,
normalmente, estão em sintonia com as melhores práticas (best
practices) dos processos de negócios. Isso ocorre em decorrência de
levantamento realizado pelos fornecedores entre as empresas líderes,
descobertas de instituições de pesquisa e da vivência dos consultores;
• elevação no acesso aos dados para a tomada de decisões operacionais
– os dados integrados proporcionam excelente suporte à tomada de
decisões operacionais, o que possibilita às empresas fornecerem
serviços ampliados, maior suporte ao consumidor, e fortalecerem o
relacionamento com cliente e fornecedores, e, por fim, criarem
oportunidades de negócios;
• atualização da infra-estrutura de tecnologia – a implantação de um
sistema ERP oferece a oportunidade para a empresa atualize e
simplifique a tecnologia de informação da empresa. A padronização em
77
uma menor quantidade de tecnologias e fornecedores reduz os custos
com as manutenções contínuas e com suporte.
Como desvantagens, Stair e Reynolds (2008) destacam os
seguintes aspectos:
• despesas e tempo de implantação – obter todos os benefícios do ERP
não é simples nem automático, e sua implementação pode ser
demorada, difícil e cara. Quando ocorrem problemas em sua
implantação, as despesas podem ser altas e o tempo se estender;
• dificuldades na implementação de mudanças – algumas empresas
podem ter que rever os seus processos de trabalho de forma radical,
para se adaptar às melhores práticas de negócios trazidas com o ERP.
Isso pode causar situações de êxodo de funcionários, principalmente, os
mais antigos, o que leva a empresa à ficar carente de funcionários mais
experientes;
• dificuldades em integração com outros sistemas – o ERP não substitui
todos os sistemas que uma empresa pode utilizar. Assim, muitas delas
utilizam, juntamente com o ERP, outros sistemas com finalidades
específicas e que, em muitos casos, devem ser integrados ao ERP, e
isso pode representar um problema se a empresa enfrentar dificuldades
para efetuar essa integração;
• riscos de adotar apenas um fornecedor – os altos custos envolvidos na
adoção de um sistema ERP dificultam a troca de um fornecedor por
outro, caso a empresa não esteja inteiramente satisfeita com o sistema
ERP ou com o atendimento que lhe é oferecido. Por outro lado, os
fornecedores também sabem que pelos mesmos motivos possuem,
dessa forma, um ‘público cativo’, e isso pode representar menos
incentivo para ouvir os problemas de seus clientes. A dependência da
empresa em relação a um único fornecedor representa risco, pois este
pode deixar de atualizar o produto na velocidade necessária para a
78
empresa, ou o contrário, fazendo com que a empresa tenha que se
apressar na atualização de versões, sem necessidade. Além disso, o
fornecedor pode, também, quebrar ou deixar o negócio.
Deve-se considerar que as relações de vantagens e
desvantagens apresentadas por Saccol (2003) e Stair e Reynolds (2008) não
especificam o grau de relevância de cada item descrito, em relação aos outros.
Dessa maneira, alguns itens têm um impacto maior e são mais relevantes se
comparados com os demais.
2.1.5 ERP: principais tendências dessa revolução
Se compararem-se o sistema ERP da década passada com o
atual, ver-se-á que muitas das funcionalidades que existiam naquela época
persistem, porém ao invés de se tornar obsoleto, suas possibilidades e
recursos vêm se ampliando à medida que novas tecnologias e conceitos se
aprimoram. Após a fase de implementação do ERP, as empresas vão aos
poucos, explorando e entendendo as potencialidades e os benefícios desses
sistemas. Além disso, mudanças em suas respectivas áreas de negócio,
estratégias, novas tecnológicas e comportamentos do mercado pressionam as
empresas por maiores demandas de TI. A resposta a essas pressões, segundo
Ross et al. (2003), podem ser agrupadas em três categorias:
• integração com softwares de aplicação – visto que o ERP oferece
uma boa infra-estrutura, sendo que a tendência é cada vez mais
esses softwares se integrarem ao ERP, mesmo que vindo de
fornecedores diferentes;
• processo de integração interorganizacional – promover uma maior
integração entre parceiros de negócio, por meio novos protocolos
de comunicação;
79
• compartilhamento de serviços e de abastecimento – as redes de
comunicação e provedores de serviços estão barateando, de tal
forma, que não importa onde o fornecedor está locado, pois a
Internet vem a ser o veículo dessa transformação.
A figura 16 ilustra o ERP como parte do eixo central de negócios,
em uma arquitetura de integração e intercâmbio.
Figura 16 – Arquitetura possível, incluindo sistemas da empresa e de troca
Fonte: adaptado de Esteves e Pastor (2000)
Norris et al. (2001) classificam o ERP como uma tecnologia
evolutiva. Segundo os autores, esse tipo de tecnologia empurra para frente as
tecnologias anteriores de forma incremental. Pode-se, então, entender que o
ERP é uma tecnologia que agrega o novo, e que, por isso, vale à pena analisar
as atuais e futuras possibilidades desse sistema. Existe uma forte tendência
80
pela conectividade, e sendo o ERP a principal plataforma de TI de muitas
empresas, nada mais natural que evolua, incorporando novas funcionalidades
nessa direção. Comparada com a conectividade existente hoje, as promessas
de mudanças e as possibilidades são tão grandes que o ERP II já é realidade,
o passo seguinte na evolução dos sistemas de integração. Segundo Ross et.
al. (2003), o ERP II deve ser entendido como uma aplicação e implementação
de estratégia, que é construída sobre o ERP atual, mas que expande suas
funções para alcançar a integração sobre funções chave, tanto internas quanto
externas, em operações de colaboração, operacionais e financeiras.
A proposta de inovação do ERP II é de romper os limites
operacionais entre empresas, enfatizando o comércio colaborativo ou o e-
business. Para Norris et al. (2001), o e-business compreende três estágios: os
primeiros são pertinentes ao atendimento ao cliente; o seguinte, a atividades de
otimização da cadeia de valor, visando ao fornecimento de mais valor ao
cliente. Assim:
• o comércio eletrônico visa à execução de transações de compras
e vendas com um mínimo de perturbação da cultura
organizacional e nos processos de negócio. O comércio
eletrônico já é hoje uma realidade que permite visualizar o
catalogo eletrônico, efetuar a compra e o pagamento, além de
formas rudimentares de busca e contratação eletrônica de
suprimentos. Mesmo com a universalização da Internet, muitas
empresas ainda contam com o EDI (Eletronic Data Interchange),
para efetuarem o comércio eletrônico. No entanto, ocorre que o
EDI é uma tecnologia personalizada, ou seja, funciona como um
padrão de troca de dados padronizado entre duas empresas, e
não é generalizado;
• o e-business representa a busca por um melhor desempenho do
negócio, por meio do uso de tecnologias eletrônicas, enquanto o
comércio eletrônico procura a eficiência em vendas, marketing e
81
compras. O e-business é focalizado na eficácia, através de
melhorias nos serviços ao consumidor, custos reduzidos e
processos de negócio otimizados. Um exemplo dessa tecnologia
é SOA (Service Oriented Architecture). No SOA, o fluxo de dados
ocorre entre diversas empresas, para a efetivação de uma
transação que, por exemplo, pode envolver o vendedor, o
comprador, instituições financeiras e de análise de crédito. Isto é
possível devido a um novo formato de arquivo chamado de XML
(Extensible Mark-upLlanguage). O formato XML, ao contrário dos
antigos lay-outs de registros padronizados, abandona a
formalização de um registro, permitindo o envio de apenas os
dados que são necessários à transação desejada, já que cada
dado tem sua própria identificação;
• a parceria eletrônica se caracteriza como um relacionamento
estratégico focalizado sobre o cliente, dentro do qual as empresas
trabalham juntas para otimizar a cadeia de valor conjunta. O
objetivo da parceria eletrônica é permitir que clientes e
fornecedores possam interligar as suas operações de forma mais
transparentes, de maneira que um possa compartilhar
informações de projetos, planejamento e previsão. A Internet veio
baratear e viabilizar essas operações em larga escala, fazendo
com que a fronteira entre as empresas, no que diz respeito a
dados e informações, passe a ser menos nítida, abrindo um novo
leque de possibilidades de negócios.
Segundo Norris et al. (2001), as empresas tiram proveito de sua
capacidade de transmitir informações por meio da cadeia de valor. A
capacidade das empresas de recuperar e, então, atuar sobre essa informação
cria valor para os clientes. Uma empresa que utiliza o sistema ERP juntamente
com a Internet, tem uma configuração que combina as funções do ERP com o
front-end de compra e venda eletrônica, além de outros. Basicamente, a
empresa ficará com o perfil ilustrado na figura 17.
82
Figura 17 – Juntos ERP e tecnologia Web expandem um grupo empresarial
Fonte: adaptado pelo autor a partir de Norris et al. (2001, p. 28)
Essa arquitetura permite variações na integração entre sistemas ERP,
conforme os três modelos apresentados na figura 18.
O primeiro caso apresenta a cadeia de valor se conectada por
portal de terceiros que criam e gerenciam mercados. Podem também ser
mercados setoriais, organizados como leilões. No segundo modelo, a cadeia
de valor está conectada diretamente empresa a empresa, com o canal de
venda eletrônico de cada empresa ligado diretamente ao canal de compras da
empresa, imediatamente, acima no processo de produção. Para que esse
modelo funcione é necessário a emprego de normas setoriais e um padrão de
comunicação como o XML que facilite esse tipo de comunicação. No terceiro
modelo, os sistemas ERP de cada empresa se comunicam diretamente com o
sistema ERP de fornecedores e clientes, de forma similar ao EDI, porém com
padrões abertos de conexão. No entanto, somente a integração não basta. É
preciso coordenação, pois, à medida que a cadeia de valor cresce e passa a
integrar mais participantes, surge a necessidade da utilização de algoritmos
para otimizar a cadeia de suprimentos. O ERP de amanhã será focalizado na
integração de um grupo empresarial, expandido em rede, que focaliza a
integração e o crescimento de uma cadeia de suprimento de múltiplos grupos
empresariais (NORRIS et al., 2001, p. 28).
83
Figura 18 – Alternativas de integração do ERP no e-business
Fonte: adaptado pelo autor a partir de Norris et al. (2001, p. 29-30)
Vale mencionar que a adoção do ERP II não é apenas uma
questão de atualização da versão do sistema, mas vai além, e se a empresa
não estiver adequadamente preparada para essa conectividade, o que poderia
ser uma oportunidade perdida no ERP pode se transformar em risco no ERP II.
Ross et al. (2003) observa que é imprescindível a necessidade de uma revisão
dos processos internos no ERP por parte das empresas, antes que esta migre
para o ERP II. O treinamento falho ou insuficiente, a preparação dos usuários
para os novos papéis a serem desempenhados e um sistema inadequado de
remuneração que não motive a mudança, são falhas comuns aos projetos de
ERP. No ERP II tais falhas comprometem seriamente o sucesso, pois à medida
que se expande o numero de usuários e as transações pelas empresas, as
84
interdependências aumentam e muitas empresas são ameaçadas por qualquer
falha ao não gerenciar adequadamente a mudança para o ERP II.
Sem dúvida, o ERP II vem sendo lentamente adotado para
atender às demandas cada vez mais necessárias de conectividade e
integração.
Outra tendência que envolve o ERP e a Internet diz respeito a
novas maneiras de prover e processar sistemas ERP, por meio de grandes
data centers. Segundo Haberkorn (2007), essas duas tendências
respectivamente denominadas de ASP (Appllication Service Provider) e BPO
(Business Process Outsoursing) remetem-se aos antigos padrões da época
dos Mainframes, pois, como naquela época, grandes data centers hospedam e
cuidam do processamento dos processos administrativos tais como RH,
contabilidade e financeiro, liberando as empresas para que cuidem de suas
atividades chave, de seus respectivos negócios. O acesso ocorre via Internet e
a cobrança é calculada sobre o tempo de uso e o volume de dados
armazenados, e o provedor se encarrega da segurança e de manter o sistema
atualizado. Essa tendência ainda esbarra em itens tais como segurança e
confiabilidade.
2.1.6 CRM – Customer Relationship Management
Segundo a Deloitte Consulting (1998), a adoção de um sistema
ERP funciona como a espinha dorsal (backbone) que permite que uma
empresa empregue tecnologias complementares, como o CRM. Muitos
fornecedores de ERP já possuem incorporados entre as funcionalidades do
ERP aplicações de CRM. O CRM trata do relacionamento da empresa com o
cliente, e essa funcionalidade agrega ao ERP um conjunto de informações,
expandindo a abrangência da base de dados corporativa, o que, por
conseqüência, melhora a base de conhecimentos para o Bunisess Intelligence.
85
Sendo assim, torna-se relevante entender um pouco melhor o seu objetivo e a
sua abrangência.
Segundo Kotler e Keller (2006), o CRM trata do gerenciamento
cuidadoso de informações detalhadas sobre cada cliente e de todos os ‘pontos
de contato’ com ele, a fim de maximizar sua fidelidade.
Com a utilização do CRM, a empresa pode reunir informações
sobre os clientes, sempre que ele entra em contato com a empresa, em
qualquer situação, por meio de qualquer departamento da empresa e por
múltiplos canais de comunicação, seja por uma venda efetuada, uma cobrança,
uma consulta solicitada ao serviço de atendimento a clientes (SAC), a
participação de treinamentos e cursos oferecidos pela empresa, campanhas de
marketing, atendimento realizado pela assistência técnica. Enfim, o objetivo é
coletar informações sobre o cliente em todas as situações em que ocorre o seu
relacionamento com a empresa.
O objetivo dessa base de dados é o de conhecer melhor os
hábitos e as preferências dos clientes e, assim, oferecer serviços e produtos,
além de realizar campanhas de Marketing mais eficientes. O sistema de CRM
permite que se estabeleça um relacionamento mais estreito com o cliente, de
maneira que possa atender a um grande número de clientes de forma
personalizada. Laudon e Laudon (2007, p. 54) enfatizam o enfoque dado ao
ganho de conhecimento que o sistema CRM propicia ao cliente e citam os seus
principais componentes, a saber:
os sistemas de CRM fornecem informações para coordenar todos
os processos de negócios que lidam com o cliente, em termos de
vendas, marketing e serviços. Seu objetivo é otimizar a receita, a
satisfação e a retenção de clientes. Essas informações ajudam as
empresas a identificar, atrair e reter os clientes mais lucrativos;
prestar serviços de melhor qualidade aos clientes atuais; e
aumentar as vendas.
O’Brien (2004) cita três componentes do sistema CRM: vendas,
marketing direto e satisfação, e atendimento e suporte ao consumidor,
descritos nos próximos itens.
86
• vendas – os sistemas de CRM acompanham os contatos com os
clientes e com as empresas, o que possibilita efetuar vendas cruzadas
ou oportunas. Por exemplo, o CRM pode ajudar a um vendedor de um
banco a identificar clientes que fazem grandes depósitos e, assim,
oferecer-lhes programas de crédito ou serviços de investimento;
• marketing direto e satisfação – o CRM pode automatizar tarefas como
qualificação de clientes, controle de reações, programa de contatos de
vendas, e fornecimento de informações para clientes e clientes
potenciais;
• atendimento e suporte ao consumidor – o CRM ajuda o serviço de
atendimento ao consumidor a criar, nomear e administrar pedidos de
serviços de forma rápida. O serviço de help desk pode, também,
fornecer informações de forma rápida sobre produtos ou serviços
adquiridos pelo cliente e que estejam apresentando problemas.
Corrêa e Caon (2002) ressaltam que clientes fiéis e retidos
aumentam, substancialmente, o potencial de lucro ao longo do tempo, pois, ao
se perder um cliente, não se está perdendo apenas a próxima transação e sim
todo um fluxo futuro de negócios que este cliente poderia trazer. Além disso,
um cliente insatisfeito tem um grande poder destruidor, maior do que o poder
construtivo de um cliente satisfeito. Assim, a melhor maneira de atender a um
cliente é reunir o maior volume possível de informações a seu respeito, de
forma a conhecê-lo melhor, compreendendo quais são as suas necessidades e
expectativas.
O CRM é uma ferramenta adequada a esse papel, pois permite o
gerenciamento das informações necessárias para um melhor relacionamento
com o cliente, permitindo estabelecer uma relação duradoura, de acordo com o
marketing de relacionamento. Para Kotler e Keller (2006), o marketing de
relacionamento tem como meta construir relacionamentos de longo prazo
mutuamente satisfatórios, com partes-chave (clientes, fornecedores,
distribuidores, e outros parceiros de marketing), a fim de conquistar ou manter
87
negócios com elas, o que constrói fortes ligações econômicas e sociais entre
as partes.
Uma empresa deve efetuar investimentos de recursos para
conquistar novos clientes e, assim, ampliar sua carteira, aumentando as
vendas; e obter lucratividade. Vencer esse desafio significa enfrentar uma série
de obstáculos, pois, hoje em dia, os clientes têm mais opções de produtos e
serviços, estão mais exigentes e menos dispostos a perdoar falhas e mau
atendimento. Entretanto, não basta fazer esforços no sentido de conquistar
novos clientes e não conseguir retê-los, perdendo logo à frente os clientes
arduamente conquistados. É preciso criar uma relação mais estreita com eles
para fidelizá-los.
Segundo Kotler e Keller (2006), existem duas maneiras de reter o
cliente: uma é erguendo barreiras que o impeçam de mudar, por exemplo, se
essa mudança significar custos adicionais ou perda de descontos; a segunda
maneira, considerada o melhor método, é o de entregar um alto grau de
satisfação aos clientes, pois isso torna mais difícil para a concorrência
ultrapassar as barreiras da mudança, pelo simples oferecimento de preços
mais baixos ou de incentivos. Com a fidelização dos clientes, é possível reduzir
consideravelmente os investimentos na busca por novos clientes. No entanto,
para que se alcancem os objetivos do CRM, não basta apenas o software, é
necessário contar também com pessoal preparado e com processos
estruturados, voltados para o atendimento ao cliente. Segundo Brown (2001),
as quatro principais estratégias dos aplicativos de CRM são:
• reconquistar – processo que consiste em convencer o cliente a ficar com
a empresa, em que se deve procurar pelas características que indicam o
início do processo de desligamento do cliente;
• busca por novos clientes – processo de prospecção, por meio de
segmentação, seletividade e fonte;
• fidelização – apoiada em três dispositivos: segmentação com base no
valor, nas necessidades do cliente e previsão de desistência;
88
• Cross-Selling (venda cruzada) / Up-Selling (venda a mais) – processo de
identificação de ofertas complementares e necessidades do cliente.
Segundo Laudon e Laudon (2007), o CRM pode ser analítico ou
operacional. O CRM operacional engloba as atividades voltadas para o cliente,
tais como ferramentas para automação da força de vendas, apoio ao
atendimento e ao call center e automação de marketing. O CRM analítico, por
sua vez, baseia-se em data warehouses que consolidam os dados coletados
pelo CRM operacional e os pontos de contato com o cliente, para que forneça
subsídios para gerenciar melhor o desempenho da empresa. A análise desses
dados tem por objetivo identificar padrões de compra, a fim de criar segmentos
para o marketing direcionado e diferenciar clientes lucrativos e dos não
lucrativos. O quadro 5 demonstra exemplos do CRM operacional versus o
analítico.
Quadro 5 – Exemplos de CRM analítico versus operacional
Fonte: adaptado de Laudon e Laudon (2007, p. 258)
CRM operacional CRM analítico
Gerenciamento de campanha Formular estratégias de segmentação de clientes
Marketing eletrônico Montar perfis de clientes
Gerenciamento de contatos e conta Analisar lucratividade do cliente
Gerenciamento de indicações Analisar lucratividade do produto
Telemarketing Identificar oportunidades de cross-seling e up-selling
Venda por telefone Selecionar as melhores estratégias de marketing,
serviços e canais de vendas para cada grupo de clientes
Venda eletrônica Identificar tendências na duração do ciclo de vendas, na
taxa de conquista e na dimensão média dos negócios
Venda de campo Analisar quanto tempo leva para o serviço ser prestado,
os níveis de atendimento segundo cada canal de
comunicação e a atividade de atendimento por linha de
produto e conta
Atendimento de campo Analisar indicações geradas e taxa de conversão
Atendimento ao cliente e help desk Analisar a produtividade dos representantes de
atendimento ao cliente e representantes de vendas
89
2.1.7 SCM – Supply Chain Management.
O sistema de gerenciamento da cadeia de suprimentos ou SCM é
uma evolução dos sistemas de compras, definido por Laudon e Laudon (2007),
como o sistema que auxilia fornecedores, empresas de compra, distribuidores
e empresas de logística a compartilharem informações sobre pedidos,
produção, níveis de estoque e entrega de produtos e serviços, de maneira que
se possam buscar insumos, produzir e entregar mercadorias e serviços com
eficiência. O objetivo principal é levar a quantidade certa de produtos da fonte
para o ponto de consumo, com o mínimo de dispêndio de tempo e menor custo
possível.
Os sistemas SCM são considerados sistemas
interorganizacionais, pois automatizam o fluxo de informações por meio das
fronteiras organizacionais, permitindo às empresas estabelecerem vínculos
eletrônicos com os consumidores e a terceirizarem o seu trabalho para outras
empresas.
Segundo O’Brien (2004), cadeia de suprimentos corresponde às
inter-relações com outras empresas, necessárias para a fabricação e venda de
um produto, compondo a rede de relações de uma empresa com outras.
Sistemas de e-business interfuncionais administram a cadeia de suprimentos,
reestruturando e agilizando os processos tradicionais. Um exemplo de cadeia
de suprimentos pode ser encontrado na relação entre uma montadora de
veículos e seus fornecedores. A montadora define a quantidade de veículos a
produzir e seus diversos modelos, e, em seguida, encomenda a entrega de
peças e equipamentos a seus fornecedores diretos, que, por sua vez, definem
o que vão produzir para atender às montadoras, e enviam para os seus
próprios fornecedores, os chamados ‘fornecedores de segunda camada’, as
necessidades de suprimentos. Juntos, montadora, fornecedores diretos e
fornecedores de segunda camada formam a cadeia de suprimentos.
O SCM ajuda as empresas a obter o máximo valor na compra e
na venda ao longo de todo o processo produtivo, atuando, assim, na margem
90
de contribuição dos produtos. Isso é possível, pois os métodos do SCM
permitem a adoção de parcerias com os fornecedores, a redução de estoques
por toda a cadeia de suprimentos, a revisão do sistema de distribuição, o
aprimoramento do sistema de informação e a melhoria da previsão de vendas,
entre outras coisas mais.
Para Laudon e Laudon (2007), as informações dos sistemas de
gerenciamento da cadeia de suprimentos ajudam as empresas a:
• decidir o que e quando produzir, estocar e transportar;
• comunicar pedidos rapidamente;
• acompanhar o andamento dos pedidos;
• verificar a disponibilidade de estoque e monitorar os níveis de estoque;
• reduzir custos de estoque, transporte e armazenamento;
• monitorar a expedição;
• planejar a produção, com base na demanda real;
• comunicar rapidamente mudanças no design de produtos.
Às práticas do SCM acrescenta-se o e-commerce, que é o
processo de compra e venda pela Internet, que, no caso do SCM mais
especificamente, trata-se do e-procurement. Segundo Zilber et al. (2006), o
objetivo do e-procurement é o de proporcionar às organizações a possibilidade
de reduzirem custos, pela automação dos processos de compra utilizando a
Internet. Sob essa perspectiva, os objetivos das empresas da cadeia de
suprimentos é o de entregar produtos no momento certo, na quantidade certa,
no local certo, com o melhor resultado possível. O e-procurement, em resumo,
é o processo de compras eletrônicas e inclui softwares, leilões, portais e
consórcios de compras. Seus objetivos são: a automatização de fluxos de
trabalho e a identificação de novas fontes e oportunidades para compras
através da Internet. Dentre as vantagens do e-procurement destacam-se:
• a redução de custos administrativos;
• a diminuição do tempo do ciclo do pedido;
91
• a diminuição dos níveis de estoque;
• a diminuição do preço de venda;
• o aumento da preparação das organizações para aumentar a
colaboração tecnológica e o planejamento entre parceiros de
negócios.
Por sua abrangência e possibilidades, era de se esperar que a
utilização do e-procurement estivesse mais disseminada do que está, mas,
para Zilber et al. (2006) existem uma série de problemas que explicam as
barreiras que o e-procurement enfrenta para a sua disseminação.
2.1.8 Conhecimento organizacional e ERP
Quando se fala da relação do conhecimento organizacional com o
ERP é importante ressaltar que a decisão da adoção de um sistema ERP é a
primeira etapa do ciclo de vida do sistema em uma organização, e, nesse
sentido, o conhecimento permeia todas as demais etapas até a sua
obsolescência e além dela. O conhecimento organizacional é parte integral e
associativa do sistema ERP, visto que ele reage e age sobre o mesmo
alterando-o de forma a assimilá-lo e, ao mesmo tempo, ao fazer isso, contribui
com sua evolução, acrescentando mais conhecimento na forma de novas
funcionalidades e experiência, à medida que se alastra pelo mundo corporativo.
Segundo Lee e Lee (2003), visto que o ERP encerra diversos
modelos de processos de negócio, quando esses processos são mapeados,
ocorre uma transferência de conhecimento, que tanto pode ser do sistema para
a empresa quanto vice-versa. Essa transferência de conhecimento afeta o
conhecimento organizacional e, portanto, cabe uma melhor análise de suas
implicações. Lee e Lee (op.cit) analisam, ainda, a transferência e o tipo de
conhecimentos que é transferido e, como isso, que pode ser transformado em
92
uma vantagem competitiva, quando processos padronizados de negócio são
implementados por uma organização.
Lee e Lee (2003) se valem dos conceitos de conhecimento tácito
e explícito, para descrever os dois tipos de conhecimento no contexto de
transferência e compartilhamento, e recorrem à análise de Brown e Duguid
(1991), para demonstrar como o mapeamento de processos de negócio explica
a transferência de conhecimento de forma tácita e explicita.
Brown e Duguid (1991) apresentam duas diferentes classificações
dos processos de negócios; os processos canônicos e o não-canônico.
Segundo os autores, os processos canônicos têm origem nas teorias da
administração científica, em que a organização é representada de forma
abstrata, e em que tarefas complexas são mapeadas em um conjunto de
simples etapas canônicas. Os processos não-canônicos são os processos
informais estabelecidos durante o relacionamento, a comunicação, e a
coordenação das práticas durante o trabalho. Assim, quando se fala em
transferência de conhecimento com o ERP, deve-se lembrar de dois tópicos
importantes: o primeiro é a transferência que ocorre do sistema para a
organização; o outro que não pode ser desprezado é o conhecimento e as
habilidades que os consultores transferem para a empresa em que o ERP está
sendo implantado, sendo que, em muitos casos, esse conhecimento supre a
falta de habilidades da equipe interna.
Sempre que se fala em geração do conhecimento, geralmente,
imagina-se estar associado a um novo produto ou serviço criado a partir de um
novo conhecimento adquirido. Isso é natural, pois a idéia da criação de um
novo conhecimento pressupõe inovação e, conseqüentemente, a idéia de algo
novo a ser oferecido à organização ou ao mercado. Ocorre, porém, que nem
sempre um novo conhecimento, necessariamente, gerará um novo produto ou
serviço. Novos conhecimentos, principalmente, aqueles oriundos de sistemas
de informação estão mais propensos a apoiar o processo decisório.
93
Segundo Rezende (2006), o conhecimento é uma derivação da
informação manipulada a partir de dados. A geração do conhecimento ocorre
quando as informações são comparadas, combinadas e analisadas por
pessoas, principalmente, quando utilizadas nos processos decisórios.
Muitas empresas não consideram os seus sistemas ERP como
algo capaz de gerar informações consistentes para a tomada de decisão e,
com isso, perdem a oportunidade de utilizar uma ferramenta que possibilita a
geração do conhecimento, pois não consideram a possibilidade de associá-lo a
aplicações de BI. Não que as empresas não as conheçam, mas por uma série
de motivos acabam descartando essa possibilidade.
Segundo Ludmer (2006), com o advento e a evolução dos
sistemas integrados de gestão, as implementações de sistemas de informação
precisam ser consideradas, predominantemente, organizacionais, mas sem o
uso convencional do conceito de organização. Muitas empresas estão tardando
em ver isso e não alocam recursos de nível para análise e gestão de aspectos
organizacionais. É preciso que o sistema de informação seja orientado para a
ação e não apenas para transações e controles. Essa recomendação é
fundamental para definir o escopo das áreas a serem abrangidas pelo ERP, e a
rapidez almejada de implantação de novos módulos e questões relacionadas
às características do produto e ao seu uso.
Segundo Perez-Montoro (2006), conhecimento é todo aquele
estado mental (ou seja, disposição mental concreta) que um sujeito possui,
causado por determinada informação, que permite a esse sujeito que tome
decisões adequadas e que realize ações concretas, resultantes dessas
decisões. Portanto, não basta apenas ter a informação, como bem ressaltou
Ludmer (2006), é preciso recursos de nível para que uma organização possa
extrair conhecimentos a partir de informações, ao combinar suas experiências
particulares.
Mesmo quando duas pessoas com formações semelhantes
acessam a mesma informação, o conhecimento que cada uma delas retira dela
94
é único. Quando alguém usa a informação para chegar a um objetivo de
negócios, esta pessoa está criando valor, ao colocar o seu próprio
conhecimento para trabalhar (DEGAGNE et al., 2003, p. 16).
Para Davenport e Prusak (2003), o conhecimento se desenvolve
ao longo do tempo, por meio da experiência, permitindo o reconhecimento de
padrões conhecidos em situações novas, o que possibilita respostas velozes e
apropriadas. No entanto, é preciso fazer uma distinção entre os indivíduos
genuinamente dotados de conhecimento daqueles que apenas oferecem
respostas prontas para qualquer pergunta nova. De acordo com os autores, as
pessoas dotadas de conhecimento evoluem por meio de tentativa e erro, no
decorrer de uma longa experiência e observação. Já para alguns experts, o
conhecimento é estático e sua reação a situações novas nada mais é do que a
repetição de velhas formas. Quando o conhecimento pára de evoluir, ele se
transforma numa opinião ou num dogma.
2.2 Business Intelligence
Possuir informações corretas, no momento e no formato
adequado, é o ideal para apoiar o processo decisório em qualquer empresa.
Porém, à medida que os sistemas de informação passaram a se popularizar e
se tornaram mais baratos e acessíveis, as empresas passaram a lidar com um
volume de dados e informações cada vez maiores, dificultando a sua utilização
para o processo gerencial.
Segundo McGee (2007), um gerente, em média, gasta duas horas
por dia procurando por informações, e metade dessas informações não terá
utilidade alguma para a finalidade de que precisa. São quantidades
inimagináveis de informações a que os administradores e gerentes têm acesso,
muito distante dos tradicionais relatórios que eram emitidos ao final de cada
mês pelos CPD’s (Cento de Processamento de Dados), contendo a relação das
95
operações realizadas pelos seus departamentos e ao final um resumo geral. O
desafio, hoje, para as organizações é transformar essas quantidades quase
que infinitas de dados e informações em algo útil e relevante. O primeiro passo
é organizar, classificar e armazenar esses dados e informações, de forma a
poder recuperá-los no momento oportuno. O segundo passo é o de
disponibilizar, por meio de soluções adequadas essas informações para melhor
capacitar a empresa no processo de tomada de decisão.
Ao encontro dessas necessidades, está o sistema ERP que tem
grande amplitude para coletar, organizar e armazenar vastas quantidades de
dados e informações, embora não disponibilize essas informações da maneira
mais adequada para o processo decisório gerencial e estratégico. Para isso
existe o Business Intelligence, que, se bem utilizado, ajuda administradores e
gerentes a manusear, interagir e tirar proveito desses volumes de dados e
informações, de maneira a criar conhecimento sobre determinados assuntos,
apoiando o processo decisório, criando, assim, vantagens competitivas. O
Business Intelligence deve estar alinhado aos negócios da empresa, e cada
aplicação desenvolvida deve ter como finalidade melhorar a performance da
empresa e dos negócios, ou seja, deve ter um propósito, caso contrário, não
deixará de ser apenas um experimento tecnológico, sem uma utilidade prática,
podendo ser abandonado logo em seguida.
As empresas coletam informações com o objetivo de avaliar o
ambiente de negócios. Geralmente, elas iniciam coletando informações
internas à organização e, posteriormente, completam essas informações com
informações externas, tais como pesquisas de marketing, industriais e de
mercado, além de análises competitivas. Dessa forma, as organizações
acumulam conhecimento e geram inteligência, o que permite a criação de
vantagens competitivas.
A seguir são descritos os principais componentes dos aplicativos
de BI, destacando-se, ao longo do texto, pontos importantes que contribuem
para o sucesso das aplicações de BI.
96
2.2.1 Definição do Business Intelligence
É fundamental definir que o Business Intelligence, não se trata
uma entidade única, monolítica, um produto, mas sim de uma reunião de
elementos, tais como: banco de dados, ferramentas de OLAP (On Line
Analytical Processing), data mining, além de conceitos de sistemas de suporte
a decisão, por esse motivo, neste trabalho foram denominados de: “aplicativos
de BI”.
Conforme Moss e Atre (2003), o BI não pode ser considerado
nem produto nem um sistema, mas uma arquitetura que combina um conjunto
integrado de aplicações operacionais, de suporte à decisão e banco de dados,
que permitem à empresa fácil acesso às informações relacionadas aos seus
negócios.
Para Tronto et al. (2003), o Business Intelligence (BI) surgiu para
apoiar as empresas no tratamento de grandes quantidades de dados e
informações.
O conceito de Business Intelligence consiste de uma vasta
categoria de tecnologias e programas aplicativos utilizados para
extrair, armazenar, analisar e transformar grandes volumes de
dados, produzindo um ambiente de conhecimento, onde há
produção sistemática de informação gerencial veloz e consistente,
capaz de auxiliar empresas a tomarem as melhores decisões nos
negócios, baseado em fatos reais, com profundidade suficiente
para descobrir as causas de uma tendência ou de um problema.
Barbieri (2001) conceitua Business Intelligence como a habilidade
de se estruturar, acessar e explorar informações, normalmente, guardadas em
DW/DM (Data Warehouses ou Data Marts), com o objetivo de desenvolver
percepções, entendimentos, conhecimentos, os quais podem produzir melhor
processo de tomada de decisão.
97
Haberkorn (2007) classifica o BI sob uma perspectiva que o ao
ERP. Dessa forma, ele define que o BI pode ser classificado como uma
evolução de todas as possibilidades de consultas que um ERP oferece.
Mais recentemente, o Business Intelligence (BI) tem sido
chamado de Business Analytics (BA), sendo que, segundo a Computerworld
(2008), as soluções de BA podem ser definidas como um conjunto de
ferramentas que simplificam a visualização e a análise de informações de
negócios que suportem a tomada de decisões, criando inclusive estimativas de
cenários futuros. É uma evolução do BI que passa a acrescentar ferramentas
de análise preditiva. Segundo Turban et al. (2007), é a aplicação de modelos
diretamente nos dados, envolvendo ferramentas de OLAP/DSS especialmente
modelos para apoio ao tomador de decisão. Para efeito deste trabalho, o termo
a ser empregado continua a ser Business Intelligence.
2.2.2 Arquitetura típica de uma aplicação de Business Intelligence
Segundo Howson (2008), os três principais componentes do BI
são:
1. ETL – (Extract, transform and load). A utilização do BI compreende,
geralmente, a análise de dados sumarizados de diferentes sistemas.
Para facilitar este trabalho, os dados devem ser extraídos de diferentes
sistemas transacionais transformados e carregados em um data
warehouse. O processo de transformação é o que demanda mais tempo,
principalmente, quando os dados têm origem em vários sistemas. O
processo de transformação compreende tarefas tais como, dados
inconsistentes, dados incompletos e associação de códigos em termos
compreensíveis, exemplos: 1- enviado, 2 – não enviado, Howson (2008).
2. Data Warehouse – é uma base de dados preparada em vários níveis de
detalhamento, obtida a partir dos sistemas estruturados, com o objetivo
98
de armazenar dados em vários graus de relacionamento e sumarização,
de forma a facilitar e agilizar os processos de tomada de decisões por
diferentes níveis gerenciais. Normalmente, não se utilizam diretamente
as bases de dados dos sistemas de informação, pois elas foram criadas
em necessidades direcionadas a aplicações independentes, e, assim,
não oferecem a visão consolidada de informações capaz de dar suporte
aos processos decisórios complexos (Barbieri, 2001).
3. Ferramentas de BI – existem vários tipos de ferramentas que são
utilizadas para diferentes finalidades dentro do BI. Barbieri (2001)
classifica os três tipos:
a. ferramentas de construção, que tem por objetivo auxiliar no
processo de extração dos dados de diversas fontes, transformar e
carregar esses dados nas estruturas finais de DW/DM. Essas
ferramentas realizam processos de ‘merges’ de fontes diferentes,
facilitando a busca em ambientes heterogêneos, a sua
transformação e sumarização para níveis de granularidade
desejados;
b. ferramentas de gerência têm por objetivo auxiliar o processo de
armazenamento e de utilização dos DW/DM e do Repositório,
onde residem as informações de metadados, responsáveis pela
definição das estruturas e dos processos de transformação
desejados. Informações sobre permissões de acesso também
estão armazenados no repositório/catálogo;
c. ferramentas de uso (front-end) são os mecanismos, por meio dos
quais os usuários manipulam os dados dos DW/DM e obtêm as
informações requeridas. Elas oferecem um arsenal de
operadores, tais como drill-down, up, cross, through, etc.
A figura 19 ilustra a arquitetura típica de uma aplicação de BI e o
relacionamento entre seus componentes.
99
Figura 19 – Arquitetura típica de uma aplicação de Business Intelligence
Fonte: Sell (2006, p.28)
2.2.3 ETL – Extrair, transformar e carregar dos dados
Segundo Moss e Atre (2003), a fase de planejamento e de
desenvolvimento do ETL é a mais complicada dentro de um projeto de BI,
sendo que o ponto inicial de qualquer aplicação de BI são os sistemas de
informação utilizados ou os sistemas transacionais que as empresas utilizam. É
comum se encontrar nas empresas dois cenários referentes aos sistemas
transacionais, em que, no primeiro, são utilizados vários sistemas que podem
ou não trocar informações entre si, por meio de programas de interligação (as
chamadas pontes). Além disso, alguns os sistemas utilizados pela empresa
podem ser em parte desenvolvidos internamente e em parte adquiridos no
mercado, como pacotes.
100
No segundo cenário, a empresa possui um sistema ERP que
processa, praticamente, todas as operações transacionais da organização. A
diferença principal entre esses dois cenários é que, com a adoção de um
sistema ERP, elimina-se uma série de problemas relacionados à qualidade dos
dados, tais como:
• padronização na formatação dos dados – dados similares possuem a
mesma formatação no sistema ERP, independentemente do módulo que
se está utilizando. Dessa forma, os campos de valor, códigos de
produtos, clientes, fornecedores, etc; têm a mesma formatação, o que
facilita a elaboração de queries que utilizem joins;
• eliminação de redundâncias – os dados referentes a um determinado
processo são alimentados uma única vez em um determinado ponto de
entrada, evitando-se, com isso, a redundância de informações similares
que são uma das principais fontes de inconsistências dos dados. Assim,
uma nota fiscal recebida em decorrência de uma compra é alimentada
no sistema de recebimento de materiais que distribui essa mesma
informação para outros módulos, tais como fiscal, contabilidade, estoque
e contas a pagar;
• consistência dos dados – no momento da entrada dos dados, eles são
consistidos para que atendam a todos os módulos que irão alimentar a
seguir, evitando, com isso, a existência de informações inconsistentes
ou incompletas;
• compartilhamento de cadastros – os cadastros no sistema ERP são
únicos e compartilhados entre os diversos módulos existentes. Desse
modo, o cadastro de um cliente é único e serve para todos os módulos
do ERP.
Howson (2008) lembra, porém, que apesar da grande maioria dos
dados que alimentam o DW terem origem nos sistemas transacionais, pode ser
necessário que uma parte dos dados tenha origem em outras fontes, tais como
101
dados fornecidos por parceiros, como por exemplo, por clientes e fornecedores;
informações de mercado e pesquisas externas; entre outras fontes.
2.2.3.1 Extração dos dados
O processo de extração dos dados consiste em acessar os
sistemas transacionais e outras fontes de dados e obter os dados requeridos,
de preferência, com o mínimo de processamento para que esse processo não
se torne lento e pesado. Moss e Atre (2003) advertem que é necessário tomar
cuidado com a extração de dados cujo arquivo ou banco de dados de origem
possua interdependência com outros arquivos ou banco de dados. Nesses
casos, é imprescindível entender essa inter-relação, pois pode ser necessário
levar em consideração o momento e a seqüência em que os programas de
extração devem ser processados para não afetar a qualidade dos dados.
Em relação ao que será extraído, uma das primeiras perguntas
que se faz quando do planejamento da extração dos dados, o ideal seria poder
extrair tudo, de todos os lugares e disponibilizar no DW, já que o usuário do BI
tem a característica de precisar de várias fontes de informações, agrupadas
das mais variadas formas e períodos. Howson (2008) afirma que isso é inviável
por uma série de motivos, tais como o tempo de processamento do ETL, alto
custo de armazenagem dos dados, queda do desempenho dos aplicativos de
BI, limitações de tempo, dinheiro e pessoas, o que obriga a priorizar o que deve
ou não ser enviado para o DW.
Para efetuar a extração é possível utilizar programas
desenvolvidos internamente ou ferramentas adquiridas no mercado. Segundo
Mantovani (2005), normalmente, as ferramentas adquiridas no mercado
possuem algumas limitações, pois, dificilmente, apenas uma reunirá todas as
funcionalidades necessárias para oferecer o suporte adequado aos processos
102
do ETL, devido à diversidade de arquiteturas existentes. Desse modo, é
necessário utilizar mais de uma para poder atender às necessidades de
extração dos dados.
Antes de serem carregados nas tabelas de destino do DW, os
dados alimentam uma área especial a que Moss e Atre (2003) chamam de área
de estadia, utilizada pelos programas de ETL. A fase de extração envolve
atividades de classificação dos dados, fusões e, até mesmo, alguns processos
de transformação que necessitam de muito espaço temporário ou até mesmo
espaço permanente que pode ocupar ou até superar o espaço ocupado pelos
dados originais. Por esse motivo, em alguns casos, é necessário utilizar um
servidor especialmente para o processo de ETL.
As transformações que ocorrem na fase de extração são
diferentes das que ocorrem na fase específica de transformação dentro do
ETL. Na fase de extração é interessante executar processos de reformatação
de dados, reconciliação e limpeza, pois isso ajuda muito a fase seguinte de
transformação, quando são efetuados processos de sumarização e agregação
dos dados.
2.2.3.2 Transformação dos dados
Os dados, por uma série de razões, precisam ser transformados
antes de serem carregados para o DW. Na fase de transformação, eles são
processados para que se moldem as necessidades de geração de
informações, o que ocorre por uma série de atividades, descrita com detalhes a
seguir, tais como limpeza, sumarização, derivação, agregação e integração.
• a limpeza dos dados ocorre tanto na fase de extração quanto na de
transformação. A diferença é que enquanto na fase de extração o que é
limpo está mais relacionado aos dados com problemas ou
inconsistentes, na de transformação a limpeza está relacionada a
103
problemas de consistência relacionada às regras do negócio. A limpeza
não significa, necessariamente, a eliminação dos antes da carga, e sim
a sua adequação às regras do negócio;
• sumarização – os valores e quantidades são sumarizados, associando-
os a diferentes níveis de agrupamento. Assim, sumarizam-se as vendas
por vendedor, gerente de vendas, região, filial, estado da federação,
país, etc;
• derivação – o processo de derivação significa a criação de novos dados
a partir dos dados existentes, que são o resultado de cálculos efetuados
com os dados existentes, ou a classificação de produtos, devido a uma
combinação diferente da existentes, etc;
• agregação – os dados relacionados a um determinado negócio podem
ter origem de fontes diferentes, sendo que o processo de agregação une
esses dados;
• Integração – o objetivo e transformar a partir de regras de
normalização, os dados com nomenclaturas e valores diferentes, porém
de mesmo conteúdo, em dados padronizados.
Moss e Atre (2003) alertam para a importância da participação de
usuários que conheçam bem as regras do negócio e que possuam poder de
decisão sobre elas, na fase do desenho e do desenvolvimento dos programas
de transformação, ou, caso se opte pela compra de uma ferramenta de ETL, da
escolha e da participação da implantação dessa ferramenta. Isso é importante,
pois poupa muito tempo nas fases de planejamento e desenvolvimento de uma
aplicação de BI e ajuda a alinhar o projeto à sua finalidade que é a de gerar
informações para a tomada de decisões.
Haberkorn (2007) alerta para a importância dos vários indicadores
que serão utilizados no BI, pois muita gente pensa apenas no indicador
‘faturamento’ e se esquecem de outros indicadores também muito comuns, tais
como custo das mercadorias vendidas, comissões de vendas, impostos. É
104
necessário, também, que se chegue a um consenso sobre o significado de
cada indicador. Assim, o significado de ‘custo de um produto’, apresentado no
BI, não pode ser entendido de uma forma por um departamento e de outra
forma por outro. Antes, o significado deve ser o mesmo para toda a empresa.
2.2.3.3 Carga dos dados
Moss e Atre (2003) dividem os dados a serem carregados em três
categorias:
1. carga inicial, que corresponde à carga que é realizada quando da
entrada em operação da aplicação do BI;
2. carga dos dados históricos, que pode ser considerado uma extensão
da carga inicial, porém diverge daquela em alguns aspectos: a
característica dos dados históricos é que eles são estáticos; além disso,
como são dados antigos, podem estar armazenados em arquivos e
tabelas cujo layout não é igual ao dados atuais correspondentes, o que
exige que sejam desenvolvidos programas específicos para a sua carga;
3. carga incremental, aquela que irá carregar os dados ativos. A
particularidade, nesse caso, é que é necessário prever que os dados
ativos podem ser novos, atualizados ou excluídos, e, portanto, é
necessário que sejam procedidos tratamentos diferentes para cada
processo. Exemplo: se um determinado dado é excluído no sistema de
origem, não necessariamente deverá ser excluído no DW, isso porque o
BI considera informações históricas, sendo que, nesse caso, o dado que
excluído do sistema de informação de origem não necessariamente terá
sua exclusão replicada na DW.
105
2.2.4 Data Warehouse
Segundo Inmon (2002) o data warehouse é uma coleção de
dados orientados por assuntos, integrada, não volátil e distribuída no tempo
para o apoio às decisões gerenciais. O data warehouse contém informações
granulares de toda a corporação.
Uma empresa que possua um sistema ERP, conta com uma base
de dados integrada e consistente da qual é possível extrair informações para o
processo decisório. De acordo com Howson (2008) é possível criar uma
aplicação de BI que utilize, diretamente, a base de dados operacional. Essa
pode ser uma estratégia interessante, como uma forma de iniciar a utilização
do BI em uma organização, caso a abordagem para a utilização do BI seja para
atender à necessidade de informações operacionais e não gerenciais e muito
menos estratégicas. Contudo é aconselhável que se crie um DW, quando a
empresa possui uma das características citadas abaixo:
• necessita utilizar análises cruzadas por assunto ou função, tal como
pedidos de produtos versus saldo em estoque disponível. Essas
informações podem estar disponíveis em dois sistemas transacionais
diferentes ou em módulos diferentes dentro de um sistema ERP. Desse
modo, com a criação de um DW, essas informações podem ser
combinadas, facilitando o seu acesso;
• quando as informações desejadas para uma análise ou para se obter
informações sumarizadas envolvam dados agrupados por data (mensal,
trimestral), ou alguma outra hierarquia (agrupados por grupos de
106
produtos). Normalmente, essas informações não se encontram prontas
na base transacional na hierarquia necessária para que possam ser
usadas prontamente pelo BI, e, se existirem, será necessário um
processamento de grandes volumes de dados para obter as informações
desejadas, o que, provavelmente, tornará a aplicação lenta e ‘pesada’;
• a empresa necessita de análises e relatórios consistentes, de forma
rápida, para um processo decisório que também é rápido. Os DW são
desenhados para esse propósito e, assim, permitem consultas (queries)
mais rápidas que as que são efetuadas diretamente no banco de dados
transacional.
A grande maioria dos bancos de dados transacionais tem seu
desenho baseado em uma filosofia que prioriza o tratamento das entradas de
dados e não de sua saída. Assim, é necessário tornar as entradas de dados o
mais eficiente possível, processando centenas de milhares de transações por
dia, evitando-se as redundâncias e inconsistências, por meio de um processo
de normalização dos dados. A normalização dos dados funciona para os
sistemas transacionais, porém, para o BI, ela pode dificultar as coisas, isso
porque acessar um banco de dados normalizado para obter uma determinada
informação pode significar ter que acessar um grande número de tabelas
relacionadas, o que compromete o desempenho da consulta. O quadro 6
demonstra uma comparação entre o banco de dados transacional e os DW/DM.
Há distinção entre o data warehouse e os data marts. Enquanto o
data warehouse é desenhado para atender as necessidades de informações de
toda a empresa, os data marts são subconjuntos de dados utilizados para
atender as necessidades de uma área específica. O que se deve evitar é a
criação de data marts independentes, cada um com seus processos de ETL.
Segundo Howson (2008), esse tipo de estrutura vem desaparecendo com o
tempo nas organizações, em detrimento dos data marts integrados.
107
Quadro 6 – Comparação entre o banco de dados transacional e o DW/DM.
Diferenças
Banco de dados transacional
Data Warehouse/Data Mart
Usuário Operacional Analítico decisório
Propósito Eliminar redundâncias, gerenciar
atualizações (updates) e repetir a
mesma operação muitas vezes todos
os dias.
O propósito principal é fornecer
acesso as informações para
gerenciamento do negócio.
Históricos Contem informações correntes e de
preferência poucas informações
históricas, pois esse volume de
dados degrada a performance do
banco de dados, assim são
freqüentes os processo de envio dos
dados históricos para back-ups que
quando necessários são
restaurados.
Grandes quantidades de
informações históricas para permitir
análises comparativas entre vários
períodos de tempo.
Normalização
dos dados
Alto grau de normalização dos dados
para evitar redundâncias,
inconsistências e manter a
integridade referencial.
Baixo grau de normalização, visto
que o objetivo é o acesso rápido a
um grande volume de informações,
o que pode significar redundâncias,
o que não significa que não haja
normalização em parte das tabelas.
Normalmente os dados
relacionados a uma determinada
aplicação são agrupados.
Atualização As informações são obtidas em
tempo real.
As atualizações não precisam ser
realizadas em tempo real,
normalmente elas ocorrem em
intervalos regulares (em questão de
horas, diariamente ou
semanalmente).
Nível de
detalhe
Contêm os dados no grau mais
detalhado possível. Contêm um
baixo nível de informações prontas
para uso.
As informações normalmente
encontram-se armazenadas
prontas para uso, os dados são
sumarizados em vários níveis de
detalhamento de acordo com as
aplicações que irão utilizar tais
informações.
Tempo de
resposta
As entradas e atualizações devem
ser rápidas, já as consultas
principalmente as muito elaboradas
tendem a demorar.
As consultas devem ser rápidas de
forma a acompanhar a urgência na
necessidade de informações.
Fonte: adaptado de Moss e Atre (2003, p. 194); Barbieri (2003, p. 47); e Howson (2008, p. 29)
Outro componente importante do DW são os metadados, que,
resumidamente, são os dados a respeito dos dados. Segundo Howson (2008),
os metadados descrevem informações tais como:
108
• quando os dados foram extraídos do sistema de origem;
• quando os dados foram carregados no data warehouse;
• de qual sistema de origem um determinado dado é originário;
• de qual tabela e de qual campo no sistema de origem o dado foi
extraído;
• definição de uma determinada regra de negócio, por exemplo: como
algo deve ser calculado: receita = ((valor unitário X quantidade vendida )
– descontos);
• o significado de um dado no contexto do negócio, exemplo: a receita é
baseada na quantidade vendida e não inclui as devoluções e as
inadimplências.
2.2.4.1 Data Warehouse – modelagem de dados
A figura 20 ilustra o modelo de dados ‘entidade relacionamento’
funciona para os sistemas transacionais que utilizam banco de dados
relacionais como o ERP, sendo que a rígida normalização dos dados e sua
distribuição por diversas tabelas são atributos fundamentais para a garantia da
funcionalidade e da integridade desses sistemas. Porém, esse modelo não é
adequado frente às características que definem a essência do Business
Intelligence, tais como velocidade no acesso, sumarização, redundância, visão
multidimensional, etc.. Para atender a essas peculiaridades, é necessária a
utilização de um modelo de dados multidimensional.
O modelo baseado na estrutura dimensional modifica a ordem de
distribuição de campos por entre as tabelas, permitindo uma formação
estrutural mais voltada para os vários pontos de entrada específicos (as
chamadas dimensões) e menos para os dados granulares em si (os chamados
fatos). Isso significa que numa estrutura dimensional os dados estarão numa
forma quase estelar, em que várias tabelas de entradas estarão se
109
relacionando com algumas (poucas) tabelas de informações, criando uma
notação mais sintética, legível e objetiva, Barbieri (2001).
Figura 20 – Exemplo de modelo de entidades e relacionamento
Fonte: adaptado de Barbieri (2001, p. 36)
O modelo dimensional é um dos componentes que fazem a
diferença entre um sistema de informação gerencial e o BI, pois permite ao
usuário contemplar a mesma informação sob aspectos diferentes a seu critério.
No caso de um sistema gerencial é necessário que se crie um relatório ou uma
consulta para cada maneira de se ver uma mesma informação, mas cujo foco
seja diferente. O modelo dimensional permite que a informação seja
armazenada já nesse formato.
Existem duas abordagens principais relacionadas ao modelo de
DW, as duas correntes têm muitas similaridades, porém diferem basicamente
na forma como os dados são armazenados. O modelo de Inmon (2002) dá
ênfase na construção do DW como um grande depósito central de informações,
110
tratadas, limpas e integradas, que é construído inicialmente, e de onde podem
surgir pequenos DM’s. Já no modelo Star Schema (modelo estrela), os dados
são armazenados em DM separados, que vão sendo integrados com outros
DM’s, e, na medida em que evolui, sua origem pode ser originada diretamente
dos dados operacionais sem a necessidade de passar por um DW central.
As duas abordagens, porém, não são excludentes e sim
complementares, de acordo com o desenho da base de dados escolhida para a
aplicação de BI. Howson (2008) afirma que o modelo Inmon está presente em
um maior número de empresas (39%), se comparada com o modelo estrela
(26%), embora ambas as abordagens sejam bem sucedidas. Normalmente,
indica-se o modelo de Inmon quando a fonte de dados tem origem em múltiplas
e diferentes bases de dados, e o modelo estrela quando a fonte de dados é
única. A arquitetura que se mostrou notavelmente de menor sucesso é a de
DM’s independentes.
Quanto ao Modelo Estrela, Turban et al. (2007) afirmam que ele se
baseia em uma tabela central chamada de tabela de fatos, que contém os
atributos necessários para executar a análise decisória, os atributos que serão
utilizados nas consultas e as chaves estrangeiras que permitem a ligação com
as tabelas de dimensões. Ao redor das tabelas de fatos encontram-se as
tabelas de dimensões, que contêm atributos que indicam como os dados serão
analisados. As dimensões são tratadas como entidades em um modelo
clássico de banco de dados relacional, ou seja, contêm as informações a
respeito da entidade (dimensão) que se deseja analisar. Parece complexo, mas
para quem conhece um pouco de modelagem de dados é uma questão de
alterar a perspectiva de visão da informação. O termo granularidade indica o
grau de detalhamento que os dados têm na tabela de fatos: quanto maior o
grau de detalhe maior será a sua granularidade. A figura 21 ilustra o modelo-
estrela.
111
Figura 21 – Exemplo de um modelo dimensional equivalente ao modelo entidade
relacionamento da figura 20
Fonte: adaptado de Barbieri (2001, p. 37)
Para o sucesso de uma aplicação de BI é necessário que, antes
de qualquer iniciativa nesse sentido, seja elaborado um projeto que descreva
as suas fases e o que será feito em cada uma delas.
2.2.4.2 Data Mining e predictive analysis
No processo decisório, muitas vezes, é necessário criar previsões
e estimativas utilizando variáveis. No entanto, na maioria das vezes, o número
de variáveis não passa de duas, e, dessa forma, pode ser necessário fazer
uma estimativa do volume de vendas para um determinado período ou prever o
112
preço de um produto para ele. Para essa finalidade, existem várias fórmulas
estatísticas disponíveis em ferramentas como o Excel, entre outras, que
permitem esse tipo de análise. Entretanto, em outros casos as análises são
mais complexas e envolvem muitas variáveis, sendo necessário o uso de
ferramentas mais sofisticadas, que permitam análises dos dados utilizando-se
modelos matemáticos, financeiros, estatísticos e outros, o que não pode ser
obtido utilizando-se apenas relatórios e queries oferecidos pelo OLAP. Para
essa finalidade, existem ferramentas especiais, tais como o data mining e o
predictive analysis.
Turban et al. (2007) definem o data mining como uma espécie de
análise das informações de um banco de dados, que procura por padrões
escondidos em um conjunto de dados que pode ser utilizado para prever
comportamento futuro. É o processo que utiliza estatística, matemática, e
inteligência artificial para extrair e identificar informações úteis e,
consequentemente, gerar conhecimento de grandes bancos de dados. O termo
data mining é utilizado para descrever o processo de descoberta de padrões,
por meio da análise dos dados. Esses padrões podem ser regras, afinidades,
correlações, tendências e modelos preditivos.
Algumas características diferem o data mining das tradicionais
técnicas de análise estatística. A mais importante delas é que por mais
sofisticadas que sejam as técnicas de análise estatística, o analista sabe o que
está procurando, possui, geralmente, uma hipótese ou pelo menos um palpite
sobre os relacionamentos de dados que está pesquisando. Já no caso do data
mining, os dados são ‘minerados’, para que os agrupamentos surjam. Então, o
analista pode usar várias ferramentas, tais como queries, geradores de
relatórios e análises multidimensionais, para avaliar os resultados.
Para Moss e Atre (2003), a melhor maneira de entender o
significado do data mining é pela análise de suas aplicações práticas. Segue,
abaixo, uma relação de situações em que o data mining pode ser utilizado:
113
1. gerenciamento de mercado: o data mining pode ajudar a identificar
situações de cross-selling, em campanhas e promoções, na análise de
cestas de compras de clientes, na análise de perda atuais e futuras de
clientes, entre outras;
2. detecção de fraudes com cartão de crédito, seguros, desvios de
comportamentos, etc;
3. gerenciamento de risco: analisar os riscos potenciais em conceder um
empréstimo por meio de modelos preditivos do banco de dados, para
identificar comportamentos de risco. Outra aplicação possível é no
controle da qualidade quando tenta-se identificar padrões que indiquem
problemas de qualidade;
4. serviços financeiros: reter os clientes pela identificação daqueles que
interessem à empresa e oferecer a eles tratamento diferenciado;
5. distribuição: melhorar o controle do inventário e o controle de
distribuição, por meio de modelos preditivos de quais produtos ou peças
serão necessárias em vários pontos de distribuição, em determinados
períodos de tempo.
Existem algumas restrições em relação ao data mining. Por se
tratar de uma técnica sofisticada, complexa e cara de análise de dados, é
necessário que sua aplicação possua uma justificativa realmente
compensadora. Por esse motivo, o data mining acaba não sendo uma técnica
largamente utilizada pelas empresas.
Segundo Turban et al. (2007), as ferramentas de predictive
analysis (análise preditiva) ajudam a determinar o resultado provável de um
acontecimento, ou a probabilidade de ocorrência de uma situação, além de
identificar, também, relações e padrões.
114
2.2.5 Ferramentas de BI: front-end
No decorrer de um projeto de BI, é possível que todas as etapas
tenham sido meticulosamente planejadas, para garantir o sucesso da
aplicação. Porém, se a ferramenta de BI não for adequadamente selecionada,
corre-se o risco de não se atingir os objetivos desejados, já que as ferramentas
de BI correspondem à parte mais importante de uma aplicação de BI para o
usuário, pois é por meio delas que o usuário interage com a aplicação. Desse
modo, deve-se ter especial atenção em relação ao tipo de ferramenta a ser
utilizada, o que dependerá do tipo de informação que os usuários finais
necessitem. Segundo Howson (2008), é fundamental selecionar a ferramenta
adequada para cada tipo de usuário, de forma a garantir o sucesso de uma
aplicação de BI. Uma técnica de marketing que pode ajudar nesse sentido é a
de segmentação dos consumidores, pois, com ela, é possível dividir um grande
número de usuários em grupos menores, agrupando-os mediante critérios, tais
como características similares necessidades e resultados desejados. A seguir,
disponibiliza-se uma relação das ferramentas de BI mais bem sucedidas.
2.2.5.1 Gerador de relatórios e queries
O gerador de relatórios permite que se criem relatórios sob
medida para a necessidade do usuário, atendendo a um propósito definido.
Sua principal característica é que, teoricamente, o usuário ganha
independência para criar relatórios e queries, por sua própria conta sem a
necessidade de ter de recorrer ao TI para o seu desenvolvimento. A ferramenta
permite que se formate o relatório da maneira mais adequada, assim o usuário
pode alterar a classificação dos dados, a totalização, a fonte, os cabeçalhos
115
dos campos, etc. O gerador de relatórios funciona para listar dados e
informações que já existam e não necessitem de processos complexos de
processamento de dados que envolvam comandos do tipo “IF”, “THEN”,
“ELSE”. Para esses casos, o melhor é que um programa de transformação na
fase do ETL prepare os dados para que o gerador de relatórios e queries possa
listá-los.
2.2.5.2 OLAP
Segundo Turban et al. (2007), o termo OLAP (Online Analytical
Processing) se refere a uma variedade de atividades frequentemente
executadas por usuários finais de sistemas online, e não há um consenso em
quais atividades são consideradas de OLAP. Geralmente, são incluídas
atividades, tais como geração de consultas (queries), geração de relatórios e
gráficos ad hoc, análises estatísticas e o desenvolvimento de aplicações de
suporte à decisão e de multimídia. Alguns incluem entre as funções de OLAP
sistemas de informação executiva e/ou empresarial e data mining. O objetivo
do OLAP é auxiliar o usuário na exploração e análise dos dados, e os
geradores de relatório ajudam a monitorar ‘o que’ está acontecendo enquanto
que o OLAP permite uma análise do ‘por que’ algo está acontecendo. As
ferramentas de OLAP são populares, não apenas por permitir aos usuários
auto-suficiência em relação às análises, mas também por outras características
inovadoras para análise de dados. Segundo Howson (2008), as principais
características de uma ferramenta de OLAP são:
• multidimensional: os usuários analisam as informações sob diferentes
dimensões, tais como tempo, região, produto, etc. Os relatórios, ao
contrário, permitem apenas uma visão de uma única dimensão;
• rapidez: o OLAP permite que os usuários efetuam consultas com
rapidez, quando navegam nas diferentes dimensões das informações;
116
• alto grau de interatividade: possui funcionalidades que permitem uma
interatividade incomparável em relação a relatórios e queries. Entre as
funcionalidades mais importantes estão:
a. drill-down: navegar de um nível consolidado para um nível mais
detalhado da informação,
b. drill-up: navegar de um nível detalhado para um nível mais
consolidado da informação,
c. drill-across: permite alterar o nível de análise dentro de uma
mesma dimensão, e, assim, passa-se de ano para mês dentro de
uma dimensão de tempo,
d. drill through: passa-se de uma dimensão para outra, e, assim, o
usuário que estava pesquisando informações em uma dimensão
de tempo, passa para uma dimensão de região,
e. slice (fatiar): funciona como um filtro, permitindo que se restrinja
uma das dimensões a apenas alguns de seus valores, por
exemplo, em uma dimensão de tempo seleciona-se apenas o ano
de 2008,
f. dice (cubo): permite analisar as diferentes dimensões das
informações, por meio da mudança de perspectiva
multidimensional;
• vários níveis de sumarização e agregação: a sumarização
corresponde à totalização de um mesmo dado de valor, por exemplo: a
soma dos salários dos funcionários de um departamento; já a agregação
ou reunião corresponde ao dado resultante da soma de vários dados
diferentes, exemplo: somar o salário anual, os bônus e o valor pago
correspondente ao plano de saúde e de aposentadoria de um
funcionário para calcular o valor do plano de compensação de um
empregado;
• cálculos através de diversas dimensões: devido às multidimensões,
os cálculos se tornam mais complexos. No OLAP, pode-se querer
117
calcular o percentual de contribuição ou participação de mercado.
Assim, será necessário sub-totalizar as vendas para um estado em
particular e depois calcular o percentual de contribuição para a região
toda, país ou mundo. Os usuários podem também analisar o percentual
de participação de mercado com números de outras dimensões, tais
como o resultado deste ano com o de outros, para um grupo particular
de produtos.
O OLAP faz a relação entre os dados e o negócio, essa relação
ocorre pela apresentação dos dados aos usuários de uma maneira fácil.
Porém, a maneira mais fácil de apresentação dos dados deve ser definida
pelos usuários desses dados e não pela equipe de TI, pois os critérios de
‘facilidades’ podem ser diferentes entre esses dois grupos de pessoas, pois o
que para uma pessoa de TI pode ser uma aplicação extremamente fácil, bem
estruturada e rápida, pode significar a mesma coisa para o usuário final, pois
não atende à suas necessidades. As ferramentas de OLAP têm que ser
flexíveis e adaptáveis, pois os usuários têm formação e habilidades diferentes,
além de diferentes preferências e necessidades.
2.2.5.3 Microsoft Office
É comum não se considerar o Excel como uma ferramenta de BI,
pois as equipes de TI, frequentemente, o ignoram ou sugerem que não seja
utilizado, visto que, com o Excel, o usuário acaba criando núcleos de
informações que podem se contrapor a outros núcleos de informações
semelhantes dentro da própria organização. Assim, a ‘verdade’ acaba tendo
uma série de versões, o que se procura eliminar quando da utilização de uma
aplicação de BI. No entanto, segundo Howson (2008), essa abordagem vem
sofrendo alterações, e hoje muitos vendedores de soluções de BI procuram
garantir que o Excel e as aplicações de BI possam trabalhar juntas.
118
2.2.5.4 Dashboards
Trata-se de uma forma de visualizar as informações mais
importantes e necessárias para se alcançar um ou mais objetivos, de forma
consolidada e disposta em uma única tela, de maneira que a informação possa
ser monitorada de uma única vez (HOWSON, 2008 p. 89).
Os dashboards funcionam como um painel de controle em que
administradores e gerentes podem monitorar o desempenho de uma
organização, por meio da visualização de diversas informações de diferentes
fontes, de uma forma ágil, e sem necessitar navegar por entre uma série de
telas. Essa funcionalidade não é exatamente uma novidade, visto que os
Sistemas de Informação Executiva dos anos 80 já traziam algumas funções
similares. Entretanto, o que é novidade é a flexibilidade, a capacidade de
agrupar um grande volume de informações em uma única tela, sendo que em
alguns casos é possível até que os dashboards sejam construídos pelo próprio
usuário. A figura 22, mais adiante, ilustra um exemplo de dashboard.
Figura 22 – Exemplo de dashboard
Fonte: InfoBuild Brasil (2008)
119
2.2.5.5 Scorecards
Segundo Howson (2008), é comum utilizar os termos ‘dashboards’
e ‘scorecards’ de forma intercambiável, como se fossem a mesma coisa,
embora não sejam. Enquanto o scorecard compara métricas da empresa com
metas e previsões, o dashboard pretende apenas mostrar diferentes números
de diferentes maneiras. Algumas vezes, os dashboards apresentam também
metas e previsões, o que acaba gerando a confusão. Porém, não é para se
entender que isso seja uma regra. O scorecard estratégico contém métricas
das quatro principais áreas que se devem monitorar para garantir o sucesso de
uma empresa: pessoas, clientes, finanças e operações. Por sua vez, o
Balanced Scorecards (BSC) procura demonstrar, de forma balanceada, os
indicadores de desempenho de uma empresa, sob diferentes perspectivas e
não apenas o desempenho econômico-financeiro.
2.2.6 Etapas de um projeto de Business Intelligence
Para o sucesso de uma aplicação de BI é necessário que antes
de qualquer iniciativa nesse sentido, seja elaborado um projeto que descreva
as suas fases e o que será feito em cada uma delas. Moss e Atre (2003)
afirmam que o projeto de BI, como qualquer outro projeto de engenharia, pode
ser dividido em 6 etapas principais, entre a identificação da necessidade de
desenvolvimento da aplicação até a sua implementação e manutenção, com a
necessária subdivisão dessas etapas em passos. A figura 23 ilustra a
sumarização dessas etapas, descritas uma a uma posteriormente.
120
Figura 23 – Etapas de um projeto de BI
Fonte: adaptado de Moss e Atre (2003, p. 194)
1. Etapa da justificativa: é necessário verificar a necessidade real da
aplicação que justifique o seu desenvolvimento.
Passo 1: avaliação da necessidade do negócio – a justificativa para a
implementação de uma aplicação de BI deve começar pela identificação
das metas estratégicas de negócios que a empresa deseja alcançar. A
partir daí, é possível propor um projeto de aplicação de BI alinhado a
essas metas. É importante que cada nova aplicação de BI tenha uma
justificativa para ser criado e que os benefícios que trará para o negócio
sejam descritos.
2. Etapa de planejamento: elaboram-se os projetos táticos e operacionais
que estabelecem a forma como o projeto será desenvolvido e
implantado.
Passo 2: avaliação da infra-estrutura necessária para a aplicação de BI
– deve-se considerar todos os elementos necessários à utilização do BI,
tais como necessidades de hardware (servidor, equipamentos de rede) e
121
software (sistema de administração de banco de dados, ferramentas de
BI). É necessário, também, considerar a necessidade de elementos não
técnicos, tais como procedimentos, metodologias, reformulação de
processos, etc.
Passo 3: planejamento do projeto – os projetos de BI são dinâmicos.
Assim, qualquer mudança em um dos elementos do projeto ( escopo,
equipe, orçamento, tecnologia, responsáveis), pode causar impacto
sobre o sucesso da aplicação.
3. Etapa de planejamento: efetua-se uma análise do problema a ser
resolvido com a aplicação do BI, as oportunidades que essa aplicação
irá trazer para a empresa e quais as soluções possíveis.
Passo 4: definição dos requisitos do projeto – o gerenciamento do
escopo do projeto é fundamental, pois a tendência é que se peça tudo
ao mesmo tempo para entrega imediata. Dessa forma, é importante se
defina bem o que será entregue.
Passo 5: análise dos dados – analisar a qualidade dos dados é um
desafio à parte para um projeto de BI, especialmente se a origem dos
dados são sistemas legados desenvolvidos há muito tempo ou, pior
ainda, se os dados terão origem em sistemas legados que,
normalmente, não são conciliados.
Passo 6: utilização de protótipos – a análise das aplicações a serem
desenvolvidas pode lançar mão da construção de protótipos para melhor
compreender as necessidades dos usuários. Novas ferramentas de
desenvolvimento permitem ao desenvolvedor criar de maneira
simplificada protótipos que podem ajudar a aprovar ou não uma
determinada idéia para o desenvolvimento de um aplicativo. A utilização
de protótipos das aplicações a serem desenvolvidas ajuda tanto o
desenvolvedor que tem uma melhor percepção se a aplicação que está
sendo criada atende as expectativas do usuário, quanto ajuda o usuário
a entender, de forma prática, as possibilidades e limitações dessa
tecnologia.
122
Passo 7: análise do repositório dos metadados – é necessário que se
criem modelos lógicos dos metadados e que estes sejam comparados
aos dos usuários. Deve-se documentar, no modelo, os metadados
referentes a um determinado negócio, e que devem ser selecionados e
armazenados.
4. Etapa do Desenho: conceber uma aplicação que resolverá o problema
da necessidade de informações ou que trará novas oportunidades.
Passo 8: desenho da base de dados (DW/DM) – deve ser definido o
grau de detalhamento das informações a serem armazenadas; deve-se
levar em consideração também que nem todas as informações
necessárias serão multidimensionais nem estratégicas.
Passo 9: desenhar como serão extraídos, transformados e carregados
os dados (ETL) – esta é a tarefa mais complicada, desafiadora e, ao
mesmo tempo, a menos empolgante de um projeto de BI. Se os dados
forem de baixa qualidade, a definição dos processos de transformação e
limpeza dos dados para que possam ser utilizados tomará muito tempo.
Passo 10: desenho do repositório dos metadados – pode-se optar por
comprar uma aplicação para administração dos metadados ou construí-
la na empresa.
5. Etapa da construção: refere-se à etapa de execução da tarefas
planejadas para a construção do BI.
Passo 11: extrair, transformar e carregar os dados (ETL) – existem
muitas ferramentas disponíveis para processar o ETL, algumas mais
complicadas e outras mais simples. Dependendo da análise dos dados
efetuados na etapa 5 e do desenho do ETL definidos na etapa 9, uma
ferramenta de ETL pode ser ou não uma boa opção.
Passo 12: desenvolvimento da aplicação – dependendo da opção que
foi efetuada, referente à utilização de protótipos definida na etapa 6, será
apenas uma questão de concluir o protótipo ou iniciar uma fase de
desenvolvimento pesado, utilizando-se ferramentas mais robustas de
123
análise e de construção da aplicação. Normalmente, esta fase caminha
em paralelo com a de desenvolvimento do repositório dos metadados e
das funções do ETL.
Passo 13: data mining – frequentemente, as aplicações desenvolvidas
para BI acabam transcrevendo consultas e relatórios pré-definidos que
já existiam de alguma forma. Porém, uma ferramenta de data mining,
que pode ser traduzida como o processo de mineração dos dados para
obtenção de padrões, pode revelar informações escondidas no conjunto
de dados da empresa.
Passo 14: construção do repositório dos metadados – se a opção
efetuada na etapa 10 for pela construção do repositório dos metadados,
ao invés da compra de uma aplicação pronta, deve-se iniciar a sua
elaboração. Pode ocorrer de uma equipe diferente ser designada para
construir o repositório dos metadados, daquela que está construindo a
aplicação de BI. Isso depende do tamanho do projeto e do número de
pessoas envolvidas.
6. Etapa de implantação: implantar e acompanhar o desempenho da
aplicação, para se saber se atingiu ou não os objetivos desejados.
Passo 15: implantação – após a equipe de desenvolvimento ter
efetuado testes exaustivos da aplicação e de ter treinado os usuários
finais, a aplicação de BI é implantada no ambiente de produção e suas
atividades são monitoradas. Efetuam-se manutenções corretivas e
acompanha-se o desempenho da aplicação e do DW.
Passo 16: avaliação de releases – é importante que se aprenda com a
experiência adquirida com o planejamento e desenvolvimento das
aplicações que já foram efetuadas. Assim, deve ser analisado o que
ocorreu nos projetos passados, como por exemplo, os motivos para o
não cumprimento dos prazos, orçamentos e entrega de aplicações que
não atenderam, de forma plena, as expectativas dos usuários. Deve-se,
também, se atentar para as técnicas, ferramentas e processos que não
funcionaram bem e reavaliar o seu uso.
124
As etapas descritas acima não precisam, necessariamente,
ser efetuadas uma após a outra, pois algumas podem ocorrer em paralelo.
Dependendo também do escopo e do tamanho do projeto é importante avaliar
a aplicação de algumas etapas e a sua intensidade.
2.2.7 Business Intelligence Competency Centers (BICC)
O BICC ou Centro de Competência do Business Intelligence é um
novo conceito que surgiu recentemente nas empresas em relação aos projetos
de BI. O BICC reúne pessoas da área de TI e usuários do BI que reúnam o
conhecimento, as habilidades e as competências necessárias para disseminar
o desenvolvimento e uso do BI pela empresa. Seu objetivo é garantir a
qualidade e o sucesso das aplicações de BI, centralizando em um grupo de
trabalho o conhecimento e as melhores práticas para o desenvolvimento de
aplicações de BI com foco na empresa.
Para Howson (2008), o BICC pode ser definido como uma equipe
multifuncional com uma tarefa específica, além de funções, responsabilidades
e processos para se apoiar e promover o uso efetivo do BI em toda a empresa.
Segundo a autora, a principal diferença entre o BICC e os projetos de BI é que
os projetos de BI têm um escopo definido e prazos para entregar as aplicações
a serem desenvolvidas, sendo que o BICC tem um caráter permanente.
A criação do BICC é indicada para empresas que pretendem criar
um modelo de BI direcionado para a organização como um todo e não apenas
como um projeto isolado. Nesses casos, a criação do BICC é indicada, pois
ajuda a definir os conhecimentos, os padrões e os recursos necessários para
que isso ocorra. Segundo Davenport (2007), o BICC é uma boa idéia e tem
funções importantes: algumas vezes são mais educadoras, outras, voltados
125
para consultoria, para os usuários e para como eles resolvem questões
relacionadas a análises. O BICC colabora com o sucesso das aplicações de BI,
pois:
• maximiza a eficiência, o uso e a qualidade do BI por toda a
organização;
• possibilita que as aplicações entreguem mais valor, melhor
qualidade, menor custo e tempo;
• conduz os usuários finais no uso do BI para garantir o seu
sucesso, pois simplesmente entregar aplicações prontas não
garante que serão utilizadas;
• elimina a separação ente o TI e o negócio;
• permite maior agilidade às empresas e uma melhor administração
da tecnologia de forma a conduzir melhor os negócios.
2.2.8 ERP e Business Intelligence: soluções complementares
Uma empresa pode utilizar o BI sem possuir um sistema ERP,
pois é possível extrair dados de diferentes origens, transformá-los e carregá-los
em um data warehouse e, a partir daí, fazer uso do BI. Porém, se compararmos
empresas semelhantes que decidirem, em um mesmo espaço de tempo,
construir uma aplicação de BI, sendo que a primeira já possui implantado o
ERP, e a segunda não; as chances da empresa que possui o ERP de construir
uma aplicação de BI de sucesso são muito maiores do que a que não o possui,
por uma série de motivos.
Os sistemas transacionais são o ponto de partida dentro do ciclo
de vida do BI, por meio dos quais os dados serão mais adiante analisados.
Sendo assim, se os sistemas transacionais permitirem a ocorrência de falhas,
falta de consistência, duplicidades, e outros problemas do gênero, isso irá se
126
refletir mais adiante e exigirá que sejam corrigidos, antes que sejam
disponibilizados no data warehouse para a aplicação de BI. Esse tipo de
ocorrência consumirá recursos adicionais, tanto na fase de planejamento,
quanto na execução e no dia-a-dia da operação do BI, e muitos dos problemas
que surgirem na origem dos dados não poderão ser corrigidos mais adiante,
surgindo no momento em que tenta combiná-los com outros dados.
Para Howson (2008), o sistema ERP garante a aderência da
empresa a processos padronizados, e são bem mais abrangentes do que os
sistemas transacionais do passado. Sob uma perspectiva dos dados, o sistema
ERP reduz duplicidades de entrada de dados, melhorando sua qualidade. Com
o ERP e sua base de dados relacional integrada, a codificação de clientes,
produtos, fornecedores e demais cadastros é compartilhada por diversos
módulos e aplicações ao longo de toda a empresa.
Além disso, a implantação e utilização de um sistema ERP
alteram a cultura da empresa, fazendo com que os dados e informações sejam
tratados de uma maneira integrada. Se no passado o ERP era visto como mais
um modismo da área de TI, hoje o software está provado e maduro, sendo que
o eixo de discussão hoje é como tirar o maior proveito possível dos benefícios
que o ERP pode, direta ou indiretamente, oferecer. Segundo Norris et al.
(2001), com o ERP uma empresa pode substituir os sistemas legados
construídos em diferentes períodos, que acumulam dados de maneiras
diversas, passando a ser o eixo que suportará estratégias de negócio
existentes.
Sobre a padronização e as vantagens que isso trás para a
empresa, Laudon e Laudon (2007) avaliam que os dados dos sistemas
integrados têm definições e formatos comuns e padronizados, aceitos por toda
a organização. Assim, os números do desempenho organizacional têm o
mesmo significado em qualquer parte da empresa. Desse modo, a
administração sênior pode, a qualquer momento, verificar o desempenho de
uma unidade organizacional específica, ou determinar quais produtos são mais
ou menos lucrativos.
127
No entanto, o ERP tradicional, sozinho, não atendia a todas as
necessidades que um a empresa possui, tanto em termos transacionais quanto
ao relacionamento com clientes e fornecedores. Sendo assim, passada a fase
de sua maturação, foi necessário expandir suas funcionalidades e agregar
recursos e outros aplicativos que antes eram considerados soluções
separadas, como no caso do Business Intelligence. Com a chamada ‘segunda
onda’, o sistema ERP passou a integrar novas funcionalidades tal como o BI,
SCM, CRM, entre outros. A queda das fronteiras é tão notória que Haberkorn
(2007) classifica o BI como uma evolução de todas as possibilidades de
consultas que um ERP oferece.
Por outro lado, uma aplicação de BI pode fazer uso das mais
modernas e interativas ferramentas de front-end. Mas, se os dados que ela
apresentar não forem confiáveis, todos os esforços efetuados no projeto da
aplicação de BI cairão em descrédito, passando a ser visto pela organização
como uma fonte insegura para a obtenção de informações no processo de
tomada de decisão, sendo abandonada em seguida. A partir desse ponto, para
se reconquistar a confiança dos seus usuários deverá haver um trabalho
extremamente penoso que tomará muito tempo da equipe de BI, isso se a
iniciativa não for definitivamente encerrada.
Além disso, Inmon (2002) complementa que a aquisição das
soluções de ERP e de BI de um mesmo fornecedor, oferece várias vantagens.
Entre elas está o fato de que o fornecedor provê toda a infra-estrutura
necessária para a construção do ambiente de BI, dentro do ambiente do ERP.
Isso economiza tempo da empresa, pois reduz a complexidade do desenho e
desenvolvimento do data warehouse, por exemplo, além de atenuar a questão
de sua manutenção ao longo do tempo. Uma outra vantagem citada é que até
mesmo os dados que não pertençam à base de dados do ERP podem ser
extraídos e carregados no data warehouse, passando a desfrutar das
vantagens proporcionadas pela infra-estrutura construída pelo fornecedor de
ERP/BI.
128
Assim, as iniciativas de desenvolvimento de aplicações de BI
apoiadas por sistemas ERP têm maiores chances de sucesso do que aquelas
que não contam com esse apoio, pois o ERP vai além de ser apenas a fonte
primária de dados para o BI, contribuindo não apenas com a infra-estrutura
necessária, mas também atuando em vários fatores que determinam o sucesso
de uma aplicação de BI.
2.2.9 Fatores para o sucesso de uma aplicação de BI
Muitos projetos de BI não atingem o êxito esperado ou fracassam
por uma série de fatores, tais como falha no gerenciamento, falta de
planejamento, falta de envolvimento e capacitação do usuário, falta de
preocupação com a origem e a qualidade dos dados, falta de preparo da
equipe de projeto, tecnologia falha, entre outros.
Mesmo quando uma empresa faz uso de uma metodologia
comprovadamente bem sucedida para a construção de uma aplicação de BI,
muitas vezes, o projeto acaba falhando, e então os seus idealizadores se
perguntam o que ocorreu para que um projeto detalhadamente estudado e
planejado tenha falhado.
Segundo Howson (2008), a tecnologia permite a utilização do BI,
mas as empresas que se concentrarem demasiadamente nas questões
tecnológicas podem acabar sabotando essa iniciativa, pois são as pessoas que
fazem a diferença entre uma iniciativa de sucesso ou uma que falhe. O
sucesso na utilização de um aplicativo de BI não depende apenas da
tecnologia empregada, mas também da criatividade, da maturidade no uso de
sistemas de informação, em aspectos culturais e em quanto as pessoas da
organização realmente acreditam que a informação pode representar uma
vantagem competitiva importante. Nem sempre as abordagens escolhidas para
disseminar o emprego de aplicações de BI nas organizações são as mais
129
apropriadas, de maneira a transmitir a relevância e os benefícios que sua
utilização pode trazer para a empresa.
A Computerworld (2008) é categórica em afirmar que, se a
adoção do BI for liderada apenas pela área de tecnologia, sem apoio da
gerência e sem o envolvimento das outras áreas internas de interesse, não há
possibilidade que a aplicação tenha sucesso. O segredo do sucesso, então,
está em considerar com igual importância tanto os aspectos técnicos quanto os
de negócio. Por isso, as decisões a serem tomadas, principalmente em relação
à ferramenta, não podem considerar apenas os custos envolvidos, mas
também outros aspectos tais como flexibilidade, disponibilidade, agilidade, ente
outras coisas. Sendo assim, ao se analisarem os fatores críticos de sucesso
para a implantação de uma aplicação de BI, é necessário levar em
consideração não apenas os aspectos técnicos, mas outras questões, tais
como a disseminação do uso do BI pela organização, a gestão da mudança,
avaliação das oportunidades, os fatores culturais, entre outros; que podem
comprometer o mais bem intencionado dos projetos de BI.
2.2.9.1 Principais fatores que contribuem para o sucesso de uma
aplicação de Business Intelligence
Na revisão da literatura sobre fatores críticos de sucesso para a
implantação de uma aplicação de BI, foram considerados os fatores críticos de
sucesso, apontados nos estudos desenvolvidos por Moss e Atre (2003),
Barbieri (2001), Turban et al. (2007), Ponniah (2001) e Howson (2008).
Levando-se em consideração que os autores se diferenciam em relação à
abordagem adotada sobre o tema, alguns com uma visão mais técnica e outros
de forma mais holística, os trabalhos possuem vários pontos de similaridade.
Howson (2008) conduziu uma pesquisa para identificar as
variáveis de sucesso de uma aplicação de BI levando-se em consideração, não
130
apenas aspectos técnicos, como também outros. Essa pesquisa envolveu
empresas do mundo todo de diferentes tamanhos e diferentes segmentos de
mercado, cujas iniciativas de desenvolvimento de aplicativos de BI foram
reconhecidas por revistas especializadas, especialistas e vendedores de
software. A autora levou em consideração também empresas que mostraram
dinamismo e crescimento expressivo, de forma a tentar compreender se as
iniciativas de BI tiveram alguma relação com o sucesso demonstrado por essas
empresas. Analisaram-se, também, alguns estudos de casos de empresas
cujas iniciativas de BI foram relevantes e significativas em relação ao
desempenho dessas organizações. O universo da pesquisa considerou 513
respondentes válidos, distribuídos entre empresas grandes (43%), médias
(30%) e pequenas (27%). Os Estados Unidos foram os maiores respondentes,
responsáveis por 69% das respostas, seguidos pela Europa 12%, Ásia 6%,
Canadá 4%, América Latina 4%, Austrália e Nova Zelândia 4%, e África do Sul
com 1%.
Os resultados dessa pesquisa foram resumidos em dez conselhos
práticos para o sucesso de aplicações de BI. Para cada um dos fatores são
citados também os outros autores toda vez que há uma concordância entre os
trabalhos, em relação à relevância daquele determinado fator para o sucesso
de uma aplicação de BI. O resultado é a montagem do modelo teórico padrão a
ser utilizado no estudo de caso deste trabalho. Os dez fatores de sucesso são
relacionados a seguir.
1. Meça o sucesso de múltiplas maneiras, utilizando medidas objetivas
quando disponíveis e identificando a importância dos benefícios que
não podem ser mensurados quantitativamente.
Seria perfeito se fosse possível aplicar um único indicador para
aferir o sucesso de uma aplicação de BI, tal como o ROI (Return on
Investment). Ocorre, porém, que as coisas não são tão simples assim, pois se
por um lado é relativamente fácil calcular o custo de desenvolver aplicações de
BI, é extremamente difícil determinar o seu retorno, apesar de que algumas
131
empresas o fazem mesmo considerando o grau de imprecisão dos indicadores.
Outra forma quantitativa de aferir o sucesso do BI é sugerida por Howson
(2008), por meio do percentual de usuários ativos versus usuários potenciais.
Nesse sentido, a autora alerta para a importância de algumas definições, por
exemplo: uma pessoa que utilize um relatório em PDF ou outra extensão
qualquer, gerado por uma ferramenta de BI é um usuário? Segundo critérios
estabelecidos por Howson (2008), tecnicamente sim, essa pessoa é usuária
ativa do BI.
No entanto, a maioria das implantações de BI que apresentaram
êxito utiliza múltiplos indicadores com variados níveis de importância e
precisão. Moss e Atre (2003) sugerem que se meça o sucesso de uma
aplicação de BI considerando as seguintes questões:
• O patrocinador do projeto está satisfeito com as aplicações de BI?
• As pessoas de negócios gostam das aplicações de BI? Essas
aplicações são fáceis de serem utilizadas?
• O que eles gostam? O que eles não gostam? Por quê?
• Eles estão utilizando o repositório de metadados? Eles acham
que o repositório de metadados ajuda?
• O patrocinador pretende apoiar outras aplicações de BI?
A figura 24 ilustra as formas mais comumente adotadas para se
medir o sucesso ou as falhas de uma aplicação de BI.
132
Figura 24 – Medidas do sucesso ou falhas do BI
Fonte: adaptado de Howson (2008, p. 58)
2. Entenda os efeitos da sorte, oportunidade, frustração e ameaça (em
inglês, LOFT: Luck, Opportunity, Frustation e Threat), para elevar sua
aplicação de BI de um resultado moderado para uma iniciativa de
grande êxito.
O papel da sorte, descrito aqui por Howson (2008), tem pouco a
ver com o acaso, e sim com a importância de se estar preparado para
identificar oportunidades e ameaças. A empresa e, em especial, a equipe de BI
deve se alinhar aos negócios de forma a poder reagir de forma ágil,
desenvolvendo aplicações que possam capacitar a empresa a identificar
oportunidades e ameaças que surgem no horizonte da empresa.
Segundo Turban (2007), o ambiente no qual as empresas operam
tem se tornado cada dia mais complexo. Essa complexidade cria oportunidades
que podem ser aproveitadas, mas ela também gera problemas com os quais a
empresa deve lidar. A globalização é um exemplo disso, pois se por um lado a
ela amplia o leque de clientes e fornecedores, criando oportunidades para a
empresa, por outro aumenta a competição com concorrentes fortes, que podem
significar ameaça para a empresa. Por conta desse aumento da complexidade
no processo decisório, os administradores de uma empresa necessitam
133
também adotar processos e ferramentas mais sofisticados com o objetivo de
agilizar as análises, efetuar previsões, obter respostas em tempo real, entre
outras ações.
A frustração deve ser administrada e pode atuar de duas
maneiras: a primeira, de forma positiva, como um indicador de onde pode ser
utilizada uma aplicação de BI, por exemplo: um gerente que se sinta frustrado
em relação ao acesso às informações, mas que não utiliza o BI pode se
transformar em uma excelente oportunidade, caso a equipe de BI tenha a
capacidade de entender as suas necessidades e desenvolver uma aplicação
em tempo ágil que resolva essa deficiência. A segunda, mencionada por
Turban et al. (2007) e Ponniah (2001), sugere que o responsável pelo projeto
de BI deve relacionar as expectativas que podem e as que não podem ser
cumpridas, como forma de evitar que os executivos se frustrem na ‘hora da
verdade’, ou seja, quando a aplicação entrar em operação.
3. Conquiste o apoio executivo para garantir que o BI se infiltre por todos
os cantos da organização, para gerar vantagens competitivas e valor
dos negócios.
Segundo as pesquisas de Howson (2008), este é o fator mais
importante de sucesso de uma aplicação de BI, pois sem o apoio efetivo da
diretória as possibilidades de sucesso de uma aplicação de BI ficam reduzidas.
Essa afirmação é reforçada por Barbieri (2001), Turban et al. (2007), Atre
(2003) e Ponniah (2001), que afirmam ser fundamental a presença de um
‘patrocinador’ para definir pendências, esclarecer dúvidas do negócio e
promover o projeto. Quem quer que seja esse ‘patrocinador’, é fundamental
que ele entenda os benefícios que o BI pode proporcionar, além de ser alguém
que possua uma ampla influência e credibilidade, de forma a influenciar os
demais pelo interesse no uso do BI. Ponniah (2001) acrescenta que esse
patrocinador deve oferecer suporte de forma contínua e comprometida por um
134
longo período de tempo. Para Howson (2008), o patrocinador apóia as
iniciativas de BI das seguintes maneiras:
a) articula o comprometimento necessário à iniciativa da construção das
aplicações de BI e com o impacto que terá sobre a organização;
b) posiciona o papel do BI dentro do contexto da estratégia da empresa;
em alguns casos, ele pode ser o responsável por definir esse papel;
c) aprova o orçamento;
d) elimina barreiras políticas;
e) ajuda a resolver problemas que a equipe de BI não pode ou não tem
poder para tal. Esses problemas, geralmente, envolvem questões
que não são técnicas, como prioridades, escopo, assuntos
organizacionais, etc.
4. Comece com uma fundação sólida e acrescente melhorias de forma
incremental e consistente para melhorar a qualidade, amplitude e
atualidade aos dados.
Essa é uma estratégia reconhecidamente de sucesso, pois tem o
efeito de demonstrar na prática o que é possível obter do BI convencendo os
mais reticentes que passam a utilizar e demandar por aplicações. Inicia-se com
uma aplicação modesta, relevante e efetiva, e então se promove essa
aplicação, demonstrando para os interessados os benefícios que o BI pode
oferecer para o negócio. Isso propaga entre os possíveis usuários o interesse
pela aplicação, sendo que eles começam a visualizar novas aplicações que
podem beneficiá-los em seu trabalho e, consequentemente, beneficiar a
empresa.
Além disso, projetos menores facilitam a definição de seu foco e
dos objetivos a serem alcançados. Barbieri (2001) classifica esse fator de
135
sucesso como a necessidade de ter um objetivo bem definido, fugindo do
gigantismo ou, por outro lado, de projetos particularizados demais.
Deve-se pensar de forma mais ampla para permitir integrações
futuras, porém desenvolver o projeto por partes. Ponniah (2001) também
sugere essa estratégia de começar com um projeto piloto que tenha
visibilidade, para demonstrar os benefícios para os futuros usuários, entretanto,
já pensando na empresa como um todo e na expansão das aplicações.
5. Alinhe a estratégia de BI com as metas do negócio, garantindo que o
pessoal de TI e de negócios trabalhem mais como parceiros do que
como adversários.
Segundo Howson (2008), 55% dos respondentes de sua pesquisa
afirmaram que a parceria entre as pessoas da área de TI e de negócios é
fundamental para o sucesso de uma aplicação de BI. A diferença entre os
perfis desses dois grupos de pessoas que integram a equipe responsável pelas
iniciativas de BI pode comprometer uma boa parceria.
Dessa forma, as pessoas da área de TI tendem a ser mais
técnicas, introvertidas, metódicas, disciplinadas, avessa a riscos e a priorizar a
comunicação documental ao invés da pessoal. Já as pessoas das áreas de
negócio tendem a ser mais extrovertidas, sociais, soltas, dispostas a aceitar
riscos e preferem o contato pessoal nas comunicações. Esses dois tipos de
perfis diferentes podem entrar em conflito e causar problemas em um projeto
em que tenham que trabalhar juntos. Desse modo, Howson (2008) sugere que
se invista em pessoas com perfil híbrido TI-negócios, para fazer a ponte entre
as áreas de TI e de negócios. Essa pessoa, geralmente, é da área de
negócios, que conheça TI, e não é preciso que seja um programador, nem um
analista de sistemas, mas que conheça o suficiente para traduzir para a equipe
de TI as necessidades, oportunidades, e solicitações de negócios, e, ao
136
mesmo tempo, que saiba das possibilidades que a tecnologia pode oferecer,
visto que o BI repousa na intersecção entre a tecnologia e a área de negócios.
É necessário, porém, não confundir parceria com alinhamento.
Parceria significa comprometimento e reconhecimento de que os parceiros têm
interesse no sucesso um do outro. Já alinhamento significa que TI e a área de
negócios estão caminhando na direção correta. Essa distinção é importante
para que a área de TI entenda que não adianta efetuar o desenvolvimento de
tudo o que uma determinada área de negócios solicitar, sem questionar se
essas solicitações não estão alinhadas às estratégias de negócio da empresa,
pois se isso ocorrer será um exercício inútil. Em concordância com essa
definição, Turban et al. (2007) e Moss e Atre (2003) afirmam que as iniciativas
de BI como um todo e as aplicações de forma específica devem apoiar as
metas estratégias do negócio, pois, sem isso, a iniciativa de BI poderá
fracassar.
6. Encontre relevância para o BI para cada trabalhador da empresa,
assim como para os clientes e fornecedores.
Howson (2008) adverte que as aplicações de BI de sucesso
devem ir além de simplesmente disponibilizar um imenso repositório de dados
com livre e, por vezes, esmagador acesso aos dados. O ideal é disponibilizar
aplicações que tenham relevância para quem vai utilizá-las, de maneira a
facilitar o seu uso e insights. Além disso pelo critério de relevância, muitas
vezes, é necessário priorizar o desenvolvimento de aplicações alinhadas com o
negócio da empresa do que se empenhar no desenvolvimento de aplicações
baseadas apenas na demanda de departamentos que efetuam as solicitações
de forma mais contundentes. Dessa forma, se uma empresa vende planos de
saúde, mas é o departamento financeiro quem demanda desenvolvimentos de
aplicações de BI, a empresa deve ponderar e priorizar as aplicações que
137
tenham relevância, por essa lógica as aplicações voltadas para o negócio
devem ter prioridade sobre a área financeira caso seja necessário priorizar o
desenvolvimento. Isso contraria o senso comum de dar ênfase no
desenvolvimento para áreas da empresa que mais demandarem aplicações de
BI, dessa forma a equipe de BI passa a atuar de forma mais pró-ativa e menos
reativa.
É possível que se questione essa estratégia, pois as áreas
voltadas para o negócio da empresa podem não demandar por aplicações de
BI, enquanto outras não relacionadas diretamente ao negócio da empresa o
façam com mais afinco. Em relação a essa questão, Howson (2008) acredita
que é necessário que a equipe de BI avalie quais são os indicadores de
desempenho da empresa, pois assim será possível desenvolver aplicações que
forneçam informações relevantes às pessoas cujas decisões têm o maior
impacto dentro da organização, ao contrário de desenvolver aplicações pelo
simples critério de demanda.
7. Utilize processos ágeis de desenvolvimento para entregar capacidades
e melhoramentos de BI de forma equivalente à medida que ocorrem as
mudanças nos negócios.
Os métodos tradicionais de desenvolvimento de sistemas seguem
uma seqüência de eventos encadeados. Assim, as etapas são executadas uma
após a outra, sendo que, em alguns casos, algumas etapas ocorrem em
paralelo. Esse método de desenvolvimento parte do princípio de que o
levantamento de necessidades e o desenho da aplicação devem ser
exaustivamente estudados de forma a economizar esforços e evitar re-
trabalhos quando do seu desenvolvimento. Essa lógica é verdadeira para parte
do projeto do BI, porém não para todo ele, principalmente se pensarmos que o
BI deve apoiar o aproveitamento de oportunidades, e as oportunidades podem
138
não esperar até que a equipe de BI desenvolva uma aplicação de acordo com
uma metodologia tradicional. Contar com um ambiente de BI flexível o bastante
para acompanhar as mudanças que ocorrem no ambiente de negócios é um
dos fatores de sucesso de uma aplicação de BI.
Desse modo, Howson (2008) sugere uma abordagem de
desenvolvimento de aplicações mais ágeis, seguindo os doze princípios do
manifesto pelo desenvolvimento ágil de softwares (BECK et al., 2001), a saber:
1. nossa maior prioridade é satisfazer o cliente, mediante à rápida e
contínua entrega de softwares que tenham valor;
2. mudanças de requisitos são bem vindos, mesmo quando o
desenvolvimento já está em andamento;
3. disponibilizar trabalhos realizados com maior freqüência, de
preferência, em uma escala de tempo curto, por exemplo, a cada
duas semanas ou a cada dois meses;
4. a equipe da área de negócios e de TI devem trabalhar juntas,
diariamente, ao longo de todo o projeto;
5. construa projetos envolvendo pessoas motivadas; dê a eles os
recursos necessários e confie que o trabalho será executado com
êxito;
6. o mais eficiente e eficaz método de transmissão de informações
dentro de uma equipe de desenvolvimento é concretizado por
contato pessoal;
7. entregar softwares que funcionem é a principal medida de sucesso;
8. processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, os desenvolvedores e os usuários devem se
preparar para manter o ritmo indefinidamente;
9. atenção contínua à excelência técnica garantem agilidade e bom
desenho das aplicações;
10. simplicidade – a arte de maximizar o trabalho não realizado – é
essencial;
139
11. a melhor arquitetura, requisitos e desenho emergem de equipes
auto-organizadas;
12. a intervalos regulares, a equipe deve refletir em como se tornar mais
eficaz e ajustar o seu comportamento para isso.
A utilização do protótipo é muito útil nessa filosofia de trabalho.
Dessa forma, os requisitos são levantados, elabora-se um protótipo e avaliam-
se os resultados, que, por sua vez, geram novos requisitos, completando o
ciclo, até que a equipe de BI considere que a aplicação atende às
necessidades.
Essa abordagem do desenvolvimento ágil se contrapõe à
abordagem defendida por outros autores como, por exemplo, Barbieri (2001)
que argumenta que um dos fatores de sucesso de uma aplicação de BI é ter
objetivo bem definido, mesmo que leve tempo. Essas posições aparentemente
antagônicas podem ser conciliadas se considerar-se que Howson (2008)
considera que existem alterações que são mais caras, requerem mais tempo e
envolvem mais riscos do que outros tipos de alterações. Desse modo, a autora
classificou esses grupos em três tipos, como demonstra o quadro 7. Assim, é
possível que sejam efetuadas alterações mais ágeis, desde que envolvam
atividades relacionadas ao terceiro grupo que tem mais relação com o front-end
do BI, do que com as funções de infra-estrutura e de suporte.
140
Quadro 7 – Nível de complexidade das alterações no BI
Menor freqüência de
mudanças / maior risco
e custo
Mudanças periódicas
Mudanças freqüentes/
menor risco e custo
• Hardware
• Software
• Sistemas de
informação de origem
• Tabelas físicas
• Aplicações
customizadas
• Processos de ETL
• Arquivos de códigos e
hierarquias de
definições
• Estrutura da base de
dados OLAP
• Business views
• Relatórios e queries
• Dashboards
• Cálculo dos
principais
indicadores de
desempenho dentro
dos business view,
scorecard, ou
dashboards
Fonte: adaptado de Howson (2008, p. 141)
8. Organize a equipe de BI e peritos para o êxito na construção de
soluções com foco sobre a empresa.
Segundo Moss e Atre (2003), as iniciativas de BI, como um todo,
e as aplicações, de forma específica, devem apoiar as metas estratégias do
negócio; sem isso a iniciativa de BI poderá fracassar. Para Barbieri (2001), um
projeto de BI é realizado por versões ou etapas, e, assim sua equipe deve ser
coesa, motivada, fortemente associada ao projeto, com condições para a
realização de suas várias etapas. É necessário que a equipe conte com
pessoas conhecimentos técnicos. Pelo lado funcional que se escolham
analistas com grande conhecimento dos sistemas que darão origem aos dados
do data warehouse, pois isso facilitará as modificações, caso sejam
necessárias, para a captura de dados em sistemas ativos no âmbito
transacional.
Em relação à composição da equipe de BI, Moss e Atre (2003)
sugerem que seja integrada por um representante de negócio, e, caso o
responsável pela área de negócio resista à iniciativa de liberar uma pessoa
para participar em tempo integral ou mesmo parcial do projeto, isso poderá
141
indicar que esse executivo não enxerga a aplicação de BI como algo crítico e
importante para o seu departamento e para a empresa.
A posição de Ponniah (2001), em relação à formação da equipe
de BI, está em concordância com as de Howson (2008), Barbieri (2001) e Moss
e Atre (2003), para quem os aspectos do negócio devem ser enfatizados em
um projeto de BI em detrimento dos aspectos técnicos. A escolha do líder do
projeto deve também ser feita considerando-se sua orientação para os
negócios da empresa.
Atre (2003) ressalta a importância do leque de habilidades que a
equipe de BI deve possuir se comparado com outro projeto clássico de
desenvolvimento de sistemas de informação. Para ela, são necessárias
habilidades tanto técnicas quanto de negócio. A autora considera importante,
também, a experiência passada dos membros da equipe como uma forma de
garantir o sucesso, desde as primeiras aplicações.
9. Escolha as ferramentas apropriadas de BI que vão de encontro com as
necessidades do usuário e do negócio e que possa trabalhar no
âmbito de tecnologias padrões que a área de TI possa apoiar
eficazmente.
Ao contrário do senso comum, que considera que os usuários e a
equipe de TI dão muita importância à ferramenta de BI, Howson (2008)
demonstrou, por meio de sua pesquisa, que este não é o quesito técnico mais
relevante citado pelos respondentes, e sim a qualidade dos dados e a
confiança nas aplicações de BI, em primeiro e segundo lugar respectivamente.
Mesmo assim, Howson (2008) considera fundamental para o sucesso de uma
aplicação de BI, que sejam disponibilizadas para os usuários ferramentas de BI
que facilitem o acesso, o processo decisório e a ação, e ressalta, ainda, a
importância do papel da padronização nas aplicações de BI em mais de um
sentido. Na medida em que é muito difícil que uma única ferramenta de BI
142
contemple todas as funcionalidades desejadas pela empresa, tais como
dashboards, relatórios, planilhas, ferramentas de OLAP, entre outras, muitas
empresas passam a utilizar um leque de ferramentas diferentes no front-end,
muitas vezes, de diferentes fornecedores, o que acaba configurando um
ambiente sem padronização.
Para complicar ainda mais esse cenário, muitas empresas não
padronizam seus indicadores de desempenho. Assim, para um determinado
departamento, o cálculo da receita de vendas considera apenas a receita bruta,
enquanto que para outros se desconta da receita as devoluções e os
descontos, o que acaba gerando duas versões de uma mesma verdade.
Howson (2008) sugere que, em vista das diferentes necessidades dos usuários
das aplicações, não é possível padronizar o uso da ferramenta de BI em um
único tipo. Dessa forma, enquanto para um diretor o dashboard é mais útil,
para outro usuário de nível gerencial os relatórios e consultas são mais
eficientes. Desse modo, como não é possível padronizar em um único tipo a
ferramenta de BI, procura-se então utilizar as ferramentas de BI de um único
fornecedor.
Segundo as pesquisas de Howson (2008), 50% das empresas
que são bem sucedidas em suas aplicações de BI utilizam um único
fornecedor. Esse percentual cai para 34% entre as empresas que declaram ter
falhado em suas aplicações de BI. A figura 25 ilustra a relação entre a escolha
da ferramenta de BI e o êxito da aplicação.
A padronização dos indicadores na empresa também é importante
para que se tenha uma única versão de um determinado indicador de
desempenho. Assim, o indicador ‘receita de vendas’ terá o mesmo sentido para
todos dentro da organização.
143
Figura 25 – Relação entre a ferramenta de BI e o nível de êxito da aplicação
34%
40%
50%
34%
42%
39%
32%
18%
11%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Falha Éxito moderado Grande éxito
Front-ends customizados
Múltiplos fornecedores
Prioritariamente um único fornecedor
Fonte: adaptado de Howson (2008)
Atre (2003), também ressalta que, na maioria das empresas, as
aplicações de BI são construídas em diferentes fases, por diferentes equipes.
Cada equipe pode utilizar ferramentas que consideram mais adequadas,
aumentando, em muito, o conjunto de ferramentas díspares utilizadas para a
construção da aplicação de BI. Um maior número de ferramentas em um
projeto implica em uma maior complexidade da interoperacionalidade entre as
ferramentas, o que demanda uma maior necessidade de administração. As
equipes de BI devem procurar utilizar o menor número possível de ferramentas
para agrupar o maior número de funcionalidades no menor roteiro possível de
ferramentas. Afirmação semelhante é feita por Turban et al. (2007), que
afirmam que as diferentes tecnologias empregadas na aplicação de BI devem
estar bem integradas para o êxito da aplicação do BI.
144
Inmon (2002) vai mais além, quando sugere que a aquisição das
soluções de ERP e de BI de um mesmo fornecedor oferece várias vantagens,
entre elas, o fato de que o fornecedor provê toda a infra-estrutura necessária
para a construção do ambiente de BI, dentro do ambiente do ERP.
10. Considere também alguns outros fatores de sucesso, tais como a
cultura da empresa, a promoção das aplicações de BI, treinamento e a
utilizações de telas gráficas para apresentação das informações.
a) O papel da cultura: a cultura da empresa pode influenciar o
sucesso de uma aplicação de BI de diferentes formas. A principal delas é a
propensão da empresa em tomar decisões baseadas em fatos ou na intuição.
Não que a intuição não seja importante no processo decisório, ela é composta
basicamente do conhecimento tácito, fundamental para as empresas, mas, por
outro, é questionável se é possível tomar decisões acertadas sem consultar
primeiro os dados a respeito do assunto a ser decidido.
Howson (2008) demonstrou, em sua pesquisa, que entre as
empresas que alegam ter tido êxito em suas aplicações de BI, 73% declararam
tomar decisões baseadas em dados, enquanto que entre as empresas que
declararam que suas aplicações BI falharam esse percentual é de apenas 20%.
Segundo Howson (2008), as ferramentas de BI podem apenas apresentar os
fatos. Eliminar preconceitos e outros erros do processo decisório faz parte da
dinâmica da cultura da empresa e que determinará o bom uso que será feito do
BI.
Mesmo baseando-se em dados, é necessário tomar cuidado com
alguns aspectos relacionados ao processo decisório, como por exemplo, partir
de uma decisão pré-estabelecida e filtrar entre as informações disponíveis
apenas aquelas que estão alinhadas com nossas decisões.
145
Outra constatação efetuada por Howson (2008) é que as
empresas que se que declararam enxutas têm um percentual de 79% de êxito
em suas aplicações de BI em relação àquelas que afirmaram o contrário (47%).
Os demais autores consultados para a formação do padrão
referencial não citam os aspectos culturais como relevantes para o êxito de
uma aplicação de BI.
b) Promover sua aplicação de BI: além de Howson (2008),
Barbieri (2001) e Ponniah (2001) enfatizam a importância de comunicar aos
membros da organização o que está sendo desenvolvido e disponibilizado,
além dos benefícios que uma nova aplicação de BI pode oferecer. Os usuários,
provavelmente, não irão adotar, automaticamente, as aplicações de BI em seus
processos decisórios, a menos que estejam convencidos de que essas
aplicações os ajudarão no seu trabalho. Nesse sentido, a promoção e a
propaganda das aplicações são importantes para a conscientização do
potencial do BI por parte dos usuários. Barbieri (2001) sugere que se
promovam palestras de demonstração, envolvendo a alta gerência, para
convençê-los de que a relação custo/benefício do projeto (até aquele ponto) foi
favorável.
Para promover as aplicações de BI vale a máxima de que uma
imagem vale mais do que mil palavras, ou seja, a demonstração de uma
aplicação desenvolvida com informações reais da empresa tem um impacto de
convencimento muito maior do que longos textos ou explicações sobre a
importância e os benefícios que uma aplicação de BI pode oferecer.
c) Treinamento: Howson (2008) e Ponniah (2001) enfatizam a
importância do treinamento, e que a forma de aplicar esse treinamento deve
levar em consideração o público alvo, pois, assim, alguns usuários podem
necessitar apenas de uma introdução para operar o BI, enquanto outros
usuários podem necessitar de um treinamento mais completo, especialmente,
se pretendem efetuar as suas próprias consultas e relatórios.
146
d) Apresentação gráfica das informações faz parte do apelo do
BI, pois o componente visual torna as aplicações mais amigáveis e facilita a
visualização das informações, ao contrário do efeito causado por uma tela
repleta de números. Howson (2008) diz ser um processo natural dos usuários
quererem transcrever para as aplicações do BI os relatórios e telas que, até
então, eram utilizados. Esta fase pode ser importante para dar confiança aos
usuários, em relação às informações que estão sendo apresentadas, mas essa
etapa deve caminhar para uma próxima, em que essas informações sejam
apresentadas de forma gráfica.
2.2.10 Modelo teórico padrão
O modelo teórico utilizado como padrão neste trabalho foi o
descrito por Howson (2008), que se destaca por reunir, de forma esclarecedora
e elucidativa, o que considera ser os dez fatores críticos de sucesso para
aplicações de BI, além das preocupações com os aspectos técnicos,
essenciais a qualquer projeto que pretenda ter êxito.
Foram analisados, também, trabalhos de outros autores sobre o
assunto, são eles: Atre (2003), Barbieri (2001), Inmon (2002), Moss e Atre
(2003), Ponniah (2001) e Turban et al. (2007). O objetivo foi o de constatar se
os fatores críticos apresentados por Howson (2008), foram também citados por
outros autores de referência no assunto, ou se eram apenas preocupações
específicas do trabalho de Howson (2008).
O resultado da comparação demonstrou que de forma geral,
existem muitas similaridades entre os autores e que a maioria dos dez fatores
apresentados por Howson (2008) constam em maior ou menor destaque nos
demais trabalhos analisados, o que reforça sua validade. A tabela 1 demonstra,
de forma resumida, os dez fatores que serão utilizados como padrão para
análise dos dados do estudo de caso Petrom e os autores que fazem
147
referências semelhantes para cada um dos fatores em seus respectivos
trabalhos. A ordem dos fatores é a originalmente estabelecida por Howson
(2005).
Tabela 1 – Fatores críticos de sucesso de aplicações de BI
Fatores crítico de sucesso de aplicações de
Business Intelligence
Referências
teóricas
1. Meça o sucesso de múltiplas maneiras, utilizando medidas
objetivas quando disponíveis e identificando a importância
dos benefícios que não podem ser mensurados
quantitativamente.
HOWSON, 2008
2. Entenda os efeitos da sorte, oportunidade, frustração e
ameaça (em inglês, LOFT: Luck, Opportunity, Frustation e
Threat), para elevar sua aplicação de BI de um resultado
moderado para uma iniciativa de grande êxito.
HOWSON, 2008
PONNIAH, 2001
TURBAN et al., 2007
3. Conquiste o apoio executivo para garantir que o BI se
infiltre por todos os cantos da organização, para gerar
vantagens competitivas e valor dos negócios.
ATRE, 2003
BARBIERI, 2001
HOWSON, 2008
PONNIAH, 2001
TURBAN et al., 2007
4. Comece com uma fundação sólida e acrescente melhorias
de forma incremental e consistente para melhorar a
qualidade, amplitude e atualidade aos dados.
BARBIERI, 2001
HOWSON, 2008
PONNIAH, 2001
5. Alinhe a estratégia de BI com as metas do negócio,
garantindo que o pessoal de TI e de negócios trabalhem
mais como parceiros do que como adversários.
HOWSON, 2008
MOSS e ATRE, 2003
TURBAN et al., 2007
6. Encontre relevância para o BI para cada trabalhador da
empresa, assim como para clientes e fornecedores.
HOWSON, 2008
7. Utilize processos ágeis de desenvolvimento para entregar
capacidades e melhoramentos de BI de forma equivalente
à medida que ocorrem as mudanças nos negócios.
BARBIERI, 2001
HOWSON, 2008
8. Organize a equipe de BI e peritos para o êxito na
construção de soluções com foco sobre a empresa.
ATRE, 2003
BARBIERI, 2001
HOWSON, 2008
MOSS e ATRE (2003)
PONNIAH, 2001
9. Escolha as ferramentas apropriadas de BI que vão ao
encontro das necessidades do usuário e do negócio e que
possa trabalhar no âmbito de tecnologias padrões que a
área de TI possa apoiar eficazmente.
ATRE, 2003
INMON, 2002
HOWSON, 2008
TURBAN et al., 2007
10. Considere também alguns outros fatores de sucesso, tais
como a cultura da empresa, a promoção das aplicações de
BI, treinamento e a utilizações de telas gráficas para
apresentação das informações.
BARBIERI, 2001
HOWSON, 2008
PONNIAH, 2001
148
Neste capítulo, analisaram-se os sistemas ERP, as aplicações de
Business Intelligence e os elementos que os compõe e os completam.
Analisaram-se cada um dos dez fatores considerados críticos por Howson
(2008) para o sucesso de aplicações de BI, que, de forma geral, são também
endossados por outros autores, considerados como referência sobre o assunto.
Ao final, é apresentada a tabela 1, que demonstra os dez fatores considerados
críticos para o sucesso de aplicações de BI e os autores que fazem referências
semelhantes sobre cada um deles.
No próximo capítulo, apresenta-se a metodologia empregada para
a realização da pesquisa.
149
3 METODOLOGIA
3.1 Procedimentos metodológicos
Para se alcançar os objetivos propostos neste estudo, realizou-se
uma pesquisa qualitativa, de caráter exploratório, pois permite ao pesquisador
obter informações para conhecer melhor o assunto que aborda, sendo que,
para tanto, lança mão de consulta a artigos, referências bibliográficas tais como
livros e outros trabalhos acadêmicos e journals. A pesquisa não tem a
pretensão de generalizar os resultados, tendo em vista as limitações da
metodologia empregada e de sua abrangência, mas de contribuir para a
discussão do tema. De acordo com Yin (2005), o estudo de caso não
representa uma amostragem, seu objetivo é expandir e generalizar teorias
(generalização analítica) e não enumerar freqüências (generalizações
estatística).
Segundo Gil (1999), as pesquisas exploratórias são
desenvolvidas com o objetivo de gerar uma visão geral, de tipo aproximativo,
sobre determinado fato, cuja principal finalidade é o desenvolver, esclarecer e
modificar conceitos e idéias com o objetivo de permitir a formulação de
problemas mais precisos ou hipóteses pesquisáveis para futuros estudos.
Ainda segundo o autor, habitualmente, elas envolvem, entre outros métodos,
os estudos de caso.
No caso desta dissertação, a pesquisa exploratória se mostrou
adequada, por contemplar a possibilidade de não apresentar resultados
conclusivos e permitir o aprofundamento do tema com estudos posteriores e
discussões sobre ele.
150
A pesquisa é, também, qualitativa, pois segundo Richardson
(1985), os estudos desenvolvidos utilizando a metodologia qualitativa podem
descrever a complexidade de determinado problema, analisar a interação de
certas variáveis, compreender e classificar processos dinâmicos vividos por
grupos sociais, contribuir no processo de mudança de determinados grupos e
possibilitar, em maior nível e profundidade, o entendimento das peculiaridades
do comportamento dos indivíduos.
Para se alcançar os objetivos propostos, esta pesquisa foi
organizada em duas partes.
Na primeira parte, composta pelo primeiro e pelo segundo
capítulo é realizada uma revisão bibliográfica, com o objetivo de compreender a
abrangência e a complexidade dos elementos envolvidos no desenvolvimento
de aplicações de Business Intelligence, e os fatores que determinam o seu
sucesso. Para tanto, esta parte foi baseada em fontes secundárias, que
abrange a bibliografia publicada sobre o tema.
Na segunda parte, que corresponde ao quarto capítulo, a
metodologia escolhida foi a de estudo de casos, que, segundo Yin (2005), é a
estratégia mais indicada quando se pretende estudar acontecimentos
contemporâneos, sobre os quais não se podem manipular comportamentos
relevantes.
De acordo com Yin (2005), os estudos de caso podem ser
classificados em três tipos: exploratórios, explanatórios ou descritivos; e podem
ser categorizados por tipos de questões, a saber: ‘quem’, ‘o que’, ‘onde’, ‘como’
e ‘por que’. No caso deste trabalho, o assunto em questão recai sobre
questionamentos do tipo ‘como’ e ‘por que’. Portanto, a estratégia escolhida é a
de estudo de caso exploratório, por meio da análise de caso único holístico.
Segundo o autor, o estudo de caso único é justificável quando o pesquisador
deseja descrever uma intervenção e o contexto na vida real em que ela ocorre,
e holístico por envolver apenas uma unidade de análise, ao invés de abranger
várias unidades ou sub-unidades de análise.
151
Yin (2005) propõe cinco componentes importantes para um
estudo de caso, que são: as questões de um estudo de caso; suas
proposições; as unidades de análise; a lógica que une os dados às
proposições; e os critérios para interpretar as constatações. Com a finalidade
de atender a esses requisitos foi estabelecido um protocolo para o estudo de
caso que é descrito a seguir.
3.2 O protocolo para o estudo de caso
A verificação empírica será realizada por meio da elaboração de
um protocolo para estudo de caso, como definido por Yin (2005), como uma
das táticas principais para aumentar a confiabilidade da pesquisa do estudo de
caso e que se destina a orientar o pesquisador ao realizar a coleta de dados a
partir de um estudo de caso único (mesmo que o caso único pertença a uma
série de casos em um estudo de casos múltiplos). De forma geral, o protocolo
apresenta as seguintes seções: 1) visão geral do projeto do estudo de caso; 2)
procedimentos de campo; 3) questões do estudo de caso; e 4) avaliação dos
resultados.
3.2.1 Visão geral do projeto do estudo de caso
Quanto à visão geral do projeto do estudo de caso, no que diz
respeito às proposições teóricas, pode-se considerar que o objetivo principal
deste trabalho é o de estudar os fatores críticos de sucesso de aplicações de
BI, baseadas em um sistema ERP. Assim, o trabalho foi fundamentado no
entendimento do papel de cada elemento que compõe a arquitetura do
Business Intelligence, tais como dados, informações, conhecimento,
inteligência, sistemas, sistemas de informação e o processo de tomada de
152
decisão; e como isso se traduz no uso de aplicações de BI baseados no ERP
que tenham êxito.
• Pressupostos do estudo
Em concordância com Yin (2005), que afirma que o pesquisador
deve partir de algumas proposições que servem para orientá-lo onde procurar
as evidências relevantes, ao invés de tentar coletar ‘tudo’, definiram-se as
proposições abaixo, que serviram de guia para a elaboração da pesquisa:
• para o sucesso de uma aplicação de Business Intelligence, deve-se dar
atenção, não apenas aos aspectos técnicos de sua iniciativa, mas
também a outros itens mais abrangentes como os aspectos políticos,
culturais, de liderança, criatividade, entre outros;
• o Business Intelligence pode contribuir para o bom desempenho da
empresa, fornecendo informações corretas no momento e no formato
adequado. No entanto, em empresas que já fazem uso dessa
arquitetura, muitas áreas não o fazem por desconhecer seus benefícios
e funcionalidades, o que pode ser superado com uma estratégia de
disseminação de seus potenciais.
Na busca por respostas para as proposições acima descritas,
verificar-se-á se o caso estudado está em concordância com as teorias em que
foi embasada.
• Unidade de análise
A unidade de análise selecionada para o estudo de caso foi a
empresa Petrom – Petroquímica Mogi das Cruzes S.A., por reunir as condições
consideradas fundamentais para este estudo, que são as seguintes:
• a empresa tem o ERP já incorporado à sua rotina, pois foi implantado
em 2002, ou seja, já se encontra na fase da pós-implantação, de
153
maneira que os esforços existentes hoje visam maximizar os benefícios
que o ERP oferece;
• a empresa desempenha atividade industrial, e isso é importante visto
que o ERP nasceu voltado para atender a esse segmento de mercado.
Dessa forma, a aderência do software às necessidades da empresa é
maior do que se a empresa atuasse em outro ramo de atividade, apesar
de outros segmentos econômicos estarem fazendo uso desses
sistemas. O setor industrial é, ainda, o que melhor se beneficia do ERP;
• a empresa utiliza o BI como ferramenta para explorar a base de dados e
gerar informações de uso estratégico pela empresa;
• o projeto de BI é considerado, pela empresa, como bem sucedido.
3.2.2 Procedimentos de campo
Como procedimentos de campo, adotaram-se o exposto a seguir.
O primeiro procedimento foi o de obter a concordância da Petrom
– Petroquímica Mogi das Cruzes S.A., em participar como objeto de estudo de
caso. Isso ocorreu mediante a apresentação do projeto deste trabalho para o
diretor administrativo e para o responsável da área de TI, e, posteriormente,
para os demais entrevistados. Entregou-se, então, uma carta de apresentação
do entrevistador (Anexo I) à empresa.
O ponto central do protocolo previu a elaboração de questões do
estudo de caso, dirigidas ao pesquisador e não ao entrevistado, com questões
que funcionavam como lembretes das informações que precisavam ser
coletadas e o motivo para se realizar a atividade.
154
Em seguida, elaborou-se um questionário baseado nas pesquisas
de Howson (2008), para a condução das entrevistas, que, apesar de serem
baseadas nesse questionário, são do tipo ‘não estruturada’. Este tipo de
entrevista, segundo Lakatos e Marconi (2003), permite ao entrevistador ter a
liberdade para desenvolver cada situação na direção que achar mais
adequada, com perguntas abertas, que podem ser respondidas dentro de uma
conversação informal. Desse modo, as perguntas foram categorizadas de
forma a permitir a análise dos dados, baseando-se na adequação aos padrões.
Visto que o objetivo central deste trabalho é estudar os fatores
críticos de sucesso de aplicações de BI baseados em sistemas ERP, o critério
adotado para a seleção dos entrevistados foi o de que deveriam ser pessoas
usuárias do sistema ERP e/ou de aplicações de BI. Dessa forma, participaram
das entrevistas:
• o diretor administrativo;
• o gerente comercial;
• o supervisor financeiro-contábil;
• o contador; e
• o supervisor da área de TI.
A área de produção da Petrom não foi incluída no universo da
pesquisa por não ser nem usuária intensiva do ERP e nem das aplicações de
BI.
As entrevistas ocorreram no período de 22 de julho a 15 de
agosto de 2008, nas dependências da Petrom.
O anexo II apresenta o formulário de identificação do participante
e o questionário utilizado para a realização deste trabalho. As respostas foram
obtidas durante as entrevistas, quando o respondente, além de preencher o
questionário, discorria livremente sobre cada um dos itens, abordando,
inclusive, temas não mencionados no questionário, mas que consideravam
relevantes para o contexto.
155
3.2.3 Questões da pesquisa
Para se obter melhores resultados no processo de análise,
segundo Yin (2005), é necessário se concentrar nas questões mais
importantes, assim as questões do estudo de caso realizado na empresa
Petrom são:
• Como a Petrom obteve êxito na implementação de aplicações de BI?
• Por que a Petrom decidiu utilizar o BI baseado no ERP para o apoio ao
processo decisório estratégico?
• Que informações foram obtidas a partir do BI, que permitem à empresa
tomar decisões?
• Qual a formação e a orientação dos profissionais da Petrom que
permitiram construir aplicações de BI de sucesso?
• Quem utiliza o BI na Petrom?
• Quais os novos projetos para a expansão dessa prática?
3.2.4 Avaliação dos resultados
A estratégia adotada para a análise das evidências foi baseada
nas proposições teóricas, conforme proposto por Yin (2005), em que se utiliza
a técnica de adequação aos padrões teóricos para análise do estudo de caso.
Segundo Trochim (apud YIN, 2005), essa lógica compara um padrão empírico
com outro de base prognostica, e se os padrões coincidirem os resultados
podem ajudar o estudo de caso a reforçar a validade interna.
O padrão teórico a ser utilizado na análise dos resultados baseou-
se nas pesquisas realizadas por Howson (2008), em que foram relacionados os
dez fatores de sucesso considerados críticos para o sucesso de aplicações de
BI. Procuraram-se na literatura citações similares, de outros autores tidos como
156
referência sobre o tema, para embasar o referencial teórico proposto por
Howson (2008), sendo que o padrão referencial teórico resultante é
apresentado ao final do capítulo 2.
• Limitações do método
Vale mencionar que o estudo de caso e o método de entrevista
apresentam algumas limitações, a saber:
¾ o emprego do estudo de caso, como método de pesquisa, é,
normalmente, visto com ressalvas em relação a outras formas de
investigação, como os experimentos. A alegação é que o estudo de caso
fornece pouca base para se fazer generalizações. Em defesa dos
estudos de caso, Yin (2005) afirma que esse tipo de preocupação
configura preconceito para com a estratégia de estudo de caso. O autor
afirma, ainda, que os estudos de caso, da mesma forma que os
experimentos, são generalizáveis a proposições teóricas, e não a
populações e universos. Quanto às alegações de que os estudos de
caso tomam muito tempo e que produzem relatórios maçantes, o autor
atribui essa percepção a pesquisas conduzidas no passado, porém,
ressalta que nada indica que as futuras devam repetir tais erros e sugere
maneiras de tornar a análise dos dados mais atrativa.
¾ Deve-se estar atento, também, às limitações em relação às entrevistas.
Segundo Lakatos e Marconi (2003), as principais limitações das
entrevistas são:
a) dificuldade de expressão e comunicação de ambas as partes;
b) incompreensão por parte do informante do significado das
perguntas;
c) possibilidade de o entrevistado ser influenciado pelo
questionador;
d) disposição do entrevistado em dar as informações necessárias;
e) retenção de alguns dados importantes;
f) pequeno grau de controle sobre uma situação de coleta de dados;
157
g) dificuldades em realizar a pesquisa bem como tempo para a
atividade.
Neste capítulo, foi apresentado a metodologia que foi utilizada
para a pesquisa, no capitulo 4 o estudo de caso é apresentado e os dados
coletados são analisados.
158
4 ESTUDO DE CASO
Este capítulo apresenta o estudo de caso realizado na empresa
Petrom – Petroquímica Mogi das Cruzes S.A, que desenvolveu aplicações de
Business Intelligence para atender às necessidades de informações de seus
administradores e gerentes, adotando uma abordagem não convencional,
considerada adequada para que, efetivamente, o projeto de BI alcançasse
êxito. O estudo discute os motivos que levaram a empresa a optar por esta
abordagem, os fatores considerados relevantes pela empresa para que o
projeto de BI obtivesse êxito e a relação dessa abordagem com o modelo
referencial teórico.
Para tanto, o capítulo está estruturado da seguinte maneira:
inicialmente é apresentado um breve panorama do setor químico, uma
descrição da empresa Petrom – Petroquímica Mogi das Cruzes S.A, seu
histórico e suas iniciativas de ERP e BI. Na seqüência, serão apresentados os
resultados do estudo de caso referente aos fatores críticos de sucesso das
aplicações de BI, averiguados nas entrevistas com diretores, gerentes e
coordenadores de departamentos. A apresentação dos resultados está
classificada na ordem dos fatores críticos de sucesso, relacionados no modelo
teórico padrão, definido no capítulo 2.
4.1 Setor da indústria química
A Petrom é uma indústria petroquímica que pertence ao setor
químico. A característica principal da indústria petroquímica é a utilização de
um derivado de petróleo (a nafta) ou o gás natural como matérias-primas
básicas. Segundo relatório anual de 2007 da ABIQUIM – Associação Brasileira
159
da Indústria Química, o faturamento da indústria química brasileira está entre
as dez maiores do mundo, sendo estimado em U$ 101,6 bilhões em 2007,
tendo apresentado um crescimento de 12,2% em relação a 2006, se
comparado em reais. Desse total, U$ 54,2 bilhões correspondem aos produtos
químicos de uso industrial (nesse grupo está inserida a indústria petroquímica,
com petroquímicos básicos correspondendo a U$ 9,6 bilhões de faturamento
líquido).
4.2 Histórico e estrutura da empresa
A história do anidrido ftálico no Brasil data de 1950, quando um
grupo italiano trouxe a tecnologia de produção para o país, fundando a
Indústria Química de Produtos Ftálicos S.A. Três anos depois, a capacidade de
produção da empresa atingia a marca de 200 toneladas por ano. Em 1963, a
Vulcan Material Plástico S.A. incorporou a empresa Indústria Química de
Produtos Ftálicos S.A, que passou a constituir a sua divisão química. Sete anos
mais tarde, o controle acionário da Vulcan passou para a Hocker Chemical
(OXY), empresa de capital americano. A divisão química da Vulcan sofreu uma
cisão em 1987, dando origem à Ftaliquímica S.A., empresa com participação
da Unipar – União das Indústrias Petroquímicas que, em 1988, passou a se
denominar Oxipar Indústrias Químicas S.A., cuja composição acionária era
formada por 50% da Unipar (nacional) e 50% pela OXI (multinacional). Em
1994, ocorre a incorporação e a formação da Carbocloro Oxipar Indústrias
Químicas S.A., com a mesma composição acionária.
A Petrom – Petroquímica Mogi das Cruzes – surgiu em março de
1998, sucessora da Oxipar, a mais nova empresa integrante do grupo Cipatex.
A Petrom emprega, aproximadamente, 190 funcionários e já nasceu como
maior fabricante de anidrido ftálico da América Latina. A nova empresa iniciou
suas atividades com uma capacidade de produção anual de cerca de 60 mil
160
toneladas de anidrido ftálico, 65 mil toneladas de plastificantes e 5.600
toneladas de ácido fumárico. Investimentos posteriores aumentaram a
capacidade anual de produção dos plastificantes, com a incorporação da
fábrica NPC Indústrias Químicas, de 65 para 90 mil toneladas. Instalada em
uma área de 400.000 m
2
, na rodovia Mogi-Bertioga, a Petrom conta com uma
área produtiva de 17.000 m
2
.
A Petrom, empresa de capital nacional, localizada na cidade de
Mogi das Cruzes, com participação majoritária do grupo Cipatex, tem um
faturamento médio anual de R$ 200 milhões no ano.
Abaixo, encontra-se a relação de seus produtos e suas principais
aplicações:
• anidrido ftálico (sólido e fundido): utilizado na produção de
plastificantes, resinas de poliéster insaturado, resinas alquídicas,
pigmentos e corantes;
• plastificantes: utilizados na formulação de compostos flexíveis de PVC,
produzidos com resinas de emulsão (plastissóis - filmes espalmados,
brinquedos e vedantes) ou com resinas de suspensão (pó ou granulado,
filmes, mangueiras, calçados, perfis e revestimentos de cabos elétricos).
• ácido fumárico (grau técnico): utilizado na produção de resinas de
poliéster insaturado, resinas fumáricas e resinas de baixo ponto de fusão
(toner para copiadoras).
A empresa é estruturada em quatro áreas, a saber:
a) Diretoria Industrial, dividida em:
• Coordenação Técnica – responsável pela pesquisa e
desenvolvimento de novos produtos e processo industriais, bem
como pela emissão dos laudos necessários a certificar a
qualidade do produto desenvolvido;
161
• Coordenação de Produção – responsável, efetivamente, pelo
controle e coordenação do processo produtivo da empresa. Esta
área é subdividida em 3 setores, cada um para um dos produtos
produzidos:
¾ anidrido ftálico;
¾ ácido fumárico;
¾ plastificantes;
¾ além desses setores principais, existem outros dois:
controle de efluentes e controle de produção, os quais
prestam serviço aos setores acima citados;
• Coordenação de Manutenção – responsável pela manutenção
dos equipamentos (elétrica e mecânica) e instalações da planta,
incluindo a área cível.
b) Diretoria Comercial
Responsável pelas áreas de vendas, marketing, exportação e
importação.
c) Diretoria Administrativa, dividida em:
• Recursos Humanos – responsável por todo o gerenciamento da
parte de pessoal, segurança e enfermaria;
• Tecnologia da Informação – responsável pela administração dos
equipamentos, sistemas e aplicativos utilizados pela empresa,
excetuando o setor de produção, que é terceirizado;
• Administrativa – responsável pelo gerenciamento da parte de
custos, compras, almoxarifado e rotinas administrativas.
162
d) Diretoria Financeira, dividida em:
• Financeira – responsável pelas áreas financeira, cobranças e
contábil;
• Fiscal - responsável pelo controle da parte fiscal da empresa.
4.3 Histórico do sistema ERP e Business Intelligence na empresa
O caso da Petrom oferece uma perspectiva interessante da
condução do projeto de BI por diversos motivos. O principal é que a intenção
da utilização de aplicações de BI já existia desde a seleção do sistema ERP.
Além disso, a forma como o projeto foi conduzido contemplou, desde seu
princípio, a preocupação de considerar além dos aspectos técnicos, outros
fatores que a Petrom considerou fundamental para o sucesso das aplicações
de BI na empresa. Para a diretoria administrativa e para o supervisor do TI era
claro que se o projeto fosse conduzido da maneira clássica, como ocorre
normalmente com os projetos de TI, as chances de êxito seriam mínimas.
Assim, uma abordagem diferenciada, mais holística e participativa foi pensada
para assegurar a viabilidade do projeto.
Até 2002, a Petrom contava com um sistema
administrativo/financeiro desenvolvido internamente pelo grupo, na linguagem
Clipper, quando decidiu pela substituição por um sistema ERP. O objetivo era o
de se atualizar tecnologicamente de forma rápida, com um sistema de maior
flexibilidade, atualidade e abrangência, além de eliminar o problema da
manutenção do sistema legado. Iniciou-se, então, um processo de seleção do
um sistema ERP que atendesse a alguns requisitos básicos, a saber:
• o ERP deveria possuir histórico de uso em outras empresas do mesmo
setor da Petrom (setor químico);
163
• o ERP e seu fornecedor deveriam ter representatividade no mercado de
TI;
• o fornecedor deveria contar com uma estrutura que garantisse o suporte
à Petrom;
• o ERP deveria contar com ampla gama de funcionalidades;
• ter custo adequado às expectativas da Petrom;
• o ERP deveria utilizar o banco de dados Oracle, que a Petrom
considerou ser o melhor em termos de qualidade.
Com base nisso, duas empresas nacionais foram selecionadas, a
Datasul e a Logocenter, além de duas multinacionais, a BAAN e a SAP.
Segundo o supervisor de TI, além desses requisitos, a Petrom já tinha a
intenção de desenvolver aplicações de BI, tão logo o processo de implantação
do ERP fosse consolidado, pois o sistema legado não possuía relatórios
gerenciais e as informações gerenciais eram administradas por meio de
planilhas produzidas no Excel. Além disso, havia a cultura de que essas
informações, de certa forma, eram de ‘propriedade’ das áreas que as
produziam, cultura que se pretendeu eliminar com o desenvolvimento de
aplicações de BI. Sendo assim, um dos quesitos que foram considerados para
a seleção do sistema ERP, além dos já mencionados, foi o de que o fornecedor
deveria ter as condições de prover, também, os componentes para o
desenvolvimento de aplicações de BI, tais como ferramentas de BI, consultores
capacitados, formação do data warehouse, entre outros.
Os supervisores e os representantes das diversas áreas da
empresa pontuaram o conteúdo das apresentações de cada um dos módulos
dos sistemas, porém o fator decisivo para a escolha do ERP LOGIX (da
empresa Logocenter, atual Totvs) foi que o seu software já estava pronto para
utilizar o banco de dados Oracle, além de atender à maioria dos requesitos
básicos estabelecidos.
O sistema ERP Logix entrou em operação na empresa em março
de 2002, com a intenção de que após um ano de operação do sistema em
164
produção, fosse dado início ao projeto de desenvolvimento das aplicações de
BI. Esse tempo foi considerado ideal para que a empresa se habituasse ao uso
do sistema Logix e para a formação de um banco de dados que permitisse o
desenvolvimento de aplicações de BI. Entre os principais módulos, vale à pena
destacar que o de produção entrou em operação parcialmente, pois a empresa
entendeu que seria necessário adequar suas funcionalidades às necessidades
da Petrom. Assim, parte das atividades do módulo de produção permanecem
sendo administradas por meio de planilhas Excel. A empresa, recentemente,
retomou o processo de adequação do módulo para completar sua
implementação, pois considera fundamental sua integração ao sistema
corporativo ERP e sua contribuição para as aplicações de BI.
Decorridos dois anos da entrada em operação do Logix, a Petrom
deu início ao projeto de BI. O primeiro passo foi analisar o que havia de
disponível no mercado. Essa etapa foi concluída com a seleção da solução
oferecida pelo mesmo fornecedor da solução ERP Logix, que é o Logix BI.
Apesar de não ser o mais bem avaliado no quesito funcionalidades, entre as
ferramentas analisadas, os fatores decisivos para a sua escolha foram: a
integração natural com o ERP Logix; o fato de ser web-based; o processo ETL
baseado no ERP estar pronto para carga inicial do data warehouse; e as
facilidades de infra-estrutura já existentes na empresa, por causa do sistema
ERP Logix; segundo relatou o supervisor de TI da Petrom.
As principais aplicações de Business Intelligence desenvolvidas
até o momento foram elaboradas para uso corporativo, sendo utilizadas por
vários departamentos. São elas:
• demonstrativo de resultados;
• resultado das exportações;
• análises comerciais e
• análise dos custos fixos.
Essas aplicações disponibilizaram as informações, o que
possibilitou que os usuários criassem as suas análises, sendo que hoje é difícil
165
determinar o exato número de consultas e relatórios existentes, pois, a cada
momento, novas consultas e relatórios são gerados pelos departamentos,
conforme sua necessidade.
O processo de ETL que forma o data warehouse da empresa é
formado por programas desenvolvidos pelo fornecedor do sistema ERP Logix,
especialmente para essa finalidade. A Petrom, até o momento, não
desenvolveu nenhum programa específico para carga de dados no data
warehouse, com origem em sistemas legados, nem de outra fonte exterior ao
sistema de informação da empresa.
4.4 Análise dos dados e discussão dos resultados obtidos
Os 10 fatores críticos de sucesso das aplicações de Business
Intelligence da Petrom serão analisados por meio da comparação com o
padrão referencial teórico estabelecido no capítulo 2, conforme proposta de Yin
(2005), apresentada no capítulo 2.
1. Meça o sucesso de múltiplas maneiras, utilizando medidas objetivas
quando disponíveis e identificando a importância dos benefícios que
não podem ser mensurados quantitativamente.
Apesar de não existir na Petrom um procedimento específico para
medir o sucesso das aplicações de BI de forma quantitativa, todos os usuários
das aplicações de BI que foram entrevistados consideram o projeto como bem
sucedido. Howson (2008) propõe utilizar formas qualitativas para avaliar o
sucesso de uma aplicação de BI, além do ROI e do percentual de usuários
ativos em relação aos usuários potenciais. Assim, utilizou-se o critério
166
estabelecido por Moss e Atre (2003) para avaliar o sucesso da aplicação de BI,
que consiste das perguntas relacionadas abaixo. Para facilitar a leitura,
seguem as respostas encontradas nas entrevistas:
a) O patrocinador do projeto está satisfeito com as aplicações de BI?
Resposta: Sim, mas acredita que faltam desenvolver mais aplicações para
aumentar a abrangência e para que mais pessoas possam utilizá-las.
b) As pessoas de negócios gostam das aplicações de BI? Elas são fáceis
de serem utilizadas?
Resposta: Sim, de acordo com os principais usuários.
c) O que eles gostam? O que eles não gostam? Por quê?
Resposta: Os usuários, em geral, gostam da facilidade de uso e da
flexibilidade em criar relatórios e consultas. Não foi perguntado o que eles
não gostam.
d) Eles estão utilizando o repositório de metadados? Eles acham que o
repositório de metadados ajuda?
Resposta: O repositório de metadados não é utilizado.
e) O patrocinador pretende apoiar outras aplicações de BI?
Resposta: Sim, conforme relatou na entrevista é seu desejo apoiar novas
aplicações de BI para aumentar a abrangência de assuntos e expandir o
uso do BI na empresa.
Os entrevistados foram questionados sobre a forma com que
avaliam o sucesso das aplicações de BI na empresa. Quanto a isso, o contador
da Petrom fez o seguinte comentário:
167
para mim, a maneira mais eficaz de avaliar o êxito das aplicações
de BI é o fato de que as aplicações estão incorporadas às rotinas
da empresa, pois acredito que se as aplicações não fossem bem
sucedidas não teriam utilidade e seriam abandonadas, o que não
ocorre aqui na Petrom; ao contrário, existe demanda por novas
aplicações (Contador).
Segundo Howson (2008), não há uma maneira clara e exata para
se medir o sucesso do Business Intelligence. Dessa forma, o seu êxito é
mensurado pela percepção dos seus usuários, que devem participar
ativamente e sentir que são os donos do projeto. Por esse critério, pode-se
considerar que as aplicações de BI existentes obtiveram êxito até o presente
momento. Em vista das respostas colhidas entre todos os entrevistados,
considera-se que o caso Petrom se adequou ao padrão referencial.
2. Entenda os efeitos da sorte, oportunidade, frustração e ameaça (em
inglês, LOFT: Luck, Opportunity, Frustation e Threat), para elevar sua
aplicação de BI de um resultado moderado para uma iniciativa de
grande êxito.
Segundo Howson (2008), os fatores sorte, oportunidade,
frustração e ameaça devem ser relacionados com o fato de a empresa
aproveitar as situações favoráveis e desfavoráveis para obter ganhos, tanto
para a empresa quanto para as aplicações de BI. A sorte, a oportunidade, a
frustração e as ameaças têm o efeito de intensificar as ações estabelecidas.
Assim, se o projeto de BI é bem planejado e executado, esses fatores,
provavelmente, atuarão no sentido de reforçar o sucesso da aplicação, e o
mesmo vale para a situação contrária. Desse modo, o fato do antigo diretor
administrativo e do atual conhecer os benefícios que o BI pode oferecer e
serem genuínos patrocinadores do projeto de BI pode ser considerado como o
fator ‘sorte’ contribuindo para o sucesso da aplicação de BI.
Howson (2008) ressalta que a equipe de BI deve estar atenta às
oportunidades e ameaças, de maneira a aproveitá-las. Foi o que ocorreu na
168
Petrom, pois o supervisor de TI, em contato com o fornecedor do Logix, obteve
a oportunidade de testar a ferramenta Logix BI por dois meses, sem custo do
produto, apenas arcando com as horas de um consultor externo por uma
semana para o treinamento e o desenvolvimento de aplicações que foram
utilizadas como forma de propaganda para a divulgação do BI na Petrom. A
oportunidade não foi desperdiçada e duas aplicações foram criadas no decorrer
dessa semana, que são: o faturamento por grupo de produto e o custo fixo.
Em relação às questões ligadas às oportunidades e ameaças, o
Bi pode agir sobre esses elementos disponibilizando dados para a criação do
conhecimento necessário para o processo decisório. Uma forma apropriada
para avaliar esses fatores é analisando o impacto no BI no processo decisório
da Petrom. Dessa forma uma abordagem interessante sobre a utilização do BI
no processo decisório foi descrita pelo gerente comercial da Petrom, que
afirmou que:
a área comercial utiliza as informações disponíveis no BI para
aferir se as ações tomadas no passado estão apresentando os
resultados esperados. Caso isso não se confirme, novas ações
são adotadas para corrigir o curso dos acontecimentos (Gerente
comercial).
Isso demonstra que as informações obtidas por meio do BI são
utilizadas para monitorar as ações adotadas no passado o que reflete nas
ações futuras. Essa abordagem do conhecimento é descrita por Michaud
(2006), para quem o conhecimento tem dupla função relativa à linha do tempo:
num primeiro momento, o conhecimento ajuda a entender partes de realidades
diversas tanto do passado quanto do presente; e, num segundo momento,
ajuda a construir alterações de partes dessa realidade, criando uma nova
realidade. Esse ciclo, na verdade, é uma espiral temporal, já que a nova
realidade gera novos dados, alterando, por sua vez, as informações e o
conhecimento anterior. Dessa maneira, o BI é utilizado na Petrom para
monitoramento das ações adotadas e influenciar as decisões futuras,
169
permitindo o aproveitamento de oportunidades e a tomada de ações corretivas
em relação às ameaças.
O gerente comercial da Petrom ressaltou, porém, que as
informações obtidas por meio do BI são parte do conjunto de informações
necessárias para o processo decisório, pois a tomada de decisões é baseada
também em outros elementos, tais como mudanças futuras no mercado,
insights, experiências pessoais e outras fontes de informações não
estruturadas.
Apesar de não existirem ainda aplicações financeiras
disponibilizadas no BI, segundo o supervisor contábil-financeiro, o BI pode
contribuir de forma mais ampla se as aplicações a serem desenvolvidas para a
área financeira possibilitarem a montagem de cenários. Isso será útil
especialmente para a análise de impacto de ações no fluxo de caixa. Como
exemplo, citou que a empresa pode optar por comprar matérias primas
nacionais ou importadas, e que a origem da matéria prima altera a forma de
pagamento, o que afeta o fluxo de caixa. A montagem de cenários pode agilizar
o processo que a empresa realiza para mudar o seu perfil de desembolso,
antecipando ou postergando pagamentos de forma a adequar o fluxo de caixa.
Em relação à frustração, nota-se que ela foi amplamente
aproveitada em favor do BI, visto que alguns usuários demandavam
informações que eram parcialmente atendidas por meio dos relatórios do ERP
e do Crystal Report (software gerador de relatórios). No entanto, estavam
frustrados, pois necessitavam de uma solução mais dinâmica e interativa, ou
seja, o BI.
Dessa forma, pode-se considerar que o fator LOFT é levado em
consideração pela equipe de TI, como sugerido por Howson (2008), e,
portanto, nesse quesito, o sucesso das aplicações de BI se adequou ao padrão
referencial.
170
3. Conquiste o apoio executivo para garantir que o BI se infiltre por todos
os cantos da organização para gerar vantagens competitivas e valor
dos negócios.
O projeto de BI na Petrom já constava dos planos do diretor
administrativo, desde a decisão pela aquisição do ERP, em substituição ao
sistema legado. A intenção de desenvolver aplicações de BI foi motivada, em
parte, pela experiência que o diretor administrativo anterior ao atual trazia de
outras empresas. Assim, a diretoria administrativa da Petrom, na pessoa do
antigo diretor e na do atual, patrocinou fortemente o desenvolvimento das
aplicações de BI. Segundo o diretor administrativo, o apoio às aplicações de BI
se deve ao fato de que elas possibilitam a realização de novas consultas e
análises, de forma fácil e interativa, além de reunirem informações de diversas
áreas. O BI contribui para a obtenção de informações de forma autônoma, pois
permite que os próprios usuários apliquem filtros sobre as informações que
desejam, alterando a visualização da análise, além de contar com o suporte de
operações como o drill-down, drill-up, slice, dice; e outras funcionalidades do
OLAP, o que não é possível de ser realizado quando se utilizam relatórios e
consultas pré-definidos.
Além disso, o diretor administrativo ressaltou a importância da
flexibilidade que o BI oferece para que os próprios usuários definam as
melhores formas da apresentação dos resultados liberando dessa tarefa a área
de TI para se concentrar nas atividades relacionadas com o negócio da
empresa e não na criação de centenas de relatórios e consultas que surgem
com novas necessidades. Mesmo levando-se em consideração que o BI não
elimina a participação da área de TI na criação das novas aplicações, a
avaliação é que o tempo gasto para o desenvolvimento é muito menor e os
resultados são melhores do que o desenvolvimento de programas específicos
de consultas e relatórios.
Segundo relato do supervisor de TI, o apoio da diretoria
administrativa foi essencial para o êxito das aplicações de BI na Petrom. Esta
afirmação está em concordância com a pesquisa realizada por Howson (2008),
171
que afirma ser este o fator mais importante para o sucesso de uma aplicação
de BI. Além disso, a autora alerta para o fato de que conseguir o apoio do
executivo certo para apoiar o desenvolvimento de aplicações de BI não é tarefa
fácil, pois é necessário que esse ‘patrocinador’ acredite e entenda o valor da
informação e consequentemente, do BI para a empresa. Nesse sentido, a
Petrom teve dupla vantagem: não só o diretor administrativo anterior conhecia
os benefícios que o BI pode oferecer devido a sua experiência em outras
empresas, como também o atual conhece e entende esses benefícios e, por
isso, continuou e pretende ampliar o desenvolvimento e o uso das aplicações.
Howson (2008) afirma ser fundamental a presença de um
‘patrocinador’ para definir pendências, esclarecer dúvidas do negócio e
promover o projeto, em concordância com Barbieri (2001), Turban et al. (2007),
Atre (2003) e Ponniah (2001). Esse fato foi constatado na Petrom de diversas
formas, e para exemplificar podem-se citar duas situações:
• existe a preocupação da diretoria administrativa e do supervisor de TI
em unificar os indicadores da empresa, de forma que um indicador
signifique o mesmo para toda a empresa. A padronização dessa
informação na empresa pode ser entendida como uma forma de resolver
um problema corporativo e de dirimir dúvidas em relação ao real
significado dos indicadores, além de exigir do patrocinador influência e
credibilidade em relação às demais áreas, o que permitirá que mais
pessoas utilizem o BI. Esse papel é descrito pela literatura consultada
como sendo inerente ao patrocinador, o que demonstra a adequação ao
padrão estabelecido para este quesito;
• outro quesito importante é a constante preocupação com a qualidade
dos dados. Para resolver esse problema, as qualidades do patrocinador,
descritas acima, também são fundamentais, pois, normalmente, atuar
sobre a qualidade dos dados significa efetuar correções e ajustes nos
processos que originam esses dados, o que testará o trânsito e a
172
influência do patrocinador sobre outras áreas, além de exigir
conhecimento sobre o assunto para poder sugerir alterações.
Sobre a infiltração do BI nas diversas áreas da empresa,
perguntou-se ao diretor administrativo sua opinião sobre a abrangência dos
assuntos abordados hoje nas aplicações de BI da empresa. A resposta foi que
foram disponibilizadas importantes aplicações contendo assuntos relevantes.
Porém, é importante ressaltar que ‘faltam assuntos a serem incluídos no BI’, e
que a intenção da empresa é a de expandir as possibilidades por meio do
desenvolvimento de novas aplicações, e, assim, permitir que mais pessoas
utilizem o BI para obter as informações de que necessitam. O diretor
administrativo acrescentou que, com a inclusão da área de produção no uso do
ERP, mesmo que mediante customizações, o conjunto de assuntos tratados no
BI será acrescido de importantes informações para a empresa.
Perguntou-se também ao diretor administrativo quem seria o
público alvo do BI na Petrom. A resposta foi de que o BI destina-se,
preferencialmente, a supervisores, gerentes e diretores, pois para os usuários
mais operacionais, existem opções mais adequadas no próprio sistema ERP,
mas ressaltou que não está descartada a possibilidade de disponibilizar no
futuro o BI para uso mais operacional, principalmente, no caso do
desenvolvimento de aplicações mais departamentais do que corporativas como
é o caso hoje. Porém, a princípio, o objetivo é permanecer voltado para atender
a média e alta direção da empresa.
Em relação a este fator, as informações coletadas demonstram
que o caso Petrom está em total concordância com o padrão referencial.
4. Comece com uma fundação sólida e acrescente melhorias de forma
incremental e consistente para melhorar a qualidade, amplitude e
atualidade aos dados.
173
A estratégia adotada pela diretoria administrativa e pela área de
TI para o projeto de BI da Petrom foi a de criar, inicialmente, algumas
aplicações em conjunto com a área de negócios, que foram apresentadas às
demais áreas. Isso, além de atender à demanda por essas informações, serviu
como elemento de divulgação do BI na empresa, visto que não havia demanda
por aplicações do BI pelas demais áreas naquele momento. Uma das primeiras
ações tomadas para o desenvolvimento dos aplicativos foi a de padronizar os
índices de desempenho que seriam contemplados pelas aplicações de BI que
foram desenvolvidas. Isso ocorreu, por exemplo, com o ‘DRE – Demonstrativo
de Resultados’. A área comercial utilizava as informações do DRE com
algumas alterações em relação ao restante da empresa. Assim, para o
desenvolvimento da aplicação do DRE, foram estabelecidas as diferenças
entre esses dois pontos de vista, e duas aplicações foram desenvolvidas: uma
para atender a empresa e a outra para atender às necessidades específicas da
área comercial. A base de dados no data warehouse, no entanto, é a mesma e
tem origem no módulo contábil do Logix.
O desenvolvimento inicial das aplicações de BI foi realizado em
conjunto com a consultoria externa da Logocenter, que desenvolveram duas
aplicações: ‘faturamento de produtos’ e ‘custo fixo’. Essas aplicações foram,
posteriormente, incrementadas à medida que passaram a ser rotineiramente
utilizadas pelas diversas áreas da empresa.
Segundo o gerente comercial da empresa, a solidez e a
confiabilidade das informações foram fundamentais para o êxito das primeiras
aplicações de BI, e sua conseqüente divulgação. Essa confiabilidade se deve
ao fato dos dados terem origem no sistema ERP, e, assim, a confiança
existente na consistência das informações no ERP é transferida para as
aplicações de BI, sem manipulações, o que poderia acarretar distorções e
erros, ou seja, as informações disponibilizadas no BI são fidedignas em relação
às existentes no sistema de gestão da empresa, apesar das consolidações e
processos necessários para a formação do data warehouse. Comentário
semelhante foi feito pelo contador da Petrom.
174
As aplicações desenvolvidas foram apresentadas para cada uma
das áreas da empresa, e, assim, os possíveis usuários dessas informações
tomaram conhecimento das aplicações existentes e de suas possibilidades.
Isso fez com que novas aplicações fossem, posteriormente, desenvolvidas, o
que ampliou o uso do BI na empresa.
Uma das perguntas efetuadas aos entrevistados foi se eles
consideravam que o projeto de BI estava bem fundamentado. O diretor
administrativo respondeu o seguinte:
Considero que o projeto de BI foi bem fundamentado, pois os
objetivos do projeto para a primeira fase foram alcançados; o
projeto gerou o retorno esperado e se expandiu além do que era
esperado; um bom exemplo foram as aplicações desenvolvidas
com informações da área comercial (Diretor administrativo).
Assim, o caso Petrom está em concordância em relação à abordagem
recomendada por Barbieri (2001), Howson (2008) e Ponniah (2001), que é de
iniciar o desenvolvimento com uma fundação sólida e efetuar ampliações
futuras.
5. Alinhe a estratégia de BI com as metas do negócio, garantindo que o
pessoal de TI e de negócios trabalhem mais como parceiros do que
como adversários.
Em virtude do quadro enxuto da Petrom, a equipe de BI é
composta da seguinte maneira: um representante da área de TI e um
representante das áreas de negócio. Desse modo, sempre que se decide pelo
desenvolvimento de uma nova aplicação, a equipe de BI se reúne e todos
trabalham juntos. O representante da área de TI é o próprio supervisor da área,
pois foi ele quem recebeu da Logocenter o treinamento para a construção de
aplicações de BI. A formação técnica (o supervisor tem graduação na área de
TI e é pós-graduado pela USP no curso de MBA em Tecnologia da Informação)
175
do supervisor da área contribui muito para o entendimento da arquitetura do BI
e para o desenvolvimento das aplicações. Porém, segundo o próprio supervisor
de TI, desde o início do projeto, houve o entendimento de que as aplicações
não deveriam ter uma abordagem técnica, e sim voltada para o negócio da
empresa, sob o risco de serem entendidas mais como uma experimentação da
área de TI do que como uma solução de negócios. A estrutura enxuta da
empresa contribui para que o supervisor da área de TI conheça bem a
funcionalidade das diversas áreas de negócio, o que contribuiu para uma maior
integração entre as áreas de TI e de negócios. Outro aspecto importante é que
o supervisor da área de TI está na empresa há dez anos, seis deles na área de
TI.
Não foi relatado nas entrevistas nenhum tipo de divergência entre
a área de TI e a de negócios, por nenhuma das partes. Pelo contrário, o
conhecimento da empresa pelo supervisor de TI é reconhecido pelas áreas de
negócios o que acaba se refletindo em certa liderança e confiança mútua em
relação à condução do projeto e nos resultados que se pretendem alcançar,
não sendo constatado na Petrom as dificuldades relatadas por Howson (2008),
por algumas empresas, em criar a parceria TI-negócios. Além disso, o projeto
de BI é de responsabilidade da diretoria administrativa, que tem a preocupação
de dar ênfase ao alinhamento do projeto de BI, com as metas do negócio da
empresa.
Assim, pode-se considerar que a integração da área de TI com a
de negócios está em concordância com o padrão referencial estabelecido.
6. Encontre relevância para o BI para cada trabalhador da empresa,
assim como para clientes e fornecedores.
Segundo Howson (2008), encontrar relevância para o BI significa
descobrir maneiras de utilização do BI que simplifiquem o trabalho dos usuários
176
da informação, de forma a torná-lo melhor. A preocupação da equipe de BI foi a
de disponibilizar nas aplicações as informações que eram demandadas pelas
diversas áreas da empresa e, assim, os usuários poderiam moldar, por meio
dos filtros, relatórios e consultas da ferramenta de BI, as informações da
maneira que achassem mais conveniente.
Para o gerente comercial da Petrom, o BI trouxe liberdade em
relação à obtenção das informações originárias no sistema ERP, pois, com o BI
ele passou a não depender de terceiros para ter acesso às informações de que
necessita para realizar seu trabalho. Antes, ele tinha que solicitar e aguardar o
recebimento de relatórios específicos. Outro tópico ressaltado pelo gerente
comercial está relacionado à flexibilidade da ferramenta de BI que permite que
ele obtenha as informações desejadas e que efetue pequenas alterações nos
relatórios e nas consultas existentes. Além disso, o fato de poder obter a
mesma informação sob diferentes aspectos ajuda muito, e isso é possível pela
utilização de filtros e da capacidade da ferramenta de BI de disponibilizar dados
de forma multidimensional. Assim, é possível acessar informações sobre o
faturamento sob pontos de vista diferentes, por exemplo: por tipo de mercado
(interno, externo), por produto, por cliente, etc. Outro item ressaltado pelo
gerente comercial foi o fato da atualização dos dados, que ocorre de forma
automática com um intervalo de horas, apesar de que as análises devem ser
realizadas contemplando-se longos períodos de tempo. Saber que os dados
são atuais tem muita importância e relevância.
Todos os entrevistados disseram que as aplicações de BI da
Petrom disponibilizam as informações de maneira apropriada para o seu uso e
que a ferramenta BI-Logix é de fácil manuseio.
Visto que o desenvolvimento das aplicações é definido, em
primeiro lugar pela demanda, e em seguida pela relevância, considera-se que o
projeto de BI da Petrom está, parcialmente, em concordância com o padrão
referencial estabelecido. Se o critério de desenvolvimento fosse o de
relevância, provavelmente a área financeira já contaria com aplicações de BI.
177
7. Utilize processos ágeis de desenvolvimento para entregar capacidades
e melhoramentos de BI de forma equivalente, à medida que ocorrem as
mudanças nos negócios.
O projeto de BI na Petrom não seguiu a metodologia clássica de
desenvolvimento de sistemas que estabelece uma seqüência de eventos e
ações a serem realizadas. Ao contrário, para não deixar passar o momento e
perder a oportunidade de iniciar o projeto de BI, adotou-se uma abordagem
diferenciada que privilegiou a rapidez.
Essa abordagem foi necessária, pois a estratégia adotada para o
projeto de BI da Petrom foi o de disponibilizar o mais rápido possível aplicações
que servissem para divulgar o potencial do BI e de suas possibilidades para a
empresa. Assim, ao escolher a ferramenta Logix BI, a Petrom levou em
consideração alguns aspectos importantes para rápido desenvolvimento e
utilização das aplicações de BI.
O primeiro deles foi que ao optar pelo Logix BI a empresa não
precisou se emprenhar nas atividades de desenho e desenvolvimento do ETL,
visto que essa função já vem pronta com a ferramenta de BI. Bastou apenas
que fossem processadas para que ocorresse a carga do data warehouse. Essa
tarefa foi simples, visto que, na época, a Petrom já utilizava o ERP Logix como
sistema integrado de gestão, pelo menos há dois anos, o que permitiu a
carregar o data warehouse, com dados de forma rápida. O Logix BI possui as
rotinas para extrair, processar e carregar o data warehouse com informações
padronizadas de diversas áreas, a saber: controladoria, finanças, comercial,
suprimentos, recursos humanos e manufatura. Também é possível criar e
alimentar novas tabelas no data warehouse, com outras informações do
178
sistema ERP ou informações externas. No entanto, no primeiro momento a
Petrom optou por explorar as informações cujo processo de ETL já contempla.
O segundo ponto para o rápido desenvolvimento das aplicações é
que o Logix BI foi descrito pelos entrevistados como de fácil manuseio e
utilização, mesmo que em detrimento de certa sofisticação que outras
ferramentas de front-end possam oferecer. Esse fator parece ter atuado como
uma vantagem da ferramenta Logix BI em relação a outras, pois, talvez, se a
Petrom tivesse optado por uma ferramenta extremamente sofisticada e
complexa o tempo de desenvolvimento, treinamento e de utilização do BI
tivesse sido maior, inclusive, o que poderia ter comprometido os resultados
desejados.
O terceiro ponto, em relação à estratégia adotada pela Petrom,
para o rápido desenvolvimento de suas aplicações foi abordagem utilizada em
relação ao desenvolvimento das aplicações piloto, desenvolvidas pela equipe
de BI em conjunto com a consultoria da Logocenter. O desenvolvimento com a
consultoria da Logocenter das aplicações piloto, misturou treinamento e
desenvolvimento e resultou na liberação para os usuários no prazo de uma
semana, das seguintes aplicações: ‘faturamento de produtos’ e ‘custo fixo’.
O quarto ponto importante, em relação ao desenvolvimento de
aplicações, é o extensivo uso do protótipo como método de desenvolvimento.
Conforme sugerido por Howson (2008), a equipe de BI efetua o levantamento
dos requisitos básicos da aplicação e desenvolve o protótipo, e, em seguida, o
protótipo sofre vários ajustes no decorrer dos testes até atingir o grau de
excelência pretendido pela equipe de BI. Mesmo após a sua publicação, a
aplicação está sujeita a correções e melhorias.
Howson (2008) alerta que o tipo de desenvolvimento ou alteração
pode ser mais caro e demorado dependendo de onde essa intervenção ocorra,
conforme demonstra o quadro 7. No caso Petrom, tanto a infra-estrutura – a
mesma utilizada pelo sistema ERP – quanto os principais processos de ETL já
vêm pronto com a ferramenta de BI. Não houve desenvolvimento até o
179
momento de processos específicos de ETL para carga de dados fora da base
de dados de ERP Logix, e, assim, a maioria dos esforços da equipe de BI se
concentrou no desenvolvimento do front-end, o que contribuiu para a agilidade
do processo.
Por último, Howson (2008) sugere uma abordagem de
desenvolvimento de aplicações mais ágeis seguindo os princípios do manifesto
pelo desenvolvimento ágil de softwares (BECK et al., 2001). Desse modo, no
levantamento realizado na Petrom, procurou-se identificar se esses princípios
estão presentes mesmo que de forma não intencional. O resultado é
demonstrado na tabela 2, que demonstra o relacionamento entre os princípios
e sua presença na empresa. Os princípios presentes são assinalados com
duas possibilidades: X (Presente) e PA (Parcialmente); no caso dos princípios
ausentes também foram previstas duas possibilidades legendadas como: NA
(Não avaliado) e NI (Não identificado).
180
Tabela 2 – Princípios do manifesto pelo desenvolvimento ágil identificados na Petrom
Princípios do manifesto pelo desenvolvimento ágil de
softwares
Presente Ausente
1. Nossa maior prioridade é satisfazer o cliente, mediante a
rápida e contínua entrega de softwares que tenham valor.
PA
2. Mudanças de requisitos são bem vindos mesmo quando o
desenvolvimento já está em andamento.
X
3. Disponibilizar trabalhos realizados com maior freqüência, de
preferência em uma escala de tempo curto, por exemplo: a
cada duas semanas ou a cada dois meses.
NI
4. O pessoal da área de negócios e de TI devem trabalhar
juntos diariamente ao longo de todo o projeto.
X
5. Construa projetos envolvendo pessoas motivadas, dê a eles
os recursos necessários e confie que o trabalho será
executado com êxito.
X
6. O mais eficiente e eficaz método de transmissão de
informações dentro de uma equipe de desenvolvimento é
através do contato pessoal.
X
7. Entregar softwares que funcionem é a principal medida de
sucesso.
X
8. Processos ágeis promovem desenvolvimento sustentável.
Os patrocinadores, os desenvolvedores e os usuários devem
estar preparados para manter o ritmo indefinidamente.
X
9. Atenção contínua a excelência técnica garantem agilidade e
bom desenho das aplicações.
X
10. Simplicidade – a arte de maximizar o trabalho não realizado
– é essencial.
X
11. A melhor arquitetura, requisitos e desenho emergem de
equipes auto-organizadas.
X
12. A intervalos regulares, a equipe deve refletir em como se
tornar mais eficaz e ajustar o seu comportamento.
P
O item 1 foi considerado parcial, pois não foi identificado no
estudo de caso identificar nenhuma ação intencional para a entrega regular de
novas aplicações, pois o desenvolvimento ocorre em função da demanda. O
item 3, pelo mesmo motivo, foi considerado não identificado, por não haver
uma política de entregas contínuas e freqüentes. O item 12 foi considerado
parcial, pois essa reflexão não ocorre a intervalos regulares e nem de forma
oficial.
Em vista do demonstrado, considera-se que, no quesito de
entregas ágeis de desenvolvimentos de aplicações, o projeto de BI da Petrom
está em concordância com o padrão referencial estabelecido.
181
8. Organize a equipe de BI e peritos para o êxito na construção de
soluções com foco sobre a empresa.
Nas entrevistas realizadas não se identificou resistência por
nenhuma das áreas em contribuir para a formação da equipe de BI. Sempre
que se planejava uma nova aplicação, a equipe de BI era formada por um
integrante da área de TI e um ou mais da área de negócios. Conforme descrito
por Barbieri (2001), um projeto de BI é realizado por versões ou etapas, assim
a equipe de BI deve ser coesa, motivada, fortemente associada ao projeto, com
condições para a realização de suas várias etapas.
Nesse aspecto, o fato da estrutura da Petrom ser enxuta
contribuiu (mesmo levando-se em consideração, que o fato de ser uma
empresa enxuta não garante a presença de tais fatores), pois a comunicação
entre os membros da equipe de BI é ágil e pessoal, assim como a
comunicação da equipe de BI com as áreas de negócio. Também contribuiu o
fato dos participantes da equipe de BI conhecerem profundamente as
operações das áreas sobre as quais as aplicações foram desenvolvidas, isso
vale também para o integrante do TI. O conhecimento técnico do representante
de TI da equipe de BI também foi fundamental para se alcançar os resultados
desejados.
A composição da equipe de BI, apesar de pequena, segue as
recomendações de Moss e Atre (2003), que sugerem que seja integrada por
um representante de negócio, além dos técnicos de TI. Está de acordo também
com Ponniah (2001), Barbieri (2001) e Moss e Atre (2003), para quem o projeto
de BI deve ser centrado no negócio em detrimento dos aspectos técnicos. A
escolha do líder do projeto deve também ser feita considerando-se sua
orientação para os negócios da empresa, o que aparece também em
concordância com Atre (2003) que ressalta a importância do leque de
habilidades que a equipe de BI deve possuir, se comparado com outro projeto
clássico de desenvolvimento de sistemas de informação.
182
Dessa forma, considera-se que, no que tange à equipe de BI, o
projeto de BI da Petrom está alinhado ao padrão referencial.
9. Escolha as ferramentas apropriadas de BI que vão ao encontro das
necessidades do usuário e do negócio e que possa trabalhar no
âmbito de tecnologias padrões que a área de TI possa apoiar
eficazmente.
A utilização do Logix BI está de acordo com as recomendações
de Howson (2008), Atre (2003) e Turban et al. (2007), que sugerem que é
recomendável padronizar as ferramentas de BI para as diferentes tecnologias
empregadas na aplicação de BI, para que estejam integradas, auxiliando no
êxito das aplicações de BI. Segundo Inmon (2002), há vantagens para as
empresas que optam por adquirir, do mesmo fornecedor do ERP, a arquitetura
necessária para a construção das aplicações de BI, pois este provê toda a
infra-estrutura, poupando muito tempo da empresa nas fases de desenho e
desenvolvimento do data warehouse e ETL. No caso da Petrom, a empresa
optou, também, por utilizar a ferramenta de BI da Logocenter, como única
solução a ser utilizada para o front-end. Isso representou vantagem em termos
de custo e tempo para a Petrom, apesar da literatura alertar para o fato de que
não se deve confundir padronização com única solução, pois cada tipo de
usuário tem necessidades diferentes, no que diz respeito ao tratamento da
informação. Nesse sentido, supervisores, gerentes e diretores têm diferentes
necessidades de informação. Segundo o levantamento realizado no Petrom, a
empresa pode estar começando a sentir essa necessidade, o que pode ser
observado no relato do supervisor financeiro-contábil, que afirma que seria de
grande utilidade se o Logix BI permitisse análises preditivas e montagem de
cenários, pois, assim, seria possível, por exemplo, avaliar o impacto no fluxo de
caixa na tomada de certas decisões. Isso pode indicar que no futuro a empresa
talvez tenha que pensar em utilizar ferramentas de BI de outros fornecedores
para completar as funcionalidades de que necessita.
183
Em relação ao suporte da área de TI, a utilização de tecnologias
do mesmo fornecedor facilita a solução dos problemas, fazendo com que não
seja necessário recorrer a diversos fornecedores. Geralmente, quando se
possui uma arquitetura formada por componentes de origens diferentes, é
comum que um fornecedor atribua a culpa de um problema ao outro, o que
dificulta a sua solução. A padronização da mesma infra-estrutura para o ERP e
para o BI também contribuiu para a eficácia do suporte pela equipe de TI.
Assim considera-se que, neste quesito, o projeto de BI da Petrom
concorda com o padrão referencial estabelecido.
10. Considere também alguns outros fatores de sucesso tais como: a
cultura da empresa, a promoção das aplicações de BI, treinamento e a
utilizações de telas gráficas para apresentação das informações.
10.1 O papel da cultura
Os entrevistados foram perguntados sobre vários pontos em
relação à influência da cultura da empresa para o êxito das aplicações de BI,
sendo que a principal pergunta foi se as decisões na empresa eram,
geralmente, baseadas em informações. Todos os respondentes afirmaram que
para a tomada de decisões na empresa, são consultadas informações que
embasam as decisões. O diretor administrativo da empresa enfatizou que
a cultura da empresa valoriza a tomada de decisões baseada em
dados e informações internas e de mercado, além é claro da
experiência individual de cada gestor (Diretor administrativo).
O gerente comercial respondeu de forma semelhante, dizendo
que é importante embasar as decisões em informações disponibilizadas no BI e
que estas são efetivamente utilizadas na Petrom, mas salientou que não é
possível tomar decisões apenas baseando-se em informações do BI. No
184
processo decisório, outros componentes devem ser levados em consideração,
tais como informações de mercado, a experiência pessoal, intuição,
oportunidades momentâneas, entre outras. Essa afirmação está de acordo com
Howson (2008), para quem a intuição e a experiência não devem ser
eliminadas do processo decisório, principalmente, quando é necessário tomar
decisões rápidas, baseadas em poucos dados disponíveis sobre o assunto. O
problema da tomada de decisões baseada apenas na intuição e na experiência
é que preconceitos e tendências podem comprometer o processo decisório, e,
nesses casos, os dados servirem para apoiar ou desqualificar a decisão a ser
tomada.
Outro tópico que foi citado pelos respondentes como um
componente que auxilia o êxito do BI na Petrom é o fato da empresa possuir
uma estrutura enxuta. Segundo Howson (2008), as empresas que se
declararam enxutas apresentaram êxito superior (79% se declararam enxutas)
às que declararam possuir um BI falho (47% se declararam enxutas). No caso
da Petrom, o fato da empresa ser enxuta contribuiu e ainda contribui para o
sucesso do projeto de BI, pois as barreiras existentes entre os departamentos e
as pessoas envolvidas em projetos comuns são menores. O contato pessoal na
Petrom é intenso, sem barreiras e constante e a resolução de problemas,
geralmente, envolve um pequeno número de pessoas, o que não é corriqueiro
nas organizações com estruturas administrativas complexas.
No estudo de caso se constatou também que o fato da empresa
ser enxuta colabora para que todos os envolvidos em um projeto como o do BI
entendam de forma rápida as necessidades dos usuários, em termos de
informações, o que facilita o desenvolvimento ágil de novas aplicações. Em
empresas complexas, do ponto de vista estrutural, esse processo tende a ser
mais demorado e burocrático.
185
10.2 Promoção de sua aplicação de BI
A estratégia utilizada pela Petrom para divulgar os benefícios do
BI foi a de criar, rapidamente, algumas aplicações que serviram de modelo.
Depois disso, o supervisor de TI apresentou, individualmente para os principais
responsáveis por cada uma das áreas da empresa, as aplicações que haviam
sido desenvolvidas e as possibilidades que o BI poderia oferecer para cada
uma das áreas. O objetivo era o de sensibilizar os gestores para que se
tornassem usuários do BI e que também contribuíssem para o desenvolvimento
de novas aplicações. Essa estratégia funcionou bem na fase inicial, porém, no
estudo de caso foi possível constatar que ela está se exaurindo, pois a
sensação é a de que as contribuições espontâneas que poderiam ocorrer já
aconteceram e que daqui para frente o desenvolvimento de novas aplicações
de BI necessitará de idéias novas e do desenvolvimento de aplicações mais
sofisticadas e abrangentes. Nesse caso, um processo de Benchmarking pode
ser útil e positivo.
10.3 Treinamento
O treinamento para utilização do Logix BI ocorre de forma
individual, sempre que alguém manifesta a necessidade de utilizá-lo. Todos os
entrevistados ressaltaram a facilidade de utilização do Logix BI.
10.4 Apresentação gráfica das informações
As primeiras aplicações desenvolvidas tenderam a ser parecidas
com os relatórios e gráficos existentes no Crystal Reports e no Excel. Na
medida em que o BI foi sendo incorporado à rotina da empresa e suas
186
possibilidades exploradas, a tendência declarada pelos entrevistados é a de
tornar as aplicações mais gráficas, tanto que o supervisor de TI planeja o
desenvolvimento de aplicações mais visuais do que as atuais, para a nova
aplicação a ser desenvolvida para a área de manufatura. Essa situação está
em concordância com o descrito por Howson (2008), em relação à evolução
das aplicações de BI que iniciam de forma mais parecida com os relatórios em
uso e depois tendem a ser mais gráficas na medida em que a empresa
compreende melhor as possibilidades e os usos do BI.
4.5 Resumo dos resultados obtidos da análise do caso estudado
No item anterior, analisaram-se os resultados obtidos da
avaliação de cada um dos dez fatores críticos de sucesso de aplicações de BI,
baseadas em sistemas ERP. A seguir é apresentada a tabela 3, que
demonstra, de forma resumida, os resultados obtidos da análise do estudo de
caso, com base no modelo de adequação aos padrões descritos por Yin
(2005). Os fatores presentes são assinalados com duas possibilidades: X
(Presente) e PA (Parcialmente presente).
187
Tabela 3 – Fatores críticos de sucesso de aplicações de BI
Fatores crítico de sucesso de aplicações de Business
Intelligence
Presente
1. Meça o sucesso de múltiplas maneiras, utilizando medidas
objetivas quando disponíveis e identificando a importância dos
benefícios que não podem ser mensurados quantitativamente.
X
2. Entenda os efeitos da sorte, oportunidade, frustração e ameaça
(em inglês, LOFT: Luck, Opportunity, Frustation e Threat), para
elevar sua aplicação de BI de um resultado moderado para uma
iniciativa de grande êxito.
X
3. Conquiste o apoio executivo para garantir que o BI se infiltre por
todos os cantos da organização, para gerar vantagens
competitivas e valor dos negócios.
X
4. Comece com uma fundação sólida e acrescente melhorias de
forma incremental e consistente para melhorar a qualidade,
amplitude e atualidade aos dados.
X
5. Alinhe a estratégia de BI com as metas do negócio, garantindo
que o pessoal de TI e de negócios trabalhem mais como parceiros
do que como adversários.
X
6. Encontre relevância para o BI para cada trabalhador da empresa,
assim como para clientes e fornecedores.
PA
7. Utilize processos ágeis de desenvolvimento para entregar
capacidades e melhoramentos de BI de forma equivalente à
medida que ocorrem as mudanças nos negócios.
X
8. Organize a equipe de BI e peritos para o êxito na construção de
soluções com foco sobre a empresa.
X
9. Escolha as ferramentas apropriadas de BI que vão ao encontro
das necessidades do usuário e do negócio e que possa trabalhar
no âmbito de tecnologias padrões que a área de TI possa apoiar
eficazmente.
X
10. Considere também alguns outros fatores de sucesso tais como: a
cultura da empresa, a promoção das aplicações de BI,
treinamento e a utilizações de telas gráficas para apresentação
das informações.
X
Em síntese, utilizando-se a lógica de adequação aos padrões em
conformidade com Yin (2005), foi possível constatar que o estudo de caso
PETROM – PETROQUÍMICA MOGI DAS CRUZES S.A. – corrobora com a
teoria referenciada, em relação aos fatores críticos de sucesso de aplicações
de Business Intelligence.
188
CONSIDERAÇÕES FINAIS
Partindo do pressuposto que para obter êxito na implementação
de aplicações de Business Intelligence, é necessário dar atenção não apenas
aos aspectos técnicos do projeto, mas também a outros fatores como os
aspectos políticos, culturais, liderança, criatividade, entre outros; a presente
pesquisa possibilitou averiguar de forma empírica como esses fatores foram
conduzidos e administrados, de maneira a permitir que a empresa Petrom obter
êxito em seu projeto de BI.
O método qualitativo, baseado em entrevistas semi-estruturadas
além da observação direta, proporcionou detalhes que permitiram a
compreensão da natureza das ações adotadas pela empresa Petrom para
atingir seus objetivos, e o relacionamento com o padrão teórico referencial
utilizado para a análise dos dados.
Muitas vezes, as empresas efetuam grandes esforços ao
desenvolverem projetos de TI, com o objetivo de tornar o trabalho das pessoas
mais ágil e dinâmico. Esse esforço resulta na elaboração de bons projetos do
ponto de vista técnico e metodológico, mas, por vezes, acabam não obtendo o
êxito esperado, pois não foram levados em consideração alguns fatores que
não são técnicos. Segundo O’Brien (2004), toda maneira nova de fazer as
coisas gera alguma resistência por parte das pessoas afetadas. Com o
Business Intelligence isso não é diferente. O segredo do sucesso parece estar
em saber identificar os fatores que devem ser trabalhados para permitir que
bons projetos do ponto de vista técnico alcancem o seu objetivo.
O caso Petrom se mostrou exemplar, pois os fatores críticos que
contribuem para o bom desempenho das aplicações de BI não foram
189
subestimados, e foram administrados de forma eficiente para que a iniciativa de
BI obtivesse êxito. Os integrantes da empresa ficaram surpresos quando
constataram que muitas das ações por eles adotadas constavam de
recomendações de autores com reconhecido domínio sobre o assunto. De
forma empírica, haviam acertado onde muitas empresas falham. É sabido que
as empresas enfrentam dificuldades ao lidar com questões subjetivas e,
portanto, não se pode esperar que todas elas contem com a mesma
sensibilidade e senso de oportunidade presentes na Petrom. Dessa forma, os
fatores de sucesso de aplicações de BI analisados neste trabalho podem servir
de apoio para outras empresas que estejam iniciando os seus projetos de BI.
Entre os fatores analisados, observou-se no estudo de caso que o
apoio executivo é fundamental para iniciativas bem sucedidas de BI. Muitos
projetos não evoluem, pois o executivo responsável não entende a importância
da informação no cenário atual das organizações, não acreditam no potencial
das aplicações de BI ou nem se sente motivado para estar à frente de tal
iniciativa. Esse tipo de comportamento compromete seriamente os resultados
obtidos, o que não ocorreu no estudo de caso da Petrom. A empresa contou
com a vantagem de ter seu projeto iniciado por um executivo que já havia
experimentado os benefícios do BI e conhecia o seu potencial, e também pelo
trabalho de seu sucessor, que deu continuidade à iniciativa, pois compartilha
dessa mesma visão.
Foi fundamental também o entendimento da empresa de que a
implementação do sistema ERP havia estabelecido os fundamentos para
obtenção de informações consistentes, que poderiam contribuir com o
processo decisório. A decisão por utilizar uma arquitetura de BI teve como
meta obter as vantagens e a flexibilidade que essa arquitetura oferece, de
maneira a maximizar a utilização do sistema ERP. Outro fator que contribuiu
também para o sucesso das aplicações de BI na Petrom foi a opção pela
ferramenta Logix BI, desenvolvida pelo mesmo fornecedor do sistema ERP,
que possibilitou o desenvolvimento de aplicações de forma rápida com a
melhor relação custo benefício.
190
O estudo de caso demonstrou também a importância que as
empresas devem dar para o processo de continuidade que se segue à
implementação das primeiras aplicações de BI. Muitas empresas tendem a
diminuir o ritmo do desenvolvimento de novas aplicações e melhorias após a
fase inicial de implementação das primeiras aplicações. O ideal é que se dê
início a um círculo virtuoso de busca por novas aplicações que estejam
alinhadas à estratégia da empresa. Isso, na prática, significa que o critério que
a empresa deve sempre adotar em relação ao BI é que as aplicações devem
contribuir, em primeiro lugar, com o negócio da empresa.
Não é recomendado que a equipe de BI dependa apenas das
demandas para o desenvolvimento e melhoria das aplicações de BI. Howson
(2008) chama esse processo de ‘buscar a relevância do BI na empresa’. Desse
modo, o ideal é que a equipe de BI identifique as pessoas e os processos de
maior impacto nos negócios da organização e procure disponibilizar aplicações
que estejam alinhadas com a atuação dessas pessoas e desses processos.
Esta é a mais importante recomendação a se fazer em relação ao estudo de
caso, pois a empresa se encontra, exatamente, nesta fase, intermediária, de
pós-implementação do BI. Por isso, esse foi o único dos dez fatores analisados
no estudo de caso que não obteve concordância com o padrão referencial
utilizado para a análise dos dados.
Em resposta à segunda proposição deste trabalho, que
estabelece que o BI contribua para o desempenho da empresa, verificou-se na
pesquisa realizada que de maneira geral, há entre os entrevistados a convicção
de que o Business Intelligence contribui efetivamente para o desempenho da
empresa, ao oferecer informações importantes para a boa gestão da
organização.
De maneira geral, o estudo do caso Petrom evidenciou que os
fatores considerados críticos pela literatura, para o êxito das aplicações de BI,
tiveram relevância no caso e merecem a atenção das empresas que estejam
iniciando projetos de BI.
191
É importante salientar, também, que o estudo possui limitações,
principalmente, por se tratar de um estudo de caso único, o que não permite
generalizações (YIN, 2005). Então, sugerem-se aqui, pesquisas que
realizassem replicações do estudo de caso, com o objetivo de verificar e,
posteriormente, confirmar as evidências encontradas neste estudo de caso.
Dessa forma será possível aumentar a confiabilidade dos resultados deste
trabalho em particular. Além disso, seria possível também responder a outras
questões que, devido à abrangência do tema, não foram exploradas e que têm
relação com o tema. Ficam, então, como sugestões para futuros trabalhos
algumas questões a serem respondidas tais como: como os fatores críticos de
sucesso descritos neste trabalho atuam em empresas que não contam com um
sistema ERP como sistema transacional, mas que possuem aplicações de BI?
Por que algumas empresas efetuam a implementação de sistemas ERP e não
avançam para, além disso, ignorando o uso de aplicativos como o BI? Quais as
razões que levam as empresas a adotar esse comportamento?
192
REFERÊNCIAS BIBLIOGRÁFICAS
ALAVI, M.; LEIDNER, D. E. Knowledge management and knowledge
managment systems: Conceptual foundations and research issues. MIS
Quarterly, v. 25, n.1, p. 107-132, mar. 2001. Disponível em:
<http://mmlab.ceid.upatras.gr/courses/AIS_SITE/files/projects2004/paper711/14
_KM_KMsystems_Alavi_MISQ.pdf>. Acesso em: 20 de fevereiro de 2008.
ANDERY, M. A. P. A.; et al. Para compreender a ciência: uma perspectiva
histórica. 13ª. Ed. Rio de Janeiro: Garamond; São Paulo: ESUC, 2004.
ATRE, S. The top 10 critical challenges for Business Intelligence sucess.
ComputerWorld, White Paper/Special Advertising, jun. 2003. Artigos. Disponível
em: http://www.computerworld.com/computerworld/records/images/pdf/BusIntel
lWPonline.pdf>. Acesso em: 19 de julho de 2008.
BARBIERI, C. BI-Business Intelligence – Modelagem & tecnologia. Rio de
Janeiro: Axcel Books Brazil Editora, 2001.
BECK, K. et al.. Manifesto for agile software development. 2001. Disponível em:
< http://www.agilemanifesto.org>. Acesso em: 02 de agosto de 2008.
BROWN, J. S.; DUGUID P. Organizational learnning and communities of
pratice: Toward a unified view of working, learning. The Institute of
Management Sciences. 1991. Disponível em:
<http://www2.parc.com/ops/members/brown/papers/orglearning.html>. Acesso
em: 23 de fevereiro de 2008.
BROWN, S. A. CRM – Customer Relationship Management. São Paulo:
Makron Books, 2001.
193
COMPUTERWORLD. Evolução do BI - Análise preditiva, 2008. Disponível em:
<http://computerworld.uol.com.br/gestao/2008/06/26/evolucao-do-bi-2013-
analise-preditiva/>. Acesso em: 14 de julho de 2008.
CORRÊA, H. L.; CAON, M. Gestão de serviços: Lucratividade por meio de
operações e de satisfação dos clientes. São Paulo: Atlas, 2002.
CORRÊA, H. L.; GIANESI, I. G. N; CAON, M. Planejamento programação e
controle da produção: MRPII/ERP – conceitos, uso e implantação. 4
ª
ed. São
Paulo: Atlas, 2001.
CRONIN, B. Esquemas conceituais e estratégicos para a gerência da
informação. Revista da Escola de Biblioteconomia da UFMG, v. 19, n. 2, p.
195-220, Set 1990.
DAVENPORT, T. H.; PRUSAK, L. Conhecimento empresarial: como as
organizações gerenciam o seu capital intelectual. Rio de Janeiro: Elsevier,
2003.
DAVENPORT, T. H. Missão crítica: obtendo vantagem competitiva com os
sistemas de gestão empresarial. Porto Alegre: Bookman, 2002.
_______________. Putting the enterprise into the enterprise system. Harvard
Business Review. Julho-Agosto, p.121-131, 1998.
_______________. Inteligência Competitiva. InformationWeek Brasil. 183.
edição, 26/06/2007. Disponível em:
<http://www.itweb.com.br/noticias/index.asp?cod=29047>. Acesso em: 25 de
junho de 2008.
DELOITTE CONSULTING. ERPs Second Wave: Maximizing the Value of
Enterprize Applications and Processes. 1998. Disponível em:
<http://www.deloitte.com/dtt/cda/doc/content/Erps_second_wave(1).pdf>.
Acesso em: 21 de Junho de 2008.
194
DEGAGNE, C.; LEANDRI, S.; PUCHLEY, T. Linking knowledge and risk
managment: controlling the information flood. Risky Business, n. 7, p. 15-20
2003.
ESTEVES J.; PASTOR J. Enterprise resource planning systems research: An
annotated bibliography. Communications of the association for information
systems, v. 7, n.8, Aug., 2001.
ESTEVES J.; PASTOR J. Towards the unification of critical sucess factors for
ERP implementations. Conference of portuguese association of information
systems, 1., 2000, Portugal, 2000. Disponível em:
<http://www.army.mil/ArmyBTKC/docs/BIT2000.pdf>. Acesso em: 22 de
fevereiro de 2008.
GARVIN, D. A. Aprendizagem em ação: um guia para transformar sua empresa
em uma lerning organization. Rio de Janeiro: Qualitymark, 2002.
GIL, A. C. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999.
HABERKORN. E. Um bate-papo sobre a gestão empresarial com ERP: tudo
que você gostaria de saber sobre o ERP e a tecnologia da informação, mas
ficava encabulado de perguntar. São Paulo: Saraiva, 2007.
HOWSON C. Successful Business Intelligence: Secrets to making BI a killer
App. New York: McGraw-Hill, 2008.
INMON, W. H. Building the data warehouse. 3. ed. New York: John Wiley &
Son, 2002.
KOTLER, P.; KELLER, K. L. Administração de marketing. 12. ed. São Paulo:
Pearson Prentice-Hall, 2006.
KROGH, G. V.; ICHIJO, K.; NONAKA, I. Facilitando a criação do conhecimento:
reinventando a empresa com o poder da inovação continua. Rio de Janeiro:
Campus, 2001.
195
LAKATOS, E. M.; MARCONI M. A. Fundamentos de metodologia científica.
São Paulo: Atlas, 2003.
LAUDON C. K.; LAUDON J. P. Sistemas de informação gerencial. 7. ed. São
Paulo: Pearson Prentice Hall, 2007.
LEE Z.; LEE J. An ERP implementation case study from a knowledge transfer
perspective. In: SHANKS, G.; SEDDON, P. B.; WILLCOCKS (eds.). Second-
wave enterprise resource planning systems: implementing for effectiveness.
Cambridge: Cambridge University Press, 2003.
McGee, M. K. Managers have too much information, do too little sharing.
InformationWeek, Jan. 2007. Disponível em:
<http://www.informationweek.com/news/management/showArticle.jhtml?articleI
D=196801833>. Acesso em: 13 de julho de 2008.
LUDMER, G. Sistemas integrados de gestão e conhecimento organizacional:
dinâmica das interações na pós-implementação em uma regional de uma
empresa de serviços de telecomunicações, 2006. 165 f. (Tese de Doutorado
em Administração) – Universidade Federal de Pernambuco, Recife, 2006.
MAHMOOD, M. A.; SOON, S. K. A comprehensive model for measuring the
potencial impact of information technology on organizational strategic variables.
Desicion Sciences, v.22, 1991.
MANÃS A. V. Avaliação de resultados no emprego do ERP em empresas
brasileiras. In: SOUZA, C. A.; SACOOL, S. A. (orgs.). Sistemas ERP no Brasil:
(Enterprise Resourse Planning): teoria e casos. São Paulo: Atlas, 2003.
MANTOVANI, F. R. Um estudo sobre a contribuição dos sistemas de
inteligência de negócios na gestão econômico-financeira das empresas.
Dissertação de Mestrado. 2005. 104 f. Dissertação (Mestrado em Ciências
Contábeis e Financeiras). Pontifícia Universidade Católica de São Paulo, São
Paulo, 2005.
196
MARTINS, R. P. Um estudo dos principais aspectos e mudanças no processo
de gestão empresarial para implantação do ERP nas indústrias do Paraná.
Dissertação de Mestrado. 2002. 104 f. Dissertação (Mestrado em
Administração). Pontifícia Universidade Católica de São Paulo, São Paulo,
2002.
MATHESON D.; MATHESON J. The smart organization, creating value through
strategic R&D. Boston: Harvard Business School Press, 1998.
MATHEUS, R. F.; PARREIRAS, F. S. Inteligência Empresarial versus Business
Intelligence abordagens complementares para o apoio à tomada de decisão no
Brasil. KMBrasil 2004, Congresso Anual da Sociedade de Gestão do
Conhecimento, 3. São Paulo, 2004. Disponível em:
<http://www.fernando.parreiras.nom.br/publicacoes/ie_bi.pdf>. Acesso em: 04
de julho de 2008.
MICHAUD, C. Modelos e conhecimento. In: TARAPANOFF, K. (org.)
Inteligência, informação e conhecimento em corporações. Brasília: IBICT,
UNESCO, 2006.
MORESI, E. A. D. Delineando o valor do sistema de informação de uma
organização. Ci. Inf. Brasília, v. 29, n. 1 p. 14-24, jan/abr. 2000.
_________________. Memória Organizacional e Gestão do Conhecimento. IN:
Inteligência, informação e conhecimento em corporações. Organizador: Kira
Tarapanoff. Brasília: IBICT, UNESCO, 2006.
MOSS L. T.; ATRE S. Business Intelligence roadmap: the complete project
lifecycle for decision-support applications. Boston: Addison-Wesley, 2003.
MOTTA, F. C. P.; VASCONCELOS, I. F. F. G. Teoria geral da administração.
São Paulo: Pioneira Thomson Learning, 2002.
197
NONAKA, I.; TAKEUCHI, H. Criação de conhecimento na empresa: como as
empresas japonesas geram a dinâmica da inovação. Rio de Janeiro: Campus,
1997.
NORRIS, G. et al. E-Business e ERP: transformando as organizações. Rio de
Janeiro: Qualitymark, 2001.
O’BRIEN, J. A. Sistemas de informação e as decisões gerenciais na era da
Internet. 2. ed. – São Paulo: Saraiva, 2004.
PÉREZ-MONTORO GUTIÉRREZ, M. O Conhecimento e sua gestão em
Organizações. IN: TARAPANOFF, K. (org.) Inteligência, informação e
conhecimento em corporações. Brasília: IBICT, UNESCO, 2006.
POLANIY, M. The Tacit Dimension. New York: Doubleday & Company, Inc.,
1966.
PONNIAH, P. Data warehouse fundamentals: A comprehensive guide for it
professionals. New York: John Wiley & Son, 2001.
POZZEBON, M. Um modelo de EIS – Enterprise Information System – que
identifica características para comportamentos proativos na recuperação de
informações. 1998. 160 f. (Dissertação de Mestrado em Administração).
Universidade Federal do Rio Grande do Sul, Escola da Administração. Porto
Alegre, 1998.
REZENDE, D. A. Sistemas de conhecimento e as relações com a gestão do
conhecimento e com a inteligência organizacional nas empresas privadas e nas
organizações públicas. IN: TARAPANOFF, K. (org.) Inteligência, informação e
conhecimento em corporações. Brasília: IBICT, UNESCO, 2006.
RICHARDSON, R. Pesquisa Social: métodos e técnicas. São Paulo: Atlas,
1985.
198
ROMANO, S. L. G. O emprego do ERP na indústria de eletrodomésticos e
eletroeletrônicos no Brasil: principais aspectos e satisfação das empresas.
2001. Dissertação (Mestrado em Administração) – PUC, São Paulo, 2001.
ROSEMANN. M. ERP – Enterprise systems management with reference
process models. In: SHANKS, G.; SEDDON, P. B.; WILLCOCKS (eds.).
Second-wave enterprise resource planning systems: implementing for
effectiveness. Cambridge: Cambridge University Press, 2003.
ROSS. W. J.; VITALE M. R.; WILLCOCKS L. P. The continuing ERP revolution:
sustainable lessons, new modes of delivery. In: SHANKS, G.; SEDDON, P. B.;
WILLCOCKS (eds.). Second-wave enterprise resource planning systems:
implementing for effectiveness. Cambridge: Cambridge University Press, 2003.
SACOOL, A. Z.; MACADAR, M. A.; PEDRON, C. D.; NETO, G. L.; CAZELLA,
S. C. Sistemas ERP e seu impacto sobre variáveis estratégicas de grandes
empresas no Brasil. In: SOUZA, C. A.; SACOOL, S. A. (orgs.) Sistemas ERP
no Brasil: (Enterprise Resourse Planning): teoria e casos. São Paulo: Atlas,
2003.
SACOOL, A. Z. Um Olhar Crítico sobre Modismos em Tecnologia da
Informação: Analisando o Discurso dos Vendedores de Pacotes ERP. In:
SOUZA, C. A.; SACOOL, S. A. (orgs.) Sistemas ERP no Brasil: (Enterprise
Resourse Planning): teoria e casos. São Paulo: Atlas, 2003.
SANTANA, V. L. Impacto de um pacote de software de gestão sobre variáveis
estratégicas: percepção dos profissionais de TI e de Administração nas
Empresas da Região Metropolitana de Curitiba. 2006 187 p. (Dissertação de
Mestrado em Administração). Centro de Ciências Sociais Aplicadas da
Pontifícia Universidade Católica do Paraná. Curitiba, 2006.
SELL, G. Uma arquitetura para Business Intelligence baseada em tecnologias
semânticas para suporte a aplicações analíticas. 2006. 210 f. (Tese de
199
Doutorado em Engenharia de Produção). Universidade Federal de Santa
Catarina, Florianópolis, 2006.
SIMON, A. H. The new science of management decision. New York: Harper,
1960.
_____________. Comportamento administrativo: estudo dos processos
decisórios nas organizações administrativas. 2 ed. Rio de Janeiro: FGV, 1970.
SOUZA C. A.; SACOOL, A. Z. Sistemas ERP e seu histórico. In: SOUZA, C. A.;
SACOOL, S. A. (orgs.) Sistemas ERP no Brasil: (Enterprise Resourse
Planning): teoria e casos. São Paulo: Atlas, 2003.
STAIR, R. M.; REYNOLDS, G. W. Princípios de sistemas de informação: uma
abordagem gerencial. 6 ed. São Paulo: Cengage Learning, 2008.
STEWART, T. A. Capital intelectual: a nova vantagem competitiva das
empresas. 3ª. Ed. Rio de Janeiro: Campus, 1998.
SVEIBY, K. E. A Nova riqueza das organizações: gerenciando e avaliando
patrimônios de conhecimento. Rio de Janeiro: Campus, 1998.
TARAPANOFF, K.; Informação, Conhecimento e Inteligência em
Corporações:relações e complementaridade. IN: TARAPANOFF, K. (org.)
Inteligência, informação e conhecimento em corporações. Brasília: IBICT,
UNESCO, 2006.
TRONTO, I. F. B; ARAUJO, A. C; SILVA, J. D. S; SANT’ANA, N. Business
Intelligence: Inteligência nos Negócios. INPE, São José dos Campos 2003.
Disponível em:
<http://hermes2.dpi.inpe.br:1905/col/lac.inpe.br/worcap/2003/10.31.15.48/doc/A
rtigoWorkap3.pdf>. Acesso em: 10 de junho de 2008.
200
TUOMI, I. Data is more then knowledge: Implications of the reversed Hierarchy
of knowledge management and organizational memory. Proceedings of the
thirty-second Hawaiinternational conference of systems sciences, 1999.
TURBAN, E.; ARONSON, J. E.; TING-PENG, L.; SHARDA, R. Decision support
systems and intelligent systems. 8 ed. Upper Saddle River, NJ: Pearson
Prentice Hall, 2007.
ZILBER, S. N.; TAVARES, J. C.; NASCIMENTO, E. E-procurement: vantagem
competitiva em suprimentos. Anais do IX Simpósio de Administração, Logística
e Operações Internacionais, SIMPOI – FGV-EAESP, 2006
ZWICKER, R.; SOUZA C. A. Sistemas ERP: Conceituação, Ciclo de Vida e
Estudos de Casos Comparados. In: SOUZA, C. A.; SACOOL, S. A. (orgs.)
Sistemas ERP no Brasil: (Enterprise Resourse Planning): teoria e casos. São
Paulo: Atlas, 2003.
WANDERLEY, A. V. M. Um instrumento de macro política de informação:
concepção de um sistema de inteligência de negócios para gestão de
investimentos de engenharia. Ciência da Informação, Brasília, v. 28, n. 2, p.
190-199, mai/ago. 1999.
YIN, R. K. Estudo de caso: planejamento e métodos. Porto Alegre: Bookman,
2005.
COMITÊ GESTOR DA INTERNET NO BRASIL. O uso das tecnologias da
informação e da comunicação no Brasil. 2007. Disponível em:
<http://www.cetic.br/tic/2007/indicadores-cgibr-2007.pdf>. Acesso em: 25 de
junho de 2008.
Sites consultados
WWW.ABIQUIM.ORG.BR. Acesso em 22 de setembro de 2008.
201
ANEXOS
202
ANEXO I
Carta de autorização para o entrevistador
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO - PUC/SP
PROGRAMA DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO
São Paulo, 31 de Julho de 2008.
Prezados Senhores,
Na condição de Coordenador do Programa de Estudos de Pós-graduação
em Administração da PUC-SP, solicito autorização para que o mestrando Manuel
Pier Sobrido, matrícula número 04100156, possa conduzir sua pesquisa de
mestrado sobre Business Intelligence e Sistemas integrados de Gestão, nesta
conceituada empresa.
Informamos que os dados e informações levantadas pela pesquisa serão
totalmente confidenciais e de uso exclusivo para fins acadêmicos. A proposta é
que ao final deste trabalho possamos apresentar à empresa um resumo das
principais conclusões.
Caso exista alguma dúvida, pede-se a gentileza de contatar o Sr. Manuel
Pier Sobrido através do e-mail do [email protected]
, ou então através dos
telefones (11) 4472-5441, (11) 9916-3960.
Atenciosamente,
Prof. Dr. Luciano A. Prates Junqueira
Coordenador do Programa de Estudos de Pós-graduação
em Administração da PUC/SP.
203
ANEXO II
FOLHA DE IDENTIFICAÇÃO DO PARTICIPANTE
NOME DO PARTICIPANTE :
NOME DA EMPRESA ONDE TRABALHA:
TELEFONE PARA CONTATO (opcional):
E-MAIL(Opcional):
NOME DA EMPRESA QUE PRESTA SERVIÇOS REFERENTES AO SEU
SISTEMA ERP E APLICAÇÃO DO BI:
DATA APROXIMADA DA IMPLANTAÇÃO DO SISTEMA ERP E DO BI NA
EMPRESA:
____ / ____ / ____
CARGO QUE OCUPA NA EMPRESA:
TEMPO NO CARGO:
TEMPO NA EMPRESA:
SISTEMA ERP QUE UTILIZA:
BI QUE UTILIZA:
204
Para o propósito desta pesquisa o Business Intelligence (BI) é definido como
um conjunto de tecnologias e processos que permitem aos usuários,
acessar, analisar, e explorar dados para o processo de tomada de decisão.
1 – Como você utiliza o BI?
Eu confio em informações fornecidas por analistas que
utilizam o BI diretamente
Eu acesso relatórios e consultas pré-definidas
Eu criei meus próprios relatórios e consultas
Eu não utilizo o BI
Outros (favor especificar)
____________________________________
____________________________________
____________________________________
____________________________________
2 – Qual avaliação você faz sobre o êxito de suas aplicações de BI?
Bem sucedidas
Razoavelmente
Sem sucesso
3 – De que maneira você avaliação o êxito das aplicações de BI? (selecione
todas as opções que se aplicam a seu caso)
Retorno sobre investimento
Percepção que é um instrumento importante para a empresa
205
Suporte aos usuários chave da empresa
Número de usuários ativos
Redução de custos
Melhora no desempenho da empresa
Melhor acesso aos dados
4 – Quanto o BI contribui para o desempenho de sua empresa?
Significativamente
Razoavelmente
Não contribui
5 – Como você caracteriza o uso do BI na empresa?
Aplicações por departamentos
Aplicações desenvolvidas para a empresa em geral
6 – Em sua avaliação o BI deve ser disponibilizado para quem na empresa?
____________________________________
____________________________________
____________________________________
____________________________________
206
7 – Quanto do sucesso do BI você atribui à cultura da empresa?
Essencial
Muito
Importante
Importante
Não muito
Importante
Sem
impacto
A parceria do TI com as
áreas de negócio
A cultura da empresa em
tomar decisões baseada
em fatos
Suporte executivo
O projeto de BI foi bem
gerenciado
A atuação do comitê de BI
Os patrocinadores do BI
por divulgar seus
benefícios
Estabelecimento de um
centro de excelência de BI
O projeto de BI foi bem
fundamentado
O projeto de BI está
alinhado com as metas
estratégicas da empresa
Qualidade e expertise
Dos consultores externos
Qualidade e expertise
Dos consultores internos
8 – Quanto do sucesso do BI você atribui aos aspectos técnicos?
Essencial
Muito
Importante Importante
Não muito
Importante
Sem
impacto
Disponibilidade e
abrangência dos assuntos
disponíveis no BI
Qualidade dos dados
Ferramenta de BI
apropriada
Incorporação do BI as
operações da empresa
Velocidade de respostas
das pesquisas
O BI está continuamente
sofrendo melhoras
A atualização dos dados é
próximo do real time
Confiabilidade das
aplicações de BI
207
9 – Quais os planos futuros para o BI e como torná-lo mais valioso para a
empresa?
____________________________________
____________________________________
____________________________________
____________________________________
10 – Algum outro comentário que gostaria de acrescentar sobre o sucesso
do projeto de BI?
____________________________________
____________________________________
____________________________________
____________________________________
OBRIGADO POR SUA PARTICIPAÇÃO
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
