GESTÃO DE RISCOS NA IMPLANTAÇÃO DE ERP

MARCELO NOGUEIRA
Universidade Paulista
Rua Dr. Bacelar 1212 – 4º - CEP 04026-002 – São Paulo – SP.
marcelo@noginfo.com.br

Resumo
As empresas de desenvolvimento de sistemas ERP apresentam seus produtos de software, bem como
suas características com o intuito de introduzi-los no mercado. No entanto a sua aderência aos
processos de negócios da empresa vai depender de um estudo profundo sobre sua funcionalidade,
requisitos, capacidade crítica de processamento, entre várias outras. Como ponto de partida,
implementar a gestão de riscos nas implantações de sistemas ERP, diminuirá os fracassos
atribuídos tanto para as empresas de software bem como para as organizações implantadas.
Capacitará a relação sob uma visão sistêmica e controlada, possibilitando a realização da efetiva
missão dos sistemas ERP, a gestão integrada dos negócios.

Palavras-chave: ERP, Gestão de Riscos, Engenharia de Software.

Abstract
The development companies of ERP systems introduce his software products, as well as her
characteristic with the purpose of introduced them into the market. However your adherence to the
business processes of the company is going to depend on a profound study about your functionality,
requisites, critical capacity of processing, come in several another. Like starting point, the
implementation of the risks administration in the implantations of ERP systems, will decrease the
attributed failures so much for the software companies as well as for the implanted organizations.
With the controlled process, it enables the accomplishment of the effective mission of ERP systems,
the administration integrated of the business.

Key words: ERP, Risks Administration, Software Engineering.

1. OBJETIVO
Este trabalho tem por objetivo principal apresentar a importância da implementação da gestão de
riscos, como um dos fatores críticos de sucesso na implantação de sistemas ERP através de
aplicação das melhores práticas de gestão de projetos o qual possibilita prever controlar e monitorar
os riscos, permitindo o acompanhamento antecipado dos problemas relacionadas à aderência do
sistema à organização.
Este artigo pretende contribuir com outros estudos de implementação da Gestão de Riscos no
processo de implantação de software.
2. INTRODUÇÃO
Num ambiente globalizado e de mudanças cada vez mais complexas, a gestão adequada da
Informação assume uma importância decisiva no processo de tomada de decisão e na busca de
vantagens competitivas nas organizações. Diante desta necessidade as empresas focam suas
atenções ao desenvolvimento de sistemas de informação integrados que propiciam informações
extremamente essenciais para a tomada de decisão dos principais executivos de uma organização.
Esta fase iniciou-se a partir da metade dos anos 90, quando as empresas começaram a adotar os
sistemas ERP (Enterprise Resource Planning).

1
Impulsionados pelo BUG do ano 2000, onde se previa catástrofes dos sistemas legados caso não
fosse remodelados seus dados, o ERP ganhou um apoio fundamental para sua adoção, permitindo
que devido à urgência, as organizações não se preparassem melhor para sua implantação.
Passado a fase do BUG, iniciaram-se estudos acadêmicos que detectaram que a falta de um processo
sistêmico para avaliação do sistema ERP adquirido, ao invés de trazer benefícios, trouxeram grandes
problemas operacionais, inclusive perda de vantagens competitivas.
A apresentação dos processos necessários para que se obtenha sucesso na implantação de ERP faz-
se necessário diante da demanda que as empresas possuem quanto a informação clara e oportuna de
seus processos operacionais, que permitem ações táticas e estratégicas no seu mercado atuante.
Considerando o ERP como um pacote de software, que possui módulos padrões para várias
empresas, entende-se que em alguns casos não atenderá as necessidades da empresa. Dependendo do
requisito ele poderá ou não, entrar num processo de customização, que onerará mais custos ao
projeto. Caso a empresa opte por não customizar, e partir para uma política de adaptar-se ao
software, poderá condenar o sucesso dessa implementação.
A implementação da gestão de riscos na implantação dos sistemas ERP, direciona como prever e
analisar possíveis incompatibilidades com os requisitos necessários para atender as regras de
negócios de uma organização. Com a gestão de riscos diminui a possibilidade de fracasso na
implantação já que controla e determina norteamentos reais e de acordo com a capacidade da
empresa seja técnica, operacional ou organizacional de promover ajustes para que a aderência do
sistema ERP seja menos “Traumática”.
Com a devida preocupação que o sistema ERP traga soluções de fato para as empresas, e considerar
que por se tratar de um pacote de software, quais riscos as empresas adquirentes estão submetidas?
3. RELEVÂNCIA
No estudo da Engenharia de Software, o autor Roger S. Pressman [PRESSMAN02], demonstra
preocupação com a “Crise do Software” que atualmente ele intitula como “Aflição Crônica”,
chegando a determinar números expressivos sobre a não finalização de projetos de sistemas
começados e não terminados.
Segundo o Standish Group, entidade americana de consultoria empresarial, através de um estudo
chamado "Chaos Report", para projetos na área de Tecnologia da informação, obteve as seguintes
conclusões: [COUTINHO02]
Apenas 16% terminam no prazo e dentro do orçamento previsto;
94% têm pelo menos um reinício;
Há um aumento de 188% no seu custo e 222% no cronograma;
Apenas 61% são concluídos com os objetivos originais pré-estabelecidos.
O mesmo Standish Group, realizou uma pesquisa entre as empresas com mais de 500 milhões de
dólares de faturamento e que investiram em projetos de ERP, mostrou resultados no mínimo
inquietantes. Apenas 10% dos projetos terminaram no tempo e prazo estimados, 55% estouraram
prazos e orçamentos e 35% foram cancelados. E dos projetos fora de controle, o estouro médio de
prazo foi 230% e de orçamento: 178%.[TOURION02]
Num mundo cada vez mais de recursos financeiros escassos, como é possível aceitar tal desperdício
de tempo e dinheiro. Pressman também aponta para o possível problema causador de tal absurdo: “A
falta de adoção de métodos, ferramentas e procedimentos no desenvolvimento de software e a difícil
relação de entendimento entre o usuário com o desenvolvedor”.
Considerado por Brooks [BROOKS87] como problema essencial:

