Gerenciamento de Serviços de Ti PDF

Série tecnologia da informação (TI)
GERENCIAMENTO
DE SERVIÇOS
DE TI
Série TECNOLOGIA DA INFORMAÇÃO (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
Série TECNOLOGIA DA INFORMAÇÃo (tI)
GERENCIAMENTO
DE SERVIÇOS
DE TI
© 2013. SENAI – Departamento Nacional
© 2013. 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.
184p.: il.
ISBN 978-85-7519-636-6
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 - Ciclo de vida de serviço..............................................................................................................................21
Figura 5 - Estratégia de serviço....................................................................................................................................21
Figura 6 - Desenho de serviço......................................................................................................................................22
Figura 7 - Transição de serviço.....................................................................................................................................23
Figura 8 - Operação de serviço....................................................................................................................................24
Figura 9 - Melhoria continua de serviço...................................................................................................................25
Figura 10 - Onde chegar.................................................................................................................................................29
Figura 11 - Modelo básico de planejamento..........................................................................................................29
Figura 12 - Exemplo de análise de Gap.....................................................................................................................31
Figura 13 - Portfólio de serviço....................................................................................................................................32
Figura 14 - Ciclo para definição dos serviços..........................................................................................................34
Figura 15 - Gerenciamento de demanda.................................................................................................................36
Figura 16 - Gerenciamento financeiro.......................................................................................................................39
Figura 17 - ITIL V3 – Ciclo de vida dos serviços......................................................................................................41
Figura 18 - Gerenciamento de nível de serviço......................................................................................................42
Figura 19 - Tipos de acordos.........................................................................................................................................43
Figura 20 - Gerenciamento da disponibilidade.....................................................................................................49
Figura 21 - Equilíbrio capacidade e demanda........................................................................................................58
Figura 22 - Gerenciamento da segurança da informação..................................................................................60
Figura 23 - Gerenciamento de mudanças................................................................................................................65
Figura 24 - Gerenciamento de liberação e implantação.....................................................................................68
Figura 25 - Gerenciamento do conhecimento.......................................................................................................71
Figura 26 - Gerenciamento de incidentes................................................................................................................74
Figura 27 - Processo de gerenciamento de incidentes.......................................................................................76
Figura 28 - Processo de gerenciamento de eventos............................................................................................79
Figura 29 - Processo de gerenciamento de requisições......................................................................................82
Figura 30 - Gerenciamento de problemas...............................................................................................................83
Figura 31 - Processo de gerenciamento de problemas.......................................................................................84
Figura 32 - Gerenciamento de acesso.......................................................................................................................86
Figura 33 - Melhoria continuada de serviço............................................................................................................89
Figura 34 - Otimização de recursos físicos e materiais........................................................................................96
Figura 35 - 5S......................................................................................................................................................................97
Figura 36 - Otimização de pessoas.............................................................................................................................99
Figura 37 - Alvo............................................................................................................................................................... 114
Figura 38 - Habilidades................................................................................................................................................ 117
Figura 39 - Áreas de conhecimento do gerenciamento de projetos.......................................................... 123
Figura 40 - Gerenciamento do tempo.................................................................................................................... 134
Figura 41 - Gerenciamento de custos..................................................................................................................... 138
Figura 42 - Gerenciamento das comunicações................................................................................................... 143
Figura 43 - Gerenciamento das aquisições........................................................................................................... 147
Figura 44 - Gerenciamento dos riscos.................................................................................................................... 150
Figura 45 - Ciclo PDCA.................................................................................................................................................. 160
Figura 46 - Organograma funcional........................................................................................................................ 162
Figura 47 - Organograma projetizado.................................................................................................................... 162
Figura 48 - Organograma matricial......................................................................................................................... 164
Figura 49 - Encerramento............................................................................................................................................ 168
Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática........................13

Quadro 2 - Mapeamento dos grupos de processos de gerenciamento de projetos e áreas de conhe-
cimento .............................................................................................................................................................................. 127
Quadro 3 - Identificação das responsabilidades.................................................................................................. 155
Tabela 1 - Modelos de pontuação............................................................................................................................. 167
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........................................29
2.5 Gerenciamento de portfólio de TI..........................................................................................................32
2.6 Gerenciamento de demanda...................................................................................................................36
2.7 Gerenciamento financeiro........................................................................................................................39
2.8 Gerenciamento de nível de serviço (GNS)...........................................................................................42
2.9 Gerenciamento de catálogo de serviços.............................................................................................47
2.10 Gerenciamento da disponibilidade.....................................................................................................49
2.11 Gerenciamento de continuidade de serviço de TI.........................................................................53
2.12 Gerenciamento de fornecedores.........................................................................................................56
2.13 Gerenciamento da capacidade.............................................................................................................57
2.14 Gerenciamento da segurança da informação.................................................................................60
2.15 Gerenciamento de ativo e configuração de serviço.....................................................................63
2.16 Gerenciamento de mudanças...............................................................................................................65
2.17 Gerenciamento de liberação e implantação....................................................................................68
2.18 Gerenciamento do conhecimento......................................................................................................71
2.19 Gerenciamento de incidentes...............................................................................................................74
2.20 Gerenciamento de eventos....................................................................................................................78
2.21 Gerenciamento de requisição...............................................................................................................81
2.22 Gerenciamento de problemas..............................................................................................................83
2.23 Gerenciamento de acesso......................................................................................................................86
2.24 Melhoria continuada de serviço...........................................................................................................89
3 Meio ambiente.................................................................................................................................................................95
3.1 Otimização de recursos físicos materiais.............................................................................................96
3.2 Otimização de recursos físicos humanos............................................................................................99
3.3 Otimização de recursos ambientais................................................................................................... 104
3.4 Otimização de recursos financeiros.................................................................................................... 107
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 profissional de TI gestor 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........................................................................................ 128
4.8 Gerenciamento do escopo do projeto.............................................................................................. 131
4.9 Gerenciamento do tempo do projeto............................................................................................... 134
4.10 Gerenciamento de custos do projeto.............................................................................................. 138
4.11 Gerenciamento das comunicações do projeto............................................................................ 143
4.12 Gerenciamento das aquisições do projeto.................................................................................... 147
4.13 Gerenciamento dos riscos do projeto............................................................................................. 150
4.14 Gerenciamento dos recursos humanos do projeto.................................................................... 154
4.15 Gerenciamento da qualidade do projeto...................................................................................... 157
4.16 Estruturas organizacionais.................................................................................................................. 160
4.17 Análise de viabilidade do projeto..................................................................................................... 164
4.18 Encerramento do projeto.................................................................................................................... 168
Referências......................................................................................................................................................................... 175
Referências das imagens.............................................................................................................................................. 177
Minicurrículo do autor................................................................................................................................................... 180
Índice................................................................................................................................................................................... 181
Introdução
Caro aluno, nesta unidade curricular você conhecerá a importância de um bom planejamento
para a qualidade do serviço de TI, conhecendo ferramentas e boas práticas de gerenciamento
para alcançar o desejado.
Aprenderemos como aplicar os procedimentos de otimização de recursos físicos, mate-

riais, 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 (Information Technology Infrastructure Library) ITIL – 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 Central Compu-
ter and Telecommunications Agency (CCTA), uma empresa do governo britânico.
Essa primeira versão foi chamada de Government Information Technology Infras-
tructure Method (GITM) – 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
Odirlei Batista (2012). Adaptado de Enterprise Architecture, 2011.
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
yA kW
i ds ic
Qu
Qualification
Figura 2 - ITIL
18
COBIT
Control Objectives for Information and Related Technology (COBIT) é um mode-

lo de governança de TI que foi desenvolvido pela Information Systems Audit and
Control Association (ISACA) – Associação de Auditoria e Controle de Sistemas de
Informação – e hoje é mantido pelo IT Governance Institute (ITGI).
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: planeja-

mento e organização; aquisição e implementação; entrega e suporte; e controle
e avaliaçã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
Odirlei Batista (2012). Adaptado de ISACA, 2011.

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
Va stru t rol
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 ta-

refa complexa que requer um conjunto de habilidades por parte dos profissionais
de TI, não é mesmo? Para auxiliá-los nessa tarefa, estão disponíveis no mercado
conjuntos de boas práticas. No conteúdo que acabou de ler, você conheceu as
recomendações mais utilizadas pelo mercado: a ITIL e o COBIT.
2.2 ITIL NO AMBIENTE DE SERVIÇOS DE SUPORTE DE TI
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-
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.
21
É 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
Odirlei Batista (2012). Adaptado de Guilherme Maia, 2012.

ITIL
Operação Transição
de Serviço de Serviço
Melhoria Melhoria
Continuada Continuada
Figura 4 - Ciclo de vida de serviço
a) Estratégia de serviço
Continuada
Desenho de Serviço
Odirlei Batista (2012). Adaptado de Pedro Carvalho, 2012.
Estratégia
de Serviço
Melhoria Melhoria
Figura 5 - Estratégia de serviço

