GerenciamentoServicosTI FINAL BAIXA PDF

Série TECNOLOGIA DA INFORMAÇÃO - hardware
GERENCIAMENTO
DE SERVIÇOS
DE TI
GERENCIAMENTO
DE SERVIÇOS
DE TI
CONFEDERAÇÃO NACIONAL DA INDÚSTRIA – CNI
Robson Braga de Andrade

Presidente
DIRETORIA DE EDUCAÇÃO E TECNOLOGIA - DIRET
Rafael Esmeraldo Lucchesi Ramacciotti

Diretor de Educação e Tecnologia
SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL – SENAI
Conselho Nacional
Robson Braga de Andrade

Presidente
SENAI – Departamento Nacional
Rafael Esmeraldo Lucchesi Ramacciotti

Diretor-Geral
Gustavo Leal Sales Filho

Diretor de Operações
GERENCIAMENTO
DE SERVIÇOS
DE TI
© 2012. SENAI – Departamento Nacional
© 2012. SENAI – Departamento Regional de Goiás
A reprodução total ou parcial desta publicação por quaisquer meios, seja eletrônico, mecâ-
nico, fotocópia, de gravação ou outros, somente será permitida com prévia autorização, por
escrito, do SENAI.
Esta publicação foi elaborada pela equipe do Núcleo Integrado de Educação a Distância do
SENAI de Goiás, em parceria com os Departamentos Regionais do Distrito Federal, Bahia e
Paraíba, com a coordenação do SENAI Departamento Nacional, para ser utilizada por todos
os Departamentos Regionais do SENAI nos cursos presenciais e a distância.
SENAI Departamento Nacional

Unidade de Educação Profissional e Tecnológica – UNIEP
SENAI Departamento Regional de Goiás

Núcleo Integrado de Educação a Distância – NIEaD
______________________________________________________________
S477t
SENAI-Departamento Regional de Goiás
Gerenciamento de serviços de TI/SENAI – Departamento
Regional de Goiás – Goiânia, 2012.
180p.: il.
1. Suporte técnico. 2. Tecnologia da informação. 3. Planejamento de

suporte. 4. Meio ambiente. 5.Gestão de projetos. 6. Educação a distância.
I. Autor. II. Título.
CDD – 004
______________________________________________________________
SENAI Sede
Serviço Nacional de Setor Bancário Norte • Quadra 1 • Bloco C • Edifício Roberto

Aprendizagem Industrial Simonsen • 70040-903 • Brasília – DF • Tel.: (0xx61) 3317-
Departamento Nacional 9001 Fax: (0xx61) 3317-9190 • http://www.senai.br
Lista de figuras, quadros e tabelas
Figura 1 - Boas práticas...................................................................................................................................................16
Figura 2 - ITIL......................................................................................................................................................................17
Figura 3 - COBIT.................................................................................................................................................................19
Figura 4 - Help....................................................................................................................................................................20
Figura 5 - Ciclo de vida de serviço..............................................................................................................................21
Figura 6 - Estratégia de serviço....................................................................................................................................22
Figura 7 - Desenho de serviço......................................................................................................................................23
Figura 8 - Transição de serviço.....................................................................................................................................24
Figura 9 - Operação de serviço....................................................................................................................................25
Figura 10 - Melhoria continua de serviço.................................................................................................................26
Figura 11 - Planejamento...............................................................................................................................................27
Figura 12 - Onde chegar.................................................................................................................................................30
Figura 13 - Modelo básico de planejamento..........................................................................................................31
Figura 14 - Exemplo de análise de Gap.....................................................................................................................32
Figura 15 - Portfólio de serviço....................................................................................................................................33
Figura 16 - Ciclo para definição dos serviços..........................................................................................................35
Figura 17 - Gerenciamento de demanda.................................................................................................................37
Figura 18 - Gerenciamento financeiro.......................................................................................................................40
Figura 19 - ITIL V3 – Ciclo de vida dos serviços......................................................................................................42
Figura 20 - Gerenciamento de nível de serviço......................................................................................................44
Figura 21 - Tipos de acordos.........................................................................................................................................45
Figura 22 - Gerenciamento da disponibilidade.....................................................................................................51
Figura 23 - Continuidade do negocio........................................................................................................................55
Figura 24 - Equilíbrio capacidade e demanda........................................................................................................60
Figura 25 - Gerenciamento da segurança da informação..................................................................................62
Figura 26 - Gerenciamento de mudanças................................................................................................................67
Figura 27 - Gerenciamento de liberação e implantação.....................................................................................70
Figura 28 - Gerenciamento do conhecimento.......................................................................................................73
Figura 29 - Gerenciamento de incidentes................................................................................................................76
Figura 30 - Processo de gerenciamento de incidentes.......................................................................................78
Figura 31 - Processo de gerenciamento de eventos............................................................................................81
Figura 32 - Processo de gerenciamento de requisições......................................................................................83
Figura 33 - Gerenciamento de problemas...............................................................................................................84
Figura 34 - Processo de gerenciamento de problemas.......................................................................................86
Figura 35 - Gerenciamento de acesso.......................................................................................................................88
Figura 36 - Melhoria continuada de serviço............................................................................................................90
Figura 37 - Otimização de recursos físicos e materiais........................................................................................98
Figura 38 - 5S......................................................................................................................................................................99
Figura 39 - Otimização de pessoas.......................................................................................................................... 101
Figura 40 - Alvo............................................................................................................................................................... 114
Figura 41 - Habilidades................................................................................................................................................ 117
Figura 42 - Áreas de conhecimento do gerenciamento de projetos.......................................................... 123
Figura 43 - Gerenciamento do tempo.................................................................................................................... 132
Figura 44 - Gerenciamento de custos..................................................................................................................... 137
Figura 45 - Gerenciamento das comunicações................................................................................................... 142
Figura 46 - Gerenciamento das aquisições........................................................................................................... 146
Figura 47 - Gerenciamento dos riscos.................................................................................................................... 149
Figura 48 - Ciclo PDCA.................................................................................................................................................. 159
Figura 49 - Organograma funcional........................................................................................................................ 161
Figura 50 - Organograma projetizado.................................................................................................................... 162
Figura 51 - Organograma matricial......................................................................................................................... 163
Figura 52 - Encerramento............................................................................................................................................ 167
Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática........................13

Quadro 2 - Identificação das responsabilidades.................................................................................................. 154
Tabela 1 - Modelos de pontuação............................................................................................................................. 166

Sumário
1 Introdução.........................................................................................................................................................................13
2 Suporte e visita técnica................................................................................................................................................15

2.1 Boas práticas associadas ao gerenciamento de serviços de TI....................................................16
2.2 ITIL no ambiente de serviços de suporte de TI..................................................................................20
2.3 Planejamento para entrega dos serviços de suporte de TI...........................................................26
2.4 Ações de planejamento para entrega dos serviços de suporte de TI........................................30
2.5 Gerenciamento de portfólio de TI..........................................................................................................33
2.6 Gerenciamento de demanda...................................................................................................................37
2.7 Gerenciamento financeiro........................................................................................................................40
2.8 Gerenciamento de nível de serviço (GNS)...........................................................................................44
2.9 Gerenciamento de catálogo de serviços.............................................................................................49
2.10 Gerenciamento da disponibilidade.....................................................................................................51
2.11 Gerenciamento de continuidade de serviço de TI.........................................................................55
2.12 Gerenciamento de fornecedores.........................................................................................................58
2.13 Gerenciamento da capacidade.............................................................................................................59
2.14 Gerenciamento da segurança da informação.................................................................................62
2.15 Gerenciamento de ativo e configuração de serviço.....................................................................65
2.16 Gerenciamento de mudanças...............................................................................................................67
2.17 Gerenciamento de liberação e implantação....................................................................................70
2.18 Gerenciamento do conhecimento......................................................................................................73
2.19 Gerenciamento de incidentes...............................................................................................................76
2.20 Gerenciamento de eventos....................................................................................................................80
2.21 Gerenciamento de requisição...............................................................................................................83
2.22 Gerenciamento de problemas..............................................................................................................84
2.23 Gerenciamento de acesso......................................................................................................................88
2.24 Melhoria continuada de serviço...........................................................................................................90
3 Meio ambiente.................................................................................................................................................................97
3.1 Otimização de recursos físicos materiais.............................................................................................98
3.2 Otimização de recursos físicos humanos......................................................................................... 101
3.3 Otimização de recursos ambientais................................................................................................... 105
3.4 Otimização de recursos financeiros.................................................................................................... 108
4 Gestão de projetos...................................................................................................................................................... 113

4.1 O que é um projeto.................................................................................................................................. 114
4.2 O que é gerência de projetos................................................................................................................ 116
4.3 Habilidades necesssárias para um gerente de projetos.............................................................. 117
4.4 Gestão de projetos no contexto do ambiente de serviços de suporte de TI....................... 119
4.5 Grupos de processos do gerenciamento de projetos.................................................................. 121
4.6 Áreas de conhecimento do gerenciamento de projetos............................................................ 123
4.7 Gerenciamento de integração do projeto........................................................................................ 126
4.8 Gerenciamento do escopo do projeto.............................................................................................. 130
4.9 Gerenciamento do tempo do projeto............................................................................................... 132
4.10 Gerenciamento de custos do projeto.............................................................................................. 137
4.11 Gerenciamento das comunicações do projeto............................................................................ 142
4.12 Gerenciamento das aquisições do projeto.................................................................................... 146
4.13 Gerenciamento dos riscos do projeto............................................................................................. 149
4.14 Gerenciamento dos recursos humanos do projeto.................................................................... 153
4.15 Gerenciamento da qualidade do projeto...................................................................................... 156
4.16 Estruturas organizacionais.................................................................................................................. 159
4.17 Análise de viabilidade do projeto..................................................................................................... 163
4.18 Encerramento do projeto.................................................................................................................... 167
Referências......................................................................................................................................................................... 173
Minicurrículo do autor................................................................................................................................................... 175
Índice................................................................................................................................................................................... 177
Introdução
Caro aluno, nesta unidade curricular você conhecerá a importância de um bom planejamen-
to para a qualidade do serviço de TI, conhecendo ferramentas e boas práticas de gerenciamen-
to para alcançar o desejado.
Aprenderemos como aplicar os procedimentos de otimização de recursos físicos, materiais,
humanos e financeiros, visando à redução de erros e consequentemente a melhoria do serviço
prestado.
A seguir, são descritos na matriz curricular os módulos e as unidades curriculares do curso,
assim como suas cargas horárias.
Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática
CARGA CARGA HORÁRIA

MÓDULOS UNIDADES CURRICULARES
HORÁRIA DO MÓDULO
Fundamentos para Documentação Técnica 140h

Básico Eletroeletrônica Aplicada 120h 320h
Terminologia de Hardware, Software e Redes 60h
Arquitetura e Montagem de Computadores 160h

Instalação e Manutenção de Computadores 250h
Instalação e Configuração de Rede 160h
Específico I Segurança de Dados 50h 880h

Sistemas Operacionais 120h
Gerenciamento de Serviços de TI 80h
Tendências e Demandas Tecnológicas em TI 60h
Bons estudos!
Suporte e visita técnica
O profissional de TI responsável pelo suporte técnico cuida da manutenção da estrutura

física de computadores, da estrutura de rede e de sistemas operacionais.
Gerenciar a entrega de serviços na área de Tecnologia da Informação é uma tarefa complexa
que requer um conjunto de habilidades por parte dos gerentes. O ITIL e o COBIT são conjuntos
de boas práticas que existem no mercado para auxiliar os profissionais desta área de suporte
nesta tarefa.
Você irá perceber que o planejamento é fundamental na área de suporte, já que através de
um bom planejamento é possível saber para onde se quer ir e o que é necessário fazer para
alcançar seus objetivos. Sem um plano de ação adequado, não há como medir a qualidade do
atendimento, tampouco o nível de satisfação dos usuários.
Ao final deste capítulo você será capaz de definir:
a) as boas práticas associadas ao gerenciamento de serviços de TI;
b) como utilizar o ITIL como apoio na execução destes serviços;
c) o planejamento e suas ações para entrega dos serviços de suporte de TI;
d) variados tipos de gerenciamento;
e) melhoria continuada de serviço.
gerenciamento de serviços de ti
16
2.1 BOAS PRÁTICAS ASSOCIADAS AO GERENCIAMENTO DE SERVIÇOS DE TI
Dreamstime (2012)
Figura 1 - Boas práticas
Você já ouviu falar em boas práticas de gerenciamento de serviços na área de

Tecnologia da Informação? Pois saiba que elas existem!
Atualmente, os principais modelos adotados para a organização de processos
na área de TI são: ITIL e COBIT. Porém, não basta saber apenas da existência des-
ses métodos, não é mesmo? Por esse motivo, vamos conhecê-los um pouco mais.
Preparado? Então vamos lá!
ITIL
A ITIL (Information Technology Infrastructure Library – Biblioteca de Infraestru-

tura de Tecnologia da Informação) é um modelo de referência que define uma
série de boas práticas em gerenciamento de serviços de TI. Em outras palavras,
trata-se de um conjunto de recomendações baseadas em ações eficazes na área
em questão.
Por se tratar de uma recomendação, a ITIL não pode ser considerada exata-
mente como uma norma, uma vez que não define uma metodologia – conjunto
de regras utilizadas em uma determinada disciplina e que denota rigidez de apli-
cação (conformidade).
A primeira versão da ITIL foi elaborada na década de 1980, pela CCTA (Central
Computer and Telecommunications Agency), uma empresa do governo britânico.
Essa primeira versão foi chamada de GITM (Government Information Technology
Infrastructure Method – Método de Governo de Infraestrutura de Tecnologia da
2 Suporte e Visita Técnica
17
Informação). O GITM tinha como objetivo atender a uma crescente dependência

do governo em relação à TI, no que dizia respeito à padronização de suas práticas.
Devido a interesses de outras entidades nas práticas do governo britânico, e
também por ter em seu nome a palavra “método”, em 1989 o GITM foi renomea-
do para ITIL.
Na ocasião, foi lançada a versão 1 da ITIL, composta por 31 livros. O uso dessa
versão ocorreu principalmente na Europa.
No ano de 2000, a ITIL foi revisada, ocorrendo o lançamento da versão 2 . Os 31
livros da primeira versão foram convertidos em 7 livros, organizados em uma fun-
ção e dez processos relacionados entre si. A partir da versão 2, a ITIL foi difundida
e passou a ser aceita mundialmente.
Hoje, a ITIL está na versão 3, composta por 5 livros: Estratégia de Serviço, Dese-
nho de Serviço, Transição de Serviço, Operação de Serviço e Melhoria de Serviço
Continuada.
rnanc e Methods
Gove St a
nda
rds
ills Al
lig
d Sk nm
an en
ge Continual Service t
ed Improvement
l
ow
Kn
Ca
se
Stu
Service Design
dies
cs
Topi
Sp ec ialt y
Services
Strategies
Templates
ITIL
Execut
Service Service
Operation Transition
Continual Continual
ive I
Service Service
Improvement Improvement
nt r
it y
od
bil
uc
t io
ala
n
Sc
St s
ud in
Odirlei Batista (2012)
yA kW
i ds ic
Qu
Qualification
Figura 2 - ITIL
18
COBIT
COBIT (Control Objectives for Information and Related Technology) é um modelo

de governança de TI que foi desenvolvido pela ISACA (Information Systems Audit
and Control Association – Associação de Auditoria e Controle de Sistemas de Infor-
mação) e hoje é mantido pelo ITGI (IT Governance Institute).
Trata-se de um modelo utilizado em todo o mundo. Seu principal propósito
é ajudar no mapeamento dos objetivos de negócio da empresa em relação aos
objetivos da área de Tecnologia da Informação.
A missão do modelo COBIT é: pesquisar, desenvolver, publicar e promover um
conjunto de objetivos de controle para uma tecnologia que seja embasada, atual,
internacional e aceita em geral para o uso no dia a dia de gerentes de negócio e
auditores. Sua visão é ser uma ferramenta para avaliação e governança de TI.
É importante saber que o COBIT é um modelo dividido em quatro domínios:
a) Focado no negócio da organização: ser focado no negócio significa que o
modelo “vê” a área de TI da perspectiva de negócio, observando os requisi-
tos de negócio da empresa e alinhando-os aos objetivos de TI. Em todos os
processos de negócio existe uma ligação com os objetivos da área de Tecno-
logia da Informação;
b) Orientado a processos: a orientação a processos está relacionada ao fato
de que sua organização interna é baseada em processos que visam facilitar
o gerenciamento;
c) Baseado em controles: para cada processo de TI há um objetivo de contro-
le definido. Esses controles são desenhados para dizer o que pode ser feito
em cada processo;
d) Orientado por métricas: o modelo fornece um conjunto de métricas que
permitem a medição do desempenho da área de TI como um todo.
Também é importante conhecer os domínios do COBIT, que são: planejamen-

to e organização; aquisição e implementação; entrega e suporte; e controle e ava-
liação.
19
IT Governance
overnance Req
and G ui re
i ness o me
Bu
s
n g Informati n and Tech nt s
bli nol
a og
En vering IT Processe y
De li s
Plan and
Organise
Di
Monitor and Co rect Acquire and
Goals Evaluate nt Implement
Metrics
ro
l
t
St ra
men
Deliver and
teg
re
Support
asu
ic
Re P
IT
Me
Ali
so roce
le
y
op
ur r it e
,P
gn
ss ce
ce Con atu re
an
m
s: A t rols and Proce ss M t u

en
c
rm
ppl s
stru t rol

Va
t
icat
ions, Information, Infra er
fo
,
lue Info on
De r mat i on C t ,P
live ion C
riteria and Applic
at en
ry, em
R isk M a nag
Manageme t Resouce
n,
Figura 3 - COBIT
Tanto o COBIT como a ITIL são utilizados por diversas empresas que entregam
serviços de TI. Ambos possuem foco no que precisa ser feito, não em como deve
ser feito. O “como” deve ser feito é uma prática intrínseca a cada organização e
pode variar de uma empresa para outra, conforme seu nível de maturidade na
execução dos processos de TI.
A adoção da ITIL é considerada uma estratégia para reduzir custos na entrega
de serviços de TI e aumentar a satisfação dos clientes. Diversas empresas exigem
certificação ITIL como pré-requisito na contratação tanto de profissionais como
de fornecedores. Logo, ter certificação ITIL é um diferencial para o profissional
que atua na área de TI.
SAIBA Acesse <http://www.itil-officialsite.com> para obter mais in-

formações sobre a ITIL e suas formas de certificação. Acesse
MAIS também o site oficial do COBIT: <http://www.isaca.org>.
20
Gerenciar a entrega de serviços na área de Tecnologia da Informação é uma

tarefa complexa que requer um conjunto de habilidades por parte dos gerentes,
não é mesmo? Para auxiliá-los nessa tarefa, estão disponíveis no mercado conjun-
tos de boas práticas. No conteúdo que acabou de ler, você conheceu as recomen-
dações mais utilizadas pelo mercado: a ITIL e o COBIT.
2.2 ITIL NO AMBIENTE DE SERVIÇOS DE SUPORTE DE TI
Denis Pacher (2012)

Figura 4 - Help
Além de conhecer as recomendações das boas práticas de gerenciamento de

serviços de Tecnologia da Informação, vamos ver também como elas podem ser
utilizadas para aprimorar a entrega dos serviços de suporte de TI.
TI COMO UM SERVIÇO
Serviço é um meio de entregar valor ao cliente, é a forma pela qual o cliente vê

o resultado gerado pela área de TI. Uma vez que a área de suporte de TI entrega
valor para seus clientes na forma de manutenção em computadores, sua função
deve ser vista como um serviço. Outros exemplos de serviços são: data center,
fábrica de software, desenvolvimento de software, projeto e suporte de rede etc.
O papel do modelo ITIL nesse contexto está no suporte ao planejamento, de-
senho, transição, operação e melhoria contínua dos serviços.
A ITIL recomenda a criação do cargo de gerente de serviço, que é a pessoa res-
ponsável pelo gerenciamento perante o cliente, para iniciação, transição, manu-
tenção e suporte de um determinado serviço. Suas principais atribuições são: con-
21
tato primário com o cliente para questões relacionadas ao serviço; garantia de que
a entrega e suporte do serviço atendam aos requisitos; identificação de oportuni-
dades de melhoria no serviço; auxílio no monitoramento da execução dos serviços.
GERENCIAMENTO DE SERVIÇO
É o conjunto de habilidades (capabilities) que, associadas a seus recursos (re-

soucers), é especializado em prover valor aos clientes na forma de serviços. Recur-
so é o termo genérico que inclui todos os elementos relacionados à infraestrutura
necessária para entrega dos serviços, tais como: pessoas, informações, hardware,
software, capital financeiro, estrutura física etc.
É importante que você saiba que os serviços devem ser gerenciados e pen-
sados durante todo o seu ciclo de vida. Segundo a ITIL, o ciclo de vida de um
serviço é composto por cinco fases: estratégia, desenho, transição de serviço,
operação e melhoria contínua do serviço. Em seguida, vamos ver com detalhes
cada uma dessas fases.
Melhoria de Serviço
Continuada
Desenho de Serviço
Estratégia
de Serviço
ITIL
Operação Transição
de Serviço de Serviço
Melhoria Melhoria
Continuada Continuada
Figura 5 - Ciclo de vida de serviço

22
a) Estratégia de serviço
Continuada
Desenho de Serviço
Estratégia
de Serviço
Melhoria Melhoria

Figura 6 - Estratégia de serviço
Durante essa fase, o valor do serviço é identificado e modelado. Segundo Frei-

tas (2010), um provedor de serviço deve reconhecer que seus clientes não com-
pram produtos, e sim o atendimento de suas necessidades. Logo, para que os ser-
viços possam ser entregues e seus clientes percebam seu valor, é necessário que
o seu provedor tenha um entendimento profundo de quem é o cliente, quando e
por que ele necessita de um serviço, quais são as suas necessidades, qual é a sua
expectativa de valor e como os serviços serão entregues.
Nesta fase, além de identificar as necessidades de seus clientes, a área de su-
porte de TI deverá planejar todos os elementos para atender às suas expectativas.
Por exemplo, itens como estrutura física dos laboratórios, técnicos, ferramentas e
softwares necessários para a entrega dos serviços devem ser planejados.
23
b) Desenho de serviço
Continuada
Desenho de Serviço
Estratégia
de Serviço
Melhoria Melhoria
Figura 7 - Desenho de serviço
Nesta etapa são projetados e modelados os serviços, e todos os seus recursos

e habilidades necessários para sua entrega. O desenho dos serviços inclui sua ar-
quitetura, processos, políticas e documentação.
Freitas (2010) cita cinco aspectos que devem ser considerados no desenho de
serviço:
a) requisitos funcionais, recursos e capacidades necessárias para entrega dos
serviços aos clientes;
b) as ferramentas necessárias para controlar os serviços por meio do seu ciclo
de vida;
c) desenho da arquitetura tecnológica e gerenciamento técnico necessário
para prover os serviços;
d) os processos necessários para transição, operação e melhoria contínua do
serviço;
e) métricas e sistemas de medição de serviços, das arquiteturas, processos e
atividades necessárias para entrega dos serviços.
24
1 MODUS OPERANDI Os processos da área de suporte de TI devem ser modelados com base no
que foi planejado na fase anterior. Por exemplo, o processo de manutenção de
É uma expressão em latim
que significa “modo de hardware deve ser especificado, ou seja, você deve definir o modus operandi1 da
operação”. Essa expressão é área de suporte de TI.
usada para se referir a uma
maneira de agir, operar ou
executar uma atividade,
seguindo sempre os c) Transição de serviço
mesmos procedimentos.
Continuada
Desenho de Serviço
Estratégia
de Serviço
Melhoria Melhoria
Figura 8 - Transição de serviço
Neste momento, o serviço e todos os seus recursos e habilidades necessários

para sua entrega são desenvolvidos, adquiridos, testados e colocados em produ-
ção, com o objetivo de garantir que sejam atendidos todos os requisitos plane-
jados e desenhados até aqui. Esta fase do ciclo corresponde ao planejamento do
projeto de implantação dos serviços que serão suportados na fase seguinte, a de
operação de serviço.
25
d) Operação de serviço
Continuada
Desenho de Serviço
Estratégia
de Serviço
Melhoria Melhoria
Figura 9 - Operação de serviço
Esta é a fase em que o serviço é mantido de modo a gerar o valor esperado

para seus clientes. Contempla as atividades do dia a dia de TI, coordenando e
conduzindo as atividades e os processos necessários para entregar e gerenciar os
serviços, de acordo com os níveis requeridos pelos clientes e pelo negócio.
Nesta fase, a área de suporte de TI deve cumprir os chamados Acordos de
nível de serviço. Esses acordos definem as “regras do jogo”, ou seja, a forma pela
qual a área deve trabalhar, estabelecendo um conjunto de metas que devem ser
alcançadas e os indicadores que devem ser colhidos para verificação dessas me-
tas. Por exemplo, a área de suporte de TI pode ter de atender seus usuários em no
máximo 12 horas após o registro de reclamação.
26
e) Melhoria de serviço continuada
Continuada
Desenho de Serviço
Estratégia
de Serviço
Melhoria Melhoria

Figura 10 - Melhoria Continua de serviço
O objetivo da melhoria de serviço continuada é alinhar e realinhar continu-

amente os serviços de TI com o negócio e com os requisitos de mudanças do
negócio por meio da implementação de melhorias nos serviços entregues pela
área de TI. O foco desta etapa é na melhoria da eficiência dos processos de geren-
ciamento de serviços de TI, considerando aspectos de custo, recursos humanos,
físicos etc.
A entrega dos serviços de suporte de TI pode ser aprimorada com a utilização
do modelo ITIL, que considera todo o ciclo de modelagem da entrega do serviço,
que vai desde a elaboração da estratégia até a melhoria contínua desse serviço.
Como você pôde perceber, o objetivo deste conteúdo foi descrever como as
recomendações da ITIL podem ser utilizadas para potencializar a entrega dos ser-
viços de suporte de TI.
2.3 PLANEJAMENTO PARA ENTREGA DOS SERVIÇOS DE SUPORTE DE TI
Agora que você já sabe como o modelo ITIL é estruturado, vamos entender
como esse conjunto de recomendações pode ser utilizado na prática. Você apren-
27
derá como o planejamento proposto pela ITIL pode ser utilizado durante a orga-
nização dos processos para a entrega dos serviços de suporte de TI.
Você já fez algum planejamento em sua vida pessoal ou profissional? O que
você deve ter claro é que o planejamento é o resultado de planejar. Ele engloba
processos e procedimentos na sua execução: são as ações do planejamento.
Por meio desse conjunto de ações temos o plano, que é o planejamento ex-
presso de forma escrita e estruturada. Nesse plano é descrito o passo a passo de
todo o processo de planejamento e os objetivos que devem ser alcançados em
todas as etapas.
Vamos juntos montar o plano para entrega dos serviços de suporte de TI?
PLANEJAMENTO
Plano de Negócios
IF trabalho
? ELSE $$
Figura 11 - Planejamento
Antes de começar a montar o nosso plano, vamos entender o que é plane-

jamento. De acordo com Sampaio (2011), trata-se de um processo contínuo e
dinâmico que consiste em um conjunto de ações intencionais, integradas, co-
ordenadas e orientadas para tornar realidade um objetivo futuro, possibilitando
a tomada de decisões com antecedência. Essas ações devem ser identificadas
para que permitiam a sua execução de forma adequada e considerando aspectos
como prazo, custos, qualidade, segurança, desempenho e outras condicionantes.
Fazer um planejamento tem vantagens: controle apropriado dos processos;
produtos e serviços entregues conforme os requisitos exigidos pelo cliente; re-
solução antecipada de problemas e conflitos; grau mais elevado de assertividade
nas tomadas de decisão.
28
O PROCESSO DE PLANEJAMENTO
No processo de planejamento temos seis etapas genéricas:

a) análise situacional;
b) definição de objetivos e elaboração de planos alternativos;
c) avaliação de objetivos e planos;
d) seleção de planos e metas;
e) implementação;
f) monitoração e controle.
Na análise situacional, todas as informações relevantes ao planejamento de-
vem ser colhidas, interpretadas e sintetizadas. Deve-se fazer uma análise da situ-
ação passada, atual e futura. Dentro das limitações de tempo e recursos, todas as
informações são reunidas nessa etapa. Nesse momento, temos como resultado
a identificação e o diagnóstico de hipóteses e dos problemas de planejamento.
A próxima etapa envolve a definição de objetivos e elaboração de planos
alternativos. Planos são os meios que os administradores dispõem para atingir
seus objetivos. Nessa etapa são esboçadas as alternativas para a realização de
cada meta.
Na avaliação de objetivos e planos, devem ser avaliadas as vantagens e des-
vantagens e os efeitos potenciais de cada objetivo e de cada plano alternativo.
Na etapa de seleção de planos e metas, devem ser identificadas as priori-
dades, ganhos e perdas relativos aos objetivos e planos. Após avaliar, é preciso
escolher, dentre as opções, as metas e os planos mais apropriados e viáveis. Uma
vez selecionados, o próximo passo é a implementação dos planos.
Implementação é a execução daquilo que foi planejado e especificado no
plano. Os melhores planos acabam sendo inúteis caso a implementação não seja
adequada. Portanto, fique atento!
A última etapa do processo é a monitoração e controle do plano. Nessa eta-
pa o desempenho da empresa na execução do plano deve ser continuamente
monitorado, no que diz respeito à sua eficiência e à sua eficácia.
OS NÍVEIS DE PLANEJAMENTO
No planejamento temos três níveis: estratégico, tático e operacional. Vamos

entender o que significa cada um dos níveis:
a) Estratégico: são as regras utilizadas para a tomada de decisão, ou seja, o
caminho para se chegar aos objetivos propostos no planejamento;
29
b) Tático: método ou habilidade para se colocar em prática as estratégias do

planejamento;
c) Operacional: são as operações rotineiras e diárias que alinham o tático com
o estratégico.
A palavra “estratégia” vem do grego estratégos, que

VOCÊ significa “general”. Na Grécia antiga, estratégia relacio-
nava-se a tudo o que um general determinava.
SABIA? “Estratégia é a ciência dos movimentos guerreiros fora
do campo de visão do general” (OLIVEIRA, 2011).
PLANEJAMENTO PARA ENTREGA DOS SERVIÇOS DE SUPORTE DE TI NA

PRÁTICA
Agora que já vimos alguns conceitos de planejamento, vamos ver como fun-
ciona na prática.
Quando a área técnica de uma empresa responsável pela entrega dos serviços
de suporte de TI (chamada daqui para a frente de área de suporte) está preparan-
do seu planejamento, primeiramente ela tem que identificar sua missão, visão e
seus objetivos.
A missão é sua razão de existir, ou seja, o que ela é. Por exemplo, a área de
suporte tem como missão a realização de testes de hardware e software com qua-
lidade.
A visão é aonde ela quer chegar com sua missão. Em outras palavras, qual é a
sua meta futura, considerando um requisito temporal de curto, médio ou longo
prazo. Por exemplo, a visão da área de suporte é alcançar 80% de satisfação de
seus clientes nos próximos seis meses.
Os objetivos são metas tangíveis (que podem ser medidas) de curto prazo,
que estão alinhadas à missão e contribuem para o alcance da missão. São exem-
plos de objetivos da área de suporte: atender aos chamados dos clientes em no
máximo 24 horas; dar o primeiro retorno ao cliente em até 48 horas após a entra-
da do equipamento em laboratório; enviar informações aos clientes (via e-mail ou
mensagens de celular), informando o andamento dos serviços etc.
O planejamento se encontra presente em muitos setores empresariais e até
mesmo em nossa vida. Fazer o planejamento para a área de suporte ajuda a mini-
mizar erros, com foco nos objetivos.
30
2 GAP
SAIBA Para saber mais sobre os níveis de planejamento tático dos

Do inglês, significa intervalo serviços de Gerenciamento de TI, acesse: <http://projetoseti.
ou distância. MAIS com.br/governanca/a-tatica-no-gerenciamento/>.
Você agora já sabe como o modelo ITIL pode ser utilizado durante a organiza-
ção dos processos para a entrega dos serviços de suporte de TI. Conhece o que é
planejamento, as vantagens de se planejar e as seis etapas genéricas que devem
ser seguidas em um processo de planejamento.
Você também tomou conhecimento dos níveis estratégico, tático e operacio-
nal. Por fim, viu na prática o planejamento para entrega dos serviços de suporte
de TI. Com base nisso tudo, você pode concluir que o planejamento não se en-
contra apenas no mundo empresarial. As metas de nossa vida também podem
ser planejadas, não é mesmo? O nosso plano agora é fazer com que você teste os
seus conhecimentos! Vamos lá!
2.4 AÇÕES DE PLANEJAMENTO PARA ENTREGA DOS SERVIÇOS DE

SUPORTE DE TI
Disney (2012)
Figura 12 - Onde chegar
Chegou o momento de estudarmos as atividades práticas do planejamento.

Como comenta Lewis Carroll, em Alice no País da Maravilhas, “para quem não
sabe aonde ir, qualquer caminho serve”. Para que você não se sinta perdido, va-
mos aprender como o planejamento ajuda a traçar caminhos.
Planejar significa elaborar um conjunto de ações que permitirão que a área de
suporte saiba o que fazer para alcançar seus objetivos. A figura a seguir ilustra um
31
modelo básico para a realização do planejamento, com a finalidade de alcançar

os objetivos. Em seguida veremos cada uma dessas etapas.

Onde Onde Como chegaremos Como
queremos estamos onde queremos saberemos se
estar? agora? estar? chegamos?
Figura 13 - Modelo básico de planejamento

Fonte: Adaptado de Freitas (2010)
Segundo Ducker (1984, p. 47),
planejamento estratégico é um processo contínuo de, siste-

maticamente e com o maior conhecimento possível do futuro
contido, tomar decisões atuais que envolvam riscos; organizar
sistematicamente as atividades necessárias à execução destas
decisões e, através de uma retroalimentação organizada e sis-
temática, medir o resultado dessas decisões em confronto com
as expectativas alimentadas.
a) Onde queremos estar?

Para identificar onde gostaria de estar, a área de suporte deve promover um
debate entre seus integrantes com o objetivo de identificar melhorias. Pesquisas
de satisfação com seus usuários podem ser muito úteis. Escutar e registrar as re-
clamações dos clientes é um ponto-chave. Em seguida, os problemas identifica-
dos devem ser cuidadosamente analisados.
b) Onde estamos agora?
Uma vez identificado onde queremos estar, o próximo passo é analisar onde
estamos agora. Precisamos identificar todas as atividades que têm sido realizadas
pela área de suporte. A relação dessas atividades também deve ser especificada.
Mais importante que a notação utilizada é a definição dos processos. Ao definir
seus processos, a área de suporte estabelece como irá chegar aonde quer estar.
c) Como chegar aonde queremos estar?
Uma vez definido aonde a área de suporte quer chegar, e onde está no momen-
to, nesta fase deve ser medida a distância entre ambas e como fazer para diminuir
essa distância. Uma das técnicas mais utilizadas para isso é a análise de Gap2.
Análise de Gap é a análise da diferença ou distância entre os objetivos a se-
rem alcançados e onde estamos agora. Essa análise denomina as atividades que
não estão alinhadas aos objetivos ou não estão contribuindo para que estes se-
jam alcançados.
32
3 Portfólio Confira na figura abaixo um exemplo de Análise de Gap:
É uma lista de trabalhos de

um profissional ou de uma Avaliação dos Gaps de Competências
empresa.
6
5
4
Níveis
3
2
0
são
soas
os
o
ltado
gica
iação
jetos
e
mica
o
iva
te
çã
idad
zaçã
cess
Clien
iciat
Deci
nica
é
e Pes
Sistê
e Pro
Resu
strat
ego c
riativ
i
e Pro
rgan
5 - In
u
co no
e de
Com
nça d
ão E
ão d
7-N
isão
para
3-C
O
ão d
idad
4 - Fo
nto e
12 -
ç
9-V
Gest
dera
valia
ação
Gest
apac
jame
6 - Li
13 -
1-A
rient
10 -
2-C
lane
8-O
11- P

