Vous êtes sur la page 1sur 90

Pontifcia Universidade Catlica

do Rio de Janeiro

Marcantonio Giuseppe Maria Carlo Fabra

Gerenciamento de Riscos em Projetos de Implantao de Sistemas ERP


PUC-Rio - Certificao Digital N 0421051/CD

Dissertao de Mestrado Dissertao apresentada como requisito parcial para a obteno do grau de Mestre pelo Programa de Ps-Graduao em Logstica do Departamento de Engenharia Industrial da PUC Rio.

Orientador: Prof. Jos Eugenio Leal.

Rio de Janeiro Dezembro de 2006

Pontifcia Universidade Catlica


do Rio de Janeiro

Marcantonio Giuseppe Maria Carlo Fabra

Gerenciamento de Riscos em Projetos de Implantao de Sistemas ERP

PUC-Rio - Certificao Digital N 0421051/CD

Dissertao apresentada como requisito parcial para obteno do ttulo de Mestre (opo profissional) pelo Programa de Ps-Graduao em Engenharia Industrial da PUC Rio. Aprovada pela Comisso Examinadora abaixo assinada. Prof. Jos Eugnio Leal Orientador Departamento de Engenharia Industrial / PUC-Rio

Prof. Jos Roberto de Souza Blaschek Co-Orientador Departamento de Informtica / PUC-Rio

Prof. Silvio Hamacher Departamento de Engenharia Industrial PUC-Rio

Prof. Rodrigo Salvador Monteiro COPPE/UFRJ

Prof. Jos Eugnio Leal Coordenador Setorial do Centro Tcnico Cientfico / PUC-Rio Rio de Janeiro, 19 de dezembro de 2006.

Todos os direitos reservados. proibida a reproduo total ou parcial do trabalho sem autorizao da universidade, do autor e do orientador.

Marcantonio Giuseppe Maria Carlo Fabra Graduou-se em Informtica pela PUC-Rio em 1986. Obteve o ttulo de Master in Project Management pela George Washington University em 2002 e a certificao PMP (Project Management Professional) pelo PMI em 2002. Concluiu MBA em Gerncia de Projetos pela FGV em 2003. Trabalha h 10 anos com gerenciamento de projetos de informtica, atualmente no Escritrio de Projetos de TI da Oi. Atua h 20 anos como professor universitrio, atualmente ministrando a cadeira de Gerncia de Projetos de Informtica e atuando como professor-orientador de monografias do Bacharelado de Informtica da PUC-RJ..

PUC-Rio - Certificao Digital N 0421051/CD

Ficha Catalogrfica

Fabra, Marcantonio Giuseppe Maria Carlo Gerenciamento de riscos em projetos de implantao de sistemas ERP / Marcantonio Giuseppe Maria Carlo Fabra ; orientador: Jos Eugenio Leal. 2006. 90 f. il. ; 30 cm Dissertao (Mestrado em Engenharia Industrial)Pontifcia Universidade Catlica do Rio de Janeiro, Rio de Janeiro, 2006. Inclui bibliografia 1. Engenharia industrial Teses. 2. Sistemas integrados. 3. Gesto da cadeia de suprimentos. 4. ERP. 5. Gerenciamento de riscos. 6. Riscos. I. Blaschek, Jos Roberto de Souza. II. Pontifcia Universidade Catlica do Rio de Janeiro. Departamento de Engenharia Industrial. III. Ttulo.

CDD: 658.5

PUC-Rio - Certificao Digital N 0421051/CD

A minha esposa Ana Flvia, que alm de ter sido a minha maior incentivadora neste Mestrado, est sempre de mos dadas comigo subindo os degraus da escada da vida e mostrando, atravs de atos, o que e como se constri um verdadeiro amor entre duas pessoas.

Agradecimentos

Deus por ter me dado f e fora para conseguir chegar ao fim deste trabalho.
PUC-Rio - Certificao Digital N 0421051/CD

Ao meu pai Giacomo (in memoriam) que onde estiver agora sabe que tudo que fiz e fao na minha vida dedicado a ele por tudo que ele foi e fez por mim. Ao meu Orientador, Professor Jos Roberto de Souza Blaschek, o meu agradecimento pelo apoio, amizade, pacincia e confiana na realizao deste trabalho. A mulher da minha vida, Ana Flvia, por tudo que ela significa para mim e por formar comigo uma dupla de muito amor, f e determinao, acreditando sempre que os sonhos podem ser conquistados. A meus filhos queridos Gabriel e Rafael que torceram por mim todo o tempo e tiveram a pacincia de suportar a minha ausncia. A minha me Ldia, meu irmo Gianfranco, meus sogros Moacyr e Brandelina, meus cunhados Cludio e Ana Paula e minha sobrinha Gabriella, pelo apoio e palavras de incentivo nos momentos crticos. A todos os professores do Mestrado Profissional em Logstica da PUC-Rio pelo privilgio de ter recebido seus conhecimentos e ter podido constatar as suas virtudes pessoais e acadmicas.

Resumo
Fabra, Marcantonio Giuseppe Maria Carlo Fabra. Gerenciamento de riscos em projetos de implantao de sistemas ERP. Rio de Janeiro, 2006. 90p. Dissertao de Mestrado Departamento de Engenharia Industrial, Pontifcia Universidade Catlica do Rio de Janeiro.

O avano da tecnologia de informao (TI) nos ltimos anos vem permitindo s empresas executarem operaes que antes eram inimaginveis. A adoo de sistemas integrados tem sido uma constante nas grandes e mdias empresas mundiais que tm buscado integrar todas as suas dimenses do negcio, como o planejamento, compras, vendas, manufatura, finanas, controle e suprimentos, entre outras, com o objetivo de obter maior agilidade e poder de deciso. Para atender a essa necessidade, os sistemas ERP surgiram com o
PUC-Rio - Certificao Digital N 0421051/CD

objetivo de suprir o rpido desenvolvimento destes sistemas integrados. capital que estes projetos de implantao sejam bem sucedidos sob pena de impactar a empresa como um todo. A preocupao com um gerenciamento de riscos efetivo em projetos desta natureza um dos fatores crticos do seu sucesso. Entretanto o que se v a no utilizao desta prtica na maioria destes projetos. Este trabalho tem como objetivo desenvolver uma lista de riscos no sentido de minimizar os seus impactos nos objetivos destes projetos com o intuito de auxiliar futuras implantaes a se planejarem quanto a estes riscos.

Palavras-Chave
Sistemas Integrados, Gesto da Cadeia de Suprimentos, ERP,

Gerenciamento de Riscos, Riscos.

Abstract
Fabra, Marcantonio Giuseppe Maria Carlo Fabra. Risk management in ERP systems implantation projects. Rio de Janeiro, 2006. 90p. Master dissertation Industrial Engineering Department, Pontifcia Universidade Catlica do Rio de Janeiro.

The advance of information technology (IT) in recent years has allowed companies to execute operations that previously were unimaginable. The adoption of integrated systems has been common in large and medium-sized companies world-wide as they have sought to integrate all aspects of their business, such as planning, purchasing, sales, manufacturing, finance, control, and supply, with the objective of achieving greater agility and the power to make decisions. To take care of this necessity, ERP systems have emerged, which offer the potential for
PUC-Rio - Certificao Digital N 0421051/CD

the fast development of these integrated systems. However, it is essential that the implementation of these projects is successful since they impact the company as a whole. Hence, effective risk management in projects of this nature is one of the critical factors of their success. However, appropriate risk management is seldom practiced in the majority of these projects. This work has the objective of developing a list of probable risks that may affect the success of these projects, with the intention of minimizing their impact, and assisting future implementations to plan properly to avoid these risks.

Keywords
Integrated Systems, Supply Chain Management, ERP, Risk Management, Risks.

Sumrio

1 Introduo 1.1 A histria do ERP 1.2 Mercado de ERP 1.3 Objetivos 1.4 Metodologia cientfica 1.4.1 Coleta de Dados 1.4.2 Tratamento de Dados 1.5 Estrutura da Dissertao 2 Fatores crticos na implantao de sistemas ERP 2.1 Definio de Sistemas ERP
PUC-Rio - Certificao Digital N 0421051/CD

12 12 14 16 17 18 18 18 20 20 23 24 25 26 27 33 41 44 44 45 46 49 53 57 61 64 67

2.2 Estrutura dos Sistemas ERP 2.3 Levantamento dos benefcios dos sistemas ERP 2.4 Implantao dos Sistemas ERP 2.4.1 Utilizao de consultoria externa 2.4.2 Etapas da implantao do ERP 2.5 Fatores crticos da implantao dos sistemas ERP 2.6 Tendncias do ERP: ERP II e BoB 3 Metodologias de gerenciamento de risco 3.1 Definio de risco 3.2 Definio de gerenciamento de riscos 3.3 O gerenciamento de riscos na abordagem de BOEHM 3.4 O gerenciamento de riscos na abordagem do RUP 3.5 O gerenciamento de riscos na abordagem do CMMI 3.6 O gerenciamento de riscos na abordagem do PMI 3.7 Comparao entre as metodologias apresentadas 4 Uma lista de riscos na implantao de sistemas ERP 4.1 Taxonomia de riscos da SEI

4.2 Projeto riscos universais da INCOSE / PMI 4.3 Escolha do mtodo para a lista de riscos 4.4 A lista de riscos 4.4.1 Riscos de Gerenciamento 4.4.1.1 Riscos Corporativos 4.4.1.2 Riscos de Gerenciamento de Stakeholders 4.4.2 Riscos Externos 4.4.2.1 Riscos Naturais 4.4.2.2 Riscos Culturais 4.4.2.3 Riscos Econmicos 4.4.3 Riscos Tecnolgicos 4.4.3.1 Riscos de Requerimentos Tecnolgicos 4.4.3.2 Riscos de Adequaes Tecnolgicas
PUC-Rio - Certificao Digital N 0421051/CD

70 72 73 74 74 75 77 77 77 78 78 78 79 80

4.4.3.3 Riscos de Aplicaes Tecnolgicas

5 Concluso 5.1 Sugestes para trabalhos futuros

82 83

6 Referncias bibliogrficas

85

Lista de Figuras

Figura 1 Estrutura conceitual do ERP e sua evoluo desde o MRP Figura 2 Ranking de rendimentos dos fornecedores ERP Figura 3 Relao entre ERP e desempenho Figura 4 Funcionalidades do Sistema ERP Figura 5 Estrutura Tpica de um Sistema ERP Figura 6 Principais problemas encontrados durante a implantao do ERP Figura 7 Modelo de desenvolvimento em espiral de Barry Boehm
PUC-Rio - Certificao Digital N 0421051/CD

13 15 21 23 24 36 47 48 50 51

Figura 8 Processo de Gerncia de Riscos proposto por Boehm Figura 9 Fases do RUP Figura 10 Estrutura dinmica e esttica do RUP Figura 11 RUP: Disciplina Gerenciamento de Projeto: Viso Geral da Atividade Figura 12 Estrutura do CMMI Figura 13 Viso Geral das reas de Conhecimento e Processos de Gerenciamento de Projetos Figura 14 Grupo de Processos do Ciclo de Vida de um Projeto segundo o PMI Figura 15 Os processos da gerncia de riscos segundo o PMI Figura 16 Riscos de Software segundo a SEI Figura 17 Riscos de Desenvolvimento de Software segundo a SEI Figura 18 Riscos Universais

52 55

58

59 60 67 68 71

Lista de Tabelas

Tabela 1 Pesos atribudos na pesquisa Utilizao de softwares de Supply Chain Management em empresas brasileiras da COPPEAD Tabela 2 Benefcios e problemas dos sistemas ERP Tabela 3 Objetivos Especficos da rea de Processo Risk Management do CMMI Tabela 4 Processos da gerncia de riscos Boehm x RUP x CMMI x PMI Tabela 5 Comparativo entre os mtodos de agrupamento de riscos Taxonomia de Riscos da SEI e Riscos Universais da INCOSE/PMI
PUC-Rio - Certificao Digital N 0421051/CD

35 38

56

62

73 73 74 75 77 77 78 78 79 80

Tabela 6 Distribuio dos riscos Tabela 7 Riscos Corporativos Tabela 8 Riscos de Gerenciamento de Stakeholders Tabela 9 Riscos Naturais Tabela 10 Riscos Culturais Tabela 11 - Riscos Econmicos Tabela 12 Riscos de Requerimentos Tecnolgicos Tabela 13 Riscos de Adequaes Tecnolgicas Tabela 14 - Riscos de Aplicaes Tecnolgicas

1. Introduo
Podemos definir os sistemas ERP como sistemas de informao integrados na forma de um pacote de software que tem a finalidade de dar suporte maioria das operaes de uma organizao. A introduo de um sistema ERP em uma empresa tem um grande impacto nas operaes que so realizadas diariamente em suas instalaes. Estes sistemas so atraentes pois surgiram com a promessa de resolver problemas de integrao, disponibilidade e confiabilidade de informaes ao incorporar em um nico sistema as funcionalidades que suportam diversos processos de negcios em uma empresa (Oliveira e Ramos, 2002). A implementao de um sistema ERP tambm uma oportunidade para
PUC-Rio - Certificao Digital N 0421051/CA

que as organizaes revejam seus processos internos, bem como a sua estratgia de trabalho, com o objetivo de atender mais rapidamente s demandas do mercado e, de uma maneira geral, aumentar sua lucratividade.

1.1. A histria do ERP Os sistemas ERP Enterprise Resource Planning surgiram da evoluo dos sistemas MRP Materials Requirement Planning (planejamento das necessidades de material) e MRP II Manufacturing Resource Planning (planejamento de recursos da produo) conforme demonstrado na figura 1. O princpio bsico do MRP o princpio do clculo da quantidade de itens requisitados em um dado momento com base nas necessidades de produtos finais, nas informaes das estruturas de produto e nos dados de estoque (Slack et al., 1999).

13

PUC-Rio - Certificao Digital N 0421051/CA

Figura 1 Estrutura conceitual do ERP e sua evoluo desde o MRP (Fonte: Corra et al., 2001).

Ao mdulo bsico do clculo de necessidades do MRP foram agregados mdulos de outras funes da cadeia de suprimentos como o planejamento da capacidade de produo (RCCP - Rough-cut capacity planning e CRP Capacity Requirements Planning), o planejamento de vendas e operao (S&OP Sales and Operations Planning), a programao-mestre da produo (MPS Master Production Schedule), o controle de compras (PUR - Purchasing) e o controle da fbrica (SFC - Shop Floor Control) e, com isto, estes novos sistemas mais amplos passaram a se chamar MRP II - Manufacturing Resource Planning (planejamento de recursos da produo). De acordo com Corra e Gianesi (1994), O princpio bsico do MRP II o princpio do clculo de necessidades, uma tcnica de gesto que permite o clculo, viabilizado pelo uso de computador, das quantidades e dos momentos em que so necessrios os recursos de manufatura (materiais, pessoas, equipamentos, entre outros), para que se cumpram os programas de entrega de produtos com um mnimo de formao de estoques. Os sistemas MRP II, embora trouxessem benefcios potenciais para a rea responsvel pelo planejamento da produo, no satisfaziam plenamente s

14 necessidades globais das empresas. Uma abrangncia limitada das suas funcionalidades e dificuldades de integrao com outros sistemas legados utilizados nas diferentes reas da empresa eram fatores que contribuam para esta insatisfao. Os sistemas MRP II foram, ento, acrescidos de novos mdulos integrados como, por exemplo, mdulos de controladoria, de gerenciamento financeiro, de compras, de apoio s atividades de vendas e de gerenciamento de recursos humanos. Esses novos sistemas integrados, capazes de atender s necessidades de informao de diversos departamentos e processos de negcio das empresas, passaram a ser chamados de sistemas ERP Enterprise Resource Planning (planejamento de recursos da corporao) (Corra et al., 2001). Os sistemas ERP podem ento ser considerados uma evoluo do modelo MRP II medida em que permitem tambm controlar os demais recursos empresariais (recursos
PUC-Rio - Certificao Digital N 0421051/CA

financeiros, recursos

humanos indiretos,

vendas,

distribuio, gerenciamento de projetos, entre outros). O crescimento da utilizao dos sistemas ERP aconteceu na dcada de 90 motivado pela globalizao e conseqente acirramento da concorrncia, o que fez com que as empresas buscassem solues de ferramentas mais robustas para gesto dos seus negcios (Moraes, 2004). Vale destacar que, em muitas das implantaes de sistemas ERP, apenas so adquiridos os mdulos voltados para a parte administrativa da organizao, ficando de lado todos mdulos relativos ao MRP II, ou seja, a parte que trata da produo. As informaes dos sistemas legados, at ento responsveis por suportar as operaes de uma empresa, so transferidas para o ERP. Porm, nem sempre todos os sistemas legados so transferidos e com isto torna-se necessrio a criao de interfaces para propiciar a troca de informaes entre eles e o ERP. 1.2. Mercado de ERP O mercado de sistemas ERP foi um dos que cresceu mais rapidamente na indstria de software (Willis e Willis-Brown, 2002).

15 Estes sistemas so bastante complexos e necessitam de um planejamento cuidadoso para garantir o sucesso de sua implantao (Gupta, 2000). Uma pesquisa da IDC (International Data Corporation) aponta que 20% das empresas brasileiras indicaram o ERP como prioridade de TI em 2005, alm de ter estimado para este mesmo ano que o mercado de ERP brasileiro cresceu 12% em relao ao ano anterior, chegando ao patamar de 283 milhes de dlares (Computerworld, 2005). Um estudo da AMR Research mostra que o mercado mundial de aplicaes ERP foi de 25,4 bilhes de dlares em 2005 e vai chegar a 29 bilhes de dlares no final de Research, 2006). As organizaes modernas esto preocupadas com uma efetiva integrao
PUC-Rio - Certificao Digital N 0421051/CA

2006. O estudo faz ainda uma previso de que nos