22
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.
Para que os serviç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 necessi-
dades, 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.
b) Desenho de serviço
Continuada
Desenho de Serviço
Estratégia
de Serviço

Melhoria Melhoria
Figura 6 - 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:
23
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.
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
hardware deve ser especificado, ou seja, você deve definir o modus operandi1 da
área de suporte de TI.
c) Transição de serviço
Continuada
Desenho de Serviço
Estratégia
de Serviço
Melhoria Melhoria
Figura 7 - Transição de serviço

24
1 MODUS OPERANDI 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-
É uma expressão em latim
que significa “modo de ção, com o objetivo de garantir que sejam atendidos todos os requisitos planeja-
operação”. Essa expressão é dos e desenhados até aqui.
usada para se referir a uma
maneira de agir, operar ou
executar uma atividade, Esta fase do ciclo corresponde ao planejamento do projeto de implantação
seguindo sempre os dos serviços que serão suportados na fase seguinte, a de operação de serviço.
mesmos procedimentos.
d) Operação de serviço
Continuada
Desenho de Serviço
Estratégia
de Serviço

Melhoria Melhoria
Figura 8 - 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.
25
e) Melhoria de serviço continuada
Continuada
Desenho de Serviço
Estratégia
de Serviço

Melhoria Melhoria
Figura 9 - 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 gerenciamento
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.
26
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-
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
Antes de começar a montar o nosso plano, vamos entender o que é planejamento.

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, coordenadas 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 permi-
tiam 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.
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;
27
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 você, profissional da área de TI, dispõe
para atingir seus objetivos. Nessa etapa são esboçadas as alternativas para a rea-
lizaçã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;
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.
28
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 supor-
te tem como missão a realização de testes de hardware e software com qualidade.
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.
Podemos citar como exemplos 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.
SAIBA Para saber mais sobre os níveis de planejamento tático dos

serviços de Gerenciamento de TI, acesse: <http://projetoseti.
MAIS com.br/governanca/a-tatica-no-gerenciamento/>.
29
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?
2.4 AÇÕES DE PLANEJAMENTO PARA ENTREGA DOS SERVIÇOS DE

SUPORTE DE TI
Disney (2010)
Figura 10 - 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
modelo básico para a realização do planejamento, com a finalidade de alcançar
os objetivos. Em seguida veremos cada uma dessas etapas.
de Marcos Freitas,
(2012). Adaptado
Onde Onde Como chegaremos Como

Odirlei Batista
queremos estamos onde queremos saberemos se

estar? agora? estar? chegamos?
2010.
Figura 11 - Modelo básico de planejamento

30
2 GAP Segundo Ducker (1984, p. 47),
Do inglês, significa intervalo

ou distância. 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.
Confira na figura abaixo um exemplo de Análise de Gap:
31
Avaliação dos Gaps de Competências

6
5
4
Níveis
3
2
0
são
oas
os
ação
ltado
gica
iação
jetos
e
mica
o
iva
te
idad
zaçã
Odirlei Batista (2012). Adaptado de Convergir, 2012.

cess
Clien
iciat
Deci
Pess
é
unic
Sistê
e Pro
Resu
strat
egoc
riativ
i
e Pro
rgan
5 - In
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 12 - 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.
32
3 Portfólio 2.5 GERENCIAMENTO DE PORTFÓLIO DE TI

É uma lista de trabalhos de Você já ouviu falar em gerenciamento de portfólio3 de TI? É uma das princi-
um profissional ou de uma
empresa. 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 ferra-
menta que descreve os serviços que um provedor disponibiliza 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)

Odirlei Batista (2012). Adaptado de ITIL Blues, 2007.
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 13 - Portfólio de serviço

33
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;
a) 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 probabilida-
de de ocorrerem e pelo impacto no valor dos serviços. O nível de exposição de
uma empresa aos eventos de risco é conhecido como vulnerabilidade.
A grande questão a ser tratada neste ponto é: como gerenciar os riscos e tor-
nar a empresa menos vulnerável? Esse gerenciamento envolve a identifica-
ção dos riscos, o planejamento de medidas para minimizar a probabilidade
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 siste-
ma crítico da empresa; uso de novas tecnologias emergentes; falência de um
provedor de serviço externo; atendimento a leis e regulamentações; mudan-
ças nos serviços impostas pelo negócio da empresa;
e) 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 abaixo.
34
Odirlei Batista (2012). Adaptado de Breno Nunes, 2012.

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 14 - 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.
35
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 à
operação; frequência de execução; indicadores explícitos de controle; matriz de
responsabilidade.
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 conhecimento de que o gerenciamento de portfólio de
serviços é uma atividade importante no que diz respeito à elaboração da estra-
té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 definidos, analisados, aprovados e con-
tratados 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 exe-
cução do ciclo de vida: funil de serviços, catálogo de serviços e serviços obsoletos.
36
2.6 GERENCIAMENTO DE DEMANDA
Vamos pensar na seguinte situação: uma loja de vendas de produtos pela

Internet 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. Milhares 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
Odirlei Batista (2012). Adaptado de BULL, 2012.
Aprovação
Projetos
Decisões de Produtos
investimento
Figura 15 - 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?
37
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 au-
mento 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.
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).
38
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 profissional que gerencia a de-

manda:
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.
39
2.7 GERENCIAMENTO FINANCEIRO
Dreamstime, 2012.
Figura 16 - 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.
40
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
pagamento. 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. Entre-
tanto, qual será o custo com o desenvolvimento desse software?
O desenvolvimento de software é uma tarefa complexa, em que diversos pro-
fissionais, realizando diversas funções, estão envolvidos. Essa complexidade ine-
rente 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 gerenciamento financeiro

Freitas (2010) cita as seguintes atribuições do profissional que realiza o geren-
ciamento 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.
41
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
Odirlei Batista (2012). Adaptado de Luiz Siqueira, 2009.
Gerenciamento do Evento
Gerenciamento de Incidente
Gerenciamento de Problema
Cumprimento de Requisição
Gerenciamento de Acesso
Gerenciamento de Operação
Figura 17 - ITIL V3 – Ciclo de vida dos serviços

