Plano de Projeto para Implantação de Software · PDF fileSensu em Gestão de Projetos segundo as ... 8.5 Plano de Gerenciamento de Aquisições ... seleção do fornecedor e produto

Gerenciamento de Projeto – Implantação de Software ERP Pág. 1

FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

CENTRO DE PÓS-GRADUAÇÃO

Gestão de Projetos segundo as Práticas do PMI®

Plano de Projeto para Implantação de Software ERP

Fabiano Kruppa Villani

Monografia de Conclusão de Curso

apresentada como exigência parcial para

obtenção do título de pós-graduação Lato

Sensu em Gestão de Projetos segundo as

Práticas do PMI®

Orientador: Prof. Augusto Camargos

São Paulo

2005



FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

CENTRO DE PÓS-GRADUAÇÃO

Gestão de Projetos segundo as Práticas do PMI®

Plano de Projeto para Implantação de Software ERP

Fabiano Kruppa Villani

Monografia de Conclusão de Curso

apresentada como exigência parcial para

obtenção do título de pós-graduação Lato

Sensu em Gestão de Projetos segundo as

Práticas do PMI®

Orientador: Prof. Augusto Camargos

São Paulo

2005


Orientador:

__________________________________________

Banca:

__________________________________________

__________________________________________


Dedicação

Dedico este trabalho a minha esposa pelo apoio, carinho e noites em claro e aos

meus pais responsáveis pela minha educação e formação.


Agradecimento(s)

Agradeço aos mestres do curso de pós-graduação em Gestão de projetos que

lecionaram para turma 11LK e em especial ao Professor Augusto Camargos, que me

orientou no desenvolvimento desse trabalho.


SUMÁRIO

1. INTRODUÇÃO .................................................................................................16 1.1 Contexto e Justificativa do Trabalho ............................................................16

1.2 Objetivo do Trabalho ....................................................................................17

1.3 Limitações do Trabalho ................................................................................17

2. VISÃO INICIAL DO PROJETO ........................................................................18 3. PROJECT CHARTER ......................................................................................19

3.1 Contextualização ..........................................................................................19

3.2 Designação do Gerente de Projeto suas Responsabilidades e Autoridade 19

3.3 Necessidades do Negócio ............................................................................20

3.4 Objetivos e Produtos do Negócio .................................................................20

3.5 Premissas .....................................................................................................21

3.6 Restrições .....................................................................................................22

4. DECLARAÇÃO DO ESCOPO..........................................................................23 4.1 Detalhamento do Escopo .............................................................................23

4.2 Exclusões......................................................................................................24

4.3 WBS do Projeto ............................................................................................25

4.4 Dicionário do WBS do Projeto ......................................................................26

5. ESTIMATIVAS DO PROJETO .........................................................................28 5.1 Estimativas de Duração................................................................................28

5.2 Estimativa de Prazo do Projeto ....................................................................28

5.3 Custo Estimado ao Projeto ...........................................................................29

5.4 Custos Acumulados por Período..................................................................29

5.5 Curva “S”.......................................................................................................30

5.6 Cronograma Detalhado do Projeto...............................................................31

6. ORGANIZAÇÃO DO PROJETO ......................................................................33


6.1 Relação dos Stakeholders............................................................................33

6.2 Sumários de Stakeholders............................................................................33

6.3 Estrutura Organizacional ..............................................................................36

7. Riscos do Projeto .............................................................................................37 7.1 Identificação dos Riscos ...............................................................................37

7.2 Plano de Resposta aos Riscos.....................................................................38

8. Plano das Áreas de Gerenciamento do Projeto...............................................41 8.1 Plano de Gerenciamento do Escopo............................................................41

8.1.1 Descrição dos Processos de Gerenciamento de Escopo ........................41

8.1.2 Sistema de Controle de Mudança de Escopo ..........................................41

8.1.3 Priorização das Mudanças de Escopo......................................................41

8.1.4 Gerenciamento das Configurações ..........................................................42

8.1.5 Freqüência de Avaliação do Escopo do Projeto.......................................42

8.2 Plano de Gerenciamento do Tempo.............................................................42

8.2.1 Descrição dos Processos de Gerenciamento de Tempo .........................42

8.2.2 Sistema de Controle de Mudança de Prazos ...........................................43

8.2.3 Freqüência de Avaliação do Prazo do Projeto .........................................43

8.2.4 Impacto das Mudanças da Programação no Projeto ...............................44

8.3 Plano de Gerenciamento do Custo ..............................................................45

8.3.1 Descrição dos Processos de Gerenciamento de Custo ...........................45

8.3.2 Freqüência de Avaliação do Orçamento do Projeto.................................45

8.3.3 Controle dos Custos do Projeto ................................................................45

8.3.4 Impacto das alterações nos Custos do Projeto ........................................45

8.4 Plano de Gerenciamento de Risco...............................................................46

8.4.1 Descrição dos Processos de Gerenciamento de Risco ...........................46


8.4.2 Identificação dos Riscos ...........................................................................46

8.4.3 Qualificação dos Riscos............................................................................47

8.4.4 Estratégias para Tratamento dos Riscos..................................................49

8.4.5 Sistema de Mudanças de Riscos..............................................................50

8.4.6 Freqüência de Avaliação dos Riscos do Projeto ......................................50

8.5 Plano de Gerenciamento de Aquisições ......................................................51

8.5.1 Descrição dos Processos do Gerenciamento de Suprimento..................51

8.5.2 Definição da Aquisição..............................................................................51

8.5.3 Responsabilidade do contrato ..................................................................52

8.5.4 Critério de Decisão....................................................................................52

8.5.5 Tipo de Contrato .......................................................................................53

8.6 Plano de Gerenciamento da Qualidade .......................................................54

8.6.1 Descrição dos Processos de Gerenciamento da Qualidade....................54

8.6.2 Política de Qualidade Corporativa ............................................................54

8.6.3 Padrões adotados ao Projeto ...................................................................56

8.6.4 Freqüência de Avaliação dos Requisitos de Qualidade ...........................56

8.6.5 Controle da Qualidade ..............................................................................56

8.6.6 Garantia da Qualidade ..............................................................................57

8.7 Plano de Gerenciamento da Comunicação..................................................58

8.7.1 Descrição do Processo de Gerenciamento das Comunicações ..............58

8.7.2 Tipos de Comunicação .............................................................................58

8.7.3 Atas de Reunião........................................................................................59

8.7.4 Relatórios do Projeto.................................................................................59

8.7.5 Plano de Comunicação.............................................................................60

8.8 Plano de Gerenciamento de Recursos Humanos........................................61


8.8.1 Descrição do Processo de Gerenciamento de Recursos Humanos ........61

8.8.2 Avaliação dos Resultados da Equipe do Projeto......................................61

8.8.3 Treinamento ..............................................................................................61

8.8.4 Bonificação................................................................................................62

8.8.5 Freqüência de Avaliação Consolidada dos Resultados da Equipe..........62

8.9 Controle Integrado de Mudanças .................................................................63

9. CONCLUSÃO...................................................................................................65 10. APÊNDICES.....................................................................................................67 11. GLOSSÁRIO ....................................................................................................72


SUMÁRIO DE TABELAS

TABELA 1 – Estimativa do Projeto .............................................................................28

TABELA 2 – Custo Estimado do Projeto ....................................................................29

TABELA 3 – Custos Acumulados do Projeto..............................................................30


SUMÁRIO DE QUADROS

QUADRO 1 – Dicionário de WBS ...............................................................................27

QUADRO 2 – Relação de Stakeholders .....................................................................33

QUADRO 3 – Sumário de Stakeholders.....................................................................35

QUADRO 4 – Plano de Respostas aos Riscos ..........................................................40

QUADRO 5 – Critérios para Priorização de Mudanças de Escopo............................42


SUMÁRIO DE FIGURAS

FIGURA 1 – WBS........................................................................................................25

FIGURA 2 – Gráfico de Estimativa do Projeto............................................................29

FIGURA 3 – Curva “S” ................................................................................................30

FIGURA 4 – Estrutura Organizacional ........................................................................36

FIGURA 5 – Fluxo do Controle de Escopo .................................................................41

FIGURA 6 – Fluxo de Gerenciamento de Configurações...........................................42