prximos cinco anos este mercado vai crescer a uma mdia de 10% ao ano (AMR

dos seus sistemas de informao e com a atualizao de sua base tecnolgica. Os sistemas ERP apresentam benefcios neste sentido. Por conseguinte, a preocupao com as dificuldades e limitaes apresentadas por este tipo de tecnologia devem ser maximizadas em prol de uma efetiva obteno destes benefcios. Os rendimentos obtidos pelos fornecedores de solues ERP vm crescendo desde 2004, como pode ser visto na figura 2:
2005 Revenue Rank 1 2 3 4 5 Revenue Share, 2004 40% 10% 5% 3% 3% Revenue Share, 2005 42% 20% 6% 4% 3% Revenue Share Forecast, 2006 43% 23% 5% 4% 3%

Vendor

SAP Oracle Sage Group Microsoft SSA Global

Figura 2 Ranking de rendimentos dos fornecedores ERP (Fonte: AMR Research, 2006)

16 importante enfatizar os fornecedores SAP e a Oracle, lderes deste segmento, que juntos detinham 62% do mercado mundial em 2005 e tm a previso de deter 66% deste mercado no final de 2006. Para obter os benefcios esperados capital analisar os riscos da implantao de um projeto desta natureza sob pena de se perder muito tempo e dinheiro sem que se consiga alcanar resultados satisfatrios. As dificuldades e a ocorrncia de alta taxa de falha na implementao de sistemas ERP tm sido amplamente citadas na literatura, mas a publicao de resultados de pesquisas sobre os fatores crticos de sucesso nestas implementaes tem sido rara e fragmentada (Nah et al., 2001). Um importante trabalho sobre fatores crticos de sucesso na implantao de sistemas ERP foi desenvolvido por Nah et al. (2001) que, a partir de uma ampla reviso bibliogrfica, apresentam e discutem a importncia de 11 fatores crticos de sucesso na implementao de um ERP.
PUC-Rio - Certificao Digital N 0421051/CA

Seguindo esta linha, Gamba et al. (2004) apresentam um mtodo para gesto de riscos em implementaes de sistemas ERP baseado em fatores crticos de sucesso, coletando ainda evidncias de que o mtodo proposto ajuda na melhora da gesto de riscos deste tipo de projeto. 1.3. Objetivos O presente trabalho tem por objetivo inicial analisar problemas que sejam causadores de falhas que possam impactar as implantaes destes tipos de sistemas. Em seguida ir pesquisar metodologias de riscos propostas pela literatura e far um comparativo entre elas, com o objetivo de identificar os principais passos para uma efetiva gerncia de riscos em projetos desta natureza. Por ltimo, com base nos dados levantados at ento, ir disponibilizar uma lista de provveis riscos em projetos de implantao de sistemas ERP, utilizando uma taxonomia, com o intuito de auxiliar futuras implantaes no que tange gerncia de riscos.

17 1.4. Metodologia Cientfica

A metodologia utilizada nesta pesquisa adotou como referncia a taxonomia apresentada por Vergara (2003). Vergara qualifica o tipo da pesquisa em relao a dois aspectos: quanto aos fins e quanto aos meios. Quanto aos fins, a pesquisa foi identificada como descritiva, explicativa e metodolgica. A pesquisa descritiva traz tona caractersticas de determinado fenmeno. Ela no tem o compromisso de elucidar os eventos que descreve, embora sirva de base para a explicao. Foi utilizada para identificar as caractersticas dos sistemas ERP. J a pesquisa explicativa possui como principal objetivo tornar o fenmeno
PUC-Rio - Certificao Digital N 0421051/CA

inteligvel, apresentando justificativas para sua ocorrncia. Utiliza-se a pesquisa descritiva para embasar suas explicaes. Foi empregada no estudo para esclarecer as razes da ineficincia em projetos de implantao dos sistemas ERP. Com base na pesquisa metodolgica, apresentaram-se os passos necessrios para a implantao de uma metodologia de gerenciamento de riscos em projetos desta natureza, com o objetivo de minimizar os problemas encontrados nestas implantaes. Este tipo de pesquisa refere-se a instrumentos de manipulao de dados da realidade, que vo indicar formas e procedimentos para se alcanar o objetivo proposto. Quanto aos meios, a pesquisa caracterizou-se por ser essencialmente bibliogrfica, que um estudo ordenado e metdico, cuja fonte o material disponvel para o pblico em geral, como livros, revistas cientficas, artigos, papers, jornais, etc. Em menor escala, utilizou-se a investigao documental para a obteno de algumas definies levantadas nesta dissertao.

18 1.4.1. Coleta de dados Os dados foram coletados por meio de: a) pesquisa bibliogrfica em livros, revistas especializadas, peridicos, internet, dissertaes, teses e anais de congressos, que abordavam a implantao de sistemas ERP e fatores crticos para o sucesso destas implantaes. As consultas foram realizadas, basicamente, nas bibliotecas do PUC-RJ e no Portal da CAPES, na internet; b) investigao documental, nos arquivos eletrnicos da Biblioteca da PUC-RJ, na internet, com vistas obteno de informaes sobre implantaes de ERP e gerenciamento de riscos.

PUC-Rio - Certificao Digital N 0421051/CA

1.4.2. Tratamento de dados O mtodo cientfico utilizado nesta pesquisa foi o fenomenolgico, no qual a compreenso de um evento est condicionada s convices e experincias do pesquisador, o que conforma seu carter subjetivo. Vergara (2003) afirma que este mtodo pratica a hermenutica, que busca a percepo dos significados, por meio da leitura do contexto. Na fenomenologia, os dados coletados so tratados de forma qualitativa; eles so analisados e apresentados ao leitor de uma forma mais estruturada. Foi o que ocorreu nesta dissertao. Os dados obtidos, relativos implantao de sistemas ERP e ao gerenciamento de riscos, foram analisados, compreendidos, e com isto, pde-se propr um checklist de riscos para estes tipos de projetos. No foram empregados procedimentos estatsticos. 1.5. Estrutura da dissertao A presente dissertao est dividida em cinco captulos, sendo este primeiro captulo o introdutrio.

19 O captulo 2 tem como objetivo elaborar uma reviso bibliogrfica sobre sistemas ERP e sua implantao visando identificar fatores que podem gerar insucesso nos resultados destas implantaes. O captulo 3 faz uma anlise comparativa entre mtodos de gerncia de riscos com o objetivo de identificar pontos comuns entre eles, para serem utilizados em projetos de implantao de sistemas ERP. O captulo 4 apresenta um checklist de riscos na implantao de sistemas ERP, sugerindo planos de ao no sentido de eliminar ou minimizar a probabilidade de suas ocorrncias. Para isto foram tomadas como base as causas identificadas no captulo 2. O captulo 5 apresenta as concluses tecidas pelo autor, analisa novas tendncias destes sistemas integrados e sugere propostas de estudos futuros.

PUC-Rio - Certificao Digital N 0421051/CA

2. Fatores Crticos na Implantao de Sistemas ERP

Uma das tendncias mais marcantes na rea de sistemas de informao nos ltimos anos representada pelo ERP. Estes sistemas tm como principal caracterstica o fato de serem compostos por um conjunto de subsistemas integrados, capazes de suprir as necessidades de informao e automatizar os diversos processos empresariais, desde a entrada de um pedido de um cliente, at sua expedio, incluindo o planejamento dos recursos financeiros, materiais e humanos para sua produo.

PUC-Rio - Certificao Digital N 0421051/CA

2.1. Definio de Sistemas ERP Os Sistemas Integrados de Gesto Empresariais (ERP - Enterprise Resource Planning) so sistemas transacionais que renem informaes de todas as reas de atuao da empresa, proporcionando a sua integrao (Arozo, 2003). Pode-se dizer tambm que o ERP um sistema integrado, que possibilita um fluxo de informaes nico, contnuo e consistente por toda a empresa, sob uma nica base de dados. Eles fornecem rastreamento e visibilidade global da informao de qualquer parte da empresa e de sua cadeia de suprimento, possibilitando a tomada de decises inteligentes (Chopra e Meindl, 2003). Segundo Rezende (2002), ERP so softwares que integram todas as funes empresariais na empresa, contendo bases de dados nicas, manipulando e gerando informaes operacionais e gerenciais para todas as empresa.. Para Polloni (1999), o ERP definido como uma arquitetura de software que facilita o fluxo de informaes entre todas as atividades da empresa como fabricao, logstica, finanas e recursos humanos. um sistema amplo de solues e informaes. Um banco de dados nico, operando em uma plataforma comum que interage com um conjunto integrado de aplicaes, consolidando todas as operaes do negcio em um simples ambiente computacional.

21 Para Crrea et al. (2001), estes sistemas tem a pretenso de suportar todas as necessidades de informao para a tomada de deciso gerencial de um empreendimento como um todo. Como se pode constatar nas definies acima, estes sistemas, tambm chamados no Brasil de Sistemas Integrados de Gesto Empresarial, controlam e fornecem suporte a todos os processos operacionais, produtivos, administrativos e comerciais da empresa. A abrangncia destes sistemas ampla e envolve praticamente toda a organizao. No momento que passamos a ter um banco de dados unificado e as informaes passam a ser compartilhadas, a preocupao com a acurcia dos dados deve ser redobrada. Neste sentido, todas as transaes realizadas devem ser registradas para que as consultas extradas do sistema sejam confiveis. Para se buscar esta qualidade importante fazer uma anlise do ciclo de
PUC-Rio - Certificao Digital N 0421051/CA

obteno da informao como mostrado na figura 3:

Figura 3 Relao entre ERP e desempenho (Fonte: Crrea et al, 2001)

22 a) Fatos fsicos transformam-se em dados: os fatos fsicos e suas previses futuras necessrias ao processo de tomada de deciso so informados e transformados em dados que passam a fazer parte do banco de dados do ERP. O sistema de informaes se basear apenas nestes dados e no mais nos fatos fsicos, ou seja, se os mesmos forem informados de forma falha, o suporte a decises estar comprometido (Crrea et al., 2001). b) Dados transformam-se em informaes: Em seguida feita a transformao da massa de dados recebidos para que eles sejam disponibilizados de uma forma mais adequada e til para os tomadores de deciso. Esta transformao de dados em informaes acontece atravs da utilizao de algoritmos (processos de clculo baseados em lgicas conhecidas). Desta maneira, diferentes sistemas de informaes podem, partir do mesmo conjunto de dados de entrada, produzir informaes diferentes dependendo do algoritmo utilizado. E, por conseguinte, se transformar em decises diferentes para tomada de deciso. Ou seja, falhas na
PUC-Rio - Certificao Digital N 0421051/CA

escolha do algoritmo a ser utilizado, bem como na sua parametrizao e customizao, podero ser fatais para a capacidade de o sistema de informaes atender adequadamente s necessidades de apoio tomada de deciso (Crrea et al., 2001). c) Informaes transformam-se em decises: No basta apenas o sistema de informaes disponibilizar informao de boa qualidade. O tomador de decises deve ter competncia e comprometimento para transformar esta boa informao disponibilizada numa deciso acertada (Crrea et al., 2001). d) Decises transformam-se em vantagem competitiva: Para que a organizao ganhe vantagem competitiva, a deciso adotada deve ainda ser melhor que as decises da concorrncia, para tal ela precisa ter como perspectiva uma viso estratgica da competitivade. Para que isto acontea, necessrio que todos os processos anteriores j tenham sido feitos de uma forma melhor que a da concorrncia (Crrea et al., 2001). Embora os conceitos em que se baseia um sistema ERP possam ser utilizados por empresas que queiram desenvolver internamente os seus aplicativos, o termo ERP refere-se frequentemente a pacotes de software comprados. Exemplos de sistemas ERP existentes no mercado so o Oracle

23 Application da americana Oracle, J.D.Edward e People Soft tambm da Oracle, o Magnus da brasileira Datasul, e o R/3 da alem SAP. Na atualidade, organizaes de todos os tipos, ramos de atividade e porte utilizam pacotes de Sistemas ERP (Colangelo, 2001).

2.2. Estrutura dos Sistemas ERP Davenport (1998) divide as funcionalidades dos sistemas ERP em funes internas (back-office), composta por recursos humanos, manufatura e finanas, e funes externas (front-office), composta por vendas e servios, alm da Tecnologia e do Gerenciamento da Cadeia de Suprimentos - SCM (Supply Chain Management) conforme ilustrado na figura 4:
PUC-Rio - Certificao Digital N 0421051/CA

Figura 4 Funcionalidades do Sistema ERP (Fonte: Davenport, 1998)

24 Estes mdulos esto presentes na maioria dos sistemas ERP. Alm deles, existem alguns mdulos adicionais, tais como: Gerenciamento da Qualidade, Gerenciamento de Projetos e Gerenciamento de Manuteno, entre outros. Silva e Alves (2000) descrevem na figura 5 a estrutura tpica de um sistema ERP onde se pode constatar que o fluxo de informaes trafega entre as diferentes interfaces de negcio de uma organizao.

PUC-Rio - Certificao Digital N 0421051/CA

Figura 5 Estrutura Tpica de um Sistema ERP (Fonte: Silva e Alves, 2000)

2.3. Levantamento dos benefcios dos Sistemas ERP Benefcios tangveis so aqueles que so financeiramente mensurados, por exemplo, reduo de estoques, reduo de atividades que no agregam valor, reduo de horas extras ou at mesmo de funcionrios. (Hyplito, 2000) Benefcios intangveis so aqueles considerados de suma importncia, mas que no apresentam, diretamente, uma reduo de custos ou um ganho de capital. Como exemplos tem-se a melhor satisfao dos clientes internos e externos, decorrentes da rapidez e acuracidade na gerao e disponibilizao de

25 informaes, e a maior confiabilidade na tomada de decises atravs do conhecimento das informaes corretas e em tempo, reduzindo assim riscos em decises gerenciais (Hyplito, 2000). Cada organizao, antes de pensar em implantar um sistema ERP, deve levantar e avaliar quais sero os benefcios trazidos pela sua utilizao, o que fortemente relacionado situao atual de seus processos e sistemas, assim como ao seu negcio.

2.4. Implantao dos Sistemas ERP

A implantao de um Sistema ERP composta das seguintes etapas: (1)


PUC-Rio - Certificao Digital N 0421051/CA

mapeamento e otimizao dos processos atuais, (2) seleo do Sistema ERP, (3) deciso da compra, (4) reviso e adequao dos processos operacionais nova realidade sistmica, (5) implantao, (6) treinamento e, (7) auditoria operacional e manualizao sistmica. A etapa mais crtica a implantao, porque depende de mudanas na cultura organizacional e da quantidade e complexidade dos mdulos que sero implantados (Salgueiro, 2005). Deve-se definir, inicialmente, a equipe interna da empresa que ir conduzir a implantao do ERP dentro da organizao. Ela deve ser composta de pessoas que possuam um conhecimento profundo dos processos da organizao e que possam dispor de dedicao total ao projeto. Existem quatro perfis obrigatrios na composio desta equipe. Os analistas de negcios, que conhecem bem os processos das reas que atuam e que sero impactadas pelo ERP; os especialistas em tecnologia da informao, responsveis por todo o suporte de desenvolvimento, manuteno e hardware que ser necessrio nesta implantao; os consultores com capacitao em redesenho de processos, responsveis pelo redesenho dos processos existentes para que seja possvel integr-los; e o gerente, responsvel por controlar as tarefas individuais e integradas da equipe do projeto (Hyplito, 2000).

26 2.4.1. Utilizao de consultoria externa

Em muitos casos, as organizaes optam por buscar o apoio de uma consultoria para suportar a implantao do ERP. A escolha da consultoria que fornecer o apoio na implantao tem que ser criteriosa e deve levar em contar a sua experincia neste tipo de atuao, tomando o cuidado em optar pela qualidade das implantaes j executadas por ela, ao invs de optar pela quantidade de implantaes ou por marketing e atratividade de preo. Segundo Bergamaschi (1999) os consultores so pessoas obrigatrias na implementao de sistemas ERP, devido necessidade que a organizao tem de buscar experincia no sistema e no seu tipo de negcio. Alberto (2001) tem um ponto de vista contrrio ao de Bergamaschi
PUC-Rio - Certificao Digital N 0421051/CA

quando cita os consultores especializados mas no os considera fundamentais no sucesso de uma implantao de ERP, alegando que a existncia de um alto grau de comprometimento do pessoal interno da organizao suficiente para o alcance deste sucesso. Na verdade quem define a necessidade ou no da existncia da consultoria em implantaes de sistemas ERP o porte da organizao. Empresas de grande porte que, por conseguinte, possuem inmeros processos e um alto nmero de usurios a serem treinados e a se adequarem nova cultura, tero uma utilizao mais complexa destes sistemas e a presena dos consultores especializados fundamental para transferir de uma maneira clara e transparente este tipo de expertise para as pessoas envolvidas com a implantao. J empresas de menor porte, por possurem menos processos e usurios, utilizaro o ERP de uma maneira menos complexa que as empresas de grande porte. Neste caso, uma boa capacitao do pessoal interno a ser envolvido na implantao pode sim ser suficiente para o sucesso deste projeto. A consultoria envolvida deve estar capacitada a discutir a implantao em sua plenitude e deve ter total domnio das limitaes e restries do ERP em questo, tendo a capacidade de recomendar solues alternativas.

27 2.4.2. Etapas da implantao do ERP 1) Mapeamento e otimizao de processos atuais: O passo inicial da implantao o mapeamento e otimizao dos processos atuais atravs de notaes para modelagem de processos de negcio, que tem como objetivo analisar problemas e redundncias nos seus fluxos e, por conseguinte, identificar melhorias que possam ser introduzidas. Este passo muito importante para que se evite a incorporao de prticas incorretas no fluxo unificado do ERP. Vale ressaltar que neste estgio os processos atuais devem ser completamente entendidos e todas as suas caractersticas devem ser totalmente informadas mesmo que este fato mostre que, por exemplo, uma rea no est atuando bem dentro da organizao. Qualquer omisso neste momento poder
PUC-Rio - Certificao Digital N 0421051/CA

trazer conseqncias bastante negativas quando o ERP estiver implantado e sendo utilizado.