42
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 18 - 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.
43
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"
Odirlei Batista (2012)
Custos
Acordados
Figura 19 - 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 con-
templar as variáveis adequadas, contar com ferramentas e com processos que per-
mitam realizar as medições de maneira padronizada e automática. 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.
44
Também deve dispor de processos de melhoria contínua que corrijam os des-

vios que possam surgir por falhas próprias do serviço ou de mudanças no entorno
operacional.
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 profissional de TI que lida com o gerenciamento de nível de
serviço tem muitas responsabilidades. Logo, é importante que a que desempe-
nhe esse papel esteja bem preparado. Vamos entender melhor com base em um
caso prático?
45
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 profissional responsável pelo gerenciamento 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.
46
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-
ção e aprovação 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 PROFISSIONAL DE TI RESPONSÁVEL PELO

GERENCIAMENTO DE NÍVEL DE SERVIÇO
De acordo com a visão de Freitas (2010), as principais atribuições do profissio-

nal de TI responsável pelo gerenciamento 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
47
de nível de serviço (provedor interno) ou contratos de nível de serviço (for-

necedor);
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 profissional de TI res-
ponsável pelo gerenciamento de nível de serviços tem uma série de atribuições e
deve estar bem preparado 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 serviç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.
48
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.
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;
49
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;
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.

GERENCIAMENTO DE CATÁLOGO DE SERVIÇOS
Os principais papéis do profissional de TI responsável pelo gerenciamento de

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 profissional dessa área.
2.10 GERENCIAMENTO DA DISPONIBILIDADE
ATENDIMENTO
24h
Denis Pacher, 2012.
Figura 20 - Gerenciamento da disponibilidade

50
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!
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 espera-
do, o baixo desempenho 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 planejado e acordado, consideram então que o serviço está indis-
poní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 tempo médio entre falhas (TMEF ou MTBF).
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
51
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 tempo médio para reparo (TMPR). 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
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 processo 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;
52
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.
Na prática, a função do gerenciamento da disponibilidade é monitorar todos
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
Sistema de Informação de Gerenciamento da Disponibilidade (SIGD). 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ê obser-
ve que não é o profissional responsável pelo gerenciamento de disponibilidade
quem resolve os problemas. Sua função é monitorar a disponibilidade e a confia-
bilidade dos serviços de TI.
53
2.11 GERENCIAMENTO DE CONTINUIDADE DE SERVIÇO DE TI
Qual deve ser a primeira atitude de um profissional de TI quando um serviço

da área, que é considerado crítico para o funcionamento de uma empresa, é in-
terrompido por um incidente 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, fa-
zendo 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 aconteçam).
Por isso, gerenciamento de continuidade também tem relação com a capaci-
dade que a empresa tem de prever eventos de risco que possam afetar seriamen-
te 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.
54
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,
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.
55
É 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.
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.
56
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 profissional de TI
que gerencia fornecedores.
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).
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;
57
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.

GERENCIAMENTO DOS FORNECEDORES
As atribuições do profissional de TI responsável pelo gerenciamento dos for-

necedores 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.
58
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 cer-
teza 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
empresas 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.
Odirlei Batista, 2012.
Demanda Capacidade
Figura 21 - Equilíbrio capacidade e demanda

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

GERENCIAMENTO DA CAPACIDADE
São atribuições do profissional de TI responsável pelo gerenciamento da ca-

pacidade:
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.
60
2.14 GERENCIAMENTO DA SEGURANÇA DA INFORMAÇÃO
Dreamstime, 2012
Figura 22 - Gerenciamento da segurança da informação
Você sabia que, na sociedade da informação em que vivemos, ao mesmo tem-

po 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 Tri-
bunal 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.
61
NBR ISO/IEC 27001
Segundo a NBR ISO/IEC 27001 (2006), os seguintes controles devem ser obser-
vados 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.
62
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 soft-

ware, 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 são elementos essenciais no dia a dia, sendo que devemos dar
atenção tanto aos dados quanto ao 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,
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.
63
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 profissional de TI responsável pela gerência de ativos e configuração
deve ser capaz de responder a perguntas do tipo: Qual é a configuração de hard-
ware do principal servidor da sua empresa? Quais são os softwares instalados nas
estações de trabalho dos funcionários? Quais sistemas operacionais devem ser atu-
alizados? Quantas licenças de software estão em uso atualmente? Para realização
dessa tarefa, existe a área de gerenciamento 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).
64
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 armazenados 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 PROFISSIONAL DE TI RESPONSÁVEL PELA GERÊNCIA DE

ATIVO E CONFIGURAÇÃO DE SERVIÇO
Segundo Freitas (2010), o profissional responsável pela gerência de ativo e

configuração de serviço exerce as seguintes funções:
65
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 responsável pelo ativo de serviço, também

existem os seguintes profissionais relacionados a esse
VOCÊ processo: gerente de configuração, analista de confi-
SABIA? guração, administrador da configuração, administrador
de ferramenta 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
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.
Dreamstime, 2012.
Figura 23 - Gerenciamento de mudanças

66
Nesse contexto, considere o seguinte cenário: a área de suporte de TI tem exe-

cutado o serviço de manutenção de monitores seguindo sempre o mesmo pro-
cesso: registro da reclamação do cliente, recolhimento do monitor para diagnós-
tico, definição do prazo de execução do serviço, solicitação de peças de reposição
ao fornecedor, reparo e devolução para o cliente.
Com base na experiência adquirida, e no feedback de seus clientes, o respon-
sável 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écni-
co. 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 rea-
lizada somente após uma consulta 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, implementa-
das, documentadas e revisadas de maneira controlada.
Essa abordagem permite que os riscos impostos pelas mudanças sejam mini-
mizados por meio de um planejamento de implementação de mudanças, e que
estas, uma vez aprovadas, sejam implementadas considerando requisitos de cus-
to, 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 le-
gais 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.
As mudanças técnicas ocorrem no nível de componentes de TI, mas sem afe-
tar os serviços, pois geralmente são mudanças necessárias apenas para correções
de componentes de TI.
67
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
aprovado, 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 deta-
lhadas 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 aconse-
lham o profissional de TI responsável pelo gerenciamento de mudanças na avalia-
ção, priorização e planejamento de mudanças. Esse comitê deve ser multidiscipli-
nar 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.
FUNÇÕES DO PROFISSIONAL DE TI RESPONSÁVEL PELO

GERENCIAMENTO DE MUDANÇAS
Além de realizar as atividades do gerenciamento de mudanças descritas no

tópico anterior, o profissional de TI responsável pela área deve:
a) gerar relatórios de avaliação das mudanças;
68
b) gerenciar a programação futura das mudanças;

c) convocar e coordenar a reuniões do CCM.
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 24 - 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 desem-
penho 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 capacida-
de para suportar o serviço? Para auxiliar nas respostas a esses questionamentos
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-
69
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.
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 conside-
rados: a quantidade de registros 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 configuração; o ambiente disponível para a construção, teste, dis-
tribuição e implementaçã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).
70
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.
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.
FUNÇÕES DO PROFISSONAL DE TI RESPONSÁVEL PELO

GERENCIAMENTO DE LIBERAÇÃO E IMPLANTAÇÃO
Basicamente, o papel do profissional de TI responsável pelo gerenciamento de

