motivações para o projeto

UNIVERSIDADE DE SÃO PAULO FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E CONTABILIDADE

DEPARTAMENTO DE ADMINISTRAÇÃO

UM ESTUDO SOBRE PROJETOS DE IMPLEMENTAÇÃO DE SISTEMAS PARA GESTÃO EMPRESARIAL

SIDNEI BERGAMASCHI

ORIENTADOR: PROF. DR. NICOLAU REINHARD

SÃO PAULO 1999

Reitor da Universidade de São Paulo Prof. Dr. Jacques Marcovitch Diretor da Faculdade de Economia, Administração e Contabilidade Prof. Dr. Eliseu Martins Chefe do Departamento de Administração Prof. Dr. Claudio Felisoni de Angelo

UNIVERSIDADE DE SÃO PAULO FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E CONTABILIDADE

DEPARTAMENTO DE ADMINISTRAÇÃO

UM ESTUDO SOBRE PROJETOS DE IMPLEMENTAÇÃO DE SISTEMAS PARA GESTÃO EMPRESARIAL

SIDNEI BERGAMASCHI

ORIENTADOR: PROF. DR. NICOLAU REINHARD

Dissertação apresentada ao Departamento de Administração da Faculdade de Economia, Administração e Contabilidade da Universidade de São Paulo, como parte dos requisitos para a obtenção do título de Mestre em Administração.

SÃO PAULO 1999

FICHA CATALOGRÁFICA

Bergamaschi, Sidnei Um estudo sobre projetos de implementação de sistemas para gestão empresarial / Sidnei Bergamaschi. – São Paulo : FEA/USP, 1999.

Xiii, 181 p. Dissertação – Mestrado. Bibliografia.

1. Administração de empresas 2. Administração da informação 3. Administração – Sistemas de informação 4. Projetos – Administração I. Faculdade de Economia, Administração e Contabilidade da USP. II. Título.

CDD – 658.403

iii

À minha família,

à minha esposa Valéria,

e ao meu filho que vai nascer.

São Paulo, Julho de 1999

O Autor

iv

AGRADECIMENTOS

Ao meu orientador, Prof. Dr. Nicolau Reinhard, pelo acompanhamento

durante todo o curso de mestrado e pela orientação e apoio no desenvolvimento

desta dissertação, desde sua concepção até sua conclusão.

Ao Prof. Dr. Eduardo Martins Morgado, pelo incentivo ao retorno à

Universidade.

Prof. Dr. Jair Manfrinato e ao Prof. Roberto Nogueira, pela grande ajuda e

orientação prestadas na parte estatística.

Aos amigos Andréa Carla G. Vianna, João Pedro Albino, Maria Alexandra

V. C. Cunha, Wilson M. Yonezawa, pela prestativa colaboração, ajuda e estímulos,

sempre presentes.

Ao Prof. Hélio Requena, Profa. Marileide Dias Esqueda e Inaiê M. Wenzel,

pela cuidadosa revisão do material.

À Lícia Abe, Vera Lúcia Sakamoto, e às funcionárias da pós-graduação e da

biblioteca, sempre muito prestativas e atenciosas durante todo o tempo.

Aos meus colegas de trabalho, que compartilharam minhas dificuldades e

souberam ajudar na hora certa.

À Tilibra S/A Produtos de Papelaria, que ajudou a tornar possível minha

participação neste curso, em especial aos Srs. Luis Antonio de Silos Carvalho e

Mário Ramires.

À Universidade do Sagrado Coração – na pessoa da Ir. Geni da Silva – e à

CAPES pelo apoio prestados, extremamente importantes para a realização deste

curso.

v

À Price Waterhouse Coopers – através do Sr. Sérgio Lozinsky – pela

disposição em auxiliar na pesquisa.

Às empresas, aos gerentes de projeto e a todos os que responderam aos

questionários da pesquisa, por seu tempo, auxílio, paciência e cooperação.

Aos meus pais, meu irmão e minha esposa Valéria, pelo constante apoio,

compreensão e incentivo, e pela grande ajuda prestada nos momentos mais

importantes.

A Deus, pela possibilidade de realizar este trabalho e tê-lo concluído.

vi

RESUMO

Este trabalho de pesquisa, organizado sob a forma de uma Dissertação de

Mestrado em Administração, estuda os fatores envolvidos na implementação de

pacotes de software para gestão empresarial, ou sistemas ERP – Enterprise

Resources Planning – no contexto de empresas usuárias desse tipo de sistema.

Além de uma pesquisa, este trabalho também é composto por uma revisão

bibliográfica sobre os principais assuntos abordados, tais como: pacotes de software

para gestão empresarial; administração de projetos; fatores críticos de sucesso em

projetos; redesenho de processos de negócios; e adoção de novas tecnologias.

Para a execução da pesquisa, foi realizado um survey com uma amostra

formada por 43 empresas, no Brasil, que já tivesse implementado ou estivesse em

um projeto de implementação de algum pacote de software ERP.

Os resultados obtidos com a análise dos dados buscam traçar um quadro

sobre os projetos de implementação de pacotes de software para gestão empresarial

no Brasil, além de estabelecer a existência ou não de relações entre alguns fatores,

considerados críticos nesse tipo de projeto, e o sucesso dos projetos.

vii

ABSTRACT

This research, organized under the form of a Mastership Dissertation in

Business Administration, studies the factors involved in the implementation of ERP

– Enterprise Resources Planning – systems, in the context of companies that use

that sort of system.

Besides a research, this essay is also composed by a bibliographical

revision on the main approached subjects, such as: integrated software packages for

business management; project management; critical success factors in projects; BPR

– business process reengineering; and adoption of new technologies.

For the execution of the research, a survey was accomplished with a sample

formed by 43 companies in Br azil, that had already implemented or it was in

an implementation project of some ERP software.

The results obtained with the analysis of the data outline a chart on the

projects of ERP software implementation in Brazil, besides establishing the

existence or not of relationships among some factors, considered critical in that

project, and the success of the projects.

viii

ÍNDICE

CAPÍTULO 1: OBJETIVO DA PESQUISA.............................................................................................1

INTRODUÇÃO................................................................................................................................................... 1

O Mercado de Sistemas ERP..................................................................................................................3

IDENTIFICAÇÃO DO PROBLEMA.................................................................................................................... 7

OBJETIVOS DO TRABALHO ............................................................................................................................ 8

JUSTIFICATIVAS PARA A PESQUISA .............................................................................................................. 9

ORGANIZAÇÃO DA DISSERTAÇÃO.............................................................................................................. 10

SUMÁRIO........................................................................................................................................................ 11

CAPÍTULO 2: REVISÃO DA LITERATURA......................................................................................12

ERP – ENTERPRISE RESOURCE PLANNING............................................................................................... 12

DECISÃO DE ADOÇÃO DE UM SOFTWARE ERP ........................................................................................ 15

IMPLEMENTAÇÃO DE PROJETOS ERP ........................................................................................................ 20

ESTRATÉGIAS DE IMPLEMENTAÇÃO........................................................................................................... 24

ADMINISTRAÇÃO DE PROJETOS.................................................................................................................. 27

FATORES CRÍTICOS DE SUCESSO ................................................................................................................ 31

Alinhamento.............................................................................................................................................35

Envolvidos na Implementação do Projeto .........................................................................................37

Mudanças na Organização...................................................................................................................43

BPR – Business Process Reengineering .............................................................................................. 43

Customizações...................................................................................................................................... 49

Presença de Consultorias em Projetos ERP......................................................................................50

MEDIDAS DE SUCESSO DE PROJETOS......................................................................................................... 54

ADOÇÃO DE NOVAS TECNOLOGIAS........................................................................................................... 57

SUMÁRIO........................................................................................................................................................ 61

CAPÍTULO 3: MODELO DE PESQUISA..............................................................................................62

MODELO DE PESQUISA................................................................................................................................. 62

HIPÓTESES DA PESQUISA............................................................................................................................. 65

DEFINIÇÃO DAS VARIÁVEIS........................................................................................................................ 66

MÉTODOS....................................................................................................................................................... 72

Survey.......................................................................................................................................................72

Questionários..........................................................................................................................................74

UNIVERSO DA PESQUISA.............................................................................................................................. 77

AMOSTRA....................................................................................................................................................... 79

COLETA DOS DADOS .................................................................................................................................... 80

ÍNDICE

ix

Mapeamento do Questionário..............................................................................................................80

Identificação ......................................................................................................................................... 81

Caracterização do Respondente............................................................................................................ 81

Caracterização do Projeto..................................................................................................................... 82

Motivações para o Projeto.................................................................................................................... 83

Disposição para a Mudança.................................................................................................................. 83

Fatores Críticos de Sucesso.................................................................................................................. 83

Adoção de Tecnologia.......................................................................................................................... 85

Sucesso do Projeto................................................................................................................................ 85

Colocação do Sistema em Produção .................................................................................................... 86

Satisfação com a Informática ............................................................................................................... 86

Aplicação do Questionário ...................................................................................................................86

Tratamento e Processamento Estatístico de Dados.........................................................................88

SUMÁRIO........................................................................................................................................................ 89

CAPÍTULO 4: ANÁLISE DE DADOS .....................................................................................................90

INTRODUÇÃO................................................................................................................................................. 90

ANÁLISE DESCRITIVA .................................................................................................................................. 91

Composição da Amostra .......................................................................................................................91

Características das empresas...............................................................................................................91

Faturamento Anual............................................................................................................................... 92

Número de Funcionários ...................................................................................................................... 92

Segmentos ............................................................................................................................................ 93

Características dos Projetos................................................................................................................94

Tamanho da equipe de Projeto............................................................................................................. 94

Tempo de Duração de Projeto.............................................................................................................. 95

Módulos Implementados...................................................................................................................... 96

Valor do Projeto................................................................................................................................... 97

Pacotes de Software na Amostra ........................................................................................................ 100

Entrada em Produção do Projeto........................................................................................................ 101

Entrada em Produção “Big bang” ...................................................................................................... 102

Motivações para o Projeto................................................................................................................. 103

Motivações dos Gerentes de Projeto.................................................................................................. 104

Motivações dos Usuários.................................................................................................................... 106

Fatores Críticos de Sucesso nas Fases do Projeto........................................................................ 108

Fatores Críticos para os Gerentes de Projeto...................................................................................... 108

Fatores Críticos para os Usuários....................................................................................................... 111

TESTE DE HIPÓTESES..................................................................................................................................112

Hipótese 1 ............................................................................................................................................. 113

Medidas do Sucesso do Projeto........................................................................................................ 113

Hipótese 2 ............................................................................................................................................. 115

Hipótese 3 ............................................................................................................................................. 116

Hipótese 4 ............................................................................................................................................. 116

ÍNDICE

x

Hipótese 5 ............................................................................................................................................. 117

Hipótese 6 ............................................................................................................................................. 117

Hipótese 7 ............................................................................................................................................. 118

Hipótese 8 ............................................................................................................................................. 119

Hipótese 9 ............................................................................................................................................. 119

Hipótese 10........................................................................................................................................... 120

ANÁLISES EXPLORATÓRIAS......................................................................................................................120

Adoção de Tecnologia........................................................................................................................ 120

Relações entre os Componentes de Sucesso ................................................................................... 122

Relações com o Porte das Empresas e dos Projetos..................................................................... 123

Comparação entre as Motivações.................................................................................................... 125

SUMÁRIO......................................................................................................................................................127

CAPÍTULO 5: CONCLUSÕES E RECOMENDAÇÕES ................................................................ 128

CONCLUSÕES...............................................................................................................................................128

Características dos Projetos............................................................................................................. 129

Motivações para o Projeto................................................................................................................. 131

Fatores Críticos de Sucesso............................................................................................................... 132

Adoção de Tecnologia........................................................................................................................ 134

RECOMENDAÇÕES......................................................................................................................................135

SUGESTÕES DE PESQUISA ..........................................................................................................................137

SUMÁRIO......................................................................................................................................................138

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................... 139

ANEXOS ........................................................................................................................................................ 151

LISTA DE QUADROS

Quadro 1: Mudança no ambiente empresarial de 1970-1985 e 1985-2000...........................................................14

Quadro 2: Diferentes participantes de projetos ERP.................................................................................................39

LISTA DE FIGURAS

Figura 1: Evolução das vendas de software ERP nas indústrias de processo.........................................................4

Figura 2: Os 10 maiores fornecedores de software ERP, em receita. ......................................................................4

Figura 3: Valor de mercado dos 3 maiores fornecedores de software ERP ............................................................5

Figura 4: Exemplo de um ciclo de vida genérico, em relação ao custo do projeto..............................................29

Figura 5: Ciclo de vida de projeto de Morris, em relação à execução do projeto...............................................30

ÍNDICE

xi

Figura 6: Modelo de equipe de projeto.........................................................................................................................38

Figura 7: Previsão de gastos com treinamento em software ERP ...........................................................................41

Figura 8: Níveis de transformação de negócios promovidos pela TI......................................................................45

Figura 9: Questões para avaliação do impacto da TI nas forças competitivas.....................................................47

Figura 10: Dimensões interdependentes do sucesso de projetos de sistemas de informação.............................55

Figura 11: Modelo do diamante, de Leavitt.................................................................................................................58

Figura 12: Modelo de Kwon-Zmud sobre o processo de implementação...............................................................60

Figura 13: Modelo de pesquisa apresentado graficamente......................................................................................65

Figura 14: Representação da ligação entre necessidade de informação e dados................................................75

Figura 15: Exemplo do uso de escalas no questionário............................................................................................77

Figura 16: Distribuição das empresas segundo o faturamento anual (milhões R$).............................................92

Figura 17: Distribuição das empresas segundo o número de funcionários...........................................................93

Figura 18: Distribuição das empresas segundo o tamanho da equipe de projeto................................................95

Figura 19: Tempo de duração (meses) dos projetos da amostra .............................................................................96

Figura 20: Módulos implementados nos projetos da amostra..................................................................................97

Figura 21: Valor dos projetos da amostra (milhões R$) ...........................................................................................98

Figura 22: Distribuição de valores dos projetos da amostra, em seus componentes...........................................99

Figura 23: Gráfico do faturamento anual x valores de projeto...............................................................................99

Figura 24: Gráfico do número de funcionários x valores de projeto................................................................... 100

Figura 25: Tipos de entrada em produção dos projetos da amostra.................................................................... 101

Figura 26: Tipo de entrada em produção “big bang”............................................................................................. 102

Figura 27: Tipo de entrada “big bang” x valor do projeto (milhões R$)............................................................. 103

Figura 28: Motivações para o projeto, na visão dos gerentes de projeto........................................................... 105

Figura 29: Proporção das motivações atingidas, na visão dos gerentes de projeto......................................... 105

Figura 30: Motivações dos usuários do projeto....................................................................................................... 107

Figura 31: Proporção das motivações atingidas, na visão dos usuários............................................................ 107

Figura 32: Fatores críticos na fase 1, para os gerentes ....................................................................................... 110

Figura 33: Fatores críticos na fase 2, para os gerentes ....................................................................................... 110

Figura 34: Fatores críticos na fase 3, para os gerentes ........................................................................................ 110

Figura 35: Fatores críticos na fase 4, para os gerentes ........................................................................................ 110

Figura 36: Fatores críticos na fase 1, para os usuários ........................................................................................ 111




LISTA DE TABELAS

Tabela 1: Número de participantes da amostra ..........................................................................................................91

Tabela 2: Faturamento anual (milhões R$) das empresas da amostra...................................................................92

ÍNDICE

xii

Tabela 3: Número de funcionários das empresas da amostra ..................................................................................93

Tabela 4: Segmento de atuação das empresas da amostra .......................................................................................94

Tabela 5: Tamanho da equipe nos projetos da amostra ............................................................................................94

Tabela 6: Tempo de duração (meses) nos projetos da amostra ...............................................................................95

Tabela 7: Duração média dos projetos.........................................................................................................................96

Tabela 8: Módulos implementados nos projetos da amostra....................................................................................97

Tabela 9: Valor dos projetos da amostra (milhões R$).............................................................................................98

Tabela 10: Fornecedores de software dos projetos da amostra............................................................................ 100

Tabela 11: Tipos de entrada em produção dos projetos da amostra.................................................................... 101

Tabela 12: Tipo de entrada em produção “big bang”............................................................................................. 102

Tabela 13: Tipo de entrada “big bang” x valor do projeto (milhões R$)............................................................. 103

Tabela 14: Motivações para o projeto, na visão dos gerentes de projeto........................................................... 104

Tabela 15: Teste de proporção das motivações, na visão dos gerentes de projeto............................................ 105

Tabela 16: Motivações para o projeto, na visão dos usuários.............................................................................. 106

Tabela 17: Teste de proporção das motivações, na visão dos usuários............................................................... 106

Tabela 18: Fatores críticos, em cada fase do projeto, para os gerentes ............................................................. 110

Tabela 19: Fatores críticos, em cada fase, para os usuários................................................................................. 111

Tabela 20: Teste de proporção para as motivações................................................................................................ 113

Tabela 21: Teste de correlação para o fator “Missões claras e definidas” ....................................................... 116

Tabela 22: Teste de correlação para o fator “Apoio da alta administração”.................................................... 116

Tabela 23: Teste de correlação para o fator “Usuários capazes e envolvidos”................................................ 117

Tabela 24: Teste de correlação para o fator “Planejamento detalhado”........................................................... 117

Tabela 25: Teste de correlação para o fator “Gerente de projeto com habilidades necessárias”................. 118

Tabela 26: Teste de correlação para o fator “Presença de empresa de consultoria”...................................... 118

Tabela 27: Teste de correlação para o fator “Mudança nos processos de negócios”...................................... 119

Tabela 28: Teste de correlação para a satisfação dos usuários com os sistemas.............................................. 120

Tabela 29: Teste de correlação para a disposição da empresa para mudança.................................................. 120

Tabela 30: Teste de proporção para adoção de tecnologia, na opinião dos gerentes...................................... 121

Tabela 31: Teste de proporção para adoção de tecnologia, na opinião dos usuários...................................... 122

Tabela 32: Correlações entre os componentes do sucesso..................................................................................... 123

Tabela 33: Teste de proporção para as motivações no grupo de gerentes ......................................................... 126

Tabela 34: Teste de proporção para as motivações no grupo de usuários......................................................... 126

LISTA DE ANEXOS

Anexo 1: Carta de apresentação ................................................................................................................................. 151

Anexo 2: Questionário.................................................................................................................................................. 153

Anexo 3: Ranking das 100 maiores empresas de software para manufatura, nos EUA ................................... 160

Anexo 4: Resultados do SPSS usados na análise descritiva................................................................................... 169

ÍNDICE

xiii

Anexo 5: Resultados do SPSS usados no teste de hipóteses................................................................................... 176

Anexo 6: Resultados do SPSS usados nas análises exploratórias......................................................................... 178

1

Capítulo 1

OBJETIVO DA PESQUISA

INTRODUÇÃO

O mercado brasileiro de sistemas vem presenciando, nos últimos anos, uma

demanda crescente no uso de pacotes de softwares destinados à gestão empresarial,

os chamados sistemas ERP – Enterprise Resources Planning (Planejamento de

Recursos Empresariais). Este fato não é exclusividade do mercado brasileiro, mas

sim parte de um fenômeno mundial.

Sistemas prontos, na forma de pacotes de software não são exatamente

novidades, mas o fato é que, somente nos últimos anos, os grandes pacotes de

software, que proclamam a capacidade de fornecer uma solução de sistemas única

para a gestão de toda a organização, começaram a ser uma presença marcante em

empresas no mundo todo.

Diversas são as razões apontadas para o crescimento e busca de soluções na

forma de pacotes de software, desde a incapacidade dos sistemas atuais em atender

todas as necessidades da empresa, a falta de atualização de sistemas para

acompanhar o “estado da arte” tecnológico, a não-integração apropriada de dados e

informações – muitas vezes provenientes de uma grande variedade de sistemas – até

o chamado bug do milênio, evento que pode ocorrer com sistemas que não estejam

preparados para lidar com a passagem de datas do ano de 1999 para o ano 2000.

Sob um outro aspecto, as empresas vêm enfrentando pressões para redução

de custos, aumento de consumo, concorrência acirrada, abertura de mercados a

CAPÍTULO 1: OBJETIVO DA PESQUISA

2

novos competidores, mudanças tecnológicas realizadas pelos concorrentes e outros

fatores que as têm levado a buscar soluções de tecnologia cada vez melhores, até

mesmo questionando suas estruturas internas de informática.

Estes e outros motivos resultam em uma grande busca pela implementação

de sistemas ERP, principalmente dos softwares dos grandes competidores deste

mercado. Estima-se que em 1997 somente a venda de licença de software ERP, nos

EUA, ultrapassou US$ 10 bilhões, sendo o valor total – inclui-se consultoria,

treinamento, hardware, e outros – movimentado por este segmento de US$ 35

bilhões. No Brasil, no mesmo ano, as vendas de licenças chegaram a R$ 200

milhões. Em ambos os casos, observa-se um crescimento acelerado da procura por

esses sistemas e estima-se que este crescimento ainda deve perdurar pelos próximos

anos, pelo menos até o ano 2000.

Além disso, os riscos e a insegurança com o bug do milênio também podem

estar inflando, até certo ponto, de maneira artificial, esse mercado, o que pode

provocar grandes mudanças após a passagem para o ano 2000.

Os projetos que resultam na implementação de um sistema ERP

normalmente são considerados como sendo demorados e caros, chegando algumas

vezes a vários anos e a várias dezenas de milhões de dólares. Em função disso,

fracassos na implementação desses projetos normalmente podem se tornar grandes

desastres para todos os envolvidos.

A grande atenção que a implementação desses projetos tem provocado na

imprensa especializada, a importância atribuída aos projetos e o tamanho dos

mesmos, motivaram o desenvolvimento deste trabalho, que se dedica ao estudo da

problemática e das características presentes em projetos de implementação de

sistemas ERP.


3

O MERCADO DE SISTEMAS ERP

Apesar da Internet ter sido um dos principais assuntos da mídia especializada

nos últimos anos, os pacotes de gestão empresarial estão ganhando cada vez mais

espaço. Muito provavelmente, algumas das principais razões para isso são a

presença desse tipo de software nas principais empresas ao redor do mundo e nos

valores envolvidos nesse mercado. A AMR – Advanced Manufacturing Research,

uma conceituada empresa de pesquisa e análise de mercado industrial, estima que,

em 1997, somente as vendas de licença de software ERP ultrapassaram US$ 10

bilhões. Se forem consideradas as vendas adicionais que acompanham o processo –

consultoria e serviços de implementação, hardware, redes, aplicações

complementares e outras ferramentas – o valor total envolvido deve ultrapassar US$

35 bilhões (Davenport, 1998; ERP ecosystem to flourish despite inroads by supply

chain firms, 1997).

A maior expansão do mercado ERP, em 1997, ocorreu na América Latina

(63%) e na Ásia/Pacífico (68%), regiões com uma rápida expansão econômica e que

enfrentam pressão competitiva para se igualar aos EUA e Europa. “O Japão deve se

transformar em um mercado importante, conforme sua mudança de software

customizado para pacotes de software [...] Além disso, China e Índia possuem um

grande potencial de mercado, visto que a maioria das empresas não utiliza sistemas

de informação” (ERP market expanding globally, 1997).

Segundo a AMR (ERP penetration of process manufacturing industry to

grow, 1997), apesar de as indústrias de processo representarem 40% de todas as

instalações industriais, apenas 20% das vendas de sistemas ERP são destinadas a

estas. Uma provável explicação para o fato é que os conceitos de MRP – que ainda

dominam muitas das aplicações ERP – focavam principalmente nos processos de

manufatura discreta. A Figura 1 demonstra esta situação:


4

Figura 1: Evolução das vendas de software ERP nas indústrias de processo

Fonte: ERP penetration of process manufacturing industry to grow, 1997.

Os fornecedores de software ERP são principalmente empresas européias e

americanas. Atualmente, quatro dos dez maiores fornecedores de sistemas ERP são

baseados na Europa, representando 45% do valor global de vendas de licença de

software. A Figura 2 demonstra a divisão entre os 10 maiores deste mercado.

Figura 2: Os 10 maiores fornecedores de software ERP, em receita.

Fonte: ERP market expanding globally, 1997.


5

Existe, no mercado americano de ações, uma acentuada confiança nas

empresas que lideram este segmento, o que se reflete no valor das suas ações. Os

três maiores fornecedores independentes de software ERP valem, juntos, US$ 43

bilhões, apesar de suas vendas, em 1996, terem sido de apenas US$ 3,3 bilhões. Isto

demonstra a expectativa de crescimento existente no segmento. Acredita-se que

essas três empresas, juntamente com a Oracle (somente se considerando sua divisão

de software corporativo), crescerão pelo menos 35% por ano, nos próximos três

anos (The best stuff Bill Gates doesn’t own, 1997). A Figura 3 demonstra os valores

de mercado dessas três empresas, comparado a outras – Sun e Netscape – do setor

de tecnologia.

Valor de Mercado

3,3

18

6,8 7

29,8

0

10

20

30

40

Data de análise: 15/10/97

US

$ b

ilhõ

es

Netscape

Sun

Peoplesoft

Baan

SAP

Figura 3: Valor de mercado dos 3 maiores fornecedores de software ERP

Fonte: The best stuff bill Gates doesn’t own, 1997.

O Manufacturing Systems Software Top 100 – ranking anual das maiores empresas

de software para a área de manufatura, mantido pela revista Manufacturing Systems

– mostra os valores de venda de software nesta área. No ranking de 1997, o valor de

vendas das 75 empresas foi de US$ 9,1 bilhões, sendo que, desse valor, US$ 5,8

bilhões, portanto aproximadamente 63%, correspondem a sistemas ERP (Michel,

1997a; Parker, 1997). O Anexo 3 mostra o ranking dos 100 maiores em 1998, onde


6

pode ser observado que as maiores empresas do setor são as que oferecem produtos

ERP.

Estes dados mundiais se repetem no Brasil, onde, segundo a revista

Computerworld, as vendas de software ERP, em 1997, foram de aproximadamente

R$ 200 milhões, com previsões para atingir R$ 500 milhões até o ano 2000.

Considerando-se que o valor do software, dentro do custo total de projetos de

implementação de software ERP, é estimado em 1/3, as previsões de negócios para

o ano 2000 chegam a R$ 1,5 bilhões (Gestão Empresarial, 1997).

No país, segundo Manzoni (1998), as maiores empresas fornecedoras de

sistemas ERP são a SAP e a Datasul (nacional), sendo seguidas por Baan, Oracle,

J.D. Edwards, Microsiga (nacional), Peoplesoft e Logocenter (nacional).

Em contrapartida ao otimismo existente em relação a esse mercado –

inegavelmente bilionário no momento atual – existem preocupações se o mesmo

realmente se manterá aquecido para os próximos anos. O principais aspectos dizem

respeito à passagem do ano 2000, que teria motivado grande procura por este tipo

de software; pelo crescimento de operações e transações pela Internet, para o que

este tipo de sistema não estaria totalmente adaptado; e ainda, pela simples saturação

do mercado, quando todas as organizações já disporiam de seu próprio ERP, assim

como seus concorrentes, o que não representaria qualquer forma de vantagem

competitiva nos negócios (ERP RIP?, 1999)

Além do valor do mercado, como um todo, os custos e tamanhos individuais

de cada projeto, algumas vezes também são extremamente altos. É o caso, por

exemplo, da Dow Chemical, que gastou 7 anos em seu projeto e meio bilhão de

dólares implementando um ERP baseado em mainframes e, atualmente, tomou a

decisão de reiniciar o processo com uma versão cliente/servidor. (Davenport, 1998,

p.122)

Os projetos ERP no Brasil também possuem tamanhos variados. Existem

grandes projetos, como, por exemplo, o da Rhodia, com previsão de US$ 25


7

milhões para implementação do SAP R/3 (A experiência Rhodia para a implantação

do SAP, 1998), ou o da VMM – Votorantim Mineração e Metalurgia – um projeto

total de US$ 400 milhões, com recursos de US$ 5 milhões na primeira fase,

previsão de duração de 14 meses e término em abril de 1999, para a implementação

do Baan (Farto, 1998b, p.6). Mas também existem projetos menores, em torno de

US$ 1 milhão, como o da Fabrimar, com duração de 8 meses e implementação do

pacote nacional Logix (Fabrimar remodela produção com ERP, 1998).

IDENTIFICAÇÃO DO PROBLEMA

A problemática envolvendo a implementação de projetos ERP reside

basicamente na existência de poucos estudos (principalmente acadêmicos) e

literatura sobre o assunto, o que levou ao desenvolvimento deste estudo exploratório

sobre o tema.

O que mais existe sobre o assunto são, normalmente, artigos de periódicos,

freqüentemente relatando casos de implementações dos grandes pacotes ERP.

Também pode ser encontrado uma grande variedade de publicações sobre os

softwares ERP que são líderes de mercado, mas, geralmente, são publicações sobre

como utilizar esses produtos.

Além disso, as consultorias especializadas na implementação de sistemas

ERP também possuem material próprio – normalmente acompanhado de uma

metodologia para tanto – , mas destinado somente a auxiliar no projeto de

implementação, funcionando mais como um conjunto de receitas prontas.

Outro aspecto, além da necessidade de explorar melhor o assunto em termos

teóricos, é verificar a aplicação de teorias da administração de projetos

especificamente para o campo da implementação de sistemas ERP.

Esse tipo de projeto pode ser considerado, em relação a projetos de TI –

Tecnologia da Informação, como caro, demorado e arriscado. Desta forma, pode ser


8

muito útil aos praticantes da área, a identificação (e confirmação) de elementos que

possam melhorar a chance de sucesso nesses projetos.

OBJETIVOS DO TRABALHO

Este trabalho busca fornecer contribuições ao estudo da implementação de

projetos de sistemas, mais particularmente de pacotes de software para gestão

empresarial, comumente identificados como sistemas de ERP – Enterprise

Resources Planning (Planejamento de Recursos Empresarias).

Dentro deste assunto, o trabalho concentra-se nos aspectos de motivação para

a realização do projeto, em fatores que podem influenciar o sucesso do mesmo e na

forma de adoção da tecnologia envolvida. Desta forma, definiram-se os seguintes

objetivos:

1. Identificar as principais motivações que levaram as organizações a iniciar

um projeto de implementação de um sistema ERP.

2. Verificar a presença de determinados fatores no projeto, que são

considerados como críticos para o sucesso de projetos. A pesquisa

concentra-se em um grupo desses fatores apresentados na literatura de

projetos e em alguns outros freqüentemente citados em textos sobre

sistemas ERP. A partir desses fatores definidos, busca-se identificar a

relação entre a presença destes e as indicações de sucesso dos projetos.

3. Verificar a variação na importância da presença desses fatores nas

diversas fases do ciclo de vida do projeto. Além de verificar a relação dos

fatores críticos com o sucesso do projeto, como citado no item anterior,

busca-se aqui analisar a importância de cada fator no decorrer do projeto,

nas várias etapas que formam o seu ciclo de vida.


9

4. Analisar os projetos em relação ao nível de adoção de tecnologia

existente. Para tanto, buscar-se-á verificar se os projetos chegaram até os

níveis de adoção, incorporação e uso da nova tecnologia.

5. Além de testar as relações entre o fatores críticos e o sucesso do projeto,

também testar o sucesso do projeto em dois aspectos: à situação da

informática existente antes da implementação do novo sistema, com base

no grau de satisfação existente em relação aos sistemas; e à disposição da

empresa para desenvolver projetos e realizar mudanças.

6. Fornecer subsídios e referências que contribuam para melhorar o

processo de implementação de projetos ERP e aumentar-lhes as chances

de sucesso. Particularmente, dando aos que estão iniciando projetos ERP

a possibilidade de identificar possíveis fatores cuja presença deva ser

levada em conta, e em quais momentos os mesmos devem merecer maior

atenção e importância.

JUSTIFICATIVAS PARA A PESQUISA

A principal justificativa para a realização desta pesquisa é o fato de, apesar

do assunto não ser exatamente novo, o mesmo ter assumido uma importância

relativamente grande na área de Tecnologia da Informação (principalmente pelos

grandes investimentos realizados) e ser verificada uma falta de estudos acadêmicos

sobre o assunto.

Como o mercado de sistemas ERP no mundo inteiro vem apresentando um

grande crescimento, que se acredita não deva ser alterado nos próximos anos, e o

mesmo parece estar acontecendo no Brasil, espera-se que, além dos valores já

investidos por muitas empresas neste tipo de projeto, muitas outras iniciem grandes

investimentos para implementar sistemas ERP. Além disso, os principais

fornecedores de software ERP vêm anunciando suas iniciativas para também atuar


10

em empresas menores, chamadas por eles de middle market – ou seja buscar um

mercado fora das grandes corporações, pois o mesmo começa a se esgotar.

Dentro desse cenário, parece justificar-se a realização de estudos que possam

auxiliar os participantes deste mercado: fornecedores, consultores e empresas

usuárias – principalmente estas últimas – a identificar fatores que sejam importantes

para facilitar o desenvolvimento de projetos de implementação de sistemas ERP e

aumentar a chance de sucesso dos mesmos, o que, em função dos recursos (tempo,

dinheiro, pessoal, e outros) exigidos para sua execução – e quase sempre escassos –

parece ser bastante interessante.

ORGANIZAÇÃO DA DISSERTAÇÃO

No capítulo seguinte – Capítulo 2 – é apresentada, de maneira breve, a

fundamentação teórica usada para o desenvolvimento da pesquisa, baseada em uma

revisão da bibliografia existente sobre os assuntos de sistemas de gestão

empresarial, pacotes de software, adoção de tecnologia, satisfação de usuários de

informática e administração de projetos.

Estes diversos assuntos são abordados por serem elementos importantes para

se formar um quadro de referência que auxilie a compreensão dos vários aspectos

da implementação de projetos ERP utilizados na pesquisa.

Já no Capítulo 3, é apresentado o modelo de pesquisa utilizado, as hipóteses

e variáveis, os procedimentos metodológicos empregados na definição da amostra,

os métodos e instrumentos de coleta de dados, bem como os elementos usados

nesta.

A análise dos dados e os resultados obtidos a partir destes são apresentados

no Capítulo 4.


11

O Capítulo 5 – final – apresenta as conclusões obtidas e possíveis sugestões

para pesquisa, derivadas a partir das observações feitas no decorrer do trabalho e

das conclusões.

SUMÁRIO

Este capítulo inicial fornece uma visão das razões e justificativas para a

realização deste projeto de pesquisa, bem como a importância do mesmo, tanto para

membros da área acadêmica quanto para atuantes no mercado de sistemas de gestão

empresarial – sejam fornecedores, consultores ou empresas usuárias.

Também são definidos os objetivos que pretendem ser atingidos com a

execução desta pesquisa.

É apresentada, ainda, uma introdução sobre o contexto atual do mercado para

sistemas de gestão empresarial – pacotes de software ERP – e sua importância na

motivação para a execução da pesquisa. Por fim, é apresentada a organização do

trabalho.

12

Capítulo 2

REVISÃO DA LITERATURA

ERP – ENTERPRISE RESOURCE PLANNING

Existem diversas definições do que é um sistema ERP – ou sistema de gestão

empresarial – mas nenhuma específica ou detalhada o suficiente para definir quais

características deverão estar obrigatoriamente presentes para a caracterização de um

sistema ERP, ou quais funcionalidades o mesmo deve atender para poder ser

classificado como tal.

A definição dada pela APICS1 para ERP é a seguinte:

ERP (Enterprise Resources Planning) é uma extensão do

conceito de planejamento de recursos de manufatura

padronizado pela APICS (American Production and Inventory

Control Society). Estes sistemas são os principais sistemas de

transações utilizados nas modernas plantas de manufatura

para automatizar e integrar os processos de administração de

negócios e da produção. Registrando transações – i.e., o

recebimento de estoque ou o processamento de uma ordem de

produção – o sistema rastreia os recursos usados na

1 A APICS foi fundada em 1957 como APICS - American Production and Inventory Control Society, mas

mudou seu nome para APICS - The Educational Society For Resource Management. Fonte: APICS. Online.

http://www.apics.org/AboutAPICS/abt2top.htm. 02/08/98.

CAPÍTULO 2: REVISÃO DA LITERATURA

13

administração financeira, de manufatura e de distribuição.

(Manufacturing Systems IT Glossary, 1998)

Esta definição da APICS sugere que o ERP é uma nova versão do MRP II –

planejamento dos recursos de manufatura. Esta versão teria sido modificada e

melhorada com o objetivo de ajudar as indústrias a enfrentarem os desafios da

competitividade dos anos 90.

Também para Gumaer (1996), o ERP ainda utiliza o mesmo modelo básico

do MRP II, somente com aplicação de “novas tecnologias de informação, como

bancos de dados relacionais, interfaces gráficas, sistemas abertos e arquitetura

cliente/servidor” (p. 32). Quanto aos avanços e melhores características de

planejamento, desenvolvidos posteriormente ao MRP II, tais como FCS (Finite

Capacity Scheduling – Planejamento de Capacidade Finita) e MES (Manufacturing

Execution Systems – Sistemas de Execução de Manufatura), estes normalmente

ainda não são abrangidos por sistemas ERP, sendo oferecidos somente por

fornecedores especializados e com foco exclusivo no assunto. Porém, é importante

destacar, como lembra Richardson (1996), que estes módulos geralmente trabalham

off-line, enquanto que o ERP possui integração total.

Já, segundo Farley (1998), o ERP está um passo à frente dos sistemas de

manufatura centrados em material, mão-de-obra e produção, pois coloca o cliente

no comando. Também Stevens (1996) afirma que o ERP é muito mais que a

próxima geração dos sistemas MRP, pois “enquanto estes planejavam uma planta, o

ERP – com suporte a múltiplas línguas e moedas – pode planejar completamente

uma organização global e muti-site, com funções de gerenciamento de fábrica,

controle de estoques e processamento de pedidos” (p. 37). Estes processos também

podem, adicionalmente, estar integrados com outras aplicações como recursos

humanos, transportes, distribuição, contabilidade, contas a pagar e receber.

É importante destacar que, baseado na época do surgimento do MRP e MRP

II em relação ao ERP, muitas das necessidades organizacionais sofreram grandes

alterações, o que passou a demandar sistemas com diferentes características das


14

existentes até então. O Quadro 1 mostra algumas das mudanças no ambiente

empresarial nesses dois períodos distintos:

De (período 1970 – 1985) Para (período 1985 – 2000)

Ciclo de produção com lead time longo Lead time curto e orientado ao mercado

Produção em massa Pequenos lotes com muita variação

Domínio das grandes corporações Domínio das corporações ágeis

Integração vertical Negócios virtuais, com parcerias

Produção interna Extensiva terceirização, contrato de trabalho

Fontes de capital fáceis Fontes de capital difíceis

Margens largas (custo + markup = preço) Grande pressão sobre margens

Mudanças técnicas e de mercado lentas Mudanças técnicas e de mercado rápidas

Centrado na produção Centrado no cliente

Produção doméstica Produção com parcerias globais

Alto custo com média gerência Pressão para organizações “enxutas”

Foco no controle de estoque Resposta ao cliente, foco no custo

Baixa confiança em computadores Alta confiança em computadores

Poder computacional limitado e caro Poder computacional abundante e barato

Quadro 1: Mudança no ambiente empresarial de 1970-1985 e 1985-2000

Fonte: Deis, 1998

Para Michel (1998), ERP é um termo genérico para “sistemas integrados

para computação corporativa”. Segundo ele, um sistema ERP “automatiza e integra

processos de negócios encontrados em ambiente de manufatura, incluindo processos

de negócios existentes no chão-de-fábrica.” Ou seja, a integração do ERP permite