FIGURA 7 – Fluxo para Verificação de Escopo..........................................................42

FIGURA 8 – Processo de Aquisição...........................................................................52


RESUMO

Geralmente, os projetos para implementação de software de ERP - Enterprise

Resource Planning - são complexos e conseqüentemente demorados. Alguns

problemas sérios encontrados neste tipo de projeto são a participação de muitas

pessoas com diferentes interesses, a localidade dos participantes, os processos sem

padronização ou não existentes, o medo ou restrição das pessoas devido a

mudança de cultura, a participação de pessoas não dedicadas inteiramente ao

projeto, entre outros. Estes problemas, se não gerenciados, geram

descontentamento do cliente, pois resultam em custos e atrasos no prazo não

planejados no início do projeto.

O estudo deste trabalho procura apresentar um modelo de plano de projeto

para a implementação de software ERP. O plano de projeto está demonstrado neste

estudo com base nas práticas de gerenciamento de projetos descritas no PMBOK -

Project Management Book of Knowledge 2000.

O sucesso para implementação de software de ERP depende de muitos

aspectos. O plano de projeto deste trabalho procura apresentar uma forma de

identificar e controlar estes aspectos para alcançar o sucesso do projeto.


ABSTRACT

Generally, the projects for implementation of ERP software - Enterprise

Resource Planning - are complex and consequently delayed. Some found serious

problems in this type of project are the participation of many people with different

interests, the locality of the participants, processes without standardization or not

existing, the fear or restriction of the people caused by the culture change, the

participation of people not dedicated entirely to the project, among others. These

problems, if not managed, generate dissatisfaction of the customer, therefore

because result in costs and delays in the stated period not planned in the beginning

of the project.

The study of this work it looks for to immediate present a model of project for

the implementation of software ERP. The project plan is demonstrated in this study

on the basis of practical of management of described projects in the PMBOK –

Project Management Book of Knowledge.

The success for implementation of ERP software depends on many aspects.

The plan of project of this work looks for to present a form to identify and to control

these aspects to reach the success of the project.


1. INTRODUÇÃO

Neste capítulo serão apresentados o contexto no qual se insere este trabalho

e as justificativas que motivaram sua realização, o objetivo proposto e as limitações

consideradas.

1.1 Contexto e Justificativa do Trabalho

Segundo Souza e Saccol (2003), os Enterprise Resource Planning (ERP) são

Sistemas de Informação adquiridos na forma de pacotes comerciais de software que

integram dados dos sistemas de informação transacionais e dos processos de

negócios de uma empresa.

Os projetos de implementação do software de ERP são geralmente encarados

como demorados e caros, e o fracasso de sua implementação se tornar um grande

desastre para a organização.

A implantação de um software de ERP apresenta significativas mudanças na

cultura de uma organização, as quais exigem muito esforço dos envolvidos e

investimento da alta direção. Em função disso, tais mudanças produzem grandes

impactos ao negócio da empresa, e o conhecimento desses impactos é essencial

para um resultado positivo no processo de implantação do software de ERP.

Os grandes riscos apresentados e o alto índice de fracasso de projetos de

implementação de software ERP motivaram o desenvolvimento desse trabalho.


1.2 Objetivo do Trabalho

O objetivo desse trabalho é apresentar um plano de projeto para

implementação de um software de ERP.

1.3 Limitações do Trabalho

Este trabalho descreve um modelo de plano para gerenciamento de projeto,

baseado nas melhores práticas para gerenciamento de projetos descritas no

PMBOK - Project Management Book of Knowledge 2000, com o objetivo de apoiar a

implementação de um software de ERP.


2. VISÃO INICIAL DO PROJETO

Este projeto objetiva a implementação de um software de gestão empresarial

conhecido comercialmente como ERP - Enterprise Resource Planning

(Planejamento de recursos empresariais). Os módulos previstos no escopo do

projeto de implantação do ERP são o módulo Financeiro e o módulo de Recursos

Humanos.

O projeto está dividido em três fases que indicarão os principais pontos de

entrega do projeto. O primeiro passo é a fase de a Iniciação, onde serão definidos o

Comitê Executivo responsável pela avaliação e aprovação dos deliverables do

projeto, os stakeholders, os usuários chaves participantes do projeto e a equipe

técnica do projeto, as necessidades de cada área de negócio da empresa e a

seleção do fornecedor e produto de ERP. Em seguida, a fase Arquitetura dos

Requisitos é responsável pelo levantamento e definição dos parâmetros e

customização de cada área de negócio e requisitos técnicos de integração do

produto ao CRM da empresa. A terceira e última fase, a Implementação, contempla

a homologação dos parâmetros configurados a cada área de negócio, a integração

com o banco de dados do software de CRM - Customer Relationship Management -

da empresa e a instalação final do produto em ambiente de produção.


3. PROJECT CHARTER

3.1 Contextualização

Prestadora de serviços no segmento de saúde medicinal, a empresa Sempre

Saudável LTDA, possui 20 anos de atividades no mercado brasileiro. A empresa

opera planos de saúde médica para o mercado empresarial e pessoa física.

Atualmente possui 150.000 beneficiários, uma rede credenciada de 15.000,

composta por profissionais e estabelecimentos que atendem a diversas

especialidades da medicina, e um faturamento anual de R$ 140.000.000 (Cento e

Setenta Milhões de Reais).

A empresa possui dois escritórios instalados nas cidades de São Paulo – SP e

Rio de janeiro – RJ. No escritório de São Paulo funcionam as operações

administrativas / financeiras e de recursos humanos / departamento pessoal,

enquanto no escritório do Rio de Janeiro somente a operações administrativas /

financeiras. Não existe, entre os escritórios, uma integração on-line das informações.

Todas as operações são administrativas sob processos, em sua maior parte,

manuais e de fontes de dados descentralizadas. Esta estrutura não possui um

processo padrão onde as atividades são tratadas de modos diferentes em cada

escritório e / ou departamento da empresa.

3.2 Designação do Gerente de Projeto suas Responsabilidades e Autoridade

O Sr. Josué Khurt Mickrer, presidente da empresa de assistência médica

Sempre Saudável, patrocinará o projeto Sistema ERP.


O Sr. Marcos Shimask Curl, gerente de projetos, é um profissional com larga

experiência em projetos de implantação de software ERP. Ele será o profissional

responsável por designar o projeto durante todo o seu ciclo da vida, tendo

autoridade máxima dentro do projeto.

3.3 Necessidades do Negócio

A empresa Sempre Saudável pretende, com o projeto, integrar as operações

tramitadas entre os escritórios de forma on-line e real-time. Padronizar os processos

administrativos / financeiros e de recursos humanos / departamento pessoal, a fim

de minimizar o prazo das atividades, tornar as informações mais confiáveis e criar

uma banco de dados de informações estratégicas para auxílio às tomadas de

decisões.

Contudo, a empresa Sempre Saudável almeja aumentar em 3% (três por

cento) o seu faturamento anual.

3.4 Objetivos e Produtos do Negócio

Além de integrar as atividades operacionais dos escritórios, a empresa deseja

também introduzir em suas operações as atividades de contabilidade e fechamento

de folha de pagamento, atualmente administrada por empresas terceiras, e

automatizar todos as operações realizadas pelo departamento administrativo /

financeiro e de recursos humanos / departamento pessoal, conforme documento de

requisição de proposta (RFP) em anexo.


Os processos financeiros a serem automatizados são, contas a pagar e

receber, cobrança, recebimento, agenda de pagamentos, controle da movimentação

de caixa e bancos, fluxos de caixas, relatórios de receitas e despesas por centro de

custo e natureza das despesas em regime de caixa e competência.

Os processos de recursos humanos a serem automatizados são, Controle e

administração de processos admissionais, processamento da folha de pagamento e

relatórios gerenciais.

A fim de atender a estas necessidades a empresa irá adquirir um software,

comercializado no mercado, de gestão empresarial.

3.5 Premissas

As premissas encontradas para o projeto são:

Alinhamento entre o software, a cultura e os objetivos de negócio da

empresa;

Comprometimento da alta administração e dos proprietários dos processos

envolvidos;

Tecnologia do software adequada com a infra-estrutura técnica das

estações de trabalho existente na empresa;

Aquisição de nova máquina servidora para instalação de banco de dados

