Gestao de contratos e servicos - Unisinos

Prévia do material em texto

GESTÃO DE CONTRATOS E SERVIÇOS DE TI
MAURICIO DE OLIVEIRA CRISTAL
Editora Unisinos, 2015
SUMÁRIO
Apresentação
Introdução
Capítulo 1 – Gestão de contratos e fornecedores segundo PMBOK®
Capítulo 2 – Gestão de contratos e fornecedores segundo MPS.BR Nível G
Capítulo 3 – Serviços e contratos em tecnologia da informação
Capítulo 4 – Exercícios de revisão contendo o conteúdo completo da
disciplina
Capítulo 5 – Gabarito dos exercícios de revisão
Referências
Sobre o autor
Informações técnicas
APRESENTAÇÃO
O objetivo deste livro é apresentar as práticas disponíveis no
mercado, bem como uma ampla visão da gestão de contratos e serviços
de tecnologia da informação. Como base bibliográfica, selecionaram-se
três modelos de mercado quanto às práticas de gestão de contratos,
aquisições e fornecedores. São elas: PMBOK, MPS.BR e conceitos de
serviços de TI, segundo (ITIL, 2005). O volume é compreendido por três
capítulos, além da introdução, conclusão e esta apresentação.
No capítulo 1 descrevem-se os processos relacionados ao
Gerenciamento das Aquisições do Projeto, segundo o (PMBOK, 2013). O
PMBOK define como aquisições o esforço realizado para gerenciar
contratos e fornecedores para o trabalho realizado fora de uma
organização. Mesmo que focando no escopo de projetos, as
nomenclaturas e práticas podem ser também aplicadas e estendidas para
gestão de contratos e serviços de TI.
No capítulo 2 apresentam-se os processos de gestão de contratos,
segundo o modelo MPS.BR – Melhoria de Processo do Software Brasileiro.
Esta guia é mantida e publicada pela Softex e baseia-se na Norma
Internacional ISO/IEC 12207:2008. Neste capítulo, as atividades e tarefas
da guia são descritos com exemplos práticos para facilitar o entendimento
das práticas propostas para gestão de contratos.
No capítulo 3 exibem-se os conceitos de contratos e serviços de TI,
segundo (ITIL, 2005). São definidos e apresentados tipos de contratos
usados no mercado de tecnologia, e o conceito de portfólio de serviços e
como podem auxiliar uma organização a coordenar os esforços na gestão
de serviços ofertados em uma organização de TI.
A partir do entendimento dos modelos e das práticas na gestão de
contratos de TI se espera que os alunos possam nivelar o conhecimento e
os conceitos na área específica com o objetivo de realizar os trabalhos
práticos com base teórica e bibliográfica.
Bons estudos!
INTRODUÇÃO
A razão e missão de uma área de TI existir em uma organização
está ligada usualmente a habilitar serviços necessários para apoiar o
desenvolvimento do planejamento estratégico. Para tanto é fundamental a
constante preocupação com a eficiência e eficácia para a efetividade em
relação à estratégia de negócio da organização. A correta implementação
de um Gerenciamento de Serviços de TI aumenta a contribuição da área
de TI para a geração e o valor para a organização, maximizando o retorno
para o negócio dos investimentos (CAPEX – Capenditure Expenses) e
reduzindo as despesas (OPEX – Operational Expenses) efetuados em
Tecnologia da Informação.
Neste cenário, palavras como “melhores práticas”, “otimização de
processos”, qualidade do serviço” e “alinhamento estratégico dos serviços
de TI ao negócio” passam a ser vital para todos os serviços providos pelas
áreas e organizações de TI. Sendo assim, tais áreas tendem a adotar
processos guiados pelas melhores práticas do mercado com o objetivo de
não terem de aprender e crescer por meio de tentativas e erros, mas de
lições já vivenciadas e superadas por outras organizações e publicadas
em modelos de mercado.
Alguns modelos de mercado podem ser citados:
PMBOK (PMBOK, 2013);
MPS.BR (MPS.BR, 2011);
ITIL® (ITIL, 2005).
Tais modelos e guias são alguns dos conjuntos de melhores
práticas que apoiam as áreas de Tecnologia da Informação, habilitando o
incremento da maturidade no processo de gerenciamento de TI. Propiciam
a construção de processos, metas e métricas auxiliando as organizações
de TI no incremento de maturidade entre o nível denominado “Caótico” e o
nível de “Valor”. A Figura 1 ilustra os níveis de maturidade para a gestão de
TI:
Figura 1 – Maturidade do Processo de Gerenciamento de TI.
Fonte: Magalhães (2007, p. 35).
Muito do trabalho a ser realizado invariavelmente passa por
aquisições externas às organizações de TI. São várias as razões, tais
como custo, cronograma ou conhecimento de tecnologia. Os modelos
citados acima surgem como alternativa no mercado de tecnologia para
apoiar o incremento de maturidade nas negociações de contrato entre
organizações, clientes e fornecedoras de soluções de tecnologia. Os três
modelos listados terão destaque neste livro e serão desenvolvidos nos
capítulos subsequentes.
CAPÍTULO 1
GESTÃO DE CONTRATOS E FORNECEDORES SEGUNDO
PMBOK®
Gerenciar aquisições em um projeto é usar os processos sugeridos
que se fazem necessários conforme o caso, para a aquisição de um ou
mais produtos ou serviços, ou segundo o PMBOK, “resultados externos à
equipe do projeto”.
Esses processos incluem tarefas como:
gerenciar contratos;
controlar mudanças relacionadas a contratos emitidos pelo
fornecedor;
controlar mudanças relacionadas a pedidos de compra emitidos
pelo fornecedor;
definição de pessoas autorizadas para emissão das mudanças;
administração de contratos emitido pelo comprador ou
adquirente;
administração das obrigações contratuais atribuídas à equipe do
projeto.
O PMBOK, na sua quinta edição, organizou as tarefas nos quatro
processos a seguir:
Planejar o gerenciamento das aquisições: documentação das
decisões de aquisições e identificação de fornecedores (é um
processo da fase de planejamento);
Conduzir as aquisições: obtenção de propostas de fornecedores,
seleção de um fornecedor e assinatura de um contrato (é um
processo da fase de execução);
Controlar as aquisições: gestão da execução da aquisição,
monitoramento do desempenho do contrato e atualização de
mudanças (é um processo da fase de controle);
Encerrar as aquisições: finalização das aquisições do projeto e
armazenamento das lições aprendidas (é um processo da fase
de encerramento).
Para ilustrar essas ideias, o Guia PMBOK Quinta Edição dispõe da
figura abaixo que mostra a visão geral do gerenciamento das aquisições.
Figura 2 – Visão geral do gerenciamento das aquisições do projeto.
Fonte: Guia PMBOK® Quinta Edição (2013, p. 356).
Além do contrato, o (PMBOK, 2013) destaca dois documentos como
essenciais para o gerenciamento das aquisições: a declaração de
trabalho ou Statement of Work e o plano de gerenciamento das
aquisições.
O contrato descreve todas as informações as quais asseguram que
as aquisições atendam as necessidades específicas do projeto e as
políticas de aquisição da organização. Outros termos, além de contrato,
também são aceitos, como acordo, combinação, subcontrato ou pedido de
compra. Outros termos, além de fornecedor, também são aceitos como
contratada, subcontratada, vendedor ou prestador de serviços.
O fornecedor normalmente gerencia o trabalho como um projeto.
Sendo que nesses eventos:
o comprador torna-se o cliente e, portanto, é uma parte
interessada principal do projeto para o fornecedor;
a equipe de gerenciamento de projetos do fornecedor está
envolvida em todos os processos de gerenciamento de projetos e
não somente com os relativos a essa área de conhecimento.
Os termos e as condições do contrato se tornam entradas principais
para muitos dos processos de gerenciamento do fornecedor. O contrato
pode realmente conter as entradas (por exemplo, entregas mais
importantes, marcos principais e objetivos de custos) ou pode limitar as
opções da equipe do projeto (por exemplo, a aprovação do comprador para
decisões referentes a preenchimento de vagas muitas vezes é necessária
em projetos de concepção).
1.1 Planejar o gerenciamento das aquisições
O primeiro passo para a contratação é a análise para comprar ou
fazer. Conforme a Figura 3 abaixo:
Figura 3 – Planejar o gerenciamento das aquisições.
Fonte: Guia PMBOK® Quinta Edição (2013, p. 358).
1.1.1 Análise para comprarou fazer
O planejamento das aquisições documenta as decisões
relacionadas às aquisições do projeto a qual inicia pela decisão de fazer
ou comprar. No caso de decidir ou comprar, deve-se especificar o que e
como será contratado, o quanto é necessário e quando deverá ser
realizado, além de identificar os fornecedores em potencial.
Para planejar o gerenciamento das aquisições o projeto deve estar
em um estágio tal que as necessidades do projeto já estejam definidas. O
objetivo é permitir analisar que a aquisição de produtos, serviços ou
resultados fora da organização são melhores que as disponíveis
internamente à organização contratante. As necessidades do projeto são
descritas na “declaração do trabalho” ou “Statement of Work”.
A declaração do trabalho das aquisições é desenvolvida
principalmente a partir dos seguintes itens segundo (PMBOK, 2013):
requisitos documentados;
declaração do escopo do projeto;
estrutura analítica do projeto (EAP);
dicionário da EAP.
Assim que forem identificadas as necessidades do projeto, toma-se
a decisão de realizar o trabalho internamente ou se decide pela
contratação externa (no caso, a decisão que interessa ao escopo deste
livro e disciplina, ou seja, a aquisição de serviços externos de tecnologia
da informação).
1.2 Conduzir as Aquisições
Os resultados ou saídas do processo de planejamento realizado
em “Planejar Aquisições” são utilizados para a execução do processo de
“Conduzir as Aquisições”. As atividades que podem ser executadas nesse
processo são as seguintes, mas não limitadas a:
obtenção de cotações e propostas, de possíveis fornecedores,
sobre como os requisitos do projeto podem ser alcançados;
pré-aplicação de critérios de avaliação para selecionar um ou
mais fornecedores que sejam qualificados e aceitáveis;
recebimento de cotações ou propostas e aplicação de critérios
para avaliação, conforme aplicável para selecionar um ou mais
fornecedores;
respostas de fornecedores;
seleção de um fornecedor;
adjudicação de um contrato com o fornecedor escolhido;
definição de um sistema de ponderação que a partir de dados
qualitativos selecione-se fornecedores de forma impessoal;
definição de um processo de gerenciamento das relações de
aquisição monitorando o desempenho do contrato e realização de
mudanças e correções conforme necessário;
garantia de que o desempenho do fornecedor atenda aos
requisitos contratuais e que o comprador atue de acordo com os
termos do contrato e níveis de serviço (SLA).
Quanto às alterações de contrato, o sistema de controle de
mudanças determina como são realizadas e quais os atores/papéis
participam das aprovações. As atividades que compõem esse sistema
são listadas a seguir:
define o processo pelo qual o contrato pode ser modificado
(aditivos);
inclui a documentação, os sistemas de acompanhamento, os
procedimentos para resolução de disputas entre as partes e os
níveis de aprovação necessários para autorização de mudanças;
interage com o sistema de controle integrado de mudanças
definido para o projeto.
A Figura 4 abaixo ilustra o processo conforme definido pelo (PMBOK,
2013):
Figura 4 – Conduzir as aquisições.
Fonte: Guia PMBOK® Quinta Edição (2013, p. 371).
O plano de gerenciamento de projeto informa como os processos
de aquisição são gerenciados. Esses processos definem desde a criação
da documentação até o encerramento do contrato. Outra informação de
entrada importante para o processo de condução das aquisições é a lista
de fornecedores qualificados. A lista pode ser definida a partir de contratos
realizados no passado ou por pesquisas no mercado local em caso de
novas organizações. Para coletar informações detalhadas sobre
fornecedores, visitas e contatos com clientes anteriores podem exigir
maior esforço por parte da organização contratante.
Segundo (PMBOK, 2013) dois ativos de processos organizacionais
podem influenciar o processo de realização das aquisições, são eles:
listagens de fornecedores em potencial e previamente
qualificados;
informações sobre experiências passadas relevantes com os
fornecedores, tanto positivas como negativas.
Com a lista de fornecedores definida é realizada a reunião com
licitantes antes da apresentação de uma licitação ou proposta. Todos os
fornecedores em potencial participam e então são apresentadas todas as
regras da aquisição, a descrição dos produtos ou serviços a serem
contratados (objetos contratuais), o escopo do projeto, as questões legais,
os requisitos técnicos, os requisitos contratuais, as restrições do projeto,
entre outras informações. Cada item do contrato é exposto e todas as
dúvidas dos fornecedores são esclarecidas. É muito importante que as
organizações adquirentes tenham o máximo cuidado de garantir que todos
os fornecedores em potencial tenham um entendimento claro e comum da
aquisição e que nenhum seja beneficiado em detrimento de outro. As
dúvidas esclarecidas podem ser incorporadas aos documentos de
aquisição como emendas. Essas dúvidas também podem ser separadas
em um documento à parte e encaminhas a todos fornecedores em
potencial, tornando o processo transparente e justo.
Como exemplos de documentos de aquisição podem-se listar as
seguintes opções usadas no mercado para solicitar informações,
propostas e cotações de preços de potenciais fornecedores:
Solicitação ou pedido de proposta (ou RFP – Request for
Proposal): o cliente solicita a potenciais fornecedores que
forneçam propostas sobre produtos ou serviços;
Solicitação ou pedido de cotação (ou RFQ – Request for
Quotation): o cliente solicita a potenciais fornecedores que
forneçam cotações de preços sobre produtos ou serviços;
Solicitação ou pedido de informação (RFI – Request for
Information): o cliente solicita a potenciais fornecedores que
descrevam informações sobre produtos, serviços ou sua
capacidade técnica para atender a entrega;
Aviso de oferta, convite para negociação, carta convite para
licitação (ou IFB – Invitation for Bid);
Edital de licitação.
Segundo (PMBOK, 2013), quando a decisão de seleção do
fornecedor é baseada em preço (como no ato de compra de itens
comerciais ou padrão) geralmente o termo utilizado é licitação, oferta ou
cotação. Quando outras considerações, como habilidades técnicas ou
abordagem técnica, são mais importantes, o termo proposta geralmente é
mais usual.
Definidos os fornecedores pré-selecionados, esses recebem a
relação de documentação necessária e as regras exigidas. As propostas
são definidas pelos fornecedores e encaminhadas à organização cliente
para seleção de um ou mais fornecedores. A opinião de consultores ou
diferentes especialistas são um importante recurso para avaliar as
propostas enviadas pelos fornecedores. Usualmente necessita-se mais
de um profissional ou departamento da organização cliente para realizar
essa análise. O produto ou serviço que está sendo adquirido pode
envolver várias áreas, como finanças, legislação fiscal, contabilidade ou
engenharia. Esse profissional ou departamento deve ter experiência na
área em que irá emitir sua opinião e, além disso, deverá ser
responsabilizado pela opinião ou consultoria que proveu.
Revisadas as propostas ocorre frequentemente que o fornecedor
selecionado já trabalha para a organização cliente em algum tipo de
contrato provisório ou em um trabalho realizado anteriormente. Quando
nessas ocasiões houver um acordo de maior importância já assinado
entre as partes (ou também conhecido no mercado como contrato “guarda-
chuva”) existirá por fatores históricos uma decisão da administração
executiva com relação aos papéis do comprador e do fornecedor entre as
duas organizações. Nesse caso basta que os níveis operacionais
desenvolvam em conjunto uma declaração do trabalho da aquisição que
atenda aos requisitos do projeto em questão. Após as partes negociarão
um contrato aditivo ao acordo já firmado.
Antes da assinatura ou adjudicação do contrato, em compras
complexas onde o sistema de ponderação se faz necessário, um
processo formal de revisão da avaliação é definido pelas políticas de
aquisição da organizaçãocompradora. O comitê de avaliação elegerá um
grupo de administradores responsável por essa revisão.
As estimativas de custo do trabalho são desenvolvidas pela própria
organização cliente ou por um consultor externo. Se as estimativas forem
muito divergentes das apresentadas pelos fornecedores, isso pode indicar
que o nível de detalhamento da declaração do trabalho da aquisição não é
suficiente ou não está suficientemente clara. Também pode indicar que os
fornecedores:
não entenderam a declaração;
não cobriram todos os pontos da declaração;
responderam a um escopo maior que o solicitado.
Essa técnica pode ser aplicada a um ou outro item da aquisição,
conforme o ocorrido, não sendo necessariamente aplicada a todos os
itens.
As estimativas devem ser independentes das organizações para
garantir que o trabalho a ser realizado seja dimensionado corretamente e
compreendido por ambas as organizações. Fatores comerciais podem
influenciar as estimativas de diferentes fornecedores, mas idealmente
devem ser informadas antecipadamente ao cliente e ao time de projeto
para evitar divergências de complexidade do projeto (estimativa do
fornecedor e expectativa do cliente) ao longo da execução do contrato.
Decisões comerciais com estimativas de risco usualmente impactam a
qualidade do produto ou serviço de software ao longo da execução do
contrato.
Após a seleção do fornecedor é possível estabelecer uma
negociação antes da adjudicação ou assinatura do contrato. Essa
negociação é muito válida para o relacionamento entre cliente e
fornecedor, pois determina uma comunicação franca e honesta, onde
todas as dúvidas podem ser sanadas a respeito do escopo e
complexidade do projeto. Segundo o (PMBOK, 2013), “Os assuntos
tratados englobam responsabilidades, autoridade para fazer mudanças,
legislação e termos aplicáveis, abordagens comerciais e técnicas de
gerenciamento, direitos de propriedade, financiamento de contratos,
soluções técnicas, cronograma geral, pagamentos e preços”.
Durante o processo de adjudicação o fornecedor selecionado
recebe o contrato para formalizar o acordo entre as partes. As formas de
um contrato variam entre um simples pedido de compra até um
documento complexo. Independente do fato esse documento, segundo
(PMBOK, 2013), “é um acordo legal que gera direitos e obrigações entre as
partes. Obriga o fornecedor a entregar os produtos, serviços ou resultados
especificados e obriga o comprador a remunerar o fornecedor” pelo
trabalho realizado. Por ser um documento legal, está sujeito a entrar em
litígio, na hipótese de uma das partes se negar a cumprir algum acordo
estabelecido. Um contrato, normalmente possui as seguintes partes:
declaração do trabalho ou entregas;
linha de base do cronograma;
relatórios de desempenho;
período de desempenho;
papéis e responsabilidades;
local de desempenho do fornecedor;
definição de preços.
Uma vez formalizado e aprovado o contrato passa a ser o
documento legal que documenta as responsabilidades entre cliente e
fornecedor. Dessa forma toda e qualquer solicitação de mudança ou
aditivo deve ser controlada formalmente e submetida para aprovação entre
as partes envolvidas (gerência de configuração da documentação do
contrato).
1.3 Controlar as aquisições
Controlar as aquisições é o processo em que tanto o fornecedor
quanto o comprador observam se as regras estabelecidas em contrato
estão sendo cumpridas. É necessário que tanto fornecedor como
comprador envolvido no contrato esteja ciente das implicações legais do
não cumprimento de cláusulas contratuais. Quando o projeto envolve
diversos fornecedores, o monitoramento entre eles, tanto do ponto de vista
de desempenho técnico, quanto do ponto de vista do desempenho das
comunicações e coordenação entre eles é fundamental para o sucesso do
projeto. Deve ser realizada periodicamente, de forma que os riscos
envolvidos sejam mitigados e problemas resolvidos.
No Guia (PMBOK, 2013) é apresentada uma figura muito explicativa
(ver figura a seguir) onde se pode visualizar a integração do processo de
Conduzir as Aquisições com os demais processos de outras áreas do
mesmo Guia.
Figura 5 – Diagrama de fluxo de dados do processo Controlar as aquisições.
Fonte: GUIA PMBOK® Quinta Edição (2013, p. 380).
Os seguintes processos do (PMBOK, 2013) podem ser aplicados no
controle das aquisições:
Orientar e gerenciar a execução do projeto (PMBOK, Seção 4.3,
2013) provendo autorização ao trabalho a ser realizado pelo
fornecedor;
Realizar o controle integrado de mudanças (PMBOK, Seção 4.5,
2013) garantindo que as mudanças sejam revisadas e aprovadas
por todas as partes envolvidas e requeridas no processo;
Monitorar e controlar o trabalho do projeto (PMBOK, Seção 4.4,
2013) garantindo entrega dos relatórios de desempenho.
Quanto ao controle do desempenho do fornecedor existe um
componente que envolve o monitoramento dos pagamentos aos
fornecedores. É um processo que assegura os termos do contrato para
que pagamentos e entregas sejam cumpridos conforme cronograma
estabelecido no contrato aprovado. Segundo o (PMBOK, 2013): “Uma das
principais preocupações ao fazer o pagamento dos fornecedores é que
exista uma relação rigorosa entre os pagamentos feitos e o trabalho
realizado”.
O controle de desempenho do fornecedor deve ser realizado com
base no contrato. Preferencialmente sempre que possível é desejável
definir métricas e objetivos de desempenho. Esse histórico de
desempenho pode ser armazenado devidamente como uma métrica de
competência do fornecedor e ser usado para projetos futuros em
ferramentas de cobrança, acompanhamento ou mesmo em futuras
seleções de fornecedores para novos projetos.
A análise de desempenho das aquisições é uma avaliação do
progresso do fornecedor para entregar o escopo e a qualidade do projeto,
de acordo com orçamento e cronograma, em comparação ao contrato.
Pode incluir uma análise da documentação, relatórios de andamento e
inspeções do comprador, assim como as auditorias de qualidade e testes.
O objetivo dessa análise é identificar os êxitos e fracassos no escopo do
trabalho realizado, o progresso em relação à declaração do trabalho da
aquisição e do não cumprimento do contrato. A análise permite que o
comprador quantifique a capacidade ou incapacidade demonstrada pelo
fornecedor para entregar o trabalho contratado.
Quanto ao cancelamento o mesmo pode ocorrer por justa causa,
conveniência ou inadimplência. Em todos os eventos é necessário seguir
a cláusula de rescisão definida no contrato.
Muitas vezes, entendem-se contratos como documentos rígidos e
imutáveis até o seu encerramento. No entanto, os contratos são e podem
ser alterados através de adendos ou retificações. O mais importante de
atentar é que toda e qualquer alteração só pode acontecer no caso de
ambas as partes (cliente e fornecedor) estarem de acordo. É importante
destacar que entre as partes usualmente existe uma estrutura de poder. As
alterações nem sempre beneficiam igualmente o fornecedor e o
comprador.
Quando decidida a alteração do contrato sugere-se que as
solicitações de mudança sejam aprovadas para adicionar modificações
nos termos e condições do contrato. São exemplos de alterações formais
em contrato: alteração de escopo ou requisitos, a definição de preços, a
descrição dos produtos, serviços ou resultados a serem fornecidos. Todas
as mudanças são documentadas formalmente por escrito e aprovadas
antes de serem implementadas. As mudanças devem seguir o processo
de gestão de configuração usado pelo projeto.
Quando cliente e fornecedor não atingem o consenso sobre
remuneração ou expectativa de desempenho durante a execução do
contrato inicia-se um processo de reivindicação que geram disputas,
negociações e recursos administrativos. Todas as reivindicações devem
ser documentadas e registradas para consulta futura. Elas igualmente
devem seguir os termos definidos e estabelecidos no contrato. A melhor
resolução para as reivindicações é a negociação entre as partes, evitando
recursos administrativos ou legais.
Para facilitaro entendimento a Figura 6 ilustra o processo acima
descrito:
Figura 6 – Controlar as aquisições.
Fonte: Guia PMBOK® Quinta Edição (2013, p. 379).
1.4 Encerrar as Aquisições
É processo finalizar todas as aquisições do projeto. Fornece suporte
ao processo “encerrar o projeto” (PMBOK, 2013), pois envolve a
confirmação de que todo o trabalho e as entregas atinjam os critérios de
qualidade definidos pelo cliente. Os critérios são validados e testados em
auditorias realizadas pelo cliente ou entidade externa. As auditorias
identificam sucessos e falhas sempre levando em consideração as
definições de qualidade definidas no contrato.
Com o encerramento do contrato, todos os documentos gerados e
usados pelas equipes de projeto (sejam do ponto de vista técnica ou
administrativa) devem ser arquivados para consulta futura. Informações
sobre escopo, custos, cronogramas, critérios de qualidade, riscos,
problemas e resoluções, bem como resultados de testes e qualificação do
produto ou serviço devem ser armazenadas e registradas junto ao projeto
e ao contrato para construir uma base de conhecimento para reuso futuro
em novos contratos como lições aprendidas.
Ao final do contrato todas as reivindicações devem ser resolvidas ou
encerradas. As disputas idealmente devem ser resolvidas por negociação
entre as partes sendo a resolução judicial a menos indicada e a menos
desejada. Encerradas as reivindicações das disputas pendentes, o cliente
envia um aviso formal notificando que o contrato está concluído e
encerrado nos termos e definições estabelecidos. Tanto o cliente quanto o
fornecedor arquivam os documentos e as lições aprendidas para futuras
consultas.
A Figura 7 ilustra o processo conforme definido em (PMBOK, 2013):
Figura 7 – Encerrar as aquisições.
Fonte: Guia PMBOK® Quinta Edição (2013, p. 386).
1.5 Exercícios sobre Gestão de Contratos e Fornecedores segundo
PMBOK®
1. Como as mudanças de escopo durante a execução de um
projeto podem impactar um contrato de prestação de serviços de
tecnologia, segundo o PMBOK®?
2. Durante o processo de planejar aquisições realiza-se a análise
de make or buy? O que significa essa análise e como ela altera
o planejamento das aquisições?
3. Qual o principal objetivo do cliente definir critérios de seleção de
fornecedores no processo de conduzir as aquisições, segundo o
PMBOK®?
4. Favor listar as atividades que compõem a execução de
inspeções e auditorias no processo de Controlar as aquisições,
segundo o PMBOK® no seu entendimento?
5. Qual a importância da declaração de trabalho para o plano de
gerenciamento das aquisições, segundo o PMBOK®?
6. Favor descrever qual o seu entendimento sobre o principal
objetivo do processo de conduzir as aquisições, conforme
definido pelo PMBOK®.
7. Qual o impacto seja positivo ou negativo de possuir fornecedores
previamente qualificados ou informações disponíveis na
contratação de fornecedores, segundo o PMBOK® no processo
de conduzir as aquisições?
8. Favor listar e descrever os diferentes documentos de aquisição
de fornecedores disponíveis no mercado e qual o objetivo de
cada um desses documentos.
9. Diferencie o documento de aquisição pedido de proposta (RFP)
do pedido de cotação (RFQ). Qual a aplicação de um documento
em comparação ao outro?
10. Qual o conceito do contrato “guarda-chuva” e como ele facilita o
processo de aquisição entre duas organizações?
11. Segundo o PMBOK®, como os pagamentos do cliente devem ser
controlados durante a execução do projeto no processo de
controlar as aquisições do ponto de vista de desempenho do
projeto e avaliação do progresso do projeto?
12. Segundo o PMBOK, quais os critérios ® devem ser assegurados
para garantir que o contrato foi finalizado corretamente?
13. Qual a relação das lições aprendidas com o encerramento do
contrato, segundo o PMBOK®, no processo de encerrar as
aquisições?
CAPÍTULO 2
GESTÃO DE CONTRATOS E FORNECEDORES SEGUNDO
MPS.BR NÍVEL G
O processo de aquisição segundo (MPS.BR, 2011) inicia com a
identificação da necessidade do cliente e encerra com a aceitação do
produto ou serviço. Uma implementação bem-sucedida do processo de
aquisição tem necessariamente:
definição das necessidades de aquisição, as metas, os critérios
de aceitação do S&SC e as estratégias de aquisição;
um contrato claro de entender, com as expectativas, as
responsabilidades e as obrigações de ambos os lados (cliente e
fornecedor);
seleção de fornecedores;
monitoramento da aquisição; custo, cronograma e qualidade
devem ser atendidos com base nas condições expressamente
definidas no contrato;
aceite das entregas do fornecedor pelo cliente;
acerto das pendências identificadas devem ter uma conclusão
positiva, com acordo documentado entre cliente e fornecedor.
O processo acima fica completo com a aplicação de quatro
atividades detalhadas na Figura 4, a seguir:
Preparação da aquisição;
Seleção do fornecedor;
Monitoração do contrato;
Aceitação pelo cliente.
Figura 8 – Atividades de aquisição no MPS.BR nível G.
Fonte: MPS.BR - Guia de Aquisição (2009, p. 9).
Cada uma das quatro atividades principais na figura acima é
composta por 3 elementos:
Objetivo – o que será alcançado com a execução da atividade;
aqui se colocam orientações gerais;
Tarefas previstas – as tarefas que atingirão os objetivos e os
resultados previstos;
Produtos requeridos e gerados – entradas e saídas de atividades
requeridas por atividade.
Cada tarefa (quadros à direita) possui entradas (que no MPS.BR
são chamadas de produtos requeridos) e saídas (denominadas produtos
gerados). Ao final de cada atividade principal é compilada uma tabela com
todos esses produtos citados nas tarefas.
Essas atividades se comparadas aos processos propostos pelo
(PMBOK, 2013) se assemelham em objetivos quanto à gestão de
contratos. Enquanto as atividades de seleção do fornecedor são
agrupadas dentro do processo de “Conduzir as Aquisições”, segundo o
guia PMBOK no guia (MPS.BR, 2011) dedica-se uma atividade específica
para esse objetivo. Cabe destacar, igualmente, que enquanto o PMBOK
atende a gestão de projetos com atividades não prescritivas o MPS.BR
destina-se à contratação de serviços de software e correlatos (SC&C),
tornando-se mais prescritivo se comparado ao PMBOK; propondo inclusive
documentos de modelos como anexo à guia. A seguir, a tabela que
compara ambos quanto às atividades e os processos:
PMBOK MPS.BR
Planejar o gerenciamento das
aquisições
Preparação da Aquisição
Conduzir as Aquisições Seleção do Fornecedor
Controlar as aquisições Monitoração do Contrato
Encerrar as Aquisições Aceitação pelo Cliente
Figura 9 – Lista de atividades e processos do PMBOK e MPS.BR.
Fonte: elaborada pelo autor.
2.1 Preparação da Aquisição
Do ponto de vista da análise de fazer ou comprar, segundo (MPS.BR,
2011), identificam-se as necessidades requeridas as quais deverão ser
atendidas pela contratação. A demanda a ser contratada pode ser um
desenvolvimento ou melhoria de um sistema existente, um produto de
software com o ciclo de vida completo ou um serviço de software.
Importante dimensionar e definir o que a organização cliente necessita
como conjunto de funcionalidades ou requisitos, ou seja, o porquê a
mesma está adquirindo, o problema que ela pretende resolver ou o
objetivo a ser atingido a partir da aquisição.
É fundamental definir nessa tarefa o escopo das necessidades que
comporão o contrato. Por mais complexo que seja essa análise é
importante estabelecer claramente os critérios de aceitação e de que
maneira quantificar, se os objetivos do cliente foram atingidos na entrega
do serviço ou do produto. Quanto maior o grau de maturidade do
fornecedor maior a quantidade de informações do mesmo a respeito de
seu desempenho técnico (qualidade e engenharia de software) e
administrativo (gestão do projeto). Organizações prestadoras de serviços
de software com baixa maturidade de processo tendem a possuir
processos “ad-hoc” e pouca informação de controle para gerir os projetos
de seus clientes (CMMI).
O documento que descreve as necessidadesda aquisição,
segundo (MPS.BR,2011), chama-se avaliação da necessidade de S&SC.
Esse documento é vivo ao longo do ciclo de vida do contrato. Ele é
versionado à medida que o processo de aquisição avança, pois mais
informações acerca do produto de software e das expectativas de
qualidade do cliente final “amadurecem” ao longo da execução do contrato.
A versão final do documento estabelece o conjunto de necessidades
e requisitos a serem contemplados pelo S&SC. Logo auxilia na tomada de
decisão se o melhor caminho é comprar um produto de prateleira ou
contratar um fornecedor especializado no desenvolvimento do S&SC
específico para a organização cliente.
Quanto à definição dos requisitos para um S&SC deve ser levado
em consideração os seguintes aspectos:
das pessoas e papéis interessados na solução;
requisitos de sistema e de qualidade de software;
aspectos de projeto;
engenharia de software;
implantação;
manutenção do software em produção;
o treinamento do usuário final.
As restrições e os riscos impostos por fatores legais, financeiros e
cronogramas devem igualmente serem consideradas como parte dos
requisitos, pois impactam diretamente o desenvolvimento e definição dos
mesmos.
Coletados os requisitos e as restrições a organização cliente tem a
habilidade de identificar produtos de mercado já desenvolvidos e prontos
(chamados de produtos de prateleira) que atendam a sua demanda. Essa
decisão simplifica bastante o processo de contratação, uma vez que o
produto de software já está disponível e pronto, bastando a implantação e
a homologação. Um exemplo muito comum atualmente são os sistemas
ERP (Enterprise Resource Planning) que são implantados, customizados e
homologados em conjunto entre cliente e fornecedores de solução. Se não
existir produtos de mercado (seja prateleira ou ERPs) a organização
cliente tem que definir uma estratégia da contratação que contemple todo o
ciclo de desenvolvimento de software. Nesse caso a solução desenvolvida
se torna bem específica aos processos de gestão da organização cliente.
A estratégia da contratação depende de aspectos de mercado, produtos
disponíveis e expectativas do cliente quanto à solução (desenvolvida
especificamente para o cliente contratante ou adaptada de um produto de
mercado).
A última etapa dessa atividade é a definição dos critérios de seleção
de fornecedores. Aspectos como localização geográfica, reconhecido
domínio e conhecimento de área técnica e de negócio no mercado, custos
de desenvolvimento de projeto, casos de sucesso e falhas, tempo de
atuação no mercado e portfólio de clientes atuais são informações que
usualmente são solicitadas pelas organizações clientes para se
certificarem da qualidade dos fornecedores em potencial. Todas as
informações consideradas relevantes pela contratante devem ser
descritas como critérios de seleção para tornar o processo de seleção
mais simples e claro para todos os envolvidos.
Como leitura complementar sugere-se a lista de documentos e
produtos gerados nesta atividade. A lista pode ser encontrada em
(MPS.BR, p.15, 2011).
2.2 Seleção do Fornecedor
Segundo (MPS.BR, 2011) esta atividade tem por objetivo determinar
o fornecedor que realizará o trabalho a partir dos requisitos definidos na
atividade “Preparação da Aquisição”. Definidos o problema a ser resolvido
e os requisitos componentes da solução, a organização cliente parte-se
para a definição do melhor fornecedor para realizar o desenvolvimento e
entrega do S&SC.
A saída dessa atividade é a escolha do fornecedor. Para tanto, o
(MPS.BR, 2011) apresenta as seguintes tarefas previstas:
avaliar a capacidade dos fornecedores;
selecionar o fornecedor;
preparar e negociar um contrato.
A partir dos requisitos definidos torna-se possível que a organização
cliente possa avaliar os potenciais fornecedores e suas capacidades.
Usualmente os clientes já possuem fornecedores pré-cadastrados para
os mais diversos serviços de tecnologia, tais como: desenvolvimento de
software, implantação, instalação de hardware e consultoria de regras de
negócio. Nesses eventos, essa atividade torna-se muito simplificada,
bastando realizar um convite para o fornecedor mais preparado para a
demanda em questão. No entanto, essa atividade mostra-se mais
complexa, por exemplo, nos casos de execução de serviços em novas
localidades nas quais o cliente não possui relacionamento prévio com
organizações fornecedoras de S&SC. Nessas métricas e critérios de
avaliação, bem como as visitas a novos fornecedores se tornam
fundamentais para adquirir maiores informações sobre os potenciais
fornecedores na nova localidade.
Nas situações em que os clientes são empresas públicas do
governo brasileiro, segue-se a legislação da Lei 8.666 para a contratação
de fornecedores, de acordo com o processo de licitação usualmente de
menor preço (Lei Nº 8666). Esse tema não é escopo dessa obra e,
portanto, não será abordado aqui, apenas será apresentado como
informação adicional para os casos que envolvem empresas públicas
como clientes em contratos.
Seja quando o cliente possuir um cadastro de fornecedores
predeterminados ou quando necessitar criar uma lista de potenciais
fornecedores é recomendado receber mais de uma proposta para serviços
a serem contratados. Tanto para comparação de custos como para realizar
uma concorrência entre os fornecedores que favoreça o cliente e
estabeleça uma competição sadia entre os fornecedores em prol de maior
produtividade e redução de custos para o desenvolvimento do S&SC.
A tarefa de “Selecionar o fornecedor”, segundo (MPS.BR, 2011)
define critérios para análise de propostas enviadas por todos os
potenciais fornecedores. Quando ocorrer a compra de produtos de
prateleira, essa atividade deverá conter critérios para avaliação de
qualidade e aderência de software ao problema do cliente. Os critérios de
avaliação e qualidade definidos devem ser de conhecimento público para
todos os fornecedores que participam do processo de seleção. Como
resultado da atividade é gerado o relatório de avaliação das propostas dos
fornecedores e, com isso, identifica-se o fornecedor selecionado de
acordo com os critérios que foram definidos e que será contratado.
Definido o fornecedor inicia-se a negociação do contrato entre as
partes: cliente e fornecedor. As especificações técnicas de engenharia de
software, critérios de qualidade, estimativas de custo detalhadas, riscos de
projeto e planos de pagamentos são exemplos de informações que devem
ser negociadas entre as organizações envolvidas. Os papéis e o processo
de aprovação do contrato também são definidos como parte dessa
atividade. Os casos de alteração de contrato, aditivos e rescisão devem ser
definidos, bem como os níveis de aprovação dentro de ambas as
organizações. Por exemplo: para os aditivos que incorporem escopo de
pequeno impacto ao contrato os gerentes de projeto podem ter alçada
para aprovar a adição de escopo. Nos casos de maior impacto, como
rescisão do contrato, os níveis executivos das organizações são mais
indicados.
As saídas da tarefa de “Preparar e negociar um contrato” são a
assinatura do contrato entre cliente e fornecedor e os documentos de
registros para revisão de contratos.
2.3 Monitoração do Contrato
O principal objetivo da atividade “Monitoração do Contrato” é garantir
que ambas as partes cumpram o acordo assinado. Sob o ponto de vista
do fornecedor, essa atividade assegura que os compromissos de
qualidade do S&SC e do desempenho estão formalizados no contrato.
Pelo lado do cliente determina que os pagamentos sejam realizados
conforme planejamento (quando se identifica desempenho satisfatório) ou
bloqueados por baixo desempenho do fornecedor. Aspectos relacionados
à resolução de problemas, negociação de escopo, prazos e custo,
revisões de qualidade e mitigação de riscos são temas de análise das
partes para determinar o andamento do projeto frente ao planejado e
acordado.
É importante destacar que o contrato do ponto de vista do fornecedor
pode ser administrado e gerido com técnicas de gestão deprojeto.
Portanto, muitas das práticas de mercado existentes para
acompanhamento de projeto podem ser reusadas nessa atividade para
monitorar um contrato relacionado à S&SC.
Conforme (MPS.BR, 2011) dentro da atividade de monitorar o
contrato listam-se as seguintes tarefas:
estabelecer e manter comunicações;
trocar informação sobre o progresso técnico;
revisar o desempenho do fornecedor;
monitorar a aquisição;
obter acordo quanto às alterações;
acompanhar problemas.
No acompanhamento de projetos de tecnologia a troca de
informações é fundamental para o sucesso e atingimento de objetivos
planejados. Usualmente em projetos de tecnologia que usam
subcontratação de serviço têm-se dois times de projetos: um time na
organização cliente e o segundo time na organização fornecedora. Esses
times basicamente tomam decisões e interagem entre si pela informação
gerada pelos canais de comunicação estabelecidos. Sejam eles verbais,
informais ou formais e escritos. A informação mal distribuída ou errônea
provavelmente gerará retrabalhos dentro das equipes gerando baixa
produtividade e perdas financeiras. Um exemplo muito comum em
projetos de desenvolvimento de software são as mudanças de requisitos.
Quando mal comunicadas por parte do cliente, consequentemente são
mal implementadas pelo fornecedor. O resultado pobre usualmente é
encontrado durante a fase de testes incrementando a contagem de
defeitos na fase de homologação do software. De acordo com (PMBOK,
2013), 90% do esforço de um gerente de projetos é gerar informação e
garantir que a mesma atinja todas as partes interessadas, dada a sua
relevância na condução de um projeto de S&SC. Portanto é esperado que
os canais de comunicação sejam formalmente estabelecidos e
compreendidos pelas partes envolvidas no projeto (preferencialmente
descritos em contrato).
Segundo (PMBOK, 2013), no início do projeto têm-se poucas
informações a respeito do produto ou serviço a ser construído como
resultado do projeto. À medida que a execução do projeto avança riscos,
são mitigados e resolvidos, além disso, as questões outrora ambíguas
tornam-se mais e mais claras. Sabe-se que o planejamento definido no
início do projeto sofrerá alterações ao longo da execução, pois a mudança
é da natureza do S&SC. A tarefa “Trocar informações sobre o progresso
técnico” tem por objetivo minimizar esse impacto à gestão do contrato.
Através de reuniões técnicas, revisões de requisitos e aprovação de
documentos, tanto cliente como fornecedor conseguem monitorar as
diferenças entre planejado e realizado, mantendo ambas as organizações
a par da evolução técnica e administrativa do projeto. Se as divergências
forem muito acentuadas, então, o cancelamento do contrato ou as
disputas judiciais poderão ser uma das alternativas disponíveis entre as
partes.
Da mesma forma que critérios são definidos para a seleção do
fornecedor, critérios de qualidade de produto para monitoramento e
controle de projeto são usados para revisar e determinar o desempenho
do fornecedor. Conforme mencionado anteriormente o contrato deve ser
seguido por ambos: compromisso da entrega conforme qualidade
esperada e compromisso de pagamento conforme planejado. Nos
eventos de baixo desempenho, de acordo com os critérios estabelecidos
em contrato, o cliente pode bloquear pagamentos (desde que igualmente
esteja explícito no contrato assinado). No mercado de tecnologia como
critérios de qualidade usa-se a engenharia de software para determinar:
quantidade de defeitos, retrabalho da equipe, estimativa planejada vs.
realizada, conforme sugerido por (Kan, 2002). Para cada uma dessas
medidas são definidos critérios e valores alvos que devem ser alcançados
pelo fornecedor ao longo da execução do projeto.
Por exemplo, a Figura 6 a seguir. No contrato fictício para o exemplo
definiu-se que os pagamentos ao fornecedor seriam realizados somente
quando o número de funcionalidades desenvolvidas fosse atingido ou
superado pelo fornecedor durante o desenvolvimento. Nota-se a linha
vermelha no mês de abril no qual o realizado (actual) está vinte
funcionalidades abaixo do planejado. Nas linhas verdes destacam-se
quando os pagamentos foram realizados, já que o desempenho do
fornecedor foi atingido conforme o contrato.
Figura 10 – Planejado vs. Realizado.
Fonte: elaborada pelo autor.
Os critérios qualitativos e quantitativos devem ser explícitos e claros
no contrato para ambas as partes com o objetivo de evitar perdas
financeiras ou perdas de produtividade na execução do trabalho. Contratos
mal planejados ou estimados tendem a gerar problemas e renegociação
durante a execução do trabalho.
A tarefa de “monitorar a aquisição” está intimamente relacionada
com as saídas da tarefa de “revisar o desempenho do fornecedor”. Para
monitorar a aquisição são necessários documentos como relatórios de
desempenho do fornecedor, progresso do projeto contra o planejamento,
controle de riscos e de resolução de problemas, assim como as barreiras
que atrapalham execução do projeto. Todas essas métricas devem estar
definidas como parte do contrato, o processo para coleta de dados e a
comunicação dos resultados. Usualmente nessas revisões e análises de
desempenho são identificadas mudanças e correções de plano.
A tarefa “obter acordo quanto às alterações” descreve as
negociações que ocorrem entre cliente e fornecedor com o objetivo de
promover mudanças, aditivos e adendos ao contrato. Como mencionado
anteriormente, a partir das revisões e das análises de desempenho, as
alterações de contrato podem ser negociadas e adicionadas ao contrato
formalizado entre as partes. Um exemplo prático muito comum em
projetos de S&SC é a adição de escopo por falta de clareza nos requisitos
providos pelo cliente. Ao iniciar o desenvolvimento do software o
fornecedor identifica uma inconsistência quanto à determinada regra de
negócio provida pelo cliente. Ao reportar o problema encontrado como
justificativa do atraso, o fornecedor sugere uma alteração do requisito para
prover maior clareza ao mesmo. Ambas as partes aprovam a alteração e
adicionam-na como aditivo ao escopo de trabalho. É fundamental destacar
o nível de aprovação das partes interessadas e o seu grau de autonomia e
liberdade quanto às alterações ao contrato. Por exemplo, alterações
operacionais sem impacto de custo podem ser aprovadas pelo nível
gerencial, enquanto alterações de contrato que impactem prazos e custos
requerem aprovação executiva de ambas as organizações, cliente e
fornecedor.
A resolução de problemas, remoção de impedimentos ou barreiras
para o time de projeto, mitigação e contingência de riscos são controlados
pela tarefa “acompanhar problemas”, conforme definido por (MPS.BR,
2011). A documentação das ações e decisões corretivas tomadas deve ser
realizada pelo time de projeto para manter o registro das resoluções como
lições aprendidas, do mesmo modo que guardar o histórico para
consultas futuras tanto do cliente como do fornecedor.
Os produtos requeridos e gerados como resultado pela atividade
“monitoração do contrato” não serão detalhados nesta obra e podem ser
revisados em detalhe no guia (MPS.BR, p.24, 2011) como estudo adicional
a este capítulo.
2.4 Aceitação pelo Cliente
O conjunto de tarefas segundo (MPS.BR, 2011) definidas para
proceder com o aceite final do cliente são definidas nesta atividade. A partir
dos critérios de aceitação propostos nos contratos (os quais podem ser
refinados ao longo da execução) procedem-se com revisões, testes e
homologações no produto de S&SC construído pelo fornecedor.
Evidentemente, espera-se que tais revisões e homologações do cliente
final ocorram também ao longo da execução para determinar términos de
etapas no plano de projeto. No entanto, ao final da execução do contrato o
aceite final será a formalização do encerramento do contrato com sucesso.
Quando ocorrer a falha, o aceite final não é emitido e as partes negociam
novos termos para o contrato original conforme mencionado anteriormente
na atividade de “monitoração do contrato”.
As tarefascomponentes da atividade de “aceitação do cliente” são
listadas a seguir:
definir critérios de aceitação;
avaliar o produto entregue;
manter conformidade com o contrato;
aceitar o S&SC.
Ao definir os critérios de aceitação entende-se que os mesmos
sejam desenvolvidos em conjunto com o produto de software de forma
iterativa e não ao final do projeto. Cada projeto segue o seu ciclo de vida
especificamente, porém acredita-se que realizar a homologação somente
no final do ciclo de vida do software acarreta em uma longa fase de
homologação e resolução de defeitos. O plano de testes é desenvolvido a
partir dos requisitos acordados em contrato, no qual valida o produto
construído ao longo da execução do projeto. Os critérios de aceitação
podem ser adaptados ou atualizados para atingir a expectativa de
qualidade do cliente. Porém, espera-se que os mesmos sejam acordados
entre ambas as partes: cliente e fornecedor.
Definido o plano de teste avalia-se o produto entregue a partir dos
critérios de aceitação acordado entre cliente e fornecedor. Conforme
mencionado anteriormente, notam-se práticas iterativas no mercado de
tecnologia nas quais as atividades de teste acontecem mais e mais nos
estágios iniciais do ciclo de vida do software para garantir maior qualidade
ao final do projeto. Postergar as atividades de homologação para o final do
projeto pode inviabilizar o produto, dado o grande esforço necessário para
corrigir os defeitos potencialmente encontrados na homologação.
Realizando a qualificação do produto de software ao longo da execução
garante um produto mais estável durante o processo de aceitação do
produto final e encerramento do contrato.
Ao longo de todo o capítulo 8 foi mencionado por diversas vezes que
o contrato assinado é sempre a referência para dirimir eventuais dúvidas
ou questionamentos das partes. Durante a atividade de encerramento do
contrato é fundamental analisar e validar se todas as decisões tomadas
estão de acordo e em conformidade com o mesmo. Reuniões de revisões
entre as partes devem ocorrer para assegurar que todos os itens do
contrato estão em conformidade com o produto entregue e as decisões
tomadas durante a execução e encerramento do projeto.
Uma vez que o contrato está em conformidade entre as partes, o
fornecedor transfere o ativo de software para o cliente garantindo que os
critérios de aceitação foram atendidos. Toda a documentação gerada ao
longo do planejamento, execução e encerramento do projeto são
arquivadas e disponibilizadas para consulta futura como lições
aprendidas. Exemplos de documentos gerados são listados abaixo:
plano de projeto;
contrato;
diagramas UML;
código-fonte e executáveis;
scripts de instalação;
manuais de treinamento do usuário e do sistema;
entre outros.
Todos os artefatos ficam armazenados em um repositório central
disponibilizado para futuras consultas.
2.5 Exercícios sobre Gestão de Contratos e Fornecedores segundo
MPS.BR Nível G
1. Quais são as 4 atividades principais da gestão de contratos e
fornecedores segundo o MPS.Br?
2. Estabelece uma comparação entre a gestão de aquisições,
segundo PMBOK® e MPS.Br, listando e explicando as diferenças
entre as duas abordagens.
3. Qual a importância de definir o escopo das necessidades do
contrato conforme MPS.Br?
4. Explique como a manutenção do software em ambiente de
produção pode alterar a definição de requisitos de um contrato
segundo MPS.Br.
5. De acordo com MPS.Br, qual análise o cliente estará apto para
realizar sobre a contratação com o encerramento da coleta de
requisitos e restrições?
6. As especificações técnicas do sistema e do produto a serem
desenvolvidas devem ser entregues em que momento do
processo de contratação ao fornecedor segundo MPS.Br?
7. Qual a consequência de mudanças pobremente controladas
durante a fase de Monitoração do Contrato, de acordo MPS.Br?
8. Liste as atividades que compõem a tarefa “Acompanhar
problemas”, de acordo MPS.Br.
9. Qual o papel da fase de homologação e resolução de defeitos
durante a aceitação do cliente no MPS.Br?
10. Para que o contrato é usado durante a atividade de encerramento
e aceitação do cliente?
CAPÍTULO 3
SERVIÇOS E CONTRATOS EM TECNOLOGIA DA
INFORMAÇÃO
No capítulo de serviços e contratos a seguir serão descritos conceitos e termos
empregados no mercado de tecnologia de informação na formulação de contratos para
serviços de tecnologia. Os termos e conceitos apresentados são difundidos e uti l izados
no mercado de tecnologia os quais porém não atendem ou seguem uma padronização
ou norma pré-estabelecida.
Segundo (Freitas, 2010), um prestador de serviços de TI deve
entender que seus clientes não contratam produtos, mas sim o
atendimento de suas necessidades e das resoluções de problemas
existentes. Para que o cliente final possa perceber o valor agregado dos
serviços entregues pelos fornecedores é necessário que o provedor tenha
um entendimento claro:
do cliente;
do tempo necessário para realizar e entregar o serviço contratado;
das necessidades do cliente específico;
do problema a ser resolvido;
de como os serviços serão entregues.
3.1 Ativos de Serviços
A palavra “ativo” para a contabilidade nas organizações significa
bens e direitos que uma empresa possui e resultados de operações que
geram benefícios financeiros para a empresa. Os serviços são
determinados como ativos intangíveis, pois não são bens físicos tal como
um equipamento na linha de produção, por exemplo, que se adiciona
fisicamente ao patrimônio de uma empresa. Entende-se por serviços de TI
como: desenvolvimento de software, teste de software, instalação de
software em produção, operação do ambiente de produção. Para ITIL®
(ITIL, 2005), o termo ativo de serviço determina o valor agregado pelo
serviço aos seus clientes finais. Os ativos de serviços possuem duas
características:
Utilidade: percepção de valor agregado ao negócio do cliente final
e de atendimento ao propósito de negócio da organização;
Garantia: como os clientes recebem os serviços de TI e de como
adequam a sua utilização também vinculada ao negócio final da
organização contratante.
Segundo ITIL® (ITIL, 2005) existem três tipos de prestadores de
serviços de TI:
Prestadores de serviços internos: são as áreas de TI alocadas à
estrutura interna das empresas. Atendem tão somente demandas
internas dos diferentes departamentos da organização. Por
exemplo, em uma fábrica atendem aos departamentos de
engenharia, recursos humanos, vendas entre outros. O maior
desafio de provedores de serviços internos é a priorização das
demandas de diferentes departamentos da organização de forma
a garantir o alinhamento e maior retorno para o negócio final. Uma
das formas usadas para garantir alinhamento com o negócio é
vincular as decisões de tecnologia ao planejamento estratégico
da organização;
Prestadores de serviços compartilhados: nesse caso a
organização foca na sua missão (razão de existir). Ou seja, em
uma empresa de transportes o departamento de logística é
estratégico para a existência da organização, enquanto para uma
fábrica o departamento de engenharia de produção torna-se mais
estratégico que o departamento de logística se comparado à
empresa de transportes. Os demais departamentos ou áreas de
apoio atuam em nível corporativo e podem determinar a sua
governança e como irão atender as necessidades da área de
maior vínculo com a estratégia organizacional. A entrega de
serviços de TI pode ser padronizada e comparada quanto à
qualidade, os custos e os riscos entre todos os clientes, pois o
mesmo serviço é entregue da mesma forma para todos os
clientes. Um bom exemplo para isso é um serviço padronizado de
e-mail, o qual é entregue igualmente para todos os clientes
contratantes e sem customização de cliente a cliente;
Prestadores de serviços externos: no caso de a organização não
ter conhecimento de prover os serviços de TI ou no caso dos
custos serem mais adequados com a subcontratação, todos os
serviços de TI podem ser alocados a um ou mais provedores
externos. Assim, prefere-se ter um provedorexterno e competitivo
no mercado de TI a ter um time interno provendo os serviços não
compatíveis com o padrão de mercado seja quanto à qualidade
seja quanto ao custo de transação dos serviços. Um bom
exemplo na atualidade são as soluções em cloud que permitem o
full-outsourcing das organizações sob um custo mais atraente e
com grande capacidade de flexibilidade na alocação. Em muitas
situações o time de TI exige um ano de planejamento para
compra de hardware e software para atender as necessidades de
crescimento de negócio. Nos eventos das soluções em cloud
atuais é possível alocar servidores virtuais de forma muito mais
simples para demandas não planejadas. Esse caso da solução
em cloud é mais um exemplo que demostra a flexibilidade e custo
que uma solução externa possui sobre uma solução interna sem
subcontratação de serviços de TI.
A Figura 11 ilustra os elementos de um ativo de serviços segundo
(ITIL, 2005):
Figura 11 – Ativos de serviços.
Fonte: adaptado pelo autor de (ITIL, 2005).
3.2 Portfólio de Serviços
É o conjunto de serviços de um fornecedor. A correta gestão do
portfólio permite que as organizações priorizem adequadamente os
recursos e investimentos para o desenvolvimento e entrega de serviços de
TI. Segundo (ITIL, 2005) um portfólio de serviços se divide de acordo com o
ciclo de vida do serviço:
funil de serviços;
catálogo de serviços;
serviços obsoletos.
O funil de serviços corresponde ao inventário de serviços de TI que
estão em planejamento, priorização de execução, avaliação e
desenvolvimento. São todos os serviços que ainda não estão disponíveis
ao cliente final para utilização. É uma visão futura dos serviços que serão
adicionados e disponibilizados no portfólio de serviços da organização.
Também recebe o nome de pipeline de serviços.
O catálogo de serviços é o inventário com todas as informações dos
serviços de TI em produção, em implantação e correntemente utilizados
pelos clientes finais. Os serviços de TI do catálogo de serviços auxilia a
organização cliente a entregar o seu valor de negócio. São atividades
necessárias para o pleno funcionamento da organização. Sugerem-se as
seguintes informações como exemplos de serem armazenadas no
catálogo de serviços a respeito de cada serviço de TI disponível para
utilização:
datas de entrega;
preços;
disponibilidade;
pessoas de contato e responsáveis em causa de problemas em
produção;
processos de solicitações de alteração ou adição de serviços.
Os serviços obsoletos são serviços desativados pela organização
que não estão mais em produção e ficam documentados para efeitos de
lições aprendidas ou futura reativação necessária.
A Figura 7 ilustra o funil e pipeline de serviços:
Figura 12 – Funil e pipeline de serviços.
Fonte: <http://www.entry.com/wp-content/uploads/2013/02/f unnel-v s-pipeline.png>.
3.3 Fornecedores
Segundo (ITIL, 2005) os fornecedores são os provedores de
serviços externos a uma organização cliente. Sejam serviços de apoio ou o
portfólio completo de serviços. Conforme mencionado anteriormente, nota-
se uma tendência e movimento no mercado de TI em direção aos serviços
de cloud (cloud services) como, por exemplo, processamento e
armazenamento remoto. O movimento deve-se a maior facilidade de alocar
e liberar stacks virtuais de hardware na cloud. Como usualmente o negócio
demanda mudanças rápidas, a frequência das mudanças impacta
diretamente a habilidade do time de TI entregar a melhor experiência para
http://www.entry.com/wp-content/uploads/2013/02/funnel-vs-pipeline.png
os seus clientes. Os serviços remotos esbarram na questão de segurança
e vazamento de informações confidenciais uma vez que são armazenadas
remotamente à organização. Esse é o um desafio a ser resolvido pelos
provedores de serviços na cloud.
O mercado de tecnologia utiliza os modelos de fornecimento de
serviços descritos abaixo do ponto de vista do tipo de contratação:
Fornecimento interno: a própria organização possui os recursos
humanos e materiais para a entrega dos serviços de TI desde o
desenho à entrega dos mesmos em produção;
Terceirização ou full-outsourcing: nesse modelo o cliente transfere
toda ou parcial responsabilidade sobre os serviços de TI. As
atividades variam conforme o contrato e podem mesclar
responsabilidades totais ou parciais dos serviços. Por exemplo: a
empresa cliente não possui habilidades em teste e já possui
relacionamento com uma empresa especializada em
planejamento e execução de testes em ativos de TI. Com o
objetivo de otimizar o ciclo de desenvolvimento a empresa cliente
fica responsável por todo o ciclo de desenvolvimento do produto
de software com exceção do planejamento e execução dos testes.
As quais serão subcontratadas a uma organização especialista
na área;
Parceria: relacionamento entre organizações com benefícios
mútuos e com objetivos em comum. Por exemplo, uma parceria
para troca de experiências e desenvolvimento de pessoal entre
duas organizações não concorrentes;
Terceirização de Processos de Negócio: além do serviço engloba
também a transferência da responsabilidade de execução, como
por exemplo: serviços de recursos humanos para contratação de
profissionais e serviços de call-centers que podem ser totalmente
contratados, definidos e executados fora da organização cliente.
Sendo assim o cliente recebe somente o resultado do trabalho
realizado (sejam os novos profissionais no caso de contratação,
sejam os clientes atendidos pelo helpdesk). Nesse modelo a
empresa cliente ainda é responsável pela definição do processo
a ser executado pelo fornecedor;
Provedor de Serviço de Aplicativo: o fornecedor nesse caso provê
hardware e software para o cliente. Esse modelo também é
conhecimento no mercado de tecnologia como Software as a
Service (SaaS). Os ativos de software são alocados no fornecedor
e o cliente via Internet acessa o aplicativo disponível. Alguns
exemplos estão disponíveis nesse modelo, tais como serviços de
correio eletrônico e aplicativos ERP disponíveis remotamente;
Terceirização de Processos de Conhecimento: nesse modelo o
fornecedor provê também o conhecimento de determinada área
de negócio ou conhecimento. Ao contrário da terceirização de
processos de negócio nesse caso o fornecedor é responsável por
definir o processo de negócio. Com o objetivo de reduzir custos de
operação e uma maior padronização com práticas de mercado o
cliente permite que o fornecedor defina os processos
organizacionais e ativos de serviço. Um exemplo desse modelo
são as constantes implantações de ERP que ocorrem no
mercado corporativo. Nota-se que os ERPs possuem processos
padronizados para as diferentes áreas funcionais das
organizações como sistemas financeiros e sistemas de recursos
humanos, por exemplo. O fornecedor através de consultores
especializados nos diferentes domínios de conhecimento (como
finanças e recursos humanos) definem processos e customizam
os processos padrões do ERP às necessidades dos clientes.
3.4 Acordo
É o documento que descreve o entendimento entre um fornecedor e
um cliente. Sendo que o relacionamento pode ser interno entre dois
departamentos dentro da mesma organização ou através de duas
organizações distintas. O acordo não tem valor legal e serve apenas como
referência para esclarecer o atendimento de metas. Como tipos de
acordos listam-se a seguir:
Acordo de Nível Operacional (ANO);
Acordo de Nível de Serviço (ANS) ou Service Level Agreement
(SLA).
O Acordo de Nível Operacional (ANO) é um acordo firmado entre
duas unidades ou departamentos da mesma organização. Por exemplo, o
provedor de serviços de TI e o departamento de recursos humanos que
proverá os profissionais necessários para a execução de um projeto
estratégico para toda a organização.
O Acordo de Nível de Serviço (ANS) ou Service Level Agreement
(SLA) é o acordo firmado entre o fornecedor do serviço de TI e um cliente.
Nesse acordo são descritos o serviço de TI, as metas de nível de serviço e
a definição das responsabilidades do prestador do serviço e do cliente.
Por exemplo, uma maneira muitoacadêmica para descrever um serviço de
TI para melhor entendimento do ANS e seus elementos seria:
Descrição do Serviço: operação da produção do ambiente XYZ;
Metas de nível de serviço: 95% de uptime 24h por dia 7 dias por
semana;
Responsabilidades do cliente: prover infraestrutura necessária
para realizar o serviço tal como hardware e software e realizar o
pagamento das horas trabalhadas no dia 5 de cada mês,
conforme fatura apresentada pelo fornecedor;
Responsabilidades do fornecedor: prover pessoal qualificado
para realizar o trabalho requerido com qualidade, custo e tempo
acordados.
Ao definir o nível de serviço as partes (cliente e fornecedor)
negociam, acordam e documentam as metas de utilização e garantia dos
serviços de TI. Os clientes finais dos serviços são explicitados e as
entregas dos serviços monitoradas de acordo com as metas acordadas. O
acordo de nível de serviço deve documentar a expectativa e a percepção de
valor dos clientes em relação aos serviços de TI entregues.
Segundo (ITIL, 2005) existem três tipos de Acordos de Nível de
Serviço:
Acordos baseados no serviço: o fornecedor provê o mesmo
serviço para diversos clientes diferenciados, sejam internos ou
externos. Por exemplo, um provedor de serviços de correio
eletrônico padronizado para todos os clientes. Sendo assim todos
os clientes possuem a mesma experiência e percepção a
respeito do serviço fornecido. Igualmente o fornecedor é avaliado
pelos mesmos indicadores por todos os seus clientes. Os
serviços nesse evento tendem a ser genéricos
independentemente do cliente que contrata;
Acordos baseados no cliente: composto por todos os serviços
entregues a um único cliente. Os serviços são especializados
cliente a cliente. Os acordos são definidos de acordo com a
expectativa do cliente e não podem ser utilizados por outras
organizações clientes;
Híbridos: é a combinação de ambos, por exemplo, um ERP
customizado e remoto no fornecedor.
São elementos que podem ser documentados como parte do
acordo do nível de serviço:
requisitos de qualidade para serviços novos ou alterados;
medidas de desempenho dos serviços;
medidas para a satisfação dos clientes em relação aos serviços
de TI definidos;
processos para registrar as reclamações, escalações e elogios
dos clientes a respeito do serviço de TI;
relatórios de informações sobre a realização e entrega dos
serviços contra as metas de serviços definidas e a periocidade
em que esses relatórios são disponibilizados às partes
envolvidas.
A Figura 13 ilustra os elementos de um acordo de nível de serviço
segundo (ITIL, 2005):
Figura 13 – Elementos de acordos de nível de serviço.
Fonte: adaptado pelo autor de (ITIL, 2005).
3.5 Contrato
Para (ITIL, 2005) o contrato é um documento com valor legal entre
um fornecedor e um cliente que descreve o entendimento formal e a
definição de obrigações para atendimento de metas entre as partes.
Segundo (PMBOK, 2013) os seguintes tipos de contratos são
encontrados no mercado:
Contratos de preço fixo (ou caixa preta): nessa categoria o preço
final do contrato é determinado no início do projeto. Os
fornecedores ficam com o maior risco de perdas financeiras, pois
são obrigados legalmente a cumprirem o contrato mesmo com
prejuízos oriundos de estimativas imprecisas. Os clientes devem
definir com clareza e precisão os produtos ou serviços a serem
implementados. Especialmente em projetos de tecnologia a
definição clara de requisitos impõem riscos adicionais ao
fornecedor que tem que definir o custo total do contrato durante as
fases iniciais do projeto. Os contratos de preço fixo também
possuem a opção de incentivos financeiros na casualidade de o
fornecedor reduzir custos ou prazos de entrega. A seguir as
opções existentes para contratos de preço fixo:
Contratos de preço fixo garantido (PFG): é o preferido pelas
organizações clientes, pois o preço dos serviços é determinado
no princípio do processo de contratação, a menos que exista
mudança de escopo e negociação entre as partes. Desse modo o
cliente deve definir claramente os requisitos de serviço contratado.
Esse é exatamente o maior desafio para os projetos de
tecnologia, nos quais usualmente as necessidades do cliente
“amadurecem” ao longo da execução do projeto. Isto é, esse é
tipo de contrato mais utilizado por licitações da Administração
Pública Brasileira (LEI Nº 8.666);
Contrato de preço fixo com remuneração de incentivo (PFRI):
permanece o conceito de preço fixo com incentivos financeiros
para o fornecedor nos casos de desempenho superior ao definido
no contrato. Reduções de custos e de prazos em relação ao
definido no contrato são convertidos em prêmios financeiros aos
fornecedores. As metas de desempenho são definidas como
parte do contrato, assim como os prêmios financeiros a serem
pagos ao fornecedor;
Contratos de custos reembolsáveis: essa categoria de contratos
envolve reembolsos de custos para todas as despesas incorridas
a partir do trabalho concluído, acrescidos da remuneração e lucro
do fornecedor. Esse tipo de contrato é mais adequado quando
não se possui total clareza do produto ou serviço a ser entregue.
Dessa forma, tanto cliente como fornecedor possuem maior
flexibilidade para definir os requisitos ao longo da execução do
trabalho. Igualmente nesse tipo de contrato metas de
desempenho de engenharia, de cronograma e custos são
predefinidos em contrato para auxiliar no controle e
relacionamento entre as partes. Os contratos de custos
reembolsáveis são bastante adequados para projetos de
pesquisa e desenvolvimento de novos produtos e serviços.
Apresenta-se a seguir os tipos de contratos nessa categoria:
Contratos de custo mais remuneração fixa (CMRF): o cliente
reembolsa todas as despesas definidas em contrato e
adicionalmente a remuneração do fornecedor para realizar o
trabalho a qual é paga somente após a conclusão do trabalho ou
etapas predefinidas em contrato. Uma modalidade desse tipo de
contrato determina que o lucro do fornecedor é calculado a partir
de um percentual dos custos do projeto o qual expõe o cliente a
um risco de perda de controle dos custos ainda maior;
Contratos de custo mais remuneração de incentivo (CMRI): nesse
modelo o cliente também reembolsa todas as despesas
definidas em contrato, porém provê incentivos financeiros se o
desempenho estabelecido no contrato for superado pelo
fornecedor. Tanto as metas de desempenho quanto o bônus por
desempenho superior são claramente definidos no contrato. Nas
situações de desempenho inferior ao estipulado no contrato o
fornecedor poderá arcar com as despesas e retrabalho gerados
na execução do trabalho. Todos esses aspectos devem
obrigatoriamente ser definidos no contrato com o objetivo de evitar
disputas judiciais entre as partes no caso de desacordo ao longo
do desenvolvimento;
Contratos por tempo e material (T&M): são tipos de contratos
híbridos entre o preço fixo e os contratos de custos
reembolsáveis. São mais adequados para aumento de pessoal
para necessidades esporádicas e de curta duração (conhecido no
mercado de tecnologia como body shop), aquisição de
especialistas e quando não é possível determinar rapidamente os
requisitos do produto ou serviço a ser desenvolvido.
A seguir, a Figura 8, apresenta o espectro de riscos envolvidos no
relacionamento entre cliente e fornecedor quanto aos tipos de contratos
apresentados:
Figura 14 – Espectro de risco em contratos.
Fonte: adaptado pelo autor disponív el em:
<http://learnline.cdu.edu.au/units/hit241/images/buy errisk.jpg>.
3.6 Principal Indicador de Desempenho (PID)
O ciclo do (ITIL, 2005) que define a melhoria da qualidade de serviço
é denominada de Melhoria Continuada de Serviços. O conceito de
melhoria contínua se baseia no constante desenvolvimento e melhoria de
processos e resultados objetivando aprimoramento de execução, redução
de custos, aumento de produtividade e economia de recursos naturais e
humanos. Modelos de qualidade da administração como o ciclo PDCA
(Liker, 2004) e o modelo KAIZEN (Liker, 2004) definem processos que
podem ser aplicadospara a gestão da melhoria continuada de serviços. A
filosofia KAIZEN japonesa, por exemplo, tem como lema para a melhoria
contínua para objetivar em maior qualidade de serviços e produtos:
“Hoje melhor que ontem, amanhã melhor que hoje.”
Os motivadores da melhoria de serviços são fatores de negócio e
fatores técnicos. No caso dos fatores de negócio, busca-se maior
alinhamento com a estratégia de negócio permitindo que o serviço
http://learnline.cdu.edu.au/units/hit241/images/buyerrisk.jpg
agregue maior valor final ao cliente e negócio. No caso dos fatores
técnicos, atinge-se a melhoria através de automações ou das novas
tecnologias que simplificam os processos de negócio.
A forma de medir e garantir que um serviço está melhorando a
percepção de qualidade perante aos seus clientes passa pela definição
de um principal indicador de desempenho (PID) ou key performance index
(KPI). O PID é a métrica utilizada para identificar e medir a capacidade de
processo e a percepção de qualidade do serviço de TI. A partir de
frequentes coletas ao longo do ciclo de vida do serviço comparam-se os
resultados coletados ao longo do tempo. A partir das coletas definem-se
metas para melhoria de serviço objetivando redução de custos e aumento
de produtividade. Para serviços de TI usa-se engenharia de software (KAN,
2002).
3.7 Exercícios sobre serviços e contratos em TI
a. Descreva a gestão de continuidade de serviço segundo o ITIL.
b. Como a Gestão de Segurança no ITIL impede o acesso de
usuários não autorizados aos dados da organização?
c. Qual a responsabilidade do Change Manager no processo de
Gestão de Mudanças segundo o ITIL?
d. Quais os processos do Gerenciamento Financeiro de Serviços
de TI segundo o ITIL?
e. Explique a diferença entre contratos de preço fixo e contratos com
incentivo de entrega.
f. Descreva o objetivo do Principal Indicador de Desempenho (PID)
para o ITIL no processo de melhoria de processo.
g. Quais são os tipos de acordo de nível de serviço definidos pelo
ITIL. Liste-os e compare-os em suas diferenças.
h. Descreva o seu entendimento sobre portfólios de serviços
conforme definição do ITIL.
i. Diferencie os provedores de serviços internos, dos provedores
de serviços compartilhados e dos provedores de serviços
externos segundo a definição do ITIL.
j. Descreva e diferencie contratos de parceria dos contratos de
terceirização de serviços.
CAPÍTULO 4
EXERCÍCIOS DE REVISÃO CONTENDO O CONTEÚDO
COMPLETO DA DISCIPLINA
1. Escolha a opção correta que justifica a decisão de realizar um
trabalho via contratação externa:
a. ( ) Falta de fornecedores.
b. ( ) Falta de conhecimento interno na organização
cliente.
c. ( ) Falta de serviços disponíveis na organização
fornecedora.
d. ( ) Sobra de mão de obra na organização fornecedora.
e. ( ) Falta de conhecimento interno na organização
fornecedora.
2. Segundo o ITIL (IT Infrastructure Library) os indicadores chave de
desempenho (KPI) são usados para:
a. ( ) Ajustar cada um dos processos de gerenciamento
de serviços de TI.
b. ( ) Melhorar o relacionamento entre a área de TI e os
seus clientes internos e externos.
c. ( ) Gerenciar a continuidade dos serviços de TI.
d. ( ) Construir processos de controle.
e. ( ) Mensurar para cada processo da organização se os
fatores críticos de sucesso são atingidos.
3. Quais processos compõem o PMBOK® do ponto de vista de
aquisições:
a. ( ) Controlar aquisições, estimar aquisições e decisão
de make or buy.
b. ( ) Administrar obrigações, definir pessoas autorizadas
e definir obrigações contratuais.
c. ( ) Planejar, conduzir, administrar e encerrar aquisições.
d. ( ) Monitorar o desempenho do contrato, realizar
mudanças e documentar decisões.
e. ( ) Planejar aquisições e encerrar aquisições.
4. Segundo o MPS.Br o plano de aquisições contém:
a. ( ) Os resultados do processo utilizado para revisão
dos requisitos especificados como, por exemplo,
relação dos interessados.
b. ( ) Os requisitos e restrições definidas pelo cliente,
incluindo requisitos dos interessados.
c. ( ) As condições, tarefas e responsabilidades pela
execução dos testes necessários para a aceitação do
S&SC a ser adquirido.
d. ( ) Objetivos específicos a serem alcançados com a
aquisição, os riscos envolvidos e um plano de projeto.
e. ( ) As condições de entrega, além das condições
gerais esperadas da aquisição, prazos e valores
envolvidos.
5. Descreva os quatro processos listados abaixo, proposto pelo
PMBOK® para gerência das aquisições, destacando como os
processos relacionam-se entre si:
a. planejar o gerenciamento das aquisições;
b. conduzir as aquisições;
c. controlar as aquisições;
d. encerrar as aquisições.
6. Descreva o seu entendimento sobre Acordo de Níveis de
Serviços (SLA) e como ele impacta o relacionamento entre duas
organizações de TI. Cite um exemplo possível de aplicação de
SLA entre duas organizações de TI.
7. Descreva segundo o MPS.Br as razões que determinam uma
organização decidir que um contrato será realizado por um
fornecedor externo.
8. Diferencie conceitualmente “service support” de “service delivery”.
9. Descreva o seu entendimento sobre Acordo de Níveis de
Serviços (SLA) e como ele impacta o relacionamento entre duas
organizações de TI. Cite um exemplo possível de aplicação de
SLA entre duas organizações de TI.
CAPÍTULO 5
GABARITO DOS EXERCÍCIOS DE REVISÃO
1. B
2. E
3. C
4. C
5. Descreva os quatro processos listados abaixo, proposto pelo
PMBOK® para gerência das aquisições, destacando como os
processos relacionam-se entre si:
Planejar o gerenciamento das aquisições
Resposta: O processo de documentação das decisões de
compras do projeto, especificando a abordagem e identificando
fornecedores em potencial é um processo da fase de
planejamento.
Conduzir as aquisições
Resposta: O processo de obtenção de respostas de
fornecedores, seleção de um fornecedor e adjudicação de um
contrato é um processo da fase de execução.
Controlar as aquisições
Resposta: O processo de gerenciamento das relações de
aquisição, monitorando o desempenho do contrato e realização
de mudanças e correções conforme necessário é um processo
da fase de controle.
Encerrar as aquisições
Resposta: O processo de finalizar todas as aquisições do projeto
é um processo da fase de encerramento.
6. Descreva o seu entendimento sobre Acordo de Níveis de
Serviços (SLA) e como ele impacta o relacionamento entre duas
organizações de TI. Cite um exemplo possível de aplicação de
SLA entre duas organizações de TI.
Resposta: SLA (Acordo de Níveis de Serviços) – determina as
responsabilidades e o tempo de resposta entre duas
organizações de serviços (uma cliente e outra fornecedora).
Exemplos:
Este acordo pode especificar as prioridades e impacto
dos incidentes em ambiente de produção.
Este acordo pode determinar o tempo de resposta para
defeitos durante o desenvolvimento do produto de
software.
7. Descreva as razões que determinam uma organização decidir
que um contrato será realizado por um fornecedor externo
segundo o MPS.BR.
Resposta: EXTRATO DA SEÇÃO DE MPS.BR
Identificam-se aqui as necessidades que a aquisição atenderá
(pode ser um desenvolvimento ou melhoria de um sistema, um
produto de software ou um serviço de software).
Analisa-se o que a organização precisa: por que ela está
adquirindo e o que ela pretende resolver ou atingir.
Nessa tarefa é definido, da melhor forma possível, o escopo das
necessidades: até onde o problema será atacado ou o tamanho
da meta que se quer atingir; interessante aqui estabelecer
quantificações mensuráveis, quando possível, para que se
possa saber, mais tarde, se foram atingidas.
Com essa primeira tarefa feita, uma decisão é tomada: o projeto
da aquisição vai seguir em frente? Caso afirmativo o que será
esperado ao final da aquisição?
Inicia-se a tarefa avaliando as necessidades que a aquisição
atenderá. O nome desse produto no MPS.BR é avaliação da
necessidade do S&SC.
Ao final da tarefa teremos o resultado da análise: resultado da
análise da necessidade da aquisição.
Importante