que, uma vez a informação seja inserida no sistema, ela passe a estar disponível em

todo o sistema, nas diversas formas em que puder ser acessada, por quem tiver

acesso a ela.

Sistemas ERP são construídos, segundo Lozinsky (1996) como sistemas

integrados, permitindo que “a informação entre por um único ponto no sistema (por

exemplo, o Recebimento de Materiais) e atualize a base de dados de todas as

funções que utilizem de maneira direta ou indireta essa informação (no caso de um


15

recebimento de materiais, por exemplo, Estoque, Livros Fiscais, Contas a Pagar,

Custos, Contabilidade e Tesouraria)” (p. 32).

Outras características de um sistema ERP dizem respeito à operação

globalizada e diversidade de métricas. Um sistema ERP permite a operação em

diversas plantas, que podem estar distribuídas ao redor do mundo, possibilitando um

fornecimento global para peças e serviços e distribuição internacional. Isso pode

exigir diferentes métricas para mensuração de desempenho em diferentes países,

porém sempre operando de uma maneira integrada. O ERP permite à empresa

“determinar quais métricas são mais adequadas para medir eficiência em uma

economia globalizada” (Farley, 1998).

Apesar das características de integração de um sistema ERP não dependerem

obrigatoriamente de nenhum aspecto tecnológico específico, o termo ERP também é

freqüentemente associado com o uso de tecnologias modernas, tais como

cliente/servidor, bancos de dados relacionais, sistemas operacionais Unix e

Windows NT. O que ocorre com freqüência é que as características tecnológicas de

um sistema ERP são usadas como argumentos para dar-lhes uma maior

credibilidade.

Um fato importante é que os sistemas ERP se utilizam, entre outras coisas,

dessas tecnologias para produzir um banco de dados único e integrado, com acesso

unificado ao mesmo, o que permite que diversas decisões sejam tomadas

enxergando a empresa como um todo, “em vez de olhar as unidades separadamente

e tentar coordenar a informação manualmente ou reconciliar dados através de

múltiplas interfaces com algum outro aplicativo” (Stevens, 1996, p. 38).

DECISÃO DE ADOÇÃO DE UM SOFTWARE ERP

Provavelmente, somente estas características de um sistema ERP não seriam

suficientes para provocar e manter aquecida a demanda que vem ocorrendo por este


16

tipo de sistema. Alguns pontos interessantes são apontados como motivadores da

escolha de um sistema integrado, seja em uma implementação inicial, seja na

substituição de sistemas existentes.

Segundo a revista Fortune, duas tendências estão levando as empresas a

encarar a necessidade de sistemas ERP. A primeira é a necessidade de substituição

da maior parte dos sistemas para o bug do milênio – evento no qual um software

pode confundir o ano 2000 com 1900 . A segunda, é a adaptação dos sistemas das

empresas que fazem negócios na Europa às regras monetárias da União Européia,

que entrarão em vigor até 2002 (The best stuff Bill Gates doesn’t own, 1997).

Essas duas tendências residem basicamente em um ponto: os sistemas atuais

não atendem mais as necessidades da organização, e esta não está disposta a

rescrever seus sistemas ou desenvolver novos, optando por substituí-los, todos, por

um único (ou alguns) pacotes de software integrado que, em função dos grandes

valores investidos pelos fabricantes destes sistemas, podem ser mantidos muito mais

atuais.

De acordo com uma pesquisa do Gartner Group, até a metade de 1997, 70%

dos sistemas ERP vendidos eram adequados para o uso no ano 2000. No início de

1998, 90% dos sistemas vendidos já atendiam essa especificação (Michel, 1997b).

A idéia de um sistema único, com uma interface única, atualizado com as

últimas novidades tecnológicas e de negócios, com todos os dados da empresa

centralizados e permitindo tomada de decisão rápida, sem dúvida é um grande

atrativo para a escolha de um sistema ERP e, segundo a empresa de consultoria

Deloitte & Touche, das empresas americanas que substituíram sistemas em 1996,

70% optaram por pacotes, em detrimento dos sistemas próprios (The best stuff Bill

Gates doesn’t own, 1997).

Projetos de reengenharia de processos na empresa também são identificados

como um forte motivo para a adoção de um sistema integrado. O ERP é visto como

“o meio para reengenharia de processos, aumento da flexibilidade e tempo de


17

resposta, derrubando barreiras entre áreas funcionais e departamentos, e reduzindo a

duplicidade de esforços” (Manufacturing Systems IT Glossary, 1998).

Apesar da afirmação constante que sistemas ERP e reengenharia de

processos caminham juntos, podem ser identificadas, basicamente, duas abordagens

distintas: a escolha de um ERP para iniciar um processo de reengenharia – quando a

empresa se utiliza do pacote de software, e dos procedimentos contidos nesse, como

um elemento para motivar e produzir mudança de processos dentro da organização;

a escolha de um ERP para concluir um processo de reengenharia, quando a empresa

busca um software para se adaptar aos processos recém-alterados.

Segundo Stevens (1997), determinadas empresas optam por fazer uma

reengenharia de processos de negócios antes da implementação de um sistema ERP,

para que o “modelo desenvolvido seja um reflexo de como conduzir o próprio

negócio, e não o que é possível fazer com o software” (p.132).

As empresas que aproveitam a oportunidade da implementação de um

sistema ERP para provocar mudanças em processos acreditam que o mesmo “força

a empresa a instituir um conjunto testado de processos de negócios, ao invés de

reinventar a roda [...] pois, quando o estado-da-arte muda, a empresa muda junto”

(Weston, 1998, p.9). O sistema ERP “age como um padrão ou um mapa para a

reengenharia, ajudando a definir que tipo de informação você precisa, que necessita

dela e quando” (Lieber & Jaynes, 1995). Os defensores dessa abordagem defendem

a idéia que as soluções de reengenharia de processos produzidas dessa forma são

mais realistas e se tornam implementáveis.

Além desses, alguns outros fatores também podem ser listados como

influenciadores no processo de adoção de um ERP, tais como a busca por aumento

no desempenho dos negócios, redução de estoques, redução de prazos para

atendimento de pedidos, aumento na agilidade da empresa e outros (What’s driving

the explosive ERP market?, 1998).


18

A questão de instalar pacotes de software como um recurso de melhoria de

competitividade, ao invés de desenvolvê -los internamente não é nova, simplesmente

está sendo reutilizada em relações aos sistemas ERP. A citação a seguir, da APICS,

datada de 1979, demonstra esta preocupação há quase 20 anos, bem antes do

surgimento do conceito ERP.

Os negócios hoje estão se tornando mais e mais competitivos.

Com o custo do capital, terra, construções e estoque, para

não citar as taxas de retorno que estão atingindo níveis

recordes, você deve “sistematizar” para continuar nos

negócios... Amanhã pode ser muito tarde. Seus competidores

já começaram. [...] pacotes podem ser instalados em uma

fração do tempo tomado para se desenvolver um sistema

internamente. A instalação pode ser em qualquer lugar, de

imediato, em até um quarto do tempo de desenvolvê-lo

internamente. (Muir, 1979, p. 32-37)

A discussão entre as abordagens de desenvolvimento de sistemas de

informação “caseiros”, criados por uma equipe interna e direcionados

especificamente a um conjunto de necessidades da empresa, ou a aquisição de

pacotes de software, prontos para serem instalados e genéricos o suficiente para

atender a todas as necessidades da empresa possui defensores em ambos os lados.

Breslin (1986) cita alguns dos principais argumentos na relação entre o

desenvolvimento de software e a aquisição e pacotes.

Argumentos favoráveis à aquisição de pacotes:

• pacotes, geralmente, são tecnologicamente superiores a produtos

“caseiros” (Isto ocorre porque as empresas de software investem pesado

no desenho original e despejam recursos de P&D – Pesquisa &

Desenvolvimento – em melhorias do produto);


19

• existe, teoricamente, menos risco em implementar pacotes que já são

produtos “testados” e funcionando em diversos locais;

• eles podem, de forma conceitual, ser implementados em menor tempo

que o esforço de desenvolvimento inicial de um sistema;

• eles, logicamente, requerem menos pessoal de informática, um recurso

caro e/ou escasso.

Argumentos contrários ao desenvolvimento de pacotes:

• pacotes, por definição, são genéricos e não refletem as condições de

operações contrastantes que são encontradas nas empresas de diferentes

ou, às vezes, do mesmo tipo de indústria. Isto é um contraste para os

desenvolvimentos customizados, sistemas desenvolvidos internamente

nas empresas por funcionários que conhecem, pelo menos, até em certo

grau, a natureza dos negócios e desenhados para um conjunto específico

de requerimentos;

• quando sistemas são desenvolvidos internamente, existe alguém, algumas

vezes muitas pessoas (usualmente analistas de sistemas e programadores)

dentro da empresa, que compreendem o software. Esta é mais uma

exceção que uma regra em relação aos pacotes;

• as apresentações de vendas e (pré-vendas) marketing das companhias de

software usualmente não fornecem informação detalhada para um

julgamento verdadeiro da aplicabilidade do pacote para uma determinada

operação. É necessário considerável experiência prática (ou ferramentas

adequadas) com um sistema para compreender totalmente suas

capacidades e limitações;

• as ferramentas fornecidas para planejar e monitorar uma instalação são

limitadas e existe tremenda variação na qualidade e quantidade de

sistemas e suporte fornecidos para os usuários finais. Alguns


20

fornecedores possuem programas de treinamento nos quais faltam o que

realmente é necessário para operar o sistema efetivamente;

• a conversão de dados dos sistemas antigos ou dos arquivos manuais

raramente recebem o planejamento e atenção que merecem. Tipicamente,

os fornecedores oferecem pouca ou nenhuma orientação nesta tarefa

essencial;

• alguns fornecedores de software persistem em uma busca contínua para

fornecer cada vez mais novas características e funções em seus produtos.

Isto pode afastá-los de seus objetivos originais e resultar em sistemas

muito complexos para serem compreendidos, utilizados adequadamente

ou instalados.

IMPLEMENTAÇÃO DE PROJETOS ERP

Diversos autores afirmam que a implementação de um sistema ERP é um

projeto caro, demorado e complexo. Este aspecto é, muitas vezes, apresentado como

uma restrição aos sistemas ERP, sendo comum encontrar-se números mostrando

projetos que demoram vários anos e consomem valores superiores a US$ 20

milhões (Gestão Empresarial, 1997).

Vasilash (1997) aborda os riscos dos projetos ERP afirmando que a

implementação dos mesmos são programas de alto risco, com “investimentos

substanciais em termos de aquisição de software e equipamento, treinamento e a

quantidade de tempo gasta. E o custo do fracasso é muito mais alto que o custo do

software” (p. 64).

Também Bartholomew (1997a) afirma que a regra geral dos projetos ERP é

custar mais e demorar mais que o planejado, resultando, ainda, algumas vezes, em

resultados inferiores aos esperados. Segundo ele, estima-se que ¼ dos projetos ERP

terminem em desastre ou nunca sejam implementados, mas este fato não é


21

publicado, pois “na indústria privada ninguém quer admitir que desperdiçou US$ 40

milhões” (p. 26).

Em uma pesquisa da Forrester Research, uma empresa de pesquisa de TI –

Tecnologia da Informação – realizada com os executivos seniores de empresas que

constavam na Fortune 1000 e tinham implementado sistemas ERP, 44% dos

mesmos afirmaram que gastaram pelo menos quatro vezes mais com ajuda para

implementar o sistema – entenda-se integradores de sistemas e empresas de

consultoria – do que com a licença do software (Michel, 1997b).

Lozinsky (1996, p. 51) afirma que o custo com serviços de implementação

começa com US$ 1,50 e chega a US$ 3,00 para cada US$ 1,00 investido no

produto. Outros afirmam que a relação entre os custos chega até a relação 1:1:5,

software : hardware : consultoria (Stevens, 1996, p. 37). Isso ocorre,

principalmente, se a implementação não seguir o modelo básico proposto pelo

software e iniciarem-se processos de alteração nos conceitos do sistema, quando

então os custos terão um aumento significativo.

O fator tempo do projeto é um dos principais problemas envolvidos, pois

quanto mais o mesmo demora, se não existir um controle extremamente rígido, mais

ele se distancia dos objetivos originais e maior o risco de especificações já

realizadas e formalizadas mudarem. Além disso, existe a perspectiva de ser

apanhado no meio da implementação pela liberação de uma nova versão de

software por parte do fornecedor, o que pode exigir, entre outros, revisões de

processos e novos treinamentos. Currier (1997) afirma que “o risco de fracasso em

um projeto aumenta significativamente na proporção do tempo gasto para completá-

lo” (p. 38).

Alguns fatores adicionais ainda podem aumentar o tempo de projeto

substancialmente, como no caso de técnicas e métodos que não são de uso corrente

na organização no momento e serão implementados juntamente com o projeto,

como exemplo, MRP II ou método de custos ABC. Ang et al. (1995, p.64) afirmam

que, no caso de sistemas MRP II, a curva de aprendizado é de 24 meses.


22

Os principais fornecedores de ERP costumam não concordar que as

implementações são muito demoradas, mas vêm realizando esforços para tornar o

processo de implementação cada vez mais rápido e simples, principalmente

fornecendo ferramentas de modelagem, métodos de implementação padronizados e

conjuntos pré-configurados com “melhores práticas de negócios” – ou seja,

procedimentos definidos de como empresas de um determinado setor devem,

teoricamente, operar.

Alguns ERP já oferecem ferramentas de modelagem que auxiliam os

usuários a definir processos de negócios e configurar o software para suportar esses

processos. Essas ferramentas ajudam a aumentar a velocidade na implementação –

reduzindo custos – e também a reconfigurar o sistema quando uma mudança é

necessária.

Como exemplo dessas medidas de aceleração do processo de implementação,

a SAP – líder do mercado de ERP – lançou um programa no qual a própria SAP ou

seus parceiros participam da implementação de uma versão padronizada do seu

produto SAP R/3 chamada Accelerated SAP, ou ASAP. Juntamente com o ASAP,

ainda são fornecidas ferramentas, modelos prontos e exemplos das “melhores

práticas”, visando a acelerar o processo e fornecer, no mínimo, a garantia de uma

implementação com sucesso. Segundo informações da própria empresa, 61% das

últimas implementações do SAP R/3 levaram menos de um ano (Tebbe, 1997, p.

108).

Já a Baan, também uma das líderes do mercado de software ERP, lançou

juntamente com a versão Baan IV do seu ERP, a ferramenta Orgware para a

chamada Modelagem Dinâmica de Negócios, que objetiva reduzir os tempos de

implementação, concentrando a atenção dos implementadores nos processos de

negócios e também fornecendo as “melhores práticas”. A empresa cita casos de

projetos concluídos em dois meses e meio, e.g., Bell Canada (Vasilash, 1996, p.44).

Também as consultorias envolvidas nos processos de implementação buscam

fornecer recursos para agilizar o processo de implementação. A KPMG Peat


23

Marwick desenvolveu ferramentas e uma metodologia própria para acelerar os

projetos em Oracle Applications, chamada Rapid Return on Investment (R2I), que

se utiliza de modelos e exemplos (Better bang for the buck, 1997, p. 82).

Apesar de fornecedores de ERP e consultorias produzirem constantes

melhorias nos processos de implementação, seja pela adição de novas ferramentas

ou metodologias, e ainda apresentarem vários casos de implementações bem

sucedidas em tempo reduzido, parece haver consenso na literatura existente e entre

os participantes deste mercado, que os projetos de implementação de sistemas ERP

são demorados e caros.

Além disso, ainda existe o fato de que, a cada nova versão, os ERP se tornam

maiores e mais complexos, pois passam a incorporar novas funcionalidades

inexistentes em versões anteriores. Isso leva a uma situação em que os fabricantes

são pressionados a adicionar funcionalidades em seus sistemas – tem sido comum o

fato dos grandes fornecedores adquirirem pequenas empresas de software para

incorporar esses produtos aos seus sistemas ERP – que os tornam maiores e de mais

difícil implementação e, ao mesmo tempo, são pressionados a fornecer mecanismos

que tornem a implementação mais simples e rápida.

Apesar de todos os esforços para reduzir os riscos, problemas continuam a

ocorrer na implementação de projetos ERP. O caso mais recente envolve o líder do

mercado ERP, a SAP, e a FoxMeyer, uma companhia de distribuição de

medicamentos com vendas anuais de US$ 5 bilhões, que declarou falência e cujo

síndico iniciou ação judicial contra o fornecedor de software, no valor de US$ 500

milhões, que corresponderia a um contrato perdido pela FoxMeyer como

conseqüência da não implantação do SAP R/3. Segundo ele, o software foi incapaz

de lidar com o volume de pedidos da empresa, o que obrigou a empresa a voltar

para seu antigo sistema Unisys ( Bankruptcy trustee sues SAP AG, 1998).


24

ESTRATÉGIAS DE IMPLEMENTAÇÃO

Muitos dos problemas e riscos aos quais os projetos ERP estão sujeitos,

dependem em grande parte das estratégias adotadas em relação aos mesmos. O

gerenciamento de um projeto ERP pode assumir diversas formas, dependendo das

diretrizes de sua gestão, suas missões e dos responsáveis pelo mesmo.

A literatura e contatos mantidos com consultores envolvidos em projetos

ERP sugeriram a presença básica de algumas estratégias bastante distintas em pelo

menos dois aspectos principais: a forma da conversão do sistema no momento de

sua colocação em produção (a colocação do sistema “no ar” ou “virada”) e a

utilização de atividades de reengenharia de processos de negócios.

Na relação entre reengenharia e projeto ERP, diversas abordagens podem ser

observadas. Muitas vezes, como já citado anteriormente, um projeto de

reengenharia pode ser o motivo para a aquisição de um sistema ERP, sendo este a

conclusão de atividades de melhoria de processos; outras vezes, o processo de

reengenharia pode caminhar junto com a implantação do sistema, sendo os

processos analisados e mudados à medida que o projeto ERP atinge cada área

funcional; também pode existir a opção pela implantação do pacote sem promover

atividades significativas de mudança de processos. Nesse caso, as mesmas podem

ou não vir após o término da implantação. O item ”Mudanças na Organização”, a

ser apresentado no decorrer deste capítulo, discutirá melhor esse assunto.

Existem algumas opções distintas para o momento da implantação (ou

conversão) de um sistema ERP – o instante em que o sistema já está em condições

de passar a operar e sustentar a operação da empresa. A discussão das mesmas é

particularmente significativa em ambientes onde já existam sistemas, que serão

substituídos, total ou parcialmente, pelo pacote ERP. A seguir alguns dos métodos

existentes:

• conversão direta, conversão única ou big bang;


25

• conversão em fases, conversão parcial;

• conversão em paralelo;

• conversão em paralelo com piloto;

• conversão em paralelo limitado;

• conversão em paralelo retroativo;

A conversão direta, ou big bang, é reconhecida como o método mais

arriscado e mais rápido. Consiste, grosso modo, em desativar os sistemas antigos

em um momento, converter os dados necessários para o novo sistema e passar a

utilizá-lo, abandonando definitivamente os sistemas antigos.

Os riscos inerentes a esse processo são vários, mas os principais residem no

fato de que o sistema foi configurado, suas centenas de tabelas interdependentes

parametrizadas e testadas, mas é praticamente impossível que todas as situações que

ocorrem no dia-a-dia da empresa tenham sido previstas, sendo inevitável que erros

ou problemas venham a ocorrer. Também é comum que surjam erros em módulos

que funcionavam corretamente sozinhos, mas passam a apresentar problemas

quando todo o sistema está interligado (Piszczalski, 1997; Radosevich, 1997).

Também é extremamente difícil que os usuários consigam – apesar da

quantidade de treinamento recebida – abandonar um sistema em um instante e obter

desempenho satisfatório no novo sistema no instante seguinte. Levando em conta

que a empresa dependa do sistema para sua sobrevivência, os riscos existentes são

consideráveis (Lozinsky, 1996).

Seus principais benefícios residem em não haver necessidade de se produzir

interfaces de software e, muitas vezes, ser a única opção possível. Radosevich

(1997) cita o caso da Quantum, um fabricante de discos para computadores com

faturamento de US$ 4,4 bilhões que adquiriu um outro grande fabricante. Os

sistemas de ambos eram ultrapassados e incompatíveis entre si, e a empresa tinha


26

uma grande urgência que suas duas operações ao redor do mundo passassem a

funcionar como uma só, o que certamente minimizou os riscos e os custos da

companhia parada por uma semana sem poder fazer qualquer negócio, como

resultado de uma implantação do tipo big bang.

A alternativa da conversão em fases, ou parcial, resume-se na colocação do

sistema por módulos (ou partes), um por vez. Isso normalmente implica o

desenvolvimento de uma grande quantidade de software para atuar como interface

entre os sistemas atuais e o módulo que está sendo implantado. Essas interfaces

importam e exportam dados entre os sistemas, permitindo que a empresa trabalhe

com os sistemas antigos e os novos módulos ao mesmo tempo. À medida que mais

módulos vão “ao ar”, as interfaces são descartadas, até que todo o pacote esteja em

funcionamento e as mesmas não sejam mais necessárias. Este método é considerado

seguro, porém as interfaces entre pacotes ERP e outros sistemas são condenadas por

muitos autores, seja por exigirem custos de desenvolvimento e serem

posteriormente descartadas, ou seja, por serem um fonte de erros (Freeman, 1997;

Kock, 1997; Radosevich, 1997; Stevens, 1996).

As conversões em paralelo seguem todas uma idéia geral, que consiste no

funcionamento dos sistemas antigos ao mesmo tempo que o pacote ERP, com a

constante comparação dos resultados obtidos, até que os mesmos sejam iguais e não

haja mais problemas com o novo pacote. Nesse momento, os sistemas antigos

podem ser desligados, passando o pacote ERP a ser o sistema oficial da empresa.

Esse método é bastante seguro, pois a empresa somente passa para o novo

sistema com a segurança do seu funcionamento, mas exige um esforço muito

grande, pois todas as operações devem ser feitas nos dois sistemas, para que os

resultados possam ser conferidos. Isto implica, no mínimo, o dobro do trabalho por

parte do usuários, havendo ainda, muitas vezes, questões tecnológicas envolvidas,

tais como usar um terminal de um determinado equipamento para o sistema antigo e

um microcomputador para o novo sistema (Lozinsky, 1996).


27

Os métodos, em paralelo, com piloto, limitado e retroativo são citados por

Lozinsky (1996, p. 198) como variações do método anterior. A conversão em

paralelo com piloto consiste no método paralelo feito somente em uma unidade de

negócios – em uma parte pequena da empresa. Quando o piloto funcionar, ele deve

ser replicado para as demais unidades. O método paralelo limitado, por sua vez, não

exige que todas as operações sejam feitas nos dois sistemas, podendo ser feitas no

novo sistema, por exemplo, por amostragem. O que importa é que a amostra reflita

todos os casos possíveis e que ocorrem no sistema antigo. No método paralelo

retroativo, pode haver um lapso, por exemplo, de alguns dias, entre as operações

nos dois sistemas. O que importa é que o resultados sejam os mesmos.

Seja qual for a estratégia de conversão escolhida, ela deve ser o resultado de

uma análise cuidadosa dos diversos fatores envolvidos. Devem ser consideradas as

necessidades e objetivos da empresa em relação ao projeto, os seus recursos

disponíveis – tempo, dinheiro, pessoal, consultoria – para a execução, além de

outros fatores como o envolvimento e participação dos usuários e da equipe de

projeto.

ADMINISTRAÇÃO DE PROJETOS

O Guide To The Project Management Body Of Knowledge (Project

Management Institute, 1996) define projeto como sendo “um esforço temporário

desenvolvido para criar um produto ou serviço único” (p. 4). Turner apud Chapman

& Ward (1997) por sua vez, define um projeto da seguinte forma:

“Um esforço no qual recursos humanos, materiais e

financeiros são organizados na forma de uma novela, para

empreender um escopo único de trabalho para uma dada

especificação, com restrições de custo e tempo, assim como

para atingir uma mudança única e benéfica, através do

cumprimento de objetivos em quantidade e qualidade.” (p. 3)


28

Tais definições mostram, entre outras coisas, o aspecto temporalidade de um

projeto, que significa que todo projeto possui um início e término definidos – não

importando se o mesmo será longo ou curto – seja quando o seu objetivo é atingido

e o projeto encerrado, ou quando o mesmo é encerrado pela simples constatação de

que seu objetivo não será atingido.

Um projeto também é único em função de suas características, mesmo que

muitos outros semelhantes já tenham sido elaborados. Diferentes momentos,

interessados, locais, equipe, entre outros fatores tornam projetos únicos. O mesmo

software pode ser implementado várias vezes, mas sempre serão diferentes

empresas, necessidades e envolvidos.

Já o gerenciamento do projeto é definido pelo Guide To The Project

Management Body Of Knowledge (Project Management Institute, 1996) como “a

aplicação de conhecimento, habilidades, ferramentas, e técnicas às atividades do

projeto com o objetivo de atender ou superar as necessidades e expectativas dos

participantes em relação ao projeto” (p.6).

Navarre & Schaan (1990) afirmam que a administração de projetos refere-se

aos métodos e técnicas criadas para a concepção, análise, e implementação dos

esforços de trabalhos temporários, altamente irreversíveis e não repetitivos, com

restrição de tempo e recursos escassos e limitados.

A administração de projetos tem múltiplos aspectos. Podem ser estudadas as

abordagens de ciclo de vida de projeto, planejamento de projetos, acompanhamento

e controle de projetos, alternativas organizacionais para projetos, papéis e

responsabilidades do gerente de projetos, desenvolvimento de equipes de projeto,

implantação e avaliação ex-post de projetos.

De acordo com Kruglianskas (1993), todo projeto apresenta um ciclo de vida

que pode ser decomposto em seis fases: (a) pré-concepção, quando se procura

identificar e analisar o problema e procurar alternativas de solução, (b) concepção,

onde se estabelecem etapas, prazos e custos, (c) estruturação, decomposição das


29

etapas em atividades, (d) execução das etapas, (e) transferência dos resultados e (f)

avaliação dos resultados obtidos. Essas fases também podem ser resumidas em três:

concepção, execução e encerramento.

Adams & Barndt (1988) dividem o ciclo de vida nas fases de conceituação,

planejamento, execução e encerramento. Eles consideram que cada fase difere da

outra em termos do nível de recursos, do grau de definição, do nível de conflito, da

taxa e gastos.

Uma boa administração integra essas atividades de forma coerente para guiar

uma proposta de desenvolvimento de um novo produto ou processo de produção de

sua fase conceitual (concepção) até seu encerramento bem sucedido, ou seja,

quando ocorre a efetiva transferência da tecnologia desenvolvida no projeto para a

produção e os objetivos são considerados atingidos.

A divisão, em diversas fases, fornece melhor acompanhamento e controle

das mesmas e, conseqüentemente, do projeto como um todo. Cada fase deve possuir

uma descrição detalhada de seu início, objetivos, término, definição de quais

atividades devem ser desenvolvidas no decorrer da mesma e quem deve estar

envolvido. A Figura 4 mostra um exemplo de um ciclo de vida de um projeto

genérico.

Figura 4: Exemplo de um ciclo de vida genérico, em relação ao custo do projeto

Fonte: Project Management Institute, 1996.

A Figura 5, por sua vez, mostra o modelo de Morris para o ciclo de vida de

projetos de construções, em relação ao percentual de execução do mesmo. Ele


30

divide o projeto em quatro fases: Viabilidade, Planejamento e Desenho, Produção,

Mudança e Operação.

Figura 5: Ciclo de vida de projeto de Morris, em relação à execução do projeto

Fonte: Project Management Institute, 1996.

O gerenciamento de projetos é considerado uma atividade crítica nos

mesmos e diretamente responsável pelo sucesso ou fracasso do projeto. O

gerenciamento de projetos de Sistemas de Informação é apontado, segundo dados

do Gartner Group, como “pior do que horrível”, pois produz perdas aproximadas

que ultrapassam US$ 100 bilhões anualmente. Falta de planejamento e

gerenciamento pobre do projeto são apontadas como as principais razões para

estouro de 1/3 dos orçamentos de projetos de software, com perdas anuais de US$

80 bilhões. Já os dados do Meta Group afirmam que um de cada 2 projetos

ultrapassa mais de 180% acima do orçamento e produz mais de US$ 59 bilhões de

perdas (King, 1997, p. 6).

O acompanhamento e controle de cada fase e atividade do projeto exige um

gerente de projeto com diversas habilidades. Este é um assunto bastante amplo, mas


31

algumas das habilidades são apresentadas como essenciais pelo Guide To The

Project Management Body Of Knowledge (Project Management Institute, 1996, p.

20), conforme abaixo listado:

• liderança: estabelecer direcionamentos, alinhar as pessoas, motivar e

inspirar os membros da equipe de projeto;

• comunicação: promover a troca de informações claras, não ambíguas e

completas, interna e externamente ao projeto;

• negociação: negociar durante toda a duração do projeto, em relação aos

diversos aspectos, principalmente mudanças de escopo, custo, duração,

contratos, recursos e fornecedores;

• solução de problemas: em relação aos problemas já ocorridos, identificar

sintomas e causas, definir o problema, que pode ser interno ou externo,

analisar as alternativas viáveis e promover tomada de decisão para

solucioná-lo;

• influenciar a organização: compreender as estruturas formais e informais

da organização e dos envolvi dos, tais como fornecedores, consultores e

outros, com o objetivo de “fazer as coisas acontecerem”. Isso,

normalmente, requer uma compreensão dos mecanismos de poder e

políticas envolvidos.

FATORES CRÍTICOS DE SUCESSO

Segundo Kwon & Zmud (1987), dentre as diversas abordagens existentes

para tentar garantir o sucesso de um projeto, está a abordagem dos Fatores Críticos

de Sucesso, a qual determina que a presença de um certo grupo de fatores,

considerados críticos, possui grande influência no projeto e aumenta as chances de

sucesso deste.


32

Os chamados Fatores Críticos de Sucesso não são exclusivos da área de

administração de projetos, sendo usados, por exemplo, na área de Sistemas de

Informações para Executivos (EIS – Executive Information Systems), quando são

definidos fatores que são considerados críticos e vitais para o sucesso do negócio e

que devem ter seus resultados monitorados em relação a padrões previamente

estabelecidos. (Rockart & De Long, 1988, p. 203; McLeod, 1995, p. 521; Martin,

1990, p. 87)

A definição do Centro de Pesquisas em Sistemas de Informação do MIT

(CISR) para Fatores Críticos de Sucesso, segundo Martin (1990) é a seguinte:

Fatores Críticos de Sucesso são o número limitado de áreas

nas quais resultados satisfatórios garantirão desempenho

competitivo para o indivíduo, departamento ou organização.

Fatores Críticos de Sucesso são as poucas áreas chave onde

"as coisas têm que dar certo" para que os negócios

prosperem e as metas de gerência sejam atingidas. (p. 89)

Slevin & Pinto (1986) apresentam um conjunto de 10 fatores, considerados

pelos mesmos como críticos para o sucesso no gerenciamento e implementação de

projetos genéricos, e apresentados a seguir:

• missão do projeto;

• apoio da alta administração;

• plano e cronograma do projeto;

• consulta aos clientes;

• pessoal;

• atividades técnicas;

• aceitação do cliente;


33

• monitoração e feedback;

• comunicação;

• crises e desvios.

A abordagem dos fatores críticos de sucesso também está presente em

diversos trabalhos sobre projetos de reengenharia de processos de negócios. Grover

et al. (1995) apresentam essa idéia, particularmente para projetos de BPR –

Business Process Reengineering, ou reengenharia de processos de negócios – como

fatores de fracasso de projetos, ou seja, fatores cuja ausência (ou presença em níveis

insuficientes) diminui as chances de sucesso de um determinado projeto. Os fatores

apresentados por Grover et al. (1995) são os seguintes:

• gerenciamento da mudança;

• competência tecnológica;

• planejamento estratégico;

• estrutura de tempo;

• apoio da administração;

• recursos humanos;

• delineamento do processo;

• gerenciamento do projeto;

• planejamento tático.

Diversos outros autores também já propuseram fatores considerados pelos

mesmos como críticos para projetos de BPR. Larsen & Myers (1997) citam os

fatores apresentados por Hammer & Champy (1993) e Robb (1995):

• apoio da alta administração;


34

• um líder de projeto respeitado e comprometido;

• objetivos bem estabelecidos, com metas agressivas;

• uma equipe de projeto formada por um composto de funcionários e

consultores;

• os melhores funcionários da empresa em cada área funcional;

• uma estratégia de comunicação e gerenciamento de mudanças bem

planejados;

• uma metodologia efetiva.

Todavia, a existência de um conjunto de fatores que por si só determinem o

sucesso ou fracasso de um projeto não é aceita com total consenso. Uma das razões

é o fato de um projeto não ser estático e, portanto, possuir diferentes “necessidades”

em diferentes níveis, durante seu desenrolar.

Pinto & Slevin (1988b) também desenvolveram um estudo sobre fatores

críticos de sucesso em relação à dinâmica de projetos, em que concluíram que não

basta a presença de um conjunto de fatores no início do projeto, pois os mesmos

demonstram intensidade variável de acordo com a fase do ciclo de vida na qual o

projeto se encontra. Isso não deixa de caracterizar a importância da presença de

fatores críticos para o sucesso de um projeto, mas mostra que a implementação não

é um processo estático e sim dinâmico, onde diversos fatores possuem diferentes

níveis de importância nas várias fases do projeto.

Outros autores também afirmam que os fatores não podem ser isolados de

maneira separada e tratados como variáveis independentes entre si, pois os mesmos

possuem relacionamentos (Ginzberg, 1981; Lucas, 1981).

A literatura existente em projetos ERP não aborda o assunto dos fatores

críticos de sucesso de maneira específica, mas podem ser encontradas várias

referências sobre o mesmo. São comuns as citações de pré-requisitos e condições


35

necessárias para o sucesso de projetos ERP. Os mais citados desses pré-requisitos

são o apoio e comprometimento da alta administração, objetivos claros e definidos,

usuários capacitados e disponíveis, existência dos recursos necessários, mudança

nos processos de negócios, presença de uma consultoria externa, e outros

(Bartholomew, 1997c; King, 1997; Lozinsky, 1996; Radosevich, 1997; Stevens,

1997; Vasilash, 1996).

Bancroft et al. (1998), por sua vez, citam 9 fatores que consideram como

críticos para implementação de sistemas complexos, em particular sistemas ERP:

1. compreender a cultura da empresa;

2. iniciar a mudança dos processos de negócios antes da implementação;

3. manter uma comunicação constante, mas não em termos técnicos;

4. garantir um forte apoio dos executivos para o projeto;

5. possuir um gerente de projeto que possa negociar em todos os níveis;

6. escolher uma equipe de projeto balanceada (entre a área de sistemas e as

áreas de negócios);

7. escolher uma boa metodologia de projeto;

8. treinar os usuários e garantir apoio para mudanças de cargos;

9. esperar que problemas surjam.

ALINHAMENTO

Um dos fatores que podem ser considerados importantes para o sucesso de

um projeto ERP é o correto alinhamento entre os objetivos da organização e o que

será atingido após a implantação do sistema.


36

Bartholomew (1997c, p.144), aponta os resultados de uma pesquisa sobre

aspectos críticos no gerenciamento de sistemas de informação, realizada com mais

de 300 CIOs – Chief Information Officer – onde mais de 80% afirmaram ser o

alinhamento dos sistemas de informação com os objetivos da organização sua

principal preocupação (mais de uma alternativa era permitida).

Stevens (1997) também identifica como razões de fracasso em projetos ERP

a falta de uma liderança e de uma direção única por parte da organização em relação

ao projeto ERP (p. 132). Lozinsky (1996) cita como imprescindível ao projeto que a

alta administração possua entendimento do processo, comprometimento com o

mesmo e visão (p. 26). Pinto & Slevin (1988b), por sua vez, em relação a projetos

em geral consideram o apoio da alta administração como um dos principais fatores

críticos de sucesso (p. 67).

Outro fator considerado importante, em relação ao alinhamento de objetivos,

é o projeto ser visto como de toda a organização, como um objetivo comum da

mesma, e não como de interesse exclusivo de alguma área específica, tal como

finanças, manufatura ou sistemas (Vasilash, 1996, p. 65; Stevens, 1997, p. 132).

Isso é particularmente importante porque, muitas vezes, a implementação, e até o

uso do novo sistema, vão exigir sacrifícios maiores – muitas vezes não esperados –

de alguma área em específico, para obtenção dos benefícios desejados.

Gerenciar as expectativas em relação aos objetivos é uma medida de cautela

no projeto, pois, muitas vezes, o ERP não faz algumas coisas tão bem como elas

podem ser feitas hoje, mas o “principal motivo da implementação do ERP é a

integração e a visibilidade, além de outros possíveis benefícios, o que exige uma

negociação quanto às suas funcionalidades” (Stevens, 1996, p. 40).

Em relação às expectativas, também as da organização devem estar coerentes

com o que pode ser obtido do novo sistema. Muitas vezes, os executivos podem

possuir expectativas exageradas e irreais em relação aos benefícios a serem obtidos

após a implantação do sistema, não contando com a possibilidade dos resultados


37

serem muito inferiores com as promessas dos vendedores de software e consultores

(Bartholomew, 1997a, p. 26).

Em relação aos objetivos, Lozinsky (1996) cita o fato de executivos que não

participam do processo de decisão e escolha do pacote possuírem expectativas

distorcidas e não condizentes com o escopo do projeto, o que pode trazer problemas

durante sua implementação (p. 105).

ENVOLVIDOS NA IMPLEMENTAÇÃO DO PROJETO

Diversas autores apresentam a necessidade de um patrocinador forte – um

alto executivo – na condução de projetos ERP, como um dos requisitos para garantir

seu sucesso. O patrocinador deve estar convencido dos benefícios e da importância

do projeto e apoiar a equipe de projeto, principalmente nos casos de resistência de

outras áreas da organização. Ele deve ainda estar inteirado da situação e do

andamento do projeto e participar do comitê executivo de projeto.

Vasilash (1997, p. 64), entre as razões que apresenta para o fracasso em

implementações de projetos ERP, coloca, em primeiro lugar, a falta de um

executivo patrocinador. Bartholomew (1997b) também afirma que “não importa se

é uma fábrica de $35 milhões ou uma corporação multinacional de $35 bilhões, é o

CEO – Chief Executive Officer – quem precisa patrocinar o projeto” (p.123).

Além disso, é importante que, além do patrocinador, toda a alta

administração esteja envolvida no processo durante e depois da implementação do

sistema para garantir seu sucesso. De acordo com Stevens (1996, p. 40), “a primeira

coisa a se ter certeza é que a alta administração em todas as unidades está 100% por

trás e visivelmente apoiando o projeto”. Em uma pesquisa com 300 gerentes de

projeto, sobre as razões de falhas no gerenciamento desses, 22% identificaram “falta

de apoio da alta administração” como a principal (King, 1997, p. 6).


38

Uma das principais responsabilidades do patrocinador do projeto é a

formação de uma equipe de projeto competente para desenvolver o projeto. Apesar

de muitos participantes da mesma possivelmente terem origem na empresa de

consultoria que pode auxiliar a implementação, ou no fornecedor de software, a

escolha dos membros da empresa que participarão da equipe, assim como do

gerente do projeto (coordenador interno), são vitais para o seu sucesso.

A equipe que participa do projeto ERP normalmente pode assumir diversas

configurações, dependendo do seu porte e características, distribuição geográfica,

módulos a serem implementados, participação da consultoria e do fornecedor, além

de outros fatores particulares de cada projeto.

