Tiexames Apostila Itil

APOSTILA FUNDAMENTOS EM
GERENCIAMENTO DE SERVIÇOS
DE TI COM BASE NA ITIL® V2
Este é um material complementar do curso e-learning da TIEXAMES.
Atenção: leia os comentários de introdução na próxima página antes de

prosseguir na leitura deste material.
Este material não pode ser distribuído.
Somente poderá ser utilizado por alunos do site TIEXAMES.
www.tiexames.com.br
Apresentação
Este material foi desenvolvido para profissionais de TI que desejam ter o primeiro contato
com a biblioteca ITIL V2. O conteúdo abordado aqui pode ser utilizado para preparação
para a certificação ITIL V2 Foundation. Este material não é reconhecido pela OGC ou
qualquer órgão relacionado, e serve apenas para estudos para o entendimento básico da
proposta da ITIL e para preparação para o exame de certificação ITIL V2 Foundation.
Esta apostila contém textos referenciados de livros e artigos em inglês, cujas referências
originais constam no final deste material, além de conter conteúdo próprio com
comentários e críticas do autor. Todos os termos da ITIL V2 foram traduzidos para o
idioma português com o auxílio de referências do glossário disponibilizado pelo itSMF
Brasil.
Este material não tem como objetivo substituir os livros oficiais da ITIL V2 e nem
mesmo o conteúdo apresentado durante o nosso curso e-learning. Muitos tópicos
aqui não são explorados com profundidade, pois eles não são necessários para a
preparação do candidato ao exame ITIL V2 Foundation. É apresentado aqui
somente o que é necessário para esta preparação. O curso e-learning da TIEXAMES
é bem mais completo, engloba mais tópicos que esta apostila. Não elaboramos esta
apostila com o objetivo de substituir o conteúdo do curso, ela serve apenas para
revisão de conteúdo. De forma alguma isto prejudica quem está se preparando para
o exame, pois conforme já dito, esta apostila engloba somente o que é necessário
para o exame.
Marcas envolvidas
ITIL® é uma marca registrada do OGC

OGC® é uma marca registrada do Office of Government Commerce
IT Infrastructure Library® é uma marca registrada pela CCTA que agora faz parte do OGC
itSMF® é uma marca registrada do IT Service Management Forum Ltd.
Direitos de cópia
Este material é oferecido apenas aos alunos da TIEXAMES e não pode ser utilizado por
nenhuma outra empresa de treinamento ou ser redistribuído de qualquer outra forma. Se
você identificar que este material está sendo utilizado por outra empresa ou está sendo
distribuído em outro site, denuncie para nós através do e-mail contato@tiexames.com.br .
Versão: 2.0 (última atualização em 15/11/2008)
2
www.tiexames.com.br
SUMÁRIO
Introdução ........................................................................................................................ 6
Introdução ao Cenário.................................................................................................... 6
Introdução à ITIL ............................................................................................................ 8
Organizações Envolvidas com a ITIL ........................................................................... 10
Estrutura de livros da ITIL V2 ....................................................................................... 13
Estrutura de livros da ITIL V3 ....................................................................................... 18
Por Que a ITIL é Importante?....................................................................................... 21
Possíveis Resultados com a Adoção da ITIL................................................................ 21
Possíveis Problemas.................................................................................................... 22
1. Fundamentos em Gerenciamento de Serviços de TI ........................................... 23
Introdução .................................................................................................................... 23
Conceito de Serviço ..................................................................................................... 24
Conceito de Processo .................................................................................................. 24
Outros Conceitos ......................................................................................................... 25
Melhoria Contínua........................................................................................................ 26
3. Central de Serviços ................................................................................................... 27
Introdução .................................................................................................................... 27
Objetivos ...................................................................................................................... 28
Descrição ..................................................................................................................... 28
Atividades .................................................................................................................... 29
Qualificações do Pessoal ............................................................................................. 29
Tipos de Centrais de Serviço ....................................................................................... 30
Estruturas de Central de Serviços ................................................................................ 30
Papéis e Responsabilidades ........................................................................................ 33
Relacionamentos ......................................................................................................... 34
Principais Benefícios .................................................................................................... 35
Problemas Comuns...................................................................................................... 35
IPD - Indicadores Principais de Desempenho .............................................................. 36
4. Gerenciamento de Incidentes ................................................................................ 37
Introdução .................................................................................................................... 37
Objetivos ...................................................................................................................... 37
Conceitos ..................................................................................................................... 38
Descrição do Processo ................................................................................................ 39
Atividades .................................................................................................................... 39
Níveis de Suporte......................................................................................................... 43
Benefícios .................................................................................................................... 46
5. Gerenciamento de Problemas ............................................................................... 47
Introdução .................................................................................................................... 47
Objetivo........................................................................................................................ 47
Conceitos ..................................................................................................................... 48
Atividades .................................................................................................................... 50
Ferramentas e Técnicas............................................................................................... 54
3
www.tiexames.com.br
Benefícios .................................................................................................................... 57
6. Gerenciamento de Mudanças ................................................................................ 59
Introdução .................................................................................................................... 59
Objetivo........................................................................................................................ 59
Conceitos ..................................................................................................................... 60
Tipos de Mudanças ...................................................................................................... 63
Atividades .................................................................................................................... 63
Comitê de Controle de Mudanças (CCM)..................................................................... 65
Benefícios .................................................................................................................... 67
7. Gerenciamento de Liberações............................................................................... 69
Introdução .................................................................................................................... 69
Objetivo........................................................................................................................ 69
Conceitos ..................................................................................................................... 70
Atividades .................................................................................................................... 72
Benefícios .................................................................................................................... 77
8. Gerenciamento da Configuração........................................................................... 79
Introdução .................................................................................................................... 79
Objetivos ...................................................................................................................... 79
Conceitos ..................................................................................................................... 81
Atividades .................................................................................................................... 84
Benefícios .................................................................................................................... 88
Melhores Práticas ........................................................................................................ 90
9. Gerenciamento do Nível de Serviço ...................................................................... 91
Introdução .................................................................................................................... 91
Objetivo........................................................................................................................ 92
Conceitos ..................................................................................................................... 93
Atividades .................................................................................................................... 96
Benefícios .................................................................................................................... 99
Problemas Comuns.................................................................................................... 100
4
www.tiexames.com.br
IPD - Indicadores Principais de Desempenho ............................................................ 100

10. Gerenciamento da Disponibilidade ..................................................................... 101
Introdução .................................................................................................................. 101
Objetivo...................................................................................................................... 101
Conceitos ................................................................................................................... 102
Descrição do Processo .............................................................................................. 103
Atividades .................................................................................................................. 104
Planejamento ............................................................................................................. 105
Papéis e Responsabilidades ...................................................................................... 106
Relacionamentos ....................................................................................................... 107
Benefícios .................................................................................................................. 107
11. Gerenciamento da Capacidade............................................................................ 110
Introdução .................................................................................................................. 110
Objetivo...................................................................................................................... 110
Atividades .................................................................................................................. 113
Benefícios .................................................................................................................. 117
12. Gerenciamento da Continuidade dos Serviços de TI......................................... 119
Introdução .................................................................................................................. 119
Objetivo...................................................................................................................... 121
Atividades .................................................................................................................. 122
Benefícios .................................................................................................................. 127
13. Gerenciamento Financeiro para Serviços de TI ................................................. 129
Introdução .................................................................................................................. 129
Objetivo...................................................................................................................... 129
Atividades .................................................................................................................. 131
Benefícios .................................................................................................................. 134
Apêndice: Gerenciamento de Qualidade ................................................................... 137
Aperfeiçoamento de Qualidade contínua: O Ciclo de Deming .................................... 137
Padrões de Qualidade................................................................................................ 138
Sistemas de Qualidade Total: EFQM ......................................................................... 139
Bibliografia................................................................................................................... 141
5
www.tiexames.com.br
Introdução
Introdução ao Cenário
Por muitos anos, algumas organizações puderam continuar seus negócios, ainda que
tivessem pouco apoio da TI. Hoje a realidade é diferente: a Tecnologia da Informação é
um fator crítico de sucesso para a organização, e em até muitos casos acaba sendo seu
diferencial competitivo no mercado. Existem determinados ramos de negócio que são
quase impossíveis de serem imaginados hoje sem o apoio da TI, como por exemplo o
sistema bancário. Seria impossível tentar controlar as contas dos clientes sem o apoio de
um sistema de banco de dados. É difícil você encontrar hoje um ramo de negócio que não
utilize serviços de TI em nenhum processo.
Hoje para muitas empresas a TI se tornou um parceiro estratégico. Ela faz parte do
negócio. Atualmente as decisões sobre os investimentos em TI são tratadas nas reuniões
de planejamento estratégico pelo conselho administrativo da empresa - não é mais
possível tratar a TI isoladamente. A TI deixou de ser tratada por técnicos e passou a ser
incorporada na estratégia da empresa para alcançar seus objetivos. Pelo menos, deveria
ser assim em organizações que enxergam a TI como essencial para o negócio.
Com o aumento do peso de importância dentro da organização, a TI passou a ter vários

desafios. Vejamos alguns:
Alinhamento dos serviços de TI com as necessidades atuais e futuras do

negócio. A TI precisa começar a entender de negócios para poder participar junto
do plano estratégico da empresa. As decisões de investimentos de TI devem levar
em conta os objetivos da organização a longo prazo. Os esforços nos
investimentos em tecnologia devem ser orientados a trazer resultados para os
negócios da organização. O plano de TI precisa refletir as metas do negócio.
Ambientes de TI cada vez mais complexos. O número de tecnologias e
fornecedores aumentou, fazendo com que a vida do gerente de TI se complicasse
mais ainda. Se no passado todos os sistemas de TI se reuniam em apenas um
único mainframe, hoje há vários servidores, várias plataformas tecnológicas. Em
muitas organizações a área de TI passou por terceirizações, preocupando-se em
gerir contratos, entender as demandas dos clientes e usuários e manter o
relacionamento com fornecedores. As organizações também expandiram seus
negócios: possuem unidades no Brasil e em diversos países, e para cada unidade
a área de TI deve prover suporte.
Dependência da TI para o negócio. A dependência tão grande sobre os serviços
de TI também fez com que a organização a desse maior atenção. Chegamos a um
ponto em que se os serviços de TI pararem, todas as outras operações do negócio
também param. Os serviços de TI devem buscar arranjos, fórmulas para manter
sua disponibilidade máxima com o melhor custo, trazendo o menor prejuízo para o
negócio em suas paradas.
Redução de custos e riscos. Devido à grande dependência da TI para o negócio
e também aos altos investimentos feitos nos projetos, a administração tem
buscado minimizar os custos através de uma melhor gestão por projetos, tratando
também os riscos relacionados a novas mudanças. Além disto, a cada ano que
6
www.tiexames.com.br
passa os orçamentos estão cada vez mais apertados - é preciso buscar formas
para reduzir custos.
Justificativa para retorno sobre os investimentos em TI. De alguma forma o
investimento em TI precisa ser justificado. É preciso demonstrar o ROI (Retorno de
Investimento), ou seja, o que a organização vai ganhar ao fazer determinado
investimento em TI. O pessoal de TI têm tido muita dificuldade de fazer estas
justificativas de ROI, justamente pelo fato de que a maioria do pessoal de TI é
muito técnico e não entende nada do negócio.
Conformidade com leis e regulamentos. Instituições financeiras e empresas
com ações em bolsas internacionais são agora obrigadas a cumprir regulamentos
impostos pelo governo e outras entidades, como por exemplo a Lei Sarbanes-
Oxley. A TI está totalmente relacionada ao cumprimento destas leis, buscando
adequação dos seus sistemas e processos para atender aos requisitos impostos.
Manter a segurança sobre as informações. A necessidade por informação em
qualquer lugar fez com que os sistemas e bancos dados fossem expostos à
vulnerabilidade de ataques de hacker e vírus. A segurança é um ponto de grande
relevância para os gestores de TI - a organização não pode correr o risco de
perder suas informações, pois isto pode trazer prejuízos financeiros e até mesmo
prejudicar a reputação da empresa no mercado.
Em virtude deste cenário onde a TI aparece com grande importância para o negócio da
empresa, buscando por otimização de seus processos e redução de custos e riscos,
várias frameworks de processos e melhores práticas foram criados. A figura abaixo
mostra a evolução destas frameworks e seus níveis de maturidade em termos de
Gerenciamento de Serviços.
Maturidade do
Gerenciamento de TI
ITIL v.3
ISO
BS 20.000
15000
ITIL
HP v.2
ITITSM
IBM IL
Idade ISMA
Escura da
TI
Tempo
1970 1980 1990 2000 2005 2007
A ITIL (IT Infrastructure Library), que é uma biblioteca composta das boas práticas para
Gerenciamento de Serviços de TI, é hoje o modelo mais utilizado quando se trata de
7
www.tiexames.com.br
suporte e entrega de serviços de TI. Criada pelo governo britânico em 1980, tornou-se
padrão de fato no mercado a partir de 1990. A ITIL na versão 2 é composta de 7 livros
principais. Já na ITIL V3, os livros foram todos reescritos e o conteúdo disponibilizado em
5 livros principais. A ITIL não se trata de uma metodologia e sim de um conjunto de boas
práticas adotadas em várias organizações. Atualmente é a framework (framework poderia
ser traduzida como “estrutura de processos”) mais adequada para o gerenciamento de
serviços para os departamentos de TI, sendo utilizada por mais de 10.000 empresas no
mundo todo.
Podemos tratar a ITIL apenas como um consenso de como devem ser tratados os
processos dentro de área de TI. Os processos propostos são genéricos, podendo ser
utilizados por qualquer organização, seja pública ou privada, de grande ou pequeno porte.
Estes processos devem ser adotados e adaptados ao seu negócio - tenha em mente
que não existe receita pronta. A ITIL é um modelo de processos e não representa os
próprios processos com o passo-a-passo para implementar na organização. Pelo fato de
ser um modelo, a ITIL serve como inspiração para definir e melhorar processos de
Gerenciamento de Serviços de TI.
Não é correto afirmar que um determinado processo na organização é “compatível com

a ITIL”, nem mesmo dizer que “vamos implantar a ITIL”. Ninguém implanta livros!!!!! O
objetivo é implementar o Gerenciamento de Serviços de TI, e para isto a ITIL pode ser
utilizada como base das boas práticas do mercado.
Os processos e organizações podem ser avaliados se estão compatíveis com as normas

BS 15.000 ou ISO/IEC 20.000 (criada em dezembro de 2005), que são padrões de
Gerenciamento de Serviços de TI. Entretanto, nem ferramentas ou pessoas podem ser
certificadas em BSs ou ISOs. A ISO 20.000 é voltada para organizações prestadoras de
serviços de TI e tem como foco avaliar a conformidade dos processos da empresa com as
práticas sugeridas. O padrão ISO substitui o padrão BS 15.000. No Brasil já existem
algumas empresas certificadas na ISO/IEC 20.000, e acredita-se que esta certificação vai
se tornar uma tendência para selecionar fornecedores no mercado.
A EXIN também disponibiliza hoje uma certificação para profissionais que conhecem a
norma ISO/IEC 20.000, que é a certificação ISO 20.000 Foundation. A TIEXAMES
disponibiliza um curso de interpretação desta norma que ajudará você a se preparar para
o exame de certificação. Como esta norma é baseada na ITIL, o profissional que já for
certificado em ITIL Foundation poderá facilmente também conquistar a certificação ISO
20.000 Foundation.
Introdução à ITIL
A ITIL foi desenvolvida inicialmente pela CCTA (Central Computing and

Telecommunications Agency) e agora está sob o domínio do OGC (Office of Government
Commerce). O OGC é o ministério de comércio do Reino Unido e é o proprietário da ITIL.
A biblioteca da ITIL foi desenvolvida pela CCTA, e tinha como objetivo melhorar os
processos dos departamentos de TI do governo britânico. Desde o seu surgimento em
1980, as empresas e outras entidades do governo perceberam que as práticas sugeridas
poderiam ser aplicadas também em seus processos de TI. Em 1990 a ITIL acabou se
8
www.tiexames.com.br
tornando um padrão de fato em todo o mundo, e a partir dela houve várias adaptações de
outros fornecedores, como a Microsoft, IBM e HP. A Microsoft oferece hoje o MOF, que é
um modelo que foi baseado na ITIL.
A ITIL atualmente desperta grande interesse no mercado pois há uma preocupação com o
Gerenciamento de Serviços de TI nas empresas. Como falamos anteriormente, a grande
dependência da TI para os negócios faz com que os gestores de TI busquem a adoção
das melhores práticas com o objetivo de trazer resultados positivos, como redução de
custos e agilidade em seus processos.
Mais de 10.000 empresas no mundo todo já adotaram as melhores práticas da ITIL. Isto
comprova sua maturidade e aceitação pelo mercado. O Brasil e os EUA estão na fase
inicial de implementação destas práticas, mas muitas empresas aqui já as adotaram e já
temos vários casos de sucesso.
A ITIL oferece uma estrutura de processos para manter uma infra-estrutura de TI. Cada
um destes processos cobre uma ou mais tarefas do provedor de TI, tais como
desenvolvimento de serviços, gerenciamento da infra-estrutura, fornecimento de serviços
e suporte a serviços.
Estes processos propiciam o uso das boas práticas, fazendo com que o provedor de TI
possa adotá-las independente da estrutura da organização.
As boas práticas da ITIL têm como objetivos:

Servir de inspiração para melhorar seus processos de TI
Sugerir onde é possível chegar, pois outras empresas já conseguiram resultados
positivos
Sugerir para que servem os processos e práticas
Sugerir por que adotar os processos e práticas
Muitas destas boas práticas são claramente identificáveis, e na verdade são utilizadas na
maioria das organizações de TI. Talvez muitos dos conceitos que você vai ver aqui você
já utiliza ou conheça.
A ITIL apresenta as boas práticas de forma coesa. Os livros da ITIL V2 descrevem como
estas práticas podem ser otimizadas e como a coordenação das atividades pode ser
aperfeiçoada. Os livros também explicam como os processos podem ser formalizados
dentro de uma organização, fornecem uma referência dentro da organização para uma
terminologia padronizada, ajudam a definir os objetivos e a determinar o esforço
requerido.
A ITIL não pode ser vista como uma metodologia, pois as práticas sugeridas são flexíveis
a ponto de você adaptá-las aos seus processos. Já uma metodologia possui uma
implementação mais rígida, com regras bem definidas. “Na ITIL tudo pode, nada deve.”
A vantagem da adoção das boas práticas está no fato de você não ter que “reinventar a
roda”. Adotar práticas já testadas propicia um ganho de tempo e retorno mais rápido
sobre o projeto de implementação de um Gerenciamento de Serviços.
9
www.tiexames.com.br
Organizações Envolvidas com a ITIL
A figura abaixo apresenta as organizações que estão envolvidas na manutenção e

disseminação da ITIL:
Corpo do Governo –
Office Of Government Garante a qualidade na estrutura
Commerce (OGC) atual e futura. Proprietário da ITIL.
itSMF Parceiro estratégico para promover as práticas

(it Service Management Forum) da ITIL no mercado.
ITILV3
Institutos de Exame – Gerenciam a definição
EXIN APMG ISE e execução dos exames de certificação.
B Credenciam os centros de treinamento.
Institutos de Treinamentos – Organizações

Provedores de credenciadas para oferecer treinamento
Treinamento em ITIL.
OGC (Antiga CCTA)

A ITIL era originalmente um produto da CCTA. A CCTA era a Agência de Processamento
de Dados e Telecomunicações do governo britânico. No dia 1 abril de 2001, a CCTA foi
fundida com o OGC (Office of Government Commerce), que é agora o novo "proprietário"
da ITIL. O OGC busca modernizar a forma de procurement (licitações) no governo, e
agregar valor substancial para o uso do dinheiro público. O OGC promove o uso das
melhores práticas em muitas áreas (por exemplo, gestão de projetos, procurement e
Gerenciamento de Serviços de TI). O OGC publica diversas séries (bibliotecas) dos livros
escritos por especialistas britânicos e outros internacionais de várias empresas.
A biblioteca consiste em um número claro de “Código de Práticas” para promover e

fornecer serviços de TI de forma eficiente e eficaz.
itSMF
O Fórum de Gerenciamento de Serviços de Tecnologia da Informação (itSMF)
originalmente ficou conhecido como Fórum do Gerenciamento da Infra-estrutura de TI
(itIMF) e foi criado no Reino Unido em 1991. O OGC não tem objetivos comerciais com a
ITIL, e também não tinha interesse em ficar divulgando as práticas da ITIL mundo afora.
Por isto repassou esta missão para o itSMF. O itSMF holandês foi o primeiro chapter
(capítulo), criado em novembro de 1993. Em 2001 mais de 500 empresas tornaram-se
membros, entre fornecedores e grupos de usuários. Atualmente existem chapters do
10
www.tiexames.com.br
itSMF em vários países, tais como África do Sul, Bélgica, Alemanha, Áustria, Suíça, EUA,
Austrália e Brasil, que participam no grupo internacional do itSMF.
O itSMF promove a troca de informações e experiências que permitem às organizações

melhorarem os serviços que fornecem. Organiza congressos, encontros especiais e
outros eventos sobre assuntos ligados a Gerenciamento de Serviços de TI.
Os associados contribuem também com o desenvolvimento do assunto. A associação