Competências
Nível Média Coord Média
Recomendado Obras Gestores
Figura 14 - Exemplo de análise de Gap
Uma vez conhecidos, os gaps devem ser resolvidos. Para isso, os processos de-
vem ser redesenhados. A esses novos processos dá-se o nome de “to be”. “To be”,
ou “como será”, é a situação futura desejada após a identificação dos gaps e do pla-
nejamento sobre como resolvê-los. Segundo Freitas (2010), a situação futura será
composta das mudanças necessárias na situação atual para o alcance dos objetivos.
d) Como saberemos que chegamos?
A última etapa do processo de planejamento é a verificação se os objetivos
foram atingidos. Para isso, métricas e indicadores devem ser definidos. Por exem-
plo, se atualmente a área de suporte tem um índice de retrabalho (computadores
que retornam após serem testados) de 30%, e o objetivo é diminuir esse índice
para 10%, devem ser definidos indicadores que determinem se esse percentual
está sendo alcançado.
Você viu que as ações do planejamento são fundamentais na área de suporte,
pois é importante que se saiba para onde se quer ir e o que é necessário fazer para
alcançar seus objetivos. Sem um plano de ação adequado, não há como medir
a qualidade do atendimento, tampouco o nível de satisfação dos usuários. Para
isso, foi apresentado um modelo básico que envolve questionamentos para a re-
alização de um planejamento e para que se possa atingir essas metas.
33
2.5 GERENCIAMENTO DE PORTFÓLIO DE TI
Você já ouviu falar em gerenciamento de portfólio3 de TI? É uma das princi-

pais subatividades que compõem os processos ITIL na fase de estratégia de ser-
viço, quando identificamos e modelamos o serviço que será entregue ao cliente.
Trata-se de uma ferramenta para priorizar investimentos e melhorar a alocação
dos recursos necessários à entrega dos serviços. O seu objetivo é garantir que os
investimentos nos serviços de TI agreguem valor para o negócio. Mas você sabe
como isso é feito na prática? Isso é realizado por meio da criação do portfólio de
serviços, que é uma ferramenta que descreve os serviços que um provedor dispo-
nibiliza para seus clientes. Vamos entender melhor? Acompanhe!
COMPOSIÇÃO DO PORTFÓLIO DE SERVIÇOS
Sistema de Gerenciamento de
Conhecimento de Serviços
Portfólio de Serviços
(conjunto completo de serviços
gerenciados por um provedor de
serviços)
(dos requerimentos à descontinuidade)
Duto de Serviços
Ciclo de Vida dos Serviços
(propostos ou em serviços de desenvolvimento)
Catálogo de Serviços Visível ao Cliente

(serviços de TI “vivos” incluindo os Catálogo de serviços de
disponíveis para distribuição) negócios
Visível à Equipe de Suporte

Catálogo dos serviços
técnicos
Serviços Descontinuados
(serviços e seus componentes que foram descontinuados)
Figura 15 - Portfólio de serviço

34
Basicamente, o portfólio de serviços é composto pelos seguintes itens: des-

crição do serviço; valor do serviço; descrição do caso de negócio; definição das
prioridades; análise de riscos; definição de ofertas, pacotes, custos e preços dos
serviços. Confira a seguir um pouco sobre cada um deles:
a) Descrição do serviço: caracteriza o serviço propriamente dito. Por exem-
plo: serviço de manutenção de computadores, serviço de desenvolvimento
de software ou serviço de suporte à rede e internet;
b) Valor do serviço: identifica o valor percebido pelo cliente em relação à uti-
lização dos serviços;
c) Descrição do caso de negócio: é descrita a necessidade de um novo serviço
em termos de custos envolvidos, modelo de serviço adotado, análises de im-
pacto no negócio, análise de cenários financeiros e benefícios para o negócio;
d) Definição das prioridades: são levantadas informações a respeito da im-
portância do serviço para o negócio da empresa. Essas informações são úteis
para dimensionar e provisionar as atividades relacionadas a esse serviço em
relação a outros;
e) Análise de riscos: é um dos itens mais importantes. Riscos geralmente são
eventos que afetam a qualidade dos serviços. São calculados pela proba-
bilidade de ocorrerem e pelo impacto no valor dos serviços. O nível de ex-
posição de uma empresa aos eventos de risco é conhecido como vulnera-
bilidade. A grande questão a ser tratada neste ponto é: como gerenciar os
riscos e tornar a empresa menos vulnerável? Esse gerenciamento envolve a
identificação dos riscos, o planejamento de medidas para minimizar a pro-
babilidade de ocorrência e o planejamento para minimizar o impacto dos
riscos, caso ocorram. São exemplos comuns de riscos associados à área de
TI: parada de um sistema crítico da empresa; uso de novas tecnologias emer-
gentes; falência de um provedor de serviço externo; atendimento a leis e re-
gulamentações; mudanças nos serviços impostas pelo negócio da empresa;
f) Definição de ofertas, pacotes, custos e preços dos serviços: neste mo-
mento, os serviços que serão entregues devem ser definidos obedecendo ao
ciclo representado pela Figura 4.
35
Definir Analisar Aprovar Contratar

Portifólio de Geração de
Casos de Valor e
Serviço Ativos de
Negócio Priorização
Autorizado Serviço
Figura 16 - Ciclo para definição dos serviços
O portfólio de serviços se preocupa em responder a algumas perguntas como:

por que um cliente compraria de nós um serviço? Qual preço estaria disposto a
pagar?
CICLO PARA DEFINIÇÃO DE SERVIÇOS
Conforme já vimos, existe um ciclo para a definição de serviços. Vamos saber

agora o que significa cada fase:
a) Definir os serviços significa coletar informações e fazer inventário dos ser-
viços existentes. Envolve ainda o estabelecimento dos requisitos para os no-
vos serviços solicitados;
b) Analisar os serviços é rever os objetivos de negócio de longo prazo e de-
terminar os serviços necessários para alcançá-los. Os serviços devem ser
analisados quanto à sua viabilidade financeira e capacidade operacional.
Por exemplo: você pode decidir obter o serviço de um terceiro em vez de
desenvolvê-lo internamente;
c) Aprovar é tomar decisões sobre manutenção, substituição, aprimoramento
ou retirada dos serviços do portfólio;
d) Contratar é a fase em que devem ser comunicadas as ações à organização
para implementação dos serviços aprovados e alocação de orçamento de
recursos necessários.
O resultado desse ciclo é a definição de três categorias de serviços. Veja mais
sobre elas a seguir.
36
CATEGORIAS DE SERVIÇOS
Três categorias de serviços são obtidas a partir da execução do ciclo de vida.

São elas:
a) Funil (pipeline) de serviços: consiste nos serviços que estão em desenvolvi-
mento ou sendo viabilizados para um determinado cliente;
b) Catálogo de serviços: é uma base de documentos estruturados que pos-
suem as informações sobre todos os serviços de TI em operação ou em vias
de entrar em produção. É a única parte do portfólio de serviço disponível
para visualização por parte do cliente;
c) Serviços obsoletos: são os serviços que já estão ultrapassados ou foram
aposentados. As informações desses serviços podem ser de grande utilidade
para a tomada de decisão em relação a investimentos futuros.
No site Mundo ITIL, na postagem intitulada The Service Catalog, são listados
alguns atributos que compõem o catálogo de serviços, tais como: uma descri-
ção do que trata (qual função) determinado serviço; acordos de nível de serviço
relacionados; privilégios de uso do serviço; custos associados ao uso; métodos
de execução (requisição) de uso; classificação ITIL; atividades relacionadas à ope-
ração; frequência de execução; indicadores explícitos de controle; matriz de res-
ponsabilidade.
SAIBA Para saber mais, acesse: <http://www.mundoitil.com.

MAIS br/2010/03/10/the-service-catalog/>.
Vimos até aqui várias informações sobre o portfólio de serviços. Você já sabe
que ele é composto pelos itens: descrição do serviço; valor do serviço; descrição
do caso de negócio; definição das prioridades; análise de riscos; e definição de
ofertas, pacotes, custos e preços dos serviços. Você também tomou conhecimen-
to de que o gerenciamento de portfólio de serviços é uma atividade importante
no que diz respeito à elaboração da estratégia de serviço da área de suporte de TI,
uma vez que nessa etapa os serviços que serão entregues por essa área serão de-
finidos, analisados, aprovados e contratados de acordo com as necessidades dos
usuários e a capacidade da área em atender a essa demanda. Por fim, conheceu as
três categorias de serviços, que são obtidas a partir da execução do ciclo de vida:
funil de serviços, catálogo de serviços e serviços obsoletos.
37
2.6 GERENCIAMENTO DE DEMANDA
Vamos pensar na seguinte situação: uma loja de vendas de produtos pela in-
ternet resolve fazer promoção de alguns de seus produtos em um único dia. Após
uma ampla divulgação com alto investimento na mídia, chega o grande dia. Mi-
lhares de clientes acessam o site para aproveitar as promoções, e o que acontece?
O servidor que armazena o site da empresa não dá conta do número de acessos
simultâneos e trava. Resultado: os clientes desistem das compras e a empresa tem
um enorme prejuízo.
Aplicações
de TI Produtos
Pedidos
Projetos
finalizados
Ideias
Iniciativas Propostas de
investimento
Gerenciamento de demandas
Revisão
Priorização
Aprovação
Projetos
Decisões de Produtos
investimento
Figura 17 - Gerenciamento de demanda
O que deveria ter sido feito para evitar esse problema? Pois bem, o gerencia-
mento de demanda pode ser parte da solução. Então, vamos conhecer o que é
gerenciamento de demanda?
38
OBJETIVO DO GERENCIAMENTO DE DEMANDA
O objetivo do gerenciamento de demanda é entender e influenciar as deman-

das dos clientes em relação às suas necessidades de serviços. Também se preocu-
pa com a provisão da capacidade para atender a essa demanda. Afinal, serviços
sem planejamento de demandas são fontes de risco para seus fornecedores, con-
forme vimos no exemplo, logo no início.
COMO É FEITO O GERENCIAMENTO DE DEMANDA?
O primeiro passo do gerenciamento de demanda é a análise da necessidade

atual do cliente com base na avaliação da capacidade atual dos serviços. Em se-
guida devem ser analisadas as necessidades sazonais e futuras do negócio.
Prover capacidade futura pode gerar uma capacidade ociosa da área de TI.
Entretanto, apesar de ociosa em determinados momentos, essa capacidade é im-
portante principalmente para lidar com problemas relacionados à sazonalidade
ou demandas futuras. Por exemplo, um site de comércio eletrônico deve estar
preparado para o aumento do número de acessos no Natal. Já os sites de compras
coletivas tiveram um crescimento assustador: de 1,7 milhão de usuários únicos
em junho de 2011, em julho esse valor foi para 2,9 milhões e em agosto subiu para
4,3 milhões. O crescimento desde o mês de junho foi de 231%.
A área de suporte de TI deve estar preparada para o aumento de demanda por
manutenção em hardware, quando há queda de energia em seu cliente, ou gran-
de quantidade de suporte em software quando os computadores são trocados e
há uma nova versão do sistema operacional.
Com base nessas análises, vários caminhos podem ser seguidos. Por exemplo,
contratação adicional de pessoas, mudanças nos processos de negócio ou upgra-
des de tecnologia.
Além de analisar a necessidade do negócio, também devem ser verificados os
perfis dos usuários que irão consumir os serviços de TI, tais como: pessoas, ativi-
dades de processos de negócio e até mesmo outras aplicações.
39
RESULTADO DO PROCESSO
Como resultado do processo de gerenciamento de demanda, são elaborados

os chamados pacotes de serviço. Há dois tipos deles: os pacotes de serviço prin-
cipal (PSP) e os pacotes de serviço de apoio (PSA).
Os PSP são os serviços que geram valor diretamente para o cliente, que o clien-
te deseja receber e pelos quais estão dispostos a pagar. Estão descritos no catá-
logo de serviços.
Os PSA são todos os serviços que apoiam, contribuem ou permitem que os ser-
viços principais sejam entregues aos clientes. Esses, por sua vez, estão descritos
no catálogo técnico.
RESPONSABILIDADES DO GERENTE DE DEMANDA
Freitas (2010) cita as seguintes atribuições do gerente de demanda:

a) identificar os requisitos de demandas dos serviços de TI;
b) gerenciar os recursos do processo de gerenciamento de demanda;
c) participar da elaboração dos acordos de nível de serviço;
d) influenciar as demandas de serviços.
Pacotes de nível de serviço (PNS) são níveis definidos

VOCÊ ativos de um serviço para um pacote de serviço
específico. Já as linhas de serviço são pacotes de
SABIA? serviços que possuem múltiplos PNS para um mesmo
seguimento de clientes.
Com base no que vimos até agora, é fácil de entender que o gerenciamento de
demanda poderia ter ajudado a resolver o problema da empresa exemplificada
no início da nossa leitura, pois conhecendo a situação (realização de uma pro-
moção de produtos em um único dia), o hardware necessário para atender a essa
demanda sazonal seria provisionado, evitando maiores prejuízos.
40
2.7 GERENCIAMENTO FINANCEIRO
Dreamstime (2012)
Figura 18 - Gerenciamneto financeiro
Você sabe como a área de suporte de TI pode cobrar pelos seus serviços?
Quanto e como cobrar por serviços são questões-chave que devem ser respondi-
das pelo gerenciamento financeiro. Vamos conhecê-lo?
OBJETIVO DO GERENCIAMENTO FINANCEIRO
O objetivo do gerenciamento financeiro é garantir os recursos financeiros ne-

cessários para a entrega dos serviços de TI aos clientes.
COMO É FEITO O GERENCIAMENTO FINANCEIRO?
Esse gerenciamento é feito com base em dados históricos, avaliação da de-

manda atual e projeções das demandas futuras em relação aos serviços de TI.
Envolve os seguintes planejamentos:
a) Planejamento de capital: tradução dos custos de TI para o negócio, ou
seja, os custos com a “caixa-preta” chamada TI deve ser decifrada;
b) Planejamento de demanda: planejamento das necessidades futuras de in-
vestimentos e das mudanças nos custos de TI planejadas;
c) Planejamento regulatório: alinhamento dos custos de TI em relação ao
planejamento do negócio.
Valoração de serviços (quantificar em termos financeiros) é uma das atividades
mais complexas realizadas pelo gerenciamento financeiro. Alguns custos, como
os relacionados a hardware, são mais fáceis de ser valorados, já os custos relacio-
nados a software geralmente são mais complexos.
41
Para que você compreenda o gerenciamento financeiro e a questão da valo-

ração, nada melhor que exemplos, não é mesmo? Então, confira os casos abaixo:
Caso 1
Uma empresa precisa desenvolver um software para gestão de sua folha de pa-
gamento. Para dar suporte a esse software, é preciso fazer a aquisição de um novo
servidor. O custo com esse servidor é relativamente simples de ser valorado, uma
vez que se trata de um produto vendido no mercado com custo fixo. Entretanto,
qual será o custo com o desenvolvimento desse software? O desenvolvimento de
software é uma tarefa complexa, em que diversos profissionais, realizando diver-
sas funções, estão envolvidos. Essa complexidade inerente ao software torna a
valoração mais difícil.
Caso 2
Uma vez que o serviço foi valorado, como ele pode ser cobrado do cliente? A
resposta é: depende. Se a área de suporte tiver fins lucrativos, o serviço de manu-
tenção deve ser valorado, e esse custo, mais a margem de lucro, devem ser cobra-
dos do cliente. E se a área de suporte fizer parte do organograma da empresa e
não tiver fins lucrativos? Nesse caso, não há o que ser cobrado. A valoração do ser-
viço servirá apenas para determinar o gasto da empresa na entrega desse serviço.
RESULTADO DO PROCESSO
O gerenciamento financeiro gera como resultado informações financeiras so-

bre o valor dos serviços, para auxílio na tomada de decisão de outros processos.
Responsabilidades do gerente financeiro

Freitas (2010) cita as seguintes atribuições do gerente financeiro:
a) identificar, negociar e aprovar os valores dos serviços de TI com as áreas do
negócio;
b) prestar informações sobre os custos de serviços de TI;
c) manter a conformidade regulatória com a política de gerenciamento finan-
ceiro da empresa.
Conforme ilustrado na figura a seguir, o gerenciamento financeiro influencia

todos os serviços do ciclo de vida do modelo ITIL, pois todos os outros processos
dependem dos recursos financeiros disponibilizados pelas empresas. De acordo
com a figura, os outros processos que influenciam em todos os outros serviços
são: gerenciamento de demanda, de segurança da informação, de fornecedor, de
mudança, de configuração e ativo de serviço e de conhecimento.
42
Processos ITIL V3 - Ciclo de Vida dos Serviços

Processo de Melhoria Processo de Estratégia Processo de Desenho Processo de Transição Processo de Operação
de Serviço Continuada de Serviço de Serviço de Serviço de Serviço
(PMSC) (PES) (PDS) (PTS) (POS)
Melhoria de Serviço Gerenciamento Financeiro
Relatório de Serviço Gerenciamento de

Portifólio de Serviços
Medição de Serviço Gerenciamento da Demanda
Geração de estratégia
Gerenciamento do Catálogo de Serviços
Gerenciamento do Nível de Serviço
Gerenciamento da Capacidade
Gerenciamento da Disponibilidade
Gerenciamento da Continuidade de Serviços de TI
Gerenciamento de Segurança da Informação
Gerenciamento de Fornecedor
Planejamento e Suporte
à Transição
Gerenciamentos de Mudanças
Gerenciamento da Configuração e de Ativo de Serviço
Gerenciamento de Liberação e Implantação
Validação e Teste de Serviço
Avaliação
Gerenciamento do Conhecimento
Gerenciamento do Evento
Gerenciamento de Incidente
Gerenciamento de Problema
Cumprimento de Requisição
Gerenciamento de Acesso
Gerenciamento de Operação
Figura 19 - ITIL V3 – Ciclo de vida dos serviços

43
44
Com base nas atribuições do gerenciamento financeiro, você pôde entender

como cobrar pelos serviços de suporte de TI. O serviço deve ser valorado e seu
custo repassado para o cliente. Entretanto, a valoração do serviço pode ser algo
complexo considerando a natureza dos serviços de TI. Fazer esse gerenciamento
propicia informações financeiras sobre o valor dos serviços, para auxílio na toma-
da de decisão de outros processos.
2.8 GERENCIAMENTO DE NÍVEL DE SERVIÇO (GNS)
Denis Pacher (2012)

Figura 20 - Gerenciamento de nível de serviço
Você sabia que os serviços entregues pela área de TI devem ser negociados,
acordados e documentados? Toda empresa que presta serviços na área de TI,
como suporte de TI por exemplo, deve definir as “regras do jogo” perante seus
clientes. A essas “regras” dá-se o nome de acordo. Um dos objetivos da área de ge-
renciamento de nível de serviço é a elaboração e o gerenciamento desses acordos.
COMO FUNCIONAM OS ACORDOS
Nos acordos são estabelecidas as combinações entre fornecedores de serviços

de TI e seus respectivos usuários. Neles é registrado claramente aquilo que se
espera do serviço e de que forma se medirá o desempenho do fornecedor. Em
outras palavras, devem-se registrar o alcance do serviço, as variáveis que devem
ser medidas e como serão medidas.
45
Existem três tipos de acordos: o acordo de nível de serviço (ANS ou SLA), o

acordo de nível operacional (ANO ou OLA) e o contrato de apoio (CA ou UC). O
ANS é um acordo feito entre uma empresa e seu cliente, o ANO ocorre entre duas
áreas de uma companhia e o CA é celebrado entre uma empresa e um fornece-
dor. A Figura 6 ilustra a abrangência dos três tipos de acordos:
Negócio Cliente
Serviço
SLA
Fornecedores
Internos OLA
TI
Fornecedores
Externos UC
Requerimentos de
Disponibilidade
Requerimentos de
"Performaces"
Custos
Acordados
Figura 21 - Tipos de acordos
É muito importante que você saiba que o ANS não é um documento estático,
mas sim dinâmico. Durante a prestação do serviço, devem ser estabelecidas revisões
periódicas a fim de incorporar as mudanças produzidas no entorno onde opera.
MÉTRICAS
Sempre que falamos em acordos de nível de serviço, necessariamente deve-

mos falar de métricas. Para que um sistema de métricas seja eficiente, em pri-
meiro lugar deve contemplar as variáveis adequadas, contar com ferramentas
e com processos que permitam realizar as medições de maneira padronizada e
automática. Também deve dispor de processos de melhoria contínua que corri-
46
jam os desvios que possam surgir por falhas próprias do serviço ou de mudanças
no entorno operacional.
Vejamos um exemplo: o serviço de laboratório de manutenção de hardware
tem como objetivo atender a todas as requisições de manutenção de hardware
de seus usuários.
Exemplos de métricas que devem ser realizadas: tempo necessário para o pri-
meiro atendimento (diagnóstico do problema), tempo médio de reparo e quan-
tidade de equipamentos com retrabalho. É com base nessas métricas que são
verificadas as metas definidas para essa área.
Exemplos de metas que podem ser calculadas: tempo médio de diagnóstico
de no máximo 24 horas; tempo médio para reparo de no máximo sete dias úteis;
índice de retrabalho de no máximo 10% (de cada dez equipamentos que entram
em laboratório, apenas um retorna para novo reparo).
OBJETIVOS DO GERENCIAMENTO DE NÍVEL DE SERVIÇO
O principal objetivo do GNS é negociar, acordar e documentar as metas de

utilidade e garantia dos serviços de TI com seus respectivos clientes, e monitorar
a entrega desses serviços de acordo com as metas acordadas.
Além da negociação com os clientes, é preciso fazer isso também com as me-
tas das áreas internas da empresa, outros provedores de serviços ou fornecedo-
res. A esses acordos dá-se o nome de acordos de nível operacional (ANO) ou con-
tratos de apoio (CA).
O GNS deve prover ainda um ponto de contato e comunicação com os clientes
e gerentes do negócio, a fim de prestar contas sobre os relatórios de atendimento
dos níveis de serviços em relação aos serviços utilizados, e também para serviços
novos ou alterados.
Finalmente, deve gerenciar a expectativa e a percepção de valor dos clientes
em relação aos serviços de TI entregues, e garantir que a qualidade dos serviços
seja mantida conforme os níveis de utilidade e garantia acordados.
Observa-se que o gerente de nível de serviço tem muitas responsabilidades.
Logo, é importante que a pessoa que desempenhe esse papel esteja bem prepa-
rada. Vamos entender melhor com base em um caso prático?
47
CASOS E RELATOS
Um caso de sucesso
A área de suporte de Tecnologia da Informação de uma empresa ne-
gociou um acordo de nível de serviço (ANS) com um de seus clientes
mais importantes. Nesse acordo, foram registradas metas em relação ao
tempo de atendimento das requisições. Ficou acordado que todas as re-
quisições de usuários deveriam ser atendidas em no máximo 12 horas
após o registro do incidente. Ficou acordado ainda que a área de suporte
deveria fornecer um orçamento com prazo e custo para reparo em seu
computador em no máximo 48 horas.
Para verificar esse desempenho, foram definidos alguns indicadores a se-
rem colhidos pelo gerente de nível de serviço.
Após o primeiro mês de atendimento, verificou-se que apenas 30% dos
atendimentos realizados atingiram a meta proposta. Com base nessa in-
formação, o gerente de nível de serviço buscou a causa do não cumpri-
mento dos prazos. Analisando detalhadamente, ele pôde verificar que o
cumprimento dos ANS acordados dependia de terceiros, como fornece-
dores de peças de reposição, por exemplo.
Para resolver o problema, foram estabelecidos acordos de nível opera-
cional (ANOs) e contratos de apoio (CAs) para que o ANS fosse atendido
conforme especificado.
Assim, conclui-se que o ANS, o ANO e o CA devem estar alinhados para
que os serviços entregues pela área de suporte atinjam seus objetivos.
O sucesso do GNS está diretamente relacionado à qualidade do portfólio
e do catálogo de serviços, porque as informações contidas no catálogo
de serviços servem como insumo para que as metas dos serviços de TI
sejam desenhadas.
48
CONCEITOS RELACIONADOS AO GERENCIAMENTO DE NÍVEL DE

SERVIÇO
Os conceitos a seguir são importantes para o gerente de nível de serviço, pois

tratam da nomenclatura comum utilizada nesse processo:
a) Requerimentos de nível de serviço: identificação da expectativa e percep-
ção de valor dos clientes;
b) Requisitos de nível de serviço (RNS): documentação – registro – negocia-
da e aprovada dos requerimentos;
c) Acordos baseados no serviço: abrange um nível de serviço único para to-
dos os clientes que utilizam esse serviço. Utilizado por centros de serviço
compartilhado;
d) Acordos baseados no cliente: abrange todos os serviços entregues a um
único cliente com um único nível de serviço para todos os serviços dele. Uti-
lizado por provedores internos ou fornecedores que entregam serviços es-
pecializados a um cliente;
e) Acordos multinível: divide-se em outros três:
a) Nível corporativo: são acordos firmados com uma única empresa, cobrin-
do todos os serviços entregues a cada cliente interno da empresa;
b) Nível de cliente: cobre todos os aspectos relevantes a um grupo particular
de clientes ou unidades de negócio que compartilham o mesmo serviço;
c) Nível de serviço: cobre todos os aspectos relevantes de um serviço especí-
fico entregue a um determinado grupo de clientes com o mesmo nível de
serviço exigido. São serviços utilizados por vários clientes sob as mesmas
características e níveis de serviço desejados, podendo ser identificados por
meio das linhas de serviço desenhadas no ciclo de estratégia de serviço.
ATRIBUIÇÕES DO GERENTE DE NÍVEL DE SERVIÇO
De acordo com a visão de Freitas (2010), as principais atribuições do gerente

de nível de serviço são:
a) determinar, negociar e documentar os requisitos de qualidade para serviços
novos ou alterados por meio dos requisitos de nível de serviço (RNS);
b) medir e monitorar o desempenho dos serviços principais e serviços de apoio
e compará-los com as metas de nível de serviço estabelecidas nos acordos
de nível de serviço (provedor interno) ou contratos de nível de serviço (for-
necedor);
49
c) medir e gerenciar a satisfação dos clientes em relação aos serviços de TI en-

tregues;
d) produzir relatórios de nível de serviço;
e) conduzir reuniões de avaliação do nível de serviço e instigar melhorias no
serviço por meio do plano de melhoria dos serviços;
f) analisar e rever os acordos de nível de serviço e operacional e contratos de
apoio;
g) desenvolver e documentar os contatos e relacionamentos com os clientes
de negócio;
h) registrar e gerenciar as reclamações e elogios dos clientes;
i) desenvolver, manter e operar procedimentos de identificação e resolução
de conflitos sobre acordos de nível de serviço;
j) fornecer informações sobre a realização e entrega dos serviços;
k) manter disponíveis os modelos e padrões de acordos de nível de serviço.
Você viu que são muitas as demandas que envolvem o gerenciamento de ní-
vel de serviço, não é mesmo? Ele é importante para garantir que as metas de uti-
lidade e garantia dos serviços de TI sejam entregues aos seus clientes. Esse obje-
tivo pode ser alcançado por meio da elaboração dos acordos de nível de serviço,
acordos de nível operacional e contratos de apoio.
Ao se falar em nível de serviços, você viu que é importante também conhecer
sobre métricas, e para que um sistema de métricas seja eficiente, é preciso con-
templar as variáveis adequadas, contar com ferramentas e com processos que
permitam realizar as medições de forma padronizada e automática.
Como bem falamos durante a explicação do conteúdo, o gerente de nível de
serviços tem uma série de atribuições e responsabilidades e deve estar bem pre-
parado para que nada saia do seu controle.
2.9 GERENCIAMENTO DE CATÁLOGO DE SERVIÇOS
A área de TI entrega valor aos seus clientes na forma de serviços. Esses ser-
viços devem ser negociados com os clientes. Uma vez negociados e definidos,
devem ser analisados, aprovados e contratados. Logo, nem todos os serviços de
que os clientes necessitam são entregues pela área de TI, apenas os aprovados.
Mas quem cuida desses serviços que são aprovados? Como os clientes sabem
quais serviços estão à sua disposição e como utilizá-los? Pois bem, isso é tarefa do
gerenciamento de catálogo de serviços.
50
QUAL O OBJETIVO DO GERENCIAMENTO DE CATÁLOGO?
O gerenciamento de catálogo de serviços tem como objetivo criar e manter o

chamado catálogo de serviços, garantindo que ele seja a única fonte de informa-
ções sobre os serviços para os clientes e outros processos que necessitam desses
serviços.
O catálogo de serviços é um documento que contém os serviços que serão
efetivamente entregues aos clientes. Por exemplo, um serviço de manutenção
de rede, que é entregue pela área de suporte de TI, deve estar descrito nesse
catálogo.
Além da descrição detalhada dos serviços, o catálogo deve conter o status do
serviço, suas interfaces e dependências em relação aos outros serviços entregues
pela área de TI.
O catálogo de serviços faz parte do portfólio de serviços. Todavia, trata-se de
um documento com mais detalhes sobre os serviços. É muito importante que você
saiba ainda que o gerenciamento de portfólio responsabiliza-se por tomar as deci-
sões sobre quais serviços devem ir ou não para o catálogo, porém, uma vez que o
serviço foi para o catálogo, este deve ser mantido pelo gerenciamento de catálogo.
TIPOS DE CATÁLOGOS DE SERVIÇOS
Existem dois tipos de catálogos de serviços: catálogo de serviços de negó-

cios e catálogo de serviços técnicos.
O catálogo de serviços de negócios contém informações úteis aos clientes,
que por sua vez só têm acesso a esse nível de informações sobre os serviços.
Já o catálogo de serviços técnicos não pode ser visualizado pelo cliente e con-
tém informações com detalhes técnicos sobre os serviços.
ATIVIDADES DO GERENCIAMENTO DE CATÁLOGO DE SERVIÇOS
Freitas (2010) descreve as seguintes atividades do gerenciamento de catálogo

de serviços:
a) produção e manutenção do catálogo de serviços;
b) gerenciamento das interfaces e dependências entre o catálogo de serviços
e o portfólio de serviços;
c) gerenciamento das interfaces e dependências entre o catálogo de serviços
e o gerenciamento de configuração;
51
d) gerenciamento das interfaces com o gerenciamento de relacionamento

com o cliente e o gerenciamento de nível de serviço, para garantir que as
informações do catálogo de serviço estejam alinhadas com o negócio.
RESPONSABILIDADES DO GERENTE DE CATÁLOGO DE SERVIÇOS
Os principais papéis do gerente de catálogo de serviços são produzir e manter

o catálogo de serviços, além de garantir a execução das atividades do gerencia-
mento desse catálogo.
Você agora sabe que o gerenciamento de catálogo de serviços cuida dos servi-
ços que são aprovados e, ainda, fornece aos clientes a descrição dos serviços que
estão à sua disposição e como utilizá-los.
Você sabe também que o catálogo de serviços faz parte do portfólio de servi-
ços, e que ele possui dois tipos: catálogo de serviços de negócios e catálogo de
serviços técnicos.
Por fim, viu as responsabilidades do gerenciamento do catálogo de serviços e
do gerente dessa área.
2.10 GERENCIAMENTO DA DISPONIBILIDADE
ATENDIMENTO
24h
Denis Pacher (2012)
Figura 22 - Gerenciamento da disponibilidade
Vamos conhecer o que é gerenciamento da disponibilidade? O seu objetivo

é garantir que os níveis de disponibilidade entregues para os serviços de Tecno-
logia da Informação (TI) estejam de acordo ou superem as expectativas atuais e
futuras do negócio, considerando o planejamento financeiro. Mas o que é dispo-
nibilidade no contexto da área de TI? Veremos a seguir!
52
DISPONIBILIDADE
Disponibilidade é a habilidade de um serviço ou componente de TI em de-

sempenhar a sua função acordada quando necessário. Um serviço está disponível
quando os sistemas de TI que o suportam estão em operação. Se a capacidade
requerida de um serviço não é entregue conforme o esperado, o baixo desempe-
nho do serviço pode inviabilizar sua execução por parte dos clientes. Estes, por
sua vez, se não conseguem executar seus serviços conforme previamente plane-
jado e acordado, consideram então que o serviço está indisponível.
DISPONIBILIDADE DOS SERVIÇOS
O nível de disponibilidade dos serviços de TI é um índice que se pode calcu-

lar. Seu valor em percentual pode ser calculado em relação ao tempo total de
disponibilidade de um período e o tempo total de indisponibilidade no mesmo
período, considerando a seguinte fórmula:
ND = Nível de disponibilidade
TTD = Tempo total de disponibilidade
TTI = Tempo total de indisponibilidade
ND = [(TTD – TTI)/TTD]x100
É importante conhecer alguns conceitos relacionados ao nível de disponibili-
dade dos serviços:
a) Tempo de serviço acordado: é a meta de disponibilidade determinada no
acordo de nível de serviço;
b) Confiabilidade: prazo em que um sistema consegue, ou espera-se que con-
siga, executar funções de acordo com o esperado. A confiabilidade de um
sistema é medida pelo cálculo do MTBF ou TMEF (tempo médio entre falhas).
Esse índice calcula o tempo entre uma falha e outra no sistema;
c) Sustentabilidade: tempo gasto para que um serviço retorne ao seu estado
original. Em outras palavras, esse índice mede quanto tempo um serviço ou
componente de TI leva para ser reparado em caso de indisponibilidade. Ao
tempo médio para restauração de um serviço dá-se o nome de TMRS.
Um outro indicador de confiabilidade é o TMPR (tempo médio para reparo). Em
muitos casos, o serviço pode ter sido reparado mas ainda estar indisponível, ou seja,
ainda não foi restaurado sob o ponto de vista do usuário. Veja o exemplo a seguir.
As filiais de uma empresa não conseguem acessar o sistema de vendas. Foi
identificada uma falha técnica no banco de dados. A tabela de indexação do
53
nome do produto está corrompida. Foram gastos 20 minutos para reindexação

da tabela. Esse foi o tempo necessário para reparo do incidente. Entretanto, após
o reparo o software SGBD, que gerencia o banco, teve de ser reinicializado. Isso
levou cerca de cinco minutos. Logo, o tempo total para que o sistema fosse res-
taurado foi de 25 minutos.
É importante que você saiba que o gerenciamento da disponibilidade não é
responsável pelo reparo em si dos serviços. Sua função é garantir que a duração
e os impactos das falhas nos serviços de TI sejam minimizados, trabalhando em
conjunto com os processos de gerenciamento de incidentes e problemas.
A real função do gerenciamento de disponibilidade é gerenciar o ciclo de vida
do incidente – uma interrupção não planejada de um serviço de TI ou uma redu-
ção na qualidade da entrega de um serviço –, considerando as seguintes fases:
a) detecção: tempo que a TI levou para identificar o incidente;
b) diagnóstico: tempo que a TI levou para determinar a causa do incidente;
c) reparo: tempo que a TI levou para reparar o serviço;
d) recuperação: tempo que a TI levou para recuperar o serviço;
e) restauração: tempo que a TI levou para restaurar o serviço.
NÍVEIS DE CONFIABILIDADE, DISPONIBILIDADE E SUSTENTABILIDADE
Acordos de nível de serviço definem em geral metas de disponibilidade. Já as

metas de confiabilidade e sustentabilidade normalmente são definidas nos acor-
dos de nível operacional. Logo, é muito importante identificar quais processos
são mais ou menos críticos para o negócio. Em outras palavras, cada tipo de pro-
cesso deve receber uma classificação em relação à sua criticidade, considerando
os seguintes quesitos:
a) Alta disponibilidade: diz respeito à característica do serviço de TI em mini-
mizar ou mascarar os efeitos de falhas em componentes de TI para os usuá-
rios do serviço;
b) Tolerância a falhas: é a habilidade de um serviço ou componente de TI em
continuar a operar mesmo depois de uma falha;
c) Operação contínua: é a capacidade de projetar serviços de TI que conti-
nuem a operar mesmo depois de falhas;
d) Disponibilidade contínua: é projetar o serviço para que ele atinja uma taxa
de 100% de disponibilidade.
54
Na prática, a função do gerenciamento da disponibilidade é monitorar to-