Lozinsky (1996) apresenta uma estrutura da equipe de projeto, conforme

mostrado na Figura 6. Porém, é importante destacar que esta é somente uma das

abordagens possíveis, e não um modelo definido de equipe de projeto.

Gerênciado

Projeto

ComitêExecutivo

UsuáriosChaves Analistas

Equipede

Trabalho

SuporteTecnológico

SuporteAdministrativo

Figura 6: Modelo de equipe de projeto

Fonte: Lozinsky, 1996, p. 88

Com base no modelo apresentado anteriormente, o Quadro 2 mostra os

diversos participantes desse modelo, sua origem e atribuições.


39

Participante Origem / Composição Atribuições

Comitê

Executivo

Formado por representantes da Alta

Administração da empresa (Diretores, o

próprio Presidente da empresa, e outras

pessoas com poder de decisão), o

responsável geral pelos trabalhos da

consultoria contratada e, eventualmente,

alguém do nível executivo do fornecedor

do pacote de software adquirido.

• Avalia andamento do projeto.

• Aprova resultados intermediários e finais.

• Provê recursos necessários.

• Toma decis ões em questões que afetam o

escopo definido.

• Negocia honorários ou custos de serviços

dos consultores ou do fornecedor do pacote.

Gerência do

Projeto

Formada pelo profissional da consultoria

que lidera os trabalhos “em campo” e pelo

representante da empresa – coordenador

interno.

• Responsável pela condução dos trabalhos

programados.

• Administra os recursos de: pessoal,

cronograma, custos, despesas.

• Responsável pela comunicação entre as

áreas do projeto.

• Presta contas ao comitê executivo.

Equipe de

trabalho

Formada pelos consultores contratados,

com experiência no pacote em

implementação. Normalmente, existem

profissionais diferentes para cada

funcionalidade do pacote.

• Levanta informações com os usuários.

• Modela e configura o pacote de acordo com

as necessidades da empresa.

• Acompanha o projeto até o final.

Usuários-

Chave

Formado por um grupo de usuários de

diversas áreas. Indivíduo com autonomia,

liderança, conhecimento técnico, respeito

dos demais usuários e formador de

opinião.

• Define como o sistema vai funcionar em

todos os detalhes.

• Discute e participa da modelagem de

processos.

• Testa o software.

• Treina os demais usuários de sua área.

Analistas Profissionais da área de informática com

conhecimento dos sistemas atuais e dos

processos de negócio da empresa.

• Desenvolve os programas de carga de dados

e interface.

• Acompanha todo o projeto para adquirir

conhecimento sobre o funcionamento do

novo sistema.

Suporte

Tecnológico

Profissionais da área de informática com

conhecimento das redes, bancos de dados

e sistemas operacionais em uso na

empresa, assim como da parte de

configuração do pacote a ser instalado.

• Instala os softwares necessários.

• Dá suporte às redes, bancos de dados,

acessos e autorizações.

• Monitora e ajusta performance.

Quadro 2: Diferentes participantes de projetos ERP

Fonte: Adaptado de Lozinsky (1996, p. 88-98)


40

Apesar dos diversos tipos de envolvidos, com missões aparentemente claras

e definidas, é importante ressaltar que apenas a execução satisfatória de seus papéis

pode não levar ao resultado esperado e ao conseqüente sucesso no projeto. Markus

& Benjamin (1998, p. 485) observam que muitas vezes projetos de TI falham seja

pela não execução correta das atribuições por parte dos envolvidos, ou seja pela

crença, por parte destes, que a execução foi correta, mas se observa que o resultado

desejado não foi atingido.

Apesar da importância de todos os componentes da equipe de projeto, um

dos pontos mais importantes na formação de uma equipe para a implementação de

um sistema ERP é a escolha dos usuários-chave – também chamados superusuários

ou usuários-líderes – e sua correta utilização no decorrer do projeto.

Esses usuários devem representar as diversas áreas de empresa envolvidas ou

afetadas pelo projeto, sendo responsáveis pela modelagem dos processos de negócio

da empresa e sua correta adequação ao software, ou vice-versa – adequação do

software ao processos de negócio da empresa.

Segundo Bettini (1996), a estratégia mais importante do projeto é o completo

envolvimento da empresa toda, representada por seus usuários-chave, desde o início

do projeto, para criar um senso de propriedade em relação ao novo sistema,

extremamente importante durante e depois da implementação, quando o mesmo

estiver em uso.

Em relação aos usuários-chave, há concordância na literatura em relação às

suas características. A primeira, é que os mesmos deverão estar alocados em tempo

integral ao projeto, abandonando suas atividades originais enquanto durar a

implementação do sistema (Lozinsky, 1996, p. 84; Stevens, 1996, p. 40;

Radosevich, 1997).

O que pode ocorrer, dependendo do plano de implementação e do

cronograma utilizados, é que um determinado usuário-chave tenha uma participação


41

mais importante em determinada fase do projeto, com exigência de dedicação em

tempo integral, e menor em outra, quando o mesmo pode participar em tempo

parcial.

A segunda é em relação ao treinamento dos mesmos, que deve ser tratado de

maneira bastante séria. Uma pesquisa da empresa de consultoria Deloitte & Touche

mostrou que 58% dos executivos de indústrias acreditam que os projetos ERP

fracassam por falta de treinamento (Bartholomew, 1997b, p. 122). Segundo Parsons

(1997), “o treinamento é essencial. Usuários que podem ser ótimos em suas

atividades, mas desconfiados em relação à tecnologia, precisam compreender como

obter o que eles querem extrair [do ERP]” (p. 19). Também, segundo Radosevich

(1997), “os gerentes não devem ser autorizados a retirar funcionários dos

treinamentos, não importando o tipo de problema que venha a surgir.”

O gráfico na Figura 7 mostra a previsão da evolução dos gastos realizados

com treinamento em sistemas ERP.

Figura 7: Previsão de gastos com treinamento em software ERP

Fonte: Marion, 1998.

Lozinsky (1996) considera que a escolha dos usuários-chave possui um

critério simples, pois devem ser escolhidos “os melhores profissionais que tivermos

[...] As pessoas nas quais queremos investir e criar oportunidades para a evolução

de suas carreiras na empresa” (p. 85).


42

Algumas consultorias se utilizam de check-lists, com características

desejáveis para recomendar a seleção dos usuários-chave, como o mostrado abaixo:

• conhecimento dos processos de negócio da empresa;

• conhecimento detalhado de sua área;

• representante legítimo de sua área;

• possuir o respeito dos companheiros;

• capacidade de influenciar;

• formador de opinião;

• ter autonomia ou acesso fácil à tomada de decisão;

• iniciativa própria;

• não se esquivar de responsabilidades;

• facilidade de comunicação e expressão;

• capacidade de abstração;

• entender modelos de simulação;

• desapego aos sistemas e processos antigos;

• aberto a mudanças;

• enxergar oportunidades;

• disponibilidade e interesse em praticar e testar modelos.

Observando os critérios acima, parece claro que a empresa, durante a

implementação do projeto, deverá abrir mão de seus melhores recursos, aqueles que

farão falta nas atividades do dia-a-dia, e não daqueles que estão disponíveis. Isto


43

nem sempre é fácil de ser conseguido e deve ser cuidadosamente negociado pelo

patrocinador do projeto.

Já em relação ao número de usuários-chave a ser utilizado na equipe do

projeto, não parecer existir qualquer regra formal para o mesmo. Lozinsky (1996, p.

87) sugere que para cada um dos “grandes processos” – e.g., Planejamento da

Produção, Suprimentos, Vendas, Distribuição, Contabilidade – haja pelo menos um

usuário-chave alocado.

Dependendo do tamanho, alguns projetos chegam a formar equipes de

usuários com centenas de pessoas, extraídas de suas áreas funcionais e alocadas em

tempo integral ao projeto, durante toda a duração de seu envolvimento com o

mesmo (Radosevich, 1997).

Contatos mantidos com consultores que atuam em projetos ERP também

mostraram que em projetos com várias plantas ou unidades, alocar representantes

dessas unidades para o projeto – mesmo que haja uma unidade para funcionar como

piloto – pode ser muito útil, pois um mesmo processo de negócio pode ser

executado de maneira totalmente diversa em locais diferentes. É importante que o

grupo formado possua pleno conhecimento de toda a operação da empresa,

abrangida pelo projeto ou afetada por ele. Outro motivo é criar o senso de

propriedade em todos os envolvidos, nas diversas áreas e unidades da organização.

MUDANÇAS NA ORGANIZAÇÃO

BPR – BUSINESS PROCESS REENGINEERING

BPR – Business Process Reengineering – reengenharia de processos de

negócios, redesenho de processos de negócios, melhoria de processos de negócios,

ou simplesmente reengenharia, segundo Sethi & King (1998, p. 3), é “o redesenho e


44

reorganização das atividades de negócios que resultam do questionamento do status

quo [...] e é freqüentemente associada com significativas mudanças culturais e

tecnológicas.” A definição de Hammer & Champy (1993) é a seguinte:

“O repensar fundamental e desenho radical dos processos de

negócio para atingir melhoria dramática em medidas de

desempenho atualmente críticas, tais como qualidade,

serviço e velocidade.” (p. 2)

Um processo de negócios pode ser definido como um conjunto de atividades

caracterizadas por entradas específicas e tarefas que adicionam valor e produzem

saídas específicas, focadas no cliente. Processos de negócios consistem de fluxos de

trabalho horizontais, que passam através de vários departamentos ou funções (Sethi

& King, 1998, p. 4).

A mudança – elemento natural em um projeto que envolve reengenharia – é

um processo difícil, seja em transformação organizacional, seja como uma mudança

pessoal. Por esse motivo, muitas vezes buscam-se todo o tipo de alternativas para

amenizar essas dificuldades. Markus & Benjamin (1998, p. 486) citam a idéia da

“bala mágica” da TI – tecnologia da informação como uma dessas alternativas.

“Balas mágicas” seriam tecnologias e metodologias as quais as pessoas acreditam

que podem fazer coisas notáveis com pouca ou nenhuma intervenção humana.

De acordo com a idéia da “bala mágica”, a “TI muda pessoas e organizações

dando-lhes poder (empowering) para realizar coisas que elas nunca realizaram antes

e prevenindo-as de trabalhar de modos antigos e improdutivos. Eu sou o agente de

mudança porque eu inicio, desenho, ou construo uma tecnologia poderosa. Quando

as pessoas usam meus sistemas, resulta a mudança organizacional desejada”

(Markus & Benjamin, 1998, p. 486).

Observe-se que a TI (neste contexto, um sistema ERP) não tem o poder, por

si só, de provocar mudanças na organização ou obrigar os usuários a fazê-lo, sem

que os mesmos estejam dispostos a tal. Um projeto ERP não deve ser simplesmente


45

uma implementação de sistemas, mas também um projeto de mudança de processos,

pois, caso contrário, os benefícios esperados podem não ser obtidos.

Orman (1995) afirma que mesmo pequenas mudanças no uso da TI em uma

organização requerem “grande reestruturação da mesma para que ela tire total

proveito dos benefícios criados pela tecnologia” (p. 100).

Para Venkatraman (1998, p.464), o impacto da TI somente produz resultados

significativos e resulta em vantagem competitiva se o mesmo for acompanhado de

mudanças organizacionais profundas. O modelo de Venkatraman, apresentado na

Figura 8, mostra que quanto mais profunda a transformação realizada no modo

como a organização realiza seus negócios, através da tecnologia da informação,

maiores serão os potenciais benefícios advindos dessa transformação.

Exploração localizada

Integração interna

Redesenho de processos denegócios

Redesenho da rede de negócios

Redefinição do escopo denegócios

Benefícios Potenciais

Gra

u de

Tra

nsfo

rmaç

ão d

o N

egóc

io

Alto

Baixo Alto

Baixo

NíveisEvolucionários

NíveisRevolucionários

Figura 8: Níveis de transformação de negócios promovidos pela TI

Fonte: Venkatraman (1998, p.463)

Porter (1989) afirma que, em qualquer indústria, as regras de concorrências

estão englobadas em 5 forças competitivas, as quais determinam a habilidade da


46

empresa para obter, em média, taxas de retorno sobre investimento superiores ao

custo do capital, o que também varia de indústria para indústria. As 5 forças

competitivas são as seguintes:

1. entrada de novos competidores;

2. poder de negociação dos fornecedores;

3. poder de negociação dos compradores;

4. rivalidade entre os concorrentes;

5. ameaça de substituição de produtos ou serviços.

McFarlan (1984) aplicou os conceitos de TI ao modelo de Porter, resultando

em uma lista de 5 questões que determinam, segundo esse modelo, se a utilização

da TI possui importância estratégica para o negócio.

1. A TI pode construir barreiras para a entrada de novos competidores?

2. A TI pode fornecer serviços que tornem difícil ou caro, para os clientes

mudarem para os concorrentes?

3. A TI pode diferenciar a organização e mudar as bases da competição?

4. A TI pode melhorar o poder de negociação com os fornecedores?

5. A TI pode criar novos produtos?

A Figura 9 mostra uma adaptação entre o modelo de Porter e as questões de

McFarlan.


47

Concorrentes

A TI pode diferenciar aempresa?

A TI pode alterar as basesda competição?

Fornecedores

A TI pode melhorar o poderde negociação?

Compradores

A TI pode prender osclientes?

Produtos substitutos

A TI pode criar novosprodutos?

Novos competidores

A TI pode construirbarreiras?

Figura 9: Questões para avaliação do impacto da TI nas forças competitivas

Fonte: Adaptado de Alanis (1991, p. 425)

Uma dessas forças são os concorrentes, que sempre buscam se sobrepor aos

demais, muitas vezes copiando-lhes inovações, métodos e melhorias. Desta forma,

logo que um dos participantes do mercado apresente alguma novidade – neste caso

um novo sistema – a mesma tende a ser copiada, estabelecendo um novo patamar

para todo o mercado.

Se o projeto ERP limitar-se à implementação do software, sem que os

processos de negócios sejam revistos, o mesmo poderá eventualmente ser

reproduzido pelos concorrentes (bastando simplesmente a aquisição do mesmo

pacote de software e a utilização da mesma consultoria) e a vantagem competitiva

almejada, simplesmente deixar de existir, mesmo depois de grandes gastos com a

implantação de um sistema ERP.

Porter (1989) afirma que a transformação tecnológica “não é, por si só,

importante, mas é importante se afetar a vantagem competitiva e a estrutura

industrial. Nem toda transformação tecnológica é estrategicamente benéfica; ela


48

pode piorar a posição competitiva de uma empresa e a atratividade de uma

indústria. Alta tecnologia não garante rentabilidade” (p.153).

Segundo Stevens (1996, p. 38), BPR e projetos ERP são intrinsecamente

ligados, pois, em muitos casos, a mudança para um sistema ERP é motivada por um

processo de reengenharia ou vice-versa – a implementação de um sistema ERP

motiva um processo de reengenharia. Além disso, o autor considera que a maior

parte dos custos de um projeto ERP é consumida em atividades de reengenharia de

processos, seja com recursos internos ou externos.

Companhias que decidem implementar um sistema ERP sem desenvolver

quaisquer atividades de reengenharia de processos correspondentes não devem

esperar milagres ou grandes benefícios como retorno do projeto, pois “um software

ERP fornece apenas a infra-estrutura e não qualquer tipo de vantagem competitiva”.

(Bartholomew, 1997a, p. 27) Também, se existem problemas nos processos de

negócios atuais, eles não podem ser resolvidos “colocando os dados que eles

produzem em um sistema novo e melhor” (Five steps toward transformation, 1997).

Bancroft et al. (1998) afirmam que, embora muitas empresas se envolvam

em maciços processos de reengenharia, outras se contentam simplesmente em tentar

solucionar seu problemas cotidianos, enquanto se preparam para esforços futuros.

Desta forma, uma implementação de um sistema ERP poderia se encaixar

corretamente em qualquer tamanho de processo de reengenharia, desde o mais

simples aos do tipo “reinventando a empresa” (p. 116).

Iniciar um processo de reengenharia, somente após o término da

implementação de um ERP, também é possível, mas não recomendado (Bancroft et

al., 1998, p. 125). Isso é possível, principalmente, quando a empresa e seus

processos combinam bem com o sistema ERP implantando, pois em caso contrário,

a equipe de projeto terá, ela mesma, que tomar decisões que, no fundo, promoverão

mudanças na maneira da empresa trabalhar.


49

CUSTOMIZAÇÕES

Também é importante destacar que, por mais configurável e parametrizável

que um software ERP seja, muitas vezes ele pode não se adaptar a determinados

processos de negócios da empresa. Laudon & Laudon (1995, p. 413) afirmam que

pacotes de software atendem em média somente 70% das funcionalidades

necessárias ou desejadas pela empresa. As diferenças entre as maneiras como a

empresa e o sistema tratam um determinado processo de negócio, seja pela

impossibilidade do sistema em atender o que se deseja, seja pela decisão da empresa

em não mudar seu processo para se adaptar ao sistema, podem gerar impasses.

Este impasse entre sistema e processo de negócio funcionando de maneiras

diferentes pode gerar customizações – alterações introduzidas no software, que

buscam atender as necessidades do processo sem afetar, à medida do possível, a

estrutura central do sistema.

Os principais sistemas ERP do mercado possuem recursos para introduzir

customizações sem alterar substancialmente o funcionamento do sistema. Alguns

fornecedores ERP também possuem a alternativa de entregar os códigos-fonte do

sistema, permitindo assim que mudanças mais profundas possam ser introduzidas

no sistema, se necessário. O ponto em comum entre autores, fornecedores e

consultores é a recomendação para evitar, ao máximo, introduzir customizações no

sistema.

O procedimento de customização, se soluciona o problema da divergência

entre software e processo de negócio, provoca alguns outros, quer tenha sido a

customização desenvolvida por pessoal interno ou externo.

Segundo Lozinsky (1996, p. 148) os principais problemas trazidos pelas

customizações são os seguintes:


50

• modificam o produto original, criando uma nova versão específica para a

nossa empresa, que pode dificultar a atualização do sistema quando uma

nova versão padrão for lançada pelo fornecedor;

• desenvolver a customização pode significar custos adicionais, algumas

vezes não previstos, além do impacto no cronograma do projeto;

• aceitar a customização pode ser uma maneira de encobrir uma

ineficiência dos processos atuais, fazendo com que o novo sistema

“herde” essas ineficiências, ou seja, custos desnecessários;

• customização é como amendoim: não se pára na primeira – dificilmente

uma lista de modificações no pacote conterá “apenas” uma única

customização.

Além do custo do desenvolvimento da customização propriamente dito, está

se introduzindo um novo custo no processo: o custo de manutenção das

customizações realizadas que, ao contrário do custo do projeto, deve se estender por

toda a vida do sistema, pois, a cada nova versão liberada pelo fornecedor, as

customizações devem ser transportadas para a mesma (When implementing na ERP-

system, streamline business processes but leave software code alone, 1997).

PRESENÇA DE CONSULTORIAS EM PROJETOS ERP

Consultorias especializadas na implantação de sistemas ERP geralmente são

uma presença constante nesse tipo de projetos e, normalmente, as responsáveis pela

maior parte dos custos totais associados ao projeto.

Sua presença, que normalmente é associada à experiência no software em

implantação, conhecimento do tipo de negócio da empresa e capacidade para

desenvolver atividades de melhoria de processos, é defendida por muitos autores,

apesar de algumas restrições à atuação das mesmas.


51

Baca (1980) apresenta a seguinte definição para a atividade de consultoria

empresarial:

“[...] é o trabalho profissional executado por pessoas

especialmente treinadas e experimentadas em ajudar gerentes

de vários tipos de empresas a solucionar problemas

gerenciais e maximizar oportunidades econômicas através de

análise sistemática de fatos e aplicação de julgamento

objetivo baseado em conhecimento especializado, habilidades

e técnicas.” (p. 43)

Segundo Kubr apud Baca (1980), quatro devem ser as características de uma

atividade de consultoria:

1. ser um serviço independente;

2. ser um serviço de aconselhamento;

3. fornecer conhecimento profissional e habilidades relevantes para

problemas gerenciais;

4. não ser um serviço que forneça soluções miraculosas para problemas

gerenciais difíceis.

Bashein et al. (1994) afirmam que o próprio estudo acadêmico da

reengenharia iniciou-se primeiramente a partir dos trabalhos de consultoria, sendo

sua visão do processo a base para a pesquisa em pré-condições para sucesso em

projetos de BPR.

Segundo Lozinsky (1996), os consultores “devem agregar valor aos

trabalhos: eles precisam trazer conhecimentos novos sobre o pacote [...]

conhecimentos que vêm de situações práticas já vividas, e que podem fazer com que

a empresa evite trilhar caminhos que outras implementações já mostraram não

funcionar muito bem” (p. 61). Eles também precisam se posicionar para “equilibrar

sua lealdade ao cliente e ao projeto em relação à defesa do fornecedor” (p. 63), pois


52

a consultoria deve saber o que é possível e viável ser feito em relação às

funcionalidades do pacote e aos desejos do cliente.

Mas não deve haver uma simples aceitação e concordância integral com as

opiniões e diretrizes da consultoria. Stevens (1996, p. 37) recomenda que os

consultores sejam desafiados e gerenciados constantemente, pois muitos conhecem

somente uma forma de fazer algo, enquanto que o sistema muitas vezes oferece

diversas possibilidades. Além disso, não basta a experiência no pacote a ser

implementado e na sua configuração, mas também conhecimento do tipo de negócio

da empresa.

Com a demanda crescente pela implementação de sistemas ERP, o mercado

está aquecido para profissionais com alguma especialização nesta área, pois, mesmo

que eles não conheçam muito, conhecem mais do que os outros sobre o assunto. Isto

ocorre principalmente com consultores especializados em SAP R/3, o líder de

mercado de software ERP. O Gartner Group estima que existam pelo menos 18 mil

consultores especializados em SAP R/3 no mundo – a maior parte alocada ao

próprio fornecedor ou às grandes empresas de consultoria – e eles não conseguem

atender a demanda por novos projetos (Kay, 1998).

Isso leva a duas situações diferentes: a primeira, é o aumento dos salários e,

conseqüentemente, dos custos de implantação, podendo chegar o preço de um

consultor a US$ 2.500,00 por dia (Kay, 1998). O custo desses consultores durante

um projeto longo pode facilmente provocar o estouro de qualquer orçamento, e

parece não existir, em função da alta demanda por sistemas ERP, perspectiva de

redução de custos, pelo menos nos próximos dois ou três anos (Better bang for the

buck, 1997, p. 82).

Para reduzir esses gastos, é importante a correta utilização dos recursos de

consultoria, garantindo que o projeto seja implantado no prazo sem alterar

substancialmente o orçamento. Algumas atividades de modelagem de simulação de

processos dentro do projeto podem, e devem, ser desenvolvidas pela equipe de


53

trabalho da própria empresa, como forma de não produzir gastos desnecessários

com a consultoria.

A segunda é a existência de muitos consultores sem a necessária qualificação

para desenvolver a implementação de um projeto ERP. A mesma pesquisa do

Gartner Group que identificou como aproximadamente 18 mil o número de

consultores SAP R/3, também conclui que menos de 500 tinham feito mais de duas

implementações completas do produto, resultando em uma grande maioria de

profissionais com pouca experiência (Kay, 1998).

É natural que nem todos os consultores tenham a mesma qualificação e

experiência profissional, mas, segundo Lozinsky (1996), no “conjunto eles devem

formar um grupo com a qualificação necessária” (p. 92). Outros autores sugerem

que pelo menos 1/3 dos consultores a trabalhar no projeto tenham experiência real

no pacote a ser implementado ( How to find the right R/3 consultant, 1998).

Na busca para reduzir custos, a empresa pode optar por pessoal próprio, se

estes tiverem qualificação e estiverem disponíveis. Um exemplo desses, no Brasil, é

o caso da Siemens, que reduziu 30% dos custos de implementação de um projeto

ERP de US$ 20 milhões, utilizando-se de pessoal interno, que já havia passado por

uma implementação semelhante em uma unidade da empresa em Portugal (Farto,

1998a, p. 7).

Como muitas vezes o projeto ERP também é um projeto de BPR (ou é

ligado a algum, ou simplesmente possui atividades de BPR), o fato de existir uma

consultoria externa no projeto de implantação pode ser muito benéfico ao processo

de BPR, pois, segundo Hammer (1990), a presença de consultores externos ao

processo pode fornecer uma visão nova nos processos atuais e descobrir passos e

condições que são parte integral do processo sem servir a algum propósito

específico. Os consultores também podem trazer uma visão objetiva para o projeto e

agir como mediadores nos conflitos que inevitavelmente surgem. Todavia, não se

pode afirmar que projetos ERP somente são possíveis ou devem ser desenvolvidos

com presença de consultorias. Stevens (1997) cita o caso da Kodak, cujo projeto


54

ERP é totalmente administrado e gerenciado pela própria empresa, sem a presença

de consultores externos. Porém, deve ser ressaltado que a empresa afirma ter

estabelecido um firme compromisso e fornecido o nível adequado de recursos e

participação, como forma de atingir seu objetivos de “ser proprietária do projeto,

compreender o sistema que estava sendo desenvolvido, e ser auto-suficiente na

capacidade de dar suporte ao mesmo futuramente” (p. 133).

MEDIDAS DE SUCESSO DE PROJETOS

Finalmente, a questão já citada várias vezes referente ao sucesso de um

projeto. Determinados tipos de projeto podem ter fácil determinação de sucesso,

seja pelo mesmo poder ser facilmente identificável ou pelo mesmo poder ser

mensurável. Projetos de BPR, por exemplo, com uma redução de pessoal de 75%

(Hammer, 1990) ou tempo de atendimento de pedidos reduzido de 33 para 6 dias

(Davenport & Short, 1990), possuem uma definição muita clara de ser – ou não –

um sucesso.

Larsen & Myers (1997), avaliando a literatura de implementação de projetos

de sistemas de informação, afirmam que não existe um consenso claro para a

definição de sucesso ou fracasso de um projeto. Sauer et al. (1997) sugerem que o

sucesso ou fracasso de um projeto somente pode ser constatado mediante a opinião

dos diversos interessados, sendo que esta também varia com o tempo. A seguir

algumas das principais razões citadas por eles, para as quais um projeto de TI pode

ser considerado um fracasso:

• fracasso de correspondência: o sistema não corresponde aos requisitos;

• fracasso de processo: estouro no custo ou prazo previstos,

desenvolvimento ou implementações problemáticos;

• fracasso de interação: o sistema não é usado.


55

Hallows (1997), por sua vez, afirma que mesmo objetivos que aparentemente

não podem ser quantificados devem ser identificados, e a partir disso buscar-se uma

definição mensurável para os mesmos. Por exemplo, a afirmação que será

implementado um sistema integrado, não é suficiente, devendo ser mensurado

quanto as vendas aumentarão (e.g., 5%) pela disponibilidade de acesso on-line ao

sistema por parte dos clientes.

DeLone & McLean (1992) definem o sucesso de projetos de sistemas de

informação na forma de 6 dimensões, interdependentes, que são: a) qualidade do

sistema; b) qualidade da informação; c) uso; d) satisfação do usuário; e) impacto

nos indivíduos; e f) impacto na organização. A Figura 10 representa esse modelo:

Qualidade dosistema

Qualidade dainformação

Uso

Satisfação dousuário

Impacto noindivíduo

Impactoorganizacional

Figura 10: Dimensões interdependentes do sucesso de projetos de sistemas de informação

Fonte: DeLone & McLean (1992)

Os interessados no projeto (stakeholders) são “indivíduos (ou organizações)

que estão ativamente envolvidos no projeto, ou cujos interesses possam ser positiva

ou negativamente afetados como resultado da execução ou término com sucesso do

projeto” (Project Management Institute, 1996, p. 15). Esses interessados possuem

diversas e variadas necessidades e expectativas em relação ao projeto, sendo muitas

vezes não declaradas.

É importante que o gerente do projeto saiba exatamente quais são os

interessados no projeto, suas necessidades e expectativas em relação ao mesmo, e


56

saiba como lidar com as diversas situações onde estas estarão envolvidas, como

forma de garantir o sucesso do projeto. Considerando que as diversas necessidades e

expectativas são, muitas vezes, conflitantes entre si, também se pode considerar que

o conceito de sucesso de um projeto poderá não atender a todas elas (Cleland, 1988,

p. 275).

Assim como um projeto pode ter um grau diferente de sucesso em relação a

todos os interessados, o mesmo também pode ocorrer em relação aos resultados

obtidos pelo projeto. Pinto & Slevin (1988a) afirmam que, se um projeto é uma

unidade organizacional temporária, voltada para o alcance de determinados

objetivos, completar com sucesso um projeto significa atingir esses objetivos dentro

das especificações técnicas de custo e prazo pré-determinados.

Porém, existe uma questão. Se um projeto cumpriu seu cronograma, mas

produziu um grande estouro de orçamento, ele pode ser considerado um sucesso? Se

ele cumpriu cronograma e orçamento, mas a organização não se tornou mais efetiva

com sua conclusão, ele pode ser considerado um sucesso?

Para Pinto & Slevin (1988c, p. 481), um projeto pode ser considerado um

sucesso de implementação se o mesmo atender a quatro requisitos básicos, que são:

• terminar dentro do cronograma (critério temporal);

• terminar dentro do orçamento (critério monetário);

• atingir basicamente todos os objetivos originalmente definidos para ele

(critério de eficácia);

• se aceito e usado pelos clientes para os quais o projeto era destinado

(critério de satisfação dos clientes).

Além destes, alguns outros critérios podem ser considerados, buscando

identificar se os resultados obtidos nos vários critérios podem definir um projeto

como sendo ou não um sucesso. A lista resultante pode ser a seguinte:


57

• aderência ao orçamento;

• aderência ao cronograma;

• nível de desempenho atingido;

• validade técnica;

• validade organizacional – o projeto deve ser adequado à organização ou

aos seus clientes, e eles devem fazer uso dos resultados;

• efetividade organizacional – a organização deve tornar-se mais efetiva

como resultado do projeto.

Deve ser observado que essa abordagem deixa de lado o enfoque nos

stakeholders – principais interessados no projeto – cuja diversidade de interesses

pode não ser unânime sobre o sucesso de um projeto. Identificar corretamente esses

interessados no projeto, bem como suas necessidades, interesses e expectativas em

relação ao projeto é uma tarefa que pode não ser simples, ou até mesmo ser

impossível.

ADOÇÃO DE NOVAS TECNOLOGIAS

O processo de implementação de um sistema ERP, como a maior parte dos

sistemas de informação, não se encerra com a colocação do mesmo em produção,

pois existem vários fatores que somente ocorrerão e poderão ser observados após o

sistema estar em operação. Dependendo do grau de mudança provocado pelo

projeto, fatores tais como a adoção e o uso do novo sistema poderão ocorrer de

maneira mais ou menos efetiva.

A teoria da inovação se aplica ao estudo da adoção (decisão de usar) e

difusão (a extensão da implementação) das inovações dentro das organizações

(Ruppel & Howard, 1998, p. 5). Isto se aplica normalmente a inovações que são


58

realmente novas à organização, e não somente uma idéia moderna. Todavia, a

literatura sobre o assunto “tem tido dificuldade em encontrar uma única teoria que

explique os processos de adoção e difusão de uma miríade de inovações dentro das

organizações. Diferentes classificações de inovações [...], o nível no qual a inovação

é adotada e difundida [...], o escopo da inovação, o tipo da inovação .[...] tem sido

propostas” (p. 6), tentando esclarecer os conhecimentos sobre o assunto.

Segundo o modelo de Leavitt (1965), reproduzido na Figura 11, quatro

forças em equilíbrio formam uma organização: Tarefas, Pessoas, Estrutura e

Tecnologia. Essas forças são interdependentes entre si e permanecem em um estado

de equilíbrio até que algum fato novo – por exemplo um sistema ERP – promova

uma mudança em um dos componentes, provocando a necessidade em todos os

demais de se ajustar à nova situação. Muito provavelmente a implementação de um

sistema ERP promoverá mudanças em pelo menos um dos componentes, qual seja,

a tecnologia. Dependendo do escopo e da profundidade da mudança de processos

envolvidos, todos os outros poderão ser afetados.

Tecnologia

Estrutura

Pessoas

Tarefas

Figura 11: Modelo do diamante, de Leavitt.

Fonte: Leavitt (1965)

Uma inovação inserida na organização pode (ou não) ser difundida pela

organização de diversas maneiras. O Modelo de Decisão e Inovação, de Rogers e


59

Shoemaker apud Miranda (1992), aponta como sendo quatro os elementos

principais do processo de difusão. São eles:

• Inovação: idéia, prática ou objeto percebido como novo pelo indivíduo, a

ser absorvido de um modo diferente dentro de um meio social e de modo

diferente entre as categorias desse meio social;

• Canais de Comunicação: meios pelos quais as informações sobre as

inovações são transmitidas para e entre os membros de um sistema social;

• Tempo Decorrido: medido entre o primeiro conhecimento do indivíduo

ou sistema social da inovação e sua adoção;

• Membros do Sistema Social: coletividade de unidades que, embora

funcionalmente diferentes, estão engajadas na solução de problemas ou

no atingimento de objetivos comuns.

Já o modelo de Lewin-Schein apud Miranda (1992) propõe a existência de

um equilíbrio mantido por forças operando em duas direções: uma delas encoraja as

mudanças e outra as inibe. Para que ocorra a mudança, as primeiras devem ser

maiores que as últimas. Isto ocorre em um processo iterativo de três fases

seqüenciais:

• Fase de Descongelamento: prepara o indivíduo (ou o grupo) para a

mudança, criando um sentimento de necessidade de mudança;

• Fase de Mudança: o indivíduo (ou grupo) adquire novos hábitos, valores,

habilidades, comportamento, que são incorporados aos antigos.

Relacionamentos e forma de execução de tarefas são alterados;

• Fase de Recongelamento: os novos hábitos são incorporados e o novo

comportamento recém-adquirido se torna firmemente estabelecido.

Por este processo ser considerado iterativo, após o “recongelamento” não

ocorre uma estagnação, mas sim uma nova repetição do ciclo, iniciando-se uma


60

nova fase de “descongelamento”, onde os comportamentos adquiridos e

estabelecidos no ciclo anterior serão questionados e uma nova mudança poderá

ocorrer.

Kown & Zmud (1987) propuseram um modelo, representado na Figura 12, o

qual considera 6 fases para o processo de implementação. O foco principal ocorre

na análise “pós-adoção” ou “pós-inovação”, o que não ocorre em outros modelos

tradicionais. Segundo eles, uma inovação somente pode ser considerada apropriada

ou inapropriada se a análise da mesma verificar todos esses aspectos.

Descongelamento

Iniciação Adoção Adaptação Aceitação

Mudança Recongelamento

UsoIncorporação(desempenho)

(satisfação)

Figura 12: Modelo de Kwon-Zmud sobre o processo de implementação

Fonte: Kown & Zmud (1987)

A incorporação somente ocorre quando “a inovação está enraizada dentro

das rotinas da organização e quando a inovação é aplicada em todo o seu potencial

dentro da organização” (Kown & Zmud, 1987, p. 233).

Dessa forma, a avaliação de projetos ERP – como outros projetos de TI – não

deveria simplesmente encerrar com a constatação da colocação do sistema em

produção e, desta forma, considerá-lo como uma inovação introduzida na

organização, mas sim avaliar o seu uso e o grau de incorporação ocorrido em

relação ao mesmo.

Também parece razoável que tais critérios possam ser melhor avaliados em

partes do sistema ERP, cuja aceitação e uso são voluntários, particularmente


61

módulos gerenciais e de apoio à decisão, pois, em partes operacionais e com

aceitação e uso obrigatórios, esta análise pode ser prejudicada.

SUMÁRIO

Este capítulo apresenta as principais definições teóricas sobre os assuntos

tratados neste trabalho. Inicialmente, é tratada a conceituação de sistemas ERP. Em

seguida, aborda-se as razões pelas quais as organizações buscam esse tipo de

sistema e iniciam seus projetos de implementação, bem como as características da

implementação desse tipo de projeto. Também são discutidas as estratégias

utilizadas no momento da colocação do sistema em produção.

Por se tratar de um tipo específico de projeto, é feita, a seguir, uma

discussão, de maneira geral, sobre administração de projetos e fatores críticos de

sucesso, por serem componentes fundamentais para os objetivos deste trabalho,

conforme apresentado no Capítulo 1.

Dentro da abordagem dos fatores críticos de sucesso, é discutido o aspecto

do alinhamento entre os objetivos do projeto e a organização; a participação dos

envolvidos na implementação do projeto; as mudanças na organização provocadas

por um projeto desta natureza; e a presença de consultores externos.

Finalmente, trata-se sobre a medida de sucesso em projetos e sobre a adoção

de novas tecnologias por parte das organizações.

62

Capítulo 3

MODELO DE PESQUISA

MODELO DE PESQUISA

O modelo de pesquisa se utiliza de fundamentos que podem ser encontrados

em algumas abordagens teóricas: fatores críticos de sucesso; ciclo de vida de

projetos; sucesso em projetos; e adoção de tecnologia.

Vários dos objetivos apresentados em relação à pesquisa consideram a

existência de fatores críticos de sucesso no projeto, ou seja, os elementos cuja

presença em níveis adequados contribui sobremaneira para assegurar o sucesso na

implementação de um projeto. Dessa maneira o modelo foi desenvolvido para, entre

outras coisas, identificar a presença desses fatores.

Foram escolhidos sete fatores – listados a seguir – para a análise em relação

ao projeto. Os cinco primeiros foram escolhidos a partir de trabalhos sobre fatores

críticos de sucesso que os citam freqüentemente (Kwon & Zmud, 1987; Pinto &

Slevin, 1986; Hammer & Champy, 1993; Robb, 1995 apud Larsen & Myers, 1997).

Os dois fatores restantes foram extraídos da literatura existente sobre a

implementação de sistemas ERP, onde são encontrados como pré-requisitos à

execução desse tipo de projeto (Bartholomew, 1997a; Lozinsky, 1996; Radosevich,

1997; Stevens, 1997; Vasilash, 1996, Bancroft et al., 1998).

Os fatores críticos escolhidos foram os seguintes:

1. missões claras e definidas;

CAPÍTULO 3: MODELO DE PESQUISA

63

2. apoio da alta administração;

3. usuários capazes e envolvidos;

4. planejamento detalhado do projeto;

5. gerente de projeto com habilidades necessárias;

6. presença de consultoria externa;

7. mudança nos processos de negócios.

Além de verificar a presença desses fatores críticos de sucesso, o modelo

também considera que os fatores críticos não são estáticos em relação ao projeto,

mas possuem variações de importância e intensidade no decorrer do mesmo (Pinto

& Slevin, 1988b).

Dessa forma, o modelo se utiliza do conceito de ciclo de vida de projetos

com o objetivo de identificar essas variações em relação às fases do ciclo de vida.

Foi escolhido, para isso, um modelo de ciclo de vida de projeto composto de quatro

fases:

1. Conceituação;

2. Planejamento;

3. Execução;

4. Encerramento.

Como a abordagem de fatores críticos afirma que a presença dos mesmos

aumenta as chances de sucesso de um projeto, o modelo também abrange a

identificação de sucesso ou não do projeto. Sendo a definição de sucesso de projeto

um tanto quanto ambígua e de difícil comprovação, a mesma será feita a partir da

análise de alguns componentes mais comuns de sucesso de projetos. Para tanto,

serão considerados como componentes do sucesso do projeto os seguintes

elementos:


64

1. tempo;

2. custo;

3. qualidade e desempenho;

4. efetividade organizacional.

Dentre esses componentes não serão considerados os interesses e as