liberação e implantação é projetar e planejar a construção dos pacotes de libera-
ção. Pacotes de liberação são conjuntos de requisições de implantação elabora-
dos 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.
71
2.18 GERENCIAMENTO DO CONHECIMENTO
Dreamstime, 2012.
Figura 25 - 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 decisã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 co-
nhecimento sobre o assunto.
A 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 Chiave-
nato (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.
72
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.
73
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 res-

peito às estruturas dados para informação, conhecimento e sabedoria – os DICS.
Os DICS são bases de dados onde estão armazenadas as informações a respei-
to 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
central de armazenamento de informações e conhecimento, que tem o ob-
jetivo 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.
74
FUNCÕES DO PROFISISONAL RESPONSÁVEL PELO GERENCIAMENTO DE

CONHECIMENTO
O profissional de TI da área 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). Adaptado de Compsult Inc., 2012.
Figura 26 - 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 profissional da área
de TI deve tomar alguma providência para que a entrega desse serviço seja res-
taurada de forma adequada. A essa interrupção ou redução da qualidade na en-
trega de um serviço dá-se o nome de incidente. Quem cuida do tratamento dos
incidentes é a área conhecida como gerenciamento de incidentes.
75
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.
76
Identificação
Registro
Categorização
Priorização
Diagnóstico
Encaminhamento
Investigação
Resolução
Autor (2012).
Encerramento
Figura 27 - Processo de Gerenciamento de Incidentes
a) Identificação do incidente
A identificação do incidente pode ser feita 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.
77
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.
78

GERENCIAMENTO DE INCIDENTES
Além de conduzir o processo acima descrito, Freitas (2010) cita que o profissio-
nal de TI da área 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.
O monitoramento é importante porque em alguns casos um evento pode afe-
tar 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 gerenciamento de eventos é evitar que os eventos se trans-
formem 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.
79
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.
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
Autor (2012).
Categorização Encerramento
Figura 28 - 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.
80
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 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 profissional de TI responsável pelo gerenciamento de eventos tem a função

de 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-
81
ç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 incidente é 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 trata-
mento dos problemas é feito pela área de gerenciamento de problemas.
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.
82
Registro da Aprovação da Execução do Fechamento
Autor (2012).
Requisição Requisição Serviço da Requisição
Figura 29 - Processo de Gerenciamento de Requisições
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 profissional de TI da área que irá entregar o serviço. Por exemplo, a disponibi-
lização de algum recurso de hardware, como um data show, deve ser comunicada
ao responsável pela área para que este faça a reserva do equipamento. Obvia-
mente 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.
83
2.22 GERENCIAMENTO DE PROBLEMAS
Dreamstime, 2012.
Figura 30 - Gerenciamento de problemas
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 es-
teve indisponível por 30 minutos na tarde da última segunda-feira. Isso é um inci-
dente. Mas qual a causa desse incidente?
Após investigação da área técnica responsável, foi observado que esse inci-
dente foi provocado por um problema no banco de dados que armazena as infor-
maçõ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-
84
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. (FREITAS, 2010, p. 279-280)
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.
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
Autor (2012).
Investigação Fechamento
Figura 31 - 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.
85
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.
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.
86
FUNÇÕES DO PROFISSIONAL DE TI RESPONSÁVEL PELO

GERENCIAMENTO DE PROBLEMAS
Além de conduzir o processo acima, Freitas (2010) cita que o profissional de TI

responsável pelo gerenciamento de problemas 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.
2.23 GERENCIAMENTO DE ACESSO

Dreamstime, 2012.
Figura 32 - Gerenciamento de acesso

87
O acesso aos serviços de TI está disponível a todos os funcionários de uma or-

ganização? Por exemplo, qualquer usuário pode propor mudança em um sistema
ou enviar um componente de hardware para reparo?
A resposta é: depende dos níveis de acesso concedido a esses usuários. De-
terminados serviços, principalmente 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 NBR ISO/IEC 27001 (2006), confidencialidade é a proprie-
dade de que a informação não esteja disponível ou revelada a indivíduos, entida-
des ou processos não autorizados. Integridade é a propriedade de salvaguarda
da exatidão e completeza de ativos. E disponibilidade é a propriedade de estar
acessível e utilizável sob demanda por uma entidade autorizada.
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
adicionalmente 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 gerencia-
mento de acesso.
As atividades previstas para o gerenciamento de acesso são geralmente reali-
zadas pelo profissional de TI responsável pela gerência de segurança da informa-
ção. Isso ocorre também pelo fato de não existir formalmente a função de geren-
te 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;
88
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.
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
89
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á função responsável pelo gerenciamento de
acesso. Geralmente as atividades acima são realizadas pela central de serviços ou
pelo profissional de TI que gerencia a 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
Odirlei Batista (2012). Adaptado de Now Go Create, 2012.
Kai Zen
Change Good
Figura 33 - Melhoria continuada de serviço
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 cus-
tos. 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 visando 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
processo? A resposta pode ser encontrada na atividade conhecida como melho-
ria continuada de serviço.
90
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 indica-

dores 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 hard-
ware 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.
O principal indicador utilizado para medir o desempe-

VOCÊ nho de um processo é conhecido como principal indi-
SABIA? cador de desempenho (PID). 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.
91
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 aten-
dimentos realizados pela área de suporte de TI são feitos dentro do tempo máxi-
mo de 24 horas, e durante as etapas iniciais de planejamento, com base no feed-
back dos usuários observou-se que o desejável era um índice de 90%. Então as
ações seguintes devem ser planejadas visando alcançar esse novo índice.
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 pro-
fissional de TI responsável pelo gerenciamento de melhoria continuada que irá
realizar as ações corretivas. Ele apenas identifica 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.
92
FUNÇÕES DO PROFISSIONAL DE TI RESPONSÁVEL PELO GERENCIAMENTO

DE MELHORIA CONTINUADA DE SERVIÇO
Além de conduzir o processo descrito acima, segundo Freitas (2010) o profis-

sional de TI responsável pelo gerenciamento 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.
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.
93
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.
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.
96
3.1 OTIMIZAÇÃO DE RECURSOS FÍSICOS MATERIAIS
Dreamstime (2012)
Figura 34 - 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ísti-
cas. Dinheiro é considerado recurso financeiro, pessoas são recursos humanos,
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
97
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.
Entre os principais benefícios dessa metodologia, podemos citar:
a) maior pro-dutividade pela redução da perda de tempo procurando por ob-
jetos, pois só fi-cam no ambiente de trabalho os itens necessários e ao alcan-
ce das mãos;
b) redução de despesas e melhor aproveitamento de materiais;
c) diminuição do acúmulo e-cessivo de materiais, que tende à degeneração;
d) melhoria da qualidade de produtos e serviços;
e) prevenção de acidentes de trabalho;
f) maior satisfação das pessoas com o ambiente de trabalho;
g) incentivo à criatividade; redução de custos;
h) desenvolvimento do trabalho em equipe;
i) 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 35 - 5S
Cada “S” dos 5S possui um significado que vamos ver a seguir.

98
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
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 en-
volvidos, melhoria do ambiente de trabalho, melhoria de áreas comuns da em-
presa, melhoria nas condições de segurança, os envolvidos passam a ter maior
cuidado com sua aparência (influenciados pelo ambiente), padronização dos pro-
cessos.
3 Meio Ambiente
99
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 melhoria contínua proporcionará menor desperdício, melhor qua-
lidade e ganhos significativos na administração do tempo. Os principais bene-
fícios deste princípio são: trabalho diário mais agradável, melhoria nas relações
humanas, valorização dos envolvidos, cumprimento dos procedimentos opera-
cionais e administrativos, melhor qualidade, produtividade e segurança no traba-
lho, 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 36 - Otimização de pessoas

