Apostila do curso e-learning:

Autor:
Flávio R. Pinheiro

ITIL Expert

1
Apresentação

Este material foi desenvolvido para profissionais de TI que desejam ter o primeiro
contato com a biblioteca da ITIL edição 2011 (última edição). O conteúdo abordado
aqui pode ser utilizado como material de revisão para o exame certificação ITIL
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 conteúdo próprio com
comentários e críticas do autor. Todos os termos da ITIL foram traduzidos para o
idioma português com o auxílio do glossário oficial da ITIL.

Este material não tem como objetivo substituir os livros oficiais da ITIL e nem mesmo o
conteúdo apresentado durante o nosso curso e-learning. Muitos tópicos não são
explorados com profundidade, pois eles não são necessários à preparação do
candidato para o exame ITIL Foundation. Somente é apresentado aqui o que é
necessário para esta preparação. Para que o aluno receba nosso certificado de
conclusão de treinamento, é obrigatório ter assistido ao menos a 70% das aulas
gravadas e ter realizado todos os quizzes e exercícios propostos durante as aulas
gravadas.

Marcas envolvidas

ITIL® é uma marca registrada da AXELOS.

Logotipo Swirl™ é uma marca comercial da AXELOS.

A TIEXAMES como provedor de treinamento credenciado pela PEOPLECERT possui

licenciamento junto a AXELOS, órgão licenciador do conteúdo ITIL, para utilizar textos
e imagens dos livros oficiais.

Outras marcas registradas podem aparecer no decorrer deste curso. O uso destas
marcas e logotipos é apenas para fins editoriais, em benefício exclusivo do dono da
marca registrada, sem intenção de infringir as regras de sua utilização.

Revisão: 3.12
Data da revisão: 12/06/18
Material atualizado conforme o syllabus 5.x do exame oficial ITIL® Foundation.

Caso você identifique erros, reporte-os pelo e-mail contato@tiexames.com.br

2
Índice
1 - INTRODUÇÃO À ITIL..................................................................................................... 7
1.1 INTRODUÇÃO À ITIL ........................................................................................................ 7
Os 5 livros principais ......................................................................................................... 8
Organizações envolvidas na ITIL ....................................................................................... 8
Por que gerenciar serviços de TI? .................................................................................... 10
Uso das melhores práticas ............................................................................................... 12
Vantagens de frameworks públicos................................................................................... 13
Razões para adotar a ITIL ............................................................................................... 13
Posicionamento da ITIL ................................................................................................... 14
Benefícios que podem ser obtidos com as práticas da ITIL ............................................... 15
Alguns casos de sucesso com a adoção da ITIL ................................................................ 15
Evolução da ITIL ............................................................................................................. 16
1.1 ESQUEMA DE QUALIFICAÇÃO EM ITIL ............................................................................ 18
Treinamento e qualificação em ITIL ................................................................................. 18
Esquema de qualificação profissional na ITIL .................................................................. 18
Vamos a seguir detalhar cada um dos níveis deste esquema de certificação...................... 19
Nível ITIL Foundation...................................................................................................... 19
Nível ITIL Practitioner..................................................................................................... 19
Nível ITIL Intermediário .................................................................................................. 20
Nível ITIL Expert ............................................................................................................. 21
Nível ITIL Master............................................................................................................. 21
Vantagens de ser um profissional certificado em ITIL ...................................................... 22
Mercado de trabalho para profissionais certificados ........................................................ 22
2 - INTRODUÇÃO AO GERENCIAMENTO DE SERVIÇOS .......................................... 23
2.1 DEFINIÇÕES DE TERMOS USADOS NO GERENCIAMENTO DE SERVIÇOS .............................. 23
Serviços ........................................................................................................................... 23
Tipos de serviços de TI..................................................................................................... 24
Resultados ....................................................................................................................... 25
Gerenciamento de serviços............................................................................................... 26
Provedor de serviços de TI ............................................................................................... 28
Parte interessada (stakeholder) ........................................................................................ 29
Ativos de serviço .............................................................................................................. 31
Utilidade e garantia ......................................................................................................... 32
Gerenciamento de riscos .................................................................................................. 33
Governança ..................................................................................................................... 36
2.2 CONCEITOS RELACIONADOS A PROCESSOS E FUNÇÕES .................................................... 38
Definições - processos e funções ...................................................................................... 38
Características de processos ............................................................................................ 41
Definições - funções ......................................................................................................... 42
Processos x Funções ........................................................................................................ 43
2.3 PAPÉIS GENÉRICOS ......................................................................................................... 44
Papéis genéricos no gerenciamento de serviços ............................................................... 44
Considerações sobre papéis ............................................................................................. 48
Papel x Cargo .................................................................................................................. 48
2.4 MATRIZ DE ATRIBUIÇÃO DE RESPONSABILIDADES - RPCI ............................................... 49
Matriz de atribuição de responsabilidades - RPCI............................................................ 49
2.5 COMPETÊNCIAS E HABILIDADES ..................................................................................... 51
Competências e treinamento ............................................................................................ 51
Framework (estrutura) para competência e habilidades ................................................... 51
ADOÇÃO DE FERRAMENTAS PARA AUTOMAÇÃO DE SERVIÇOS .............................................. 52
Automação de serviços..................................................................................................... 52

3
 Uso de ferramentas de gerenciamento de serviços ............................................................ 52
3 - INTRODUÇÃO AO CICLO DE VIDA DO SERVIÇO ................................................. 53
3.1 VISÃO GERAL ................................................................................................................. 53
3.2 INTRODUÇÃO ÀS PUBLICAÇÕES DO CICLO DE VIDA DO SERVIÇO ...................................... 54
Estratégia de serviço........................................................................................................ 54
Desenho de serviço .......................................................................................................... 55
Transição de serviço ........................................................................................................ 56
Operação de serviço ........................................................................................................ 56
Melhoria contínua de serviço (MCS) ................................................................................ 57
Feedback contínuo ........................................................................................................... 58
3.3 APRESENTAÇÃO DOS PROCESSOS DA ITIL 2011 .............................................................. 59
Mapa dos 26 processos e 4 funções da ITIL...................................................................... 59
Atuação dos processos no ciclo de vida ............................................................................ 60
4 - ESTRATÉGIA DE SERVIÇO ........................................................................................ 61
4.1 PROPÓSITO, OBJETIVOS, ESCOPO E VALOR AGREGADO AO NEGÓCIO ................................ 61
Propósito da estratégia de serviço.................................................................................... 61
Objetivos da estratégia de serviço .................................................................................... 62
Escopo da estratégia de serviço ....................................................................................... 62
Valor que a estratégia de serviço agrega ao negócio........................................................ 62
4.2 CONCEITOS E PRINCÍPIOS-CHAVE ................................................................................... 63
Valor de serviço ............................................................................................................... 63
Percepção de valor .......................................................................................................... 64
Padrões de atividade de negócio (PAN) ........................................................................... 66
Caso de negócio............................................................................................................... 67
4.3 PROCESSOS DA ESTRATÉGIA DE SERVIÇO ........................................................................ 68
Gerenciamento de portfólio de serviço ............................................................................. 68
Gerenciamento financeiro para serviços de TI ................................................................. 71
Gerenciamento financeiro para serviços de TI ................................................................. 72
Gerenciamento de relacionamento de negócio ................................................................. 73
4.4 TIPOS DE FERRAMENTAS DE SUPORTE A ESTRATÉGIA DE SERVIÇO .................................. 76
5 - DESENHO DE SERVIÇO............................................................................................... 77
5.1 PROPÓSITO, OBJETIVOS, ESCOPO E VALOR AGREGADO AO NEGÓCIO ................................ 77
Propósito do desenho de serviço ...................................................................................... 77
Objetivos do desenho de serviço....................................................................................... 77
Escopo do desenho de serviço .......................................................................................... 78
Valor que o desenho de serviço agrega ao negócio .......................................................... 78
5.2 CONCEITOS E PRINCÍPIOS-CHAVE ................................................................................... 79
A importância dos 4 Ps no desenho .................................................................................. 79
Os 5 aspectos do desenho de serviço ................................................................................ 80
Até poderíamos intitular esta seção como "O escopo do estágio de desenho de serviço".
Que tipo de coisas se desenha nesse estágio? Claramente, nós desenhamos o serviço, mas
ao fazer isso também devemos identificar os impactos em outras áreas que podem ser
afetadas pelo projeto. ITIL se refere a essas áreas como os cinco aspectos do desenho de
serviço. Aqui estão elas:................................................................................................... 80
Soluções de serviço: desenhamos os serviços novos ou alterados. Coletamos e acordados
todos os requisitos funcionais e estimamos os recursos e capacidades necessários para
desenvolver e operar o serviço. ........................................................................................ 80
Sistemas e ferramentas de gerenciamento de serviços: qualquer ferramenta de
gerenciamento de serviços que usaremos, por exemplo, uma ferramenta de registro de
chamadas na central de serviços. Devemos estabelecer um conjunto de requisitos e
adquirir ou desenvolver as ferramentas para atender a esses requisitos. A ITIL dá uma

4
 menção especial aqui ao portfólio de serviços (que abordo no Capítulo 4), do qual
extraímos os requisitos de negócios de alto nível para novos serviços. ............................. 80
Arquiteturas de tecnologia e sistemas de gerenciamento: a arquitetura, as ferramentas e os
sistemas que devem estar implementados para suportar o desenho da infraestrutura, dos
dados e dos ambientes. ..................................................................................................... 80
Processos: desenhando os processos de gerenciamento de serviços. Desenhar e
implementar esses processos pode ser demorado e complexo. .......................................... 80
Sistemas, métodos e métricas de medição: não são as ferramentas de monitoramento
propriamente ditas, embora as usemos para reunir grande parte de seus dados de medição
- a ênfase aqui é desenhar uma estrutura para agrupar as medidas e métricas certas que
fornecem a visibilidade e a capacidade necessárias para controlar o serviço e os processos
de gerenciamento de serviços. .......................................................................................... 80
Pacote de Desenho de serviço (PDS) ................................................................................ 81
5.3 PROCESSOS NO DESENHO DE SERVIÇO ............................................................................ 83
Coordenação de desenho ................................................................................................. 83
Gerenciamento de catálogo de serviço ............................................................................. 85
Gerenciamento de nível de serviço (GNS) ........................................................................ 90
Gerenciamento de disponibilidade ................................................................................. 100
Gerenciamento de capacidade ....................................................................................... 106
Gerenciamento de continuidade de serviço de TI............................................................ 109
Gerenciamento de segurança da informação .................................................................. 113
Gerenciamento de fornecedor ........................................................................................ 115
5.4 TIPOS DE FERRAMENTAS DE SUPORTE AO DESENHO DE SERVIÇO .................................. 117
6 - TRANSIÇÃO DE SERVIÇO ....................................................................................... 118
6.1 PROPÓSITO, OBJETIVOS, ESCOPO E VALOR AGREGADO AO NEGÓCIO .............................. 118
Propósito da transição de serviço .................................................................................. 118
Objetivos da transição de serviço ................................................................................... 118
Escopo da transição de serviço ...................................................................................... 119
Valor que transição de serviço agrega ao negócio ......................................................... 120
6.2 PROCESSOS DA TRANSIÇÃO DE SERVIÇO ....................................................................... 120
Planejamento e suporte da transição.............................................................................. 120
Gerenciamento de configuração e de ativo de serviço .................................................... 122
Gerenciamento de conhecimento .................................................................................... 129
Gerenciamento de mudança ........................................................................................... 132
Gerenciamento de liberação e implantação .................................................................... 141
6.3 TIPOS DE FERRAMENTAS DE SUPORTE A TRANSIÇÃO DE SERVIÇO .................................. 143
7 - OPERAÇÃO DE SERVIÇO ......................................................................................... 144
7.1 PROPÓSITO DA OPERAÇÃO DE SERVIÇO......................................................................... 145
Propósito da operação de serviço .................................................................................. 145
Objetivos da operação de serviço ................................................................................... 145
Escopo da operação de serviço ...................................................................................... 145
Valor que a operação de serviço agrega ao negócio....................................................... 146
7.2 PRINCÍPIOS-CHAVE....................................................................................................... 146
Papel da comunicação na operação de serviço .............................................................. 146
7.3 PROCESSOS DA OPERAÇÃO DE SERVIÇO ........................................................................ 147
Gerenciamento de evento ............................................................................................... 148
Gerenciamento de incidente ........................................................................................... 150
Cumprimento de requisição ........................................................................................... 158
Gerenciamento de problema .......................................................................................... 160
Gerenciamento de acesso ............................................................................................... 167
7.4 FUNÇÕES NA OPERAÇÃO DE SERVIÇO ........................................................................... 168
Central de serviço .......................................................................................................... 169
Gerenciamento técnico................................................................................................... 174

5
 Gerenciamento de aplicativo .......................................................................................... 175
Gerenciamento de operações de TI ................................................................................ 176
Sobreposições das funções na organização .................................................................... 177
7.5 TIPOS DE FERRAMENTAS DE SUPORTE A OPERAÇÃO DE SERVIÇO ................................... 177
8 - MELHORIA CONTÍNUA DE SERVIÇO (MCS) ........................................................ 178
8.1 PROPÓSITO, OBJETIVOS, ESCOPO E VALOR AGREGADO .................................................. 178
Introdução à MCS.......................................................................................................... 178
Propósito da MCS.......................................................................................................... 179
Objetivos da MCS .......................................................................................................... 179
Escopo da MCS.............................................................................................................. 179
MCS através do ciclo de vida ......................................................................................... 180
Valor que a MCS agrega ao negócio .............................................................................. 181
8.2 PRINCÍPIOS-CHAVE E MODELOS .................................................................................... 181
Ciclo de Deming (PDCA) ............................................................................................... 181
Abordagem de melhoria contínua de serviço .................................................................. 182
PAPEL DA MEDIÇÃO PARA A MELHORIA CONTÍNUA DE SERVIÇO ......................................... 183
FCSs e PIDs .................................................................................................................. 184
Linhas de base de medição ............................................................................................. 184
Tipos de métricas ........................................................................................................... 185
Registro da MCS ............................................................................................................ 186
8.3 PROCESSOS DA MCS .................................................................................................... 187
Processos da MCS ......................................................................................................... 187
Processo de melhoria de 7 etapas .................................................................................. 187
8.4 TIPOS DE FERRAMENTAS DE SUPORTE A MCS ............................................................... 190
9 - ORIENTAÇÕES PARA O EXAME DE CERTIFICAÇÃO ........................................ 191
9.1 EXAME ITIL ................................................................................................................ 191
Informações adicionais sobre o exame ITIL Foundation ................................................. 191
9.2 CURRÍCULO DO EXAME ITIL ........................................................................................ 192
Escopo do exame ITIL Foundation ................................................................................. 192
Detalhamento dos tópicos do currículo ITIL Foundation ................................................ 192
9.3 DICAS PARA PREPARAÇÃO............................................................................................ 197
Realize o quanto antes o seu exame ................................................................................ 197
Recomendações para estudos após o curso .................................................................... 197
Recomendações durante o exame ................................................................................... 198
9.4 CERTIFICADO ITIL ....................................................................................................... 199
Resultado do exame ....................................................................................................... 199
Certificado..................................................................................................................... 199
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................... 200

6
1 - Introdução à ITIL
1.1 Introdução à ITIL
De propriedade da AXELOS (joint venture estabelecida com o Cabinet Office do
Governo no Reino Unido), a ITIL é um conjunto de publicações das melhores práticas
para gerenciamento de serviços de TI.

A ITIL não é uma norma que tem que ser seguida. Em vez disto, é um guia que
contém práticas que podem ser adotadas e adaptadas em cada organização
conforme as suas necessidades, pois fornece orientações para todos os tipos de
provedores de serviço sobre como fornecer serviços de TI com qualidade, abordando
processos, funções e outras habilidades necessárias. Com mais de 20 anos
existência, sua última edição foi lançada em 2011.

A ITIL é o framework (estrutura de trabalho) mais utilizado para o gerenciamento de

serviços de TI no mundo todo. Este framework é baseado em um ciclo de vida de
serviço que contém 5 componentes ou estágios, com um livro para cada estágio.

A biblioteca atual da ITIL está estrutura da seguinte forma:

• Conteúdo complementar: livro de introdução, guias de bolso, guias

complementares com a aplicação da ITIL em cenários específicos, guias
voltados para certificações ITIL, guias para implementação e material baseado
na web.

• Conteúdo principal: 5 publicações do ciclo de vida.

Onde comprar publicações oficiais: www.amazon.com e www.axelos.com

Observação: os livros oficiais da ITIL não foram traduzidos para o português e não há previsão de
tradução.

7
Os 5 livros principais
Abaixo você visualiza as capas dos 5 livros principais da ITIL. Durante o curso, é
fornecida uma visão geral de todos estes livros.

Basicamente todos os cinco livros principais da ITIL têm a mesma estrutura de

conteúdo:

1. Introdução, visão geral, contexto

2. Gerenciamento de serviço como uma prática
3. Princípios do estágio
4. Processos do estágio
5. Atividades adicionais do estágio
6. Estruturas organizacionais de suporte e papéis
7. Considerações sobre o uso de tecnologias
8. Considerações para a implementação do estágio
9. Desafios, riscos e fatores críticos de sucesso
10. Apêndices com exemplos e templates

Organizações envolvidas na ITIL

Conheça abaixo as principais organizações envolvidas no desenvolvimento da ITIL e
certificações para profissionais.

AXELOS

Os produtos do portfólio de melhores práticas foram criados em nome do Governo da

Sua Majestade (sigla HSM em inglês), no Reino Unido. De 2000 a 2010, o Office of
Government Commerce (OGC), também um órgão do governo do Reino Unido, foi o
guardião da propriedade intelectual destes produtos. E, de 2010 em diante, o Cabinet
Office assumiu esta propriedade e criou mais alguns produtos. E por fim, em 1 de
junho de 2013, foi anunciada a criação nova empresa chamada AXELOS, uma joint

8
venture formada entre o Cabinet Office e a empresa Capita. A AXELOS foi criada para
entregar e comercializar o portfólio de produtos e credenciamentos associados a
publicação das melhores práticas, incluindo ITIL e outros produtos como o PRINCE2.
A AXELOS agora detém a propriedade intelectual de todo o portfólio de melhores
práticas.

TSO

É a editora responsável pela impressão e publicação das obras da coroa britânica,

incluindo os livros oficiais da ITIL.

Instituto de exame

Um Instituto de Exame (IE) é uma organização credenciada e licenciada pelo órgão

credenciador (agora a AXELOS) que tem a permissão para administrar os exames de
certificação ITIL e atividades de credenciamento.

A PEOPLECERT é a partir de 2018 o único instituto de exames autorizado pela

AXELOS para oferecer os exames de ITIL em todo o mundo. Os exames podem ser
realizados remotamente (em casa ou no trabalho) ou em sala de aula (se contratados
em um treinamento presencial local).

9
Por que gerenciar serviços de TI?
Agora que você sabe o que é ITIL e quais as organizações envolvidas, vamos
entender um pouco sobre as motivações que levaram as empresas a adotarem as
melhores práticas para gerenciamento de serviços de TI.

Por muitos anos algumas organizações puderam continuar seus negócios ainda que
tivessem pouco apoio da Tecnologia da Informação (TI). Hoje a realidade é diferente:
a TI é um fator crítico de sucesso para muitas organizações, e até em 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
bancárias dos clientes sem o apoio de um sistema de banco de dados.

A TI hoje se tornou um parceiro estratégico para muitas empresas. Ela faz parte do
negócio – por isso falamos que a TI está integrada ao negócio (ou pelo menos deveria
estar). 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 está deixando de ser tratada apenas por
técnicos e está passando a ser incorporada na estratégia da empresa para alcançar
seus objetivos de negócio. Em algumas empresas, obviamente, não há este mesmo
nível de integração: a TI ainda é tratada como um componente tecnológico. Quando a
TI é tratada como componente tecnológico e apenas é comunicada sobre as decisões
da organização, ela se torna muito reativa às mudanças, e muitas vezes não consegue
atender prontamente a todas elas. Em empresas onde é colocada como parceira de
negócios, a TI consegue antecipar as mudanças e consegue fazer um planejamento
adequado. A ITIL é uma biblioteca que vai ajudar a TI a se integrar com 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:

• Adaptar-se rapidamente às necessidades de mudança do negócio. Como você

já deve saber, hoje no mercado competitivo as organizações têm que inovar o
tempo todo. Qualquer serviço ou produto que as organizações venham a
oferecer vai depender da TI de alguma forma para ser colocado no mercado.
Imagine uma empresa de transporte aéreo: se ela decide colocar à venda de
bilhetes na internet, ela vai precisar que a TI desenvolva este sistema,
preocupando-se com a funcionalidade da compra do bilhete e com a segurança
da informação. É raro hoje uma organização que não dependa da TI para
executar suas estratégias. Com isto a TI tem que ser muito ágil. Qualquer
mudança no negócio implica em alguma mudança na infraestrutura de TI.
• A TI precisa justificar o Retorno sobre o Investimento (ROI). A TI é uma das
áreas das organizações que mais consumiu investimentos nos últimos anos.
Os projetos de TI são complexos, envolvem tecnologias, e isto custa muito
dinheiro para as organizações. A questão é que muitas iniciativas em TI nem
sempre geram resultados para as organizações. A TI precisa de alguma forma
justificar o seu orçamento anual e comprovar como cada projeto vai gerar
retorno para o negócio. E o pessoal de TI tem muita dificuldade em fazer estas
justificativas, pois existe uma lacuna entre a linguagem de TI e a linguagem
usada pelo pessoal de negócio. Ambos precisam conversar na mesma língua.

10
 • Com a competitividade do mercado, as organizações veem-se pressionadas a
reduzir seus custos internos. Todas as áreas da organização são impactadas,
inclusive a TI. Por isso a TI precisa obter maior eficiência e eficácia nas suas
operações. Ela precisa conseguir executar suas operações com um orçamento
anual menor. Em resumo, temos aqui um desafio de otimizar os recursos e
custos das operações de TI.
• Como os processos de negócio de uma organização dependem de algum
serviço para funcionar, chegamos a um ponto em que qualquer parada em um
serviço de TI impacta diretamente o negócio. No caso de uma indisponibilidade
no servidor que hospeda o site de venda de bilhetes, automaticamente os
clientes não poderão efetuar suas compras e consequentemente vão procurar
outra companhia aérea. A TI tornou-se um risco operacional para a
organização. Ela precisa ser flexível o suficiente para atender às novas
demandas do negócio e ao mesmo tempo ela precisa criar um ambiente
estável. Temos aqui um grande desafio: aumentar a disponibilidade dos
serviços de TI sem perder a agilidade.
• Como todas as informações da organização estão armazenadas em sistemas,
servidores e bancos de dados, qualquer norma regulamentadora impacta
diretamente as operações de TI. A segurança da informação é algo crítico para
as organizações. Leis como a Sarbanes Oxley e normas do Banco Central,
entre outras, impactam diretamente a TI da organização. Com isto, as
operações de TI devem oferecer o menor risco possível e segurança em
conformidade com todas estas leis e regulamentos que impactam o negócio.

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ários frameworks (estruturas) de processos e boas práticas foram criados. A
figura abaixo mostra a evolução destes frameworks e seus níveis de maturidade em
termos de gerenciamento de serviços de TI.

Maturidade do
Gerenciamento de TI

ITIL v.3
ISO 20.000
BS 15000

ITIL v.2
HP ITSM
ITIL
IBM ISMA
Idade
escura da TI

Tempo
1970 1980 1990 2000 2005 2007

11
Uso das melhores práticas
As organizações costumam fazer benchmarking (comparação) para procurar por gaps
(lacunas, diferenças) nas suas habilidades. Isto as possibilita se tornarem mais
competitivas por meio do aperfeiçoamento de sua habilidade de entregar serviço de
qualidade que atenda às necessidades dos seus clientes a um preço que eles podem
pagar.

Uma forma de preencher as lacunas é por meio da adoção de melhores práticas

usadas pelo mercado. Existem várias fontes de melhores práticas, incluindo
frameworks públicos e normas e conhecimento de organizações e indivíduos.

Veja abaixo a definição de melhores práticas.

Melhores práticas
Atividades ou processos que comprovadamente obtiveram sucesso quando usados
em várias organizações. (Glossário da ITIL)

As melhores práticas originam-se de:

• Frameworks públicos (exemplos:

COBIT, CMMI, PMBOK, ITIL, etc.)
• Padrões proprietários (desenvolvidos
por alguma empresa/governo apenas
para o seu uso próprio)
• Normas ISO, leis, regulamentos
• Práticas da indústria
• Pesquisas acadêmicas
• Treinamento e educação
• Experiência interna

A ITIL é um framework de domínio público que representa um conjunto das melhores

práticas para o gerenciamento de serviços de TI que já foram testadas por outras
empresas. A ideia por trás da ITIL é não reinventar a roda. As práticas da ITIL já foram
testadas por milhares de empresas. São práticas comprovadas. Estas práticas foram
documentadas para que todos possam se beneficiar da experiência de outros.

12
Vantagens de frameworks públicos
A ITIL é um framework público que pode ser adotado por qualquer empresa ou
indivíduo sem a necessidade de pagar royalties. Framework público significa uma
estrutura de trabalho de referência divulgada abertamente para qualquer organização
adotar.

Vantagens de se usar um framework público:

▪ O conhecimento proprietário é difícil de ser adotado, replicado ou ainda

transferido sem a cooperação de seus proprietários. Normalmente, este
conhecimento proprietário está mal documentado.
▪ O conhecimento proprietário é personalizado para o contexto local e
necessidades específicas de uma empresa.
▪ Normalmente há custos com licenciamento para usar o conhecimento
proprietário.
▪ Frameworks públicos como ITIL, COBIT, CMMI, PMBOK, etc. foram validados
em vários ambientes e há várias experiências compartilhadas.
▪ O conhecimento de frameworks públicos é largamente divulgado na
comunidade de profissionais por meio de treinamentos e certificação.

Razões para adotar a ITIL

A ITIL adota uma abordagem prática para o gerenciamento de serviços: faça o que
funciona. Ela descreve as práticas que permitem às organizações entregar benefícios,
retorno do investimento e sucesso sustentado. Sucesso sustentado consiste em
atender às necessidades das partes interessadas (principalmente do cliente) não
somente no curto e médio prazo. Você verá durante os processos do ciclo de vida do
serviço, principalmente no estágio de Desenho de serviço, que são feitas
considerações sobre as necessidades futuras do negócio para o planejamento de
serviços novos e alterados. Essa é a principal razão para o sucesso global da ITIL.
Outras razões para adotá-la são que a ITIL é:

• Um modelo independente de plataforma tecnológica. Suas práticas de

gerenciamento de serviços são aplicáveis em qualquer organização de TI, pois
não são baseadas em uma plataforma tecnológica ou um tipo de indústria
específicos.

• Um modelo não prescritivo. A proposta da ITIL é servir como um guia

orientativo para práticas de gerenciamento de serviços de TI. A ITIL não é uma
norma com regras rígidas, ordenando exatamente o que tem que ser feito. Isto
permite então que a ITIL seja adotada e adaptada conforme o contexto da
organização.

• Uma fonte das melhores práticas. Ela apresenta experiências de

aprendizagem e liderança dos melhores prestadores de serviços no mundo.

13
Posicionamento da ITIL
Veja na figura abaixo o posicionamento da ITIL® em relação a outros modelos para
gerenciamento de serviços de TI:

Não existe uma certificação ITIL para empresas, apenas para profissionais. As
empresas que quiserem obter um selo ou certificação para seus processos de TI
poderão se certificar com base na ISO/IEC 20000. Publicada em dezembro de 2005, a
ISO/IEC 20000 propôs estabelecer os requisitos mínimos que um provedor de serviços
de TI deve atender para dizer que ele tem um sistema de gerenciamento de serviços
de TI estabelecido e controlado. Esta norma ISO substitui a norma britânica BS 15000.
Uma organização que adota as práticas da ITIL terá mais facilidade em conseguir a
certificação ISO/IEC 20000, pois esta norma foi baseada na estrutura da ITIL. A ITIL
explica como devem ser os processos e a ISO/IEC 20000 tem os requisitos
obrigatórios que especificam o que o provedor de serviços deve cumprir.

No Brasil já temos algumas empresas certificadas em ISO/IEC 20000. Acredita-se que

esta norma ainda terá muitas empresas certificadas no país. A partir do momento em
que o governo começar a colocar este requisito em suas licitações, muitas empresas
vão começar a se preocupar com esta certificação. As organizações ainda não estão
preparadas para a ISO/IEC 20000 – falta muito para chegar lá pois muitas empresas
ainda estão no estágio de conhecer o que é esta tal de ITIL.

Abaixo da ITIL, na pirâmide acima, encontramos outros modelos baseados nas ITIL,
como MOF da Microsoft e o modelo de gestão de serviços desenvolvido pela HP.
Estes modelos foram desenvolvidos para cenários específicos. E na base da pirâmide
está a implementação do gerenciamento de serviços de TI na organização. Cada
organização irá desenhar seus processos de TI atendendo a particularidades do seu
cenário. A ITIL serve apenas de inspiração para que as organizações possam
desenhar ou melhorar seus processos de gerenciamento de serviços de TI.

14
Benefícios que podem ser obtidos com as práticas da ITIL
A ITIL é adotada pelas organizações com as seguintes intenções:

▪ Entregar valor para os clientes por meio de serviços de TI

▪ Integrar a estratégia para serviços com a estratégia de negócio e necessidades
dos clientes
▪ Medir, monitorar e otimizar serviços de TI e o desempenho do provedor de
serviços
▪ Gerenciar investimento e orçamento para TI
▪ Gerenciar riscos
▪ Gerenciar conhecimento
▪ Gerenciar habilidades e recursos para entregar serviços de forma eficaz e
eficiente
▪ Possibilitar a adoção de uma abordagem padrão para o gerenciamento de
serviços na organização
▪ Fazer uma mudança cultural na organização para suportar a realização do
sucesso pretendido
▪ Melhorar interação e relacionamento com clientes
▪ Otimizar e reduzir custos.

Alguns casos de sucesso com a adoção da ITIL

A ITIL é adotada por mais de 15.000 organizações no mundo todo. Grandes empresas
como IBM, Microsoft, HP, Boeing, HSBC, British Airways e P&G são algumas das
usuárias.

Alguns cases divulgados:

• Caterpillar – 18 meses após a implantação, o índice de atendimento a

incidentes realizado nos acordos de nível de serviço firmados com as unidades
de negócio da organização passou de 60% para mais de 90%.
• Corte de Justiça de Ontário – Implantou e ativou um service desk virtual,
reduzindo os custos com suporte técnico em 40% dois anos e meio após a
implantação.
• Procter & Gamble – Três anos após a implantação, obteve uma redução entre
6% e 8% nos custos operacionais da infraestrutura de TI, e uma redução entre
15% e 20% do pessoal alocado. No caso específico do service desk, foi obtida
uma redução de 10% no volume total de chamadas recebidas. Conseguiu
economizar U$ 125 milhões nos custos anuais de TI.
• Polícia militar de SP – Conseguiu o incremento em 10% na disponibilidade da
TI e reduziu em também 10% os custos com o departamento de TI.
Veja mais cases em http://www.itsmcommunity.org/Resources/casestudies

15
Evolução da ITIL
A ITIL fornece orientações práticas e tem mais 20 anos de evolução. Acompanhe
abaixo a linha de evolução desta biblioteca:

Fonte: Baseado em http://itservicemngmt.blogspot.com/2007/09/brief-history-of-itil.html

Em 1983 o governo britânico pediu para a CCTA, que era o departamento que
desenvolvia pesquisas em TI, para desenvolver um manual de boas práticas no
gerenciamento de infraestrutura, com o foco em reduzir os custos em suas áreas de
TI.

O CCTA pesquisou o que as empresas de sucesso estavam fazendo, compilou tudo e

daí nasceu o GITIMM, Método de Gerenciamento da Infraestrutura de TI do Governo.
Este foi o primeiro nome da ITIL.

Alguns anos depois, viu-se que este nome não combinava muito com a estrutura dos
livros, e decidiram tirar o G de Governo e trocaram os dois MM do final por L de
Library, já que a estrutura era composta por mais de um livro. Eis que então a
biblioteca ganha o nome de ITIL (IT Infrastructure Library).

A partir daí empresas mundo afora conheceram o que o governo britânico tinha
produzido e perceberam que as praticas da ITIL eram aplicáveis nos departamentos
de TI das empresas privadas. Foi então que a partir da década de 90 empresas
começaram a adotar estas práticas.

Como o governo britânico não tinha desenvolvido a ITIL com o intuito de disseminá-la
mundo afora (o objetivo era apenas o uso interno), decidiu-se então repassar esta
tarefa para uma entidade chamada na época de ITMF (IT Infrastructure Management

16
Fórum). O ITMF era composto por uma comunidade de profissionais de TI com
objetivo de discutir e disseminar as boas práticas na gestão de TI. Como viram que a
área de TI estava se transformando em uma área de serviços (o foco deixava de ser a
manutenção da infraestrutura), decidiu-se em 1997 mudar o nome da comunidade
para itSMF (IT Service Management Forum).

A partir do ano 2000 a ITIL passa por uma reestruturação. Surge então o primeiro livro
da ITIL versão 2, Suporte ao Serviço. Ao longo dos próximos anos são lançados os
demais livros, totalizando 9.

Em 2004 inicia-se um projeto para reescrever toda a biblioteca e lançar a ITIL versão
3. Enquanto a ITIL era toda reescrita em 2005, é publicada a norma ISO/IEC 20000,
voltada para certificar o sistema de gestão das áreas de TI das empresas. Pelo fato da
ISO/IEC 20000 ter sido publicada antes da ITIL versão 3 , ela tem uma estrutura muito
parecida com estrutura de processos da versão 2.

Desde 2004 o OGC (suas funções agora passaram para o Cabinet Office) , que ficou
responsável pela ITIL, iniciou um projeto chamado ITIL Refresh, que trata de uma
revisão da atual estrutura de livros. A ITIL versão 2 já não refletia totalmente a
realidade das organizações. Foram convidados vários autores de diversas empresas e
universidades para criar uma nova versão. Os livros foram todos reescritos e em maio
de 2007 foi lançada a ITIL versão 3, com 5 livros principais. A partir de então, ITIL
deixa de ser referenciado com um acrônimo de “IT Infrastructure Library” e passa ser
apenas uma marca, isto porque se entende que a ITIL hoje não cobre apenas
aspectos da infraestrutura. Gerenciamento de serviços é algo mais abrangente.

Em 2011 foi lançada a ITIL edição 2011 trazendo algumas correções e melhorias nos
5 livros principais.

A seguir apresentaremos o esquema de certificação atual da ITIL e informações sobre

a estrutura do exame ITIL Foundation.

17
1.1 Esquema de qualificação em ITIL
Treinamento e qualificação em ITIL
O treinamento em gerenciamento de serviços ajuda os provedores de serviço a
construir e manter as habilidades necessárias para a entrega de serviços que atendam
às necessidades de seus clientes.

O esquema de qualificação profissional da ITIL possibilita às organizações o

desenvolvimento de competência do seu pessoal por meio de cursos de treinamento
aprovados. Os cursos ajudam os alunos a ganhar conhecimento das melhores práticas
da ITIL, desenvolver suas competências e ganhar uma qualificação reconhecida
internacionalmente.

O esquema tem cinco níveis de qualificação profissional:

Esquema de qualificação profissional na ITIL

O esquema de qualificação da ITIL é bem estruturado e fornece uma carreira para o
profissional que deseja especializar-se em gerenciamento de serviços de TI. Este
esquema introduz um sistema de aprendizagem que possibilita ao candidato ganhar
créditos para todas as certificações ITIL que ele alcançar. Uma vez que o candidato
acumular um número suficiente de créditos, pode ser concedido a ele a certificação
ITIL Expert em gerenciamento de serviços de TI.

18
Para alcançar a certificação ITIL Expert, os candidatos precisam obter o mínimo de 22
créditos. Dois deles vêm do módulo Foundation, o qual é o primeiro passo mandatório,
e cinco devem vir do módulo “Managing Across the Lifecycle”, o qual é o passo final
mandatório. Os demais créditos vêm do módulo practitioner e dos módulos
intermediários.

