DIFICULDADES NA IMPLANTAO DE

UM SISTEMA ERP: UM ESTUDO DE

CASO SOBRE A FASE DE TESTES
VICTOR LEAL GOMES (USP)
victor@dczeus.com.br
EDER MIRANDA DE NOVAIS (USP)
eder.novais@usp.br
EDMIR PARADA VASQUES PRADO (POLI/USP)
eprado@usp.br
JOO PORTO DE ALBUQUERQUE (USP)
joao.porto@usp.br
THIAGO CASTRO FERREIRA (USP / EACH)
thiago.castroferreira@yahoo.com.br

Resumo: ESTE TRABALHO MOSTRA UM ESTUDO DE CASO SOBRE AS

DIFICULDADES ENFRENTADAS DURANTE A FASE DE TESTES NA
IMPLANTAO DE UM SISTEMA DE
APLICATIVOS INTEGRADOS
REALIZADO EM UMA EMPRESA DE MDIO PORTE DO SETOR DE
COMRCIO. OS RESULTADOS AQUI EEXPOSTOS MOSTRAM QUE OS
PACOTES PREEXISTENTES DE ERP NO CORRESPONDEM
S
CARACTERSTICAS DE UM PRODUTO MUITO DIFERENCIADO DOS
EXISTENTES NO MERCADO. AINDA
MOSTRADO QUE AS
DIFICULDADES DOS USURIOS SO AGRAVADAS DE ACORDO COM O
NVEL DE TREINAMENTO
E O MATERIAL DISPONVEL PARA
CONSULTA SOBRE O NOVO SISTEMA E PELO TEMPO DE DEDICAO
QUE PODEM DISPOR NA FASE DE TESTES QUE O NOVO SISTEMA
EXIGE.
NESTE TRABALHO FOI CONSTATADO QUE DEVIDO
COMPLEXIDADE DE UM PRODUTO DETECTADA SOMENTE
DURANTE A FASE DE TESTES, UMA PARTE DA SUTE DE
APLICATIVOS PRECISOU SER TOTALMENTE REFEITA, POIS
OS
MOVIMENTOS
DE
DESCONTEXTUALIZAO
E
RECONTEXTUALIZAO SE MOSTRARAM RECORRENTES.
Palavras-chaves: SISTEMAS INTEGRADOS DE GESTO; TESTE DE SISTEMAS;
ESTUDO DE CASO

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

DIFFICULTIES IN THE
IMPLEMENTATION OF AN ERP
SYSTEM: A CASE STUDY ON THE
STAGE TESTS
Abstract: THIS WORK SHOWS A CASE STUDY ON THE DIFFICULTIES FACED
DURING THE TEST PHASE IN THE DEPLOYMENT OF
AN
INTEGRATED SYSTEM APPLICATION DONE IN A
MEDIUM-SIZE
BUSINESS SECTOR OF COMMERCE. EXPOSED HERE THE RESULTS
SHOW THAT THE PACKAGES PRE-EEXISTING ERP DOES NOT MEET
THE CHARACTERISTIC OF A PRODUCT WAS MUCH DIFFERENT
FROM THE MARKET. IS STILL SHOWN THAT THE DIFFICULTIES OF
AGGRAVATED USERS ARE ACCORDING TO THE LEVEL OF TRAINING
AND MATERIALS AVAILABLE FOR CONSULTATION ON THE NEW
SYSTEM AND THE DEDICATION OF TIME THAT MAY AVAILABLE IN
PHASE OF TESTING THE NEW SYSTEM THAT REQUIRES. IN THIS
WORK WE NOTED THAT DUE TO COMPLEXITY OF A PRODUCT
DETECTED ONLY DURING PHASE OF TESTING AS A PART OF THE
SUITE OF APPLICATIONS NEEDED BE SCRAPED CLEAN, FOR THE
MOVEMENT
OF
DECONTEXTUALIZATION
AND
RECONTEXTUALIZATION IF SHOW RECURRING.
Keyword: INTEGRATED SYSTEMS MANAGEMENT, TEST SYSTEMS, CASE STUDY

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

