View
461
Download
3
Category
Preview:
Citation preview
Gerenciamento de Aquisições em Projetos
São Paulo, GEEP – Turma 41
Droneway: Software para Controle de DronesGrupo 04
Prof. Marco Coghi
Diretores
GEEP – T41 Prof. Marco Coghi
Droneway: Software para Controle de Drones
Anderson Rezende
Andrey P. Melo
Mateus GodinhoCarlos Lederman
Leonardo de Oliveira Costa
Idalino Pereira
AGENDA
Apresentação do Projeto e Justificativa
EAP/WBS com a análise de make or buy
Critérios Make or Buy
Mapa das Aquisições
DT – Declaração do Trabalho
WBS do Contrato
Critérios de Avaliação
Documentos de Aquisição e Tipo do Contrato
Fluxograma da Condução da Concorrência
Etapas de Monitoramento e Controle
Etapa de Encerramento
Apresentação do Projeto
Nosso negócio é a exploração do mercado de software para o controle de drones.
Os drones de mercado são vendidos com softwares básicos, sem customização para clientes com necessidades específicas; queremos entrar nesse nicho de oportunidades.
JUSTIFICATIVA
Empresas de vendas e entrega de refeições (food delivery) faturam R$ 351
milhões anuais e apresentam crescimento anual da ordem de 30%. Requerem
serviços de entrega rápida, com baixo custo e qualidade.
Empresas de comércio eletrônico faturam R$ 28,8 bilhões anuais,
apresentam mais de 51 milhões de consumidores com crescimento anual de
28%. A redução no prazo e custo de entrega é altamente desejável.
Ampliar opções de entrega é caminho para rentabilizar comércio
eletrônico. Custo do frete é considerado desafio para lojas virtuais
(FecomercioSP)
A logística no comércio eletrônico impacta os dois fatores mais
valorizados pelo cliente virtual: preço total do pedido e tempo de espera entre
a compra e a chegada do produto.
Os clientes de comércio eletrônico começaram a preferir fornecedores
ausência de custo de entrega, ou menores custos e prazos de entrega.
A taxa de crescimento das vendas de medicamentos no Brasil gira em torno
de 13% ao ano, sendo seis vezes superior ao desempenho dos mercados
desenvolvidos (IMS Health).
Estrutura Analítica do Projeto – EAP/WBS
Legenda:
M: Make
B: Buy:
GerenciamentoM
PesquisaM
DesenvolvimentoB
EncerramentoM
ControleM
1.1 TAP
1.3 Plano gerenciamento
de Comunicação
1.2 Plano gerenciamento
de Escopo
1.4 Declaração de
Escopo
1.6 Plano gerenciamento
de Tempo
1.5 WBS
5.1 Termo de Aceite
5.3 Documentos do
Projeto
5.2 Lições Aprendidas
4.4 Atualização dos
documentos
4.5 Homologação
2.1 Fornecedores
2.3 Requisitos Técnicos
(HW/SW)
2.2 Tecnológica
2.4 Requisitos Legais
2.6 Infaestrutura
2.5 Requisitos
Tributários/Fiscais
3.1 Design Funcional
3.3 Construção
3.2 Design Técnico
3.4 Validação
3.5 Documentação do
Software
4.1 Reuniões
4.3 Relatórios
4.2 Teste
4.6 Revisão
4.7 Aceitação
Eliminadas na revisão da WBS
Critérios Make / Buy1. Todo o software para o controle de drones e sua documentação será
contratada de um terceiro, a ser escolhido via RFI e RFP (fase de desenvolvimento). Razões:
- Necessidade de Absorção Tecnológica
- Necessidade de Fornecimento Especializado
- Necessidade de Cumprimento de Prazos
- Falta de know-how da equipe interna
- Existência de fornecedores com a competência necessária
- Melhor controle de custos de desenvolvimento
- Aproveitamento interno do conhecimento já adquirido pelo fornecedor
2. Todas as demais fases do projeto serão executadas com recursos internos
Mapa das AquisiçõesItem da
WBS
Descrição Concorrentes Cronograma (vide slide
do cronograma)
Orçamento Critério Make/Buy
3.1 Design Funcional (a) 2/10 a 21/10 (b) B
3.2 Design Técnico (a) 22/10 a 10/11 (b) B
3.3 Construção Software
(a) 11/11 a 25/11 (b) B
3.4 Validação (a) 26/11 a 30/11 (b) B
3.5 DocumentaçãoSoftware
(a) 12/12 a 13/12 (b) B
(a): Fornecedor do Software para Drones
(b): valor contemplado no orçamento do projeto e no contrato
Estrutura Analítica do Projeto – EAP/WBSRevisada
Legenda:
M: Make
B: Buy:
GerenciamentoM
PesquisaM
DesenvolvimentoB
EncerramentoM
ControleM
1.1 TAP
1.3 Plano gerenciamento
de Comunicação
1.2 Plano gerenciamento
de Escopo
1.4 Declaração de
Escopo
1.6 Plano gerenciamento
de Tempo
1.5 WBS
5.1 Termo de Aceite
5.3 Documentos do
Projeto
5.2 Lições Aprendidas
4.4 Atualização dos
documentos
4.5 Homologação
2.1 Fornecedores
2.3 Requisitos Técnicos
(HW/SW)
2.2 Tecnológica
2.4 Requisitos Legais
2.6 Infaestrutura
2.5 Requisitos
Tributários/Fiscais
3.1 Design Funcional
3.3 Construção
3.2 Design Técnico
3.4 Validação
3.5 Documentação do
Software
4.1 Reuniões
4.3 Relatórios
4.2 Teste
Registro de Riscos RevisadoEventos de Risco Resposta ao Risco Momento da Resposta ao Risco
Não funcionamento adequado nos
testes de campo
Selecionar a empresa com o melhor
processo
Realizar testes de garantia de qualidade
durante e após a fabricação
SEL
ESP
Atraso na entrega pelo fato do
fornecedor estar atendendo demandas
acima da sua capacidade
Analisar histórico de fornecimento
Multa contratual
Diligenciar durante a fabricação
SEL
CONT
ADM
Indisponibilidade do ambiente de testes
do fornecedor
Avaliar o ambiente de testes do
fornecedor e checar sua disponibilidade
PQ
Fornecedor estrangeiro operando em
seu país de origem
Garantir a disponibilidade da equipe do
fornecedor no fuso horário brasileiro
PLAN / CONT
MOMENTOS: SEL: Seleção do Fornecedor; ESP:Especificações; CONT: Contrato; ADM:
Administração do Contrato; PQ: Pré-Qualificação; PL: Planejamento
Declaração de Trabalho (1)
Linha Escolhida do Mapa de Aquisições:
- OBJETIVO: Contratação de Empresa para o desenvolvimento de software para controle de drones
- ESCOPO: Software para 3 marcas de drones: Leica, Xfly e Fabris
- ESPECIFICAÇÃO TÉCNICA: - Software a ser desenvolvido em Java;
- Deverá permitir o controle do drone até a distância homologada pelo fabricante, e o auto-deslocamento a partir de coordenadas e início e fim de trajeto;
- o software deverá monitorar a carga das baterias e alertar, antes do vôo, as distâncias máximas a serem percorridas em função da carga disponível no momento;
- para os drones com sensor de proximidade, o software deverá evitar colisões;
- deverá incluir o Manual do Operador (um para cada marca de drone) para quem for operar o drone e Manual do Integrador (um para cada marca de drone) para quem for integrar o software com outras plataformas.
- PRAZO: 10 semanas
3.3 Construção
Declaração de Trabalho (2)
- QUALIDADE: O Gerente de Projeto da Contratada submeterá os entregáveis ao Gerente de Projeto da Contratante, o qual validará a qualidade junto à equipe da qualidade da Contratante.
- APROVAÇÃO DE MUDANÇAS: a Contratada somente executará demandas de mudanças após aprovação de orçamento e cronograma; o Gerente de Projeto da Contratante ficará com a responsabilidade de obter as aprovações internas e refletir no projeto e nas comunicações, eventuais atrasos.
- LOCAL DE TRABALHO: a contratada deverá acomodar seus recursos em ambiente externo à contratante, sendo que a infra-estrutura demandada por esses recursos serão responsabilidade da Contratada
- PAGAMENTO: a ser executado após a validação dos entregáveis, de acordo com o cronograma físico-financeiro presente no contrato
Declaração de Trabalho (3)
- CONTRATO: - cobrirá o desenvolvimento e a manutenção do software, garantindo a correção de defeitos e novas
funcionalidades desenvolvidas durante o contrato;
- deverá cobrir responsabilidades, exclusão de funcionalidades/ responsabilidades, e cronograma de entregas / pagamentos e penalidades/recompensas;
- exime a contratante de qualquer demanda trabalhista impetrada pelos recursos da contratada;
- a Contratada e o Contratante estabelecem a existência de um Gerente de Projeto dedicado com exclusividade a este projeto.
- Os critérios de classificação são de uso interno à contratante e não serão divulgados aos concorrentes; o objetivo dessa medida é evitar delongas na finalização do processo de seleção.
- RFP: este documento não descreverá os critérios de classificação, somente os de habilitação
WBS do Contrato de Desenvolvimento de Software
1. Escopo 2. Responsabilidades 3. Marcos 4. Penalidades 5. Encerramento
e Recompensas
1.1 Desenvolvimento do Software 2.1 da Contratada 3.1 Técnicos 4.1 Penalidades 5.1 Critérios de
1.1.1 Fluxograma do Sistema Aceitação
1.1.2 Especificação Funcional
1.2 Manutenção do Software 2.2 da Contratante 3.2 Financeiros 4.2 Recompensas
1.2.1 Termo de Compromisso
de fornecimento de atualizações
1.2.2 Termo de compromisso de correção
de bugs
1.3 Solicitações de Mudanças
Critérios Eliminatórios
- Capacidade Financeira
- Certidões Negativas com até 60 dias de validade
- Experiência comprovada no objeto do escopo em clientes de porte médio ou superior (através de carta dos clientes com data inferior a 6 meses)
- Equipe com pelo menos 1 elemento certificado pelo PMI ou com mais de 10 anos de experiência como Gerente de Projeto
- Equipe com pelo menos 1 elemento certificado em desenvolvimento de software Java/PHP
Critérios Classificatórios e Sistema de Pontuação
Critérios Classificatórios
Peso Nota Peso x Nota
Entendimento do Escopo 10Maturidade na Metodologia de Desenvolvimento utilizada 8
Preço 9
Prazo 7
Depoimentos dos Clientes 4
Documentos de Aquisição e Tipo de Contrato (1)
• Não vamos explicitar na DT os critérios de avaliação. Justificativa: evitar questionamentos do processo e do resultado pelos concorrentes
• Turn Key: o fornecedor do software o entregará pronto para uso, acompanhado dos manuais do usuário e do integrador
• Concorrência Privada
• Documentos de Aquisição: os concorrentes receberão carta-convite com a RFP contemplando o escopo do projeto e os critérios de habilitação (eliminatórios)
• Os concorrentes enviarão um e-mail ao setor de compras confirmando o recebimento da RFP
Documentos de Aquisição e Tipo de Contrato (2)
- Os concorrentes enviarão e-mail ao setor de compras
com as certidões e demais documentos exigidos de
forma digital, até a data limite especificada na RFP
- Os concorrentes que atenderem os critérios
eliminatórios, receberão e-mail solicitando a resposta
à RFP (contendo as propostas técnica e comercial),
até a data especificada na carta-convite.
- Ao final do processo, os concorrentes perdedores
receberão um e-mail de agradecimento pela
participação no processo e o vencedor receberá uma
convocação para a primeira reunião de
entendimento.
Fluxograma da Condução da Concorrência
Etapas de Monitoramento e Controle (1)
Processo de Fiscalização a ser Adotado- Respeito das partes ao contrato: semanalmente ocorrerão
reuniões de para validação de progressos e para se verificar se existem questões relacionadas a eventuais não aderências ao contrato, por qualquer das partes
- O fornecedor produzirá semanalmente um relatório de desempenho apresentando o que foi produzido e eventuais razões de não conformidade não solucionadas na comunicação diária
- O contratante emitirá semanalmente um boletim de medição, que servirá de base para o acompanhamento do projeto e para o pagamento mensal
Etapas de Monitoramento e Controle (2)
• O contrato contempla a apresentação ao contratante do fluxo do sistema antes do início dos trabalhos de programação, para que se mitiguem futuras solicitações de mudanças e discussões sobre o escopo do projeto nos momentos de validação das entregas
• ISO-25000 – o contrato prega aderência mínima a essa norma de qualidade de desenvolvimento de software, cuja validação será conduzida pela área da qualidade do contratante
Iniciação Planejamento ExecuçãoMonitoramento &
Controle
`--> TAP ´--> PGP ´--> Entrega terminada ´-->Entrega aceita
INTEGRAÇÃO
01-EPF: Encerrar Projeto ou Fase
AQUISIÇÕES
02- EA: Encerrar Aquisições
a) Modo Normal
Escopo Completado? N Exigir do Fornecedor a completude do Escopo
S
Pagamentos Efetuados? N Pagar os eventuais Saldos
S
Obrigações Cumpridas? N Exigir do Fornecedor os eventuais saldos de obrigações
S
Outras Pendencias? S Exigir do fornecedor quitar eventuais pendencias
N
Termo de Recebimento Definivo
b) Resilição
Fazer acordo entre as partes
c) Rescisão
Encerrar o contrato e pleitear ou pagar eventuais multas
Encerramento
´--> Produto
Encerramento das Aquisições
Etapas de Monitoramento e Controle (3)
Exemplo de Boletim de Medição
Id Fase da WBS Unidade PreçoPeso
P %
Qtdd
Planej
Qtdd
Realizada
Critério
C %
Avanço
Planejado
Avanço
Realizado%
1.1 Desenvolvimento de SW 100k 20 100k
1.1.1 Fluxograma do SistemaDiagramas
de Blocos500 10 20K
1.1.2 Especificação Funcional Folhas 100 40 80k
1.2 Contrato de Manutenção 50k 25 50k
1.2.1Termo de Compromisso de
fornecedimento de atualizações
Documento
Único1 100 25k
1.2.2Termo de compromisso de
correção de bugs
Documento
Único1 100 25k
Obs. O texto das fases é auto-explicativo
Controle de Aquisições – Passo a PassoIniciação Planejamento Execução Monitoramento & Controle Encerramento
`--> TAP ´--> PGP ´--> Entrega terminada ´-->Entrega aceita ´--> Produto
01 - MCTP: Controlar o
Trabalho do Projeto
02 - RCIM: Realizar o Controle
Integrado de Mudanças
03 - Validar Escopo
04 - Controlar Escopo
05 - Ccro - Controlar
Cronograma
06 - Cc: Controlar Custos
07- CQ: Controlar Qualidade
08 - Cco: Controlar
comunicações
09 - CR: Controlar Riscos
10 - CA: Controlar Aquisições
STAKEHOLDERS
11- CESH: Controlar o
Envolvimento dos
Stakeholders
RISCOS
AQUISIÇÕES
COMUNICAÇÕES
INTEGRAÇÃO
ESCOPO
TEMPO
CUSTO
QUALIDADE
Sumário – Como seria Organizado o PGAA partir de uma WBS faremos a Análise Make or Buy (utilizando critérios de M/B) e a seguir será gerado o Mapa de Aquisições usando como insumo o Cronograma, o Orçamento e o Vendor List (a partir de critérios eliminatórios).
A seguir a WBS passa por uma revisão. Ao final desta, a partir do Mapa de Aquisições, é feita:
1. Revisão dos Riscos (que é entregue ao Jurídico para elaboração do contrato) e;
2. Elaboração da Declaração de Trabalho, da Declaração de Escopo e a Carta Introdutória.
O julgamento pelos Critérios de Classificação e o Sistema de Pontuação ocorrem à partir da finalização dos pontos anteriores
Recommended