dos os aspectos de disponibilidade, confiabilidade e sustentabilidade por meio
de procedimentos normais ou automatizados. As informações colhidas devem
ser armazenadas em um repositório chamado SIGD (Sistema de Informação de
Gerenciamento da Disponibilidade). O resultado dessa atividade é um plano de
disponibilidade. Esse gerenciamento também tem como função analisar as falhas
e riscos de disponibilidade de serviços de TI.
TÉCNICAS PARA ANÁLISE DE FALHAS E RISCOS DE DISPONIBILIDADE
Existem quatro técnicas muito utilizadas para análise de falhas e riscos de dis-
ponibilidade. São elas:
a) Análise de falha do serviço: busca a identificação das causas da indisponi-
bilidade e elaboração de propostas de melhorias para disponibilidade dos
serviços;
b) Análise de impacto em falhas de componente: tem como objetivo identi-
ficar falhas de componentes de TI em um serviço de negócio;
c) Análise de ponto único de falhas (PUF): visa analisar os componentes de
TI que não têm capacidade de tolerância a falhas ou não há contingência. A
identificação desses pontos é importante para localizar um potencial ponto
de impacto relacionado a esse componente e justificar financeiramente pla-
nos de melhoria para sua disponibilidade;
d) Análise da árvore de falhas (AAF): é uma técnica de representação em
árvore para identificar a sequência de eventos causados por uma falha em
um serviço ou componente de TI.
Vimos aqui que o gerenciamento de disponibilidade é uma atividade impor-
tante no que diz respeito à garantia de que os serviços de TI sejam entregues de
acordo com a expectativa do cliente. Entretanto, é importante que você observe
que não é o gerente de disponibilidade quem resolve os problemas. Sua função é
monitorar a disponibilidade e a confiabilidade dos serviços de TI.
55
2.11 GERENCIAMENTO DE CONTINUIDADE DE SERVIÇO DE TI

Figura 23 - Continuidade do Negocio
Qual deve ser a primeira atitude de um gerente quando um serviço de TI, con-
siderado crítico para o funcionamento da empresa, é interrompido por um inci-
dente ou outro problema qualquer? O que devemos fazer, por exemplo, quando
um software de emissão de notas fiscais deixa de funcionar devido a uma falha no
servidor de aplicações? A resposta é: continuar a execução do serviço por meio de
uma solução de contorno. Em outras palavras, temos de garantir a continuidade
dos serviços, fazendo com que o impacto da sua interrupção seja minimizado.
Você deve estar se perguntando: mas o que é uma solução de contorno?
Como isso pode ser feito na prática? Por meio do gerenciamento de continuidade
dos serviços de TI, podemos contornar esse problema. Continue atento e observe
como!
OBJETIVO DO GERENCIAMENTO DE CONTINUIDADE
O objetivo do gerenciamento de continuidade de serviço de TI é dar suporte

ao chamado plano de continuidade de negócio (PCN), garantindo que os serviços
e componentes críticos de TI tenham seu funcionamento restaurado, em casos de
interrupções causadas por incidentes ou problemas. Dessa forma, continuidade
está relacionada justamente a essa capacidade que a empresa tem em manter
seus serviços em funcionamento.
Perceba então que continuidade tem a ver com incidentes e problemas, pois
são eles os causadores da interrupção dos serviços. Incidentes e problemas, por
sua vez, estão relacionados a risco (risco de que os incidentes ou problemas acon-
teçam). Por isso, gerenciamento de continuidade também tem relação com a
56
capacidade que a empresa tem de prever eventos de risco que possam afetar
seriamente o seu negócio, e com a habilidade da empresa em estar preparada
para reagir caso esses eventos ocorram.
Gerenciamento de continuidade foca os eventos de risco que são significa-
tivos para o negócio. Eventos menos importantes ou com impactos reduzidos
são tratados pelo gerenciamento de disponibilidade e pelo gerenciamento de
incidentes.
Como garantir a continuidade e tratar os riscos? Freitas (2010) relaciona as fun-
ções do gerenciamento de continuidade.
FUNÇÕES DO GERENCIAMENTO DE CONTINUIDADE
a) desenhar e manter planos de continuidade dos serviços de TI, além de pla-

nos de recuperação que suportem o plano de continuidade;
b) realizar a análise de impacto no negócio;
c) conduzir as análises de riscos em conjunto com o negócio;
d) garantir que os mecanismos de continuidade apropriados estejam sendo
gerenciados, para atender ou superar as metas de continuidade do negócio
acordadas;
e) garantir que métricas proativas de melhoria da disponibilidade dos serviços
estejam sendo implementadas;
f) negociar e contratar os fornecedores necessários para suportar o plano de
continuidade dos serviços de TI.
ATIVIDADES DO GERENCIAMENTO DE CONTINUIDADE
Freitas (2010) afirma que as atividades desse processo devem ser realizadas
considerando o seguinte ciclo de vida: iniciação, requerimentos e estratégia, im-
plementação e operação.
Na fase de iniciação ocorre a definição dos propósitos, objetivos e garantias
de comunicação do plano de continuidade do serviço de TI. Definem-se o escopo
do plano e as responsabilidades de todos os envolvidos; são alocados recursos
internos ou externos para suporte ao plano; é definida a estrutura organizacional
e de controle do projeto; e são acordados o projeto e o seu plano de qualidade.
A fase de requerimentos e estratégia quantifica o impacto dos riscos no ne-
gócio por meio da análise de riscos de perdas financeiras, aumento de custos,
57
perda de vantagem competitiva ou desconformidade com leis e regulamenta-

ções. Nesta fase também são analisados o nível de ameaça, a abrangência de um
risco e o nível de vulnerabilidade da empresa a essa ameaça. Finalmente, com
base na análise de impacto de negócio e na análise de risco, é produzido o plano
estratégico de continuidade de serviço de TI.
Na fase de implementação são desenvolvidos e testados o plano de continui-
dade de serviço de TI e os procedimentos de recuperação dos serviços. Também
são identificadas as áreas afetadas, em caso de falhas.
Por último, na fase de operação, todos os envolvidos no plano de continui-
dade de serviços de TI devem estar conscientes de sua importância e devem ser
treinados para implementar suas ações em caso de incidentes.
É importante que o plano de continuidade de serviços seja constantemente
revisado e realinhado aos objetivos de negócio.
No plano estratégico de continuidade devem estar contempladas as chama-
das soluções de contorno. Essas soluções são utilizadas para minimizar o impacto
da ocorrência de incidentes e problemas no negócio, e garantem de fato a conti-
nuidade de execução do serviço. Conheça a seguir sua classificação:
a) Soluções de contorno manual: requer a intervenção manual. Por exemplo:
emissão de uma nota fiscal manual até que o sistema de emissão de notas
fiscais seja restaurado;
b) Backup ou contingência: garante que os dados mais importantes para o
negócio estejam armazenados em outra localização física;
c) Acordo recíproco: acordo entre duas empresas para compartilhar recursos
similares em caso de indisponibilidade dos serviços;
d) Recuperação gradual: inclui a provisão de recursos e componentes de TI
para reposição e uso em casos de indisponibilidade dos recursos em opera-
ção. Exemplo: reinstalação do sistema em outro servidor;
e) Recuperação intermediária: inclui a provisão de recursos e componentes
de TI para reposição. Exemplo: utilização de um servidor de backup com os
dados dos sistemas;
f) Recuperação rápida: trata-se de uma evolução da recuperação intermediá-
ria – inclui a provisão de recursos e componentes de TI para reposição auto-
mática. Exemplo: replicação de um banco de dados;
g) Recuperação imediata: é a duplicação de recursos e componentes de TI
(espelhamento). Exemplo: restauração do banco de dados de produtos para
sistemas de vendas pela internet.
58
Como você constatou, o gerenciamento de continuidade é importante para

garantir que os serviços e componentes críticos de TI continuem funcionando,
mesmo em casos de interrupções causadas por incidentes ou problemas. Vimos
que isso pode ser alcançado por meio da elaboração do plano de continuidade e
mediante tratamento adequado dos riscos envolvidos na execução dos serviços.
2.12 GERENCIAMENTO DE FORNECEDORES
Você sabe o que acontece quando a área de suporte de TI precisa comprar

um componente de hardware para substituir outro que não funciona mais? Deve
recorrer a um fornecedor de peças de reposição.
A partir dessa afirmação, nota-se que as áreas que entregam os serviços de TI
não trabalham “sozinhas”. Em diversas situações, elas necessitam de fornecedores
– são os terceiros que auxiliam na entrega dos serviços. Terceirização é um pro-
cesso muito utilizado em TI e deve ser gerenciado de forma adequada. É para aten-
der a essa necessidade que existe a área de gerenciamento de fornecedores.
OBJETIVO DO GERENCIAMENTO DE FORNECEDORES
O objetivo do gerenciamento de fornecedores é garantir que as expectativas

de negócio do cliente em relação à qualidade na entrega dos serviços de TI se-
jam atendidas pelos fornecedores. Em outras palavras, devemos garantir que as
atividades entregues pelos fornecedores atendam às expectativas do negócio e
agreguem valor adequado aos serviços.
Veja o exemplo: a área de suporte de TI firmou um acordo de nível de serviço
de manutenção dos monitores dos computadores de seus clientes. Nesse acordo
ficou estabelecida uma meta de cinco dias de prazo máximo para o diagnóstico
e a correção dos problemas. Entretanto, em geral a manutenção nos monitores
envolve troca de peças que, por sua vez, depende de um fornecedor de peças.
Para cumprir esse acordo e garantir a entrega do serviço, a área de suporte
deverá estabelecer essa mesma meta com o fornecedor de peças de reposição.
Garantir esse alinhamento é uma das principais atribuições do gerente de forne-
cedor.
Todas as informações sobre contratos de fornecedores, informações cadastrais
e informações sobre atividades e políticas dos fornecedores devem ser cadastra-
das em uma base de informações denominada base de dados de fornecedores e
contratos (BDFC).
59
ATIVIDADES DO GERENCIAMENTO DE FORNECEDORES
Segundo Freitas (2010), as atividades do gerenciamento de fornecedores de-

vem ser planejadas considerando as seguintes etapas:
a) identificação das necessidades e requisitos do negócio e preparação do pla-
no de negócios;
b) avaliação, aquisição e estabelecimento de novos contratos de fornecedores;
c) categorização dos fornecedores e seus contratos;
d) gerenciamento do desempenho do fornecedor;
e) gerenciamento do término do contrato.
RESPONSABILIDADES DO GERENTE DE FORNECEDOR
As responsabilidades de um gerente de fornecedor são:

a) auxiliar no desenvolvimento de contratos de nível de serviço e de contratos
de apoio com fornecedores;
b) manter a base de dados de fornecedores e contratos;
c) avaliar os riscos dos fornecedores e contratos;
d) avaliar e adquirir novos fornecedores e contratos;
e) avaliar o desempenho dos fornecedores;
f) gerenciar o relacionamento com os fornecedores.
Neste material você aprendeu que, para entregar serviços de forma adequada
aos seus clientes, a área de TI depende de fornecedores (terceiros). O relaciona-
mento com esses fornecedores deve ser gerenciado de forma satisfatória e, para
isso, existe a área de gerenciamento de fornecedores.
2.13 GERENCIAMENTO DA CAPACIDADE
Você já teve problemas com velocidade de conexão com a internet? Já teve

problemas para comprar com cartão de crédito na época do Natal? Já demorou
muito para realizar saque em um caixa eletrônico? O que esses três problemas
têm em comum? Todos são serviços entregues pela área de TI. Logo, se você já
enfrentou algum dos problemas listados, saiba que eles estão relacionados com
a capacidade da empresa em entregar seus serviços de TI. Para lidar com esses
problemas existe uma área chamada de gerenciamento da capacidade.
60
OBJETIVO DO GERENCIAMENTO DA CAPACIDADE
O objetivo do gerenciamento da capacidade é garantir que os serviços de TI

sejam entregues de acordo com os níveis de capacidade adequados. Em outras
palavras, garantir que o desenho do serviço contemple o desenho da capacidade
adequada para entregar os serviços.
É importante que a garantia da capacidade adequada ocorra dentro de um
custo que possa ser justificado, e que essa capacidade esteja alinhada com as
necessidades atuais e futuras do negócio.
Segundo o site WebHolic (http://webholic.com.br/2010/11/10/o-enorme-
-crescimento-do-mercado-de-compras-coletivas-e-a-velocidade-de-expansao-
-dos-servicos/), os servidores que armazenavam os sites de compras coletivas em
junho de 2011 tiveram um aumento de demanda de 231% em dois meses. Foi
necessário planejar a capacidade das empresas de compras coletivas em atender
às demandas de seus clientes atuais e futuros em curto prazo. Com certeza não
haveria tempo hábil para troca de servidores com tamanha demanda. O gerente
de capacidade teve que alinhar a capacidade de TI com a expectativa das empre-
sas de crescimento rápido.
A essa capacidade extra para atender a uma demanda futura dá-se o nome de
capacidade ociosa. Logo, o planejamento da capacidade ociosa torna-se funda-
mental em alguns casos para a garantia da entrega dos serviços. Se mal planeja-
da, pode significar grandes prejuízos para a empresa.
Tome como exemplo uma empresa de varejo que vende muito pela internet
no Natal. Pode ser necessário manter a capacidade ociosa dos servidores da em-
presa apenas para atender à demanda nessa época do ano. O custo de manuten-
ção dessa capacidade se justifica pelos lucros obtidos ao final do ano.
A figura a seguir ilustra a relação de equilíbrio que deve haver entre capacida-
de e demanda.
Demanda Capacidade
Figura 24 - Equilíbrio capacidade e demanda

61
ATIVIDADES DO GERENCIAMENTO DA CAPACIDADE
A área de gerenciamento da capacidade pode trabalhar de forma reativa ou

proativa. O ideal é que essa seja uma área proativa. Para isso, Freitas (2010) sugere
as seguintes atividades:
a) identificar e antecipar falhas de desempenho e solicitar a tomada de ações
antes que elas ocorram;
b) produzir análises de tendência de utilização atual dos componentes de TI e
estimativa de utilização futura;
c) modelar e analisar tendências de mudanças nos serviços de TI e identificar
os componentes de TI que deverão ser modificados para atender à mudança
no serviço;
d) garantir que os custos de atualizações e melhorias de TI estejam planejados
em conjunto com o gerenciamento financeiro;
e) buscar ativamente a melhoria do desempenho do serviço;
f) aperfeiçoar o desempenho dos serviços e componentes.
RESPONSABILIDADES DO GERENTE DA CAPACIDADE
São de responsabilidade do gerente da capacidade:

a) garantir capacidade adequada de TI para atender aos serviços;
b) balancear a capacidade de TI com a demanda dos serviços de TI a um custo
justificável;
c) aperfeiçoar e fazer o melhor uso das capacidades de TI disponíveis;
d) monitorar e prover relatórios de capacidade.
Para entregar serviços de forma adequada a seus clientes, a área de TI deve ter
capacidade atual e futura adequada. Logo, para não ter problemas na capacidade
de entrega dos serviços, a empresa deve implantar a área de gerenciamento da
capacidade.
62
2.14 GERENCIAMENTO DA SEGURANÇA DA INFORMAÇÃO
Dreamstime (2012)
Figura 25 - Gerenciamento da segurança da informação
Você sabia que, na sociedade da informação em que vivemos, ao mesmo tempo

que as informações são consideradas o principal patrimônio de uma organização,
elas também estão sob constante risco, como nunca estiveram antes? Esse dado
é do Manual de Boas Práticas em Segurança da Informação do Tribunal de Contas
de União (2008). Com isso, a segurança da informação tornou-se um ponto crucial
para a sobrevivência das instituições. Nesse contexto torna-se necessária a adoção
de procedimentos que visam ao gerenciamento de segurança da informação.
OBJETIVO DO GERENCIAMENTO DE SEGURANÇA DA INFORMAÇÃO
O objetivo do gerenciamento de segurança da informação é alinhar segurança

de TI com os requisitos de segurança do negócio para garantir que a segurança
da informação esteja sendo gerenciada de forma eficaz em relação a todos os
serviços e componentes de TI. Logo, gerenciar segurança da informação significa
garantir que a informação esteja segura.
Mas o que significa informação segura? A informação é considerada segura
quando está disponível para ser acessada quando requerida, sendo acessada so-
mente pelas pessoas certas, com as autorizações adequadas, quando está íntegra
(correta) e representa a realidade.
A questão é: como garantir isso? Através da utilização de normas de segurança
da informação. Essa é considerada uma boa prática para garantia da segurança.
A principal norma de segurança da informação adotada pelo mercado é a nor-
ma NBR ISO/IEC 27001 (2006).
63
NBR ISO/IEC 27001
Segundo a NBR ISO/IEC 27001, os seguintes controles devem ser observados

para garantia de um nível adequado de segurança da informação:
a) controles organizacionais;
b) controles de aplicativos;
c) controles de desenvolvimento de sistemas;
d) controles de banco de dados;
e) controles de redes;
f) controles de microcomputadores.
CONTROLES ORGANIZACIONAIS
Nos controles organizacionais, a organização do departamento de TI com suas

respectivas unidades organizacionais devem ser bem definidas. Deve ser elabo-
rada uma política de segregação de funções e controles de acesso. As atividades
dos funcionários devem ser controladas e devem ser implementadas políticas cla-
ras de seleção, treinamento e avaliação de desempenho.
Também deve ser elaborado, implantado e divulgado um Programa Geral de
Segurança da Informação contendo: princípios da gestão da segurança, avaliação
de riscos, estrutura de segurança, estrutura de gerência de segurança com atri-
buição clara de responsabilidades, políticas de segurança eficientes e eficazes,
política de controles de acesso contendo a classificação dos recursos de informa-
ção de acordo com sua importância e vulnerabilidade, lista atualizada de usuários
autorizados e seu nível de acesso, controles lógicos (sobre arquivos de dados e
softwares, base de dados e acesso remoto) e físicos para prevenção ou detecção
de acesso não autorizado, supervisão do acesso, investigação de indícios de vio-
lação de segurança e adoção das medidas corretivas.
CONTROLES DE APLICATIVOS
Os controles de aplicativos envolvem o controle dos dados de entrada e saída

dos sistemas, bem como seu processamento. No controle dos dados de entra-
da devem ser verificados os seguintes itens: documentos ou telas de entrada de
dados, rotinas de preparação dos dados de entrada, autorização para entrada de
dados, validação de dados de entrada, rotinas de tratamento de erros e mecanis-
mos de suporte para entrada de dados.
64
O controle do processamento requer a verificação da integridade do proces-

samento, sua validação e processo de tratamento de erros.
Finalmente, verificar dados de saída significa conferir se esses dados são pe-
riodicamente revisados, se são distribuídos adequadamente e armazenados de
forma segura.
CONTROLES DE DESENVOLVIMENTO DE SISTEMAS
É necessário que existam controles do processo de desenvolvimento de sof-

tware, tais como: quem tem acesso aos bancos de dados, ao ambiente de desen-
volvimento e produção, como o código desenvolvido é controlado ou como é
feito o controle de invasão via código malicioso.
CONTROLES DE BANCO DE DADOS
Banco de dados é um sistema computadorizado de manutenção de dados.

Em outras palavras, é um conjunto de dados que, associados a um conjunto de
programas para acessá-los, forma um Sistema Gerenciador de Banco de Dados
(SGBD).
Sua principal finalidade é armazenar dados e permitir que usuários busquem
e atualizem esses dados. Um SGBD é um software que incorpora as funções de
definição, recuperação e alteração de dados em um banco de dados.
Uma das principais funções de um SGBD é garantir a segurança e integridade
dos dados nele armazenados. Para isso, deve monitorar requisições de usuários
e rejeitar todas as tentativas de violar as restrições de segurança e integridade
definidas pela organização.
CONTROLES DE REDES
Envolve o gerenciamento da rede através de procedimentos e políticas para

auxiliar a gerência do ambiente de rede, utilizando padrões definidos para con-
trole do hardware e do software envolvidos.
Além disso, para garantia da segurança dos dados e da rede, devem ser im-
plementados mecanismos de controle dos recursos físicos que a compõem, bem
como o limite e o controle de acesso a programas e dados ali disponíveis.
É importante que a organização ofereça condições para uma operação efi-
ciente da rede, incluindo normas e procedimentos de treinamento de pessoal,
65
execução de cópias de segurança, avaliação da eficiência do serviço, rotinas de

recuperação da rede após interrupções inesperadas, monitoramento e controle
do software de comunicação e do sistema operacional instalado.
CONTROLES DE MICROCOMPUTADORES
É o controle de todo o parque computacional da organização, considerando

toda a infraestrutura de hardware disponível e dos softwares em utilização. Nesse
processo, controles sobre a operação desses softwares devem ser realizados.
Você pôde perceber que a segurança da informação está relacionada a todos
os processos da área de TI. Para implementar as políticas adequadas de gerencia-
mento de segurança das informações, é recomendada e utilização de normas de
segurança. A principal norma disponível no mercado é a ISO/IEC 27001.
2.15 GERENCIAMENTO DE ATIVO E CONFIGURAÇÃO DE SERVIÇO
Você conhece o ambiente de TI da empresa em que trabalha? Para responder

a essa pergunta, os responsáveis pela área de TI das empresas devem ter controle
sobre a configuração de todos os ativos necessários para entrega dos serviços de
TI. Ativos são todos os itens que compõem a infraestrutura utilizada para entrega
desses serviços, tais como hardware, software e documentação. Logo, o gerente
de ativos e configuração deve ser aquela pessoa capaz de responder a perguntas
do tipo: Qual é a configuração de hardware do principal servidor da sua empre-
sa? Quais são os softwares instalados nas estações de trabalho dos funcionários?
Quais sistemas operacionais devem ser atualizados? Quantas licenças de software
estão em uso atualmente? Para realização dessa tarefa, existe a área de gerencia-
mento de ativo e configuração de serviço.
OBJETIVO DO GERENCIAMENTO DE ATIVO E CONFIGURAÇÃO DE SERVIÇO
O objetivo do gerenciamento de ativo e configuração de serviço é definir e

controlar os serviços e componentes de TI, mantendo informações de configura-
ções precisas e confiáveis, tanto do estado atual dos componentes como de seu
histórico de atualizações.
Essa atividade é importante porque permite à empresa ter controle de todos
os componentes de TI da organização. Logo, é uma atividade que, entre outros
benefícios, auxilia na conservação, manutenção e atualização desses componen-
tes. A esses componentes dá-se o nome de item de configuração (IC).
66
ITEM DE CONFIGURAÇÃO
Item de configuração (IC) são os ativos de TI da empresa. Trata-se de qualquer

componente físico ou lógico que possui identificação única e serve para entregar
um serviço de TI.
Geralmente, os ICs são compostos pelos seguintes atributos (características):
nome, tipo (hardware, software, documentação etc.), descrição, versão, fabrican-
te, status (em operação, em manutenção, descontinuado etc.), localização física,
nome do responsável pela sua guarda, seus dados históricos sobre reparos ou
atualizações e seu nível de serviço acordado. Todos esses atributos são armazena-
dos em um banco de dados conhecido como banco de dados de gerenciamento
de configuração (BDGC).
Há diversos conceitos relacionados aos ICs e seu gerenciamento. Entre eles
estão a Biblioteca Definitiva de Mídia (BDM), que são as localidades onde são ar-
mazenadas as versão finais dos softwares utilizados pela empresa; a Biblioteca
Segura, que é uma área segura onde fica armazenada a BDM; o Armazém Seguro,
que é a localização física onde é armazenado todo hardware que ainda não en-
trou em produção na empresa; as Peças Sobressalentes, que é uma área segura
reservada para armazenamento de peças de reposição para o hardware; e final-
mente a Linha de Base (Baseline), que é a configuração de IC revista e acordada,
que somente poderá ser alterada por uma requisição formal de mudança.
ATIVIDADES DO GERENCIAMENTO DE ATIVO E CONFIGURAÇÃO DE SERVIÇO
Basicamente, as atividades do gerenciamento de ativo e configuração de ser-

viço são:
a) planejamento e gerenciamento da configuração dos ICs;
b) configuração e identificação dos ICs e seus atributos;
c) controle da configuração dos ICs;
d) emissão de relatórios sobre os ICs;
e) verificação e auditoria sobre os ICS.
FUNÇÕES DO GERENTE DE ATIVO E CONFIGURAÇÃO DE SERVIÇO
Segundo Freitas (2010), o gerente de ativo e configuração de serviço exerce as

seguintes funções:
67
a) define as políticas, padrões e processos de gerenciamento de ativos de ser-

viço da organização;
b) avalia os desenhos de novos serviços ou melhorias nos serviços atuais;
c) participa do planejamento de estimativa de esforço para a criação, monito-
ramento e relatório dos serviços;
d) avalia as ferramentas necessárias para a identificação e visualização dos ser-
viços;
e) participa da auditoria de conformidade do sistema de gerenciamento de
configuração;
f) provê relatórios de serviços de TI.
Além do gerente do ativo de serviço, também existem

os seguintes profissionais relacionados a esse proces-
VOCÊ so: gerente de configuração, analista de configuração,
SABIA? administrador da configuração, administrador de ferra-
menta de gerenciamento de configuração e um comitê
de controle de configuração.
Agora você já sabe que essa atividade é importante porque permite à orga-
nização ter controle de todos os seus itens de configuração. Logo, quando você
precisar saber qual é a configuração de hardware do principal servidor da sua
empresa, já sabe a quem recorrer.
2.16 GERENCIAMENTO DE MUDANÇAS

Dreamstime (2012)
Figura 26 - Gerenciamento de mudanças

68
Mudança é adição, modificação ou remoção de um serviço autorizado, plane-

jado e suportado e/ou de seus componentes e documentação associada.
Nesse contexto, considere o seguinte cenário: a área de suporte de TI tem
executado o serviço de manutenção de monitores seguindo sempre o mesmo
processo: registro da reclamação do cliente, recolhimento do monitor para diag-
nóstico, definição do prazo de execução do serviço, solicitação de peças de repo-
sição ao fornecedor, reparo e devolução para o cliente. Com base na experiência
adquirida, e no feedback de seus clientes, o gerente dessa área percebeu que a
definição do prazo de execução vinha falhando, pois nem sempre o fornecedor
entregava as peças no prazo definido pelo técnico. Logo, havia a necessidade de
uma mudança nesse processo. Então ele decidiu propor a seguinte mudança: a
definição do prazo de execução passaria a ser realizada somente após uma con-
sulta ao fornecedor.
Esse exemplo mostra que os processos de entrega dos serviços de TI precisam
passar por mudanças, que por sua vez precisam ser planejadas. Para gerenciar
mudanças, existe a área de gerenciamento de mudanças.
OBJETIVO DO GERENCIAMENTO DE MUDANÇAS
O objetivo do gerenciamento de mudanças é garantir que as mudanças ne-

cessárias para melhoramento na entrega dos serviços de TI sejam devidamente
registradas, avaliadas, autorizadas, priorizadas, planejadas, testadas, implemen-
tadas, documentadas e revisadas de maneira controlada. Essa abordagem per-
mite que os riscos impostos pelas mudanças sejam minimizados por meio de um
planejamento de implementação de mudanças, e que estas, uma vez aprovadas,
sejam implementadas considerando requisitos de custo, prazo e qualidade.
A premissa básica do gerenciamento de mudanças é: “Nada muda antes de ser
avaliado, planejado e aprovado”.
Segundo Freitas (2010), as mudanças podem ocorrer em quatro níveis: estra-
tégico, tático, operacional e técnico.
Mudanças estratégicas são aquelas que podem impactar nos serviços estra-
tégicos da organização, que podem causar perdas financeiras, ter implicações
legais ou provocar danos à imagem da empresa. As táticas geralmente estão
ligadas a atividades comerciais da organização. As operacionais estão relacio-
nadas à entrega dos serviços de TI e as mudanças técnicas ocorrem no nível de
componentes de TI, mas sem afetar os serviços, pois geralmente são mudanças
necessárias apenas para correções de componentes de TI.
69
PROCESSO DE MUDANÇA
Uma vez identificada uma necessidade de mudança, existe um caminho a ser

percorrido para que a mesma seja implementada. Esse caminho envolve quatro
etapas: proposta de mudança, requisição de mudança, registro de mudança e ins-
trução de trabalho.
A proposta de mudança é uma avaliação inicial sobre a necessidade de mu-
dança. Devem ser elaborados estudos prévios de impacto, de custos e de riscos.
Com base nesses estudos é elaborada uma requisição de mudança (RDM). A
RDM é um documento formal que segue para aprovação ou não. Uma vez aprova-
do, esse documento gera um registro de mudança, que deve referenciar todos
os componentes que serão afetados pela mudança. Finalmente, é gerada uma
instrução de trabalho, que é um documento que contém instruções detalhadas
sobre os passos que devem ser seguidos para executar a mudança.
Entretanto, esse processo serve apenas para mudanças consideradas não
emergenciais. Mudanças emergenciais, que são aquelas realizadas devido à ne-
cessidade de reparar um serviço considerado crítico para o negócio, devem ser
realizadas assim que possível. Logo, seu fluxo de planejamento e aprovação deve
ser mais rápido e prioritário.
O Comitê Consultivo de Mudanças (CCM) é um grupo de pessoas que acon-
selham o gerente de mudanças na avaliação, priorização e planejamento de mu-
danças. Esse comitê deve ser multidisciplinar e possuir representantes de todas as
áreas envolvidas nas mudanças.
ATIVIDADES DO GERENCIAMENTO DE MUDANÇAS
Freitas (2010) define as seguintes atividades para o gerenciamento de mudanças:

a) registro, revisão, avaliação, autorização, programação e coordenação de im-
plementação de mudanças;
b) revisão e fechamento das requisições de mudanças.
RESPONSABILIDADES DO GERENTE DE MUDANÇAS
Além de realizar as atividades do gerenciamento de mudanças descritas no

tópico anterior, o gerente de mudanças deve:
a) gerar relatórios de avaliação das mudanças;
b) gerenciar a programação futura das mudanças;
c) convocar e coordenar a reuniões do CCM.
70
Agora você já sabe que o processo de execução de serviços de TI sofre mudan-

ças, e que essas mudanças devem ser avaliadas, planejadas e aprovadas para que
seu impacto seja mínimo na entrega dos serviços.
2.17 GERENCIAMENTO DE LIBERAÇÃO E IMPLANTAÇÃO
Dreamstime (2012)
Figura 27 - Gerenciamento de liberação e implantação
Pense na seguinte situação: o servidor da empresa em que você trabalha tem

apresentado constantemente problemas de desempenho. Nos últimos meses,
parou por três vezes em horário considerado crítico para a empresa. Na primeira
vez em que o servidor parou, foi realizado um upgrade em sua memória princi-
pal e secundária, com o objetivo de resolver o problema e suportar a demanda.
Apesar disso, o servidor ainda parou mais duas vezes até que o problema fosse
resolvido. Algumas perguntas surgem nesse cenário: Por que esse problema de
desempenho não foi resolvido logo na primeira vez em que servidor parou? Por
que o servidor foi liberado para entrar novamente em produção sem a devida
capacidade para suportar o serviço? Para auxiliar nas respostas a esses questiona-
mentos existe o processo de gerenciamento de liberação e implantação.
OBJETIVO DO GERENCIAMENTO DE LIBERAÇÃO E IMPLANTAÇÃO
O objetivo do gerenciamento de liberação e implantação é implantar libera-

ções no ambiente de produção da organização de maneira controlada e plane-
jada, a fim de garantir sua qualidade e a consequente entrega do serviço de ma-
neira adequada. Em outras palavras, podemos dizer que para entrar em produção
(ser implantado), um serviço deve ser aprovado, com sua qualidade garantida por
meio de processos de análise, planejamento e testes.
71
Segundo Freitas (2010), um dos fatores que contribuem para a quantidade de

incidentes de TI tem sido justamente a qualidade das implantações, que são rea-
lizadas sem o devido planejamento.
Sabe-se, entretanto, que a maioria dessas implantações mal planejadas é
emergencial. Apesar disso, sua liberação também deve ser cuidadosamente pla-
nejada.
Uma unidade de liberação descreve uma parte de um serviço de TI que é libe-
rado de acordo com a política de liberação da empresa. Para criar uma unidade
de liberação, os seguintes fatores devem ser considerados: a quantidade de regis-
tros de mudanças e instruções de trabalho necessária; a quantidade de recursos
e tempo necessária para construir, testar, distribuir e implementar a unidade; a
complexidade do relacionamento entre a unidade e os outros itens de configu-
ração; o ambiente disponível para a construção, teste, distribuição e implemen-
tação da unidade; e a janela de mudanças necessária para implementação das
unidades.
AS TÉCNICAS DE LIBERAÇÃO DOS SERVIÇOS
As principais técnicas de liberação dos serviços são:

a) Big Bang;
b) Liberação por fases;
c) Push and Pull.
Na técnica Big Bang, a implantação de novos serviços é feita de uma única
vez. Esse não é o modelo ideal para todos os cenários, mas em algumas situações
específicas, como o upgrade de estações de trabalho ou troca de servidores, não
há outra opção.
Na liberação por fases, o serviço é liberado em partes. Essa técnica é utilizada
para determinados serviços que permitem uma implantação gradual (por ondas).
Um exemplo seria a implantação de novos módulos de um sistema.
Já a liberação do tipo Push and Pull é utilizada quando uma parte de um siste-
ma maior, seja de hardware ou software, precisa ser atualizada. Por exemplo, atua-
lização de services packs em sistemas operacionais ou upgrade de memória com o
computador em funcionamento (quando o hardware permite esse tipo de prática).
Essas três técnicas de liberação podem ocorrer de forma manual ou automáti-
ca. As liberações manuais ocorrem quando há intervenção humana no processo.
Nas automáticas, isso não ocorre.
72
ATIVIDADES DO GERENCIAMENTO DE LIBERAÇÃO E IMPLANTAÇÃO
A área de gerenciamento de liberação e implantação realiza as seguintes ati-

vidades:
a) desenvolvimento dos planos de liberação e implantação;
b) preparação para produção, teste e implantação;
c) gerenciamento das atividades de construção e teste;
d) realização de testes no serviço que será implantado;
e) planejamento e preparação para implantação;
f) gerenciamento de transferências de políticas, processos, procedimentos,
habilidades e capacidades de execução dos serviços;
g) verificação da implantação;
h) suporte para o período de funcionamento experimental;
i) revisão e encerramento da implantação e da transição de serviço.
O processo de gerenciamento de liberação e implantação termina somente
após a revisão e o fechamento da requisição de mudança pelo gerenciamento de
mudanças.
RESPONSABILIDADES DO GERENTE DE LIBERAÇÃO E IMPLANTAÇÃO
Basicamente, o papel do gerente de liberação e implantação é projetar e pla-

nejar a construção dos pacotes de liberação. Pacotes de liberação são conjuntos
de requisições de implantação elaborados para atender às requisições de mudan-
ça no ambiente de TI.
Agora você já conhece a importância de se planejarem as mudanças que de-
vem ocorrer no ambiente de TI. Sem planejamento, essas mudanças podem atra-
palhar a entrega adequada dos serviços. E quem cuida desse planejamento é a
área de gerenciamento de liberação e implantação.
73
2.18 GERENCIAMENTO DO CONHECIMENTO
Dreamstime (2012)
Figura 28 - Gerenciamento do conhecimento
Você já teve que decidir algo em sua vida, correto? Por isso você sabe que
qualquer decisão, seja ela profissional ou pessoal, deve ser tomada com base em
algum conhecimento previamente adquirido. Por exemplo, você tomou a deci-
são de comprar uma moto em vez de um carro porque descobriu que os gastos
de combustível da moto são menores. Você ficou sabendo disso porque colheu
informações em diversas fontes e construiu um conhecimento sobre o assunto.
Ou seja, tomada de decisão é o processo pelo qual são escolhidas algumas ou
apenas uma entre muitas opções para determinada ação. Ou, numa definição de
Chiavenato (2003), é um processo de análise e escolha entre várias alternativas
disponíveis do curso de ação que a pessoa deverá seguir.
Em resumo, tomar uma decisão nada mais é do que a conversão das informa-
ções em ações, ou seja, é a ação tomada com base na apreciação de informações.
Apreciar informações gera conhecimento. Para gerenciar esse conhecimento,
que servirá como base para o processo de tomada de decisão na empresa, existe
a área de gerenciamento do conhecimento.
OBJETIVO DO GERENCIAMENTO DO CONHECIMENTO
O objetivo do gerenciamento de conhecimento é garantir que a informação

correta esteja disponível em local apropriado, para as pessoas competentes, no
momento certo, a fim de auxiliar no processo de tomada de decisão.
74
Isso é importante porque auxilia as organizações a melhorarem a qualidade