100
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.
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-
3 Meio Ambiente
101
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,
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. (CHIAVENA-
TO, 2007, p. 61).
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.
102
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;
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
indivíduos dotados de competências que geram vantagem competitiva.
Também aprendeu que essas competências precisam ser geridas de forma
que se acrescente valor às pessoas para melhorar os processos internos da orga-
nização e incrementar a qualidade e a produtividade às tarefas do dia a dia e aos
produtos e serviços oferecidos.
3 Meio Ambiente
103
CASOS E RELATOS
Trabalhando com talentos

Quantos talentos escondidos existem em uma organização? Quan-
tas pessoas almejam a execução de atividades que lhes sejam mais
desafiadoras? A gestão orientada por competências, que você estu-
dou neste 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 competência das pessoas em relação às compe-
tências requeridas para as funções que ocupam. Mas o que pode ocor-
rer se os talentos não estiverem 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.
104
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-
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
3 Meio Ambiente
105
comprometer o direito de as gerações futuras atenderem às suas próprias neces-

sidades”.
Nessa definição há dois conceitos envolvidos: o primeiro é o conceito de ne-
cessidades, que podem variar de sociedade para sociedade, mas que devem ser
satisfeitas para assegurar as condições essenciais de vida a todos, indistintamen-
te; o segundo é o de limitação, que reconhece a necessidade de a tecnologia de-
senvolver 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.
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 susten-

tável”, descreve um conjunto de etapas pelas quais os profissionais de TI devem
passar para alcançar a sustentabilidade:
a) Desenvolvimento interno: o profissional de TI de uma empresa que desen-
volve tecnologias internamente deve esclarecer aos colaboradores que tudo
deverá 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.
106
Além disso, o profissional deve analisar a integração de qualquer nova apli-

caçã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 profissional de TI conscientizar os funcionários sobre formas
de atuação mais sustentáveis, que incluem práticas para a redução do con-
sumo 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
recursos (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
companhias estrangeiras, as organizações precisam exigir que seus fornece-
dores adotem políticas sustentáveis.
Embora o apelo financeiro para a compra de suprimentos mais baratos pos-
sa 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 eco-
nomia 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 Meio Ambiente
107
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.
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.
108
É 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. (CHIAVENATO,
2007, p. 60).
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 (2000), orçamento é o balanço prévio das receitas
(o que a empresa recebe) e despesas (o que a empresa gasta) da gestão finan-
ceira. Como tal, deve apresentá-las nas mais minuciosas discriminações; as des-
pesas, na expressão das necessidades dos serviços organizados; as receitas, em
suas fontes originais e nos seus custos de produção.
Gomes (2000) também afirma que a elaboração do orçamento em um am-
biente empresarial, juntamente com o planejamento financeiro, são atividades
muito importantes, ou seja: para que o orçamento seja considerado viável às es-
traté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
financiamentos requeridos.
A utilização das técnicas de OBZ se justifica, segundo Gomes (2000), no se-
guinte contexto: para alocar efetivamente recursos limitados. Um processo orça-
mentá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-
3 Meio Ambiente
109
çã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 administrador é obrigado a preparar um “pacote de decisão” para cada
atividade ou operação, e esse pacote inclui uma análise de custo, finalidade, al-
ternativas, medidas 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 profissionais de TI têm primeiro que identificar
diferentes maneiras de executar cada atividade e essa análise obriga a todos ava-
liarem 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
instrumento que promove a redução dos gastos e das despesas, gerando aumen-
to do ganho financeiro.
Apesar dos avanços tecnológicos atuais, como a utiliza-

VOCÊ ção de softwares financeiros ou planilhas eletrônicas, o
SABIA? planejamento financeiro não deve ser mecanizado, mas
profundamente analisado e discutido.
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.
110
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.
2 SISTEMA OPERACIONAL
111
Anotações:
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 é 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 anda-
mento 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 para gerenciar 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 37 - 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 em-
presas, como, por exemplo, o atendimento ao cliente, o gerenciamento financei-
ro 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.
4 Gestão de projetos
115
Os projetos são bem-sucedidos quando atendem às expectativas das partes

interessadas (ou mesmo quando as ultrapassam), mas podem ser finalizados caso
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 central 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 impacto; 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 Project Management Body of Knowledge (PMBOK) – Corpo de Conhecimento

em Gerenciamento de Projetos – é um conjunto de práticas em gerenciamento
de projetos publicado pelo Project Management Institute (PMI) – Instituto de Ge-
renciamento de Projetos. Ele constitui a base de conhecimento em gerenciamen-
to 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 profissional de TI que gerencias projetos tem a responsa-
bilidade 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 coleti-
vo 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 seria atribuído a um pro-
fissional de TI, que se reportaria ao responsável pelo projeto.
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 (Project Management Office – PMO). 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 38 - 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 profissional da área de Suporte de TI
deve escolher a pessoa que gerenciará o projeto, e você, ciente de sua competên-
cia 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
gestor de projetos – o profissional de TI que almeja a posição 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ên-
cia; de liderança; e para formação e motivação de equipes.
a) Habilidades organizacionais e de planejamento
Responsabilidade 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 rea-
lização de estimativas dos custos do projeto –, são necessários conhecimentos,
mesmo que básicos, em finanças e contabilidade.
c) Habilidades para resolução de conflitos
Capacidade 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 depende da capacidade técnica da equipe, é necessária 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 profissional de TI para
ser um bom gestor de projetos, pois suas habilidades vão muito além do conhe-
cimento 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, são necessárias diversas habilidades para

gerenciá-lo: organizacionais, de planejamento, elaboração de orçamentos, re-
soluçã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.
Isso ocorre porque projetos de áreas diferentes requerem conhecimentos e
capacidades técnicas diferentes. O conhecimento 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 Su-
porte 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 software 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, chama-
das 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 po-
dem passar por fases como: estudo de viabilidade, projeto, construção, inspeção
e vendas. Já os grupos de processos (iniciação, planejamento, execução, monito-
ramento e controle e encerramento) são sempre os mesmos, independentemen-
te 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
122
Projeto e a Identificação das Partes Interessadas. Esses documentos servem como

insumo para o próximo processo, o planejamento.
b) Planejamento
Esse é o momento de formular e revisar as metas e objetivos do projeto e deli-
near 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, de-
finição das atividades do projeto, planejamento do escopo, desenvolvimento do
cronograma, identificação dos riscos, recrutamento da equipe e planejamento
das aquisições. O resultado 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 profissional de TI 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-
123
des devem ser revisadas várias vezes ao longo do ciclo de vida do projeto. Cada
revisão é chamada de iteração.
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
Odirlei Batista (2012). Adaptado de QualiTec, 2012.