1. Introduo
Com o surgimento da corrida espacial na segunda metade do sculo XX a computao
passou a ter fins mais abrangentes que foram alm daqueles especficos ligados a clculos
balsticos que marcou o perodo da segunda guerra mundial. Nesta poca, a computao foi
usada principalmente para clculos corriqueiros em empresas, como folha de pagamentos,
alquotas de impostos, entre outros. No incio da dcada de 1990, com o advento da
globalizao, a computao passou a ter novos propsitos, e um dos produtos da
informatizao o ERP (Sistema Integrado de Gesto). Os sistemas ERP conseguiram lugar
de destaque em anncios publicitrios e se tornaram verdadeiros objetos de obsesso por parte
das organizaes, consumindo horas de trabalho de gerentes e executivos que alimentam
idias sobre sucesso empresarial (WOOD Jr.; PAULA; CALDAS, 2006). Com a planificao
da economia, as empresas passaram a ter mais concorrentes e a disputa por espao no
mercado se tornou mais acirrada. Segundo Laudon e Laudon (2007), os sistemas de
informao - integrantes da computao aplicada - ajudam as organizaes a atingirem seus
objetivos operacionais que so: excelncia operacional; novos produtos, servios e modelos
de negcio; relacionamento mais prximo com clientes e fornecedores; melhor tomada de
decises; e vantagem em relao a concorrentes e sobrevivncia.
A tecnologia da informao (TI) em um sistema ERP constituda de hardware,
software, redes de comunicao eletrnica de dados, redes digitais de telecomunicaes,
protocolos de transmisso de dados e outros servios. Segundo Neves e Santos (2007) os
sistemas ERP tm sido amplamente utilizados para aumentar a eficincia dos processos
produtivos e a gesto empresarial das organizaes. Essa realidade tambm foi constatada
pela Federao das Indstrias do Estado de So Paulo (FIESP, 2002). Por outro lado, a
crescente utilizao dos sistemas ERP se deve a vrios fatores. Entre eles destacam-se a
capacidade de integrar informaes oriundas de diversas reas funcionais de uma organizao
e por possurem as melhores prticas do mercado (ABBAD, 2002).
Segundo Pressman (2006), existem diversos processos de desenvolvimento de
software. Entre eles destacam-se o desenvolvimento em cascata, a prototipao, o processo
unificado e os mtodos geis. Em todas essas abordagens h uma etapa de testes, onde so
envolvidos os desenvolvedores, os clientes e a organizao. Nesta etapa, o artefato
desenvolvido confrontado com as prticas empresariais.
Nesse contexto, este estudo tem como objetivo identificar as dificuldades que surgem
durante a fase de testes no processo de implantao de um sistema ERP em uma organizao
de mdio porte.
2. Histrico dos Sistemas Integrados de Gesto (ERP)
Durante a dcada de 1970 as organizaes possuam dificuldades para gerenciar seus
estoques. Nessa poca, a quantidade de mercadorias em galpes era substancial, dificultando a
gerencia de produtos por parte dos setores responsveis. Nesse cenrio, surgiram os sistemas
MRP (Material Requirements Planning) ou Planejamento das Necessidades de Materiais.
Esses sistemas possuam funcionalidades que viabilizavam a gerncia de estoques, como o
saldo de produtos, relatrios de mercadorias e controle de entrada e sada de materiais.
Nos anos 80, o MRP evoluiu para MRP-II (Manufacturing Resource Planning ou

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

Planejamento dos Recursos de Manufatura) que tinha como base, alm dos bens, outros
recursos essenciais produo. Pode-se dizer que o MRP-II o mtodo para o planejamento
efetivo de todos os recursos de uma indstria. Esse tipo de sistema, ainda usados por diversas
empresas, possui vrias funes integradas: planejamento do negcio, plano de vendas e
operaes, plano de produo, programao mestre de produo, planejamento das
necessidades de materiais, e planejamento das necessidades de capacidade (OLIVEIRA,
2003).
O aperfeioamento dos sistemas MRP-II trouxe novas funcionalidades e a capacidade
de gerenciar os processos de todas as reas funcionais da organizao em um nico sistema,
nascendo o sistema ERP (Enterprise Resource Planning). Com o surgimento dessa ferramenta
a organizao passou a ter o controle de todos os seus processos, podendo tomar decises com
base em relatrios e ndices oriundos do sistema ERP, proporcionando benefcios para as
estratgias de negcios (LAUDON; LAUDON, 2007). Os sistemas ERP apresentam um
conjunto de mdulos integrados e um banco de dados central, que permite que os dados sejam
compartilhados pelos diferentes processos de negcios e reas funcionais da organizao.
3. Ciclo de Vida de um sistema ERP
Zwicker e Souza (2006) propem uma viso sobre o ciclo de vida de sistemas ERP.
Para os autores existem quatro etapas que sintetizam o processo de insero de um sistema
ERP nas organizaes. Essas etapas esto ilustradas na Figura 1. importante observar que
fatores contingenciais como atrasos de etapas, alterao na ordem de implementao dos
mdulos, entre outros, devem ser previstos.
a) Deciso e seleo. Esta etapa diz respeito deciso tomada pela empresa de que o
sistema necessrio para a mesma e pela seleo de um fornecedor de aplicativos integrados.
Dessa maneira, a instituio procura no mercado um sistema adequado s suas necessidades
empresariais. Esta etapa contempla o projeto de implantao do sistema, custos, prazos e
regras de negcios estabelecidas entre o fabricante do software e a organizao.
b) Implementao. Representa o processo pelo qual os mdulos do sistema so
implantados na organizao e envolve: parametrizao e adaptao dos mdulos existentes
aos processos de negcios organizacionais; seleo de usurios chaves de cada departamento,
para auxilio no treinamento das equipes, conforme destacado por Padilha (2005); carga e
converso de dados iniciais; configurao do hardware e software; treinamento de usurios e
gestores; e a disponibilizao de ajuda e suporte. A etapa de implementao considerada a
mais crtica de todo o ciclo de vida de um sistema ERP, pois nesta fase que os problemas de
inconsistncia de software so encontrados. Quando o sistema instalado na organizao os
usurios se deparam com uma nova realidade e o novo sistema testado para que suas
funcionalidades estejam de acordo com os processos da organizao. Dessa forma, essa etapa
pode durar meses e at extrapolar o prazo para concluso do projeto de implantao do
sistema. Os testes de sistema, foco principal deste trabalho, so um componente desta etapa.
c) Estabilizao. Corresponde a utilizao do sistema implantado. Nesta etapa, o
sistema j est em uso, porm os usurios ainda encontram dificuldades em utiliz-lo. Falhas
no treinamento so encontradas, erros em programas so detectados e novas customizaes
podem ser necessrias. Alm disso, apesar da organizao estar dependendo do sistema ERP
para suas atividades, de acordo com o problema encontrado, que dificilmente poderia ser
previsto na etapa de implantao, o sistema anterior que foi substitudo pelo ERP pode voltar
a ser utilizado. Dois aspectos crticos destacam-se nessa etapa: as dificuldades dos usurios
finais e os problemas do sistema ERP. Os usurios operam o sistema com lentido e possuem
4

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