das decisões, garantindo que informações confiáveis e seguras estejam disponí-
veis por intermédio do ciclo de vida dos serviços.
Chiavenato (2003) diz que toda tomada de decisão envolve seis elementos:
a) Tomador de decisão: é a pessoa que faz uma escolha ou opção entre várias
alternativas futuras de ação;
b) Objetivos: são os objetivos que o tomador de decisão pretende alcançar
com suas ações;
c) Preferências: são os critérios que o tomador de decisão usa para fazer sua
escolha;
d) Estratégia: é o curso de ação que o tomador de decisão escolhe para atingir
seus objetivos. O curso de ação é o caminho escolhido e depende dos recur-
sos de que pode dispor;
e) Situação: é o ambiente que envolve o tomador de decisão, por vezes com
aspectos fora do seu controle, conhecimento ou compreensão e que afetam
sua escolha;
f) Resultado: é a consequência ou resultante de uma dada estratégia.
Para explicar este processo, Chiavenato (2003) afirma que:
O tomador de decisão está inserido em uma situação, preten-

de alcançar objetivos, tem preferências pessoais e segue es-
tratégias (cursos de ação) para alcançar resultados. A decisão
envolve uma opção. Para a pessoa seguir um curso de ação,
ela deve abandonar outros cursos que surjam como alternati-
vas. Há sempre um processo de seleção, isto é, de escolha de
alternativas. O processo de seleção pode ser uma ação reflexa
condicionada (como digitar as teclas do computador) ou pro-
duto de raciocínio, planejamento ou projeção para o futuro.
Todo curso de ação é orientado no sentido de um objetivo a
ser alcançado e segue uma racionalidade. O tomador de de-
cisão escolhe uma alternativa entre outras: se ele escolhe os
meios apropriados para alcançar um determinado objetivo,
sua decisão é racional.
Dá-se o nome de racionalidade limitada ao fenômeno em que as pessoas to-

mam decisões racionais apenas em relação aos aspectos da situação que podem
perceber e interpretar, sem levar em consideração outros aspectos existentes.
75
O PROCESSO DE TOMADA DE DECISÃO
Segundo Chiavenato (2003) o processo de tomada de decisão é complexo e de-

pende das características pessoais do tomador, da situação em que está envolvido
e da maneira como percebe a situação. Este processo exige as seguintes etapas:
a) percepção da situação que envolve algum problema;
b) análise e definição do problema;
c) definição dos objetivos;
d) procura de alternativas de solução ou de cursos de ação;
e) escolha (seleção) da alternativa mais adequada ao alcance dos objetivos;
f) avaliação e comparação das alternativas;
g) implementação da alternativa escolhida.
CONCEITOS DO GERENCIAMENTO DE CONHECIMENTO
O primeiro conceito importante do gerenciamento do conhecimento diz respei-

to às estruturas de dados para informação, conhecimento e sabedoria, os DICS. Os
DICS são bases de dados onde estão armazenadas as informações a respeito de toda
infraestrutura de TI disponível para entrega dos serviços, bem como outras informa-
ções importantes como registros de incidentes ou disponibilidade dos serviços.
Já o sistema de gerenciamento de conhecimento (SGCS) é um repositório cen-
tral de armazenamento de informações e conhecimento, que tem o objetivo de
armazenar, gerenciar, atualizar e apresentar todas as informações necessárias à
tomada de decisão.
ATIVIDADES DO GERENCIAMENTO DE CONHECIMENTO
Freitas (2010) define as seguintes atividades para o gerenciamento de conhe-

cimento:
a) definir a estratégia de gerenciamento do conhecimento;
b) compartilhar conhecimento com as partes envolvidas;
c) gerir os dados e informações que compõem a base de dados de gerencia-
mento do conhecimento;
d) utilizar o sistema de informação de gerenciamento do conhecimento.
76
RESPONSABILIDADES DO GERENTE DE CONHECIMENTO
O gerente de conhecimento fica responsável por:

a) entender os requisitos de conhecimento da organização;
b) identificar, capturar e manter o conhecimento adquirido;
c) manter o sistema de gerenciamento do conhecimento;
d) monitorar a publicação de conhecimento;
e) agir como conselheiro no gerenciamento de conhecimento.
Agora você já sabe que o processo de tomada de decisão depende do conhe-
cimento sobre determinado assunto. Logo, os dados que formam a base desse co-
nhecimento devem ser gerenciados para garantir que a informação correta esteja
disponível em local apropriado, para as pessoas competentes e no momento certo.
2.19 GERENCIAMENTO DE INCIDENTES
Denis Pacher (2012)
Figura 29 - Gerenciamento de incidentes
O que acontece quando a entrega de um serviço de TI é interrompida? E quan-

do a qualidade na entrega de um serviço deixa a desejar? O gerente da área de TI
deve tomar alguma providência para que a entrega desse serviço seja restaurada
de forma adequada. A essa interrupção ou redução da qualidade na entrega de
77
um serviço dá-se o nome de incidente. Quem cuida do tratamento dos inciden-

tes é a área conhecida como gerenciamento de incidentes.
OBJETIVO DO GERENCIAMENTO DE INCIDENTES
O objetivo da área de gerenciamento de incidentes é restaurar a operação de

um serviço, quando ocorre uma interrupção, da forma mais ágil possível, visando
minimizar o impacto que esse incidente pode causar no negócio.
Existem vários exemplos de incidentes das mais diferentes classificações. O
simples fato de um usuário não conseguir se autenticar em uma máquina conec-
tada à rede da empresa é considerado um incidente leve. Já a indisponibilidade
de toda a rede da empresa, impedindo acessos aos sistemas, também é conside-
rado um incidente, mas de natureza grave.
O gerenciamento de incidentes é responsável apenas pelo tratamento dos
eventos que causam a interrupção dos serviços, causando falhas em sua opera-
ção normal. Já o termo “operação normal” refere-se aos níveis de serviços que
foram combinados na elaboração dos acordos de nível de serviço (SLA).
O PROCESSO DE GERENCIAMENTO DE INCIDENTES
O gerenciamento de incidentes deve prover um canal de comunicação de in-

cidentes com os usuários. Esse canal geralmente é a central de serviços (service
desk). A central de serviços é o principal canal de comunicação com os usuários e
em alguns casos é a única porta de comunicação com a equipe de TI.
Segundo Freitas (2010), com base nas prioridades de atendimento de inciden-
tes e as metas acordadas dos níveis de serviço, as equipes de atendimento de inci-
dentes devem planejar seus horários de atendimento e prazos de resolução. Para
isso todos os incidentes devem necessariamente ser identificados, registrados,
categorizados, priorizados, diagnosticados, encaminhados, investigados, resolvi-
dos e encerrados, conforme ilustrado na figura a seguir.
78
Identificação
Registro
Categorização
Priorização
Diagnóstico
Encaminhamento
Investigação
Resolução

Encerramento
Figura 30 - Processo de Gerenciamento de Incidentes
a) Identificação do incidente
A identificação do incidente pode ser feit de três formas:
a) pela área de gerenciamento de eventos e em seguida comunicada à área
de gerenciamento de incidentes;
b) por identificação da própria equipe de TI;
c) pela comunicação do usuário.
A comunicação do usuário é a forma mais comum e pode ser feita via registro
telefônico, abertura de um chamado via sistema ou central de serviços.
b) Registro do incidente
Todas as informações relevantes sobre o incidente devem ser registradas, pre-
ferencialmente em um sistema específico para essa finalidade.
c) Categorização do incidente
Todos os incidentes devem ser categorizados (ou classificados) de acordo com
critérios estabelecidos pela empresa. Por exemplo: incidente de rede, de sistema,
de hardware etc.
79
d) Priorização do incidente
A priorização do incidente geralmente é feita com base no impacto que o mes-
mo causou na entrega do serviço e na importância desse serviço para a organiza-
ção. Exemplos de priorização são: prioridade imediata, alta, média ou baixa.
Freitas (2010) afirma que incidentes considerados graves, ou seja, que cau-
sam impacto significativo no negócio, devem ter seu atendimento realizado com
urgência. Isso deve ser feito com base no planejamento de procedimentos de
atendimento diferenciados. É importante saber que a definição da “gravidade” do
incidente não deve ser feita pelo usuário, mas por acordos predefinidos onde são
identificados os cenários de riscos para a entrega dos serviços de TI.
e) Diagnóstico do incidente
É o processo de investigação para tentar identificar as características do inci-
dente, para posterior encaminhamento do mesmo. Isso pode ser feito com auxílio
das bases de dados de erros conhecidos ou simplesmente pela experiência do
funcionário ou equipe responsável pelo atendimento.
f) Encaminhamento do incidente
Caso não seja identificada uma solução de contorno após o diagnóstico inicial
do incidente, este deve ser encaminhado para uma equipe capaz de resolver o
problema e restabelecer o serviço.
g) Investigação do incidente
Significa identificar o que está fora da operação padrão de um serviço, enten-
der a ordem dos eventos que levaram ao incidente, confirmar as informações que
levem à classificação de priorização e investigar todas as bases de dados que pos-
sam auxiliar no trabalho de identificação de uma possível solução para o incidente.
h) Resolução do incidente
Caso não seja identificada uma solução de contorno para o incidente, deve ser
elaborada uma solução para o mesmo. Isso pode ou não envolver a modificação
de um item de configuração. Caso seja necessário modificá-lo, deve ser aberto um
registro de modificação formal.
i) Encerramento do registro de incidente
Após a resolução do incidente, a central de serviços deve verificar se todas as
informações importantes a respeito do incidente foram registradas. Feito isso, ela
entra em contato com o(s) usuário(s) do serviço para saber se o mesmo foi resta-
belecido de forma adequada.
80
RESPONSABILIDADES DO GERENTE DE INCIDENTES
Além de conduzir o processo acima descrito, Freitas (2010) cita que o gerente
de incidentes deve realizar as seguintes tarefas:
a) garantir a eficácia e eficiência das atividades do gerenciamento de incidentes;
b) prover relatório sobre os incidentes dos serviços de TI da organização;
c) gerenciar as equipes de atendimento de incidentes;
d) monitorar as atividades de gerenciamento de incidentes e propor melho-
rias no processo;
e) planejar e manter os sistemas de gerenciamento de incidentes;
f) gerenciar incidentes graves;
g) desenvolver procedimentos e políticas de modelos de incidentes, encami-
nhamento, priorização e resolução de conflitos no atendimento de incidentes.
Agora você sabe que incidentes podem acontecer na entrega dos serviços de
TI, e que eles podem causar interrupção dos serviços. Para tratá-los existe a área
de gerenciamento de incidentes.
2.20 GERENCIAMENTO DE EVENTOS
A área de TI está sujeita a vários tipos de ocorrências. Algumas com pouca

relevância, outras com certo grau de risco para entrega dos serviços. Tentativas
de intrusões na rede da empresa, alertas de vírus ou de falhas em componentes,
baixo desempenho de sistemas, de servidores e bancos de dados são exemplos
de eventos do dia a dia da TI que devem ser monitorados. Esse monitoramento
é importante porque em alguns casos um evento pode afetar o desempenho ou
até mesmo causar paralisação na entrega dos serviços de TI. Quando isso ocorre,
o evento torna-se um incidente. Logo, um dos principais objetivos da área de ge-
renciamento de eventos é evitar que os eventos se transformem em incidentes.
OBJETIVO DO GERENCIAMENTO DE EVENTOS
O objetivo da área de gerenciamento de eventos é monitorar todos os eventos

que acontecem no ambiente de TI da organização e gerar alertas ou notificações
a respeito desses eventos.
Além de monitorar os eventos relacionados à entrega dos serviços de TI, a área
de gerenciamento de eventos também é responsável por indicar quais serão as
ações seguintes, ou seja, o que deverá ser feito para tratar o evento.
81
O PROCESSO DE GERENCIAMENTO DE EVENTOS
O processo de gerenciamento de eventos envolve as seguintes atividades em

relação aos eventos: identificação da ocorrência, notificação, detecção, filtro, ca-
tegorização, correlação, direcionamento, seleção da reação, revisão e fechamen-
to, conforme ilustrado na figura a seguir.
Identificação Correlação
Notificação Direcionamento
Detecção Reação
Filtro Revisão
Categorização Encerramento
Figura 31 - Processo de gerenciamento de eventos
a) Identificação da ocorrência do evento

Envolve a definição dos eventos que precisam ser identificados.
b) Notificação do evento
É a informação que o evento ocorreu no ambiente de TI. Isso deve ser feito
através de alguma ferramenta de monitoramento do ambiente.
c) Detecção do evento
Uma vez notificado, deve ser detectado se o evento realmente ocorreu.
d) Filtro do evento
Esse filtro serve para verificar se o evento deve ser ignorado ou comunicado
aos responsáveis pelo seu tratamento. O filtro deve ocorrer porque muitos even-
tos não representam riscos para a entrega dos serviços de TI.
e) Categorização do evento
A categorização do evento é o meio utilizado para definição da forma de tra-
tamento do mesmo. Alguns eventos podem ser apenas informativos, não reque-
rendo ações. Outros podem ser avisos que requerem algum tipo de ação, por
exemplo, quando a disponibilidade de memória em disco rígido de algum servi-
dor está se esgotando. Outros eventos podem ser de natureza mais grave. Esses
82
eventos, chamados de exceções, identificam que uma determinada situação pre-

definida não está funcionando conforme o previsto, e que isso pode impactar nos
serviços de tal forma que se tornem um incidente.
f) Correlação do evento
Nessa etapa os eventos são relacionados ao tipo de impacto que podem cau-
sar. Por exemplo, alguns eventos podem causar impacto nos sistemas ou nos ser-
vidores da organização. Essa correlação é necessária para o correto encaminha-
mento da solução do problema.
g) Direcionamento do evento
Deve indicar para quem ou para onde os eventos devem ser informados. Isso
deve ser feito de acordo com a classificação realizada na etapa anterior.
h) Seleção da reação ao evento
Considerando a categoria do evento, há vários tipos de ações que podem ser
realizadas para tratamento dos mesmos. Eventos informativos geralmente são ar-
quivados. Já avisos e exceções podem requerer ações humanas ou automáticas
para tratamento. Alguns eventos também podem requerer alteração de algum
item de configuração. Nesse caso, deve ser gerada uma requisição formal de mu-
dança (RDM).
i) Revisão da ação de reação ao evento
O processo de tratamento de eventos não é estático e deve ser revisto durante
o processo. Nesse caso, é fundamental verificar se os eventos importantes, com as
exceções críticas, por exemplo, estão sendo direcionados corretamente.
j) Fechamento
É importante que o tratamento determinado para algum evento seja formal-
mente encerrado. Isso indica que aquele evento foi tratado de forma adequada.
O gerente de eventos é a pessoa responsável por conduzir o processo descrito

acima.
Existe diferenças entre evento, incidente e problema. Segundo Freitas (2010),
um evento é uma mudança de status significativa para o gerenciamento de servi-
ço de TI. É um alerta de notificação criado por qualquer serviço de TI, item de con-
figuração ou ferramenta de monitoração. Eventos geralmente requerem ações
das equipes de operação de TI e podem iniciar um registro de incidente. Já um in-
cidente é uma interrupção não planejada de um serviço de TI ou a redução de sua
qualidade. Finalmente, um problema é a causa raiz de um ou mais incidentes. A
causa raiz não é conhecida no momento em que o registro do problema é criado.
O tratamento dos problemas é feito pela área de gerenciamento de problemas.
83
Agora você sabe que devemos evitar que eventos se transformem em inciden-
tes. Para isso, o evento deve ser monitorado e tratado, sendo que tratar eventos é
função da área de gerenciamento de eventos.
2.21 GERENCIAMENTO DE REQUISIÇÃO
Nem todos os eventos que acontecem no dia a dia na área de TI são problemas
ou incidentes. Algumas atividades consideradas rotineiras, que não influenciam
na entrega dos serviços ou não representam uma ameaça (como uma simples tro-
ca de senha de usuário ou substituição de um cartucho de impressora), também
devem ser atendidas. A esses eventos dá-se o nome de requisições.
OBJETIVO DO GERENCIAMENTO DE REQUISIÇÕES
O objetivo do gerenciamento de requisições é executar as requisições (ou so-

licitações) de serviços dos usuários. São exemplos de requisições: troca de senha
de usuário, troca de cartucho de impressora, mudança de localização física de
equipamentos, instalação de softwares, suporte a sistemas corporativos etc.
Qualquer outra solicitação que não cause impacto na operação de TI, que não
necessite de pré-aprovação e sua operação possa ser padronizada e agilizada
também é considerada uma requisição.
É muito importante que as equipes de suporte de TI saibam diferenciar uma
solicitação de serviço de um registro de incidente. Enquanto um registro de inci-
dente identifica uma interrupção não planejada de um serviço de TI ou a redução
de sua qualidade, uma solicitação de serviço é um pedido de um usuário para
realizar alguma atividade simples que não cause impacto na entrega dos serviços.
O PROCESSO DE GERENCIAMENTO DE REQUISIÇÕES
O processo de gerenciamento de requisições é composto pelas seguintes ati-

vidades (FREITAS, 2010): registro da requisição de serviço, aprovação, execução e
fechamento. A figura a seguir ilustra esse processo.
Registro da Aprovação da Execução do Fechamento

Requisição Requisição Serviço da Requisição
Figura 32 - Processo de Gerenciamento de Requisições

84
a) Registro da requisição de serviço

As requisições de serviços devem ser feitas à central de serviços. É ela que de-
fine a forma pela qual as requisições serão registradas. Geralmente a solicitação é
feita via telefone ou por algum sistema disponibilizado pela empresa.
b) Aprovação da requisição de serviço
Quando necessário, a requisição deve ser encaminhada para aprovação. Geral-
mente essa aprovação é um evento meramente informativo, apenas para ciência
do gerente da área que irá entregar o serviço. Por exemplo, a disponibilização de
algum recurso de hardware, como um data show, deve ser comunicada ao res-
ponsável pela área para que este faça a reserva do equipamento. Obviamente o
recurso pode não ser entregue, caso não esteja disponível.
c) Execução do serviço
É a execução propriamente dita do serviço pela área responsável. A execução
deve respeitar os acordos de nível de serviço feitos.
d) Fechamento da requisição
A central de serviços entra em contato com o usuário para saber se o serviço
foi mesmo entregue. Em caso positivo, a requisição de serviço é encerrada.
Não existe o papel de gerente de requisições. O responsável pela execução do
processo acima é a central de serviços. O objetivo da central de serviços é ser um
ponto único de contato para usuários de TI, além de prover a restauração normal
dos serviços dentro dos prazos definidos nos acordos de nível de serviço.
Agora você sabe que caso algum usuário necessite de algum serviço rotineiro
que não influencie na entrega dos serviços ou represente alguma ameaça, este
deve recorrer à central de serviços e registrar uma requisição de serviço.
2.22 GERENCIAMENTO DE PROBLEMAS

Dreamstime (2012)
Figura 33 - Gerenciamento de problemas

85
Antes de falar sobre problema, é importante relembrar o conceito de inciden-

te. Incidente é qualquer evento que cause a interrupção na entrega de um serviço
de TI. Mas você sabe o que causa um incidente? A resposta é: um problema. Por
exemplo, o principal software da empresa esteve indisponível por 30 minutos na
tarde da última segunda-feira. Isso é um incidente. Mas qual a causa desse inci-
dente? Após investigação da área técnica responsável, foi observado que esse
incidente foi provocado por um problema no banco de dados que armazena as
informações do software.
Percebeu agora a diferença entre incidente e problema? A questão é que pro-
blema só existe no contexto dos incidentes. Em outras palavras, os problemas
geram incidentes. Quem cuida do tratamento dos problemas é a área conhecida
como gerenciamento de problemas.
OBJETIVO DO GERENCIAMENTO DE PROBLEMAS
De acordo com Freitas (2010), o objetivo da área de gerenciamento de proble-

mas é prevenir a ocorrência de problemas e incidentes associados através da eli-
minação de incidentes recorrentes e da minimização do impacto dos incidentes
que não puderam ser prevenidos.
O autor enfatiza ainda a diferença entre incidente e problema:
Registro de incidentes é diferente de registro de problemas.

Um incidente não se transforma em um problema. Um inci-
dente gera a abertura de um registro de problema. São dois
registros diferentes, atendidos sob atividades diferentes, com
propósitos diferentes. Enquanto o objetivo do gerenciamento
de incidentes é restabelecer a entrega do serviço de TI o mais
rápido possível, o objetivo do gerenciamento de problema é
encontrar a causa raiz do problema e aplicar uma solução defi-
nitiva para sua resolução.
O gerenciamento de problemas é uma atividade geralmente realizada pelas

equipes técnicas com maior nível de conhecimento. Muitas empresas possuem
somente equipes de gerenciamento de incidentes e passam a vida toda aplican-
do soluções de contorno para restaurar a entrega dos serviços, sem se preocupar
em solucionar a causa raiz dos problemas que geram os incidentes.
86
O PROCESSO DE GERENCIAMENTO DE PROBLEMAS
O processo de gerenciamento de problemas envolve as seguintes atividades:

detecção, registro, categorização, priorização, investigação e diagnóstico do pro-
blema, identificação de solução de contorno, registro do erro conhecido, resolu-
ção e fechamento do problema. A figura a seguir ilustra este processo.
Detecção
Identificação de
Solução de
Contorno
Registro
Registro do Erro
Categorização Conhecido
Priorização Resolução

Investigação Fechamento
Figura 34 - Processo de Gerenciamento de Problemas
a) Detecção do problema
Envolve a identificação dos problemas que causam incidentes recorrentes, ou
incidentes para os quais ainda não foi elaborada uma solução de contorno.
b) Registro do problema
Todas as informações relevantes sobre o problema devem ser registradas, pre-
ferencialmente em um sistema específico para essa finalidade.
c) Categorização do problema
Todos os problemas devem ser categorizados (ou classificados) de acordo
com critérios estabelecidos pela empresa. Por exemplo: problemas de rede, de
sistema, de hardware etc.
d) Priorização do problema
A priorização do problema geralmente é feita com base no impacto que esse
causou na entrega do serviço e na importância desse serviço para a organização.
Exemplos: prioridade imediata, alta, média ou baixa.
87
e) Investigação e diagnóstico do problema

As investigações devem ser conduzidas para identificação da causa raiz dos
problemas. Esse tipo de investigação tem o objetivo de encontrar, e ajudar a ata-
car, a real causa de um determinado problema, e não seu efeito. Quando não se
resolve a causa raiz de um problema, a tendência é que outros efeitos semelhan-
tes (ou o mesmo) apareçam no futuro.
f) Identificação de solução de contorno
As soluções de contorno devem ser utilizadas enquanto a causa raiz é identifi-
cada e o problema é resolvido.
g) Registro do erro conhecido
As soluções encontradas devem ser armazenadas em um banco de dados co-
nhecido como base de dados de erros conhecidos. Essa base de dados é impor-
tante porque servirá de referência para resolução de outros problemas semelhan-
tes que possam ocorrer no futuro.
h) Resolução do problema
A resolução em si da causa raiz do problema é feita pela equipe técnica com-
petente.
i) Fechamento do problema
Após a resolução do problema, a central de serviços deve verificar se todas as
informações importantes a respeito do problema foram registradas e, em segui-
da, encerrar o processo.
RESPONSABILIDADES DO GERENTE DE INCIDENTES
Além de conduzir o processo acima, Freitas (2010) cita que o gerente de pro-
blemas deve realizar as seguintes tarefas:
a) garantir a comunicação entre grupos de resolução de problemas visando
garantir a resolução dos problemas dentro das metas definidas nos acordos
de nível de serviço;
b) manter a base de dados de erros conhecidos;
c) garantir o fechamento dos registros de problemas;
d) fornecer informações sobre os problemas;
e) gerenciar as atividades da revisão de problemas críticos.
Agora você sabe que incidentes e problemas são conceitos que, apesar de
diferentes, estão diretamente relacionados. E que para tratar os problemas existe
a área de gerenciamento de problemas.
88
2.23 GERENCIAMENTO DE ACESSO
Dreamstime (2012)
Figura 35 - Gerenciamento de acesso
O acesso aos serviços de TI está disponível a todos os funcionários de uma

organização? Por exemplo, qualquer usuário pode propor mudança em um siste-
ma ou enviar um componente de hardware para reparo? A resposta é: depende
dos níveis de acesso concedido a esses usuários. Determinados serviços, princi-
palmente aqueles considerados críticos, não podem ser acessados por qualquer
funcionário, apenas por aqueles que têm direito de acesso a eles. Para gerenciar a
política de acesso da organização existe a área de gerenciamento de acesso.
OBJETIVO DO GERENCIAMENTO DE ACESSO
O gerenciamento de acesso tem como objetivo garantir que apenas usuários

autorizados possam utilizar serviços de TI, visando garantir a confidencialidade, a
integridade e a disponibilidade dos mesmos.
Segundo a norma ISO/IEC 27001 (2006), confidencialidade é a propriedade
de que a informação não esteja disponível ou revelada a indivíduos, entidades ou
processos não autorizados. Integridade é a propriedade de salvaguarda da exati-
dão e completeza de ativos. E disponibilidade é a propriedade de estar acessível
e utilizável sob demanda por uma entidade autorizada.
89
Uma vez que o objetivo da área de segurança da informação é a preservação

da confidencialidade, da integridade e da disponibilidade da informação, e adi-
cionalmente outras propriedades, tais como autenticidade, responsabilidade, não
repúdio e confiabilidade, pode-se concluir que há uma relação importante entre
a área de gerenciamento de segurança da informação e a área de gerenciamento
de acesso. Tanto que as atividades previstas para o gerenciamento de acesso são
geralmente realizadas pelo gerente de segurança da informação. Isso ocorre tam-
bém pelo fato de não existir formalmente a função de gerente de acesso.
Freitas (2010) define alguns conceitos importantes relacionados ao gerencia-
mento de acesso:
a) Acesso refere-se a determinado nível de funcionalidades de um serviço ou
dados a que um usuário possui direito de acesso e uso;
b) Identidade é a forma única pela qual um usuário é identificado dentro de
uma organização;
c) Direitos são os privilégios que o acesso do usuário tem a determinadas fun-
cionalidades ou dados;
d) Serviços ou grupos de serviços são conjuntos de serviços semelhantes que
podem ser agrupados em perfis de acesso;
e) Serviços de diretórios são ferramentas utilizadas para gerenciar os privilé-
gios de acesso dos usuários.
ATIVIDADES DO GERENCIAMENTO DE ACESSO
Segundo Freitas (2010), o gerenciamento de acesso deve realizar basicamen-

te as seguintes atividades: gerenciamento das solicitações de acesso, verificação
das solicitações de acesso, provimento de permissões, monitoramento do status
das identidades, registro e rastreamentos de acessos e remoção ou restrição de
permissões.
a) Gerenciamento das solicitações de acesso
É importante que as solicitações de acesso sejam formalmente registradas. Ge-
ralmente o usuário solicita o acesso por telefone, via central de serviços, que deve
cadastrar o pedido em um software específico para essa finalidade.
b) Verificação das solicitações de acesso
Nesse momento, duas situações devem ser verificadas: a identificação correta
do funcionário (se o usuário é realmente quem ele diz que é), e se ele tem autori-
zação para fazer a solicitação.
90
c) Provimento de permissões
O gerenciamento de acesso concede (ou não) acesso, considerando as políti-
cas de acesso elaboradas no ciclo de estratégia de serviço. Ele não tem autonomia
para decidir sozinho se o acesso deve ser dado ou não para determinado usuário.
d) Monitoramento do status das identidades
Todas as mudanças de acessos que ocorrem no ambiente de TI devem ser ge-
renciadas. Por exemplo, o acesso de funcionários que foram demitidos e que per-
deram todo acesso, os que foram transferidos ou promovidos e mudaram o tipo
de acesso.
e) Registro e rastreamentos de acessos
Além de conceder e retirar acessos, o gerenciamento de acessos deve moni-
torar as atividades realizadas considerando os perfis de acessos concedidos. Por
exemplo, detectar uso não autorizado de determinado sistema. A auditoria nos
acessos concedidos também é realizada nessa fase.
f) Remoção ou restrição de permissões
O gerenciamento de acesso deve remover ou restringir acessos considerando
as políticas de acesso elaboradas no ciclo de estratégia de serviço.
Como dito anteriormente, não há a função do gerente de acesso. Geralmente
as atividades acima são realizadas pela central de serviços ou pelo gerente de
segurança da informação.
Agora você já sabe que o acesso aos serviços de TI deve ser gerenciado, uma
vez que não podem ser acessados por todos os funcionários, e que para isso exis-
te a área de gerenciamento de acesso.
2.24 MELHORIA CONTINUADA DE SERVIÇO
Kai Zen
Change Good
Figura 36 - Melhoria continuada de serviço

91
O princípio básico da filosofia japonesa KAIZEN (do japonês KAI = mudan-

ça, ZEN = melhor) é: “Hoje melhor do que ontem, amanhã melhor do que hoje”
(IMAI, 1994). Essa frase nos leva à seguinte reflexão: melhorar sempre deve ser
uma meta? A resposta é sim. Os processos nas organizações não são estáticos,
devem sempre evoluir e ser aprimorados visando, entre outras coisas, economia
de recursos, prazos e custos. Isso não é diferente na entrega dos serviços de TI.
A área de suporte de TI, por exemplo, deve sempre medir aquilo que faz visan-
do melhoria. Se atualmente consegue realizar um diagnóstico de manutenção
em hardware em até 48 horas, por que não reduzir esse tempo para 24 horas? A
questão é: como isso pode ser feito? Em outras palavras: como aprimorar o pro-
cesso? A resposta pode ser encontrada na atividade conhecida como melhoria
continuada de serviço.
OBJETIVO DA MELHORIA CONTINUADA DE SERVIÇO
A melhoria continuada de serviço tem como objetivo alinhar e realinhar con-

tinuamente os serviços de TI com o negócio e com os requisitos de mudança nos
negócios, através da implementação de melhorias nos processos para entrega dos
serviços de TI. Segundo Freitas (2010), o foco dessa área é a melhoria na eficiência
e eficácia dos processos de gerenciamento de serviços de TI a um custo justificado.
MELHORIA CONTÍNUA X MELHORIA CONTINUADA
Segundo a ITIL (2007), contínuo dá ideia de continuidade ou união de partes

ininterruptas. Já o termo continuada se refere a processos que se repetem. Logo,
o termo melhoria continuada, no contexto da melhoria, dá ênfase na repetição
como ferramenta para melhoramento dos processos.
O PROCESSO DE MELHORIA CONTINUADA
A primeira etapa no processo de melhoria continuada é estabelecer os indi-

cadores de desempenho. Um indicador de desempenho é um valor, ou conjunto
de valores, que mede o desempenho do processo em termos quantitativos. Por
exemplo, qual o tempo médio para reparo de um componente de hardware ou a
quantidade de pessoas necessárias para desenvolver um módulo de um sistema?
Todo o restante do processo visa ao ajuste desses indicadores para melhoria no
desempenho dos processos.
92
O principal indicador utilizado para medir o desempe-

VOCÊ nho de um processo é conhecido como PID (principal
SABIA? indicador de desempenho). Esse termo tem origem na
sigla KPI, do inglês Key Performance Indicator.
Freitas (2010) define sete passos para a melhoria continuada do processo. Veja
a seguir:
a) Definir o que será medido
Este é o primeiro passo no processo de melhoria continuada. Nesse momento
devem ser definidos os PIDs de cada processo, e os outros indicadores que po-
dem ser úteis no processo de aprimoramento.
b) Definir o que pode ser medido
Uma vez definidos os indicadores que precisam ser medidos, o passo seguinte
é a definição daquilo que pode ser medido. Por questões operacionais ou de cus-
to, nem tudo o que é necessário pode ser medido. Por exemplo, medir o tempo
médio para primeiro atendimento de um determinado componente de hardware
pode não ser possível se o registro do atendimento for feito apenas por telefone,
sem o devido armazenamento em software com esse propósito específico.
c) Coleta de dados
Envolve a coleta dos dados que representam os indicadores definidos nos pas-
sos anteriores.
d) Processamento dos dados
Geralmente é necessário algum tipo de processamento dos dados colhidos
na fase anterior, para que sejam posteriormente analisados. Por exemplo, foram
colhidas informações sobre o tempo total gasto para a realização de diagnósticos
em hardware. Já o tempo médio deve ser calculado (processado) em função da
quantidade de atendimentos realizados.
e) Análise dos dados
Uma vez colhidos e processados, os dados seguem para análise, que envolve
a comparação da situação atual com a situação a ser alcançada. Por exemplo, se
a análise dos dados atuais mostrar que apenas 60% dos atendimentos realizados
pela área de suporte de TI são feitos dentro do tempo máximo de 24 horas, e
durante as etapas iniciais de planejamento, com base no feedback dos usuários
observou-se que o desejável era um índice de 90%. Então as ações seguintes de-
vem ser planejadas visando alcançar esse novo índice.
93
f) Apresentação e utilização da informação

Nessa fase as informações colhidas, processadas e analisadas devem ser devi-
damente apresentadas aos responsáveis pelo planejamento dos processos. Com
base nessas informações, o passo seguinte é a implementação das ações correti-
vas para aprimoramento do processo.
g) Implementação das ações corretivas
Envolve a correção, otimização e melhoria dos serviços por meio da imple-
mentação de ações necessárias para tal. É importante ressaltar que não é o geren-
te de melhoria continuada que irá realizar as ações corretivas. Ele apenas identifi-
ca as necessidades. Quem corrige é a equipe técnica responsável pela entrega do
serviço, que por sua vez possui a competência técnica necessária.
RESPONSABILIDADES DO GERENTE DE MELHORIA CONTINUADA DE SERVIÇO
Além de conduzir o processo descrito acima, segundo Freitas (2010) o gerente

de melhoria continuada do serviço deve realizar as seguintes atividades:
a) desenvolver o plano de melhoria continuada do serviço;
b) comunicar sobre a visão da melhoria de serviço a toda a organização de TI;
c) identificar e priorizar as oportunidades de melhoria dos serviços;
d) garantir que os requisitos de nível de serviço estão definidos e os monitora-
mentos de nível de serviço estão operacionais;
e) coletar as linhas de base dos serviços de TI;
f) realizar a Análise de Gap entre os instantâneos coletados e a linha de base
dos serviços de TI;
g) reportar os principais indicadores de desempenho;
h) avaliar se o gerenciamento de conhecimento é uma parte integrante do dia
a dia da operação de TI;
i) garantir que as atividades de melhoria continuada estão endereçadas atra-
vés dos ciclos de vida dos serviços de TI;
j) preparar apresentações de recomendações aos gerentes sêniores da em-
presa;
k) liderar projetos de melhoria dos serviços de TI;
l) orientar e suportar os profissionais de TI.
94
Agora você já sabe: temos que melhorar sempre. E isso ocorre por meio da
observação daquilo que fazemos hoje em comparação com aquilo que queremos
alcançar. Para melhorar devemos mudar os nossos procedimentos visando atin-
gir as novas metas.
Recapitulando
Neste capítulo você conheceu as melhores práticas que estão vincula-

das ao gerenciamento de serviços de TI, tendo como foco os principais
modelos adotados para a organização de processos nessa área: o ITIL e
o COBIT.
Aprendeu o que é e como fazer um bom planejamento, de forma escrita
e estruturada.
Viu também que o gerenciamento pode se dar de diversas formas: por
demanda, análise financeira, serviço, fornecedores, capacidade de entre-
ga, mudanças, incidentes, eventos, problemas, entre outros.
Por último, teve um breve contato com conceito, processos e responsabi-
lidades referentes à melhoria continuada de serviço.
95
Anotações:
Meio ambiente
Os recursos na área de Suporte de TI são fundamentais para que uma empresa possa funcio-
nar e alcançar seus objetivos de maneira eficiente.
O procedimento para a otimização dos recursos envolve técnicas de planejamento para a
redução da complexidade das atividades, acarretando na redução de erros nas operações e
consequentemente na melhoria do custo-benefício do serviço prestado.
Ao final deste capítulo você será capaz de aplicar os procedimentos de:
a) otimização de recursos físicos;
b) otimização de recursos humanos;
c) otimização de recursos materiais;
d) otimização de recursos financeiros.
Desta forma, um profissional dessa área se torna imprescindível em qualquer empresa, já
que é o responsável pelo não desperdício, pela redução de custos e de tempo na entrega dos
serviços.
98
3.1 OTIMIZAÇÃO DE RECURSOS FÍSICOS MATERIAIS
Dreamstime (2012)
Figura 37 - Otimização de recursos físicos e materiais
Você sabia que toda empresa precisa de recursos para poder funcionar e al-
cançar seus objetivos? Uma vez que a área de Suporte de TI é uma parte da em-
presa, ela também necessita desses recursos.
Mas o que são esses recursos? Segundo Chiavenato (2007), são os meios em-
pregados para possibilitar as ações e operações da empresa e proporcionar efi-
ciência e eficácia no alcance dos resultados desejados. São ativos utilizados para
gerar produtos ou prestar serviços.
São exemplos de recursos na área de Suporte de TI: hardware, software, ferra-
mentas, pessoas e até mesmo o dinheiro disponível para os gastos do dia a dia.
Perceba que os recursos podem ser classificados em função de suas caracterís-
ticas. Dinheiro é considerado recurso financeiro, pessoas são recursos humano,
hardware, software e ferramentas são classificados como recursos físicos mate-
riais, que é o objeto de estudo deste capítulo.
RECURSOS FÍSICOS MATERIAIS
São os recursos necessários para as operações básicas da organização, seja