sto
Qualidade
s
çõ e s
Ris
ica
co
n
Escopo
u
m
Co
Recursos Aquisições
Humanos
Figura 39 - Áreas de conhecimento do gerenciamento de projetos
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 (<http//:www.pmi.org>) agrupa-os em nove categorias, conhecidas
como áreas de conhecimento do gerenciamento de projetos. A seguir, você po-
derá aprender mais sobre essas nove áreas de conhecimento.
124
Á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,
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 tempo
hábil.
125
O gerenciamento do tempo é um aspecto importante do gerenciamento de

projetos, pois envolve a manutenção das atividades do projeto em dia e a contra-
posição dessas atividades ao plano de projeto para garantir que ele seja concluí-
do dentro do prazo.
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 aprovado.
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 co-
municação são as habilidades gerais de gerenciamento que o gerente de projeto
usa no dia a dia.
Os processos aí envolvidos visam a garantir que todas as informações do pro-
jeto, inclusive planos de projeto, avaliações de risco, notas tomadas em reuniões
etc., sejam coletadas, documentadas, arquivadas e descartadas quando apropria-
do. Asseguram também a distribuição e o compartilhamento 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
126
recursos humanos designados para o projeto sejam utilizados da maneira mais

eficiente possível.
Entre os participantes do projeto com os quais você praticará essas habilida-
des 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 competências de li-
derança e formação de equipes. Assim, um profissional de TI gestor de projetos
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 processo
de planejamento do projeto, a fim de garantir que o cliente receba o produto ou
serviço que supõe ter comprado.
Agora que você conhece as áreas de conhecimento e os grupos de processos,
veja no quadro a seguir, de forma resumida, como são divididas as atividades das
áreas em cada grupo.
127
Quadro 2 - Mapeamento dos grupos de processos de gerenciamento de projetos e áreas de conhecimento
Grupos de processos
Áreas de
conhecimento Monitoramento
Iniciação Planejamento Execução Encerramento
e controle
- Termo de aber- - Monitoramen-

Gerenciamento
tura do projeto - Plano de gerencia- - Orientação e to e controle - Encerramento
de integração
- Declaração mento do projeto gestão executiva - Controle integrado do projeto
do projeto
do escopo de mudanças
- Planejamento do escopo
Gerenciamento
- Definição do escopo
do escopo
- Elaboração da Estrutura
do projeto
Analítica do Projeto (EAP)
- Definição das atividades

- Sequenciamento das atividades
- Estimativa de recur-
Gerenciamento
sos das atividades - Controle do
do tempo do
- Estimativa de dura- cronograma
projeto
ção das atividades
- Desenvolvimento
do cronograma
Gerenciamento
- Estimativa de custos
dos custos - Controle de custos
- Elaboração de orçamentos
do projeto
- Distribuição das
Gerenciamento
informações
das - Planejamento das - Elaboração dos relató-
- Gerenciamento das
comunicações comunicações rios de desempenho
partes interessadas
do projeto
Gerenciamento
- Realização das
das aquisições - Planejamento das aquisições
aquisições
do projeto
- Planejamento do geren-
ciamento de riscos
Gerenciamento - Identificação de riscos
- Monitoramento e
dos riscos - Análise qualitativa de riscos
controle de riscos
do projeto - Análise quantitativa de riscos
- Planejamento de res-
postas a riscos
- Contratação e
Adaptado de: Guia PMBOK 4 ed. (2008).
mobilização da
Gerenciamento
equipe do projeto
de recursos - Planejamento de re-
- Desenvolvimento da
humanos do cursos humanos
equipe do projeto
projeto
- Gerenciamento da
equipe do projeto
Gerenciamento
da qualidade - Planejamento da qualidade - Garantia da qualidade - Controle da qualidade
do projeto
Neste tópico, você aprendeu sobre as nove áreas de conhecimento do gerencia-

mento de projetos: quais são essas áreas e sua diferença em relação aos grupos
de processos.
128
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.
TERMO DE ABERTURA DO PROJETO
O termo de abertura do projeto é um documento utilizado para descrever as

atribuições 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 interes-
sados, designação do gerente do projeto, cronograma sumarizado, orçamento
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.
129
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.
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:
130
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.
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:
131
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 soft-
ware de integração; o segundo tipo é a técnica conhecida como Gerenciamento
de Valor Agregado (do inglês Earned Value Management – EVM), uma metodolo-
gia de integração de projetos que, além de integrar processos, auxilia na mensu-
raçã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 profissional de TI gestor do projeto, e a declaração do esco-
po é constantemente refinada junto com os interessados no projeto. O plano de
gerenciamento integra os componentes, enquanto a gestão propriamente dita
orienta as atividades para alcançar o previsto no escopo.
Os desvios identificados durante a orientação da execução devem ser corri-
gidos na etapa de monitoramento e controle. O encerramento 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 corresponde ao objetivo que se pretende atingir. É

o termo utilizado para definição dos limites de um projeto. Assim, o plano de pro-
jeto obedece ao escopo do projeto. Nesse contexto, o gerenciamento do escopo
do projeto tem por objetivo garantir que o projeto realize “todo”, considerando
“somente” o trabalho necessário para o seu sucesso.
Além de controlar as mudanças, o gerenciamento do escopo também organi-
za 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.
132
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 gerenciamento 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-
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.
133
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 acordados com esse cliente.
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.
134
4.9 GERENCIAMENTO DO TEMPO DO PROJETO
Dreamstime, 2012.
Figura 40 - Gerenciamento do tempo
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.
É um aspecto importante do gerenciamento de projetos, pois envolve a ma-
nutençã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).
135
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.
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).
136
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.
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.
137
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 dis-
ponibilidade dos recursos com o objetivo 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 necessidade de recursos adicionais e a ocio-
sidade 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.
138
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.
4.10 GERENCIAMENTO DE CUSTOS DO PROJETO
Dreamstime (2012)
Figura 41 - 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.
139
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.
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 (HELDMAN, 2009).
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
140
1 fluxo de caixa uma das entregas de seu projeto seja uma embalagem espe-
cial, e haja pessoal terceirizado encarregado dessa tarefa. Este
Indica a origem de todo
o recurso financeiro provavelmente tratará a entrega como um projeto dentro de
(dinheiro) que entrou
no caixa da empresa, sua própria organização, decompondo o trabalho até o nível
bem como o destino de das atividades. Para o seu projeto, porém, ela não passará de
todo o recurso que saiu,
considerando determinado uma entrega no nível dos pacotes de trabalho (Heldman, 2009).
período de tempo. Seu
principal objetivo é
evidenciar as transações A atividade de estimativa de custos emprega diversas ferramentas e técnicas
que efetivamente
movimentaram o caixa. para gerar as estimativas. Destacam-se:
a) opinião especializada;
b) estimativa bottom-up;
c) estimativa de três pontos;
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.
141
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.
Estimativas paramétricas representam um método de base quantitativa. Por
exemplo, multiplicam a quantidade de tempo necessária para executar uma ati-
vidade pelos custos dos recursos necessários, com o objetivo de determinar seu
custo total. Essa técnica pode ser exata quando os dados utilizados são confiáveis.
RECONCILIAÇÃO DO LIMITE DE RECURSOS FINANCEIROS
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;
142
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.
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 Valor Presente Líquido (VLP) 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 Taxa Interna de Retorno (TIR) é 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.
143
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.
4.11 GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO
Denis Pacher (2012)
Figura 42 - 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, ava-
144
liações de risco, notas tomadas em reuniões etc., sejam coletadas, documentadas,

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 projeto, as informações são arquivadas e usadas como referên-
cia para os próximos projetos (HELDMAN, 2009).
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.
145
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.
146
2 Probidade
administrativa
Significa integridade de CASOS E RELATOS

caráter, honradez. Seu
contrário, a improbidade,
é o mesmo que
desonestidade, falta de A importância da comunicação
caráter.
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.
147
4.12 GERENCIAMENTO DAS AQUISIÇÕES DO PROJETO
Denis Pacher (2012)