insegurana com relao as suas atividades rotineiras, antes realizadas normalmente pelo
sistema antigo. Os problemas do sistema so relacionados a erros no software (frmulas
erradas, erros na sada de dados, etc.) e adaptaes aos processos da empresa.
d) Utilizao. Nesta etapa o sistema ERP est funcionando integralmente e sendo
operado intensamente. Obviamente que novos erros podero ser encontrados e o sistema pode
voltar para etapa de implementao. Entretanto, neste ponto espera-se que os erros j estejam
sanados e a preocupao volte para os objetivos que a organizao espera alcanar com o
novo sistema.

FIGURA 1 Ciclo de vida de Sistemas ERP. Fonte: Souza e Zwicker (2006).

4. Fase de Testes na Implantao de Software

Existem diversos modelos de processos de desenvolvimento de software e dentre eles
esto os modelos prescritivos, o modelo em cascata, os modelos incrementais, os modelos
evolucionrios, os modelos especializados e o processo unificado. Este ltimo combina
diversos modelos anteriores em um nico. Segundo Pressman (2006), todos estes modelos
possuem uma etapa de testes. Esta seo apresenta uma estratgia de teste de software para
arquiteturas de software convencionais, distinguindo o teste de sistema com o teste de
software e mostrando as peculiaridades dos testes relacionados a sistemas ERP.
4.1 Testes de Software e de Sistema
O processo de engenharia de software pode ser visto como a espiral ilustrada na Figura
2. Inicialmente, a engenharia de sistemas define o papel do software e leva anlise dos
requisitos de software, onde so estabelecidos o domnio da informao, a funo, o
comportamento, o desempenho, as restries e os critrios de validao para o software.
Adentrando-se ao longo da espiral, chega-se ao projeto e finalmente codificao. Para
desenvolver software de computador, move-se em espiral para dentro, ao longo de voltas que
diminuem o nvel de abstrao em cada volta.

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

FIGURA 2 Estratgia de teste. Fonte: Pressman (2006).

Uma estratgia para teste de software pode tambm ser vista no contexto da espiral. O
teste de unidade comea no centro da espiral e se concentra em cada unidade (por exemplo,
componente) do software como implementado em cdigo-fonte. O teste progride movendo-se
para fora ao longo da espiral para o teste de integrao, em que o foco fica no projeto e na
construo da arquitetura do software. Em seguida encontra-se o teste de validao, em que os
requisitos estabelecidos como parte da anlise das necessidades do software so validados em
contraste com o software que acabou de ser construdo. Finalmente, chega-se ao teste de
sistema, em que o software e os outros elementos do sistema so testados como um todo. Para
testar o software de computador, move-se pela espiral para fora ao longo de voltas que
ampliam o escopo do teste a cada volta.
4.2 Teste de Sistema Integrados de Gesto (ERP)
Em sistemas ERP os testes realizados so do tipo caixa preta, pois a organizao
compradora do produto adquire um sistema pronto e executvel, com a ausncia do cdigo
fonte, inviabilizando os testes internos. Outro ponto importante, que se pressupe que o
fabricante j tenha realizado testes internos ao sistema e que o mesmo encontra-se em sua
melhor forma possvel em relao ao desempenho, usabilidade e s funcionalidades em
geral.
Durante o processo de implantao do sistema selecionada uma equipe responsvel
pelos testes e os integrantes dessa equipe so denominados usurios chave. Segundo Escouto
e Schilling (2006), estes geralmente so os responsveis por cada departamento da empresa. A
partir desse ponto realizado um roteiro de testes em conjunto com os desenvolvedores do
aplicativo. Cada mdulo recebe um conjunto de testes que sero aplicados por usurios de
cada rea funcional da empresa.
O treinamento dos usurios chaves, responsveis pelas reas funcionais da empresa e
que daro suporte aos demais funcionrios, geralmente feito por empresas externas de
consultoria, conforme apontado por Mendes e Escrivo Filho (2006).
Ao realizar um teste e se deparar com uma situao de erro, o sistema precisar sofrer
alguma modificao para solucionar o problema. Como conseqncia, o mdulo contendo o
erro volta para a empresa desenvolvedora. Ao ser reintroduzido na organizao o software
poder conter um novo problema e essa situao se poder tornar cclica. Essa questo
muito recorrente na etapa de testes, conforme descrito por Souza e Saccol (2006). Assim,
questes sociotcnicas devem ser consideradas na etapa de testes em sistemas ERP. Um dos

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