2
“A parte mais difícil do desenvolvimento de software é decidir precisamente o que será
desenvolvido. Nenhuma outra parte do trabalho é tão difícil quanto estabelecer (definir) os detalhes
técnicos necessários incluindo todas as interfaces para pessoas, máquinas e para outros sistemas de
software. Nenhuma outra parte do trabalho é tão possível de ocasionar erros no sistema como essa.
Nenhuma outra parte é tão difícil de ser posteriormente consertada”.
Apesar dessa “Crise de Software” ter iniciado a partir dos anos 60, até hoje ainda enfrentamos seus
efeitos. Os sistemas ERP não fogem a regra. Quando o produto não atende as expectativas dos
clientes/usuários e possuem falhas de concepção da real necessidade da empresa, estouram prazos e
custos, eles também se enquadram na perspectiva da “Crise do Software”.
4. ERP
Os sistemas ERP (Enterprise Resource Planning) são sistemas de informação integrados, adquiridos
na forma de pacotes comerciais, para suportar a maioria das operações da empresa. Eles procuram
atender a requisitos genéricos do maior número possível de empresas, incorporando modelos de
processos de negócio, obtidos pela experiência acumulada de fornecedores, consultoria e pesquisa
em processos de benchmarking. A integração é possível pelo compartilhamento de informações
comuns entre os diversos módulos, armazenados em um único banco de dados centralizado.
[SOUZA00]
Segundo Davenport [DAVENPORT98], o ERP é um software que promete a integração das
informações que fluem pela empresa. Esse sistema impõe sua própria lógica à estratégia, à cultura e
à organização da empresa. É uma solução genérica que procura atender a todo tipo de empresa e seu
projeto reflete uma série de hipóteses sobre como operam as organizações. É desenvolvido para
refletir as melhores práticas de negócio, porém a decisão sobre a melhor prática é de
responsabilidade do cliente.
Com o avanço da Tecnologia da Informação as empresas passaram a utilizar sistemas
computacionais para suportar suas atividades. Geralmente, em cada empresa, vários sistemas foram
desenvolvidos para atender aos requisitos específicos das diversas unidades de negócio, plantas,
departamentos e escritórios. Por exemplo, o departamento de planejamento da produção utiliza um
sistema próprio e o departamento de vendas utiliza outro. Dessa forma, a informação fica dividida
entre diferentes sistemas.
O principal problema dessa fragmentação da informação é a dificuldade de obtenção de informações
consolidadas e a inconsistência de dados redundantes armazenados em mais de um sistema. Os
sistemas ERP (Enterprise Resource Planning) solucionam esses problemas ao agregar, em um só
sistema integrado, funcionalidades que suportam as atividades dos diversos processos de negócio
das empresas.
Os sistemas ERP surgiram a partir da evolução dos sistemas MRP (Material Resource Planning).
Neles, foram agregados as funções de programação mestre da produção, cálculo de necessidades de
capacidade, cálculo detalhado de necessidade de capacidade, controle do chão de fábrica, controle
de compras e, mais recentemente, Sales & Operations Planning. Dessa forma, os sistemas MRP
deixaram de atender apenas as necessidades de informação referentes ao cálculo da necessidade de
materiais, para atender às necessidades de informação para a tomada de decisão gerencial sobre
outros recursos de manufatura. O MRP passou, então, a ser chamado de MRP II (Manufacturing
Resource Planning - Planejamento de Recursos de Manufatura). [CORRÊA97]

Com o objetivo de ampliar a abrangência dos produtos vendidos, os fornecedores de sistemas

desenvolveram mais módulos, integrados aos módulos de manufatura, mas com escopo que
ultrapassa os limites da manufatura. Como exemplo, foram criados os módulos de Gerenciamento
dos Recursos Humanos, Vendas e Distribuição, Finanças e Controladoria, entre outros. Esses
sistemas, capazes de suportar as necessidades de informação para todo o empreendimento, são
denominados sistemas ERP.