e serviço para comunicação entre os escritórios via rede privada;


3.6 Restrições

As restrições encontradas para o projeto são:

O projeto deverá ser concluído no prazo máximo de dez meses.

O custo máximo para o projeto é de R$ 250.000 (Duzentos e Cinqüenta

Mil Reais).

Utilizar a infra-estrutura das estações de trabalho existentes na empresa.

As pessoas envolvidas participarão do projeto em suas localidades, sem a

necessidade de se reunirem num mesmo local;


4. DECLARAÇÃO DO ESCOPO

4.1 Detalhamento do Escopo

O projeto Sistema ERP contempla integrar as informações operacionais e

administrativas tramitadas entre os escritórios e a automatização dos processos

administrativos / financeiros e de recursos humanos / departamento pessoal da

empresa de assistência médica Sempre Saudável. Para isso a empresa pretende

adquirir um software de gestão empresarial de mercado e contratar uma empresa

para prestação de serviços de manutenção do produto, ou seja, uma empresa

responsável por realizar novas customizações ou parametrizações do software

conforme necessidades dos usuários ou do negócio.

O produto de software de ERP deverá seguir as necessidades descritas no

documento Request for Proposal (RFP) pelo Comitê Executivo e usuários chaves do

software. Os fornecedores selecionados deverão atender todos os padrões de

qualidade de serviços terceirizados definidos na política de qualidade da empresa

Sempre Saúde.

Haverá uma rede privada para comunicação entre os escritórios, o banco de

dados do software de ERP ficará instalado no escritório de São Paulo e deverá

integra-se com o banco de dados do CRM - Customer Relationship Management -

da empresa Sempre Saudável, assim como os requisitos mínimos de infra-estrutura

das estações de trabalho para execução do software ERP deverão ser baseados a

infra-estrutura existente na empresa.


4.2 Exclusões

Não fazem parte deste projeto:

O gerenciamento de novas manutenções necessárias ao software pós-

implantação;

O desenvolvimento de relatórios gerenciais do software de gestão

empresarial pós-implantação;

A administração de contratos pós-implantação para manutenção do

software.


4.3 WBS do Projeto

FIGURA 1 – WBS


4.4 Dicionário do WBS do Projeto

Código Item da WBS Descritivo

1 Projeto ERP

1.1 Gerenciamento do projeto Este deliverable tem como objetivo prover o gerenciamento de todo o ciclo de vida do projeto.

1.1.1 Plano do Projeto Documento desenvolvido e aprovado formalmente usado para executar o gerenciamento do projeto.

1.1.2 Controle do Projeto Documentos e reuniões de acompanhamento e controle do projeto.

1.1.3 Fechamento do Projeto Documentos e reuniões de encerramento de contratos e do projeto.

1.2 Iniciação

Este deliverable tem como objetivo definir os stakeholders do projeto, realizar o levantamento inicial das informações fornecidas pelos usuários-chave para a definição do escopo do produto, e desenvolvimento do documento de requisição de proposta caseado nos requerimentos de negócio fornecidos pelo usuário-chave.

1.2.1 Comitê Executivo Formação do Comitê Executivo de avaliação do projeto.

1.2.2 RFP - Request for Proposal Documento para requisição de propostas de fornecedores.

1.2.3 Software ERP Seleção, definição e contrato do produto de software de ERP.

1.2.4 Fornecedor ERP Seleção, definição e contrato do fornecedor dos serviços de manutenção do software de ERP.

1.2.5 Aceite da RFP Documento de aprovação formal do Comitê Executivo e usuários chave referente ao documento RFP.

1.3 Arquitetura dos Requisitos

Este deliverable visa o entendimento das reais necessidades de negócio dos usuários chave, criação do plano de testes e definição do ambiente para adequação ao funcionamento correto do produto.

1.3.1 Especificação de Parâmetros Documento contendo regras de negócio e especificação dos parâmetros e


e Customizações customizações necessárias às operações da empresa.

1.3.2 Modelo de Infra-Estrutura Documento para validação do modelo de infra-estrutura adequado ao produto.

1.3.3 Plano de Testes

O propósito deste documento é identificar processos de negócio que devem ser testados, identificar os recursos requeridos e prover a estimativa de esforço para os testes.

1.3.4 Plano de Implantação Documento contendo todas as atividades necessárias para a implementação do software em ambiente de produção.

1.4 Implementação

Este deliverable tem como objetivo o configurar o ambiente de homologação, execução dos testes finais pelos usuários-chave e implantação do produto no ambiente de produção.

1.4.1 Parametrização do Software Executar a parametrização e customização do software conforme definido durante a arquitetura de requisitos.

1.4.2 Integração com CRM Executar a integração do banco de dados do software ERP com o banco de dados do software CRM.

1.4.3 Ambiente de Testes Configuração do ambiente de testes.

1.4.4 Treinamento dos usuários Treinamento dos usuários do software.

1.4.5 Execução do Plano de Testes Documento contendo a indicação dos testes realizados e o tempo real de esforço.

1.4.6 Testes de Usuários Documento contendo os resultado dos testes realizados em ambiente de homologação.

1.4.7 Configuração Final do Software

Documento contendo os ajustes realizados no software para implementação do ambiente de produção.

1.4.8 Instalação do Software Instalação e início das operações do software ERP.

QUADRO 1 – Dicionário de WBS


5. ESTIMATIVAS DO PROJETO

5.1 Estimativas de Duração

Utilizaremos a este projeto duas abordagens para estimativa de duração das

atividades. A primeira abordagem, chamada de Estimativa por Analogia, utilizada na

fase inicial do projeto quando existe uma quantidade limitada de informações sobre

o projeto. Neste conceito usam-se os valores reais de durações de projetos

anteriores ou similares e / ou a opinião de um especialista em projetos de mesmas

características.

A segunda abordagem, chamada de Estimativa Detalhada, é utilizada após a

identificação e a especificação das tarefas necessárias ao desenvolvimento do

projeto.

A abordagem Estimativa por Analogia possui uma margem de erro que varia de

-25% a +75%. Enquanto a abordagem Estimativa Detalhada possui uma margem de

erro que varia de -5% a +10%.

5.2 Estimativa de Prazo do Projeto

Esta estimativa foi realizada na fase inicial do projeto utilizando a abordagem

de Estimativa por Analogia. Abaixo seguem os principais milestones e estimativas de

entrega.

Milestones Data Inicial Data Final Gerenciamento do Projeto 03/11/2004 30/05/2005 Iniciação 18/11/2004 21/12/2004 Arquitetura dos Requisitos 21/12/2004 27/04/2005 Implementação 27/04/2004 30/05/2005

TABELA 1 – Estimativa do Projeto


Estimativa por Analogia

03/11/04

08/04/0530/05/05

02/11/05

23/04/04

01/08/04

09/11/04

17/02/05

28/05/05

05/09/05

14/12/05

Variações da Estimativa

Data

s P

revi

stas

Estimativa por Analogia

Estimativa por Analogia 03/11/04 08/04/05 30/05/05 02/11/05

Data de Início -25% Estimada +75%

FIGURA 2 – Gráfico de Estimativa do Projeto

5.3 Custo Estimado ao Projeto

Milestones Custo em R$ Gerenciamento do Projeto R$ 12.720,00

Iniciação R$ 100.080,00

Arquitetura dos Requisitos R$ 35.272,00

Implementação R$ 63.968,00

Custo Total Estimado para o Projeto R$ 212.040,00

TABELA 2 – Custo Estimado do Projeto

5.4 Custos Acumulados por Período

Gerenciamento do Projeto Iniciação Arquitetura

dos Requisitos Implementação Custo Total Acumulado

Nov/04 R$ 6.320,00 R$ 80,00 R$ 0,00 R$ 0,00 R$ 6.400,00

Dez/04 R$ 7.920,00 R$ 100.080,00 R$ 10.724,00 R$ 0,00 R$ 118.724,00

Jan/05 R$ 7.920,00 R$ 100.080,00 R$ 22.992,40 R$ 0,00 R$ 130.992,40

Fev/05 R$ 7.920,00 R$ 100.080,00 R$ 33.409,60 R$ 0,00 R$ 141.409,60


Gerenciamento do Projeto Iniciação Arquitetura