pilares que sustentam o modelo de Mikropolis (MM), descrito por Albuquerque (2006), e cuja
filosofia evidenciar a inter-relao entre a TI e o contexto social, justamente a perspectiva
sociotcnica.
A perspectiva sociotcnica enfoca esse conflito entre as prticas organizacionais e o
sistema que se deseja implantar. O processo pelo qual as especificaes, regras e prticas
organizacionais so transformadas em requisitos e entregues ao desenvolvedor chamado de
descontextualizao, pois uma srie de normas e valores existentes so formalizados e
exportados para uma outra dimenso no qual se desenvolver ou se customizar um artefato
de software. Ao produzir ou alterar o artefato, o mesmo reintroduzido (recontextualizado)
no ambiente organizacional que alm de modific-lo, est sujeito a novas mudanas,
constituindo um ciclo.
O processo de formalizao, algoritmizao e utilizao, ou seja, a elaborao de
requisitos de forma que se possa construir um artefato com base em um conjunto finito de
passos e depois re-introduzir esse artefato para ser utilizado por pessoas intrinsecamente
conflituoso. Em algumas situaes ele pode ser to contnuo que o objetivo de alterar um
componente de software pode fracassar, fazendo com que o mesmo seja reconstrudo desde o
incio.
5. Metodologia da Pesquisa
Esta pesquisa se caracteriza como um estudo qualitativo. Segundo Richardson (1999),
a pesquisa qualitativa adequada para descrever a complexidade de uma determinada
situao e compreender seus processos dinmicos. Como conseqncia, esse tipo de pesquisa
adequada a este trabalho, pois se busca identificar as dificuldades que surgem durante a fase
de testes no processo de implantao de um sistema ERP. Adicionalmente, pode-se classificar
esta pesquisa como exploratria. Segundo Selltiz, Wrightman e Cook (1987), a pesquisa
exploratria busca aumentar o conhecimento do pesquisador acerca do fenmeno investigado,
servindo como base para a formulao de problemas para pesquisa mais exata.
Esta pesquisa foi realizada atravs de trs etapas: definio do problema de pesquisa,
seleo da estratgia da pesquisa e coleta e anlise dos dados.
5.1 Problema de Pesquisa
O objetivo geral desta pesquisa identificar as dificuldades que surgem durante a fase
de testes no processo de implantao de um sistema ERP. Para atingir esse objetivo procurouse responder seguinte pergunta: qual a importncia da fase de testes durante a implantao
de um ERP em uma empresa de porte mdio?
Ao responder a essa pergunta, deseja-se melhorar o entendimento sobre as
dificuldades encontradas na fase de testes do processo de implantao de um sistema ERP,
contribuindo para que fornecedores de sistemas ERP e organizaes clientes possam
aperfeioar o processo de testes, melhorando os resultados obtidos na implantao.
5.2 Estratgia da Pesquisa
O estudo de caso um mtodo de pesquisa emprica que investiga fenmenos
contemporneos em seu contexto real, quando os limites entre o fenmeno e o contexto no
esto claramente definidos. Yin (2005) destaca ainda que para se entender assuntos
complexos que permeiam a sociedade contempornea deve se utilizar de fatos empricos e
contrast-los com a teoria existente sobre o tema, pois desta forma se obtm as
particularidades do fato, permitindo alcanar novos horizontes. Essa viso compartilhada
7

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