publica um boletim de notícias e fornece um website com informações sobre suas
atividades (http://www.itsmf.com.br).
O capítulo brasileiro do itSMF, como é chamada uma representação em um país, está

estabelecido em São Paulo. Existem em alguns estados extensões do itSMF para
disseminar as práticas na região - estas são conhecidas como Grupos de Interesse Local,
abreviados de LIGs. No website do itSMF você poderá verificar se existe um LIG na sua
região.
EXIN e ISEB
Da mesma forma que o OGC não tinha interesse em ficar divulgando as práticas da ITIL,
ele resolveu fazer uma licitação para que outras organizações se responsabilizassem
pelas certificações profissionais e treinamentos credenciados. O EXIN e a ISEB venceram
esta licitação no passado. O Examination Institute for Information Science (EXIN) e a
Information Systems Examinations Board (ISEB) juntos desenvolveram uma certificação
profissional para a ITIL V2. Isto foi feito em cooperação com o itSMF. O EXIN e a ISEB
são organizações sem fins lucrativos que cooperam para oferecer uma escala de
qualificação ITIL V2 em três níveis:
• Certificado Foundation em Gerenciamento de Serviços de TI

• Certificado Practitioner em Gerenciamento de Serviços de TI
• Certificado Manager em Gerenciamento de Serviços de TI
O sistema de certificação é baseado nas exigências para cumprir o papel relevante dentro
de uma organização de TI. Até agora os certificados foram concedidos para mais 600.000
profissionais de TI em mais de 30 países.
Na ITIL V3 o esquema de certificação foi atualizado e existem mais opções de

treinamento. Para mais informações sobre o novo esquema, consulte o site da
TIEXAMES.
11
www.tiexames.com.br
APMG
Com o lançamento da ITIL V3, o OGC abriu uma nova concorrência para empresas que
estivessem interessadas em assumir o controle de treinamentos e certificações na nova
versão da ITIL. Nesta nova concorrência, quem ganhou foi outra organização: o APMG.
Agora o APMG está envolvida no novo esquema de certificação da ITIL V3, e o EXIN e a
ISEB apenas fazem a distribuição dos novos exames.
Certificações para os profissionais de TI na ITIL V2
Para obter a certificação Foundation não é necessário participar de

um curso oficial, nem mesmo comprovar experiência na área. É
importante que o candidato já atue na área de serviços de TI - isto
facilita os estudos. Com o apoio de livros e simulados é possível
obter a certificação de maneira fácil. A prova é composta de 40
questões, sendo que é necessário obter um acerto de 65% (26
questões apenas). As questões são objetivas e de múltipla escolha.
As provas podem ser feitas em qualquer lugar do Brasil através de
centros de testes VUE (www.vue.com) ou PROMETRIC
(www.prometric.com). As provas eletrônicas estão disponíveis nos
idiomas inglês, espanhol e português e custam US$ 160,00.
Na certificação Practitioner o candidato deve realizar um curso

oficial reconhecido pelo EXIN ou pela ISEB. Este curso será focado
em 2 ou 3 processos da ITIL, dando ao aluno um conhecimento
mais profundo sobre os processos estudados. É ideal para as
pessoas que vão trabalhar na parte operacional do projeto de
implementação da Gestão de Serviços de TI. O curso normalmente
tem a duração de 3 dias e a avaliação do candidato acaba sendo
feita durante o próprio treinamento. É pré-requisito já possuir a
certificação Foundation para este nível.
A certificação Manager é voltada para os gestores de TI que terão

uma visão ampla e aprofundada de todos os processos da ITIL.
Para realizar esta certificação também é necessário um curso oficial,
e é pré-requisito ter a certificação Foundation - mas não é
necessário realizar a Practitioner. A formação Manager requer um
bom investimento, pois o curso tem duração de duas semanas, além
de workshops de preparação. O exame é composto de duas provas
realizadas em 2 dias. Cada exame foca um livro da ITIL. Esta
certificação também é muito indicada para quem busca desenvolver
carreira na área de consultoria.
Para mais informações sobre os exames de certificação consulte o

website www.exin-exams.com
12
www.tiexames.com.br
Aqui nesta apostila não iremos apresentar o esquema de certificação da ITIL V3. É
importante comentar que as certificações na ITIL V2 serão oferecidas enquanto houver
demanda de mercado.
Para conhecer o novo esquema de certificação da ITIL V3 consulte o link abaixo no nosso
site:
http://www.tiexames.com.br/ITIL3_esquema_certificacao.php
Estrutura de Livros da ITIL V2
ITIL (IT Infrastructure Library)
A ITIL V2 é uma série de livros. Assim como o nome já sugere, é uma biblioteca (IT
Infrastructure Library). Esta seção descreverá os vários componentes da biblioteca na
versão anterior. Os livros oficiais do OGC estão disponíveis para compra em algumas
livrarias. Para comprar estes livros, consulte o site www.itsmf.com.br. A utilização destas
práticas na sua empresa é de domínio público, entretanto todo o material da ITIL possui
direitos de cópia da coroa inglesa.
Cada um dos livros da ITIL faz parte da framework completa da ITIL. A ITIL na verdade é
uma biblioteca de muitos livros. Esta apostila é focada na entrega do serviço e nos livros
de Suporte a Serviços e Entrega de Serviços. Nós descrevemos a ITIL conforme estes
dois livros durante toda a apostila.
A ITIL define os objetivos e atividades, as entradas e saídas de cada um dos processos

encontrados em uma organização de TI. Entretanto, a ITIL não dá uma descrição
específica de como estas atividades devem ser executadas, pois em cada organização
estas são diferentes, ou seja, não existe receita pronta. A ênfase está em sugestões que
foram provadas na prática, mas que dependendo das circunstâncias podem ser
implementada de várias formas. A ITIL não oferece um método de implementação, ao
invés disto oferece uma framework para planejar os processos mais comuns, papéis e
atividades, indicando as ligações entre elas e que linhas de comunicação são
necessárias.
A ITIL é baseada na necessidade de fornecer serviços de alta qualidade, com ênfase no

serviço e no relacionamento com o cliente. A organização tem que cumprir exigências do
cliente, o que significa um bom relacionamento com ele, com os parceiros e com os
fornecedores.
Parte da filosofia da ITIL é baseada nos sistemas de qualidade, tais como a série ISO-
9000. A ITIL suporta tais sistemas de qualidade com uma descrição clara dos processos e
das melhores práticas em Gerenciamento de Serviços de TI. Isto pode significativamente
reduzir o tempo necessário para obter a certificação ISO.
Originalmente, a ITIL V1 era consistida por um grande conjunto de livros. Cada um deles
descrevia uma área específica de manutenção e operação da infra-estrutura de TI. Os
dez livros que descreviam o Suporte de Serviços e Entrega de Serviços eram
13
www.tiexames.com.br
considerados o núcleo da ITIL V2. Havia aproximadamente outros 40 livros nos assuntos
complementares relacionados ao Gerenciamento de Serviços de TI, desde mandar um
telegrama ao cliente a relacionar-se com ele. Entretanto, a série original dos livros da
biblioteca de infra-estrutura focou-se mais no Gerenciamento de Serviços de TI a partir da
perspectiva de TI.
O conjunto de Perspectiva de Negócio foi introduzido para construir uma ponte entre o
negócio e a organização de TI.
O núcleo dos livros da ITIL V2 foi revisado e publicado apenas como dois livros: Suporte a
Serviços e Entrega de Serviços. Isto eliminou sobreposições e inconsistências da série
anterior.
O quebra-cabeça da ITIL V2 mostra os principais elementos localizados nos seus livros.

Cada um destes elementos se relaciona entre si, e se sobrepõem em alguns tópicos.
Os 7 livros principais da ITIL V2 são:
• Perspectiva de Negócio
• Entrega de Serviço
• Suporte a Serviço
• Gerenciamento da Segurança
• Gerenciamento da Infra-estrutura
• Gerenciamento de Aplicações
• Planejamento da Implementação do Gerenciamento de Serviços
PLANEJAMENTO PARA IMPLEMENTAR O A

O GERENCIAMENTO DE SERVIÇOS
T
N Gerenciamento de Serviços
E
E C
A GERENCIAMENTO N
G PERSPECTIVA SUPORTE AO SERVIÇO DA INFRA-
DO NEGÓCIO ESTRUTURA DA O
Ó TIC L
C O
I ENTREGA DO SERVIÇO
G
O GERENCIAMENTO I
DA SEGURANÇA
A
GERENCIAMENTO DE APLICAÇÕES
Fonte: livro Service Support do OGC
14
www.tiexames.com.br
Estes 7 módulos constituem o corpo da ITIL V2. Abaixo você terá uma descrição
resumida do propósito de cada livro:
Suporte a Serviços: descreve os processos associados ao suporte do dia-a-dia e

atividades de manutenção associadas com a provisão de serviços de TI.
Entrega de Serviços: cobre os processos necessários para o planejamento e entrega de

serviços de TI com qualidade, e se preocupa ao longo do tempo com o aperfeiçoamento
desta qualidade.
ICT - Gerenciamento da Infra-estrutura: cobre todos os aspectos do Gerenciamento da

Infra-estrutura como a identificação dos requisitos do negócio, testes, instalação, entrega
e otimização das operações normais dos componentes que fazem parte dos serviços de
TI.
Planejamento para Implementação do Gerenciamento de Serviços: examina questões

e tarefas envolvidas no planejamento, implementação e aperfeiçoamento dos processos
do Gerenciamento de Serviços dentro de uma organização. Também foca questões
relacionadas à cultura e mudança organizacional.
Gerenciamento de Aplicações: descreve como gerenciar as aplicações a partir das

necessidades iniciais dos negócios, passando por todos os estágios do ciclo de vida de
uma aplicação, incluindo sua saída do ambiente de produção (quando o sistema é
aposentado). Este processo dá ênfase a assegurar que os projetos de TI e as estratégias
estejam corretamente alinhados com o ciclo de vida da aplicação, assegurando que o
negócio consiga obter o retorno do valor investido.
Perspectiva de Negócio: fornece um conselho e guia para ajudar o pessoal de TI a

entender como eles podem contribuir para os objetivos do negócio e como suas funções e
serviços podem estar mais bem alinhados e aproveitados para maximizar sua
contribuição para a organização.
Gerenciamento da Segurança: detalha o processo de planejamento e gerenciamento

em um nível mais detalhado da segurança da informação e serviços de TI, incluindo todos
os aspectos associados com a reação da segurança dos incidentes. Também inclui uma
avaliação e gerenciamento dos riscos e vulnerabilidade, e implementação de custos
justificáveis para a implementação de contra-recursos (estratégia de segurança).
Esta apostila irá descrever apenas os dois livros principais da ITIL: Suporte a Serviços e
Entrega de Serviços, considerados o coração da framework.
15
www.tiexames.com.br
Suporte a Serviços
O livro Suporte a Serviços descreve como um cliente

consegue acesso aos serviços para suportar seus
negócios.
Este livro cobre os seguintes assuntos:

• Central de Serviços
• Gerenciamento de Incidentes
• Gerenciamento de Problemas
• Gerenciamento da Configuração
• Gerenciamento de Mudanças
• Gerenciamento de Liberação
A figura abaixo apresenta o relacionamento entre os processos do livro Suporte a

Serviços.
CLIENTES & USUÁRIOS
Suporte a
Serviços
SERVICE-DESK
Inform.
Mudanças Inform.
Liberações
Gerenciam.
Ferramentas Incidentes
Monitoramento Gerenciam.
Problemas
Gerenciam.
Mudanças
Gerenciam.
Liberações
Gerenciam.
Configuração
BDGC
Problemas Relacionamento
Incidentes
Erros Conhecidos Mudanças Liberações Entre ICs
16
Entrega de Serviços
O livro Entrega de Serviços descreve os serviços que o

cliente necessita, e o que é necessário para fornecer estes
serviços.
Este livro cobre os seguintes assuntos:

• Gerenciamento do Nível de Serviços
• Gerenciamento Financeiro para Serviços de TI
• Gerenciamento da Capacidade
• Gerenciamento da Disponibilidade
• Gerenciamento da Continuidade dos Serviços de TI
• Gerenciamento da Segurança (com referência ao
livro Gerenciamento da Segurança)
A figura abaixo apresenta o relacionamento entre os processos do livro Entrega de

Serviços.
CLIENTES & USUÁRIOS
Entrega de
Serviços
Informação
Plano de
Capacidade
Níveis de
Serviço &
Relatórios Orçamento,
Informações
de cobrança Informação
Plano de
Continuidade
Open
Hrs 9-5
Gerenciam.
Capacidade
Gerenciam.
Disponibilidade
Gerenciam.
Nível de Serviços
Gerenciam.
Finanças Gerenciam.
Continuidade
Serviços de TI
Ferramentas
Monitoração
17
Estrutura de livros da ITIL V3
A framework da ITIL V2 é um conjunto de livros com alguns problemas de consistência –

não há uma conexão bem elaborada entre os processos pelo fato de os livros terem sido
escritos em momentos diferentes. A ITIL foca basicamente a eficiência e eficácia dos
serviços em produção. O grande público de TI lia apenas os dois livros principais: Suporte
ao Serviço e Entrega do Serviço. Mas somente pensar nisto não bastava. Pois se você
não planeja, se não antecipa as demandas, você vai ter uma TI muito reativa. Foram
vários os motivadores para que os livros fossem reescritos e uma nova versão da ITIL
fosse lançada.
Então, em meados de 2007 foi lançado a ITIL V3. A estrutura passou de 7 para 5 livros
principais. Agora os livros da nova versão fazem parte do ciclo de vida do serviço. Esta é
a grande mudança estrutural na ITIL V3.
Melhoria de Serviço
Continuada
Desenho
de Serviço
Operação
de Serviço
Estratégia
de Serviço
Framework ITIL® V2
Transição
de Serviço
Ciclo de vida do serviço da ITIL V3
A abordagem do ciclo de vida do serviço é algo novo para a TI, mas não é algo novo em
outras áreas do negócio. Temos que entender que um serviço nasce, se desenvolve, vai
para a operação e um dia ele morre ou é aposentado, e é necessário gerenciar o serviço
não só durante a sua fase adulta, mas sim desde a sua fase embrionária para que gere
valor para o negócio.
18
Conheça abaixo as capa dos livros principais.
Estratégia de Desenho de Transição de Operação de Melhoria de

Serviço Serviço Serviço Serviço Serviço
Continuada
5 livros principais
Introdução ao
Ciclo de Vida
do Serviço
O ciclo de vida do serviço tem um eixo central, que é a estratégia do serviço – é também
a fase inicial deste ciclo. Esta estratégia vai guiar todas as outras fases: Desenho de
Serviço, seguida da Transição de Serviço e Operação de Serviço. E envolvendo todas as
fases do ciclo de vida vem a Melhoria de Serviço Continuada. Processos e funções agora
estão distribuídos ao longo do ciclo de vida.
A fase de Estratégia de Serviço é a grande sacada na ITIL V3. É aqui que a TI vai se
integrar com o negócio. Nós já estamos acostumados a ver a TI como sendo apenas um
departamento de tecnologia que é comunicado sobre as decisões da empresa. E quando
o comunicado chega a TI tem que se virar para atender às demandas - e aí começam os
conflitos: falta de recursos e falta de tempo. Nesta fase de estratégia a TI tem que buscar
entender quais são as demandas dos seus clientes, identificar oportunidades e riscos,
decidir por terceirizar ou não determinados serviços e pensar no retorno para o negócio.
Nesta fase a TI vai gerenciar o seu portfolio de serviço, e este portfolio vai conter o
pipeline, o funil de serviços que é um termo que o pessoal de vendas conhece muito bem.
Todos nós sabemos que a TI sempre tem mais demanda que a sua capacidade, só que
ela vai ter que priorizar o que vai desenvolver. Nem toda demanda vira serviço, por isto
ela precisa fazer a gestão do seu portfolio. Com a Estratégia de Serviço da ITIL V3 é
possível agora ter a visão da razão de se ter um serviço no portfolio.
Na fase do Desenho de Serviço tudo que foi levantado na Estratégia de Serviço será
usado para projetar um novo serviço: custos, mercado e como o serviço será utilizado. O
serviço vai ser definido com base nesta estratégia, já pensando no valor que ele vai gerar
para os clientes. Se todas as informações forem levantadas já durante a fase de
estratégia, a TI conseguirá projetar o serviço conforme esperado. Nesta fase já se deve
19
pensar em qual será o SLA (Acordo de Nível de Serviço), quais os riscos envolvidos e os
fornecedores necessários, e qual a capacidade da infra-estrutura para suportar o serviço.
A próxima fase é a Transição de Serviço. Então se na fase anterior empacotam-se todas

as informações do desenho para colocar o serviço em operação, nesta fase o foco é no
Gerenciamento de Mudança. Ela se preocupará com todos os detalhes para que o serviço
seja colocado em produção com o menor impacto possível para a organização.
A outra fase é a Operação de Serviço: é só manter o serviço, é o dia-a-dia. Basicamente

os processos de suporte do livro da V2 estão aqui nesta fase. Então aqui vem o
gerenciamento de incidentes, problemas e solicitações. Também as funções de TI foram
incluídas aqui, como Service Desk (Central de Serviços), manutenção de data centers,
instalações técnicas e aplicações.
E envolvendo todas as fases do ciclo de vida vem a Melhoria de Serviço Continuada, que
tem um foco na qualidade, avaliando tanto o serviço como os processos de
gerenciamento das fases. Outro foco é que um serviço que foi entregue não é estático:
ele pode ser bom hoje, mas amanhã não mais, pois a demanda do usuário vai
aumentando. Então esta fase vai procurar avaliar os serviços, vai procurar obter o
feedback, e nada impede que este ciclo de vida do serviço gire várias vezes - pois pode
ser necessário repensar a estratégia do serviço.
Como vocês podem perceber, se a TI executar todas as fases ao criar um novo serviço ou
alterar um serviço existente, ela vai errar menos. Se os serviços forem desenhados
conforme os requisitos dos clientes e projetados devidamente, o pessoal de produção irá
ter menos estresse para manter o serviço. Em resumo, teremos menos re-trabalho e
maior controle sobre os custos.
O conteúdo que estamos apresentando nesta apostila é baseado na ITIL V2, e este ainda
se aplica às organizações. Os processos de suporte e entrega da versão anterior
praticamente são os mesmos na nova estrutura de livros. O mercado vai continuar
adotando a ITIL V2 por um bom tempo. Muitas organizações estão preferindo iniciar seus
projetos de ITIL na versão 2 e depois evoluir para a versão 3, pelo fato de acharem que a
versão anterior está mais simples. Por isto, tudo o que você vai aprender aqui nesta
apostila será de grande valia. Se você tiver interesse em conhecer mais a ITIL V3, faça o
nosso curso e-learning de migração. Ao fazer o nosso curso de migração você estará
habilitado para prestar o novo exame ITIL V3 Foundation.
20
Por Que a ITIL é Importante?
Como visto no capítulo Introdução ao Cenário, a área de TI tem ganhado grande

importância dentro do negócio e tem servido como meio para alcançar os objetivos da
organização. Em virtude da necessidade de um Gerenciamento de Serviço de TI mais
robusto, a biblioteca da ITIL tem ganhado destaque no mercado, servindo como apoio
para melhorar os processos de TI.
Entre os principais objetivos da adoção da melhores práticas da ITIL podemos destacar

os seguintes:
Alinhar os serviços de TI com as necessidades atuais e futuras do negócio e seus

clientes. Todos os processos da ITIL falam que a TI precisa entender os requisitos
de negócio da empresa para poder planejar e prover seus serviços para atender
expectativas.
Melhorar a qualidade dos serviços de TI. Através de um programa de melhoria
contínua, deve-se buscar a consistência na entrega dos serviços atendendo às
necessidades de negócio.
Reduzir custos na provisão de serviços. Este é um dos motivos-chave que levam
os gestores de TI a adotarem as melhores práticas. Já existem vários casos de
sucesso onde houve grande redução dos custos operacionais e investimentos em
TI.
Processos mais eficientes e eficazes, buscando rapidez e resultados nos
processos.
Adoção das boas práticas, evitando reinventar a roda.
Possíveis Resultados com a Adoção da ITIL
Falhas: 30% quantidade, 50% tempo de resolução

Mudanças: 25% tempo de conclusão, 50% mudanças urgentes e caras
Capacidade: 15% capacidade ociosa
CTP (TCO): 10%
Disponibilidade: 10%
Confiabilidade
Tempo de lançamento no mercado
Fonte: ITIL Forum 2003
Abaixo temos alguns exemplos de resultados alcançados em algumas empresas e

setores de TI que foram pesquisados.
Redução do custo total até 48% - Gartner

6-8% de redução de custos operacionais, $ 125 milhões de economia (10% do
budget) - Procter e Gamble
Aumento da satisfação do cliente
Aumento de resolução de incidentes de 5% para 30% com o uso de uma base de
conhecimento - IS Organizations
21
Redução de 50% no tempo médio de resolução, redução de 30% no tempo para
realizar novas mudanças, redução de 50% dos recursos - Utility Provider
Possíveis Problemas
Um projeto de implementação dos processos da ITIL pode ter vários problemas. É

importante que você esteja ciente e busque contornar alguns obstáculos já conhecidos:
Falta de patrocínio, comprometimento e entendimento. É importante que todas

as pessoas relacionadas com o projeto estejam conscientes das melhorias que a
mudança poderá trazer. O comprometimento de todos é fundamental para fazer
com que os processos sejam implementados. É necessário que este projeto tenha
um patrocinador com poder dentro da organização. Mudar a cultura da
organização e alterar a forma de trabalho das pessoas exige sempre que alguém
com maior influência na organização apóie estas mudanças.
Cultura da empresa. Se a organização não tiver cultura para a gestão de
serviços, torna-se muito complicado a TI obter a colaboração dos demais
departamentos. Foco no cliente e busca por serviços de qualidade é primordial
para sustentar um projeto de ITIL.
Excesso de expectativa. Tenha em mente que a adoção das melhores práticas
não se faz em dias. É necessário planejamento, insistência, acompanhamento e
adaptações ao longo do projeto.
Problemas na gestão do projeto. A implementação de um programa de
gerenciamentos de TI deve ser encarado como um projeto, com responsáveis por
cada etapa, prazos para implementação e recursos necessários. Para que você
possa implementar as práticas da ITIL é recomendável passar por um treinamento
como ITIL Manager. O treinamento de fundamentos não é o suficiente para
conduzir um projeto como este.
Falhas de comunicação. A estrutura de departamentos dentro da TI pode
dificultar o trabalho em equipe e o fluxo de informações.
Objetivos não alcançados: melhoria de qualidade, redução de custo, satisfação
do usuário, alinhamento de TI com a estratégia de negócio. Muitos implementam a
ITIL para alcançar estes objetivos, e quando não obtém sucesso em pouco tempo
acabam abandonando o uso da ITIL. O não-sucesso do projeto pode estar
associado à forma como a organização resolveu implementar as práticas da ITIL.
É preciso ter bom senso do que é realmente necessário na organização. É
importante saber adaptar as práticas.
22
1. Fundamentos em Gerenciamento de Serviços de TI
Introdução
As necessidades dos clientes devem ser entendidas pelo provedor de TI. Para atender a
estas necessidades é necessário buscar e implementar soluções e tecnologias
disponíveis no mercado. É necessário ter pessoas que implementem esta tecnologia,
forneçam suporte aos usuários, negociem níveis de serviços e mantenham a solução
disponível. Para que as pessoas trabalhem de forma eficiente e eficaz são necessários
processos que digam como as atividades devem ser executadas. Deverão também existir
processos que controlem e monitorem a entrega de serviços sempre com o mesmo
padrão. Pessoas, processos e tecnologia são os três elementos principais do
Gerenciamento de Serviços de TI, e os três juntos fornecem serviços que atendam às
necessidades dos clientes.
Agrupando as atividades em processos,

seu controle se torna mais fácil,
possibilitando a criação de métricas para
acompanhamento de performance. Os
processos devem ser bem definidos para
buscar a eficiência e eficácia. Lembre-se:
processos que não são possíveis de
monitorar através de indicadores não são
viáveis. De nada vale se você não puder
medir o processo, ou seja, se não há
controle sobre ele.
Por que adotar o Gerenciamento de Serviços?
É preciso levar em conta que os benefícios de um programa de Gerenciamento de

Serviços podem levar tempo para ser obtidos. Entretanto há também benefícios em curto
prazo. Vejamos abaixo os principais benefícios para a empresa ao implementar uma
metodologia para o Gerenciamento de Serviços:
1) Melhor qualidade no serviço, com um suporte mais confiável.
2) Segurança e confiança da continuidade dos serviços de TI, aumentando a
habilidade para restaurar os serviços quando houver necessidade. Se sabemos
que qualquer parada em um serviço gera perdas financeiras, então ao conseguir
23
uma maior disponibilidade dos serviços o negócio deixará de perder dinheiro com
as paradas de TI.
3) Visão mais clara da capacidade atual de fornecimento de serviços.
4) Fornecimento de informações gerenciais para acompanhamento de desempenho,
possibilitando traçar melhorias.
5) Equipe de TI mais motivada: conhecendo a carga de trabalho é possível gerenciar
melhor as expectativas.
6) Maior satisfação dos clientes e usuários, com a TI entregando serviços com mais
qualidade e rapidez.
7) [Em alguns casos] Redução de custos: a partir do melhor planejamento e controle
dos processos internos é possível otimizar os custos operacionais.
8) Maior agilidade e segurança para realizar as mudanças propostas pelo negócio.
Com processos definidos e controlados é mais fácil implementar várias mudanças
simultaneamente.
Conceito de Serviço
É definido como um conjunto de componentes relacionados fornecidos para suporte a um

ou mais processo de negócios.
Exemplo:
Um sistema de faturamento é fornecido usando uma base Oracle e uma rede
O serviço de e-mail utiliza recurso de rede, servidor e link de internet
DICA: para não haver confusão sobre o que é serviço e o que é recurso de TI, tenha em
mente que serviço é sempre com o que o usuário interage diretamente. O usuário usa um
sistema, e não um banco de dados. O banco de dados não pode ser considerado um
serviço de TI, mas sim um componente de um serviço.
Conceito de Processo
Processo é um conjunto de atividades inter-relacionadas com um objetivo especifico.

Possui entradas de dados, informações e produtos para, através da identificação dos
recursos necessários ao processo, transformar estas entradas nos objetivos previstos.
Vejamos a seguir a figura que ilustra a estrutura de um processo:

• Cada processo pode ser quebrado em uma série de tarefas (ou atividades)
• Cada tarefa terá entradas e saídas
• Cada tarefa será executada por uma função (humana ou executada por software)
• A execução das funções é controlada por regras (definições de como deve ser)
• Cada processo tem que ter um proprietário - ele define o processo em si
24
Outros Conceitos
Dentro do cenário de Gerenciamento de Serviços de TI temos cliente e usuário. Vejamos

abaixo a principal diferença entre eles.
CLIENTE: é aquele que normalmente paga pelos serviços de

TI. Se a TI for um departamento interno de uma organização,
os clientes serão as unidades de negócio da empresa, como
por exemplo os departamentos de marketing, financeiro,
produção, etc. No caso de um prestador de serviços, os
clientes são as empresas atendidas.
USUÁRIO: pessoa que usa os serviços de TI no dia-dia. Um

departamento de contabilidade, por exemplo, poderá ter vários
usuários dos serviços de TI. É possível que um usuário seja
um cliente. Mas é importante que fique claro, neste conceito,
que cliente é aquele que de alguma forma PAGA pelo serviço.
Com o cliente são negociados os níveis de serviços e são desenvolvidos novos serviços.
São os usuários ligam para a Central de Serviços (service-desk ou help-desk) para
solicitar ajuda ou reportar incidentes. É importante saber quem são estas figuras dentro
do seu cenário.
PROVEDOR DE TI: fornece serviço de TI. Pode ser um

departamento de TI dentro de uma empresa ou uma empresa
prestadora de serviços de TI.
25
Melhoria Contínua
Para que uma organização de TI possa funcionar como um negócio dentro de um

negócio, é preciso traçar uma visão que inclua objetivos, metas e métricas. O
Gerenciamento de Serviços deve ter um programa de melhoria contínua. A cada ciclo
devem ser traçados os objetivos que se espera atingir em determinado prazo, avaliando
continuamente os processos e adaptando-os para obter a melhor eficiência e eficácia nos
resultados.
Esta figura acima ilustra o ciclo de melhoria contínua sugerido pela ITIL. Quando você for
adotar a ITIL, você poderá utilizar este ciclo. No primeiro momento se identificam quais
são os objetivos do negócio, o que o negócio precisa da TI para realizar suas estratégias.
Com base nisto, a TI deve organizar seus processos de suporte e de entrega. Em
seguida se faz uma avaliação, conhecida como ITIL assessment. Esta avaliação pode ser
feita através de questionários que apresentarão a situação atual de TI e os gaps (lacunas)
entre o que está sendo feito na prática e o que está sendo sugerido nos livros da ITIL. Na
área do aluno em nosso site você poderá baixar um modelo de questionários. Depois que
você já conhece a sua realidade e a distância desta para o que o modelo da ITIL sugere,
você pode fazer um plano de implementação de melhorias nos seus processos. Uma vez
que este plano foi implementado, é necessário avaliar se os processos desenhados estão
gerando os resultados previstos, se eles estão colaborando para a realização das
estratégias do negócio. Esta avaliação pode ser feita por meio de métricas usando
indicadores. A ITIL tem uma série de indicadores para cada processo.
Este ciclo pode se repetir várias vezes. A melhoria contínua, como o próprio nome diz, é
contínua. Continuamente você precisa verificar se os processos estão gerando
resultados, e sempre há algo a melhorar. Um processo nunca chega ao nível
OTIMIZADO, mas sim no nível OTIMIZANDO. A TI está sempre passando por inovações,
e estas inovações impactam os processos existentes. Por isto sempre haverá algo a
melhorar ou inovar em seus processos. Nada é estático para sempre.
26
3. Central de Serviços
Introdução
A Central de Serviços, também conhecida em inglês como service-desk é uma função

dentro da TI que tem como objetivo ser o ponto único de contato entre os
usuários/clientes e o provedor de serviços de TI.
A proposta sugerida é separar, dentro das operações de TI, quem faz parte do suporte
aos usuários e quem vai realizar atividades de resolução de problemas e
desenvolvimento. Ter uma área específica para o suporte traz vantagens para os
usuários, propiciando um suporte com maior agilidade e qualidade, e propiciando mais
eficiência para a equipe de TI, pois o técnico especialista acaba não sendo mais
interrompido pelas chamadas diretas dos usuários.
Não há nada mais aborrecedor do que você ligar para um número de suporte e passar por
várias pessoas e departamentos para conseguir resolver o seu problema. Com a Central
de Serviços haverá pessoas focadas em resolver as solicitações dos usuários, evitando
colocar os usuários em contato direto com as equipes de suporte ou desenvolvimento.
Fonte: www.piada.com
Você certamente já conhece o funcionamento de uma help-desk. A Central de Serviços é

uma evolução deste conceito. Uma help desk tradicionalmente atende problemas de
hardware e softwares básicos, já a Central de Serviços assume todas as solicitações dos
usuários relacionadas a qualquer serviço prestado pelo provedor de TI.
27
Objetivos
A implementação da Central de Serviços tem como principais objetivos:
• Funcionar como o ponto central de contato (SPOC – Single Point of Contact) entre
os usuários e o provedor de TI. A Central de Serviços funciona como o 1º. nível de
suporte aos usuários, isto é, o primeiro atendimento é feito pelo atendente de
suporte que trabalha dentro da Central de Serviços.
• Restaurar os serviços sempre que possível. A equipe de suporte deve estar
equipada com ferramentas e informações, tais como Erros Conhecidos e base de
conhecimento, para que possa oferecer soluções o mais rápido possível.
• Prover suporte com qualidade para atender aos objetivos do negócio. É
necessário que a equipe esteja bem treinada para ter conhecimento de todos os
serviços que serão fornecidos e entender o impacto que eles têm para o negócio.
• Gerenciar todos os incidentes até o seu encerramento. A Central de Serviços será
responsável pelo processo de Gerenciamento de Incidentes, e será responsável
pelo tratamento de todos os incidentes. É importante esclarecer que o processo de
Gerenciamento de Incidentes inicia na Central de Serviços, mas um incidente
pode ser escalado para outras áreas da TI. Não é só a Central de Serviços que
está envolvida na resolução de um incidente. É de responsabilidade também da
Central de Serviços monitorar o cumprimento dos acordos estabelecidos nos
ANSs (SLAs - Acordos de Nível de Serviço).
• Dar suporte a mudanças, fornecendo comunicação aos usuários sobre o
agendamento de mudanças. A Central de Serviços é uma área que pode executar
pequenas mudanças ou mudanças-padrão que não têm risco para o negócio. A
própria Central de Serviços pode executar tudo aquilo que já tem procedimentos
escritos, que é rotineiro.
• Aumentar a satisfação do usuário, provendo suporte com maior qualidade,
estando sempre de prontidão para o atendimento, buscando solucionar os
incidentes de forma mais rápida.
• Maximizar a disponibilidade do serviço. Se houver alguém focado em restaurar os
serviços após o incidente, isto conseqüentemente aumentará a disponibilidade do
serviço.
Descrição
A Central de Serviços não é um processo da ITIL - é uma função. É importantíssima

esta diferenciação entre o que é um processo e o que é uma função. Uma função é um
grupo ou uma área da empresa que executa determinadas atividades. A Central de
Serviços nada mais é do que uma área que reúne um grupo de atendentes com a função
de prestar suporte aos usuários.
O Gerenciamento de Serviços de TI está criado em torno da entrega de níveis de serviços

estabelecidos aos usuários finais, e para isto é necessário ter uma área com o foco de:
• Dar suporte aos usuários à medida que eles requerem ajuda para o uso dos
serviços de TI.
28
• Monitorar o cumprimento dos níveis de serviços estabelecidos nos ANSs. O
Gerenciamento do Nível de Serviços é um habilitador de negócio primordial para
esta função.
Atividades
A Central de Serviços tem várias responsabilidades primárias. São elas:
• Receber e gravar TODAS as chamadas dos usuários

• Gravar e acompanhar incidentes e reclamações
• Prover uma avaliação inicial dos incidentes
• Monitorar/escalar incidentes por ANS
• Comunicar mudanças planejadas nos níveis de serviço
• Encerrar os incidentes com confirmação
• Manter os usuários informados sobre o progresso de suas requisições
• Produzir relatórios de gerenciamento
• Coordenar os grupos de suporte de 2º e 3º níveis
• Prover informações gerenciais
• Identificar necessidades de treinamento dos usuários
• Contribuir na identificação de problemas
Controle de Incidentes
A Central de Serviços é responsável por registrar todos os incidentes e controlá-los. A

Central de Serviços pode usar diferentes origens para registrar os incidentes:
• Telefone
• E-mail
• Internet
• Fax
• Visita pessoal
A Central de Serviços não está envolvida apenas com o Gerenciamento de Incidentes.

Atividades de outros processos podem ser executadas também nesta função.
Qualificações do Pessoal
A equipe de suporte que fará parte da Central de Serviços deverá ter algumas
qualificações mínimas, como:
• Habilidades interpessoais - ser...

o Paciente
o Comunicativo
o Amigo
o Entusiasmado
o Assertivo
o Empático
29
o Honesto
• Entendimento dos serviços utilizados pelo negócio
• Conhecimento técnico necessário para fornecer o suporte
Quanto ao conhecimento técnico podemos ter 3 tipos de qualificação. A decisão pela

escolha do nível dependerá do tipo de suporte e dos clientes que serão atendidos:
• Skilled (hábil) – qualificado tecnicamente

• Unskilled – pouco conhecimento técnico
• Expert (perito) – especialista
Se o usuário que liga para a Central de Serviços é um usuário mais experiente com
necessidade de resolver questões mais complexas, pode ser mais adequado utilizar uma
equipe de atendentes skilled ou experts.
Tipos de Centrais de Serviço
Central de Atendimento (Call Center)

Voltada para grandes volumes de chamadas e transações por telefone. Neste caso esta
Central não atua sobre as transações, e as encaminha para a área devida dentro da
organização.
Central de Suporte (Help Desk)

O principal objetivo é que nenhuma requisição seja perdida ou não atendida mesmo
depois de cadastrada. Tem também como função resolver e coordenar incidentes,
propiciando a interface (ou comunicação) com o Gerenciamento da Configuração.
Central de Serviços (Service Desk)

A característica principal é a abrangência dos serviços, pois o processo de negócio neste
caso está integrado, não só resolvendo incidentes, mas também problemas e dúvidas e
fazendo interface com as requisições de mudanças.
Estruturas de Central de Serviços
Em geral as empresas preferem manter centrais de atendimentos locais, ou seja, por

