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

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

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.

Para meus pais, que me suportaram.

Para Mirela, que sempre me acompanhou. Para meus amigos, que me estimularam.

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.

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.

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.

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

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

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

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

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

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.

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.

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

16

técnica de modelagem de interesse para sistemas onde os elementos são intangíveis e

complexos.

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.

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 à

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

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;

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

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

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

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

Possib

ilidade

de

Mudança

s D

ura

doura

s

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.

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.

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”

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).

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

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)

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.

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.

TAXATAXATAXATAXA

FluxoFluxoFluxoFluxo

TAXATAXATAXATAXA

FluxoFluxoFluxoFluxo

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

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.

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/Scheduler•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/Scheduler•SIMRUNNER @ProModel ($4K)

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.

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.

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.

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.

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:

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

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.

Planta1

Planta2

Planta3

Planta4

Mês 0 15

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

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 re p a ra ç ã o D e s e n h o d a S o lu ç ã o R e a liz a ç ã o P re p a ra ç ã 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 ro je to , In f ra -e s tru tu ra e G e s tã o

G e s tã o d o P ro je to e T re 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 T re 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 la n e ja m e n to d a P a r tid a d o S is te m a

P re 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 re in a m e n to d o U s u á r io F in a l

E s tru tu ra ç ã 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 ro 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 irm a ç ã o In ic ia l

P re p e C o o rd 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 rfa c e s e

R e la tó r io s )

A u to r iz a ç õ e s e s ta b e le c id a s

T e s te In te g ra 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 te r ia 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 in g

D e s e n v o lv im e n to d o s A m b ie n te 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 te m a

P ro c e s s o d e P a r tid a d o S is te m a

F in a liza ç ã o d o P ro je to

S u p o r te a S is te m a P ro d u t iv 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 l ic a ç ã o

T e c n o lo g ia

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

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;

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.

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.

SponsorPatrocinador Principal

SponsorPatrocinador Principal

Comitê Executivo do Projeto

Lider do Projeto

Equipe Funcional Equipe Desenvolvimento Equipe de Tecnologia Equipe de Gestão de Mudança

Equipe PMO

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.

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 ProjetoAtividades: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 ProjetoAtividades: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

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 •

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

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

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 dasatividades 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

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ãoconsolidados

Falta de Consolidação doSistema

Cronograma Apertado

Inter-relação dasatividades 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.

55

AtrasoInter-relação das

atividades paraleas+

Trabalho adicional a serrealizado

Retrabalho

Recursos Treinadosdisponí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ãoconsolidados

Consolidação do Sistema

Cronograma ApertadoRetrabalho

+

-+

++

Atraso

Inter-relação dasatividades paraleas

+

Trabalho ser realizado

Recursos Treinadosdisponí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.

56

Pressão de Cronograma

Tempo estimado paraFinalização

+

Trabalho restante

+

-

+

Taxa de Finalização dasatividades

Quantidade de Trabalho

Trabalho Semana

Tempo Disponível

Equipe

Intensidade deTrabalho

+

+++

+

+

+

-

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.

57

Pressão de Cronograma +

-Data FimPrazo paraData Fim

Intensidade deTrabalho

-

-

(B)

Intensidade deTrabalho

+

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 deCronograma

+

TrabalhoRestante

Atividadesfinalizadassem erros

Atividadescom Errosconhecidos

+

+

(B)Taxa de

finalizaçãopercebida

+

Atividadescom Erros não

conhecidos

Taxa de

Criação deErro

+

+

+

++

(R)

(R)

Figura 21 - Estrutura de Retrabalho

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.

59

Taxa de tarefas aserem realizadas

Taxa derealização do

Trabalho Base

Trabalho Base

disponível pararealização

Trabalho Basenão realizado

+

(B)Restrições dePrecedência

-

Trabalho BaseRealizado

Escopo doProjeto