por Eisenhardt (1989), que afirma que o estudo de caso permite ao pesquisador responder, de
forma flexvel, a novas descobertas feitas quando da coleta de novos dados.
A estratgia de pesquisa adotada neste trabalho foi o estudo de caso simples. O estudo
de caso simples se justifica quando nico, o que ocorre quando o mesmo raro o bastante,
ou quando o pesquisador tem a oportunidade de observar e analisar uma interveno
previamente inacessvel investigao cientfica, um caso revelador (YIN, 2005).
5.3 Coleta de Dados
O instrumento de coleta de dados utilizado foi a entrevista. Elaborou-se inicialmente
um roteiro de perguntas, que foi aplicado pessoalmente a cada um dos entrevistados. As
entrevistas foram conduzidas no primeiro semestre de 2010 junto aos usurios-chave de cada
mdulo do sistema ERP implantado. O responsvel pela rea de TI e um funcionrio da
empresa fornecedora tambm foram entrevistados.
6. Apresentao do Caso
Em janeiro de 1990, os Terminais Rodovirios foram terceirizados pela Companhia do
Metropolitano de So Paulo (Metr) que, atravs de concorrncia pblica, contratou o
Consrcio Prisma, para administrar e explorar comercialmente os trs Terminais Rodovirios
da cidade de So Paulo incluindo as responsabilidades sobre manuteno e conservao das
instalaes existentes, e a ampliao e modernizao dos terminais. O Consrcio Prisma,
composto pelas empresas de capital fechado SCK e Rodexo S/A, administra o Terminal
Rodovirio do Tiet, o Terminal Rodovirio da Barra Funda e o Terminal Rodovirio do
Jabaquara. As tarefas para o cumprimento das funes do consrcio so divididas e
executadas pelas duas empresas que o compe.
O papel da SCK no consrcio a responsabilidade operacional, ou seja, o controle de
embarques e desembarques dos terminais, a manuteno dos banheiros e a administrao e
fiscalizao dos contratos dos estabelecimentos comerciais de alguns ramos de atividades, tais
como os de alimentao, farmcias, jornais e tabacarias, entre outros.
A empresa objeto de estudo desta pesquisa a Rodexo S/A. Seu papel e
caractersticas, bem como a sua rea de TI.
6.1 Caracterizao da Empresa Estudada
A Rodexo S/A est sediada no Terminal Rodovirio do Tiet e responsvel pelo
desenvolvimento dos terminais rodovirios. A empresa possui 64 funcionrios, sendo quatro
do setor de engenharia, 11 do setor administrativo e os 49 restantes esto lotados na nica
filial e nos estacionamentos que esto localizados nos trs terminais rodovirios.
As atividades principais da empresa so: (1) administrao e manuteno dos
estacionamentos para carros dos terminais; (2) auxlio na definio dos contratos
administrados e fiscalizados pela SCK; (3) definio, administrao, fiscalizao e cobrana
dos contratos de aluguis de espaos, lojas e publicidade nos terminais e que no so de
responsabilidade da SCK, ou seja, contratos administrativos de no vinculao direta
operao dos terminais rodovirios; e (4) a realizao de obras de grande porte. Como
exemplo de obras de grande porte, pode-se citar a reforma e a modernizao do Terminal
Tiet e a construo de elevadores. Essas atividades mostram a importncia que a gerncia de
contratos tem para a Rodexo S/A.
A maior parte das tarefas da Rodexo S/A gira em torno do gerenciamento de contratos

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

de locao, que so muitos, com caractersticas diversas, de complexidade alta e com

caractersticas especficas em cada caso.
6.2 rea de Tecnologia de Informao da Empresa
A rea de TI da Rodexo S/A possui uma infra-estrutura e um porte compatvel com
suas necessidades operacionais. Em 2009 a empresa atualizou seu parque tecnolgico com o
objetivo de adequar o ambiente para receber o novo sistema ERP adquirido. Essa atualizao
visou atender aos requisitos de hardware exigidos e tambm aos requisitos de disponibilidade
do ambiente. Foram adquiridos dois servidores, 10 estaes de trabalho e equipamentos de
rede com padro GIBABIT Ethernet para atender ao projeto.
A rea de TI da Rodexo S/A administrada por uma empresa terceirizada. Existe um
funcionrio responsvel por toda a administrao e manuteno dos sistemas e da infraestrutura de TI. O mesmo possui 25 anos de experincia na rea e pelo menos 10 anos com o
sistema ERP alvo deste estudo.
7. Anlise dos Dados
A pesquisa descreve o processo de implantao, em especial a fase de testes, de um
sistema ERP em uma organizao localizada em So Paulo. Os dados coletados nas
entrevistas foram resumidos em trs tpicos: deciso pela implantao; o processo de
implantao; e a apresentao dos Resultados.
7.1 Deciso pela Implantao
A origem da motivao para a implantao do sistema ERP foi a informatizao e
integrao do sistema de gesto de contratos com os demais sistemas. A gesto de contratos e
os dados sobre eles eram digitalizados no software de gesto empresarial denominado Zeus.
Este software foi criado exclusivamente para o uso da Rodexo S/A. Ele inclua as
caractersticas necessrias para digitalizao dos dados contratuais, tratamento de excees e
procedimentos mais especficos e complexos.
Por outro lado, a outra empresa do Consrcio Prima, a SCK, havia integrado seus
dados a partir do sistema ERP da TOTVS, o Protheus 10. Alm disso, havia tambm a
necessidade de integrar o sistema de gesto de contratos com o sistema contbil, de finanas e
recursos humanos, para uma maior eficincia operacional. Como conseqncia, a diretoriada
Rodexo S/A decidiu por implantar o mesmo sistema ERP denominado Protheus 10, o que
facilitaria futuras consolidaes de balanos. As motivaes para implantao podem ser
resumidas em cinco fatores: (1) mesmo sistema usado pelo parceiro SCK; (2) produto
tecnologicamente melhor em relao ao anteriormente instalado, que estava operando em
plataforma no-grfica e obsoleta; (3) necessidade de migrao da plataforma para ambiente
com suporte tcnico disponvel no mercado; (4) integrao do mdulo de Recursos Humanos,
anteriormente gerenciado por fornecedor externo; e (5) necessidade de aumentar a eficincia
das reas funcionais de gesto de contratos, finanas, contabilidade e recursos humanos.
7.2 Processo de Implantao
Neste caso, foram implantados quatro mdulos do sistema integrado de gesto
Protheus 10:: financeiro, responsvel pelos processos financeiros da empresa; mdulo
contbil, responsvel pela contabilidade fiscal e gerencial da empresa; mdulo de RH que
gerencia os recursos humanos; e o mdulo de gesto de contrato de clientes, que controla os
diversos contratos que a empresa possui com seus clientes.

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