dos Requisitos Implementação Custo Total Acumulado

Mar/05 R$ 9.520,00 R$ 100.080,00 R$ 35.272,00 R$ 40.982,40 R$ 185.854,40

Abr/05 R$ 9.520,00 R$ 100.080,00 R$ 35.272,00 R$ 57.064,00 R$ 201.936,00

Mai/05 R$ 12.720,00 R$ 100.080,00 R$ 35.272,00 R$ 63.968,00 R$ 212.040,00

TABELA 3 – Custos Acumulados do Projeto

5.5 Curva “S”

Projeto Sistema ERP

R$ 6.400,00

R$ 118.724,00R$ 130.992,37

R$ 141.409,60

R$ 185.854,40

R$ 201.936,00R$ 212.040,00

R$ 0,00

R$ 50.000,00

R$ 100.000,00

R$ 150.000,00

R$ 200.000,00

R$ 250.000,00

nov/04 dez/04 jan/05 fev/05 mar/05 abr/05 mai/05

Meses

Cus

to R

$

FIGURA 3 – Curva “S”


5.6 Cronograma Detalhado do Projeto



6. ORGANIZAÇÃO DO PROJETO

6.1 Relação dos Stakeholders

Stakeholder Departamento Cargo Telefone

Marciel Rodrigues Guedhes Presidência Presidente 1101-0100

José Ferreira Shurts Financeiro Diretor Financeiro 1101-0101

Patrycia Khalts Financeiro Gerente Financeiro 1101-0102

Marcos Brito Ghost Bross Financeiro Analista Financeiro 1101-0202

Roberto Friman Turns Financeiro Analista Contábil 1101-0203

Francisco Hermins Schimt Tecnologia da Informação

Diretor de Tecnologia da Informação 1101-0303

Josué Khurt Mickrer Tecnologia da Informação

Gerente de Tecnologia da Informação 1101-0301

Fábio Hernany Crusb Tecnologia da Informação Analista de Sistemas 1101-0304

Heitor Villas Fransher Tecnologia da Informação DBA 1101-0305

Kleber Presba Norman Tecnologia da Informação

Analista de Infra-estrutura 1101-0306

Eliana Machado Thirds Recursos Humanos Diretor de Recursos Humanos 1101-0401

Humberto Costa Michigan Recursos Humanos Analista de Recursos Humanos 1101-0402

Ana Paulo Figueira Mharts Recursos Humanos Assistente de Recursos Humanos 1101-0403

Arnaldo Roberto Shiriks Recursos Humanos Analista de Departamento Pessoal 1101-0404

QUADRO 2 – Relação de Stakeholders

6.2 Sumários de Stakeholders

Nome Papel Responsabilidades Envolvimento

Marciel Rodrigues

Patrocinador Prover benefícios ao projeto

Acompanhamento do status do projeto.


Nome Papel Responsabilidades Envolvimento Guedhes Garantir suporte da alta

gerencia

Decisões finais

José Ferreira Shurts

Membro Comitê Executivo

Avaliações de resultados

Aprovações de mudanças de pleno

Definições

Participação durante as atividades de controle e avaliação do projeto.

Patrycia Khalts Usuário-chave

Fornece requisitos e informações

Desenvolvimento dos processos de negócios

Testes de aceite

Participação durante as fases de iniciação, Arquitetura de requisitos e implementação.

Marcos Brito Ghost Bross Usuário-chave



Testes de aceite


Roberto Friman Turns Usuário-chave



Testes de aceite

Participação durante as fases de Arquitetura de requisitos e implementação.

Francisco Hermins Schimt




Definições


Josué Khurt Mickrer

Gerente do Projeto

Responsável pelo projeto

Resolver conflitos

Direção do projeto para garantir orçamento, cronograma e escopo

Participa de todo o ciclo de vida do projeto.

Fábio Hernany Crusb

Coordenador Área Técnica

Coordenação das atividades da equipe.

Participa das fases de Arquitetura de requisitos e Implementação.


Nome Papel Responsabilidades Envolvimento

Heitor Villas Fransher DBA

Suporte a implementação do projeto

Suporte ao aceite

Migração para produção

Recomendações


Kleber Presba Norman

Analista de Infra-estrutura

Suporte a implementação do projeto

Suporte ao aceite

Migração para produção

Recomendações


Eliana Machado Thirds




Definições


Humberto Costa Michigan Usuário-chave



Testes de aceite


Ana Paulo Figueira Mharts Usuário-chave



Testes de aceite


Arnaldo Roberto Shiriks Usuário-chave



Testes de aceite


QUADRO 3 – Sumário de Stakeholders


6.3 Estrutura Organizacional

FIGURA 4 – Estrutura Organizacional


7. Riscos do Projeto

7.1 Identificação dos Riscos

1) Ausência de comprometimento entre os membros da equipe de

desenvolvimento em relação ao projeto;

2) Membros da equipe de desenvolvimento não familiarizados com o negócio

da empresa;

3) Ausência de apoio da alta direção;

4) Ausência da participação do usuário chave;

5) Ausência de cooperação entre os usuários chave;

6) Mudanças contínuas dos requisitos;

7) Licença saúde de um membro da equipe;

8) Terminar o projeto antes da data prevista;

9) O software não executar corretamente no ambiente de produção;

10) Satisfação dos beneficiários;

11) Satisfação da rede credenciada;

12) Estimativas incorretas de prazo das atividades;

13) Falha de comunicação entre os envolvidos de cada escritório;

14) A empresa fornecedora abandonar o projeto;


7.2 Plano de Resposta aos Riscos

Risco

Prob

abili

dade

Impa

cto

P X

I

Influ

ênci

a C

ód. W

BS

Devilerable

Estr

atég

ia

Respostas ao Risco

Ausência de comprometimento entre os membros da equipe de desenvolvimento em relação ao projeto

0,3 0,7 0,21 -11.11.4

Planejamento do projeto

Iniciação E Envolver a equipe nos objetivos do projeto.

Membros da equipe técnica não familiarizados com o negócio da empresa

0,5 0,5 0,25 -11.21.3

Iniciação Arquitetura dos

Requisitos M Identificar as deficiências e treinar a equipe para

conhecimento das regras de negócio da empresa.

Ausência de apoio da alta direção 0,1 0,9 0,09 -1

1.11.21.3

Gerenciamento do projeto


Requisitos

M Envolver e participar a alta direção durante todo ciclo de vida do projeto.

Ausência da participação do usuário chave 0,1 0,9 0,09 -1

1.21.4

Iniciação Implementação

MEnvolver os usuários chave na necessidade do projeto. Mantê-los informado do status do projeto.


Risco

Prob

abili

dade

Impa

cto

P X

I

Influ

ênci

a C

ód. W

BS

Devilerable

Estr

atég

ia

Respostas ao Risco

Ausência de cooperação entre os usuários chave 0,5 0,9 0,45 -1

1.21.4

Iniciação Implementação

M Destacar aos usuários chaves a necessidade de cooperação para o bom desempenho do projeto.

Mudanças contínuas dos requisitos 0,7 0,5 0,35 -1 1.4 Implementação M

Solicitar aprovação de todos documentos do projeto junto ao usuário chave. Negociar as solicitações de mudanças definindo prioridades.

Licença saúde de um membro da equipe 0,5 0,7 0,35 -1 A Treinar outros membros da equipe para que

possam executar outras funções dentro do projeto.

Terminar o projeto antes da data prevista 0,1 0,7 0,07 +

1 A Informar os stakeholders à mudança de prazo do projeto.

O software não executar corretamente no ambiente de produção

0,3 0,5 0,15 -1 1.4 Implementação E Configurar o ambiente de desenvolvimento igual o ambiente de produção

Satisfação dos beneficiários 0,3 0,7 0,21

+

1

A


Risco

Prob

abili

dade

Impa

cto

P X

I

Influ

ênci

a C

ód. W

BS

Devilerable

Estr

atég

ia

Respostas ao Risco

Satisfação da rede credenciada 0,3 0,7 0,21

+

1

A

Estimativas incorretas de prazo das atividades

0,5 0,7 0,35 -11.11.21.3

Gerenciamento do Projeto


Requisitos

E

Buscar as melhores práticas de estimativas de prazo e treinar a equipe.

Falha de comunicação entre os envolvidos de cada escritório