regiões. Isso ocorre devido ao regionalismo. Esta forma de atendimento gera um custo
maior e dificuldade de padronização.
Existem três possíveis formas de realizar o atendimento:

• Local
• Centralizado
• Virtual
Vamos ver a seguir como cada uma destas possibilidades funciona.
Central de Serviços Local
Centrais de Serviço Locais são criadas para atender a necessidades locais de cada
unidade de negócio. Este tipo de estrutura é escolhido quando há necessidades
30
especificas para cada unidade de negócio, onde o atendimento é facilitado devido ao fato
da equipe de suporte já estar implantada no local. Normalmente neste tipo de estrutura o
custo operacional é maior, devido ao fato de manter várias estruturas físicas com recursos
como hardware e software específicos para cada uma.
Usuário 1 Usuário 2 Usuário 3
Central de Serviços
Suporte
Terceiros Redes ERP Manutenção
Interno
Figura: Central de Serviços Local
Este tipo de Central local é muito comum em empresas multinacionais, onde cada planta
(filial) tem uma estrutura de TI local, pois cada filial tem a sua própria infra-estrutura de TI
assim como sistemas próprios.
31
Central de Serviços Centralizada
Uma Central de Serviços Centralizada tem como objetivo centralizar todas as solicitações
de suporte em um único local. Este modelo leva à redução de custos operacionais,
melhora o Gerenciamento de Serviços de TI e otimiza a utilização dos recursos.
Cliente 1 Cliente 2 Cliente 3
Suporte Segundo Nível
Suporte
Terceiros Redes ERP Manutenção
Interno
Figura: Central de Serviços Centralizada
Neste caso a organização pode ter várias filiais, mas o suporte é centralizado na matriz.
Não existe o melhor tipo de Central de Serviços - vai existir o melhor tipo para a sua
necessidade. Cada organização tem necessidades, serviços e complexidades diferentes.
32
Central de Serviços Virtual
Com o avanço das tecnologias de tele-comunicações é possível ter uma Central de

Serviços sem nenhuma posição física próxima ao usuário. Com isto é possível ter uma
Central de Serviços que funcione 24 horas por dia, atendendo a diversos clientes em
diversos locais distintos.
Conforme apresentado na figura acima, a organização poderia ter várias estruturas de TI

em países diferentes. Para que todas as filiais tenham suporte durante 24 horas, ao invés
de contratar pessoas para cobrir vários fusos horários, aproveita-se a estrutura de suporte
que está em outro país para que ela ofereça suporte às demais filiais durante um fuso
horário. Enquanto é noite em Sidnei, pode ser dia em Washington, então utilizamos o que
chamamos de “Follow the Sun”.
Esta estrutura virtual é muito utilizada por empresas que têm filiais espalhadas pelo globo.
Papéis e Responsabilidades
Em todo processo e função na ITIL você vai ter papéis, não cargos. Isto significa que a
ITIL sugere que alguém desempenhe determinado papel em relação ao processo e
função. No caso da Central de Serviço existe a figura do Gerente da Central de Serviços.
Dependendo da estrutura da organização, acaba existindo uma pessoa que tem este
cargo fixo.
Principais responsabilidades deste gerente:

Responsável pelo sucesso do suporte da Central de Serviços
Acorda interface com outras disciplinas do Gerenciamento de Serviços. Exemplo:
Gerenciamento da Configuração e Nível de Serviço
Recruta e treina a equipe
33
Avalia e compra ferramentas para a Central de Serviços (software)
Garante que todas as chamadas recebidas pela Central de Serviços serão
prontamente registradas
Garante que as requisições e consultas de clientes/usuários serão satisfeitas
dentro do tempo acordado nos ANSs
Apóia o Gerenciamento de Problema com a análise dos incidentes registrados
para determinar a causa-raiz dos problemas e mudanças necessárias através do
Gerenciamento de Mudanças, e reduzir incidentes que podem ser evitáveis
Estar presente no Comitê de Controle de Mudanças quando necessário
Revisa a função da Central de Serviços e faz recomendações de custos para
melhorias
Relacionamentos
Sendo um ponto único de contato para o serviço de TI, a Central de Serviço deve ter um
vínculo com todos os processos da ITIL. Com alguns processos este vínculo é mais claro
do que com outros.
Gerenciamento
da Configuração
Gerenciamento
de Incidentes Central de Gerenciamento
de Mudanças
Serviços
Gerenciamento Gerenciamento do
de Liberação Nível de Serviço
A Central de Serviços é, de fato, um aspecto operacional importante do processo do

Gerenciamento de Incidentes. A Central de Serviços registra e controla os incidentes.
Os incidentes podem ser relacionados aos Itens de Configuração. Se este vínculo for
suportado por um software, teremos condições de futuramente fazer todo o rastreamento
de problemas ocasionados com determinado equipamento na infra-estrutura.
Isto também permitirá à equipe da Central de Serviços resolver rapidamente os incidentes

buscando soluções relacionadas ao Item de Configuração ou ao problema relacionado.
Em alguns casos a Central de Serviços realiza mudanças pequenas e tem um vínculo

com o Gerenciamento de Mudanças e com o Gerenciamento de Liberações. A Central de
34
Serviços poderá executar atividades como instalar softwares e hardwares e também
efetuar mudanças-padrão, como por exemplo realocar fisicamente estações de trabalho
(PCs), configurar conexões de LAN, etc. É importante que estas atividades sejam
coordenadas pelo processo de Gerenciamento de Mudanças e Liberações.
O vínculo entre a Central de Serviços e o Gerenciamento do Nível de Serviço pode ser

ilustrado como o resultado da Central de Serviços monitorando os níveis de suporte e
reportando se o serviço de TI foi restaurado dentro dos limites definidos nos Acordos de
Nível de Serviços (ANSs). A Central de Serviços reportará ao Gerenciamento do Nível de
Serviços se os serviços não estiverem restaurados dentro do prazo e se procedimentos
de escalonamento não estiverem corretamente definidos para alcançar os prazos
determinados.
Principais Benefícios
A implementação de uma Central de Serviços poderá trazer vários benefícios para a TI e

para o negócio:
Aumento de acessibilidade: ponto único de contato e suporte sempre disponíveis
Produtividade: a equipe de 2º nível não é interrompida por chamadas de usuários
Redução de impacto: rapidez na restauração dos serviços
Disponibilidade do atendimento
Percepção de qualidade e satisfação dos clientes
Melhor trabalho em equipe
Melhor comunicação: a equipe da Central de Serviços terá habilidades para o
relacionamento com o usuário, e será focada em dar o feedback de suas
solicitações
Indicadores para gestão e suporte à decisão
Problemas Comuns
Não existe dúvida que a adoção da Central de Serviços terá barreiras de sucesso.
Algumas barreiras típicas que poderão ocorrer:
1. Usuários não ligarem para Central de Serviços, mas tentarem buscar uma solução
diretamente com uma pessoa que conhecem ou que ajudou da última vez.
2. A equipe técnica não estar preparada para atender às necessidades do negócio
ou dos usuários.
3. Nem todas as partes estão informadas sobre os serviços fornecidos e os níveis de
serviços acordados, resultando em frustração por parte dos usuários.
35
IPD - Indicadores Principais de Desempenho
É importante usar indicadores de controle para avaliar o desempenho da Central de

Serviços. Dentro da ITIL os chamamos de IPDs (Indicadores Principais de Desempenho,
ou em inglês KPIs - Key Performance Indicators).
Alguns IPDs propostos para esta função:

• Quantidade de chamadas atendidas
• Quantidade de incidentes resolvidos no 1º nível de suporte
• Quantidade de incidentes atendidos dentro do prazo
• Quantidade de incidentes resolvidos no primeiro contato por telefone
• Status de incidentes e problemas x Níveis acordados nos ANSs
• Disponibilidades dos serviços, brechas
• Índice de satisfação (através de formulários de pesquisa)
36
4. Gerenciamento de Incidentes
Introdução
Vimos no capítulo anterior que a Central de Serviços é uma função dentro do provedor de
TI que tem como objetivo prestar suporte aos usuários em relação ao uso dos serviços de
TI. Iremos ver agora o processo de Gerenciamento de Incidentes, que normalmente é
executado pela Central de Serviços, - mas isto não quer dizer que ele acontece apenas
na Central de Serviços.
Um Gerenciamento de Serviços de TI está orientado à entrega de níveis de serviços com

a qualidade e rapidez que o negócio exige. Para isto é necessário ter um processo de
tratamento de incidentes eficaz e eficiente, capaz de monitorar os níveis de serviços,
escalonando os incidentes quando necessário.
Este é um dos processos mais reativos, pois entrará em atuação a partir dos incidentes
levantados por usuários ou ferramentas de monitoramento. Entretanto este processo é
vital para manter a agilidade dos serviços de TI. É importante considerar também que as
informações dos incidentes levantadas neste processo serão de grande importância para
o processo de Gerenciamento de Problemas, pois incidentes recorrentes precisam ser
tratados.
Objetivos
O processo de Gerenciamento de Incidentes tem como missão restaurar os serviços o

mais rápido possível com o mínimo de interrupção, minimizando os impactos negativos
nas áreas de negócio.
O processo de Gerenciamento de Incidentes tem como objetivos:
• Resolver os incidentes o mais rápido possível, restabelecendo o serviço normal

dentro do prazo acordado nos ANSs
• Manter a comunicação dos status dos incidentes aos usuários
• Escalonar os incidentes para os grupos de atendimento para que seja cumprido o
prazo de resolução
• Fazer avaliação dos incidentes e sua possíveis causas, informando ao processo
de Gerenciamento de Problemas. Este processo não é responsável por fazer o
diagnóstico identificando a causa-raiz: ele apenas auxiliará o processo de
Gerenciamento de Problemas que tem este foco
O escopo do Gerenciamento de Incidentes é muito amplo e pode incluir aspectos que

afetem os serviços ao cliente tais como:
• Falha de hardware
• Erro de software
• Solicitações de informações
• Solicitação de mudança de equipamento
37
• Troca de senha
• Criação de perfil para novos funcionários
• Solicitação de suprimentos
• Problemas de desempenho
Perceba que na lista acima existem alguns itens que não são incidentes, isto é, não são
falhas ou anomalias no serviço. Solicitação de suprimentos, criação de perfil para um
novo usuário, etc., é o que chamamos de solicitação de serviço. Na ITIL V2 este tipo de
solicitação também pode ser tratado por este processo. Já na ITIL V3 você vai encontrar
um processo para lidar especificamente com estas questões.
Conceitos
Dentro deste processo existem alguns conceitos que devem ficar claros:
Incidente: qualquer evento que não é parte padrão da operação de um serviço, que
causa ou pode causar uma interrupção ou redução da qualidade do serviço. Exemplo de
incidente: a tela do PC do usuário travou e ele não consegue mais digitar.
Requisição de Serviço: qualquer solicitação/contato que não é uma falha na infra-

estrutura de TI. Exemplo: solicitação para criar um relatório ou executar uma rotina no
sistema.
Problema: é quando a causa-raiz de um ou mais incidentes é desconhecida. Exemplo: o

computador do usuário sempre trava quando ele executa determinada aplicação. Quando
não se sabe o motivo pelo qual o PC trava, isto pode ser considerado um problema.
Erro Conhecido: quando a causa-raiz de um problema é conhecida e já se tem uma

solução de contorno. Exemplo: descobriu-se que o PC travava porque faltava memória
para executar a aplicação.
Solução de Contorno (Workaround): este é um método de contornar um incidente a

partir de uma reparação temporária. Exemplo: reiniciar o computador sempre que a
aplicação travar e não abrir mais de dois programas simultaneamente.
38
Descrição do Processo
A figura abaixo mostra as principais entradas e saídas deste processo:
Procedimentos de
Incidentes entram no processo
Requisição de Serviço
Central de Roteamento
Serviços
Processo de Gestão de Incidentes RDM
Gestão de
Operações • Detecção e registro de incidentes Mudanças
• Classificação e suporte inicial

Redes • Diagnóstico e resolução
• Recuperação
• Encerramento Banco de dados de
problemas e
Outras fontes
de incidentes • Propriedade, monitoração Erros Conhecidos
Acompanhamento e Comunicação
Soluções de contorno
Detalhes de configuração
BDGC
Como em todo processo, existem entradas e saídas. A entrada principal deste processo
são os incidentes. Como mostrado acima, os incidentes podem vir de muitas fontes como
usuários, equipes de operações, redes ou ferramentas de monitoramento que identificam
irregularidades nos serviços. Soluções de contornos podem ser buscadas a partir de uma
base de Erros Conhecidos, ajudando a resolver o incidente mais rápido. A Base de Dados
do Gerenciamento da Configuração (BDGC) auxiliará na identificação do Item de
Configuração relacionado ao incidente, incidentes anteriores, mudanças já registradas,
problemas abertos e o possível impacto e itens relacionados ao incidente. Determinadas
solicitações de usuários podem necessitar de um Registro de Mudança, como por
exemplo, uma nova regra de negócio ou instalação de um novo componente.
Atividades
As atividades do Gerenciamento de Incidentes incluem:
• Detecção de incidentes e registro

• Classificação e suporte inicial
• Investigação e diagnóstico
• Resolução e restauração
• Fechamento do incidente
• Responsabilidade pelo incidente, monitoração, acompanhamento e comunicação
39
O diagrama abaixo mostra as atividades durante o processo de Gerenciamento de
Incidentes.
Detecção e registro do incidente

Delegar, monitorar, acompanhar, comunicar
Classificação e suporte inicial
S Procedimento de
Requisição de requisição de
Serviço? serviços
Investigação e diagnóstico
Solução e restauração
Fechamento do incidente
Detecção de incidentes e registro
Os incidentes na maioria das vezes são oriundos de necessidades de suporte dos

usuários. O contato com a Central de Serviços poderá acontecer por telefone ou e-mail.
Atualmente a maioria das organizações está adotando sistemas web que permitem que o
usuário abra um chamado de suporte diretamente da intranet ou na internet, evitando
gargalo para a central telefônica e facilitando também a vida dos analistas de suporte que
terão mais tempo para resolver os incidentes ao invés de gastar o tempo no registro do
chamado via telefone.
É importante que todos os incidentes sejam registrados, mesmo que resolvidos por
telefone. O histórico de incidentes registrados ajudará no processo de identificação de
tendências de problemas e também para a extração de informações gerenciais úteis. Se o
incidente também não for registrado, não teremos rastreabilidade. Se a mesma questão
voltar a se repetir com o usuário, pode ser verificado o que foi aplicado como solução de
contorno anteriormente.
40
Classificação e suporte inicial
Os incidentes devem ser classificados de tal forma que permitam a identificação de Erros
Conhecidos e gerem informações gerenciais que permitam a identificação dos tipos de
incidentes mais freqüentes.
Exemplos de classificação de incidentes:
• Software
• Microsoft Office
• Hardware
• CD-ROM
• Impressoras
A estrutura acima é apenas um exemplo e não existe um padrão para classificação dos
incidentes. Cada organização pode criar as suas categorias e níveis de classificação.
É importante determinar o impacto e a urgência de cada incidente para determinar a sua
prioridade. A prioridade determina qual será a ordem de execução para resolver os
incidentes. Para determinar a prioridade utilize como boa prática a combinação entre
impacto e urgência do incidente. O impacto será considerado quantas pessoas ou
sistemas serão prejudicados pelo incidente. Já a urgência determina a velocidade em que
o incidente precisa ser resolvido.
A tabela abaixo apresenta a combinação de impacto x urgência. Esta combinação gera

um número de prioridade, que vai de 1 a 5.
Impacto = criticidade para o negócio

Urgência = velocidade
Para ajudar na identificação de impacto e urgência pode ser que seja necessário envolver
o cliente para obter melhor entendimento sobre os serviços de TI que são utilizados e
como as falhas impactam os seus negócios.
41
A prioridade poderá ser utilizada para determinar o prazo para resolução dos incidentes.
Esta prioridade com estes devidos tempos de atendimento podem ser estabelecidos em
acordos com o cliente. Não é uma decisão única da TI, será necessário saber do cliente
qual é o tempo máximo para recuperar o serviço evitando impacto no negócio.
A tabela abaixo apresenta um exemplo de tempo para cada prioridade.
Prioridade Descrição Tempo para atendimento

1 Crítica 1 hora
2 Alta 4 horas
3 Média 24 horas
4 Baixa 48 horas
5 Planejada -
Investigação e diagnóstico
Uma vez registrado o incidente, a atividade de investigação e de diagnóstico será iniciada.

Se a Central de Serviços não puder resolver um incidente, ele será encaminhado a outros
níveis de suporte que irão investigá-lo usando um conjunto de habilidades e ferramentas
disponíveis, tais como uma base de conhecimento de Erros Conhecidos. É importante
que todas as partes que trabalhem com os incidentes mantenham o registro de suas
ações, atualizando o registro do incidente. Estes outros níveis de suporte podem ser
outras áreas da organização, como departamentos de infra-estrutura, desenvolvimento,
etc.
Resolução e restauração
Uma vez que uma solução de contorno ou definitiva para o incidente é encontrada, esta
será adotada. Se uma mudança for necessária, uma RMD (Requisição de Mudança) será
submetida ao Gerenciamento de Mudanças. Você vai ver mais sobre abertura de RDMs
no Gerenciamento de Problemas.
Fechamento do incidente
A etapa de fechamento do incidente inclui:

• Atualização dos detalhes do registro de incidente
• Comunicação ao usuário sobre a solução
Responsabilidade pelo incidente, monitoração, acompanhamento e comunicação
É importante que durante todo o ciclo de vida do incidente a Central de Serviços

permaneça proprietária do incidente, sendo ela responsável pelo seu fechamento. Desta
forma teremos um comprometimento maior da Central de Serviços para o cumprimento
dos prazos, escalonando o incidente para o grupo disponível quando necessário. Sendo
42
assim, sempre que o usuário entrar em contato com a Central de Serviços, terá uma
pronta resposta sobre a situação de suas chamadas. Não é conveniente que os usuários
tenham contato direto com os solucionadores finais do incidente, isto fará com que os
usuários comecem a manter o contato direto com eles e diminua a produtividade dos
mesmos.
Níveis de Suporte
O primeiro nível de suporte irá ser feito pela Central de Serviços e inclui o registro,
classificação, escalonamento (encaminhamento do incidente), resolução e fechamento.
O segundo e terceiro níveis de suporte são responsáveis pela investigação, diagnóstico e

recuperação dos incidentes. Quando a Central de Serviços não tiver capacidade de
resolver o incidente, ou não tiver tempo hábil, ela pode escalonar o incidente para o
próximo nível de suporte. Os grupos de segundo níveis terão conhecimento técnico mais
profundo sobre o assunto, e serão compostos por programadores, consultores, analistas
de negócio e administradores de rede. O grupo de terceiro nível poderá ser formado pelos
fornecedores de software ou hardware. O terceiro nível pode ser um prestador de serviço
externo. Obviamente estes níveis podem variar dependendo do tamanho do provedor de
TI.
43
Diferentes tipos de escalonamento
Diretor
Gerente 1 Gerente 2
Hierárquico
Desktop Aplicações Operações Rede
Funcional
Os incidentes podem ter dois tipos de escalonamento: funcional ou hierárquico. No tipo

funcional os incidentes são escalonados para grupos com conhecimentos mais
específicos sobre o assunto. Veja na figura acima: se o pessoal de operações não tiver
conhecimento sobre a aplicação, o incidente será escalonado para a equipe que cuida de
aplicações. No tipo hierárquico o incidente pode ser escalonado para um chefe ou gerente
da Central de Serviços, quando a situação exigir aprovação de custos ou maior poder de
decisão. Muitas vezes é necessário escalonar para cima devido ao poder de influência
necessário dentro da organização para que o incidente seja resolvido rapidamente.
Neste processo deve haver o Gerente de Incidente, que na maioria das organizações é
um papel atribuído para o Gerente da Central de Serviços.
A função de Gerente de Incidente inclui responsabilidades para:
Monitorar a eficiência e eficácia do processo

Controlar o trabalho dos grupos de suporte
Fazer recomendações para melhorias
Desenvolver e manter o sistema de Gerenciamento de Incidente
Reportar à gerência de TI e outras áreas de processo
Além deste papel, deve haver a equipe que vai atuar na resolução de incidentes, incluindo
o grupo de atendentes da Central de Serviços e os grupos de suporte apresentados
anteriormente.
44
Relacionamentos
O Gerenciamento de Incidentes tem um relacionamento muito próximo com os outros

processos da ITIL. Alguns destes relacionamentos são descritos aqui.
Gerenciamento da Configuração
Cada incidente está conectado com um Item de Configuração (IC) armazenado no BDGC.
Um incidente tipicamente irá envolver mais de um IC. Exemplo: determinado incidente
pode estar relacionado a uma impressora que não imprime corretamente. Esta impressora
é um IC associado ao registro de incidente.
O BDGC fornece informações sobre os ICs e os relacionamentos de dependência entre

eles. Isto ajuda a determinar a causa, a solução e o escalonamento de um incidente,
rastreando as falhas anteriores ao mesmo IC. Por exemplo, se um usuário não puder
acessar a internet, verificando os relacionamentos de dependência daquele PC irá se
descobrir que um hub utilizado pelo usuário para se conectar à rede é um IC potencial
que deve ser investigado.
Gerenciamento de Problemas
Para incidentes com causas não-conhecidas abre-se um registro de problema para que o
processo de Gerenciamento de Problemas faça o diagnóstico da causa-raiz e desenvolva
uma solução de contorno. Um incidente nunca vira um problema. Na verdade, são dois
registros separados. Pode acontecer que os dois processos ocorram em paralelo.
Erros Conhecidos, soluções de contorno e quick fixes (reparos rápidos) são fornecidos ao
Gerenciamento de Incidentes pelo Gerenciamento de Problemas. O Gerenciamento de
Problemas é quem alimenta a base de conhecimento com os Erros Conhecidos.
Gerenciamento de Mudanças
Este processo pode ser a causa dos incidentes se uma mudança não foi executada
corretamente. Conseqüentemente é muito importante que o Gerenciamento de Incidentes
saiba de todas as mudanças planejadas - assim ele poderá relacionar os incidentes a
uma mudança e notificar o processo de Gerenciamento de Mudanças para que o
processo de retrocesso (back out) seja executado. De outra forma, alguns incidentes
serão resolvidos por meio de uma mudança, como por exemplo no caso de um
equipamento defeituoso ser substituído.
Um exemplo de mudança mal sucedida: foi implementada no dia anterior uma nova
versão corretiva para o software XYZ. No dia seguinte, dois usuários reclamam àa Central
de Serviços que os dados históricos armazenados no software XYZ foram perdidos após
a implementação da mudança. Esta ligação será registrada como um incidente, mas este
incidente está relacionado a uma mudança.
45
Benefícios
Principais benefícios que a implementação deste processo pode trazer:
• Impacto reduzido dos incidentes (devido ao tempo de resolução).

• Suporte ao cumprimento dos ANSs.
• Eliminação de incidentes perdidos, pois todos os incidentes serão registrados e
ninguém vai esquecer de atender um incidente.
• Melhor utilização da equipe de suporte, atingindo uma eficiência melhor. Serão
utilizados níveis de suporte com determinadas especialidades.
• O BDGC será mais preciso: a cada incidente serão verificados os dados dos ICs
relacionados. O atendente verifica se as características citadas pelo usuário em
relação ao seu PC conferem com os registros que estão no BDGC.
• Exportação de dados para o Gerenciamento de Problemas. O Gerenciamento de
Problemas poderá realizar o diagnóstico com maior rapidez se já tiver
informações detalhadas do incidente.
• Melhora a satisfação do usuário, porque existe um acompanhamento de seus
incidentes.
Problemas Comuns
• Falta de gestão ou comprometimento da equipe com os incidentes

• Falta de entendimento das necessidades do negócio para identificar a prioridade
dos incidentes
• Falta de objetivos, metas e responsabilidades no processo
• Sem provisão de Acordos de Nível de Serviço com clientes, o que pode gerar
conflitos com o cliente na hora de decidir o que é prioritário
• Falta de conhecimento técnico da equipe para resolver os incidentes
• Falta de integração com outros processos de gerenciamento de serviços
• Falta de ferramentas para registrar os incidentes
• Resistência a mudanças da equipe em relação as regras deste processo de
gerenciamento de incidente
Principais indicadores para este processo:
• Número total de incidentes, por área de negócio, departamento, natureza, etc.

• Tempo médio entre falhas (MTBF)
• Tempo médio para reparo (MTTR)
• Número de incidentes resolvidos por operador
• Redução do tempo médio de solução
• Distribuição de solução entre os níveis de suporte
• Porcentagem de incidentes resolvidos com a base de conhecimento
46
5. Gerenciamento de Problemas
Introdução
A maioria dos provedores de TI tem como tarefa diária apagar incêndios. O grande
volume de chamados com erros em sistemas e mau funcionamento dos componentes de
hardware acabam criando um gargalo para a equipe de suporte. O dia-a-dia corrido da
equipe acaba fazendo com que os problemas não sejam resolvidos definitivamente,
utilizando apenas soluções paliativas para contornar a pressão dos usuários. É como se
colocassem a poeira embaixo do tapete.
O problema da qualidade da solução faz com que o incidente volte a acontecer

novamente, ocupando o tempo da equipe de suporte para resolvê-lo. O que acaba
acontecendo é que a equipe de suporte quase nunca resolve o problema de forma
definitiva devido à falta de tempo.
Uma forma de reduzir a quantidade de incidentes é evitando a sua recorrência. Através do

processo de Gerenciamento de Problemas os incidentes com causas não-identificadas
serão analisados e corrigidos para que não voltem a se repetir. Poderíamos fazer uma
analogia com uma goteira dentro de casa: o Gerenciamento de Incidentes utilizaria um
balde embaixo da goteira para que a chão não fique molhado, já o Gerenciamento de
Problemas iria trocar a telha para que na próxima chuva esta goteira não apareça
novamente.
Este processo de Gerenciamento de Problemas também terá outra preocupação: registrar

todos os Erros Conhecidos e soluções de contorno. Com isto será possível fazer uma
melhor gestão do conhecimento, fazendo com que a maioria dos incidentes seja resolvida
no 1º nível de suporte. Dependendo do ramo de negócio, algumas empresas conseguem
fazer com que 80% dos incidentes sejam resolvidos diretamente no 1º nível através do
uso de uma base de conhecimento. Com uma base de conhecimento e aumento da taxa
de resolução no primeiro nível de atendimento, então é possível reduzir a carga de
trabalho no 2º nível de suporte. Quando a equipe técnica se livra de incidentes ela passa
a ocupar o seu tempo com atividades pró-ativas, fazendo melhorias nos serviços.
É importante que o Processo de Gerenciamento de Problemas venha acompanhado do

Gerenciamento de Mudanças, fazendo com que a correção dos erros seja previamente
analisada em relação aos riscos. Muitas vezes a correção de um erro acaba gerando mais
incidentes e criando impacto para os usuários.
Objetivo
Este processo tem como missão minimizar a interrupção nos serviços de TI através da
organização dos recursos para solucionar problemas de acordo com as necessidades de
negócio, prevenindo a recorrência dos mesmos e registrando informações que melhorem
a maneira pela qual a organização de TI trata os problemas, resultando em níveis mais
altos de disponibilidade e produtividade.
Principais objetivos:
47
• Minimizar os efeitos adversos nos negócios
• Tratar incidentes e problemas causados por erros na infra-estrutura
• Prevenir pró-ativamente a ocorrência de incidentes, problemas e erros
• Reduzir o número geral de incidentes
Este processo terá como escopo:

• Problemas que afetam os serviços de TI
• Problemas recorrentes
• Gerenciamento pró-ativo de problemas
• Incidentes de maior importância
• Relacionamento com os fornecedores
Conceitos
Principais conceitos envolvidos neste processo:
• Problema: é a causa desconhecida de um ou mais incidentes. Assim como existe

o registro de um incidente, vai existir o registro de um problema. O incidente
nunca vira problema. Podemos ter um registro de um incidente relacionado com
um registro de problema. É necessário dois registros separados, pois cada
registro será usado por processos separados.
• Solução de contorno: solução não definitiva (workaround, em inglês). É a
solução paliativa para resolver o incidente. Podemos ter o incidente fechado e
manter o registro de problema aberto até que a verdadeira causa-raiz esteja
identificada.
• Causa: é um erro em um Item de Configuração. É o que provocou o
problema/incidente.
• Erro Conhecido (Known Error): é um problema cuja causa foi diagnosticada e
para a qual existe uma solução. Este Erro Conhecido precisa ser registrado em
algum lugar. Recomenda-se a criação de um banco de dados de Erros
Conhecidos. Este banco é também conhecido como base de conhecimento.
• Solução: solução definitiva. Descreve como remover o erro da infra-estrutura.
Esta solução vai constar no registro de mudança, explicando como se pretende
corrigir o erro.
• Gestão de incidentes X problemas: foco na solução rápida x foco na introdução
de melhorias confiáveis e robustas na infra-estrutura.
O processo de Gerenciamento de Problemas é focado em encontrar relacionamentos