3
4.1 ESTRUTURA TÍPICA DOS SISTEMAS ERP
Os sistemas ERP são compostos por uma base de dados única e por módulos que suportam diversas
atividades das empresas. A figura a seguir apresenta uma estrutura típica de funcionamento de um
sistema ERP. Os dados utilizados por um módulo são armazenados na base de dados centrais para
serem manipulados por outros módulos. [DAVENPORT98]
Figura 1 - Estrutura típica de funcionamento de um sistema ERP [DAVENPORT98].

Os módulos citados na figura acima estão presentes na maioria dos sistemas ERP. Além deles,
alguns sistemas ERP possuem módulos adicionais, tais como: Gerenciamento da Qualidade,
Gerenciamento de Projetos, Gerenciamento de Manutenção, entre outros.
Os sistemas ERP possuem características que, se tomadas em conjunto, permitem distingui-los de
sistemas desenvolvidos internamente nas empresas e de outros tipos de pacotes comerciais. Essas
características podem ser resumidas como: [ZWICKER03]
• São pacotes comerciais de software;
• Incorporam modelos de processos de negócios “Best Practices”;
• São sistemas de informação integrados e utilizam banco de dados corporativo;
• Possuem grande abrangência funcional;
• Requerem procedimentos de ajuste para que possam ser utilizados em determinada empresa.
As funcionalidades dos módulos de um sistema ERP representam uma solução genérica que reflete
uma série de considerações sobre a forma que as empresas operam em geral. Para flexibilizar sua
utilização em um maior número de empresas de diversos segmentos, os sistemas ERP foram
desenvolvidos de forma que a solução genérica possa ser customizada em um certo grau.
[DAVENPORT98]
Na implantação de um sistema ERP, a customização é um compromisso entre os requisitos da
empresa e as funcionalidades disponíveis no sistema. Inicialmente, na maioria das vezes, os
processos de negócio das empresas precisam ser redefinidos para que seus requisitos se aproximem
das funcionalidades do sistema. Então, a primeira medida de customização é a seleção dos módulos
que serão instalados. A característica modular permite que cada empresa utilize somente os módulos
que necessite e possibilita que módulos adicionais sejam agregados com o tempo. Em seguida, para
cada módulo, são feitos ajustes nas tabelas de configuração para que o sistema se adeque da melhor
forma possível aos novos processos de negócio. Mesmo com a customização, a solução pode não
atender a alguns requisitos específicos das empresas. Nesses casos, as empresas precisam utilizar
outros sistemas complementares ou abandonar seus requisitos específicos e adotar processos
genéricos.
Por esse motivo, a decisão de implantação de um sistema ERP só deve ser tomada após uma análise
detalhada dos processos da empresa e das funcionalidades dos sistemas ERP. Além disso, é muito
importante que as empresas considerem, desde o início da implantação, os impactos que a

4
redefinição dos processos e a introdução do sistema terão na estrutura, cultura e estratégia da
organização. [DAVENPORT98]
5. PORQUE ADOTAR E IMPLANTAR ERP?
A adoção de um sistema ERP afeta a empresa em todas as suas dimensões culturais, organizacionais
ou tecnológicas. Esses sistemas controlam toda a empresa, da produção às finanças, registrando e
processando cada fato novo na engrenagem corporativa e distribuindo a informação de maneira clara
e segura, em tempo real. Ao adotar um sistema ERP, o objetivo básico não é colocar o software em
produção, mas melhorar os processos de negócios usando tecnologia da informação.[LIMA00]
A conclusão é que a utilização de sistemas ERP otimiza o fluxo de informações e facilita o acesso
aos dados operacionais, favorecendo a adoção de estruturas organizacionais mais achatadas e
flexíveis. Além disso, as informações tornam-se mais consistentes, possibilitando a tomada de
decisão com base em dados que refletem a realidade da empresa. Um outro benefício da
implantação é a adoção de melhores práticas de negócio, suportadas pelas funcionalidades dos
sistemas, que resultam em ganhos de produtividade e em maior velocidade de resposta da
organização.
6. RISCO
Segundo Robert Charette [CHARETTE89], a definição de risco é:
“Em primeiro lugar, risco afeta acontecimentos futuros. Presente e passado não preocupam, pois o
que colhemos hoje já foi semeado por nossas ações anteriores. A questão é mudando nossas ações
hoje, podemos criar oportunidade para uma situação diferente e possivelmente melhor para nós
amanhã? Isso significa, em segundo lugar, que risco envolve mudança, como por exemplo,
mudança de pensamento, opinião, ações ou lugares..., e em terceiro lugar, o risco envolve escolha e
a incerteza que a própria escolha envolve. Assim, paradoxalmente, o risco, como a morte e os
impostos, é uma das poucas certezas da vida.”
Quando o risco é considerado no contexto da Engenharia de Software, as três fundamentações
conceituais de Charette estão sempre em evidência. [PRESSMAN02]
1. O futuro é nossa preocupação: Que riscos podem causar o insucesso do projeto de software?
2. A mudança é nossa preocupação: Como as mudanças de requisitos do cliente, afetam a
pontualidade e o sucesso geral?
3. Devemos cuidar das escolhas: Que métodos e ferramentas devemos usar, quantas pessoas devem
ser envolvidas, quanta ênfase em qualidade é suficiente?
Peter Drucker disse certa vez, “já que é fútil tentar eliminar riscos e questionável tentar minimizá-
los, o essencial é que os riscos considerados sejam os certos”. Antes que possamos identificar os
“riscos certos”, que acontecerão durante um projeto de software, é importante identificar todos os
demais que são óbvios, tanto para gerentes quanto para profissionais. [PRESSMAN02]
Segundo Higuera [HIGUERA95], “um risco 100% provável é uma restrição ao projeto de software”.
Um grande volume de dados publicados aponta para os riscos que ocorrem os projetos de software
executados se a utilização de processos adequados [PADUA03]. Um levantamento publicado de
uma base de dados de 4.000 projetos, constatou a ocorrência freqüente dos seguintes problemas:
70% dos projetos de grandes aplicativos sofrem instabilidade dos requisitos. Os requisitos
crescem tipicamente cerca de 1% ao mês, atingindo níveis de mais de 25% de inchaço ao final
do projeto.
Pelo menos 50% dos projetos são executados com níveis de produtividade abaixo do normal.
Pelo menos 25% dos softwares de prateleira e 50% dos produtos feitos por encomenda
apresentam níveis de defeitos superiores ao razoável.