0,5 0,9 0,45 -1 1.21.3


Requisitos E

Usar canais de comunicação que apresentem maior interatividade entre o emissor e o receptor da mensagem, tais como, vídeo conferência e tele conferência.

A empresa fornecedora abandonar o projeto 0,1 0,9 0,09 -1 1.4

Implementação E

Definir critérios de seleção de fornecedores referentes à qualidade dos serviços prestados. Conhecer o fornecedor através de seus clientes.

QUADRO 4 – Plano de Respostas aos Riscos


8. Plano das Áreas de Gerenciamento do Projeto

8.1 Plano de Gerenciamento do Escopo

8.1.1 Descrição dos Processos de Gerenciamento de Escopo

Iniciação: autoriza o projeto ou fase.

Planejamento do Escopo: desenvolvimento da declaração escrita do escopo

como base para decisões futuras do projeto.

Detalhamento do Escopo: subdivisão dos principais subprodutos do projeto

em componentes menores e mais manejáveis.

Verificação do Escopo: formalização da aprovação do escopo do projeto.

Controle de Mudanças de Escopo: controla as mudanças do escopo do

projeto.

8.1.2 Sistema de Controle de Mudança de Escopo

As mudanças de escopo serão identificadas através do documento de

Solicitação de Mudança de Escopo. Este documento deverá ser preenchido pelo

responsável a requisição de mudança de escopo e entregue ao gerente de projeto.

O gerente de projeto fará um estudo de impacto da mudança de escopo no projeto,

quanto ao tempo, custo e riscos, o qual será apresentado para o comitê executivo. O

comitê executivo será o responsável pela aprovação e priorização das mudanças de

escopo.

Solicitação demudança de

escopo

Análise e estudodo impacto no

projeto

Aprovação eprioridades damudança de

escopo FIGURA 5 – Fluxo do Controle de Escopo

8.1.3 Priorização das Mudanças de Escopo

As mudanças de escopo serão priorizadas conforme critérios a seguir:


Prioridade Identificação Quando se Aplica Baixa 0 Mudança a ser implementada ao término do projeto; Média 1 Mudança sem impacto no projeto, no entanto deve ser

aplicada antes do término do projeto; Alta 2 Mudança imediata e imprescindível para continuidade do

projeto; QUADRO 5 – Critérios para Priorização de Mudanças de Escopo

8.1.4 Gerenciamento das Configurações

Depois de aprovada uma alteração de escopo, a declaração do escopo, assim

como, o cronograma, o custo e os riscos serão atualizados no plano do projeto. A

mudança de escopo e seus impactos no projeto serão apresentadas à equipe. Os

quais farão as alterações necessárias nos documentos técnicos do produto.

Mudança deEscopo

Atualização noPlano do Projeto

Atualização nosdocumentostécnicos do

produto

Apresentação damudança a equipe

do projeto

FIGURA 6 – Fluxo de Gerenciamento de Configurações

8.1.5 Freqüência de Avaliação do Escopo do Projeto

O escopo do projeto será avaliado ao término de cada fase do ciclo de vida

projeto definido na WBS, conforme fluxo abaixo.

FIGURA 7 – Fluxo para Verificação de Escopo 8.2 Plano de Gerenciamento do Tempo

8.2.1 Descrição dos Processos de Gerenciamento de Tempo

Definição das Atividades: identifica as atividades específicas que devem ser

realizadas para produzir os diversos subprodutos do projeto.

Plano do Projeto

Controle do Projeto

Iniciação Arquitetura dos requisitos

Implementação do Sistema

Verificação do Escopo


Seqüenciamento das Atividades: identifica e documenta as relações de

dependência entre as atividades.

Estimativa de Duração das Atividades: estima a quantidade de períodos de

trabalho que serão necessários para a implementação de cada atividade.

Desenvolvimento do Cronograma: analisa a seqüência e as durações das

atividades, e os requisitos de recursos para criar o cronograma do projeto.

Controle do Cronograma: controla as mudanças no cronograma do projeto.

8.2.2 Sistema de Controle de Mudança de Prazos

As mudanças de prazos podem ser identificadas pelo gerente do projeto ou

definidas pelo patrocinador ou cliente do projeto. O desempenho e progresso do

cronograma do projeto, acompanhado pelo gerente do projeto, será controlado

através da técnica EVM - Earned Value Management,

Depois de identificadas, as mudanças de prazo serão analisadas pelo gerente

do projeto. O resultado da análise será apresentado ao comitê de executivo, o qual

será responsável pela aprovação da mesma. Depois de aprovada a mudança de

prazo, o cronograma do projeto será atualizado e apresentado à equipe do projeto e

stakeholders.

8.2.3 Freqüência de Avaliação do Prazo do Projeto

Os prazos do projeto serão avaliados semanalmente durante a execução do

projeto, ou sempre que houver uma mudança no escopo ou no custo do projeto

aprovado pelo comitê executivo.


8.2.4 Impacto das Mudanças da Programação no Projeto

Os impactos das mudanças de tempo serão calculados com base no

cronograma atual levando em consideração as alterações de custo e qualidade do

projeto. Os stakeholders serão relatados a cada mudança de tempo do projeto.


8.3 Plano de Gerenciamento do Custo

8.3.1 Descrição dos Processos de Gerenciamento de Custo

Planejamento dos Recursos: determina quais recursos (pessoas,

equipamentos, materiais) e que quantidade de cada deve ser usada para

executar as atividades do projeto.

Estimativa dos Custos: desenvolve uma estimativa dos custos dos recursos

necessários à implementação das atividades do projeto.

Orçamento dos Custos: aloca as estimativas de custos globais as atividades

individuais de trabalho.

Controle dos Custos: controla as mudanças no orçamento do projeto.

8.3.2 Freqüência de Avaliação do Orçamento do Projeto

Os custos do projeto serão avaliados quinzenalmente durante a execução do

mesmo, ou sempre que houver uma mudança no escopo ou no prazo do projeto

aprovado pelo comitê executivo.

8.3.3 Controle dos Custos do Projeto

O controle dos custos do projeto serão administrados pelo gerente do projeto

através da técnica de técnica EVM - Earned Value Management.

8.3.4 Impacto das alterações nos Custos do Projeto

Os impactos das mudanças de custo serão calculados com base no

cronograma atual levando em consideração as alterações de tempo e qualidade do

projeto. Os stakeholders serão relatados a cada mudança de custo do projeto.


8.4 Plano de Gerenciamento de Risco

8.4.1 Descrição dos Processos de Gerenciamento de Risco

Plano de Gerência do Risco: decide como abordar e planejar as atividades

de gerência de risco para um projeto.

Identificação do Risco: determina quais riscos podem afetar o projeto e

documenta suas características.

Análise Qualitativa de Risco: realiza uma análise qualitativa dos riscos e as

condições para priorizar seus efeitos nos objetivos do projeto.

Análise Quantitativa do Risco: mede a probabilidade e as conseqüências

dos riscos e estima suas implicações para os objetivos do projeto.

Plano de Respostas ao Risco: desenvolve procedimentos e técnicas para

melhorar as oportunidades e reduzir as ameaças para os objetivos do projeto.

Monitorando e Controlando Risco: monitora os riscos residuais, identifica

novos riscos, executa planos de redução de risco e avalia sua eficácia

durante toda o ciclo de vida do projeto.

8.4.2 Identificação dos Riscos

A identificação de riscos envolve determinar e documentar os riscos que

podem afetar positivamente ou negativamente os objetivos do projeto. Neste projeto

utilizaremos algumas técnicas conforme descrito abaixo:

Reuniões: conversas com a equipe técnica do projeto utilizando a técnica de

Brainstorming para identificação de riscos técnicos.


Análise de SWOT: reunião com os principais stakeholders do projeto

utilizando a técnica Análise de SWOT, com o objetivo de identificar as forças,

fraquezas, oportunidades e ameaças para os objetivos do projeto.

Análise Histórica de Projetos Semelhantes: comparar projetos

semelhantes para identificação dos riscos.

8.4.3 Qualificação dos Riscos

Os riscos identificados serão qualificados na sua probabilidade de ocorrência

e impacto dos resultados, conforme a seguir:

Probabilidade de Ocorrência

Classificação Peso Fator de Maturidade