(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

60

atingir o padrão definido, influenciando assim as decisões de retrabalho de

atividades, conforme Figura 23.

-

(R)

Padrão deQualidade

Qualidade doTrabalho

Tarefasfinalizadassem Erros

Qualidade do

Produto

Defasagem deQualidade

Trabalhorestante

Pressão paradiminuiçã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.

61

Taxa definalização de

atividades

TrabalhoRestante

Pressão para diminuiçãodos requerimentos do

Projeto

Escopo doProjeto

Fila deAtividades

Porcentagem doEscopo 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 paraFinalização

+

Trabalho restante

+

-

+

Taxa de Finalização dasatividades

Quantidade de Trabalho

Trabalho Semana

Tempo Disponível

Equipe

Intensidade deTrabalho

+

+++

+

+

+

-

Ciclo de Balanço(B)

(B)

(B)

Estrutura de Trabalho

Pressão de Cronograma +

-Data FimPrazo para

Data FimIntensidade de

Trabalho

-

-

(B)

Intensidade de

Trabalho

+

Estrutura de Pressão no Cronograma

62

Pressão de

Cronogram a+

Trabalho

RestanteAtividades

finalizadas

sem erros

Atividadescom Erros

conhecidos

+

+

(B)Taxa de

finalização

percebida

+

Atividades

com Erros nãoconhecidos

Taxa deCriação de

Erro

+

+

+

++

(R)

(R)

Estrutura de Retrabalho

Taxa de tarefas aserem realizadas

Taxa derealização doTrabalho Base

Trabalho Basedisponível para

realização

Trabalho Basenão realizado

+

(B)Restrições dePrecedência

-

Trabalho Base

Realizado

Escopo doProjeto

(R)+

-

+

+

+

+

Estrutura de Trabalho Disponível

-

(R)

Padrão deQualidade

Qualidade doTrabalho

Tarefasfinalizadas

sem Erros

Qualidade do

Produto

Defasagem de

Qualidade

Trabalho

restante

Pressão para

diminuição dosrequerimento de Projeto

+

+

+

+ +

+

-

-

(B)

(R)

Estrutura de Qualidade

Taxa de

finalização deatividades

Trabalho

Restante

Pressão para diminuição

dos requerimentos do

Projeto

Escopo do

Projeto

Fila deAtividades

Porcentagem do

Escopo do Projetoatendido

(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.

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 01Erros 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.

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ídoTaxa 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ídoTaxa de atividades realizada

Trabalho InicialPessoas 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”

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,

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).

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

Ho

ras

real

men

te a

dic

ion

adas

no

Res

ult

ado

Engenharia Produção

Trabalho a

ser realizado

Retrabalhonão

Descoberto

Qualidade

Horas Extras

Necessidade

Pessoal

Progresso

aparente

Pessoas Produtividade

Taxa de Atividade

realizadas

Retrabalhonão

Descoberto

Retrabalho

Conhecido Identificaçãodo Trabalho

Qualidade

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.

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.

Retrabalhonão

Descoberto

Retrabalho

Conhecido Identificaçãodo Trabalho

Qualidade

Trabalho a

ser realizado

Retrabalhonão

Descoberto

Qualidade

Horas Extras

Necessidade

Pessoal

Progresso

aparente

Pessoas Produtividade

Taxa de Atividade

realizadas

Nível de

Competência Incial

Contratação

Nova EquipeEquipe Disponível

Nível de Atrito

Nível de Competência

da Equipe

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 é

Retrabalhonão

Descoberto

Retrabalho

Conhecido Identificaçãodo Trabalho

Qualidade

Trabalho a

ser realizado

Retrabalhonã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

Retrabalhonão

Descoberto

Retrabalho

Conhecido Identificaçãodo Trabalho

Trabalho a

ser realizado

Retrabalhonão

DescobertoTaxa de Atividade

realizadas

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.

Retrabalhonão

Descoberto

Retrabalho

Conhecido Identificaçãodo Trabalho

Trabalho a

ser realizado

Retrabalhonão

Descoberto

Qualidade

Horas Extras

Necessidade

Pessoal

Progresso

aparente

Pessoas Produtividade

Taxa de Atividade

realizadas

Nível de

Competência Incial

Contratação

Nova EquipeEquipe 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

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

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

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.

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.

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çãoTrabalho

Concluído+

Trabalho BaseDisponível para

realização +

Escopo do Projeto

+

Pressão para diminuiçãodos Requerimentos do

Projeto

+

Fila de atividades

+

Moficação de Escopo eAumento 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

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

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

realizadoTrabalho 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

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

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

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

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

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

ParalelismoRecursos 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 BaseDisponí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

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.

AtrasoParalelismo

Recursos Humanos

Disponíveis

Trabalho a ser

realizado

Duração das

Atividades

Inter-Relação de AtividadesParalelas (Restrições de

Precedência)+

-+ + +

+

Trabalho em

ExecuçãoTrabalho

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 BaseDisponível para

realização+

Escopo do Projeto

+

-

Tarefas realizadas

sem Erros+

Padrão de

QualidadePressão para diminuiçãodos Requerimentos do

Projeto

+

-

--

Fila de atividades

+

+

Nível de Confiança

(gestor)

-

-

Modificação de Escopo eAumento 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)

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.

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ídoTrabalho em execução