expectativas dos stakeholders – principais interessados no projeto – que muitas

vezes não são declarados ou mesmo conhecidos.

Visando a atender um dos objetivos deste trabalho, o modelo de pesquisa

também busca identificar as motivações que levaram a organização à decisão de

desenvolver um projeto para a implementação de um sistema ERP. Esses motivos

podem ser únicos ou formar um conjunto de motivações, que podem variar entre

organizações.

Finalmente, o modelo ainda busca identificar o nível de adoção de tecnologia

ocorrido após a implementação do projeto. O modelo busca testar o seguintes níveis

de adoção de tecnologia, extraídos do modelo de Kwon & Zmud (1987): adoção,

uso e incorporação. Este último nível, se atingido, demonstra que o sistema já está

completamente embutido na cultura da organização, fazendo parte de sua rotina. O

modelo de pesquisa, descrito acima, está representado graficamente na Figura 13.


65

F2 Apoio da alta Administração

F3 Usuários capazes e envolvidos

F4 Planejamento detalhado do projeto

F5 Gerente de projeto com habilidades necessárias

F6 Presença de consultoria externa

F7 Mudança dos processos de negócio

Efetividadeorganizacional

Qualidade /desempenho

Tempo

Custo

Impo

rtân

cia

dos

Fat

ores

nas

Fas

es

Con-ceito

Sucesso do Projeto

Fases do Ciclo de Vida do Projeto

Planeja-mento Execução Con-

clusão

Fatores Críticos de Sucesso

F1 Missões claras e definidas

Motivações para oprojeto

Ambiente ExternoAmbiente Interno

Inco

rpor

ação

Uso

Ace

itaçã

o

Ada

ptaç

ão

Ado

ção

Inic

iaçã

o

Níveis de Adoção de Tecnologia

Situação daInformática

Disposiçãoda empresap/ mudança

Figura 13: Modelo de pesquisa apresentado graficamente

HIPÓTESES DA PESQUISA

Buscando atingir os objetivos apresentados anteriormente, procurou-se criar

hipóteses a serem testadas com base nos dados coletados junto à população

amostral. Foram elaboradas as seguintes hipóteses:


66

H0,1 : As motivações para o projeto não têm seus objetivos alcançados.

H0,2 : A existência de missões claras e definidas não é um fator crítico para o

sucesso do projeto.

H0,3 : A existência de apoio da alta administração não é um fator crítico para

o sucesso do projeto.

H0,4 : A existência de usuários capazes e envolvidos não é um fator crítico

para o sucesso do projeto.

H0,5 : A existência de um planejamento detalhado do projeto não é um fator

crítico para o sucesso do projeto.

H0,6 : A existência de um gerente de projeto com as habilidades necessárias

não é um fator crítico para o sucesso do projeto.

H0,7 : A existência de uma empresa de consultoria externa não é um fator


H0,8 : A existência de mudanças dos processos de negócio não é um fator


H0,9 : Não existe relação entre a satisfação dos usuários com os sistemas

existentes e o sucesso do projeto.

H0,10 : Não existe relação entre a disposição da empresa para mudança e o

sucesso do projeto.

DEFINIÇÃO DAS VARIÁVEIS

A definição das variáveis a serem utilizadas é de particular importância em

um trabalho de pesquisa, pois busca definir da maneira mais precisa possível, o que

se busca pesquisar. Para tanto, realiza-se a definição conceitual e operacional das


67

variáveis. Tull & Hawkings (1976) apresentam a seguinte definição para este

processo:

A “definição conceitual” define um conceito em termos de

outros conceitos. Ela especifica a idéia central ou essência do

conceito. Muito freqüentemente é o equivalente a uma

definição encontrada no dicionário. [...] Uma “definição

operacional” descreve as atividades que o pesquisador deve

completar para associar um valor a um conceito sob estudo

em um determinado caso. Conceitos são abstrações; tanto

que não são observáveis. As definições operacionais traduzem

o conceito em um ou mais eventos observáveis.” (p. 214)

Considerando-se as hipóteses da pesquisa, foram definidas as principais

variáveis inseridas nestas hipóteses, que serão testadas neste trabalho. A seguir,

estão listadas as variáveis com suas definições teóricas e operacionais.

1. Motivações

Conceito: Fator ou conjunto de fatores, que leva um indivíduo a apresentar

um determinado padrão ou desempenho, ou a tomar uma decisão. (Bowditch

& Buono, 1992)

Operacionalização: Para efeito da pesquisa, foram consideradas as causas ou

motivos, apresentados pelos respondentes, como sendo os responsáveis por

uma decisão favorável ao desenvolvimento de um projeto para

implementação de um sistema ERP.

2. Fatores críticos de sucesso

Conceito: Fatores críticos de sucesso são o número limitado de elementos

cuja presença em níveis adequados é importante para assegurar o sucesso na

implementação de um projeto.


68

Operacionalização: Foram considerados um conjunto de 7 fatores como

sendo críticos para a implementação de projetos ERP:

2.1. Missões claras e definidas

Operacionalização: Clareza inicial dos objetivos e diretrizes gerais do

projeto, que determinam quais objetivos devem ser atingidos.

2.2. Apoio da alta administração

Operacionalização: Vontade da alta administração em fornecer os

recursos necessários, além da autoridade e poder para a execução do

projeto.

2.3. Usuários capazes e envolvidos

Operacionalização: Usuários com conhecimento funcional das áreas

abrangidas pelo escopo do projeto e com as habilidades necessárias para

a participação na equipe do projeto, assim como com disponibilidade de

tempo e também envolvidos, ou seja, comprometidos com a

implementação do projeto e seu sucesso.

2.4. Planejamento detalhado do projeto

Operacionalização: Especificação detalhada dos passos e ações

individuais, bem como da alocação de recursos necessária para garantir

a execução de todas as atividades essenciais à conclusão do projeto.

2.5. Gerente de projeto com habilidades necessárias

Operacionalização: Um líder do projeto com habilidades

administrativas, técnicas e interpessoais necessárias para administrar a

equipe de projeto, e ainda com o apoio e autoridade requeridos para a

condução do projeto.

2.6. Presença de consultoria externa


69

Operacionalização: A participação de empresa de consultoria

especializada na implementação do software escolhido, enquanto durar o

projeto, em atividades de planejamento, técnicas e/ou funcionais.

2.7. Mudança nos processos de negócios

Operacionalização: Alterações introduzidas nos processos de negócios

da empresa, com relação direta à implementação do projeto, com o

objetivo de melhorar o desempenho da organização ou adaptá-la ao novo

sistema.

3. Fases do ciclo de vida do projeto

Conceito: Diferentes fases do projeto, com seus próprios objetivos e metas,

além de diferentes recursos, definições, gastos e atividades. A concretização

das atividades de cada fase deve levar à conclusão do projeto.

Operacionalização: Para a realização da pesquisa, foram consideradas as

seguintes fases para a implementação de projetos ERP, caracterizadas pelas

atividades descritas a seguir:

3.1. Fase de Conceituação

Operacionalização: Processo de escolha do software e tomada da

decisão de implementá-lo.

3.2. Fase de Planejamento

Operacionalização: Desenvolvimento do plano de implementação do

projeto.

3.3. Fase de Execução

Operacionalização: Treinamento para conhecer o software, simulação de

processos de negócios no software, modelagem de dados e processos,


70

mudança dos processos de negócio, desenvolvimento de interfaces e

customizações.

3.4. Fase de Encerramento

Operacionalização: Parametrização do sistema, treinamento do usuário

final, colocação do sistema em produção e desativação de sistemas

antigos.

4. Sucesso do projeto

Conceito: Atingir os objetivos previstos, com aderência ao orçamento,

cronograma e escopo previstos, apresentar desempenho e validade aceitáveis,

além de melhorar a organização de alguma forma.

Operacionalização: As seguintes dimensões de sucesso em projetos foram

usadas para a realização da pesquisa:

4.1. Tempo

Operacionalização: O projeto deve ser executado dentro do tempo e

cronograma estipulados para o mesmo.

4.2. Custo

Operacionalização: Os custos totais do projeto devem se situar dentro do

orçamento planejado.

4.3. Desempenho e qualidade

Operacionalização: O desempenho do sistema deve ser compatível com

o esperado, permitindo sua correta e completa utilização. Também deve

ser válido tecnicamente e adequado à organização, ou aos seus clientes,

e eles devem fazer uso dos resultados.

4.4. Efetividade organizacional


71

Operacionalização: A organização deve melhorar e tornar-se mais

efetiva como resultado do projeto.

5. Nível de adoção de tecnologia

Conceito: Com uma inovação tecnológica (como um novo sistema)

implantada, o nível de adoção desta tecnologia varia dependendo do quanto a

inovação se torna inserida dentro da organização e na utilização de todo o

seu potencial.

Operacionalização: Na pesquisa, foram usados somente os seguintes níveis

de adoção de tecnologia (Kown & Zmud, 1987, p. 233):

5.1. Adoção

Operacionalização: O sistema foi implementado e está sendo utilizado

pela organização.

5.2. Uso

Operacionalização: O sistema é amplamente utilizado e suas

informações são úteis ao processo de tomada de decisão.

5.3. Incorporação

Operacionalização: O sistema já está inserido dentro da rotina da

organização e seus recursos e potencial estão sendo totalmente

explorados.

6. Situação da informática

Conceito: Situação da informática da organização, particularmente quanto à

qualidade percebida em relação aos sistemas existentes antes da

implementação do novo sistema.


72

Operacionalização: Grau de satisfação em relação aos sistemas, às

informações fornecidas, às alterações introduzidas no mesmo e tempo

necessário para tal.

7. Disposição para a mudança

Conceito: É a existência de empresas mais dispostas à mudança que outras, e

que reagem de forma diferente às pressões para mudar. A implementação de

um sistema ERP quase que obrigatoriamente provocará uma mudança nos

hábitos – e não necessariamente na cultura – e nos procedimentos

organizacionais. (Drucker, 1992; Davenport, 1998)

Operacionalização: Existência de projetos na empresa, que envolvam

processos de mudança, juntamente com a percepção sobre a mesma quanto

as respostas a pressões e inovação.

MÉTODOS

SURVEY

O desenvolvimento da pesquisa foi baseado no método de levantamento de

dados – survey – que é a “coleta de informação dos respondentes com o propósito

de compreender e/ou predizer alguns aspectos do comportamento da população de

interesse” (Tull & Hawkings, 1976, p.373).

Um das principais vantagens do survey, segundo Aaker & Day (1990, p.

187), é “que o mesmo permite coletar uma grande quantidade de dados sobre um

respondente de uma vez, sendo que estes dados podem ser: 1) profundidade e

extensão dos conhecimentos; 2) atitudes, interesses e opiniões; 3) comportamento

[...]; e 4) variáveis de classificação, tais como idade, renda, [...].”


73

Para Hyman (1957, p. 2) o “survey, além da função descritiva da acumulação

de fatos e opiniões expressas, representativas da população-meta, os levantamentos

podem ter também uma função explanatória alcançada através de instrumentos, tais

como a análise simultânea de muitas variáveis, como a análise multidimensional.”

Kerlinger (1986) apud Grover (1998) divide os surveys em exploratórios e

explanatórios. Os primeiros têm por objetivo principal tornar-se mais familiar com

um assunto, quando não existe um modelo definido ou os pontos de interesse

necessitam ser melhor compreendidos e mensurados. Por sua vez, os últimos já se

utilizam de teorias estabelecidas e buscam estabelecer relações causais entre as

variáveis em estudo.

De acordo com as características da pesquisa e como os objetivos possuem

um certo caráter exploratório – identificar e priorizar motivações para um projeto

ERP – e também explanatório – testar a presença de fatores críticos de sucesso – a

utilização de um survey pareceu bastante adequada.

Um survey também pode ser dividido de acordo com sua forma de coleta dos

dados: entrevista pessoal, entrevista telefônica ou por correio. Cada uma dessas

formas possui suas vantagens e desvantagens, podendo ser mais ou menos adequada

em uma ou outra situação.

A pesquisa se utilizou de survey por correio para aplicação de questionários

aos respondentes. Este tipo de survey tem como principais vantagens o baixo custo,

a não-presença do entrevistador – uma possível fonte de erro – além “de resultados

mais precisos, dentre os questionários respondidos, pois muitos não o são” (Aaker

& Day, 1990, p. 209).

A ampla distribuição geográfica dos respondentes, bem como sua baixa

disponibilidade de tempo – em função do ritmo normalmente acelerado deste tipo

de projeto – são fatores que tornaram o survey por correio bastante atrativo. Dentre

as principais desvantagens do questionário, a que mais se aplica no caso desta


74

pesquisa é a impossibilidade de esclarecimentos em caso de dúvida no

preenchimento do questionário.

A maior parte dos respondentes foi contatada previamente, por telefone, para

explicar os objetivos da pesquisa, solicitar sua colaboração e combinar o envio do

questionário. Acompanhando o mesmo, seguiu uma carta de apresentação com as

credenciais da Instituição e os objetivos da pesquisa, bem como um envelope já

preenchido e selado, a ser usado para o retorno do questionário preenchido.

A carta de apresentação ainda deixa claro que os dados são confidenciais e

não serão utilizados de forma individualizada, informa o tempo médio usado para o

preenchimento do questionário – estimado em 15 minutos – e, apresenta ao

respondente a possibilidade de receber um sumário executivo com os resultados da

pesquisa, o que se espera, serviu como estímulo à resposta e retorno do

questionário. O questionário pode ser encontrado no Anexo 2, enquanto que a carta

de apresentação está presente no Anexo 1.

QUESTIONÁRIOS

Um questionário é, segundo Chisnall (1980, p. 175), "um método de obter

informação específica sobre um problema definido de modo que, os dados, após

análise e interpretação, resultem em melhor apreciação do problema". Segundo

Parasuraman (1991, p. 363), é "um grupo de questões desenhado para gerar os

dados necessários para se atingir os objetivos de um projeto de pesquisa". Para

Kinnear & Taylor (1991, p. 336), é "um roteiro formalizado para coleta de dados

dos respondentes". A Figura 14 mostra o papel do questionário no projeto de

pesquisa.


75

Necessidade deinformação

Projeto depesquisa

Questõesperguntadas

Questionário

Dados

Respondentes

Figura 14: Representação da ligação entre necessidade de informação e dados

Fonte: Kinnear & Taylor (1991, p.340).

Os questionários, segundo Parasuraman (1991, p. 363), apresentam a

possibilidade de sua utilização tanto em atividades de pesquisa exploratórias, quanto

de pesquisa conclusiva. No primeiro caso, busca-se obter informações e dados

preliminares que orientarão o desenvolvimento de um projeto de pesquisa, podendo,

então, ser utilizados os questionários de forma mais "informal e flexível", o que já

não ocorre no segundo caso.

O desenvolvimento de um questionário é uma tarefa bastante difícil, apesar

de "poder parecer simples, principalmente por aqueles que nunca desenharam um

anteriormente" (Parasuraman, 1991, p. 364). Segundo Kinnear & Taylor (1991, p.

338), "o desenho de um questionário é mais uma arte do que um empreendimento

científico".

O questionário da pesquisa foi desenvolvido como estruturado e não

disfarçado, ou seja, o mesmo possui, em sua maior parte, questões com alternativas

pré-definidas. As questões, que permitem algum tipo de resposta aberta, permitem

fazê-lo em poucas palavras, sem alterar essencialmente a característica de

questionário estruturado. O questionário também não é disfarçado, pois as questões

são diretas ao ponto desejado. Questões disfarçadas são recomendadas para

situações onde se busca identificar “atitudes encobertas em aspectos passíveis de

constrangimento social, tais como aborto, poluição ou atos ilegais” (Parasuraman,

1986, p. 221).


76

Dentre as vantagens de questionários estruturados sobre não-estruturados,

citados por Parasuraman (1986, p. 210), as que mais se aplicam no caso desta

pesquisa são: possibilidade de se cobrir mais tópicos no mesmo intervalo de tempo;

menos tempo necessário tanto para o respondente quanto para o processamento;

rápida transferência dos dados coletados para o processamento; mais barato; maior

acuracidade; mais conveniente aos respondentes em função do tempo para resposta

e da facilidade.

Foi realizado um pré-teste junto a três possíveis respondentes com

acompanhamento do preenchimento do questionário. Esse teste teve o intuito de

medir o tempo necessário, obter subsídios e identificar possíveis problemas que

pudessem existir, como, por exemplo, termos dúbios, dificuldade de compreensão

das questões, intervalos ou alternativas de respostas inadequadas, e outros. Como

resultado do pré-teste, ocorreram algumas mudanças na formulação das questões e

afirmações, para melhorar e simplificar seu entendimento. Também foram

acrescentadas outras alternativas para uma das questões. O tempo gasto para o

preenchimento do questionário, no pré-teste, foi entre 15 e 20 minutos.

Parasuraman (1991, p. 396) aponta o fato de que o pré-teste não deve ser

visto como um substituto para o cuidado e o rigor no desenvolvimento do

questionário, nem tampouco como uma simples caçada a erros que o questionário

possa ter. Deve ser visto como uma ferramenta destinada aos últimos retoques do

trabalho, confirmando a clareza das instruções, a abrangência das alternativas e

outros detalhes.

As questões que formam o questionário são, em sua maior parte,

dicotômicas, permitindo respostas “Sim” ou “Não” para uma dada pergunta (Sarle,

1995). Essas questões são, basicamente, aquelas que buscam identificar a presença

dos fatores críticos de sucesso no projeto, a partir de perguntas sobre o contexto da

sua realização.

Na maior parte dessas questões, a confirmação da presença de um dos fatores

críticos se dá pela resposta afirmativa “Sim”. Entretanto, para minimizar os efeitos


77

de um possível “viés de aquiescência” (Miller, 1977, p. 382), algumas das questões

estão em sua forma negativa, ou seja, a confirmação da presença de um fator crítico

se dá pela resposta “Não”.

Para as questões relativas ao sucesso do projeto, foi usada uma escala

numérica de 0 a 10, onde o respondente deve, para cada fator de sucesso

perguntado, atribuir-lhe uma nota, sendo 0 a pior e 10 a melhor. A Figura 15

apresenta exemplos das escalas utilizadas.

Sim Não

Os objetivos do projeto eram claros para toda a equipe de projeto? r r

Afirmações ò 0 1 2 3 4 5 6 7 8 9 10

O tempo para execução do projeto foi menor ou igual ao previsto.

r r r r r r r r r r r

Figura 15: Exemplo do uso de escalas no questionário.

UNIVERSO DA PESQUISA

Basicamente, o universo da pesquisa é formado por empresas que estejam

desenvolvendo um projeto para implementação de um pacote de software ERP

(sistema de gestão empresarial), ou tenham encerrado este projeto nos últimos 36

meses (três anos).

O universo da pesquisa não restringe empresas em virtude de tamanho,

faturamento, segmento de negócios, existência de fins lucrativos ou não, entre

outros. Em relação à localização geográfica, a única restrição é que a organização

esteja no Brasil. Como a aplicação de questionários foi feita por correio, a dispersão

geográfica não foi considerada como um fator de restrição para a formação do

universo da pesquisa.

Uma restrição ocorre nas empresas onde o projeto ainda está sendo

implementado. Nesse caso, é imprescindível que algum módulo do mesmo já tenha


78

sido colocado em produção, pois grande parte das questões de pesquisa avaliam o

projeto a partir do pressuposto que o sistema já está em operação parcial ou total.

Apesar do universo da pesquisa ser finito, não existe uma maneira segura e

viável – por razões econômicas e por limitações de tempo – de se identificar todas

as empresas que implementaram ou estão implementando projetos de sistemas ERP.

Uma possível forma (e talvez a única) para a correta identificação dessa população

seria através dos fornecedores de sistemas, que deveriam fornecer sua lista de

clientes completa.

Isso pode não ser muito factível, pois, em uma lista de usuários de um

determinado software, entregue pelo seu fornecedor (caso isso seja possível com

todos os fornecedores), não se pode ter a garantia que a mesma contenha todos os

seus clientes. Isso pode ocorrer por falta de controle do fornecedor ou por esse

desejar que determinados usuários não sejam alvos da pesquisa – apesar de esta não

analisar resultados por software ou por fornecedor separadamente. Particularmente,

podem ficar de fora as empresas nas quais os projetos não tenham tido sucesso.

Um outro aspecto do universo da pesquisa é em relação ao sistema de gestão

empresarial em implementação. A pesquisa não trata de projetos de implementação

de sistemas de uma forma genérica, mas da implementação de pacotes de software,

mais precisamente, sistemas ERP ou sistemas para gestão empresarial.

Como não existe nenhum padrão de classificação que determina quando um

sistema é ou não um sistema ERP – podendo este até mesmo ser somente um

atributo de marketing do produto – somente serão considerados como parte do

universo da pesquisa as empresas que se utilizarem de sistemas notadamente

reconhecidos, na literatura e publicações da área, como softwares ERP.


79

AMOSTRA

Em função das particularidades do universo da pesquisa descrito no item

anterior, foi usada uma amostra de conveniência, extraída a partir de empresas ou

organizações que satisfaziam as restrições da pesquisa, particularmente as que se

mostraram dispostas a participar e a colaborar com o estudo.

A amostragem por conveniência é o “procedimento no qual a conveniência

do pesquisador forma a base para a seleção de uma amostra de unidades”

(Parasuraman, 1991, p. 541; Kinnear & Taylor, 1991, p. 398). Amostragem por

conveniência também pode ser tratada como amostragem intencional (Fonseca &

Martins, 1993, p. 181).

Este é um método de amostragem não-probabilístico, onde diversos

membros da população não tem a chance de ser selecionados, o que limita as

conclusões que podem ser extraídas da pesquisa.

Uma restrição à amostragem por conveniência é que a partir dela não se pode

medir o erro amostral, o que não permite afirmações conclusivas ou definitivas

sobre os resultados da pesquisa sobre a amostra (Kinnear & Taylor, 1991, p. 398).

Entretanto, amostras por conveniência são justificadas em estudos

exploratórios, quando se buscam dados e informações iniciais sobre o assunto, mais

do que generalizações para toda a população, assim como quando se está disposto a

aceitar o risco da falta de acuracidade (Parasuraman, 1991, p. 546). Kinnear e

Taylor também afirmam que amostras por conveniência são bastante usadas em

pesquisas de negócios, aproximadamente por 40% dos pesquisadores (Kinnear &

Taylor, 1991, p. 399).

A amostra utilizada foi formada por um conjunto de 147 empresas, obtidas a

partir de contatos pessoais mantidos pelo próprio autor com empresas que estão

desenvolvendo seus projetos de implementação e com consultores que estão

atuando em projetos. Também auxiliaram na formação da amostra um fornecedor


80

de software ERP e uma empresa de consultoria especializada na implementação de

projetos ERP.

Para as empresas que compuseram a amostra, foram solicitadas respostas de

três participantes do projeto. O primeiro deles, a quem normalmente foi dirigido o

questionário e com que se estabeleceu contato, foi o gerente responsável pelo

projeto, por parte da organização (e não da consultoria, caso essa estivesse

presente). Os outros dois participantes do projeto, aos quais também se solicitavam

respostas, eram os usuários-chave ou os gerentes – ou responsáveis – por setores

onde o projeto já tivesse sido implantando e estivesse em operação.

Essa divisão entre as respostas das áreas técnicas e funcionais foi feita para

buscar um balanceamento e diminuir um possível viés nas respostas somente dos

gerentes de projeto, que poderiam, por exemplo, considerar que a implementação do

sistema foi “mais sucesso” do que o considerariam os usuários.

COLETA DOS DADOS

MAPEAMENTO DO QUESTIONÁRIO

O questionário foi estruturado para levantar as informações necessárias à

comprovação das hipóteses de pesquisa e realização dos objetivos do trabalho. O

mesmo é composto por 67 questões, numeradas seqüencialmente. A seguir, busca-

se apresentar o propósito das questões que formam o questionário em relação aos

objetivos de pesquisa. O questionário encontra-se presente no Anexo 2.


81

IDENTIFICAÇÃO

O quadro inicial permite ao respondente identificar-se e à organização a qual

pertence, bem como seu endereço de correspondência. Isto é particularmente útil se

o mesmo desejar receber os resultados da pesquisa, que lhes serão enviados caso o

mesmo assinale o campo indicado para tal, também presente no quadro inicial.

CARACTERIZAÇÃO DO RESPONDENTE

As questões de n.º 1 a n.º 10 são questões introdutórias, e têm como

objetivos propiciar uma idéia do ambiente de implementação do projeto, permitir a

formação de agrupamentos de respondentes, por exemplo, por tamanho de

organização e ainda filtrar o questionário, para que sejam considerados somente os

que atendem aos requisitos da pesquisa. A seguir, as “questões-filtro” presentes

neste bloco:

• Questão n.º 7 “Qual a data de término do projeto?”: filtra os projetos

muito antigos, pois não foram considerados os projetos encerrados há

mais de 36 meses, portanto, anteriores a julho de 1996.

• Questão n.º 8 “Qual o principal pacote software do projeto?”: filtra os

projetos de implementação de sistemas que não possam ser enquadrados

como de pacotes de software ERP. Foram considerados os softwares

presentes no ranking das 100 maiores empresas de software de

manufatura nos EUA, da Revista Manufacturing Systems de 1998 –

Anexo 3 – onde se encontram os mais significativos ERPs em nível

mundial. Também foram considerados softwares nacionais comumente

encontrados e identificados na bibliografia sobre o assunto com sendo

ERPs, tais como os das empresas Datasul, Logocenter e Microsiga.


82

• Questão n.º 10 “Quais das alternativas abaixo melhor descrevem seu

papel no projeto?”: filtra os respondentes que não se enquadram no

objetivo da pesquisa. Em caso da alternativa “Outros” e uma resposta

aberta, essa seria analisada caso a caso, mas isso não ocorreu em nenhum

questionário. Abaixo os cargos que, eventualmente, invalidaram o

respondente:

§ Diretor ou gerente do projeto, por parte da consultoria;

§ Consultor funcional;

§ Consultor técnico;

§ Programador;

§ Suporte técnico ou suporte de banco de dados.

CARACTERIZAÇÃO DO PROJETO

Nas questões n.º 11 a n.º 13 buscam-se informações sobre os custos do

projeto – em uma estimativa atualizada – para permitir classificações segundo o

volume de recursos envolvidos, bem como a distribuição desses custos entre os

diversos componentes (hardware, software, serviços) do projeto.

Para as questões n.º 14 a n.º 27 solicita-se que o respondente “Marque um ý

nos módulos do sistema previstos no projeto, e um ý na situação atual dos

mesmos.”, sendo fornecida uma lista dos dez módulos de pacotes ERP mais

comuns, enumerados de 14 a 24. De 25 a 27 são espaços em aberto onde podem ser

adicionados três módulos. Essas questões, além de servir como filtro – somente

foram considerados os questionários que tiveram pelo menos um dos módulos do

sistema com a implementação concluída –ainda permite identificar os módulos mais

comumente presentes nos projetos e as dimensões dos mesmos, em relação à sua

abrangência.


83

MOTIVAÇÕES PARA O PROJETO

Identificar as principais motivações para a realização de um projeto ERP é o

objetivo da questão n.º 28. É fornecida uma lista de possíveis motivações – extraída

dentre as mais presentes na bibliografia – que pode ser usada pelo respondente, ou

não, visto que ele pode responder de forma aberta, em até cinco espaços de resposta

fornecidos para tanto. Essa questão, além de identificar as principais motivações do

projeto, indaga ao respondente se as mesmas tiveram seus objetivos atingidos.

DISPOSIÇÃO PARA A MUDANÇA

As questões de n.º 29 a n.º 31 objetivam verificar se a empresa pode ser

considerada como propensa a mudanças – fato que pode influenciar o sucesso do

projeto. Para tanto, são questionadas características da empresa em relação a

pressões externas, bem com sobre outros projetos não característicos da área de

Tecnologia da Informação. A questão n.º 30 é uma questão invertida.


As questões de n.º 32 a n.º 45 buscam identificar a presença dos fatores

críticos de sucesso usados na pesquisa. São usadas catorze questões para testar os

fatores, sendo duas por fator. Abaixo, a relação das questões, com os respectivos

fatores críticos a serem identificados:

• Fator “Missões claras e definidas”:

§ Questão n.º 32

§ Questão n.º 33 (invertida)

• Fator “Apoio da alta administração”:


84

§ Questão n.º 34

§ Questão n.º 35

• Fator “Usuários capazes e envolvidos”:

§ Questão n.º 36

§ Questão n.º 37

• Fator “Planejamento detalhado do projeto”:

§ Questão n.º 38


• Fator “Gerente de projeto com habilidades necessárias”:

§ Questão n.º 40


• Fator “Presença de consultoria externa”:

§ Questão n.º 42

§ Questão n.º 43

• Fator “Mudança nos processos de negócios”:



As questões n.º 46 a n.º 52 realizam um cruzamento entre os sete fatores

críticos de sucesso – do conjunto de questões anterior – em relação às quatro fases

do ciclo de vida do projeto, para buscar informações sobre a importância de cada

fator crítico para cada fase do ciclo de vida. A seguir, as fases do ciclo de vida

testadas em cada questão:


85

• Questão n.º 46: Fator “Missões claras e definidas”;

• Questão n.º 47: Fator “Apoio da alta administração”;

• Questão n.º 48: Fator “Usuários capazes e envolvidos”;

• Questão n.º 49: Fator “Planejamento detalhado do projeto”;

• Questão n.º 50: Fator “Gerente de projeto com habilidades necessárias”;

• Questão n.º 51: Fator “Presença de consultoria externa”;

• Questão n.º 52: Fator “Mudança nos processos de negócios”.

ADOÇÃO DE TECNOLOGIA

As questões n.º 53 a n.º 56, tentam identificar o níve l de adoção de

tecnologia ocorrido no projeto. A seguir, as questões em relação aos níveis de

adoção de tecnologia considerados:

• Questão n.º 53: Nível de “Adoção”

• Questões n.º 55: Nível de “Uso”

• Questão n.º 54 e n.º 56: Nível de “Incorporação”

SUCESSO DO PROJETO

As questões n.º 57 a n.º 60 perguntam sobre o sucesso do projeto, em relação

aos aspectos em análise. O objetivo destas questões é identificar, no conceito do

respondente, qual o grau de sucesso do projeto. Nessa questão é usada a escala de

notas de 0 a 10 mostrada anteriormente na Figura 15. A seguir, o detalhamento

dessas questões em relação aos aspectos de sucesso do projeto analisados.


86

• Questão n.º 57: Aderência ao cronograma;

• Questão n.º 58: Aderência ao orçamento;

• Questão n.º 59: Nível de desempenho atingido e qualidade;

• Questão n.º 60: Efetividade organizacional.

COLOCAÇÃO DO SISTEMA EM PRODUÇÃO

A questão n.º 61 “Quais das alternativas abaixo melhor descrevem a

estratégia usada para a colocação do sistema em produção?” além de fornecer uma

visão sobre os métodos usados para colocação dos sistemas em produção ainda

verifica se o questionário deve ser descartado caso o projeto ainda não tenha

passado por nenhum processo de “entrada em produção”.

SATISFAÇÃO COM A INFORMÁTICA

Finalmente, as questões n.º 62 a n.º 67 questionam sobre a situação dos

sistemas e da informática – em relação ao grau de satisfação do usuário – existentes

na organização antes da implementação do pacote de gestão empresarial. A questão

n.º 65 também é uma questão invertida.

APLICAÇÃO DO QUESTIONÁRIO

Para a aplicação do questionário, inicialmente foi desenvolvido o trabalho de

preparação dos dados e contato com a amostra. Como para a maioria das empresas

que formavam a amostra estavam disponíveis somente o telefone ou e-mail do

contato – normalmente o gerente de projeto ou gerente de informática – foi


87

necessário ligar (ou enviar uma mensagem eletrônica) para essas empresas e obter

os endereços de correspondência e confirmar os nomes dos contatos.

Ainda, antes do envio, foi feito, com um grande número de empresas, um

pedido de participação via telefone, onde – quando era possível contato com o

próprio respondente ou sua secretária – explicava-se a importância do estudo,

ressaltava-se o caráter de sigilo e enfatizava-se o envio de um sumário executivo

com os resultados da pesquisa.

Foram enviados questionários para um total de 147 empresas, no período de

abril a junho de 1999. Eles não foram todos ao mesmo tempo, pois à medida que

eram obtidos e confirmados novos contatos, esses questionários eram enviados.

Foram considerados os questionários recebidos até o dia 3 de julho de 1999.

O envio foi feito em um envelope timbrado da FIA/USP, nominal ao contato

na empresa. Dentro, estavam três conjuntos para resposta, cada qual contendo uma

carta de apresentação, um questionário e um envelope já selado e preenchido para

ser usado como envelope-resposta. A carta – Anexo 1 – solicitava que o

respondente preenchesse um questionário e enviasse os restantes para dois usuários

do sistema.

O retorno dos questionários se deu para uma caixa postal, alugada

especificamente para esse fim. Esse procedimento visou a garantir que os

questionários postados pelos respondentes fossem todos recebidos, diminuindo-se o

risco de extravios.

O desenvolvimento de um follow-up com os respondentes é apontado por

Miller (1977, p. 77) como capaz de aumentar em 50% a taxa de retorno em

questionários. Portanto, após o envio, caso o questionário não retornasse em 7 dias,

se estabelecia um contato telefônico com a empresa para confirmar o recebimento e

perguntar se havia “alguma dúvida ou ajuda que pudesse ser prestada”. Caso ainda

assim não houvesse o retorno, o mesmo procedimento era executado mais uma vez


88

ou duas vezes (dependendo do caso) e, por fim, abandonado, assumindo-se que não

haveria retorno.

Das 147 empresas para as quais foram enviados questionários, 43 retornaram

pelo menos um questionário válido – normalmente o do contato estabelecido – o

que representa uma taxa de resposta de aproximadamente 29,25%, a qual pode ser

considerada bastante significativa, utilizando-se questionários por correio, visto que

as taxas de retorno oscilam entre 3% e 50% (Mattar, 1996, p. 73; Miller, 1977, p.

79).

Das 43 empresas que retornaram envelopes-resposta, foram recebidos 45

questionários de “gerente ou diretor de projeto” (observa-se, que em alguns casos,

para uma mesma empresa, mais de uma pessoa se identificou como “gerente de

projeto”) e 22 questionários de “usuário-chave, usuário final ou membro do comitê

de projeto”, totalizando 67 questionários válidos. Foram ainda descartados 7

questionários por não atenderem algum dos requisitos nas questões filtro ou terem

retornado após o esgotamento do prazo final.

TRATAMENTO E PROCESSAMENTO ESTATÍSTICO DE DADOS

Os dados foram sendo tabulados e digitados em planilhas usando o software

Microsoft Excel, à medida que os questionários foram sendo recebidos.

Posteriormente, utilizou-se o software SPSS v.8.0 para os processamentos

estatísticos e confecção dos gráficos.


89

SUMÁRIO

Este capítulo discute o modelo teórico de pesquisa, bem como as hipóteses

presentes no mesmo. São ainda apresentadas as variáveis definidas e utilizadas na

pesquisa. Também é discutido o método survey utilizado na pesquisa, bem como o

uso de questionários como instrumento da coleta de dados.

O capítulo traz, ainda, o universo da pesquisa e a formação de uma amostra

de conveniência para a aplicação dos questionários.

Em relação ao questionário, é apresentada sua estrutura e a relação entre as

questões do mesmo e os objetivos da pesquisa. Finalmente, são descritos os

procedimentos utilizados para aplicação do questionário.

90

Capítulo 4

ANÁLISE DE DADOS

INTRODUÇÃO

Uma vez tabulados, os dados obtidos a partir da coleta foram analisados para

tentar cumprir com os objetivos da pesquisa. O processo de análise de dados foi

dividido em 3 dimensões distintas:

• A primeira dimensão se caracteriza por uma análise descritiva, onde o

objetivo é fornecer uma visão geral dos projetos de implementação de

sistemas ERP, com os seus participantes, custos, duração, entre outros.

Os dados foram agrupados em tabelas que permitiram uma análise

descritiva das respectivas freqüências observadas, bem como alguns

testes de proporção. No Anexo 4, encontram-se as listagens com as

tabelas de freqüência e outros dados relevantes obtidos a partir do SPSS.

• A segunda dimensão é caracterizada pelo teste das hipóteses propostas,

que buscam prováveis relações entre fatores críticos e o sucesso dos

projetos, assim como outras, todas descritas no Capítulo 3. Os resultados

obtidos a partir do SPSS estão no Anexo 5.

• A terceira é formada por uma análise exploratória dos dados obtidos com

a pesquisa e procura explorar alguns relacionamentos existentes entres os

dados levantados. No Anexo 6 encontram-se o resultados completos.

CAPÍTULO 4: ANÁLISE DE DADOS

91

ANÁLISE DESCRITIVA

COMPOSIÇÃO DA AMOSTRA

Participaram da amostra 43 empresas, com, pelo menos, um questionário

cada. Dessas empresas, algumas participaram com mais de um questionário

respondido, motivo pelo qual existem mais questionários do que empresas.

Os respondentes, de acordo com o cargo indicado na questão n.º 10, foram

separados em 2 categorias: gerentes de projeto e usuários. Na primeira categoria –

gerentes – ficaram os respondentes associados à gerência do projeto, identificados

pelos cargos de: diretor do projeto; gerente, coordenador ou responsável da empresa

pelo projeto. Na segunda categoria – usuários – ficaram os usuários-chave, usuários

finais e membros do comitê de projeto. A seguir, as distribuições de freqüência.

Tipo do respondente Freqüência Gerente 45 Usuário 22 Total 67 Tabela 1: Número de participantes da amostra

CARACTERÍSTICAS DAS EMPRESAS

As empresas participantes foram caracterizadas pelo seu segmento de

atuação e pelo seu tamanho, sendo este baseado no valor do faturamento anual e no

número de funcionários. Em relação ao segmento de atuação, como se tratava de

uma amostra de conveniência, não sendo escolhido um setor específico, ocorreu

uma grande dispersão entre setores.


92

FATURAMENTO ANUAL

O faturamento anual, em milhões de R$, foi identificado na forma de faixas,

para as quais estão apresentadas a seguir as respectivas freqüências. Observa-se

uma distribuição significativa da amostra em todas as faixas, destacando-se a

participação de empresas com faturamento superior a R$ 300 milhões, que

representaram 39,5% da amostra.

Faturamento anual (milhões R$) Freqüência % Válido % Acumulado <= 20 5 11,6 11,6

21 - 70 7 16,3 27,9 71 - 150 7 16,3 44,2

151 - 300 7 16,3 60,5 > 300 17 39,5 100,0 Total 43 100,0

Tabela 2: Faturamento anual (milhões R$) das empresas da amostra

39,5%

16,3%

16,3%

16,3%

11,6%

> 300

151 - 300

71 - 150

21 - 70

<= 20

Figura 16: Distribuição das empresas segundo o faturamento anual (milhões R$)

NÚMERO DE FUNCIONÁRIOS

Em relação ao número de funcionários, a distribuição também é bastante

equilibrada a partir da faixa inicial – até 100 funcionários – que representa somente

4,7%.


93

Número de funcionários Freqüência % Válido % Acumulado <= 100 2 4,7 4,7

101 – 500 10 23,3 27,9 501 – 1000 8 18,6 46,5

1001 – 3000 11 25,6 72,1 > 3000 12 27,9 100,0 Total 43 100,0

Tabela 3: Número de funcionários das empresas da amostra

27,9%

25,6%

18,6%

23,3%

4,7%

> 3000

1001 - 3000

501 - 1000

101 - 500

<= 100