Fator de Complexidade

Fator de Dependência

Fator de Estabilidade

Pouco Provável 0,1

Domínio total da tecnologia / processo

Simples em relação ao ambiente atual

Totalmente sob controle da equipe do projeto

Fatores externos não irão afetar o projeto

Baixo

0,3

Conhecimento considerável da tecnologia / processo (<25%)

Pouco complexo em relação ao ambiente atual

Depende de produto / serviço padrão de fornecedor externo à organização

Fatores externos irão requer pequenas mudanças (<25%)

Médio

0,5

A tecnologia / processo é relativamente desconhecida (<50%)

Moderadamente complexo em relação ao ambiente atual

Depende de um fornecedor externo à organização que deverá fazer pequenas modificações no produto / serviço

Fatores externos irão requer mudanças (<50%)

Alto

0,7

A tecnologia / processo é significativamente desconhecida

Significativamente complexo em relação ao ambiente atual

Depende do desenvolvimento de um produto / serviço novo por

Fatores externos irão requerer mudanças


Classificação Peso Fator de Maturidade

Fator de Complexidade

Fator de Dependência

Fator de Estabilidade

(<75%) um fornecedor externo à organização

significativas (<75%)

Muito Alto

0,9

Estado da arte, alguma pesquisa deverá ser realizada

Extremamente complexo em relação ao ambiente atual

Depende da descoberta do produto / serviço por um fornecedor externo à organização

Fatores externos irão requerer mudanças constantes e significativas

Impacto nos Resultados

Classificação Peso Fator capacidade Fator político Fator Custo

Fator Cronograma

Insignificante

0,1

Sem conseqüências, ou conseqüências mínimas.

Pode ocasionar algum desconforto no cliente ou na organização

Orçamento não excedido

O impacto pode ser compensado pelas folgas

Baixo

0,3 Pequena redução na capacidade (até 10%)

Solicitado justificativas antes da abertura de uma investigação / análise

Custo estimado supera 1 a 5%

Pequenas mudanças no cronograma (atraso < 5%)

Médio

0,5

Alguma redução na capacidade (até 25% dos requerimentos não cumpridos)

Opinião pública desfavorável


Mudança razoável no cronograma (atraso < 10%)

Alto

0,7

Redução significativa na capacidade (50% dos requerimentos não cumpridos)

Cortes no orçamento devido à retribuição política


Mudança significativa no cronograma (atraso < 25%)

Muito Alto

0,9 Objetivos técnicos não podem ser atingidos

Pressão para substituição de altos executivos

Custo estimado supera 50%

Mudança catastrófica no cronograma (atraso acima de 25%)


Influência do Impacto

Classificação Diretrizes

+1 (Positivo) O risco deve ser classificado como positivo quando contribuir favoravelmente para o projeto

-1 (Negativo) O risco deve ser classificado como negativo quando contribuir desfavoravelmente para o projeto

8.4.4 Estratégias para Tratamento dos Riscos

Para o tratamento dos riscos serão utilizadas as seguintes estratégias:

Estratégia Descrição Critérios para adoção

Evitar Esta estratégia é adotada quando se pode evitar a ocorrência do risco ou até mesmo eliminá-lo.

Sempre que possível, deve-se adotar esta estratégia, desde que as tolerâncias de custo e escopo sejam mantidas.

Aceitar Esta estratégia é adotada quanto o custo de qualquer alternativa é muito alto e a probabilidade e magnitude do impacto do risco é baixo.

Quando a exposição ao risco (fator PI) for inferior a 0,1 e a somatória de todos os custos estimados dos riscos que irão ser aceitos for inferior a 3% do total do projeto.

Mitigar Esta estratégia é adotada para reduzir a ameaça reduzindo a probabilidade de ocorrência ou magnitude de impacto do risco. A minimização de um risco é o método mais comum empregado nos projetos. O time do projeto deve decidir sempre baseada na análise de custo benefício, uma vez que a minimizar um risco não o remove completamente.

Deve-se adotar esta estratégia quando o risco não puder ser evitado, aceito ou transferido. Neste caso, deve-se obrigatoriamente discriminar um plano de ações detalhado.

Transferir Neste caso, o mais comum é transferir parte do projeto para o ambiente externo.

Quando for possível repassar o risco para um fornecedor que lide melhor com a situação. O custo desta transferência deve estar previsto no orçamento de ações para esta área.


8.4.5 Sistema de Mudanças de Riscos

Geralmente as mudanças do planejamento de risco são identificadas através

das mudanças geradas no escopo, prazo, custo e/ou qualidade do projeto. Depois

de identificado o risco, o gerente do projeto fará as análises qualitativa e quantitativa

no risco adotando a melhor estratégia para minimizar seu impacto. Esta análise será

apresentada e discutida em primeiro lugar junto a equipe do projeto e posteriormente

ao comitê executivo.

8.4.6 Freqüência de Avaliação dos Riscos do Projeto

Os riscos do projeto serão avaliados ao término de cada fase, junto com a

verificação do escopo detalhado no plano de gerenciamento de escopo, ou sempre

que forem aprovados mudanças de escopo, custo ou prazo do projeto.


8.5 Plano de Gerenciamento de Aquisições

8.5.1 Descrição dos Processos do Gerenciamento de Suprimento

Planejamento das Aquisições: determinar o que contratar e quando.

Preparação das Aquisições: documentar os requerimentos do produto e

identificar os fornecedores potenciais.

Obtenção de Propostas: obter propostas de fornecimento conforme

apropriado a cada caso (cotações de preço, cartas-convite, licitação).

Seleção de Fornecedores: escolher entre os possíveis fornecedores.

Administração dos Contratos: gerenciar os relacionamento com os

fornecedores.

Encerramento do Contrato: completar e liquidar o contrato incluindo a

resolução de qualquer item pendente.

8.5.2 Definição da Aquisição

O desenvolvimento do projeto contempla a aquisição de um produto de

software de ERP com os módulos financeiro e de recursos humanos e também a

contratação do serviço de customização do software ERP para as necessidades da

empresa.

O comitê executivo e usuários chaves do projeto serão responsáveis pelo

desenvolvimento do documento Request for Proposal (RFP) para aquisição do

software de ERP. E o gerente do projeto será responsável pelo documento Request

of Proposal (RFP) para contratação dos serviços de customização do software.


As propostas serão recebidas e tabuladas conforme planilha de avaliação de

propostas, as quais serão pontuadas e receberão uma nota final. Os dois

fornecedores melhores pontuados serão selecionados e participarão da fase final de

seleção que será baseada exclusivamente no critério de preço.

FIGURA 8 – Processo de Aquisição

8.5.3 Responsabilidade do contrato

Os acordos contratuais serão celebrados pelo Comitê Executivo e pelo

gerente do projeto. Quaisquer alterações contratuais deverão ser antes aprovadas

pelo Comitê Executivo e pelo gerente do projeto antes de iniciarem sua vigência.

8.5.4 Critério de Decisão

Para aquisição do software de ERP e dos serviços de customização do

software serão adotados os seguintes critérios para seleção:

Apresentação da proposta: Identificar se a proposta está de acordo com o

formato exigido na RFP e avaliar o visual.

Capacidade da Empresa: Analisar o tempo da empresa e do produto no

mercado e a saúde financeira da empresa.

Capacidade Técnica: Analisar o entendimento da necessidade, ambiente

tecnológico, quantidade de recursos requeridos ao projeto, cronograma

detalhado, prazo, certificações e parcerias.


Condições Comerciais: Avaliar a curva “S”, o preço e as condições de

pagamentos das propostas apresentadas.

8.5.5 Tipo de Contrato

O contrato utilizado para aquisição do software de ERP será de preço fixo

através de um valor negociado junto ao fornecedor ou fabricante.

Para os serviços de customização ao ERP deverá reger um contrato de preço

unitário, ou seja, serão cobrados os valores horas dos profissionais envolvidos na

customização do software.


8.6 Plano de Gerenciamento da Qualidade

8.6.1 Descrição dos Processos de Gerenciamento da Qualidade

Planejamento da Qualidade: identifica quais padrões de qualidade são

relevantes para o projeto e determinar a forma de satisfazê-los.

Garantia da Qualidade: avalia periodicamente o desempenho geral do