(2) Seleo do Sistema ERP: A seleo adequada do sistema ERP a ser implantado capital para que o mesmo possa apresentar um diferencial de futuro sucesso na sua utilizao. No existe uma soluo nica que possa ser utilizada em qualquer tipo de organizao porque os problemas existentes so variados e, em muitos casos, especficos. Sendo assim, deve ser escolhido o ERP que melhor se adeque e integre as caractersticas de uma organizao. Anlises de sistemas ERP mostram considerveis diferenas relativas a funes e objetivos, o que significa a existncia de diferentes modelos, bases de suas concepes. Apesar de semelhanas conceituais de mdulos em produtos ERP, muitos elementos lgicos de seus modelos apresentam diferenas. Essas diferenas acentuam-se nos mdulos do negcio, embora muitas vezes tratem a mesma classe de problema. Essa anomalia ou inconsistncia pode ser ou pela falta do mdulo no sistema ERP ou pela sua existncia mas de forma inadequada ao funcionamento da empresa, por conter lgica divergente ao modelo do negcio em questo.

28 A grande quantidade de opes em termos de produtos, se de um lado positiva, pois atende a um variado espectro de necessidades, de outro pode confundir o usurio. No discurso, todos os provedores de solues so muito parecidos, vendendo a idia de que seus produtos se ajustam a qualquer empresa, independente do tamanho, natureza do negcio e disponibilidade de recursos para investir. Existem sistemas ERP que trabalham melhor para certos tipos de organizaes com foco em diferentes processos industriais, enquanto outros focalizam o relacionamento com pessoas e parceiros, sendo que a organizao deve se conhecer inicialmente para depois conhecer o sistema (Foti, 2003). A seleo errnea de um software pode gerar um futuro convvio incmodo e caro com este novo sistema de informao, podendo mesmo chegar a afetar o seu desempenho operacional. (Crrea et al., 2001)
PUC-Rio - Certificao Digital N 0421051/CA

Uma falha nesse sentido pode resultar no uso de processos e tecnologia totalmente inadequados cultura e operao do negcio, o que, com certeza, comprometeria o desempenho da empresa. Muitas empresas, infelizmente, na nsia de verem seus problemas resolvidos, optam por um procedimento de escolha rpida do ERP, seja pelo marketing feito pelo fornecedor, seja pelo benchmarking feito em outras organizaes, ao invs de utilizarem um critrio de avaliao que priorize a integrao com as suas caractersticas. Taurion (1999) apresenta um critrio de avaliao para seleo de um sistema ERP composto por trs aspectos: (a) funcional: seleo de critrios de funcionalidade que caracterizem as expectativas da empresa com o objetivo de avaliao do grau de aderncia do ERP ao seu modelo de gesto e aos seus processos de negcio; (b) tcnicos: anlise das caractersticas tcnicas e operacionais do ERP para alinhamento com os direcionamentos definidos pela arquitetura de TI da organizao; (c) mercadolgicos: pelo fato do mercado de ERP ser altamente competitivo, o objetivo deste aspecto o de analisar as caractersticas comerciais e mercadolgicos dos fornecedores e seus produtos, para garantir uma relao futura bastante duradoura com o fornecedor escolhido.

29 (3) Deciso da compra: Ao tomar a deciso pela utilizao de sistemas ERP as empresas esperam obter diversos benefcios. Entre eles esto a integrao entre as diversas atividades da cadeia de valor, o incremento das possibilidades de controle sobre os processos da empresa, a atualizao tecnolgica, a reduo de custos de informtica e o acesso a informaes de qualidade em tempo real para a tomada de decises sobre toda a cadeia produtiva. Por outro lado, tambm h problemas a considerar, tais como dependncia do fornecedor, tempo de aprendizagem, resistncia a mudanas, custos e prazos de implementao, entre outros (Souza e Zwicker, 2001). Wagle (1998) recomenda que a deciso de implantar o ERP s deve ser tomada com base em um fluxo de caixa positivo, pois tratam-se de projetos nos quais o perodo de retorno do investimento (payback) muito longo e o investimento muito grande.
PUC-Rio - Certificao Digital N 0421051/CA

um equvoco a organizao acreditar que poder recuperar os valores gastos com a implantao do sistema ERP to logo a aplicao seja instalada e operacionalizada. O ROI (return of investment) s comea a acontecer depois que a soluo passar a ser utilizada por algum tempo e esta utilizao comear a gerar melhorias nos processos de negcio que foram afetados pelo sistema. (4) Reviso e adequao dos processos operacionais nova realidade sistmica: O redesenho dos processos deve avaliar se existem particularidades nos processos que no sero atendidas pelo ERP. Uma vez identificados estes gaps, deve-se estudar a melhor opo: procurar alternativas no sistema para alcanar o resultado esperado, ou mesmo realizar customizaes, alterando o sistema para que ele atenda s necessidades do processo. Outro item a ser verificado durante o redesenho dos processos a necessidade de manuteno ou no de sistemas legados e, em caso positivo, as interfaces devero ser criadas e os dados migrados para o ERP. (5) Implantao: O escopo de implantao consiste em definir quais processos da empresa sero atendidos pelo ERP e que mdulos so necessrios para que isto acontea.

30 Para tal importante que a empresa conhea todas as funcionalidades destes mdulos e que consiga visualizar como eles podero atender s suas necessidades estratgicas. Existem trs estratgias para se implantar o ERP em uma organizao: (a) Substituio Total e Conjunta (Big Bang) todos os sistemas legados so substitudos ao mesmo tempo por um nico sistema ERP; (b) Estratgia de Franquias (Franchising) sistemas ERP independentes so instalados em cada unidade da organizao; (c) Mtodo "Slam-dunk" o ERP substitui um sistema legado apenas em processos-chaves, como por exemplo os processos financeiros (Padilha e Marins, 2005). Uma outra maneira de apresentar a insero de sistemas ERP nas organizaes apresentada por Colangelo (2001). Segundo ele, a entrada do ERP em uma organizao compreendido de trs etapas: pr-implantao, implantao e ps-implantao.
PUC-Rio - Certificao Digital N 0421051/CA

A etapa de pr-implantao tem como principal objetivo a tomada de deciso quanto a implementar ou no o sistema. Esta deciso deve ser baseada em um slido estudo de viabilidade que serve como base para a seleo do ERP. So definidos tambm o software, hardware e os parceiros de implantao. Na etapa de implantao, so definidos os processos de negcio e realizada a configurao do sistema ERP. O produto final dessa etapa a operao do sistema pelos usurios da organizao, atravs de novos processos de negcios suportados pelo sistema ERP. Finalmente, na etapa de ps-implantao, esperado que o sistema estabilize-se e que o desempenho da organizao cresa em funo do uso dos novos processos, para que, dessa forma, os benefcios possam ser auferidos. A implantao, entretanto, deve ser conduzida por uma metodologia que divida o projeto em vrias fases, sendo especificadas atividades e entregas em cada uma delas (Hyplito, 2000). O mercado apresenta diversas metodologias de implantao pertencentes a empresas de consultoria especializadas em implantao de sistemas ERP ou at mesmo sugeridas pelos fornecedores destes sistemas integrados (Hyplito, 2000). Duas aes so muito importantes dentro do processo de implantao de um sistema ERP: a configurao do sistema e os testes.

31 A configurao do sistema uma preparao do ambiente para implementao dos processos da organizao. Como os sistemas ERP so desenvolvidos com o intuito de atender a empresas com diferentes perfis, este o momento de definir os parmetros que iro garantir que o sistema vai estar configurado conforme as regras de negcio da organizao. Uma outra atividade importante que deve ser feita neste momento a definio dos perfis de acesso do sistema para os seus usurios (Hyplito, 2000). Aps a configurao do sistema, inicia-se a fase de testes, que pode ser dividida em trs etapas. Primeiramente ocorrem os testes individuais de cada transao do sistema que ser utilizada aps a entrada em produo. Estes testes devem ser realizados, preferencialmente, pelos usurios finais do sistema, acompanhados pelos integrantes da equipe de implantao. Esta etapa
PUC-Rio - Certificao Digital N 0421051/CA

proporciona aos usurios finais um contato mais estreito com o sistema, trazendo para a equipe do projeto detalhes operacionais importantes e muitas vezes correes nos procedimentos que sero utilizados aps a entrada em produo (Molinari, 2003). Em seguida, so realizados os testes integrados. Estes testes so de fundamental importncia, pois passam atravs de vrios mdulos do sistema, testando um processo completo, do incio ao fim. As equipes para o teste integrado devem ser compostas por pessoas de todas as reas envolvidas nos processos. justamente neste momento que muitos problemas e falhas na configurao do sistema so detectados, podendo at mesmo paralisar o teste. Isto ocorre pois campos existentes em um mdulo podem ter influncia direta nas funcionalidades de outro mdulo, o que pode levar a resultados diferentes dos esperados. A presena do usurio final tambm muito importante nesta etapa, fazendo com que ele esteja cada vez mais comprometido com a implantao do sistema (Molinari, 2003). Por ltimo, ocorre o teste de stress, quando verificado o desempenho do sistema para um volume real de transaes da empresa (Molinari, 2003).

32 (6) Treinamento: O treinamento de usurios finais uma tarefa fundamental e demorada, principalmente devido ao grande nmero de pessoas que devero ser treinadas, devendo portanto ser considerada desde o incio do projeto. O planejamento das pessoas a serem treinadas, o local onde ser realizado o treinamento, a preparao do material a ser utilizado, a definio dos instrutores (que, em muitos casos, consiste na prpria equipe de implantao da empresa) e as datas de realizao dos treinamentos so fatores que devem ser tratados com bastante antecedncia. (Hyplito, 2000) Os gastos com treinamento so considerados altos pelo fato de que os funcionrios no estaro aprendendo mais uma nova interface de software e sim um novo conjunto de processos, tendo que assumir responsabilidades diferentes das que eles estavam acostumados a conviver antes da implantao do ERP.
PUC-Rio - Certificao Digital N 0421051/CA

Devido a este fato, o tempo de treinamento mais elevado do que um treinamento comum de um software.

(7) Auditoria operacional e manualizao sistmica: A auditoria operacional deve acontecer aps a implantao do sistema ERP. Seu objetivo o de examinar as caractersticas de segurana e controle do aplicativo no intuito de determinar se est sendo mantida a integridade geral dos dados de uma organizao. Alm disto deve verificar se os dados esto sendo tratados com a acurcia desejada pelo sistema, no que tange entrada ou sada de informaes. Manuais eletrnicos devem ser utilizados como em qualquer outra ferramenta tecnolgica. A criao de um manual online com o intuito de disponibilizar aos usurios os procedimentos inerentes ao sistema garantem uma padronizao da sua utilizao. A pesquisa de satisfao online uma outra opo que ir permitir uma ampliao da satisfao dos usurios bem como um maior desenvolvimento das potencialidades do sistema.

33 2.5. Fatores crticos da implantao dos sistemas ERP

A implantao de um sistema ERP um desafio tanto tecnolgico quanto social e, por conseguinte, faz com que se torne necessrio uma viso diferenciada das inovaes tecnolgicas, dependendo de um balanceamento mais bem definido de como a organizao ser considerada como um sistema total (Kansal, 2006). Um fator a ser considerado que solues projetadas para grandes corporaes tm origens em pases de culturas diferentes. Os efeitos da globalizao contribuem com a uniformizao, porm esse processo gradativo e no chegou ainda a muitas empresas. Para as grandes empresas este fato considerado irrelevante em razo das normas e dos procedimentos internacionais que naturalmente adotam. Como softwares ERP so considerados ferramentas de padronizao, no caso delas, tais
PUC-Rio - Certificao Digital N 0421051/CA

recursos so vistos to somente como um fator positivo acrescentado (Soh et al., 2000). Por outro lado, as pequenas e mdias empresas encontram dificuldades quando tm a inteno de adquirir este tipo de sistema, em decorrncia do consumo de recursos, custos elevados e adequaes que precisariam ser feitas (Soh et al., 2000). Uma outra questo bastante complexa na implantao de um sistema ERP o seu alto custo. Neste tipo de projeto esto envolvidos custos com a compra do software, que por si s j bastante elevado, e consumo de homem/hora tanto de consultoria como dos profissionais internos, que no caso de uma implantao de longa durao bastante relevante. Existe ainda a compra dos equipamentos necessrios para a instalao do software. Alm dos custos mencionados acima, existem tambm outros custos que normalmente no so considerados como o custo do treinamento dos usurios finais, a integrao e testes, a converso dos dados e os decorrentes de um mal planejamento da utilizao dos consultores contratados (Koch, Slater e Baatz, 2006). Estima-se, por exemplo, que para cada dlar gasto com licenas de uso do software do ERP propriamente dito, sejam gastos cerca de 3 dlares adicionais em

34 servios profissionais de suporte e consultoria de implantao (Souza e Saccol, 2003). Por ser uma alternativa para implantao de sistemas integrados, o ERP faz com que os departamentos busquem a integrao de toda a empresa ao invs de se preocuparem apenas com a otimizao de suas atividades, o que gera esforos coletivos das pessoas que compem aquela organizao (Souza e Zwicker, 2001). Os sistemas ERP derivam da interligao bastante forte de processos de negcio, sistemas de software e reengenharia de processos. Diferentemente dos projetos de software que tem como foco nico o desenvolvimento de um sistema, os projetos de ERP so compostos de projetos de software e de processos de negcio e, por conseguinte, necessitam de uma colaborao mais intensa dos stakeholders envolvidos. De acordo com estimativas do Standish Group International, 90% dos
PUC-Rio - Certificao Digital N 0421051/CA

projetos de implantao de SAP/R3 terminam com atraso (Scott e Vessey, 2002). Uma explicao para este alto ndice de falhas se deve ao fato dos gerentes destes projetos no serem prudentes em identificar e gerenciar os riscos envolvidos neste tipo de implantao (Wright e Wright, 2001). As dificuldades encontradas no cumprimento destes prazos se devem : resistncia ao ERP por parte das pessoas da organizao, temendo a perda de seus empregos ou dificuldade em se adequar ao novo processo, rotatividade dos funcionrios treinados para utilizar o novo sistema ou que dominam o negcio da empresa, m qualidade dos recursos humanos internos alocados e da equipe de consultoria contratada, limitaes inerentes ao prprio produto ERP escolhido e dificuldade de integrar o ERP com outros sistemas legados existentes na organizao (Padilha e Marins, 2005). Outro problema encontrado se origina da integrao de todos os processos da organizao no ERP. Desta maneira, um problema de uma rea pode se alastrar com rapidez para outras, com o risco de afetar toda a organizao (Padilha e Marins, 2005). Em uma pesquisa da FGV realizada com 28 empresas com faturamento acima de R$ 500 milhes, constatou-se que a deciso sobre a adoo de ERP foi tomada de forma apressada, alimentada pela presso da concorrncia ou de seus

35 acionistas, na grande maioria das entrevistadas. Os dados levantados mostraram que 90% das empresas adotaram o ERP para acompanhar a tendncia de mercado e 45% devido a presso dos seus acionistas. Estas empresas no perceberam a amplitude e a profundidade das questes envolvidas com a implantao de um projeto desta natureza e fizeram uma reengenharia dos seus processos de uma maneira superficial, preocupando-se apenas com a automatizao (cerca de 66%). Este fato gerou, como conseqncia, o no atendimento das necessidades especficas dos negcios e, em alguns casos, perda de algumas destas funes essenciais (Wood Jr., 1999). Uma pesquisa realizada em 2003, pelo Centro de Estudos em Logstica/ COPPEAD, acerca do estgio das implantaes de softwares de Supply Chain Management (SCM) em treze empresas brasileiras teve, como um de seus objetivos, identificar aspectos que poderiam influenciar negativamente o sucesso
PUC-Rio - Certificao Digital N 0421051/CA

destas implantaes (Arozo, 2003). Foi solicitado a cada empresa que ordenasse os cinco principais problemas encontrados durante a implantao do sistema. Os pesos foram atribudos segundo a ordem de escolha. Obteve-se uma pontuao a partir do produto entre o nmero de citaes de cada problema e o peso a ele atribudo. Na tabela 1 mostrada a distribuio dos pesos. A pontuao mxima seria de 65 pontos, caso um mesmo problema tivesse sido escolhido pelas 13 empresas como sendo o mais grave.
ORDEM DE ESCOLHA 1 2 3 4 5 PESO ATRIBUDO 5 4 3 2 1

Tabela 1 Pesos atribudos na pesquisa Utilizao de softwares de Supply Chain Management em empresas brasileiras da COPPEAD (Fonte: Arozo, 2003)

36 importante considerar que, nesta pesquisa, no foram pesquisados isoladamente apenas a implantao de sistemas ERP, mas tambm outros softwares de SCM. A figura 6 mostra um grfico com os principais problemas encontrados ao longo do processo de implantao, segundo os respondentes desta pesquisa:

PUC-Rio - Certificao Digital N 0421051/CA

Figura 6 Principais problemas encontrados durante a implantao do ERP (Fonte: Arozo, 2003)

Como podemos notar, segundo a pesquisa, os problemas culturais e a remodelagem dos processos so os maiores ofensores no que tange ao sucesso de implantaes deste tipo de sistema. Em relao aos problemas culturais, que obteve a maior pontuao, foram identificadas duas barreiras: a resistncia mudana com alegaes de que o novo sistema no atende s necessidades, gerando uma no utilizao da ferramenta e uma sensao de perda do poder originada pela substituio de atividades manuais por funcionalidades do novo sistema (Arozo, 2003). Os problemas culturais dentro de uma organizao transcedem a implantao de um sistema ERP. Eles aparecem sempre que mudanas so

37 sinalizadas em algum processo e se maximiza se este processo for utilizado por um volume grande de funcionrios. Em relao remodelagem dos processos foi identificado que muitas vezes ela no contemplada nas implantaes. Este fato faz com que as metodologias de anlise embutidas nos softwares de SCM no se encaixem nos processos anteriores existentes na organizao (Arozo, 2003). No se preocupar com a remodelagem dos processos existentes antes de uma automatizao desta natureza preocupante, pois como o sistema tem o objetivo de suportar em sua base de dados todas as informaes operacionais de uma organizao, processos mal definidos ou com problemas no corrigidos tero seus problemas maximizados aps o ERP implantado. importante que se faa, quase sempre, um estudo e adequao dos processos que sero suportados pelo novo software. Outros aspectos considerados pela pesquisa foram a padronizao e
PUC-Rio - Certificao Digital N 0421051/CA