Figura 17: Distribuição das empresas segundo o número de funcionários

SEGMENTOS

Em relação aos segmentos, como já observado acima, a amostra por

conveniência provocou uma grande dispersão entre os mais diversos segmentos de

atuação. A tabela de freqüências abaixo ilustra esta distribuição.

Segmento de atuação Freqüência % Válido % Acumulado Administradora saúde 1 2,3 2,3 Alimentos 8 18,6 20,9 Autopeças 3 7,0 27,9 Cerâmico 1 2,3 30,2 Construção 1 2,3 32,6 Distribuição bens 1 2,3 34,9 Distribuição gás 1 2,3 37,2 Eletro-eletrônico 2 4,7 41,9 Eletrônico 1 2,3 44,2 Elevadores 1 2,3 46,5 Embalagens 1 2,3 48,8 Gráfica 3 7,0 55,8 Informática 1 2,3 58,1


94

Material construção 1 2,3 60,5 Metal-mecânica 2 4,7 65,1 Metalúrgico 3 7,0 72,1 Montadora 1 2,3 74,4 Móveis 1 2,3 76,7 Papel e celulose 1 2,3 79,1 Químico 2 4,7 83,7 Serviços 1 2,3 86,0 Siderurgia 1 2,3 88,4 Sucro-alcooleiro 2 4,7 93,0 Telecomunicações 1 2,3 95,3 Têxtil automotivo 1 2,3 97,7 Transportes 1 2,3 100,0 Total 43 100,0 Tabela 4: Segmento de atuação das empresas da amostra

CARACTERÍSTICAS DOS PROJETOS

Os projetos tiveram diversos de seus aspectos identificados e apresentados a

seguir, o que, se espera, forneça uma caracterização adequada dos projetos

implementados ou em implementação pelas empresas que participaram da pesquisa.

Foram analisadas características de: tamanho de equipe; valores envolvidos no

projeto; duração; e método de entrada em produção do sistema.

TAMANHO DA EQUIPE DE PROJETO

A seguir, a distribuição de freqüência da formação da equipe de projeto, em

relação ao número de funcionários alocados na mesma, excluindo-se consultores

externos que, porventura, participassem da mesma. Destaca-se, com 30,2%, as

equipes de tamanho intermediário, entre 11 e 20 funcionários, sendo seguidas pelas

pequenas equipes, com menos de 5 funcionários, que representaram 25,6%.

Tamanho da equipe Freqüência % Válido % Acumulado < 5 11 25,6 25,6

5 - 10 7 16,3 41,9 11 - 20 13 30,2 72,1 21 - 50 8 18,6 90,7

51 - 100 4 9,3 100,0 Total 43 100,0

Tabela 5: Tamanho da equipe nos projetos da amostra


95

9,3%

18,6%

30,2%

16,3%

25,6%

51 - 100

21 - 50

11 - 20

5 - 10

< 5

Figura 18: Distribuição das empresas segundo o tamanho da equipe de projeto

TEMPO DE DURAÇÃO DE PROJETO

Os tempos de duração dos projetos, em meses, são mostrados a seguir. Deve-

se observar o fato de que, apesar de, normalmente serem identificados como

projetos de longa duração, 64,1% tiveram prazo de até 1,5 anos (18 meses) e 79,5%

prazo de até 2 anos (24 meses). Os projetos mais longos, superiores a 4 anos (48

meses) foram somente 7,7%. O tempo médio de duração dos projetos foi de 21,1

meses. Cabe lembrar, no entanto, que podem existir projetos ERP dos mais diversos

portes. A pesquisa não discriminou, por exemplo, projetos que tiveram sua

implementação em mais de uma planta (ou fábrica). As tabelas a seguir mostram a

distribuição de freqüência e a média dos projetos.

Tempo de duração (m) Freqüência % Válido % Acumulado <= 12 11 28,2 28,2

13 - 18 14 35,9 64,1 19 - 24 6 15,4 79,5 25 - 36 3 7,7 87,2 37 - 48 2 5,1 92,3

> 48 3 7,7 100,0 Total 39 100,0

Tabela 6: Tempo de duração (meses) nos projetos da amostra


96

N

Mínimo

Máximo

Média

Desvio Padrão

Tempo de duração (m) 39 6 110 21,10 18,27 Tabela 7: Duração média dos projetos

7,7%

5,1%

7,7%

15,4%

35,9%

28,2%

> 48

37 - 48

25 - 36

19 - 24

13 - 18

<= 12

Figura 19: Tempo de duração (meses) dos projetos da amostra

MÓDULOS IMPLEMENTADOS

Em relação aos módulos implementados, o questionário propunha uma lista

com os módulos mais comumente encontrados nos principais sistemas ERP. Além

disso, ainda havia a possibilidade de uma resposta aberta, acrescentando-se outros

módulos, que estiveram presentes em 25,6% das empresas, sem destaque em

especial para alguma resposta especificamente. Os módulos com maior presença são

o módulo financeiro, de compras, contábil e industrial, com 83,7%, 83,7%, 79,1% e

72,1% de presença nas empresas, respectivamente. Cabe ressaltar que, por não

haver uma distinção entre segmentos empresarias na formação da amostra, alguns

módulos podem ter tido sua análise prejudicada. O módulo industrial, por exemplo,

poderia ter maior representatividade, caso a amostra considerasse somente empresas

do setor industrial.


97

Módulos Freqüência % Empresas Financeiro 36 83,7 Compras 36 83,7 Contábil 34 79,1 Industrial 31 72,1 Vendas 29 67,4 RH 16 37,2 Projetos 13 30,2 Outros 11 25,6 Manutenção 10 23,3 Marketing 7 16,3 Transporte 7 16,3 Serviços 5 11,6 Total 235 Tabela 8: Módulos implementados nos projetos da amostra

Módulos

Serviços

Transporte

Marketing

Manutenção

OutrosProjetos

RHVendas

Industrial

Contábil

Compras

Financeiro

Fre

qüên

cia

40

30

20

10

0

Figura 20: Módulos implementados nos projetos da amostra

VALOR DO PROJETO

O valor do projeto, apresentado a seguir em milhões de R$, foi informado

pelos respondentes seguindo faixas pré-determinadas. Os valores ficaram

distribuídos em todas as faixas, sendo os destaques para os projetos menores, até R$

500 mil, que representaram 29,4% dos casos, e para a presença de grandes projetos,

com valores superiores a R$ 10 milhões, com 11,8% do casos. Também é mostrado

a seguir a formação obtida para os custos do projeto, em relação aos componentes

de hardware, software e serviços. Este último é o mais representativo de todos - o


98

que é condizente com a literatura a respeito – sendo responsável, segundo a amostra

em questão, por 41,6% do valor total do projeto. Em seguida, está o custo de

hardware com 31,6% e, finalmente, o custo de software, com 26,8%. A seguir as

distribuições de freqüência obtidas.

Valor do projeto (milhões R$) Freqüência % Válido % Acumulado <= 0,5 10 29,4 29,4

0,6 - 1,0 6 17,6 47,1 1,1 - 1,5 4 11,8 58,8 1,6 - 2,0 3 8,8 67,6 2,1 - 4,0 5 14,7 82,4

4,1 - 10,0 2 5,9 88,2 > 10,0 4 11,8 100,0 Total 34 100,0

Tabela 9: Valor dos projetos da amostra (milhões R$)

11,8%

5,9%

14,7%

8,8%

11,8%

17,6%

29,4%

> 10,0

4,1 - 10,0

2,1 - 4,0

1,6 - 2,0

1,1 - 1,5

0,6 - 1,0

<= 0,5

Figura 21: Valor dos projetos da amostra (milhões R$)

A distribuição dos custos do projeto entre seus principais componentes:

hardware, software e serviços, é apresentada de diversas formas na literatura sobre

o assunto. Na amostra analisada, a distribuição desses valores para a formação do

custo final do projeto foi a seguinte: hardware com 31,6%; software com 26,8%; e

serviços com 41,6%. O que é consistente com a literatura, é a maior participação do

custo de serviços na formação do valor total do projeto. A seguir, esses custos estão

representados graficamente.


99

41,6%

26,8%

31,6%

Valor serviços

Valor software

Valor hardware

Figura 22: Distribuição de valores dos projetos da amostra, em seus componentes

Foi realizada uma comparação entre os valores médios de projeto em relação

ao porte das empresas – considerando-se número de funcionários e valor do

faturamento anual. Os resultados, apresentados de forma gráfica a seguir, mostram

o que já era esperado, ou seja, as maiores organizações gastam mais em seus

projetos do que as menores.

Faturamento anual (milhões R$)

> 300151 - 30071 - 15021 - 70<= 20

Méd

ia (m

il R

$)

6000

5000

4000

3000

2000

1000

0

Valor hardware

Valor software

Valor serviços

Valor do projeto

Figura 23: Gráfico do faturamento anual x valores de projeto


100

Número de funcionários

> 30001001 - 3000501 - 1000101 - 500

Méd

ia (m

il R

$)

6000

5000

4000

3000

2000

1000

0

Valor hardware

Valor software

Valor serviços

Valor do projeto

Figura 24: Gráfico do número de funcionários x valores de projeto

PACOTES DE SOFTWARE NA AMOSTRA

Diversos pacotes de software formaram a amostra em estudo, pois, como a

pesquisa não se prendeu a um determinado fornecedor/pacote, ocorreu uma grande

diversidade entre os participantes. Ainda, como a pesquisa não estabelece

comparações entre os resultados obtidos entre cada pacote de software, a relação a

seguir serve somente para ilustrar a diversidade obtida e apresentar os ERPs cujos

projetos foram analisados. A tabela abaixo mostra o fornecedor do pacote utilizado,

sendo, normalmente, o nome do pacote de software associado ao nome do

fornecedor.

Fornecedor do pacote Freqüência % Válido % Acumulado Baan 17 39,5 39,5 SAP 9 20,9 60,5 Microsiga 8 18,6 79,1 Datasul 4 9,3 88,4 Oracle 3 7,0 95,3 Marcam 2 4,7 100,0 Total 43 100,0 Tabela 10: Fornecedores de software dos projetos da amostra


101

ENTRADA EM PRODUÇÃO DO PROJETO

O método utilizado para a entrada em produção do projeto foi outra das

características dos projetos analisadas. Havia a possibilidade de múltipla escolha

entre: big bang, ou conversão direta; conversão em fases ou parcial; e conversão em

paralelo. Diversas respostas apontaram conversões dos tipos big bang e fases com a

opção em paralelo. A seguir, são apresentadas as distribuições de freqüência

obtidas, sendo mostrado no próximo item uma análise mais detalhada sobre o

método big bang.

Tipo de entrada em produção Freqüência % Válido % Acumulado Big bang 15 37,5 37,5 Fases 15 37,5 75,0 Paralelo 1 2,5 77,5 Big bang + paralelo 1 2,5 80,0 Fases + paralelo 8 20,0 100,0 Total 40 100,0 Tabela 11: Tipos de entrada em produção dos projetos da amostra

Tipo de entrada em produção

Fases + paralelo

Big bang + paralelo

Paralelo

Fases

Big bang

N. C

asos

16

14

12

10

8

6

4

2

0

Figura 25: Tipos de entrada em produção dos projetos da amostra


102

ENTRADA EM PRODUÇÃO “BIG BANG”

O método big bang, quando todo o sistema é colocado em produção em um

só momento, é apresentado como um tanto quanto arriscado (vide Capítulo 2), daí

sua alta presença nas respostas sugerir uma análise. Das respostas originais, foram

considerados somente os métodos big bang e fases, independentemente dos mesmos

serem em paralelo ou não – conforme apresentado no item anterior. Desta forma, o

método big bang apareceu um 41% dos casos. Especulando-se que tal fato poderia

estar ocorrendo somente em projetos de menor porte, onde, supõem-se, seja mais

fácil fazer uma implantação única com todo o sistema de uma única vez, efetuou-se

um cruzamento entre os projetos que tiveram um método big bang e o tamanho do

projeto, em relação ao seu valor. O resultado observado (mostrado a seguir)

apresenta um distribuição equilibrada deste método em todas as faixas de valor,

atingindo 23,1% nos projetos acima de R$ 10 milhões, o que parece mostrar que o

método realmente é bastante utilizado (apesar da conversão em fases o ser mais),

independentemente do tamanho do projeto. A seguir, as freqüências obtidas.

Tipo de entrada em produção Freqüência % Válido % Acumulado Big bang 16 41,0 41,0 Fases 23 59,0 100,0 Total 39 100,0 Tabela 12: Tipo de entrada em produção “big bang”

59,0%

41,0%

Fases

Big bang

Figura 26: Tipo de entrada em produção “big bang”


103

Valor do projeto (milhões R$) Total <= 0,5 0,6 - 1,0 1,1 - 1,5 1,6 - 2,0 2,1 - 4,0 > 10,0 Big bang 15,4% 23,1% 15,4% 7,7% 15,4% 23,1% 100,0% Tabela 13: Tipo de entrada “big bang” x valor do projeto (milhões R$)

23,1%

15,4%

7,7%15,4%

23,1%

15,4%> 10,0

2,1 - 4,0

1,6 - 2,01,1 - 1,5

0,6 - 1,0

<= 0,5

Figura 27: Tipo de entrada “big bang” x valor do projeto (milhões R$)


Identificar as motivações que levaram as organizações a iniciar a

implementação de um software ERP é um dos objetivos da pesquisa, descrito no

Capítulo 1. O questionário apresentava ao respondente uma lista com 11 motivações

freqüentemente encontradas na literatura sobre o assunto (vide Capítulo 2), como

responsáveis pela decisão de iniciar um projeto ERP. Além disso, havia espaço

reservado para respostas abertas, caso a lista fornecida não possuísse alguma das

motivações desejadas pelo respondente – o que não ocorreu.

Os tópicos a seguir apresentam essas motivações juntamente com suas

distribuições de freqüência obtidas. Nessa questão, as respostas são apresentadas

separadamente de acordo com o grupo do respondentes – gerente de projeto ou


104

usuário – pois se considerou que as opiniões poderiam variar em função do papel

representado por cada um no projeto.

Finalmente, foi realizado um teste de proporção, que testa a diferença entre

duas proporções populacionais (Fonseca & Martins, 1993, p. 210; Costa, 1977, p.

118; Stevenson, 1981, p. 276; ) para verificar se as motivações apresentadas haviam

tido seus objetivos atingidos ou não.

MOTIVAÇÕES DOS GERENTES DE PROJETO

Dentre os gerentes de projeto que responderam esta questão, as principais

motivações apresentadas pelos mesmos dizem respeito à integração de informações

(100% dos gerentes apresentaram esta motivação) e à necessidade de informações

gerenciais (95,5%), com percentuais muito expressivos. O problema do bug do

milênio – um problema técnico – aparece em terceiro lugar, com 68,2%.

Tipo motivação gerentes Freqüência % Gerentes Integração de informações 44 100,0 Necessidade de informações gerenciais 42 95,5 Ano 2000 30 68,2 Busca de vantagem competitiva 29 65,9 Evolução da arquitetura de informática 28 63,6 Redesenho de processos 25 56,8 Redução de pessoal 16 36,4 Globalização de negócios 15 34,1 Determinação da matriz 12 27,3 Indicação por empresa de consultoria 5 11,4 Pressão de parc eiros 4 9,1 Total 250 Tabela 14: Motivações para o projeto, na visão dos gerentes de projeto

O teste de proporção, mostrado abaixo, indica que o que motivou a

realização do projeto teve seus objetivos atingidos. A proporção de 85% é altamente

significativa, como indicado pela aproximação de Z na tabela abaixo.


105

Categoria N Prop. Observada Teste Proporção Significância bicaudal) Motivação gerentes Atingida 213 ,85 ,50 ,000a

Não atingida 37 ,15 Total 250 1,00a Baseado na aproximação de Z. Tabela 15: Teste de proporção das motivações, na visão dos gerentes de projeto

Os gráficos a seguir representam as motivações e a proporção atingida,

mostrados nas tabelas acima.

Tipo motivação gerentes

Pressão de parceiros

Indicação por empres

Determinação da matr

Globalização de negó

Redução de pessoal

Redesenho de process

Evolução da arquitet

Busca de vantagem co

Ano 2000

Necessidade de infor

Integração de inform

Fre

qüên

cia

50

40

30

20

10

0

Figura 28: Motivações para o projeto, na visão dos gerentes de projeto

14,8%

85,2%

Não atingida

Atingida

Figura 29: Proporção das motivações atingidas, na visão dos gerentes de projeto


106

MOTIVAÇÕES DOS USUÁRIOS

As motivações dos usuários, basicamente não diferiram de maneira

significativa das apresentadas pelos gerentes de projeto, o que pode, talvez,

evidenciar uma sintonia no aspecto de comunicação sobre o projeto. As principais

motivações também são a integração de informações e a busca de vantagem

competitiva, que aparecem em 100% e 90,9% das respostas. O destaque pode ser

dado ao bug do milênio, que possui uma importância maior junto aos gerentes de

projeto (68,2%) do que junto aos usuários (59,1%), e também à motivação de busca

de vantagem competitiva (90,9%), que é consideravelmente maior junto aos

usuários que aos gerentes de projeto (65,9%).

Tipo motivação usuários Freqüência % Usuários Integração de informações 22 100,0 Busca de vantagem competitiva 20 90,9 Necessidade de informações gerenciais 19 86,4 Ano 2000 13 59,1 Redesenho de processos 12 54,5 Determinação da matriz 10 45,5 Evolução da arquitetura de informática 10 45,5 Redução de pessoal 8 36,4 Globalização de negócios 8 36,4 Indicação por empresa de consultoria 3 13,6 Total 125 Tabela 16: Motivações para o projeto, na visão dos usuários

O teste de proporção efetuado para as respostas dos usuários indicou que as

motivações para a realização do projeto tiveram seus objetivos atingidos, com uma

proporção de 82%, que é altamente significativa, como indicado pela aproximação

de Z na tabela abaixo.

Categoria N Proporção Observada

Teste de Proporção

Significância (bicaudal)

Motivação usuários Atingida 103 ,82 ,50 ,000a

Não atingida 22 ,18 Total 125 1,00 a Baseado na aproximação de Z. Tabela 17: Teste de proporção das motivações, na visão dos usuários


107

Os gráficos a seguir reproduzem os dados acima, com as motivações para o

projeto e a proporção de motivações atingidas.

Tipo motivação usuários

Indicação por empres

Globalização de negó

Redução de pessoal

Evolução da arquitet

Determinação da matr

Redesenho de process

Ano 2000

Necessidade de infor

Busca de vantagem co

Integração de inform

Fre

qüên

cia

30

20

10

0

Figura 30: Motivações dos usuários do projeto

17,6%

82,4%

Não atingida

Atingida

Figura 31: Proporção das motivações atingidas, na visão dos usuários


108

FATORES CRÍTICOS DE SUCESSO NAS FASES DO PROJETO

Em relação aos fatores críticos de sucesso, apresentados no Capítulo 2, foi

perguntado aos usuários sobre a importância do mesmo nas várias fases do projeto:

conceituação; planejamento; execução; e encerramento. A fase 1 é a escolha do

software e a decisão de implementá-lo; na fase 2, está a criação do plano de

implementação do projeto; na fase 3, a simulação de processos, modelagem de

dados e processos, desenvolvimento de interfaces e customizações; e na fase 4, a

parametrização do sistema, treinamento do usuário final e colocação do sistema em

produção.

Os fatores críticos analisados foram: missões claras e definidas; apoio da alta

administração; usuários capazes e envolvidos; planejamento detalhado do projeto;

gerente de projeto com habilidades necessárias; presença de consultoria externa; e

mudança nos processos de negócios.

Os fatores foram pontuados pelos respondentes de acordo com a importância

dada pelo mesmo em determinada fase. Nos resultados, quanto mais importante um

fator, maior é sua pontuação. Uma pontuação baixa, nesta análise, não indica que o

mesmo não é crítico para o sucesso do projeto, mas somente que ele pode não ser

um dos mais importantes.

As respostas estão tabuladas separadamente, de acordo com o grupo

respondente – gerentes de projeto ou usuários – e de acordo com a fase do projeto.

FATORES CRÍTICOS PARA OS GERENTES DE PROJETO

Para os gerentes de projeto, a presença de consultoria externa é o mais

importante na fase de escolha do software, seguido pelo apoio da alta administração

e pela existência de missões claras e definidas.


109

O apoio da alta administração também se mostra significativo nas próximas

duas fases, somente deixando de ser tão importante no momento da colocação do

sistema em produção – fase 4 – quando a consultoria externa, por sua vez, o item

mais importante na fase 1, volta a ter uma importância significativa, possivelmente

pela necessidade de treinamento de usuário e parametrização do sistema.

De maneira interessante, os gerentes de projeto consideram que a presença

de usuários capazes e envolvidos não é um dos itens mais significativos durante o

decorrer de todo o projeto, figurando como o último da lista durante três fases. De

forma semelhante, o planejamento detalhado do projeto aparece freqüentemente

como um dos itens de menor importância em todas as fases do projeto.

Por sua vez, a presença de um gerente de projeto, com as habilidades

necessárias, surge como o item mais importante nas fases 3 e 4, notadamente com

maior envolvimento operacional. Quanto ao aspecto da mudança de processos, este

surge com uma importância intermediária, mantendo-se assim durante todas as

fases.

Pinto & Slevin (1988b) desenvolveram uma pesquisa com um grupo de

gerentes de projeto e, apesar de diferenças entre os objetivos e características da

mesma com esse trabalho, alguns pontos em comum puderam ser observados. Por

exemplo, na fase 2 – planejamento – os gerentes de projeto em ambas as pesquisas

apontaram dois fatores – que eram comuns às pesquisas – como os mais

importantes: a necessidade de missões claras e definidas, sendo seguido pelo apoio

da alta administração.

Também surgiram semelhanças na fase 3 – execução – onde a presença de

gerente de projeto com habilidades necessárias recebeu um grande destaque

(segundo fator mais importante). A principal diferença ficou por conta do fator

“missões claras e definidas” que foi apresentada nos resultados da outra pesquisa

como o fator mais importante também nas fases 1 e 2 – conceituação e

planejamento.


110

A seguir, estão as tabelas e os gráficos de cada fase com os fatores e suas

pontuações.

Fatores Fase1 Fase2 Fase3 Fase4 1-Missões claras e definidas 720 1180 900 750 2-Apoio da alta administração 1060 1050 960 740 3-Usuários capazes e envolvidos 640 450 620 630 4-Planejamento detalhado do projeto 480 630 760 720 5-Gerente de projeto c/ habilidades necessárias 630 640 1100 1060 6-Presença de consultoria externa 1170 910 720 900 7-Mudança nos processos de negócios 650 920 880 920 Tabela 18: Fatores críticos, em cada fase do projeto, para os gerentes

Planej. detalhado

Ger. proj. c/ habil.

Usuários capazes

Mudança processos

Missões claras e def

Apoio alta adm.

Consultoria externa

Pon

tos

na F

ase

1

1200

1000

800

600

400

200Usuários capazes

Planej. detalhado


Consultoria externa

Mudança processos

Apoio alta adm.


Pon

tos

na F

ase

2

1200

1000

800

600

400

200

Figura 32: Fatores críticos na fase 1, para os gerentes Figura 33: Fatores críticos na fase 2, para os gerentes

Usuários capazes

Consultoria externa

Planej. detalhado

Mudança processos


Apoio alta adm.


Pon

tos

na F

ase

3

1200

1100

1000

900

800

700

600


Planej. detalhado

Apoio alta adm.


Consultoria externa

Mudança processos


Pon

tos

na F

ase

4

1200

1100

1000

900

800

700

600

500

Figura 34: Fatores críticos na fase 3, para os gerentes Figura 35: Fatores críticos na fase 4, para os gerentes


111

FATORES CRÍTICOS PARA OS USUÁRIOS

De maneira geral, os resultados obtidos com o grupo dos usuários é

semelhante ao grupo dos gerentes de projeto. Essa semelhança ocorre inclusive em

relação ao fator usuários capazes, que também neste grupo foi considerado como de

baixa importância durante todas as fases do projeto.

O aspecto que difere mais significativamente é o da mudança de processos,

que se mostra muito importante (é o primeiro da lista) para o grupo dos usuários,

nas fases 3 e 4, o que não acontece no grupo dos gerentes de projeto. Outra

diferença é o apoio da alta administração, nestas mesmas fases, que não é

considerado importante.

Fatores Fase1 Fase2 Fase3 Fase4 1-Missões claras e definidas 170 350 130 120 2-Apoio da alta administração 270 240 80 200 3-Usuários capazes e envolvidos 160 90 120 340 4-Planejamento detalhado do projeto 150 130 190 130 5-Gerente de projeto c/ habilidades necessárias 170 170 360 360 6-Presença de consultoria externa 390 190 190 240 7-Mudança nos processos de negócios 210 320 390 100 Tabela 19: Fatores críticos, em cada fase, para os usuários

Planej. detalhado

Usuários capazes



Mudança processos

Apoio alta adm.

Consultoria externa

Pon

tos

na F

ase

1

500

400

300

200


Planej. detalhado


Consultoria externa

Apoio alta adm.

Mudança processos


Pon

tos

na F

ase

2

500

400

300

200

100

0

Figura 36: Fatores críticos na fase 1, para os usuários Figura 37: Fatores críticos na fase 2, para os usuários


112

Apoio alta adm.

Usuários capazes


Consultoria externa

Planej. detalhado


Mudança processos

Pon

tos

na F

ase

3

500

400

300

200

100

0Usuários capazes

Apoio alta adm.


Consultoria externa

Planej. detalhado


Mudança processos

Pon

tos

na F

ase

4

500

400

300

200

100

0

Figura 38: Fatores críticos na fase 3, para os usuários Figura 39: Fatores críticos na fase 4, para os usuários

TESTE DE HIPÓTESES

A primeira hipótese diz respeito às motivações para a realização de projetos

ERP, mais precisamente, se as mesmas têm seus objetivos atingidos.

Da segunda à sétima hipótese, são tratadas as relações entre os fatores

críticos e o sucesso do projeto.

A oitava e nona hipóteses são semelhantes a estas, porém não tratam de

fatores críticos, mas sim da existência de uma boa situação de informática antes do

projeto ERP – analisada através da satisfação com os sistemas – e da disposição da

empresa para mudança.

As hipóteses foram testadas com o grupo dos gerentes, pois a

representatividade do mesmo é maior – 45 respostas – que a dos usuários, que

possui somente 22 respostas.

O teste das hipóteses utiliza do nível de significância de até 5%. O nível de

significância de um teste é “a probabilidade de uma hipótese nula ser rejeitada,

quando verdadeira”, sendo os valores normalmente recomendados 1% e 5%. Um

nível de significância de 5% significa que a confiança no teste é de 95%. (Siegel,

1985, p. 208; Stevenson, 1981, p. 225)


113

HIPÓTESE 1

H0,1 : As motivações para o projeto não têm seus objetivos alcançados.

Com base nas motivações apresentadas pelos respondentes, e a informação

dos mesmos se essas tinham atingido ou não seus objetivos, foi realizado um teste

de proporção, com nível de significância de 1%. Os resultados – mostrados a seguir

– indicam que a proporção das motivações atingidas é de 85%.

Portanto, ao nível de significância de 1% rejeita-se H0,1, ou seja, as

motivações para o projeto têm seus objetivos alcançados.




Motivação gerentes Atingida 213 ,85 ,50 ,000a

Não atingida 37 ,15 Total 250 1,00 a Baseado na aproximação de Z. Tabela 20: Teste de proporção para as motivações

MEDIDAS DO SUCESSO DO PROJETO

Para testar a maior parte das hipóteses é necessário medir o sucesso do

projeto, que por sua vez foi considerado em quatro dimensões (variáveis) distintas:

Tempo; Custo; Qualidade; e Melhoria. No questionário, os respondentes opinaram

sobre o sucesso do projeto com notas de 0 a 10 para as quatro dimensões do mesmo.

Foi realizado, para as dimensões de sucesso, um teste de análise fatorial com

os mesmos. A análise fatorial é o nome genérico dado à classe de métodos

estatísticos multivariados, cujo objetivo primário é definir uma estrutura “oculta”

em uma matriz de dados. Ela busca identificar variáveis subjacentes, ou fatores, que

explicam o padrão de correlação dentro de um conjunto de variáveis observadas.

Seu uso mais comum é na redução de dados, identificando um pequeno número de

fatores que explicam a maior parte da variância observada em um número maior de


114

variáveis (Hair, p. 367; SPSS Inc., 1998). Os resultados do SPSS para a análise

fatorial estão apresentados no Anexo 5.

As quatro variáveis de sucesso foram agrupadas em duas novas variáveis:

Eficiência, para as dimensões de tempo e custo – mais condizentes com os aspectos

de cronograma do projeto; e Eficácia, para as dimensões qualidade e melhoria – por

sua vez, mais intangíveis e subjetivas que as anteriores. A partir destas duas novas

variáveis, foi criada uma outra, Efetividade, formada por uma ponderação entre

ambas. Desta forma:

Eficiência = Tempo + Custo

Eficácia = Qualidade + Melhoria

Efetividade = Eficácia * 1,484 + Eficiência * 1,416

A partir da variável Efetividade, que congrega as dimensões de sucesso

fornecidas pelos respondentes nos questionários, foi verificada a correlação entre a

Efetividade e os fatores de cada hipótese, utilizando-se o Coeficiente de

Correlação de Spearman. Os resultados completos das correlações estão no Anexo

5.

O coeficiente de Spearman, designado por “rho”, busca identificar uma

correlação entre duas variáveis e é baseado em postos, quando cada indivíduo

recebe um posto em duas séries ordenadas. O mesmo possui mecanismos para tratar

observações empatadas, quando o mesmo score é dado para mais de um indivíduo.

(Siegel, 1975, p. 228; Ott, 1993, p. 465). Sua fórmula do Coeficiente de Correlação

de Spearman é dada por:

NN

dr

N

ii

s −−=

∑=3

1

261


115

onde N são os valores amostra e di são as diferenças entre os valores das

variáveis Xi e Yi. Quando existe um conjunto de observações empatadas, a fórmula

mais recomendada é a seguinte:

∑∑∑ ∑ ∑−+

=22

222

2 yx

dyxrs

onde

∑∑ −−

= xTNN

x12

32

∑∑ −−

= yTNN

y12

32

12

3 ttT

−=

t = número de observações empatadas em determinado posto.

HIPÓTESE 2

H0,2 : A existência de missões claras e definidas não é um fator crítico


A correlação apresentada nessa hipótese – 0,362 – em relação à medida

Efetividade, permite rejeitar-se H0,2 com grau de significância de 5%. Portanto,

acredita-se que a existência de missões claras e definidas é um fator crítico para o

sucesso do projeto. Observa-se ainda a existência de correlações com a Eficiência

ao nível de 10% e com a Eficácia ao nível de 1%. A seguir, os resultados das

correlações.


116

Eficiência Eficácia EfetividadeRho de Spearman F1-Missões claras e def. Coeficiente Correlação ,276 ,447** ,362* Significância (bicaudal) ,066 ,002 ,015 N 45 45 45** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 21: Teste de correlação para o fator “Missões claras e definidas”

HIPÓTESE 3

H0,3 : A existência de apoio da alta administração não é um fator crítico


Esta hipótese apresenta uma correlação de 0,487 em relação à Efetividade,

permitindo rejeitar-se H0,3 com grau de significância de 1%. Desta forma, pode-se

afirmar que o apoio da alta administração representa um fator crítico para o sucesso

do projeto. Com relação à Eficiência, também existe uma correlação ao nível de

5%. Na tabela a seguir, os resultados das correlações.

Eficiência Eficácia Efetividade Rho de Spearman F2-Apoio alta adm. Coeficiente Correlação ,572** ,249 ,487** Significância (bicaudal) ,000 ,100 ,001 N 45 45 45** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 22: Teste de correlação para o fator “Apoio da alta administração”

HIPÓTESE 4

H0,4 : A existência de usuários capazes e envolvidos não é um fator


A hipótese H0,4 não apresentou correlação de acordo com a Efetividade

(assim como com qualquer outra medida). Dessa forma, não se pode rejeitar H0,4, ou

seja, não existem indícios estatísticos de que a existência de usuários capazes e

envolvidos é um fator crítico para o sucesso do projeto. A seguir, o teste de

correlações.


117

Eficiência Eficácia EfetividadeRho de Spearman F3-Usuários capazes Coeficiente Correlação ,065 ,163 ,085 Significância (bicaudal) ,670 ,284 ,581 N 45 45 45** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 23: Teste de correlação para o fator “Usuários capazes e envolvidos”

HIPÓTESE 5

H0,5 : A existência de um planejamento detalhado do projeto não é um

fator crítico para o sucesso do projeto.

No nível de significância do teste, de 5%, a hipótese H0,5 não apresenta

correlação, o que não rejeita a hipótese. Desta forma, não se pode afirmar que o

planejamento detalhado do projeto é um fator crítico para o sucesso deste. Todavia,

é importante observar que existem fortes indícios de correlação, particularmente se

fosse utilizada uma significância ao nível de 10%, visto que, em relação à

Efetividade, o resultado obtido foi 0,293, com significância exatamente igual a 5%.

Resultados semelhantes podem ser verificados para as medidas de Eficiência e

Eficácia. A seguir, a tabela com estes resultados.

Eficiência Eficácia EfetividadeRho de Spearman F4-Planej. detalhado Coeficiente Correlação ,276 ,265 ,293 Significância (bicaudal) ,066 ,078 ,050 N 45 45 45** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 24: Teste de correlação para o fator “Planejamento detalhado”

HIPÓTESE 6

H0,6 : A existência de um gerente de projeto com as habilidades

necessárias não é um fator crítico para o sucesso do projeto.

A hipótese H0,6 não apresentou correlação de acordo com a Efetividade.

Dessa forma, não se pode rejeitar H0,6, ou seja, não existem indícios de que um


118

gerente de projeto com as habilidades necessárias seja um fator crítico para o

sucesso do projeto. Contudo, em relação à medida de Eficácia, existe uma

correlação, no nível de significância de 5%, o que é um indício da importância do

gerente de projeto. A seguir os resultados dos testes.

Eficiência Eficácia EfetividadeRho de Spearman F5-Ger. proj. c/ habil. Coeficiente Correlação ,090 ,312* ,139 Significância (bicaudal) ,559 ,037 ,364 N 45 45 45** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 25: Teste de correlação para o fator “Gerente de projeto com habilidades

necessárias”

HIPÓTESE 7

H0,7 : A existência de uma empresa de consultoria externa não é um

fator crítico para o sucesso do projeto.

Assim como o gerente de projeto com habilidades necessárias, a presença de

um empresa de consultoria – hipótese H0,7 – não apresentou correlação de acordo

com a Efetividade. Dessa forma, não se pode rejeitar H0,7, ou seja, não foram

apresentados indícios de que a presença de uma empresa de consultaria externa seja

considerada um fator crítico para o sucesso do projeto. Todavia, em relação à

medida de Eficácia – aspectos de qualidade e melhoria da organização – existe uma

correlação, no nível de significância de 10%, que poderia indicar uma relação entre

esta medida e a presença de uma empresa de consultoria. A seguir, os resultados das

correlações.

Eficiência Eficácia EfetividadeRho de Spearman F6-Consultoria externa Coeficiente Correlação ,104 ,284 ,175 Significância (bicaudal) ,502 ,061 ,256 N 44 44 44** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 26: Teste de correlação para o fator “Presença de empresa de consultoria”


119

HIPÓTESE 8

H0,8 : A existência de mudanças dos processos de negócio não é um fator


A correlação apresentada nessa hipótese – 0,270 – em relação à medida

Efetividade, não permite rejeitar-se H0,8 com grau de significância de 5%. Portanto,

não se pode afirmar que a realização de mudanças nos processos de negócios seja

um fator crítico para o sucesso do projeto. Deve -se, entretanto, ressaltar a correlação

existente entre a mudança de processos de negócios e a medida de Eficiência –

tempo e custo do projeto – que é significativa com nível de 5%. A própria

Efetividade permitiria uma correlação, com nível de 10% - o que rejeitaria esta

hipótese. As correlações estão descritas a seguir.

Eficiência Eficácia EfetividadeRho de Spearman F7-Mudança processos Coeficiente Correlação ,309* ,077 ,270 Significância (bicaudal) ,042 ,619 ,077 N 44 44 44** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 27: Teste de correlação para o fator “Mudança nos processos de negócios”

HIPÓTESE 9

H0,9 : Não existe relação entre a satisfação dos usuários com os sistemas

existentes e o sucesso do projeto.

Em relação à satisfação dos usuários com os sistemas existentes antes do

projeto e o sucesso deste, a hipótese é rejeitada com nível de significância de 5%.

Observa-se ainda que, em relação à medida de Eficiência – tempo e custo – poderia

ser utilizado o nível de significância de 1%. Ou seja, a existência de uma

informática satisfatória é um elemento que se relaciona com o sucesso do projeto. A

seguir, os resultados das correlações.


120

Eficiência Eficácia EfetividadeRho de Spearman Informática Coeficiente Correlação ,331* ,155 ,297* Significância (bicaudal) ,026 ,308 ,048 N 45 45 45** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 28: Teste de correlação para a satisfação dos usuários com os sistemas

HIPÓTESE 10

H0,10 : Não existe relação entre a disposição da empresa para mudança e

o sucesso do projeto.

Quanto à disposição da empresa para mudança, não se pode rejeitar a

hipótese, com qualquer dos níveis de significância utilizados, o que parece mostrar

não existir relação entre a disposição para a mudança e o sucesso do projeto. A

tabela abaixo mostra as correlações utilizadas.

Eficiência Eficácia EfetividadeRho de Spearman Disposição p/ mudança Coeficiente Correlação -,092 ,133 ,008 Significância (bicaudal) ,547 ,383 ,956 N 45 45 45** Correlação é significante ao nível .01 (bicaudal). * Correlação é significante ao nível .05 (bicaudal). Tabela 29: Teste de correlação para a disposição da empresa para mudança

ANÁLISES EXPLORATÓRIAS


No aspecto de adoção de tecnologia, buscou-se identificar se a mesma havia

ocorrido em três das fases do modelo de Kwon & Zmud (1987). As fases

consideradas foram: adoção; uso; e incorporação. Foi aplicado um teste de

proporção nos dados obtidos do questionário, sendo os resultados apresentados nas

tabelas logo a seguir.


121

Em relação à nova tecnologia na fase de “adoção”, os resultados mostram

que se pode afirmar que a mesma ocorreu, tanto para o grupo de gerentes

(proporção de 90%), quanto para o grupo de usuários (proporção de 89%), com uma

significância de até 1%.

Quanto à fase de “uso”, para o grupo de gerentes, a mesma ocorreu, com

proporção de 73% e significância de 1%, que pode ser aceita. Porém, para o grupo

de usuários, o mesmo não ocorreu, pois a proporção foi de somente 63%, não

atingindo uma significância aceitável. O que parece indicar que o grupo dos

gerentes acredita mais no uso do sistema que o grupo de usuários.

Finalmente, na fase de “incorporação”, o teste de proporção nada permitiu

comprovar, pois as proporções sobre a adoção de tecnologia ficaram em 52% e 53%

paras o gerentes e usuários, respectivamente. Explorando-se um pouco mais as

respostas dessa fase, separou-se a mesma em dois aspectos distintos: recursos

completamente explorados e recursos usados para a tomada de decisão. Pode-se

afirmar, pelas proporções obtidas, que ocorre o uso dos recursos para tomada de

decisão, com significância de 5% para gerentes e de 10% para usuários. O oposto

ocorre, porém, no segundo aspecto, pois o mesmo demonstrou, com significância de