para prestar serviços especializados, seja para produzir bens ou produtos. Os re-
cursos materiais constituem o próprio espaço físico da empresa, os prédios, edifí-
cios e terrenos, o próprio processo produtivo, a tecnologia que o orienta, os mé-
todos e processos de trabalho voltados para a produção dos bens e dos serviços
realizados pela organização (CHIAVENATO, 2007).
Agora que você já sabe o que são recursos físico materiais, vamos pensar no
que pode ser feito para otimizá-los? Otimização pode ser considerada sinônimo
de “não desperdício”, ou seja, otimizar o uso dos recursos materiais significa que
eles não devem ser desperdiçados, reduzindo os custos na entrega dos serviços.
3 Meio Ambiente
99
OTIMIZAÇÃO DOS RECURSOS FÍSICO MATERIAIS
Para evitar o desperdício, existem várias técnicas e dentre elas podemos citar
o Programa 5S (SILVA, 1996; ABNT/CNI/SEBRAE, 1997), que é focado na organiza-
ção do ambiente de trabalho da organização, de forma que esse ambiente seja
simplificado e o desperdício reduzido, acarretando a melhoria dos aspectos rela-
cionados à qualidade e segurança.
O conjunto de técnicas que compõem os 5S foi desenvolvido no Japão, sen-
do utilizado inicialmente pelas donas de casa japonesas para envolver todos os
membros da família na administração e organização do lar. No final da década de
1960, o Programa 5S passou a ser utilizado pelas indústrias japonesas.
Dentre os principais benefícios dessa metodologia, podemos citar: maior pro-
dutividade pela redução da perda de tempo procurando por objetos, pois só fi-
cam no ambiente de trabalho os itens necessários e ao alcance das mãos; redução
de despesas e melhor aproveitamento de materiais; diminuição do acúmulo ex-
cessivo de materiais, que tende à degeneração; melhoria da qualidade de produ-
tos e serviços; prevenção de acidentes de trabalho; maior satisfação das pessoas
com o ambiente de trabalho; incentivo à criatividade; redução de custos; desen-
volvimento do trabalho em equipe; melhoria das relações humanas.
SEIRI
Senso de
Utilização
SHITSUKE SEITON
Senso de Senso de
5S
Ordem Organização
Denis Pacher (2012)
SEIKETSU SEISO
Senso de Senso de
Higiene Limpeza
Figura 38 - 5S
Cada “S” dos 5S possui um significado que vamos ver a seguir.
a) SEIRI – ORGANIZAÇÃO
É o princípio da organização, que recomenda que, no local de trabalho, apenas
o necessário deve ser mantido. Os itens mais utilizados devem ser mantidos mais
próximos, os menos utilizados mais distantes, e os desnecessários descartados
100
definitivamente. Os principais benefícios deste princípio são: liberação de espaço

físico, liberação de objetos (ferramentas, equipamentos etc.) para outros usuá-
rios, redução de tempo de procura, eliminação de desperdício.
b) SEITON – ORDENAÇÃO
Trata-se da ordenação das coisas necessárias de forma sistemática. Na prática,
significa identificar locais, ordenar objetos de modo que o local de trabalho fique
mais organizado, agradável para o trabalho e, consequentemente, mais produti-
vo. Os principais benefícios deste princípio são: redução do estresse, maior agi-
lidade na localização e acesso aos recursos materiais, bem como controle sobre
seu consumo.
c) SEISO – LIMPEZA
Trata-se da eliminação de sujeiras e limpeza permanente. Essas ações preci-
sam ser encaradas como uma oportunidade de reconhecer o ambiente. A limpeza
também facilita a localização imediata de materiais que não estão no seu devido
lugar. Este princípio pode e deve ser seguido pelos funcionários para que os obje-
tivos do programa 5S sejam alcançados. Os principais benefícios deste princípio
são: prevenção de quebras e de acidentes, melhoria do ambiente de trabalho,
redução/eliminação de desperdícios, mudança no comportamento e nos hábitos.
d) SEIKETSU – PADRONIZAÇÃO (OU NORMALIZAÇÃO)

O objetivo deste princípio é conseguir manter a organização, arrumação e lim-
peza obtidas através dos três primeiros S (Seiri, Seiton, Seiso). Envolve a padroniza-
ção e melhoria contínua das atividades. Essa etapa exige muita disciplina e força
de vontade dos envolvidos, pois caso as mudanças não sejam institucionalizadas,
há risco de que tudo volte a ser como era antes. Os principais benefícios deste
princípio são: equilíbrio físico e mental dos envolvidos, melhoria do ambiente de
trabalho, melhoria de áreas comuns da empresa, melhoria nas condições de se-
gurança, os envolvidos passam a ter maior cuidado com sua aparência (influen-
ciados pelo ambiente), padronização dos processos.
e) SHITSUKE – DISCIPLINA
Finalmente, para manter o real funcionamento dos quatro S anteriores, cum-
prindo fielmente seus princípios, é necessário disciplina, que é o compromisso
pessoal, de cada envolvido, com o cumprimento dos padrões éticos, morais e téc-
nicos definidos pelo Programa 5S. Pode-se dizer que se este princípio está sendo
executado, então todas as etapas do 5S estão se consolidando. O efeito da melho-
ria contínua proporcionará menor desperdício, melhor qualidade e ganhos signi-
ficativos na administração do tempo. Os principais benefícios deste princípio são:
trabalho diário mais agradável, melhoria nas relações humanas, valorização dos
3 Meio Ambiente
101
envolvidos, cumprimento dos procedimentos operacionais e administrativos,

melhor qualidade, produtividade e segurança no trabalho, consolidação do 5S.
O Japão foi reestruturado no período pós-guerra (dé-

VOCÊ cada de 1960) com a ajuda dos princípios do 5S. Isso
ajudou ainda mais a espalhar essa filosofia pelo mundo,
SABIA? inclusive dando origem a outras filosofias, como o
housekeeping (OSADA, 2010), por exemplo.
Neste tópico, você aprendeu sobre recursos físicos materiais. Aprendeu tam-
bém que otimização significa o não desperdício, e que através dos princípios dos
5S podemos otimizar a utilização desses recursos.
3.2 OTIMIZAÇÃO DE RECURSOS FÍSICOS HUMANOS

Dreamstime (2012)
Figura 39 - Otimização de pessoas
Você sabia que a área de Recursos Humanos também faz parte da infraestrutura
necessária para entrega dos serviços de TI? Pense na área de Suporte de TI, por
exemplo. É fácil perceber que não é possível realizar manutenção em hardware sem
uma pessoa qualificada para isso. Nesse caso, qualificada quer dizer treinada, mo-
tivada e com as competências necessárias para realizar essa tarefa: a manutenção.
102
Neste tópico você vai aprender o conceito moderno de recursos humanos, ou

seja, como as pessoas devem ser tratadas pelas organizações.
RECURSOS HUMANOS
São pessoas que ingressam, permanecem e participam da empresa, indepen-

dentemente de seu nível hierárquico ou sua tarefa (CHIAVENATO, 2007).
Podem ser: dirigentes (quando estão distribuídos no nível institucional da
empresa), gerentes, executivos e assessores (quando estão distribuídos no nível
intermediário da empresa) ou supervisores, técnicos e colaboradores internos
(quando estão distribuídos no nível operacional da empresa).
Constituem o único recurso vivo e dinâmico das empresas. Decidem e mani-
pulam os demais recursos (materiais, financeiros etc.) e têm vocação para o cres-
cimento e o desenvolvimento. Além disso, trazem para a empresa, entre outras
coisas, habilidades, julgamentos, atitudes, comportamentos e percepções.
CONCEITO MODERNO DE RECURSOS HUMANOS
Chiavenato (2007) descreve muito bem a evolução do conceito de recursos

humanos nas empresas:
Modernamente, o conceito de recursos humanos está sendo

discutido e modificado. O fato é que pessoas são pessoas e não
recursos empresariais. Tratá-las como recursos – ou como coi-
sas que pertencem à empresa – é uma questão ultrapassada.
Na Era Industrial floresceu o conceito de recursos humanos
pelo qual as pessoas eram consideradas meios de produção da
empresa. Como tal, as pessoas eram tratadas de maneira uni-
forme, homogênea e padronizada por meio da seleção, aloca-
ção em cargos, treinamento, remuneração, benefícios e avalia-
ção do desempenho. A Era da Informação (que vivemos hoje)
incumbiu-se de mudar radicalmente tal situação. Hoje impera a
diversidade: as empresas respeitam plenamente as diferenças
individuais de personalidade, conhecimento, atitude, compor-
tamento entre as pessoas e até mesmo realçam essas diferen-
ças. As pessoas deixaram de ser tratadas como fornecedoras
de mão de obra ou ocupantes de cargos para serem considera-
das fornecedoras de conhecimentos e habilidades intelectuais.
Fala-se hoje não mais em administração de recursos humanos,
3 Meio Ambiente
103
mas em gestão de pessoas, de talentos, de capital humano e de

capital intelectual. As pessoas deixaram de ser meros recursos
para se transformar em competências. Agora o cérebro ficou
mais importante que o músculo. As competências ultrapassam
os recursos em termos de importância estratégica.
Nessa definição de Chiavenato, fica claro que as pessoas não devem ser tra-
tadas simplesmente como recursos, pois o importante são suas competências.
Nesse contexto, surge a ideia da Gestão por Competências, uma das formas de se
otimizar a gestão de recursos humanos nas empresas. Esse tipo de gestão preten-
de agregar valor às pessoas e, consequentemente, à organização.
GESTÃO POR COMPETÊNCIAS
Competências dizem respeito às características dos recursos humanos ne-

cessárias para a obtenção e sustentação da vantagem competitiva da empresa.
Essencialmente, as competências são os atributos básicos dos empregados que
agregam valor à organização (MILKOVICH, G.; BOUDREAU, 2006).
Nesse contexto, pode-se dizer que gerir competências significa investir nas
pessoas de maneira constante e permanente, sendo uma alternativa aos modelos
gerenciais tradicionalmente utilizados pelas organizações. A proposta é orientar
esforços para planejar, captar, desenvolver e avaliar – nos diferentes níveis da or-
ganização – as competências necessárias para alcançar os objetivos da empresa.
A Gestão por Competências se justifica, segundo Chiavenato (2006), porque
ao acrescentar valor às pessoas, as empresas enriquecem seu próprio patrimônio,
melhoram seus processos internos e incrementam qualidade e produtividade às
suas tarefas, produtos e serviços.
GESTÃO POR COMPETÊNCIAS NA PRÁTICA
Na prática, a Gestão por Competências é realizada a partir do levantamento de

competências organizacionais que são críticas para o sucesso empresarial. Poste-
riormente, essas competências gerais são mapeadas em termos de competências
específicas profissionais necessárias para o quadro de funcionários da empresa –
processo chamado de Mapeamento das Competências.
Chiavenato (2010) propõe o mapeamento de quatro tipos de competências:
competências essenciais da organização, funcionais, gerenciais e individuais.
a) Competências essenciais: aquelas que toda organização precisa construir
e possuir para manter vantagem competitiva para as demais;
104
b) Competências funcionais: as que toda unidade organizacional ou depar-

tamento deve construir e possuir para servir de base às competências es-
senciais da organização. Assim, cada uma das diversas áreas da organização
precisa construir competências próprias relacionadas à sua especialização;
c) Competências gerenciais: as que todo gerente ou executivo precisa cons-
truir e possuir para atuar como gestor de pessoas;
d) Competências individuais: as que todo funcionário deve construir e pos-
suir para atuar na organização ou em suas unidades.
Uma vez mapeadas, as competências passam a constituir um repertório de
comportamentos capazes de integrar, mobilizar, transferir conhecimentos, habi-
lidades, julgamentos e atitudes que agreguem valor econômico à organização e
valor social à pessoa.
Chiavenato (2010) afirma que em cada pessoa a compe-

VOCÊ tência é construída tanto a partir de suas características
SABIA? inatas (inerentes ao indivíduo) como adquiridas (obtidas
a partir de suas experiências).
Neste tópico, você aprendeu sobre recursos humanos: os funcionários das em-
presas não devem ser tratados apenas como recursos empresariais, mas como in-
divíduos dotados de competências que geram vantagem competitiva. Também
aprendeu que essas competências precisam ser geridas de forma que se acres-
cente valor às pessoas para melhorar os processos internos da organização e in-
crementar a qualidade e a produtividade às tarefas do dia a dia e aos produtos e
serviços oferecidos.
CASOS E RELATOS
Trabalhando com talentos

Quantos talentos escondidos existem em uma organização? Quantas
pessoas almejam a execução de atividades que lhes sejam mais desa-
fiadoras? A gestão orientada por competências, que você estudou nes-
te tópico, é um importante passo, por exemplo, na gestão dos talentos
de uma organização. Para identificar talentos e posicioná-los no lugar
certo dentro da organização, as empresas procuram formas de medir a
3 Meio Ambiente
105
competência das pessoas em relação às competências requeridas para as

funções que ocupam. Mas o que pode ocorrer se os talentos não estive-
rem posicionados nos lugares certos?
Em empresas pequenas ou no início de organizações, normalmente todos
os funcionários se conhecem, o que facilita a identificação dos talentos.
Em empresas de porte maior diminui a possibilidade de todos se conhe-
cerem. Nesse caso, a empresa deve realizar a sistematização e o alinha-
mento das competências necessárias às estratégias empresariais. Veja a
seguir o caso de uma empresa de telecomunicações que apresentou di-
ficuldade de identificar um talento necessário para determinada função:
Essa empresa de telecomunicações necessitava de um especialista para
suprir a demanda de determinado conhecimento. Buscou essa pessoa
dentro da empresa, mas não a encontrou. Diante disso, recorreu a uma
consultoria, a qual, depois de três meses de pesquisa no mercado, iden-
tificou um especialista exatamente como se desejava e com mais de 20
anos de experiência na área. Na hora da entrevista, a surpresa: o profissio-
nal superespecializado encontrado já trabalhava na empresa e não tinha
sido identificado para a função.
Quantos casos semelhantes a esse podem estar ocorrendo? Quando os
talentos da empresa não são identificados, novos profissionais são con-
tratados. Isso gera despesas com o investimento da nova contratação,
além de promover a desmotivação dos empregados que poderiam aten-
der à demanda, os quais ainda podem ser perdidos para a concorrência.
Fonte: MORCERF et al., 2012.
3.3 OTIMIZAÇÃO DE RECURSOS AMBIENTAIS
O que você faz com a bateria do seu celular quando ela não segura mais carga?
O que você faz com aquele circuito queimado de seu computador? Você descar-
ta. Mas já parou para pensar onde tem descartado esses itens? Agora pense nos
itens descartados pelos laboratórios que prestam serviços na área de Suporte à TI:
imagine a quantidade de lixo tecnológico produzido por eles.
Esse é só um aspecto relacionado ao meio ambiente e à área de Tecnologia da
Informação. Quer dizer: a área de TI também utiliza recursos do meio ambiente,
ou seja, também é poluidora. Então, nosso desafio é: como tornar a área de TI me-
106
nos poluidora? Como otimizar a utilização dos recursos ambientais pela área de
TI? Antes de responder a essas perguntas, entenda o que são recursos ambientais.
RECURSOS AMBIENTAIS
Recursos ambientais (ou naturais) são quaisquer insumos de que os organis-

mos, as populações e os ecossistemas necessitam para sua manutenção (BRAGA,
2005). A princípio, a pergunta seria: há relação disso com Tecnologia da Infor-
mação? Sim, uma vez que existe a necessidade de processos tecnológicos (não
necessariamente processos de TI) para a utilização de recursos.
Por exemplo: houve um tempo em que o magnésio não era considerado um
recurso. A partir do momento em que se desenvolveu tecnologia adequada para
sua utilização em ligas metálicas para aviões, o magnésio passou a ser útil. Em
outras palavras: algo é considerado um recurso quando sua exploração torna-se
economicamente viável.
Diante disso, observe que a exploração, o processamento e a utilização de
recursos naturais tendem a causar danos ao meio ambiente – que, por sua vez,
representa a fonte desses recursos.
Portanto, como minimizar o impacto da utilização dos recursos naturais no
meio ambiente? Atualmente existe um conceito bastante difundido entre a so-
ciedade: o desenvolvimento sustentável.
DESENVOLVIMENTO SUSTENTÁVEL (SUSTENTABILIDADE)
Valle (2004) descreve o conceito de desenvolvimento sustentável (ou susten-

tabilidade) como a capacidade de atender às necessidades da geração atual
sem comprometer o direito de as gerações futuras atenderem às suas próprias
necessidades. Nessa definição há dois conceitos envolvidos: o primeiro é o con-
ceito de necessidades, que podem variar de sociedade para sociedade, mas que
devem ser satisfeitas para assegurar as condições essenciais de vida a todos, in-
distintamente; o segundo é o de limitação, que reconhece a necessidade de a tec-
nologia desenvolver soluções que conservem os recursos limitados atualmente
disponíveis e que permitam renová-los à medida que sejam necessários às futuras
gerações. Assim, o desenvolvimento sustentável deve assegurar as necessidades
econômicas, sociais e ambientais sem comprometer o futuro de nenhuma delas.
Mas o que a área de TI tem feito em favor do desenvolvimento sustentável? A
Tecnologia da Informação Verde (TI Verde ou Green IT) é um novo conceito que
pode favorecer o desenvolvimento sustentável da área de TI.
3 Meio Ambiente
107
TI VERDE
Trata-se de uma tendência mundial voltada ao tratamento do impacto dos

recursos tecnológicos no meio ambiente. A TI Verde preocupa-se com a utilização
mais eficiente de energia, recursos e insumos na produção de tecnologia, e com
o uso de matérias-primas e substâncias menos tóxicas na fabricação de compo-
nentes tecnológicos. Além disso, estuda o desenvolvimento de equipamentos
que consumam menos energia, que não agridam o meio ambiente durante sua
operação e cujo descarte permita a reutilização e a reciclagem a fim de minimizar
os impactos ao meio ambiente.
Agora você pode perceber claramente que tornar a TI sustentável é o desafio
proposto a nós. A seguir, você verá como isso pode ser feito.
COMO TORNAR A ÁREA DE TI SUSTENTÁVEL?
Lisboa (2009), no artigo “Como adaptar sua empresa ao conceito de TI sus-

tentável”, descreve um conjunto de etapas pelas quais os gestores de TI devem
passar para alcançar a sustentabilidade:
a) Desenvolvimento interno: o gestor de TI de uma empresa que desenvolve
tecnologias internamente deve esclarecer aos colaboradores que tudo de-
verá ser estruturado de forma sustentável, ou seja: os softwares e aplicações
precisam ser projetados sem a utilização de componentes tóxicos e ser viá-
veis o maior tempo possível. Além disso, o gestor deve analisar a integração
de qualquer nova aplicação ou hardware ao atual ambiente, com o intuito de
evitar investimentos desnecessários;
b) Uso consciente: mais do que exigir o desenvolvimento verde das tecnolo-
gias, é papel do gestor de TI conscientizar os funcionários sobre formas de
atuação mais sustentáveis, que incluem práticas para a redução do consu-
mo energético (como a exigência de que todos desliguem as máquinas por
completo antes de ir embora ao final do dia) e o compartilhamento de re-
cursos (sejam eles tecnológicos ou referentes à rotina corporativa, como os
materiais de escritório, por exemplo);
c) Reciclagem: todo gestor deve desenvolver políticas para que o lixo produzi-
do pelo seu departamento seja reciclado e reaproveitado. No caso da TI, essa
situação é ainda mais crítica, visto que, além de componentes eletrônicos, os
líderes devem criar processos para o descarte e armazenamento de máqui-
nas e dados;
d) Contratação responsável: as empresas estão inseridas em uma cadeia que
inclui fornecedores, clientes e a sociedade. Assim como já feito por algumas
108
companhias estrangeiras, as organizações precisam exigir que seus fornece-

dores adotem políticas sustentáveis. Embora o apelo financeiro para a com-
pra de suprimentos mais baratos possa pesar nos orçamentos, o gestor deve
sugerir ao seus superiores a adoção de tecnologias verdes, atitude que tem
a capacidade de gerar grande economia a longo prazo;
e) Proliferação: mais importante até do que todas as etapas anteriores, o líder
tem de agir de acordo com o seu discurso. Nesse caso, isso implica a ado-
ção de posturas sustentáveis na vida pessoal e agir como um proliferador da
consciência verde na empresa e na sociedade.
Segundo um cálculo feito pelo físico americano Alex

VOCÊ Wissner-Gross, da Universidade de Harvard, fazer uma
SABIA? pesquisa no Google gera 7 gramas de gás carbônico na
atmosfera. Isso equivale a ferver um bule de chá.
Neste tópico, você aprendeu sobre recursos ambientais e viu os conceitos de

desenvolvimento sustentável e TI Verde, além da relação entre ambos. Depois
você aprendeu algumas atitudes que as empresas podem tomar para tornar a TI
sustentável.
3.4 OTIMIZAÇÃO DE RECURSOS FINANCEIROS
Você já sabe que é importante que a área de Suporte de TI entregue serviços

de qualidade, ou seja, que estejam de acordo com o que o cliente espera. Mas isso
deve ser feito a qualquer custo?
É fácil perceber que não. Tanto os processos da área de Suporte como todos
os outros processos de uma empresa, sejam eles da área de TI ou não, devem ser
organizados de tal forma que os serviços sejam entregues de forma econômica,
sem desperdícios ou gastos exagerados. Mas como fazer isso?
Um dos caminhos é o planejamento financeiro. Na visão de Gitman (1997),
por exemplo, as empresas utilizam-se do planejamento financeiro para direcionar
suas ações com vistas a atingir seus objetivos imediatos e de longo prazo onde
um grande montante de recursos está envolvido. Mas como otimizar o gerencia-
mento dos recursos financeiros? Antes de pensar nisso, compreenda primeiro o
que são recursos financeiros.
3 Meio Ambiente
109
RECURSOS FINANCEIROS
Segundo Chiavenato (2007),
recursos financeiros são recursos relacionados com o dinhei-

ro sob a forma de capital, fluxo de caixa (entradas e saídas),
empréstimos, financiamento, créditos etc., em disponibilidade
imediata ou futura para fazer frente aos compromissos da em-
presa. Incluem também a receita decorrente das operações da
empresa, investimento de terceiros e toda forma de numerário
que transite pela tesouraria ou pelo caixa da empresa.
Os recursos financeiros garantem os meios para aquisição ou

obtenção dos demais recursos (físicos, materiais, humanos, ad-
ministrativos etc.) necessários à empresa. Até certo ponto, são
os recursos financeiros que definem boa parte da eficácia da
empresa no alcance de seus objetivos, em razão de possibilita-
rem à empresa adquirir os recursos necessários para as opera-
ções dentro de um volume adequado.
É muito comum traduzir-se o desempenho da empresa pela

linguagem financeira, em termos de lucros, em valores mone-
tários ou em termos de facilidade com que suas ações podem
ser comercializadas (transformadas em dinheiro). Também
é muito comum o dimensionamento dos recursos físicos ou
materiais em termos financeiros, como o valor de máquinas e
equipamentos da empresa, valor do estoque de matérias-pri-
mas ou de produtos acabados, entre outros, ou o próprio valor
patrimonial ou valor de mercado da empresa.
Analisando essa definição de Chiavenato, fica claro que os recursos financei-

ros são vitais para a empresa, logo precisam ser gerenciados de forma adequada.
Uma das formas é a técnica conhecida com Orçamento Base Zero (OBZ).
ORÇAMENTO BASE ZERO (OBZ)
Antes de entender o conceito de Orçamento Base Zero, entenda o que é um

orçamento e qual é sua relação com o planejamento financeiro.
Segundo o dicionário Aurélio (FERREIRA, 2004), orçamento é o ato ou efeito
de orçar, envolve avaliação, cálculo de receitas e despesas. Já na definição de
Gomes, orçamento é o balanço prévio das receitas (o que a empresa recebe) e
110
despesas (o que a empresa gasta) da gestão financeira. Como tal, deve apresen-
tá-las nas mais minuciosas discriminações; as despesas, na expressão das neces-
sidades dos serviços organizados; as receitas, em suas fontes originais e nos seus
custos de produção.
Gomes também afirma que a elaboração do orçamento em um ambiente em-
presarial, juntamente com o planejamento financeiro, são atividades muito im-
portantes, ou seja: para que o orçamento seja considerado viável às estratégias
da empresa, é necessário um planejamento financeiro feito de modo a se poder
monitorar sua situação financeira, avaliar a necessidade de aumentar ou reduzir
sua capacidade produtiva e determinar os aumentos ou reduções dos financia-
mentos requeridos.
A utilização das técnicas de OBZ se justifica, segundo Gomes, no seguinte con-
texto: para alocar efetivamente recursos limitados. Um processo orçamentário
tem que dar, ao mesmo tempo, respostas às perguntas: onde e como gastar o
dinheiro da empresa de forma eficaz e quanto gastar.
Nos orçamentos tradicionais, geralmente não há metas bem definidas e o en-
volvimento na elaboração do orçamento restringe-se apenas à alta administra-
ção, ou seja, não há uma participação efetiva dos funcionários da empresa. Essas
projeções sempre são feitas considerando-se os orçamentos dos anos anteriores
e isso normalmente gera como resultado as mesmas falhas e perpetuação dos
erros. Esse tipo de técnica considera então os dados históricos da empresa e pode
ser chamado de Orçamento Base Histórica (OBH).
Já no OBZ, os dados históricos não são considerados. Essa é sua principal di-
ferença em relação a outros tipos de orçamento. Isso é importante porque exige
que cada administrador justifique detalhadamente todas as dotações solicitadas
em seu orçamento, cabendo-lhe justificar por que deve gastar dinheiro. Cada ad-
ministrador é obrigado a preparar um “pacote de decisão” para cada atividade ou
operação, e esse pacote inclui uma análise de custo, finalidade, alternativas, me-
didas de desempenho, consequências de não executar a atividade e benefícios.
CONCEITO DE OBZ
A análise de alternativas exigida pelo OBZ introduz um conceito novo nas téc-
nicas típicas de orçamento, pois os gestores têm primeiro que identificar diferen-
tes maneiras de executar cada atividade e essa análise obriga a todos avaliarem
um nível de despesa mais baixo que seu nível atual de operação.
É fácil perceber então que esse tipo de técnica tende a ser mais eficiente, con-
siderando a economia que ele pode promover. Logo, a técnica OBZ torna-se um
3 Meio Ambiente
111
instrumento que promove a redução dos gastos e das despesas, gerando aumen-
to do ganho financeiro da empresa.
Apesar dos avanços tecnológicos atuais, como a utiliza-

VOCÊ ção de softwares financeiros ou planilhas eletrônicas, o
planejamento financeiro não deve ser mecanizado, mas
SABIA? profundamente analisado e discutido entre os executi-
vos da empresa.
Neste tópico, você aprendeu mais sobre planejamento financeiro e elabora-

ção de orçamentos. Aprendeu ainda que existe uma técnica, conhecida como Or-
çamento Base Zero (OBZ), que auxilia na otimização do planejamento financeiro.
Recapitulando
Neste capítulo você estudou sobre procedimentos que visam à otimiza-

ção de recursos físicos, humanos, materiais e financeiros.
Vimos que a otimização de recursos pode ser considerada sinônimo de
“não desperdício”, significando a redução de custos e o crescimento de
habilidades, julgamentos, atitudes, comportamentos e percepções mais
sustentáveis.
Como prática de boas maneiras, você foi apresentado ao método 5S,
cujos principais benefícios é trazer maior produtividade, redução de des-
pesas, organização do ambiente de trabalho e consequente prevenção
de acidentes de trabalho, além de melhoria nas relações humanas.
Gestão de projetos
No dia a dia da área de TI, somos responsáveis pela entrega de produtos ou serviços.
Um Projeto é uma atividade de natureza temporária, com data de início e de término bem
definidas que cria um produto ou serviço único e termina quando suas metas e objetivos foram
atingidos e aprovados pelas partes interessadas.
Você verá que para realizar um processo bem definido de gerência de projetos é necessário
registrar e classificar as requisições dos usuários levando em conta seu impacto e urgência;
restabelecer o mais rápido possível os serviços com o mínimo de impacto; manter os usuários
informados sobre o andamento de suas solicitações e, então, fechar as solicitações de serviço.
Ao final destes estudos você será capaz de:
a) definir o que é projeto e gestão de projetos;
b) conhecer as habilidades necessárias de um gerente de projetos e como funciona esta
gestão no contexto do ambiente de serviços de suporte de TI;
c) conhecer grupos de processos e as áreas do gerenciamento de projetos;
d) definir os gerenciamentos de integração, de escopo, de tempo, dos custos, das comunica-
ções, dos riscos, dos recursos humanos e da qualidade dos projetos;
e) definir as estruturas organizacionais;
f) definir a viabilidade dos projetos e como ocorre o encerramento destes.
Assim, a gerência de projetos está sendo vista como um diferencial competitivo para as or-
ganizações, colocando-as em posição de destaque frente ao mercado, pois ajuda a estabelecer
o controle do ambiente de uma empresa.
114
4.1 O QUE É UM PROJETO
Denis Pacher (2012)

Figura 40 - Alvo
No dia a dia da área de TI, somos responsáveis pela entrega de produtos ou

serviços. A área de Suporte de TI, por exemplo, entrega o serviço de manutenção
em hardware, uma das atividades fim dessa área, ou seja: é um serviço realizado
no dia a dia pela área, sua razão de existir. Por essa característica de atividade
fim, esse é um serviço chamado de operação contínua, porque envolve atividades
executadas continuamente pelas empresas, como, por exemplo, o atendimento
ao cliente, o gerenciamento financeiro ou fechamento de folha de pagamento.
Entretanto, existem atividades que não são operações contínuas: o lançamen-
to de um produto, a construção de uma obra ou a implantação de uma central de
serviços, por exemplo. Note a diferença básica entre essas atividades e as opera-
ções contínuas: essas têm início e término bem definidos.
CONCEITO DE PROJETO
Segundo Heldman (2009), projeto é uma atividade de natureza temporária,

com data de início e data de término bem definidas; cria um produto ou serviço
único e termina quando suas metas e objetivos foram atingidos e aprovados pe-
las partes interessadas.
Os projetos existem para viabilizar um produto, serviço ou resultado até então
inexistente, inclusive produtos tangíveis e serviços como consultorias e funções
de negócio que apoiam a empresa.
Os projetos são bem-sucedidos quando atendem às expectativas das partes
interessadas (ou mesmo quando as ultrapassam), mas podem ser finalizados caso
4 Gestão de projetos
115
se chegue à conclusão de que não é possível cumprir suas metas e objetivos ou

quando seu produto, serviço ou resultado não é mais necessário.
EXEMPLO DE PROJETO
Um bom exemplo de projeto na área de TI é a criação de uma central de servi-

ços, cujo objetivo é ser o ponto único de contato entre os usuários (que utilizam
os serviços) e a área de TI (que fornece os serviços). Assim, a implantação de uma
central de serviços é um projeto. Por isso, você poderia ser contratado por uma
empresa qualquer para montar e estruturar sua central de serviços, por exemplo.
O produto a ser entregue é a própria central de serviços em funcionamento – sua
meta é estruturá-la e colocá-la em funcionamento.
Nesse momento, como validar o produto entregue? Como saber se os objeti-
vos foram alcançados? Como saber se as partes estão satisfeitas? No caso da cen-
tral de serviços é necessário verificar se ela cumpre sua missão, que, em resumo,
é: registrar e classificar as requisições dos usuários levando em conta seu impacto
e urgência; restabelecer o mais rápido possível os serviços com o mínimo de im-
pacto; manter os usuários informados sobre o andamento de suas solicitações;
fechar as solicitações de serviço.
Perceba agora que todas essas atividades de responsabilidade da central de
serviços passam a representar operações contínuas: são atividades repetitivas,
que envolvem trabalho contínuo, sem data de término, conduzidas sempre pelos
mesmos processos e produzindo sempre os mesmos resultados. Em outras pala-
vras, são as funções do dia a dia de uma central de serviços.
Heldman (2009) afirma que, mesmo quando todos

VOCÊ os objetivos de um projeto são alcançados, se suas
principais partes interessadas não ficarem satisfeitas,
SABIA? ninguém estará satisfeito, ou seja, o projeto não foi um
sucesso.
Neste tópico, você viu o conceito de projeto e de operação contínua. Depois,

você teve um exemplo de projeto e agora já é capaz de definir um.
116
4.2 O QUE É GERÊNCIA DE PROJETOS
Vamos começar com um exemplo. Você tem um projeto em suas mãos: implan-
tar a Central de Serviços na empresa XYZ, com um prazo limitado e bem definido,
dentro do qual você tem metas a cumprir – atendendo ou excedendo as expecta-
tivas dos diretores da empresa. Então, como fazer isso de maneira eficaz, eficiente,
dentro do prazo e do custo planejados? Você deve gerenciar o seu projeto.
CONCEITO DE GERÊNCIA DE PROJETOS
De acordo com Heldman (2009), gerência de projetos abrange uma série de

ferramentas e técnicas para descrever, organizar e monitorar o andamento das
atividades de um projeto.
Assim, os gerentes de projeto são as pessoas responsáveis pela administração
dos processos envolvidos em um projeto e pela aplicação das ferramentas e téc-
nicas necessárias ao cumprimento das atividades desse projeto.
GERÊNCIA DE PROJETOS SEGUNDO O PMBOK
O PMBOK (Project Management Body of Knowledge – Corpo de Conhecimento

em Gerenciamento de Projetos) é um conjunto de práticas em gerenciamento de
projetos publicado pelo PMI (Project Management Institute – Instituto de Geren-
ciamento de Projetos). Ele constitui a base de conhecimento em gerenciamento
de projetos mais utilizada no mundo por ser o guia (livro) onde essa base está
registrada (disponível em <http://www.pmi.org>).
Segundo o PMBOK, o gerenciamento de projetos envolve a aplicação de co-
nhecimentos, habilidades, ferramentas e técnicas durante o curso do projeto para
alcançar seu objetivo. O gerente do projeto tem a responsabilidade de assegurar
que tais técnicas sejam utilizadas e seguidas.
PROGRAMAS E PORTFÓLIOS DE PROJETOS
Programas são grupos de projetos relacionados e gerenciados pelas mesmas

técnicas. Sua importância se dá pelo fato de permitirem o gerenciamento coletivo
e o consequente compartilhamento de recursos. Por exemplo, a implantação da
central de serviços poderia ser considerada um programa se fosse subdividida em
vários subprojetos (serviços de rede, serviços de software, hardware etc.). Cada
um desses subprojetos teria seu próprio gerente de projetos, que se reportaria ao
gerente do programa.
117
Já os portfólios são coleções de programas e projetos que apoiam metas ou

objetivos de negócio específicos. O gerenciamento de portfólio deve abranger
então o gerenciamento de coleções de programas, projetos e até mesmo outros
portfólios, monitorando-os para que se mantenham alinhados aos seus objetivos.
É importante ressaltar que programas e projetos dentro de um mesmo portfó-
lio não estão necessariamente relacionados entre si. Entretanto, quaisquer pro-
gramas ou projetos contidos em um mesmo portfólio devem atender aos seus
objetivos estratégicos, que por sua vez devem estar alinhados ao objetivo estra-
tégico da empresa.
Heldman (2009) conceitua Escritório de Gerenciamento de

SAIBA Projetos (PMO – Project Management Office). Trata-se de uma
MAIS unidade organizacional centralizada que supervisiona o ge-
renciamento de projetos e programas de toda organização.
Neste tópico, você aprendeu o conceito de gerenciamento de projetos, de

programas e portfólios e conheceu o PMBOK, ao qual você pode recorrer para
aprender mais sobre o gerenciamento de projetos.
4.3 HABILIDADES NECESSSÁRIAS PARA UM GERENTE DE PROJETOS

Dreamstime (2012)
Figura 41 - Habilidades
Imagine que você seja o técnico mais competente da área de Suporte de TI da

empresa em que trabalha: possui grande competência técnica, fez vários cursos
de atualização e realiza seu trabalho dentro do prazo, com o menor custo possí-
vel. Certo dia surge um grande projeto a ser executado: a implantação e configu-
ração da infraestrutura de hardware de uma filial da empresa. Para cumprir essa
tarefa, seria necessário formar uma equipe de 20 técnicos de hardware trabalhan-
118
do oito horas por dia durante dois meses. O gerente da área de Suporte de TI deve
escolher a pessoa que gerenciará o projeto, e você, ciente de sua competência
técnica, candidata-se ao posto.
Contudo, o fato de ser o melhor técnico não garante que você seja a pessoa
mais qualificada para gerenciar essa equipe – isso vai depender da demonstração
de outras habilidades.
O PERFIL DO GERENTE DE PROJETOS
Heldman (2009) afirma que o gerente de projetos deve ser um profissional

generalista, ou seja, que possua uma série de competências, pois sua especialida-
de seria resolver problemas em variados campos. Ele pode ter aptidões técnicas,
mas isso não é requisito obrigatório: sua equipe de projeto, sim, deve contar com
técnicos especializados, aos quais o gerente recorrerá para as soluções técnicas.
Note que não basta ter alto nível de conhecimento técnico para ser um bom
gerente de projetos – esse profissional deve ter outras competências: habilidades
organizacionais e de planejamento; habilidades para elaboração de orçamentos;
para resolução de conflitos; de negociação e influência; de liderança; e para for-
mação e motivação de equipes.
a) Habilidades organizacionais e de planejamento
O gerente de projetos é responsável pela realização de tarefas organizacionais
como: rastrear a documentação do projeto, preencher memorandos e relatórios,
realizar cotações junto a fornecedores, elaborar contratos, organizar reuniões,
reunir equipes etc.
No entender de Heldman (2009), “as habilidades de planejamento caminham
de mãos dadas com as aptidões organizacionais. A combinação desses dois talen-
tos com excelentes habilidades de comunicação é quase a garantia de sucesso no
gerenciamento de projetos”.
b) Habilidades para elaboração de orçamentos
Para a elaboração e administração de orçamentos – importantes para a reali-
zação de estimativas dos custos do projeto –, um gerente de projetos precisa ter
conhecimentos, mesmo que básicos, em finanças e contabilidade.
c) Habilidades para resolução de conflitos
O gerente de projetos deve ser capaz de determinar o melhor caminho a ser
seguido para a resolução de um problema. Isso requer a capacidade de identificar
a causa do problema e sua possível solução.
119
d) Habilidades de negociação e influência

