ads:
Fabiano Sannino
A Dinâmica em um Projeto de Tecnologia de Grande Porte
Dissertação de Mestrado (Opção profissional)
Dissertação apresentada como requisito parcial para
obtenção do título de Mestre pelo Programa de Pós-
Graduação em Engenharia Industrial da PUC-Rio.
Orientador: Silvio Hamacher
Rio de Janeiro
Fevereiro de 2006
PUC-Rio - Certificação Digital Nº 0321251/CA
ads:
Fabiano Sannino
A Dinâmica em um Projeto de Tecnologia de Grande Porte
Dissertação apresentada como requisito parcial para
obtenção do título de Mestre pelo Programa de Pós-
Graduação em Engenharia Industrial da PUC-Rio.
Aprovada pela Comissão Examinadora abaixo assinada.
Silvio Hamacher
Orientador
PUC-Rio
Silvio Hamacher
PUC-Rio
Luiz Felipe Roris Rodriguez Scavarda do Carmo
PUC-Rio
José Roberto Blaschek
PUC-Rio
José Eugenio Leal
Coordenador(a) Setorial do Centro Técnico Científico - PUC-Rio
Rio de Janeiro, 16 de fevereiro de 2006
PUC-Rio - Certificação Digital Nº 0321251/CA
Todos os direitos reservados. É proibida a reprodução total ou
parcial do trabalho sem autorização do autor, do orientador e da
universidade
Fabiano Sannino
Graduou-se em Engenharia Elétrica pela Escola de Engenharia
Mauá em 2000. Obteve o título de especialização de
Administração de Negócios pela Fundação Getúlio Vargas- SP
em 2005. Associado da Sociedade Brasileira de Dinâmica de
Sistemas. É consultor de negócios em uma grande empresa do
setor de tecnologia, onde atua profissionalmente desde 2001.
Ficha Catalográfica
CDD:658.5
Sannino, Fabiano
A dinâmica em um projeto de tecnologia de grande
porte / Fabiano Sannino ; orientador: Silvio Hamacher. – Rio
de Janeiro : PUC, Departamento de Engenharia Industrial,
2006.
v. 108 f. : il. (col.) ; 30 cm
Dissertação (mestrado) – Pontifícia Universidade
Católica do Rio de Janeiro, Departamento de Engenharia
Industrial.
Inclui referências bibliográficas.
1. Engenharia industrial – Teses. 2. Dinâmica de
sistemas. 3. Gestão de projetos. 4. ERP. I. Hamacher, Silvio.
II. Pontifícia Universidade Católica do Rio de Janeiro.
Departamento de Engenharia Industrial. III. Título.
PUC-Rio - Certificação Digital Nº 0321251/CA
ads:
Para meus pais, que me suportaram.
Para Mirela, que sempre me acompanhou.
Para meus amigos, que me estimularam.
PUC-Rio - Certificação Digital Nº 0321251/CA
Agradecimentos
Ao meu orientador Silvio Hamacher, que aceitou, orientou e estimulou um
trabalho diferenciado para meus objetivos.
Ao Professor Phokion_Sotirios_Georgiou que me aconselhou e mostrou a trilha
correta que tornou possível finalizar essa dissertação.
Aos meus amigos Rafael Nora Tannus e Leise Kelli de Oliveira, que me ouviram,
apoiaram e auxiliaram.
A Mirela Margarotti do Anjos, por suas incontáveis palavras de conforto e
carinho.
Ao Adolfo Gonzalez e Eduardo Raffaini que entenderam o objetivo dessa
conquista e me apoiaram.
Aos meus Pais, por entenderem minhas metas e sempre me suportarem.
A todos os professores que participaram da banca examinadora
A todos meus amigos e familiares.
Pois sem eles, este trabalho não teria sido finalizado.
PUC-Rio - Certificação Digital Nº 0321251/CA
Resumo
Sannino, Fabiano; Hamacher, Silvio. A Dinâmica em um Projeto de
Tecnologia de Grande Porte. Rio de Janeiro, 2006. 108 p. Dissertação de
Mestrado (Opção profissional) - Departamento de Engenharia Industrial,
Pontifícia Universidade Católica do Rio de Janeiro.
Este trabalho apresenta um estudo de Dinâmica de Sistema como uma
ferramenta de apoio às decisões da gerência de um projeto, procurando
demonstrar sua utilização e aplicação em um projeto de implementação
tecnológica de grande porte. O trabalho visa possibilitar que a gestão do projeto
possua uma ferramenta de análise que proporcione a antecipação das
interferências existentes nos projetos, como a necessidade de adição de recursos,
ingerência nas decisões do projeto, alterações de escopo e solicitação de
atividades adicionais não relacionadas diretamente ao projeto. A análise da
dinâmica requer a manipulação de muitas variáveis, necessitando de ferramentas
que auxilie a gerência do projeto na sua visão e compreensão do projeto como um
todo. Com a técnica proposta, gerentes, tomadores de decisão e gestores em geral
poderão analisar as variáveis de um processo e suas dependências no projeto.
Inicialmente, o trabalho apresenta uma parte teórica relacionada à Dinâmica de
Sistemas apresentando um breve histórico da técnica e informações conceituais.
Em seguida discorre sobre implementações de projetos de Enterprise Resource
Planning (ERP), suas principais características, modelos conceituais, fases,
principais produtos existentes e estruturação da equipe necessária para o projeto.
Seqüencialmente apresentamos os principais modelos causais e formais de gestão
de projetos, realizando uma aplicação baseada nos conceitos de implementação de
ERP, demonstrando o funcionamento das principais influências existentes.
Palavras-chave
Dinâmica de Sistemas; Gestão de Projetos; ERP.
PUC-Rio - Certificação Digital Nº 0321251/CA
Abstract
Sannino, Fabiano; Hamacher, Silvio. The dynamics in a large scale
technology project. Rio de Janeiro, 2006. 108p. MSc.Dissertation (Opção
profissional) - Departamento de Engenharia Industrial, Pontifícia
Universidade Católica do Rio de Janeiro.
This work presents a study of the System Dynamic as a support tool for
decisions of the project leadership, demonstrating its use and application in a
large-scale technology implementation project. Its objective is to make possible
for the project management to have an analysis tool that provides the anticipation
of the projects’ existent interferences, such as the need of additional resources,
project decisions failures, scope changes, requests for additional activities not
directly related to the project. The dynamic analysis requires the manipulation of
many variables and needs a tool that supports the project leadership in their vision
and better understanding of the overall project. With the proposed technique,
project leadership, decision makers and managers in general can analyze the
variables of a process and their dependencies. First, the work describes the theory
related to System Dynamic, presenting a brief technique history and conceptual
information. After that, it explains about Enterprise Resource Planning (ERP)
implementation projects, their main characteristics, conceptual models, phases,
main products and the required organizational structure. Afterwards, it introduces
the main project management hard (formal) and soft (causal) models, applying the
system dynamic based on the ERP implementation concepts and demonstrating
the existing influences.
Keywords
System Dynamic, Project Management, ERP.
PUC-Rio - Certificação Digital Nº 0321251/CA
Sumário
1.1 Objetivos gerais 14
1.2 Objetivos específicos 14
1.3 Delimitações 15
1.4 Estrutura do Trabalho 16
2 Teoria da Dinâmica de Sistemas 17
2.1 História da Dinâmica de Sistemas 17
2.2 Base da Dinâmica de Sistemas 18
2.3 Conceitos da Dinâmica de Sistema 19
2.3.1 Sistema 20
2.3.2 Pensamento Sistêmico 22
2.3.3 Características da Dinâmica de Sistemas 23
2.4 Definição de Modelo 24
2.4.1 Modelo Soft 25
2.4.1.1 Estrutura dos Modelos de Dinâmica de Sistemas 25
2.4.2 Modelagem Hard 28
2.4.2.1 Características do Diagrama de Estoques e Fluxos 30
2.4.3 Softwares de Simulação 33
3 Projetos de Implementação Softwares de ERP e o Escritório de 36
Gestão de Projetos
3.1 Introdução sobre Implementação de ERP 36
3.2 A estratégia de Implementação do software de ERP 39
3.2.1 Aspectos da Gestão de Projetos de ERP 41
3.2.2 Fases de um projeto de implementação 42
3.2.3 Organização de um projeto 45
3.2.3.1 Escritório de Gerenciamento de Projetos: 47
4 Estudo da Dinâmica de um Projeto 50
4.1 A visão da Dinâmica de um Projeto – Modelo Mental 50
4.2 Ciclo de Retrabalho – Modelo Formal 63
PUC-Rio - Certificação Digital Nº 0321251/CA
5 Aplicação da Modelagem Dinâmica de um Pojeto de ERP 72
5.1 O Modelo Dinâmico 72
5.2 O Diagrama Causal 74
5.3 O Diagrama Formal 86
6 Conclusões 95
7 Referências Bibliográficas 98
8 Anexos 102
PUC-Rio - Certificação Digital Nº 0321251/CA
LISTA DE FIGURAS
Figura 1 - Diagrama Estrutura de Sistema ..............................................24
Figura 2 - Ciclo de Realimentação ...........................................................26
Figura 3 - Esperas....................................................................................28
Figura 4 – Elementos Chaves da Dinâmica de Sistemas.........................29
Figura 5 – Fluxos .....................................................................................31
Figura 6 – Estoque ..................................................................................32
Figura 7 - Ferramentas de modelagem de negócios ...............................34
Figura 8 – Abordagem em Série ..............................................................40
Figura 9 - Abordagem Faseada................................................................40
Figura 10 - Abordagem Big Bang .............................................................41
Figura 11 - Fases da Implementação do Projeto......................................42
Figura 12 - Detalhamento das Fases da Implementação do Projeto........43
Figura 13 - Organograma de um projeto de ERP ....................................47
Figura 14 - Diagrama de Comunicação versus Execução do Projeto ......49
Figura 15 – Ciclo de paralelismo básico...................................................53
Figura 16 – Ciclo de paralelismo considerando a consolidação do
sistema .............................................................................................54
Figura 17 – Ciclo de paralelismo considerando recursos disponí veis
limitados.............................................................................................55
Figura 18 – Esquema de paralelismo.......................................................55
Figura 19 – Estrutura de Trabalho............................................................56
Figura 20 – Estrutura de Pressão no Cronograma...................................57
Figura 21 - Estrutura de Retrabalho .........................................................57
Figura 22 - Estrutura de Trabalho Disponível...........................................59
Figura 23 - Estrutura de Qualidade ..........................................................60
Figura 24 - Estrutura do Escopo...............................................................61
Figura 25 - Modelo do Fluxo de Erros por Múltiplas Fases ......................63
Figura 26 - Esquema tradicional...............................................................64
Figura 27 - Esquema tradicional com o acréscimo da influência da
produtividade e das pessoas.............................................................64
Figura 28 – Ciclo de Retrabalho...............................................................65
PUC-Rio - Certificação Digital Nº 0321251/CA
Figura 29 – Ciclo de Retrabalho com Retrabalho não identificado...........65
Figura 30 – Influência da Utilização Horas Extras....................................67
Figura 31 – Resultado realmente ganho com diferentes quantidades
de horas extras de trabalho...............................................................67
Figura 32 – Influência da Contratação de Novos Funcionários................69
Figura 33 – Influência da Contratação de Pessoal...................................70
Figura 34 – Influência da Pressão para Respeitar o Cronograma............71
Figura 35 - Diagrama de Fluxo de Produtos e Retrabalho em um
Projeto de Tecnologia .......................................................................73
Figura 36 – Digrama Causal – Trabalho e Escopo do Projeto .................76
Figura 37 – Diagrama Causal - Relação entre a qualidade, geração de
erros e retrabalho..............................................................................78
Figura 38 – Diagrama Causal - Moral da Equipe e Nível de Confiança
do Gestor ..........................................................................................80
Figura 39 - Diagrama Causal – Duração, Intensidade de Trabalho. ........83
Figura 40 - Diagrama Causal – Execução dos desenvolvimentos na
fase de realização de um projeto de Implementação tecnológica.....85
Figura 41- Tela de definição inicial do Vensim PLE. ................................87
Figura 42 – Diagrama Formal tradicional .................................................87
Figura 43 – Gráfico de Progresso – Base do Diagrama formal
Tradicional.........................................................................................88
Figura 44 -Trabalho em execução ou demanda de recursos de
durante o projeto ...............................................................................89
Figura 45- O ciclo de retrabalho ..............................................................90
Figura 46 - Gráfico do Trabalho em execução .........................................91
Figura 47- Diagrama Formal do Ciclo considerando o retrabalho não
identificado ........................................................................................92
Figura 48 - Gráfico do trabalho em execução com e sem a
consideração de retrabalhos não identificados. ................................93
Figura 49- Gráfico do Retrabalho ainda não identificado .........................94
PUC-Rio - Certificação Digital Nº 0321251/CA
LISTA DE QUADROS
Quadro 1 - Diferenças entre as modelagens Soft e Hard.........................25
Quadro 2 – Mapa dos processos de gestão de projetos .........................50
Quadro 3 – Seis Estruturas de Realimentação .......................................61
Quadro 4 - Resultado da simulação com modelos formais descritos.......94
PUC-Rio - Certificação Digital Nº 0321251/CA
1
INTRODUÇÃO
Projetos de tecnologia de grande porte, como a implementação de uma
ferramenta de Enterprise Resource Planning (ERP, também conhecida como
Planejamento de Recursos Empresariais) são usualmente projetos de grande impacto
financeiro e organizacional dentro de uma empresa. Dessa forma, os impactos
existentes na realização do projeto, nos quesitos de modificação de prazo, escopo,
custo e qualidade, podem ser de grande abrangência na estrutura da empresa.
Projetos de grande porte possuem um ambiente mutável, onde as políticas,
estímulos dos funcionários e condições de contorno que direcionam o projeto se
alteram a todo o momento. Comumente, para obter sucesso, o gestor do projeto
precisa tomar decisões baseadas em informações inadequadas, onde o discernimento
e a visão dos fatos são incompletos, dessa forma impedindo ter um conjunto de
decisões corretas e focadas, ampliando por sua vez, o efeito do atraso causado por re-
trabalho, atrasos, qualidade, estímulo do funcionário ou mau planejamento.
A gestão de projetos é atualmente uma disciplina utilizada em diversos tipos de
atividades. Esta prática vem sendo cada vez mais adotada, havendo um grande
aumento no número de profissionais e de empresas investindo tempo e dinheiro na
formação e implementação dessa prática, com o intuito de minimizar os impactos das
variações existentes dentro e fora do projeto.
Quando analisamos com maior profundidade a situação que rodeia esses
projetos, se percebe que as situações do cotidiano tornam-se complexas, sendo
necessário fragmentá-las para uma tentativa parcial de resolução.
Se tomarmos a visão sistêmica de um projeto, veremos que ele se comporta
como uma malha de inúmeros nós, onde o estímulo externo aplicado em um nó
afetará todos os outros em intensidades diferentes (Ford, 1995). Esse estímulo poderá
ser aumentado ou atenuado se transmitido de um nó para outro. A busca de integração
e intercâmbio no fluxo de informação e nos elementos de um sistema motivou a
criação da Dinâmica de Sistemas, apoiada pela teoria de controle, por modelos
matemáticos e pela simulação computacional.
PUC-Rio - Certificação Digital Nº 0321251/CA
14
Neste trabalho, a teoria da Dinâmica de Sistemas será utilizada para estudar a
execução do produto de desenvolvimento da fase de realização em um projeto de
implementação da ferramenta ERP, analisando características como o aumento da
tensão da equipe, utilização de recursos e tempo acima do planejado.
O modelo tratado nesse trabalho tem uma natureza genérica, embora o problema
seja estudado especificamente. O modelo enfatiza mais a estrutura de um projeto e
suas principais características, do que a análise de parâmetros e suas sensibilidades no
sistema.
1.1 Objetivos gerais
O presente trabalho propõe apresentar a técnica de Dinâmica de Sistemas como
ferramenta de suporte para a gerência de um projeto de ERP, apoiando o
planejamento de atividades e trabalho com a compreensão das situações ambientais,
bem como das estruturas que afetam a execução de um projeto de tecnologia.
A utilização da Dinâmica de Sistemas nesse trabalho se dará pela execução dos
conceitos de modelagem de sistema, facilitadas pela utilização de ferramentas
computacionais, como o software Vensim, disponível gratuitamente para uso
acadêmico (http://www.vensim.com).
1.2 Objetivos específicos
O modelo possibilita:
• Apresentar ao gestor uma forma rápida para entender as influências
internas existentes no projeto.
• Definir os principais enlaces causais em um projeto de tecnologia
• Estruturar um modelo formal de Dinâmica de Sistema básico, com
algumas das principais estruturas e principais pontos de controle.
PUC-Rio - Certificação Digital Nº 0321251/CA
15
1.3 Delimitações
Em um projeto de tecnologia, uma das maiores questões é sua grande
complexidade durante todas suas fases. Devido às características distintas que temos
em um projeto desse porte, esse trabalho concentra-se em um número limitado de
produtos estabelecidos para equipe de desenvolvimento dentro da fase de realização,
conforme será apresentado posteriormente, sendo abordado apenas fatores e questões
internas ao projeto.
1.4 Estrutura do Trabalho
Esse trabalho está dividido em 5 partes:
A primeira parte aborda brevemente o histórico sobre a disciplina de Dinâmica
de Sistemas, revendo o embasamento teórico necessário para o desenvolvimento do
modelo.
A segunda parte descreve a metodologia de implementação de ERP utilizada,
onde se estabelece o escopo de atuação das fases e produtos do projeto, além de
definir a atuação da gestão do projeto na realização da implementação.
Na terceira parte é apresentado os principais modelos causais (soft) e modelos
formais (hard), conceituados pela literatura de Dinâmica de Sistemas, mostrando o
processo de modelagem, principais participantes da modelagem, definição das
fronteiras de atuação, desenvolvimento dos diagramas de causas e criação de um
modelo formal de projeto.
A apresentação dos modelos causal e formal aplicados a projeto, baseados nos
estudos de Ford (1995) e Sterman (2000), estão na quarta parte, onde são descritos os
nós, as interligações, as suposições assumidas e suas traduções no modelo aplicado ao
produto de desenvolvimento dentro de um projeto. Na quinta parte é apresentado a
aplicação do modelo simulando situações críticas do sistema.
Na última parte são expostos conclusão e comentários gerais. Dessa pretende-se
proporcionar uma visão sistêmica de uma implementação de ERP, a partir de uma
PUC-Rio - Certificação Digital Nº 0321251/CA
16
técnica de modelagem de interesse para sistemas onde os elementos são intangíveis e
complexos.
PUC-Rio - Certificação Digital Nº 0321251/CA
2
TEORIA DA DINÂMICA DE SISTEMAS
A teoria da Dinâmica de Sistemas é um estudo com uma abrangência ampla e
complexa, com várias vertentes desenvolvidas a partir dos estudos de Jay W.
Forrester. Esse capítulo apresentará as principais características existentes na Teoria
da Dinâmica de Sistemas, sua origem, a teoria envolvida na simulação e as técnicas
de modelagem existentes.
2.1 História da Dinâmica de Sistemas
A técnica utilizada em Dinâmica de Sistemas foi criada ao longo do século 20,
pelo professor Jay W. Forrester do Instituto Tecnológico de Massachusetts e
apresentada inicialmente em seu livro Industrial Dynamics (Forrester, 1961).
Forrester utilizou técnicas de ciências e engenharia, para analisar a utilização de
sistemas de realimentação em processos administrativos, com intuito de investigar os
motivos dos fracassos de corporações.
As aplicações de suas idéias ganharam força quando se iniciou o envolvimento
de empresas como a General Eletric, que durante os anos 50 utilizou a metodologia
para solucionarem problemas como a instabilidade dos funcionários da planta de
Kentucky, onde pelos estudos tradicionais não se encontravam explicações
suficientes que explicassem os fatos.
Entre 1950 e 1960, foram formados diversos estudantes no campo da Dinâmica
de Sistemas. Nessa época, também foi criada uma primeira linguagem para simulação
dinâmica, chamada SIMPLE (Simulation of Industrial Management Problems with
Lot of Equations), liderado por Richard Bennett em 1958.
PUC-Rio - Certificação Digital Nº 0321251/CA
18
Em 1959, foi criado o DYNAMO (Dynamic Models), uma evolução do
SIMPLE, criado por Phyllis Fox e Alexander Pugh, que tornou-se a linguagem
padrão durante os próximos 30 anos.
Forrester fortalece seu interesse de Dinâmica de Sistemas em problemas sociais
e econômicos complexos, culminando em sua terceira obra, o “World Dynamics”
(Forrester, 1971).
Suas obras tiveram rápida reação no meio acadêmico, pois até então nenhum
outro modelo de “Dinâmica de Sistemas” foi tão minuciosamente discutido por tantas
pessoas. O livro “World Dynamics” contém modelos de simulação, que mostram
como aumentos exponenciais na população e no consumo de recursos naturais
conduzem a crises de poluição e fome, a menos que se tome alguma medida,
principalmente nas políticas econômicas.
A aplicação de Dinâmica de Sistemas está crescendo substancialmente,
suportando desde soluções em problemas de gestão empresarial e economia, indo até
ecologia, fenômenos sociais e educação.
2.2 Base da Dinâmica de Sistemas
As bases do conhecimento da Dinâmica de Sistemas originaram-se
principalmente dos conceitos de realimentação e da teoria dos servomecanismos
(sistema de controle no qual a grandeza de saída é de natureza mecânica), originários
da cibernética e da engenharia (Fernandes, 2003).
O conceito de cibernética foi definido e elaborado pelo matemático Norbert
Wiener em 1948, que através do trabalho de Wiener, Ashby e von Foerster, entre os
anos de 1940 e 1950, ganhou força, tendo como interesse inicial a demonstração da
semelhança entre sistemas autônomos, seres vivos e máquinas (Principia Cybernetic
technology, 2005).
A cibernética pode ser compreendida como uma teoria de comunicação e
controle, aplicada aos animais, sociedades e máquinas. Esta teoria possui três
elementos principais: realimentação, auto-regulação (homeostasis) e o controle, onde
a ênfase está normalmente na identificação de condições que possam levar à
PUC-Rio - Certificação Digital Nº 0321251/CA
19
instabilidade, e o terceiro é a informação transmitida em resposta, que está associada
a redes de comunicação e teoria de informação (Arnold et al. apud Batista Filho
2001, Mohapatra et al. 1994).
Historicamente podemos dividir os avanços e estudos relacionados à
Cibernética em dois movimentos amplos:
− “Movimento Cibernético de Primeira Ordem”, onde o sistema analisado
fica fora do controle do criado. Sendo que sua compreensão é baseada em
representações simplificadas da realidade, focando apenas no propósito que
foram originados, excluindo aspectos sistêmicos. (Vasconcelos, 2003);
− “Movimento Cibernético de Segunda Ordem”, que a partir do
fortalecimento da engenharia de controle e da informática no início dos
anos 70, fez com que os caminhos da cibernética se distinguissem da visão
mecanicista existente, enfatizando pontos como a autonomia, auto-
organização, cognição e o papel do observador na modelagem de um
sistema (Principia Cybernetica Technology, 2005).
2.3 Conceitos da Dinâmica de Sistema
O conceito central para Dinâmica de Sistemas está em entender como os objetos
de um sistema interagem entre si, pois tanto os objetos quanto as pessoas em um
sistema interagem através de laços de realimentação, onde uma mudança em uma
variável afeta outras variáveis. Com o passar do tempo, essas modificações por sua
vez alteram a variável original, e assim consecutivamente (SDEP, 2005).
Vemos em sistemas complexos a existência de nós e malhas de realimentação
que mascaram a tradicional análise de eventos, sistemas estes modificados pela
simples ótica de causa e efeito. O pensamento sistêmico propõe uma “outra forma” de
analisar e compreender os sistemas complexos que aparecem no mundo real, como
organizações sociais, comportamentos individuais e fenômenos físicos que ao
receberem estímulos reagem de forma muito mais complexa que uma simples
resposta (SBDS, 2005)
A Dinâmica de Sistemas objetiva elaborar modelos de simulação que reflitam
situações analisadas através do Pensamento Sistêmico. Através destes modelos
PUC-Rio - Certificação Digital Nº 0321251/CA
20
podemos compreender melhor o comportamento dinâmico do problema ou do
fenômeno sendo estudado.
Dinâmica de Sistemas é uma técnica na qual sistemas sociais não lineares,
dinâmicos e complexos podem ser entendidos e analisados, através de interações.
Além disso, novas políticas e estruturas podem ser desenhadas para melhorar o
comportamento do sistema (Mohapatra et al.,1994).
Para aprimorar a compreensão da metodologia utilizada na Dinâmica de
Sistemas e seus princípios, descreveremos a seguir alguns conceitos importantes de
sistemas e pensamento sistêmico.
2.3.1 Sistema
A origem da palavra sistemas é “systema”, derivada de “syn”, que significa,
“juntamente”, “conjuntamente”, “ao mesmo tempo”, e “hystema”, que significa
“estabelecer”. Assim, “sistema” literalmente significa “estabelecer conjuntos”.
Segundo Gordon (1969), para entendermos a definição de sistema é necessário
possuir uma visão ampla da finalidade, complexidade e interdependências entre os
elementos analisados. Podendo assim, de forma abrangente, definir sistema como
uma agregação ou reunião de objetos coesos em alguma interação regular ou
interdependente.
Seguindo a mesma linha, Kim (1998) define sistema como qualquer grupo de
partes que possuem interação, inter-relação, ou interdependência e de forma
complexa e unificada, possuindo uma proposição específica.
De acordo com Jenkis apud Mohapatra et al (1969), as principais
características de sistema são as seguintes:
− Um sistema é um agrupamento complexo de humanos e de máquinas;
− Um sistema pode estar formado de subsistemas, a quantidade de detalhes
dos subsistemas depende do problema que está sendo estudado. Os
diagramas de fluxo dão a descrição de um caminho para o real
entendimento desses subsistemas;
PUC-Rio - Certificação Digital Nº 0321251/CA
21
− As saídas de um dado subsistema proporcionam a entrada de outros
subsistemas. Assim, um subsistema interage com outro subsistema e,
portanto, não podem ser estudados isoladamente;
− O sistema que está sendo estudado, usualmente, formará parte de uma
hierarquia de tais sistemas. O sistema superior é muito importante e exerce
considerável influência no sistema abaixo dele;
− Para funcionar, o sistema deve ter um objetivo, mas este objetivo é também
influenciado pelos demais sistemas do qual ele forma parte. Normalmente,
os sistemas possuem múltiplos objetivos que estão em conflito um com o
outro; assim, é requerido um objetivo geral que afete os compromissos
entre esses objetivos conflitantes;
− Para funcionar com a máxima eficiência, um sistema deve ser projetado de
tal forma que seja capaz de alcançar seu objetivo geral da melhor forma
possível.
De acordo com as características definidas, podemos classificar os sistemas de
diversas formas diferentes. Das classificações mais clássicas, e melhores aplicadas à
dinâmica de sistemas, podendo dividir um sistema em dois tipos básicos, (Forrester,
1976): os sistemas de ciclo aberto (enlaces abertos) e os sistemas de ciclo de
realimentação ou fechado (enlaces fechados).
Segundo Forrester (1976), um sistema de ciclo aberto é caracterizado por saídas
(output) que respondem a entradas (inputs), porém as saídas estão isoladas das
entradas e não exercem influência sobre estas. Um sistema de ciclo aberto não
reconhece e nem reage à sua própria performance, dessa forma a ação passada não
controla a ação futura. Forrester (1976) exemplifica dizendo que um automóvel é um
sistema aberto, pois por si só não governou a sua ação passada e não tem uma meta
para onde se deslocar no futuro. Ele mostra que boa parte dos aparelhos mecânicos
são sistemas de ciclo aberto.
Segundo Fernandes (2003), um sistema aberto se caracteriza por relações de
causa e efeito lineares, pois apesar da causa redundar num efeito, este efeito não
realimenta a causa geradora, ou seja, não existe realimentação (feedback). Nesse tipo
de estrutura unidirecional de causa e efeito, o pressuposto é que a informação sobre o
PUC-Rio - Certificação Digital Nº 0321251/CA
22
estado do sistema orienta uma decisão, acarretando uma ação, que leva a um
resultado. Quando a informação do estado do sistema não se altera, permanecendo
estática, toda a decisão e a ação presente não influenciam as decisões futuras e não
alteram o sistema.
Um sistema de ciclo de realimentação ou fechado é influenciado pelo seu
próprio comportamento passado, possuindo uma estrutura em circuito fechado, onde
a saída influencia a entrada, ou seja, onde a causa e o efeito se confundem, pois
qualquer influência de um componente do sistema é, ao mesmo tempo, causa e efeito.
Em outras palavras, uma causalidade não tem um único sentido. Podemos
exemplificar com os sistemas sociais e ecológicos.
Realimentação é uma seqüência fechada de causa e efeito, isto é, um caminho
fechado de ação e informação (Richardon e Plugh apud Kirkwood, 1998).
Em uma perspectiva de realimentação, o mundo é visto interconectado, com
diversos relacionamentos circulares, que afetam diretamente o próximo membro da
cadeia e assim por diante.
2.3.2 Pensamento Sistêmico
O avanço da visão mecanicista apresentada no avanço da cibernética e as
impossibilidades de explicar diversas questões apresentadas em sistemas biológicos
tornaram-se os principais fatores para o desenvolvimento da ciência dos sistemas,
que, apoiada em diversas disciplinas da ciência, deu origem ao pensamento sistêmico
e à teoria geral dos sistemas, apresentada inicialmente por Bertalanffy (1975).
Kim (1998) apresentou o pensamento sistêmico como a forma de ver e falar
sobre a realidade que nos auxilia a entender e trabalhar melhor com sistemas para
influenciar a qualidade de nossas vidas. Assim, o Pensamento Sistêmico é a
capacidade de se conhecer o ambiente enquanto um todo e conseguir prever as
conseqüências de uma ação com base no encadeamento e nas dependências
existentes. Uma forma holística de pensar que contribui para a compreensão de
sistemas complexos e que quando utilizado em aplicações no mundo real ajuda a
PUC-Rio - Certificação Digital Nº 0321251/CA
23
promover a eficiência da gestão, descrevendo e apresentando formalmente os
sistemas.
2.3.3 Características da Dinâmica de Sistemas
Segundo Kirkwood (1998), existem quatro níveis hierárquicos na estrutura de
um sistema dinâmico:
− Limite fechado: isto não significa que as funções de sistemas não possuam
integração com o ambiente externo, mas que os elementos importantes, que
criam as causas e efeitos do comportamento, estão dentro do limite;
− Laço de Realimentação como o componente de sistema básico: o
comportamento do sistema é determinado pela estrutura dos laços de
realimentação dentro de um limite fechado; as estruturas de realimentação são
responsáveis pelas mudanças existentes com o passar do tempo, resultando
em um comportamento de acordo com sua estrutura interna (dentro o limite
fechado) ao invés dos elementos externos.
− Níveis e taxas: em um sistema existem níveis e taxas. Níveis podem ser
descritos como estoques que armazenam a quantia de um elemento (por
exemplo; número de empregados, horas extras). Taxas são as quantias
relativas dos níveis que aumentam ou diminuem.
− Metas: são as condições observadas, as discrepâncias entre elas e ações
desejadas. A meta é o nível que o sistema está tendendo a alcançar, condições
mostram o status atual do sistema. A discrepância entre os estados conduz a
uma ação desejada para fechar a abertura entre a meta e as condições
observadas.
Uma estrutura sistêmica pode ser física, como a forma de organização do local
de trabalho, ou a construção de máquinas, ou pode ser intangível, como a forma de
remuneração dos empregados.
Para considerarmos uma estrutura de sistemas, devemos primeiramente
generalizar os eventos específicos associados a um determinado problema, para a
avaliação dos padrões de comportamento que caracterizam a situação. Uma vez
PUC-Rio - Certificação Digital Nº 0321251/CA
24
identificado tais padrões, pode-se analisar a estrutura do sistema que leva a este
determinado padrão, conforme a Figura 1 (Kirkwood, 1998)
Eventos
Padrões de Comportamento
Estrutura do Sistema
Possibilidade de
Mudanças Duradouras
Figura 1 - Diagrama Estrutura de Sistema (Fonte: Kirkwood, 1998)
2.4 Definição de Modelo
Radzicki (1997) define um modelo como uma representação externa e explícita
de parte da realidade percebida pela pessoa que deseja usar aquele modelo para
entender, mudar, gerenciar e controlar parte daquela realidade. Segundo Mohpatra et
al. (1994), os objetivos para a construção de um modelo do sistema real são:
− Entender como um sistema real trabalha;
− Ter capacidade de reconhecer os fatores que exercem grande influência no
controle do comportamento do sistema;
− Experimentar e determinar as conseqüências da implantação de várias formas
de controle e políticas;
− Alcançar uma função de controle viável;
− Ter capacidade de compartilhar com outros o processo de investigação e seus
resultados.
Maami e Cavana (2000) apresentam a distinção entre modelagem soft ou mental e
modelagem hard ou formal. Modelagem soft, defendida por diversos autores, refere-
se a abordagem conceitual e contextual que busca maior realismo, pluralismo e uma
intervenção mais holística que a modelagem hard. Os conceitos de modelagem soft e
hard são também relacionados às idéias de qualitativo e quantitativo.
PUC-Rio - Certificação Digital Nº 0321251/CA
25
De acordo com o quadro 1, podemos sumarizar as diferenças entre abordagens
hard e soft (Naami e Cavana, 2000).
Quadro 1 - Diferenças entre as modelagens Soft e Hard
HARD (Formal) SOFT (Mental)
Definição do modelo
Uma apresentação da Realidade
Um método para gerar debates e insight sobre a
realidade
Definição do problema
Uma única e bem definida dimensão Múltiplas Dimensões (objetivos diversos)
Agentes/ Organizações
Não são levados em conta Partes integrantes do modelo
Dados/ Informações
Quantitativos Qualitativos
Objetivos
Soluções e otimizações
Insight e aprendizagem
Resultados
Produtos ou recomendações Aprendizado em grupo ou autodesenvolvimento.
Fonte: Adaptado de Naami e Cavana apud Bastos (2003)
2.4.1 Modelo Soft
A modelagem Soft é baseada em crenças e suposições que temos sobre como o
mundo trabalha. Podendo ver essas suposições como geradores da estrutura sistêmica,
pois fornecem o fator inicial para essas estruturas do sistema (Kim , 1998)
A partir da modelagem Soft é possível analisar as visões desejadas de
determinado modelo, obtendo um retrato de como queremos o nosso futuro, assim
tornando-se uma força guia para determinar o modelo mental que ajudará a procurar
as metas desejadas.
2.4.1.1 Estrutura dos Modelos de Dinâmica de Sistemas
Segundo Goodman apud Fernandes (2003), o comportamento de um sistema é
determinado pela sua “estrutura”, que por sua vez é composta de circuito de
realimentação (feedback) e atrasos. Quando duas ou mais variáveis formam um
circuito fechado de relações, ou seja, quando a primeira influencia uma segunda, que
influencia uma enésima, que por sua vez influencia novamente a primeira, forma-se
um ciclo de realimentação.
PUC-Rio - Certificação Digital Nº 0321251/CA
26
Os ciclos de realimentação (enlace) são responsáveis pelos mecanismos de
reforço (positivo) e equilíbrio (negativo) que fazem com que um sistema cresça,
decresça, oscile ou se mantenha estagnado. Dessa forma, percebemos que uma
estrutura de realimentação nada mais é que a representação de um conjunto circular
de causas interconectadas que, em decorrência de uma estrutura e atividades,
produzem certos comportamentos de resposta.
Para se determinar o tipo de enlace em questão, é necessário identificar se
uma ação produz uma variação no mesmo sentido, originando uma realimentação de
reforço, ou se ela produz uma variação contrária, originando uma realimentação de
equilíbrio.
Figura 2 - Ciclo de Realimentação
Podemos exemplificar o enlace com uma simples ilustração de realimentação,
como mostra a Figura 2, onde é possível identificar os seguintes elementos:
− Variáveis ou Elementos do Sistema: são as entidades ou fatores
relevantes do sistema. A escolha das variáveis deve ser acompanhada da
definição operacional e da especificação das unidades que serão mensuradas
individualmente. (Martelanc apud Bastos, 2003) – no caso acima
“Motivação”, “Avanço de Atividades” e “Problemas”;
− Relacionamentos: Setas que indicam a direção de influência de um
elemento sobre o outro. O sinal que acompanha a seta indica a forma de
relacionamento; quando <+>, indica a variação ocorre no mesmo sentido, no
exemplo, quanto maior o Avanço das Atividades, maior a Motivação da
Equipe, e quanto maior a Motivação, maior o Avanço das Atividades. Porém
quanto maior o Avanço das Atividades, maior o número de Problemas
encontrados, assim com o aumento de problemas menor o Avanço das
Atividades.
Motivação
Avanço de
Atividades
Problemas
+
+
-
+
“R” “B”
Motivação
Avanço de
Atividades
Problemas
+
+
-
+
“R” “B”
PUC-Rio - Certificação Digital Nº 0321251/CA
27
É importante notar que a determinação do efeito de um único elemento sobre
outro é definido mantendo-se constantes todos os demais efeitos sobre o
elemento afetado (Andrade apud Bastos, 2003).
− Enlaces ou Realimentações (ou loops): Conjunto circular de causas
onde uma perturbação em um elemento causa uma variação nele própria como
resposta. Para determinar a polaridade do enlace basta identificar o efeito
resultante sobre ele mesmo e no mesmo sentido, originando “realimentação
positiva”, ou de Reforço, possuindo uma simbologia de (+), “R” maiúsculo
(Enlace de Reforço) ou pela utilização do símbolo (bola de neve). Se o
efeito é contrário, origina uma realimentação negativa ou de Balanço, utilizando
a simbologia de (-), “B” maiúsculo (Enlace de Balanço) ou com o símbolo
(Balança).
Se a somatória de relacionamentos negativos possuir uma resultante negativa,
assim teremos um enlace de balanço, caso contrário, nós teremos um enlace de
reforço.
Analisando a situação descrita na Figura 2, temos que um aumento na
realização da atividade causa um aumento da Motivação, causando por sua vez um
novo aumento na realização das Atividades, caracterizando assim um enlace de
Reforço.
Os enlaces de balanço ou equilíbrio têm maior variedade de possibilidades de
comportamento do que o enlace de reforço. Em todos os casos, um enlace de balanço
age de forma a conter a direção inicial da mudança das variáveis, mas ocorrem
diferentes formas de flutuação ou busca de equilíbrio (Martelanc apud Bastos, 2003).
Os enlaces de reforço possuem um comportamento previsível, pois as variáveis
atuam de forma a reforçar ou acelerar a mudança inicial. Dessa forma, possuem um
início de crescimento lento, porém com o aumento da velocidade do crescimento, este
aumenta subitamente. (Kirkwood, 1998). Este enlace possui um comportamento
exponencial (crescente ou decrescente), que ocorrerá indefinidamente a não ser que:
entrem em colapso; sejam introduzidas restrições com outros enlaces de
realimentação, ou ainda, a partir de variáveis exógenas ao sistema (Martelanc apud
Bastos, 2003).
PUC-Rio - Certificação Digital Nº 0321251/CA
28
O enlace de reforço pode ser também chamado de ciclo virtuoso ou vicioso,
dependendo da natureza das mudanças ocorridas (Kirkwood, 1998).
A combinação de enlaces pode criar uma variedade de padrões possíveis. Como
por exemplo, o formato “S” que é criado a partir de um crescimento exponencial em
conjunto a um atraso adicionado de um enlace negativo (Kirkwood, 1998).
Esperas (ou delays) juntamente com o conceito de realimentação são os
responsáveis por grande parte dos sistemas complexos. Esperas são atrasos ou
retardos que fazem com que uma ação possa produzir efeitos diferentes no tempo e
espaço. Em um ciclo (ou enlace), a realimentação ocorre em alguns casos com a
existência de atraso em relação as variáveis atuantes, gerando dessa forma
comportamentos inesperados (Martelanc apud Bastos, 2003). A existência desse
atraso ocorre quando os efeitos de uma variação num dos elementos do sistema não
são imediatos, causando neste caso efeitos indesejados, como oscilações ou
amplificações. Na simbologia utilizada na construção de modelos, as Esperas são
ilustradas por duas barras paralelas ao longo do relacionamento que produz efeitos
como atrasos.
+
-
Var A Var B
Var A Var B
+
-
Var A Var B
Var A Var B
Figura 3 - Esperas (Fonte: Andrade apud Bastos, 2003)
A partir dos elementos básicos para modelagem soft, diversos autores, como
Senge (2003), estabeleceram algumas estruturas criadas a partir de enlaces causais
(reforço e balanço), onde sua resultante nos leva a observar padrões, chamados de
arquétipos. Esses padrões são verificados em diversos tipos de modelos, podendo-se
então realizar análises e comparações de comportamentos em diversos tipos de
sistemas diferentes (Anexo).
2.4.2 Modelagem Hard
Analisando sob a perspectiva de simulação computacional, a partir do diagrama
de enlace causal, temos componentes que não são eficazes tanto para uma análise
PUC-Rio - Certificação Digital Nº 0321251/CA
29
quantitativa, quanto para uma análise do comportamento sistêmico ao longo do
tempo.
Dessa forma, para obter uma análise quantitativa, contínua e que tenham
características estruturais definidas no Diagrama de Enlace Causal, foi necessário
desenvolver uma abordagem que possibilite estudar a evolução de um sistema, dentro
de um período de interesse, o Diagrama de Estoque e Fluxo.
A partir da linguagem composta pelo Diagrama de Estoque e Fluxo, perante a
perceptiva da Dinâmica de Sistemas, podemos descrever matematicamente qualquer
sistema artificial ou natural através de quatro elementos chave (Fernandes, 2003)
(Figura 4):
− Estoques (níveis), que representam o estado de um recurso, como, por
exemplo, pedido em carteira, quantidade de trabalhadores, inventário, ou
capital intelectual.
Na utilização do software Ithink, é possível utilizar quatro tipos diferentes de
Estoque: Reservoir (reservatório), Conveyor (transportadora), Queue (fila),
Oven (Forno).
− Fluxos são atividades que produzem crescimento ou redução do estoque, tal
como o movimento de materiais e informações dentro de um sistema, como
por exemplo fluxo de água de uma torneira.
O Fluxo é representado por uma flecha com linha dupla, como se fosse um
encanamento, sendo que o registro do encanamento é representado por um
símbolo parecido com o de uma válvula, que controla o fluxo do
encanamento.
− Conversores podem processar informações a respeito dos estoques e fluxos,
ou ainda representar fontes de informação externa ao sistema.
− Conectores são as ligações de informações que conectam Estoques e Fluxos,
podendo realizar ligações de um ponto para diversos pontos.
ESTOQUE
FLUXO
CONVERSORES
Figura 4 – Elementos Chaves da Dinâmica de Sistemas (Fonte: Autor)
PUC-Rio - Certificação Digital Nº 0321251/CA
30
2.4.2.1 Características do Diagrama de Estoques e Fluxos
A Dinâmica de Sistemas credita que todo o comportamento dinâmico é um
sistema baseado no princípio da acumulação (Radzick apud Bastos, 2003). Este
princípio afirma que o comportamento dinâmico no mundo ocorre quando os fluxos
se acumulam em estoques, ou seja, o comportamento dinâmico surge quando algum
elemento flui por um meio, se acumulando (ou se esgotando) de alguma forma. Na
modelagem com Diagramas de Estoques e Fluxos, variáveis físicas podem fluir pelos
fluxos e se acumular nos estoques.
O entendimento e distinção das entidades dos Diagramas de Estoques e Fluxos
são fundamentais para uma correta análise do comportamento dinâmico gerado pelo
sistema.
Para identificar as principais estruturas do Diagramas de Estoques e Fluxos, o
modelador deve descobrir quais variáveis determinam o estado, a situação do sistema
(seus estoques) e quais variáveis estabelecem as mudanças (seus fluxos).
Analisando um sistema, temos que um estoque é normalmente descrito através
de um substantivo (população, estoque, auto-estima, empregados), um fluxo descrito
através de um verbo e pode ser caracterizado como fluxo de entrada (nascer, produzir,
evoluir, contratar) e fluxo de saída (morrer, despachar, retroceder, demitir).
É possível também diferenciar estoque e fluxo dentro de um sistema,
“paralisando” o sistema em um determinado momento e analisando as quantidades
resultantes dentro de cada entidade. Assim, as entidades com quantidades diferentes
de zero são os estoques, que acumulam os valores, e aquelas entidades com valor zero
são fluxos, onde nada trafega pela paralisação do sistema.
Analisando separadamente cada uma das entidades que pertencem à Dinâmica
de Sistemas, vemos que elas possuem características importantes para a determinação
do comportamento dinâmico:
Fluxos ou taxas
Os fluxos em um sistema são o resultado das decisões por parte da gestão, ou
então forças exógenas fora do controle dos gestores.
PUC-Rio - Certificação Digital Nº 0321251/CA
31
Segundo Forrester (1961), as equações dos fluxos são políticas estabelecidas
que definem como o fluxo ocorrerá no sistema. Essas taxas não poderão ser
observadas em um único momento do tempo, exceto sua somatória acumulando com
o passar do tempo ou na média resultante.
A Figura 5 mostra a flecha na extremidade do fluxo indicando seu sentido e o
círculo com a válvula, no centro, como o regulador do fluxo, chamado de taxa. Este
regulador conterá a “lógica”, ou a “regra de decisão”, que ajusta o fluxo.
Figura 5 – Fluxos ( Fonte: Ithink)
Em algumas situações, o fluxo se inicia ou se encerra em uma “nuvem”, que
representa um ponto limite do modelo (HPS, 2001). Estas nuvens nas extremidades
de alguns fluxos são fontes ou escape da estrutura, significando o infinito e definem
as fronteiras, os limites do modelo (Powersim, 2001).
Estoques
Possuem quatro características básicas (Radzick apud Bastos, 2003)
− O estoque possui efeito memória (como resistência ou inércia). Se o fluxo
de um estoque é interrompido, o nível ou quantidade acumulada no
estoque não será alterado, permanecendo estático no nível em que se
encontrava no exato momento que o fluxo foi interrompido. Essa
característica demonstra que se um determinado estoque estiver
estabelecido o padrão de acumulação no estoque, normalmente não exibirá
o mesmo padrão do fluxo.
− Estoques repartem (interrompem ou separam) os fluxos em fluxos de
entrada (ou alimentação) e fluxos de saída (ou drenagem), sendo que a
variação entre os dois fluxos resulta no desequilíbrio dentro do estoque,
como pode-se observar na Figura 6.
TAXA
TAXATAXA
TAXA
Fluxo
FluxoFluxo
Fluxo
TAXA
TAXATAXA
TAXA
Fluxo
FluxoFluxo
Fluxo
PUC-Rio - Certificação Digital Nº 0321251/CA
32
Fluxo de entrada Fluxo de Saída
Estoque
Figura 6 – Estoque (Fonte: Itink)
− Estoques criam atrasos (delays), pois a partir da variação de qualquer
estoque dentro de um sistema, haverá uma fração de tempo (dt) para essa
mudança refletir no restante do sistema.
A identificação desses padrões de atraso é um fator primordial para a Dinâmica
de Sistemas, pois freqüentemente alteram o comportamento do sistema de diferentes
maneiras, causando um distanciamento entre causa e efeito e dessa forma dificuldade
no Diagnóstico e decisões dos gestores, por não perceberem a dualidade de conexão
causa e efeito.
Representação Matemática: Estoque (T+dt) = Estoque (T) + Fluxo (dt)*dt
Conversores
Conversores são variáveis intermediárias que podem, se necessário, ser
utilizados em lugar das equações de fluxo para inserir, manipular ou converter dados
(Manni e Cavana, 2000).
Além disso um conversor é uma variável auxiliar, utilizada para combinar ou
reformular informações. É o processamento algébrico de qualquer combinação de
estoques, taxas de fluxos, ou mesmo outros conversores. Pode servir de entrada para
os fluxos e outros conversores, porém não pode estar ligado diretamente ao estoque,
pois o fluxo é o único elemento capaz de mudar os estoques (Powersim, 2001).
A característica padrão para um conversor é a modelagem de informação, não
tendo assim o efeito memória existente nos estoques, pois os conversores não tratam
de fluxos de bens físicos de bens e quantidades. (Powersim, 2001).
Conectores
Conectores são entidades que estabelecem conexões entre taxas de fluxos,
conversores e estoques, permitindo que essa informação passe de uma entidade para
PUC-Rio - Certificação Digital Nº 0321251/CA
33
outra. Eles definem de que maneira os elementos do sistema se dispõem
conjuntamente.
Através dos conectores é possível transferir os valores e quantidades dos
estoques de volta para os fluxos, indicando a dependência dos fluxos aos valores dos
estoques, semelhante à óbvia dependência do estoque em relação ao fluxo (Powersim,
2001), demonstrando, dessa forma, o fechamento dos enlaces de realimentação (ou
feedback).
2.4.3 Softwares de Simulação
A partir do entendimento dos princípios da Dinâmica de Sistemas, tratamos sua
complexidade de maneira prática, de forma a construir modelos representativos e
focados do sistema, para estudar seu comportamento ao longo do tempo, analisar e
reproduzir seus problemas, com o intuito de criação de novas políticas para o sistema.
Softwares de simulação tornam-se necessários e tradicionalmente utilizados pela
Dinâmica de Sistema. O mercado de softwares de simulação atualmente abrange os
mais diversos tipos de simulação, onde é necessário inicialmente identificar qual
software é o mais propício para utilização dentro de seu problema e sistema.
A modelagem de negócio é uma área abrangente e em contínua evolução, em
que é possível listar as mais diversas ferramentas para simulação de sistemas
estáticos, dinâmicos e ferramentas especializadas em otimização de processos.
A Figura 7 descreve uma classificação das ferramentas de modelagem de
negócios, onde está contida a ferramenta de Dinâmica de Sistema.
PUC-Rio - Certificação Digital Nº 0321251/CA
34
Figura 7 - Ferramentas de modelagem de negócios (Bearingpoint, 2004)
As ferramentas de modelagem estática provêm uma ilustração gráfica dos
fluxos de processo, atividades e custo. Adicionalmente, a modelagem estática permite
ao usuário detalhar a hierarquia de processo dentro de um maior nível de detalhe.
O ponto positivo dos modelos estáticos é a facilidade de representar
graficamente um processo por um curto período de tempo, facilitando o entendimento
do modelo atual e o desenho do modelo futuro.
As ferramentas de otimização de operações são similares a uma ferramenta de
modelagem estática, que calcula o tempo e custo do processo de forma automática,
simples e ágil.
As ferramentas de modelagem dinâmica provêem a habilidade de representar
instantaneamente os efeitos das mudanças das entradas e variáveis do modelo. A
partir dessas ferramentas é possível obter uma excelente aplicação para simulação das
relações estratégica de alto nível, tornando-se uma poderosa ferramenta para entender
as implicações das decisões no negócio, além de também utilizar como uma forma de
modelar as interações dos recursos e entidades dos modelos, analisando o efeito das
suas restrições.
A vantagem da ferramenta de modelagem dinâmica é a habilidade de mostrar o
relacionamento de causa e efeito, além de possibilitar o cálculo de tempo e custo do
Ferramentas de
Modelagem de Negócios
Estática Dinâmica
Otimização/Outras
Modelagem de
Processos
Modelagem de
Informação
Simulação de
Evento Discreto
Dinâmica de
Sistemas
Análise de
Decisão
Modelagem
Matemática
•desingnIDEF
(Mac, Win; $5000)
•Visio
(Windows; $100)
•Innovation
(Mac, Win; $500)
•ADW
(OS2, W;10-15 K)
•TopDown ($200)
•Flowchart 4.0
($100)
•Process Charter
($500)
•ER WIN/ERX
(MAC, Win; $5000)
•desingnIDEF
(Mac, Windows;
$5000)
•ADW
(OS2, W;10-15 K)
•Process Charter
($500)
•Extent
(Win, Mac; $1700)
•SIMSCRIPT
(Win, OS2; 22K)
•Arena
(Win; 22K)
• designCPN
(Mac, Unix, Win;
$25K)
•SIMPROCESS
(Win; $12K
•BONES
(Unix)
• Network/Comnet
(Unix, Win; 15K)
•Ithink
(Mac, Win; $900)
•Vensim
(Win; 2K)
•Extent
(Win, Mac; $1700)
•SIMSCRIPT
(Win, OS2; 22K)
•ProSim
(Win; 2K)
•PowerSim
(Windows, $ 2K)
•Ithink
(Mac, Win; $900)
•IDA Template
(Win, Mac)
•@ Risk
(Mac; $200)
Easy ABC
(Win, Mac; $ 2K)
•What If ($500)
•Logical Decision
Works AHP ($700)
•PowerSim
(Windows, $ 2K)
•Extent
(Win, Mac; $1700)
•LINPRO
•Powertools Suite
•Neural Nets
Analyser
•MATHPRO,
AMPL,CPLEX
•MPL
•ILOGSolver/Sched
uler
•SIMRUNNER
@ProModel ($4K)
Ferramentas de
Modelagem de Negócios
Estática Dinâmica
Otimização/Outras
Modelagem de
Processos
Modelagem de
Informação
Simulação de
Evento Discreto
Dinâmica de
Sistemas
Análise de
Decisão
Modelagem
Matemática
•desingnIDEF
(Mac, Win; $5000)
•Visio
(Windows; $100)
•Innovation
(Mac, Win; $500)
•ADW
(OS2, W;10-15 K)
•TopDown ($200)
•Flowchart 4.0
($100)
•Process Charter
($500)
•ER WIN/ERX
(MAC, Win; $5000)
•desingnIDEF
(Mac, Windows;
$5000)
•ADW
(OS2, W;10-15 K)
•Process Charter
($500)
•Extent
(Win, Mac; $1700)
•SIMSCRIPT
(Win, OS2; 22K)
•Arena
(Win; 22K)
• designCPN
(Mac, Unix, Win;
$25K)
•SIMPROCESS
(Win; $12K
•BONES
(Unix)
• Network/Comnet
(Unix, Win; 15K)
•Ithink
(Mac, Win; $900)
•Vensim
(Win; 2K)
•Extent
(Win, Mac; $1700)
•SIMSCRIPT
(Win, OS2; 22K)
•ProSim
(Win; 2K)
•PowerSim
(Windows, $ 2K)
•Ithink
(Mac, Win; $900)
•IDA Template
(Win, Mac)
•@ Risk
(Mac; $200)
Easy ABC
(Win, Mac; $ 2K)
•What If ($500)
•Logical Decision
Works AHP ($700)
•PowerSim
(Windows, $ 2K)
•Extent
(Win, Mac; $1700)
•LINPRO
•Powertools Suite
•Neural Nets
Analyser
•MATHPRO,
AMPL,CPLEX
•MPL
•ILOGSolver/Sched
uler
•SIMRUNNER
@ProModel ($4K)
PUC-Rio - Certificação Digital Nº 0321251/CA
35
processo. Por outro lado, essas ferramentas de modelagem são de demorado
desenvolvimento, requerendo um treinamento de alto nível para a criação dos
modelos e validação dos resultados.
Nesse trabalho estaremos abordando a utilização da ferramenta de modelagem
dinâmica Vensim da Ventana System (http://www.vensim.com), basicamente por
quatro motivos principais: a familiarização do software pelo usuário, o acesso
gratuito, a expressiva utilização no meio acadêmico e profissional, com um grande
número de modelos e a existência de uma interface gráfica de fácil utilização, que
favorece o aprendizado dos conceitos de Dinâmica de Sistemas.
PUC-Rio - Certificação Digital Nº 0321251/CA
3
PROJETOS DE IMPLEMENTAÇÃO SOFTWARES DE ERP E O
ESCRITÓRIO DE GESTÃO DE PROJETOS
Estabelecer quais são os fatores de maior importância e impacto de um projeto de
ERP é a forma de obter sucesso na implantação desse software, o qual é determinado por
uma estrutura de projeto bem definida, metas claras, equipe diversificada e, principalmente,
uma gestão de projeto estruturada de uma forma correta.
3.1 Introdução sobre Implementação de ERP
Segundo a definição apresentada por Norris et al (2001), “ERP é uma abordagem
estruturada para a otimização da cadeia de valor interna de uma empresa”, onde a utilização
de um “software instalado ao longo de um grupo empresarial interliga os componentes
através de um sistema lógico de transmissão e compartilhamento de dados comuns do ERP
integrado”.
Para Wallace (2001), o ERP organiza, codifica e padroniza os processos e dados de
negócio de um grupo empresarial de forma a influenciar todas suas áreas e departamentos.
O software transforma os dados transacionais em informações utilizáveis, agrupando esses
dados de forma que possam ser analisados.
Um software de Enterprise Resource Planning ou Planejamento de Recursos
Empresariais (ERP) é uma tecnologia evolutiva que se iniciou com as primeiras
automações dos sistemas de informações da área financeira e de manufatura há
aproximadamente 40 anos, partindo dos estudos de otimização de fluxo de materiais e
softwares de planejamento de requisições de materiais (MRP – Material Resource
Planning).
O ERP e seu predecessor, o MRP, auxiliaram na transformação do ambiente
empresarial, tornando possível melhorias profundas na forma que as empresas gerenciam
sua manufatura. a evolução do Enterprise Resource Planning ocorreu em quatro passos que
esclarecem sua grande utilização e o interesse de utilização pelas empresas.
PUC-Rio - Certificação Digital Nº 0321251/CA
37
O primeiro passo ocorreu por volta de 1960, com o início do MRP (Material
Requirement Planning) ou Planejamento de Requerimento de Materiais, onde foi
desenvolvida uma técnica que melhor ordenava materiais e componentes, usando um
calendário mestre, uma lista de materiais e pedidos de estoque para determinar os pedidos
futuros.
O segundo passo é definido como ciclo fechado de MRP; neste passo o MRP possuía
capacidade de reordenação de pedidos, possibilitando priorizar o pedido de acordo com o
seu prazo.
O terceiro passo, conhecido como MRP II (Manufacturing Resource Planning) ou
Planejamento de Recursos de Manufatura, é utilizado para o planejamento efetivo de todos
os recursos da empresa. Neste avanço foram adicionados os seguintes elementos:
− Planejamento de Operações e Vendas – Processo para balancear a demanda e o
suprimento no melhor ponto, o qual prove um controle operacional para a
gerência do negócio;
− Interface Financeira – Habilidade de traduzir o plano operacional em termos
financeiros;
− Simulação – Criação de cenários para obter ações que respondam a necessidade
da empresa.
O último passo é o ERP, que além das capacidades de problemas do MRP II, permite
aos tomadores de decisão a capacidade de predizer e balancear a demanda e suprimentos da
empresa. Possui ferramentas para previsão, planejamento e agendamento, possibilita unir
consumidores e fornecedores dentro da mesma cadeia de suprimento, melhorar o processo
de decisão e coordenação de vendas, marketing, desenvolvimento de produto, logística e
recursos humanos (Wallace, 2001).
Segundo Norris et al. (2001), a adoção em larga escala da solução ERP no setor
industrial é função de um mercado com um aumento da competição global, necessidade de
controle executivo e controle dos fluxos de produtos e informação dentro da empresa,
criando assim uma grande demanda de projetos de implementações de ERP.
PUC-Rio - Certificação Digital Nº 0321251/CA
38
A decisão pela implementação do ERP pode ter efeitos de redução empresarial
(downsizing) e reestruturação, mas sempre com o objetivo de otimizar os processos do
negócio.
Para Esteves e Pastor (1999), o ciclo de vida do ERP influencia as decisões do
sistema na empresa, ocorre em diversas intensidades e mostra que um dos pontos mais
importantes é a fase de sua implementação.
Em sua divisão de estágios, Esteves e Pastor (1999) especificaram que a primeira
fase, a fase de adoção da decisão, será quando os responsáveis pela decisão e gerentes
questionam sobre a necessidade de um sistema que acompanhará as modificações críticas
de seu negócio, para apoiar as decisões estratégicas da empresa e os requerimentos de
sistemas, benefícios e análises de impacto no negócio e organização.
O segundo estágio, a fase de aquisição, abrange os produtos que melhor se encaixam
nos requerimentos da organização, minimiza o período de customização. Pontos como
preço, retorno sobre o investimento, funcionalidades do software e treinamento necessário
da equipe são elementos importantes para a decisão.
A fase mais crítica descrita é a fase de Implementação, onde a customização,
parametrização do software adquirido e carga inicial dos dados do sistema são realizados
para suprir as necessidades da empresa. Nesta fase encontram-se os desenhos de processos
e definições mais críticas da situação futura da empresa após implementação. Nesta fase,
acontece o período de maior investimento em treinamento pela empresa.
Com a realização da implementação e o início da utilização efetiva do sistema, inicia-
se a fase de Utilização e Manutenção, em que a utilização efetiva do sistema leva aos
benefícios esperados e à minimização das interrupções nas atividades normais da empresa.
Nessa fase o alinhamento de processos, sistemas e funcionalidades são importantes e
muitas vezes contínuos, visando minimizar o impacto e permitir correções dos erros de
implementação e sistema.
As duas próximas fases descritas por Esteves e Pastor (1999) são a fase da evolução,
onde estão integradas novas capacidades e benefícios adicionais ao ERP (como extensão de
simulações estratégicas ou ligações com sistemas de Gerenciamento de Relacionamento
com o Cliente - CRM) e a fase de retirada, onde aparecerá uma nova tecnologia que
substituirá os sistemas atuais de ERP.
PUC-Rio - Certificação Digital Nº 0321251/CA
39
A maior importância colocada na fase de implementação é fortalecida por Wallace
(2001), mostrando que a implementação de ERP requer mudanças importantes dos
processos organizacionais, culturais e de negócio, onde há muitas vezes a necessidade de
redesenho dos processos de negócio atuais da empresa, para obter uma redução de tarefas
que não agregam valor à empresa e aumentar suas capacidades produtivas e assim realizar
um aumento em seus ganhos financeiros em longo prazo e em seu desempenho operacional.
Curram e Keller (2004) listam os segmentos que levam uma empresa a redesenhar os
processos para realizar a implementação de um ERP, como:
− Fazer uma empresa ser focada na criação de valor para consumidores e
fornecedores;
− Integrar todos os processos críticos de negócio;
− Gerir todo o processo, não apenas uma tarefa individual;
− Reduzir ou até eliminar o tempo entre as etapas de uma cadeia de negócio.
3.2 A estratégia de Implementação do software de ERP
A definição da estratégia que será utilizada pela implementação de ERP é o tema de
uma seqüência de decisões necessárias para minimizar o impacto da implementação na
empresa.
De acordo com Umble et al. (2003), 65 % dos executivos possuem a percepção de
que problemas na implementação do sistema ERP influenciam negativamente as metas da
empresa.
Curram e Keller (2004) estabelecem como pré-requisitos de uma correta
implementação a necessidade da empresa possuir características como:
− Foco da empresa nas necessidades para a mudança dos processos de negócio;
− Projeto deve ser liderado por profissionais qualificados e experientes;
− Gerência da comunicação sobre os problemas da gestão de mudança;
− Cultura de utilizar a tecnologia para novas iniciativas.
Bancroft et al. (1996) e Umble et al. (2003) estabelecem diversos fatores
classificados como críticos para o sucesso em qualquer implementação de maior
complexidade.
Esses fatores são definidos abaixo:
PUC-Rio - Certificação Digital Nº 0321251/CA
40
− Claro entendimento das metas estratégicas e cultura corporativa em termos de
prontidão e capacidade de mudança;
− Foco da empresa apenas na implementação e medição de sua performance;
− Ter uma informação de qualidade e comunicá-la continuamente com todos os níveis
de usuários da empresa, com termos não técnicos e nivelando suas expectativas;
− Prover apoio executivo para o Projeto e comprometimento da alta gerência;
− Ter uma gestão efetiva para questões técnicas, negócios e gestão de mudança, que
favorece as mudanças, sem esperar que problemas aconteçam;
− Escolher uma equipe balanceada (tecnologia e negócios), provendo uma clara
definição de suas responsabilidades;
− Treinar os usuários e equipe do projeto, provendo suporte para a mudança dos
negócios;
− Selecionar uma boa metodologia de gestão e medição de projetos.
A partir de um ambiente e equipe com padrões estabelecidos, Wallace (2001) propõe
três abordagens de implementação de um software de ERP. A primeira abordagem,
chamada de Série, é aquela em que a implementação completa do ERP é realizada em uma
primeira planta completamente e, em seguida, passa para a segunda e assim por diante.
Figura 8 – Abordagem em Série
A segunda abordagem é chamada de faseada. A implementação faseada é
caracterizada por termos diversos módulos ou unidades de negócio realizados em fases
adjacentes, conforme Figura 9
Figura 1 - Abordagem Faseada
Planta 1
Planta 2
Planta
3
Planta
4
Mês 0
15 18 21 24
Planta 1
Planta 2
Planta
3
Planta
4
Mês 0
15
30
45
60
PUC-Rio - Certificação Digital Nº 0321251/CA
41
Nessa abordagem os esforços de desenvolvimento são focados na solução a ser
implementada, para minimizar o impacto na empresa e o risco de falhas na implementação.
A desvantagem é definida pelo grande número de interfaces a serem mapeadas,
desenvolvidas e testadas para uma solução final integrada. Necessitam um elaborado
planejamento e um detalhado desenho da solução de negócios e tecnológica.
A escolha de implementar todos os módulos para toda a empresa é conhecida pelo
termo de Implementação Big Bang ou abordagem simultânea. Essa terceira abordagem
possui características críticas, havendo riscos de implementação. De acordo com Bancroft
et al. (1996), essa técnica possui altos riscos estratégicos, pois necessitará de um grande
rigor nos testes de integração em todas as unidades da empresa e processos de negócios,
para possibilitar a ativação correta em toda a empresa.
Figura 10 - Abordagem Big Bang
3.2.1 Aspectos da Gestão de Projetos de ERP
A gestão de projetos de ERP deve abordar alguns pontos considerados de grande
importância para o sucesso do projeto. Esses fatores são uma forma de esclarecer e
diminuir as expectativas de uma implementação. Bancroft et al. (1996) lista os seguintes
pontos:
− A solução de ERP não é uma solução única e direta;
− A solução de ERP não suporta áreas sem solução ou com soluções nebulosas;
− O limite do software abrange a necessidade da empresa;
− O treinamento do software ERP é apenas o início do aprendizado;
− A equipe de projeto deve ser focada na solução, porém visionária para a empresa.
P
lanta1
Planta2
Planta3
Planta4
Mês 0
15
PUC-Rio - Certificação Digital Nº 0321251/CA
42
Na gestão de projetos para projetos de Implementação de ERP, existem três variáveis
primárias e principais que definem um projeto. Segundo Wallace (2001) estas variáveis
são:
− Quantidade de trabalho a ser realizada – é considerada uma constante, isso quer
dizer que existe uma quantidade de trabalho fixa para a realização da
implementação.
− Tempo disponível (calendário de implementação total) – O tempo é variável
constante, dessa forma a implementação deve ser realizada com um prazo fixo e
uma data final para a finalização.
− Quantidade de recursos disponíveis para realização do trabalho - A quantidade de
recursos se torna a variável limite para a implementação do ERP.
3.2.2 Fases de um projeto de implementação
Na descrição dos fatores críticos de sucesso expostos por Bancroft et al. (1996) e
Umble et al. (2003) para implementação de um ERP (item 3.2), listaram diversos pontos
descritos como primordiais para o sucesso da implementação.
No mercado esses fatores críticos são traduzidos em metodologias e técnicas de
trabalho que são repetidas como uma fórmula para o sucesso desses projetos.
A implementação de um software ERP pode ter diversas metodologias aplicadas,
definidas pela empresa e pelo modelo de gestão. A partir da metodologia aplicada, são
definidos regras e conceitos que serão utilizados nos diversos momentos da implantação.
A proposta de metodologia da Bearingpoint (2004) inicia-se pelo entendimento da
estrutura macro, onde, de acordo com a Figura 11, vemos a seqüência das principais fases
do projeto
Figura 11 - Fases da Implementação do Projeto. (Fonte: Bearingpoint, 2004)
Numa visão aprofundada dessa metodologia, temos um detalhamento de macro-
atividades e seus principais relacionamentos, com intuito de criar um processo de entrega e
de realização, em que podemos analisar o encadeamento de atividades priorizado pela
realização das atividades.
Preparação
do projeto
Realização
Desenho da
solução
Preparação
final
Suporte
PUC-Rio - Certificação Digital Nº 0321251/CA
43
Esse encadeamento é definido pelo direcionamento dos gerentes e líderes do projeto,
análise estratégica da empresa e restrições imposta pelo cliente.
A Figura 12 ilustra as macro-atividades segundo a metodologia da Bearingpoint
(2004)
Figura 12 - Detalhamento das Fases da Implementação do Projeto. (Fonte: Bearingpoint,
2004).
Segundo a metodologia utilizada por Bearingpoint (2004), definem-se as principais
fases e produtos:
− Preparação do Projeto: Nesta primeira fase, os responsáveis pelo projeto definem a
organização do projeto, a estratégia de implantação, o planejamento macro dos
trabalhos, bem como recebem o treinamento introdutório sobre o sistema a ser
implementado e finalizam a fase com a reunião de inauguração, conhecida como
início executivo (kick-off) do projeto.
O instituto americano de gestão de projetos, PMI (Project Management Institute), em
seu livro guia de gestão, o PMBok (2004), coloca a necessidade da ocorrência das fases de
P r e p a r a ç ã o
D e s e n h o d a S o lu ç ã o R e a liz a ç ã o P r e p a r a ç ã o F in a l G o - liv e e S u p o r te
P la n e ja m e n to d o
P r o je to , In f r a -
e s t r u tu r a e G e s tã o
G e s tã o d o P r o je to
e T r e in a m e n to d a
E q u ip e
G e s tã o d o P r o je to e
T r e in a m e n to d a E q u ip e
G e s tã o d o P ro je to e
P l a n e ja m e n to d a
P a r ti d a d o S is t e m a
P r e p a ra ç ã o d a
G e s tã o d e
M u d a n ç a
A ç õ e s d e G e s t ã o
d e M u d a n ç a
T r e in a m e n to d o
U s u á r io F in a l
E s tr u t u r a ç ã o d a
O rg a n iz a ç ã o d e
N e g ó c io
D e f in iç ã o d o s
P r o c e s s o s d e
N e g ó c io
C o n f ig u ra ç ã o /
C o n f ir m a ç ã o
In ic ia l
P r e p e C o o r d
D e s e n v o lv
(A B A P )
C o n f ig u ra ç ã o
F in a l
D e s e n v d e C o m p o n e n te s
C u s to m iz a d o s
(C o n v e rs õ e s , In te r fa c e s e
R e la tó rio s )
A u to r iz a ç õ e s e s ta b e le c id a s
T e s t e
In te g r a d o F in a l
D o c u m e n ta ç ã o d o
U s u á r io F in a l e M a t e ri a l
d e T re in a m e n to
G e s tã o d e S is te m a
e A rc h iv i n g
D e s e n v o lv im e n to
d o s A m b ie n t e s d o
S is te m a
P la n e ja m e n to d o s
R e q u e r im e n to s
T e c n o ló g ic o
G e s tã o d o S is t e m a
P r o c e s s o d e
P a r tid a d o
S is te m a
F in a li z a ç ã o
d o P ro je to
S u p o r te a
S i s t e m a P ro d u tiv o
G e s tã o d o P ro je to
G e s tã o d e M u d a n ç a
D e s e n v o lv im e n to d a
A p lic a ç ã o
T e c n o lo g ia
PUC-Rio - Certificação Digital Nº 0321251/CA
44
iniciação e planejamento do projeto, que é representada no modelo como a Fase de
Preparação.
Dentro das possíveis atividades que descrevem estas fases temos atividades técnicas,
como a definição, requerimentos, infra-estrutura e “sizing” de servidor, atividades de gestão
de mudança, como a definição de estrutura da equipe, padrões de documentos, agenda, atas
e minutas. Temos também atividades de planejamento e definição do projeto, como a
criação do Project Charter e atividades de gestão, sendo definida a estratégia de
implantação e formação do comitê executivo do projeto.
− Desenho da Solução, fase que compreende: a definição e o desenho dos cenários de
negócios conforme a necessidade da empresa; a identificação e a especificação dos
desenvolvimentos, interfaces e melhorias do sistema integrado; a identificação das
necessidades de relatórios gerenciais e definição dos dados necessários para operação do
sistema; levantamento de dados que deverão ser migrados durante a implementação do
novo sistema.
As atividades de Desenho da Solução consistem no mapeamento e desenho dos
processos de negócio, para definir a situação presente da empresa e determinando a
situação futura dos processos da empresa com o sistema implementado, validar a
informação resultante e determinar as mudanças necessárias nos sistemas, para definir
seqüencialmente a especificação dos desenvolvimentos necessários aprovada.
− Realização (Desenvolvimento da Solução): Fase responsável pela construção do
novo sistema, que é construído através da customização do ERP, do desenvolvimento de
programas necessários para solucionar necessidades locais, novas interfaces e melhorias,
realizar desenvolvimento e teste dos relatórios gerenciais e execução do primeiro ciclo de
testes do projeto (teste de cenário). É também a fase responsável pelo desenvolvimento dos
programas de conversão e limpeza de dados para carregar o novo sistema, conforme
proposto durante a fase de desenho da solução.
− Preparação Final: A fase de preparação final é determinada pelo período de
preparação do projeto para entrada em produção de todos os processos
implementados no novo sistema de ERP.
O período de preparação final da implementação é realizado na dependência da
abordagem de implementação definida na estratégia inicial de implementação. Uma
PUC-Rio - Certificação Digital Nº 0321251/CA
45
implementação faseada terá diversos momentos de preparação, específicas para cada
entrada em produção. A preparação final para a abordagem Big Bang, é única e por outro
lado, extremamente crítica, prioritária e arriscada para o sucesso do projeto.
Nessa fase encontram-se os últimos módulos de treinamento do usuário final, plano
de entrada em produção, testes, monitoramento e gestão do sistema.
− Suporte: A fase de suporte inicia uma fase contínua que se estenderá até a
finalização do projeto. Nessa fase serão analisados a performance do sistema, dos
processos implementados e treinamento do usuário final.
A partir do resultado dessa análise contínua, surgirão melhorias a serem
implementadas no sistema até sua estabilização.
3.2.3 Organização de um projeto
Uma vez definido o escopo e a abordagem de implementação do ERP, o ponto de
maior impacto é a definição da equipe que deverá realizar a implementação do projeto.
Baseado no modelo de gestão utilizado em projetos realizado pela consultoria
Bearingpoint (Bearingpoint, 2004), a equipe é definida de uma forma matricial com todas
as áreas e interfaces da empresa, de forma que a equipe seja mista para abranger todas as
áreas de impacto na empresa.
Na posição de gerência do projeto, encontra-se o Líder do Projeto, pessoa responsável
por encabeçar a equipe do projeto e alinhar definições no nível operacional.
O próximo passo, após definir o líder do projeto, é a definição da equipe do projeto.
Esse grupo será o responsável pela implementação do sistema operacional, que dentro de
suas principais atividades possui as seguintes:
− Estabelecer o cronograma de implementação;
− Relatar o desempenho realizado versus desempenho planejado;
− Identificar problemas e obstáculos para uma implementação com sucesso;
− Criar forças tarefas para minimizar o impacto dos problemas identificados;
− Realizar definições, quando apropriado, baseado em prioridades e re-alocação dos
recursos existentes;
− Propor novas recomendações, quando necessário, para o comitê executivo do
projeto;
PUC-Rio - Certificação Digital Nº 0321251/CA
46
− Fazer o necessário para permitir uma implementação eficaz, rápida e com sucesso.
Em um exemplo de metodologia de implementações utilizada no mercado, a equipe
do projeto é subdividida em cinco grandes grupos com atribuições específicas dentro do
projeto (Bearingpoint, 2004)
− Equipe Funcional: Realiza o desenho da solução de negócio (BPR) abrangendo os
processos atuais e definição dos processos futuros, customização do ERP para
cobrir a necessidade da empresa e o suporte ao treinamento e material de apoio.
− Equipe de Tecnologia: Responsável pela estrutura tecnológica do projeto,
realizando definições de máquinas para utilização no projeto e após implementação,
pela definição e seleção de fornecedores e pelo suporte de infra-estrutura e
tecnológico ao projeto.
− Equipe de Desenvolvimento: Responsável pela construção dos desenvolvimentos
necessários para customizar o software padrão à necessidade da empresa. As
funções da equipe de desenvolvimento podem ser amplas ou restritas dependendo
da experiência dos participantes em relação ao mercado, solução e empresa que
estão atuando. De uma forma mais ampla, sua atuação pode ser considerada desde o
desenho da solução técnica e o desenvolvimento propriamente dito, até os teste dos
desenvolvimentos e criação dos cenários de teste da empresa.
− Equipe de Gestão de Mudança: Responsável pela estrutura organizacional do
projeto, pela identificação e interface com patrocinadores do projeto e formadores
de opinião; avalia a disposição para mudança, realiza a comunicação do projeto,
avalia os impactos organizacionais proporcionados pela mudança de processos e
tecnologia modificada pelo projeto. Também cabe a essa equipe realizar o
treinamento e educação dos usuários identificados para o novo ambiente de trabalho
− Equipe do PMO (Escritório de Gestão do Projeto): Responsável pelo
acompanhamento e gestão do projeto, suportando os líderes do projeto e o Comitê
Executivo para que eles possuam uma visão ampla do desempenho existente,
comunicação dos problemas e riscos identificados, análise das necessidades de
modificações estratégicas e operacionais do projeto.
PUC-Rio - Certificação Digital Nº 0321251/CA
47
A partir do relacionamento da equipe PMO com a gerência do projeto, ocorrerão as
principais definições de estratégia e resolução de problemas, risco e modificações do
planejamento do projeto.
No nível estratégico do projeto, temos o Comitê Executivo do Projeto. Esse comitê
consiste primariamente em um grupo da alta gerência da empresa, com a missão básica de
assegurar o sucesso do projeto, de forma a comprometer todas as áreas e equipes da
empresas com as mudanças necessárias para a uma implementação consistente.
O Sponsor ou Patrocinador principal do projeto é o executivo com a maior
responsabilidade do projeto, sendo assim ponto focal do projeto na empresa.
Um projeto de ERP pode ser caracterizado pelo diagrama organizacional descrito na
Figura 13.
Figura 13 - Organograma de um projeto de ERP (Fonte: Autor)
3.2.3.1 Escritório de Gerenciamento de Projetos:
De acordo com Project Management Institute (2004), um escritório de gestão de
projetos (PMO) é uma unidade organizacional que centraliza e coordena o gerenciamento
de projetos sob seu domínio, sendo responsável pelo planejamento, organização, direção ou
gerenciamento, pelo controle organizacional de recursos para conclusão dos objetivos e
metas do projeto.
Sponsor
Patrocinador Principal
Sponsor
Patrocinador Principal
Comitê Executivo do Projeto
Lider do Projeto
Equipe Funcional Equipe Desenvolvimento Equipe de Tecnologia Equipe de Gestão de Mudança
Equipe PMO
PUC-Rio - Certificação Digital Nº 0321251/CA
48
Em um complexo ambiente de implementação tecnológica, existe uma crescente
necessidade de gerenciar grupos do projeto, estrategicamente relacionados a um objetivo
principal, visando obter o máximo de retorno e assim colher o máximo em benefícios.
O somatório dos múltiplos projetos e diversas equipes passa a ser maior do que
representariam isoladamente em um projeto simples, dessa forma esses gigantescos
empreendimentos terão grande probabilidade de oferecer um significativo impacto em
todas as principais funções comerciais, além de mudar a direção estratégica da organização.
A necessidade de minimizar os efeitos negativos de um projeto de grande porte nas
organizações e a busca pela maximização dos resultados e sucesso na implementação
projeto fazem com que a utilização da estrutura do escritório de gestão do projeto tenha
objetivo de maximizar os benefícios da realização, com apoio de técnicas de gestão e
utilização de ferramentas específicas.
O gerenciamento de projeto se mostra eficaz para atingir as metas dentro do prazo e
orçamento definido. Ele é aplicável para projetos de qualquer porte complexidade e custo.
A chave para o sucesso no gerenciamento de projetos é a comunicação clara de sua
missão e de seus objetivos baseado na geração de benefícios reais, quantificáveis, mas
também de benefícios menos tangíveis. O sucesso também depende de um patrocínio ativo,
de um gerente e uma equipe experientes para o programa, e do uso de um sistema
estruturado e uniforme apoiado em um plano abrangente do programa.
Analisando a estrutura de comunicação do projeto e execução do projeto, podemos
entender um projeto de implementação seguindo a estrutura caracterizada na Figura 14. A
partir dessa figura podemos entender que a equipe PMO é uma estrutura de suporte ao
projeto que visa ser um instrumento de suporte à decisão, sem interferir diretamente na
execução dos projetos e de forma a aumentar a probabilidade do cumprimento de metas de
prazo, custo e qualidade dos projetos.
A utilização da dinâmica de sistemas no gerenciamento de projeto, através de ações
da equipe de PMO, torna o entendimento e controle das metas do projeto, eificaz para todos
os níveis de organizacionais do projeto.
PUC-Rio - Certificação Digital Nº 0321251/CA
49
Figura 14 - Diagrama de Comunicação versus Execução do Projeto (Fonte: Bearingpoint,
2004)
O PMO se concentra no planejamento, priorização e execução de projetos vinculados
aos objetivos gerais de negócios do cliente.
Os maiores benefícios, de que listados em pesquisa realizada pela CIO Survey (2003)
são:
− Implementar padrão de Gestão de Projeto – 62% ;
− Aumentar a satisfação do cliente interno – 38% ;
− Aumentar a produtividade do funcionário – 39% ;
− Reduzir custos – 27% ;
− Aumentar Satisfação do Cliente Externo – 25%.
O Diagrama de Comunicação versus Execução do Projeto apresenta a estrutura de
informação e ação existente dentro de um projeto, onde o escritório de gestão é fator
catalisador do atraso das informações, detecção de problemas , erros, percepção de fatores
que influenciam a equipe. Pode-se a partir desse conceito estruturar a modelagem dinâmica
de um projeto de ERP, onde a simulação dos principais fatores de atraso e dos impactos no
projeto podem ser visualizados e analisados sob o enfoque de gestão do projeto.
Equipe
Funcional
Escritório de Gestão do Projeto
Atividades:
Evolução/ Resultado: de
identificação de indicadores até a
emissão de relatórios gerenciais
Conhecimento: Gestão da base
de problemas, riscos e mudança
dos projeto
Transformação: da identificação
de necessidades de mudança até
o monitoramento da transformação
Gerência do
Projetos
Fluxo de
Informações
Equipe
Desnvolvi
mento
Equipe
Tecnologia
Equipe
Gestão de
Mudança
Equipe
Funcional
Escritório de Gestão do Projeto
Atividades:
Evolução/ Resultado: de
identificação de indicadores até a
emissão de relatórios gerenciais
Conhecimento: Gestão da base
de problemas, riscos e mudança
dos projeto
Transformação: da identificação
de necessidades de mudança até
o monitoramento da transformação
Gerência do
Projetos
Fluxo de
Informações
Equipe
Desnvolvi
mento
Equipe
Tecnologia
Equipe
Gestão de
Mudança
PUC-Rio - Certificação Digital Nº 0321251/CA
4
ESTUDO DA DINÂMICA DE UM PROJETO
Neste capítulo, apresentaremos o estudo da dinâmica da gestão de projetos,
demonstrando como os principais autores de Dinâmica de Sistemas apresentam
sua aplicações em gestão de projeto de tecnologia.
Os estudos realizados por esses autores tiveram o intuito de aumentar o
entendimento do desenvolvimento do projeto, visando contribuir aumento da
compreensão das relações de realimentação e das características dinâmicas que
possuem impacto na performance do projeto, avaliando a natureza desses
impactos, apresentados em modelos mentais e formais, de gestão e performance
do projeto.
4.1 A visão da Dinâmica de um Projeto – Modelo Mental
Para conduzir um projeto de sucesso, é importante entender o escopo do
trabalho que deverá ser realizado, seus riscos, recursos necessários, atividades a
serem finalizadas, marcos a serem atingidos, esforços gastos e o cronograma a ser
seguido (Webster Junior, 2002).
Um projeto, de acordo com as nove áreas de conhecimento definidas no
PMBok Guide (PMI, 2004), é organizado em quarenta e quatro processos de
gestão, como podemos verificar no quadro.2.
A análise do modelo mental dos processos de gestão em relação às áreas de
conhecimento, possibilita o entendimento dos produtos e atividades de entrada e
saída para cada processo dentro de um projeto.
Quadro 2 – Mapa dos processos de gestão de projetos (PMbok, 2004)
Áreas de
Conhecimento
Processo de
Inciailização
Processos de
Planejamento
Processo de
Execução
Processo de
Controle e
Monitoramento
Processo de
encerramento
Gestão da
Integração
• Desenvolver
Project Charter
• Desenvolver
Project Statement
• Desenvolver Plano de
Gestão
• Dirigir e
gerenciar o plano
de execução do
projeto
• Monitorar e
controlar o
trabalho do
Projeto
• Encerrar o
projeto
Gestão do
• • Planejamento de • • Verificação de •
PUC-Rio - Certificação Digital Nº 0321251/CA
51
escopo
escopo
• Definição de Escopo
• Criar WBS
Escopo
• Controle de
Escopo
Gestão do
Tempo
• • Definição de Atividade
• Sequenciamento de
atividade
• Estimativa de
atividade de recurso
• Estimativa de duração
de atividades
• Desenvolvimento de
cronograma
• • Controle de
Cronograma
•
Gestão do
Custo
• • Estimativa de custo
• Orçamento de custo
• • Controle de
Custo
•
Gestão da
Qualidade
• • Planejamento de
qualidade
• Garantia da
qualidade de
performance
• Controle da
performance da
qualidade
•
Gestão dos
Recursos
Humanos
• • Planejamento de
recursos humanos
• Aquisição da
equipe do projeto
• Desenvolver a
equipe do projeto
• Gestão da
equipe do projeto
•
Gestão da
Comunicação
• • Planejamento de
comunicação
• Distribuição da
Informação
• Reportar
andamento do
projeto
• Gerenciar
Stakeholders
•
Gestão do
Risco
• • Planejamento de
gestão de risco
• Identificação de Risco
• Analise qualitativa do
Risco
• Análise quantitativa do
Risco
• Planejamento de
resposta ao Risco
• • Controle e
monitoração de
risco
•
Gestão de
Fornecedores
• • Planejar Compras e
aquisições
• Plano de Contrato
• Resposta ao
pedido do
Fornecedor
• Selecionar
fornecedores
• Administração
de contrato
• Fechamento
de contrato
Analisando complementarmente as fases descritas na figura 12 e os
processos estabelecidos pelo PMI no quadro 2, temos em cada fase do projeto de
ERP, a execução dos principais processos de gestão, cada uma delas com
características distintas.
As diversas fases descritas em um projeto de ERP, como preparação do
projeto, desenho da solução, desenvolvimento da solução, preparação final e
suporte, possuem características bem definidas. De acordo com Ford (1995), essas
características possuem interações físicas e, no processo de informação com as
decisões gerenciais, irão criar uma dinâmica de projeto integrada com as
PUC-Rio - Certificação Digital Nº 0321251/CA
52
variáveis. Dentre essas variáveis devem ser citadas: a duração de atividade e
seqüência de atividades; os requerimentos de informações, que compreendem a
informação das dependências; as restrições entre fases; a política de liberação de
trabalho e por fim, a coordenação e gestão das atividades de retrabalho e revisão.
De acordo com Webster Junior (2002), o método tradicional de análise do
projeto é a verificação do caminho crítico. Este estudo é realizado através do
cálculo da menor data de início de execução e maior data de finalização das
atividades existentes no projeto. O caminho crítico realiza, entre outros cálculos,
uma análise de recursos. Este cálculo é aplicável ao desenvolvimento de produtos
e de projetos, onde os elementos das atividades são similares em objetivos e
cronogramas, possuindo como foco a finalização do projeto no menor tempo
possível.
Segundo Rodrigues e Willians (1996), existem quatro razões que, uma vez
identificadas, tornam os modelos tradicionais inapropriados:
− Grande detalhamento do planejamento de atividades resulta em uma
complexidade que impossibilita uma rápida e clara análise estratégica.
− Não incorporam explicitamente a influência de fatores humanos.
− Não consideram explicitamente o fenômeno do retrabalho.
− Falham na captura da dinâmica da interação entre desenvolvimento técnico
e políticas de gestão.
Desta forma, o aumento da complexidade de um projeto promove uma maior
interdependência de informações entre as fases e elementos, ocasionando a inter-
relação das atividades paralelas e o grande detalhamento de atividades.
Baseado nessa complexidade que ocorre em projetos de larga escala, Ford e
Sterman (1999) definiram a “síndrome dos 90%” como sendo um problema que
atinge os projetos, mostrando que um projeto ao atingir 90% de realização do
cronograma original, repentinamente não obtém mais avanço, finalizando apenas
depois que duas vezes do tempo original do projeto tenha ocorrido.
Abdel-Hamid apud Ford e Sterman (1999) apresentam uma abordagem de
simulação para integrar os comportamentos e processos e investigar a “síndrome
dos 90%” em projetos de implementação de software. Foi identificado que a
eliminação dessa síndrome pode potencialmente reduzir o ciclo de execução do
projeto em 50% do prazo original. O trabalho também mostrou que as causas da
PUC-Rio - Certificação Digital Nº 0321251/CA
53
síndrome são o planejamento subestimado e a falta de acompanhamento do
avanço e da qualidade do projeto. Demonstrou-se que problemas de
desenvolvimento do processo de gestão (atraso na detecção de erros), paralelismo
de atividades e de dificuldade na decisão gerencial (estimativa do tamanho do
projeto) são os elementos críticos da “síndrome de 90%”.
Segundo Ford (1995) a realização de atividades em paralelo possui como
objetivo primário à redução do ciclo de tempo pela melhoria do planejamento e
execução de múltiplas atividades de desenvolvimentos simultâneos ao invés do
modelo seqüencial.
Baseado em um modelo de Willians apud Enger (2004), o ciclo de
realimentação positiva ao executar várias atividades do projeto simultaneamente
cria uma interdependência entre os diversos componentes. Ou seja, para o
desenvolvimento de um item é necessário que se tenha informações suficientes
vindas dos demais. Este fato faz com que a duração de uma atividade seja
aumentada devido à necessidade de coordenação com as atividades dos demais
itens, causando atraso no desenvolvimento do projeto como um todo. Este atraso
unido ao prazo restrito requerido pelo cliente, faz com que o gerente do projeto
opte por desenvolver mais atividades em paralelo, fechando o ciclo.
Cronograma Apertado
Inter-relação das
atividades paraleas
+
+
Paralelismo de atividades
Duração das atividades
+
+
R
+
Atraso
Figura 15 – Ciclo de paralelismo básico
O paralelismo de atividade representa que o mesmo recurso está sendo
requerido em duas ou mais atividades ao mesmo tempo, podendo ocasionar a
necessidade de horas extras ou ainda o atraso de uma das atividades, ambas
causando aumento do custo.
Com o aumento do paralelismo e da interdependência de atividades,
inevitavelmente ocorrem atrasos devido às restrições de tempo e de recursos
existente em um projeto. O atraso no projeto pode ser causado através de um ciclo
vicioso, onde o atraso em um dos elementos do projeto poderá causar atraso dos
PUC-Rio - Certificação Digital Nº 0321251/CA
54
demais ou, alternativamente o projeto avançará, porém baseado em informações
não consolidadas de um elemento atrasado, conforme apresentado na Figura 16.
Trabalho com item não
consolidados
Falta de Consolidação do
Sistema
Cronograma Apertado
Inter-relação das
atividades paraleas
Atraso
Retrabalho
+
+
+
+
+
+
Figura 16 – Ciclo de paralelismo considerando a consolidação do sistema
Eventualmente em uma fase mais adiantada, os dados estimados poderão
mostrar-se incorretos, resultando em retrabalho para corrigi-los e
conseqüentemente em atraso, que afetará os elementos relacionados. Quando isso
ocorre, o trabalho realizado terá que ser adequado às novas informações, causando
um aumento na taxa de retrabalho, que por sua vez provocará atraso, aumentando
a inter-relação das atividades entre si.
O aumento das dependências entre as atividades paralelas e o aumento da
taxa de retrabalho faz com que haja mais atividades a serem realizadas. Como em
geral os recursos disponíveis em um projeto são limitados, teremos uma
contribuição para o aumento do atraso.
Analisando o ciclo da Figura 17, temos um ciclo de realimentação positiva
interna a outro, dessa forma gerando um sistema complexo e sensível, onde
pequenas perturbações, como a demora na aprovação dos desenhos dos processos
de negócios ou uma modificação inesperada por motivo de erro na especificação
do produto, apresentam efeitos maiores que o esperado devido ao seu poder de
amplificação no sistema.
PUC-Rio - Certificação Digital Nº 0321251/CA
55
Atraso
Inter-relação das
atividades paraleas
+
Trabalho adicional a ser
realizado
Retrabalho
Recursos Treinados
disponívies
+
+
-
+
Figura 17 - Ciclo de paralelismo considerando recursos disponíveis limitados
De uma forma genérica vemos o ciclo de paralelismo das atividades
conforme a Figura 18.
Trabalho com item não
consolidados
Consolidação do Sistema
Cronograma Apertado
Retrabalho
+
-
+
+
+
Atraso
Inter-relação das
atividades paraleas
+
Trabalho ser realizado
Recursos Treinados
disponívies
+
+
-
+
-
Paralelismo de atividades
Duração das atividades
+
+
Figura 18 – Esquema de paralelismo (fonte: Willians apud Enger (2004)
Segundo Ford (1995), existe seis estruturas chave de realimentação em um
sistema dinâmico de projeto. A primeira estrutura apresentada na figura 19 é a
estrutura de trabalho, onde é constituída de três enlaces de realimentação de
balanço, onde o aumento do esforço de trabalho como uma resposta da pressão
pelo cronograma apertado é comum na gestão de projetos de implementação.
Como resposta a esse modelo é possível ajustar a quantidade de trabalho.
PUC-Rio - Certificação Digital Nº 0321251/CA
56
Pressão de Cronograma
Tempo estimado para
Finalização
+
Trabalho restante
+
-
+
Taxa de Finalização das
atividades
Quantidade de Trabalho
Trabalho Semana
Tempo Disponível
Equipe
Intensidade de
Trabalho
+
++
+
+
+
+
-
Ciclo de Balanço
(B)
(B)
(B)
Figura 19 – Estrutura de Trabalho
A estrutura de trabalho, apresentada por Ford (1995), provê um método de
descrever o impacto em diversos modelos de governança (políticas de gestão).
Esta política pode ser vista como o plano para alteração de forças para os
relacionamentos entre as variáveis.
A variável equipe, descrita por Webster (2002) como a taxa de utilização de
recursos, é a variável que determina o custo da atividade. Esta variável é
determinada por diversos fatores, sendo que o paralelismo de atividades para um
mesmo recurso e a dependência de atividades predecessores tornam-se críticos.
O paralelismo de atividade, fator não apresentado na estrutura de Ford
(1995), representa que o mesmo recurso é necessário em duas ou mais atividades
ao mesmo tempo, causando uma necessidade de realização de hora extra ou atraso
de uma das atividades, ambas causando aumento do custo.
A segunda estrutura apresentada na figura 20 é a estrutura de pressão no
cronograma, que utiliza a idéia de meta flutuante, descrevendo uma característica
comum na gestão de projetos, onde a meta (data fim) deslize conforme as
condições do sistema (tempo esperado para finalizar).
Nessa estrutura de Ford, a proposta é a redução da pressão no cronograma,
de forma a diminuir a resistência a modificação da data final, o que deve
representar um comprometimento da equipe de desenvolvimento com a realização
dos prazos do cronograma.
PUC-Rio - Certificação Digital Nº 0321251/CA
57
Pressão de Cronograma +
-
Data Fim
Prazo para
Data Fim
Intensidade de
Trabalho
-
-
(B)
Intensidade de
Trabalho
+
Figura 20 – Estrutura de Pressão no Cronograma
A estrutura de Retrabalho é a terceira estrutura chave apresentada para um
projeto por Ford (1995). Nessa estrutura, os erros existentes ocasionam um
retrabalho dentro do produto do projeto. Diferente de um problema de qualidade,
onde existe a opção de manter a baixa qualidade do produto, um erro acarreta em
um retrabalho necessário, ocasionando um maior impacto em todas as tarefas
subseqüentes.
A estrutura de retrabalho descreve o esforço adicional no progresso para
completar o projeto, conforme a Figura 21.
O enlace de balanço representado pela Figura 21 demonstra a pretensão de
impacto da resposta do gerenciamento visando aumentar a Pressão de
Cronograma e reduzir o Trabalho Restante. Os dois Enlaces de Reforço
representam o impacto do efeito não intencional na estrutura de retrabalho, ou
seja, a geração de erros adicionais que requerem correção.
Pressão de
Cronograma
+
Trabalho
Restante
Atividades
finalizadas
sem erros
Atividades
com Erros
conhecidos
+
+
(B)
Taxa de
finalização
percebida
+
Atividades
com Erros não
conhecidos
Taxa de
Criação de
Erro
+
+
+
+
+
(R)
(R)
Figura 21 - Estrutura de Retrabalho
PUC-Rio - Certificação Digital Nº 0321251/CA
58
De acordo com Ford apud Cooper (1993), a estrutura de retrabalho foi
implementada com o elemento de Erros Desconhecidos, de forma a estimar que o
tempo para descobrir um erro pode ser aproximadamente 25% a 75% do tempo
requerido para a realização do trabalho original. Ford demonstrou que esse atraso
é um dos maiores e mais importante determinante da performance do ciclo de
tempo.
O modelo de gestão pode ter um grande impacto na performance com a
redução do tempo de percepção do erro, tornando a influência do enlace inferior
de reforço mais fraco, de forma a realizar ações de comunicação efetiva, como
uma análise de qualidade de erros ou desenvolvimento de reuniões de equipe.
A quarta estrutura é o Trabalho Disponível, pois em muitas fases e produtos
do projeto existem restrições internas para a disponibilidade do trabalho a ser
realizado. Essa disponibilidade é referente a dependências entre atividades, onde
uma atividade depende de sua antecessora para poder ser realizada.
Exemplificando, as atividades de execução do teste do desenvolvimento não
podem ser realizadas antes da finalização do próprio desenvolvimento.
Esta limitação de disponibilidade de trabalho para uma fase individual de
um projeto é a base de alguns modelos de projetos (tal como a teoria das filas,
caminho crítico e método PERT). Webster Jr. (2002) comenta que a dependência
de atividades é o fator que encadeia o atraso de uma atividade predecessora,
fazendo com que o recurso responsável pela atividade futura possa ficar sem
trabalho para realizar, porém adicionando um custo de homem hora sem
produção.
Ford (1995) define trabalho base como o trabalho que deve ser realizado
para a realização das atividades pela primeira vez , definido no início do projeto.
As restrições impostas pelo trabalho disponível impactam a taxa de
realização do trabalho base pela disponibilização do estoque de trabalho base não
realizado, demonstrado na Figura 22.
PUC-Rio - Certificação Digital Nº 0321251/CA
59
Taxa de tarefas a
serem realizadas
Taxa de
realização do
Trabalho Base
Trabalho Base
disponível para
realização
Trabalho Base
não realizado
+
(B)
Restrições de
Precedência
-
Trabalho Base
Realizado
Escopo do
Projeto
(R)
+
-
+
+
+
+
Figura 22 - Estrutura de Trabalho Disponível
O enlace de reforço na estrutura de trabalho disponível representa a
liberação de novos trabalhos a ser realizada dentro da data de conclusão. O enlace
de balanço representa a redução no trabalho base disponível, porém não finalizado
no prazo de conclusão do trabalho.
As restrições de precedência e a taxa de tarefas a serem realizadas são a base
para a modelagem de múltiplas fases interdependentes do produto. A restrição de
precedência descreve o possível progresso de uma fase anterior baseada no avanço
das fases subseqüentes que são dependentes (restrições externas) e o pregresso
baseado no avanço da própria fase (restrições internas).
A Estrutura da Qualidade, quinta estrutura apresentada, é a função de gestão
do projeto, cujo efeito é a repetição das tarefas de desenvolvimento do produto.
Webster Jr (2002) define qualidade como sendo a diferença entre o
planejado e objetivo atingido para o produto do projeto, em termos de
conformidade com a especificação, seguindo uma visão tradicional da gestão de
projetos.
Qualidade = (Trabalho realizado/ Trabalho planejado) X 100
Além disso, a análise da qualidade deve ser realizada como um reflexo das
necessidades de desejos do cliente, que com o decorrer do projeto tornam-se mais
precisas e definidas.
Ford (1995), seguindo as definições de estrutura básicas de gestão, mostra,
de forma distinta à Estrutura de Retrabalho, que a Estrutura de Qualidade reflete o
nível de cumprimento dos objetivos do cliente, como o número de imperfeições
no produto ou quantidade de dados não migrados dentro de uma base de dados.
Essa estrutura reflete um aspecto real da gestão de projeto, pois exprimem um
posicionamento voluntário para a performance padrão e ajuste do processo para
PUC-Rio - Certificação Digital Nº 0321251/CA
60
atingir o padrão definido, influenciando assim as decisões de retrabalho de
atividades, conforme Figura 23.
-
(R)
Padrão de
Qualidade
Qualidade do
Trabalho
Tarefas
finalizadas
sem Erros
Qualidade do
Produto
Defasagem de
Qualidade
Trabalho
restante
Pressão para
diminuição dos
requerimento de Projeto
+
+
+
+
+
+
-
-
(B)
(R)
Figura 23 - Estrutura de Qualidade
O enlace de reforço superior, dentro da Estrutura de Qualidade, representa
um dos impactos pretendidos da definição dos níveis de qualidade, de forma que
aumentando a qualidade do produto temos um aumento no padrão de qualidade. O
enlace de balanço representa a resistência do aumento da qualidade causada por
um implemento do desnível de qualidade. Já o último enlace, o enlace inferior de
reforço, representa um segundo beneficio da gestão de qualidade, que é o aumento
velocidade de realização do projeto. De acordo com Ford (1995), quanto maior o
padrão de qualidade, maior é o ciclo de tempo, descrevendo uma diferença na
visão dos gestores de projeto para a perspectiva tradicional qualidade e tempo.
Como última estrutura, Ford (1995) definiu a Estrutura do Escopo,
representando o ajuste do tamanho do projeto. Webster Junior (2002) diz que a
Performance do Escopo é a relação entre o produto final realizado no projeto e sua
proposta inicial, sendo que seu objetivo não se trata apenas do produto final
concluído. Trata-se da forma que ocorreu o progresso do projeto, onde temos
diversos objetivos sendo atingidos, tais como minimizar tempo, custo ou
retrabalho.
PUC-Rio - Certificação Digital Nº 0321251/CA
61
Taxa de
finalização de
atividades
Trabalho
Restante
Pressão para diminuição
dos requerimentos do
Projeto
Escopo do
Projeto
Fila de
Atividades
Porcentagem do
Escopo do Projeto
atendido
(B)
(R)
++
-
+
-
Figura 24 - Estrutura do Escopo
De acordo com Ford (1995), o enlace de balanço descreve um impacto
tipicamente intencional para a redução de escopo, com intuito de acelerar o
progresso pela redução da quantidade de trabalho a ser realizado. O enlace de
reforço é tipicamente não intencional e muitas vezes não percebido.
As seis estruturas de realimentação representam um modelo do
desenvolvimento da solução para implementação, que resultam em uma série de
combinações que não podem ser claramente demonstradas em um simples
Diagrama. A complexidade dos enlaces excede as barreiras de racionalidade
humana para simular e predizer com precisão.
De forma sintética, no quadro 3, temos as seis principais estruturas descritas
por Ford(1995)
Quadro 3 – Seis Estruturas de Realimentação – Ford (1995)
Pressão de Cronograma
Tempo estimado para
Finalização
+
Trabalho restante
+
-
+
Taxa de Finalização das
atividades
Quantidade de Trabalho
Trabalho Semana
Tempo Disponível
Equipe
Intensidade de
Trabalho
+
++
+
+
+
+
-
Ciclo de Balanço
(B)
(B)
(B)
Estrutura de Trabalho
Pressão de Cronograma +
-
Data Fim
Prazo para
Data Fim
Intensidade de
Trabalho
-
-
(B)
Intensidade de
Trabalho
+
Estrutura de Pressão no Cronograma
PUC-Rio - Certificação Digital Nº 0321251/CA
62
P ressão de
Cro nogram a
+
Traba lh o
Re stante
Ativida des
fina lizadas
se m erros
A tividade s
com E rros
con hecido s
+
+
(B)
Ta xa de
fin alizaç ão
perceb id a
+
A tivid ad es
com E rros n ão
con hecido s
Ta xa de
Criação de
E rro
+
+
+
+
+
(R )
(R )
Estrutura de Retrabalho
Taxa de tarefas a
serem realizadas
Taxa de
realização do
Trabalho Base
Trabalho Base
disponível para
realização
Trabalho Base
não realizado
+
(B)
Restrições de
Precedência
-
Trabalho Base
Realizado
Escopo do
Projeto
(R)
+
-
+
+
+
+
Estrutura de Trabalho Disponível
-
(R)
Padrão de
Qualidade
Qualidade do
Trabalho
Tarefas
finalizadas
sem Erros
Qualidade do
Produto
Defasagem de
Qualidade
Trabalho
restante
Pressão para
diminuição dos
requerimento de Projeto
+
+
+
+
+
+
-
-
(B)
(R)
Estrutura de Qualidade
Taxa de
finalização de
atividades
Trabalho
Restante
Pressão para diminuição
dos requerimentos do
Projeto
Escopo do
Projeto
Fila de
Atividades
Porcentagem do
Escopo do Projeto
atendido
(B)
(R)
++
-
+
-
Estrutura do Escopo
Analisando o quadro 3 e relacionando com as áreas de conhecimento e
processos definidos no PMBok (PMI, 2004), apresentadas no quadro 2, vemos
que os principais ações dos processos de planejamento, execução e monitoração,
estão contemplados nas estruturas descritas.
Ford (1995) apresentou uma visão integrada de projetos em fases onde
potencializou as estruturas ligações de informações de fases predecessores e
acrescentou o fluxo de erros entre as fases que mostram grandes impactos,
conforme mostrada na Figura 25.
PUC-Rio - Certificação Digital Nº 0321251/CA
63
Retrabalho -
Fase 01
Erros encontrados
internamentes - Fase 01
Erros Gerados -
Fase 01
Trabalho Planejado
Incial - Fase 01
Probabilidade de
Fracasso - Fase 01
+
+
+
+
+
Tarefas Liberadas -
Fase 01
Erros Liberados -
Fase 01
Erros da Fase 01
econtrados - Fase 02
Retrabalho -
Fase 02
Erros encontrados
internamentes - Fase 02
Erros Gerados -
Fase 02
Trabalho Planejado
Incial - Fase 02
Probabilidade de
Fracasso - Fase 02
+
+
+
+
+
Tarefas Liberadas -
Fase 02
Erros Liberados -
Fase 02
+
-
Tarefas Recicladas
- Fase 01
+
-
+
+
-
-
+
Figura 25 - Modelo do Fluxo de Erros por Múltiplas Fases (Fonte: Ford, 1995)
4.2 Ciclo de Retrabalho – Modelo Formal
Cooper e Mullen apud Sterman (2000) apresentaram uma análise dinâmica
de um projeto, baseados em problema de atraso, aumento de custo e problemas de
qualidade no projeto, disponibilizados através de um modelo formal.
A abordagem apresentada nesse modelo é considerada como um fluxo
contínuo de trabalho e informações, diferentemente dos modelos exibidos nas
técnicas tradicionais de gestão, que consideram o projeto como sendo composto
de atividades discretas e individuais.
Esse modelo foi disposto para um projeto de desenvolvimento, cuja natureza
engloba estrutura e processos integrativos, onde a importância da qualidade
realizada e da integração das informações incompletas entre fases subseqüentes na
realização do produto são fatores primordiais para análise do retrabalho realizado.
PUC-Rio - Certificação Digital Nº 0321251/CA
64
De uma forma tradicional, o modelo do projeto considera apenas o
“Trabalho a ser realizado”, “Trabalho em Processo“ e “Trabalho Concluído”, o
que pode ser evoluído para uma para a visão dinâmica, considera ciclos de
retrabalho.
Na Figura 26, vemos o processo onde de um lado temos um estoque com o
“Trabalho a ser realizado” que se transforma em “Trabalho concluído” à medida
que passa por uma taxa de realização fixa (válvula), chamada de “Taxa de
atividades realizada”.
Trabalho a ser
realizado
Trabalho
concluído
Taxa de atividades realizada
Trabalho Inicial
Figura 26 - Esquema tradicional
Esta representação pode ser melhorada quando reconhecemos que a válvula
da Taxa de atividades realizada ou a Fluxo de Trabalho é controlada pelos fatores
de quantidade de pessoas envolvidas na realização do trabalho e por sua
produtividade, de maneira a aumentar ou diminuir a taxa de trabalho a ser
realizada.
Trabalho a ser
realizado
Trabalho
concluído
Taxa de atividades realizada
Trabalho Inicial
Pessoas
Produtividade
Figura 27 - Esquema tradicional com o acréscimo da influência da produtividade e
das pessoas.
No passo seguinte Cooper e Mullen apud Sterman (2000) inserem no
modelo a Qualidade, traduzida como o percentual de trabalho realizado realmente
concluído. Uma fração deste trabalho pode ser rejeitada e deverá ser refeito. Este
retrabalho voltará à entrada do processo somando-se ao “Trabalho a ser realizado”
PUC-Rio - Certificação Digital Nº 0321251/CA
65
que consumirá os mesmos recursos que foram planejados apenas para o Trabalho
original.
Figura 28 – Ciclo de Retrabalho
De maneira mais realista, é necessário separar o retrabalho em dois estágios:
o não descoberto e o conhecido. Esta distinção se faz necessária, já que um muitas
vezes uma falha de projeto só é descoberta muito tempo depois, em geral, durante
os testes finais do sistema. Quanto mais se demora a descobrir uma falha, maior
será o impacto do retrabalho no progresso do projeto, uma vez que muitas
atividades serão afetadas.
Figura 29 – Ciclo de Retrabalho com Retrabalho não identificado.
Nos sistemas tradicionais, o retrabalho não descoberto é computado junto
com a parcela do trabalho concluído, dando a impressão de maior avanço do
progresso do projeto do que realmente ocorreu. Aparece, portanto, uma diferença
entre o progresso percebido e o realmente atingido, relacionado à síndrome de
90% apresentada por Sterman (2000) .
Segundo Cooper e Mullen apud Sterman (2000) , este último elemento do
ciclo de retrabalho, o retrabalho não identificado, tem papel fundamental na
propagação de problemas durante o decorrer do projeto. Enquanto não percebidos,
PUC-Rio - Certificação Digital Nº 0321251/CA
66
problemas como erros de software ou erros de cálculo de projeto causam a perda
de produtividade, atrasos e mais retrabalho nas atividades dependentes. O
retrabalho não identificado é a fonte mais importante de crise nos custos e prazos
de um projeto.
A partir do desenvolvimento desse primeiro modelo, Cooper e Mullen apud
Sterman (2000) desenvolve uma análise verificando como a gerência do projeto
influencia a performance do projeto.
Através do ciclo do retrabalho apresentado, Cooper e Mullen apud Sterman
(2000) modela o primeiro elemento como sendo a utilização de horas
extraordinárias de trabalho no projeto. Esta medida geralmente ocorre quando é
verificado um desvio no curso planejado para progresso dos trabalhos. Esta
constatação da ocorrência do atraso inicia-se à medida que os retrabalhos, até
então considerados como parte do trabalho já realizado, começam a serem
descobertos.
Quando se toma a decisão de se utilizar o artifício das horas extra, imagina-
se que a situação de desvio será temporária, já em casos mais graves opta-se pela
contratação de mais mão-de-obra. No entanto, numa situação típica, o retrabalho
continua aparecendo e o tempo gasto com eles reduz ainda mais a velocidade
planejada inicialmente para progresso do projeto.
A medida corretiva que parece temporária perlonga-se por um período
superior ao esperado. A partir desse momento, os efeitos secundários começam a
aparecer, dando origem a um ciclo vicioso (Figura 30).
PUC-Rio - Certificação Digital Nº 0321251/CA
67
Figura 30 – Influência da Utilização Horas Extras
A utilização de horas extras por um período prolongado propicia a fadiga,
relaciona à queda da produtividade e da qualidade do trabalho, e que originará
mais retrabalho no projeto e mais atrasos em relação ao planejamento inicial, com
necessidades de jornadas maiores.
O efeito da fadiga sobre a produtividade e qualidade do trabalho é
aumentado à medida que as horas se acumulam. Cooper e Mullen apud Sterman
(2000) ilustra este efeito através do gráfico apresentado na Figura 31, que mostra
a quantidade de horas realmente somadas para os níveis de quatro, oito e doze
horas extras semanais trabalhadas durante um período de dois a três meses, tanto
em serviços de engenharia, como nos serviços de Produção ou Desenvolvimento.
-1
0
1
2
0 4 8 12
Horas Extras
Horas realmente adicionadas no Resultado
Engenharia Produção
Trabalho a
ser realizado
Retrabalho
não
Descoberto
Qualidade
Horas Extras
Necessidade
Pessoal
Progresso
aparente
Pessoas
Produtividade
Taxa de Atividade
realizadas
Retrabalho
não
Descoberto
Retrabalho
Conhecido
Identificação
do Trabalho
Qualidade
PUC-Rio - Certificação Digital Nº 0321251/CA
68
Figura 31 – Resultado realmente ganho com diferentes quantidades de horas extras de
trabalho. (Fonte: Cooper apud Enger , 2004)
Vemos que o progresso efetivo alcançado é muito menor do que as horas
trabalhadas e que a produtividade piora quanto maior o período de trabalho de
horas extraordinárias.
No caso da produção, a partir de dez horas extras trabalhadas por semana, a
quantidade de retrabalho torna-se muito grande e o avanço torna-se negativo, por
motivos de qualidade, erro e baixa produtividade. A partir desse cenário, onde o
atraso torna-se muito grande, ficando praticamente impossível de atingir o
planejado do inicio do projeto, inicia-se uma segunda medida, baseada na
contratação de mais pessoal. Com o processo de contratação iniciado, o projeto
passa por um problema secundário, muitas vezes desprezado pelos líderes do
projeto e o período de adaptação e aprendizagem com o trabalho.
A duração deste período pode variar, dependendo da exigência da tarefa a
ser realizada, da experiência e competência de cada indivíduo. No entanto,
invariavelmente haverá um período de transição de competência média da equipe
que pode ser reduzida com a chegada dos novos membros. Conseqüentemente, a
produtividade e a qualidade dos trabalhos serão reduzidas, aumentando o
retrabalho que não foi considerado quando se dimensionou o novo tamanho da
equipe.
A partir desse cenário temos uma situação que pode piorar a performance do
projeto. Pois quanto mais contratações ocorrerem, menor será a competência
média da equipe, supondo-se que os melhores profissionais foram contratado
inicialmente isto ocorre geralmente em projetos de tecnologia.
A grande quantidade de pessoas, característica dos projetos de tecnologia,
traz a tona o fator de relacionamento entre funcionários, que se torna crítico,
principalmente com o aumento das contratações. Este fator mostra que o nível de
atrito é maior entre os novos funcionários, do que com os funcionários antigos.
Isso ocorre basicamente por erros na contratação, expectativas de funcionários não
atendidas, menor lealdade com a empresa. O Nível de Atrito gera mais
necessidade de contratação que por sua vez contribui para aumentar novamente o
Nível de Atrito, em um ciclo de realimentação positivo, como demonstrada na
Figura 32.
PUC-Rio - Certificação Digital Nº 0321251/CA
69
Figura 32 – Influência da Contratação de Novos Funcionários
Os efeitos do ciclo de retrabalho de Cooper e Mullen apud Sterman (2000)
são apresentados de forma completa, estabelecendo-se os efeitos das fases
anteriores do projeto na influência da contratação, retrabalho e qualidade das
atividades realizadas.
Retrabalho
não
Descoberto
Retrabalho
Conhecido
Identificação
do Trabalho
Qualidade
Trabalho a
ser realizado
Retrabalho
não
Descoberto
Qualidade
Horas Extras
Necessidade
Pessoal
Progresso
aparente
Pessoas
Produtividade
Taxa de Atividade
realizadas
Nível de
Competência Incial
Contratação
Nova Equipe
Equipe Disponível
Nível de Atrito
Nível de Competência
da Equipe
PUC-Rio - Certificação Digital Nº 0321251/CA
70
Figura 33 – Influência da Contratação de Pessoal
A decisão de contratar mais funcionários para um correto dimensionamento
da equipe durante o andamento do projeto é baseado apenas na percepção de
trabalho concluído em estágios anteriores, dos quais a atual fase é dependente. No
entanto, não é normalmente levado em conta a existência do “Retrabalho não
Descoberto” como conjunto do “Trabalho Concluído”.
Ao definir o tamanho de uma equipe de trabalho, o gerente considera a
disponibilidade aparente na necessidade de desenvolvimentos e produtos que são
pré-requisitos para o trabalho em questão. Porém a baixa qualidade destas
atividades causará uma redução não intencional na produtividade e na qualidade
do trabalho subseqüente. Assim, se a qualidade da informação não for considerada
no momento em que se planeja um estágio subseqüente, a descoberta de
retrabalho implicará em uma necessidade maior de força de trabalho que a
inicialmente estimada.
De acordo com Cooper e Mullen apud Sterman (2000) , as pessoas para
quem os gerentes de projeto reportam, tanto dentro da organização, como os
clientes, são muito freqüentemente as partes mais culpadas. Essa afirmação é
Retrabalho
não
Descoberto
Retrabalho
Conhecido
Identificação
do Trabalho
Qualidade
Trabalho a
ser realizado
Retrabalho
não
Descoberto
Qualidade
Necessidade
Pessoal
Progresso
aparente
Pessoas
Produtividade
Taxa de Atividade
realizadas
Qualidade do
Trabalho Precedente
Equipe Disponível
Impacto de etapas
precedentes de trabalho
Progresso aparente de
etapas precedentes
Retrabalho
não
Descoberto
Retrabalho
Conhecido
Identificação
do Trabalho
Trabalho a
ser realizado
Retrabalho
não
Descoberto
Taxa de Atividade
realizadas
PUC-Rio - Certificação Digital Nº 0321251/CA
71
baseada no fato que líderes do projeto, que com intuito de ver o progresso do
projeto, podem cometer um erro crítico: pressionar a equipe para que haja um
aumento indiscriminado da força de trabalho no intuito de atingir o progresso
desejado, ou ainda pressionar para que ocorra uma adequação de pessoal, sem
assumir os problemas existentes em fases anteriores.
Figura 34 – Influência da Pressão para Respeitar o Cronograma.
De fato, a pressão por um tempo prolongado afeta o desempenho da, equipe
na medida em que provoca impactos no moral dos indivíduos, contribuindo desta
maneira para a redução da produtividade e qualidade do trabalho. Além disso, no
intuito de acelerar o processo, é comum a prática de adiantar as etapas sucessoras,
de modo que o trabalho passa a ser executado fora de seqüência, utilizando
informações de estágios anteriores que ainda não foram fechadas e podem ainda
ser modificada mais adiante, gerando retrabalho.
Retrabalho
não
Descoberto
Retrabalho
Conhecido
Identificação
do Trabalho
Trabalho a
ser realizado
Retrabalho
não
Descoberto
Qualidade
Horas Extras
Necessidade
Pessoal
Progresso
aparente
Pessoas
Produtividade
Taxa de Atividade
realizadas
Nível de
Competência Incial
Contratação
Nova Equipe
Equipe Disponível
Nível de Atrito
Nível de Competência
da Equipe
Avanço do
Cronograma
Problemas de
Moral
Problemas de
Coordenação
Trabalho fora de
sequência
PUC-Rio - Certificação Digital Nº 0321251/CA
5
APLICAÇÃO DA MODELAGEM DINÂMICA DE UM PROJETO
DE ERP
A criação de um modelo de um Projeto de Implementação de ERP será feita
integrando partes existentes da estrutura do projeto em um único modelo, onde a
gestão é o mecanismo para se atingir um melhor controle do projeto, baseado na
interface com o cliente, sub-contratados e realizando a interação entre
gerenciamento, planejamento, monitoração, desenvolvimento técnico, qualidade e
gestão de configuração. As diversas funções devem manter o foco no custo,
qualidade e no tempo de duração originalmente estabelecido.
O entendimento das inter-relações, interferências existentes em um projeto
de ERP é uma função crítica para o gestor do projeto suportar um correto
planejamento de atividades, recursos e prazo em seu projeto.
Nesse capítulo, apresentaremos a visão da dinâmica de um projeto de
tecnologia de grande porte, fruto da experiência do autor em trabalhos de gestão
de projeto em implementação de softwares de ERP, utilizando como base modelos
de Cooper e Mullen apud Sterman (2000) e Ford (1995) e traduzindo
especificamente para os produtos de desenvolvimento do projeto com suas
principais interferências e inter- relações. Estabelecemos uma forma abrangente o
modelo mental e de uma forma restrita o modelo formal.
5.1 O Modelo Dinâmico
O modelo dinâmico proposto é inicialmente definido com a estruturação do
problema, onde temos como objetivo o entendimento das inter-relações,
interferências existentes em um projeto de ERP, dessa forma definindo o escopo
que será tratado e suas fronteiras para o estudo em questão.
Dentro de uma estrutura de projetos onde envolvemos equipes e produtos
diferentes dentro de um sistema complexo de alta tecnologia em um prazo
reduzido, será inevitável a existência de paralelismo entre as atividades
interdependentes. Na Figura 35 vemos os principais produtos de escopo desse
PUC-Rio - Certificação Digital Nº 0321251/CA
73
trabalho, onde, de acordo com os relacionamentos existentes, temos o teste
integrado final com dependência da configuração final, da autorização
estabelecida e da criação dos desenvolvimentos de componentes customizados.
Este por sua vez necessita da definição dos processos de negócio e preparação e
coordenação de desenvolvimentos, assim por diante.
Para realização da modelagem, estaremos definindo como escopo o produto
referente ao desenvolvimento da solução que são pertencentes ao caminho crítico,
apresentado na figura 12, onde apresentamos todo o fluxo de produtos existente
nas fases de implementação de um projeto de tecnologia.
Figura 35 - Diagrama de Fluxo de Produtos e Retrabalho em um Projeto de
Tecnologia (Bearingpoint, 2004)
A fase de realização de um projeto de ERP é intimamente ligada às
definições realizadas na fase de Desenho da Solução, com a execução dos
produtos de “Estruturação da organização de Negócio” e a “Definição dos
Processos de Negócios”.
Para execução na fase de realização, todas as informações sobre as interfaces
entre produtos e pré-requisitos dos produtos do projeto devem estar disponíveis e
consolidadas em sua fase anterior, de forma que caso este requisito não seja
observado, a equipe de desenvolvimento corre o risco de desenvolver produtos
baseando-se em premissas que posteriormente serão alterados causando retrabalho
e consumindo recursos não previstos inicialmente.
As interfaces para execução do projeto devem ser bem claras e disponíveis
em um tempo hábil, com aprovação rápida de documentação técnica, poucas
Estruturação da
Organização de
Negócio
Definição dos
Processos de
Negócio
Configuração/
Confirmação
Inicial
Prep e Coord
Desenvolv
(ABAP)
Configuração
Final
Desenv de Componentes
Customizados
(Conversões, Interfaces e
Relatórios)
Autorizações estabelecidas
Teste
Integrado Final
Produto Desenvolvido
Produtos Realizados
Retorno de Erros para Retrabalho
Legenda
PUC-Rio - Certificação Digital Nº 0321251/CA
74
modificações em relação ao escopo inicial, autonomia da equipe de gestão do
projeto e um canal único de comunicação com o cliente.
A comunicação entre as diversas equipes do projeto deve ser clara e eficiente,
de forma que as diversas frentes do projeto devem correr paralelamente e a
velocidade semelhante, para que não haja discrepâncias entre as informações
geradas entre elas. A coordenação do projeto deverá trabalhar de forma que
permita a troca de informações rápidas e sem ruídos.
A comunicação entre a equipe executora e a gerência (sponsor) do projeto
deve ocorrer através de um único canal para diminuir ao máximo as perdas devido
à falta de informação no tempo correto e devido a informações conflitantes, para
minimizar esse efeito no projeto, temos que o ideal seria haver um ponto único de
contato na gerência e outro na equipe executora do projeto
Devido à interdependência da fase do desenvolvimento, qualquer atraso que
ocorra em produtos predecessores e em fase subseqüente isoladamente, provocará
efeitos secundários nas demais, devidos aos ciclos internos de retrabalho.
5.2 O Diagrama Causal
Com a definição do problema que será conceitualizado, iniciaremos o
Diagrama Causal, que é o principal ponto para o entendimento do funcionamento
de um sistema, sendo um modelo qualitativo que representa como cada elemento
do sistema interfere nos demais.
Para construí-lo, foram utilizados como base os ciclos de paralelismo e
retrabalho como visto no capítulo quatro. Além de realizar o entendimento do
processo de gestão e de execução existente no projeto, com intuito de representar
as inter-relações que formam o sistema.
Iniciaremos o entendimento apresentando os Digramas Causais, onde na
Figura 36, temos o Escopo do Projeto como o elemento inicial do projeto definido
pela alta gestão do projeto em conjunto com os principais stakeholders do projeto.
Nesse momento, é definido qual é a abrangência do projeto, possibilitando assim
ter a relação do Trabalho Base Disponível para realização.
PUC-Rio - Certificação Digital Nº 0321251/CA
75
O Escopo do Projeto e o Trabalho Base disponível para realização são
funções da definição inicial do projeto, onde a partir desses fatores é possível
definir todo o planejamento do projeto. Nesse ponto ocorrem ações gerenciais
para impedir o aumento do trabalho base definido, seja por interesses internos ou
externos ao projeto, evitando o aumento de horas extras necessário para o projeto.
Com o progresso das atividades e o aumento do entendimento da situação
atual da empresa que está ocorrendo à implementação de ERP, muitas vezes é
iniciado um esforço contínuo de aumento do escopo do projeto. O interesse no
Aumento do Trabalho Base acordado causará uma Fila de atividades pendentes
não acordada que será fator para ações de gestão para a Pressão para Diminuição
de Requerimentos do Projeto.
O Trabalho Base Disponível para realização é a primeira definição do trabalho
a ser realizado originado ao projeto. No caso de um projeto de implementação de
ERP, podemos defini-lo como o conjunto de desenvolvimentos e configurações
no software padrão de ERP necessários para possibilitar a implementação do ERP
na corporação, baseados em um conjunto de processos de negócio definidos para
possibilitar essa implementação. Esses desenvolvimentos e a configuração padrão
definidas originalmente, tornam-se então o elemento de trabalho ou atividade
realizada pelos recursos humanos disponíveis para a execução do projeto.
O Trabalho a ser Realizado é composto pelas atividades originais planejadas
inicialmente, acrescidas dos retrabalhos identificados pela geração de erros ou das
atividades adicionais existentes na fila de atividade. O Aumento do Trabalho Base
e Modificação do Escopo do Projeto contribuirão para o aumento do estoque de
trabalho a ser realizado que, que devido às restrições colocadas nas restrições de
precedência, dos recursos disponíveis e de sua produtividade irá ser executado
mais ou menos rapidamente. O Trabalho a ser Realizado juntamente com o já
executado determinará o progresso do empreendimento e também serão fatores
determinantes na avaliação do atraso.
Com a definição do Trabalho a ser Realizado temos a ocorrência do Trabalho
em Execução que é a taxa com que o trabalho a ser realizado é executado, se
transformado em trabalho concluído ou retrabalho ainda não identificado. Ele
dependerá dos Recursos Humanos Disponíveis, bem como de sua produtividade e
influenciará positivamente o progresso aparente do projeto.
PUC-Rio - Certificação Digital Nº 0321251/CA
76
A interferência no escopo do projeto e a continua pressão no cumprimento
do prazo do cronograma junto à equipe, influencia diretamente equipe. Os
Recursos humanos disponíveis para essa equipe do projeto são compostos pelo
corpo de profissionais treinados e disponíveis para integrar a equipe do projeto. A
capacidade de recursos humanos, em termos de homem-hora é aumentada através
da liberação do trabalho em regime de horas extraordinárias. Os recursos
disponíveis determinarão a taxa de execução dos trabalhos a serem realizados e
também da produtividade da equipe. Além disso, serão utilizados na previsão do
tempo requerido para conclusão dos trabalhos e, conseqüentemente, influenciarão
na medição do atraso. Os recursos humanos disponíveis também são utilizados no
cálculo das horas-extras necessárias para recuperar um projeto atrasado ou no
cálculo dos ajustes no cronograma que serão propostos ao cliente para reduzir o
atraso.
Essas ações gerenciais representam as pressões para diminuir os
requerimentos do projeto, o qual ficam mais evidentes com o aumento da Fila de
atividades requeridas como aumento de escopo.
Recursos Humanos
Disponíveis
Trabalho a ser
realizado
+
Trabalho em
Execução
Trabalho
Concluído
+
Trabalho Base
Disponível para
realização
+
Escopo do Projeto
+
Pressão para diminuição
dos Requerimentos do
Projeto
+
Fila de atividades
+
Moficação de Escopo e
Aumento do Trabalho base
acordado
+
+
-
Progresso
Aparente
+
+
+
Horas Extras
-
Figura 36 – Digrama Causal – Trabalho e Escopo do Projeto
A seguir na com a Figura 37, representaremos da relação entre a qualidade,
geração de erros e retrabalho apresentados no Diagrama Causal da Figura 36.
A Geração de Erros é uma parte inerente ao sistema e entrará no ciclo de
retrabalho como Retrabalho não descoberto. Quando mais tarde o erro for
identificado pela equipe do projeto que verifica a qualidade e conformidade às
especificações criadas, mais demorará em ser integrado ao estoque de trabalho a
ser realizado. A Geração de Erros é geralmente exacerbada quando a visão global
PUC-Rio - Certificação Digital Nº 0321251/CA
77
do sistema é preterida por uma mais localizada. Isto pode ocorrer, por exemplo
quando uma determinada especificação tem seu desenvolvimento iniciado,
apresentando erros de consistência ou erros de integração do outras partes do
sistema já definido.
Erros não identificados farão com que o trabalho seja baseado em informações
não consolidadas, que deturparão o entendimento sistêmico do projeto,
contribuindo para a geração de mais erros, num círculo vicioso. De maneira
semelhante, erros também serão gerados pelo Paralelismo que dificulta a
consolidação do projeto ou quando o desenvolvimento se torna mais complicada e
redundante devido a alterações de escopo e especificações A qualidade do
trabalho em execução determinará a porcentagem das atividades que deverão ser
refeitas devido aos erros gerados, que posteriormente serão detectados pela análise
da qualidade transformando o retrabalho não identificado em conhecido.
Quanto maior o Paralelismo de atividades, maior será a relação de
dependência entre as atividades, tendo cada uma que aguardar informações das
demais para poder avançar e disponibilizar seus dados para que as outras
atividades possam progredir. O efeito mais danoso do Paralelismo é a geração de
erros, por exemplo, pela continuação de uma atividade baseando-a em dados não
consolidados que posteriormente serão alterados. Quanto mais tardia for a
identificação de um erro, mais atividades terão como pressuposto tal erro e maior
será a quantidade de retrabalho para corrigi-lo.
O aumento do paralelismo é muitas vezes motivo de inclusão de atividades
não planejadas anteriormente. Modificações deste tipo podem ser originadas a
partir de alterações das especificações ou escopo do projeto, com o intuito de
reduzir ou manter um cronograma apertado.
O Retrabalho não Descoberto torna-se então uma fração do trabalho
concluído devido à baixa qualidade do produto, como erros de execução devido
não alinhamento entre especificação inicial e desenvolvimento, erro na
configuração padrão, ou por erro na execução dos testes integrados. Esse
Retrabalho não Descoberto com o passar do tempo torna-se conhecido, assim o
retrabalho detectado pela equipe passará a integrar o estoque de trabalho a ser
realizado. O aumento do Retrabalho Conhecido, interfere diretamente na
Qualidade percebida pelos Stakeholders do projeto, sendo comparado a um
Padrão de Qualidade, possibilitando posicionar a gerência do projeto na
PUC-Rio - Certificação Digital Nº 0321251/CA
78
intensidade da pressão para a diminuição dos requerimentos do projeto. Em geral,
quando identificado, a equipe de projeto opta por corrigi-lo rapidamente para que
suas conseqüências sejam o menos abrangente possível. Pode-se optar pelo
paralelismo entre as atividades já programadas e os retrabalhos descobertos.
A parcela do trabalho que foi executado corretamente sem nenhuma
introdução de erros, mesmo os não identificados, e que foi definitivamente
terminado, torna-se o Trabalho Concluído final não mais precisando ser revisto ou
refeito. O Trabalho Concluído comparado ao seu complementar, o Retrabalho não
descoberto, definirá o índice de qualidade.
A Qualidade Percebida é a porcentagem das tarefas realizadas sem erros que
está definitivamente concluída e não mais necessitarão de retrabalhos futuros e o
retrabalho conhecido. A qualidade dos trabalhos realizados influenciará
diretamente a confiança do cliente em relação à equipe de projeto e varia
conforme o padrão de qualidade do projeto modifica, sob impacto da pressão de
diminuição de requerimentos do projeto.
O Progresso Aparente é o trabalho executado, tanto o efetivamente
concluído como o retrabalho ainda não identificado, em relação ao volume de
trabalho a ser realizado. Com base no progresso aparente e no cronograma oficial,
será definido o atraso do projeto e também calculada a quantidade de horas-extras
necessárias para se concluir as atividades pendentes no prazo acordado.
Paralelismo
Trabalho a ser
realizado
Trabalho em
Execução
Trabalho
Concluído
Qualidade (Geração
de Erros)
+
Retrabalho não
descoberto
Progresso
Aparente
+
Retrabalho
Conhecido
+
+
Qualidade
Percebida
-
+
+
-
-
Tarefas realizadas
sem Erros
Padrão de
Qualidade
+
+
Figura 37 – Diagrama Causal - Relação entre a qualidade, geração de erros e retrabalho
O Atraso, na Figura 38 ocorre quando o tempo necessário para a realização
de uma atividade ou um conjunto delas é superior ao que havia sido previsto no
PUC-Rio - Certificação Digital Nº 0321251/CA
79
Cronograma Acordado (cronograma planejado). O tempo necessário para
realização do conjunto de atividades depende da quantidade de trabalho a ser
realizada, da duração de cada uma das atividades, dos recursos disponibilizados e
de sua produtividade. O Atraso diminui o Nível de Confiança dos gestores,
aumentando a pressão sobre a equipe de projeto para que o cronograma seja
respeitado, bem como favorece a tomada de decisão no sentido de que mais ,
atividades devam ocorrer paralelamente.
A Moral da Equipe é uma variável de extrema importância por influenciar
diretamente a Produtividade do trabalho da equipe, como também sua qualidade
através da Geração de Erros. Entretanto, ela é difícil de ser mensurada por ser
bastante subjetiva. O ânimo da equipe é afetado quando existe o sentimento de
perda de autonomia devido ao Nível de Confiança do gestor ou quando são
solicitadas atividades adicionais (respostas a perguntas não pertinentes,
comparações, relatórios de progresso) que não contribuem para o andamento do
projeto e divergem a atenção da equipe de suas atividades mais produtivas. O
Moral da Equipe também é abalado pela pressão da gerência do projeto para que o
cronograma seja cumprido e piora ainda mais ao se perceber que os esforços não
estão surtindo efeito e o projeto continua atrasado. Na tentativa de reverter o
atraso, a equipe de projeto libera o trabalho em horas-extras cujos membros, com
o passar do tempo, irão ficando exaustos e comprometendo ainda mais a
Produtividade e a Qualidade do trabalho, uma vez que mais retrabalhos serão
gerados devido à introdução de erros no projeto.
A necessidade de aumentar a capacidade de homem-hora da equipe através de
trabalho em horas extraordinárias (Horas Extras) surgirá quando o progresso
aparente do projeto comparado com o cronograma planejado não for satisfatório e
houver uma pressão tanto interna como externa para que o prazo final seja
mantido. Além disso, é necessário que o estoque de recursos treinados da
contratada tenha se exaurido e não haja a possibilidade ou intenção de se contratar
mais pessoal. Entretanto, o trabalho excessivo em regime de horas extraordinárias
acabará por afetar o Moral da Equipe devido à exaustão crescente dos indivíduos
que terão seus períodos de descanso reduzidos, impactando na produtividade,
variando a taxa de finalização das tarefas.
A taxa de finalização de atividades e a produtividade da equipe é a
porcentagem do tempo disponível dos recursos do projeto que é utilizada em
PUC-Rio - Certificação Digital Nº 0321251/CA
80
trabalhos que contribuem efetivamente para o progresso do projeto, ou seja, para a
transformação do trabalho em execução em trabalho realizado (tanto o concluído
como o retrabalho não descoberto). A produtividade é diretamente afetada pelo
moral da equipe. Equipes cansadas e desanimadas ou desmotivadas utilizam
menos eficientemente o seu tempo. Trabalhos baseados em dados de projeto não
consolidados também reduzem a produtividade da equipe, uma vez que parte do
tempo será utilizada para a verificação do efeito das informações quando
modificadas. De maneira semelhante, o paralelismo influenciará a produtividade,
pois os recursos humanos limitados terão que dividir seus esforços entre a
coordenação adicional para troca de informações entre as atividades simultâneas e
seus trabalhos corriqueiros de desenvolvimento do projeto. A produtividade
afetará o atraso, pois ela entra no cálculo do tempo requerido para a finalização do
trabalho a ser executado, determinando quanto dos recursos serão efetivamente
utilizados.
Atraso
Paralelismo
+
Horas Extras
Cronograma Acordado
(Tempo Disponível)
-
-
Pressão para cumprir
o Cronograma
-
Taxa de Finalização das
atividades (Produtividade)
Nível de Confiança
(gestor)
-
+
-
Moral da Equipe
-
+
+
Qualidade
-
-
Figura 38 – Diagrama Causal - Moral da Equipe e Nível de Confiança do Gestor
Na Figura 39, será apresentado o último item apresentado no Diagrama
Causal. O item Cronograma Acordado (tempo disponível) está estruturado no
tempo do qual se dispõe para a execução das atividades de projeto influenciará
diretamente as decisões sobre quantas e quais destas atividades serão executadas
paralelamente e se é possível esperar a chegada de dados menos suscetíveis a
PUC-Rio - Certificação Digital Nº 0321251/CA
81
modificações futuras. O Cronograma Acordado possui o mesmo comportamento
do trabalho base disponível para realização , que varia de acordo com a variação
do escopo do projeto e com a chegada ou postergação da data fim. Haverá
também influência na noção de Atraso, pois geralmente as equipes do projeto
percebem tardiamente que a inclusão de uma especificação ou um aumento de
escopo é problemática para o avanço do projeto. Isto ocorre também devido ao
fato de que muitas partes do sistema deverão ser revistas para serem
compatibilizadas com a modificação pertinente. Assim a Duração das Atividades
será aumentada, bem como a quantidade de trabalho a ser realizado. Mais trabalho
em um sistema mais complicado contribuirá para o crescimento da possibilidade
de erros serem gerados.
Inter-relação de atividades paralelas/ restrições de Precedência é quando o
grau de paralelismo na execução das atividades do projeto é aumentado, uma vez
que atividades atrasadas se sobrepõem a outras subseqüentes ainda não atrasadas,
as dependências entre elas aumenta. Mais atividades deverão esperar informações
das demais, para que suas execuções possam ser continuadas de maneira
consistente, aumentando o tempo requerido para realizá-las. A fase de realização
de um projeto de ERP é complexo e redundante, onde as inter-relações entre
produtos executados proporcionam um aumento da dependência entre as
atividades do projeto, que por sua vez influenciará o nível de consolidação de suas
informações. Isso ocorre claramente nos produtos de especificação e
desenvolvimento que se tornam paralelos devido aos erros de execução, sendo
para isso modificado a técnica de execução, o que aumenta a Geração de Erros,
não possibilitando a execução de uma fase futura como o teste integrado desses
desenvolvimentos.
A Pressão para cumprir o Cronograma inicia-se quando o escopo do projeto
é definido e seu respectivo cronograma acordado aprovado pela gerência e pela
equipe do projeto, a relação do atraso que inicia no projeto, a relação do tempo
estimado para realização do trabalho a ser realizado baseado na definição da Data
Fim do projeto e o tempo disponível baseado no cronograma acordado e a
qualidade percebida farão com que a equipe de projeto seja pressionada para
tomar decisões com o intuito de manter o cronograma e evitar conseqüências
negativas como a deterioração do fluxo de caixa do projeto ou o pagamento de
multas contratuais. A equipe de gerenciamento do projeto passará a exercer
PUC-Rio - Certificação Digital Nº 0321251/CA
82
pressão sobre as demais equipes para que não haja novas alterações no
cronograma. As medidas tomadas para conter atrasos são em geral a liberação do
trabalho em regime extraordinário, aumento no paralelismo das atividades,
permissão para o avanço do projeto mesmo sem informações totalmente
consolidadas e inter-relação de atividades paralela e instrução para que os
procedimentos e critérios da qualidade sejam relaxados, reduzindo a eficácia da
Garantia da Qualidade na detecção de erros. Como conseqüência da pressão para
cumprimento do cronograma, a produtividade da equipe e a qualidade do trabalho
se deteriorarão à medida que o moral da equipe é afetado negativamente. A
gerência do projeto aceitará mais solicitações feitas pelo stakeholders para
alterações do escopo com o intuito de evitar negociações demoradas. Também
aceitará a interferência do cliente no escopo como forma de demonstrar sua boa
vontade na busca de soluções para o atraso de forma que ocorra ajuste no
cronograma planejado inicial, com o intuito de diminuir o atraso percebido.
Na definição do Cronograma Acordado do projeto, as restrições de
precedência e Inter-relação das atividades paralelas e quantidade de Recursos
Humanos disponíveis e treinados para execução do projeto compões o Paralelismo
existente entre as atividades do projeto. Esse Paralelismo ocorre pois o projeto de
um sistema envolve o desenvolvimento de diversas atividades que podem ocorrer
paralelamente ou em série, de acordo com o grau de interdependência entre elas.
Em alguns casos, uma etapa não pode iniciar sem a conclusão da anterior, em
outros é possível estimar-se dados de entradas e corrigi-los posteriormente sem
grandes implicações para o restante do sistema. Outra possibilidade ainda é
desenvolver atividades dependentes simultaneamente. Cada passo adiante que
uma das atividades completa alimenta as demais com dados atualizados que
também permitirão o avanço delas e assim sucessivamente.
Isso ocorre com a definição de processos de negócios, que com o avanço
desta atividade aumenta o entendimento e a capacidade de desenvolver novas
atividades, como a configuração inicial e o desenvolvimento dos componentes
customizados, sendo que estas atividades devem ocorrer de forma estruturadas.
Uma vez que os recursos são limitados, a produtividade da equipe será
prejudicada.
O atraso do projeto aliado à pressão para manter o cronograma no prazo,
bem como o aumento da quantidade de trabalho devido aos retrabalhos que vão
PUC-Rio - Certificação Digital Nº 0321251/CA
83
sendo identificados e a fila de novas demandas possíveis, demandar uma
reprogramação das atividades para atender ao cronograma estabelecido. Devido à
restrição do tempo disponível, algumas atividades, antes programadas em série,
terão que ser executadas
O aumento do retrabalho causa influência de forma direta na pressão para
cumprir o cronograma, que proporciona um aumento na intensidade do trabalho
realizado pela equipe, sendo que este aumento da intensidade varia da mesma
forma que a taxa de finalização de atividades e a produtividade da equipe.
A variação da intensidade de realização e a respectiva produtividade da equipe
são fatores que casam Ajustes no cronograma, modificando a Data Fim. Essas
modificações são feitas no cronograma acordadas entre a gestão do projeto e seus
participantes. Estes ajustes são tanto maiores quanto maior for a relação entre o
esforço extra necessário para executar as atividades não planejadas inicialmente e
os recursos treinados disponíveis. Os ajustes no cronograma são limitados
também pela tolerância do cliente em aceitar estas modificações. Quanto maior
pressão sobre a equipe de projeto para manter o cronograma de acordo com o
planejado, maior será o número possíveis ajustes no cronograma. Finalmente, os
ajustes no cronograma contribuem no sentido de aumentar o prazo inicial para
acomodar as atividades não planejadas que surgiram no decorrer do projeto. Os
ajustes reduzirão o atraso percebido na medida em que o tempo disponível para
execução das tarefas pendentes é aumentado.
Atraso
Paralelismo
Recursos Humanos
Disponíveis
Duração das
Atividades
Inter-Relação de
Atividades Paralelas
+
+
+
Qualidade (Geração
de Erros)
Cronograma Acordado
(Tempo Disponível)
+
-
+
Pressão para cumprir
o Cronograma
-
Intensidade de
Trabalho
Taxa de Finalização das
atividades (Produtividade)
Tempo estimado
para realização
+
+
-
Data fim
-
+
Trabalho Base
Disponível para
realização
+
-
Figura 39 - Diagrama Causal – Duração, Intensidade de Trabalho.
O estudo dos diagramas causais de forma parcial, proporciona um
entendimento da estrutura de um projeto implementação de ERP, porém quando
PUC-Rio - Certificação Digital Nº 0321251/CA
84
analisamos em conjunto teremos um diagrama aparentemente caótico e confuso,
porém refletindo o entendimento do sistema no processo de criação do modelo,
como apresentado na figura 40.
PUC-Rio - Certificação Digital Nº 0321251/CA
Atraso
Paralelismo
Recursos Humanos
Disponíveis
Trabalho a ser
realizado
Duração das
Atividades
Inter-Relação de Atividades
Paralelas (Restrições de
Precedência)
+
-
+
+
+
+
Trabalho em
Execução
Trabalho
Concluído
Qualidade (Geração
de Erros)
+
Retrabalho não
descoberto
Progresso
Aparente
+
Retrabalho
Conhecido
+
Horas Extras
Cronograma Acordado
(Tempo Disponível)
Qualidade
Percebida
-
-
+
-
-
Pressão para cumprir
o Cronograma
-
Intensidade de
Trabalho
Taxa de Finalização das
atividades (Produtividade)
Tempo estimado
para realização
+
+
+
-
Data fim
-
+
-
Trabalho Base
Disponível para
realização
+
Escopo do Projeto
+
-
Tarefas realizadas
sem Erros
+
Padrão de
Qualidade
Pressão para diminuição
dos Requerimentos do
Projeto
+
-
-
-
Fila de atividades
+
+
Nível de Confiança
(gestor)
-
-
Modificação de Escopo e
Aumento do Trabalho base
acordado
+
+
+
+
Moral da Equipe
-
+
+
-
+
-
+
-
Figura 40 - Diagrama Causal – Execução dos desenvolvimentos na fase de realização de um projeto de Implementação tecnológica (fonte: o
Autor)
PUC-Rio - Certificação Digital Nº 0321251/CA
86
5.3 O Diagrama Formal
Uma vez estabelecido o Diagrama Causal, que mostra como cada fator influência os
demais e por eles é influenciada, a meta seguinte é quantificar estas relações para que se
possa verificar numericamente o comportamento de cada nó do sistema diante de uma
perturbação qualquer.
Nesta seção, focaremos o modelo básico de retrabalho, que será construído passo a
passo, e será explicado o modelo mental por trás de cada elemento acrescentado, bem como
sua tradução matemática no modelo de simulação.
Na transição do Diagrama Causal para o de fluxo, nem sempre são aproveitados todos
os elementos do primeiro. O desenvolvimento do modelo é um processo que em cada
momento vai sendo melhorado na medida em que as relações vão sendo questionadas.
Assim, alguns elementos presentes no causal foram aglutinados no Diagrama de Fluxo.
Outros foram divididos em dois ou mais e também houve aqueles que foram introduzidos
para melhor caracterizar o modelo matemático.
Nesta etapa, bem como na anterior na qual foi construído o Diagrama Causal, foi
utilizado o programa de simulação Vensim PLE32 versão 4.0d. Vale lembrar que será
modelada apenas a produto de desenvolvimento na fase de realização, onde a quantidade de
atividades iniciais é restritiva, porém o efeito do retrabalho é de maior interferência.
A modelagem inicia-se com a representação mais básica possível de como funciona o
processo de desenvolvimento de um projeto. No entanto, por ser a mais simples, esta é a
maneira mais comum de se pensar no fluxo de trabalho no momento de se preparar uma
proposta.
As variáveis de estado, nesta primeira etapa da construção do modelo, são as
quantidades de trabalho programado ou realizado, que são medidos em homem-hora (HH).
A unidade de tempo é dia (d) e a taxa de transformação é medida em homem-hora por dia
(HH/d). Seguindo os parâmetros necessários para definição no software Vensim,
necessitamos da definição do dt (Time Step), ou intervalo da simulação e seu horizonte de
simulação, definido pelo tempo inicial (Initial Time) e Tempo Final (Final Time).
Nessa simulação definimos o Tempo como 200 dias com um intervalo de simulação de
0,25 dia, como podemos verificar na Figura 41.
PUC-Rio - Certificação Digital Nº 0321251/CA
87
Figura 41- Tela de definição inicial do Vensim PLE.
O processo constitui-se de um estoque de trabalho a ser realizado que vai sendo
transformado, através do trabalho em execução, em trabalho concluído. Tanto o primeiro
como o último é variável de estado do sistema, enquanto que o trabalho em execução é a
taxa com que um se transforma no outro.
Figura 42 – Diagrama Formal tradicional
Os retângulos representam as variáveis de estado, os símbolos de válvula representam
as taxas de transformação das variáveis de estado e os demais símbolos são as variáveis
auxiliares, constantes, ou dados de entrada do projeto,
Os recursos humanos disponíveis e a equipe mínima indicam a máxima e a mínima
capacidade de trabalho da equipe para execução das atividades. O variável “Projeto
concluído?" indica o momento em que o trabalho concluído atinge seu nível final igual ao
Trabalho a ser
realizado
Trabalho
concluído
Trabalho em execução
Definição inicial do projeto
Progresso
Recursos humanos
disponíveis
Ajuste
Projeto concluído?
Equipe mínima
PUC-Rio - Certificação Digital Nº 0321251/CA
88
da definição inicial do projeto. Neste momento, o trabalho em execução assume
valor zero e o processo pára.
O variável “Progresso" mostra a porcentagem do trabalho concluído a cada
momento e possui a característica de uma curva em forma de "S", como podemos
ver no Gráfico de Progresso apresentado na Figura 43. Esta curva foi baseada na
curva de evolução da fase de realização para a criação dos desenvolvimentos
durante o planejamento inicial.
Progresso (Curva S)
2
1.5
1
0.5
0
0 20 40 60 80 100 120 140 160 180 200
Time (Day)
Progresso : Current1
Dmnl
Figura 43 – Gráfico de Progresso – Base do Diagrama formal Tradicional
A calibração do formato da curva é feita através da variável "ajuste", que, uma vez
definida, permanecerá inalterada até o modelo final. Durante a fase de preparação da
proposta, numa tentativa de alcançar o melhor prazo previsto para superar a concorrência, é
comum se pecar por um excesso de otimismo. A equipe estima o tempo necessário para
execução das atividades sem considerar interferências internas ou externas, ou seja, apenas
a situação hipotética ideal. Ao final é acrescentada uma contingência que deverá ser a
mínima possível e está baseada mais na percepção do vendedor com relação ao prazo que o
cliente aceitará do que no histórico da ineficiência inerente ao processo.
No caso do projeto, parte das contingências foi consumida durante a fase de
negociação, tornando a situação ainda pior. O trabalho em execução mostra tanto a taxa de
transformação do trabalho como, numa interpretação mais concreta, o tamanho da equipe
necessária para, execução do projeto a cada momento. A capacidade máxima de 400 HH/d
PUC-Rio - Certificação Digital Nº 0321251/CA
89
dos recursos humanos disponíveis equivale a uma equipe de cinqüenta recursos trabalhando
oito horas por Dia. Este era aproximadamente o tamanho da equipe de desenvolvimento de
um projeto, durante a fase de maior intensidade do projeto, a equipe mínima foi
considerada como sendo de 12,5 pessoas trabalhando oito horas, ou seja, 100 HH/d.
A Figura 44 apresenta do gráfico do trabalho em execução, mostrando como varia esta
demanda por mão de obra de desenvolvimento durante o projeto. Normalmente este gráfico
teria, em sua parte central, uma forma parabólica caso não houvesse a limitação de recursos
e tenderia lentamente a zero, não fosse pela imposição de uma equipe mínima.
Trabalho em Execução
400
300
200
100
0
0 20 40 60 80 100 120 140 160 180 200
Time (Day)
Figura 44 -Trabalho em execução ou demanda de recursos de durante o projeto
Com esta carga de trabalho e distribuição de recursos ao longo do projeto, o prazo
estimado para conclusão dos trabalhos seria de 136 dias.
Em um próximo passo, complementamos o modelo com o conceito de retrabalho, no
qual se reconhece o efeito da qualidade. Parte do trabalho concluído é retornada ao estoque
de trabalho a ser executado devido à geração de erros durante o processo de
desenvolvimento do projeto, que exigem retrabalho para corrigi-los. O conceito de
qualidade aparece, portanto, como sendo o trabalho executado corretamente dividido pelo
trabalho executado.
PUC-Rio - Certificação Digital Nº 0321251/CA
90
Na Figura 45, pode-se ver a representação do ciclo de retrabalho. A taxa de retrabalho
é dada pelo trabalho em execução multiplicado pelo complemento da qualidade, ou seja, a
porção de geração de erro.
Trabalho a ser
realizado
Trabalho
concluído
Trabalho em execução
Definição inicial do projeto
Progresso
Capacidade
Normal
Ajuste
Projeto concluído?
Retrabalho
Qualidade
Equipe
mínima
Figura 45-O ciclo de retrabalho
Neste modelo, a qualidade é considerada constante e foi utilizado o valor de 93%.
Este é um valor empírico estimado pela gestão do projeto como sendo a melhor taxa média
de revisões de especificações e desenvolvimentos para realização dos testes do projeto,
quando os níveis de pressão interna e externa são os menores possíveis. Assim, este valor
foi considerado como o valor máximo da qualidade. Ou seja, a taxa de 7% seria o erro
inerente ao processo de desenvolvimento. Em modelos avançados de gestão podemos
elaborar a variação da qualidade em função de fatores endógenos e exógenos.
Neste modelo, devido a existência do retrabalho, a conclusão da execução dos
desenvolvimentos ocorre, como esperado, num prazo maior que no modelo anterior. Agora,
o tempo para execução do projeto passa a ser de 146 dias; dez dias a mais do que na
situação sem a geração de erros, conforme vemos na Figura 46, apresentando o Gráfico do
trabalho em execução.
PUC-Rio - Certificação Digital Nº 0321251/CA
91
Trabalho em Execução
400
300
200
100
0
0 25 50 75 100 125 150 175 200 225 250
Time (Day)
Figura 46 - Gráfico do Trabalho em execução
No estágio seguinte de aprimoramento do modelo, é introduzido o conceito de atraso na
identificação do retrabalho. Ou seja, diferentemente de como foi expresso no modelo
anterior, existe um espaço de tempo entre a geração do erro e a sua identificação. Este é um
conceito importante, pois quanto mais se demora em encontrar um erro de projeto, maior
podem ser as conseqüências por ele geradas em termos da extensão do retrabalho requerido
para corrigi-lo.
Assim, os erros gerados são armazenados sob a forma de retrabalho ainda não
identificado e são transformados em retrabalho conhecido de acordo com a eficácia da
Garantia da Qualidade para a identificação de erros. O atraso utilizado neste modelo é de
primeira ordem, ou seja, o fluxo de saída (eficácia da GQ) é proporcional à variável de
estado (retrabalhos ainda não identificados), tendo como fator de proporcionalidade o
inverso do tempo para detectar erros que é o tempo médio de demora para a identificação
do retrabalho, e que neste caso é de sessenta dias. Na Figura 47 apresentamos o ciclo de
retrabalho considerando a parcela não reconhecida do mesmo.
PUC-Rio - Certificação Digital Nº 0321251/CA
92
Trabalho a ser
realizado
Trabalho
concluído
Trabalho em execução
Definição inicial do projeto
Progresso real
Capacidade
Normal
Ajuste
Projeto
concluído?
Qualidade de
execução do trabalho
Equipe
mínima
Retrabalhos
ainda não
identificados
Retrabalho
conhecido
Geração de erro
Trabalho
executado
Qualidade
percebida do
resultado
Eficácia da GQ
(detecção de erros)
Tempo para
detectar erros
Progresso
aparente
<Retrabalhos ainda
não identificados>
Figura 47- Diagrama Formal do Ciclo considerando o retrabalho não identificado
Como existe uma parcela do trabalho executado que terá que ser refeita, da qual ainda
não se tem conhecimento, o conceito de progresso do trabalho deverá ser mais
especificado. Portanto, haverá o progresso real e o progresso aparente. O primeiro não pode
ser medido durante a execução do projeto, pois incorpora o retrabalho ainda não
identificado como parte do trabalho a ser realizado. Por outro lado, o segundo, que é o
progresso percebido e medido pela equipe de projeto, considera o retrabalho ainda não
identificado como trabalho concluído.
Da mesma maneira, a qualidade de execução do trabalho será diferente daquela
medida reportada pela equipe de projeto, pois a qualidade percebida do resultado não
reconhece o retrabalho ainda não identificado. De acordo com o modelo causal apresentado
no início do capitulo, vemos que as decisões de projetos são baseadas nas percepções da
equipe com relação ao progresso e à qualidade, e não em seus respectivos valores reais,
porém esse fatores não estarão no escopo do modelo formal apresentado.
PUC-Rio - Certificação Digital Nº 0321251/CA
93
Quando este modelo é utilizado para a simulação do projeto, verifica-se que o tempo
requerido para a conclusão dos trabalhos é um pouco menor que no caso anterior. De fato
como vemos no gráfico de trabalho em execução apresentado na Figura 48, o projeto é
considerado concluído depois de 143 dias, em lugar de 146, como anteriormente.
Trabalho em Execução
400
300
200
100
0
0 20 40 60 80 100 120 140 160 180 200
Time (Day)
Figura 48- Gráfico do trabalho em execução com e sem a consideração de retrabalhos não
identificados.
Este resultado ocorre devido ao fato de que quando as realizações dos
desenvolvimentos são consideradas concluídas, ainda existem retrabalhos que a equipe de
projeto não teve tempo de identificar. Estes retrabalhos vão aparecer posteriormente, nas
fases de teste integrado unitários ou integrado do sistema e poderão ter conseqüências
bastante negativas para o progresso. No entanto, o escopo desta modelagem limita-se a
realização dos desenvolvimentos e, portanto medimos o quanto de retrabalho será passado
para as fases posteriores.
A Figura 49 demonstra que no momento em que os desenvolvimentos são considerados
concluídos, ainda restam 1027 HH de retrabalhos não identificados.
PUC-Rio - Certificação Digital Nº 0321251/CA
94
Retrabalhos ainda não identificados
2,000
1,500
1,000
500
0
0 20 40 60 80 100 120 140 160 180 200
Time (Day)
Figura 49- Gráfico do Retrabalho ainda não identificado
Para efeito de comparação dos diversos modelos, poderemos considerar a hipótese de
que este montante de retrabalho no final do projeto, quando a equipe de desenvolvimentos é
a equipe mínima (100 HH/d), seja identificado de uma só vez e durante a sua execução não
sejam gerados mais erros. Assim, seriam necessários aproximadamente mais 10 dias para
concluir o restante dos retrabalhos. O total ajustado seria então de 153 dias.
Podemos verificar na Quadro 2 os resultados da análise realizadas com os três
cenários desenhados pelo modelo formal dos efeitos do retrabalho na implementação do
projeto de ERP.
Quadro 4 - Resultado da simulação com modelos formais descritos
Vimos nesse capítulo a influência do retrabalho e o efeito do retardo da identificação
no retrabalho e na realização dos desenvolvimentos necessários para a implementação de
um projeto de ERP.
Descrição
Prazo para Conclusão do
projeto (dias)
Retrabalho não
identificado (HH)
Tempo
Corrigido (dias)
Proposta Incial
136,3
-
-
Retrabalho
146,5
-
-
Retrabalho não Identificado
143,5
1027
153,8
PUC-Rio - Certificação Digital Nº 0321251/CA
6
CONCLUSÕES
Neste trabalho tivemos como objetivo principal, a apresentação da técnica
de Dinâmica de Sistemas como ferramenta de suporte para a gerência de um
projeto de ERP, apoiando o planejamento de atividades e trabalho com a
compreensão das situações ambientais, bem como das estruturas que afetam a
execução de um projeto de tecnologia.
As conclusões deste trabalho são direcionadas para questões de
aprendizagem e compreensão da gestão do projeto e os principais efeitos que
interferem no sucesso de um projeto. Para isso foi apresentado uma ferramenta de
apoio à gestão, que possibilita a criação de simulação computacional de forma
simples, capaz de inter-relacionar fatores que com as técnicas tradicionais não são
possíveis de analisar. Através do sistema modelado, foi possível mostrar uma
visão sistêmica mais próxima do real, proporcionando na construção, um elevado
grau de conhecimento aos seus modeladores sobre os problemas que envolvem a
implementação de um projeto de tecnologia de grande porte.
Fatores como causalidade mostram quais fatores causam os atrasos e como
estes fatores são responsáveis pelo resultado negativo do projeto e a possibilidade
de quantificação, mostrando também os fatores que causaram uma parcela
específica do resultado negativo.
A modelagem utilizando a dinâmica dos sistemas como proposta neste
trabalho cobriu os três itens. Definição do escopo do problema na implementação
de ERP, identificação dos fatores relevantes que afetam o sistema e como eles se
inter-relacionam, tendo como produto final o Diagrama Causal que serviu de base
para o terceiro item com a construção do modelo formal simplificado.
A utilização de Dinâmica de Sistema para o planejamento e preparação de
um projeto de implementação de ERP, permite superar a visão fragmentada da
dinâmica de um projeto seguida na gestão tradicional do projeto, onde os
PUC-Rio - Certificação Digital Nº 0321251/CA
96
principais fatores de influencia são baseado em uma idéia estática de projeto, sem
influência humana.
Nesse trabalho foi apresentada a técnica de Dinâmica de Sistema
apresentado por Jay W. Forrester, com a aplicação em gestão de projeto de
implementação de ERP. Para isso foram detalhados os passos da construção de
um modelo, a partir de um estágio básico, mostrando o modo como o projeto no
planejamento inicial e na elaboração da proposta. Por falta de informações
detalhadas sobre a dinâmica do projeto visto como um sistema, já que cada
projeto nesta área de negócios é único, o planejamento inicial utiliza
tradicionalmente um modelo mental mais simples. Sobre a sua estimativa, é
acrescentada uma contingência.
Desta maneira, foi criado o modelo neutro, ou seja, aquele que simula o
projeto sem nenhum efeito adicional. Se compararmos os resultados desta
simulação com os do modelo básico utilizado na proposta, vemos que o erro de
previsão não é muito grande, quando comparado com as estimativas iniciais,
sendo certamente coberto pela contingência considerada.
Como objetivo específico a realização desta modelagem foi de suma
importância para a compreensão do problema pela equipe envolvida neste projeto.
Talvez o ponto principal tenha sido compreender o papel do ciclo de retrabalho, e
realizar que há situações em que decisões que à primeira vista contribuem para a
redução do prazo, além de ter um custo alto, produzirão retrabalhos que só serão
identificados mais adiante. Ao final, estas ações aparentemente benéficas, poderão
prejudicar ainda mais o resultado do projeto.
Outra grande vantagem da utilização das ferramentas da Dinâmica dos
Sistemas na criação de modelos da evolução de projetos é a possibilidade de se
considerar fatores intangíveis como o moral da equipe de projeto e a pressão para
cumprimento do cronograma. Estes fatores não são considerados quando se
utilizam técnicas tradicionais como PERT (Program Evaluation and Review
Techinique – Técnica de Análise e Avaliação de Programas) e CPM (Critical Path
Method – Método do Caminho Crítico).
Outra diferença da Dinâmica dos Sistemas em relação aos métodos
tradicionais é a possibilidade de se modelar decisões. No modelo aqui apresentado
foi possível simular as ações do gerente do projeto frente ao nível de pressão para
PUC-Rio - Certificação Digital Nº 0321251/CA
97
cumprimento do cronograma. Ele poderia decidir por liberar as horas extras,
aumentar o paralelismo, reduzir o nível de exigência da qualidade, negociar prazo,
ou tudo isso junto. Isto é possível graças ao enfoque dinâmico e amplo da
Dinâmica dos Sistemas. Ela enxerga os processos e as relações entre os fatores
que de alguma maneira os modificam enquanto que um estudo através de PERT e
CPM analisa as atividades individualmente e suas relações de dependência com as
demais.
De certa maneira, estes métodos são complementares, uma vez que possuem
enfoques diferentes. A Dinâmica dos Sistemas, por ter uma abordagem holística, é
mais indicada para aplicações gerenciais, enquanto a visão mais específica e
detalhada do PERT e CPM adequam-se melhor como apoio para decisões mais
operacionais.
Para futuros trabalhos sugere-se a continuação da modelagem, que neste
caso compreendeu os produtos de desenvolvimento dentro da fase de realização
de um projeto de implementação de ERP, estendendo-a para as inter-relações com
outros produtos e fases, inserindo no modelo formal as inter-relações endógenas e
exógenas para diversos elementos listados. Os elementos e a dinâmica entre eles
seriam bastante semelhantes aos descritos neste trabalho, com a diferença que a
fase seguinte seria influenciada também pelo retrabalho não identificado nas
etapas anteriores. Tais retrabalhos são então reconhecidos e afetarão o trabalho já
realizado e considerado concluído daquela fase.
Podemos também realizar a utilização de modelos tradicionais de gestão
(PERT/ CPM) em conjunto com as técnicas de Dinâmica de Sistemas, de forma a
analisar o caminho crítico de um projeto definido em conjunto com os fatores de
influência em cada produto ou atividade do caminho de forma a analisar a
sensibilidade do atraso e suas influências em cada segmento do projeto, criando
dessa forma um micro-mundo do projeto.
A Dinâmica dos Sistemas vem expandindo seu leque de aplicações por
diversas áreas do conhecimento humano. Este trabalho mostrou que esta disciplina
pode ser utilizada como uma ferramenta que fornece subsídios para um
planejamento e acompanhamento de projeto de forma estruturada e com maior
discernimento das resultantes do projeto e suas origens. Esta é uma abordagem
pouco conhecida que ainda pode ser bastante
PUC-Rio - Certificação Digital Nº 0321251/CA
7
REFERÊNCIAS BIBLIOGRÁFICAS
BANCROFT, N., SEIP, H. AND SPRENGEL, A. (1996). Implementing SAP R/3 –
How to Introduce a Large System. 2º edição, Manning Publications Co., EUA.
BASTOS, A. A. P. (2003) A dinâmica de sistemas e a compreensão de
estruturas de negócios. Dissertação de mestrado. USP, FEA, SP.
BATISTA FILHO, J. (2001) Simulação Dinâmica de modelos Operacionais com
enfoque aplicado a Engenharia de Projetos. Dissertação de Mestrado. UFSC,
SC.
BEARINGPOINT (2004) – Metodologia de Gestão de Projeto de ERP,
Bearingpoint, SP.
BERTALANFFY, L. V. (1975) Teoria Geral dos Sistemas, 2ª, Editora Vozes,
Petrópolis, RJ.
CHAPMAN, R (1998) The role of system dynamics in understanding the
impact of changes to key project personnel on design production within
construction projects International Journal of Project Management Vol 16, Julho,
pg 235- 247
CHECCHINATO, D (2002) Modelagem de Problemas Logísticos sob o enfoque
de Sistemas Dinâmicos: O caso do jogo da Cerveja. Dissertação de Mestrado.
UFSC, SC.
COOPER, K (1993) The Rework Cycle: Vital insights into Managing Projects
IEEE Engineering Management Review Vol 16, Edição Outono, pg 4-12
COOPER, K (1994) The $2,000 Hour: How Managers Influence Project
Performance Through the Rework Cycle Project Management Journal Vol. 25,
Março pp. 11-24
CURRAM T., KELLER G. (2004), SAP R/3 business blueprint: understanding
the business process reference model, Prentice Hall , NJ
ENGER, E.R. (2004) Quantificação da interferência do Cliente em Projetos de
Grande Porte – Um método utilizando Dinâmica dos Sistemas. Dissertação de
Mestrado, FGV, SP.
ESTEVES J., PASTOR J. 1999. "Enterprise Resource Planning Systems
Research: An Annotated Bibliography", Business Process Management Journal,
Vol. 7, article 8 pg195-204.
PUC-Rio - Certificação Digital Nº 0321251/CA
99
FERNANDES, A.C. (2003) Scorecard Dinâmico – Em direção à Intergração
dinâmica de sistemas com o Balanced Scorecard. COPPE, UFRJ, RJ.
FORD D. N. (1995) The Dynamics of Project Mangement: An Investigation of
Project Process and Coordination on Performance, Tese de Doutorado, MIT
FORD, D., STERMAN J.D. (1999) Overcoming the 90% Syndrome: Iteration
Management in Concurrent Development Projects, MIT Sloan Scholl of
Management.
FORRESTER, J. W. (1961) Industrial Dynamics. MIT Press. Cambridge. MA.
FORRESTER, J. W. (1971) World Dynamics. MIT Press. Cambridge. MA.
FORRESTER, J. W. (1976) Principles of Systems. 2a, Wright Allen Press.
Cambridge. MA.
GOODMAN, M.R. (1989) Study Notes in System Dynamics. Toolbox Reprint
Series, Pegasus Communications, Inc., 2000.
GORDON G. (1969) System Simulation. 1a, Prentice-Hall, Nova Jersey
HPS (2001) Manual do Software Ithink Disponível em: http://www.hps-
inc.com/community/downloads/tutorials/iThink.aspx Acessado em: 01/05/2004.
KIM, D. (1998) Introduction to System Thinking. Toolbox Reprint Series,
Pegasus Communications, Inc.
KIRKWOOD, C. W. (1998) System Dynamics Methods: A Quick Introduction
www.public.asu.edu/~kirkwood/sysdyn/SDIntro/SDIntro.htm Acessado em
01/05/2004
MAANI K. E CAVANA, R.Y. (2000) System Dynamic and Modeling:
Understanding Change and Complexity. Pearson Education, Nova Zelândia.
MEADOWS, D.H. MEADOWS D.L. RANDERS J., BEHRENSW.W III. (1972) The
Limits to Growth: A report for the Club of Romeo’s Project on the
predicament of mankind. 2a, Universe Books, Nova York.
MOHAPATRA P.K.J. MANDAL, P. E.,BORA M.C. (1994) Introdução a
Modelagem de Dinâmica de Sistemas, Depto de Engenharia Industrial e
Gerenciamento, Instituto de Tecnologia da Índia, Índia
NORRIS G., HURLEY, J. (2001) E-Business e ERP – Transformando as
Organizações , Quallitymark , RJ
POWERSIM (2001) Manual do Software Powersim Disponível em:
http://www.powersim.com/download/demo.asp Acessado em: 01/05/2004.
PUC-Rio - Certificação Digital Nº 0321251/CA
100
Principia Cybernetic technology (2005), Disponível em:
http://pespmc1.vub.ac.be/ Acessado em: 15/05/2005
PMBOK Guide - A guide to the Project Management Body of Knowledge. 3º
Edição (2004) – Project Management Institute. Disponível em: www.pmi.org
Acessado em: 15/05/2005
RADZICKI, M.J. (1997)
Introduction to System Dynamic: A system approach to
understanding Complex Policy Issues (Versão 1.0), US Department of Energy,
Disponível em: http://www.systemdynamics.org/DL-IntroSysDyn Acessado em:
01/05/2004
RIBEIRO, L.M.F.(2002) Dinâmica de Sistemas: Uma ferramenta de
experimentação e aprendizado organizacional. UNIFEI, ITAJUBÁ, MG.
RICHMOND, B.(2000) The 'Thinking' in System Thinking: Seven Essential
Skills, Toolbox Reprint Series, Pegasus Communications, Inc.
RODRIGUES, A. AND BOWERS J. (1996) The role of system dynamics in
projects management. International Journal of Project Management, Vol 14,
Julho, pg 213-220.
RODRIGUES, A., WILLIAMS, T (1996). System Dynamics in Project
Management: & Assessing the Impacts of Client Behavior on Project
Performance, Research Paper No. 1996/6, Strathcycle Business School
SBDS (2005) Sociedade Brasileira de Dinâmica de Sistemas. Disponível em:
http://www.espm.br/sbds/index.htm Acessado em 15/05/2005
SDEP (2005) Road Maps. Disponível em: http://sysdyn.clexchange.org/ Acessado
em 15/05/2005
SENGE P., (2003) A quinta disciplina: Arte e Prática da Organização que
aprende, Editora Best Seller, SP
STERMAN, J.D., (2000) Business dynamics -Systems Thinking and Modeling
for a Complex World, 2a, McGraw Hill
UMBLE, E.J., HAFT, R.R., UMBLE, M.M. (2003) Enterprise resource planning:
Implementation procedures and critical success factors, European Journal or
Operational Research Vol146, Abril, pg 241-257
VASCONCELOS M., (2003) Pensamento Sistêmico, Um novo Paradigma da
Ciência, 2ª. PUCMinas, MG
VILLELA, P.R. (2002) Curso de Dinâmica de Sistemas, Universidade Federal de
Juiz de Fora. MG
PUC-Rio - Certificação Digital Nº 0321251/CA
101
WALLACE T.H., KREMZAR M.H. (2001) ERP: Making it happen – The
implementers Guide to Success whit Enterprise Resource Planning, John
Willey & Son, Nova York
WEBSTER JUNIOR F.M. (2002), PM 102 According to the Olde Curmudgeon –
A introduction to the basic concepts of modern project management , Project
Management Institute
WIENER, N (1948) Cybernetics or control and communication in the animal
and the machine, John Wiley & Son Inc, Nova York
WILLIAMS, Y., EDEN, C., ACKERMANN, F. AND TAIT A. (1995) The vicious
circles of parallelism. International Journal of Project Management ,Vol 5,Maio,
pg 151-155 C
PUC-Rio - Certificação Digital Nº 0321251/CA
102
8
ANEXOS
Fonte: Bearingpoint Consulting (2004)
Funcional
Desenvolvimentos
Tecnologia
GDM
Atividade Externa
Configuração
Especificação
Funcional
Desenvol-
vimento
Homologação
Teste
Unitário
BPP’s
Documentação
Configuração
Funções
Proc / Org
Infra BasicaInfra-SAP
Ferramentas
De Projeto
Ambiente de
Qualidade
Ambiente de
Treinamento
Ambiente de
Produção
Perfis de
Autorização
Treinamento
1 (Piloto)
Material
Didático
Catalogo de
Cursos
Mapeamento
1 e 2
Impactos
Org.
Migração
Ciclo 1
Teste
Integrado
Grade
Trein. 1 e 2
Go-live
1
Capacitação
Multiplicadores
Associação de
Usuários a
Perfil
Preparação
Centros de
Treinamento
Teste de
Campo -Simulado
Teste de
Desempenho
Teste de
Cutover
Estrutura de
Suporte
CutOver
Treinamento
2
Associação de
Usuários a
Perfil
CutOver
Go-live
2
Implementação
Encadeamento
Migração
Ciclo 2
Migração
Revisão
Migração
Teste
Piloto + UE
Ambiente de
Teste Migração
TesteTécnico
Realização
Preparação
para Partida
R: 42% P:57%
Fev 11 Maio 31
R: 0 % P: 0%
Abril 06 Junho 03
R: 0% P:0%
Abril 08 Junho 07
R: 0% P:0%
Abril 13 Julho 8
R: 0% P: 0%
Abril 11 Junho 17
R: 0% P:0%
Junho 8 Julho 29
R: 0% P:0%
Julho 8 Set 30
R: 0% P:10%
Julho30 Out 31
R: 0% P:0%
Ago 01 Out 31
R: 97 % P:100%
Fev 1 Mar 24
R: 45% P:%
Fev 22 Maio 2
R: 2% P:14%
Mar 18 Junho 07
R: 0% P:0%
Ago 4 Set 9
R: 11% P:22%
Mar 17 Junho 8
R: 10% P:12%
Mar 4 Jun 14
R: 0% P:0%
Maio 16 Jun 30
R: 0% P0:%
R: 1% P:4%
Mar 29 Aug 31
R: % P:%
R: 0% P: 0%
Set 09 Out 31
R: 0% P:0%
R: 0% P:0%
Dez 28 Jan 31
R: 0 % P: 0%
Nov 01 Jan 31
R: 0% P: 0%
R: 0% P:%
R: 0% P:0%
R: 0% P: 0%
R: 0% P:0%
Abril 25 julho 28
R: 0% P: 0%
Out 03 Out 31
R: 35% P:45%
Feb 04 Maio 13
R: 44% P:57%
Feb 02 Maio 15
R: 0% P:0%
Nov 01
Fev 01
R: 0% P:0%
Maio 3 Julho 29
Teste de
Campo -Itaguaí
Teste de
Desempenho
Estrutura de
Suporte
R:0 % P:0%
R: 0% P: 0%
R: 0% P:0%
Maio 16 Junho 21
Preparação
para Partida
R: 0% P:0%
Planos de
Cutover
R: 0% P: 0%
Migração
Teste
Varejo
R: 0% P:0%
Ago 4 Dez 12
Plano
de Teste
R: 0% P:0%
Maio 02 Maio 20
Workflow
Julho 01 Agosto 31
Planos de
Cutover
R: 0% P: 0%
Especificação
Técnica
*
*
*
Participação de outro time
Inicio de desvio significativo
Alto desvio na atividade
Caminho Crítico Atual
Desvio maior de 25% e menor de 40%
Desvio maior de 40%
R: 12% P:46%
Feb 16 Maio 25
R: 35% P:58%
Fev 14 Maio 15
R: 45% P:55%
Fev 16 Maio 31
R: 58% P:74%
Fev 16 Maio 31
R: 6% P:35%
Fev 25 Maio 31
R: 3% P:21%
Fev 23 Maio 31
R: 8% P:72%
Fev 15 Maio 25
R: 2% P:42%
Fev 18 Maio 31
R: 0 % P:28%
Mar 14 Maio 25
R: 25% P:69%
Fev 14 Maio 20
Nov 1 – Dez 31
Funcional
Desenvolvimentos
Tecnologia
GDM
Atividade Externa
Configuração
Especificação
Funcional
Desenvol-
vimento
Homologação
Teste
Unitário
BPP’s
Documentação
Configuração
Funções
Proc / Org
Infra BasicaInfra-SAP
Ferramentas
De Projeto
Ambiente de
Qualidade
Ambiente de
Treinamento
Ambiente de
Produção
Perfis de
Autorização
Treinamento
1 (Piloto)
Material
Didático
Catalogo de
Cursos
Mapeamento
1 e 2
Impactos
Org.
Migração
Ciclo 1
Teste
Integrado
Grade
Trein. 1 e 2
Go-live
1
Capacitação
Multiplicadores
Associação de
Usuários a
Perfil
Preparação
Centros de
Treinamento
Teste de
Campo -Simulado
Teste de
Desempenho
Teste de
Cutover
Estrutura de
Suporte
CutOver
Treinamento
2
Associação de
Usuários a
Perfil
CutOver
Go-live
2
Implementação
Encadeamento
Migração
Ciclo 2
Migração
Revisão
Migração
Teste
Piloto + UE
Ambiente de
Teste Migração
TesteTécnico
Realização
Preparação
para Partida
R: 42% P:57%
Fev 11 Maio 31
R: 0 % P: 0%
Abril 06 Junho 03
R: 0% P:0%
Abril 08 Junho 07
R: 0% P:0%
Abril 13 Julho 8
R: 0% P: 0%
Abril 11 Junho 17
R: 0% P:0%
Junho 8 Julho 29
R: 0% P:0%
Julho 8 Set 30
R: 0% P:10%
Julho30 Out 31
R: 0% P:0%
Ago 01 Out 31
R: 97 % P:100%
Fev 1 Mar 24
R: 45% P:%
Fev 22 Maio 2
R: 2% P:14%
Mar 18 Junho 07
R: 0% P:0%
Ago 4 Set 9
R: 11% P:22%
Mar 17 Junho 8
R: 10% P:12%
Mar 4 Jun 14
R: 0% P:0%
Maio 16 Jun 30
R: 0% P0:%
R: 1% P:4%
Mar 29 Aug 31
R: % P:%
R: 0% P: 0%
Set 09 Out 31
R: 0% P:0%
R: 0% P:0%
Dez 28 Jan 31
R: 0 % P: 0%
Nov 01 Jan 31
R: 0% P: 0%
R: 0% P:%
R: 0% P:0%
R: 0% P: 0%
R: 0% P:0%
Abril 25 julho 28
R: 0% P: 0%
Out 03 Out 31
R: 35% P:45%
Feb 04 Maio 13
R: 44% P:57%
Feb 02 Maio 15
R: 0% P:0%
Nov 01
Fev 01
R: 0% P:0%
Maio 3 Julho 29
Teste de
Campo -Itaguaí
Teste de
Desempenho
Estrutura de
Suporte
R:0 % P:0%
R: 0% P: 0%
R: 0% P:0%
Maio 16 Junho 21
Preparação
para Partida
R: 0% P:0%
Planos de
Cutover
R: 0% P: 0%
Migração
Teste
Varejo
R: 0% P:0%
Ago 4 Dez 12
Plano
de Teste
R: 0% P:0%
Maio 02 Maio 20
Workflow
Julho 01 Agosto 31
Planos de
Cutover
R: 0% P: 0%
Especificação
Técnica
*
*
*
Participação de outro time
Inicio de desvio significativo
Alto desvio na atividade
Caminho Crítico Atual
Desvio maior de 25% e menor de 40%
Desvio maior de 40%
R: 12% P:46%
Feb 16 Maio 25
R: 35% P:58%
Fev 14 Maio 15
R: 45% P:55%
Fev 16 Maio 31
R: 58% P:74%
Fev 16 Maio 31
R: 6% P:35%
Fev 25 Maio 31
R: 3% P:21%
Fev 23 Maio 31
R: 8% P:72%
Fev 15 Maio 25
R: 2% P:42%
Fev 18 Maio 31
R: 0 % P:28%
Mar 14 Maio 25
R: 25% P:69%
Fev 14 Maio 20
Nov 1 – Dez 31
F u n c i o n a l
D e s e n v o lv i m e n t o s
T e c n o l o g i a
G D M
A t iv i d a d e E x t e r n a
P a r ti c i p a ç ã o d e o u t r o t im e
I n i c i o d e d e s v i o s i g n i fic a t i v o
A l t o d e s v i o n a a t iv i d a d e
C a m i n h o C r í t ic o A t u a l
D e s v i o m a i o r d e 2 5 % e m e n o r
d e 4 0 %
D e s v i o m a i o r d e 4 0 %
C o n f i g u r a ç ã o
E s p e c i f i c a ç ã o
F u n c i o n a l
D e s e n v o l -
v i m e n t o
H o m o l o g a ç ã o
T e s t e
U n i t á r i o
A m b i e n t e d e
Q u a l id a d e
A m b i e n t e d e
P r o d u ç ã o
T e s t e
I n t e g r a d o
G o - l i v e
E n c a d e a m e n t o
A m b i e n t e d e
T e s t e M i g r a ç ã o
R e a l iz a ç ã o
R : 0 % P : 0 %
A b r i l 0 6 J u n h o 0 3
R : 0 % P : 0 %
A b r il 0 8 J u n h o 0 7
R : 0 % P : 0 %
A b r i l 1 3 J u l h o 8
R : 0 % P : 0 %
J u n h o 8 J u l h o 2 9
N o v 0 1
E s p e c i f i c a ç ã o
T é c n i c a
*
R : 3 5 % P : 5 8 %
F e v 1 4 M a i o 1 5
R : 5 8 % P : 7 4 %
F e v 1 6 M a i o 3 1
R : 6 % P : 3 5 %
F e v 2 5 M a i o 3 1
R : 8 % P : 7 2 %
F e v 1 5 M a i o 2 5
R : 2 % P : 4 2 %
F e v 1 8 M a i o 3 1
R : 0 % P : 2 8 %
M a r 1 4 M a i o 2 5
R : 2 5 % P : 6 9 %
F e v 1 4 M a i o 2 0
F u n c i o n a l
D e s e n v o lv i m e n t o s
T e c n o l o g i a
G D M
A t iv i d a d e E x t e r n a
P a r ti c i p a ç ã o d e o u t r o t im e
I n i c i o d e d e s v i o s i g n i fic a t i v o
A l t o d e s v i o n a a t iv i d a d e
C a m i n h o C r í t ic o A t u a l
D e s v i o m a i o r d e 2 5 % e m e n o r
d e 4 0 %
D e s v i o m a i o r d e 4 0 %
C o n f i g u r a ç ã o
E s p e c i f i c a ç ã o
F u n c i o n a l
D e s e n v o l -
v i m e n t o
H o m o l o g a ç ã o
T e s t e
U n i t á r i o
A m b i e n t e d e
Q u a l id a d e
A m b i e n t e d e
P r o d u ç ã o
T e s t e
I n t e g r a d o
G o - l i v e
E n c a d e a m e n t o
A m b i e n t e d e
T e s t e M i g r a ç ã o
R e a l iz a ç ã o
R : 0 % P : 0 %
A b r i l 0 6 J u n h o 0 3
R : 0 % P : 0 %
A b r il 0 8 J u n h o 0 7
R : 0 % P : 0 %
A b r i l 1 3 J u l h o 8
R : 0 % P : 0 %
J u n h o 8 J u l h o 2 9
N o v 0 1
E s p e c i f i c a ç ã o
T é c n i c a
*
R : 3 5 % P : 5 8 %
F e v 1 4 M a i o 1 5
R : 5 8 % P : 7 4 %
F e v 1 6 M a i o 3 1
R : 6 % P : 3 5 %
F e v 2 5 M a i o 3 1
R : 8 % P : 7 2 %
F e v 1 5 M a i o 2 5
R : 2 % P : 4 2 %
F e v 1 8 M a i o 3 1
R : 0 % P : 2 8 %
M a r 1 4 M a i o 2 5
R : 2 5 % P : 6 9 %
F e v 1 4 M a i o 2 0
PUC-Rio - Certificação Digital Nº 0321251/CA
103
Adversários Acidentais
Os Adversários Acidentais estruturam é
um composto de três laços de reforço e
dois Laços de balanço. Temos o
crescimento de sistema como um todo
dirigido por um Laço de reforço global.
Dois Laços de reforços locais criam um
Laço de balanceamento limitando o
crescimento do geral do sistema
Laço de Balanço
O Laço de balanço busca modificar o
estado atual para um estado desejado ou
de referencia
A estrutura pode começar com o estado
atual maior ou menor que o estado
desejado, seja qual for o caso, o estado
atual pode chegar o estado desejado.
Acumulando Metas
A estrutura Acumulando Metas é
composta por dois Laços de
balanceamento que interagem de tal
modo que a atividade de um Laço é
contraria ao equilíbrio planejado pelo
outro Laço
Escalação
A estrutura Escalação é composta de
dois Laços de balanço os quais
interagem de forma a criar um único
Laço de reforço
Conserto de Falhas
A estrutura Conserto de Falhas
consistem em um Laço de
balanceamento e um Laço de reforço.
Estes dois Laços interagem de tal modo
PUC-Rio - Certificação Digital Nº 0321251/CA
104
que o resultado desejado produzido
inicialmente pela volta de balanceamento
é, após pouco tempo compensado pelas
ações do Laço de reforço
Crescimento e Decrescimento
A estrutura de Crescimento e
Decrescimento é simplesmente uma
elaboração da Estrutura Limites para o
Sucesso onde a lenta ação é parte de
outro Laço de balanço com um padrão
externo e com algum atraso.
Limites para o Sucesso
A estrutura Limites para o Sucesso
consiste em um Laço de Reforço,
crescimento o qual, após pouco
aumento, seja compensado por uma
ação de um Laço de balanço.
Laço de Reforço
A estrutura de Laço de Reforço é aquela
que a existe uma realimentação
produzindo um crescimento ou
decrescimento
O Laço de reforço é uma estrutura que
se realimenta produzindo um
crescimento ou decrescimento.
Troca de Problema
A estrutura Troca de Problema é
composta de dois Laços de balanço e um
Laço de reforço. Essa é uma complicada
estrutura pois os dois Laço balanço
agem como um único Laço de reforço,
modificando a situação para a mesma
situação de um Laço de reforço.
Ambas as estruturas finalizam movendo
o sistema em uma outra direção ao invés
da desejada
PUC-Rio - Certificação Digital Nº 0321251/CA
105
Sucesso para os Prósperos
A estrutura Sucesso para os Prósperos
consiste de dois Laços de reforços o qual
age junto com um Laço de reforço
simples.
Tragédia dos Comuns
A tragédia dos Comuns é uma estrutura
que representa a situação em que duas
ou mais estruturas de reforço são
contingentes em algum um recurso
limitado comum.
PUC-Rio - Certificação Digital Nº 0321251/CA
106
Formulas e Equações do modelo
(01) Ajuste= 0.25
Units: Dmnl
(02) Capacidade Normal= 400
Units: HH/Dia
(03) Definição inicial do projeto= 40000
Units: HH
(04) "Eficácia da GQ (detecção de erros)"= "Projeto
concluído?"*Retrabalhos ainda não identificados/ Tempo para detectar erros
Units: HH/Dia
(05) Equipe mínima= 100
Units: HH/Month
(06) FINAL TIME = 200
Units: Dia
The final time for the simulation.
(07) Geração de erro= Trabalho em execução*(1-Qualidade de
execução do trabalho)
Units: HH/DIA
(08) INITIAL TIME = 0
Units: Dia
The initial time for the simulation.
(09) Progresso aparente= Trabalho executado/(Trabalho a ser
realizado+Trabalho executado)
Units: Dmnl
(10) Progresso real= (Trabalho concluído-Retrabalhos ainda não
identificados)/(Retrabalhos ainda não identificados +Trabalho a ser
realizado+Trabalho concluído)
Units: Dmnl
PUC-Rio - Certificação Digital Nº 0321251/CA
107
(11) "Projeto concluído?"= IF THEN ELSE(Trabalho
concluído<Definição inicial do projeto, 1, 0)
Units: Dmnl
(12) Qualidade de execução do trabalho= 0.93
Units: Dmnl
(13) Qualidade percebida do resultado= 1-(Retrabalho
conhecido/Trabalho executado)
Units: Dmnl
(14) Retrabalho conhecido=INTEG (“Eficácia da GQ (detecção de
erros)", 0)
Units: HH
(15) Retrabalhos ainda não identificados= INTEG (Geração de erro-
"Eficácia da GQ (detecção de erros)", 0)
Units: HH
(16) SAVEPER = TIME STEP
Units: Dia
The frequency with which output is stored.
(17) Tempo para detectar erros= 60
Units: DIA
(18) TIME STEP = 0.25
Units: Dia
The time step for the simulation.
(19) Trabalho a ser realizado= INTEG ( -Trabalho em
execução+"Eficácia da GQ (detecção de erros)", Definição inicial do projeto)
Units: HH
(20) Trabalho concluído= INTEG (Trabalho em execução-"Eficácia da
GQ (detecção de erros)",1)
Units: HH
PUC-Rio - Certificação Digital Nº 0321251/CA
108
(21) Trabalho em execução= "Projeto concluído?"*IF THEN
ELSE(Equipe mínima+Capacidade Normal*Trabalho a ser realizado*Trabalho
concluído/(Trabalho a ser realizado +Trabalho concluído)^2/Ajuste<=Capacidade
Normal, IF THEN ELSE(Equipe mínima+Capacidade Normal *Trabalho a ser
realizado*Trabalho concluído/(Trabalho a ser realizado+Trabalho
concluído)^2/Ajuste >=Equipe mínima, Equipe mínima+Capacidade Normal
*Trabalho a ser realizado*Trabalho concluído/(Trabalho a ser
realizado+Trabalho concluído )^2/Ajuste , Equipe mínima), Capacidade Normal)
Units: HH/DIA
(22) Trabalho executado= INTEG (Trabalho em execução, 1)
Units: HH
PUC-Rio - Certificação Digital Nº 0321251/CA