obteno dos dados, o treinamento e comunicao, a qualificao do pessoal contratado, a qualificao do pessoal da empresa, a falta de apoio da direo, a coordenao dos trabalhos e uma estrutura organizacional inadequada. Para garantir um banco de dados consistente e que permita a tomada de deciso importante que se eliminem as redundncias dos dados e que os mesmos sejam armazenados de uma maneira padronizada. O treinamento deve ser feito com base nos processos. Se ele for focado apenas no ensino da utilizao da ferramenta, no ser efetivo e causar transtornos quando da utilizao do sistema. Um outro ponto bastante crtico no que tange ao treinamento a rotatividade de pessoal. Por ser um sistema que apresenta muitas complexidades, sua implantao deve ser feita por profissionais que conheam no somente o negcio da empresa, como tambm a soluo escolhida. Geralmente as empresas optam pelo apoio de uma consultoria especializada. importante que se tenha confiana no fornecedor contratado. Ele deve possuir profissionais que tenham experincia na soluo utilizada e uma metodologia bem definida de implantao. Este fato gerador de um outro problema, pois fornecedores de ERP possuem maneiras distintas de conduzir o processo de implantao do sistema (Souza e Zwicker, 2001).

38 A montagem da equipe de trabalho para este tipo de projeto deve contemplar os profissionais mais qualificados e conhecedores dos negcios da empresa. importante tambm que se crie uma integrao bem forte destes profissionais com os consultores contratados. capital o apoio da direo, que deve ser a responsvel por transmitir, desde o incio da implantao, as vantagens que sero obtidas com o ERP e por tomar as decises estratgicas necessrias para uma boa coordenao do andamento do projeto. Cada projeto de implantao de um ERP apresenta caractersticas prprias que so definidas pelos processos e estratgias da organizao onde ele ser implantado. Apesar destas diferenas, as implantaes apresentam em geral os mesmos tipos de dificuldades (Hyplito, 2000). Ao tomar a deciso pela utilizao de sistemas ERP, as empresas esperam
PUC-Rio - Certificao Digital N 0421051/CA

obter diversos benefcios (Souza e Saccoll, 2003). Entre os benefcios apontados pelas empresas fornecedoras esto a integrao, o incremento das possibilidades de controle sobre os processos da empresa, a atualizao tecnolgica, a reduo de custos de informtica e o acesso a informaes de qualidade em tempo real para a tomada de decises sobre toda a cadeia produtiva. Por outro lado, tambm h problemas a considerar. A tabela 2 relaciona dificuldades e benefcios decorrentes das caractersticas desses sistemas.

Caractersticas So Pacotes comerciais

Benefcios Reduo de custos de informtica; Foco na atividade principal da empresa; Reduo de backlog de aplicaes; Atualizao tecnolgica permanente, por conta do fornecedor. Difunde conhecimento sobre as melhores prticas; Facilita a reengenharia de

Problemas Dependncia do fornecedor; Empresa no detm o conhecimento sobre o pacote.

Usam modelos de processos

Necessidade de adequao do pacote empresa; Necessidade de alterar

39
processos; So sistemas integrados Impe padres. Reduo do trabalho e inconsistncias; Reduo da mo-de-obra relacionada a processos de integrao de dados; Maior controle sobre a operao da empresa; Eliminao de interfaces entre sistemas isolados; Melhoria na qualidade da informao; Contribuio para a gesto integrada; Otimizao global dos processos da empresa. processos empresariais; Alimenta a resistncia mudana. Mudana cultural da viso departamental para a de processos; Maior complexidade de gesto da implementao; Maior dificuldade na atualizao dos sistemas, pois exige acordo entre vrios departamentos; Um mdulo no disponvel pode interromper o funcionamento dos demais; Alimenta a resistncia mudana. Mudana cultural da viso de dono da informao para a de responsvel pela informao. Mudana cultural para uma viso de disseminao de informaes dos departamentos por toda a empresa; Alimenta a resistncia mudana. Dependncia de um nico fornecedor; Se o sistema falhar, toda a empresa pode parar.


PUC-Rio - Certificao Digital N 0421051/CA

Usam bancos de dados corporativos

Padronizao de informaes e conceitos; Eliminao de discrepncias entre informaes de diferentes departamentos; Melhoria na qualidade da informao; Acesso a informaes para toda a empresa.

Possuem grande abrangncia funcional Eliminao da manuteno de mltiplos sistemas; Padronizao de procedimentos; Reduo de custos de treinamento; Interao com um nico fornecedor.

Tabela 2 - Benefcios e problemas dos sistemas ERP. (fonte: Souza e Saccol, 2003).

40 Algumas vantagens podem ser destacadas do quadro acima, como a possibilidade de integrao das diversas reas de uma organizao, a atualizao permanente da base tecnolgica por conta do fornecedor e a reduo dos custos de informtica, relacionada sobretudo terceirizao do desenvolvimento de aplicaes. Entretanto esta integrao, mesmo sendo uma vantagem no que tange padronizao do processo de negcio, traz como conseqncias novos desafios na forma de trabalhar da organizao. Ainda em relao ao processo de integrao, existe a possibilidade de resistncia por parte dos usurios, pois a responsabilidade pela gerao da informao para outros setores da organizao encarada como carga adicional de trabalho. Alm disso, as dependncias de informaes de uma rea para outra faz com que seus processos de trabalho sejam mais transparentes para as demais, gerando tambm possveis resistncias. Esta maior transparncia deve-se no somente dependncia de informaes interdepartamentais, mas tambm pela
PUC-Rio - Certificao Digital N 0421051/CA

padronizao de alguns processos, como por exemplo fluxos de aprovaes. Dessa forma, de suma importncia a preparao dos usurios na gesto da mudana associada a projetos de implantao de sistemas ERP. Este um aspecto crucial para este estudo, visto que estaremos avaliando a aceitao de um sistema ERP aps sua implementao, e que as resistncias dos usurios tendem a ser maiores nesta fase, se no forem devidamente tratadas antes da implementao. importante para que a implantao seja bem sucedida que se obtenha o compromisso daqueles que podem direcionar a mudana. Este compromisso de fundamental importncia na identificao e combate de resistncias ao novo sistema. Na tabela 2, verificamos que vantagens relacionadas reduo de custos devem-se, em parte, ao compartilhamento dos dados. Nesse caso, a eliminao de bases de dados redundantes, prtica comum em sistemas legados, geralmente resulta em diminuio no custo de manuteno de dados. Alm disso, reduz-se tambm a falta de consistncia entre informaes e a alimentao repetida de informaes em diferentes bases de dados (Souza e Saccol, 2003). Assim, aumenta-se a qualidade da informao, e reduz-se a necessidade de esforo de integrao dos processos da organizao.

41 Em resumo, a tabela 2 sugere que cada benefcio traz consigo riscos associados. importante salientar que cada empresa reage de forma diferenciada a esses aspectos. Algumas empresas fracassaram na implementao de sistemas ERP porque gastaram mais do que previram inicialmente. Outras, por exemplo, no prepararam seus funcionrios devidamente para as mudanas que estavam por vir. Portanto fica evidente que cada organizao deve avaliar e decidir se vale a pena abraar esses benefcios e riscos, tendo em vista impacto que sistemas podem representar, em termos de reduo de custos, qualidade e satisfao dos clientes internos, no seu caso especfico (Davenport, 2000). 2.6. Tendncias do ERP: ERP II e BoB No cenrio atual, um outro fator importante a transformao destes sistemas em ferramentas de gesto e suporte s decises quando vemos a sua
PUC-Rio - Certificao Digital N 0421051/CA

integrao no s com o gerenciamento da cadeia de fornecedores (Supply Chain Management SCM) como tambm com sistemas de gerenciamento de relacionamento com o cliente (Customer Relationship Management CRM) e com BI (Business Intelligence BI). Diante destes fatos, esto surgindo novos conceitos na forma de fazer negcio em funo das transformaes competitivas em um mundo globalizado devido necessidade cada vez mais crescente em se reduzir custos e promover a diferenciao dos produtos de uma organizao (Souza e Saccol, 2003). Sendo assim, as empresas esto se vendo foradas a rever seus processos e sua forma de trabalho. Essa necessidade est promovendo fortes mudanas nos sistemas de informao com o objetivo de suportar essa nova forma de fazer negcio. Por conseguinte, fornecedores de Sistemas ERP esto tendo que mudar o foco de seus produtos e servios, inicialmente voltado para o gerenciamento de recursos internos, para que passem a contemplar tambm o ambiente externo da empresa e processos decisrios mais estratgicos. Dessa forma, surge a segunda onda de sistemas ERP, batizada pelo Gartner Group como ERP II. Neste contexto foram adicionadas ao ERP novas capacidades de negcio como, por exemplo, o Customer Relationship Management-CRM e o Business Intelligence-BI.

42 O ERP II tem como principal caracterstica, alm da integrao dos sistemas, a nfase na colaborao comercial que utiliza a Internet. Alm de desenvolver produtos e formas de comercializao especficas, ele permite ainda o incremento do fluxo de informaes entre as corporaes interligando sistemas entre elas, mais notadamente mdulos do ERP. Por meio do conceito ERP II, o papel dos sistemas de gesto amplificado, o que mostra a evoluo contnua da famlia de sistemas. Ele inclui software de CRM (Customer Relationship Management), que significa gerenciamento do relacionamento com os clientes; EPM (Enterprise Performance Management), que o gerenciamento do desempenho da empresa e que engloba ferramentas como Data Warehouse (transformar dados em informao para tomada de deciso) e Inteligncia de Negcios. O ERP II ainda engloba uma soluo de Portal, que um ambiente web personalizvel.
PUC-Rio - Certificao Digital N 0421051/CA

A filosofia presente no ERP II possvel graas disseminao em larga escala da Internet, principal estrada para que o envio e o recebimento de dados acontea na dinmica do tempo real. A idia de reunir empresas de um mesmo setor um bom exemplo na Web so os chamados marketplaces para transacionar, dividir insumos e informaes a soma disto, e s possvel graas ao controle e a integrao dos sistemas de gesto com outros softwares. Deve-se comentar que na evoluo dos Sistemas de Tecnologia de Informao, aps a consolidao do e-business, a nova onda se refere Colaborao nas Cadeias de Suprimentos. Essa tendncia se caracteriza pelo planejamento colaborativo entre os vrios elos que compem uma cadeia, a integrao entre diversas cadeias, mesmo concorrentes, de modo que sejam melhoradas a velocidade, agilidade e a flexibilidade para o atendimento ao cliente e para a tomada de deciso. Quanto implantao de sistemas ERP, deve-se comentar, ainda, que, devido s crticas aqui citadas sobre implementaes tradicionais de ERP, tal como a sua inflexibilidade em no atender requisitos especficos de determinadas empresas, tm-se proposto como alternativa s empresas que desejam investir em Tecnologia de Informao o uso da Estratgia da Melhor Criao BoB (Best of Breed Strategy).

43 Esta estratgia consiste na integrao de softwares padres de vrios fornecedores e/ou do prprio cliente, ao invs de se adotar uma soluo de um nico fornecedor. Sobre esta ltima abordagem, Light et al. (2001) apresentam uma interessante anlise comparativa entre utilizar um ERP (de um nico fornecedor) ou optar pela estratgia de BoB. Estes autores ilustram, com um estudo de caso, as diferenas entre uma alternativa e outra com respeito a: complexidade de implementao, nveis de funcionalidade, potencial para o alinhamento de processos de negcios e os requisitos de manuteno. No ser considerada nesta dissertao a anlise dos riscos inerentes a projetos de implantao de sistemas ERP II, ficando como sugesto futura a incorporao destes riscos na lista de riscos criada com base na implantao de sistemas ERP.
PUC-Rio - Certificao Digital N 0421051/CA

Como pudemos ver neste captulo, existem muitos problemas existentes em implantaes de projetos de sistemas ERP. Estes problemas, se no forem controlados e contornados, iro acarretar, alm do prprio insucesso da implantao, em mais gastos para as organizaes. Este fato faz com que se torne necessrio esforos no sentido de se gerenciar os riscos deste tipo de projeto. Este trabalho, com a sua lista de riscos, torna-se um importante alavancador destes esforos.

3. Metodologias de Gerenciamento de Riscos


A complexidade que caracteriza a implantao de um sistema ERP uma das maiores preocupaes das organizaes que pretendem desenvolver projetos desta natureza. Como vimos no captulo anterior, existem muitos fatores que influenciam de forma negativa no objetivo de se conseguir uma implantao com sucesso de um sistema ERP. Fatores estes que podem ser evitados ou que podem ter seus impactos minimizados atravs de efetivo levantamento dos riscos inerentes a este tipo de projeto. Um procedimento vital no sentido de se evitar desvios nos objetivos do gerenciamento de um projeto de implantao de um sistema ERP, e que crucial para o sucesso deste projeto, o gerenciamento de riscos (Cleland e Ireland,
PUC-Rio - Certificao Digital N 0421051/CA

2000). Embora alguns destes desvios no possam ser previstos, outros, se identificados a tempo, podem ser controlados atravs de aes de preveno sobre a sua atuao. O gerenciamento de riscos adiciona ao gerenciamento de projetos uma abordagem estruturada para identificao e anlise de riscos no incio do planejamento do projeto e no decorrer das fases do desenvolvimento do software. (Gusmo e Moura, 2004)

3.1. Definio de risco A palavra riscos deriva do italiano antigo resicare que significa ousar. Neste sentido, risco uma opo e no um destino. Correr riscos faz parte da histria antiga (Bernstein, 1997). Nas ltimas dcadas a palavra riscos tem sido utilizada nos mais diversos objetivos tais como: riscos de negcios, riscos sociais, riscos econmicos, riscos de segurana, riscos polticos, entre outros. No que tange a gerenciamento de projetos, a sua aplicao se volta para os seus impactos no sucesso da execuo dos projetos, como podemos ver nas

45 definies seguintes, dadas pelas maiores instituies de gerenciamento de projetos do mundo: Risco um evento ou condio incerta que, se ocorrer, tem um efeito positivo ou negativo sobre ao menos um dos objetivos do projeto. (PMI, 2004). Segundo a Associao Brasileira de Gerenciamento de Projetos - ABGP, representante oficial do International Project Management Association - IPMA no Brasil, riscos so acontecimentos com impacto negativo (prejuzos ou danos) ao sucesso geral do projeto, ou so eventos que podem causar prejuzos que no puderam ser previstos. (Santos e Carvalho, 2005). Segundo a Association for Project Management, risco a combinao da probabilidade ou frequncia de ocorrncia de uma ameaa ou oportunidade definida e a magnitude das consequncias de sua ocorrncia (APM, 2006). Analisando as definies acima, podemos concluir que os riscos so condies ou circunstncias futuras que podero proporcionar um impacto
PUC-Rio - Certificao Digital N 0421051/CA

favorvel ou desfavorvel ao empreendimento. O risco tambm algo que est relacionado escolha, no ao acaso, pois decorre da incerteza inerente ao conjunto de possveis conseqncias (ganhos e perdas) que resultam de decises tomadas diariamente pelas organizaes.

3.2. Definio de gerenciamento de riscos Segundo o Project Management Institute - PMI, o gerenciamento de riscos um processo sistemtico que tem por objetivo identificar, analisar e responder aos riscos de um projeto. Seu objetivo o de diminuir ou at eliminar a probabilidade e o impacto de um evento negativo, ou seja adverso ao projeto, acontecer. Por outro lado, ele tambm se preocupa em aumentar a probabilidade e impacto de um evento positivo, ou seja, benfico para o projeto, acontecer (PMI, 2004). Segundo a ABGP, a gesto de riscos aplicadas em projetos consiste nos processos de identificao, classificao e quantificao dos riscos, bem como no gerenciamento das aes de resposta a todos riscos do projeto. (Santos e Carvalho, 2005).

46 uma aplicao sistemtica de polticas, procedimentos, mtodos e prticas para as tarefas de identificar, analisar, avaliar, tratar e monitorar os riscos. o processo no qual as decises so tomadas para aceitar riscos conhecidos e avaliados e/ou para a implementao de aes para reduzir as consequncias ou a probabilidade de ocorrncia destes riscos. (APM, 2006). O gerenciamento de riscos uma forma organizada de identificar e medir os riscos de desenvolver, selecionar e gerenciar as opes para o seu controle. (Kerzner, 2006). Analisando as definies acima, podemos concluir que o gerenciamento de riscos justamente um conjunto de processos proativos que so acionados para identificar e analisar riscos e executar aes para eliminar ou minimizar os problemas antes que ocorram e, conseqentemente, aumentar a probabilidade de sucesso dos projetos. Por isto importante que exista uma metodologia que organize estes
PUC-Rio - Certificao Digital N 0421051/CA

passos com o objetivo de se alcanar um efetivo controle dos riscos inerentes a um projeto. Mesmo a mais simples deciso gerencial ou de negcio envolve riscos em suas aes. Pelo fato dos projetos necessitarem de tomadas de deciso durante praticamente todo o seu ciclo de vida, gerenciar riscos torna-se um fator crtico de sucesso deste tipo de empreendimento (Pritchard, 2001). A seguir ser feita a anlise de algumas metodologias de riscos e ao final ser feito um estudo comparativo, no sentido de verificar suas semelhanas. As metodologias analisadas sero a de Boehm, a do Rational Unified Process RUP, a do Capability Maturity Model CMMI e a do PMI.

3.3. O gerenciamento de riscos na abordagem de Boehm Barry Boehm, ao apresentar o seu modelo em espiral (figura 7) no final dos anos 80, foi o pioneiro na incluso da gerncia de riscos no ciclo de vida de desenvolvimento de software. Neste modelo, a anlise dos riscos do projeto feita a cada iterao (Machado, 2002). Ele critica expressamente o processo de desenvolvimento clssico (em cascata), afirmando que estes modelos sequenciais fazem com que os

47 desenvolvedores acabem prometendo elaborar mais funcionalidades do software do que deveriam, sem antes entender quais so as implicaes resultantes dos riscos envolvidos (Boehm, 1991).

PUC-Rio - Certificao Digital N 0421051/CA

Figura 7 Modelo de desenvolvimento em espiral de Barry Boehm (Fonte: Roque, 1998)

