UNIVERSIDADE DE SO PAULO

Faculdade de Economia, Administrao e Contabilidade

Departamento de Administrao

SISTEMAS INTEGRADOS DE GESTO EMPRESARIAL:

ESTUDOS DE CASOS DE IMPLEMENTAO DE SISTEMAS
ERP

Cesar Alexandre de Souza

Orientador: Prof. Dr. Ronaldo Zwicker

So Paulo
Maio de 2000

UNIVERSIDADE DE SO PAULO
Faculdade de Economia, Administrao e Contabilidade
Departamento de Administrao

SISTEMAS INTEGRADOS DE GESTO EMPRESARIAL:

ESTUDOS DE CASOS DE IMPLEMENTAO DE SISTEMAS
ERP

Dissertao Apresentada ao Departamento de

Administrao da Faculdade de Economia, Administrao e Contabilidade da Universidade de So
Paulo, como parte dos requisitos para a obteno
do ttulo de Mestre em Administrao

Cesar Alexandre de Souza

Orientador: Prof. Dr. Ronaldo Zwicker

So Paulo
Maio de 2000

ii

Notas sobre a verso eletrnica:

-

Esse trabalho pode ser livremente copiado e distribudo desde que no se altere seu contedo
Se o trabalho for utilizado no todo ou em parte, pede-se a gentileza de citar a fonte
Todos os direitos so reservados pelo autor
E-mail : calesou@uol.com.br

FICHA CATALOGRFICA

Souza, Cesar Alexandre de

Sistemas integrados de gesto empresarial : estudos
de caso de implementao de sistemas ERP / Cesar Alexandre de Souza. __ So Paulo : FEA/USP, 2000.
253 p.
Dissertao - Mestrado
Bibliografia.
1. Administrao Sistemas de informao 2. Administrao de empresas 3. Informtica I. Faculdade de Economia, Administrao e Contabilidade da USP.

CDD 658.403

iii

NDICE

LISTA DE FIGURAS.................................................................................................................................... vi

LISTA DE QUADROS .................................................................................................................................. vi

LISTA DE TABELAS ................................................................................................................................... vi

RESUMO...................................................................................................................................................... vii

ABSTRACT................................................................................................................................................. viii

CAPTULO 1 O PROBLEMA DE PESQUISA............................................................................................. 1

1.1

INTRODUO ..................................................................................................................................... 1

1.2

FORMULAO DO PROBLEMA ............................................................................................................. 4

1.3

QUESTO PRINCIPAL DA PESQUISA ..................................................................................................... 5

1.4

OBJETIVOS DA PESQUISA .................................................................................................................... 6

1.5

JUSTIFICATIVAS ................................................................................................................................. 6

1.6

ORGANIZAO DA DISSERTAO ....................................................................................................... 7

CAPTULO 2 SISTEMAS ERP ..................................................................................................................... 8

2.1

SISTEMAS DE INFORMAO ................................................................................................................ 8

2.2

TIPOLOGIA DE SISTEMAS DE INFORMAO .......................................................................................... 8

2.3

SISTEMAS ERP................................................................................................................................. 11

2.4

CARACTERSTICAS DOS SISTEMAS ERP ............................................................................................. 12

2.5

OUTROS CONCEITOS RELACIONADOS AOS SISTEMAS ERP ................................................................. 16

2.6

A ARQUITETURA DE SISTEMAS ERP ................................................................................................. 19

2.7

SISTEMAS ERP COMO ESPINHA DORSAL DO PROCESSAMENTO CORPORATIVO ................................ 22

CAPTULO 3 O CICLO DE VIDA DE SISTEMAS ERP........................................................................... 23

3.1

O CICLO DE VIDA DE SISTEMAS ........................................................................................................ 23

3.2

CICLOS DE VIDA DE PACOTES COMERCIAIS DE SOFTWARE ................................................................. 24

3.3

TEORIAS DE IMPLEMENTAO DE TI................................................................................................. 25

3.4

PROPOSTA PARA CICLO DE VIDA DE SISTEMAS ERP .......................................................................... 26

3.5

DECISO E SELEO ........................................................................................................................ 28

3.6

A ETAPA DE IMPLEMENTAO ......................................................................................................... 38

iv

3.7

A ETAPA DE UTILIZAO.................................................................................................................. 47

CAPTULO 4 BENEFCIOS E DIFICULDADES DOS SISTEMAS ERP................................................. 50

4.1

BENEFCIOS DOS SISTEMAS ERP ....................................................................................................... 50

4.2

DIFICULDADES E POSSVEIS PROBLEMAS RELACIONADOS AOS SISTEMAS ERP.................................... 51

4.3

TI E VANTAGEM COMPETITIVA: MODELO DE PORTER E MILLAR ........................................................ 54

4.4

OS SISTEMAS ERP E A CADEIA DE VALORES ..................................................................................... 56

4.5

TI E REDESENHO DE PROCESSOS ....................................................................................................... 56

4.6

OS SISTEMAS ERP E O REDESENHO DE PROCESSOS............................................................................ 58

4.7

RELAO ENTRE BENEFCIOS E PROBLEMAS E CARACTERSTICAS DOS SISTEMAS ERP........................ 59

CAPTULO 5 METODOLOGIA DA PESQUISA....................................................................................... 63

5.1

OBJETIVO DA PESQUISA.................................................................................................................... 63

5.2

TIPO E METODOLOGIA DE PESQUISA ................................................................................................. 63

5.3

O MTODO DE ESTUDO DE CASOS .................................................................................................... 65

5.4

O DELINEAMENTO DA PESQUISA....................................................................................................... 67

5.4.1 Questo de Pesquisa....................................................................................................................... 67

5.4.2 Proposies e Modelo da pesquisa ................................................................................................. 67
5.4.3 Unidade de Anlise e Tipo de Estudo de Casos: Casos Mltiplos .................................................... 71
5.4.3.1 Escolha dos Casos.................................................................................................................... 72
5.4.3.2 Coleta de Dados....................................................................................................................... 75
5.4.3.3 O Roteiro para a Entrevista ...................................................................................................... 76
5.4.3.4 O Caso Piloto........................................................................................................................... 77
5.4.4 Ligao entre os Dados e as Proposies: Anlise dos resultados................................................... 77
5.4.4.1 Apresentao e Anlise individual dos casos ............................................................................ 77
5.4.4.2 Anlise entre os casos .............................................................................................................. 79
5.4.5 Critrios para Interpretar os Resultados e Limitaes da Pesquisa ................................................. 80
CAPTULO 6 ESTUDOS DE CASOS ......................................................................................................... 82
6.1

CASO RHODIA POLIAMIDA (EX-FAIRWAY) ............................................................................ 83

6.2

CASO COMPANHIA NQUEL TOCANTINS.............................................................................. 107

6.3

CASO BOSCH.............................................................................................................................. 124

6.4

CASO SANTISTA ALIMENTOS ................................................................................................. 141

6.5

CASO AGROLARANJA (NOME FICTCIO)..................................................................................... 164

6.6

CASO VINE TXTIL ................................................................................................................... 183

6.7

CASO ZENECA ........................................................................................................................... 196

6.8

CASO MELHORAMENTOS PAPIS .......................................................................................... 210

CAPTULO 7 CONCLUSES E RECOMENDAES........................................................................... 230

7.1

CICLO DE VIDA DE SISTEMAS ERP.................................................................................................. 230

7.2

BENEFCIOS E DIFICULDADES DE SISTEMAS ERP ............................................................................. 244

7.3

RECOMENDAES .......................................................................................................................... 249

7.4

RECOMENDAES PARA FUTURAS PESQUISAS ................................................................................. 251

7.5

COMENTRIOS FINAIS DO PESQUISADOR ......................................................................................... 252

REFERNCIAS BIBLIOGRFICAS ....................................................................................................... 254

REFERNCIAS BIBLIOGRFICAS ....................................................................................................... 255

ANEXOS..................................................................................................................................................... 259

ANEXO 1 QUESTIONRIO PARA O RESPONSVEL PELO PROJETO OU REA DE TI .......... 260

ANEXO 2 QUESTIONRIO PARA OS GERENTES USURIOS....................................................... 263

ANEXO 3 AUTORIZAES PARA PUBLICAO............................................................................ 266

ANEXO 4 TABELAS DE COMPARAO ENTRE OS CASOS.......................................................... 275

vi

LISTA DE FIGURAS

Figura 1 Distribuio dos Sistemas de Informao nos Nveis Hierrquicos da Empresa

Figura 2 Arquitetura de um Sistema ERP
Figura 3 Sistemas Cliente/Servidor em Trs Camadas
Figura 4 - Ciclo de Vida de Sistemas ERP
Figura 5 - Etapa de Deciso e Seleo
Figura 6 - Estrutura Organizacional do Projeto
Figura 7 - Modelo de Implementao de Pacotes
Figura 8 - Etapa de Implementao
Figura 9 - Adaptao de um Mdulo - Elaborada pelo autor
Figura 10 - A Cadeia de Valores de Uma Empresa - Extrada de Porter (1989)
Figura 11 - Relao entre TI e BPR - Adaptada de Davenport (1990)
Figura 12 O Modelo da Pesquisa
Figura 13 Votorantim Minerao e Metalurgia
Figura 14 Padro episdico para a adaptao de tecnologias
Figura 15 Evoluo Aproximada do Grau de Customizao aps o Incio da Operao
Figura 16 Modos de Incio de Operao, por Abrangncia Geogrfica e Funcional
Figura 17 Modelo de Ciclo de Vida de Sistemas ERP Implementao em big-bang
Figura 18 Modelo de Ciclo de Vida de Sistemas ERP Implementao em Fases ou S-Bangs

10
20
21
27
29
38
40
44
45
55
58
70
108
233
235
237
243
243

LISTA DE QUADROS
Quadro 1 Ciclo de Vida de Sistemas Linear
Quadro 2 - Ciclo de Vida de Pacotes Comerciais
Quadro 3 - Possibilidades da TI para a BPR
Quadro 4 - As Possibilidades dos Sistemas ERP
Quadro 5 - Benefcios e problemas relativos caracterstica Pacote Comercial
Quadro 6 - Benefcios e problemas associados caracterstica Integrao
Quadro 7 - Benefcios e problemas associados caracterstica Abrangncia Funcional
Quadro 8 - Benefcios e problemas associados caracterstica Mod. de Dados Corporativo
Quadro 9 Casos Selecionados para a Pesquisa
Quadro 10 Riscos e Vantagens dos Diferentes Modos de Incio de Operao
Quadro 11 Novos Benefcios e Problemas Verificados nos Casos Elaborado pelo Autor

23
25
58
59
60
61
61
62
75
238
248

LISTA DE TABELAS
Tabela 1 - Usurios por planta ou mdulo na Bosch
Tabela 2 Etapas da Implementao do sistema ERP na AgroLaranja
Tabela 3 - Data de Implementao e qtde. de usurios por mdulos

127
167
215

vii

RESUMO

Os anos 90 assistiram adoo dos sistemas ERP (enterprise resource planning) pelas
grandes corporaes industriais. Esses sistemas tm sido utilizados como infra-estrutura tecnolgica para suporte s operaes de empresas com vantagens sobre os sistemas anteriores
desenvolvidos internamente. As vantagens incluem a possibilidade de integrar os diversos
departamentos da empresa, a atualizao permanente da base tecnolgica e benefcios relacionados terceirizao do desenvolvimento de aplicaes, como por exemplo, a reduo dos
custos de informtica.
Este trabalho um estudo das caractersticas dos sistemas ERP, de seus processos de
escolha, implementao e utilizao, de seus benefcios, suas desvantagens e de seus possveis
impactos nas organizaes e pretende colaborar para o aprofundamento do conhecimento sobre esses sistemas e para o desenvolvimento de um modelo terico que permita analisar os
benefcios que esses sistemas podem trazer para as empresas, bem como as dificuldades a eles
relacionadas.
Em seu levantamento bibliogrfico, este trabalho apresenta conceitos relacionados aos
sistemas ERP, bem como uma proposta de modelo de ciclo para estes sistemas, com a finalidade de estudar suas diferentes etapas na empresa, procurando estabelecer em cada uma delas
quais so os aspectos mais importantes. So apresentados tambm um levantamento e sistematizao dos benefcios e possveis problemas de sistemas ERP, tais como encontrados na
literatura e em artigos na imprensa especializada, a fim de se estabelecer um quadro de referncia para o estudo.
Na pesquisa emprica realizada, este trabalho procurou identificar e analisar, atravs do
mtodo de estudos de casos mltiplos em 8 empresas, aspectos relacionados ao processo de
escolha, implementao e utilizao do sistema ERP.
Entre os resultados obtidos, destacam-se a anlise da influncia do modo de incio de
operao do sistema nas etapas de implementao e estabilizao do sistema, o detalhamento
de caractersticas do ciclo de vida dos sistemas ERP e a descrio da relao entre a integrao oferecida pelos sistemas ERP e seus benefcios e dificuldades para implementao.

viii

ABSTRACT

The ninetieths witnessed the adoption of ERP (enterprise resource planning) systems
by large corporations. These companies are using these systems to provide the technological
infrastructure they need to conduct their businesses with advantages over custom systems
developed by the internal IT staff. They include enterprise integration features, they update
the information technology used by the company and they may be associated with outsourcing
benefits, such as cost reductions.
This thesis is a study of ERP systems, their characteristics and their selection, implementation and utilization processes, as well as their benefits, disadvantages and impacts on
the adopting organizations. The main objective is to review the literature about this subject
and to contribute to the development of a theoretical model of ERP impacts on the organizations.
The literature review presents concepts related to ERP systems and a model of its life
cycle, with the purpose of classifying the aspects found and associating them with the life
cycles phases. It is also presents an analysis of ERP systems benefits and disadvantages.
The empirical research was conducted by a multiple-case study in eight companies, and
its objective was to identify and analyze aspects of ERP systems in the studied companies.
Among the conclusions, there is an analysis of the impacts of go-live option in the
implementation and stabilization phases, and a description of the relation between ERP systems integration and its benefits and implementation difficulties.

CAPTULO 1
O PROBLEMA DE PESQUISA

1.1 Introduo
Os anos 90 assistiram ao surgimento e a um expressivo crescimento dos sistemas ERP
(enterprise resource planning, ou planejamento de recursos empresariais) no mercado de solues de informtica. Entre as explicaes para esse fenmeno esto as presses competitivas
sofridas pelas empresas e que as obrigaram a buscar alternativas para a reduo de custos e
diferenciao de produtos e servios, forando-as a reverem seus processos e suas maneiras
de trabalhar. As empresas reconheceram a necessidade de coordenar melhor as atividades de
suas cadeias de valores, para eliminar desperdcios de recursos, reduzir custos e melhorar o
tempo de resposta s mudanas das necessidades do mercado. Segundo Porter e Millar (1985),
a TI uma ferramenta poderosa para essa transformao, principalmente porque a TI est
aumentando muito a habilidade das empresas para explorar as interligaes entre as suas
atividades, tanto interna quanto externamente empresa. Um dos principais atributos dos
sistemas ERP justamente esse: so sistemas de informao integrados, que permitem interligar e coordenar as atividades internas das empresas.
Segundo Alsne (1999), a idia de sistemas de informao integrados existe desde o incio da utilizao dos computadores em empresas, na dcada de 60. Porm, uma srie de dificuldades de ordem prtica e tecnolgica no permitiram que esta viso fosse implementada
em grande parte das empresas. A esse respeito, Bancroft, Seip e Sprengel (1998) afirmam que
no passado os programas customizados eram a fundao do processamento corporativo.
Tradicionalmente, estes programas eram desenvolvidos internamente pela equipe de informtica e eram modificados medida que as necessidades da empresa se alteravam. Em muitos casos, esses sistemas eram desenvolvidos a pedido de um departamento da empresa. A
viso destes departamentos era naturalmente limitada por sua responsabilidade operacional.
Cada departamento definia ainda seus dados de acordo com seus prprios objetivos e prioridades. [...] Isto se refletia no software desenvolvido pelo departamento de informtica.
Davenport e Short (1990) afirmavam, no incio da dcada de 90, que a TI havia sido
utilizada at ento para automatizar atividades dentro de departamentos sem uma viso integrada dos processos. Buscava-se um aumento na eficincia local, mas desconhecia-se a performance do processo a qual esta atividade estava ligada. Segundo os autores, cada depar-

tamento (vendas, crdito, faturamento, etc.) achava que tinha otimizado a sua performance,
mas o processo como um todo era lento e ineficiente, e, quando a TI era empregada, era
usualmente com a finalidade de acelerar ou automatizar componentes isolados de um processo. Isso criou problemas de comunicao entre os processos e barreiras para o seu redesenho. Os autores afirmam tambm que um grande problema no redesenho de processos interfuncionais o fato de que muitos dos sistemas de informao do passado foram desenvolvidos para automatizar reas funcionais especficas, ou parte de funes. Poucos pacotes
foram desenvolvidos para dar suporte a processos completos. Poucas organizaes identificaram e criaram modelos de processos interfuncionais existentes ou os redesenharam, e as
empresas tero problemas substanciais para desenvolver sistemas interfuncionais sem tais
modelos.
Dessa maneira, a ausncia do enfoque em processos e as presses para a soluo de
problemas locais sobre os departamentos de TI levaram ao desenvolvimento de sistemas isolados nas empresas, embora existisse a possibilidade de construo de sistemas totalmente
integrados. Como resultado, as empresas terminaram por ficar dependentes de uma srie de
sistemas diferentes, cujas interfaces dependem de trabalho manual sujeito a erros, e tornaramse incapazes de fornecer informaes de qualidade a respeito da empresa como um todo.
Os sistemas ERP surgiram, ento, explorando a necessidade de rpido desenvolvimento
de sistemas integrados, ao mesmo tempo em que as empresas eram (e ainda so) pressionadas
para terceirizarem todas as atividades que no pertenam ao seu foco principal de negcios.
Contriburam tambm para a expanso dos sistemas ERP o amadurecimento das opes disponveis no mercado, a evoluo da tecnologia utilizada por esses pacotes (bancos de dados
relacionais, processamento cliente/servidor) e algumas histrias de sucesso de empresas no
incio da dcada.
No que se refere TI propriamente dita, os sistemas ERP representam uma mudana no
modelo de desenvolvimento de sistemas, por meio da terceirizao da anlise e desenvolvimento. Ao invs de contar com equipes de analistas de sistemas e programadores que fazem o
trabalho de levantamento de requisitos com os usurios e o desenvolvimento dos sistemas,
compra-se o sistema pronto, j desenvolvido. Alm do foco no negcio principal, esta alternativa traz a vantagem da reduo do tempo de desenvolvimento (anlise e programao), a
reduo do backlog de aplicaes (fila para o desenvolvimento) e a possibilidade de reduo
de custos de informtica. A reduo de custos de informtica pode ser resultado da troca de

plataformas de hardware mais caras por plataformas mais modernas (um processo conhecido
como downsizing) e da reduo do nmero de funcionrios do departamento de informtica.
Outro apelo dos sistemas ERP a disponibilizao de conhecimentos acumulados a respeito de diferentes maneiras de se realizar processos. Isto decorre do fato de as empresas fornecedoras utilizarem-se de modelos de processos obtidos atravs de estudo e comparao em
diversas empresas (benchmarking), as chamadas melhores prticas. Este conhecimento
agregado empresa no processo de implementao. Essas melhores prticas, em associao
integrao dos departamentos, podem permitir redues de mo-de-obra indireta, principalmente nos setores administrativos da empresa.
No final da dcada de 90, a utilizao de sistemas ERP j estava consolidada como soluo para a construo da infra-estrutura tecnolgica das empresas e dificilmente o desenvolvimento interno de um sistema que atenda s mesmas funes j contempladas pelos sistemas ERP seria novamente considerado.
De acordo com dados de uma pesquisa da IDC-International Data Corporation, publicados na revista Byte Brasil (out/1998), o mercado global dos sistemas ERP movimentaria,
naquele ano, US$ 17,7 bilhes de dlares. Nesse artigo so apresentados tambm os resultados de uma pesquisa realizada no Brasil, pela DRC, em 150 empresas. Entre essas empresas,
38,8% j eram usurias de algum sistema ERP. Meirelles (1997), que realiza uma pesquisa
anual entre empresas brasileiras que utilizam a TI, apresenta em seu relatrio os seguintes
dados relativos utilizao de pacotes: 81 % das empresas pesquisadas usam algum pacote,
de maneira parcial ou total, e 31 % das empresas pesquisadas utilizam um pacote integrado. A
pesquisa foi realizada entre novembro de 1996 e abril de 1997, e teve 974 respostas vlidas
entre 1200 pesquisadas.
Tambm no final da dcada, o mercado assistiu a um movimento das grandes empresas
fornecedoras de sistemas ERP em direo a mercados ainda no-atendidos. De acordo com
Kulmar e Hillegersberg (2000), as evidncias atuais sugerem que as notcias sobre o fim dos
sistemas ERP foram um tanto quanto prematuras. Alm do fato de que os fornecedores ainda esto comeando a avanar sobre um mercado relativamente inexplorado na Europa e nos
Estados Unidos, o das empresas de tamanho mdio (citando pesquisa realizada por Everdingen et al.), os autores comentam que os fornecedores esto apenas iniciando seu trabalho em
pases como a China, o Brasil e a ndia, alm de somente agora estarem iniciando avanos em
direo a companhias diferentes de sua tradicional base de clientes de manufatura e logstica,
tais como empresas de servios, empresas de telecomunicao, seguradoras e bancos.

1.2 Formulao do Problema

Como exposto no item anterior, a adoo de sistemas ERP transforma a empresa em
pelo menos trs maneiras: a terceirizao do desenvolvimento de aplicaes transacionais,
reduzindo custos de informtica, a implementao de um modelo de empresa integrada e centralizada e a mudana da viso departamental para a viso de processos, por meio dos modelos disponibilizados pelo sistema.
Por todos os seus apelos, os sistemas ERP terminaram por se tornar irresistveis pacotes, que trazem embutidos em si a reengenharia de processos, o benchmarking, a mudana da
viso departamental para a viso de processos, ferramentas que permitem o controle de toda a
cadeia de valor da empresa, a inovao tecnolgica, a reduo do backlog de aplicaes da
rea de informtica e redues de custo, principalmente no que se refere mo-de-obra indireta e ao departamento de informtica. No toa que esses apelos foram explorados pelas
empresas fornecedoras que procuraram vender os sistemas ERP como soluo final para todos
os problemas empresariais da atualidade.
Slater (1999), comentando a respeito da necessidade de um processo formal e extenso
para a seleo do fornecedor de sistemas ERP, afirma que empresas compram sistemas que
custam milhes de dlares para depois descobrir que no funcionam ou pelo menos no
funcionam bem para um de seus principais processos de negcio. Segundo o autor, uma
das razes para isso que os sistemas ERP esto de tal maneira na moda e a imprensa e
consultores insistem tanto em suas possibilidades, que muitas empresas embarcam nessa soluo sem fazer o estudo necessrio.
No h dvida de que os sistemas ERP so uma poderosa soluo para a construo da
arquitetura de TI das empresas, e que, se implementados mediante processos de deciso, seleo e implementao bem conduzidos, possam trazer inmeros benefcios para a empresa.
Entretanto, necessrio analisar com cuidado os benefcios e vantagens propostos pelos sistemas ERP, procurando-se diferenciar o que pode e o que no pode ser obtido com o uso desses sistemas e quais so os problemas e obstculos que se podem esperar quando se decide
utiliz-los.
Segundo Davenport (1998), certo que os sistemas empresariais podem trazer grandes recompensas, mas os riscos so altos tambm. Conforme diz o autor, o principal perigo
trazido pela utilizao dos sistemas ERP ocorre quando a empresa que os est implementando
desconsidera os impactos dos pressupostos do pacote, isto , dos modelos de negcio que

esto embutidos neles. Empresas que tm como filosofia a operao descentralizada, por
exemplo, podem no obter os benefcios de um sistema cuja filosofia a completa integrao
da empresa.
Quanto implementao desses sistemas nas empresas, Bingi, Sharma e Godla (1999)
afirmam que a mesma causa mudanas macias nas organizaes, e devem ser cuidadosamente gerenciadas para que os benefcios possam ser obtidos. Os autores relatam alguns
casos de implementaes mal sucedidas, onde os projetos foram interrompidos, causando
grandes prejuzos s empresas. Segundo eles, uma boa preparao antes da implementao
chave para o seu sucesso.
possvel ento perceber a importncia dos processos de DECISO pela utilizao de
pacotes integrados, de ESCOLHA do pacote, sua IMPLEMENTAO, e que a UTILIZAO
de sistemas ERP pode implicar em mudanas na organizao, seja em relao maneira como
os processos so executados ou em relao prpria estrutura organizacional. O conhecimento desses elementos pela direo da empresa fundamental para que se obtenham os
BENEFCIOS que esses sistemas possam oferecer e minimizar as DIFICULDADES relacionadas. Segundo Laudon e Laudon (1996), o impacto dos sistemas de informao dependem
em parte das decises tomadas pelos dirigentes a seu respeito, pois, afinal de contas, so os
dirigentes que decidem que sistemas sero desenvolvidos, o que eles faro, como sero implementados e assim por diante. De certa maneira, so os dirigentes que escolhem os impactos que querem (ou, pelo menos, recebem os impactos que merecem).
Quais benefcios podem ser obtidos atravs da utilizao de sistemas ERP? Quais problemas podem acompanhar a utilizao de sistemas ERP? Como proceder implementao
para que tais problemas possam ser minimizados? Quais as conseqncias para a organizao,
no que se refere sua estrutura organizacional e seus processos? Quais desafios a empresa
enfrenta aps a implementao? Estes so exemplos de questes importantes, relativas utilizao de sistemas ERP.
1.3 Questo Principal da Pesquisa
A fim de dirigir a realizao do estudo, foi colocada a seguinte questo principal de
pesquisa:

QUAIS benefcios e dificuldades os sistemas ERP trazem s empresas e COMO ocorrem

estes benefcios e dificuldades?

1.4 Objetivos da Pesquisa

Este trabalho, que pretende colaborar para o aprofundamento do conhecimento sobre os
sistemas ERP, tem como objetivo principal descrever e analisar como ocorrem os processos
de deciso, seleo e implementao e utilizao de sistemas ERP, verificando, nas empresas
pesquisadas, quais benefcios e dificuldades ocorreram, como e porque ocorreram, buscando
contribuir para o delineamento de um modelo terico que relacione estes benefcios e dificuldades s caractersticas dos sistemas ERP e ao contexto onde esses sistemas esto inseridos.
O estudo foi conduzido a partir de levantamento bibliogrfico e realizao de pesquisa
emprica, com a finalidade de observar o fenmeno de maneira abrangente, descobrir novos
aspectos importantes e gerar novas hipteses, contribuindo para o desenvolvimento de um
corpo de conhecimentos mais completo a respeito da implementao e utilizao de sistemas
ERP em empresas.
Em seu levantamento bibliogrfico, este trabalho apresenta conceitos relacionados aos
sistemas ERP, bem como uma proposta de modelo de ciclo para estes sistemas, com a finalidade de estudar suas diferentes etapas na empresa, procurando estabelecer em cada uma delas
quais so os aspectos mais importantes. So apresentados tambm um levantamento e sistematizao dos benefcios e possveis problemas de sistemas ERP, tais como encontrados na
literatura e em artigos na imprensa especializada, a fim de se estabelecer um quadro de referncia para o estudo. Na pesquisa emprica realizada, este trabalho procurou identificar e analisar, atravs do mtodo de estudos de casos mltiplos (8 empresas), aspectos relacionados ao
processo de escolha, implementao e utilizao do sistema ERP. A fim de se limitar o escopo
do trabalho, a pesquisa de campo se restringiu a empresas industriais nacionais que j implementaram um dos principais pacotes disponveis no mercado. A restrio a empresas industriais foi oportuna, pois os pacotes integrados foram originalmente concebidos para este tipo de
organizao, tendo a, portanto, maior maturidade.
1.5 Justificativas
Este estudo pretende contribuir como referncia para as empresas que estejam analisando a possibilidade de utilizao ou j utilizem um sistema ERP, assim como para as empresas
que fornecem tais sistemas. As questes pesquisadas podem contribuir para facilitar a tomada
de decises, para melhorar o desenvolvimento de estratgias de implementao e utilizao,
no caso das empresas clientes, e contribuir para o desenvolvimento de produtos e servios, no

caso de empresas fornecedoras. No mbito acadmico, este estudo poder ser til atravs da
reunio de bibliografia a respeito de sistemas ERP e sistematizao de conhecimentos sobre
este assunto. Embora exista vasta literatura a respeito de processos de implementao de alguns sistemas ERP especficos (com caractersticas basicamente tcnicas) e bastante informao na imprensa especializada a respeito dos produtos disponveis no mercado e seus problemas de implementao, existem poucas anlises mais aprofundadas que sigam alguma base
terica sobre as caractersticas essenciais dos sistemas ERP e de seus potenciais benefcios e
problemas. A literatura cientfica consultada a respeito da implementao de TI em geral
mostrou-se bastante ampla, mas at o momento so poucos os trabalhos especficos a respeito
da implementao de sistemas ERP. Alm disso, a utilizao de um nico sistema integrado
que abrange todas as funes informatizadas da empresa, disponibilizando as informaes
para todos os departamentos no momento em que so inseridas no sistema, um fenmeno
ainda recente em muitas empresas e seus desdobramentos ainda esto ocorrendo, seja no que
se refere organizao como no que se refere prpria tecnologia em si. Este trabalho poder
identificar alguns desses desdobramentos, servindo como base para futuras pesquisas.
1.6 Organizao da Dissertao
Alm desta introduo, a dissertao compreende os seguintes captulos:
CAPTULO 2: Sistemas ERP, onde so apresentadas e discutidas suas caractersticas
CAPTULO 3: Ciclo de Vida de Sistemas ERP, onde apresentado um modelo para a
evoluo destes sistemas nas empresas que deles se utilizam, compreendendo as etapas de
deciso e seleo do fornecedor, implementao e utilizao
CAPTULO 4: Benefcios e Dificuldades dos Sistemas ERP, onde so apresentados e
organizados os achados na literatura a respeito dos benefcios que as empresas buscam obter
pela utilizao dos sistemas ERP e das dificuldades e problemas associados
CAPTULO 5: Metodologia da Pesquisa, onde a metodologia utilizada para a pesquisa
emprica definida e justificada
CAPTULO 6: Estudos de Caso, onde so apresentados os relatos dos oito casos analisados, bem como consideraes individuais a respeito de cada um deles
CAPTULO 7: Concluses e Recomendaes, onde so apresentadas as concluses derivadas da anlise combinada dos casos, e recomendaes prticas, baseadas tambm nos fatos observados nos casos

CAPTULO 2
SISTEMAS ERP

2.1 Sistemas de Informao

De acordo com Laudon e Laudon (1996), sistemas de informao (SI) podem ser definidos tecnicamente como um conjunto de componentes inter-relacionados que coletam (ou
recuperam), processam, armazenam e distribuem informao com a finalidade de dar suporte
tomada de decises e controle em uma organizao. [Alm disso,] os sistemas de informao podem tambm auxiliar gerentes e trabalhadores a analisar problemas, a visualizar formas complexas e a criar novos produtos. Ainda segundo os autores, sob um enfoque empresarial, os sistemas de informao podem ser definidos como uma soluo organizacional e
gerencial, baseada em tecnologia da informao, em resposta a um desafio apresentado pelo
meio ambiente. Esta definio salienta o papel da organizao como um todo no planejamento de sistemas de informao, como soluo ou parte de soluo de um problema real,
imposto pelo ambiente em que a empresa opera.
2.2 Tipologia de Sistemas de Informao
Ainda segundo Laudon e Laudon (1996), os SI podem ser classificados de acordo com o
nvel hierrquico onde so tomadas as decises a que do suporte. Alm dos trs nveis da
clssica diviso da empresa (operacional, ttico e estratgico), os autores incluem uma camada adicional entre o nvel operacional e o ttico, denominada nvel de conhecimento
(knowledge level). Neste nvel da organizao estariam engenheiros, advogados, cientistas,
analistas de marketing, analistas financeiros e de controladoria, cujo trabalho consiste principalmente na criao de novas informaes e conhecimento.
Os sistemas que atendem s necessidades operacionais so chamados pelos autores de
sistemas de processamento transacional (TPS transaction processing systems). Os TPS esto ligados s transaes e operaes do dia-a-dia que do suporte aos negcios da empresa,
tais como entrada de pedidos de vendas, emisso de notas fiscais, liberao de crdito, requisies de materiais e lanamentos de produo. So sistemas altamente estruturados, pois
tanto os dados que sero entrados no sistema como as maneiras pelas quais sero processados
so previamente conhecidas. O objetivo dos TPS o de registrar estas transaes e disponibi-

lizar as informaes para os empregados e supervisores diretamente envolvidos. Exemplos

destes sistemas so sistemas de pedidos, faturamento, folha de pagamento e de contabilidade.
Segundo os autores, duas caractersticas dos TPS se destacam: eles ampliam as fronteiras da organizao, pois atravs deles realizado o contato com clientes, fornecedores, bancos
e eles so a base de fornecimento de informao para os demais sistemas. Alm disso, eles
so chamados de sistemas de misso-crtica, pois uma interrupo em seu funcionamento
pode prejudicar a operao da empresa.
Os sistemas que do apoio aos trabalhadores no nvel do conhecimento das empresas
tm o objetivo de facilitar a criao, distribuio e integrao de conhecimentos e informaes criados ou adquiridos aos negcios da empresa. So dois os tipos apresentados pelos
autores: os sistemas para trabalho em conhecimento (KWS knowledge work systems) e os
sistemas de automao de escritrio (OAS office automation systems). Os KWS so sistemas que auxiliam no processo de criao da informao, tais como sistemas de automao de
engenharia (CAD/CAM computer-aided design / computer-aided manufacturing). Utilizados de maneira mais geral dentro da empresa, os OAS gerenciam documentos internos e a
comunicao entre os funcionrios. Exemplos desses sistemas so as planilhas eletrnicas, os
editores de texto e os correios eletrnicos.
No nvel gerencial das empresas esto as atividades realizadas pelas gerncias mdias
relacionadas monitorao e ao controle das atividades realizadas no nvel operacional. Os
autores apresentam dois tipos de sistemas desenhados para dar suporte a estas atividades: os
sistemas de informaes gerenciais (MIS management information systems) e os sistemas
de apoio deciso (DSS decision support systems). Os MIS fornecem resumos das transaes operacionais realizadas nos TPS, permitindo aos gerentes acompanhar o seu andamento e
comparar o seu desempenho com padres estabelecidos ou com o comportamento do ms ao
ano anterior. So sistemas estruturados, pois trazem informaes previamente estabelecidas,
pouco flexveis, utilizadas nas decises gerenciais de rotina e so orientados apenas ao interior da empresa. Exemplos destes sistemas so relatrios semanais e mensais de vendas, resumidos por produto ou rea de vendas. Os DSS do suporte a decises menos rotineiras e estruturadas, mais dificilmente conhecidas de antemo. Eles incluem ferramentas analticas
mais avanadas, tais como simulao de cenrios e a possibilidade de incluir filtros e reordenar as informaes apresentadas.
No nvel estratgico da empresa as decises so bem menos estruturadas e referem-se
ao posicionamento da organizao frente a mudanas em seu ambiente e ao planejamento das

10

conseqncias internas deste posicionamento. Os sistemas de informao que do apoio aos

gerentes e diretores deste nvel hierrquico devem ser bem menos estruturados e muito mais
flexveis, integrando ferramentas de comunicao e sistemas de recebimento de informaes
de mercado e concorrncia aos sistemas anteriormente apresentados de apoio deciso. Estes
sistemas so conhecidos como sistemas de apoio aos executivos (ESS executive support
systems).
Alm da classificao apresentada, os autores ainda dividem os sistemas pela rea funcional a que atendem. Assim, os sistemas de informao podem atender s reas de vendas e
marketing, produo, recursos humanos, finanas e controladoria. A figura 1 resume as informaes apresentadas.

1tYHLV GD

2UJDQL]DomR

(66

(VWUDWpJLFR

0,6

'66

*HUHQFLDO

.:6

2$6

&RQKHFLPHQWR

736

2SHUDFLRQDO

UHD
)XQFLRQDO

Figura 1 Distribuio dos Sistemas de Informao nos Nveis Hierrquicos da Empresa

Adaptada de Laudon e Laudon (1996)

11

2.3 Sistemas ERP

Os sistemas ERP (enterprise resource planning) podem ser definidos como sistemas de
informao integrados, adquiridos na forma de um pacote de software comercial, com a finalidade de dar suporte maioria das operaes de uma empresa. So geralmente divididos em
mdulos que se comunicam e atualizam uma mesma base de dados central, de modo que informaes alimentadas em um mdulo so instantaneamente disponibilizadas para os demais
mdulos que delas dependam. Os sistemas ERP permitem ainda a utilizao de ferramentas
de planejamento que podem analisar o impacto de decises de manufatura, suprimentos, finanas ou recursos humanos em toda a empresa.
A Deloitte Consulting (1998) define ERP como um pacote de software de negcios
que permite a uma companhia automatizar e integrar a maioria de seus processos de negcio, compartilhar prticas e dados comuns atravs de toda a empresa e produzir a acessar
informaes em um ambiente de tempo real. Segundo a TechEnciclopedya (1999), o ERP
um sistema de informaes integrado que serve a todos os departamentos em uma empresa.
Tendo sido desenvolvido a partir de indstrias de manufatura, o ERP implica no uso de pacotes de software ao invs de sistemas desenvolvidos internamente ou apenas para um cliente. Os mdulos do ERP podem ser capazes de interagir com outros sistemas da organizao,
com grau de dificuldade varivel, e, dependendo do fornecedor, o ERP pode ser alterado
atravs de programao.
A sigla ERP foi cunhada por uma empresa americana de pesquisa, o Gartner Group. A
inteno era definir esses sistemas integrados como uma evoluo dos sistemas MRP II (manufacturing resource planning, ou planejamento dos recursos de produo). De acordo com
Corra e Gianesi (1994), O princpio bsico do MRP II o princpio do clculo de necessidades, uma tcnica de gesto que permite o clculo, viabilizado pelo uso de computador, das
quantidades e dos momentos em que so necessrios os recursos de manufatura (materiais,
pessoas, equipamentos, entre outros), para que se cumpram os programas de entrega de produtos com um mnimo de formao de estoques. Os sistemas ERP podem, ento, ser considerados uma evoluo do modelo MRP II, pois permitem controlar os demais recursos empresariais (recursos financeiros, recursos humanos indiretos, vendas, distribuio, etc.).
Segundo Hicks (1995), o ERP est essencialmente ligado a garantir que as decises
de manufatura de uma empresa no sejam feitas sem levar em considerao seus impactos
sobre a cadeia de fornecimento, tanto para frente como para trs. Indo mais adiante, as decises de produo so afetadas e afetam todas as outras reas da empresa, incluindo a enge-

12

nharia, contabilidade e marketing. Para tomar melhores decises necessrio levar em considerao todas estas importantes interaes dentro da empresa. O software o meio para
conseguir esta integrao dos processos de deciso. O autor sugere que atravs da utilizao
desses sistemas possvel imaginar uma empresa altamente integrada que receberia pedidos
eletronicamente atravs de EDI (eletronic data interchange, ou intercmbio eletrnico de dados), geraria as listas de material e seqncias de produo automaticamente e de maneira
otimizada, levando em considerao outros pedidos em andamento, quantidades em estoque,
pedidos de compra j colocados e possveis problemas de produo. Uma vez manufaturados
os produtos, estes seriam automaticamente distribudos para os depsitos de maneira a otimizar a relao custo e atendimento ao cliente. Durante o processo, todas as transaes de produo, compras, movimentao de material, vendas, distribuio e contabilidade seriam continuamente atualizadas e a alta direo estaria sempre a par de quo bem tudo estaria correndo. O autor termina por enfatizar que a idia central do modelo o total controle sobre toda a
cadeia de valores e pergunta: colocando qualquer objeo ideolgica de lado, no seria interessante ter controle sobre tudo?.
Embora os conceitos utilizados em sistemas ERP possam ser usados por empresas que
queiram desenvolver internamente os seus aplicativos, o termo ERP refere-se essencialmente
a pacotes comprados. Exemplos de sistemas ERP existentes no mercado seriam o R/3, da
alem SAP, o Baan IV, da Holandesa Baan, o OneWorld da americana JD Edwards, o Oracle
Financials da americana Oracle, o EMS e o Magnus da brasileira Datasul e o Logix, da brasileira Logocenter.
2.4 Caractersticas dos Sistemas ERP
Os sistemas ERP possuem uma srie de caractersticas que tomadas em conjunto claramente os distinguem dos sistemas desenvolvidos internamente nas empresas e de outros tipos
de pacotes comerciais. Essas caractersticas, importantes para a anlise dos possveis benefcios e dificuldades relacionados com a sua utilizao e com os aspectos pertinentes ao sucesso
de sua implementao, so:

Os sistemas ERP so pacotes comerciais de software

Os sistemas ERP so desenvolvidos a partir de modelos-padro de processos
Os sistemas ERP so integrados
Os sistemas ERP tm grande abrangncia funcional
Os sistemas ERP utilizam um banco de dados corporativo
Os sistemas ERP requerem procedimentos de ajuste

13

Os sistemas ERP so pacotes comerciais de software

A idia bsica da utilizao de pacotes comerciais resolver dois dos grandes problemas que ocorrem na construo de sistemas atravs dos mtodos tradicionais de anlise e programao: o no cumprimento de prazos e de oramentos. Segundo Martin (1989), muito j
se escreveu sobre o que h de errado com o processamento de dados hoje em dia, existindo
registros de vrios anos. A construo de sistemas toma muito tempo e seu custo muito
alto. Segundo Gibbs (1994), em mdia, os projetos de desenvolvimento de software ultrapassam o cronograma em 50%. Projetos maiores geralmente ultrapassam mais.
Diversas alternativas tm sido usadas para tentar resolver esse problema, tais como o
uso de novas metodologias de desenvolvimento, a prototipao, a utilizao de ferramentas
CASE (Computer-Aided Software Engineering) e as linguagens e metodologias orientadas a
objeto que tm como objetivo permitir a reutilizao de componentes de software. Entre essas
alternativas tambm est a utilizao de pacotes comerciais de software. Brooks (1987) afirma
que a mais radical soluo para os problemas da construo de software no constru-lo
mais. Segundo o autor, O custo do software sempre foi o de desenvolvimento, no o de replicao. Dividindo esse custo entre diversos usurios, mesmo que poucos, reduz-se radicalmente o custo por usurio.
Os sistemas ERP incorporam modelos-padro de processos de negcios
Processos de negcios podem ser definidos como um conjunto de tarefas e procedimentos interdependentes realizados para alcanar um determinado resultado empresarial. O
desenvolvimento de um novo produto, o atendimento de uma solicitao de um cliente, ou a
compra de materiais so exemplos de processos. Segundo Davenport e Short (1990), uma das
caractersticas dos processos de negcios o fato de que eles normalmente cruzam fronteiras
organizacionais, isto , as tarefas de um mesmo processo podem ser realizadas por diferentes
departamentos em uma empresa.
Assim como os demais pacotes comerciais, os sistemas ERP no so desenvolvidos para
clientes especficos, procurando atender a requisitos genricos do maior nmero possvel de
empresas, justamente para explorar o ganho de escala em seu desenvolvimento. Portanto, para
que possam ser construdos necessrio que incorporem modelos de processos de negcio,
obtidos por meio da experincia acumulada pelas empresas fornecedoras em repetidos proces-

14

sos de implementao, ou elaborados por empresas de consultoria e pesquisa em processos de

benchmarking.
Comentando a respeito do desenvolvimento do pacote R/3, Bancroft et al. (1998) afirmam que [para fazer o sistema] os desenvolvedores da SAP recolheram os requisitos de
diferentes empresas dentro de uma mesma indstria e os combinaram com resultados de estudos das principais empresas de pesquisa. Essa compilao tornou-se a base para o desenvolvimento de cada mdulo dentro do R/3. Dentro deste contexto, o termo melhores prticas
[best practices] usado para representar o sucesso dos processos de negcio padronizados
implementados.
O termo best practices utilizado amplamente por fornecedores de sistemas ERP e consultores para designar esses modelos-padro, mas preciso certo cuidado quanto ao seu real
significado. O Gartner Group (1998), por exemplo, refere-se a esses modelos-padro de processos como average practices (prticas comuns). Davenport (1998) afirma que [no caso
dos sistemas ERP] o fornecedor, e no o cliente, que define o que melhor quer dizer e
que em alguns casos os pressupostos do sistema podem ir realmente de encontro aos interesses da empresa.
Apesar desse cuidado na definio do termo, importante salientar o fato de os sistemas
ERP disponibilizarem um catlogo de processos empresariais criado a partir de um extenso
trabalho de pesquisa e experimentao. O acesso a este catlogo por si s j pode ser interessante para as empresas. Muitas vezes esto includos nesse catlogo processos e funes que
faziam parte dos planos de desenvolvimento de sistemas da empresa, e que, por alguma razo,
ainda no haviam sido implementados. A adoo de um sistema ERP torna-se ento uma
oportunidade para que estes processos sejam realmente incorporados aos sistemas da empresa.
Os sistemas ERP so integrados
Segundo Alsne (1999), existe certa confuso entre os termos empresa integrada e
sistemas integrados pois o primeiro um objetivo e o segundo um meio para atingi-lo.
Segundo o autor o objetivo final [da integrao da empresa por meio de sistemas informatizados] no interconectar os sistemas informatizados existentes ou que sero implementados
no futuro, mas sim construir um todo empresarial coerente a partir das vrias funes que se
originam da diviso do trabalho nas empresas. Ressalte-se ainda que h diferena entre os
termos empresa integrada por meio de sistemas informatizados e empresa integrada, pois
este segundo objetivo pode ser alcanado por outros meios, alm da utilizao de sistemas

15

informatizados. Genericamente os sistemas integrados podem ser caracterizados como sistemas informatizados que so utilizados em conjunto por membros de diferentes departamentos
dentro de uma mesma organizao.
Os sistemas ERP realmente integrados so construdos como um nico sistema empresarial que atende aos diversos departamentos da empresa, em oposio a um conjunto de sistemas que atendem isoladamente a cada um deles. Entre as possibilidades de integrao oferecidas por sistemas ERP esto o compartilhamento de informaes comuns entre os diversos
mdulos, de maneira que cada informao seja alimentada no sistema uma nica vez, e a verificao cruzada de informaes entre diferentes partes do sistema. Um exemplo a verificao de notas fiscais de entrada, no recebimento, comparando-as com os dados de pedidos de
compra e garantindo o recebimento apenas com preos e quantidades corretos. Outra possibilidade o fornecimento instantneo de informaes, assim que so alimentadas no sistema,
para todos os mdulos que delas se utilizem. Segundo Burch e Grudnitski (1989), a integrao um poderoso elemento no desenho [de sistemas de informao] devido crescente necessidade de coordenao e sincronizao de operaes dentro e fora das organizaes, e
as organizaes devem ser vistas como sistemas nicos, formados de partes interdependentes que formam um todo unificado. O objetivo dos sistemas integrados disponibilizar um
fluxo de informaes em vrios nveis e interdepartamental que possa dar suporte a essa interdependncia.
Conforme os conceitos apresentados por Alsne (1999), importante ressaltar que o
fato de um sistema ERP ser integrado no leva necessariamente construo de uma empresa
integrada. O sistema meramente uma ferramenta para que este objetivo seja atingido.
importante tambm diferenciar o termo integrao do sistema ERP do termo integrao de aplicaes (application integration) e integrao interempresarial. O termo integrao de aplicaes representa as possveis customizaes, desenvolvimentos e utilizao de
outros pacotes para realizar a comunicao entre o sistema ERP e outros sistemas utilizados
pela empresa, tais como sistemas de suporte deciso, automao de fora de vendas e
CAD/CAM. Embora integrados no todo da arquitetura de TI da empresa, no uma integrao nativa como no caso da observada internamente aos sistemas ERP. O termo integrao
interempresarial representa as possveis customizaes, desenvolvimentos e utilizao de pacotes complementares para permitir a conexo do sistema ERP da empresa a sistemas de outras empresas, sejam elas clientes, fornecedores, bancos, governo ou outros parceiros.

16

Os sistemas ERP utilizam um banco de dados corporativo

Entre as diversas formas de se desenvolver sistemas totalmente integrados est a utilizao de um nico banco de dados centralizado, denominado banco de dados corporativo. Isto
interpe desafios organizacionais significativos para a empresa, entretanto, as dificuldades de
implementao so em geral plenamente compensadas pelas vantagens que esta soluo traz
consigo. Esta prtica em geral preconizada pelos sistemas ERP.
Os sistemas ERP possuem grande abrangncia funcional
Uma diferena entre os sistemas ERP e os pacotes de software tradicionais a abrangncia funcional dos primeiros, isto , a ampla gama de funes empresariais atendidas. Normalmente, no caso dos demais pacotes, apenas uma funo empresarial atendida, possivelmente com maior profundidade do que atravs da utilizao de um sistema ERP. A idia dos
sistemas ERP cobrir o mximo possvel de funcionalidade atendendo ao maior nmero possvel de atividades dentro da cadeia de valor. Ainda assim, claro, existem pacotes especialmente desenvolvidos para o atendimento de determinadas funes empresariais que superam
os sistemas ERP no atendimento a essas funes. Exemplos desses pacotes seriam sistemas de
planejamento de capacidade finita e CAD/CAM que possuem funcionalidades que no so
cobertas pelos atuais sistemas ERP. A necessidade de utilizao destes sistemas obriga, por
vezes, o trabalho de criao de interfaces de comunicao entre os ERP e outros sistemas.
Os sistemas ERP requerem procedimentos de ajuste
A ADAPTAO o processo por meio do qual o sistema ERP preparado para ser
utilizado em uma determinada empresa. Segundo Lucas (1985), improvvel que um pacote
v atender exatamente aos requisitos da empresa, o que gera discrepncias entre os dois [o
pacote e a empresa]. Como ser discutido mais adiante, quando a etapa de implementao
de sistemas ERP for detalhada, a adaptao pode ser entendida como um processo de eliminao dessas discrepncias, ou diferenas, entre o pacote e a empresa.
2.5 Outros Conceitos Relacionados aos Sistemas ERP
Alm das caractersticas apresentadas, outros conceitos importantes relativos aos sistemas ERP so: funcionalidade, mdulos, parametrizao, configurao, customizao, localizao e atualizao de verses.

17

A FUNCIONALIDADE o conjunto total de funes embutidas em um sistema ERP,

suas caractersticas e suas diferentes possibilidades de uso. A composio destas funes forma o sistema de informaes transacional que d suporte aos processos de negcio. Mais genericamente, o termo funcionalidade utilizado para representar o conjunto total de diferentes
situaes que podem ser contempladas e diferentes processos que podem ser executados no
sistema. Um exemplo seria uma empresa que desejasse controlar os descontos praticados por
seus vendedores, impondo limites sobre o montante mensal concedido. Seria necessrio que o
sistema contemplasse essa determinada funo (controle de descontos concedidos) com essa
determinada caracterstica (limite com base no montante mensal) para que isto fosse possvel.
Desta maneira, tal situao deveria estar includa no conjunto de funcionalidades do sistema.
Os MDULOS so os menores conjuntos de funes que podem ser adquiridos e implementados separadamente em um sistema ERP. Normalmente, tais conjuntos de funes
correspondem a divises departamentais de empresas (vendas, financeiro, produo, etc.).
Exemplos de mdulos so: contabilidade, contas a pagar, contas a receber, pedidos, faturamento, planejamento de produo. O mdulo de contas a pagar, por exemplo, compreende as
funes de controle de compromissos de pagamento, emisso de cheques, baixa em compromissos, e demais funes necessrias ao processamento das atividades relativas ao departamento de contas a pagar de uma empresa. Os sistemas ERP so divididos em mdulos para
possibilitar que uma empresa implemente apenas aquelas partes do sistema que sejam de seu
interesse, e, mesmo que a empresa deseje implementar todo o sistema, possa faz-lo em etapas para simplificar o processo. Alm disso, a diviso conceitual de um sistema ERP em mdulos facilita a compreenso de seu funcionamento e a diviso de responsabilidades entre os
usurios. Embora os mdulos normalmente sigam a diviso departamental das empresas, desenvolvimentos recentes dos sistemas ERP, tais como mdulos de atendimento ao cliente e
gerenciamento da cadeia de suprimentos, parecem estar incorporando o conceito da diviso da
empresa em processos.
A PARAMETRIZAO o processo de adequao da funcionalidade de um sistema
ERP a uma determinada empresa atravs da definio dos valores de parmetros j disponibilizados no prprio sistema. Parmetros so variveis internas ao sistema que determinam, de
acordo com o seu valor, o comportamento do sistema. Segundo Martin e McClure (1983),
uma boa possibilidade de parametrizao a chave para (1) fazer pacotes se adaptarem s
organizaes com um mnimo de necessidade de mudana e (2) evitar custos de manuteno. Segundo estes autores, pacotes parametrizveis so divididos em partes, cada parte

18

disponibilizando uma funo ou caracterstica separada. O pacote projetado de maneira a

permitir ao usurio que selecione apenas aquelas caractersticas que deseja usar definindo
os parmetros apropriados. Um exemplo de parametrizao seria, em um processo de recebimento de cheques pr-datados, a empresa aceitar apenas cheques pr-datados acima de um
determinado valor. Se existir no sistema a possibilidade de definir esse valor, ento possvel
parametrizar o sistema para adequ-lo empresa. Davenport (1998) cita outro exemplo, um
parmetro que definisse que tipo de controle de estoque, FIFO ou LIFO, seria utilizado. A
parametrizao para adequao de um sistema ERP empresa s possvel se as funcionalidades alternativas j estiverem embutidas no sistema. A parametrizao importante para os
sistemas ERP, pois a maneira pela qual os fornecedores podem garantir seu ganho de escala
no desenvolvimento. Quanto mais parametrizveis, maior o nmero de possibilidades de realizao de processos contemplados pelo mesmo sistema sem necessidades de alterao e desenvolvimentos

posteriores,

e,

portanto,

maiores

os

ganhos

para

fornecedor.

CONFIGURAO o nome dado ao conjunto total de parmetros aps a sua definio, representando o conjunto das opes de funcionamento das diversas funes de um sistema
ERP.
A CUSTOMIZAO a modificao de um sistema ERP para que este possa se adequar a uma determinada situao empresarial impossvel de ser reproduzida atravs dos parmetros j existentes. Esta modificao pode ser feita pelo prprio fornecedor a pedido do cliente, alterando o cdigo dos programas-padro do sistema ERP, ou pelas prprias empresas
clientes, construindo programas ou mdulos que se comunicam com o sistema base do ERP e
que complementam a funcionalidade necessria. importante salientar que apesar de qualquer tipo de customizao poder ser feita para adaptar um sistema ERP s necessidades imediatas do cliente, quanto maior for a quantidade de customizaes realizadas, mais o sistema
utilizado se afasta do modelo de sistema ERP e mais se aproxima do modelo de desenvolvimento interno de aplicaes. Os custos de manuteno crescem, pois muitas vezes os fornecedores no do suporte para rotinas altamente customizadas. Problemas podem surgir quando
instalada uma nova verso do sistema, uma vez que todas as customizaes feitas nas verso
anteriores podero ter que ser refeitas ou adaptadas para uso na nova verso. Segundo Laudon
e Laudon (1996) medida que as modificaes feitas a um pacote aumentam, tambm aumentam os custos de sua implementao. Quando o nmero de linhas de cdigo alteradas
aproxima-se de 5 % do total de linhas do programa, os custos so multiplicados por 5. Segundo Martin e McClure (1983), alguns usurios modificam os pacotes quando estes so

19

instalados e depois descobrem que eles se tornam caros para manter. Alm disso, o fornecedor muitas vezes atualiza o pacote de maneiras que invalidam as alteraes feitas.
A norma implcita portanto adaptar a empresa ao sistema ERP, evitando customizaes. Segundo Martin e McClure (1983), quaisquer mudanas necessrias devem vir do fornecedor do pacote.
A LOCALIZAO a adaptao (atravs de parametrizaes ou customizaes) de
sistemas ERP desenvolvidos em um determinado pas para a utilizao em outro, considerando aspectos como impostos, taxas, leis e procedimentos comerciais. No caso da adaptao
para a utilizao no Brasil, a localizao comumente referida pelo termo tropicalizao.
A ATUALIZAO DE VERSES, ou upgrading, o processo pelo qual o fornecedor disponibiliza aumentos na funcionalidade e correes de problemas e erros para instalao
na empresa. No caso de sistemas complexos como os ERPs, as atualizaes de verso podem
exigir esforos significativos da empresa envolvida.
2.6 A Arquitetura de Sistemas ERP
Davenport (1998) divide os ERP em quatro blocos: financeiro, recursos humanos, operaes e logstica, e vendas e marketing. Exemplos de mdulos do bloco financeiro seriam
contabilidade, contas a pagar, contas a receber, fluxo de caixa. Exemplos do bloco de recursos
humanos seriam a folha de pagamento, gerenciamento de recursos humanos e controle de
despesas de viagem. Exemplos de mdulos de operaes e logstica seriam o gerenciamento
de estoques, o MRP, o faturamento. Exemplos de mdulos de vendas e marketing seriam processamento de pedidos e gerenciamento e planejamento de vendas.
O autor apresenta ento um esquema apresentando a estrutura de um sistema ERP, enfatizando que no corao de um sistema empresarial est um banco de dados central que
recebe e fornece dados para uma srie de aplicaes que suportam as diversas funes de
uma empresa. A utilizao de um banco de dados central agiliza dramaticamente o fluxo de
informaes atravs do negcio. O esquema est apresentado na figura 2.
A respeito do banco de dados central, no caso do SAP R/3, Bancroft et al. (1998) afirmam que a idia bsica por trs do SAP R/3 era desenvolver um nico banco de dados para
toda a empresa sem qualquer redundncia e com definies claras a respeito de cada campo.
Sobre este banco de dados, um conjunto completo de aplicaes de software foi desenvolvido,
fornecendo toda a lgica necessria ao processamento de dados da corporao. O software

20

foi desenhado para dar suporte aos processos de negcio, ao invs de funes de negcio.
Esse banco de dados centralizado deve, preferencialmente, ser um banco de dados relacional,
pois caractersticas de integridade das transaes e disponibilizao de um dicionrio de dados so fundamentais, para garantir o correto suporte s operaes da empresa.

'LUHomR H
$FLRQLVWDV
5HODWyULRV
0yGXORV GH
)LQDQoDV
0yGXORV GH
9HQGDV H
'LVWULEXLomR

&OLHQWHV

)RUoD GH
9HQGDV H
6HUYLoR
DR
&OLHQWH

%DQFR GH
'DGRV

0yGXORV GH
0DQXIDWXUD

&HQWUDO

3HVVRDO GH
6XSRUWH

$GPLQVWUDWLYR
H 0DQXIDWXUD

)RUQH
FHGRUHV

0yGXORV GH
6HUYLoR DR
0yGXORV GH

&OLHQWH

(VWRTXH H
0yGXORV GH

6XSULPHQWRV

5HFXUVRV
+XPDQRV

(PSUHJDGRV

Figura 2 Arquitetura de um Sistema ERP Extrada de Davenport (1988)

Os sistemas ERP mais atuais so construdos utilizando-se a arquitetura clienteservidor, que pode ser definida como uma estrutura de processamento onde um computador, o
cliente, requisita servios de processamento de outro computador, o servidor. A conexo entre
estes computadores feita atravs de protocolos de rede, locais (LANs local area networks)
ou remotas (WANs wide area networks). Essa arquitetura oposta arquitetura dos mainframes, na qual o processamento centralizado e o computador central utiliza-se de terminais
para a comunicao com o usurio.
Lewis (1996) define a arquitetura cliente-servidor como computao distribuda onde
a aplicao dividida em pelo menos duas partes: uma executada por um ou mais computadores servidores e a outra por um ou mais computadores clientes. Para tanto, os clientes
devem estar conectados aos servidores por algum tipo de rede.

21

A arquitetura cliente-servidor dividida em trs tipos de processamento: duas camadas

(two-tier), trs camadas (three-tier) e n camadas (n-tier). Cada um destes tipos representa a
quantidade de computadores (servidores e cliente) envolvidos no processamento. No caso dos
ERP, por exemplo, as aplicaes podem ser divididas em trs partes principais: a apresentao
dos dados, os programas que processam as transaes e o banco de dados. Estes trs componentes podem estar localizados todos no mesmo computador (arquitetura mainframe tradicional), divididas em dois computadores na arquitetura cliente-servidor em duas camadas, com o
computador servidor realizando o processamento do banco de dados e dos programas e o
computador cliente realizando o processamento da apresentao, e finalmente, em uma arquitetura cliente-servidor de trs camadas, o banco de dados pode ser processado em um servidor, chamado de servidor de banco de dados e os programas processados em um segundo
servidor, chamado de servidor de aplicaes e o cliente realizando a apresentao dos dados.
A maioria dos ERP disponveis hoje permite a utilizao da arquitetura de trs camadas, que
tem a vantagem da escalabilidade, isto , facilidade de aumentar o poder de processamento
em passos incrementais, adicionando mais servidores, medida que a necessidade de velocidade de processamento cresce. O processamento cliente-servidor de trs camadas est representado na figura 3.
CAMADA 1
APRESENTAO

CAMADA 2
APLICAO

CAMADA 3
BANCO DE DADOS

BANCO
DE
DADOS
CLIENTE requisita dados da
APLICAO

APLICAO processa os dados

e retorna o resultado ao CL IENTE

APLICAO requisita dados

para o BANCO DE DADOS

BANCO DE DADOS retorna os

dados APLICAO

Figura 3 Sistemas Cliente/Servidor em Trs Camadas

Extrada de Bancroft et al. (1998)

22

2.7 Sistemas ERP como Espinha Dorsal do Processamento Corporativo

Pode-se considerar o ERP como um sistema TPS e MIS, e, dependendo das caractersticas implementadas, tambm DSS e ESS. Mas, trata-se basicamente de um poderoso TPS, a
infra-estrutura sobre a qual uma empresa pode construir seus sistemas de informaes gerenciais. De acordo com a Deloitte Consulting (1998), muitas empresas consideram os sistemas
ERP como um backbone, ou espinha dorsal, sobre o qual novas funcionalidades podem ser
obtidas atravs da integrao de outros softwares e componentes de outros fornecedores, tais
como sistemas DSS, ESS, automao de fora de vendas e comrcio eletrnico. A respeito
disso, Taurion (1998) afirma que os ERP devem ser vistos realisticamente como core
applications [aplicaes centrais] e praticamente todas as organizaes tero suas aplicaes bsicas baseadas neles. Podemos at imaginar que ter um ERP ser algo to comum
como a posse do Windows. Entretanto, o autor ressalta que embora a ausncia de um ERP
possa ser prejudicial ao negcio, sua presena no ser diferenciadora em relao concorrncia. Sero necessrias aplicaes especficas, voltadas para as caractersticas de cada
negcio, bem como para suportar adequadamente o supply chain e o e-business. A princpio
a idia do ERP era suprir a base dos sistemas de informao (TPS e MIS), mas, forados pelas
necessidades dos clientes, os fornecedores esto caminhando rapidamente para uma integrao em todos os nveis de sistemas de informao.

23

CAPTULO 3
O CICLO DE VIDA DE SISTEMAS ERP

3.1 O Ciclo de Vida de Sistemas

O ciclo de vida representa as diversas etapas pelas quais passa um projeto de desenvolvimento e utilizao de sistemas de informao. Em sua forma tradicional o ciclo de vida inclui as etapas de levantamento de requisitos do sistema, definio de escopo do projeto, anlise de alternativas, projeto do sistema, codificao, testes, converso de dados e manuteno.
Dois exemplos de modelos de ciclo de vida so o modelo waterfall, ou linear, onde as etapas
so executadas em seqncia uma nica vez para cada sistema, e o modelo de prototipao,
em que sucessivas repeties de todas as etapas vo refinando incrementalmente o produto
final at que este esteja pronto para ser efetivamente implementado. A noo de ciclo de vida
tambm incorpora a idia de que sistemas passam por fases sucessivas de crescimento, evoluo e declnio, e que ao final deste ciclo devem ser substitudos por outros sistemas que possam melhor atender as necessidades das empresas. As fases do ciclo de vida tradicional do
tipo linear, de acordo com Lucas (1985), esto no quadro 1.

Incio
Pesquisa Preliminar
Estudo de viabilidade
Anlise dos processos existentes
Anlise das alternativas
Estimativas de custo
Anlise do Sistema
Detalhamento dos processos existentes
Anlise de Requisitos
Levantamento das necessidades dos usurios
Definio de escopo
Desenho
Desenho do sistema ideal
Revises para tornar o desenho ideal vivel

Especificaes
Processos lgicos
Desenho de tabelas
Requisitos de programao
Definio de procedimentos
manuais
Programao
Testes
Treinamento
Converso e Instalao
Operao
Manuteno
Melhorias

Quadro 1 Ciclo de Vida de Sistemas Linear, adaptado de Lucas (1985)

24

3.2 Ciclos de vida de Pacotes Comerciais de Software

O ciclo de vida de pacotes comerciais deve ser considerado de maneira diferente dos
modelos de ciclo de vida tradicionais, pois no se trata efetivamente de um desenvolvimento
interno de sistemas proprietrios, mas, sim, de uma aquisio e adaptao de um sistema comercial desenvolvido externamente de maneira genrica para atender a diversas empresas. A
fase de levantamento de requisitos, por exemplo, difere totalmente da fase de levantamento de
requisitos tradicional. Nesta etapa, as funcionalidades e caractersticas de diversos produtos
disponveis no mercado devem ser apresentadas aos usurios para que se possa verificar a
adequao destas aos processos da empresa.
Segundo Carney (1998), comentando a respeito de sistemas desenvolvidos a partir de
componentes comerciais, o mtodo tradicional de definio de requisitos direto: descrevese o sistema desejado atravs de uma srie de condies que ele deve atender. Entretanto, a
definio de requisitos muito diferente quando se adquire sistemas baseados em componentes comerciais, j que pelo menos alguns dos requisitos devem ser flexveis o suficiente
para acomodar as flutuaes do mercado. O autor complementa seu raciocnio afirmando
que no caso de sistemas comerciais ou os requisitos so estabelecidos a partir de sistemas
existentes ou devem possuir flexibilidade suficiente para serem atendidos por um dos produtos disponveis no mercado. Outras diferenas apresentadas pelo autor esto nas fases de teste,
onde basicamente os sistemas so considerados como caixas pretas, e o que se testa na verdade so possveis parametrizaes do sistema, e na fase de manuteno, onde o trabalho realizado basicamente o de fazer as atualizaes do pacote conforme disponibilizadas pelo fornecedor.
Referindo-se utilizao de pacotes como alternativa para desenvolvimento de sistemas, Lucas (1985) apresenta duas etapas de sua utilizao: a aquisio, que compreenderia a
escolha do fornecedor, e a implementao. Martin e McClure (1983) apresentam uma srie de
consideraes a respeito da fase de aquisio, incluindo questes que devem guiar a deciso
pela utilizao de pacotes e uma discusso a respeito de clusulas contratuais. Os autores no
discutem a fase de implementao do pacote, mas mencionam a fase de utilizao, citando a
possibilidade de dificuldades na manuteno aps a implementao. Laudon e Laudon (1996)
relacionam as etapas de parametrizao e customizao de pacotes comerciais s fases de
anlise do sistema, anlise dos requisitos, desenho e programao do ciclo de vida tradicional.
Os autores tambm apresentam a fase de manuteno de pacotes, ressaltando os processos de

25

correo de problemas, atualizao e implementao de melhorias nos pacotes. As etapas

mencionadas esto apresentadas no quadro 2.

Anlise do Sistema
Identificao do Problema
Anlise dos Requisitos
Identificao dos possveis fornecedores
Avaliao dos pacotes versus desenvolvimento interno
Seleo do pacote
Desenho
Adaptar os requisitos s caractersticas do
pacote (mudana em procedimentos ou
customizao)
Treinamento do depto. de informtica
Projeto das customizaes
Projeto das mudanas em procedimentos

Programao
Instalao do pacote
Implementao das customizaes
Desenho das interfaces
Documentao
Converso
Teste
Treinamento dos usurios
Operao
Manuteno
Melhorias
Atualizao

Quadro 2 - Ciclo de Vida de Pacotes Comerciais - Adaptado de Laudon e Laudon (1996)

3.3 Teorias de Implementao de TI
Cooper e Zmud (1990) apresentam um resumo das pesquisas realizadas a respeito da
implementao de TI em empresas. De acordo com os autores, as pesquisas nesse campo se
dividem em pesquisa sobre fatores, sobre processos e pesquisas sobre aspectos polticos. As
pesquisas sobre fatores estudam toda a variedade de foras individuais, organizacionais e tecnolgicas que so importantes para a efetividade da implementao de sistemas. Entre os fatores que essas pesquisas verificaram possuir um grande impacto esto o apoio da alta direo e
o relacionamento adequado entre os usurios e os responsveis pelo desenho do sistema. A
pesquisa sobre processos encara a implementao de TI como um processo de mudana organizacional e estuda os aspectos envolvidos com base em teorias a respeito deste assunto. As
pesquisas polticas reconhecem que os envolvidos em implementaes possuem interesses e
encaram o resultado de uma implementao de TI como o resultado de um jogo entre as
diversas foras ou faces polticas existentes dentro da empresa. Segundo essa linha de
pesquisa, o sucesso de uma implementao depende do gerenciamento dessa diversidade de
interesses.
Os autores apresentam ento um modelo de processo de implementao de TI construdo a partir da literatura a respeito de mudana organizacional, inovao e difuso tecnolgica,

26

desenvolvido por Kwon e Zmud (1987) e posteriormente adaptado por Zmud e Apple (1989).
Esse modelo prope 6 estgios para o processo de implementao e fundamentado na teoria
de mudana organizacional de Lewin (1952). As etapas definidas por esse modelo so: iniciao, adoo, adaptao, aceitao, rotinizao e incorporao (infusion).

Iniciao : Processo atravs do qual os problemas da organizao e as possibilidades da

TI so examinados at que se localize uma possibilidade de aplicao da TI como soluo
de um problema organizacional. Corresponde etapa de incio do modelo tradicional de
ciclo de vida apresentado.

Adoo : Processo de negociao entre os interessados na empresa que termina com a

aprovao do projeto de implementao e dos investimentos necessrios.
Adaptao : So todos os processos atravs dos quais a aplicao de TI desenvolvida,
instalada e manutenida . Nessa etapa os procedimentos organizacionais so revistos e os
usurios so treinados tanto nos novos procedimentos como no uso da TI. Como resultado
essa etapa a aplicao est disponvel para o uso na empresa.
Aceitao : Processo atravs do qual os usurios so induzidos a se comprometerem com
o uso da aplicao, e ela torna-se empregada nos processos organizacionais.
Rotinizao : Processo atravs do qual o uso da aplicao encorajado como uma atividade do dia-a-dia, deixando de ser responsabilidade do departamento de TI e de ser percebida como alguma coisa extraordinria.
Incorporao: Processo atravs do qual a efetividade e eficincia organizacional so finalmente ampliadas pelo uso da TI. Atravs desse processo, obtm-se o total potencial da
tecnologia implementada.

Note-se que na proposta deste trabalho o termo implementao refere-se a uma das etapas do processo, enquanto que os autores denominam implementao o processo que vai desde o reconhecimento de que existe um problema organizacional, passa pelas etapas de projeto,
desenho e desenvolvimento de uma soluo de TI para esse problema e vai at o ponto em
que atravs da TI obtm-se ganhos de eficincia e eficcia organizacional. Lai e Mahapatra
(1997) denominam esse processo de transferncia completa de TI.
3.4 Proposta para Ciclo de Vida de Sistemas ERP
Assim como os demais pacotes comerciais os sistemas ERP apresentam diferenas em
seu ciclo de vida em relao aos modelos de ciclo de vida tradicionais. Entretanto, os sistemas
ERP apresentam grandes diferenas em relao aos pacotes comerciais tradicionais no que se
refere abrangncia funcional e viso de processos refletida na integrao entre seus diversos mdulos. Os pacotes considerados pelos autores em suas anlises eram de maneira geral
pacotes departamentais isolados.

27

Para a definio de uma proposta de modelo de ciclo de vida para sistemas ERP foram
utilizados como base os modelos de ciclo de vida tradicionais, as caractersticas e etapas de
ciclo de vida de pacotes comerciais de software apresentadas no item anterior, os modelos de
implementao de TI apresentados, as caractersticas especficas dos sistemas ERP e uma
reviso da literatura existente a respeito da seleo, implementao e utilizao de sistemas
ERP. A literatura sobre implementao de sistemas ERP relativamente extensa, mas seu
enfoque geralmente tcnico e relativo a pacotes especficos. Pode-se citar Bancroft et al.
(1998), Lozinsky (1996) e Davenport (1998). A proposta para o ciclo de vida de sistemas ERP
apresentada na figura 4.

Novas necessidades,
Conhecimento acumulado
Parmetros j estabelecidos

DECISO E
SELEO

Pacote
Selecionado
Plano de
Implementao

IMPLEMENTAO

Fase n

UTILIZAO

Fase 2

Fase 1
Fase 2
Fase n

Fase 1

Mdulos parametizados,
customizados
Dados migrados
Usurios treinados

Figura 4 - Ciclo de Vida de Sistemas ERP Elaborada pelo autor

Este modelo composto pelas etapas de deciso, escolha, implementao e utilizao.
As etapas de deciso e escolha ocorrem uma nica vez, e as etapas de implementao e utilizao ocorrem em sucessivas iteraes, muitas vezes simultaneamente. Cada uma destas iteraes representa uma etapa de implementao que conduz, ao seu trmino, a uma nova fase
na utilizao do sistema onde mais funes esto implementadas e integradas. E cada sucessiva etapa de implementao recebe novas demandas e restries decorrentes da fase de utilizao em que o sistema ERP se encontra. Quanto mais mdulos implementados, menores as

28

possveis variaes de parametrizao para os mdulos que esto sendo implementados, devido s restries impostas pelos mdulos j definidos e em utilizao. Em contrapartida, medida que mais mdulos esto implementados, maior o conhecimento acumulado sobre o sistema e, portanto, maior a facilidade em explorar suas possibilidades.
A etapa de deciso e seleo no modelo proposto equivale s etapas de iniciao e adoo no modelo apresentado por Cooper e Zmud (1990). A etapa de implementao corresponde s etapas de adaptao e aceitao e a etapa de utilizao corresponde s etapas de rotinizao e incorporao. Entretanto existe uma diferena entre o modelo proposto pelos autores
e o proposto por este trabalho. Nesse ltimo, as etapas de implementao e utilizao no so
exatamente seqenciais, mas ocorrem simultnea e iterativamente.
Para as empresas fornecedoras de sistemas ERP que realizam o desenvolvimento destes
sistemas tambm h diferenas no ciclo de vida do desenvolvimento dos sistemas. A fase de
levantamento de requisitos, por exemplo, no realizada internamente com os usurios de
sistema, mas entre inmeras empresas que j se utilizem ou pretendam utilizar os sistemas.
Estes requisitos so utilizados para a construo das melhores prticas. A proposio de um
ciclo de vida especfico para empresas desenvolvedoras de sistemas ERP foge, entretanto, aos
objetivos deste trabalho.
Nos itens seguintes sero apresentadas cada uma das etapas propostas para o ciclo de
vida de sistemas ERP, incluindo uma anlise de seus fatores crticos de sucesso encontrados
na literatura.
3.5 Deciso e Seleo
A etapa de deciso e seleo ocorre apenas uma vez. A empresa deve considerar, na
medida do possvel, os fatores envolvidos na utilizao de sistemas ERP, analisando vantagens e desvantagens do modelo ERP e de cada um dos fornecedores. Por meio da interao
entre o processo de deciso pela utilizao de um sistema ERP como alternativa ao desenvolvimento de sistemas e o processo de levantamento das caractersticas, funcionalidades e possibilidades de cada um dos diferentes produtos disponveis chega-se a definio de qual ser o
pacote implementado. A idia geral do que pode ser realizado por meio do uso dos sistemas
obtida dos fornecedores, em pesquisas, artigos em revistas e visitas a empresas que j estejam
utilizando os sistemas. medida que o conhecimento a respeito das possibilidades aumenta, a
certeza da deciso por um sistema ERP tambm. A etapa de deciso e seleo como proposta
por este trabalho est representada na figura 5.

29

Presses
Competitivas

Possibilidades
e Limitaes
dos Produtos

DECISO

Restries
(tempo,
recursos,
competncias)

SELEO
DO FORNECEDOR
E
IMPLEMENTADOR

Requisitos da
Organizao,
Metodologia do
Implementador

PLANEJAMENTO

Objetivos do Projeto,
Requisitos da
Organizao

Plano de
Implementao

Figura 5 - Etapa de Deciso e Seleo Elaborada pelo autor

Deciso
A deciso pela utilizao de pacotes tem sido associada a uma deciso do tipo fazer ou
comprar na literatura de anlise de sistemas. A favor desta deciso tem sido geralmente apresentado o argumento da reduo de tempo de desenvolvimento e custo. Contra esta deciso
tem sido historicamente apresentada questo da adaptao das funes do pacote s necessidades da empresa. No caso de sistemas ERP, devido sua abrangncia funcional e seu alto
grau de integrao, outros aspectos devem ser levados em considerao.
A definio, logo no incio do projeto, dos objetivos empresariais da implementao de
um sistema ERP fundamental para o processo. A implementao de um sistema ERP um
processo longo, que envolve vrias partes da organizao e que exige a cada momento decises a respeito de como adaptar empresa ao sistema ou vice-versa, decises que transcendem os departamentos, criam novas relaes antes inexistentes e desnudam erros e redundncias em processos. A existncia de objetivos que norteiem essas decises impede que estas
sejam tomadas de maneira local, visando apenas otimizao de um determinado departamento. A fim de se determinarem estes objetivos, as empresas devem proceder a um estudo a
respeito dos sistemas ERP, seus possveis benefcios e potenciais problemas.
Wagle (1998) apresenta um modelo para a tomada de deciso a respeito da utilizao de
sistemas ERP baseado na avaliao de custos e retornos reais previstos. A anlise dos retornos

30

de um projeto de implementao de sistemas ERP apresenta um problema comum aos investimentos em TI onde os retornos tangveis representam apenas uma parte dos retornos e os
retornos intangveis, tais como ganhos em produtividade, so difceis de prever e de associar
apenas TI caso ocorram. Entretanto, muitas vezes so justamente esses os retornos que se
procuram, o que tem justificado muitas vezes decises por projetos de TI, mesmo que no
tragam retornos tangveis. Apesar disso, segundo o autor, a deciso pela utilizao de um sistema ERP s deve ser tomada com base em um fluxo de caixa positivo (hard-return basis),
pois se tratam de projetos onde o perodo de payback muito extenso e o investimento
muito grande. Segundo o autor, a dificuldade e os custos associados implementao de
sistemas ERP significa que a maioria das empresas deveria analisar este investimento puramente atravs de seu potencial de reduo de custos.
Como citado anteriormente, Davenport (1998) analisa esta deciso sob o ponto de vista
da compatibilidade entre a organizao e as caractersticas destes sistemas, ressaltando a necessidade de avaliao da compatibilidade entre a estratgia empresarial e a lgica, ou maneira de fazer negcios, que muitos sistemas empresariais impem. A esse respeito Myers
(1995) afirma que baseando a lgica de seus principais sistemas em pacotes significa, na
maioria dos casos, que voc pretende fazer negcios baseados na maneira em que o software
foi construdo.
Quanto ao tipo de empresa, interessante salientar que, at o momento, a maioria dos
sistemas ERP foram desenvolvidos e implementados com sucesso em empresas industriais.
No momento os fornecedores desses sistemas esto procurando adapt-los para atender empresas de servio e da rea financeira. Se a empresa for do tipo indstria, com certeza contar
com uma quantidade maior de opes, com maior maturidade. Seno, a empresa dever ter
um cuidado adicional, pois os sistemas ERP esto iniciando agora seu ciclo de desenvolvimento nesses setores.
Note-se que h uma diferena fundamental entre o processo de deciso e escolha de um
sistema ERP e processos de escolha de pacotes com menor funcionalidade. A deciso tomada
ser nica e envolver praticamente a empresa inteira. Desta maneira, esta etapa deve envolver os nveis mais altos de direo da empresa.
Seleo
Para a seleo dos pacotes necessrio comparar as alternativas do mercado. Os modelos de comparao de alternativas mediante critrios e pesos bastante interessante. Por meio

31

desse processo, primeiro estabelecem-se os critrios que devero ser utilizados para a comparao e sua importncia relativa. Cada uma das alternativas avaliada, atribuindo-se notas ao
desempenho destas alternativas frente aos critrios analisados. Aquele fornecedor que obtiver
a melhor nota final ser o escolhido.
Uma variao interessante desse processo a sua realizao em duas etapas. Na primeira etapa, a de pr-seleo, considera-se o maior nmero possvel de candidatos, mas com um
nmero reduzido de critrios. Esses critrios devem ser aqueles fundamentais de acordo com
os objetivos do projeto, mas devem permitir uma verificao mais rpida. Nessa etapa de prseleo escolhem-se dois ou trs fornecedores finalistas (ou mais, dependendo da disponibilidade de tempo para o processo) que sero submetidos a um estudo mais rigoroso na etapa de
seleo final. Lozinsky (1996) apresenta como sugestes para os critrios da fase de prseleo a base instalada no pas, a faixa de custo, a qualidade e acessibilidade do servio de
suporte, a anlise prvia de algumas funes consideradas como mandatrias (por exemplo,
mltiplas moedas, mdulos para conexes com clientes e bancos), a disponibilidade de ferramentas de customizao que permitam adaptar o sistema s necessidades da empresa sem
ferir a estrutura do software e o posicionamento do fornecedor no mercado. importante
salientar que cada empresa poder ter diferentes critrios de pr-seleo, dependendo dos objetivos do projeto.
importante envolver as reas usurias nessa segunda etapa de maneira bastante intensiva, deixando bem claro que a escolha de todos. Esse envolvimento dever ser feito com a
participao de todos em palestras e apresentaes realizadas por cada um dos fornecedores
participantes e no processo de atribuio de notas a cada uma das alternativas. Segundo Lozinski (1996), a deciso de adquirir um pacote de software precisa do apoio de todos os
lderes de rea e usurios-chave[principais usurios do sistema] que sero envolvidos no
processo de implementao: deve haver um claro comprometimento com a deciso, de modo
que o projeto seja de todos. O autor d uma sugesto para garantir esse envolvimento: a formao de uma equipe de avaliao de pacotes, que deve ter representantes de todas as reas
envolvidas e ser responsvel pelo parecer sobre as alternativas selecionadas.
Tambm comum utilizar-se de empresas de consultoria para executaram a etapa de
deciso e seleo. Ainda segundo Lozinsky (1996), existem algumas vantagens em utilizar
consultores j no processo de seleo: uma maneira de trazer uma metodologia para fundamentar tecnicamente a deciso e garantir um grau de imparcialidade no processo e se os
consultores tiverem real experincia em selecionar e implementar pacotes, eles podero con-

32

tribuir com informaes prticas sobre os fornecedores e seus produtos. Entretanto, Hecht
(1997) afirma que necessrio tomar cuidado quando se entrega a uma consultoria a tarefa de
selecionar o fornecedor, pois a maioria das grandes consultorias deriva seu faturamento em
implementao de um ou dois fornecedores. Conseqentemente, elas deixam esses fornecedores no topo da lista de opes para seus clientes, bloqueando o estudo de outros sistemas
ERP potencialmente mais adequados.
O critrio que talvez merea o maior peso e que, com certeza, exige maior esforo para
a sua avaliao o grau de atendimento aos requisitos dos usurios. O levantamento desses
requisitos equivale fase de levantamento de requisitos do ciclo de vida de sistemas tradicional. preciso considerar, entretanto, que se trata de um sistema com abrangncia muito maior
do que um normalmente desenvolvido pelas empresas. Dessa maneira, a quantidade de requisitos muito grande, pois envolve a maioria dos departamentos das empresas. Assim, no
possvel realizar esse levantamento de requisitos ao nvel de detalhes exigido pelo desenvolvimento tradicional, onde o sistema ser desenhado do zero. necessrio que se fixe naqueles pontos considerados essenciais pelos usurios, e supor que os detalhes no-essenciais
j estejam por definio embutidos no pacote. A se encontra um dos grandes riscos do processo de seleo, pois muitas vezes as empresas consideram bvios alguns requisitos e imaginam que sero com certeza atendidos pelo pacote. No momento da implementao verifica-se,
com surpresa, que aquela funcionalidade no atendida. Segundo Martin e McClure (1983),
uma das armadilhas dos pacotes de software resulta do cuidado insuficiente em verificar a
adequao do pacote empresa. Sutilezas no percebidas na pressa da compra podem aparecer mais tarde, quando se transformaro em severos problemas de manuteno.
Por isso a importncia da interao entre o processo de levantamento de requisitos e a
seleo do fornecedor. Estas etapas no podem ser realizadas em seqncia uma nica vez.
preciso realimentar o levantamento de requisitos com as observaes obtidas nas apresentaes dos fornecedores para que se tenha uma noo mais clara de quais so os requisitos fundamentais. Alm disso, esse talvez seja o principal ponto para justificar a utilizao de uma
consultoria na seleo do fornecedor. Tendo um maior conhecimento das funcionalidades
disponveis nos produtos do mercado e das funcionalidades exigidas por empresas naquela
determinada indstria o processo de identificao dos requisitos fundamentais torna-se mais
seguro. Entretanto, se membros da empresa j tiverem participado de processos de implementao de sistemas ERP anteriormente, talvez o risco seja minimizado pela prpria participao desses elementos.

33

Embora a funcionalidade deva ser o foco principal do processo de seleo do fornecedor

existem outros aspectos que em conjunto so tanto ou mais importantes. Hecht (1997) afirma
que recomenda-se que o critrio funcionalidade no deva ter mais do que um tero do peso
total na deciso. O autor apresenta cinco outros critrios que devem considerados na seleo
do fornecedor: arquitetura tcnica, custo, servio e suporte ps-venda, bem estar financeiro do
fornecedor e viso tecnolgica do fornecedor. A arquitetura tcnica refere-se s tecnologias
empregadas, tais como a utilizao de bancos de dados relacionais, a arquitetura cliente/servidor, as interfaces grficas, as facilidades para extrao de informaes, a performance,
a escalabilidade, etc. O bem-estar financeiro do fornecedor, segundo o autor, no pode ser
enfatizado o suficiente, e muitas vezes o critrio mais importante na avaliao de um sistema ERP. Isto porque dada a consolidao que dever ocorrer no mercado de ERP nos prximos trs anos [e est ocorrendo] e a importncia de misso-crtica que esses sistemas tem
para as empresas que os utilizam, simplesmente fundamental saber se a tendncia do fornecedor continuar existindo. A viso tecnolgica tambm est relacionada a esse problema.
importante saber qual o futuro do produto que est sendo adquirido em termos de expanso de
funcionalidades e implementao de novas tecnologias.
As consideraes de Martin e McClure (1983) a respeito da aquisio de pacotes de
software tambm so importantes para sistemas ERP. Eles afirmam que um dos principais
pontos a serem observados na aquisio de pacotes a elaborao de um contrato eqitativo
que d segurana empresa cliente. Segundo os autores, um bom contrato deve deixar o cliente seguro de que o software ser utilizvel e manutenvel durante seu tempo de vida esperado, e deve definir claramente a funcionalidade do pacote, a qualidade que deve ser entregue, os servios de suporte e os processos de manuteno e atualizao de verses. As responsabilidades do cliente e do fornecedor devem ser explicitamente definidas em cada um desses
itens. Aspectos como performance, qualidade da documentao e descrio de todos os elementos necessrios para manter o software tambm devem ser considerados. Todos esses aspectos devem ser negociados da maneira mais objetiva possvel, evitando-se termos genricos
ou subjetivos que possam ter dupla interpretao. Segundo os autores, clusulas como o fornecedor se compromete a envidar seus melhores esforos para manter o software em boas
condies de operao devem ser evitadas, sendo substituda por clusulas do tipo o fornecedor manter um perodo de resposta de 4 horas s solicitaes do cliente. A taxa de manuteno bsica inclui atendimento das 8 da manh s 5 da tarde de segunda a sexta-feira, ....
Quanto terminao do contrato, quando esta ocorre por problemas do fornecedor e no so
motivadas pelo no cumprimento dos compromissos do cliente (falncia do fornecedor, por

34

exemplo), os autores sugerem que se insira uma clusula em que o fornecedor se comprometa
a disponibilizar todo o cdigo fonte e documentao para o cliente para que este possa dar
continuidade ao sistema.
Na fase de escolha do fornecedor deve-se ter conscincia de que cada opo de mercado tem
diferenas que vo alm do preo. Cada pacote melhor em determinadas reas de aplicao,
utiliza determinadas tecnologias, tem um determinado esquema de suporte, etc. Isto se deve
ao fato de que cada pacote tem uma histria e origem diferentes. Segundo Lozinsky (1996),
cada diferente pacote surgiu em uma determinada rea de aplicao e a partir da desenvolveu-se. Assim, por exemplo, se a inteno controlar uma empresa transnacional de maneira
centralizada, deve-se procurar um pacote que esteja adaptado a operar em diversos pases e
oferea a opo de centralizao de informaes dispersas. Se a inteno obter o mximo de
funcionalidades na rea financeira, deve-se procurar pacotes que enfoquem esta rea.
Aps o processo de anlise aprofundada das alternativas, devem-se atribuir notas a cada uma
delas em cada uma das caractersticas utilizadas para comparao. Atravs da utilizao dos
pesos, chega-se a uma pontuao final que indica a alternativa superior, considerando-se os
pesos utilizados. Entretanto, Lozinsky (1996) salienta que verdade que um dos pacotes
deve ter tirado a nota mais alta, mas isso em si no condio suficiente para apont-lo
como vencedor e que necessrio um entendimento por parte da equipe que est decidindo
de quais so as diferenas entre cada uma das alternativas para que se avalie realmente qual
a melhor alternativa para a empresa. Atravs dessas consideraes chega-se deciso final.
Alm da seleo do fornecedor de pacotes, pode ser considerada nessa etapa tambm a
seleo de uma empresa de consultoria para auxiliar no processo de implementao, dependendo da estratgia de implementao que a empresa queira adotar. Segundo Lozinsky
(1996), a utilizao de empresas de consultoria na implementao de sistemas desse porte traz
muitas vantagens, tais como a reduo do tempo de aprendizagem e a possibilidade de utilizao de experincia acumulada pelos consultores no gerenciamento de projetos e na configurao dos sistemas. Entretanto, aspectos como a transferncia de conhecimento e preparao
para uma efetiva terminao do processo de consultoria ao final da etapa de implementao
devem ser considerados caso essa seja a opo. Podem ser ento delineadas as seguintes etapas genricas para o processo de seleo:

35

Formao de uma Equipe de Avaliao de Alternativas, que envolva representantes de

todas as reas envolvidas

Levantamento dos requisitos das reas atravs da realizao de reunies com os envolvidos
Levantamento dos requisitos empresariais atravs da realizao de reunies com os nveis
mais altos da empresa
Definio dos critrios da pr-seleo
Pr-seleo de alternativas
Definio dos critrios de seleo e seus pesos. Entre esses critrios esto:
Percentual de atendimento dos requisitos levantados sem que seja necessrio customizar o pacote

Custos, incluindo custos de licena, hardware, outros softwares necessrios, customizaes, treinamento, implementao, manuteno
Arquitetura tcnica e viso de futuro do fornecedor
Qualidade do servio de suporte
Sade financeira do fornecedor e base instalada no pas
Garantias contratuais
Caractersticas especficas, tais como pacote internacional, existncia de um determinado mdulo (p. exemplo exportao), etc.
Anlise aprofundada de cada uma dos produtos finalistas e atribuio de notas, realizada
por meio de apresentaes dos produtos pelos fornecedores, testes e visitas a clientes que
j utilizam o sistema
Comparao final das alternativas e deciso final

Planejamento
Aps a seleo do fornecedor, deve-se proceder ao planejamento do processo de implementao. Bancroft et al. (1998) sugerem alguns passos para esse planejamento, entre os
quais esto a definio do lder do projeto, a formao do comit executivo, a definio do
plano geral de implementao e a estruturao das equipes do projeto.
Segundo os autores, o lder do projeto deve ser um indivduo com uma srie de caractersticas tcnicas e habilidades interpessoais que deve ter experincia prvia na implementao
do sistema ERP, e sugerem o apoio de consultores para esse papel. Lozinsky (1996) sugere
que o papel seja dividido entre um coordenador do projeto da empresa e o consultor responsvel pela equipe de projeto.
O comit executivo tem por objetivo desenvolver o plano geral de implementao, definir as equipes do projeto e acompanhar os resultados do projeto como um todo, bem como
tomar decises que possam exigir liberao de recursos adicionais ou mudanas no cronograma. Esse comit deve ser liderado por um executivo de alto nvel com poder de deciso na

36

organizao. Deve ser composto por executivos das diversas reas que sero afetadas pela
implementao e pelo lder do projeto.
A definio do plano geral de implementao refere-se elaborao da estratgia de
implementao e definio de escopo do projeto. De acordo com Bancroft et al. (1998), a
primeira deciso a respeito da implementao que se deve tomar a definio de quais mdulos sero implementados, onde sero implementados e em que ordem sero implementados.
Essa definio tambm conhecida como estratgia de implementao. Existem basicamente
duas alternativas: implementao em fases, onde os mdulos so implementados sucessivamente, com diferentes datas para incio de operao, ou a implementao completa, onde todos os mdulos so implementados ao mesmo tempo, com mesma data para incio da operao. Essa ltima alternativa conhecida como big-bang. Na implementao em fases tambm se pode combinar alguns mdulos que sero implementados ao mesmo tempo, em cada
uma das fases. difcil definir regras simples para a definio da melhor estratgia, pois isso
depende dos objetivos do projeto, de restries ou mesmo possibilidades da arquitetura tecnolgica existente, da predisposio pela mudana, dos investimentos que se deseja fazer, dos
benefcios que se pretende obter, dos riscos que se deseja correr, entre outros. Os autores ressaltam que a alternativa big-bang s deve ser utilizada caso seja um imperativo para a empresa, pois os riscos so muito altos. A alternativa em fases mais segura e permite que a equipe
de projeto aprenda com a experincia antes de colocar importantes processos da empresa no
novo sistema. Entretanto, ela exige a construo de interfaces entre o sistema ERP e os sistemas antigos, tarefa que exige recursos, tempo e cujo produto final ser totalmente descartado
ao final do projeto. Se a empresa possui mais de uma unidade de negcio ou localidade, existe
ainda uma terceira possibilidade: o projeto piloto, tambm chamado de small-bang pelos
autores. Por meio dessa alternativa, escolhe-se uma unidade de negcio ou localidade (uma
fbrica, por exemplo) de menor porte e importncia para o incio da implementao. Dessa
maneira possvel obter a experincia da implementao simultnea, sem comprometer demais o negcio.
Alm disso, aspectos tais como necessidade de utilizao de informaes entre os mdulos (por exemplo, o plano de contas utilizado na produo deve ser definido no mdulo de
contabilidade) devem ser considerados para a definio da estratgia mais adequada.
Outro elemento importante do plano de implementao, segundo os autores, a definio do escopo de cada uma das fases ou mesmo do projeto como um todo. Sem essa definio

37

muito provvel que o projeto incorra em grandes atrasos, devido a presses para que se aumentem as fronteiras de cada uma das etapas.
Para a estruturao das equipes do projeto, o lder do projeto e o comit diretivo devem
identificar o nmero de equipes necessrias para a implementao e sua composio. Uma das
maneiras de se montarem essas equipes mediante a diviso em mdulos, formando-se uma
equipe para cada mdulo, ou grupo de mdulos muito prximos. Os autores sugerem a proporo de 75 % de indivduos das reas usurias e 25 % de profissionais da rea de TI. Segundo eles, deve-se ter em mente que est se implementando um pacote: no necessrio
desenvolvimento. As decises tomadas pelas equipes sero basicamente a respeito dos processos de negcio. Tambm devem ser previstos os mecanismos para a integrao e comunicao entre os times do projeto, tais como reunies conjuntas, um local comum de trabalho e
participao de membros de uma equipe nos trabalhos de outras equipes. Por se tratar da implementao de um sistema integrado, essa comunicao fundamental.
comum referir-se aos usurios chamados a participarem do projeto como usurioschave (key-users). Segundo Lozinsky (1996) os usurios-chave so usurios do futuro sistema, mas, muito mais do que isso, so as pessoas que vo definir como o sistema vai funcionar
em todos os seus detalhes. So tipicamente pessoas que possuem uma certa autonomia em
sua rea de atuao e lideram naturalmente seus colegas de trabalho. O autor tambm inclui duas equipes adicionais estrutura organizacional do projeto: uma equipe de suporte tecnolgico, que cuida dos aspectos tcnicos da implementao, tais como instalao de computadores e programas, configurao de estaes de trabalho e rede, e uma equipe de suporte
administrativo, que deve dar apoio gerncia de projeto em trabalhos de secretaria, tais como
agendamento de reunies, preparao e distribuio de material, etc.
A estrutura organizacional do projeto, adaptada de Lozinsky (1996) est representada na
figura 6. O autor coloca em sua estrutura original, em lugar de diversas equipes divididas por
mdulos com composio mista entre usurios e tcnicos, apenas trs equipes: uma equipe de
usurios-chave, uma equipe composta por consultores e uma equipe de analistas de sistemas
da empresa.

38

C o m it
E xe c u tivo

G e r n c ia
d o P ro je to
S u p o rte
T e c n o l g ic o

E q u ip e 1

S u p o rte
A d m in is tra tivo

E q u ip e 2

E q u ip e n

Figura 6 - Estrutura Organizacional do Projeto - Adaptada de Lozinsky (1996)

Fatores Crticos de Sucesso da Etapa de Deciso e Seleo

De acordo com Bancroft et al. (1998), os fatores crticos de sucesso da etapa de deciso
e seleo, que tambm inclui uma etapa de planejamento do processo de implementao, podem ser definidos como:

Comprometimento da alta direo com o processo desde o incio

Conhecimento e comunicao para todos os nveis dos benefcios possveis e potenciais
dificuldades dos sistemas ERP
Entendimento de que ser provavelmente necessrio mudar a organizao
Envolvimento dos usurios desde o princpio e obteno de seu comprometimento com a
alternativa selecionada
Escolha de um lder de projeto que possua habilidades de negociao e gerenciamento de
projetos e experincia em realizao de mudanas organizacionais

3.6 A Etapa de Implementao

Embora o termo implementao seja normalmente confundido com o ciclo completo,
ela apenas uma das etapas do ciclo de vida de sistemas ERP. A implementao de um sistema ERP pode ser definida como o processo pelo qual mdulos do sistema so colocados em
funcionamento em uma empresa. Isso significa dar incio utilizao do sistema para processar as transaes empresariais, sendo para isso necessrio que o sistema ERP tenha sido adequadamente parametrizado, customizado (se necessrio), que os dados iniciais tenham sido
inseridos no sistema (normalmente so migrados do sistema anterior), que os processos de

39

negcio tenham sido alterados para adaptar-se utilizao do sistema (se necessrio), que o
equipamento e software que ser utilizado para o processamento (servidores, sistemas operacionais, bancos de dados, redes, microcomputadores) tenham sido adequadamente instalados e
configurados, que os funcionrios que iro operar o sistema e que os supervisores e gerentes
que iro supervision-los e extrair informaes do sistema estejam adequadamente treinados e
que as condies de se obter suporte ou auxlio se necessrio tenham sido disponibilizadas de
maneira adequada. Laudon e Laudon (1996) definem implementao como todas as atividades organizacionais realizadas em direo adoo, gerenciamento e rotinizao de uma
inovao.
Implementao de pacotes
Lucas (1985) apresenta um modelo para implementao de pacotes que introduz o conceito de discrepncia entre o pacote e a organizao. Segundo esse modelo, a implementao
de pacotes basicamente uma busca pela eliminao dessas discrepncias. O modelo est
representada na figura 7.
De acordo com o modelo, o pacote apresentado como uma soluo ao atendimento de
requisitos de sistema gerados a partir da combinao das necessidades impostas pelo ambiente
da organizao e das necessidades e expectativas dos usurios. Entretanto, improvvel que o
pacote combine perfeitamente com os requisitos. O autor chama de discrepncias as diferenas entre a funcionalidade do pacote e os requisitos do sistema. Um exemplo, bastante simplificado, seria o caso de a codificao de itens de estoque utilizada pela empresa exigir 8 dgitos, e o pacote permitir apenas o cadastro de cdigos com 6 dgitos.

40

Necessidades e
Expectativas
dos Usurios

Ambiente da
Organizao

Requisitos do
sistema

DISCREPNCIAS

Demandas sobre o
processo de
Implementao

Funcionalidade
do Pacote

Demandas sobre a
Organizao

Plano de
Implementao

Figura 7 - Modelo de Implementao de Pacotes - Extrada de Lucas

Segundo o autor, durante o processo de implementao, essas discrepncias devem ser
resolvidas de duas maneiras: ou muda-se o pacote, atravs de parametrizao ou customizao, ou mudam-se os procedimentos da organizao. Existem duas maneiras alm dessas:
uma combinao de mudana no pacote e na organizao ou no mudar nem o pacote nem a
organizao, utilizando-se de controles ou normas paralelas.
A alterao dos procedimentos empresa a alternativa mais barata em termos de investimento a curto prazo e tem sido a grande opo. Martin e McLure (1983) analisando a utilizao de pacotes afirmam que a mudana de procedimentos era a preferida por pequenas empresas que no podiam pagar as despesas da alterao de pacotes. Entretanto trata-se de mudana organizacional, e, como toda mudana organizacional, tal alterao tem um benefcio e
um custo. Embora este custo seja difcil de ser medido, ele existe e pode ocorrer, por exemplo, atravs da perda de clientes acostumados com determinado tipo de procedimento que
passa a no ser mais possvel ou com a criao de controles manuais lentos e imprecisos que
terminam por diminuir a eficincia.

41

A alterao do pacote, quando feita mediante customizao, pode levar a uma srie de
custos adicionais que se repetiro enquanto se utilizar o pacote, conforme j citado. Este custo
que no normalmente computado em um projeto de implementao de ERP pode ser bastante alto se somado o tempo gasto na resoluo de problemas, suporte aos usurios e correo de dados. A opo de alterar tanto o pacote como a empresa pode proporcionar um custo
menor, pois pode-se buscar um ponto onde a alterao no pacote seja a menor possvel desde
que se realize alguma alterao na empresa.
No mudar nem o sistema nem a empresa a mais barata de todas, mas ser vivel apenas quando a discrepncia entre pacote e empresa for muito pequena e contornvel por pequenos artifcios. Um exemplo seria um campo de cdigo de produto que aceitasse a digitao
de caracteres alfanumricos (letras e nmeros) mas a empresa deseja utilizar apenas caracteres
numricos. Faz-se um acordo entre os usurios para que no sejam criados novos produtos
utilizando-se de caracteres alfanumricos. O sistema no mudou e o cdigo dos produtos, isto
, a empresa, tambm no. Embora seja a mais barata de todas, s deve ser utilizada em procedimentos de pouca importncia operacional, pois o risco de erros grande. Outra possibilidade seria a realizao de alguns procedimentos por fora, isto , controles em papel ou em
planilhas eletrnicas. As desvantagens dessa alternativa so bvias: sistemas redundantes e
no integrados.
Segundo Lucas (1985), os usurios devem ser envolvidos no processo de identificao e
anlise das discrepncias, bem como nas decises a respeito de como sero resolvidas.
Implementao de Sistemas ERP
Lozinsky (1996) divide a implementao de sistemas ERP em quatro etapas. Bancroft et
al. (1998) tambm apresentam 4 etapas semelhantes, acrescentando passos especficos para o
sistema R/3. Essas etapas e suas subetapas esto resumidas a seguir, com algumas adaptaes.

Fase 1 Levantamento da Situao Atual (As-Is Picture)

Anlise dos processos de negcio atuais

Treinamento das equipes do projeto no pacote
Levantamentos de aspectos especficos do negcio da empresa
Planejamento da converso de dados

42

Fase 2 Definio da Situao Desejada (To-Be Picture)

Preparao do ambiente para prototipao

Prototipao
Levantamento das discrepncias e decises a respeito de como sero eliminadas (atravs
de mudanas no pacote por parametrizao ou customizao ou mudanas em procedimentos e controles da organizao)
Identificao das interfaces, com outros sistemas ou com os sistemas atuais, caso sejam
necessrias
Definio de nveis de acesso, segurana e controle

Fase 3 Configurao, Customizao, Testes

Programao das customizaes planejadas

Programao das interfaces e programas de converso
Desenvolvimento dos novos procedimentos e controles
Testes por mdulo e testes integrados
Treinamento dos usurios finais

Fase 4 Incio da Operao (Going-Live)

Preparao do ambiente de processamento final

Definio do plano para incio da operao
Migrao dos dados
Incio da operao (converso, virada, ou go-live)
O autor ressalta que as fases 1, 2 e 3 e suas subetapas no podem ser consideradas como

uma seqncia rgida e pr-definida de etapas que ocorrem apenas uma vez, j que a natureza
de um projeto desse essencialmente iterativa. Essas fases podem ocorrer simultaneamente,
em uma mesma ou em diferentes equipes de projeto e os resultados de cada uma das etapas
alimentam qualquer uma das demais etapas, da mesma equipe ou de outras equipes.
A prototipao o nome dado ao processo atravs do qual os usurios modelam seus
processos no sistema e realizam testes da maneira mais completa possvel, identificando problemas no previstos, necessidades de configurao em outros mdulos relacionados, problemas de integrao, etc. Faz parte do processo de aprendizagem e conhecimento da soluo. O
nome prototipao dado porque os usurios constroem modelos, ou prottipos, do futuro
sistema durante esse processo, no estando este termo relacionado ao termo prototipao
como metodologia de desenvolvimento de sistemas, embora a natureza iterativa esteja presente em ambos. Uma opo interessante a montagem de um laboratrio de prototipao,
para que os usurios possam fazer a modelagem do sistema e testes de configuraes alterna-

43

tivas. O laboratrio deve ser preferencialmente comum a todos os mdulos para permitir fcil
comunicao e tomada de decises entre as diversas equipes.
O plano para o incio da operao deve definir a estratgia que ser utilizada para desligar um sistema e ligar o outro. Lozinsky (1996) apresenta as seguintes estratgias bsicas: converso direta e processamento paralelo. Na converso direta desliga-se o sistema
anterior e liga-se o sistema atual no mesmo momento. O risco principal dessa estratgia
parar a empresa em caso de problemas. O processamento paralelo pressupe que as informaes sejam entradas por um perodo de tempo nos dois sistemas, at que haja segurana na
utilizao do sistema novo. Embora o risco seja menor, existe a dificuldade em manter dois
sistemas funcionando tanto pelo trabalho dobrado imposto aos usurios como pelas diferenas
entre os dois sistemas, j que nos sistemas novos muitos procedimentos foram eliminados ou
modificados. O autor apresenta ento trs variaes da estratgia de processamento paralelo
que podem torn-la mais vivel: o piloto, o paralelo limitado e o paralelo retroativo. O piloto
a implementao do sistema em uma unidade de negcio ou localidade menor da empresa e
j foi apresentado neste captulo como uma estratgia geral do plano de implementao. O
paralelo limitado um teste do novo sistema que ocorre em paralelo operao do sistema
atual. Apenas uma parte dos dados do dia-a-dia so inseridos no sistema e seus resultados so
comparados aos do sistema atual. No momento em que se acha que h segurana para o incio
da operao, desliga-se o sistema atual e liga-se o novo. Segundo o paralelo retroativo,
digitam-se transaes de um perodo anterior (ms ou semana) para os testes. Deve-se levar
em considerao nessas ltimas duas alternativas que mesmo que os resultados sejam corretos, e batam com os do sistema anterior, existem problemas que s sero percebidos no
momento de operao real do sistemas, tais como velocidades de realizao das tarefas no
dia-a-dia, dependncias das tarefas de outros departamentos, etc.
Proposta de Modelo de Implementao de Sistemas ERP
O modelo da etapa de implementao proposto por este trabalho est apresentado na figura 8. Esse modelo baseado no conceito de que a implementao de um sistema ERP um
processo atravs do qual busca-se a melhor adaptao entre uma TI e a organizao. O processo de implementao realizado em vrias etapas de adaptao, uma para cada mdulo ou
grupo de mdulos, que ocorrem simultnea ou seqencialmente de acordo com o definido no
plano geral de implementao.

44

Adaptao do
Mdulo 1

Plano
Geral de
Implemen
tao

Plano
Detalhado de
Implementao

Treinamento

Adaptao do
Mdulo 2

Adaptao do
Mdulo n

Converso
Incio da Operao
Mdulo 1
Treinamento
Converso
Incio da
Operao
Treinamento
Converso
Incio da
Operao

Figura 8 - Etapa de Implementao - Elaborada pelo autor

O plano detalhado de implementao um cronograma completo com todas as atividades necessrias para o execuo do projeto como um todo, bem como a definio de pontos de
verificao e responsveis por cada uma das atividades. Esse plano deve ser elaborado pelo
lder do projeto e segundo Bancroft et al. (1998), importante que o lder tenha uma boa noo de como se realizam os processos de implementao de sistemas ERP para a construo
desse cronograma. Cada uma das etapas de adaptao composta por uma srie de etapas que
podem ocorrer simultaneamente entre si e entre etapas correspondentes na adaptao de outros mdulos. Na figura 9 est representada a etapa de adaptao de um mdulo ou conjunto
de mdulos qualquer.
A anlise dos processos da empresa e do pacote ocorrem simultaneamente. medida
que as equipes vo aumentando seu conhecimento a respeito do pacote atravs de treinamento
e testes vo podendo visualizar de maneira mais clara como seus processos de negcio podero ser implementados. medida que estudam os seus processos de negcio de maneira mais
estruturada percebem que oportunidades de melhoria existem no novo sistema.
Como exposto anteriormente, a eliminao de discrepncias pode ocorrer modificandose o pacote, a empresa, mudando-se ambos ou nenhum dos dois. No modelo acima se dividiu
a opo modificao do pacote em parametrizao e customizao. A parametrizao no
modifica o pacote em si, apenas determina entre as alternativas possveis de operao aquela
que mais adequada. A customizao implica em desenvolvimento de programas que sero
integrados ou na modificao do prprio sistema ERP.

45

Mudanas em
Procedimentos

Entender o
Processo

Requisitos
e Objetivos
do Projeto

Entender o
Pacote

Identificar
Discrepncias
e Decidir
Eliminao

Parametrizao

Prototipao
e Testes

Mdulo
Adaptado

Customizaes
Adaptao do Mdulo n

Necessidades de
Parametrizao,
Customizao e
Mudanas em Processos
de Mdulos
Relacionados

Necessidades de
Parametrizao,
Customizao e
Mudanas em Processos
Para Mdulos
Relacionados

Figura 9 - Adaptao de um Mdulo - Elaborada pelo autor

Note que o processo de eliminao de discrepncias pode ser rpido, pelo uso de parametrizaes locais ou envolver extensas negociaes entre as diversas equipes. Se forem exigidas customizaes, o processo pode se tornar ainda mais lento, dependendo de como sero
desenvolvidas e da necessidade de se alterar ou no o sistema ERP padro. Muitas vezes a
soluo final das discrepncias pode ser adiada, por consenso dos envolvidos, para etapas
posteriores do projeto, aps a implementao do sistema ERP. Enquanto no so resolvidas,
os usurios comprometem-se a conviver com elas.
Aps a subetapa de adaptao do mdulo, os usurios finais so treinados, os dados so
migrados e inicia-se a operao do mdulo. O aspecto mais crtico a ser considerado a definio do momento em que a subetapa de adaptao do mdulo terminada. Trata-se de um
processo de balanceamento entre diminuio de riscos e cumprimento de prazos. Quanto mais
tempo se investe no estudo, adaptao e teste dos mdulos, menores os riscos de implementao, mas maiores os prazos necessrios. Como o prazo de implementao determinado a
priori, com base em estimativas (dos fornecedores, de empresas de consultoria ou mesmo dos
participantes da empresa) pode haver alguns conflitos que obriguem o incio da operao do
sistema antes do momento oportuno. Tambm no possvel testar todas as possibilidades,
porque muitas s surgiro no dia-a-dia das operaes e porque o prazo se tornaria proibitivo.
Stedman (1999) afirma que a pressa em implementar sistemas ERP nem sempre deixa tempo

46

de colocar tudo no lugar e as empresas tm que voltar para fazer a sintonia fina de seus processos e configurao do sistema. Davenport (1998) afirma que uma implementao rpida
pode ser um bom negcio, uma implementao apressada no, enfatizando a necessidade de
planejamento e gerenciamento para que se possa implementar um sistema ERP dentro de prazos apertados.
Fatores Crticos de Sucesso da Etapa de Implementao
A etapa de implementao bastante crtica para o processo. Segundo Lucas, Walton e
Ginzberg (1988), espera-se que o processo de implementao influencie a medida de sucesso e o impacto de um pacote. A empresa que se concentrar nos fatores associados ao sucesso
da implementao e no processo de implementao deve considerar [a utilizao] do pacote
como um sucesso
A principal dificuldade dessa etapa o fato de que se trata de um processo de mudana
organizacional, que envolve, ao mesmo tempo, mudanas nas tarefas de indivduos, nas tarefas e responsabilidades de departamentos e nas relaes entre os diversos departamentos.
uma mudana que ocorre simultaneamente em trs nveis: individual, departamental e organizacional. Do porte e da complexidade dessa mudana e dos conflitos que ela certamente causar entre os envolvidos, decorre a necessidade de uma intensa participao e comprometimento da alta direo, considerado fundamental por grande parte dos autores.
Segundo Davenport e Short (1990), talvez a maior dificuldade no redesenho dirigido
pela TI [O ERP se enquadra a] seja conseguir e manter o comprometimento da direo. O
autor afirma que gerenciar a mudana em processos como gerenciar outros tipos de mudana, com a exceo de que a natureza interfuncional aumenta o nmero de envolvidos,
aumentando, portanto, a complexidade dos esforos. Essa natureza interfuncional clara no
caso da implementao de sistemas ERP. A mudana de sistemas isolados para um nico
sistema integrado traz embutida a mudana de uma viso departamental da organizao para
uma viso de processos.
Wagle (1988) apresenta como falha comum na implementao de sistemas ERP a falta
de definio clara das responsabilidades dos gerentes de negcio no processo de implementao. Esses gerentes esto na posio de impedir que outras atividades conflitantes com o tempo necessrio implementao prejudiquem o processo. Segundo o autor, esses gerentes devem ser plenamente responsabilizados em caso de atrasos no cronograma e estouro em oramentos da implementao do sistema em suas reas.

47

Outros aspectos crticos so os inmeros processos de tomada de deciso que ocorrem

para a eliminao das discrepncias e sua comunicao para todos os envolvidos. Como essas
decises ocorrem muitas vezes em equipes diferentes, e por tratarem-se de sistemas integrados, importante que sejam comunicadas s demais equipes antes mesmo de serem efetivadas
as medidas. Caso contrrio, corre-se o risco de que a deciso tomada localmente, considerando apenas um mdulo ou processo, interfira de maneira inadequada em outros mdulos. Bancroft et al. (1998) salientam a importncia da comunicao, entre todos os envolvidos, das
decises que so tomadas, em cada uma das etapas e por todas as diferentes equipes. Segundo
os autores, os processos de comunicao que sero utilizados devem ser planejados e postos
em funcionamento logo no incio do projeto e mantidos em operao contnua, pois as pessoas precisam ser informadas diversas vezes a respeito de mudanas. Os autores afirmam
ainda que a chave para o sucesso [do esforo de comunicao] a repetio e o estabelecimento de expectativas adequadas.
Em relao a esse grande nmero de decises tomadas simultaneamente durante a etapa
de adaptao dos mdulos, importante que sejam tomadas tendo em considerao os objetivos gerais do projeto. Sem essa direo, possvel que decises tomadas por uma equipe
contrastem com as decises tomadas por outras equipes simplesmente por no seguirem a
mesma orientao e por preocuparem-se com a soluo de problemas locais. Muitas dessas
decises transcendem os departamentos, criam novas relaes antes inexistentes e apontam
erros e redundncias em processos. Muitas vezes, quando a deciso envolve transferncia de
responsabilidades de um departamento para outro, a deciso deve ser tomada em conjunto
pela gerncia do projeto e pelos departamentos.
Finalmente, improvvel que tudo saia como planejado. A esse respeito, Bancroft e al.
(1998) afirmam: Tenha certeza de que ocorrero problemas: comprometa-se com a mudana.
3.7 A etapa de Utilizao
Aps o processo de implementao, a utilizao do sistema passa a fazer parte do dia-adia das operaes. Orlikovski e Hofman (1997) apresentam um estudo sobre a introduo de
novas tecnologias e relatam a dificuldade em conhecer de antemo todas as suas possibilidades de uso. Este conhecimento s se daria aps certo tempo de uso continuado da tecnologia,
atravs de idias que surgiriam durante o processo de utilizao. Esta uma considerao
importante para a etapa de utilizao de sistemas ERP, pois geralmente no se conhecem to-

48

das as possibilidades de uso no momento da implementao, quando grande parte do esforo

utilizada para fazer combinar o pacote com a organizao. Somente aps esta etapa possvel
vislumbrar novas alternativas e possibilidades de uso na empresa. Desta maneira, a etapa de
atualizao realimenta a etapa de implementao com novas necessidades que possivelmente
sero atendidas por outros mdulos e com condies de contorno, isto , parmetros do
sistema j estabelecidos e em uso que s podero ser alterados mediante nova mudana em
procedimentos operacionais.
A Deloitte Consulting (1998), apresentando os resultados de uma pesquisa realizada em
agosto de 1998 com 64 empresas que j implementaram sistemas ERP e encontram-se na fase
de utilizao, mostra que muitos benefcios obtidos pelas empresas s foram percebidos algum tempo aps o incio das operaes. Segundo a pesquisa, o incio da operao do sistema
(going-live) geralmente o nico objetivo, ou benefcio, atingido aps a implementao. Os
demais benefcios so obtidos em etapas sucessivas, no que a pesquisa chama de segunda
onda (second wave) dos sistemas ERP, medida que a empresa comea a perceber todas as
potencialidades da utilizao dos sistemas. A pesquisa afirma que a segunda onda ocorre
quando finalmente todas as foras do sistema ERP finalmente se juntam: a tecnologia, o redesenho de processos, e, principalmente, as pessoas operando e executando os novos processos. A segunda onda, proposta pela Deloitte (1998), corresponde etapa de utilizao proposta por este trabalho, e etapa de incorporao, no modelo de Kwon e Zmud.
Fatores Crticos de Sucesso da Etapa de Utilizao
Crticos na etapa de utilizao so aspectos como necessidade de implementar as novas
releases (ou verses) do pacote liberadas pelo fornecedor, em um processo conhecido como
atualizao, ou upgrading, e necessidades de realizar mudanas na configurao de parmetros para melhor adaptar o sistema ao uso, num processo conhecido como in-flight reconfiguration(ou reconfigurao durante o vo).
Uma vez implementados, os sistemas ERP mantm-se em evoluo contnua. As empresas fornecedoras buscam incorporar novas necessidades de seus clientes, corrigir problemas encontrados e apresentar novas e melhores maneiras de executar os processos abrangidos
pelos pacotes. O processo de implementao de uma nova verso de um sistema ERP no
simples como aparenta. Cada atualizao pode ter complexidade que varia desde a simples
mudana de uma tela ou processo at a total mudana no pacote, podendo praticamente ser

49

considerada como uma nova implementao. A necessidade de gerenciamento e atualizao

das verses de sistemas ERP uma das principais dificuldades da utilizao de sistemas ERP.
Segundo Davenport (1999), a implementao de sistemas ERP tem sido tratada como
um projeto na maioria das empresas, isto , tem incio, meio e fim. Mas est se percebendo
que um projeto ERP no um projeto, mas um meio de vida. O autor afirma que para obter
os benefcios desejados dos sistemas ERP preciso encar-los dessa maneira, e tomar as medidas gerenciais necessrias, tais como alocao de recursos para um centro permanente de
adaptao do sistema ERP s novas necessidades.
Segundo a Deloitte (1998), os benefcios dos sistemas ERP s podem ser obtidos na
etapa de utilizao se aps a implementao a empresa mantiver o foco e esforos na obteno dos resultados.

50

CAPTULO 4
BENEFCIOS E DIFICULDADES DOS SISTEMAS ERP

4.1 Benefcios dos Sistemas ERP

Ao tomar a deciso pela utilizao de sistemas ERP as empresas esperam obter diversos
benefcios. Entre os apresentados pelas empresas fornecedoras esto principalmente a integrao do sistema, que permite o controle da empresa como um todo, a atualizao tecnolgica, a
reduo de custos de informtica e a disponibilizao de informao de qualidade em tempo
real para a tomada de decises sobre toda a cadeia produtiva.
Lozinsky (1996) cita a reduo dos custos e do quadro funcional da rea de TI, a disponibilizao de informaes em tempo real, a reduo de mo-de-obra decorrente da simplificao de processos administrativos e gerao de relatrios gerenciais, a eliminao de duplicidade de esforos, a disponibilizao de indicadores que permitam avaliar o real desempenho
do negcio e a atualizao tecnolgica.
Bancroft et al. (1998) citam a integrao dos diferentes mdulos, a ampla cobertura funcional que permite a utilizao de um nico sistema para a empresa como um todo, e a disponibilizao de melhores prticas para redesenho dos processos da empresa. Os autores tambm apresentam como benefcios a melhor qualidade na informao fornecida pelo sistema,
atravs da utilizao de um nico banco de dados corporativo.
Davenport (1988) cita a integrao da informao atravs de toda a empresa, a padronizao de procedimentos e a eliminao de inconsistncias entre diversos sistemas. Segundo o
autor, a fim de se compreender a atrao dos sistemas empresariais, necessrio primeiro
entender qual problema eles se destinam a resolver: a fragmentao da informao em grandes empresas. Atravs da utilizao de um nico sistema integrado possvel para as grandes organizaes reduzir custos de manuteno de inmeros sistemas dispersos e obsoletos e
eliminar custos de transferncia das informaes de um sistema para o outro. Mas os principais ganhos, segundo o autor, so obtidos atravs da reduo dos custos indiretos, relacionados falta de coordenao entre as diversas atividades da empresa, tais como vendas, produo e suprimentos. A falta de coordenao pode, entre outras coisas, acarretar problemas na
resposta s necessidades dos clientes e envolver a utilizao de relatrios inconsistentes. O
autor complementa afirmando que um sistema empresarial torna mais eficiente o fluxo de
informaes de uma empresa e disponibiliza direo acesso direto a uma ampla gama de

51

informaes operacionais em tempo real. Em muitas empresas estes benefcios transformamse em ganhos dramticos de produtividade e velocidade.
Hecht (1997) afirma que a padronizao da interface de acesso ao sistema em toda a
empresa leva reduo de custos de treinamento, e que o fato de que toda a operao da empresa estar consolidada em apenas um sistema leva reduo de custos de operao tais como
backup e controle de performance.
Finalmente, a Deloitte Consulting (1998), na citada pesquisa realizada em 64 empresas
americanas, arrola, alm dos benefcios j citados, a melhoria do desempenho dos processos
de negcio, a compatibilidade com o ano 2000, o suporte a processos da cadeia de fornecimento, o suporte a empresas globalizadas, a utilizao do ERP como infra-estrutura tecnolgica, a reduo do tempo do ciclo pedido/produo/entrega, a reduo do nvel de estoques e
o aumento da produtividade.
4.2 Dificuldades e Possveis Problemas Relacionados aos Sistemas ERP
Como qualquer alternativa de desenvolvimento de sistemas de informao, a utilizao
de sistemas ERP traz desvantagens e potenciais problemas, alm dos benefcios esperados.
Especificamente, esta alternativa leva as empresas e departamentos de TI a comprometeremse com um novo modelo de disponibilizao de sistemas de informao e que traz consigo
uma srie de novos desafios.
A principal desvantagem dos sistemas ERP apontada em artigos e na imprensa especializada a grande dificuldade para a sua implementao, que muitas vezes ocorre atravs de
demorados processos que podem levar at 3 anos para serem completados. Tal dificuldade
decorre da necessidade de introduo de mudanas organizacionais profundas, pois as empresas, normalmente orientadas a uma viso hierrquica e departamental, so obrigadas a adaptar-se a uma viso orientada a processos, isto , conjuntos de atividades que cruzam e integram os departamentos. Alm disso, muitas vezes as empresas so obrigadas a mudar seus
procedimentos para adaptar-se s funcionalidades dos pacotes. Devido complexidade do
processo so citados como fatores crticos para a implementao de sistemas ERP o total
comprometimento da alta direo, encarar o gerenciamento do projeto como algo crtico, o
comprometimento dos gerentes usurios pelos resultados, a passagem de responsabilidades
sobre o sucesso do projeto para as reas usurias, o treinamento e a comunicao.
Lozinsky (1996) cita a necessidade de utilizao de uma consultoria externa para a implementao, j que as habilidades de gerenciamento de projeto, de gerenciamento de mudan-

52

as e o conhecimento a respeito do pacote em geral no esto disponveis nas empresas. Em

conseqncia disto o custo final da implementao pode ficar de trs a quatro vezes maior do
que o custo do licenciamento do pacote.
Davenport (1998) ressalta a necessidade de avaliao da compatibilidade entre a estratgia empresarial e a lgica, ou maneira de fazer negcios, que muitos sistemas empresariais impe. Segundo o autor, muitos dos problemas e dificuldades da implementao e utilizao dos sistemas ERP no so tecnolgicos, mas organizacionais. Ele afirma que as empresas falham em conciliar os imperativos dos sistemas empresariais s necessidades da empresa. O modelo embutido nos sistemas empresariais o da integrao total da empresa, e pode
haver casos em que a estratgia geral da empresa no combine com este tipo de enfoque. Segundo o autor se uma empresa apressa-se em instalar um sistema empresarial sem ter um
claro entendimento de suas implicaes para o negcio, o sonho da integrao pode tornarse um pesadelo. O autor tambm apresenta a questo da inflexibilidade dos sistemas ERP em
adaptar-se aos processos da empresa, o que pode exigir que a empresa se adapte ao software.
Para ele, apesar de certo grau de parametrizao e modularizao ser possvel, a extrema
complexidade dos pacotes torna grandes alteraes impraticveis.
O Gartner Group (1998) apresenta a ausncia de flexibilidade e problemas na integrao
com outros aplicativos como problemas dos atuais sistemas ERP. O Gartner Group no acredita que algum milagre v ocorrer no mercado para tornar a flexibilidade inerente s aplicaes e afirma que fica claro que os usurios entraram no mundo dos pacotes pensando que
estes eram mais flexveis do que os programas desenvolvidos internamente: este no o
caso.
Stedman (1998b) apresenta o caso de uma empresa onde o tempo para o processamento
de pedidos triplicou no incio das operaes de um sistema ERP, pois os funcionrios no
estavam inteiramente adaptados nova interface. Cole-Gomolski (1998) apresenta outros casos onde problemas de performance associados aos problemas de adaptao a novas interfaces
tambm prejudicaram a performance de processos nos meses iniciais aps a implementao.
O fato de estes sistemas possurem uma lenta curva de aprendizado pode interpor dificuldades
nos primeiros meses aps a implementao.
Stedman (1998a) apresenta a questo da imediata disponibilizao de informaes alimentadas incorretamente no sistema e relata o caso de uma empresa que tendo adotado um
sistema ERP teve problemas no seu controle de materiais para fabricao devido entrada de
dados incorretos no sistema. Segundo o autor embora a natureza do software esteja inte-

53

grando as empresas como nunca isto pode se tornar uma faca de dois gumes quando erros
so imediatamente propagados pelo sistema.
A mudana cultural um dos aspectos mais crticos na implementao de sistemas ERP.
Appleton (1997) aponta as necessidades de mudana de comportamento na organizao necessrias viso de processos, afirmando que se um departamento operar por suar prprias
regras ento o sistema no ir funcionar corretamente. E prossegue afirmando que as implementaes de sistemas ERP geralmente exigem das pessoas que elas criem novas relaes
de trabalho, dividam informaes que antes estavam bem guardadas e tomem decises que
nunca haviam sido exigidas antes. Esse o tipo de mudana que gera resistncia e confuso,
completa o autor. Bancroft et al. (1998) citam como desafio a grande participao dos usurios nos processos de deciso e implementao e a transferncia da propriedade dos sistemas e
dados para os usurios, com a conseqente carga de responsabilidade e conhecimento necessrio.
Como citado, em outro artigo, Davenport (1999) aponta dificuldades em manter o conhecimento necessrio para a operao continuada dentro da empresa, aps o trmino da fase
de implementao de um sistema ERP. Segundo o autor, o ERP deve ser considerado como
um fenmeno de longo prazo e nas empresas no deve ser considerado como um projeto, mas
como um modo de vida. As empresas devem estar prontas para manterem estruturas de
apoio utilizao dos sistemas ERP. Sobre este aspecto, Johnson (1999) afirma que os clientes esto exigindo que empresas de consultoria em ERP faam os investimentos necessrios
em ferramentas e servios que incorporem a sua experincia acumulada para garantir um
resultado e produto mais consistentes e duradouros.
A complexidade dos sistemas ERP, sua abrangncia funcional e sua integrao levam a
dificuldades nas operaes de manuteno, tais como atualizao de verses, paradas para
manuteno de mquinas, realizao de backups, testes e mudanas de parametrizao durante o uso. Todas essas operaes passam a exigir extensas rodadas de negociao com a
comunidade usuria e muitas vezes deixam o departamento de TI na linha de fogo entre alteraes urgentes, requeridas por um departamento, que no podem ser implementadas devido a
procedimentos de outro departamento. Hecht (1997) afirma que a execuo de atualizaes de
verso, ou qualquer forma de shutdown (parada, ou desligamento do sistema) ou backup no
sistema, exige mais consenso entre os departamentos da empresa em um sistema integrado.
A pesquisa da Deloitte Consulting (1998) apresenta um resumo do que as empresas
consideraram como obstculos e dificuldades durante e aps a implementao de sistemas

54

ERP. Em ambos os casos os aspectos relacionados s pessoas e organizao foram considerados mais importantes do que os aspectos tecnolgicos. Antes da implementao, o gerenciamento da mudana, a adequao do staff interno nova filosofia do sistema e o gerenciamento de projeto foram considerados as maiores dificuldades. Aps a implementao, o gerenciamento de mudanas continua como maior dificuldade, seguido pela necessidade de treinamento, qualidade do suporte oferecido pelo fornecedor e carncias na funcionalidade do
software (este ltimo considerado como aspecto tecnolgico pela pesquisa).
4.3 TI e Vantagem Competitiva: Modelo de Porter e Millar
Para justificar a importncia da TI para as organizaes, Porter e Millar (1885) utilizam
os conceitos de cadeia de valor (value chain) e sistema de valor (value system). Segundo os
autores, a cadeia de valor composta por todas as atividades que uma empresa realiza para
fazer produzir e vender seus produtos. Estas atividades so relacionadas entre si e podem ser
divididas em nove categorias genricas, representadas na figura 10.
A vantagem competitiva vem atravs da criao de valor para os clientes proporcionada
pela soma do desempenho de cada uma das atividades. Segundo os autores, a cadeia de valor de uma firma um sistema de atividades interdependentes, conectadas entre si por meio
de elos. Os elos existem quando a maneira pela qual uma atividade realizada afeta o custo
ou desempenho de outra atividade. Quando se deseja otimizar uma das atividades da cadeia
de valor necessrio estar atento para a influncia desta otimizao em outras atividades relacionadas. Geralmente, segundo os autores, estas otimizaes so conseguidas base de trocas
de custo e desempenho entre tarefas (trade-offs). Um exemplo seria a utilizao de matrias
primas mais custosas, que aumentariam o custo da atividade de logstica de entrada, mas, poderiam resultar em menores custos para a atividade servios de ps-venda.

55

Infra-estrutura
Adm. R. H
P&D
Compras
Atividades
de Apoio

Logstica de
Entrada

Operaes
(Manufatura)

Logstica de
Sada

Marketing e
Vendas

Servios de
Ps Venda

Atividades
Primrias

Figura 10 - A Cadeia de Valores de Uma Empresa - Extrada de Porter (1989)

O sistema de valor composto pela unio das cadeias de valor de diversas empresas clientes e fornecedores formando uma cadeia completa desde a matria-prima at o consumidor
final em uma determinada indstria. Da mesma maneira que existem elos entre as atividades
internas de uma cadeia de valor tambm existem elos que relacionam diferentes cadeias de
valor, dentro de um sistema de valor.
O sistema de valores de Porter tambm conhecido como cadeia de fornecimento (supply chain). Figueiredo e Zambom (1998) definem a cadeia de fornecimento como um sistema constitudo por agentes de deciso envolvidos em um processo interdependente, por meio
de um fluxo de produtos e servios em uma direo, com o objetivo de atender a uma necessidade social. Pode envolver desde fornecedores de matria-prima, a produo propriamente
dita, a distribuio e at consumidores finais. O Supply Chain Council (1999) afirma que
por causa de seu amplo escopo, o gerenciamento da cadeia de suprimento deve enderear
interdependncias complexas, criando uma empresa expandida que alcana muito alm da
porta da fbrica.
A TI adquire importncia estratgica para uma empresa a partir do momento em que
esta possibilita mudanas na maneira de realizar cada uma das atividades da cadeia de valor,
aumentando a sua eficincia individual e principalmente por possibilitar a alterao da natureza dos elos entre as atividades. Segundo Porter (1989), a coordenao das atividades ligadas
reduz os custos de transao, permite melhor informao para finalidades de controle e
substitui operaes mais caras por outras menos custosas, em outros pontos. [...] A adminis-

56

trao cuidadosa dos elos pode ser uma fonte decisiva de vantagem competitiva. Muitos elos
no so bvios e os rivais tm dificuldades em perceb-las, com freqncia. O autor ainda
acrescenta que a obteno da vantagem competitiva exige que a cadeia de valores de uma
empresa seja administrada como um sistema, e no como uma coleo de partes separadas.
Quanto aos elos externos, com as demais empresas em um sistema de valores, o autor afirma
que a vantagem competitiva , cada vez mais, funo da competncia com que uma empresa
pode administrar todo esse sistema. Os elos no s conectam as atividades dentro de uma
companhia como tambm criam interdependncias entre uma empresa e os seus fornecedores
e canais. Uma companhia pode criar vantagem competitiva otimizando ou coordenando melhor essas elos com o lado de fora. Figueiredo e Zambom (1998) afirmam ainda que o desempenho das empresas envolvidas em uma cadeia de produo e distribuio pode ser mantido em estado crnico de ineficincia quando elas so administradas isoladamente, isto ,
sem levar em conta suas interdependncias dentro do sistema. O JIT e o Kanban so algumas tcnicas que foram empregadas com esta finalidade.
4.4 Os Sistemas ERP e a Cadeia de Valores
Os sistemas ERP apresentam uma caracterstica bastante importante de acordo com o
modelo de Porter e Millar (1985): eles so totalmente integrados, isto , so um sistema nico
que d suporte a todas as atividades da cadeia de valores da empresa. Essa caracterstica dos
sistemas ERP pode permitir que a empresa administre a cadeia de valores como um sistema
nico, integrado. Segundo os autores, disso depende cada vez mais a possibilidade de as empresas conseguirem obter vantagens competitivas.
Por meio desse modelo, a obteno de benefcios e possivelmente de vantagens competitivas com o uso de sistemas ERP depende de a empresa utiliz-los para coordenar melhor as
ligaes entre as suas diversas atividades.
4.5 TI e Redesenho de Processos
Segundo Davenport e Short (1990), assim como as idias de Taylor revolucionaram as
empresas no incio do sculo atravs da decomposio do trabalho em tarefas e sua medio,
objetivando a aplicao de princpios cientficos para a obteno de ganhos de produtividade,
as idias da reengenharia, ou redesenho de processos (BPR - business process redesign) tiveram o mesmo impacto no final dos anos 80. Segundo os autores, os princpios da administra-

57

o cientfica, cristalizados na engenharia de produo, tiveram uma grande influncia no

planejamento de atividades de manufatura. Entretanto, com o avano da importncia econmica das atividades de servio e das atividades de informao dentro das empresas, essas atividades tambm passaram a ter a necessidade de serem alvo de anlises e redesenho, visando
sua melhoria. Os autores reforam que muitas destas atividades de negcio so desenhadas,
isto , definidas, de maneira ad-hoc, e localmente dentro de departamentos, sem que haja uma
viso global. Assim, o timo local no necessariamente o timo global, o que refora a necessidade de redesenho. O autor afirma que as atividades de negcio devem ser vistas como
mais do que uma simples coleo de tarefas individuais ou funcionais; elas devem ser divididas em processos, que podem ser desenhados para mxima efetividade, tanto na manufatura
como em servios.
Por que a necessidade de se analisar processos, e no mais atividades? Para os autores,
Taylor podia, no incio do sculo XX, focalizar tarefas individuais porque o ambiente de negcios era altamente estvel. Contudo, no final do mesmo sculo esta estabilidade no existe,
as tarefas mudam mais rpido do que o tempo necessrio para planej-las, e a responsabilidade pelo resultado mais dividida entre grupos do que atribuda a indivduos. A necessidade de
coordenao de atividades interdependentes, ou seja, processos, surge da necessidade de desenvolver e coordenar grupos flexveis, capacitados para a mudana.
Ainda segundo Davenport e Short (1990), a relao entre TI e o redesenho de processos
uma via de mo dupla. Os autores afirmam que TI e BPR tem uma relao recursiva [...]
cada uma delas a chave para se pensar a respeito da outra. Grover, Teng e Fiedler (1998)
afirmam que as tecnologias de informao esto tendo um importante papel na reorganizao organizacional e projetos de reengenharia. Esta relao est apresentada na figura 11.
Seguindo o princpio da recursividade entre TI e BPR, Davenport e Short (1990) afirmam que um procedimento de redesenho de processos deve passar obrigatoriamente por uma
etapa onde as oportunidades oferecidas pela utilizao de TI so consideradas. Segundo os
autores, o processo tradicional em que primeiro se determinam os requisitos de um processo
para depois se desenvolver o sistema deixa de lado este aspecto, e o papel da TI em um processo deveria ser considerado nas primeiras etapas de seu redesenho. Os autores destacam
oito possibilidades de uso da TI, apresentadas no quadro 3, e afirmam que a TI uma ferramenta to importante que merece uma etapa prpria no redesenho de processos, e pode de
fato criar novos desenhos de processos, ao invs de apenas dar suporte aos antigos.

58

Como a TI pode ser

utilizada nos processos
da empresa?

TI

BPR
Como os processos da
empresa podem ser
transformados
utilizando a TI?

Figura 11 - Relao entre TI e BPR - Adaptada de Davenport (1990)

Possibilidades da TI Impacto na Organizao

A TI pode transformar processos no estruturados em transaes rotinizadas
Transacional
A TI pode transferir informaes rapidamente atravs de longas distncias, tornando
Geogrfica
Automao
Analtica
Informativa
Seqencial
Conhecimento
Rastreabilidade
Desintermediao

processos independentes da geografia

A TI pode substituir mo-de-obra
A TI possibilita a utilizao de complexas ferramentas analticas
A TI pode disponibilizar grande quantidade de informaes a respeito de um processo
A TI pode permitir mudanas na seqncia de tarefas e permitir execuo simultnea de
tarefas
A TI pode capturar e disseminar conhecimento a respeito de um processo
A TI permite o acompanhamento do status, entrada e sadas de tarefas
A TI permite a eliminao de intermedirios

Quadro 3 - Possibilidades da TI para a BPR - Adaptado de Davenport (1990)

4.6 Os Sistemas ERP e o Redesenho de Processos

Pelo fato de os sistemas ERP serem integrados, eles impem uma viso de processos
quelas empresas que os implementam, obrigando-as a compreender e transpor suas barreiras
departamentais. A implementao desses sistemas trata-se, portanto, de uma grande oportunidade para que as empresas revejam seus procedimentos e busquem as vantagens da viso de
processos apresentadas por Davenport e Short (1990).

59

Alm disso, pelo fato de os sistemas ERP serem construdos a partir de modelos de processos, as chamadas melhores prticas, eles permitem que as empresas faam uma reviso de
processos a partir do que teoricamente so bons modelos, isto , testados e em funcionamento
em diversas outras empresas. A reviso de processos no feita ento a partir de um papel
em branco, mas j se partindo de certas premissas e modelos que podem, pelo menos a princpio, conter boas idias e possibilidades. Os sistemas ERP disponibilizam a maioria das diferentes possibilidades da TI apontadas, conforme mostrado no quadro 4.

Possibilidades da TI
Transacional
Geogrfica
Automao
Analtica
Informativa
Seqencial
Conhecimento
Rastreabilidade
Desintermediao

Sistemas ERP
Padronizam e rotinizam as operaes da empresa
Podem ser utilizado para uniformizar os SI de uma empresa global, ou de uma empresa com grande abrangncia geogrfica
Automatizam diversas atividades da cadeia de valores
ainda deficiente, mas os sistemas ERP servem como base para uma slida construo de sistemas DSS e ESS
Disponibiliza instantaneamente a informao para os departamentos que dela precisam
A integrao obriga as tarefas a serem executadas na ordem correta, e o banco de
dados centralizado permite que algumas tarefas sejam executadas simultaneamente
por diversos departamentos
Ainda no disponibiliza essa possibilidade
A integrao e o modelo de dados corporativo permitem total rastreabilidade das
operaes
Ainda no disponibiliza essa possibilidade

Quadro 4 - As Possibilidades dos Sistemas ERP - Elaborado pelo autor

4.7 Relao entre Benefcios e Problemas e Caractersticas dos Sistemas ERP

Souza e Zwicker (1999) apresentam um modelo que relaciona possveis benefcios e
potenciais problemas s caractersticas dos sistemas ERP. As caractersticas que, em conjunto,
distinguem os sistemas ERP de outros pacotes e alternativas de desenvolvimento so o fato de
sistemas ERP serem desenvolvidos por terceiros, a integrao, a utilizao de um modelo de
dados corporativo e a grande abrangncia funcional. Os autores dividem ainda os benefcios e
problemas em tcnicos e organizacionais. Nos quadros 5 a 8 esto resumidos os benefcios e
problemas apresentados, relacionados s quatro caractersticas de sistemas ERP consideradas.

60

PACOTE
COMERCIAL

Benefcios
procurados

Aspectos Organizacionais

Problemas
potenciais

Foco na atividade principal da empresa

Possibilitar a reengenharia dos processos,
utilizando as melhores prticas, conhecimento
e experincia de outras empresas acumulados
nos sistemas
Reduo dos custos de informtica
Focar a rea de TI na busca de solues empresariais, e no no desenvolvimento de sistemas

Dependncia do fornecedor

Problemas de adequao do pacote empresa

Necessidade de alterar processos empresariais

Necessidade de utilizao de consultoria para

implementao

Resistncia a mudanas

Tempo para aprendizado de interfaces no

desenvolvidas especificamente para a empresa

Possvel incompatibilidade entre a estratgia

da empresa e a lgica do ERP

Aspectos Tecnolgicos

Atualizao de tecnologia

Contar com ganho de escala na pesquisa de

novas tecnologias

Compatibilidade com o ano 2000

Ganho de escala no tempo para desenvolvimento do sistema

Reduo do backlog de aplicaes

Criao de uma infra-estrutura de comunicao

sobre a qual possvel construir os sistemas
que a empresa precisa para poder se diferenciar

Falta de controle sobre a evoluo tecnolgica

do sistema

O conhecimento a respeito do funcionamento

do pacote no est na empresa

Curva de aprendizado para o novo modelo de

desenvolvimento e necessidade de retreinamento da equipe de TI

Dificuldade em manter o conhecimento a respeito do funcionamento do pacote aps o trmino da implementao

Nem toda a funcionalidade necessria j est

disponvel ou adequada, o que obriga integrao com outros sistemas

Quadro 5 - Benefcios e problemas relativos caracterstica Pacote Comercial

61

INTEGRAO

Benefcios
procurados

Problemas
potenciais

Aspectos Organizacionais

Aspectos Tecnolgicos

Reduo de mo-de-obra

Integrao dos processos permitindo maior

controle sobre a operao da empresa

Eliminao da fragmentao dos sistemas de

informao da empresa

Eliminao de interfaces entre sistemas isolados

Eliminao da necessidade de manuteno

em diversos sistemas isolados e diferentes

Consumao da viso de sistemas integrados

Maior preocupao sobre a disponibilidade

do sistema (se um mdulo no estiver operacional, pode inviabilizar a utilizao de outros
mdulos)

Maior dificuldade para fazer a atualizao de

verses e alteraes no sistema, devido necessidade de acordo entre todos os departamentos envolvidos

Entrada nica de informao no sistema

Maior velocidade nos processos

Aumentar a competitividade da empresa atravs da integrao das atividades

Atender integrao global (pacotes internacionais)

Disponibilizao em tempo real de informaes alimentadas no sistema

Dificuldades na implementao: mudana

cultural da viso departamental para a viso
de processos

Dificuldades na implementao: as decises

devem ser tomadas em conjunto por todos os
departamentos envolvidos

Entrada de dados incorretos pode ser imediatamente propagada pelo sistema

Necessidade de utilizao de consultoria para

implementao

Altos custos e prazo de implementao

Possvel incompatibilidade entre a estratgia

da empresa e a lgica do ERP

Quadro 6 - Benefcios e problemas associados caracterstica Integrao

ABRANGNCIA
FUNCIONAL

Benefcios
procurados

Aspectos Organizacionais

Padronizao de processos e procedimentos

Reduo de custos de treinamento

Aspectos Tecnolgicos

Problemas
potenciais

Dependncia de um nico fornecedor em

um sistema crtico para a misso da empresa

Um nico sistema para toda a empresa

Interface de acesso unificada para toda a
empresa
nico fornecedor para contato
Reduo dos custos de operao
Maior preocupao sobre a disponibilidade
do sistema , pois a empresa inteira depende
de um nico sistema

Quadro 7 - Benefcios e problemas associados caracterstica Abrangncia Funcional

62

BANCO DE
DADOS
CORPORATIVO

Benefcios
procurados

Aspectos Organizacionais

Problemas
potenciais

Aspectos Tecnolgicos

Padronizao de informaes
Eliminao de discrepncias entre mesma
informao produzida por departamentos
diferentes
Melhoria na qualidade da informao
disponvel
Entrada nica da informao no sistema
Disponibilizao de informaes gerenciais para anlise da empresa como um todo

Dificuldades na implementao: necessidade de mudana cultural da viso de

dono da informao, para a viso de
responsvel pela informao
Dificuldades na implementao: as decises devem ser tomadas em conjunto
Informaes digitadas incorretamente so
propagadas instantaneamente pelo sistema

Possibilidade de extrair informaes utilizando ferramentas desktop

Consumao da viso do modelo de dados
corporativo
Eliminao de redundncias no banco de
dados
Eliminao de duplicidade de esforos na
entrada de dados

Maior dificuldade para fazer upgrades e

alteraes no sistema devido necessidade
de haver acordo entre todos os departamentos envolvidos

Quadro 8 - Benefcios e problemas associados caracterstica Mod. de Dados Corporativo

63

CAPTULO 5
METODOLOGIA DA PESQUISA

5.1 Objetivo da Pesquisa

O objetivo principal deste trabalho descrever e analisar como ocorrem os processos
de deciso, seleo e implementao e utilizao de sistemas ERP, verificando, nas empresas
pesquisadas, quais benefcios e dificuldades ocorreram, como e porque ocorreram, buscando
contribuir para o delineamento de um modelo terico que relacione estes benefcios e dificuldades s caractersticas dos sistemas ERP e ao contexto onde esses sistemas esto inseridos.
A fim de se atingir o objetivo principal, foram delineados os seguintes objetivos especficos:

Identificar um referencial terico inicial para guiar a realizao do estudo emprico

Realizar um estudo emprico com o objetivo de verificar e descrever como ocorreram os
processos de deciso, seleo e implementao do sistema ERP nas empresas pesquisadas,
quais so e como esto sendo obtidos os benefcios, quais so e porque ocorrem dificuldades com a utilizao de sistemas ERP nessas empresas

Identificar, a partir das informaes levantadas na pesquisa bibliogrfica e emprica, os

benefcios e problemas apresentados pela utilizao de sistemas ERP, suas possveis causas e relaes com suas caractersticas, com os processos de seleo e implementao e
com o contexto das empresas
O primeiro objetivo especfico foi atendido por meio do levantamento bibliogrfico e

das consideraes apresentadas nos captulos 3 (ciclo de vida de sistemas ERP) e 4 (benefcios e dificuldades de sistemas ERP).
Os prximos itens deste captulo apresentam a descrio do estudo emprico realizado
para atender ao segundo e terceiro objetivos especficos, e incluem a definio do tipo de pesquisa, o detalhamento da metodologia empregada e a descrio dos procedimentos utilizados
para anlise dos resultados.
5.2 Tipo e Metodologia de Pesquisa
A pesquisa emprica realizada neste trabalho de natureza qualitativa e foi conduzida
pelo mtodo de estudos de casos mltiplos.

64

Segundo Strauss e Corbin (1990), pesquisas qualitativas so qualquer tipo de pesquisa

que chega s suas concluses por meios distintos de procedimentos estatsticos ou outros
meios de quantificao, podendo este tipo de pesquisa ser utilizado para descobrir e entender o que est por trs de fenmenos sobre os quais pouco ainda se conhece ou para se obter
novos pontos de vista sobre coisas das quais j se conhece bastante.
Segundo Godoy (1995), a pesquisa qualitativa no procura enumerar e/ou medir os
eventos estudados [...] Parte de focos ou questes de interesse amplo que vo se definindo
medida que o estudo se desenvolve. Segundo a autora, muitos dos aspectos envolvidos s
sero percebidos no transcorrer da execuo da pesquisa emprica, ao contrrio de uma pesquisa quantitativa onde o pesquisador conduz seu trabalho a partir de um plano estabelecido
a priori, com hipteses claramente especificadas e variveis operacionalmente definidas.
Segundo a autora ainda, Quando o estudo de carter descritivo e o que se procura o entendimento do fenmeno como um todo, na sua complexidade, possvel que uma anlise
qualitativa seja a mais indicada.
Segundo Selltiz et al. (1965), os estudos realizados para adquirir familiaridade com
um fenmeno ou obter novos discernimentos sobre ele, muitas vezes para a formulao de um
problema mais preciso de pesquisa ou para desenvolver hipteses so geralmente chamados
de estudos formulativos ou exploratrios, onde a nfase na descoberta de idias e discernimentos.
A natureza exploratria e qualitativa da pesquisa emprica proposta justificvel, uma
vez que, objetivando a ampliao dos conhecimentos a respeito de sistemas ERP, pretende-se
observar a sua implementao e utilizao dentro do contexto empresarial, buscando identificar novos aspectos envolvidos e novas relaes entre estes e aspectos levantados na literatura,
procurando-se delinear modelos tericos que descrevam o fenmeno. Esse enfoque pode ser
considerado vlido uma vez que o fenmeno que se pretende estudar (a utilizao de sistemas
ERP) um campo de estudos acadmicos relativamente novo, existindo ainda poucos trabalhos a ele relacionados. Embora a implementao desses sistemas tenha se iniciado em grandes empresas no comeo dos anos 90, e, como citado no primeiro captulo, j esteja entrando
em fase de maturidade no que se refere sua prtica nessas grandes empresas, somente a partir de meados desta dcada os primeiros resultados comearam a ser apresentados e discutidos
na imprensa especializada, principalmente na americana. Quanto a trabalhos acadmicos a
respeito de sistemas ERP, os mesmos s comearam a surgir mais recentemente, a partir do
final de 1.998. Na poca em que foi realizado o levantamento bibliogrfico para esta pesquisa,

65

entre janeiro e setembro de 1.999, no foram encontrados estudos cientficos que contivessem
pesquisa emprica nos peridicos disponveis no ProQuest (banco de dados que contm artigos de cerca de 1.000 publicaes em ingls, entre revistas especializadas e acadmicas). No
Brasil, foram localizados dois estudos acadmicos com pesquisa emprica, sendo eles Wood
Jr. e Caldas (1999) e Bergamaschi (1999). S mais recentemente (a partir do final de 1.999) o
assunto recebeu a ateno de peridicos importantes da rea de informtica e administrao
de sistemas de informao como a Communications da ACM (edio de abril de 2.000) e o
JMIS (edio que dever ser lanada no segundo semestre de 2.000).
Alm disso, a implementao e utilizao de sistemas ERP um fenmeno complexo,
de amplitude diferente dos tradicionais sistemas de informao normalmente implementados
at agora nas empresas, uma vez que suas caractersticas de integrao e abrangncia funcional trazem impactos em diversas reas da empresa simultaneamente.
Dessa maneira, possvel dizer que o estudo desse fenmeno ainda se encontra em seus
estgios iniciais, de construo de teoria, sendo justificado um estudo exploratrio com objetivo de oferecer propostas para um modelo terico. O que se pretendeu foi a obteno de uma
viso geral do fenmeno e suas principais caractersticas, oferecendo uma anlise do contexto
e obtendo assim indicaes de questes ou hipteses para futuras pesquisas mais aprofundadas.
5.3 O Mtodo de Estudo de Casos
Segundo Yin (1989), o mtodo de estudo de casos uma pesquisa emprica que investiga um fenmeno contemporneo dentro de um contexto real de vida, no qual as fronteiras
entre fenmeno e contexto no so claramente evidentes e no qual mltiplas fontes de evidncia so usadas.
O autor afirma que a deciso por uma pesquisa qualitativa do tipo exploratrio no define obrigatoriamente a preferncia pelo mtodo do estudo de casos, uma vez que esse mtodo
pode ser utilizado tambm com outros objetivos, tais como o descritivo e o explanatrio, no
havendo, segundo ele, uma hierarquia para os mtodos de pesquisa. Para o autor, essa escolha deve ser realizada com base em trs fatores: o tipo de questo que a pesquisa pretende
responder, a contemporaneidade do fenmeno que se pretende estudar e a possibilidade de
controle sobre esse fenmeno. O mtodo de estudos de caso o mais adequado quando se
procura responder questes do tipo como? e por que?, quando o fenmeno estudado contemporneo (isto , ainda est ocorrendo) e quando h pouca ou nenhuma possibilidade de

66

controlar os fatores envolvidos. Quando o foco em fenmenos ou eventos no contemporneos (isto , j ocorreram) a anlise histrica o mtodo mais adequado. Quando se procura
responder questes do tipo quem? , onde? , quantos?, o que?, os levantamentos (surveys) so
mais adequados. Quando o foco em questes do tipo por que? e como?, mas existe controle
sobre os fatores relevantes envolvidos, o mtodo experimental o mais adequado. Questes
do tipo o que? (ou quais?) tambm podem ser respondidas pelo mtodo do estudo de caso
quando a pesquisa do tipo exploratrio, isto , busca-se identificar aspectos presentes, e no
quantific-los ou descrever sua incidncia estatstica.
Para o autor, as perguntas do tipo como? e por que? levam ao uso de estudos de caso ou
experimentos porque tais questes lidam com ligaes operacionais que precisam ser rastreadas ao longo do tempo, ao invs de mera quantificao de freqncia ou incidncia.
O mtodo de estudo de casos adequado neste trabalho porque em sua pesquisa emprica busca-se descrever e analisar os benefcios e problemas de sistemas ERP, levando-se em
considerao o contexto empresarial em que ocorrem. Fazem parte desse contexto os motivos
pelos quais se tomou a deciso de se utilizar o sistema ERP, o particular sistema ERP escolhido, as caractersticas da empresa (tipo de indstria, porte, nmero de divises), as caractersticas do sistema anterior que foi substitudo, as caractersticas dos sistemas ERP, como foi realizado o processo de implementao, entre outros. Alm disso, este trabalho procura esclarecer o funcionamento dos processos relacionados aos sistemas ERP (deciso, seleo, implementao e utilizao), procurando responder a perguntas do tipo como? e por que? (como os
benefcios ocorrem? por que ocorrem?). As perguntas do tipo quais? propostas (quais os benefcios? quais os problemas?) so de carter exploratrio e, portanto, tambm so adequadas
a estudos de caso.
Sobre o uso de estudos de caso em pesquisas relacionadas especificamente rea de
sistemas de informao, Benbasat, Goldstein e Mead (1987) afirmam que o uso de estudos
de caso adequado para capturar o conhecimento dos profissionais da rea e construir teorias a partir deste. Segundo os autores, citando Christenson, o processo de tentativa-e-erro
no qual os profissionais da rea esto envolvidos fundamental para que o conhecimento
seja acumulado. tarefa dos acadmicos formalizar esse conhecimento antes de seguir para
uma fase de testes [da teoria]. Antes que ocorra essa formalizao, os estudos de caso podem
ser empregados para documentar as experincias da prtica. No caso de sistemas ERP,
notvel a experincia obtida na prtica dos processos de implementao pelos profissionais

67

envolvidos. O presente trabalho espera contribuir ainda com a sistematizao de parte desses
conhecimentos prticos obtidos nas empresas pesquisadas.
5.4 O Delineamento da Pesquisa
Segundo Yin (1989), qualquer tipo de pesquisa emprica deve ter um delineamento de
pesquisa (research design), que a seqncia lgica que conecta s questes propostas pela
pesquisa aos dados coletados e, finalmente, s concluses que sero traadas. um plano de
ao, que indica qual o caminho que ser seguido para se sair das questes propostas e chegar as repostas desejadas.
Para o autor, o delineamento de uma pesquisa baseada no mtodo de estudos de caso
deve apresentar 5 itens, considerados especialmente importantes:

Questes da pesquisa
Proposies
Definio da(s) unidade(s) de anlise
Descrio da lgica ligando os dados obtidos s proposies
Definio de critrios para interpretar as descobertas da pesquisa
Esses itens so apresentados a seguir.

5.4.1 Questo de Pesquisa

A fim de dirigir a realizao do estudo, foi colocada a seguinte questo principal da
pesquisa, elaborada com base no objetivo principal da pesquisa.

QUAIS benefcios e dificuldades os sistemas ERP trazem s empresas e COMO ocorrem

estes benefcios e dificuldades?

5.4.2 Proposies e Modelo da pesquisa

Segundo Yin (1989), a definio de proposies dirigem a ateno da pesquisa para determinados aspectos que devem ser examinados dentro do escopo do estudo. Proposies podem ser entendidas como afirmaes que estabelecem, de certa maneira, relaes tericas
entre os fatores que esto sendo estudados. Num exemplo citado pelo autor, ele apresenta a
seguinte questo de pesquisa: Como e por que as organizaes colaboram entre si para
prestar servios em conjunto?. Uma vez que a pergunta em si no indica o que deve ser estudado, uma proposio do tipo as organizaes colaboram para obter benefcios mtuos

68

pode indicar a direo para que o estudo seja iniciado. O autor salienta que mesmo no caso de
pesquisas exploratrias, onde o objetivo principal a busca de novas idias e hipteses para
explicao de fenmenos, importante que sejam conduzidas a partir de algum referencial
terico para que possam chegar a algum objetivo determinado, iniciando a explorao com
alguma lgica e direo, mesmo que mais tarde as propostas iniciais sejam comprovadas erradas. As proposies no podem ser consideradas como hipteses da pesquisa, pois no haver
comprovao estatstica.
Entretanto, alguma flexibilidade deve ser preservada na construo das proposies do
estudo. Segundo Selltiz et al. (1965), no caso das pesquisas exploratrias o plano de pesquisa deve ser suficientemente flexvel, para permitir a considerao de muitos outros aspectos
de um fenmeno.
Com a finalidade de estabelecer uma referncia terica para o estudo, ou, de acordo com
a definio de Yin (1989), elaborar as proposies da pesquisa, realizou-se um levantamento
bibliogrfico por meio do qual buscou-se identificar, na literatura e na imprensa especializada,
as principais questes e aspectos referentes aos sistemas ERP (problemas enfrentados, benefcios obtidos, dvidas, comentrios, afirmaes, etc.).
Durante o levantamento bibliogrfico, percebeu-se que as questes apresentadas dividiam-se em quatro grupos: questes relacionadas deciso pela utilizao de sistemas ERP,
relacionadas seleo do fornecedor, relacionadas ao processo de implementao e questes
relacionadas ao uso dos sistemas ERP nas empresas, incluindo-se nestas ltimas aquelas relacionadas aos benefcios obtidos (melhoria em processos, integrao das atividades, reduo de
mo-de-obra, retornos financeiros, etc.) e s dificuldades enfrentadas pelas empresas em seu
uso (adaptao ao sistema, dificuldades dos usurios, etc.).
No captulo 3, organizaram-se ento essas questes e foi possvel o delineamento de um
modelo para o ciclo de vida dos sistemas ERP, elaborado tambm a partir de reviso bibliogrfica sobre o desenvolvimento de sistemas e implementao de pacotes em geral. Nesse
modelo de ciclo de vida, so representados os processos de deciso, seleo, implementao e
utilizao de sistemas ERP.
Especificamente em relao aos benefcios e problemas relacionados aos sistemas ERP,
foco inicial e parte principal do estudo, foi possvel perceber durante o levantamento bibliogrfico, que estes poderiam ser classificados de acordo com a sua relao com as principais
caractersticas dos sistemas ERP (so pacotes comerciais, usam modelos de processos, so
integrados, usam bancos de dados corporativo e possuem abrangncia funcional). Essa classi-

69

ficao, que est apresentada no captulo 4, no pretende ser definitiva, no abrange todos os
benefcios e dificuldades possveis e no leva em considerao todos os possveis aspectos
envolvidos, mas tornou-se til para o presente trabalho uma vez que pde ser utilizada para a
elaborao das proposies de estudo.
As proposies do estudo, derivadas do modelo de ciclo de vida de sistemas ERP (captulo 3) e da classificao de benefcios e dificuldades dos sistemas ERP (captulo 4), so as
seguintes:

Os benefcios e problemas de sistemas ERP esto associados s seguintes caractersticas,

que em conjunto os distinguem dos sistemas desenvolvidos internamente s empresas e
dos pacotes tradicionais de software:
So desenvolvidos por terceiros
So desenvolvidos com base em modelos-padro de processos
Seus mdulos so integrados
Usam um banco de dados corporativo
Tm grande abrangncia funcional
Exigem procedimentos de ajuste

Os benefcios e dificuldades de sistemas ERP esto associados maneira como foram

conduzidos os processos de deciso, seleo do fornecedor e implementao
As proposies seguintes foram usadas como base para a seleo dos casos, na pesquisa

emprica.

Sistemas ERP de fornecedores distintos apresentam diferenas quanto ao grau em que as

caractersticas gerais dos sistemas ERP esto presentes, alm de diferenas relacionadas
nacionalidade e caractersticas especficas daquele pacote e a caractersticas do servio
prestado por aquele fornecedor
Sistemas ERP de fornecedores distintos apresentam diferenas na maneira como so conduzidos os processos de implementao
Alm dessas, so apresentadas as seguintes proposies adicionais, que tm a finalidade

de flexibilizar o plano de pesquisa e permitir descobertas adicionais, o que justificado pela

natureza exploratria da pesquisa

Os benefcios e dificuldades de sistemas ERP esto associados a aspectos do contexto

empresarial (organizao e tecnologia) onde esto inseridos

70

Os benefcios e dificuldades de sistemas ERP so percebidos de maneira diferente pelas

diversas reas, departamentos ou divises envolvidas

Entre os benefcios dos sistemas ERP esto ganhos em competitividade da empresa (por
reduo de custo ou diferenciao de produtos/servio)
Com base nessas proposies foi delineado o modelo de pesquisa, exibido na figura 12.

ERP
Processos de
Deciso,
Seleo,
Implementao
e Utilizao

Fatores
presentes no
contexto das
empresas

Empresa
Div. A

Benefcios

Div. B

Caractersticas dos ERPs

Desenvolvim. por
Terceiros
Modelos de Processo
Integrao
B.D. Corporativo
Abrangncia Funcional
Procedimentos de Ajuste
Caractersitas Particulares
do Pacote Escolhido

Div. C

Problemas

Figura 12 O Modelo da Pesquisa Elaborada pelo Autor

Nessa figura est representada a interao entre o sistema ERP e suas caractersticas e a
empresa e seu contexto. Entre os dois, esto os processos de deciso, seleo, implementao
e utilizao. Associados s caractersticas dessa interao, esto os benefcios, problemas e
dificuldades, trazidos pelo sistema ERP. A maneira de representar a empresa indica que os
benefcios e/ou problemas podem ser percebidos de maneira diferente pelos seus departamentos ou divises.

71

5.4.3 Unidade de Anlise e Tipo de Estudo de Casos: Casos Mltiplos

De acordo com Yin (1989), em uma pesquisa conduzida utilizando-se do mtodo de
estudos de casos, duas dimenses devem ser consideradas: o nmero de casos que compe o
estudo e o foco que ser dado unidade de anlise.
Quanto ao nmero de casos, os estudos de caso podem ser de caso nico (single-case)
ou casos mltiplos (multiple-case).
O autor apresenta trs casos tpicos para a realizao de um estudo de caso nico: quando o caso um caso que representa todos os aspectos de uma teoria bem formulada, quando
representa um caso extremo ou nico ou quando representa uma oportunidade nica de estudo
para um determinado pesquisador. Em outras circunstncias, segundo o autor, deve-se analisar com cuidado se ser utilizado apenas um caso ou mltiplos casos para a realizao da pesquisa. A escolha pela utilizao de casos mltiplos deve ser tomada com base na estratgia da
pesquisa e deve ter objetivos definidos. Para o autor, uma das vantagens do estudo de casos
mltiplos o fato de que as evidncias obtidas por meio de casos mltiplos so geralmente
consideradas mais convincentes e os estudos resultantes mais robustos.
Godoy (1995b) afirma que quando o estudo envolve dois ou mais sujeitos, duas ou
mais instituies, podemos falar de casos mltiplos. Aqui podemos encontrar pesquisadores
cujo nico objetivo descrever mais de um sujeito, organizao ou evento, e aqueles que
pretendem estabelecer comparaes.
Neste trabalho ser utilizado o estudo de casos mltiplos. O objetivo da utilizao de
casos mltiplos possibilitar a comparao entre benefcios e problemas em diferentes empresas que se utilizam de diferentes sistemas ERP, identificando as semelhanas e diferenas
entre os casos e analisando-as a partir das diferenas entre as empresas, procurando relacionar
os benefcios e dificuldades ao contexto de cada uma delas. Alm disso, as proposies da
pesquisa e a natureza do fenmeno apontam para a realizao de um estudo de casos mltiplos, uma vez que esta no preenche nenhum dos trs requisitos para estudo de casos nicos
apontados por Yin.
Quanto ao foco, os estudos de caso podem ser holsticos ou embutidos (embedded). Os
estudos de caso holsticos consideram a unidade de anlise como um todo, enquanto os estudos de caso embutidos procuram observar diferenas entre os diversos componentes de uma
mesma unidade de anlise, mas com a finalidade de obter maiores informaes a respeito do
todo. Segundo Lazzarini (1995), citando McClintoc et al., a unidade de anlise a entidade
central do problema de pesquisa. Embora seja normalmente definida como sendo indivduos,

72

grupos ou organizaes, ela pode tambm ser uma atividade, um processo, um aspecto ou
uma dimenso do comportamento organizacional e social.
Um exemplo de estudo de caso embutido, citado por Yin (1989), seria um estudo de
caso a respeito da implementao de um programa pblico que considerasse em sua anlise os
resultados de diferentes projetos dentro desse programa. Se, ao contrrio, o estudo de caso
examinasse apenas os resultados do programa como um todo, seria um estudo de caso holstico.
Neste trabalho, a unidade de anlise considerada ser o processo pelo qual o sistema
ERP escolhido, implementado e utilizado nas empresas estudadas. A partir dessa definio,
pode-se perceber que este estudo tem natureza embutida, uma vez que possvel que os benefcios e problemas dos sistemas ERP no sejam avaliados apenas para a empresa como um
todo, mas tambm relativamente a cada um dos departamentos envolvidos e sua utilizao se
apresente de maneira diferente em cada um destes departamentos.
Neste projeto, essa opo implicou na necessidade de realizao de entrevistas com pessoas de mais de um departamento em cada um dos casos. Yin (1989) apresenta como um dos
possveis riscos da anlise embutida de casos o fato de que o pesquisador pode falhar em expandir as concluses obtidas nas subunidades de anlise para a unidade de anlise principal.
Para evitar esse problema, no questionrio utilizado foi includa uma questo onde se solicitava que o entrevistado apresentasse os benefcios do sistema para a sua rea e para a empresa
como um todo.
5.4.3.1 Escolha dos Casos
Segundo Yin (1989) a escolha dos casos em um estudo de casos mltiplos deve seguir
uma lgica semelhante escolha de diversos experimentos em uma pesquisa experimental,
onde cada um deles procura comprovar ou negar determinado aspecto da teoria que est sendo
testada. Essa lgica diferente da empregada na definio de amostragens utilizadas em pesquisas quantitativas, pela qual se procura obter determinado grau de preciso para inferncias
estatsticas sobre a populao. Para o autor, em projetos de estudo de casos mltiplos cada
caso deve servir a um propsito especfico dentro do contexto da pesquisa, existindo duas
possveis lgicas para a escolha: a replicao literal (literal replication) a e a replicao terica (theoretical replication). A replicao literal feita buscando-se casos onde se prev que
resultados j verificados em casos semelhantes ocorram novamente. feita buscando-se reforar aspectos da teoria que est sendo construda. A replicao terica, por sua vez, feita

73

buscando-se casos onde se prev resultados contrrios aos j obtidos, mas por razes previsveis. A finalidade da replicao terica a de testar os limites da teoria que est sendo construda.
De acordo com o autor, a habilidade em conduzir entre 6 a 10 estudos de caso adequadamente arranjados dentro de um estudo de casos mltiplos anloga habilidade de
conduzir entre 6 e 10 experimentos a respeito de determinado tpico. Para o autor, alguns
casos (2 ou 3) poderiam ser usados para replicaes literais, enquanto que alguns outros (entre
4 e 6) poderiam ser desenvolvidos para diferentes padres de replicao terica. O autor comenta que se tudo ocorrer como previsto, esses 6 a 10 casos, observados em conjunto, vo
prover uma forte argumento em favor das proposies do estudo.
A escolha dos casos foi feita com base em dimenses que foram em primeira anlise
consideradas importantes para os resultados de cada um dos casos e da pesquisa como um
todo, ao mesmo tempo em que so de verificao imediata nos casos a serem estudados. Essas
dimenses so: o sistema ERP escolhido (SAP, Baan, Logix, etc.) e o fato de o fornecedor ser
nacional ou estrangeiro. Essas duas dimenses so consideradas importantes uma vez que os
diferentes pacotes possuem algumas diferenas em suas caractersticas, tanto de produto como
de servios e um dos fatos verificados no mercado nacional de sistemas ERP a necessidade
de localizao dos pacotes estrangeiros e a argumentao dos fornecedores nacionais quanto
aos possveis problemas apresentados por aqueles.
Em um primeiro momento, considerou-se a realizao da pesquisa em seis empresas,
duas utilizando o SAP R/3 (estrangeiro), duas utilizando o Logix (nacional), uma o Baan IV
(estrangeiro) e uma o Magnus (nacional). Considerou-se assim possvel a comparao entre
duas empresas que utilizam o mesmo sistema (duas utilizando o SAP e duas utilizando o Logix), a comparao desses resultados entre si e entre os resultados duas outras empresas, uma
utilizando um outro sistema nacional (Magnus) e uma um outro sistema estrangeiro (Baan).
Dessa maneira, procurou-se seguir uma lgica que permitisse tanto a replicao literal, nas
duas dimenses (duas empresas com o mesmo pacote, trs empresas com pacotes de mesma
nacionalidade), como a replicao terica, tambm nas duas dimenses (4 pacotes diferentes
verificados, 2 nacionais e 2 estrangeiros). Esses pacotes foram escolhidos uma vez que pertencem ao grupo das principais empresas fornecedoras de sistemas integrados, de acordo com
a pesquisa de participao de mercado realizada pela IDC Brasil em 1997. Segundo essa pesquisa, as principais empresas fornecedoras de sistemas integrados no Brasil eram a Datasul
(empresa brasileira, com sede em Joinville, Santa Catarina), a SSA (empresa americana), a

74

SAP (empresa alem, com sede em Waldorf), a Baan (empresa holandesa, com sede em
Amsterd) e a Logocenter (empresa brasileira, com sede em Joinville, Santa Catarina). Entre
esses fornecedores, foi dada preferncia queles que possuem produtos que reconhecidamente
pertenam categoria dos sistemas ERP e possuam uma grande abrangncia funcional.
Para a escolha das empresas usurias, definiu-se que as mesmas deveriam pertencer ao
setor industrial e que j tivessem implementado dois ou mais mdulos de pacotes integrados
em uma ou mais reas (manufatura, comercial, administrao) h pelo menos seis meses e h
menos de quatro anos. A restrio a empresas industriais oportuna, pois os sistemas ERP
foram originalmente concebidos para este tipo de organizao, tendo, portanto, maior maturidade neste setor. A limitao do espao de tempo decorrido desde a implantao (entre seis
meses e quatro anos) teve a finalidade de conciliar a necessidade de se levantar como ocorreram os processos de seleo e implantao com a necessidade de se verificar a utilizao do
pacote, o que s possvel aps o mesmo ter se estabilizado na empresa. A finalidade da limitao de pelo menos dois mdulos terem sido implantados garantir que o fator integrao
entre reas funcionais da empresa esteja presente e permitir observar diferenas entre a avaliao de benefcios e problemas em diferentes departamentos da empresa.
O contato com as empresas usurias do R/3 e do Logix foi feito por intermdio dos fornecedores dos pacotes, que cederam os telefones de contato em algumas empresas que preenchessem as condies iniciais. A partir da, foi feito o contato com as empresas, tendo sido
escolhidas aquelas que ofereceram plenas condies para a realizao de um estudo do tipo
estudo de caso, ou seja, disponibilidade de tempo do responsvel pela informtica e gerentes
usurios para entrevistas no-estruturadas e abertura de documentao relativa ao assunto
estudado. Pela facilidade de realizao da pesquisa foram escolhidas preferencialmente empresas usurias cujos escritrios centrais estivessem no estado de So Paulo. Foi enviada uma
carta especificando os objetivos da pesquisa, os resultados esperados e o comprometimento
necessrio da empresa pesquisada.
No caso do Baan IV e do Magnus, houve dificuldades em obter contatos em empresas
usurias a partir dos fornecedores dos pacotes. Dessa maneira, o acesso a duas empresas
(Santista Baan IV e Vine Txtil Magnus) foi obtido por meio de contatos pessoais do pesquisador. No caso da Vine Txtil, apesar de a empresa j ter implementado o sistema h mais
de quatro anos, todos os entrevistados haviam participado dos processos de deciso, seleo e
implementao, o que minimizou a dificuldade em obter a descrio destes processos .

75

Conseguiu-se realizar os casos em trs empresas usurias do SAP R/3. Como esse o
pacote mais utilizado nas grandes empresas, e como havia consideraes interessantes para os
resultados da pesquisa nos trs casos, resolveu-se incluir as trs empresas na pesquisa. Quanto
segunda empresa usuria do Baan IV, durante a realizao das entrevistas na primeira empresa, percebeu-se que o caso tinha um aspecto em que se diferenciava bastante das empresas
que implementaram o R/3, a grau de customizao do pacote. Resolveu-se, neste momento,
acrescentar mais uma empresa usuria do Baan IV para que pudesse ser verificado se essa
variao era decorrente do pacote ou da empresa usuria. O quadro 9 apresenta os casos selecionados.

Pacote
Estrangeiro

Pacote
Nacional

SAP R/3

Baan IV

- Rhodia
- Bosch
- Zeneca

- Santista Alimentos
- CNT/VMM

Logix

Magnus

- AgroLaranja
- Melhoramentos
Papis

- Vine Txtil

Quadro 9 Casos Selecionados para a Pesquisa

Embora muito interessante para a pesquisa, no se conseguiu selecionar casos que apresentassem diferentes caractersticas produtivas (montagem ou produo contnua), devido
dificuldade em se obter contatos em empresas que se enquadrassem nas caractersticas desejadas. exceo da Bosch, cujo processo em algumas de suas unidades se aproxima mais da
linha de montagem, e da Vine Txtil que apresenta grande quantidade de produtos finais, todas as demais empresas so caracterizadas por processos bastante contnuos, com pouca variedade de produtos e produo constante para o estoque.
5.4.3.2 Coleta de Dados
De acordo com Yin (1989), seis fontes de evidncia podem ser utilizadas para a coleta
de dados em um estudo de casos: documentao, registros de arquivos, entrevistas (abertas,
fechadas e levantamentos), observao direta, observao participante e artefatos fsicos.

76

Utilizaram-se neste trabalho entrevistas no-estruturadas, realizadas com os principais

participantes dos processos de seleo, implantao e utilizao de pacotes, e tambm a anlise de documentos e registros e a observao direta. Nas empresas escolhidas, foram entrevistados o diretor de informtica (ou Gerente, ou Supervisor ou responsvel pela rea) que tivessem participado do processo de implementao e gerentes de pelo menos duas reas usurias
(manufatura, comercial, financeiro, administrativo) em que havia mdulos do sistema j implantados dentro das especificaes j citadas. Quando necessrio, foram entrevistadas outras
pessoas (usurios, analistas de sistemas, consultores) para a complementao ou esclarecimento de informaes. Procurou-se, quando possvel, escolher um gerente da rea administrativa (finanas ou contabilidade) e um de reas operacionais (produo, suprimentos ou
vendas).
Para a realizao das entrevistas foi utilizado um questionrio com perguntas abertas.
As entrevistas foram gravadas e em seu trmino foi pedida ao entrevistado a possibilidade de
um novo contato para esclarecimentos ou questes adicionais que se fizeram necessrias. A
idia do questionrio aberto permitir a flexibilidade necessria natureza exploratria da
pesquisa, isto , possibilitar a gerao de novas idias, o que no possvel com um questionrio fechado. Devido natureza da pesquisa e do questionrio (questes abertas), as entrevistas foram conduzidas pelo prprio pesquisador.
5.4.3.3 O Roteiro para a Entrevista
Os roteiros para as entrevistas foram elaborados a partir das proposies iniciais, do
modelo de pesquisa e das informaes coletadas no levantamento bibliogrfico. O roteiro foi
dividido em quatro partes, cada uma representando uma etapa do ciclo de vida de sistemas
ERP: deciso e seleo, implementao e utilizao, alm de uma ltima parte onde se perguntou como a empresa est encarando o futuro dos sistemas ERP. As perguntas do roteiro
foram baseadas nas seguintes questes:

Por que as empresas pesquisadas decidiram utilizar sistemas ERP?

Como ocorreram os processos de seleo de fornecedor nas empresas pesquisadas?
Como ocorreram os processos de implementao nas empresas pesquisadas? Quais problemas ocorreram durante a implementao?
Quais benefcios foram ou esto sendo obtidos com a utilizao de um sistema ERP, nas
empresas pesquisadas? Como e por que foram obtidos?
Quais dificuldades ocorreram ou esto ocorrendo relativas utilizao de um sistema
ERP nas empresas pesquisadas? Como e por que ocorreram?

77

Quais mudanas o sistema ERP trouxe para o departamento do entrevistado? E para a

empresa?
possvel relacionar o sistema ERP a ganhos de competitividade nas empresas?
Quais os prximos passos da empresa, no que se refere informtica?
Nos Anexos 1 e 2 esto os questionrios que foram utilizados nas entrevistas dos responsveis pelo departamento de TI e gerentes usurios respectivamente. Foram realizadas 31
entrevistas, que geraram 39 horas gravao. Essas entrevistas foram transcritas e serviram
como base para a elaborao dos relatrios individuais dos casos.
5.4.3.4 O Caso Piloto
Em julho de 1999, foi realizada uma pesquisa piloto em uma empresa comercial distribuidora de peas automotivas que implementou um sistema ERP em sua totalidade em 1997.
O objetivo desse caso piloto era o teste do questionrio e determinao de algumas proposies bsicas para guiar o desenvolvimento da pesquisa emprica. Nessa visita pode-se observar que o mesmo questionrio no poderia ser aplicado igualmente para o gerente de TI e para
os gerentes usurios, sendo desenvolvidos dois tipos de questionrios. Foram eliminadas algumas questes que percebeu-se no terem sentido, acrescentadas outras e os resultados da
pesquisa auxiliaram no desenvolvimento do modelo de pesquisa.
5.4.4 Ligao entre os Dados e as Proposies: Anlise dos resultados
A anlise dos resultados ser realizada por meio de relatrios individuais, um para cada
caso e de um estudo comparativo dos resultados, onde os pontos principais levantados em
cada uma das empresas sero comparados s demais.
5.4.4.1 Apresentao e Anlise individual dos casos
Para Eisenhardt (1989), a anlise individual dos casos um dos passos importantes para
a construo de teoria a partir do estudo de casos mltiplos. De acordo com a autora, essa
anlise envolve tipicamente a elaborao de relatrios detalhados sobre cada um dos casos.
Embora geralmente sejam descries, so centrais para a gerao de idias. Segundo ela,
isso ocorre porque por meio da elaborao dos relatrios, o pesquisador se torna intimamente familiar com cada caso individual, e o processo permite que as caractersticas nicas
de cada caso surjam antes do investigador partir para a identificao de padres de generalizao entre os casos.

78

Para a apresentao dos casos, utilizou-se neste trabalho o modelo analtico-linear descrito por Yin (1989). Os relatos foram organizados de maneira a apresentar os diferentes tpicos de interesse relativos s proposies iniciais. Foi apresentado no incio de cada caso seus
pontos principais de interesse. Ao final de cada caso so apresentadas as principais concluses
obtidas frente s proposies iniciais do estudo, alm das novas idias geradas pelo caso em
particular.
Optou-se por uma descrio bastante completa dos casos para preservar o contexto e
para permitir que o leitor acompanhe o raciocnio empregado na elaborao das concluses do
caso, caracterstica que Yin (1989) chama de cadeia de evidncia (chain of evidence). A preservao do contexto tambm permite que o leitor dos casos, interessado em utilizar as concluses em outros casos, possa fazer, ele mesmo, a devida aplicao dos resultados tendo em
vista o seu caso em particular.
Durante a elaborao dos relatrios, as dvidas do pesquisador foram anotadas e foi
feito um novo contato com os informantes principais (os entrevistados da rea de TI) a fim de
esclarec-las. Aps a elaborao inicial os casos foram revistos por colegas do curso de mestrado que elaboraram comentrios apresentando dvidas ou indicando a ausncia de informaes relevantes. Os relatrios dos casos foram ento revistos pelo principal informante em
todas as empresas pesquisadas, sendo feitas modificaes com base nos comentrios feitos
por esses entrevistados. Aps a reviso final e aprovao por parte dos informantes, foi solicitado a cada empresa uma autorizao formal para a publicao do caso. As cartas de autorizao se encontram no anexo 3. Apenas uma empresa no autorizou a publicao do caso com
o seu nome real, tendo sido criado um nome fictcio para a mesma (AgroLaranja).
Os relatrios dos casos foram elaborados a partir dos seguintes pontos:

Contexto do caso (tipo de empresa, porte, descrio dos processos de deciso e seleo,
qual o pacote utilizado e outros fatores que sejam considerados relevantes)
Descrio do processo de implementao e seus principais problemas
Benefcios e problemas verificados no caso
Anlise dos resultados desse caso frente s proposies iniciais e ao referencial terico
elaborado no levantamento bibliogrfico, mostrando os resultados previamente esperados
e surpresas observadas no caso e novas idias geradas durante o estudo desse caso
Note-se que novas idias que surgiram durante a realizao de cada um dos casos foram

incorporadas para verificao nos casos seguintes e mesmo nos casos anteriores, quando necessrio. Segundo Yin (1989), cada caso individual considerado como um estudo comple-

79

to, onde buscada evidncia convergente para os fatos e a concluso desse caso; as concluses de cada caso so ento consideradas como informao necessitando de replicao [confirmao emprica] pelos outros casos individuais.
5.4.4.2 Anlise entre os casos
Segundo Bogdan e Biklen (1982), uma das maneiras pelas quais os pesquisadores podem analisar dados qualitativos a utilizao de um sistema de classificao. De acordo com
os autores, o desenvolvimento de um sistema de classificao (coding system) envolve a busca por regularidades e padres, bem como tpicos cobertos pelos dados, que devem ser ento
sintetizados por meio de palavras ou frases. Essas palavras ou frases tornam-se ento as categorias, ou classes, por meio das quais os dados podem ser organizados. Embora a viso proposta pelos autores seja a de derivar o sistema de classificao dos prprios dados coletados
com a finalidade de descrev-los e posteriormente desenvolver teorias a partir das classes descobertas (codificao ou categorizao), o mtodo tambm pode ser utilizado para organizar
os dados a partir de classes definidas a partir das proposies tericas. Segundo Yin (1989),
citando Miles e Huberman, entre as vrias tcnicas analticas que podem ser empregadas para
a anlise de estudos de caso esto a criao de matrizes de categorias e a distribuio das evidncias coletadas nessas matrizes.
Neste trabalho, para o desenvolvimento de um sistema de classificao que permitisse a
comparao os casos, a verificao de aspectos do modelo terico proposto bem como a gerao de novos discernimentos a partir dos dados coletados, combinou-se a utilizao das classes pr-determinadas no levantamento terico com classes que foram originadas a partir da
anlise dos casos. Foi construda uma tabela, que apresenta as evidncias coletadas nos diversos casos divididas nas diversas classes (e subclasses), o que permitiu a comparao entre os
casos e entre as dimenses utilizadas na replicao literal e terica. A tabela est includa no
anexo 4.
A anlise entre os casos foi realizada considerando os seguintes pontos:

Diferenas entre os contextos das diferentes empresas

Semelhanas entre os resultados obtidos nas diferentes empresas
Diferenas entre os resultados obtidos nas diferentes empresas
Novas idias geradas atravs da comparao dos casos
Anlise dos resultados frente s proposies iniciais e ao referencial terico elaborado no
levantamento bibliogrfico

80

Na elaborao das concluses, principalmente na modificao e aperfeioamento do referencial terico inicial, foram utilizadas teorias e referncias bibliogrficas que no haviam
sido inicialmente includas no levantamento, entre elas a teoria de Lewin (1952) para as mudanas na organizao. Como parte dos objetivos da pesquisa eram exploratrios e, alm de
se comprovar alguns aspectos do modelo inicial buscava-se ampli-lo com base nos achados
da pesquisa emprica, entendeu-se que esse recurso seria vlido. Segundo Eisenhardt (1989),
autora que defende a utilizao de estudos de caso para a construo de teoria, uma caracterstica essencial da construo de teoria a comparao dos conceitos, teorias ou hipteses
que emergem do estudo com a literatura existente. Isso envolve o questionamento a respeito
do que similar, do que contraditrio e por que contraditrio?
Para Selltiz et al. (1965), um estudo no est totalmente cristalizado quando se formula o problema de pesquisa. Durante a pesquisa, pode ser desenvolvida uma apresentao
mais adequada do prprio problema, podem surgir novas hipteses e aparecer relaes imprevistas. Por conseguinte, enquanto a formulao original apresente o aspecto bsico de
referncia para o relatrio, ainda pode haver espao para a incluso de subseqentes aperfeioamentos.
5.4.5 Critrios para Interpretar os Resultados e Limitaes da Pesquisa
Segundo Yin (1989), muitas vezes o mtodo de estudos de caso tem sido considerado
como fraco pelos pesquisadores sociais, que afirmam que os resultados obtidos por esse
mtodo no podem ser generalizados. Yin comenta que o mesmo problema tambm existe nos
mtodos experimentais, uma vez que tambm no possvel generalizar a partir de um nico
experimento. Segundo o autor, os fatos cientficos so normalmente baseados em vrios experimentos, que replicam o mesmo fenmeno sob diferentes condies. A mesma lgica pode
ser aplicada aos estudos de caso (a replicao analtica e a replicao terica), e os estudos de
caso, como os experimentos, so generalizveis para proposies tericas e no para populaes ou universos. De acordo com Yin, nesse aspecto, um caso no representa uma amostra,
e o objetivo do pesquisador o de expandir e generalizar teorias (generalizao analtica) e
no enumerar freqncias (generalizao estatstica).
Assim, os resultados do presente estudo no podem ser generalizados de maneira estatstica, mas, por aspectos de sua construo, podem ser generalizados de maneira analtica, ou
seja, o usurio dessa pesquisa a pessoa mais indicada para avaliar a validade externa, isto ,
se os casos apresentados, limitaes, tipos de empresas e sistemas se aplicam ao seu caso.

81

Outro problema apontado quanto ao uso de estudos de caso a questo do rigor empregado na pesquisa, e da influncia do pesquisador nos resultados (validade interna). As precaues tomadas j foram explicitadas, mas podemos sintetiza-las em:

uso de questionrio para orientar as entrevistas

o prprio pesquisador realizou as entrevistas, as transcries e a redao dos casos
o uso de mltiplas fontes de evidncia (triangulao), para confirmar ou complementar as
informaes obtidas nas entrevistas
confirmao das descries dos casos pelos entrevistados
A respeito das limitaes desta pesquisa, relativas ao mtodo empregado, pode-se citar

as seguintes, elaboradas com base nas consideraes de Bido (1999):

Apesar do cuidado do pesquisador em entrevistar pessoas de pelo menos duas reas diferentes, necessrio que se considere que os resultados so parciais e no representam toda
a complexidade envolvida no fenmeno estudado
Os casos descritos tm forte influncia do ponto de vista das pessoas entrevistadas nas
empresas (fonte principal de informao), sendo que no houve contato com os terceiros
envolvidos, como por exemplo, as consultorias e os fornecedores dos pacotes
A pesquisa realizada de natureza indutiva, a anlise depende muito do pesquisador, sendo impossvel identificar todas as variveis importantes
Por ser um estudo onde as empresas permitiram a divulgao do nome esperado que
algumas informaes que seriam relevantes para o estudo tenham sido censuradas.
Outra limitao de carter prtico decorrente do fato de que muitos dados e fatos rele-

vantes para a pesquisa no estavam disponveis atravs de documentos ou registrados de alguma forma, por isso o levantamento de dados dependeu muito da memria dos entrevistados
fazendo com que em alguns casos as informaes estejam incompletas ou imprecisas

82

CAPTULO 6
ESTUDOS DE CASOS

A seguir sero apresentados os relatrios dos oito casos estudados, na seguinte ordem:

RHODIA POLIAMIDA : R/3 (pg. 83)

COMPANHIA NQUEL TOCANTINS : Baan IV (pg. 107)
BOSCH : R/3 (pg. 124)
SANTISTA ALIMENTOS : Baan IV (pg. 141)
AGROLARANJA : Logix (pg. 164)
VINE TXTIL : Magnus (pg. 183)
ZENECA : R/3 (pg.196)
MELHORAMENTOS PAPIS : Logix (pg.210)

83

6.1 CASO RHODIA POLIAMIDA (EX-FAIRWAY)

Empresa: Rhodia Poliamida
Sistema ERP utilizado: SAP R/3, verso 3.0 fd
Entrevistas realizadas entre Julho e Agosto de 1.999.
Entrevistados: Coordenador de Desenvolvimento de Sistemas
Gerente de Produo Txtil Nylon
Gerente de Contab. Geral e Custos Industriais
Analista de negcios do mdulo SD

Pontos Principais do Caso

A Rhodia Poliamida foi uma das pioneiras na implementao do sistema R/3 como um
todo, utilizando o modelo big-bang, sendo a experincia obtida neste caso importante tanto
para a adaptao do sistema R/3 como da metodologia de implementao ao Brasil. Tambm
no caso da Rhodia destacou-se a utilizao do sistema ERP com a finalidade de unir dois sistemas e unificar a cultura da empresa, originada da fuso de duas outras empresas. Dos trs
casos estudados do sistema R/3, o da Rhodia foi o nico conduzido com total envolvimento
de uma empresa de consultoria.
Histrico da Empresa
Fundada em julho de 1.995, a Fairway Filamentos foi o resultado da unio da diviso
txtil da Rhodia Brasil, subsidiria na poca da empresa francesa Rhne-Poulenc, com a diviso txtil da Hoechst do Brasil, subsidiria na poca da empresa alem de mesmo nome, tendo
cada uma das empresas igual participao. Essa fuso foi realizada pelos grupos porque ambos procuravam foco em seus negcios principais (indstria qumica e farmacutica) e, segundo Jackson (1995), como resposta ao aumento na importao de produtos txteis no Brasil, decorrente da abertura do mercado. A Fairway recebeu as fbricas de fios de nylon da
Rhodia Brasil (uma em Santo Andr, no estado de So Paulo, e uma em Jacare, tambm no
estado de So Paulo), de fios polister da Rhodia Brasil (em Santo Andr) e a fbrica de fios
de polister da Hoechst do Brasil (em Osasco, tambm no estado de So Paulo). Aps a formao da joint-venture, foi construda uma nova fbrica de fios de polister em Alfenas-MG.
Em abril de 1.999, a Hoechst decidiu sair do mercado txtil e vender a sua participao
na Fairway. Atravs de acordo com a Rhodia, a Hoechst vendeu a outras empresas (UNIFI e

84

Leverdin) as fbricas de polister e a Rhodia recebeu novamente 100% de participao nas

fbricas de nylon. A Fairway voltou a ser uma empresa do grupo Rhodia, sendo chamada a
partir de ento Rhodia Poliamida. A Rhodia Poliamida reteve, portanto, as fbricas de Santo
Andr-SP e Jacare-SP, e tem administrao independente da Rhodia do Brasil, que compreende as divises qumica e farmacutica.
No momento da realizao das entrevistas, mais duas divises da Rhodia do Brasil estavam sendo incorporadas Rhodia Poliamida: a Diviso de Intermedirios Nylon e a Diviso
de Plsticos de Engenharia Nylon. Dessa maneira o grupo pretende concentrar todo os produtos de nylon na Rhodia Poliamida. Com a incorporao dessas unidades de negcios, a
Rhodia Poliamida receber mais uma planta em Paulnia e uma em So Bernardo do Campo,
ambas cidades do estado de So Paulo. O escritrio central da Rhodia Poliamida est localizado em So Paulo.
Atualmente a Rhodia Poliamida se reporta diviso de poliamidas da Rhodia mundial,
empresa que concentra as atividades relativas a industria qumica e txtil do grupo. A Rhodia
Brasil tambm se reporta Rhodia mundial. As atividades farmacuticas do grupo pertencem
atualmente empresa Aventis, resultado da fuso mundial das reas farmacuticas da RhnePoulenc e da Hoechst.
Para facilitar o relato do caso, a empresa ser sempre citada como Rhodia Poliamida,
mesmo que os fatos se refiram ao perodo em que a empresa chamava-se Fairway.
Mercado e Principais Produtos
A Rhodia Poliamida atende a dois mercados de fios de nylon: o industrial e o txtil. Os
produtos vendidos ao mercado industrial so fios mais grossos, destinados produo de
pneus, correias transportadoras, cordas de navios e tecidos emborrachados, entre outros. Os
fios da rea txtil so mais finos e utilizados na produo de tecidos para vesturio. Entre os
principais clientes da empresa esto a Firestone e a Pirelli, empresas fabricantes de pneus. Os
intermedirios de nylon so utilizados na cadeia de produo da prpria Rhodia Poliamida e
os plsticos de engenharia so produtos que atendem a mercados tais como o automobilstico,
eletrodomsticos e ferramentas. Antes da ciso da empresa, a Rhodia Poliamida tambm produzia fios de polister, utilizados principalmente no mercado txtil.
A empresa faturou US$ 400 milhes em 1.999 e contava com 4.000 funcionrios em
outubro de 1.999.

85

A rea de TI e Dados Tcnicos

A equipe de TI da empresa tem um total 28 pessoas, divididas entre 13 funcionrios e
15 terceirizados. Os funcionrios esto distribudos em 8 analistas de negcio, 1 programador
ABAP, 3 analistas de suporte e o gerente de informtica. Os 15 funcionrios terceirizados
esto assim distribudos: 7 na rea de basis (suporte parte tecnolgica do R/3, tal como banco de dados, configurao de servidores e rede), 4 na operao e suporte, 1 programador
ABAP, 1 analista de negcio do mdulo MM (suprimentos), um no mdulo FI (finanas e
contabilidade) e um no mdulo PM (controle de manuteno). Parte dos analistas de negcio
da equipe so profissionais que vieram das reas usurias, tais como os analistas responsveis
pelos mdulos PP (produo), CO (custos) e PM e o coordenador de sistemas entrevistado,
que veio da rea de produo e responsvel pelo mdulo PP. Segundo ele, o fato de a equipe
contar com pessoas das reas de negcio decorrente do fato de que a empresa saiu do zero
e de que a equipe de TI foi montada para o projeto de implementao do R/3 e depois se
perenizou. Segundo ele, a equipe de analistas de negcio no precisa conhecer detalhes de
tecnologia, no precisa saber como funciona um banco de dados, isto , no necessrio
que os analistas de negcio tenham conhecimento em tecnologia de informtica, mas sim profundos conhecimentos nos processos de negcio da empresa. J os analistas de negcio responsveis pelos mdulos MM e FI vieram da rea de informtica, bem como os demais funcionrios das reas tcnicas citadas. A equipe de 7 terceirizados na rea de tecnologia eram funcionrios da Rhodia Poliamida que criaram uma empresa, que hoje tambm presta servio
para outros clientes.
O dia-a-dia dos analistas funcionais a soluo de discrepncias e a adequao dos processos da empresa ao sistema, alm da soluo de problemas na operao encaminhados pelos
usurios. Segundo o coordenador, o processo de adaptao do sistema ERP empresa contnuo porque a empresa dinmica, sempre surgem novos negcios, modalidades novas de
vendas, compras, etc. Muitas vezes, segundo o entrevistado, a prpria equipe de analistas de
negcios prope alteraes no sistema, buscando melhorar maneira como os processos so
executados no sistema.
O sistema R/3 executado em Santo Andr, em um servidor de bancos de dados e um
servidor de aplicao, ambos da Sun, em sistema operacional Unix Solaris e banco de dados
Oracle. O sistema atende a cerca de 250 usurios na planta de Santo Andr, 70 usurios na
sede em So Paulo e 30 na planta de Jacare. A comunicao entre Santo Andr e a sede

86

feita via microondas, numa linha de 2 Mbps, e por meio de linha privativa de dados (LP) de
64 Kbps entre Santo Andr e Jacare.
A rea de TI subordinada diretoria administrativa e financeira da empresa.
Os mdulos implementados
Em Maro de 1.998 foram implementados os mdulos FI (finanas e contabilidade), CO
(custos), SD (vendas e distribuio), MM (suprimentos), PP (produo) e PM (controle de
manuteno), todos simultaneamente, em big-bang.
Histrico da Deciso e Seleo
Em julho de 1.995, em sua criao, a Rhodia Poliamida herdou vrios sistemas desenvolvidos internamente, tanto da Rhodia quanto da Hoechst. No caso da Rhodia, utilizava-se
uma srie de sistemas isolados desenvolvidos para departamentos especficos em diferentes
momentos, usando diferentes tecnologias (mainframe IBM, VAX, microcomputadores), que
eram integrado por meio de troca de arquivos em batch. Na Hoechst a situao era semelhante, e a empresa possua uma srie de sistemas desenvolvidos em mainframe IBM. No incio,
cada fbrica utilizava os sistemas da empresa da qual era originria (isto , as fbricas que
vieram da Hoechst utilizavam os sistemas da Hoechst e as fbricas que vieram da Rhodia utilizavam os sistemas da Rhodia). Os dados dos sistemas eram consolidados de maneira praticamente manual para que os processos financeiros e contbeis fossem centralizados. Alm
desse problema, havia sido definido um prazo internacional para o trmino da utilizao dos
sistemas proprietrios da Hoechst, que tambm optara mundialmente pela utilizao de pacotes e definira que aps dezembro de 1.997 todas as subsidirias deveriam deixar de utilizar o
sistema proprietrio em mainframe. O pacote escolhido internacionalmente pela Hoechst era o
R/3.
O projeto de implementao de um sistema ERP surgiu nesse momento como resultado
da necessidade de se substituir os diversos sistemas por um sistema nico e do reduzido prazo
para o desligamento de parte dos sistemas utilizados. Em decorrncia desse prazo, a opo
pelo desenvolvimento interno de um novo sistema foi descartada logo de incio, e a deciso
pela utilizao de um sistema ERP foi tomada quase que simultaneamente criao da nova
empresa. Alm da motivao principal, a consolidao dos sistemas, buscava-se tambm a
reduo dos custos de informtica, a atualizao tecnolgica dos sistemas de informao da
empresa e a reduo de custos operacionais por meio da entrada nica de dados, eliminando-

87

se os retrabalhos, objetivos estes formalizados durante as reunies de apresentao do projeto.

Grande parte dos custos de informtica era relativa s despesas de manuteno do ambiente
mainframe.
Durante o perodo em que a empresa utilizou-se dos sistemas vindos da Rhodia Brasil e
da Hoechst (entre julho de 1.995, no incio da empresa, e maro de 1.998, quando se iniciou a
utilizao do R/3), o suporte aos sistemas legados (sistemas anteriores) era fornecido pelas
reas de informtica da Rhodia Brasil e da Hoechst, pagando a Rhodia Poliamida por esse
servio s duas empresas. A equipe de informtica da Rhodia Poliamida, como citado anteriormente, foi criada para a implementao do sistema ERP, tendo sido definido o gerente de
informtica da empresa, originrio da Rhodia Brasil, que montou a equipe inicial com alguns
funcionrios da Rhodia Brasil. Posteriormente, durante o processo de seleo e implementao do sistema ERP, funcionrios das reas usurias foram chamados a participar da equipe.
O processo de seleo do fornecedor foi conduzido com o apoio e metodologia de uma
empresa de consultoria (Price Waterhouse), e contou com as etapas de levantamento de funcionalidades necessrias, apresentaes das alternativas aos usurios por meio de reunies e
avaliao por meio de questionrios preenchidos pelos usurios. No incio do processo, o R/3
ainda no estava localizado para o Brasil e no participou da seleo, o outro pacote foi inicialmente escolhido (o MM/X da Computer Associates). No final do processo, antes de o contrato ser fechado com o primeiro fornecedor, o R/3 foi disponibilizado para o Brasil, entrou na
disputa e foi adotado no lugar do primeiro pacote escolhido. Segundo o entrevistado da rea
de informtica, no houve imposio da Hoechst quanto ao pacote escolhido, embora o fato
de uma das scias utilizar o pacote na Alemanha e ter um bom relacionamento mundial com o
fornecedor tenha sido importante na deciso. A Rhodia Brasil optou tambm pelo R/3, mas
em processo independente realizado aps a escolha da Rhodia Poliamida, e hoje o R/3 j est
implementado tambm naquela empresa. Atualmente, segundo o coordenador de sistemas,
embora no haja uma determinao mundial para que as empresas utilizem o R/3, uma grande
parte das empresas utiliza ou est se direcionando para o uso desse sistema.
Quanto questo da compatibilidade entre o R/3 e a Rhodia Poliamida, a principal preocupao dos usurios era que esse sistema substituiria todo um conjunto de sistemas desenvolvidos sob medida ao longo do tempo e j bastante estabilizados, sabendo-se que muitas
das funcionalidades disponveis nestes sistemas no seriam suportadas pelo R/3. Durante a
implementao, algumas dessas funcionalidades foram adicionadas por meio de desenvolvimento de programas externos em ABAP/4 (a linguagem de programao em que escrito o

88

R/3). Esses programas externos so executados a partir de pontos determinados nos programas padro do R/3, chamados de user-exits, e so de exclusiva responsabilidade da empresa
usuria. Apesar do desenvolvimento desses programas externos, algumas funcionalidades
terminaram por ser perdidas. Uma diretriz do projeto era evitar qualquer alterao nos programas originais do R/3.
O gerente de produo entrevistado citou como preocupao a dvida se o R/3 seria capaz de atender particularidade de grande diversidade de produtos acabados da Rhodia Poliamida, pois as outras empresas usurias que foram visitadas na poca eram fabricantes de
bens de consumo (commodities), que tinham pouca variao de itens acabados. A necessidade
de controlar alguns produtos feitos sob encomenda para determinados clientes tambm era
uma preocupao. Tambm segundo esse gerente, a principal preocupao j durante a implementao era saber se o sistema iria conseguir expedir os produtos [emitir as notas fiscais e o documento de carga dos caminhes] atendendo a tudo que estava amarrado agora: estoque, roteiro de fabricao, fiscal, etc., que antes a gente no via, pois estava tudo
separado. Segundo ele, foi a primeira vez que todo mundo pensou em todas as etapas [do
processo] em conjunto.
Histrico da Implementao
A Rhodia Poliamida foi praticamente a pioneira do big-bang no Brasil, o que representou uma preocupao adicional pela falta de conhecimento disponvel a respeito do prprio
produto e do processo de implementao escolhido. O big-bang foi escolhido porque havia
um prazo muito curto para o trmino do sistema da Hoechst e, portanto, no haveria tempo de
fazer o processo por fases. Outra percepo do coordenador de TI entrevistado que os mdulos do R/3 so muito integrados, e seria muito difcil implement-los em separado.
A mesma empresa de consultoria que auxiliou o processo de deciso foi contratada para
dar suporte ao processo de implementao do R/3, que teve a durao de 20 meses. O processo iniciou-se em julho de 1.996 e teve as seguintes etapas:

Levantamento e anlise dos processos da empresa (at dezembro de 1.996)

Prototipao, parametrizaes, customizaes, e testes, por meio de reunies com usurios
(at outubro de 1.997)
Testes detalhados, treinamento (480 pessoas) e carga de dados
Incio da operao em big-bang em maro de 1.998
A equipe de projeto era composta por pessoas da informtica da Rhodia Poliamida e da

consultoria, chegando a contar com 50 pessoas nos momentos finais da implementao. Em

89

mdia a equipe era composta por 26 pessoas (12 funcionrios, 9 consultores e 5 terceirizados),
divididas entre analistas de negcios para os diversos mdulos, equipe de tecnologia (basis) e
programadores ABAP (terceirizados) que recebiam apoios eventuais de especialistas em determinados mdulos, quando necessrio. O projeto era dirigido em conjunto pelo diretor financeiro da Rhodia Poliamida e um diretor scio da consultoria. Havia um elemento da consultoria que tinha o papel especfico de gerenciar a integrao entre os mdulos e um elemento da Rhodia Poliamida, que era um gerente de custos e controles internos, que tinha o
mesmo papel. Essas duas pessoas tiveram um papel muito importante como gerentes do diaa-dia do projeto, fazendo o papel de integradores entre as diversas equipes. Havia um comit
executivo do projeto, composto por diretores e gerentes usurios, ao qual os gerentes de projeto se reportavam por meio de reunies peridicas.
Segundo o coordenador de TI, a configurao o R/3 foi considerada uma tarefa muito
complexa, em decorrncia do grande nmero de parmetros existentes no sistema que devem
ser considerados em conjunto (segundo a SAP, so 8.000 tabelas de parmetros na verso 3.0
f). So milhares de combinaes diferentes, e a determinao de alguns parmetros influencia
a maneira como outros podem ser configurados. O coordenador de TI comentou que como
se a configurao fosse um conjunto de polinmios, com cada um dos parmetros sendo um
coeficiente nas equaes. A complexidade do software est justamente em sua grande flexibilidade. O papel dos dois gerentes integradores no projeto era garantir que a determinao de
parmetros em algumas reas no afetasse as outras reas de maneira no prevista.
Segundo o coordenador de TI, a participao de usurios que conheam bastante os processos do negcio fundamental para o sucesso da implementao, assim como a realizao
de testes que sejam o mais completos possveis. Segundo ele, necessrio simular o mximo
possvel de processos da empresa no sistema. Segundo ele, a equipe de implementao tinha
grande participao de elementos da rea usuria, e, como citado, alguns deles tornaram-se
membros da equipe de TI da empresa aps o projeto. O gerente de controladoria entrevistado
tambm concorda que houve grande participao dos usurios no projeto e que sem a participao a implementao seria muito difcil.
Os usurios que participaram do projeto, denominados de usurios-chave, foram escolhidos pelos gerentes dos departamentos e em alguns casos por indicao da equipe de projeto, que procurava escolher pessoas que considerava mais adequadas. Segundo o coordenador, a equipe de projeto no conseguiu a liberao dos usurios-chave para que participassem
em tempo integral do projeto. Segundo ele, isso seria muito importante para que os usurios

90

realmente se comprometessem com o projeto e assumissem a propriedade do sistema. Quando

o usurio envolvido em tempo parcial, ele entende que est apenas ajudando o projeto, e
muitas vezes associa a responsabilidade pelo funcionamento do sistema equipe de projeto. A
dificuldade de obter a participao em tempo integral surge do fato de que o ideal para o projeto que se escolham aqueles funcionrios mais importantes de cada departamento, que melhor conhecem os processos, e que so, portanto, indispensveis. Justamente por esse fato, foi
difcil afast-los de suas funes.
No incio da operao, as 4 fbricas e o escritrio central (vendas) entraram em operao simultaneamente. A equipe foi dividida e prestou suporte local a cada uma delas. Em
maro de 1.998 eram 480 usurios no total.
O prazo inicialmente previsto para o projeto era de 18 meses, e foi completado em 20
meses. O oramento inicial era de US$ 9 milhes, incluindo as licenas do R/3, a consultoria
e a atualizao de hardware, e foi atingido.
A Unio de Duas Empresas
Um aspecto presente no caso da Rhodia Filamentos foi o fato de que a empresa era o resultado da unio de duas empresas diferentes, que possuam algumas diferenas em suas culturas.
Na criao da empresa, houve uma separao dos cargos executivos e administrativos,
sendo parte deles foi atribuda a funcionrios da Rhodia, e parte deles atribuda a funcionrios
da Hoechst. Nas fbricas, permaneceram os funcionrios das empresas de origem. Dessa maneira, havia em cada um dos mdulos uma influncia maior da cultura da Rhodia ou da cultura da Hoechst, dependendo do caso.
Segundo o coordenador, essas diferenas se refletiam na maneira como as empresas
eram estruturadas, na maneira como produziam seus relatrios de controle e na maneira como
organizavam as tarefas. Pelo fato de a Rhodia ter passado por um programa promovido pelo
presidente da empresa que procurou implementar a flexibilizao e uma maior participao
dos subordinados nos processos de deciso, havia nos funcionrios dessa empresa um certo
grau de informalidade, que permitia aos subordinados o acesso informaes e um certo grau
de autonomia em relao a seus chefes. J na Hoechst, que ainda vinha buscando essa iniciativa, a formalidade no relacionamento era um pouco mais acentuada e a comunicao entre os
diversos nveis hierrquicos um pouco mais restrita.

91

Segundo o coordenador, na prtica da implementao essa diferena percebia-se pelo

fato de que nos mdulos implementados por funcionrios da Rhodia havia uma maior discusso entre chefes e subordinados a respeito de como deveria ser configurado o sistema. Nos
mdulos onde a participao da Hoechst era maior, na maioria dos casos a deciso sobre
como seriam implementados os processos tinha maior participao dos chefes. Entretanto,
segundo o coordenador, as decises no caso da Rhodia tomavam mais tempo, ao passo que
as decises da Hoechst eram mais rpidas.
Outro aspecto que precisou ser levado em considerao pela equipe de implementao,
que em sua maioria era constituda por funcionrios vindos da Rhodia, era o cuidado que deveria ser tomado nas definies necessrias do sistema, para que se evitasse a idias de que a
equipe estava impondo a maneira da Rhodia fazer, quando os usurios daquele mdulo
eram oriundos da Hoechst.
Como j citado, no momento da realizao das entrevistas, a equipe de informtica estava preparando a incorporao de duas unidades da Rhodia Brasil, que tambm j utilizam o
R/3. Segundo o coordenador de sistema, pelo fato de a Rhodia Poliamida ter parametrizado
seu sistema R/3 de maneira independente, mesclando a maneira de duas empresas diferentes
realizarem seus processos, o sistema ficou configurado de maneira bastante diferente do da
Rhodia Brasil, o que est dificultando o processo.
Implementao : Problemas
Nos momentos iniciais da operao do novo sistema, percebeu-se que o tempo necessrio para que os usurios executassem os processos foi maior do que o necessrio no sistema
anterior, ao qual j estavam acostumados. Havia dificuldades em operar o sistema novo, tais
como dvidas freqentes que exigiam suporte e dificuldades em localizar as operaes nos
menus e as informaes nas telas. Durante os primeiros 15 dias a lentido nos processos chegou a causar queda no faturamento da empresa, que foi recuperada ao longo do ms. Segundo
o coordenador de TI, o treinamento deve ser considerado um aspecto crtico da implementao porque no suficiente treinar rapidamente as pessoas na operao do novo sistema,
preciso ter certeza de que elas estejam bastante seguras de como o sistema ir funcionar e que
conheam profundamente como realizaro suas tarefas. A preparao de um material de apoio
claro e simples, adequado s pessoas que iro utiliz-lo (linguagem e complexidade adequadas), que possa auxiliar os usurios respondendo as principais dvidas tambm foi considerado importante. Segundo o coordenador, tnhamos uma preocupao muito grande com o

92

treinamento, e, no momento do incio da operao, ele se mostrou realmente bastante crtico.

Quanto aos problemas no treinamento citados, aos poucos percebeu-se que estes no
eram problemas tcnicos, tais como a utilizao do sistema operacional Windows (que muitos
usurios desconheciam antes do incio do projeto) ou mesmo em dificuldades com as telas do
sistema, mas problemas relacionados dificuldade das pessoas entenderem as implicaes
relacionadas a trabalhar em um sistema integrado. Segundo o gerente de contabilidade e custos, a mudana de uma viso da empresa dividida em departamentos para a viso de uma empresa que utiliza um sistema integrado foi a maior dificuldade da implementao. Segundo
ele, as empresas no Brasil esto acostumadas a trabalhar de maneira departamentalizada e os
funcionrios de um departamento desconhecem o funcionamento de outras reas. Para utilizar
um sistema integrado, as pessoas tm que conhecer o funcionamento da empresa como um
todo e entender o efeito de cada uma de suas atividades no resultado global. Segundo o
gerente de produo, o pessoal s acordou para a integrao depois que iniciou-se a operao, poderia ter havido uma preparao maior nesse sentido, sobre como trabalhar em
grupo.
O fato de a implementao ter sido feita em big-bang em quatro fbricas e no escritrio
central simultaneamente, gerou uma dificuldade pelas distncias envolvidas. Embora a equipe
houvesse sido dividida, muitos casos exigiam o deslocamento dos consultores entre as fbricas. Segundo o coordenador, durante as primeiras quatro semanas a equipe precisou estar disponvel 24 horas por dia, 7 dias por semana, o que gerou um cansao muito grande.
O coordenador de TI citou o fato de que no incio da operao a digitao de valores incorretos e a no observao de determinados procedimentos para digitao das transaes
causou erros em mdulos tais como custos e controle de estoques. A dificuldade de acompanhar um grande nmero de usurios no incio da operao, para eliminar dvidas e corrigir
erros de digitao foi tambm apontada como uma dificuldade no incio da operao pelo
gerente de contabilidade e custos.
A necessidade de as pessoas passarem a entrar informaes e executarem tarefas necessrias apenas para outros mdulos e departamentos, tais como custos e contabilidade, foi motivo para algumas resistncias mudana encontradas. Segundo o coordenador de TI, aos
poucos as pessoas foram se adaptando essa realidade, mas existiram alguns casos de pessoas
que precisaram ser mudadas de funo. Segundo o gerente de produo, na implementao do
mdulo PP no houve resistncia por parte dos usurios, mas sim uma grande ansiedade

93

em saber se as mesmas informaes disponveis no sistema anterior estariam disponveis no

R/3.
Segundo o gerente de contabilidade e custos, a localizao do sistema foi bastante problemtica, pois a Rhodia Poliamida foi uma das primeiras empresas a implementar o R/3 no
Brasil. Boa parte da localizao do R/3 para o Brasil foi feita durante essa implementao,
segundo os entrevistados. Um exemplo citado que o sistema original do R/3 no tinha a impresso de notas fiscais, a emisso de livros fiscais e o controle de estoque por preo mdio,
que uma exigncia da legislao brasileira. Segundo o coordenador de TI, a Rhodia Poliamida sofreu um bocado por ser pioneira. Ns fomos um laboratrio para o fornecedor e
para a empresa de consultoria. Atualmente os principais problemas de localizao esto
resolvidos, com a exceo da folha de pagamento e do ativo fixo, que so pacotes de outras
empresas. Entretanto, alguns pontos de localizao no foram totalmente atendidos, sendo
feitos em programas desenvolvidos em ABAP, ou mesmo usando um processo no timo,
dentro do R/3. Segundo o coordenador de TI, em alguns casos, para solucionar os problemas
de atendimento legislao foi necessrio estabelecer procedimentos manuais de separao
de determinadas operaes de cadastro que devem ser efetuadas de maneira diferente no sistema para atender os requisitos da localizao. Essa opo no tima acaba por permitir que
se cometam erros na entrada de dados, que mais tarde iro se refletir em outros mdulos (especialmente a apurao fiscal e contabilidade).
O gerente de produo citou um problema que ocorreu em sua rea, durante a implementao, que foi uma excessiva preocupao com a integrao com o mdulo de custos, que
gerou a criao de um cadastro de rvore de produtos excessivamente detalhada. Mesmo insumos que poderiam ser considerados como despesas, tais como peas de manuteno, filtros,
ou ar comprimido, foram incorporados nas estruturas dos produtos por meio de porcentagens
estimadas. Isso gerou, no incio da utilizao, problemas para controle de estoque destes insumos, na apurao dos custos e tornou a operao do sistema mais lenta e no trouxe nenhum benefcio, pois estes itens tinham apenas um pequeno impacto no custo final. Houve
necessidade de rever os cadastros.
Outro problema importante, citado por esse gerente, foi a interface entre o R/3 e o sistema de controle de estoque de produtos acabados. Esse sistema, desenvolvido sob encomenda para Rhodia Poliamida, faz o controle do estoque de produtos acabados considerando as
variaes existentes de peso entre cada caixa de bobinas de fios. Segundo o gerente de produo, e muito difcil produzir as bobinas exatamente com o mesmo peso e, portanto, as caixas

94

de bobina devem ser controladas individualmente dentro do armazm para a montagem dos
pedidos dos clientes, uma necessidade no atendida pelo R/3. Para resolver esse problema, foi
desenvolvida uma interface para troca de dados entre esse sistema e o R/3. No incio da operao, problemas nessa interface geraram diferenas de estoque entre os dois sistemas, o que
chegou a causar problemas no faturamento. H um projeto em andamento para customizar o
R/3 para que esse possa controlar o estoque de bobinas da maneira exigida pela empresa.
Em relao aos mdulos do prprio R/3, houve um problema no incio da operao com
a utilizao de uma funo especfica, chamada material ledger. Essa funo, que faz parte do
mdulo FI e recebe dados do mdulo MM, possibilita a contabilizao e posterior apurao de
custos em dlares (ou outra moeda diferente da moeda corrente), um dos requisitos da empresa. Segundo o coordenador de sistemas, essa funo extremamente complexa e durante a
operao comearam a ocorrer diversos problemas relacionados a variedades de cenrios,
com diferentes combinaes de operaes, valores e quantidades que no haviam sido previstos ou verificados durante os testes. O coordenador relatou tambm a grande dificuldade
em corrigir os erros que essa funo apresentava j com o sistema rodando, porque alm da
complexidade do problema havia grande presso para resolv-lo uma vez que o sistema j
estava em operao.
Em relao a problemas tcnicos, o coordenador de TI apontou o fato de que o tempo
necessrio para a converso dos dados (transferncia dos dados dos sistemas anteriores para o
novo sistema, no momento do incio da operao) foi maior do que o que era esperado, e teve
que ser prolongado em alguns cadastros para depois do go-live, o que causou alguns pequenos
transtornos. Essa demora maior do que a esperada justificada pelo grande volume de dados e
porque muitos problemas de converso nos dados s puderam ser verificados no momento da
transferncia real, devido s dificuldades para se testar os programas de converso com a totalidade dos dados reais, pois a mquina de testes tem menor capacidade do que a mquina de
produo.
Segundo o coordenador de TI, uma das vantagens do big-bang o papel motivacional
deste tipo de implementao. Como muito difcil voltar ao sistema anterior aps o incio da
utilizao do novo sistema, h um maior incentivo para que as pessoas superem os difceis
momentos iniciais da operao, j que a alternativa a no prosseguir e no enfrentar as dificuldades seria a paralisao das atividades da empresa.

95

Mudar o Pacote ou a Empresa?

A diretiva da Rhodia Poliamida era no alterar os programas padro do R/3, isto , as
customizaes deveriam ser feitas utilizando-se de programas externos para evitar problemas
com atualizaes futuras do pacote. Segundo o coordenador de TI, no faz sentido gastar
milhes em um software e depois alter-lo de tal maneira que no pode ser mais atualizado.
Quando havia uma diferena entre os procedimentos da empresa e os do pacote, a alternativa inicial era sempre buscar a adaptao do sistema por meio de parametrizao antes de
se optar pelo desenvolvimento de programas. Segundo o coordenador de TI, a maioria dos
processos foi adaptada por meio de parametrizao. Se fosse necessrio resolver entre mudar
a empresa e desenvolver uma customizao, a rea envolvida, o gerente do projeto e a consultoria tomavam a deciso sobre o que seria feito. Caso no houvesse acordo, o comit de
direo decidia. As obrigaes legais eram diretamente encaminhadas para a customizao,
sem a necessidade de aprovao pelo comit. O entrevistado da rea de TI estima que o pacote tenha se adaptado entre 80% e 90% sem a necessidade de customizao. Segundo ele, a
maioria dos programas externos desenvolvidos foram relatrios.
O gerente de produo relatou que houve um momento da implementao a partir do
qual definiu-se que o que melhoria, isto , o que deve ser feito para aproximar o sistema
ao que a gente j tinha, seria feito em uma segunda etapa. A preocupao a partir daquele
momento seria preparar o sistema para iniciar a operao. Tanto que a turma do projeto [a
equipe de informtica] ainda deve ter uma carteira de melhorias solicitadas pelos usurios.
Entretanto, segundo o entrevistado, o desenvolvimento dessas melhorias aps o incio da operao terminou por ser postergado em decorrncia dos projetos que ocorreram logo em seguida da separao das empresas e da incorporao das duas novas unidades, que tem prioridade
maior. Por outro lado, segundo ele, isto foi at bom, porque a empresa teve de se adaptar
aos processos como esto. O gerente de produo afirmou que em sua rea no houve alteraes nos procedimentos da empresa, mas sim nos relatrios e na maneira como as informaes so apresentadas.
Utilizao: Benefcios
Os objetivos iniciais de consolidao dos dois sistemas anteriores e desligamento dos
mainframes foram atingidos. Parte do retorno do investimento era a economia relativa ao desligamento do mainframe, decorrente da eliminao das despesas de manuteno deste ambiente, e esta foi obtida.

96

Um benefcio no tangvel obtido, segundo o coordenador de TI, foi um maior entendimento por parte das pessoas de seu papel e responsabilidade dentro dos processos da empresa.
O entrevistado entende isso como um benefcio cultural adicional, salientando que este no
foi um resultado imediato, mas fruto de um intenso trabalho de treinamento, presso por resultados e empenho em solucionar problemas, caracterizando-se como uma mudana gradual
por meio de um processo de aprendizagem. O entrevistado exemplificou afirmando que o
pessoal da produo foi aprendendo, sentindo na pele, que se o gerente de produo quer
o custo correto, isso no problema da rea de custos, mas problema da rea de produo,
que deve fazer os apontamentos de maneira correta.
Outro benefcio foi a mudana de um sistema onde o controle de qualidade das informaes era feito por inspeo final para um sistema onde essa qualidade controlada durante o processo. Por serem os sistemas anteriores isolados, havia margem para que se cometessem erros de digitao ou que o registro das transaes da empresa no fosse realizado,
problemas que seriam corrigidos mais tarde pela contabilidade na preparao dos relatrios
mensais. A entrada incorreta de dados no prendia o processo do usurio, isto , no o impedia de continuar suas atividades, mas gerava um trabalho adicional para a contabilidade no
fechamento mensal, trabalho este considerado pelos usurios como de responsabilidade da
contabilidade. A partir da utilizao do sistema ERP, a entrada correta da informao no momento e no local onde a informao foi gerada passou a ser obrigatria. Em um recebimento
de mercadoria, por exemplo, se a nota fiscal no for corretamente digitada no sistema no momento em que recebida, o estoque de matrias primas no atualizado e pode impedir a
liberao de ordens de produo. Isso passou a obrigar aos usurios uma preocupao com a
exatido e com o momento correto para a entrada das informaes. Como conseqncia disso,
no final do ms a contabilidade no necessita digitar, corrigir e conciliar as informaes geradas pelos diversos departamentos, pois de maneira geral elas j esto inseridas no sistema e
esto corretas. O tempo despendido pela contabilidade nos primeiros dias do ms em corrigir
as informaes que foram entradas incorretamente no sistema ao longo do ms anterior foi
distribudo ao longo do prprio ms, realizado pelos usurios agora responsveis pelas informaes que so entradas no sistema, caracterizando a mudana da inspeo final para o
controle de processo. Com isso, o tempo necessrio para o fechamento da contabilidade e
de custos reduziu-se de 10 dia teis para 4 dias corridos. Segundo o coordenador de TI, muitos usurios mostraram um comportamento interessante relativo essa mudana. Quando um
usurio tentava inserir uma informao incorreta e o software no permitia, em um primeiro
momento os usurios tendiam a afirmar que o software s d problema, no funciona e no

97

me deixa trabalhar. Na verdade, aps um exame do problema, verificava-se que o sistema

no estava errado, mas que a integrao do sistema revelava erros que podiam permanecer
escondidos nos sistemas anteriores. Muitas vezes os usurios ligavam ao suporte para perguntar como realizar operaes da maneira que executavam nos sistemas anteriores, isto ,
burlando certas burocracias. Quando eram informados de que no seria possvel, uma
resposta comum era: mas eu sempre fiz assim. Segundo o coordenador de TI, uma vez que
o software obriga a digitao correta desde o incio, e comea a amarrar o usurio, ele acha
que o software est com problema, e as pessoas tem que se acostumar com isso [com a correta entrada de dados].
O gerente de contabilidade salientou que para o funcionamento do sistema integrado
como citado no pargrafo anterior, a correta entrada e manuteno dos cadastros fundamental. Por meio dos cadastros do sistema, que relacionam materiais, produtos e tipos de movimentao (recebimento, venda, consumo pela produo, transferncias entre estoques) s
correspondentes contas contbeis e centros de custo, garantida a exatido das informaes
no sistema. Em um exemplo, o entrevistado explicou que um usurio no pode comprar um
material para o ativo imobilizado e jogar para consumo, isto , lanar o material em uma
conta de despesa, pois no momento do cadastro da solicitao de compra o sistema obriga que
exista uma ordem de investimento para um ativo fixo (isto , uma aprovao de investimento
em ativos). Entretanto, se o cadastro daquele material estiver incorreto, perde-se a segurana
de que a informao est correta. A responsabilidade pelos cadastros dividida entre as diversas reas. Um material, por exemplo, tem informaes relativas rea de suprimentos, de
produo, de contas a pagar, de contabilidade. Cada uma destas reas responsvel pela sua
parte no cadastro.
O fato de o sistema disponibilizar a informao on-line permite que as operaes sejam
acompanhadas imediatamente por toda a empresa. Segundo o gerente de contabilidade e custos, em qualquer momento a empresa inteira est enxergando as operaes que foram feitas
naquele momento. O diretor de vendas quer ver se um pedido foi faturado ou no, ele no
precisa pegar no telefone, ele entra no sistema e v se j foi faturado ou no. Esse ponto
tambm apontado pelo gerente de produo como benefcio do sistema para a sua rea.
Quanto novas idias para realizao de processos, o entrevistado da rea de TI acha
que o novo sistema no trouxe grandes idias novas, principalmente porque a Rhodia Poliamida tinha sistemas que eram bastante evoludos no que se refere a funcionalidade, contando
com muita participao dos usurios. Muitas dessas funcionalidades, desenvolvidas nos sis-

98

temas em mainframe, foram transportadas para o sistema ERP. Uma das funcionalidades
que no era atendida pelo sistema anterior e que pretende-se aproveitar o mdulo de MRP e
planejamento da produo, ainda em fase de implementao no momento da realizao das
entrevistas. Segundo a analista de negcio, por ser um pacote extremamente genrico, que
pode ser utilizado por qualquer tipo de empresa, dependendo de sua configurao, muito
difcil extrair idias para novos procedimentos do R/3 (benchmarking, ou utilizao das best
practices). Mais comum o trabalho de adaptao do pacote empresa.
Integrao
Segundo o gerente de contabilidade, a integrao eliminou o papel dentro da rea, e
hoje o trabalho da contabilidade mais voltado anlise dos dados e informaes do que ao
operacional (digitao e verificao das informaes). O sistema tambm auxiliou na padronizao das informaes e procedimentos nas duas plantas. Hoje um material recebido l
em Jacare da mesma maneira que aqui em Santo Andr. Houve tambm reduo no nmero
de pessoas da rea financeira.
Um ponto interessante citado, relacionado integrao a velocidade de propagao
de erros. Se um usurio digitar um lanamento incorreto, este ser imediatamente disponibilizado para toda a empresa. Se um usurio lanar um recebimento de material de maneira incorreta, por exemplo, lanando mais material do que o efetivamente recebido, pode permitir
que ordens de produo sejam disparadas sem que haja o material necessrio para execut-las.
Para que se minimize esse problema, segundo o entrevistado da rea de TI, necessria uma
preocupao constante com o treinamento e o desenvolvimento de mecanismos no sistema
para que se evitem os erros de digitao. Embora o sistema j faa o controle no que se refere
a dados cadastrais, as digitaes de quantidades de recebimento ou consumo no tm como
ser verificadas automaticamente pelo sistema. O coordenador de TI citou um erro ocorrido no
incio do processo onde o usurio da produo lanou uma produo mil vezes maior do que a
real, o que zerou imediatamente todos os estoques de matrias primas. Segundo o entrevistado, caso o erro seja grande, ele rapidamente percebido, o problema so erros pequenos,
que sero percebidos apenas no fechamento do ms.
O gerente de contabilidade afirmou que por ser um sistema totalmente integrado, gerado um grande nmero de lanamentos na contabilidade. Quando necessrio extrair um
relatrio, estes ficam muito grandes e lentos para a extrao. Segundo ele, se alguns mdulos
no fossem totalmente on-line, enviando lanamentos resumidos por semana ou ms, por

99

exemplo, no haveria este problema. Entretanto, as informaes no ficariam mais disponveis imediatamente para toda a empresa. Este problema sentido principalmente nos lanamentos do mdulo de custos. Em compensao, a qualquer momento voc sabe quanto o
seu custo de produto.
Utilizao: Problemas
De maneira geral no foram citados grandes problemas de utilizao do sistema pelos
entrevistados.
Segundo o coordenador de TI, o suporte oferecido pela SAP bastante satisfatrio, mas
exigiu dos funcionrios de TI a habilidade de ler e manter uma conversao em ingls, pois o
suporte realizado por 3 centrais, uma nos Estados Unidos, uma na Alemanha e uma em Cingapura. Outro aspecto citado pelo entrevistado a criticidade que o sistema ERP passa a ter
para a empresa, pois se houver algum problema que exija uma parada no planejada (problemas de hardware, erros de programa, ou mesmo digitaes incorretas), a empresa toda obrigada a paralisar seus processos. Segundo ele, a gente mede quanto a empresa depende de um
software pela falta dele. Hoje se eu para o sistema um dia imprevisto, a empresa pra. Segundo o gerente de produo, um sistema integrado pode parar fisicamente a produo, o que
no acontecia nos sistemas anteriores.
O gerente de produo entende que a ausncia de relatrios gerenciais e de controle de
custos um dos principais problemas do R/3. As informaes so obtidas utilizando-se os
dados de relatrios do R/3 consolidados em planilhas eletrnicas. J o gerente de contabilidade entende que as necessidades de informaes gerenciais esto sendo atendidas. Segundo ele,
o R/3 como um banco de dados e, dessa maneira, as informaes esto no sistema, e os usurios definem como querem as informaes. Os relatrios so pedidos ao departamento da TI,
que os desenvolvem em ABAP. Segundo a analista de negcios, existe uma ferramenta de
gerao de relatrios no R/3 que permite a extrao de alguns relatrios. Os relatrios padro
do sistema foram avaliados pelos usurios na implementao e modificados de acordo com as
necessidades.
Alguns custos adicionais que esto sendo percebidos pela Rhodia Poliamida so os
custos com treinamento da equipe de informtica e de salrios, porque no momento da realizao da pesquisa o mercado estava carente de profissionais especializados em R/3. Outros
custos que esto sendo percebidos so os associados mudana de verses. Embora a mudana da verso 3.0fb para 3.0fd tenha levado em torno de quatro meses ocupando apenas parte

100

dos funcionrios em tempo parcial, a Rhodia Poliamida entende que a mudana para a verso
4.6 ser mais problemtica e custosa. Foi citado que a empresa de consultoria que implementou o sistema na empresa est vendendo projetos de upgrade, justamente em decorrncia destas dificuldades.
ERP e desempenho / competitividade
O coordenador de TI acha que a utilizao do sistema ERP no pode ser associada a um
aumento na competitividade, pois na Rhodia Poliamida ela est centrada em aspectos tcnicos
(atendimento a requisitos dos produtos) e de preo. O ERP tambm no proporcionou grandes
redues de mo-de-obra, pois a empresa j era muito enxuta, apenas uma melhor absoro de um turnover natural, isto , de pessoas que saem normalmente da empresa, sem que
haja necessidade de recontratao. Tambm houve reduo nas despesas de informtica, mas
na opinio do entrevistado, esta no chega a fazer diferena competitiva.
O gerente de produo tambm entende que no h como relacionar a competitividade
da empresa utilizao do sistema ERP, porque no havia problemas crticos nos sistema
anterior. Segundo ele, no houve reduo no tempo do ciclo de pedido (desde a entrada do
pedido at o atendimento ao cliente) em decorrncia da implementao do sistema. Ele acredita que aps a implementao do MRP, o grande anseio de seu departamento, podero ser
obtidos benefcios de melhoria de desempenho na rea de produo, que podero ser relacionados ao uso do sistema.
O gerente de contabilidade entende que o sistema trouxe agilidade e confiabilidade nas
informaes, o que pode ser relacionado a um melhor apoio tomada de decises, e portanto
melhoria de desempenho da empresa.
Integrao com outros sistemas
Para o processamento da folha de pagamento e o controle de ativo fixo so utilizados
outros pacotes comerciais. No caso do ativo fixo, a integrao com o R/3 ainda feita por
meio de digitao, embora a interface esteja sendo desenvolvida. Alm destes, h tambm o
sistema de expedio j citado, que possui uma interface com o R/3 baseada em trocas de arquivos. Os registros fiscais de sada tambm so processados em outro pacote. Segundo o
entrevistado da rea de TI, a integrao com outros sistemas no chega a representar um problema porque a Rhodia Poliamida utiliza muito poucos softwares alm do R/3.

101

O Processo de Melhoria Contnua

O entrevistado da rea de TI entende que um projeto de ERP no acaba logo aps o incio da operao do novo sistema, mas deve ser considerado como um processo de melhoria
contnua. Boa parte do conhecimento a respeito do software comea a surgir depois da utilizao, principalmente em decorrncia da complexidade do software, que exige tempo para a
aprendizagem. Muitas vezes voc est olhando os mdulos e descobre uma funo que voc
poderia usar. No comeo voc poderia at estar precisando desta funo, mas no sabia que
existia, no tinha condies de procur-la com cuidado. a mesma coisa quando voc est
com fome. Voc vai comer sem olhar muito a aparncia do prato. Depois que voc j satisfez
a sua fome, voc passa a se preocupar com a aparncia do prato. Com o R/3 a mesma coisa, num primeiro momento voc quer matar a fome, quer resolver o seu problema. Depois
voc comea a pensar um pouco melhor, a preparar um pouco melhor o prato.
Os analistas da rea funcional trabalham basicamente nessa adaptao contnua, pois a
empresa dinmica, sempre surgem coisas novas, como por exemplo uma modalidade nova
de compra, uma operao de vendas diferenciada, uma nova maneira de contabilizao.
Alm disso, aps a implementao a empresa passou por duas mudanas que tiveram grande
impacto no sistema: a ciso da empresa (a sada da Hoechst) e a incorporao de duas novas
unidades de negcio, vindas da Rhodia do Brasil. Segundo o coordenador de sistemas, muitos
dos processos que foram feitos da maneira mais difcil no momento da implementao tem
sido analisados pela equipe, buscando-se melhorias para a maneira de execut-los no sistema.
Segundo ele, essa equipe tem um papel pr-ativo na busca de oportunidades de implementao de funcionalidades do sistema.
Entretanto, o processo de melhoria contnua encontra algumas dificuldades. Segundo os
entrevistados, a implementao do MRP no pde ainda ser iniciada, porque os projetos de
ciso da empresa (a sada da Hoecsht) e a juno com as duas novas unidades de negcio da
Rhodia do Brasil absorveram os recursos da rea da informtica. Alm disso, o gerente de
produo entende que houve ainda um trabalho conjunto dos grandes atores do MRP (vendas, suprimentos e produo), isto , necessrio realizar um esforo conjunto entre as reas
diretamente envolvidas na implementao do MRP. Apesar disso, todas as trs reas ficam
na expectativa de que o MRP seja implementado.

102

Outros Comentrios dos Entrevistados

Sobre a consultoria: No comeo, qualquer consultor convencia. Hoje, com o conhecimento dos usurios, no qualquer consultor que pode convenc-los.
Sobre o trmino do projeto: Os problemas no acabam com a implementao. Sempre
h uma melhoria ou nova funcionalidade a ser implementada. um processo de kaizen, ou
melhoria contnua.
Consideraes sobre o Caso
Pontos de Destaque
O destaque do caso Rhodia Poliamida o fato de este ter sido uma das primeiras implementaes em big-bang do sistema R/3 no Brasil, abrangendo todos os seus principais mdulos (FI, CO, MM, PP e SD). A implementao serviu como experincia tanto para o fornecedor como para a empresa de consultoria para a adaptao do pacote e metodologia de implementao ao Pas. Entre as principais dificuldades enfrentadas pela empresa durante a
prototipao e nos momentos iniciais da operao estavam os problemas relativos localizao do sistema R/3, que, segundo os entrevistados, foi praticamente construda durante o projeto de implementao da Rhodia Poliamida. O sistema foi implementado em big-bang em 5
localidades, o que gerou grande necessidade de planejamento e preparao da equipe de projeto.
Outro destaque do caso foi a utilizao do sistema ERP para a unificao de duas culturas empresariais distintas, cada uma com seus requisitos de informao e estruturas de consolidao e apresentao de resultados. Isso tambm permitiu verificar como a cultura da empresa pode influenciar a configurao do sistema, uma vez que, no momento da realizao das
entrevistas, a Rhodia Poliamida estava incorporando duas divises da Rhodia do Brasil, onde
o sistema R/3 havia sido implementado em um projeto independente. Vrias diferenas verificadas entre a configurao dos dois sistemas (o da Rhodia Poliamida e o da Rhodia do Brasil)
dificultaram o projeto, obrigando a revises em processos em ambas as empresas.
Dos trs casos de utilizao de R/3 apresentados, a Rhodia Poliamida foi o nico onde a
consultoria foi utilizada para o planejamento e gerncia do projeto, alm da parte tcnica.
Principais Aspectos Presentes no Modelo Inicial
O caso da Rhodia permitiu observar, na etapa de utilizao, a questo da curva de
aprendizagem do sistema e o fato de que a obteno de benefcios e melhoria dos processos

103

vm apenas aps algum tempo de iniciada a operao, de acordo com o proposto por Orlikovski e Hofman (1997). Segundo o coordenador de sistemas, isso decorre principalmente em
razo da complexidade do software, o que aumenta a exigncia de tempo para a sua aprendizagem.
Essa complexidade refletiu-se tambm na dificuldade em realizar a parametrizao do
sistema tendo em vista a integrao de seus mdulos. A equipe de projeto na Rhodia Poliamida contava com duas pessoas, uma da empresa e uma da consultoria, que tinham a responsabilidade de verificar se a integrao estava sendo adequadamente considerada e garantir a
comunicao entre as pessoas que cuidavam de cada um dos mdulos.
A formao da equipe de TI tendo em parte usurios de algumas reas da empresa tambm foi um aspecto interessante, possibilitado pelo fato de esta equipe ter sido criada para a
nova empresa j com a misso de implementar um sistema ERP. Dessa maneira, a equipe de
TI segue em parte as recomendaes de Davenport (1999), mantendo uma combinao de
profissionais que, segundo o autor, facilita a continuidade do processo de melhoria contnua
do sistema ERP.
O caso tambm forneceu um certo suporte idia de que a implementao de um sistema ERP , em parte, um processo de reduo das discrepncias entre o pacote e a empresa, e
que esse processo sujeito a algumas restries. A primeira delas o prazo do projeto e, conseqentemente, seu custo. A segunda o fato de que o pacote comea a se descaracterizar ao
ser customizado alm de um determinado ponto. Isso pode trazer dificuldades para futuras
atualizaes de verso. A empresa opta, ento, por iniciar a operao do sistema, fazendo um
balano entre os riscos representados pelo incio da operao e o custo de continuar a adaptao do sistema, reduzindo ainda mais as discrepncias. No caso da Rhodia, determinou-se um
ponto de corte para as customizaes que estavam sendo solicitadas pela equipe de projeto,
a fim de garantir o cumprimento dos prazos estabelecidos. As mudanas que no trariam impactos imediatos ao funcionamento do sistema foram deixadas para depois do incio da operao, constituindo um novo backlog.
Entre as dificuldades presentes na literatura e verificadas no caso da Rhodia Poliamida
esto a preocupao com a disponibilidade do sistema (isto , garantir que o sistema esteja em
operao), uma vez que toda a empresa passa a depender dele, e a velocidade com que erros
de digitao ou operao so propagados para os demais mdulos do sistema.

104

Novos Aspectos que Podem ser Incorporados ao Modelo Inicial

Embora tenham se evidenciado as etapas propostas para o ciclo de vida de sistemas
ERP, o caso da Rhodia permitiu observar que logo aps o incio da operao do sistema a
empresa enfrentou problemas com a mudana cultural efetiva de seus usurios finais para o
trabalho em um sistema integrado, a incorporao das atividades impostas pelo sistema ERP
em suas rotinas dirias e problemas relativos a erros em programas e situaes no testadas,
na etapa de implementao. Como ser descrito a seguir, possvel associar essas dificuldades a uma etapa de estabilizao, que pode ser adicionada ao modelo do ciclo de vida dos
sistemas ERP.
Ficou evidenciado, no caso, que a integrao traz consigo exigncias maiores para os
usurios que esto executando tarefas que originam informaes e que sero utilizadas nos
processos seguintes da cadeia. A informao alimentada uma nica vez, em sua origem, e
enquanto isso no for realizado, no possvel dar continuidade s tarefas seguintes, nem de
forma parcial. Exige-se que a informao seja inserida corretamente no sistema no momento
apropriado, sujeita a todas as verificaes (consistncias) que podem ser feitas na ocasio.
Dessa forma, elimina-se a possibilidade de deixar que a verificao dos dados seja feita posteriormente por outro departamento (muitas vezes a contabilidade, ponto final da maioria das
informaes na empresa). Esse aspecto, denominado mudana do controle de qualidade de
informaes por inspeo final para controle de qualidade durante o processo por um dos
entrevistados, diretamente ligado integrao do sistema, pode ser relacionado melhoria da
qualidade da informao (os erros so verificados na hora) e reduo do tempo necessrio
para o fechamento da contabilidade.
Esse aspecto tambm pode ser relacionado, no caso, a alguns motivos para a resistncia
dos usurios finais, uma vez que aqueles usurios que trabalham em departamentos que so a
origem de informaes, tais como a produo e o recebimento de mercadorias, perceberam o
sistema como tendo aumentado sua carga de trabalho e responsabilidade. Alm disso, os usurios passam a ter responsabilidade direta sobre as atividades realizadas em outros departamentos, j que digitaes erradas ou atrasadas podem interferir nestas atividades. Outra
dificuldade associada a esse aspecto o fato de que as atividades realizadas em cada um dos
departamentos tornam-se expostas aos demais, deixando mostra eventuais problemas ou
ineficincias existentes.
O fato de que os usurios no estavam preparados para realidade da integrao do sistema, mesmo havendo dois gerentes de projeto especificamente voltados para este trabalho,

105

pode estar relacionado falta de um trabalho especfico de gerenciamento de mudana organizacional, que poderia trazer essa perspectiva integradora ao processo. Embora tenha havido
grande trabalho para a capacitao dos usurios finais nas funes do sistema, percebeu-se
que tambm importante que o usurio esteja preparado para assumir suas novas responsabilidades.
Outra dificuldade apresentada pelos usurios relativa localizao das informaes
nas telas do sistema ou nos novos relatrios da maneira como estavam acostumados.
Tambm verificou-se no caso a dificuldade em se realizar todos os testes possveis e garantir o perfeito funcionamento do sistema, assim que se inicia a sua operao. Essa dificuldade se evidenciou nos problemas relatados a respeito da funo material ledger, da interface
com o sistema de controle de estoque de produtos acabados e mesmo nos programas utilizados para fazer a converso dos dados dos sistemas antigos para o R/3. Essa dificuldade est
relacionada impossibilidade de se realizarem os testes com a totalidade de dados reais e
prpria complexidade e abrangncia do sistema.
Dessa maneira, possvel destacar e associar os fatos observados, definindo-se mais
uma etapa para o ciclo de vida dos sistemas ERP, pelo menos para os casos onde o incio da
operao feito por meio de big-bang. Essa etapa, que pode ser chamada de etapa de estabilizao, marcada pela necessidade de se corrigirem erros que no puderam se detectados na
modelagem e testes ao mesmo tempo em que as dificuldades relacionadas integrao tornam-se reais para os usurios finais. Pelo que pde-se observar no caso da Rhodia, uma etapa que exige grande esforo e determinao por parte da equipe de projeto, talvez mais do que
nas etapas anteriores. Assim, tambm, pode-se dizer que o trmino do processo de implementao no se d aps o incio da operao, ou go-live, mas sim ao trmino dessa etapa de
estabilizao.
Os benefcios colhidos pela Rhodia esto basicamente associados integrao do sistema ERP, como percebeu-se no caso da contabilidade, uma vez que os sistemas anteriores no
eram integrados. Como os sistemas anteriores, apesar de no serem integrados, eram considerados de boa qualidade pelos usurios, no foram citados grandes ganhos com relao funcionalidades novas ou mesmo melhorias em processos, chegando-se at mesmo a haver crticas por perdas de funcionalidades ou mudanas nos relatrios.
As diferenas de percepo entre o gerente de contabilidade e o gerente de produo a
respeito do envolvimento dos usurios no processo pode ser decorrente da participao e envolvimento dos usurios destas reas especficas. Segundo o coordenador de sistemas, em

106

algumas reas havia mais dificuldade em disponibilizar os usurios para que participassem do
projeto, por questes de necessidade operacional.
Contrastes com o Modelo Inicial
No caso pde-se perceber que o processo de evoluo contnua sofre restries decorrentes da escassez de recursos (pessoal para executar os projetos) e da necessidade de coordenar esforos entre vrias reas sem que haja uma responsabilidade definida para essa coordenao, o que termina por prolongar o tempo para a implementao de novas funcionalidades
ou correo de problemas que ficaram para ser resolvidos aps o incio das operaes. Alm
disso, fatores contingenciais (novos projetos, ciso da empresa, incorporao de outras unidades, etc.) tambm podem impedir o processo de adaptao contnua.
A vantagem de oferecer um nico sistema para toda a empresa no foi obtida pela Rhodia Poliamida, que ainda precisou interligar o sistema ERP a outros pacotes e sistemas. A facilidade de obteno de informaes gerenciais tambm no foi verificada no caso, sendo a
ausncia de relatrios gerenciais adequados uma das criticas unnimes entre os entrevistados.
A reduo de custos de treinamento da equipe de informtica tambm no foi verificada, uma vez que foi relatada a necessidade de retreinamento dos analistas de negcio nas novas verses do sistema ERP.

107

6.2 CASO COMPANHIA NQUEL TOCANTINS

Empresa: Votorantim Minerao e Metalurgia / Companhia Nquel Tocantins
Sistema ERP utilizado: Baan IV, verso C.3
Entrevistas realizadas entre Dezembro de 1.999 e Janeiro de 2.000
Entrevistados: Gerente Corporativo de Tecn. da Informao - VMM
Controller - CNT
Gerente de Materiais e Logstica - CNT
Planejador de Materiais CNT

Pontos Principais do Caso

Neste caso, foi possvel observar a implementao de um sistema ERP em um grupo de
empresas, bem como a realizao do projeto de maneira centralizada no escritrio da holding
do grupo. A deciso de manter a customizao em um nvel mnimo antes do incio da operao tambm destacou-se no caso.
Histrico da Empresa
A Companhia Nquel Tocantins (CNT) uma empresa mineradora de nquel, que faz
parte da Votorantim Minerao Metalurgia (VMM), holding que controla as empresas de minerao e metalurgia do grupo Votorantim. O grupo Votorantim o maior grupo privado brasileiro, faturando cerca de US$ 4,5 bilhes anuais, e contando com cerca de 20.000 funcionrios. Alm da minerao, possui operaes nas reas de cimento, papel e celulose, produo e
distribuio de energia eltrica, agropecuria, qumica e financeira. A estrutura da VMM est
representada na figura 13.
At a criao da VMM, em fevereiro de 1.997, as trs empresas eram administradas independentemente. A holding foi criada em decorrncia da necessidade de reduo de custos e
a fim de se aproveitar melhor as sinergias das empresas frente a uma situao de desafio econmico. As reas de controladoria, financeira e gesto de caixa foram centralizadas, de maneira que cada das empresas tem suas gerncias se reportando a diretorias da VMM. A CNT
fatura cerca de US$ 110 milhes por ano, e tem 1.000 funcionrios. A VMM como um todo
fatura cerca de US$ 400 milhes por ano, e tem 4.000 funcionrios.

108

V M M - V o tora n tim M in e ra o e M etalu rg ia

VMM
(H old in g )

CMM
C ia . M in eira d e M e tais
(Z in c o)
T r s M arias - M G
M orro A g u d o - M G
V az a n te - M G
S o P a u lo - S P
(c om erc ial)

CNT
C ia. N iq u e l Toc a n tin s
(N q u el e C o b a lto)

S id er rg ic a
B a rra m a n s a
(A o s p / c on s tru o )

S o P au lo - S P
N iq u el n d ia - TO

B arra M a n s a - R J

Figura 13 Votorantim Minerao e Metalurgia Elaborada pelo Autor

Mercado e Principais Produtos
A CNT fabrica dois produtos, o nquel e o cobalto. O produto principal o nquel, vendido em lingotes, por tonelada. Seus principais clientes so indstrias siderrgicas, que utilizam o nquel para a fabricao de aos. Cerca de 70 % da produo da CNT exportada. O
nquel uma commodity, que tem seu preo fixado em dlar, de acordo com a cotao da bolsa de Londres. A CNT produz 17.500 toneladas de nquel anualmente.
A CNT possui duas plantas: uma em Niquelndia, no estado de Tocantins, onde feita a
extrao do minrio, e uma em So Paulo, no bairro de S. Miguel Paulista, onde o minrio
purificado e obtido o nquel. O cobalto um subproduto da refinao do minrio de nquel.
Os principais clientes da CMM (zinco) so indstrias de peas e chaparias para a rea
automobilstica. Na Siderrgica Barra Mansa (aos), os principais clientes so grandes construtoras e distribuidoras de ao.
A rea de TI e Dados Tcnicos
Atualmente, a funo de TI do grupo centralizada na VMM, cujo escritrio fica no
centro de So Paulo, na Praa Ramos. So 10 pessoas, sendo 8 funcionrios e 2 terceirizados.
Destes, 4 pessoas pertencem a uma equipe denominada grupo de competncia Baan, responsvel por receber as solicitaes e problemas dos usurios, fazer a anlise das alternativas

109

para a soluo, e, quando preciso, encaminh-las a Baan ou empresa de consultoria. A proposta da VMM terceirizar todo o desenvolvimento de sistemas, ou seja, toda e qualquer programao e customizao do Baan, com o objetivo de manter a equipe de informtica com
foco no entendimento do negcio da empresa, e no na tecnologia. Nessa equipe, 2 funcionrios respondem pelos mdulos de distribuio (comercial) e manufatura, e 2 terceirizados respondem pelos mdulos financeiro e suprimentos.
Ainda na Praa Ramos, 2 funcionrios esto alocados no desenvolvimento do sistema
de datawarehouse e business intelligence (BI), 2 funcionrios do suporte ao banco de dados
e rede, alm do gerente de TI e de uma assistente. A manuteno dos micros e o suporte ao
MS-Office tambm so terceirizados.
Nas empresas do grupo, existem dois funcionrios de informtica em cada uma das
plantas principais (ou seja, aquela onde est localizado o escritrio central de cada uma das
trs empresas) e mais um em cada planta secundria, totalizando 9 pessoas, que tm como
funo realizar o suporte local, a realizao de backups e a soluo de problemas de telecomunicao. Essas pessoas esto funcionalmente subordinadas informtica corporativa, mas
administrativamente subordinadas s gerncias de controladoria de cada uma das empresas. A
rea de TI subordinada diretoria financeira da VMM.
Anteriormente criao da holding, havia um total de 39 pessoas nas informticas das
trs empresas, sendo 22 funcionrios e 17 terceirizados. Com a mudana, a maioria dos analistas de sistema saiu da empresa e ficaram apenas os funcionrios operacionais e um pequeno
grupo de especialistas em Baan, banco de dados e rede na VMM central. No caso da CNT, o
sistema anterior era desenvolvido internamente em COBOL em AS/400, e a equipe de informtica da CNT contava com 6 funcionrios. Atualmente na CNT so 3 funcionrios (2 em S.
Miguel Paulista e 1 em Niquelndia), com a funo de suporte local.
Na VMM existem 750 micros na rede, e um total de 1.000 usurios. Na CNT, especificamente, so 250 micros e 300 usurios. O Baan roda em 3 servidores da Sun, um localizado
em S. Miguel Paulista (CNT), um em Barra Mansa (Siderrgica Barra Mansa) e um em Trs
Marias (CMM), alm de um servidor para desenvolvimento, localizado na informtica corporativa, na Praa Ramos. O banco de dados utilizado o Informix, e o sistema operacional o
Sun Solaris. A comunicao de dados feita via satlite, em uma rede fornecida pela Embratel e Comsat.
Para que a reduzida equipe de informtica possa dar suporte ao grande nmero de usurios, existe nas plantas a figura dos usurios responsveis pelos mdulos (usurios estes que

110

participaram ativamente do processo de implementao, como ser apresentado mais adiante)

que tm a funo de filtrar e centralizar os problemas. De maneira geral, so esses usurios
que entram em contato com o grupo de competncia Baan, somente com aqueles problemas
ou dvidas que no puderam eles mesmos responderem.
Os mdulos implementados
Esto implementados os mdulos de manufatura, distribuio, finanas (inclui custos e
contabilidade), service (controle de manuteno) e controle de projetos, em todas as trs empresas.
A CMM e a Barra Mansa iniciaram a operao do sistema em big-bang em janeiro de
1.999. A CNT iniciou suas operaes, tambm em big-bang em junho de 1.999. Nas trs empresas, todos os mdulos foram implementados em todas as plantas simultaneamente (no caso
da CNT, so duas plantas).
As instalaes do Baan IV, em cada uma das empresas, so exatamente iguais nos mdulos de suprimentos e finanas. Nos mdulos de manufatura, comercial e custos, houve algumas particularidades da operao de cada uma das empresas que exigiram diferentes customizaes e parametrizaes em cada uma das instalaes. Segundo o gerente de TI, o gerenciamento das diferenas entre as trs instalaes feito pelo centro de competncia Baan, e
no representa problema.
Histrico da Deciso e Seleo
Com a unificao das administraes das trs empresas mineradoras do Grupo Votorantim na VMM, iniciou-se um processo de busca por reduo de custos operacionais e obteno de sinergias, isto , possibilidades de consolidao de atividades, entre as empresas e
plantas, nas reas financeira, suprimentos, administrao e informtica. Segundo o gerente de
TI, a empresa estabeleceu um modelo de gesto corporativa, e, para que esse modelo fosse
implementado, entendia-se como necessria uma ferramenta [sistema] que poderia alinhar e
padronizar os processos nas trs empresas.
A consolidao das informaes e unificao dos sistemas tambm foi considerada
como um dos objetivos do projeto de implementao de sistema ERP, pois cada uma das empresas tinha uma soluo de informtica diferente, cada uma com seus problemas tecnolgicos especficos (custo da equipe de desenvolvimento, desatualizao do pacote, etc.). A opo
de desenvolvimento interno foi descartada porque, segundo o gerente de informtica, no fa-

111

zia sentido reinventar a roda em aspectos como MRP, nem manter equipes para desenvolvimentos futuros, tais como o supply chain e o e-business. Apesar de cada empresa ter os seus
problemas especficos, estes no foram analisados individualmente durante o processo de deciso e seleo do fornecedor, pois a idia era a busca por um sistema corporativo que atendesse a holding como um todo. Na CNT, os sistemas informatizados eram desenvolvidos internamente, e eram departamentais e no integrados
A partir de outubro de 1.997, um grupo composto por gerentes usurios das trs empresas e pelo ento responsvel pela rea de informtica, comeou a visitar os fornecedores para
conhecer os pacotes existentes no mercado, e buscar aquele que mais se adaptasse (s) empresa(s).
Com a chegada do gerente de informtica corporativo empresa, em novembro de
1.997, houve uma mudana no foco da busca. Segundo ele, ns no tnhamos que escolher a
ferramenta, e sim saber o que queramos [no que se refere qual o modelo corporativo de
gesto desejado, isto , quais reas sero centralizadas e como ser a operao da empresa]
e a sim a ferramenta viria at ns. Esse modelo de gesto deveria contemplar a integrao
das trs empresas com um total de sete plantas, e exigiria, portanto, sistemas multiempresa e
multiplanta com capacidade de processamento e segurana para atender a uma grande quantidade de operaes e transaes.
Dentro dessa viso, a escolha recaiu entre o R/3 e o Baan IV, considerados os nicos na
poca (novembro de 1.997), que poderiam atender a esses requisitos organizacionais. Contra
os fornecedores nacionais pesou a questo do porte e tecnologia para suportar uma situao
multiempresa e multiplanta, o que foi no foi considerado suficiente nos pacotes nacionais.
Segundo o gerente de TI, os pacotes nacionais tambm no possuam uma ferramenta que
apoiasse a remodelagem de processos (O Baan tem o Organize e o SAP tem o ARIS Tools
SET). Outros pacotes estrangeiros no foram considerados viveis pelo pouco tempo de Brasil
e inexistncia de outras instalaes e localizao.
Um dos principais desafios era realizar o projeto com o menor investimento possvel,
para que houvesse um retorno mais rpido, em decorrncia das restries econmicas da empresa na poca.
Foi enviado um questionrio aos dois fornecedores finalistas a respeito da existncia de
determinadas possibilidades e funcionalidades dos mdulos comercial e manufatura (considerados mais crticos), para que se verificasse se estes poderiam se adaptar s necessidades especficas das empresas. A opo pelo envio de um questionrio foi decorrente da dificuldade,

112

na poca, de se visitarem outras empresas que tivessem um dos dois sistemas j em funcionamento, pois o R/3 ainda estava em implementao na maioria dos clientes, assim como o
Baan IV (o sistema anterior da Baan, o Triton j estava implementado em operao em algumas empresas, mas no o Baan IV, que bastante diferente do anterior). Segundo o gerente de
informtica, foi necessrio confiar nas empresas fornecedoras quanto s respostas ao questionrio, pois no havia como verificar em clientes.
No final de dezembro, decidiu-se pelo Baan, porque este demandava menor investimento, menor tempo de implementao e o custo da empresa de consultoria que seria utilizada era 40 % menor. Segundo o gerente de informtica, outro fator que favoreceu o Baan foi
sua menor exigncia sobre os usurios, por ser o produto menos complexo e mais facilmente
compreensvel, dificilmente necessrio procurar um manual. Isso facilitaria a implementao na empresa e sua absoro pelos usurios.
A opo por um sistema estrangeiro foi considerada pelos gerentes e usurios entrevistados como uma preocupao, devido possibilidade de dificuldades na localizao, no que
se refere legislao, bancos, e questes comerciais.
Mudar o Pacote ou a Empresa?
Uma das premissas do projeto, definida ainda na fase de seleo, era no customizar
mdulos que no agregassem valor empresa. Dessa maneira, a empresa deveria se adaptar
ao pacote nos mdulos financeiro e suprimentos. Mesmo em processos relativos aos clientes
(comercializao) e aos produtos (manufatura), considerados como fundamentais para o negcio da empresa, as customizaes no pacote s seriam feitas se bem justificadas. Segundo o
gerente de informtica, houve um esforo pela parte da equipe de projeto em evitar ao mximo as customizaes. Apenas 10% das solicitaes geradas pelo grupo que estava implementando o grupo chegaram a ser enviadas ao comit da diretoria para tomada de deciso e apreciao. Os outros 90% foram resolvidos com a adaptao da empresa.
No momento do incio das operaes, cerca de 3% do pacote, como um todo, havia sofrido customizaes. Essa estimativa confirmada pelos demais entrevistados na CNT, que
afirmam que na maioria dos casos a empresa adaptou-se. Um deles afirma que o nvel de
customizao teria que ser pequeno por definio, o que de certa forma no poderia ser diferente, at porque a customizao ficaria cara demais e a empresa realmente precisava de
uma reviso em seu modo de trabalhar. Outro gerente afirma que quando voc compra um
sistema, voc precisa se adaptar a ele, para ganhar benefcios em outras coisas. Se voc qui-

113

ser customizar todo o sistema, ele acaba se tornando pesado, caseiro. preciso quebrar paradigmas. No caso do mdulo de MRP especificamente, no houve problemas para a adaptao, pois no havia essa funcionalidade no sistema anterior.
Segundo o gerente de TI, a idia era customizar o mnimo possvel antes da implementao para depois, em uma segunda fase, verificar o que deveria ser customizado, pois a empresa certamente teria outra cara operacional [aps a implementao do sistema] e os usurios mais critrios para customizar em detrimento da melhoria dos negcios e no de detalhes operacionais. Isto , com maior conhecimento do pacote e dos processos, seria mais
fcil diferenciar quais seriam as modificaes realmente necessrias. Aps 12 meses de implementao, o gerente de TI estima que cerca de 10% do pacote sofreu customizaes.
Histrico da Implementao
A implementao foi conduzida atravs da metodologia do fornecedor (Target) pela
empresa de consultoria contratada, especializada em implementaes deste pacote. Foram
escolhidos funcionrios das trs empresas, denominados usurios-chave, que ficaram em
tempo integral em um laboratrio de prototipao no escritrio da VMM, recebendo treinamento em seus respectivos mdulos e participando da modelagem dos processos. Os usurioschave foram escolhidos entre aqueles usurios (funcionrios, supervisores ou gerentes) que
melhor conheciam os processos das empresas e que podiam responder pelas reas que representavam, tomando decises durante a modelagem. Os usurios-chave foram afastados das
rotinas operacionais, ficando exclusivamente dedicados ao projeto. Aqueles que vieram das
plantas mais distantes ficaram hospedados em um apart-hotel durante o projeto. O grupo de
implementao era composto de 32 usurios-chave, 6 funcionrios da TI e 8 consultores.
O processo de modelagem iniciou-se em maro de 1.998 e durou at novembro de
1.998. Durante esta etapa, a equipe realizou a modelagem dos processos da empresa no Baan
IV, simulando seu funcionamento e tomando decises quanto s adaptaes necessrias.
Quando havia dvidas, os usurios-chave voltavam s suas reas nas empresas para consultar
os demais usurios e verificar como a empresa se adaptaria aos novos processos. Mensalmente, havia uma reunio com um comit formado pelos diretores da empresa e por um consultor independente da FGV, que tinha por objetivo verificar o andamento e validar a modelagem dos processos, bem como tomar decises a respeito da realizao ou no de determinadas
customizaes solicitadas pelo grupo.

114

Alm da preocupao tcnica, houve tambm uma preocupao com o desenvolvimento

pessoal dos usurios-chave envolvidos. Durante este perodo, alm de treinamento especfico
no Baan, os usurios-chave receberam treinamentos de aperfeioamento pessoal, tais como
cursos de negociao e liderana, participaram de atividades de integrao (teatros, atividades
sociais), o que acabou por criar uma grande integrao e motivao entre eles. O planejador
de materiais entrevistado, que foi usurio-chave no projeto, salientou que a experincia de
simulao no laboratrio permitiu um grande aprendizado do funcionamento do sistema e da
integrao entre os mdulos, alm de uma troca de experincia com pessoas de outras reas e
da mesma rea nas outras empresas do grupo. Segundo o gerente de informtica, apesar da
grande evoluo profissional dos usurios-chave, a empresa no perdeu nenhum funcionrio
para o mercado aps a implementao.
Aps a modelagem e customizaes, em novembro de 1.998 iniciou-se o treinamento
dos funcionrios que operariam o sistema. O treinamento dos usurios foi auxiliado pelos
usurios-chave, que atuaram como multiplicadores de conhecimento. No final do processo,
foram treinados 1.000 usurios.
Com a finalidade de se fazer o incio da operao em big-bang, a equipe de projeto foi
dividida em duas, uma responsvel pela CMM e uma pela Siderrgica Barra Mansa. Decidiuse fazer a virada em big-bang em apenas duas empresas, deixando-se a CNT para uma segunda etapa para evitar excesso de custos, pois seria necessrio alocar mais consultores para uma
terceira equipe que seria responsvel pelo incio das operaes na terceira empresa. Ao mesmo tempo, a experincia adquirida pela equipe na implementao da CMM e Usina Barra
Mansa tornaria o processo na CNT mais simples. Em janeiro de 1.999, iniciou-se a operao
do sistema na CMM e na Usina Barra Mansa. A CNT estava prevista para iniciar-se quatro
meses depois, em abril de 1.999. Os usurios da CNT participaram ativamente do incio da
operao nas outras empresas, com a finalidade de aproveitar a experincia e o conhecimento
obtido em sua prpria empresa.
O oramento do projeto era de R$ 6 milhes, e o custo real ficou cerca de 15% menor,
tendo sido gastos R$ 5,2 milhes. O prazo planejado inicialmente, de 10 meses para a implementao das primeiras duas empresas, foi cumprido.
Implementao: Problemas e Dificuldades
Durante a modelagem do sistema, houve dificuldade em envolver as chefias e gerncias
das reas onde o sistema estava sendo implementado. Essa dificuldade era decorrente do di-

115

namismo do processo, pois a modelagem ocorria muito rapidamente e no havia como comunicar e consultar os gerentes diariamente e, tambm, porque o grupo de implementao estava
centralizado na holding, em So Paulo. Um reflexo deste problema, apontado pelos entrevistados, foi a falta de integrao da equipe de usurios-chave com os demais usurios da empresa. Segundo o gerente de controladoria, isto trouxe algumas dificuldades na adaptao dos
processos da empresa ao novo sistema, porque uma maior comunicao entre os usurioschave e os usurios poderia ter permitido um maior estudo ou anlise de possibilidades que
tornassem menor o impacto das mudanas.
Logo aps o go-live na CMM e Usina Barra Mansa, o principal problema foi a constatao da inadequao do Baan IV realidade brasileira, principalmente no que se refere aos
livros fiscais e transferncia eletrnica de ttulos de cobrana e pagamento para os bancos
(cobrana escritural). Os problemas com a emisso do livro fiscal s chegaram a ser resolvidos alguns meses aps o incio da operao. No caso da cobrana, os recebimentos precisaram
ser feitos manualmente, digitados um a um no sistema. Isso causou grandes transtornos e acabou por atrasar em dois meses o incio das operaes na CNT. Entre janeiro e junho de 1.999,
foram abertos 450 chamados no suporte da Baan.
Na CNT, esses problemas foram menores, pois a implementao foi adiada at que estes
tivessem sido resolvidos nas duas empresas, e tambm em decorrncia da experincia j obtida nas outras duas empresas. Os usurios-chave da CMM tambm participaram da implementao da CNT.
Entre os problemas relativos ao incio da operao na CNT, estavam a necessidade de
um maior treinamento dos usurios e a dificuldade em incorporar o novo sistema em suas
atividades. Um exemplo era a dificuldade em localizar as informaes necessrias no sistema
e nos novos relatrios. Segundo o gerente de controladoria, no incio da operao ficou claro
que o conhecimento do usurio ainda no era o bastante, mas, segundo o entrevistado, esses
problemas foram aos poucos sendo vencidos. Estes problemas foram considerados pelos entrevistados como problemas de absoro e adaptao ao novo sistema. O gerente de TI
entende que existe a necessidade de retreinamento, pois como o treinamento dos usurios finais foi executado mais prximo da data estabelecida para o incio das operaes e pelo fato
de terem sido treinados uma grande quantidade de usurios (1.000), houve necessidade de
realiz-lo de maneira menos profunda.
Para o gerente de TI, uma dificuldade adicional da CNT era o excessivo particionamento da operao, isto , os departamentos trabalhavam muito isoladamente, e isto tornou

116

mais difcil a ligao entre as atividades, necessria em um sistema integrado. Um exemplo

citado o do recebimento de mercadorias. Na situao anterior, o departamento financeiro era
responsvel pelo recebimento fiscal das mercadorias, enquanto que o departamento de suprimentos era responsvel pelo recebimento fsico. Para a utilizao do Baan, houve a necessidade da criao de uma clula de recebimento, onde os funcionrios, que respondem s
duas reas, passaram a ser responsveis pelas duas operaes. Houve tambm um problema
tcnico de comunicao com a planta de Niquelndia, pois a velocidade de comunicao de
dados pelo satlite disponvel no incio da operao no era suficiente para atender as necessidades do novo sistema.
Segundo o gerente de controladoria, no houve resistncia mudana para o novo sistema em sua rea, porque a empresa estava carente de sistemas. Embora alguns usurios
tenham comentado que o sistema anterior era melhor, os comentrios eram sobre aspectos
pontuais, isto , determinadas funes do sistema. J o gerente de materiais e logstica entende que houve resistncias, mas ressalta que importante ir quebrando os paradigmas
aos poucos. Um dos argumentos utilizados para isto o de que necessrio pensar no conjunto, e no no individual.
Utilizao: Benefcios
Entre os benefcios citados, espontaneamente, pelos entrevistados da CNT esto a segurana e confiabilidade das informaes, comparativamente ao(s) sistema(s) anterior(es).
Agora as pessoas confiam nas informaes, e h garantia de que todas as atividades esto registradas no sistema, so afirmaes comuns aos entrevistados. Anteriormente, a
mesma informao precisava ser redigitada nos diversos sistemas, causando dificuldades na
conciliao dos resultados destes sistemas. O gerente de controladoria comentou que hoje me
sinto como o maior beneficirio do sistema Baan, pois o sistema anterior, pela sua instabilidade e quantidade de erros, sequer me permitia fazer uma conciliao entre o movimento
econmico e o movimento financeiro da empresa.
A reduo do tempo para fechamento do balano foi citada (de 12 dias teis, com informaes imprecisas, para 5 dias teis, com informaes confiveis).
Segundo o gerente e o planejador de materiais entrevistados, o sistema permitiu uma reduo do nvel de estoques, de matrias-primas e almoxarifado de manuteno, em decorrncia do maior controle possibilitado tanto pelas caractersticas do novo sistema, como pela
existncia de um histrico de movimentaes e pelo trabalho de levantamento e correo das

117

informaes de informaes feito durante a implementao. Outro benefcio trazido pelo sistema para essa rea foi a maior facilidade para gerenciamento remoto da planta de Niquelndia, o que permitiu que o planejamento de materiais fosse centralizado em S. Miguel Paulista.
Segundo o planejador, possvel saber remotamente quais pedidos de compra foram entregues, quais foram entregues mas no foram inspecionados, de maneira a poder controlar o
dia-a-dia das operaes, sem a presena fsica de um supervisor.
Outro aspecto citado pelo planejador de materiais, foi a disponibilizao de um sistema
on-line para requisio de materiais de manuteno no almoxarifado. Antes, os funcionrios
da manuteno perdiam tempo indo ao almoxarifado para verificar se havia as peas necessrias. Com o sistema on-line, os funcionrios digitam uma requisio para o almoxarifado
sem a necessidade de sarem de seus respectivos departamentos, e, no momento da digitao,
j recebem a informao se h ou no a disponibilidade no estoque e, em caso negativo, se a
pea j foi comprada e qual a data prevista para recebimento. Segundo o planejador de materiais, Hoje h um ganho tambm na rea de manuteno. O funcionrio da manuteno verifica no sistema se as peas que ele necessita existem no estoque. Em caso negativo, ele aciona imediatamente o departamento de materiais, que toma a ao de reposio.
O gerente de informtica mencionou, ainda, a flexibilidade para alterao de processos
uma vez implementados no software, citando o exemplo de uma alterao que ser feita no
mdulo de custos da Usina Barra Mansa em apenas duas semanas. O mesmo gerente, citou
como benefcio a reduo dos custos de informtica, salientando, entretanto, que embora as
despesas de informtica tenham diminudo, aumentaro os investimentos, porque implementaes de extenses do ERP (tais como o CRM e o supply-chain) passam a ser importantes.
A consolidao dos dados do grupo VMM ainda no foi obtida, e ser inicialmente realizada por meio do datawarehouse que est sendo desenvolvido.
Integrao
Em relao integrao, foi citada a questo da necessidade da mudana cultural das
pessoas, tanto como dificuldade como benefcio do novo sistema, pois, medida que so
obrigadas a entender a empresa como um todo e compartilhar suas informaes com os demais, as pessoas evoluem profissionalmente, em decorrncia da ampliao de sua viso e conhecimento empresarial. Segundo o gerente de controladoria, fazer do usurio o responsvel
pelas informaes e pelo seu prprio negcio [isto , a sua rea], um grande crescimento
profissional.

118

Apesar de ainda existirem problemas, h um consenso de que questo de tempo para

as pessoas se adaptarem, uma vez que o sistema obriga as pessoas a cumprirem as burocracias necessrias ao controle. Um exemplo citado pelo gerente de controladoria o caso de
produtos comprados que chegam aos portes da empresa para serem entregues e o recebimento no permitido, porque no h pedido de compra digitado e autorizado no sistema.
Segundo o gerente de controladoria, o sistema benfico neste ponto, porque ajuda de maneira definitiva as pessoas a entenderem que existem certas obrigaes a se cumprirem para
que se realizem determinados gastos na companhia, e isto resulta em uma segurana nas
informaes cada vez maior.
Para aquele gerente, tambm, a reduo do tempo para fechamento da contabilidade
pode ser ainda maior, quando a mudana cultural se concretizar. Segundo ele, antes do Baan
IV, os usurios geravam um papel qualquer [para registrar as suas operaes], e jogavam
na controladoria, que tinha como responsabilidade conferi-la, garantir a sua exatido e digit-la no sistema. Com o sistema integrado, aos poucos os usurios iro percebendo que a
responsabilidade pela qualidade da informao do prprio usurio, e a controladoria ter
essa tarefa de verificao de dados diminuda e passar a fazer aquilo que se prope, isto ,
controlar, sinalizar os desvios e gerar as informaes gerenciais.
De maneira geral, todos os entrevistados entendem que algumas reas esto trabalhando mais, mas com ganhos no todo da empresa, que se refletem no maior controle sobre
as atividades e disponibilizao mais rpida de informaes mais seguras. Este trabalho adicional refere-se necessidade de digitaes e procedimentos que no esto diretamente ligados
atividade que est sendo realizada em si, mas tm como finalidade alimentar outros mdulos
(contabilidade, custos e planejamento). A rea de planejamento e de contabilidade e custos
so vistas como as maiores beneficiadas do sistema pelos entrevistados.
Utilizao: Problemas
O principal problema, citado espontaneamente por todos os entrevistados, a ausncia
de relatrios, sejam gerenciais ou operacionais, adequados ao dia-a-dia. Os dados esto disponveis no sistema, mas apresentados em formato diferente do antigo, ou dispersos em vrios
relatrios. Alguns departamentos obtm as informaes combinando os dados obtidos nos
relatrios do sistema em planilhas eletrnicas. A VMM est desenvolvendo, internamente, um
sistema de datawarehouse para resolver esse problema. Quanto aos relatrios operacionais,
estes esto sendo desenvolvidos aos poucos, medida que so requisitados pelos usurios. Os

119

entrevistados reconhecem que esta uma grande falha do sistema, mas entendem que os relatrios so uma segunda fase do processo, que est se iniciando aps alguns meses da implementao.
Um dos problemas relacionados pelos usurios orientao do projeto de customizar o
mnimo possvel e s novas necessidades de integrao do sistema, o fato de que em algumas reas houve um aumento de servio, decorrente das novas necessidades do sistema. Segundo os entrevistados, esse aumento de servio, ou burocracias do sistema, no permitiram a efetiva realizao de algumas redues de custos administrativos (mo-de-obra) previstas no projeto. Isso ocorre porque os mdulos de entrada de dados (apontamento de produo, recebimento fiscal, pedidos de compras) exigem a digitao de mais dados necessrios
integrao com outros mdulos. Embora essas digitaes pudessem ser evitadas por meio de
customizaes, estas no foram feitas, em decorrncia da orientao de se customizar o mnimo possvel. Segundo o gerente de TI, durante o projeto de implementao, toda a empresa
estava orientada pela determinao de customizar o mnimo possvel, mas, aps o trmino do
projeto e em decorrncia da cobrana por resultados (em relao mo-de-obra), h, na fase
de utilizao, uma presso maior no sentido contrrio, isto , que se realizem as customizaes no pacote.
Uma dificuldade trazida pela utilizao do sistema, apontada pelo gerente de controladoria, refere-se a apontamentos necessrios para a elaborao de um relatrio de custos por
centros de custos produtivos. Para que a apurao de custos fosse apresentada com o mesmo
nmero de centros de custos do que no sistema anterior, o Baan IV exigiria realizar uma srie
de apontamentos em fases intermedirias do processo, o que terminaria por onerar o pessoal
de produo. Optou-se por apontar a produo somente em alguns pontos do processo, e
para se obter o relatrio final, as informaes so combinadas em planilhas eletrnicas. No
sistema anterior, mais adaptado ao processo produtivo da empresa, esses apontamentos eram
desnecessrios. Segundo o gerente de controladoria, o excesso de burocracia do sistema impediu que se implementassem os apontamentos de maneira a se obter a informao, e hoje
sou obrigado a controlar em planilhas, at que se encontre uma soluo mais adequada,
como, por exemplo, uma "reparametrizao" do sistema.
H uma unanimidade entre os entrevistados da CNT de que os seis meses de utilizao
so insuficientes para que se possa extrair todos os benefcios do sistema, o que dever levar
mais seis meses ou um ano para acontecer. Segundo o gerente de controladoria, esse tempo

120

necessrio muito mais pela necessidade de aculturamento e conscientizao do que propriamente do sistema em si.
Um dos problemas mencionados pelo gerente de TI, em relao a todas as empresas do
grupo, foi a reabsoro dos usurios-chave por suas tarefas operacionais quando de seu retorno suas reas, sem que houvesse tempo para que desenvolvessem e aperfeioassem a utilizao do novo sistema. Segundo o entrevistado, os usurios-chave foram escolhidos entre os
melhores funcionrios, e eram, portanto, imprescindveis para o dia-a-dia. Desta maneira, a
presso para que voltassem s suas tarefas operacionais nos mesmos cargos que ocupavam foi
muito forte. De certa maneira, isso se tornou um problema, pois, a grande preparao que eles
receberam poderia ser mais bem aproveitada em tarefas de planejamento e melhoria contnua
do sistema.
A localizao foi considerada um dos principais problemas da implementao e ainda
persiste na fase de utilizao. Segundo o gerente de TI, h ainda o problema de que a cada
nova verso, ou mesmo correes em programas especficos, necessrio encarar aqueles
problemas nevrlgicos, isto , verificar e refazer novamente todas as customizaes feitas
nos programas que esto sendo atualizados, embora o entrevistado no considere o esforo
necessrio como equivalente ao de uma nova implementao. A fim de contornar este problema, a VMM no est mais instalando novas verses ou correes que atinjam a muitos
programas.
Alguns custos no esperados, percebidos na fase de utilizao so os custos de ajustes, isto , customizaes em programas e desenvolvimentos de relatrios, pois, segundo o
modelo de informtica adotado pela VMM, todas as customizaes so terceirizadas. Segundo
os entrevistados, 100 % dos relatrios do sistema foram customizados. O custo de retreinamento dos usurios tambm est sendo percebido, decorrente do fato de o prazo para implementao no ter permitido um treinamento completo de usurios e do turnover natural de
funcionrios.
Alguns problemas tecnolgicos esto sendo percebidos pela VMM na fase de utilizao.
Devido a problemas de performance, h a necessidade de, uma vez por ms, reorganizar o
banco de dados em um processo que demora em torno de 20 horas. Segundo o gerente de TI,
a combinao de equipamento Sun, banco de dados Informix e ERP Baan IV no bem conhecida no Brasil, e h alguns problemas que surgem inesperadamente, sem que haja a possibilidade de criar uma rotina preventiva. O gerente credita este problema falta de preocupao com aspectos de performance na criao das tabelas, que ele acredita no ser exclusivida-

121

de do Baan e falta de conhecimento dos fornecedores em lidar com a combinao Sun, Informix e Baan.
ERP e desempenho / competitividade
A melhoria da empresa, no aspecto desempenho e competitividade, ficou associada pelos entrevistados melhoria da qualidade da informao, permitindo uma tomada de deciso
mais segura e mais gil. A reduo do trabalho operacional, e uma evoluo para anlise das
informaes tambm foram citadas.
O gerente de TI afirma que a melhoria na competitividade ainda est por ser obtida, com
a utilizao de ferramentas do tipo supply-chain e a construo do e-business. O ERP mais
uma base, que daria suporte a estas atividades, permitindo o seu rpido desenvolvimento.
Integrao com outros sistemas
A folha de pagamento e o ativo fixo so rodados em pacotes de outros fornecedores,
integrados ao Baan IV por meio de transmisso batch de arquivos. O controle das exportaes
da empresa feito por meio de planilhas eletrnicas.
Outros Comentrios dos Entrevistados
Sobre a tecnologia: Sabe o que o ERP? expertise em processo. Em tecnologia, a
nota zero, para todos os pacotes. Voc percebe que as tabelas parecem desenvolvidas por
amadores, h grandes problemas de performance.
Sobre a integrao: Hoje voc aperta 3 botes e eu 10. Com o novo sistema, voc vai
apertar 5 botes e eu 5. Voc vai trabalhar mais, mas a empresa como um todo vai apertar
menos botes.
Consideraes sobre o Caso
Pontos de Destaque
Um dos destaques do caso CNT/VMM foi a dedicao em tempo integral dos usurioschave e a centralizao de toda atividade do projeto de implementao no escritrio da holding. Como efeitos dessa orientao, observou-se que o projeto ficou relativamente isolado
dos demais usurios nas empresas. Embora a dedicao em tempo integral dos usurios-chave
seja apresentada pela literatura como importante para o sucesso da implementao, uma vez
que se evita que o tempo necessrio para o projeto seja drenado por problemas do dia-a-dia e

122

permite-se a obteno de um maior comprometimento dos usurios, foi comentado por um

dos entrevistados que uma maior integrao com as reas envolvidas, nas fbricas, poderia ter
trazido melhores resultados.
Interessante tambm foi a deciso inicial de se customizar o sistema o mnimo possvel
no incio, importante neste projeto para que tanto o prazo como o custo fossem reduzidos.
Aps a implementao, verificou-se existir presses por parte dos usurios para que as adaptaes que no foram feitas na fase de implementao fossem realizadas. Entretanto, como
salientou o gerente de TI, ao deixar as customizaes para depois, a empresa pode ter obtido
benefcios por receber solicitaes mais maduras, ou seja, mais adequadas realidade do
novo sistema, uma vez que feitas com maior conhecimento a respeito de sua operao, e no
espelhando necessidades existentes nos sistemas anteriores.
Outro aspecto que merece nota o modelo de TI adotado pela VMM, com terceirizao
de todo o tipo de desenvolvimento, ficando a TI apenas com analistas de negcio, que compram as customizaes e relatrios de consultorias. Um dos aspectos apontados pelo gerente
de TI sobre esse assunto a permanente necessidade de adaptao dos programas. Segundo
ele, voc economiza por um lado, mas a utilizao de um sistema ERP uma mexida
constante e eterna, sempre h adaptaes e ajustes em programas e relatrios. Desta maneira, associadas utilizao de sistemas ERP com uma equipe bastante reduzida, esto despesas
com desenvolvimento de programas e customizaes.
Como na Rhodia, foram verificados problemas relativos localizao do pacote. Tambm como naquele caso, a VMM foi uma das pioneiras na implementao do sistema ERP no
Brasil (a verso Baan IV).
Principais Aspectos Presentes no Modelo Inicial
Entre as dificuldades presentes na etapa de utilizao, foram citados problemas relacionados instalao de novas verses de programas enviados pelo fornecedor, uma vez que
essas novas verses podem estar incompatveis com as modificaes realizadas.
Novos Aspectos que Podem Ser Incorporados ao Modelo Inicial
Como no caso anterior, foi observada a ocorrncia de grande quantidade de erros e problemas, nesse caso bastante ligados localizao, que tambm permitiram a caracterizao de
uma etapa de estabilizao, aps o incio da operao. Parte dos problemas foi decorrente das
dificuldades para se testar e eliminar todos os problemas, durante a etapa de implementao.
Tambm, como no caso anterior, no incio da operao foram verificadas falhas no treinamento dos usurios finais.

123

O caso da CNT/VMM permitiu ainda a observao de outros efeitos da integrao entre

os mdulos, presentes nos sistemas ERP. Uma vez que o sistema obriga que sejam cumpridas
determinadas etapas de registro das atividades, foi percebido que ele auxilia a controlar a maneira como so realizadas as tarefas. Dessa maneira, o sistema ERP uma poderosa ferramenta para a implementao de regras e procedimentos na organizao. A questo do controle remoto das atividades, na planta de Niquelndia, evidencia a possibilidade de utilizao
de um sistema de informaes, no caso um sistema ERP, para a reduo da quantidade de
supervisores e gerentes por meio da centralizao destas atividades. Impondo a realizao de
procedimentos e permitindo o controle distncia, o sistema ERP termina por reduzir a necessidade de superviso dos funcionrios.
A integrao entre as atividades e a conseqente ampliao da viso empresarial por
parte dos usurios foram percebidas vantagens relacionadas evoluo profissional dos funcionrios. A satisfao dos usurios com o novo sistema, na CNT, tambm pareceu bastante
ligada a problemas de qualidade do sistema anterior.
A dificuldade de implementar algumas funcionalidades em conseqncia do excesso de
burocracia, isto , da quantidade de telas e campos a serem preenchidas, mostrou como o
sistema ERP pode impor o aumento de tarefas em determinadas reas em decorrncia do fato
de ser um pacote genrico, que tenta atender a todos os tipos de empresas. A ausncia de relatrios adequados, sejam gerenciais ou operacionais, tambm foi verificada no caso.

124

6.3 CASO BOSCH

Empresa: Robert Bosch Limitada
Sistema ERP utilizado: SAP R/3, verso 3.0 fd
Entrevistas realizadas entre Outubro e Dezembro de 1.999.
Entrevistados: Gerente de Aplicao de Sistemas
Gerente de Controle Econmico
Chefe de Contabilidade Geral
Gerente de Materiais e Logstica
Pontos Principais do Caso
A caso Bosch oferece a perspectiva de uma implementao do sistema R/3 em uma empresa composta por vrias fbricas e divises utilizando uma combinao dos modelos de
implementao em small-bangs e em fases. Alm disso, o caso mostrou como ocorre o
aprendizado da empresa em um processo de implementao, uma vez que em cada sucessiva implementao do sistema ERP nas diversas fbricas, o processo tornava-se mais rpido,
mais simples e com melhores resultados. A Bosch mais complexa em termos de quantidade
de fbricas e divises, relativamente aos outros casos de R/3 estudados.
Apresentao da Empresa
O Grupo Bosch, com sede em Stuttgart, Alemanha, um dos maiores fabricantes de peas para a indstria automobilstica do mundo e administrado desde 1.964 por uma fundao
sem fins lucrativos, que controla 92% do capital acionrio. O faturamento anual do grupo da
ordem de US$ 21 bilhes.
A Robert Bosch Limitada, que ser citada daqui em diante apenas como Bosch, a subsidiria brasileira do grupo, e uma das maiores empresas limitadas do Brasil, com faturamento anual da ordem de US$ 1,2 bilhes. A Bosch possui 5 plantas: 2 em Campinas-SP,
uma em Curituba-PR, uma em Aratu-BA, e uma em So Paulo-SP. Em uma das plantas de
Campinas esto localizados os escritrios centrais da empresa. Em outubro de 1.999, a Bosch
contava com 13.100 funcionrios.
O Grupo Bosch possui ainda duas outras empresas no Brasil: A BS Continental (eletrodomsticos), e a Bosch Telecom (produtos de telecomunicao). Na Amrica Latina, o grupo
possui, ainda, fbrica na Argentina e escritrios de vendas na Venezuela e Colmbia.

125

Mercado e Principais Produtos

O negcio principal da Bosch a fabricao de autopeas (motores de partida, injees
eletrnicas, freios, faris, buzinas, entre outros) que responde pela maior parte de seu faturamento. Seus principais clientes so as grandes montadoras de automveis, que so atendidas
em um regime chamado de produo seriada, pelo qual os produtos so desenvolvidos especialmente para cada cliente, para serem utilizados em modelos e marcas de automveis especficos. Depois de desenvolvido o produto, acertado um contrato de fornecimento com o
cliente que inclui preos e prazos de entrega. Os outros produtos da Bosch so ferramentas de
potncia (furadeiras, serras eltricas) e equipamentos de som (auto-rdios, alto-falantes). A
fbrica de Campinas a mais complexa da empresa, pois atende a duas unidades de negcio
voltadas ao mercado automobilstico, uma unidade de ferramentas de potncia e mais as unidades produtivas centrais, como, por exemplo, uma fbrica de bens de capital (mquinas de
produo de equipamentos que so utilizadas pela Bosch) e uma estamparia, que atendem s
demais fbricas da empresa.
A rea de TI e Dados Tcnicos
A rea de TI da Bosch est localizada no escritrio de Campinas e conta com 71 funcionrios. Existe um diretor de informtica, ao qual esto subordinados trs gerentes: o gerente
de aplicao, responsvel pela parte funcional do R/3 (isto , ao atendimento das necessidades
de negcio dos usurios e da empresa por meio do uso do R/3), o gerente de basis (isto , a
parte tecnolgica do R/3), responsvel pela parte tecnolgica e suporte (redes, banco de dados, telecomunicaes, computadores, etc.), e o gerente de novas tecnologias, responsvel
pela prospeco e estudo de novas tecnologias de informao. No escritrio central em Campinas esto a rea de aplicao, com 26 analistas de negcios, a rea de basis, com 18 funcionrios e a rea de novas tecnologias, com 6 funcionrios. Alm desses h em cada localidade
2 ou 3 funcionrios dedicados operao do sistema e suporte aos usurios locais, exceo
da planta de Curitiba que tem 7 destes funcionrios. Os 26 analistas de negcio atendem tambm s demais unidades da Bosch no Mercosul. O diretor da rea se reporta ao diretor administrativo da empresa, que, alm da informtica, responsvel pela controladoria financeira e
logstica.
Atualmente, o R/3 roda em servidores Intel da IBM e da Siemens Nixdorf, em sistema
operacional Windows NT e banco de dados Oracle. So 5 servidores de bancos de dados, um
para cada planta, 4 deles localizados no prprio departamento de TI em Campinas (apenas a

126

mquina de Curitiba est localizada na prpria planta). Alm desses, em nmero que depende
da necessidade de processamento de cada planta, existem os servidores de aplicao. Essa
configurao caracteriza o uso do R/3 em uma arquitetura cliente-servidor de trs camadas.
Em cada um dos servidores de bancos de dados, roda uma instalao diferente do R/3.
Segundo o gerente de sistemas, apesar dessa separao, a diferena entre os sistemas de
cada uma das plantas mnima e est bem controlada. A troca de dados entre os sistemas das
plantas feita atravs do recurso ALE (application linking embedded) do R/3, que um mecanismo de replicao de dados que transporta os dados entre os diversos bancos de dados em
intervalos de tempos regulares (por exemplo, de hora em hora, dia a dia, etc.) com freqncia
que depende do dado e da aplicao. Entre os sistemas de cada planta so trocados os dados
de notas fiscais de transferncia de materiais, e entre estes sistemas e os mdulos centralizados (FI, SD e CO) so trocados dados referentes a lanamentos contbeis e ao faturamento, os
quais so consolidados no servidor central. A comunicao entre as plantas feita por satlite,
com resultados satisfatrios, segundo o gerente de sistemas.
Antes do R/3, a Bosch utilizava-se de uma srie de sistemas departamentais desenvolvidos internamente, rodando em mainframe, alm do pacote COPICS da IBM, contas a pagar da
ADP, contabilidade da Cetil, entre outras. Esses sistemas eram isolados ou integrados por
procedimentos batch. A informtica contava ento com 112 funcionrios.
Os Mdulos Implementados
A Bosch implementou os mdulos FI, CO, SD, MM, PP, WM (gerenciamento de armazm), PS (controle de manuteno) e QM (controle de qualidade) do R/3.
Os mdulos foram implementados por meio de small-bangs, isto , em sucessivas implementaes dos mdulos MM e PP, SD, QM, FI-Fiscal e CO-Custo do Produto em cada
uma das diversas plantas da empresa. Entre a implementao da fbrica de So Paulo e a de
Campinas, em abril de 1.998, foram implementados, em fases, os mdulos FI, na rea de Finanas Central, o SD, na rea de Comrcio Central e, na rea de Controladoria Central e Resultados, o mdulo CO, em janeiro de 1.999. Entre o incio do projeto de implementao na
primeira planta (Curitiba), em maio de 1.996, e o incio da operao na ltima planta (a segunda planta em Campinas, uma fbrica de freios), em junho de 1.999, transcorreram-se 38
meses.
A tabela 1 resume as datas de incio das operaes em cada planta e as quantidades de
usurios totais e simultneos (usurios que acessam o sistema em um mesmo momento). Na

127

implementao de Curitiba, houve um atraso de 4 meses no prazo inicialmente planejado de 7

meses. Nas demais implementaes no houve atrasos.

Planta ou Mdulo
Curitiba
So Paulo
FI (central)
SD Central
CO (central)
Campinas
Aratu
Freios (Campinas)
Totais

Incio da Tempo de Implementao Usurios Usurios

Operao
(Total)
(Simultneos)
Abr/1.997
11 meses
800
150
Mar/1.998
7 meses
620
70
Abr/1.998
3 meses
Set/1.998
9 meses
460
150
Jan/1.999
4 meses
Out/1.998
6 meses
1.600
200
n.d.
Jan/1.999
1,5 ms
300
n.d.
Jun/1.999
4 meses
325
38 meses

3.300 (*)

n.d.

(*) O total menor do que a soma dos usurios de cada planta ou mdulo porque usurios das plantas tambm acessam aos mdulos centrais

Tabela 1 - Usurios por planta ou mdulo na Bosch elaborada pelo autor

Histrico da Deciso e Seleo
A escolha do SAP R/3 uma deciso mundial do Grupo Bosch, em um plano que pretende at o ano 2.004 ter implementado o R/3 em todo o mundo, atingindo a cifra de 50.000
usurios (em outubro de 1.999 havia 20.000 usurios de R/3 no Grupo Bosch no mundo). Segundo material elaborado pela Symnetics (1999), a deciso do Grupo Bosch por um sistema
ERP est fundamentada no esforo em implementar uma estratgia para a integrao global
da empresa, no suporte estratgia de incorporao de novos negcios e na reduo dos custos de TI mundialmente. Ainda segundo a Symnetics, o suporte incorporao de novos negcios decorre do fato de que o R/3 auxilia na padronizao dos processos de empresas recm
incorporadas. A deciso pelo R/3 tambm vista pelos entrevistados como parte de um projeto de integrao e padronizao global dos sistemas de informao da empresa.
A subsidiria no Brasil foi uma das primeiras do Grupo Bosch a implementar o R/3,
principalmente porque os sistemas anteriores no estavam preparados para o ano 2.000, fato
que trouxe uma grande presso sobre o prazo para a implementao. Na Alemanha e Europa,
o Grupo Bosch, que usa o SAP R/2, est implementando o R/3 em suas fbricas, em um cronograma mais dilatado, pois no havia a presso causada pelo problema da compatibilidade
com o ano 2.000.
A Bosch j estava em um processo de seleo de ERP no Brasil, que havia sido iniciado
em 1.995 quando a deciso pelo R/3 foi tomada na Alemanha no final deste mesmo ano. Esse

128

projeto tinha como principais motivaes a necessidade da adaptao do sistema anterior ao

ano 2000 e substituio do mainframe, visando reduo de custos de informtica.
Histrico da Implementao
O caso da Bosch traz um exemplo das dificuldades existentes na implementao de um
sistema ERP em uma empresa com maior nmero de plantas, divises e quantidade de usurios. A Bosch decidiu implementar o R/3 em small-bangs, fbrica por fbrica, considerando
cada uma das implementaes como um projeto, isto , com diferentes responsveis e prazos
de implementao. Alm da implementao dos mdulos citados nas plantas, haveria a implementao das reas centrais com os mdulos FI, SD e CO no escritrio de Campinas, tambm consideradas como projetos. Segundo o material da Symnetics, a deciso de realizar a
implementao em small-bangs teria como objetivo a criao, na primeira implementao, de
um padro de configurao que seria replicado s demais plantas, facilitando o processo e
reduzindo os custos pela diminuio da dependncia de consultoria externa. A opo pela
fbrica de Curitiba como piloto deu-se, segundo o mesmo documento, por excluso. A fbrica de Campinas era muito complexa, o que a descaracterizava como piloto. A fbrica de
Aratu, embora pequena, era pouco representativa das demais e havia ainda o problema da
distncia. A fbrica de So Paulo havia sido recentemente incorporada empresa e, assim
como a fbrica de Aratu, no foi considerada representativa das demais. Escolheu-se, portanto, a fbrica de Curitiba. Essa deciso foi tomada pelo comit diretivo do projeto, composto
pelos diretores plenos, diretores administrativos das plantas e diretores das reas, que tambm
definiu a ordem e prazos de implementao nas demais plantas e a composio dos comits
executivos que seriam responsveis pelos projetos em cada uma delas. Em cada comit executivo havia um lder escolhido entre as reas usurias da planta, considerado como o dono
do projeto, e um lder da rea de TI. O lder usurio deveria coordenar os responsveis de
cada uma das reas usurias, e o lder de TI os funcionrios de TI e consultores. A Bosch optou por no utilizar consultoria externa na gerncia ou mesmo na realizao dos projetos, mas
apenas para solucionar problemas tcnico-operacionais, ou seja, dvidas pontuais e problemas relacionados ao sistema. A metodologia utilizada foi a da prpria SAP (ASAP), com
adaptaes definidas pela Bosch. As etapas seguidas em cada um dos projetos foram: definio do escopo do projeto, modelagem e prototipao, preparao para a produo (testes finais, treinamento e converso dos dados dos sistemas antigos), incio da operao e acompanhamento inicial.

129

Segundo o relatrio da Symnetics, foram escolhidos os melhores funcionrios de cada

uma das reas para integrar o time de projeto. Os usurios escolhidos para participar das
implementaes, denominados usurios-chave, receberam os treinamentos oficiais da SAP e
foi criado um laboratrio de prototipao, para que fosse feita a modelagem do sistema. Aps
a modelagem dos processos, o treinamento dos usurios finais foi conduzido pelos usurioschave, que agiram como multiplicadores do conhecimento. Antes do incio das operaes,
foram realizados testes de integrao no sistema, por meio de simulaes das transaes de
um dia normal da empresa.
Segundo o gerente de sistemas e o gerente de logstica, os small-bangs trouxeram um
risco elevado em cada uma das plantas, mas o risco elevado foi importante para fazer com
que as coisas acontecessem. Haviam sido estabelecidos procedimentos para voltar ao sistema anterior em caso de problemas no incio da operao, mas sabia-se que aps uma hora de
utilizao do novo sistema, isto seria extremamente difcil. O conhecimento do fato de que
no havia como voltar atrs, obrigou as pessoas a irem para frente, segundo o gerente de
sistemas. Nos momentos que antecediam a virada em cada uma das plantas, havia um
nvel de tenso muito grande. E isso era muito importante. Isso uma caracterstica do ser
humano. Sempre temos que dizer no tem jeito de voltar. A, as pessoas vo. O gerente
tambm afirmou que, nesses momentos de tenso, algumas pessoas se estressam, outras tm
muita garra. muito importante a presena de lderes que possam manter o ambiente estvel
nesse momento, pois todo mundo est bastante tenso. De acordo com o gerente de sistemas,
no houve como fazer a implementao por mdulos nas fbricas, porque difcil distinguir
exatamente onde comeam e onde terminam os mdulos em um sistema integrado. Um processo atravessa os diversos mdulos.
Na fbrica de Campinas, o grupo de projeto contou com, aproximadamente, 46 usurios-chave, com 70% do tempo dedicado ao projeto.
Implementao: Problemas
Pelo fato de a implementao ter sido feita em small-bangs, foi necessria a construo
de interfaces (programas para troca de dados) entre o sistema R/3 nas plantas implementadas
e os sistemas centrais no mainframe, at estes terem sido totalmente substitudos, alm da
necessidade de troca de dados entre os sistemas das plantas (transferncia de materiais). Segundo o gerente de sistemas, as interfaces entre sistemas so crticas, uma vez que so a fonte
de muitos e constantes problemas. Entre as razes apresentadas, est o fato de que a concep-

130

o dos sistemas R/3 era diferente da dos sistemas do mainframe, o que levou necessidade
de serem feitas adaptaes nos dados. Dependendo do tipo de adaptao, impossvel fazer
com que os dados coincidam nos dois sistemas. Alm disso, a impossibilidade de prever todos
os tipos de situaes na construo de interfaces, programas feitos rapidamente para terem
vida curta, ocasionava novos e inesperados problemas medida que outros eram resolvidos.
De acordo com o gerente de sistemas, quanto menos interfaces, melhor. Minha percepo
a de que as interfaces, ao contrrio do que se imagina, aumentam o risco em uma implementao por mdulos. A implementao por fases pode reduzir o risco operacional, mas as interfaces aumentam o risco, porque geram erros o tempo todo.
Aps a implementao de Finanas Central (FI) em abril de 1.998 e Comrcio Central
(SD) em Set/98, eliminou-se uma boa parte do problema, mas novas interfaces tiveram que
ser construdas na outra direo, porque ainda havia trs fbricas (Campinas, Aratu e
BSBR) que utilizavam o sistema anterior. As interfaces tiveram ento que ser desenvolvidas
para enviar e receber dados dos sistemas das plantas no mainframe para os mdulo FI e SD no
R/3. Apenas com a finalizao do projeto, em junho de 1.999, eliminou-se completamente o
problema das interfaces temporrias.
Outro problema importante, segundo o gerente de sistemas, foi o enfoque dado ao treinamento das pessoas. As pessoas foram bastante treinadas na operao do sistema, mas no
nas caractersticas que diferenciam um sistema integrado dos sistemas isolados com os quais
estavam acostumadas. Seria importante o treinamento em aspectos como a preocupao com
os resultados das operaes locais em outros departamentos e a importncia da atividade de
cada um para o todo da empresa. Como conseqncia desses problemas no treinamento, o
gerente de custos apresentou a grande quantidade de digitao de movimentaes incorretas
por desconhecimento do efeito que as operaes causam nos demais mdulos. Como os sistemas anteriores permitiam uma srie de estornos e correes, antes da integrao dos dados
com os outros mdulos (em batch), no havia a preocupao de digitar corretamente os valores logo na primeira vez. Segundo o gerente de sistemas, no R/3 as pessoas so obrigadas a
seguir os procedimentos.
Para o gerente de logstica, o apoio de consultoria externa deveria ter sido mais utilizado
na fase de anlise dos processos, pois a rea usuria tem grande conhecimento do processo,
enquanto a rea de TI conhece bem o funcionamento de sistemas informatizados. Na fase de
planejamento, a fase mais importante da implementao, a consultoria poderia auxiliar na
integrao dos dois conhecimentos, disponibilizando uma metodologia mais adequada para

131

que os processos fossem modelados no sistema. J durante as etapas finais da implementao

(testes e treinamento), o gerente concorda que a consultoria no seria necessria.
Houve resistncia mudana e muito esforo para mostrar que o sistema funciona. O
gerente de logstica, que foi coordenador do projeto na fbrica de Campinas juntamente com o
gerente de sistemas, afirmou que uma das dificuldades do projeto foi a obteno do comprometimento de todas as reas, pois nem todas as reas se envolvem da mesma maneira. Segundo ele, foi grande o trabalho para obter esse comprometimento, atravs da constante argumentao e lembrana de que o projeto no era dos coordenadores, mas sim das reas,
e que os resultados e desempenho seriam cobrados dos responsveis das reas. Chegou a
ser necessrio envolver a diretoria da fbrica nesse processo. Como exemplo, o gerente de
logstica comentou que, nas reunies mensais, era exigido dos gerentes das reas usurias que
se fizesse um relatrio de acompanhamento. Muitas vezes, estes gerentes procuravam-no para
que ele, como coordenador do projeto, fizesse o relatrio e o apresentasse na reunio. Nessas
ocasies, segundo o entrevistado, era sempre necessrio lembrar que a responsabilidade pelo
acompanhamento dos resultados em cada rea, e, portanto, pela execuo do relatrio era de
cada um dos gerentes, e no do coordenador. Mas, segundo o entrevistado, aos poucos o comprometimento foi sendo obtido e, a partir de ento, o projeto evoluiu com facilidade e motivao elevada. Segundo ele, Se o projeto do usurio, e o usurio no vestir a camisa, fica
difcil. O usurio tem que internalizar o projeto, tem que assumir.. O projeto de Campinas
envolvia a implementao dos mdulos PP, MM, FI, QM, WM, SD e CO, e o gerente de logstica considera um sucesso a implementao de um sistema novo para 1.200 usurios em 6
meses.
Outro problema citado pelo gerente de informtica foi o despreparo dos consultores que
atenderam a empresa. Segundo o entrevistado, por ter sido uma das primeiras implementaes
do R/3, os consultores no estavam devidamente preparados. Para ela, Os consultores disponveis no mercado no tm domnio dos processos. Normalmente uma pessoa com boa formao, mas com pouco domnio do processo. Como resultado disso, a Bosch investiu na
formao de seus tcnicos, o que inclusive causou a perda de alguns funcionrios para o mercado, carente de profissionais com conhecimento no pacote.
Mudar o Pacote ou a Empresa?
Na primeira implementao, na fbrica de Curitiba, a norma era no mudar a empresa. Acreditava-se que tal procedimento tornaria mais rpida a implementao, uma vez que

132

no haveria a necessidade de reviso de processos. No entanto, segundo os gerentes entrevistados, isto no ocorreu. Ao contrrio, a excessiva preocupao em no mudar os processos da
empresa gerou a necessidade de uma srie de pequenas customizaes para a adaptao de
pequenos detalhes, que terminaram por tornar o processo muito mais lento e mais custoso,
com um resultado pouco satisfatrio.
Na planta seguinte, em So Paulo, procurou-se aproveitar melhor as caractersticas do
R/3, mudando os processos da empresa quando houvesse convenincia. Segundo o gerente de
sistemas entrevistado, no foi feita uma reengenharia [isto , uma mudana radical nos processos da empresa], mas deixamos o SAP fluir, e assim tiramos os benefcios. A implementao foi mais rpida, devido menor quantidade de customizaes necessrias. Tambm
influenciou bastante nesse resultado, segundo os entrevistados, a crescente experincia dos
profissionais da Bosch com o R/3. O padro de configurao, que era planejado para ser
construdo na primeira implementao em Curitiba, comeou a tomar forma apenas na terceira implementao, na fbrica de Campinas. Agora, a Bosch planeja reimplementar o R/3 nas
primeiras plantas (Curitiba e So Paulo) para aproveitar a experincia e os resultados obtidos
na fbrica de Campinas.
A questo do aprendizado por parte da equipe da Bosch ficou clara quando se discutiram as necessidades de adaptao do mdulo de custos, que se pressupunha bastante problemtico, porque o mtodo de custeio da Bosch considerado muito diferente do padro. Especificamente no sistema de custos, a determinao era no mudar nenhum procedimento ou
informao da empresa, optando-se por adaptar totalmente o R/3. O sistema de custos da
Bosch mundialmente padronizado, da a determinao em mant-lo. Com ele, a Bosch consegue comparar a performance de quaisquer fbricas no mundo, com a finalidade de trocar
informaes e projetos de melhoria entre elas. Por ter sido o ltimo mdulo implementado,
apesar de sua complexidade e do desafio de faz-lo exatamente igual ao sistema anterior, foi o
que recebeu o menor nmero de customizaes, sendo toda a adaptao praticamente feita
com base em parametrizao.
Segundo o gerente de logstica, em sua rea, o sistema anterior disponibilizava uma srie de funcionalidades que ainda no foram completamente atendidas pelo R/3, citando o caso
de um controle de desempenho de fornecedores por meio de uma srie de indicadores de eficincia (prazo de entrega, qualidade, etc.), disponvel no sistema anterior. Existem indicadores para essa anlise no R/3, que, entretanto, no so exatamente iguais aos do sistema anterior. Neste caso, optou-se por adaptar a empresa ao novo mtodo, o que est gerando dificulda-

133

des na avaliao dos fornecedores. Entretanto, segundo este gerente, importante evitar ao
mximo mexer no sistema R/3, em decorrncia das dificuldades para atualizao gerada
pelas customizaes. S quando for inevitvel, que se deve alterar o sistema ERP. O gerente de logstica estima que, em sua rea, cerca de 95% do sistema tenha sido implementado
sem adaptaes.
Utilizao: Benefcios
Entre os benefcios citados espontaneamente pelos gerentes esto o fato de toda a companhia usar a mesma informao, sem diferena entre dados apresentados pelos diversos departamentos, e a integrao, ressaltada no aspecto digitao nica do dado na empresa. Antes, informaes a respeito de estoques, por exemplo, eram diferentes nos departamentos de
materiais, finanas e contabilidade. O gerente de logstica citou esta integrao dos mdulos
(materiais, finanas, contabilidade) como a grande vantagem do R/3 sobre os sistemas anteriores.
A qualidade, isto , a exatido das informaes, tambm foi citada. Segundo o gerente
de custos, no se perde nada [nenhuma movimentao], tudo vai para o resultado. O maior
controle sobre as diversas operaes da fbrica, em decorrncia da obrigatoriedade de lanamento de todas as movimentaes no momento em que ocorrem, tambm citado por esse
gerente.
Segundo o gerente de sistemas, com o R/3 possvel, a partir de agora, fazer a evoluo e melhoria dos processos da empresa, pois sabemos que o sistema ir acompanhar, isto
, ser possvel adaptar mais fcil e rapidamente o sistema s novas necessidades da empresa.
Segundo o entrevistado, isso tambm decorre do fato de que, aps a implementao do R/3,
possvel enxergar a companhia como um todo, isto , ter uma viso macro e um melhor
conhecimento do funcionamento dos processos. Outro benefcio citado por esse gerente reside
no fato de o software, por ser fornecido por uma empresa especializada, estar sempre em
evoluo e recebendo novos desenvolvimentos, tais como o e-commerce e o APO (Advanded
Planner and Optimizer), ferramenta de planejamento e sequenciamento de produo disponvel no R/3). Sobre esse mesmo aspecto, o gerente ressalta a vantagem de se ter uma empresa
que pense globalmente desenvolvendo o software. Dessa maneira, as diferenas regionais
dentro de uma mesma empresa so minimizadas, pois todas as localidades podem rodar o
mesmo sistema (a Bosch ir utilizar o R/3 na sua planta em Buenos Aires, Argentina, a partir
de um servidor instalado em Campinas, com instalao similar do Brasil).

134

Na contabilidade, houve uma reduo do tempo para fechamento do balano de 30 para

15 dias, e segundo o chefe de contabilidade, h a possibilidade de reduzir-se ainda mais este
tempo. Na rea financeira, o nmero de pessoas foi reduzido de 70 para 55 pessoas.
Outros benefcios, apresentados no relatrio da Symnetics, so o aumento do comprometimento dos funcionrios com a qualidade da informao, uma vez que estes passaram a
compreender a importncia das informaes que entram no sistema, e a capacidade de absorver aumentos na complexidade do negcio, sem que haja a necessidade de aumentar o quadro
de funcionrios para realizar o controle e o planejamento adicionais. Aps a implementao
do R/3, por necessidades do mercado, a Bosch aumentou o nmero de produtos produzidos
em cada planta, e, segundo o relatrio citado, o sistema permitiu que isso fosse feito sem aumento de pessoas nas funes de controle e administrao.
Utilizao: Problemas
Segundo todos os entrevistados, o R/3 pobre em informaes gerenciais e esse um
dos grandes problemas do sistema. Um dos gerentes afirmou que o sistema tem as informaes do jeito que ele acha que voc tem que ter, e muitas vezes voc tem que ter a informao
um pouco diferenciada, pois cada empresa peculiar em algumas coisas. A Bosch est implementado o BW (business warehouse), uma ferramenta de EIS (executive information system) da prpria SAP, para permitir a extrao de informaes gerenciais.
Apesar de terem sidos despendidas 30.000 horas de treinamento com os 1.000 usurios
(uma mdia de 30 horas por usurio) na fbrica de Campinas, o gerente de logstica acredita
que haja necessidade de retreinamento, pois considera que o nvel de conhecimento no uniforme entre os usurios.
O gerente de sistemas citou o fato de o R/3, por vezes, dificultar o trabalho do usurio,
em decorrncia do grande nmero de telas para realizar um processo. E citou tambm que h
problemas de performance e lentido de processamento.
Ainda h problemas de localizao, principalmente nos registros fiscais, onde alguns
lanamentos tm de ser corrigidos manualmente. A SAP garante o atendimento legislao
estadual, mas no municipal, que tem que ser feita atravs de customizaes, por meio de
programas desenvolvidos pela Bosch. Os juros de cliente (atrasos em pagamentos) tambm
so controlados em planilhas eletrnicas, pois no so contemplados pelo R/3.

135

Integrao
As entrevistas revelaram um aspecto relacionado integrao: por ser integrado e orientado a processos, o sistema termina por mostrar onde os processos esto errados, j que
no mais possvel esconder procedimentos dos demais departamentos da empresa. O gerente de logstica citou que a integrao do sistema exige mais trabalho na digitao dos dados, bem como uma maior qualidade de servio nessa entrada de dados. Entretanto, esse maior trabalho em algumas reas reflete-se em benefcios em outras.
ERP e desempenho / competitividade
O gerente de sistemas entende que muito difcil creditar melhorias de desempenho e
competitividade ao sistema ERP apenas, pois a empresa no est parada, esperando a implementao do ERP. Durante o tempo de implementao [3 anos] existiram vrios projetos
de melhoria e racionalizao de processos, o mercado mudou, os produtos mudaram, houve
troca de diretorias, etc.. Entretanto, o gerente salienta que o ERP permite uma maior agilidade no contato com os clientes.
O gerente de logstica entende que, embora o ERP ainda no possa ser associado a ganhos diretos e reduo de mo-de-obra administrativa em sua rea, houve ganhos qualitativos
importantes, tais como agilidade no atendimento e capacidade de reagir mais rapidamente s
alteraes de pedidos por parte dos clientes, capacidade esta creditada possibilidade de realizar o processamento do MRP duas ou mais vezes por semana. No sistema anterior, o processamento demorava 10 horas e era realizado uma vez por semana, nos finais de semana. No
sistema atual, o processamento do MRP realizado em 1 hora, e pode ser rodado com maior
freqncia, na hora do almoo. O entrevistado salientou que no possvel obter redues em
mo-de-obra administrativa, rapidamente, com a implementao de um sistema ERP, pois
num primeiro momento, com a implementao de um sistema ERP, a sua necessidade de
pessoal passa a ser maior do que a que voc tinha antes.
O Departamento de Consultoria criado na Logstica
Durante o processo de implementao na fbrica de Campinas, a rea de logstica sentiu
a necessidade de criar um minidepartamento para dar continuidade ao processo de aprendizagem e utilizao de novos recursos do sistema. Este minidepartamento, que composto por
dois funcionrios que se destacaram durante a implementao e que tm uma grande viso do
processo de logstica da empresa, tem como responsabilidade o desenvolvimento contnuo do

136

SAP e o treinamento dos usurios. Segundo o gerente de sistemas, o ERP est tirando o servio burocrtico das pessoas. Se estas pessoas forem reaproveitadas para pensar na empresa, os ganhos podero ser muito grandes. Segundo o gerente de logstica, ns vivemos
do sistema, necessrio um recurso voltado sua melhoria contnua. A rea de logstica de
Campinas a maior rea de logstica da empresa e tem um papel de coordenao sobre aspectos das reas de logstica das demais empresas que envolvem todas as plantas, como a
transferncia de materiais.
A Nova Verso
No momento da realizao das entrevistas, a Bosch estava planejando a atualizao da
verso do R/3 (da verso 3.0 para a 4.6). Segundo os entrevistados, essa mudana tem uma
complexidade razovel, e exige esforo no planejamento, teste e mesmo redesenvolvimento
de customizaes feitas na verso anterior. Segundo um dos entrevistados, a mudana de verso praticamente obrigatria, pois muitas dos problemas que so comunicados SAP no
so resolvidos pelo fornecedor, que informa que os mesmos j esto solucionados na nova
verso. Mesmo assim, a Bosch est fazendo um projeto para justificar economicamente o
projeto de atualizao, que deve ser aprovado pela diretoria. Alguns dos custos associados
atualizao so o retreinamento de pessoas, a compra de novos servidores e discos (maior
exigncia de capacidade de processamento), novos microcomputadores (maior exigncia nos
clientes tambm), custos de desenvolvimento para mudana nos programas customizados e
custos de consultoria. H tambm a necessidade de reviso de processos, em decorrncia da
alterao de algumas funcionalidades existentes na verso anterior e a incluso de novas. A
necessidade de se refazerem as customizaes decorrente do fato de que as alteraes nos
programas podem invalidar a maneira como estas foram construdas na verso anterior. A
atualizao, entretanto, traz benefcios como novas caractersticas oferecidas no R/3 e a
oportunidade para rever e melhorar a maneira como alguns processos foram implementados.
As Ordens de Produo Repetitivas
Um exemplo que merece nota na implementao na fbrica de Campinas est associada
a uma funcionalidade do R/3 que foi adotada pela empresa, e por meio da qual pode-se analisar alguns aspectos relacionados implementao de um sistema ERP.
O R/3 permite que sejam cadastradas no sistema de manufatura ordens de produo repetitivas, isto , que no so encerradas quando a quantidade solicitada produzida, permitindo que sejam produzidos novos lotes de produtos, utilizando-se a mesma ordem j digitada no

137

sistema. Esse tipo de ordem de produo adequado para produtos com produo contnua.
Na Bosch, a utilizao das ordens de produo repetitivas facilitou o processo de criao de
ordens de produo em produtos que so produzidos continuamente, ou com entregas muito
freqentes, eliminando grande trabalho de redigitao e controle de grande nmero de ordens
de produo.
Analisando essa funcionalidade, o gerente de planejamento e logstica comentou que o
R/3 diminuiu a dependncia dos usurios na rea de informtica uma vez que possvel escolher qual modelo de gerenciamento da produo ser usado em cada produto, entre os diversos tipos disponveis (repetitiva, por lote de produo, por pedido de venda, kanban, etc.),
sem ter que pedir para a informtica desenvolver um novo sistema. Ou seja, devido grande gama de opes disponveis no sistema, o usurio tem maior flexibilidade do que em um
sistema proprietrio desenvolvido internamente. No caso destes sistemas, muitas vezes as
funcionalidades vo sendo adicionadas medida que surgem a necessidade ou a idia. Um
sistema ERP j traz embutido um maior nmero de opes, em decorrncia da ao dos diversos clientes que j usam o sistema. No caso da Bosch, essa possibilidade j havia sido solicitada no sistema anterior, mas no foi desenvolvida por questes de custo. Com a implementao do R/3, houve a oportunidade de mudana.
tambm interessante notar que na primeira fbrica (Curitiba), as ordens repetitivas
no foram implementadas, em decorrncia da orientao inicial de no se alterarem os procedimentos da empresa. Aps a implementao em Campinas, percebeu-se que essa caracterstica poderia ter trazido benefcios fbrica de Curitiba. Como j citado, prevista uma reimplementao do R/3 na fbrica de Curitiba, para que essa e outras funcionalidades sejam disponibilizadas.
Entretanto, o uso da funcionalidade em questo mostrou-se inadequado utilizao do
sistema de custos tal como foi definido pela Bosch, o que trouxe problemas na implementao
deste mdulo. Segundo os entrevistados, o uso das ordens repetitivas exigiu um maior grau de
customizao e de trabalho para a adaptao do mdulo de custos do que poderia ter sido necessrio se a implementao do sistema ERP tivesse sido iniciada pelo mdulo de custos ou,
ainda, se este fosse levado em considerao pelas equipes de projeto desde o incio das implementaes.

138

Consideraes sobre o Caso

Pontos de Destaque
Um ponto de destaque no caso da Bosch foram as mudanas de orientao quanto
customizao realizadas ao longo das sucessivas implementaes. A orientao inicial de no
mudar os processos da empresa, adaptando o pacote sempre que necessrio, pode ser atribuda
ao relativo desconhecimento da nova soluo e preocupao de que um pacote comercial
poderia no atender s necessidades da organizao. Essa orientao mudou quando a empresa comeou a conhecer melhor as caractersticas e possibilidades do sistema. Tambm percebeu-se que esta alternativa gerou um nmero muito grande de customizaes relacionadas a
pequenos detalhes operacionais que chegaram a comprometer o prazo do primeiro projeto, em
Curitiba (como citado, houve um atraso de 4 meses na primeira implementao). Nas implementaes seguintes, com maior conhecimento do pacote e com a maior confiana na soluo,
foi possvel aproveitar melhor as funcionalidades j existentes e buscar uma adequao mais
flexvel entre empresa e pacote. Verificou-se ento, neste caso, que diminui-se a tenso e a
exigncia dos usurios e da empresa por detalhes menores medida que a empresa aprende a
utilizar um pacote e confia mais nos resultados. Segundo o gerente de sistemas, quando voc
j tem a viso de processo [de como o R/3 trabalha], os detalhes desaparecem. Isso reduziu o
nmero de pendncias violentamente. Outro aspecto percebido ao longo das sucessivas implementaes foi a reduo da necessidade de apoio externo de tcnicos e consultores, que foi
maior na fbrica de Curitiba do que nas demais fbricas. Isso tambm evidenciou o aspecto do
aprendizado da empresa em relao ao uso do sistema ERP. A empresa tambm percebeu que
a criao de um modelo para a implementao nas outras fbricas no foi possvel logo na
primeira vez, sendo necessrias trs outras para que o modelo Bosch comeasse a tomar
forma. Isso pode significar que a criao de modelos de negcio em laboratrio, isto , sem
a sua utilizao na prtica da empresa, uma tarefa que pode ser invivel. Tambm verificouse que ao se conhecer melhor as caractersticas e possibilidades do sistema ERP, a necessidade de resolver os problemas de adaptao por meio de customizaes diminui, fato que se
verificou nas sucessivas implementaes na Bosch.
Tambm pde-se perceber neste caso a complexidade envolvida quando um sistema
ERP implementado em uma empresa composta por diversas plantas e unidades de negcios
e a conseqente necessidade de elaborar um projeto de implementao que combinasse smallbangs e implementao por fases de alguns mdulos, sendo conduzidos por diferentes equipes

139

de projeto. A durao do projeto (38 meses) tambm significativa e est relacionada estratgia adotada.
No caso Bosch, o R/3 foi uma definio da matriz, parte de uma estratgia global de
unificao dos sistemas de informao. Interessante notar, sobre este ponto, que o sistema de
custeio foi o nico que recebeu orientao explcita da matriz de ser mantido exatamente igual
ao existente no sistema anterior. Isso porque o sistema de custos da Bosch j era padronizado
mundialmente, antes do incio da implementao do R/3, e j cumpre uma srie de objetivos,
tal como permitir a comparao de desempenho entre fbricas de todo o mundo.
A opo da empresa em no utilizar consultoria para o planejamento e gerncia do projeto tambm destacou-se.
Principais Aspectos Presentes no Modelo Inicial
Como previsto no modelo inicial, percebeu-se que na implementao em fases os mdulos j implementados trazem restries aos mdulos seguintes, como verificou-se no caso
do mdulo de custos. Esse mdulo recebeu uma carga maior de adaptaes do que seria necessrio, porque precisou levar em considerao restries relativas a como o mdulo industrial estava sendo utilizado na Bosch. Verificou-se tambm que a atualizao de verses pode
obrigar o redesenvolvimento de customizaes j feitas e testadas, acrescentando mais uma
dificuldade essa atividade.
A criao de um departamento permanente para estudo e melhoria do uso do sistema
ERP localizado, no na rea de TI, mas em uma rea usuria (logstica), mostrou um dos aspectos apresentados por Davenport (1999) - a necessidade de a empresa manter a preocupao
com a evoluo do sistema ERP para que possa colher maiores benefcios.
Novos Aspectos que Podem ser Incorporados ao Modelo Inicial
O caso mostrou os seguintes benefcios dos sistemas ERP que no haviam sido observados na literatura: 1) a diminuio da dependncia das reas usurias em relao rea de
TI, uma vez que o sistema ERP disponibiliza grande quantidade de alternativas de uso, como
observado no caso das ordens de produo repetitivas e 2) o aumento da produtividade da
mo-de-obra administrativa, uma vez que foi possvel Bosch incorporar novos negcios e
expandir a sua linha de produtos, mantendo-se os mesmos quadros para controle.
A percepo dos entrevistados de que o momento do incio da operao do sistema um
dos mais crticos para o projeto como um todo, por sua grande carga de tenso emocional,

140

pode ser includa como um dos aspectos de uma etapa de estabilizao, includa no modelo de
ciclo de vida dos sistemas ERP. A presena de lderes que possam manter as pessoas tranqilas e confiantes nessa etapa foi considerada fundamental, e uma das recomendaes para
essa etapa que pode ser extrada deste caso.
Tambm neste caso, como em outros, pde-se perceber como os benefcios e dificuldades da integrao esto relacionados eliminao dos estoques de problemas e conseqente
necessidade de apontar as operaes no sistema corretamente e no momento em que ocorrem.
A transparncia que o sistema integrado traz aos departamentos envolvidos, mostrando os
processos errados, tambm foi verificada nesse caso. Assim como na Rhodia Poliamida, as
dificuldades relacionadas a esse aspecto tambm foram percebidas como falhas no treinamento do usurios finais, preparados apenas para as funes que iriam executar, sem a preparao para lidar com os aspectos relativos ao trabalho em um sistema integrado.
Contrastes com o Modelo Inicial
No caso da Bosch, percebeu-se que as dificuldades tcnicas e decorrentes da necessidade de construo de interfaces na opo de implementao por small-bangs e fases trazem
alguns riscos tambm a esses modelos. Apesar de a possibilidade de interrupo das atividades da empresa ser diminuda, em oposio a uma implementao em big-bang (que no caso
Bosch seria muito arriscada, em conseqncia do nmero de plantas), pode-se perceber que a
necessidade de construo, utilizao e manuteno de interfaces entre os sistemas anteriores
e o novo sistema traz outros tipos de risco operacionais. Ao contrrio do levantado na literatura, essas opes tambm podem apresentar riscos. Tambm neste caso percebeu-se que os
small-bangs trazem elevada motivao, em cada uma das plantas.

141

6.4 CASO SANTISTA ALIMENTOS

Empresa: Santista Alimentos S/A
Sistema ERP utilizado: Baan IV, verso C.3
Entrevistas realizadas entre Dezembro de 1.999 e Janeiro de 2.000
Entrevistados: Sr. Gerente de Informtica
Sr. Gerente Industrial
Sr. Coordenador de Sistemas - Mdulo de manufatura
Sr. Chefe de Desenv. de Sistemas - Mdulos financeiro
Sr. Chefe de Desenv. - Mdulos de materiais
Sr. Analista de Suporte Snior
Pontos Principais do Caso
O caso Santista destaca-se pela utilizao do sistema ERP com a finalidade de centralizar sistemas e departamentos distintos em 23 localidades no Brasil. Seu processo de implementao, devido ao tamanho da empresa e diversidade de seus negcios, foi conduzido por
uma grande equipe de projeto, utilizando uma combinao de implementao em fases por
mdulos e por fbricas. Outro destaque do caso a ligao feita entre o sistema ERP e as mquinas de produo da empresa, o que permitiu grande controle sobre o processo produtivo.
Apresentao da Empresa
A Santista Alimentos uma empresa nacional pertencente ao grupo Bunge, cuja sede
est atualmente localizada nos Estados Unidos. A empresa foi fundada em 1.905, iniciando
suas atividades como produtora de farinha de trigo. Em 1.908, a empresa foi adquirida pela
Bunge e iniciou a expanso de seus negcios, incorporando as atividades de produo de leo
de caroo de algodo, leo de amendoim, margarinas e produtos originados da soja. Em
1.986, a empresa incorporou a Petybom, empresa produtora de bolachas e biscoitos, e, em
1.995, a Pullman, fabricante de pes e bolos. At 1.994, a Santista operava de forma totalmente descentralizada, quando a sua diretoria decidiu pela centralizao administrativa da
empresa. As diversas fbricas do grupo foram unidas em uma s empresa, a Santista Alimentos. (Na apresentao do caso a empresa ser chamada apenas de Santista).
A empresa possui 23 plantas, todas no Brasil, sendo oito moinhos de trigo, dois moinhos de milho, duas fbricas de massas, quatro fbricas de pes, quatro fbricas de margarina
e maionese e trs grandes centros de distribuio. O escritrio central que ficava sediado no
Centro Empresarial, em So Paulo-SP, foi transferido, em 1.997, para o bairro do Jaguar, na

142

mesma cidade, onde esto localizadas uma fbrica de margarina, uma fbrica de maioneses e
uma refinaria de leos vegetais. Na mesma localidade ficam localizados os departamentos
corporativos (administrativos, financeiros, logstica) e o departamento de informtica.
Mercado e Principais Produtos
A Santista fabrica produtos derivados do trigo, soja, e milho, tais como farinhas, farelos,
misturas para bolos, leos vegetais, gorduras vegetais, lecitina, margarinas e maioneses, massas, pes e bolos, alm de uma linha de produtos tais como requeijes e gelias e leos especiais (girassol e canola). A empresa atende ao mercado consumidor, ao mercado industrial,
padarias e ao segmento de lanchonetes, hotis e restaurantes. No mercado consumidor, os
produtos so distribudos por supermercados e atacadistas. A empresa tem aproximadamente
26.000 clientes, considerando todos os setores.
Segundo dados disponibilizados pela empresa, ela lder no mercado nacional de margarinas, com participao de 40%, e no mercado de leos especiais (girassol, canola e milho),
com 23% de participao. Alm disso, possui posio de destaque nos setores de farinha de
trigo, massas, maioneses e pes. Toda a produo da Santista vendida no mercado nacional.
Entre seus principais produtos esto as margarinas Milla e Delcia, a maionese Mayoneggs, as massas Petybom e a farinha de trigo Sol. A empresa faturou R$ 1,8 bilhes em
1.999, e no momento da realizao das entrevistas contava com 5.300 funcionrios.
Os mdulos implementados
A Santista implementou os mdulos financeiros (contabilidade, contas a pagar, contas a
receber), os mdulos de materiais (compras, recebimento e estoques), manufatura (controle e
planejamento de processos industriais) e vendas e distribuio, do Baan IV.
Na planta de So Paulo, no bairro do Jaguar, esto implementados os mdulos financeiros, o mdulo de manufatura, o mdulo de vendas e distribuio e o mdulo de materiais.
O mdulo de recursos humanos utilizado o do sistema ERP da Oracle, o Oracle Applications, que foi implementado em conjunto com os demais mdulos do Baan IV.
A operao do mdulo de recursos humanos iniciou-se em outubro de 1.998 e dos mdulos financeiros em janeiro de 1.999 e, com a implementao destes, foram centralizadas as
diversas reas de contabilidade, financeiras e departamentos pessoais que havia nas diversas
fbricas da Santista.

143

As operaes dos mdulos de materiais e industrial iniciaram-se respectivamente em

novembro de 1.998 e janeiro de 1.999, apenas na planta do bairro do Jaguar. Esses mdulos
sero implementados de maneira descentralizada nas diversas fbricas. No momento da realizao das entrevistas, os mdulos de materiais j estavam em operao em 9 e o de manufatura em 2 das 20 fbricas onde sero implementados, estando previsto para o final do ano 2.000
o trmino do processo de implementao destes mdulos.
O mdulo de vendas e distribuio deveria ter iniciado sua operao no mesmo perodo,
mas, por problemas de adaptao aos processos da empresa, a entrada em operao sofreu
atraso em relao previso inicial, tendo iniciado sua operao em Abril de 2.000. O sistema
de faturamento da Santista j era centralizado anteriormente. O mdulo de custos est sendo
adaptado pelo fornecedor para que possa atender s necessidades de custeio em processos
contnuos, uma vez que o mdulo disponvel no Baan IV era apenas adequado produo
discreta, e tem sua implementao prevista para o final do ano 2.000.
A rea de TI
A organizao atual da rea de informtica da Santista est relacionada ao processo de
implementao do sistema ERP. Durante a fase principal do projeto de implementao, entre
maro de 1.998 e janeiro de 1.999, foi criada uma hierarquia para o projeto paralela estrutura da rea. Foi definido um diretor do projeto (o diretor financeiro da empresa) e abaixo desse
diretor havia trs gerentes: o gerente de processos, responsvel pelas 5 equipes que estavam
implementando o Baan IV (uma por mdulo), o gerente de infra-estrutura, responsvel pela
preparao do ambiente tecnolgico sobre o qual seria operado o sistema ERP, e gerente de
apoio ao desenvolvimento, que era responsvel por um grupo que iria assumindo o conhecimento a respeito do sistema ERP para dar suporte ao produto aps o trmino do projeto.
Aps o incio da operao dos mdulos financeiros, recursos humanos e manufatura e
industrial na fbrica do Jaguar em janeiro de 1.999, decidiu-se que seria mantida a estrutura
de equipes por mdulos. A rea passou ento a ter duas gerncias, subordinadas ao diretor
financeiro: a gerncia de processos, que manteve sob si a estrutura de 5 equipes, uma por mdulo implementado, e a gerncia de informtica (cuja responsabilidade do gerente de informtica entrevistado) que possui as reas de desenvolvimento de projetos especiais (tais como
o e-business e outros), infra-estrutura (rede e servidores), suporte e telecomunicaes (dados e
telefonia). Existem analistas de sistemas nas duas gerncias, mas os analistas responsveis
pelo sistema ERP esto subordinados gerncia de processos. Note-se que o projeto de im-

144

plementao ainda estava em andamento no momento de realizao das entrevistas, e possvel que essa no seja a estrutura definitiva da equipe. Naquele momento, a equipe de informtica contava com 32 pessoas. Dessas 32, 22 esto no Jaguar e as demais distribudas nas
outras localidades
A Santista utiliza um servidor IBM Risc para o sistema ERP, com sistema operacional
AIX e banco de dados Oracle. utilizado um nico servidor que atende a toda a empresa,
sendo a comunicao de dados com as fbricas feita por meio do servio frame-relay da Embratel que vem apresentando dificuldades em alguns locais. Novecentos usurios estavam
utilizando o sistema, sendo previsto um total de 1.200 usurios at o final da implementao.
Histrico da Deciso e Seleo
Anteriormente ao sistema ERP, a Santista utilizava sistemas desenvolvidos internamente ou por empresas terceirizadas em linguagem Clipper, com servidores Intel e sistema
operacional Netware. Esses sistemas foram desenvolvidos de maneira isolada para atender aos
diversos departamentos, e alguns deles eram administrados de forma descentralizada e mantidos por terceiros. Havia um total de 30 servidores espalhados pelas fbricas e em cada uma
delas havia uma equipe interna de informtica que dava suporte aos usurios e verificava as
necessidades de alterao nos sistemas, repassando-as aos terceiros. Os terceiros faziam as
alteraes solicitadas, de maneira local, e, com isso, sistemas que deveriam ser idnticos nas
diversas fbricas (como por exemplo, o sistema de contabilidade) possuam pequenas diferenas que se tornavam difceis de administrar. Nessa poca as equipes de informtica da Santista
eram compostas por 47 funcionrios e 22 terceiros, totalizando 69 pessoas.
As fbricas tambm possuam departamentos administrativos descentralizados, tais
como contabilidade, contas a receber e contas a pagar. Embora houvesse um desejo de a empresa centralizar esses departamentos, havia a dificuldade da limitao tecnolgica dos sistemas existentes que no comportariam o volume de dados e a necessidade de processamento
resultantes da centralizao. Segundo o gerente de informtica, os sistemas anteriores estavam
apresentando uma fadiga tecnolgica, pois no comportavam o crescente volume de dados e
obrigavam a realizao de constantes reindexaes nos arquivos (uma caracterstica da linguagem Clipper, que no utiliza bancos de dados relacionais e obriga a reconstruo dos ndices quando h problemas no processamento, tais como erros em programas ou quedas de
energia). Outro fator decisivo no processo de deciso era a necessidade de atualizao dos

145

sistemas para que ficassem compatveis com o ano 2.000, o que passou a exercer uma presso
para que se substitussem os sistemas.
Em junho de 1.997, a empresa decidiu ento pela utilizao de um sistema ERP, que
poderia ao mesmo tempo permitir a centralizao da empresa, atualizar a tecnologia pela utilizao de bancos de dados relacionais e tornar compatveis os sistemas da empresa com o ano
2.000. A opo de desenvolvimento interno de um novo sistema foi descartada em decorrncia do prazo imposto pelo problema do ano 2000 e porque a empresa entendia que a utilizao
de sistemas ERP era uma tendncia de mercado, que permitiria a utilizao de best practices
nos processos considerados como padro para todas as empresas (tais como contabilidade,
contas a pagar e contas a receber).
Para a seleo do fornecedor, realizou-se um levantamento dos requerimentos funcionais da empresa que serviu como base para uma pr-seleo dos pacotes disponveis no mercado. Foi contratada uma empresa de consultoria que auxiliou nesse processo, realizado por
meio de entrevistas com os usurios e na definio dos analistas de sistema, que conheciam
bastante os sistemas e os processos de negcio da Santista. Foi levantando o que a empresa
considerava como essencial (isto , funcionalidades que obrigatoriamente deveriam ser disponibilizadas pelos pacotes), e algumas funcionalidades que a empresa gostaria de ter, mas tinham menor importncia para o processo de escolha, recebendo os diversos requisitos diferentes pesos. Foram feitas apresentaes dos diversos pacotes aos usurios que melhor conheciam os processos, e cada um deles dava notas aos requerimentos funcionais.
Considerados apenas os requerimentos, destacaram-se os pacotes da SAP e da Baan. A
escolha final foi definida por meio da negociao com os fornecedores. A Baan foi escolhida
por apresentar menores custos totais e por oferecer menor prazo para implementao. Outro
destaque da Baan foi a aceitao de um contrato com preo fixo, isto , o valor da implementao seria o mesmo independente do cumprimento ou no do prazo estabelecido. Para que
isso fosse possvel, todos os requerimentos funcionais levantados na empresa foram extensivamente detalhados no contrato. Outra imposio da Santista era que o prprio fornecedor do
pacote realizasse a sua implementao, a fim de garantir o completo envolvimento e comprometimento deste com o projeto, e porque todas as funcionalidades prometidas por ocasio da
venda do produto poderiam ser cobradas do fornecedor sem aumento de custo. Caso fosse
contratada uma terceira empresa para a implementao do ERP, qualquer funcionalidade inexistente no produto seria acrescentada atravs de customizaes cobradas.

146

O processo de escolha foi realizado em 3 meses, tempo considerado curto pelo coordenador de sistemas, que explicou a rapidez pelo grande conhecimento que os usurios escolhidos para o processo e analistas de sistema tinham do sistema e das necessidades da empresa (o
coordenador de sistemas est h 11 anos na empresa). A deciso final pelo Baan IV ocorreu
em dezembro de 1.997.
A Santista optou por utilizar o mdulo de recursos humanos do Oracle Applications
porque esse produto tambm contemplava a folha de pagamento, embora essa funo do mdulo seja realizada por um pacote desenvolvido por outro fornecedor, incorporado no mdulo
do Oracle Applications.
A principal preocupao da empresa com a utilizao de um sistema ERP eram as necessidades da rea comercial e da logstica, consideradas bastante complexas (20 fbricas, 3
centros de distribuio, 26.000 clientes, cerca de 1.000 produtos, sendo emitidas 4.000 notas
fiscais diariamente). Essa complexidade exigiu um alto grau de customizao do mdulo comercial. Segundo o gerente de informtica, a principal razo pelo adiamento do incio da operao do mdulo comercial foi justamente essa complexidade e a quantidade de customizaes realizadas. Outra preocupao era a quantidade e diversidade de negcios com caractersticas distintas dentro da empresa. A legislao brasileira tambm era preocupao, uma vez
definido um sistema estrangeiro, porque a Santista produz e vende em praticamente todos os
estados do Brasil, onde existem legislaes locais distintas para os diversos produtos.
Histrico da Implementao
O processo de implementao dos mdulos financeiros e recursos humanos, e dos mdulos de materiais e manufatura na planta do Jaguar iniciou-se em maro de 1.998 e durou
at janeiro de 1.999. Em outubro de 1.998 iniciou-se a operao do mdulo de recursos humanos, em novembro do mesmo ano iniciou-se a operao do mdulo de materiais e em janeiro de 1.999 iniciou-se a operao dos mdulos de manufatura e financeiros.
Como citado, um dos requisitos da Santista na escolha do fornecedor era a restrio de
que este deveria ser o responsvel pela implementao do pacote. Embora o fornecedor tenha
subcontratado alguns consultores para montar a equipe de projeto, a responsabilidade por esses profissionais era do prprio fornecedor. A metodologia utilizada para a implementao foi
a do prprio fornecedor, denominada Target. De acordo com a metodologia Target, denomina-se programa o conjunto de todas as atividades relacionadas implementao do sistema
Baan no cliente. O programa de implantao geralmente dividido em fases e o nmero de

147

fases de cada programa pode variar de uma a cinco fases, dependendo das necessidades do
cliente. No caso da Santista foram estabelecidas trs fases para o programa:

Viso: essa fase se destina construo de um modelo corporativo de negcios. Nessa

fase todas as funes, processos e procedimentos corporativos so levantados, estudados e
redefinidos.

Prova de Conceito: nessa fase se faz a implantao piloto do sistema. Geralmente se escolhe uma parte da empresa para entrar em operao, com um grupo reduzido de funcionalidades do Baan IV. O escopo da implementao piloto depende da estratgia de implantao e do que mais adequado a cada empresa. Em geral, nos programas de implantao, os escopos para esta fase s so firmemente definidos ao final da fase Viso.
Implementao: essa fase consiste na replicao das implantaes piloto para as demais
partes da empresa. Uma vez que uma Prova de Conceito foi bem sucedida, as funcionalidades abrangidas por ela so estendidas para as demais partes da empresa

Para cada mdulo ou grupo de mdulos a ser implementado (materiais, manufatura,

vendas, financeiro, recursos humanos) formou-se uma equipe de implementao sediada no
escritrio da fbrica no Jaguar. As equipes eram compostas por elementos da rea de TI, por
usurios e consultores do fornecedor, e lideradas por um funcionrio da rea de TI e um consultor do fornecedor. Os usurios que participaram das equipes foram escolhidos pela rea de
TI, em conjunto com as reas usurias, com base no conhecimento do negcio e capacidade
de formar opinio junto a seus colegas e ficaram dedicados exclusivamente ao projeto durante
os dez meses de sua durao (de maro de 1.998 a janeiro de 1.999). Segundo o chefe de sistemas, lder da equipe responsvel pela implantao dos mdulos financeiros, alguns usurios
dessas equipes no retornaram suas funes operacionais ao trmino da implementao,
tendo sido aproveitados em reas como auditoria interna ou ficando alocados nas reas usurias como consultores tcnicos dos processos, quando possvel. Responsvel pelas diversas
equipes, estava um gerente de projeto. Alm do gerente de projeto, havia um gerente de recursos humanos que ficou responsvel pelo processo de mudana, por meio da preparao de
treinamentos e educao para a mudana, um gerente responsvel pelo controle de qualidade
do projeto e um gerente de projeto do fornecedor. Os gerentes respondiam a um gerente geral
do projeto, que era o gerente de informtica da Santista. O gerente geral por sua vez respondia
ao diretor do projeto, que era o diretor financeiro da empresa. Ainda em paralelo s gerncias
do projeto, havia um comit formado pelos gerentes das reas usurias. Esse comit se reunia
mensalmente para validar os modelos de processos como definidos pelas equipes do projeto.
Ao longo do ms, os gerentes participavam, dando suporte s equipes de projeto e atendendo
s dvidas destas equipes.

148

O fornecedor disponibilizou modelos de processos que considerava mais adequados a

uma indstria de alimentos, que serviram como base para implementao. Segundo o coordenador de sistemas, para a modelagem do mdulo de manufatura foram selecionados engenheiros de cada uma das reas (margarinas, maioneses, farinhas), a fim de que os modelos do sistema fossem adaptados de maneira adequada, espelhando as necessidades de cada um desse
processos produtivos. Os diferentes processos produtivos esto implementados no mesmo
banco de dados e compartilham os mesmos cadastros (de itens, por exemplo), mas, para o
atendimento das necessidades especficas de cada processo produtivo, foi desenvolvido um
mdulo industrial customizado a partir do mdulo padro.
Segundo o chefe de sistemas, lder dos mdulos de materiais, os mdulos de compras,
recebimento e estoques sero mantidos iguais para todas as fbricas, de maneira que a implementao do sistema ERP servir para padronizar os procedimentos nessas reas (recebimento
de materiais e controle de estoques). Segundo ele, estamos fazendo o contrrio de muitas
empresas que primeiro fazem a reviso de seus processos para depois implementar o ERP;
no nosso caso estamos utilizando o sistema ERP como ferramenta para reviso dos processos. Entretanto, ele salienta que existem algumas diferenas locais que devem ser acomodadas dentro do sistema nico, embora a maior parte delas seja relativa a relatrios especficos
solicitados pelos usurios. Para facilitar o desenvolvimento desses relatrios especficos, a
Santista adotou um gerador de relatrios, o Business Objects.
O incio da operao do sistema ERP na Santista no seguiu exatamente os modelos
apresentados no captulo 3, mas uma combinao deles. A Santista implementou os mdulos
por fases, uma vez que no incio da operao cada um dos mdulos foi sendo implementado
seqencialmente, ms a ms. Entretanto, os mdulos financeiro e de recursos humanos substituram simultaneamente os sistemas de todas as diversas localidades, em um processo de
centralizao dos sistemas e departamentos. No caso dos mdulos de materiais e manufatura,
estes foram implementados apenas na planta do Jaguar (que tem trs fbricas: maionese,
margarina e refinaria de leos vegetais), sendo progressivamente implementados nas demais
fbricas. Com a finalidade de fazer a implementao seguindo esse modelo, foi necessrio o
desenvolvimento de muitas interfaces entre o sistema novo e os anteriores. Segundo o gerente
de informtica, isso no trouxe maiores problemas no caso da Santista, que estava acostumada
ao trabalho de integrao dos diversos sistemas legados.
Quanto execuo em paralelo, ela tambm variou conforme do mdulo. No mdulo de
recursos humanos foi realizado o processamento em paralelo. No caso dos sistemas financei-

149

ros, no foi feito o paralelo, mas os dados de movimentos de meses anteriores no foram convertidos para o novo sistema, em um modelo que o chefe de sistemas (financeiro) chamou de
com esgotamento, isto , enquanto houver movimentos financeiros em aberto nos meses
anteriores, tanto o novo sistema como os antigos so utilizados. No mdulo de manufatura
no houve paralelo, pois no havia sistema anterior. Nos mdulos de materiais, houve paralelo, realizado de uma maneira diferente da apresentada na bibliografia: iniciou-se em um
primeiro momento o novo sistema apenas para uma parte dos materiais comprados (matriasprimas e embalagens) considerados mais estveis, isto , com demanda mais controlada.
Um ms depois, iniciou-se a operao do sistema para os demais materiais e servios adquiridos. Durante o ms em que os dois sistemas foram utilizados em paralelo, os compradores
faziam as requisies nos dois sistemas, dependendo do material adquirido. Dessa maneira,
segundo o chefe de sistemas (materiais), pde-se verificar os principais problemas em operao mas com um volume de dados e transaes menor, durante o ms da operao em paralelo
(essa orientao parece estar associada idia de prova de conceito da metodologia utilizada).
Segundo o gerente de informtica, para todos os mdulos foram definidos planos de contingncia, indicando quais passos deveriam ser realizados caso fosse necessrio o retorno ao
sistema anterior.
Os prazos planejados para a implementao dos mdulos centralizados e para os mdulos iniciais na fbrica do Jaguar foram atingidos, exceo do mdulo de vendas, tambm
centralizado, que teve sua implementao adiada por problemas de adaptao dos processos
da empresa ao sistema, que exigiu ter seu grau de customizao ampliado. Os custos de implementao planejados tambm foram atingidos, pois, embora o prazo e o grau de customizao do mdulo comercial tenham sido revistos, o contrato estabelecido com o fornecedor
determinava um valor fixo.
Implementao: Problemas
Segundo o chefe de sistemas (financeiro), em decorrncia do grande tamanho do projeto
e de sua diviso em cinco frentes, uma para cada mdulo, houve dificuldades em fazer a integrao e parametrizao do sistema. Embora cada equipe estivesse obtendo grande conhecimento dos mdulos sob sua responsabilidade, comeou-se a perceber durante os testes que a
modelagem (parametrizao, cadastros, customizao) estava sendo feita com pouca viso
do todo. Segundo ele, para que o processo do contas a pagar realmente funcione como fim
do processo, necessrio que desde o incio do processo, no recebimento dos materiais, as
parametrizaes financeiras estejam corretas. Aps uma srie de problemas, percebeu-se que

150

seria necessrio rever os processos considerando a integrao e as equipes passaram a ter a

responsabilidade formal de verificar como a modelagem de seu mdulo iria influenciar os
demais. Segundo ele, essa necessidade poderia ter sido enfatizada pelo fornecedor no incio
do projeto, por meio de troca de experincias, facilitando o processo.
O mdulo de vendas e distribuio foi colocado em funcionamento, na modalidade paralelo, no ms de junho de 1.999. Entretanto, segundo o gerente de informtica, ajustes e correes de problemas que normalmente so feitos com o mdulo em funcionamento no puderam ser efetuados nesse mdulo tendo em vista o grande volume de notas fiscais que processadas diariamente na Santista (4.000 notas dia). Assim, o fornecedor entendeu ser melhor fazer as adequaes com o mdulo fora de operao, razo pela qual o paralelo foi encerrado.
Paralelamente a esses fatos, o fornecedor passou por um processo de reestruturao administrativa, o que, de certa forma, tambm colaborou na postergao da entrada em operao desse mdulo. O mdulo entrou em produo em maro de 2.000, sem que houvessem maiores
problemas. A necessidade de adaptao desse mdulo ao grande volume de transaes, fez
com que ele sofresse um maior grau de customizao (cerca de 80%).
Quanto aos problemas de performance do processamento, que ocorreram no incio da
operao, o gerente de informtica comentou que uma das causas para isso pode ser o fato
de os desenvolvedores de sistemas ERP no se preocuparem com a otimizao do uso dos
recursos de informtica. Para eles os recursos so sempre infinitos e, portanto a nica preocupao com o bom funcionamento da lgica do sistema, razo pela qual ele aconselhou a
ter sempre na equipe, alm dos jovens entusiastas, alguns profissionais com senioridade.
Segundo ele, no caso do desenvolvimento interno os analistas so obrigados a se preocuparem
com aspectos tais como performance, retirada de dados histricos de tabelas, segurana de
dados, processos para realizao de estornos, isto , como refazer lanamentos ou operaes
erradas, porque so tambm responsveis pelo suporte posterior ao sistema. Ele tambm salientou que o processo de sizing (determinao do tamanho da mquina) no levou em considerao esses fatores, porque a mquina recomendada pelo fornecedor mostrou ter poder de
processamento inferior ao que se mostrou necessrio. Segundo ele, logo aps o incio da operao foi necessrio expandir a capacidade do servidor.
Segundo o gerente de informtica, houve, no incio, uma certa frustrao dos usurios, uma vez que estes estavam mudando de sistemas que haviam sido desenvolvidos sob medida para cada departamento para um sistema padronizado. Muitos usurios comentaram que
achavam os sistemas anteriores mais amigveis, isto , mais fceis de usar. Entretanto, ha-

151

via uma conscincia bastante forte, e tambm um reforo por parte da diretoria da empresa,
que, embora os usurios individualmente pudessem perder alguma funcionalidade, o ganho do
projeto seria da empresa como um todo, e isso motivou os usurios a se convencerem da importncia do projeto. Disse ele que era um projeto do presidente da empresa e no da informtica e entendia-se que cada um deveria fazer a sua parte para o projeto acontecer. Ao longo do tempo a empresa buscar melhorar o sistema nesse sentido, tornando o mais adaptado
s necessidades dos usurios e aos poucos o sistema ficar melhor que os anteriores. Segundo o chefe de sistemas (materiais), a utilizao da ferramenta de gerao de relatrios
(Business Objects) permitiu que alguns relatrios semelhantes ao do sistema anterior fossem
rapidamente replicados, o que de certa maneira contribuiu para que os usurios se adaptassem
ao novo sistema.
De acordo com o gerente de produo, houve uma grande preocupao por parte da empresa em lidar com o fator humano na implementao. Segundo ele, claro que houve dificuldades de adaptao, principalmente nos primeiros trs meses, mas as dificuldades foram
aos poucos sendo contornadas. Segundo o coordenador de sistemas, a Santista pode ser considerada um modelo em implementao de sistemas ERP relativamente a esse aspecto, uma
vez que o time de projeto contou com um gerente de recursos humanos, responsvel por gerenciar os fatores humanos envolvidos na implementao, tais como a motivao e expectativas dos participantes. Alm de preparar treinamentos e palestras para esclarecimento e apresentao do projeto, o gerente auxiliou no estabelecimento de um plano de prmios e incentivos ligado ao sucesso da implementao. Entretanto, segundo o coordenador de sistemas,
apesar dos cuidados, na prtica difcil gerenciar a mudana, uma vez que est se lidando
com pessoas, e as mudanas na cultura da empresa demoram um pouco para se estabelecer.
Segundo o chefe de sistemas (financeiro), um dos problemas do incio da operao em
fases que a cada nova implementao, seja dos mdulos seguintes, seja dos mdulos anteriores em outras fbricas, surgem problemas em partes do sistema que j estavam estabilizadas. De acordo com ele, a cada nova virada dos mdulos de materiais ou manufatura,
ocorrem alguns problemas nos mdulos financeiros, embora os problemas estejam mais controlados medida que mais fbricas so implementadas. O chefe de sistemas tambm espera
problemas semelhantes quando o mdulo comercial entrar definitivamente em operao.
Segundo o gerente de informtica, o fornecedor prestou o suporte necessrio para que se
resolvessem a maioria dos problemas tcnicos ocorridos na implementao, mas ele percebeu
que no existe uma sistematizao para a troca de conhecimentos a respeito de problemas

152

semelhantes que possam ter ocorrido em outras empresas onde o sistema foi implementado.
Segundo ele, uma possibilidade interessante para o fornecedor seria criar uma equipe do fornecedor que integrasse os resultados das implementaes entre as diversas empresas, permitindo o aproveitamento dos conhecimentos obtidos nos diversos projetos.
Dois custos no esperados pela Santista ocorreram na implementao: o aumento da capacidade do servidor e o custo de algumas poucas customizaes que se perceberam necessrias, mas que no estavam no contrato.
Mudar o Pacote ou a Empresa?
Segundo o gerente de informtica, a orientao da Santista era evitar ao mximo a customizao do pacote, que deveria ficar restrita queles processos que realmente interferissem
nos negcios da empresa. As discrepncias deveriam inicialmente ser resolvidas pela prpria
equipe de implementao, de preferncia por meio da opo de adaptar a empresa ao pacote.
Se houvesse impasse entre os membros do grupo a deciso era passada ao comit de gerentes
usurios. Segundo o coordenador de sistemas, nos mdulos industriais no havia preferncia
quanto a customizar ou no, decidia-se pelo que se acreditava ser o melhor para a empresa.
Segundo ele, o que guiava o processo eram os requerimentos funcionais levantados na etapa
de seleo e definidos no contrato com o fornecedor. Quanto aos mdulos de materiais, o chefe de sistemas (materiais) informou que a idia era seguir ao mximo o novo sistema, porque
a Santista o est utilizando para padronizar os processos da rea nas diversas fbricas. Segundo ele, a implementao de um sistema ERP uma boa hora para voc revisar os seus processos, porque existem certas coisas que voc no consegue mexer na empresa, porque existem resistncias. A implementao de um sistema ERP a chance para mudar.
Apesar da orientao inicial, os entrevistados entendem que o pacote foi bastante customizado, principalmente no mdulo comercial, que inclui vendas e distribuio. O gerente de
informtica estima que esse mdulo foi customizado em 80% de sua funcionalidade. O coordenador de sistemas estima que o mdulo industrial tenha sido customizado em 50% e o chefe
de sistemas (materiais) estima que os mdulos de materiais tenham sido customizados em
20%. No geral, considerando todos os mdulos, a customizao do sistema ERP est estimada em torno de 30% da sua funcionalidade. Na rea de produo, as necessidades de customizao ficaram por conta da adaptao ao sistema para o controle e apontamento de produo
em quilos, ao invs de unidades, exigida pelo processo de fabricao contnuo da Santista.

153

O chefe de sistemas (materiais) relatou que embora a orientao da empresa fosse a de

customizar o mnimo possvel, no momento da implementao sempre h uma srie de presses para que se faam alteraes para tornar o uso do sistema mais simples. Isso acaba levando criao de um backlog (fila de solicitaes de alterao de sistemas) de pequenas
alteraes aps a implementao, tais como a eliminao de campos em telas ou juno de
duas ou mais telas em uma s.
As customizaes eram feitas pelos consultores, atendendo s definies das equipes.
Os programas fontes esto disponibilizados para a Santista, que pretende dar manuteno ao
sistema depois de estabilizado. O gerente de informtica entende que no obrigatrio que a
empresa esteja sempre na ltima verso do sistema ERP, atualizando-o a cada nova verso.
Segundo ele, uma vez que o sistema esteja estabilizado no haver necessidade de atualizaes posteriores, sendo a manuteno feita pela equipe de informtica da Santista. Ele entende
que uma atualizao de verso implica em uma carga de trabalho semelhante de uma nova
implementao.
Utilizao: Benefcios
Segundo o gerente de informtica, a integrao o grande mrito do sistema ERP,
tendo a empresa alcanado por meio da integrao um grande controle e disciplina em suas
operaes. O entrevistado afirma que o sistema ERP disciplina a empresa, pois operaes
que eram realizadas de maneira improvisada passam a ser sistematizadas, e a empresa consegue um grande ganho no que se refere ao controle das atividades.
O gerente de produo tambm aponta a disciplina trazida s operaes como benefcio
do sistema ERP, uma vez que impede os improvisos. Segundo ele, com a utilizao de um
sistema ERP, se no houver bom planejamento [das operaes a serem executadas] no h
bom resultado. Para que uma operao seja realizada no sistema necessrio que o usurio
disponha de todas as informaes necessrias antes da execuo das tarefas, o que impede que
estas informaes sejam inseridas de maneira incorreta para que depois sejam corrigidas. Entretanto, o gerente de produo salienta que a disciplina tambm trouxe algumas dificuldades
relativas flexibilidade. Segundo ele, aps a entrada do sistema ERP, necessrio que a produo informe com antecedncia, no incio do dia, quais lotes de produtos sero produzidos,
para que os demais departamentos estejam alimentados com as informaes necessrias. Isso
imps uma maior necessidade de planejamento rea uma vez que no possvel alterar a
programao de uma linha de produo que j estava estabelecida, o que poderia comprome-

154

ter o planejamento dos demais departamentos. Entretanto, o gerente de produo entende que
a mudana benfica, pois h tanto um melhor controle quanto uma maior produtividade da
rea, j que todos os insumos (matrias primas, horas extras, etc.) devem ser planejados com
antecedncia. O coordenador de sistemas entende que a padronizao de rotinas e procedimentos nas diversas fbricas tambm um grande benefcio do sistema.
Outro benefcio da integrao apontado pelo gerente de produo o fato de as informaes do processo, desde a entrada do material at a venda do produto, estarem disponibilizadas em tempo real para toda a empresa. Dessa maneira, os diversos departamentos podem
trabalhar de modo mais eficiente em seus planejamentos. A rea de vendas, por exemplo, por
estar sincronizada com o departamento de produo, tem informaes mais rpidas a respeito de disponibilidade de produtos, e pode atender melhor ao cliente.
Outro ganho possibilitado pelo novo sistema relativo centralizao das reas de recursos humanos, contabilidade, reas financeiras, compras e informtica. Como citado, cada
uma das fbricas possua sistemas e departamentos descentralizados. Embora j houvesse a
inteno de realizar a centralizao dos departamentos, os sistemas anteriores no o permitiam. Com a centralizao, houve reduo de pessoas nas reas administrativas. Na rea de informtica tambm houve reduo, em decorrncia da centralizao, de 69 para 32 pessoas.
Segundo o coordenador de sistemas, esse benefcio foi obtido no pela utilizao do sistema
ERP, cuja principal caracterstica a integrao, mas pelo fato de que a empresa decidiu utiliz-lo de maneira centralizada, em um nico servidor e um nico banco de dados, uma vez que
o sistema ERP poderia ter sido implementado em uma instalao para cada uma das fbricas.
Quanto importncia do sistema ERP para o processo de centralizao, o chefe de sistemas (financeiro) comentou que a centralizao seria possvel sem o ERP, porm, o processo seria bastante complicado. A respeito da centralizao utilizando-se de um sistema desenvolvido internamente, o gerente de informtica comentou que a centralizao seria at
possvel sem o ERP, mas, seguramente, se o sistema fosse desenvolvido internamente, abrirse-ia mo da centralizao total por solicitaes das reas, como, por exemplo, a possibilidade de recepo de materiais sem o pedido correspondente ou a compra, em situaes de
emergncia, sem que se passe pelo processo de requisio, etc., etc. Essas aberturas seriam
feitas em nome do bom andamento dos negcios, mas com perda de controle.
Outra possibilidade relacionada centralizao e padronizao trazida pelo sistema,
apontada pelo coordenador de sistemas, a de a empresa transferir pessoas de uma fbrica
para outra sem que haja a necessidade de retreinamento. Uma das dificuldades para a execu-

155

o da centralizao foi assegurar o funcionamento dos equipamento e da rede, pois, a partir

do instante em que o processamento foi centralizado em um nico servidor, a desativao
desse servidor poderia paralisar toda a empresa.
Segundo o gerente de informtica, o sistema tambm melhorou a qualidade da informao disponvel. Na situao anterior, os dados vinham dos diversos sistemas localizados nas
diversas fbricas e para a obteno de informaes consolidadas era necessrio agreg-las em
um processo lento e sujeito a erros. Alm disso, um mesmo dado (por exemplo, o faturamento
de janeiro) poderia apresentar diferenas quanto extrado de cada um dos diferentes sistemas
(contabilidade, faturamento, contas a receber, estoques). Segundo o gerente, isso ocorria porque muitas vezes os conceitos empregados para a apurao desses nmeros em cada um dos
sistemas era diferente (por exemplo, se o faturamento inclua devolues de mercadoria ou
no). O sistema ERP permitiu a padronizao dos conceitos e a eliminao dessas diferenas.
O chefe de sistemas (financeiro) apontou a integridade e a agilidade de atualizao da
informao, a quebra de feudos de informao e a transparncia como benefcios trazidos
pelo fato de a informao ser nica e estar disponvel a todos os usurios que a ela tiverem
acesso ou necessidade.
Integrao do Sistema ERP s Mquinas de Produo
Um benefcio obtido pelo sistema apontado pelos entrevistados a padronizao das
frmulas dos produtos em todas as fbricas da empresa. A Santista integrou o sistema ERP ao
sistema que controla suas mquinas de produo de maneira que, quando um lote de produo
for liberado para fabricao no Baan IV (isto , quando determinada quantidade de determinado produto requisitado produo), a informao passada diretamente s mquinas que
iro produzi-los. As mquinas de produo utilizam-se das frmulas (receitas) cadastrada no
Baan IV para retirar de maneira automtica as quantidades necessrias de cada um dos ingredientes (por meio de vlvulas e reservatrios ligados a essas mquinas). Durante o processo, o
estoque de matrias primas do sistema ERP atualizado de maneira on-line, bem como as
quantidades produzidas. Essa integrao foi uma customizao do Baan IV feita internamente
pela informtica da Santista, integrando-o ao sistema que controla as mquinas de produo.
Alm da eliminao de desperdcios e de problemas de erros de quantidade nas misturas
obtidos nas fbricas onde j est implementado, o sistema permitir Santista padronizar a
frmula de seus produtos em todas as fbricas do Brasil. Atualmente, no h como garantir
que as frmulas utilizadas nas fbricas estejam de acordo com o definido pelo departamento

156

de qualidade, centralizado no Jaguar. Quando h mudanas nas frmulas, estas so enviadas

s diversas fabricas por meio de comunicaes internas aos departamentos de produo, mas
no h como garantir que estejam realmente sendo usadas da maneira adequada. Segundo o
gerente de produo, o ganho neste aspecto ser muito grande, permitindo uma melhoria no
controle da qualidade dos produtos e na satisfao do consumidor.
Segundo o gerente de produo, a idia de conexo do sistema de controle das mquinas
de produo ao sistema ERP surgiu durante a implementao. Segundo ele, essa ligao permitiu que todas as informaes do processo de fabricao estivessem sempre atualizadas e
corretas no sistema, j que para que possa haver produo os recebimentos de matriaprima so obrigatoriamente apontados, os produtos so feitos de acordo com uma receita
determinada, sem possibilidade de erros nas informaes e na utilizao das matrias primas, pois as quantidades so alimentadas automaticamente. Ao final do processo, as quantidades consumidas e produzidas j esto apontadas no sistema, apenas exigindo a liberao
do controle de qualidade. Aps essa aprovao, o lote j consta do estoque de produtos acabados.
Alm da integrao com as mquinas, foi tambm desenvolvido um mdulo-satlite
para confeco de etiquetas de cdigo de barras e posterior leitura para fazer o apontamento
da produo no momento em que o produto transferido da produo para o armazm de distribuio, eliminando a necessidade de apontamento manual, que era dificultada pela velocidade do processo na Santista.
Utilizao: Problemas e Dificuldades
Segundo o coordenador, uma das dificuldades na utilizao de um sistema ERP a sua
complexidade. Segundo ele, muitas vezes difcil explicar para os usurios, como por exemplo um apontador de produo, porque ele precisa fazer sua tarefa em uma determinada hora,
de uma determinada maneira. Para que o sistema ERP possa operar de maneira correta, necessrio que uma srie de operaes sejam coordenadas e executadas nos momentos corretos,
tais como a colocao de pedidos de venda, cadastro de previses de vendas, pedidos de compras, liberao de ordens de produo e outros. Segundo o coordenador, se algum usurio
entrar com alguma informao errada no sistema, ou no momento errado, sero produzidas
quantidades inadequadas, podendo sobrar produto ou faltar material para a fabricao.
Outra dificuldade citada pelo coordenador de sistemas est relacionada s mudanas nas
tarefas dos analistas da rea de informtica. Segundo ele, se havia algum problema ou nova

157

necessidade em um sistema na situao anterior, bastava discutir com os usurios do departamento que aquele sistema atendia, decidir qual seria a alterao e implement-la. J com o
sistema ERP, o coordenador entende que isso no mais possvel, pois uma alterao em um
mdulo pode trazer impactos em outros mdulos. Segundo ele, cada alterao no sistema tem
que ser pensada considerando-se o conjunto de todos os mdulos, o que as torna mais demoradas e complexas, uma vez que envolvido um maior nmero de pessoas.
Segundo o gerente de informtica, no ocorreram problemas graves quanto localizao. Entretanto, a Santista utilizou uma srie de pacotes adicionais para tarefas como emisso
de livros fiscais, controle de tesouraria, controle de patrimnio, controle de financiamentos e
controle de importaes. Esses pacotes foram adquiridos durante o projeto de implementao
do Baan IV, foram escolhidos pela Santista e a responsabilidade pela integrao entre os pacotes e o sistema ERP ficou a cargo dos fornecedores desses pacotes. Quanto comunicao
com bancos por meio de arquivos enviados via EDI, foi desenvolvida uma customizao pela
Santista. Segundo o chefe de sistemas (materiais) uma das dificuldades da localizao a necessidade de constantes modificaes, uma vez que a legislao est sempre se modificando.
Segundo ele, o Baan IV ainda apresenta algumas dificuldades no mdulo de materiais, relacionadas ao recolhimento de impostos tais como o Funrural, o ISS e a reteno de INSS para
prestadores de servios que no estavam contempladas no sistema ERP padro. Essas customizaes esto sendo feitas pela prprio fornecedor, que as incorporar ao pacote padro do
Brasil.
De acordo com o coordenador de sistemas, uma das desvantagens da utilizao de pacotes o fato de que alguns processos so muito genricos e impem certa ordem de tarefas.
Para ele, o sistema ERP tenta ser o mais genrico possvel e acaba no atendendo a ningum. Em empresas, possvel pela experincia e conhecimento dos processos mudar ordem
de tarefas ou eliminar etapas intermedirias. Mas quando se implementa um sistema ERP,
muitas vezes a empresa deve adaptar-se maneira como as tarefas so executadas nesse sistema, uma vez que customiz-lo traria custos. Entretanto, o coordenador de sistemas reconhece que alguns processos da empresa foram melhorados, utilizando-se a maneira de o pacote
realizar as tarefas. Segundo o chefe de sistemas (financeiro), o ERP dificulta certos processos
pelo nmero excessivo de telas e de campos desnecessrios que devem ser preenchidos. Em
alguns departamentos, como no caso do contas a pagar, no incio da operao foi necessrio
aumentar o nmero de funcionrios para dar conta das tarefas, uma vez que a dificuldade em
execut-las foi maior. Segundo o gerente de informtica, muitas das solicitaes dos usurios

158

nesse sentido fazem parte do backlog, e sero atendidas aps o trmino da implementao dos
sistemas.
Para o chefe de sistemas (financeiro), as necessidades de extrao de informaes gerenciais no so plenamente atendidas pelos relatrios e consultas do sistema ERP, e a Santista est adotando um software extrator de relatrios (o Business Objects). Esse software exige que os usurios conheam bem os princpios de extrao de relatrios, e atualmente o
departamento de informtica que desenvolve os relatrios, embora o plano seja passar aos
usurios esse procedimento. Segundo o entrevistado, os relatrios obtidos pelo Business Objects atendem mais s necessidades de relatrios operacionais, e a Santista desenvolveu internamente um sistema EIS utilizando ferramentas da Oracle para atender a necessidades de informaes gerenciais.
Segundo o coordenador de sistemas, h a exigncia de aumento de qualificao profissional dos usurios do sistema com a implementao de um sistema ERP, pois ERP sinnimo de controle e os profissionais tm que estar adequados a essa nova cultura. Outro motivo porque o sistema ERP, como qualquer sistema que no feito sob medida, permite
que o usurio cometa erros. Dessa maneira, o usurio tem que ser bem qualificado para que
se minimize esse problema. Segundo ele, num sistema desenvolvido internamente, possvel
criar controles na entrada de dados para evitar esses problemas, mas em um sistema ERP,
onde esses controles precisariam ser implementados por meio de customizaes, no possvel gastar dinheiro para fazer esses controles.
Integrao
Como citado, a integrao entre os mdulos foi citada espontaneamente como vantagem
do sistema ERP. Entretanto, o principal aspecto ressaltado pelos entrevistados foi a centralizao do sistema e reas administrativas na fbrica do Jaguar.
ERP e desempenho / competitividade
Os entrevistados afirmaram que o sistema ERP trouxe ganhos de desempenho e competitividade na empresa, uma vez, que alm da integrao do sistema com as mquinas de produo, que permitir a homogeneizao dos produtos em todo o Brasil, a empresa ganhou
com a reduo de custos decorrente da centralizao dos departamentos. Segundo os entrevistados, com o sistema ERP possvel pela primeira vez gerenciar a empresa como um
todo e no como um conjunto de fbricas independentes, buscando-se e obtendo-se sinergias.

159

Para o gerente de informtica, o ganho no em decorrncia do fato de a empresa utilizar

um sistema ERP, mas do fato de ele ser processado de maneira centralizada, o que tambm
poderia ser feito com sistemas desenvolvidos internamente.
O gerente de informtica entende que atualmente a simples utilizao de um sistema
ERP no pode mais ser considerada como uma vantagem competitiva em si, pois a maioria
das grandes empresas j utiliza essa soluo. Dessa maneira, poderia se dizer que a utilizao
de um sistema ERP estaria mais como uma necessidade para a empresa permanecer no mercado do que como vantagem competitiva. Segundo o gerente, [os vendedores] at dizem que
hoje no faz mais sentido fazer anlise de viabilidade econmica para um projeto de ERP,
pois isso seria como se fazer um estudo de viabilidade para verificar se sua empresa deve ou
no utilizar telefones.
Integrao com outros sistemas
A Santista utiliza alm do ERP uma srie de pacotes-satlite, integrados por meio de
trocas de arquivos. Entre eles esto os pacotes de controle de importao (Bergen), livros fiscais (da Procwork), controle de tesouraria (Sincron), controle de patrimnio (da Sispro) e
controle de financiamentos. O mdulo de recursos humanos da Oracle e tambm integrado
por meio de trocas de arquivos-texto.
O sistema ERP ser integrado a um sistema de vendas em palmtops e a um sistema que
coletar pedidos feitos pela Internet (e-commerce). Como citado, o sistema ERP foi integrado
ao sistema de controle de mquinas de produo e foi desenvolvido um mdulo-satlite
para apontamento da produo por leitura de cdigo de barras. A Santista no considera a
manuteno das interfaces como problemtica.
Outros Comentrios dos Entrevistados
Sobre sistemas ERP: os modelos de processo dos sistemas ERP so timos para trabalhos acadmicos, mas a prtica traz diversas restries que devem ser consideradas. Se
voc fatura dez notas por dia, o sistema timo, perfeito. Mas se voc fatura 4.000 existem
dificuldades de performance e operao que devem ser consideradas.
Sobre o sistema nico para a empresa: o grande desafio voc conseguir modelar todas as diferentes reas de negcios e fbricas dentro de um nico sistema

160

Consideraes sobre o Caso

Pontos de Destaque
No caso da Santista, destacaram-se os ganhos obtidos com a centralizao da administrao e a padronizao das informaes e processos em uma empresa geograficamente dispersa (23 localidades espalhadas pelo Brasil). O sistema permitiu uma melhora sensvel na
qualidade da informao e pela primeira vez a empresa pode facilmente obter a informao
consolidada de suas atividades. Alm disso, a padronizao das atividades e procedimentos
em uma empresa que tem grande abrangncia geogrfica permite o controle distncia e a
garantia de que as diferentes fbricas esto sendo operadas de acordo com o direcionamento
central.
Outro grande destaque, este tecnolgico, foi a padronizao das receitas dos produtos
em todo o Brasil por meio da integrao do sistema ERP aos sistemas de controle das mquinas de produo. Isso permitiu Santista a garantia da homogeneidade da qualidade de seus
produtos em todo o Brasil. Alm disso, percebeu-se que por meio dessa interligao o prprio
processo fsico de produo passou a fazer parte do processo controlado pelo sistema ERP.
Isso, como observado nos casos j apresentados, trouxe um grande aumento na qualidade das
informaes disponveis sobre o processo, uma vez que todas as atividades que fazem parte
dos processos em um sistema integrados terminam por ser obrigadas a disponibilizar suas
informaes de maneira correta e no momento adequado.
Quanto ao processo de implementao, a Santista utilizou-se de uma combinao dos
modelos propostos na bibliografia, uma vez que a situao anterior dos sistemas era extremamente fragmentada (diversos sistemas isolados, diferentes em cada uma das localidades) e
havia a dificuldade das distncias geogrficas envolvidas e a grande quantidade de fbricas.
Segundo o chefe de sistemas (financeiro), a realizao da implementao por meio de bigbang no seria possvel na Santista. A empresa tambm utilizou-se de uma equipe de projeto
considerada grande pelo prprio fornecedor, uma vez que essas caractersticas assim o exigiram. Embora a estratgia de implementao escolhida tenha obrigado a empresa a desenvolver uma grande quantidade de interfaces, isso no foi considerado como problema pela empresa, uma vez que essa era uma realidade na situao anterior. Segundo o gerente de informtica, o fato de a Santista estar acostumada com a interligao de uma srie de sistemas facilitou o processo. A Santista tambm utilizou variaes do processamento em paralelo para
diminuir os riscos nos mdulos de recursos humanos, financeiro e materiais. Assim como na

161

Bosch, a complexidade da empresa refletiu-se em uma maior complexidade do plano de implementao e maior necessidade de lidar com os aspectos relacionados aos riscos de implementao.
No que se refere negociao com o fornecedor, destacou-se o fato de a Santista ter
estabelecido um contrato com o valor fixo, independentemente do tempo gasto para a implementao. Isso trouxe uma garantia a empresa quanto ao cumprimento dos custos planejados,
deixando com o fornecedor a presso para a entrega das funcionalidades contratadas.
Um destaque bastante singular, verificado apenas no caso da Santista, a deciso de no
de atualizar o sistema com as novas verses do fornecedor uma vez que este esteja estabilizado. Dessa maneira, a Santista pretende evitar os problemas e custos associados atualizao
de verses e a necessidade de redesenvolvimento de customizaes. Entretanto, ser necessrio manter uma equipe de informtica que possa acomodar as necessidades de manuteno do
sistema.
Principais Aspectos Presentes no Modelo Inicial
Como apresentado no modelo do ciclo de vida de sistemas ERP, verificou-se que um
dos aspectos mais importantes da etapa de implementao garantir a comunicao entre as
equipes que fazem a adaptao de cada um dos mdulos. No caso da Santista, percebeu-se
que a ausncia dessa comunicao estava fazendo com que os mdulos fossem inadequadamente parametrizados, e definiu-se um procedimento formal para troca de informaes entre
as equipes.
Tambm verificou-se que a caracterstica de banco de dados corporativo permitiu a padronizao de conceitos entre os diversos sistemas (contabilidade, estoques, vendas), eliminando diferenas entre eles. necessrio ressaltar que esse benefcio s pde ter sido percebido pelo fato de os sistemas anteriores apresentarem alto grau de discrepncias entre suas informaes.
Na Santista pde-se observar a utilizao do sistema ERP para a reviso e padronizao
de processos na rea de materiais.
Novos Aspectos que Podem Ser Incorporados ao Modelo Inicial
A utilizao de uma ferramenta para gerao de relatrios (tanto operacionais como gerenciais) mostrou-se interessante para permitir que os usurios se adaptassem mais rapidamente ao sistema. Segundo o chefe de sistemas (materiais), o maior impacto da mudana de

162

sistema nos mdulos em que participou foi justamente a mudana nos relatrios. Utilizandose da ferramenta, foi possvel refazer rapidamente relatrios semelhantes aos que existiam no
sistema anterior.
Percebeu-se no caso que o fato de os sistemas ERP serem elaborados com base em modelos de processos pode fazer com que, embora conceitualmente corretos, no levem em considerao aspectos prticos tais como volume de processamento, possibilidade de erros por
parte dos usurios e mesmo limites de armazenamento e processamento de informao dos
equipamentos em produo.
Assim como nos casos da Rhodia Poliamida e CNT/VMM, percebeu-se que, durante a
implementao, h presses por parte dos usurios para que se faam alteraes relativas
facilidade de operao, tais como a reduo do nmero de telas ou eliminao de campos.
Mesmo que sejam postergadas, essas solicitaes tornam-se um backlog que invariavelmente
termina por ser atendido, e, medida isso acontece, o sistema ERP vai se distanciando do
modelo padro do fornecedor.
Outra contribuio interessante do caso para o modelo do ciclo de vida de sistemas ERP
a verificao de que, em uma implementao por fases, os novos mdulos que esto sendo
implementados podem trazer problemas nos mdulos anteriores, mesmo que estabilizados. O
modelo original indica apenas que os mdulos j implementados podem exercer influncia
sobre os prximos mdulos, e no o contrrio.
Novamente, como nos casos anteriores, percebeu-se que tanto os benefcios como dificuldades trazidos pelo novo sistema esto bastante relacionados s caractersticas dos sistemas
anteriores. No caso da Santista, o fato de os sistemas anteriores terem sido desenvolvidos sob
medida refletiu-se em crticas quanto dificuldade em operar o novo sistema.
Alm disso, neste caso pde-se perceber mais uma maneira pela qual a integrao do
sistema ERP traz mudanas nas atividades das reas. Em decorrncia da integrao, as informaes a respeito das atividades (por exemplo, a produo de determinadas quantidades de
determinados produtos) devem ser inseridas previamente sua execuo, e, uma vez inseridas, tornam-se disponveis a todos os demais departamentos, que as utilizam para o seu prprio planejamento. Isso impede, ou dificulta, mudanas repentinas no que havia sido planejado, uma vez que isso poderia refletir negativamente sobre o planejamento de outras reas.
Assim, o sistema ERP obriga o planejamento prvio das atividades das reas e dificulta
mudanas no planejadas, o que leva a uma maior coordenao entre as atividades das reas.

163

Contrastes com o Modelo Inicial

Uma opinio interessante emitida pelo gerente de informtica questiona o fato de o fornecedor no aproveitar de experincias de outras implementaes para evitar problemas de
performance. Isso aparentemente contrrio a uma das vantagens dos sistemas ERP apregoadas pelos fornecedores, justamente a possibilidade de aproveitamento de experincias anteriores.

164

6.5 CASO AGROLARANJA (nome fictcio)

Empresa: AgroLaranja
Sistema ERP utilizado: Logix, verso 3.0
Entrevistas realizadas em Agosto de 1.999
Entrevistados: O gerente de Informtica e R.H., o Coordenador de Sistemas e o Gerente de
Suprimentos

Principais Caractersticas do Caso

O caso da AgroLaranja oferece uma perspectiva da implementao de um pacote nacional em um grupo de 80 empresas, muitas com negcios bastante distintos, com o objetivo de
unificar os diversos sistemas existentes e reduzir os custos administrativos (contabilidade,
financeiro, recursos humanos, compras e informtica). Tambm mostra como o sistema ERP
serviu de base para o desenvolvimento de uma srie de sistemas adicionais, com a finalidade
de atender a pontos especficos da operao e obter melhorias no desempenho da empresa.
Apresentao da Empresa, Mercado e Principais Produtos
A AgroLaranja uma empresa produtora de sucos concentrados de laranja e derivados,
pertencente a um grupo de empresas de capital nacional que possui diversos negcios nas
reas agropecuria (fazendas de laranja, ma e gado), de servios porturios (navegao,
terminais porturios, manuteno de plataformas martimas, desembarao alfandegrio, entre
outros), alm de empresa distribuidora de ttulos e valores mobilirios, serraria, reflorestadora
e uma empresa que fabrica a base para bebidas como sucos e refrigerantes. So 80 empresas,
das quais a AgroLaranja a maior em faturamento. O grupo como um todo fatura cerca de
US$ 800 milhes anualmente, e a AgroLaranja fatura US$ 400 milhes. O grupo como um
todo conta com 8.000 funcionrios, e a AgroLaranja com 750.
A AgroLaranja produz suco concentrado e congelado de laranja e subprodutos, sendo a
produo de suco de laranja praticamente toda exportada (cerca de 99% da produo). A empresa produz em mdia 400.000 toneladas de suco de laranja concentrado por ano. Os clientes
da AgroLaranja so empresas que envasam o suco de laranja para o consumidor final, e esto
nos Estados Unidos (70%), Europa (20%) e sia (10%). A AgroLaranja tambm comercializa
subprodutos da laranja: leo destilado, lcool ctrico, essncia para cosmticos (a partir da
casca) e rao bovina (bagao da laranja).

165

A AgroLaranja possui duas fbricas no interior de So Paulo. Alm disso, a empresa

possui um entreposto exportador em Santos-SP e escritrios nos Estados Unidos, Europa e
Japo, onde possui tambm portos prprios para descarregamento e armazenagem do suco de
laranja. O grupo tambm possui uma unidade fabril nos Estados Unidos. A laranja para a produo dos sucos adquirida de suas prprias fazendas e de cerca de 5.000 produtores rurais
independentes.
A rea de TI e Dados Tcnicos
A rea de TI da AgroLaranja contava no momento da realizao das entrevistas com 9
pessoas, divididas em 3 analistas de negcios, um administrador de banco de dados (DBA),
um funcionrio para suporte rede e telecomunicaes, um funcionrio para o suporte e desenvolvimento do sistema EIS, um funcionrio para suporte ao Unix, o coordenador de sistemas e o gerente de informtica (que acumula a funo de gerente de recursos humanos). Alm
desses, existem 3 funcionrios terceirizados que fazem manuteno em microcomputadores.
Os analistas de negcio tm a funo de fazer a ligao entre o fornecedor do pacote e
os usurios. Quando h solicitaes de alteraes no pacote ou necessidade de informaes a
respeito do funcionamento do sistema ou correo de problemas, estes analistas centralizam
as solicitaes e as negociam com o fornecedor. Esses analistas so tambm responsveis pelo
teste e instalao das alteraes e correes em programas enviados pelo fornecedor. Os analistas esto divididos por mdulos, sendo um especializado no atendimento aos mdulos financeiro e suprimentos, um especializado nos mdulos comercial (faturamento e logstica) e
manufatura, e um no mdulo citrcola, um mdulo-satlite desenvolvido para gerenciamento das safras, que ser descrito mais adiante. Quando a AgroLaranja precisa de mo-deobra para desenvolvimento de mdulos-satlite, so utilizados programadores, contratados
do fornecedor do sistema ERP ou outras empresas pela durao do projeto.
A rea de TI da AgroLaranja atende a todas as empresas do grupo, que de maneira geral
no possuem pessoal prprio de informtica, exceo de quatro empresas centralizadoras (a
empresa que centraliza as fazendas de ma, a empresa que centraliza as fazendas de laranja,
a empresa que centraliza as atividades porturias e a empresa que centraliza as atividades de
manuteno de plataformas martimas) que tm um ou dois funcionrios prestando suporte
direto aos usurios dessas empresas e de suas controladas. So 9 pessoas no total, subordinadas hierarquicamente s empresas onde trabalham e funcionalmente ao gerente de informtica
da AgroLaranja.

166

Anteriormente ao sistema ERP, a AgroLaranja possua uma srie de sistemas departamentais desenvolvidos em Oracle Forms, Clipper ou Access. Os sistemas em Oracle foram
desenvolvidos em 1.993 com a finalidade de substituir os sistemas anteriores que haviam sido
desenvolvidos em COBOL e rodavam em mainframe Bull. As demais empresas do grupo
tambm possuam uma srie de sistemas, desenvolvidos em uma variedade de plataformas e
linguagens. O Logix executado em um servidor HP (Hewlett-Packard), em sistema operacional HP-UX (prprio da HP, baseado em Unix) e banco de dados Informix. O servidor est
localizado na fbrica que abriga o escritrio central e atende a todas as empresas do grupo de
maneira centralizada. A AgroLaranja possui um outro servidor idntico, utilizado para testes e
como servidor backup para o caso de falhas do servidor principal.
A comunicao com as fbricas, empresas, escritrios feita por meio de servio de
rede de longa distncia fornecido pela Embratel (TopNet). As fazendas e empresas mais distantes esto conectadas por satlites, em servio fornecido pela Comsat. O grupo tem 400
usurios e 400 microcomputadores distribudos entre as diversas empresas. Na AgroLaranja,
so 250 usurios e 250 microcomputadores e terminais acessando o Logix. A rea de informtica est subordinada ao vice-presidente da AgroLaranja, que tambm vice-presidente do
grupo.
Os Mdulos Implementados
A AgroLaranja implementou os mdulos de pedidos e faturamento, crdito e cobrana,
suprimentos (que inclui compras, controle de estoques, recebimento e planejamento de materiais), contabilidade, contas a pagar, tesouraria, recursos humanos, ativo fixo e exportao. Os
mdulos da rea financeira, compras, contabilidade e recursos humanos atendem de maneira
centralizada a todas as empresas do grupo. Embora cada empresa possua sua equipe administrativa, essas equipes utilizam o mesmo sistema centralizado, seguindo os conceitos determinados pela administrao da AgroLaranja.
O mdulo de manufatura foi implementado apenas na AgroLaranja e est com implementao prevista para o ano 2.000 em algumas das outras empresas. O mdulo de custos
tambm tem implementao prevista para o ano 2.000, em todas as empresas. O mdulo comercial (gesto de vendas) tambm ser implementado em 2.000 em algumas das empresas
do grupo. No caso da AgroLaranja, especificamente, esse mdulo no ser utilizado, pois toda
a produo exportada e esse controle feito no mdulo de exportao.

167

O processo de implementao da maioria dos mdulos foi iniciado em abril de 1.997 e

os mdulos foram sendo implementados em fases at dezembro de 1.997. A tabela 2 resume
as etapas de implementao na AgroLaranja. medida que cada mdulo do Logix era implementado na AgroLaranja, as outras empresas eram agregadas ao sistema ERP. exceo
do mdulo de RH, que teve sua ordem de implementao alterada por fatores contingenciais,
descritos a seguir, todos os outros foram implementados inicialmente na AgroLaranja. Alm
dos mdulos de manufatura e custos citados, alguns dos outros mdulos ainda estavam em
implementao nas demais empresas do grupo, no momento da realizao das entrevistas.

Mdulo
R.H.
Contas a Pagar
Suprimentos
Exportao
Contas a Receber
Contabilidade
Citrcola (*)
Sistema de controle
industrial (*)
Manufatura

Incio da Implementao
Abril/1.997
Junho/1.997
Junho/1.997
Setembro/1.997
Agosto/1.997
Maio/1.997
Abril/1.998
Abril/1.998

Incio da Operao
Junho/1.997
Julho/1.997
Agosto/1.997
Dezembro/1.997
Dezembro/1.997
Dezembro/1.997
Agosto/1.998
Junho/1.998

Junho/1.999

Agosto/1.999

(*) O mdulo citrcola e o sistema de controle industrial foram desenvolvidos como complementos ao Logix, e so especficos para a AgroLaranja

Tabela 2 Etapas da Implementao do sistema ERP na AgroLaranja

Histrico da Deciso e Seleo
Em 1.996, enquanto o grupo passava por um processo de reestruturao de seus negcios, foi contratado um novo vice-presidente para a AgroLaranja. Na empresa onde trabalhava
anteriormente, o vice-presidente da AgroLaranja havia participado de um processo de substituio de sistemas onde a deciso por utilizar um sistema ERP foi muito bem sucedida. Nessa
outra empresa inicialmente tentou-se fazer o desenvolvimento completo de um novo sistema
utilizando-se de uma empresa terceirizada, mas o projeto no chegou ao fim. Para solucionar
o problema decidiu-se implementar um sistema ERP, o que resultou em sucesso.
Ao chegar AgroLaranja, o vice-presidente verificou que os sistemas atuais possuam
algumas caractersticas que apontavam para a sua substituio. A AgroLaranja necessitava de
um sistema que substitusse toda uma srie de sistemas departamentais isolados, desenvolvidos em Oracle, Clipper e Visual Basic com o objetivo principal de reduo de custos de informtica e a eliminao de erros e diferenas entre os dados nos diversos sistemas. Tambm

168

era inteno do vice-presidente da AgroLaranja que todas as empresas do grupo utilizassem o

mesmo sistema, eliminando-se a redundncia de esforos nas diversas empresas do grupo,
buscando-se ganhos pela padronizao das atividades administrativas (contabilidade, financeiro, recursos humanos, compras e informtica). Alm disso, havia o problema da necessidade
de reviso dos sistemas para o ano 2.000 e o fornecedor da linguagem em que estavam feitos
os principais sistemas (Oracle) iria deixar de oferecer manuteno linguagem utilizada
(FORMS 3), o que iria obrigar a AgroLaranja a reescrever os programas na nova verso da
linguagem do fornecedor (FORMS 4).
O gerente de informtica foi, ento, contratado pelo vice-presidente da empresa, assumindo a rea em janeiro de 1.997, com a misso de selecionar e implementar um sistema
ERP. Nesse momento, foi feito um estudo de custo versus benefcio e concluiu-se que o redesenvolvimento completo do sistema na nova verso da linguagem (FORMS 4) seria muito
oneroso, tanto em termos da necessidade de retreinamento da equipe como o custo da manuteno de uma equipe de informtica para dar continuidade ao sistema desenvolvido, decidindo-se, ento, pela utilizao de um pacote integrado de mercado. Alm disso, a experincia
anterior do vice-presidente com a utilizao de sistemas ERP tambm favoreceu a deciso.
Os sistemas ERP disponveis no mercado foram pr-selecionados com base na disponibilidade de mdulos para atender a todas as reas da empresa e com base em um critrio tcnico: a possibilidade de utilizao do banco de dados Informix, empresa com o qual o gerente
de informtica possua facilidades para a negociao. Os finalistas foram apresentados aos
usurios e, por fim, decidiu-se pelo Logix como tendo a melhor relao custo versus benefcio. O Logix tambm era o nico que possua um mdulo prprio de exportao integrado aos
mdulos de faturamento, financeiro e contabilidade. Como a AgroLaranja exporta 99% de sua
produo, esse foi considerado um fator importante. Alm disso, segundo o gerente de informtica, a negociao e execuo das customizaes necessrias seriam mais simples e mais
baratas no Logix, pois a empresa concordava em incorporar as principais mudanas desejadas
pela empresa no sistema. J as outras empresas, embora realizassem as customizaes, as fariam em mdulos-satlite desenvolvidos especificamente para a AgroLaranja, deixando a
responsabilidade pela manuteno posterior com a empresa. Segundo o gerente de informtica, deve-se partir do que a empresa quer [em relao aos servios] para depois escolher o
fornecedor. preciso se preocupar menos com a funcionalidade e mais com o servio e a
viso de futuro do fornecedor. A informtica no um fim em si, mas uma rea de apoio. No
se pode escolher um sistema ERP somente pelo aspecto tecnolgico.

169

O mdulo de RH do Logix tambm prprio, o que lhe conferiu uma maior abrangncia funcional em relao ao seus concorrentes neste processo de deciso. Segundo o coordenador de sistemas, quanto mais mdulos estiverem contemplados por um nico sistema, menor a necessidade de acareao, isto , colocar os diversos fornecedores em contato para a
resoluo de problemas.
Histrico da Implementao
O processo de implementao do sistema ERP iniciou-se em abril de 1.997 com a apresentao detalhada do sistema escolhido aos principais usurios, sendo ento estabelecido um
cronograma para a implementao dos diversos mdulos, em fases. A idia inicial era implementar cada um dos mdulos na AgroLaranja, e posteriormente nas demais empresas do grupo. No foi utilizada a metodologia proposta pelo fornecedor e para o gerenciamento e controle da implementao foram utilizados apenas recursos internos.
Para cada um dos mdulos da (recursos humanos, contas a pagar, suprimentos, contas a
receber, exportao e contabilidade) foi estabelecida uma equipe de implementao, com a
conduo de um analista da rea de informtica e um consultor do fornecedor do pacote que
conhecesse aquele determinado mdulo, alm de um usurio, gerente ou supervisor da rea
onde o mdulo estivesse sendo implementado. A responsabilidade pela conduo do projeto
como um todo ficou atribuda ao gerente de informtica e ao coordenador de sistemas. Em
cada um dos mdulos a equipe verificava como seria realizada a adaptao por meio de parametrizaes ou quais seriam as customizaes necessrias. Os usurios das equipes participaram do projeto das modificaes e dos testes, mas no se dedicaram de maneira integral ao
projeto. De maneira geral, a equipe de informtica os consultava e envolvia-os nos testes
quando julgava necessrio. Os usurios operacionais participaram nas fases finais do processo
de implementao, no momento da converso dos dados e cadastros das tabelas. O treinamento aos usurios operacionais foi ministrado pelo fornecedor. Segundo o coordenador, os
usurios operacionais no tiveram grandes dificuldades em utilizar o novo sistema, pois j
tinham bastante facilidade com o uso da informtica.
Durante o processo de implementao, como o grupo estava em fase de reestruturao,
foram surgindo novas necessidades que influenciaram o processo, e alteraram algumas das
etapas previstas. Segundo o coordenador de sistemas, o cronograma havia sido inicialmente
definido para que o sistema fosse primeiro implementado na AgroLaranja e depois nas demais
empresas do grupo, iniciando-se a implementao pelo mdulo de recursos humanos. Entre-

170

tanto, no momento em que o sistema estava sendo preparado, em maio de 1.997, o grupo decidiu consolidar todas suas empresas agrcolas (fazendas) em uma nica empresa, e a prioridade passou a ser a implementao do sistema de recursos humanos nesta nova empresa. Segundo o coordenador de sistemas, a dificuldade dessa tarefa era unir os diversos sistemas de
recursos humanos existentes em todas estas empresas (30 empresas, incluindo as fazendas),
escritos em diversas linguagens diferentes (Clipper, COBOL, Lotus 1-2-3, etc.). Segundo o
entrevistado, o trabalho foi rduo, mas foi um sucesso, pois em um ms o sistema estava
implementado e funcionando sem problemas ou erros. Segundo ele, o sucesso obtido nessa
implementao de emergncia serviu como respaldo para que a informtica implementasse o sistema nas outras reas, muitas delas ainda reticentes quanto ao novo sistema que seria
implementado.
Entre maio e dezembro de 1.997 foram implementados os mdulos da rea administrativa e financeira do Logix, na AgroLaranja. O mdulo de manufatura recebeu extensa customizao, em decorrncia das necessidades de controle de qualidade da AgroLaranja no serem atendidas pelo sistema na poca e foi implementado apenas no terceiro ano de utilizao,
em agosto de 1.999, integrando-se ao mdulo de suprimentos.
A implementao em fases exigiu a integrao dos dados entre os sistemas antigos e o
sistema ERP por meio de arquivos-texto, gerados em lote, por seis meses, o que foi considerado bastante trabalhoso pelo gerente de informtica. O gerente no apontou problemas
tcnicos causados pelas interfaces. Segundo o gerente de informtica, os sistemas foram implementados sem que se utilizassem os sistemas em paralelo. Segundo o coordenador de sistemas, no houve atraso nos prazos planejados de implementao. Entretanto, os custos inicialmente planejados foram ultrapassados em decorrncia de um grau de customizao maior
do que o imaginado. A AgroLaranja investiu US$ 680 mil no projeto, incluindo as licenas de
uso, o banco de dados, os servidores, o treinamento e as customizaes.
Implementao: Problemas
A principal dificuldade da implementao, segundo o gerente de informtica, no foi
tcnico, mas relativo mudana da maneira das pessoas trabalharem e visualizarem as informaes necessrias. No caso do mdulo de recursos humanos, houve a dificuldade inicial de o
sistema anterior ter sido desenvolvido sob medida e j ter sido utilizado por mais de quatro
anos, o que levou a um tempo maior para a adaptao. Segundo o coordenador de sistemas, os
sistemas anteriores eram desenvolvidos como luvas cirrgicas, perfeitamente adaptados ao

171

dia-a-dia dos usurios, e isso trouxe dificuldades para que os usurios moldassem as suas
tarefas a um sistema padro.
Segundo o coordenador de sistema, a principal dificuldade foi enfrentar a necessidade
de mudana de cultura, quando algumas reas passaram a ser responsveis por tarefas que
antes no realizavam, tais como a entrada de informaes contbeis no sistema. O coordenador de sistemas aponta o total apoio oferecido pelo vice-presidente da empresa ao projeto
como fundamental para o processo.
De acordo com o gerente de suprimentos, houve uma dificuldade com os consultores do
fornecedor do pacote, em decorrncia da carncia de conhecimentos de alguns deles, principalmente os mais novos na empresa fornecedora, sobre o sistema. Muitas vezes era necessrio
que o fornecedor enviasse o consultor snior responsvel pelo mdulo para que problemas de
implementao pudessem ser resolvidos.
Para aquele gerente ainda, houve resistncias mudana do sistema, refletida em comentrios do tipo o sistema anterior era muito melhor, mas o argumento utilizado para justificar a mudana era o ganho que a empresa como um todo obteria, ao utilizar-se um nico
sistema integrado. Segundo o gerente, a informtica ajudou nisso [no processo de convencimento dos usurios] pressionando o fornecedor para que as customizaes necessrias
fossem feitas.
Uma das dificuldades enfrentadas pela rea de informtica foi a necessidade de implementar o sistema nas diversas empresas do grupo. Segundo o gerente de informtica, se [a
implementao do sistema] fosse s na AgroLaranja, o problema seria facilmente resolvido.
Como as demais empresas muitas vezes tm negcios bastante diferenciados dos da AgroLaranja (portos, fazendas, etc.), foi necessrio o desenvolvimento de novas customizaes, alm
das dificuldades para convencimento dos usurios. Muitas vezes as pessoas nas empresas
eram resistentes, porque estava se implementado um sistema que teoricamente estaria adaptado apenas AgroLaranja, e esses usurios consideravam que os negcios de suas empresas
eram diferentes. Segundo o coordenador de sistemas, uma das dificuldades de implementar o
sistema em diversas empresas a realizao do trabalho de convencimento e quebra de resistncia nas inmeras empresas, repetidas vezes. Mas, segundo ele, com o tempo todos vo se
engajando no processo, e chegam l [aceitam o sistema, em funo dos benefcios para o
grupo como um todo]. Auxiliaram nesse processo de convencimento o gerente de controladoria da AgroLaranja, que tinha como misso a centralizao dos planos de contas de todas as
empresas do grupo e o vice-presidente da empresa.

172

Segundo o gerente de informtica, o fornecedor tem atendido muito bem empresa nas
customizaes necessrias utilizao pelas diversas empresas e o fato de o sistema poder ser
parametrizado diferentemente para cada uma das empresas que o utiliza facilita bastante nesse
processo.
Mudar o Pacote ou a Empresa?
As discrepncias entre o pacote e a empresa eram apresentadas ao vice-presidente da
empresa juntamente com uma anlise de vantagens e desvantagens, e este decidia o que seria
mudado. Segundo o gerente de informtica, o resultado foi equilibrado, optando-se por mudar os procedimentos da empresa nos momentos em que os custos da customizao seriam
altos. Em alguns casos, segundo os entrevistados, o pacote trouxe novas idias e melhorou a
forma de trabalhar da empresa. O gerente de informtica citou o caso do pagamento aos produtores de laranja que recebiam seus pagamentos depositados pela empresa no banco que
cada um desejasse, o que representava uma dificuldade de controle de um grande nmero de
bancos. Como o sistema Logix possua opo de pagamento escritural com poucos bancos,
seria necessrio um grande e custoso trabalho de customizao, adaptando-o para trabalhar
com cada um dos bancos. Decidiu-se ento negociar com o principal banco que atendia empresa para que este recebesse todos os pagamentos e os distribusse entre os diversos bancos.
(Neste caso, o sistema em si no melhorou o processo, mas terminou por obrigar a uma reviso deste, que gerou uma nova maneira de trabalhar).
Segundo o gerente de suprimentos, antes da implementao do sistema foi feito um estudo e verificaram-se quais as customizaes seriam necessrias no mdulo de suprimentos.
Parte destas customizaes, consideradas por ele como o mnimo necessrio para iniciar a
operao, foram feitas antes do incio da operao, deixando-se o restante para ser desenvolvido aps o incio da utilizao, em decorrncia do prazo para o incio da operao.
As customizaes foram via de regra incorporadas ao pacote, por meio de negociao
com o fornecedor, exceo dos mdulos-satlite citados. O coordenador estima que 70%
do pacote foi implementado sem customizao.
Os Mdulos-Satlite
Alm dos mdulos do Logix, a AgroLaranja desenvolveu uma srie de mdulossatlite que tm a finalidade de complementar a funcionalidade do sistema ERP em reas
especficas da empresa. Os mdulos-satlite so customizaes que por serem bastante ex-

173

tensas e possurem um certo grau de independncia, podem ser consideradas como se fossem
mdulos adicionais do sistema ERP. Segundo o coordenador de sistemas, esses sistemas so
mdulos que nenhum ERP tem, e que devem ser construdos ou continuar existindo para
que as empresas possam realizar adequadamente as suas operaes. A AgroLaranja desenvolveu os mdulos de controle industrial e o mdulo citrcola, alm dos mdulos de controle de
fretes, controle do bagao de cana (combustvel) e controle de produo de lcool que estavam sendo desenvolvidos na poca da realizao das entrevistas.
O sistema de controle industrial foi desenvolvido com a finalidade de controlar o descarregamento dos caminhes de laranja e a pesagem das frutas antes de entrarem na linha de
produo. Este sistema alimenta o Logix com a informao a respeito das quantidades recebidas no estoque, eliminando erros na digitao, que se refletiam nos estoques e nos valores
pagos aos produtores. Esse mdulo est interligado a um sistema de controle das mquinas de
produo, trocando as informaes de pesos e quantidades de laranja. O mdulo citrcola tem
como finalidade controlar as safras e a produo de laranja. Por meio deste sistema ser possvel prever a quantidade de frutas que sero recebidas, controlando o tipo de laranja, as datas
de entrega e o produtor. Tambm por este sistema sero controlados e previstos os pagamentos aos produtores.
Nas demais empresas do grupo, tambm existem sistemas que controlam as atividades
especficas e particulares de cada uma das atividades, tais como sistemas de controle de custos
nas fazendas, sistemas para controle de execuo de servios porturios, controle de servios
de navegao, entre outros. Segundo o coordenador de sistemas, no caso das fazendas, cada
cultura (ma, laranja, gado) exige um sistema diferente para seu controle, pois tem uma srie
de caractersticas diferentes.
A AgroLaranja est realizando um esforo para redesenvolver os sistemas j existentes
que sejam necessrios, tanto da prpria AgroLaranja como das demais empresas do grupo, de
maneira a facilitar a sua integrao ao Logix, realizando os projetos em conjunto com o fornecedor do pacote e desenvolvendo-os de maneira a compartilhar dados com o Logix, acessando ao mesmo banco de dados. Mesmo que no sejam incorporados ao sistema ERP, o fornecedor participa do desenvolvimento terceirizando a mo-de-obra (anlise e programao)
necessria ao desenvolvimento destes mdulos. De maneira geral, a AgroLaranja tem deixado
os programas desses mdulos-satlite sob a custdia do fornecedor, de maneira que este
controla quando modificaes no pacote exigiro alteraes nos programas customizados.
Nesse caso, o fornecedor faz um oramento para a realizao dessas alteraes. Segundo o

174

coordenador de sistemas, o ERP como uma casa, voc comea a construir, mas no acaba
nunca.
Utilizao: Benefcios
Segundo o gerente de informtica, o principal benefcio obtido foi a integrao dos diversos sistemas departamentais, inexistente na situao anterior. Com a integrao eliminouse a redundncia de dados e foi possvel garantir e controlar melhor certos processos. Um
exemplo, citado pelo entrevistado, o recebimento de materiais. Como o sistema permite a
verificao dos pedidos de compra, h a garantia de que o material que est sendo recebido
foi devidamente autorizado. Segundo o coordenador, havia realmente muitos problemas nessa rea, e havia muitos casos de mercadorias que eram recebidas antes de o pagamento estar
devidamente autorizado, o que gerava grande retrabalho e necessidade de mo-de-obra para
controle. Com a implementao do sistema ERP, esse controle passou a ser realizado pelo
prprio sistema, que na verdade impede que o problema seja trazido para dentro da empresa.
O gerente de suprimentos tambm aponta a integrao entre os diversos mdulos como o
principal benefcio do sistema.
Com relao a utilizao de um nico sistema por todas as empresas do grupo, os principais benefcios obtidos foram a criao de uma pirmide de controle dentro do grupo,
utilizando os conceitos de linhas de negcio disponveis no sistema, e a reduo dos custos
administrativos. Quanto ao controle, o sistema ERP possibilitou a extrao de relatrios contbeis consolidando os diversos negcios e empresas, da maneira desejada pelo grupo, o que
era praticamente impossvel na situao anterior. Tambm, com o novo sistema, foi possvel
que a controladoria do grupo passasse a ter um papel gerenciador, ao invs de operacional, e
que fosse implementado um plano de contas nico para todo o grupo. Tambm em relao
esse aspecto, a utilizao do sistema ERP permitiu que o grupo padronizasse a maneira de os
diversos departamentos administrativos trabalharem. Os departamentos continuam descentralizados, com pessoal trabalhando nas diversas empresas, mas com o sistema ERP foi possvel
padronizar os conceitos e os processos administrativos. Isso tambm permitiu a implementao dos relatrios consolidados descritos.
Quanto reduo de custos, alm da economia obtida com o desligamento do mainframe, a informtica do grupo foi reduzida de 38 para 9 funcionrios e 3 terceiros na AgroLaranja. O nmero de funcionrios de informtica nas demais empresas no foi reduzido (permaneceram 9 pessoas), embora, segundo o coordenador de sistemas, tenha melhorado a quali-

175

dade do atendimento dessas pessoas s necessidades da empresa com o novo sistema. Os

custos anuais com a informtica reduziram-se de US$ 2,2 milhes de dlares para US$ 1,0
milho.
A utilizao de um nico fornecedor foi apontada como vantagem pelo gerente de informtica, pela facilidade de negociao e gerenciamento obtida. O coordenador de sistemas
aponta outro ganho que a reduo da necessidade de treinamento e desenvolvimento de novos sistemas necessrios para acompanhar a evoluo tecnolgica, pois, segundo ele, estes
custos foram transferidos para o fornecedor.
Outro benefcio importante apontado pelo coordenador de sistemas a reduo do
backlog, isto , da fila de solicitaes dos usurios relativas a modificaes ou desenvolvimento de novos sistemas. Segundo o entrevistado, no modelo anterior de desenvolvimento, a
rea de informtica tinha uma grande dificuldade em executar as solicitaes dos usurios,
pois em boa parte do tempo a rea estava envolvida em dar manuteno ou realizando atualizaes tecnolgicas (como por exemplo, mudanas de linguagem ou verso da linguagem de
programao) nos sistemas anteriores. Esses processos de atualizao tecnolgica consumiam
grandes recursos e tratavam-se apenas de refazer os sistemas em novas linguagens, para que
continuassem funcionando exatamente como antes. Segundo ele, muitas vezes os usurios
cobravam os novos sistemas solicitados, e a informtica no podia atender. Com a implementao do sistema ERP, muitas das solicitaes pendentes foram eliminadas de uma s
vez. Segundo ele, a implementao do sistema ERP trouxe novas solicitaes, mas estas esto em um novo patamar, isto , so solicitaes voltadas ao aprimoramento dos processos
de negcios j implementados ou melhoria das informaes gerenciais. No h mais solicitaes operacionais, isto , de desenvolvimento de sistemas necessrios operao da empresa. Dentro deste aspecto, o sistema ERP possibilitou a realizao de muitas coisas que
eram sonhos, e no foram realizadas por falta de tempo ou limitaes na tecnologia, tais
como a descentralizao do controle de horrio dos funcionrios ou a completa integrao
dos sistemas existentes.
Segundo o coordenador, alm da reduo de custos de pessoal, o nvel de servio prestado pela rea de TI melhorou muito, pois o foco da rea que antes era a manuteno dos sistemas passou a ser o atendimento s necessidades do negcio da empresa. Segundo ele, o
sistema ERP reorientou a informtica, o interesse do pessoal agora participar dos negcios
da empresa, no ficar apenas programando. Com a implementao do sistema ERP e a conseqente mudana na estrutura da rea, os profissionais de informtica se transformaram em

176

facilitadores nos momentos de implementao e intermediadores das necessidades de negcio

da empresa com o fornecedor do sistema. A rea no executa customizaes ou desenvolvimentos de mdulos-satlite, e utiliza um software gerador de relatrios para desenvolvimentos adicionais (o GQL).
Dentro da rea de recursos humanos, o gerente de informtica percebeu uma maior integrao dos funcionrios nas diversas atividades do departamento. O responsvel pelo controle
do horrio dos funcionrios (ou ponto) passou a conhecer as demais atividades no departamento, tais como a folha de pagamento, o controle de frias e rescises, entre outras. O gerente de informtica considera este um crescimento profissional para os funcionrios, obtido
em decorrncia do processo de implementao do sistema. Outro benefcio percebido pelo
gerente em relao rea de recursos humanos foi a passagem da responsabilidade de realizar
a liberao das horas extras e o acompanhamento de faltas para os supervisores das reas,
com a descentralizao do controle do horrio dos funcionrios (coletado em relgios de
ponto eletrnicos). Mensalmente, o sistema emite um relatrio (que pode tambm ser visualizado na tela) indicando pendncias (atrasos, faltas, horas extras). Os supervisores responsveis pelos funcionrios devem ento liberar, ou no, os pagamentos e descontos relativos,
cadastrando esta informao diretamente no sistema. Desta maneira os supervisores passaram
a compreender melhor o funcionamento e as dificuldades enfrentadas pela rea de recursos
humanos neste aspecto. Segundo o coordenador de sistemas, o sistema ERP permitiu que a
gesto de recursos humanos fosse efetivamente descentralizada entre os departamentos.
De acordo com o coordenador de sistema, a rea de exportao mudou bastante com o
novo sistema, e adaptou-se inteiramente ao processo proposto pelo Logix, com ganhos de
eficincia, principalmente no que se refere integrao com o mdulo financeiro, antes realizada inteiramente de maneira manual. A maior parte da produo da AgroLaranja exportada, o que justifica o grande benefcio obtido nessa integrao especificamente.
Na opinio do gerente de suprimentos, em sua rea a implementao do Logix no trouxe grandes benefcios relacionados a mudanas em procedimentos. Ele explicou que, na ocasio do desenvolvimento do sistema de compras anterior, em 1.992, foi feito um benchmarking com diversos fornecedores com a finalidade de se estudar maneiras de melhorar os processos da rea, sendo incorporadas algumas prticas, tais como a digitao da solicitao de
compra pelo prprio requisitante do material, a reviso das famlias de produtos e novas atribuies de responsabilidades entre os compradores. Essa reviso nos processos da rea permitiu uma reduo de 30 pessoas para 8 pessoas. Segundo o gerente de suprimentos, uma das

177

alternativas analisadas na poca foi a compra de um pacote de mercado, mas preferiu-se o

desenvolvimento interno porque o pacote considerado no atenderia a todas as necessidades.
Quando o Logix foi implementado, a viso de processos j estava estabelecida e o ganho relativo foi pequeno, havendo mesmo alguma perda de funcionalidade, pois o sistema anterior
estava exatamente adaptado ao que fazemos. Entretanto, ele salienta que a integrao do
sistema ao sistema de estoques e de contas a pagar trouxe benefcios rea e empresa. O
gerente de suprimentos aponta que os maiores benefcios relativos reduo de pessoal ocorreram na rea de controladoria, que alm de ter o pessoal reduzido (no total do grupo, em
30%) est fazendo a contabilidade das demais empresas do grupo, e na rea de informtica,
onde o servio foi todo terceirizado.
Utilizao: Problemas
Um dos problemas de se ter no s a empresa toda em um nico sistema mas todo um
grupo de empresas, apontado pelo gerente e pelo coordenador de informtica, a necessidade
de manter a disponibilidade do sistema 24 horas por dia, 7 dias por semana. Isso traz dificuldades para a realizao de rotinas de manuteno e atualizao de verses, pois sempre necessrio negociar datas e horrios com empresas que tm necessidades diferentes. Com a possvel implementao de sistemas nas filiais na Europa e no Japo, o gerente de informtica
acha que talvez seja necessria a contratao de uma pessoa adicional na rea de informtica
para trabalhar no turno da noite, dando suporte a esses usurios. A empresa investiu em um
gerador de energia para manter o sistema funcionando no caso de quedas de energia e tem,
como citado, um servidor reserva. Para diminuir os problemas com a telecomunicao, a empresa negociou com a Embratel a criao de um ponto de presena dentro da empresa. Esse
ponto de presena uma antena de rdio que atende toda a cidade, no que se refere aos
servios da Embratel. Por essa razo, um tcnico da Embratel est sempre disponvel ali, o
que torna mais rpida a soluo de eventuais problemas.
O coordenador de sistemas apresentou um problema relacionado ao desenvolvimento de
mdulos-satlite que utilizam a mesma base de dados de um sistema ERP. O fornecedor
alterou o nome de algumas tabelas na atualizao de verso e alguns sistemas importantes
como o de controle industrial deixaram de funcionar de uma hora para a outra.
Segundo o gerente de suprimentos, h uma carncia de relatrios gerenciais no sistema.
Apesar de a empresa utilizar um gerador de relatrios que possibilita extrair informaes di-

178

retamente do banco de dados do Logix, ele considera difcil localizar as informaes no banco
de dados sem o auxlio do fornecedor, devido falta de documentao (modelo de dados).
De acordo com o coordenador de sistemas, o Logix atende adequadamente s necessidades da legislao brasileira, e o fornecedor tem respondido bem s alteraes legais, enviando as alteraes em programas de maneira adequada.
Integrao
Como citado, a integrao de diversos sistemas isolados e a conseqente reduo das tarefas de redigitao e melhoria na qualidade de informao foram citados espontaneamente
como os principais benefcios do sistema pelos entrevistados.
Segundo coordenador de sistemas, a construo da integrao entre os sistemas havia
sido tentada anteriormente, mas como cada sistema pertencia a um analista de sistemas lder
e seus programadores, que por sua vez atendiam a um determinado departamento ou grupo de
usurios, era muito difcil a execuo desta integrao. Segundo ele, cada um se prendia
sua premissa e no mudava, ou seja, cada vez que havia necessidade de alterar a maneira de
um departamento trabalhar em funo da integrao, havia uma resistncia muito grande por
parte dos departamentos envolvidos e da prpria informtica. Com a utilizao do sistema
ERP, a integrao pde ser finalmente obtida.
ERP e desempenho / competitividade
O gerente de informtica entende que um sistema ERP traz benefcios internos para a
empresa, tal como o aumento do controle das operaes, mas entende que no possvel associ-lo ganhos em competitividade na AgroLaranja. Mesmo com o desenvolvimento do
sistema citrcola, que controla as safras e os fornecedores, ele acredita que os ganhos sero
internos, isto , relativos uma melhoria na eficincia dos processos da empresa. Entretanto, ele reconhece que o sistema ERP trouxe redues de custos, em relao ao pessoal administrativo e aos custos de informtica.
O mesmo gerente apresentou o caso de uma das empresas do grupo, produtora e exportadora de mas, que possui um posto de venda no Ceasa em So Paulo-SP. Trata-se de um
ambiente muito dinmico onde as vendas so realizadas muito rapidamente. Se uma determinada informao no puder ser fornecida no momento em que o comprador a solicita, grande o risco de ele comprar do concorrente, localizado no box vizinho. No caso dessa empresa,
o entrevistado entende que o sistema ERP trar ganhos competitivos, pois o vendedor poder

179

consultar os estoques e a programao de recebimentos de maneira on-line, evitando problemas de promessas no cumpridas e a perda de vendas enquanto a informao solicitada est
sendo obtida pelo telefone.
Muitas vezes a percepo de melhoria por parte das reas est ligada reduo de pessoal. Em muitas reas, onde a reduo foi grande, acredita-se que o sistema trouxe mais trabalho, e, conseqentemente pior que o anterior. Segundo o gerente de informtica, o sistema
no trouxe mais trabalho, mas eliminou folgas que existiam nos departamentos com os sistemas anteriores. No caso do departamento de recursos humanos, reduziu-se de 41 para 10
pessoas, atendendo a todo o grupo. Segundo ele, as pessoas hoje trabalham de maneira mais
inteligente. Segundo o coordenador de sistemas, apesar das diferentes percepes nos departamentos, o ganho na empresa como um todo foi muito grande.
Integrao com outros sistemas
O Logix foi integrado ao Fast-EIS (executive information system) da Execplan, ao sistema de controle de manuteno Mantec da SEMAPI, alm dos mdulos-satlite desenvolvidos para a AgroLaranja e para as demais empresas do grupo. Segundo o coordenador de
sistemas, o controle dessas interfaces no problemtico.
Consideraes sobre o Caso
Pontos de Destaque
Destacou-se no caso da AgroLaranja o ganho da empresa com a substituio dos inmeros sistemas nas diversas empresas do grupo. A reduo de custos de informtica obtida por
meio dessa unificao sozinha justificou financeiramente o projeto.
Por ser o fornecedor nacional, verificou-se uma maior abrangncia funcional do pacote
escolhido, uma vez que este inclui mdulos como recursos humanos, ativo fixo e exportao.
Uma das vantagens apontadas pelos entrevistados quanto a essa maior abrangncia a simplificao de negociao com um nico fornecedor. No foram citados problemas de atendimento legislao brasileira, mais comuns nos pacotes importados, e no foi necessrio
AgroLaranja adquirir pacotes adicionais para atender necessidades legais, tais como a emisso de livros fiscais.
Outra considerao importante a ser citada, o fato de como a representatividade de um
determinado cliente pode alterar a sua relao com o fornecedor de sistemas. O grupo era, no

180

momento da realizao das entrevistas, um dos principais clientes do fornecedor, o que, aparentemente, lhe conferiu um maior poder de barganha, tornando mais fcil a negociao de
customizaes e a sua incluso no corpo do pacote, o que como se observou nos outros caos
no uma prtica comum entre os fornecedores de sistemas ERP. Entre os servios obtidos
pela AgroLaranja com o fornecedor est a citada custdia dos mdulos-satlite. Por meio
desse servio, o fornecedor fica responsvel pelo controle das necessidades de alterao nestes sistemas. Esse servio no comum, e no foi observado nos demais casos. Entretanto,
seria necessrio verificar a viabilidade desse procedimento para o fornecedor no longo prazo,
uma vez que essa administrao uma tarefa complexa e possivelmente custosa.
Sobre o desenvolvimento dos mdulos-satlite ainda importante apontar que a
AgroLaranja utilizou o sistema ERP como base para uma srie de desenvolvimentos adicionais que tem melhorado os seus processos. O sistema de controle industrial, por exemplo,
permitiu um grande ganho em eficincia e controle. Outro aspecto interessante o desenvolvimento dos mdulos-satlite com uso bastante intensivo de mo-de-obra terceirizada, tanto
do fornecedor do sistema ERP como de outros parceiros. A AgroLaranja escolheu reduzir ao
mximo sua equipe de informtica, terceirizando todo e qualquer tipo de desenvolvimento.
Mesmo com o grande nmero de desenvolvimentos que tm sido realizados, os custos ainda
so bem menores do que com o desenvolvimento interno, segundo o coordenador de sistemas.
Principais Aspectos Presentes no Modelo Inicial
Neste caso pde-se verificar, pelo relato do coordenador de sistemas entrevistado, as dificuldades existentes para a criao de um sistema integrado utilizando a equipe interna de
informtica, mesmo estando a tecnologia necessria disponvel (no caso, o banco de dados e a
linguagem de programao da Oracle), o que foi tentado na AgroLaranja. As dificuldades
surgiram relacionadas tanto equipe de informtica, que no estava preparada para desenvolver sistemas desta maneira, como aos usurios, uma vez que a implementao de sistemas
integrados exige mudanas de procedimentos e possvel aumento de tarefas em outras reas.
Verificou-se tambm que a implementao e utilizao de um sistema ERP permitiu a
reduo do backlog de aplicaes e a reorientao da rea de TI, que passou a se ocupar mais
com o atendimento s necessidades do negcio do que com a evoluo da tecnologia em si.
Pelo fato de o sistema ERP possuir grande abrangncia funcional e estar atendendo 80
empresas do grupo, verificou-se uma grande preocupao em manter a disponibilidade do
sistema. O fato de a AgroLaranja ter praticamente abrangido toda a sua operao com um

181

nico sistema refletiu em facilidade de negociao e suporte pelo fato de tratar-se de um nico
fornecedor.
Novos Aspectos que Podem ser Incorporados ao Modelo Inicial
No caso da AgroLaranja, foi possvel perceber como a resistncia dos usurios e o grau
de customizao podem estar relacionados. Uma vez que os sistemas da AgroLaranja eram
desenvolvidos sob medida, foi notada uma grande resistncia dos usurios ao novo sistema,
considerado pouco amigvel. Entre os recursos utilizados para vencer essas resistncias
estavam o apoio da alta direo (como indicado no modelo inicial), a argumentao de que,
embora houvesse aumento no trabalho em algumas reas, a empresa como um todo ganharia,
e, por fim, a execuo das customizaes solicitadas. Esse ltimo recurso, quando utilizado
para contornar a resistncia nos momentos iniciais da implementao, pode levar a um grau
maior de customizao.
Muito importante no caso da AgroLaranja foi a verificao de que fatores contingenciais podem influenciar a conduo do projeto de implementao e obrigar a alteraes nos planos iniciais. Entretanto, neste caso, a mudana foi at benfica, pois ofereceu equipe de informtica a possibilidade de mostrar sucesso em uma primeira implementao de emergncia. At ento havia uma descrena dos usurios quanto a utilizao de pacotes, e esse primeiro sucesso serviu para aumentar a credibilidade do projeto.
A questo de como os benefcios e dificuldades dos sistemas ERP so percebidos diferentemente nas diferentes reas tambm foi notada neste caso. O gerente de suprimentos
identificou as reas de contabilidade e informtica como as maiores beneficiadas pelo projeto,
uma vez que foram as que obtiveram maior reduo de pessoal. Ainda sobre isso, um comentrio do gerente de informtica mostrou que os usurios finais podem ter uma interpretao
distinta dos gerentes das reas a respeito do sistema ERP. Como ele citou, os usurios das
reas onde aconteceram as maiores redues de pessoal tendem a achar que o sistema piorou, uma vez que suas tarefas foram ampliadas.
A definio do termo mdulo-satlite ficou mais clara no relato do caso da AgroLaranja. So programas customizados que podem ser considerados como se fossem novos mdulos dos sistemas ERP.
Contrastes com o Modelo Inicial
Como citado anteriormente, a AgroLaranja no considera uma dificuldade da utilizao
de sistemas ERP a obteno de modificaes nos programas-padro do sistema ERP. Isso

182

pode estar associado, como citado tambm, posio de destaque que a empresa ocupa para o
fornecedor.

183

6.6 CASO VINE TXTIL

Empresa: Vine Txtil S.A.
Sistema ERP utilizado: Magnus, verso i
Entrevistas realizadas entre Outubro de 1.999 e Novembro de 1.999
Entrevistados: Gerente de Informtica
Contador
Gerente Financeiro

Pontos Principais do Caso

O Caso Vine Txtil apresenta a implementao do outro pacote nacional pesquisado, o
Magnus. Sua implementao foi feita utilizando-se o modelo de big-bang e em um projeto
com prazo bastante reduzido, que tinha um prazo irrevogvel para o seu trmino.
Apresentao da Empresa, Mercado e Principais Produtos
A Vine Txtil, referida daqui em diante apenas como Vine, uma empresa nacional
pertencente ao grupo Vicunha. O grupo Vicunha um grupo nacional que possui empresas
em diversas atividades (tais como finanas, siderurgia e minerao). No ramo txtil, so quatro as empresas do grupo: a Vicunha Nordeste, a Vine, a Fibrasil e a Fibra. At o momento da
realizao das entrevistas, a administrao da Vine era independente das demais empresas
txteis do grupo, embora j fosse prevista, para o incio do ano 2.000, a consolidao de algumas reas, tais como a administrao e a informtica. No momento da realizao das entrevistas, a consolidao ainda no havia se iniciado e esse processo no ser considerado no
caso.
A Vine produz tecidos e malhas de algodo, nylon e polister brancos, tingidos e estampados. Seus principais clientes so confeces de roupas e varejistas de tecidos. A Vine possui 6 fbricas, todas no estado de So Paulo: uma localizada em So Manuel, 3 localizadas em
Itatiba, 1 em Amparo e 2 em Americana. Alm das fbricas, a Vine ainda possui na cidade de
So Paulo um prdio onde ficam localizados os escritrios (administrao e comercial) e depsito centrais. O valor do faturamento anual da Vine gira em torno de R$ 200 milhes, e a
empresa contava com aproximadamente 2.480 funcionrios em seus quadros, em dezembro de
1.999. At 1.998, a empresa chamava-se Elizabeth Txtil.

184

A rea de TI e Dados Tcnicos

O departamento de informtica da Vine conta atualmente com 14 pessoas. Destas, 10
pessoas esto alocadas no escritrio central em So Paulo, e esto assim divididas: 4 analistas
de sistemas, 4 pessoas no suporte, a gerente de informtica e uma secretria. Alm destas, a
rea tem 4 pessoas funcionrios nas fbricas, sendo um em So Manuel, um em Americana e
dois em Itatiba. Os funcionrios alocados nas fbricas tm basicamente a funo de suporte ao
sistema industrial (SGT), rede e a telecomunicaes. Entre as atribuies da rea esto o
desenvolvimento de melhorias e relatrios para o sistema ERP e tambm o acompanhamento
das necessidades dos usurios, apresentando e executando projetos que possam trazer benefcios s reas. Segundo a gerente de informtica, que era analista de sistemas na poca da implementao do sistema ERP, com a entrada do sistema ERP houve uma mudana no perfil
dos profissionais da reas, que passaram a se preocupar mais em entender os processos de
negcio da empresa e como o sistema pode ser utilizado para auxiliar esses processos, ao invs de cuidar apenas de aspectos tcnicos de anlise e programao de sistemas.
Antes da implementao do sistema ERP, a equipe de informtica contava com 7 pessoas, que prestavam suporte microinformtica. Aps a implementao, foi montada a rede,
instalada a comunicao via satlite e um maior nmero de usurios passou a ter acesso microinformtica e aos sistemas. Com a mudana na infra-estrutura tecnolgica, alm das necessidades de desenvolvimentos adicionais, foi necessrio expandir a equipe de informtica
para o nmero atual de 14 pessoas.
O servidor utilizado pela empresa uma mquina HP K200, o sistema operacional o
Unix e o banco de dados o Progress. Em dezembro de 1.999, havia 110 usurios utilizando o
sistema Magnus. O Magnus roda de maneira centralizada, e a conexo com as outras localidades feita via satlite. A rea de TI subordinada diretoria administrativa e financeira da
empresa.
Os mdulos implementados
Os seguintes mdulos do Magnus esto implementados na Vine: contabilidade, pedidos
e faturamento, suprimentos (estoque, compras e recebimento), contas a pagar, contas a receber, obrigaes fiscais, caixa e bancos e patrimnio. Para o mdulo industrial, a Vine utiliza
outro sistema, o SGT (sistema de gerenciamento txtil), que um pacote de MRP adaptado
especificamente ao processo txtil. O mdulo de custos no utilizado, porque exigiria a entrada do sistema de manufatura do prprio Magnus.

185

A implementao do Magnus foi iniciada em maro de 1.994 e em julho do mesmo ano

iniciou-se a operao. Os mdulos de obrigaes fiscais, contas a pagar e caixa e bancos entraram em operao em um segundo momento, em janeiro de 1.995.
Histrico da Deciso e Seleo
At a implementao do sistema ERP, a Vine utilizava-se dos servios de um bureau de
informtica para atender s suas necessidades de processamento de dados. Esse bureau era
tambm uma empresa do grupo Vicunha, a Informatel, e prestava servios s demais empresas do grupo. exceo do livro fiscal, que era um sistema desenvolvido em microcomputador, todos os demais sistemas (pedidos e faturamento, contas a receber, contas a pagar, finanas e contabilidade) eram executados pelo bureau. Uma das dificuldades apresentadas pelo
sistema anterior que havia um grande nmero de relatrios que eram executados no bureau
durante a noite e trazidos empresa pela manh. Alm disso, segundo a gerente de informtica, os sistemas do bureau no eram integrados e exigiam grande trabalho de redigitao para
transferncia de dados entre eles. O cadastro de produtos, por exemplo, era feito em quatro
sistemas diferentes. Os sistemas do bureau eram desenvolvidos em COBOL e rodavam em
mainframes IBM.
Com a finalidade de reduo de custos e atualizao dos sistemas utilizados, a empresa
decidiu escolher e implementar um sistema ERP. Alm das diretorias da empresa, participou
do processo de seleo uma consultoria, que por meio da realizao de um estudo chegou
concluso que a substituio do software era necessria tanto para a melhoria dos processos
administrativos como para a reduo de custos.
Outro problema apontado pela gerente de informtica como um dos fatores que pesaram
na deciso por um sistema ERP era a dificuldade em se conseguir alteraes no sistema ou
mesmo o desenvolvimento de relatrios, pois o processo de negociao das alteraes era
demorado e o custo era alto.
Segundo a gerente de informtica, o Magnus foi escolhido por ser a melhor alternativa
entre as existentes na poca em que se realizou o processo de escolha (incio de 1.994). Influenciou tambm a deciso o fato de a Vicunha Nordeste utilizar o banco de dados Progress, e
na poca a empresa no pensou em pesquisar os fornecedores estrangeiros. Segundo a gerente
de informtica, o usurio no foi envolvido na seleo do fornecedor, sendo basicamente uma
deciso tomada pela rea de informtica e a consultoria contratada para o estudo, e isto chegou a causar alguns problemas durante a implementao. Para ela, um maior envolvimento

186

dos usurios-chave no processo de seleo poderia diminuir algumas resistncias que foram
apresentadas no processo de implementao.
A gerente de informtica apontou como uma preocupao existente na poca a adequao do pacote s necessidades do processo txtil, que eram consideradas muito especficas.
Por isso essas necessidades foram desconsideradas no processo de seleo, deixando-se o foco
da escolha na rea administrativa e financeira. Para automatizar a parte industrial, optou-se
por adquirir um aplicativo especfico para a rea txtil (o citado SGT), implementando os dois
sistemas concomitantemente. O SGT permitiria o controle de caractersticas especficas do
processo de produo txtil, tais como o controle de produtos por grade de largura e cor, controle de produtos por pea e controle de receitas (combinao de fios e tintas).
Histrico da Implementao
A implantao do sistema ERP foi iniciada em maro de 1.994 e iniciou-se a operao
do sistema em julho 1.994. O prazo reduzido para a implementao (4 meses) era decorrente
de um prazo negociado entre o grupo Vicunha e a empresa que fornecia os servios de informtica. Ao trmino desse prazo, o contrato com grande parte das empresas do grupo, inclusive a Vine, estaria encerrado e os servios deixariam de ser prestados. Dessa maneira, alm do
prazo reduzido, havia a impossibilidade de se alterar a data de incio das operaes.
Utilizou-se a metodologia de implementao do prprio fornecedor do pacote, que tambm participou do processo com uma equipe de consultores tcnicos, alm de um consultor
que coordenava o processo pelo lado do fornecedor. O gerente de informtica da empresa na
poca de implementao foi definido como o coordenador do projeto. A equipe interna foi
dividida em duas reas, comercial e financeira, que tinham dois coordenadores cada. A equipe
do fornecedor tambm tinha coordenadores por rea. Durante a implementao, foram contratadas duas pessoas que j haviam trabalhado com o Magnus, para reforar a equipe interna
de informtica.
As atividades de cada uma das equipes eram planejadas em conjunto pela empresa e
pelo fornecedor, e as principais tarefas dessas equipes eram o levantamento de dados, a apresentao do sistema aos usurios, discusso a respeito das adaptaes e a realizao da parametrizao e customizaes necessrias, incluindo a integrao com o SGT. Com a finalidade
de facilitar o processo, o fornecedor disponibilizou modelos-padro de processos, que incluam a maneira de realizar a parametrizao, para serem utilizados como base da implementao. A participao do usurio ocorreu por meio de entrevistas quando era necessria a obten-

187

o de informaes a respeito de como eram executados os processos na empresa. Alm disso, os usurios receberam treinamento e participaram dos cadastros nas tabelas do sistema.
Para o mdulo contbil, o incio da operao foi por meio do processo de sistemas em
paralelo. Por um ms, os dois sistemas foram utilizados simultaneamente. Na rea comercial
no houve a realizao do paralelo, e desta maneira no havia como se retornar ao sistema
anterior, aps o incio da operao. Dentro do escopo do projeto, pode-se considerar a implementao do Magnus como tendo sido feita em big-bang, uma vez que substituiu, simultaneamente, todos os principais sistemas da empresa. Os trs mdulos que foram implementados
logo aps (obrigaes fiscais, caixa e bancos e contas a pagar) ou eram executados em microcomputadores ou inexistentes antes da implementao do sistema ERP.
Segundo a gerente de informtica, tanto os custos como os prazos planejados para a implementao do sistema ERP foram atingidos.
Mudar o Pacote ou a Empresa?
A meta estabelecida para o projeto era minimizar as customizaes na fase de implementao, para que se garantisse a realizao do projeto em quatro meses. Para isso, a rea de
informtica decidiria quais eram as customizaes necessrias, estabelecendo que apenas
aquelas alteraes extremamente necessrias seriam realizadas.
Segundo a gerente de informtica, essa orientao criou uma certa dificuldade de negociao com as reas usurias, especialmente no que se referia aos relatrios que existiam no
sistema anterior na rea comercial. Se os mesmos relatrios fossem ser replicados no novo
sistema seria necessrio muito tempo para o seu desenvolvimento. Era necessrio negociar
com os diretores das reas usurias a no realizao de todas as customizaes solicitadas,
pelo menos na fase de implementao. Mas, segundo a gerente, todos os usurios envolvidos
estavam conscientes do motivo pelo qual as customizaes deveriam ser evitadas (o prazo
para a entrada do novo sistema era inegocivel), alm de uma clara orientao da alta diretoria
da empresa nesse sentido. Isso tornou o processo de convencimento um pouco mais simples,
mas o processo foi um jogo poltico. Segundo ela, em alguns casos no foi possvel evitar a
customizao.
As principais alteraes realizadas durante a implementao foram a integrao com o
sistema SGT e a modificao no contas a receber para o controle de duplicatas de terceiros. A
Vine aceita como pagamento duplicatas dos clientes, e assume a responsabilidade por sua
cobrana. Esse tipo de controle no existia no Magnus.

188

Aps a implementao, a orientao de no customizao foi abrandada, e a rea de informtica passou a analisar quais mudanas ou melhorias poderiam ser realizadas, principalmente na rea comercial, onde foi desenvolvida uma srie de relatrios, tais como relatrios
de cotas de vendas.
No caso do Magnus, as customizaes no podem ser feitas nos programas principais do
sistema. Para se fazer as customizaes, so desenvolvidos programas externos que so chamados a partir de pontos especficos - e previamente definidos - dos programas principais.
A gerente de informtica estima que na rea comercial o Magnus tenha sido customizado em cerca de 50%, principalmente em decorrncia das alteraes necessrias para a integrao ao SGT e desenvolvimento de relatrios. No mdulo de contabilidade e no mdulo de
obrigaes fiscais a customizao foi mnima e permaneceu pequena aps a implementao.
No caso da contabilidade, apenas um relatrio adicional foi desenvolvido. No contas a receber, cerca de 20% foi customizado devido ao controle de duplicatas de terceiros. O mdulo de
compras tambm precisou ser customizado para que fosse integrado ao SGT.
Implementao: Problemas
Uma das dificuldades relatadas pela gerente de informtica foi o fato de que durante a
implantao (no momento dos testes e parametrizao) percebeu-se que o sistema ERP no
possibilitaria que o controle de estoque de produtos acabados fosse feito pea por pea, o que
era exigido pela empresa e pela natureza do negcio. Por ser o tecido um produto que armazenado em rolos e pode ser cortado em peas nos comprimentos solicitados pelo cliente, pode
ocorrer que cada bobina de tecido tenha uma metragem diferente, e isso deve ser controlado
pelo sistema. Alm disso, existe a necessidade de se manterem informaes de rastreabilidade
(de que lote de fibras foi feito o tecido, em que lote recebeu a tintura, entre outros) para que
possveis problemas de qualidade possam ser verificados. Segundo a gerente de informtica,
houve dificuldade em convencer o fornecedor do pacote a realizar as customizaes necessrias, tanto no sentido de convenc-lo da importncia das alteraes para a empresa, como faz-lo compreender essas alteraes, pois os consultores do fornecedor no tinham experincia
no setor txtil, e tinham dificuldade em compreender suas peculiaridades. Um exemplo de
peculiaridade, relativo ao controle de produtos acabados e faturamento e que no era contemplado pelo sistema, o fato de que quando o cliente pede 1.000 metros, posso entregar 980
ou 1.020, dependendo das bobinas que tenho em estoque. O Magnus no realizava esse controle, deixando o pedido em aberto, ou exigindo a digitao de novo pedido. Para resolver

189

esse impasse, houve a customizao do mdulo de faturamento uma maior amplitude em sua
integrao com o SGT.
A gerente de informtica apontou ainda outros trs problemas relacionados implementao. O primeiro relaciona-se ao o fato de que simultaneamente ao incio da operao do
sistema (julho de 1.994) estava sendo iniciado o Plano Real, um plano econmico do governo
que criou uma nova moeda (o real), entre outras medidas. Entretanto, segundo a gerente, embora a preocupao tenha sido maior, houve a vantagem de se iniciar o novo sistema j utilizando a nova moeda. Isso eliminou a necessidade de se realizar a transformao de moedas no
sistema antigo para que depois se implementasse o sistema novo, pois se aproveitou o processo de transferncia de dados para o novo sistema para converter os valores para a nova moeda.
O segundo problema citado foi a inexperincia dos consultores do fornecedor que participaram do processo de implementao. Segundo ela, os consultores que cuidavam do gerenciamento do projeto possuam bons conhecimentos, mas aqueles que metiam a mo na massa, ou seja, aqueles que realizavam a adaptao do sistema realidade da empresa, eram
menos experientes. Ela entende que havia uma grande resistncia do fornecedor em se envolver nos problemas da empresa e em executar alteraes consideradas essenciais pela empresa.
O terceiro problema apontado foi o prazo reduzido para a implementao, que, segundo
a entrevistada, obrigou a empresa a implementar o sistema sem muito planejamento, sendo
necessrio um intenso trabalho para corrigir eventuais problemas aps a implementao. Segundo ela, o primeiro ms de operao foi muito complicado, principalmente em decorrncia
de problemas relacionados integrao do Magnus com o SGT, que no pde ser extensivamente testada durante a implementao: a equipe trabalhou por vrios finais de semana,
mas chegou um momento em que as coisas entraram nos eixos. O processo de estabilizao
total do sistema demorou cerca de seis meses, o que incluiu a implementao de alguns mdulos adicionais (obrigaes fiscais, contas a pagar e caixa e bancos). Aps esse perodo, foi
possvel ao departamento de informtica voltar-se ao desenvolvimento de melhorias no sistema ERP.
O gerente financeiro comentou que, em decorrncia do reduzido tempo de implementao, no houve a possibilidade de treinar os usurios com a profundidade necessria, e no
momento em que se iniciou a operao do sistema alguns deles no sabiam como operar adequadamente o sistema. Isso gerou alguns problemas como a necessidade de maior suporte do
fornecedor.

190

O contador apontou as necessidades de modificao no mdulo de contas a receber

como uma das dificuldades da etapa de implementao, e, segundo ele, em decorrncia do
prazo reduzido foi necessrio que se iniciasse a operao do sistema sem que as alteraes
estivessem finalizadas. Isso gerou a necessidade de controle manual por um certo perodo de
tempo. Segundo o gerente financeiro, no caso dessa alterao, os consultores do fornecedor
tiveram dificuldades em compreender as necessidades da empresa, por se tratar de uma situao nova a que no estavam acostumados.
Houve tambm o problema de mudana cultural, pois o usurio no possua a viso de
sistemas integrados. Segundo a gerente de informtica, muitas pessoas estavam h muito tempo na empresa e tinham medo da mudana. Durante a implementao foram encontradas algumas resistncias, principalmente relacionadas ao fato de que os usurios estavam percebendo que, em funo da integrao do sistema, algumas tarefas seriam eliminadas.
Utilizao: Benefcios
Segundo a gerente de informtica e o contador, o maior benefcio do sistema ERP foi a
integrao entre os mdulos, que no existia na situao anterior. Com isso, houve reduo do
tempo necessrio para o fechamento contbil, eliminando a necessidade de lanamentos manuais e envio de planilhas para o bureau de servios. Por meio da integrao, tambm houve
uma reduo no pessoal da rea de contabilidade e financeira. De maneira geral, a utilizao
do sistema ERP reduziu o fluxo de papel na empresa, e a informao ficou mais rpida e confivel. A maioria dos relatrios disponibilizados pelo outro sistema era executada em batch
durante a noite no bureau de servios, e eram trazidos pela manh para a empresa. Segundo o
gerente financeiro, um dos grandes benefcios do sistema foi a possibilidade de executar os
relatrios a qualquer momento, e extra-los na prpria empresa ou mesmo visualiz-los em
tela. Dessa maneira, os ganhos em velocidade de informao foram muito grandes.
Com o desenvolvimento de outras funcionalidades em mdulos-satlite, tal como o
controle de peas com cdigo de barras, houve redues adicionais de tempos de operao e
mo-de-obra em outros setores, tal como o setor de almoxarifado de produtos acabados.
A utilizao do sistema ERP permitiu a reduo de custos de informtica em decorrncia da eliminao da taxa paga ao bureau, mesmo com a necessidade de aumento de pessoal
na rea e implementao de infra-estrutura de informtica.
Segundo a gerente de informtica, uma das vantagens em se utilizar um sistema desenvolvido por terceiros que no mais necessrio que a empresa se preocupe com o desenvol-

191

vimento e manuteno de funcionalidades que so padro para todas as empresas, tais como a
contabilidade e rea financeira, havendo, portanto, um ganho em escala. Entretanto, ela salienta que a flexibilidade nas alteraes e desenvolvimentos est limitada ao desenvolvimento
de relatrios e utilizao de programas externos, no sendo possvel a alterao nos programas-padro do pacote. Ela entende que os sistemas anteriores possuam a vantagem de ser
desenvolvido sob medida de acordo com as necessidades do grupo Vicunha, mas, embora
fosse possvel a sua alterao, era cara e demorada. Mesmo que os programas-padro do Magnus no possam ser modificados, a possibilidade de criar relatrios e programas externos na
prpria Vine trouxe uma flexibilidade maior do que na situao anterior.
Utilizao: Problemas
O gerente financeiro entende que uma das dificuldades na utilizao do sistema ERP a
obteno de alteraes ou melhorias. Como a rea de informtica tem seus recursos reduzidos,
a obteno de algumas modificaes e relatrios fica dificultada. Segundo ele, embora sempre
exista a alternativa de gerar diversos relatrios j existentes no sistema e combinar as informaes em planilhas para a obteno dos relatrios desejados, desta maneira a obteno da
informao fica mais demorada e trabalhosa. O gerente financeiro entende que o sistema
desenvolvido para atender s necessidades gerais das empresas, existindo dificuldades para o
atendimento de necessidades especficas. Porm, segundo ele, mesmo com as dificuldades
possvel aproveitar bastante o sistema.
A Vine no utiliza os servios do fornecedor para desenvolvimento de relatrios, e o faz
com sua equipe prpria. Dependendo do tamanho do projeto e da customizao, so contratados terceiros para o desenvolvimento.
Segundo o gerente financeiro e a gerente de informtica, uma das dificuldades no atendimento das informaes gerenciais o fato de que mudanas na diretoria da empresa exigem
mudanas nos relatrios, pois cada novo administrador quer dar a sua cara s informaes
gerenciais, e a cada mudana necessrio mudar os relatrios. Desde o incio da utilizao do
sistema ERP ocorreram trs mudanas de administrao. No momento ele entende que as informaes esto adequadas. Segundo o contador, o gerador de relatrios existente no Magnus
tem atendido s necessidades de obteno de informaes gerenciais da rea. Segundo a gerente de informtica, o gerador de relatrio do Magnus apresenta algumas limitaes, o que
traz dificuldades para a elaborao de relatrios mais complexos.

192

Para o contador, uma das dificuldades apresentadas pelo sistema que a quantidade de
posies numricas para o armazenamento de centros de custo limitada a cinco dgitos, o
que trouxe maiores dificuldades para a realizao do controle de custos por planta, sendo a
alterao exigida no sistema para o aumento dessa quantidade de dgitos considerada bastante
trabalhosa.
A gerente de informtica apontou ainda a dificuldade existente para o teste das alteraes e correes enviados pelo fornecedor. Como existem programas adicionais desenvolvidos para atender s necessidades da Vine, em cada alterao de programas feita pelo fornecedor necessrio que se realizem testes, verificando a compatibilidade com os programas desenvolvidos internamente. Apesar de as tabelas do sistema no sofrerem alteraes, apenas
quando muda a verso, pode ocorrer de o local do programa principal onde realizada a chamada para o programa externo mudar de localizao dentro do programa, e isso pode exigir a
alterao do programa externo. A Vine mantm um controle dos programas externos desenvolvidos, de maneira que possvel saber quais programas podem ser afetados pelas correes enviadas.
A gerente de informtica comentou que o sistema ERP atende adequadamente s necessidades da legislao brasileira, apontando apenas a dificuldade relacionadas s mudanas na
legislao que obrigam ao fornecedor enviar correes, que tm o problema j citado de exigir
alteraes nos programas externos desenvolvidos pela empresa.
Segundo a gerente de informtica, as necessidades de melhorias incorporadas ao programa central so passadas ao fornecedor por um grupo formado por representantes de diversas empresas usurias do sistema. Esse grupo de usurios, que organizado de maneira independente, tem grande preocupao em cobrar do fornecedor as melhorias que considera necessrias. As alteraes realizadas pelo fornecedor, negociadas pelo grupo de usurios, so
incorporadas nas prximas verses do produto. Segundo a gerente de informtica, esse grupo,
chamado Grupo de Usurios do Magnus, tem alguma fora no sentido de obter vitrias
junto ao fornecedor, mas no o grupo que determina as mudanas do sistema. Este grupo
ainda no conta com a participao de vrios clientes o que ainda no o faz muito influente
nas decises do fornecedor .
Integrao
Na questo da integrao, um dos aspectos apontados pela gerente de informtica, o
fato de que a partir do momento em que os usurios comearam a utilizar o sistema, passaram

193

a perceber que seria necessrio mudar de postura, uma vez que houve mudanas na responsabilidade pela entrada dos dados. Um exemplo dado pela gerente o do setor de recebimento
que deveria dar entrada aos dados fiscais, o que obrigou os funcionrios a entender essa parte
do processo. A partir dessa necessidade, houve um crescimento profissional das pessoas, sendo esse tambm considerado como benefcios relativo integrao. Segundo a gerente, a integrao ajudou a empresa a mudar e melhorar seus processos administrativos.
O gerente financeiro tambm apontou a integrao como o grande benefcio do sistema.
Entretanto, ele salienta que se o sistema industrial e o mdulo de recursos humanos utilizados
fossem do prprio Magnus, poderia haver um ganho maior relativo a esse aspecto. Ele entende que mesmo que fosse necessrio fazer adaptaes nesses mdulos para permitir sua utilizao, os custos seriam menores do que o retorno proporcionado pela integrao.
Segundo o gerente financeiro, a integrao completa dos mdulos do sistema ERP da
maneira adequada foi sendo conseguida ao longo do tempo, em um processo de aprendizagem
da empresa.
ERP e desempenho / competitividade
A gerente de informtica entende que difcil relacionar o sistema ERP a ganhos em
desempenho e competitividade, pois o desempenho da empresa est mais relacionado ao desempenho das mquinas de produo. Segundo ela, o mercado txtil sofreu grandes mudanas
recentemente com a entrada de produtos importados o que exigiu uma srie de medidas, e
difcil isolar o efeito do sistema ERP do todo. Segundo ela, a informao mais gil ajuda a
tomada de deciso, mas difcil afirmar que a empresa ficou mais competitiva em decorrncia
dessa agilidade.
Integrao com outros sistemas
O Magnus integrado ao SGT, desenvolvido por uma empresa de Blumenau, SC, que
transfere e recebe dados de pedidos de compra e estoques de produtos acabados com o Magnus via batch. A folha de pagamento tambm um pacote de outro fornecedor (APData),
tambm integrada via batch. Alm desses, existe um sistema de automao de vendas, desenvolvido por terceiros para palmtops (plataforma Windows CE). Por esse sistema, cerca de 30
representantes enviam seus pedidos pela Internet. Tambm existe um sistema de controle de
depsito com leitor de cdigo de barras, desenvolvido internamente como um mdulosatlite.

194

Outros Comentrios dos Entrevistados

Sobre o projeto: Foi um projeto de informtica. Se fosse fazer de novo, faria de outra
maneira, envolvendo mais o usurio.
Sobre a utilizao: Com o passar dos anos, a empresa foi aprendendo a usar o sistema, aprendendo a usar os relatrios fornecidos.
Consideraes sobre o Caso
Pontos de Destaque
Um dos pontos que podem ser destacados no caso da Vine o baixo envolvimento dos
usurios nos processos de escolha e implementao, e o fato de que os entrevistados entendem
que isso trouxe reflexos para o processo de implementao, principalmente no que se refere a
resistncias mudana. Alm disso, a orientao de no se customizar o sistema, cuja execuo ficou bastante centralizada na rea de informtica, tambm dificultou o processo e acentuou as resistncias.
Outro ponto interessante, apresentado pelo gerente financeiro, o fato de que muitas
vezes as informaes necessrias esto todas no sistema ERP, mas sua extrao da maneira
desejada pode exigir o trabalho de combinao de diversos relatrios em planilhas eletrnicas.
Criando-se um relatrio customizado, o trabalho automatizado e torna-se mais simples. Entretanto, necessrio despender recursos de desenvolvimento e controle posterior de verses
para que esses relatrios possam ser desenvolvidos.
Foi citada tambm a existncia de um grupo de empresas usurias que age como centralizador das necessidades e solicitaes de alteraes que essas empresas gostariam de incluir
nos programas-padro do pacote. Segundo a gerente de informtica, esse grupo, apesar de
conseguir que muitas solicitaes sejam incorporadas ao pacote, sofre algumas limitaes em
sua influncia, porque no conta com a totalidade dos clientes do pacote (deve-se salientar
que as necessidades de alterao que so incorporadas no pacote, isto , em seus programaspadro, so interessantes para os clientes uma vez que o nus da manuteno do fornecedor). A existncia desse grupo um aspecto interessante, que pode merecer estudo mais profundo, e que est ligado maneira como as empresas usurias se relacionam com os fornecedores de sistemas ERP.

195

Principais Aspectos Presentes no Modelo Inicial

Novamente, o principal benefcio do sistema ERP citado pelos entrevistados foi a integrao entre os mdulos e, novamente, essa no estava presente na situao anterior. A velocidade para obteno de informaes foi citada como benefcio, mas tambm comparativamente ao sistema anterior.
A resistncia mudana para um sistema integrado tambm foi citada, e, nesse caso foi
citada tambm a questo do temor frente possibilidade de perda de emprego, por conta da
eliminao de tarefas proporcionada pelo sistema integrado.
Novos Aspectos que Podem ser Incorporados ao Modelo Inicial
O caso permitiu observar novamente a questo do controle das customizaes antes do
incio da operao. Assim como no caso da CNT/VMM, a determinao inicial era de minimizar a customizao, mas, nesse caso, em decorrncia da existncia de um prazo fixado e
irrevogvel para o incio da operao do sistema, uma vez que se entendia que a realizao de
customizaes poderia comprometer o prazo. Tambm, como na CNT/VMM, ficou para o
departamento de informtica a responsabilidade de cumprir essa determinao. Mesmo havendo apoio da alta direo da empresa e a conscincia por parte dos usurios que essa era
uma necessidade do projeto, o processo foi encarado pela rea de informtica como um difcil
jogo poltico.
Em decorrncia do reduzido prazo para a etapa de implementao e do fato de que a
data de incio da operao no poderia ser alterada, houve pouco tempo para testar a integrao entre o Magnus e o SGT e mesmo terminar algumas customizaes que estavam sendo
feitas, o que se refletiu em problemas no incio da operao. O fato de que se implementaram
dois pacotes simultaneamente (o Magnus e o SGT) tambm contribuiu para a dificuldade no
incio das operaes, pois eram dois sistemas novos, desconhecidos na empresa e em sua fase
inicial de curva de aprendizagem e que, alm disso, deveriam trocar informaes entre si para
operarem. Tambm foram percebidos problemas no treinamento dos usurios, que tiveram
dificuldades para operar o sistema. A gerente de informtica estimou a etapa de estabilizao
do sistema em 6 meses, incluindo-se a a implementao de trs mdulos que ficaram para
uma segunda etapa.
Quanto consultoria, destacou-se o fato de que a equipe de informtica percebeu que os
consultores tinham dificuldade em entender a empresa, e resistncia em fazer as adaptaes
necessrias aos processos da empresa.

196

6.7 CASO ZENECA

Empresa: Zeneca Brasil Ltda.
Sistema ERP utilizado: SAP R/3, verso 3.0 fd
Entrevistas realizadas em Setembro e Novembro de 1.999
Entrevistados: Gerente de Informtica
Tesoureiro
Ger. de Planejamento e Comrcio Exterior
Pontos Principais do Caso
No caso da Zeneca, o principal ponto que pode ser destacado a implementao do R/3
em substituio a outro sistema comercial integrado. Como os entrevistados participaram
tanto da implementao do primeiro pacote como da implementao do sistema ERP, pde-se
comparar os dois momentos. Outro ponto de destaque a implementao conduzida de maneira bastante centralizada na equipe de informtica.
Apresentao da Empresa, Mercado e Principais produtos
A Zeneca Brasil uma empresa fabricante de defensivos agrcolas, subsidiria da Zeneca, empresa inglesa originria da separao da ICI, fabricante de produtos qumicos e farmacuticos, em duas empresas. Na diviso, ocorrida em 1.993, a ICI reteve os negcios da rea
qumica e a Zeneca, nova empresa criada no processo, os das reas farmacutica e agrcola.
Em abril de 1.999 a Zeneca e a Astra, empresa farmacutica sueca, se uniram formando a AstraZeneca, que atualmente a terceira maior empresa farmacutica no mundo. A Zeneca continua centralizando as atividades agroqumicas do grupo. A AstraZeneca possui, ainda no
Brasil, uma empresa dedicada ao negcio farmacutico, a AstraZeneca do Brasil.
A Zeneca Brasil possui duas fbricas, uma em Paulnia-SP e uma em Cravinhos-SP,
alm de um depsito de vendas em Porto Alegre-RS e do escritrio central em So Paulo-SP.
Em 1.998 a empresa faturou US$ 250 milhes e contava com 600 funcionrios em setembro
de 1.999, no momento da realizao das entrevistas.
Os principais produtos da empresa so os herbicidas Zapp, Gramoxone e Flex, os fungicidas Fusilade, Amistar, e Anvil, e os inseticidas Effect e Karate. Os clientes da Zeneca Brasil
so basicamente distribuidores, que revendem os produtos a fazendeiros de diversas culturas
(milho, soja, caf, etc.) em todo o Brasil. Existe tambm a venda direta aos fazendeiros, mas
esta modalidade ainda representa um percentual pequeno em funo da disperso geogrfica

197

de seus clientes por todo o Brasil. A Zeneca Brasil possui ainda uma diviso que atende rea
de sade pblica.
A rea de TI e Dados Tcnicos
Hoje a rea de TI conta com 13 profissionais, assim distribudos: gerente, secretria, 8
analistas de negcio e 3 analistas de suporte. H tambm um programador ABAP (funo
tambm conhecida no mercado como abapper) terceirizado, presente na empresa em tempo
integral. Segundo o gerente de informtica, os funcionrios da rea esto todos na empresa
desde a poca do mainframe, isto , h pelo menos 7 anos (o mainframe foi utilizado na
empresa at 1.992). A rea de TI subordinada presidncia da empresa.
O sistema ERP executado em 3 servidores Compaq, utilizando sistema operacional
Windows NT e banco de dados Oracle. Um dos servidores utilizado para o desenvolvimento
de programas, um para a realizao de testes e outro para a produo, isto , para o processamento real das transaes da empresa. O processamento do sistema ERP e o seu banco de
dados so centralizados em uma nica mquina, que atende a todas as localidades (4 no total:
as duas fbricas, o depsito de vendas e o escritrio central). Como infra-estrutura de comunicao de dados, a Zeneca Brasil utiliza a rede frame-relay da Embratel e algumas linhas privativas de dados ponto a ponto da Telefonica, com resultados satisfatrios.
A rede da empresa possui um total de 400 micros e 180 usurios acessam o R/3. Desses,
15 so usurios internacionais, acessando o R/3 de localidades remotas tais como a Inglaterra
e os Estados Unidos.
Os mdulos implementados
Em agosto de 1.998 iniciou-se a operao dos mdulos FI, CO, SD, MM e PP-PI (industrial verso indstria de processos) do SAP R/3, todos simultaneamente em todas as localidades da empresa, em big-bang.
Histrico da Deciso e Seleo
At 1.992, a Zeneca Brasil, ento ICI, utilizava um sistema desenvolvido internamente
em COBOL, em mainframe IBM. Nesse momento, a ICI mundial decidiu por um processo de
downsizing, isto , reduo dos custos de informtica por meio de mudana de tecnologia e
utilizao de sistemas comerciais em substituio ao desenvolvimento prprio, objetivando
tanto a reduo de custos como o aumento do foco no negcio. Nessa ocasio, a empresa op-

198

tou no Brasil pelo PACOTE A, de origem americana, que foi implementado na empresa ao
longo de 1.992. Nessa poca, a ICI era usuria do SAP R/2 na Europa e nos Estados Unidos,
sendo, inclusive, uma das primeiras clientes da SAP para o R/2. No momento da escolha do
PACOTE A no Brasil, o R/3 ainda no estava disponvel no pas.
Em 1.997, a empresa, j Zeneca Brasil, confrontou-se com o problema da necessidade
de atualizao da verso do PACOTE A para garantir a compatibilidade das datas do sistema
com o ano 2000. Esta nova verso do PACOTE A, por ser bastante diferente, exigiria uma
nova implementao com todos os custos e esforos associados. Ao mesmo tempo, tambm
em 1.997, a matriz da Zeneca decidiu por uma padronizao em todas as subsidirias do mundo utilizando o R/3, em um projeto cuja implementao dever ser iniciada no ano 2.000.
(Atualmente o R/2 usado na Europa e nos EUA e o R/3 j est implementado na Argentina,
Guatemala e Hong Kong, alm do Brasil. As subsidiarias da Europa acessam o R/2 instalado
na Inglaterra, em um CPD europeu centralizado). As empresas da Zeneca no Brasil (a Zeneca
Brasil e a Zeneca Farmacutica) tinham ento duas alternativas: atualizar a verso do
PACOTE A ou substitu-lo por outro pacote, antes que o projeto mundial de implementao
do R/3 se iniciasse.
A motivao para a substituio do sistema ERP foi, portanto, uma combinao da necessidade de resolver o problema do ano 2000 e a oportunidade de aderir mais rapidamente a
uma determinao da matriz. A diviso farmacutica da Zeneca no Brasil (ento Zeneca Farmacutica) optou por fazer a atualizao para a nova verso do PACOTE A, enquanto a Zeneca Brasil optou pela sua substituio pelo R/3. Segundo os entrevistados, a Zeneca Brasil
preferiu partir para a mudana de sistema em razo da maior atualizao tecnolgica e abrangncia do pacote R/3 em relao s exigncias e necessidades do mercado e mesmo porque o
custo da atualizao do PACOTE A seria bastante significativo. Tambm, segundo o gerente
de informtica, uma padronizao corporativa acaba por economizar um grande esforo despendido em processos de seleo de pacotes nas diversas subsidirias, onde muito provavelmente o R/3 estaria invariavelmente entre os pacotes finalistas.
Quanto questo da compatibilidade entre o R/3 e a Zeneca Brasil, a principal preocupao era o sistema comercial, pois a poltica de preos da Zeneca Brasil considerada pelos
entrevistados como muito diferente do processo padro disponvel em pacotes comerciais.
Alm disso, o sistema de contas a receber tambm apresentaria dificuldades, devido s polticas de financiamento aos agricultores no Brasil.

199

Histrico da Implementao
O caso Zeneca Brasil oferece a oportunidade de comparar duas implementaes de pacotes em uma mesma empresa. Uma, em 1.992, do PACOTE A em substituio a sistemas
proprietrios em mainframe, e, outra, em 1.998, do R/3 em substituio ao PACOTE A.
Como o gerente de informtica entrevistado participou das duas implementaes, foi possvel
comparar alguns dos aspectos presentes nos dois momentos.
Na implementao do PACOTE A, a principal preocupao da rea de TI era enfrentar
a descrena dos usurios em relao utilizao de pacotes, uma vez que se estava substituindo sistemas desenvolvidos pela equipe interna, sob medida, de acordo com os requisitos
dos usurios, para um sistema comercial padronizado. Segundo gerente de TI, nessa situao
comum os usurios afirmarem que a empresa diferente das demais e que pacotes no
vo funcionar, havendo uma maior resistncia implementao do novo sistema. Para o gerente de informtica, no momento da implementao do R/3, a cultura de pacotes j estava
estabelecida, isto , os usurios j haviam utilizado um pacote por mais de 5 anos e as vantagens e limitaes desse tipo de soluo j eram bem conhecidas. A principal preocupao
ficou ento com a questo do tipo de converso escolhida: o big-bang.
Segundo o gerente de informtica, uma das vantagens do big-bang est na criao de
um senso de urgncia em toda a empresa, que fora a um estabelecimento de prioridades
em relao ao projeto. Em um sistema implementado por fases, apenas aqueles departamentos
diretamente envolvidos no mdulo, ou mdulos, que esto sendo implementados se dedicam
ao projeto, e a ateno da empresa como um todo no obtida. Quando a converso em bigbang, por sua vez, toda a empresa est voltada para o projeto, o que garante maior ateno por
parte das diretorias, gerncias e usurios. Alm disso, o fato de que ser praticamente impossvel voltar ao sistema anterior tambm fora a um maior comprometimento com os testes e
treinamento. O entrevistado salientou que no h como criar um plano de contingncia (isto ,
preparar alternativas para a hiptese do sistema parar de operar) no caso do big-bang, e que h
riscos, principalmente se os problemas ocorrerem dois ou trs dias aps o incio das operaes, pois nesse caso, decorrido j algum tempo de operao no novo sistema, a dificuldade
de retornar ao anterior ainda maior. Outra vantagem citada pelo gerente a eliminao da
necessidade de construo de interfaces entre os sistemas antigos e o novo, enquanto todos os
mdulos no estiverem implementados.
Segundo os entrevistados, o grande projeto de reengenharia, isto , revises e racionalizao nos processos da empresa, ocorreu na implementao do PACOTE A, em 1.992.

200

Nessa ocasio foram revistos os processos, aproveitou-se da tecnologia que estava sendo implementada para a reduo de mo-de-obra e melhoria em procedimentos. Aps a implementao, a empresa sofreu ainda algumas alteraes com a venda para a Zeneca, tais como reduo do nmero de divises e linhas de produto. A implementao do PACOTE A foi feita em
fases, mdulo a mdulo, ao contrrio da implementao do R/3.
O processo de implementao do R/3 iniciou-se em novembro de 1.997 com o apoio de
uma grande empresa de consultoria, utilizando-se de metodologia desenvolvida pelo fornecedor do sistema ERP, a ASAP. O processo de controle de qualidade do projeto e a configurao do basis (parte tcnica do R/3, isto , configuraes de bancos de dados, redes, hardware,
backup, performance, etc.) seria feita pelo prprio fornecedor do pacote. Alm disso, havia o
apoio de um grupo da Zeneca americana, especialista em R/2, para a construo de templates,
isto , modelos de processos, que seriam aproveitados nas instalaes seguintes do R/3 na
empresa (na Guatemala e em Hong Kong).
Alguns problemas foram apontados pelos entrevistados: a consultoria no enviou pessoal devidamente preparado, o que causou grande desgaste entre os consultores e a equipe de
projeto. Por essa deficincia, a empresa foi gradualmente deixando de utilizar os servios da
consultoria. Os consultores do fornecedor foram sendo ento progressivamente mais utilizados para suprir essa deficincia e o fornecedor, por sua vez, mostrou-se cada vez melhor no
atendimento das necessidades de conhecimentos relativos aos processos. Segundo o gerente
de informtica, o consultor , regra geral, um homem de informtica formado pelo mercado,
com pouca experincia de R/3, to bom ou to ruim como qualquer um de ns. Hoje a realidade melhorou, sinto que eles tm mais segurana. Mas hoje ainda voc se decepciona muito
com as consultorias.
Os americanos da Zeneca auxiliaram bastante, mas tiveram dificuldades em entender o
funcionamento do processo brasileiro, principalmente no mdulo SD (vendas e distribuio).
A questo, segundo o gerente de informtica, cultural: Nos Estados Unidos, quem pede,
recebe, e quem recebe, paga. Alm disso, quem promete, entrega. Outros aspectos apresentados pelo gerente de informtica referem-se aos tempos de entrega de mercadorias (leadtimes), que segundo ele so menores nos Estados Unidos, e aos estoques de segurana mantidos pelas empresas, que so maiores. Dessa maneira, o processo comercial americano muito
mais simples, com menor necessidade de controles, alm, claro, da menor quantidade de
relatrios fiscais necessrios.

201

A partir da metade do processo de implementao, em fevereiro de 1.998, a equipe de

informtica da Zeneca Brasil conduziu sozinha o projeto, coordenado pelo gerente de informtica. Os usurios envolvidos no foram retirados do dia-a-dia das operaes e participaram
dos processos de parametrizao e customizao por meio de consultas realizadas pelos analistas de sistemas da equipe. Segundo os gerentes usurios entrevistados, o grande conhecimento dos analistas internos em relao aos processos de negcio, uma vez que todos estavam
na empresa h bastante tempo, tendo participado tanto do desenvolvimento dos sistemas do
mainframe como da implementao do PACOTE A, foi fundamental para o sucesso da implementao. Segundo eles, quando havia algum problema, o pessoal da informtica j trazia solues detalhadas, pr-estudadas, para que ns pudssemos decidir qual seria a melhor
alternativa e os analistas entendiam como funcionava a ferramenta nova [o R/3] e a
adaptavam ao nosso processo.
O processo de implementao durou 9 meses. Em novembro de 1.997 iniciou-se o treinamento da equipe do projeto e em janeiro de 1.998 foram entregues os templates pelos americanos. Entre fevereiro e julho de 1.998 houve o processo de customizao e parametrizao
e em agosto de 1.998 foi feito o go-live (isto , o incio da operao no novo sistema). O prazo
inicialmente estabelecido era julho de 1.998, ocorrendo um atraso de um ms, em decorrncia
de riscos (possibilidade de ocorrerem problemas na operao, tanto pelo treinamento como
pelas customizaes e adaptaes) percebidos nos testes finais em junho.
Quanto resistncia mudana, os entrevistados concordam que ela foi muito maior na
implementao do PACOTE A. Segundo eles, na implementao do R/3 a resistncia utilizao de pacotes j estava de certa maneira vencida. Ainda assim, houve a realizao de reunies contnuas de esclarecimento, salientando os objetivos empresariais do projeto, uma vez
que devido ao excesso de problemas ocorrido durante o incio do PACOTE A, descritos a
seguir, havia uma preocupao de que eles se repetiriam. Nos primeiros momentos da operao do R/3 no houve muitos problemas, segundo o gerente de informtica. Para ele, isso foi
decorrncia de um trabalho de preparao bastante forte, e havia uma equipe do fornecedor
de planto na empresa. Apesar de o incio da operao ter apresentado muito poucos problemas, alguns deles s foram percebidos aps o primeiro ms de operao, no primeiro fechamento do sistema, o que obrigou a correo de alguns dados inseridos ao longo de todo o
ms.

202

Mudar o Pacote ou a Empresa?

Segundo o gerente de informtica entrevistado, a utilizao do PACOTE A teve duas
fases distintas. Na primeira fase, implementou-se o sistema sem grandes alteraes, seguindo
os modelos de processo disponveis no pacote. Mas devido ao grande nmero de problemas
causados pela incompatibilidade entre as funcionalidades do PACOTE A e as necessidades da
empresa, alterou-se o que foi necessrio para adapt-lo, em uma segunda fase. O resultado
desse processo de adaptao foi um pacote bastante customizado.
Na implementao do R/3 a norma era no mudar o pacote. Segundo os entrevistados,
como a reengenharia de processos j havia sido feita na implementao do PACOTE A, acreditava-se que as diferenas entre a empresa e o pacote seriam menores e seria muito mais
simples a implementao sem customizaes. Entretanto, segundo o gerente de informtica
entrevistado, a diretriz de no customizar o pacote sofre restries na vida real de um
projeto de implementao. Segundo ele, todas as empresas que estiverem implementando o
R/3 vo definir, em princpio, que o R/3 no dever ser alterado, mas sempre ocorrero presses por parte das reas usurias pela modificao do pacote, muitas delas plenamente justificadas, uma vez que os pacotes podem impor aumento de tarefas, pelo uso de uma maior
quantidade de telas ou preenchimento de um maior nmero de campos, ou dificuldades em
localizao ou consolidao das informaes nos relatrios fornecidos pelo sistema. Em conseqncia disso, a empresa realizou algumas customizaes no pacote. A deciso a respeito
das alteraes no R/3 eram tomadas por uma comisso formado pelo presidente da empresa,
pelos gerentes usurios e pelo gerente de informtica. Sempre que possvel, a empresa tentou
manter-se fiel diretriz e no customizar o pacote, utilizando-se apenas de novos relatrios,
construdos a partir de dados j existentes no sistema.
Um exemplo de customizao necessria foi o de tratamento das tabelas de preos, que
alm de relatrios e parametrizao, exigiu o desenvolvimento de rotinas adicionais, utilizando o recurso das user-exits. Um exemplo de adaptao do sistema comercial sem grande necessidades de alterao do R/3 foi o processo de previso e reserva, segundo o qual clientes
que antecipam sua previso de consumo, fornecendo Zeneca as quantidades que pretendem
adquirir mensalmente, tm prioridades no atendimento de seus pedidos no caso de restries
nos estoques. As alteraes necessrias ao atendimento desse processo foram basicamente
resolvidas por meio da construo de relatrios.
Segundo o gerente de informtica entrevistado, cerca de 10% da funcionalidade do R/3
foi customizada, tendo sido o SD o mdulo mais customizado. Segundo ele, foi menor a ne-

203

cessidade de customizao no R/3 em relao que foi necessria no PACOTE A, devido a

sua maior quantidade de recursos e flexibilidade. Para o gerente, o R/3 bastante flexvel,
embora complexo, havendo a necessidade de se pesquisar a fundo o seu funcionamento para
realizar sua adaptao empresa de maneira adequada. Segundo ele, no acredite quando
algum diz que o R/3 no faz, investigue, pois sempre h uma alternativa. A dificuldade
descobrir essa alternativa. Nossa cultura, tanto de informtica quanto de consultoria muito
na base do faz ou no faz, e no de investigar e procurar alternativas.
Utilizao: Benefcios
Quando da implementao do PACOTE A, a empresa estava mudando seu modelo de
desenvolvimento de aplicativos da construo de sistemas por equipe interna de informtica
para a utilizao de pacotes comerciais. Buscava-se ento a reduo de custos de informtica,
o foco no negcio, a simplificao da plataforma tecnolgica (substituio do mainframe por
um minicomputador). Nessa ocasio a equipe de informtica foi reduzida de 40 para 13 pessoas, e os custos de manuteno de hardware tambm foram reduzidos. Tambm nessa ocasio procurou-se fazer uma reviso e simplificao dos processos de negcio.
Com o R/3, um dos benefcios esperados era a soluo do problema do ano 2000, tendo
este sido atingido.
Segundo o gerente de planejamento, o principal benefcio obtido na rea foi a substituio de uma srie de sistemas isolados por um nico sistema, eliminando a necessidade de
redigitao dos dados e diferenas nos valores entre cada um desses sistemas e reduzindo o
tempo necessrio para a preparao dos relatrios mensais. Outro benefcio citado pelo entrevistado foi a transparncia dos dados, isto , o acesso s informaes do sistema por todos
aqueles que delas necessitem. Essa possibilidade de acesso inclui os usurios na matriz inglesa, o que eliminou a necessidade de envio de relatrios via fax ou mesmo comunicaes telefnicas.
Segundo o gerente de tesouraria, na rea financeira no houve benefcios muito significativos, pois procurou-se espelhar ao mximo o sistema anterior. Entre os benefcios obtidos citados pelo entrevistados esto alguns recursos do R/3, tais como contas contbeis cujos
lanamentos s podem ser automaticamente gerados pelo sistema em resposta a determinados
eventos empresariais (tais como uma movimentao de material), o que garante a integridade
e a confiabilidade dos dados, e a integrao da contabilidade aos demais mdulos por meio de

204

lanamentos on-line. No sistema anterior, o PACOTE A, a integrao dos demais mdulos

com a contabilidade j existia, porm em processamento batch.
Na contabilidade, aproveitou-se tambm a implementao do R/3 para remodelar o plano de contas contbeis e para se mudar o plano de contas da rea de informaes gerenciais
para um padro determinado internacionalmente pela Zeneca.
Entre os entrevistados h a opinio de que os benefcios obtidos foram diferentes em
cada uma das reas, sendo maiores nas reas de logstica e comrcio exterior.
Utilizao: Problemas
O gerente de informtica apontou a dependncia dos usurios em relao rea de informtica em decorrncia da complexidade do software como uma das dificuldades trazidas
pelo sistema R/3, embora haja um esforo de melhoria nesse sentido por meio do treinamento
dos usurios.
Um dos gerentes usurios entrevistado informou que os consultores da SAP no conseguem mais acompanhar as necessidades de informao da Zeneca Brasil, pois medida que
cresce o grau de conhecimento da empresa sobre o sistema ERP, as perguntas dos usurios
vo se tornando mais especficas e os consultores tm dificuldades em respond-las.
O gerente de tesouraria afirmou que no h nenhum problema srio em sua rea, mas
citou que existem alguns desenvolvimentos (customizaes ou implementaes de algumas
funcionalidades) que foram adiados para depois da implementao para que no se prejudicasse o prazo do projeto e que ainda no foram feitos. Segundo ele, a implementao de um
sistema ERP demanda uma grande dedicao de toda a empresa. Pelo prazo reduzido, muita
coisa fica para depois. uma reao natural humana depois da implementao as prioridades dissiparem-se em outros projetos. Um dos exemplos citados um relatrio de anlise de
rentabilidade que deve ser desenvolvido, e envolve a participao das reas de vendas, custos,
distribuio e financeira. O entrevistado relatou ainda a necessidade de se criarem alguns
controles por fora do sistema R/3, em planilhas eletrnicas, na rea financeira. Alguns casos desta necessidade so o controle de fundos de investimentos e relatrios gerenciais. O
ideal seria que todos os controles da empresa estivessem no sistema, eliminando-se a necessidade de controles externos. Para ele, um sistema ERP perfeito seria aquele que eliminasse
completamente a planilha eletrnica da rea financeira.
A respeito de dificuldades com a localizao, no foram citados grandes problemas,
exceo do mdulo IN-68 (instruo normativa 68, que obriga as empresas a manterem um

205

banco de dados com informaes de 5 anos em um formato especfico, disposio para consultas do governo estadual e federal) e do mdulo de tesouraria (no implementado) que, segundo um dos entrevistados, muito incompleto frente realidade brasileira. Um exemplo de
um problema citado o controle de juros de duplicatas em atraso, que no feito pelo R/3,
sendo necessrio o seu controle externamente ao sistema ERP, em planilhas eletrnicas.
Os gerentes usurios apontaram deficincias nos relatrios gerenciais fornecidos pelo
sistema. Para suprir essa deficincia so desenvolvidos relatrios pela rea de informtica e
existe um projeto para a implementao do BW (business warehouse, o produto de data warehousing da SAP).
Integrao
Os entrevistados no citaram a integrao entre os mdulos como benefcio enquanto
no estimulados com pergunta especfica sobre ela. A esse respeito, o gerente de informtica
salienta o aspecto positivo de obrigar a empresa a encarar o fato de que cada operao tem
um impacto imediato em outras reas, embora os usurios ainda tenham dificuldade de entender isso na prtica. Na opinio do entrevistado, os impactos da integrao em geral so
sentidos nos mdulos financeiros e no MRP. Como problemas, o entrevistado citou a grande
necessidade de planejamento para que seja possvel a utilizao de mdulos e relatrios do
R/3 que utilizem dados que venham de diversos mdulos. Isto , na parametrizao de cada
um dos mdulos necessrio levar em considerao o projeto como um todo, sob pena de ser
impossvel, ou muito difcil, uma implementao posterior. Os exemplos citados so os relatrios de anlise de rentabilidade e o mdulo de custos.
O PACOTE A era integrado, mas, segundo o gerente de informtica, em um grau menor
do que o R/3. No PACOTE A havia muitas integraes feitas em processos batch, e algumas
feitas de maneira on-line. J no R/3, a integrao entre os mdulos feita de maneira on-line
na grande maioria dos processos.
O gerente de planejamento tambm concorda com esse ponto, salientando o extremo
cuidado que deve ser tomado com os cadastros, para que se evitem problemas em outros departamentos. No caso da lista de materiais (bill of materials) do MRP, que a relao de todos as matrias-primas que compem cada um dos produtos, chegou-se a redigitar manualmente os cadastros para que se evitassem problemas na converso automtica dos dados.

206

ERP e desempenho / competitividade

Segundo o gerente de informtica entrevistado, o ERP em si no um diferenciador
competitivo. Entretanto, o entrevistado acredita que, sem ele, uma empresa teria dificuldades
para se estruturar e, portanto, para competir. O entrevistado lembrou que tambm existem
empresas em que isso no necessariamente verdade, onde a competitividade independe da
existncia de sistemas de informao.
Houve benefcios de reduo de mo-de-obra, em decorrncia da integrao dos processos, e possibilidade de se realizar uma maior quantidade de tarefas com mesma mo-de-obra
nos setores administrativos. Contudo, segundo o tesoureiro, as redues obtidas com o R/3
no foram significativas. De acordo com ele, quando o R/3 entra em uma empresa retalhada, cujos sistemas ainda no so integrados, o ganho enorme. Em uma empresa j bem
estruturada, ele no promove grandes alteraes.
Segundo o gerente de planejamento, com a facilidade de gerenciamento e as ferramentas de planejamento disponibilizadas pelo sistema ERP e pela integrao dos mdulos, h
menor necessidade de se manter folgas nos estoques. Tambm melhorou o relacionamento
com o cliente, pois possvel com a reduo do tempo para obteno e reunio de informaes agilizar a resposta ao cliente e diminuir o tempo de entrega. O sistema de previso e reservas de pedidos citado tambm trouxe uma melhoria no relacionamento com os clientes,
uma vez que a empresa pde controlar melhor quais clientes efetivamente haviam fornecido a
previso de consumo, evitando erros na prioridade de atendimento.
Integrao com outros sistemas
A folha de pagamento um sistema independente e sua integrao limita-se entrada
dos lanamentos contbeis no R/3 aps o fechamento do processamento da folha de pagamentos mensal. A rea de planejamento e comrcio exterior utiliza pacotes para o controle
dos processos de importao e exportao, inclusive oficiais como o Siscomex, tambm integrados por meio de troca de arquivos-texto com o R/3.
Consideraes sobre o Caso
Destaques do Caso
Um dos destaques deste caso a possibilidade de comparar alguns aspectos entre a implementao do PACOTE A e a implementao do R/3. Na implementao do PACOTE A,
houve maior resistncia por parte dos usurios, uma maior quantidade de problemas na etapa

207

de estabilizao, que foi mais longa, e o resultado final foi um pacote bastante customizado.
J na implementao do R/3, a resistncia apresentada pelos usurios foi considerada menor,
ocorreram menos problemas aps o incio da operao e o pacote foi considerado como tendo
sido pouco customizado.
Entre as razes que explicam a diferena quanto resistncia, foi apresentada a questo
da descrena quanto ao uso de pacotes, presente na implementao do PACOTE A, uma
vez que esse pacote estava substituindo sistemas desenvolvidos internamente. Na implementao do R/3, parte dessa resistncia j havia sido vencida. Entretanto, havia ainda certa resistncia, uma vez que havia a preocupao de que os mesmos problemas verificados na implementao do PACOTE A se repetissem.
A menor ocorrncia de problemas no incio da operao e menor grau de customizao
foram atribudos uma melhor qualidade tecnolgica, maior flexibilidade e disponibilidade
de opes presentes no R/3 em relao ao PACOTE A. A experincia obtida pela equipe de
informtica na implementao do PACOTE A tambm pode justificar essas melhorias, uma
vez que essa mesma equipe implementou o R/3. Outro aspecto observado, que pode justificar
o menor grau de customizao, foi a preocupao da rea de informtica em procurar realmente conhecer o pacote e sempre procurar alternativas atravs de parametrizaes.
Quanto aos benefcios, houve uma reduo de mo-de-obra mais acentuada na implementao do PACOTE A, tanto em relao rea de informtica quanto em relao s reas
administrativas. Quanto integrao, seus benefcios foram menos enfatizados neste do que
nos demais casos de implementao do R/3, sendo mais salientados no caso da rea de planejamento, onde o R/3 acabou por incorporar boa parte de sistemas isolados que existiam. No
caso da rea financeira, procurou-se substituir exatamente o sistema anterior, e o ganho percebido foi muito menor.
Ficou aparente no caso, portanto, que a dificuldade de implementao de um sistema
ERP maior quando este substitui sistemas customizados. Tambm possvel considerar que
os resultados da substituio de um sistema ERP por outro so menores do que os obtidos
quando o sistema ERP substitui sistemas isolados.
Outro destaque do caso Zeneca referente aos aspectos envolvidos na utilizao do
sistema ERP por uma empresa transnacional. O R/3 acessado por usurios da matriz na Inglaterra, o que facilitou a extrao de relatrios e envio de informaes. A Zeneca tem um
CPD nico na Europa, onde as linhas de comunicao so consideradas boas, o que pode representar uma tendncia para esse tipo de empresa. Outro aspecto interessante, relacionado ao

208

uso globalizado de sistemas ERP, foi a dificuldade da equipe americana da Zeneca em entender as peculiaridades dos processos comerciais no Brasil. de se esperar que esse tipo de
problema se repita em outras empresas e pases.
Novos Aspectos que Podem ser Incorporados ao Modelo Inicial
No caso Zeneca pde-se perceber a questo da dificuldade para o desenvolvimento de
alteraes solicitadas pelos usurios durante o projeto que foram adiadas para depois do incio
da operao, por questes de prazo ou recursos. Uma vez iniciado o uso do sistema, h mudana nas prioridades da equipe de informtica, muitas vezes em razo de fatores contingenciais. No caso de alteraes maiores, h ainda a dificuldade em obter-se o envolvimento de
todas os departamentos necessrios. A esse respeito, um dos entrevistados apresentou a seguinte analogia: conheo um casal que ao mudar de casa uma primeira vez, por no dispor
de tempo ou recursos, deixou para comprar e instalar o lustre da sala em um segundo momento. O tempo foi passando, outras necessidades surgiram e o lustre no foi colocado.
Quando o casal mudou novamente de casa, a esposa exigiu de seu marido que o lustre da
sala fosse colocado antes da mudana, pois, seno, ela no mudaria. Hoje, h um lustre na
sala deles.
A respeito da determinao em no se alterar o pacote durante a implementao, o gerente de informtica salientou que h dificuldade em se manter essa diretriz, em razo das
presses dos usurios para que as dificuldades impostas pelo uso de um sistema genrico
(maior quantidade de telas, maior quantidade de campos a serem preenchidos) sejam minimizadas.
Mais uma vez destacou-se a questo dos consultores e a sua dificuldade em fornecer os
conhecimentos requeridos pela empresa e usurios, tanto durante como aps a implementao.
Principais Aspectos Presentes no Modelo Inicial Verificados
Ocorreu uma quantidade menor de problemas de localizao neste caso, comparativamente aos outros casos de R/3 estudados, possivelmente por ter sido essa a implementao
mais recente. Ainda foram citados problemas e a necessidade da realizao de alguns controles externos ao R/3, por meio de planilhas eletrnicas.

209

Contrastes com o Modelo Inicial

O fato de a implementao de o sistema ERP ter sido realizada em sua maior parte pela
equipe de TI, sem o auxlio direto de consultoria externa em grande parte do projeto e com
baixo envolvimento dos usurios, mas com sucesso, na opinio unnime dos entrevistados,
contrasta com as recomendaes observadas no levantamento bibliogrfico. Um dos gerentes
entrevistados apontou como fator crtico para esse sucesso, dentro das condies apresentadas
(conduo do projeto pela rea de TI), o grande conhecimento da equipe de informtica a respeito dos processos de negcio, uma vez que todos na equipe de informtica esto na empresa
desde a poca do mainframe, e participaram tanto dos processos de desenvolvimento interno dos aplicativos no mainframe, como do processo de implementao e adaptao do
PACOTE A. Isso trouxe equipe um grande conhecimento a respeito dos processos da empresa e tambm, de certa maneira, das necessidades dos usurios. Segundo o gerente de informtica, o conhecimento da arquitetura mainframe tambm foi de grande valia no caso do
R/3, pois este incorpora uma srie de atributos de segurana de dados que haviam naqueles
sistemas. Outros aspectos que podem ter auxiliado o sucesso dentro das condies apresentadas foram a existncia prvia de uma cultura de pacotes e a menor necessidade de reengenharia de processos, pois tratou-se de uma substituio de sistemas ERP e no de uma implementao sobre sistemas customizados.
Outro ponto observado o citado aumento da dependncia dos usurios em relao
rea de informtica, o que contrasta um pouco com os benefcios apresentados no levantamento bibliogrfico. Esse fato tambm pode ser justificado pela maneira como foi conduzido
o projeto e pelo fato de a rea de TI possuir grandes conhecimentos sobre o sistema.
A questo das vantagens do big-bang surgiu novamente, sendo citado que esse modelo
de implementao cria um senso de urgncia na empresa que fora o envolvimento de todos
os departamentos simultaneamente.

210

6.8 CASO MELHORAMENTOS PAPIS

Empresa: Melhoramentos Papis Ltda
Sistema ERP utilizado: Logix, verso 3.0
Entrevistas realizadas entre Dezembro de 1.999 e Janeiro de 2.000
Entrevistados: Diretor Financeiro
Controller
Gerente de Materiais e Logstica
Gerente de Informtica
Supervisora de Telemarketing
Principais Caractersticas do Caso
O caso Melhoramentos Papis fornece a perspectiva de aspectos relativos implementao por fases e tambm da utilizao de um sistema ERP nacional. No caso da implementao por fases, pde-se verificar a importncia do planejamento da ordem de implementao
dos diferentes mdulos. Tambm nesse caso pde-se verificar como um sistema ERP pode ser
usado para unificar os sistemas e a cultura em uma nova empresa criada a partir da unio de
duas empresas distintas.
Histrico da Empresa
Em 1.993, a Cia. Melhoramentos de So Paulo (CMSP) decidiu expandir suas atividades de produo de papel absorvente, contratando a consultoria de um banco de investimentos
para auxiliar nesse processo. Nessa poca, a empresa possua tambm outras atividades, tais
como editora, grfica, livrarias, e grfica de valores (cheques e vales refeio), alm de negcios na rea de reflorestamento e urbanizao. A recomendao do banco foi que se separasse
a rea de produtos de papel absorventes das demais, criando-se uma nova empresa que seria
ento aberta para o mercado. Formou-se ento a Melpaper S/A. Nessa ocasio havia tambm
a oportunidade de compra da fbrica de papis absorventes da Kimberly Clark do Brasil
(KCB), subsidiria da empresa norte-americana de mesmo nome, que estava se retirando do
mercado brasileiro. A Melpaper S/A buscou recursos no mercado de aes, aumentando seu
capital com objetivo de adquirir a KCB. A operao foi bem sucedida e a Melpaper S/A passou a ser controladora da KCB, que, por sua vez, teve sua razo social alterada para Melhoramentos Papis Ltda (MP). A operao de produo e venda de papel das duas fbricas a
partir daquele momento passou a ser centralizada na MP. Passaram a pertencer a essa nova
empresa (a MP) a fbrica de produtos de papel absorvente da CMSP localizada em Caieiras,

211

no estado de So Paulo, e a fbrica da KCB, localizada em Mogi das Cruzes, tambm no estado de So Paulo. O controle acionrio manteve-se com a CMSP, mas o banco nomeou conselheiros para o Conselho de Administrao e um diretor financeiro, a fim de manter a independncia e autonomia na gesto da empresa. A rea administrativa foi separada e alocada em
um edifcio comercial em So Paulo, fora da sede da CMSP e da antiga KCB.
No que se refere aos funcionrios, a nova empresa recebeu pessoas das duas empresas
anteriores. Na administrao (contabilidade, financeiro), a maioria dos funcionrios veio da
KCB, j que a CMSP manteve sua estrutura administrativa para os outros negcios da empresa. Na rea comercial a maioria dos funcionrios era oriunda da CMSP. Nas fbricas, algumas
funes como suprimentos e planejamento da produo foram ao longo do tempo sendo absorvidas pela fbrica de Mogi das Cruzes.
Em fevereiro de 1.995, o banco de investimentos vendeu sua participao acionria para
fundos de penso, retirando-se do Conselho de Administrao da empresa. Em Julho de 1.997
o escritrio central da MP mudou-se para o bairro da Lapa, em So Paulo, no mesmo prdio
onde esto a grfica, a editora e os escritrios da CMSP.
Mercado e Principais Produtos
A MP fabricante de produtos de papel absorvente e atua em quatro reas de negcio
distintas, que recebem internamente o nome de divises: a diviso consumo, a diviso institucional, a diviso de semi-acabados e a diviso de pasta termomecnica. A diviso consumo
comercializa produtos de consumo domstico, tais como papel higinico, toalhas de cozinha,
guardanapos e lenos de papel. Os principais clientes desta diviso so os hipermercados,
supermercados e farmcias. A empresa atende a um total de 4.000 clientes em todo o Brasil
com essa linha de produtos e de acordo com os dados fornecidos pela empresa, encontra-se
em terceiro lugar neste mercado com participao de 9% no mercado nacional. A diviso de
consumo atende seus clientes por meio de fora de vendas, que coletam pedidos com o uso de
palmtops, e por meio de troca de arquivos via EDI (eletronic data interchange - intercmbio
eletrnico de dados) com alguns clientes de grande porte.
A diviso institucional comercializa papis higinicos e toalhas absorventes para colocao em banheiros de restaurantes, bares, hotis e empresas. So cerca de 12.000 os clientes
desta diviso, que fazem pedidos por um sistema de telemarketing e so atendidos por uma
rede de distribuidores e assistentes tcnicos, responsveis pela instalao e manuteno dos
reservatrios de papel, tambm conhecidos como dispensers. Neste segmento especifico, a

212

empresa lder de mercado no Brasil, detendo aproximadamente 12% das vendas. A diviso
institucional inteiramente originria da KCB.
Alm disso, a empresa tambm comercializa e exporta papel absorvente em bobinas
para fbricas de fraldas e absorventes femininos, o que representa a terceira rea de negcios
da empresa, a venda de semi-acabados. A diviso de pasta termomecnica relativa a uma
fbrica de pasta de celulose, originria da CMSP e localizada na planta de Caieiras. A pasta
termomecnica uma pasta de celulose utilizada para a confeco de produtos de papel, tais
como o papelo e o papel Kraft, para embalagens e sacos.
No momento da realizao das entrevistas, a empresa contava com um total de 840 funcionrios. O faturamento anual da empresa de certa de US$ 120 milhes.
Histrico da Deciso e Seleo
No incio da operao da MP eram utilizados tanto os sistemas herdados da KCB como
os sistemas da CMSP. Havia ento a necessidade imediata de se decidir qual dos dois sistemas seria utilizado. Alm das dificuldades operacionais geradas pela utilizao de sistemas
redundantes, existiam dificuldades especficas relativas ao sistema de faturamento em razo
da impossibilidade fiscal de se emitir notas fiscais em dois sistemas diferentes na mesma empresa.
Os sistemas da CMSP eram desenvolvidos internamente em COBOL, rodando em
mainframe UNISYS. A KCB, por sua vez, utilizava dois sistemas. Para os mdulos relativos
entrada de materiais (suprimentos e contas a pagar) e contabilidade era utilizado o pacote
BPCS, da americana SSA rodando em AS/400 da IBM. Para os mdulos relativos sada de
produtos (comercial, faturamento, contas a receber e livros fiscais de sada) utilizava-se um
sistema desenvolvido internamente em COBOL, rodando em um microcomputador SID.
No primeiro momento, decidiu-se utilizar o sistema de sadas (pedidos, faturamento,
crdito e cobrana) da CMSP, porque o sistema de faturamento da KCB j apresentava limitaes de espao de armazenamento e velocidade de processamento e no teria condies de
comportar o movimento das duas empresas em conjunto. Quanto ao sistema de entradas, decidiu-se utilizar o AS/400, porque esse sistema j estava bastante consolidado na KCB, de
onde viria a maior parte do pessoal de contabilidade e suprimentos. Outra justificativa para as
duas decises seria a composio da nova empresa, pois, como citado, a rea comercial em
sua maioria era oriunda da CMSP enquanto que a administrao vinha da KCB.

213

Como etapa seguinte, a empresa decidiu buscar um sistema ERP no mercado que substitusse os dois sistemas, integrasse os mdulos de entrada e sada e possibilitasse a obteno
de relatrios de resultados consolidados. Decidiu-se dividir o projeto em duas etapas, substituindo-se inicialmente o sistema de sadas da CMSP e depois o sistema de entradas do BPCS.
O foco inicial do projeto era o sistema comercial, porque era o que tinha o custo mensal mais
elevado (a MP pagava CMSP pelo uso do sistema UNYSIS) e seriam obtidos resultados em
um prazo mais curto. Segundo o diretor financeiro, o desenvolvimento interno de um novo
sistema foi desconsiderado por questes de tempo, custo e porque por meio do uso de um sistema desenvolvido por terceiros possvel aproveitar as experincias do fornecedor com
outras empresas de maneira a se obter um sistema mais inteligente, isto , que contenha
prticas de negcio j testadas em outras empresas.
O processo de escolha do novo sistema iniciou-se em dezembro de 1.994, gerenciado
pela equipe de informtica. A equipe consultou empresas existentes no mercado e realizou
uma pr-seleo, utilizando critrios iniciais de atendimento a alguns requisitos bsicos: 1)
que o sistema abrangesse todos os mdulos necessrios; 2) que fosse integrado (isto , que os
mdulos trocassem informaes entre si); 3) que atendesse a requisitos bsicos de funcionamento do mdulo comercial (emisso de notas fiscais, atendimento legislao fiscal); 4) que
utilizasse bancos de dados relacionais e 5) que existissem clientes que pudessem atestar o
funcionamento do pacote. Aps essa pr-seleo, chegou-se a trs pacotes finalistas. Para uma
segunda etapa, foram levantados com os usurios da rea comercial, financeira e fiscal alguns
requisitos considerados fundamentais e foi desenvolvido um novo conjunto de critrios e pesos para a avaliao final. A equipe de informtica e os usurios participaram de apresentaes dos pacotes, aps as quais foram atribudas notas a cada um dos critrios, tanto pelos
usurios como pela equipe de informtica. A escolha final recaiu sobre o Logix, da Logocenter, tendo a deciso sido tomada em maro de 1.995.
Quanto aos usurios da rea comercial, havia uma preocupao em saber se o novo sistema forneceria relatrios semelhantes aos existentes no sistema anterior. A rea financeira
tinha a preocupao em garantir que o processo de cobrana escritural (transferncia eletrnica de documentos de cobrana entre a empresa e os diversos bancos) funcionaria corretamente. Parte dessa preocupao era decorrente do fato de que o sistema de cobrana da KCB j
possua essa funo, enquanto que o novo sistema que estava sendo utilizado pela empresa (o
sistema em UNISYS) no.

214

Aps a deciso pelo Logix, a equipe de projeto enfrentou uma dificuldade adicional. Em
decorrncia da sada do banco de investimentos da empresa houve a troca da presidncia e da
diretoria financeira. Como a empresa ainda estava em seu incio e buscava firmar a sua estabilidade no mercado, outras prioridades de investimentos surgiram e o projeto ficou paralisado por quatro meses. Em julho de 1.995, a nova diretoria financeira aprovou o reincio do
projeto.
A rea de TI
Na criao da empresa, a rea de TI da MP recebeu os profissionais de informtica
oriundos da KCB, que ficaram responsveis pelo BPCS e pelo projeto de substituio dos
sistemas. O suporte aos sistemas da CMSP em mainframe que seriam utilizados at a implementao do sistema ERP ficaram por conta da equipe de informtica da CMSP, que atendia
MP como prestadora de servios. No momento da implementao, a rea de TI da Melhoramentos Papis contava com 7 funcionrios, sendo 3 analistas de sistemas, 2 analistas de suporte, um deles localizado em Mogi das Cruzes, o gerente de informtica e uma estagiria.
Em dezembro de 1.999, a rea contava com 11 pessoas, divididas em 3 analistas de sistemas (uma cuida dos mdulos comercial e contas a receber, outro dos mdulos financeiro e
contabilidade, e uma cuida dos mdulos suprimentos e manufatura), 2 analistas de suporte
(um deles responsvel pelas duas fbricas), um analista de suporte rede, uma analista responsvel pela manuteno do sistema EIS, o gerente de informtica, uma estagiria, um funcionrio terceirizado, e um programador Informix-4GL terceirizado, funcionrio da empresa
fornecedora do pacote. O objetivo deste ltimo desenvolver programas externos adicionais
ligados ao sistema ERP e relatrios.
Existiam 122 usurios acessando o sistema, incluindo o escritrio central, as duas fbricas e quatro filiais de venda. Alm disso, 35 vendedores da diviso consumo enviavam pedidos de clientes utilizando-se de um sistema para digitao e envio de pedidos em palmtops
(computadores portteis) desenvolvido por terceiros.
O Logix era processado em um servidor HP, em sistema operacional HP-UX e utilizava
o banco de dados Informix. O servidor estava localizado no escritrio central e a comunicao
com as fbricas e filiais era feita por meio de LPs dedicadas da Telefonica e da Embratel,
exceo da fbrica de Mogi, que era conectada por meio de uma linha de dados via rdio da
Comsat.

215

Os mdulos implementados
A MP implementou os mdulos comercial (pedidos e faturamento), crdito e cobrana,
suprimentos, contabilidade, custos, contas a pagar, tesouraria, manuteno industrial, recursos
humanos e ativo fixo. Os principais mdulos foram implementados em fases, em duas etapas.
Na primeira etapa, cuja operao iniciou-se em novembro de 1.995, implementaram-se os
mdulos comercial e crdito e cobrana. Na segunda etapa, cuja operao iniciou-se em fevereiro de 1.997, implementaram-se os mdulos de suprimentos, contabilidade, contas a pagar e
custos. Alm destes, outros mdulos foram implementados aps as duas etapas e no intervalo
entre elas, conforme resumido na tabela 3. O nmero de usurios apresentado o nmero
existente no momento do incio da operao e atualmente em cada grupo de mdulos, considerando as duas fbricas, o escritrio central e os escritrios de venda.

Incio Implantao
Jul/1.995

Incio Opera- Qtd. Usurios

o
atual
Nov/1.995
50

Etapa 1
Comercial, Contas a
Receber e Livros fiscais
de sada
Recursos Humanos
Jan/1.995
Fev/1.995
15
Out/1.996
Fev/1.997
40
Etapa 2
Suprimentos, Contas a
pagar, Livros fiscais de
entrada, Contabilidade
Manuteno Industrial
Mar/1.997
Jun/1.997
2
Custos
Jun/1.998
Dez/1.998
2
Tesouraria
Jan/1998
Fev/1.998
2
Ativo Fixo
Jun/1.998
Jul/1.998
1
Manufatura
Dez/1.999
---8
Tabela 3 - Data de Implementao e qtde. de usurios por mdulos
Histrico da Implementao

A metodologia de implementao utilizada foi baseada na metodologia utilizada pela

empresa para implementar o BPCS em 1.992, que sugere a criao de uma equipe de projeto
composta por um diretor de projeto e por elementos que teriam a responsabilidade pela implementao de cada um dos mdulos, chamados de lderes de mdulo. Os lderes de mdulos
seriam pessoas escolhidas nas reas usurias que tivessem grande conhecimento a respeito do
processo e poder de deciso para definir como os processos seriam implementados, e que teriam a responsabilidade de realizar ou coordenar a prototipao dos processos de sua rea no
sistema e em cobrar a participao e o envolvimento dos usurios. Segundo a metodologia,

216

informtica caberia o papel de apoio ao processo de implementao, atendendo s solicitaes dos lderes de mdulos no que se refere s necessidades de treinamento e disponibilizao do ambiente para a prototipao, alm de fazer o intercmbio com o fornecedor no caso
de dvidas, problemas ou necessidades de customizao. Dessa maneira, a metodologia procura deixar claro que o projeto pertence s reas usurias, e no rea de informtica.
A equipe de projeto foi ento montada para a primeira etapa, que envolveria os mdulos
comercial (pedidos e faturamento), contas a receber e livros fiscais. O diretor financeiro assumiu o posto de diretor de projeto e como lderes de mdulos foram chamados o supervisor
das rea de faturamento, o supervisor de administrao de vendas, a supervisora de crdito e
cobrana, o gerente de vendas da diviso de consumo e da diviso institucional e o chefe de
escrita fiscal. Foi realizado um coquetel no incio do projeto com a participao de toda a diretoria da empresa e equipe de projeto com a finalidade de chamar a ateno da empresa sobre
o projeto e envolver os participantes.
Primeira Etapa da Implementao
Na primeira etapa, um dos principais objetivos estabelecidos pela diretoria comercial e
pela gerncia de informtica era a alterao da maneira como era realizado o faturamento da
empresa, aproveitando-se a mudana do sistema. No sistema anterior (da CMSP), o departamento comercial imprimia as notas fiscais de acordo com os pedidos e as encaminhava para a
expedio que manualmente as organizava, definindo os lotes (ou grupos de notas) que seriam
embarcadas nos caminhes. Com a mudana planejada, a responsabilidade pela emisso das
notas fiscais ficaria com a prpria expedio. O sistema distribuiria previamente os pedidos
em lotes de acordo com o destino (endereo de entrega), o prazo de entrega e volume em metros cbicos ocupados, e estes lotes seriam associados aos caminhes pela expedio. O objetivo da mudana era possibilitar um melhor controle e planejamento dos fretes, que tm parte
significativa no custo do produto, pois o papel higinico tem um valor muito baixo por metro
cbico.
Para realizar o processo de distribuio como planejado pela MP, o Logix precisou ser
bastante customizado, sendo necessrias alteraes no processo de impresso de notas fiscais
bem como a criao dos processos de montagem dos lotes de pedidos em caminhes e definio da seqncia de entregas (roteirizao). Em conseqncia disso, o envolvimento e participao dos usurios nessa etapa foi baixo. Como a necessidade de customizao do mdulo
comercial foi alta, o trabalho mais tcnico de anlise de sistemas e programao foi enfatizado

217

nesta etapa e a equipe de informtica tornou-se responsvel pelo projeto, perdendo o seu carter consultivo previsto na metodologia. Durante o trabalho de customizao, testes e migrao de dados, dois analistas do fornecedor ficaram na empresa praticamente em tempo integral. A equipe de informtica realizava os testes e aprovava o funcionamento do sistema.
A implementao da primeira etapa era prevista para ser realizada em trs meses (de
julho de 1.995 a setembro de 1.995, iniciando-se no primeiro dia de outubro), mas momentos
antes do incio da operao do sistema percebeu-se que ainda no havia confiana suficiente
nas customizaes realizadas e havia necessidade de maior treinamento dos usurios nas novas rotinas. O risco de problemas com o faturamento era alto e preferiu-se adiar o incio da
operao por trinta dias. Durante esse ms, os treinamentos e testes foram intensificados e no
primeiro dia de novembro de 1.995 iniciou-se a operao, com aproximadamente 30 usurios,
entre as reas comercial, faturamento e contas a receber.
Como se alterou tanto o sistema como a maneira de trabalhar na expedio, os dois primeiros meses foram um perodo de grandes necessidades de adaptaes, tanto na empresa
como no sistema, e novas customizaes precisaram ser feitas j com o sistema em operao,
o que dificultava as mudanas. Aps esse perodo de dois meses a operao estabilizou-se.
Outro aspecto observado no incio da utilizao foi a necessidade de alterao nos programas de entrada de pedidos para que fosse possvel sua utilizao pela diviso institucional
que trabalhava basicamente por meio de telemarketing, sendo necessrio desenvolver programas distintos para a entrada de pedidos de cada uma das reas. As necessidades de sistema
das duas divises, embora vendam produtos semelhantes, so diferentes em virtude de atenderem a mercados muito diversos. Essas diferenas mostraram-se importantes tambm no que se
refere aos relatrios de vendas e cobrana, e muitos relatrios adicionais precisaram ser desenvolvidos para atender as necessidades da diviso institucional. Quanto digitao de pedidos em si, a supervisora de telemarketing comentou que o sistema implementado melhorou
bastante a rea. Segundo ela, anteriormente os pedidos eram transcritos para tales de pedidos, para serem posteriormente digitados em um setor de digitao. Quando o sistema ERP
foi implementado, as operadoras de telemarketing passaram a digitar os pedidos no momento
da conversa com o cliente, sendo possvel tambm acessar de maneira on-line a uma srie de
informaes.

218

Segunda Etapa da Implementao

A segunda etapa do projeto deveria iniciar-se logo aps o trmino da primeira. Entretanto, por razes econmicas, foi adiada para o segundo semestre de 1.996. A implementao
iniciou-se em outubro de 1.996 e a operao em fevereiro de 1.997.
Na segunda etapa a participao dos usurios foi mais acentuada e decidiu-se utilizar o
sistema com o mnimo de customizao. Ficou para os usurios a responsabilidade de transferir seus processos para o novo sistema, e para a informtica o papel de consultoria e intermediao com o fornecedor do pacote em caso de dvidas, necessidades de treinamento e mesmo
eventuais modificaes. Foi criada a equipe de projeto para a segunda etapa e montada uma
sala no escritrio central em So Paulo onde os lderes de mdulo e usurios recebiam treinamentos e faziam os testes no sistema. Segundo o gerente de planejamento, que participou da
segunda etapa como lder de mdulo da rea de suprimentos, durante o perodo em que foram
realizados os treinamentos e a prototipao foi possvel realizar testes integrados do sistema
por vrias vezes, o que possibilitou que se adquirisse um grande conhecimento sobre as funes principais do sistema. Um dos motivos apontados pelo gerente de informtica para a
maior participao dos usurios nesta etapa e menor participao da rea de informtica o
fato de que a informtica possua um conhecimento menor sobre o funcionamento dos processos de negcio no BPCS, uma vez que a implementao deste sistema havia sido conduzida em grande parte pelos prprios usurios, que assumiram a responsabilidade sobre o processo. J no caso do faturamento e cobrana, a equipe de informtica possua um grau muito
maior de conhecimento do sistema, uma vez que havia sido responsvel pela desenvolvimento
destes sistemas no SID. Segundo o gerente de planejamento, para se obter sucesso em uma
implementao de sistemas ERP a maior responsabilidade est no empenho dos usurios, na
vontade de fazer com que a coisa acontea.
Durante a prototipao, ocorreram algumas dificuldades em parametrizar o sistema tendo em vista a integrao dos mdulos. Um dos problemas foi a definio de um cadastro de
tipos de pagamento que foi cadastrado de maneira diferente no contas a pagar e na contabilidade, criando a dificuldade de conciliar os valores. Segundo o controller, uma das medidas
que poderiam ser tomadas para que problemas desse tipo fossem evitados seria enfatizar a
integrao entre os mdulos durante o processo de prototipao e treinamento dos lderes de
mdulo. Um problema apontado pelo gerente de informtica foi a dificuldade em encontrar
um consultor que possusse uma boa viso geral do funcionamento do pacote, pois na segunda
etapa os mdulos que estavam sendo implementados eram bastante integrados entre si (rece-

219

bimento, estoques, contas a pagar, compras, contabilidade, livros fiscais). O papel desse consultor seria o de homogeneizar o entendimento de todos os participantes a respeito de determinados parmetros e cadastros e dos conceitos envolvidos na obteno de informaes. Com
a ausncia dessa padronizao de conhecimentos, houve alguns problemas decorrentes de
parametrizaes incompatveis que dificultaram a integrao entre os mdulos.
Nos primeiros dias de utilizao dos mdulos da segunda etapa foram percebidos alguns
problemas de treinamento e conhecimento das pessoas. O gerente de planejamento salientou
que durante a prototipao os lderes de mdulo estavam absorvidos pela tarefa de entender o
sistema e de certa forma foi dada menor importncia ao treinamento dos usurios finais, que
efetivamente iriam operar o sistema. Segundo o gerente de informtica, a equipe percebeu que
o treinamento do usurio final um dos aspectos mais importantes da implementao e que
no basta trein-lo nas funes do sistema, mas necessrio transmitir conhecimentos a respeito de como o trabalho em um sistema totalmente integrado.
Um problema apontado pelo gerente de planejamento foi o fato de que, aps 30 dias de
utilizao, descobriu-se que fazia parte dos procedimentos do mdulo de suprimentos a execuo de um processo de encerramento mensal para que os saldos iniciais do ms fossem calculados e passassem a constar dos relatrios. Esse processo era tambm necessrio para que
se pudesse dar continuidade contabilizao e apurao de custos. Apesar de ser necessrio
para o funcionamento do sistema e exigir cuidados nos cadastros de todos os mdulos envolvidos na segunda etapa, o procedimento no foi abordado durante os treinamentos e a prototipao. Houve a necessidade de corrigir os dados do ms que havia passado para que o fechamento fosse possvel, corrigir problemas no cadastro de todos os mdulos e executar as rotinas de fechamento j com o sistema em operao. Segundo o gerente de planejamento responsvel pelo mdulo de suprimentos, foram necessrios 20 dias de dedicao praticamente integral com a participao de um consultor do fornecedor. A normalizao do processo demorou trs meses, e atualmente o procedimento executado em um dia apenas.
Na rea industrial a dificuldade foi maior pois o Logix no estava adaptado a certas caractersticas relacionadas produo da MP e a adaptao do sistema de manufatura (que inclua o MRP) seria muito onerosa e demorada naquele momento. Nesse caso, optou-se por
no implementar o mdulo de manufatura, deixando-o para uma terceira etapa.

220

Resistncias Mudana
Segundo o diretor financeiro, na primeira etapa do projeto as resistncias mudana foram maiores, mas de maneira geral foram resolvidas por meio de conversas e reunies. A
equipe de informtica ajudou nesse processo fazendo um trabalho de esclarecimento das vantagens do novo sistema aos usurios. Houve apenas uma exceo, em uma rea cujo responsvel precisou ser substitudo para que o sistema fosse adequadamente implementado. Na
segunda etapa os problemas foram menores, principalmente em decorrncia das experincias
da primeira etapa e da experincia anterior dos usurios destes mdulos com pacotes (o
BPCS). Mesmo assim, sempre h expectativas a respeito do novo sistema. O gerente de planejamento colocou a questo da seguinte maneira: todo sistema novo uma caixa preta,
voc nunca sabe se ele vai atender a tudo aquilo que voc j tem. A primeira preocupao
dos usurios saber: o sistema vai fazer aquilo que eu fao? ou o sistema ter os relatrios que eu tenho? .
Mudar o Pacote ou a Empresa?
Como citado, na primeira etapa a customizao do mdulo comercial foi bastante intensa. Alm disso, os relatrios de acompanhamento de pedidos e faturamento disponveis eram
inadequados para a realidade da empresa, e tiveram que ser modificados. O mdulo de contas
a receber no sofreu customizaes, mas foi necessrio o desenvolvimento de relatrios de
acompanhamento que considerassem o grande nmero de ttulos existentes na diviso institucional.
Na segunda etapa, procurou-se customizar o sistema o mnimo possvel. Como eram
mdulos mais padronizados essa alternativa foi preferida. Segundo o gerente de planejamento,
a primeira providncia era sempre tentar se adaptar ao sistema para quebrar alguns paradigmas existentes. De maneira geral, segundo o controller e o gerente de planejamento,
estes mdulos foram realmente pouco customizados.
Quando havia a solicitao em se alterar o sistema na segunda etapa, era feito um oramento no fornecedor que era depois submetido aprovao da diretoria do projeto. Aps o
trmino da implementao, o oramento das customizaes posteriores solicitadas pelas reas
usurias deveria ser aprovado pela prpria rea usuria, e as despesas lanadas no centro de
custo da rea solicitante.

221

Utilizao: Benefcios
O principal benefcio obtido pela utilizao do sistema, segundo o diretor financeiro, foi
a unificao da informao da empresa. Segundo o entrevistado, boa parte do tempo em reunies de diretoria era gasto para descobrir de onde cada um dos participantes havia tirado a
informao que estava apresentando, e perdia-se o foco do assunto principal. Com o sistema
unificado, todos tm o mesmo nmero. Segundo todos os entrevistados, o novo sistema trouxe um aumento na confiabilidade das informaes em relao ao sistema anterior. Para o diretor financeiro ainda, o sistema ERP trouxe uma maior transparncia para as informaes da
empresa. De acordo com ele, o sistema integrado democrtico, e elimina os feudos de
informao. Toda a informao est no sistema, e ele operado por todo mundo. Coloca-se
um fluido na engrenagem de comunicao da empresa
O controller apontou a eliminao da necessidade de digitao na contabilidade como
um benefcio do sistema. O tempo necessrio para o fechamento da contabilidade foi reduzido
de 12 dias, em um ritmo muito intenso, para 8 dias em ritmo normal de trabalho. Alm disso
salientou como benefcios a integrao do sistema de folha de pagamento e do faturamento
com a contabilidade, que no existiam no sistema anterior (tanto da KCB como no incio da
MP).
Segundo o gerente de planejamento, uma das motivaes para a mudana para o Logix
foi partir de um sistema que no fornecia informaes suficientes para um que passaria a
fornecer uma srie de relatrios. Segundo ele, o grande benefcio do Logix foi a disponibilizao de informaes on-line, isto , no momento em que so inseridas no sistema, o que no
era possvel no sistema anterior, e a facilidade de obteno de informaes, seja nas telas disponveis ou pelo desenvolvimento de novos relatrios.
O gerente de planejamento tambm citou o fato de que relatrios que haviam sido desenvolvidos para outros clientes do fornecedor puderam ser aproveitados pela MP, mudando-se
a maneira da empresa trabalhar, com benefcios para o controle dos procedimentos.
Um benefcio adicional que no era esperado foi percebido pelo diretor financeiro. Segundo ele, a implementao do sistema ERP auxiliou na unificao das duas culturas existentes na empresa, facilitando a criao de uma cultura prpria da MP. Isso foi conseqncia
tanto da padronizao das informaes e procedimentos (todos usando um mesmo sistema),
como resultado do prprio processo de implementao, quando as pessoas se integraram e
trabalharam juntas para atingir um objetivo comum. O fato de implementar um sistema novo,

222

diferente dos dois anteriores, tambm colaborou para que ningum se sentisse inferiorizado,
ou como sendo obrigado a aceitar o sistema do outro.
Houve reduo de aproximadamente 50% nos custos de informtica, principalmente em
decorrncia da descontinuao do pagamento da taxa de manuteno do mainframe para a
CMSP .
A Implementao por Fases e a Apurao de Custos
Uma das dificuldades na utilizao do sistema na MP est na obteno da apurao de
custos da maneira requerida pela empresa, isto , dividindo-se os custos por rea de negcio
para que a rentabilidade de cada uma das divises (consumo, institucional, semi-acabados e
pasta termomecnica) possa ser controlada. Atualmente a diviso feita utilizando-se de critrios de rateio, em planilhas eletrnicas. Alm do trabalho manual, o controller salienta que, ao
dividir as despesas por critrios de rateio, torna-se mais difcil a cobrana de resultados dos
responsveis pelas reas de negcio, porque a utilizao desses critrios no exata e despesas realizadas por uma rea de negcio podem eventualmente ser alocadas em outra.
Segundo o controller, para que fosse possvel a apurao de custos da maneira correta
primeiro deveriam ter sido implementados os mdulos de entrada (suprimentos e manufatura)
para que depois se implementassem os mdulos de sada, pois um sistema ERP comea pela
produo, para depois chegar s vendas. Segundo ele, uma das dificuldades da implementao foi a ausncia de uma definio, logo no incio do projeto, de que tipo de informaes a
diretoria queria receber. O gerente de informtica tambm entende que o fato de a implementao no ter se iniciado pelo mdulo de manufatura trouxe dificuldades adicionais.
Segundo o controller, um sistema ERP deve ser implementado em fases, mas importante o planejamento da seqncia das etapas. Ele entende que em parte o planejamento no
foi inteiramente realizado devido grande presso pelo tempo, pois havia a necessidade urgente de substituir os sistemas existentes. Outra dificuldade apontada pelo controller foi o fato
de que a implementao do sistema ocorreu simultaneamente ao processo de aquisio e juno das empresas e conseqentes mudanas de diretoria, o que tornou mais difcil um planejamento prvio das necessidades de informao da empresa.
Um dos problemas associados separao em etapas foi a realizao dos cadastros dos
produtos na primeira etapa, levando em considerao apenas requisitos da rea comercial, j
que era esse o foco da implementao na primeira etapa. Na segunda etapa do projeto, descobriu-se que a diviso de produtos em unidades de negcio foi feita de maneira inadequada

223

para a apurao do custo da maneira desejada pela empresa. Segundo o controller, uma das
alternativas para minimizar esse problema teria sido um maior questionamento do fornecedor
pela equipe de implementao sobre as implicaes dos cadastros que estavam sendo feitos na
primeira etapa nos demais mdulos do sistema, quando estes fossem implementados.
Segundo o gerente de informtica, como decorrncia do grande espao de tempo entre
as etapas (um total de 11 meses), a dificuldade em corrigir os problemas citados e se integrar
adequadamente os mdulos da primeira e da segunda etapa foi aumentada. Segundo ele, os
problemas de parametrizao dos mdulos comercial e contas a receber relativos integrao
com os mdulos da segunda etapa (manufatura, custos e contabilidade) poderiam ter sido solucionados mais facilmente se a segunda etapa tivesse se iniciado mais cedo, porque as alteraes nos parmetros teriam sido realizadas enquanto o sistema comercial ainda estava se estabilizando, e uma srie de relatrios e mdulos-satlite (tais como o EIS) ainda no teriam
sido desenvolvidos.
Utilizao: Problemas
Segundo o diretor financeiro, uma das desvantagens de utilizar um sistema de terceiros
que existe menor flexibilidade para negociao de novos desenvolvimentos. Quando h a
necessidade de um desenvolvimento, a solicitao entra na ordem de prioridade do fornecedor, que nem sempre a nossa prioridade. Segundo ele, com um sistema desenvolvido por
uma equipe interna, a vantagem que a prioridade dos novos desenvolvimentos ditada exclusivamente pelas necessidades da empresa.
Depois da implementao, houve um processo de estudo da rea de logstica que culminou na terceirizao da rea. Entretanto, verificou-se que o nvel de detalhe dos relatrios para
controle de fretes disponveis no sistema eram insuficientes e houve a necessidade de se realizar uma customizao. O mdulo foi comprado em conjunto com os demais mdulos do Logix, e segundo o diretor dentro do Logix havia um mdulo que no satisfazia as necessidades da gerncia. No foi um problema de implantao, mas o mdulo oferecia um nvel de
detalhe insuficiente.
Segundo o diretor financeiro e o controller, o sistema no fornece os relatrios gerenciais necessrios. Para o controller, as informaes esto no sistema, mas necessrios agreglas em planilhas eletrnicas. Para disponibilizar informaes gerenciais, a MP desenvolveu
um sistema EIS, baseado na linguagem Pilot Lightship. Segundo o diretor financeiro, o des-

224

envolvimento do EIS foi facilitado pelo sistema ERP, uma vez que toda a informao da empresa encontra-se em um nico banco de dados.
O Relatrio de Vendas
Um exemplo dos possveis problemas associados customizao de sistemas ERP pde
ser observado no caso da MP. Com a finalidade de facilitar a implementao do mdulo comercial, foi desenvolvido um relatrio para a rea de vendas que replicava as mesmas informaes de um relatrio existente no sistema anterior, considerado o mais importante pelos
usurios da rea. O relatrio foi desenvolvido, mas como os conceitos que definiam as informaes eram diferentes dos utilizados pelo Logix, foi necessrio o desenvolvimento de um
mdulo-satlite para acumular os dados e gerar o relatrio. Tambm foi necessrio criar
uma srie de parmetros para definir quais informaes seriam extradas do Logix para esse
relatrio, e de que maneira seriam agrupadas. Como resultado dessa complexidade, foram
necessrios alguns meses para que o relatrio se ajustasse. Aps o ajuste, quando havia alteraes no Logix, era geralmente necessrio rever os programas que geravam o relatrio, pois
seus resultados no coincidiam mais com o de outros relatrios do Logix. Durante os trs
primeiros anos (de 1.995 at 1.998), esse relatrio foi utilizado, mas, em 1.999, ele foi totalmente refeito, com base nos conceitos do prprio Logix, procurando-se, desta maneira, eliminar as dificuldades de manuteno.
O desenvolvimento desse relatrio representa um outro aspecto importante em uma mudana de sistemas. Segundo o gerente de informtica na poca da implementao, em um processo de mudana, na fase de implementao necessrio oferecer s pessoas algum porto
seguro em qual elas possam se apoiar. Segundo ele, esse porto seguro so informaes
que representem conceitos j estabelecidos e que sejam apresentadas da maneira com a qual
as pessoas esto acostumadas, e por isso o desenvolvimento do relatrio solicitado pela rea
comercial era importante. Se a informao mudada o usurio perde seu histrico de comparao, isto , a maneira pela qual ele avaliava o desempenho de seu departamento ou da
empresa. O desenvolvimento de relatrios semelhantes aos existentes em sistemas anteriores
um preo [decorrente de esforos e custos de customizao e manuteno] que deve ser
pago para que se viabilize a implementao de um novo sistema. Sem esse desenvolvimento,
a implementao pode se tornar mais difcil e desgastante devido maior resistncia por parte
dos usurios.

225

Integrao
A integrao entre os mdulos no foi citada espontaneamente como benefcio. Quando
perguntado a esse respeito, o gerente de planejamento disse que o benefcio foi a eliminao
da necessidade de retrabalho (digitar a mesma informao em diversos sistemas), necessria
no sistema anterior. Segundo ele, apesar do fato de que se a informao for digitada incorretamente o erro ser transmitido aos demais mdulos, o sistema fornece as ferramentas necessrias para que se localizem erros ou problemas. (O Logix no integrado on-line e no utiliza um modelo de dados corporativo como o R/3. Apesar de ser integrado, isto , a mesma
informao alimenta toda a empresa. estas so transmitidas entre os mdulos de maneira
batch, em processos de integrao, isto , programas que buscam dados de um mdulo e o
inserem em outro). O controller citou a eliminao da necessidade de digitao como benefcio em sua rea.
ERP e desempenho / competitividade
Segundo o diretor de informtica, o desempenho da rea de logstica melhorou bastante,
porque o sistema anterior era muito ineficiente e manual. Embora no possa ser creditado exclusivamente ao novo sistema, pois houve a terceirizao completa da rea, a empresa tem
economizado cerca de US$ 2 milhes por ano nesta rea.
Segundo o gerente de planejamento, o sistema permitiu a reduo dos nveis de estoques
de matrias primas e materiais de reposio, por disponibilizar melhores ferramentas para
controle. Um exemplo citado a possibilidade de cadastrar-se a poltica do item, isto ,
estoque mnimo e lote de reposio, deixando o gerenciamento do estoque para o sistema. O
entrevistado acrescentou que isso economizou tempo do ser humano e reduziu os excessos de
estoque, porque quando o ser humano comprava, sempre havia a preocupao de que o que
estava sendo solicitado podia no ser suficiente. Com o sistema, o ser humano passa a analisar o que o sistema est fazendo.
O controller acha que o sistema no trouxe novidades para os processo da rea, mas relaciona o uso do sistema melhoria do controle interno dos procedimentos. Segundo ele, o
objetivo do sistema eliminar os controles manuais, passando-os para o prprio sistema.
Quanto melhoria do desempenho de sua rea, ele acredita que com a menor necessidade de
trabalho operacional (digitao e verificao), h maior espao para que a controladoria efetivamente trabalhe na anlise dos resultados. Segundo ele, isso s no foi plenamente obtido,

226

pois o mdulo de manufatura ainda no foi completamente implementado, e ainda h a necessidade de lanamentos manuais.
O plano de participao nos resultados
Um aspecto interessante citado pelo controller foi o efeito das reunies de resultado e do
plano de participao nos resultados (PPR) implementado pela empresa. Desde 1.994 a empresa tem feito um plano anual de bonificao de funcionrios com base em indicadores negociados entre os funcionrios e a diretoria da empresa. Os indicadores so relativos ao faturamento da empresa, rentabilidade e a ndices operacionais de cada rea, quando possvel,
tais como rendimento de mquinas, refugo, etc. As gerncias de produo das fbricas de Caieiras e Mogi das Cruzes realizam reunies mensais para acompanhamento dos indicadores,
com a participao de todos os supervisores e alguns funcionrios dos diversos departamentos
das fbricas. Cada rea deve apresentar os seus resultados, frente aos objetivos definidos no
PPR. Com a necessidade de acompanhar as metas para garantir o melhor resultado no PPR,
todos se interessaram por aperfeioar e entender como o sistema de informao funciona. Segundo o controller, a partir deste momento os usurios comearam a perceber a importncia
da correta entrada de dados, e muitos erros puderam ser corrigidos.
Integrao com outros sistemas
O Logix cobre praticamente todas as necessidades de sistemas da MP, mas esto integrados a ele um sistema de recepo de informaes dos relgios de ponto eletrnicos e um
sistema para recepo dos pedidos enviados pelos vendedores por meio de palmtops. O primeiro um pacote fornecido pelos fabricantes do relgio de ponto eletrnico e o segundo foi
desenvolvido por terceiros sob medida para a MP.
Outros Comentrios dos Entrevistados
Sobre o tempo necessrio para a implementao: Numa implementao de sistema, o
tempo e deve ser curto. Curto, porm suficiente para voc entender o pacote. No se pode
ficar navegando no sistema por um ou dois anos com receio de implementar. Depois de
implementado o pacote, medida que forem surgindo as necessidades do dia-a-dia, voc
busca uma soluo. Se voc for esperar resolver todas as suas dificuldades antes de implementar, voc vai encontrar novas necessidades quando iniciar a operao do sistema, porque
as necessidades evoluem, assim como a empresa e o mercado

227

Sobre os benefcios nos departamentos: Em alguns departamentos houve mais melhorias, pois alguns no exploram muito o sistema, e isto est ligado pessoa que est utilizando.
Consideraes sobre o Caso
Destaques do Caso
Nesse caso interessante observar um possvel risco que pode ser trazido pela implementao de sistemas ERP em fases: a configurao dos mdulos iniciais sem que se leve em
considerao as necessidades dos ltimos mdulos, ou a viso total do projeto. Mesmo com
um planejamento inicial, a ateno da empresa estar voltada quelas reas que esto implementando os mdulos daquela etapa, e possvel que as prioridades destas reas sejam enfatizadas em prejuzo do todo. Tambm pde-se perceber como o planejamento de uma implementao de sistemas est bastante ligado a fatores contingenciais. A necessidade urgente de
substituio do sistema comercial fez com que a implementao se iniciasse por esse mdulo,
o que poderia no ser o ideal, segundo os entrevistados. Outra influncia do contexto foi a
imposio de um grande intervalo de tempo entre as duas etapas da implementao, o que fez
com que o processo de integrao final entre os mdulos de cada uma delas se tornasse mais
difcil e trabalhoso.
Outro destaque do caso o papel que o sistema ERP teve na criao de uma cultura empresarial para a nova empresa, facilitando a unio das equipes vindas das duas empresas originais. Foi possvel perceber que um sistema ERP, por sua abrangncia e integrao, pode
exercer influncia na maneira como so feitas as coisas simultaneamente em vrias partes
das organizaes onde so implementados. Schein (1992) define cultura organizacional a partir do pressuposto de que toda organizao deve lidar com dois tipos de problemas para sobreviver e prosperar: a adaptao ao meio externo e a integrao interna. A partir da, o autor
define cultura organizacional como o conjunto de pressupostos bsicos, compartilhados pelos
membros da organizao, aprendidos por estes membros medida que o grupo vai resolvendo
tais problemas, e que funcionaram suficientemente bem para serem considerados vlidos e
perpetuados. importante notar tambm que a viso de Schein (1992) entende a cultura das
empresas como um processo de aprendizagem. Entretanto, apesar dessa possibilidade unificadora dos sistemas ERP, pde-se perceber, no caso, dificuldades relacionadas ao uso do mesmo sistema para atender a duas reas distintas, que possuem processos de negcio e modos de
comercializao de seus produtos diferentes. Alm da influncia do sistema na empresa, tam-

228

bm pde-se perceber como aspectos presentes na organizao, tal como o PPR, podem incentivar os usurios a colaborarem no sentido de melhorar o sistema de informaes da empresa.
Outro destaque a diferena na orientao da equipe de informtica na conduo das
duas etapas, sendo a primeira conduzida mais fortemente pela TI e a segunda mais fortemente
pelos usurios. Entre os fatores que justificaram, ou possibilitaram, essa diferena neste caso
esto o maior conhecimento que a rea de informtica tinha a respeito dos mdulos implementados na primeira etapa, bem como a viso dos usurios dessa etapa quanto ao seu papel
no processo. Na segunda etapa, a informtica possua menores conhecimentos a respeito dos
mdulos que estavam sendo implementados e os usurios j tinham participado de um projeto
de implementao de pacotes, no qual receberam grande parte da responsabilidade por sua
conduo. Quanto resistncia dos usurios, o fato de ela ter sido maior na primeira etapa
pode estar relacionada tanto aos fatos citados (orientao da equipe de informtica e experincia anterior) como ao fato de que, nesta etapa, foram substitudos sistemas desenvolvidos internamente, enquanto que, na segunda etapa, o sistema ERP substituiu um outro pacote comercial. Assim como no caso da Zeneca, foi verificada menor resistncia em usurios que j
se utilizavam de pacotes. A necessidade de criao de um novo relatrio, espelhando um j
existente no sistema anterior, destacou-se no caso como maneira de lidar com a resistncia
dos usurios.
Principais Aspectos Presentes no Modelo Inicial
A dificuldade para obteno de alteraes nos programas-padro do sistema ERP e definio das prioridades para desenvolvimentos pelo fornecedor foi verificada nesse caso (em
contraste ao observado na AgroLaranja). Na segunda etapa, foi constatada a dificuldade de
parametrizao do sistema tendo em vista a integrao dos mdulos.
Novos Aspectos que Podem ser Incorporados ao Modelo Inicial
Novamente foram percebidos problemas no treinamento dos usurios finais, excesso de
dvidas e dificuldades nos momentos inicias da operao. Tambm, novamente, a carncia de
relatrios gerenciais foi destacada, bem como as dificuldades dos consultores em fornecer as
informaes necessrias durante o processo de implementao.
A diferena entre a opinio dos entrevistados da rea de controladoria e da rea de planejamento quanto aos benefcios do sistema, pode estar associada diferena de opinio sobre

229

o sistema anterior, o que reforaria a idia de que os benefcios dos sistemas ERP (ou de
quaisquer sistemas de informao) esto bastante associados situao anterior e aos problemas que se supunha que os novos sistemas resolvessem.

230

CAPTULO 7
CONCLUSES E RECOMENDAES
Tendo descrito oito casos de implementao de sistemas ERP em empresas de So
Paulo, acredita-se ter sido atingido o objetivo principal deste trabalho, enunciado como descrever e analisar como ocorrem os processos de deciso, seleo e implementao e utilizao de sistemas ERP, verificando, nas empresas pesquisadas, quais benefcios e dificuldades
ocorreram, como e porque ocorreram, buscando contribuir para o delineamento de um modelo terico que relacione estes benefcios e dificuldades s caractersticas dos sistemas ERP
e ao contexto onde esses sistemas esto inseridos.
Como j se havia colocado no captulo Metodologia, o primeiro objetivo especfico de identificar um referencial terico inicial para guiar a realizao do estudo emprico foi alcanado com o levantamento da literatura e apresentado nos captulos 3 e 4. Acredita-se que os resultados do estudo emprico realizado, apresentados no captulo 6, tenham permitido alcanar
o objetivo de verificar e descrever como ocorreram os processos de deciso, seleo e implementao do sistema ERP nas empresas pesquisadas, quais so e como esto sendo obtidos os benefcios, quais so e porque ocorrem dificuldades com a utilizao de sistemas ERP
nessas empresas. Esses achados permitem algumas consideraes que levam ao terceiro
objetivo, proposto como identificar possveis causas e relaes dos benefcios e problemas
apresentados pela utilizao de sistemas ERP, com suas caractersticas, com os processos de
seleo e implementao e com o contexto das empresas.
A seguir sero apresentadas as concluses gerais deste trabalho. A anlise do modelo de
ciclo de vida de sistemas ERP e dos benefcios e dificuldades destes ser dividida em itens,
representando os aspectos verificados nos casos.
7.1 Ciclo de Vida de Sistemas ERP
O Modelo de Lewin Aplicado aos Sistemas ERP
Muitos dos aspectos observados nos casos podem ser analisados por meio do modelo de
Lewin, apresentado por Laudon e Laudon (1996). Esse modelo explica como ocorrem resistncias a mudanas em grupos ou organizaes, utilizando os conceitos de descongelamento,
mudana e recongelamento. Segundo o modelo de Lewin, nos grupos ou organizaes existe
um equilbrio dinmico entre diversas foras presentes, parte delas exercendo influncias a

231

favor de mudanas, parte delas a favor da manuteno da situao. O modelo recomenda que,
quando se deseja realizar uma mudana em uma determinada situao organizacional (a implementao de um novo sistema, por exemplo), seja realizado um descongelamento da
situao inicial, estimulando as foras favorveis mudana e inibindo as contrrias. Assim,
um novo ponto de equilbrio obtido e a mudana facilitada. Aps o descongelamento, fazse a mudana e, ao final dela, necessrio que se recongele a nova situao, estabelecendo
a ao de novas foras ou consolidando o novo balano de foras obtido, de maneira que se
impea que a situao volte ao estado anterior. Laudon e Laudon (1996) apresentam como
objetivos de cada uma das etapas, a criao de um clima de mudana, no descongelamento,
a anlise e desenho da soluo, na mudana, e a institucionalizao da soluo adotada, no
recongelamento.
Nas etapas de implementao e incio da operao, que podem ser associadas ao descongelamento e mudana no modelo de Lewin, foi verificada a existncia de resistncia por
parte dos usurios quanto ao novo sistema e dificuldades na obteno de seu comprometimento. Como medidas tomadas pelas empresas para a diminuio dessas foras contrrias
mudana, foram observadas a realizao de reunies e palestras de conscientizao, a execuo de customizaes como solicitadas pelos usurios (principalmente relatrios) e, como na
Bosch e Melhoramentos, a ao explcita da alta direo. Destacou-se, na Santista, a presena
de um gerente de recursos humanos na equipe de projetos com a funo especfica de realizar
a conscientizao dos usurios para a mudana que estava ocorrendo. A incluso de um plano
de incentivos, baseado no sucesso do projeto, tambm se destacou nessa empresa, bem como
a utilizao de um gerador de relatrios para agilizar a criao de programas externos e diminuir as resistncias dos usurios na implementao.
Aps o incio da operao e a introduo do novo sistema, h a necessidade de se manter o novo equilbrio de foras, que permita a continuidade do sistema. Nesse aspecto, o modo
de incio de operao em big-bang foi verificado como sendo um poderoso recongelante
pelas empresas que dele se utilizaram, uma vez que, iniciando-se a utilizao do sistema dessa
maneira, h praticamente um consenso na empresa de que no h possibilidade de voltar ao
sistema anterior. A possibilidade de paralisar a operao da empresa se os problemas iniciais
no forem vencidos exerce uma grande fora favorvel mudana.
Outro aspecto interessante, verificado nos casos, foi o aproveitamento de uma janela de
oportunidade criada pela implementao dos sistemas ERP para a incluso de alteraes nos
processos que j haviam sido planejadas anteriormente mas no haviam sido implementadas,

232

muitas vezes por falta de condies de realizao da mudana. Exemplos dessas alteraes
so a modificao do faturamento na Melhoramentos, a utilizao das ordens de produo
repetitivas na Bosch, a descentralizao do controle de horrios na AgroLaranja, e mesmo
modificaes menores como a mudana de planos de contas, na Zeneca e na Rhodia. Tambm
verificou-se que, algum tempo aps o incio da operao, tornou-se mais difcil a implementao de algumas customizaes ou mdulos deixados para depois da etapa de implementao,
ou mesmo novos mdulos que no estavam includos nos planos ou melhorias no sistema
ERP, o que novamente caracteriza o recongelamento da situao. Essa dificuldade foi associada s mudanas de prioridades da empresa e da rea de informtica, o surgimento de novos
projetos e a dificuldade em reunir novamente todos os departamentos ou usurios que seriam
necessrios para a implementao das mudanas desejadas.
Isso traz algumas dificuldades para a realizao da etapa de adaptao contnua como
apresentado por Orlikovski e Hofman (1997). Embora claramente, de acordo com o modelo
das autoras, o conhecimento das possibilidades dos sistemas ERP e da funcionalidade dos
pacotes especficos s seja consolidada aps o incio da operao, verificou-se que as empresas encontram dificuldades para implementar as novas idias surgidas. Uma possvel explicao para essa discrepncia relativa ao fato de que o caso analisado pelas autoras tratava de
um sistema de computao colaborativa, que, embora de grande importncia para a empresa
em estudo, possua menor abrangncia funcional do que um sistema ERP. possvel que a
evoluo dos sistemas integrados nas empresas, em decorrncia de sua abrangncia e impacto
na organizao, seja menos flexvel nesse aspecto. Embora boas idias surjam aps o incio da
operao, quando elas exigem a participao de mais do que um departamento para que sejam
implementadas necessrio muitas vezes que haja novas janelas de oportunidades, ou concentrao e direcionamento de esforos por parte da empresa. Uma das janelas de oportunidade verificadas em dois casos, e que ser detalhada adiante, a atualizao de verses dos
pacotes.
Curiosamente, em um artigo anterior de uma das autoras (Tyre e Orlikowski, 1993),
apresentado um modelo de introduo de novas tecnologias de processo e sua evoluo em
empresas. Embora o estudo no tratasse de tecnologias de informao, o modelo apresentado
parece bastante apropriado. Segundo esse modelo, a evoluo de tecnologias introduzidas em
uma empresa se d por um padro episdico, no qual existem perodos onde a atividade
voltada adaptao das novas tecnologias tem sua intensidade aumentada, como mostrado na
figura 14.

233

Alto

Nvel da
Atividade
Adaptativa

Baixo

t
Figura 14 Padro episdico para a adaptao de tecnologias Extrado de Tyre e Orlikowsky (1993)

Tipos de Customizao
No estudo dos casos, pde-se observar que h diferentes maneiras de se efetuar a customizao do sistema ERP. A primeira pela modificao dos programas-padro do pacote,
sendo essa a alternativa menos preferida e muitas vezes sendo mesmo proibida pelo fornecedor. No caso da AgroLaranja, em contraste com os demais casos, foi possvel a negociao
com o fornecedor da incluso de diversas solicitaes nos programas-padro, o que bastante
confortvel para a empresa cliente.
A segunda opo a criao de programas externos, desenvolvidos na mesma linguagem de programao do que o sistema ERP que so executados a partir de pontos especficos
dos programas-padro. Essa a alternativa mais utilizada, em todos os casos. Quando os programas externos so desenvolvidos para desempenhar tarefas com maior complexidade e
abrangncia, podem ser considerados como mdulos-satlite, sendo essa a terceira opo
para a customizao verificada nos casos. H ainda a possibilidade de desenvolver programas
externos em outras linguagens de programao, ou por meio de geradores de relatrios, ou a
utilizao de pacotes de outros fornecedores utilizando os dados dos sistemas ERP. Essas duas alternativas tambm esto sujeitas s mesmas dificuldades dos demais tipos de customizao, uma vez que alteraes no sistema ERP podem inviabilizar os relatrios desenvolvidos e
a interface de troca de dados com os pacotes externos.

234

O Grau de Customizao, Antes e Depois do Incio da Operao

Em todas as empresas foi enfrentado o dilema das customizaes. Na maioria delas,
optou-se pela sua limitao at a etapa de utilizao, havendo mesmo, em trs casos (Vine,
CNT/VMM e na implementao do PACOTE A, na Zeneca) grande esforo em mant-la no
menor grau possvel. No outro extremo, esto os casos da primeira planta da Bosch, onde procurou-se customizar o necessrio para manter o pacote o mais prximo possvel do sistema
anterior, e a primeira etapa da Melhoramentos Papeis, onde buscou-se adaptar completamente
o sistema ao novo modelo de faturamento planejado pela empresa.
Diversos fatores interagiram durante a etapa de implementao para a definio do grau
de customizao do pacote antes do incio da operao. Entre esses fatores esto a diretriz
inicial do projeto, seu respaldo por parte da alta administrao, o prazo definido para o incio
da operao, a impossibilidade do adiamento desse prazo e a presso exercida pelos usurios.
No caso da Vine e da Rhodia, as presses sobre o prazo de implementao resultaram em
cortes nas customizaes antes do incio da operao. No caso da VMM, a diretriz era decorrente do pressuposto de que as customizaes seriam mais adequadas se realizadas aps o
incio da operao, havendo grande respaldo por parte da diretoria para essa determinao.
Nesses casos, entretanto, foram verificadas algumas dificuldades relativas a essa orientao,
tal como a resistncia dos usurios nos momentos iniciais da operao e a percepo de que
seu trabalho aumentou. J no caso da primeira planta da Bosch, o excesso de customizaes
gerado pela diretriz de adaptar totalmente o pacote terminou por prejudicar o prazo de implementao, atrasando-o em 4 meses. O fato de que a customizao excessiva tenha suas desvantagens, e de que a regra muito estrita de no se customizar antes da operao tambm leve
a dificuldades no incio da operao sugerem a existncia de um ponto de equilbrio para as
customizaes nessa etapa.
Aps o incio da operao, na etapa de estabilizao, verificou-se, o aumento da quantidade de customizaes, seja por meio da construo de programas externos, alterao de programas-padro ou desenvolvimento de mdulos-satlite, sendo as sucessivas plantas da Bosch
a exceo a essa regra. A figura 14 representa o grau de customizao com base nas estimativas feitas pelos entrevistados e nas informaes verificadas nos casos, antes e depois do incio
das operaes.
Como pode-se perceber na figura, h no conjunto dos casos estudados uma tendncia no
sentido do aumento das customizaes, aps o incio da operao, o que era de certa maneira
esperado. Aps o incio da operao, com as dificuldades do dia-a-dia, aumentam as presses

235

dos usurios pela customizao, ao mesmo tempo em que a equipe de projeto perde parte de
sua importncia e visibilidade dentro da empresa. Isso ocorre, apesar de que a noo de que o
aumento da quantidade de customizaes traz mais custos e dificuldades foi observada no s
entre os entrevistados da rea de informtica, mas tambm entre os usurios. Isso suscita
questes a respeito da utilizao de sistemas ERP em um prazo mais longo ou sobre as atualizaes de verso, que em princpio se tornariam mais difceis. Entretanto, nos casos estudados
no puderam ser observados os efeitos de uma atualizao de verso, para verificar se ela se
torna mais difcil em empresas onde o pacote est mais customizado e mesmo se as novas
funcionalidades disponveis na verso no permitem a reduo do grau de customizao do
pacote.

Maior

Bosch
Melhoramentos
AgroLaranja

Grau de
Customizao

Zeneca
Rhodia
Santista

Vine Melhoramentos
AgroLaranja
Santista
Bosch Zeneca
Rhodia
CNT/VMM

Menor

CNT/VMM
Vine
Implementao

Utilizao

Figura 15 Evoluo Aproximada do Grau de Customizao aps o Incio da Operao

Elaborada pelo Autor
Tambm no foi possvel verificar, nos casos estudados, se as diferentes orientaes iniciais quanto s customizaes influenciaram na qualidade das mesmas, como sugerido na
CNT/VMM. Essa suposio est de acordo com as consideraes de Orlikovski e Hofman
(1997), mas, como citado anteriormente, pode ser mais difcil implementar as modificaes
necessrias uma vez iniciada a operao do sistema.
Consultoria
Algumas dificuldades relativas participao dos consultores nos processos de implementao ficaram bastante evidentes nos casos. Embora uma das recomendaes da literatura

236

seja a utilizao de consultoria, e ela efetivamente tenha sido utilizada em maior ou menor
grau em todos os casos, foram apontados problemas relacionados falta de conhecimento dos
consultores, tanto nos pacotes estrangeiros como nos nacionais. Nos pacotes estrangeiros,
naquelas empresas que os implementaram mais cedo, a inexperincia foi associada ao curto
tempo de presena dos produtos no mercado nacional. Nos pacotes nacionais, os problemas
foram associados s diferenas de conhecimento entre os consultores empregados para gerenciar os projetos e aqueles utilizados na sua execuo (parametrizao, customizao e treinamentos). Alm desse problema, apresentou-se outra questo: a dificuldade dos consultores em
compreender particularidades dos processos das empresas. Segundo Soh, Kien e Tay-Yap
(2000), os trs diferentes grupos envolvidos na implementao so os usurios-chave, a
equipe de TI e os consultores do fornecedor, cada um com seus conhecimentos especficos
(processos de negcio, arquitetura dos sistemas anteriores e funcionalidades do pacote, respectivamente), e h dificuldade de transferir esses conhecimentos de um grupo para o outro.
Verificou-se tambm que, aps o incio da utilizao do sistema ERP na empresa, os
conhecimentos dos consultores vo se tornando mais e mais insuficientes para o atendimento
das novas dvidas que vo surgindo, uma vez que elas vo se tornando cada vez mais especficas daquela empresa.
Os Modos de Incio de Operao
Os diversos casos apresentaram a oportunidade para a comparao dos diferentes modos
de incio de operao para o sistema ERP citados na literatura. Como pde-se observar na
prtica dos projetos, os diferentes modelos so combinados (como, por exemplo, na Bosch,
que combinou small-bangs com a implementao em fases de mdulos que atenderiam a reas centralizadas), de acordo com necessidades ditadas por: situao dos sistemas anteriores,
prazo para o trmino do projeto, disponibilidade financeira, abrangncia geogrfica da empresa e nmero de divises da empresa. Embora no tenha sido possvel estabelecer uma regra a
respeito do modelo escolhido, verificou-se que o big-bang foi utilizado nas empresas menores
ou onde havia restries de prazo bastante claras. Nas empresas maiores, a implementao em
fases teve preferncia (na Santista, por exemplo, o big-bang foi considerado uma impossibilidade). A VMM, embora possusse um grande nmero de plantas e se tratasse de um grupo de
empresas, utilizou um modelo que combinou dois small-bangs simultneos. possvel que a
escolha do modo de operao tambm esteja associada maneira como a empresa e a equipe
de projeto lidam com riscos, mas isso no foi observado nos casos.

237

A anlise dos diferentes modos de incio de operao empregados permitiu observar que
possvel a sua classificao segundo dois tipos de abrangncia, a funcional e a geogrfica,
formando um modelo para facilitar a compreenso dos riscos envolvidos em cada um dos
modos. A abrangncia funcional relaciona-se quantidade de mdulos que so implementados simultaneamente, enquanto a abrangncia geogrfica est ligada ao nmero de localidades
onde o sistema inicia a sua operao em um mesmo momento. A Vine e a Melhoramentos,
por exemplo, implementaram o sistema ERP em duas grandes etapas, cada uma com um certo
nmero de mdulos, o que caracterizou seu modo de incio de operao como intermedirio
entre a implementao por fases e o big-bang. A Santista, por sua vez, implementou um
mesmo mdulo simultaneamente em todas as 21 localidades (o mdulo financeiro), caracterizando uma implementao em fases, mas, com um maior risco associado justamente abrangncia geogrfica. A figura 16 resume essas informaes e posiciona as empresas dentro da
abordagem escolhida. A seta no centro da figura representa a direo em que cresce o risco
normalmente associado s implementaes com maior abrangncia, o de interrupo das atividades da empresa.

Em Fases
Todos
as Localidades
Simultaneamente

Melhoramentos

Vine

Zeneca
Rhodia
Big-bang

Abrangncia
Geogrfica

Planta a
Planta

Santista

AgroLaranja
Mdulo a
Mdulo

CNT/VMM
Risco de
Interrupo
das Operaes

Smallbangs

Bosch
Abrangncia Funcional

Todos os
Mdulos
Simultaneamente

Figura 16 Modos de Incio de Operao, por Abrangncia Geogrfica e Funcional Elaborada pelo Autor

238

Os casos tambm permitiram que se verificassem outros riscos e vantagens associados a

cada um dos modos de incio de operao. Na literatura, o big-bang foi considerado como
arriscado, enquanto que a implementao em fases foi considerada com poucos riscos associados, mas, nos casos foram observados algumas vantagens e riscos adicionais de cada um dos
modelos. O quadro 10 resume essas observaes.

Riscos
Big-bang - Possibilidade de parar a empresa

SmallBang
Fases

- muito difcil voltar atrs

- Grande necessidade de esforo por parte da equipe na etapa de estabilizao em atender a toda a
empresa
- Os erros, comuns no incio da operao, repercutem-se mais facilmente por todo o sistema
- Possibilidade de parar a fbrica
- muito difcil voltar atrs
- H a necessidade de construo de interfaces
- H a necessidade de construo de interfaces
- No h o envolvimento simultneo de toda a
empresa
- No considerao, nos primeiros mdulos, das
necessidades dos mdulos seguintes
- Possibilidade de ser necessria a mudana em
mdulos j estabilizados, por necessidades dos
mdulos seguintes
- Ocorrncia simultnea de processos de implementao e estabilizao

Vantagens
- H mais motivao para enfrentar os
momentos iniciais da operao
- Elimina a necessidade da construo de
interfaces
- Cria um senso de urgncia que facilita o estabelecimento de prioridades
- H mais motivao para enfrentar os
momentos iniciais da operao
- Cria um senso de urgncia que facilita o estabelecimento de prioridades
- Menor possibilidade de parar a empresa
- Maior possibilidade de voltar atrs

Quadro 10 Riscos e Vantagens dos Diferentes Modos de Incio de Operao Elaborado

pelo Autor

possvel utilizar as consideraes apresentadas na figura 16 e no quadro 10 para a estimativa de vantagens e dificuldades em uma determinada empresa, considerando-se um determinado plano de implementao que combine um ou mais dos modelos propostos.
Os Fatores Contingenciais e o Planejamento
Nos casos pde-se perceber como a ao de fatores contingenciais influenciam o processo de planejamento, implementao e utilizao dos sistemas ERP. Fatores tais como aquisies de outras empresas, mudanas na direo, dificuldades oramentrias, impem constantemente novas restries e exigncias sobre os sistemas, obrigando a realizao de mudanas no que havia sido inicialmente planejado. Isso est de acordo com as observaes de Zwicker (1999): planos so recursos acessrios para aes localizadas, mas efetivamente no
determinam o efetivo curso de ao tomado. Segundo essa abordagem, a eficincia de planos

239

como representaes vem exatamente do fato de eles no conseguirem representar todas as

circunstncias e detalhes que cercam uma determinada situao.
Etapa de Estabilizao
A anlise dos casos permitiu aumentar a compreenso a respeito do ciclo de vida de
sistemas ERP. Percebeu-se que o incio da operao, fato que marcava o final da etapa de
implementao no modelo de ciclo de vida, d incio a uma etapa bastante crtica para o sucesso do projeto. Nessa etapa, que pode ser chamada de etapa de estabilizao, o sistema
ERP, que antes era apenas uma abstrao, torna-se real e passa a fazer parte do dia-a-dia da
empresa e das pessoas. Esse o momento em que a maior carga de energia, seja gerencial ou
tcnica, necessria, pois, apesar de o sistema j ter sido implementado, o principal objetivo
do projeto que era faz-lo operar de maneira adequada s necessidades da empresa, ainda no
foi atingido, havendo a possibilidade de que seja necessrio voltar ao sistema anterior. Nesse
momento, surgem dificuldades de operao, falhas no treinamento, falhas em testes, erros em
programas, necessidades de novas customizaes ou customizaes que no foram realizadas
durante a implementao e a ocorrncia de problemas que dificilmente poderiam ter sido previstos na etapa de implementao. H tambm o agravante de que a empresa j est dependendo do sistema para suas atividades, o que traz grande presso para que os problemas sejam
rapidamente resolvidos.
Dois aspectos crticos se destacaram nessa etapa: as dificuldades dos usurios finais e
problemas do sistema ERP (em programas ou na sua adaptao empresa). Os usurios,
mesmo que tenham sido bastante treinados nas funes do novo sistema, o operam com lentido nos momentos iniciais, porque apresentam dvidas e ficam inseguros quanto a estarem
executando corretamente suas atividades. Alm das dificuldades de adaptao s funes do
novo sistema, h a questo da adaptao s necessidades trazidas pelo trabalho em sistema
integrado, que sero detalhadas adiante.
Ao mesmo tempo em que os usurios enfrentam essas dificuldades, tambm ocorrem erros em programas, customizaes ou parametrizaes, impedindo a operao normal. Como
citado no levantamento bibliogrfico e verificado nos casos, muito difcil que se teste e se
preveja todas as possveis maneiras pelas quais o sistema ERP ser usado na empresa. A ocorrncia simultnea de dificuldades dos usurios e erros em programas, associada ao relativamente pequeno conhecimento da equipe de projeto sobre o novo sistema, torna mais difcil a
tarefa de identificar a real causa dos problemas e, consequentemente, elimin-los.

240

Nos casos analisados, foi verificado nessa etapa o grande esforo realizado, por parte da
equipe de projeto, para vencer as resistncias e as crticas ao sistema, eliminar erros de sistema j com a operao em andamento, resolver problemas de performance nas operaes, entre
outros. Nessa etapa foram exigidas extrema dedicao por parte das equipes de projeto e,
principalmente, a determinao de que seria possvel ultrapassar as dificuldades e estabilizar o
sistema ERP.
A configurao e aspectos crticos dessa etapa esto ligados ao modelo de incio de operao escolhido pela empresa. Se a operao do sistema ERP iniciou-se por meio de big-bang,
possvel diferenciar claramente a etapa de estabilizao das etapas de implementao e da
etapa de utilizao. A diferena entre a etapa de estabilizao e a de utilizao que a primeira caracterizada pelo esforo da equipe de projeto em solucionar os erros e normalizar a
operao do sistemas, enquanto que na etapa de utilizao espera-se que os erros j tenham
sido resolvidos e a preocupao seja a evoluo e melhoria contnua do sistema ERP. Nos
casos de big-bang apresentados, foram relatadas duraes entre dois e seis meses para essa
etapa, que dependeram principalmente do pioneirismo no uso do pacote (Rhodia e VMM tiveram problemas de localizao que tornaram mais extensa a etapa de estabilizao em ambas
as empresas) e tambm da complexidade da empresa (nmero de divises ou plantas). Como
toda a empresa entrou em operao simultaneamente, h um grande esforo por toda a equipe
de projeto para corrigir os problemas, que tm ampla abrangncia, funcional e geogrfica.
J nas empresas que implementaram os mdulos em fases, ou mesmo em small-bangs, a
etapa de estabilizao, embora claramente presente, ficou menos caracterizada, e confundiu-se
com a etapa de implementao dos demais mdulos. Nos casos estudados de implementao
em fases, pde-se observar como os ltimos mdulos implementados trouxeram problemas e
necessidades de alterao nos primeiros mdulos implementados (o mdulo de custos, na
Bosch e na Melhoramentos, e os impactos das sucessivas implementaes do mdulo de materiais nas diversas fbricas, na Santista). Tambm pde-se observar as dificuldades trazidas
pela construo de interfaces entre os sistemas antigos e o novo (seja pelo trabalho despendido, na AgroLaranja, ou pela ocorrncia de problemas durante toda a sua utilizao, como na
Bosch).
Embora no tenha sido explicitamente verificado nos casos, possvel inferir que, no
caso de implementaes em fases, a etapa de implementao e a etapa de estabilizao confundem-se aps a entrada em operao do primeiro mdulo. A conseqncia direta disso
que h a possibilidade de ocorrer uma diviso de esforos na equipe de projeto e perda de

241

foco projeto, uma vez que as duas etapas (a implementao e a estabilizao) tm objetivos
conflitantes. Aqueles departamentos que j implementaram o seu sistema esto preocupados
em estabiliz-los, e isso pode significar um esforo para mant-los inalterados se no houver o
interesse especfico daquele departamento. Os departamentos que ainda esto em processo de
implementao e desejarem utilizar novos recursos do sistema podem se ver impedidos de
faz-lo, uma vez que poderia ser necessria a mudana em mdulos j implementados. Ou
podem, ainda, serem obrigados a desenvolver extensas customizaes para que possam fazlo sem alterar os mdulos j em funcionamento (similar ao caso do mdulo de custos na
Bosch, que embora no se tenha utilizado muitas customizaes, parmetros anteriormente
definidos no mdulo industrial tornaram mais complexa a sua adaptao). Seguindo essas
consideraes, pode-se afirmar que a etapa de estabilizao, no caso de implementao em
fases, inicia-se com a entrada em operao do primeiro mdulo e termina apenas quando o
ltimo mdulo implementado, na ltima localidade da empresa, se estabiliza. Essa maior durao, e o fato de que o projeto perde seu foco, tambm podem ser listadas como riscos associados implementao por fases.
As Atualizaes de Verso (Upgrades)
Segundo Kremers e Dissel (2000), um dos dilemas enfrentados pelas empresas na utilizao dos sistemas ERP o da atualizao de verses, que os autores chamam de migrao:
medida que os sistemas ERP evoluem para se adequar aos requisitos dos clientes, novas
verses vo sendo disponibilizadas. A cada vez, as empresas devero decidir se iro ou no
migrar para a nova verso. De acordo com dados de uma pesquisa realizada pelos autores
com 24 empresas usurias de sistemas ERP que fizeram atualizaes de verso, 50% dos respondentes afirmaram que o processo de atualizao foi muito extenso, 25% apontaram que ao
atualizao custou mais caro do que o que havia sido previsto pelo fornecedor e 31% acharam
muito trabalhoso lidar com os problemas em programas na nova verso.
Um dos aspectos interessantes, ressaltado pelos autores, o fato de que se a atualizao
for complexa ou cara demais, abre-se uma oportunidade para os pacotes concorrentes, uma
vez que impossvel que a empresa considere a troca de fornecedor, j que o trabalho e o
custo seria praticamente o mesmo. Segundo os autores, isso obrigar aos fornecedores que
disponibilizem processos mais suaves para a atualizao. Outro ponto apresentado a respeito das empresas pesquisadas, que todas concordaram que a atualizao de verses uma
fase inevitvel do ciclo de vida do software. Outro aspecto a ser ressaltado, ainda, o fato de

242

que a necessidade de atualizao de verses muitas vezes uma imposio externa, por parte
do fornecedor.
Nos casos estudados, apenas a Bosch e a Rhodia estavam se preparando para uma atualizao de verso (da 3.0 para a 4.6, do R/3). Em ambos os casos, as empresas estavam dedicando um razovel tempo e esforo ao projeto, e, entre os custos apontados para a atualizao
estavam os custos de treinamento da equipe de informtica, consultoria e atualizao de equipamentos. claro que deve ser considerado que a implementao de uma atualizao de verso, que assim como a implementao do sistema ERP pode ser conduzida em big-bang,
small-bangs ou em fases, oferece menores desafios e dificuldades no que se refere mudana
cultural dos usurios, j que semelhante a implementao de um sistema ERP em substituio a um outro pacote integrado. Por outro lado, a atualizao de verso foi considerada tambm como uma oportunidade para reviso de processos, na Bosch, e a incorporao de mais
duas unidades do grupo, na Rhodia. Novamente isso mostra que a reviso e melhoria de processos facilitada quando h algum tipo de descongelamento, no caso, um projeto de atualizao de verso.
A Etapa de Seleo
Um aspecto que percebido na anlise dos casos, e que contrariou o que havia sido apresentado no levantamento bibliogrfico foi o fato de que diferentes processos de seleo, que
variaram desde a anlise detalhada de diversas alternativas at a imposio da matriz, no
exerceram, pelo menos nos casos estudados, influncia significativa no resultado final das
implementaes. Entretanto, preciso considerar nessa observao, o vis da escolha dos casos, uma vez que foram apenas escolhidas empresas onde o sistema ERP foi efetivamente
implementado e estava de fato em utilizao, no sendo possvel concluir que o processo de
escolha no exerceu influncia nas demais etapas do processo.
Expanso do Modelo de Ciclo de Vida de Sistemas ERP
Alm da existncia de uma etapa de estabilizao, outros aspectos que se destacaram
nos casos e que podem ser incorporados ao modelo de ciclo de vida dos sistemas ERP so:

A influncia que os novos mdulos que vo sendo implementados podem exercer sobre os
mdulos j implementados
A influncia dos fatores contingenciais sobre a execuo do plano original de implementao
A influncia do modo de incio de operao (big-bang, small-bangs ou em fases) na etapa
de estabilizao, caracterizando-a de maneira diferente em cada um dos casos

243

As figuras 17 e 18 apresentam os modelos de ciclo de vida de sistemas ERP, considerando-se os dois modelos de incio de operao.

Fatores
Contingenciais

DECISO E
SELEO

IMPLEMENTAO

ESTABILIZAO

Mdulos
parametizados,
customizados
Dados migrados
Usurios treinados

Pacote
Selecionado
Plano Inicial de
Implementao

UTILIZAO

Sistema ERP
estabilizado

Figura 17 Modelo de Ciclo de Vida de Sistemas ERP Implementao em big-bang Elaborada pelo Autor

Novas necessidades,
Conhecimento acumulado
Parmetros j estabelecidos

DECISO E
SELEO

Pacote
Selecionado
Plano Inicial de
Implementao

Mdulos adaptados
Dados migrados
Usurios treinados

IMPLEMENTAO

Fase n
Fase 2

Mdulos
Estabilizados

ESTABILIZAO

Fase 1

Fatores
Contingenciais

Necessidades de Alterao em
Mdulos em Estabilizao

UTILIZAO

Fase n
Fase 2
Fase 1

Fase 1
Fase 2
Fase n

Necessidades de Alterao em
Mdulos em Utilizao

Figura 18 Modelo de Ciclo de Vida de Sistemas ERP Implementao em Fases ou SmallBangs Elaborada pelo Autor

244

7.2 Benefcios e Dificuldades de Sistemas ERP

A integrao
Entre todas as caractersticas dos sistemas ERP, a que mais se destacou foi a integrao
entre os seus mdulos. O estudo permitiu perceber como a integrao influencia a organizao
e como ocorrem os benefcios e dificuldades a ela associados.
Com a implementao do sistema ERP, as atividades da empresa passam a estar interligadas on-line. Dessa maneira, as informaes geradas por essas atividades passam a ser imediatamente utilizadas como entradas para as atividades seguintes em um processo. Em razo
disso, necessrio que elas sejam adequadamente registradas no sistema (isto , informaes
corretas e inseridas no momento adequado) para que as outras atividades que delas dependam
possam ser executadas.
Isso traz as seguintes conseqncias: 1) a melhoria na qualidade e na preciso das informaes disponveis no sistema, uma vez que todos os dados devem ser obrigatoriamente
registrados no sistema para que a atividade possa ser realizada; 2) um grande controle sobre
todas as atividades que dependam do sistema, uma vez que para que possam ser executadas,
necessrio que as informaes sejam registradas no momento adequado e seguindo as determinaes do sistema; e 3) as atividades dos departamentos tornam-se transparentes, uma
vez que as informaes que eles geram so disponibilizadas a toda a empresa, de maneira online, e problemas ou erros em suas operaes so imediatamente percebidos pelas demais reas. Os principais benefcios da integrao so, portanto, a qualidade e a disponibilizao de
informaes on-line, o controle que pode ser exercido sobre as tarefas e a eliminao de erros
e ineficincias que podem ser escondidos em departamentos. Nas empresas onde os sistemas anteriores eram isolados e havia necessidade de redigitao de dados, foram obtidos,
alm dos benefcios citados, redues em mo-de-obra.
Em compensao, a integrao traz dificuldades para a implementao dos sistemas
ERP, tambm relacionadas aos trs pontos apresentados acima: 1) como o sistema integrado
transfere aos departamentos que originam as informaes a responsabilidade de inseri-los, de
maneira correta e incluindo dados que servem apenas para os departamentos seguintes no processo (por exemplo, a digitao de uma conta contbil em um lanamento de produo), h a
percepo, por parte dos usurios, de que suas tarefas foram aumentadas; 2) como, alm disso, as informaes devem ser inseridas no sistema no momento mais adequado para o processo como um todo, e no para aquele departamento em especfico, h a necessidade de se mu-

245

dar a maneira como as tarefas so executadas e passam a existir cobranas por parte dos demais departamentos que dependem dessas informaes; e 3) finalmente, o fato de as atividades de um departamento tornarem-se transparentes aos demais traz o inconveniente de ser
necessria a prestao de contas por tudo aquilo que se faz.
O treinamento dos usurios finais para o trabalho em um sistema integrado, levando em
considerao os aspectos citados, foi apontado como a grande deficincia nos treinamentos
realizados nas empresas. Apesar disso, percebeu-se que uma vez vencidas essas dificuldades,
houve o crescimento profissional dos usurios, que passaram a ter sua viso do funcionamento da empresa ampliada e a perceber melhor o seu papel e importncia nos processos empresariais.
Pacote Comercial
Em todas as empresas, a implementao de sistemas ERP em substituio a sistemas
desenvolvidos internamente representou grandes redues nos custos de informtica, por dois
motivos: a eliminao de mainframes, ambientes que at bem recentemente apresentavam
altos custos de manuteno e a reduo de custos de pessoal na informtica.
Em alguns casos, foram citados como relevantes os custos de desenvolvimento de customizaes e adaptao contnua do sistema ERP.
A Abrangncia Geogrfica
Como citado anteriormente, a anlise dos casos permitiu observar que alm de abrangncia funcional, a utilizao dos sistemas ERP tambm pode ser caracterizada por sua
abrangncia geogrfica. Embora essa no seja uma caracterstica exclusiva dos sistemas ERP,
ela permite que estes sistemas sejam utilizados para centralizar o processamento e padronizar
atividades administrativas em empresas ou grupos de empresas que possuam grande nmero
de localidades, tal como observado nos casos da AgroLaranja (80 empresas) e Santista (23
localidades). No caso da CNT/VMM, essa caracterstica permitiu o gerenciamento remoto da
rea de materiais na planta de Tocantins.
O Ganho Global versus o Ganho Local
O estudo dos casos permitiu verificar a questo da percepo dos benefcios e dificuldades dos sistemas ERP considerando a empresa como um todo e os diversos departamentos
individualmente.

246

Foi observado que em muitos dos casos, usurios ou departamentos individuais perderam funcionalidades que existiam nos sistemas anteriores, sendo mesmo necessria a sua execuo em planilhas eletrnicas. Em muitos casos tambm, aumentou o nmero de telas e
campos a serem preenchidos, bem como a quantidade a exigncia de preciso nas tarefas a
serem realizadas. Se os departamentos foram analisados individualmente, pode-se afirmar que
uma das mximas do desenvolvimento interno de sistemas, o novo sistema deve, no mnimo,
fornecer aquilo que o usurio j tinha, foi ignorada nas implementaes de sistemas ERP
estudadas.
Mas, em todos os casos, foram percebidos grandes ganhos de eficincia quando se considera a empresa como um todo. O estudo dos casos permitiu a observao de que a implementao de um sistema ERP proporciona ganhos relativos integrao dos processos, sincronizao de suas atividades internas, melhoria no planejamento, reduo de desperdcios
de materiais e tempo e ao controle interno das operaes realizadas. Esses benefcios globais
foram, como observado nos casos, obtidos s custas de dificuldades ou aumento de tarefas
em alguns departamentos individuais.
Quanto a isso, foi interessante a verificao, no caso da AgroLaranja, de que o desenvolvimento interno de um sistema integrado no foi possvel, pela resistncia dos departamentos e da prpria informtica. Isso pode indicar que os sistemas integrados trazem seus
maiores benefcios para a empresa como um todo, no para os departamentos individuais, e,
no havendo motivao da empresa ou determinao da alta direo, sua construo pela
equipe interna de informtica de difcil execuo. Os sistemas ERP auxiliaram s empresas
a descongelar essa situao, permitindo, enfim, a consumao da viso de sistemas integrados.
Em todos os casos houve a reduo do tempo necessrio para o fechamento da contabilidade, o que pode ser considerado como um indicador de que o processamento de informaes para a tomada de deciso esteja sendo realizado de maneira mais eficiente e com melhor
qualidade. A contabilidade foi citada, na maioria dos casos, como a principal rea beneficiada
pelos sistemas ERP, enquanto que as reas onde as informaes so originadas, tais como o
recebimento de materiais e a produo, foram citadas como tendo sua carga de trabalho aumentada.

247

O Papel dos Sistemas Anteriores

Foi marcante, em todos os casos, a importncia das caractersticas dos sistemas anteriores na percepo dos benefcios obtidos e problemas relacionados aos sistemas ERP. Nos casos onde o sistema ERP substituiu sistemas desenvolvidos internamente, foi observada maior
resistncia dos usurios em se adaptar s tarefas impostas pelo fato de o pacote ser mais genrico (maior nmero de telas e campos). Onde havia problemas de qualidade nos sistemas, a
melhoria de qualidade da informao foi mais enfatizada. Onde a dificuldade era a integrao
dos sistemas, esse aspecto foi o mais destacado pelos usurios. Nos casos da Zeneca e da
Melhoramentos, onde pde-se observar o sistema ERP sendo implementado em substituio a
um pacote, foi percebida uma menor resistncia por parte dos usurios e menores exigncias
para a realizao de customizaes antes da implementao. No caso da Santista e na AgroLaranja, onde o sistema ERP substituiu a uma srie de sistemas diferentes em diversas localidades, a padronizao e a centralizao foram os principais benefcios percebidos.
Diferenas entre os Pacotes
No foram percebidas diferenas fundamentais entre os dois pacotes estrangeiros estudados, nem entre os dois pacotes nacionais estudados. As diferenas mais significativas observada entre os pacotes estrangeiros e os nacionais foram os problemas com a localizao,
observados nos pacotes estrangeiros, e a maior abrangncia funcional dos pacotes nacionais,
que incluam mdulos como controle de patrimnio, recursos humanos, tesouraria e controle
de exportaes.
Quanto localizao, deve se ressaltar que os problemas maiores ocorreram nas empresas que foram pioneiras na implementao dos pacotes no Brasil, percebendo-se uma diminuio de sua intensidade nas empresas que implementaram esses pacotes mais recentemente.
Outro ponto a ser ressaltado o de que mesmo os pacotes nacionais apresentaram algum grau
de inadequao legislao brasileira, extremamente complexa e com variaes regionais, e o
fato de que tambm esses pacotes esto sujeitos s alteraes em leis, e, consequentemente
necessidade de serem feitas novas correes ou atualizaes nos programas-padro.

248

Novos Benefcios e Problemas Verificados nos Casos

O quadro 11 resume novos benefcios e dificuldades relacionados aos sistemas ERP que
foram verificados nos casos, bem como detalhamentos daqueles apresentados no captulo 4.

Vantagens

Dificuldades

- Crescimento profissional dos envolvidos

- Resistncia devido ao aumento de trabalho
Integrao
- Disciplina organizacional
das reas responsveis pela entrada de da- Sincronizao entre atividades da cadeia
dos
de valor, melhorando o planejamento glo- - Resistncia devido ao aumento da cobrana
bal da empresa
sobre as reas responsveis pela entrada de
- Reduo do prazo para a consolidao dos
dados
resultados mensais e fechamento da conta- - No obteno de reduo de mo-de-obra
bilidade
nas reas responsveis pela entrada de da- Melhoria na qualidade da informao, uma
dos
vez que h mais garantias de que todas as
atividades tenham sido registradas no sistema
- A integrao mostra problemas escondidos nos departamentos
- Dificuldade para suporte, principalmente
Abrangncia Fun<<
sem
alterao
>>
nos momentos iniciais da operao em bigcional
bang
Abrangncia Ge- - Padronizao de procedimentos e concei- - Dificuldade para suporte, principalmente
tos
nos momentos iniciais da operao em bigogrfica
- Controle distncia
bang
- Centralizao de reas administrativas
- Dificuldades na troca de conhecimentos
Pacote Comercial - Grande gama de possibilidades (ou funes)
oferecidas
diminui
a
dependncia
da
com os consultores
e Uso de Modelos
rea de informtica
- Perda de funcionalidades existentes nos
de Processos
sistemas anteriores
- Custos relativos adaptao contnua
- No obteno de reduo de mo-de-obra
nas reas responsveis pela entrada de dados
- O desenho do sistema no leva em considerao aspectos de performance
- Excesso de telas e campos a serem digitados
- Ausncia de relatrios gerenciais e operacionais adequados

Banco de Dados
Corporativo

<< sem alterao >>

Necessidade de grande cuidado com cadastros que possam ser compartilhados entre as reas (produtos, por exemplo)
- Excesso de dados no banco de dados, gerando problemas de performance

Quadro 11 Novos Benefcios e Problemas Verificados nos Casos Elaborado pelo Autor

249

7.3 Recomendaes
Com base nas concluses deste trabalho, podem-se traar algumas recomendaes para
as etapas de implementao, estabilizao e utilizao dos sistemas ERP. Essas recomendaes no podem ser consideradas como fatores crticos de sucesso no sentido estrito do termo,
uma vez que so fruto da observao dos fatos relatados nos diversos casos e, muitas vezes,
refletem a opinio pessoal dos entrevistados. Em alguns casos elas no foram observadas e,
mesmo assim, a implementao do sistema ERP foi bem sucedida, no sentido em que o sistema est em operao adequada.

Planejamento da Implementao

Escolher o modo de incio de operao adequadamente, considerando as limitaes de

recursos, equipe de projeto, nmero de mdulos que sero implementados e localidades
Preparar planos de contingncia para eventuais alteraes no projeto em decorrncia de
fatores contingenciais (tal como o atraso de etapas, alterao na ordem da implementao
de mdulos ou plantas, etc.)
Etapa de implementao
Alm da comunicao entre as equipes que esto implementando os diversos mdulos,

podem-se apresentar as seguintes recomendaes:

Deixar claro que a responsabilidade pelo sucesso do projeto das reas usurias, e no da
equipe de informtica.
No seguir nenhuma destas duas regras: customizar tudo ou no customizar nada.
Deve ser buscado um ponto que equilibre o custo e permita a empresa extrair mais benefcios do novo sistema.
Deixar a customizao de detalhes, que, em princpio, no iro comprometer a utilizao,
para depois da etapa de estabilizao, pois, antes do incio da operao do sistema, essas
solicitaes so muitas vezes baseadas na situao anterior.
Testar a integrao entre os mdulos e os fechamentos (dirios, semanais, mensais, anuais) de cada um deles
Treinar o usurio final no somente nas suas funes, mas, se possvel, nos mdulos que
dependam das informaes que ele est gerando.
Envolver o usurio final em testes integrados, onde ele poder perceber a implicao de
suas atividades nas demais reas.
Preparar material de apoio adequado, em portugus, para os usurios finais.

250

Etapa de estabilizao
o momento mais crtico para o projeto, onde o novo sistema externa sua realidade
para a empresa. Iro ocorrer erros de operao ou sistema, sendo muitas vezes difcil distingui-los. Portanto, so importantes os seguintes fatores:

Apoio da alta direo, no sentido de confirmar que no haver a possibilidade de retornar

ao sistema anterior
Apoio da alta direo, no sentido de estabelecer que o sucesso da implementao tarefa
de todos, no do departamento de informtica exclusivamente
Presena de lderes que possam manter o ambiente estvel. Os lderes jamais podem colocar a culpa no sistema, mas transmitir a mensagem clara de que essa a nova realidade
e que papel de todos torn-la funcional e livre de problemas
Manuteno completa da estrutura, funes e responsabilidades da equipe de projeto at
que a estabilizao do sistema tenha se completado
Presena de uma equipe de apoio do fornecedor ou consultoria, para que se resolvam mais
rapidamente os problemas que iro ocorrer. A presena de uma equipe ampliada nesses
momentos tambm interessante, para que se possa mais rapidamente esclarecer se os
problemas so de operao ou de sistema
A soluo de problemas de operao ou sistema deve ser comunicada rapidamente a todos, deixando clara a origem do problema (operao ou sistema). Deve haver um trabalho
ativo na eliminao de boatos e criao de lendas, que possam minar a determinao
em usar o novo sistema e justificar resistncias
No caso de implementao em fases ou small-bangs, faz-se necessrio ampliar ainda mais
o apoio da alta direo ao projeto e a comunicao entre todos os envolvidos, uma vez
que, complexidade do projeto associa-se a ocorrncia de trs etapas simultaneamente (a
implementao, a estabilizao e a utilizao)
Etapa de Utilizao

Manter, em cada um dos departamentos ou para cada um dos mdulos, um usurio responsvel por aquele mdulo.
Manter um coordenador permanente para o sistema ERP (no necessariamente o gerente
de informtica)
Manter, com esses representantes e com o coordenador permanente, reunies (mensais,
bimensais ou trimestrais, de acordo com a necessidade e o tempo de utilizao), para que
possam discutir e definir prioridades e, principalmente, definir responsabilidades em alteraes ou melhorias que exijam o envolvimento de mais de uma rea.
Manter, entre esses representantes e a equipe de TI, o canal aberto para a comunicao,
por meio de boletins, intranet, etc.

251

7.4 Recomendaes para Futuras Pesquisas

Uma das caractersticas do processo de implementao e utilizao de sistemas ERP que
ficou bastante clara em todos os casos, e na anlise entre eles, a complexidade do fenmeno,
e a conseqente diversidade de enfoques que pode ser dada ao seu estudo. Isso aponta uma
possibilidade para a realizao de estudos de caso tomando como unidade de anlise as pessoas envolvidas no processo (gerentes, analistas de negcios, analistas de suporte, usurioschave, usurios finais, etc.), que poderiam verificar mais claramente quais so os impactos
dos sistemas ERP nas pessoas, suas tarefas, suas perspectivas, e em sua viso a respeito de seu
trabalho. Um aspecto que se destacou durante as entrevistas foi o fato de que as implementaes so relatadas pelos entrevistados como se fossem batalhas, com heris e viles, dificuldades e solues duramente encontradas. Um estudo focalizado na compreenso desses
heris e viles, permitiria observar o lado humano de projetos desse porte, verificando
como as pessoas envolvidas conseguiram conduzir o projeto at o seu trmino, vencendo as
dificuldades citadas e os problemas contingenciais.
Uma outra possibilidade, com foco cultural, seria um estudo utilizando as ferramentas
propostas por Schein (1995), por exemplo, que poderia analisar empresas que tenham implementado sistemas ERP do mesmo fornecedor e verificar se o sistema ERP uniformiza diferentes culturas empresariais e em que aspecto isso ocorre.
Outro aspecto interessante, que poderia ser pesquisado, a respeito da influncia de
determinados clientes, ou grupos de clientes, no desenvolvimento dos sistemas ERP, talvez
utilizando modelos que expliquem a ao poltica de usurios internos, em uma situao de
desenvolvimento de sistemas realizados dentro da empresa, extrapolando-os para uma situao onde o fornecedor representaria o departamento de informtica e os diversos clientes os
usurios. Essa pesquisa permitiria observar como determinados clientes, ou grupos de clientes, tais como os grupos de usurios, influenciam a evoluo dos sistemas ERP, alm, claro,
da influncia dos no-clientes (mercado). O caso da AgroLaranja representativo frente a
essa questo, uma vez que a empresa conseguiu extrair diversos benefcios do fornecedor,
relativamente aos observados nos demais casos. entretanto um fornecedor nacional, sobre
quem, talvez, essa influncia possa ser mais facilmente exercida.
Outra possvel pesquisa poderia focar os aspectos econmicos da utilizao de sistemas
ERP, verificando se e como ocorrem as economias de escala no desenvolvimento e manuteno de sistemas, no curto e no longo prazo, para as empresas clientes e para as empresas fornecedoras, e como aspectos como manuteno e evoluo de sistemas mais ou menos custo-

252

mizados pelos clientes podem interferir na obteno dessas economias. Essa pesquisa, embora
de difcil consecuo, poderia trazer luz sobre as perspectivas do modelo de sistemas terceirizados.
Uma possvel pesquisa de cunho quantitativo seria a definio com clareza de uma medida para o grau de customizao dos pacotes, tentando relacion-la com os fatores origem do
pacote, importncia do cliente para o fornecedor, tamanho da rea de informtica, nmero de
usurios, entre outros. Essa pesquisa tambm poderia definir operacionalmente os diferentes
tipos de customizao ( modificao em programas-padro, programas externos, mdulossatlite, etc.) e fazer trs medies ao longo do tempo, uma logo aps o incio da operao,
outra aps a estabilizao e uma terceira aps algum tempo de utilizao. Poderia ser estabelecido algum modelo que explicasse a evoluo desse aspecto nas empresas, bem como a sua
implicao para as atividades de manuteno e os custos de informtica.
Outra pesquisa quantitativa, relacionada ao estudo de processos, poderia ser feita na
rea de suprimentos (compras, recebimento e controle de estoques), procurando definir indicadores de integrao e de performance antes e depois da implementao, como objetivo de
verificar a influncia da integrao sobre o funcionamento dessa rea. A rea de suprimentos
mostrou-se interessante para um estudo dessa natureza, uma vez que em boa parte dos casos
foram relatados ganhos na integrao.
Outra pesquisa possvel, novamente em estudos de caso, seria uma ampliao do conhecimento sobre a etapa de utilizao especificamente, que no pde ser bastante detalhada
neste estudo. Aspectos como a atualizao de verses, de equipamentos, manutenes menores nos programas, etc., e sua influncia nas atividades da rea e na melhoria dos sistemas
ERP poderiam ser analisados por essa pesquisa.
7.5 Comentrios Finais do Pesquisador
O fenmeno dos sistemas ERP trouxe consigo uma riqussima oportunidade de estudo
para a rea de administrao de informtica, uma vez que sua abrangncia e complexidade
permitem a anlise simultnea de diversos aspectos relacionados ao uso de sistemas de informao em empresas. A realizao deste trabalho permitiu ao pesquisador (e, espera-se, aos
leitores) a ampliao da viso a respeito dos processos de implementao e utilizao de sistemas de informao em geral.
O estudo dos casos permitiu a resposta a uma pergunta que surgiu vrias vezes, no incio deste trabalho: por que as empresas gastam tanto, em projetos to longos, de alto risco,

253

para implementar um sistema que tem limitaes em relao aos desenvolvidos internamente?. Nos casos, pde-se perceber que os sistemas ERP trazem a possibilidade de ganhos
muito grandes e reais de eficincia empresarial, pelo controle que proporcionam e pela sincronizao das atividades que obrigam, e conseqentemente seu melhor planejamento. Claramente os sistemas ERP propem-se a melhorar a eficincia da empresa, sendo isso obtido
pela integrao, como observado nos casos. Em alguns deles, as respostas dos entrevistados
indicaram tambm melhorias na eficcia e ganhos competitivos, tal como no caso da Santista,
mas, em todos estes, os ganhos foram obtidos por meio da extenso dos sistemas ERP, seja
pela sua integrao a outros sistemas ou extenso de suas funcionalidades por mdulossatlite. As respostas tambm indicaram que os sistemas ERP permitiram a reduo das despesas de informtica nas empresas. preciso salientar entretanto, que essa reduo de custo
localizada na rea de informtica ou em determinadas reas das empresas pode no necessariamente ter levado a uma reduo de custos para a empresa como um todo, o que precisaria ser
verificado em maior detalhe por meio de um estudo da contabilidade de custos da empresa,
sendo este um trabalho de relativa dificuldade.
Claro que, como as demais solues de informtica, os sistemas ERP tm, seguramente,
em sua forma presente, seus dias contados. Entre os desafios que esto sendo enfrentados por
esses sistemas esto a sua integrao externa e o aumento de sua flexibilidade para acompanhar as mudanas nos negcios da empresa.
Quanto integrao do ERP cadeia de fornecimento, destacam-se ferramentas tais
como o CRM (customer relationship managemet), o SCM (supply-chain management) e a
implementao de sistemas de e-business, havendo a tanto a possibilidade de ganhos de eficincia, quanto de eficcia.
Quanto segunda questo, os sistemas ERP como so atualmente, embora flexveis durante a implementao, mostraram-se de difcil mudana uma vez iniciada a operao. Esse
pode ser o calcanhar de Aquiles desse modelo. Entre as alternativas disponveis para a soluo desse problema, ou, evoluo do modelo, esto o aperfeioamento das tcnicas e ferramentas para a modelagem de processos (preferida pelos fornecedores tradicionais) e o uso de
objetos e componentes.

254

REFERNCIAS BIBLIOGRFICAS

255

REFERNCIAS BIBLIOGRFICAS

Alsne, ric (1999). The computer integration of the enterprise. IEEE Transactions on Engineering Management, vol. 46, no. 1, pp. 26-35.
Appleton, Elaine L. (1997). How to survive ERP. Datamation, Mar, 97.
Bancroft, Nancy H., Seip, Henning e Sprengel, Andrea (1998). Implementing SAP R/3: How
to introduce a large system into a large organization (2a. edio). Greenwich: Manning.
Benbasat, Izak, Goldstein, David K. e Mead, Melissa (1987). The case research strategy in
studies of information systems. MIS Quarterly, set/1987, pp. 369-386.
Bergamaschi, Sidnei (1999). Um estudo sobre projetos de implementao de sistemas para
gesto empresarial. Dissertao de Mestrado. Faculdade de Economia e Administrao,
USP, So Paulo.
Bido, Digenes S. (1999). Implementao de sistemas da qualidade para a busca de certificao em pequenas e mdias empresas do ramo automotivo. Dissertao de Mestrado.
Faculdade de Economia e Administrao, USP, So Paulo.
Bingi, Prasad, Sharma, Maneesh K. e Godla, Jayanth K. (1999). Critical issues affecting an
ERP implementation. Information Systems Management, 1999, vol 16, no. 13, pp 7-14.
Bogdam, Robert C. e Biklen, Sari K. (1982). Qualitative research for education: an introduction to theory and methods. Allyn and Bacon: Boston.
Brooks, Frederick P. Jr. (1987). No silver bullets. Unix Review, Agosto/1997, p.39-48.
Burch, John G. e Grudnitski, Jarry (1989). Information systems: Theory and practice (5 edio). New York: John Willey & Sons.
Carney, David (1998). Assembling large systems from COTS components: Opportunities,
cautions, and complexities. SEI Monographs on the Use of Commercial Software in Government Systems. < http://www.sei.cmu.edu/cbs/papers/monographs/ assemblingsystems/assembling.systems.htm >
Cole-Gomolski, Barb (1998). ERP! Excuse us as we digest our new system. Computerworld, 21/9/98, p.100.
Cooper, Randolph B. e Zmud, Robert W. (1990) . Information technology implementation
research: A technological diffusion approach. Management Science, Fevereiro/1990,
v.36, n.2, p.123-139.
Corra, Henrique L. e Gianesi, Irineu G. N. (1994). Just in time, MRP II e OPT: Um enfoque
estratgico. So Paulo: Editora Atlas Ltda.

256

Davenport, Thomas H. (1990). The new industrial engineering: Information technology and
business process redesign. Sloan Management Review, Summer/1990, p.11-27.
Davenport, Thomas H. (1998). "Putting the Enterprise into the Enterprise System". Harvard
Business Review, Julho/Agosto 1998, p.121-131.
Davenport, Thomas H.(1999). Living with ERP. CIO Magazine, 01/12/1998.
Deloitte Consulting (1998). ERPs Second Wave: Maximizing the Value of ERP-Enabled Processes. Relatrio de pesquisa publicado pela Deloitte Consulting.
Einsenhardt, Kathleen M. (1989). Building theory from case study research. Academy of
Management Review, vol 14, no. 4, pp. 532-550.
Figueiredo, Reginaldo S. e Zambom, Antonio C. (1998). A empresa vista como elo da cadeia
de produo e distribuio. Revista de Administrao, Julho/Setembro 1998, v.33, n.3,
p.29-39.
Gartner Group (1998). Pacotes de Aplicativos Empresariais: Em Busca de Limites. Apostila
da 3a Conferncia Anual sobre O Futuro da Tecnologia da Informao, realizada em So
Paulo, Ago/1998.
Gibbs, W. Wayt (1994). Softwares chronic crisis. Scientific American, Setembro/1994,
p.72-81.
Godoy, Arilda S. (1995). Introduo pesquisa qualitativa e suas possibilidades. Revista de
Administrao de Empresas / EAESP / FGV, Maro/Abril 1995, v.35, n.2, p.57-63.
Godoy, Arilda S. (1995b). Pesquisa qualitativa: Tipos fundamentais. Revista de Administrao de Empresas / EAESP / FGV, Maio/Junho 1995, v.35, n.3, p.20-29.
Grover, Varun, Teng, James T.C. e Fiedler, Kirk D. (1998). IS investment priorities in contemporary organizations. Communications of the ACM, Fevereiro/1998, v.41, n.2, p.4048.
Hecht, Bradley (1997). Chose the right ERP software. Datamation, Mar, 97.
Hicks, Donald A. (1995). The ERP maze. IIE Solutions, Agosto/95, p.13-16.
Jackson, Debbie (1995). RP, Hoecsht tie the knot in Brazil. Chemical Week, New York,
14/06/1995.
Johnson, Rod (1999).Riding the New ERP Consulting Wave. Intelligent Enterprise,
11/5/99.
Kremers, Mark e Dissel, Han Van (2000). ERP system migrations. Communications of the
ACM, Abril/2000, v.43, n.4.
Kuldeep Kumar e Jos Van Hillegersberg (2000). ERP experiences and evolution. Communications of the ACM, Abril/2000, v.43, n.4.

257

Kwon, Tae H. e Zmud, Robert W. (1987). Unifying the fragmented models of information
systems implementation. Em Critical issues in information systems research, editado
por R. J. Boland Jr. e R. A. Hirschheim. New York: John Willey & Sons.
Lai, Vincent S. e Mahapatra, Radha K. (1997). Exploring the research in information technology implementation. Information & Management, v.32, p.187-201.
Laudon, Kenneth C. e Laudon, Jane P (1996). Management Information Systems (4 edio).
Upper Saddle River: Prentice Hall.
Lazzarini, Srgio G. (1995). Estudos de Caso: aplicabilidade e limitaes do mtodo para
fins de pesquisa. Economia & Empresa, outubro/dezembro 1995, pp.17-26.
Lewin, Kurt (1952). Group decision and social change. em Readings in social psychology.
New York: Henry and Holt Company, 1952, p.197-211.
Lewis, Ted (1996). Deploying distributed business software. New York: SIGS Books.
Lozinsky, Srgio (1996). Software: Tecnologia do negcio. So Paulo: Imago.
Lucas, Henry C. Jr. (1985). The analysis, design and implementation of information systems
(3 edio). New York: McGraw Hill.
Lucas, Henry C., Walton, Eric e Ginzberg, Michael (1988). Implementing Packaged Software. Mis Quarterly, Dezembro/1988, p.537-549.
Martin, James (1989). Engenharia da informao: Introduo (trad.). Rio de Janeiro: Editora
Campus Ltda.
Martin, James e McClure, Carma (1983). Buying software off the rack. Harvard Business
Review, Novembro/Dezembro 1983, p.32-60.
Meirelles, Fernando S. (1997) (coord). Pesquisa: Administrao de Recursos de Informtica.
FGV, Agosto/1997
Myers, Marc (1995). The trouble with off-the-shelf apps. Network World, 09/10/95, p.37.
Orlikovski, Wanda J. e Hofman, J. Debra (1997). An Improvisational Model for Change
Management: The Case of Groupware Technologies. Sloan Management Review, Winter/1997, p.11-21.
Porter, Michael E. (1989). Vantagem Competitiva (trad.). Rio de Janeiro: Editora Campus.
Porter, Michael E. e Millar, Victor E. (1985). How information gives you competitive advantage. Harvard Business Review, Julho/Agosto 1985, p.149-160.
Schein, Edgar (1995). Organizational culture and leadership. Jossey-Bass.

258

Shepherd, James (1998). Is ERP in Trouble? If this is trouble, where can I get some?. Computerworld, 14/09/98, p.64.
Selltiz, C., Jahoda, M., Deutsch, M., Cook, S. M. (1965). Mtodos de pesquisas das relaes
sociais. So Paulo: Editora Herder.
Slater, Derek (1999). An ERP package for you... and you ... and even you. CIO Magazine,
15/02/99.
Soh, Christina, Kien, Sai S. e Tay-yap, Joanne (2000). Cultural fits and misfits: Is ERP a
universal solution?. Communications of the ACM, Abril/2000, v.43, n.4, p.47-51.
Souza, Cesar e Zwicker, Ronaldo (1999). Aspectos envolvidos na seleo e implementao
de sistemas ERP. Anais da XXXIV Assemblia Anual do CLADEA, Porto Rico.
Stedman, Craig (1998a). ERP can magnify errors. Computerworld, 19/10/98, p.14.
Stedman, Craig (1998b). ERP user interfaces drive workers nuts. Computerworld, 2/11/98,
p.24.
Stedman, Craig (1999). Fast ERP installations need fine-tuning. Computerworld,
19/04/1999.
Strauss, Anselm e Corbin, Juliet (1990). Basics of qualitative research. London: Sage Publications.
Supply Chain Council (1999). FAQ Supply Chain Council. Disponvel em <http://
www.supply-chain.org/html/faq.html>
Symnetics (1999). Implementaes referenciais: Robert Bosch Limitada, estudo de caso de
implementao de SAP R/3. Documento disponibilizado pela Symnetics.
Taurion, Cezar (1998). ERP: Como ser o dia seguinte. Computerworld Brasil, 26/06/98.
TechEnciclopedya (1999). Disponvel em < < http://www.techweb.com > >
Tyre, Marcie J. e Orlikowsli, Wanda J. (1993). Exploiting opportunities for technological
improvement in organizations. Sloan Managemen Review, fall/1993, pp.13-26.
Wagle, Dilip (1998). The case for ERP systems. The McKinsey Quarterly, 1998, n.2, p.130138.
Wood Jr., T. e Caldas, M. P. (1999). Stripping Big Brother: or spying the backstage behind
the ERP phenomenom. Trabalho submetido para apresentao no encontro anual da
Academy of Management, Chicago.
Yin, Robert K. (1989). Case study research. Design and methods. London: Sage Publications.
Zwicker, Ronaldo (1999). "Cognio e Sistemas". Anais da XXXIV Asemblia Anual do
CLADEA, Porto Rico.

259

ANEXOS

260

ANEXO 1 QUESTIONRIO PARA O RESPONSVEL PELO PROJETO OU REA DE TI

261

ANEXO 1 QUESTIONRIO PARA O RESPONSVEL PELO PROJETO OU REA DE TI

EMPRESA: _____________________________ ENTREVISTADO: ______________________________
DATA: _____________________
CARGO: ______________________________

Dados sobre a empresa e histrico

Nome da Empresa:
Atividade principal/ Principais Produtos:
A empresa multinacional? Onde fica a matriz?
Qual o faturamento anual? Qual o nmero de funcionrios?
Quais mercados atende? Quais seus principais clientes?
Quantas plantas possui? Onde esto localizadas?
Qual o sistema ERP utilizado?
Qual a plataforma de hardware e software (servidores, redes, banco de dados, etc.)?
Quais os mdulos j implementados?
Em que data (ms e ano) os mdulos foram implementados?
Quantos funcionrios h na rea de TI?
A rea de TI subordinada a que rea da empresa?
Qual o nmero total de usurios? Quantos micros h na rede?
Descrio do sistema anterior (pacote, prprio, tecnologia, etc.)
I Deciso e Seleo

Por que as empresa optou pela utilizao de um sistema ERP? Quais seriam possveis alternativas ao uso de sistemas ERP, e por que foram preteridas? Quais as principais caractersticas do(s) sistema(s) anterior(es)?
Quais os benefcios buscados pela empresa ao utilizar um sistema ERP? Eles foram formalmente definidos no incio do projeto?
Como foi o processo de tomada de deciso e de escolha do fornecedor? Quais foram as
etapas? Quem foi envolvido? Quais foram os fatores considerados para comparao das
alternativas?
Caso a empresa seja multinacional, houve participao da matriz na deciso?
A empresa tem alguma caracterstica particular que poderia representar uma dificuldade na
utilizao de ERP?

II - Implementao

Como foi conduzida a implementao do sistema ERP? Quem definiu a metodologia? Qual
era esta metodologia? Como foi (foram) estruturada(s) a(s) equipe(s) do projeto?
Quais problemas ocorreram durante a implementao? Como foram resolvidos?
Quando surgia uma discrepncia entre o sistema e os processos do(s) departamento(s),
como era resolvida? Quem decidia o que seria feito? Se a alternativa fosse mudar a empresa, como isto era conduzido?
Quais foram os aspectos considerados crticos durante a fase de implementao?
Existiu resistncia mudana? Como foi contornada?
Como foi o incio da operao. Houve paralelo?

262

III Utilizao (Deptos Usurios e TI)

Quais foram os benefcios trazidos pela utilizao do sistema ERP? Os benefcios esperados pela utilizao do sistema esto sendo obtidos? (Por que no?) Existiram benefcios
no esperados?

Quais foram os problemas que surgiram ou esto surgindo na fase de utilizao? Como
foram, ou esto sendo solucionados?

Como o aspecto integrao entre os mdulos presente no sistema ERP modificou a empresa? Quais foram os benefcios e problemas relacionados integrao?

Como o aspecto sistema desenvolvido por terceiros influencia na utilizao do sistema?

Quais so os benefcios e problemas da utilizao de um sistema comprado?

Em que outros aspectos o sistema ERP modificou o seu departamento? E a empresa?

O sistema trouxe alguma oportunidade para mudanas em procedimentos? O sistema trouxe alguma nova idia sobre como realizar algum procedimento especfico?

possvel relacionar a utilizao do sistema ERP com a melhoria no desempenho da empresa?

possvel relacionar a utilizao do sistema ERP com a melhoria na competitividade da

empresa? Em que aspectos? (custo, diferenciao). Atravs de que aspectos do sistema
(automao, redesenho de processos, integrao entre os departamentos, integrao com
clientes e fornecedores, novos negcios)?

O sistema ERP trouxe melhoria a todas as reas envolvidas da mesma maneira? Por que
no?

Como foram, ou esto sendo resolvidos, problemas de localizao no sistemas ERP, caso a
opo tenha sido por um fornecedor estrangeiro?

O sistema tem atendido as necessidades de informaes gerenciais da empresa? Como esto sendo extradas estas informaes?
IV - Utilizao (Apenas Depto de TI)

Os custos e prazos planejados foram atingidos no processo de implementao?

Que outros custos alm dos citados esto sendo percebidos, na fase de utilizao do sistema ERP?

Quais foram as dificuldades tecnolgicas encontradas? (distribuio de dados, comunicao de dados, etc.)

Quais so as tarefas de manuteno de um sistema ERP? Qual o consumo de recursos nestas tarefas?

Existe customizao interna? E externa? Como controlada?

Qual porcentagem estimada do sistema adequou-se empresa sem necessidade de customizao?

Especificamente em relao ao departamento de TI quais foram as mudanas (nmero de

pessoas, perfil, atribuies, etc.) ?

Aps a implementao, a empresa considera o projeto ERP encerrado? Por qu? Por que
no?

263

ANEXO 2 QUESTIONRIO PARA OS GERENTES USURIOS

264

ANEXO 2 QUESTIONRIO PARA OS GERENTES USURIOS

EMPRESA: _____________________________ ENTREVISTADO: ______________________________
DATA: _____________________
CARGO: ______________________________

Dados sobre o departamento/rea

Nmero de funcionrios por departamento
Nmero de funcionrios usurios do sistema
Principais atribuies do departamento/ rea
I Deciso e Seleo

Por que a empresa optou pela utilizao de um sistema ERP?

Quais os benefcios buscados pela empresa ao utilizar um sistema ERP?

A empresa tem alguma caracterstica particular que poderia representar uma dificuldade na
utilizao de ERP?
II - Implementao

Como foi conduzida a implementao do sistema ERP? Quem definiu a metodologia?

Como esta metodologia? Como foi (foram) estruturada(s) a(s) equipe(s) do projeto?

Quais problemas ocorreram durante a implementao? Como foram resolvidos?

Quando surgia uma discrepncia entre o sistema e os processos do(s) departamento(s),

como era resolvida? Quem decidia o que seria feito? Se a alternativa fosse mudar a empresa, como isto era conduzido?

Quais foram os aspectos considerados crticos durante a fase de implementao?

Existiu resistncia mudana? Como foi contornada?

III Utilizao

Quais foram os benefcios trazidos pela utilizao do sistema ERP? Os benefcios esperados pela utilizao do sistema esto sendo obtidos? (Por que no?) Existiram benefcios
no esperados?

Quais foram os problemas que surgiram ou esto surgindo na fase de utilizao? Como
foram, ou esto sendo solucionados?

Como o aspecto integrao entre os mdulos presente no sistema ERP modificou o seu
departamento? E a empresa?

Como o aspecto sistema desenvolvido por terceiros influencia na utilizao do sistema?

Em que outros aspectos o sistema ERP modificou o seu departamento? E a empresa?

O sistema trouxe alguma oportunidade para mudanas em procedimentos? O sistema trouxe alguma nova idia sobre como realizar algum procedimento especfico?

possvel relacionar a utilizao do sistema ERP com a melhoria no desempenho do seu

departamento? Em que aspectos? E no desempenho da empresa?

possvel relacionar a utilizao do sistema ERP com a melhoria na competitividade da

empresa? Em que aspectos? (custo, diferenciao). Atravs de que aspectos do sistema
(automao, redesenho de processos, integrao entre os departamentos, integrao com
clientes e fornecedores, novos negcios)?

265

O sistema ERP trouxe melhoria a todas as reas envolvidas da mesma maneira? Por que
no?
Como foram, ou esto sendo resolvidos, problemas de localizao no sistemas ERP, caso a
opo tenha sido por um fornecedor estrangeiro?
O sistema tem atendido as necessidades de informaes gerenciais de seu departamento? E
da empresa? Como esto sendo extradas estas informaes?

266

ANEXO 3 AUTORIZAES PARA PUBLICAO

275

ANEXO 4 TABELAS DE COMPARAO ENTRE OS CASOS

276

CONTEXTO DAS EMPRESAS

Rhodia Poliamida

Empresa

Categorias/Empresas
Pacote / Origem

R/3 / Estrangeiro

Apresentao da
Empresa

A Rhodia Poliamida resultado da

unio da diviso txtil de duas empresas (Rhodia e Hoechst)

Origem

Multinacional Francesa

Qtde. Plantas

3 localidades (no incio da operao

eram 5)

Produtos e Clientes

Fios de Nylon, para indstrias e confeces

Caractersticas do
processo

Processo em bateladas, combina produo para estoque e sob encomenda

Faturamento /
Funcionrios

US$ 400 milhes/ano e 4.000 funcionrios

CNT/VMM

Bosch

Baan IV / Estrangeiro

R/3 / Estrangeiro

A CNT uma das empresas da VMM,

holding que controla as atividades de
minerao e metalurgia do Grupo Votorantim

A Robert Bosch Limitada a subsidiria brasileira da Bosch, uma das maiores fabricantes de peas para a indstria
automobilstica no mundo

Brasileira

VMM : 7 localidades
CNT : 2 localidades

5 localidades

CNT: Zinco e Cobalto, para siderrgicas e farmacuticas

70% exportado

Processo contnuo, produto commodity

VMM : US$ 400 milhes/ano e 4.000

funcionrios
CNT: US$ 110 milhes/ano e 1.000
funcionrios

Multinacional Alem

Auto peas, para montadoras e distribuidoras, auto-rdios e ferramentas,

para lojas e supermercados

Processo em bateladas, so estabelecidos contratos de fornecimento com as

montadoras

US$ 1,2 bilhes e 13.100 funcionrios

Santista
-

Baan IV / Estrangeiro

A Santista uma das maiores empresas do ramo alimentcio no Brasil

Nacional, pertencente a um grupo

argentino

23 localidades
-

Derivados de soja e trigo (leos,

margarina, maionese, farinha e pes).
26.000 clientes (supermercados, padarias, indstrias). A empresa no exporta

Processo contnuo

US$ 800 milhes/ano e 5.300 funcionrios

277

CONTEXTO DAS EMPRESAS

Rhodia Poliamida

Categorias/Empresas

Sistema(s) Anterior(es)

rea de TI e Dados Tcnicos

Equipe de TI

28 pessoas

A rea foi criada no momento da unio

das empresas origem, j com a inteno
de se implementar um sistema ERP,
com funcionrios da Rhodia. No incio
do projeto, alguns funcionrios de reas
usurias foram incorporados equipe.

Histrico da rea

19 pessoas

A rea foi centralizada na VMM no

momento da criao da holding.

A programao toda terceirizada Os

analistas de negcio fazem a interface
com o fornecedor.

Bosch
-

71 pessoas

Santista
-

32 pessoas

A rea sofreu modificaes durante a

implementao do sistema ERP, sendo dividida em duas gerncias (ger.
Processos e ger., informtica). Essa
estrutura consolidou-se aps a principal parte da implementao.

Muitos analistas entraram na empresa

aps o incio do projeto.

A rea atende tambm s demais

subsidirias do Mercosul

Ainda est envolvida na implementao do R/3 nas demais plantas.

Os analistas de negcio trabalham na

adaptao contnua. H um programador ABAP terceirizado na empresa.

Diretoria Adm. Financeira

Diretoria Adm. Financeira

Diretoria Adm. Financeira

Diretoria Adm. Financeira

VMM: 1.000 usurios

CNT: 300 usurios

3.300 usurios

900 usurios

3 servidores Sun, um em cada empresa,

mais um na VMM para desenvolvimento e testes

5 servidores (4 em Campinas, um em
Curitiba) + servidores de aplicao
onde necessrio

1 servidor IBM

Atividades da rea
Subordinao

CNT/VMM

Usurios

350 usurios

Servidores

1 servidor de banco de dados e um de

aplicao, ambos da Sun

Banco de Dados

Oracle

Informix

Oracle

Oracle

Comunicao

LPs e Microondas

Satlite

Satlite

Frame-relay

Sistemas originados da Rhodia e da

Hoechst. Desenvolvidos internamente
em mainframe IBM. Cada fbrica usava os sistemas da empresa da qual era
originria
Departamentais, integrados por meio de
procedimentos batch, digitao e consolidao em planilhas eletrnicas
Dificuldades para consolidao da
informao entre os sistemas da Rhodia
e da Hoechst
Custos de manuteno do mainframe

Sistemas desenvolvidos internamente,

pelas equipes de TI de cada uma das
empresas. O sistema da CNT era feito
em COBOL, em AS/400

Combinao de desenvolvimento
interno, em COBOL, em mainframe
IBM e pacotes (tal como o COPICS)

Sistemas departamentais desenvolvidos em Clipper, gerenciado por equipes de TI descentralizadas, em cada

uma das plantas

Departamentais, integrados por meio de procedimentos batch ou digitao

Departamentais, integrados por meio

de interfaces batch.

Problemas de qualidade de informao

e dificuldades de integrao

No foram citados

Os sistemas possuam diferenas em

cada uma das fbricas. A consolidao
dos dados era muito difcil (eram 30
servidores espalhados pelas fbricas).

39 pessoas

112 pessoas

69 pessoas

Descrio
-

Integrao
-

Problemas
-

Equipe Anterior

A equipe foi formada no incio da

empresa

Departamentais, Integrados por procedimentos batch ou digitao

278

DECISO E SELEO
Rhodia Poliamida

Categorias/Empresas
-

Motivao
-

Deciso por ERP

CNT/VMM

Y2K
Desligamento do sistema da Hoechst
(em dez/97)
Reduo dos custos de informtica
Atualizao tecnolgica

O desenvolvimento interno no seria

possvel por conta do prazo reduzido
(desligamento do sistema da Hoechst)

Pr-seleo

-----

Seleo

Papel da Matriz

Conduzida com o apoio de consultoria,

teve a participao dos usurios no processo. Selecionou primeiramente um
outro pacote, pois o R/3 no estava disponvel. Antes da deciso, o R/3 foi disponibilizado e foi o escolhido

Dar suporte ao novo modelo de gesto

(holding)
Reduo de custos de informtica
Consolidao da informao das trs
empresas
Reduo da equipe de informtica e
aproveitamento de ganhos de escala dos
fornecedores de ERP

Bosch
-

Teve influncia das matrizes, mas foi

independente

------

Conduzida pela rea de TI., definiu os

finalistas (Baan ou R/3) partindo das necessidades do modelo de gesto (multiempresa, multiplanta e capacidade de
processamento)
Enviados questionrios aos dois finalistas, a respeito de funes que deveriam
ser disponibilizadas pelos sistemas. Escolhido o Baan IV na negociao de
preo e prazo e por sua maior simplicidade

Integrao global da empresa

Reduo mundial de custos de TI
Facilitar a incorporao de novas empresas
No Brasil havia ainda a questo do Y2K

Santista
-

Deciso mundial da Matriz

-----

Definio da Matriz, em dez/95

Deciso da Matriz

------

Preocupaes da TI

Preocupaes dos
Usurios
-

Substituir sistemas desenvolvidos

internamente sob medida

Perda de funcionalidade disponvel nos

sistemas anteriores e atendimento s caractersticas produtivas da empresa
(grande nmero de produtos acabados,
controle de estoque e produo sob encomenda)
Se o sistema iria conseguir faturar,
considerando todas as amarraes que
foram feitas

Localizao, uma vez que no foi possvel ver funcionando em nenhuma empresa

Localizao

Atendimento necessidades especficas

da empresa

atualizao tecnolgica
Y2K
O sistema anterior dificultaria a centralizao da empresa
Dificuldades na consolidao de resultados
O desenvolvimento interno no seria
possvel por conta do prazo (ano 2.000),
e a empresa desejava seguir a tendncia
do mercado
Conduzida com o apoio de consultoria,
que fez o levantamento dos requisitos
junto aos usurios e analistas de sistemas, que possuam grande experincia
na empresa
Os finalistas (Baan IV e R/3) foram
apresentados aos usurios, que atriburam notas aos pacotes.
A deciso final ficou por conta da
negociao de preo, prazo de implementao e clusula estabelecendo preo fixo para o projeto.

Localizao, uma vez que a empresa

opera em diversos estados.
Quantidade de divises e negcios
dentro da empresa
Substituio de sistemas desenvolvidos
internamente

Necessidades da rea comercial e logstica, pela complexidade da operao

279

DECISO E SELEO
Rhodia Poliamida

Categorias/Empresas

CNT/VMM

Bosch

Santista
-

O prazo inicialmente previsto era de 18

meses, e o projeto foi completado em 20
meses. O oramento inicial de US$ 9
milhes, incluindo as licenas do R/3, a
consultoria e o hardware, foi atingido

Prazos e Custos

O prazo para as duas primeiras empresas

era de 10 meses e foi cumprido
Houve atraso de 4 meses na implementao da terceira empresa (a CNT), devido aos problemas de localizao
O oramento do projeto era de R$ 6
milhes, e o gasto real ficou em R$ 5,2
milhes

Os prazos planejados em cada um dos

projetos foram cumpridos, exceo do
primeiro, em Curitiba, que atrasou 4
meses

Os prazos planejados em cada um dos

mdulos, no Jaguar, foram cumpridos,
exceo do mdulo comercial., que
atrasou 12 meses
Os custos foram atingidos, principalmente em decorrncia do contrato a preo fechado
Mas alguns custos adicionais de customizaes que no estavam no contrato,
embora no significativos, ocorreram.

IMPLEMENTAO
Rhodia Poliamida

Categorias/empresas

CNT/VMM
-

Modelo de incio de
operao

Big-bang, com incio em maro de 1.998

Havia um prazo reduzido para implementao e considerava-se muito difcil a separao do R/3 em mdulos

Big-bang, com incio em janeiro de

1.999 (VMM) e junho (CNT).
A implementao em fases foi descartada porque decidiu-se no se investir na atualizao dos sistemas antigos para o Y2K

Bosch
-

Small-bangs nas fbricas e em fases nos

mdulos centralizados.
Pretendia-se na primeira planta (Curitiba)
construir um template para as demais
plantas

No foi utilizado

Os small-bangs trazem risco elevado em

cada planta, mas incentivam a equipe
no desistir nos momentos iniciais, porque
no h como voltar atrs
A necessidade de construo de interfaces
entre o sistema novo e os antigos foi considerada problemtica

Santista
-

Paralelo

No foi utilizado

A Rhodia foi pioneira na implementao

em big-bang do R/3 no Brasil, e havia
preocupaes tanto quanto ao conhecimento da consultoria e fornecedor sobre o
produto e sobre o modelo de implementao
O big-bang tem um papel motivacional,
uma vez que pela dificuldade de voltar ao
sistema anterior, as pessoas se esforam
para superar as dificuldades no incio da
operao

Consideraes sobre o
modelo de incio de
operao

Mdulos

FI, CO, SD, MM, PP e PM

No foi utilizado

O big-bang no foi feito nas trs

empresas simultaneamente porque haveria a necessidade de utilizao de
mais recursos junto consultoria, aumentando o custo do projeto

Finanas (inclui custos e contabilidade), comercial e distribuio, manufatura, servios e controle de projetos

Nas fbricas: MM, PP, SD, QM, WM, FIfiscal, CO-custo do produto.
Centrais: FI, SD, CO

Em fases, tanto nas fbricas como

nos mdulos centralizados (finanas, r.h. e comercial).
O big-bang foi considerado inadequado para a Santista pela sua complexidade e tamanho
Utilizado no r.h. e materiais. O
mdulo financeiro foi convertido
com esgotamento
A necessidade de construo de
interfaces no foi considerada problemtica, uma vez que a equipe da
Santista possua experincia na interligao de seus diversos sistemas.
A implementao de novos mdulos ou dos mesmos em novas fbricas gerou problemas nos mdulos j
implementados.
Centrais: Finanas (menos custos),
rh (Oracle) e comercial e distribuio
Fbricas: manufatura e materiais

280

IMPLEMENTAO
Rhodia Poliamida

Categorias/empresas

CNT/VMM

Bosch

Santista
-

Detalhes

Pioneira do big-bang c/ R/3 no Brasil.

Incio/Trmino

Jul/96 a Mar/98

Durao total

20 meses

Consultoria

Metodologia

Uma das pioneiras do Baan IV no

Brasil

O Brasil foi um dos pioneiros do grupo

Bosch a implementar o R/3

Mar/98 a Dez/00 (estimativa)

11 meses p/ centrais + primeira

fbrica. Tempo total estimado: 34
meses

Do fornecedor,, utilizada no planejamento, gerenciamento e execuo.

Metodologia do fornecedor (Target)

Mar/98 a Jan/99 (UBM e CMM)

A CNT iniciou a operao em Jul/99

Mai/96 a Jun/99

10 meses p/ as duas primeiras empresas, mais 6 meses para a CNT

38 meses

Independente, utilizada no planejamento,

gerenciamento e execuo

Independente, utilizada no planejamento, gerenciamento e execuo

Apoio tcnico, durante a execuo. A

finalidade de no utilizar plenamente a
consultoria era a diminuio da dependncia da empresa

Metodologia do fornecedor, adaptada pela

consultoria

Metodologia do fornecedor (Target),

adaptada pela consultoria

Composta por pessoal da TI, consultores e

usurios-chave
Mdia de 26 pessoas na equipe

Composta por pessoal da TI (6 pessoas), consultores (8 pessoas) e usurios-chave (32 pessoas):

Total: 46 pessoas

Equipe
-

Direo do projeto

Diretor Financeiro Administrativo +

Diretor da Consultoria

Comit Executivo

Diretores e gerentes usurios, reunies

peridicas para validao dos processos

Gerenciamento do projeto
Gerenciamento das
equipes (mdulos)

Destaque
-

- Gerente de Informtica
-

Diretores da empresa e um consultor

independente da FGV, reunies mensais para validao de processos

Gerente de informtica

Gerente de informtica

TI + consultoria

TI + consultoria

Os usurios-chave ficaram concentrados por 10 meses no escritrio central

e receberam uma srie de treinamentos de desenvolvimento pessoal (liderana, negociao), alm dos treinamentos tcnicos

Havia um gerente da consultoria com o

papel especfico de administrar a integrao entre os mdulos
Alguns usurios tornaram-se efetivos da
equipe de TI durante a implementao

Contrato de preo fechado com o

fornecedor para a implementao
do pacote
A implementao dos mdulos
financeiro e r.h. centralizou a operao destas reas

Metodologia do fornecedor (ASAP)

adaptada pela empresa

Composta por pessoal da TI e usurioschave. Cada planta possua uma equipe de projeto.
A de Campinas era composta por 46
pessoas

Composta por pessoal da TI, consultores e usurios-chave. Dividida

nos 5 mdulos.

Gerentes de cada um dos projetos

Diretor Administrativo Financeiro

Diretores da empresa e diretores das

plantas. Se reuniram no incio do projeto
para definir o cronograma das diversas
plantas, bem como a gerncia das equipes

Gerentes das reas usurias, se

reunia mensalmente para validao
dos processos

Gerente de TI + um lder usurio, em cada

uma das equipes das fbricas

Gerente de Informtica

TI + um lder usurio

TI + consultoria

Cada planta tinha uma equipe de projeto.

O comit executivo existiu at a definio
de cada uma das equipes.

Existncia de um gerente de rh na
equipe com a finalidade de facilitar
a mudana cultural
Plano de incentivos voltado ao
sucesso do projeto

281

IMPLEMENTAO
Rhodia Poliamida

Usurios-chave

Categorias/empresas
-

Escolha

Escolhidos pelos gerentes das reas, com

base em critrios de adequao e indicao
da equipe de projeto

CNT/VMM
-

Escolhidos pela equipe de projeto

entre aqueles que conheciam bem os
processos e podiam tomar decises
tcnicas na modelagem

Tempo parcial, conforme a necessidade do

projeto e possibilidade dos usurios

Tempo integral

Localizao do
projeto

Na fbrica de Santo Andr

No escritrio central (VMM)

Treinamento e
tarefas

Modelagem e testes

Envolvimento dos
demais usurios

No informado

Treinamentos sobre o pacote e desenvolvimento pessoal.

Participaram em tempo integral da
modelagem dos processos
Quando havia dvidas, os usurioschave voltavam s suas empresa para
consult-los

Realizado pelos consultores e equipe de TI

Dedicao

Treinamento dos usurios finais

Dificuldades

Realizado pelos usurios-chave

Houve dificuldade em envolver as

gerncias e chefias, pela distncia e
dinmica do processo
Faltou integrao entre os usurioschave e os demais usurios

Lidar com a diferena entre as culturas

(Rhodia e Hoechst)
-

Dificuldades c/ Consultoria

A Rhodia foi um laboratrio para o

fornecedor e a consultoria. Tanto um
quanto o outro tinham poucos conhecimentos a respeito do produto
O desconhecimento do nvel de detalhe
necessrio para o mdulo de custos elevou
a complexidade da implementao do mdulo industrial

Bosch

Santista

Escolhidos pela gerncia das equipes

Escolhidos pela equipe de TI

Tempo parcial, conforme a necessidade do

projeto

Tempo integral, durante os 10

meses da etapa principal

Em cada uma das plantas

Na fbrica do Jaguar

Receberam os treinamentos oficiais da

SAP.
Participaram da modelagem dos processos

Participaram em tempo integral da

modelagem dos processos

No informado

No informado

Realizado pelos usurios-chave

No informado

Houve dificuldades em obter o comprometimento das diversas reas da mesma

maneira, sendo necessrio o envolvimento
da diretoria da empresa
Depois que o comprometimento foi obtido, o projeto, em Campinas, deslanchou

O tamanho da equipe e sua diviso

em 5 mdulos dificultou a comunicao e a modelagem tendo em
vista a integrao. Foi necessrio,
durante o projeto, formalizar a responsabilidade dos lderes das equipes em garantir a comunicao entre elas

O fornecedor no aproveitou a sua

experincia acumulada para evitar
problemas durante a implementao

Despreparo dos consultores em R/3

282

IMPLEMENTAO
Rhodia Poliamida

Categorias/empresas
-

Fatores Crticos de Sucesso, na viso dos

entrevistados

CNT/VMM

Bosch

Participao de usurios que conheam

bem os processos
Realizao de testes o mais completos
possvel
Treinamento profundo nas tarefas
Formalizar o grau de participao (quanti- - No foram citados
dade % do tempo) dos usurios. Como no
havia determinao a respeito, houve diferenas entre a participao dos usurios
das diversas reas e conseqente diferena
nos resultados obtidos

Santista

- No foram citados

- No foram citados

ADAPTAO
Rhodia Poliamida

Categorias/empresas

CNT/VMM

Bosch
-

Diretrizes para adaptao

-

Quem decidia, em caso

de impasse
Estimativas das empresas para o grau de customizao
Dificuldades relativas
customizao

No alterar os programas padro

do R/3, customizando-se apenas
pelo uso de programas externos e
relatrios
A orientao inicial era customizar-se o mnimo possvel

A gerncia do projeto

No geral : 10 %

No informado

A diretriz inicial era no customizar o que no agregasse valor ao

negcio da empresa, ou seja, os
mdulos industrial e comercial
A equipe de projeto se esforou
ao mximo para manter a diretriz
Apenas 10% das solicitaes
foram levadas ao comit

Na primeira planta (Curitiba) optou-se por adaptar

o pacote empresa da maneira mais prxima possvel, porque acreditava-se que seria mais rpido.
Essa orientao gerou atraso na implementao, em
decorrncia do excesso de customizao.
Na segunda planta (So Paulo), optou-se por
abrandar a primeira diretriz, alterando-se a maneira
da empresa trabalhar quando fosse a melhor alternativa, e os resultados foram melhores.
O template comeou a tomar forma s na terceira
implementao

O comit executivo

- No informado

No incio da operao, cerca de

5%.
Aps 10 meses de operao,
cerca de 10%

O gerente de logstica estima que seu mdulo foi

customizado 5%. O mdulo de custos foi bastante
modificado, espelhando exatamente o que havia
antes

Adaptao ao novo sistema, no caso do relatrio de

controle de fornecedores, causou dificuldades

No informado

Santista

A orientao inicial da empresa era

evitar a customizao, que deveria se
restringir aos processos de negcio (industrial e comercial)

Comit executivo

Comercial: 80%
Manufatura: 50%
Materiais e finanas: menos de 20%

A Santista no pretende atualizar o

pacote com as novas verses, uma vez
estabilizado, para evitar a necessidade
de refazer as customizaes

283

ADAPTAO
Rhodia Poliamida

Categorias/empresas

CNT/VMM
-

Adiamento de customizaes

Consideraes sobre a
adaptao

Houve um corte nas modificaes do pacote, para que se evitasse o atraso do projeto, criandose um backlog
Um dos aspectos positivos desse
adiamento foi o fato de que a empresa terminou por se adaptar ao
sistema como ele era

Aps o incio da operao, muitas

dessas melhorias foram postergadas por mudanas nas prioridades
e fatores contingenciais

A diretriz de no se customizar
antes da implantao, alm da reduo do prazo, baseou-se no
princpio de que as solicitaes
feitas pelos usurios aps o incio
da operao seriam mais adequadas nova realidade do sistema
Nos momentos iniciais da operao e suas dificuldades, o fato de
o sistema ter sido muito pouco
customizado levou crticas
A CNT/VMM usou como princpio a idia de que as solicitaes
dos usurios so mais adequadas
quando realizadas aps o incio
da operao

Bosch

Foi possvel verificar o aprendizado da empresa em

relao ao R/3. As ltimas implementaes foram
as que tiveram menor grau de customizao e maiores benefcios

Santista

Durante a implementao existiram

presses para a realizao de alteraes.
As que no foram executadas tornaramse um backlog da rea

A Santista percebeu que grande parte

das solicitaes de customizao eram
relatrios, e utilizou um gerador de relatrios para facilitar o processo, com
grande sucesso

INCIO DA OPERAO
Rhodia Poliamida

Categorias/empresas
-

Problemas de Treinamento (geral)

-

Problemas de Treinamento (uso de um sistema integrado)

Grande nmero de dvidas exigiu

grande trabalho da equipe de projeto e
interrompiam freqentemente o processo
Falta de um material de apoio (apostila)
claro
os usurios no estavam preparados para
trabalhar com um sistema integrado
desconhecimento do funcionamento das
demais reas
desconhecimento do efeito de suas
atividades nas outras reas
dificuldades na mudana da viso
departamental para a viso de processos

CNT/VMM
Os usurios no estavam suficientemente preparados quando iniciou-se a
operao
Apresentaram dificuldades em localizar
as informaes necessrias

Dificuldades em incorporar o novo

sistema em suas atividades

Bosch
-

Apesar do grande nmero de horas totais

de treinamento (30.000 horas p/ 1.000
usurios, em Campinas), ainda h dificuldades na operao do sistemas

o treinamento no considerou a integrao

os usurios desconheciam o efeito de suas
atividades nas outras reas
erros de digitao repercutiam-se em
outros mdulos

Santista
- No foram citados

- No foram citados

284

INCIO DA OPERAO
Rhodia Poliamida

Categorias/empresas

CNT/VMM

Bosch

Santista
-

Motivos para resistncias dos usurios

Dificuldades Operacionais

Decorrentes do aumento de tarefas por

necessidades de outras reas
Grande ansiedade em localizar as informaes como eram no outro sistema
O sistema mostra erros que estavam
escondidos, e, segundo os usurios, o
sistema d muito problema e no nos
deixa trabalhar
Em decorrncia dos problemas de
treinamento, a performance do processo
no incio foi muito inferior do sistema
anterior, o que prejudicou a operao da
empresa na primeira quinzena
O big-bang em 5 locais exigiu muito
esforo da equipe de projeto
A converso dos dados demorou mais
que o previsto
Erros de digitao foram propagados
para outros mdulos
Problemas na interface com sistema de
controle de estoque e na operao do
material-ledger

Localizao

Problemas de localizao (emisso de

nfs e livros fiscais), em decorrncia do
pioneirismo

O sistema eliminou os estoques de problemas, obrigando sua soluo imediata

e tornando as atividades da rea transparentes aos outros departamentos

Os deptos. da CNT eram muito isolados,

o que tornou mais difcil a integrao
entre os processos

Aumento de trabalho percebido no novo

sistema (mais telas e mais campos)

A localizao foi o principal problema

no incio da operao, chegando a comprometer a operao nas duas primeiras
empresas (cobrana e livros fiscais),
Foi decorrncia do pioneirismo no uso
do Baan IV

As interfaces construdas entre os sistemas

antigos e o novo foram a fonte de muitos
problemas, tal como a inconsistncia e erros nos valores
Apenas aps o trmino da implementao
em todas as plantas foi possvel eliminar o
problema das interfaces temporrias
A necessidade de interfaces surge tanto no
modelo small-bang quanto no em fases

Ainda h dificuldades para emisso dos

livros fiscais e controle de juros em duplicatas, feitos manualmente em planilhas
A legislao municipal deve ser atendida
por programas externos, pois no contemplada pelo pacote

Dificuldades especficas

Fatores Crticos de Sucesso, na viso dos

entrevistados

Unio de duas empresas

Treinar os usurios finais adequadamente, considerando a questo da integrao do sistema

Tambm envolver os usurios finais no
processo

Implementao em trs empresas diferentes

- No foram citados
-

Muitas linhas de produtos e grande nmero de usurios, resultando em um projeto

mais complexo.

Os sistemas anteriores eram feitos

sob medida, eram apreciados pelos
usurios, e houve reclamaes
quanto dificuldade de operar o
novo sistema
Uma das maneiras de contornar a
situao foi a promessa de mudanas, a serem feitas aps o incio da
operao (presso pela customizao)
Problemas de performance, decorrentes do projeto do ERP no levar
em considerao necessidades reais
do processamento
Houve um custo no esperado,
decorrente da necessidade de aumento da capacidade de processamento do servidor
No caso do comercial, onde o
volume de notas fiscais era muito
elevado (4.000 nfs/dia) houve a necessidade de interromper a operao
e rever as customizaes
No ocorreram grandes problemas
Emisso de livros fiscais feita em
outro pacote
A troca de arquivos com bancos
feita em um mdulo satlite desenvolvido na empresa
Grande nmero de plantas, muitas
linhas de produto, resultando em
um projeto mais complexo.
Dificuldade de comunicao entre
as equipes

Presena de lderes que saibam administrar

a tenso nos momentos iniciais da operao
- No foram citados
Obter o comprometimento dos gerentes
das reas usurias

285

INCIO DA OPERAO
Rhodia Poliamida

Categorias/empresas
-

Novos Aspectos Verificados / Aspectos Presentes Verificados

CNT/VMM

Dificuldade em testar antes do incio da

operao todas as possibilidades de uso
e eliminar todos os problemas
Dificuldades em trabalhar em um sistema integrado decorrem da mudana de
responsabilidades e transparncia das
atividades

Bosch

Dificuldade em testar antes do incio da

operao todas as possibilidades de uso
e eliminar todos os problemas

Santista

Os mdulos j implementados (industrial)

trouxeram restries e dificuldades para a
implementao dos mdulos seguintes

Os mdulos seguintes tambm

trazem impactos aos mdulos j
implementados

UTILIZAO: BENEFCIOS
Rhodia Poliamida

Categorias/empresas

CNT/VMM
-

Permitiu a implementao do modelo de

gesto corporativo

Equipe de informtica foi reduzida de

39 p/ 19 pessoas

Gerais

Unificao dos sistemas

Custos

Diminuio de custos de informtica

Evoluo profissional: entender o

papel e a responsabilidade nos proces- sos
Essa evoluo no foi imediata, mas
fruto de uma presso por resultados
Aprendizagem de que a responsabilidade pela informao correta de todos os departamentos

Pessoas

Integrao
-

Fechamento da Contabilidade

Mudana no processo de controle de

qualidade da informao, de inspeo final para controle de processo
Mudana do papel da rea de contabilidade
A integrao faz com que as atividades dos departamentos fiquem transparentes, mostrando erros que estavam escondidos

De 10 p/ 4 dias

Evoluo profissional: as pessoas tm a

sua viso e conhecimento empresarial
ampliados
As pessoas tornam-se mais responsveis
pelas suas atividades e pelas informaes geradas por elas

Bosch
-

Sistema globalizado

Reduo de pessoal na rea financeira, de

70 p/ 55 pessoas

A TI passa a ter uma viso macro da

empresa e a entender os seus processos
Evoluo profissional: aumento do comprometimento com a qualidade da informao

Como uma atividade est ligada a outra,

o sistema obriga s pessoas a executarem suas atividades corretamente, em
um momento preestabelecido. Isso aumenta o controle sobre as atividades da
empresa
Dessa maneira, h garantia de que toda
a informao est registrada no sistema, e consequentemente, um aumento
na qualidade da informao
Eliminou a necessidade de redigitaes
e inconsistncia entre sistemas

De 12 p/ 5 dias

Digitao nica
Eliminao de diferenas entre diversos
sistemas, existentes na situao anterior
Transparncia nos processos, o sistema
mostra onde os processos esto errados
Uma vez que obrigatrio o registro das
atividades corretamente e no momento
adequado, h aumento da qualidade da informao, pois no se perde nada, tudo
vai para o resultado
Isso reflete tambm em maior controle
sobre as operaes
De 30 p/ 15 dias

Santista
-

Centralizao dos sistemas em uma

empresa com grande nmero de plantas

Reduo de custos, relativa centralizao dos departamentos

A integrao o grande mrito de

um sistema ERP
A integrao traz disciplina e controle
s operaes, sistematizando atividades realizadas de maneira improvisada
O sistema ERP obriga a um maior
planejamento das operaes da rea
industrial, uma vez que outras reas
utilizam os dados da produo
Por esse motivo, a integrao traz
mais sincronismo entre as reas
Tambm evita custos por impedir
correrias

No informado

286

UTILIZAO: BENEFCIOS
Rhodia Poliamida

Categorias/empresas

CNT/VMM

Bosch

Santista
-

Abrangncia (funcional
e geogrfica)

Padronizao de procedimentos na
empresa, independentemente da
planta

Controle remoto da planta de Niquelndia

Tcnicos

Maior flexibilidade para alteraes, uma

vez implementado

Outras

Novas idias ou possibilidades trazidas pelo

pacote

Competitividade
-

Disponibilizao de informaes online

No trouxe muitas novas idias, uma

vez que os sistemas anteriores eram
muito bons e muitas funcionalidades
foram transportadas para o R/3
Como o pacote extremamente
flexvel e genrico, ele no traz novas
idias, mas adapta-se a empresa

No possvel associar o sistema ERP

melhorias na competitividade empresarial
A empresa j era enxuta, no houve
reduo de pessoal
No havia problemas srios nos
sistemas anteriores
As decises esto mais bem suportadas
-

A informao est mais segura e confivel, em comparao ao sistema anterior

O sistema melhorou bastante a empresa,
pois a empresa estava carente de sistemas

Sistema de requisies de almoxarifado

on-line, eliminando desperdcio de tempo
Foi possvel o gerenciamento remoto da
planta de Niquelndia
Ainda no possvel associar o sistema
ERP a melhorias na competitividade
empresarial, falta a implementao de
ferramentas tais como o SCM e o ebusiness
Houve redues nos nveis de estoque
de matrias-primas em decorrncia do
maior controle e do processo de reviso
que foi feito para a implementao
As decises esto mais bem suportadas

Flexibilidade tecnolgica para acompanhar

as novas necessidades da empresa
Diminuio da dependncia dos usurios
em relao TI devido ao grande nmero
de possibilidades do sistema
Possibilidade de aproveitar a evoluo
tecnolgica do pacote
Aumento da produtividade administrativa,
uma vez que a empresa pde aumentar sua
complexidade (plantas e produtos), gerenciando-a com o mesmo nmero de pessoas

Facilitou a centralizao das atividades administrativas

Padronizao de atividades nas diversas fbricas
Permite que pessoas de uma fbrica
possam trabalhar em outras
Eliminao de diferenas entre sistemas que antes eram fragmentados
Padronizao dos conceitos empregados para clculos nos diversos sistemas

Eliminao de uma srie de sistemas

diferentes por um nico sistema centralizado

Aumento da qualidade da informao

consolidada, porque antes era necessrio um trabalho complexo e sujeito a
erros
Quebra de feudos de informao,
pois a informao disponibilizada
on-line para toda a empresa

Utilizao de ordens de produo repetitivas

Conexo das mquinas de produo

ao sistema ERP

No possvel associar o sistema a melhorias em performance, pois durante o tempo

de durao do projeto a empresa tomou
outras medidas
Houve uma melhoria no tempo de resposta
solicitaes dos clientes, porque o MRP
pode ser executado diariamente
Em um primeiro momento, foi necessrio
mais gente para operar o sistema

Segundo os entrevistados, o ERP no

fator de competitividade, mas de sobrevivncia
O uso do sistema ERP em conexo s
mquinas de produo permitiu a homogeneizao da qualidade dos produtos em todo o pas
A empresa pode controlar todas as
fbricas de maneira centralizada

287

UTILIZAO: BENEFCIOS
Rhodia Poliamida

Categorias/empresas

CNT/VMM
-

Consideraes e Destaques
Fatores Crticos de Sucesso, de acordo com os
entrevistados

Os entrevistados entendem que as reas

que geram as informaes esto trabalhando mais, mas com benefcios para
toda a empresa
Os entrevistados entendem que esse
aumento de trabalho poderia ter sido reduzido por meio de customizaes

Manuteno correta dos cadastros do

sistema crtica para a operao,
A responsabilidade pelos cadastros
deve ser adequadamente dividida

No foram citados

Bosch
-

Aumentou o trabalho nas reas onde as

informaes so geradas, mas com benefcios para o todo da empresa

No foram citados

Santista
-

A conexo das mquinas de produo

ao sistema ERP trouxe grande confiabilidade nas informaes de todo o
processo, uma vez que a prpria atividade de produo passou a fazer parte
dos processos controlados pelo sistema ERP

No foram citados

UTILIZAO : DIFICULDADES
Rhodia Poliamida

Categorias/empresas

CNT/VMM
-

Pessoas
-

Tcnicos
Abrangncia (funcional
e geogrfica)

Excesso de dados no banco de dados,

uma vez que o sistema registra um grande nmero de transaes e lanamentos
O sistema pode parar a empresa
Velocidade de propagao de erros de
digitao

Dificuldade em as pessoas entenderem a

viso de processos
Perdeu-se o investimento nos usurioschave, pois esses foram reabsorvidos
pelas suas tarefas operacionais
O excesso de burocracia, isto ,
grande quantidade de telas e campos a
serem preenchidos, causa insatisfao
por parte dos usurios
ERP desenhado sem a preocupao com
a performance
Problemas decorrentes da interao
entre ERP x Banco de Dados x Sistema
Operacional

Bosch

Santista
-

Dificuldades em adaptao s informaes como disponibilizadas no sistema

Problemas de performance e lentido

nos processos

Dificuldade em fazer o usurio entender o seu papel no processo como um

todo, pois o sistema muito complexo
O sistema ERP exige pessoal mais
qualificado parra que se evitem erros
na operao

ERP desenhado sem a preocupao

com a performance

Digitaes erradas em vendas, estoques, produo podem acarretar erros

nas quantidades produzidas

288

UTILIZAO : DIFICULDADES
Rhodia Poliamida

Categorias/empresas

CNT/VMM

Bosch

Santista
-

Processos

Relatrios Gerenciais

Atualizao de verses
ou correo de programas

Custos Adicionais percebidos

Algumas funcionalidades existentes nos

sistemas anteriores foram perdidas

Faltam relatrios gerenciais no sistema,

compensam-se com planilhas eletrnicas -

A atualizao de verses exige tempo de

preparao, testes e implica em custos
adicionais
A atualizao para a verso 4.6 est
sendo encarada como um novo projeto

Treinamento da equipe de TI
Salrios
Custos p/ mudana de verses

Algumas funcionalidades foram perdidas

Algumas funcionalidades no puderam
ser implementadas em conseqncia da
grande quantidade de telas e campos
para que possam ser executadas

Faltam relatrios, gerenciais e operacionais

Usam-se planilhas eletrnicas para
consolidar os dados

Cada nova verso ou correo exige que

se reverifiquem programas j estabilizados
A VMM no est mais baixando atualizaes no sistema para evitar problemas

Retreinamento de usurios
Custos para adaptao contnua e novas
customizaes

O sistema no atende a uma srie de

funcionalidades dos sistemas anteriores
Dificultou o trabalho do usurio em
decorrncia do grande nmero de telas e
campos a serem preenchidos

Pobre em informaes gerenciais

O sistema fornece as informaes do
jeito que ele acha que deve ser

A atualizao para a nova verso do R/3

(4.6) tem custos associados reviso de
processos, retreinamento, redesenvolvimento de customizaes, ampliao de
equipamentos e consultoria
A Bosch entende essa atualizao como
obrigatria, uma vez que o suporte s
verses anteriores tem prazo limitado
H entretanto um benefcio com a
atualizao: a possibilidade de reveremse os procedimentos, j com maiores
conhecimentos sobre o sistema e a utilizao das novas caractersticas da verso

Treinamento constante dos usurios

Custos p/ mudana de verses

A disciplina e a necessidade de planejamento tiram um pouco a flexibilidade da operao, no mdulo industrial

Processos muito genricos impem
ordem de tarefas no tima, e excesso
de telas e campos a serem preenchidos
No incio da operao foi necessrio
aumentar o quadro do contas apagar,
devido s dificuldades citadas

Faltam relatrios gerenciais e operacionais

A Santista no pretende atualizar o

sistema ERP, uma vez que esteja estabilizado, fazendo as alteraes necessrias com sua equipe interna

289

UTILIZAO : ADAPTAO CONTNUA

Rhodia Poliamida

Categorias/empresas
-

Consideraes sobre a
adaptao contnua

Dificuldades para a
adaptao contnua

Nos primeiros momentos, a urgncia

colocar o pacote em funcionamento,.
Somente aps a estabilizao possvel
pensar em melhorias na utilizao
O Conhecimento surge aps o uso, pela
complexidade do software
A aprendizagem sobre o R/3 permite a
melhoria nos processos que j foram
implementados da maneira mais difcil
A adaptao contnua necessria em
decorrncia de mudanas na operao da
empresa e fatores contingenciais
A perda no foco do projeto traz dificuldades em reunir as reas envolvidas e
definir responsveis pela implementao
das novas alteraes ou funcionalidades
necessrias
Novas prioridades e contingncias
ocupam os recursos disponveis
Dificuldade em obter conhecimentos
junto aos consultores, necessrios para a
adaptao contnua

CNT/VMM

Bosch

A Bosch criou um departamento na logstica

para acompanhar e promover as mudanas
no sistema
Segundo o gerente da rea, ns vivemos do
sistema, necessrio um recurso voltado
sua evoluo

Santista

Aps o incio da operao h

presses p/ a customizao de pequenos detalhes (reduo de telas,
eliminao de campos), que transformam-se em um backlog

H dificuldades em realizar
alteraes ou corrigir problemas
porque necessrio envolver
muitas pessoas

290

CONTEXTO DAS EMPRESAS

AgroLaranja

Categorias/Empresa

Empresa

Pacote / Origem

Logix / Nacional

Vine Txtil
-

Magnus / Nacional

Zeneca
-

R/3 / Estrangeiro

A Zeneca a subsidiria da diviso

agroqumica da AstraZeneca, uma
das maiores empresas farmacuticas
do mundo

Melhoramentos Papis
-

Logix / Nacional

A Melhoramentos Papis (MP) resultado

da unio da diviso de papel absorvente da
Companhia Melhoramentos de So Paulo
com a Kymberly Clarke do Brasil, em
1.994

Apresentao
da Empresa

a principal de um grupo de 80 empresas

Uma das empresas txteis do grupo

Vicunha

Origem

Nacional

Nacional

Multinacional Inglesa

Nacional

A AgroLaranja possui 3 localidades,

mas o Logix atende ao grupo, com 80
empresas

7 localidades (6 fbricas e um escritrio

e depsito central)

4 localidades (2 fbricas, escritrio

e depsito)

7 localidades (2 fbricas, um escritrio

central e 4 escritrios de vendas)

Tecidos e malhas de algodo, nylon e

polister, para confeces e varejistas

Defensivos agrcolas, para distribuidores e fazendeiros

Suco de laranja concentrado, para

empresas envasadoras
99% da produo exportada

Produtos de papel absorvente, atendendo

2 tipos de clientes: consumo e institucionais

Processo contnuo

Em lotes, com a complexidade de haver

grades de produtos

No informado

Em bateladas

AgroLaranja:US$ 400 milhes/ano e

750 funcionrios
Grupo Fischer: 800 milhes/ano e 8.000
funcionrios

U$ 120 milhes/ ano e 2.480 funcionrios

US$ 250 milhes/ano e 600 funcionrios

US$ 120 milhes/ano e 840 funcionrios

Qtde. Plantas
Produtos e
Clientes
Caractersticas
do processo
Faturamento /
Funcionrios

291

CONTEXTO DAS EMPRESAS

AgroLaranja

rea de TI

Categorias/Empresa

Vine Txtil

Equipe de TI

21 pessoas

Histrico da
rea

A rea atende s 80 empresas do grupo

Os analistas de negcio fazem a ligao

entre os usurios e o fornecedor, testam
e instalam alteraes e novos desenvolvimentos
A programao toda terceirizada
A rea utiliza um gerador de relatrios

Subordinao

Vice-presidncia da empresa

No informada

Usurios

AgroLaranja: 250 usurios

Fischer: 400 usurios

110 usurios

1 Servidor HP Unix

1servidor HP Unix, que centraliza o

processamento do grupo
H um servidor p/ testes e backup

Banco de Dados

Informix (exigido pelo Logix)

Comunicao

Rede TopNet da Embratel e Satlites

nas fazendas

Desenvolvidos em Oracle Forms, alm

de alguns em Clipper e Access
Os sistemas em Oracle foram desenvolvidos em 1.993, para substituir sistemas
em mainframe
Nas demais empresas do grupo, tambm eram utilizadas uma srie de linguagens e plataformas

Atividades da
rea

Servidores

Descrio dos Sistemas

Anteriores

14 pessoas

A rea expandiu-se quando foi implementado o sistema ERP

Os analistas de sistemas desenvolvem

melhorias e relatrios para o sistema,
Acompanham as necessidades dos
usurios, apresentando e executando
projetos
A rea desenvolve programas externos
ao Magnus

Zeneca
-

14 pessoas

Os funcionrios da rea esto na

empresa desde a poca do mainframe

Departamentais, integrados por meio de

procedimentos batch ou digitao

11 pessoas

A rea originria da KCB, e uma de suas

primeiras misses foi a unio dos sistemas

Os analistas de negcio fazem a ligao

entre os usurios e o fornecedor, testam e
instalam alteraes e novos desenvolvimentos
H um terceiro em tempo inte4gral, do
fornecedor, que faz a programao de relatrios e mdulos satlite

Presidncia

Diretoria Financeira

180 usurios (15 deles fora do pas,

na Europa e EUA)

120 usurios

3 Servidores Compaq: um para

desenvolvimento, outro para testes e
outro para a produo

1 Servidor HP Unix
H um servidor p/ testes e backup

Progress (exigido pelo Magnus)

Oracle

Informix (exigido pelo Logix)

Satlite

Frame-relay e LPs

LPs e Rdio (Mogi)

Antes do R/3: pacote integrado

americano (PACOTE A)
Antes do PACOTE A: sistemas
desenvolvidos internamente em
COBOL, mainframe IBM

Mdulos de sada: Desenvolvimento

interno em COBOL/mainframe UNISYS
Mdulos de entrada: pacote integrado
(BPCS)
Essa arquitetura foi o resultado de
necessidades tcnicas presentes na unio
das empresas

Sistemas desenvolvidos por um bureau

de servios que atendia ao grupo
Desenvolvidos em COBOL, mainframe
IBM

Integrao dos Sistemas

Anteriores

Os analistas de negcio fazem a

ligao entre os usurios e o fornecedor, testam e instalam alteraes
e novos desenvolvimentos

Melhoramentos Papis

Departamentais, integrados por redigitao

PACOTE A: integrado, por procedimentos batch

Sistemas em mainframe:: departamentais, integrados por procedimentos batch

Os mdulos de entrada no eram integrados aos mdulos de sada, havendo a

necessidade de digitao

292

CONTEXTO DAS EMPRESAS

AgroLaranja

Categorias/Empresa

Vine Txtil
-

Problemas dos Sistemas

Anteriores

Integrao

Equipe Anterior

47 pessoas

Zeneca

Custo elevado do servio do bureau

OS relatrios eram executados noite
no bureau e trazidos pela manh empresa
Os sistemas eram feitos sob medida
para as empresas, mas havia dificuldade
em obter alteraes por conta de prazos
e custos

7 pessoas

Melhoramentos Papis

Sistemas em mainframe: custos

PACOTE A: dificuldades na manuteno (havia sido muito customizado, em decorrncia da pouca
disponibilidade de funes) e problemas de qualidade no pacote
Antes do R/3: 13 pessoas
Antes do PACOTE A: 40 pessoas

Mdulos de sada: custo elevado

Sistemas no unificados

A equipe foi formada na criao da empresa

DECISO E SELEO
Categorias/
Empresas

AgroLaranja
-

Motivao

Deciso por
ERP

Reduo dos custos de TI

Unificao dos sistemas no grupo e padronizao das atividades administrativas nas diversas empresas
Y2K
A linguagem Oracle Forms 3 iria ser descontinuada, o que obrigaria a substituio
dos sistemas
O redesenvolvimento foi considerado mais
custoso e com prazo mais longo
O vice-presidente veio de uma empresa onde
um ERP foi implementado com sucesso

Vine Txtil

Zeneca
-

Reduo de custos de TI
Atualizao tecnolgica
Dificuldades (custo e prazo) para
obteno de alteraes no sistema

Auxlio de consultoria que indicou a

substituio do software como necessrio para melhorar os processos
administrativos e reduzir custos

Para o PACOTE A: processo mundial de

downsizing
Para o R/3: Y2K, a atualizao do
PACOTE A seria mais custosa do que a
implementao do R/3 e a matriz j havia
definido um plano para a implementao
do R/3 no mundo

Da matriz

Melhoramentos Papis
-

Unificao dos sistemas da empresa

Obteno de relatrios consolidados
Reduo de custos de informtica (altos, em
decorrncia do mainframe da CMSP)

Decidiu-se dividir o projeto em duas etapas,

substituindo-se primeiro os mdulos de sada e depois os mdulos de entrada
O foco inicial eram os mdulos de sada,
em decorrncia dos custos e necessidade de
adequao nova empresa
Com base em critrios tcnicos: abrangncia
funcional, integrao, BD relacional, atendimento a requisitos bsicos da rea comercial e existncia de clientes que pudessem
atestar o funcionamento do pacote
Foram selecionados 3 finalistas (Logix,
Magnus e Triton Baan)

Pr-seleo

Papel da Matriz

Realizada com base em critrios tcnicos:

possibilidade de usar banco de dados Informix e que tivesse grande abrangncia funcional

-----

-----

-----

-----

Ofereceu duas opes: atualizar o

PACOTE A ou implementar o R/3

-----

293

DECISO E SELEO
Categorias/
Empresas

AgroLaranja
-

Seleo

Os finalistas foram apresentados aos usurios

O Logix foi escolhido pela melhor relao
custo/benefcio e porque possua mdulos
de exportao e r.h. prprios
Tambm foi escolhido porque a negociao
e execuo das customizaes necessrias,
incorporando-as aos programas-padro, foi
considerada mais simples e barata. A Logocenter foi a nica que concordou em incorporar as alteraes aos mdulos-padro

Vine Txtil
-

Preocupaes da
TI

-----

Preocupaes
dos Usurios

-----

Prazos e Custos
-

A seleo foi feita pela consultoria

e equipe de TI, no incio de 1.994
O Magnus se destacou na poca
O usurio no foi envolvido no
processo de seleo, o que gerou alguma resistncia na implementao
Para o mdulo industrial, foi selecionado um pacote especfico para a
rea txtil (SGT)

Adequao do pacote s especificidades do processo txtil, o que levou aquisio do SGT

-----

Os prazos previstos para a implementao

dos mdulos na AgroLaranja foram atingidos.
Os custos planejados foram ultrapassados em
decorrncia de um grau de customizao
maior que o previsto
Foram investidos US$ 680 mil no projeto,
incluindo licenas, hardware, treinamento e
customizaes

Zeneca
-

Tanto os custos como os prazos

planejados foram atingidos
Havia grande presso sobre o prazo,
pois o contrato com o bureau seria
encerrado

PACOTE A: No informado
R/3: A Zeneca possua duas alternativas,
oferecidas pela matriz: atualizar o
PACOTE A ou implementar o R/3, aderindo mais rapidamente nova determinao da empresa (plano mundial que ser
iniciado em 2.000)
Optou-se pelo R/3, pois a atualizao do
PACOTE A seria mais custosa, o R/3 possua mais opes e estava tecnologicamente mais avanado e a empresa aderiria
mais rapidamente ao plano da matriz
PACOTE A: substituio de sistemas
feitos sob medida, e a descrena em
pacotes
R/3: modelo escolhido: big-bang
R/3: se os problemas ocorridos na implementao do PACOTE A se repetiriam
R/3: Se o pacote poderia atender detalhes
da operao comercial e contas a receber

Melhoramentos Papis
-

Levantados, junto aos usurios das reas

comercial, financeira e fiscal (reas da 1
etapa), requisitos considerados importantes
Com base nesses requisitos, e em requisitos
tcnicos, foi elaborado um conjunto de critrios e pesos
Os usurios assistiram apresentaes e
pontuaram os pacotes
A escolha , feita em mar/95, recaiu sobre o
Logix

-----

Saber se os mesmos relatrios presentes no

sistema anterior existiriam no novo sistema
(da rea comercial)

Aps a escolha a equipe enfrentou o adiamento do projeto por motivo de troca de presidncia e outras prioridades de investimento., por 3 meses A implementao iniciou-se
em jul/96

R/3: O prazo inicialmente estabelecido era

de 9 meses, e houve um atraso de 1 ms
em decorrncia de riscos percebidos nos
testes

IMPLEMENTAO
Categorias/
Empresas

AgroLaranja

Vine Txtil

Zeneca

Modelo de incio de
operao

Em fases, inicialmente na AgroLaranja e depois sendo gradualmente

implementados nas demais empresas

Big-bang, substituindo-se simultaneamente os principais mdulos usados na

empresa

R/3: Big-bang
PACOTE A: em fases

Paralelo

No foi utilizado

Utilizado na contabilidade por um ms

No foi utilizado

Melhoramentos Papis
-

Em fases, em duas grandes etapas (etapa

1 = mdulos de sada e etapa 2 =
mdulos de entrada). Entre e aps as
etapas foram implementados outros mdulos complementares

No foi utilizado

294

IMPLEMENTAO
Categorias/
Empresas

AgroLaranja

Vine Txtil

Zeneca
-

Consideraes sobre o modelo de

incio de operao

A implementao em fases exigiu a

construo e manuteno de interfaces, o que foi considerado trabalhoso
No foram relatados problemas
relacionados s interfaces

-----

Mdulos
-

Comercial, fiandeiro, contabilidade,

suprimentos, r.h., exportao e patrimnio

Detalhes

Aps a implementao, cada empresa

continuou a ter a sua prpria rea administrativa
A definio dos conceitos e modo de
operao das reas de r.h., finanas e
suprimentos ficaram centralizados na
AgroLaranja

Incio/Trmino

Abr/97 a Dez/00 (previsto)

A implementao dos principais

mdulos na AgroLaranja demorou 9
meses
No momento da realizao das entrevistas ainda estavam sendo implementados os mdulos nas outras empresas do grupo. A durao total estimada de 45 meses

Durao total

Consultoria

Do fornecedor, utilizada apenas para

apoio tcnico e treinamento

Comercial, financeiro, contabilidade,

suprimentos e patrimnio
O custos no usado pois exigiria a
implementao do mdulo industrial do
Magnus

Melhoramentos Papis

As vantagens do big-bang so a criao

de um senso de urgncia na empresa que
fora um estabelecimento de prioridades
em relao ao projeto e a grande dificuldade em voltar atrs. Na implementao por fases, s os departamentos envolvidos no mdulo que est sendo implementado se preocupam
Outra vantagem do big-bang a eliminao da construo de interfaces
O principal risco do big-bang ser
necessrio voltar atrs alguns dias aps
o incio da operao
FI, CO, SD, MM, PP-PI
-

O prazo para implementao do sistema

era de 4 meses, e no podia ser alterado
porque j havia sido negociado com o bureau a data para o trmino do servio

Mar/94 a Jul/94

4 meses

Do fornecedor, utilizada no planejamento,

gerenciamento e execuo

Houve apoio de um grupo americano da

empresa, especializado em R/2
O objetivo era a elaborao de um
template que seria utilizado nas prximas implementaes do R/3 na Zeneca
(Guatemala e HK)
Nov/97 a Ago/98

10 meses

Usada consultoria externa no incio do

projeto. A partir do meio do projeto, a
Zeneca conduziu sozinha, usando apoio
tcnico do fornecedor

A razo para a diviso em etapas foi a

urgncia na substituio dos sistemas
de sada e a necessidade de dividir o
projeto por questes de custos

Etapa 1: comercial, crdito e cobrana

Etapa 2: suprimentos, contabilidade,
contas a pagar, custos
R.H., manuteno industrial, patrimnio
e tesouraria
Os principais problemas enfrentados
pela empresa, referentes ao modo de
implementao escolhido, foram o tempo decorrido entre as etapas, por fatores
contingenciais, e a no considerao das
necessidades dos mdulos da segunda
etapa, na implementao dos primeiros
mdulos

Etapa 1: Jul/95 a Nov/95

Etapa 2: Out/96 a Fev/97

Projeto todo: 18 meses

Etapa 1: 4 meses
Etapa 2: 4 meses
Fatores contingenciais atrasaram a
segunda etapa por 10 meses

Do fornecedor, utilizada apenas para

apoio tcnico e treinamento

Definida pela equipe, com base na

utilizada p/ implementar o BPCS

Metodologia

Definida pela equipe

Do fornecedor

Do fornecedor (ASAP)

295

IMPLEMENTAO
Categorias/
Empresas

AgroLaranja
-

Equipe

Composta por pessoal da TI, usurios

e consultores do fornecedor
Uma equipe de trs pessoas
(TI+usurio+consultor) para cada
mdulo

Vine Txtil
-

Composta pela equipe de informtica e

consultores
Foi dividida por mdulos

Zeneca
-

Melhoramentos Papis

Composta por pessoal da TI e consultores (empresa independente no incio e

do fornecedor)

Composta por pessoal da TI, usurios e

consultores do fornecedor
Dividida por mdulos

No informado

Diretor Financeiro

Presidente + gerentes usurios + gerente

de TI

No havia

Direo do projeto

Vice-presidente

- Gerente de informtica

Comit Executivo

No havia

No havia

Gerente de Informtica

Gerente de Informtica

Gerente de Informtica

Gerente de informtica

Equipe de TI

TI + consultoria

Equipe de TI

Lder de mdulo (usurio)

Durante a implementao foram contratadas mais duas pessoas para a rea de TI, j
com experincia em Magnus

O projeto foi conduzido pela TI com

baixo envolvimento do usurio
O grande conhecimento da rea a respeito dos processos foi considerado
como fundamental para o sucesso da
implementao

Na primeira etapa, o projeto foi conduzido pela TI com baixo envolvimento do

usurio
Na segunda etapa, o envolvimento do
usurio foi maios

Gerenciamento do
projeto
Gerenciamento das
equipes (mdulos)

Usurios-chave

Destaque

Escolha

Escolhidos pela equipe de projeto

Dedicao

Tempo parcial, envolvidos quando

necessrio

-----

-----

Em Mato, no escritrio central

-----

-----

Treinados no Logix, participao na

modelagem dos processos

-----

-----

Localizao do
projeto
Treinamento e
tarefas

-----

Envolvimento
dos demais
usurios

Foram envolvidos nas etapas finais

(testes e cadastramento de tabelas)

Foram entrevistados quando era necessrio.

Participaram das etapas finais (testes e
cadastramento de tabelas)

Os usurios envolvidos no foram

retirados do seu dia-a-dia
Eram consultados pela TI quando necessrio
Segundo os usurios, quando havia
algum problema, o pessoal j trazia solues detalhadas para que pudssemos
escolher a melhor alternativa

Escolhidos pela equipe de projeto

Etapa 1:Tempo parcial, envolvidos

quando necessrio
Etapa 2: Tempo parcial, gerenciavam
seu envolvimento

Em So Paulo, no escritrio central

Treinados no Logix, participao na

modelagem dos processos

Foram envolvidos nas etapas finais

(testes e cadastramento de tabelas)

296

IMPLEMENTAO
Categorias/
Empresas
Treinamento dos
usurios finais

AgroLaranja
-

Realizado pelos consultores do fornecedor

Fatores contingenciais alteraram a

ordem de implementao prevista, e o
mdulo de r.h. foi implementado inicialmente em outra empresa do grupo
Apesar disso, o sucesso dessa primeira implementao de emergncia
trouxe credibilidade equipe e ao pacote
A implementao em diversas empresas do grupo, com atividades diferentes representou dificuldades pela exigncia de maior quantidade de customizaes
Entretanto, a flexibilidade do pacote
auxiliou bastante nesse aspecto

Dificuldades
-

Vine Txtil
-

Carncia de conhecimentos dos

consultores a respeito do produto

No momento dos testes percebeu-se a

impossibilidade do Magnus para o faturamento de acordo com as necessidades da
empresa
Houve dificuldade em convencer o fornecedor a realizar as alteraes necessrias e
ampliou-se a integrao com o SGT

No informado

Melhoramentos Papis
-

Realizado pelos usurios-chave e consultores do fornecedor

Um dos principais objetivos da primeira

etapa era a redefinio do processo de
faturamento da empresa
Isso exigiu extensa customizao do
pacote, um trabalho mais tcnico, o que
levou a um envolvimento mais baixo do
usurio
Na segunda etapa, o conhecimento da
rea de TI sobre os mdulos era menor,
e buscou-se seguir as recomendaes da
metodologia, envolvendo mais o usurio
Uma das dificuldades da segunda etapa
foi a parametrizao dos mdulos levando em considerao a integrao

Dificuldades c/ Consultoria

No informado

Zeneca

O conhecimento dos consultores que

gerenciavam o projeto eram bons, mas os
consultores que realizavam o trabalho ope- racional no tinham experincia
Houve dificuldade em fazer o fornecedor
entender as necessidades da empresa e as
alteraes necessrias
Os consultores no queriam envolver-se
com os problemas da empresa
Os consultores tinham dificuldades em
entender o processo txtil

A consultoria no enviou pessoal devidamente treinado, o que causou desgaste

entre a consultoria e a equipe de projeto
Por esse motivo, a empresa foi gradualmente deixando de usar a empresa de
consultoria e passando a substitu-la
pelos consultores do fornecedor

Na segunda etapa, percebeu-se que os

consultores do fornecedor no possuam
a viso global do pacote, o que dificultou a parametrizao tendo em vista a
integrao

297

ADAPTAO
Categorias/
Empresas

AgroLaranja

Vine Txtil

Zeneca
-

Diretrizes para
adaptao

Quem decidia, em
caso de impasse
Estimativas das
empresas para o
grau de customizao

Dificuldades relativas customizao

Adiamento de
customizaes e
implementao de
funcionalidades
Consideraes
sobre a adaptao

No havia orientao explcita

O resultado foi equilibrado, optandose por mudar a empresa quando o custo
da customizao fosse alto

Definiu-se a diretriz de minimizar a

customizao para garantir o prazo
O Magnus no permite modificaes em seus programas-padro, as
customizaes so feitas por programas externos

O vice-presidente

A informtica

Cerca de 30% do pacote

Comercial: 50%
Financeiro: 20%
Contabilidade: 1%

A orientao e deixar para a informtica o poder de deciso causou

dificuldades, pois era necessrio
negociar as solicitaes com as reas, um complicado jogo poltico
Em alguns casos no foi possvel o
adiamento de algumas customizaes que a informtica gostaria de
fazer aps o incio da operao

- O comit executivo
-

No houve, o fornecedor atendeu adequadamente s solicitaes

O mdulo de manufatura necessitou

receber extensa customizao para se
adaptar s necessidades do processo e s
foi implementado no terceiro ano de
operao, em ago/99
O fornecedor incorporou boa parte das
customizaes nos programas-padro,
possivelmente pela representatividade
do cliente

Aps a implementao a orientao

foi abrandada e a rea desenvolveu
as alteraes solicitadas

-----

Cerca de 10% do pacote R/3, sendo o SD o mais

customizado
O R/3 foi menos customizado do que o PACOTE
A, devido sua maior quantidade de recursos e flexibilidade

-----

O PACOTE A foi implementado sem customizar.

Houve um excesso de problemas e dificuldade de
adaptao dos usurios. Foi preciso ento alterar o
necessrio, e o pacote ficou bastante customizado
No R/3, a norma era no mudar o pacote, uma
vez que entendia-se que a reviso de processos j
havia sido feita no PACOTE
Segundo o gerente, essa diretriz sofre restries na
vida real, decorrente de presses das reas usurias, uma vez que os pacotes podem impor aumento
de tarefas pelo nmero de telas e dificuldades em
localizar e consolidar informaes nos relatrios
existentes

Algumas funcionalidades tiveram sua implementao adiada em decorrncia do prazo

No foram ainda realizadas porque, depois do
incio da operao, as prioridades se dissipam em
outros projetos e mais difcil envolver todas as
reas necessrias
-----

Melhoramentos Papis
-

Na primeira etapa customizou-se o

necessrio para modificar o faturamento como desejado pela empresa
Na segunda etapa, decidiu-se customizar o mnimo possvel, uma vez
que os mdulos que estavam sendo
implementados eram mais padronizados

Diretor Financeiro

Comercial: 50%
Financeiro: 5%
Suprimentos: 10%

-----

-----

-----

298

ADAPTAO
Categorias/
Empresas

AgroLaranja
-

Sistemas satlite

Vine Txtil

A AgroLaranja desenvolveu uma srie

de sistemas satlite com a finalidade
de complementar a funcionalidade do
sistema, fazendo o que nenhum ERP
faz
A empresa est fazendo um esforo para
incorporar todo os seus sistemas ao Logix, por meio de mdulos satlites
A AgroLaranja negociou com o fornecedor a custdia dos mdulos satlite

Sistema para controle de estoque

por meio de leitores de cdigo de
barras

Zeneca

Melhoramentos Papis

-----

-----

INCIO DA OPERAO
Categorias
Empresas

AgroLaranja

Vine Txtil

Zeneca

Melhoramentos Papis
-

Problemas de
Treinamento (geral)

-----

Problemas de
Treinamento (uso
de um sistema
integrado)

-----

No momento do incio da operao, os

usurios no sabiam operar adequadamente o
sistema, o que gerou maior necessidade de
suporte por parte da equipe de projeto

-----

O incio da operao foi adiado um

ms pois no havia confiana no conhecimento dos usurios

-----

Na primeira etapa, o incio da operao foi

adiado um ms pois no havia confiana no
conhecimento dos usurios, alm de insegurana quanto s customizaes realizadas
Na segunda etapa, no incio da operao
percebeu-se que os usurios finais no sabiam operar adequadamente o sistema, o que
gerou grande necessidade de apoio por parte
dos usurios-chave

-----

299

INCIO DA OPERAO
Categorias
Empresas

AgroLaranja
-

Motivos para resistncias dos

usurios
-

Adaptao ao novo sistema, pois os

anteriores haviam sido desenvolvidos sob medida, o que gerou comentrios do tipo o sistema anterior era melhor
Mudanas nas tarefas de reas que
passaram a ser responsveis por entradas de dados que no realizavam
antes. Perceberam isso como aumento em suas tarefas.
No caso das demais empresas do
grupo, a resistncia estava relacionada crena de que o pacote era
da AgroLaranja, e no atenderia s
necessidades especficas de cada
empresa

Vine Txtil

Zeneca

Dificuldade para a mudana cultural relativa

viso de sistemas integrados
Essa dificuldade tambm estava relacionada
ao medo de perder o emprego, com a eliminao das tarefas de redigitao, por
exemplo

Os entrevistados concordam que a

resistncia foi maior na implementao do PACOTE A, pois na do R/3, a
resistncia ao uso de pacotes j estava
vencida
Mesmo assim, em decorrncia dos
problemas ocorridos com o PACOTE
A, havia a preocupao que estes se
repetissem

Melhoramentos Papis

Como foram vencidas as resistncias

Total apoio da alta direo para

vencer as resistncias
Argumentao: o ganho da empresa, embora em sua rea haver
um pouco mais de trabalho
Customizaes: a informtica
ajudou no convencimento pressionando o fornecedor para que fizesse
as customizaes necessrias

-----

-----

Dificuldades Operacionais

-----

-----

Localizao

No houve problemas

No houve problemas

No R/3 houve poucos problemas,

devido forte preparao
Aps 30 dias, foram percebidos
problemas no fechamento mensal
No houve problemas, exceo do
mdulo IN 68
O controle de juros em duplicatas
feito externamente ao sistema

A rea de vendas gostaria de que os relatrios do novo sistema fossem semelhantes ao

do anterior
A resistncia dos usurios foi considerada
menor na segunda etapa, pois os usurios da
segunda etapa j estavam acostumados com
pacotes e participaram mais ativamente da
implementao

Foi criado um relatrio consolidado de

vendas exatamente igual ao do sistema anterior, para facilitar a aceitao do novo sistema
Entretanto, por serem seus conceitos bastante diferentes dos existentes no Logix, isso
gerou a necessidade de criao de um mdulo satlite complexo, de manuteno
bastante trabalhosa
Mas, segundo o gerente de informtica, em
um processo de implementao necessrio
fornecer aos usurios as informaes como
ele est acostumado, para que ele possa
manter um histrico de comparao
Um mesmo sistema para atender a duas
divises comerciais com processos distintos
na mesma empresa gerou necessidade de
customizaes adicionais
No houve problemas

300

INCIO DA OPERAO
Categorias
Empresas

AgroLaranja

Vine Txtil
-

Dificuldades especficas

-----

Fatores Crticos de
Sucesso, na viso
dos entrevistados

Fatores contingenciais afetaram o incio da

operao: A mudana da moeda p/ o real no
dia do incio da operao exigiu maior necessidade de planejamento e a converso de
valores
O prazo reduzido e obrigatrio obrigou a
empresa a implementar o sistema sem muito
planejamento ou testes
Em conseqncia houve um intenso trabalho
para corrigir eventuais problemas aps a implementao
O incio de operao de dois pacotes simultaneamente (o Magnus e o SGT) trouxe uma
srie de dificuldades adicionais
O processo de estabilizao durou cerca de 6
meses

Total apoio da alta direo (vicepresidente)

-----

Zeneca

Melhoramentos Papis
-

-----

Na primeira etapa, como alterou-se tanto o

sistema como a maneira de trabalhar na expedio, os dois primeiros meses foram marcados por necessidades de alterao durante
o vo e novas customizaes
O perodo de estabilizao desta etapa foi de
aprox. 2 meses
Na segunda etapa: 30 dias aps o incio da
operao descobriu-se que o fechamento
de suprimentos era um processo bastante
complexo, que deveria ter sido parametrizado na implementao
Houve a necessidade de corrigir dados
anteriores e reparametrizar adequadamente
j com os mdulos em funcionamento
A estabilizao desse mdulo durou 3 meses

-----

-----

UTILIZAO: BENEFCIOS
AgroLaranja

Categorias/empresas

Gerais

Custos

Pessoas

Unificao do sistema no grupo

Controle consolidado do grupo
Reduo de custos administrativos no
grupo
Padronizao dos conceitos usados na
administrao em todo o grupo
Reduo de 50% nos custos de informtica
Reduo de 47 para 21 pessoas na rea
de informtica
Reduo de 41 para 10 pessoas no r.h.
Crescimento profissional pelo conhecimento de mais funes dentro da mesma
rea, no r.h.

Vine Txtil
-

Maior facilidade para criao de

novos relatrios e programas, do que
na situao anterior
Reduo de pessoas nas reas administrativas, pela eliminao das tarefas
de integrao entre os sistemas
Reduo dos custos de informtica,
mesmo havendo aumento de pessoas
na rea
-----

Zeneca
-----

No PACOTE A: reduo de pessoas na

administrao e informtica (de 40 para 13
pessoas) e reduo de custos de manuteno
de hardware

-----

Melhoramentos Papis
-

Unificao dos sistemas, uma vez

que os anteriores estavam separados

Reduo de custos de informtica

em 50%

O sistema novo facilitou a unificao de duas culturas empresariais

distintas, criando-se uma terceira, a
da nova empresa

301

UTILIZAO: BENEFCIOS
AgroLaranja

Categorias/empresas
-

Integrao

Fechamento da Contabilidade
Abrangncia (funcional e geogrfica)

Vine Txtil

Os sistemas que antes eram isolados

foram integrados, o que eliminou redundncias e inconsistncias existentes
A integrao melhorou a qualidade da
informao
A integrao melhorou o controle sobre
os processos
O ERP permitiu a consumao da viso
de sistemas integrados, uma vez que o
desenvolvimento interno de um sistema
integrado dificultado por resistncias
dos usurios e da prpria rea
No informado

Um nico fornecedor facilita a negociao e o gerenciamento

Os sistemas que antes eram isolados

foram integrados, o que eliminou redundncias e inconsistncias existentes
Informao mais confivel, pois
eliminaram-se os erros de digitao
Ajudou a melhorar os processos
administrativos

O tempo foi reduzido, pois eliminouse a necessidade da digitao de lanamentos

Zeneca

No informado

Na rea de planejamento o R/3 substitui uma

srie de sistemas diferentes e isolados, eliminando a necessidade de redigitao que
havia na situao anterior

-----

Tcnicos

-----

-----

Outros
-

Pacote
-

O ERP permitiu a descentralizao da

gesto de recursos humanos, porque foi
possvel passar o controle do apontamento de horas para os supervisores
Uso do ERP como backbone para novos
desenvolvimentos
Custos de evoluo tecnolgica transferidos para o fornecedor
Reduo do backlog de aplicaes,
execuo de muitas coisas que eram
sonhos
Focalizao da rea de TI no negcio,
melhoria no servio prestado pela rea

Informao mais rpida, e disponvel

a qualquer instante (em oposio a
situao anterior, onde os relatrios
eram executados noite)
Uso do ERP como backbone para
novos desenvolvimentos

Ganhos em escala no desenvolvimento e manuteno de funes que

so padro para todas as empresas

Lanamentos contbeis gerados automaticamente e a integrao on-line aumentaram a

confiabilidade dos dados
Obrigou a empresa a encarar o fato de que
cada operao tem impacto sobre outras

O R/3 trouxe de volta a segurana que

havia no mainframe, e no existia no
PACOTE A
O R/3 tm mais flexibilidade e possibilidades do que o PACOTE A
Acesso da matriz s informaes, eliminando a necessidade de envio de relatrios e
comunicao telefnica

-----

Melhoramentos Papis

Eliminao de inconsistncias entre

os sistemas

De 12 p/ 8 dias, pois eliminou-se a

necessidade da digitao de lanamentos do comercial e folha

Relatrios desenvolvidos para

outros clientes puderam ser aproveitados

Disponibilizao de informaes
on-line na tela
Facilidade de obteno de informaes pelo desenvolvimento de novos relatrios

302

UTILIZAO: BENEFCIOS
AgroLaranja

Categorias/empresas
-

Novas idias ou possibilidades trazidas

pelo pacote
-

Competitividade

O sistema, em um determinado processo

que no poderia ser atendido (pagamento escritural com vrios bancos)
obrigou a empresa a buscar uma soluo que, no final das contas, melhorou a
operao
O processo de exportao foi refeito,
com base no pacote, com melhorias

No possvel associar o ERP com

aumento na competitividade, apenas
com melhorias nos processos internos

Vine Txtil

Zeneca
-

Aproveitou-se a implementao para remodelar os planos de contas contbeis e gerenciais

O ERP no um diferenciador competitivo,

mas sem ele algumas empresas poderiam ter
dificuldades em se estruturar adequadamente
para competir
A integrao e as ferramentas de planejamento permitiram a reduo de folgas em
estoques e melhoraram o tempo de resposta
ao cliente
A possibilidade de controlar melhor as
reservas feitas melhorou o relacionamento
com os clientes

Na rea financeira no houve benefcios

significativos, uma vez que o sistema novo
procurou espelhar o anterior

H diferenas entre os benefcios obtidos em

cada uma das reas, sendo maiores na logstica e comrcio exterior

difcil isolar o ERP de outras medidas tomadas pela empresa

As decises esto mais bem suportadas

Onde no melhorou
-

Diferenas de percepo entre as reas

Na rea de suprimentos, o ERP no

trouxe melhorias ao processo uma vez
que o sistema anterior j havia sido desenvolvido c/ a viso de processos
As reas percebem os benefcios de
maneira diferente
Para o gerente de suprimentos, o maior
beneficiado foi a contabilidade, pois
houve reduo de mo de obra e a rea
ainda pode absorver aumento de trabalho
Em algumas reas onde houve reduo
de pessoal, a percepo do usurio final
a de que o seu trabalho aumentou, e,
portanto, o novo sistema pior do que o
anterior

Melhoramentos Papis
-

Aproveitou-se a implementao
para remodelar os planos de contas
contbeis e gerenciais

303

UTILIZAO : DIFICULDADES
AgroLaranja

Categorias/empresas
-

Pessoas

Vine Txtil

No tiveram dificuldades com o sistema,

pois estavam acostumados informtica

Zeneca
-

Dependncia dos usurios em relao a

informtica em decorrncia da complexidade do software
Dificuldade em entender o impacto de
suas operaes em outras reas

Melhoramentos
-

Terceiros

Tcnicos
Abrangncia (funcional
e geogrfica)
Localizao

Necessidade de manter alta disponibilidade do sistema

Dificuldade em parar a mquina para
fazer manutenes
-

Cuidados com cadastros que podem

afetar outras reas

No foram citados grande problemas

exceo dos mdulos IN 68 e tesouraria
H a necessidade de controlar os juros
de clientes em planilhas eletrnicas

Integrao

Processos

Menor flexibilidade para negociao

de alteraes, uma vez que as solicitaes obedecem a ordem de prioridades do fornecedor, no da empresa
Alguns mdulos adquiridos com o
sistema no atenderam a necessidade
da empresa

Dificuldade em planejar o uso dos

mdulos adequadamente para a obteno de futuros relatrios consolidados

Existem necessidades no cobertas na

rea financeira, que so controladas externamente em planilhas eletrnicas

Cuidados com cadastros que podem

afetar outras reas

A MP enfrenta dificuldades em apurar

custos como desejado porque as necessidades dos mdulos da segunda
etapa (contab. e custos) no foram
consideradas na primeira etapa
Isso foi decorrncia do foco da primeira etapa e da presso pelo tempo
Outro complicador foi o grande
espao de tempo entre as duas etapas,
pois tornou-se mais difcil realizar
mudanas nos mdulos da primeira
etapa, j consolidados e estabilizados

304

UTILIZAO : DIFICULDADES
AgroLaranja

Categorias/empresas

Vine Txtil
-

Relatrios Gerenciais

Atualizao de verses
ou correo de programas

Carncia de relatrios gerenciais

Mesmo com a utilizao do gerador de
relatrios, e difcil localizar informaes
no banco de dados sem o auxlio do fornecedor

- Instalaes de atualizaes ou correes em

programas podem inviabilizar customizaes
e mdulos satlites desenvolvidos

Zeneca

Sistema desenvolvido para tender

necessidades genricas nem sempre
apresentam as informaes desejadas
O gerador de relatrios do Magnus
limitado
necessrio desenvolver novamente
alguns relatrios, quando h mudana na
diretoria
Dificuldades em instalar alteraes ou
atualizaes em decorrncia das customizaes realizadas

Carncia de relatrios gerenciais

A empresa pretende implementar o BW
da SAP e desenvolve relatrios externos
em ABAP

Melhoramentos
-

Carncia de relatrios gerenciais

A empresa desenvolveu um sistema
EIS, o que foi facilitado pelo banco de
dados nico do ERP

Instalaes de atualizaes ou correes em programas podem inviabilizar customizaes e mdulos satlites desenvolvidos

UTILIZAO : ADAPTAO CONTNUA

AgroLaranja

Categorias/empresas

Vine Txtil
-

Consideraes sobre a
adaptao contnua

Dificuldades para a
adaptao contnua

Existe um grupo independente de empresas usurias que cobra do fornecedor

as melhorias necessria
Esse grupo no totalmente influente,
uma vez que no conta com a participao da totalidade dos clientes
Limitao de recursos e definio de
prioridades

Zeneca
-

Os consultores no conseguem mais acompanhar as dvidas da empresa, pois estas vo

se tornando muito especficas

Melhoramentos
-

O oramento de customizaes
solicitadas deve ser aprovado pela
rea usuria e lanado em seu
centro de custos

OUTROS ASPECTOS
AgroLaranja

Categorias/empresas

Vine Txtil

Zeneca
-

Uso global

As empresas da Zeneca na Europa acessam

o R/2 localizado em um CPD nico, na Inglaterra
Os americanos da Zeneca tiveram dificuldades em compreender o processo comercial
brasileiro
Acesso da matriz s informaes, eliminando a necessidade de envio de relatrios e
comunicao telefnica

Melhoramentos

305

OUTROS ASPECTOS
AgroLaranja

Categorias/empresas

Vine Txtil

Zeneca

Melhoramentos
-

Outros

O PPR fez com que os funcionrios procurassem entender como

as informaes gerenciais so
obtidas e auxiliar na correo de
erros na entrada e apurao de informaes