Após ter obtido a certificação Foundation, os candidatos podem escolher entre fazer o
curso do módulo Practitioner ou os do nível Intermediário. No nível intermediário
existem os módulos de Capability (geram 4 créditos por módulo) ou de Lifecycle
(geram 3 créditos por módulo) para ganhar os outros 15 créditos necessários para
obter a certificação ITIL Expert.

Vamos a seguir detalhar cada um dos níveis deste esquema de certificação.

Nível ITIL Foundation

Este é o nível de entrada para qualquer profissional que queira se capacitar e
desenvolver carreira em gerenciamento de serviços de TI. A certificação ITIL
Foundation tem um público muito abrangente e se aplica a qualquer membro da
equipe de TI envolvido em atividades de gerenciamento de serviços de TI.

Durante o curso ITIL Foundation, o candidato obtém conhecimentos básicos da ITIL,

sua terminologia, princípios e conceitos básicos e entendimento abrangente das
práticas de gerenciamento de serviços de TI. É importante deixar claro que o
treinamento no nível Foundation não tem a intenção de capacitar o profissional a
conduzir sozinho um projeto de implementação das práticas da ITIL – para isto
existem os cursos no nível intermediário.

Não há pré-requisitos para realizar o exame deste nível de certificação. Apesar de

recomendado, não é necessário passar por um treinamento formal. É permitido ao
candidato optar pelo autoestudo e contratar o exame diretamente do instituto
PEOPLECERT, que é o único instituto que está aplicando os exames de ITIL desde o
início de 2018.

O nível de dificuldade deste exame é considerado fácil. O exame testa apenas

conhecimentos básicos sobre a ITIL (não testa a aplicação dos conceitos em situações
práticas). O exame é sem consulta ao material, composto por 40 questões de múltipla
escolha, sendo necessário acertar no mínimo 26 questões (65%). Ele pode ser
realizado em no máximo 60 minutos de duração e está disponível em português.
Quando o exame pode ser realizado remotamente em casa e o resultado de
aprovação sai na hora.

Nível ITIL Practitioner

Este pode ser o próximo passo após obter a certificação ITIL Foundation. É um nível
opcional antes de realizar os cursos intermediários.

Neste curso, o candidato ganha orientações de como adotar a adaptar a estrutura da

ITIL para suportar os objetivos de negócio. O foco está em práticas de melhoria
contínua e como preparar a organização para mudanças.

19
Não é necessário passar pelo curso credenciado para prestar o exame deste nível,
também é permitido autoestudo. E ao passar no exame são acumulados 3 créditos.
Até o início de 2018, este exame ainda não estava disponível no idioma português.
Consulte diretamente no site da AXELOS em https://www.axelos.com/certifications/itil-
certifications/itil-practitioner-level se foi disponibilizado o syllabus (currículo) em
português. Uma vez disponibilizado o syllabus em português, o exame também passa
a ser oferecido neste idioma.

Nível ITIL Intermediário

Após ter obtido a sua certificação Foundation o profissional também está habilitado a
participar dos cursos do nível intermediário. O nível intermediário tem uma estrutura
modular e cada módulo tem um foco diferente. O candidato pode ter poucas ou muitas
qualificações intermédias, conforme ele precisar para atender às suas necessidades
de qualificação. Os módulos intermediários entram em mais detalhes do que o nível
Foundation.

As qualificações intermédias são agrupadas em dois conjuntos:

• Trilha do ciclo de vida (lifecycle): esta será de interesse para os candidatos

que buscam uma função de líder de gestão/equipe que requer um enfoque
amplo no gerenciamento de áreas de atuação da ITIL e no trabalho em
equipes. O foco principal é o ciclo de vida em si, o uso de processos e
elementos de prática dentro dele e as habilidades de gestão necessárias para
a realização de práticas de gerenciamento da qualidade de serviço em uma
organização. Para cada módulo desta trilha existe um exame associado. A
certificação somente é obtida se o candidato passar obrigatoriamente por um
treinamento credenciado e passar no exame respectivo.

• Trilha das habilidades (capability): esta será de interesse para os candidatos

que desejam obter conhecimentos especializados e profundos em um ou mais
processos, com foco na execução das práticas da ITIL do dia-a-dia. A atenção
ao ciclo de vida do serviço é ilustrada como parte do currículo dos cursos, no
entanto o foco principal está nas atividades do processo e execução e uso do
processo durante todo o ciclo de vida do serviço. Para cada módulo também há
um exame associado.

20
Veja na figura na página seguinte os cursos que fazem parte de cada uma das trilhas:

Para conhecer o currículo de cada um dos cursos intermediários, consulte o seguinte link:
https://www.axelos.com/qualifications/itil-qualifications/itil-intermediate-level

Qualquer uma das trilhas intermediárias que o candidato escolher vai propiciar a ele
uma compreensão maior das aplicações das práticas da ITIL. É permitido que o
candidato faça uma combinação de certificações entre as duas trilhas para acumular
créditos para o certificado ITIL Expert. Por exemplo: um candidato poderia obter 4
certificações dos módulos do ciclo de vida (4 x 3 créditos = 12 créditos) e fazer mais
uma certificação em um módulo de capacidade obtendo assim mais 4 créditos.

Para localizar provedores de treinamento para estes cursos acima, acesse o site
https://www.axelos.com/find-a-training-provider e procure quais são as empresas
credenciadas no Brasil para oferecer os cursos que você deseja. Os currículos dos
exames também se encontram disponíveis no site do AXELOS.

Nível ITIL Expert

Esta certificação é direcionada para quem tem interesse em demonstrar nível de
conhecimento superior em ITIL. Este título servirá como pré-requisito para a
certificação ITIL Master. Não existe curso para o nível Expert – para alcançar este
título o candidato precisa acumular 22 créditos, obtendo o título ITIL Foundation (2
créditos), realizando cursos intermediários e passando nos respectivos exames
somando pelo menos 17 créditos e passando no exame após realizar o curso de 5
dias “Managing Across the Lifecycle - MALC”.

Para mais informações consulte a página http://www.axelos.com/qualifications/itil-

qualifications/itil-expert-level

Nível ITIL Master

Este é o nível mais elevado de certificação no esquema. Esta certificação é voltada

para pessoas experientes no mercado, tipicamente especialistas, consultores,
gerentes ou executivos seniores, com 5 anos ou mais de experiência relevante. Para
poder obter esta certificação o profissional precisa ter o título de ITIL Expert. Os

21
candidatos a esta certificação terão que elaborar uma proposta de adoção da ITIL em
uma situação real. Se a proposta for aprovada, o candidato terá ainda que defendê-la
para uma banca.

Vantagens de ser um profissional certificado em ITIL

Veja abaixo alguns pontos a serem considerados para o investimento em uma
certificação ITIL:

▪ São as certificações mais valorizadas no mercado, com mais de 600.000

profissionais certificados no mundo todo.
▪ Aumenta as suas habilidades e melhora o desempenho no seu trabalho.
▪ Fornece uma verificação formal do conhecimento por uma entidade terceira.
▪ Possibilita a você provar seus conhecimentos para empregador e clientes em
qualquer lugar do mundo.
▪ Possibilita candidatar-se a vagas de emprego que exigem esta certificação.
▪ Proporciona reconhecimento profissional e networking com outros
profissionais.

Mercado de trabalho para profissionais certificados

Gerenciamento de serviços é uma preocupação em qualquer organização de TI que
oferece serviços. Veja abaixo principais papéis que exigem conhecimento em ITIL:

▪ Gerentes e diretores de TI
▪ Gerentes de serviços e operações
▪ Gerentes de projetos que atuam em projetos de desenvolvimento e
implementação de serviços/aplicativos
▪ Consultores em TI que vão conduzir projetos de implementação baseados em
ITIL
▪ Analistas de processos e qualidade na área de TI
▪ Analistas de infraestrutura de TI
▪ Analistas de segurança da informação
▪ Analistas de suporte técnico (atendentes de helpdesk e especialistas técnicos)
▪ Administradores de rede

22
2 - Introdução ao gerenciamento de serviços
Neste capítulo vamos passar definições sobre termos básicos utilizados no
gerenciamento de serviços. O entendimento destes termos é crucial para que você
possa avançar para os próximos capítulos.

2.1 Definições de termos usados no gerenciamento de

serviços
Serviços
Antes de entender o que é gerenciamento de serviços, primeiro você precisa entender
o que é um serviço e os tipos de serviços. Veja abaixo a definição para serviço
segundo o glossário da ITIL:

Serviço
É um meio de entregar valor aos clientes, facilitando os resultados que os
clientes querem alcançar, sem terem que assumir custos e riscos.

Se você compra um carro, todos os custos de aquisição e riscos são transferidos para
você. Se o carro estragar, você tem que levá-lo para oficina. Se você bater o carro,
mesmo que tenha seguro, você assume o custo da franquia do seguro. Mas se você
usa um serviço de taxi, você só paga pelo uso do serviço, você não assume os riscos
e custos da operação. A mesma coisa acontece se você usar serviços de provedor de
serviços de TI. Se você quiser hospedar o site da sua empresa em um provedor de
hospedagem, você paga pelo serviço, você não arca com os custos da infraestrutura e
nem com os riscos da operação, como falha de energia, queda de link, etc. Esses
riscos precisarão ser tratados pelo provedor de serviços para que não se materializem
e gerem impacto para você como cliente. Isso não quer dizer que nunca um risco irá
ocorrer, mas sim que o tratamento destes riscos são de responsabilidades do provedor
de serviços.

Agora vamos ver a adaptação da definição de serviço para o nosso contexto de TI.

Serviço de TI
É um serviço fornecido por um provedor de serviços de TI. É composto de uma
combinação de tecnologia da informação, pessoas e processos.

23
Alguns exemplos de serviços de TI:

• Escritório: processamento de textos, planilhas eletrônicas, digitalização e

impressão de documentos.
• Comunicação: acesso à internet, acesso wireless, VoIP, e-mail, web
conferência.
• Vendas: CRM, emissão de nota fiscal eletrônica, gerenciamento de pedidos de
compra, e-commerce.
• Produção: gerenciamento de recursos da empresa (usando algum software
ERP, como o SAP).
• Manutenção: manutenção e suporte de computadores e impressoras.

Tipos de serviços de TI
Os serviços podem ser classificados em termos de como eles se relacionam entre si e
com seus clientes:

Serviços principais

• Entregam resultados desejados para um ou mais clientes.

• Representam o valor que o cliente quer e pelo qual ele está disposto a pagar.
• Sustentam a proposição de valor para o cliente e fornecem a base para sua
utilização contínua e para sua satisfação.
Serviços de apoio (ou secundários)

• São necessários para que um serviço principal seja entregue.

• Podem ou não ser visíveis para o cliente, mas o cliente não os percebe como
serviços de fato.
• São “fatores básicos” que possibilitam ao cliente receber o serviço principal
“real”.
Serviços intensificadores

• São adicionados a um serviço principal para torná-lo mais atraente ao cliente.

• Não são essenciais para a entrega de um serviço, porém são usados para
estimular os clientes a usar os serviços principais ou diferenciar o provedor de
serviços dos seus concorrentes.

24
A tabela abaixo apresenta alguns exemplos de serviço principal, de apoio e
intensificador:

Serviço Serviços de Serviços

Categoria
principal apoio intensificadores

Serviços de TI Processamento Download e Publicação de

(automação de de textos. instalação de documento para
escritório). atualizações. impressão
profissional de alta
qualidade.

Serviços de TI Funcionários Um portal web Clientes podem

(consulta de de uma que fornece uma criar e gerenciar um
benefícios). empresa interface programa de
podem amigável para o condicionamento
monitorar o usuário acessar físico ou de peso.
status de seus o serviço de Clientes que
benefícios (tais consulta de seus mostrarem seu
como plano de benefícios. progresso no
saúde e de programa são
aposentadoria). contemplados com
descontos nas
mensalidades.

Apesar de os serviços de apoio nem sempre serem visíveis ao cliente, eles são
importantes para a entrega do serviço principal. Além disto, é importante para o
provedor de serviços TI ter um mapeamento de todos estes serviços de apoio. Eles
precisam ser gerenciados adequadamente para que o serviço principal entregue os
resultados esperados pelo cliente. Mais adiante, no capítulo 5, será apresentado o
catálogo de serviços técnico no qual estes serviços de apoio podem ser vinculados ao
serviço principal.

Resultados
Vimos antes que serviços são oferecidos para facilitar os resultados que os clientes
querem alcançar. Os resultados que os clientes querem alcançar são a razão para
comprar ou utilizar um serviço. O valor do serviço para o cliente é diretamente
dependente da forma como ele facilita esses resultados. Veja abaixo uma definição
para resultados:

Resultados
Este termo é aqui usado para se referir tanto aos resultados pretendidos como aos
resultados realmente obtidos.

25
Veja alguns exemplos de resultados de negócio que podem ser facilitados com algum
serviço de TI:

• O departamento de vendas processa um pedido de venda.

• O salário de um funcionário é pago.

• Um vendedor pode obter informações sobre um cliente para identificar

oportunidades.

• Um passageiro faz uma reserva e emite o bilhete de embarque.

Podemos também dizer que os resultados estão associados aos objetivos de negócio
a serem alcançados por uma organização.

Gerenciamento de serviços
O gerenciamento de serviços é que possibilita a um provedor de serviços entender os
serviços que estão sendo fornecidos, assegurar que os serviços realmente facilitam os
resultados que seus clientes querem alcançar, entender o valor dos serviços para os
seus clientes e entender como gerenciar todos os custos e riscos associados com
estes serviços.

Gerenciamento de serviços
É um conjunto especializado de habilidades organizacionais para fornecer valor para o
cliente em forma de serviços.

Estas habilidades organizacionais incluem práticas de gerenciamento, processos,

funções, papéis, conhecimento e competências que um provedor de serviços usa para
possibilitar a entrega de serviços que criem valor para seus clientes.

Agora vamos ver como a ITIL descreve este gerenciamento para a TI.

Gerenciamento de serviços de TI
É a implementação e o gerenciamento da qualidade dos serviços de TI de forma a
atender às necessidades de negócio.

O gerenciamento de serviços de TI é feito pelos provedores de serviços de TI por meio

da combinação adequada de pessoas, processos e tecnologia da informação.

26
O ato de transformar recursos em serviços de valor explorando as habilidades da
organização é o coração do gerenciamento de serviços de TI. Sem as habilidades, a
organização de serviço é meramente um conjunto de recursos inúteis. É isso que está
sendo demostrado na figura abaixo.

Recurso é um termo genérico que pode se referir à informação, aplicativos,

infraestrutura, capital, pessoas (no sentido de pessoas em quantidade) ou qualquer
coisa que pode ajudar na entrega de serviços. Recursos são sempre algo físico,
tangível. Já as habilidades são intangíveis, como gerenciamento, organização,
processos, conhecimento e pessoas (no sentido de pessoas com capacitação). As
habilidades vão ajudar na realização das atividades fazendo o melhor uso dos
recursos que a TI dispõe. Iremos desenvolver melhor este entendimento de recursos e
habilidades no capítulo 4.

O gerenciamento de serviços hoje é uma disciplina madura suportada por

conhecimento, experiência e habilidades. O gerenciamento de serviços era uma
preocupação básica de empresas de outros setores, como hotéis, transportadores
aéreos, bancos, restaurantes, lavanderias, etc., onde o negócio já sabia que o seu
principal foco era fornecer serviços ao cliente. Pessoas que trabalham nestes ramos
têm uma perspectiva diferente sobre o cliente. Não se pode dizer o mesmo para a
maioria dos provedores de TI – o pessoal de TI está passando por uma mudança
drástica de postura: por muitos anos eles se preocuparam em apenas dominar a
tecnologia, mas ao longo do tempo percebeu-se que a função de TI não era apenas
fornecer tecnologia. Ter a última tecnologia disponível não é sinônimo de
disponibilidade e de bom serviço. Além de ter a tecnologia, é preciso adicionar outros
ingredientes para que se possa entregar um bom serviço ao cliente.

27
Provedor de serviços de TI
Toda organização de TI deve atuar como um provedor de serviços, utilizando os
princípios de gerenciamento de serviços para garantir que ela entrega os resultados
exigidos pelos seus clientes.

Provedor de serviços de TI
É um provedor de serviços que fornece serviços de TI para clientes internos ou
externos.

De forma geral, qualquer departamento de TI de uma empresa pode ser considerado

um provedor de serviços de TI.

A ITIL descreve três tipos básicos de provedores de serviços de TI:

Tipo I - Provedor de serviços internos

Fica localizado internamente em uma unidade (departamento ou filial) de negócio.
Pode haver vários dentro de uma organização. Por exemplo, imagine uma grande
empresa que tem algumas filiais espalhadas no Brasil e que dentro de cada filial existe
uma área de TI local.

Empresa

Unidade A Unidade B Unidade C

TI TI TI

Tipo II - Unidade de serviços compartilhados

Fornece serviços de TI compartilhados para mais de uma unidade (departamento ou
filial) de negócio. Em vez de ter uma área de TI para cada filial ou departamento do
negócio, há uma única área de TI compartilhada fornecendo serviços para as unidades
de negócio.

28
Tipo III - Provedor de serviços externos
Fornece serviços de TI para clientes externos (fora da organização). Por exemplo, a
IBM fornece diversos serviços de TI para várias outras empresas no mercado. Nesta
figura abaixo, uma empresa poderia utilizar vários serviços (como CRM, folha de
pagamento, Voip) que são providos por provedores de serviços externos (no caso, por
outras empresas de TI especializadas).

É importante considerar que uma empresa pode usar mais de um tipo de provedor de
serviço (ela pode ter uma combinação deles).

Parte interessada (stakeholder)

É uma pessoa que tem um interesse em uma organização, um projeto, um serviço de
TI, etc. Ela pode estar interessada nas atividades, metas, recursos ou entregas.
Existem muitas partes interessadas envolvidas no gerenciamento de serviços:

29
Há uma diferença entre clientes que trabalham na mesma organização que o provedor
de TI e clientes que trabalham em outras organizações. A distinção é a seguinte:

• Clientes internos: são aqueles que trabalham para o mesmo negócio do

provedor de serviços de TI. Por exemplo: o departamento de marketing é um
cliente interno da organização de TI porque usa serviços de TI. Se o provedor
de serviços de TI realizar cobranças para estes serviços, o dinheiro pago é
uma transação interna no sistema de contabilidade da organização (não existe
uma receita real).

o Clientes internos usam serviços internos fornecidos por um provedor de

serviços internos ou compartilhados.

• Clientes externos: são aqueles que trabalham para um negócio diferente do

provedor de serviços de TI. Por exemplo: a empresa X contrata um serviço de
Voip do provedor Y. Clientes externos tipicamente compram serviços de um
provedor de serviços de TI externo por meio de um contrato ou acordo legal.

o Clientes externos usam serviços externos fornecidos por um provedor

de serviços externos (providos por outra organização).

Um provedor de serviços de TI pode oferecer serviços tanto para clientes internos

como externos conforme ilustrado na figura abaixo:

30
Ativos de serviço
Para criar valor em forma de bens ou serviços, um provedor de serviços precisa de
ativos de serviço.

Ativo de serviço
É qualquer recurso ou habilidade usada pelo provedor de serviços para entregar
serviços a um cliente.

A figura abaixo mostra os ativos de serviço sendo utilizados pelo provedor de serviços
para entregar serviços aos seus clientes.

Existem dois tipos de ativos de serviço: recursos e

habilidades.

• Recursos é um termo genérico que inclui

capital financeiro, infraestrutura, aplicativos,
informação e pessoas. Os recursos são
necessários para a produção de um bem ou
fornecimento de um serviço e podem ser
adquiridos facilmente em relação às
habilidades.

• Habilidades referem-se a gerenciamento,

organização, processos, conhecimento e
pessoas. São ativos intangíveis usados para
transformar recursos em serviços.

31
Utilidade e garantia
Para que um serviço possa entregar valor para os clientes, dois elementos devem ser
considerados em conjunto: utilidade e garantia.

Veja abaixo a definição destes dois termos.

Utilidade é a funcionalidade oferecida por um produto ou serviço para atender a uma

necessidade particular.

Garantia é a confiança de que um produto ou serviço atenderá aos requisitos

acordados. Isso pode ser feito por meio de um acordo formal, como um acordo de
nível de serviço ou contrato, ou pode ser uma mensagem de marketing ou imagem de
uma marca.

A tabela a seguir mostra as diferenças entre os dois elementos:

Utilidade Garantia

Foco no que o serviço faz? Foco em como o serviço faz isto bem?

Refere-se a requisitos funcionais do

Refere-se a requisitos não funcionais.
serviço.

Cobre aspectos de garantia como

Pode descrever características,
Disponibilidade, Capacidade,
entradas, saídas geradas pelo serviço.
Continuidade, Segurança.

Significa “apto para o propósito”. Significa “apto para o uso”.

A utilidade é aquilo que o cliente recebe, e a garantia vai dar sustentação para o que
está sendo entregue. A criação de valor é a combinação dos efeitos de utilidade e
garantia. Ambos são necessários para a criação de valor para o cliente.

32
Abaixo você visualiza uma figura mostrando os dois elementos juntos criando valor
para o serviço.

Imagine um serviço de faturamento que roda a partir de um aplicativo ERP que é

usado pelo departamento financeiro de uma empresa. O valor não será gerado apenas
a partir das funcionalidades deste sistema, como os processos de contas a pagar e de
contas a receber: para que o serviço gere valor ele precisa estar disponível sempre
que o usuário precisar acessá-lo. Inclui também ter a capacidade de processar e
armazenar os dados necessários, e um plano de continuidade para evitar uma
interrupção maior no negócio. E também muito importante: garantir a integridade dos
dados. Então veja que a criação de valor apenas dar-se-á com os efeitos de utilidade e
garantia. Ambos são necessários.

Gerenciamento de riscos
Para entregar serviços com qualidade é importante que o provedor de serviços
considere os riscos. Avaliação de riscos e gerenciamento de riscos podem ser
aplicados para identificar e mitigar riscos dentro de qualquer parte do ciclo de vida do
serviço.

Definição de risco
Risco
É um evento possível que pode causar perdas ou danos, ou afetar a habilidade de
atingir os objetivos.

33
Um risco é calculado pela probabilidade de uma determinada ameaça ocorrer, pela
vulnerabilidade do ativo relacionado à ameaça e pelo impacto gerado caso a ameaça
ocorra.

Uma ameaça é qualquer coisa que pode explorar uma vulnerabilidade.

Uma vulnerabilidade é um ponto fraco que pode ser explorado por uma ameaça.

Uma contramedida é uma ação implementada para eliminar vulnerabilidades e

minimizar o impacto de riscos.

Exemplo: a porta do firewall aberta é uma vulnerabilidade e a ameaça é um hacker

invadir a rede. O risco seria o hacker conseguir invadir o sistema e obter dados
confidenciais da empresa. Uma contramedida poder ser fechar esta porta do firewall e
implementar um sistema de detecção de intrusos.

Estrutura (framework) para lidar com riscos

Para lidar com os riscos, o provedor de serviços pode implementar um framework
considerando dois aspectos: avaliação de riscos e gerenciamento de riscos.

Avaliação de riscos

Inclui coletar informações sobre a exposição a riscos para que o provedor de serviços
possa fazer uma avaliação de riscos, tomar decisões apropriadas e acompanhar o
tratamento dos riscos.

Inclui também analisar o valor dos ativos, identificar as ameaças a estes ativos e
avaliar o quanto cada ativo está vulnerável às ameaças.

Gerenciamento de riscos

Ter processos para monitorar os riscos, obter informações atualizadas e confiáveis

sobre os riscos, definir respostas para lidar com os riscos e processo para revisão.

34
A figura abaixo ilustra uma estrutura ideal de passos para o gerenciamento de riscos:

Usa-se esta abordagem de gerenciamento de riscos em todo o ciclo de vida do

serviço. É natural que o gerenciamento de riscos tenha uma ênfase no estágio
estratégia de serviço, pois é neste estágio que há a concepção do serviço, onde ainda
não se tem domínio real se a estratégia vai de fato se concretizar. Entretanto, nos
estágios de desenho e principalmente no de transição também há necessidade de
gerenciar os riscos envolvidos.

Vejamos algumas razões para se ter um gerenciamento de riscos na organização:

• Ao adotar uma nova tecnologia que não se conhece é preciso obter o máximo
de benefícios pelo seu uso
• Adaptar-se às mudanças do mercado para atender a necessidades dos
clientes
• Manter a continuidade dos serviços de TI mesmo que aconteça alguma
adversidade, como por exemplo a falência de um fornecedor, falhas de
segurança ou desastre natural

35
 • Gerenciar mudanças externas, como cultura e políticas. Um serviço pode ser
desenvolvido e não ser utilizado pela organização por infringir uma política da
organização – isto é risco
• Minimizar impactos que a organização possa ter no mercado devido a alguma
falha no serviço
• Demonstrar conformidade com leis e requisitos regulatórios: SOX, ISO 27001,
requisitos do Banco Central, SUSEP, entre outros. Dependendo do tipo de
organização, ela pode estar submissa a várias leis, e a TI precisa ter seus
serviços adequados a essas normas para a que a empresa esteja em
conformidade

Governança
Uma grande preocupação ao desenvolver novos serviços e implementar processos de
TI é se estes vão de fato atender às necessidades do negócio e vão habilitar o negócio
a realizar seus objetivos estratégicos.

Para dar direcionamento para a estratégia de serviço e avaliar os resultados gerados

pela TI, surgiu uma nova abordagem de gestão no mercado que é a Governança – a
única área abrangente que une TI e o negócio, pois ela define as orientações comuns
e políticas e regras que o negócio e a TI usam para realizar negócios. Estas definições
são feitas por um conselho de administração ou partes interessadas.

Governança
Consiste em garantir que políticas e estratégia sejam realmente implementadas e que
os processos requeridos estejam sendo corretamente seguidos. Governança inclui
definir papéis e responsabilidades, medir e relatar, e tomar as ações para resolver
quaisquer questões identificadas.

A governança define direções, políticas e regras que deverão ser seguidas pelas
unidades de negócio assim como pela TI. Estas definições são feitas por um conselho
de administração ou partes interessadas.

De acordo com a norma ISO/IEC 38500, a governança de TI precisa ser capaz de

dirigir, avaliar e monitorar as estratégias, políticas e planos estabelecidos para a TI.

36
Na figura abaixo, temos os 3 pilares na governança.

O primeiro pilar é DIRIGIR, formado pela estrutura de governança, envolvendo o

pessoal da alta administração da empresa e também os gestores de TI. Aqui são
tomadas decisões e são estabelecidos planos e políticas.

O segundo pilar é AVALIAR, formado pelos resultados obtidos com a implantação dos
planos, regras e políticas do primeiro pilar.

O terceiro pilar é MONITORAR, formado pelos dados de monitoração do desempenho

dos serviços colocados em produção.

37
2.2 Conceitos relacionados a processos e funções
Processos, funções e papéis são habilidades-chave no gerenciamento de serviços de
uma organização.

Definições - processos e funções

No gerenciamento de serviços de TI existem várias atividades de gerenciamento de
serviços. A ITIL agrupa estas atividades em processos. Os processos estão
distribuídos ao longo do ciclo de vida do serviço, onde vamos encontrar também
funções (grupos de pessoas) que realizam atividades nos processos.

Processo
Processo é um conjunto estruturado de atividades elaborado para alcançar um
determinado objetivo. Um processo utiliza uma ou mais entradas definidas e as
transforma em saídas definidas.

Um processo pode ser composto por vários elementos. Basicamente todo processo
tem uma entrada e atividades que vão utilizar esta entrada para produzir uma saída. A
figura abaixo ilustra a estrutura de um processo simples:

38
Entretanto, a ITIL descreve vários outros elementos que podem compor um processo.
Estes elementos deveriam ser observados ao desenhar novos processos ou melhorar
processos já existentes. Veja abaixo todos os elementos que compõem um processo:

Um processo é organizado em torno de um conjunto de objetivos. As principais saídas

a partir de um processo devem ser guiadas por estes objetivos e devem incluir formas
de medição (métricas), relatórios e melhorias de processo.

A saída produzida por um processo precisa estar em conformidade como padrões

operacionais que são derivados a partir dos objetivos do negócio. Se o produto está
em conformidade com os padrões da organização, o processo pode ser considerado
eficaz (porque ele pode ser repetido, medido, gerenciado e alcança o resultado
requerido). Se as atividades do processo são realizadas com um mínimo de recursos,
o processo pode ser considerado eficiente.

Entradas são dados ou informações usadas pelo processo e podem ser uma saída
para outro processo.

Um processo ou atividade dentro de um processo é iniciada(o) por um gatilho. Um

gatilho pode ser a chegada de uma entrada ou outro evento. Por exemplo, o processo
gerenciamento de incidente pode ser disparado de diversas formas. O usuário pode
ligar para a central de serviço ou pode registrar o incidente a partir de uma interface
web. No caso do processo de gerenciamento de incidente, a entrada é o incidente e o
gatilho é a chamada na central de serviço.

Um processo pode ter papéis, responsabilidades, ferramentas e controles gerenciais

requeridos para entregar as saídas de forma confiável. Um processo pode definir

39
políticas, padrões, orientações, atividades e instruções de trabalho se eles forem
necessárias.

Processos, uma vez definidos, podem ser documentados e controlados. Uma vez sob
controle, eles podem ser repetidos e gerenciados. A medição de processo e métricas
podem ser embutidas dentro do processo para controlar e melhorar o processo. A
análise de processo, resultados e métricas podem ser incorporados nos relatórios
gerenciais.

Um processo também tem habilitadores que incluem recursos (capital, infraestrutura,

aplicativos, informação e pessoas) e habilidades (gerenciamento, organização,
processos, conhecimento e pessoas).

Onde encontramos os processos?

Muitas empresas são organizadas de forma hierárquica. Elas podem ter vários
departamentos e em cada departamento há um grupo de especialistas em
determinados assuntos. Existem muitas formas de estruturas de departamentos: eles
podem ser agrupados por cliente, por produto, por região ou por área de
conhecimento. O problema da departamentalização é que se criam silos dentro da
organização, sem comunicação adequada entre os departamentos e sem uma visão
única para atender ao cliente. Muitas vezes o departamento foca mais na sua função
de tecnologia que no desenvolvimento da solução orientada ao cliente. As pessoas
que estão dentro do departamento trabalham para atender aos interesses do seu
gerente ao invés de atender aos interesses dos clientes da TI. Desta forma criam-se
os feudos na organização (veja figura na próxima página).

A abordagem de processos da ITIL ultrapassa a estrutura hierárquica de

departamentos. Vejamos por exemplo um processo de gerenciamento de incidente.
Este processo pode iniciar a partir de uma chamada do usuário à central de serviço,
que por sua vez pode escalar o incidente para outros departamentos (grupos) devido
ao grau de conhecimento exigido para resolver a questão.

40
Um processo de TI tem várias atividades e pode ter papéis desempenhados por
pessoas que estão em departamentos diferentes. A estrutura departamental serve
apenas para agrupar as pessoas, e não é necessário mudarmos esta estrutura para
implantarmos um processo de gerenciamento de incidente ou qualquer outro processo
da ITIL. A estrutura baseada em processos faz o vínculo entre os departamentos e
estabelece um fluxo de trabalho e comunicação entre áreas, evitando assim a criação
de silos.

Uma organização que apenas possui departamentos e não tem processos

estabelecidos entre estes departamentos pode ter vários problemas:

• Os departamentos não se comunicam.

• Cada gerente quer ser rei em seu feudo – há uma competição muito grande
por poder; há conflitos de interesses entre os gerentes de departamentos.
• Quando o cliente precisa de uma solução, demora-se muito para se dar uma
resposta. Muitas vezes a solução depende de várias pessoas que estão em
departamentos diferentes, mas pelo fato que elas terem que cumprir metas
estabelecidas pelos seus gerentes o problema do cliente é colocado como
prioridade secundária.

Quando se implementam os processos de gerenciamento de serviços na organização,

teremos uma TI focada em atender às necessidades dos clientes. São estabelecidos
objetivos e metas comuns para todos os departamentos. Com isso a comunicação
entre os departamentos melhora e eliminam-se os conflitos de interesses entre os
departamentos. A ITIL ajuda a criar uma TI com a missão de ser um provedor de
serviços aos clientes e não meramente uma área que desenvolve tecnologia.

Características de processos

A ITIL traz 4 características essenciais para processos:

• Geram resultados específicos. Um processo existe para entregar um

resultado específico. Este resultado precisa ser individualmente identificável e
mensurável.

• São orientados a clientes. Cada processo entrega seus resultados primários

para um cliente ou parte interessada.

• São mensuráveis. Precisamos ser capazes de medir o processo de uma

maneira adequada. O processo precisa ter um bom desempenho. Podemos
medir custo, qualidade, duração, produtividade, etc.

• Respondem a gatilhos (eventos) específicos. Como um processo é iniciado?

Qual o evento que dispara o processo?

41
Eficiência x Eficácia

No gerenciamento de serviços, além de buscar gerar valor ao cliente, deve-se buscar

a eficiência e a eficácia nos processos. Eficiência e eficácia são dois conceitos
diferentes, porém muito relacionados (por isso algumas vezes ocorre confusão no
entendimento e na diferenciação dos mesmos).

Eficiência é uma medida para identificar se a quantidade correta de recursos foi

usada para a entrega de um processo, serviço ou atividade. Um processo eficiente
alcança seus objetivos com a quantidade mínima necessária de tempo, dinheiro,
pessoas ou outros recursos.

Eficácia é uma medida para identificar se os objetivos de um processo, serviço ou

atividade foram atingidos. Um processo ou atividade é eficaz quando atinge os seus
objetivos acordados.

Para entender estes dois termos, imagine a seguinte situação: acordamos com nosso
cliente que vamos atender a 100% dos incidentes dentro do prazo estabelecido. Para
que isto ocorra, consideramos que o número de atendentes na central de serviço não
é adequado para o volume de incidentes atual – seria necessário dobrar a quantidade
de atendentes para que o tempo de resolução acordado fosse atendido. Dobrar a
quantidade de atendentes seria uma ação eficaz, pois conseguiríamos cumprir a meta
de atender a todos os incidentes no prazo acordado. Entretanto, o custo operacional
dobraria com mais atendentes no suporte. Nós seríamos eficazes, mas não eficientes.
Para sermos eficientes teríamos que de alguma forma fazer o uso otimizado dos
recursos que já temos. Isto poderia ser alcançado se os atendentes fossem bem
treinados e as ferramentas de suporte fossem melhores. Talvez com estas iniciativas
não fosse necessário dobrar a quantidade de atendentes no suporte.

Definições - funções
Função é uma equipe ou grupo de pessoas que são utilizadas para conduzir um ou
mais processos ou atividades, como por exemplo a central de serviços.

Função é o termo que a ITIL utiliza para se referir a uma unidade/departamento/grupo

da TI que é especializado em determinados assuntos. A ITIL descreve as 4 funções
comuns – entretanto na sua organização elas podem estar quebradas em vários
departamentos/grupos, e em organizações menores é possível que uma pessoa atue
em mais de uma função.

42
Existem quatro funções comuns descritas pela ITIL:

Processos x Funções
Profissionais de determinadas funções (grupos/departamentos) podem executar
atividades nos processos de gerenciamento de serviços. Por exemplo, para resolver
uma falha em um servidor de um aplicativo (no caso, um incidente), podem ser
envolvidas pessoas de diversas funções nas atividades do processo de gerenciamento
de incidente.

43
2.3 Papéis genéricos
Papéis genéricos no gerenciamento de serviços
Para que um processo tenha sucesso na organização, é preciso definir claramente os
papéis e responsabilidades necessários para realizar as atividades envolvidas nos
processos.

Papel é um conjunto de responsabilidades, atividades e autorizações concedidas a

uma pessoa ou equipe. Um papel é definido em um processo ou função. Uma pessoa
ou equipe pode ter vários papéis (por exemplo, os papéis de gerente da configuração
e gerente de mudança podem ser executados por uma única pessoa).

A ITIL descreve papéis genéricos que auxiliam no fornecimento de serviços de

qualidade:

• Dono de processo
• Gerente de processo
• Profissional de processo
• Dono de serviço

