Escolar Documentos
Profissional Documentos
Cultura Documentos
Cas Erp
Cas Erp
So Paulo
Maio de 2000
UNIVERSIDADE DE SO PAULO
Faculdade de Economia, Administrao e Contabilidade
Departamento de Administrao
So Paulo
Maio de 2000
ii
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
CDD 658.403
iii
NDICE
LISTA DE FIGURAS.................................................................................................................................... vi
RESUMO...................................................................................................................................................... vii
ABSTRACT................................................................................................................................................. viii
INTRODUO ..................................................................................................................................... 1
1.2
1.3
1.4
1.5
JUSTIFICATIVAS ................................................................................................................................. 6
1.6
2.2
2.3
SISTEMAS ERP................................................................................................................................. 11
2.4
2.5
2.6
2.7
3.2
3.3
3.4
3.5
3.6
iv
3.7
A ETAPA DE UTILIZAO.................................................................................................................. 47
4.2
4.3
4.4
4.5
4.6
4.7
OBJETIVO DA PESQUISA.................................................................................................................... 63
5.2
5.3
5.4
O DELINEAMENTO DA PESQUISA....................................................................................................... 67
6.2
6.3
6.4
6.5
6.6
6.7
6.8
7.2
7.3
7.4
7.5
ANEXOS..................................................................................................................................................... 259
vi
LISTA DE FIGURAS
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.
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:
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
10
1tYHLV GD
2UJDQL]DomR
(66
(VWUDWpJLFR
0,6
'66
*HUHQFLDO
.:6
2$6
&RQKHFLPHQWR
736
2SHUDFLRQDO
UHD
)XQFLRQDO
11
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:
13
14
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
17
18
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
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
CAMADA 2
APLICAO
CAMADA 3
BANCO DE DADOS
BANCO
DE
DADOS
CLIENTE requisita dados da
APLICAO
22
23
CAPTULO 3
O CICLO DE VIDA DE SISTEMAS ERP
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
24
25
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
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).
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
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
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
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
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
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
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.
42
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
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
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
48
49
50
CAPTULO 4
BENEFCIOS E DIFICULDADES DOS SISTEMAS ERP
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
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
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
58
TI
BPR
Como os processos da
empresa podem ser
transformados
utilizando a TI?
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
60
PACOTE
COMERCIAL
Benefcios
procurados
Aspectos Organizacionais
Problemas
potenciais
Dependncia do fornecedor
Resistncia a mudanas
Aspectos Tecnolgicos
Atualizao de tecnologia
61
INTEGRAO
Benefcios
procurados
Problemas
potenciais
Aspectos Organizacionais
Aspectos Tecnolgicos
Reduo de mo-de-obra
ABRANGNCIA
FUNCIONAL
Benefcios
procurados
Aspectos Organizacionais
Aspectos Tecnolgicos
Problemas
potenciais
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
63
CAPTULO 5
METODOLOGIA DA PESQUISA
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
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.
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:
emprica.
70
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
Div. C
Problemas
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
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
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
77
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:
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:
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:
83
84
85
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
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:
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
91
92
93
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
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
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
102
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
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
108
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
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
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
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
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
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
123
124
125
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
Planta ou Mdulo
Curitiba
So Paulo
FI (central)
SD Central
CO (central)
Campinas
Aratu
Freios (Campinas)
Totais
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
128
129
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
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
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
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
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
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:
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
148
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
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
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
156
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
160
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
164
165
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
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
168
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
176
177
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
184
185
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
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
195
196
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
202
203
204
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
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
210
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
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
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
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
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
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
Riscos
Big-bang - Possibilidade de parar a empresa
SmallBang
Fases
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
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
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
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
248
Vantagens
Dificuldades
Banco de Dados
Corporativo
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
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:
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
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
261
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
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?
O sistema trouxe alguma oportunidade para mudanas em procedimentos? O sistema trouxe alguma nova idia sobre como realizar algum procedimento especfico?
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)
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?
Aps a implementao, a empresa considera o projeto ERP encerrado? Por qu? Por que
no?
263
264
A empresa tem alguma caracterstica particular que poderia representar uma dificuldade na
utilizao de ERP?
II - Implementao
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?
O sistema trouxe alguma oportunidade para mudanas em procedimentos? O sistema trouxe alguma nova idia sobre como realizar algum procedimento especfico?
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
275
276
Empresa
Categorias/Empresas
Pacote / Origem
R/3 / Estrangeiro
Apresentao da
Empresa
Origem
Multinacional Francesa
Qtde. Plantas
Produtos e Clientes
Caractersticas do
processo
Faturamento /
Funcionrios
CNT/VMM
Bosch
Baan IV / Estrangeiro
R/3 / Estrangeiro
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
Multinacional Alem
Santista
-
Baan IV / Estrangeiro
23 localidades
-
Processo contnuo
277
Categorias/Empresas
Sistema(s) Anterior(es)
Equipe de TI
28 pessoas
Histrico da rea
19 pessoas
Bosch
-
71 pessoas
Santista
-
32 pessoas
3.300 usurios
900 usurios
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
Banco de Dados
Oracle
Informix
Oracle
Oracle
Comunicao
LPs e Microondas
Satlite
Satlite
Frame-relay
Combinao de desenvolvimento
interno, em COBOL, em mainframe
IBM e pacotes (tal como o COPICS)
No foram citados
39 pessoas
112 pessoas
69 pessoas
Descrio
-
Integrao
-
Problemas
-
Equipe Anterior
278
DECISO E SELEO
Rhodia Poliamida
Categorias/Empresas
-
Motivao
-
CNT/VMM
Y2K
Desligamento do sistema da Hoechst
(em dez/97)
Reduo dos custos de informtica
Atualizao tecnolgica
Pr-seleo
-----
Seleo
Papel da Matriz
Bosch
-
------
Santista
-
Deciso da Matriz
------
Preocupaes da TI
Preocupaes dos
Usurios
-
Localizao, uma vez que no foi possvel ver funcionando em nenhuma empresa
Localizao
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.
279
DECISO E SELEO
Rhodia Poliamida
Categorias/Empresas
CNT/VMM
Bosch
Santista
-
Prazos e Custos
IMPLEMENTAO
Rhodia Poliamida
Categorias/empresas
CNT/VMM
-
Modelo de incio de
operao
Bosch
-
No foi utilizado
Santista
-
Paralelo
No foi utilizado
Consideraes sobre o
modelo de incio de
operao
Mdulos
No foi utilizado
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
280
IMPLEMENTAO
Rhodia Poliamida
Categorias/empresas
CNT/VMM
Bosch
Santista
-
Detalhes
Incio/Trmino
Jul/96 a Mar/98
Durao total
20 meses
Consultoria
Metodologia
Mai/96 a Jun/99
38 meses
Equipe
-
Direo do projeto
Comit Executivo
Gerenciamento do projeto
Gerenciamento das
equipes (mdulos)
Destaque
-
- Gerente de Informtica
-
Gerente de informtica
Gerente de informtica
TI + consultoria
TI + consultoria
Composta por pessoal da TI e usurioschave. Cada planta possua uma equipe de projeto.
A de Campinas era composta por 46
pessoas
Gerente de Informtica
TI + um lder usurio
TI + consultoria
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
CNT/VMM
-
Tempo integral
Localizao do
projeto
Treinamento e
tarefas
Modelagem e testes
Envolvimento dos
demais usurios
No informado
Dedicao
Dificuldades
Dificuldades c/ Consultoria
Bosch
Santista
Na fbrica do Jaguar
No informado
No informado
No informado
282
IMPLEMENTAO
Rhodia Poliamida
Categorias/empresas
-
CNT/VMM
Bosch
Santista
- No foram citados
- No foram citados
ADAPTAO
Rhodia Poliamida
Categorias/empresas
CNT/VMM
Bosch
-
A gerncia do projeto
No geral : 10 %
No informado
O comit executivo
- No informado
No informado
Santista
Comit executivo
Comercial: 80%
Manufatura: 50%
Materiais e finanas: menos de 20%
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
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
Santista
INCIO DA OPERAO
Rhodia Poliamida
Categorias/empresas
-
CNT/VMM
Os usurios no estavam suficientemente preparados quando iniciou-se a
operao
Apresentaram dificuldades em localizar
as informaes necessrias
Bosch
-
Santista
- No foram citados
- No foram citados
284
INCIO DA OPERAO
Rhodia Poliamida
Categorias/empresas
CNT/VMM
Bosch
Santista
-
Dificuldades Operacionais
Localizao
Dificuldades especficas
- No foram citados
-
285
INCIO DA OPERAO
Rhodia Poliamida
Categorias/empresas
-
CNT/VMM
Bosch
Santista
UTILIZAO: BENEFCIOS
Rhodia Poliamida
Categorias/empresas
CNT/VMM
-
Gerais
Custos
Pessoas
Integrao
-
Fechamento da Contabilidade
De 10 p/ 4 dias
Bosch
-
Sistema globalizado
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
-
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
Tcnicos
Outras
Competitividade
-
287
UTILIZAO: BENEFCIOS
Rhodia Poliamida
Categorias/empresas
CNT/VMM
-
Consideraes e Destaques
Fatores Crticos de Sucesso, de acordo com os
entrevistados
No foram citados
Bosch
-
No foram citados
Santista
-
No foram citados
UTILIZAO : DIFICULDADES
Rhodia Poliamida
Categorias/empresas
CNT/VMM
-
Pessoas
-
Tcnicos
Abrangncia (funcional
e geogrfica)
Bosch
Santista
-
288
UTILIZAO : DIFICULDADES
Rhodia Poliamida
Categorias/empresas
CNT/VMM
Bosch
Santista
-
Processos
Relatrios Gerenciais
Atualizao de verses
ou correo de programas
Treinamento da equipe de TI
Salrios
Custos p/ mudana de verses
Retreinamento de usurios
Custos para adaptao contnua e novas
customizaes
289
Categorias/empresas
-
Consideraes sobre a
adaptao contnua
Dificuldades para a
adaptao contnua
CNT/VMM
Bosch
Santista
H dificuldades em realizar
alteraes ou corrigir problemas
porque necessrio envolver
muitas pessoas
290
Categorias/Empresa
Empresa
Pacote / Origem
Logix / Nacional
Vine Txtil
-
Magnus / Nacional
Zeneca
-
R/3 / Estrangeiro
Melhoramentos Papis
-
Logix / Nacional
Apresentao
da Empresa
Origem
Nacional
Nacional
Multinacional Inglesa
Nacional
Processo contnuo
No informado
Em bateladas
Qtde. Plantas
Produtos e
Clientes
Caractersticas
do processo
Faturamento /
Funcionrios
291
rea de TI
Categorias/Empresa
Vine Txtil
Equipe de TI
21 pessoas
Histrico da
rea
Subordinao
Vice-presidncia da empresa
No informada
Usurios
110 usurios
1 Servidor HP Unix
Banco de Dados
Comunicao
Atividades da
rea
Servidores
14 pessoas
Zeneca
-
14 pessoas
11 pessoas
Presidncia
Diretoria Financeira
120 usurios
1 Servidor HP Unix
H um servidor p/ testes e backup
Oracle
Satlite
Frame-relay e LPs
Melhoramentos Papis
292
Categorias/Empresa
Vine Txtil
-
Integrao
Equipe Anterior
47 pessoas
Zeneca
7 pessoas
Melhoramentos Papis
DECISO E SELEO
Categorias/
Empresas
AgroLaranja
-
Motivao
Deciso por
ERP
Vine Txtil
Zeneca
-
Reduo de custos de TI
Atualizao tecnolgica
Dificuldades (custo e prazo) para
obteno de alteraes no sistema
Da matriz
Melhoramentos Papis
-
Pr-seleo
Papel da Matriz
-----
-----
-----
-----
-----
293
DECISO E SELEO
Categorias/
Empresas
AgroLaranja
-
Seleo
Vine Txtil
-
Preocupaes da
TI
-----
Preocupaes
dos Usurios
-----
Prazos e Custos
-
-----
Zeneca
-
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
-
-----
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
IMPLEMENTAO
Categorias/
Empresas
AgroLaranja
Vine Txtil
Zeneca
Modelo de incio de
operao
R/3: Big-bang
PACOTE A: em fases
Paralelo
No foi utilizado
No foi utilizado
Melhoramentos Papis
-
No foi utilizado
294
IMPLEMENTAO
Categorias/
Empresas
AgroLaranja
Vine Txtil
Zeneca
-
-----
Mdulos
-
Detalhes
Incio/Trmino
Durao total
Consultoria
Melhoramentos Papis
Mar/94 a Jul/94
4 meses
10 meses
Metodologia
Do fornecedor
Do fornecedor (ASAP)
295
IMPLEMENTAO
Categorias/
Empresas
AgroLaranja
-
Equipe
Vine Txtil
-
Zeneca
-
Melhoramentos Papis
No informado
Diretor Financeiro
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
Durante a implementao foram contratadas mais duas pessoas para a rea de TI, j
com experincia em Magnus
Gerenciamento do
projeto
Gerenciamento das
equipes (mdulos)
Usurios-chave
Destaque
Escolha
Dedicao
-----
-----
-----
-----
-----
-----
Localizao do
projeto
Treinamento e
tarefas
-----
Envolvimento
dos demais
usurios
296
IMPLEMENTAO
Categorias/
Empresas
Treinamento dos
usurios finais
AgroLaranja
-
Dificuldades
-
Vine Txtil
-
No informado
Melhoramentos Papis
-
Dificuldades c/ Consultoria
No informado
Zeneca
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
Adiamento de
customizaes e
implementao de
funcionalidades
Consideraes
sobre a adaptao
O vice-presidente
A informtica
Comercial: 50%
Financeiro: 20%
Contabilidade: 1%
- O comit executivo
-
-----
-----
Melhoramentos Papis
-
Diretor Financeiro
Comercial: 50%
Financeiro: 5%
Suprimentos: 10%
-----
-----
-----
298
ADAPTAO
Categorias/
Empresas
AgroLaranja
-
Sistemas satlite
Vine Txtil
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)
-----
-----
-----
-----
299
INCIO DA OPERAO
Categorias
Empresas
AgroLaranja
-
Vine Txtil
Zeneca
Melhoramentos Papis
-----
-----
Dificuldades Operacionais
-----
-----
Localizao
No houve problemas
No houve problemas
300
INCIO DA OPERAO
Categorias
Empresas
AgroLaranja
Vine Txtil
-
Dificuldades especficas
-----
Fatores Crticos de
Sucesso, na viso
dos entrevistados
-----
Zeneca
Melhoramentos Papis
-
-----
-----
-----
UTILIZAO: BENEFCIOS
AgroLaranja
Categorias/empresas
Gerais
Custos
Pessoas
Vine Txtil
-
Zeneca
-----
-----
Melhoramentos Papis
-
301
UTILIZAO: BENEFCIOS
AgroLaranja
Categorias/empresas
-
Integrao
Fechamento da Contabilidade
Abrangncia (funcional e geogrfica)
Vine Txtil
Zeneca
No informado
-----
Tcnicos
-----
-----
Outros
-
Pacote
-
-----
Melhoramentos Papis
Disponibilizao de informaes
on-line na tela
Facilidade de obteno de informaes pelo desenvolvimento de novos relatrios
302
UTILIZAO: BENEFCIOS
AgroLaranja
Categorias/empresas
-
Competitividade
Vine Txtil
Zeneca
-
Onde no melhorou
-
Melhoramentos Papis
-
Aproveitou-se a implementao
para remodelar os planos de contas
contbeis e gerenciais
303
UTILIZAO : DIFICULDADES
AgroLaranja
Categorias/empresas
-
Pessoas
Vine Txtil
Zeneca
-
Melhoramentos
-
Terceiros
Tcnicos
Abrangncia (funcional
e geogrfica)
Localizao
Integrao
Processos
304
UTILIZAO : DIFICULDADES
AgroLaranja
Categorias/empresas
Vine Txtil
-
Relatrios Gerenciais
Atualizao de verses
ou correo de programas
Zeneca
Melhoramentos
-
Instalaes de atualizaes ou correes em programas podem inviabilizar customizaes e mdulos satlites desenvolvidos
Categorias/empresas
Vine Txtil
-
Consideraes sobre a
adaptao contnua
Dificuldades para a
adaptao contnua
Zeneca
-
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
Melhoramentos
305
OUTROS ASPECTOS
AgroLaranja
Categorias/empresas
Vine Txtil
Zeneca
Melhoramentos
-
Outros