5
 Produtos feitos sob pressão de prazos podem quadruplicar o número de defeitos.
Pelo menos 50% dos grandes projetos de software estouram seu orçamento e seu prazo.
2/3 dos projetos de software muito grandes são cancelados antes do final.
Os usuários não ficam satisfeitos com 25% dos produtos comerciais para PC, 30% dos produtos
comerciais para mainframe e 40% dos produtos feitos por encomenda.
Tipicamente, 50% do patrimônio de software das empresas não são usados.
Atritos entre a área de tecnologia da informação e a alta gerência ocorrem em mais de 30% das
organizações.
Atritos com clientes ocorrem, no desenvolvimento de aplicativos, em 50% dos contratos por
administração e 65% dos contratos por empreitada.
O risco de projeto pode ser estimado qualitativamente (Tabela 1). O principal objetivo da análise de
riscos é desenvolver um conjunto de estratégias de prevenção de riscos.[IEEE95]
Tabela 1 – Esquema de Classificação de Riscos - IEEE 1044.1-1995
Esquema de Classificação de Riscos Descrição
Alto A correção de irregularidades ou a implementação de melhorias
apresentam risco alto de impacto negativo no projeto.
Médio A correção de irregularidades ou a implementação de melhorias
apresentam risco médio de impacto negativo no projeto.
Baixo A correção de irregularidades ou a implementação de melhorias
apresentam risco baixo de impacto negativo no projeto.
Zero A correção de irregularidades ou a implementação de melhorias
apresentam risco desprezível de impacto negativo no projeto.

7. GESTÃO DE RISCOS
Gestão de Riscos é composta por atividades coordenadas para direcionar uma organização em
relação ao risco. A gestão de riscos, geralmente inclui avaliação, tratamento, aceitação e
comunicação de riscos. [MCT02]
A gestão de riscos envolve cinco atividades principais (Figura2): Planejamento, controle,
monitoração, direcionamento e recrutamento [PETERS01].
Figura 2 – Taxonomia da Engenharia de Riscos. [PETERS01]
Engenharia de Riscos
Garantir que as
recomendações
da análise de
riscos sejam
cumpridas

Análise de Riscos Garantir que as Gestão

recomendações
da análise de
riscos sejam
• Identificação dos riscos cumpridas
• Estimativa dos riscos
Observar a eficácia
• Avaliação dos riscos das estratégias de
Prevenção de riscos
de Riscos Observar a eficácia
das estratégias de
Prevenção de riscos
• Planejamento dos riscos
• Controle de riscos Recomendar
• Monitoração de riscos mudanças nas
estratégias de
• Direcionamento de riscos
• Recrutamento (para prevenção de riscos
combate aos riscos)

Garantir que as
recomendações
da análise de
riscos sejam
cumpridas

6
A gestão de riscos é particularmente importante para projetos de software, devido às incertezas
inerentes que a maioria dos projetos enfrenta. [SOMMERVILLE03]
De modo simplificado, podemos pensar no risco como uma probabilidade de que alguma
circunstância adversa realmente venha ocorrer. Os riscos podem ameaçar o projeto, o software que
está sendo desenvolvido ou a organização. Essas categorias de riscos podem ser definidas como se
segue: [SOMMERVILLE03]
1. Riscos relacionados ao Projeto: São os riscos que afetam a programação ou os recursos do
projeto.
2. Riscos relacionados ao Produto: São os riscos que afetam a qualidade ou o desempenho do
software que está em desenvolvimento.
3. Riscos para os negócios: São os riscos que afetam a organização que está desenvolvendo ou
adquirindo o software.
O processo de gestão de riscos envolve vários estágios: [SOMMERVILLE03]
1. Identificação dos riscos: São identificados os possíveis riscos de projeto, produto e negócios.
2. Análise de riscos: São avaliadas as possibilidades e as conseqüências da ocorrência desses
riscos.
3. Planejamento de riscos: São traçados planos para enfrentar os riscos, seja evitando-os, seja
minimizando seus efeitos sobre o projeto.
4. Monitoramento de riscos: O Risco é constantemente avaliado e os planos para a diminuição dos
riscos revisados, à medida que mais informações sobre eles se tornam disponíveis.
Segundo Pádua [PADUA03], os riscos dever ser estimados e monitorados:

A estimativa de riscos é uma atividade muito importante e pouco praticada; um bom planejamento
não apenas o que deve acontecer se tudo correr bem, mas também o que pode correr mal, quais as
conseqüências dos problemas e o que pode ser feito para combatê-los. Entre os fatores de riscos que
devem ser considerados podem ser incluídos:
Riscos legais;
Riscos Tecnológicos;
Riscos devidos ao tamanho e à complexidade do produto;
Riscos relativos a pessoal;
Riscos relativos à aceitação pelos usuários;

Sommerville [SOMMERVILLE03], descreve os tipos de riscos que podem afetar o projeto e do

ambiente organizacional em que o software está sendo desenvolvido.
Contudo, muitos riscos são considerados universais e eles envolvem as seguintes áreas:

Tecnologia

Pessoal

Organizacional

Ferramentas

Requisitos

Estimativa

7
 A estimativa dos riscos compreende as seguintes tarefas (Tabela 2):
Identificação dos riscos possíveis em relação ao projeto;
Análise desses riscos, avaliando-lhes a probabilidade e o provável impacto;
Previsão de contramedidas curativas ou preventivas;
Priorização dos riscos, organizando-os de acordo com a probabilidade e o impacto.
Tabela 2 – Exemplo de Estimativa de Riscos – [PADUA03]
Prioridade Risco Gravidade Probabilidade Impacto Previsto Contramedidas
De ocorrência Previstas
1 Falta de Equipamentos para Alta Média Impossibilidade de Cobrar providência do cliente.
testes beta. realizar os testes beta.
2 Defeitos na Engenharia de Média Média Vários dias de atraso por Incluir na primeira liberação os
Software alteração de requisitos. requisitos mais complexos.
3 Falta de Usuários responsáveis Alta Baixa Impossibilidade de Cobrar providência do cliente.
por testes. realizar os testes beta.
4 Falta de inventário das Alta Baixa Impossibilidade de Cobrar providência do cliente.
mercadorias para o realizar os testes beta.
cadastramento
5 Falta de povoamento inicial Alta Baixa Impossibilidade de Cobrar providência do cliente.
das bases de dados. realizar os testes beta.
6 Mudança de Legislação Média Baixa Pode ser necessário Isolar as classes e interfaces
refazer partes referentes susceptíveis de mudança de
à nota fiscal. legislação.

Os riscos não permanecem constantes durante a execução de um projeto. Alguns desaparecem,

outros novos surgem, e outros sofrem alterações de probabilidade e impacto, mudando portanto a
prioridade. Um relatório de acompanhamento do projeto juntamente com uma tabela atualizada para
monitoração dos riscos. A tabela de estimativa deve ser repetida e atualizada para refletir as
modificações ocorridas, até que os riscos sejam concretizados ou completamente
eliminados.[PADUA03]

As questões a seguir foram derivadas de dados de riscos obtidos por levantamento feito com
gerentes de projeto de software experientes, em diferentes partes do mundo [KEIL98]. As questões
estão ordenadas por sua importância relativa em relação ao sucesso de um projeto:
1. A alta administração do software e do cliente empenhou-se formalmente em apoiar o projeto?
2. Os usuários finais estão entusiasticamente empenhados com relação ao projeto?
3. Os requisitos estão plenamente entendidos ?
4. Os clientes envolveram-se totalmente na especificação dos requisitos?
5. Os usuários finais têm expectativas realistas ?
6. O escopo do projeto é estável?
7. A equipe de projeto tem a combinação de aptidões adequadas?
8. Os requisitos do projeto são estáveis?
9. A equipe de projeto tem experiência com a tecnologia a ser implementada?
10. A quantidade de pessoal é adequada ao projeto?
11. Todos os membros da equipe e usuários envolvidos no projeto concordam com a importância do
projeto e com os requisitos do sistema ?