São habilidades necessárias para resolução de conflitos. Quase tudo em um
projeto precisa ser negociado: contratos, orçamentos, convênios etc., de modo
que a influência é a principal arma de convencimento em um processo de nego-
ciação.
e) Habilidades de liderança
Líderes são pessoas que expressam sua visão, obtêm consenso quanto às me-
tas estratégicas, estabelecem direções e inspiram e motivam os demais.
f) Habilidades para formação e motivação de equipes
Como os gerentes de projetos dependem da capacidade técnica de sua equi-
pe, então eles devem ter a habilidade de escolher as pessoas certas para a execu-
ção das funções.
Neste tópico, você aprendeu que não basta ser um bom técnico para ser um
bom gerente de projetos, pois suas habilidades vão muito além do conhecimento
técnico. Será que você estará preparado para isso?
4.4 GESTÃO DE PROJETOS NO CONTEXTO DO AMBIENTE DE SERVIÇOS

DE SUPORTE DE TI
Independentemente do projeto, para ser um bom gerente de projetos são ne-

cessárias diversas habilidades: organizacionais, de planejamento, elaboração de
orçamentos, resolução de conflitos, negociação e influência, liderança, formação
e motivação de equipes, conforme você viu no tópico anterior. Então você já sabe
que ter as habilidades citadas não garante a capacidade de gerenciar qualquer
projeto em qualquer área do conhecimento.
Vamos pensar a respeito: você é um profissional da área de TI, mais especifi-
camente da área de Suporte de TI. Então talvez você não seja a pessoa certa para
gerenciar o projeto de construção de um edifício, ou a organização de um grande
evento, como um show, por exemplo. Isso ocorre porque projetos de áreas di-
ferentes requerem conhecimentos e capacidades técnicas diferentes. O conhe-
cimento necessário para gerenciar um projeto de engenharia civil é totalmente
diferente do conhecimento necessário para gerenciar um projeto na área de TI.
Mas o que difere um projeto da área de Suporte de TI de outros tipos de projeto?
120
O AMBIENTE DE SUPORTE DE TI
Em um ambiente de suporte de TI, você lida basicamente com hardware, sof-

tware e suporte a usuários. Na área de hardware, o trabalho envolve, entre outras
coisas, montagem e manutenção de computadores, monitores, impressoras etc.
Já a área de software envolve a instalação e a configuração dos softwares. Suporte
a usuários é o atendimento a dúvidas, o treinamento etc. Nesse ambiente, qual
seria a demanda por projetos?
PROJETOS DA ÁREA DE SUPORTE DE TI
Antes de pensar nos projetos que podem ser demandados pela área de Supor-
te de TI, é importante observar que o trabalho rotineiro da área não é projeto, mas
operação contínua. Mesmo que as solicitações dos usuários tenham prazos bem
definidos, serviços como pequenas manutenções em hardware, instalações de sof-
tware ou orientação a um usuário específico não são, de forma nenhuma, projetos.
Apesar disso, algumas solicitações de usuários podem dar origem a projetos.
Geralmente são solicitações mais complexas, que demandam tempo relativamen-
te longo para atendimento, requerem várias pessoas, têm custo elevado e depen-
dem de fornecedores ou da compra de insumos. Veja a seguir alguns exemplos:
a) Projetos na área de hardware
a) Troca de toda infraestrutura de hardware da empresa.
b) Aquisição, configuração e instalação de um grande número de compu-
tadores.
c) Montagem e configuração de toda infraestrutura de rede da empresa.
b) Projetos na área de software
a) Aquisição de um novo software de gestão.
b) Desenvolvimento de um novo software para empresa.
c) Troca de versão de todos os sistemas operacionais.
c) Projeto envolvendo suporte a usuários
a) Treinamento de vários funcionários de uma única vez para a utilização
dos softwares da empresa.
Neste tópico você aprendeu que projetos na área de Suporte de TI são diferen-
tes de projetos em outras áreas, e que esses projetos não podem ser gerenciados
por qualquer pessoa, pois é necessário ter conhecimento técnico da área. Isso,
associado a um conjunto de habilidades, torna um profissional mais completo.
121
Você pode obter mais informações sobre gerenciamento de projetos na área

de TI no livro Gerenciamento de projetos: de Tecnologia da Informação, de Fábio
Marconi Vieira (2003).
4.5 GRUPOS DE PROCESSOS DO GERENCIAMENTO DE PROJETOS
Todo projeto tem um fim, diferentemente das tarefas rotineiras, aquelas rea-
lizadas no dia a dia das empresas. Isso significa que o projeto termina, em algum
momento, e seu resultado pode estar de acordo ou não com o que você planejou.
Entre o começo e o término do projeto ocorre uma série de atividades, chamadas
de Grupo de Atividades do Gerenciamento de Projetos. Todo projeto tem o mesmo
grupo de processos, sendo que há cinco grupos, os quais você conhecerá a seguir.
GRUPOS DE PROCESSOS
Segundo o PMBOK (disponível em <http://www.pmi.org>), há cinco grupos

de processos: iniciação; planejamento; execução; monitoramento e controle; e
encerramento. Cada um desses grupos é composto por um conjunto de ativida-
des. O processo de iniciação, por exemplo, é composto da atividade de elabora-
ção do Termo de Abertura do Projeto e Identificação das Partes Interessadas.
Heldman (2009) alerta para que não se confundam fases e ciclos de vida do
projeto com grupos de processos. Fases e ciclos de vida do projeto descrevem de
que forma será concluído o trabalho associado ao produto do projeto; grupos de
processos organizam e descrevem de que forma serão conduzidas as atividades
para que os requisitos do projeto sejam atendidos. Por exemplo: os ciclos de vida
de um projeto de construção de uma casa podem passar por fases como: estudo
de viabilidade, projeto, construção, inspeção e vendas. Já os grupos de processos
(iniciação, planejamento, execução, monitoramento e controle e encerramento)
são sempre os mesmos, independentemente do tipo de projeto.
A seguir, veja mais sobre os cinco grupos de processos:
a) Iniciação
Conforme o nome já diz, ocorre no início do projeto, ou em cada fase de gran-
des projetos. Esse é o momento em que são alocados os recursos necessários ao
projeto ou fase. Como saída desse processo são gerados o Termo de Abertura do
Projeto e a Identificação das Partes Interessadas. Esses documentos servem como
insumo para o próximo processo, o planejamento.
122
b) Planejamento
Esse é o momento de formular e revisar as metas e objetivos do projeto e de-
linear os planos que serão usados para cumprir os propósitos do projeto. É hora
de especificar os requisitos do projeto e as partes interessadas. Uma vez que cada
projeto é único (suas fases e ciclos de vida nunca foram executadas antes), o pla-
nejamento deve envolver pelo menos: orçamento, definição das atividades do
projeto, planejamento do escopo, desenvolvimento do cronograma, identifica-
ção dos riscos, recrutamento da equipe e planejamento das aquisições. O resulta-
do dessa fase é a geração do plano de projeto.
c) Execução
Compreende a execução, ou seja, a realização do que foi planejado no plano
do projeto, e o ponto-chave é o cumprimento dos cronogramas. Essa fase costu-
ma ser a que tem os custos mais altos, pois é o momento em que os recursos são
gastos. O gerente responsável pela execução do projeto deve manter a execução
alinhada ao que foi planejado.
d) Monitoramento e controle
Nesse momento são feitas e analisadas as avaliações de desempenho para
averiguar se o projeto está sendo seguido conforme o plano. Se houver desvios,
ações corretivas devem ser aplicadas com o objetivo de manter a execução ali-
nhada ao plano do projeto.
O monitoramento e controle é utilizado para monitorar o progresso do traba-
lho executado e identificar problemas e variações dentro de um grupo de proces-
sos. Esse ciclo pode exigir novas passagens pelo processo de planejamento (2),
até que os objetivos em pauta sejam executados.
e) Encerramento
É quando há o término formal e ordenado das atividades de um projeto. Assim
que os objetivos são alcançados, a maioria dos integrantes do projeto se prepara
para migrar para o projeto seguinte. Nesse momento, todas as informações refe-
rentes ao projeto são reunidas e armazenadas para futura referência. Para finali-
zar formalmente o projeto, deve-se obter sua aceitação e aprovação formal.
RELAÇÃO ENTRE OS GRUPOS DE PROCESSOS
Não devemos pensar nos cinco grupos de processos como atividades isoladas.
Ao contrário, esses grupos interagem e se sobrepõem. Além disso, suas ativida-
des devem ser revisadas várias vezes ao longo do ciclo de vida do projeto. Cada
revisão é chamada de iteração.
123
Gerente e equipe determinam que fases, em cada grupo

VOCÊ de processo, são mais apropriadas para determinado
projeto. Esse procedimento é denominado adaptação
SABIA? (tailoring) e leva em consideração fatores como tama-
nho e complexidade do projeto.
Neste tópico, você aprendeu sobre os cinco grupos de processos do gerencia-

mento de projetos, conheceu seus objetivos e percebeu que eles não são execu-
tados de maneira isolada.
4.6 ÁREAS DE CONHECIMENTO DO GERENCIAMENTO DE PROJETOS
Integração
po
Cu
Tem
sto
Qualidade
s
çõ e s
Ris
ica
co
n
Escopo
u
m
Co
Recursos Aquisições
Humanos
Figura 42 - Áreas de conhecimento do gerenciamento de projetos
Fonte: http://www.mhavila.com.br/topicos/gestao/img/pmbok_areas.png
Você já sabe que os projetos possuem cinco grupos de processos de gerencia-

mento: iniciação; planejamento; execução; monitoramento e controle; e encerra-
mento. Agora, saiba que cada um desses grupos de processos possui um conjun-
to de outros processos, que são utilizados durante todo o ciclo de vida do projeto.
O PMBOK (<www.pmi.org>) agrupa-os em nove categorias, conhecidas como
áreas de conhecimento do gerenciamento de projetos. A seguir, você poderá
aprender mais sobre essas nove áreas de conhecimento.
ÁREAS DE CONHECIMENTO
As nove áreas de conhecimento do gerenciamento de projetos são: geren-

ciamento de integração, gerenciamento de escopo, gerenciamento de tempo,
124
gerenciamento de custo, gerenciamento de comunicação, gerenciamento de

aquisições, gerenciamento de risco, gerenciamento de recursos humanos e ge-
renciamento de qualidade.
Veja como Heldman (2009) diferencia áreas de conhecimento e grupos de pro-
cessos: enquanto as áreas de conhecimento agrupam os processos por pontos
em comum, os grupos de processos são mais ou menos a ordem em que você
executa os processos de gerenciamento de projetos.
A seguir, conheça melhor cada uma das nove áreas de conhecimento através
das definições de Heldman (2009).
a) Gerenciamento de integração do projeto
Trata da coordenação de todos os aspectos do plano do projeto por meio de
um elevado nível de interação. Essa área identifica e define o trabalho do projeto
e combina, unifica e integra os processos apropriados. Além disso, preocupa-se
em atender satisfatoriamente aos requisitos do cliente e das partes interessadas
e gerenciar suas expectativas.
b) Gerenciamento do escopo do projeto
Trata da definição de todo o trabalho do projeto e apenas do trabalho neces-
sário para produzir com sucesso os objetivos do projeto. As atividades (coleta de
requisitos, definição do escopo, criação da estrutura analítica do projeto, verifica-
ção do escopo, controle do escopo) que compõem este processo são altamente
interativas. Elas definem e controlam o que faz ou não parte do projeto e ocorrem
pelo menos uma vez durante o ciclo de vida do projeto (com frequência, ocorrem
várias vezes).
VOCÊ Escopo é o objetivo que se pretende atingir. É o termo

SABIA? utilizado para definição dos limites de um projeto.
c) Gerenciamento do tempo do projeto

Essa área tem como objetivo estimar a duração das atividades do plano do
projeto, elaborar o cronograma do projeto e monitorar e controlar desvios do
cronograma. Em termos gerais, essa área trata da conclusão do projeto em tem-
po hábil. O gerenciamento do tempo é um aspecto importante do gerenciamen-
to de projetos, pois envolve a manutenção das atividades do projeto em dia e a
contraposição dessas atividades ao plano de projeto para garantir que ele seja
concluído dentro do prazo.
125
d) Gerenciamento dos custos do projeto

As atividades dessa área definem estimativas de custos e recursos e controlam
tais custos para garantir que o projeto permaneça dentro do orçamento aprova-
do. Nessa área de conhecimento são utilizadas duas técnicas: a determinação dos
custos do ciclo de vida; e a engenharia de valor. A primeira considera um grupo
de custos em conjunto (como aquisição, operações, descarte etc.) ao comparar
ou decidir entre alternativas. Já a engenharia de valor ajuda a aprimorar a utiliza-
ção de cronogramas, lucros, qualidade e recursos e a otimizar os custos do ciclo
de vida.
e) Gerenciamento das comunicações do projeto
Os processos dessa área estão relacionados com as habilidades gerais de co-
municação, mas vão muito além da troca de informações. As competências de
comunicação são as habilidades gerais de gerenciamento que o gerente de pro-
jeto usa no dia a dia. Os processos aí envolvidos visam a garantir que todas as
informações do projeto, inclusive planos de projeto, avaliações de risco, notas
tomadas em reuniões etc., sejam coletadas, documentadas, arquivadas e descar-
tadas quando apropriado. Asseguram também a distribuição e o compartilha-
mento das informações com as partes interessadas, a gerência e os integrantes
do projeto nos momentos adequados. Ao término do projeto, as informações são
arquivadas e usadas como referência para os próximos projetos.
f) Gerenciamento das aquisições do projeto
Abrange os processos relacionados à compra de bens ou serviços de fornece-
dores externos e empresas contratadas.
g) Gerenciamento dos riscos do projeto
Riscos incluem tanto ameaças como oportunidades dentro do projeto. Os pro-
cessos dessa área referem-se à identificação, análise e planejamento de riscos po-
tenciais que podem afetar o projeto. Isso significa minimizar a possibilidade e o
impacto de riscos negativos e, ao mesmo tempo, maximizar a probabilidade e o
impacto dos riscos positivos.
h) Gerenciamento de recursos humanos do projeto
Abrange todos os aspectos de gerenciamento e da interação das pessoas,
incluindo liderança, orientação, resolução de conflitos e gestão de avaliação de
desempenho, entre outras atividades. Esses processos visam a fazer com que os
recursos humanos designados para o projeto sejam utilizados da maneira mais
eficiente possível. Entre os participantes do projeto com os quais você pratica-
rá essas habilidades estão as partes interessadas, os integrantes da equipe e os
clientes. Cada um deles requer o uso de diferentes estilos de comunicação e com-
petências de liderança e formação de equipes. Assim, um gerente de projetos
126
eficiente deve saber quando aplicar determinadas aptidões e estilos de comuni-

cação, de acordo com a situação.
i) Gerenciamento da qualidade do projeto
Esse processo pretende assegurar que o projeto atenda aos requisitos com os
quais se comprometeu. Concentra-se na qualidade do produto e na qualidade
dos processos de gerenciamento de projetos empregados no ciclo de vida do
projeto. Esses processos avaliam o desempenho geral, monitoram os resultados
do projeto e os comparam com os padrões de qualidade estabelecidos no pro-
cesso de planejamento do projeto, a fim de garantir que o cliente receba o produ-
to ou serviço que supõe ter comprado.
Neste tópico, você aprendeu sobre as nove áreas de conhecimento do geren-
ciamento de projetos: quais são essas áreas e sua diferença em relação aos grupos
de processos.
4.7 GERENCIAMENTO DE INTEGRAÇÃO DO PROJETO
O Gerenciamento de Integração coordena as diversas áreas do projeto, ou

seja, trata da conexão efetiva entre as nove áreas de conhecimento (integração,
escopo, tempo, custo, comunicação, aquisições, risco, recursos humanos e quali-
dade) de um projeto e seus processos.
Seu principal produto é o Plano do Projeto, que auxilia no gerenciamento do
projeto, porque descreve os processos e as atividades que integram os diversos
elementos. Esses elementos são identificados, definidos, combinados, unificados
e coordenados dentro dos grupos de processos de gerenciamento de projetos.
CONCEITO DE GERENCIAMENTO DE INTEGRAÇÃO DO PROJETO
Trata da coordenação de todos os aspectos do plano do projeto e envolve um

elevado nível de interação. Esta área identifica e define o trabalho do projeto e
combina, unifica e integra os processos apropriados. Ela também se preocupa
em atender aos requisitos do cliente e das partes interessadas satisfatoriamente,
além de gerenciar suas expectativas (HELDMAN, 2009).
As principais atividades realizadas neste gerenciamento são: elaboração do
termo de abertura do projeto; declaração de escopo; plano de gerenciamento do
projeto; orientação e gestão executiva; monitoramento e controle; controle inte-
grado de mudanças; e encerramento do projeto, as quais você verá em detalhes
a seguir.
127
TERMO DE ABERTURA DO PROJETO
O termo de abertura do projeto é um documento utilizado para descrever as

responsabilidades do gerente do projeto. Esse documento precisa reter informa-
ções básicas, como: objetivo ou justificativa do projeto, necessidade de negócio
ao qual o projeto foi endereçado, requisitos que satisfazem as necessidades dos
interessados, designação do gerente do projeto, cronograma sumarizado, orça-
mento sumarizado, premissas e restrições do projeto.
DECLARAÇÃO DE ESCOPO
É normal fazer uma declaração do escopo preliminar, pois ela define de ante-
mão o que precisa ser realizado no projeto. Esse documento serve de referência
no acordo entre as partes envolvidas (stakeholders), facilitando a tomada de deci-
sões sobre mudanças e sobre o detalhamento do projeto.
Stakeholder é o termo usado em diversas áreas que se

VOCÊ refere a todos os envolvidos em um processo, que pode
SABIA? ser de caráter temporário (como um projeto) ou dura-
douro (como o negócio de uma empresa).
PLANO DE GERENCIAMENTO DO PROJETO
O plano de gerenciamento do projeto é um processo necessário para definir,

preparar, integrar e coordenar todos os componentes de um plano de gerencia-
mento do projeto. É um documento dinâmico, pois evolui durante todo o ciclo de
vida do projeto. Como ele registra todas as atividades do gerenciamento, auto-
maticamente se torna uma das principais fontes de informações de como o pro-
jeto será planejado, executado, monitorado, gerenciado e encerrado.
ORIENTAÇÃO E GESTÃO EXECUTIVA
Após a definição do plano de gerenciamento de projeto, você deve orientar e

gerenciar a execução do projeto. Nessa etapa, a equipe do projeto realizará diver-
sas ações para a execução do plano do projeto, de forma que todas as atividades
previstas na declaração do escopo sejam realizadas.
128
O PMBOK exemplifica várias dessas ações executivas. Veja:

a) executar as atividades para realizar os objetivos do projeto;
b) empreender os esforços e usar recursos financeiros para realizar os objeti-
vos do projeto;
c) formar, treinar e gerenciar os membros da equipe do projeto designados
para o projeto;
d) implementar as normas e os métodos planejados;
e) criar, controlar, verificar e validar as entregas do projeto;
f) gerenciar os riscos e implementar as atividades de respostas a riscos;
g) gerenciar os fornecedores;
h) adaptar as mudanças aprovadas ao escopo, planos e ambiente do projeto;
i) estabelecer e gerenciar os canais de comunicação do projeto, tanto externos
como internos à equipe do projeto.
Por fim, tenha sempre em mente que orientar e gerenciar a execução do pro-
jeto é coordenar e direcionar as várias interfaces técnicas e organizacionais. Logo:
a) o projeto deve ter um processo definido;
b) o processo é afetado pela área de aplicação do projeto;
c) o processo realiza o controle da baseline e ações corretivas;
d) o processo depende da pró-atividade do gerente de projeto.
Uma baseline é uma “imagem” de uma versão de cada

VOCÊ artefato no repositório do projeto. Ela funciona como
um padrão oficial básico para os trabalhos subsequen-
SABIA? tes. Somente mudanças autorizadas podem ser efetua-
das na baseline.
MONITORAMENTO E CONTROLE
O processo de “monitorar e controlar”, segundo o PMBOK, está relacionado

à comparação do desempenho real do projeto com o planejado, avaliação do
uso de ações corretivas e/ou preventivas, monitoramento de riscos, manutenção
de uma base de informações sobre o projeto e a documentação associada como
suporte para relatórios de acompanhamento e medições de progresso, previsão
de atualização do cronograma e dos custos do projeto e monitoramento das mu-
danças aprovadas no projeto.
129
CONTROLE INTEGRADO DE MUDANÇAS
Todas as alterações identificadas durante o monitoramento e controle de um

projeto precisam ser analisadas e revisadas. O responsável pela coordenação das
alterações deve revisar os pedidos, aprovações e controle das mudanças, nas en-
tregas e nos ativos organizacionais. Essas alterações podem estar relacionadas ao
escopo, tempo, custo, qualidade e demais áreas de conhecimento.
ENCERRAMENTO DO PROJETO
Um projeto sempre deve ter seu encerramento definido. Normalmente isso

ocorre quando seus objetivos são alcançados. Também é importante que o pro-
jeto possua uma estratégia de gerar e coletar informações com o objetivo de do-
cumentar e arquivar para o futuro.
Além do encerramento por entrega do produto, um projeto também pode ser
encerrado por:
a) Adição: ocorre quando um projeto sofre muitas modificações, que evoluem
para operações rotineiras, portanto deixa de ser um projeto;
b) Corte de recursos: ocorre quando recursos financeiros são retirados do
projeto, impossibilitando sua conclusão;
c) Realocação dos recursos: ocorre quando recursos materiais e/ou humanos
são desviados para outros projetos;
d) Obsolescência: ocorre quando os objetivos do projeto não mais interessam
ao cliente ou patrocinador por algum motivo externo.
FERRAMENTAS DE GERENCIAMENTO DE INTEGRAÇÃO
Segundo Heldman (2009), nesse processo há dois tipos de ferramentas que

podem ser utilizados para integração entre os processos: o primeiro é algum sof-
tware de integração; o segundo tipo é a técnica conhecida como Gerenciamento
de Valor Agregado (GVA, do inglês Earned Value Management), uma metodologia
de integração de projetos que, além de integrar processos, auxilia na mensuração
do desempenho do projeto ao longo do seu ciclo de vida.
Neste tópico você aprendeu que o principal produto do gerenciamento de
integração é o plano do projeto. O termo de abertura do projeto descreve as res-
ponsabilidades do gerente do projeto, e a declaração do escopo é constantemen-
te refinada junto com os interessados no projeto. O plano de gerenciamento inte-
gra os componentes, enquanto a gestão propriamente dita orienta as atividades
130
para alcançar o previsto no escopo. Os desvios identificados durante a orientação

da execução devem ser corrigidos na etapa de monitoramento e controle. O en-
cerramento do projeto é uma etapa importante, porém pode ser feita de várias
maneiras diferentes.
4.8 GERENCIAMENTO DO ESCOPO DO PROJETO
Gerenciamento de escopo Escopo corresponde ao objetivo que se pretende

atingir. É o termo utilizado para definição dos limites de um projeto. Assim, o pla-
no de projeto obedece ao escopo do projeto. Nesse contexto, o gerenciamen-
to do escopo do projeto tem por objetivo garantir que o projeto realize “todo”,
considerando “somente” o trabalho necessário para o seu sucesso. Em outras
palavras, além de controlar as mudanças, o gerenciamento do escopo também
organiza o que deve e o que não deve ser feito no projeto.
Neste tópico, você vai aprender o que envolve a área de gerenciamento do
escopo e estudar os processos da criação de um escopo efetivo.
CONCEITO DE GERENCIAMENTO DO ESCOPO
Trata da definição de todo o trabalho do projeto e apenas do trabalho neces-

sário para produzir com sucesso os objetivos do projeto. As atividades que com-
põem esse processo são altamente interativas. Elas definem e controlam o que
faz parte ou não do projeto e ocorrem pelo menos uma vez (e, com frequência,
várias vezes) durante o ciclo de vida do projeto (HELDMAN, 2009).
O gerenciamento do escopo compreende tanto o escopo do produto como o
escopo do projeto. O escopo do produto refere-se às características do produto
ou serviço do projeto. Ele é contraposto aos requisitos do projeto para determinar
sua conclusão. Já o escopo do projeto envolve a administração da execução do
projeto, e só da execução do projeto. Ele é confrontado com o plano de gerencia-
mento do projeto, a declaração de escopo (e a sua estrutura analítica de projeto
– EAP) e seu dicionário.
As principais atividades realizadas nesse gerenciamento são: planejamento do
escopo, definição do escopo e elaboração da estrutura analítica do projeto.
a) Planejamento do escopo
A finalidade do planejamento do escopo é descrever como o projeto deve ser
gerenciado e como as mudanças do projeto devem ser incorporadas. Requer um
balanceamento cuidadoso entre as ferramentas, recursos, metodologias, proces-
131
sos e outros fatores que garantam que os esforços realizados na definição este-
jam de acordo com o tamanho, complexidade e importância do projeto.
b) Definição do escopo
Enquanto o planejamento do escopo prevê o balanceamento de todas as atri-
buições do projeto, a etapa da definição do escopo tem igual importância na fase
inicial do projeto. É através do escopo que todos os envolvidos conhecem a estru-
tura das atividades para alcançar um determinado objetivo.
A definição do escopo também pode contar com uma análise especializada.
Essa análise avalia as entradas de iniciação, e os seus especialistas podem ser con-
sultores, outras unidades da organização, associações industriais e técnicas, além
de outras partes envolvidas.
Brainstorming é uma técnica de reunião que pode ser

VOCÊ utilizada para definição do escopo. Trata-se de uma
SABIA? atividade desenvolvida para explorar a potencialidade
criativa de um indivíduo ou de um grupo.
c) Elaboração da estrutura analítica do projeto (EAP)

Existem algumas ferramentas que facilitam a criação do escopo de um projeto.
Uma delas é a chamada Estrutura Analítica do Projeto (EAP), termo que vem do
inglês Work Breakdown Structure (WBS). Essa técnica é utilizada para desmembrar
as fases de um projeto, e sua finalidade é colocar em evidência somente os itens
necessários na realização de um projeto.
COMPOSIÇÃO DA EAP
Os itens de níveis mais inferiores da EAP são chamados de pacotes de trabalho.

Cada pacote deve ter: um código de identificação único; um artefato (documen-
to) de saída específico e verificável; um único responsável pela sua entrega; de
40 a 80 horas de duração (de acordo com o ciclo de acompanhamento); recursos
humanos (equipe), tecnológicos e logísticos alocados. Cada artefato de saída tem
um cliente validado, um formato definido e critérios de aceite previamente acor-
dados com esse cliente.
132
PASSOS PARA A CRIAÇÃO DA EAP
Após a elaboração de um nível de detalhamento estruturado, é preciso realizar

a verificação do escopo. De acordo com o Guia PMBOK, a verificação do escopo é
o processo de obtenção da aprovação formal do escopo do projeto por parte dos
envolvidos e interessados diretos.
A seguir, o escopo deve ser controlado. Este controle está relacionado ao ge-
renciamento das alterações do escopo, de forma a garantir que sejam coletadas
todas as informações relacionadas aos interessados nas alterações. O controle do
escopo pode ser definido considerando as seguintes etapas:
a) identificação de algum problema no escopo;
b) proposição e análise de mudanças no escopo;
c) avaliação de impacto, riscos, custos, atrasos no escopo;
d) elaboração da documentação de mudanças do escopo.
Neste tópico você aprendeu que o escopo é um dos principais recursos para a
realização de um projeto e que, quanto mais detalhado for o escopo, melhor será
o resultado final do projeto.
4.9 GERENCIAMENTO DO TEMPO DO PROJETO

Dreamstime (2012)
Figura 43 - Gerenciamento do tempo

133
Administrar o tempo é uma tarefa que exige atenção, pois o tempo é algo críti-
co, que deve ser devidamente controlado durante todo o ciclo de vida do projeto.
Por isso, na gestão de projetos, é importante saber utilizar o tempo ao seu favor,
tanto na elaboração como na execução das atividades do projeto.
Neste tópico, você vai aprender como gerenciar bem o tempo em um projeto
e conhecer alguns processos que facilitam o gerenciamento do tempo.
CONCEITO DE GERENCIAMENTO DO TEMPO
Gerenciamento do tempo é a área responsável por estimar a duração das ati-

vidades do plano do projeto, elaborar o cronograma do projeto e monitorar e
controlar desvios do cronograma. Em termos gerais, trata da conclusão do proje-
to em tempo hábil. O gerenciamento do tempo é um aspecto importante do ge-
renciamento de projetos, pois envolve a manutenção das atividades do projeto
em dia e a contraposição dessas atividades ao plano de projeto para garantir que
ele seja concluído dentro do prazo (HELDMAN, 2009).
Basicamente, a principal atividade realizada nesse gerenciamento é o planeja-
mento do tempo, cujo objetivo é garantir que o projeto seja concluído dentro do
prazo determinado. De acordo com o Guia PMBOK, o planejamento do tempo é
composto pelas seguintes tarefas:
a) definição das atividades;
b) sequenciamento de atividades;
c) estimativa de recursos das atividades;
d) estimativa de duração das atividades;
e) desenvolvimento do cronograma;
f) controle do cronograma.
DEFINIÇÃO DAS ATIVIDADES
Definição das atividades é o primeiro passo para o gerenciamento do tempo.

Envolve a identificação das atividades específicas do cronograma que serão reali-
zadas para produzir as entregas do projeto.
Após a definição do escopo e a identificação dos principais produtos, as ativi-
dades do projeto precisam ser definidas, sequenciadas e estimadas. Ao estimar a
duração, é necessário definir o cronograma das atividades que envolvem identifi-
car e documentar o trabalho planejado e a ser realizado.
134
SEQUENCIAMENTO DE ATIVIDADES
Após a identificação das atividades, você dará início ao seu sequenciamento,

realizando a identificação e a documentação das dependências entre as ativida-
des do cronograma.
Durante esse processo, os diagramas de rede de projeto são utilizados como
base para o planejamento, análise e monitoramento de programas, datas e recur-
sos (por exemplo: pessoas, máquinas, materiais, documentos e desenhos).
Diagramas de rede do projeto são as representações esquemáticas das ativi-
dades do cronograma do projeto e dos relacionamentos lógicos entre elas (de-
pendências). Esses diagramas geralmente são desenhados da esquerda para a
direita para refletir a ordem cronológica dos acontecimentos.
Identificando as atividades previstas, elas podem ser feitas em sequência (sé-
rie) ou simultaneamente (em paralelo).
Através do diagrama de rede você pode obter respostas a perguntas que ge-
ralmente aparecem durante a definição das atividades, como:
a) Existem pontos confusos nos processos do projeto?
b) Isto pode acarretar consequências?
c) Para garantir que a programação seja mantida, quando e em que quantida-
de os recursos devem estar disponíveis?
O diagrama de rede também permite fazer diversos tipos de relacionamento,
como: “Término – Início”, “Início – Início”, “Término – Término” e “Início – Término”.
ESTIMATIVAS DE RECURSOS DAS ATIVIDADES
De acordo com o Guia PMBOK, a estimativa de recursos das atividades do cro-

nograma envolve determinar os recursos (pessoas, equipamentos ou material),
as quantidades de cada recurso que será usado, e quando cada recurso estará
disponível para realizar as atividades do projeto.
Isso envolve tentar prever tempo, recursos e/ou dinheiro necessários para pro-
duzir um produto, serviço ou resultado específico. Geralmente, essa atividade se
beneficia de experiências anteriores, tais como: bancos de dados sobre estimati-
vas comerciais; experiência da equipe; opinião de especialistas.
135
ESTIMATIVA DE DURAÇÃO DAS ATIVIDADES
A duração das atividades do cronograma deve ser estimada a partir das infor-
mações do escopo do projeto e dos recursos disponíveis. Assim, estima-se o pro-
cesso de duração das atividades. Faz parte desse processo estimar a quantidade
ou número de períodos de trabalho exigidos para implementar uma atividade.
DESENVOLVIMENTO DO CRONOGRAMA
O desenvolvimento do cronograma parte da análise dos recursos necessários,

restrições, durações e sequências de atividades de um projeto. Uma técnica usa-
da para determinar a flexibilidade na elaboração de cronogramas é o chamado
Método do Caminho Crítico (Critical Path Method – CPM).
Esse método calcula datas teóricas de início e término mais cedo, e de início
e término mais tarde de todas as atividades do cronograma. O cálculo é fei-
to sem considerar quaisquer limitações de recursos, realizando uma análise do
caminho de ida e uma análise do caminho de volta pelos caminhos de rede do
cronograma do projeto.
COMPREENSÃO DO CRONOGRAMA
Você certamente já ouviu a expressão que diz que “tempo é dinheiro”. O que
fazer quando o cronograma prevê mais atividades incompatíveis com a data do
fim do projeto?
Uma das opções é executar uma “compressão do cronograma”. Essa técnica
reduz o cronograma do projeto sem mudar o escopo do projeto para atender a
restrições, datas impostas e outros objetivos do cronograma.
As técnicas de compressão do cronograma incluem:
a) Compressão (Crashing) – alocar mais recursos às atividades do caminho
crítico;
b) Paralelismo (Fast Tracking) – realizar atividades em paralelo que normal-
mente deveriam ser executadas em sequência;
c) Nivelamento de recursos (resource-based method) – busca evitar a supe-
ralocação dos recursos retirando os recursos das atividades não críticas e
alocando nas atividades críticas. Prevê que as mudanças no cronograma
sejam efetuadas em função da disponibilidade dos recursos com o obje-
tivo de diminuir os custos do projeto, buscando o equilíbrio no uso dos
recursos, atenuando “picos” e os “vales” de utilização, o que minimiza a
136
necessidade de recursos adicionais e a ociosidade de recursos alocados e

utilização de regras heurísticas ou modelos de otimização automática no
nivelamento de recursos.
Heurística é um conjunto de regras de julgamento que