O Processo de implantao foi iniciado em setembro de 2009 e foi dividido em

diversas etapas pr-estipuladas pela equipe da TOTVS. Tratou-se inicialmente da implantao
dos quatro mdulos de maneira separada, ou seja, de acordo com a estratgia de implantao
em fases segundo Souza e Saccol (2006).
O mdulo de RH no apresentou muitos problemas. Entretanto, isso s foi possvel
devido ao maior grau de independncia deste mdulo em relao aos demais e pelo fato desse
mdulo no ser utilizado anteriormente e ser bastante padronizado. A implantao apresentou
apenas problemas pequenos relacionados a clculos incorretos de horas extras, 13 salrio e
frias. Outro ponto importante a ser destacado a experincia do usurio contratado
exclusivamente para operar o novo mdulo de RH, que identificava facilmente os erros,
devido sua experincia anterior com o sistema.
Os mdulos de Contabilidade e Finanas, nesta ordem, iniciaram os testes aps o
mdulo de RH. O mdulo de Contabilidade apresentou pequenos erros em frmulas e
relatrios. O mdulo de Finanas apresentou ausncia de mais opes de relatrios, em
comparao com o sistema anterior, e tambm apresentou problemas relacionados aos
pagamentos realizados no estacionamento, pois o novo sistema no oferecia uma maneira
eficaz de lidar com as modalidades de pagamentos e suas particularidades.
O mdulo de Gesto de Contratos o mais complexo existente no pacote e no se
assemelha aos padres existentes no mercado. Algumas peculiaridades desse mdulo podem
ser destacadas: (1) existem contratos de faturamento e de no-faturamento; (2) os contratos de
no-faturamento tm durao de 12 meses, enquanto os de faturamento variam de 12 meses
at prazo indeterminado; (3) o pagamento de aluguis feito mensalmente por um valor fixo
definido em contrato, podendo ser complementados por um percentual do faturamento; (4) os
contratos de faturamento tm reajustes de 20% do valor fixo nos meses de dezembro e janeiro
e 10% nos meses de julho; (5) os contratos podem sofrer alteraes em qualquer poca do
ano, pois esto ligados a fatores imprevisveis como queda no rendimento dos
estabelecimentos enegociaes entre donos de lojas e a empresa.
Ao iniciar a etapa de testes do mdulo de Contratos descobriu-se que havia muitos
erros no produto, e tambm a necessidade de uma parametrizao mais adequada. As
alteraes eram feitas no mdulo e o mesmo era reinserido no ambiente de testes da empresa.
Entretanto, essa atividade se tornou recorrente, ou seja, o processo de descontextualizao e
recontextualizao do aplicativo ocorria com freqncia acima do normal. Alm dos erros
pontuais, ocorreram diversos problemas em questes j solucionadas, ou seja, quando um erro
corrigido, outros, anteriormente solucionados, voltam a apresentar problemas. Por se tratar
de tarefas e rotinas muito especficas para cada tipo de contrato, os ajustes no ERP
inicialmente definidos pela Totvs, no foram capazes de atender as necessidades da empresa.
Em funo disso, o cliente e o desenvolvedor concluram que o mdulo precisava ser refeito,
pois as medies anteriormente eliminadas se mostraram indispensveis para a melhor
aderncia do produto.. Como conseqncia, foi necessrio envolver a equipe de
desenvolvimento de sistemas da TOTVS.
7.3 Apresentao dos Resultados
Os dados foram coletados atravs de entrevistas realizadas com diversos colaboradores
que desempenharam um papel relevante no processo de implantao e principalmente na fase
de testes. Foram entrevistados cinco usurios-chave, sendo dois responsveis pelo mdulo de
Contratos e trs responsveis pelos mdulos de Finanas, Contabilidade e Recursos Humanos.
Adicionalmente, foram entrevistados um funcionrio da empresa desenvolvedora (TOTVS),
10

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

responsvel pelo mdulo de Contratos e o responsvel pela rea de TI da empresa.

A Tabela 1 apresenta um resumo das dificuldades enfrentadas durante a fase de testes
segundo a viso dos entrevistados. Um dos mdulos, o de contratos, apresenta
particularidades associadas ao negcio da Rodexo S/A. Essa caracterstica dificultou a
implantao e principalmente os testes, ou seja, a identificao e correo dos erros. Cabe
destacar que as dificuldades em se adequar o mdulos funcionalidades exigidas pelos
Contratos, dificultou a validao e os testes do mesmo.
TABELA 1 - Dificuldades encontradas na fase de testes do sistema Protheus 10.
Partes interessadas

Dificuldades enfrentadas

Usurios-chave

Ausncia de um roteiro de testes representa falta de um guia para verificar