1% para gerentes e 5% para usuários, que os sistemas não têm seus recursos

completamente explorados. A seguir, os resultados dos testes.




Adoção Atingida 37 ,90 ,50 ,000a

Não atingida 4 ,10 Total 41 1,00Uso Atingido 30 ,73 ,50 ,005a

Não atingido 11 ,27 Total 41 1,00Incorporação Não atingido 43 ,52 ,50 ,740a

Atingido 39 ,48 Total 82 1,00Incorporação - Atingida 10 ,24 ,50 ,002a

Recursos Não atingida 31 ,76explorados Total 41 1,00Incorporação - Atingida 29 ,71 ,50 ,012a

Tomada Não atingida 12 ,29Decisão Total 41 1,00a Baseado na aproximação de Z. Tabela 30: Teste de proporção para adoção de tecnologia, na opinião dos gerentes


122



Signific. Exata (bicaudal)

Adoção Atingida 17 ,89 ,50 ,001 Não atingida 2 ,11 Total 19 1,00Uso Atingido 12 ,63 ,50 ,359 Não atingido 7 ,37 Total 19 1,00Incorporação Não atingida 20 ,53 ,50 ,871a

Atingida 18 ,47 Total 38 1,00Incorporação - Atingida 5 ,25 ,50 ,041Recursos Não atingida 15 ,75Explorados Total 20 1,00Incorporação - Atingida 13 ,72 ,50 ,096Tomada Não atingida 5 ,28Decisão 18 1,00a Baseado na aproximação de Z. Tabela 31: Teste de proporção para adoção de tecnologia, na opinião dos usuários

RELAÇÕES ENTRE OS COMPONENTES DE SUCESSO

A formação das variáveis Eficiência e Eficácia, conforme mostrada nos

testes de análise fatorial, neste capítulo, agregou os componentes de sucesso Tempo

+ Custo e Qualidade + Melhora. A tabela abaixo, que se utiliza do método de

correlação pelo Coeficiente de Pearson, mostra um resultado semelhante, indicando

que essas variáveis possuem uma alta correlação. O Coeficiente de Pearson (r)

indica o grau de relacionamento entre duas variáveis contínuas (Spiegel, 1985, p.

302; Stevenson, 1981, p. 368). Foi utilizada a amostra dos gerentes para os testes.

Tais correlações eram um tanto quanto esperadas, pois se acredita que um

projeto com maior sucesso na execução de seu cronograma resultaria em melhores

resultados de tempo e custo (e vice-versa), assim como um projeto, cujo

desempenho seja considerado adequado e de qualidade, propicie melhorias na

organização. O teste apresenta – ao nível de 1% – a associação entre Tempo e

Custo, com correlação 0,402 e entre Qualidade e Melhora, com correlação 0,538.


123

Tempo Custo Qualidade MelhoraTempo Correlação de Pearson 1,000 ,402** ,295 ,260 Significância (bicaudal) , ,009 ,061 ,101 N 41 41 41 41Custo Correlação de Pearson ,402** 1,000 ,266 ,171 Significância (bicaudal) ,009 , ,093 ,286 N 41 41 41 41Qualidade Correlação de Pearson ,295 ,266 1,000 ,538** Significância (bicaudal) ,061 ,093 , ,000 N 41 41 41 41Melhora Correlação de Pearson ,260 ,171 ,538** 1,000 Significância (bicaudal) ,101 ,286 ,000 , N 41 41 41 41** A correlação é significante ao nível 0.01 (bicaudal). Tabela 32: Correlações entre os componentes do sucesso

RELAÇÕES COM O PORTE DAS EMPRESAS E DOS PROJETOS

Em relação ao porte das empresas e dos projetos, buscou-se identificar se

existiam relações entre os mesmos. Foi aplicado o teste de correlação, utilizando-se

o método do Coeficiente de Spearman, e identificadas algumas correlações

estabelecidas entres as variáveis de porte das empresas – faturamento anual e

número de funcionários – e porte do projeto – tamanho da equipe, duração e valor

do projeto – e as medidas de sucesso do projeto – Eficiência, Eficácia e Efetividade

– que são discutidas a seguir.

O porte da empresa (faturamento e funcionários) mostrou altas correlações –

significâncias de 1% e 5% – com o porte do projeto (equipe, duração e valor), o que

era razoavelmente esperado, pois empresas maiores tendem a implementar projetos

maiores. A única exceção foi o número de funcionários em relação ao valor do

projeto, quando a correlação obtida não foi significativa. A tabela abaixo mostra as

correlações.


124

Rho de Spearman Faturamen-to anual

Número funcionários

Tamanho da equipe

Duração do projeto

Valor do projeto

Faturamento anual Coeficiente de Correlação 1,000 ,798** ,537** ,363* ,530** Significância (bicaudal) , ,000 ,000 ,014 ,001 N 45 45 45 45 35Número funcionários Coeficiente de Correlação ,798** 1,000 ,344* ,309* ,268 Significância (bicaudal) ,000 , ,021 ,039 ,120 N 45 45 45 45 35Tamanho da equipe Coeficiente de Correlação ,537** ,344* 1,000 ,212 ,567** Significância (bicaudal) ,000 ,021 , ,163 ,000 N 45 45 45 45 35Duração do projeto Coeficiente de Correlação ,363* ,309* ,212 1,000 ,474** Significância (bicaudal) ,014 ,039 ,163 , ,004 N 45 45 45 45 35Valor do projeto Coeficiente de Correlação ,530** ,268 ,567** ,474** 1,000 Significância (bicaudal) ,001 ,120 ,000 ,004 , N 35 35 35 35 35* Correlação é significante ao nível .05 (bicaudal). ** Correlação é significante ao nível .01 (bicaudal).

O cruzamento entre porte da empresa e medidas de sucesso do projeto não

apresentou quaisquer correlações. Dessa forma, acredita-se que tanto empresas

grandes ou pequenas podem possuir o mesmo grau de sucesso em seus projetos. O

quadro abaixo mostra essas correlações.

Rho de Spearman Eficiência Eficácia Efetividade Faturamen-to anual

Número funcionários

Eficiência Coeficiente de Correlação 1,000 ,383* ,915** -,028 ,035 Significância (bicaudal) , ,014 ,000 ,860 ,827 N 41 41 41 41 41Eficácia Coeficiente de Correlação ,383* 1,000 ,692** -,100 ,018 Significância (bicaudal) ,014 , ,000 ,534 ,913 N 41 41 41 41 41Efetividade Coeficiente de Correlação ,915** ,692** 1,000 -,092 ,001 Significância (bicaudal) ,000 ,000 , ,566 ,995 N 41 41 41 41 41Faturamento anual Coeficiente de Correlação -,028 -,100 -,092 1,000 ,798** Significância (bicaudal) ,860 ,534 ,566 , ,000 N 41 41 41 45 45Número funcionários Coeficiente de Correlação ,035 ,018 ,001 ,798** 1,000 Significância (bicaudal) ,827 ,913 ,995 ,000 , N 41 41 41 45 45* Correlação é significante ao nível .05 (bicaudal). ** Correlação é significante ao nível .01 (bicaudal).

Na análise entre as medidas de sucesso e o porte do projeto, nenhuma

correlação foi observada nos níveis de significância de 1% ou 5%. Porém, surgiu

uma correlação negativa, ao nível de 10%, entre a Efetividade e a duração do

projeto. Isso pode ser um forte indício que os projetos com menor duração – mais

rápidos – obtêm um maior grau de sucesso, o que é bastante significativo, mesmo

porque a duração da implementação dos projetos ERP é um dos pontos importantes

discutidos na literatura sobre o assunto.


125

Rho de Spearman Eficiência Eficácia Efetividade Tamanho da equipe

Duração do projeto

Valor do projeto

Eficiência Coeficiente de Correlação 1,000 ,383* ,915** ,118 -,247 ,070 Significância (bicaudal) , ,014 ,000 ,462 ,119 ,709 N 41 41 41 41 41 31Eficácia Coeficiente de Correlação ,383* 1,000 ,692** -,087 -,247 ,060 Significância (bicaudal) ,014 , ,000 ,588 ,119 ,748 N 41 41 41 41 41 31Efetividade Coeficiente de Correlação ,915** ,692** 1,000 ,081 -,277 ,078 Significância (bicaudal) ,000 ,000 , ,616 ,079 ,676 N 41 41 41 41 41 31Tamanho da equipe Coeficiente de Correlação ,118 -,087 ,081 1,000 ,212 ,567** Significância (bicaudal) ,462 ,588 ,616 , ,163 ,000 N 41 41 41 45 45 35Duração do projeto Coeficiente de Correlação -,247 -,247 -,277 ,212 1,000 ,474** Significância (bicaudal) ,119 ,119 ,079 ,163 , ,004 N 41 41 41 45 45 35Valor do projeto Coeficiente de Correlação ,070 ,060 ,078 ,567** ,474** 1,000 Significância (bicaudal) ,709 ,748 ,676 ,000 ,004 , N 31 31 31 35 35 35* Correlação é significante ao nível .05 (bicaudal). ** Correlação é significante ao nível .01 (bicaudal).

COMPARAÇÃO ENTRE AS MOTIVAÇÕES

Em relação às motivações apresentadas para a realização do projeto, foi feito

um teste de proporção, no item “Motivações para o Projeto” que apresentou como

resultado o fato de que as motivações tinham sido atingidas. A tabela abaixo

representa um teste de proporção feito com cada motivação para avaliar se a mesma

teve seu objetivo atingido.

Em sua maior parte, os resultados apresentados são condizentes com o teste

unificado (usado na hipótese n.º 1), porém algumas exceções devem ser destacadas.

A principal delas é a motivação de redução de pessoal, que obteve seu objetivo

atingido em somente 56% e 38% (gerentes e usuários, respectivamente), uma

proporção muito baixa. Dessa forma, fica a consideração sobre os projetos ERP que

buscam redução de pessoal terem, aparentemente, dificuldade em atingir esse

objetivo. Quanto ao fato da motivação “Pressão de parceiros” também não ter

atingido seus objetivos com um nível de significância aceitável, deve ser

considerado a pequena quantidade de casos presentes nessa motivação – somente 4

– que não a torna muito relevante. O outro destaque é, no grupo de usuários, a

motivação do projeto pela globalização de negócios, que atingiu somente 63%, com

uma significância insuficiente.


126

Categoria N

Prop. Obser-vada

Teste Pro-

porção

Signifi-cância (bicaudal)

Sig. exata (bicaudal)

Integração de informações Atingida 43 ,98 ,50 ,000a

Não atingida 1 ,02 Total 44 1,00Redução de pessoal Atingida 9 ,56 ,50 ,804 Não atingida 7 ,44 Total 16 1,00Busca de vantagem competitiva Atingida 24 ,83 ,50 ,001a

Não atingida 5 ,17 Total 29 1,00Determinação da matriz Atingida 10 ,83 ,50 ,039 Não atingida 2 ,17 Total 12 1,00Globalização de negócios Atingida 12 ,80 ,50 ,035 Não atingida 3 ,20 Total 15 1,00Ano 2000 Atingida 22 ,73 ,50 ,018a

Não atingida 8 ,27 Total 30 1,00Pressão de parceiros Atingida 3 ,75 ,50 ,625 Não atingida 1 ,25 Total 4 1,00Necessidade de informações gerenciais Atingida 36 ,86 ,50 ,000a

Não atingida 6 ,14 Total 42 1,00Indicação por empresa de consultoria Atingida 5 1,00 ,50 ,063 Total 5 1,00Evolução da arquitetura de informática Atingida 27 ,96 ,50 ,000a

Não atingida 1 ,04 Total 28 1,00Redesenho de processos Atingida 22 ,88 ,50 ,000 Não atingida 3 ,12 25 1,00a Baseado na aproximação de Z.

Tabela 33: Teste de proporção para as motivações no grupo de gerentes

Categoria N

Prop. Obser-vada

Teste Pro-

porção

Signifi-cância (bicaudal)

Integração de informações Atingida 17 ,77 ,50 ,017 Não atingida 5 ,23 Total 22 1,00Redução de pessoal Atingida 3 ,38 ,50 ,727 Não atingida 5 ,63 Total 8 1,00Busca de vantagem competitiva Atingida 15 ,75 ,50 ,041 Não atingida 5 ,25 Total 20 1,00Determinação da matriz Atingida 9 ,90 ,50 ,021 Não atingida 1 ,10 Total 10 1,00Globalização de negócios Atingida 5 ,63 ,50 ,727 Não atingida 3 ,38 Total 8 1,00Ano 2000 Atingida 13 1,00 ,50 ,000 Total 13 1,00Necessidade de informações gerenciais Atingida 16 ,84 ,50 ,004 Não atingida 3 ,16 Total 19 1,00Indicação por empresa de consultoria Atingida 3 1,00 ,50 ,250 Total 3 1,00Evolução da arquitetura de informática Atingida 10 1,00 ,50 ,002 Total 10 1,00Redesenho de processos Atingida 12 1,00 ,50 ,000 Total 12 1,00

Tabela 34: Teste de proporção para as motivações no grupo de usuários


127

SUMÁRIO

O conteúdo deste capítulo é formado basicamente por diversas análises dos

dados coletados, divididas em três blocos principais. O primeiro com uma análise

descritiva das características das empresas e dos projetos, os motivos para a

implementação dos projetos, valores envolvidos e outras informações, apresentadas

na forma de tabelas e gráficos.

O segundo bloco de análises contém o teste das hipóteses enunciadas e sua

conseqüente aceitação ou rejeição – a partir dos níveis de significância adotados –

bem como alguns comentários sobre os resultados obtidos com as mesmas.

Finalmente, a terceira parte é composta por algumas análises exploratórias,

onde se buscam identificar relações existentes entre elementos obtidos na coleta de

dados, como, por exemplo, o processo de adoção de tecnologia após a

implementação de um sistema de gestão empresarial.

128

Capítulo 5

CONCLUSÕES E RECOMENDAÇÕES

CONCLUSÕES

Os resultados obtidos com a pesquisa permitiram que algumas conclusões

pudessem ser delineadas. Algumas destas foram fundamentadas nos testes

estatísticos aplicados sobre as hipóteses de pesquisa; outras, a partir da observação e

análise dos dados coletados e sua análise descritiva.

Os resultados se agrupam, basicamente, em conclusões sobre a presença de

fatores críticos de sucesso, obtidas a partir do teste de hipóteses, em conclusões

sobre as características das empresas e dos projetos analisados; nas motivações para

o projeto; presença dos fatores críticos de sucesso nas fases do projeto; e no

processo de adoção de tecnologia.

Deve-se lembrar que, conforme apresentado no Capítulo 3, esse estudo, em

função de suas características exploratórias e explanatórias, além de sua amostra de

conveniência, possui restrições quanto às suas conclusões, que não permitem

afirmações conclusivas ou definitivas sobre os resultados da pesquisa,

particularmente na aplicação dos resultados obtidos com a amostra em relação ao

universo da pesquisa.

CAPÍTULO 5: CONCLUSÕES E RECOMENDAÇÕES

129

CARACTERÍSTICAS DOS PROJETOS

Inicialmente, a análise do porte das empresas – baseado no número de

funcionários e no faturamento anual – que formaram a amostra, e do porte dos

projetos – baseado no tamanho da equipe, duração e valor do projeto –

desenvolvidos por essas, mostrou uma forte correlação, indicando que, como era

esperado, maiores empresas tendem a desenvolver e implementar projetos maiores.

Porém, ainda no que diz respeito ao porte da empresa, não foi possível

observar qualquer indício de sucesso de projetos que estivesse ligado a este. Ou

seja, parece não importar o tamanho da empresa para se obter ou não sucesso na

implementação de projetos ERP.

Agora, quanto ao porte do projeto, esta afirmação se mostrou verdadeira

quando se considerou o tamanho da equipe e o valor do projeto. Nesses aspectos,

também não foi possível observar quaisquer sinais que indicassem maior ou menor

grau de sucesso em correspondência com o tamanho da equipe ou valor do projeto.

A exceção, neste caso, foi na duração do projeto. Se a mesma for considerada com

um grau de significância de 10%, surge uma correlação negativa entre a duração do

projeto e o grau de sucesso alcançado pelo mesmo. Isso indica que os projetos que

foram implementados mais rapidamente alcançaram um maior grau de sucesso que

os demais.

Quando se trata do sucesso do projeto, é importante relembrar que o mesmo

foi medido a partir de quatro dimensões: o tempo, com a execução dentro do tempo

e cronograma estipulados; o custo, como este deveria se situar dentro do planejado;

desempenho e qualidade, permitindo a utilização correta do sistema e ser adequado

à organização; e melhora da organização pelo uso do sistema.

Dentre as notas fornecidas para estas quatro dimensões do sucesso do

projeto, as análises mostraram existir correlações entre o custo e o tempo, e entre a

qualidade e a melhora. Isso indica que projetos que têm sucesso ou fracasso em


130

custo também o fazem em relação ao tempo (e vice-versa), assim como quanto à

qualidade e melhora da organização.

No item valor de projeto, foi analisada a formação do valor total do projeto, a

partir dos três componentes básicos presentes na implementação de sistemas de

gestão empresarial: hardware, software e serviços. A relação encontrada entre os

mesmos foi: hardware com 31,6%; software com 26,8%; e serviços com 41,6%.

Esses números coincidem com alguns encontrados na literatura e diferem de outros,

porém confirmam um ponto em comum, que é o alto custo do item “serviço” nesse

tipo de projeto.

Os projetos apresentaram uma certa regularidade em relação aos módulos

utilizados – em processo de implementação ou já concluídos. A presença freqüente

dos módulos “principais” confirma a sua implementação nos pacotes ERP, em sua

maior parte. O destaque deve ser dado para os módulos Financeiro e de Compras

com presença em 83,7% das empresas, seguidos pelos módulos Contábil (79,1%),

Industrial (72,1%) e de Vendas (67,4%). Quanto ao módulo Industrial, uma ressalva

deve ser feita. Como a amostra não tratou as empresas por segmento de atuação no

mercado, foi observada a presença de um certo número de empresas de

características não industriais, tais como serviços, distribuição, etc. o que as torna

não-usuárias em potencial do referido módulo.

Finalmente, em relação às características dos projetos, foi analisado o

método pelo qual esses são colocados em produção. O método conhecido como big

bang, que se caracteriza pela colocação do sistema em funcionamento de uma só

vez, e que se contrapõem ao método de colocação em funcionamento por fases, teve

uma representatividade muito grande na amostra. Este método foi utilizado por 41%

das empresas que formaram a amostra, sendo aplicado em empresas de todos os

portes avaliados, em uma proporção semelhante. Esse último fato é significativo por

existir uma correlação entre porte de empresa e porte de projeto, o que indica que

grandes projetos também estão entrando em produção utilizando-se desse método.


131


Quanto às motivações para a implementação de um projeto ERP, ficou

evidenciado que as mesmas tiveram, em sua maioria, seus objetivos atingidos. Isso

ocorreu em 85% dos casos na amostra dos gerentes e 82% dos casos na amostra dos

usuários. Ou seja, os motivos e as razões apresentados para se iniciar um projeto

desse tipo, normalmente, são satisfeitos, o que não deixa de ser um indicador

implícito de um certo sucesso dos projetos (não considerando aspectos da

implementação medidos em outro ponto, como tempo, custo, etc.)

Dentre as motivações apresentadas, a necessidade de integrar informações e

sistemas foi, para os dois grupos, o grande destaque, com 100% de presença em

todas as respostas. Isso parece vir de encontro ao grande argumento de venda

apresentado pelos fornecedores de softwares ERP, sobre as características de

integração de informações existentes nesses. Em seguida, surgem em comum as

motivações em relação à maior necessidade de informações gerenciais para tomada

de decisão; busca de vantagem competitiva e outros benefícios potenciais; e

substituição de sistemas por problemas com o ano 2000.

Deve-se observar uma aparente maior preocupação (até certo ponto,

esperada) com os aspectos técnicos no grupo de gerentes – as motivações do ano

2000 em 68,2% das empresas e da evolução da estrutura de informática em 63,6% -

do que no de usuários. Em contrapartida, os usuários pareceram demostrar uma

maior preocupação com aspectos de negócios, como, por exemplo, a necessidade de

buscar vantagem competitiva e de redesenhar processos.

Com relação às motivações de projeto induzidas por problemas com o bug

do milênio, estas já não devem mais ser significativas para os novos projetos que

irão se iniciar ou estão se iniciando, pois a solução desse tipo de problema, há

menos de seis meses da data crítica (31/12/1999), provavelmente não deve passar

pela decisão de se iniciar a implementação de um projeto ERP.


132

Quando analisadas separadamente, as motivações também apresentaram seus

objetivos atingidos, com destaque especial para apenas uma exceção. A redução de

pessoal, como motivação para se implementar um projeto ERP, não parece ser das

mais bem sucedidas, pois a mesma obteve uma proporção de 56% no grupo dos

gerentes e de somente 38% no de usuários, ambas não significativas.


Em relação aos fatores críticos de sucesso, com o teste de hipóteses aplicado

nos mesmos, pode-se observar que alguns são considerados como críticos para o

sucesso do projeto, enquanto que outros não o são. Existem alguns, ainda, que não

se pode afirmar que são críticos, mas parecem possuir indícios de serem, pelo

menos, muito importantes para o sucesso do projeto.

Também precisa ser ressaltado que a não-criticidade de um fator, não indica

que o mesmo seja dispensável. Alguns elementos podem ser considerados como

críticos para o sucesso de um projeto, mas serem básicos e essenciais para a sua

execução.

Foram dois os fatores identificados como críticos para o sucesso dos

projetos: o primeiro é a existência de missões claras e definidas para o projeto; o

segundo é o apoio da alta administração. Ambos são condizentes com a literatura

(Pinto & Slevin, 1988b) sobre o assunto, e sua criticidade já era um tanto quanto

esperada.

Os seguintes fatores não foram identificados como críticos, mas

apresentaram diversos indícios (alguns bastante fortes) sobre a sua importância:

gerente de projeto com as habilidades necessárias; presença de uma empresa de

consultoria; e a ocorrência de mudanças nos processos de negócios da empresa. Isso

indica que, apesar dos mesmos não terem sido classificados como críticos, sua

presença no projeto parecer contribuir e ser importante para o sucesso do mesmo.


133

Em relação aos fatores “planejamento detalhado do projeto” e “usuários

capazes e envolvidos no projeto”, aparentemente não se pode concluir que os

mesmos sejam críticos, pois não foram encontrados indícios de tal fato. Pode-se,

talvez, inferir tratar-se de aspectos de projeto que sejam básicos e não encarados

pelos respondentes como críticos, mas não há nada de conclusivo a respeito.

Além dos fatores críticos, foram analisados dois outros aspectos da

organização que se supunha poderem ter uma relação direta com o sucesso dos

projetos: a disposição da mesma para a mudança; e a satisfação com a informática –

mais particularmente com os sistemas – existentes antes da implementação do

projeto.

No primeiro aspecto, não surgiu qualquer evidência que o mesmo seja crítico

para o sucesso do projeto. Acredita-se que uma avaliação diferente desse aspecto

poderia ter produzido outros resultados, pois a grande maioria dos respondentes

identificou sua organização como propensa à mudança, o que não forneceu qualquer

correlação com o sucesso dos projetos.

Quanto ao segundo aspecto, surgiram evidências do relacionamento entre a

satisfação dos usuários com os sistemas e o sucesso do projeto, o que pode levar a

acreditar que, de maneira geral, quanto melhor a informática em uma organização,

maior a chance de sucesso em projetos ERP.

Quanto aos fatores críticos, os mesmos também tiveram sua importância

verificada nas diferentes fases do projeto – porém sem testes de validade estatística.

O resultado principal mostrado foi a existência de uma grande variação na

importância dos fatores em cada fase do projeto, o que ressalta a dinâmica muito

grande do mesmo. Os gráficos que apresentam essas variações podem ser

verificados nas figuras 32 a 38.

Deve ser destacado que alguns dos resultados apresentados são bastante

condizentes com o teste de hipóteses dos fatores críticos. Particularmente, para

“usuários capazes e envolvidos” e “planejamento detalhado do projeto”, pode ser


134

observado que os mesmos quase não apresentaram importância em qualquer fase,

seja para o grupo de gerentes como para o grupo de usuários. Outro detalhe

interessante é o apoio da alta administração, identificado como crítico, e que possui

alta importância durante a maior parte do projeto, mas tem uma diminuição grande

no final, no momento de colocar o sistema em produção.

A presença de uma empresa de consultoria aparece como muito importante

no início do projeto – particularmente para a definição do software, acredita-se – e

volta a ter importância no momento da colocação dos sistemas em funcionamento.

O gerente de projeto parece exercer um papel muito importante (na opinião dos dois

grupos da amostra) principalmente nas fases mais operacionais do projeto, que

dizem respeito à sua execução e à entrada em operação. Finalmente, existe um

destaque especial para a atividade de mudança de processos de negócios, que

evidencia sua importância muito mais para os usuários do que para os gerentes de

projeto, que aparentam não dar tanta importância a este tópico.


Quanto aos aspectos de adoção da nova tecnologia trazida pelo sistema ERP,

nas três das fases do modelo de Kwon & Zmud (1987) analisadas – adoção, uso, e

incorporação – pode-se observar que a fase de adoção da tecnologia parecer ter

ocorrido, tanto para o grupo de usuários quanto para o de gerentes, com

significância de 1%.

No referente à fase de uso da nova tecnologia, essa sintonia entre os dois

grupos não ocorreu. Somente foi possível detectar o uso junto à opinião do grupo de

gerentes, também com significância de 1%. Para o grupo de usuários, isso não é tão

claro assim, pois o uso ocorreu somente em uma proporção de 63%, o que não foi

significativo. Isto parece fornecer indícios que o grupo de gerentes acredita mais no

uso do sistema que o grupo de usuários.


135

Finalmente, quanto à incorporação da nova tecnologia, os testes indicaram

que a mesma não ocorre em ambos os grupos. Na avaliação um pouco mais

detalhada dessa fase, parece haver evidências claras sobre a não-exploração

completa dos recursos do sistema, comprovado com nível de 1% para gerentes e 5%

para usuários, o que, provavelmente, é o principal motivo para o não-atingimento da

fase de incorporação da tecnologia.

RECOMENDAÇÕES

A partir das análises efetuadas e das conclusões apresentadas, como objetivo

final deste projeto, busca-se estabelecer algumas recomendações práticas que

possam ser úteis aos envolvidos na implementação de projetos de sistemas de

gestão empresarial, sejam esses gerentes de projeto, fornecedores, consultores,

usuários ou outros interessados no assunto.

Primeiramente, as recomendações são para garantir-se a presença dos fatores

que demonstraram ser críticos para o sucesso de projetos, assim como dos que

apresentaram sinais de serem de grande importância para tal. Acredita-se que a

presença de ambos, apesar de não ser uma garantia de sucesso, constitua um

elemento muito importante para tal.

Nesta linha, o projeto deve ter suas missões muito bem definidas e claras, se

possível para toda a organização, e não somente para os membros da equipe de

projeto, e mantidas durante o decorrer do projeto. A presença do apoio da alta

administração também é crítico para o sucesso do projeto e deve estar presente de

maneira efetiva, não somente para fornecer os recursos necessários, mas para,

sempre que possível, tornar explícito seu apoio à implementação do projeto.

Ainda, deve se buscar a existência de um gerente com as habilidades

necessárias para gerenciar o projeto, que se mostrou um fator muito importante para

o sucesso dos projetos da amostra, principalmente nas fases mais operacionais do


136

projeto. O mesmo ocorre com a presença de uma empresa de consultoria, que

também se mostrou um fator com fortes indícios de importância para o sucesso do

projeto. Os resultados mostraram ainda que a maior necessidade no uso dessa se dá

na fase inicial do projeto. Finalmente, desenvolver atividades de mudança nos

processos de negócios parece ser um recomendação muito importante para a

implementação com sucesso de um projeto ERP, pois, além da mesma ser

recomendada fortemente na literatura sobre o assunto, os resultados evidenciaram

essa importância.

Em relação ao planejamento detalhado e à presença de usuários capazes e

envolvidos no projeto, apesar dos mesmos não terem sido relacionados com o

sucesso do projeto, não parece ser prudente recomendar que se prescinda dos

mesmos, visto que se poderia especular se estes não são vistos como críticos pelos

respondentes por serem considerados básicos e essenciais. De qualquer forma, fica a

recomendação para, se possível, existir um planejamento detalhado e um grupo de

usuários capazes e envolvidos com os objetivos do projeto.

Quanto aos fatores, fica evidenciado que as necessidades dos projetos

mudam de acordo com cada momento deste, o que implica a exigência da presença

de um ou outro fator com maior ou menor intensidade. Dessa forma, estar atento ao

ambiente, avaliar as necessidades momentâneas do projeto e garantir a presença dos

elementos que satisfaçam essas necessidades parece ser uma recomendação

adequada.

Além das recomendações relacionadas aos fatores críticos de sucesso,

algumas outras ainda podem ser definidas. Ainda no aspecto sucesso, não se pode

fazer uma afirmação conclusiva, mas surgiram indícios que projetos com menor

duração atingem um maior grau de sucesso que os projetos mais longos. Dessa

forma, fica a recomendação no sentindo de priorizar as implementações mais

rápidas.

Quanto aos objetivos para a realização do projeto, não parece ser pertinente

tecer recomendações, pois cada organização possui seus próprios objetivos para


137

implementar um projeto deste tipo. A única ressalva é em relação à implementação

de sistemas ERP com o objetivo de redução de pessoal. Nesse caso, os objetivos

mostraram, de maneira significativa, não terem sido atingidos, o que serve de alerta

aos que pretendem desenvolver um projeto com esse objetivo somente.

Finalmente, quando foi analisado o aspecto adoção de tecnologia, surgiram

mostras de que os sistemas ERP implementados não têm seus recursos

completamente explorados. Considerando-se que os projetos, além de consumir

recursos valiosos de toda a organização, ainda têm sua motivação pela

implementação baseada, muitas vezes, na necessidade de integração de

informações, busca de vantagem competitiva, maior necessidade de informações

gerenciais para tomada de decisão, etc., torna-se importante uma recomendação

para se ir além da implementação apenas dos procedimentos operacionais dos

sistemas, e buscar-se uma maior e melhor exploração dos recursos do mesmo, o que

se acredita, poderia vir aumentar o grau nos quais as motivações citadas acima

seriam atingidas.

SUGESTÕES DE PESQUISA

No nível de sugestões para pesquisa, a partir do que foi elaborado neste

projeto, considera-se que alguns tópicos podem ser melhor explorados enquanto que

alguns novos podem ser desenvolvidos.

A utilização de uma amostra diferente poderia ser interessante em diversos

aspectos. Inicialmente, a amostra utilizada foi formada basicamente por gerentes de

projeto. Como o contato foi estabelecido com esses, os usuários que também

participaram foram contatados pelos gerentes, quando isso ocorreu. Isso pode abrir

espaço para a utilização de uma outra amostra, formada basicamente por usuários e

sem o envolvimento dos gerentes de projeto.


138

Outro aspecto que diz respeito à amostra é uma segmentação da mesma em

relação às empresas. Acredita-se que uma amostra formada em algum segmento de

atuação específico ou em um porte de empresa mais definido diminuiria a

diversidade apresentada e poderia trazer resultados interessantes. Com uma amostra

desse tipo, algumas relações poderiam ser estudadas com maior profundidade,

como, por exemplo, os gastos com os projetos.

Alguns tópicos também parecem requerer um estudo específico e mais

aprofundado, como, por exemplo, se a adoção de tecnologia realmente não está

ocorrendo de maneira completa e por quê. Um outro tópico é sobre as mudanças nos

processos de negócios ocorridas com a implementação do projeto e seus impactos

na organização.

Finalmente, também poderiam ser avaliados e comparados os resultados dos

pacotes de diversos fornecedores, bem como das empresas de consultoria que atuam

na implementação de projetos ERP.

SUMÁRIO

Este capítulo final é composto por um conjunto de conclusões obtidas a

partir da análise dos dados coletados, da aplicação de testes estatísticos e da

verificação das hipóteses propostas para esta pesquisa.

Também está presente um grupo de recomendações, que pretendem servir de

ajuda para os envolvidos e interessados na implementação de projetos de sistemas

ERP, esperando-se que as mesmas sejam úteis a esses.

Finalmente, para encerrar este capítulo e, conseqüentemente, este trabalho,

foram feitas algumas sugestões de pesquisa, que podem interessar e ser úteis aos

envolvidos e interessados neste estudo.

139

REFERÊNCIAS BIBLIOGRÁFICAS

A experiência Rhodia para a implantação do SAP. Excellence in action, v. 4, n. 10,

p. 3, abr. 1998.

AAKER, David A., DAY, George S. Marketing research. 4. ed. New York: John

Wiley & Sons, 1990. 739p.

ADAMS, John R., BARNDT, Stephen E. Behavioral implications of the project life

cycle. In: CLELAND, David I., KING, William R. Project management

handbook. 2. ed. New York: Von Nostrand Reinhold, 1988. p. 206-230.

ALANIS, Macedonio. Controlling the introduction of strategic information

technologies. In: SZEWCZAK, Edward, SNODGRASS, Coral,

KHOSROWPOUR, Mehdi. Management impacts of information technology:

perspectives on organizational change and growth. Harrisburg, Pennsylvania:

Idea Group, 1991. p. 421-437.

ANG, James S. K. et al. Critical success factors in implementing MRP and

government assistance: a Singapore context. Information Management, v. 29, p.

63-70, 1995.

BACA, Helen. A study of the role of project management in the design and

management of consulting practice. Austin, 1980. 264p. Tese (Doutorado) - The

University of Texas, Austin, 1980.

BANCROFT, Nancy H. et al. Implementing SAP R/3: how to introduce a large

systen into a large organization. 2. ed. Upper Saddle River, NJ: Prentice Hall,

1998. 336p.

Bankruptcy trustee sues SAP AG. Reuters-ZDNN, August 27, 1998. [Online.]

Disponível na Internet via WWW. URL


140

http://www.zdnet.com/zdnn/stories/zdnn_smgraph_display/0,3441,2132064,00.h

tml. Arquivo capturado em 28 de setembro de 1998.

BARTHOLOMEW, Doug. Promise vs. reality: are manufacturers expecting too

much from integrated systems? Or are software vendors over hyping the results?

Industry Week Magazine, v. 246, n. 20, p. 26-30, Nov. 1997a.

__________. Taking charge: CEOs should take an active role in enterprise-wide IT

projects. Industry Week Magazine, v. 246, n. 15, p. 122-128, Aug. 1997b.

__________. The king and IT. Industry Week Magazine, v. 246, n. 15, p. 144, Aug.

1997c.

BASHEIN, Barbara J., MARKUS, M. Lynne, RILEY, Patricia. Preconditions for

BPR success. Information Systems Management, v. 11, n. 2, p. 7-13, 1994.

BETTER bang for the buck. Software Magazine, v. 17, n. 6, p. 82, June 1997.

BETTINI, Patrick J. The people/software equation. The Oliver Wight Companies,

1996. [Online.] Disponível na Internet via WWW. URL:

http://www.ollie.com/PSEquation.html. Arquivo capturado em 23 de março de

1998.

BOWDITCH, James L., BUONO, Anthony F. Elementos de comportamento

organizacional. São Paulo: Pioneira, 1992. 305p.

BRESLIN, Jud. Selecting and installing software packages. Westport, Connecticut:

Greenwood Press, 1986. 241p.

CHAPMAN, Chris, WARD, Stephen. Project management risk. Chichester,

England: Hohn Wiley & Sons, 1997. 322p.

CHISNALL, Peter M. Pesquisa mercadológica. São Paulo: Saraiva, 1980.


141

CLELAND, David I. Project stakeholder management. In: CLELAND, David I.,

KING, William R. Project management handbook. New York: Van Nostrand

Reinhold, 1988. p. 275-301.

COSTA, Pedro Luiz de Oliveira, Neto. Estatística. São Paulo: Edgard Blücher,

1977. 264p.

CURRIER, Richard. Why you must factor in time when selecting software.

Financial Executive, v. 13, n. 5, p. 37-38, Sept./Oct. 1997.

DAVENPORT, Thomas H., SHORT, James E. The new industrial engineering:

information technology and business process redesign. Sloan Management

Review, v. 34, n. 4, p. 11-27, 1990.

DAVENPORT, Thomas H. Putting the enterprise into the enterprise system.

Harvard Business Review, v. 76, n. 4, p. 121-131, July/Aug. 1998.

DeLONE, William H., McLEAN, Ephraim R. Information systems success: the

quest for the dependent variable. Information Systems Research, v. 3, n. 1, p. 60-

95, Mar. 1992.

DEIS, Paul. Beyond MRP with AIMS. [Online.] Disponível na Internet via WWW.

URL: http://www.aimserp.com/bydmrpwp.htm. Arquivo capturado em 18 de

fevereiro de 1998.

DRUCKER, Peter F. Don’t change corporate culture: use it! In: LOVELOCK,

Christopher H. Managing services: Marketing, Operations and Human

Resources. 2. ed. Upper Saddle River, NJ: Prentice Hall, 1992. p. 406-408.

ERP ecosystem to flourish despite inroads by supply chain firms. AMR Research.

December 4, 1997. [Online.] Disponível na Internet via WWW. URL:

http://www.advmfg.com/press/971204.htm. Arquivo capturado em 2 de agosto

de 1998.


142

ERP penetration of process manufacturing industry to grow. AMR Research. April

23, 1997. [Online.] Disponível na Internet via WWW. URL:

http://www.advmfg.com/press/970423.htm. Arquivo capturado em 2 de agosto

de 1998.

ERP software market on a global tear. AMR Research. August 5, 1997. Online.

Available. http://www.advmfg.com/press/970805.htm. Arquivo capturado em 2

de agosto de 1998.

ERP market expanding globally. IEE Solutions, v. 29, n. 11, p. 8, Nov. 1997.

ERP RIP? The Economist, v. 352, n. 8125, p. 13-15 , June/July 1999.

FABRIMAR remodela produção com ERP. Computerworld, v. 6, n. 247, p. 10,

mar. 1998.

FARTO, Maria E. Nos bastidores do ERP. Computerworld, v. 6, n. 245, p. 6-7, mar.

1998a.

__________. Votorantim muda cultura com ERP. Computerworld, v. 6, n. 251, p. 6,

abr. 1998b.

FARLEY, Gregory A. Defining enterprise resource planning. APICS – The

Performance Advantage. March 1998. [Online.] Disponível na Internet via

WWW. URL: http://www.apics.org/OtherServices/Articles/defining.htm.

Arquivo capturado em 2 de agosto de 1998.

FIVE steps toward transformation. Datamation. March 1997. [Online.] Disponível

na Internet via WWW. URL:

http://www.datamation.com/PlugIn/issues/1997/march/5steps.html. Arquivo

capturado em 9 de março de 1998.

FONSECA, Jairo S., MARTINS, Gilberto A. Curso de Estatística. 4. ed. São Paulo:

Atlas, 1993. 317p.


143

FREEMAN, Eva. Manufacturing applications: what’s the right recipe? Datamation.

August 1997. [Online.] Disponível na Internet via WWW. URL:

http://www.datamation.com/PlugIn/workbench/mfgsys/stories/recipe.htm.

Arquivo capturado em 9 de março de 1998.

GESTÃO Empresarial. Computerworld Brasil – Guideline Especial. 30 de junho de

1997. [Online.] Disponível na Internet via WWW. URL:

http://www.idg.com.br/computerworld/computerworld/215/guideline/215guide0

1.htm. Arquivo capturado em 11 de fevereiro de 1998.

GINZBERG, Michael J. Key recurrent issues in the MIS implementation process.