Figura 43 - 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
148
3 Alienação 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
É a transferência da posse
de um bem móvel ou só é realizado quando você estiver comprando mercadorias ou serviços de fora
imóvel do devedor ao
credor para garantir o de sua organização. Se você dispõe de todos os recursos necessários à execução
cumprimento de uma do trabalho do projeto dentro da organização, esse processo não será utilizado.
obrigação.
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 na-
tureza. No Brasil, todas as licitações feitas por entidades que fazem uso da verba
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á regulamen-
tado 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

garantir a observância do princípio constitucional da isonomia, a seleção da pro-
posta 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 igualda-
de, da publicidade, da probidade administrativa2, da vinculação ao instrumento
convocatório, do julgamento objetivo e dos que lhe são relacionados.
149
EDITAL
Todas as características do bem ou serviço que será adquirido devem constar

no edital. Esse documento é desenvolvido para estabelecer as condições da lici-
tação. A correta elaboração do edital e a definição precisa das características do
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.
150
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 44 - Gerenciamento dos riscos
Chama-se “risco” um evento ou condição incerta que, se ocorrer, tem um efei-

to 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ó trazem 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 proje-
tos 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-
151
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 proje-
to 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
152
vezes, de forma intuitiva. No âmbito do gerenciamento de projetos, assim como

na vida, é preciso ter uma abordagem proativa, 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.
153
Existem várias técnicas para análise quantitativa. Entre elas destacam-se: análi-
se 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.
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
154
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.
155
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 3 - 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.
156
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.
Entre as principais ferramentas e técnicas utilizadas nesse processo, 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 comporta-
mento aceitável da equipe; agrupamento físico dos integrantes da equipe; e defi-
nição de uma política clara de reconhecimento e recompensas para os integran-
tes da equipe.
157
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 profissional de TI gestor do projeto prepara e con-
duz as avaliações de desempenho, identifica e resolve os problemas e fornece
feedback aos membros da equipe. Alguns comportamentos também são obser-
vados 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. Entre elas podemos citar: observações e conversas; avaliações de desem-
penho do projeto; gerenciamento de conflitos; registro das questões; e habilida-
de 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.
A preparação da equipe começa com a compreensão do conceito de qualida-
de, 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, possibilitan-
do 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,
158
os quais avaliam o desempenho geral, monitoram os resultados do projeto e os

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 o ISO
9000) com o qual, nesses casos, o planejamento da qualidade deve estar alinha-
do. 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 planejamen-
to 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
159
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) histograma;
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.
160
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
Denis Pacher, 2012.

Executar
C D
RESULTADOS
Coletar
Dados
Figura 45 - 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-
161
ção de projetos; e há organizações matriciais, que surgiram para minimizar as dife-

renças entre os pontos fortes e fracos 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 reali-
zar tarefas específicas do departamento. A figura a seguir ilustra um exemplo de
organograma de uma empresa funcional.
162
Gerência
Denis Pacher (2012). Adaptado de HELDMAN (2009).

RH Finanças Marketing TI Produção
Pessoal Pessoal Pessoal Pessoal Pessoal
Figura 46 - Organograma funcional
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. Quando comparada à anterior, ilustra as diferenças na estrutura organi-
zacional entre ambos os tipos de empresa.
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

Projeto Projeto Projeto Projeto Projeto
Membros/ Membros/ Membros/ Membros/ Membros/
Figura 47 - Organograma projetizado

163
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 simultanea-
mente, eles podem ser subordinados a vários gerentes de projeto.
O gerente funcional, por sua vez, responde por atividades administrativas, alo-
ca 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 ta-
refas de acor-do com as atividades previstas. Ambos dividem a responsabilidade
pelas avalia-ções de desempenho dos funcionários.
A figura seguinte mostra um exemplo de organograma de empresa matricial.
164
Gerência

Gerentes Finanças Marketing TI Produção
Gerente de
Pessoal Pessoal Pessoal Pessoal
Projeto
Gerente de
Pessoal Pessoal Pessoal Pessoal
Projeto
Figura 48 - 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
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.
165
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 estudo que indique qual será a aceitação desse produto. Também
podem ser analisadas questões técnicas relacionadas ao projeto, verificando se sua
tecnologia sugerida é 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-
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
166
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).
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,
167
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 30
Fonte: Adaptado de HELDMAN (2009)
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.
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:
168
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 49 - Encerramento
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
169
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 basica-

mente as seguintes atividades: encerramento administrativo e de contrato com
terceiros, aceitação formal do produto do projeto e registro das lições aprendi-
das. Todos os conceitos abaixo foram adaptados do livro Gestão de projetos, de
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
à 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.
170
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.
171
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.
172
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.
173
Anotações:
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.
REFERÊNCIAS DAS FIGURAS
1 DREAMSTIME. Boas práticas. 2012. Fotografia. Color. Disponível em: <http://www.dreamstime.

