Embed Size (px)
Citation preview
Evandro Luiz de Oliveira
UTILIZAÇÃO DOS PROGRAMAS DE PLANEJAMENTO
DE RECURSOS EMPRESARIAIS NA GESTÃO DE
PROJETOS: um estudo de caso
Taubaté – SP
2004
Evandro Luiz de Oliveira
UTILIZAÇÃO DOS PROGRAMAS DE PLANEJAMENTO
DE RECURSOS EMPRESARIAIS NA GESTÃO DE
PROJETOS: um estudo de caso
Monografia apresentada para obtenção do
Certificado de Especialização pelo Curso MBA -
Gerência de Produção e Tecnologia do
Departamento de Economia, Contabilidade e
Administração – ECA da Universidade de Taubaté.
Área de Concentração: Gestão de Projetos e
Tecnologia da Informação Orientador: Prof. Dr. Francisco Cristóvão Lourenço
de Mello
Taubaté – SP
2004
Ficha catalográfica elaborada pelo SIBi – Sistema Integrado de Bibliotecas / UNITAU
O482u Oliveira, Evandro Luiz de
Utilização dos programas de planejamento de recursos empresariais na gestão de projetos: um estudo de caso / Evandro Luiz de Oliveira. Taubaté: UNITAU, 2004.
116f. : il.
Orientador: Francisco Cristovão Lourenço de Melo Monografia (Especialização) – Universidade de Taubaté, Departamento de Economia,
Contabilidade e Administração, 2004.
1.Tecnologia da informação. 2. Gestão de projetos - Softwares. 3. Entreprise ResourcesPlanning – ERP. 4. Recursos empresariais. I. Universidade de Taubaté. Departamento de Economia, Contabilidade e Administração. II. Melo, Francisco Cristovão Lourenço de (orient.). III. Título.
EVANDRO LUIZ DE OLIVEIRA
UTILIZAÇÃO DOS PROGRAMAS DE PLANEJAMENTO DE RECURSOS
EMPRESARIAIS NA GESTÃO DE PROJETOS: um estudo de caso.
UNIVERSIDADE DE TAUBATÉ, TAUBATÉ, SP
Data: ___________________________________________
Resultado: _____________________________________
COMISSÃO JULGADORA Prof. Dr. Francisco Cristóvão Lourenço de Mello Universidade de Taubaté
Assinatura _____________________________________
Prof. Dr. José Luís Gomes da Silva Universidade de Taubaté
Assinatura _____________________________________
Prof. M.Sc. Paulo Cesar Corrêa Lindgren Universidade de Taubaté
Assinatura _____________________________________
Dedico este trabalho:
Aos meus amados pais, Evandro, “em memória”, e Constância, os quais construíram os
alicerces a partir do qual venho edificando a minha vida, além de possibilitar percorrer
o longo caminho para acrescentar mais este tijolo à obra.
À minha esposa Cleusa e filhas Jéssica e Júlia, que são fonte de inspiração para superar
os desafios da vida e as quais sofreram com minha ausência para a realização deste
trabalho.
Aos professores da nossa turma, pelo exemplo, carinho, dedicação e competência com
que fizeram deste curso uma experiência inesquecível para mim.
Aos colegas de turma, junto com os quais tive a alegria de poder compartilhar grandes
alegrias e aprender muito de todos.
Aos inestimáveis amigos e profissionais na Alstom, os quais conheci ao longo de minha
carreira profissional. Sem ajuda deles não teria sido possível percorrer o longo caminho
para chegar à realização deste trabalho, além do mais, os mesmos tiveram uma
participação importante na minha formação como profissional e cidadão e somente por
falta de espaço não são citados.
AGRADECIMENTOS
Ao professor Dr. Francisco Cristóvão Lourenço de Mello, pela habilidade com que
me orientou na realização deste trabalho. Pela paciência em ouvir e esclarecer minhas
dúvidas, apresentando críticas e sugestões precisas; as quais possibilitaram este
trabalho ser realizado com a qualidade e o prazo requeridos. A indicação de
referências bibliográficas e o empréstimo de uma das mesmas, a qual se mostrou
muito útil, para a realização da revisão da literatura utilizada neste trabalho.
A Empresa Alstom do Brasil Ltda, a qual permitiu a utilização do mandante de testes de
seu sistema ERP SAP R/3 na sua unidade produtiva localizada na cidade de Taubaté.
Ao Diretor Angelo Alberto Bellelis pelo apoio na realização deste trabalho.
Ao Gerente de Aplicações de TI, Itamar Glezer, pelo apoio, incentivo e interesse sobre
o tema.
Ao Eng. César Roberto Santos, pela ajuda na realização de algumas das simulações e
esclarecimento de algumas dúvidas sobre os recursos disponíveis no SAP R/3 para
planejamento de projetos.
Ao Eng. Edgar Crafig, pela ajuda na revisão e correção do texto.
OLIVEIRA, Evandro Luiz. Utilização dos programas de planejamento de recursos
empresarias na gestão de projetos: um estudo de caso. 2004. 116 f. Monografia
(Especialização, MBA Gerência de Produção e Tecnologia) – Departamento de
Economia, Contabilidade e Administração – ECA, Universidade de Taubaté, Taubaté.
RESUMO
A utilização de softwares para aplicação das técnicas de Gerenciamento de
Projetos, sintetizadas na obra A Guide to the Project Management Body of Knowledge
ou, simplesmente, como é mais conhecido, PMBOK®, tem crescido no mundo.
Atualmente, além dos softwares específicos para Gestão de Projetos, têm sido utilizados
também softwares conhecidos como Enterprise Resources Planning, ou Planejamento
de Recursos Empresarias. Para verificar a capacidade destes softwares suportarem as
técnicas de Gestão de Projetos, realizou-se a simulação, em um sistema SAP R/3, da
utilização de algumas das técnicas adotadas pela Gestão de Projetos. Foram simuladas
as utilizações das técnicas de Estrutura Analítica do Projeto e Planejamento Físico do
Projeto, com utilização da técnica do Método do Caminho Crítico e Cronograma de
Gantt. As simulações consistiram na construção, para um Projeto fictício, de: estrutura
analítica do projeto, diagramas de precedência e cronogramas utilizando o software SAP
R/3, acompanhadas da análise dos resultados em relação às técnicas de Gestão de
Projetos. Após realização das simulações e comparação dos resultados obtidos com a
literatura, concluiu-se que os softwares de Planejamento de Recursos Empresariais são
capazes de suportar, de forma satisfatória, as técnicas da Gestão de Projetos no que se
refere à construção de estruturas analíticas, diagramas de precedência e cronogramas
dos projetos, desde que os usuários dominem as técnicas de Gestão de Projetos e
tenham um conhecimento adequado de como utilizar o software.
Palavras-chave: planejamento, projetos, diagramas, cronogramas, gestão de projetos.
OLIVEIRA, Evandro Luiz. Utilization of enterprise resources planning software in
project management: a case study. 2004. 116 p. Monograph (Specialization, MBA
Management of Production and Technology) – Department of Economics, Accounting
and Management – ECA, University of Taubaté, Taubaté, BRAZIL.
ABSTRACT
The utilization of the software to apply the techniques of Project Management,
synthesized in the Guide to the Project Management Body of Knowledge, or, simply as
it is known, PMBOK®, has been growing in the world. Now, besides the specific
software for Projects Management, it has been used software known as Enterprise
Resource Planning. To verify the capacity of these software to support the Management
Projects techniques, it was realized a simulation in a SAP R/3 system, of the utilization
of some of the techniques adopted by the Management Projects. It was simulated the
utilization of the techniques of: Project Analytic Structures and Project Physical
Planning with utilization of the Critical Path Method and Gantt Schedule. The
simulations consisted of the construction for a fictitious Project of: Analytic structures,
precedence diagrams and schedules using a software SAP R/3, accompanied of the
analysis of the results in relation to the techniques of the Projects Management.
After accomplishment of the simulations and comparison of the obtained results with
the literature, was concluded that the software Enterprise Resource Planning are capable
to support in a satisfactory way the techniques of the Projects Management that refers to
the construction of projects structures, precedence diagrams and schedules of the
projects, since the users dominate the techniques of Projects Management and have an
appropriate knowledge of how to use the software.
Word-key: planning, projects, diagrams, schedules, projects management.
SUMÁRIO RESUMO.............................................................................................................. 7
ABSTRACT.......................................................................................................... 8
LISTA DE FIGURAS........................................................................................... 11
1 INTRODUÇÃO................................................................................................. 15
1.1 OBJETIVOS.............................................................................................. 16
1.1.1 Objetivo Geral...................................................................................... 16
1.1.2 Objetivos Específicos.......................................................................... 16
1.2 DELIMITAÇÃO DO ESTUDO................................................................ 16
1.3 RELEVÂNCIA DO ESTUDO................................................................... 17
1.4 ORGANIZAÇÃO DO TRABALHO......................................................... 17
2 REVISÃO DA LITERATURA......................................................................... 19
2.1 A Gerência de Projetos, uma visão geral................................................... 19
2.1.1 A Gerência de Projetos, numa perspectiva histórica.......................... 19
2.1.2 Gerência de Projetos: conceitos e área de conhecimento................... 22
2.1.3 A Gerência de Projetos num contexto mais amplo............................ 27
2.2 Gerenciamento do escopo do Projeto – divisão dos pacotes de trabalho.. 31
2.2.1 Gerenciamento do escopo do Projeto – uma visão geral................... 31
2.2.2 Divisão dos pacotes de trabalho - Estrutura do Projeto..................... 33
2.3 Gerenciamento do prazo do Projeto........................................................... 39
2.3.1 Gerenciamento do prazo do Projeto, uma visão geral........................ 39
2.3.1.1 Gerenciamento do prazo do Projeto – processos, ferramen- tas e técnicas.........................................................................
40
2.3.2 Processo de Definição das Atividades............................................... 41
2.3.3 Processo de Seqüenciamento das Atividades..................................... 43
2.3.3.1 Método do Diagrama de Precedência (PDM)........................ 43
2.3.3.2 Método do Diagrama de Flecha (ADM)................................ 45
2.3.3.3 Análise comparativa dos métodos Diagramas de Flecha e Precedência............................................................................
46
2.3.3.4 Métodos do Diagrama Condicional (CDM) e modelos de rede.........................................................................................
47
2.3.3.5 Saídas das técnicas de construção de diagramas................... 47
2.3.4 Estimativas da duração das atividades dos diagramas de projeto...... 48
2.3.4.1 Elaboração dos diagramas do projeto tipo CPM................... 49
2.3.4.2 Elaboração dos diagramas do projeto tipo Diagramas de Gantt.......................................................................................
54
2.3.5 Processo de controle do cronograma.................................................. 57
2.3.6 Construção e integração da EAP, diagramas e cronogramas de PRJ. 58
2.4 Uso de programas em Gerenciamento e Planejamento de Projetos........... 61
2.5 Programas para Planejamento de Recursos Empresarias........................... 62
2.5.1 Os sistemas ERP, características e aplicações................................... 62
2.5.2 O sistema ERP SAP R/3, uma visão geral......................................... 63
3 METODOLOGIA.............................................................................................. 68
4 RESULTADOS E DISCUSSÃO....................................................................... 69
4.1 Projeto fictício para realização da simulação............................................. 69
4.2 Elaboração da EAP no ERP SAP R/3........................................................ 72
4.2.1 A tela de criação da EAP no ERP SAP R/3 – visão geral.................. 72
4.2.2 Simulação de criação da EAP no ERP SAP R/3................................ 73
4.2.3 Elaboração da EAP no ERP SAP R/3 a partir de modelos................ 78
4.3 Planejamento Físico de Projetos no ERP SAP R/3.................................... 80
4.3.1 A tela de criação de Diagramas e Cronogramas no ERP SAP R/3 – visão geral..........................................................................................
80
4.3.2 Simulação de criação de Diagrama de Precedência no ERP SAP R/3......................................................................................................
81
4.3.3 Relações possíveis de serem utilizadas nos Diagramas no ERP SAP R/3......................................................................................................
85
4.3.4 Simulação de criação de Gráfico de Gantt no ERP SAP R/3............. 87
4.3.5 Exportação do diagrama gráfico de Gantt do ERP SAP R/3 para MS-Project.........................................................................................
90
4.4 Recursos para integração da EAP com os Diagramas de Rede no ERP SAP R/3.....................................................................................................
91
4.5 Recursos para gestão de documentos no ERP SAP R/3............................ 95
4.6 Os relatórios para gestão física dos projetos no ERP SAP R/3................ 97
4.7 Os recursos do ERP SAP R/3 e as técnicas de Gestão de Projeto............. 100
5 CONCLUSÃO................................................................................................... 103
6. PERSPECTIVAS ABERTAS COM A REALIZAÇÃO DO TRABALHO.... 104
REFERÊNCIAS.................................................................................................... 105
ANEXO A – Técnicas de planejamento e elaboração de diagramas de rede....... 107
ANEXO B – Cálculo da duração das atividades, utilizando a técnica PERT...... 108
ANEXO C – Uma crítica às técnicas CPM e PERT............................................. 109
APÊNDICE A – Exemplos dos recursos de personalização do ERP SAP R/3.... 110
APÊNDICE B – Ordem de Realização ORC Nº 100........................................... 111
GLOSSÁRIO DE ABREVIATURAS E TERMOS............................................. 112
LISTA DE FIGURAS
Figura 1 - Triângulo dos objetivos do projeto........................................................... 23
Figura 2 - Características específicas de projetos, conforme Wideman (1992)........ 24
Figura 3 - Comparação entre as características das atividades em curso e as dos
projetos...................................................................................................
24
Figura 4 - Tipologia de projetos................................................................................ 25
Figura 5 - Relacionamento da Gerência de Projetos com outras disciplinas da
Administração...........................................................................................
26
Figura 6 - As fases do ciclo de vida de um projeto................................................... 28
Figura 7 - O ambiente do projeto, exemplo de alguns fatores que afetam projetos.. 29
Figura 8 - Esquema de um processo.......................................................................... 30
Figura 9 - Processo de detalhamento do escopo....................................................... 33
Figura 10 - Detalhamento do escopo x complexidade no gerenciamento................. 34
Figura 11 - Representação esquemática da EAP....................................................... 36
Figura 12 - Representação de uma EAP para construir uma casa............................. 38
Figura 13 - A hierarquia de planejamento................................................................. 40
Figura 14 - Processo de Definição de Atividades..................................................... 41
Figura 15 - Exemplo de lista de atividades para construção de uma casa................ 42
Figura 16 - Processo de Seqüenciamento de Atividades........................................... 43
Figura 17 - Exemplo de Diagrama de Precedência – DPM...................................... 44
Figura 18 - Representação gráfica dos relacionamentos em um diagrama............... 45
Figura 19 - Desenho de diagrama de rede pelo método ADM.................................. 46
Figura 20 - Resumo comparativos das diferenças dos métodos PDM e ADM........ 46
Figura 21 - Processo de estimativa da duração das atividades.................................. 49
Figura 22 - Processo de desenvolvimento do cronograma........................................ 49
Figura 23 - Convenção dos termos utilizados em diagramas ADM ou AOA........... 50
Figura 24 - Convenção dos termos utilizados em diagramas PDM ou AON........... 51
Figura 25 - Diagrama de Flechas – ADM (exemplo)................................................ 52
Figura 26 - Diagrama de Precedência (PDM) de uma Casa Hipotética.................... 52
Figura 27 - Termos usados em Gerência de Projetos................................................ 53
Figura 28 - Gráfico simples de Gantt (exemplo)....................................................... 56
Figura 29 - Técnica Top-to-Bottom x Bottom-UP……….………………………… 59
Figura 30 - Representação esquemática da integração EAP x Diagramas de Rede.. 60
Figura 31 - Principais fornecedores de software ERP............................................... 63
Figura 32 - Principais módulos do sistema SAP R/3................................................ 64
Figura 33 - Representação esquemática da integração de alguns módulos do SAP
R/3..........................................................................................................
64
Figura 34 - Principais características/conceitos do Sistema SAP R/3...................... 65
Figura 35 - Visão macro do funcionamento do Sistema SAP R/3............................ 67
Figura 36 - EAP do projeto Financial....................................................................... 70
Figura 37 - Etapas do projeto de implementação de um software............................ 71
Figura 38 - Visão da tela de criação da EAP no Sistema SAP R/3........................... 72
Figura 39 - Visão da EAP no Sistema SAP R/3 para PRJ Casa da Figura 12.......... 73
Figura 40 - Visão da EAP no Sistema SAP R/3 para PRJ Financial da
Figura 36................................................................................................
73
Figura 41 - Visão da EAP com responsáveis para PRJ Financial no SAP R/3......... 74
Figura 42 - Visão da seção Datas para EAP do PRJ Financial no SAP R/3............. 74
Figura 43 - Relatório de estrutura no SAP R/3 para a EAP do Projeto Financial.... 75
Figura 44 - Relatório do PRJ Financial exportado para o MS-Excel a partir do
SAP R/3..................................................................................................
75
Figura 45 - PRJ Financial criado em MS-Excel a partir do SAP R/3...................... 76
Figura 46 - EAP do PRJ Casa - Figura 12 na forma de árvore no SAP R/3............ 76
Figura 47 - EAP do PRJ Financial na forma de árvore no SAP R/3........................ 77
Figura 48 - Exemplo de construção de códigos de PEP para uma EAP no
SAP R/3...................................................................................................
77
Figura 49 - Exemplo de uma EAP modelo no SAP R/3........................................... 78
Figura 50 -Exemplo de criação do PRJ S.500 a partir de uma EAP modelo no
SAP R/3..................................................................................................
78
Figura 51 - Criação do PRJ S.500 a partir do modelo Z.XXX no SAP R/3 –
Passo 1.....................................................................................................
79
Figura 52 - Criação do PRJ S.500 a partir do modelo Z.XXX no SAP R/3 –
Passo 2....................................................................................................
79
Figura 53 - PRJ S.500 criado a partir do modelo Z.XXX no SAP R/3..................... 80
Figura 54 - Visão da tela de criação de Diagramas e Cronogramas no
SAP R/3..................................................................................................
81
Figura 55 - Diagrama de Precedência para PRJ Casa no SAP R/3........................... 82
Figura 56 - Diagrama de Precedência para PRJ Financial no SAP R/3................... 83
Figura 57 - Detalhe das atividades no diagrama no SAP R/3 da Figura 56............. 84
Figura 58 - Legenda das atividades no diagrama no SAP R/3.................................. 84
Figura 59 - Lista dos diagramas precedência criados no SAP R/3 para PRJ
Financial................................................................................................
85
Figura 60 - Tipo de relações possíveis em diagramas no SAP R/3........................... 86
Figura 61 - Relação de Fim-Início em diagramas no SAP R/3................................. 86
Figura 62 - Relação de Início-Fim em diagramas no SAP R/3................................. 86
Figura 63 - Relação de Início-Início em diagramas no SAP R/3.............................. 87
Figura 64 - Relação de Fim-Fim em diagramas no SAP R/3.................................... 87
Figura 65 - Diagrama de Gantt para Casa da Figura 55 no SAP R/3........................ 88
Figura 66 - Diagrama de Gantt para PRJ Financial da Figura 56 no SAP R/3........ 89
Figura 67 - Transferência do diagrama de rede do SAP R/3 para MS-Project –
Passo 1....................................................................................................
90
Figura 68 - Transferência do diagrama de rede do SAP R/3 para MS-Project –
Passo 2....................................................................................................
90
Figura 69 - Transferência do diagrama de rede do SAP R/3 para MS-Project –
Passo 3....................................................................................................
91
Figura 70 - Diagrama de rede do SAP R/3 do PRJ Financial transferido para MS-
Project....................................................................................................
91
Figura 71 - Comando para buscar datas para EAP nos diagramas no SAP R/3....... 92
Figura 72 - Datas programadas da EAP atualizada com datas dos diagramas -
SAP R/3..................................................................................................
92
Figura 73 - Comando programar prazos da EAP no SAP R/3................................. 93
Figura 74 - EAP com programação atualizada - SAP R/3........................................ 93
Figura 75 - EAP PRJ Financial, detalhe das opções de programação..................... 94
Figura 76 - Comando para visualizar cronograma no SAP R/3 a partir da EAP...... 94
Figura 77 - Cronograma do PRJ Financial visualizado a partir da EAP no
SAP R/3...................................................................................................
95
Figura 78 - Comando para buscar ou anexar documento a elemento da EAP no
SAP R/3..................................................................................................
95
Figura 79 - Visualizando o documento a partir da EAP no SAP R/3....................... 96
Figura 80 - Documento ORC-100 aberto no Ms-Word a partir da EAP no SAP R/3..................................................................................................
96
Figura 81 - Árvore de relatórios do SAP R/3 sobre estruturas.................................. 97
Figura 82 - Relatórios do grupo Sínteses Individuais da árvore de relatórios
Estruturas do SAP R/3...........................................................................
98
Figura 83 - Relatório Síntese de Estruturas do SAP R/3 – tela de entrada.............. 98
Figura 84 - Relatório Síntese de Estruturas do projeto S.100.................................. 99
Figura 85 - Principais comandos do relatório de Estrutura do SAP R/3................... 99
Figura 86 - Principais símbolos utilizados no relatório de Estrutura do SAP R/3.... 100
Figura 87 - Características desejadas dos softwares para Gestão de Projetos
segundo Keelling x recursos do SAP R/3..............................................
101
Figura 88 - Durações probabilísticas......................................................................... 108
Figura 89 - Exemplos dos recursos de personalização do ERP SAP R/3................. 110
Figura 90 - Documento ORC-100 na simulação do item 4.5................................... 111
1 INTRODUÇÃO
Nos últimos anos a aplicação das técnicas de Gestão de Projetos, tem ganhado
cada vez mais espaço nas organizações em todo mundo. Estas técnicas consagradas e
em constante evolução, são aplicadas por profissionais no mundo todo, denominados
Project Managers (Gerentes de Projeto). Resultado da associação dos profissionais da
área com objetivo de difundir, consolidar e ampliar os conhecimentos e técnicas para o
exercício desta profissão, que cresce cada vez mais no mercado mundial. Na década de
oitenta foi fundado, nos Estados Unidos da América, o Project Management Institute –
PMI®, o qual publica e tem reservado os direitos autorais da obra A Guide to the
Project Management Body of Knowledge ou, simplesmente, como é mais conhecido,
PMBOK®. O PMBOK® é uma obra de síntese das técnicas e práticas consagradas e
utilizadas na Gestão de Projetos em todo mundo, um guia para os profissionais do ramo.
Atualmente as organizações, além de utilizar profissionais com conhecimento
nas técnicas de Gestão de Projetos (Project Manager), têm utilizado cada vez mais a
tecnologia da informação, principalmente os pacotes de software conhecidos como
Enterprise Resources Planning - ERP, ou seja, em português Planejamento de Recursos
Empresariais ou simplesmente ERP.
A utilização dos ERP tem se tornado uma realidade presente, em diversas
organizações no mundo e no Brasil.
Os Gerentes de Projeto (Project Managers), assim como os demais funcionários
nas organizações, também interagem com esta moderna ferramenta de apoio à Gestão
das Organizações no desempenho das suas atividades profissionais. Assim, os sistemas
ERP tendem a, cada vez mais, desempenharem um papel de relevância no sucesso ou
não da execução das atividades dos Gerentes de Projeto (Project Managers) nas
organizações contemporâneas.
Partindo desta perspectiva ampla, se formulou a proposta de realizar este estudo,
cujo objetivo foi analisar a aderência dos sistemas ERP às técnicas de Gestão de
Projetos formalizadas no PMBOK®, relacionadas à Gerência do Escopo e Gerência do
Prazo do Projeto.
16
1.1 OBJETIVOS
1.1.1 Objetivo Geral
Verificar a aderência dos sistemas ERP às técnicas de Gestão de Projetos nas
dimensões:
• Divisão dos pacotes de trabalho – Estrutura do Projeto;
• Planejamento físico dos projetos.
Conforme definições nas seções dos capítulos 5 e 6 do PMBOK 2000.
1.1.2 Objetivos Específicos
Avaliar a aderência, a facilidade e as possíveis limitações do sistema tipo ERP
por meio da realização de simulação no ERP SAP R/3, das técnicas de elaboração de
Estrutura Analítica do Projeto (EAP) ou Work Breakdown Structure (WBS), construção
dos diagramas de redes utilizando a técnica Critical Path Method (CPM), elaboração
dos cronogramas do projeto, na forma de gráfico de barras ou de Gantt, a existência de
relatórios de apoio e, quando possível, propor sugestões para melhor utilização dos
recursos disponíveis no sistema SAP R/3.
1.2 DELIMITAÇÃO DO ESTUDO
O presente estudo se limita a estudar como os sistemas ERP atendem ou não as
necessidades dos Gerentes de Projetos (Project Managers), de acordo com os seguintes
capítulos do PMBOK 2000 (tradução para o português realizada pelo PMI-MG):
Cap. 5 – Gerenciamento do Escopo do Projeto, com ênfase principalmente nas
seções 5.1 a 5.3;
Cap. 6 – Gerenciamento do Prazo do Projeto.
Não fazem parte do escopo deste trabalho os demais capítulos do PMBOK 2000
e nem o estudo da Gestão de Projetos utilizando ERP em todos os seus recursos.
Também não faz parte do escopo deste estudo, a análise dos impactos das
decisões tomadas pelos Gerentes de Projeto e a utilização de ERP nas outras áreas da
organização, bem como as relações diretas do Gerente de Projeto com outros
17
profissionais da organização, sejam ou não mediadas pela utilização de sistemas do tipo
ERP.
1.3 RELEVÂNCIA DO ESTUDO
Este estudo procura responder a questão: Os sistemas do tipo ERP realmente
suportam as técnicas de elaboração de EAP, cronogramas e diagramas de rede que são
utilizadas pelos Gerentes de Projetos para realizarem seus trabalhos?
Responder esta questão ganha relevância, à medida que as técnicas de Gestão de
Projetos são anteriores aos softwares ERP, mas hoje os mesmos têm sido empregados
cada vez mais nas organizações em conjunto com as técnicas de Gestão de Projetos.
Com isto, se os sistemas ERP forem adequados para utilização das técnicas de Gestão
de Projetos, os mesmos podem se tornar uma poderosa ferramenta para aumentar a
eficácia e eficiência da ação dos Gerentes de Projeto nas organizações, caso contrário,
se tornam mais um obstáculo a ser superado.
1.4 ORGANIZAÇÃO DO TRABALHO
O trabalho foi dividido em partes, a saber: revisão da literatura; metodologia;
resultados e discussão; conclusão e perspectivas para novos trabalhos, sendo a revisão
da literatura dividida em sub-tópicos, para permitir ao leitor adquirir, de forma
gradativa, conhecimento das teorias e estudos sobre o tema abordado.
A revisão da literatura se inicia com o estudo da teoria sobre Gestão de Projetos
numa perspectiva ampla, seguida pela revisão das técnicas de Gestão de Projetos
pertinentes ao escopo deste trabalho e finaliza-se com o estudo dos programas tipo ERP,
seus fundamentos e conceitos relacionados ao escopo da presente dissertação.
Após a revisão da literatura, apresentam-se a metodologia de pesquisa e as
técnicas utilizadas para avaliar a aderência ou não das técnicas de Gestão de Projetos
pelos programas do tipo ERP analisadas neste trabalho.
Em seguida à exposição da metodologia utilizada, na parte quatro tem-se a
apresentação dos resultados da simulação da gestão de um projeto utilizando um
programa tipo ERP, com as técnicas de Gerência do Escopo e Gerência do Prazo, ao
18
mesmo tempo em que se realiza a discussão e interpretação dos resultados à luz da
teoria revisada. Na parte cinco apresenta-se a conclusão dos estudos e simulações
realizados. Finalizando o trabalho, na parte seis, se apresentam as perspectivas abertas
com a realização deste estudo e a indicação de potenciais áreas para aprofundamento ou
temas correlatos que podem ser explorados em trabalhos futuros, estendendo-se, nas
referências utilizadas para elaboração desta dissertação.
2 REVISÃO DA LITERATURA
2.1 A Gerência de Projetos, uma visão geral
Para se atingir o objetivo deste trabalho, que foi estudar a aderência dos sistemas
ERP às técnicas de Gestão de Projetos nas dimensões: dividir pacotes de trabalho,
planejamento físico e relatórios para acompanhamento da evolução dos projetos,
utilizando-se recursos do ERP, fez-se necessário conhecer o básico sobre o que é
Gerência de Projetos e o que são Projetos. A compreensão destes dois conceitos chaves
é indispensável para se compreender o contexto do presente estudo, analisar as variáveis
envolvidas e sua importância. Assim, partindo-se destas premissas, os próximos itens
apresentam um panorama histórico, sucinto, da evolução da Gerência de Projetos e a
definição de alguns conceitos chaves que compõem esta área de estudo.
2.1.1 A Gerência de Projetos, numa perspectiva histórica
O campo de estudo compreendido hoje sob a denominação de Gerência de
Projetos é amplo, mas a história de sua construção como se conhece e define atualmente
é recente. Segundo Cleland e Ireland (2002, p.5), “[...] a gerência de projetos, existe ha
mais de 50 anos, e vem sendo praticada em diversificados ramos de negócios e se
firmando como uma disciplina, o que representa uma promessa para o futuro das
organizações”. Um campo de estudo com uma história não maior do que 50 anos é
recente, se comparado com os campos de estudo das ciências mais tradicionais, mesmo
as mais recentes como, por exemplo, a Psicologia e a Administração, cujos fundamentos
já possuem alguns séculos de história. Embora a metodologia utilizada na Gerência de
Projetos seja milenar, como se encontra no trabalho de Keelling (2002, p.3):
[...] Projetos têm sido realizados desde a aurora dos tempos, mas nos últimos anos a gestão de projetos tem evoluído, alcançando novos patamares de sofisticação e popularidade. A maioria dos projetos das civilizações antigas era relacionada a poder, religião ou construção de grandes monumentos. O custo, cuja importância é hoje dominante, significava muito pouco para os déspotas do passado, e o tempo, agora tão valioso e estreitamente ligado ao custo do projeto, era de importância secundária. Eram raras as ocasiões em que o prazo seria sinônimo de sucesso. Na quinta dinastia, uma pirâmide no Egito, em Abusir, não foi concluída a tempo para a morte de seu patrocinador, e acabou sendo usada para abrigar os restos de outro dignitário.
20
Esse desdém pelo prazo se aplicou também a construção das grandes catedrais. A obra se estendia por centenas de anos e sucessivas gerações de pedreiros eram empregadas em sua edificação. As considerações então dominantes eram beleza, durabilidade da estrutura e qualidade da mão-de-obra. Com o passar dos anos, custo e prazo assumiram importância cada vez maior. Um estudo das grandes habitações da Europa conta muitas histórias tristes de proprietários ambiciosos que, não conseguindo realizar o planejamento financeiro, foram reduzidos à pobreza pela escalada no custo do projeto.
A disciplina ou campo de estudo que hoje se denomina Gerência de Projetos é
obra contemporânea, como se encontra em Cleland e Ireland (2002, p.5) “a disciplina
(Gerência de Projetos) surgiu de maneira modesta na década de 1950. Seus primeiros
passos podem ser encontrados na indústria de construção e, mais recentemente, na área
de materiais bélicos e de desenvolvimento de sistemas”.
Apesar de ser uma disciplina com pouco tempo de existência, a Gerência de
Projetos é reconhecida no mundo empresarial, premissa que encontra suporte no estudo
de Kerzner (2000, p.17): “[...] percebe-se que o mundo empresarial passou a reconhecer
a importância da gestão de projetos, tanto para o futuro quanto no presente”.
Uma outra indicação da importância da Gerência de Projetos no mundo moderno
e de sua popularidade se encontra no trabalho de Cleland e Ireland (2002, p.22):
A Gerência de Projetos tem várias associações profissionais no mundo inteiro, que vão desde algumas centenas de membros a muitos milhares. A maior e mais conhecida dentre elas é o Project Manager Institute (PMI®), em Newton Square, Pensilvânia, com mais de 48.000 membros, em seis dos sete continentes.
Segundo Cleland e Ireland (2002, p.22-23) o Project Manager Institute (PMI)
foi fundado em 1969, por seis pessoas, para promover a Gerência de Projetos. Ainda
segundo os mesmos autores, o PMI tem cinco competências principais:
• Certificação – Programa de Certificação dos profissionais do Project Manager Professional (PMP®). Este programa destina-se a testar o conhecimento das pessoas nas funções de gerência de projetos, determinar a sua experiência nesse ramo e estabelecer expectativas éticas mediante códigos de ética.
• Educação: programa para fornecer treinamento em gerência de projetos, tanto a membros quanto a não membros, no mundo inteiro. Esse programa amplia e intensifica as capacitações individuais para a gerência de projetos.
• Publicações: desenvolvimento e distribuição das informações baseadas no conhecimento da gerência de projetos. Esses meios incluem periódicos mensais, como jornais e uma revista técnica, e um jornal trimestral especializado recomendado pelo PMP®.
• Pesquisas: realização de investigações nas práticas atuais de gerência de projetos e nas necessidades futuras de sua
21
metodologia e técnicas. Os trabalhos de pesquisa também incluem o trabalho de cooperação com outras associações de projetos no mundo inteiro.
• Padrões: desenvolvimento e distribuição de uma metodologia e de práticas coerentes de gerência de projetos para praticantes no mundo inteiro. O único padrão que tem sido aceito em todos os países é A Guide to the Project Management Body of Knowledge (Guia PMBOK®).
A história do desenvolvimento do campo de estudo da Gerência de Projetos e de
suas técnicas, apesar de breve, é um campo de estudo que apresenta crescimento
acelerado na amplitude de organizações que as utilizam e dos profissionais capacitados
nas mesmas nas últimas décadas, talvez parte deste crescimento se deva aos fatores
identificados no trabalho de Vargas (2002, p.3):
Para atender a demanda de maneira eficaz, em um ambiente caracterizado pela velocidade das mudanças, torna-se indispensável um modelo de gerenciamento baseado no foco em prioridades e objetivos. Por essa razão, o gerenciamento de projetos tem crescido de maneira tão acentuada no mundo nos últimos anos [...].
Ainda segundo Vargas (2002, p.5), “outro fator que impulsiona o gerenciamento
de projetos é o crescimento da competitividade. Quem for mais rápido e competente
certamente conseguirá melhores resultados [...]”.
Corroborando as análises anteriores sobre a razão do crescimento da gerência de
projetos, se encontra no trabalho de Kerzner (2000, p.29):
Desde o começo da década de 1990, a corrida pela excelência na gestão de projetos tem assumido importância cada vez maior. Os benefícios da gestão de projetos são óbvios hoje tanto para os clientes quanto para os fornecedores. De fato a excelência em gestão de projetos se tornou uma arma competitiva que atrai novos negócios e mantém os clientes tradicionais.
Após entender as razões da Gerência de Projetos ser um campo de estudo que
cresce rapidamente, e amplia sua aplicação e utilidade no mundo industrial moderno, se
faz necessário compreender os conceitos principais desta nova área de conhecimento,
sendo que antes de tudo como afirmado por Kerzner (2000, p.17), “para entender de
gestão projetos, em primeiro lugar é preciso saber reconhecer o que é projeto [...]”.
No próximo tópico se definirá o que é projeto e outros conceitos básicos da
Gerência de Projetos, ou seja, se buscará responder a questões como: qual a definição de
Gerência de Projetos, seu escopo e áreas de estudo? Quais seus objetivos? O que são
Projetos? Sem a compreensão destes e outros conceitos básicos, não é possível
22
compreender a Gerência de Projetos e atingir o objetivo do presente trabalho que foi
estudar a aderência dos sistemas ERP as técnicas de Gestão de Projetos nas dimensões:
dividir pacotes de trabalho; planejamento físico das encomendas e relatórios para
acompanhamento da evolução dos projetos.
2.1.2 Gerência de Projetos: conceitos e área de conhecimento
Segundo o PMBOK 2000 (2002, p.4): “Projeto é um empreendimento
temporário com o objetivo de criar um produto ou serviço único”.
A definição de projeto encontrado no PMBOK 2000 implica, conforme Keelling
(2002, p.3), em: “[...] um prazo limitado, uma data estipulada para conclusão e um
resultado diferente daquele produzido no curso da rotina operacional”.
Uma definição mais elaborada do que seja projeto, e que parece englobar a
definição que se encontra no PMBOK 2000 e as observações de Keelling é a encontrada
no trabalho de Vargas (2002, p.8):
Projeto é um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade.
Ambas as definições anteriores enfatizam o fato de que um empreendimento
somente será um projeto se for realizado com o objetivo de criar um produto ou serviço
único e possuir duração finita, ou seja, prazo determinado para sua execução,
características que separam, de forma clara, os empreendimentos considerados projetos
dos demais.
Estas características são bem enfatizadas na conceituação de projeto encontrada
no trabalho de Kerzner (2000, p.17) ao definir projeto como: “[...] trata-se de um
empreendimento com objetivo identificável, que consome recursos e opera sob pressões
de prazos, custos e qualidade [...]”. Está concepção é corroborada por Slack, Chambers
e Johnston (2002, p.518):
Os projeto como qualquer outra operação, podem ser julgados em termos dos cinco objetivos de desempenho [...] qualidade, rapidez, confiabilidade, flexibilidade e custo. Entretanto, flexibilidade é vista como “dada” em muitos projetos que, por definição, são em alguma medida, únicos e velocidade e confiabilidade estão comprimidas em um objetivo composto – “tempo”. Isso resulta no que é conhecido
23
como os “três objetivos do gerenciamento de projeto” – custo, tempo e qualidade.
Na Figura 1 apresenta-se, de forma esquemática o triângulo dos objetivos dos projetos.
Custo Tempo
Qualidade
Figura 1 – Triângulo dos objetivos do projeto Fonte: Adaptado de Slack, Chambers e Johnston (2002, p.519)
Por meio das definições anteriores e do conceito de triângulo dos objetivos do
projeto, pode-se compreender a razão pela qual os projetos realizados na antiguidade,
como a construção de pirâmides, catedrais e outras grandes obras, não são considerados
projetos no sentido moderno: porque as mesmas não incluíam preocupações e
metodologias sistemáticas para atingir metas pré-definidas de custos, prazo e qualidade,
mas basicamente buscavam atender aos gostos pessoais e ao senso de beleza estética
dos proprietários. De qualquer forma, isto não impediu, que a antiguidade nos legasse
construções consideradas verdadeiras obras de engenharia, arquitetura e engenhosidade
humana, mas certamente foram empreendimentos que, em muito extrapolaram suas
previsões de custos e tempo iniciais.
Complementando as definições anteriores discutidas, segundo Wideman (apud
Vargas 2002, p.17), os projetos apresentam várias características específicas que
necessitam de atenção especial, conforme Figura 2, e no trabalho de Keelling (2002,
p.5) se encontra uma comparação entre as características das atividades em curso ou
contínuas da administração de empreendimentos ou organizações e as dos projetos, as
quais foram resumidas na Figura 3.
24
Característica Função
Raridade A definição dos objetivos do projeto faz com que ele seja único, ou relativamente pouco freqüente.
Restrições Tempo limitado Capital limitado Recursos limitados
Multidisciplinaridade
Os esforços realizados entre áreas diferentes da organização, ou entre organizações requerem integração. O trabalho interdisciplinar necessita de coordenação através dos limites organizacionais. Diversas habilidades podem requerer coordenação específica.
Complexidade
Objetivos divergentes entre as partes envolvidas no projeto necessitam de gerenciamento. A tecnologia pode ser modificada em métodos e análises. A tecnologia pode ser complexa por si mesma.
Figura 2: Características específicas de projetos, conforme Wideman (1992) Fonte: Wideman (apud Vargas 2002, p.17)
A análise dos conceitos apresentados nas Figuras 2 e 3 permite concluir que os
projetos são diferentes e independentes das operações rotineiras nas organizações, em
razão de suas características específicas. Além disto, um outro conceito importante que
diferencia os projetos das operações rotineiras, é a singularidade. Este conceito está
presente nas definições apresentadas anteriormente do que são projetos e subentendido
na descrição das características. É por causa do conceito de singularidade que uma
pessoa pode gerenciar a construção de dezenas de casas ao longo de sua vida, mas cada
um delas será um projeto único, o qual exigira sempre ações especificas.
Característica Projeto Rotinas contínuas, de longo prazo
Perspectivas Limitadas Planejamento de longo prazo dominante, estratégias e funções de longo prazo.
Objetivos Precisos Planejamento de longo prazo dominante, estratégias e funções de longo prazo.
Tempo/Duração Fixa (pré-determinado) Amplos relacionados à sobrevivência e/ou RSI de longo prazo.
Planejamento Resultado de planejamento
previsíveis e precisos
Flexibilidade de estratégias, táticas e utilização de recursos.
Tomada de Decisão Controle dominante Decisões estruturadas, poucas restrições,
perspectiva muda. Figura 3: Comparação entre as características das atividades em curso e as dos projetos Fonte: Adaptado de Keelling (2002, p.5)
25
Por fim, um último conceito que não se pode omitir é a existência de muitos
tipos de projeto, o que se costuma denominar de tipologia de projetos. Segundo Slack,
Chambers e Johnston (2002, p.513): “a tipologia ajuda a dar um formato racional à
vasta gama de tarefas na qual os princípios do gerenciamento do projeto podem ser
aplicados”.
Na Figura 4 se apresenta uma ilustração de tipologia de projetos encontrada em
Slack, Chambers e Johnston (2002, p.513):
(de
cust
os, t
écni
ca, p
rogr
amas
).
INC
ER
TE
ZA
Tratado de Maastricht
Campanha das Nações Unidas
Túnel do Canal da Mancha
Espaçonave
Airbus
Campanha Militar
Comporta do Tâmisa
Fábrica de carros
Auto- Estrada
Transportador de petróleo
Indústria química
o
Auditoria de empresa
o
Campanha Publicitária
Escrita de um romance
Desenvol- vimento de produto
Exploração de óleo e gás
Expedição à Antártica
Pesquisa básica
Individual
Baixa Figura 4: Tipologia deFonte: Adaptado Slack
Observando-se
podem ser aplicadas a
de características com
fatores como: ambiente
Uma vez defin
sua área de conhecim
conceituadas, respect
conhecimentos, habilid
requerimentos do proje
Casament
Grupo Organização
COMPLEXIDA projetos , Chambers e Johnston (200
a Figura 4 se verifica qu
uma variada gama de proje
o incerteza e complexidade
s, objetivos e amplitude do
ido o que é projeto, é possí
entos, as quais, segundo
ivamente, como: “Gerênc
ades e técnicas para proje
to [...]” e as áreas de conhec
Aeroport
Alta
Baixa
Multi- Nacional Multinacional -OrganizaçãoDE Alta
2, p.513)
e as técnicas de Gestão de Projetos
tos, que terão diferentes combinações
, as quais irão variar em função de
projeto.
vel se definir Gerência de Projetos e
o PMBOK 2000 (2002, p.6-7) são,
ia de Projetos é a aplicação de
tar atividades que visam a atingir os
imento da Gerência do Projeto:
26
[...] descreve os conhecimentos e práticas em Gerência de Projetos em termos dos processos que as compõem. Estes processos foram organizados em nove áreas de conhecimento como descrito abaixo[...]: • [...] Gerência da Integração do Projeto [...]; • [...] Gerência do Escopo do Projeto [...]; • [...] Gerência do Tempo do Projeto [...]; • [...] Gerência do Custo do Projeto [...]; • [...] Gerência da Qualidade do Projeto [...]; • [...] Gerência dos Recursos Humanos do Projeto [...]; • [...] Gerência da Comunicação do Projeto [...]; • [...] Gerência dos Riscos do Projeto [...]; • [...] Gerência da Aquisição do Projeto [...].
Outra maneira de definir Gerência de Projetos é a encontrada no trabalho de
Keelling (2002, p.3): “A Gestão de Projetos pode ser definida como o planejamento,
programação e controle de uma série de tarefas integradas de forma a atingir seus
objetivos com êxito, para beneficio dos participantes do projeto”.
Além disto no PMBOK 2000 (2002, p.9), se encontra a Figura 5, que apresenta
de forma esquemática o relacionamento das áreas de conhecimento de projetos com
outras áreas.
Universo de Conhecimento da
Gerência de Projetos
Conhecimentos e Práticas da Gerência
de Projetos
geralmente aceitas.
Conhecimentos e
Práticas de Gerência
Geral
Conhecimentos e Práticas das
Áreas de
Aplicação
Figura 5: Relacionamento da Gerência de Projetos com outras disciplinas da Administração (Está figura é uma visão conceitual desses relacionamentos. As sobreposições mostradas não são proporcionais) Fonte: PMBOK 2000 (2002, p.9)
27
Assim se finaliza a elaboração do plano geral da área de conhecimento
denominada Gerência de Projeto. No próximo item, se apresenta um estudo sucinto do
contexto da Gerência de Projetos no mundo atual, onde se procura desenhar um
panorama global, o qual complementará os conceitos vistos até aqui. Assim, se
permitirá aos leitores não ligados diretamente a esta área de conhecimento, obter uma
visão mais abrangente do papel desempenhado pela Gerência de Projetos na atualidade,
além de facilitar a compreensão dos demais conceitos que serão explorados a partir do
item 2.2 e seguintes, relacionados com o objetivo deste trabalho.
2.1.3 A Gerência de Projetos num contexto mais amplo
Os Projetos e os esforços para Gerenciar os Projetos, são empreendimentos
realizados nas e/ou para a sociedade ou organizações, concomitantemente com outras
atividades e às vezes compartilhando recursos com outros projetos e/ou
empreendimentos. Por causa deste contexto mais amplo, se torna importante possuir
uma visão mais abrangente quando se trabalha com projetos, necessidade esta também
identificada no PMBOK 2000 (2002, p.11):
Tanto projetos quanto a gerência de projetos se inserem num ambiente bem mais amplo do que o projeto propriamente dito. A equipe de gerência do projeto deve compreender este contexto mais amplo – a gerência das atividades diárias do projeto é necessária, mas não suficiente para o seu sucesso [...]. [...] Como os projetos possuem um caráter único, a eles está associado um certo grau de incerteza. As organizações que desenvolvem projetos usualmente dividem-nos em várias fases visando um melhor controle gerencial e uma ligação mais adequada de cada um dos projetos aos seus processos operacionais contínuos. O conjunto das fases de um projeto é conhecido como ciclo de vida do projeto.
Embora a definição do ciclo de vida dos projetos não seja algo rígido, pois
existem variações na definição deste conceito, às vezes as variações se devem ao tipo de
projeto. Valeriano (1998, p.23 e 24) reconhece a variação e propõem um modelo geral:
Há diferentes versões para o ciclo, desde as que contêm umas poucas fases até aquelas de mais de uma dezena, dependendo do que, arbitrariamente se considera como uma fase distinta ou um componente de uma delas. Mas convencionou-se chamar de ciclo de vida genérico de um projeto à seqüência de quatro fases, às quais podem ser reduzidos os demais ciclos: • Fase conceptual, que inclui atividades que vão desde a idéia
inicial do produto, ou assunto a pesquisar, passando pela
28
elaboração de uma proposta e chegando até a aprovação. • Fase de planejamento e organização, em que o projeto é
planejado e organizado com as minúcias necessárias à execução e ao controle.
• Fase de implementação, na qual os trabalhos da equipe do projeto são levados a efeito, sob a coordenação e liderança do gerente, até a obtenção do objetivo, compreendendo a execução propriamente dita das tarefas e o controle desta execução.
• Fase de encerramento, em que se efetiva a transferência dos resultados do projeto, com aceitação do seu cliente, seguida de uma avaliação geral do projeto e, por fim, da desmobilização dos meios e recursos postos a disposição do projeto.
Ritzman e Krajewski (2004, p.69) também dividem o ciclo de vida dos projetos
em quatro fases, denominadas: Definição e Organização, Planejamento, Execução e
Encerramento. Outros estudiosos que dividem o ciclo de vida dos projetos em quatro
fases são: Keelling (2002, p.15): “as fases (estágios) do ciclo de vida do projeto são: (1)
Conceituação; (2) Planejamento; Implementação (execução); e (4) Conclusão” e
Cleland e Ireland (2002, p.190) para os quais o ciclo de vida do projeto são: Fase 1
Conceitual; Fase 2 Planejamento; Fase 3 Desenvolvimento e Fase 4 Finalização, além
disto Kerzner (2000, p.96), afirma: “[...] entre as características de uma metodologia de
expressão mundial, destacam-se: máximo de seis fases de ciclo de vida; superposição de
fases do ciclo de vida; revisões final de fase [...]”.
Em vista do exposto, parece válido concluir que utilizar um modelo de quatro
fases para o ciclo de vida do projeto está de acordo com a prática da maioria das
organizações e com as melhores práticas utilizadas para gestão de projetos, além de
poder ser aplicado a uma ampla gama de tipos de projetos.
A Figura 6 apresenta o modelo genérico de ciclo de vida de quatro fases de um
projeto proposto por Valeriano (1998, p.24).
Figura 6 – As fases do ciclo de vida de um projeto Fonte: Valeriano (1998, p. 24)
29
Dois fenômenos importantes a serem observados sobre o ciclo de vida do
projeto, são: primeiro, observando a Figura 6, se constata que as fases se sobrepõem
umas às outras, e, em segundo lugar, é à observação encontrada no PMBOK 2000
(2002, p.12) sobre a capacidade de se influenciar o resultado do projeto:
A capacidade das partes envolvidas de influenciar as características finais do produto do projeto e o seu custo final, é alta no início e vai se reduzindo com o andamento do projeto. Isto acontece, principalmente porque o custo de mudanças e correção de erros geralmente aumenta à medida que o projeto se desenvolve.
Mas o que foi visto até aqui está inserido em um contexto mais abrangente, o
qual denomina-se Ambiente do Projeto; segundo Slack, Chambers e Johnston (2002,
p.516) “o ambiente do projeto compreende todos os fatores que podem afetar o projeto
durante a sua vida. Ele determina o cenário e as circunstâncias nas quais o projeto é
executado”.
Na Figura 7 apresentam-se, de forma esquemática, exemplos de alguns fatores
do ambiente que afetam um projeto, adaptado de Slack, Chambers e Johnston (2002,
p.517).
AMBIENTE
Fornecedores
Economia Governo
Estratégia da Empressa
Concorrentes Recursos
O
PROJETO
Clientes
Cultura Nacional
Figura 7 – O ambiente do projeto, exemplo de alguns fatores que afetam projetos Fonte: Adaptado de Slack, Chambers e Johnston (2002, p.517)
30
Observando a Figura 7, é possível visualizar vários fatores que compõem o
ambiente e que podem afetar o projeto.
Além de o ambiente possuir uma série de fatores que podem afetar os projetos,
outro conceito importante é o que se denomina de partes envolvidas do projeto, que
conforme o PMBOK 2000 (2002, p.16): “são indivíduos e organizações diretamente
envolvidos no projeto, ou aqueles cujos interesses podem ser afetados, de forma positiva
ou negativa, no decorrer do projeto ou mesmo após a sua conclusão [...]”.
Uma outra inferência possível, analisando-se as Figuras 4, 6 e 7, é que a força
dos fatores ambientais pode variar conforme o tipo e fase que o projeto se encontra.
Alguns fatores terão mais influencia em determinados tipos de projetos do que em
outros, ou em determinadas fases do que em outras; estes e os outros aspectos
relacionados com a Gerência de Projetos devem sempre ser levados em consideração
quando se trabalha com projetos.
O ultimo conceito a ser formalizado, é o conceito de processo e suas partes
constituintes que segundo Valeriano (1998, p.6-7):
Entende-se por processo um conjunto de recursos e atividades inter-relacionadas (os subprocessos) que transformam insumos em produtos ou resultados. Os insumos são genericamente chamados de entrada (input) e os produtos, de saídas (output). Insumo é tudo aquilo que é fornecido ao processo [...]. Um produto ou resultado pode ser: tangível [...], intangível [...] e intencional [...] ou não intencional [...]. [...] Denomina-se processamento o conjunto das ações que realizam as transformações dos insumos em produtos ou resultados e processador é qualquer parte interna do processo que desempenha estas ações. Então, sinteticamente, o processo consiste no emprego de insumos, que passam por um processamento, para produzir resultados [...].
Na Figura 8, a representação esquemática de um processo segundo Valeriano
(1998, p.6).
Figura 8 – Esquema de um processo
Saída Entrada Processamento (s) Processador (es) ou Insumos ou Resultados
Fonte: Valeriano (1998, p.6)
Quando se citar o termo processo no presente trabalho, sempre se realizará
segundo a definição acima.
31
Concluída a formulação de uma visão geral de Gerência de Projetos e do que são
projetos, bem como, os conceitos chaves para compreensão desta área do conhecimento,
no próximo item (2.2) se inicia o estudo dos conhecimentos e técnicas para
Gerenciamento do Escopo dos Projetos, o qual é um dos sub-itens que compõem o
objetivo deste trabalho.
2.2 Gerenciamento do escopo do Projeto – divisão dos pacotes de trabalho
2.2.1 Gerenciamento do escopo do Projeto – uma visão geral
Segundo o PMBOK 2000 (2002, p.51):
A Gerência do escopo do Projeto abrange os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário, para complementar de forma bem sucedida o projeto. A preocupação fundamental compreende definir e controlar o que está, ou não, incluído no projeto. Principais processos da gerência do escopo de projetos: Iniciação – autorizar o projeto ou fase. Planejamento do escopo – desenvolver uma declaração escrita do escopo como base para as decisões futuras do projeto. Detalhamento do escopo – subdividir os principais subprodutos do projeto em componentes menores e mais manejáveis. Verificação do escopo – formalizar a aprovação do escopo do projeto. Controle da mudança do escopo – controlar a mudança do escopo do projeto.
Já em Vargas (2002, p.56) se encontra a seguinte definição:
Gerenciamento de escopo tem como objetivo principal definir e controlar os trabalhos a serem realizados pelo projeto de modo a garantir que o produto, ou serviço, desejado seja obtido através da menor quantidade de trabalho possível, sem abandonar nenhuma premissa estabelecida no objetivo do projeto.
Ambas definições expressam a mesma preocupação, ou seja, o gerenciamento do
escopo tem por finalidade ultima garantir que o projeto entregará o produto que foi
solicitado, e nada além disto. Para se compreender as definições anteriores sobre
gerência do escopo, se faz necessário definir o que seja escopo. O PMBOK 2000 (2002,
p.51), define escopo do projeto dividindo-o em duas partes:
Escopo do produto: aspectos e funções que caracterizam um produto ou serviço. Escopo do projeto: o trabalho que deve ser feito com a finalidade de fornecer um produto de acordo com os aspectos e as funções especificados.
32
Para Vargas (2002, p.56): “[...] escopo do projeto é definido como o trabalho
que precisa ser desenvolvido para garantir a entrega de um determinado produto dentro
de todas as suas especificações e funções”.
Vargas (2002, p.57) também propõe que o escopo do projeto possa ser
subdividido em:
Escopo funcional – conjunto de características funcionais do produto ou serviço, a ser desenvolvido pelo projeto, tais como capacidade, mercado, filosofia etc. Escopo técnico - características técnicas do projeto, destacando os padrões e as especificações a serem utilizadas. Escopo de atividades – trabalho a ser realizado para prover os escopos técnico e funcional do produto, ou serviços, do projeto, normalmente evidenciado na Estrutura Analítica do Projeto ou WBS.
Analisando-se a definições de escopo anteriores, se pode afirmar que o escopo
funcional e técnico definido por Vargas corresponde ao escopo do produto definido pelo
PMBOK 2000, enquanto que o escopo de atividades é equivalente ao escopo do projeto.
Uma maneira de definir escopo de forma bastante sucinta e objetiva é
encontrada em Slack, Chambers e Johnston (2002, p.519): “o escopo de fornecimento
de um contratado, vai definir as fronteiras dentro das quais o trabalho deve ser feito”.
Os mesmos autores Slack, Chambers e Johnston (2002, p.519), complementam a
definição acima:
Em geral, definir o escopo de um projeto ou de um pacote de trabalho é ajudado pela definição do seguinte: • Das partes da organização que são afetadas [...]. • Do período de tempo envolvido [...]. • Dos processos de negócio envolvidos [...]. • Dos recursos a serem usados [...]. • Das responsabilidades dos contratados [...].
Os conceitos acima mostram a complexidade que envolve a gerência do escopo
dos projetos e parecem corroborar a observação encontrada no trabalho de Valeriano
(1988, p.188): “o “escopo” e a “descrição do trabalho” são títulos de documentos das
mais alta importância [...]. Entretanto, dependendo da fonte, observam-se algumas
diferenças a respeito do emprego e do conteúdo destas duas peças [...]”.
Uma vez que se definiu o que é o gerenciamento de escopo e o que se entende
por escopo de um projeto, no próximo item, procura-se definir e compreender o que é e
como se realiza a divisão dos pacotes de trabalho, que tem como produto a Estrutura
Analítica do Projeto, que também é conhecida por outras nomenclaturas.
33
2.2.2 Divisão dos pacotes de trabalho - Estrutura do Projeto
Segundo o PMBOK 2000 (2002, p. 57-58) a Estrutura Analítica do Projeto –
EAP, ou em inglês Work Breakdown Structure – WBS, é uma ferramenta e, ao mesmo
tempo, a saída do processo de detalhamento do escopo, conforme resumido na Figura 9.
Saídas Ferram. e Técnicas Entradas
1. Modelo de estrutura analítica do projeto (WBS)
2. Atualização do escopo
1. Modelo de estrutura analítica do projeto (WBS templates)
2. Decomposição
1. Declaração do escopo 2. Restrições 3. Premissas 4. Saídas de outro
planejamento 5. Informações históricas
Figura 9 – Processo de detalhamento do escopo Fonte: PMBOK 2000 (2002, p.57)
O PMBOK 2000 (2002, p.57) ainda adverte para:
Quando existe um detalhamento pobre do escopo, pode ser esperado um custo final mais alto por causa de inevitáveis mudanças que quebram o ritmo do projeto, causam retrabalho, comprometem o prazo e diminuem a produtividade e o moral da força de trabalho.
Mas se por um lado um detalhamento pobre do escopo pode ter como
conseqüência um aumento dos custos, um detalhamento muito grande também pode
gerar sérias dificuldades, devido ao aumento da complexidade dos processos de
gerenciamento. Isto é observado no trabalho de Vargas (2002, p.57) o qual chama a
atenção para relação “detalhamento do escopo x complexidade do gerenciamento”:
Um projeto com um detalhamento de escopo significativamente grande possui uma complexidade muito alta no que diz respeito ao gerenciamento de escopo. É importante trabalhar-se com um escopo que garanta o produto ou serviço, do projeto, sem ser demasiadamente detalhado, para que seu gerenciamento não se torne excessivamente complexo.
Na Figura 10, se representa, de forma esquemática, a relação entre o
“detalhamento do escopo x complexidade do gerenciamento”. Esta Figura sintetiza o
paradoxo do gerenciamento de escopo apresentado nos parágrafos anteriores, ou seja, é
importante se realizar o detalhamento de escopo, porém o mesmo não deve ser feito em
34
um nível de detalhe muito grande, pois se aumenta a complexidade do gerenciamento
sem obter nenhum ganho. Sempre se deve procurar um ponto de equilíbrio entre o
detalhamento e a complexidade gerada.
Complexidade
Figura 10 - Detalhamento do escopo x complexidade no gerenciamento
Alta
Alto Detalhamento
Baixa
Escopo
Obj
etiv
o de
Esc
opo
do P
roje
to
Complexidade
Fonte: Adaptado de Vargas (2002, p.57)
Com relação à definição da Estrutura Analítica do Projeto – EAP, se encontra no
PMBOK 2000 (2002, p.59-60):
Uma estrutura analítica do projeto (EAP) é um agrupamento de componentes de projeto (orientado para a elaboração de subprodutos – deliverable-orientade) que organiza e define o escopo total do projeto: o trabalho que não está na EAP está fora do escopo do projeto. Com relação à declaração do escopo, a EAP é freqüentemente usada para criar ou ratificar o entendimento comum do escopo do projeto. Cada nível descendente representa um incremento no detalhamento da descrição do escopo do projeto [...]. A cada item da EAP é, geralmente designado um identificador único; estes identificadores podem fornecer uma estrutura para a totalização hierárquica de custos e recursos. Os itens nos níveis mais baixos da EAP são, freqüentemente, referenciados como pacotes de trabalho (work packages) especialmente nas organizações que seguem as práticas de gerenciamento pelo Earned Value. Estes processos podem ainda ser decompostos em uma EAP de subprojeto [...].
Nos estudos de Cleland e Ireland (2002, p. 189) se encontra uma definição de
EAP e sua utilidade a qual parece complementar e reforçar os conceitos encontrados no
PMBOK 2000:
A estrutura de divisão do trabalho (Work Breakdown Structure – WBS) consiste em uma divisão do projeto global em “blocos de trabalho”, que representam unidades de trabalho individuais, atribuídas à empresa ou a entidades externas como, por exemplo, um distribuidor.
35
A filosofia básica do WBS é dividir o projeto em bloco de trabalho que podem ser designados e dos quais pode esperar-se confiabilidade. O desenvolvimento de uma WBS fornece meios para: 1. Sumarizar todos os produtos e serviços contidos no projeto,
incluindo suporte e outras tarefas. 2. Estender as inter-relações dos blocos de trabalho entresi, com o
projeto total e com as demais atividades da organização. 3. Estabelecer a autoridade–responsabilidade da organização matricial 4. Calcular o custo do projeto. 5. Conduzir análise de risco. 6. Planejar blocos de trabalho. 7. Desenvolver informações para a gerência do projeto. 8. Providenciar uma base para controle da aplicação de recursos no
projeto. 9. Estabelecer pontos de referência para fazer com que as pessoas se
comprometam em apoiar o projeto.
Em Valeriano (1988, p.191) se encontra a EAP definida como Estrutura de
Decomposição do Trabalho – EDT:
A estrutura de decomposição do trabalho – EDT é uma forma de apresentação do projeto que o explicita em suas partes físicas, em softwares, serviços e outros tipos de trabalho, a qual organiza, define e graficamente mostra tanto o produto a ser feito como o trabalho a ser realizado para obtê-lo”.
O mesmo autor, Valeriano (1998, p.192) afirma existir duas formas de
apresentar a EDT: “[...] sob a forma de um organograma, também conhecido como
árvore de decomposição do projeto ou como uma relação ou tabela”.
Além disto, segundo Valeriano (1998, p.193)
“A EDT como: árvore de decomposição do projeto” tem cada uma das suas partes, com detalhamentos sucessivos, representados por um retângulo ou “bloco” tendo a aparência de uma árvore invertida, com os galhos voltados para baixo [...]”.
Prado (2001, p.93) define EAP como “[...] um desenho no qual se apresenta a
decomposição do produto em suas partes constituintes”, ainda segundo Prado (2001, p.
94) “a EAP é também conhecida por EDT – Estrutura de Decomposição do Trabalho e
WBS – Work Breakdown Structure”, o que pode ser comprovado pelas diversas
definições anteriores sobre a EAP. Neste trabalho sempre será utilizada a sigla EAP.
Segundo Verzuh (2000, p.135) as EAP podem ser construídas na forma de
gráfico ou de tópicos, sendo a vantagem da EAP em forma de gráfico o fato de facilitar
o entendimento dos envolvidos e a EAP na forma de lista, segundo o autor, apresenta a
vantagem de permitir listar centenas de tarefas, muito mais do que se poderia na forma
36
gráfica.
Vargas (2002, p.162) define pacote de trabalho como: “[...] o produto a ser
entregue no mais baixo nível da estrutura analítica do projeto EAP. Um pacote de
trabalho pode ser repartido em atividades. Também podem ser denominadas atividades
resumo”. O próprio Vargas (2002, p.162) complementa a definição de pacote de
trabalho definindo: “entregas são todos os resultados físicos, ou semiprodutos, obtidos
ao longo do projeto. Servem para medir e avaliar a performance do projeto.
Normalmente pode ser definido através de marcos, ou etapas no cronograma”.
Já Verzuh (2000, p.138), define dois tipos de tarefas para uma EAP, as do nível
superior que ele denomina de tarefas resumos, ou seja, resumo das dos níveis inferiores,
as quais denomina pacotes de trabalho.
Para Verzuh (2000, p.138) “os pacotes de trabalho é que são executados de
verdade”.
Definido os conceitos de pacote de trabalho e entrega, pode se entender como
Vargas (2002, p.163), “os pacotes de trabalho são estruturados de modo a compor o
Work Breakdown Structure ou WBS. O WBS, também conhecido como Estrutura
Analítica do Projeto (EAP), ou até mesmo Plano Estruturado do Projeto (PEP)”.
As definições parecem enfatizar a importância e a riqueza de informação que
uma EAP pode trazer para um projeto e seu gerenciamento. Na Figura 11 se apresenta
um modelo esquemático de uma EAP genérica, na forma gráfica.
Figura 11 – Representação esquemática da EAP Fonte: Elaborada pelo autor
37
Na Figura 11, observa-se que o nível superior da hierarquia (1), abarca o escopo
total do Projeto, enquanto que nos níveis inferiores 2, 3, 4, etc., tem–se a divisão
sucessiva do escopo do projeto, sendo que nos níveis 3 ou 4 estão os pacotes de
trabalho.
Com relação até que nível deve ser detalhado uma EAP, se encontra em Vargas
(2002, p.163):
O WBS é uma ferramenta de gerenciamento do escopo do projeto. Cada nível descendente do projeto representa um aumento no nível de detalhamento do projeto como se fosse um organograma. O detalhamento pode ser realizado até o nível desejado, apresentando dados genéricos ou detalhados.
Já Verzuh (2000, p.147) sugere a utilização de três regras práticas, para
definição dos pacotes de trabalho:
A regra do 8 ou 80: nenhuma tarefa deve ter menos de 8h ou mais de 80h de trabalho [...].
A regra do período de avaliação: nenhuma tarefa deve ter duração maior do que à distância de dois pontos de avaliação [...]. A regra do “se for útil’: quando pensar se deve desmembrar ainda mais a tarefas, lembre-se que existem dois motivos para isto: a tarefa é fácil para estimar [...] ou é fácil distribuir a tarefa [...].
Por outro lado, segundo Prado (2001, p.97): “de modo a não deixar dúvida sobre
o conteúdo de cada item da EAP, deve-se construir um dicionário da EAP descrevendo
o significado de cada pacote de trabalho.”
Com base no exposto, parece válido concluir que: quanto mais alto na hierarquia
o pacote de trabalho, maior a abrangência e o volume de informações disponíveis sobre
o escopo. Assim os pacotes de trabalhos definidos nos níveis 4 ou 5, têm muita menos
informação em volume/quantidade que os níveis 1, 2 e 3, porém a riqueza de detalhes é
bem maior e o foco bem preciso.
Na Figura 12 tem-se a representação de uma EAP para construção de uma casa.
Embora não seja a função principal, no sentido horizontal, muitas EAP dão a
idéia de qual pacote de trabalho se inicia primeiro, pois, de maneira geral, ao se
estruturar os pacotes de trabalhos da EAP, se elabora a mesma colocando-se os pacotes
por ordem cronológica do início para o fim, ou seja, seqüência crescente ao ler a EAP
na horizontal, no sentido da esquerda para a direita, olhando-se de frente para a EAP.
Observa-se que as definições citadas de Valeriano, Prado, Verzuh e Vargas estão
contempladas nas Figuras 11 a pagina 36 e 12 a página 38.
38
Figura 12 – Representação de uma EAP para construir uma casa Fonte: Adaptado de Prado (1998, p.88)
Segundo Valeriano (1988, p.198), para um mesmo projeto podem ser elaboradas
EAP e até mesmos planejamentos diferentes, dependendo da visão e experiência de
cada gerente de projeto; por outro lado, isto não impede que as EAP sejam reutilizadas
ou que sejam elaborados modelos, conforme descrito no PMBOK 2000 (2002, p.57-58):
[...] Uma estrutura analítica de projetos – EAP, de um projeto anterior pode ser usada como modelo em um novo projeto. Embora cada projeto seja único, EAP podem, freqüentemente ser “reusadas” uma vez que a maioria dos projetos se assemelha a um outro, em algum aspecto. Por exemplo, a maioria dos projetos de uma determinada organização terá ciclos de vida de projeto iguais ou similares e, conseqüentemente, terá os subprodutos requeridos iguais ou similares, para cada fase. Muitas áreas de aplicação têm EAP padrão ou semipadrão que podem ser usadas como modelos [...].
Analisando as duas colocações anteriores, a de Valeriano e a do PMBOK 2000,
parece válido concluir, que não existe uma regra rígida que defina a forma como se deve
construir ou se elaborar uma EAP. Existe apenas, uma definição conceitual a qual
orienta os gerentes de projeto e suas equipes na utilização desta ferramenta fundamental
para o gerenciamento de todo o projeto. Os detalhes das EAP variam de projeto para
projeto conforme as características da equipe e/ou gerente que estão à frente do projeto,
como responsáveis pelos resultados do mesmo.
No item 2.3.6 à página 56, se apresenta de forma sucinta as duas técnicas
utilizadas para construção e integração das EAP e dos diagramas de rede.
39
Um outro aspecto importante na elaboração das EAP, é que as mesmas devem
ser elaboradas com um sistema de identificação dos blocos que a compõem. Este tema é
bem colocado por Valeriano (1998, p.205), segundo o qual este sistema de identificação
se torna a chave que possibilita obter informações cruzadas por meio de todas as
atividades, linhas de comunicação, documentos e dados do projeto, como cronogramas,
orçamentos, documentação e interfaces, configurações, contratos, controles etc.
Segundo Valeriano (1998, p.205) geralmente se emprega um sistema decimal, porém se
tem observado que as organizações têm adotado sistemas compostos por letras ou
sistemas alfa-numéricos (letras e números), similares a alguns sistemas utilizados para
codificação de materiais.
2.3 Gerenciamento do prazo do Projeto
2.3.1 Gerenciamento do prazo do Projeto, uma visão geral
Realizar o gerenciamento de um projeto não é tarefa trivial e, com certeza, para
tanto será necessária a elaboração de um plano, visão compartilhada por Keelling (2002,
p.181):
Mesmo o projeto mais simples exige um plano que seja factível e eficaz. O plano não é meramente uma lista de atividades do projeto e de seus prazos, mas um contínuo estabelecimento de objetivos, táticas e operações necessárias para conduzi-los do início até a conclusão bem sucedida. O documento de planejamento constitui diretriz para a coordenação, dizendo a todos o que fazer e quando empreender a ação, permitindo ao gerente do projeto controlar e coordenar o andamento do trabalho à medida que passa de um estágio para outro. É uma ferramenta de proteção contra o caos que tende a ocorrer em uma atividade não planejada.
Já em Cleland e Ireland (2002, p.189) se encontra a definição de que:
“planejamento é o processo de análise e explicitação dos objetivos, metas e estratégias
necessárias para que o projeto, durante seu ciclo de vida, possa alcançar plenamente
seus objetivos de custo, cronograma e desempenho”.
As definições propostas por Keelling e Cleland e Ireland sobre os objetivos do
planejamento dos projetos são complementares e podem ser enriquecidas se considerado
o conceito proposto por Keelling (2002, p.184): “a hierarquia do planejamento está
baseada nos objetivos principais (mission objectives). Começa nos níveis estratégicos,
40
passa para as táticas e depois para o nível básico das operações e atividades”, este
conceito está representado esquematicamente na Figura 13.
Figura 13 – A hierarquia de planejamento
Objetivos principais Estratégia Táticas Operações
Fonte: Keelling (2002, p. 184)
Uma outra visão do processo de planejamento e de sua importância é encontrada
no trabalho de Valeriano (1998, p.176) segundo o qual o processo de planejamento é um
esforço para se preparar para o futuro que virá. Neste contexto o papel do processo de
planejamento será estabelecer com antecedência, as decisões e ações que necessitam ser
executadas num dado futuro, para se atingir objetivos pré-definidos, em um prazo
determinado. De acordo com Valeriano (1998, p.176) “para planejar em busca deste
objetivo, é preciso saber o que se quer, para se determinar o que fazer, como fazê-lo, por
quem, quais os insumos necessários (existentes e a obter) e estimar quando se faz”.
Pelo exposto, pode se perceber que um bom processo de planejamento não é
uma tarefa simples, que possa ser realizada sem algum preparo, conhecimentos e
utilização de técnicas que auxiliem na sua execução.
2.3.1.1 Gerenciamento do prazo do Projeto – processos, ferramentas e técnicas
De acordo com o PMBOK 2000 (2002, p.65): “o gerenciamento do Prazo do
projeto inclui os processos necessários para assegurar que o projeto será implementado
no prazo previsto”, e os processos do mesmo podem ser divididos em:
41
Definição das atividades – identificar as atividades que devem ser realizadas para produzir os diversos subprodutos de projeto. Seqüenciamento das atividades – identificar e documentar as relações de dependência entre as atividades. Estimativa da Duração das Atividades – estimar a quantidade de períodos de trabalho que serão necessários para a implementação de cada atividade. Desenvolvimento do Cronograma - analisar a seqüência das atividades, sua duração, e os requisitos de recursos para criar o cronograma do projeto. Controle do Cronograma – controlar as mudanças no cronograma do projeto.
Para compreender as técnicas e ferramentas utilizada em planejamento de
projetos, é importante que se compreenda dois conceitos chaves: atividade e evento,
segundo Gaither e Frazier (2002, p.538): “uma atividade é uma tarefa ou uma
determinada quantidade de trabalho necessário no projeto, e um evento simplesmente
sinaliza o início e o fim de uma atividade. As atividades requerem um tempo para ser
concluída; os eventos não”.
Nos próximos itens se analisa cada um dos processos que compõem o
Gerenciamento de Prazo do Projeto, conforme o PMBOK 2000.
2.3.2 Processo de Definição das Atividades
Conforme o PMBOK 2000 (2002, p.65), “a definição de atividades envolve
identificar e documentar as atividades específicas que devem ser realizadas com a
finalidade de produzir diversos níveis de subprodutos identificados na EAP”.
Na Figura 14 se representa de forma esquemática o processo de definição de
atividades, segundo o PMBOK 2000 (2002, p.67).
Figura 14 – Processo de Definição de Atividades
Saídas
1. Lista de atividades 2. Detalhes de suporte 3. Atualização da EAP
1. Decomposição 2. Modelos
1. Estrutura Analítica do Projeto (EAP)
2. Declaração do escopo. 3. Informações históricas. 4. Restrições. 5. Premissas 6. Avaliação especializada
Ferram. E Técnicas Entradas
Fonte: PMBOK 2000 (2002, p.67)
42
As saídas deste processo são a atualização da EAP, que se estudou no item 2.3.1,
e a elaboração da lista de atividades, a qual consiste no levantamento de todas as tarefas
necessárias para a realização do projeto com suas respectivas durações.
Analisando-se o processo de definição de atividades, o mesmo pode ser
entendido como um conjunto de ferramentas que ajuda a aprimorar a EAP elaborada e
fornece informações que são utilizadas nos demais processos de Gerenciamento do
Projeto, é uma atividade com características analíticas e descritivas, não se utilizando
técnicas matemáticas especiais. Os resultados deste processo dependem das capacidades
de análise e síntese da equipe do projeto e de seus conhecimentos sobre o ambiente.
Na Figura 15, tem-se um exemplo de uma lista de atividades.
Cód. Descrição da atividade Duração
(semanas)
A Projeto 5
B Fundações 4
C Alvenaria (paredes, muros, rebocos, etc.) 4
D Esgotos 1
E Telhado (laje do teto, estrutura, caixa d’água, telhas, etc.) 5
F Piso (compactação, laje, etc.) 1
G Instalações elétricas 3
H Instalações Hidráulicas 4
I Carpintaria (janelas, portas, tacos, etc.) 6
J Pintura interna 8
K Pintura externa 2
L Limpeza (acabamento, jardinagem, etc.) 1
Figura 15 – Exemplo de lista de atividades para construção de uma casa Fonte: Adaptado de Prado (1998, p.25)
No trabalho de Prado (2001, p.98) se encontra a observação de que: “em razão
da importância para o sucesso dos projetos, as empresas que tocam muitos projetos
semelhantes costumam padronizar suas EAP. Assim ao se iniciar um novo projeto é
possível à utilização de um formato pré-existente”.
Os modelos de EAP e diagramas de rede podem ser muitos úteis, principalmente
quando se utilizam softwares, já que os modelos facilitam a padronização dos objetos.
43
2.3.3 Processo de Seqüenciamento das Atividades
Conforme o PMBOK 2000 (2002, p.65):
O seqüenciamento de atividades envolve identificar e documentar as relações de dependência entre as atividades. As atividades devem ser seqüenciadas corretamente possibilitando mais tarde o desenvolvimento de um cronograma realista e viável”.
Na Figura 16, tem-se a representação esquemática do processo de
seqüenciamento de atividades.
Saídas Ferram. e Técnicas Entradas
1. Diagrama de rede do projeto
2. Atualização da lista de atividades
1. Método do diagrama de precedência (PDM)
2. Método do diagrama de flecha (ADM)
3. Método do diagrama condicional
4. Modelos de rede
1. Lista de atividades 2. Descrição do produto 3. Dependências
mandatárias 4. Dependências arbitradas 5. Dependências externas 6. Marcos
Figura 16 – Processo de Seqüenciamento das Atividades Fonte: PMBOK 2000 (2002, p.68)
As entradas descritas no processo de seqüenciamento representado na Figura 16
são os produtos ou saídas dos processos anteriores analisados. Nos próximos itens se
executa a análise das ferramentas e técnicas utilizadas no processo de seqüenciamento
de atividades.
2.3.3.1 Método do Diagrama de Precedência (PDM)
Conforme PMBOK 2000 (2002, p.69):
Método do diagrama de precedência – PDM é um método de rede que utiliza retângulos para representar as atividades e os conecta por setas que representam as dependências [...]. Está técnica também é chamada de atividades no nó (AON – Activity-on-node) e é o método utilizado pela maioria dos pacotes de programas para gerência de projetos. O PDM pode ser feito manualmente ou no computador.
Na Figura 17 o desenho de um diagrama utilizando o método do diagrama de
precedência (PDM).
Apesar da aparente simplicidade da construção dos diagramas de precedência
44
conforme exemplo na Figura 17, deve-se observar, conforme alertado por Valeriano
(1998, p.215) que: a construção de diagramas PDM não pode ser arbitrária, pois na
construção dos mesmos deve-se levar em consideração as restrições ou condicionantes
que normalmente existem na execução de projetos.
Figura 17 – Exemplo de Diagrama de Precedência - PDM
Fim
F E
A B C
D
Início
Fonte: PMBOK 2000 (2002, p.69)
Segundo Verzuh (2000, p.158-159), existem duas regras básicas para se criar um
diagrama de rede:
1 – Defina os relacionamentos das tarefas somente entre pacotes de tarefas. Mesmo embora um projeto possa ter centenas de pacotes de trabalhos e diversos níveis de tarefas de resumo, mantenha as limitações de seqüências no nível de pacote de trabalho [...]. 2 – Os relacionamentos das tarefas refletem somente limites de seqüência entre os pacotes de trabalho, não os limites dos recursos. Alterar um diagrama de rede por causa das limitações de rede é o erro mais comum na criação de diagramas de rede [...].
Nos diagramas do tipo PDM existe quatro tipos de relacionamentos de
dependência ou precedência possíveis, PMBOK 2000 (2002, p.69):
Término/Início (finish-to-start): O início do trabalho da sucessora depende do término da predecessora. Término/Término (finish-to-finish): O término do trabalho da
sucessora depende do término da predecessora. Início/Início (start-to-start): O término do trabalho da sucessora
depende do início da predecessora. Início/Término (start-to-finish): O início do trabalho da sucessora
depende do início da predecessora.
Com relação ao tipo de relacionamento, conforme PMBOK 2000 (2002, p.69):
O término/início é o tipo de relacionamento lógico mais comumente usado. Os relacionamentos: inicio/término são raramente usados e assim mesmo apenas por engenheiros e profissionais de programação. Usar início/início, término/término ou início/término em softwares de gerência de projetos pode produzir resultados inesperados uma vez que estes tipos de relacionamentos não foram ainda implementados consistentemente.
45
Na Figura 18 a representação gráfica dos quatro tipos de relacionamentos
possíveis entre as tarefas em uma diagrama.
Início/Início Início/Término
Término/Término
Término/Início
Figura 18 – Representação gráfica dos relacionamentos em um diagrama Fonte: Adaptado de Cleland e Ireland (2002, p.202)
2.3.3.2 Método do Diagrama de Flecha (ADM)
Com relação ao método do diagrama de flecha (ADM – Arrow Diagramming
Method) no PMBOK 2000 (2002, p.70) se encontra a sua definição como:
Este é um método de construção de diagramas de rede que utiliza setas para representar as atividades e as conectar por meio de nós que representam as dependências [...]. Está técnica é também chamada de atividade na flecha (AOA – Activity-on-arrow) e, embora menos predominante que o PDM, é ainda a técnica escolhida em algumas áreas de aplicação. O ADM utiliza apenas relações de dependência do tipo fim/início e, às vezes necessitam da criação de atividades “fantasmas” para definir corretamente o relacionamento lógico. O ADM pode ser feito manualmente ou no computador.
Na Figura 19, tem-se um exemplo de diagrama utilizando o método de
diagramação por flecha (ADM). A seta tracejada na Figura 19 representa uma atividade
“fantasma”, de acordo com Prado (1998, p.39) o recurso da atividade “fantasma” ou
fictícia deverá ser utilizado para mostrar interdependência entre atividades, sempre que
o traçado da rede se mostrar complexo. A definição de atividade fictícia se encontra na
Figura 27. De acordo com Prado (1998, p.39) “os círculos mostrados recebem a
denominação de eventos ou nós. A atividade é representada no nó não sendo necessário
que se desenhe à seta em escala proporcional à sua duração estimada”. Além disto, é
possível realizar a numeração dos eventos para melhor identificá-los, sendo a mesma
realizada em ordem crescente partindo-se do início da rede, segundo Prado (1998, p.40).
46
Figura 19 – Desenho de diagrama de rede pelo método ADM
Fim Início
A
F
E
C
D
B
Fonte: PMBOK 2000 (2002, p.70)
2.3.3.3 Análise comparativa dos métodos Diagramas de Flecha e Precedência
Analisando-se os conceitos apresentados sobre a construção de diagramas de
rede utilizando os métodos PDM ou AON e ADM ou AOA, verifica-se que os mesmos
trazem as mesmas informações, porém as representam de forma diferente, as principais
diferenças entre as duas técnicas estão resumidas na Figura 20 a seguir:
Característica PDM ou AON ADM ou AOA
Traçado do diagrama Simples, pode-se utilizar inclusive papel pré-impresso.
Mais complexo que no método PDM ou AON.
Atividades fantasmas ou fictícias
Não existe necessidade deste recurso.
De 20% a 40% das atividades são fantasmas.
Inclusão de atividades Simples Complexo, pois necessita se alterar a identificação dos nós já existentes.
Exclusão de atividades Simples Complexo, pois necessita alterar a identificação dos nós remanescentes.
Desenho em escala Não necessário/aplicável Possível, mais muito trabalhoso, raramente utilizado.
Possibilidade de utilizar computadores
Maioria dos softwares usado em gestão e planejamento tem.
Poucos softwares usados em gestão e planejamento, tem.
Figura 20 – Resumo comparativos das diferenças dos métodos PDM e ADM Fonte: Elaborado com base nas análises encontradas em Prado (1998, p.51) e Slack, Chambers e Johnston (2002, p.534)
47
Analisando-se a Figura 20, pode-se concluir como Prado (1998, p.51), “por tudo
isso fica claro que o diagrama de precedência leva ampla vantagem sobre o de setas
[...]”.
2.3.3.4 Métodos do Diagrama Condicional (CDM) e modelos de rede
Os métodos do diagrama condicional (CDM – Conditional Diagramming
Method), segundo o PMBOK 2000 (2002, p.70), são:
As técnicas de diagramação tais como GERT (Graphical Evaluation and Review Technique - Avaliação Gráfica e Técnicas de Revisão) e Modelos de Sistemas Dinâmicos (System Dynamics) permitem atividades não seqüenciais como “loops” (por exemplo, um teste deve ser repetido mais de uma vez) ou desvios condicionados (por exemplo, a atualização de desenho que é necessária apenas se a inspeção detectar erros). Nem o PDM nem o ADM permitem “loops” ou desvios condicionados.
Uma outra técnica utilizada na construção de redes é elaboração de modelos de
rede, que segundo PMBOK 2000 (2002, p.70), “redes padronizadas podem ser utilizadas
para auxiliar a preparação do diagrama de rede do projeto. Podem incluir todo projeto
ou apenas uma parte”.
Pelas definições das técnicas de Avaliação Gráfica, Técnicas de Revisão e os
Modelos de Sistemas Dinâmicos, as mesmas parecem ser técnicas onde a utilização
somente é possível com uso de softwares enquanto as técnicas de Diagrama de Flechas
e Diagrama de Precedências, podem ser elaborados até mesmo a mão se necessário, o
que em algumas situações pode ser uma grande vantagem.
2.3.3.5 Saídas das técnicas de construção de diagramas
A utilização das técnicas vista (ADM, PDM, GERT e Sistemas Dinâmicos), tem
como saída o diagrama de rede do projeto, que segundo o PMBOK 2000 (2002, p.70),
“é um esquema de apresentação das atividades do projeto e dos relacionamentos lógicos
(dependências) entre elas”. Nas Figuras 17 e 19, se apresentou exemplo de diagrama
construído utilizando-se a técnica PDM e ADM, respectivamente.
A grande variedade de modelos, técnicas e nomenclaturas dos diagramas de rede
às vezes provocam confusões, é comum no ambiente profissional da gerência de
48
projetos os diagramas rede apresentados anteriormente serem conhecidos simplesmente
por redes PERT/CPM, o que pode ser compreensível na visão de Prado (1998, p.16):
Apesar do diagrama de precedência ser o modelo mais usado em todo o mundo, os termos PERT, CPM e PERT/CPM, são usados atualmente como designação da representação de um projeto por redes, independentemente de qual tipo de rede se usa.
A elaboração de diagramas de redes de projetos como visto até aqui, pode causar
a impressão de que este processo é estático, que o planejamento do projeto é elaborado
uma única vez. Mas na prática empresarial o processo de planejamento é dinâmico,
como salientado por Slack, Chambers e Johnston (2002, p.521):
O planejamento não é um processo único. Ele pode ser repetido diversas vezes durante a vida do projeto, à medida que mudam as circunstanciais. O replanejamento não é um sinal de falha do projeto ou de mau gerenciamento. Especialmente em projetos incertos, é uma ocorrência normal. De fato, planos em estágio superiores tipicamente significam que mais informação está disponível, e que o projeto está tornando-se menos incerto.
A visão de que a elaboração de um diagrama de rede é um processo dinâmico é
compartilhada pelo PMBOK 2000 (2002, p.71), a “[...] preparação do diagrama de rede
do projeto pode revelar situações em que uma atividade dever ser dividida ou mesmo
redefinida com a finalidade de diagramar corretamente o relacionamento lógico”.
2.3.4 Estimativas da duração das atividades dos diagramas de projeto
Uma atividade importante para elaboração de diagramas de projeto, é a
estimativa da duração da atividade, que segundo o PMBOK 2000 (2002, p.71), “é o
processo de gerar as durações das atividades para entrada no cronograma, a partir das
informações do escopo do projeto e dos recursos disponíveis”.
A Figura 21 representa de forma esquemática o processo de estimativa da
duração das atividades.
O processo de estimativa da duração das atividades, segundo Vargas (2002,
p.63) “consiste em determinar o período de tempo necessário para realizar cada
atividade do projeto. Vários métodos podem ser empregados nas estimativas, tais como
a simulação, julgamentos especializados e os modelos matemáticos e estatísticos”.
Verzuh (2000, p.163), chama atenção para que as estimativas de tempo das
tarefas sejam realizadas considerando-se a quantidade de tempo necessário para atingir
49
os objetivos da mesma, ou seja, de seu tempo decorrido do início até o seu fim, e não
simplesmente o tempo necessário para realizar a tarefa em si. Como exemplo, um
pedido de compra pode ser realizado em duas horas, mas se o material levará dez dias
para chegar o tempo estimado da tarefa deverá ser de onze dias e não de duas horas.
Saídas Ferram. e Técnicas Entradas
1.Estimativas de duração das atividades
2.Bases para a estimativa.
3.Atualização da lista de atividades
1. Avaliação especializada 2. Estimativas por analogia 3. Durações estimadas quantativamente 4. Tempo de reserva (contingência)
1. Lista de atividades 2. Restrições 3. Premissas 4. Necessidades de recursos 5. Capabilidade de recursos 6. Informações históricas 7. Riscos identificados
Figura 21 – Processo de estimativa da duração das atividades Fonte: PMBOK 2000 (2002, p.71)
2.3.4.1 Elaboração dos diagramas do projeto tipo CPM
Após a elaboração das estimativas de duração das atividades que compõem os
diagramas do projeto, o passo seguinte é o desenvolvimento do cronograma que
segundo o PMBOK 2000 (2002, p.72), “significa determinar as datas de início e fim
para as atividades do projeto. Se as datas de início e fim não forem realistas, é
impossível que o projeto termine conforme o planejado”, na Figura 22 a representação
deste processo.
Figura 22 – Processo de desenvolvimento do cronograma
Saídas Ferram. e Técnicas Entradas
1. Cronograma do projeto
2. Detalhes de suporte 3. Atualização das
necessidades de recursos
1. Análise matemática 2. Compressão da duração 3. Simulações 4. Heurística de
nivelamento de recursos Software5. de gerência de
6. Estrutura de codificação
projeto
1. Diagramas de rede do projeto
2. Estimativas de duração das atividades
3. Necessidades de recursos
4. Descrição do quadro de recursos
5. Calendários 6. Restrições 7. Premissas 8. Folgas e flutuações 9. Plano de gerenciamento
de riscos 10. Atributos das
atividades
Fonte: PMBOK 2000 (2002, p.73)
50
Analisando-se o processo de desenvolvimento do cronograma, apresentado na
Figura 22, se verifica que o mesmo é um processo abrangente que considera um grande
número de variáveis como dados de entrada, e tem como principal saída o cronograma
do projeto. Para elaboração do cronograma do projeto é necessário utilizar ferramentas e
técnicas específicas para esta finalidade, de acordo com PMBOK 2000 (2002, p.75), a
técnica CPM, uma das mais utilizada pelos profissionais da área, pode ser definida
como:
Método do Caminho Crítico (CPM - Critical Path Method): calcula de forma determinística, uma data única mais cedo e mais tarde, de início e de término para cada atividade, baseado na seqüência lógica especificada da rede em uma duração única estimada.
No anexo A se encontra uma descrição sucinta de outras técnicas e ferramentas,
além da CPM, utilizadas para calcular a duração das atividades na gestão de projetos e
para o desenvolvimento de cronogramas.
Com as definições dos conceitos sobre os diagrama de rede e as técnicas
matemáticas utilizadas para calcular a duração das atividades, fica fácil se compreender
porque as técnicas CPM/PERT são aplicadas aos diagramas de blocos ou precedências
(PDM) e de setas (ADM) conforme Figuras 17 e 19 nas páginas 44 e 46, os quais
incorporam mais informação, ou seja, Keelling (2002, p.207):
Sendo um desdobramento do diagrama de setas simples, os diagramas baseados nos métodos do caminho crítico (CPM) ou das técnicas de avaliação e revisão de programas (PERT) incluem informações não só sobre a duração de cada atividade, mas sobre as datas mais cedo e mais tarde nas quais esta atividade poderá acontecer [...].
Considerando todas as observações acima, um diagrama de setas completo,
poderá ter todas as convenções apresentadas na Figura 23 e os diagramas de
precedência PDM ou AON, conforme Figura 24.
Figura 23 – Convenção dos termos em um diagrama ADM ou AOA Fonte: Adaptado de Slack, Chambers e Johnston (2002, p.533) e Keelling (2002, p.208)
51
Data mais
cedo de início Duração
Data mais
cedo de término
Número de atividades
Descrição de atividades
Data mais
tarde de início Folga total
Data mais
tarde de término
Figura 24 – Convenção dos termos utilizados em diagramas PDM ou AON Fonte: Slack, Chambers e Johnston (2002, p.536)
Nas Figuras 25 e 26 se tem um exemplo de diagrama de flechas (ADM) e um
diagrama de precedência (PDM) elaborados utilizando a técnica CPM para sua
construção, no anexo B se apresenta como se calcula a duração das atividades
utilizando-se a técnica PERT e no anexo C uma crítica as técnicas CPM e PERT.
Keelling (2002, p.208) complementa as informações sobre a nomenclatura dos
diagramas de flecha com as seguintes notas:
1. Os números dos eventos são alocados após ter sido traçado o diagrama.
2. O número dos eventos serve apenas para identificar o evento ou o ponto na seqüência.
3. Lacunas na numeração permitem a inserção de atividades adicionais que podem ser lembradas mais tarde.
4. Os números dos eventos no exemplo acima foram fixados a intervalos de 10 para permitir a identificação de atividades em um plano secundário (de atividades) que pode reduzir os números intermediários.
Como observado, por Prado (1998, p.57), os diagramas tipo ADM ou AOA, não
permitem ter todas as informações sobre as datas para os eventos e folga de forma
explicita; neste caso tem se duas opções para se ter as datas das atividades:
• No próprio diagrama;
• Numa tabela confeccionada à parte.
O próprio Prado (1998, p.57) observa, “seguramente, a primeira opção é melhor,
todavia ela torna o desenho bastante “pesado”, pelo excesso de informações”.
Além das definições dos termos utilizados no planejamento de projetos em geral
apresentados na Figura 27, Keelling (2002, p.211) propõem que existe mais de um tipo
de folga, as quais podem ser definidas como:
Folga independente: a margem de segurança que a vezes ocorre quando uma atividade é conduzida entre a data mais tarde do evento e
52
a data mais cedo do evento sucessor. Folga livre: a margem de segurança entre dois eventos.Nota se a folga for calculada a partir das datas mais cedo para cada evento, o número pode diferir em relação a um cálculo que utilize ambas as datas mais tarde do evento. Folga total: o tempo livre máximo entre dois eventos quando estes são realizados de modo mais distanciado possível. Folga de seqüência: a folga total em uma seqüência de eventos.
Nas Figuras 25 e 26 a representação de um diagrama de flechas ADM e um de
Precedência PDM, com todos os tempos de duração das atividades.
Figura 25 – Diagrama de Flechas – ADM (exemplo) Fonte: Adaptado de Keelling (2002, p.210)
Figura 26 – Diagrama de Precedência (PDM) de uma Casa Hipotética Fonte: Adaptado de Prado (1998, p.83)
53
Nas Figuras 25 e 26 as letras representam atividades, e podem ser substituídas
pelo nome da atividade, como por exemplo: construir o alicerce, fazer a fundação,
elaborar o projeto, etc., em geral se coloca o nome das atividades quando possível ou se
elabora uma tabela que possui a descrição completa de cada atividade.
As definições dos termos utilizados nos diagramas do tipo ADM, PDM, CPM e
na gerência de projetos em geral estão listados na Figura 27.
Termos usados em Gerência de Projetos
Termo Sigla Definição
Atividade - Uma determinada quantidade de trabalho necessária para o projeto.
Duração de Atividade -
Em CPM, a melhor estimativa do tempo para concluir uma atividade. Em PERT o tempo esperado ou o tempo médio para concluir uma atividade.
Atividade crítica -
Uma atividade na qual não há espaço para atrasos. Se ela atrasar, toda a conclusão do projeto atrasará. Uma atividade com folga zero.
Caminho crítico - A cadeia de atividades para o projeto. O caminho mais
longo de uma atividade. Atividade
fictícia - Uma atividade que não consome tempo, mas tem prioridade entre as atividades.
Primeira data de término
PDT O mais cedo que uma atividade pode terminar, a partir do início do projeto.
Primeira data de início
PDI O mais cedo que uma atividade pode começar, a partir do início do projeto.
Evento - Um início, o ponto de conclusão ou feito que marca o projeto. Uma atividade começa e termina com eventos.
Última data de término UDT O mais tarde que uma atividade pode ser concluída, sem
provocar atraso na conclusão do projeto. Última data
de início UDI o mais tarde que uma atividade pode ser iniciada, sem provocar atraso na conclusão do projeto.
Atividade antecedente - Uma atividade que tem de ocorrer antes de uma outra.
Atividade subseqüente - Uma atividade que tem de ocorrer depois de uma outra.
Folga - O tempo que uma atividade ou um grupo de atividades pode passar do prazo sem provocar atraso na conclusão do projeto.
Figura 27 – Termos usados em Gerência de Projetos Fonte: Adaptado de Gaither e Frazier (2002, p.533)
Os termos apresentados na Figura 27, não são uma unanimidade, mas são
54
utilizados na elaboração e interpretação, dos diagramas de redes e na gerência de projeto
em geral, existindo algumas pequenas variações nas denominações e siglas, mas os
conceitos são sempre os mesmos, independentes de variações nas denominações e/ou
siglas. Por exemplo, Verzuh (2000, p.174) denomina de flutuação o que comumente
muitos autores chamam de folga, o mesmo define flutuação como sendo a diferença
entre o início antecipado e o término antecipado. Independente dos termos utilizado,
flutuação ou folga, seu conceito na gerência de projetos não muda.
2.3.4.2 Elaboração dos diagramas do projeto tipo Diagramas de Gantt
A saída mais importante do processo de desenvolvimento do cronograma é o
cronograma do projeto, o qual segundo o PMBOK 2000 (2002, p.77), “[...] inclui, para
cada atividade, no mínimo as datas de início e de término esperado para cada atividade
[...]”, mais adiante um pouco complementa “O cronograma do projeto pode ser
apresentado de forma sumarizada (“master schedule”) ou em detalhes”.
As formas de apresentação gráfica dos diagramas de rede foram apresentadas
anteriormente juntamente com a termologia utilizada nas Figuras 17, 19, 23, 24, 25 e
26, apenas um tipo de gráfico não foi ainda apresentado, o Gráfico de Barras, conforme
PMBOK 2000 (2002, p.78), “o gráfico de barras, também chamado de gráfico de Gantt,
mostram as datas de início e término das atividades bem como as durações esperadas, e
algumas vezes mostra as dependências [...]”.
Na visão de Keelling (2002, p.214), “o gráfico de Gantt, não substitui o
diagrama de setas ou o de precedência, mas apresenta um quadro de fácil compreensão
da programação de tarefas”.
Esta necessidade de se utilizar o gráfico de Gantt juntamente com os diagramas
de setas ou de precedência apesar de sua fácil utilização, se deve segundo Prado (1998,
p.27) ao fato de que, “o gráfico de Gantt possui uma excelente comunicação visual e
esta é a razão do seu uso generalizado. Sua maior desvantagem está em não mostrar
claramente a interdependência entre as atividades [...]” esta limitação do gráfico de
Gantt pode ter um grande impacto, segundo Prado (1998, p.27):
[...] em projetos com centenas de atividades, está deficiência do diagrama pode acarretar erros gravíssimos. Esta é a maior desvantagem do Gráfico de Gantt, que o torna muito difícil o seu uso no controle de projeto com um número de atividades superior a trezentos [...].
55
De acordo com Verzuh (2000, p. 178) o diagrama de rede (precedência) é útil
para calcular o cronograma, mas difícil para visualizar, sendo esta a grande qualidade
do gráfico de Gantt, a sua clareza, já que em seu eixo horizontal temos o cronograma e
no eixo vertical a lista da estrutura de trabalho desmembrada.
Vargas (2002, p.179-180) aponta algumas vantagens e desvantagens em se
utilizar o diagrama de Gantt:
As principais vantagens [...]: simples entendimento, visualização de atrasos com facilidades e escala de tempo bem definida. Suas principais desvantagens [...]: inadequação para grandes projetos, difícil visualização de dependências e vaga descrição de como o projeto reage a alterações de escopo.
Os gráficos de Gantt devem ser utilizados, juntamente com os diagramas de
precedência e de setas, provendo a visão geral do projeto por meio do diagrama de
barras e das relações de dependência e caminho crítico, pelos diagramas de precedência.
Conforme Valeriano (1998, p. 214), pode se construir um cronograma geral da
obra denominado Cronograma Mestre o qual deve cobrir toda a duração do projeto e
tem como finalidade principal prover uma visão geral do projeto, a partir do mesmo
deve-se construir os diagramas detalhados, ou parciais.
Na prática é comum se construir o gráfico de Gantt geral para a obra toda, e à
medida que mais informações vão sendo disponibilizadas se construir os diagramas
detalhados. A esse respeito Prado (1998, p. 95) sugere que o detalhamento das
atividades deverá ocorrer de acordo com a proximidade da necessidade de realização
das mesmas, detalhando-se mais as atividades mais próximas (até um semestre).
Nos gráficos de Gantt, é comum se utilizar símbolos para assinalar eventos
chaves que deverão ocorrer, para facilitar o controle e acompanhamento da evolução do
projeto. Estes marcos podem ser denominados como metas intermediárias, as quais
também são conhecidas com milestones em inglês, conforme Prado (1998, p.95).
Prado (1998, p.96) divide os marcos ou milestones em dois tipos, os contratuais
e os internos.
Metas que fazem parte do contrato (exigências do cliente); Metas internas, que são conseqüência da estratégia de execução
montada pelo Gerente de Projeto (este grupo costuma receber o nome de Etapas ou Fases).
Na Figura 28, se tem um exemplo de cronograma de barras ou Gantt, elaborado
para construção de uma casa hipotética.
56
Figura 28 – Gráfico simples de Gantt (exemplo) Fonte: Adaptado de Prado (1998, p.26)
57
Na prática gerencial, é comum que os marcos internos sejam alocados ao início e
ao fim de cada fase do projeto, no diagrama de Gantt apresentado na Figura 28, as datas
de início e fim de cada uma das atividades poderiam ser consideradas como marcos
internos.
A existência de marcos nos planejamento não quer dizer que as pessoas
envolvidas ou responsáveis pelos trabalhos devam parar para analisar a evolução dos
trabalhos somente quando chegam na data prevista para cumprimento dos marcos,
sejam internos ou contratuais, mas durante toda a execução. Os marcos são importantes
para permitirem aos envolvidos no projeto terem uma visão abrangente de quais partes
do escopo estão atrasadas, em dia ou adiantadas em relação ao programado. Ter está
visão é fundamental para poder se estabelecer planos de recuperação de prazo quando
existem atrasos e balanceamento da distribuição dos recursos disponíveis para o projeto.
2.3.5 Processo de controle do cronograma
O último processo que compõem o processo de gerenciamento do prazo, é o
processo de controle do cronograma, o qual segundo Vargas (2002, p.63) pode ser
entendido como:
O processo que se concentra na avaliação dos fatores que criam mudanças nos prazos, de modo a garantir que essas mudanças sejam benéficas, além de se utilizar um sistema de controle de mudanças de tempo, previamente definido no Plano de Gerenciamento de Tempo para definir os procedimentos nos quais os prazos do projeto podem ser modificados.
Independente do tipo, de acordo com Gaither e Frazier (2002, p.532):
Os gráficos de programação e controle são os instrumentos mais utilizados para gerenciar projetos. Cada gráfico primeiro planeja e programa uma determinada parte do projeto – o que deve ser feito e quando. Depois, à medida que o projeto evolui cada um dos gráficos é atualizado de forma que indique quanto do plano foi concluído. Desta forma os gerentes de projeto podem comparar o trabalho efetivamente realizado com a evolução planejada do projeto. Esse procedimento permite mudanças racionais no uso de recursos por parte da gerência para concluir o projeto dentro das metas de tempo, custo e qualidade.
É claro que quando se utilizam softwares para a elaboração e acompanhamento
dos projetos, geralmente também se conta com uma série de relatórios, que estão
58
embutidos nos mesmos, os quais são ferramentas complementares aos gráficos de
programação e controle, sendo úteis para os usuários devido a riqueza de informações.
e Sem esquecer a advertência de Verzuh (2000, p.191), embora os softwares
façam o trabalho e executem os cálculos necessários para a elaboração dos diagramas e
cronogramas dos projetos, os mesmos só fazem duas tarefas: o armazenamento de
informações e os cálculos. Portanto, independente de se utilizar ou não softwares o
conhecimento das técnicas de planejamento é indispensável.
2.3.6 Construção e integração da EAP, diagramas e cronogramas de PRJ
As EAP e os Diagramas de Rede deverão ser integrados, segundo Vargas (2002,
p.164) existem duas técnicas para estruturar as atividades: técnica Top-to-Bottom ou
Decomposição e técnica Bottom-Up.
Vargas (2002, p.165) define estas técnicas como:
Técnica Top-to-Bottom ou Decomposição: [...] a estrutura deve ser criada de cima para baixo, isto é, dos macros fases do projeto até os níveis de esforço (entregas estritamente operacionais). Sua construção segue os seguintes passos:
1. Identifique as grandes fases dos projetos. 2. Para cada fase identificada, detalham-se as entregas desejadas. 3. Para cada entrega, detalha-se o pacote de trabalho necessário para
a sua conclusão. 4. Se necessário, para cada pacote de trabalho, detalha-se o nível de
esforço realizado para a conclusão do respectivo pacote. 5. Agregam-se os conjuntos de modo a produzir o WBS. Técnica Bottom-UP: [...] a estrutura deve ser criada de baixo para
cima, isto é, a partir de um conjunto aleatório de entregas, gerado através de brainstorming ou da experiência dos participantes. Sua construção segue os seguintes passos:
1. Obtém-se o conjunto de entregas através de brainstorming, ou através da experiência dos envolvidos.
2. Criam-se os pacotes de trabalho para atingir as entregas. 3. Agrupam-se as entregas em fases. 4. Agrupam-s as fases em um projeto.
Independente da técnica que seja utilizada para construir a EAP e definir as
atividades nos diagramas, de rede é importante salientar que a EAP e os diagrama de
redes deverão ser integrados, constituindo um todo, que permitirá gerenciar e controlar
todo o projeto. Esta integração é representada de forma esquemática na Figura 30.
Na Figura 29 a representação esquemática das duas técnicas, (Top-to-Bottom e
Bottom-Up), discutidas anteriormente.
59
Figura 29 – Técnica Top-to-Bottom x Bottom-Up Fonte: Adaptado de Vargas (2002, p. 165)
Na Figura 30, se observa que para cada pacote de trabalho da EAP, pode-se
associar um diagrama de rede, o qual contém as atividades de forma detalhada a serem
executadas bem como os recursos que serão utilizados.
Nos projetos com grande complexidade, é possível se associar às atividades mais
complexas um outro diagrama de rede, denominado sub-rede, o qual detalhará a
seqüência de atividades/tarefas que serão executadas para realizar e atingir a meta. Este
recurso em geral é utilizado somente em projetos de grande porte e complexidade, ver a
discussão anterior sobre a quantidade de atividades gerenciáveis nos diagramas de rede.
Um conceito importante muito utilizado na Gerência de Projetos, na elaboração
de EAP e do diagrama de rede, é o conceito de recurso, que segundo Vargas (2002, p.
172) é definido como: “[...] todas as pessoas, materiais de consumo e equipamentos
necessários para a realização da atividade”.
Uma última observação, no trabalho de Verzuh (2000, p.154), se encontra a
informação de que muitas organizações utilizam EAP para desmembrar a estrutura do
produto, e não num nível de detalhe mais alto.
Observa-se que isto ocorre em várias organizações, porém na prática isto não
tem grandes conseqüências desde que o adequado detalhamento das tarefas seja
realizado nos diagramas e cronogramas do projeto, ou em outros documentos
complementares como, por exemplo, os roteiros de produção, que nos projetos
complexos são utilizados para detalhar ainda mais as atividades previstas nos diagramas
e cronogramas.
60
Figura 30 – Representação esquemática da integração EAP x Diagramas de Rede Fonte: Elaborada pelo autor
61
2.4 Uso de programas em Gerenciamento e Planejamento de Projetos
Existem diversos softwares desenvolvidos especificamente para utilização em
gerência de projetos, Keelling (2002, p.223) cita alguns dos mais conhecidos e
utilizados: “Ártemis, Pretigie, Primavera Project Planner Scheduler (Fox e Spence,
1998)”.
Existem várias características desejadas em um software utilizado para gerência
de projetos, segundo Keelling (2002, p.223) em maio de 1998 foi relatado em Cost
Engineering, um levantamento realizado sobre a capacidade de dezoito pacotes de
softwares, o qual selecionou os seguintes critérios:
1. Facilidade de uso e programação; 2. Gerenciamento avançado de agendas e recursos; 3. Projetos múltiplos; 4. Estimativa e controle de custos; 5. Trabalho de grupo e apoio da internet.
Ainda segundo Keelling (2002, p.224), as características mais desejadas são
simplicidade, velocidade, facilidade de treinamento e uso em operações e a maioria dos
gerentes procura:
1. Capacidade para produzir diagramas, gráficos e tabelas, incluindo diagramas de seqüência e de setas, diagramas PERT e gráficos de Gantt, monocromáticos e com combinação de cores;
2. Capacidade para acompanhar dependências, produzir listas de seqüências e recursos, agendar atividades e calcular custos em relação ao tempo, calcular “folga”, previsões de fluxo e comparações entre desempenho e custos planejados para e efetivamente incorridos;
3. Capacidade para produzir agendas e relatórios segundo o formato dado pelos gerentes;
4. Capacidade para deduzir atividades e eventos ou conjuntos de atividades e eventos para fins de análise, comparação e relatórios;
5. Fornecimento de lembretes sobre itens como prazos e advertências sobre prazos vendidos.
Além dos softwares específicos dedicados exclusivamente ao Gerenciamento e
Planejamento de Projetos, a família de softwares tipo ERP tem incorporado cada vez
mais facilidades para possibilitar a execução de muitas operações e controles
diretamente nos mesmos, com a vantagem de que estes programas estão incorporados
(integrados) a toda organização.
Independente do tipo de software que se utilize, o conhecimento das técnicas de
gerenciamento de projetos é fundamental, pois os programas são ferramentas e não
62
objetivos em si mesmos.
Este ponto é abordado por Keelling (2002, p.223), o qual sugere uma técnica
simples para verificar se o programa está realmente sendo útil. A técnica consiste em
verificar se os trabalhos realizados no computador seriam feitos de forma similar
manualmente, caso não se tivesse o computador disponível, se a resposta for sim o
computador é um bom recurso, caso contrário a sua utilização deverá ser reavaliada.
No próximo item se apresenta de forma concisa as principais características dos
programas tipo ERP e do software ERP SAP R/3.
2.5 Programas para Planejamento de Recursos Empresariais
Os programas ou sistemas para Planejamento de Recursos Empresariais tradução
para o nome em inglês de Enterprise Resources Planning conhecido mundialmente
sobre a sigla ERP, são softwares utilizados no mundo inteiro, nos mais diversos ramos
da indústria, comércio e serviços.
Nos próximos itens procura-se definir de forma concisa o que são os softwares
ERP e suas principais características bem como apresentar uma visão geral do software
ERP SAP R/3.
2.5.1 Os sistemas ERP, características e aplicações
De acordo com Laudon e Laudon (2001, p.16), os softwares ERP podem ser
definidos como “[...] um sistema gerencial que integra todas as facetas da empresa,
inclusive planejamento, produção, vendas e finanças, de forma que elas podem ser
coordenadas mais de perto compartilhando informação [...]”.
Já segundo Stair e Reynolds (2002, p.265):
Os sistemas ERP acomodam diferentes maneiras pela qual cada companhia conduz seu negócio, seja pela disponibilização de funções que, muitas vezes, transcendem o que o negócio precisa, ou pela inclusão de ferramentas personalizadas que viabilizam atingir aquilo que era apenas uma aspiração ou sintonizar o que já está compatível.
Ao se analisar os softwares ERP a partir da perspectiva acima, é possível
imaginar a complexidade e tamanho que os softwares ERP atuais estão atingindo, uma
vez que eles tendem a procurar atender e integrar todas as funções das organizações.
63
Em geral os sistemas ERP comercialmente disponíveis são construídos em
módulos que podem ser ajustados as necessidades dos clientes. Laudon e Laudon (2001,
p.269) definem este recurso como: “[...] as características de personalização permitem a
um pacote de software ser modificado para atender as exigências únicas de uma
organização sem destruir a integridade do pacote”.
Outra importante característica dos softwares ERP é a existência no mercado de
programas chamados middleware, que segundo Laudon e Laudon (2001, p. 269-270)
“[...] é um produto de software que conecta duas aplicações separadas para passar dados
entre si [...]”.
Na Figura 31 apresentam-se os principais fornecedores de softwares tipo ERP na
atualidade e no apêndice A exemplos dos recursos de personalização do ERP SAP R/3.
Fornecedor do Software Nome do Software
Avalon Software Avalon CIIM
Quad.inc MRG/PRO
SAP America SAP R/3
Symix Cumputer Systems Symix Advanced Manufacturing Inc.
Baan Triton
People Soft People Soft
J.D.Edwards World
Figura 31 – Principais fornecedores de software ERP Fonte: Stair e Reynolds (2002, p.265)
Tendo-se construído um panorama geral do software ERP, no próximo item se
apresenta de forma sucinta as principais características do software ERP da SAP
América, o SAP R/3.
2.5.2 O sistema ERP SAP R/3, uma visão geral
Em www.sap.com.br (acesso Nov/02), se encontra a definição do SAP R/3
como:
[...] uma aplicação de negócios funcional, construída com uma estrutura modular completamente integrada que o torna extraordinariamente flexível e expansível. Foi concebido considerando os padrões da indústria em sistemas abertos com ambiente cliente/servidor e interface gráfica do usuário.
64
O sistema SAP R/3 é um sistema construído em módulos independentes, os
quais podem ser implementados segundo as necessidades e/ou escolhas do cliente, e
serem implementados em uma única etapa ou em várias etapas, ou por fases.
Na Figura 32, se apresenta a descrição dos principais módulos do SAP R/3.
• Recursos Humanos (HR) • Contabilidade Financeira (FI) • Controladoria (CO) • Investimentos de Capital (IM) • Tesouraria (TR) • Vendas e Distribuição (SD) • Manutenção (PM)
• Materiais (MM) • Controle de Qualidade (QM) • Projetos (PS) • Produção (PP) • Produção em Ind. de Processos
(PP/PI) • Controle de Empresa (EC) • Workflow (WF)
Figura 32 – Principais módulos do sistema SAP R/3 Fonte: www.sap.com.br (acesso em Nov/02)
Na Figura 33 se apresenta a representação esquemática da instalação e das
relações de alguns dos principais módulos de um software SAP R/3.
Figura 33 – Representação esquemática da integração de alguns módulos do SAP R/3 Fonte: Elaborada pelo autor
65
Observa-se na representação esquemática apresentada na Figura 33, que os
diversos módulos que compõem o programa, interagem uns com os outros. Além disto,
na Figura 33, se apresentou o esquema de uma configuração (arranjo) que é mais
comum em empresas que trabalham com projetos e sistema SAP R/3. Nestes casos,
como representado esquematicamente pela figura, o módulo PS passa a ter uma grande
integração com praticamente todos os demais módulos do sistema. Está integração se
deve ao fato dos projetos ser os elementos que consolidam a quase totalidade das
informações e dados, criados na execução das atividades diárias das organizações
voltadas para o gerenciamento de projetos.
Um conjunto das principais características e conceitos chaves dos sistemas SAP
R/3, segundo Stair e Reynolds (2002, p. 266-269), estão resumidas nas Figura 34.
Característica/Conceito Descrição / Definição para sistema SAP R/3
Clientes Clientes em geral, são computadores Pentium com no mínimo 32 megabytes de RAM. O sistema SAP R/3 suporta centenas até milhares de clientes.
Servidores de aplicativos
Servidores são poderosos computares médios ou mesmos mainframes. Num sistema SAP R/3 pode existir muitos servidores de aplicativos.
Interface de programação
para aplicação de negócios
(BAPIs)
Business Application Programming Interfaces (BAPIs), são interfaces públicas. Estas interfaces foram desenvolvidas com clientes SAP, com organizações de desenvolvimento de softwares e seguindo padrões de organização, permitem integrar outros aplicativos ao SAP R/3.
Servidor de banco de dados
Mantém os dados sendo acessados e atualizados constantemente. Dependendo do hardware escolhido, os bancos de dados podem ficar em várias máquinas ou em uma única.
Objeto Consiste em um conjunto de dados e em programas para processar dados. O “pedido de compra” e “clientes”, são exemplos de objetos no sistema SAP R/3.
Repositórios È um dicionário de dados, ágil de forma que os dados novos ou modificados no repositório estão imediatamente disponíveis para todo o sistema.
Tabelas Locais onde são armazenadas todas as informações do sistema dividem-se em: tabelas de configuração do sistema, de controle e aplicação.
ABAP/4 Linguagem de programação de 4º geração da SAP. Programa desenvolvido para atender a necessidades especifica do negócio no SAP R/3, são chamados de ABAP.
Figura 34 – Principais características/conceitos do Sistema SAP R/3 Fonte: Adaptado de Stair e Reynolds (2002, p.266-269)
66
Ainda segundo Stair e Reynolds (2002, p.269) as características apresentadas na
Figura 34 para o sistema SAP R/3, são similares aos sistemas ERP de outros
fornecedores mundiais como a People Soft, Oracle e outros.
Os recursos para realização das atividades ou operações relacionadas com a
Gestão de Projetos no sistema SAP R/3, se concentram no módulo Projetos (PS), o qual
de acordo com página da internet da SAP www.sap.com.br (acesso Nov/02) apresenta
os seguintes recursos disponíveis:
Dados Mestres / Dados do Projeto / Planejamento do Projeto / Planejamento de Custos / Gestão de Orçamento / Cronograma de Atividades / Implementação e Execução do Projeto / Integração de Sistemas Operacionais / Logísticos / Integração de Sistemas de HR/FI/CO/SD/PM/MM / Sistemas de Informação / Grau de Avanço do Projeto / Liquidação do Projeto.
Na Figura 35, a representação esquemática de como funciona o sistema SAP
R/3, a partir de uma perspectiva global. Nas empresas que possuem sistemas SAP R/3,
os usuários entram com informações, como por exemplo: número de pedido de compra,
EAP para projetos, diagramas, etc., na execução de suas várias atividades diárias, o que
na Figura 35 é o processo de início. Após a entrada de informações/dados, o sistema
SAP R/3 processa os mesmos em diversos bancos de dados (também conhecidos como
tabelas) e os apresenta aos usuários na forma de relatórios e/ou documentos (conhecidos
como objetos), este dois processo são a execução na Figura 35. O usuário no final, com
base nas informações interpreta e reinicia o processo ao realizar novas entradas de
informações no sistema no processo de início, para corrigir ou completar alguma
informação/dado. Este processo se repete indefinidamente, assim sendo, a qualidade dos
dados entrados no sistema ERP é fundamental para integridade do sistema.
Partindo desta visão abrangente pode-se concluir como Corrêa e Gianesi (1996,
p.54), que embora os sistemas de administração da produção, conhecidos genericamente
pela sigla SAP (e conseqüentemente os ERP):
[...] não sejam suficiente para garantir, por si só, o sucesso competitivo de uma organização (já que os sistemas produtivos são sistemas, que dependem da interação de todos os seus componentes, não só infra-estruturais – como os SAP – mas, também com igual relevância, de seus componentes estruturais – as pessoas e os equipamentos e instalações). Entretanto, certamente, é condição necessária para que uma organização atinja sucesso competitivo”.
A integração e o treinamento para utilização de forma produtiva dos ERP em
todo seu potencial parecem ser o grande desafio das organizações que os adotaram.
PROCESSO
ONDE/QUEM
ANÁLISE
INICIO EXECUÇÃO ANÁLISE / DECISÃO / AÇÃO
SAP SAP SAP/
BANCO DE DADOS A
BANCO DE DADOS B
BANCO DE DADOS C
AÇÕES EXTERNAS
REALIMENTA- ÇÃO DO SISTEMA
ENTRADA DE DADOS NO SISTEMA
SISTEMA PROCESSA
INFORMAÇÕES
INFORMAÇÕES EM
RELATÓRIOS
USUÁRIO USUÁRIO USUÁRIORC
PC
NF N
LEGENDA: PC (Pedido de Compra); RC (Requisição de Compra); NF (Notas Fiscais); N (Representação para outras entradas diversas)
Figura 35 – Visão macro do funcionamento do Sistema SAP R/3 Fonte: Elaborado pelo autor
67
3 METODOLOGIA
Realizar simulações em sistema ERP do tipo SAP R/3 versão 4.6c, para
possibilitar a análise e comparação da aplicação das técnicas da teoria de Gestão de
Projetos referentes a:
Construção da Estrutura Analítica do Projeto (EAP);
Diagramas de precedência com técnica CPM;
Elaboração de cronogramas tipo Gráfico de Gantt;
Relatórios e recursos para auxiliar o acompanhamento dos projetos.
O plano das simulações no sistema SAP R/3, seguiu a seguinte seqüência:
1. Elaboração de uma estrutura analítica para o exemplo da Figura 12 -
Representação de uma EAP para construir uma casa na página 38 e para
projeto e instalação de um programa de software para uma empresa fictícia.
2. Elaboração de diagrama de precedência e gráfico de Gantt, utilizando-se a
técnica CPM com os dados da Figura 15 - Exemplo de lista de atividades
para construção de uma casa na página 42 e para desenvolvimento e
instalação de um software em uma empresa fictícia retirada da bibliografia.
3. Verificar se existem relatórios disponíveis no ERP que possam ser
utilizados para auxiliar o acompanhamento físico dos projetos.
Para interpretar e verificar o grau de aderência dos resultados das simulações dos
três itens anteriores realizadas no sistema SAP R/3 em relação à teoria sobre gestão de
projetos estudada na revisão de literatura. Realizou-se análise comparativa e qualitativa
dos resultados, utilizando-se para tanto os parâmetros indicados na literatura como
desejáveis nos softwares utilizados para gestão de projetos, como: facilidade de uso,
clareza das informações, integração das informações, etc., além da verificação da
consistência dos resultados em relação à teoria de gestão de projetos. Durantes as
simulações, sempre que pertinente, se buscou explorar os pontos fortes ou limitações,
bem como fornecer sugestões de maneiras mais produtivas para utilizar os recursos
disponíveis nos sistemas SAP R/3.
As simulações foram realizadas no mandante de testes do sistema SAP R/3 da
unidade produtiva em Taubaté da empresa Alstom Brasil Ltda, o qual é uma cópia das
customizações do mandante de produção. A configuração do sistema SAP R/3 na
Alstom foi realizada por um grupo de funcionários com apoio de consultoria externa e
acompanhamento de especialistas da filial da empresa SAP no Brasil.
4 RESULTADOS E DISCUSSÃO
4.1 Projeto fictício para realização da simulação
Para realização das simulações, além da execução dos exemplos apresentados na
revisão da literatura, será utilizado um caso fictício elaborado com base em exemplo
encontrado no trabalho de Prado (2001, p. 217 e 224) conforme Figura 36 e 37, onde se
apresentam os pacotes de trabalho, as atividades e os prazos.
O projeto apresentado na Figura 36 pode ser resumido como segue, adaptado de
Prado (2001, p.213):
Titulo do Projeto: Financial 2004
Gerente do Projeto: José Nixon Soares
Cliente: Financial
Objetivo gerencial:
Desenvolver e implementar aplicativo de captação e análise do mercado de
ações para a empresa Financial.
Datas:
O prazo previsto para o projeto é de vinte e sete meses, iniciando-se em 01 de
janeiro de 2005 e finalizando-se em 27 de março de 2007.
Escopo do Projeto:
Desenvolvimento e implementação de aplicativo de captação e análise do
mercado de ações, conforme detalhado na Proposta Técnica, constituído de:
Sistema de cadastramento do cliente.
Sistema de acompanhamento do mercado de ações.
Sistema de auxílio na tomada de decisões.
Sistema de controle gerencial.
O que não vai ser feito: não se fará nenhuma alteração nos outros sistemas de
informatizados atuais da Financial.
Premissas ou expectativas: todo o planejamento do projeto foi elaborado com a
expectativa de que a Financial colocará a disposição da Prosoft os profissionais
necessários para a realização do projeto.
Restrições: todos os feriados e férias deverão ser respeitados. Preferencialmente
não se trabalhará em horas extras e finais de semana.
70
Figura 36 – EAP do Projeto Financial Fonte: Adaptado de Prado (2001, p.217)
71
Figura 37 – Etapas do projeto de implementação de um software Fonte: Adaptado de Prado (2001, p. 217)
72
4.2 Elaboração da EAP no ERP SAP R/3
4.2.1 A tela de criação da EAP no ERP SAP R/3 – visão geral
A Figura 38 mostra a tela de criação da EAP no SAP 4.6c, onde são indicadas as
principais funções/recursos.
Figura 38 – Visão da tela de criação da EAP do Sistema SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Na barra azul superior tem-se os comando do sistema, indo de Projeto,
Processar, Ir para, Elemento PEP, Detalhe, Suplemento, Sistema e Ajuda, logo abaixo
tem uma série de ícones ( ) que são
atalhos para comandos, observa-se que a configuração da tela é similar a do Windows
2000 da Microsoft.
No campo onde se cria a EAP se tem uma séria de janela
( ).
Dados básicos: onde se vê os dados da EAP elaborada, entre estes, o nível e o
código do elemento PEP (componente da EAP), a denominação, o código breve, e
outras informações.
Datas: nesta seção é possível visualizar as datas do projeto.
Atribuições: define parâmetros para integração projeto com a área financeira.
Responsabilidade: nesta seção, pode se informar e visualizar os responsáveis
pela execução do pacote de trabalho.
Controle: nesta seção são realizadas as definições referentes a integração da
EAP com relação ao controle de custos do sistema.
Total: nesta seção é possível visualizar todas as informações anteriores, numa
73
única seção, sendo uma síntese das seções ou pastas: dados básicos, datas, atribuições,
responsabilidade e controle.
4.2.2 Simulação de criação da EAP no ERP SAP R/3
Nas Figuras 39 e 40 se apresenta a EAP no SAP 4.6c para o PRJ de uma casa
conforme Figura 12 à página 38 e para o Projeto da Financial conforme Figura 36 a
pagina 70.
Figura 39 – Visão da EAP no Sistema SAP R/3 para PRJ Casa da Figura 12 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 40 – Visão da EAP no Sistema SAP R/3 para PRJ Financial da Figura 36 Fonte: Simulação elaborada pelo autor no SAP R/3
74
Na Figura 41 vemos a seção responsabilidade, para o Projeto Financial no SAP
R/3 apresentado na Figura 39. Observa-se que o nome do gerente do projeto aparece nos
níveis 1 e 2 (elementos PEP S.100 e S.100-A), e os nomes dos responsáveis pelo demais
pacotes de trabalho, aparecem em frente ao respectivo elemento PEP. As opções de
entradas (nomes dos responsáveis) podem ser facilmente configuradas pelo usuário,
para atender as necessidades de cada projeto.
Figura 41 – Visão da EAP com responsáveis para PRJ Financial no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Na Figura 42, a seção Datas para o projeto Financial, onde se visualiza a seção
Datas-base e se pode selecionar as seções: Datas previstas, Datas Reais ou Síntese de
Operações para o projeto.
Figura 42 – Visão da seção Datas para EAP do PRJ Financial no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
75
Confrontando as informações apresentadas nas Figuras 39 a 42 referentes à
simulação no SAP R/3 da criação da EAP, observa-se que as mesmas apresentam as
EAP em forma de tabela, porém para se obter toda a informação disponível, é necessária
a consulta de mais de uma seção. Uma forma de se contornar está limitação e se obter a
EAP em forma de tabela com todas as informações, pode ser a utilização de um dos
relatórios de estruturas, conforme exemplo apresentado na Figura 43.
Figura 43 – Relatório de estrutura no SAP R/3 para a EAP do Projeto Financial Fonte: Simulação elaborada pelo autor no SAP R/3
O relatório apresentado na Figura 43 pode ser manipulado de diversas formas,
inclusive com relação às colunas as serem exibidas e em relação à ordem das mesmas.
Além disto este relatório pode ser exportado para planilha do MS-Excel se necessário
conforme apresentado na Figura 44 e 45, onde pode ser formatado a critério do usuário.
Figura 44 – Relatório do PRJ Financial exportado para o MS-Excel a partir do SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
76
Figura 45 – PRJ Financial criado em MS-Excel a partir do SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Analisando-se os resultados das simulações apresentados nas Figuras 39 a 45,
pode-se concluir que o sistema ERP SAP R/3 apresenta ferramentas e flexibilidade
suficiente para permitir elaborar a EAP em forma de tabela conforme visto na revisão da
literatura.
A partir das mesmas telas/comandos, apresentados nas Figuras 39 a 42, é
possível se obter no sistema SAP R/3 a visão da EAP na forma de árvore conforme
exemplo apresentado na Figura 46 e 47 para o projeto Casa da Figura 12 à página 38 e
para o projeto Financial da Figura 41 à página 74, respectivamente.
Figura 46 – EAP do PRJ Casa - Fig. 12 na forma de árvore no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
77
Figura 47 – EAP do PRJ Financial na forma de árvore no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Observando-se o exemplo de Figuras 46 e 47 e os conceitos vistos na revisão de
literatura, pode-se concluir que o sistema ERP SAP R/3 é capaz de atender ao requisito
de elaborar a EAP em forma de árvore invertida.
Uma última observação a ser realizada com relação à criação de EAP no ERP
SAP R/3, é que o mesmo trabalha com o conceito de Definição de Projeto, onde este
corresponde a um contrato, o qual pode ser quebrado em um ou mais pacotes nível 1,
onde cada nível 1 da estrutura EAP corresponderia a um projeto, ver Figura 38.
Além disto o código para identificação dos elementos que compõem a EAP
pedem ser alfanuméricos, somente numéricos ou somente letras, a critério dos usuários,
desde que seu tamanho máximo não ultrapasse 24 caracteres. Na Figura 48, pode ser
visualizado um exemplo do que foi exposto. O recurso disponível para criar os códigos
de identificação dos projetos parece razoável, já que, conforme estudado no item 2.2.2,
o mais importante é a padronização dos códigos que são utilizados para indexar todas as
informações sobre os projetos.
Figura 48 – Exemplo de construção de códigos de PEP para uma EAP no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
78
4.2.3 Elaboração da EAP no ERP SAP R/3 a partir de modelos
O ERP SAP R/3 permite elaborar estruturas de EAP a partir de modelos pré-
definidos, conforme exemplo apresentado nas Figura 49 a 51 a seguir:
Figura 49 – Exemplo de uma EAP modelo no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 50 – Exemplo de criação do PRJ S.500 a partir de uma EAP modelo no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Na Figura 49 se tem uma EAP modelo, a partir da execução de um comando
conforme Figura 50, se seleciona os elementos que se deseja ter na nova estrutura
79
(linhas amarelas) e substituem-se os “Z.XXX” por “S.500”, criando-se assim o projeto
S.500 a partir do projeto modelo Z.XXX, com a realização dos passos apresentados nas
Figuras 51 e 52.
Figura 51 – Criação do PRJ S.500 a partir do modelo Z.XXX no SAP R/3 – Passo 1 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 52 – Criação do PRJ S.500 a partir do modelo Z.XXX no SAP R/3 – Passo 2 Fonte: Simulação elaborada pelo autor no SAP R/3
Na Figura 52, se tem o PRJ S.500 criado a partir do PRJ Z.XXX, com os
elementos desnecessários excluídos (linhas brancas), após os passos apresentados na
Figura 51 e 52, clica-se no botão “integrar” canto superior esquerdo e obtém o projeto
80
S.500 conforme apresentado Figura 53 a seguir.
Figura 53 – PRJ S.500 a criado a partir do modelo Z.XXX no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Observando-se os resultados obtidos nas simulações, apresentadas nas Figuras
48 a 53, pode-se concluir que o ERP SAP R/3 apresenta recursos e flexibilidade para
elaboração de EAP a partir de modelos como visto na revisão de literatura.
Importante lembrar que a maior vantagem em se utilizar modelos na criação de
EAP, não está tanto na produtividade, mas sim na padronização dos componentes da
EAP e suas respectivas descrições.
4.3 Planejamento Físico de Projetos em ERP SAP R/3
Nos tópicos a seguir, se apresenta a simulação da elaboração dos diagramas de
precedência e de Gantt para o PRJ Casa apresentado na Figura 28 à página 56 e para o
PRJ Financial da Figura 36 à página 70. Também, discute-se a consistência dos
recursos do ERP do SAP R/3 para estas tarefas, em relação aos conceitos da Gestão de
Projetos estudados na revisão de literatura.
4.3.1 A tela de criação de Diagramas e Cronogramas no ERP SAP R/3 – visão geral
Na Figura 54 se apresenta a tela de criação de Diagramas e Cronogramas para
Projetos no ERP SAP R/3, onde se procurar indicar os principais comandos e recursos
disponíveis.
81
Figura 54 – Visão da tela de criação de Diagramas e Cronogramas no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Na barra azul superior tem-se os comando do sistema, indo de Diagrama de rede,
Processar, Saltar, Operações, Detalhe, Suplementos, Sistema e Ajuda, logo abaixo tem
uma série de ícones ( ) que são atalhos
para comandos, observa-se que a configuração da tela é similar a do Windows 2000 da
Microsoft.
No campo onde se elaboram os diagramas de rede se tem uma série de janelas
( ):
Processm.int: nesta seção, se encontra os dados do diagrama de rede elaborado
ou em elaboração, entre estes, o número da operação, a descrição da operação, duração,
a unidade de medida da duração (dia, semana, mês, etc.), quantidade de trabalho em
horas, o centro de trabalho e outras informações.
Proc.d/terceiros: esta seção contém informações a compra de serviços, outros
módulos do sistema ERP SAP R/3.
Cts,primários: nesta seção, pode se informar e visualizar informações
referentes a custos dos trabalhos planejados nos Diagramas de Rede se o sistema for
assim configurado para estas finalidades.
Total: nesta seção é possível visualizar todas as informações anteriores, numa
única seção, é uma síntese das seções ou pastas: processamento interno, processamento
de terceiros e custos primários.
4.3.2 Simulação de criação de Diagrama de Precedência no ERP SAP R/3
Nas Figuras 55 e 56 se apresenta o diagrama de precedência no SAP R/3 para os
Projetos Casa e Financial das Figuras 39 e 41 nas páginas 73 e 74 respectivamente.
Figura 55 – Diagrama de Precedência para PRJ Casa no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
82
Figura 56 – Diagrama de Precedência para PRJ Financial no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
83
84
Observa-se que o diagrama de precedência para a casa apresentado na Figura 55
indica que para a realização deste projeto o caminho crítico é composto pela seqüência
das atividades 10, 20, 30, 50, 80, 100 e 120, as quais estão na cor vermelha.
A Figura 56 apresenta o diagrama de rede para o elemento S.100.A.3 do PRJ
Financial. Observa-se, que o caminho crítico do diagrama de rede é identificado pela
cor vermelha nas atividades, na Figura 57 o detalhe de como o SAP R/3 detalha as
atividades no diagrama de precedência.
Figura 57 – Detalhe das atividades no diagrama no SAP R/3 da Figura 56 Fonte: Simulação elaborada pelo autor no SAP R/3
Na Figura 58 a legenda, identificando cada uma das informações apresentadas
nas atividades do diagrama de precedência no SAP R/3. Observa-se que a mesma possui
as mesmas informações apresentadas na Figura 24 na revisão de literatura.
Figura 58 – Legenda das atividades no diagrama no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Para o Projeto Financial, foi criado um diagrama de rede para cada elemento do
projeto, no sistema SAP R/3 conforme relação apresentada na Figura 59.
85
Figura 59 –Lista dos diagramas precedência criados no SAP R/3 para PRJ Financial Fonte: Simulação elaborada pelo autor no SAP R/3
Analisando-se as informações obtidas e os resultados das pesquisas e simulações
apresentadas nas Figuras 55 a 59, pode-se concluir que o SAP R/3 apresenta recursos e
flexibilidade suficiente para realizar a construção de diagramas de precedência para
projetos, atendendo as definições vistas na revisão da literatura.
4.3.3 Relações possíveis de serem utilizadas nos Diagramas no ERP SAP R/3
Na revisão de literatura foi verificado que existem quatro tipos de relações
utilizadas na construção de diagramas de rede ou precedência: Fim-Início, Início-Fim,
Início-Início e Fim-Fim (ver item 2.3.3.1).
O sistema ERP SAP R/3, apresenta recursos que possibilitam elaborar diagramas
de precedência utilizando qualquer uma das relações, como pode ser observado nas
Figuras 60 a 64.
Observar que a relação entre a nomenclatura encontrada no ERP SAP R/3 e a
teoria sobre Gestão de Projeto para a denominação das relações entre as operações dos
diagramas de rede são:
PV – Seqüência Normal = Relação Fim-Início
SP – Seqüência de Salto = Relação Início-Fim
LO – Seqüência de Início = Relação de Início-Início
CU – Seqüência de Fim = Relação de Fim-Fim
86
Figura 60 – Tipo de relações possíveis em diagramas no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 61 – Relação de Fim-Início em diagramas no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 62 – Relação de Início-Fim em diagramas no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
87
Figura 63 – Relação de Início-Início em diagramas no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 64 – Relação de Fim-Fim em diagramas no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
4.3.4 Simulação de criação de Gráfico de Gantt no ERP SAP R/3
Nas Figuras 65 e 66 se apresenta o diagrama de Gantt no SAP R/3 para os
diagramas de precedência do PRJ de uma casa conforme Figura 55 à pagina 82, e para o
Projeto da Financial conforme Figura 56 à página 83.
O caminho crítico no diagrama de barras ou de Gantt no SAP R/3, Figuras 65 e
66, apresenta as atividades com as barras na cor vermelha, ou seja, o caminho critico é
composto pela seqüência de atividades 10, 20, 30, 50, 80, 100 e 120 para PRJ Casa e 10,
20, 40, 70 e 80 para PRJ Financial.
Observa-se que o caminho crítico no diagrama de barras ou de Gantt no SAP
R/3 para o PRJ Financial, Figura 66, além das atividades do caminho crítico estarem na
cor vermelha, ele também está com a apresentação de um marco de fim de atividades
para cada uma das atividades que compõem o caminho crítico.
Observando-se o resultados obtidos com as simulações no SAP R/3 conforme
apresentado nas Figuras 65 e 66, pode-se concluir que o sistema ERP SAP R/3
apresenta recursos e flexibilidade suficiente para atender os conceitos vistos na revisão
de literatura sobre a elaboração de diagramas de barra ou Gantt.
Figura 65 – Diagrama de Gantt para PRJ Casa da Figura 55 no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
88
Figura 66 – Diagrama de Gantt para PRJ Financial da Figura 56 no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
89
90
4.3.5 Exportação do diagrama gráfico de Gantt do ERP SAP R/3 para MS-Project
O ERP SAP R/3, permite que os diagramas de rede criados sejam exportados
para software MS-Project. Para tanto é necessário que o usuário, tenha um programa
especial instalado em seu micro para realizar a integração dos softwares, muitas versões
desses programas são livres e podem ser obtidos na internet.
Nas Figuras 67 a 70 está apresentado um exemplo da exportação do diagrama de
rede do PRJ Financial da Figura 59.
Figura 67 – Transferência do diagrama de rede do SAP R/3 para MS-Project – Passo 1 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 68 – Transferência do diagrama de rede do SAP R/3 para MS-Project – Passo 2 Fonte: Simulação elaborada pelo autor no SAP R/3
91
Figura 69– Transferência do diagrama de rede do SAP R/3 para MS-Project – Passo 3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 70 – Diagrama de rede do SAP R/3 do PRJ Financial transferido para MS-Project Fonte: Simulação elaborada pelo autor no SAP R/3
4.4 Recursos para integração da EAP com os Diagramas de Rede no ERP SAP R/3
O sistema ERP SAP R/3 apresenta recursos para a realização da programação
dos elementos dos projetos e dos cronogramas ou diagramas de rede de forma integrada,
conforme visto no item 2.3.6 e Figura 29. Os recursos do sistema SAP R/3 para
realização destas operações, são demonstrados pelas Figuras 71 a 74 a seguir,
utilizando-se o projeto de simulação S.100 – Projeto Financial.
92
Figura 71 – Comando para buscar datas para EAP nos diagramas no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 72 – Datas programadas da EAP atualizada com datas dos diagramas - SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
93
Figura 73 – Comando programar prazos na EAP no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 74 – EAP com programação atualizada - SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
As Figuras 71 a 74 apresentam a simulação da utilização dos recursos do SAP
R/3 para realizar a programação da EAP a partir dos cronogramas (diagramas) no
sistema. A programação de prazos da EAP do Projeto Financial – S.100 apresentada na
Figura 66 foi realizada na modalidade Bottom-up, ou seja, de baixo para cima, conforme
customização do sistema. Na Figura 75, se observa que o sistema desde que
devidamente customizado, pode executar a programação Top-down, ou seja, de cima
para baixo.
94
Figura 75 – EAP PRJ Financial, detalhe das opções de programação Fonte: Simulação elaborada pelo autor no SAP R/3
Nas Figuras 76 e 77, a demonstração da integração dos elementos da EAP com
os respectivos diagramas de rede (cronogramas), a partir da EAP.
Figura 76 – Comando para visualizar cronograma no SAP R/3 a partir da EAP Fonte: Simulação elaborada pelo autor no SAP R/3
95
Figura 77 – Cronograma do PRJ Financial visualizado a partir da EAP no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Analisando-se as informações obtidas e os resultados das pesquisas e simulações
apresentadas nas Figuras 71 a 77, pode-se concluir que o SAP R/3 apresenta recursos e
flexibilidade suficiente para realizar a integração e a programação de prazos da EAP e
cronogramas (diagramas de rede), atendendo as recomendações e definições vistas na
revisão da literatura.
4.5 Recursos para gestão de documentos no ERP SAP R/3
O ERP SAP R/3, apresenta recursos integrados de gestão de documentos, os
quais possibilitam que documentos sejam anexados aos elementos da estrutura da EAP,
desde que o módulo DMS do sistema esteja instalado e configurado. As Figuras 78 e 79
apresentam um exemplo de como este recurso funciona e pode ser utilizado.
Figura 78 – Comando para buscar ou anexar documento a elemento da EAP no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
96
Figura 79 –Visualizando o documento a partir da EAP no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 80 – Documento ORC-100 aberto no Ms-Word a partir da EAP no SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
O documento apresentado na Figura 80 foi aberto no MS-Word, a partir da EAP
no SAP R/3, se encontra no apêndice B.
97
Este recurso do SAP R/3 permite que documentos importantes da Gestão de
Projetos, criados em outros softwares como MS-Excel ou MS-Word, sejam vinculados
aos elementos da EAP e a partir dos mesmos consultados por vários usuários desde que
o sistema ERP SAP R/3 tenha o módulo de DMS configurado.
Este é mais um exemplo dos recursos verificados de integração do ERP SAP R/3
com outros softwares.
4.6 Os relatórios para gestão física dos projetos no ERP SAP R/3
Um dos recursos que muito auxilia os gerentes de projetos na execução de seus
trabalhos, é a possibilidade e se obter relatórios sobre as diversas informações
registradas nos bancos de dados.
Em relação às informações geradas e registradas sobre o avanço físico dos
projetos. O software ERP SAP R/3 apresenta um conjunto abrangente de relatórios para
gestão física de projetos, conforme demonstrado pela Figura 81. Os relatórios mais úteis
para a obtenção de informações sobre o planejamento físico dos projetos no ERP SAP
R/3, é o grupo de relatórios reunidos sob o nome de estrutura.
Figura 81 – Árvore de relatórios do ERP SAP R/3 sobre estruturas Fonte: Simulação elaborada pelo autor no SAP R/3
Na Figura 82, se abre o grupo de relatórios “Sínteses Individuais” apresentado
na Figura 81.
98
Figura 82 – Relatórios do grupo Sínteses Individuais da árvore de relatórios Estruturas do SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
Para exemplificar os recursos deste grupo de relatórios, nas Figuras 83 a 86
mostram a execução do relatório CN-41 Síntese de Estruturas, por meio do qual se
realizará a exploração dos recursos básicos disponíveis, nos relatórios de estruturas.
Figura 83 – Relatório Síntese de Estruturas do SAP R/3 – tela de entrada Fonte: Simulação elaborada pelo autor no SAP R/3
Na Figura 84 se apresenta o relatório Síntese de Estruturas do projeto S.100 e
nas Figuras 85 a 86 os principais comandos e recursos disponíveis nos relatórios de
Estrutura do ERP SAP R/3.
99
Figura 84 – Relatório Síntese de Estruturas do projeto S.100 Fonte: Simulação elaborada pelo autor no SAP R/3
Figura 85 – Principais comandos do relatório de Estrutura do SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
100
Figura 86 – Principais símbolos utilizados nos relatórios de Estrutura do SAP R/3 Fonte: Simulação elaborada pelo autor no SAP R/3
4.7 Os recursos do ERP SAP R/3 e as técnicas de Gestão de Projeto
Na revisão da literatura, no capítulo 2.4, verificou-se que as características mais
desejáveis de um software para projetos são: simplicidade, velocidade, facilidade de
treinamento e uso em operações, além de algumas outras características chaves.
Com base nas simulações realizadas, apresentadas e discutidas neste capítulo e
os conceitos vistos na revisão da literatura, apresenta-se na Figura 87 uma análise
sintetizada das “características desejadas x relação ao verificado” no ERP SAP R/3.
Com relação às informações tabuladas na Figura 87, alguns comentários
complementares se fazem necessários. O sistema ERP SAP R/3 com relação à
característica simplicidade parece ser atendida de forma satisfatória, uma vez que o
mesmo apresenta, conforme simulações realizadas, grandes similaridades com os
programas MS-Office. Já com relação à velocidade, a mesma está mais diretamente
relacionada com a capacidade dos hardwares utilizados e volume de informações
processadas e armazenada ao longo do tempo.
O treinamento pode ser considerado um dos fatores críticos para o sucesso.
Durante a realização das simulações, ficou evidente que se o sistema for operado por
pessoas sem conhecimentos razoáveis dos recursos e possibilidades do sistema, a
101
produtividade e qualidade dos trabalhos pode ser seriamente afetadas. É difícil afirmar a
quantidade de treinamento necessário, mas pode-se estimar que cerca de 25h sejam
necessárias para uma completa assimilação dos recursos do sistema para uma pessoa
sem nenhum conhecimento do software, para prepará-la para utilizar o módulo PS.
Características dos softwares utilizados em Gestão de Projetos ITEM
Desejadas No SAP R/3
01 Simplicidade O sistema parece simples, alguns comandos são intuitivos.
02 Velocidade As operações no sistema são executadas com rapidez.
03 Facilidade de treinamento Exige uma carga de treinamento de em torno de 25h para um bom aprendizado de todos os recursos.
04 Uso em operações Apresenta grande flexibilidade para utilização em diversos contextos ou formas.
05 Capacidade para produzir diagramas e cronogramas
Apresenta recursos adequados para tais finalidades
06 Capacidade de calcular folgas nos diagramas de precedência
Apresenta recursos adequados para calcular e recalcular folga nos diagramas de precedência.
07 Capacidade de produzir agendas e relatórios
Apresenta recursos e flexibilidade para personalização de relatórios.
08 Capacidade de produzir gráficos e tabelas
Apresenta recursos para produção de gráficos e tabelas, além de integração com outros softwares, para exportação de informação.
09 Trabalho em grupo e apoio à internet
Apresenta recursos para integração via internet e pode ser utilizado por múltiplos usuários, desde que conectado em rede.
10 Facilidade de uso e programação A utilização parece ser simples, mas a programação deve ser realizada por especialista.
Figura 87 – Características desejadas dos softwares para Gestão de Projetos segundo Keelling x recursos do SAP R/3 Fonte: Elaborado pelo autor com base em Keelling (2002, p.223-224)
Em relação à capacidade do ERP SAP R/3 produzir diagramas de precedência,
cronogramas na forma de gráfico de Gantt e realizar o cálculo das folgas. O sistema
apresentou recursos satisfatórios para realizar estas tarefas de forma rápida e precisa,
além de grande flexibilidade, apresentando recursos para permitir ao usuário escolher as
102
cores e os procedimentos de cálculos das folgas. Conforme visto no capítulo quatro, o
sistema além disto, identifica o caminho crítico do diagrama de precedência. Com
relação a estas atividades, talvez a grande vantagem do ERP seja a sua grande
flexibilidade. A qual permite modificar os parâmetros de prazo, duração, início ou fim
de qualquer atividade e recalcular as folgas e caminho crítico do projeto imediatamente.
O sistema apresenta recursos para produção de gráficos e tabelas, sendo os
recursos de relatórios flexíveis e abrangentes, abarcando todos os aspectos e
informações registradas no sistema, tais como: custos, prazos, datas, responsáveis, etc,
além disto, o sistema apresenta recursos de integração com os softwares da MS-Office o
que permite exportar estas informações para programas como o Excel ou MS-Project.
Com relação a trabalhos em grupos, uma vez que estes sistemas são instalados
em servidores que atendem a redes de micros, este requisito é atendido de forma
satisfatória. Além disto, o sistema ERP SAP R/3 apresenta recursos para integração com
a internet, permitindo que usuários em países diferentes compartilhem e atualizem o
mesmo banco de dados em tempo real (on line).
Com base nas simulações realizadas, pode-se afirmar que a operação requer um
treinamento adequado, porém a programação do sistema exige um conhecimento
detalhado do funcionamento do sistema, mas isto não interfere na utilização do sistema
pelos usuários ou Gerentes dos Projetos.
Pelas simulações realizadas, pode-se observar que os recursos disponíveis no
ERP SAP R/3 aparentemente atendem a todas as necessidades das técnicas de Gestão de
Projeto para construção de EAP e planejamento físico de projetos. Sua única limitação é
o código dos elementos que compõem a EAP, o qual não podem possuir mais do que 24
caracteres, o que parece ser um tamanho razoável, e não ser uma restrição que limite ou
impeça a utilização do sistema ERP SAP R/3 na construção de EAP para projetos.
5 CONCLUSÃO
Com base nos resultados e na discussão realizada sobre as simulações no sistema
ERP SAP R/3, pode-se entender que a resposta à questão colocada no inicio deste
trabalho: “Os sistemas do tipo ERP realmente suportam as técnicas de elaboração de
EAP, cronogramas e diagramas de rede que são utilizadas pelos Gerentes de Projetos
para realizarem seus trabalhos?”, pode ser afirmativa, desde que se aceite a premissa de
que os vários sistemas ERP disponíveis no mercado apresentam recursos similares aos
verificados no sistema SAP R/3.
Além disto, em relação ao objetivo deste trabalho: avaliar a aderência, facilidade
e possíveis limitações do sistema tipo ERP através de realização de simulação no ERP
SAP R/3, das técnicas de elaboração de Estrutura Analítica do Projeto (EAP) ou Work
Breakdown Structure (WBS), construção dos diagramas de redes utilizando a técnica
Critical Path Method (CPM) e a existência de relatórios de apoio, tem-se que as
simulações realizadas e discussões, revistas com base na revisão da literatura, parecem
permitir afirmar que os sistemas SAP R/3:
1. Possuem flexibilidade suficiente para suportar as técnicas de Gestão de
Projeto em diversos contextos industrias.
2. São capazes de realizar a elaboração do diagrama de precedência,
cronogramas na forma de gráfico de Gantt e Estruturas Analíticas dos
Projetos, também conhecidas pelas siglas EAP ou WBS ou EDT ou PEP.
3. Possui relatórios que são úteis como ferramentas de apoio à utilização das
técnicas de Gestão de Projetos e acompanhamento dos projetos.
Se aceita a premissa que os diversos ERP existentes no mercado possuem
recursos similares, pode-se concluir, com base nos testes e na discussão realizada no
item quatro, que os softwares ERP são capazes de suportar de forma satisfatória as
técnicas da Gestão de Projetos no que se refere à construção de EAP, diagramas de
precedência e cronogramas para os projetos, desde que os usuários dominem as técnicas
de Gestão de Projetos e tenham um conhecimento adequado de como utilizar o
software, além de possibilitar realizar estes trabalhos de forma integrada na empresa, em
um único software.
6 PERSPECTIVAS ABERTAS COM A REALIZAÇÃO DO TRABALHO
O presente trabalho se limitou a analisar o atendimento das necessidades das
técnicas de Gestão de Projetos, sobre a construção das EAP e planejamento físico dos
projetos. O mesmo poderá ser enriquecido ou complementado por outros trabalhos que
sejam realizados para estudar as outras ferramentas e técnicas da Gestão de Projeto com
apoio de ERP, dentre as quais destacam-se:
A utilização do ERP para realizar o nivelamento de recursos;
O acompanhamento do avanço físico dos projetos utilizando ERP;
A aderência e atendimento dos ERP à técnica PERT;
A Gestão e Coordenação de múltiplos projetos numa mesma organização
com várias equipes e a utilização do ERP;
O controle de custos e sua integração com o planejamento físico dos projetos
no ERP;
As dificuldades de se treinar pessoas com conhecimento das Técnicas de
Gestão de PRJ na utilização de ERP;
As relações entre as Técnicas de Comunicação e Controle adotadas pela
Gestão de Projeto e o impacto do ERP nas mesmas;
Estudo dos fatores críticos de sucesso da utilização do ERP como ferramenta
de apoio a Gestão de Projetos e o impacto na produtividade.
Os temas sugeridos acima são apenas um exemplo de quão abrangente pode ser
o campo a ser analisado e estudado sobre a utilização dos softwares ERP e as técnicas
de Gestão de Projetos, os quais poderiam vir a ser temas de trabalhos futuros.
REFERÊNCIAS
CLELAND, D. I.;IRELAND, L. R. Gerência de Projetos 1º ed. Rio de Janeiro:
Reichmann & Affonso, 2002. 324 p.
CORRÊA, H. L.; GIANESI, I. G.N. Just In Time, MRP II e OPT um enfoque
estratégico 2º ed. São Paulo: Atlas S.A, 1996. 186 p.
MELHORAMENTOS Mini Dicionário da Língua Portuguesa 22º edição São Paulo:
Cia Melhoramentos de São Paulo, 1997. 252 p.
GAITHER, N.; FRAZIER, G. Administração da Produção e Operações 8 ed. São
Paulo: Pioneira Thomson Learning, 2002. 598 p.
KERZNER, H. Gestão de Projetos: As melhores práticas Porto Alegre-RS: Bookman,
2000. 519p.
KEELLING, R. Gestão de Projetos: uma abordagem global São Paulo: Saraiva, 2002.
293 p.
LAUDON, K. C.; LAUDON, J. P. Gerenciamento de Sistemas de Informação 3º ed.
Rio de Janeiro: LTC, 2001. 433 p.
PRADO, D. Planejamento e Controle de Projetos Série Gerência de Projetos Volume
2 4º ed. Belo Horizonte: Desenvolvimento Gerencial, 2001. 241 p.
PRADO, D. PERT/CPM Série Gerência de Projetos Volume 4 2º ed Belo Horizonte:
Desenvolvimento Gerencial, 1998. 147 p.
RITZMAN, L. P.; KRAJEWSKI, L. J. Administração da Produção e Operações 1º
ed. 2004 São Paulo: Pearson Prentice Hall, 2004. 431 p.
106
STAIR, R. M.; REYNOLDS, G. W. Princípios de Sistemas de Informação 4º ed. Rio
de Janeiro: LTC, 2002. 496 p.
SLACK, N.;CHAMBERS, S.; JOHNSTON, R. Administração da Produção 2º ed.
São Paulo: Atlas, 2002. 747 p.
Site da SAP Brasil em http://www.sap.com.br (acesso em novembro de 2002).
Site da SAP Brasil em http://www.sap.com/brazil/company/historia.asp (acesso em 21
de agosto/2004).
Tradução livre do PMBOK – Project Manager Body Knowledge 2000 v.1.0 recolhido
na internet em <http://www.pmimg.org.br/pmbok/html> - PMI MG (Project Manager
Institute – filial Minas Gerais). Cópia obtida na internet em Março de 2002.
VALERIANO, D. L. Gerência em Projetos: Pesquisa, Desenvolvimento e Engenharia
São Paulo: Markron Books, 1998. 438 p.
VARGAS, R. V. Gerenciamento de Projetos: Estabelecendo diferenciais competitivos
4º ed. Rio de Janeiro: Brasport, 2002. 260 p.
VERZUH, E.; MBA COMPACTO: Gestão de Projetos 9º ed. Rio de Janeiro: Campus,
2000. 398p.
107
ANEXO A – Técnicas de planejamentos e elaboração de diagramas de rede
Além da técnica CPM, existem outras técnicas utilizadas na elaboração e
utilização de diagramas de rede, de acordo com PMBOK 2000 (2002, p.75), as técnicas
matemáticas mais amplamente conhecidas, além da CPM, são:
GERT – Graphical Evaluation and Review Technique: permite o tratamento probabilístico tanto para a rede lógica quanto para as estimativas de duração das atividades. PERT – Program Evaluation and Review: usa uma rede seqüencial e uma estimativa de duração por média ponderada para calcular as durações das atividades. Embora existam diferenças superficiais o PERT difere do CPM fundamentalmente porque usa distribuição de médias (valor esperado) em vez de estimativa mais provável, originalmente usado no CPM. Compressão da duração: é um caso especial de análise matemática que procura alternativas para reduzir o prazo do projeto sem alterar o seu escopo [...]. A compressão da duração inclui duas técnicas Colisão (Crashing) [...] e Caminho Rápido (Fast tracking) [...]. Simulação: A simulação envolve o cálculo de múltiplas durações de projeto com diferentes grupos de premissas nas atividades [...]. Heurística de Nivelamento dos Recursos: as análises matemáticas freqüentemente produzem um cronograma preliminar de datas mais cedo que requer, durante certos períodos de tempo, mais recursos do que a disponibilidade real que estão disponíveis, ou requer alterações inviáveis nos níveis de recursos previstos. [...] O nivelamento de recursos freqüentemente resulta numa duração maior par ao projeto do que o cronograma preliminar. Esta técnica é algumas vezes chamada de “Método Baseado em Recursos” (Resource-based Method) [...]. Softwares de gerência de projetos: são amplamente usados no desenvolvimento do cronograma [...]. Estrutura de codificação: as atividades devem ter uma estrutura de códigos que permitirá classificações e extrações em diferentes atributos designados às atividades, tais como responsável área geográfica ou período, fase do projeto, nível de programação, tipo de atividade, e classificação EAP.
108
ANEXO B – Cálculo da duração das atividades, utilizando a técnica PERT
Quando se utiliza a técnica PERT, deve-se elaborar a estimativas de tempo para
cada atividade, segundo Keelling (2002, p.206) utilizando-se a seguinte fórmula:
te = (to + 4 tm + tp)
6 Onde:
to = a duração mais curta ou mais otimista
tm = a duração mais provável
tp = a duração mais longa ou mais pessimista
Existe uma fórmula alternativa, Keelling (2002, p. 206):
Experiência de alguns patrocinadores de projetos sugere que as estimativas de tempo excessivamente otimistas. Uma fórmula corrigida pode ser obtida mediante o ajuste da curva de distribuição para alcançar uma abordagem mais conservadora do processo de cálculo.
te = (to + 3 tm + 2tp) 6
Prado (1998, p.56-57), amplia a compreensão sobre o modelo estatístico do
PERT:
No chamado modelo estatístico, a duração de cada atividade pode variar, havendo uma probabilidade de ocorrência de cada valor. As durações seguem a distribuição normal ou de Gauss, (Figura 88). Para que seja perfeitamente definida, é necessário o valor da média (duração estimada) e da variância (X2). Esses valores podem ser obtidos de duas formas: • Para atividades que já foram executadas diversas vezes, os valores
da média e da variância são obtidos pelos cálculos normais estatísticos.
• Para as atividades que nunca foram executadas anteriormente, os valores da média e da variância são obtidos a partir de três outros valores de duração, que são estimados pelos responsáveis pelas atividades: duração otimista, duração mais provável e duração pessimista.
Figura 88 – Durações probabilísticas Fonte: Prado (1998, p.61)
109
ANEXO C – Uma crítica às técnicas CPM e PERT
Nos trabalho de Gaither e Frazier (2002, p.554 e 555), se encontra um conjunto
de críticas surgidas após o aparecimento das Técnicas CPM e PERT, as quais são:
1. O CPM/PERT pressupõe que as atividades do projeto são independentes. Na prática sabemos que em algumas circunstâncias a duração de uma atividade depende das dificuldades encontradas no desempenho de outras atividades relacionadas. Nesses casos, a duração de uma atividade depende da duração de uma ou mais atividades.
2. O CPM/PERT pressupõe que existem fronteiras precisa onde uma atividade termina e outra começa. Na prática, uma atividade pode começar antes de uma atividade antecedente se concluída, desde que o trabalho preparatório tenha sido feito.
3. O CPM/PERT se concentra demasiadamente no caminho crítico. Na prática uma atividade que não está no caminho crítico no início do projeto pode encontrar dificuldades e atrasos. Essa atividade pode não receber a atenção que merece até aparecer no caminho crítico, e aí pode ser tarde demais para tornar uma medida corretiva para evitar que o projeto atrase.
4. As estimativas dos tempos podem refletir questões comportamentais que podem diminuir a utilidade do CPM/PERT. Por exemplo, as pessoas que fornecem as estimativas podem ser otimistas demais, podem estimar a duração de atividades longas demais, o que lhes dá um fator de amortecimento ou de ultrapassagem de limites.
5. A PERT foi muitas vezes criticada porque: (a) pode ser irreal esperar três estimativas de duração precisas do pessoal; (b) pode ser esperar demais que o pessoal entenda seus conceitos estatísticos; (c) foi demonstrado que as hipóteses de PERT no que diz respeito as distribuições de probabilidade das atividades e dos caminhos provocaram erros nos resultados PERT; (d) o custo extra da PERT em relação a COM não é justificado pelo valor das informações adicionais fornecidas.
6. O CPM/PERT aplica-se a uma quantidade excessiva de projetos, um legado arrasador do governo e da indústria aeroespacial. Em muitas dessas aplicações, o custo do CPM/PERT não pode ser justificado pelo valor das informações fornecidas quando comparado a outras técnicas de gerência de projetos, como gráficos de projetos.
Gaither e Frazier (2002, p. 555) comentam e refutam as críticas anteriores:
Apesar das críticas, o CPM/PERT forma a família das técnicas amplamente utilizadas hoje nas organizações. Essas técnicas ajudam os gerentes de operações a estruturar projetos de forma que se entenda que atividades precisam ser executadas e quanto, identifiquem as medidas corretivas que precisam ser tomadas, atribua responsabilidades pelas atividades, controle, custos, e planeje e controle o desempenho em termos de tempo. A verdade é que eles funcionam – e funcionam bem – [...] apesar das falhas [...].
APÊNDICE A – Exemplos dos recursos de personalização do ERP SAP R/3
Figura 89 – Exemplos dos recursos de personalização do ERP SAP R/3 Fonte: Sistema SAP R/3 4.6c
110
111
APÊNDICE B – Ordem de Realização ORC Nº 100
Figura 90 – Documento ORC-100 na simulação do item 4.5 Fonte: Exemplo elaborado pelo autor
112
GLOSSÁRIO DE ABREVIATURAS E TERMOS
Aderência: Dic. Melhoramentos (1997, p.480); (1) Ato de aderir; (2) Qualidade do que é aderente. Atividade: Gaither e Frazier (2002, p.538); são uma tarefa ou uma determinada quantidade de trabalho necessário no projeto. ADM (Arrow Diagramming Method): PMBOK 2000 (2002, p.70); é um método de rede que utiliza setas para representar atividades e os conecta por meio de nós que representam as dependências. Está técnica também é conhecida como AOA (Activity-on-arrow). AOA (Activity-On-Arrow): PMBOK 2000 (2002, p.70); é um método de rede que utiliza setas para representar atividades e os conecta por meio de nós que representam as dependências. AON (Activity-On-Node): PMBOK 2000 (2002, p.69); é um método de rede que utiliza retângulos para representar atividades e os conecta por setas que representam as dependências. CPM (Critical Path Method): Keelling (2002, p.272); ou método do caminho crítico. Uma técnica de rede baseada na duração das atividades e do projeto para determinar a seqüência e os tempos de folga. Cronograma: Vargas (2002, p.225); a sincronização e a seqüência de atividades em um projeto [...]. Cronograma Mestre: Vargas (2002, p.225); Cronograma sumarizado que identifica as atividades e marcos principais. Declaração do escopo: PMBOK 2000 (2002, p.56); a declaração do escopo fornece a documentação que servira de base para tomada de decisões futuras no projeto e para confirmar ou desenvolver um entendimento comum do escopo entre as partes envolvidas. Decomposição: PMBOK 2000 (2002, p.58); a decomposição envolve subdividir os principais subprodutos do projeto em componentes menores, mais manejáveis, até que os subprodutos estejam definidos em detalhes suficientes para suportar o desenvolvimento das atividades do projeto (planejar, executar, controlar e fechar). Diagrama de Barras: Vargas (2002, p.225); uma representação gráfica de informações relacionadas à programação. [...] Também é chamado de Cronograma de Gantt. Dignitário: Dic. Melhoramentos (1997, p.166); Indivíduo que exerce um cargo elevado ou goza de um título. EAP (Estrutura Analítica do Projeto): PMBOK 2000 (2002, p.59-60); é um agrupamento de componentes de projeto (orientado para elaboração de subprodutos – deliverable-oriented) que organiza e define o escopo total do projeto. Segundo Prado
113
(2001, p.94), a EAP também é conhecida por: EDT – Estrutura de Decomposição do Trabalho e WBS – Work Breakdown Structure. EDT (Estrutura de Decomposição do Trabalho): Valeriano (1998, p.191); é uma forma de apresentação dos projetos que o explicita em suas partes físicas, em softwares, serviços e outros tipos de trabalho, a qual organiza, define e graficamente mostra tanto o produto a ser feito como o trabalho a ser realizado para obtê-lo. Entradas: PMBOK 2000 (2002, p.32); documentos ou itens documentáveis que influenciarão o processo. Entregas: Vargas (2002, p. 163); são todos os resultados físicos, ou semiprodutos, obtidos ao longo do projeto. Evento: Gaither e Frazier (2002, p.538); sinaliza o inicio ou fim de uma atividade. Estratégia: Valeriano (1998, p.420); arte de preparar e aplicar os meios e especificar os cursos de ação, considerando as oportunidades e ameaças, para alcançar ou manter os objetivos fixados pela Política. Estrutura de Decomposição: Valeriano (1998, p.420); conjunto ordenado hierarquizado das partes constitutivas de uma entidade. A estrutura geralmente é apresentada sob a forma de uma relação organizada segundo os níveis de decomposição, de um diagrama de blocos, organograma (estrutura de uma organização) ou de uma árvore de decomposição. ERP (Enterprise Resource Planning): Stair e Reynolds (2002, p.476); planejamento de recursos empresariais, conjunto de programas integrados que gerenciam as operações de negócios vitais de todas as unidades de uma organização. Escopo: Vargas (2002, p.230); o somatório de produtos e serviços realizados como um projeto. EVA (Earned Value Analysis): Valeriano (1998, p.235); processo que permite exercer o controle integrado de custos, prazos e do trabalho efetivamente realizado no decorrer do projeto. Ferramentas e Técnicas: PMBOK 2000 (2002, p.32); mecanismos aplicados á entradas para criar as saídas. Gerente de Projetos: Vargas (2002, p.234); indivíduo responsável pelo gerenciamento de projetos. Gerência de Projetos: PMBOK 2000 (2002, p. 6); é a aplicação de conhecimentos, habilidades e técnicas para projetar atividades que visem atingir os objetivos do projeto. Gráfico de Gantt: Vargas (2002, p.225); uma representação gráfica de informações relacionadas à programação [...].
114
Hardware: Stair e Reynolds (2002, p.473); qualquer maquinário (a maioria dos quais usam circuitos digitais) que auxilia as atividades de entrada, processamento, armazenamento e de saída de um sistema de informações. Insumos: Valeriano (1988, p.421); tudo aquilo que é fornecido a um processo para utilização, transformação ou consumo e que se constitui de recursos (humanos, materiais e financeiros) e serviços (administrativos ou gerenciais, de apoio: transporte, secretariado, etc.). Implementar: Dic. Melhoramentos (1997, p.480); (1) Executar um plano projeto, etc.; (2) Levar a prática por meio de providências concretas. Internet: Vargas (2002, p.235); rede mundial composta por milhares de pequenas redes de computadores e milhões de computadores comerciais, educacionais, governamentais e pessoais. A Internet é semelhante a uma cidade eletrônica, com bibliotecas virtuais, fachadas de lojas, escritórios comerciais, galerias de arte, etc. Loop: Vargas (2002, p. 235); um caminho de rede que passa pelo mesmo ponto duas vezes. Os loops não podem ser analisados utilizando-se as técnicas tradicionais de análise de rede, como CPM e PERT. Os loops são permitidos nos GERT. Mandante: www.sap.com.br (consulta em Nov/02); unidade comercial, organizacional e tecnicamente auto-contida em um Sistema SAP. Os mandantes têm os seus próprios registros mestres e conjuntos de tabelas. O mandante é o nível máximo da hierarquia no Sistema SAP. As especificações feitas, ou os dados entrados neste nível são válidos para todas as empresas e para todas as outras estruturas organizacionais. Portanto, é necessário fazer essas especificações, ou entrar esses dados somente uma vez. Isto assegura a consistência dos dados. A definição de unidade organizacional mandante é obrigatória; Marco (milestone): Keelling (2002, p.274); termo empregado por alguns planejadores de projeto para indicar uma etapa significativa no andamento do projeto. Pacote de trabalho: Vargas (2002, p.162); o produto a ser entregue no mais baixo nível da estrutura analítica do projeto WBS. Paradoxo: Dic. Melhoramentos (1997, p.377); opinião contrária a comum. PDM (Precedence Diagramming Method ou Método do Diagrama de Precedência): PMBOK 2000 (2002, p.69); é um método de rede que utiliza retângulos para representar atividades e os conecta por setas que representam as dependências, também são denominados de AON (activity-on-node). PERT (Programme evaluation and review technique): Keelling (2002, p.275); técnica de avaliação e revisão de programas. O uso de métodos do caminho crítico para planejar, acompanhar e avaliar o andamento de um projeto ou atividade. Planejamento: Valeriano (1998, p.423); processo que estabelece, com antecedência, as decisões e ações a serem executadas em um dado futuro, para atingir objetivos definidos.
115
Planejamento Estratégico: Valeriano (1998, p.74); aquele nível mais alto e mais abrangente, em geral de longo prazo, que, a partir dos objetivos fixados na política, define os meios e os cursos de ação, de forma geral e abrangente para toda a organização, considerando seu relacionamento com o mundo exterior: governo, clientes, fornecedores, competidores etc. Planejamento Tático: Valeriano (1998, p.74); Plano Diretor ou Plano Setorial em que são traçadas as linhas gerais que devem servir de orientação para os planos que estão entre o nível estratégico e o operacional (como quando, onde e por quem). Muitas vezes substituídos por Diretrizes. Planejamento Operacional: Valeriano (1998, p.74); Plano Operacional (baseado no plano diretor/setorial) em que são determinadas as ações dos componentes da organização (como, quando, onde, por quanto e por quem), podendo se revestir de formas diversas [...] Plano Estruturado do Projeto (PEP): Vargas (2002, p. 162); uma outra denominação para Estrutura Analítica do Projeto ou Work Breakdown Structure. PMI® (Project Manager Institute): Cleland e Ireland (2002, p.22); foi fundado em 1969, por seis pessoas que tinham enorme interesse em promover a gerência de projetos. O esforço inicial dessas pessoas nos EUA expandiu-se para o Canadá, o Brasil e a África do Sul. Até 1999, o quadro de membros havia subido para 106 países no mundo, continuando a consolidar-se nas nações em desenvolvimento. PMBOK® (A Guide to the Project Management Body of Knowledge): Cleland e Ireland (2002, p.22); é o padrão mundial para gerência de projetos, documento elaborado pelo PMI®, contém os conhecimentos e metodologia coerente e comprovada (aceita) para a gerência de projetos. Este documento já foi traduzido para seis idiomas: francês, japonês, espanhol, russo, ucraniano e português. Política: Valeriano (1998, p.74); arte de estabelecer os objetivos e intenções de uma organização, mediante a interpretação de seus interesses e aspirações, e de orientar a obtenção ou a preservação daqueles objetivos. Processo: Valeriano (1998, p.424); conjunto de recursos e atividades inter-relacionados que transformam insumos (entradas) em produtos ou resultados (saídas). (ISSO 8402: 1.2.). Produto: Valeriano (1998, p.424); resultado de atividades ou processos. (ISSO 8402: 1.4). Premissas: PMBOK 2000 (2002, p.43); suposições, são fatores que para os propósitos do planejamento, são considerados verdadeiros, reais ou certos. Profissional do Gerenciamento de Projetos: Vargas (2002, p.238) indivíduo certificado como tal pelo Project Manager Institute – PMI. Também chamado PMP.
116
Project Manager Professional (PMP®): Cleland e Ireland (2002, p.24); único programa de certificação mundialmente reconhecido para praticantes da gerência de projetos, realizado pelo Project Manager Institute (PMI®). Project Manager Institute (PMI): Cleland e Ireland (2002, p.22-23); foi fundado em 1969 por seis pessoas que tinham enorme interesse em promover a gerência de projetos. O esforço inicial dessas pessoas nos EUA expandiu-se para o Canadá, o Brasil e a África do Sul. Projeto: PMBOK 2000 (2002, p.4); é um empreendimento temporário com o objetivo de criar um produto ou serviço único. Relatório descritivo da estrutura: Valeriano (1998, p.426); relatório que tem por finalidade descrever a estrutura do produto ou do processo e de seus componentes. Restrições: PMBOK 2000 (2002, p.43); uma restrição é uma limitação aplicável que afetará o desempenho do projeto. RSI: autor da monografia; abreviatura de Retorno Sobre o Investimento, em inglês ROI – Return Over Investiment. 1. Mensuração comum da eficiência administrativa da empresa, segundo a proporção do lucro líquido em relação ao investimento. 2. Valor líquido gerado por um investimento em determinado período de tempo. Em termos percentuais, significa a taxa representada pelo valor líquido em relação ao investimento total. Saídas: PMBOK 2000 (2002, p.32); documentos ou itens documentáveis resultados do processo. SAP: http://www.sap.com/brazil/company/historia.asp (acesso em 21 de agosto/2004) Systemanalyse and Programmentwicklung.- Sistemas, Aplicações e Produtos para Processamento de Dados. Singular: Dic. Melhoramentos (1997, p.480); (1) Notável, extraordinário; (2) Especial particular; (3) Esquisito, excêntrico; (4) Distinguir-se de outro (s); [...]. Software: Valeriano (1998, p.426); criação intelectual compreendendo programas (de computador), procedimentos (1), regras e qualquer documentação correlata á operação de um sistema de processamento de dados. (ISSO 9000-3). Sub-rede: Vargas (2002 p.240); uma subdivisão do diagrama de rede do projeto, usualmente representando alguma forma de subprojeto. Subprojeto: Vargas (2002, p.240); projeto inserido em outro projeto. Os subprojetos são usados como uma maneira de dividir projetos complexos em partes com melhor gerenciamento. É também conhecido como projeto inserido. WBS (Work Breakdown Structure): Verzuh (2000, p.134); ou Estrutura de Desmembramento do Trabalho (EDT) é a ferramenta para desmembrar um projeto em seus componentes e partes.