44
O diagrama a seguir mostra qual é o envolvimento dos donos de processos e donos
de serviços:

Dono de processo
O dono de processo é responsável por assegurar que um processo
está apto para seu propósito. Este papel é frequentemente atribuído a
uma mesma pessoa que exerce o papel de gerente de processo, mas
estes dois papéis podem ser separados em organizações maiores. O
papel de dono do processo é responsável por assegurar que o
processo é realizado de acordo com um padrão acordado e
documentado e que atende aos objetivos do processo definido.

Principais responsabilidades do dono de processo:

▪ Patrocina o processo
▪ Define a estratégia do processo
▪ Assiste o desenho do processo
▪ Assegura que a documentação do processo está disponível e atualizada
▪ Define políticas e padrões para serem empregados no processo
▪ Audita periodicamente o processo
▪ Comunica informações ou alterações no processo
▪ Fornece recursos para suportar as atividades
▪ Assegura que o pessoal está capacitado para seus papéis no processo
▪ Identifica, realiza e revisa melhorias no processo.

45
Gerente de processo
É responsável pelo gerenciamento operacional de um processo.
Podem existir vários gerentes de processo para o mesmo processo na
organização (exemplo: gerente de mudança regional ou gerente de
continuidade do serviço de TI para cada data center. Este papel pode
ser atribuído a quem já assume o papel de dono de processo).

Principais responsabilidades do gerente de processo:

▪ Trabalha com o dono do processo para planejar e coordenar todas as

atividades do processo
▪ Assegura que todas as atividades são realizadas conforme requeridas
▪ Designa pessoas para papéis requeridos
▪ Gerencia recursos atribuídos ao processo
▪ Trabalha com os donos de serviço e outros gerentes de processo para
assegurar o fornecimento ininterrupto dos serviços
▪ Monitora e reporta o desempenho do processo e identifica oportunidades de
melhoria
▪ Realiza melhorias na implementação do processo

Profissional de processo (practitioner em inglês)

É responsável pela realização de uma ou mais atividades do
processo. Em algumas organizações e para alguns processos,
este papel pode ser combinado com o papel de gerente de
processo; em outras, existem um grande número de
profissionais realizando diferentes atividades no processo.

Principais responsabilidades do profissional de processo:

▪ Realiza uma ou mais atividades de um processo

▪ Entende de forma geral como seu papel contribui para a entrega de serviço e
criação de valor para o negócio
▪ Trabalha com outras partes interessadas, tais como seus gerentes, colegas de
trabalho, usuários e clientes, para assegurar que suas contribuições são
eficazes
▪ Assegura que entradas, saídas e interfaces para suas atividades estão corretas
▪ Cria e atualiza registros para mostrar que as atividades estão sendo realizadas
corretamente

46
Dono de serviço
O dono de serviço é responsável pela entrega de um serviço
específico. Para o cliente, ele é responsável pela iniciação,
transição, manutenção em produção e suporte de um serviço
particular. O dono de serviço assegura que o serviço é
gerenciado com foco no negócio – a definição de um dono único
de responsabilidade é absolutamente essencial para fornecer o
nível de atenção e foco necessário para sua entrega. É ele
quem presta contas ao diretor de TI sobre a entrega de um
serviço.

É possível que uma única pessoa possa assumir o papel de

dono de serviço para mais de um serviço.

Principais responsabilidades do dono de serviço:

▪ Representar o serviço em toda a organização

▪ Entender o serviço e seus componentes
▪ Trabalhar com o gerente de contas para entender e traduzir os requisitos do
cliente em atividades
▪ Assegurar comunicação apropriada e consistente com o cliente para questões
e solicitações relacionadas ao serviço
▪ Assegurar a entrega contínua do serviço e que o suporte atenda aos requisitos
do cliente
▪ Participar da negociação de acordos de nível de serviço (ANSs)
▪ Representar o serviço nas reuniões do comitê consultivo de mudanças (CCM)
▪ Interagir com os donos de processos durante o ciclo de vida do serviço
▪ Participar de reuniões internas de revisões de serviço com a TI e de reuniões
de revisões com o negócio
▪ Identificar e fazer melhorias no serviço
▪ Prestar contas pela entrega do serviço

Para cada serviço deve haver um dono. Isso não significa que cada serviço terá o
mesmo dono nem que uma mesma pessoa não possa ser dona de mais de um
serviço.

47
Considerações sobre papéis
Em uma organização pequena, os papéis podem ser combinados. Por exemplo, a
mesma pessoa pode assumir o papel de gerente do processo de capacidade e do
processo de continuidade do serviço de TI. Em grandes organizações, diferentes
pessoas realizam cada um destes papéis.

Somente deve existir um único dono de processo para cada processo e um único dono
de serviço para cada serviço.

Papel x Cargo
Papéis são frequentemente confundidos com cargos, mas é importante perceber que
eles não são a mesma coisa. Cada organização irá definir os cargos para a área de TI
conforme suas necessidades. Uma pessoa pode ocupar determinado cargo por
assumir um ou mais papéis no ciclo de vida do serviço.

Por exemplo, uma pessoa que tem o cargo de administrador de redes no momento em
que está resolvendo uma indisponibilidade na rede está participando de atividades do
processo de gerenciamento de incidente. Quando este administrador de redes está
planejando a capacidade dos servidores para o próximo ano, está fazendo uma
atividade do processo de gerenciamento de capacidade.

48
2.4 Matriz de atribuição de responsabilidades - RPCI
Matriz de atribuição de responsabilidades - RPCI
Ao desenhar um serviço ou um processo, é importante que todos os papéis estejam
claramente definidos. Para que serviços, processos e suas atividades sejam
executados corretamente na organização, as atividades precisam ser claramente
mapeadas para papéis definidos.

Para ajudar nisto, existe a matriz de atribuição de responsabilidades conhecida pela

sigla RPCI (ou RACI em inglês). Esta matriz estabelece quatro principais atribuições
em relação a processos e atividades:

• Responsável (Responsible)
• Prestador de contas (Accountable)
• Consultado (Consulted)
• Informado (Informed)
Responsável é a pessoa ou grupo responsável pela execução, por realizar o trabalho
na atividade do processo.

Prestador de contas é a pessoa que responde (assume a propriedade) pela

qualidade e pelo resultado final. Somente uma pessoa pode ser prestador de contas
por atividade.

Consultado é a pessoa que precisa ser consultada em alguma atividade. Esta pessoa
fornece informações para tomada de decisões.

Informado é a pessoa que precisa ser mantida atualizada em relação ao progresso de

alguma coisa. Esta pessoa recebe informações sobre a execução do processo.

49
Exemplo de matriz RPCI para o processo gerenciamento de incidente:

A matriz RPCI é uma das principais ferramentas usadas no mapeamento ou na

definição de processos. Adotando-a fica claro na organização quem é o responsável
pelo processo e quem são os demais envolvidos nas atividades do processo.

Passos para elaborar uma matriz RPCI:

1. Identifique as atividades nos processos

2. Identifique ou estabeleça os papéis dos envolvidos nas atividades
3. Realize reuniões e atribua responsabilidades para cada atividade
4. Identifique sobreposições (exemplos: 2 Rs ou nenhum P para as atividades)
5. Distribua a matriz para os envolvidos e incorpore sugestões recebidas
6. Assegure-se de que a matriz está sendo seguida dia a dia

Possíveis problemas que você vai encontrar ao criar a matriz RPCI:

▪ Mais de uma pessoa prestando contas para a mesma atividade (2 Ps) – só

deve haver um P para cada atividade
▪ Atribuição de responsabilidade sem autoridade necessária
▪ Focar em combinar processos e atividades com departamentos
▪ Distribuição de funções conflitando agendas e metas

50
2.5 Competências e habilidades
Competências e treinamento
A entrega de serviço com sucesso depende de pessoal envolvido no gerenciamento
de serviços tendo formação, treinamento, habilidades e experiência adequados.

As pessoas precisam entender seus papéis e como elas podem contribuir para a
organização, serviços e processos serem mais eficazes e eficientes.

É importante que as pessoas, ao assumirem seus papéis no gerenciamento de

serviços, tenham os seguintes atributos genéricos:

• Consciência de prioridades, objetivos e motivadores do negócio

• Consciência do papel da TI para suportar os objetivos do negócio
• Habilidades para atendimento ao cliente
• Consciência do que a TI pode entregar ao negócio
• Competência, conhecimento e informação necessários para desempenhar
seus papéis
• Habilidades para usar, entender e interpretar as melhores práticas, políticas e
procedimentos para assegurar a sua aderência

Framework (estrutura) para competência e habilidades

Muitos provedores de serviços usam um framework
(estrutura) de referência para competências e habilidades
para suportar atividades tais como habilidades de auditoria,
planejamento de requisitos de habilidades para o futuro,
programa de desenvolvimento organizacional e alocação de
recursos.

O Framework de Habilidades para a Era da Informação

(Skills Framework for the Information Age - SFIA) é um
exemplo de modelo de referência comum para a
identificação de habilidades necessárias para desenvolver
serviços de TI eficazes, sistemas de informação e
tecnologia.

O SFIA define sete níveis genéricos para os quais tarefas

precisam ser realizadas, com habilidades necessárias
associadas para cada nível, e é usado por muitos
provedores de TI para identificar oportunidades de
desenvolvimento de carreira.

Para mais informações, consulte www.sfia.org.uk

51
Adoção de ferramentas para automação de serviços
Automação de serviços
A automação pode impactar significativamente os ativos de
serviço, tais como gerenciamento, organização, pessoas,
processos, conhecimento e informação.

Por meio da automação, a utilidade e a garantia dos serviços

podem ser melhoradas. Ela oferece vantagens em muitas áreas:

▪ A capacidade de recursos automatizados pode ser facilmente ajustada em

resposta a variações no volume de demanda
▪ Recursos automatizados podem lidar com a capacidade com menos restrições
no tempo de acesso
▪ Sistemas automatizados representam uma boa base para medição e melhoria
de processos
▪ Muitos problemas de otimização, como roteamento, agendamento e alocação
de recursos necessitam do poder da computação que está além da capacidade
dos agentes humanos
▪ Automação é um meio para capturar o conhecimento requerido para
um processo de serviço
Se a automação for bem implementada, ela pode ajudar a melhorar a qualidade dos
serviços e reduzir custos e riscos em áreas como:

▪ Desenho e modelagem
▪ Catálogo de serviço
▪ Reconhecimento e análise de padrões de demanda
▪ Classificação, priorização e roteamento
▪ Detecção e monitoração
▪ Otimização

Uso de ferramentas de gerenciamento de serviços

Existe um consenso de que as ferramentas de gerenciamento de serviços podem
ajudar a implantar os processos.

O uso de tecnologia para suportar os processos pode aumentar a eficiência dos

mesmos. Entretanto, é importante considerar:

▪ Processos ruins com ferramentas boas continuarão a ser processos ruins

(automação do caos)
▪ As ferramentas suportam os processos, não definem os processos – primeiro
vem o desenho do processo, depois a ferramenta
▪ Procure não modificar os processos para se adequarem às ferramentas
Diretório de ferramentas homologadas para a Estratégia de serviço:
https://www.pinkelephant.com/PinkVERIFY/

52
3 - Introdução ao ciclo de vida do serviço
3.1 Visão geral
O ciclo de vida do serviço é um modelo que fornece uma visão dos estágios do serviço
desde a sua concepção até a sua retirada.

É a forma como a abordagem de gerenciamento de serviços da ITIL está estruturada

atualmente (representa a melhor prática).

O ciclo de vida funciona também como se fosse uma “cola” entre as 5 publicações
principais.

O ciclo de vida do serviço é composto por 5 estágios (ou fases):

1. Estratégia de serviço
Desenvolve uma estratégia de TI alinhada com a do negócio. Identifica quais
serviços devem ser criados para atender às necessidades/demandas de
clientes/negócio.
2. Desenho de serviço
Projeta, desenvolve e levanta o que é necessário para oferecer o serviço
(solução).
3. Transição de serviço
Transfere o serviço novo ou alterado para o ambiente de produção de forma
controlada.
4. Operação de serviço
Mantém o serviço em um bom estado operacional. Inclui processos e
atividades de rotina.
5. Melhoria contínua de serviço (MCS)
Melhora serviço e processos para continuar gerando valor (benefícios) para o
cliente e para o negócio.

53
A ideia do ciclo de vida do serviço permite alinhar a TI com o negócio para:

• Converter conceitos e ideias inovadoras em serviços para os clientes. Isso quer

dizer que se a TI tem muitas demandas (o negócio pede muitos projetos para a
TI), ela vai ter que saber decidir o que deve ser transformado em serviço. O
desenvolvimento do serviço terá que ser feito de maneira controlada, passando
pelos estágios Estratégia, Desenho e Transição, e depois colocado em
Operação.
• Resolver problemas usando soluções efetivas e prolongadas. O feedback entre
os estágios permite identificar melhorias necessárias tanto para processos
como para serviços. A intenção é que todo o sistema tenha uma otimização ao
longo do tempo para obter melhores resultados.
• Controlar custos e riscos que podem potencialmente influenciar o valor criado.
Os riscos devem ser identificados já durante o estabelecimento da estratégia.
Isso é muito importante, pois nós sabemos que os projetos de TI normalmente
não cumprem os seus orçamentos justamente porque os riscos não são
gerenciados. Esta questão é um tanto preocupante, pois o pessoal de TI ainda
não tem a cultura de prever os riscos e fazer a gestão correta deles.
• Aprender com os sucessos e falhas para gerenciar desafios e ideias. Isso é a
melhoria contínua de serviço. Identifica-se o que não funciona e o que falhou
no processo, e propõe-se uma ação corretiva.

3.2 Introdução às publicações do ciclo de vida do

serviço
Estratégia de serviço
A criação de valor começa com o entendimento dos objetivos estratégicos da
organização e necessidades do cliente. É o eixo que move todo o ciclo.

Esta publicação:

▪ Fornece orientações sobre como ver o gerenciamento de serviços não apenas

como uma habilidade organizacional, mas como um ativo estratégico.
▪ Descreve princípios a serem usados para desenvolver políticas, objetivos,
diretrizes e processos que serão usados nos outros estágios do ciclo de vida.
▪ Inclui tópicos como entendimento de espaço de mercado, características de
provedores internos e externos, ativos de serviço, portfólio de serviços e
implementação da estratégia durante o ciclo de vida do serviço.
▪ Ajuda a identificar, selecionar e priorizar oportunidades.

54
Processos descritos no livro estratégia de serviço:

1. Gerenciamento estratégico para serviços de TI

2. Gerenciamento de portfólio de serviço
3. Gerenciamento financeiro para serviços de TI
4. Gerenciamento de demanda
1. Gerenciamento de relacionamento de negócio

Não faz parte do currículo do exame ITIL Foundation

Desenho de serviço
É o estágio que transforma a estratégia de serviço em um plano para realizar os
objetivos de negócio.

Esta publicação:

▪ Fornece orientações para o desenho e desenvolvimento de serviços e

processos de gerenciamento de serviços.
▪ Cobre princípios de desenho e métodos para converter os objetivos
estratégicos em portfólios de serviços e ativos de serviços.
▪ Também inclui mudanças e melhorias nos serviços já existentes para aumentar
ou manter o valor aos clientes (o escopo não é limitado a novos serviços).
Processos descritos neste livro:
COORDENA OS PROCESSOS DO ESTÁGIO PARA QUE OS ESTÁGIOS
1. Coordenação de desenho POSSAM SE CONVERSAR DE FORMA INTEGRADA.
2. Gerenciamento de nível de serviço GERENCIAR E ACORDAR METAS DE NIVEL DE SERVIÇO:EX:
DIPONIBILIDADE, SEGURANÇA, DESEMPENHO DE SERVIÇO
3. Gerenciamento de catálogo de serviço PARA DOCUMENTAR A LISTA DE SERVIÇOS
CONSIDERA OS ASPECTOS RELACIONADOS A DISPONIBILIDADE
4. Gerenciamento de disponibilidade DO SERVIÇO
REFERE-SE AOS ASPECTOS RELACIONADOS A INTEGRI
5. Gerenciamento de segurança da informação DADE DAS INFORMAÇÕES
6. Gerenciamento de fornecedor LISTA DE FORNECEDORES
7. Gerenciamento de capacidade CONSIDERA O DESEMPENHO, CAPACIDADE DOS RECURSOS
SE REFERE À PREVENÇÃO EM RELAÇÃO A
8. Gerenciamento de continuidade de serviço de TI DESASTRES QUE PODEM PARAR O SERVIÇO
Observação: a ITIL não descreve processos específicos para desenvolvimento de software.
Entretanto, no capítulo 5 do livro Desenho de Serviço há tópicos relacionados à engenharia
de requisitos, gerenciamento de dados e informação e gerenciamento de aplicativos.

55
Transição de serviço
É o estágio que constrói o pacote de liberação (release), testa e implanta um serviço
ou mudança no ambiente de produção.

Esta publicação:

▪ Fornece orientações para implantar serviços novos ou alterados no ambiente

de produção.
▪ Considera todos os elementos necessários para colocar (implantar) o serviço
em operação, incluindo elementos técnicos e não técnicos.
▪ Ajuda a controlar riscos e suportar o conhecimento organizacional.
▪ Contém orientações para assegurar que os valores identificados na Estratégia
de serviço e codificados no desenho são realizados na Operação de serviço.

Processos descritos neste livro:

1. Planejamento e suporte da transição PLANEJAR O QUE VAI INTRODUZIR, CONSIDERANDO RECURSOS

INVESTIMENTOS.
2. Gerenciamento de mudança CONTROLA O QUE VAI SER INTRODUZIDO PARA CONTROLAR OS RISCOS
3. Gerenciamento de configuração e ativo de serviço MAPEAMENTO DOS ATIVOS
4. Gerenciamento de liberação e implantação EXECUTA AS MUDANÇAS: INSTALAÇÃO E SOFTWARES,
ENSINAR USUÁRIOS
5. Validação e teste de serviço TESTES EM CONJUNTO COM O GERENCIAMENTO DE LIBERAÇÃO
PROCESSO DE APOIO QUE ABASTECE O GERENCIAMENTO DE MUDANÇAS COM
6. Avaliação de mudança INFORMAÇÕES
ALÉM DE MAPEAR AS INFORMAÇÕES RELACIONADAS À CONFIGURA
7. Gerenciamento de conhecimento ÇÃO, COMO QUALQUER INFORMAÇÃO AO LONGO DE VIDA DE SERVI-
ÇO
Não faz parte do currículo do exame ITIL Foundation

Operação de serviço
É o estágio em que o valor do serviço é realizado e a estratégia da organização é
executada de fato. Este estágio é importante para a melhoria contínua de serviço, pois
é quando os serviços são monitorados e melhorias são identificadas por meio de
medição e relatórios.

Esta publicação fornece orientações sobre:

▪ Como gerenciar os serviços no ambiente de produção.

▪ Como alcançar a eficácia e eficiência na entrega e suporte aos serviços para
assegurar o valor ao cliente, usuário e provedor de serviços.
▪ Como manter a estabilidade na Operação de serviço.
▪ Como aplicar processos, métodos e ferramentas para atuar de forma reativa e
proativa.

56
Processos descritos no livro operação de serviço:

1. Gerenciamento de evento DEPENDE DE FERRAMENTA DE MONITORAMENTOS