com>. Acesso em: 30/10/2013.
2 BATISTA, Odirlei. ITIL. 2012. Ilustração. Color. Adaptado de: Enterprise Architecture, 2011.
Disponível em: <http://iea.wikidot.com/itil>. Acesso em: 30/10/2013.
3 BATISTA, Odirlei. COBIT. 2012. Ilustração. Color. Adaptado de: ISACA, 2011. Disponível em:
<http://www.isaca.org/Knowledge-Center/cobit/PublishingImages/cobit_circle_lg.gif>. Acesso em:
30/10/2013.
4 BATISTA, Odirlei. Ciclo de vida de serviço. 2012. Ilustração. Color. Adaptado de: Guilherme
Maia, 2012. Disponível em: <http://guilhermemaia.org/2011/10/20/o-que-e-itil-e-como-se-
preparar/ciclo_de_vida_itil/>. Acesso em: 30/10/2013.
5 BATISTA, Odirlei. Estratégia de serviço. 2012. Ilustração. Color. Adaptado de: Pedro Carvalho,
2012. Disponível em: <http://www.pedrofcarvalho.com.br/itilestrategia.png>. Acesso em:
30/10/2013.
6 BATISTA, Odirlei. Desenho de serviço. 2012. Ilustração. Color. Adaptado de: Pedro Carvalho,
2012. Disponível em: <http://www.pedrofcarvalho.com.br/ITIL_DESENHO_SERVICO.png>. Acesso
em: 30/10/2013.
7 BATISTA, Odirlei. Transição de serviço. 2012. Ilustração. Color. Adaptado de: Pedro Carvalho,
2012. Disponível em: <http://www.pedrofcarvalho.com.br/itil_transicao_servico.png>. Acesso em:
30/10/2013.
8 BATISTA, Odirlei. Operação de serviço. 2012. Ilustração. Color. Adaptado de: Pedro Carvalho,
2012. Disponível em: <http://www.pedrofcarvalho.com.br/ITIL_OPERACAO.png>. Acesso em:
30/10/2013.
9 BATISTA, Odirlei. Melhoria contínua de serviço. 2012. Ilustração. Color. Adaptado de: Pedro
Carvalho, 2012. Disponível em: <http://www.pedrofcarvalho.com.br/ITIL_melhoria.png>. Acesso
em: 30/10/2013.
10 DISNEY. Onde chegar. 2010. Ilustração. Color. Disponível em: <http://2.fimagenes.com/
i/5/b/18/am_79219_6228002_620868.jpg>. Acesso em: 30/10/2013.
11 BATISTA, Odirlei. Modelo básico de planejamento. Adaptado de FREITAS (2010). 2012.
Ilustração. Color.
12 BATISTA, Odirlei. Exemplo de análise de Gap. 2012. Ilustração. Color. Adaptado de:
Convergir, 2012. Disponível em: <http://convergir.com.br/wp-content/uploads/2010/11/avaliacao-
competencias-600.jpg>. Acesso em: 30/10/2013.
13 BATISTA, Odirlei. Portfólio de serviço. 2012. Ilustração. Color. Adaptado de: ITIL Blues, 2012.
Disponível em: <http://itilblues.files.wordpress.com/2007/07/serviceportfoliobigpic-cc-bync25-
web.png>. Acesso em: 30/10/2013.
14 BATISTA, Odirlei. Ciclo para definição dos serviços. 2012. Ilustração. Color. Adaptado de:
Breno Nunes, 2012. Disponível em <http://2.bp.blogspot.com/-PCECeFXpcyk/T5Hfat7UZmI/
AAAAAAAAARk/OXyLbfq47ig/s1600/7passos_ITILV3_Melhoria.jpg>. Acesso em: 30/10/2013.
15 BATISTA, Odirlei. Gerenciamento de demanda. 2012. Ilustração. Color. Adaptado de: BULL,
2012. Disponível em: <http://www.bull.fr/gestion-projets/>. Acesso em: 30/10/2013.
16 DREAMSTIME. Gerenciamento financeiro. 2012. Fotografia. Color. Disponível em: <http://
www.dreamstime.com>. Acesso em: 30/10/2013.
17 BATISTA, Odirlei. ITIL V3 – Ciclo de vida dos serviços. 2012. Ilustração. Color. Adaptado
de: Luiz Siqueira, 2009. Disponível em: <http://lhsiqueira.files.wordpress.com/2009/04/itilv3_
processos_clico_vida_gd.jpg>. Acesso em: 30/10/2013.
18 PACHER, Denis. Gerenciamento de nível de serviço. 2012. Ilustração. Color.
19 BATISTA, Odirlei. Tipos de acordos. 2012. Ilustração. Color.
20 PACHER, Denis. Gerenciamento da disponibilidade. 2012. Ilustração. Color.
21 BATISTA, Odirlei. Equilíbrio capacidade e demanda. 2012. Ilustração. Color.
22 DREAMSTIME. Gerenciamento da segurança da informação. 2012. Fotografia. Color.
Disponível em: <http://www.dreamstime.com>. Acesso em: 30/10/2013.
23 DREAMSTIME. Gerenciamento de mudanças. 2012. Fotografia. Color. Disponível em: <http://
24 DREAMSTIME. Gerenciamento de liberação e implantação. 2012. Fotografia. Color.
Disponível em: <http://www.dreamstime.com>. Acesso em: 30/10/2013.
25 DREAMSTIME. Gerenciamento do conhecimento. 2012. Ilustração. Color. Disponível em:
<http://www.dreamstime.com>. Acesso em: 30/10/2013.
26 PACHER, Denis. Gerenciamento de incidentes. 2012. Ilustração. Color. Adaptado de:
Compsult Inc., 2012. Disponível em: <http://compsultinc.blogspot.com.br/2012/06/how-summer-
effects-technology-heat.html>. Acesso em: 30/10/2013.
27 MORAES, Edison. Processo de gerenciamento de incidentes. 2012. Ilustração. Color.
28 MORAES, Edison. Processo de gerenciamento de eventos. 2012. Ilustração. Color.
29 MORAES, Edison. Processo de gerenciamento de requisições. 2012. Ilustração. Color.
30 DREAMSTIME. Gerenciamento de problemas. 2012. Fotografia. Color. Disponível em: <http://
31 MORAES, Edison. Processo de gerenciamento de problemas. 2012. Ilustração. Color.
32 DREAMSTIME. Gerenciamento de acesso. 2012. Fotografia. P&B. Disponível em: <http://www.
dreamstime.com>. Acesso em: 30/10/2013.
33 BATISTA, Odirlei. Melhoria continuada de serviço. 2012. Ilustração. P&B. Adaptado de: Now
Go Create, 2012. Disponível em: <http://www.nowgocreate.co.uk/blog/article.php?blogID=3>.
Acesso em: 30/10/2013.
34 DREAMSTIME. Otimização de recursos físicos e materiais. 2012. Fotografia. Color. Disponível
em: <http://www.dreamstime.com>. Acesso em: 30/10/2013.
35 PACHER, Denis. 5S. 2012. Ilustração. Color.
36 DREAMSTIME. Otimização de pessoas. 2012. Fotografia. Color. Disponível em: <http://www.
37 PACHER, Denis. Alvo. 2012. Ilustração. Color.
38 DREAMSTIME. Habilidades. 2012. Fotografia. Color. Disponível em: <http://www.dreamstime.
com>. Acesso em: 30/10/2013.
39 BATISTA, Odirlei. Áreas de conhecimento do gerenciamento de projetos. Ilustração. Color.
Adaptado de: QualiTec, 2012. Disponível em: <http://qualitec-engenharia.blogspot.com.br/>.
Acesso em: 30/10/2013.
40 DREAMSTIME. Gerenciamento do tempo. 2012. Fotografia. Color. Disponível em: <http://
41 DREAMSTIME. Gerenciamento de custos. 2012. Fotografia. P&B. Disponível em: <http://www.
42 PACHER, Denis. Gerenciamento das comunicações. 2012. Ilustração. Color.
43 PACHER, Denis. Gerenciamento das aquisições. 2012. Ilustração. Color.
44 DREAMSTIME. Gerenciamento dos riscos. 2012. Ilustração. Color. Disponível em: <http://
45 PACHER, Denis. Ciclo PDCA. 2012. Ilustração. Color.
46 PACHER, Denis. Organograma funcional. Adaptado de HELDMAN (2009). 2012. Ilustração.
Color.
47 PACHER, Denis. Organograma projetizado. Adaptado de HELDMAN (2009). 2012. Ilustração.
Color.
48 PACHER, Denis. Organograma matricial. Adaptado de HELDMAN (2009). 2012. Ilustração.
Color.
49 DREAMSTIME. Encerramento. 2012. Fotografia. Color. Disponível em: <http://www.
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

Gerenciamento de Serviços de Ti 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

Gerenciamento de Serviços de Ti PDF

Caricato da

Copyright:

Formati disponibili

Série tecnologia da informação (TI)

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

© 2013. SENAI – Departamento Regional de Goiás

SENAI Departamento Nacional

SENAI Departamento Regional de Goiás

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

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

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

Referências das imagens.............................................................................................................................................. 177

Minicurrículo do autor................................................................................................................................................... 180

Aprenderemos como aplicar os procedimentos de otimização de recursos físicos, mate-

A seguir, são descritos na matriz curricular os módulos e as unidades curriculares do curso,

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 (Information Technology Infrastructure Library) ITIL – Biblioteca de Infraestru-

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

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

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

Odirlei Batista (2012). Adaptado de ISACA, 2011.

s: A t rols and Proce ss M t u

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

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

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-

Odirlei Batista (2012). Adaptado de Guilherme Maia, 2012.

Figura 4 - Ciclo de vida de serviço

Figura 5 - Estratégia de serviço

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

Odirlei Batista (2012). Adaptado de Pedro Carvalho, 2012.

Figura 6 - Desenho de serviço

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

a) requisitos funcionais, recursos e capacidades necessárias para entrega dos

Figura 7 - Transição de serviço

Odirlei Batista (2012). Adaptado de Pedro Carvalho, 2012.

Figura 8 - 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). Adaptado de Pedro Carvalho, 2012.

Figura 9 - Melhoria Continua de serviço

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 é planejamento.

No processo de planejamento temos seis etapas genéricas:

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