entre incidentes, problemas e Erros Conhecidos. Estas três áreas são chaves para
compreender a "análise da causa-raiz". O princípio básico está em começar com muitas
possibilidades e ir estreitando até encontrar a causa-raiz final.
A figura abaixo mostra as principais entradas e saídas deste processo:
48
Banco de Dados do Base de dados de
Gerenciamento da Erros Conhecidos e
Configuração (BDGC) problemas
Incidentes
graves
• Controle de problemas
• Suporte inicial, classificação e controle de
erros
• Apoio no tratamento de incidentes graves Requisição de
• Prevenção pró-ativa de problemas Mudança (RDM)
• Obtenção de informações gerenciais a partir
Incidentes dos dados de problemas
correlacionados • Revisão dos principais problemas
Gerenciamento de
Mudanças Gerenciamento da Gerenciamento de
Configuração Liberações
O processo de Gerenciamento de Problemas requer as seguintes entradas:

• Registros de incidentes e detalhes sobre eles. Os dados dos incidentes serão
usados para fazer o diagnóstico da causa-raiz.
• Erros Conhecidos já cadastrados. Pode haver algum co-relacionamento com o
problema que está sendo analisado.
• Informação sobre os ICs a partir do BDGC. Pode ser que o erro esteja relacionado
aos componentes do IC principal. Entender os relacionamentos, dependências e
conexões entre os ICs associados ao problema pode ajudar a identificar mais
rápido a causa-raiz.
• Informação de outros processos. Por exemplo: o Gerenciamento do Nível de
Serviço provê informação sobre os prazos a serem cumpridos, o Gerenciamento
de Mudanças provê informação sobre as mudanças recentes que podem ser parte
do Erro Conhecido.
As saídas do processo são:
• RMDs (Requisições de Mudança) para começar o processo de mudança para

resolver os Erros Conhecidos. Um Erro Conhecido certamente será resolvido
passando antes por uma mudança na infra-estrutura. Toda mudança precisa ser
gerenciada.
• Informação gerencial do processo
• Soluções de contorno criadas
• Erros Conhecidos registrados
49
• Atualização dos registros de problemas e registro de problemas resolvidos quando
o Erro Conhecido for resolvido.
Atividades
O Gerenciamento de Problemas na ITIL tem quatro atividades primárias:

• Controle de problemas
• Controle de erros
• Gerenciamento pró-ativo de problemas
• Finalização da revisão dos problemas graves
Basicamente as duas atividades principais, controle de problemas e controle de erros, têm

as seguintes finalidades: a primeira vai identificar a causa-raiz e a solução definitiva, e a
segunda vai acompanhar a remoção do erro passando pelo Gerenciamento de Mudanças.
Controle de problemas
Este subprocesso é responsável pela identificação da causa-raiz dos problemas,

identificando uma solução definitiva.
As principais atividades do controle de problemas são:
• Identificação e registro de problemas (é parecido com o registro de

incidentes)
o Alguns problemas podem ser identificados por processos que não sejam o
Gerenciamento de Problemas (exemplo: Gerenciamento da Capacidade).
• Classificação dos problemas:
o Esta atividade centra em entender o impacto sobre os níveis acordados de

serviços relacionados ao problema. A classificação do problema é similar
ao incidente (impacto, urgência, prioridade).
• Investigação e diagnóstico de problemas

o Este é o passo onde entendemos qual é a causa do problema. Este passo
é diferente do Gerenciamento de Incidentes, onde o foco é na restauração
rápida do serviço.
50
A figura abaixo apresenta o fluxo de atividades dentro do controle de problemas:
Depois que se descobre qual é o erro, inicia-se a segunda parte, que é o controle de
erros.
Controle de erros
O controle de erros é um subprocesso pelo qual os Erros Conhecidos são pesquisados e

corrigidos. Quando se tem o registro da solução definitiva será feita uma Requisição de
Mudança (RDM). Esta e é submetida ao Gerenciamento de Mudanças, que vai acionar a
aprovação. Uma vez que a mudança foi implementada, este processo irá fazer a Revisão
Pós-implementação (RIP), para verificar se a mudança realmente surtiu os efeitos
desejados e se o erro realmente foi removido.
51
O controle de problemas e o controle de erros ocorrem na seqüência. Na ITIL V3 estes
dois subprocessos foram agrupados em único subprocesso. Você pode perceber que se o
fluxo dos dois subprocessos fossem colados um abaixo do outro, eles poderiam ser
emendados.
Em resumo, uma solução estruturada para a remoção de um erro da infra-estrutura

poderá passar pelas seguintes etapas:
Erro na Incidente Problema Erro Conhecido RDM

infra-estrutura Solução
estruturada
Conforme já mencionamos anteriormente, a partir do momento em que é registrado o Erro

Conhecido deve ser aberta uma Requisição de Mudança para filtrar, analisar e
acompanhar a mudança na infra-estrutura, com menor impacto e risco para o ambiente de
produção.
Gerenciamento pró-ativo de problemas
O gerenciamento pró-ativo de problemas foca na análise de dados coletados de outros

processos, e seu objetivo é definir quais são os possíveis “problemas”. Estes problemas
são passados para o controle de problemas e erros, se eles já aconteceram.
O ideal seria que a equipe técnica tivesse uma parte do tempo reservadas para fazer esta
parte pró-ativa do processo.
As atividades deste processo incluem:
Análise das tendências
Exemplos:
Ocorrência de problemas específicos após determinada mudança

Pequenas falhas de um mesmo tipo - poderiam estar ocorrendo muitas falhas
com a mesma funcionalidade em um sistema (este mesmo incidente ocorre
com muita freqüência e pode ser sinal que há algum problema a ser resolvido)
Falhas recorrentes com determinado equipamento
Necessidade de melhor treinamento dos usuários e documentação
Esta parte pró-ativa é outra diferença para o processo de Gerenciamento de Incidente. O

processo de Gerenciamento de Incidente produz relatórios para a gestão, mas ele não faz
uma avaliação de tendência entre os incidentes. O Gerenciamento de Incidentes é
tipicamente reativo.
Esta análise de tendências poderia ser realizada com o uso de um gráfico sugerido
abaixo. As categorias com o maior número de incidentes e com a maior relevância
deveriam ser analisadas com mais detalhes. Para identificar a categoria mais relevante a
52
ser analisa, usa-se um peso, que poderia ser o impacto que a categoria apresenta ao
negócio.
Rede ERP E-mail
Categoria de incidentes
Peso
Ações preventivas
Exemplos:
Utilizar o “pain factor” (onde dói mais, onde gera mais impacto) dos incidentes
para direcionar recursos
Realização das revisões dos maiores problemas
O foco principal do gerenciamento pró-ativo de problemas é redirecionar os

esforços que estão atuando sempre em ações reativas para prevenção pró-ativa
de incidentes que poderão ocorrer. O ideal é que a equipe tenha condições de
trabalhar 80% em atividades reativas e pelo menos 20% em atividades pró-ativas.
Caso haja muita carga de trabalho, não será possível conseguir as vantagens da
pró-atividade. Para isto é muito importante que se faça o dimensionamento da
carga, pois, caso contrário, não serão obtidas todas as vantagens deste processo.
53
A figura abaixo apresenta as atividades da fase reativa para a fase pró-ativa.
REATIVO PRÓ-ATIVO
►Prevenção de problemas em
outros sistemas e aplicações
►Monitoramento do Gerenciamento de
Mudanças
►Iniciação de mudanças para combater:

• Ocorrência de incidentes
• Repetição de incidentes
►Identificação de tendência
►Identificação do problema e diagnóstico do problema
►Fornecer suporte para 2º/3º níveis
Revisão dos problemas graves
Esta é uma outra atividade pró-ativa. Ao final do ciclo de um problema grave, deve haver
uma revisão para poder aprender:
1. O que deu certo?
2. O que fizemos de forma diferente?
3. Que lições podemos tirar da resolução deste problema?
Ferramentas e Técnicas
Para a identificação da causa-raiz dos problemas são sugeridas algumas ferramentas da

área de gestão da qualidade, entre elas o Diagrama de Ishikawa e a Análise de Kepner e
Trogoe.
Diagrama de Ishikawa
O diagrama de Ishikawa, também conhecido como Diagrama de Causa-efeito ou

Diagrama Espinha de Peixe, apresenta os fatores que podem afetar a qualidade,
resultando em um problema. O diagrama ganhou o nome do seu autor, Kaoru Ishikawa
(1915 – 1989), um expert japonês em controle de qualidade. Este diagrama é utilizado
largamente na área de qualidade e também pode ser aplicado no processo de
Gerenciamento de Problema para o diagnóstico da causa-raiz.
54
O Diagrama de Ishikawa é tipicamente o resultado de uma sessão de brainstorming, na
qual os membros de um grupo jogam idéias de como melhorar um produto, processo ou
serviço. É também muito utilizado para a identificação da causa-raiz do problema. Na
ponta da espinha é colocado o problema identificado, e em cada ponta lateral são
colocadas as possíveis áreas que estão resultando no problema. Cada causa possível é
testada até chegar à raiz, desta forma identificando qual é o motivo ou o erro que gerou o
problema.
Análise de Kepner e Tregoe

É um método desenvolvido por Charles Kepner e Benjamin Tregoe, que tem uma
sistemática para resolver problemas e usar o máximo de vantagem do conhecimento das
experiências anteriores:
Os passos sugeridos para a identificação do problema são:

Definir o problema
Descrever o problema relacionando identidade, localização, tempo e tamanho
Estabelecer possíveis causas
Testar a causa mais provável
Verificar a verdadeira causa
Vejamos os papéis existentes neste processo.
O Gerente de Problema deve assegurar que:
As atividades de controle de problema e controle de erros estão sendo efetivas

Os dados estejam registrados adequadamente
Os dados sejam regularmente auditados
Os Erros Conhecidos sejam registrados no BD de Erros Conhecidos
A equipe de suporte esteja preparada para fazer o registro correto dos problemas
55
Existem recursos para a efetividade do processo de gerenciamento pró-ativo de
problema
Gerente de Problema, conforme já foi abordado anteriormente, não é um cargo, e sim um

papel. Uma mesma pessoa na organização pode assumir mais de um papel. É comum o
Gerente da Central de Serviços assumir o papel de Gerente de Incidente e de Gerente de
Problema também. Alguns até recomendam que os papéis de Gerente de Incidente e de
Problema não sejam compartilhados, visto que os objetivos dos dois processos são
distintos. O processo de Gerenciamento de Incidentes é imediatista, quer uma solução
rápida. Já o processo de Gerenciamento de Problemas precisa ser mais métodico e
criterioso para analisar com calma os problemas.
A equipe de suporte é responsável por:
Identificação dos problemas

Investigação dos problemas chegando aos Erros Conhecidos
Monitoramento do processo de eliminação dos Erros Conhecidos
Emitir a RDM (Requisição de Mudança) quando necessário
Identificar tendências nos incidentes
Comunicar soluções de contorno para o Gerenciamento de Incidentes
É importante esclarecer que não haverá um departamento para executar as atividades do

processo de Gerenciamento de Problemas. As equipes técnicas, normalmente os grupos
de segundo e terceiro nível, poderão ser envolvidas neste processo.
Relacionamentos
O processo de Gerenciamento de Problemas tem conexões muito próximas com outros

processos da ITIL.
Com o Gerenciamento de Incidentes
Há um vínculo muito próximo, conforme nós já aprendemos. O Gerenciamento de

Problemas se preocupa em resolver a causa-raiz dos incidentes que são registrados pelo
Gerenciamento de Incidentes. É importante que o controle de incidentes forneça uma
informação precisa para que então o controle de problemas possa identificar a causa-raiz
e propor uma solução de contorno o mais rápido possível.
O Gerenciamento de Problemas irá suprir o Gerenciamento de Incidentes com soluções

de contorno e quick fixes (reparos rápidos) quando possível.
56
Com o Gerenciamento de Mudanças
Quando o Gerenciamento de Problemas encontrar uma solução para o Erro Conhecido,

ele então submete uma RDM para o Gerenciamento de Mudanças, que é responsável
pela implementação da mudança. Quando implementar uma mudança, em conjunto com
o Gerenciamento de Problemas ele irá revisar o problema para verificar se a mudança o
resolveu totalmente. Isto é chamado de Revisão Pós-Implementação (RPI). Após esta, o
Gerenciamento de Problemas fechará o registro do problema.
Com o Gerenciamento da Configuração
A informação que é fornecida pelo Gerenciamento da Configuração é importante no

diagnóstico de problemas. Inclui informações sobre os ICs e os relacionamentos entre
eles.
Com outros processos
Gerenciamento do Nível de Serviço, Gerenciamento da Capacidade e Gerenciamento da

Disponibilidade fornecem ao Gerenciamento de Problemas informações que ajudam a
definir e determinar o impacto dos problemas. Em contrapartida, o Gerenciamento de
Problemas fornece informações relevantes a eles e a outros processos, como por
exemplo: ao Gerenciamento do Nível de Serviço se a causa do problema foi resolvida
dentro dos padrões acordados (ANSs) e ao Gerenciamento da Capacidade se o HD é a
causa do problema.
Benefícios
O Gerenciamento de Problemas melhora a qualidade dos serviços de TI resolvendo a

causa-raiz dos incidentes. Isto leva à redução do número de incidentes, beneficiando
usuários, clientes, organização e o provedor de TI.
As principias vantagens são:
Melhoria nos serviços de TI

Redução da quantidade de incidentes
Soluções permanentes, evitando ficar apenas na solução de contorno fazendo
com que os mesmos incidentes continuem aparecendo novamente
Melhor aprendizado da organização através dos registros de soluções de contorno
e Erro Conhecidos documentados
Aumento da taxa de resolução da Central de Serviços no primeiro contato com o
usuário, evitando sobrecarregar o 2º nível (este aumento deve-se ao fato de haver
soluções de contorno já documentadas)
Mas a m maior vantagem é a redução da quantidade de incidentes ao longo do tempo.

Isto poderá trazer redução de custos a longo prazo, visto que haverá menor número de
atendentes pela quantidade de incidentes abertos.
57
Problemas Comuns
Os problemas comuns no Gerenciamento de Problemas incluem:
Qualidade das informações dos incidentes que serão utilizadas no diagnóstico da

causa raiz
Tempo e recursos para fazer o tratamento dos problemas
Criar e manter uma Base de Conhecimento e Erros conhecidos
Reconhecer que Central de Serviços tem um papel importante neste processo. A
Central de Serviços pode registrar os problemas e também fazer o repasse de
problemas aos fornecedores.
Lidar com Erros Conhecidos não resolvidos por falta de tempo
Dados históricos de incidentes não confiáveis para a análise de tendência
Desvio da Central de Serviços e não abrir o problema e já aplicar uma solução de
contorno não confiável
Falta de comprometimento gerencial e da equipe
Comprometimento da equipe (cultura)

Um Gerenciamento de Problemas com sucesso pode ser medido por:
• Número de problemas por status, serviços, impacto e classificação

• Número e impacto dos incidentes durante a operação do processo
• Percentual de esforço reativo x pró-ativo
• Esforço, custo e prazo dos diagnósticos
• Número de RDMs geradas pelo processo de controle de erros
• Tempo para solução de problemas x tempo estimado
58
6. Gerenciamento de Mudanças
Introdução
Como já visto anteriormente, a TI tem se tornado crítica para as operações das empresas
em virtude das dependências que o negócio tem sobre os sistemas de TI para continuar
funcionando. Cada vez mais os usuários exigem níveis de disponibilidade mais altos dos
serviços para alcançar os objetivos do negócio. Percebemos ainda que a área de TI está
em constante mudança para atender à demanda da evolução do cenário de negócios,
realizando implementações nos sistemas, implementando novos sistemas, aumentando a
capacidade para os serviços e criando novas políticas de segurança, entre outros.
É sabido também que a maioria dos problemas relacionados com a qualidade dos
serviços normalmente está relacionada a alguma mudança já realizada anteriormente.
Mudanças mal feitas, sem planejamento e sem testes adequados podem resultar em mais
problemas, muitas vezes desastrosos, trazendo prejuízos ao negócio. Há também
pesquisas no mercado que indicam que quase 60% dos problemas de indisponibilidade
dos serviços são devidos a uma falha de configuração do operador. Como estamos tão
dependentes dos serviços de TI, não podemos mais aceitar falhas brutais nas mudanças
realizadas.
Através do processo de Gerenciamento de Mudanças, todas as implementações e

modificações na infra-estrutura de TI serão analisadas e planejadas para que se tenha o
menor risco e impacto. Qualquer ação que altere a configuração da infra-estrutura atual
pode ter riscos associados. Não podemos perder a estabilidade dos serviços.
Este é um processo considerado um tanto quanto burocrático pela equipe, pois é

aconselhável que para a maioria dos erros identificados seja aberta uma Requisição de
Mudança (RDM) que deverá ser aprovada. Toda mudança precisa ser planejada e
controlada. É necessário que haja uma mudança de cultura e um comprometimento de
todos para que o processo funcione, evitando formas de burlar o processo.
Normalmente o Gerenciamento de Mudanças é aplicado em provedores de TI que já

tenham certa maturidade no Gerenciamento de Serviços de TI. Este processo pode ser
implementado isoladamente, mas é importante o apoio do Gerenciamento da
Configuração para dar suporte à avaliação de impacto, indicando os ICs envolvidos na
mudança.
Objetivo
Este processo tem como missão gerenciar todas as mudanças que possam causar
impacto na habilidade do provedor de TI em entregar serviços, através de um processo
único e centralizado de aprovação, programação e controle de mudança, para assegurar
que a infra-estrutura de TI permaneça alinhada aos requisitos do negócio com o menor
risco possível.
Principais objetivos deste processo:
59
• Assegurar que os procedimentos padronizados estão sendo usados para o
tratamento eficiente de todas as mudanças, reduzindo seus riscos e impactos
• Minimizar incidentes relacionados com mudanças
• Balanço entre necessidade e impacto
Este processo tem foco nas mudanças que afetam:

• Hardware, software, equipamentos e software de comunicação
• Aplicações em produção
• Toda a documentação e procedimentos associados com a operação, suporte e
manutenção da Infra-estrutura de TI
Ficam fora do escopo, mas relacionados:

• Mudanças em projetos - por exemplo, um projeto de implantação de um ERP
(Enterprise Resource Planning) pode exigir mudanças na capacidade dos
servidores
• Identificação de componentes afetados na mudança ou atualização de registro
(domínio do Gerenciamento da Configuração)
• Liberação de novos componentes (foco do Gerenciamento de Liberações)
Conceitos
Há dois conceitos básicos que você precisa saber:
Mudança:
Uma ação que resulta em um novo status para um ou mais ICs da infra-estrutura de TI.
Exemplos de mudanças:
Trocar a memória de um servidor
Alterar a versão do sistema corporativo
Trocar o no-break de um servidor
Requisição de Mudança (RDM):

Utilizada para registrar detalhes de uma mudança em qualquer IC. Pode ser um
formulário em papel ou em formato eletrônico.
O Processo de Gerenciamento de Mudanças é responsável por DECIDIR e

COORDENAR as mudanças. Ele não tem como objetivo executar a implementação das
mudanças. A implementação será realizada por uma equipe técnica responsável pela
área da mudança, como a área de redes, sistemas, hardware. Normalmente esta
implementação envolve o Gerenciamento de Liberações. O processo de Gerenciamento
de Mudanças controlará as mudanças para que elas sejam implementadas de forma
eficiente e eficaz no que se refere ao custo e com um mínimo de riscos para os serviços
mantidos. Para que se possa fazer uma análise de riscos adequada é importante o uso de
uma Base de Dados do Gerenciamento da Configuração (BDGC) que forneça todos os
serviços e recursos relacionados ao IC que sofrerá a mudança.
60
Não é necessário que todas as mudanças sejam controladas pelo processo de
Gerenciamento de Mudanças. Por exemplo, mudanças sem importância, como alterar
uma senha, podem ser feitas pela Central de Serviços seguindo procedimentos definidos.
Qualquer mudança comum e de baixo risco pode se transformar em um procedimento
que qualquer um na organização pode executar. Fazendo desta forma, reduzem-se carga
de trabalho, frustração e boicote ao processo.
Banco de Dados do
Gerenciamento da
Configuração (BDGC)
Requisições de
Mudanças Programação
(RDMs) Futura de
Mudanças(PFM)
• Registro e classificação Requisições de

Mudança
• Aprovação aprovadas
• Coordenação do desenvolvimento
• Autorização e implementação Atas de reunião
do CCM e
• Avaliação
Programação ações
Futura de
Mudanças (PFM)
Relatórios do
Gerenciamento
de Mudanças
Gerenciamento Gerenciamento Gerenciamento

da Capacidade da de Liberações
Configuração
Principais entradas para este processo:
• Requisições de Mudanças (RDMs). As Requisições de Mudança são os registros.

Estes registros contêm descrição da mudança, seu propósito, riscos, plano de
ação, responsáveis, etc.
• Programação Futura de Mudanças (PFM). É o agendamento das próximas
mudanças.
• Informações dos processos de Gerenciamento da Capacidade, da Configuração e
de Liberações para realizar a análise de riscos, planejamento e custos.
61
Principais saídas:
• Programação Futura de Mudanças (PMF). Agenda de quando as mudanças serão

implementadas.
• Requisições de Mudança aprovadas.
• Atas da reunião do Conselho de Controle de Mudanças (CCM). Veja mais adiante
o que é o CCM.
• Informações gerenciais do processo.
O processo de Gerenciamento de Mudanças tem ligação muito próxima com o

Gerenciamento de Projetos, que é outra disciplina não tratada pela ITIL. Dependendo da
complexidade da mudança, seu desenvolvimento será tratado como um projeto dentro da
organização. A figura abaixo ilustra as atividades que fazem parte do Gerenciamento de
Mudanças e as atividades que fazem parte do Gerenciamento de Projetos (que também
podem fazer parte do Gerenciamento de Liberações).
Projeto / Liberação Gerenciamento de Mudanças
Monitoração e Registro e classificação RDM

planejamento
Desenvolvimento Aprovação Recusa
Teste Autorização e Recusa

omplementação
Implementação
Backout
Avaliação
Para as melhores práticas no Gerenciamento de Projetos é recomendável utilizar outras

frameworks. O OGC criou o PRINCE2 (www.prince2.com), e o PMI (Project Management
Institute) criou o PMBOK. O padrão PMI é americano e é adotado como padrão no mundo
todo. Para mais informação consulte o site www.pmi.org.
Muitas atividades que você visualiza ao lado do projeto são atividades também cobertas
pelo processo de Gerenciamento de Liberações da ITIL. O Gerenciamento de Mudanças
aprova e controla as mudanças, mas quem planeja a liberação dos componentes de
hardware e software que fazem parte da mudança é o processo de Gerenciamento de
Liberações. O processo de Gerenciamento de Liberações pode ser subordinado ou
coordenado pelo Gerenciamento de Mudanças.
62
Tipos de Mudanças
As mudanças podem ser classificadas em três tipos:
Mudança Padrão
Mudança com roteiro pré-definido (atualização de softwares, troca de
senha)
Não é necessária uma aprovação
Em alguns casos pode ser executada pela Central de Serviços
Existe um documento modelo padrão (procedimento escrito)
Mudança Normal
Segue os procedimentos normais, precisa passar pelo fluxo de aprovação
Mudança Urgente
O tempo é muito pequeno para seguir o fluxo normal, cria-se um fluxo
mais ágil de aprovação.
Cria-se o procedimento de urgência
Atividades
O processo do Gerenciamento de Mudanças inclui as seguintes atividades:
• Registro e classificação
• Aprovação
• Coordenação do desenvolvimento
• Autorização e implementação
• Avaliação
63
RDM
Requisição de Mudança
Rejeição
Gerenciamento da Configuração processa mudanças nos
Nova RDM possível

Aceite
Classificação/Prioridade
Sim
Urgente? Procedimentos
Não
Urgentes
Planejamento
ICs
Coordenação
Desenvolvimento
Testes
Implementação
Inicia o plano
Funcionou?
Não de retrocesso
Sim
Avaliação e fechamento
Registro de Requisição de Mudança (RDM)

Uma RDM pode ser levantada a partir de uma necessidade do cliente, ou surgir a partir de
um erro identificado no processo de Gerenciamento de Problemas. Qualquer outro
processo também pode abrir uma RDM. Sempre que alguma coisa precisa ser alterada na
infra-estrutura para corrigir um erro, fazer uma melhoria ou implementar um novo serviço,
normalmente abre-se uma RDM. A RDM poderá ser em papel ou eletrônica, através de
um software de Gerenciamento de Serviços.
Registro e classificação
Uma RDM deve ter várias informações para a tomada de decisão, tais como categoria,
impacto e custo. Estas informações serão utilizadas para extrair o relatório gerencial.
Também é importante alocar a prioridade para cada mudança para definir a agenda de
mudanças programadas.
Aprovação
As RDMs são filtradas e aprovadas. Alguns fatores podem determinar que uma mudança
seja recusada, como por exemplo o custo muito alto em relação ao benefício que ela vai
trazer para o negócio. Esta atividade também ajuda a identificar o nível requerido de
aprovação - por exemplo, determinado tipo de mudança o Gerente de Mudanças pode
aprovar, outro deve circular pelo CCM ou pelo Comitê Executivo.
64
Coordenação do desenvolvimento
Aprovada a mudança, a RDM deve ser passada para o grupo técnico que será
responsável pelo seu desenvolvimento e implementação. O Gerenciamento de Mudanças
deve coordenar este processo, assegurando que existam os recursos necessários,
monitorando os riscos e acompanhando os testes. Muitas destas atividades de
implementação são planejadas pelo processo de Gerenciamento de Liberações.
Autorização e implementação
Após passar pela fase de desenvolvimento, as mudanças devem ser testadas antes de ir
para o ambiente de produção. É aconselhável que exista um grupo de testes
independente neste processo com condições técnicas para elaborar o plano de testes
avaliando todos os requisitos para o funcionamento da mudança no ambiente de
produção. Após o resultado dos testes a mudança será autorizada para ser implantada.
Dependendo da urgência e do impacto da mudança, a fase de testes poderá ser ignorada.
Implementação
O Gerenciamento de Mudanças deve garantir que as mudanças sejam implementadas
seguindo um programa definido. A execução da implementação não é de
responsabilidade deste processo, ele apenas irá coordenar. O processo de
Gerenciamento de Liberações poderá ser coordenado pelo processo de Gerenciamento
de Mudanças, pois as mudanças acabam gerando novos releases de software ou de
hardware.
Avaliação
O Gerenciamento de Mudanças deve avaliar todas as mudanças implementadas após
determinado período. Esta revisão se chama Revisão Pós-Implementação (RPI). O
processo de Gerenciamento de Problemas também poderá acompanhar este processo,
visto que o controle de erros tem esta atividade no seu escopo. Esta revisão serve para
verificar se a mudança trouxe os resultados esperados. Se houver algum problema ou
ineficiência, ações devem ser tomadas para a correção.
Comitê de Controle de Mudanças (CCM)
É um grupo responsável pela avaliação do impacto das mudanças. Este grupo será
composto de várias pessoas técnicas e até mesmo clientes e fornecedores externos, que
fornecerão assessoria ao Gerente de Mudanças sobre quais mudanças devem ser
aprovadas e quais seus riscos e impactos no negócio, e auxiliarão na programação das
mudanças. Normalmente o CCM se reúne como uma determina freqüência para discutir
todas as mudanças novas e em andamento. É comum esta reunião ser semanal, com
uma hora de duração.
Possíveis membros do CCM:

• O Gerente de Mudanças
• Clientes
• Gerentes usuários
• Representantes de grupo de usuários
• Pessoal de desenvolvimento/manutenção de aplicações (quando apropriado)
• Consultores, especialistas e técnicos
• Equipe de serviços (se necessário)
65
• Equipe de serviços administrativos (quando as mudanças afetam as instalações)
• Representantes dos contratantes ou de terceiros (se necessário - por exemplo, em
situações de outsourcing)
Dependendo do impacto, a mudança não poderá ser aprovada apenas pelo Gerente de
Mudança. Será necessário que ela circule pelo CCM. O Gerente de Mudanças
normalmente tem autoridade para aprovar mudanças de menor impacto por conta própria.
CCM/CE (Comitê de Emergência)

Quando surgem problemas mais graves, pode não haver tempo para se criar um CCM
completo e é, portanto, necessário identificar um menor grupo de pessoas com autoridade
para tomar decisões emergenciais. Este comitê sempre será formado pelo Gerente de
Mudanças e os técnicos responsáveis pela implementação da mudança.
Comitê Executivo e mudanças maiores

O Comitê Executivo é o grupo responsável pela aprovação de mudanças maiores. Em
mudanças que envolvem investimentos financeiros e alto impacto para o negócio, pode
ser necessário envolver membros que representam o negócio para tomar decisões. Uma
vez aprovada, a Requisição de Mudança deve ser devolvida, talvez via Comitê de
Controle de Mudanças, para agendamento e implementação. As mudanças maiores são
caracterizadas como tendo enorme impacto e/ou necessidades de grandes quantidades
de recursos de desenvolvimento.
O principal papel envolvido neste processo é o do Gerente de Mudanças, que será