funcionalidades do sistema;
Desconhecimento do manual explicando o aplicativo aumenta a dependncia aos
treinadores da empresa desenvolvedora;
Falta de treinamento dirio atrasa o processo de aprendizado com o sistema;
Difcil conciliar as atividades dirias com os testes com o novo sistema;
No possvel lembrar-se de todas as situaes em que o sistema utilizado na
prtica para prever onde os erros podem ocorrer.

Desenvolvedor

A mudana no escopo do sistema com tantos ajustes realizados dificulta o termino

do projeto;
Adequao com a situao e com o problema por t-lo assumido recentemente;
Os diversos testes realizados mostram a real complexidade do produto, porm
difcil prever todas as situaes nos testes;
A gesto de contratos complexa e tem caractersticas especficas. O sistema
implantado lida bem com produtos manufaturados, mas quando se trata de
servios, como a locao de espao fsico, h necessidade de muitas adaptaes.

Responsvel pela rea

de TI

A comunicao entre desenvolvedor e cliente no foi eficaz a ponto de solucionar

os erros encontrados;
Os usurios foram capacitados em seus mdulos, mas o atraso na implantao
provocado pelos problemas com Gesto de Contratos, acabou prejudicando o
aprendizado e dificultando a utilizao do sistema posteriormente;
A mudana do responsvel pela adequao do mdulo de Gesto de Contratos,
deixou a situao mais complexa, pois aumentou o tempo para compreenso e
soluo dos problemas.

Fonte: Slack et al. (1999).

8. Discusso dos Resultados

A partir das dificuldades evidenciadas na implantao do sistema Protheus 10 foi
possvel identificar fatores que influenciaram a implantao e principalmente a fase de testes.
Um primeiro fator que acabou se tornando perceptvel a todos os envolvidos na implantao
foram as funcionalidades exigidas pelo mdulo de Contratos e que no foram identificadas na
fase de especificao e verificao da aderncia do sistema. Esse problema sobrecarregou a
fase de testes pela identificao de vrios requisitos no atendidos.
Os dados permitiram ver a diferena da viso entre os funcionrios e os patrocinadores
do projeto, isto , com o desconhecimento das sistemticas de implantao e de sistemas ERP
de modo geral pelos primeiros, estes desejavam maior suporte atravs de manuais e
11

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

treinamento em perodo integral, sendo que a metodogia adotada previa a capacitao inicial
nos mdulos e o treinamento continuado num perodo de testes alongado aps a implantao.
Um aspecto importante e percebido durante a coleta de dados foi o quadro reduzido de
funcionrios, tpico de pequenas e mdias empresas. Com exceo da seo de Contratos, as
reas de Recursos Humanos, Contabilidade e Finanas possuem apenas um funcionrio cada
uma. Nessa realidade, os usurios-chave e os usurios alvos so os mesmos, tendo que
aprender o novo sistema, gerar relatrios de testes para o desenvolvedor e operar o sistema
antigo para garantir as atividades cotidianas da empresa.
Finalmente, cabe destacar que foi a ocorrncia de fatores contingenciais durante a fase
de implantao que dificultou e atrasou o projeto. Entre eles, destaca-se o afastamento do
desenvolvedor do projeto por parte da empresa desenvolvedora, durante a fase de testes. Essa
situao, no prevista, atribuiu maior dificuldade no andamento do projeto.
9. Consideraes Finais
O objetivo deste trabalho foi identificar as dificuldades que surgem durante a fase de
testes no processo de implantao de um sistema ERP em uma organizao. Este objetivo foi
atingido por meio de uma pesquisa qualitativa e exploratria, utilizando a estratgia de estudo
de caso, aplicada em uma organizao localizada na cidade de So Paulo. Cabe destacar, que
a pesquisa investigou o processo de implantao de um sistema ERP, em especial a fase de
testes, e apesar de ter seguido com rigor o procedimento metodolgico, apresenta limitaes.
Entre elas destacam-se a impossibilidade para efetuar generalizaes cientficas e a falta de
outras fontes de informao que pudessem reduzir o vis dos pesquisadores e aumentar o
rigor metodolgico (YIN, 2005).
Ao realizar o projeto de implantao percebeu-se que os maiores problemas surgiram
durante a fase de testes. Nesta fase, as dificuldades puderam ser associadas capacidade de
antecipar situaes em que os erros ocorreram, falta de eficcia na comunicao entre
cliente e desenvolvedor, inexperincia dos usurios e falta de um adequado planejamento e
execuo dos testes. Essa realidade dificultou o aprendizado das funcionalidades do sistema e
limitou a execuo de testes mais adequados.
Durante a fase de testes foi possvel perceber uma heterogeneidade do grupo de
usurios, que uma questo atpica e retratada nos estudos de casos vistos em Souza e Saccol
(2006). Um grupo composto por usurios experientes e sem experincia nenhuma causa um
desequilbrio no processo de implantao, visto que por um lado se tem usurios que operam
o novo sistema eximiamente e por outro um grupo que apresenta dificuldades em oper-lo,
pois possui experincia apenas com sistema mais antigos e com tecnologia obsoleta.
Uma questo relevante a se destacar que as metodologias de implantao de sistemas
ERP tratam as empresas de forma genrica e so voltadas sobretudo para grandes empresas.
Nas pequenas e mdias empresas esses mtodos precisam sofrer srias modificaes. Um
exemplo dessa realidade a questo de no prever que os usurios-chave podem ser os
prprios usurios-alvo, pois so os nicos nas reas funcionais da empresa e precisam
fracionar o tempo de trabalho para que possam realizar as atividades da fase de testes e
simultaneamente desempenhar suas funes cotidianas.
As evidncias encontradas nesta pesquisa ajudam a formular novos problemas de
pesquisa. Como conseqncia, pretende-se analisar, em futuras pesquisas, quais as aes
recomendadas na fase de testes de sistemas ERP e a respectiva contribuio no resultado da
implantao do sistema. Pesquisas atravs de surveys (enquetes) podem contribuir para o
12