O objetivo do modelo espiral (figura 7) o de prover um metamodelo que possa acomodar diversos processos especficos. Isto significa que podemos encaixar, neste modelo, as principais caractersticas de outros modelos, adaptando-os a necessidades especficas de desenvolvedores ou a particularidades do software a ser desenvolvido (Matoso, 2004). Sua principal inovao guiar o processo de desenvolvimento gerado a partir deste metamodelo, com base em anlise de riscos e um planejamento que realizado durante toda a evoluo do desenvolvimento (Matoso, 2004). O modelo espiral descreve um fluxo de atividades cclico e evolutivo constitudo de quatro estgios. No estgio 1 devem ser determinados os objetivos, as solues alternativas e as restries. No estgio 2, por sua vez, devem ser analisados os riscos das decises tomadas no estgio anterior atravs da

48 construo de prottipos ou simulaes do software. O estgio 3 consiste nas atividades da fase de construo que incluem a especificao da soluo, sua codificao e posterior verificao. No estgio 4 feita a reviso das etapas anteriores e o planejamento da prxima fase. Neste planejamento, dependendo dos resultados obtidos nos estgios anteriores - decises, anlise de riscos e verificao - pode-se optar por seguir o desenvolvimento em outro tipo de modelo (Matoso, 2004). Segundo Boehm (1991), a identificao e respectivas aes com o risco no incio do desenvolvimento, diminuem os custos e ajudam a prevenir os impactos negativos que podem ser causados por ele. A metodologia de gerenciamento de riscos desenvolvida por Boehm, com base no modelo espiral apresentado, composta por duas grandes fases: Avaliao de Riscos (Identificao, Anlise e Priorizao de riscos) e Controle
PUC-Rio - Certificao Digital N 0421051/CA

dos Riscos (Plano de gerenciamento de riscos, Resoluo dos riscos e Monitoramento dos riscos), conforme pode ser visto na figura 8:

Figura 8 Processo de Gerncia de Riscos proposto por Boehm (Fonte: Boehm, 1991)

Como podemos observar, cada uma das fases composta por trs atividades secundrias, que, por sua vez, possuem tcnicas que as auxiliam a

49 alcanar os seus objetivos. A seguir sero apresentados os objetivos das atividades que compem a metodologia. Avaliao de Riscos: A identificao de riscos tem por objetivo a criao de uma lista com os riscos identificados que possam vir a impactar o sucesso do projeto. A anlise de riscos tem por objetivo executar a avaliao da probabilidade de ocorrncia e do tamanho do impacto que pode ser causado por cada um dos riscos identificados, com o objetivo de compr os seus graus de criticidades. A priorizao de riscos tem por objetivo criar um ranking priorizado dos riscos identificados e analisados de acordo com o seu grau de criticidade. Controle de Riscos: O planejamento da gerncia de riscos tem por objetivo a elaborao de um
PUC-Rio - Certificao Digital N 0421051/CA

planejamento de como devero ser gerenciados os riscos identificados qualificados e priorizados para que fiquem sob controle. A resoluo de riscos tem por objetivo a definio de aes para eliminar a probabilidade de ocorrncia de um risco ou minimizar os seus impactos para os objetivos do projeto. A monitorao de riscos tem por objetivo o monitoramento do progresso do projeto tendo por base o controle efetivo dos riscos do projeto atravs de aes corretivas, sempre que for necessrio. 3.4. O gerenciamento de riscos na abordagem do RUP O RUP um processo de engenharia de software que fornece uma abordagem disciplinada no que tange a assumir as responsabilidades e tarefas necessrias dentro do desenvolvimento organizado de um software. Seu objetivo o de assegurar que o produto gerado seja de alta qualidade, e que tenha sido desenvolvido dentro do cronograma e do oramento planejado, gerando assim uma satisfao das necessidades dos usurios finais (Kruchten, 2003). O RUP tem como base seis boas prticas de desenvolvimento de software: O desenvolvimento iterativo do software, onde os requisitos so implementados

50 gradativamente, o que faz com que os riscos sejam identificados e controlados prematuramente; o gerenciamento dos requisitos, que permite um maior controle sobre as necessidades dos stakeholders; a utilizao de uma arquitetura baseada em componentes, que gera a possibilidade do desenvolvimento isolado de partes do software, trazendo como benefcio o desenvolvimento de componentes genricos; uma modelagem visual, onde os modelos so simplificaes da realidade e com isto facilitam o entendimento do sistema pelos stakeholders; uma verificao contnua da qualidade, onde os testes so realizados ao final de cada iterao; e o estabelecimento de um processo de gerenciamento de mudanas, que garante que os stakeholders estejam sincronizados com as definies e eventuais mudanas que aconteam no sistema (Kruchten, 2003), O ciclo de vida proposto pelo RUP composto de quatro fases seqenciais que possuem atividades e objetivos especficos como pode ser visto na figura 9:
PUC-Rio - Certificao Digital N 0421051/CA

Figura 9 Fases do RUP (Traduzido da Fonte: Rational Software Corporation, 2003)

A fase de concepo tem como objetivo a definio do escopo do projeto e a posterior obteno do aceite de todos os stakeholders, com o intuito de garantir que suas expectativas sero atendidas. O primeiro marco do ciclo de vida do RUP chamado de Marco de Objetivos do Ciclo de Vida (Lifecycle Objectives LCO) alcanado quando existir a concordncia de todos os stakeholders sobre os requisitos levantados para o desenvolvimento da soluo e, com isto, esta fase finalizada (Rational Software Corporation, 2003). A fase de elaborao tem como objetivo a construo de uma arquitetura consistente e estvel para abrigar o software. A implementao dos requisitos mais crticos vai contribuir para que este fato se torne possvel. O segundo marco do ciclo de vida do RUP chamado de Marco de Arquitetura

51 (Lifecycle Architecture LCA) alcanado quando este objetivo tiver sido satisfeito e, com isto, esta fase finalizada (Rational Software Corporation, 2003). A fase de construo tem como objetivo finalizar o desenvolvimento do software atravs da implementao dos requisitos restantes dentro da arquitetura criada na fase anterior. O terceiro marco do ciclo de vida chamado de Marco de Capacidade Inicial de Operao (Initial Operational Capability IOC) alcanado quando o software estiver completo e suficientemente estvel para entrar em operao e, com isto, esta fase finalizada (Rational Software Corporation, 2003). A fase de transio tem como objetivo a garantia da disponibilizao do software para os seus usurios finais atravs de atividades como testes finais, documentao, homologao e treinamento. O quarto marco do ciclo de vida do RUP, que o seu marco final, chamado de Marco de Capacidade Inicial de Operao (Initial Operational Capability IOC) alcanado quando todos os
PUC-Rio - Certificao Digital N 0421051/CA

critrios de aceitao do software definidos pelos usurios finais tiverem sido satisfeitos e, com isto, esta fase finalizada (Rational Software Corporation, 2003). Esta a estrutura dinmica do RUP (composta por fases) que representa a dimenso do tempo no processo. Porm, ele tambm possui uma estrutura esttica que descreve como os elementos do processo so agrupados em disciplinas, que so um conjunto de atividades relacionadas maior rea de interesse dentro do processo. A figura 10 mostra a estrutura esttica e dinmica do RUP:

Figura 10 Estrutura dinmica e esttica do RUP (Traduzido da Fonte: Rational Software Corporation, 2003)

52 A disciplina Modelagem de Negcios abrange todas as tcnicas de modelagem que podem ser utilizadas para modelar visualmente o negcio. A disciplina Requisitos tem a finalidade de definir o que o sistema deve fazer. A disciplina Anlise e Design objetiva mostrar como os casos de uso do sistema sero realizados na implementao. A disciplina Implementao tem a funo de implementar e realizar teste do desenvolvedor em componentes de software. A disciplina Teste tem a funo de integrar e testar o sistema. J o objetivo da disciplina Implantao assegurar uma transio bem-sucedida do sistema, desenvolvido para seus usurios. A disciplina Gerenciamento de Configurao e Mudana, por sua vez, se preocupa em restringir e gerenciar alteraes nos itens de configurao do sistema. A disciplina Gerenciamento de Projeto tem a finalidade de fornecer uma estrutura para gerenciamento de projeto de software, fornecendo um guia prtico para planejamento, recrutamento, execuo e monitoramento de projeto e uma
PUC-Rio - Certificao Digital N 0421051/CA

estrutura para o gerenciamento de risco. Finalmente, a disciplina Ambiente cuida de definir e gerenciar o ambiente no qual o sistema est sendo desenvolvido (Rational Software Corporation, 2003). A figura 11 mostra todas as atividades que compem a disciplina Gerenciamento de Projeto:

Figura 11 RUP: Disciplina Gerenciamento de Projeto: Viso Geral da Atividade (Fonte: Rational Software Corporation 2003)

53 A gerncia de riscos no RUP utilizada em suas fases de desenvolvimento do produto, de forma sistemtica: Concepo nfase nos riscos dos requisitos de negcio; Elaborao foco nos riscos tcnicos de definio da arquitetura do software; Construo tratamento dos riscos lgicos envolvidos na construo do produto; Transio os riscos funcionais de utilizao do software (Kruchten, 2003). O papel envolvido com o gerenciamento de riscos no RUP o do gerente do projeto, que executa as atividades Desenvolver o Plano de Gerenciamento de Riscos, Identificar e Avaliar Riscos, e Monitorar o Status do Projeto, que tm como sada os artefatos Plano de Gerenciamento de Riscos e Lista de Risco, que sero entrada para vrias atividades desta disciplina. A atividade Desenvolver o Plano de Gerenciamento de Riscos tem o objetivo de criar um plano documentado para identificar, analisar e priorizar riscos bem como identificar as estratgias de gerenciamento para os riscos mais
PUC-Rio - Certificao Digital N 0421051/CA

significativos do projeto. Este plano documentado o artefato Plano de Gerenciamento de Riscos. A atividade Identificar e Avaliar Riscos executa, com base no Plano de Gerenciamento de Riscos, a identificao, anlise e priorizao dos riscos do projeto bem como a determinao das estratgias mais apropriadas para gerenciar estes riscos. Esta atividade tambm reavalia os riscos no final de cada iterao. O artefato Lista de Riscos a sada desta atividade, criada no incio do projeto e atualizada nas demais atividades da disciplina. A atividade Monitorar Status do Projeto captura e avalia o status atual do projeto, utilizando os artefatos Plano de Gerenciamento de Risco e Lista de Risco como entradas e, dependendo das anlises deste status, atualiza a Lista de Riscos. 3.5. O gerenciamento de riscos na abordagem do CMMI A Software Engineering Institute (SEI), que faz parte da Carnegie Mellon University, um centro de pesquisa e desenvolvimento criado em 1984 e patrocinado pelo Departamento de Defesa dos Estados Unidos da Amrica, que prov uma prtica avanada de engenharia de software qualificando graus de qualidade de software (SEI, 2006).

54 Em 1987, a SEI criou um modelo chamado CMM (Capability Maturity Model), composto por documentos de maturidade de processos e por um questionrio de maturidade, que tinha por objetivo medir a qualidade dos processos de uma organizao e classific-los por nveis de maturidade (SEI, 2006). Em 1991, o SEI evoluiu a estrutura de maturidade de processo para o SWCMM (Capability Maturity Model for Software) que foi o primeiro modelo desenvolvido na rea de maturidade e capacidade organizacional, na rea de desenvolvimento de software (SEI, 2006). partir da outros modelos foram criados para cobrir outras reas de interesse da organizao como o SA-CMM (Capability Maturity Model for Software Acquisition) para processos de aquisio de software; o SE-CMM (Capability Maturity Model for System Engineering) para processos de engenharia de sistemas; o IPD-CMM (Capability Maturity Model for Integrated Product
PUC-Rio - Certificao Digital N 0421051/CA

Development) para processos de suporte ao produto e o P-CMM (Capability Maturity Model for People) para processos de administrao de recursos humanos necessrios para o desenvolvimento de software. Com o objetivo de eliminar as inconsistncias e diminuir as redundncias existentes, alm de criar uma terminologia comum, entre todos os modelos, a SEI, em 2000 os unificou lanando o CMMI (Capability Maturity Model Integration). O CMMI oferece uma avaliao mais efetiva e consequente melhoria dos processos da organizao atravs de uma viso integrada. Alm disto, os custos desta avaliao so reduzidos e oferece um novo meio de representao da informao de disciplinas especficas, atravs do uso de modelos de melhoria testados (Gusmo e Moura, 2004). Existem duas formas de representao dos modelos CMMI: a contnua (continuous) e a por estgios (staged), esta segunda derivada do SW-CMM. A representao contnua permite que a organizao escolha a ordem das melhorias de acordo com os objetivos de negcio ou ainda pelas suas reas de risco e deve ser utilizada quando a organizao conhece os processos que devem ser melhorados. A representao por estgios prov uma reconhecida seqncia de melhorias, iniciando pelas prticas gerenciais bsicas e avana gradativamente por um caminho predefinido de sucessveis nveis, onde cada nvel serve de base para

55 o prximo. Esta representao deve ser utilizada quando a organizao no sabe quais so os processos que devem ser melhorados (SEI, 2006). A representao por estgios, que trata do nvel de maturidade da organizao como um todo, possui cinco nveis de maturidade (Inicial, Gerenciado, Definido, Gerenciado Quantitativamente e Aprimorando). Cada nvel possui diversas reas de processo. A representao contnua, que trata do nvel de maturidade da organizao como um todo, possui seis nveis de maturidade para dimenso da capacitao (Incompleto, Executado, Gerenciado, Definido, Gerenciado Quantitativamente e Aprimorando).

PUC-Rio - Certificao Digital N 0421051/CA

Figura 12 Estrutura do CMMI

Conforme descrito na figura 12, cada nvel de maturidade composto por diversas reas de processos (process area PA) que so agrupamentos de prticas em uma rea especfica. No CMMI, existem 25 reas de processos que so comuns tanto para a representao por estgio como para a representao contnua. As reas de processos so compostas por objetivos especficos (specific goals, SGs) que identificam caractersticas nicas que descrevem o que precisa ser

56 implementado para satisfazer uma rea de processo; e objetivos genricos (generic goals, GGs) que so objetivos que aparecem em vrias reas de processo. Os objetivos especficos possuem prticas especficas (specific practice, SPs) que so atividades consideradas essenciais para que um objetivo especfico seja alcanado. Por sua vez, os objetivos genricos possuem prticas genricas (generic practice, GPs) relativas a compromissos, habilidades, diretrizes para implementao e verificaes que so necessrias para o atingimento de um objetivo genrico. O gerenciamento de riscos em projetos tratado inicialmente pelo CMMI no segundo nvel de maturidade (Gerenciado) atravs de duas reas de processo: Project Planning (planejamento do projeto) atravs do SP Identificar os Riscos do Projeto dentro da SG Desenvolvimento do Plano do Projeto; e Project Monitoring and Control (monitorao e controle do projeto) atravs da SP Monitorar os Riscos do Projeto dentro da SG Monitorar o Projeto de Acordo
PUC-Rio - Certificao Digital N 0421051/CA

com o Plano. Entretanto, esta atuao feita de de uma forma reativa, ou seja, colocando o seu foco apenas na identificao dos riscos para conscientizao e reao medida que eles ocorram. O gerenciamento de riscos efetivamente tratado no terceiro nvel de maturidade (Definido) atravs da rea de processo Risk Management (gerncia de riscos). Esta rea de processo atua de uma forma proativa no sentido de minimizar os impactos dos riscos nos objetivos do projeto.
SG 1 Preparar-se para a Gerncia de Riscos SP 1.1 SP 1.2 SP 1.3 SG 2 SP 2.1 SP 2.2 SG 3 SP 3.1 Determinar Fontes e Categorias de Riscos Definir Parmetros de Riscos Estabelecer uma Estratgia para a Gerncia de Risco Identificar Riscos Avaliar, Categorizar e Priorizar Riscos Desenvolver Planos de Mitigao de Riscos

Identificar e Analisar Riscos

Mitigar Riscos

SP 3.2 Implementar Planos de Mitigao de Riscos Tabela 3 Objetivos Especficos da rea de Processo Risk Management do CMMI (fonte: SEI, 2006)

57 O objetivo especfico Preparar-se para a Gerncia de Riscos, atravs das suas trs prticas especficas descritas na tabela 3, tem a funo de estabelecer uma estratgia para identificar, analisar e mitigar riscos, que devero ficar documentadas num plano de gerenciamento de riscos. O objetivo especfico Identificar e Analisar Riscos, atravs das suas duas prticas especficas descritas na tabela 3, tem a funo de identificar os riscos e categoriz-los alm de fazer a sua anlise para obter o seu nvel de probabilidade e impacto com o objetivo de prioriz-los quanto ao seu grau de criticidade. O objetivo especfico Mitigar Riscos, atravs das suas duas prticas especficas descritas na tabela 3, tem a funo de atuar nos riscos no sentido de minimizar a sua probabilidade de ocorrncia e o seu impacto aos objetivos do projeto. Alm destes trs objetivos especficos, a rea de processo Risk
PUC-Rio - Certificao Digital N 0421051/CA

Management possui tambm um objetivo genrico: GG3 Institucionalizar um Processo Definido composto de 12 prticas genricas. Este objetivo genrico foi considerado desnecessrio para o escopo do presente trabalho e no ser comentado. 3.6. O gerenciamento de riscos na abordagem do PMI Estabelecido em 1969 e sediado na Filadlfia, Pensilvnia EUA, o Project Management Institute (PMI) a principal associao mundial sem fins lucrativos em Gerenciamento de Projetos, atualmente com mais de 170.000 associados em todo o mundo, que praticam e estudam o Gerenciamento de Projeto nas mais diversas reas. O seu principal documento o A Guide to the Project Management Body of Knowledge PMBOK, considerado um padro global para o Gerenciamento de Projetos nos mercados de hoje. O PMBOK prope quarenta e quatro processos divididos em nove reas de conhecimentos necessrias, segundo o PMI, para se gerenciar um projeto com sucesso: Gerncia da Integrao, Gerncia de Escopo, Gerncia de Tempo, Gerncia de Custos, Gerncia de Qualidade, Gerncia de Recursos Humanos,