responsável por:
Processamento das RDMs, incluindo registro e classificação destas
Planejamento, coordenação (envolvendo todas as partes) e implementação das
mudanças
Autorização, após discutir com o CCM ou CCM/EC
Onde apropriado, obter autoridade para autorizar as mudanças
Fechamentos das RDMs
Emitir a PFM (Programação Futura de Mudanças) através da Central de Serviços
Coordenar a estruturação, testes e implementação das mudanças
Revisar todas as mudanças implementadas
Analisar tendências nos registros
Produzir relatórios sobre o processo de Gerenciamento de Mudança
66
Relacionamentos
O processo de Gerenciamento de Mudanças depende da precisão dos dados de

configuração para assegurar o conhecimento sobre o impacto completo de se aplicar a
mudança. Existe um relacionamento muito próximo com o Gerenciamento da
Configuração, Gerenciamento de Liberações e o Gerenciamento de Mudanças.
Avisar a Central de Serviços sobre mudanças é crucial. Mudanças precisam ser

divulgadas para o processo de Gerenciamento de Incidentes.
Também o processo de Gerenciamento de Problemas pode submeter uma RDM para

resolver Erros Conhecidos. Algumas vezes isto pode causar um efeito bola de neve se o
processo de Gerenciamento da Configuração não tiver habilidade para informar quais
componentes irão ser afetados (incluindo hardware, software, ANSs).
Outros processos podem estar vinculados com o Gerenciamento de Mudanças no sentido

de que eles podem também requisitar mudanças (Gerenciamento da Disponibilidade) ou
serão consultados para determinar o impacto da mudança (Gerenciamento da
Continuidade dos Serviços de TI, Gerenciamento do Nível de Serviço e Gerenciamento da
Capacidade).
Benefícios
Principais benefícios deste processo:
• Melhor alinhamento dos serviços de TI com os negócios. As mudanças serão

filtradas e priorizadas conforme a sua necessidade para o negócio.
• Aumento da visibilidade dentro das mudanças. Há um controle maior sobre a
execução da mudança.
• Redução de impacto negativo da mudança. A análise de riscos permite evitar que
o serviço fique indisponível devido a falhas.
• Melhor avaliação do custo da mudança. Antes de a mudança ser implementada, o
seu custo x benefício deve ser avaliado.
• Habilidade de absorver um volume maior de mudanças. Na implementação do
processo haverá um Gerente de Mudanças que deverá coordenar todas as
mudanças. Além disto, para cada área de mudança haverá uma equipe que será
convocada para a reunião. Com um processo definido ficará mais fácil ter o
controle de várias mudanças ao mesmo tempo.
67
Problemas Comuns
Assim como todo processo que tem benefícios, nós temos que reconhecer que existem
problemas também. O Gerenciamento de Mudanças é um processo importante, tanto
para o provedor de TI como para os usuários e clientes.
Principais problemas relacionados a este processo:
• Falta de informação para análise de riscos. Se não houver uma base de

configuração atualizada com as informações necessárias para fazer a análise de
impacto, poderá haver falhas na implementação devido ao surgimento de riscos
que não foram previstos.
• Falta de ferramenta integrada aos demais processos. O auxílio de uma ferramenta
adequada ajudará no controle das mudanças. A integração aos demais processos
ajudará no planejamento da mudança.
• Falta de comprometimento da equipe. A equipe de TI pode ser relutante em aderir
aos procedimentos devido ao Gerenciamento de Mudanças envolver muitos
aspectos. É importante fazer com que a equipe esteja consciente dos efeitos
positivos do processo como um todo. A cultura da empresa influenciará na adesão
a este processo. Uma empresa que não é organizada, que não tem controle sobre
as decisões tomadas dentro dos seus departamentos, provavelmente encontrará
na equipe de TI a mesma desorganização.
• Priorização de todas as mudanças. É importante que sejam definidas as
prioridades das mudanças conforme as necessidades do negócio. As mudanças
devem ser planejadas e agendadas no seu tempo correto. Devem ser tratadas
apenas como mudanças urgentes aquelas que implicam na indisponibilidade atual
ou imediata de um serviço.
Principais IPDs para este processo:
• Número de mudanças aprovadas e rejeitadas

• Número de incidentes relacionados com uma mudança
• Relação de mudanças urgentes x normais
• Distribuição de mudanças por motivo (tratamento de incidente, correção de erro,
melhoria, etc.)
• Número de mudanças com sucesso e sem sucesso
• Numero de mudanças que precisaram acionar o plano de backout
• Tempo médio para implementar uma mudança
68
7. Gerenciamento de Liberações
Introdução
Com o aumento da complexidade dos sistemas e a maior necessidade das organizações

de TI em fornecer um ambiente estável, a liberação de um novo software ou hardware
precisa ser controlada com mais atenção.
Este processo dentro da ITIL se preocupa em fornecer um meio estruturado para o

Gerenciamento de Liberação na infra-estrutura a partir do planejamento da liberação
(release) até a instalação de fato. Os relacionamentos com o Gerenciamento de
Mudanças e da Configuração são chaves para este processo. Os três processos estão
intimamente ligados. Normalmente acompanhada de uma mudança vem uma liberação
de softwares ou hardware. O Gerenciamento de Mudanças aprova e coordena as
mudanças. Envolvido na mudança pode estar o processo de Gerenciamento de
Liberações, que vai planejar as liberações de software e hardware. O Gerenciamento de
Liberações deve submeter o seu plano para o Gerenciamento de Mudanças aprovar.
Os principais componentes controlados pelo processo de Gerenciamento de Liberação

incluem:
Software
Aplicações desenvolvidas internamente
Pacotes de software
Softwares específicos da empresa
Softwares desenvolvidos externamente
Hardware
Licenças de softwares
Documentação
Especificações técnicas
Manuais do usuário
Procedimentos
Imagine que no próximo mês serão atualizadas todas as instalações do Microsoft Office
para a versão 2007 em 2.000 PCs na organização. Esta atualização vai passar antes pelo
Gerenciamento de Mudanças, que vai fazer a aprovação e a coordenação. Esta
atualização nos PCs vai ser planejada e entregue pelo Gerenciamento de Liberações.
Objetivo
O Gerenciamento de Liberação é o processo que “protege” o ambiente de produção. Esta

proteção vem em forma de procedimentos formais ou testes extensivos relacionados a
mudanças de software ou hardware que estão sendo propostas dentro do ambiente de
produção.
69
Objetivos do processo de Gerenciamento de Liberação incluem:
• Gerenciar, distribuir e implementar ICs de hardware e software que foram
aprovados
• Prover o armazenamento físico e seguro de itens de hardware e software no
Depósito de Hardware Definitivo (DHD) e na Biblioteca de Software Definitiva
(BSD)
• Assegurar que apenas versões de softwares e hardwares autorizadas e com
qualidade controlada serão utilizadas nos ambientes de teste e de produção
• Negociar o conteúdo e o plano de implantação de liberações
• Comunicar e gerenciar expectativas do cliente durante o planejamento e rollout de
novas liberações
Alguns benefícios de se implementar este processo:

Redução de riscos de vírus (antes de serem instalados nos PCs os softwares
passaram pela homologação do Gerenciamento de Liberações)
Redução de incidentes causados por liberações mal planejadas
Melhor uso dos recursos da TI (equipe e software e hardware)
Conceitos
Liberação
É usada para descrever uma coleção de mudanças aprovadas em um serviço de TI que
foram autorizadas pelo Gerenciamento de Mudanças. Uma liberação é definida pelas
RDMs que irão implementá-las. Dependendo do tamanho, a liberação pode ser
classificada como sendo:
Liberação Emergencial
Liberação menor de Software ou Upgrade de Hardware
Liberação Maior
Biblioteca de Software Definitiva (BSD)
Biblioteca de Software Definitiva de é o termo usado

para definir o local físico e lógico em que as versões
definitivas e autorizadas de todos os softwares (ICs de
software) são armazenados.
A BSD é uma biblioteca física e segura de:

• Código-fonte de software desenvolvido dentro da organização
• Mídia original e documentação dos produtos de software adquiridos, como licença
e manuais de usuários
70
A BSD não precisa existir como um local físico, podemos ter um servidor de arquivos que
armazena as cópias originais dos softwares.
A diferença do BDGC para a BSD é que a BSD armazenada cópias físicas dos ICs, já o
BDGC armazena apenas informações lógicas. O CD de um software ficar armazenado na
BSD, já o BDGC vai dizer quais usuários e em que PCs este software está sendo
utilizado.
Depósito de Hardware Definitivo (DHD)
O Depósito de Hardware Definitivo (DHD) é

uma área segura para manter ICs definitivos de
hardware sobressalentes, que são peças de
reposição como teclado, mouse, memórias, placas,
etc.
Estes ICs são mantidos no mesmo nível dos

sistemas correspondentes do ambiente de
produção. Ou seja, precisamos de peças que sejam
compatíveis com o que está em produção. Os detalhes destes componentes podem estar
registrados no BDGC.
O Gerenciamento de Liberação gerencia todos os softwares e hardwares, desde a

compra ou desenvolvimento até o teste e eventual implantação em ambiente de
produção.
O processo começa com o planejamento de uma nova liberação, seja de um software ou

hardware, e termina com uma liberação documentada, armazenada com segurança, com
o menor impacto possível nas atividades do dia-a-dia da organização.
O diagrama seguinte ilustra algumas das situações básicas que envolvem o processo de
Gerenciamento de Liberação.
Antes do Implementação do Após o

Gerenciamento de Gerenciamento de Gerenciamento de
Liberação Liberação Liberação
• Alto risco de vírus

• Redução do risco de vírus
• Problemas devido à
fragilidade do planejamento • Redução de problemas
de liberação de software devido a liberações de
softwares mais
• Aumento na carga de consistentes
trabalho com múltiplas
versões em produção • Melhor aproveitamento dos
recursos (equipe de TI,
• Perda dos softwares software e hardware)
originais que foram
comprados
71
Atividades
O diagrama abaixo mostra as atividades do Gerenciamento de Liberação e seus

relacionamentos com o Banco de Dados do Gerenciamento da Configuração (BDGC):
Teste
Política de Desenvolvimento Construção & elaborado Planejamento Comunicação & Distribuição
liberações & ou compra configuração da de rollout treinamento & instalação
planejamento liberação Aceite da
liberação
• Biblioteca de Software Definitiva (BSD)

• Depósito de Hardware Definitivo (DHD)
• Banco de Dados de Gerenciamento da Configuração (BDGC)
Planejamento e política de liberações
A política de liberações irá documentar como a organização irá receber a liberação de um

novo software ou hardware na infra-estrutura. Nesta política, poderá constar:
Freqüência das liberações aceitas pelo negócio
Uma política de como emitir as liberações de emergência
Uma política de testes e subseqüente liberação dentro da produção
Convenções de nome para as liberações
O planejamento para qualquer liberação poderá conter os seguintes itens:

Conteúdos da liberação
Agenda da liberação
Recursos necessários
Regras e responsabilidades
Plano de back out
Plano de qualidade
Plano de aceite
72
Na política de liberação também poderá ser identificado o tipo de liberação que pode ser
feito. Existem 4 tipos principais:
Completa: todos os elementos da unidade de liberação são construídos, testados,
distribuídos e implementados juntos.
Módulo
Liberação
Comercial
Completa
C3 C2 C1 C4
C21 C22 Unidade de liberação
Delta: uma liberação parcial, geralmente para reparar um problema ou liberar

alguma funcionalidade antes do tempo programado.
Módulo
Comercial
C3 C2 C1 C4
Liberação Delta
C2 C2
1 2 Unidade de
liberação
73
Pacote: inclui pelo menos duas liberações (Delta e Completa). Uma liberação
Pacote tem a intenção de oferecer um período mais longo de estabilidade,
reduzindo a freqüência das liberações.
Liberação Módulo
Completa Comercial
C3 C2 C1 C4 Módulo
Logística
C2 C2 Unidade de L3 L2 L1
1 2 liberação
Liberação
Delta
L2 L2
1 2
Unidade de liberação
Liberação de Emergência: normalmente contém as correções para um número

pequeno de problemas conhecidos. Refere-se à solução de problemas com alta
prioridade.
Outro item que precisa ser definido na política são as unidades de liberação, que
escrevem a coleção de ICs, ou porções da infra-estrutura de TI que são liberadas juntas.
A unidade pode variar, dependendo dos tipos ou itens do software e hardware.
Identificação da liberação:
A liberação ser identificada de modo único
de acordo com a política de Liberação.
Exemplos:
Liberações maiores: Sistema de
Contabilidade v.1, v2, v3 etc.
Liberações menores: Sistema de
Contabilidade v.1.1, v1.2, v.1.3, etc.
Liberações emergenciais: Sistema de
Contabilidade v.1.1.1, v.1.1.2, v.1.1.3, etc.
74
Construção e configuração das liberações
Esta atividade dentro do Gerenciamento de Liberação pode ser considerada como a

fase técnica do processo. As ações associadas com a construção e configuração são
realizadas pela equipe técnica.
No final deste estágio, o plano de backout deve ser criado. Este plano será focado em
restaurar todos os serviços para o seu estado antes de qualquer mudança. Este plano
será avaliado pelo processo de Gerenciamento de Mudança.
A saída desta atividade será a liberação completa com a instrução de sua instalação,
plano de teste e o plano de backout.
Teste e aprovação das novas liberações
A falta de testes adequados antes de implementar a versão no ambiente de produção

é a causa das falhas de todas as liberações.
É recomendável nesta etapa envolver representantes do negócio para testar as

funcionalidades esperadas. Podemos ter aqui o aceite de teste do usuário.
É importante a formalização do aceite da liberação.
Planejamento do rollout de liberações
O plano completo da liberação que foi originalmente criado precisa ser enriquecido com
informações dos detalhes da implantação da liberação (rollout). Este irá incluir:
• Lista de tarefas e recursos necessários para cada tarefa

• Uma lista de todos os ICs que serão instalados e retirados do serviço
• Em caso de múltiplos sites: plano de ação para sites separados levando em
consideração as diferenças de cada um
• Comunicação para todos envolvidos (usuários e equipe de TI)
• Plano para a implantação da liberação comprada (se houver)
• Adquirir hardware e software. O plano de implantação deve incluir os
procedimentos a serem seguidos para armazenamento seguro antes da
implantação e mecanismos para acompanhar sua instalação
• Agenda de reuniões para gerenciamento da equipe e grupos envolvidos na
liberação.
75
Comunicação, preparação e treinamento
É importante comunicar todas as partes envolvidas para obter o aceite e sucesso da

liberação. Isto pode envolver reuniões e sessões de treinamento com grupos de
usuários, equipe de TI e gerentes.
O tempo de qualquer treinamento ou comunicado precisa ser planejado de acordo

com a data de liberação.
A Central de Serviços é a área-chave que precisa ser informada sobre a liberação e

também deve ter conhecimento das possíveis soluções de contorno encontradas
durante a fase de teste.
O plano de liberação deve se tornar público para que todos tenham acesso.
Liberação, distribuição e instalação
Distribuição e instalação são vistas como atividades diferentes. Hoje, com o avanço da
tecnologia, é possível fazer a distribuição de releases através de softwares de
distribuição de pacotes nas estações da rede, o que automatiza esta atividade. A
instalação pode acontecer efetivamente quando o usuário fizer o seu primeiro login na
estação que irá executar um script de logon para iniciar o processo de instalação.
Nesta etapa, deve ser criado um gatilho para atualizar o BDGC com detalhes da
liberação e todos os ICs que sofreram esta atualização.
O Gerente de Liberação será responsável pela definição e manutenção da política de

liberações e por controlar as atividades dentro do processo. O Gerente de Liberação deve
ter uma grande experiência técnica e bons conhecimentos sobre os últimos utilitários e
ferramentas de suporte disponibilizados no mercado. O Gerente de Liberação também é
responsável por:
Preparar o plano de liberação
Autorizar a construção da liberação e configuração
Comunicar-se com outros grupos, tais como usuários, Gerente de Nível de
Serviço, Central de Serviços e Gerente de Mudanças
Coordenar a implementação da Liberação
A equipe responsável pelo processo deverá receber treinamento técnico sobre as

técnicas de desenvolvimento e manutenção de software, bem como sobre a configuração
e instalação de dispositivos de hardware.
76
Relacionamentos
O Gerenciamento de Liberação tem um vínculo muito próximo com o Gerenciamento de

Mudanças e com o Gerenciamento da Configuração. O Gerenciamento de Mudanças
controla todas as mudanças, determina quando uma nova liberação será implantada e
quais mudanças estarão em cada liberação. Em grandes organizações um representante
do processo de Gerenciamento de Liberação participará do Comitê de Controle de
Mudanças.
O Gerenciamento da Configuração precisa ser informado pelo Gerenciamento da

Liberação sobre cada mudança em ICs, então eles poderão atualizar o BDGC. Eles
precisam também certificar-se que as novas versões de software ou hardware estão
sendo armazenadas na BDS ou no DHD. O Gerenciamento de Liberação irá usar o
Gerenciamento da Configuração para conseguir informações sobre cada IC que será
afetado pela nova liberação, e o relacionamento com outros ICs.
Benefícios
A implantação do processo de Gerenciamento de Liberação da ITIL provê as seguintes

vantagens:
• O software é liberado para teste e produção de uma maneira controlada,

reduzindo as chances de erros.
• Os softwares da organização são mantidos em um lugar seguro (na Biblioteca
Definitiva de Software).
• Possibilidade de implantar várias mudanças concorrentes no software que está
sendo utilizado no ambiente de produção sem afetar a qualidade do ambiente de
TI.
• Os softwares em localizações remotas podem ser gerenciados de forma eficiente
e econômica a partir de um ponto central.
• A possibilidade de uso de cópias ilegais é reduzida drasticamente.
• O impacto de um novo hardware é avaliado antes da sua instalação na infra-
estrutura.
• Usuários finais mais informados sobre as liberações e envolvidos no ambiente de
teste. O risco da resistência de novas liberações irá reduzir significativamente.
77
Problemas Comuns
Para que o processo de Gerenciamento de Liberação possa ter sucesso é necessário

levar em consideração alguns problemas:
• Falta de comprometimento: usuários finais podem ser relutantes na primeira vez

que você comunicá-los como devem agir no caso de uma nova liberação. A
vantagem deste processo precisa estar clara antes do processo ser implantado.
• Consertos urgentes: procedimentos precisam estar definidos para assegurar que
não irão comprometer a exatidão do BDGC, do BDS ou do DHD.
• Teste: um ambiente de testes apropriado deve estar disponível para avaliar o
impacto e reduzir os riscos de uma nova liberação. Criar um ambiente de testes
pode ter custos, e é comum a realização de testes direto no ambiente de produção
- o que deve ser evitado.
• Boicotar o processo pode causar a instalação de software ilegal ou a entrada de
vírus na infra-estrutura de TI: auditorias regulares devem ajudar a minimizar esta
questão.
Para avaliar a eficiência do processo de Gerenciamento de Liberação, um número de

indicadores deve ser monitorado.
Exemplos de possíveis indicadores:
• Liberações desenvolvidas, implantadas no prazo e dentro do orçamento.

• Número de liberações que resultaram em retrocesso (backout) devido a erros
inaceitáveis.
• Número de incidentes causados pela liberação.
• Resultado de auditorias feitas na BDS e DHD.
• Precisão e tempo gasto para registrar todas as atividades de desenvolvimento,
distribuição e implantação no BDGC.
78
8. Gerenciamento da Configuração
Introdução
Este é o processo que gera informações para os demais processos da ITIL, tanto para os
processos de suporte como para os processos de entrega. O Gerenciamento da
Configuração é um processo que dá sustentação, que alimenta outros processos com
informações sobre serviços, componentes e ativos de TI. Implementar este processo
isoladamente não faz sentido algum - o Gerenciamento da Configuração somente terá
importância se as informações que ele gerar forem utilizadas pela gerenciar os serviços
de TI.
O Gerenciamento da Configuração é um processo que levanta todas as informações dos

ICs na infra-estrutura de TI, e armazena estas informações no Banco de Dados do
Gerenciamento da Configuração (BDGC). Através deste levantamento, é possível se
obter um modelo lógico da infra-estrutura de TI.
As informações sobre os ICs são úteis por exemplo para identificar todos os componentes
do serviço que serão impactados por uma mudança, ou para fazer um planejamento de
liberação. Sem estas informações, alguns processos da ITIL poderão não ter a efetividade
esperada.
Objetivos
Os principais objetivos do processo do Gerenciamento da Configuração são:
Fornecer informações completas e atualizadas das configurações dos ativos de TI,

como hardware, software e documentações afins
Garantir que apenas componentes autorizados estejam presentes no ambiente de
TI
Criar um banco de dados para outros processos (BDGC)
Acompanhar e registrar todo o ciclo de vida de um IC (quando ele entra na
organização, quando ele sai para manutenção e quando ele se aposenta)
Identificar os relacionamentos entre os ICs (quem se conecta a quem)
Assegurar que todas as modificações estejam atualizadas no BDGC
Auditar e informar exceções às recomendações e padrões de infra-estrutura de TI
e aos procedimentos do processo de Gerenciamento da Configuração
Informar o estado atual e histórico dos ICs
O Gerenciamento da Configuração é responsável por identificar e definir os componentes

que fazem parte de um serviço de TI, registrar e informar o status destes componentes e
o relacionamento entre os Itens de Configuração.
79
O escopo é definido por dois elementos:
• Extensão da responsabilidade do Gerenciamento da Configuração
• A amplitude do Banco de Dados do Gerenciamento da Configuração
O processo de Gerenciamento da Configuração é um dos processos que deve ser

implementado em conjunto com o Gerenciamento de Mudanças e de Liberações, pois não
adianta criar um BDGC se não houver controle sobre as alterações dos ICs na infra-
estrutura. O escopo do processo Gerenciamento da Configuração vai depender muito das
informações que os outros processos vão utilizar. Você não pode ter informação demais,
pois vai ficar difícil manter um nível de detalhe muito grande. E também não pode ter
informação de menos, pois isto pode atrapalhar nas decisões de outros processos.
Este também é um processo que fará o gerenciamento de ativos. O BDGC deve conter
informações contábeis. A diferença que existe deste processo de Gerenciamento da
Configuração para o simples processo de Gerenciamento de Ativos é que este processo,
além de conter informação financeira de todos os ativos, vai conter outras informações,
como o relacionamento de um ativo com outro, relacionamento com registros de
mudanças, incidentes, e outros. Esta é a principal diferença entre estes dois tipos de
processos.
Dentro do escopo da atividade de identificação podem ser considerados os seguintes ICs:

Servidores
Estrutura da rede
Estações de trabalho dos usuários
Softwares (aplicativos, drives, sistemas operacionais)
Softwares de Gestão (ERPs)
Banco físico de dados
Relacionamento entre o banco de dados, aplicações e servidores
Documentação de processos/procedimentos
80
Conceitos
Infra-estrutura de TI: Todos os componentes de TI, como hardware,

software e documentação associada.
Banco de Dados do Gerenciamento da Configuração (BDGC):

base única e centralizada capaz de conter todos os dados e
informações suficientes para o controle dos processos e serviços.
Consiste em uma aplicação capaz de suportar os requisitos para
um BDGC. Existem softwares no mercado que suportam estas
funcionalidades.
Esta aplicação deve permitir:

BDGC • Restauração de dados interativa
• Atualização interativa
• Extrair relatórios
• Importação/exportação automática de dados
• Reestruturação do BDGC para atender a mudanças na infra-
estrutura
As entradas neste BDGC são os Itens de Configuração.
Item de Configuração (IC): unidade de informação. Representação lógica de cada

componente da infra-estrutura de TI.
Infra-estrutura Um item de configuração:

• É necessário para entregar um
serviço
• É unicamente identificável
Hardware Software • Pode fazer parte de uma
mudança
• Pode ser gerenciado
Um item de configuração pode ter:

Servidor Roteador • Categoria
Unix • Relacionamento
• Atributos
• Status
81
Exemplo de uma estrutura de Itens de Configuração:
Redes Servidores
Computado Notebooks Monitores Manuais

r Impressora Maiframes
s
Veja alguns exemplos de informações relacionadas a um Item de Configuração:
Unidade
Localização Produto
Status
Custo
Eventos
Item de Relaciona-
Configuração mentos
Manutenção
Atributos
Usuários
Fornecedor ANS
82
Exemplos de atributos para um Item de Configuração:
CI PC CI Contrato
Identificador: PC2030 Nome: Manutenção

Vigências: 01/01 a 30/12
Local: RH
Fornecedor: XPTO CI Usuário
Contrato: 1030
Nome: Josélito Silva
Usuário: Joselito
Ramal: 190
Aquisição: 30/11/07 CI Local
E-mail: js@kks.com.br
Status: Instalado Nome: RH
Local: RH
Prédio: 1
Cidade: Blumenau
Fone: 47 3030 2020
A principal entrada no processo vem do Gerenciamento de Mudanças, requisitando

informações sobre itens que serão afetados ou reportando o status dos itens mudados.
O processo inicia com o projeto, população e implantação do BDGC. É responsabilidade

do Gerenciamento da Configuração manter o BDGC. A população do BDGC pode ser
cara e prolongada dependendo do escopo da infra-estrutura de TI que está sendo
gerenciada e do nível de detalhes sobre cada item requisitado. Ferramentas de auditoria
automática podem ajudar nesse aspecto. As saídas deste processo são relatórios para o
gerenciamento de TI e disponibilidade de informação que podem ser fornecidas a partir do
BDGC a outros processos.
83
Banco de Dados Biblioteca de
do Gerenciamento SW Definitivo
da Configuração (BSD)
(BDGC)
Incidentes
Política de
• Planejamento Padrões
Problemas
• Identificação
• Controle Relatórios de
Auditoria
Erros
Conhecidos
• Registro do Status
• Verificação e auditoria
Requisições de
Mudanças(RDM)
Mudanças Gerenciamento
Autorizadas de Mudança
Atividades
As atividades do processo de Gerenciamento da Configuração são:

• Planejamento
• Identificação
• Controle
• Acompanhamento do status
• Verificação e auditoria
Planejamento
A atividade de planejamento consiste na definição do propósito, escopo, objetivos,
políticas e procedimentos, contexto técnico e organizacional para o processo de
Gerenciamento da Configuração.
O plano do Gerenciamento da Configuração deve incluir a definição e acordo sobre:

• Estratégia (foco nos fatores críticos de sucesso - considerações sobre outros
processos)
• Situação atual (informações que já existem mapeadas)
84
• Contexto organizacional (o contexto em que o Gerenciamento da Configuração será
implantado)
• Interfaces (processo ITSM, projetos, fornecedores, aplicações, times de suporte)
• Processos, papéis e responsabilidades
Identificação
A atividade de identificação envolve a coleta de todas as informações do IC dentro do
escopo do processo. A informação do IC é coletada manualmente e/ou pelo uso de
ferramentas automatizadas. Na hora de coletar estes dados, cada IC deverá ser
etiquetado para referência e propósitos de controle.
O que deve ser levado em consideração:
Estrutura de configuração
ICs
Escopo
Nível do IC e atributos
Levantamento e registro de dados (etiquetar)
Relacionamentos (pai/filho, contém, depende de)
Controle
Antes de o BDGC ser populado, procedimentos de controle já devem existir. É vital que as
mudanças dentro do BDGC sejam feitas apenas com autorização. Procedimentos
necessários precisam ser estabelecidos para que todas as mudanças sejam
documentadas.
Controles principais:
Registro de novos ICs e arquivamento no BDGC
Atualizações quanto a mudanças (configuração, local, responsável)
Atualização do status
Controle de licenças
Garantir que apenas os ICs autorizados estão presentes na infra-estrutura de TI
85
Registro do status
O acompanhamento do status é uma atividade que registra o estado atual e anteriores de
um IC, podendo desta forma um IC ser rastreável. Os níveis de status podem ser
definidos como parte do processo de planejamento (exemplo: em compra, em uso, fora de
uso, em reparo, aposentado).
IC em
desenvolvimento
Ciclo de vida de um IC
Teste
Agendado para
implementar
IC fora para
manutenção IC em Uso
IC aposentado
Verificação e auditoria
Ao conduzir auditorias regulares na organização pode-se verificar que todos os ICs estão
registrados corretamente. A primeira auditoria deve ser aguardada logo após o BDGC ser
implementado, para certificar que esta é uma representação correta da infra-estrutura de
TI atual. Auditoria também pode ocorrer após desastres e mudanças graves.
A freqüência de auditorias dependerá do resultado ou valor que ela pode agregar nas
informações e o gasto que ela irá gerar. Auditorias parciais e auditorias em pontos
específicos são estratégias que podem ser mais rápidas e baratas.
86
O Gerente de Configuração irá ajudar na definição do escopo e níveis de detalhes

necessários no processo, implantado procedimentos de interação com outros processos e
assumindo a responsabilidade pelo planejamento e população do BDGC. É comum este
papel ser compartilhado com a mesma pessoa que assume o papel de Gerente de
Mudanças.
O Bibliotecário da Configuração é a pessoa que controla o acesso às cópias-mestre de