XVIII SIMPSIO DE ENGENHARIA DE PRODUO

Gesto de projetos e Engenharia de produo

Bauru, SP, Brasil, 08 a 10 de novembro de 2010

conhecimento dessa realidade.

Referncias
ABBAD, I. S. G. Avaliao de sistemas empresariais. Dissertao de Mestrado. Universidade Federal do Rio
Grande do Sul, 2002.
ALBUQUERQUE. J. P. Por uma Perspectiva Sociotcnica no Desenvolvimento de Sistemas de Computao: o
exemplo do Modelo Mikropolis. II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software
WOSES. Vila Velha, Esprito Santo, 2006.
EISENHARDT K. M. Building Theories from Case Study Research. Academy of Management Review, v. 14, n.
4, p. 532-550, 1989.
ESCOUTO, R. M. C; SCHILLING, L. F. Proposta de metodologia de seleo de sistemas ERP para uma
empresa de mdio porte. In: Sistemas ERP no Brasil: (Enterprise Resolutions Problems): Teoria e Casos. Souza,
C. A; Saccol, A. Z (organizadores) 1 ed. So Paulo: Atlas, 2006.
FIESP Pesquisa: Perfil da Empresa Digital. Disponvel em: <http://www.fiesp.com.br/download/ pesquisa/
PERFIL%20DA%20EMPRESA%20DIGITAL%202002.pdf> acesso em: 27 mai de 2010.
LAUDON, K. C.; LAUDON, J. P. Sistemas de Informao Gerenciais: administrando a empresa digital, 7 ed.
So Paulo: Prentice Hall, 2007.
LARMAN, C. Utilizando UML e Padres, 3 ed. So Paulo: Bookman, 2007.
MENDES, J. V; ESCRIVO FILHO, E. Sistemas integrados de gesto ERP em pequenas empresas: Um
confronto entre o referencial terico e a prtica empresarial. Revista Gesto e Produo, v. 9, n. 3, p. 277-296,
dezembro, 2002.
NEVES, J. M. S; SANTOS, F. C. A. Implantao de tecnologias de informao utilizadas na integrao entre o
cho-de-fbrica e os sistemas ERP. XXVII Encontro Nacional de Engenharia de Produo. Foz do Iguau,
Paran, 2007.
OLIVEIRA, A. C. Estratgia de Testes para Implantao de Sistemas ERP. Dissertao de Mestrado.
Universidade Estadual de Campinas, 2003.
PADILHA, T. C. C. (2005) Sistemas ERP: caractersticas, custos e tendncias. In: Revista Produo, v. 15, n. 1,
p. 102-113, Jan./Abr. 2005.
PRESSMAN, R. S. Engenharia de Software, 6 ed. So Paulo: Macgraw-hill, 2006.
RICHARDSON, R. J; PERES, J. A. S; WARDELEY, J. C. V; CORREIA, L. M; PERES, M. H. M. Pesquisa
Social - Mtodos e Tcnicas. So Paulo: Atlas, 1999.
SELLTIZ, C; WRIGHTMAN, L. S; COOK, S. W. Mtodos de pesquisa nas relaes sociais. So Paulo: EPU,
1987.
SOUZA, C. A; SACCOL, A. Z. Sistemas ERP no Brasil: (Enterprise Resolutions Problems): Teoria e Casos, 1
ed. So Paulo: Atlas, 2006.
WOOD Jr., T; Paula, A. P; Caldas, M. P. Despindo o Big Brother: Sistemas Empresariais e totalitarismo
corporativo. In: Sistemas ERP no Brasil: (Enterprise Resolutions Problems): Teoria e Casos. Souza, C. A.;
Saccol, A. Z (organizadores) 1 ed. So Paulo: Atlas, 2006.
YIN, R. K. Estudo de caso planejamento e mtodos. Porto Alegre: Bookman, 2005.
ZWICKER, R; Souza, C. A. Sistemas ERP: Conceituao, ciclo de vida e estudos de casos comparados. In:
Sistemas ERP no Brasil: (Enterprise Resolutions Problems): Teoria e Casos. Souza, C. A.; Saccol, A. Z
(organizadores) 1 ed. So Paulo: Atlas, 2006.

13