58 Gerncia de Comunicaes, Gerncia de Riscos e Gerncia de Aquisies, que podem ser vistos na figura 13 (PMI, 2004).

PUC-Rio - Certificao Digital N 0421051/CA

Figura 13 Viso Geral das reas de Conhecimento e Processos de Gerenciamento de Projetos (fonte: PMI, 2004)

Estes processos esto agrupados em cinco grupos de processos, conforme mostrado na figura 14: Iniciao, onde o projeto definido e autorizado; Planejamento, onde so planejadas as aes necessrias para o alcance dos objetivos do projeto; Execuo, onde feita a realizao das aes planejadas na fase anterior; Monitoramento e Controle, onde o progresso do projeto controlado e medido com o intuito de identificar eventuais variaes e, neste caso, tomar aes corretivas para que os objetivos do projeto voltem a ser atendidos; e Encerramento, onde a entrega do produto formalizada e o projeto finalizado.

59

PUC-Rio - Certificao Digital N 0421051/CA

Figura 14 Grupo de Processos do Ciclo de Vida de um Projeto segundo o PMI (fonte: PMI, 2004)

A gerncia de integrao engloba os processos necessrios para identificar, definir, combinar, unificar e coordenar os diversos processos de gerenciamento de projetos dentro dos grupos de processos. A gerncia de escopo, os processos necessrios para garantir que o projeto inclua todo o trabalho necessrio para ser completado com sucesso. A gerncia de tempo, os processos necessrios para garantir que o projeto termine dentro do prazo previsto. A gerncia de custos, os processos necessrios para garantir que o projeto termine dentro do oramento aprovado. A gerncia de qualidade, os processos necessrios para garantir que o projeto satisfaa as necessidades para o qual foi empreendido. A gerncia de recursos humanos, os processos necessrios para garantir o uso mais efetivo das pessoas envolvidas no projeto. A gerncia de comunicao, os processos necessrios para garantir a correta gerao, distribuio, armazenamento, coleta, e disposio final das informaes relativas ao projeto. A gerncia de aquisies, os processos necessrios para compra de produtos e servios de fora da organizao executora do projeto.

60 E, finalmente, a gerncia de riscos inclui os processos referentes ao planejamento da gerncia de riscos, identificao, anlise, ao planejamento das respostas e ao controle e monitorao dos riscos em um projeto. Esses processos interagem entre si e com os processos das outras reas do conhecimento. Os objetivos da gerncia de riscos so aumentar a probabilidade de ocorrncia e os impactos de eventos positivos e diminuir a probabilidade e os impactos dos eventos adversos aos objetivos do projeto. A gerncia de riscos composta por seis processos que acontecem sequencialmente, cinco deles no fase de planejamento e o sexto na fase de monitoramento e controle. So eles: Planejamento do Gerenciamento de Riscos, Identificao de Riscos, Anlise Qualitativa de Riscos, Anlise Quantitativa de Riscos, Planejamento de Respostas a Riscos e Monitoramento e Controle de Riscos.
PUC-Rio - Certificao Digital N 0421051/CA

Figura 15 Os processos da gerncia de riscos segundo o PMI (criado pelo autor)

O processo de Planejamento de Gerenciamento de Riscos, executado na fase de planejamento, determina como abordar e planejar as gerncia de riscos do projeto. atividades de

61 O processo de Identificao de Riscos, que acontece na fase de planejamento, identifica, atravs de uma abordagem organizada, eventos de risco relevantes que possam impactar o atendimento dos objetivos do projeto. O processo de Anlise Qualitativa de Riscos, que acontece na fase de planejamento, avalia e classifica os riscos identificados em relao aos seus impactos e probabilidades de ocorrncia e os prioriza de acordo com seus potenciais efeitos sobre o desempenho do projeto. O processo de Anlise Quantitativa de Riscos, que acontece na fase de planejamento, analisa numericamente os riscos mais significantes estabelecidos durante a anlise qualitativa, e a interao entre eles, com o objetivos de estimar um range de possveis resultados para o projeto como um todo. O processo de Planejamento de Respostas a Riscos, que acontece na fase de planejamento, desenvolve procedimentos e tcnicas para ampliar as oportunidades e reduzir as ameaas aos objetivos do projeto, assegurando que os
PUC-Rio - Certificao Digital N 0421051/CA

riscos identificados sero tratados adequadamente. O processo de Monitoramento e Controle de Riscos, que acontece na fase de monitoramento e controle, rastreia sistematicamente os riscos identificados, monitora os riscos residuais e identifica novos riscos. Ele tambm assegura a execuo dos planos de respostas aos riscos e avalia a sua efetividade. 3.7. Comparao entre as metodologias apresentadas A tabela 4 toma como base os tens que compem as metodologias de riscos apresentadas e faz uma comparao entre elas, agrupando-as de uma maneira lgica e sequencial quanto sua atuao. O objetivo desta comparao a de investigar similaridades e divergncias entre elas com o intuito de identificar uma sequncia nica para gerenciar riscos em projetos de software.

62 Boehm RUP CMMI


Preparar-se para a Gerncia dos Riscos (SG 1): Determinar Fontes e Categorias de Riscos (SP 1.1) Definir Parmetros de Riscos (SP 1.2) Estabelecer uma Estratgia para Gerncia de Risco (SP 1.3)

PMI

Desenvolver o Plano de Gerenciamento de Riscos

Planejamento da Gerncia de Riscos

Identificao de Riscos

Identificao dos Riscos Anlise Qualitativa dos Riscos Anlise Quantitativa dos Riscos Planejamento das Respostas aos Riscos Planejamento das Respostas aos Riscos Monitorao e Controle de Riscos

Anlise de Riscos Identificar e Avaliar os Riscos

Identificar e Analisar Risco (SG 2): Identificar Riscos (SP 2.1)

Priorizao de Riscos
PUC-Rio - Certificao Digital N 0421051/CA

Planejamento da Gerncia de Riscos

Mitigar Riscos (SG 3): Desenvolver Planos de Mitigao deRiscos (SP 3.1)

Resoluo de Riscos Monitorar o Status do Projeto Monitorao de Riscos

Mitigar Riscos (SG 3): Implementar os Planos de Mitigao de Riscos (SP 3.2)

Tabela 4 Processos da gerncia de riscos Boehm x RUP x CMMI x PMI

A partir da anlise da tabela, inegvel afirmar que as abordagens apresentadas, embora tenham suas caractersticas prprias, possuem alguns princpios e atividades em comum, mostrando uma consonncia em seus aspectos essenciais. Um outro aspecto levantado neste estudo foi a incluso do gerenciamento de oportunidades, ou seja, a explorao de eventos positivos, em conjunto com os processos de gerenciamento de riscos. Da mesma forma que identificamos os riscos que possam gerar impactos negativos ao projeto e, em seguida, nos preocupamos em criar estratgias para eliminar a probabilidade deles

63 acontecerem, devemos tambm buscar as oportunidades, tambm chamadas de riscos positivos que, caso aconteam, traro impactos positivos ao projeto. Neste caso, as estratgias devem ser elaboradas no sentido de aumentar a probabilidade do acontecimento destas oportunidades. Podemos verificar que todas as metodologias, dentro do seu tipo de estrutura, possuem processos de identificao, anlise, planejamento de respostas e monitorao e controle de riscos. A dinmica vista em todas as metodologias segue a mesma linha. partir da identificao dos riscos e de sua anlise, elaboram-se opes de aes com vistas a proteger o projeto contra os riscos e, em seguida, decide-se qual destas opes ser a melhor para ser utilizada para que se coloque em prtica esta proteo. Isto comprova a importncia da gerncia de riscos para os projetos de um
PUC-Rio - Certificao Digital N 0421051/CA

modo geral, em especial em projetos de alto risco como o da implantao de sistemas ERP. Os altos custos oriundos de impactos negativos causados por riscos inerentes a estes tipos de projetos, poderiam ser minimizados se existisse uma preocupao da equipe do projeto em, no mnimo, buscar a identificao de riscos e a criao de estratgias de ao para os mesmos.

4. Uma Lista de Riscos na Implantao de Sistemas ERP

Como observado no captulo 2, projetos de implantao de ERP possuem uma grande quantidade de riscos associados, que podem comprometer o sucesso de sua implementao. A gesto efetiva destes riscos possibilita um maior controle dos seus efeitos. Uma pesquisa feita com gerentes de projetos do setor pblico e privado mostrou que apenas 41% dos projetos foram considerados bem sucedidos. Ela mostra tambm que somente 35% destes projetos utilizaram alguma ferramenta de gerenciamento de riscos, e que 46% destes projetos tiveram riscos inesperados que afetaram a sua performance (White e Fortune, 2002). O objetivo deste captulo o de produzir uma lista de riscos identificados
PUC-Rio - Certificao Digital N 0421051/CA

em projetos de implantao de ERP e possveis aes que poderiam ser tomadas no sentido de minimizar seus impactos aos objetivos destes tipos de projetos. Esta lista poder ser utilizada como referncia inicial para o gerenciamento de riscos em projetos desta natureza. Durante um projeto de implantao de sistemas ERP, existiro inmeras atividades que devem ser gerenciadas em prol do no comprometimento dos objetivos do projeto e, por conseguinte, da sua impossibilidade de sucesso. Por ser o risco algo incerto quanto sua ocorrncia, torna-se difcil elencar e controlar todas as possibilidades negativas presentes neste tipo de projeto. Estudos do PMI mostram que 10% dos riscos que acontecem em projetos de qualquer natureza no foram identificados pelas equipes responsveis pelo gerenciamento de riscos (PMI, 2004). Como visto no captulo anterior, a identificao de riscos o processo de examinar os diversos processos que atuam no ambiente de um projeto e determinar os riscos que podem afet-lo, documentando os mesmos. Em um projeto de software, um efetivo exame na natureza deste software bem como os processos bsicos de sua operao podem identificar fontes de riscos (Hall e Hullet, 2002). Alm disto, existem outros fatores que devem ser observados como, por exemplo, fatores culturais, sociais e ambientais que cercam estes tipos de projetos.

65 No sero considerados, neste levantamento, os riscos positivos, tambm chamados de oportunidades, que so eventos ou fatos que afetam positivamente os objetivos de um projeto e, neste caso, devem ter aes que os faam acontecer e que faam seus impactos serem os mais benficos possveis para estes projetos. O presente trabalho no tem a pretenso de identificar todos os riscos possveis em projetos desta natureza, preocupando-se em elencar apenas os riscos mais previsveis e conhecidos com base em informaes histricas de projetos finalizados ou em andamento. Novos riscos podero ser identificados atravs de uma efetiva identificao de riscos elaborada pelas organizaes que pretendem implantar ERP. Pritchard (2001) alega ser este o processo mais crtico dentro do gerenciamento de riscos de projetos. Segundo ele, os riscos no podem ser gerenciados com efetividade se no forem identificados e descritos de uma maneira clara.
PUC-Rio - Certificao Digital N 0421051/CA

Uma sugesto de tcnica bastante efetiva na identificao de novos riscos o brainstorming. Esta tcnica tm se mostrado a mais efetiva no que tange quantidade de riscos identificados segundo a experincia do autor em gerenciamento de projetos de TI. Em dinmicas de sala de aula de cursos de gerncia de riscos ministrados pelo autor, o mesmo experimentou que esta tcnica foi a maior geradora de riscos nos cases apresentados em relao a outras tcnicas utilizadas. O fato do risco ser um fenmeno futurista aliado ao fato de que as pessoas possuem alguma habilidade de intuio sobre alguns aspectos do futuro, faz com que esta tcnica se torne ideal para aplicaes lgicas (Pritchard, 2001). O brainstorming possui uma abordagem para obteno de riscos altamente criativa e sinrgica sem a existncia de qualquer tipo de restrio imposta aos seus participantes. Atravs da figura de um facilitador, todas as pessoas envolvidas no projeto se renem presencialmente e identificam, sem nenhum tipo de restrio, riscos potenciais do projeto sob o seu ponto de vista. Findo este processo, o facilitador agrupa os riscos identificados, eliminando redundncias e os mesmos so discutidos por todo o grupo. Entretanto outras tcnicas de identificao de riscos podero ser utilizadas como, por exemplo, o Delphi, o Slip de Crawford e as entrevistas com

66 especialistas. Existe vasta literatura sobre o assunto e importante que a organizao escolha a tcnica que melhor se adeque s suas caratersticas. Um fator crtico para o sucesso deste processo de identificao de novos riscos o de assegurar que os novos riscos identificados sero tratados adequadamente, incluindo a sua correta identificao e designao de indivduos ou grupos responsveis para atender cada possvel resposta de risco planejada. Sero sugeridas tambm no presente trabalho aes para os riscos identificados e categorizados. Estas aes tm o objetivo de prevenirem o acontecimento dos riscos. Conforme visto anteriormente, desenvolver planos de ao se resume em pensar e criar aes que reduzam as ameaas dos riscos acontecerem no sentido de torn-las nulas ou atuando na diminuio dos impactos por eles causados. No sero considerados, neste estudo, os processos de avaliao dos riscos
PUC-Rio - Certificao Digital N 0421051/CA

identificados, ou seja qualificao e quantificao dos riscos. A concluso quanto ao grau de criticidade de um risco, ou seja, a probabilidade deste risco acontecer e o nvel de impacto que ele pode causar aos objetivos do projeto, podem variar de organizao para organizao, dependendo de vrias caractersticas especficas de cada uma delas, como por exemplo, seu tamanho ou a sua atuao no mercado. Da mesma maneira, a percepo da quantificao destes riscos se diversifica nas organizaes, como por exemplo, em relao sua viso econmica de ganhos e perdas, o que poderia acarretar uma medio errnea e consequente falta de apoio na sua utilizao pela organizao. Aps a anlise de diversas monografias, artigos, livros e da experincia do prprio autor sobre implantaes de sistemas ERPs em empresas dos mais variados tipos, os riscos identificados nesta reviso foram reagrupados por semelhana. Para este agrupamento foram analisados dois mtodos com o intuito de escolha de um para ser o mtodo utilizado neste trabalho: a taxonomia de riscos da SEI e o Projeto Riscos Universais do INCOSE / PMI.

67 4.1. Taxonomia de Riscos da SEI Uma taxonomia uma estrutura categorizada e a classificao a ao de atribuio de entidades s categorias definidas dentro da taxonomia, ou seja, o agrupamento de itens semelhantes, tomando por base critrios estabelecidos (Prieto-Daz, 2002). No caso de uma taxonomia de riscos, a classificao equivale a atribuir riscos identificados dentro das categorias de riscos propostas.

PUC-Rio - Certificao Digital N 0421051/CA

Figura 16 Riscos de Software segundo a SEI (Traduzido de Fonte: SEI, 1993)

Segundo a SEI, os riscos de software so oriundos de problemas resultantes de aes gerenciais que acontecem no projeto e no processo de desenvolvimento de um software; e em aes tcnicas que acontecem no processo de desenvolvimento de um softtware e na gerao do produto, como pode ser visto na figura 16 (SEI, 1993). Exemplos de aes gerenciais que acontecem no projeto de desenvolvimento de software so a obteno de recursos, o relacionamento com os fornecedores, a busca de suporte organizacional e o controle sobre as variveis externas ao projeto. J no processo de desenvolvimento de software estes exemplos seriam o controle e a garantia da qualidade, a gerncia de configurao e a seleo de pessoal. No caso de aes tcnicas que acontecem na gerao do produto, o desempenho do produto, a estabilidade aos requisitos, a especificao de testes e a

68 complexidade do cdigo so exemplos destas aes. J no processo de desenvolvimento de software, os exemplos seriam a anlise de requisitos e o prprio processo de desenvolvimento. A taxonomia de riscos da SEI organiza os riscos de software em classes, que por sua vez so divididas em elementos e estes so divididos em atributos como pode ser vistos na figura 17:

PUC-Rio - Certificao Digital N 0421051/CA

Figura 17 Riscos de Desenvolvimento de Software segundo a SEI (traduzido da Fonte: SEI, 1993)

Existem trs grandes classes: Engenharia de Produtos, Ambiente de Desenvolvimento e Restries do Projeto. (Carr et al, 1993) A classe Engenharia de Produtos contempla os aspectos tcnicos e fsicos das atividades necessrias na criao de um software que satisfaa os requisitos definidos e as expectativas dos clientes. So exemplos destas atividades a anlise e especificao dos requisitos do software, a modelagem e a implementao do software, a integrao dos componentes do hardware e do software e os testes do software. Ou seja, engloba os aspectos tcnicos do trabalho a ser realizado na criao do software (Carr et al, 1993). Ela possui os seguintes elementos: requisitos, que define o que ser feito pelo software produzido e o que necessrio para que ele seja feito e

69 posteriormente utilizado e que tm como atributos a estabilidade, a perfeio, a clareza, a validade, a viabilidade, os precedentes e a escala do software; projeto, que traduz os requisitos para um efetivo projeto da soluo a ser produzida dentro das restries operacionais e do projeto e que tm como atributos a funcionalidade, a dificuldade, a interface, o desempenho, a testabilidade, as restries de hardware para o software; codificao e teste unitrio, que traduz o projeto para uma codificao que satisfaa os requisitos pedidos e que tm como atributos a viabilidade, o teste unitrio e a codificao e implementao do software; integrao e teste, que integra as unidades geradas criando o software pedido e que tm como atributos o ambiente, o produto e o sistema do software; e especialidades de engenharia, que se preocupa com a existncia de expertise nas reas envolvidas no desenvolvimento do software e que tm como atributos a manuteno, a confiabilidade, a segurana, os fatores humanos e as especificaes do software.
PUC-Rio - Certificao Digital N 0421051/CA