softwares e documentações. O foco é nos itens físicos. Este bibliotecário também pode
ser responsável pelo controle das cópias de software na BSD.
Relacionamentos
Conforme já indicado, a infra-estrutura de TI forma o fundamento de uma organização de

TI. Todos os processos dentro da ITIL conseqüentemente terão vínculos com o
Gerenciamento da Configuração ou buscarão informações dentro do Banco de Dados do
Gerenciamento da Configuração.
Entretanto o Gerenciamento de Mudanças e o Gerenciamento de Liberações têm um

relacionamento muito próximo com o Gerenciamento da Configuração e poderiam ainda
ser considerados parte integral deste. O gráfico de fluxo seguinte mostra o
relacionamento entre os 3 processos e como o fluxo ocorre entre os processos em cada
estágio.
87
Aqui temos um loop que ilustra o BDGC fornecendo informações durante todo o ciclo de
suporte:
Incidente
Fecha
Problema BDGC Implementa
Mudança
Benefícios
Alguns dos benefícios que decorrem da implantação do Gerenciamento da Configuração

incluem:
• Disponibilidade para fornecer informações para outros processos sobre ICs e o
relacionamento entre eles
• Contribuição para o planejamento da continuidade dos serviços de TI
• Controle da infra-estrutura de TI (sabendo onde o IC está e quem é responsável
por ele)
• Gerenciamento de Problemas eficiente e eficaz
• Processamento de mudanças eficiente e eficaz
• Segurança de que as obrigações legais estão sendo executadas
• Questões de suporte à segurança otimizadas.
Problemas Comuns
Problemas que podem evitar uma implantação eficiente do Gerenciamento da

Configuração são:
• O nível de detalhes dos ICs não estar correto. Se o nível de detalhes for muito
profundo, muita informação será registrada e irá tomar muito tempo, dinheiro e
esforço para manter. Entretanto se o nível de detalhes não for suficiente, poderá
prejudicar a tomada de decisões para outros processos, gerando mais problemas
e incidentes.
88
• Mudanças emergenciais normalmente acontecem fora do horário normal de
operação. Pode ser que nenhuma pessoa tenha sido autorizada para registrar as
mudanças no BDGC. Isto pode ser evitado através de um procedimento de
atualização pós-mudança. De outra forma a confiança do BDGC pode ser
comprometida.
• Comprometimento: deve haver um comprometimento da equipe de TI com este
processo. A disciplina será necessária para assegurar que mudanças na infra-
estrutura devem seguir procedimentos para manter o BDGC preciso.
• Interação com outros processos. Como o Gerenciamento da Configuração se
baseia no Gerenciamento de Mudanças e de Liberação, seria recomendável
implantar estes processos ao mesmo tempo.
• Controle. Deve haver um processo implantado que assegure a validade do BDGC.
Por exemplo, usuários que compram softwares sozinhos pela internet podem criar
incidentes que são difíceis de resolver devido ao desconhecimento das mudanças
de configuração (tipicamente você houve “Eu não mudei nada!!”).
A mensuração do processo de Gerenciamento da Configuração pode ter muitos IPDs que

podem ser analisados. Para medir a eficácia do Gerenciamento da Configuração são
necessários objetivos realistas. Os objetivos podem ser mudados durante o tempo para
assegurar a melhoria do processo.
• Resultado das auditorias: número de ICs não autorizados, ICs que não estão em
uso.
• Número de mudanças que ocorreram devido à informação errada de configuração,
causando incidentes ou problemas.
• RDMs que não foram completadas com sucesso devido à avaliação pobre de
impacto, dados incorretos no BDGC ou fraco controle de versão.
• O tempo que uma mudança leva para iniciar e acabar.
• Licenças de softwares que não foram aproveitadas ou não estão em uso.
Outros indicadores podem incluir:
• A quantidade de chamadas por mês que foram resolvidas pelo telefone usando
informações do BDGC.
• Redução de incidentes e problemas ao longo do tempo e a mudança no impacto
que eles tiveram no negócio.
• Melhoria do prazo necessário para resolver incidentes e problemas que não
podiam ser resolvidos imediatamente.
• Número de mudanças no BDGC por mês devido à identificação de erros no
BDGC.
89
• Tempo necessário para registrar um IC.
Melhores Práticas
O BDGC
Muitas organizações já usam algum tipo de BDGC, em planilhas ou em papel. Em muitos

casos o BDGC é baseado em tecnologia de banco de dados, o qual coleta informações
do usuário de forma mais amigável. Existem hoje softwares de coleta de inventário que
varrem a rede cadastrando computadores conectados e softwares instalados. Estas
informações de coleta podem ser depois integradas em um BDGC.
Um BDGC também contém informações de relacionamentos entre incidentes, problemas,

Erros Conhecidos, mudanças, liberações e ICs. Se for implementado um software de
Gerenciamento de Serviços, ele pode conter suporte a todos os processos da ITIL, com
um BDGC integrado que irá fornecer todas estas informações.
Alguns exemplos de “relacionamentos” que podem ser definidos:

• Depende de:
o ANS “Provisão de Serviços Bancários” depende do servidor de aplicação
X2
o ANS “Provisão de Serviços Bancários” depende da impressora 9
• É parte de:
o ANS “Provisão de Serviços Bancários” afeta o cliente 11
• É vinculado a:
o Sistema bancário vinculado ao sistema administrativo
• Tem:
o Impressora 9 tem a RDM 0019 aplicada
90
9. Gerenciamento do Nível de Serviço
Introdução
Este é o primeiro processo do livro Entrega de Serviço que vamos estudar. Todos os
outros processos apresentados até agora fazem parte do livro Suporte ao Serviço da ITIL
V2. Os processos do livro de Entrega de Serviço são processos táticos e não incluem
atividades que são executadas no dia-a-dia como as do Suporte ao Serviço.
Já sabemos da importância da TI para negócio, e que os serviços de TI são habilitadores

para os processos de negócio da organização. Sabemos também que a TI deve ser
focada nas necessidades do cliente e não pode apenas desenvolver tecnologia para si,
mas sim desenvolver serviços que gerem valor para os clientes. E se um dos objetivos de
implementar um gerenciamento de serviços de TI é melhorar a qualidade dos serviços e
aumentar a satisfação do cliente, nada mais primordial do que ouvir o que o cliente quer,
quais são seus desejos, suas necessidades atuais e futuras, suas premissas. Sem saber
o que o cliente quer, a TI não vai ter condições de entregar aquilo que deveria ser
entregue. A TI não pode adivinhar ou impor o que ela acha, é preciso de fato levantar as
necessidades junto aos clientes.
A implantação do processo de Gerenciamento do Nível de Serviço irá resolver a maioria

dos problemas de alinhamento entre TI e negócio. Um dos elementos mais conhecidos no
Gerenciamento do Nível de Serviços são os Acordos de Nível de Serviços (ANSs - em
inglês, SLAs). Os ANSs permitem que o provedor de TI e o cliente decidam juntos sobre
quais serviços devem ser fornecidos, a disponibilidade necessária, demandas e seus
custos. Estes níveis devem ser mensuráveis para ambos os lados poderem verificar se
estão sendo atendidos. A TI precisa acordar com o cliente o que vai ser entregue. E em
todo acordo deve haver uma negociação - nem tudo aquilo que o cliente pede é possível.
O cliente sempre vai querer o melhor serviço com o menor custo possível, mas sabemos
muito bem que serviço de alta qualidade está normalmente na contramão de serviço de
baixo custo.
O Gerenciamento do Nível de Serviço é o processo que forma o vínculo entre o provedor

de TI e os clientes. Para implantar este processo com sucesso é necessário que os outros
processos da ITIL já tenham sido implantados. De nada adianta realizar acordos com o
cliente se de fato nada será entregue conforme prometido. É necessário ter processos de
suporte que sustentem os níveis de serviço acordados.
O foco principal deste processo é assegurar os serviços de TI acordados com o cliente

são fornecidos com a qualidade esperada e a um custo aceitável ao negócio. É este
processo que vai gerar metas para disponibilidade, capacidade e continuidade, e vai
também definir os targets para o tempo de restauração de incidentes. O Gerenciamento
do Nível de Serviço é o núcleo do Gerenciamento de Serviços. Alguns até dizem que o
Gerenciamento do Nível de Serviço é o mais importante dentro da ITIL. Isto é difícil de
argumentar, pois todos os processos têm a mesma importância. É verdade que o
Gerenciamento do Nível de Serviço tem um foco maior no cliente se comparado com os
outros processos, mas sem os outros processos é impossível atender ao cliente.
91
Objetivo
Principais objetivos deste processo:

Catalogar os serviços de TI
Melhorar a qualidade percebida pelos usuários e clientes dos serviços de TI
Reduzir a indisponibilidade dos serviços de TI
Alcançar metas de serviços internos e externos
Manter o foco nas necessidades do negócio
Garantir o alinhamento entre o negócio e a área de TI
Aperfeiçoar continuamente os níveis de serviço
Este processo foca no relacionamento com o cliente e na garantia de qualidade do serviço

entregue. Para a garantia do serviço entregue será necessário realizar acordos com as
equipes de TI, como a equipe de redes e de manutenção de hardware, para cumprir
metas internas que satisfaçam os ANSs com clientes. Também envolve os fornecedores,
pois muitos serviços de TI oferecidos aos clientes têm dependência de fornecedores,
como por exemplo o suporte ao sistema de gestão ERP e telefonia.
Relações existentes com o provedor de serviços de TI que serão tratadas pelo

Gerenciamento do Nível de Serviço.
Provedores internos
Provedor de serviços TI
Fornecedores Clientes
externos
92
Conceitos
Para entender o processo de Gerenciamento do Nível de Serviço é necessário entender
alguns conceitos básicos que são usados que serão explicados aqui para que o processo
se torne mais fácil de entender.
Requisitos de Nível de Serviços (RNSs)
Documentos que contém todos os requisitos do cliente relacionados aos serviços de TI.
Define a disponibilidade e desempenho que os clientes precisam para estes serviços. É o
ponto inicial para traçar os Acordos de Nível de Serviço.
Especificações de Serviço
A organização de TI rascunha as Especificações de Serviço baseada nos RNSs. É uma

transcrição dos requisitos do cliente e “como” a organização de TI irá fornecer estes
serviços. Quais são as necessidades técnicas? Ele irá mostrar os relacionamentos entre
os ANSs, fornecedores e a própria organização de TI.
Acordos de Nível de Serviço (ANSs)
O ANS é um documento que define níveis de serviços acordados entre o cliente e o

provedor de serviços (por exemplo, entre TI e o negócio). O ANS deve ser escrito em
linguagem que o negócio entenda, clara, concisa e livre de jargões. O ANS não deve
incluir diagramas de procedimentos detalhados para outros processos ou informações
técnicas.
Contratos de Apoio (CAs)
Com um fornecedor externo ou terceiro que está sendo envolvido na entrega de serviços
de TI haverá um contrato que garanta que ele fornecerá o serviço dentro de prazo, custo,
nível, etc. A organização de TI passa os requisitos do negócio para os fornecedores
externos.
Este documento será reflexo dos níveis de serviços definidos nos ANSs. Por exemplo, se
o ANS apresenta um conserto de uma impressora em 5 dias, então o CA com o terceiro
deverá dar suporte a esta necessidade, por exemplo consertando da impressora e
retornando para a organização em 3 dias.
Acordos de Nível Operacional (ANOs)
Alguns serviços de TI dependem de outros serviços providos dentro da própria

organização de TI. Por exemplo, um sistema que é executado via rede depende da
disponibilidade da rede. Acordos sobre a disponibilidade da rede serão desenhados em
um Acordo de Nível Operacional (ANO). Assim como o CA, estes “contratos” internos irão
dar suporte aos ANSs da mesma maneira. A diferença é que o foco é voltado para dentro
da organização de TI.
93
A figura abaixo ilustra o relacionamento entre o cliente, a organização de TI e provedores
externos de serviços:
Plano de Qualidade de Serviço
Este plano irá conter informação sobre indicadores de performance para a organização de
TI medir os serviços. Ele irá conter indicadores de desempenho para cada um dos
processos que estão sendo implantados na organização. É importante também incluir
indicadores de desempenho nos CAs e ANOs - assim eles contribuirão para o serviço de
TI como um todo.
Catálogo de Serviço
Este é um documento que contem todos os serviços que estão sendo fornecidos,
descrição, níveis, custo, cliente e pessoa/departamento responsável pela manutenção do
serviço. O conteúdo do Catálogo de Serviço irá variar de acordos com os requisitos da
organização de TI.
As folhas de Especificação de Serviço freqüentemente formam parte do Catálogo de

Serviço.
Relacionamentos entre os documentos
Negócio RNS
ANS
TI representada
por um Gerente Catálogo
de Nível de de Serviço
Serviço
ANO CA
(Acordo com grupos (Acordo com fornecedores
de TI internos) de serviço externo)
94
• Define
Início do
G NS
• Executa
• Controla
Planejar
Implementar AN S(SLAs)
Desenhar o
Fehar ANS
CAs/ANOs
Catalogar
Gerenciar o processo
Negociar
serviços
Revisar
acordo
contínuo
Monitorar
Reportar
Revisar
Revisões
Periódicas
Revisar SLAs
Revisar o
processo
O processo de Gerenciamento do Nível de Serviço é um ciclo de qualidade completo que

está sempre em loop. Uma vez que os ANSs são definidos, o loop é iniciado.
Quando o processo for iniciar, o primeiro passo será planejar as atividades, desenhando
os procedimentos, criando o catalogo de serviços e rascunhando os ANSs possíveis.
Na fase de implementação dos ANSs deve-se planejar a estrutura dos acordos,

estabelecendo os próprios acordos com os clientes e revendo os contratos de apoio com
terceiros que você poderá precisar no apoio ao fornecimento dos serviços de TI.
Uma vez estabelecidos e acordados os ANSs com os clientes, definidos os acordos

internos com as equipes de TI e revistos contratos com terceiros, é hora de gerenciar o
processo contínuo. Nesta etapa, deve-se monitorar através de indicadores de
desempenho se estamos conseguindo atender aos ANSs e gerar relatórios estatísticos.
Na revisão periódica teremos reuniões com as equipes de TI, ou até com o cliente se
necessário, para verificar o cumprimento das metas estabelecidas nos ANSs. Para o que
não estiver sendo cumprido, deve ser traçado uma ação corretiva. Estas ações podem
fazer parte do Programa de Aperfeiçoamento do Serviço (PAS) contínuo.
95
Atividades
Clientes demanda Identificação Requisitos de Nível

de Serviços
Definição Especificação de
Serviço
Plano de Qualidade
de Serviço
Acordos de Nível de
Serviços
Negociação Acordos de Nível

Operacional
Catálogo de Serviço
Contratos de Apoio
Monitoração Realizações de Nível

de Serviços
Relatório Relatório de Níveis de

Serviço
Revisão Programa de
Aperfeiçoamento de
Serviços
As principais atividades do Gerenciamento do Nível de Serviço consistem de:

• Compor o Catálogo de Serviço
• Negociar com os clientes baseado nas possibilidades e preços
• Assegurar e manter o Acordo de Nível Serviço (ANS)
Isto será feito através de um ciclo constante das seguintes ações:
• Identificação
• Definição
• Negociação
• Monitoração
96
• Relatório
• Revisão
Identificação
Dentro desta atividade a organização de TI precisará definir os serviços que ela fornece
dentro do Catálogo de Serviço. O Catálogo de Serviço é como se fosse um menu de
serviços que a TI oferece, e os componentes destes serviços.
Neste estágio o relacionamento entre a organização de TI e o cliente é criado ou mantido.

O foco é identificar os requisitos do cliente em relação aos serviços de TI. Como parte
desta atividade, o documento de RNS é escrito. Este documento será assinado por
ambas as partes, para assegurar que esteja claro o entendimento do que será realizado
pela TI e os requisitos relacionados ao negócio.
Definição
O primeiro resultado desta atividade será a entrega do RNS, da folha de especificação de

serviço e do Plano de Qualidade de Serviço.
A partir dos RNSs e do Catálogo de Serviço será feita uma proposta do ANS que alinha
ambos em níveis de serviços aceitáveis. Durante a criação deste documento a elaboração
de CAs e ANOs é critica para dar suporte ao ANS.
As necessidades do cliente podem ser alteradas devido a mudanças nos procedimentos

do negócio. Neste caso as especificações e os serviços precisam ser mudados ou
tecnologias mais avançadas precisem ser adotadas.
Negociação
Uma vez que a proposta do ANS é formulada, é hora de fazer o acordo, aceite e
assinatura para os seguintes documentos:
• Acordo de Nível de Serviço

• Contratos de Apoio
• Acordo de Nível Operacional
É necessário que os documentos acima sejam negociados e assinados.
97
Monitoração
Se os níveis não podem ser medidos ou monitorados seus valores serão reduzidos
significativamente. Por que criar níveis de serviço se você não sabe se eles estão sendo
alcançados?
Para que os níveis de serviços possam ser medidos eles precisam ser claros e ter um
objetivo.
Não é suficiente definir por quanto tempo um serviço pode estar indisponível, é
necessário também definir quando o serviço estará disponível novamente. E é
considerado disponível quando a organização de TI restaurar o serviço ou quando os
usuários forem notificados que ele já se encontra disponível?
Para monitorar o desempenho, disponibilidade e dar suporte aos níveis de serviço, outros
processos tais como Gerenciamento da Capacidade, de Disponibilidade e de Incidentes já
devem existir. Estes processos irão gerenciar e reportar sobre os níveis de serviços para
o processo de Gerenciamento do Nível de Serviço.
Relatório
Os relatórios devem mostrar números sobre os níveis de serviços que são necessários e
os níveis de serviços medidos de fato.
Itens que podem ser incluídos aqui:
• Tempo necessário para resolver os incidentes

• Downtime da rede e qualquer outra situação onde os níveis de serviço não estão
sendo atingidos
• Tempo necessário para uma mudança
• Todas as interrupções graves no serviço em detalhes
• Uso da capacidade (mínimo e máximo)
• Quantidade de interações com vários serviços
Revisão
Revisar regularmente os serviços com os clientes irá ajudar a descobrir oportunidades

para melhorar o que está sendo fornecido. Com a ajuda do Programa de Aperfeiçoamento
de Serviço Contínuo isto poderá ser alcançado.
Uma vez que os Acordos de Nível de Serviço estejam documentados, isto não é o final do
processo - é apenas o começo. É também importante revisar regularmente como os
processos estão sendo operados, e atualizá-los quando necessário.
98
O Gerente de Nível de Serviço é responsável pela implantação dos processos e

manutenção e melhoria dos níveis de serviços através das ações de melhoria. Esta
função requer uma posição que permita à pessoa negociar os níveis de serviços com os
clientes em nome da organização de TI.
O Gerente de Nível de Serviço fiscaliza os passos que resultam nos seguintes

documentos oficiais:
• Requisitos de Nível de Serviço (RNSs)

• Especificações de Serviços
• Acordos de Nível de Serviço (ANSs)
• Contratos de Apoio (CAs)
• Plano de Qualidade de Serviço
• Programa de Aperfeiçoamento de Serviço (PAS Contínuo)
Relacionamentos
O Gerenciamento do Nível de serviço é o resultado da implantação dos processos de

Gerenciamento de Serviço. O Gerenciamento do Nível de Serviço está relacionado com
cada um dos processos da ITIL. Você não pode implantar este processo com o objetivo
de alcançar a maturidade completa sem os outros nove processos e a função da Central
de Serviços devido à aproximação holística com o Gerenciamento de Serviços.
Os processos de suporte a serviços, incidentes e problemas e a Central de Serviços

focam em restaurar os serviços o mais breve possível quando existir alguma falha nos
níveis de serviços. Eles fornecem ao Gerenciamento do Nível de Serviços informações
valiosas, como a percepção do cliente em relação aos níveis de serviço.
Os processos de entrega de serviços são mais focados em manter os serviços dentro dos
parâmetros definidos no ANS. Eles coletam informação a partir do Gerenciamento do
Nível de Serviço sobre quais são os níveis necessários, dão informação sobre os níveis
atuais e avisam sobre o impacto de novos serviços ou mudanças em serviços.
Benefícios
Implantar o Gerenciamento do Nível de Serviços trará os seguintes benefícios para o

negócio e para a organização de TI:
• O serviço de TI terá uma qualidade maior e irá causar menos interrupção. Por
conseqüência a produtividade dos clientes da TI será aperfeiçoada.
• Os recursos da equipe de TI serão usados de forma mais eficiente.
99
• A organização de TI fornecerá serviços que satisfaçam as expectativas dos
clientes.
• O serviço fornecido poderá ser medido.
• A percepção da organização de TI será melhorada.
• O custo será reduzido.
• Os serviços de fornecedores são mais bem gerenciados com Contratos de Apoio,
reduzindo a possibilidade de influência negativa no serviço de TI fornecido.
• O monitoramento do serviço se torna possível identificando os pontos fracos que
podem ser melhorados.
Problemas Comuns
As seguintes questões podem ser aplicadas para assegurar o sucesso do processo de

Gerenciamento do Nível de Serviço:
• Os níveis de serviços previstos no ANS precisam ser alcançáveis pela

organização de TI em primeiro lugar.
• OS CAs e ANOs precisam ser escritos corretamente para que os fornecedores ou
grupos internos não criem inadvertidamente brechas (falhas) nos níveis de
serviços acordados.
• Os serviços precisam ser mensuráveis.
• Os Acordos de Nível de Serviços precisam regularmente ser revisados e
negociados para que não se tornem obsoletos.
As seguintes questões irão ajudar a determinar se o processo de Gerenciamento do Nível

de Serviço é eficaz e eficiente:
• Todos os serviços estão sendo cobertos por ANSs?

• Os serviços dentro do ANS têm CA’s ou ANO’s necessários?
• Existe alguma melhoria nos níveis de serviço?
• Os níveis de serviço são medidos?
• A percepção sobre a melhoria na organização de TI está melhorando?
100
10. Gerenciamento da Disponibilidade
Introdução
As organizações estão se tornando cada vez mais dependentes dos serviços de TI. Já
sabemos que a indisponibilidade dos serviços de TI gera prejuízos financeiros para o
negócio, pois sem TI as operações simplesmente param. Além da criticidade que alguns
serviços de TI têm para o negócio, as organizações não funcionam mais apenas 8 horas
por dia - há também a demanda por disponibilidade de serviços 24/7 (7 dias por semana,
24 horas por dia). Lojas virtuais, por exemplo, exigem serviços de TI disponíveis 24/7. Os
serviços bancários hoje são estendidos através do home-banking, por isto um banco não
funciona mais apenas no horário tradicional.
É vital para a organização de TI gerenciar e controlar a disponibilidade dos seus serviços

de TI. Isto é feito a partir da combinação dos requisitos de negócio com a disponibilidade
dos serviços. Estes requisitos do negócio são levantados pelo processo de
Gerenciamento do Nível de Serviço.
Objetivo
Objetivos do processo:
Projetar os serviços de TI para entregar níveis de disponibilidade exigidas pelo

negócio
Fornecer relatório de disponibilidade para demonstrar confiança e sustentabilidade
Reduzir excesso de freqüência e duração dos incidentes que impactam a
disponibilidade
Realizar ações corretivas para as paradas não programadas
Elaborar o plano de disponibilidade
Otimizar a disponibilidade da infra-estrutura e ajudar a entregar um nível de
disponibilidade a um custo aceitável ao negócio
O Gerenciamento de Disponibilidade pode ser aplicado a:
Todos os novos serviços de TI

Serviços existentes com ANSs implementados
Fornecedores de TI (internos e externos)
Todos os aspectos da infra-estrutura de TI que possam afetar a disponibilidade
O Gerenciamento de Disponibilidade não é Gerenciamento da Continuidade dos

Serviços de TI. Vamos abordar mais adiante as diferenças que existem entre estes
dois processos.
101
Conceitos
A terminologia-chave e ações que formam a base deste processo são:
Disponibilidade (Availability)
• Habilidade de um serviço de TI ou componente realizar sua função requisitada em
determinado instante ou durante um período de tempo.
• Apoiada pela confiança, sustentabilidade, capacidade de serviço e tolerância de falhas
na infra-estrutura de TI.
• Medida pela Média de Tempo entre Falhas (MTBF – Mean Time Between Failures)
Para calcular a disponibilidade usa-se a seguinte fórmula:
D = (TS – DT) / TS x 100, onde:
D = Disponibilidade, TS = Tempo de Serviço Acordado e DT = Downtime.
Confiabilidade (Reliability)
• Habilidade de trabalhar sem falha operacional.
• Depende da probabilidade de uma falha de cada componente e manutenção aplicada
para prevenir a ocorrência de falhas.
• Medida pela Média de Tempo entre Incidentes do Sistema (MTBSI – Mean Time
Between System Incidents)
Habilidade de Manutenção (Maintainability)

• Habilidade para segurar e restaurar um estado operacional.
• Depende de antecipação, detecção, diagnóstico, resolução, recuperação de
falhas, restauração dos dados e serviço de TI.
• Medida pela Média de Tempo para Reparar (MTTR – Mean Time T Repair)
Habilidade de obter Serviço (Serviceability)

• Habilidade de manter a disponibilidade, confiança e manutenção fornecida pelos
acordos com os provedores de serviços de TI.
• Não pode ser medida por métrica.
102
Redundância ou Tolerância a Falhas (Resilience)
• Habilidade de um serviço de TI permanecer operacional devido à má função de um ou
mais sub-componentes.
Segurança
Definida em termos de confiabilidade, integridade e disponibilidade dos dados associados
ao serviço.
Função de Negócio Vital

Funções críticas para a organização, identificadas através de um processo formal como a
avaliação de risco.
Requisitos de negócio Critérios para projeto de

disponibilidade e de
relacionados com a recuperação
disponibilidade
Avaliação do impacto Redundância e avaliação da
no negócio - Planejar infra-estrutura de TI
- Aperfeiçoar
Requisitos de - Medir e reportar Objetivos acordados para
disponibilidade, disponibilidade,
confiabilidade e confiabilidade,
sustentabilidade sustentabilidade
Relatórios sobre
Dados de problemas e disponibilidade,
incidentes confiabilidade,
sustentabilidade
Dados de Monitoramento da
disponibilidade
configuração e
monitoramento
Plano de melhoria da
Níveis de Serviço disponibilidade
acordados
O Gerenciamento da Disponibilidade depende de muitas entradas para funcionar

corretamente. Entre as entradas temos:
• Os requisitos relacionados à disponibilidade do negócio

• Avaliação do impacto no negócio quando um determinado serviço fica
indisponível
• Informações relacionadas à confiabilidade, sustentabilidade, capacidade de
recuperação e oficiosidade dos ICs
103
• Informações de outros processos, incidentes e problemas relacionados à
indisponibilidade
• Dados de configuração e monitoramento de serviço para ajudar a medir a
disponibilidade
• Targets de níveis de serviço acordados com o cliente
As saídas do processo são:
• Critérios para projeto de disponibilidade e de recuperação

• Recomendações relacionadas à infra-estrutura de TI para assegurar sua
resiliência
• Objetivos acordados para disponibilidade, confiabilidade, sustentabilidade.
• Monitoramento da disponibilidade
• Relatórios sobre a disponibilidade dos serviços
• Procedimentos para assegurar a disponibilidade e recuperação de cada serviço de
TI (novo ou aperfeiçoado)
• Planos para aperfeiçoar a disponibilidade dos serviços de TI
Atividades
Atividades do Gerenciamento da Disponibilidade
Determinar os requisitos da disponibilidade
Projetar a disponibilidade
Planejamento
Gerenciamento Projetar a recuperação
da
Disponibilidade
Questões sobre segurança
Gerenciamento da Manutenção
Aperfeiçoamento
Desenvolvimento de um plano de disponibilidade
Medição &
Relatório
Medição e emissão de relatórios
Estas atividades dentro do processo podem ser divididas em três atividades principais, as
quais serão discutidas em detalhes durante este capítulo:
• Planejamento
104
• Aperfeiçoamento
• Medição & Relatório
Planejamento
O planejamento envolve as seguintes atividades:

Determinar os requisitos da disponibilidade
É importante não apenas identificar os requisitos, mas também identificar se e como a
organização de TI pode atender a estes requisitos. O processo de Gerenciamento do
Nível de Serviço mantém contato com o negócio e possibilita atender às expectativas do
cliente por meio do processo de Gerenciamento da Disponibilidade. O cliente pode ter
uma expectativa realista com respeito à disponibilidade sem entender o que isto significa
na verdade. Por exemplo, o cliente pode querer uma disponibilidade de 99,9% sem
perceber que isto irá custar cinco vezes mais do que fornecer a uma disponibilidade de
98%. Gerenciar essas expectativas é responsabilidade do Gerenciamento do Nível de
Serviço e do processo de Gerenciamento da Disponibilidade.
Planos
Quando estiver considerando o arranjo da infra-estrutura da organização de TI, pode-se
ainda levar em conta um plano de “disponibilidade” e “recuperação”.
Plano de disponibilidade
Quando o negócio não puder arcar com os prejuízos de um serviço particular estar “fora
do ar” (downtime) por um período de tempo, um plano para a disponibilidade fazendo um
arranjo na infra-estrutura será necessário. Neste momento a organização de TI irá
precisar construir resiliência dentro da infra-estrutura e assegurar que a manutenção
preventiva possa ser executada para manter os serviços em operação. Em muitos casos
criar uma “disponibilidade extra” dentro da infra-estrutura é uma tarefa cara que precisa
ser justificada pela necessidade do negócio.
Fazer um plano para a disponibilidade é considerado uma tarefa pró-ativa para evitar o
downtime nos serviços de TI.
Plano de recuperação
Quando o negócio puder tolerar algum downtime do serviço ou a justificativa do custo não
puder ser feita para construir uma resiliência adicional dentro da infra-estrutura, então um
plano para a recuperação será mais apropriado. Neste caso a infra-estrutura será
projetada de tal forma que no evento de uma falha a recuperação do serviço seja a mais
rápida possível.
Planejar a recuperação pode ser visto como uma tarefa mais reativa do Gerenciamento
da Disponibilidade.
Os processos (como o Gerenciamento de Incidentes) precisam já estar definidos para

recuperação o mais rápido possível no caso de uma interrupção do serviço.
105
Outras considerações
• Questões sobre segurança
Defina as áreas de segurança e o impacto que elas podem ter na disponibilidade dos
serviços. Certifique-se que esteja claro quem tem acesso ao que e onde.
• Gerenciamento da manutenção
Defina uma “janela de manutenção” acordada e conhecida pelos clientes na qual a

organização de TI possa fazer manutenção e reparos. Desta forma o impacto sobre os
serviços de TI será reduzido.
Aperfeiçoamento
Desenvolvimento de um plano de disponibilidade. Esta plano irá visar o futuro

(normalmente 12 meses) e documentará quais medidas serão utilizadas para assegurar
que a infra-estrutura e serviços de TI estarão disponíveis para alcançar os requisitos do
negócio.
Entradas a partir da monitoração e outros processos, como o Gerenciamento do Nível de

Serviço, irão fornecer embasamento para decisões sobre quais medidas de
disponibilidade serão utilizadas. Todos os planos precisam ter custos justificáveis e
alinhamento às necessidades do negócio.
Medição & Relatório

Envolve relatórios sobre a disponibilidade de cada serviço, downtime e tempos para
recuperação. Estes relatórios irão freqüentemente para o processo de Gerenciamento do
Nível de Serviço para serem usados em comparações (planejado x realizado) sobre os
níveis de serviço entregues ao cliente.
É também importante medir e reportar a percepção dos clientes sobre a disponibilidade

dos serviços de TI.
Você pode usar muitas formas para identificar a disponibilidade e problemas potenciais.
Os seguintes métodos são mencionados pelo OGC:
• AIFIC: Análise de Impacto em Falhas de Componentes - para predizer e avaliar o

impacto sobre os serviços de TI que surgem a partir de falhas de componentes
dentro da infra-estrutura de TI.
• ATF: Análise de Tolerância à Falha - para determinar a cadeia de eventos que
causa uma interrupção dos serviços de TI.
• AIS: Análise de Interrupções de Sistemas - para fornecer uma visão estruturada e
identificar as causas-base da interrupção do serviço ao usuário.
O Gerente de Disponibilidade tem uma função que orienta e tem uma visão geral sobre
a infra-estrutura de TI. Irá se reunir e analisar dados a partir dos processos como
Gerenciamento de Problemas, Gerenciamento de Mudanças, Central de Serviços e
106
Gerenciamento da Capacidade para assistir no gerenciamento e planejamento
relacionado à disponibilidade.
Usando os resultados destes dados ele pode dirigir os processos de Gerenciamento de

Serviços para assegurar a disponibilidade acordada, desta forma ajudando a prevenir
problemas. Por exemplo, ele pode estar presente nas reuniões do Comitê de Controle de
Mudanças dentro do Gerenciamento de Mudanças.
O Gerente de Disponibilidade comunica suas descobertas para o Gerente de Nível de

Serviço e, desta forma, faz uma contribuição importante para o estabelecimento dos
ANSs. Ele implanta políticas do Gerenciamento de Segurança em relação à segurança
dos dados.
Relacionamentos
A introdução do Gerenciamento de Disponibilidade sem os outros processos já definidos

tende a ter falhas. Sem o suporte dos outros processos ele não pode prover a
disponibilidade acordada.
O Gerenciamento de Incidentes e o Gerenciamento de Problemas fornecem uma entrada-

chave para assegurar ações corretivas apropriadas. As medidas e relatórios da
disponibilidade de TI garantem que o nível de disponibilidade entregue atenda o Acordo
de Nível de Serviço. O Gerenciamento da Disponibilidade dá suporte ao processo de
Gerenciamento do Nível de Serviços, fornecendo medidas e relatórios para a revisão de
serviços.
Benefícios
O principal benefício é o uso eficiente da capacidade da infra-estrutura de TI e

atendimento da disponibilidade dos serviços de TI de acordo com os requisitos acordados
com os clientes.
Outros benefícios incluem:

• Constante empenho para aperfeiçoar a disponibilidade
• Aumento da satisfação do cliente
• Em caso de interrupção uma ação corretiva será tomada
• Aumento da disponibilidade dos serviços de TI
107
Problemas Comuns
Como em todo processo, existem algumas questões que precisam ser levadas em
consideração para que se tenha sucesso.
Para o Gerenciamento da Disponibilidade estas questões são:

• Requisitos do negócio em relação à disponibilidade esperada do serviço de TI não
são levantados de forma clara.
• Nenhum contrato oficial é elaborado para especificar a disponibilidade acordada
de cada serviço.
• Falta de comprometimento com o processo.
O negócio e a organização de TI precisam compartilhar um entendimento comum sobre a

disponibilidade e definição do downtime.
Através de relatórios os seguintes itens de eficiência e eficácia do processo podem ser

medidos:
• O tempo total de downtime por serviço
• Tempo de recuperação após um incidente
• A disponibilidade dos serviços
• O aperfeiçoamento da disponibilidade dos serviços de TI
108
O gráfico a seguir mostra as principais medidas de desempenho.
TMPR – Tempo Médio Para Reparar DOWNTIME Sustentabilidade

TMEF – Tempo Médio Entre Falhas UPTIME Disponibilidade (Oficiosidade)
TMIS – Tempo Médio Entre Incidentes do Sistema Média de Confiabilidade (Confiabilidade)
109
11. Gerenciamento da Capacidade
Introdução
O processo de Gerenciamento da Capacidade foi desenhado para assegurar que a

capacidade da infra-estrutura de TI esteja alinhada com as necessidades do negócio.
Enquanto o Gerenciamento de Disponibilidade monitora os serviços e planeja uma
disponibilidade para que eles fiquem “no ar” o maior tempo possível, o Gerenciamento da
Capacidade planeja e monitora a capacidade para que a infra-estrutura consiga atender à
carga de trabalho. Ao desenvolver qualquer serviço novo, primeiro deve ser estimado qual
será a sua demanda, quando usuários vão acessar simultaneamente o serviço e qual será
a estrutura necessária para que o serviço tenha bom desempenho.
A falta de capacidade, como por exemplo falta de memória do servidor de aplicações,

pode afetar o desempenho do serviço, causando lentidão para os usuários. A falta de
capacidade também prejudica o negócio, além de gerar incidentes e aumentar a carga de
trabalho na Central de Serviços.
O propósito principal do Gerenciamento da Capacidade é entender e manter os níveis de

entrega de serviços requisitados a um custo aceitável. A capacidade deve ser projetada
com base nas necessidades do negócio. O que foi estabelecido em ANSs com o cliente
agora servirá como target para o plano de capacidade. O ANS deve conter especificações
sobre a carga de trabalho estimada pelo cliente.
Através da investigação sobre as necessidades de capacidade técnicas e do negócio este

processo irá planejar a capacidade necessária para que a infra-estrutura de TI cumpra os
requisitos do negócio. O plano de capacidade é o documento principal que descreve as
necessidades previstas para o próximo período.
Muita gente faz confusão entre capacidade e disponibilidade, mas são duas coisas muito
distintas. Obviamente a falta de espaço em disco pode travar um sistema, fazer com que
o sistema fique indisponível ao usuário. O Gerenciamento de Disponibilidade não planeja
a capacidade dos servidores, apenas planeja um arranjo ou sugere uma tecnologia para
que os servidores tenham a maior disponibilidade possível.
Objetivo
Os principais objetivos são:
Garantir que a infra-estrutura existente seja operada a um bom nível de

desempenho em relação aos níveis acordados nos ANSs
Entender o modo como a infra-estrutura está sendo usada atualmente e como
será usada no futuro
Construir capacidade para novos serviços de forma que os serviços existentes não
sejam afetados
Desenvolver um plano de capacidade que possibilite à área de TI prover os
serviços com base no que foi acordado nos ANSs
110
Este processo será um ponto focal para todos os assuntos relacionados ao desempenho
e à capacidade da infra-estrutura de TI:
Hardware (desktop, servidores, etc)
Software (SO, in-house, pacotes, gerenciamento, etc)
Equipamentos de rede (LAN, WAN)
Periféricos (impressoras)
Recursos humanos, mas somente quando a falta de recurso pode acarretar um
atraso de tempo de resposta (exemplo: operador de backup). Este processo não
vai fazer uma estimativa de quantos atendentes deve haver na Central de
Serviços, por exemplo.
O processo de Gerenciamento da Capacidade é dividido em três subprocessos listados

abaixo:
Requisitos de nível de Relatórios de

serviço, catálogo de Capacidade
serviço e SLAs
Plano de
Capacidade
Estratégia e planos de
negócio e de TI • Gerenciamento da Capacidade Programação
de Negócios Futura de
Mudanças(PFM)
Orçamentos e planos
financeiros • Gerenciamento da Capacidade Plano
de Serviços Operacional
Quebras de SLAs, Revisado
revisão de servidores,
incidentes e • Gerenciamento da Capacidade
problemas de Recursos Recomendações
sobre custos e
cobrança
Planos operacionais e
planos de
BANCO DE DADOS Limites e
implementação
CAPACIDADE (BDC) alarmes
111
Gerenciamento da Capacidade de Negócio
Este subprocesso tem foco no longo prazo. Ele é responsável por assegurar que os
requisitos futuros do negócio sejam levados em consideração, estejam sendo planejados
e implantados quando necessário e por atender a todas as necessidades de mudanças do
negócio que estão relacionadas com capacidade, trabalhando em sintonia com os
processos de:
Gerenciamento de Desenvolvimento
Gerenciamento de Mudança
Gerenciamento do Nível de Serviço
Compras
Gerenciamento Financeiro de TI
Gerenciamento da Capacidade de Serviço
É responsável por assegurar que o desempenho de todos os Serviços de TI atuais

estejam dentro dos parâmetros definidos nos ANSs.
Analisa os requisitos do negócio para os serviços de TI e irá trabalhar em sintonia com os

processos de:
Gerenciamento da Continuidade dos Serviços de TI
Função Central de Serviços
Gerenciamento de Incidente
Gerenciamento de Problema
Gerenciamento de Mudança
Gerenciamento da Capacidade de Recursos
É responsável pelo gerenciamento de componentes individuais dentro da infra-estrutura.

Este processo tem foco mais técnico.
Exemplos de recursos que serão monitorados:
Processadores
Memória
Discos
Largura de banda
Financeiro
112
Atividades
As atividades do Gerenciamento da Capacidade são executadas como o gráfico abaixo.

Veja que os subprocessos do Gerenciamento da Capacidade possuem muitas atividades
que são similares, principalmente s Gerenciamento da Capacidade do Negócio e
Gerenciamento da Capacidade de Serviços.
Gerenciamento da
Capacidade de Negócio
Atividades
Gerenciamento da Iterativas
Capacidade de Serviço Armazenamento
Monitoração Gerenciamento dos dados do
Análise da Demanda Gerenciamento
Gerenciamento da Ajuste Dimensionam
Capacidade de Recursos
da Capacidade
Implementação ento de
Aplicação Modelagem
Planejamento da Capacidade
BDGC
Relatórios
Cada um dos subprocessos mencionados acima envolve, em um grau maior ou menor, as

seguintes atividades:
• Atividades iterativas
• Armazenamento dos dados do Gerenciamento da Capacidade
• Gerenciamento da demanda
• Dimensionamento de aplicação
• Modelagem
• Plano de Capacidade
• Relatórios
113
Atividades Iterativas
As atividades interativas gerenciam os sistemas de TI no dia-a-dia para garantir que eles

estão operando dentro do padrão esperado.
As seguintes atividades iterativas fazem parte do Gerenciamento da Capacidade:
• Monitoração: verifica se todos os níveis de serviços estão sendo alcançados.

• Análise: os dados coletados através da monitoração precisam ser analisados, e
poderão ser feitas predições para o futuro.
• Ajuste: implementa o resultado dos dois passos anteriores para assegurar o uso
otimizado da infra-estrutura para o presente e o futuro.
• Implementação: implementa a nova capacidade ou mudança de capacidade
através do Gerenciamento de Mudanças.
Armazenamento de dados do Gerenciamento da Capacidade
O Banco de Dados do Gerenciamento da Capacidade (BDGC) é a pedra fundamental do

processo. Ele é usado para formar a base dos relatórios e contém informações técnicas
relevantes para o Gerenciamento da Capacidade. Desta forma a informação contida aqui
fornece para os outros processos os dados necessários para as suas análises.
114
Gerenciamento da Demanda
O Gerenciamento da Demanda é responsável pelo gerenciamento ou carga de trabalho

na infra-estrutura com o objetivo de utilizar melhor a capacidade atual em vez de
aumentá-la. O comportamento do usuário é influenciado para que se use uma carga de
trabalho diferente. Por exemplo: usar determinado recurso da TI em outro horário do dia
para aliviar a falta de capacidade.
Dimensionamento de Aplicação
O Dimensionamento de Aplicação está relacionado à avaliação dos requisitos de

capacidade das aplicações durante seu planejamento e desenvolvimento. Os requisitos
de capacidade de uma nova aplicação precisam ser entendidos, e a infra-estrutura pode
ser ajustada para atender a estes novos requisitos.
Modelagem
Através de simulação ou com auxílio de modelos matemáticos é possível a predição dos

requisitos futuros da capacidade. Os resultados desta atividade podem ser usados como
uma entrada no plano de capacidade.
Plano de Capacidade
O plano de capacidade é desenhado a partir da base dos dados do BDGC, dados

financeiros, dados do negócio, dados técnicos, etc. O plano é orientado para o futuro,
tendo como base um período de pelo menos 12 meses.
Relatórios
Os relatórios conferem o desempenho da capacidade durante um determinado período.

Os relatórios, por exemplo, podem trazer números que sirvam para comparar os índices
dos ANSs.
As principais responsabilidades do Gerente de Capacidade são:
• Desenvolver e manter o plano de capacidade

• Gerenciar o processo
• Certificar que o banco de dados da capacidade está atualizado
Para fazer isto, o gerente precisa estar envolvido na avaliação de todas as mudanças e
estabelecer os efeitos sobre a capacidade e desempenho. Isto deve acontecer tanto
quando as mudanças são propostas como depois de implantadas. Ele deve prestar
atenção em particular nos efeitos cumulativos das mudanças durante um período de
tempo. Os efeitos cumulativos de uma única mudança podem freqüentemente causar
problemas nos tempos de resposta, problemas de armazenamento de arquivos, excesso
de demanda para processamento, etc.
115
Outras funções dentro do Gerenciamento da Capacidade são as funções do
Administrador de Redes e do Gerente de Aplicações e Sistemas. Eles são responsáveis
por traduzir os requisitos do negócio para uma capacidade necessária que consiga
satisfazê-los e aperfeiçoar o desempenho.
Relacionamentos
O Gerenciamento da Capacidade é parte da entrega de serviços e está diretamente

relacionado com os requisitos do negócio. Não é simplesmente preocupado com a
performance dos componentes dos sistemas, individualmente ou coletivamente.
Central de Serviços, Gerenciamento de Incidentes e Problemas
Estes processos irão fornecer ao Gerenciamento da Capacidade informações sobre

incidentes e problemas relacionados à capacidade. O Gerenciamento da Capacidade irá
suportar estes processos resolvendo incidentes e problemas e também fornecendo a eles
informações sobre desempenho.
Gerenciamento de Mudanças e Liberações
As atividades do Gerenciamento da Capacidade irão abrir Requisições de Mudanças

(RDMs) para assegurar que a capacidade apropriada esteja disponível. Este é um
assunto do processo de Gerenciamento de Mudanças. As implantações podem afetar
muitos Itens de Configuração, incluindo hardware, software e documentação. Desta forma
será necessário um Gerenciamento de Liberação eficiente.
Gerenciamento da Disponibilidade
O vínculo entre o Gerenciamento da Capacidade e o Gerenciamento da Disponibilidade é

muito forte. Para que se tenha certo nível de disponibilidade será necessária certa
capacidade relacionada aos ICs. Sem a capacidade necessária, você jamais vai
conseguir a disponibilidade necessária. Além disto, os valores medidos pelo
Gerenciamento da Capacidade são importantes para o Gerenciamento da Disponibilidade
em relação à disponibilidade e confiabilidade.
Tanto o Gerenciamento da Capacidade como o Gerenciamento de Disponibilidade

precisam fornecer ao Gerente de Nível de Serviço informações para que ele faça
negociações de ANSs. O Gerenciamento da Capacidade informa ao Gerenciamento do
Nível de Serviço sobre os níveis que podem ser fornecidos ao cliente.
116
Gerenciamento Financeiro para Serviços de TI
O plano de capacidade fornece uma importante entrada para o Gerenciamento

Financeiro, o qual dá uma visão mais precisa sobre o plano de investimento para a
capacidade.
Gerenciamento da Continuidade dos Serviços de TI (GCSTI)
O Gerenciamento da Capacidade fornece ao GCSTI informações sobre a capacidade

mínima necessária para a recuperação. É importante considerar o impacto (para a
capacidade necessária) de mudanças para os serviços de TI nos procedimentos do
GCSTI.
Benefícios
O Gerenciamento da Capacidade oferece os seguintes benefícios:

• Uma visão geral sobre a capacidade atual existente na infra-estrutura
• A possibilidade de planejar a capacidade antecipadamente
• A possibilidade de estimar o impacto de novas aplicações ou modificações
• Economias de custos
• Melhores serviços em harmonia com os requisitos do negócio
Problemas Comuns
Alguns problemas comuns que podem ser encontrados após o processo já estar
implantado:
• Informações sobre capacidade vinda de fornecedores podem não estar

disponíveis, serem muito genéricas ou estar equivocadas.
• A expectativa sobre o que o Gerenciamento da Capacidade pode ser
superestimada. Se uma aplicação for projetada de maneira errada, a capacidade
não irá resolver o problema.
• Os detalhes da monitoração podem ser muitos detalhados, fazendo com que o
processo seja muito caro.
• A informação pode ser difícil de ser obtida. Não é fácil sempre predizer que a
capacidade futura será necessária antes de desenvolver uma aplicação.
117
Para verificar se o processo está operando dentro dos objetivos deve-se verificar:
• Se a linha da demanda prevista está alinhada com a do realizado

• Se o plano de capacidade está correto
• Se os requisitos estão sendo atendidos
• Se a capacidade é a causa nas falhas dos níveis de serviços, incidentes ou
problemas
• Se os gastos estão sendo reduzidos pelo fato de haver um planejamento melhor
para a capacidade
• Desempenho dos ANSs
118
12. Gerenciamento da Continuidade dos Serviços de TI
Introdução
Ainda existem alguns gerentes que o vêem o Gerenciamento da Continuidade dos

Serviços de TI (GCSTI) como um luxo para o qual não se direciona nenhum recurso.
Entretanto, as estatísticas mostram que os desastres ocorrem freqüentemente. As causas
de tais desastres são eventos como incêndio, queda de raio, enchente, roubo,
vandalismo, falta de energia ou ainda ataques terroristas. Um plano de continuidade para
o negócio poderia salvar muitas empresas que foram afetadas por uma série de
problemas.
Os negócios estão se tornando cada vez mais dependentes da TI. O impacto da

indisponibilidade dos serviços de TI tem aumentado drasticamente. Cada vez que a
disponibilidade ou desempenho de um serviço é reduzida, os usuários têm dificuldade de
continuar a trabalhar normalmente. Esta tendência continuará, fazendo com que a
dependência da TI aumente as exigências dos usuários, gerentes e executivos. É por isto
que é importante estimar o impacto sobre a perda dos serviços de TI e fazer um plano de
continuidade que assegure a continuidade das operações.
Riscos de eventos que podem causar um desastre
Evento Percentual
Roubo 36%
Vírus 20%
Ataque de hackers 16%
Falha de hardware e comunicação 11%
Ambiente 7%
Falhas de software 4%
Incêndio/ Enchentes / Força Maior 3%
Outros 3%
Fonte: Gartner Study 2001
É importante destacar as diferenças que existem entre os processos de Gerenciamento

da Disponibilidade e Gerenciamento da Continuidade dos Serviços de TI. O
Gerenciamento da Disponibilidade vai planejar a disponibilidade dos serviços na infra-
estrutura de produção e também vai analisar as causas de indisponibilidade e por que
elas acontecem, e junto com o Gerenciamento de Problema e de Mudanças vai tratar
estas causas. Já o Gerenciamento da Continuidade dos Serviços de TI vai fazer um plano
para recuperação dos serviços caso aconteça um desastre.
119
O processo de Gerenciamento da Continuidade dos Serviços de TI tem por escopo dar
suporte à continuidade dos serviços que suportam os processos de negócio da empresa,
garantindo desta forma que tais serviços possam ser recuperados no menor intervalo de
tempo possível e de acordo com as prioridades do negócio após a ocorrência de um
desastre. O processo de Gerenciamento de Continuidade dos Serviços de TI é um
processo integrado com o Gerenciamento da Continuidade do Negócio como um todo. A
continuidade dos serviços de TI não é de responsabilidade apenas da TI, mas sim da
gestão da empresa como um todo. Conselho, diretores e gerentes devem saber da
importância que o seu negócio tem de operar mesmo que passe por crises ou desastres.
O GCSTI é um processo que exige muito a integração da TI com as unidades de negócio.

A TI deverá planejar o seu plano de continuidade para os serviços conforme as análises
das unidades de negócio da empresa. Ou seja, quem define o que é prioritário não é a TI,
mas sim o negócio.
Gerenciamento da Continuidade do
Negócio (GCN)
Gerenciamento da
Continuidade do Serviços
de TI (GCSTI)
O GCSTI faz parte do GCN. A ITIL não trata do GCN. Existem outros livros mais focados
no Gerenciamento da Continuidade do Negócio.
120
Objetivo
O objetivo principal do processo de GCSTI é dar suporte ao Gerenciamento da

Continuidade de Negócio (GCN), assegurando que os requisitos técnicos da TI e
determinados serviços possam ser recuperados dentro de prazos requeridos e acordados.
Outros objetivos:
Assegurar a sobrevivência do negócio reduzindo o impacto do desastre ou falha

grave
Reduzir a vulnerabilidade e o risco para o negócio através de uma análise de
riscos eficaz e de um gerenciamento de riscos a um custo justificável
Transferir o risco para um terceiro
Produzir planos de recuperação de TI que serão integrados e darão suporte
completo ao Gerenciamento da Continuidade de Negócio (GCN)
Prevenir perda de segurança para cliente e usuário
Este processo vai cobrir serviços de TI que dão suporte a processos de negócios
críticos. Isto inclui:
Sistemas e aplicativos
Rede
Telecomunicações
Suporte técnico
O processo pode ser dividido em 4 estágios, os quais serão descritos neste capítulo em
detalhes:
• Iniciação
• Requisitos & Estratégia
• Implementação
• Gerenciamento Operacional
121
Atividades
Cada um dos estágios tem suas próprias atividades, as quais serão descritas em mais
detalhes durante este capítulo.
Iniciação
• Inicia o GCN
O processo de iniciação contempla a organização como um todo. As políticas ao redor do

GCN e do GCSTI são identificadas, o escopo do processo e os termos de referências são
determinados, recursos são alocados e um plano de projeto é estabelecido.
Requisitos & Estratégia
• Análise de Impacto no Negócio (AIN)
O impacto de um desastre no negócio será investigado. Questões que podem ser feitas:
O negócio poderá continuar operando em caso de um desastre? Por quanto tempo ele
poderá se manter? Ele se baseia nos serviços de TI para continuar a operar?
122
O quanto a empresa agüenta perder com o resultado de um desastre ou outra interrupção
de serviço e a velocidade do escalonamento destas perdas será avaliada através de:
o Identificação dos processos críticos do negócio

o Identificação do estrago potencial ou perda que pode ser causada para a
organização como resultado da interrupção do processo crítico do negócio
• Avaliação de Riscos
Esta atividade analisa a probabilidade de ocorrer um desastre ou outra interrupção séria

no serviço. Esta é uma avaliação do nível de perigo e extensão da vulnerabilidade da
organização. A Avaliação de Riscos consiste de duas partes:
o A Análise de Riscos é focada em identificar os riscos analisando as
vulnerabilidades e as ameaças para todos os ativos críticos.
o O Gerenciamento de Riscos se preocupa em identificar os contra-recursos
para manter os riscos sob controle. Estes ainda podem ser ações para
reduzir o impacto ou a probabilidade do risco, ou desenvolver planos
(recovery, ou recuperação) que detalhem como agir quando o risco
acontecer.
Gerenciamento da
Disponibilidade
Ameaças Importância da TI para Ameaças
externas o cliente internas
Pegue alguns riscos:

Pegue os riscos: Riscos - risco mínimo ao negócio
- irá diminuir as vendas? - planejamento da
- trará perda de clientes? continuidade do negócio
- custo? Opções de - custo?
- medidas -
Decisão do cliente
Custo/Benefício
Testa Plano ANS

Avalia
Ajusta
123
• Estratégia de Continuidade do Negócio
Uma estratégia apropriada precisa ser desenvolvida, contendo um equilíbrio ideal da

redução dos riscos e opções de recuperação. O equilíbrio irá depender muito da natureza
do negócio e da dependência dos serviços de TI. Exemplo: um corretor de ações irá focar
na redução de riscos, já uma padaria local provavelmente irá arcar com o tempo envolvido
na recuperação de uma falha no sistema.
Em caso de um plano de recuperação, as decisões devem ser feitas sobre como

recuperar. Estas opções são:
Não fazer nada

Esta escolha pode ser feita se a análise de riscos sugerir que a falha do serviço em TI não
afeta o negócio de forma irreparável. Isto pode ser razoável. De qualquer forma confirme por
escrito que em caso de uma calamidade nenhum plano de contingência estará disponível.
Contorno manual (Paper-based)

Se a infra-estrutura não estiver disponível por muito tempo, uma opção é utilizar
procedimentos administrativos. Um destes procedimentos poderá ser voltar a utilizar
formulários em papel.
Disposições recíprocas
Em caso de um desastre, organizações disponibilizam suas infra-estruturas uma para a outra.
Ou seja, é feito um acordo entre empresas que possuem infra-estruturas semelhantes, sendo
que uma emprestará sua infra-estrutura para a outra. É possível também que empresas em
conjunto desenvolvam uma infra-estrutura de contingência e rateiem os custos entre si. A
desvantagem desta opção é a falta de confidencialidade dos dados.
Recuperação gradual (cold stand-by > 72 horas)

Nesta estratégia a própria organização tem um espaço disponível com uma infra-estrutura que
contenha eletricidade, conexões telefônicas e ar condicionado para onde as aplicações
possam ser migradas e os níveis de serviços restaurados. Este espaço pode ser alugado ou
fazer parte da estrutura da empresa.
Recuperação intermediária (warm stand-by = 24 a 72 horas)

Neste cenário existe uma local para evacuação disponível, alugado ou comprado. Exemplos
são o centro de computação para evacuação ou o IBM truck. A última opção é apenas possível
para sistemas de porte médio.
Recuperação imediata (hot standby = 0 a 24 horas)