Definição inicial do projeto

Progresso

Recursos humanos

disponíveis

AjusteProjeto concluído?

Equipe mínima

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

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.

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ídoTrabalho 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.

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.

92

Trabalho a ser

realizado

Trabalho

concluídoTrabalho em execução

Definição inicial do projeto

Progresso real

Capacidade

Normal

AjusteProjeto

concluído?

Qualidade de

execução do trabalho

Equipe

mínima

Retrabalhos

ainda não

identificados

Retrabalho

conhecidoGeraçã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.

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.

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

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

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

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

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.

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.

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

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

102

8 ANEXOS

Fonte: Bearingpoint Consulting (2004)

FuncionalDesenvolvimentos

TecnologiaGDM

Atividade ExternaConfiguração

EspecificaçãoFuncional

Desenvol-vimento

Homologação

Teste Unitário

BPP’s

DocumentaçãoConfiguração

FunçõesProc / Org

Infra BasicaInfra-SAP

FerramentasDe Projeto Ambiente de

Qualidade

Ambiente deTreinamento

Ambiente deProdução

Perfis deAutorização

Treinamento1 (Piloto)

MaterialDidático

Catalogo de Cursos

Mapeamento1 e 2

Impactos Org.

MigraçãoCiclo 1

TesteIntegrado

Grade Trein. 1 e 2

Go-live1

CapacitaçãoMultiplicadores

Associação deUsuários a

Perfil

PreparaçãoCentros de

Treinamento

Teste de Campo -Simulado

Teste deDesempenho

Teste de Cutover

Estrutura deSuporte

CutOver

Treinamento2

Associação deUsuários a

Perfil

CutOver

Go-live2

Implementação

Encadeamento

MigraçãoCiclo 2

MigraçãoRevisão

MigraçãoTeste

Piloto + UE

Ambiente deTeste 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 8R: 0% P: 0%

Abril 11 Junho 17R: 0% P:0%

Junho 8 Julho 29R: 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 deCampo -Itaguaí

Teste deDesempenho

Estrutura deSuporte

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çãoTeste 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çãoTé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 31R: 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

FuncionalDesenvolvimentos

TecnologiaGDM

Atividade ExternaConfiguração

EspecificaçãoFuncional

Desenvol-vimento

Homologação

Teste Unitário

BPP’s

DocumentaçãoConfiguração

FunçõesProc / Org

Infra BasicaInfra-SAP

FerramentasDe Projeto Ambiente de

Qualidade

Ambiente deTreinamento

Ambiente deProdução

Perfis deAutorização

Treinamento1 (Piloto)

MaterialDidático

Catalogo de Cursos

Mapeamento1 e 2

Impactos Org.

MigraçãoCiclo 1

TesteIntegrado

Grade Trein. 1 e 2

Go-live1

CapacitaçãoMultiplicadores

Associação deUsuários a

Perfil

PreparaçãoCentros de

Treinamento

Teste de Campo -Simulado

Teste deDesempenho

Teste de Cutover

Estrutura deSuporte

CutOver

Treinamento2

Associação deUsuários a

Perfil

CutOver

Go-live2

Implementação

Encadeamento

MigraçãoCiclo 2

MigraçãoRevisão

MigraçãoTeste

Piloto + UE

Ambiente deTeste 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 8R: 0% P: 0%

Abril 11 Junho 17R: 0% P:0%

Junho 8 Julho 29R: 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 deCampo -Itaguaí

Teste deDesempenho

Estrutura deSuporte

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çãoTeste 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çãoTé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 31R: 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 lD e s e n v o lv i m e n t o s

T e c n o l o g i aG D M

A t i v i d a d e E x t e r n a

P a r t i c i p a ç ã o d e o u t r o t i m e

I n i c i o d e d e s v i o s i g n i f i c 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 i c 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 ç ã oF 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 eQ u a l i d a d e A m b i e n t e d e

P r o d u ç ã o

T e s t eI 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 eT e s t e M i g r a ç ã o

R e a l i z 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 i l 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 ç ã oT é 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 lD e s e n v o lv i m e n t o s

T e c n o l o g i aG D M

A t i v i d a d e E x t e r n a

P a r t i c i p a ç ã o d e o u t r o t i m e

I n i c i o d e d e s v i o s i g n i f i c 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 i c 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 ç ã oF 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 eQ u a l i d a d e A m b i e n t e d e

P r o d u ç ã o

T e s t eI 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 eT e s t e M i g r a ç ã o

R e a l i z 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 i l 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 ç ã oT é 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

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

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

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.

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

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

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