8
Se qualquer dessas questões for respondida negativamente, os passos de atenuação, monitoração e
gestão devem ser instituídos imediatamente. O grau em que o projeto está em risco é diretamente
proporcional ao número de respostas negativas a essas questões.
Segundo PMBOK [PMBOK00], existem ferramentas e técnicas para identificação de riscos. São
elas:
• Listas de Verificação: Questões do produto, tecnologia e pessoas envolvidas no projeto;
• Fluxogramas: Melhor compreensão das causas e efeitos dos riscos do projeto;
• Entrevistas: Entrevistas orientadas aos riscos com participação de várias partes envolvidas;
8. RISCOS E ASPECTOS RELEVANTES NA IMPLANTAÇÃO DO ERP
O termo implantação compreende o processo de adoção do ERP, que envolve desde a seleção,
aquisição, até a implantação e testes.[MENDES03]
Segundo Filho [FILHO00], esse processo deve ser planejado, passar por uma etapa de análise de
funcionalidades da empresa e do sistema e estar de acordo com a orientação estratégica da empresa.
Para Lima [LIMA00], o sucesso na implantação depende do alinhamento entre software, cultura e
objetivos de negócio da empresa. É necessário ter:
Articulação entre os objetivos do projeto e as expectativas de mudança da organização; boa
gerência; comprometimento da alta administração e dos proprietários dos processos; e os usuários
devem compreender a mudança. Na seleção, deve-se avaliar o sistema mais adequado à empresa. A
Implantação é um processo caro, demorado e obriga a corporação a repensar sobre sua estrutura e
processos. A equipe de implantação deve conhecer o sistema e os processos de negócio da empresa.
Conforme Buckout [BUCKOUT99], a implantação de um ERP tem sido problemática por duas
razões: A empresa não faz antes as escolhas estratégicas para configurar os sistemas e os processos,
e a implantação escapa do controle da empresa. Muitas empresas encaram com um projeto de
tecnologia e não como um projeto empresarial. Além desses fatores, a alta direção deve estar
comprometida e envolvida na implantação para indicar prioridades estratégicas e vincular controles
e incentivos para os envolvidos no sucesso do projeto.
Diante desses fatores citados, foram identificados os principais fatores de risco na implantação de
um sistema ERP. Serão apresentados a seguir:
8.1 SELEÇÃO DE PACOTE INADEQUADO
Segundo Tonini [TONINI03], a seleção é a primeira etapa do ciclo de vida de um sistema
corporativo e tem, basicamente, o objetivo de identificar, entre todas as alternativas avaliadas,
aquela que seja mais adequada para atender às necessidades sistêmicas da empresa. A utilização de
uma metodologia prática e objetiva pode representar importante contribuição para o sucesso da
implantação de um sistema desse porte, levando à economia de tempo e dinheiro, bem como
garantindo satisfação para a empresa.
O risco de cometer um erro na escolha do pacote pode levar ao fracasso a implantação do ERP,
devido à falta de aderência aos processos de negócios na empresa adquirente, não estando de acordo
com os seus objetivos e estratégias.
8.2 PLANEJAMENTO INADEQUADO DA IMPLEMENTAÇÃO
Segundo Zwicker [ZWICKER03], a implementação constitui a segunda etapa do ciclo de vida de
sistemas ERP, embora o termo seja normalmente utilizado para representar o ciclo de vida
completo. A implementação pode ser definida como o processo pelo qual os módulos do sistema são
colocados em funcionamento em uma empresa. Ela envolve a adaptação dos processos de negócio
ao sistema, a parametrização e eventual customização do sistema, a carga ou conversão dos dados
iniciais, a configuração de hardware e software de suporte, o treinamento de usuários e gestores e a

9
disponibilização de suporte e auxílio. Essa etapa contempla as tarefas que vão desde o término da
elaboração do plano de implementação até o momento do início da operação.
Para ter sucesso na implementação do ERP, um programa de mudanças organizacionais deve ser
gerenciado e com muitos esforços na implantação do software. [HONG02]
Devido à abrangência e complexidade da implementação dos sistemas ERP, esta fase é a mais
crítica quanto aos riscos a ela estabelecida, pois envolve mudanças organizacionais e alta capacidade
técnica dos implementadores para que os conflitos e falhas sejam minimizadas. É nessa fase que
ocorrem os erros de concepção, escopo e especificação de requisitos, provocando o não
cumprimento de prazos e custos do projeto.
8.3 DIFICULDADE DA CUSTOMIZAÇÃO
“Geralmente, requisitos corretos no início do projeto são mudados posteriormente” [FREITAS00].
A customização é um processo crucial, longo, e caro na implementação bem sucedida de sistemas
ERP, e conseqüentemente é muito importante que sejam uma das especialidades das empresas
vendedoras e consultoras de implementação de ERP. [GEFEN02]
A decisão sobre customizar ou não o pacote adquirido nem sempre foi tratada com a devida
importância pela equipe de implementação, resultando, em alguns casos, no completo fracasso na
implementação.[BLAITT00]
“A customização é o único caminho para alcançar diferenciação em sistemas ERP”. [GARTNER99]
Com a dificuldade de compreender certos processos e seus requisitos, a customização do sistema
ERP para melhorar a aderência aos processos de negócios da empresa, eleva o risco de fracasso do
projeto, pois o torna caro e longo demais o prazo de término, inviabilizando o projeto de
implantação dependendo do porte da empresa.
8.4 INÍCIO DA OPERAÇÃO
O início da operação de um sistema ERP pode ser realizado de 3 modos diferentes. Possui riscos e
vantagens associados a cada um dos modos. São eles: [SOUZA00]
Tabela 3 – Riscos e vantagens dos modos de início de operação. [SOUZA00]
Modo Riscos Vantagens
Big-bang Possibilidade de parar a empresa – Grande esforço para estabilizar. Há mais motivação para enfrentar o início.
Small-Bang Possibilidade de parar a empresa – Há necessidade de construção de interfaces. Facilita o estabelecimento de prioridades.
Fases Não há envolvimento simultâneo de toda empresa – Parar módulos já estabilizados. Menor possibilidade de parar a empresa.