MIS Quarterly, n. 5, p. 47-59, 1981.

GUMAER, Robert. Beyond ERP and MRP II: Optimized planning and

synchronized manufacturing. IEE Solutions, v. 28, n. 9, p. 32-35, Sept. 1996.

GROVER, Varun et al. The implementation of business process reengineering.

Journal of Management Information Systems, v. 12, n. 1, p. 109-144, 1995.

__________. A tutorial on survey research: from constructs to theory. IS World.

[Online.] Disponível na Internet via WWW. URL:

http://theweb.badm.sc.edu/grover/survey/MIS-SUVY.html. Arquivo capturado

em 29 de março de 1998.

HAIR, Joseph F., Jr. et al. Multivariate data analysis. 4. ed. Upper Saddle River, NJ:

Simon & Schuster, 1995, 751p.

HALLOWS, Jolyon. Information systems project management: how to deliver

function and value in information technology. New York: Amacon, 1997. 272p.

HAMMER, Michael, Reengineering work: don't automate, obliterate. Harvard

Business Review, v. 68, n. 4, p. 104-112, July/Aug. 1990.

HAMMER, Michael, CHAMPY J. Reengineering the corporation: a manifesto for

business revolution. London: Nicholas Brealey, 1993.


144

HYMAN, Herbert. Design and Analysis. Glencoe, Illinois: The Free Press, 1957.

HOW to find the right R/3 consultant. Datamation. [Online.] Disponível na Internet

via WWW. URL:

http://www.datamation.com/PlugIn/toolkits/implr3/howto.htm. Arquivo


KAY, Emily. Desperately seeking SAP support. Datamation. [Online.] Disponível


http://www.datamation.com/PlugIn/toolkits/implr3/seeking.htm. Arquivo


KINNEAR, Thomas C., TAYLOR, James R. Marketing research: an applied

approach. 4. ed. New York: McGraw-Hill, 1991. 856p.

KING, Julia. Project management ills cost businesses plenty. Computerworld, v. 31,

n. 38, p. 6, Sept. 1997.

KOCK, Christopher. Crossing no man’s land. CIO Magazine, v. 2, n. 5, Section 1,

p. 44-54, Dec. 1997.

KRUGLIANSKAS, Isaac. Engenharia simultânea: organização e implantação em

empresas brasileiras. Revista de Administração, São Paulo, v. 28, n. 4, p. 104-

110, out./dez. 1993.

KWON, Tae H., ZMUD, Robert. W. Unifying the Fragmented Models of

Information Systems Implementation. In: BOLAND Jr., Richard J.,

HIRSCHHEIM, Rudy A. Critical Issues in Information Systems Research. New

York: John Wiley and Sons, 1987. p. 227-251.

LEAVITT, Harold J. Applying organizational change in industry: structural

technological and humanistics approaches. In: Handbook of organizations.

Chicago: Rand McNally, 1965.


145

LAUDON, Kenneth C., LAUDON, Jane P. Information systems: a problem-solving

approach. 3. ed. Fort Worth, TX: The Dryden Press, 1995. 653p.

LARSEN, Melissa A., MYERS, Michael D. BPR success or failure? A business

process reengineering project in the financial services industry. In:

INTERNATIONAL CONFERENCE ON INFORMATION SYSTEMS, 18,

1997, Atlanta, Georgia. Proceedings... Atlanta, Georgia: [s.n], 1997. p. 367-382.

LIEBER, Ronald, JAYNES, Madeline. Here comes SAP. Fortune, v. 132, n. 7, p.

122-124, Oct. 1995.

LOZINSKY, Sérgio. Software: tecnologia do negócio: em busca de benefícios e de

sucesso na implementação de pacotes de software integrados. Rio de Janeiro:

Imago, 1996. 242p.

LUCAS Jr., Henry C. Why information systems fail. New York: Columbia

University Press, 1981.

MANZONI, Ralphe Jr. Crescimento acelerado: venda de pacotes ERP deve

explodir neste ano. Computerworld, 25 de maio de 1998. [Online.] Disponível


http://www.idg.com.br/computerworld/computerworld/255/soft_03.htm.

Arquivo capturado em 20 de agosto de 1998.

MANUFACTURING systems IT glossary. Manufacturing Systems. [Online.]

Disponível na Internet via WWW. URL:

http://www.manufacturingsystems.com/Glossary/index.shtml. Arquivo

capturado em 2 de agosto de 1998.

MARION, Larry. The 15% solution. Datamation. [Online.] Disponível na Internet

via WWW. URL:

http://www.datamation.com/PlugIn/issues/1998/may/05erp.html. Arquivo

capturado em 20 de agosto de 1998.


146

MARKUS, M. Lynne, BENJAMIN, Robert I. The magic bullet theory in IT-

enabled transformation. In: SETHI, Vikram, KING, William R. Organizational

transformation through business process reengineering: applying the lessons

learned. Upper Saddle River, NJ: Prentice Hall, 1998, p. 484-503.

MARTIN, James. Information engineering: book II: planning and analysis.

Englewood Cliffs: Prentice-Hall, 1990.

MATTAR, Fauze N. Pesquisa de marketing: edição compacta. São Paulo: Atlas,

1996. 270p.

McFARLAN, F. Warren. Information technology changes the way you compete.

Harvard Business Review, v. 62, n. 3, p. 98-103, 1984.

McLEOD, Raymond. Jr. Management information systems. 6. ed. Englewood

Cliffs: Prentice-Hall, 1995. 754p.

MICHEL, Roberto. Model citizens: ERP’s implementation tools provide process

framework, tie to workflow. Manufacturing Systems Magazine, v. 16, n. 2, p.

29-44, Feb. 1998.

__________. In with the new: ERP systems promise added functionality while

reducing Year 2000 problems. Manufacturing Systems Magazine, v. 15, Crunch

time – year 2000 supplement, p. 10A-16A, Sept. 1997a.

__________. Reinvention reigns: ER vendor redefine value, planning and elevate

customer service. Manufacturing Systems Magazine, v. 15, n. 7, p. 28-92, July

1997b.

MILLER, Delbert C. Handbook of research design and social measurement. New

York: Longman, 1977.

MIRANDA, Olga M. Zulzke. A implementação da tecnologia da informação em

um hospital: um estudo de caso. São Paulo, 1992. 197p. Dissertação (Mestrado)


147

– Faculdade de Economia, Administração e Contabilidade, Universidade de São

Paulo, 1992.

MUIR, James W. When should a package be considered? Washington, D.C.:

American Production and Inventory Control Society, 1979. p. 32-37.

NAVARRE, Christian, SCHAAN, Jean-Louis. Design of project management

systems from top management’s perspective. Project Management Journal, v.

21, n. 2, June 1990.

ORMAN, Levent V. A model management approach to business process

reengineering. In: AMERICAS CONFERENCE ON INFORMATION

SYSTEMS, 1, 1995, Pittsburgh, Pennsylvania. Proceedings... Pittsburgh,

Pennsylvania: [s.n], 1995. p. 100-102.

OTT, R. Lyman. An introduction to statistical methods and data analysis. 4 ed.

Belmont, California: Duxbury, 1993, 1121p.

PARASURAMAN, A. Marketing research. Reading, Mass: Addison-Wesley, 1986.

831p.

__________. Marketing research, 2.ed. Reading, Mass: Addison-Wesley, 1991.

898p.

PARKER, Kevin. Big, bigger, best. Manufacturing Systems Magazine, v. 15, n. 7,

p. 20-27, July 1997.

PARSONS, Michael. Surviving SAP. Inforworld, v. 19, n. 34, p. 19, Aug. 1997.

PINTO, Jeffrey K., SLEVIN, Dennis P. Project success: definitions and

measurement techniques. Project Management Journal, v. 19, n. 1, Feb. 1988a.

__________. Critical success factors across the project life cycle. Project

Management Journal, v. 19, n. 3, p. 67-75, June 1988b.


148

__________. Critical success factors in effective project implementation. In:

CLELAND, David I., KING, William R. Project management handbook. New

York: Van Nostrand Reinhold, 1988c. p. 479-512.

PISZCZALSKI, Martin. Lessons learned from Europe’s SAP users. Automotive

Manufacturing & Production, v. 109, n. 1, p. 54-56, Jan. 1997.

PORTER, Michael. Vantagem competitiva: criando se sustentando um desempenho

superior. Rio de Janeiro: Campus, 1989. 512p.

PROJECT MANAGEMENT INSTITUTE. A guide to the project management body

of knowledge. Upper Darby, PA: [s.n], 1996. 176p.

RADOSEVICH, Lynda. Quantum’s leap. CIO Magazine, v. 10, n. 9, p. 40-46, Feb.

1997.

RICHARDSON, Bruce. Plan for success. Manufacturing Systems Magazine, v. 14,

n. 5, p. 30, May 1996.

ROCKART, John F., DeLONG, David W. Executive information systems: The

emergence of top management computer use. Homewood, Ill: Dow Jones-Irwin,

1988.

ROBB, David J. Business process innovation: Reengineering for operations

renewal. Operations Management Review, v. 10, n. 3, p. 12-15, 1995.

RUPPEL, Cynthia P., HOWARD, Geoffry S. Facilitating innovation adoption and

diffusion: the case of telework. Information Resources Management Journal, v.

11, n. 3, p. 5-15, 1998.

SARLE, Warren S. Measurement theory: frequently asked questions.

Disseminations of the International Statistical Applications Institute. 4. ed.

Wichita: ACG Press, 1995. p. 61-66.

SAUER, C. et al. Fit, failure, and the house of horrors: toward a configurational

theory of IS project failure. In: INTERNATIONAL CONFERENCE ON


149

INFORMATION SYSTEMS, 18, 1997, Atlanta, Georgia. Proceedings...

Atlanta, Georgia: [s.n], 1997. p. 349-366.

SETHI, Vikram, KING, William R. Introduction to business process reengineering.

In: SETHI, Vikram, KING, William R. Organizational transformation through

business process reengineering: applying the lessons learned. Upper Saddle

River, NJ: Prentice Hall, 1998. p. 3-29.

SIEGEL, Sidnei. Estatística não-paramétrica: para as ciências do comportamento,

São Paulo: McGraw-Hill, 1975. 350p.

SLEVIN, Dennis, PINTO, Jeffrey K. P. The project implementation profile: new

tool for project managers. Project Management Journal, v. 17, n. 4, p. 57-70,

1986.

SPIEGEL, Murray R. Estatística. 2. ed. São Paulo: McGraw-Hill, 1985, 454p.

SPSS Inc. SPSS Base 8.0 Application Guide. Chicago, Il: [s.n], 1998. 372p.

STEVENS, Tim. Kodak focuses on ERP. Industry Week, v. 246, n. 15, p. 130-134,

Aug. 1997.

__________. ERP explodes: business is booming for enterprise-resource-planning

(ERP) systems that promise to coordinate an entire organization. Industry Week,

v. 245, n. 13, p. 37-40, July 1996.

STEVENSON, William J. Estatística aplicada à administração. São Paulo: Harper

& Row, 1981. 495p.

TEBBE, Mark. SAP’s initiatives focus on what the company denies: This stuff is

hard to install. Infoworld, v. 19, n. 35, p. 108, Sept. 1997.

THE BEST stuff Bill Gates doesn’t own. Fortune, v. 136, n. 9, p. 102, Nov. 1997.

TULL, Donald S., HAWKINGS, Del. L. Market research: meaning, measurement

and method: a text with cases. New York: MacMillan, 1976. 736p.


150

VASILASH, Gary S. ERP with fast implementation? Baan says it has it.

Automotive Manufacturing & Production Magazine, v. 108, n. 7, p. 44-45, July

1996.

__________. How to – and how not to – implement ERP. Automotive

Manufacturing & Production Magazine, v. 109, n. 8, p. 64-65, Aug. 1997.

VENKATRAMAN, N. IT-enabled business transformation: from automation to

business scope redefinition. In: SETHI, Vikram, KING, William R.

Organizational transformation through business process reengineering:

applying the lessons learned. Upper Saddle River, NJ: Prentice Hall, 1998. p.

461-483.

WESTON, Randy. ERP users find competitive advantages. Computerworld, v. 32,

n. 3, p. 9, Jan. 1998.

WHAT’S driving the explosive ERP market?. GT Online Technology. [Online.]

Disponível na Internet via WWW. URL:

http://www.grantthornton.com/gtonline/it/erp.html. Arquivo capturado em 11 de

março de 1998.

WHEN implementing an ERP system, streamline business processes but leave

software code alone. Industry Week, v. 246, n. 15, p. 133, Aug. 1997.

151

ANEXOS

Anexo 1: Carta de apresentação

USP – Universidade de São Paulo FEA – Faculdade de Economia, Administração e Contabilidade

PPGA – Programa de Pós-graduação em Administração Pesquisa “Projetos de Implementação de Sistemas para Gestão Empresarial”

São Paulo, abril de 1999. Ref.: Pesquisa sobre Sistemas de Gestão Empresarial – FEA/USP Prezado(a) Senhor(a), Investigar diversos aspectos dos projetos de implementação de sistemas para gestão empresarial – sistemas ERP – é o objetivo desta pesquisa, que é parte integrante de uma dissertação de mestrado. Para realizá-la, necessitamos de sua valiosa colaboração, encaminhando os 3 questionários em anexo ao gerente responsável pela implementação do sistema de gestão empresarial em sua organização, e aos gerentes ou responsáveis por 2 departamentos onde o sistema já tenha sido implementado. Estimamos que o preenchimento do questionário não tomará mais do que 15 minutos de seu tempo. Gostaríamos de esclarecer que os dados obtidos através deste questionário serão analisados em uma pesquisa acadêmica. Todas as respostas serão tratadas de forma confidencial e agregada, de maneira a que nenhuma resposta individual possa ser identificada. Por favor, leia com atenção todos os itens de cada questão. Não se sinta obrigado a procurar uma resposta “ideal”, pois não existe resposta certa ou errada. Simplesmente assinale aquela que estiver de acordo com a realidade existente em sua organização. Solicitamos o obséquio de responder o questionário e nos enviar pelo correio, utilizando-se do envelope, já preenchido e selado, que o acompanha. Se desejar receber, em primeira mão, o sumário executivo com os resultados da pesquisa, favor indicar no campo reservado para isso, no corpo do questionário. Em caso de qualquer dúvida, por favor entre em contato conosco. Agradecemos sua contribuição,

Prof. Dr. Nicolau Reinhard Professor da Área de Sistemas de Informação FEA / USP (011) 818-5838 [email protected]

Sidnei Bergamaschi Mestrando em Administração de Empresas FEA / USP (014) 227-2281 [email protected]

ANEXOS

153

Anexo 2: Questionário



1 / 6

Nome

Empresa

Departamento Cargo/Função

E-mail Fone Fax Endereço

Deseja receber os resultados desta pesquisa? Sim r Não r

1. Em que segmento de negócios sua empresa atua? ................................................................................................................................................

2. Qual a faixa de faturamento anual da sua empresa? (milhões de R$) r < 20 r 20-70 r 70-150 r 150-300 r >300

3. Qual é o número de funcionários de sua empresa? r < 100 r 100-500 r 500-1000 r 1000-3000 r >3000

4. Qual o número estimado de usuários para o sistema? r < 100 r 100-500 r 500-1000 r 1000-3000 r >3000

5. Qual o número de pessoas da empresa, na equipe de projeto? r < 5 r 5-10 r 11-20 r 21-50 r 51-100 r >100

6. Qual a data de início do projeto? ......... / ..........

7. Qual a data de término do projeto? (prevista ou realizada) ......... / ..........

8. Qual o principal pacote de software do projeto? ...............................................................................................................................

9. Qual a principal empresa de consultoria envolvida com o implementação do projeto? ......................................................................................... 10. Quais das alternativas abaixo melhor descrevem seu papel no projeto? (assinale quantas forem necessárias)

r Diretor do projeto r Membro do comitê de projeto r Gerente, coordenador ou responsável da empresa pelo projeto r Diretor ou gerente do projeto, por parte de consultoria r Consultor funcional r Consultor técnico r Analista de sistemas r Programador r Usuário-chave (key user) r Suporte técnico ou suporte de banco de dados r Usuário final do sistema r Outro: .........................................................................................



2 / 6

Preencha o quadro abaixo com uma estimativa atualizada dos gastos do projeto, até o momento. Itens de gastos Estimativa (mil R$)

11. Hardware (equipamentos, redes e telecomunicações, etc.) ......................................................

12. Software (licenças ERP, sistemas operacionais, bancos de dados e ferramentas, etc.) ......................................................

13. Serviços (consultoria externa, treinamento, customizações, etc.) ...................................................... Marque um ý nos módulos do sistema previstos no projeto, e um ý na situação atual dos mesmos. Módulos O módulo está

previsto no projeto Implementação do módulo foi iniciada

Implementação do módulo foi concluída

14. Industrial r r r 15. Contábil r r r 16. Financeira r r r 17. Compras r r r 18. Vendas r r r 19. Marketing r r r 20. Recursos Humanos r r r 21. Transportes r r r 22. Manutenção r r r 23. Controle de Projetos r r r 24. Serviços r r r 25. ................................................................................................................................. r r r

26. ................................................................................................................................. r r r

27. ................................................................................................................................. r r r



3 / 6

Em relação ao restante do questionário, caso o projeto ainda não esteja concluído, considere a parte do projeto que já foi implementada para responder as questões. 28. Cite, somente para as afirmações abaixo que representaram motivações para a realização do projeto, se as mesmas tiveram seus objetivos

atingidos com o projeto. Motivações ò

Não era uma motivação para o

projeto

O objetivo foi atingido

O objetivo não foi atingido

Necessidade de integração de informações e sistemas. r r r Redução de pessoal. r r r Busca de vantagem competitiva e outros benefícios potenciais. r r r Determinação da matriz ou de empresas controladoras. r r r Globalização de negócios, com atuação em outros países. r r r Substituição de sistemas por problemas com o ano 2000. r r r Pressão por parte de parceiros de negócios. r r r Maior necessidade de informações gerenciais para tomada de decisão. r r r Indicação feita por empresa de consultoria externa. r r r Necessidade de evolução na arquitetura de informática. r r r Redesenho de processos. r r r

........................................................................................................................................................ r r r

........................................................................................................................................................ r r r

........................................................................................................................................................ r r r

........................................................................................................................................................ r r r

........................................................................................................................................................ r r r



4 / 6

Em relação à mudanças ocorridas na empresa nos últimos anos, responda as perguntas abaixo. Perguntas ò

Sim Não

29. A empresa passou por processos de mudança (just-in-time, zero defeito, CCQ, TQC, kanban, kaizen, downsizing)?

r r

30. A resposta da empresa à pressões internas e externas é lenta? r r 31. A empresa é bastante inovadora em produtos e serviços? r r Em relação à implementação do projeto, responda as perguntas abaixo. Perguntas ò

Sim Não

32. Os objetivos do projeto eram claros para toda a equipe de projeto? r r 33. Os objetivos do projeto eram contraditórios? r r 34. A alta administração apoiou efetivamente o projeto? r r 35. A alta administração compreendia as necessidades de recursos (tempo, dinheiro, pessoal, etc.) necessários

para implementar o projeto? r r

36. Os usuários-chave compreendiam seu papel e estavam comprometidos com o sucesso do projeto? r r 37. Os usuários–chave envolvidos no projeto possuíam conhecimento e as habilidades necessárias? r r 38. Existia um plano detalhado dos recursos necessários (tempo, dinheiro, equipamentos, etc.) para completar

o projeto? r r

39. Não havia um plano de contingência, caso o projeto estivesse fora do prazo? r r 40. Existia um gerente de projeto dedicado em tempo integral ao projeto? r r 41. O gerente do projeto não possuía a experiência e habilidades necessárias para a conclusão do mesmo? r r 42. Havia a presença formal de uma empresa de consultoria externa no projeto? r r 43. A consultoria externa acompanhou todas as atividades do projeto? r r 44. Os processos de negócios foram integrados mas não sofreram mudanças? r r 45. Os processos de negócios da empresa são iguais ao que eram antes do projeto? r r



5 / 6

Classifique os 7 fatores listados abaixo em ordem de importância (1 para o mais importante, 7 para o menos importante) em cada uma das 4

fases do projeto apresentadas. Se o fator apresentado não for relevante em alguma fase, deixe em branco.

Fases ð Fatores ò

Escolha do software e decisão de implementá-lo

Criação do plano de implementação do projeto.

Simulação de processos, modelagem de dados e processos, desenvolvimento de interfaces e customizações.

Parametrização do sistema, treinamento do usuário final, colocação do sistema em produção.

46. Possuir um planejamento detalhado do projeto. 47. As missões do projeto serem claras e definidas. 48. Ocorrer mudança nos processos de negócios da empresa. 49. Uma empresa de consultoria externa estar presente. 50. Os usuários serem capazes e envolvidos com o projeto. 51. Possuir apoio da alta administração. 52. O gerente de projeto possuir as habilidades necessárias. Em relação ao uso do sistema após sua implementação, responda as perguntas abaixo. Perguntas ò

Sim Não

53. As informações fornecidas pelo sistema são consideradas potencialmente úteis para o processo de tomada de decisão? r r

54. Os recursos de informações gerenciais do sistema são completamente explorados? r r 55. As informações gerenciais extraídas a partir do sistema são usadas correntemente na empresa? r r 56. Os processos de tomada de decisão foram alterados com o uso do sistema? r r



6 / 6

Forneça, para cada uma das afirmações abaixo, uma nota de 0 a 10 que indique seu grau de concordância com as mesmas. Afirmações ò

0 1 2 3 4 5 6 7 8 9 10

57. O tempo para a execução do projeto foi menor ou igual ao previsto. r r r r r r r r r r r 58. O custo para a execução do projeto foi menor ou igual ao previsto. r r r r r r r r r r r 59. A qualidade e desempenho apresentados pelo sistema foi igual ou superior ao esperado. r r r r r r r r r r r 60. Houve melhora no funcionamento da empresa provocada ou motivada pelo sistema. r r r r r r r r r r r 61. Quais das alternativas abaixo melhor descrevem a estratégia usada para a colocação do sistema em produção? (assinale quantas forem

necessárias)

r Conversão direta, única ou big bang, quando todos os módulos do sistema são colocados em operação ao mesmo tempo em que ocorre o desligamento do sistema antigo (se este existir).

r Conversão em fases ou parcial, quando os módulos do sistema são colocados aos poucos, sendo desenvolvidas interfaces para os sistemas atuais, que são retiradas à medida que novos módulos são implantados.

r Conversão em paralelo, quando o sistema novo é colocado em produção sem o desligamento do antigo, sendo os processos executados em ambos os sistemas e os resultados comparados até que se decida pelo desligamento do sistema antigo.

r Ainda não ocorreu nenhuma conversão.

r Outra: ....................................................................................................................................................................................................................

Em relação aos sistemas usados na empresa antes da implementação do pacote de software, responda as perguntas abaixo. Perguntas ò

Sim Não

62. O sistema fornecia informações suficientes? r r 63. As informações geradas eram claras, confiáveis e úteis? r r 64. O sistema era fácil de ser usado? r r 65. O sistema não integrava informações das diversas áreas da empresa? r r 66. Quando alterações eram necessárias, estas eram rapidamente introduzidas nos sistemas? r r 67. O sistema era tecnologicamente atualizado? r r

ANEXOS

160

Anexo 3: Ranking das 100 maiores empresas de software para manufatura, nos EUA

Fonte: Manufacturing Systems, 1998.

1. SAP AG Vendas de Software: US$2083 milhões Vendas Totais: US$ 3000 milhões Categorias de Software: ERP MRP II. Produto: R/2, R/3 Plataformas de servidor: NT, OS/400, Unix, Reliant,Solaris. Plataformas de banco de dados: IBM DB2, Informix, MS SQL Server, Oracle.

2. Oracle Corp. Vendas de Software: US$1509 milhões Vendas Totais: US$ 6303 milhões Categorias de Software: ERP MRP II. Produto: Oracle Applications Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Oracle.

3. The Baan Co. Vendas de Software: US$684 milhões Vendas Totais: US$ 684 milhões Categorias de Software: Configurators, Demand Planning, ERP MRP II, Planning, Advanced, Supply Chain Mgmt. Produto: Baan Series Plataformas de servidor: NT, Unix. Plataformas de banco de dados: IBM DB2, Informix, MS SQL Server, Oracle, Sybase.

4. J.D. Edwards Vendas de Software: US$648 milhões Vendas Totais: US$ 648 milhões Categorias de Software: Demand Planning, ERP MRP II, Financials, Accounting and Business Mgmt., Supply Chain Mgmt, Transportation Planning, Warehouse Management. Produto: OneWorld, Genesis, WorldSoftware, WorldVision Plataformas de servidor: NT, OS/400, Unix, Digital VMS. Plataformas de banco de dados: IBM DB2, MS SQL Server, Oracle.

5. System Software Associates (SSA) Vendas de Software: US$431 milhões Vendas Totais: US$ 431 milhões Categorias de Software: ERP MRP II, Maintenance Management, Warehouse Management. Produto: BPCS Plataformas de servidor: OS/400, Unix. Plataformas de banco de dados: Informix, Oracle.

6. JBA International Vendas de software: US$363 milhões Vendas totais: US$ 363 milhões Categorias de software: ERP MRP II, Warehouse Management. Produto: System21 Plataformas de servidor: NT, OS/400, Unix. Plataformas de banco de dados: IBM DB2, Oracle.

7. Acacia Technologies – Divisão da Computer Associates International Categorias de software: ERP MRP II. Produto: PRMS, KBM, Quick Response Engine Plataformas de servidor: OS/400. Plataformas de banco de dados: IBM DB2, Other DBMS.

7. MK Group – Divisão da Computer Associates International Categorias de software: ERP MRP II. Produto: MK Enterprise Plataformas de servidor: DEC Open VMS, NT, Unix. Plataformas de banco de dados: Informix, Ingres, MS SQL Server, Oracle.

7. Computer Associates International Vendas de software: US$301 milhões Vendas totais: US$ 4462 milhões Categorias de software: ERP MRP II, Scheduling, Warehouse Management. Produto: PRMS, Warehouse Boss, MK Enterprise, Manufacturing, Logistics Plataformas de servidor: DEC Open VMS, Novell Netware, NT, OS/400, Unix, Windows 95/98, MVS. Plataformas de banco de dados: Ingres, MS SQL Server, Oracle, Sybase, ODBC Compliant.

8. FileNET Corp. Vendas de software: US$251 milhões Vendas totais: US$ 251 milhões Categorias de software: Data Management. Produto: FileNET Panagon Desktop Plataformas de servidor: Novell Netware, NT, OS/400, Unix, Windows 95/98. Plataformas de banco de dados: MS SQL Server, Oracle, Sybase.

9. Intentia International Vendas de software: US$216 milhões Vendas totais: US$ 216 milhões

ANEXOS

161

Categorias de software: Configurators, Demand Planning, Distribution Planning, ERP MRP II, Maintenance Management, Project Management, Quality Management, Supply Chain Mgmt, Transportation Planning. Produto: MOVEX Plataformas de servidor: OS/400. Plataformas de banco de dados: Other DBMS. 10. i2 Technologies Vendas de software: US$201 milhões Vendas totais: US$ 201 milhões Categorias de software: Supply Chain Mgmt. Produto: Rhythm, Think Demand, Optiflex Plataformas de servidor: NT, Unix, Windows 95/98. Plataformas de banco de dados: IBM DB2, Informix, Ingres, MS Access, MS SQL Server, Oracle,

11. Indus International Vendas de software: US$177 milhões Vendas totais: US$ 177 milhões Categorias de software: Maintenance Management. Produto: PassPort, EMPAC Plataformas de servidor: NT, Unix.

12. QAD Vendas de software: US$172 milhões Vendas totais: US$ 172 milhões Categorias de software: Demand Planning, Distribution Planning, ERP MRP II, Supply Chain Mgmt, Warehouse Management. Produto: MFG/PRO Plataformas de servidor: NT, Unix, Windows 95/98. Plataformas de banco de dados: Oracle, Progress.

13. SAS Institute Vendas de software: US$165 milhões Vendas totais: US$ 750 milhões Categorias de software: Data Management. Produto: SAS Quality Warehouse Plataformas de servidor: NT, Unix.

14. DataWorks Corp. Vendas de software: US$147 milhões Vendas totais: US$ 147 milhões Categorias de software: Configurators, Data Management, Demand Planning, ERP MRP II, Financials, Accounting and Business Mgmt., MES, Project Management, Quality Management, Scheduling, Supply Chain Mgmt, Warehouse Management. Produto: DataFLO, MANFACT, Vantage, Vista, Enterprise Client/Server

Plataformas de servidor: DEC Open VMS, NT, Unix. Plataformas de banco de dados: MS SQL Server, Other DBMS.

15. Manugistics Vendas de software: US$145 milhões Vendas totais: US$ 145 milhões Categorias de software: Supply Chain Mgmt. Produto: Manugistics5 Plataformas de servidor: NT, Unix, MVS VME.

16. PeopleSoft Vendas de software: US$122 milhões Vendas totais: US$ 816 milhões Categorias de software: Configurators, Distribution Planning, ERP MRP II, Planning, Advanced, Supply Chain Mgmt. Produto: PeopleSoft Manufacturing Plataformas de servidor: NT, OS/400, Unix, Windows 95/98, MS/Windows 3.1, Windows NT. Plataformas de banco de dados: IBM DB2, Informix, MS SQL Server, Oracle, Sybase.

17. American Software Vendas de software: US$103 milhões Vendas totais: US$ 103 milhões Categorias de software: Demand Planning, Distribution Planning, ERP MRP II, Supply Chain Mgmt, Transportation Planning, Warehouse Management. Produto: Intelliprise Plataformas de servidor: OS/400, Unix. Plataformas de banco de dados: IBM DB2, Oracle.

18. MAPICS Vendas de software: US$102 milhões Vendas totais: US$ 102 milhões Categorias de software: ERP MRP II. Produto: MAPICS Plataformas de servidor: OS/400.

19. Marcam Solutions Vendas de software: US$99 milhões Vendas totais: US$ 99 milhões Categorias de software: ERP MRP II, Financials, Accounting and Business Mgmt., Maintenance Management, Supply Chain Mgmt. Produto: Protean, Prism, Avantis Plataformas de servidor: NT, OS/400, Unix, Windows 95/98. Plataformas de banco de dados: IBM DB2, Informix, MS SQL Server, Oracle.

20. PSDI Vendas de software: US$50 milhões

ANEXOS

162

Vendas totais: US$ 98 milhões Categorias de software: Maintenance Management. Produto: MAXIMO Plataformas de servidor: Novell Netware, NT, OS/400, Unix, Windows 95/98. Plataformas de banco de dados: MS SQL Server, Oracle, Sybase, Centura SQL Base.

21. ABB Industrial Systems Vendas de software: US$95 milhões Vendas totais: US$ 3251 milhões Categorias de software: MES, Quality Management, Supervisory Control, Supply Chain Mgmt. Produto: Advant Plataformas de servidor: NT, Unix, Windows 95/98. Plataformas de banco de dados: MS Access, MS SQL Server, Oracle.

22. Infinium Software Vendas de software: US$56 milhões Vendas totais: US$ 93 milhões Categorias de software: ERP MRP II, Maintenance Management, Warehouse Management. Produto: Infinium Process Manufacturing Plataformas de servidor: NT, OS/400. Plataformas de banco de dados: IBM DB2, MS SQL Server, Oracle.

23. Industri-Matematik International (IMI) Vendas de software: US$47 milhões Vendas totais: US$ 87 milhões Categorias de software: Demand Planning, Supply Chain Execution, Distribution Planning, Supply Chain Mgmt, Warehouse Management. Produto: System ESS Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Oracle.

24. Kronos Vendas de software: US$84 milhões Vendas totais: US$ 178 milhões Categorias de software: MES. Produto: Datakeeper, ShopTrac, Timekeeper Plataformas de servidor: DEC Open VMS, Novell Netware, NT, OS/400, Unix, Windows 95/98. Plataformas de banco de dados: IBM DB2, Informix, MS SQL Server, Oracle.

25. Wonderware Corp. Vendas de software: US$83 milhões Vendas totais: US$ 83 milhões Categorias de software: MES, Supervisory Control.

Produto: InTouch, InTrack, InBatch, InSupport Plataformas de servidor: NT, Windows 95/98. Plataformas de banco de dados: MS Access, MS SQL Server.

26. Ross Systems Vendas de software: US$67 milhões Vendas totais: US$ 82 milhões Categorias de software: ERP MRP II, Financials, Accounting and Business Mgmt., Maintenance Management, Planning, Advanced, Quality Management, Supply Chain Mgmt. Produto: Renaissance CS Plataformas de servidor: DEC Open VMS, NT, Unix. Plataformas de banco de dados: MS SQL Server, Oracle, DEC RDB.

27. IFS Industrial & Financial Systems Vendas de software: US$80 milhões Vendas totais: US$ 80 milhões Categorias de software: Configurators, ERP MRP II, Financials, Accounting and Business Mgmt., Maintenance Management, MES, Project Management, Scheduling, Supply Chain Mgmt, Transportation Planning, Warehouse Management. Produto: IFS Applications Plataformas de servidor: DEC Open VMS, NT, Unix, Windows 95/98. Plataformas de banco de dados: Oracle.

28. Rockwell Software Vendas de software: US$80 milhões Vendas totais: US$ 80 milhões Categorias de software: MES, Supervisory Control. Produto: ControlView, WINtelligent Series Plataformas de servidor: NT, Windows 95/98, Intel-based PCs.

29. Tetra International Vendas de software: US$75 milhões Vendas totais: US$ 80 milhões Categorias de software: Configurators, Distribution Planning, ERP MRP II, Financials, Accounting and Business Mgmt., Maintenance Management, Project Management, Scheduling, Warehouse Management. Produto: Tetra CS/3 Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Informix, MS SQL Server, Oracle.

30. Micro-MRP Vendas de software: US$65 milhões

ANEXOS

163

Vendas totais: US$ 80 milhões Categorias de software: ERP MRP II. Produto: MAX for Windows Plataformas de servidor: Novell Netware, NT, Citrix Winframe. Plataformas de banco de dados: Btrieve.

31. Symix Computer Systems Vendas de software: US$78 milhões Vendas totais: US$ 78 milhões Categorias de software: Configurators, ERP MRP II, Financials, Accounting and Business Mgmt., Project Management, Quality Management. Produto: SyteLine Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Progress.

32. Documentum Vendas de software: US$48 milhões Vendas totais: US$ 76 milhões Categorias de software: ERP MRP II. Produto: Documentum EDMS Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Informix, MS SQL Server, Oracle, Sybase.

33. Datasul Vendas de software: US$74 milhões Vendas totais: US$ 74 milhões Categorias de software: ERP MRP II. Produto: Datasul EMS Plataformas de servidor: Novell Netware, NT, OS/400, Unix, Windows 95/98. Plataformas de banco de dados: Progress.

34. McHugh Software International Vendas de software: US$74 milhões Vendas totais: US$ 74 milhões Categorias de software: Supply Chain Execution, Supply Chain Mgmt, Transportation Planning, Warehouse Management. Produto: McHugh Logistics System (LES) Plataformas de servidor: NT, Unix, HP, Sun. Plataformas de banco de dados: MS SQL Server, Oracle.

35. Metaphase Technology Vendas de software: US$74 milhões Vendas totais: US$ 74 milhões Produto: Metaphase Enterprise

36. MAI Systems Corp. Vendas de software: US$72 milhões Vendas totais: US$ 72 milhões Categorias de software: ERP MRP II. Produto: CIMPRO Plataformas de servidor: NT, OS/400, Unix, Windows 95/98.

Plataformas de banco de dados: MS SQL Server, Oracle.

37. Intellution Vendas de software: US$71 milhões Vendas totais: US$ 71 milhões Categorias de software: MES, Supervisory Control. Produto: FIX, PlantTV, VisualBatch, Paradym-31 Plataformas de servidor: NT.

38. Datastream Systems Vendas de software: US$70 milhões Vendas totais: US$ 70 milhões Categorias de software: Maintenance Management. Produto: MP2 Enterprise, MaintainIt Plataformas de servidor: DEC Open VMS, Novell Netware, NT, OS/400, Unix, Windows 95/98. Plataformas de banco de dados: MS Access, MS SQL Server, Oracle.

39. Cincom Systems Vendas de software: US$64 milhões Vendas totais : US$ 165 milhões Categorias de software: Configurators, ERP MRP II. Produto: Cincom CONTROL, Cincom MANAGE:Enterprise Plataformas de servidor: DEC Open VMS, NT, Unix, Windows 95/98, OS/390. Plataformas de banco de dados: MS Access, Oracle.

40. EXE Technologies Vendas de software: US$60 milhões Vendas totais: US$ 60 milhões Categorias de software: Supply Chain Execution, Supply Chain Mgmt, Warehouse Management. Produto: Exceed Plataformas de servidor: NT, Unix. Plataformas de banco de dados: IBM DB2, Informix, MS SQL Server, Oracle.

41. HK Systems Vendas de software: US$59 milhões Vendas totais: US$ 209 milhões Categorias de software: Supply Chain Execution, Warehouse Management. Produto: Supply Chain Management Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Informix, MS SQL Server, Oracle, Sybase.

42. Trilogy Development Group Vendas de software: US$40 milhões Vendas totais: US$ 55 milhões

ANEXOS

164

Categorias de software: Configurators. Produto: Selling Chain Plataformas de servidor: NT, Windows 95/98. Plataformas de banco de dados: MS SQL Server, Oracle, Sybase, Any ODBC Compliant.

43. Fourth Shift Corp. Vendas de software: US$52 milhões Vendas totais: US$ 52 milhões Categorias de software: ERP MRP II. Produto: MSS, OBJECTS Enterprise Software Plataformas de servidor: Novell Netware, NT. Plataformas de banco de dados: MS SQL Server, Other DBMS.

44. Aspect Development Vendas de software: US$50 milhões Vendas totais: US$ 50 milhões Categorias de software: Supply Chain Execution, Supply Chain Mgmt. Produto: Explore CSM Plataformas de banco de dados: Oracle.

45. Lilly Software Associates Vendas de software: US$45 milhões Vendas totais: US$ 45 milhões Categorias de software: Configurators, Data Management, ERP MRP II, Financials, Accounting and Business Mgmt., MES, Planning, Advanced, Quality Management, Scheduling. Produto: VISUAL Manufacturing Plataformas de servidor: Novell Netware, NT, OS/400. Plataformas de banco de dados: IBM DB2, MS SQL Server, Oracle, Centura SQL.

46. Effective Management Systems (EMS) Vendas de software: US$44 milhões Vendas totais: US$ 44 milhões Categorias de software: ERP MRP II, MES. Produto: TCM Plataformas de servidor: DEC Open VMS, NT, Unix. Plataformas de banco de dados: Oracle.

47. Glovia International Vendas de software: US$42 milhões Vendas totais: US$ 42 milhões Categorias de software: Configurators, ERP MRP II, Project Management, Supply Chain Mgmt. Produto: GLOVIA Plataformas de servidor: NT, Unix. Plataformas de banco de dados: MS SQL Server, Oracle.

48. GE Fanuc Automation Vendas de software: US$41 milhões Vendas totais: US$ 3000 milhões Categorias de software: MES, Supervisory Control. Produto: CIMplicity Plataformas de servidor: NT, Windows 95/98. Plataformas de banco de dados: MS Access.

49. SCT Corp. Manufacturing & Distribution Systems Division Vendas de software: US$41 milhões Vendas totais: US$ 317 milhões Categorias de software: ERP MRP II, Supply Chain Mgmt. Produto: Adage Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Informix, Ingres, MS SQL Server, Oracle.