VOCÊ ajudam a guiar as pessoas em tomadas rápidas de deci-
SABIA? sões. Se for bem empregada, pode ajudar a levar ao ob-
jetivo pelo melhor caminho, utilizando o menor tempo.
CONTROLE DO CRONOGRAMA
Assim como na etapa de planejamento de projeto, também no cronogra-

ma é necessário realizar o monitoramento e controle. Essa atividade envolve a
determinação do andamento atual do cronograma do projeto, o controle dos
fatores que criam mudanças no cronograma, a determinação de que o crono-
grama do projeto mudou e o gerenciamento das mudanças conforme elas efe-
tivamente ocorrem.
CONSIDERAÇÕES SOBRE AS TAREFAS
Heldman (2009) enfatiza que, embora cada uma das tarefas listadas acima
ocorra pelo menos uma vez (ou mais) em cada projeto, o sequenciamento e a
estimativa de duração das atividades, e o desenvolvimento do cronograma, são
– sobretudo nos projetos de menor porte – tratados como uma única atividade.
Nos projetos menores basta uma pessoa para realizá-los, e todos são trabalhados
simultaneamente.
Neste tópico, você aprendeu que o bom uso do tempo é de extrema impor-
tância para a realização de um projeto. A definição das atividades, o seu sequen-
ciamento e a estimativa de duração de cada atividade são etapas importantes na
criação de um cronograma de projeto.
137
4.10 GERENCIAMENTO DE CUSTOS DO PROJETO
Dreamstime (2012)
Figura 44 - Gerenciamento de custos
A área de gerenciamento de custos, assim como a de gerenciamento do tem-

po, é considerada uma área-chave no gerenciamento de projetos, por isso tem
grande impacto na dinâmica da execução de projetos.
O principal objetivo da área de gerenciamento de custos é garantir que o ca-
pital disponível seja suficiente para a obtenção de todos os recursos necessários
para a realização dos trabalhos do projeto.
Neste tópico, você verá a importância do gerenciamento de custos, de que
maneira ele acontece e qual é a melhor forma de conduzi-lo, a divisão de seus
processos, o planejamento de custos e a análise financeira de um projeto.
CONCEITO DE GERENCIAMENTO DE CUSTOS
As atividades dessa área definem estimativas de custos e recursos, além de

controlar tais custos para garantir que o projeto permaneça dentro do orçamento
aprovado (HELDMAN, 2009).
As principais atividades realizadas nesse gerenciamento são:
a) estimativa de custos;
b) elaboração dos orçamentos;
c) controle de custos;
d) análise financeira.
138
ESTIMATIVA DE CUSTOS
Para estimar custos planejados devem-se prever de forma realista os custos de

todos os recursos a serem utilizados nas atividades do projeto. Com base no pla-
nejamento de recursos feito anteriormente, nas taxas associadas a cada recurso,
calcula-se o custo previsto para cada pacote de trabalho.
Heldman (2009) define pacotes de trabalho:
são as atividades ou componentes que podem ser facilmente

atribuídos a uma pessoa ou grupo, que assumirão a clara res-
ponsabilidade pelo seu cumprimento. Além das estimativas de
custo, os pacotes de trabalho servem de base também para
estimativas de tempo e recursos.
A autora descreve ainda a sua utilização em projetos de grande porte:
Em projetos de grande porte, os níveis dos pacotes de trabalho

podem constituir subprojetos – decompostos, por sua vez, em
suas próprias estruturas analíticas. Também podem se consti-
tuir em trabalho que devem ser realizados por pessoal tercei-
rizado, outra organização ou outro departamento da empresa.
Se você delegar tarefas do projeto para outro setor da orga-
nização, deve distribuir os pacotes de trabalho para gerentes
individuais, que por sua vez vão subdividi-los em atividades
durante o processo de definição de atividades, que ocorre no
processo de planejamento. Caso você confie pacotes de traba-
lho a um profissional externo, essas atividades não constarão
na estrutura analítica desse projeto. Por exemplo, imagine que
uma das entregas de seu projeto seja uma embalagem espe-
cial, e haja pessoal terceirizado encarregado dessa tarefa. Este
provavelmente tratará a entrega como um projeto dentro de
sua própria organização, decompondo o trabalho até o nível
das atividades. Para o seu projeto, porém, ela não passará de
uma entrega no nível dos pacotes de trabalho (Heldman, 2009).
A atividade de estimativa de custos emprega diversas ferramentas e técnicas

para gerar as estimativas. Destacam-se:
a) opinião especializada;
b) estimativa bottom-up;
c) estimativa de três pontos;
139
d) análise das reservas;

e) custo da qualidade;
f) software de estimativa de gerenciamento de projetos;
g) análise da proposta do fornecedor.
SAIBA Detalhes sobre essas ferramentas e técnicas podem ser obti-

MAIS dos no livro Gerência de projetos, de Kim Heldman (2009).
ELABORAÇÃO DOS ORÇAMENTOS
Após a estimativa de custos, inicia-se a elaboração dos orçamentos, quando

se alocarão os valores nos diversos níveis da estrutura. A alocação das estimativas
dos custos nas atividades individuais dos pacotes de trabalho tem como finalida-
de estabelecer uma linha base de custos para medir o desempenho do projeto.
Heldman (2009) descreve três ferramentas e técnicas utilizadas para elabora-
ção de orçamentos:
a) agregação de custos;
b) relações históricas;
c) reconciliação do limite de recursos financeiros.
AGREGAÇÃO DE CUSTOS
É o processo de agregação das estimativas de custos das atividades do crono-

grama no nível dos pacotes de trabalho e, em seguida, totalização desses níveis
de pacote nos níveis mais altos de componentes da estrutura do projeto. Assim,
todos os custos podem ser agregados para obter um custo total do projeto.
RELAÇÕES HISTÓRICAS
São estimativas de projetos semelhantes e paramétricas que podem ser utili-

zadas para ajudar a determinar custos totais do projeto. Estimativas de projetos
semelhantes são úteis quanto não há informações detalhadas disponíveis sobre
o projeto ou quando ele ainda está em fases iniciais.
140
1 fluxo de caixa Estimativas paramétricas representam um método de base quantitativa. Por

exemplo, multiplicam a quantidade de tempo necessária para executar uma ati-
Indica a origem de todo
o recurso financeiro vidade pelos custos dos recursos necessários, com o objetivo de determinar seu
(dinheiro) que entrou
no caixa da empresa, custo total. Essa técnica pode ser exata quando os dados utilizados são confiáveis.
bem como o destino de
todo o recurso que saiu,
considerando determinado
período de tempo. Seu
principal objetivo é RECONCILIAÇÃO DO LIMITE DE RECURSOS FINANCEIROS
evidenciar as transações
que efetivamente
movimentaram o caixa.
Envolve a reconciliação do total gasto com os limites de financiamento orça-
dos para o projeto – definidos pela empresa ou pelo cliente.
Todo projeto possui um orçamento. Para ele ser consi-

VOCÊ derado bem-sucedido, é preciso finalizá-lo dentro do
SABIA? orçamento aprovado. Às vezes, o gerente de projetos
não é responsável por esse aspecto do trabalho.
CONTROLE DE CUSTOS
O próximo passo após a elaboração dos orçamentos é o controle de custos,

que tem o objetivo de gerenciar as mudanças no orçamento do projeto ao decor-
rer de suas variações.
De acordo com o PMBOK, o controle de custos do projeto inclui:
a) controlar os fatores que criam mudanças na linha de base dos custos;
b) garantir que houve um acordo em relação às mudanças solicitadas;
c) monitorar as mudanças reais quando e conforme ocorrem;
d) garantir que os possíveis estouros nos custos não ultrapassem o financia-
mento autorizado periodicamente e no total para o projeto;
e) monitorar o desempenho de custos para detectar e compreender as varia-
ções em relação à linha de base dos custos;
f) registrar exatamente todas as mudanças adequadas em relação à linha de
base dos custos;
g) evitar que mudanças incorretas, inadequadas ou não aprovadas sejam inclu-
ídas nos custos relatados ou na utilização de recursos;
h) informar as partes interessadas adequadas sobre as mudanças aprovadas;
i) agir para manter os estouros nos custos esperados dentro dos limites acei-
táveis.
141
ANÁLISE FINANCEIRA
A análise financeira de projetos é feita por métodos numéricos que comparam

indicadores financeiros de projetos. A necessidade de decidir por um projeto ou
por outro decorre do fato de lidar com recursos limitados e pressões para fazer
sempre melhor, mais rápido e mais barato.
Três técnicas para análise financeira ganham destaque por serem mais conhe-
cidas e utilizadas: VPL, TIR, PAYBACK.
O VPL (Valor Presente Líquido) considera o fluxo de caixa1 descontado pela
taxa de juros do mercado financeiro, e o valor presente dos benefícios (receitas) é
subtraído do valor do investimento no projeto. Critérios de aceitação do projeto:
a) VPL > 0 indica que o investimento será recuperado;
b) VPL < 0 indica que o investimento no mercado financeiro seria mais atrativo.
A TIR (Taxa Interna de Retorno) é a taxa de desconto que torna o VPL igual a
zero. É a taxa de desconto que iguala o valor presente das receitas com o inves-
timento inicial do projeto. Trata-se da taxa relativa ao fluxo de caixa do projeto.
Critério de aceitação do projeto:
Se TIR > taxas do mercado financeiro, então o projeto é atrativo do ponto de
vista do retorno financeiro.
Já o PAYBACK, nome dado ao Período de Retorno do Investimento, trata do
período de tempo necessário para o retorno do valor do investimento inicial. O
tempo de payback é o tempo necessário para que os fluxos de caixa positivos se
igualem aos fluxos de caixa negativos do projeto.
Neste tópico, você aprendeu que o gerenciamento de custos divide com
o gerenciamento do tempo o mais alto grau de importância para um projeto.
Também viu que o gerenciamento de custos pode ser dividido em quatro pro-
cessos: estimativa de custos; elaboração de orçamentos; controle de custos; e
análise financeira.
142
4.11 GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO
Denis Pacher (2012)

Figura 45 - Gerenciamento das comunicações
Na sociedade atual, os canais de comunicação se expandem cada vez mais e

se transformam. A informação está em todo lugar. Mas o que isso tem a ver com
projetos?
Tudo. Um plano de comunicação é essencial em qualquer empreendimento
logo no início do projeto, visando a evitar atrasos, atritos, aumento dos custos e
desvio de escopo.
Neste tópico, você vai desvendar os processos para uma comunicação eficaz,
e ainda saber como planejar e gerenciar a comunicação dentro de um projeto.
CONCEITO DE GERENCIAMENTO DAS COMUNICAÇÕES
Os processos da área de gerenciamento das comunicações estão relacionados

com as habilidades gerais de comunicação, mas vão muito mais além da troca
de informações. As competências de comunicação são as habilidades gerais de
gerenciamento que o gerente de projetos usa no dia a dia. Os processos aí envol-
vidos visam a garantir que todas as informações dos projetos, incluindo planos de
projeto, avaliações de risco, notas tomadas em reuniões etc., sejam coletadas, do-
cumentadas, arquivadas e descartadas quando apropriado. Asseguram também
a distribuição e o compartilhamento das informações com as partes interessadas,
gerência e integrantes do projeto nos momentos adequados. Ao término do pro-
jeto, as informações são arquivadas e usadas como referência para os próximos
projetos (HELDMAN, 2009).
143
As principais atividades realizadas nesse gerenciamento são:

a) planejamento das comunicações;
b) distribuição das informações;
c) elaboração dos relatórios de desempenho;
d) gerenciamento das partes interessadas.
PLANEJAMENTO DAS COMUNICAÇÕES
Para que o plano de comunicação seja implementável e retrate as reais neces-

sidades de comunicação dos interessados, ele deve, em primeiro lugar, comuni-
car. Para isso, é preciso identificar as partes interessadas do projeto, determinar
os requisitos de informação dos interessados e definir a tecnologia e/ou métodos
utilizados para transmitir a informação. A partir daí, o plano de comunicação deve
ser desenvolvido.
Na prática, o planejamento das comunicações envolve a identificação do mé-
todo de comunicação mais adequado no contexto. Métodos de comunicação se
referem à maneira como as informações sobre o projeto são compartilhadas en-
tre as partes interessadas. Segundo o PMBOK, há três métodos de comunicação:
interativa, de uma via e de duas vias.
A comunicação interativa envolve a comunicação multidirecional em que
duas ou mais partes trocam pensamentos ou ideias. Esse método inclui recursos
tecnológicos como videoconferência, telefone e teleconferências, além de incluir
métodos tradicionais como reuniões.
Na comunicação de uma via, um emissor envia informações para um ou mais
receptores. Inclui métodos como cartas, memorandos, relatórios, e-mails, correio de
voz etc. Esse método assegura que a informação foi enviada, mas não se preocupa
com o fato de ela ter sido recebida ou mesmo entendida pelos seus receptores.
A comunicação em duas vias é o oposto da comunicação em uma. Nesse tipo
de comunicação, os receptores da informação acessam as informações por con-
ta própria, utilizando métodos como páginas de internet, sites de aprendizagem
eletrônica, repositórios de conhecimento, unidades de rede compartilhada etc.
144
DISTRIBUIÇÃO DAS INFORMAÇÕES
O processo de distribuição das informações tem como objetivo obter, orga-

nizar e dispor informações a todos os interessados do projeto, de acordo com o
plano de comunicações.
O uso da objetividade e da clareza é fundamental. Se houver ruídos na comu-
nicação, estes devem ser esclarecidos o quanto antes para não causarem proble-
mas ao longo do ciclo de vida do projeto.
ELABORAÇÃO DOS RELATÓRIOS DE DESEMPENHO
Os relatórios de desempenho são documentos que centralizam as informa-

ções sobre os resultados do projeto. Eles também alimentam o processo de toma-
da de decisão e realinhamento, sempre que for necessário.
GERENCIAMENTO DAS PARTES INTERESSADAS
O gerenciamento das partes interessadas é o gerenciamento das comunica-

ções entre as partes. Seu objetivo é detectar problemas, desvios e propor solu-
ções, de forma a aumentar a probabilidade de o projeto não se desviar do curso
por causa de problemas não resolvidos das partes interessadas.
A comunicação entre as partes interessadas é feita através dos canais de comu-
nicação. Esses canais serão o meio efetivo da comunicação entre os interessados.
Sobre os canais de comunicação, é importante salientar: utilize canais ricos
para implementar planos do projeto; não utilize um canal pobre na coleta de in-
formações sobre questões cruciais; não se limite a utilizar apenas um canal.
É o PMBOK que descreve os quatro processos neces-

VOCÊ sários para uma boa comunicação entre todos os en-
volvidos– planejamento, distribuição das informações,
SABIA? relatório de desempenho e gerenciamento das partes
interessadas.
145
CASOS E RELATOS
A importância da comunicação
Heldman (2009) comenta a importância da comunicação:
O gerenciamento das comunicações talvez seja a área do co-
nhecimento mais importante em qualquer projeto. E a maioria
dos gerentes de projetos entende a importância das boas habi-
lidades de comunicação e também de assegurar que as partes
interessadas recebam informações sobre o status do projeto.
Conheço uma gerente de projetos que tinha dificuldades de
marcar uma reunião com o patrocinador do projeto. O patro-
cinador do projeto concordava em marcar reuniões com a ge-
rente, ele agendava-as, e então cancelava ou simplesmente não
comparecia. A infeliz gerente do projeto não sabia o que fazer
para se comunicar com o patrocinador a fim de obter algumas
respostas às perguntas que ela tinha. Sua mesa não ficava lon-
ge do escritório do patrocinador do projeto. Um dia, vendo que
o patrocinador se encontrava em sua sala, ela decidiu que, se
o patrocinador não vinha até ela, ela iria até ele. Desde então,
toda vez que o patrocinador saía de seu escritório, ela pulava da
sua cadeira e pegava o elevador com ele. Era uma audiência ca-
tiva, isto é, naquela situação ele não tinha outra saída a não ser
ouvi-la. Ela conseguiu fazer com que ele respondesse a algumas
perguntas fáceis e, finalmente, o convenceu, depois da quarta
ou quinta viagem de elevador, que eles precisavam agendar
reuniões face a face regulares. Ela entendeu a importância da
comunicação e não mediu esforços para assegurar que o patro-
cinador também entendesse.
Um bom gerenciamento da comunicação prevê a identificação das par-
tes interessadas, as informações que devem ser comunicadas e o respon-
sável por esse processo, além dos métodos e frequência da comunicação.
146
2 Probidade 4.12 GERENCIAMENTO DAS AQUISIÇÕES DO PROJETO

administrativa
Significa integridade de
caráter, honradez. Seu
contrário, a improbidade,
é o mesmo que
desonestidade, falta de
caráter.
Denis Pacher (2012)

Figura 46 - Gerenciamento das aquisições
O gerenciamento de aquisições é uma das áreas de conhecimento do Guia

PMBOK frequentemente empregada em qualquer projeto, seja de pequeno, mé-
dio ou grande porte. Essa área é responsável por cuidar das compras e aquisições
de produtos, e serviços e/ou resultados necessários para a realização do trabalho.
Neste tópico, você vai conhecer os conceitos e processos do gerenciamento
de aquisições e as seis modalidades de licitação no Brasil.
CONCEITO DE GERENCIAMENTO DAS AQUISIÇÕES
Abrange os processos relacionados à compra de bens ou serviços de fornece-

dores externos e empresas contratadas (HELDMAN, 2009).
As principais atividades realizadas nesse gerenciamento são: planejamento e
realização das aquisições.
a) Planejamento das aquisições
É um processo que visa a identificar que bens ou serviços serão comprados de
fora da organização e a quais necessidades a equipe de projeto precisa atender.
Parte da sua tarefa nesse processo é confirmar se você deve adquirir produtos ou
serviços e, em caso afirmativo, quanto e quando.
b) Realização das aquisições
Diz respeito à obtenção de respostas a ofertas e propostas dos potenciais for-
necedores, à seleção de um fornecedor e à concessão do contrato. Esse processo
só é realizado quando você estiver comprando mercadorias ou serviços de fora
147
de sua organização. Se você dispõe de todos os recursos necessários à execução

do trabalho do projeto dentro da organização, esse processo não será utilizado.
Agora que você já conhece os conceitos e processos relacionados ao gerencia-
mento de aquisições, veja como é o processo de aquisição do governo brasileiro.
LICITAÇÃO
É o procedimento administrativo para contratação de serviços ou aquisição de

produtos pelos governos federal, estadual, municipal ou entidades de qualquer
natureza. No Brasil, todas as licitações feitas por entidades que fazem uso da ver-
ba pública são reguladas, ou seja, controladas pelo poder executivo.
Neste subtópico, você aprenderá sobre aquisições realizadas pelo setor pú-
blico. No Brasil, todo processo de aquisição na Administração Pública está regu-
lamentado pela lei das licitações, a Lei Ordinária n. 8.666/93. Essa lei estabelece
normas gerais sobre licitações e contratos administrativos pertinentes a obras e
serviços, incluindo publicidade, compras, alienações e locações no âmbito dos
poderes da União, dos estados, do Distrito Federal e dos municípios.
SAIBA Para ler mais a respeito da lei das licitações, acesse o link
MAIS <www.planalto.gov.br/ccivil_03/leis/L8666cons.htm>.
PROCESSO LICITATÓRIO
O processo licitatório é composto de diversos procedimentos e destina-se a ga-

rantir a observância do princípio constitucional da isonomia, a seleção da proposta
mais vantajosa para a Administração e a promoção do desenvolvimento nacional
sustentável. Toda licitação deve ser processada e julgada em estrita conformidade
com os princípios básicos da legalidade, da impessoalidade, da moralidade, da
igualdade, da publicidade, da probidade administrativa2, da vinculação ao instru-
mento convocatório, do julgamento objetivo e dos que lhe são relacionados.
Mais informações sobre esses princípios podem ser vistas na Constituição da
República Federativa do Brasil de 1988, disponível em <www.planalto.gov.br/cci-
vil_03/Constituicao/Constituiçao.htm>.
148
3 Alienação EDITAL
É a transferência da posse
de um bem móvel ou Todas as características do bem ou serviço que será adquirido devem constar
imóvel do devedor ao no edital. Esse documento é desenvolvido para estabelecer as condições da lici-
credor para garantir o
cumprimento de uma tação. A correta elaboração do edital e a definição precisa das características do
obrigação. bem ou serviço pretendido pela entidade licitadora são essenciais para a concre-
tização da licitação.
MODALIDADES DE LICITAÇÃO
No Brasil existem seis modalidades de licitação, previstas no artigo 22 da Lei n.

8.666/93. São elas:
a) Concorrência: é a modalidade de licitação entre quaisquer interessados
que, na fase inicial de habilitação preliminar, comprovem possuir os requisi-
tos mínimos de qualificação exigidos no edital para execução de seu objeto;
b) Tomada de preços: é a modalidade de licitação entre interessados devida-
mente cadastrados, ou que atenderem a todas as condições exigidas para
cadastramento até o terceiro dia anterior à data do recebimento das propos-
tas, observada a necessária qualificação;
c) Convite: é a modalidade de licitação entre interessados do ramo pertinente
ao seu objeto, cadastrados ou não, escolhidos e convidados em número mí-
nimo de três pela unidade administrativa, a qual afixará, em local apropriado,
cópia do instrumento convocatório e o estenderá aos demais cadastrados
na correspondente especialidade que manifestarem seu interesse com an-
tecedência de até 24 (vinte e quatro) horas da apresentação das propostas;
d) Concurso: é a modalidade de licitação entre quaisquer interessados para
escolha de trabalho técnico, científico ou artístico, mediante a instituição de
prêmios ou remuneração aos vencedores, conforme critérios constantes de
edital publicado na imprensa oficial com antecedência mínima de 45 (qua-
renta e cinco) dias;
e) Leilão: é a modalidade de licitação entre quaisquer interessados para a ven-
da de bens móveis que não têm mais utilidade para a Administração ou de
produtos legalmente apreendidos ou penhorados, ou para a alienação3 de
bens imóveis, a quem oferecer o maior lance, igual ou superior ao valor da
avaliação;
f) Pregão: é a modalidade utilizada para aquisição de bens e serviços comuns.
Bens e serviços comuns são aqueles cujos padrões de desempenho e quali-
dade possam ser objetivamente definidos pelo edital, por meio de especifi-
cações usuais no mercado.
149
A modalidade “pregão eletrônico” foi introduzida na lei

VOCÊ de licitações posteriormente à Lei n. 8.666/93. Hoje, essa
SABIA? modalidade pode ser realizada por sites específicos do
órgão licitante.
Neste tópico, você aprendeu sobre o gerenciamento de aquisições e seus pro-

cessos e sobre a licitação, que é o procedimento administrativo para contratação
de serviços ou aquisição de produtos pelos governos. Finalmente, aprendeu o
conceito de edital e as modalidades de licitação.
4.13 GERENCIAMENTO DOS RISCOS DO PROJETO
Dreamstime (2012)
Figura 47 - Gerenciamento dos riscos
Chama-se “risco” um evento ou condição incerta que, se ocorrer, tem um

efeito positivo (ganho) ou negativo (perda) no objetivo do projeto. Apesar de a
maioria das pessoas se preocupar mais com os “riscos puros” (aqueles que só tra-
zem impactos negativos), um exemplo de risco que pode ter efeitos positivos ou
negativos é a variação da taxa de câmbio do dólar em projetos com contratos
expressos nessa moeda.
Neste tópico, você vai conhecer os processos pertencentes ao gerenciamento
dos riscos do projeto, identificar os componentes do risco e entender as estraté-
gias de resposta ao risco.
CONCEITO DE GERENCIAMENTO DOS RISCOS
Gerenciamento dos riscos refere-se à identificação, análise e planejamento de

riscos potenciais que podem afetar o projeto. Isso significa minimizar a possibili-
150
dade e o impacto de riscos negativos e, ao mesmo tempo, maximizar a probabili-

dade e o impacto dos riscos positivos (HELDMAN, 2009).
Segundo o Guia PMBOK, existem seis processos de gerenciamento de riscos:
a) Planejamento do gerenciamento de riscos: decisão de como abordar,
planejar e executar as atividades de gerenciamento de riscos de um projeto;
b) Identificação de riscos: determinação dos riscos que podem afetar o pro-
jeto e documentação de suas características;
c) Análise qualitativa de riscos: priorização dos riscos para análise ou ação
adicional subsequente através de avaliação e combinação de sua probabili-
dade de ocorrência e impacto;
d) Análise quantitativa de riscos: análise numérica do efeito dos riscos iden-
tificados nos objetivos gerais do projeto;
e) Planejamento de respostas a riscos: desenvolvimento de opções e ações
para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto;
f) Monitoramento e controle de riscos: acompanhamento dos riscos iden-
tificados, monitoramento dos riscos já existentes, identificação dos novos
riscos, execução de planos de respostas a riscos e avaliação da sua eficácia
durante todo o ciclo de vida do projeto.
Antes de estudar esses processos, compreenda a diferença entre risco e pro-
blema:
a) Risco: é uma situação que pode vir a ocorrer e causar impacto no projeto. É
gerenciável, pode (e deve) ser identificado previamente e pode se transfor-
mar em problema. Exemplos de riscos: alta do dólar (em contratos vincula-
dos ao dólar); mudança na legislação do setor; inviabilidade tecnológica (se
há dependência de tecnologia não comprovada);
b) Problema: é uma situação que de fato está ocorrendo e impactando o pro-
jeto. É solucionável, requer ação imediata e é descoberta (normalmente de
forma reativa) durante o curso do projeto. Exemplos de problemas: indispo-
nibilidade de infraestrutura para instalação de hardware; falta de recursos
necessários para início de certa atividade; atrasos no cronograma.
PLANEJAMENTO DO GERENCIAMENTO DE RISCOS
No planejamento dos riscos, a equipe de projetos deve decidir de que forma

vai lidar e planejar os riscos do projeto. Perceba que todos os dias nos deparamos
com riscos na vida. Isso é uma ação contínua, com a qual se lida, na maioria das
151
vezes, de forma intuitiva. No âmbito do gerenciamento de projetos, assim como

na vida, é preciso ter uma abordagem pró-ativa, e não reativa.
Riscos se originam da incerteza que está presente em todos os projetos (novo
e temporário). Com o atual cenário de um mercado com muita competitividade,
tecnologia avançada e duras restrições econômicas, os riscos assumiram propor-
ções significativamente maiores.
IDENTIFICAÇÃO DE RISCOS
A identificação envolve a utilização de várias ferramentas e técnicas. Destacam-se:

a) opinião especializada: consulta a especialistas na área;
b) reuniões específicas: uso de técnicas de reunião apropriadas ao objetivo a
ser atingido, como brainstorming, por exemplo;
c) delphi: técnica utilizada para obter a opinião especializada de forma anô-
nima, que também pode ser utilizada quando os profissionais se encontram
localizados remotamente;
d) pesquisa: busca em informações históricas de projetos anteriores;
e) listas de verificação: checklists.
Uma vez identificados, os riscos devem ser categorizados. Algumas das cate-
gorias mais comuns de riscos são: riscos organizacionais, riscos técnicos, riscos
externos.
ANÁLISE QUALITATIVA DE RISCOS
É o processo de avaliar a probabilidade e o impacto dos riscos identificados. A

análise qualitativa de riscos baseia-se no julgamento, na intuição e na experiência
em estimar probabilidades de ocorrência de potenciais riscos e medir a intensida-
de de perdas e ganhos potenciais.
ANÁLISE QUANTITATIVA DE RISCOS
A análise quantitativa de riscos é feita regularmente após a análise qualitativa,

e tem o objetivo de analisar numericamente a probabilidade de ocorrência de
cada risco e suas implicações para os objetivos do projeto. Ela se apoia em en-
trevistas com especialistas, séries históricas, planilhas estatísticas e outros dados
sobre a natureza do risco em estudo.
152
Existem várias técnicas para análise quantitativa. Dentre elas destacam-se:

análise de sensibilidade, árvore de decisão e métodos de simulação (Método de
Monte Carlo). Os principais produtos gerados a partir desse tipo de análise são
a relação priorizada dos riscos em potencial ao projeto e as probabilidades de
alcance dos objetivos.
VOCÊ O Método de Monte Carlo (MMC) é um método estatísti-

co utilizado em simulações com diversas aplicações em
SABIA? áreas como a física, a matemática e a biologia.
PLANEJAMENTO DE RESPOSTAS A RISCOS
Após a análise quantitativa dos riscos, é necessário realizar o planejamento de

respostas a riscos. Esse processo é responsável pela determinação das alternati-
vas e ações, para melhorar oportunidades e reduzir ameaças para o projeto.
Esse planejamento aborda os riscos de acordo com a sua prioridade, inserindo
recursos e atividades no orçamento, cronograma e plano de gerenciamento do
projeto, conforme necessário.
As principais estratégias para respostas a riscos são:
a) Mitigar: desenvolver ações visando minimizar a probabilidade da ocorrên-
cia do risco ou de seu impacto no projeto, com o objetivo de tornar o risco
aceitável. Exemplo: projetar uma redundância;
b) Evitar: mudar o plano do projeto eliminando a condição que estava expon-
do o projeto a um risco específico. Exemplo: adotar uma abordagem tradi-
cional em vez de uma inovadora;
c) Aceitar: indicada nas situações em que a criticidade do risco é média ou
baixa, na ocorrência de riscos externos em que não seja possível ou não haja
interesse em se implementar uma ação específica.
MONITORAMENTO E CONTROLE DE RISCOS
O último processo de gerenciamento de riscos é o monitoramento e controle

de riscos. De acordo com o Guia PMBOK, esse é o processo de identificação, aná-
lise e planejamento dos riscos recém-surgidos.
153
O guia aponta ainda algumas técnicas para o monitoramento, entre elas a aná-
lise das tendências e da variação. Esse processo visa determinar se as variáveis
de entrada do projeto ainda têm validade; se o risco alterou a condição anterior;
se as estratégias para o gerenciamento de riscos continuam válidas e sendo exe-
cutadas; e se o planejamento dos custos provisórios ou do cronograma deve ser
modificado como resposta aos riscos do projeto.
Neste tópico, você aprendeu que o planejamento do gerenciamento de riscos
é o processo de decidir como abordar e executar as atividades de gerenciamento
de riscos de um projeto; que o objetivo da identificação de riscos é determinar os
riscos que podem afetar o projeto e documentar suas características; e que um
plano de respostas é desenvolvido com o objetivo de otimizar as oportunidades
e diminuir possíveis ameaças ao projeto.
4.14 GERENCIAMENTO DOS RECURSOS HUMANOS DO PROJETO
O gerenciamento dos recursos humanos tem por objetivo possibilitar a me-

lhor utilização das pessoas envolvidas no projeto. Como recurso, cada pessoa tem
características próprias de personalidade e competências. Mas mesmo assim é
possível enquadrar as fases de uma equipe de trabalho e percebê-las evoluindo
junto, sendo que o gerente do projeto tem papel fundamental neste processo.
Neste tópico, você vai conhecer as ferramentas utilizadas no gerenciamento
de recursos humanos, entender quais ações devem constar na matriz de respon-
sabilidades e identificar os processos do gerenciamento de recursos humanos.
CONCEITO DE GERENCIAMENTO DOS RECURSOS HUMANOS
Abrange todos os aspectos de gerenciamento e da interação das pessoas, in-

cluindo liderança, orientação, resolução de conflitos e gestão de avaliação de de-
sempenho, entre outras atividades. Esses processos pretendem fazer com que os
recursos humanos designados para o projeto sejam utilizados da maneira mais
eficiente possível (HELDMAN, 2009).
As principais atividades que compõem este gerenciamento são:
a) planejamento de recursos humanos;
b) contratação e mobilização da equipe do projeto;
c) desenvolvimento da equipe do projeto;
d) gerenciamento da equipe do projeto.
154
PLANEJAMENTO DE RECURSOS HUMANOS
O planejamento de recursos humanos envolve identificar, documentar e de-

signar os papéis, as responsabilidades e os relacionamentos do projeto.
Por meio do plano de gerência de pessoal, esse planejamento serve para de-
finir como os recursos serão alocados e retirados da equipe do projeto. Uma boa
forma de organizar esse processo é elaborar um organograma do projeto e uma
matriz de responsabilidades.
O organograma do projeto é a representação gráfica dos relacionamentos de
reporte do projeto. Pode estar organizado em termos de função, responsabilida-
de, autoridade e competência:
a) a organização por função rotula e descreve a parte de um projeto pelo qual
a pessoa é responsável;
b) a organização por responsabilidade descreve o trabalho que deve ser feito;
c) a organização por autoridade mostra quem tem o direito de aplicar recur-
sos, tomar decisões ou assinar aprovações;
d) a organização por competência é função do somatório de conhecimento,
habilidade e atitude.
No quadro a seguir, você pode ver um exemplo de organização por responsa-
bilidade.
Quadro 2 - Identificação das responsabilidades
Função Responsabilidade
• aprovação de problemas, mudanças e riscos escalonados pelo

comitê operacional;
Diretores e gerentes
• aprovação do fechamento do projeto;
• aprovação do plano geral do projeto.
• aprovação de mudanças;
• aprovação de planos de respostas aos riscos;
• aprovação de planos de ação para resolução de problemas esca-
Gerente de projetos
lonados pelo gerente de projeto;
e usuários
• definição de escalonamento de problemas, mudanças ou riscos
para comitê executivo;
• aprovação do plano geral do projeto.
155
CONTRATAÇÃO E MOBILIZAÇÃO DA EQUIPE DO PROJETO
A equipe do projeto é fundamental para o seu êxito. Logo, uma equipe bem
montada, com profissionais comprometidos e capacitados, deve ser uma preocu-
pação constante para todos os envolvidos no projeto.
O gerenciamento das equipes de projeto não é uma tarefa fácil por dois moti-
vos: primeiro, porque os times de projetos são extremamente dinâmicos, ou seja,
os membros do grupo estão em constante mudança; segundo, porque talvez so-
mente o gerente do projeto e alguns membros da alta gerência consigam ver a
equipe do projeto como uma entidade única. Cabe ao gerente de projeto recrutar
um grupo de pessoas para auxiliá-lo ao longo do ciclo de vida do projeto.
Veja a seguir algumas recomendações para o gerente motivar sua equipe de
projetos:
a) pergunte à equipe como eles se sentem em relação a seu papel no projeto.
Isso o ajudará a corrigir o andamento das atividades para que se ajustem às ne-
cessidades da melhor forma possível. Além disso, pode obter feedback, o que
é importantíssimo para melhorar o desempenho do projeto como um todo;
b) quando o trabalho realizado for bom, elogie e mostre apreciação diante de
todos. Essa apreciação deve ser sincera para que fique clara a importância de
cada um nos resultados do projeto;
c) assuma riscos calculados dando à sua equipe atividades que expandam sua
zona de conforto, permitindo que aprendam e cresçam com o projeto.
DESENVOLVIMENTO DA EQUIPE DO PROJETO
Segundo o Guia PMBOK, o processo de desenvolvimento da equipe do projeto

prevê melhorar as competências e a interação de membros da equipe para apri-
morar o desempenho do projeto.
É de se esperar que, no início do projeto, o grupo passe por algumas fases
de comportamento com notória expressividade, sob a coordenação do gerente
de projeto. Dentre as principais ferramentas e técnicas utilizadas nesse proces-
so, podemos citar: análise das habilidades individuais; elaboração de políticas de
treinamento; coordenação de atividades de construção de equipes; definição das
expectativas estabelecidas pelo gerente e pela equipe de projeto, descrevendo
o comportamento aceitável da equipe; agrupamento físico dos integrantes da
equipe; e definição de uma política clara de reconhecimento e recompensas para
os integrantes da equipe.
156
GERENCIAMENTO DA EQUIPE DO PROJETO
Segundo Heldman (2009), o gerenciamento da equipe de projeto preocupa-se

com o acompanhamento e o relato do desempenho de cada um dos integrantes
da equipe. Nesse processo, o gerente do projeto prepara e conduz as avaliações
de desempenho, identifica e resolve os problemas e fornece feedback aos mem-
bros da equipe. Alguns comportamentos também são observados durante esse
processo, mas o foco principal está nos indivíduos e em seu desempenho.
A maioria das ferramentas e técnicas utilizadas para condução desse processo
é nova. Dentre elas podemos citar: observações e conversas; avaliações de de-
sempenho do projeto; gerenciamento de conflitos; registro das questões; e habi-
lidade interpessoais.
Segundo o PMBOK, uma das consequências do processo de gerenciamento
da equipe é uma atualização do Plano de Recursos Humanos, uma das principais
saídas do gerenciamento dos recursos humanos.
Neste tópico, você aprendeu que o gerenciamento dos recursos humanos do
projeto possibilita que as pessoas envolvidas sejam utilizadas da melhor maneira
e, para que o projeto seja bem executado, é importante manter a equipe motiva-
da. Além disso, você viu que o desenvolvimento da equipe melhora a interação
entre o grupo e aprimora o andamento do projeto.
4.15 GERENCIAMENTO DA QUALIDADE DO PROJETO
A qualidade de um projeto se define pela conformidade com os requisitos pre-