8.5 RESISTÊNCIA A MUDANÇAS

Conforme Zwicker [ZWICKER03], a etapa de implementação é uma das mais críticas. As
dificuldades decorrem principalmente do fato de ela envolver mudanças organizacionais, que
implicam alterações nas tarefas, responsabilidades de indivíduos, departamentos e transformações
nas relações entre os diversos departamentos. É importante que essas mudanças conduzam à
otimização global dos processos da empresa em contrapartida à otimização localizada de atividades
departamentais.
Caso a cultura organizacional não esteja preparada para mudanças, o risco de insucesso aumenta de
forma que pode comprometer todo os recursos empregados no projeto.
8.6 FALTA DE COMUNICAÇÃO ENTRE ENVOLVIDOS
Do porte e complexidade das mudanças e dos conflitos que ela pode causar entre os envolvidos
“Stackholders” no projeto, decorre a necessidade de intensa participação e comprometimento da alta
direção da empresa nessa etapa e de garantir a comunicação entre todas as equipes envolvidas.
[ZWICKER03]

10
A falta de envolvimento da alta administração da empresa adquirente juntamente com a empresa
fornecedora, interferindo e apoiando na resolução dos conflitos ocasionados na dificuldade de
concepção dos processos de negócios, aumenta o risco de fracasso na implantação.
8.7 NÃO CAPACITAÇÃO DE USUÁRIOS FINAIS
Segundo Pereira [PEREIRA03], as conseqüências finais da sucessão de erros ocorridos no processo
de implementação produzem acontecimentos na fase posterior a implementação, os quais derivam-
se do não treinamento dos usuários, independentemente de seu nível hierárquico. Isso provoca
diversos erros na utilização do sistema ERP.
A falta de capacitação para os usuários finais, aumenta o risco de fracasso, onde a operação do
sistema, a aceitação e os resultados da nova tecnologia estão totalmente centradas nessas pessoas.
8.8 ERRO NA ESTIMATIVA DE CUSTOS COM INFRA-ESTRUTURA
Para Lima [LIMA00], muitas empresas calculam de forma errada os custos relativos à implantação
de um ERP. Os custos devem incluir: Licenças do Software, hardware, serviços em consultoria,
treinamento, e os ajustes após a implantação.
A não previsão desses custos adicionais, eleva o risco de insucesso da implantação num eventual
racionamento de orçamento estabelecido no projeto, já que são vitais para o sucesso do projeto.
8.9 DESMOTIVAÇÃO DE PESSOAL
Segundo Dempsey [DEMPSEY99], como o projeto é amplo, as empresas perdem de vista as
motivações originais e naufragam diante das dificuldades encontradas. Muitos sistemas têm uma
interface ruim com o usuário. Para solucionar esse problema, elas adotam outro sistema com a
interface gráfica mais atraente, que facilite o uso pelo usuário.
Manter a equipe comprometida e motivada para continuidade dos trabalhos, mesmo diante de tantas
dificuldades, minimiza o risco de fracassar a implantação diante dos usuários perderem o interesse
em colaborar e facilitar a operação do sistema ERP.
9. CONCLUSÃO
O sistema ERP permite a integração total da empresa sendo capaz de levar as informações em tempo
real aos tomadores de decisão, obtendo eficiência e eficácia na gestão do negócio.
Para tanto, as dificuldades e riscos para se conseguir a implantação com sucesso desta ferramenta de
gestão, requer muitas mudanças organizacionais a serem realizadas.
A gestão dos riscos aqui apresentada, não teve a profundidade de identificar todos os riscos e sim
demonstrar de uma forma sistêmica, como fazer essa identificação e apresentar os fatores de riscos
mais comuns de software. Cabe ao gerente de projetos, constante identificação, controle, e
monitoração de outros riscos que podem aparecer de acordo com cada empresa, diferindo ao seu
porte, cultura organizacional, política e estratégias de negócios. Assim eleva-se a probabilidade de
sucesso na implantação diante de que os fatores são críticos e envolvem áreas de conhecimentos
amplos e complexos.
Após a implantação do ERP, o passo seguinte é a implementação das tecnologias para inteligência
empresarial , ou Business Intelligence (BI), entre elas Data Warehouse, Data Mining, CRM, entre
outras.
Segundo Gartner Group, 70% dos projetos de data warehouse e CRM falham, graças à maioria das
implantações de ERP falharem ou terem graves problemas na implantação [SERRA02]. Diante
dessa lógica não é difícil prever que sem a gestão adequada dos riscos nas implantações dos
sistemas ERP, buscando sucesso no projeto, inviabilizará a seqüência da implementação das
tecnologias do BI, sendo que um dos principais fatores para que isso ocorra é a falta de
compromisso da alta direção da empresa e nas dificuldades de implantar mudanças culturais, mudar
processos de negócios existentes em adaptar e atualizar os sistemas legados.