projeto buscando assegurar a satisfação dos padrões relevantes de

qualidade.

Controle da Qualidade: monitora os resultados específicos do projeto para

determinar se eles estão de acordo com os padrões de qualidade relevantes e

identificar as formas para eliminar as causas de desempenhos insatisfatórios.

8.6.2 Política de Qualidade Corporativa

Na ausência de uma política de qualidade corporativa, serão adotados os

padrões de qualidade utilizados especificamente pelo departamento de tecnologia

da informação para avaliação de software.

Funcional

O produto do software deverá satisfazer as especificações de requisitos,

cumprindo os objetivos visados pelo usuário chave.

Propõe-se a fazer o que é apropriado: Deve se comportar conforme

especificações definidas pelos usuários chave.

Faz o que foi proposto de forma correta: Imune a falhas operacionais.


Evita acesso não autorizado aos dados do sistema: Possui uma

administração de usuários e definição de acesso através de grupos de

usuários ou níveis de acesso.

Uso do produto

O produto do software deverá ser de fácil utilização a qualquer usuário do

mesmo. Não requerendo nenhum treinamento especifico em qualquer outra

ferramenta para a utilização correta do produto.

É fácil entender o conceito e a aplicação: Máximo de 40 horas por módulo

do software para treinamento dos usuários.

É fácil aprender a usar: Máximo de 40 horas por módulo do software para

treinamento dos usuários.

É fácil de operar e controlar: Acesso inteligente e rápido as telas.

Manutenção

O produto do software deverá ser construído e documentado de forma a

tornar fácil a manutenção e a implementação de novos recursos, e minimizar o

esforço exigido para localizar e reparar erros em um programa.

É fácil de encontrar uma falha, quando ocorre: Possua tratamento de erros

e relatórios dos erros ocorridos.

É fácil modificar e adaptar: Apto a customização de telas e criação de

relatórios gerenciais por usuários comuns.

Não há grande risco quando se faz alterações: Possua controle de versão.


É fácil testar quando se faz alterações: Possuir documentos de versão para

testar as modificações realizadas.

Confiável

O produto do software deverá executar as funções pretendidas com a

precisão exigida.

Imune a falhas: Disponibilidade de 24 horas por dia e 7 dias por semana.

Capaz de recuperar dados em caso de falha: Controle de transações, e

segurança dos dados.

8.6.3 Padrões adotados ao Projeto

Para o gerenciamento do projeto serão adotados os padrões usuais do

departamento de tecnologia da informação da empresa Sempre Saudável baseada

nas práticas de gestão de projetos do PMI.

8.6.4 Freqüência de Avaliação dos Requisitos de Qualidade

A avaliação dos requisitos de qualidade do projeto será realizada a cada

semana durante a execução do projeto.

8.6.5 Controle da Qualidade

Para controle da qualidade será utilizada a técnica de inspeção baseado nos

requerimento e padrões de qualidade do projeto, inclui as atividades tais como

medir, examinar e testar a fim de eliminar as causas de resultados insatisfatórios.


8.6.6 Garantia da Qualidade

Para garantir a qualidade do projeto serão aplicados atividades de auditoria

da qualidade com o objetivo de identificar as lições aprendidas que conduzem ao

melhor desempenho desse e / ou de outros projetos.


8.7 Plano de Gerenciamento da Comunicação

8.7.1 Descrição do Processo de Gerenciamento das Comunicações

Planejamento das Comunicações: determina as informações e

comunicações necessárias para os interessados: quem necessita de qual

informação, quando necessitarão dela e como isso será fornecido.

Distribuição das Informações: disponibiliza as informações necessárias

para os interessados do projeto da maneira conveniente.

Relato de Desempenho: coleta e dissemina as informações de desempenho.

Inclui relatórios de situação, medição de progresso e previsões.

Encerramento Administrativo: reuni, gera e dissemina informações para

formalizar a conclusão de uma fase ou de todo o projeto.

8.7.2 Tipos de Comunicação

O plano de comunicação contempla três tipos de comunicação:

Mandatória: geralmente inclui os tipos de comunicação que são necessárias

na organização e durante o desenvolvimento de um projeto. Exemplo:

relatório de status.

Informativa: o que as pessoas precisam saber para fazer seus trabalhos.

Exemplo: os entregáveis do projeto, requerimento das atividades do projeto,

mudança de escopo.

Marketing: informação motivacional, utilizada para motivar e informar a

equipe de projeto. Exemplo: newsletter, elogios, contagem regressiva para o

fim do projeto, etc.


8.7.3 Atas de Reunião

A ata de reunião é um documento que formaliza os assuntos discutidos em

uma reunião. Para cada reunião será gerada um ata de reunião durante a mesma e

assinada por todos os participantes ao final da reunião.

O modelo utilizado no projeto identifica os participantes, os assuntos

discutidos e as pendências geradas.

8.7.4 Relatórios do Projeto

Relatório Descrição

Relatório de Status O relatório de status tem o objetivo de informar o atual status do projeto em relação ao planejado, fazendo referência ao tempo e custo.

Relatório de Mudanças O relatório de mudanças descreve as mudanças aprovadas e suas conseqüências à equipe do projeto.

Relatório de Desempenho

O relatório de desempenho é utilizado para apresentar a equipe a comparação entre o planejado e o realizado no projeto, e a partir dessas informações identificaremos as lições aprendidas.

Comunicado Geral O relatório de comunicação geral tem como objetivo expor a importância, o benefício e o andamento do projeto as demais áreas da empresa.

Previsão de Custo e Prazo

O relatório de previsão de custo e prazo apresenta as estimativas de custo e prazo para a conclusão do projeto e o quanto será necessário para a conclusão do projeto.


8.7.5 Plano de Comunicação

Deliverable Tipo Público Alvo Método de

Distribuição

Freqüência de

Distribuição Responsável

Relatório de Status Mandatória Patrocinador Reunião Mensal Josué Khurt Mickrer

Relatório de Status Mandatória Comitê Executivo

Usuário-chave

E-mail Semanal Josué Khurt Mickrer

Previsão de Custo e Prazo

Mandatória Patrocinador

Comitê Executivo

Reunião Quinzenalmente Josué Khurt Mickrer

Relatório de Mudanças

Informativa Patrocinador

Equipe Técnica

Comitê Executivo

E-mail e Reunião Sempre que houver mudanças

Josué Khurt Mickrer

Relatório de Desempenho

Mandatória Patrocinador

Comitê Executivo

Reunião Término do Projeto Josué Khurt Mickrer

Comunicado Geral Marketing Funcionários Intranet Quinzenalmente Josué Khurt Mickrer


8.8 Plano de Gerenciamento de Recursos Humanos

8.8.1 Descrição do Processo de Gerenciamento de Recursos Humanos

Planejamento Organizacional: identificar, documentar e designar as

funções, responsabilidades e relacionamentos de reporte dentro do projeto.

Montagem da Equipe: conseguir que os recursos humanos necessários

sejam designados e alocados ao projeto.

Desenvolvimento da Equipe: desenvolver habilidades individuais e do grupo

para aumentar o desempenho do projeto.

8.8.2 Avaliação dos Resultados da Equipe do Projeto

O gerente do projeto é o responsável por avaliar o desempenho da equipe em

geral e a participação individual de cada membro da equipe.

Os resultados globais do trabalho da equipe serão apresentados pelo gerente

do projeto em reunião de pauta com a presença de todos os integrantes da equipe.

Haverá também um feedback individual para cada membro da equipe onde será

apresentada a performance individual em comparação da performance esperada.

8.8.3 Treinamento

Os treinamentos serão aplicados para a equipe conforme as avaliações de

desempenho ou por necessidades específicas do projeto. Havendo a necessidade

de treinamentos ministrados por fornecedores, apenas um integrante sênior realizará

o curso e posteriormente aplicará o treinamento aos demais membros da equipe.


8.8.4 Bonificação

Não existem procedimentos de bonificação para este projeto.

8.8.5 Freqüência de Avaliação Consolidada dos Resultados da Equipe

As avaliações de performance e resultados da equipe serão aplicadas

quinzenalmente e podendo sobre alterações conforme desempenho da equipe.


8.9 Controle Integrado de Mudanças

As mudanças do projeto poderão ser embasadas com base no relatório de