A classe Ambiente de Desenvolvimento contempla os mtodos, procedimentos e ferramentas utilizados na produo do software. Inclui os processos de desenvolvimento, os mtodos de gerenciamento e o ambiente do trabalho (Carr et al, 1993). Ela possui os seguintes elementos: processo de desenvolvimento, que so os mtodos e procedimentos utilizados para o desenvolvimento proposto do produto e que tm como atributos a formalidade, a convenincia, o controle e a familiaridade do processo, o controle do produto; sistema de desenvolvimento, que so as ferramentas e equipamentos necessrios para o desenvolvimento do software e que tm como atributos a capacidade, a convenincia, a usabilidade, a familiaridade, a confiabilidade, o suporte e a entrega do produto; processo de gerenciamento, que o planejamento, execuo e controle do projeto de desenvolvimento do software e que tm como atributos o planejamento e organizao do projeto, a experincia de gerenciamento e a interface com os stakeholders; mtodos de gerenciamento, que so os mtodos e ferramentas que sero utilizados para gerenciar e controlar o desenvolvimento do software e que tm como atributos o monitoramento, a gerncia de pessoal, o asseguramento da qualidade e a gerncia de configurao; e o ambiente de trabalho, que so os aspectos subjetivos (moral, comunicao e esprito de cooperao) da equipe

70 responsvel pelo desenvolvimento do software e que tm como atributos as atitudes de qualidade, a cooperao, a comunicao e a moral. A classe Restries do Projeto faz referncia aos fatores externos do projeto. Estes fatores normalmente esto fora do controle do projeto mas influenciam o seu sucesso. Temos como exemplos os fatores contratuais, os fatores organizacionais e os fatores operacionais (Carr et al, 1993). Ela possui os seguintes elementos: recursos, que so as restries impostas obteno e manuteno dos recursos e que tm como atributos o cronograma, o staff, o oramento e as instalaes; contrato, que so os termos e condies do contrato do projeto e que tm como atributos o tipo de contrato, as restries e as dependncias; e interfaces do programa, que so interfaces externas com clientes, outros contratados e a alta gerncia e que tm como atributos o cliente, os parceiros, a alta gerncia, os fornecedores e as polticas (Carr et al, 1993).
PUC-Rio - Certificao Digital N 0421051/CA

4.2. Projeto Riscos Universais da INCOSE / PMI Desenvolvido em 2002 pelo grupo de trabalho de gerenciamento de riscos (Risk Management Working Group - RMWG) do International Council on Systems Engineering (INCOSE) e pelo grupo de interesse especfico de gerenciamento de riscos (Risk Management Specific Interest Group RiskSIG) do Project Management Institute (PMI), o Projeto Riscos Universais (Universal Risk Project) teve o objetivo de desenvolver uma lista de reas universais de riscos (universal risk areas) que podem ser aplicadas em qualquer tipo de projeto ou operao dos setores comerciais, industriais e do governo (Hall e Hullet, 2002). A definio de um risco universal um evento ou condio que causa desvios em em relao ao que foi planejado e que tem uma chance razovel de afetar a conduo e a execuo de um projeto, operao de um sistema e conduo de uma anlise, podendo acontecer em qualquer projeto, operao ou sistema independentemente do tipo de indstria, organizao, sistema e projeto (Hall e Hullet, 2002). Os riscos universais podem ser includos em trs grandes grupos: os riscos de gerenciamento, os riscos externos e os riscos tecnolgicos. Estes grupos, por

71 sua vez, se subdividem em reas de riscos, conforme pode ser visto na figura 18 (Hall e Hullet, 2002).

PUC-Rio - Certificao Digital N 0421051/CA

Figura 18 Riscos Universais

O grupo de riscos de gerenciamento composto por uma srie de riscos especficos que caracterizam a organizao responsvel pelo projeto. So riscos provenientes do gerenciamento do projeto e de aspectos da organizao. Como aspectos da organizao podemos considerar a sua cultura, suas tendncias, suas condies financeiras e os estilos de comunicao e gerenciamento existentes. Este grupo possui duas reas de riscos especficos: a rea de riscos corporativos e a rea de riscos de gerenciamento de stakeholders. Na rea de riscos corporativos podem ser agrupados riscos relacionados com a histria, experincia e cultura da organizao, a sua estabilidade financeira e de mercado e seus processos e metodologias existentes. A rea de riscos de gerenciamento de stakeholders possui riscos relacionados com aspectos dos stakeholders do projeto, em especial os clientes do software, aspectos contratuais e definio e estabilidade dos requerimentos. O grupo de riscos externos composto por uma srie de riscos especficos que saem do controle da organizao responsvel pelo projeto. Estes riscos incluem aes de pessoas externas ao projeto (como clientes, fornecedores,

72 concorrentes e outros stakeholders), aes climticas, caractersticas

demogrficas, mercado e crescimento da economia. Este grupo possui trs reas de riscos especficos: a rea de riscos naturais, a rea de riscos culturais e a rea de riscos econmicos. Na rea de riscos naturais temos os riscos relacionados com aspectos fsicos do ambiente (condies metereolgicas, mudanas climticas, etc.), servios bsicos (eletricidade, gua, gs natural, segurana pblica, etc.) e caractersticas geogrficas. Na rea de riscos culturais temos riscos polticos e legais e na rea de riscos econmicos os riscos oriundos de relaes trabalhistas e do mercado de trabalho e financeiro. O grupo de riscos tecnolgicos composto por uma srie de riscos especficos relativos tecnologia e aos processos utilizados no desenvolvimento do projeto. Estes riscos derivam do estado da arte da tecnologia aplicada em relao a como o projeto est definido e adequado sua utilizao.
PUC-Rio - Certificao Digital N 0421051/CA

Este grupo possui trs reas de riscos especficos: a rea de riscos de requerimentos tecnolgicos, a rea de riscos de adequaes tecnolgicas e a rea de aplicaes tecnolgicas. Na rea de riscos de requerimentos tecnolgicos podem ser agrupados riscos relacionados com incerteza do escopo, condies de uso e complexidade da tecnologia utilizada. Na rea de riscos de adequaes tecnolgicas os riscos relacionados com a maturidade e os limites da tecnologia utilizada, e na rea de riscos de aplicaes tecnolgicas os relacionados com a experincia da organizao com a tecnologia, experincia e know-how das pessoas envolvidas com a tecnologia e recursos fsicos necessrios para utilizar a tecnologia.

4.3. Escolha do mtodo para a lista de riscos Inicialmente foi feito um comparativo entre os dois mtodos de agrupamento. Para isto analisou-se as classes de riscos da taxonomia de riscos da SEI com os grupos de riscos do mtodo dos riscos universais da INCOSE/PMI e observou-se uma similaridade entre eles, conforme pode ser visto na tabela 4:

73
Taxonomia de Riscos da SEI Engenharia de Produtos Ambiente de Desenvolvimento Restries do Projeto Riscos Universais da INCOSE / PMI Riscos Tecnolgicos Riscos de Gerenciamento Riscos Externos

Tabela 5 Comparativo entre os mtodos de agrupamento de riscos Taxonomia de Riscos da SEI e Riscos Universais da INCOSE/PMI

De acordo com as definies levantadas, a classe de riscos Engenharia de Produtos equivale ao grupo de riscos Riscos Tecnolgicos; a classe de riscos Ambiente de Desenvolvimento equivale ao grupo de riscos Riscos de Gerenciamento; e a classe de riscos Restries do Projeto equivale ao grupo de riscos Riscos Externos. Por se tratar de um mtodo mais moderno, foi escolhido o mtodo dos riscos universais para o agrupamento dos riscos levantados em projetos de implantao de ERPs.
PUC-Rio - Certificao Digital N 0421051/CA

Outro aspecto que foi levado em conta nesta escolha foi a adequao com os objetivos do trabalho, pois o autor tem o objetivo de tornar o checklist gerado como universal para implantaes de sistemas ERP, ou seja, que possa ser utilizado por qualquer organizao que pretenda atuar neste sentido. 4.4. A lista de riscos A lista de riscos desenvolvida pelo autor composta de 62 riscos. Na tabela 5 mostrada a distribuio destes riscos dentro das categorias.
CATEGORIAS DO RISCO Riscos de Gerenciamento Riscos Corporativos Riscos de Gerenciamento de Stakeholders Riscos Externos Riscos Naturais Riscos Culturais Riscos Econmicos Riscos Tecnolgicos Riscos de Requisitos Tecnolgicos QUANTIDADE DE RISCOS 33 15 18 6 2 2 2 23 7

74
Riscos de Adequaes Tecnolgicas Riscos de Aplicaes Tecnolgicas TOTAL Tabela 6 Distribuio dos riscos 5 11 62

4.4.1. Riscos de Gerenciamento


4.4.1.1 Riscos Corporativos: RISCO Instabilidade financeira devido ao alto Fazer custo da implantao do sistema ERP PLANO DE AO uma anlise prvia das condies financeiras da organizao e tomar medidas no sentido de manter estas
PUC-Rio - Certificao Digital N 0421051/CA

condies

saudveis

preparadas para suportar os custos de implantao do ERP. Alterao nos processos produtivos e Identificar administrativos da organizao. que processos sero alterados em virtude da implantao do ERP e documentar estas alteraes, informando-as prviamente para as pessoas da organizao. Falta de aderncia do ERP aos Incluir esta anlise no processo de processos da organizao. antes ERP. antes ERP. da seleo/implantao da seleo/implantao escolha do fornecedor do ERP. do processos atuais da organizao antes da implantao do ERP. o redesenho prvio dos do processos atuais da organizao antes da implantao do ERP. para novos desafios na Falta de mapeamento dos processos Garantir o mapeamento prvio dos

Falta de redesenho dos processos Garantir

Eliminao do nvel hierrquico de Atuar no sentido de realocao destas natureza ttica dentro da estrutura pessoas organizacional. Falha no oramento de implantao. organizao. Exigir do fornecedor um oramento detalhado e obter garantias destes gastos.

75
Disperso geogrfica da organizao. Garantir que todas as filiais estaro bem suportadas em relao ao novo sistema. Sistema no estar alinhado com o Garantir negcio da organizao. Falta de apoio da alta direo. atravs da anlise dos processos atuais que o sistema ir suport-los. Apresentar prviamente para a alta administrao os benefcios da implantao deste sistema buscando o seu apoio poltico. Brigas polticas pelo patrocnio do Atuar no sentido de gerenciar este projeto. organizao.
PUC-Rio - Certificao Digital N 0421051/CA

conflito de interesses. do patrocinador. Fazer incurses polticas para obter o apoio de novos patrocinadores.

Perda de prioridade do projeto na Atuar na manuteno do apoio poltico Perda do patrocinador.

O gerente do projeto no ser um Impr a obrigatoriedade do gerente de funcionrio da organizao. projetos ser algum que pertena organizao. Escolha inadequada do gerente do Utilizar critrios tcnicos e gerenciais projeto. pr-definidos para a escolha correta do funcionrio que ir se tornar o gerente do projeto. Tabela 7 Riscos Corporativos 4.4.1.2 Riscos de Gerenciamento de Stakeholders

RISCO funcionrios da organizao.

AES aos funcionrios como ser a nova rotina de trabalho aps a implantao do ERP.

Impacto na rotina de trabalho dos Identificar e comunicar prviamente

Falta

de

dedicao envolvidos

total com

dos Garantir internos.

a dedicao total destes atravs de acordos

funcionrios

a funcionrios

implantao do ERP.

Perda de funcionrios envolvidos com Buscar um comprometimento destes

76
a implantao do ERP. Resistncia dos funcionrios funcionrios implantao. Executar um trabalho de implantao do ERP. conscientizao dos funcionrios sobre as vantagens de utilizao de um sistema ERP. Aumento das atividades Fazer uma anlise de como sero aumentadas as atividades dos funcionrios e comunic-los antes, fazendo tambm uma redistribuio das atividades, se for necessrio. Utilizao inadequada da consultoria Planejar prviamente como e quando a externa. consultoria externa ser utilizada no projeto.
PUC-Rio - Certificao Digital N 0421051/CA

antes

do

incio

da

desempenhadas pelos funcionrios.

Falta

de

suporte da

tcnico empresa

ps- Incluso desta clusula no contrato de com a consultoria externa.

implantao

consultoria externa. No transferncia de conhecimento Incluso desta clusula no contrato para a equipe interna por parte da com a consultoria externa. empresa de consultoria externa. Impactos na implantao causados Alinhar com o patrocinador do projeto a pela no contratao de uma necessidade desta contratao para o bom andamento da implantao do ERP. Problemas na dispensa da Planejar previamente como ser feito trmino dos servios da consultoria externa e incluir esta clusula no contrato. Falta ERP. Desmotivao implantao. da equipe de preparo tcnico dos Criar um programa de treinamentos utilizar o ERP. de Atuar no sentido de manter estes funcionrios motivados durante todo o processo de implantao. No capacitao dos membros da Capacitar os membros da equipe, com consultoria externa. consultoria externa.

funcionrios na utilizao do sistema extensvel a todas as pessoas que iro

77
equipe para rpidas tomadas de apoio da consultoria externa, para que deciso. sejam capazes de tomar decises rpidas em aspectos relacionados com a implantao do sistema. No envolvimento dos usurios na Incluir implantao do sistema. Comunicao insuficiente. projeto. interna e representantes das reas usurias no time principal do projeto de implantao do sistema. externa Desenvolver um plano de comunicao para o projeto. projeto e um cronograma detalhado.

No formalizao do cronograma do Exigir do fornecedor um plano do Falta de integrao e/ou confiana Prever nos contratos de ambos que entre o fornecedor do ERP e a esta integrao dever existir. consultoria externa. Mudanas nos requisitos do sistema.
PUC-Rio - Certificao Digital N 0421051/CA

Definir um processo de controle de mudanas para o projeto.

Tabela 8 Riscos de Gerenciamento de Stakeholders

4.4.2. Riscos Externos


4.4.2.1 Riscos Naturais RISCO Danos causados nos equipamentos. Demora na entrega do hardware. Tabela 9 Riscos Naturais 4.4.2.2 Riscos Culturais RISCO ERP durante o projeto de implantao. AES ERP com posies slidas neste tipo AES Providenciar no-breaks e back-ups para os servidores. Acompanhar ativamente o processo de entrega do harware pelo fornecedor.

Falncia do fornecedor do software Selecionar fornecedores de software

78
de mercado. Falncia contratada implantao. Tabela 10 Riscos Culturais da consultoria o externa Selecionar consultorias externas com de posies mercado. slidas neste tipo de durante projeto

4.4.2.3 Riscos Econmicos RISCO Aumento excessivo do financeiro do contrato. Expectativas


PUC-Rio - Certificao Digital N 0421051/CA

AES indexador Criar clusulas no contrato com o fornecedor do ERP que protejam a organizao deste risco. (return of Alinhar do ROI. prviamente com os

de

ROI

investment) no atendidas. Tabela 11 Riscos Econmicos

stakeholders as expectativas realistas

4.4.3. Riscos Tecnolgicos


4.4.3.1 Riscos de Requerimentos Tecnolgicos RISCO Escolha inadequada do fornecedor do Utilizar ERP. uma AES comparao de alternativas de critrios e pesos para escolha do possvel fornecedor. Escolha inadequada da verso do Determinar qual ser a verso do ERP ERP. a ser utilizada e evitar upgrades desnecessrios. Escolha inadequada da consultoria Buscar o mximo de referncias sobre externa. migrados. os possveis consultores externos. da qualidade dos dados atuais Falta de acurcia nos dados a serem Fazer um estudo bastante aprofundado apresentados pelos sistemas antes da implantao.

79
M definio do escopo do projeto. Desenvolver uma declarao de

escopo do projeto e obter a aprovao de todos os stakeholders. Estratgia inadequada de implantao Dimensionar do ERP. desvantagens implantao consenso escolhida. Implantao de mdulos do ERP Garantir desnecessrios para a organizao. realmente que apenas os mdulos para a necessrios as das vantagens estratgias e e de obter

existentes quanto

estratgia

organizao sero implantados. Tabela 12 Riscos de Requerimentos Tecnolgicos 4.4.3.2 Riscos de Adequaes Tecnolgicas
PUC-Rio - Certificao Digital N 0421051/CA

RISCO No integrao do ERP com os Analisar sistemas legados da organizao.

AES quais as interfaces que devero ser criadas para a integrao do ERP com estes sistemas.

Dificuldade de integrar o ERP com Garantir, junto ao fornecedor, e com outros sistemas legados da apoio da consultoria externa que todas as interfaces com os sistemas legados sejam criadas do para ERP uma com efetiva estes integrao sistemas. Dimensionamento hardware implantao do ERP. inadequado para do Fazer um estudo junto ao fornecedor a do que como dever ser a atualizao do hardware atual para suportar o novo sistema. A soluo do ERP ser muito complexa Verificar previamente se a empresa para a organizao. tem condies culturais e estruturais para operar com um sistema desta natureza. Falta de segurana dos dados do ERP. Definir e implementar poltica segurana destes dados, Tabela 13 Riscos de Adequaes Tecnolgicas de necessrio organizao.

80
4.4.3.3 Riscos de Aplicaes Tecnolgicas RISCO Funcionrios preparados complexidade. O treinamento ser baseado na Conhecer previamente o contedo do baseie nos processos. Conhecer previamente o contedo do treinamento e exigir mudanas no mesmo caso seja identificado m qualidade do mesmo. Testes do sistema no serem efetivos.
PUC-Rio - Certificao Digital N 0421051/CA

AES com sua a Treinamento alta dos funcionrios

envolvidos para a

customizao do sistema no estarem envolvidos.

ferramenta ao invs de baseado nos treinamento e adequ-lo para que se processos. O treinamento ser de baixa qualidade.

Criar um planejamento detalhado dos testes.

Problemas na migrao dos dados Fazer um planejamento prvio de para o sistema ERP. No padronizao dos dados atuais. como ser o processo de migrao dos dados. Definir como ser feita a padronizao dos dados atuais para que possam ser recebidos pelo ERP. Documentao insuficiente do sistema. Acordar previamente com o fornecedor o nvel de documentao exigido pela organizao. Falha na estimativa do prazo de Exigir do fornecedor um cronograma implantao. detalhado com definies claras de cada fase da implantao e que seja elaborado em conjunto com os seus funcionrios. M qualidade do componentes Garantir suporte efetivo da consultoria externa contratada no que tange construo do sistema. Excesso de customizaes. Canalizar esforos para que se utilize processos construdos no prprio ERP. desenvolvidos para o sistema.

81
Configurao inadequada do software. Validao de todas as adaptaes antes do go live (liberao do sistema para a produo). Tabela 14 Riscos de Aplicaes Tecnolgicas