11
10. REFERÊNCIAS BIBLIOGRÁFICAS
[BLAITT] BLAITT, JEFFERSON, Uma identificação dos modelos de customização em sistemas integrados
de gestão empresarial, http://www.unip.br/websites/posgraduacao/engproducao, SP, 2000.
[BROOKS87] BROOKS, F. Essence and accidents to software engineering. L. A., California, IEEE, 1987.
[BUCKOUT99] BUCKHOUT,S, et al, Por um ERP eficaz, HSM Management, Set./Out. 1999.
[CHARETTE89] CHARETTE, R., N., Software Engineering Risk analysis and management, McGraw H.89.
[CORRÊA97] CORRÊA,H. L., ERPs: por que as implantações são tão caras e raramente dão certo? In:
Simpósio de Administração da Produção, Logística e Operações Industriais, 1998, Anais do simpósio, SP.
[COUTINHO02] COUTINHO, ÍTALO, Planejar é a chave para o sucesso, http://www.zopp.com.br, 2002.
[DAVENPORT98] DAVENPORT, T.H., Putting the enterprise into the enterprise system. H. B. R.1998.
[DEMPSEY99] DEMPSEY, M, Pacote de ERP não resolve tudo. Gazeta Mercantil, In: Sistemas ERP no
Brasil, Teoria e Casos, São Paulo,1999.
[FILHO00] FILHO, ESCRIVÃO, et al. , O sistema integrado de gestão empresarial é fator de
competitividade para pequenas e médias empresas? Revista UNIARA, no.8, In: Sistemas ERP no Brasil,
Teoria e Casos, 2000.
[FREITAS00] FREITAS, LUÍS RICARDO NAPOLITANO, Projetos em Tecnologia da Informação –
Como acertar através da análise dos erros. Dissertação de Mestrado, USP-SP, 2000.
[GARTNER99] BOND, BRUCE, ERP Scenario, Gartner Group, 1999.
[GEFEN02] GEFEN, DAVID, Nurturing clients’ trust to encourage engagement success during the
customization of ERP systems, PERGAMON, OMEGA – The Int. Journal of Management Science, 2002.
[HIGUERA95] HIGUERA, R.P., “Team Risk Management”, CrossTalk, U.S. Dept. of Defense, jan/1995.
[HONG02] HONG, KYUNG KWON, et al. The critical success factors for ERP implementation,
ELSEVIER, 2002.
[IEEE95] IEEE 1044.1-1995, IEEE Standard Glossary of Software Engineering Terminology, IEEE,1995.
[KEIL98] KEIL, M., et al., “A Framework for identifying software project risks”, ACM, 1998.
[LIMA00] LIMA, A. D. A., et al., Implantação de pacote de gestão empresarial em médias empresas.
KMPress, http://www.kmpress.com.br, 2000.
[MCT02] Guide ISO 73 – Risk Management – Guidelines for use in standards in: Ministério da Ciência e
Tecnologia, Qualidade e Produtividade no Setor de Software Brasileiro, 2002.
[MENDES03] MENDES, JULIANA VEIGA, et al. , Sistemas Integrados de Gestão ERP em pequenas e
médias empresas: Um confronto entre a teoria e prática empresarial, In: Sistemas ERP no Brasil, Teoria e
Casos, São Paulo, Ed.Atlas, 2003.
[PADUA03] FILHO, WILSON DE PÁDUA PAULA, Engenharia de Software, RJ, Ed. LTC, 2003.
[PEREIRA03] PEREIRA, CARLOS DANIEL SCHNEIDER, et al, Caso Seguradora: Insucesso na
implementação de um sistema ERP, In: Sistemas ERP no Brasil, Teoria e Casos,São Paulo, Ed. Atlas, 2003.
[PETERS01] PETERS, JAMES F. et al. Engenharia de Software,Rio de Janeiro, Ed. Campus,2001.
[PMBOK00] PMBOK, Project Management Body of Knowledge, PMI Project Management Institute, 2000.
[PRESSMAN02] PRESSMAN, ROGER S., Engenharia de Software, Rio de Janeiro, Ed. McGraw-H.,2002.
[SERRA02] SERRA, LAÉRCIO, A essência do Business Intelligence,São Paulo, Ed. Berkeley, 2002.
[SOMMERVILLE03] SOMMERVILLE, IAN, Engenharia de Software, São Paulo, Ed. Pearson, 2003.
[SOUZA00] SOUZA, C. A., et al. , Ciclo de Vida de sistemas ERP, Caderno de Pesquisas em Administração,
In: Sistemas ERP no Brasil, Teoria e Casos,São Paulo, v.1 no. 11, 1o.trim./2000.
[TONINI03] TONINI, ANTONIO CARLOS, Metodología para seleção de sistemas ERP, In: Sistemas ERP
no Brasil, Teoria e Casos,Ed.Atlas, SP,2003.
[TOURION02] TOURION, CEZAR, Gestão Empresarial Magazine, São Paulo,outubro 2002.
[ZWICKER03] ZWICKER, RONALDO et al, Sistemas ERP, In: Sistemas ERP no Brasil, Teoria e Casos,
São Paulo, Ed. Atlas, 2003.

12