desempenho e / ou através de solicitações de mudanças formalizadas.

As solicitações de mudança somente serão avaliadas se destinadas

diretamente ao gerente do projeto. As solicitações poderão ser feitas verbalmente ou

por escrito através do formulário de requisição de mudança. Se feitas verbalmente

deverão ser traduzidas, descritas no formulário de requisição de mudanças e a

assinada pelo requisitante.

O gerente do projeto e a equipe técnica serão os responsáveis por avaliar e

analisar os impactos decorrentes da requisição de mudança. Esta análise deverá

apresentar as variações de custo, prazo e qualidade decorrente da implementação

da mudança.

Após análise e avaliação da possível mudança, o gerente do projeto

apresentará, para o responsável pela requisição, os impactos decorrentes da

mudança. Nesta reunião será discutida e negociada a viabilidade de seguir com a

solicitação de mudança para aprovação para o grupo de controle de configuração,

CCB - Configuration Control Board.

Para aprovação das solicitações de mudança será criado um grupo de

controle de configuração, CCB - Configuration Control Board. O grupo de controle de

configuração será composto por usuários-chave, equipe técnica e membros do


comitê executivo do projeto. Dependendo do nível de impacto no projeto, as

solicitações de mudanças poderão ser implementadas de imediato ou somente após

aprovação do grupo de controle de configurações.

As requisições de mudanças serão apresentadas semanalmente para

aprovação do CCB. Quando ocorrer emergências, o gerente de projetos poderá

requisitar uma reunião em caráter de urgência para aprovação da mudança com

quorum mínimo de três pessoas.

As mudanças aprovadas resultarão em atualizações do plano do projeto. Os

stakeholders serão informados conforme descrito no plano de gerenciamento da

comunicação sobre as mudanças ocorridas, o local onde as descrições das

mudanças podem ser encontradas e seus impactos.


9. CONCLUSÃO

Os softwares de ERP - Enterprise Resource Planning – automatizam os

processos de gestão empresarial, sendo em sua maioria flexíveis e customizáveis as

necessidades do cliente. Este produto é o sonho de muitas empresas e geralmente

é encarado como a solução para todos os problemas da organização. Mas é aí que

mora o perigo. A implantação de um ERP significa mudança de cultura para a

organização, os processos usados até então serão mudados ou deixarão de existir,

as atividades realizadas por diversas pessoas poderão agora ser realizada somente

por uma ou nenhuma pessoa, as atividades de demoravam horas poderão agora

demorar segundos. Tais mudanças, assim como qualquer outra mudança de cultura

organizacional pode ser traumática e acarretar conseqüências, especialmente

resistências por parte das pessoas envolvidas diretamente ao projeto.

Qualquer mudança de cultura em uma organização deve acontecer de forma

planejada, havendo consenso entre as partes envolvidas. Portanto, um projeto de

implantação do software ERP deve iniciar muito antes da aquisição do produto.

Precisamos primeiro conhecer as necessidades, os interesses, os anseios e as

inseguranças das pessoas envolvidas, este é um grande passo para o sucesso do

projeto de implantação de um ERP. Em seguida, identificar as pessoas estratégicas

ao projeto e conquistar seu comprometimento. Estas pessoas serão as responsáveis

por envolver os demais stakeholders.


Outra atividade muito importante para o sucesso do projeto é conhecer,

identificar e documentar todos os processos atuais da organização e que serão

automatizados com o software ERP, estas informações terão grande valor e serão

determinantes durante no processo de seleção do produto. A seleção do fornecedor

e / ou do produto deve se basear aos requisitos pré-determinados pela equipe ou

usuários -chave do projeto.

O desenvolvimento de um planejamento adequado e o apoio da alta gerência

permitirá ao projeto maior precisão na sua execução e o controle efetivo de suas

atividades. Por fim, a comunicação de todas as ocorrências positivas ou negativas

ao projeto durante o seu ciclo de vida e o poder de influenciar do gerente de projeto

serão fundamentais para a consolidação das expectativas dos stakeholders.


10. APÊNDICES

Apêndice 1 – Modelo de Ata de Reunião


Apêndice 2 – Modelo de Requisição de Mudança no Projeto


Apêndice 3 – Relatório de Progresso do Projeto


Apêndice 4 – Lições aprendidas


Apêndice 5 – Documento de Encerramento de Projeto


11. GLOSSÁRIO

CCB (Changing Control Board): Um grupo de interessados (stakeholders)

formalmente constituído, responsável pela aprovação ou rejeição de mudanças às

Bases de Referência do projeto.

CRM (Customer Relationship Management): software para gerenciamento do

relacionamento da organização com seu cliente.

Curva S: Representação gráfica dos custos, horas trabalhadas ou outras

quantidades acumuladas, ao longo do tempo. O nome deriva do formato da curva

similar à letra S (mais deitada no início e término, inclinado na parte intermediária)

produzida por um projeto que inicia lentamente, acelera e depois reduz seu ritmo.

Deliverables: Algo mensurável, tangível, resultado verificável, resultado, ou item que

deva ser produzido para completar um projeto ou parte de um projeto. Usualmente

mais usada para um produto a ser aprovado pelo patrocinador ou cliente.

ERP (Enterprise Resource Planning): Os ERP’s são softwares que permitem a

existência de um sistema de informação unificado para todas as áreas (Finanças,

RH, Marketing, Produção, etc,) de uma empresa. Ele integra e promete um banco de

dados único, uma aplicação e uma interface para toda a empresa melhorando o seu

Business Process.

EVM (Earned Value Management): Metodologia de gerenciamento utilizada para

integrar o escopo, o cronograma e os recursos para medir objetivamente o

desempenho e o progresso do projeto.

Milestones: Principais marcos do projeto para controle dos produtos de entrega do

projeto.


PERT (Program Evaluation and Review Technique): técnica que apresenta

informação estatística com referência às incertezas a enfrentar, na execução das

diversas atividades de um projeto.

PMBOK (Project Management Book of Knowledge): Guia do conjunto de

conhecimentos em gerenciamento de projetos desenvolvido pelo PMI.

PMI (Project Management Institute): Organização mundial sem fins lucrativos voltada

ao gerenciamento de projetos.

SOW (Statement of Work): Descreve o(s) item(ns) a ser(em) adquirido(s) com

suficiente detalhe para permitir uma avaliação dos fornecedores quanto à sua

capacidade de atender o edital.

Stakeholders: São todas as pessoas e organizações que têm interesses ou que são

direta e ou indiretamente afetados (penalizados ou o beneficiados) pelo projeto

SWOT: é uma ferramenta de gestão muito utilizada por empresas privadas como

parte do planejamento estratégico dos negócios. O termo SWOT vem do inglês e

representa as iniciais das palavras Streghts (forças), Weaknesses (fraquezas),

Opportunities (oportunidades) e Threats (ameaças).

WBS: Working Breakdown Structure - Decomposição hierárquica orientada à

entrega do trabalho a ser executado pela equipe do projeto para atingir os objetivos

do projeto e criar as entregas necessários.


REFERÊNCIAS BIBLIOGRÁFICAS

SOUZA, C. A.; SACCOL, A. Z., SISTEMAS ERP NO BRASIL: Teoria e Casos. São

Paulo, Atlas, 2003.

Heldman, KIM., GERENCIA DE PROJETOS: Guia para o exame oficial do PMI, São

Paulo, Campus, 2003

Project Management Institute., Guide to the Project Management Body of knowledge

- PMBOK. ed. 2000.

DOCUMENTOS ELETRÔNICOS

www.pmi.org – Site da empresa Professional Management Institute, possui materiais

referente a gerenciamento de projetos. Data de acesso: 15/06/2005.

http://www.rm.com.br – Site de empresa de desenvolvimento de softwares de gestão

empresarial. Data de acesso: 15/06/2005.

http://br.groups.yahoo.com/group/PMI-SP - Grupo de discussão do capítulo PMI de

São Paulo, este grupo possui materiais e assuntos referentes a gerenciamento de

projetos. Data de acesso: 01/07/2005.

Documents

Plano de Projeto para Implantação de Software · PDF fileSensu em Gestão de Projetos segundo as ... 8.5 Plano de Gerenciamento de Aquisições ... seleção do fornecedor e produto