2. Gerenciamento de incidente RECUPERAR O SERVIÇO QUANDO ACONTECE UMA FALHA
3. Cumprimento de requisição ATENDER OUTRAS NECESSIDADES DO USUÁRIO
4. Gerenciamento de problema FAZER DIAGNÓSTICO DE SITUAÇÕES DESCONHECIDAS( DE CAUSA RAIZ
EX: RESETAR UM SERVIDOR
5. Gerenciamento de acesso CONTROLE DOS ACESSOS
Funções descritas neste livro:

1. Central de serviços
2. Gerenciamento técnico
3. Gerenciamento de operações de TI
4. Gerenciamento de aplicativos

Melhoria contínua de serviço (MCS)

Não deve ser vista como um estágio final do ciclo de vida do serviço. A MCS deve
estar integrada dentro de todos os estágios.

Esta publicação fornece orientações sobre:

▪ Como alcançar melhorias incrementais e de grande escala na qualidade do

serviço, eficiência operacional e continuidade do negócio.
▪ Melhores práticas para assegurar que o portfólio de serviço continue alinhado
com as necessidades de negócio.
▪ Princípios, práticas e métodos do gerenciamento da qualidade.
▪ Como fazer o vínculo entre os esforços de melhoria com Estratégia, Desenho,
Transição e Operação de serviço.
Processos descritos neste livro:

1. Processo de melhoria de sete etapas

57
Feedback contínuo
Esta figura apresenta as interfaces que temos entre os estágios do ciclo de vida.

Já sabemos que o padrão dominante no ciclo de vida é o progresso sequencial

começado pela estratégia de serviço, indo para o desenho do serviço, transição e
operação, e voltando para a estratégia através da melhoria contínua de serviço.

Entretanto, nesta nova abordagem esse não é o único padrão de relacionamento entre
os estágios. Existem várias interações entre os estágios deste ciclo.

Especialização e coordenação são necessárias nesta abordagem do ciclo de vida.

Cada estágio gera saídas que servem como entradas para os próximos estágios. O
feedback das lições aprendidas e o controle entre funções e processos por dentro e
por fora do ciclo de vida tornam isto possível. Assim pode-se saber, em qualquer
estágio do ciclo de vida do serviço, se as estratégias vão conseguir se realizar. Este
feedback é muito importante justamente porque tanto se fala que os projetos de TI
fracassam: durante todo o ciclo deve verificar-se se tudo está conforme a estratégia.
Isto evita surpresas e controla melhor os riscos e custos.

Outra coisa que precisamos saber é que a melhoria contínua de serviço não começa
somente após as operações. Essa melhoria ocorre em todo o ciclo de vida.

58
3.3 Apresentação dos processos da ITIL 2011
Mapa dos 26 processos e 4 funções da ITIL
Em cada estágio do ciclo de vida existem processos e funções que ajudarão a realizar
o propósito e os objetivos do estágio. Na figura abaixo você visualiza um mapa com os
principais processos e funções da ITIL edição 2011.

Para o nível ITIL Foundation, somente alguns processos foram selecionados para o
exame. Nesta apostila iremos explorar estes processos conforme a estrutura desse
syllabus (currículo). A partir dos próximos capítulos iremos detalhar os estágios do
ciclo de vida e os processos selecionados para o exame.

59
Atuação dos processos no ciclo de vida
Nesta figura abaixo observamos apenas os processos selecionados para o exame
Foundation associados a cores para demonstrar sua relação com os estágios do ciclo
de vida.

Por exemplo, o processo Gerenciamento da demanda faz parte do livro Estratégia de

serviço, mas ele não se envolve apenas no estágio Estratégia de serviço. Este
processo é acionado neste estágio, mas o estudo da demanda continua nos demais
estágios pois ela pode mudar ao longo do tempo.

60
4 - Estratégia de serviço
A estratégia de serviço é o primeiro estágio do ciclo de vida do serviço, e é o eixo
central que move todos os outros estágios. Tudo gira em torno desse estágio.

A ITIL ajuda a integrar a TI ao negócio de forma que cada um ressalte o que há de

melhor no outro. Isto assegura que cada elemento do ciclo de vida do serviço seja
focado em resultados para o cliente e se relacione com cada elemento do processo. A
ITIL foca muito o lado do cliente, mais do que a eficiência e a eficácia das operações
de TI. As ações de TI têm que ser direcionadas para que o serviço gere valor ao
cliente/negócio.

4.1 Propósito, objetivos, escopo e valor agregado ao

negócio
Propósito da estratégia de serviço
A Estratégia de serviço estabelece uma estratégia geral para serviços e para o
gerenciamento de serviços – não apenas como uma habilidade organizacional, mas
como um ativo estratégico.

O propósito da Estratégia de serviço é definir perspectiva, posição, planos e padrões

que um provedor de serviços precisa para executar algo a fim de atender aos
resultados de negócio de uma organização.

61
Objetivos da estratégia de serviço
Os objetivos da Estratégia de serviço incluem fornecer:

▪ Um entendimento do que é estratégia

▪ Uma clara identificação da definição dos serviços e dos clientes que os utilizam
▪ A habilidade de definir como o valor é criado e entregue
▪ Um meio de identificar oportunidades para fornecer serviços e como explorá-
los
▪ Um modelo claro de fornecimento de serviços que articula como os serviços
serão entregues e financiados, para quem eles serão entregues e com qual
propósito
▪ O meio de entender a habilidade organizacional para realizar a estratégia
▪ Documentar e coordenar como os ativos de serviço são usados para entregar
os serviços e como otimizar seu desempenho
▪ Fornecer processos que definam a estratégia da organização, quais serviços
serão obtidos com a estratégia, qual o nível de investimento necessário, em
que níveis de demanda e meios para assegurar uma relação de trabalho entre
o provedor de serviços e o cliente

Escopo da estratégia de serviço

Dois aspectos da estratégia são cobertos no livro de Estratégia de Serviços da ITIL:

• Definir uma estratégia em que o provedor de serviços irá entregar serviços que
atendam aos resultados de negócio do cliente

• Definir uma estratégia para a forma de gerenciar estes serviços

Valor que a estratégia de serviço agrega ao negócio

A adoção e a implementação das práticas para a Estratégia de serviço irão:

▪ Possibilitar ao provedor de serviços vincular suas atividades com os resultados

que são críticos para o cliente
▪ Possibilitar ao provedor de serviços ter um claro entendimento de quais tipos e
níveis de serviço irão satisfazer o cliente, e então organizar-se de forma
adequada para entregar e suportar estes serviços
▪ Possibilitar ao provedor de serviços responder de maneira rápida a mudanças
no ambiente de negócio
▪ Suportar a criação e manutenção do portfólio de serviços que habilitará o
negócio a alcançar um retorno positivo em seus investimentos em serviços
▪ Facilitar a comunicação funcional e transparente entre o cliente e o provedor
serviços

62
4.2 Conceitos e princípios-chave
Valor de serviço
O valor de um serviço advém daquilo que ele possibilita ao cliente. Com base nisto,
algumas principais características de valor de serviço são:

▪ O valor é definido pelo cliente

▪ Os clientes selecionam os serviços que representam a melhor composição
(mix) de funcionalidades (features) ao preço que eles estão dispostos a pagar
▪ Os clientes medem o valor do serviço em termos de como o serviço os ajuda a
alcançar seus objetivos
▪ O valor muda ao longo do tempo e de acordo com as circunstâncias
Lembre-se de que o cliente não adquire um serviço ou produto – ele adquire uma
solução para resolver necessidades específicas.

Para ajudar a avaliar o valor entregue pela TI por meio de serviços, algumas questões
podem servir como orientação:

▪ Quem são os nossos clientes?

▪ Qual é o negócio dos nossos clientes?
▪ Quais serviços de TI são oferecidos?
▪ Como os serviços de TI ajudam o negócio a obter seus
resultados desejados (realizar objetivos estratégicos)?
▪ O custo/preço destes serviços compensa os benefícios
(valor) obtidos?

63
Percepção de valor
O valor de um serviço é determinado pelo que o cliente prefere (preferências), o que o
cliente percebe (percepções) e o que o cliente de fato obtém (resultados de negócio).

O valor de um serviço pode ser algo subjetivo. Nem sempre um serviço é quantificado
através do valor financeiro. Existem outros aspectos não financeiros que podem ser
utilizados para valorizar um serviço, como sentimentos e a percepção do cliente. Por
exemplo, se pegarmos uma mesa velha, para uma pessoa aquilo pode ser uma peça
antiga, valiosa. Ela adoraria ter aquela mesa como objeto de decoração. Já para outra
pessoa uma mesa antiga não teria valor algum.

O valor é determinado pela percepção do cliente, sua preferência e resultados no

negócio. A percepção do cliente é influenciada pela:

• Experiência anterior
• Comparação com concorrentes
• Imagem em si

Os clientes também têm suas preferências, que podem ser baseadas em experiências
anteriores e impressões. Nem sempre as pessoas gostam da mesma cor e de fazer as
mesmas coisas, por exemplo. Por natureza somos diferentes e pensamos de forma
diferente.

E os resultados no negócio também orientam a perspectiva de valor. Um serviço

precisa facilitar os resultados que devem ser alcançados no processo do cliente.

Embora o provedor de serviços não tenha a possibilidade de decidir o valor de um

serviço, ele pode influenciar a percepção do cliente em relação ao valor do serviço. A
figura se seguir ilustra como os clientes percebem o valor de um serviço. O ponto
inicial para a percepção do cliente é o valor de referência. Este valor pode ser baseado
no que o cliente tem ouvido sobre o serviço ou o fato de que o cliente está atualmente

64
realizando atividades por conta própria ou está baseado em alguma experiência
anterior desse ou de outro serviço similar.

O valor de referência pode ser vagamente definido ou baseado em fatos reais. Um

exemplo de valor de referência é a linha de base de custos que clientes têm para
manter suas funções ou serviços internos. É importante que o provedor de serviços
entenda e tenha um senso de qual é o valor de referência usado pelo cliente. Este
valor pode ser obtido por meio de diálogo com o cliente.

A diferença positiva do serviço é baseada nos benefícios adicionais percebidos e

ganhos fornecidos pelo provedor de serviços. Estas diferenças são baseadas na
garantia e utilidade adicional que o provedor de serviços é capaz de entregar. É aqui
que o provedor de serviços está mais habilitado a influenciar a percepção do cliente.

A diferença negativa do serviço é a percepção do que o cliente irá perder investindo no

serviço. Por exemplo, ele pode perceber algumas questões de qualidade e custos
ocultos. O serviço também pode não ter toda a funcionalidade que o cliente gostaria
pelo preço que está sendo pedido.

A diferença líquida é a percepção real que o cliente tem de quão bom (ou ruim) o
serviço é em relação ao seu valor de referência após descontar a diferença negativa.

65
Padrões de atividade de negócio (PAN)
Outro conceito também importante para o exame que aparece no estágio de
Estratégia é o de Padrões de atividade de negócio (PAN).

Cada vez que uma atividade de negócio é realizada, uma demanda por serviços é
gerada. Entretanto, serviços não podem ser produzidos antes que eles sejam
consumidos. Por isso, é essencial sincronizar oferta e demanda.

Ativos de clientes tais como pessoas, processos e aplicativos realizam atividades de

negócio – e estas atividades serão realizadas seguindo um padrão, ou seja, um perfil
de carga de trabalho de uma ou mais atividades de negócio.

Padrões de atividade de negócio são usados para ajudar o provedor de serviços de TI

a entender e a planejar para os diferentes níveis de atividade de negócio. Por
exemplo, no final do ano está previsto um aumento no volume de vendas devido ao
Natal e com isto haverá maior carga de trabalho para os aplicativos usados no
processo de vendas da organização.

Um PAN nada mais é do que uma carga de trabalho, e descreve como o

cliente/usuário usa determinados serviços de TI. Os seguintes itens são
documentados em um PAN:
• Classificação: indica o tipo de PAN e pode se referir à sua
origem (usuário ou automação).
• Atributos: frequência, volume, local e duração.
• Requisitos: desempenho, segurança, disponibilidade,
privacidade, tolerância a delays.
• Requisitos para ativos de serviço: quais recursos são
usados e como cada recurso é usado.
O processo de gerenciamento de demanda analisa, rastreia, monitora e documenta os
Padrões de Atividade de Negócio (PAN) para prever as demandas atuais e futuras por
serviços. Entretanto, este processo não faz parte do currículo do exame ITIL
Foundation.

66
Caso de negócio
Quando vamos desenvolver um novo serviço, precisamos antes fazer um caso de
negócio – ou em inglês um business case.

Caso de negócio (business case)

É uma justificativa para um item ou gasto significativo. Ele contém
informações sobre custos, benefícios, opções, questões, riscos e
possíveis problemas.

O caso de negócio é um documento que pode servir para “vender” uma ideia ou
iniciativa, ou para justificar um item de gasto. Ele pode conter:

▪ Introdução que apresenta objetivos (operacional, financeiro, estratégico,

marketing, etc.)
▪ Métodos e premissas (custo e tempo)
▪ Análise de impactos e benefícios (deve mostrar análise dos impactos
financeiros e não financeiros)
▪ Custos
▪ Riscos que podem aparecer e contingências
▪ Desafios
▪ Recomendações
▪ Ações que precisariam ser tomadas

O processo de gerenciamento financeiro pode ajudar na elaboração de um caso de

negócio, principalmente nas análises financeiras para o investimento em TI.

67
4.3 Processos da estratégia de serviço
Os processos da Estratégia de serviço selecionados para exame ITIL Foundation são
os seguintes:

• Gerenciamento de portfólio de serviço

• Gerenciamento financeiro para serviços de TI

• Gerenciamento de relacionamento de negócio

Os processos gerenciamento estratégico para serviços de TI e gerenciamento da

demanda, também fazem parte do livro Estratégia de Serviço da ITIL edição 2011,
porém não fazem parte do escopo do exame ITIL Foundation. Por isso os demais
processos não serão detalhados nesta apostila.

Gerenciamento de portfólio de serviço

Propósito
O propósito do gerenciamento de portfólio de serviço inclui:

• Garantir que o provedor de serviços tenha a composição

(mix) correta de serviços para atender aos resultados de
negócio
• Acompanhar os investimentos em serviços durante seu
ciclo de vida
• Assegurar que os serviços estão claramente definidos e vinculados com a
realização de resultados de negócio

Objetivos
Os objetivos do gerenciamento de portfólio de serviço são:

▪ Fornecer um processo e mecanismos para habilitar a organização a investigar

e decidir sobre quais serviços oferecer, com base em uma análise de retorno
potencial e um nível aceitável de risco
▪ Manter o portfólio de serviços fornecidos
▪ Fornecer um mecanismo para a organização avaliar como os serviços a
possibilitam de realizar sua estratégia e a responder a mudanças
▪ Controlar quais serviços são oferecidos, sob quais condições e em que nível de
investimento
▪ Acompanhar o investimento em serviços durante o seu ciclo de vida
▪ Analisar quais serviços não são mais viáveis e quando eles deveriam ser
aposentados

68
Escopo
O escopo do gerenciamento de portfólio de serviço é acompanhar os serviços usando
o portfólio de serviço. Este portfólio é composto por 3 elementos: funil de serviço,
catálogo de serviço e serviços obsoletos (conforme figura na página seguinte).

O gerenciamento avalia o valor dos serviços durante seus ciclos de vida, ou seja,
quais novos serviços devem ser oferecidos e quais serviços obsoletos precisam ser
substituídos.

Um provedor de serviços interno irá trabalhar com as unidades de negócio na

organização para vincular cada serviço com os resultados de negócio antes de poder
comparar o investimento com os retornos.

Um provedor de serviços externo tende a avaliar o valor de forma mais direta, como
cada serviço irá gerar receita de forma direta ou suportar outros serviços que irão
gerar receitas.

Conceitos básicos
Portfólio de serviço
É um conjunto completo de serviços que são gerenciados por um provedor de
serviços.

Ele representa os compromissos e investimentos feitos pelo provedor de serviços para

todos os clientes, espaços de mercado e estágios do ciclo
de vida.

O gerenciamento de portfólio de serviço ajuda a priorizar o

investimento e a melhorar a alocação de recursos. Este
processo é usado para gerenciar o ciclo de vida completo
de todos os serviços, incluindo:

▪ Funil de serviço (serviços propostos ou

aprovados/priorizados para desenvolvimento)

▪ Catálogo de serviço (serviços em produção ou

disponíveis para implantação)

▪ Serviços obsoletos (serviços aposentados)

69
A figura abaixo apresenta o portfólio de serviço:

Veremos no estágio desenho de serviço a existência de um processo chamado

gerenciamento de catálogo de serviço. Não faça confusão com este processo. O
gerenciamento de catálogo de serviço é o processo que de fato vai criar e manter o
catálogo de serviço, que é um documento à parte. O processo gerenciamento de
portfólio gerencia portfólio de serviço e não é responsável pela documentação e
manutenção do serviço no catálogo de serviço. O portfólio de serviço fornece uma
estrutura para a tomada de decisão que ajudará a responder aos seguintes tipos de
questões:

▪ Por que um cliente compraria estes serviços?

▪ Por que um cliente compraria de nós?
▪ Qual é o preço e como serão os modelos de cobrança?
▪ Quais são os nossos pontos na matriz SWOT? [Nesta matriz identificamos
nossos pontos fortes, pontos fracos, ameaças, oportunidades. Serve para
traçarmos uma estratégia em relação ao mercado.]
▪ Como recursos e habilidades devem ser alocados?
Antes de qualquer iniciativa relacionada ao Desenho de serviço, o provedor de
serviços precisa saber quais serviços serão oferecidos. O portfólio de serviço dá à
organização a habilidade de antecipar mudanças. O portfólio de serviços descreve os
serviços de um provedor em termos de valor para o negócio. Ele define as
necessidades do negócio e as soluções do provedor para estas necessidades.

Este processo tem a habilidade de comparar os serviços do provedor, com base na

sua descrição e no seu valor, com os serviços fornecidos por outro provedor. Esta é
uma forma de analisar a competitividade de serviços entre vários provedores (verificar
pontos fracos e fortes).

70
Este processo fornece informações sobre todos os serviços através do ciclo de vida.
Este é um processo que ajuda na governança de TI, que diz o que a TI está fazendo.
Saberemos o que está no funil de serviço em desenvolvimento, o que está em
operação, o que deve ser aposentado ou já foi retirado de operações.

Por meio do portfólio de serviço podemos identificar os recursos de TI comuns

usados/alocados para avaliar, desenhar, transferir, operar e melhorar os serviços. O
portfólio de serviço pode ser usado para priorizar onde estes recursos devem focar
para garantir que os serviços prioritários tenham a atenção merecida.

Gerenciamento financeiro para serviços de TI

As organizações de TI estão admitindo ser bem

similares às empresas que colocam produtos
no mercado. Veja o departamento de TI como
se fosse um negócio: as organizações de TI
também têm a necessidade de analisar,
empacotar, vender e entregar serviços assim
como qualquer outra empresa. Elas também
compartilham de uma crescente necessidade
de entender e controlar fatores de oferta e
demanda e de prover serviços a um custo-benefício efetivo enquanto maximizam a
visibilidade em estruturas relacionadas aos custos. Ter tudo isso em comum é de
grande valia ao negócio, pois faz a TI buscar baixar custos e melhorar os serviços.

Quando o gerenciamento de nível de serviço entra em acordo com o cliente sobre

níveis de serviço, ele deve saber quanto dinheiro está envolvido na entrega deste
serviço, especialmente quando o custo do serviço de TI for cobrado do cliente. O
gerenciamento financeiro permite que a organização de TI articule claramente os
custos de entregar o serviço de TI.

O gerenciamento financeiro se aplica a todos os tipos de provedores de serviço. Em

qualquer organização se questionam os custos dos serviços de TI.

Propósito
Todos os processos da ITIL têm um propósito estabelecido, descrevendo para que
serve o processo. O propósito do gerenciamento financeiro para serviços de TI inclui:

• Assegurar o nível de orçamento apropriado para desenhar, desenvolver e

entregar serviços que atendam à estratégia da organização
• Identificar o equilíbrio entre o custo e a qualidade do serviço
• Manter o equilíbrio de oferta e demanda entre o provedor de serviços e seus
clientes

71
Objetivos
Todos os processos da ITIL têm objetivos. Eles detalham o que este processo terá que
realizar para atender aos seus propósitos. Os objetivos do gerenciamento financeiro
para serviços de TI incluem:

▪ Definir e manter uma estrutura para identificar, gerenciar e comunicar os custos

▪ Avaliar o impacto financeiro de estratégias novas ou alteradas
▪ Facilitar o serviço e ativos do cliente para assegurar que a organização atenda
a seus objetivos
▪ Entender o relacionamento entre despesas e receitas
▪ Gerenciar e reportar gastos no fornecimento de serviços
▪ Executar políticas e práticas financeiras no fornecimento de serviços
▪ Contabilizar o dinheiro gasto na criação, entrega e suporte de serviços
▪ Fazer a previsão de requisitos financeiros (orçamento)
▪ Se apropriado, definir uma estrutura para cobrança pelos serviços oferecidos

Gerenciamento financeiro para serviços de TI

Escopo
O gerenciamento financeiro para serviços de TI consiste de três subprocessos:
planejamento orçamentário, contabilidade e cobrança.

Planejamento orçamentário:

• Faz a previsão e controla o gasto de dinheiro

• Consiste em ciclos de negociações periódicas para definição de orçamentos
futuros (normalmente anuais), monitoração diária e ajustes dos orçamentos
Contabilidade:

• Possibilita à organização de TI contabilizar a forma como seu dinheiro é gasto

(identificando custos por cliente, serviço, atividade)
• Envolve sistemas de contabilidade, incluindo livros de registro, centros de
custos, etc.
• Deve ser supervisionada por alguém com formação em contabilidade
Cobrança:

• É uma parte opcional deste processo

• Necessária para emitir cobranças aos clientes pelos serviços fornecidos a eles
• Deve ser baseada em práticas e sistemas de contabilidade
Obs.: estes 3 subprocessos podem atuar em todos os estágios do ciclo de vida do serviço.
Consulte tabela no final do capítulo 3.

72
Gerenciamento de relacionamento de negócio

Propósito
Este processo tem dois propósitos:

1 - Estabelecer e manter um relacionamento de negócio entre o

provedor de serviços e o cliente, baseado no entendimento do
cliente e suas necessidades de negócio.
2 - Identificar as necessidades do cliente e assegurar que o
provedor de serviços é capaz de atender a estas necessidades,
considerando que as necessidades de negócio mudam ao
longo do tempo e assegurando que as expectativas do cliente não excedem o que ele
está disposto a pagar e o que o provedor pode entregar.

Objetivos
Os objetivos do gerenciamento de relacionamento de negócio incluem:

▪ Assegurar que o provedor de serviços entenda a perspectiva de serviço do

cliente
▪ Assegurar níveis altos de satisfação do cliente
▪ Estabelecer e manter uma relação construtiva entre o provedor de serviços e o
cliente
▪ Identificar mudanças no ambiente do cliente e tendências de tecnologia
▪ Estabelecer e articular requisitos de negócio para serviços novos ou mudanças
para os serviços existentes
▪ Trabalhar com o cliente para assegurar que os serviços serão capazes de
entregar valor
▪ Mediar em casos onde existirem requisitos conflitantes para serviços de
diferentes unidades de negócio
▪ Estabelecer um processo formal para receber e fazer escalação de
reclamações de clientes

73
Escopo
Nos provedores de serviços internos, este
processo é tipicamente executado entre um
representante sênior da TI e gerentes sênior das
unidades de negócio. O escopo é alinhar os
objetivos do negócio com as atividades do
provedor de serviços.

Nos provedores de serviços externos, este

processo é frequentemente executado por uma
função de GRN separada e dedicada ou por
gerentes de contas que são dedicados a um
cliente ou grupo de clientes. O escopo é
maximizar o valor do contrato por meio da
satisfação do cliente.

Diferenças entre Gerenciamento de relacionamento de negócio (GRN) e

Gerenciamento de nível de serviço (GNS)
Tanto o processo gerenciamento de relacionamento de negócio como o processo
gerenciamento de nível de serviço que vamos estudar no capítulo 5 estão envolvidos
em fazer a interface com o cliente, mas o foco de cada processo é diferente. O GNS
está focado em fornecer um nível específico de serviço para os serviços identificados,
enquanto que o escopo do GRN é maior, busca entender os requisitos e construir
relações no nível estratégico e tático.

74
A tabela abaixo apresenta as diferenças entre estes dois processos. No capítulo 5
você entenderá melhor o processo GNS.
Gerenciamento de
relacionamento de negócio
(GRN)
Propósito Estabelecer e manter um
relacionamento de negócio entre o
provedor de serviços e o cliente
baseado no entendimento do
cliente e suas necessidades de
negócio.
Identificar as necessidades do
cliente e assegurar que o provedor
de serviços é capaz de atender a
estas necessidades conforme os
requisitos de negócio mudam ao
longo do tempo.
Foco Estratégico e tático – o foco está
em todo o relacionamento entre o
provedor de serviços e seu cliente
e quais serviços o provedor de
serviços irá entregar para atender
às necessidades do cliente.
Medida Satisfação do cliente.
primária
75
Gerenciamento de nível de serviço
(GNS)
Negociar acordos de nível de serviço
(em termos de garantia) com clientes e
assegurar que todos os processos de
gerenciamento de serviços, acordos de
nível operacional e contratos de apoio
são apropriados para as metas de nível
de serviço acordadas.
Tático e operacional – o foco está em
alcançar o acordo no nível de serviço
que será entregue para serviços novos
ou existentes e se o provedor de
serviço será capaz de atender a estes
acordos.
Realização dos níveis de serviço
acordados (os quais naturalmente
levam à satisfação do cliente).
4.4 Tipos de ferramentas de suporte a estratégia de
serviço

Existem vários pacotes de software que podem apoiar as atividades realizadas nos
processos da estratégia de serviço.

76
5 - Desenho de serviço

Após o estágio Estratégia de serviço vem o estágio Desenho

de serviço. Tudo o que foi levantado na Estratégia de serviço
será passado para o Desenho de serviço. O
pessoal que vai atuar no Desenho de serviço
precisa saber de que forma a solução precisa
ser desenhada, quem vai ser o cliente
daquele serviço e como ele vai usar o
serviço. Neste estágio levam-se em
consideração estratégia, políticas,
recursos e restrições que já foram
levantados no estágio anterior.
Precisamos considerar tudo o que é
necessário para projetar um serviço
que atenda aos requisitos do cliente
para que o serviço gere valor ao cliente.
É aqui no Desenho de serviço que vamos
confirmar exatamente e claramente quais
são os requisitos do cliente e vamos entrar nos
detalhes dos requisitos funcionais e não
funcionais. Na estratégia nós avaliamos
as necessidades, mas não detalhamos estes requisitos, não definimos uma solução. É
aqui que vamos fazer isso: no Desenho nós vamos alinhar os objetivos e metas de
qualidade para que o serviço seja entregue dentro das condições necessárias para o
negócio.

5.1 Propósito, objetivos, escopo e valor agregado ao

negócio
Propósito do desenho de serviço
O propósito do estágio Desenho de serviço inclui:

▪ Desenhar serviços de TI, junto com as práticas que o regem, processos e

políticas requeridas para realizar a estratégia do provedor de serviços
▪ Facilitar a introdução de serviços nos ambientes suportados assegurando a
entrega de serviço com qualidade, satisfação do cliente e provisão de serviço a
custo efetivo

Objetivos do desenho de serviço

O principal objetivo do Desenho de serviço é desenhar serviços de TI de forma tão
eficaz que seja requerido o mínimo de melhoria durante o seu ciclo de vida.

77
Escopo do desenho de serviço
O Desenho de serviço cobre:

• Alinhamento dos serviços e soluções de TI com os requisitos de negócio

• Princípios do Desenho de serviço
• O conceito de pacote de Desenho de serviço
• Métodos, práticas e ferramentas para alcançar a excelência no Desenho do
serviço

Valor que o desenho de serviço agrega ao negócio

Com um bom Desenho de serviço é possível entregar qualidade e serviços com
efetividade de custo, e assegurar que os requisitos do negócio sejam atendidos.

Adotar e implementar abordagens consistentes para o Desenho de serviço irá:

▪ Melhorar a qualidade do serviço

▪ Melhorar a consistência do serviço
▪ Melhorar a transição de serviços novos e alterados
▪ Melhorar a eficácia do gerenciamento de serviços e processos de TI
▪ Melhorar o alinhamento do serviço
▪ Reduzir o custo total de propriedade – no custo total de propriedade (CTP)
avalia-se o ciclo de vida do custo de um item de configuração por completo,
não apenas o custo inicial ou preço de compra.

78
5.2 Conceitos e princípios-chave
A importância dos 4 Ps no desenho
Muitos desenhos, planos e projetos falham devido à falta de preparação e
gerenciamento. Um bom desenho de serviço é dependente da preparação e
planejamento eficiente e eficaz do uso dos 4 Ps: pessoas, processos, produtos e
parceiros.

Pessoas

Produtos/
Processos Tecnologia
Parceiros

© Crown copyright 2011. Reproduced under licence from Cabinet Office.

Ao desenhar um serviço é necessário considerar:

• Pessoas: é necessário garantir ter as pessoas certas com as habilidades e
treinamentos adequados.

• Processos: os processos de gerenciamento de serviços precisam ser

desenhados ou ajustados. É fundamental que eles sejam desenhados
adequadamente para os serviços que precisam ser implantados e suportados.

• Produtos / tecnologia: inclui os componentes de tecnologia dos serviços de TI

(hardware e software), juntamente com qualquer ferramenta ou tecnologia de
apoio. Novamente, garanta que eles sejam apropriados.

• Parceiros / fornecedores: geralmente precisamos ter fornecedores

terceirizados certos para ajudar a fornecer e oferecer suporte ao serviço.

O desenho de serviço procura garantir que os quatro Ps sejam levados em conta em

cada estágio do ciclo de vida.

79
Os 5 aspectos do desenho de serviço

Até poderíamos intitular esta seção como "O escopo do estágio de desenho de
serviço". Que tipo de coisas se desenha nesse estágio? Claramente, nós desenhamos
o serviço, mas ao fazer isso também devemos identificar os impactos em outras áreas
que podem ser afetadas pelo projeto. ITIL se refere a essas áreas como os cinco
aspectos do desenho de serviço. Aqui estão elas:

Soluções de serviço: desenhamos os serviços novos ou alterados. Coletamos e

acordamos todos os requisitos funcionais e estimamos os recursos e capacidades
necessários para desenvolver e operar o serviço.

Sistemas e ferramentas de gerenciamento de serviços: qualquer ferramenta de

gerenciamento de serviços que usaremos, por exemplo, uma ferramenta de registro de
chamadas na central de serviços. Devemos estabelecer um conjunto de requisitos e
adquirir ou desenvolver as ferramentas para atender a esses requisitos. A ITIL dá uma
menção especial aqui ao portfólio de serviços (abordado no Capítulo 4), do qual
extraímos os requisitos de negócios de alto nível para novos serviços.

Arquiteturas de tecnologia e sistemas de gerenciamento: a arquitetura, as

ferramentas e os sistemas que devem estar implementados para suportar o desenho
da infraestrutura, dos dados e dos ambientes.

Processos: os processos de gerenciamento de serviços precisam ser desenhados

com antecedência.

Sistemas, métodos e métricas de medição: não são as ferramentas de

monitoramento propriamente ditas, embora as usemos para reunir grande parte de
seus dados de medição - a ênfase aqui é desenhar uma estrutura para agrupar as
medidas e métricas certas que fornecem a visibilidade e a capacidade necessárias
para controlar o serviço e os processos de gerenciamento de serviços. Em outras
palavras, vamos desenhar a forma como vamos medir o desempenho das coisas
antes das coisas serem implantadas.

80
Pacote de Desenho de serviço (PDS)
Pacote de Desenho de serviço (PDS) é um documento que define todos os aspectos
de um serviço e seus requisitos para cada estágio subsequente do ciclo de vida.

O PDS precisa ser produzido durante o estágio de Desenho para cada serviço novo,
mudança maior, remoção de serviço ou para mudanças no próprio PDS.

O pacote de Desenho de serviço é passado do estágio Desenho de serviço para a

Transição de serviço e na sequência detalhes de todos os aspectos do serviço e seus
requisitos são enviados para o estágio de Operação.

O pacote de Desenho de serviço contém tudo que é necessário para a realização dos
testes, introdução e operação da solução ou serviço. Seu conteúdo pode incluir os
seguintes itens:

1. Requisitos de negócio
2. Requisitos funcionais do serviço
3. Requisitos de gerenciamento da operação e do serviço
4. Desenho de serviço e topologia
5. Avaliação da prontidão organizacional
6. Plano de Transição de serviço
7. Plano de aceite operacional do serviço
8. Critérios de aceitação de serviço

81
O diagrama a seguir apresenta em que momento do ciclo de vida do serviço o PDS é
gerado.

82
5.3 Processos no desenho de serviço
Os processos do Desenho de serviço selecionados para exame ITIL Foundation são
os seguintes:

• Coordenação de desenho
• Gerenciamento de catálogo de serviço
• Gerenciamento de nível de serviço
• Gerenciamento de disponibilidade
• Gerenciamento de capacidade
• Gerenciamento de continuidade de serviço de TI
• Gerenciamento de segurança da Informação
• Gerenciamento de fornecedor
Todos os processos do livro Desenho de Serviço da ITIL são cobertos pelo currículo
do exame ITIL Foundation atual. Entretanto, somente para o processo gerenciamento
de nível de serviço serão apresentadas as atividades e interfaces do processo.

Coordenação de desenho

Os provedores de serviços não vão lidar apenas com um projeto

de desenho por vez. Este processo de coordenação de desenho
vai assegurar que todos os projetos de desenho são bem
coordenados e seguem um padrão. Além disto, este processo vai
coordenar todas as atividades deste estágio, garantindo que o
projeto de desenho está considerando todos os aspectos,
atividades e processos do estágio desenho de serviço.

Propósito
O propósito da coordenação de desenho é garantir que metas e objetivos do estágio
Desenho de serviço sejam atendidas por meio de fornecimento e manutenção de um
ponto único de coordenação e controle para todas as atividades e processos dentro
deste estágio do ciclo de vida do serviço.

Objetivos
Os objetivos da coordenação de desenho incluem:

▪ Assegurar o desenho consistente de serviços apropriados, sistemas de

gerenciamento da informação de serviço, arquiteturas, tecnologia, processos,
informação e métricas
▪ Coordenar todas as atividades de desenho envolvidas em projetos, mudanças,
fornecedores e equipes de suporte

83
 ▪ Planejar e coordenar os recursos e habilidades requeridas para desenhar
serviços novos ou alterados
▪ Produzir pacotes de desenho de serviço (PDSs) baseados no termo de
abertura de serviço e em requisições de mudança
▪ Assegurar que desenhos de serviços apropriados e/ou PDSs são produzidos e
que eles são repassados para a Transição de serviço conforme acordado
▪ Gerenciar os critérios de qualidade, requisitos e pontos de repasse entre os
estágios Desenho de serviço, Estratégia de serviço e Transição de serviço
▪ Assegurar que todos os modelos de serviço e desenhos de solução de serviço
estão em conformidade com a estratégia, arquitetura, governança e outros
requisitos corporativos
▪ Melhorar eficácia e eficiência das atividades e processos deste estágio
▪ Assegurar que todas as partes adotam uma estrutura padrão e práticas de
desenho reutilizáveis
▪ Monitorar e melhorar o desempenho deste estágio

Escopo
O escopo deste processo inclui todas as atividades
de desenho, particularmente todas as soluções de
serviço novas ou alteradas que estão sendo
desenhadas para transição dentro (ou para fora, no
caso de ser uma remoção de um serviço obsoleto)
do ambiente de produção.

Alguns esforços de Desenho farão parte de um

projeto, enquanto outros serão gerenciados pelo
processo de gerenciamento de mudança sem a
necessidade de definir um projeto. O processo de coordenação de Desenho inclui:

▪ Auxiliar e suportar cada projeto ou mudança durante todas as atividades e

processos do Desenho de serviço
▪ Manter políticas, diretrizes, padrões, orçamentos, modelos, recursos e
habilidades para as atividades e processos do Desenho de serviço
▪ Coordenação, priorização e agendamento de recursos do Desenho de serviço
▪ Planejar e fazer previsão para os recursos necessários para a demanda futura
das atividades de desenho
▪ Revisão, medição e melhoria do desempenho de todas as atividades e
processos do Desenho de serviço
▪ Garantia de que todos os requisitos estão sendo apropriadamente
endereçados nos projetos de Desenho, particularmente requisitos de utilidade
e garantia
▪ Garantia da produção de Desenho de serviço e/ou pacotes de Desenho de
serviço e seu repasse para a Transição de serviço

84
Gerenciamento de catálogo de serviço

Este processo é responsável pelo gerenciamento de um documento chamado catálogo

de serviço. É este processo que ficará responsável pela criação e manutenção deste
documento.

Propósito
O propósito do gerenciamento de catálogo de serviço é fornecer e manter uma fonte
única de informação consistente de todos os serviços operacionais e aqueles que
estão sendo preparados para entrar em operação.

Objetivos
Os objetivos do gerenciamento de catálogo de serviço são:

▪ Gerenciar a informação contida dentro do catálogo

de serviço
▪ Assegurar que o catálogo de serviço está correto e
reflete detalhes, status, interfaces e dependências
atuais de todos os serviços que estão sendo
executados ou estão sendo preparados para serem
executados no ambiente de produção
▪ Assegurar que o catálogo de serviço está disponível para aqueles que
precisam acessá-lo de maneira que suporte o uso eficaz e eficiente das
informações nele contidas
▪ Assegurar que o catálogo de serviço suporta as necessidades envolvidas em
todos os processos do gerenciamento de serviços referentes às suas
informações

Escopo
O escopo do gerenciamento de catálogo de serviço é fornecer e manter informação
precisas sobre todos os serviços que estão sendo transferidos ou que foram
transferidos para o ambiente de produção.

Os serviços apresentados no catálogo de serviço podem ser listados individualmente

ou, mais tipicamente, apresentados em forma de pacotes de serviço.

85
Conceitos básicos
O conceito mais importante relacionado a este processo refere-se ao entendimento do
que é um catálogo de serviço e suas visões.

Catálogo de serviço
É um banco de dados ou documento estruturado com informações sobre todos os
serviços de TI em produção, incluindo aqueles disponíveis para implantação.

O catálogo de serviço é a única parte do portfólio de serviço publicada aos clientes, e

é usada para dar suporte à venda e à entrega de serviços de TI, incluindo informação
sobre entregas, preços, pontos de contato, processos de compra e requisição.

O catálogo de serviço inclui relacionamentos para os serviços de suporte, serviços

compartilhados, componentes e itens de configuração necessários para suportar a
provisão de serviços ao negócio. O catálogo de serviço serve como apoio para a
construção de relacionamento entre os serviços, Acordos de Nível de Serviço,
contratos e componentes, além de identificar a tecnologia necessária para suportar um
serviço e os grupos de suporte que suportam os componentes.

86
Veja abaixo um exemplo de uma estrutura simples para um catálogo de serviço:

Serviço 1 Serviço 2
Descrição
Tipo de serviço
Serviços de suporte
Donos do negócio
Unidades de negócio
Impacto no negócio
Prioridade no negócio
ANS
Horário de serviço
Contatos no negócio
Contatos de escalação
Relatórios de serviço
Revisões de serviço
Nível de segurança
© Crown copyright 2011. Reproduced under licence from Cabinet Office.

É importante esclarecer que o processo gerenciamento de portfólio de serviço

gerencia o portfólio, tomando decisões sobre quais serviços devem ser desenvolvidos
ou retirados de operação, além de acompanhar o valor gerado pelos serviços que
estão em produção. Apesar de ser uma parte integrante do portfólio de serviço, o
catálogo de serviço não é mantido pelo processo gerenciamento de portfólio de
serviço. A elaboração e a atualização do catálogo ficam por conta do processo
gerenciamento de catálogo de serviço. Essa é a diferença básica entre os dois
processos: como o catálogo de serviço tem muitas informações, e os serviços sofrem
mudanças ao longo do seu ciclo de vida, há a necessidade de um processo que
produza este catálogo e controle suas alterações. Isso significa que este é um
processo “vivo”.

87
Visões do catálogo de serviço

É recomendado que o provedor de serviços no mínimo defina duas diferentes visões,

cada uma focando um tipo de serviço:

• Catálogo de serviço do negócio (visão para usuários/clientes)

• Catálogo de serviço técnico (visão para o provedor de serviços)

Catálogo de serviço do negócio

Este é o catálogo de serviço que o cliente pode ver e que contém detalhes sobre todos
os serviços de TI entregues aos clientes. Inclui relacionamentos com as unidades de
negócio e processos de negócio que são baseados nos serviços de TI. Facilita o
desenvolvimento do processo de Gerenciamento de Nível de Serviço, pois se saberá
quais são os clientes do serviço e suas necessidades.

Catálogo de serviço técnico

Deriva do catálogo de serviço do negócio e não faz parte da visão do cliente. Contém
detalhes técnicos sobre todos os serviços de TI entregues aos clientes. Inclui
relacionamentos para os serviços de suporte, serviços compartilhados, componentes e
itens de configuração necessários para suportar a provisão de serviços ao negócio.
Serve como apoio para a construção de relacionamento entre os serviços, Acordos de
Nível de Serviço, contratos e componentes, além de identificar a tecnologia necessária
para suportar um serviço e os grupos de suporte que suportam os componentes.

Algumas organizações podem desenvolver mais do que duas visões para o catálogo.
Não existe um número correto de visões sugeridas que uma organização pode
desenvolver. O número de visões irá depender do público que vai ser endereçado e
usos que o catálogo irá ter. O diagrama na página seguinte é um exemplo disso: no

88
lado esquerdo estão os serviços oferecidos para clientes que atuam no segmento de
vendas por atacado e no lado direito em vendas no varejo.

89
Gerenciamento de nível de serviço (GNS)

O gerenciamento de nível de serviço (GNS) é um dos processos fundamentais no

Desenho de serviço. Este processo é responsável por garantir um entendimento claro
entre as necessidades dos clientes e o que o provedor de serviço deve entregar. Para
isso ele irá negociar, acordar e documentar os serviços de TI. Este processo deverá
ser proativo para melhorar os níveis de serviços existentes. Para isso os níveis devem
ser monitorados, reportados e revisados.

O gerenciamento de nível de serviço possibilitará estabelecer acordos entre as partes.

E com isso as partes estarão cientes de como o serviço será entregue, havendo
menos conflito de interesses e de entendimento. Estabelecer acordos é uma forma de
gerenciar a expectativa do cliente. O cliente saberá o que ele poderá exigir do
provedor de serviço, visto que o foi acordado. Para o provedor de serviço também há
benefícios, pois haverá um claro entendimento do que ele deve entregar ao cliente.

É muito importante que o nível de serviço seja desenhado corretamente para evitar
que o serviço seja colocado em operação com níveis abaixo do requerido. Por isso,
este processo irá depender de informações que vêm dos processos do estágio
Estratégia de serviço.

Propósito
O propósito do gerenciamento de nível de serviço (GNS) é assegurar que os serviços
de TI atuais e planejados sejam entregues com as metas atingíveis. Isto pode ser feito
por meio de um ciclo constante de negociação, acordo, monitoração, reporte e revisão
de metas e resultados obtidos e por meio de ações para corrigir e melhorar o nível de
serviço entregue.

90
Objetivos
Os objetivos do gerenciamento de nível de serviço são:

▪ Definir, documentar, acordar, monitorar, medir, reportar e

revisar o nível dos serviços de TI fornecidos
▪ Fornecer e melhorar o relacionamento e a comunicação
com o negócio e os clientes
▪ Assegurar que metas específicas e mensuráveis sejam
desenvolvidas para todos os serviços de TI
▪ Monitorar e melhorar a satisfação do cliente com a
qualidade do serviço entregue
▪ Assegurar que TI e clientes tenham expectativas claras e não ambíguas sobre
os níveis de serviço a serem entregues
▪ Assegurar que ainda que metas acordadas sejam cumpridas, os níveis de
serviço entregues estão sujeitos à melhoria contínua

Escopo
O gerenciamento de nível de serviço deve fornecer um ponto regular de contato e
comunicação para clientes e gerentes de negócio de uma organização em relação aos
níveis de serviço. Esta atividade deve englobar o uso de serviços existentes como
também requisitos futuros potenciais para serviços novos ou alterados.

O gerenciamento de nível de serviço precisa gerenciar as expectativas e percepções

do negócio, clientes e usuários e assegurar que a qualidade (garantia) do serviço
entregue pelo provedor de serviços atende a estas expectativas e
necessidades. A fim de fazer isto de forma mais eficaz, o
gerenciamento de nível de serviço deve estabelecer e manter
acordos de nível de serviço (ANSs) para todos os serviços em
produção e gerenciar o nível de serviço fornecido para atender às
metas e medições de qualidade contidas dentro dos ANSs.

O gerenciamento de nível de serviço também deve produzir e acordar requisitos de

nível de serviço (RNSs) para todos os serviços novos planejados e alterados.

91
Conceitos básicos
Antes de detalharmos as atividades de processos, vejamos a seguir alguns termos
que você precisa conhecer.

Requisito de Nível de Serviço (RNS)

Acordos de Nível de Serviço são baseados em requisitos dos clientes. É aconselhável
envolver os clientes desde o início, preferencialmente com um rascunho de potenciais
metas de desempenho e requisitos operacionais como um ponto de partida para
discussões mais detalhadas.

Requisito de Nível de Serviço

Um requisito do cliente para um aspecto de um serviço de TI. Os Requisitos de Nível
de Serviço são baseados em objetivos de negócio e usados para negociar metas de
nível de serviço acordadas.

Estes RNSs são os desejos dos clientes –

eles representam quais as necessidades do
cliente em relação ao uso de um serviço. Os
requisitos podem incluir especificações
funcionais, descrevendo como um
aplicativo/serviço deve funcionar. E eles são
refinados conforme o serviço se move no seu
ciclo de vida, até virarem um ANS piloto no
suporte para período de funcionamento
experimental.

Acordo de Nível de Serviço – ANS (SLA em inglês)

Fornece uma base para gerenciar o relacionamento
entre o provedor de serviços e o cliente.

Acordo de Nível de Serviço

É um acordo entre um provedor de serviço de TI e um
cliente que descreve o serviço de TI, documenta metas
de nível de serviço e especifica as responsabilidades do
provedor de serviços de TI e do cliente. Um único
acordo pode cobrir múltiplos serviços de TI ou múltiplos
clientes.

92
Exemplo de conteúdo para um ANS:
• Validade
• Nome do cliente
• Tipo de serviço ou produto
• Definição e escopo do serviço/produto (o que se inclui e exclui)
• Horário de serviço
• Contatos e procedimentos para solicitação de serviços
• Pré-requisitos que devem ser preenchidos pelo cliente
• Padrões de qualidade acordados
• Disponibilidade e confiabilidade
• Metas de desempenho do serviço (tempo de resposta, volume)
incluindo “deadlines” para determinados dias
• Regulamento de emergência (referir a conceitos de emergência)
• Tempo de resposta para incidentes
• Reclamações e procedimentos de escalonamento
• Procedimentos de mudança (RDM)
• Continuidade
• Política de segurança
• Monitoração
• Relatórios que devem ser produzidos
• Agenda de reuniões de revisão
• Contabilidade de custos e cobrança (se aplicável)
• Regulamento de bônus/multas

Veja abaixo alguns exemplos de meta que podem ser estabelecidas em um ANS
referentes ao tempo de resposta para resolução de incidentes.

Nível de prioridade Tempo de resolução

1 1 hora útil
2 4 horas úteis
3 8 horas úteis
4 16 horas úteis

Outros exemplos de metas incluem:

• Meta de disponibilidade: 99,5% dentro do horário de funcionamento do serviço.

• Metas de desempenho de serviço: tempo de resposta para uma conexão: 2

segundos; volume: 10 transações por segundo.

É recomendado estabelecer um ANS para cada serviço existente no catálogo de

serviço. De qualquer forma, é importante que a coleta de requisitos seja feita sempre
antes que um novo serviço seja desenvolvido. É importante que esta coleta de
requisitos seja incorporada como uma etapa em todos os projetos para novos
serviços.

93
Tipos de estruturas para os ANSs
Usando o catálogo de serviço como apoio, o gerenciamento de nível de serviço
precisa desenhar uma estrutura de ANS que assegure que todos os serviços sejam
cobertos da maneira que melhor atende às necessidades da organização. Um número
de opções para estruturar os ANS inclui:

• ANS baseado em serviços

• ANS baseado em cliente

• ANS multinível

ANS baseado em serviço

Quando um ANS cobre um serviço para todos os clientes daquele serviço. Exemplo:
um ANS pode ser estabelecido para o serviço de e-mail da organização, cobrindo
todos os clientes deste serviço.

ANS baseado em cliente

Este é um acordo com um grupo de clientes individuais, cobrindo todos os serviços

que eles usam. Por exemplo: acordos podem ser realizados com o departamento
financeiro da organização, cobrindo o sistema financeiro, de contabilidade e contas a
pagar.

94
ANS multinível

Algumas organizações podem escolher adotar uma

estrutura de ANS multinível conforme ilustrado na figura
ao lado. Por exemplo, uma estrutura de três camadas
pode ser organizada da seguinte forma:

▪ Nível corporativo: cobre todas as questões

genéricas de gerenciamento de nível de serviço.
Estas questões podem ser menos voláteis, então
menos atualizações frequentes serão necessárias.

▪ Nível cliente: cobre todas as questões relevantes

para um grupo de clientes ou unidade de negócio,
independente do serviço que está sendo usado.

▪ Nível serviço: cobre todas as questões relevantes

para um serviço específico em relação a um grupo
de clientes específicos (um para cada serviço
coberto pelo ANS).

Acordo de Nível Operacional (ANO)

Além dos acordos entre provedor de serviço e clientes,
podem existir acordos internos entre o provedor e
equipes internas.

Acordo de Nível Operacional (ANO)

É um acordo entre um provedor de serviço de TI e
outra parte da mesma organização. Ele dá apoio à
entrega, pelo provedor de serviço de TI, de serviços de
TI a clientes e define os produtos ou serviços a serem
fornecidos e as responsabilidades de ambas as partes.

Por exemplo, pode haver um Acordo de Nível

Operacional entre o provedor de serviços de TI e o
departamento de compras, para obter hardware dentro
de um prazo acordado, ou entre a central de serviços e
um grupo de suporte, para fornecer resolução de
incidente dentro de um prazo acordado.

95
Exemplo de conteúdo para um ANO:

• Validade
• Nome do provedor interno
• Tipo de serviço ou produto:
• Definição e escopo do serviço/produto (o que se inclui e exclui)
• Horário de serviço
• Contatos e procedimentos para solicitação de serviços
• Padrões de qualidade acordados:
• Metas de serviço
• Tempo de resposta para incidentes
• Tempo de resposta para problemas
• Responsabilidades na implantação de mudanças, liberação,
manutenção da configuração, suporte da política de segurança,
gerenciamento dos componentes do serviço que afetariam a
disponibilidade, teste dos planos de recuperação, assistência no
gerenciamento da capacidade, de nível de serviço e de fornecedor

Contrato de Apoio (CA)

Acordos de Nível de Serviço são sustentados por Acordos de Nível Operacional
(ANOs) e Contratos de Apoio (CA).

Contrato de Apoio (CA)

É um contrato entre um provedor de serviços de TI e um terceiro. O terceiro fornece
produtos ou serviços que são necessários para a execução de um serviço de TI a um
cliente.

O Contrato de Apoio define metas e responsabilidades

requeridas para atender a metas de nível de serviço
acordadas em um ou mais acordos de nível de serviço, e
seu conteúdo básico é composto de:

• Termos e condições básicas

• Descrição e escopo do serviço
• Padrões do serviço (medições de serviço e níveis
mínimos que constituem o desempenho e
qualidade aceitáveis)
• Faixas de carga de trabalho
• Informações gerenciais (relatórios)
• Responsabilidades e dependências

Observação: A negociação de contratos de apoio não faz

parte do escopo do GNS, isto é parte do processo
gerenciamento de fornecedor.

96
Relatório de serviços
Relatórios períodicos de nível de serviço produzidos e distribuídos aos clientes e
gerentes de TI apropriados. Os relatórios periódicos devem incorporar detalhes de
desempenho em relação a todas as metas de ANSs, juntamente com detalhes de
quaisquer tendências ou ações específicas que estão sendo tomadas para melhorar a
qualidade do serviço.Uma técnica útil é incluir neste relatório um gráfico MANS
(Monitoração do Acordo de Nível de Serviço).

Um gráfico de monitoração do acordo de nível de serviço que é usado para ajudar a

monitorar e reportar resultados atingidos em comparação com metas de nível de
serviço estabelecidas. Um gráfico MANS geralmente usa um código de cores para
melhor demonstrar qual meta de nível de serviço foi atingida, não foi atingida ou quase
não foi atingida durante cada um dos 12 meses anteriores.

Exemplo de gráfico MANS:

Plano de melhoria de serviço (PMS)

Planos de melhoria serviço e reuniões de revisão de serviço precisam ser realizadas
em base regular com clientes (ou seus representantes) para analisar a realização de
serviços no último período e para visualizar qualquer questão para o próximo período.
É normal realizar tais reuniões com frequêncial mensal ou no mínimo trimestral.

Plano de melhoria de serviço (PMS)

É um plano formal para implementar melhorias a um processo ou serviço de TI.

As ações precisam ser realizadas no lado do cliente e do fornecedor, conforme

apropriado para melhorar áreas fracas onde as metas não estão sendo atendidas.
Todas as ações precisam ser datadas, e os progressos devem ser revistos na próxima
reunião para garantir que os itens de ação estão sendo acompanhados e devidamente
executados. Esta é uma valiosa entrada para o PMS para gerenciamento,
planejamento e implementação de todas as melhorias de processo e serviço.

97
Atividades
As atividades-chave dentro o processo gerenciamento de nível de serviço incluem:

▪ Determinar, negociar, documentar e acordar os requisitos para serviços novos

ou alterados referentes aos Requisitos de Nível de Serviço, gerenciar e revisá-
los através do ciclo de vida do serviço nos ANSs para serviços operacionais
▪ Monitorar e medir a realização do desempenho do serviço contra as metas dos
ANSs
▪ Produzir relatórios de serviços
▪ Conduzir revisões de serviços, identificando oportunidades de melhoria para a
inclusão no registro da Melhoria contínua dos serviços (MCS) e gerenciamento
adequado dos planos de melhoria de serviço (PMSs)
▪ Confrontar, medir e melhorar a satisfação do cliente, em cooperação com o
gerenciamento de relacionamento de negócio
▪ Revisar ANSs, escopo de serviço e ANOs
▪ Auxiliar o gerenciamento de fornecedor a analisar e rever contratos ou acordos
de apoio
▪ Desenvolver e documentar contatos e as relações com o negócio, clientes e
outras partes interessadas em cooperação com o gerenciamento de
relacionamento de negócio
▪ Registrar e gerenciar reclamações e elogios, em cooperação com o
gerenciamento de relacionamento de negócio

Interfaces
As interfaces mais críticas para o gerenciamento de nível de serviço incluem:

98
• Gerenciamento financeiro para serviços de TI
Suporta o gerenciamento de nível de serviço validando custos previstos para
entregar o serviço e gerenciando a efetividade de custo do serviço.
• Gerenciamento de relacionamento de negócio
Assegura que necessidades e prioridades do negócio são entendidas e que os
clientes são envolvidos ou representados no gerenciamento de nível de
serviço.
• Coordenação de desenho
Assegura que as atividades gerais do Desenho de serviço são completadas
com sucesso.
• Gerenciamento de catálogo de serviço
Provê informação sobre serviços e suas interfaces e dependências para
determinar o framework do ANS.
• Gerenciamento de fornecedor
Trabalha em colaboração com o gerenciamento de nível de serviço para
definir, negociar, documentar e acordar termos de serviço com fornecedores
para suportar níveis acordados de serviço.
• Gerenciamento de disponibilidade, capacidade, continuidade do serviço
de TI e segurança da informação
Ajuda a definir metas realistas de nível de serviço e a assegurar que os
resultados atendam às metas.
• Gerenciamento de incidente
A habilidade de resolver incidentes em um tempo específico é uma parte
essencial de entregar e reportar um nível acordado de serviço.
• Gerenciamento de problema
A ocorrência de problemas afeta o nível do serviço entregue medido pelo
gerenciamento de nível de serviço.

99
Gerenciamento de disponibilidade

Como nós já sabemos, é raro ter um processo de negócio da organização que não
dependa de algum sistema de TI para suportá-lo. Portanto, qualquer parada em algum
componente do sistema impacta diretamente o negócio. Atender à disponibilidade
exigida pelo negócio é um dos grandes desafios da TI. Por isto, disponibilidade é um
aspecto crítico da garantia do serviço.

Temos que trabalhar com a condição de que atingir 100% de disponibilidade não é
algo possível. Para ter boa disponibilidade nos serviços é preciso planejar e gerenciar.
Comprar a última tecnologia não é sinônimo de alta disponibilidade. Nada adiantará ter
o melhor servidor se não houver pessoal disponível para fazer sua manutenção.

Propósito
O propósito do processo de gerenciamento de disponibilidade é garantir que o nível de
disponibilidade entregue em todos os serviços de TI atende de maneira eficaz às
necessidades de disponibilidade e/ou metas de nível de serviço acordadas.

O gerenciamento de disponibilidade define, analisa, planeja, mede e melhora todos os

aspectos da disponibilidade de serviços de TI e garante que todos os processos,
infraestruturas, ferramentas, papéis, etc. de TI sejam adequados para as metas de
nível de serviço acordadas para disponibilidade.

Objetivos
Os objetivos do gerenciamento de disponibilidade são:

▪ Produzir e manter um plano de disponibilidade apropriado e atualizado que

reflita as necessidades atuais e futuras do negócio
▪ Fornecer conselhos e orientações a todas as outras áreas do negócio e de TI
em todas as questões relacionadas à disponibilidade
▪ Assegurar que as realizações de disponibilidade do serviço atendem ou
excedem suas metas acordadas, através do gerenciamento de serviços e da
disponibilidade dos recursos relacionados

100
 ▪ Auxiliar no diagnóstico e resolução de incidentes e problemas relacionados à
disponibilidade
▪ Avaliar o impacto de todas as mudanças no plano de disponibilidade e na
disponibilidade de todos os serviços e recursos
▪ Garantir que as medidas proativas para melhorar a disponibilidade dos serviços
sejam aplicadas sempre que o custo for justificável para fazê-las
Quando um serviço é projetado, é necessário saber do gerenciamento da demanda
qual é a expectativa de uso deste serviço para que ele possa ser desenhado de forma
a atender a esta demanda com boa disponibilidade. É importante descobrir já no
estágio de Desenho se o serviço será de fato suportado pela infraestrutura de TI atual.
Muitas vezes é necessário fazer investimentos em servidores para que o serviço rode
no ambiente de produção com o nível de disponibilidade desejado.

Escopo
O escopo do gerenciamento de disponibilidade cobre desenho, implementação,
medição, gerenciamento e melhoria da disponibilidade de serviços de TI e
componentes.

O gerenciamento de disponibilidade inclui dois elementos-chave (veja figura na página

seguinte):

• Atividades reativas
Envolvem monitoramento, medição, análise e gerenciamento de todos os
eventos, incidentes e problemas envolvendo indisponibilidade. Estas atividades
são principalmente desempenhadas como parte dos papéis operacionais.

• Atividades proativas
Envolvem planejamento, desenho e melhoria proativas de disponibilidade.
Estas atividades são principalmente desempenhadas como parte dos papéis
de desenho e planejamento.

101
O diagrama abaixo apresenta estas duas atividades principais do gerenciamento de
disponibilidade.

Atividades reativas

Monitorar, medir, analisar,

reportar e revisar
disponibilidade de serviço
e componente Sistema de
informação
do gerenciamento
Investigar todas as de disponibilidade
indisponibilidades em
serviço e componentes e
instigar ações de remediação

Relatórios do
gerenciamento
de disponibilidade

Atividades proativas
Avaliação e Planejar e desenhar Plano de
gerenciamento serviços novos disponibilidade
de riscos e alterados

Implementar Revisar todos serviços Critérios de

contramedidas novos e alterados e testar desenho de
a custo justificável mecanismos de disponibilidade
disponibilidade e resiliência

Cronograma de
Revisão e testes de
melhoria contínua disponibilidade

© Crown copyright 2011. Reproduced under licence from Cabinet Office.

102
Conceitos básicos
O gerenciamento da disponibilidade é completado
por dois níveis interconectados:

• Disponibilidade do serviço: envolve todos

os aspectos da disponibilidade e
indisponibilidade do serviço, e impacto da
disponibilidade do componente ou potencial
impacto da indisponibilidade de um
componente na disponibilidade do serviço.

• Disponibilidade do componente: envolve

todos os aspectos na disponibilidade ou
indisponibilidade do componente.

O gerenciamento de disponibilidade monitora,

mede, analisa e reporta os seguintes aspectos:
• Disponibilidade
• Confiabilidade
• Sustentabilidade
• Função de negócio vital (FNV)

Disponibilidade
A capacidade de um serviço, componente ou item de configuração desempenhar suas
funções acordadas quando necessário. A disponibilidade é determinada por
confiabilidade, sustentabilidade, funcionalidade do serviço, desempenho e segurança.

A disponibilidade é normalmente calculada em porcentagens. Tal cálculo

frequentemente se baseia no tempo de serviço acordado e na indisponibilidade. A
melhor prática para calcular a disponibilidade de um serviço de TI é medir pela
perspectiva do negócio.

Exemplo: Se para um serviço foi acordado 98% de disponibilidade durante os dias

úteis das 07:00h às 19:00h, e o serviço ficou fora do ar por 2 horas durante este
período, seu percentual de disponibilidade foi ([12h por dia x 5 dias úteis - 2h]/60h) =
96,66%. Para calcular a disponibilidade utiliza-se a fórmula abaixo:

103
Confiabilidade
Medida do tempo em que um serviço de TI ou outro item de configuração pode
executar a sua função acordada sem interrupção. Frequentemente reportada como um
tempo médio entre incidentes do serviço (TMEIS) ou tempo médio entre falhas
(TMEF).

A confiabilidade do serviço pode ser melhorada aumentando a confiabilidade dos

componentes ou aumentando a resiliência do serviço referente à falha de um
componente específico (aumentando a redundância de componente, por exemplo,
usando técnicas de balanceamento de cargas).

Resiliência refere-se a habilidade de um serviço de TI ou de outro item de

configuração de resistir à falha ou de se recuperar de maneira oportuna depois de uma
falha.

A confiabilidade frequentemente medida e reportada como um tempo médio entre

incidentes do serviço (TMEIS) ou tempo médio entre falhas (TMEF). A figura abaixo
apresenta o ciclo de vida expandido do incidente representando estas duas métricas.

104
O gerenciamento de disponibilidade monitora, mede, analisa e reporta também a
sustentabilidade.

Sustentabilidade
Medida de quão rápido e eficaz um serviço de TI ou outro item de configuração pode
ser restaurado à operação normal após uma falha. A sustentabilidade é
frequentemente medida e reportada como TMRS.

A sustentabilidade é também usada no contexto de desenvolvimento de software ou

serviço de TI para significar a habilidade de este ser mudado ou reparado com
facilidade. E a sustentabilidade é frequentemente medida e reportada como TMRS
(Tempo Médio para Restaurar o Serviço).

Outro conceito a ser observado neste processo é Função de negócio vital (FNV)

Função de negócio vital (FNV)

Parte de um processo de negócio que é crítico para o sucesso do negócio. A função
de negócio vital é uma consideração importante no gerenciamento de continuidade de
negócio, gerenciamento de continuidade de serviço de TI e gerenciamento de
disponibilidade.

Quanto mais vital for a função de negócio, maior deverá que ser o nível de resiliência e
disponibilidade. Alguns aspectos a serem considerados para estas funções de
negócio:
▪ Alta disponibilidade
▪ Tolerância à falhas
▪ Operação contínua
▪ Disponibilidade contínua

105
Gerenciamento de capacidade
A capacidade da infraestrutura de TI, que normalmente inclui capacidade de
processador, armazenamento de registros no banco de dados, arquitetura do software,
etc., deve ser planejada logo no estágio de Desenho de serviço para que não haja
surpresas quando o novo serviço entrar no ambiente de produção. O gerenciamento
da capacidade é inicialmente suportado pela Estratégia de serviço, onde são
identificados: decisões e análises de requisitos do negócio, resultados do cliente que
influenciam o desenvolvimento de padrões de atividades do negócio, níveis de serviço
e pacotes de serviços. Isso cria indicadores contínuos necessários para alinhar a
capacidade de TI à demanda do negócio.

Capacidade, assim como disponibilidade, é uma parte importante da garantia de um

serviço.

Propósito
O propósito do gerenciamento de capacidade é garantir que a capacidade dos
serviços de TI e a infraestrutura de TI sejam capazes de atender aos requisitos
relacionados à capacidade e ao desempenho acordados de maneira oportuna e eficaz
em custo.

Objetivos
Os objetivos do gerenciamento de capacidade são:

▪ Produzir e manter um plano de capacidade adequado e atualizado, o qual

reflita as necessidades atuais e futuras do negócio
▪ Fornecer conselhos e orientações às áreas do negócio e de TI em relação a
questões relacionadas à capacidade e ao desempenho
▪ Assegurar que os resultados de desempenho do serviço atendem ou excedem
as metas de desempenho acordadas, através do gerenciamento do
desempenho e da capacidade tanto dos serviços como dos recursos
▪ Auxiliar no diagnóstico e resolução de incidentes e problemas relacionados ao
desempenho e capacidade
▪ Avaliar o impacto de todas as mudanças no plano de capacidade, e o
desempenho e capacidade de todos os serviços e recursos

106
 ▪ Garantir que as medidas proativas para melhorar o desempenho dos serviços
sejam aplicadas sempre que o custo seja justificável para fazê-las

Escopo
O gerenciamento de capacidade considera todos os
recursos necessários para entregar o serviço de TI e
planos de requisitos de negócio para curto, médio e
longo prazo. Este processo engloba todas as áreas
de tecnologia, tanto hardware como software, para
todos os componentes de tecnologia e ambientes da
TI.

O gerenciamento de capacidade deve considerar o

planejamento de espaço e o ambiente para a capacidade de sistemas.

Conceitos básicos
O processo de gerenciamento da capacidade é um processo extremamente técnico,
complexo e exigente, e para alcançar resultados ele requer o suporte de três
subprocessos:
Gerenciamento da capacidade de negócio

▪ Traduz as necessidades do negócio e planos em

requisitos para os serviços e para a infraestrutura de TI
▪ Assegura que os requisitos de negócio futuros para os
serviços de TI sejam quantificados, desenhados,
planejados e implantados em tempo hábil
Gerenciamento da capacidade de serviço

▪ Gerencia, controla e faz previsão de desempenho e

capacidade de ponta a ponta dos serviços de TI em uso
e de cargas de trabalho
▪ Assegura que o desempenho de todos os serviços,
conforme detalhado nas metas de serviço dentro dos
ANSs e RNSs, seja monitorado e medido, e que os
dados coletados sejam gravados, analisados e
reportados
Gerenciamento da capacidade de componente

▪ Gerencia, controla e faz previsão do desempenho,

utilização e capacidade de cada um dos componentes de
TI individuais
▪ Assegura que todos os componentes dentro da
infraestrutura de TI que tenham recursos finitos sejam
monitorados e medidos, e que os dados coletados sejam
gravados, analisados e reportados.

107
A figura abaixo que apresenta os três subprocessos de gerenciamento de capacidade.

Plano de capacidade

Uma das atividades principais deste processo é a produção do

plano de capacidade. Este documento tem tipicamente o
seguinte conteúdo:

▪ Introdução
 Serviços, tecnologia e recursos atuais
 Níveis de capacidade da organização
 Problemas atuais ou futuros
▪ Avaliações do negócio e cenários
▪ Escopo e termos de referência usados no plano
▪ Métodos utilizados para obtenção de informações
▪ Suposições
▪ Opções de melhoria do serviço
▪ Custos previstos
▪ Recomendações (benefícios, impactos, riscos envolvidos, recursos, custos
iniciais e de manutenção)

108
Gerenciamento de continuidade de serviço de TI

O Gerenciamento de continuidade de serviço de TI prepara o provedor de serviço para

a pior situação possível. Ele investiga, desenvolve e implementa opções de
recuperação de serviços quando uma interrupção grave no serviço ocorrer.

O Gerenciamento de continuidade de serviço de TI faz

parte de um processo maior, que não é de TI, mas sim
da organização como todo: o gerenciamento da
continuidade do negócio. A organização tem que ter
um “plano B” para que continue operando mesmo
apesar de crises ocorrerem. A TI, como parte
essencial para o negócio operar, precisa também
elaborar o seu plano de continuidade. Sendo assim, se
o prédio onde está situado o escritório principal da
organização sofrer um incêndio, deve haver um plano
para que a organização continue prestando serviço
aos seus clientes em outro local. Neste outro local,
haverá necessidade de serviços primários serem
fornecidos aos clientes, e estes serviços dependem da TI para funcionar.

Como a continuidade dos serviços de TI faz parte da continuidade do negócio, a

escolha final sobre qual opção de recuperação a ser usada é feita pelo negócio, como
parte do Acordo de Nível de Serviço. O custo geralmente é um fator na seleção da
opção apropriada de recuperação. Por exemplo, em um banco é inadmissível que o
internet bank fique fora do ar por algumas horas durante o período comercial devido a
problemas no datacenter principal. Se isto de fato acontecer, a imagem do banco será
afetada, ele pode perder clientes e credibilidade. Por isso a TI de uma instituição
bancária precisa de um plano de continuidade com opção de recuperação
praticamente imediata. Se o datacenter principal deixar de operar, o sistema backup
deve entrar no ar imediatamente. Este é um tipo de recuperação que custa caro para o
negócio, mas é essencial para a sobrevivência da organização.

Propósito
O propósito do processo de gerenciamento de continuidade de serviço de TI é apoiar
de forma geral o processo de gerenciamento da continuidade de negócio (GCN)
assegurando que, por meio do gerenciamento de riscos que poderiam seriamente
afetar os serviços de TI, o provedor de serviços de TI possa sempre prover o mínimo
nível de serviço acordado relacionado à continuidade do negócio.

109
Objetivos
Os objetivos do gerenciamento de continuidade de serviço de TI são:

▪ Produzir e manter um conjunto de planos de continuidade dos serviços de TI

que suportam os planos de continuidade de negócios (PCN) da organização
▪ Realizar regularmente a análise de impacto no negócio (AIN) para garantir que
todos os planos de continuidade são mantidos em conformidade com os
requisitos e impactos das mudanças de negócio
▪ Conduzir regularmente a análise e gerenciamento de risco, especialmente em
conjunto com o gerenciamento de disponibilidade e o gerenciamento de
segurança da informação
▪ Fornecer conselho e orientação a todas as outras áreas do negócio e de TI
sobre questões relacionadas à continuidade e à recuperação
▪ Assegurar que a continuidade e os mecanismos adequados de recuperação
estejam implantados para atender ou superar as metas acordadas de
continuidade de negócio
▪ Avaliar o impacto de todas as mudanças nos planos de continuidade de serviço
de TI e suportar métodos e procedimentos
▪ Garantir que as medidas proativas para melhorar a disponibilidade dos serviços
sejam implementadas sempre que o custo for justificável para tal
▪ Negociar e acordar os contratos necessários com fornecedores para a provisão
de habilidade e recuperação necessária para suportar todos os planos de
continuidade em conjunto com o processo de gerenciamento de fornecedor

Escopo
Este processo foca em eventos que o negócio considerar significativos o suficiente
para serem tratados como um “desastre”. Eventos menos significativos serão tratados
como parte do processo gerenciamento de incidente.

O gerenciamento de continuidade de serviço de TI considera os ativos e configurações

de TI que suportam os processos de negócio e não cobre riscos de longo prazo tais
como mudança de direção, reestruturação, diversificação do negócio, entre outros.

Este processo inclui:

▪ Acordar o escopo do gerenciamento de continuidade de serviço de TI e

políticas adotadas
▪ Análise de impacto no negócio (AIN)
▪ Avaliação e gerenciamento de riscos
▪ Produção de uma estratégia de continuidade de serviço de TI
▪ Produção de um plano de continuidade de serviço de TI
▪ Testes dos planos
▪ Operação e manutenção contínua dos planos

110
Conceitos básicos

Análise de impacto no negócio

A análise de impacto no negócio – AIN (em inglês, business impact analysis – BIA) é
feita com ajuda do processo de gerenciamento financeiro e complementada neste
processo. A AIN quantifica o impacto que a perda do serviço de TI teria no negócio. A
análise de risco identifica ameaças potenciais para a continuidade e a probabilidade
de elas acontecerem. Isto também inclui tomar medidas para gerenciar as ameaças
identificadas, quando o custo se justificar.

Basicamente esta análise deve:

▪ Identificar os serviços críticos ao negócio

▪ Determinar os efeitos da indisponibilidade
▪ Avaliar cenários de impacto
▪ Analisar obrigações legais que a empresa deve cumprir
▪ Analisar quanto tempo a empresa aguentaria sem os serviços de TI
▪ Avaliar os requisitos mínimos de recuperação (pessoas, estruturas e serviços)
para manter os processos críticos para o negócio
▪ Determinar o tempo mínimo e máximo dos níveis de serviços a serem
recuperados
▪ Determinar quais processos de negócio devem ser recuperados por completo

Avaliação de riscos
Entendimento da probabilidade que um desastre ou outra
interrupção no serviço poderá de fato ocorrer. Falhas na avaliação
de todos os riscos relevantes deixam a organização vulnerável a
possíveis interrupções.

A avaliação de riscos identifica:

▪ Riscos a processos ou a um serviço em particular

▪ Níveis de ameaças e vulnerabilidades
▪ Níveis de risco
▪ Medidas iniciais de redução de riscos

111
Exemplo de resultado de uma avaliação de riscos:

Ameaça Vulnerabilidade Probabilidade Efeito/impacto Medida de controle

Enchente As instalações da Média Estrago da Colocar o datacenter

TI estão no água,falta de em andar seguro.
subsolo do acesso.
prédio.

Blackout A empresa está Média Perda de Utilizar gerador de

elétrico situada em uma dados, perda energia.
ilha e os cabos de de controles de
energia que segurança. Utilizar estação elétrica
alimentam a auxiliar.
cidade passam
debaixo da ponte.

Falha no Um hacker pode Alta Parada dos Fazer backup com base
servidor de invadir a nossa processos de de dados duplicada.
aplicação do rede e alterar os faturamento,
ERP/SAP dados. vendas, etc.

Muitas pessoas têm dificuldade para entender as diferenças entre os processos de

gerenciamento da disponibilidade e de gerenciamento da continuidade de serviço.

O gerenciamento da disponibilidade foca em obter a melhor disponibilidade possível

para os serviços de TI que estão rodando a partir do ambiente de produção. Como
estratégia para aumentar a disponibilidade podem ser implantadas tecnologias como
servidores redundantes, discos RAID e espelhamento de discos. Além de tecnologias,
outros elementos influenciam a disponibilidade do serviço, como ter pessoas na
equipe de TI para dar manutenção aos hardwares e softwares e contratos com
terceiros estabelecendo metas apropriadas.

Já o gerenciamento da continuidade de serviço foca em elaborar um plano de

continuidade com estratégias de recuperação de serviço caso algum evento de
desastre aconteça. Este é um processo que garante que a TI irá continuar fornecendo
os serviços essenciais mesmo apesar das crises. Entretanto, como hoje as estratégias
de recuperação para muitos provedores são baseadas em opções de recuperação
imediata, acaba se fazendo muita confusão entre os dois processos.

Podemos até dizer que o gerenciamento da disponibilidade atua mais na infraestrutura

de produção e o gerenciamento da continuidade de serviço atua nos bastidores
elaborando um “plano B” caso a infraestrutura de produção tenha falhas, sendo então
necessário invocar este plano.

112
Gerenciamento de segurança da informação

O gerenciamento da segurança da informação é um processo

importante que visa controlar a provisão de informações e evitar seu
uso não autorizado. Por muitos anos, o gerenciamento da segurança
da informação não foi tratado como assunto de importância nas
organizações – mas isto está mudando.

A informação hoje é um dos ativos mais valiosos. A segurança da

informação é hoje considerada uma das questões críticas da
organização, visto que todos os dados estão armazenados em aplicativos de TI. Há
uma preocupação constante com entrada de vírus, ataques de hackers e acessos não
autorizado aos dados dos sistemas.

Propósito
O propósito do gerenciamento de segurança da informação é alinhar a segurança de
TI com a segurança do negócio e garantir que confidencialidade, integridade e
disponibilidade dos ativos, informações, dados e serviços de TI de uma organização
correspondam às necessidades acordadas do negócio.

Objetivos
O objetivo deste processo é proteger os interesses de quem utiliza informações,
sistemas e comunicações contra danos resultantes de falhas de confidencialidade,
integridade e disponibilidade.

Para a maioria das organizações, o objetivo da segurança é cumprida quando:

▪ A informação é observada por ou divulgada somente para aqueles que têm o

direito de acesso (confidencialidade)
▪ A informação está completa, precisa e protegida contra modificações não
autorizadas (integridade)
▪ A informação está disponível e utilizável quando necessário e os sistemas que
a fornecem podem resistir adequadamente a ataques, prevenir ou recuperar-se
de falhas (disponibilidade)
▪ Transações comerciais, bem como o intercâmbio de informação entre
empresas ou com parceiros, são confiáveis (autenticidade e não-repúdio)

Escopo
O gerenciamento de segurança da informação deve ser um ponto focal para todas as
questões de segurança de TI, e precisa garantir que uma política de segurança da
informação é produzida, mantida e implementada, cobrindo o uso e abuso de sistemas
e serviços de TI.

113
Este processo precisa entender o ambiente de segurança do negócio e da TI,
incluindo:

▪ Políticas e planos de segurança do negócio

▪ Operações de negócio atuais e seus requisitos de segurança
▪ Planos futuros do negócio e requisitos
▪ Requisitos legais e regulatórios
▪ Obrigações e responsabilidades relacionadas à segurança contidas nos ANSs
▪ O negócio e riscos de TI e seu gerenciamento

Conceitos básicos

Política de segurança da informação

Esta política é uma das principais saídas deste
processo. A política de segurança da informação nada
mais é do que um documento que estabelece um
conjunto de controles de segurança que atendem aos
objetivos internos da organização e conformidades para
atender a leis e regulamentos externos. Esta política
deve estar disponível para todos os clientes, usuários e
equipe da TI e deve cobrir todas as áreas de segurança,
ser apropriada, atender às necessidades do negócio e
incluir:

▪ Visão geral da política de segurança da informação

▪ Política de uso e abuso de ativos de TI
▪ Política de controle de acesso
▪ Política de controle de senha
▪ Política de uso de e-mail
▪ Política de uso da internet
▪ Política de uso de antivírus
▪ Política de classificação de informações
▪ Política de classificação de documentos
▪ Política de acesso remoto
▪ Política com relação ao acesso de fornecedor de serviços de TI, de informação
e de componentes
▪ Política de eliminação de ativos
▪ Política para retenção de registros

114
Gerenciamento de fornecedor

Sabemos que os fornecedores e parceiros são elementos

importantes na cadeia de valor. O desempenho deles é vital para
que o serviço seja entregue com o nível requerido.

Hoje muitos serviços são terceirizados, como telefonia,

hardware, softwares, hospedagem, datacenter, suporte
especializado, suporte de primeiro nível, etc. O gerenciamento
de fornecedor assegura que os fornecedores e os serviços que
eles fornecem são gerenciados para suportar as metas dos
serviços de TI e as expectativas do negócio (cliente).

Propósito
O propósito do processo de gerenciamento de fornecedor é a obtenção de valor para o
dinheiro a partir de fornecedores, além de fornecer uma qualidade de serviço de TI
adequada ao negócio, garantindo que todos os contratos e acordos com fornecedores
suportam as necessidades do negócio e que todos os fornecedores cumpram os seus
compromissos contratuais.

É essencial que o gerenciamento de fornecedor esteja envolvido em todos os estágios

do ciclo de vida: da Estratégia ao Desenho, na Transição e na Operação até a
Melhoria contínua de serviço. Este processo faz parte do estágio de Desenho, pois é
neste estágio em que se precisa identificar e selecionar fornecedores para projetar um
novo serviço.

Uma missão importante neste processo é obter valor pelo dinheiro e assegurar que
fornecedores atinjam os objetivos contidos nos termos e condições dos contratos e
acordos. Como quase tudo é terceirizado, hoje boa parte dos custos de operações de
TI está relacionada aos contratos com terceiros. Todo contrato deve ter uma
justificativa e deve gerar valor de alguma forma. Se o contrato não gera valor, é
necessário descontinuá-lo. Muitas organizações conseguem economizar muito
dinheiro apenas nas revisões de contratos existentes.

Objetivos
Os principais objetivos do gerenciamento de fornecedor são:

▪ Obter valor para o dinheiro a partir de fornecedores e contratos

▪ Garantir que os contratos com os fornecedores estejam alinhados com as
necessidades do negócio, e em conjunto com o GNS suportar e alinhar as
metas acordadas em RNSs e ANSs (isto quer dizer que se o provedor de
serviço negocia com o cliente que ele vai entregar determinado serviço com
98% de disponibilidade, então todos os componentes entregues por terceiros
devem ter também no mínimo 98% de disponibilidade)
▪ Gerenciar relacionamentos com fornecedores
▪ Gerenciar o desempenho de fornecedores

115
 ▪ Negociar e acordar contratos com fornecedores, e gerenciá-los durante o seu
ciclo de vida
▪ Manter uma política para fornecedores e suportar o sistema de informação de
gerenciamento de fornecedor e contrato (SIGFC)

Escopo
O processo de gerenciamento de fornecedor deve incluir o gerenciamento de todos os
fornecedores e contratos necessários para apoiar o fornecimento de serviços de TI
para o negócio. Portanto, o processo de gerenciamento de fornecedores deve incluir:

▪ Implementação e execução da política para fornecedores

▪ Manutenção de sistema de informação de gerenciamento de fornecedor e
contrato (SIGFC)
▪ Categorização de fornecedores e contratos e avaliação de riscos
▪ Avaliação e seleção de fornecedores e contratos
▪ Desenvolvimento, negociação e acordo de contratos
▪ Revisão, renovação e encerramento de contratos
▪ Gerenciamento de fornecedores e desempenho de fornecedores
▪ Identificação e oportunidades de melhoria para inclusão no registro da MCS e
implementação dos planos de melhoria relacionados
▪ Manutenção de padrões de contrato, termos e condições
▪ Gerenciamento de resolução de disputas contratuais

Conceitos básicos

Categoria de fornecedores
O processo de gerenciamento
de fornecedor deve fornecer um
esquema para categorizar os
fornecedores, sua importância
para o provedor de serviços e
os serviços fornecidos para a
empresa.

Uma maneira de categorizar os

fornecedores é avaliar o risco e
o impacto associado com o uso
do fornecedor, o valor e a
importância do fornecedor e de
seus serviços para o negócio,
como ilustrado abaixo:

116
Sugere-se que os fornecedores sejam classificados conforme a sua avaliação de risco
e impacto, e de valor e importância:

 Fornecedores estratégicos: que envolvem troca de informação confidencial ou

estratégica.
 Fornecedores táticos: que envolvem atividades comerciais significativas.
 Fornecedores operacionais: que fornecem serviços ou produtos operacionais.
 Fornecedores de commodity: fornecedores de papel, cartuchos de tinta, etc.

O gerenciamento de fornecedor será baseado na classificação de fornecedores. Por

exemplo: um fornecedor estratégico é gerenciado por alguém da alta direção. Já um
fornecedor operacional pode ser gerenciado por alguém em função de menor escalão.
Cada fornecedor precisa de um tratamento diferenciado conforme sua importância.

5.4 Tipos de ferramentas de suporte ao Desenho de

serviço
Ferramentas podem assegurar que os processos de Desenho de serviço possam
funcionar de forma eficiente. Alguns tipos de ferramentas que podem ser utilizadas no
Desenho de serviço são:

▪ Ferramentas para suportar o desenho de:

 Hardware, software, ambiente, processos e dados
▪ Ferramentas de GNS:
 Relatórios com gráficos
 Monitoração de metas de serviço, componentes, processos,
fornecedores
▪ Ferramentas de discovery que permitam fazer relacionamentos entre os
componentes dos serviços
▪ Ferramentas para gestão de portfólio de serviço e catálogo de serviço
▪ Ferramentas de medição e relatórios

117
6 - Transição de serviço

Depois que o serviço foi projetado

no estágio Desenho de serviço, o
próximo estágio do ciclo de vida do
serviço é a Transição de serviço.
Este estágio vai receber como
entrada o pacote de desenho de
serviço (PDS) a partir do estágio de
desenho de serviço para então
construir e preparar o serviço para
colocar em operação no ambiente
de produção. A transição de serviço
é responsável pelo gerenciamento
de mudanças e liberações para um
serviço, assim como controlar
modificações no serviço.

6.1 Propósito, objetivos, escopo e valor agregado ao

negócio
Propósito da transição de serviço
O propósito do estágio Transição de serviço é garantir que serviços novos,
modificados ou obsoletos atendam às expectativas do negócio conforme documentado
nos estágios de Estratégia de serviço e Desenho de serviço.

Objetivos da transição de serviço

Os principais objetivos da Transição de serviço são:

▪ Planejar e gerenciar mudanças em serviços de forma eficiente e eficaz

▪ Gerenciar os riscos relacionados a serviços novos, modificados ou obsoletos
▪ Implementar com sucesso liberações de serviço dentro de ambientes
suportados
▪ Estabelecer expectativas corretas sobre o desempenho e uso de serviços
novos e modificados
▪ Garantir que alterações no serviço criarão valor esperado ao negócio
▪ Fornecer conhecimento e informação de boa qualidade sobre serviços e ativos
de serviço

118
Escopo da transição de serviço
A Transição de serviço cobre a Transição de serviços novos e modificados para dentro
de ambientes suportados, incluindo planejamento de liberação, construção, testes,
avaliação e implantação.

A Transição de serviço também cobre retirada e transferência de serviços entre

provedores de serviço.

Este livro foca em como garantir que os requisitos da Estratégia de serviço,

desenvolvidos no Desenho de serviço, são efetivamente realizados na Operação de
serviço enquanto os riscos de falhas e subsequentes interrupções são controlados.

O diagrama abaixo exibe todos os processos dentro do escopo do estágio de

Transição de serviço.

119
Valor que transição de serviço agrega ao negócio
A adoção e a implementação de abordagens padrão e consistentes para a Transição
de serviço irão:

▪ Permitir estimar custo, prazo, necessidades de recursos e riscos associados ao

estágio Transição de serviço com mais precisão nos projetos
▪ Resultar em volumes mais altos de mudanças com sucesso
▪ Permitir que os ativos de Transição de serviço possam ser compartilhados e
reusados entre projetos e serviços
▪ Reduzir atrasos decorrentes de conflitos e dependências – por exemplo, se
múltiplos projetos precisam usar o mesmo ambiente de teste ao mesmo tempo
▪ Aumentar a confiança de que serviços novos ou modificados possam ser
entregues de acordo com a especificação sem afetar de forma inesperada
outros serviços ou partes interessadas

6.2 Processos da transição de serviço

Os processos da Transição de serviço selecionados para exame ITIL Foundation são
os seguintes:

• Planejamento e suporte da transição

• Gerenciamento de configuração e de ativo de serviço
• Gerenciamento de conhecimento
• Gerenciamento de mudança
• Gerenciamento de liberação e implantação
O livro Transição de Serviço da ITIL edição 2011 aborda 7 processos. Os processos
de validação e teste de serviço e avaliação de mudança não fazem parte do escopo do
exame ITIL Foundation.

Planejamento e suporte da transição

Para que o projeto de transição de um serviço tenha sucesso, é necessário que o

trabalho seja gerenciado para assegurar que o projeto tenha recursos corretos, esteja
planejado e completado para atender as necessidades de negócio. Este processo vai
fornecer, de forma geral, um suporte para os projetos de transição.

Propósito
O propósito do planejamento e suporte da Transição inclui fornecer um planejamento
geral para todos os processos de Transição de serviços e coordenar os recursos que
eles requerem.

120
Objetivos
Os objetivos do planejamento e suporte da Transição são:

▪ Planejar e coordenar os recursos para garantir que os requisitos da Estratégia

de serviço documentados no Desenho são realizados efetivamente na
Operação de serviço
▪ Coordenar atividades entre projetos, fornecedores e equipe de serviço quando
requeridas
▪ Estabelecer serviços novos ou modificados em ambientes suportados dentro
de estimativas de custos, qualidade e prazo previstos
▪ Estabelecer sistemas de gerenciamento de informação e ferramentas,
tecnologia e arquiteturas, processos de gerenciamento de serviços e métodos
de medição e métricas para atender aos requisitos estabelecidos durante o
estágio de Desenho de serviço
▪ Garantir que todas as partes adotam a estrutura padrão de processos para
melhorar a eficácia e eficiência das atividades de planejamento e coordenação
▪ Fornecer planos claros e abrangentes que possibilitem aos projetos de
mudança do cliente e do negócio alinhar suas atividades com os planos de
Transição de serviço
▪ Identificar, gerenciar e controlar riscos para minimizar a chance de falha e
interrupções durante as atividades de transição
▪ Monitorar e melhorar o desempenho da Transição de serviço durante o estágio
de transição

Escopo
O escopo do planejamento e suporte da transição inclui:

▪ Manter políticas, padrões e modelos para atividades e processos de Transição

de serviço
▪ Orientar cada mudança importante ou novo serviço durante todos os processos
de Transição de serviço
▪ Coordenar os esforços necessários para permitir que várias transições possam
ser gerenciadas ao mesmo tempo
▪ Priorizar recursos na Transição de serviços
▪ Planejar o orçamento e os recursos necessários para cumprir as necessidades
da Transição de serviços
▪ Rever e melhorar o desempenho do planejamento de transição
▪ Garantir que a Transição de serviço seja coordenada com o gerenciamento de
projetos e programas, atividades de desenho e desenvolvimento de serviços
O escopo do planejamento e suporte da transição exclui o planejamento detalhado da
construção, testes e implementação de mudanças (parte do gerenciamento de
mudança e gerenciamento de liberação e implantação).

121
Gerenciamento de configuração e de ativo de serviço

O gerenciamento da configuração é o
processo que identifica todos os ICs
necessários para entregar os serviços de
TI. Este processo vai fornecer um modelo
lógico da infraestrutura de TI em que os
serviços de TI são relacionados com os
diferentes componentes necessários para
fornecer o serviço.

Este é um processo importante na

Transição de serviço, pois é a partir do
entendimento do que existe na
infraestrutura que poderemos fazer o
planejamento da transição de um serviço novo ou alterado. A documentação dos
componentes e seus relacionamentos não será utilizada apenas pelos processos da
Transição de serviço, mas também por todos os outros processos do ciclo de vida do
serviço.

Propósito
O propósito do processo gerenciamento de configuração e de ativo de serviço inclui
garantir que ativos necessários para entregar o serviço são controlados
adequadamente e garantir que informação precisa e confiável sobre estes ativos está
disponível quando ela for necessária. Esta informação inclui detalhes sobre como os
ativos de serviço foram configurados e o relacionamento entre eles.

Objetivos
Os objetivos do gerenciamento de configuração e ativo de serviço são:

▪ Garantir que os ativos sob o controle da organização de TI são identificados,

controlados e bem cuidados durante todo seu ciclo de vida
▪ Identificar, controlar, registrar, auditar e verificar os serviços e outros itens de
configuração, incluindo as versões, linhas de base, componentes constituintes,
seus atributos e relacionamentos
▪ Responsabilizar-se por gerenciar e proteger a integridade do IC durante o ciclo
de vida do serviço, trabalhando com o gerenciamento de mudança para
garantir que apenas componentes autorizados são usados e apenas mudanças
autorizadas são realizadas
▪ Garantir a integridade dos ICs e configurações necessárias para controlar os
serviços, estabelecendo e mantendo um sistema de gerenciamento de
configuração (SGC) preciso e completo
▪ Manter as informações de configuração referentes ao histórico, estados
planejados e atuais dos serviços e outros ICs

122
 ▪ Apoiar os processos de gerenciamento de serviço e os serviços, fornecendo
informações sobre a configuração exata para que as pessoas possam tomar
decisões na hora certa

Escopo
O escopo do gerenciamento de configuração e ativo de serviço (GCAS) inclui o
gerenciamento do ciclo de vida completo de cada item de configuração e interfaces
com provedores de serviços internos e externos, onde houver ativos e itens de
configuração que precisam ser controlados (como ativos compartilhados, por
exemplo).

Conceitos básicos
Item de configuração (IC)
É qualquer componente ou outro ativo de
serviço que precise ser gerenciado de forma a
entregar um serviço de TI.

ICs tipicamente incluem serviços de TI, hardware,

software, prédios, pessoas e documentação formal
tais como documentação de processo e acordos
de nível de serviço. Suas informações são
registradas no SGC (sistema de gerenciamento de
configuração) e mantidas durante o seu ciclo de
vida por este processo.

ICs estão sob controle do processo gerenciamento

de mudança.

123
Existe uma variedade de ICs. Os exemplos de categorias a seguir ajudam a identificá-
los:

ICs do ciclo de Caso de negócio, planos de grenciamento de serviços, planos do

vida do serviço ciclo de vida do serviço, pacote de Desenho de serviço, planos de
liberação e de mudança e planos de teste.

ICs de serviço Ativos de habilidade do serviço (gerenciamento, organização,

processos, conhecimento, pessoas), ativos de recursos de
serviço (dinheiro, sistemas, aplicativos, informação, dados,
infraestrutura e pessoas), modelo de serviço, pacote de serviço,
pacote de liberação e critérios de aceite de serviço.

ICs da Estratégia da organização e outras políticas.

organização

ICs internos Aqueles que são entregues por projetos individuais, incluindo
ativos tais como hardware e software que são requeridos para
entregar e manter o serviço e infraestrutura.

ICs externos Requisitos de clientes externos e acordos, liberações de

fornecedores e subcontratados e serviços externos.

ICs de interface Documentações de escalação e acordos de interface.

No SGC serão armazenados os atributos e relacionamentos de cada IC. Veja

informações comuns para um IC que podem ser armazenadas no SGC:

Cada IC pode ter atributos como: Cada IC pode ter relacionamentos

▪ ID com outros ICs como:
▪ Nome ▪ Conectado à
▪ Versão ▪ Depende de
▪ Tipo ▪ Mantido por
▪ Modelo ▪ Interfaceado por
▪ Fabricante ▪ Usado por
▪ Número de série ▪ Cópia de
▪ Status ▪ Consiste de
▪ Etc. ▪ Etc.

Os relacionamentos entre ICs são informação essencial a ser considerada neste

processo. A partir dos relacionamentos poderemos avaliar, por exemplo, qual seria o
impacto de uma mudança em um determinado serviço ou componente do serviço e
identificar o que pode estar causando um incidente.

O status é outra informação importante, pois mostra em que situação o IC se encontra

dentro do seu ciclo de vida individual. O status pode ser: em estoque, em teste, em
produção, aposentado, etc.

124
Os relacionamentos entre ICs podem ser representados por meio de um modelo de
configuração. Este modelo é usado também para:
▪ Avaliar o impacto e causa de incidentes e problemas
▪ Impacto de mudanças
▪ Planejar o desenho de alterações no serviço
▪ Planejar liberações

A figura abaixo apresenta um exemplo de modelo de configuração.

Linha de base de configuração

Um instantâneo que é usado como um ponto de referência para uma configuração de
um serviço/aplicativo.

Linhas de base de configuração devem ser capturadas antes da realização de

mudanças na infraestrutura.

125
Sistema de gerenciamento de configuração (SGC)
Conjunto de ferramentas, dados e informações usado para dar suporte ao
gerenciamento de configuração e ativo de serviço.

O SGC inclui ferramentas para coletar, armazenar, atualizar, analisar e apresentar

dados sobre todos os itens de configuração e seus relacionamentos. Ele também pode
incluir informação sobre incidentes, problemas, erros conhecidos, mudanças e
liberações.

O SGC é mantido por este processo e usado por todos os demais processos de
gerenciamento de serviços de TI. Também pode fazer um vínculo com funcionários,
fornecedores, locais e unidades de negócio, cliente e usuários.

Muitas organizações têm adotado softwares de gerenciamento de serviços que

contemplam o recurso SGC embutido. É comum uma organização ter mais de um
aplicativo (um para cada finalidade). Por exemplo: um aplicativo para a central de
serviço registrar incidentes, outro aplicativo para coleta de inventário e ativos, e outro
para gerenciar disponibilidade dos serviços. Cada aplicativo destes pode ter o seu
próprio banco de dados de configuração (BDGC) - e consequentemente a organização
terá vários BDGCs. Os diversos BDGCs que existirem na organização precisam ser
integrados para que as informações não fiquem duplicadas e desatualizadas. Para
isso se cria um BDGC integrado. O SGC é o sistema que reúne todas as informações
disponíveis sobre a configuração da infraestrutura e serviços de TI que podem estar
dentro deste BDGC integrado. O SGC consiste de quatro camadas conforme ilustrado
na figura a seguir.

126
O SGC pode ser composto por várias camadas:
• Camada de apresentação: as informações são formatadas em relatórios para
determinados públicos.
• Camada de processamento de conhecimento: é onde se produzem as querys
(consultas) para extrair os dados para serem exibidos em relatórios.
• Camada de integração de informação: é a que coleta e estrutura os dados.
• Camada de dados: contém dados e informações de diferentes origens, como
BDGCs, ferramentas de inventário, informações de projetos.

Biblioteca de mídia definitiva (BMD)

A ITIL ainda define algumas bibliotecas que podem ficar sobre o controle do
gerenciamento da configuração e de ativo de serviço.

Biblioteca de mídia definitiva (BMD)

Uma ou mais localidades em que as versões definitivas e autorizadas de todos os
itens de configuração de software são armazenadas de maneira segura. A biblioteca
de mídia definitiva também pode conter itens de configuração associados, como
licenças e documentação.

127
É uma área de armazenamento físico e todos os softwares na BMD estão sob controle
do gerenciamento de mudanças e são registrados no SGC. Sendo assim, são
controlados pelo processo GCAS.

A BMD contém cópias-mestre de todos os ativos de software desenvolvidos

internamente ou adquiridos, ferramentas de gerenciamento assim como aplicativos e
licenças e documentação. Antes de serem armazenados nesta biblioteca, os softwares
devem ser verificados: se estão completos, corretos e sem vírus. A BMD serve como
fonte única para distribuição. É a partir desta biblioteca que o processo gerenciamento
de liberação vai fazer as instalações de softwares. Sempre que alguém for instalar um
software na maquina do usuário, deve utilizar os softwares que estão salvos na BMD.

Na maioria das organizações a BMD pode ser representada por um armário onde se
guardam todos os CDs originais de instalação de software, ou pode ainda ser
representada por um servidor de arquivos no qual estão salvas as cópias originais dos
softwares. Analise o diagrama abaixo: na BMD se mantém a mídia física do software e
no BDGC, que faz parte do SGC, encontramos a informação lógica do software. No
BDGC vamos registrar os atributos do software: detalhes da licença, usuários que
estão utilizando cada licença, etc. Recomenda-se que todos os softwares que estão
salvos na BMD constem no SGC.

128
Gerenciamento de conhecimento

Propósito
O propósito do processo gerenciamento de conhecimento inclui compartilhar
perspectivas, ideias, experiência e informações, e garantir que estejam disponíveis no
lugar certo no momento certo. Este processo possibilita a tomada de decisões bem
informada e melhora a eficiência reduzindo a necessidade de redescobrir o
conhecimento.

A ideia deste processo é saber o que as pessoas precisam para tomar decisões – não
só relacionadas ao estágio Transição de serviço, mas com todos os outros estágios do
ciclo de vida do serviço. Então, neste processo vamos levantar quais informações as
pessoas precisam e em que momento elas vão precisar.

Estas informações podem estar no SGC, podem estar na base de incidentes,

problemas e erros conhecidos ou no banco de capacidade. Em praticamente todos os
processos nós geramos dados e informações. Este processo se preocupa em como
disponibilizar estas informações para as pessoas certas e no momento certo.
Disponibilizando as informações corretamente será possível tomar decisões mais
adequadas para o que precisa ser feito. O gerenciamento do conhecimento está
relacionado a reter o conhecimento, a fazer com que as informações sejam melhor
aproveitadas na organização para melhorar os serviços.

Objetivos
Os objetivos do gerenciamento de conhecimento são:

▪ Melhorar a qualidade da tomada de decisão gerencial assegurando que

conhecimento, informações e dados seguros e confiáveis estejam disponíveis
durante todo o ciclo de vida
▪ Permitir ao provedor de serviços ser mais eficiente, melhorar a qualidade do
serviço, aumentar a satisfação do cliente e reduzir o custo do serviço por meio
da redução da necessidade de redescobrir conhecimento
▪ Garantir que a equipe tenha um entendimento claro e em comum do valor que
os seus serviços fornecem aos clientes
▪ Manter o sistema de gerenciamento de conhecimento de serviço (SGCS)
▪ Coletar, analisar, armazenar, compartilhar, usar e manter conhecimento,
informação e dados no provedor de serviço

Escopo
O gerenciamento de conhecimento é um processo que atua em todo o ciclo de vida e,
portanto, é referenciado em todas as publicações da ITIL.

Inclui supervisão do gerenciamento de conhecimento e informações/dados dos quais

deriva o conhecimento.

129
Exclui atenção detalhada na captura, manutenção e uso dos dados de configuração
estabelecidos no gerenciamento de configuração.

Conceitos básicos
O gerenciamento do conhecimento é exibido tipicamente dentro de uma estrutura de
Dados-para-Informação-para-Conhecimento-para-Sabedoria (DICS) conforme a figura
abaixo. O gerenciamento de conhecimento se preocupa em converter dados em
informação e em que a informação seja aproveitada corretamente gerando e
facilitando conhecimento e sabedoria.

É um conjunto de fatos sobre eventos. Muitas organizações

capturam vários dados significativos em banco de dados altamente
Dado
estruturados usando sistemas de gerenciamento de configuração e
ativo de serviço e ferramentas de gerenciamento de serviços.

Vem a partir do fornecimento do contexto para os dados. A

Informação informação é geralmente armazenada em conteúdo
semiestruturado, tais como documentos, e-mail e multimídia.

É composto por experiências tácitas, ideias, insights, valores e

julgamentos de indivíduos. Pessoas ganham conhecimento tanto a
Conhecimento partir da experiência de seus pares como a partir da análise de
informação (e dados). A partir da síntese destes elementos, um novo
conhecimento é criado.

Faz o uso do conhecimento para criar valor por meio de decisões

Sabedoria corretas e bem informadas. Sabedoria envolve ter a aplicação e a
consciência contextual para fornecer julgamento.

130
Nós podemos utilizar ferramentas para transformar dados em relatórios, identificar
padrões de comportamento nos incidentes e fazer associações até chegar ao nível de
conhecimento. Entretanto, a sabedoria é algo que uma ferramenta não pode nos dar.
As pessoas precisam habilidades para usar o conhecimento disponível na organização
e a partir dele tomar decisões corretas.

Sistema de gerenciamento do conhecimento de serviço – SGCS

O gerenciamento do conhecimento está focado dentro do sistema de gerenciamento

do conhecimento do serviço (SGCS). O SGCS preocupa-se com o conhecimento e é
suportado por um conjunto de dados. Estes dados são obtidos a partir de um local
central, ou SGC, e de um BDGC. Este processo preocupa-se em como extrair dados
de dentro do SGC e transformá-los em informações para gerar conhecimento.

Sistema de gerenciamento de conhecimento de serviço (SGCS)

Um conjunto de ferramentas e bancos de dados que são usados para gerenciar
conhecimento, informações e dados. O sistema de gerenciamento de conhecimento
de serviço inclui o sistema de gerenciamento de configuração, além de outros bancos
de dados e sistemas de informação.

O sistema de gerenciamento de conhecimento de serviço inclui ferramentas para

coletar, armazenar, gerenciar, atualizar, analisar e apresentar todos os
conhecimentos, informações e dados que um provedor de serviço de TI precisa para
gerenciar o ciclo de vida completo dos serviços de TI. O SGCS inclui o SGC, assim
como outros bancos de dados e sistemas de informação conforme exibido no
diagrama abaixo.

© Crown copyright 2011. Reproduced under licence from Cabinet Office.

131
Entretanto, o SGCS é um conceito que abrange uma base de conhecimento mais
ampla. Por exemplo:

▪ Portfólio de serviço
▪ Biblioteca de mídia definitiva
▪ ANSs, contratos, ANOs
▪ Política de segurança da informação
▪ Sistema de informação de gerenciamento de fornecedor e contrato (SIGFC)
▪ Orçamentos e modelos de custos
▪ Planos de negócio
▪ Registro da MCS e planos de melhoria de serviço (PMSs)
▪ Plano de capacidade do sistema de gerenciamento de informação de
capacidade (SIGC)
▪ Plano de disponibilidade e sistema de informação do gerenciamento de
disponibilidade (SIGD)
▪ Procedimentos de invocação de continuidade de serviço
▪ Relatório de serviço
▪ Fórum de discussão para participantes de processo
▪ Planos de projetos
▪ Banco de dados de erros conhecidos
▪ Scripts de diagnóstico

Gerenciamento de mudança

Mudanças são geradas a partir de vários locais na organização e por diversas razões.
Algumas requisições de mudança podem ter razões proativas, como por exemplo,
redução de custos, melhorias na produtividade, melhorias na qualidade, melhorias nas
funcionalidades do serviço. Razões reativas para requisições de mudança podem ser
resolver erros ou adaptações que o ambiente de negócio está exigindo. Estas
requisições de mudança vão iniciar este processo gerenciamento de mudança.

Propósito
O propósito do processo gerenciamento de mudança é controlar o ciclo de vida de
todas as mudanças, possibilitando que mudanças benéficas sejam feitas com o
mínimo de interrupção aos serviços de TI.

Objetivos
Os objetivos do gerenciamento de mudança são:

▪ Responder aos requisitos de negócio do cliente que estão em constante

mudança, maximizando valor e reduzindo incidentes, interrupção e retrabalho
▪ Responder às requisições do negócio e da TI para mudanças que irão alinhar
os serviços às necessidades do negócio

132
 ▪ Assegurar que mudanças são registradas e avaliadas, e que mudanças
autorizadas são priorizadas, planejadas, testadas, implementadas,
documentadas e revisadas de maneira controlada
▪ Assegurar que todas as mudanças em itens de configuração são registradas
no sistema de gerenciamento de configuração (SGC)
▪ Otimizar o risco de negócio – muitas vezes é correto minimizar o risco do
negócio, mas algumas vezes é apropriado aceitar conscientemente um risco
devido ao beneficio potencial

Escopo
O gerenciamento de mudança cobre qualquer acréscimo, modificação ou remoção de
qualquer coisa que possa afetar os serviços de TI. Seu escopo inclui mudanças em
todos os processos, arquiteturas, ferramentas, métricas e documentação, além de
mudanças em serviços de TI e outros itens de configuração.

O escopo do gerenciamento de mudança também inclui todas as mudanças em

qualquer um dos 5 aspectos do Desenho de serviço:

▪ Soluções de serviço
▪ Sistemas de gerenciamento de informações e ferramentas
▪ Arquiteturas tecnológicas
▪ Processos de gerenciamento de serviços
▪ Métodos de medição e métricas

Conceitos básicos
Vejamos a seguir alguns termos básicos usados neste processo.

Mudança
Acréscimo, modificação ou remoção de qualquer coisa que possa afetar serviços de
TI.

Requisição de mudança (RDM)

Um pedido formal para fazer uma mudança. Inclui os detalhes da mudança solicitada e
pode ser registrada em papel ou em formato eletrônico. O termo é frequentemente
confundido com o registro da mudança ou com a mudança propriamente dita.

133
Registro de mudança
Um registro contendo os detalhes de uma mudança. Cada registro de mudança
documenta o ciclo de vida de uma única mudança. Um registro de mudança é criado
para cada requisição de mudança recebida, mesmo para aquelas que
subsequentemente sejam rejeitadas. Os registros de mudança devem referenciar os
itens de configuração que serão afetados pela mudança. Os registros de mudança
podem ser armazenados no sistema de gerenciamento de configuração ou em
qualquer outra parte do sistema de gerenciamento de conhecimento de serviço.

Tipos de mudança
Para diferentes tipos de mudança geralmente existem procedimentos específicos,
como os de avaliação de impacto e de autorização de mudança. Existem três tipos de
mudança de serviço:

1. Mudança normal
2. Mudança padrão
3. Mudança emergencial

Mudança normal
Passa pelos estágios de avaliação completa, autorização e implementação.
Normalmente este tipo de mudança é categorizado como:

▪ Mudança importante
▪ Mudança significativa
▪ Mudança de pouca importância

Mudança padrão
É uma mudança pré-aprovada que tem baixo risco, relativamente comum e segue um
procedimento ou instrução de trabalho, como uma recuperação de senha ou o
fornecimento de um equipamento padrão para um novo funcionário, por exemplo.

Toda mudança padrão deve ter um modelo de mudança que defina os passos a serem
seguidos, incluindo como a mudança deve ser registrada, gerenciada e implementada.

Elementos cruciais que caracterizam uma mudança padrão são:

▪ Tem um gatilho definido que inicia a mudança, por exemplo, uma requisição de
serviço ou uma exceção gerada no gerenciamento de evento
▪ As tarefas são bem conhecidas, documentas e comprovadas
▪ Aprovação de orçamento será tipicamente predeterminada ou dentro do
controle do solicitante da mudança
▪ Os riscos geralmente são de baixo nível e sempre bem entendidos

134
Mudança emergencial
É reservada para mudanças altamente críticas que precisam ser implementadas o
mais rápido possível, como resolver um incidente grave ou implementar um patch de
segurança, por exemplo.

Mudanças de emergência são algumas vezes necessárias e devem ser

cuidadosamente desenhadas e testadas o tanto quanto possível antes de serem
usadas. Caso contrário, o impacto da mudança de emergência pode ser maior do que
o incidente original.

Detalhes de mudanças de emergência podem ser documentados de forma retroativa.

Em uma situação de emergência, pode não ser possível a convocação do comitê
consultivo de mudança (CCM). Quando uma aprovação de CCM é requerida, esta
será fornecida pelo CCM de emergência (CCME).

Propostas de mudança
Mudanças importantes que envolvam custo, risco ou impacto organizacional
significativos geralmente são iniciadas pelo processo de gerenciamento de portfólio de
serviço. Antes que seja feita a abertura do termo de serviço de um serviço novo ou
alterado, é importante que a mudança seja revisada sobre impactos potenciais em
outros serviços, em recursos compartilhados e no cronograma de mudança.

Propostas de mudança são submetidas ao gerenciamento de mudança antes da

abertura do termo de serviço para assegurar que conflitos em recursos ou outras
questões sejam identificados. A autorização da proposta de mudança não autoriza a
implementação da mudança – ela simplesmente permite que o termo de serviço seja
aberto para que a atividade de Desenho de serviço possa começar.

A proposta de mudança é normalmente criada pelo processo de gerenciamento de

portfólio de serviço e é passada para o gerenciamento de mudança para autorização.
Em algumas organizações, propostas de mudança podem ser criadas por um
escritório de gerenciamento de programa ou por projetos individuais.

Propostas de mudança incluem:

▪ Uma descrição de alto nível do serviço novo, alterado ou aposentado, incluindo

saídas de negócio a serem suportadas e utilidade e garantia a serem providas
▪ Um caso de negócio completo incluindo riscos, questões e alternativas, assim
como um orçamento e expectativas financeiras
▪ Um esboço de cronograma para desenho e implementação da mudança
Depois que o serviço novo ou alterado é encomendado, requisições de mudança
serão usadas da maneira normal para requisitar autorização para mudanças
específicas. Estas requisições serão associadas com a proposta de mudança para que
o gerenciamento de mudança tenha uma visão da intenção estratégica geral e possa
priorizar e revisar estas RDMs apropriadamente.

135
Modelos de mudança
A organização pode pré-definir modelos de processos de
mudança já com passos acordados que podem ser
executados para lidar com certos tipos de mudanças. Para
mudanças que ocorrem com frequência podemos ter um
modelo que oriente como o pessoal deve tratar aquela
mudança. Estes modelos incluem:

▪ Os passos a serem tomados para lidar com a

mudança, incluindo eventos inesperados
▪ A ordem cronológica em que estes passos devem ser tomados, com definição
de qualquer dependência ou co-processo
▪ Responsabilidades: quem faz o quê
▪ Cronogramas e limites para ações serem completadas
Procedimentos de escalação: quem deve ser contatado e quando

Planejamento de remediação
Nenhuma mudança deve ser aprovada sem um plano de remediação.

Idealmente, deve haver um plano de remediação para restaurar a organização para a

sua situação inicial, muitas vezes através da recarga de um conjunto de linha de base
de ICs, especialmente software e dados. Entretanto, nem todas as mudanças são
reversíveis. Neste caso, uma abordagem alternativa de remediação é requerida.

Quando estamos lidando com uma mudança como por exemplo uma migração de
versão de software ou uma troca de servidor, existem riscos – coisas que podem dar
errado durante a execução da mudança. Por esse motivo, todas as mudanças
precisam de um planejamento para falhas. O plano de remediação existe justamente
porque se sabe que algo pode dar errado – e se algo der errado realmente haverá
uma forma de reverter a mudança, ou alguma contingência estará disponível para
contornar a situação. Este plano de remediação pode ser feito para cada modelo de
mudança.

136
Comitê consultivo de mudança (CCM)
Na avaliação de uma mudança talvez seja necessário envolver as partes interessadas.
Dependendo de sua complexidade e relevância, a mudança não deve ser avaliada
apenas pelo gerente de mudança, mas sim por um grupo de pessoas – chamado
Comitê Consultivo de Mudança (CCM).

O CCM serve como um corpo de conselho auxiliando o gerenciamento de mudança na

avaliação e priorização de mudanças, com visão tanto técnica como de negócio. Por
isso o CCM precisa incluir pessoas com uma clara compreensão das necessidades do
negócio, do cliente e dos usuários, bem como das funções do desenvolvimento técnico
e de suporte.

Seus membros podem ser:

▪ Gerente de mudança (sempre preside as reuniões)

▪ Cliente(s)
▪ Gerente(s) de negócio(s)
▪ Representante(s) de grupos de usuários
▪ Pessoal de desenvolvimento/manutenção de aplicações (quando apropriado)
▪ Equipe de serviços (se necessário)
▪ Equipe de serviços administrativos (quando as mudanças afetam as instalações)
▪ Consultores especialistas/técnicos
▪ Representantes de terceiros (se necessário, como em situações de outsourcing,
por exemplo)

Comitê consultivo de mudança emergencial (CCME)

Quando surge a necessidade de uma mudança emergencial, pode não haver tempo
para se criar um CCM completo. É assim necessário identificar uma configuração
menor com autoridade para tomar decisões emergenciais, chamada de comitê
consultivo de mudança emergencial (CCME).

Seus membros podem ser:

▪ Gerente de mudança
▪ Pessoal de desenvolvimento/manutenção de aplicações (que estarão envolvidos
na mudança)
▪ Representantes do cliente

137
Atividades
As atividades do gerenciamento de mudança incluem:

▪ Planejamento e controle de mudanças

▪ Cronograma de mudança e de liberação
▪ Comunicações
▪ Decisão e autorização de mudança
▪ Assegurar que haja planos de remediação
▪ Medidas e controle
▪ Relatórios
▪ Entendimento do impacto da mudança
▪ Melhoria contínua
Atividades de gerenciamento individual de mudanças incluem:

▪ Criar e registrar RDMs

▪ Revisar RDMs e filtrar mudanças
▪ Avaliação da mudança:
 Estabelecer o nível apropriado de autoridade de mudança
 Estabelecer áreas relevantes de interesse (quem deve ser envolvido no
CCM)
 Avaliar justificativa, impacto, custo, benefícios e riscos, prevendo o
desempenho da mudança
 Requisitar avaliação formal do gerenciamento de mudança
▪ Autorizar a mudança:
 Obter autorização/rejeição
 Comunicar a decisão a todas as partes interessadas, especialmente ao
iniciador da RDM
▪ Planejar atualizações
▪ Coordenar implementação de mudança
▪ Revisar e fechar a mudança

138
No diagrama abaixo você visualiza os passos recomendados para tratar uma mudança
normal. Considere que nem toda mudança vai seguir o mesmo caminho – vai
depender do tipo de mudança ou do modelo que foi criado para mudança.

© Crown copyright 2011. Reproduced under licence from Cabinet Office.

Interfaces
O gerenciamento de mudança tem interfaces com os processos de mudança do
negócio, com programas de gerenciamento de projetos e com parceiros.

As interfaces com os outros processos incluem: gerenciamento da configuração e

ativo de serviço, gerenciamento de problema, gerenciamento da continuidade de
serviço de TI, gerenciamento da segurança da informação e gerenciamento da
demanda e capacidade.

139
O gerenciamento de mudança tem um forte vínculo com o gerenciamento da
configuração. O gerenciamento da configuração fornecerá informações sobre os itens
de configuração que fazem parte da mudança. Através do SGC o gerenciamento de
mudança poderá avaliar riscos e impacto da mudança.

Este relacionamento é de duas vias. O gerenciamento de mudança não só usa as

informações que estão no SGC como irá disparar um gatilho para o gerenciamento da
configuração informando que mudanças foram realizadas e que o SGC precisa ser
atualizado. O gerenciamento da configuração também auxiliará o gerenciamento de
liberação. Antes que uma mudança seja implantada no ambiente de produção, uma
linha de base de configuração precisa ser criada no SGC. Esta linha de base contém
informações sobre a configuração atual do serviço. Caso aconteça alguma falha
durante a implantação da liberação, ela será utilizada para retroceder a mudança,
voltando à configuração que o serviço tinha anteriormente.

Fonte: Bon, Jan Van; et al. – “Foundations of IT Service Management Based on ITIL V3”.

140
Gerenciamento de liberação e implantação

Assim que o gerenciamento de mudança aprova uma mudança, o gerenciamento de

liberação pode entrar em ação para liberar novas versões de software/hardware no
ambiente de produção. Imagine que um determinado aplicativo apresentou um erro na
tela do usuário, e que para corrigir este erro seria necessário fazer algumas correções
no código-fonte. Então, inicialmente abre-se uma requisição de mudança que deverá
ser avaliada e aprovada. Após a aprovação, a equipe responsável pelo
desenvolvimento do aplicativo irá realizar a correção no código-fonte. Pronta a
correção, uma nova versão do software será gerada. O processo de gerenciamento de
liberação entra na etapa final, quando a mudança já foi desenvolvida e precisa ser
liberada no ambiente de produção. O gerenciamento de liberação vai se envolver
desde a criação do pacote da nova versão (empacotamento) até a instalação. Este
processo vai se preocupar com todos os aspectos relacionados com a liberação de
serviço, incluindo treinamento de usuários e equipe de suporte.

Propósito
O propósito do gerenciamento de liberação e implantação é planejar, programar
(agendar) e controlar a construção, o teste e a implantação de liberações, e entregar
novas funcionalidades exigidas pelo negócio enquanto protege a integridade dos
serviços existentes.

Os objetivos do gerenciamento de liberação são:

▪ Definir e acordar planos de liberação e implantação com os clientes e partes

interessadas
▪ Criar e testar pacotes de liberação
▪ Garantir que a integridade do pacote de liberação e de seus componentes
constituintes seja mantida durante as atividades de transição
▪ Implantar pacotes de liberação a partir da BMD para o ambiente de produção
seguindo um plano e um cronograma acordado
▪ Garantir que todos os pacotes de liberação sejam rastreados, instalados,
testados, verificados e/ou desinstalados ou retornados se apropriado
▪ Garantir que a organização e partes interessadas da mudança serão
gerenciadas durante as atividades de liberação e implantação
▪ Garantir que um serviço novo ou alterado e seus sistemas de apoio, tecnologia
e organização sejam capazes de entregar a utilidade e a garantia acordadas
▪ Garantir que existirá transferência de conhecimento para permitir a clientes e
usuários usarem da melhor forma o serviço
▪ Assegurar que habilidades e conhecimento sejam transferidos para as funções
da Operação de serviço

141
Escopo
O escopo do gerenciamento de liberação e implantação inclui processos, sistemas e
funções para empacotar, construir, testar e implantar uma liberação dentro do
ambiente de uso, estabelecer o serviço especificado no pacote de Desenho de serviço
e formalmente repassar o serviço para as funções da Operação de serviço.

O escopo inclui todos os itens de configuração requeridos para implementar uma

liberação, como:

▪ Ativos físicos tais como um servidor ou rede

▪ Ativos virtuais tais como um servidor virtual ou armazenamento virtual
▪ Aplicativos e software
▪ Treinamento para usuários e equipe de TI
▪ Serviços, incluindo todos os contratos e acordos relacionados
Apesar de este processo ser responsável por garantir que os testes são realizados, a
execução de fato dos testes é feita pelo processo de validação e teste de serviço.

Conceitos básicos
Liberação
Uma ou mais mudanças a um serviço de TI que são construídas, testadas e
implantadas ao mesmo tempo. Uma única liberação pode incluir mudanças ao
hardware, software, documentação, processos e outros componentes.

Atividades
Há quatro fases no gerenciamento de liberação e implantação:

• Planejamento de liberação e implantação

Criação de planos para a implantação da liberação. Esta fase começa com a
autorização do gerenciamento de mudança para planejar uma liberação e
termina com a autorização do gerenciamento de mudança para criar a
liberação.
• Construção e teste
O pacote de liberação é construído, testado e arquivado na BMD. Esta fase
começa com a autorização do gerenciamento de mudança para construir a
liberação e termina com a autorização para o gerenciamento de configuração e
ativos arquivar o pacote de liberação na BMD. Esta fase acontece apenas uma
vez para cada liberação.
• Implantação
O pacote de liberação na BMD é implantado no ambiente de uso. Esta fase
começa com a autorização do gerenciamento de mudança para implantar o
pacote de liberação em um ou mais ambientes-alvo e termina com a passagem
para a função de Operação de serviço e suporte para período de
funcionamento experimental (PFE). Pode haver muitas fases de implantação
para cada liberação, dependendo das opções planejadas de liberação.

142
 • Revisão e encerramento
Experiências e feedback são recolhidos, desempenho e resultados são
avaliados e lições são aprendidas.
A figura na página seguinte mostra pontos múltiplos onde uma mudança autorizada é
o gatilho para a atividade de gerenciamento de liberação e implantação. Isso não
requer uma RDM separada para cada estágio. Algumas organizações gerenciam toda
a liberação com uma única RDM e autorizações separadas para cada estágio para
continuar as atividades, enquanto outras requerem uma RDM para cada estágio.
Ambas as abordagens são aceitáveis, o que importa é que a autorização de mudança
seja recebida antes de começar cada estágio.

© Crown copyright 2011. Reproduced under licence from Cabinet Office.

6.3 Tipos de ferramentas de suporte a transição de

serviço

Ferramentas asseguram que os processos de transição de serviço possam funcionar

de forma eficiente. Alguns tipos de ferramentas utilizadas na Transição de serviço são:

▪ Ferramentas de fluxo de trabalho para o gerenciamento de mudança

▪ Sistemas de gerenciamento da configuração
▪ Sistemas de gerenciamento do conhecimento do serviço
▪ Ferramentas de colaboração
▪ Ferramentas de relatórios e painéis
▪ Ferramentas de implantação
▪ Ferramentas de coleta automatizada de inventário de hardware e software

143
7 - Operação de serviço
Uma vez que um serviço novo ou alterado foi transferido para o ambiente de
produção, inicia-se o estágio de operação de Serviço.

O livro Operação de Serviço introduz, explica e detalha atividades de entrega e

controle para alcançar a excelência operacional em uma base cotidiana.

Este é um estágio mais prolongado do ciclo de vida, pois o serviço deverá ser mantido
em bom estado operacional até que ele perca a sua utilidade e seja aposentado
(retirado do ambiente de produção). A operação de serviço é o dia-a-dia do pessoal de
TI.

É importante reconhecer que o sucesso da operação de serviço dependerá de todos

os estágios anteriores do ciclo de vida do serviço. Se o serviço foi mal planejado
durante o estágio da estratégia, então ele será desenhado incorretamente.
Consequentemente a transição irá implantar um serviço em operação que apresentará
defeitos. Por isso durante todo o ciclo de vida cada estágio deve validar o pacote de
informação gerado pelo estágio anterior, para evitar que o serviço seja projetado e
implantado sem atender plenamente às necessidades do negócio. Para que se possa
ter ganhos com as práticas da ITIL na organização, é necessário que todos os
estágios do ciclo de vida estejam em bom funcionamento.

Se tudo for bem pensado, planejado e coordenado nos estágios anteriores, o serviço
entrará em operação sem causar impactos negativos tanto para a equipe de TI como
para a organização. Na maioria das organizações de TI que não tem uma boa gestão
é muito comum os serviços serem projetados sem haver um bom entendimento dos
requisitos do cliente e do desenho adequado da infraestrutura para suportar a
demanda do serviço, e após a implantação do serviço é que se descobrem as falhas e

144
iniciam-se as correções. Este tipo de situação causa grandes impactos negativos
como:

▪ Insatisfação dos usuários

▪ Piora da imagem da TI
▪ O tempo e o dinheiro que se gasta para corrigir falhas quando o serviço já está
implantado é muito maior comparado às falhas que são identificadas durante o
estágio de Desenho de serviço
▪ Cria demanda para a central de serviço com chamadas referentes a erros e
mau funcionamento do serviço
▪ Perdas financeiras para o negócio

7.1 Propósito da operação de serviço

Propósito da operação de serviço
O propósito da Operação de serviço inclui:

▪ Coordenar e realizar as atividades e processos necessários para entregar e

gerenciar serviços em níveis acordados para usuários do negócio e clientes
▪ Ser responsável pelo gerenciamento da tecnologia que é usada para entregar
e dar suporte aos serviços

Objetivos da operação de serviço

Os principais objetivos da Operação de serviço são:

▪ Manter a satisfação do negócio e a confiança na TI por meio de entrega e

suporte eficientes e eficazes de serviços de TI acordados
▪ Minimizar o impacto das indisponibilidades dos serviços no dia-a-dia das
atividades do negócio
▪ Assegurar que o acesso aos serviços acordados de TI é apenas fornecido
àqueles que estão autorizados a receber os serviços

Escopo da operação de serviço

O escopo da Operação de serviço inclui:

▪ Todos os aspectos do serviço de ponta a ponta acordados com o negócio,

incluindo atividades desempenhadas pelo provedor de serviço, por
fornecedores externos e pelo usuário ou cliente do serviço
▪ Processos do gerenciamento de serviço que suportam os serviços
▪ Funções organizacionais requeridas para entregar e suportar serviços
▪ Tecnologia e infraestrutura necessárias para entregar serviços
▪ Pessoal para gerenciar tecnologia, processos e serviços

145
Valor que a operação de serviço agrega ao negócio
A adoção e a implementação de abordagens padrão e consistentes para a Operação
de serviço irão:

▪ Reduzir mão de obra e custos não planejados tanto para o negócio como para
a TI por meio de tratamento otimizado das indisponibilidades do serviço e
identificação de suas causas raiz
▪ Reduzir duração e frequência das indisponibilidades do serviço, o que permitirá
ao negócio obter vantagem completa do valor criado pelos serviços que estão
sendo recebidos
▪ Fornecer resultados e dados operacionais que podem ser usados por outros
processos da ITIL para melhorar os serviços continuamente
▪ Atender a metas e objetivos da política de segurança da organização,
garantindo que serviços de TI serão acessados somente por quem está
autorizado a usá-los
▪ Fornecer acesso rápido e efetivo para serviços padrão
▪ Fornecer uma base para operações automatizada, aumentando assim
eficiências e permitindo que os recursos humanos sejam utilizados para
trabalho de inovação
A Operação de serviço é o momento da verdade. É onde o cliente vai confirmar
realmente a qualidade do serviço e se o custo compensa os benefícios que o serviço
gera. O cliente só vai perceber a qualidade do serviço quando começar a usar o novo
serviço ou melhoria no seu dia-a-dia. E o serviço só vai estar disponível para o uso
quando ele estiver em operação.

7.2 Princípios-chave
Papel da comunicação na operação de serviço
A comunicação efetiva na operação de serviço assegura que todas as equipes e
departamentos sejam capazes de executar atividades padrão envolvidas na entrega
dos serviços e no gerenciamento da infraestrutura. Imprevistos podem ser geralmente
evitados ou mitigados com comunicação apropriada.

Um importante princípio é que toda comunicação precisa ter um propósito ou uma

ação resultante pretendida. Informações não devem ser comunicadas sem que haja
uma audiência (público) clara. Além disto, a audiência deve ser envolvida ativamente
na determinação das necessidades de comunicação e no que ela irá fazer com as
informações. Considere-se ainda que deve haver uma revisão periódica para validar
se as informações que estão sendo enviadas são ainda necessárias para a audiência.

Tipos de comunicação incluem:

▪ Comunicações operacionais de rotina

▪ Comunicação entre turnos
▪ Relatos de desempenho

146
 ▪ Comunicação em projetos
▪ Comunicação relativa a mudanças
▪ Comunicação relativa a exceções e emergências
▪ Treinamento de processos novos ou customizados e desenhos de serviço
▪ Comunicação de estratégia, desenho e transição para as equipes de Operação
de serviço

7.3 Processos da operação de serviço

Os processos da Operação de serviço selecionados para exame ITIL Foundation são
os seguintes:

• Gerenciamento de evento
• Gerenciamento de incidente
• Cumprimento de requisição
• Gerenciamento de problema
• Gerenciamento de acesso
Todos os processos do livro Operação de Serviço da ITIL são cobertos pelo currículo
do exame ITIL Foundation atual. Entretanto, somente para os processos
gerenciamento de incidente e gerenciamento de problemas serão apresentadas as
atividades e interfaces do processo, conforme é exigido para o exame .

147
Gerenciamento de evento

Dentro da infraestrutura de TI vão ocorrer muitos eventos. Os servidores geram log de

eventos, os aplicativos geram eventos, o software antivírus gera eventos, as
ferramentas de monitoramento de rede podem gerar eventos. Enfim, podemos ter
eventos de diversas origens. Alguns destes eventos podem indicar alguma coisa fora
do padrão esperado, outros eventos apenas constatam que algo está dentro da
normalidade, como por exemplo que uma transação em um determinado aplicativo foi
realizada com sucesso. O que o processo gerenciamento de evento vai fazer é tratar
cada um destes eventos para decidir que tipo de ação deve ser tomada.

Propósito
O propósito do gerenciamento de evento é gerenciar eventos durante seus ciclos de
vida. Este ciclo de vida de atividades detecta eventos, entende-os e determina ações
de controle apropriadas, e é coordenado pelo processo de gerenciamento de evento.

Objetivos
Os objetivos do processo gerenciamento de eventos são:

▪ Detectar todas as mudanças de estado que são significativas para o

gerenciamento de IC ou serviço de TI
▪ Determinar as ações de controle apropriadas para eventos e assegurar que
estas são comunicadas para as funções apropriadas
▪ Fornecer um gatilho ou um ponto de entrada para a execução de processos da
Operação de serviço e atividades de gerenciamento de operações
▪ Fornecer um meio para comparar o desempenho operacional e comportamento
atual contra os padrões de desenho e ANSs
▪ Fornecer uma base para garantia de serviço e relatórios (melhoria de serviço)

148
Escopo
O gerenciamento de evento pode ser aplicado a qualquer aspecto do gerenciamento
de serviço que precisa ser controlado e o qual pode ser automatizado. Estes incluem:

▪ Itens de configuração (switch, link, impressoras, etc.)

▪ Condições ambientais (detecção de fogo e fumaça, temperatura, energia
elétrica)
▪ Monitoração de licença de software (verificar se existem mais cópias instaladas
do que licenciadas)
▪ Segurança (detecção de invasão na rede, tentativas de acesso)
▪ Atividades normais (rastrear o uso de um aplicativo ou desempenho de um
servidor)

Conceitos básicos
Evento
É uma mudança de estado que possui significado para o gerenciamento de um item
de configuração ou serviço de TI. Eventos geralmente requerem uma ação da equipe
de operações de TI e às vezes podem levar à geração e ao registro de incidentes.

Eventos são tipicamente reconhecidos por meio de notificações criadas por um serviço
de TI, IC ou ferramenta de monitoração.

Alguns exemplos de eventos:

1. Servidor está desligado (exceção)

2. Uso de memória em um servidor próximo de 70% (aviso)

3. Falha em um HD (exceção)

4. Backup completado com sucesso (informativo)

5. Impressora com nível baixo de tinta (aviso)

6. Transação com cartão de crédito completada com sucesso (informativo)

7. Novo software instalado em um desktop na rede (informativo ou exceção)

Alerta
Uma notificação de que um limite foi alcançado, alguma coisa mudou ou uma falha
ocorreu. Alertas são normalmente criados por uma ferramenta de monitoração.

Um alerta é um meio de iniciar uma intervenção humana - quando você quer que um

149
analista técnico se envolva e investigue o evento. Geralmente, isso envolve enviar
uma mensagem para a tela, telefone ou pager do analista.

Exemplos de eventos que podem gerar um alerta:

• A ferramenta de monitoramento detectou que o servidor de e-commerce não

está mais respondendo e disparou uma mensagem SMS para o responsável
tomar providencias.

• O uso de memória no servidor do aplicativo está acima de 85% e um aviso no

painel de monitoramento do servidor foi gerado.

Gerenciamento de incidente

Propósito
O propósito do gerenciamento de incidente é restaurar a operação normal o mais
rápido possível e minimizar o impacto negativo sobre as operações do negócio,
garantindo assim que os melhores níveis de qualidade de serviço e disponibilidade são
mantidos.

"Operação normal de um serviço" é definida aqui como um estado operacional em que

os serviços e itens de configuração estão desempenhando de acordo com os níveis
acordados de serviço e operação.

Este processo vai lidar com todos os incidentes. Estes podem incluir falhas, questões
ou consultas realizadas pelos usuários (normalmente via chamada telefônica para a
central de serviço) ou pela equipe técnica. Esta detecção pode também ser
automática, reportada por ferramentas de monitoração.

Objetivos
Os objetivos do processo gerenciamento de incidentes são:

▪ Assegurar que métodos e procedimentos padronizados são usados para pronta

resposta, análise, documentação, gerenciamento contínuo e reporte eficientes
de incidentes
▪ Aumentar a visibilidade e comunicação de incidentes para o negócio e para a
equipe de suporte de TI
▪ Melhorar a percepção do negócio em relação à TI por meio de uso de uma
abordagem profissional, resolvendo rapidamente e comunicando incidentes
quando eles ocorrerem
▪ Alinhar as atividades de gerenciamento de incidente e prioridades com as
atividades e prioridades do negócio
▪ Manter a satisfação do usuário com a qualidade dos serviços de TI

150
Escopo
Este processo irá lidar com:

▪ Qualquer evento que interrompe ou que poderia interromper um serviço

▪ Eventos que são comunicados diretamente por usuários, seja por meio da
central de serviço ou pela interface de ferramentas de gerenciamento de
incidente
▪ Incidentes reportados ou registrados pela equipe técnica
 Por exemplo: alguém nota algo estranho com um componente de
hardware ou de rede e reporta/registra um incidente e encaminha para
a central de serviço.

Este processo não engloba:

▪ Atendimento de requisição de serviço
 Apesar de requisições de serviço e incidentes serem reportados para a
central de serviço, eles não são a mesma coisa. Requisições de serviço
não representam uma interrupção em um serviço acordado.
 Para atender requisitos existe o processo cumprimento de requisição.

Conceitos básicos
Incidente
É uma interrupção não planejada de um serviço de TI ou uma redução da qualidade
de um serviço de TI. Falha de um item de configuração que ainda não tenha
impactado um serviço de TI é também um incidente. Por exemplo: falha de um disco
rígido de um conjunto de discos espelhados.

Exemplos de incidentes:
▪ Sistema apresenta lentidão
▪ Mensagem de erro em uma aplicação
▪ Informações erradas na tela do sistema
▪ Impressora não imprime
▪ Sem conexão com a internet
▪ O computador não liga
▪ O backup falhou
▪ Um vírus corrompeu arquivos

151
Incidente grave
São aqueles que têm um alto impacto nas áreas de negócio. Uma definição do que
constitui um incidente grave precisa ser acordada e mapeada usando o sistema de
priorização de incidentes.

Procedimentos separados são necessários para tratar incidentes graves, com escalas
de tempo menores e com alta prioridade. Quando necessário, o procedimento para
incidente grave precisa incluir uma equipe de incidente grave sob liderança direta do
gerente de incidente. Esta equipe é formulada para se concentrar em um incidente
garantindo que os recursos e foco são fornecidos para descobrir uma solução.

Modelo de incidente
É uma maneira de predefinir os passos a serem tomados em um processo para lidar
com um tipo definido de incidente de maneira acordada. Muitos incidentes não são
novidades. Eles envolvem lidar com algo que já aconteceu antes e pode acontecer
novamente. Por isso, algumas organizações acham útil predefinir modelos de
incidente.

Um modelo de incidente pode conter:

▪ Passos para resolver o incidente

▪ Tempo necessário para executar cada passo
▪ Lista de responsáveis que poderão ser envolvidos
▪ Precauções a serem tomadas antes de resolver o incidente (como backup de
dados e arquivos de configuração) ou passos para atender a regras de
segurança
▪ Cronogramas e limites para completar ações
▪ Procedimentos de escalação: quem deve ser contatado e quando
▪ Qualquer atividade necessária para preservação de evidência

Atividades
As atividades-chave dentro do processo de gerenciamento de incidente incluem:

1. Identificação do incidente
2. Registro do incidente
3. Categorização do incidente
4. Priorização do incidente
5. Diagnóstico inicial
6. Escalada do incidente
7. Investigação e diagnóstico
8. Resolução e recuperação
9. Encerramento

152
O diagrama abaixo apresenta as atividades envolvidas neste processo.

Identificação do incidente

Incidentes podem ser detectados pelo gerenciamento de eventos, por chamadas à

central de serviços, pela internet, por interfaces de autoajuda ou diretamente pelo
pessoal técnico.

Requisições de serviço ou requisições de mudança incorretamente registradas como

incidentes são identificadas para serem repassadas aos processos de cumprimento de
requisição ou gerenciamento de mudança respectivamente.

Registro do incidente

Todos os incidentes precisam ser registrados por completo, incluindo data e horário,
sejam eles recebidos pela central de serviço ou detectados automaticamente via
ferramentas de monitoramento.

Informações relevantes sobre a natureza do incidente precisam ser registradas.

Informações básicas deste registro incluem:
▪ ID único
▪ Categoria
▪ Urgência
▪ Prioridade
▪ Status atual
▪ Pessoa ou grupo que registrou o incidente
▪ Descrição do sintoma
▪ Atividades que foram executas na resolução (histórico)

153
Durante o ciclo de vida do incidente pode-se utilizar um status para identificar o
progresso:

Categorização do incidente

A categorização é usada para identificar o tipo de incidente e ajudar a analisar

tendências. Uma categorização multinível pode ser usada para identificar múltiplos
níveis de categorias que podem ser associados a um incidente, conforme mostrado
abaixo:

Copyright © AXELOS Limited 2011. All rights reserved. Material is reproduced under licence from
AXELOS.

154
Priorização do incidente

Um incidente pode ser priorizado com base em dois fatores: impacto e urgência.

Impacto está relacionado ao efeito nos processos de negócio, quantos serviços serão
afetados com aquela falha e qual será a perda financeira com a parada do serviço.

Urgência está relacionada a quanto um incidente pode afetar um processo de negócio

da empresa, e indica a velocidade com que o pessoal de suporte deve corrigir a falha.

Nesta tabela temos um exemplo de tempos que podem ser acordados para resolver
cada incidente com base em sua prioridade:

Diagnóstico inicial

Se o incidente foi roteado via central de serviço, o analista de suporte irá fazer o
diagnóstico inicial, tipicamente enquanto o usuário aguarda ao telefone.

O analista de suporte irá tentar descobrir o que está ocasionando o incidente e tentar
corrigi-lo. Podem ser usados scripts de diagnósticos e informações de erros
conhecidos para ajudar no diagnóstico. Se não for possível resolver de imediato o
incidente, informa-se ao usuário o ID de registro do incidente e o fato de que a
situação será tratada internamente.

Se o analista de suporte não conseguir resolver o incidente, ele pode procurar

assistência de outros grupos ou escalar o incidente.

155
Escalada do incidente

Existem dois tipos de escalação:

▪ Funcional: quando o incidente é repassado para um grupo funcional. Ocorre

quando um grupo não tem conhecimento técnico para resolver o incidente ou
não tem recursos suficientes para cumprir os prazos acordados.

▪ Hierárquica: quando é necessário notificar o nível gerencial. Ocorre quando é

necessária a liberação de recursos técnicos para resolver o incidente mais
rápido.

Investigação e diagnóstico

Quando o incidente se referir a falhas, este irá requerer algum grau de investigação e
diagnóstico. Mais de um grupo pode ser envolvido no diagnóstico e todo o histórico
precisa ser documentado no log do incidente.

Resolução e restauração

Quando a potencial resolução for descoberta, esta deve ser testada. Quando a
restauração e a recuperação estiverem completas, o incidente pode ser devolvido à
central de serviço para seu encerramento formal.

156
Encerramento do incidente

A central de serviço executa o encerramento formal do incidente verificando que o

usuário está satisfeito com a resolução.

Interfaces
Os processos abaixo têm interface com o gerenciamento de incidente:

▪ Gerenciamento de problema: incidentes são causados por problemas que

precisam ser resolvidos. O gerenciamento de incidente reportará estes
problemas. Além disto, os erros conhecidos documentados pelo gerenciamento
de problema serão usados para agilizar a resolução de incidentes.
▪ Gerenciamento de acesso: incidentes podem ser levantados quando tentativas
de acessos não autorizados e brechas de segurança são detectadas. Um
histórico de incidentes é também mantido para suportar atividades de
investigação forense e resolução de brechas nos acessos.
▪ Gerenciamento de configuração e ativo de serviço: o SGC é usado para
identificar os componentes associados ao serviço e avaliar o impacto de um
incidente.
▪ Gerenciamento de mudança: para implantar uma solução de contorno pode ser
necessário abrir uma RDM. Incidentes podem ocorrer devido a mudanças.
▪ Gerenciamento de nível de serviço (GNS): o gerenciamento de incidente
fornece relatórios para o GNS. O GNS estabelece níveis de serviços para o
gerenciamento de incidente funcionar, incluindo:
▪ Tempos de resposta para os incidentes
▪ Definições de impacto
▪ Metas de tempo para resolução

▪ Gerenciamento de segurança da informação: o gerenciamento de incidente

fornece informações sobre incidentes relacionados à segurança conforme
necessário para suportar atividades de desenho e ganhar uma visão completa
da eficácia das medidas de segurança.

157
 ▪ Gerenciamento de capacidade: o gerenciamento de incidente pode solicitar o
monitoramento de desempenho. O gerenciamento de capacidade fornece
soluções de contorno para os incidentes.
▪ Gerenciamento de disponibilidade: o gerenciamento da disponibilidade usa
dados dos incidentes para determinar a disponibilidade dos serviços (ciclo
expandido do incidente).

Cumprimento de requisição

O termo “requisição de serviço” é usado como

uma descrição genérica para muitos tipos
variáveis de demandas colocadas sobre o
departamento de TI por seus usuários. Muitas
delas são na verdade pequenas mudanças de
baixo risco, ocorrendo com frequência e baixo
custo. Podem ser: uma requisição para mudar
uma senha, instalar um software em uma
estação de trabalho, realocar alguns itens do
equipamento de desktop ou apenas uma
pergunta requisitando uma informação. Mas
pela escala, pela natureza de frequência e
baixo risco, este tipo de solicitação pode ser
tratado por um processo separado em vez de
congestionar os processos de gerenciamento
de incidente e gerenciamento de mudança.

Propósito
O propósito do cumprimento de requisição é gerenciar o ciclo de vida de todas as
requisições de serviço dos usuários.

Objetivos
Os objetivos do processo cumprimento de requisição são:

▪ Manter a satisfação de usuários e clientes por meio de um tratamento eficiente

e profissional de todas as requisições de serviço
▪ Fornecer um canal para os usuários requisitarem e receberem serviços padrão
para os quais existe um processo de autorização e qualificação
▪ Fornecer informações para usuários e clientes sobre a disponibilidade de
serviços e como obtê-los
▪ Fornecer e entregar componentes de serviços padrão requisitados (ex: licenças
e mídia de software)
▪ Auxiliar com informações e receber reclamações ou comentários de forma
geral

158
Escopo
O processo necessário para cumprir uma requisição irá variar dependendo
exatamente do que está sendo requisitado, mas pode usualmente ser quebrado em
um conjunto de atividades a serem realizadas. Para cada requisição, estas atividades
podem ser documentadas em um modelo de requisição e armazenadas no SGCS.

Algumas organizações usam o processo de gerenciamento de incidente e suas

ferramentas para tratar requisições de serviços. Neste caso o formulário para registro
de incidente deverá ter uma categorização em alto nível permitindo classificar o que é
de fato incidente e o que é requisição de serviço.

Em algumas organizações as requisições de serviço podem ser tratadas por uma

equipe de trabalho separada da equipe de tratamento de incidentes.

É apropriado que a central de serviço seja utilizada também como ponto focal para
receber requisições de serviço.

Conceitos básicos
Requisição de serviço
É uma requisição formal de um usuário para algo a ser fornecido, como uma
requisição para informações ou aconselhamento, para redefinir uma senha ou para
instalar uma estação de trabalho para um novo usuário.

O termo “requisição de serviço” é usado como uma descrição genérica para os muitos
tipos de diferentes demandas colocadas por usuários às organizações de TI. Muitas
são tipicamente requisições para pequenas mudanças de baixo risco frequentemente
realizadas, como mudança de senha, instalação de software adicional ou meramente
pedidos de informação.

Requisições de serviço podem estar ligadas a uma requisição de mudança como parte
do cumprimento de requisição e são gerenciadas pelo processo cumprimento de
requisição, usualmente em conjunto com a central de serviço.

159
Gerenciamento de problema

Propósito
O propósito do gerenciamento de problema é gerenciar o ciclo de vida de todos os
problemas desde a identificação, passando pela investigação, documentação e
eventual remoção do erro.

Este processo busca minimizar o impacto negativo de incidentes e problemas no

negócio que são causados por erros dentro da infraestrutura de TI, além de prevenir
proativamente a recorrência de incidentes relacionados a estes erros. Para tanto, o
gerenciamento de problema procura identificar a causa raiz de incidentes, documentar
e comunicar erros conhecidos e iniciar ações para melhorar ou corrigir a situação.

Objetivos
Os objetivos do processo gerenciamento de problema são:

▪ Prevenir problemas e incidentes resultantes de uma ocorrência

▪ Eliminar incidentes recorrentes
▪ Minimizar o impacto de incidentes que não podem ser prevenidos

Escopo
O gerenciamento de problema inclui atividades requeridas para diagnosticar a causa
raiz de incidentes e determinar a resolução dos problemas associados.

Este processo é responsável por assegurar que a resolução é implementada por meio
de procedimentos de controle apropriados, especialmente gerenciamento de mudança
e gerenciamento de liberação e implantação.

O gerenciamento de problema irá manter a informação sobre problemas e soluções de

contorno apropriadas. Assim a organização pode reduzir o número e o impacto dos
incidentes ao longo do tempo. Neste sentido, o gerenciamento de problema tem uma
forte interface com o gerenciamento de conhecimento e ferramentas como o BDEC.

Conceitos básicos

Incidentes x problemas
Um incidente é uma interrupção não
planejada ou a redução da qualidade em um
serviço de TI.

Um problema apresenta uma visão diferente

de um incidente entendendo a sua causa
raiz – que pode ser também a causa de
outros incidentes.

Incidentes não se tornam problemas. Enquanto as atividades do gerenciamento de

incidente focam em restaurar os serviços ao estado normal de operação, as atividades

160
do gerenciamento de problema focam em descobrir maneiras de prevenir que
incidentes aconteçam.

A figura abaixo ilustra o relacionamento entre incidente e problema.

Problema
É a causa de um ou mais incidentes. Esta causa geralmente não é conhecida quando
um registro de problema é criado, e o gerenciamento de problema é responsável pela
investigação.

Erro conhecido
Um problema que possui causa raiz e solução de contorno documentadas.

Erros conhecidos são criados e gerenciados através de seu ciclo de vida pelo
gerenciamento de problema.

Erros conhecidos podem também ser identificados pelo pessoal de desenvolvimento

ou por fornecedores. Assim que o diagnóstico esteja completo, e particularmente
quando uma solução de contorno tenha sido encontrada, um registro de erro
conhecido deve ser feito e colocado no banco de dados de erros conhecidos (BDEC)
para que, se acontecerem novamente, possam ser identificados e o serviço possa ser
restaurado mais rapidamente.

Entretanto, em alguns casos pode ser vantajoso fazer o registro de erro conhecido
ainda no início do processo, para fins de informação, mesmo que o diagnóstico e a
solução de contorno não tenham sido encontrados. É aconselhável estabelecer um

161
procedimento concreto especificando exatamente quando um erro conhecido deve ser
registrado. Isso deve ser feito assim que for útil.

Banco de dados de erros conhecidos (BDEC)

Um banco de dados que contém todos os registros de erros conhecidos.

Para permitir diagnósticos e resoluções de incidentes e problemas mais rápidos,

conhecimento prévio de como eles foram superados devem ser arquivados em um
banco de dados de erros conhecidos.

O BDEC é usado durante a fase de diagnóstico de incidente e problema para tentar

acelerar o processo de resolução – e novos registros devem ser adicionados tão logo
quanto possível quando um novo problema tenha sido identificado e um diagnóstico
feito.

O registro de erros conhecidos deve ter detalhes exatos da falha e dos sintomas que
ocorreram, além de detalhes precisos de qualquer solução de contorno ou ação de
resolução que pode ser tomada para restaurar o serviço e resolver o problema.

Assim como o sistema de gerenciamento de configuração (SGC), o BDEC é parte do

sistema de gerenciamento do conhecimento de serviço (SGCS).

Modelo de problema
Muitos problemas serão únicos e serão trabalhados de forma individual. Entretanto,
alguns incidentes podem ser recorrentes devido a problemas desconhecidos.

Assim como o registro de erros conhecidos para ajudar em diagnósticos mais rápidos,
a criação de um modelo para lidar com estes problemas pode ser útil.

Atividades
O gerenciamento de problema consiste de dois subprocessos: gerenciamento de
problema reativo e gerenciamento de problema proativo.

Tanto no gerenciamento de problema reativo como no proativo, as atividades buscam

levantar problemas, gerenciá-los por meio do processo de gerenciamento de
problema, descobrir as causas raiz de incidentes e prevenir a recorrência futura destes
incidentes. A diferença entre o gerenciamento reativo e proativo se baseia em como o
processo de gerenciamento de problema é acionado.

Com o gerenciamento de problema reativo as atividades do processo irão tipicamente

ser acionadas em reação a um incidente que ocorreu. O gerenciamento de problema
reativo complementa as atividades de gerenciamento de incidente focando na causa
raiz de um incidente para prevenir sua recorrência e identifica soluções de contorno
quando necessárias.

Com o gerenciamento de problema proativo as atividades são acionadas pelas

atividades que procuram melhorar os serviços. Um exemplo pode ser atividades de
análise de tendência para descobrir causas comuns no histórico de incidentes com o
intuito de prevenir sua recorrência. Este subprocesso complementa as atividades de

162
MCS ajudando a identificar soluções de contorno e ações de melhoria que podem
melhorar a qualidade dos serviços.

O processo de gerenciamento de problema de forma geral consiste das seguintes

atividades:

1. Detecção de problema
2. Registro de problema
3. Classificação de problema
4. Priorização de problema
5. Investigação e diagnóstico de problema
6. Descoberta de solução de contorno
7. Criação do registro de erro conhecido
8. Resolução de problema
9. Encerramento de problema

O diagrama na página seguinte apresenta o fluxo de atividades do gerenciamento de

problema:

163
Detecção de problema

Gatilhos para o gerenciamento de problema reativo:

▪ Suspeita ou detecção de causa de um ou mais incidentes feita pela central de

serviço, resultando na criação de registro de problema
▪ Análise de um incidente feita pelo grupo de suporte técnico que revela que um
problema relacionado existe ou pode existir
▪ Detecção automática de uma falha na infraestrutura ou em um aplicativo
▪ Notificação de um fornecedor que um problema existe e precisa ser resolvido
Gatilhos para o gerenciamento de problema proativo:

▪ Análise de incidente que resulta na necessidade de criar um registro de

problema
▪ Tendência do histórico de registro de incidentes para identificar uma ou mais
causas relacionadas que, se removidas, podem prevenir suas recorrências
▪ Atividades realizadas para melhorar a qualidade de um serviço que resultam na
necessidade de criar um registro de problema para identificar mais ações de
melhoria que precisam ser tomadas
Registro de problema

Todos os detalhes de um problema precisam ser registrados para que exista um

histórico completo. Uma referência cruzada precisa ser feita com o(s) incidentes(s)
que iniciaram o registro de problema – e todos os detalhes relevantes precisam ser
copiados a partir do(s) registro(s) de incidente.

Categorização de problema

Problemas podem ser categorizados da mesma forma que os incidentes (é

aconselhável usar o mesmo sistema de codificação), assim a natureza do problema
pode ser facilmente rastreada no futuro e informação gerencial significativa pode ser
obtida.

Priorização de problema

Problemas podem ser priorizados da mesma forma usando as mesmas razões usadas
nos incidentes. A frequência e o impacto dos incidentes relacionados precisam ser
levados em consideração.

Investigação e diagnóstico

Uma investigação deve ser conduzida para tentar diagnosticar a causa raiz do
problema. A velocidade e a natureza desta investigação irão variar dependendo de
impacto, severidade e urgência dos problemas.

Há várias técnicas que podem ser úteis para o diagnóstico, como análise cronológica,
análise do valor do impacto, Kepner e Trogoe, brainstorming, 5 porquês, isolamento de
falha, mapa de afinidade, diagrama de Ishikawa, análise de Pareto, etc.

164
Descoberta de soluções de contorno

Em alguns casos pode ser possível descobrir uma solução de contorno para os
incidentes causados pelo problema – uma forma temporária de superar as
dificuldades. Quando uma solução de contorno é descoberta, ainda assim é
importante que o registro do problema permaneça aberto e que os detalhes da solução
de contorno sejam documentados no registro do problema.

Criação de registro de erro conhecido

Assim que o diagnóstico estiver completo e particularmente onde uma solução de

contorno foi descoberta (ainda que não exista uma resolução permanente), um registro
de erro conhecido pode ser colocado no BDEC para ser utilizado para resolver novos
incidentes. Às vezes pode ser vantajoso abrir um registro de erro conhecido ainda no
início do processo.

Resolução de problema

Uma vez que a causa raiz foi descoberta e uma solução para removê-la foi
desenvolvida, esta deve ser aplicada para resolver o problema.

Se qualquer mudança em uma funcionalidade é requerida, uma RDM deve ser criada
e autorizada antes de a resolução ser aplicada. Se uma correção urgente é
necessária, uma RDM emergencial deve ser criada.

Existem alguns problemas para os quais um caso de negócio para resolução não pode
ser justificado (por exemplo, onde o impacto é limitado ou o custo da resolução é
extremamente alto).

Encerramento de problema

Quando uma resolução final foi aplicada, o registro do problema pode ser encerrado
formalmente – mesmo que registros de incidente estejam ainda abertos. Uma
verificação é feita neste momento para assegurar que o registro do problema contém
uma descrição histórica completa e todos os eventos – e se não, o registro deve ser
atualizado.

Revisão de problema grave

Após cada problema grave e enquanto a memória ainda estiver fresca, é aconselhável
conduzir uma revisão para aprender quaisquer lições para o futuro. Especialmente, a
revisão deve examinar:

▪ Coisas que foram feitas corretamente

▪ Coisas que foram feitas errado
▪ O que poderia ser feito melhor no futuro
▪ Como prevenir a recorrência do problema
▪ Se houve qualquer responsabilidade de terceiro e se ações de
acompanhamento são necessárias

165
Interfaces
Além do relacionamento primário com o processo gerenciamento de incidente, que já
foi discutido anteriormente, os processos abaixo têm interface com o gerenciamento
de problema:

▪ Gerenciamento de mudança: o gerenciamento de problema levanta RDMs para

corrigir erros.
▪ Gerenciamento de configuração e ativo de serviço: o SGC é usado para
identificar se existe alguma coisa errada em relação aos ICs usados no serviço.
▪ Gerenciamento de liberação e implantação: é responsável pelo lançamento de
correções de problemas no ambiente de produção.
▪ Gerenciamento de conhecimento: o SGCS pode ser usado para formar a base
do BDEC e manter ou integrar registros de problema.
▪ Gerenciamento da disponibilidade: vai trabalhar em conjunto com o
gerenciamento de problema de forma proativa para identificar formas de reduzir
o downtime.
▪ Gerenciamento da capacidade: alguns problemas vão requerer investigação
pelo gerenciamento da capacidade. O gerenciamento da capacidade pode
auxiliar em medidas proativas.
▪ Gerenciamento da continuidade do serviço de TI: se um problema não for
resolvido a tempo pode ser necessário invocar o plano de continuidade.
▪ Gerenciamento de nível de serviço: o gerenciamento de problema contribui
para alcançar as metas de qualidade, ajudando a prevenir incidentes e
problemas.
▪ Gerenciamento financeiro: o gerenciamento de problema fornece informações
de custos para resolver e prevenir problemas.
▪ Processo de melhoria de sete etapas: a ocorrência de incidentes e problemas
fornece uma base para identificação de oportunidades de melhoria de serviço e
as adiciona ao registro de MCS. Atividades de gerenciamento de problema
proativo podem também identificar problemas e questões de serviço que, se
tratadas, podem contribuir para aumentar a qualidade do serviço e a satisfação
do usuário/cliente.

166
Gerenciamento de acesso

Propósito
O propósito do gerenciamento de acesso é fornecer o direito para que os usuários
possam usar um serviço ou grupo de serviços.

O gerenciamento de acesso é, portanto, a execução de políticas e ações definidas no

gerenciamento de segurança da informação. Em algumas organizações este processo
é conhecido como gerenciamento de direitos ou gerenciamento de perfis.

Objetivos
Os objetivos do processo gerenciamento de acesso são:

▪ Gerenciar os acessos aos serviços com base nas políticas e ações definidas
no gerenciamento de segurança da informação (Desenho de serviço). O
gerenciamento da segurança da informação que vimos no estágio Desenho de
serviço define as políticas de segurança, enquanto o gerenciamento de acesso
executa o que foi definido a partir destas políticas. É a parte operacional da
segurança da informação.
▪ Responder eficientemente às requisições para conceder acesso aos serviços,
alterar direitos de acesso ou restringir acessos, assegurando que os direitos
que estão sendo fornecidos ou alterados são concedidos de forma devida.
▪ Supervisionar o acesso aos serviços e assegurar que os direitos que estão
sendo fornecidos não são usados de forma indevida.

Escopo
Este processo é efetivamente a execução das políticas no gerenciamento de
segurança da informação, na medida em que possibilita à organização gerenciar
confidencialidade, disponibilidade e integridade dos dados e a propriedade intelectual
da organização.

O gerenciamento de acesso assegura que aos usuários são dados os direitos de uso a
um serviço, mas não assegura que o acesso esteja disponível em todos os horários
acordados – isto é fornecido pelo processo gerenciamento de disponibilidade.

É um processo executado por todas as funções de gerenciamento técnico e de

aplicativo. Entretanto, pode existir um ponto de coordenação de controle único,
usualmente no gerenciamento de operações de TI ou na central de serviço.

Este processo pode ser iniciado por uma requisição de serviço e ser realizado também
pela equipe da central de serviço.

167
Conceitos básicos
Acesso
Refere-se ao nível e extensão de funcionalidades de um serviço ou dados que um
usuário tem permissão para usar.

Identidade
Refere-se à informação que distingue cada usuário dentro da organização. Por
definição, a identidade de um usuário é única para aquele usuário.

Exemplos de identidades podem ser o nome de usuário SilvaJ ou papel ‘gerente de

mudança’.

Direito
Direitos (ou privilégios) referem-se a configurações que o usuário pode acessar em um
serviço ou grupo de serviços.

Direitos típicos, ou níveis de acesso, incluem leitura, escrita, execução, alteração e

exclusão de dados.

7.4 Funções na Operação de serviço

Função pode ser uma equipe ou grupo de pessoas que são utilizadas para conduzir
um ou mais processos ou atividades. Existem quatro funções principais que vão atuar
no ambiente operacional da TI:

▪ Central de serviço
▪ Gerenciamento técnico
▪ Gerenciamento de operações de TI
▪ Gerenciamento de aplicativo
Estas funções vão assegurar que os sistemas de TI, componentes e instalações
funcionem adequadamente.

168
Central de serviço

Papel
A central de serviço é uma unidade funcional composta por uma equipe responsável
por lidar com uma variedade de eventos de serviço, frequentemente feitos via
chamadas telefônicas ou interface web, ou ainda reportados automaticamente.

Objetivos
O objetivo primário da central de serviço é fornecer um ponto único de contato entre os
serviços sendo providos e os usuários.

169
Responsabilidades específicas da central de serviço são:

▪ Registrar todos os detalhes de incidente e requisições de serviço, alocando os

códigos de categorização e priorização
▪ Prover o diagnóstico e investigação no primeiro nível
▪ Resolver incidentes e requisições de serviço para os quais a central de
serviços está preparada
▪ Escalar incidentes conforme ANSs
▪ Manter usuários informados sobre o progresso
▪ Fechar todos os incidentes, requisições e outros tipos de chamadas
▪ Conduzir pesquisa de satisfação com clientes/usuários
▪ Atualizar o SGC fazendo uma rápida verificação se as informações
correspondem aos dados do usuário

Estruturas organizacionais

Central de serviço local

A estrutura local funciona mais perto do usuário final. A presença local facilita a
comunicação. Pode custar mais caro quando há um volume de atendimento muito
pequeno em cada local.

O exemplo abaixo mostra uma central de serviço localizada dentro de cada filial de
uma organização.

170
Central de serviço centralizada
O pessoal de suporte fica centralizado em um ou mais locais. Pode ser mais
econômica quando existem poucas pessoas na equipe e um volume maior de
chamadas. A central de serviços centralizada exigirá que o pessoal conheça um
número maior de serviços e que entenda a necessidades de diversos clientes.

Em uma organização pode haver uma combinação de estrutura centralizada com

estrutura local.

O exemplo abaixo mostra duas filiais sendo atendidas pela mesma central de serviço,
que poderia estra localizada na matriz.

171
Central de serviço virtual
É possível estabelecer uma única central de serviço centralizada, mesmo que o
pessoal de suporte esteja localizado em diferentes regiões geográficas. Através de
recursos tecnológicos na central telefônica, é possível redirecionar a chamada sem
que o usuário saiba o local que o está atendendo.

O exemplo abaixo mostra duas filiais sendo atendidas por uma central de serviço
virtualizada, onde os atendentes podem estar localizados em cidades diferentes.
Esses atendentes fazem parte de uma “equipe virtual” de atendimento.

172
Central de serviço siga o sol
Empresas que possuem locais de atendimento espalhados pelo globo podem fornecer
suporte 24 horas por dia através de uma central de serviço siga o sol. Em vez de a
matriz ter que trabalhar com vários turnos, é possível redirecionar as chamadas para
um determinado local conforme o horário de expediente naquele país.

Para que isto funcione bem, todas as centrais de serviço precisam ter os mesmos
processos e ferramentas, e uma base única de informação. Aspectos culturais e
linguagem também devem ser considerados.

O exemplo abaixo mostra uma organização com filiais nos EUA, Europa e Ásia.
Quando o expediente da central de serviços nos EUA terminar, as chamadas são
repassadas para a central da Europa e na sequência para a central localizada na Ásia.

173
Gerenciamento técnico

Papel
A função gerenciamento técnico refere-se aos grupos,
departamentos ou equipes que fornecem especialidade
técnica e gerenciamento da infraestrutura em geral.

Em organizações menores, é possível gerenciar este

conhecimento especializado em um único departamento.
Mas em organizações maiores eles são distribuídos em
vários departamentos técnicos especializados.

Esta função tem um papel duplo:

▪ Assegura que o conhecimento requerido para

desenhar, testar, gerenciar e melhorar os serviços de
TI é identificado, desenvolvido e refinado
▪ Fornece recursos para suportar o ciclo de vida do
gerenciamento de serviço de TI
Os grupos de suporte podem ser organizados por
especialidade:

Objetivos
Os objetivos do gerenciamento técnico são de ajudar a planejar, implantar e manter
uma infraestrutura técnica estável para suportar os processos de negócio da
organização por meio de:

▪ Topologias bem desenhadas, com redundância e custo efetivos

▪ Uso adequado de habilidades técnicas para manter a infraestrutura técnica em
condição ótima
▪ Uso adequado de habilidades técnicas para resolver rapidamente falhas que
possam ocorrer

174
Gerenciamento de aplicativo

Papel
O gerenciamento de aplicativo é a função responsável
por gerenciar aplicativos durante todo o seu ciclo de
vida, sejam estes comprados ou desenvolvidos
internamente. Pode ser executado por qualquer
departamento, grupo ou equipe envolvida no
gerenciamento e suporte de aplicativos operacionais.

O gerenciamento de aplicativo participa da decisão

sobre comprar ou desenvolver o aplicativo, fornece
especialidade e conhecimento técnico para gerenciar
aplicativos, trabalhando em conjunto com o
gerenciamento técnico e fornece recursos para suportar
o ciclo de vida do gerenciamento de serviços de TI.

Esta função fornece conhecimento técnico e recursos

para suportar os aplicativos:

Objetivos
Os objetivos do gerenciamento de aplicativo são de suportar os processos de negócio
da organização ajudando a identificar requisitos funcionais para o aplicativo, e então
assistir em seu desenho e desenvolvimento e fornecer suporte para melhoria nos
aplicativos em operação.

Estes objetivos serão alcançados por meio de:

▪ Aplicativos bem desenhados, resilientes e com custo justificável

▪ Garantia de que os requisitos funcionais estejam disponíveis para alcançar os
resultados necessários para o negócio
▪ Organização das habilidades técnicas adequadas para manter aplicativos
operacionais em condição ótima
▪ Rápido uso de habilidade para fazer diagnóstico e resolver qualquer falha
técnica que ocorra

175
Gerenciamento de operações de TI

Papel
O gerenciamento de operações de TI é a função responsável por executar as
atividades operacionais do dia-a-dia, gerenciando a infraestrutura de TI para entregar
o nível de serviço de TI acordado com o negócio.

O papel do gerenciamento de operações de TI é executar as atividades em

andamento e os procedimentos requeridos para gerenciar e manter a infraestrutura de
TI. Estas atividades incluem controle de operações de TI e gerenciamento das
instalações.

Controle de operações de TI
É composto por uma equipe de operadores que garante a execução e monitoramento
das atividades operacionais e eventos na infraestrutura:

 Gerenciamento de console
 Agendamento de jobs (rotinas em batch e scripts)
 Backup e restauração
 Gerenciamento de impressão
 Atividades de manutenção

Gerenciamento das instalações

Gerencia a parte física do ambiente de TI:

 Salas de data centers e de computadores

 Sites de recovery
 Contratos de data centers terceirizados
 Projetos de consolidação de servidores e data centers

Objetivos
Os objetivos do gerenciamento de operações de TI incluem:

▪ Alcançar a estabilidade nas atividades e processos cotidianos de uma empresa

▪ Implementar melhorias regulares para alcançar melhores serviços a menores
custos, mantendo a estabilidade
▪ Aplicar rapidamente habilidades operacionais para diagnosticar e resolver
qualquer falha de TI que ocorrer

176
Sobreposições das funções na organização
Tipicamente há uma sobreposição de algumas funções nas organizações:

7.5 Tipos de ferramentas de suporte a operação de

serviço

Ferramentas podem assegurar que os processos de operação de serviço possam

funcionar de forma eficiente.

Alguns tipos de ferramentas que podem ser utilizadas na Operação de serviço são:

▪ Ferramentas de autoajuda
▪ Softwares para gerenciar incidentes e problemas
▪ Workflow para suportar os processos de operação
▪ SGC integrado com ferramentas da central de serviço
▪ Acesso remoto
▪ Ferramentas de monitoramento de rede e componentes de serviço
▪ Gerador de relatórios e consoles

177
8 - Melhoria contínua de serviço (MCS)
Esta última parte do ciclo de vida avalia os
serviços e identifica formas de melhorar a
sua qualidade. Também faz melhorias para
garantir a eficiência e eficácia dos
processos em cada estágio do ciclo de
vida.

8.1 Propósito, objetivos,

escopo e valor agregado
Introdução à MCS
A melhoria de contínua de serviço é responsável por gerenciar melhorias nos serviços
e ativos de serviço para alinhá-los com as necessidades de negócio que mudam ao
longo do tempo. O desempenho do provedor de serviço é continuamente medido e
melhorias são feitas nos serviços, habilidades e recursos de forma a aumentar eficácia
e eficiência. Exemplos:

Área de melhoria Exemplo de melhoria

Processos Recentemente o volume de incidentes tem aumentado consideravelmente e

a central de serviços não utiliza um critério de priorização. O uso de um
critério de priorização de incidentes se faz necessário. Exemplo: criar uma
tabela considerando impacto e a urgência.

Papéis Todos os chamados recebidos na central de serviço para um determinado

aplicativo têm sido escalados para a equipe de gerenciamento de
aplicativos. Com um treinamento básico os atendentes da central de
serviços poderiam lidar com questões.

Serviços A empresa começou a atuar em toda a América do Sul e se faz necessário

que o envio de pedidos utilizado pelos representantes seja multi-idiomas.

Tecnologia O servidor X10 tem apresentado muitas falhas no sistema operacional e

sobre ele roda um aplicativo importante para o negócio. Recomenda-se que
seja feita uma formatação e atualização do sistema operacional.

178
Propósito da MCS
O propósito primário da MCS é continuamente alinhar os serviços de TI às mudanças
de necessidades do negócio por meio da identificação e implementação de melhorias
nos serviços de TI.

Estas atividades de melhoria suportam os outros estágios do ciclo de vida. A MCS

procura formas para melhorar a eficácia e a eficiência dos processos e serviços, bem
como sua relação custo-benefício (efetividade do custo).

Objetivos da MCS
Os objetivos da MCS incluem:

▪ Rever, analisar e fazer recomendações sobre oportunidades de melhoria em

cada estágio do ciclo de vida
▪ Rever e analisar os resultados obtidos em relação aos níveis de serviço
▪ Identificar e implementar atividades individuais para melhorar a qualidade do
serviço e melhorar a eficiência e eficácia dos processos habilitadores
▪ Melhorar o custo-benefício (efetividade do custo) da entrega de serviços de TI
sem sacrificar a satisfação do cliente
▪ Assegurar que métodos de gerenciamento da qualidade aplicáveis sejam
usados para suportar as atividades de melhoria contínua
▪ Entender o que medir, por que algo está sendo medido e qual deveria ser o
resultado de sucesso

Escopo da MCS
A Melhoria Contínua de Serviço da ITIL fornece orientações em quatro áreas:

▪ A saúde geral do GSTI como uma disciplina

▪ O alinhamento contínuo do portfólio de serviços com as necessidades atuais e
futuras do negócio
▪ A maturidade e habilidade da organização, gerenciamento, processos e
pessoas utilizados pelos serviços
▪ Melhoria contínua de todos os aspectos do serviço de TI e ativos de serviço
que o suportam

179
MCS através do ciclo de vida
Na figura abaixo visualizamos a atuação da MCS em todo o ciclo de vida.

A MCS faz a melhorias em cada estágio e no ciclo de vida inteiro, funcionando como
se fosse um governo que controla as metas de cada estágio do ciclo de vida.

Nós não precisamos esperar que o serviço ou que os processos sejam implantados
em operação para identificar oportunidades de melhorias. Oportunidades de melhoria
podem aparecer na Estratégia, no Desenho e na Transição.

Se focarmos somente em melhorias em operações, nós vamos ter sucesso limitado.

Temos que lembrar que se tivermos problemas no Desenho e/ou na Transição,
continuamente vão aparecer problemas na Operação. Por exemplo, podemos
identificar que alguns aplicativos hoje estão tendo problemas de desempenho. O que
nós fazemos para resolver? Normalmente resolvemos problemas de desempenho
melhorando a configuração dos servidores. Mas problemas como estes aparecem
porque não foi feito um bom dimensionamento da demanda na Estratégia e não foi
feito um bom planejamento da capacidade no Desenho. Perceba que muitos
problemas surgem devido a falhas que cometemos desde a concepção do serviço, no
momento em que ele nasce na Estratégia de serviço. E a MSC tem esta visão holística
de todo o ciclo, identificando onde é necessário propor melhorias para que todo o ciclo
funcione bem.

180
Valor que a MCS agrega ao negócio
A adoção e implementação padrão e consistente da MCS irá:

▪ Levar a uma melhoria gradual e contínua na qualidade do serviço, quando

justificada
▪ Assegurar que serviços de TI permanecem continuamente alinhados com os
requisitos do negócio
▪ Resultar em melhorias graduais na efetividade do custo por meio de uma
redução de custos e/ou habilidade de lidar com mais trabalho ao mesmo custo
▪ Usar a monitoração e relatórios para identificar oportunidades de melhoria em
todos os estágios do ciclo de vida e em todos os processos

8.2 Princípios-chave e modelos

Ciclo de Deming (PDCA)
William Edwards Deming ficou conhecido por propor o ciclo PDCA (PEVA em
português) para a melhoria da qualidade. Este ciclo é composto por quatro estágios e
facilita a melhoria contínua de processos e serviços de TI.

181
Este ciclo PDCA é um princípio fundamental da MCS. Veja a seguir o detalhamento
dos seus estágios:

Abordagem de melhoria contínua de serviço

O livro MCS também recomenda uma abordagem estruturada para ajudar na melhoria
de serviços baseada no ciclo PDCA. Esta abordagem consiste de 6 questões:

182
A abordagem de melhoria pode ser resumida da seguinte forma:

Questão Propósito

Qual é a visão? Compreende a visão pelo entendimento dos principais objetivos do

negócio. A visão deveria alinhar estratégias de negócio e de TI.

Onde estamos Avalia a situação atual para obter uma “foto” precisa, imparcial, de onde a
agora? organização está agora. Esta avaliação de linha de base é a análise da
posição atual em termos de negócio, organização, pessoas, processos e
tecnologia.

Onde queremos Entende e acorda as prioridades para melhoria baseadas em um

estar? desenvolvimento mais apurado de princípios definidos na visão.

Como Detalhar o plano de MCS para alcançar o fornecimento de serviço de alta

chegaremos lá? qualidade por meio de implementação ou melhoria de processos de
gerenciamento de serviços de TI.

Chegamos lá? Verifica se as medições e métricas estão implantadas e que marcos foram
alcançados, se a conformidade dos processos é alta e se os objetivos do
negócio e prioridade foram atendidos pelo nível de serviço.

Como mantemos Finalmente, a abordagem deve assegurar que o momento da melhoria de

o impulso? qualidade é mantido assegurando que as mudanças sejam incorporadas na
organização.

Papel da medição para a melhoria contínua de serviço

A medição tem um papel importante na MCS e:

▪ Faz parte de cada processo do ciclo de vida do serviço

▪ Fornece uma base para as atividades de MCS:

▪ Todas as medições precisam ter um propósito claro

▪ Possibilita a avaliação da situação atual
▪ Ajuda na identificação de áreas de aperfeiçoamento
▪ Ajudar a avaliar as melhorias feitas

183
FCSs e PIDs
Para estabelecer uma medição adequada é necessário considerar dois elementos:
fatores críticos de sucesso (FCS) e principais indicadores de desempenho (PID).

Fatores críticos de sucesso (FCS) são algo que deve ocorrer para que um
processo/serviço tenha sucesso, atinja seus objetivos. São medidos por principais
indicadores de desempenho (PID), ou seja, métricas usadas para medir o
desempenho de um processo/serviço em relação a um objetivo. PID ajudam a avaliar
a eficácia, eficiência e efetividade de custo.

Um exemplo é o seguinte: o FCS “Manter a satisfação do usuário com os serviços de

TI” é medido pelo PID “Pontuação média na pesquisa de satisfação”.

Exemplos de FCS e PID no gerenciamento de incidente:

FCS PID

Resolver Tempo médio decorrido para alcançar a resolução ou desvio de um incidente,

incidentes o desdobrado por código de impacto.
mais rápido
possível, Desdobramento de incidentes em cada estágio do ciclo de vida do incidente.
minimizando
impactos para o Porcentagem de incidentes encerrados pela central de serviços sem referência
negócio. a outros níveis de suporte.

Número e percentagem de incidentes resolvidos remotamente sem a

necessidade de uma visita local.

Número de incidentes resolvidos sem impacto ao negócio.

Manter a Número total de incidentes (como medida de controle).

qualidade dos
serviços de TI Tamanho do backlog de incidentes atuais para cada serviço de TI.

Número e porcentagem de incidentes graves

para cada serviço de TI.

Linhas de base de medição

É importante estabelecer uma linha de base (base de referência) quando vamos focar
na melhoria de um serviço ou processo.

Temos que ter dados iniciais, que representam a situação anterior de um

processo/serviço. Depois utilizamos estes dados para comparar (fazer benchmarking)
com a situação atual, para saber se o serviço ou processo precisa de melhoria. Se
uma linha de base inicial não existir, então a primeira medição de algo se torna a linha
de base (base de referência).

184
Por exemplo: antes de implementar uma melhoria na central de serviço para aumentar
o número de incidentes resolvidos no primeiro nível, primeiro se identifica qual é o
percentual de incidentes resolvidos diretamente pelo primeiro nível no momento para
então ter uma linha de base para comparação posterior.

Tipos de métricas
Existem três tipos de métricas que podem ser coletadas para suportar as atividades da
MCS:

Tipo de métrica Descrição

• Podem ser usadas para medir o desempenho e disponibilidade

Métricas de de aplicativos ou componentes.
Tecnologia • São utilizadas para verificar se os componentes tecnológicos
estão funcionando de forma a atender às metas do serviço.

• São capturadas em forma de fatores críticos de sucesso (FCS)

e principais indicadores de desempenho (PID).
Métricas de • Estas métricas ajudam a determinar a saúde de um processo,
Processo considerando aspectos como qualidade, desempenho, valor
agregado e conformidade com o processo documentado (se o
pessoal segue na prática o processo documentado).

• Ajudam a medir resultados de um serviço de ponta a ponta.

Métricas de
Serviço • Por exemplo, elas podem medir eficiência, esforço, custo,
defeitos, produtividade e satisfação do cliente.

185
 Registro da MCS
Recomenda-se que todas as iniciativas e possibilidades para melhoria sejam
identificadas e documentadas no registro da MCS. Este documento pode seguir o
seguinte exemplo:

# Data Tamanho Tempo p/ Descrição Prioridade Métrica PID Responsável

criação implementar

1 1/04/11 Pequena Curto Um número de falhas Urgente n% redução de falhas João

têm ocorrido ao
implementar
aplicativos atualizados
ou novos. Isto tem sido
causado pelo
procedimento de testes
na liberação e
implantação usar
dados de teste
desatualizados. O
requisito é atualizar os
dados de teste no
repositório de teste
4371.

2 1/05/11 Médio Longo Gerenciamento de 2 n% redução de Pedro

evento: o número de eventos falsos
alertas a partir do
módulo ABC no
software da folha de
pagamento está ainda
causando tempo de
análise desnecessário.
Um filtro adicional é
necessário.

186
8.3 Processos da MCS
Processos da MCS
Muitas atividades realizadas pela MCS durante o ciclo de vida do serviço podem ser
embutidas em um único processo: processo de melhoria de sete etapas. Este é o
único processo formalizado no livro Melhoria Contínua de Serviço da ITIL edição 2011.

Processo de melhoria de 7 etapas

Propósito
É o processo responsável pela definição e gerenciamento das etapas necessárias
para:

▪ Identificar oportunidades de melhoria

▪ Definir o que será medido
▪ Coletar dados
▪ Processar dados
▪ Analisar a informação e dados
▪ Apresentar e usar a informação
▪ Implementar melhorias

Objetivos
Os objetivos do processo de melhoria de 7 etapas são:

▪ Identificar oportunidades para melhorar serviços, processos, ferramentas, etc.

▪ Reduzir o custo do fornecimento de serviços e assegurar que os serviços de TI
suportam os resultados do negócio que precisam ser alcançados
▪ Identificar o que precisa ser medido, analisado e reportado para estabelecer
oportunidades de melhoria
▪ Continuamente revisar os resultados dos serviços para assegurar que eles
permanecem atendendo aos requisitos de negócio
▪ Entender o que precisa ser medido, por que algo está sendo medido e
cuidadosamente definir o resultado de sucesso

187
Escopo
O escopo do processo de melhoria de 7 etapas inclui:

▪ A análise do desempenho e habilidades do serviço, processos do ciclo de vida,

parceiros e tecnologia.
▪ O alinhamento contínuo do portfólio de serviços com as necessidades atuais e
futuras do negócio assim como a maturidade necessária para os processos de
TI para cada serviço.
▪ Fazer o melhor uso da tecnologia que a organização tem e procurar explorar
novas tecnologias conforme elas se tornam disponíveis (um caso de negócio
para justificar o investimento é necessário).
▪ Ainda dentro do escopo estão a estrutura organizacional, habilidades do
pessoal e analisar se o pessoal está trabalhando nas funções e papéis
apropriados e se eles têm as habilidades requeridas.

Atividades
A figura abaixo apresenta as atividades envolvidas neste processo:

Etapa 1 - Identificar a estratégia para melhoria

Neste passo, a visão, necessidade do negócio, estratégia e metas táticas e

operacionais são definidas baseadas no escopo do processo que se pretende
melhorar. É importante saber isto para determinar o que precisa ser medido para
atender a visão, metas e/ou objetivos estratégicos do negócio.

188
Etapa 2 - Definir o que você irá medir

A Estratégia de serviço e o Desenho de serviço deve ter identificado esta informação

logo no início do ciclo de vida. Pode ser utilizada aqui a abordagem do modelo MCS
para levantar novamente “Onde estamos agora?” e “Onde queremos chegar?”. Isto
identifica a situação ideal que se espera alcançar.

Etapa 3 - Coletar os dados

A fim de responder à questão “Chegamos lá?”, dados precisam primeiro ser coletados
(usualmente, por meio das operações do serviço). Dados podem ser coletados de
diferentes fontes baseadas nas metas e objetivos identificados. Coletar dados é
sinônimo de medir o serviço.

Etapa 4 - Processar os dados

Aqui os dados são processados de acordo com os fatores críticos de sucesso (FCS) e
PID identificados. O objetivo deste passo é basicamente processar os dados de
diferentes fontes para saber o contexto em que podem ser comparados.

Etapa 5 - Analisar a informação e dados

Os dados são analisados no contexto. Envolve transformar os dados em informação

para poder identificar tendências e possíveis impactos no negócio.

Etapa 6 - Apresentar e usar a informação

Aqui a questão “Chegamos lá?” é formatada e comunicada em qualquer que seja o

meio necessário para apresentá-la às várias partes interessadas. O conhecimento é
apresentado para o negócio em uma forma e maneira que reflita suas necessidades e
os auxilie a determinar os próximos passos.

Etapa 7 - Implementar a melhoria

O conhecimento obtido é usado para otimizar, melhorar e corrigir serviços e

processos. Questões foram identificadas e agora as soluções são implementadas –
sabedoria é aplicada ao conhecimento. As melhorias que precisam ser realizadas para
melhorar o serviço ou processo são comunicadas e explicadas à organização.
Seguindo este passo, a organização estabelece uma nova linha de base e o ciclo
começa novamente.

189
Dados-para-Informação-para-Conhecimento-para-Sabedoria (DICS)
Em cada estágio do ciclo de vida dados precisam ser capturados para que se possa
gerar conhecimento e entender o que está acontecendo, para então chegarmos à
sabedoria. Isto é referenciado como Dados-para-Informação-para-Conhecimento-para-
Sabedoria.

Muitas vezes a organização captura os dados apropriados, mas falha em transformar

os dados em informação, sintetizar a informação em conhecimento e então combinar
aquele conhecimento com outros para gerar sabedoria. A sabedoria irá levar a
decisões melhores sobre melhorias no serviço.

8.4 Tipos de ferramentas de suporte a MCS

Para suportar as atividades de MCS, ferramentas de monitoração e relatórios para os
serviços e processos de TI podem ser utilizadas. Estas ferramentas serão usadas
para:

▪ Coletar dados
▪ Monitorar
▪ Analisar
▪ Gerar relatórios e indicadores para os serviços e determinar a eficiência e
eficácia dos processos

190
9 - Orientações para o exame de certificação
Algumas orientações sobre o exame de certificação ITIL Foundation.

9.1 Exame ITIL

Informações adicionais sobre o exame ITIL Foundation
▪ Formato: é composto por 40 questões de múltipla escolha, sendo necessário
acertar no mínimo 26 questões (65%).
▪ 60 minutos de duração.
▪ Disponível em português (excelente tradução).
▪ Sem consulta a material
▪ Instituto de exame: somente oferecido pela PEOPLECERT a partir de 2018.
▪ Onde realizar o exame: o exame remoto pode ser feito de qualquer local com
acesso à internet. Também pode ser realizado em um centro de treinamento
presencial, se for contratado diretamente com o centro. Obtenha no ambiente
de ensino o PDF do último módulo do curso para obter informações de como
realizar o exame presencial.

Requisitos do computador para realizar o exame remotamente:

• Ter uma webcam com boa resolução para visualização de seu documento de
identidade.
• Ter um microfone.
• Possuir uma conexão rápida com a internet: 5 MB de download e 1 de upload
são o suficiente.

O exame remoto é acompanhado por um fiscal da PEOPLECERT que fará a

checagem de identidade, verificará se o seu local está apropriado para o exame e lhe
orientará sobre o funcionamento do aplicativo. Para qualquer falha durante o exame
poderá ser solicitada ajuda diretamente ao fiscal, seja através do bate-papo do
aplicativo do exame ou através do e-mail.

191
9.2 Currículo do exame ITIL
Escopo do exame ITIL Foundation
Os candidatos devem esperar obter conhecimento e compreensão sobre as unidades
a seguir após concluírem com êxito o curso relacionado a esta certificação.

Unidades de aprendizagem Nível a ser testado

1. Gerenciamento de serviço como uma prática Compreensão

2. O ciclo de vida de serviço da ITIL Compreensão

3. Conceitos genéricos e definições Conscientização

4. Princípios-chave e modelos Compreensão

5. Processos selecionados Conscientização

6. Funções selecionadas Conscientização

7. Papéis selecionados Conscientização

8. Tecnologia e arquitetura Conscientização

9. Competência e treinamento Conscientização

No exame ITIL Foundation haverá questões de teste em todas as unidades de

aprendizagem acima.

Detalhamento dos tópicos do currículo ITIL Foundation

Gerenciamento de serviço como uma prática

Tópicos cobrados no exame Módulo do curso

Conceito de melhores práticas de domínio público 2

Por que a ITIL é bem sucedida 1

Conceito de um serviço 2

Conceito de clientes internos e externos 2

Conceito de serviços internos e externos 2

Conceito de gerenciamento de serviço 2

192
Conceito de gerenciamento de serviço de TI 2

Conceito de partes interessadas no gerenciamento de serviço 2

Conceito de processos e funções 2

Elementos de um processo 2

O ciclo de vida de serviço da ITIL

Tópicos cobrados no exame Módulo do curso

Estrutura do ciclo de vida de serviço da ITIL 3

Propósito, objetivos, escopo e valor da Estratégia de serviço 4

Propósito, objetivos, escopo e valor do Desenho de serviço 5

Propósito, objetivos, escopo e valor da Transição de serviço 6

Propósito, objetivos, escopo e valor da Operação de serviço 7

Propósito, objetivos, escopo e valor da Melhoria contínua de 8

serviço

Conceitos genéricos e definições

Tópicos cobrados no exame Módulo do curso

Utilidade e garantia 2

Ativos, recursos e habilidades 2

Portfólio de serviço 4

Catálogo de serviço 5

Governança 2

Caso de negócio 4

Gerenciamento de risco 2

Provedor de serviço 2

Acordo de Nível de Serviço (ANS) 5

Acordo de Nível Operacional (ANO) 5

193
Contrato de Apoio (CA) 5

Pacote de desenho de serviço (PDS) 5

Disponibilidade 5

Sistema de gerenciamento do conhecimento de serviço (SGCS) 5

Item de configuração (IC) 6

Sistema de gerenciamento da configuração (SGC) 6

Biblioteca de mídia definitiva 6

Mudança 6

Tipos de mudança (normal, padrão e emergencial) 6

Alerta 7

Incidente 7

Impacto, urgência e prioridade 7

Requisição de serviço 7

Problema 7

Solução de contorno 7

Erro conhecido 7

Banco de dados de erro conhecido (BDEC) 7

O papel da comunicação na Operação de serviço 7

Política de liberação 6

Tipos de serviço 2

Propostas de mudança 6

Registro da MCS 8

Resultados 2

Padrões de atividade de negócio 4

Clientes e usuários 2

Ciclo de Deming (planejar, executar, verificar, agir) 8

194
Princípios-chave e modelos
Tópicos cobrados no exame Módulo do curso

Criação de valor através de serviços 4

Importância de pessoas, processos, produtos e parceiros para o 5

gerenciamento de serviço

Cinco aspectos principais do Desenho de serviço 5

Abordagem da Melhoria contínua de serviço 8

Processos
Tópicos cobrados no exame Módulo do curso

Gerenciamento de portfólio de serviço 4

Gerenciamento financeiro para serviços de TI 4

Gerenciamento de relacionamento de negócio 4

Gerenciamento do nível de serviço (GNS) 5

Gerenciamento de catálogo de serviço 5

Gerenciamento da disponibilidade 5

Gerenciamento de segurança da informação (GSI) 5

Gerenciamento de fornecedor 5

Gerenciamento da capacidade 5

Gerenciamento da continuidade do serviço de TI 5

Coordenação de desenho 5

Gerenciamento de mudança 6

Gerenciamento de liberação e implantação 6

Gerenciamento do conhecimento 6

Planejamento e suporte da transição 6

Gerenciamento de incidente 7

Gerenciamento de problema 7

Gerenciamento de evento 7

195
Cumprimento de requisição 7

Gerenciamento de acesso 7

Processo de melhoria de sete etapas 8

Funções
Tópicos cobrados no exame Módulo do curso

Função central de serviço 7

Função gerenciamento técnico 7

Função gerenciamento de aplicativo 7

Função gerenciamento de operações de TI 7

Papéis
Tópicos cobrados no exame Módulo do
curso

Dono de processo 2

Gerente de processo 2

Profissional de processo 2

Dono de serviço 2

Tecnologia e arquitetura
Tópicos cobrados no exame Módulo do curso

Como a automação de serviço auxilia na agilidade dos processos 2

de gerenciamento de serviço

196
Competência e treinamento

Tópicos cobrados no exame Módulo do curso

Competência e habilidades para o gerenciamento de serviço 2

Competência e estrutura de habilidades 2

Treinamento 1

9.3 Dicas para preparação

Realize o quanto antes o seu exame
Realize o exame o mais cedo possível após ter completado as aulas gravadas e
enquanto você ainda estiver com os conceitos frescos na sua memória. Não perca o
ritmo de estudos!

Após completar as aulas gravadas, reserve um tempo para revisar o material do curso
e praticar os simulados. 3 dias podem ser o suficiente para isto!

Se você já completou as aulas gravadas, é ideal que você agende neste momento a
data do seu exame. Agendando antecipadamente o exame, você estabelece um
objetivo a ser alcançado e se organizará para completar seus estudos dentro de um
tempo limite. Além disto, você evita que o processo de agendamento do exame tire a
sua atenção nos seus estudos na véspera do exame.

Recomendações para estudos após o curso

Após completar as aulas gravadas, recomendamos:

▪ Revisar os slides do nosso curso

▪ Aproveitar para transferir o seu conhecimento para um resumo
▪ Revisar todos os tópicos do exame utilizando o nosso mapa mental onlie
▪ Praticar todos os simulados que disponibilizados para ganhar familiaridade com
os tipos de questões e confirmar seu entendimento sobre os conceitos
 Procure obter um score em torno 85% nos simulados na primeira
tentativa. Se o score for abaixo de 65%, não prossiga na realização dos
demais simulados sem antes revisar o conteúdo no qual você teve
pouco acerto
 Leia os comentários das respostas nas questões que você errou
 Não repetir cada simulado por mais de 3 vezes para evitar decorar as
questões
 Se ainda assim você se sentir inseguro, participe da aula de revisão
ao vivo via web conferência. De uma a duas vezes por mês oferecemos
esta aula.

197
Recomendações durante o exame
Durante o exame:

1. Mantenha a calma! Se você entendeu todo o conteúdo do curso e teve uma

boa pontuação nos simulados, não há motivos para ficar apreensivo.
2. Leia com atenção cada questão e certifique de que você entendeu o que a
questão está pedindo.
3. Procure desenvolver uma resposta para a questão antes de olhar as opções de
resposta disponíveis.
4. Leia e considere todas as opções de resposta antes de você escolher a opção
que melhor responde à questão.
5. Certifique que você respondeu o que a questão pediu.
6. Não existem questões de “pegadinha” neste exame. Então, não gaste tempo
procurando este tipo de questão.
7. Responda primeiro às questões mais fáceis, depois volte e responda às
questões mais difíceis.
8. Se houve alguma questão que você ficou em dúvida na resposta, elimine as
respostas menos plausíveis e depois faça uma suposição entre as opções
plausíveis.
9. Não gaste muito tempo em qualquer questão. Você tem 90 segundos por
questão.
10. Antes de clicar no botão para encerrar o exame, certifique-se de que todas as
questões foram respondidas. O score do exame é baseado no número de
questões a que você respondeu corretamente.
11. Se sobrar tempo, revise as questões.
12. Procure não ficar mudando as respostas na revisão – geralmente a sua
primeira escolha é a correta, a menos que você não tenha lido corretamente a
questão na primeira vez.

198
9.4 Certificado ITIL
Resultado do exame
Após ter encerrado seu exame você vai obter um relatório mostrando o resultado e
qual foi o seu percentual de acerto por unidade de aprendizagem conforme o currículo
do exame.

Certificado
Após a aprovação, em até 5 dias liberado o certificado em PDF no portal do candidato
fornecido pela PEOPLECERT. Somente há o envio do certificado digital em PDF na
taxa padrão do exame online. A compra do certificado impresso pode ser feita
posteriormente via portal do candidato.

No certificado não constará a sua nota e não é mencionada a edição da ITIL, apenas é
informada a data em que o título foi obtido. No seu currículo e assinatura de e-mail
poderá ser citado que você é “Certificado ITIL Foundation”. Recomenda-se não citar
edição de ITIL, no máximo data do certificado.

Outras questões sobre o certificado

O certificado ITIL Foundation vale por tempo ilimitado e não há obrigação de se
submeter a um novo exame quando for lançada uma nova edição para os livros da
ITIL. Também não há taxas de manutenção do certificado.

Para questões relacionadas à correção do seu nome no certificado, extravio no

recebimento do certificado pelo correio, não recebimento do acesso para baixar o
certificado em PDF ou inclusão do seu nome no diretório de profissionais, você deverá
contatar diretamente o instituto de exame. A PEOPLECERT oferece suporte pelo
formulário de contato no site www.peoplecert.org.

199
Referências Bibliográficas
As referências abaixo foram utilizadas para elaborar o conteúdo do curso e-learning
Fundamentos no Gerenciamento de Serviços com base na ITIL® edição 2011.

Bon, Jan Van; et al. – “Foundations of IT Service Management Based on ITIL V3”. Van
Haren Publishing, 2007.

ITIL – “Continual Service Improvement”. Londres: TSO, 2011

ITIL – “Service Design”. Londres: TSO, 2011

ITIL – “Service Operation”. Londres: TSO, 2011

ITIL – “Service Strategy”. Londres: TSO, 2011

ITIL – “Service Transition”. Londres: TSO, 2011

ITIL – “The Official Introduction to the ITIL Service Lifecycle”. Londres: TSO, 2011

ITIL Glossary. Londres: TSO, 2011

ORAND, Brady – “Foundations of It Service Management”. ITILYaBrady, 2011.

200