estabelecidos desse projeto e deve ser uma constante em todos os processos do
gerenciamento. Então, a preparação da equipe começa com a compreensão do
conceito de qualidade, que há alguns anos esteve ligado à inspeção, mas que,
com o passar do tempo e a melhoria dos métodos de gestão, voltou-se para o
planejamento, possibilitando a prevenção de falhas e de não conformidades.
Neste tópico, você vai ver quais são os processos de gerenciamento da quali-
dade, depois vai aprender como planejar a qualidade e como se realiza a garantia
e o controle da qualidade.
CONCEITO DE GERENCIAMENTO DA QUALIDADE
O gerenciamento da qualidade busca assegurar que o projeto atenda aos re-

quisitos com os quais se comprometeu, concentrando-se na qualidade do pro-
duto e dos processos de gerenciamento empregados no ciclo de vida do projeto,
os quais avaliam o desempenho geral, monitoram os resultados do projeto e os
157
comparam com os padrões de qualidade estabelecidos no processo de plane-

jamento para garantir que o cliente receba o produto ou serviço que comprou
(HELDMAN, 2009).
Segundo o PMBOK, o gerenciamento da qualidade envolve:
a) planejamento da qualidade;
b) garantia da qualidade;
c) controle da qualidade.
PLANEJAMENTO DA QUALIDADE
Determina que procedimentos de qualidade devem ser adotados no projeto e

de que maneira serão implementados e gerenciados.
Muitas vezes, a organização já possui um sistema da qualidade (como ISO
9000, por exemplo) com o qual, nesses casos, o planejamento da qualidade deve
estar alinhado. Seu objetivo é identificar os padrões de qualidade relevantes ao
projeto e a forma como eles devem ser satisfeitos, por meio da participação no
planejamento global do projeto.
Nesse escopo, entram tanto os padrões de qualidade – que podem ser cha-
mados de “voluntários” – como os padrões de qualidade definidos por normas e
legislação, os quais serão requeridos conforme a finalidade ou produto final do
projeto, e questões do ambiente interno e externo das organizações envolvidas.
Dessa forma, o processo de planejamento explicita as ações dos processos de
garantia e controle da qualidade.
GARANTIA DA QUALIDADE
É um processo pró-ativo que implementa a ideia de que, antes de detectar o

defeito, é necessário evitá-lo. Assim, como a ideia é obter qualidade – não pela
detecção do defeito, mas por fazer o correto logo da primeira vez –, a garantia de
qualidade acrescenta atividades ao processo para garantir que sua elaboração
seja imune a determinada gama de erros comuns.
CONTROLE DA QUALIDADE
Conjunto das atividades de verificação que, em qualquer ponto do processo

de desenvolvimento, avalia se o produto ou serviço produzido é tecnicamente
158
consistente e está conforme a especificação produzida na fase de planejamento.

Alguns exemplos de ferramentas da qualidade são:
a) estratificação;
b) folha de verificação;
c) gráfico de Pareto;
d) diagrama de Ishikawa (ou espinha de peixe ou de causa e efeito);
e) diagrama de correlação;
f) gistograma;
g) carta de controle.
SAIBA Obtenha mais informações sobre métodos de controle e

qualidade no livro Gerência de projetos, de Kim Heldman
MAIS (2009).
PDCA
Do inglês Plan, Do, Check and Act (Planejar, Fazer, Checar e Agir), trata-se de um
método amplamente aplicado para o controle eficaz e confiável das atividades de
uma organização – principalmente as relacionadas a melhorias –, possibilitando
a padronização nas informações do controle de qualidade e a diminuição da pro-
babilidade de erros nas análises ao tornar as informações mais compreensíveis.
Após a realização da investigação das causas das falhas ou desvios no pro-
cesso, deve-se repetir ou aplicar o ciclo PDCA para corrigir as falhas (através do
mesmo modelo, planejar as ações, fazer, checar e corrigir), de forma a melhorar
cada vez mais o sistema e o método de trabalho.
O CICLO PDCA
O primeiro passo para a aplicação do PDCA é a elaboração de um plano, que

deverá ser estabelecido com base nas diretrizes do projeto. A boa elaboração des-
se plano evita falhas e perdas de tempo desnecessárias nas próximas fases do ciclo.
O segundo passo é a execução do plano: treinamento dos envolvidos no mé-
todo a ser empregado, na execução propriamente dita e na coleta de dados para
posterior análise.
159
O terceiro é passo é a análise ou verificação dos resultados alcançados e dos

dados coletados.
A última fase é a realização das ações corretivas, ou seja: correção das falhas
encontradas no passo anterior.
A Ação:
Definir
Meta P
Corretiva
Preventiva Definir
Melhoria Método
Educar e
Checar: Treinar
METAS
X Executar
C D
RESULTADOS Denis Pacher (2012)
Coletar
Dados
Figura 48 - Ciclo PDCA
As ferramentas utilizadas para controle da qualidade do

VOCÊ projeto são conhecidas como “As sete ferramentas de
qualidade básicas de Ishikawa”. Kaoru Ishikawa é mais
SABIA? conhecido pela criação do famoso diagrama de Ishika-
wa, ou “espinha de peixe”.
Neste tópico, você aprendeu que a busca pela qualidade deve estar presente
em todos os processos de gerenciamento do projeto. Depois, viu as ações uti-
lizadas para garantir a qualidade do projeto e aprendeu que o PDCA é um dos
métodos mais utilizados para o controle da qualidade.
4.16 ESTRUTURAS ORGANIZACIONAIS
É possível aplicar os conhecimentos adquiridos e gerenciar projetos em qual-

quer tipo de organização? Sim. Entretanto, a forma de gerenciar projetos varia de
acordo com o tipo de organização da empresa. Há empresas funcionais, onde as
atividades são centradas em especializações agrupadas por função; há empresas
projetizadas, cuja organização é feita em função de projetos; e há organizações
160
matriciais, que surgiram para minimizar as diferenças entre os pontos fortes e fra-
cos das empresas funcionais e das estruturadas.
O tipo de organização da empresa influencia diretamente no modo como o
trabalho do projeto é conduzido. Neste tópico, você vai aprender um pouco mais
sobre as estruturas organizacionais das empresas, como elas se classificam e de-
talhes sobre essas classificações.
SOBRE AS ESTRUTURAS ORGANIZACIONAIS
Na visão de Heldman (2009), assim como cada projeto é único, as empresas

em que os projetos são executados também. Elas possuem estilo e cultura pró-
prios, que influenciam no modo como o trabalho do projeto é conduzido.
O que determina o tipo de estrutura organizacional da empresa é a autoridade
que a alta diretoria delega aos gerentes de projeto. Empresas cujo gerente de
projeto tem pouca ou nenhuma autoridade oficial, por exemplo, geralmente pri-
vilegiam as funções empresariais; logo, é comum chamá-las de empresas funcio-
nais. Quando ocorre ao contrário, são conhecidas como empresas projetizadas.
Ambas as classificações possuem pontos fortes e fracos. Para balanceá-los, sur-
giram as empresas matriciais.
EMPRESAS FUNCIONAIS
Organizações funcionais representam o tipo mais comum de empresa. Trata-

-se, provavelmente, do estilo mais antigo de organização e, por isso, é conhecido
como método tradicional de organização de empresas.
Geralmente, essas empresas são centradas em especialistas e agrupadas em
funções, por isso o nome de organizações “funcionais”. Exemplos de função são:
recursos humanos (RH), finanças, tecnologia da informação (TI) etc. A estas fun-
ções geralmente dá-se o nome de departamentos (ou áreas, divisões, setores etc.).
O trabalho nesses departamentos é especializado e exige pessoas com um
conjunto de habilidades e experiências nessas funções especializadas para rea-
lizar tarefas específicas do departamento. A figura 2 ilustra um exemplo de orga-
nograma de uma empresa funcional.
161
Gerência
RH Finanças Marketing TI Produção
Pessoal Pessoal Pessoal Pessoal Pessoal
Denis Pacher (2012)

Figura 49 - Organograma funcional

Fonte: Adaptado de HELDMAN (2009)
Um das principais dificuldades enfrentadas pelos gerentes de projeto nesse

tipo de organização é que eles, geralmente, têm muito pouca ou nenhuma autori-
dade oficial, delegada pela alta gerência da empresa. Isso ocorre pela organização
lógica da empresa e exige dos gerentes habilidades de comunicação acima da
média, bom relacionamento interpessoal e capacidade de influenciar as pessoas.
Para amenizar o problema, é muito importante que o gerente de projeto conte
com o apoio (ou trabalhe junto) com os gerentes funcionais envolvidos no proje-
to. Isso permite o compartilhamento das responsabilidades em benefício da exe-
cução do projeto.
EMPRESAS PROJETIZADAS
Empresas projetizadas representam o oposto das empresas funcionais. O en-

foque desse tipo de organização são os projetos. A ideia é dar ênfase aos projetos,
não às funções.
A próxima figura mostra o exemplo de um organograma de uma empresa pro-
jetizada. A figura, quando comparada à figura 2, ilustra as diferenças na estrutura
organizacional entre ambos os tipos de empresa.
162
Gerência
Gerente de Gerente de Gerente de Gerente de Gerente de

Projeto Projeto Projeto Projeto Projeto
Equipe do Equipe do Equipe do Equipe do Equipe do
Denis Pacher (2012)

Projeto Projeto Projeto Projeto Projeto
Membros/ Membros/ Membros/ Membros/ Membros/
Figura 50 - Organograma projetizado

Heldman (2009) destaca:
nas organizações estruturadas exclusivamente por projetos, os

recursos organizacionais são dedicados aos projetos e suas me-
tas. Quase sempre, os gerentes de projeto têm total autoridade
sobre o projeto e são subordinados diretamente aos diretores
da empresa, sem intermediários. Neste tipo de organização,
as funções de apoio, como recursos humanos e contabilidade,
também podem responder diretamente aos gerentes de pro-
jeto. Estes são responsáveis pela tomada de decisões em rela-
ção aos projetos e à aquisição e alocação de recursos. Eles têm
autoridade para escolher e alocar recursos de outras áreas da
organização ou para contratar recursos externos, se necessário.
E agora? Qual é o modelo organizacional ideal: funcional ou projetizada? An-

tes de responder a essa pergunta vamos conhecer um terceiro modelo: a empre-
sa matricial.
EMPRESAS MATRICIAIS
Empresas matriciais surgiram para minimizar as diferenças entre os pontos for-

tes e os fracos das organizações funcionais e das projetizadas. A ideia é obter o
melhor de cada um dos modelos, combinando-os em um só. O objetivo é atender
às necessidades dos gerentes de projeto, ao mesmo tempo que também se man-
tém a estrutura hierárquica funcional da organização.
Nesse tipo de empresa, os funcionários se reportam ao gerente funcional e a,
no mínimo, um gerente de projeto. Caso trabalhem em vários projetos simulta-
neamente, eles podem ser subordinados a vários gerentes de projeto. O gerente
163
funcional, por sua vez, responde por atividades administrativas, aloca funcioná-
rios para os projetos e monitora o trabalho desses funcionários. Já o gerente de
projeto é responsável pela execução do projeto e distribuição das tarefas de acor-
do com as atividades previstas. Ambos dividem a responsabilidade pelas avalia-
ções de desempenho dos funcionários.
A figura 4 mostra um exemplo de organograma de empresa matricial.
Gerência
Gerentes Finanças Marketing TI Produção
Gerente de
Pessoal Pessoal Pessoal Pessoal
Projeto
Denis Pacher (2012)

Gerente de
Pessoal Pessoal Pessoal Pessoal
Projeto
Figura 51 - Organograma matricial

Nas organizações matriciais há muita comunicação e

VOCÊ negociação entre o gerente de projeto e o gerente fun-
SABIA? cional. Isso requer certo equilíbrio de poder entre os
dois. Se não for assim, um tende a dominar o outro.
Neste tópico, você aprendeu que existem três estruturas organizacionais de

empresas: funcional, projetizada e matricial. Aprendeu sobre as características
inerentes a cada tipo, suas diferenças, pontos fortes e fracos.
4.17 ANÁLISE DE VIABILIDADE DO PROJETO
Depois que um projeto é pensado, o próximo passo é a sua iniciação. Você já

sabe que para iniciar um projeto deve-se definir seu escopo e criar o seu termo
de abertura. Mas o que mais poderia existir entra a ideia de um projeto e sua ini-
ciação?
Não é difícil imaginar que, antes de um projeto ser iniciado, é preciso saber
se ele é viável, ou seja, se é possível executá-lo, considerando custos, tempo e os
recursos. Essa análise é conhecida como estudo de viabilidade do projeto e seu
164
principal objetivo é servir como parâmetro para que se decida sobre a execução
ou não de um projeto.
Neste tópico, você vai entender a importância dos estudos de viabilidade,
como é o processo de seleção e priorização de projetos, e também vai aprender
sobre metodologias de seleção de projetos.
OBJETIVOS DOS ESTUDOS DE VIABILIDADE
Heldman (2009) afirma que os estudos de viabilidade são realizados por vários
motivos. Um deles é verificar se o projeto é viável ou não. Uma segunda razão é
analisar a sua probabilidade de êxito. Estudos de viabilidade também podem exa-
minar a viabilidade de um produto, serviço ou resultado do projeto. Por exemplo,
antes de lançar um novo produto no mercado, pode ser necessário realizar um es-
tudo que indique qual será a aceitação desse produto. Também podem ser analisa-
das questões técnicas relacionadas ao projeto, verificando se sua tecnologia suge-
rida é viável, confiável e fácil de incorporar à estrutura tecnológica da organização.
É importante garantir que a equipe que realizará o estudo de viabilidade não
seja a mesma que trabalhará no projeto, pois os integrantes da equipe de projeto
podem já ter suas preferências pessoais, em função das quais tenderão a influen-
ciar no resultado do estudo.
Como é feita a seleção e priorização dos projetos considerados viáveis?
SELEÇÃO E PRIORIZAÇÃO DE PROJETOS
Métodos de seleção de projetos ajudam as organizações a decidirem entre

diversos projetos e determinam os benefícios tangíveis (que podem ser medidos,
alcançados) para que a empresa opte ou não por um projeto.
Há vários critérios de seleção, que variam de acordo com a realidade de cada
empresa. Questões financeiras, de mercado, políticas, entre outras, são os princi-
pais fatores que influenciam na seleção de um projeto. Geralmente a combinação
desses fatores tem maior influência na seleção dos projetos.
Um exemplo de processo de seleção de projetos é descrito por Heldman (2009):
Na minha organização existe um comitê gestor responsável

pela análise, seleção e atribuição de prioridades a projetos. O
comitê é composto por gerentes seniores que representam
cada uma das áreas funcionais da organização. O processo fun-
165
ciona da seguinte forma: o comitê gestor solicita ideias para

projetos aos funcionários da empresa antes do início do ano.
Essa documentação contém as metas do projeto, uma descri-
ção das entregas, sua justificativa de negócios, uma data dese-
jada de implementação, o que a organização espera ganhar,
uma lista de áreas funcionais da empresa afetadas pelo pro-
jeto e, se for o caso, uma análise custo-benefício. É marcada
uma reunião do comitê gestor para analisar os projetos e defi-
nir quais serão incluídos na lista de projetos do ano seguinte.
Os projetos recusados são deixados de lado e os demais são
ordenados conforme a importância e benefício para a organi-
zação. Os projetos são documentados em uma lista oficial e o
andamento dos que estiverem ativos é informado nas reuni-
ões mensais regulares do comitê gestor.
Existem vários métodos de análise e seleção de projetos. Entre os mais conhe-

cidos estão a análise custo-benefício, os modelos de pontuação e a análise do
período de retorno.
ANÁLISE CUSTO-BENEFÍCIO
Esse método é bastante conhecido e seu principal objetivo é comparar o cus-

to da produção de um produto, serviço ou resultado de um projeto, com o seu
benefício, geralmente medido em valores monetários na forma de economias ou
receitas. Em outras palavras, benefício é aquilo que a organização receberá como
resultado da execução do projeto.
Obviamente, o estudo de viabilidade de um projeto baseado em uma análise
custo-benefício bem fundamentada é aquele em que os custos de implementa-
ção ou geração do produto em pauta são menores que os benefícios financeiros.
É importante ressaltar que a avaliação dos custos, nesse tipo de análise, deve
compreender os custos de geração do produto ou serviço, da introdução do pro-
duto no mercado, quando for o caso, e de suporte ao produto.
A análise custo-benefício também é conhecida como

VOCÊ análise benefício-custo. As técnicas são as mesmas, mas
o termo benefício-custo tem uma conotação mais posi-
SABIA? tiva porque mostra o benefício (aspecto bom) antes do
custo (aspecto ruim).
166
MODELOS DE PONTUAÇÃO
Outra técnica de seleção de projetos da categoria de mensuração de benefí-

cios é o modelo de pontuação ou modelo de pontuação ponderada. Essa técnica,
considerada relativamente simples, é baseada na especificação dos critérios de
seleção que serão utilizados no modelo de pontuação. Exemplos de critérios são:
potencial de lucro do produto ou serviço, potencial de comercialização, capacida-
de da empresa em gerar o produto com rapidez a agilidade, entre outros. A cada
critério é atribuído um peso, que determina a importância daquele critério no
contexto, sendo que os mais relevantes recebem peso maior.
Na tabela a seguir, cada projeto é classificado em uma escala de 1 a 5 (ou simi-
lar), em que o maior valor corresponde ao resultado mais desejável para a empre-
sa e vice-versa. Essa classificação é multiplicada pelo peso de cada critério e adi-
cionada a outras pontuações ponderadas para se chegar à pontuação ponderada
total. Observe o exemplo na tabela abaixo.
Tabela 1 - Modelos de pontuação
Facilidade
Potencial Potencial de Pontuação
Critérios de
de Lucros Comercialização Ponderada
Produção
Peso 5 3 1
Pontuação 5 4 4
Projeto A
Total 25 12 4 41
Projeto A
Pontuação
Projeto B
5 3 3
Total
Projeto B
25 9 3 37
Pontuação
Projeto C
3 4 2
Total
Projeto C
15 12 3
PERÍODO DE RETORNO
O período de retorno é o tempo necessário para uma empresa recuperar os

custos iniciais de geração do produto ou serviço do projeto. Neste método, com-
para-se o investimento inicial com as entradas de caixa esperadas durante a vida
do produto, serviço ou resultado.
167
Por exemplo, suponhamos que o investimento inicial de um projeto seja de

R$ 200.000,00, com entradas esperada de caixa no valor de R$ 25.000,00 por tri-
mestre nos dois primeiros anos e de R$ 50.000,00 daí para a frente. O período de
retorno neste caso é de dois anos e pode ser calculado da seguinte forma:
Investimento inicial: R$ 200.000,00

Entradas de caixa: R$ 25.000,00 x 4 (Ano 1) + R$ 25.000,00 x 4 (Ano 2)
Total de entradas de caixa em dois anos: R$ 200.000,00
Logo, o retorno sobre o investimento ocorre em dois anos, daí para a frente é lucro.
A técnica de análise de período de retorno difere das técnicas de análise cus-
to-benefício e de modelos de pontuação porque se enquadra na categoria de
técnicas conhecidas como técnicas de análise de fluxo de caixa. Você pode ter
mais informações sobre esse tipo de técnica no livro Gerência de projetos, de Kim
Heldman (2009).
Na análise de viabilidade e seleção de projetos podem

VOCÊ ser utilizados um ou mais métodos combinados. Assim
SABIA? como um mesmo método pode ser utilizado para avaliar
múltiplos projetos ou apenas um.
Neste tópico, você aprendeu que é necessário realizar estudos de viabilidade

para saber se um projeto deve ser realizado ou não. Você aprendeu ainda como é
o processo de seleção e priorização de projetos, e como funciona a análise custo-
-benefício, os modelos de pontuação e a análise do período de retorno.
4.18 ENCERRAMENTO DO PROJETO

Dreamstime (2012)
Figura 52 - Encerramento
168
O projeto foi concluído. E agora? Podemos simplesmente considerar as ativi-

dades encerradas, deslocar recursos para outros projetos e diminuir ou desmobi-
lizar as equipes? A resposta é: não. Há muito que aprender com o encerramento
dos projetos. Além disso, temos que tratar a questão da aceitação do resultado do
projeto pelo cliente e registrar as lições aprendidas.
Neste tópico, você vai aprender o que é o encerramento do projeto, quais são
as atividades de encerramento interno e externo ao projeto, como ocorre o en-
cerramento administrativo e de contratos com terceiros, o que é aceitação formal
do projeto e como registrar as lições aprendidas.
O QUE É ENCERRAMENTO DO PROJETO?
Segundo Menezes (2009), encerrar um projeto significa finalizar os contra-

tos estabelecidos com terceiros, avaliar com o cliente se o escopo do projeto foi
cumprido (se os objetivos do projeto foram alcançados), obtendo deste um “de
acordo” em tudo o que lhe foi entregue, e conduzir todo o fechamento interno e
externo do projeto.
Além disso, esse é o momento de olhar para trás e verificar tudo o que foi po-
sitivo e o que foi negativo no projeto, para que se possa registrar e aprender com
as lições do projeto e não repetir mais os erros, mas concretizar boas práticas em
futuros projetos.
ENCERRAMENTO INTERNO E EXTERNO DO PROJETO
O processo de encerramento interno e externo do projeto envolve basicamen-

te as seguintes atividades: encerramento administrativo e de contrato com ter-
ceiros, aceitação formal do produto do projeto e registro das lições aprendidas.
Todos os conceitos abaixo foram adaptados do livro Gestão de projetos, de Luiz
César Menezes (2009).
ENCERRAMENTO ADMINISTRATIVO E DE CONTRATO COM TERCEIROS
No plano interno do projeto, deve ser verificado se existem produtos penden-

tes, se as certificações internas foram assinadas e recebidas, se existem compro-
metimentos internos pendentes, se todos os custos foram apropriadamente co-
brados do projeto, se todas as unidades de trabalho e pedidos foram concluídos,
se as unidades de trabalho incompletas foram documentadas e justificadas, se a
gerência foi notificada quanto à disponibilidade de pessoal do projeto e quanto
169
à disponibilidade das instalações do projeto, se o plano de projeto foi arquivado

com todos os dados de suporte e se os excedentes de material do projeto foram
administrados.
Externamente ao projeto, deve ser verificado se foi obtido acordo com o pro-
prietário do projeto sobre a disposição dos produtos restantes, se as certificações
e autorizações externas foram assinadas e aprovadas, se os fornecedores foram
notificados quanto a compromissos pendentes, se todas as partes estão cientes
do encerramento pendente, se as instalações do projeto foram fechadas e se os
procedimentos de auditoria e manutenção foram conduzidos.
Em relação ao pessoal do projeto, internamente deve-se verificar se as preocu-
pações da equipe de projeto referentes a empregos futuros foram abordadas, se
a equipe está dedicada a manter os compromissos restantes do projeto, se ainda
existem fatores de motivação presentes para tarefas e obrigações restantes, se as
preocupações referentes à identidade da equipe foram abordadas, e o pessoal foi
recolocado ou notificado da metodologia de realocação.
Finalmente, ainda em relação ao pessoal do projeto, externamente deve-se
verificar se estão sendo feitos esforços para assegurar que o interesse do contra-
tado permaneça atendido, se estão sendo feitos esforços para assegurar que as
atitudes e percepções do contratante referentes ao projeto permaneçam está-
veis, se as questões de transferência de pessoal estão sendo abordadas com os
contratantes do projeto, se o pessoal-chave e o contratante estão sendo notifi-
cados sobre o status do projeto e se existe uma metodologia de comunicação
para manter as relações entre os contratantes e os gerentes do projeto (seu e do
contratado).
ACEITAÇÃO FORMAL
Ao final do projeto deve ser gerado um documento no qual o cliente ou pa-

trocinador do projeto atesta a aceitação do seu produto. Nos casos em que o pro-
duto do projeto é muito “grande”, este pode ser subdividido em vários produtos
visando facilitar o trabalho e aceitação formal do cliente. Desta forma, o processo
de aceitação formal pode ser conduzido durante a execução do projeto e não
apenas no seu final.
LIÇÕES APRENDIDAS
O documento de lições aprendidas deve conter, dentre outros itens, a análise

de erros cometidos no gerenciamento de prazo, de custo, de qualidade, escopo e
risco. Também devem ser registrados os acertos do projeto.
170
Existem reuniões durante a execução do projeto e du-

VOCÊ rante seu encerramento cujo objetivo é avaliar as lições
SABIA? aprendidas. Essas reuniões são conhecidas como Lear-
ning Meetings.
AVALIAÇÃO FINAL DO PROJETO
Após os encerramentos formais do projeto, o aceite do cliente e o registro das

lições aprendidas, Menezes (2009) cita que deve ser gerada uma documentação
final do projeto, que por sua vez deve conter o seguintes itens:
a) avaliação dos documentos utilizados no acompanhamento do projeto;
b) avaliação do processo de gerenciamento do projeto: reuniões, trabalhos
etc.;
c) quantificação e alcance dos objetivos;
d) riscos: como foram geridos, investimentos realizados e benefícios colhidos;
e) custos do projeto;
f) equipe: formação, mudanças, relacionamentos, envolvimentos e compro-
metimentos;
g) técnico: ações e documentos que contribuíram com o projeto, processos
utilizados, desenvolvidos ou aperfeiçoados;
h) tecnológico: aquisição ou desenvolvimento de novos conhecimentos;
i) todos os documentos legais necessários.
Esses itens devem estar contidos em um único documento, seja fisicamente
ou eletronicamente, para ser utilizado como referência em projetos futuros.
Finalmente, deve ser realizada uma reunião de encerramento (close-out
meeting), na qual os principais resultados possam ser apresentados, além de um
resumo das lições aprendidas, e destaques e agradecimentos possam ser feitos a
todos os membros da equipe de projeto.
Neste tópico, você aprendeu sobre o encerramento de um projeto. Agora,
você já sabe quais são as atividades de encerramento interno e externo ao pro-
jeto, como ocorre o encerramento administrativo e de contratos com terceiros, o
que é aceitação formal do projeto e como registrar as lições aprendidas.
171
Recapitulando
Neste capítulo você aprendeu o que é um projeto e como gerenciá-lo.

Conheceu quais as habilidades necessárias para se gerenciar projetos
voltados à área de TI, seja para elaboração de orçamentos, resolução de
conflitos, negociação, formação ou motivação de equipes.
Também aprendeu conceitos de gerenciamento, como integração, esco-
po, tempo, custos, comunicações, riscos, recursos humanos e qualidade
dos projetos, e aprendeu a definir viabilidades de projetos e o encerra-
mento deles.
Aqui você viu definições de estruturas organizacionais, levando em con-
sideração que o tipo de organização de uma empresa influencia direta-
mente no modo como o trabalho do projeto é conduzido.
REFERÊNCIAS
ABNT/CNI/SEBRAE. Manual ISO 9000 para micro e pequenas empresas. Rio de Janeiro: ABNT/
CNI/SEBRAE, 1997.
ABNT. ISO/IEC 27001:2005: Tecnologia da Informação – Técnicas de segurança – Sistemas de

gestão de segurança da informação – Requisitos. Rio de Janeiro: Associação Brasileira de Normas
Técnicas, 2006.
BRAGA, B. Introdução à engenharia ambiental. 2. ed. São Paulo: Prentice Hall, 2005.
CHIAVENATO, Idalberto. Administração: teoria, processos e prática. 4. ed. Rio de Janeiro: Campus,
2007.
______. Gestão de pessoas: o novo papel dos recursos humanos das organizações. 3. ed. Rio de
Janeiro: Elsevier, 2010.
______. Introdução à teoria geral da administração. 7. ed. Rio de Janeiro: Campus, 2003.
______. Recursos humanos: o capital humano nas organizações. 8. ed. São Paulo: Atlas, 2006.
FERREIRA, A. B. H. Novo dicionário eletrônico Aurélio. 5. ed. Curitiba: Positivo Informática, 2004.
FREITAS, M. A. S. Fundamentos de gerenciamento de serviços de TI: Preparatório para a

Certificação ITIL V3 Foundation. Rio de Janeiro: BRASPORT, 2010.
GITMAN, Lawrence. Princípios da administração financeira. São Paulo: Habra, 1997.
HELDMAN, Kim. Gerência de projetos: guia para o exame oficial do PMI. 5. ed. Rio de Janeiro:
Elsevier, 2009.
IMAI, M. Kaizen: A estratégia para o sucesso competitivo. 5. ed. São Paulo: IMAM, 1994.
LISBOA, Patrícia. Como adaptar sua empresa ao conceito de TI sustentável. In: PC World, Dicas, 22
dez. 2009. Disponível em: <pcworld.uol.com.br/dicas/2009/12/22/como-adaptar-sua-empresa-ao-
conceito-de-ti-sustentavel/>. Acesso em: 23 fev. 2012.
MENEZES, Luiz César de Moura. Gestão de projetos. 3. ed. São Paulo: Atlas, 2009.
MILKOVICH, G.; BOUDREAU, J. Administração de recursos humanos. São Paulo: Atlas, 2006.
MORCERF, Sônia de Oliveira; VILAS BOAS, José Aurélio; FERREIRA, José Cláudio; SAID, Ricardo Alves;
SEABRA, Teresa Cristina. Gestão por competências: um estudo de caso. In: III SEGeT – Simpósio
de Excelência em Gestão e Tecnologia. Disponível em: <www.aedb.br/seget/artigos06/669_
GESTAO%20DE%20COMPETENCIAS%20-%20DOM%20BOSCO.pdf>. Acesso em: 4 abr. 2012.
OGC. ITIL: Continual Service Improvement. Londres: TSO, 2007.

OSADA, Takashi. Housekeeping 5S: cinco pontos-chave para o ambiente da Qualidade Total. 3.
ed. Rio de Janeiro: IMAM, 2010.
SILVA, J. M. O ambiente da qualidade na prática – 5S. Belo Horizonte: Fundação Christiano

Ottoni, 1996.
TRIBUNAL DE CONTAS DA UNIÃO. Boas práticas em segurança da informação. 3. ed. Brasília:

TCU, 2008.
VALLE, C. Qualidade ambiental: ISO 14000. 5. ed. São Paulo: SENAC, 2004.
VIEIRA, Marconi Fábio. Gerenciamento de projetos: de Tecnologia da Informação. 5. ed. Rio de

Janeiro: Elsevier, 2003.
MINICURRÍCULO Do AUTOr
Edison Andrade Martins Morais é Analista de Sistemas do Tribunal de Justiça do Estado de Goi-
ás, Professor Assistente II 20h do Instituto de Informática (INF) da Universidade Federal de Goiás
(UFG) e Professor Adjunto da Faculdade de Tecnologia SENAC Goiás. Possui mestrado em Ciência
da Computação pela UFG (2007), especialização em Análise e Projeto de Sistemas de Informação
pela UFG (2003), e graduação em Processamento de Dados pelo IUESO (1996). Tem experiência
como docente em graduação e pós-graduação presencial desde 2003, pós-graduação na modali-
dade EAD desde 2010, e experiência na área de Tecnologia da Informação desde 1997, com ênfa-
se em Governança em TI, Engenharia de Software, e Análise e Projeto de Sistemas de Informação,
Banco de Dados e Desenvolvimento de Software.
Índice
A
Alienação 148
F
Fluxo de caixa 140
G
Gap 30
M
Modus operandi 24
P
Portfólio 32
Probidade administrativa 146
SENAI – Departamento Nacional
Unidade de Educação Profissional e Tecnológica – UNIEP
Rolando Vargas Vallejos

Gerente Executivo
Felipe Esteves Morgado

Gerente Executivo Adjunto
Diana Neri
Coordenação Geral do Desenvolvimento dos Livros
SENAI – Departamento Regional de GOIÁS
Ariana Ramos Massensini

Coordenação do Desenvolvimento dos Livros no Departamento Regional
Camila Lückmann
Silvio Rodrigo de Lima
Elaboração
Cláudio Martins Garcia

Revisão Técnica
FabriCO
Aline Pimentel
Helena Gouveia
Design Educacional
Bárbara da Silveira
Revisão Ortográfica e Gramatical
Denis Pacher
Odirlei Batista
Ilustrações
Thiago Rocha
Denis Pacher
Tratamento de imagens
Laura Martins Rodrigues

Diagramação
i-Comunicação
Projeto Gráfico

GerenciamentoServicosTI FINAL BAIXA PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

GerenciamentoServicosTI FINAL BAIXA PDF

Caricato da

Copyright:

Formati disponibili

Série TECNOLOGIA DA INFORMAÇÃO - hardware

Robson Braga de Andrade

DIRETORIA DE EDUCAÇÃO E TECNOLOGIA - DIRET

Rafael Esmeraldo Lucchesi Ramacciotti

SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL – SENAI

Robson Braga de Andrade

SENAI – Departamento Nacional

Rafael Esmeraldo Lucchesi Ramacciotti

Gustavo Leal Sales Filho

© 2012. SENAI – Departamento Regional de Goiás

SENAI Departamento Nacional

SENAI Departamento Regional de Goiás

1. Suporte técnico. 2. Tecnologia da informação. 3. Planejamento de

I. Autor. II. Título.

Serviço Nacional de Setor Bancário Norte • Quadra 1 • Bloco C • Edifício Roberto

Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática........................13

Tabela 1 - Modelos de pontuação............................................................................................................................. 166

2 Suporte e visita técnica................................................................................................................................................15

4 Gestão de projetos...................................................................................................................................................... 113

Minicurrículo do autor................................................................................................................................................... 175

Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática

CARGA CARGA HORÁRIA

Fundamentos para Documentação Técnica 140h

Arquitetura e Montagem de Computadores 160h

Específico I Segurança de Dados 50h 880h

Gerenciamento de Serviços de TI 80h

Tendências e Demandas Tecnológicas em TI 60h

O profissional de TI responsável pelo suporte técnico cuida da manutenção da estrutura

2.1 BOAS PRÁTICAS ASSOCIADAS AO GERENCIAMENTO DE SERVIÇOS DE TI

Você já ouviu falar em boas práticas de gerenciamento de serviços na área de

A ITIL (Information Technology Infrastructure Library – Biblioteca de Infraestru-

Informação). O GITM tinha como objetivo atender a uma crescente dependência

COBIT (Control Objectives for Information and Related Technology) é um modelo

Também é importante conhecer os domínios do COBIT, que são: planejamen-

s: A t rols and Proce ss M t u

Odirlei Batista (2012)

SAIBA Acesse <http://www.itil-officialsite.com> para obter mais in-

Gerenciar a entrega de serviços na área de Tecnologia da Informação é uma

2.2 ITIL NO AMBIENTE DE SERVIÇOS DE SUPORTE DE TI

Denis Pacher (2012)

Além de conhecer as recomendações das boas práticas de gerenciamento de

Serviço é um meio de entregar valor ao cliente, é a forma pela qual o cliente vê

É o conjunto de habilidades (capabilities) que, associadas a seus recursos (re-

Figura 5 - Ciclo de vida de serviço

Odirlei Batista (2012)

Durante essa fase, o valor do serviço é identificado e modelado. Segundo Frei-

Odirlei Batista (2012)

Figura 7 - Desenho de serviço

Nesta etapa são projetados e modelados os serviços, e todos os seus recursos

Odirlei Batista (2012)

Figura 8 - Transição de serviço

Neste momento, o serviço e todos os seus recursos e habilidades necessários

Odirlei Batista (2012)

Figura 9 - Operação de serviço

Esta é a fase em que o serviço é mantido de modo a gerar o valor esperado

e) Melhoria de serviço continuada

Odirlei Batista (2012)

O objetivo da melhoria de serviço continuada é alinhar e realinhar continu-

2.3 PLANEJAMENTO PARA ENTREGA DOS SERVIÇOS DE SUPORTE DE TI

Antes de começar a montar o nosso plano, vamos entender o que é plane-

No processo de planejamento temos seis etapas genéricas:

No planejamento temos três níveis: estratégico, tático e operacional. Vamos

b) Tático: método ou habilidade para se colocar em prática as estratégias do