Esta é normalmente uma extensão das opções de recuperação intermediária através de
fornecedores. Esta cobre normalmente serviços que são extremamente críticos que podem
afetar a sobrevivência da empresa ou podem pelo menos causar um impacto que impeça a
empresa de gerar receitas. É comum neste caso ter um site de redundância funcionando em
local paralelo: se um sistema cair, o link é redirecionado para o site de cópia.
124
Implementação
• Organização e plano de implementação
Vários planos precisam ser criados para implantar o processo de GCSTI. Estes planos se
referem a questões como: procedimentos de emergência, avaliação de danos, o que fazer
com os dados, planos de recuperação, etc.
• Arranjos stand-by e medidas de redução de riscos
As medidas de redução de riscos precisam ser implantadas. Na maioria dos casos estas
são feitas com a ajuda do processo de Gerenciamento da Disponibilidade. Também
procedimentos de stand-by precisam existir. Por exemplo, criar um acordo com um
terceiro para fornecer equipamentos em caso de um desastre.
• Desenvolver planos e procedimentos de GCSTI
O plano de recuperação precisa ser definido. Este plano deve conter os seguintes itens:
o Quando ele será atualizado
o Lista de responsáveis por definir qual ação deve ir para determinado grupo
o Iniciação da recuperação
o Grupo de especialistas para cobrir as ações e responsabilidade de setores
individualmente. Estes setores são: administração, pessoal da infra-
estrutura de TI, segurança, sites de recuperação e restauração.
• Executar os testes iniciais
O teste é a parte crítica de todo o processo de GCSTI, e é a única forma de garantir que a
estratégia escolhida, os arranjos stand-by, logísticas, planos de recuperação de negócio e
procedimentos irão funcionar na prática.
Gerenciamento Operacional
• Educação, treinamento e conscientização
Estas são ações essenciais que devem ser tomadas para que o processo de GCSTI
tenha sucesso. Isto assegura que toda a equipe esteja ciente das implicações da
continuidade de negócio e continuidade dos serviços de TI, e as considere como parte da
sua rotina de trabalho normal.
• Revisão e auditoria
É necessário regularmente revisar e auditar os planos, para certificar que eles estão ainda
atualizados.
• Testes
Através de testes regulares não apenas a eficácia do plano pode ser testada, mas
também as pessoas irão saber o que irá acontecer, onde fica o plano e o que ele contém.
• Gerenciamento de Mudanças
125
Em virtude das mudanças do dia-a-dia na área de TI, é necessário que os planos de
GCSTI estejam atualizados. O GCSTI precisa ser incluído como parte do processo de
Gerenciamento de Mudanças para assegurar que qualquer mudança na infra-estrutura de
TI seja refletida nos arranjos de contingência fornecidos pela TI ou terceiros.
• Garantia
A qualidade do processo é verificada para assegurar que os requisitos do negócio

possam ser alcançados e que os processos de Gerenciamento Operacional estejam
funcionando de forma satisfatória.
A distinção pode ser feita nas funções e responsabilidades dentro e fora dos períodos de
crise. Diferentes níveis dentro deste processo podem ser definidos, começando pelo
comitê, seguido pelo gerente sênior, gerente, líderes de equipe e seus membros. É vital
documentar as responsabilidades e funções de cada um.
Operação normal Em uma crise

Presidente (Conselho)
Gerenciamento, decisões
Inicia a continuidade dos serviços de TI, cria uma
corporativas, relacionamento
política, aloca responsabilidades, dirige e autoriza.
externo.
Diretor
Gerencia a continuidade dos serviços de TI, aceita as Coordenação, direção e
entregas, comunica e mantém a campanha de arbitração, autorização dos
conscientização, faz a integração na organização. recursos.
Gerente
Faz a análise da continuidade dos serviços de TI, define Invocação, liderança,
as entregas e contratos para os serviços, gerencia os gerenciamento do site, reportação
testes. das ações.
Supervisor e Equipe
Desenvolve entregas, negocia os serviços, executa os Execução das tarefas, faz parte
testes, desenvolve e opera processos e procedimentos. da equipe de apoio.
126
Relacionamentos
O GCSTI tem um relacionamento muito próximo com todos os outros processos da ITIL e
o negócio de forma geral. Estes relacionamentos com alguns dos processos são descritos
abaixo em mais detalhes.
O Gerenciamento do Nível de Serviço fornece informações ao processo de GCSTI sobre

os níveis de serviços requisitados.
Gerenciamento da Disponibilidade
O Gerenciamento da Disponibilidade tem uma função mais de suporte e ajuda ao

processo de GCSTI, para prevenir e reduzir os riscos de desastres, entregando e
implantando medidas de redução de riscos.
O Gerenciamento da Configuração fornece informações sobre os Itens de Configuração

que são necessários para restaurar os serviços de TI após um desastre.
Gerenciamento de Mudanças
O Gerenciamento de Mudanças precisa certificar que o GCSTI esteja ciente do impacto

das mudanças nos planos de continuidade e recuperação, permitindo que os planos
sejam atualizados quando necessário.
Gerenciamento da Capacidade
O Gerenciamento da Capacidade certifica que a infra-estrutura pode suportar os

requisitos do negócio.
Central de Serviços e Gerenciamento de Incidentes
Em conjunto com o Gerenciamento de Incidentes a Central de Serviços fornece dados

históricos (estatísticas) ao processo de GCSTI.
Benefícios
O GCSTI suporta o processo do GCN e a infra-estrutura de TI necessária para fazer com

o que o negócio continue a operar após uma interrupção de serviço. Os principais
benefícios de se implantar o processo de GCSTI são:
• Gerenciamento de riscos e conseqüente redução de impacto das falhas

• Redução dos prêmios pagos aos contratos de seguro
• Cumprimento de requisitos obrigatórios ou regulamentares (acordos, leis)
127
• Melhor relacionamento entre o negócio e a TI, fazendo com que a TI se torne mais
focada no negócio e mais ciente sobre os impactos e prioridades
• Aumento da confiança do cliente, possível vantagem competitiva e aumento da
credibilidade da organização
No caso de um desastre o processo irá ter os seguintes benefícios:
• Redução de interrupções no negócio, com a possibilidade de recuperar os

serviços de forma eficiente na prioridade que o negócio exigir
• O tempo de recuperação menor
• Infra-estrutura de TI mais estável e alta disponibilidade dos serviços de TI
Problemas Comuns
Alguns problemas podem ser encontrados ao implantar o processo de GCSTI:
• Insuficiência de recursos para implantar o processo

• O GCSTI não ser baseado no GCN
• Falta de comprometimento do Gerente de TI e gerentes de negócio
• Análise superficial dos componentes críticos causando má interpretação nos
impactos do negócio
• A recuperação não funcionar como deveria por falta de testes
• Faltar conscientização de suporte dos usuários
• Equipe de TI fazendo com que o processo falhe quando ocorrer o desastre

Durante a operação normal pode se reportar:
• Os resultados dos testes feitos no plano

• Custo do processo
Durante/após um desastre pode se reportar:
• Pontos fracos no plano

• Tempo que se levou para recuperar em relação ao tempo estimado
• Perdas devidas ao desastre
128
13. Gerenciamento Financeiro para Serviços de TI
Introdução
Como nos últimos anos os negócios se tornaram mais dependentes da TI para realizar
suas operações, conseqüentemente o número de usuários aumentou – assim com
também o volume de gastos com TI (orçamento de TI).
Desta forma os clientes dos provedores de TI e seus diretores perceberam que está se
gastando muito dinheiro em TI. Ainda leva-se em conta que estes investimentos precisam
trazer um aumento da qualidade dos serviços prestados e ter um custo-benefício melhor.
De outro lado, o provedor de TI acha que está fazendo um bom trabalho, mas acha muito
difícil explicar na linguagem do negócio os custos reais e benefícios dos serviços de TI
fornecidos.
Organizações (clientes e diretores) são relutantes em gastar dinheiro para melhorar os

serviços de TI se eles não tiverem uma idéia clara dos custos envolvidos e os benefícios
que podem ter para o negócio. O Gerenciamento Financeiro para Serviços de TI pode
tornar os custos mais claros, criando um método de cobrança e dando aos clientes uma
idéia sobre a relação entre qualidade e preço. Em outras palavras, o Gerenciamento
Financeiro promove a execução dos serviços de TI como se fosse uma operação de
negócio.
Objetivo
O objetivo do processo de Gerenciamento Financeiro para os Serviços de TI em um

departamento de TI interno deve ser o seguinte:
• Fornecer um custo efetivo para os gastos aplicados nos ativos de TI e nos

recursos usados para fornecer os serviços de TI.
Em um ambiente comercial, pode haver premissas que irão refletir no lucro e nas ações
de marketing da organização. Mas para qualquer serviço de TI os objetivos deverão
incluir:
• Contabilização completa dos gastos com serviços de TI e atribuição destes custos

aos serviços entregue aos clientes.
• Assistência às decisões da gerência sobre os investimentos de TI, fornecendo
planos de negócios para mudanças nos serviços de TI.
O foco principal deste processo é o entendimento dos custos envolvidos na entrega de

serviços de TI (atribuindo os custos para cada serviço e cliente específico). Esta
consciência dos custos melhora a qualidade de todas as decisões tomadas em relação
aos gastos de TI. A cobrança destes custos do cliente é opcional.
129
O Gerenciamento Financeiro consiste de três subprocessos:
Orçamento Contabilidade de TI Cobrança
Elaboração do Orçamento (obrigatório)
A elaboração do orçamento é o processo de predizer e controlar os gastos em dinheiro

dentro da organização, e consiste de um ciclo de negociação periódico para criar
orçamentos (normalmente anuais) e monitoração diária dos gastos.
A elaboração do orçamento assegura que os recursos em dinheiro necessários estarão

disponíveis para o fornecimento de serviços de TI, e que durante o período contemplado
pelo orçamento eles não serão extrapolados. Todas as organizações têm uma rodada de
negociações periódica (normalmente anual) entre os departamentos de negócio e a
organização de TI, cobrindo os planos de despesas e programas de investimentos
acordados.
Contabilidade de TI (obrigatório)
A contabilidade de TI é um conjunto de processos que possibilita à organização de TI

acompanhar de que forma o dinheiro é gasto (particularmente alocando os custos por
cliente, serviço e atividade).
Cobrança (opcional)
A cobrança é um conjunto de processos necessários para emitir contas aos clientes pelos
serviços fornecidos a eles. É necessário ter o apoio da contabilidade de TI para que isto
possa ser feito de forma simples, clara e correta.
Dentro das organizações existem dois tipos de ciclos associados com a elaboração de
orçamento, contabilidade de TI e cobrança:
• Um ciclo de planejamento (anual) onde as projeções de custos e previsão de

carga de trabalho formam a base para o cálculo de custos e formação de preços
• Um ciclo operacional (mensal ou trimestral) onde os custos são monitorados e
comparados com os orçamentos, faturas emitidas e as receitas geradas
Todos estes processos serão discutidos em mais detalhes durante este capítulo.
130
Ciclo do processo
Atividades
Cada um dos três subprocessos do Gerenciamento Financeiro consiste de um conjunto

de atividades, as quais serão discutidas neste capítulo.
Elaboração do Orçamento
• Determinar o método de orçamento:
o Orçamento incremental: os números dos últimos anos são usados como

base para o orçamento do próximo ano.
o Orçamento base-zero: inicia o orçamento do zero. O propósito e as
necessidades de cada despesa precisam ser determinados.
• Determinar o período do orçamento:
Na maioria dos casos este período será de um ano financeiro (fiscal), o qual pode
ser subdividido em períodos menores.
• Elaborar o orçamento:
Determine todas as categorias disponíveis e estime os custos para o orçamento do

próximo período. Leve em consideração que a demanda pode aumentar durante o
período. Alguns custos precisam ser estimados.
Contabilidade de TI
A contabilidade TI se preocupa em fornecer informações sobre onde está sendo gasto o
dinheiro. Todo Item de Configuração necessário para entregar um serviço de TI para o
131
cliente gera um custo. Estes custos somam-se aos custos necessários para a entrega dos
serviços de TI. Para que possamos entender os custos é necessário discutir sobre os
custos de maneira geral.
Classificação dos elementos de custos:
Custos capitais Custos operacionais

Referem-se à compra dos ativos fixos. São aqueles oriundos das operações do dia-a-dia,
Exemplo: prédio, licenças, tais como custo de pessoal, manutenção de
computadores, etc. hardware e eletricidade.
Custos diretos Custos indiretos (overheads)
Aqueles que são aplicados com São divididos por todo o número de clientes.
clareza a um único cliente, tal como Exemplo: suporte técnico ou de rede que têm que
manutenção de um sistema específico. ser rateado para todos.
Custos fixos Custos variáveis
Custos que não variam pelo uso. Um São aqueles que variam de acordo com algum fator,
exemplo pode ser um contrato de tais como uso ou tempo.
manutenção de um servidor ou ERP.
Para facilitar o controle orçamentário de TI identificando onde o dinheiro está sendo gasto,
podemos ter a uma categorização dos tipos de custos. Dentro de cada tipo podemos ter
vários elementos de custo. Vejamos a tabela a seguir:
Tipos de custos Elementos de custos
Hardware Mainframes, storages, periféricos, redes, PCs, portáteis, servidores, etc.
Sistemas operacionais, aplicações, banco de dados, ferramentas de

Software
controle e gestão
Salários, benefícios, custos de recolocação, despesas, consultoria, hora-

Pessoas
extra
Acomodações Escritórios, armazéns, áreas de segurança, serviços públicos.
Serviço de segurança, serviços de recuperação (disaster recovery),

Serviço Externo
serviços terceirizados
Custos internos oriundos de outros centros de custos da organização

Transferência
(exemplos: serviço administrativo, segurança, recepção)
132
Cobrança
Em um centro de lucro (quando a TI é a área-fim do negócio) o objetivo é recuperar os

custos decorridos através de cobrança. Para um departamento de TI interno o foco
poderia ser recuperar os custos de uma forma simples e clara. A cobrança pode ser
usada também para influenciar o comportamento do cliente e seus usuários, influenciando
desta forma a demanda e uso dos serviços de TI que são fornecidos.
Antes da cobrança devem ser tomadas algumas decisões de como será a política de
cobrança, custos unitários e preço.
Dentro da política de cobrança, temos:
Comunicação da informação: apenas os custos atuais serão calculados, reportados

e cobrados do cliente.
Flexibilidade de preço: estabelecer e cobrar os preços a cada ano. Este método dá a

opção de influenciar o uso excessivo.
Cobrança nocional: todos os custos são emitidos, mas o cliente não precisa pagar
em dinheiro real. Este método é usado para fazer experiências e eliminar erros.
Para poder realizar as cobranças, os custos para as unidades de custos dos clientes de TI
(também conhecidos como centro de custos) ou itens cobráveis precisam ser criados. Isto
deve estar claro para que o cliente também possa entender o funcionamento da cobrança.
Um exemplo pode ser um PC que o cliente usa, ou a quantidade de impressões
requisitadas por ele.
Alguns dos métodos para formação do preço podem ser utilizados para realizar a
cobrança:
• Preço por custo: para cobrir despesas com P&D e despesas adicionais
• Preço de mercado: preço que é cobrado pelo serviço no mercado
• Taxas existentes: taxas que são usadas também em organizações similares ou
outros departamentos internos
• Preço fixo: o preço é negociado com o cliente antecipadamente.
133
O Gerente de Finanças de TI pode ser uma pessoa da organização de TI ou do

departamento financeiro. Uma alternativa seria que as tarefas associadas a esta função
fossem compartilhadas entre ambos. As principais responsabilidades são:
• Fiscalizar a implantação do processo de Gerenciamento Financeiro para os

serviços de TI e seus subprocessos (elaboração de orçamentos, contabilidade de
TI e cobrança)
• Apoiar a elaboração dos orçamentos e planos de contabilidade
• Trabalhar, em um nível apropriado, com os diretores da empresa e com o
departamento financeiro para desenvolver as políticas de orçamento, contabilidade
de TI e cobrança
Relacionamentos
O Gerenciamento Financeiro para os Serviços de TI fornece informações importantes

para o Gerenciamento do Nível de Serviço sobre as estratégias de custos, preços e
cobranças introduzidas.
Este processo de Gerenciamento Financeiro analisa se nível de serviço entregue possui

um custo real para o negócio.
O Gerenciamento Financeiro para os Serviços de TI pode desenvolver estratégias de

preço junto com o Gerenciamento de Mudanças e o Gerenciamento da Disponibilidade.
Estas estratégias podem realizar uma distribuição otimizada da carga de trabalho dentro
de uma organização, o que irá resultar no uso otimizado dos recursos. Ele ainda pode
usar os ativos e informações de custos a partir do Gerenciamento da Configuração para
analisar diferentes cenários de equipamentos (custos diferentes para diferentes
configurações).
Benefícios
Os benefícios de implantar o processo de Gerenciamento Financeiro para os serviços de

TI incluem:
• Aumento da segurança em elaborar e gerenciar orçamentos

• Uso mais eficiente dos recursos de TI na organização
• Aumento da satisfação dos clientes a partir do momento em que eles souberem
pelo que estão pagando
• Decisões de investimentos feitas através de informações mais precisas
• Aumento do profissionalismo da equipe dentro da organização de TI
134
Os benefícios podem ser divididos por subprocesso:
Para a elaboração de orçamento:
• Possibilita estimar os custos totais necessários para manter a organização de TI

• Redução do risco de se gastar mais dinheiro do que o disponível
• Possibilita comparar os custos previstos x o realizado
• Garantia de que os recursos financeiros estarão disponíveis para manter a
organização de TI dentro dos níveis de serviço acordados
Para a contabilidade de TI:
• Disponibilidade de informação gerencial sobre os custos do fornecimento de

serviços de TI
• Gerentes de TI e de negócio podem tomar decisões melhores, as quais
asseguram que os serviços de TI estão sendo executados dentro de um custo
efetivo
• Possibilidade de contabilizar de maneira precisa todas as despesas feitas pela
organização de TI
• Demonstrar o consumo dos serviços em termos financeiros
• Maximizar o valor do dinheiro gasto no fornecimento dos serviços de TI
• Possibilidade de determinar os custos de NÃO fazer um investimento específico
• Formar um fundamento para implantar uma forma de cobrança
Para a cobrança:
• Possibilita recuperar os cursos da TI de uma maneira mais bem elaborada.

• Influencia a demanda dos serviços de TI fornecidos e o comportamento do cliente
135
Problemas Comuns
Para que o processo funcione de forma eficaz e eficiente as seguintes questões devem
ser levadas em conta para evitar problemas nesta área:
• Os modelos que são usados para a contabilidade de TI podem ser muito

detalhados, criando um sobrecarga de trabalho administrativo
• Não há comprometimento dos gerentes de TI e de negócio
• O Gerenciamento Financeiro para os serviços de TI não estão alinhados com os
procedimentos financeiros da organização
• Políticas de cobrança não são comunicadas corretamente aos clientes, causando
um comportamento indesejável, como ações dos usuários e clientes para tentar
evitar cobranças emitidas
Os indicadores de performance que podem ser usados neste processo:
• Análise de custo/benefício dos serviços fornecidos de forma mais precisa

• Os clientes consideram os métodos de cobranças adequados?
• A organização de TI consegue atingir os objetivos financeiros?
• O uso dos serviços pelos clientes sofre modificações?
136
Apêndice: Gerenciamento de Qualidade
O Gerenciamento de Qualidade para os serviços de TI é forma sistemática de assegurar
que todas as atividades para desenhar, desenvolver e implantar os serviços de TI que
satisfaçam os requisitos da organização e usuários sejam planejadas e comprometidas
com a otimização do custo.
A forma pela qual a organização planeja gerenciar suas operações para entregar serviços
com qualidade é especificada pelo sistema de Gerenciamento de Qualidade. O sistema
de Gerenciamento de Qualidade define a estrutura organizacional, responsabilidades,
políticas, procedimentos, processo, padrões e recursos necessários para entregar
serviços de TI com qualidade. Entretanto, um sistema de Gerenciamento de Qualidade irá
apenas funcionar como pretendido se a equipe e a parte gerencial estiverem
comprometidas com seus objetivos.
Aperfeiçoamento de Qualidade contínua: O Ciclo de Deming
“Nós aprendemos a viver em um mundo de erros e produtos defeituosos que ainda

são necessários para a vida. É hora de adotar uma nova filosofia.”
(W. Edwards Deming, 1900-1993)
W. Edwards Deming ficou conhecido pela sua filosofia de gestão que estabelece
qualidade, produtividade e posição competitiva. Como parte desta filosofia, ele formulou
14 pontos de atenção para os gerentes. Alguns destes pontos são mais apropriados para
o Gerenciamento de Serviços do que outros, por exemplo:
Resumo dos pontos relevantes para o Gerenciamento de Serviços:
• Quebra de barreiras entre departamentos (melhorar comunicações e

gerenciamento)
• Os gerentes devem aprender suas responsabilidades e tomar a liderança
(aperfeiçoamento do processo requer comprometimento da alta direção,
e bons líderes para motivar as pessoas a se aprimorarem)
• Melhorar constantemente (um tema central para os Gerentes de Serviço
é o aperfeiçoamento contínuo, que também é um tema para o
Gerenciamento da Qualidade)
• Instituir um programa de educação e auto-aperfeiçoamento (aprender e
melhorar as habilidades tem sido o foco do Gerenciamento de Serviços
por muitos anos)
• Treinamento durante o trabalho (vinculado com o aperfeiçoamento
contínuo)
• Transformação é dever de todos (ênfase no time de trabalho e
entendimento)
137
Para a melhoria de qualidade, Deming propôs o Ciclo (ou Círcuilo) de Deming. Os quatro
estágios-chave são: planejar, fazer, verificar e agir (em inglês: plan, do, check, act –
PDCA).
Após cada fase consolidada, é usado um círculo que irá girando sobre a rampa conforme
ilustrado na figura abaixo. A consolidação de cada fase possibilita à organização tomar as
lições aprendidas e assegurar que o aperfeiçoamento continuará embutido no processo.
Freqüentemente, uma série de aperfeiçoamentos tem sido realizada nos processos que
irão requerer documentação (tanto para permitir que o processo se torne repetível como
para facilitar o alcance de alguma forma de um padrão de qualidade).
Melhoria contínua
passo-a-passo Alinhamento da
TI
com o negócio
Nível de maturidade
Plan (Planejar)
Do (Executar)
A P Check (Auditar)
Act (Agir)
C D Aperfeiçoamento
contínudo de
qualidade
Consolidação do
nível alçado
Escala de tempo
Figura: Ciclo de Deming
Padrões de Qualidade
International Standards Organisation – ISO 9000
As ISO 9000 é um conjunto de padrões internacionais para garantir a qualidade, e é

composta de cinco padrões universais para um sistema de Garantia de Qualidade que é
aceito no mundo todo. A partir da década de 1990 os países começaram a adotar a ISO
9000 como pedra fundamental para seus padrões nacionais. Quando você compra um
produto ou serviço de uma empresa que possui o selo de qualidade ISO 9000, você se
assegura que a qualidade do que você irá receber é o que você espera.
138
Um dos padrões mais utilizados é o ISO 9001. Ele é aplicado às indústrias envolvidas no
projeto, desenvolvimento, produção, instalação e assistência técnica de produtos ou
serviços. Os padrões se aplicam uniformemente a qualquer empresa de qualquer
tamanho.
Um guia mais detalhado sobre isto pode ser obtido a partir do livro Quality Management
for IT Services – ISBN 0-11-330555-9. Este livro tem como foco primário adequar os
serviços de TI com a ISO 9001.
Sistemas de Qualidade Total: EFQM
“... a batalha pela qualidade é um dos pré-requisitos para o sucesso de suas

empresas e para o nosso sucesso coletivo.”
(Jacques Delors)
O EFQM – Modelo de excelência
O EFQM (European Foundation for Quality Management) foi fundado em 1988 por
presidentes das 14 maiores empresas e foi endossado pela Comissão Européia. O grupo
de associados atual excede mais de 600 organizações das mais respeitadas, desde
multinacionais a empresas nacionais importantes até renomados institutos de pesquisas
de universidades européias.
O EFQM fornece um modelo para aqueles que desejam alcançar a excelência nos
negócios através de um programa de aperfeiçoamento contínuo.
Missão do EFQM
Estimular e assistir organizações por toda a Europa a participar em atividades de

aperfeiçoamento que levam à excelência em satisfação do cliente, satisfação dos
colaboradores, impacto dos resultados na sociedade e nos negócios; e dar suporte
aos diretores das organizações européias para acelerar o processo de fazer o
Gerenciamento de Qualidade Total um fator decisivo para obter uma vantagem
global competitiva.
Descrição do modelo de excelência do EFQM

O modelo de excelência do EFQM consiste de 9 critérios e 32 sub-critérios, como
ilustrado na figura abaixo.
139
Neste modelo existe um foco explícito no valor para os usuários do ciclo PDCA (Plan-Do-
Check-Act) em suas operações de negócio.
Auto-avaliação e maturidade: a escala de maturidade do EFQM
Umas das ferramentas fornecidas pelo EFQM é o questionário de auto-avaliação. Este

processo de auto-avaliação permite à organização discernir claramente seus pontos fortes
e também quaisquer áreas onde melhorias podem ser feitas. O processo do questionário
termina quando ações de melhorias são planejadas, as quais então são monitoradas por
progresso.
Nesta avaliação, o progresso pode ser verificado através de 5 pontos da escala de

maturidade:
1. Orientação ao produto
2. Orientação ao processo (o estágio de maturidade focado originalmente pela ITIL)
3. Orientação ao sistema (o target da maturidade para organizações aderentes à ITIL
no novo milênio)
4. Orientação à cadeia (de relacionamentos)
5. Qualidade total
140
Bibliografia
BON, JAN VON. Foundations of IT Service Management based on ITIL.

Lunteren – Holanda: Van Haren Publishing, 2005.
Service Delivery. Londres – Inglaterra: The Stationary Office, 2000.
Service Support. Londres – Inglaterra: The Stationary Office, 2000.
141

Lingua

Benvenuto in Scribd!

Tiexames Apostila Itil

Caricato da

Informazioni sul documento

Descrizione:

Data di caricamento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

Tiexames Apostila Itil

Caricato da

Descrizione:

Copyright:

Formati disponibili

Titoli correlati

APOSTILA FUNDAMENTOS EM

Este é um material complementar do curso e-learning da TIEXAMES.

Atenção: leia os comentários de introdução na próxima página antes de

ITIL® é uma marca registrada do OGC

Versão: 2.0 (última atualização em 15/11/2008)

IPD - Indicadores Principais de Desempenho ............................................................ 100

Com o aumento do peso de importância dentro da organização, a TI passou a ter vários

Alinhamento dos serviços de TI com as necessidades atuais e futuras do

Não é correto afirmar que um determinado processo na organização é “compatível com

Os processos e organizações podem ser avaliados se estão compatíveis com as normas

A ITIL foi desenvolvida inicialmente pela CCTA (Central Computing and

As boas práticas da ITIL têm como objetivos:

Organizações Envolvidas com a ITIL

A figura abaixo apresenta as organizações que estão envolvidas na manutenção e

itSMF Parceiro estratégico para promover as práticas

Institutos de Treinamentos – Organizações

OGC (Antiga CCTA)

A biblioteca consiste em um número claro de “Código de Práticas” para promover e

O itSMF promove a troca de informações e experiências que permitem às organizações

Os associados contribuem também com o desenvolvimento do assunto. A associação

O capítulo brasileiro do itSMF, como é chamada uma representação em um país, está

• Certificado Foundation em Gerenciamento de Serviços de TI

Na ITIL V3 o esquema de certificação foi atualizado e existem mais opções de

Certificações para os profissionais de TI na ITIL V2

Para obter a certificação Foundation não é necessário participar de

Na certificação Practitioner o candidato deve realizar um curso

A certificação Manager é voltada para os gestores de TI que terão

Para mais informações sobre os exames de certificação consulte o

Estrutura de Livros da ITIL V2

ITIL (IT Infrastructure Library)

A ITIL define os objetivos e atividades, as entradas e saídas de cada um dos processos

A ITIL é baseada na necessidade de fornecer serviços de alta qualidade, com ênfase no

O quebra-cabeça da ITIL V2 mostra os principais elementos localizados nos seus livros.

Os 7 livros principais da ITIL V2 são:

PLANEJAMENTO PARA IMPLEMENTAR O A

Fonte: livro Service Support do OGC

Suporte a Serviços: descreve os processos associados ao suporte do dia-a-dia e

Entrega de Serviços: cobre os processos necessários para o planejamento e entrega de

ICT - Gerenciamento da Infra-estrutura: cobre todos os aspectos do Gerenciamento da

Planejamento para Implementação do Gerenciamento de Serviços: examina questões

Gerenciamento de Aplicações: descreve como gerenciar as aplicações a partir das

Perspectiva de Negócio: fornece um conselho e guia para ajudar o pessoal de TI a

Gerenciamento da Segurança: detalha o processo de planejamento e gerenciamento

O livro Suporte a Serviços descreve como um cliente

Este livro cobre os seguintes assuntos:

A figura abaixo apresenta o relacionamento entre os processos do livro Suporte a

O livro Entrega de Serviços descreve os serviços que o

Este livro cobre os seguintes assuntos:

A figura abaixo apresenta o relacionamento entre os processos do livro Entrega de

A framework da ITIL V2 é um conjunto de livros com alguns problemas de consistência –

Ciclo de vida do serviço da ITIL V3

Estratégia de Desenho de Transição de Operação de Melhoria de

A próxima fase é a Transição de Serviço. Então se na fase anterior empacotam-se todas

A outra fase é a Operação de Serviço: é só manter o serviço, é o dia-a-dia. Basicamente

Como visto no capítulo Introdução ao Cenário, a área de TI tem ganhado grande

Entre os principais objetivos da adoção da melhores práticas da ITIL podemos destacar

Alinhar os serviços de TI com as necessidades atuais e futuras do negócio e seus