50. Consilium Vendas de software: US$41 milhões Vendas totais: US$ 41 milhões Categorias de software: MES. Produto: Workstream DFS, Flowstream Plataformas de servidor: DEC Open VMS, Unix.

51. R + H America, Vendas de software: US$40 milhões Vendas totais: US$ 40 milhões Categorias de software: Data Management, ERP MRP II, Financials, Accounting and Business Mgmt., Planning, Advanced, Quality Management, Supply Chain Mgmt.

52. Sherpa Corp. Vendas de software: US$40 milhões Vendas totais: US$ 40 milhões Categorias de software: Data Management. Produto: SherpaWORKS

53. ORSI America Vendas de software: US$36 milhões Vendas totais: US$ 36 milhões Categorias de software: Maintenance Management, MES, Quality Management, Supervisory Control. Produto: CUBE Plataformas de servidor: NT. Plataformas de banco de dados: IBM DB2, Informix, Ingres, MS Access, MS SQL Server, Oracle, Sybase.

54. Gensym Corp. Vendas de software: US$20 milhões Vendas totais: US$ 36 milhões

ANEXOS

165

Categorias de software: MES, Scheduling, Supervisory Control. Produto: G2 Plataformas de servidor: DEC Open VMS, NT, Unix. Plataformas de banco de dados: IBM DB2, Informix, Ingres, MS Access, MS SQL Server, Oracle, Sybase.

55. Numetrix Vendas de software: US$35 milhões Vendas totais: US$ 35 milhões Categorias de software: Demand Planning, Distribution Planning, Planning, Advanced, Scheduling, Supply Chain Mgmt, Transportation Planning. Produto: Numetrix/3 Plataformas de servidor: NT, Unix.

56. Western Data Systems Vendas de software: US$35 milhões Vendas totais: US$ 35 milhões Categorias de software: ERP MRP II. Produto: CompassENTERPRISE Plataformas de servidor: Unix, Windows 95/98. Plataformas de banco de dados: Oracle.

57. Syspro Impact Software Vendas de software: US$30 milhões Vendas totais: US$ 35 milhões Categorias de software: Configurators, ERP MRP II, Financials, Accounting and Business Mgmt., MES, Project Management, Supply Chain Mgmt, Warehouse Management. Produto: Impact Award, Impact Encore Plataformas de servidor: Novell Netware, NT, Unix, Windows 95/98. Plataformas de banco de dados: MS SQL Server, Btrieve,CI SAM.

58. Lawson Software Vendas de software: US$34 milhões Vendas totais: US$ 171 milhões Categorias de software: ERP MRP II. Produto: Open Enterprise--Financials, Human Resources, Distribution, Materials Management

59. Optum Software Vendas de software: US$34 milhões Vendas totais: US$ 34 milhões Categorias de software: Supply Chain Execution, Warehouse Management. Produto: Move Warehouse Management System Plataformas de servidor: NT, Unix.

60. PowerCerv Corp. Vendas de software: US$23 milhões

Vendas totais: US$ 33 milhões Categorias de software: Configurators, Distribution Planning, ERP MRP II, Financials, Accounting and Business Mgmt.. Produto: ERP Plus Plataformas de servidor: NT, Unix. Plataformas de banco de dados: MS SQL Server, Sybase.

61. Ci Technologies Vendas de software: US$22 milhões Vendas totais: US$ 33 milhões Categorias de software: Quality Management, Supervisory Control. Produto: CITECT Opensuite Plataformas de servidor: NT, Windows 95/98. Plataformas de banco de dados: IBM DB3.

62. Logility Vendas de software: US$32 milhões Vendas totais: US$ 32 milhões Categorias de software: Planning, Advanced, Supply Chain Mgmt, Transportation Planning, Warehouse Management. Produto: Logility Value Chain Solutions Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Oracle.

63. OSI Software Vendas de software: US$32 milhões Vendas totais: US$ 32 milhões Produto: PI-ProcessBook 2.0

64. Macola Vendas de software: US$16 milhões Vendas totais: US$ 30 milhões Categorias de software: Configurators, Distribution Planning, ERP MRP II, Project Management, Scheduling. Produto: Progression Plataformas de servidor: Novell Netware, NT, Windows 95/98. Plataformas de banco de dados: MS SQL Server, Btreve.

65. HarrisData Vendas de software: US$23 milhões Vendas totais: US$ 29 milhões Categorias de software: ERP MRP II. Produto: Manufacturing Enterprise Plataformas de servidor: OS/400, System 36. Plataformas de banco de dados: IBM DB2.

66. Pivotpoint Vendas de software: US$26 milhões Vendas totais: US$ 26 milhões Categorias de software: ERP MRP II. Produto: Point.MAN, Minxware, GrowthPower

ANEXOS

166

Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Oracle.

67. Ramco Systems Vendas de software: US$17 milhões Vendas totais: US$ 26 milhões Categorias de software: ERP MRP II, Financials, Accounting and Business Mgmt., Maintenance Management, Quality Management, Supply Chain Mgmt. Produto: Ramco Marshall Plataformas de servidor: NT. Plataformas de banco de dados: MS SQL Server.

68. FASTech Integration Vendas de software: US$24 milhões Vendas totais: US$ 24 milhões Categorias de software: MES. Produto: FACTORYworks, STATIONworks, CELLworks Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Oracle.

69. Promis Systems Corp. Vendas de software: US$24 milhões Vendas totais: US$ 24 milhões Categorias de software: MES. Produto: PROMIS Plataformas de servidor: NT. Plataformas de banco de dados: Oracle.

70. Friedman Corp. Vendas de software: US$23 milhões Vendas totais: US$ 23 milhões Categorias de software: Configurators, ERP MRP II. Produto: Frontier Plataformas de servidor: OS/400. Plataformas de banco de dados: IBM DB2, MS Access, MS SQL Server.

71. Catalyst International Vendas de software: US$23 milhões Vendas totais: US$ 23 milhões Categorias de software: Supply Chain Execution, Warehouse Management. Produto: CatalystWMS Plataformas de servidor: Unix. Plataformas de banco de dados: None.

72. USDATA Corp. Vendas de software: US$22 milhões Vendas totais: US$ 22 milhões Categorias de software: MES, Supervisory Control. Produto: FactoryLink ECS Plataformas de servidor: NT, Unix, Windows 95/98.

Plataformas de banco de dados: MS SQL Server, Oracle, Sybase, Any ODBC Compliant.

73. Visibility Vendas de software: US$22 milhões Vendas totais: US$ 22 milhões Categorias de software: ERP MRP II. Produto: Visibility Plataformas de servidor: DEC Open VMS, NT, Unix. Plataformas de banco de dados: Oracle.

74. Descartes Systems Group Vendas de software: US$16 milhões Vendas totais: US$ 21 milhões Categorias de software: Supply Chain Execution, Distribution Planning. Produto: ENERGY Plataformas de servidor: DEC Open VMS, NT, Unix, IBM MVS. Plataformas de banco de dados: IBM DB2, Informix, MS SQL Server, Oracle, Sybase.

75. Dados não fornecidos

76. Profitkey International Vendas de software: US$20 milhões Vendas totais: US$ 20 milhões Categorias de software: ERP MRP II, Financials, Accounting and Business Mgmt., Scheduling. Produto: Rapid Response Manufacturing Client/Server Plataformas de servidor: NT. Plataformas de banco de dados: Oracle.

77. ROI Systems Vendas de software: US$18 milhões Vendas totais: US$ 18 milhões Categorias de software: Configurators, ERP MRP II. Produto: Manage 2000 Plataformas de servidor: NT, Unix.

78. CIMLINC Vendas de software: US$18 milhões Vendas totais: US$ 18 milhões Categorias de software: MES. Produto: Shop Excellerator Plataformas de servidor: NT, Unix.

79. Chesapeake Decision Sciences Vendas de software: US$17 milhões Vendas totais: US$ 17 milhões Categorias de software: Demand Planning, Distribution Planning, Planning, Advanced, Scheduling, Supply Chain Mgmt, Transportation Planning. Produto: MIMI

ANEXOS

167

Plataformas de servidor: NT, Unix, Solaris,DEC Alpha. Plataformas de banco de dados: IBM DB2, Informix, Ingres, MS Access, MS SQL Server, Oracle, Sybase.

80. Industrial Computer Corp. (ICC) Vendas de software: US$17 milhões Vendas totais: US$ 17 milhões Categorias de software: MES. Produto: Shop Floor Data Manager Plataformas de servidor: Unix. Plataformas de banco de dados: Informix, Oracle.

81. Made2Manage Systems Vendas de software: US$16 milhões Vendas totais: US$ 16 milhões Categorias de software: ERP MRP II. Produto: Made2Manage Plataformas de servidor: Novell Netware, NT. Plataformas de banco de dados: Visual Studio.

82. Aremis Soft Corp. Vendas de software: US$16 milhões Vendas totais: US$ 45 milhões Categorias de software: ERP MRP II. Produto: Aremis Enterprise Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Informix, Oracle.

83. Haushahn Systems & Engineers Vendas de software: US$15 milhões Vendas totais: US$ 15 milhões Categorias de software: Supply Chain Execution, Warehouse Management. Produto: VIAWARE Plataformas de servidor: DEC Open VMS, OS/400, Sun, HP.

84. SynQuest Vendas de software: US$12 milhões Vendas totais: US$ 15 milhões Categorias de software: MES, Planning, Advanced. Produto: SynQuest Supply Chain Performance Series Plataformas de servidor: NT, Unix. Plataformas de banco de dados: Oracle.

85. Telesis Computer Corp. Vendas de software: US$13 milhões Vendas totais: US$ 14 milhões Categorias de software: Configurators, ERP MRP II. Produto: Telesis MFG Plataformas de servidor: NT, Unix.

86. Camstar Systems Vendas de software: US$14 milhões Vendas totais: US$ 14 milhões Categorias de software: MES. Produto: MESA Plataformas de servidor: OS/400. Plataformas de banco de dados: IBM DB2.

87. Relevant Business Systems Vendas de software: US$13 milhões Vendas totais: US$ 13 milhões Categorias de software: Configurators, Demand Planning, ERP MRP II, Financials, Accounting and Business Mgmt., Project Management, Supply Chain Mgmt. Produto: INFIMACS II Plataformas de servidor: Novell Netware, NT, Unix. Plataformas de banco de dados: Informix, MS SQL Server, Oracle.

88. CMS Manufacturing Systems Vendas de software: US$13 milhões Vendas totais: US$ 13 milhões Categorias de software: ERP MRP II, Maintenance Management, Quality Management, Warehouse Management. Produto: CMS/400 Plataformas de servidor: OS/400. Plataformas de banco de dados: IBM DB2.

89. Scala North America Vendas de software: US$12 milhões Vendas totais: US$ 60 milhões Categorias de software: ERP MRP II. Produto: SCALA Plataformas de servidor: Novell Netware, NT. Plataformas de banco de dados: MS SQL Server.

90. CMI-Competitive Solutions - Subsidiary of CMI-International Vendas de software: US$12 milhões Vendas totais: US$ 12 milhões Categorias de software: ERP MRP II. Produto: TRANS4M Plataformas de servidor: NT, Unix.

91. AutoSimulations Vendas de software: US$11 milhões Vendas totais: US$ 11 milhões Categorias de software: Planning, Advanced, Scheduling. Produto: AutoMod Plataformas de servidor: NT, Unix. Plataformas de banco de dados: MS SQL Server, Oracle, Sybase.

ANEXOS

168

92. Immpower Vendas de software: US$11 milhões Vendas totais: US$ 11 milhões

93. ILOG Vendas de software: US$10 milhões Vendas totais: US$ 42 milhões Produto: Optimization Suite Plataformas de servidor: Unix. Plataformas de banco de dados: Informix, Oracle, Sybase.

94. Calico Technology Vendas de software: US$10 milhões Vendas totais: US$ 10 milhões Categorias de software: Configurators. Plataformas de servidor: NT, Windows 95/98, Solaris. Plataformas de banco de dados: ODBC Compliant.

95. Smart Shop Software Vendas de software: US$10 milhões Vendas totais: US$ 10 milhões Categorias de software: Configurators, ERP MRP II, Project Management, Scheduling. Produto: Smart Shop Manager 96. Paragon Management Systems Vendas de software: US$10 milhões Vendas totais: US$ 10 milhões Categorias de software: Planning, Advanced, Scheduling. Plataformas de servidor: NT, Unix. Plataformas de banco de dados: IBM DB2, Informix, Ingres, MS Access, MS SQL Server, Oracle, Sybase, Other DBMS.

97. Platinum Software Corporation Vendas de software: US$10 milhões Vendas totais: US$ 74 milhões Categorias de software: ERP MRP II.

98. Powerway Vendas de software: US$8 milhões Vendas totais: US$ 8 milhões Categorias de software: Quality Management. Produto: Powerway Suite Solution Plus Plataformas de servidor: NT, Windows 95/98. Plataformas de banco de dados: MS SQL Server, Oracle, Sybase.

99. CIM Vision International Vendas de software: US$8 milhões Vendas totais: US$ 8 milhões Categorias de software: MES, Quality Management, Warehouse Management. Produto: CIM+

Plataformas de servidor: Novell Netware, NT, OS/400, Unix. Plataformas de banco de dados: IBM DB2, Ingres, MS Access, MS SQL Server, Oracle.

100. STG Americas Vendas de software: US$8 milhões Vendas totais: US$ 8 milhões Categorias de software: Planning, Advanced, Supply Chain Mgmt. Produto: OPT Solution suite Plataformas de servidor: DEC Open VMS, NT, Unix, Windows 95/98. Plataformas de banco de dados: Oracle.

ANEXOS

169

Anexo 4: Resultados do SPSS usados na análise descritiva

Tipo respondente Frequency Percent Valid

PercentCumulative

PercentValid Gerente 45 67,2 67,2 67,2 Usuário 22 32,8 32,8 100,0 Total 67 100,0 100,0 Empresas Frequency Percent Valid

PercentCumulative

PercentValid 1 3 4,5 4,5 4,5 2 2 3,0 3,0 7,5 3 1 1,5 1,5 9,0 4 1 1,5 1,5 10,4 5 1 1,5 1,5 11,9 6 2 3,0 3,0 14,9 7 1 1,5 1,5 16,4 8 2 3,0 3,0 19,4 9 1 1,5 1,5 20,9 10 3 4,5 4,5 25,4 11 1 1,5 1,5 26,9 12 1 1,5 1,5 28,4 13 1 1,5 1,5 29,9 14 1 1,5 1,5 31,3 15 1 1,5 1,5 32,8 16 3 4,5 4,5 37,3 17 1 1,5 1,5 38,8 18 1 1,5 1,5 40,3 19 1 1,5 1,5 41,8 20 1 1,5 1,5 43,3 21 4 6,0 6,0 49,3 22 1 1,5 1,5 50,7 23 1 1,5 1,5 52,2 24 1 1,5 1,5 53,7 25 1 1,5 1,5 55,2 26 3 4,5 4,5 59,7 27 1 1,5 1,5 61,2 28 1 1,5 1,5 62,7 29 3 4,5 4,5 67,2 30 3 4,5 4,5 71,6 31 1 1,5 1,5 73,1 32 3 4,5 4,5 77,6 33 1 1,5 1,5 79,1 34 2 3,0 3,0 82,1 35 3 4,5 4,5 86,6 36 1 1,5 1,5 88,1 37 1 1,5 1,5 89,6 38 1 1,5 1,5 91,0 39 1 1,5 1,5 92,5 40 1 1,5 1,5 94,0 41 1 1,5 1,5 95,5 42 1 1,5 1,5 97,0 43 2 3,0 3,0 100,0 Total 67 100,0 100,0 Faturamento anual (milhões R$)

ANEXOS

170

Frequency Percent Valid Percent

Cumulative Percent

Valid <= 20 5 11,6 11,6 11,6 21 - 70 7 16,3 16,3 27,9 71 - 150 7 16,3 16,3 44,2 151 - 300 7 16,3 16,3 60,5 > 300 17 39,5 39,5 100,0 Total 43 100,0 100,0 Número de funcionários Frequency Percent Valid

PercentCumulative

PercentValid <= 100 2 4,7 4,7 4,7 101 - 500 10 23,3 23,3 27,9 501 - 1000 8 18,6 18,6 46,5 1001 - 3000 11 25,6 25,6 72,1 > 3000 12 27,9 27,9 100,0 Total 43 100,0 100,0 Segmento de atuação Frequency Percent Valid

PercentCumulative

PercentValid Administradora saúde 1 2,3 2,3 2,3 Alimentos 8 18,6 18,6 20,9 Autopeças 3 7,0 7,0 27,9 Cerâmico 1 2,3 2,3 30,2 Construção 1 2,3 2,3 32,6 Distribuição bens 1 2,3 2,3 34,9 Distribuição gás 1 2,3 2,3 37,2 Eletro-eletrônico 2 4,7 4,7 41,9 Eletrônico 1 2,3 2,3 44,2 Elevadores 1 2,3 2,3 46,5 Embalagens 1 2,3 2,3 48,8 Gráfica 3 7,0 7,0 55,8 Informática 1 2,3 2,3 58,1 Material construção 1 2,3 2,3 60,5 Metal-mecânica 2 4,7 4,7 65,1 Metalúrgico 3 7,0 7,0 72,1 Montadora 1 2,3 2,3 74,4 Móveis 1 2,3 2,3 76,7 Papel e celulose 1 2,3 2,3 79,1 Químico 2 4,7 4,7 83,7 Serviços 1 2,3 2,3 86,0 Siderurgia 1 2,3 2,3 88,4 Sucro-alcooleiro 2 4,7 4,7 93,0 Telecomunicações 1 2,3 2,3 95,3 Têxtil automotivo 1 2,3 2,3 97,7 Transportes 1 2,3 2,3 100,0 Total 43 100,0 100,0

ANEXOS

171

Tamanho da equipe Frequency Percent Valid

PercentCumulative

PercentValid < 5 11 25,6 25,6 25,6 5 - 10 7 16,3 16,3 41,9 11 - 20 13 30,2 30,2 72,1 21 - 50 8 18,6 18,6 90,7 51 - 100 4 9,3 9,3 100,0 Total 43 100,0 100,0 Tempo de duração (m) Frequency Percent Valid

PercentCumulative

PercentValid <= 12 11 25,6 28,2 28,2 13 - 18 14 32,6 35,9 64,1 19 - 24 6 14,0 15,4 79,5 25 - 36 3 7,0 7,7 87,2 37 - 48 2 4,7 5,1 92,3 > 48 3 7,0 7,7 100,0 Total 39 90,7 100,0Missing System 4 9,3Total 43 100,0 Módulos Frequency Percent Valid

PercentCumulative

PercentValid Financeiro 36 15,3 15,3 15,3 Compras 36 15,3 15,3 30,6 Contábil 34 14,5 14,5 45,1 Industrial 31 13,2 13,2 58,3 Vendas 29 12,3 12,3 70,6 RH 16 6,8 6,8 77,4 Projetos 13 5,5 5,5 83,0 Outros 11 4,7 4,7 87,7 Manutenção 10 4,3 4,3 91,9 Marketing 7 3,0 3,0 94,9 Transporte 7 3,0 3,0 97,9 Serviços 5 2,1 2,1 100,0 Total 235 100,0 100,0 Valor do projeto (milhões R$) Frequency Percent Valid

PercentCumulative

PercentValid <= 0,5 10 23,3 29,4 29,4 0,6 - 1,0 6 14,0 17,6 47,1 1,1 - 1,5 4 9,3 11,8 58,8 1,6 - 2,0 3 7,0 8,8 67,6 2,1 - 4,0 5 11,6 14,7 82,4 4,1 - 10,0 2 4,7 5,9 88,2 > 10,0 4 9,3 11,8 100,0 Total 34 79,1 100,0Missing System 9 20,9Total 43 100,0

ANEXOS

172

Fornecedor do pacote Frequency Percent Valid

PercentCumulative

PercentValid Baan 17 39,5 39,5 39,5 SAP 9 20,9 20,9 60,5 Microsiga 8 18,6 18,6 79,1 Datasul 4 9,3 9,3 88,4 Oracle 3 7,0 7,0 95,3 Marcam 2 4,7 4,7 100,0 Total 43 100,0 100,0 Tipo de entrada em produção Frequency Percent Valid

PercentCumulative

PercentValid Big bang 15 34,9 37,5 37,5 Fases 15 34,9 37,5 75,0 Paralelo 1 2,3 2,5 77,5 Big bang + paralelo 1 2,3 2,5 80,0 Fases + paralelo 8 18,6 20,0 100,0 Total 40 93,0 100,0Missing System 3 7,0Total 43 100,0 Tipo de entrada em produção Frequency Percent Valid

PercentCumulative

PercentValid Big bang 16 37,2 41,0 41,0 Fases 23 53,5 59,0 100,0 Total 39 90,7 100,0Missing System 4 9,3Total 43 100,0 Big bang * Valor do projeto (milhões R$) Crosstabulation % of Total Valor do Projeto (milhões R$) Total <= 0,5 0,6 - 1,0 1,1 - 1,5 1,6 - 2,0 2,1 - 4,0 > 10,0 Big bang 1 15,4% 23,1% 15,4% 7,7% 15,4% 23,1% 100,0%Total 15,4% 23,1% 15,4% 7,7% 15,4% 23,1% 100,0% Tipo motivação gerentes Frequency Percent Valid

PercentCumulative

PercentValid Integração de informações 44 17,6 17,6 17,6 Necessidade de informações gerenciais 42 16,8 16,8 34,4 Ano 2000 30 12,0 12,0 46,4 Busca de vantagem competitiva 29 11,6 11,6 58,0 Evolução da arquitetura de informática 28 11,2 11,2 69,2 Redesenho de processos 25 10,0 10,0 79,2 Redução de pessoal 16 6,4 6,4 85,6 Globalização de negócios 15 6,0 6,0 91,6 Determinação da matriz 12 4,8 4,8 96,4 Indicação por empresa de consultoria 5 2,0 2,0 98,4 Pressão de parceiros 4 1,6 1,6 100,0 Total 250 100,0 100,0

ANEXOS

173

Binomial Test - motivação gerentes Category N Observed

Prop.Test Prop. Asymp.

Sig. (2-tailed)

Motivação gerentes Group 1 Atingida 213 ,85 ,50 ,000 Group 2 Não atingida 37 ,15 Total 250 1,00a Based on Z Approximation. Tipo motivação usuários Frequency Percent Valid

PercentCumulative

PercentValid Integração de informações 22 17,6 17,6 17,6 Busca de vantagem competitiva 20 16,0 16,0 33,6 Necessidade de informações gerenciais 19 15,2 15,2 48,8 Ano 2000 13 10,4 10,4 59,2 Redesenho de processos 12 9,6 9,6 68,8 Determinação da matriz 10 8,0 8,0 76,8 Evolução da arquitetura de informática 10 8,0 8,0 84,8 Redução de pessoal 8 6,4 6,4 91,2 Globalização de negócios 8 6,4 6,4 97,6 Indicação por empresa de consultoria 3 2,4 2,4 100,0 Total 125 100,0 100,0 Binomial Test - motivação usuários Category N Observed


Sig. (2-tailed)

Motivação usuários Group 1 Atingida 103 ,82 ,50 ,000 Group 2 Não atingida 22 ,18 Total 125 1,00a Based on Z Approximation. Descriptive Statistics - gerentes fase 1 N SumConsultoria externa 43 1170,00Apoio alta adm. 43 1060,00Missões claras e def. 39 720,00Mudança processos 41 650,00Usuários capazes 39 640,00Ger. proj. c/ habil. 40 630,00Planej. detalhado 38 480,00Valid N (listwise) 37 Descriptive Statistics - gerentes fase 2 N SumMissões claras e def. 44 1180,00Apoio alta adm. 43 1050,00Mudança processos 44 920,00Consultoria externa 40 910,00Ger. proj. c/ habil. 42 640,00Planej. detalhado 40 630,00Usuários capazes 40 450,00Valid N (listwise) 38

ANEXOS

174

Descriptive Statistics - gerentes fase 3 N SumGer. proj. c/ habil. 45 1100,00Apoio alta adm. 44 960,00Missões claras e def. 42 900,00Mudança processos 44 880,00Planej. detalhado 42 760,00Consultoria externa 41 720,00Usuários capazes 40 620,00Valid N (listwise) 38 Descriptive Statistics - gerentes fase 4 N SumGer. proj. c/ habil. 45 1060,00Mudança processos 43 920,00Consultoria externa 42 900,00Missões claras e def. 40 750,00Apoio alta adm. 40 740,00Planej. detalhado 41 720,00Usuários capazes 41 630,00Valid N (listwise) 37 Descriptive Statistics - usuários fase 1 N SumConsultoria externa 22 390,00Apoio alta adm. 21 270,00Mudança processos 21 210,00Missões claras e def. 20 170,00Ger. proj. c/ habil. 22 170,00Usuários capazes 21 160,00Planej. detalhado 20 150,00Valid N (listwise) 20 Descriptive Statistics - usuários fase 2 N SumMissões claras e def. 22 350,00Mudança processos 22 320,00Apoio alta adm. 21 240,00Consultoria externa 21 190,00Ger. proj. c/ habil. 20 170,00Planej. detalhado 20 130,00Usuários capazes 19 90,00Valid N (listwise) 19 Descriptive Statistics - usuários fase 3 N SumMudança processos 22 390,00Ger. proj. c/ habil. 22 360,00Planej. detalhado 20 190,00Consultoria externa 21 190,00Missões claras e def. 20 130,00Usuários capazes 19 120,00Apoio alta adm. 19 80,00Valid N (listwise) 18

ANEXOS

175

Descriptive Statistics - usuários fase 4 N SumMudança processos 22 360,00Ger. proj. c/ habil. 22 340,00Planej. detalhado 21 240,00Consultoria externa 21 200,00Missões claras e def. 20 130,00Apoio alta adm. 20 120,00Usuários capazes 19 100,00Valid N (listwise) 19

ANEXOS

176

Anexo 5: Resultados do SPSS usados no teste de hipóteses

KMO and Bartlett's Test Kaiser-Meyer-Olkin Measure of Sampling Adequacy. ,605 Bartlett's Test of Sphericity Approx. Chi-Square 20,252 df 6 Sig. ,002 Anti-image Matrices

Tempo Custo Qualidade Melhora Anti-image Covariance Tempo ,815 -,293 -8,051E-02 -5,100E-02 Custo -,293 ,809 -,120 -1,100E-02 Qualidade -8,051E-02 -,120 ,719 -,338 Melhora -5,100E-02 -1,100E-02 -,338 ,756Anti-image Correlation Tempo ,634a -,361 -,105 -6,496E-02 Custo -,361 ,622a -,157 -1,406E-02 Qualidade -,105 -,157 ,596a -,459 Melhora -6,496E-02 -1,406E-02 -,459 ,581a

a Measures of Sampling Adequacy(MSA) Communalities

Initial Extraction Tempo 1,000 ,694Custo 1,000 ,703Qualidade 1,000 ,729Melhora 1,000 ,775Extraction Method: Principal Component Analysis. Total Variance Explained

Initial Eigenvalues Extraction Sums of Squared Loadings

Rotation Sums of Squared Loadings

Component

Total

% of Variance

Cumulative %

Total

% of Variance

Cumulative %

Total

% of Variance

Cumulative %

1 1,871 46,774 46,774 1,871 46,774 46,774 1,484 37,104 37,1042 1,029 25,735 72,509 1,029 25,735 72,509 1,416 35,405 72,5093 ,602 15,040 87,5494 ,498 12,451 100,000Extraction Method: Principal Component Analysis. Component Matrix

Component 1 2

Tempo ,648 ,523Custo ,650 ,529Qualidade ,754 -,401Melhora ,678 -,561Extraction Method: Principal Component Analysis. a 2 components extracted.

ANEXOS

177

Rotated Component Matrix Component 1 2

Tempo ,122 ,824Custo ,119 ,830Qualidade ,826 ,216Melhora ,879 4,722E-02Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization. a Rotation converged in 3 iterations. Component Transformation Matrix Component 1 2

1 ,735 ,6782 -,678 ,735

Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization. Correlations Eficiência Eficácia EfetividadeSpearman's rho F1-Missões claras e def. Correlation Coefficient ,276 ,447** ,362* Sig. (2-tailed) ,066 ,002 ,015 N 45 45 45 F2-Apoio alta adm. Correlation Coefficient ,572** ,249 ,487** Sig. (2-tailed) ,000 ,100 ,001 N 45 45 45 F3-Usuários capazes Correlation Coefficient ,065 ,163 ,085 Sig. (2-tailed) ,670 ,284 ,581 N 45 45 45 F4-Planej. detalhado Correlation Coefficient ,276 ,265 ,293 Sig. (2-tailed) ,066 ,078 ,050 N 45 45 45 F5-Ger. proj. c/ habil. Correlation Coefficient ,090 ,312* ,139 Sig. (2-tailed) ,559 ,037 ,364 N 45 45 45 F6-Consultoria externa Correlation Coefficient ,104 ,284 ,175 Sig. (2-tailed) ,502 ,061 ,256 N 44 44 44 F7-Mudança processos Correlation Coefficient ,309* ,077 ,270 Sig. (2-tailed) ,042 ,619 ,077 N 44 44 44 Informática Correlation Coefficient ,331* ,155 ,297* Sig. (2-tailed) ,026 ,308 ,048 N 45 45 45 Disposição p/ mudança Correlation Coefficient -,092 ,133 ,008 Sig. (2-tailed) ,547 ,383 ,956 N 45 45 45** Correlation is significant at the .01 level (2-tailed). * Correlation is significant at the .05 level (2-tailed).

ANEXOS

178

Anexo 6: Resultados do SPSS usados nas análises exploratórias

Binomial Test - gerentes Category N Observed


Sig. (2-tailed)

Adoção Group 1 Atingida 37 ,90 ,50 ,000 Group 2 Não atingida 4 ,10 Total 41 1,00 Uso Group 1 Atingido 30 ,73 ,50 ,005 Group 2 Não atingido 11 ,27 Total 41 1,00 Incorporação - Group 1 Atingida 10 ,24 ,50 ,002 Recursos Group 2 Não atingida 31 ,76 Explorados Total 41 1,00 Incorporação - Group 1 Atingida 29 ,71 ,50 ,012 Tomada Group 2 Não atingida 12 ,29 Decisão Total 41 1,00 a Based on Z Approximation. Binomial Test - gerentes Category N Observed


Sig. (2-tailed)

Incorporação Group 1 Não atingido 43 ,52 ,50 ,740 Group 2 Atingido 39 ,48 Total 82 1,00a Based on Z Approximation. Binomial Test - usuários Category N Observed

Prop.Test Prop. Exact Sig.

(2-tailed) Adoção Group 1 Atingida 17 ,89 ,50 ,001 Group 2 Não atingida 2 ,11 Total 19 1,00 Uso Group 1 Atingido 12 ,63 ,50 ,359 Group 2 Não atingido 7 ,37 Total 19 1,00 Incorporação - Group 1 Atingida 5 ,25 ,50 ,041 Recursos Group 2 Não atingida 15 ,75 Explorados Total 20 1,00 Incorporação - Group 1 Atingida 13 ,72 ,50 ,096 Tomada Group 2 Não atingida 5 ,28 decisão Total 18 1,00 Binomial Test - usuários Category N Observed


Sig. (2-tailed)

Incorporação Group 1 Não atingida 20 ,53 ,50 ,871 Group 2 Atingida 18 ,47 Total 38 1,00 a Based on Z Approximation.

ANEXOS

179

Correlations Eficiência Eficácia Efetividade Fatura-

mento Funcio-nários

Tamanho equipe

Duração projeto

Valor projeto

Tempo Custo Qualidade Melhora

Spearman's rho Eficiência Correlation Coefficient 1,000 ,383* ,915** -,028 ,035 ,118 -,247 ,070 ,853** ,797** ,362* ,267 Sig. (2-tailed) , ,014 ,000 ,860 ,827 ,462 ,119 ,709 ,000 ,000 ,020 ,092 N 41 41 41 41 41 41 41 31 41 41 41 41 Eficácia Correlation Coefficient ,383* 1,000 ,692** -,100 ,018 -,087 -,247 ,060 ,329 ,333 ,867** ,861** Sig. (2-tailed) ,014 , ,000 ,534 ,913 ,588 ,119 ,748 ,035 ,033 ,000 ,000 N 41 41 41 41 41 41 41 31 41 41 41 41 Efetividade Correlation Coefficient ,915** ,692** 1,000 -,092 ,001 ,081 -,277 ,078 ,784** ,754** ,625** ,556** Sig. (2-tailed) ,000 ,000 , ,566 ,995 ,616 ,079 ,676 ,000 ,000 ,000 ,000 N 41 41 41 41 41 41 41 31 41 41 41 41 Faturamento Correlation Coefficient -,028 -,100 -,092 1,000 ,798** ,537** ,363* ,530** ,024 -,064 -,162 -,104 Sig. (2-tailed) ,860 ,534 ,566 , ,000 ,000 ,014 ,001 ,882 ,689 ,312 ,519 N 41 41 41 45 45 45 45 35 41 41 41 41 Funcionários Correlation Coefficient ,035 ,018 ,001 ,798** 1,000 ,344* ,309* ,268 ,065 ,029 ,030 -,092 Sig. (2-tailed) ,827 ,913 ,995 ,000 , ,021 ,039 ,120 ,688 ,856 ,850 ,565 N 41 41 41 45 45 45 45 35 41 41 41 41 Tamanho equipe Correlation Coefficient ,118 -,087 ,081 ,537** ,344* 1,000 ,212 ,567** ,238 -,033 -,203 -,034 Sig. (2-tailed) ,462 ,588 ,616 ,000 ,021 , ,163 ,000 ,134 ,838 ,202 ,832 N 41 41 41 45 45 45 45 35 41 41 41 41 Duração projeto Correlation Coefficient -,247 -,247 -,277 ,363* ,309* ,212 1,000 ,474** -,125 -,252 -,261 -,216 Sig. (2-tailed) ,119 ,119 ,079 ,014 ,039 ,163 , ,004 ,435 ,111 ,100 ,175 N 41 41 41 45 45 45 45 35 41 41 41 41 Valor projeto Correlation Coefficient ,070 ,060 ,078 ,530** ,268 ,567** ,474** 1,000 ,270 -,176 -,097 ,147 Sig. (2-tailed) ,709 ,748 ,676 ,001 ,120 ,000 ,004 , ,142 ,342 ,603 ,431 N 31 31 31 35 35 35 35 35 31 31 31 31 Tempo Correlation Coefficient ,853** ,329* ,784** ,024 ,065 ,238 -,125 ,270 1,000 ,388* ,280 ,252 Sig. (2-tailed) ,000 ,035 ,000 ,882 ,688 ,134 ,435 ,142 , ,012 ,076 ,111 N 41 41 41 41 41 41 41 31 41 41 41 41 Custo Correlation Coefficient ,797** ,333* ,754** -,064 ,029 -,033 -,252 -,176 ,388* 1,000 ,363* ,205 Sig. (2-tailed) ,000 ,033 ,000 ,689 ,856 ,838 ,111 ,342 ,012 , ,020 ,199 N 41 41 41 41 41 41 41 31 41 41 41 41 Qualidade Correlation Coefficient ,362* ,867** ,625** -,162 ,030 -,203 -,261 -,097 ,280 ,363* 1,000 ,523** Sig. (2-tailed) ,020 ,000 ,000 ,312 ,850 ,202 ,100 ,603 ,076 ,020 , ,000 N 41 41 41 41 41 41 41 31 41 41 41 41 Melhora Correlation Coefficient ,267 ,861** ,556** -,104 -,092 -,034 -,216 ,147 ,252 ,205 ,523** 1,000 Sig. (2-tailed) ,092 ,000 ,000 ,519 ,565 ,832 ,175 ,431 ,111 ,199 ,000 , N 41 41 41 41 41 41 41 31 41 41 41 41* Correlation is significant at the .05 level (2-tailed). ** Correlation is significant at the .01 level (2-tailed).

ANEXOS

180

Correlations Tempo Custo Qualidade Melhora Tempo Pearson Correlation 1,000 ,402** ,295 ,260 Sig. (2-tailed) , ,009 ,061 ,101 N 41 41 41 41 Custo Pearson Correlation ,402** 1,000 ,266 ,171 Sig. (2-tailed) ,009 , ,093 ,286 N 41 41 41 41 Qualidade Pearson Correlation ,295 ,266 1,000 ,538** Sig. (2-tailed) ,061 ,093 , ,000 N 41 41 41 41 Melhora Pearson Correlation ,260 ,171 ,538** 1,000 Sig. (2-tailed) ,101 ,286 ,000 , N 41 41 41 41 ** Correlation is significant at the 0.01 level (2-tailed). Binomial Test

Category N

Observed Prop.

Test Prop.

Asymp. Sig. (2-tailed)

Exact Sig. (2-tailed)

Integração de informações Group 1 1 43 ,98 ,50 ,000a

Group 2 2 1 ,02 Total 44 1,00Redução de pessoal Group 1 1 9 ,56 ,50 ,804 Group 2 2 7 ,44 Total 16 1,00Busca de vantagem competitiva Group 1 1 24 ,83 ,50 ,001a

Group 2 2 5 ,17 Total 29 1,00Determinação da matriz Group 1 1 10 ,83 ,50 ,039 Group 2 2 2 ,17 Total 12 1,00Globalização de negócios Group 1 1 12 ,80 ,50 ,035 Group 2 2 3 ,20 Total 15 1,00Ano 2000 Group 1 1 22 ,73 ,50 ,018a

Group 2 2 8 ,27 Total 30 1,00Pressão de parceiros Group 1 1 3 ,75 ,50 ,625 Group 2 2 1 ,25 Total 4 1,00Necessidade de informações gerenciais Group 1 1 36 ,86 ,50 ,000a

Group 2 2 6 ,14 Total 42 1,00Indicação por empresa de consultoria Group 1 1 5 1,00 ,50 ,063 Total 5 1,00Evolução da arquitetura de informática Group 1 1 27 ,96 ,50 ,000a

Group 2 2 1 ,04 Total 28 1,00Redesenho de processos Group 1 1 22 ,88 ,50 ,000 Group 2 2 3 ,12 Total 25 1,00a Based on Z Approximation.

ANEXOS

181

Binomial Test Category N Observed

Prop.Test Prop. Exact

Sig. (2-tailed)

Integração de informações Group 1 Atingida 17 ,77 ,50 ,017 Group 2 Não

atingida5 ,23

Total 22 1,00Redução de pessoal Group 1 Atingida 3 ,38 ,50 ,727 Group 2 Não

atingida5 ,63

Total 8 1,00Busca de vantagem competitiva Group 1 Atingida 15 ,75 ,50 ,041 Group 2 Não

atingida5 ,25

Total 20 1,00Determinação da matriz Group 1 Atingida 9 ,90 ,50 ,021 Group 2 Não

atingida1 ,10

Total 10 1,00Globalização de negócios Group 1 Atingida 5 ,63 ,50 ,727 Group 2 Não

atingida3 ,38

Total 8 1,00Ano 2000 Group 1 Atingida 13 1,00 ,50 ,000 Total 13 1,00Necessidade de informações gerenciais Group 1 Atingida 16 ,84 ,50 ,004 Group 2 Não

atingida3 ,16

Total 19 1,00Indicação por empresa de consultoria Group 1 Atingida 3 1,00 ,50 ,250 Total 3 1,00Evolução da arquitetura de informática Group 1 Atingida 10 1,00 ,50 ,002 Total 10 1,00Redesenho de processos Group 1 Atingida 12 1,00 ,50 ,000 Total 12 1,00

motivações para o projeto

Documents