Vale ressaltar que esta lista de riscos, se utilizada em outros tipos de projetos de TI, dever ser revista no sentido de adequ-la s caractersticas especficas destes outros projetos. Acreditar que os riscos no iro afetar um projeto durante o seu ciclo de vida uma premissa perigosa. importante que os mesmos sejam identificados e
PUC-Rio - Certificao Digital N 0421051/CA

que tenham aes planejadas para o caso do seu acontecimento. Este foi o objetivo deste captulo. A disponibilizao de uma lista de provveis riscos em projetos desta natureza um fator motivacional para que as organizaes se sensibilizem quanto a gerenciar riscos. A identificao de riscos um fator crtico para o sucesso do gerenciamento de riscos por demandar tempo das pessoas envolvidas no projeto. A utilizao desta lista de riscos ir reduzir este problema no momento que j disponibiliza uma quantidade de riscos que, se bem gerenciados, podero contribuir para o sucesso destes projetos.

5. Concluso
A presente dissertao tem como objetivo principal o mapeamento de riscos inerentes a projetos de implantao de ERP nas organizaes e gerao de uma lista destes riscos apresentados atravs de uma taxonomia. Como podemos concluir, a implantao destes tipos de sistemas considerado algo bastante crtico, j que ela envolve mudanas na organizao e na relao entre seus colaboradores, entre outros problemas que pudemos ver no desenvolvimento desta dissertao. Os projetos desta natureza so considerados projetos dispendiosos e que necessitam de muito tempo de implementao devido sua alta complexidade de desenvolvimento. Em 1999, a empresa de consultoria Boston Consulting Group
PUC-Rio - Certificao Digital N 0421051/CA

fez um estudo com cem executivos de empresas lderes em seus segmentos de mercado e constatou que somente um em cada trs projetos de ERP obtiveram sucesso nas suas implantaes dentro das organizaes consultadas (Bergamaschi, 1999). Este captulo tem o objetivo de apresentar as principais concluses obtidas com os resultados desta pesquisa e algumas sugestes de trabalhos futuros. O captulo 2 teve como objetivos apresentar os conceitos dos sistemas ERP, seus benefcios para as organizaes, as etapas necessrias para a sua implantao e os fatores crticos observados neste processo atravs de pesquisas em teses, dissertaes e artigos que versassem sobre este tema. Este captulo foi um meio importante para que o objetivo principal desta dissertao, o checklist de riscos, fosse possvel de ser produzido. Como resultado da reviso bibliogrfica feita neste captulo, observou-se que sistemas desta natureza afetam a organizao como um todo e que suas implantaes devem ser precedidas de um planejamento bem elaborado em conjunto com a existncia de um gerenciamento de riscos efetivo. Outra concluso importante observada a de que o sistema ERP em produo deve estar de acordo com os processos de negcio de uma organizao, o que torna capital uma reviso nestes processos, antes de partir para a

83 implantao. Para que isto ocorra, a escolha do fornecedor e da consultoria especializada adequada torna-se um fator crtico para o alcance deste objetivo. O captulo 3 teve como objetivos elaborar uma reviso bibliogrfica sobre riscos e gerenciamento de riscos e fazer uma pesquisa em metodologias de gerenciamento de riscos existentes e conceituadas, com o intuito de elaborar um estudo comparativo entre elas. Aps este estudo comparativo, concluiu-se que as metodologias analisadas, embora tenham algumas particularidades, tm no fundo a mesma dinmica processual: partir de um planejamento do gerenciamento dos riscos e posterior identificao dos riscos e de sua anlise, elaboram-se aes com vistas a proteger o projeto contra estes riscos e, em seguida, decide-se qual destas opes ser a melhor para ser utilizada para que se coloque em prtica esta proteo. O captulo 4 analisou duas taxonomias de riscos existentes fazendo um
PUC-Rio - Certificao Digital N 0421051/CA

comparativo entre elas e, aps a escolha de uma delas, agrupou mais de 60 riscos levantados com base nas informaes obtidas no captulo 2, o que resultou no objetivo principal do trabalho que era o da criao de uma lista de riscos para projetos de implantao de sistemas ERP. Para a comunidade de futuros usurios do ERP, o entendimento da incluso do gerenciamento de riscos nos projetos de implantao destes sistemas auxiliar em uma maior probabilidade de sucesso nestas implantaes, pois quanto mais conhecidos forem os riscos e as aes que devem ser tomadas contra eles, mais segurana e confiana tero as empresas em se engajar em projetos desta natureza. Para a comunidade acadmica, este estudo representa mais um passo em direo a um melhor entendimento de como o gerenciamento de riscos capital para o sucesso dos projetos. 5.1. Sugestes de trabalhos futuros Um assunto novo a incluso do gerenciamento de oportunidades em conjunto com os processos de gerenciamento de riscos. No h dvidas que as organizaes tem muito a ganhar se no se limitarem a apenas gerenciar ameaas, mas complementar este esforo para tambm aproveitar oportunidades de gerar ganhos para o projeto e para a prpria organizao (Hillson, 2002). Um estudo

84 complementar para identificar oportunidades em projetos de implantao de ERP poderia ser feito para complementar o estudo atual. Ainda neste quesito, seria interessante a criao de um ranking de riscos em projetos de implantao de ERP atravs de um processo de qualificao de riscos proposto. Outra sugesto seria a criao de uma lista de riscos para a implantao e operao de sistemas ERP II, englobando tambm os riscos inerentes sua integrao com o Customer Relationship Management - CRM e com o Business Intelligence - BI. Finalizando, o lanamento de um questionrio sobre riscos encontrados em implantaes de sistemas ERP a ser direcionado para empresas que passaram por esta experincia seria uma ao que poderia gerar novos riscos para a lista que foi gerada neste trabalho.
PUC-Rio - Certificao Digital N 0421051/CA

6. Referncias Bibliogrficas

ALBERTO, Sebastio E., ERP Sistemas de Gesto Empresarial metodologia para avaliao, seleo e implantao: para pequenas e mdias empresas. So Paulo : Iglu, 2001. ALVARENGA, M.L.F., Metodologia para Verificao do Sucesso na Implantao de ERP (Enterprise Resource Planning) Baseada nos Fatores Crticos de Sucesso Aplicao na Indstria Mineira, Universidade Federal de Santa Catarina - UFSC, Florianpolis, 2003. AMR Research Press Release 2006 [online], Internet: <http://www.amrresearch.com/Content/View.asp?pmillid=19840>, acesso em 31/10/2006). APM, APM Body of Knowledge, 5th edition. Association for Project Management, 2006.
PUC-Rio - Certificao Digital N 0421051/CA

AROZO, Rodrigo, Software de Supply Chain, Revista Tecnologstica, Centro de Estudos de Logstica, Outubro, 2003. BERGAMASCHI, Sidnei. Um Estudo Sobre Projetos de Implementao de Sistemas Para Gesto Empresarial. Dissertao (Mestrado em Administrao) Faculdade de Economia, Administrao e Contabilidade, Universidade de So Paulo, So Paulo, 1999. BERNSTEIN, P. L. Desafio aos Deuses: a fascinante histria do risco. 2 edio. Rio de Janeiro Campus, 1997. BOEHM, Barry W. Software Risk Management: Principles and Practices. IEEE, Janeiro, 1991. CARR, M. ET AL, Based Risk Identification. Technical Report CMU/SEI-93TR-6. Software Engineering Institute, Carnegie Mellon University. USA. 1993. CARR, M. J., KONDA, S. L., MONARCH, I., ULRICH, F. C., and WALKER, C. F. Taxonomy-based risk identification. Technical Report CMU/SEI-93-TR-6, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, USA, 1993. CHOPRA, S.; MEINDL, P. Gerenciamento da Cadeia de Suprimentos Estratgia, Planejamento e Operao. Prentice Hall, 2003. CLELAND, D. I.; IRELAND, L. R. Gerncia de projetos. Rio de Janeiro: Reichmann & Affonso Editores, 2000.

86 COLANGELO, L.F.. Implantao de sistemas ERP (Enterprise Resource Planning): um enfoque de longo prazo., Atlas, So Paulo, 2001. COMPUTERWORLD, "Executive Briefing Guia Executivo para Decises Estratgicas Sistemas de Apoio Deciso", 2005. CORRA, H. L., GIANESI I. G. & CAON, M., Planejamento, Programao e Controle de Produo. 4 edio. So Paulo: Editora Atlas, 2001. CORRA, H.L; GIANESI, I.G.N., Just in time: MRPII e OPT: Um Enfoque Estratgico. So Paulo: Editora Atlas S.A., 1994. DAVENPORT, T.H., Misso crtica: Obtendo vantagem competitiva com os sistemas de gesto empresarial, 2000. DAVENPORT, T.H., Putting the enterprise into the enterprise system. Harvard Business Review. 1998. DONOVAN, R. M., Successful ERP Implementation the First Time, 2002. Disponvel em < http://www.rmdonovan.com >. Acesso em 12/outubro/2006.
PUC-Rio - Certificao Digital N 0421051/CA

DONOVAN, R. M., Why the Controversy over ROI from ERP?, 2000. Disponvel em < http://www.rmdonovan.com >. Acesso em 12/outubro/2006. FOTI, Ross. The essential ERP guide. PMnetwork, Newton Square, p.28-34, jun/2003. GAMBA, Fernando A. R.; LAU, J.L.-S.; CAPUTO, Mrcio S.; BRESCIANI F., Ettore. Mtodo para Gesto de Riscos em Implementaes de Sistemas ERP baseado em Fatores Crticos de Sucesso. In: Revista de Gesto da Tecnologia e Sistemas de Informao, v. 1, n. 1, 2004. GOMES, C.; VANALLE, R. Aspectos Crticos para a Implantao de Sistemas ERP. In: Encontro Nacional da Engenharia de Produo. Anais. Salvador, 2001. GUPTA, A., "Enterprise resource planning: the emerging organizational value systems", Industrial Management & Systems, Vol. 100 No. 3, pp. 114-18, 2000. GUSMO, C; MOURA, H., Gerncia de Risco em Processos de Qualidade de Software: uma Anlise Comparativa. Universidade Federal de Pernambuco, 2004. HALL D.; HULLET D., Universal Risk Project Final Report. Risk Research and Development Program, PMI & INCOSE, 2002. HILLSON, D., Extending the risk process to manage opportunities. International Journal of Project Management, IPMA, 2002.

87

HYPLITO, C.M., Um Estudo sobre Problemas na Implantao de Sistemas Integrados de Gesto: um Enfoque rea de Custos. Escola Federal de Engenharia de Itajub, junho de 2000. KANSAL, V., Enterprise Resource Planning Implementation: A Case Study In Journal of American Academy of Business, Cambridge. Hollywood, 2006 KERZNER, Harold., Gesto de Projetos As Melhores Prticas. So Paulo, Bookman, 2006. KOCH, C., The ABCs of ERP, 2006. Disponvel em < http://www.cio.com/research/erp/edit/erpbasics.html>. Acesso em 12/outubro/2006. KOCH, C.; SLATER, D.; BAATZ, E. The ABCs of ERP. Disponvel na Internet em http://www.cio.com. Acesso em 22/agosto/2006. KRUCHTEN, P. Introduo ao RUP Rational Unified Process. Editora Cincia Moderna, 2003.
PUC-Rio - Certificao Digital N 0421051/CA

LIGHT, B.; HOLLAND, C.P. ; WILLS, K. ERP and Best of Breed: a comparative analysis. Business Process Management Journal, v. 7, n. 3, p. 216224, 2001. MACHADO, Cristina A. F., A-Risk: Um mtodo para identificar e quantificar risco de prazo em projetos de desenvolvimento de software. Curitiba, 2002. MATOSO, A. Estratgias ou Processos de Desenvolvimento de Software (Ciclo de Vida). Centro de Ensino Unificado de Braslia - UNICEUB, Braslia, 2004. MOLINARI, L. Produzindo Sistemas Melhores e Mais Confiveis. Editora rica, 2003. MORAES, Anderson L., "Trabalho sobre ERP", Centro Federal de Educao Tecnolgica do Paran, Curitiba, 2004. MORAES, Anderson L., Trabalho sobre ERP, Centro Federal de Educao Tecnolgica do Paran, Curitiba, 2004. NAH, F.F.-H.; LAU, J.L.-S.; KUANG, J. Critical factors for successful implementation of enterprise systems. Business Process Management Journal, v. 7, n. 3, p. 285-296, 2001. OLIVEIRA, M.A., RAMOS, A.S.M. Fatores de Sucesso na Implementao de Sistemas Integrados de Gesto Empresarial (ERP): Estudo de Caso em uma Mdia Empresa. In: Encontro Nacional de Engenharia de Produo. Anais. Curitiba, 2002.

88 OLIVEIRA, N.M., Seleo de Sistemas de Gesto e o Impacto no Processo de Implantao: Um Estudo de Casos Mltiplos, Universidade do Vale do Rio dos Sinos - UNISINOS, So Leopoldo, 2003. PADILHA, Thais Cssia Cabral et al . Tempo de implantao de sistemas ERP: anlise da influncia de fatores e aplicao de tcnicas de gerenciamento de projetos. Gest. Prod., So Carlos, v. 11, n. 1, 2004. PADILHA, Thais Cssia Cabral; MARINS, Fernando Augusto Silva. Sistemas ERP: caractersticas, custos e tendncias. Prod., So Paulo, 2005. Disponvel em: <http://www.scielo.br> . Acesso em: 20/10/2006. PMI. Conjunto de Conhecimentos em Gerenciamento de Projetos (PMBOK). Project Management Institute (PMI) 3 edio 2004. POLLONI, Enrico G. Franco, Enterprise resource planning (ERP) Planejamento de Recursos Empresariais. So Paulo: Revista lvares Penteado, 1999.
PUC-Rio - Certificao Digital N 0421051/CA

PRIETO-DAZ, R. A Faceted Approach to Building Ontologies. 21st International Conference on Conceptual Modeling-ER2002. Tanpere, Finland. Julho de 2002. PRITCHARD Carl L., Risk Management Concepts and Guidance. ESI International, 2001. RATIONAL SOFTWARE CORPORATION, Rational Unified Process. Version 2003.06.00.65. CD-ROM, Rational Software, Cupertino, Califrnia, 2003. REZENDE, Denis Alcides, Engenharia de software e sistemas de informao. 2 ed. Rio de Janeiro: Brasport, 2002. ROCHA, P.C.; BELCHIOR A.D., SIMPROS 2004 (VI Simpsio Internacional de Melhoria de Processo de Software) SENAC/CenPRA, So Paulo, 2004. ROQUE, Ruth Ferreira, Estudo Comparativo de Metodologias de Desenvolvimento de Sistemas de Informao Utilizando a Tcnica Delphi. Florianpolis, 1998. SALGUEIRO, Morgana Duarte, Desafios da Implantao de um Sistema ERP, 2005. Disponvel em: http://www.desafio21.com.br. Acesso em: 10/10/2006. . SANTOS, J..A.S., CARVALHO, H. G., Referencial Brasileiro de Competncias em Gerenciamento de Projetos. ABGP / IPMA. 2005. SCOTT, J.E.; VESSEY, I., "Managing risks in enterprise systems implementations", Communication of the ACM, Vol. 45 No. 4, pp. 74-81, 2002.

89 SILVA, Firmino; ALVES, Jos A., ERP e CRM. Da empresa e-empresa solues de informao reais para empresas globais. Lisboa: Centro Atlntico, 2000. SLACK, N. et al. Administrao da produo. So Paulo: Editora Atlas S.A., 1999. SEI - SOFTWARE ENGINEERING INSTITUTE, CMMI for Development version 1.2 Pittsburgh, PA. Software Engineering Institute, Carnegie Mellon University. USA., 2006. Disponvel na Internet em <http://www.sei.cmu.edu>. Acesso em 09/setembro/2006. SOH, C., Siew Kien, S., and Tay-Yap, J. Cultural fits and misfits: is ERP a universal solution?, Communications of the ACM, 2000. SOUSA, J.E.; COLLADO, J.P., Towards the Unification of Critical Success Factors for ERP Implementations, Universitat Politcnica de Catalunya, 2000. Disponvel em <http://www.crm2day.com/erp/erp-2.php>. Acesso em 12/outubro/2006.
PUC-Rio - Certificao Digital N 0421051/CA

SOUZA, C.A. de e SACCOL, A.Z., Sistemas ERP no Brasil: (Enterprise Resource Planning): teoria e casos. So Paulo: Atlas, 2003. SOUZA, C.A.; ZWICKER, R. Sistemas ERP e sua utilizao por empresas globais: estudo de caso em empresas multinacionais. In: V SEMEAD / FEA USP. So Paulo, 2001. TAURION, C., Oportunidades e Riscos na Escolha de uma Soluo ERP. Gesto Empresarial Magazine. Rio de Janeiro, ano 1, n. 1, janeiro de 1999. VERGARA, S.C, Projetos e relatrios de pesquisa em administrao. 4.ed. So Paulo: Atlas, 2003. WAGLE, D. The Case for ERP Systems. The Mckinsey Quarterly, n. 2, 1998. WHITE, D; FORTUNE, J. Current practice in project management an empirical study. International Journal of Project Management, IPMA, 2002. WILLIS, T.H. and WILLIS-BROWN, A.H., "Extended the value of ERP", Industrial Management & Data Systems, Vol. 102 No. 1, pp. 35-8, 2002. WOOD JR., T. Modas e modismos gerenciais: o caso dos sistemas integrados de gesto. Srie de Relatrios de Pesquisa, NPP, Ncleo de Pesquisas e Publicaes. Escola de Administrao de Empresas de So Paulo, FGV. Relatrio n. 16, 1999. WORTHEN, B., Nestls ERP Odissey, CIO Magazine, 2002. Disponvel em < http://www.cio.com/archive/051502/nestle.html>. Acesso em 12/outubro/2006.

90 WRIGHT, S.; WRIGHT, A.M., "Information system assurance for enterprise resource planning systems: implementation and unique risk considerations", Journal of Information Systems, Vol. 16, pp. 5-15, 2001.

PUC-Rio - Certificao Digital N 0421051/CA