Ebook ITILv3 Foundation-115

tel (41) 3045.7810 - info@dltec.com.br - www.dltec.com.
br
DlteC do Brasil®
www.dltec.com.br
info@dltec.com.br | 41 3045.7810
DLTEC DO
BRASIL
ITIL® FOUNDATION
Apostila Impressa do Curso de ITIL® Foundation

DlteC do Brasil®
Todos os direitos reservados©
Apostila do Curso ITIL ® Foundation Página 1

tel (41) 3045.7810 - info@dltec.com.br - www.dltec.com.br
Sobre o E-book/Apostila
O conteúdo desse documento é uma adaptação

da matéria online de leitura do curso.
O presente material traz conteúdo teórico do cur-

so online, porém temos que deixar claro que não
é um curso e sim uma adaptação do nosso
material online para e-book/apostila. Portan-
to recursos como exercícios, simulados, tutoria
(tira dúvidas com professores) e vídeo aulas não
fazem parte desse e-book, pois são exclusivos
para alunos devidamente matriculados em nosso
site oficial.
Para maiores informações sobre nossos treinamento visite o

site:
>>> http://www.dltec.com.br <<<

Direitos Autorais
Aviso Importante!
Esse material é de propriedade da DlteC do Brasil Ltda e é protegido

pela lei de direitos autorais 9610/98.
É expressamente proibida cópia física ou em meio digital, reprodução

parcial, reprografia, fotocópia ou qualquer forma de extração de infor-
mações deste sem prévia autorização da DlteC do Brasil conforme le-
gislação vigente.
Seu uso pessoal e intransferível é somente para o cliente que adquiriu o

referido e-book/apostila.
A cópia e distribuição são expressamente proibidas e seu descumpri-

mento implica em processo cível de danos morais e materiais previstos
na legislação contra quem copia e para quem distribui, sejam cópias físi-
cas e/ou digitais.
Copyright © 2016.

Indice
Capítulo 01 - Gerenciamento de Serviço como uma Prática ............................................. 5

Capítulo 02 – Estratégia de Serviço ............................................................................... 23
Capítulo 03 – Desenho de Serviço ................................................................................. 36
Capítulo 04 – Transição de Serviço ................................................................................ 70
Capítulo 05 – Operação de Serviço................................................................................ 91
Capítulo 06 – Melhoria Contínua de Serviço ................................................................ 114

Capítulo 01 - Gerenciamen-
to de Serviço como uma
O primeiro capítulo do cur- Prática
so fará uma introdução ao
estudo da ITIL®. Conhece- Objetivos do Capítulo
remos as suas principais
características, conceitos Ao final desse capítulo você deverá ser
capaz de:
chave (MUITO IMPORTAN-
TES), os estágios do ciclo de  Saber de onde veio a ITIL® e os seus
vida do serviço, etc. principais benefícios.
 Conhecer os estágios do ciclo de vida
de serviço da ITIL®.
 Compreender conceitos chave iniciais.
Estudaremos também sobre
os principais tipos de prove-
dores de serviços, entende- Sumário do Capítulo
remos o porquê da ITIL® ser
um framework tão bem- 1 Tópicos do Exame ________________ 6
sucedido e veremos como a 2 Introdução ______________________ 7
Governança age sobre o
ciclo de vida de serviço. 2.1 Estratégia de Serviço _____________ 9
2.2 Desenho de Serviço ______________ 9
2.3 Transição de Serviço _____________ 9
2.4 Operação de Serviço ____________ 10
É importante que todos os
conceitos e tópicos aqui a- 2.5 Melhoria Contínua de Serviço _____ 10
presentados estejam “na 3 O Sucesso da ITIL ________________ 10
ponta da língua” antes de
4 Serviços e Gerenciamento _________ 11
passar para o próximo capí-
tulo. Não tenha pressa! 5 Tipos de Provedores de Serviços,
Processos e Funções _________________ 15
6 A Governança no Ciclo de Vida de
Serviço ____________________________ 18
7 Automação de Serviço ____________ 19
8 Bate papo ______________________ 20
8.1 A Certificação ITIL Foundation _____ 20
8.2 Como Deverei Estudar? __________ 22
Desejamos a todos bons es- 8.3 Quando Deverei Agendar o Exame? 22

tudos.

1 Tópicos do Exame
 (ITIL®FND01) Gerenciamento de Serviço como uma Prática:
 (ITIL®FND01-1) descrever o conceito de melhores práticas no domínio público.
 (ITIL®FND01-2) descrever e explicar o porquê da ITIL® ser bem-sucedida.
 (ITIL®FND01-3) definir e explicar o conceito de um serviço.
 (ITIL®FND01-6) definir e explicar o conceito de gerenciamento de serviço.
 (ITIL®FND01-7) definir e explicar o conceito de gerenciamento de serviço de TI.
 (ITIL®FND01-8) definir e explicar o conceito de partes interessadas no gerenciamento de serviço.
 (ITIL®FND01-9) definir processos e funções.
 (ITIL®FND01-10) explicar o modelo de processo e as características de processos.
 (ITIL®FND02) O ciclo de vida de serviço da ITIL:
 (ITIL®FND02-2) descrever a estrutura do ciclo de vida de serviço da ITIL.
 (ITIL®FND03) Conceitos Genéricos e Definições:
 (ITIL®FND03-2) Ativos, recursos e capacidades.
 (ITIL®FND03-5) Governança.
 (ITIL®FND03-8) Provedor de serviço.
 (ITIL®FND03-10) fornecedor.
 (ITIL®FND03-39) resultados.
 (ITIL®FND04) Princípios-chave e modelos:
 (ITIL®FND04-2) descrever a criação de valor através dos serviços.
 (ITIL®FND08) Tecnologia e arquitetura:
 entender como a automação de serviço auxilia na agilização dos processos de geren-

(ITIL®FND08-2)
ciamento de serviço.
Apostila do Curso de ITIL® Página 6

2 Introdução
A ITIL® é um conjunto de melhores práticas para o Gerenciamento de Serviços de Tecnologia
da Informação (GSTI). Atualmente de propriedade da joint venture Axelos (constituída pelo
Governo do Reino Unido e Capita), a ITIL® oferece um guia para a provisão de serviços de TI
com maior qualidade, além de processos, funções e outras capacidades necessárias para supor-
tá-los. Trata-se do framework mais reconhecido mundialmente quando se trata em GSTI, sendo
utilizada em diversas organizações provedoras de serviços, como Microsoft, NASA, IBM, HP,
etc. Quando surgiu, a ITIL® era conhecida pelo acrônimo Information Technology Infrastructre
Library. Entretanto, atualmente o nome representa uma marca (não mais o acrônimo).
A ITIL® não é um padrão que deverá ser seguido. Não se trata de algo pres-
critivo; e sim, de um guia que deverá ser lido e compreendido para que, em
seguida, seja utilizado para criar valor para o provedor de serviços e seus
clientes. Além disso, as melhores práticas da ITIL® poderão ser adaptadas
pelas organizações, conforme às suas necessidades.
A ITIL® emergiu ainda durante a década de 1980, quando o Governo Britânico apontava que o
nível dos serviços de Tecnologia da Informação (TI) que lhe eram oferecidos não possuíam a
devida a qualidade. O Office of Government Commerce (OGC), antes chamada de Central Com-
puter and Telecommunications Agency (CCTA), foi solicitada para desenvolver um framework
visando a utilização eficiente e financeiramente vantajosa dos recursos de TI - tanto para o go-
verno Britânico quanto para setores privados. Assim surgiu a ITIL®. Apesar dessa primeiríssi-
ma versão ser bem diferente da atual, a essência já estava sendo definida: foco na entrega e
suporte aos serviços que eram oferecidos. Interessante notar que essa versão (assumida
como ITIL v.1) continha uma biblioteca composta por cerca de 30 volumes.
Com o sucesso, esse framework começou a se espalhar pela Europa durante a década de 1990.
Começou então a ser utilizada também por organizações não governamentais. Com isso, a TI
como um todo cresceu bastante. Em 2000-2001, a versão 2 foi lançada, tornando a ITIL® ain-
da mais acessível. Agora, continha apenas 9 volumes.
Em 2007, a ITIL® v.3 foi liberada – dessa vez, ainda mais compacta: 5 volumes. Na época do
lançamento, essa versão era conhecida como ITIL Refresh Project. Foi nela que se começou a
estruturar os serviços em ciclos de vida. Atualmente, a ITIL® v.3 é conhecida como ITIL®
2007.
A atual versão do framework é aquela lançada em julho de 2011. Trata-se, na verdade, de um

update da versão de 2007. Na versão de 2011, a ITIL® veio em uma coleção principal (core)
contendo 5 publicações (que já veremos). Assim, esses 5 volumes formam o framework princi-
pal de melhores práticas que diversos gerentes de serviços de TI ao redor do globo utilizam.

Observe abaixo as capas das edições 2007, 2011 (original) e a nova prensagem da anexos:
É importante salientar que a ITIL® não certifica empresas, e sim pessoas. A ISO/IEC 20000 é
aquela que oferece um padrão universal e formal para organizações que buscam auditar e certi-
ficar suas capacidades de Gerenciamento de Serviço.
O framework da ITIL® é baseado nos 5 estágios do ciclo de vida do serviço. A publicação core
oferece guias de boas práticas para cada um dos estágios, incluindo princípios-chave, processos
e atividades, papéis, etc. Veremos que cada estágio exerce influência sobre os demais, além de
gerar saídas que significarão, muitas vezes, entradas para outros. Existem ainda outras publi-
cações complementares da ITIL®, onde são apresentadas guias para setores específicos, tipos
de organizações específicas, etc. Nós estudaremos aqui o material core. Veja a seguir a figura
que ilustra o ciclo de vida de serviço da ITIL:

2.1 Estratégia de Serviço
No centro do ciclo de vida do serviço encontra-se a Estratégia de Serviço. A criação de valor

começa justamente nesse estágio. A ES (Estratégia de Serviço) busca compreender os objeti-
vos organizacionais e as necessidades dos clientes. Todos os ativos da organização, incluindo
pessoas, processos e produtos, deverão suportar a estratégia. Aqui, o foco é sobre o porquê
alguma coisa deve ser feita (ao contrário de como ser feita).
O estágio busca visualizar a TI como um ativo estratégico, ao contrário de somente uma função
administrativa interna. Dessa forma, no estágio em questão, diversos tópicos importantes esta-
rão presentes, como o desenvolvimento de espaços de mercado (oportunidades que o provedor
de serviços de TI poderia explorar para atender as necessidades dos clientes), as características
dos tipos de provedores de serviço1, ativos estratégicos, o portfólio de serviço e a implementa-
ção da estratégia pelo ciclo de vida do serviço.
2.2 Desenho de Serviço
Para que o provedor de serviços consiga entregar valor aos clientes, os serviços precisam ser
desenhados de maneira que estejam alinhados aos objetivos de negócio dos mesmos. Sendo
assim, o estágio Desenho de Serviço oferece um guia para o desenho e desenvolvimento de
serviços, cobrindo os princípios e métodos de desenho que buscará traduzir os objetivos estra-
tégicos em portfólios de serviço e ativos de serviço. É nesse estágio que o “como deve ser fei-
to? ” entrará em ação.
2.3 Transição de Serviço
Como no estágio anterior o serviço já fora desenhado, agora busca-se através da Transição de
Serviço desenvolver e melhorar as capacidades para a introdução de novos ou alterados servi-
ços em ambientes suportáveis. Ou seja, a TS descreve como transicionar uma organização de
um estado para outro, controlando devidamente os riscos e suportando o conhecimento organi-
zacional para o suporte às decisões. O valor criado na estratégia e codificado no desenho será
agora transicionado para o ambiente de produção para que, logo em seguida, o valor do serviço
seja realizado na Operação de Serviço.
Um dos mais importantes tópicos do estágio é o Sistema de Gerenciamento do Conhecimento

de Serviço, que poderá oferecer suporte ao aprendizado organizacional, além de ajudar a me-
lhorar a eficiência geral e efetividade de todos os estágios do ciclo de vida.
1
Organização que oferece serviços para um ou mais clientes internos ou externos

2.4 Operação de Serviço
Nesse estágio serão descritas as melhores práticas para gerenciar os serviços nos ambientes. O
“papo” aqui agora será operacional – o dia a dia no fornecimento do serviço. O estágio buscará
oferecer guias para atingir a efetividade e eficiência na entrega dos serviços e, especialmente,
no suporte aos serviços – assim, o valor poderá ser realizado pelo cliente, usuários e provedor
de serviços. O foco do estágio é “manter” a estabilidade da operação do serviço.
2.5 Melhoria Contínua de Serviço
A Melhoria Contínua de Serviço, como já podemos deduzir, buscará oferecer guias sobre como
criar e manter o valor para os clientes através de melhores estratégias, desenhos, transição e
operação dos serviços.
O estágio oferece as melhores práticas para atingir melhorias incrementais e de larga-escala na

qualidade dos serviços, na eficiência operacional e na continuidade do negócio. Uma das preo-
cupações do estágio é fazer com o que o portfólio de serviço esteja sempre alinhado com as
necessidades de negócio. Busca-se, também, realizar medições e avaliar a maturidade dos ser-
viços, demonstrar valor através de métricas e desenvolver linhas de base2.
3 O Sucesso da ITIL
Como vimos, a ITIL® é utilizada por muitas organizações no mundo inteiro. São diversos os
casos de sucesso na implementação das suas boas práticas. Por exemplo, a Gartner apontou
que a PEMCO investiu no treinamento ITIL® Essentials com a Pink Elephant, em 2002, e resul-
tou posteriormente numa economia geral de $500,000 em 12 meses. São muitos os casos
(pesquise – fará você compreender ainda melhor o “mundo ITIL®”).
Os principais motivos que fizeram a ITIL® ser um sucesso são:
 Neutralidade: as práticas de gerenciamento de serviços de TI são aplicáveis a qualquer tipo

de organização de TI, porque não são baseadas em uma plataforma tecnológica específica ou
área industrial – é neutra. A ITIL® não é vinculada a qualquer prática ou solução proprietá-
ria.
 Descritividade: A ITIL® oferece práticas robustas, maduras e testadas que possuem apli-
cabilidade a todos os tipos de organizações provedoras de serviços. Ainda continua a ser re-
levante nos setores público e privado, provedores internos e externos, pequenas/médias e
grandes empresas e dentro de qualquer ambiente técnico. Assim, ela é flexível o suficiente
para que uma organização a adote e adapte-a segundo as suas necessidades (não é prescri-
tiva).
 Melhores práticas: A ITIL® representa as experiências de aprendizado e liderança de pen-
samento dos maiores provedores de serviço do mundo.
2
Uma espécie de “fotografia” que é utilizado como ponto de referência. Por exemplo, uma linha de base da configura-
ção pode ser usada como parte de um plano de “retorno”, para permitir que a infraestrutura seja restaurada ao estado
anterior à uma mudança ou liberação realizadas com problemas.

4 Serviços e Gerenciamento
A ITIL® define serviço como sendo “um meio de entregar valor aos clientes, facilitando os resul-
tados3 que desejam alcançar, sem apropriar-se de custos e riscos específicos. ”. Imagine a sua
rede social preferida. Ela permite que você interaja com seus amigos, familiares e compartilhe
notícias, por exemplo. Você, como usuário, não deseja entender ou gerenciar toda a complexi-
dade que envolve esse serviço (servidores espalhados pelo mundo, aplicações diversas, contas
de usuário, etc). O cliente entende que o serviço possui os seus custos e que estes estão por
trás da provisão dos serviços. Mas tais custos, além dos riscos, devem ser gerenciados pelo
provedor de serviços, não pelo cliente.
Focando-se no resultado desejado pelo cliente e gerenciando os serviços apropriadamente, o

provedor de serviços conseguirá INTEGRAR a TI com o negócio do cliente (o alinhamento com o
negócio já é pré-requisito. O intuito é a INTEGRAÇÃO).
A ITIL® define serviços de TI como sendo qualquer serviço oferecido por

um provedor de serviços de TI. Os serviços são compostos por uma
combinação de TI, pessoas e processos. A satisfação do cliente com os
serviços oferecidos é também um importantíssimo aspecto da entrega.
Apesar dos clientes não quererem prestar contas ou apropriar-se dos
custos e riscos associados a um serviço, essas questões ainda deverão
ser gerenciadas (pelo provedor, claro). Os custos dos serviços serão
refletidos em termos financeiros, como ROI4 e TCO5.
Os serviços também podem ser classificados, segundo o valor que oferecem aos clientes:
 Serviços principais: aqueles que entregam os resultados básicos desejados pelo cliente. É
o serviço que o cliente quer. Por exemplo, um serviço de controle de estoque básico.
 Serviços de apoio: o serviço principal poderá utilizar outros serviços para que possa reali-
zar efetivamente o seu trabalho (em muitos casos, nem são notados pelos clientes). Para
que o serviço principal (Controle de Estoque) seja entregue, os links de rede deverão estar
disponíveis, por exemplo. Esse seria o serviço de apoio.
 Serviços Intensificadores: são serviços plus; aqueles adicionais que, ao serem acrescen-
tados aos serviços principais, os tornam mais atraentes ao cliente. Mas, não são essenciais
para a entrega dos serviços principais. O provedor de serviços poderia oferecer, juntamente
ao serviço principal, uma interface Web para tal, de forma que as partes interessadas pu-
dessem acessá-lo remotamente.
Outro exemplo que reforça o que vimos sobre os tipos de serviço é ilustrado na figura abaixo,
representando um serviço de Email:
3
Resultado de uma atividade que fora seguida por um processo.
4
Return Of Investment: trata-se do retorno do capital que fora investido no serviço.
5
Total Cost of Ownership: trata-se do custo total de aquisição, instalação, utilização, manutenção, mudança e elimina-
ção de um serviço.

O gerenciamento de serviços é um conjunto de capacidades organizacionais especializadas para

o provimento de valor aos clientes na forma de serviços. Quanto mais madura as capacidades
de um provedor de serviços, melhor será a sua habilidade em produzir, de maneira consistente,
serviços de qualidade que atendam (em tempo e com baixo custo) às necessidades dos clien-
tes.
O principal propósito do gerenciamento de serviços é transformar capacidades

e recursos em serviços valiosos. Sem tais capacidades, uma organização
prestadora de serviços é, simplesmente, um amontado de recursos, que pos-
sui relativamente baixo valor intrínseco para os clientes.
O valor de um serviço pode ser considerado como sendo o nível que o serviço atende às expec-
tativas dos clientes. Ao contrário de produtos, por exemplo, os serviços não possuem valor in-
trínseco, já que seu valor é “calculado” segundo o quê ele possibilita alguém a fazer. Então,
atente-se ao que vem a seguir sobre as características do Valor:
 O valor é definido pelo cliente: não importa o quanto o provedor de serviços ressalte a
importância dos seus serviços. A última palavra em relação a se o serviço é valioso é a do
cliente;
 Acessível mix de recursos: é fato que se pode influenciar a percepção de valor do cliente
através de negociações. Entretanto, o cliente ainda terá a palavra final (se é valioso ou não).
Ou seja, o cliente escolherá aquele produto ou serviço que representa o melhor mix de re-
cursos com o preço que estejam dispostos a pagar;
 Atingir os objetivos: os clientes nem sempre medem o valor do serviço de maneira finan-
ceira. Nem sempre os clientes desejam produzir receita com os serviços, mas atender a al-
gum objetivo de negócio (resultado de negócio).
 Altera com o tempo e com as circunstâncias: o que é valioso para um cliente HOJE po-
derá não ser AMANHÃ, pois suas necessidades são alteradas com o passar do tempo.

Viu só a complexidade em relação ao valor de um serviço? Além da funcionalidade do serviço,

custo e se o serviço atende aos resultados de negócio, o valor também possui outros compo-
nentes:
As preferências são influenciadas pelas percepções. As percepções, por outro lado, são influen-
ciadas, dentre outras coisas, pelos atributos de um serviço, experiências prévias com atributos
similares e a capacidade relativa dos concorrentes. Visualize outra figura importantíssima para
o exame abaixo:
Na figura anterior, o ponto inicial é o valor de referência, ou seja, o que o cliente já ouviu falar
sobre o serviço (ou até mesmo já experenciou). A diferença positiva é baseada nos benefícios
adicionais e ganhos oferecidos pelo provedor de serviços (influência do provedor de serviços no
valor).

A diferença negativa é a percepção do que o cliente perderia ao investir no serviço. A diferença

net é a percepção “de fato” que o cliente possui sobre o serviço (referência menos a diferença
negativa). O valor econômico é o valor total que o cliente percebe sobre o serviço a ser entre-
gue.
Vale ressaltar agora outros conceitos importantes:
 Ativos: Todas as interações entre provedor de serviço e cliente são baseadas na utilização
de ativos. Podem ser classificados como Ativos de Cliente (qualquer recurso/capacidade usa-
do pelo cliente para atingir um resultado de negócio) e Ativo de Serviço (qualquer recur-
so/capacidade usado pelo provedor de serviço para entregar os serviços). Há dois tipos de
ativos utilizados pelos provedores de serviço e clientes, que servem para criar valor na forma
de bens e serviços:
 Recursos: são as entradas diretas para a produção dos serviços. Por exemplo: dinheiro,
aplicações, pessoas, infraestrutura, etc. Ou seja, tudo que poderia ser usado para auxili-
ar a entrega de um serviço.
 Capacidades: são os ativos que representam a habilidade de uma organização para fa-
zer alguma coisa – de forma a atingir o valor (como a habilidade de coordenar, controlar
e implantar recursos na forma de um serviço).

5 Tipos de Provedores de Serviços, Processos e Funções

A ITIL® classifica os provedores de serviços em três tipos:
Tipo I (Provedores de serviços internos): são funções de negócio embutidas dentro das
unidades organizacionais6 que eles servem. Logo, são dedicados.
São caracterizados por serem especializados em servir um conjunto relativamente pequeno de

necessidades de negócio. Os seus objetivos primários são atingir excelência operacional e pos-
suir bom custo/efetividade para as suas unidades organizacionais.
Seu crescimento é limitado pelo crescimento da unidade organizacional a qual pertencem.
Tipo II (Unidades de Serviços Compartilhados): Funções como finanças, TI e Recursos

Humanos nem sempre são a vantagem competitiva de uma organização. Assim, os seus servi-
ços são posicionados em unidades separadas, denominadas Unidades de Serviços Compartilha-
dos. Logo, como podemos deduzir, elas poderão atender a diversas unidades de negócio ao
mesmo tempo (ao invés de ter uma TI em cada uma delas). Como vantagem, podemos citar a
redução de custos (em comparação com o tipo III) e padronização. Como desvantagem, existe
a pressão pela comparação com provedores de serviços externos.
6
Segmento de negócio que possui seus próprios planos métricas, receita e custos.

Tipo III (Provedores de serviços externos): oferece seus serviços a clientes externos. Por
exemplo, muitas vezes os serviços de TI não estão no portfólio de investimento para uma orga-
nização, já que é necessária flexibilidade em seus ambientes para manter-se competitivo. Sen-
do assim, é melhor comprar tais serviços. Embora não seja mostrado na figura a seguir, mesmo
usando provedores de serviços do tipo III, a organização ainda precisaria de uma função de TI
interna para gerenciar a especificação dos requisitos, contratos e garantir que os resultados de
negócio estão sendo alcançados.
Para o exame ITIL® Foundation, é também importante reconhecer a diferença entre Processos
e Funções.
Processo é um conjunto de atividades necessárias para se realizar um objetivo específico, to-

mando entradas definidas e transformando-as em saídas definidas7. O framework da ITIL®, por
exemplo, é baseado em processos. Possuem as seguintes características:
 Mensurabilidade: os processos são direcionados a desempenho e, sendo assim, poderão

ser medidos de acordo com a perspectiva de quem analisa;
 Resultados específicos: os processos existem para entregar resultados específicos, que

deverão ser individualmente identificáveis e contáveis;
 Clientes: os processos sempre entregam resultados a clientes (internos ou externos) ou

partes interessadas8; a necessidade é que eles devem sempre atender as suas expectati-
vas;
7
As entradas são dados ou informações utilizadas pelos processos e podem se tornar a saída para outros processos.
8
Qualquer pessoa que possua interesse em uma organização, projeto, serviço de TI, etc. Isso inclui gerentes, parceiros,
funcionários, etc.

 Respondem a gatilhos específicos: Ape-

sar dos processos poderem ser contínuos
ou iterativos, eles sempre deverão ser ras-
treáveis a um gatilho específico.
Dentro de um processo, podemos definir ações,

dependências e sequência. Além disso, uma vez
definidos, eles deverão ser documentados e
controlados (para que possam se tornar repetí-
veis e gerenciados). Vejamos ao lado a imagem
que ilustra o modelo de processo:
Analisando a figura, podemos distinguir três

seções. A primeira delas, Controle, mostra to-
dos os controles que são necessários para que o
processo consiga de fato existir.
Como vimos, os processos possuem um conjunto organizado de objetivos. Esses incluirão as

medidas do processo (métricas) e outras saídas (ações de melhoria, reports de desempenho,
etc).
Na seção central, podemos ver as entradas, saídas e atividades. Se as saídas de um processo

atender aos requisitos especificados pelos objetivos de negócio, pode-se dizer que o mesmo é
efetivo.
Se pensarmos em uma receita de bolo, por exemplo, as entradas seriam os ingredientes, as

atividades seriam os métodos e a saída, claro, seria o bolo. As decisões sobre os tipos de ingre-
dientes seriam baseadas no ‘resultado’ requerido, por exemplo. Tudo isso deverá satisfazer as
partes interessadas, em termos de qualidade.
A ITIL® define “Função” como sendo um grupo de pessoas que são utilizadas
para executar um processo. Isso também inclui outros recursos ou ferramen-
tas, desde que sejam utilizadas para tal fim. Como estudaremos as funções
definidas pela ITIL® no capítulo 5, esturaremos aqui somente a definição.
Geralmente, em organizações maiores, uma função pode ser “particionada” e realizada por in-
divíduos ou grupos – contendo habilidades específicas com as tarefas a serem executadas. Já
em organizações menores, podem haver poucos grupos especializados. Assim, uma ou mais
equipes poderão ser responsabilizadas por executar diversas funções.

É importante não confundir Papel com “título do trabalho”. Cada organização define um título
de trabalho de acordo com suas necessidades, mas os indivíduos com um determinado título
poderão realizar um ou mais papéis. Vejamos as definições para que tudo isso torne-se mais
claro:
 Papel: conjunto de responsabilidades, atividades e autoridades concedidas à uma pessoa ou

equipe. Um papel é definido em um processo ou função.
 Grupo: pessoas realizando atividades similares, mas não são normalmente vistos como es-
truturas formais. São usados para garantir que os processos sejam executados da mesma
maneira através de diferentes áreas na organização.
 Equipe: as equipes são estruturas formais, trabalhando juntos em prol de objetivos comuns.
Podem ou não estarem localizados no mesmo lugar. Ex: equipe de projetos, de resolução de
incidentes, etc.
 Departamentos: são estruturas formais dentro das organizações, que existem para realizar
um conjunto específico de atividades definidas.
 Divisão: refere-se ao número de departamentos que foram reunidos (agrupados). Geral-
mente são independentes.
Vimos há pouco o conceito de “partes interessadas”, mas não explanamos muito ainda sobre
isso. Dentro da organização do provedor de serviços existem muitas partes interessadas, inclu-
indo as funções, grupos e equipes que entregam os serviços.
Entretanto, existem as chamadas “partes interessadas externas” como os Clientes (aqueles que
compram os bens ou serviços), Usuários (aqueles que usam o serviço no dia a dia) e Fornece-
dores (terceiros responsáveis por oferecer bens ou serviços requeridos para entregar os servi-
ços de TI).
6 A Governança no Ciclo de Vida de Serviço

A Governança9, segundo a ITIL®, é a única área abrangente o suficiente para “enlaçar” a TI
com o negócio, e o serviço é a forma de garantir que a organização está realmente pronta para
executar a governança. A Governança de TI (explanada nas vídeo-aulas do curso) é parte inte-
gral da Governança Empresarial.
Muitas estratégias de gerenciamento de serviços de TI falham porque, ao invés de trabalhar

com as estruturas de governança existentes na organização, tentam impor suas próprias estru-
turas.
A Governança precisa estar preparada para avaliar, direcionar e monitorar a estratégia (deverá
estar clara), políticas (define as fronteiras – o que uma organização pode não fazer como parte
de suas operações) e planos.
9
Garante que políticas e estratégias estão sendo implementadas e que processos requeridos estão sendo seguidos
apropriadamente.

7 Automação de Serviço
Para fechar o capítulo, estudaremos as ferramentas que poderão ser aplicadas no auxílio ao GS.
A automação pode ser extremamente benéfica para a entrega de serviços e melhorar o desem-
penho de processos e ativos de serviço. As aplicações são meios de automação por si só, mas
elas podem ser melhoradas pela adição da tecnologia, onde precisarão ser compartilhadas por
pessoas e ativos de processos (vemos avanços em Inteligência Artificial, Aprendizagem de Má-
quina, etc). A automação é considerada para melhorar os aspectos de Utilidade e Garantia (ve-
remos isso no próximo capítulo) dos serviços, oferecendo diversas vantagens:
 Gerenciamento da capacidade: A automação no gerenciamento da capacidade possibilita

respostas mais rápidas às variações de demanda (sem a intervenção humana), além da faci-
lidade de gerenciamento para serviços disponíveis durante 24 horas por dia;
 Medição: possibilita medição consistente e identificação de melhoria, sem a variável huma-

na. Isso também pode mostrar onde o elemento humano (conhecimento, habilidades e expe-
riência) está oferecendo benefícios;
 Otimização: as limitações da capacidade humana (processamento de informações, por e-

xemplo) é compensada pela possibilidade de automação;
 Captura do conhecimento: o gerenciamento de conhecimento orientado a sistemas reduz

a dependência do conhecimento individual e as dificuldades no compartilhamento desses co-
nhecimentos.
Diversas áreas do gerenciamento de serviço podem ser beneficiar pela automação: Desenho e
modelagem, catálogo de serviço, padrão de reconhecimento e análise, etc. A demanda por ser-
viços poderá ser capturada, por exemplo, através de uma simples interação entre os clientes
com os itens do catálogo de serviço – de forma automatizada. A variação na performance dos
indivíduos com o tempo, carga de trabalho, motivação e a natureza das tarefas pode ser des-
vantajoso em algumas situações. Isso tudo poderia ser monitorado/analisado através de ferra-
mentas automatizadas.
Mas, é importante ressaltar algumas considerações:
 Processos ruins, mesmo com ferramentas boas, ainda serão processos ruins (automação do
caos);
 As ferramentas servem para suportar os processos, não em defini-los;
 As ferramentas se adaptam aos processos, não o contrário.

8 Bate papo sobre a Certificação ITIL Foundation

Nessa seção, não iremos discutir nada diretamente relacionado ao currículo ITIL Foundation.
Iremos apenas comentar um pouco sobre como que funciona o esquema de certificação ITIL, os
possíveis caminhos futuros e dicas gerais de como estudar de maneira eficiente para o seu e-
xame. Importante: sobre as dicas, não é algo prescritivo.
Essas dicas são baseadas na minha própria experiência. Sendo assim, pegue as coisas que você
achar mais importante e aplique-as conforme necessário. Vamos lá!
8.1 A Certificação ITIL Foundation
O nível foundation10 é o nível de qualificação de entrada - ou seja, serão apresentados funda-

mentos que irão oferecer uma visão geral dos elementos chave, conceitos e terminologia usada
no ciclo de serviço da ITIL® (isso inclui os processos, os relacionamentos entre os estágios do
ciclo de vida, etc).
Ao obter a certificação, você irá ganhar 2 créditos rumo a certificação mais cobiçada: ITIL®
Master.
10
https://www.axelos.com/qualifications/itil-qualifications/itil-foundation-level

Para quem é indicada?
Dentre os principais tipos de público para a certificação, podemos citar:
 Aqueles que precisam conhecer / ter um entendimento básico do framework da ITIL®;
 Aqueles que precisam entender como a ITIL® pode ser usada para melhorar o gerencia-
mento de serviços de TI em uma organização;
 Profissionais de TI em geral que trabalham em organizações que adotaram as boas prá-

tica da ITIL® e que precisam lidar diariamente com isso
O importante a ser considerado é que o esquema de certificação não termina no nível Funda-
mentos. Longe disso! Mesmo obtendo a certificação ITIL® Foundation, é necessário obter muito
mais conhecimento para que as práticas da ITIL® possam ser aplicadas a projetos profissionais
ou situações do dia a dia dos provedores de serviço de TI.
A certificação Foundation é, como o nome diz: Fundamentos. O ponto de partida! Por isso exis-
tem as demais certificações (Practioner, os módulos Intermediários, etc – conforme ilustrado na
figura acima). Repare que cada certificação possui um número de crédito.
Os módulos intermediários11 são divididos em duas categorias: Ciclo de Vida e Capacidade. Al-
guns candidatos costumam se concentrar apenas em um dos módulos, no entanto, isso não é
regra. Pode-se combinar os módulos conforme você achar necessário. Veja abaixo a divisão das
categorias:
 Ciclo de vida de Serviço (Estratégia de Serviço, Desenho de Serviço, Transição de

Serviço, Operação de Serviço e Melhoria Contínua de Serviço). Então, nessa categoria,
você conseguirá no máximo 15 créditos (+ 2, do nível Foundation);
 Capacidade de Serviço (Análises e suporte operacionais, Planejamento, Proteção e O-

timização, Liberação, Controle e Validação e Acordos e Ofertas de Serviços). Então, nes-
sa categoria, você conseguirá no máximo 16 créditos (+ 2, do nível Foundation).
Após concluir a certificação ITIL® Foundation (já com 2 créditos), você também poderá certifi-
car-se em ITIL® Practioner12 (mas não é obrigatório), antes de ir para os módulos intermediá-
rios. Se optar por essa certificação, você ganhará mais 3 créditos (Totalizando 5).
Para a certificação ITIL® Expert13, é necessário ter acumulado (no mínimo) 17 créditos (nível
Foundation + practioner (se desejar) + os módulos intermediários). Assim, após ter acumulado
essa quantidade, é necessário realizar o exame MALC (Managing across the Life Cycle).
Lembrando que, para a certificação ITIL® Master, é necessário já possuir a certificação ITIL®
Expert e, além disso, já ter trabalhado no mínimo 5 anos em elevado nível de gestão. Ou seja,
já deverá ter bastante experiência prática com a ITIL®.
Para conhecer mais detalhes sobre o esquema de certificação ITIL®, visite o website:
https://www.axelos.com/qualifications/itil-qualifications.
11
https://www.axelos.com/qualifications/itil-qualifications/itil-intermediate-level
12
https://www.axelos.com/qualifications/itil-qualifications/itil-practitioner-level
13
https://www.axelos.com/qualifications/itil-qualifications/itil-expert-level

8.2 Como Deverei Estudar?
Primeiramente você deve fazer um levantamento dos seus horários e identificar aqueles consi-
derados livre. Esse será o seu tempo de estudo. Por exemplo, de Segunda a Sexta você tem 2
horas livres (descontando tempo de trabalho, família, etc.). Pegue essas 2 horas e divide: 1
hora de teoria e 1 hora de exercícios.
Teoria sem exercícios, é nula! A teoria deve sempre ser intercalada com a elaboração de resu-
mos sobre o capítulo que você já leu. Ao realizar os resumos, não escreva na íntegra o que vo-
cê já leu na apostila.
Escreva com suas próprias palavras. Se você assimilar mais por elementos visuais, faça dese-
nhos...tudo com o intuito de você assimilar ao máximo as informações. Com o decorrer do cur-
so, muitos conteúdos virão.
Assim, não deixe acumular. Só passe para o próximo tópico quando você já tiver assimilado as
ideias principais do anterior.
Não tenha pressa. Também não precisa ficar decorando tudo. A certificação é no nível Funda-
mentos; assim, não pense em como tal coisa seria na prática, como isso seria feito ou como
aquilo poderia trazer problemas. Pegue os conceitos. Outros tópicos mais avançados virão nas
próximas certificações que você for “tirar”.
8.3 Quando Deverei Agendar o Exame?
Comigo funciona assim: só consigo estudar com um “marco”... o dia do exame! Logo, se você
também é assim, marque o dia do seu exame. Claro, em uma data plausível, né? Aquela data
que, após fazer o levantamento do tempo que você possui para estudar, você dará conta.
Trata-se de um curso longo. No meu caso, eu tinha 2 horas por dia para estudar. Eu agendei o
exame para 2 meses a frente. Eu me sentia confortável dessa forma. Você tem que se conhecer
nesse quesito. Mas, o fato é: poucas pessoas conseguem estudar de maneira efetiva sem uma
data “marco”... sem o dia do exame.
Portanto, minha dica é: marque o dia da prova e faça o seu cronograma de estudos, de modo
que você consiga ter tempo para estudar, para sua família, para seus compromissos, etc. Mui-
tos perguntam se o exame é difícil.
A resposta é a mesma: depende do quanto você estudou.
O exame não apresenta pegadinhas. É direto. É aquele “sabe ou não sabe”. Prepara-se para
uma rotina de estudos que, garanto: você não terá qualquer dificuldade e terá, muito em bre-
ve, o certificado em suas mãos.

Capítulo 02 – Estratégia de
Como vimos no capítulo
Serviço
anterior, o framework da
ITIL® é baseado nos 5 está- Objetivos do Capítulo
gios do ciclo de vida de um Ao final desse capítulo você deverá ser
serviço. Cada um dos livros capaz de:
que compõe a ITIL® traz um
guia de boas práticas rela-
cionados a cada um dos  Explicar e definir conceitos básicos rela-
ciclos. cionados ao gerenciamento de serviço
de TI relacionados à Estratégia de Ser-
viço.
Nesse capítulo iremos estu-  Compreender todos os processos rela-

dar o primeiro estágio do cionados ao estágio que são cobrados
ciclo de vida do serviço: Es- no exame ITIL® Foundation, edição
2011.
tratégia de Serviço. Dessa
forma, entenderemos os
princípios- chave e proces-
sos cobrados no exame I- Sumário do Capítulo
TIL® Foundation, ed. 2011.
Ao contrário dos próximos
capítulos, nesse não estuda- 1 Tópicos do Exame _______________ 24
remos nenhum processo em 2 A Estratégia de Serviço ___________ 25
detalhes. Ao todo, veremos
2.1 Conceitos importantes ___________ 26
aqui 03 processos.
3 Processos ______________________ 28
3.1 Gerenciamento do Portfólio de Serviço
28
Todo o texto presente aqui é 3.2 Gerenciamento financeiro para
importante para a prova. serviços de TI ________________________ 30
Assim, estude-o com aten- 3.3 Gerenciamento de Relacionamento de
ção... Leia e releia quantas Negócio ____________________________ 32
vezes for necessário. Não
siga para o próximo capítu- 4 Padrões de Atividade de Negócio ___ 34
lo sem antes entender os 5 Gestão de Risco _________________ 35
conceitos chave desse está-
gio.
Essa é a dica! Desejamos a

todos bons estudos.

1 Tópicos do Exame
 (ITIL®FND02) ciclo de vida de serviço da ITIL®:
 (ITIL®FND02-3) ciência do propósito, objetivos e escopo da estratégia de serviço.
 (ITIL®FND02-4) explicar qual o valor entregue pela estratégia de serviço ao negócio.
 (ITIL®®FND03) conceitos genéricos e definições básicas:
 (ITIL®FND03-1) utilidade e garantia.
 (ITIL®FND03-3) portfólio de serviço.
 (ITIL®FND03-6) caso de negócio (Business Case).
 (ITIL®FND03-7) gerenciamento de risco.
 (ITIL®FND03-40) Padrões de atividade de negócio.
 (ITIL®FND03-41) clientes x usuários
 (ITIL®®FND05) sobre os processos:
 (ITIL®FND05-2) declarar o propósito, objetivos e escopo de:
o (ITIL®FND05-21) gerenciamento do portfólio de serviço.
o (ITIL®FND05-22) gerenciamento financeiro para serviços de TI.
o (ITIL®FND05-23) gerenciamento de relacionamento de negócio.

2 A Estratégia de Serviço
Propósito:
Definir a perspectiva, posição, planos e padrões que um provedor de serviços precisa estar
pronto para executar, de forma a atender os resultados de negócio de uma organização.
A Estratégia de Serviço é o estágio que visa obter o direcionamento geral do negócio; ou seja,
“para onde estamos indo? ”. É nesse estágio que a perspectiva é definida, a criação de valor é
iniciada para o serviço, a posição é tomada, os planos e padrões são levantados e as posições
são tomadas (os 4Ps da estratégia. Já veremos).
Esse é o propósito do estágio! Tudo que um provedor de serviços precisa para ir de encontro
aos resultados de um negócio. O estágio buscará visualizar o gerenciamento de serviço como
um ativo estratégico, ao invés de apenas uma capacidade organizacional.
Assim sendo, o foco desse estágio é entender o PORQUÊ algo deve ser feito, não em COMO ser
feito! Para o exame ITIL® Foundation, não precisamos estudar “a fundo” nenhum dos processos
contidos no estágio; apenas entender o propósito (para que serve), objetivos (o que tem que
ser feito para atingir o propósito) e escopo (qual a “área de atuação” do estágio).
Objetivos:
 Compreender o conceito de estratégia;
 Identificar os serviços e os clientes que os utilizarão;
 Entender a criação e a entrega de valor;
 Oferecer meios para identificar oportunidades de serviços e como tirar o melhor proveito dos
mesmos;
 Entregar um claro e compreensivo modelo de provisão de serviço, onde será possível identi-
ficar como os serviços serão consolidados e apresentados, para quem serão entregues e o
propósito;
 Entender a capacidade organizacional que será necessária para entregar os serviços de acor-
do com a estratégia;
 Coordenar e documentar o uso dos ativos de serviço usados para fornecer o serviço, incluin-
do a otimização de desempenho;
 Definir o nível de investimento que será necessário para o provimento dos serviços;
 Entender os níveis de demanda;
 Entender como estabelecer um relacionamento entre o provedor de serviços e o cliente.
Escopo:
A estratégia de serviço começa definindo e discutindo os princípios genéricos e processos do
gerenciamento de serviço. Em seguida, tais princípios genéricos são aplicados de maneira con-
sistente ao gerenciamento de serviços de TI. O seguinte aspecto de estratégia é coberto pelo
estágio:
 Definir a estratégia para entregar os serviços que atenderão aos resultados de negócio dos
clientes, bem como a estratégia para gerenciá-los;

Valor oferecido ao negócio:

 Suporte à habilidade de “linkar” as atividades realizadas pelo provedor de serviços aos resul-
tados que são críticos para os clientes (internos ou externos);
 Possibilta ao provedor de serviços obter um claro compreendimento sobre quais tipos e ní-
veis de serviço trará sucesso aos clientes;
 Possibilita ao provedor de serviços responder rápida e eficientemente às mudanças no ambi-

ente de negócios, garantindo maior vantagem competitiva;
 Suporte à criação e manutenção de um portfólio de serviços quantificado, habilitando ao ne-

gócio atingir retorno positivo sobre os investimentos realizados nos serviços;
 Facilita a comunicação funcional e transparente com o cliente;
 Oferece meios para que o provedor de serviços se organize de forma a conseguir oferecer
serviços de maneira eficiente e efetiva.
2.1 Conceitos importantes
“Estratégia” não é somente um simples plano; ao contrário, é um vasto e complexo conjunto de

atividades de planejamento, cujo foco é fazer com que a organização saia de uma determinada
situação e vá para outra (melhor, claro), baseado nas variáveis (internas e externas) que sofre.
Aplicada aos serviços, a estratégia irá definir como que um provedor de serviços irá usar os
seus serviços para atingir os resultados do negócio dos clientes para que, com isso, consiga
também atingir os seus próprios objetivos.
A ITIL® cita a definição de Henry Mintzberg para “estratégia”. Segundo o autor, ao se definir
estratégia, os seguintes 4 Ps deverão ser considerados. Observe a imagem abaixo:
Para o exame, é importante compreender a diferença entre Cliente e Usuário. Cliente é quem
paga pelo serviço e, eventualmente, também poderá utilizá-lo. Já Usuário é toda pessoa que
utilizará o serviço no dia a dia (não paga pelo serviço, não toma decisões em relações ao mes-
mo).

No capítulo passado, vimos o quão complexo é a questão do “valor” de um serviço. Agora ve-
remos algo muito importante. Sob o ponto de vista do cliente, o valor de um serviço poderá ser
criado combinando dois elementos primários: Utilidade (encaixa-se no propósito) e Garantia
(apto para o uso). A fórmula básica é: Garantia do Serviço + Utilidade do Serviço = Valor
do Serviço. Observe a imagem a seguir:
Outro fator que merece destaque: Os clientes não compram serviços; os clien-
tes compram o cumprimento de necessidades particulares.
A utilidade do serviço refere-se aos aspectos funcionais de um serviço, além do seu impacto
positivo nos processos, atividades e tarefas do negócio. Por outro lado, a garantia do serviço
está relacionada aos atributos de um serviço (disponibilidade, desempenho, capacidade, etc).

3 Processos
Processos de TI nada mais são do que um valoroso agregado de conhecimentos e experiências
acumuladas durante muitos anos por diversas empresas e especialistas do ramo, que perce-
bendo os erros e acertos em suas ações do cotidiano, resolveram sistematizar as melhores
condutas para lidar de forma dinâmica com os riscos característicos da profissão e minimizar as
chances de erros na execução dos mais diversos trabalhos.
Vamos estudar agora os três processos relacionados a estratégia de serviços.
3.1 Gerenciamento do Portfólio de Serviço
Propósito:
O propósito do Gerenciamento do Portfólio de Serviço é garantir que o provedor de serviços
possua o mix correto de serviços para que consiga balancear o investimento feito na TI com a
habilidade de atender aos resultados de negócio.
O processo registrará também os investimentos feitos nos serviços por todo o seu ciclo de vida.
Entenda que o processo trabalha também com outros processos, de forma a garantir que os
retornos desejados estão sendo atingidos.
Ao analisar a figura anterior, percebemos que as informações registradas pelo processo pode-
rão ser encontradas no sistema de gerenciamento do conhecimento de serviço.

Objetivos:
 Oferecer um processo e mecanismos para que uma organização consiga investigar e decidir
sobre quais serviços oferecer, baseado na análise de retorno potencial e nível aceitável de
risco;
 Manter o portfólio definitivo dos serviços oferecidos, articulando as necessidades de negócio

que cada serviço atende e os resultados de negócio que ele suporta;
 Oferecer mecanismo para que a organização avalie como os serviços a possibilitam alcançar
a sua estratégia, além de responder às mudanças em seus ambientes internos e externos;
 Controlar quais serviços são oferecidos (além das condições e níveis de investimentos);
 Registrar o investimento nos serviços pelo ciclo de vida, para que a organização avalie a sua
estratégia;
 Analisar quais serviços não são mais viáveis e quando deverão se tornar aposentados.
Escopo:
Fazem parte do escopo do processo todos os serviços que o provedor de serviços pretende en-
tregar, aqueles que já estão sendo entregues e aqueles que já foram retirados de operação.
No caso de provedores de serviços internos, a tática é que trabalhem em conjunto com as uni-
dades de negócio na organização, para que cada serviço esteja relacionado com os resultados
de negócio – antes de compararem investimentos com os retornos. Para provedores de serviços
externos o valor é calculado mais diretamente, já que cada serviço precisa estar preparado pa-
ra gerar receitas diretas (ou, até mesmo, apoiar os serviços geradores de receitas).
A ITIL® o classifica “portfólio de serviços” como sendo o conjunto completo de serviços que são
gerenciados por um provedor de serviços, utilizado para gerenciar o ciclo de vida completo de
um serviço, além dos investimentos efetuados no mesmo.
O portfólio de serviço inclui 3 categorias de serviço:
1) Funil de serviço: serviços que estão sendo propostos ou, ainda, em desenvolvimento,
mas que não se encontram disponíveis para os clientes – geralmente os clientes nem
possuem acesso);
2) Catálogo de serviço (serviços que já se encontram em operação ou já disponíveis para

a implantação);
3) Serviços aposentados (serviços inativos. São mantidos no portfólio de serviço por di-
versas razões. Por exemplo, muitas vezes o novo serviço poderá não atender a todos os
requisitos. Dessa forma, é importante estar preparado para que, caso aconteça isso,
possa retornar ao serviço anterior).
Em resumo, o portfólio de serviços ajuda a obter as seguintes questões estratégicas (sob a

prisma do provedor de serviços): Por que o cliente compra esses serviços? Por que compram os
nossos serviços? Quais são os nossos pontos fortes e fraquezas, prioridades e riscos? Como os
nossos recursos e capacidades deverão ser alocados?

3.2 Gerenciamento financeiro para serviços de TI
Propósito:
O propósito do processo Gerenciamento Financeiro para Serviços de TI é garantir que haja o
pleno equilíbrio entre o custo e a qualidade de um serviço – ou seja, o quanto o cliente pode
pagar e o que o provedor de serviços consegue oferecer. Dessa forma, o equilíbrio irá exercer
influência sobre as variáveis presentes durante a entrega de um serviço, como a utilidade, ga-
rantia, os recursos, a capacidade, a percepção e as preferências. Além disso, o processo irá
controlar a oferta e demanda entre o provedor de serviços e o cliente. É necessário que os cus-
tos (que se elevam em resposta às demandas) sejam gerenciados de maneira apropriada. Um
exemplo bem característico desse cenário é em relação à capacidade – já que, com o aumento
na demanda, é necessário que o provedor de serviços se organize para conseguir mais capaci-
dade física. E, lógico: isso gera custos!
Escopo:
No contexto da TI, o Gerenciamento Financeiro é uma função separada daquela da organização.
Ou seja, trata-se de uma área especializada, que precisa compreender o mundo das finanças e
do negócio como um todo; além, é claro, de tecnologia. A ITIL® aponta que as políticas finan-
ceiras e práticas dentro da TI devem estar consistentes com as da organização em geral, já
que, além dos aspectos legais e melhores práticas, isso facilita bastante a comunicação e repor-
te entre a TI e as outras unidades de negócio.
O gerenciamento financeiro consiste de três sub-processos principais:
 Orçamento: prediz e controla os gastos de TI. Normalmente a organização de TI tem que

estabelecer, de maneira anual ou semestral, o quanto de dinheiro ela precisará para manter
as operações do dia a dia.
 Contabilidade: possibilita que a organização de TI tome ciência sobre como o seu dinheiro
está sendo gasto (identificar custos por cliente, serviço e atividade).
 Cobrança: requerido para que os clientes sejam cobrados pelos serviços oferecidos.
Objetivos:
 Estabelecer e gerenciar uma estrutura para que consiga identificar, gerenciar e comunicar os
custos dos serviços que são oferecidos;
 Avaliar (de maneira financeira), o impacto das novas estratégias e as propostas de mudan-
ças para as já existentes;
 Garantir financiamento para gerenciar a provisão de serviços;
 Facilitar para que haja uma boa administração do serviço e dos ativos dos clientes. Com isso,
a organização poderá atingir os seus objetivos;
 Entender a relação entrada x saída – e garantir que ambos estejam alinhados em conformi-
dade com as políticas da organização;
 Contabilizar os dinheiros gastos com a criação, entrega e suporte aos serviços;
 Executar as políticas financeiras e práticas na provisão de serviços;
 Prever os requisitos financeiros, para que a organização esteja pronta a atender aos seus
compromissos de serviço com seus clientes e estar de acordo com os requisitos regulatórios
e legislativos;

 Quando apropriado, definir uma estrutura para recuperar os custos da provisão de serviços
ao cliente.
É importante que também estejamos atentos em relação aos Casos de

Negócio – item que também poderá cair no exame ITIL® Foundation.
Caso de Negócio é uma justificativa para um item ou gasto significativo.

Ou seja, trata-se de uma ferramenta de suporte que projeta as conse-
quências de uma ação de negócio (com dimensões qualitativa e quantita-
tiva).
Uma análise financeira, por exemplo, é um ponto crucial para um bem formatado caso de ne-
gócio. Itens que compõe um caso de negócio:
 Introdução: apresenta os objetivos de negócio que o serviço irá de encontro;
 Métodos e premissas: define as fronteiras do caso de negócio, como período de tempo e

qual contexto organizacional está sendo usado para definir os custos e benefícios;
 Impactos no negócio: resultados financeiros e não-financeiros antecipados para o serviço

ou iniciativa de gerenciamento de serviço;
 Riscos e contingências: a probabilidade que resultados alternativos irão emergir;
 Recomendações: ações específicas recomendadas.

3.3 Gerenciamento de Relacionamento de Negócio
Propósito:
O Gerenciamento de Relacionamento de Negócio é o processo que possibilita aos gerentes de
relacionamento de negócio (que geralmente são representantes sêniores da TI) criar relacio-
namentos entre o provedor de serviço e clientes, nos níveis estratégico e tático, para que o
provedor de serviços possa compreender os requisitos de negócio do cliente e estar preparado
para oferecer serviços que vão de encontro com tais requisitos. Além disso, o Gerenciamento
de Relacionamento de Negócio buscará identificar as necessidades do cliente e garantir que o
provedor de serviços esteja pronto para atendê-las, mesmo que o negócio do cliente mude com
o tempo ou devido a circunstâncias;
Objetivos:
 Garantir que o provedor de serviços entenda a perspectiva de serviço do cliente e que esteja
pronto para priorizar seus serviços e ativos de serviço apropriadamente;
 Garantir níveis altos de satisfação do cliente;
 Identificar as mudanças no ambiente do cliente e que poderiam impactar o tipo, nível ou

utilização dos serviços oferecidos;
 Identificar as tendências tecnológicas que poderiam impactar o tipo, nível ou utilização dos
serviços prestados e alertar os clientes;
 Estabelecer e articular os requisitos de negócio para serviços novos ou mudanças naqueles

existentes;
 Garantir que o provedor de serviços esteja sempre atendendo às necessidades de negócio

dos clientes;
 Trabalhar com os clientes para garantir que os serviços e os níveis de serviço estejam pron-
tos para entregar valor;
 Mediar em casos onde haja conflitos de requisitos para serviços de diferentes unidades de
negócio;
 Estabelecer processos formais de reclamações e escalação para o cliente.
Escopo:
Para provedores de serviços interno, o processo é geralmente executado entre um representan-
te sênior da TI e gerentes sêniores das unidades de negócio (clientes). O intuito é alinhar os
objetivos do negócio com a atividade do provedor de serviço.
Para os provedores de serviços externos, o processo é executado geralmente por uma função
dedicada (Gerente de Relacionamento de Negócio) ou gerentes de contas – cada um dedicado a
um cliente ou grupos de clientes menores. O intuito é maximizar o valor do contrato através da
satisfação do cliente.

tel (41) 3045.7810 - info@dltec.com.br
@dltec.com.br - www.dltec.com.br
Para entender como que os serviços atendem aos requisitos do cliente, o processo deve focar
focar-
se em compreender e comunicar:
 Resultados de negócio que o cliente deseja alcançar;
 Os serviços que estão sendo oferecidos aos clientes, bem como a maneira em que estão
sendo oferecidos (os responsáveis pelos mesmos, quais níveis de serviço foram acordados, a
qualidade entregue) e como os clientes o utilizam;
 Como otimizar os serviços para o futuro;
 Medir os níveis de satisfação dos clientes;
 Como o provedor de serviços é representado para o cliente.
É importante deixar claro a diferença primária entre Gerenciamento de Relacionamento de N

Ne-
gócio e Gerenciamento de Nível de Serviço:

4 Padrões de Atividade de Negócio

Apesar do processo Gerenciamento da Demanda não fazer parte do currículo ITIL® Foundation
Syllabus 5.5, há uma parte de seu contexto que poderá cair no exame. Tratam-se dos Padrões
de Atividade de Negócio.
Já que os serviços possibilitam uma atividade de negócio (e essas geram os resultados de ne-
gócio), torna-se necessário entender quaisquer padrões que hajam na atividade de negócio, de
forma a entregar serviços que vão de encontro aos resultados desejados. É fácil reconhecer as
atividades que tendem a formar padrões – são aquelas repetíveis, frequentes. Quanto mais o
provedor de serviços puder reconhecer os padrões de atividade de negócio, melhor estará pre-
parado entregar serviços que realmente atendam as demandas dos clientes.
As atividades de negócio cobrem a utilização dos ativos do cliente (pessoas, processos e aplica-
ções) e as interações entre clientes, parceiros, fornecedores e outras partes interessadas.
Uma vez que um padrão de atividade de negócio tenha sido identificado, a ITIL® recomenda
que seja compreendido o seu perfil e devidamente documentado. Os seguintes itens devem ser
capturados:
 Classificação: indica o tipo de padrão de atividade de negócio e suas origens (usuário ou

automatizado), o tipo e impacto dos resultados que são suportados e a carga de trabalho as-
sociada.
 Requisitos: inclui desempenho, segurança, disponibilidade, privacidade e tolerância a atra-
sos (alguns desses poderiam ser classificados como considerações de garantia).
 Requisitos de Ativos de Serviço: utilizado pelas equipes de desenho para capturar e en-
tender o que é requerido para suportar um padrão de atividade de negócio específico, em
termos de recurso e capacidade.
Observe a imagem a seguir. Ela ilustra uma abordagem anual para o reconhecimento de pa-
drões. A empresa Meeting Card terá clientes comprando de acordo com os principais feriados
ou eventos.
Reconhecendo o impacto dessa atividade sobre o uso de sistemas de TI, o provedor de serviços
poderá oferecer capacidade suficiente para possibilitar ao negócio funcionar nesses picos.

5 Gestão de Risco
Apesar de todas as organizações gerenciar os seus riscos14, muitas vezes não é realizado de
maneira consistente e repetível. Dessa forma, o propósito de um gerenciamento formal de ris-
cos é possibilitar melhores decisões baseadas no compreendimento dos riscos e seus potenciais
impactos para se atingir os objetivos estratégicos.
Existem diferentes metodologias, padrões e frameworks que servem justamente para isso, en-
tre eles Management of Risk (M_o_R), ISO 31000, Risk IT e ISO/IEC 27001.
Na ITIL® são apresentadas algumas referências ao assunto, porém, não é coberta nenhuma
metodologia em especial. Ao contrário, o framework trata a questão em alto nível – cobrindo
apenas o básico que é necessário à um projeto ao implementar a abordagem de gerenciamento
de serviços de TI.
As seguintes atividades são propostas:
 Identificar os riscos: essa parte envolve identificar e nomear os riscos, mas não necessa-
riamente explicá-los ou quantificá-los. A questão é apenas identificar o que poderá impactar
o projeto ou a estratégia que está sendo levada em consideração. Cada um dos riscos identi-
ficados é, então, documentado (juntamente com suas potenciais consequências).
 Analisar os riscos: uma vez que o time já tenha identificado os riscos, poderão começar a
quantificar o impacto e a probabilidade de ocorrência dos mesmos. A maioria das aborda-
gens de gestão de riscos utilizam descrições qualitativas e quantitativas. Ou seja, as conse-
quências e os impactos são definidos em textos para que, em seguida, valores numéricos se-
jam também associados.
 Gerenciar os riscos: uma vez que os riscos já tenham sido documentados (juntamente
com os seus planos de ação), o plano de gestão de riscos deve ser revisado regularmente,
de forma a garantir que as ações apropriadas estejam sendo tomadas. Note que, os status
relacionados aos riscos poderão alterar-se durante o curso do projeto.
O gerenciamento de riscos é, na verdade, uma atividade repetitiva e deverá fazer parte da cul-
tura aceitável de qualquer programa ou iniciativa.
14
Risco é a incerteza de um determinado resultado (seja uma oportunidade positiva ou uma ameçada negativa).

Capítulo 03 – Desenho de
Iremos agora entrar em um
Serviço
importantíssimo tópico em
se tratando de ITIL®: o es- Objetivos do Capítulo
tágio Desenho de Serviço. É Ao final desse capítulo você deverá ser
um dos estágios mais co- capaz de:
brados no exame (seus con-
ceitos, processos, etc). Ao  Explicar e definir conceitos básicos rela-
contrário do estágio anteri- cionados ao gerenciamento de serviço
or, onde não estudamos ne- de TI relacionados ao Desenho de Ser-
viço.
nhum processo a fundo, dos  Entender os processos relacionados ao
8 processos que estudare- estágio em questão, cobrados no exa-
mos aqui, 1 deles será mais me ITIL® Foundation, edição 2011.
detalhado: Gerenciamento
do Nível de Serviço.
Sumário do Capítulo
Assim, tente estudar cada 1 Tópicos do Exame _______________ 37

processo com bastante a-
tenção e, especialmente: 2 O Desenho de Serviço ____________ 39
não tenha pressa. É um ca- 2.1 Conceitos importantes ___________ 40
pítulo longo e com bastante
3 Processos ______________________ 46
conceitos. Atente-se a eles,
releia o Syllabus para você 3.1 Gerenciamento de Nível de Serviço 46
poder “se encontrar” e veri- 3.2 Gerenciamento da Disponibilidade _ 53
ficar onde poderá investir
mais tempo de estudo, faça 3.3 Gerenciamento do Catálogo de Serviço
os exercícios, etc. Lembre- 57
se: esse estágio é crucial 3.4 Gerenciamento da Segurança da
para o seu sucesso no exame Informação _________________________ 59
ITIL® Foundation. 3.5 Gerenciamento de Fornecedor ____ 62
3.6 Coordenação do Desenho ________ 64
3.7 Gerenciamento da Continuidade de
Serviço de TI ________________________ 65
3.8 Gerenciamento da Capacidade ____ 67
Desejamos a todos bons es-

tudos.

1 Tópicos do Exame
 (ITIL®FND02) O ciclo de vida de serviço da ITIL®:
 (ITIL®FND02-5) ciência do propósito, objetivos e escopo do desenho de serviço.
 (ITIL®FND02-6) explicar qual o valor entregue pelo desenho de serviço ao negócio.
 (ITIL®FND03) Conceitos genéricos e definições básicas:
 (ITIL®FND03-4) catálogo de serviço.
 (ITIL®FND03-11) acordo de nível de serviço.
 (ITIL®FND03-12) acordo de nível operacional.
 (ITIL®FND03-13) contrato de apoio.
 (ITIL®FND03-14) pacote de desenho de serviço
 (ITIL®FND03-15) disponibilidade.
 (ITIL®FND04) Princípios chave e modelos
 entender a importância de pessoas, processos, produtos e parceiros para o gerencia-

(ITIL®FND04-3)
mento de serviço.
 (ITIL®FND04-4) entender os cincos principais aspectos do desenho de serviço.
 (ITIL®FND05) Processos:
 explicar o propósito, objetivos, escopo, conceitos básicos, atividades de processo e

(ITIL®FND05-3)
interfaces para:
o (ITIL®FND05-31) gerenciamento do nível de serviço
 (ITIL®FND05-4) declarar o propósito, objetivos e espoco para:
o (ITIL®FND05-41) gerenciamento do catálogo de serviço.
o (ITIL®FND05-42) gerenciamento da disponibilidade.
o (ITIL®FND05-43) gerenciamento da segurança da informação.
o (ITIL®FND05-44) gerenciamento de fornecedor.
o (ITIL®FND05-45) gerenciamento da capacidade.
o (ITIL®FND05-46) gerenciamento da continuidade de serviço de TI.
o (ITIL®FND05-47) coordenação de desenho.

 (ITIL®FND07) Papéis
 (ITIL®FND07-1) ciência do papel e das responsabilidades do:
o Dono do processo.
o Gerente do processo.
o Profissional de processo.
o Dono do serviço.
 reconhecer o modelo RACI de responsabilidade e explicar seu papel na determinação

(ITIL®FND07-2)
da estrutura organizacional.

2 O Desenho de Serviço
O estágio oferece um guia para o desenho de serviços de TI, para que os requisitos de negócio
atuais e futuros possam ser atendidos. Veremos que nesse estágio é introduzido o conceito de
Pacote de Desenho de Serviço, Acordos de Nível de Serviço, Acordos de Nível Operacional, etc.
Assim sendo, veremos nesse estágio os métodos, práticas e ferramentas para que se possa
alcançar a excelência no desenho de um serviço.
Propósito:
O propósito do estágio é desenhar os serviços de TI, governar as práticas de TI, processos e
políticas, para que se possa realizar a estratégia do provedor de serviços e facilitar a introdução
desses serviços em ambientes suportados. Ou seja, o estágio buscará entregar os resultados de
negócio requeridos. A preocupação aqui é grande: o estágio irá considerar o quê será requerido
pela fase de transição para que possa implementar o serviço em produção, como será o de-
sempenho do serviço, o que será necessário para suportá-lo, etc.
Objetivo:
Dentre os principais objetivos do estágio, estão:
 Desenhar serviços que satisfaçam aos objetivos de negócio e que estejam alinhados com as
necessidades do negócio;
 Desenhar serviços que possam ser facilmente e eficientemente desenvolvidos e melhorados,

dentro dos prazos e custos;
 Identificar e gerenciar os riscos dos serviços, para que possam ser eliminados ou mitigados
antes de entrarem em produção;
 Desenhar métodos de medição e métricas para avaliar a efetividade e eficiência dos proces-
sos de desenho e seus entregáveis;
 Produzir e manter planos de TI, processos, políticas, arquiteturas, frameworks e documentos

para o desenho de soluções de TI de qualidade - buscando atender as necessidades atuais e
futuras do negócio;

 Redução do Custo Total de Propriedade: o custo total de propriedade (metodologia usa-
da para tomar decisões sobre investimentos) somente poderá ser minimizado caso todos os
aspectos dos serviços, processos e tecnologia sejam desenhados de acordo e implementados
conforme o estabelecido.
 Melhora na qualidade e consistência do serviço: tanto o serviço quanto a qualidade o-
peracional serão melhoradas sendo os serviços bem desenhados. E, com isso, os serviços es-
tarão alinhados com a estratégia corporativa, arquitetura e restrições de negócio.
 Facilitação na Implementação de novos/alterados serviços: desenhos completos e
integrados dos serviços (além da produção dos pacotes de serviços15) irão facilitar bastante
a futura transição; sem contar que irão atender aos requisitos de nível de serviço16.
 Melhora na performance do serviço: a melhoria no desempenho do serviço somente será
conseguida se o serviço for desenhado para atender os critérios de desempenho especifica-
dos e, da mesma forma, se os planos de capacidade, disponibilidade, continuidade de serviço
de TI e financeiro forem reconhecidos e incorporados.
15
Dois ou mais serviços que foram combinados para oferecer uma solução a um tipo específico de necessidade dos
clientes ou sustentar resultados de negócio específicos.
16
Representam o que é necessário e indispensável em relação a um aspecto particular de um serviço.

2.1 Conceitos importantes
O pacote de desenho de serviço, saída chave do estágio, é um conjunto de documentos que são
produzidos durante todo o estágio e que descrevem todos os aspectos dos serviços, ou seja,
todas as informações necessárias que serão utilizadas para realizar a transição e operação do
serviço.
Por exemplo, constarão no PDS: requisitos de negócio acordados para o serviço, a forma de
utilização do serviço, informações dos contatos chave e/ou partes interessadas, desenho técni-
co, estratégia de terceirização, processos necessários para o suporte do serviço, critério de a-
ceitação, etc).
Para que o desenho de serviço seja efetuado com sucesso, deverão ser considerados os seguin-
tes 4 elementos chave (4Ps):
O elemento “Pessoas” foi incluso com destaque na imagem acima porque elas precisam estar
preparadas para utilizar/suportar os serviços. Além disso, os responsáveis pelo desenho de um
serviço deverão considerar a quantidade de pessoas necessárias para suportar o novo serviço
(aqui, Pessoas significa Recursos), como também quais habilidades elas deverão possuir (CA-
PACIDADE).
Outra questão a ser considerada é que hajam planos de comunicação, para garantir que a in-
formação correta seja dada às pessoas corretas no tempo certo (pelo método mais apropriado).
Isso porque? Para que as pessoas saibam/entendam o que precisa ser feito.
A ITIL® também deixa claro que, além dos processos descritos no framework, a organização
também poderá criar processos adicionais para serviços novos, como processo de autorização,
por exemplo.
O que importa é: todos os processos precisam ser documentados, além das interfaces que rea-
lizam com outros processos. É comum pensarmos que somente os serviços são considerados
produtos. Sim, os serviços são também produtos – mas não os únicos.
Tecnologia, as ferramentas escolhidas para auxiliar no desenho ou para suportar posteriormen-

te o serviço também são considerados produtos. É também essencial para o desenho de serviço
que exista bastante atenção na hora da escolha do fornecedor correto.
Assim sendo, “Parceiro” (geralmente são fornecedores especialistas – terceiros, vendedores,

etc) é um elemento muito importante a ser considerado no estágio.
O Desenho de Serviço deve adotar uma abordagem holística (global) ao desenvolver os servi-
ços. Desenvolver uma nova aplicação, por exemplo. Isso não poderá ser feito isoladamente – e
sim, considerar o impacto que ela exercerá no serviço como um todo.

Para que os processos que iremos estudar nesse capítulo possam ser efetivos, os seguintes 5
aspectos maiores deverão ser considerados:
 1º aspecto: Soluções para novos/alterados serviços: o primeiro aspecto é a própria

solução; ou seja, a nova funcionalidade oferecida pela aplicação ou outro serviço. Os requisi-
tos para tal já terão sido defninidos no portfólio de serviço. Assim sendo, é trabalho do está-
gio entregar soluções que atendam a tais requisitos. Além disso, as soluções deverão estar
de acordo com as regras corporativas e trabalhar com os serviços existentes.
 2º aspecto: Sistemas e Ferramentas de Gerenciamento da informação: essas são

usadas para suportar os processos, além de poder automatizá-los. Então, busca-se com esse
aspecto garantir que o novo/alterado serviço irá se integrar com os sistemas de gestão da
informação existentes (ex: o Sistema de Gerenciamento do Conhecimento de Serviço; que
manipula detalhes sobre o serviço dentro do portfólio de serviço e do catálogo de serviço).
 3º aspecto: Arquiteturas de tecnologia e Arquiteturas de gerenciamento: outro as-

pecto importantíssimo é que o novo/alterado serviço deverá ser compatível com os demais
sistemas existentes na organização. Já existirá uma plataforma arquitetural na organização,
como também padrões técnicos. Tudo isso precisará ser avaliado, para saber se esses con-
seguem suportar o novo serviço.
 4º aspecto: Métodos e métricas de medição: esse aspecto significa que o desenho de

um novo/alterado serviço precisa garantir que o que está sendo medido atende aos requisi-
tos. As métricas que estão sendo usadas devem ser suficientes para permitir que se avalie
adequadamente o serviço (em termos eficiência e efetividade).
 5º aspecto: Processos necessários: os novos/alterados serviços precisarão de processos

(específicos ou existentes). Tudo deverá ser considerado (processos, papéis, responsabilida-
des e habilidades) ao desenhar um serviço. Se os processos existentes não suportarem os
serviços que estão sendo desenhados, eles deverão ser melhorados. Caso os processos exis-
tentes não puderem ser melhorados, os serviços precisarão ser alterados.
Com relação a organização do departamento de TI dentro das organiza-

ções, a ITIL® deixa claro que isso fica por conta da própria organização. É
importante termos em mente que uma pessoa poderá possuir diversos
papéis. Por exemplo, uma pessoa poderia ser responsável pelo Gerencia-
mento da Disponibilidade e, ao mesmo tempo, também ser responsável
pelo Gerenciamento da Capacidade.
É importante destacar que, embora os papéis possam ser compartilhados (ou combinados),
somente poderá haver 1 dono do processo para cada um dos processos, além de 1 dono do
serviço para cada serviço.
Todos os processos possuem os seus próprios papéis específicos. Entretanto, iremos estudar
agora os considerados “papéis genéricos” que aparecem em todos os estágios do ciclo de vida
do serviço.

Dono do Serviço
Devido aos serviços interagir com muitos processos, há o perigo dos mesmos não receberem a
devida atenção. Para evitar isso, a ITIL® recomenda que cada serviço possua um único dono.
Com isso, sempre haverá aquele que responderá pelo serviço e garantirá que haja foco nos
processos de negócio que o serviço suporta.
Além de ser responsável pelo serviço que está sendo desenvolvido, implementado e mantido,
ele (a) também prestará contas ao diretor de TI ou diretor de gerenciamento de serviço pela
sua entrega.

Dono do Processo
O dono do processo é aquele que prestará conta sobre 1 único processo. Ou seja, ele deve ga-
rantir que o processo funcione de maneira eficiente e efetivamente. Esse papel é essencial para
o sucesso de um processo, já que com a ausência do mesmo, não haverá ninguém com a res-
ponsabilidade de garantir a consistência em aplicar o processo (além de garantir que sua saída
ainda vá de encontro com os objetivos do negócio).
Gerente do Processo
O dono do processo é o prestador de contas pelo sucesso de um processo, mas poderá não ser
o executor do mesmo. A responsabilidade de gerenciamento da implementação do processo no
dia a dia pertence ao gerente do processo.

Praticante do Processo
Dependendo do processo, poderá haver uma ou mais pessoas executando as atividades do pro-
cesso. Todas as pessoas envolvidas na execução das atividades do processo são chamadas de
praticantes do processo.
Com tantos processos dentro das organizações e diversos papéis dentro de cada um, é muito
importante que tais papéis sejam claramente definidos para cada processo individual. É tam-
bém essencial que exista um acordo sobre as responsabilidades e prestações de conta para
tarefa do processo.
É um Fator Crítico de Sucesso17 para processos efetivos que a responsabilidade e prestação de

conta estejam claramente definidos. As boas práticas na área sugerem o mapeamento das tare-
fas para os cargos/funções e a definição do nível de envolvimento na tarefa que cada car-
go/função terá. A matriz (ou modelo) RACI é geralmente usada para mostrar os papéis e res-
ponsabilidades para as atividades e processos. Vejamos o que representa o acrônimo em ques-
tão:
 Responsible (Responsável): aqueles que “realizam o trabalho”, ou seja, executa a tarefa.

Deverá haver ao menos 1 pessoa responsável para cada tarefa.
 Accountable (Cobrado): é aquele quem responde pela atividade ou processo; aquele que
será cobrado pelo bom andamento da atividade ou processo. Para evitar qualquer tipo de
confusão, deverá haver somente um accountable para cada tarefa.
 Consulted (Consultado): quando apropriado para o processo, poderão haver pessoas que
são consultadas com o intuito de conhecer suas opiniões em relação a uma atividade do pro-
cesso. São pessoas que oferecem informações. Não é mandatório, como os dois anteriores.
 Informed (Informado): essas pessoas são atualizadas conforme o progresso da atividade.

Da mesma forma que o anterior, não é mandatório; dependerá da atividade em questão.
17
FCS é um termo para um elemento que é necessário para que uma organização ou projeto consiga atingir a sua
missão.

Veja na figura a seguir uma simples matriz RACI:
É importante destacar que os papéis e atividades são coordenados pelos gerentes de processo.
Embora algumas vezes seja muito trabalhoso a elaboração de uma matriz RACI, as vantagens
trazidas ao negócio são recompensadoras. Há duas outras grandes vantagens na utilização da
mesma:
1) Geralmente todos os Rs na matriz representam oportunidades potenciais para acordos de

níveis operacionais;
2) Identificando os papéis que devem ser mantidos informados, auxilia (e muito) em expor os
caminhos de comunicação e fluxo de trabalho.
Entretanto, a matriz RACI também apresenta alguns potenciais problemas, entre eles:
 Ter mais de uma pessoa cobrada para um processo significa que, na prática, ninguém é co-
brado;
 Delegação de responsabilidade ou prestação de contas sem a autoridade necessária;
 Incorreta divisão/combinação de funções; conflitando agendas ou objetivos;

3 Processos
3.1 Gerenciamento de Nível de Serviço
Propósito:
O Gerenciamento do Nível de Serviço é um processo vital para todo e qualquer provedor de
serviços de TI, já que é responsável por acordar e documentar as metas de nível de serviço e
responsabilidades dentro dos acordos de nível de serviço e Requisitos de Nível de Serviço para
todos os serviços e atividades relacionadas dentro da TI.
Se as metas são apropriadas e refletem precisamente os requisitos do negócio, o serviço entre-

gue estará alinhado com os requisitos de negócio e atenderá as expectativas dos clientes e u-
suários, em termos de qualidade do serviço. O acordo de nível de serviço é, efetivamente, um
nível de garantia em relação ao nível de qualidade de serviço presentes em cada um dos servi-
ços entregues.
O sucesso do processo é bastante dependente da qualidade do Portfólio de Serviço e do Catálo-

go de Serviço, já que oferecem as informações necessárias sobre os serviços a serem gerencia-
dos dentro do processo.
Esse visa garantir que todos os serviços de TI atuais e planejados sejam entregues de acordo
com as metas acordadas. Isso é realizado através de um constante ciclo de negociações, acor-
dos, monitoramentos, reportes e revisões das metas e resultados dos serviços de TI, como
também através de ações para corrigir ou melhorar o nível de serviço entregue.
Objetivos:
 Definir, documentar, acordar, monitorar, medir, reportar e revisar o nível dos serviços de TI
oferecidos e instigar medidas corretivas quando necessário;
 Oferecer e melhorar o relacionamento e comunicação com o negócio e clientes, em conjunto

com o Gerenciamento de Relacionamento de Negócio;
 Garantir o desenvolvimento de metas específicas e mensuráveis para todos os serviços de

TI;
 Monitorar e melhorar a satisfação do cliente com a qualidade do serviço entregue;
 Garantir que a TI e os clientes possuam uma clara expectativa do nível de serviço a ser en-
tregue;
 Garantir que os níveis de serviço estejam sujeitos a melhorias contínuas proativas e custo-
efetivas (mesmo quando conseguem atingir todas as metas acordadas).
Escopo:
O processo oferece um ponto de contato e de comunicação regular com os clientes e gerentes
de negócio de uma organização em relação aos níveis de serviço. Nesse contexto, ele deve re-
presentar o provedor de serviços de TI para o negócio e vice-versa.
O processo precisa gerenciar a expectativa e percepção do negócio, dos clientes e usuários;

além disso, buscará garantir que a qualidade (garantia) do serviço entregue consiga alcançar as
expectativas e necessidades. Para conseguir isso, o processo deve estabelecer e manter os a-
cordos de nível de serviço para todos os serviços atuais e gerenciar o nível de serviço oferecido
para atender as metas e medidas de qualidade contidas nos acordos de nível de serviço.

Além disso, o processo também deve produzir e acordar os requisitos de nível de serviço para
todos os novos ou alterados serviços, que documentem os requisitos de garantia.
O processo deve incluir:
 Cooperação com o processo gerenciamento de relacionamento de negócio, ou seja, inclui o

desenvolvimento de relacionamentos com o negócio necessários para atingir os objetivos do
processo de gerenciamento do nível de serviço;
 Negociação e acordo para os requisitos e metas futuras de nível de serviço, além da docu-
mentação e gerenciamento dos requisitos de nível de serviço para todos os serviços (novos
ou alterados);
 Negociação e acordo para os requisitos e metas de nível de serviço atuais, além da docu-
mentação e gerenciamento dos acordos de nível de serviço para todos os serviços operacio-
nais;
 Desenvolvimento e gerenciamento de Acordos de Nível Operacionais para garantir que as

metas estejam alinhadas com as metas de acordos de nível de serviço;
 Revisar todos os acordos com fornecedores e contratos de apoio com o Gerenciamento de

Fornecedor, para garantir que as metas sejam alinhadas com as metas de acordos de nível
de serviço;
 Prevenção proativa de falhas nos serviços, redução dos riscos de serviço e melhoria na qua-
lidade dos mesmos, em conjunto com todos os outros processos;
 Reportar e gerenciar todos os níveis de serviços atingidos e revisar todas as violações de

acordos de nível de serviço;
 Revisão periódica, renovação e/ou revisão dos acordos de nível de serviço, escopo de serviço
e acordos de nível de serviço, conforme apropriado;
 Identificar oportunidades de melhorias para a inclusão no registro de Melhoria Contínua de

Serviço;
 Revisar e priorizar melhorias no registro de Melhoria Contínua de Serviço;
 Instigar e coordenar os Planos de Melhoria de Serviços para o gerenciamento, planejamento

e implementação das melhorias de serviço e de processo.
O Acordo de Nível de Serviço é um documento (ou conjunto de documentos) que descreve o

serviço e as medidas de qualidade nos quais a entrega do serviço será baseada. No mesmo
deverá estar bem definido sobre o quê será oferecido ou não, as responsabilidades do provedor
de serviço e dos clientes. Lembre-se: o acordo de nível de serviço é um contrato FORMAL com o
cliente (contendo assinaturas, inclusive).
Nos Acordos de Nível de Serviço estarão também descritos os métodos para calcular os níveis
de prioridade para os incidentes e as metas de tempo para resolução dos mesmos. Para que
possa ser assumido um compromisso no acordo de nível de serviço, o gerente de nível de servi-
ço deve estar ciente de que cada parte do serviço será entregue segundo o padrão requerido.
Para isso, deve-se garantir que existam acordos com equipes internas, além de contratos com
terceiros (caso seja necessário), para que todos esses aspectos do serviço possam ser atendi-
dos.

Vamos agora estudar os Acordos de nível operacional. Algumas vezes o provedor de serviços
precisará de serviços prestados por outras partes da organização, para que o serviço possa ser
entregue apropriadamente ao cliente. Ou seja, nem sempre irão precisar de terceiros. Os A A-
cordos de nível operacional são realizados entre um provedor de serviços de TI e outra parte da
mesma organização, que será responsável por apoiar a entrega do todo ou parte do serviço de
TI que é vendido a um cliente externo. As boas práticas recomendam que os Acordos de nível
operacional sejam revisados, ao menos, uma vez por ano – de forma a manter-se sempre atua-
lizado.
Outro contrato muito importante é o Contrato de Apoio. Esses acordos são aqueles realizados
com organizações externas que oferecem elementos para o serviço como um todo. Devido aos
fornecedores serem externos, tais acordos serão contratuais (responsabilidade legal). Exemplos
muito comuns de fornecedores terceiros são os Provedores de Internet, mantenedores de
hardware e software, etc. Lembre-se: todo compromisso presente no Acordo de Nível de Servi-
ço deve ser suportado por um acordo de apoio (Acordo de Nível Operacional ou Contrato de
Apoio).
Outra importante decisão que é tomada durante a fase de planejamento para a implementação
do gerenciamento de nível de serviço é sobre a estrutura de acordo de nível de serviço mais
apropriada para a organização. A ITIL® estabelece três opções: baseada no cliente, baseada no
serviço e multinível:
 O acordo de nível de serviço baseado em serviço é aquele em que cada acordo de nível de
serviço refere-se a somente 1 serviço. O serviço descrito é oferecido para todos os usuários
do mesmo, logo, os requisitos para todos os grupos de clientes deverão ser apurados. Essa
opção é útil para grandes serviços de uma organização, como serviços de email. Como des-
vantagem, podemos citar que o serviço oferecido por todas as localizações pode não ser de
igual qualidade, devido a problemas de rede, por exemplo.

 Outra opção é ter um acordo cobrindo todos os serviços oferecidos para um único cliente ou
grupo de clientes. Esse é o acordo de nível de serviço baseado em cliente. Por exemplo, o
departamento de recursos humanos poderia ter um acordo de nível de serviço baseado em
cliente, como também o departamento financeiro, etc. Isso é bastante conveniente para o
cliente, já que todos os serviços que utiliza estarão em um único acordo. Para a TI, tais a-
cordos significam que o mesmo serviço poderá aparecer em muitos acordos de nível de ser-
viço, o que resulta em dificuldade de monitoramento.
A terceira opção é o acordo de nível de serviço multinível, composta de três níveis:
 Nível corporativo – cobre todas as questões genéricas do 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 do cliente – cobre todas as questões relevantes para um grupo de clientes ou unida-
des de negócio, independentes do serviço que está sendo usado.
 Nível do serviço – cobre todas as questões relevantes para um serviço especifico em rela-
ção a um grupo de clientes específicos (um para cada serviço coberto pelo acordo de nível de
serviço).

Uma vez que o Catálogo de Serviço tenha sido produzido e a estrutura definida, os primeiros
requisitos de nível de serviço deverão ser rascunhados. Um requisitos de nível de serviço é um
requisito do cliente para um aspecto de um serviço de TI. Eles são baseados nos objetivos de
negócio e são usados para negociar as metas de nível de serviço.
O requisito de nível de serviço está intimamente relacionado à garantia do serviço: quais níveis
de serviço são requeridos pelo cliente para que eles possam receber o valor da utilidade do ser-
viço? O quão disponível deverá estar um serviço? O quão seguro?
É importante deixar claro a diferença entre requisito de nível de serviço e as metas de nível de
serviço específicas e associadas ao cumprimento de um requisito de nível de serviço.
Por exemplo, um requisito de nível de serviço relacionado a desempenho pode ser expresso
pelo cliente como aquele serviço “rápido o bastante para suportar o volume antecipado de pe-
didos em períodos de pico”.
Já a meta de nível de serviço a esse requisito definirá os tempos de respostas específicos e

mensuráveis, além das condições sobre as quais a meta será considerada como tendo sido vio-
lada.
Quando o acordo de nível de serviço é acordado e aceito, o monitoramento deverá ser instigado
e os relatos do aproveitamento do serviço também deverá também ser produzido. Os relatos
operacionais devem ser efetuados com frequência e, quando possível, relatos de exceção deve-
rão também ser produzidos, não importando se o acordo de nível de serviço tenha sido quebra-
do.
Algumas vezes dificuldades são encontradas no atendimento as metas dos novos serviços du-
rante o período inicial de suporte, devido ao alto volume de Requisições de Mudança. Os meca-
nismos de reporte dos acordos de nível de serviço, intervalos e formatos deverão ser também
acordados com os clientes.
Os relatos periódicos devem conter detalhes do desempenho obtido em relação às metas do

ANS, junto a detalhes sobre quaisquer tendências ou ações específicas que estão sendo toma-
das para melhorar a qualidade do serviço.
Uma técnica muito útil é incluir um gráfico do monitoramento do acordo de nível de serviço na
frente do relato de serviço. O gerenciamento de nível de serviço deverá identificar as necessi-
dades de reportes necessárias e tentar automatizar a sua produção. A figura a seguir ilustra os
resultados dos 6 serviços em um período de 8 meses:

O gerente de nível de serviço deve regularmente se encontrar com os diversos clientes para
revisar a entrega contra o acordo de nível de serviço (1 vez por mês, se possível). Trata-se de
uma ótima oportunidade de construir um relacionamento mais forte e aumentar o compreendi-
mento uns sobre os outros.
Esses encontros regulares irão garantir que, tanto o sucesso quanto as falhas, sejam discutidas
e que os problemas que poderiam ser destrutíveis ao relacionamento sejam devidamente resol-
vidos. Questões que poderiam estar em uma agenda padrão:
 Revisão das atas e ações anteriores;
 Revisão de quaisquer incidentes maiores desde o último encontro;
 Revisão dos reports de serviço do mês anterior e dos últimos 12 meses;
 Discussão sobre quaisquer problemas que poderão surgir dos reports e alocação das ações;
 Revisão do progresso do Plano de Melhoria de Serviço contra as metas acordadas;
 Discussão sobre os desenvolvimentos de negócio futuros;
 Notificação sobre quaisquer mudanças de TI que poderão afetar o serviço a ser entregue.
Quando as melhorias que foram discutidas na revisão de serviço precisar de várias ações que
deverão ser realizadas por diferentes pessoas ou grupos, deverá ser elaborado um plano de
melhoria de serviço (pelo gerente de nível de serviço).
Esse plano deve ser acordado na revisão de serviço. Nele estarão acordados prazos e resulta-
dos desejados. As ações serão alocadas e o progresso será checado. Quando completado, os
resultados do plano de melhoria de serviço serão revisados para ver se o plano foi realizado
com sucesso ou se novas ações serão requeridas.
Vejamos abaixo alguns relacionamentos existentes entre o Gerenciamento de Nível de Serviço e

demais processos do ciclo de vida do serviço:
 Gerenciamento de Relacionamento de Negócio: esse processo garante que o provedor

de serviço possua um completo compreendimento das necessidades e prioridades do negócio
e que os clientes estejam apropriadamente envolvidos/representados no trabalho do geren-
ciamento de nível de serviço;
 Gerenciamento do Catálogo de Serviço: esse processo oferece informações precisas so-

bre os serviços e suas interfaces/dependências para suportar na determinação do acordo de
nível de serviço, identificando clientes/unidades de negócio que precisam ser engajadas pelo
gerenciamento de nível de serviço; e auxiliar o gerenciamento de nível de serviço na comu-
nicação com os clientes em relação aos serviços oferecidos;
 Gerenciamento de Incidente: o processo oferece dados críticos para o Gerenciamento de

Nível de Serviço, de forma a comparar o desempenho obtido com as metas dos Acordos de
Nível de Serviço; além de também operar com o preenchimento das metas do Acordo de Ní-
vel de Serviço, como Fatores Críticos de Sucesso. O Gerenciamento de Nível de Serviço ne-
gocia metas relacionadas a suporte e, em seguida, o cumprimento dessas metas é embutido
na operação do processo Gerenciamento de Incidente;

 Gerenciamento de Fornecedor: esse processo trabalha colaborativamente com o Gerenci-

amento de Nível de Serviço para definir, negociar, documentar e acordar os termos de servi-
ço com os fornecedores, para suportar o atingimento dos comprometimentos feitos pelo pro-
vedor de serviços nos Acordos de Nível de Serviço. O Gerenciamento de Fornecedor também
gerencia o desempenho dos fornecedores e contratos contra os termos de serviço para ga-
rantir que as metas dos Acordos de Nível de Serviço relacionados estejam sendo cumpridas;
 Gerenciamento da Segurança da Informação, Disponibilidade, Capacidade e Conti-

nuidade de Serviços de TI: esses processos contribuem para o Gerenciamento de Nível de
Serviço ajudando a definir as metas que se relacionam com suas áreas de responsabilidade;
além de verificar se essas metas são realmente realistas;
 Gerenciamento Financeiro para Serviços de TI: esse processo trabalha com o Gerenci-
amento de Nível de Serviço para validar o custo predito para entregar os níveis de serviço
requeridos pelo cliente, de forma a garantir que os custos sejam comparados com os predi-
tos;
 Coordenação de Desenho: durante esse estágio, o processo é responsável por garantir

que as atividades gerais de desenho sejam completadas com sucesso. O Gerenciamento de
Nível de Serviço possui um papel crucial nisso, através do desenvolvimento de Requisitos de
Nível de Serviço acordados e as metas de serviço associadas que os serviços novos ou alte-
rados devem ser desenhados para atingir.
As atividades chave dentro do processo são:
1 – Desenvolver contatos e relacionamentos

2 – Desenhar o framework do Acordo de Nível de Serviço
3 – Determinar, documentar e acordar os requisitos para os novos serviços
4 – Negociar e desenvolver os Acordos de Nível de Serviço
5 – Revisar os Acordos de Nível de Serviço, Contratos de Apoio, Acordos de Nível Operacional e
o escopo do serviço
6 – Monitorar o desempenho do serviço em comparação com o Acordo de Nível de Serviço
7 – Produzir relatórios sobre os serviços
8 – Conduzir revisões de serviço e propor melhorias dentro do Plano de Melhoria de Serviço18
geral
9 – Coletar, medir e melhorar a satisfação dos clientes
10 – Gerenciar as queixas e os elogios (parceria com o processo Gerenciamento de Relaciona-
mento de Negócio)
18
Planos formais que implementam melhorias em processos ou serviços.

3.2 Gerenciamento da Disponibilidade
Propósito:
O propósito do estágio é tomar as ações necessárias para entregar os requisitos de disponibili-
dade definidos em acordo de nível de serviço. Assim, o processo deve considerar tanto os re-
quisitos atuais quanto as necessidades futuras do negócio.
O estágio considera todos os aspectos da provisão de serviços de TI para identificar possíveis

melhorias à disponibilidade (claro, sempre se atentando em ser custo-efetivas). Conclui-se que
o estágio analisa as razões do downtime e avalia o ROI sobre as melhorias propostas.
Quando falamos em garantia de um serviço, a disponibilidade é, sem dúvidas, a primeira coisa

a ser pensada. Não importa a funcionalidade (utilidade) que um serviço ofereça: se não estiver
disponível, o negócio não perceberá o valor que o provedor de serviços prometera.
A ITIL® define “disponibilidade” como sendo a habilidade de um serviço de TI (ou qualquer

item de configuração) em desempenhar a sua função acordada quando necessário. Qualquer
interrupção no serviço durante o período de tempo estabelecido é considerada como downtime.
Por exemplo, imagine que um serviço esteja disponível 24 horas por dia, 7 dias por semana.
Se houver 1 hora de downtime por semana, veja como ficará o cálculo de sua disponibilidade:
168 horas – 1 = 167 / 168 * 100 = 99.4%
Fica claro que o foco do processo é reduzir ao máximo o tempo de downtime dos serviços. O
propósito do processo é garantir que os níveis de disponibilidade dos serviços de TI sejam sem-
pre atendidos, ou seja, vá de encontro às necessidades de disponibilidade acordadas/metas de
nível de serviço (dentro do orçamento e em tempo).
Assim sendo, o processo irá seguir todos os passos para entregar os requisitos (atuais e futu-
ros) de disponibilidade, definidos no acordo de nível de serviço. Para identificar possíveis me-
lhorias na disponibilidade dos serviços, o processo considerará todos os aspectos da provisão
dos serviços de TI.
Escopo:
O escopo do processo cobre o desenho, implementação, medição, gerenciamento e melhoria do
serviço de TI e da disponibilidade de componentes. Ao se definir claramente os requisitos de
disponibilidade para um serviço, o processo já é imediatamente iniciado. Além disso, é um pro-
cesso contínuo – somente é finalizado quando o serviço é descontinuado ou aposentado. O pro-
cesso inclui dois elementos chave: atividades reativas e proativas.
As atividades reativas são aquelas que envolvem o monitoramento, medição, análise e gerenci-
amento de todos os eventos, incidentes e problemas relacionados à não disponibilidade – ou
seja, tornar o serviço ainda mais robusto. Já as atividades proativas envolvem o planejamento,
desenho e melhoria da disponibilidade – ou seja, redução do downtime. São geralmente execu-
tadas por papéis de desenho e planejamento.

A figura a seguir ilustra muito bem o processo (repare a presença do Sistema de Gerenciamen-
to da Disponibilidade, parte integrante do Sistema de Gerenciamento do Conhecimento de Ser-
viço):
Objetivos:
 Produzir e manter o plano de disponibilidade e garantir que esse seja apropriado e atualiza-
do, de maneira a refletir as necessidades correntes e futuras do negócio (o plano deverá
considerar requisitos dos próximos 12 a 24 meses);
 Oferecer informações para outras áreas do negócio e da própria TI, em relação a todos os
problemas relacionados a disponibilidade;
 Garantir que a disponibilidade do serviço atenda todas as metas acordas, através do geren-
ciamento dos serviços e do desempenho dos recursos, relacionados a disponibilidade;
 Oferecer auxílio, através de diagnósticos, à problemas e incidentes relacionados a disponibi-

lidade;
 Garantir que medidas proativas sejam implementadas para melhorar a disponibilidade dos
serviços, contanto que o custo seja justificável.
Todos os serviços em operação e tecnologias fazem parte do escopo do processo. Onde há a-

cordos de nível de serviço, há metas que foram acordadas. E, onde há metas, haverão questões
relacionadas à disponibilidade.
Os serviços de suporte também não ficam de fora dos “olhos” do processo, já que ocorrendo
falhas nos mesmos, poderá impactar da mesma forma os serviços oferecidos aos clientes – por
isso, o processo também poderá trabalhar em conjunto com o Gerenciamento de Fornecedor.
Tudo que possui contribuição para o aumento de downtime (processos ruins, equipe não treina-
da, ferramentas não efetivas, etc.) será preocupação do processo.

O processo requer compreendimento sólido a respeitos dos componentes individuais que com-
põem os serviços, além de suas capacidades e desempenho atual. Ao desenhar um novo servi-
ço, quando o assunto sobre os requisitos de disponibilidade vier à tona, ambos, provedores de
serviços e o negócio, precisam focar-se no quão crítico é o serviço para que o cliente atinja os
seus objetivos.
O processo de negócio que o serviço de TI suporta pode ser uma Função Função Vital de Negó-
cio19; dessa forma, identificar os serviços (ou partes do mesmo) que são os mais críticos é uma
decisão tomada pelo negócio.
Quem irá decidir sobre qual seria a meta apropriada de disponibilidade para um
serviço é o NEGÓCIO – e não a TI. Entretanto, cabe a TI garantir que o cliente
entenda os custos implicados com uma meta muito alta.
O processo admite conceitos importantes. O primeiro deles é a própria Disponiblidade, medida

em porcentagem. Vejamos a fórmula de cálculo:
Disponibilidade (%) = Tempo Acordado de Serviço – downtime ÷ Tempo Acordado de Servi-

ço x 100
Outro aspecto é a Confiabilidade, definida pela ITIL® como sendo o tempo que um serviço,
componente ou IC consegue realizar suas funcionalidades acordas sem que hajam interrupções.
A medição da confiabilidade é obtida através do Tempo Médio Entre Falhas (TMEF) ou Tempo
Médio Entre Incidentes de Serviço (TMEIS).
Confiabilidade (TMEF em horas) = Tempo disponível em horas – Tempo de

downtime em horas ÷ número de paradas.
Confiabilidade (TMEIS em horas) = Tempo disponível em horas ÷ número de pa-

radas
Quando uma falha ocorre e não há resilênica suficiente no serviço para prevenir o downtime,
entre em cena outro aspecto importantíssimo – a Mantenibilidade – medida através do Tem-
po Médio de Restauração de um Serviço (TMRS). Ou seja, o quão rápido um serviço, compo-
nente ou IC consegue voltar a sua operação normal após uma falha.
Mantenibilidade (TMRS em horas) = Tempo de downtime em horas ÷ Número de paradas do ser-

viço.
A ITIL® recomenda a utilização do TMRS ao invés do Tempo Médio Para Reparo (TMPR), já que
esse poderá incluir ou não a restauração do serviço a seguir do reparo efetuado.
19
A Função Vital de Negócio é um termo usado para refletir a parte de um processo de negócio que seja crítica para o
sucesso do negócio.

Vamos exemplificar esses aspectos da seguinte forma: Imagine uma situação onde um serviço
24x7 rodou por um período de 5,020 horas com somente duas paradas, a primeira de 6 horas e
a segunda de 14 horas. Vamos observar os cálculos:
Disponibilidade = (5,020 – (6+14)) ÷ 5,020 x 100 = 99.60%

Confiabilidade (TMEIS) = 5,020 ÷ 2 = 2,510 horas
Confiabilidade (TMEF) = 5,020 – (6 + 14) / 2 = 2,500 horas
Mantenibilidade (TMRS) = (6+14) ÷ 2 = 10 horas
A Facilidade de manutenção é definida como a habilidade de um fornecedor terceiro em a-

tender o que fora estabelecido em contratos, que incluem níveis acordados de disponibilidade,
confiabilidade e/ou mantenibilidade para os serviços de suporte ou componentes que os mes-
mos oferecem.
Observe a imagem a seguir de forma a ficar bem claro o que estudamos sobre os aspectos a
serem considerados para o Desenho de Serviço:
Importante destacar: não podemos confundir Disponibilidade de Serviço com Disponibilidade

de Componente. Enquanto este último envolve todos os aspectos da disponibilidade e indispo-
nibilidade do componente, a disponibilidade de serviço envolve todos os aspectos da disponibili-
dade e indisponibilidade do serviço, além do impacto da disponibilidade do componente ou po-
tencial impacto da indisponibilidade do componente sobre a disponibilidade geral do serviço.

3.3 Gerenciamento do Catálogo de Serviço
Propósito:
O propósito do processo Gerenciamento do Catálogo de Serviço é oferecer e manter uma única
fonte de informações consistentes sobre todos os serviços operacionais, como também aqueles
que estão sendo preparados para rodarem. Além disso, garantir que estejam prontamente dis-
poníveis para aqueles autorizados a acessá-los. O catálogo de serviço incluirá serviços que
também estão sendo desenvolvidos ou melhorados para a transição futura em ambiente de
produção.
O catálogo de serviço será utilizado pelos clientes e pela TI, como também para a base para o
Gerenciamento de Nível de Serviço. Identificar e documentar todos os serviços oferecidos, jun-
tamente com seus serviços de suporte, são tarefas muito complexas, mas as vantagens que
isso oferece fazem valer a pena.
O catálogo de serviço é definido na ITIL® como sendo “um banco de dados ou documento es-
truturado com informações sobre todos os serviços de TI em produção, incluindo aqueles dis-
poníveis para implantação.
O catálogo de serviço é parte do Portfólio de Serviço e contém informações sobre dois tipos de
serviços de TI: serviços voltados para o cliente (visíveis ao negócio) e serviços de suporte (ne-
cessários para que provedor de serviços consiga entregar os serviços voltados para o cliente).
Vamos examinar mais detalhadamente essa definição:
“Um banco de dados ou documento estruturado”: o catálogo reúne informações de servi-

ços e apresenta-as de forma a se tornarem de fácil compreendimento ao negócio.
Informações sobre todos os serviços de TI em produção, incluindo aqueles disponí-

veis para implantação: o catálogo contém detalhes dos serviços que estão disponíveis ao
negócio; dessa forma, o catálogo de serviço se difere dos outros componentes do Portfólio de
Serviços (lembrando: funil de serviço e serviços aposentados). Reunir e manter a informação é
trabalho do Gerenciamento do Catálogo de Serviço.
Informações sobre dois tipos de serviços de TI: o catálogo oferece os detalhes que os cli-
entes requerem sobre a disponibilidade do serviço, ou seja, os entregáveis, preços, pontos de
contato e processos de requisição. Existe uma outra visão do catálogo de serviço – aquela que
é visível somente para a TI, mostrando os serviços de suporte que devem estar prontos para
que os serviços dos clientes sejam entregues.
A estrutura do catálogo de serviço deve considerar as diferentes necessidades de diferentes

pessoas, já que nem todo serviço e informações sobre os serviços é do interesse de todos. De-
pendendo da natureza do negócio, o provedor de serviços poderá ter clientes internos e exter-
nos e diferentes tipos de clientes, com serviços diferentes disponíveis para cada um.

A figura abaixo ilustra um catálogo de serviço de “duas visões” – representando as visões do

cliente (contendo os serviços visíveis ao mesmo) e a visão técnica (contendo os serviços de
suporte aos serviços principais).
Na figura a seguir é ilustrada outra possibilidade para a representação de um catálogo de servi-

ço – desta vez, conhecido como “três visões”:
Note que, agora, os serviços foram “divididos” em serviços para o atacado e serviços para o
varejo. A forma que a organização estruturará o catálogo de serviço irá variar de uma para ou-
tra. Para o exame, lembre-se que poderão conter as essas visões que foram demonstradas.
Escopo:
O escopo do processo inclui todos os serviços que estão sendo transicionados (ou que já te-
nham sido) para o ambiente de produção, além a elaboração e manutenção dos pacotes de ser-
viço.
Um pacote de serviço é a combinação de dois ou mais serviços de forma a ofere-

cer uma solução específica a determinados clientes. Poderá consistir da combina-
ção de serviços principais, serviços de apoio e serviços intensificadores. Também
faz parte do escopo a definição desses serviços ou pacotes de serviços e as des-
crições a serem usadas para eles dentro do catálogo.

Objetivos:
O processo possui como objetivo a produção e manutenção do catálogo de serviço. A informa-
ção contida dentro do catálogo de serviço deve ser precisa. Na medida em que a transição mo-
ve serviços para o ambiente de produção ou aposenta outros serviços, o catálogo de serviço
deverá ser atualizado para refletir tais mudanças. Para que a consistência seja garantida, a
descrição do serviço deve permanecer a mesma, na medida em que o serviço progride através
do portfólio, para evitar quaisquer confusões.
Outro objetivo do processo é garantir que a informação dentro do catálogo de serviço esteja
disponível em um formato adequado para quem precisar. Poderá até mesmo ser um documento
no Microsoft Word, uma planilha eletrônica ou, até mesmo, em uma Intranet. Não importa,
contanto que as necessidades dos usuários e clientes sejam consideradas.
3.4 Gerenciamento da Segurança da Informação
Propósito:
O propósito do processo é alinhar a segurança da TI com a segurança do negócio e garantir que
a confidencialidade, integridade e disponibilidade dos ativos da organização, informação, dados
e serviços de TI sempre atendam às necessidades acordadas.
A segurança é um dos aspectos chave da Garantia de um serviço, já que, um serviço inseguro

não entragará o valor que o cliente espera (aliás, poderá nem mesmo ser usado). A ITIL® defi-
ne a segurança da informação20 como sendo o processo de gerenciamento localizado no frame-
work da governança corporativa, responsável por oferecer a direção estratégica para as ativi-
dades de segurança e garantir que os objetivos sejam atingidos.
Escopo:
O processo deverá ser o ponto focal para todos os problemas de segurança da TI e, além disso,
garantir que uma política de segurança da informação seja produzida e mantida. Essa deve co-
brir detalhes a respeito da utilização dos sistemas e serviços de TI.
Entendendo totalmente o ambiente de segurança da TI e do negócio (como políticas e planos

de segurança, do negócio, operação de negócio atual e requisitos de segurança, requisitos re-
gulatórios, planos e requisitos futuros, etc), possibilitará ao processo garantir que todos os as-
pectos (atuais e futuros) de segurança e riscos do negócio sejam gerenciados de maneira cus-
to-efetiva.
O processo deve também:
 Implementar um conjunto de controles de segurança que suportem a política de segurança

da informação e gerencie os riscos associados ao acesso aos serviços, informações e siste-
mas;
 Documentar todos os controles de segurança e (proativamente) melhorá-los, junto com a
operação e manutenção dos controles e riscos associados aos mesmos. O foco é reduzir ao
máximo os riscos de segurança;
 Gerenciar os fornecedores e contratos em relação ao acesso aos sistemas e serviços, junto
com o Gerenciamento de Fornecedor.
20
Informação inclui armazenamentos de dados, bancos de dados e metadados (conjunto de dados que descrevem ou
fornece informações sobre outros dados).

Objetivos:
O objetivo do processo é proteger os interesses daqueles que devem confiar nas informações, e
fazer com que os sistemas e qualquer tipo de comunicação responsáveis por entregar as infor-
mações não sofram com falhas relacionadas a confidencialidade, integridade e disponibilidade.
Dessa forma, o processo buscará garantir a informação seja:
 Observada ou divulgada por somente aqueles que possuem o direito de saber (confidenciali-
dade);
 Completa, precisa e protegida contra modificações não autorizadas (integridade);
 Disponível e usável quando necessário, e os sistemas que a oferece pode apropriadamente

resistir a ataques e recuperar-se de/ou prevenir falhas (disponibilidade);
 Confiável (em relação às transações de negócio, como também trocas de informações entre
os negócios, ou com parceiros) [autenticidade e não repúdio].
Para que haja a efetiva governança da informação, o provedor de serviços deverá estabelecer e
manter um Sistema de Gerenciamento da Segurança da Informação (SGSI) para guiar o de-
senvolvimento e gerenciamento de um programa de segurança da informação compreensivo e
que suporte os objetivos de negócio.
O escopo desse sistema inclui, obviamente, todos os aspectos de segurança da

informação que sejam importantes para o negócio. É de responsabilidade do
negócio definir o que requer proteção e o quão forte essa proteção deverá ser.
Os riscos de segurança devem ser reconhecidos e contramedidas deverm ser implementadas,

incluindo aspectos físicos (entrada somente com cartões magnéticos em algumas salas, por
exemplo) e aspectos técnicos (políticas de senha, biometria, etc).
A Política de Segurança da Informação

O documento em questão deverá estar disponível para toda a equipe de TI, clientes e usuários.
A política de segurança da informação também faz parte do Gerenciamento de Segurança da
Informação, de forma a garantir que a política esteja sendo executada. As atividades do pro-
cesso devem ser focadas e direcionadas pela política geral de segurança da informação. Por
isso, a sua importância.
Todos os problemas de segurança da informação devem ser completamente compreendidos

pelo gerente de segurança da TI, para que possa produzir uma política. É necessário que a polí-
tica de segurança da informação esteja sempre alinhada com as novas ameaças e serem for-
malmente revisadas (pelo menos, a cada ano).
É importante realmente compreender que, para a segurança ser efetiva, ela não deve ser so-
mente considerada como um aspecto adicional, e sim como parte integral para o desenho e
operação de todos os serviços e por todos os processos do gerenciamento de serviços de TI.
Por isso, as políticas de segurança da informação devem ser autorizadas pelo gerenciamento
sênior, já que formam parte da governança geral.

A política de segurança da informação deve incluir políticas para controle de acesso, de senhas,
de Internet, antivírus, email, classificação da informação, classificação de documentos, infração
de direitos autorais para materiais eletrônicos, etc. A figura a seguir mostra que as políticas de
SI se encontram armazenadas no Sistema de Gerenciamento da Segurança da Informação:

3.5 Gerenciamento de Fornecedor
Propósito:
O propósito do processo é obter valor pelo dinheiro investido em fornecedores e oferecer quali-
dade (sem gambiarra) aos serviços de TI oferecidos ao negócio. O processo irá buscar garantir
que todos os contratos e acordos com terceiros suportem as necessidades do negócio e que
todos os fornecedores atendam aos comprometimentos contratuais. Com tantas organizações
terceirizando elementos na sua provisão de serviços atualmente, o papel de gerenciar os forne-
cedores apropriadamente nunca foi tão essencial.
Objetivos:
 Obter valor do dinheiro investido em fornecedores e contratos;
 Garantir que contratos com fornecedores sejam alinhados às necessidades de negócio e su-
portem/alinham-se com as metas acordadas em Requisitos de Nível de Serviço e Acordos de
Nível Operacional, em parceira com o Gerenciamento de Nível de Serviço;
 Gerenciar os relacionamentos com os fornecedores;
 Gerenciar a performance dos fornecedores;
 Negociar e acordar contratos com fornecedores e gerenciá-los pelos seus ciclos de vida;
 Manter uma política de fornecedor
Escopo:
O escopo do processo deve incluir o gerenciamento de TODOS os fornecedores e contratos ne-
cessários para suportar a provisão dos serviços de TI para o negócio. Dessa forma, é necessário
que o provedor de serviços possua processos formais para o gerenciamento dos fornecedores e
contratos (adaptáveis a importância do fornecedor e/ou contrato, além do potencial impacto ao
negócio sobre a provisão dos serviços).
Quanto maior a contribuição que realiza para o valor do negócio, mais esforços o provedor de
serviços deverá dispor em seu gerenciamento.
O processo deverá incluir:
 Manutenção de um Sistema de Informação para o Gerenciamento de Fornecedores e Con-

tratos (integra o Sistema de Gerenciamento do Conhecimento de Serviço);
 Categorização de fornecedores e contratos e avaliação de riscos;
 Desenvolvimento, negociação e acordos dos contratos;
 Revisão, renovação e término de contratos;
 Gerenciamento dos fornecedores e seus desempenhos;
 Identificação de oportunidades de melhoria para inclusão no registro de Melhoria Contínua

de Serviço e a implementação do serviço e planos de melhoria de forcedores;

 Manutenção de contratos padrão, termos e condições;
 Gerenciamento de resolução disputas contratuais;
 Gerenciamento de fornecedores subcontratados.
Muitos fornecedores podem ser gerenciados no nível operacional, com relatos e revisões para
garantir que estão entregando o que fôra estabelecido em contrato. Alguns fornecedores ofere-
cem serviços especializados, cuja substituição poderia se tornar muito problemática.
Em alguns casos, a estratégia técnica do provedor de serviços é bastante dependente dos de-
senvolvimentos técnicos entregues por um
fornecedor em particular. Já em outros, os
fornecedores oferecem serviços padrão e
poderiam ser substituídos com pouco (ou
nenhum) impacto ao negócio.
Uma parte essencial do processo é criar um

método para categorização dos fornecedores,
para que tanto tempo quanto atenção sejam
alocados para cada um apropriadamente.
Uma das formas é baseada na avaliação do

risco e impacto em utilizar o fornecedor e o
valor/importância de seus serviços para o
negócio. Dessa forma, poderão ser avaliados
como estratégicos, táticos, operacionais ou
Commodities21 (ou padrão):
O tipo de relacionamento entre o negócio e o

fornecedor estratégico é reconhecido como
uma “parceria”, já que ambas as partes compartilham informações confidenciais para que possa
ser permitida uma cooperação mútua de longo prazo.
Aqueles classificados como médio risco e médio valor, Fornecedores Táticos, embora não seja
tão crítico quanto o anterior, envolve significante atividade comercial. Um bom exemplo para
esse tipo são aqueles fornecedores de manutenção de servidores.
Os fornecedores operacionais são gerenciados por gerentes juniores, através de revisões regu-
lares. Havendo falha por parte desses fornecedores, o impacto será relativamente baixo. Um
exemplo bom para esse tipo são os fornecedores que oferecem serviços de reparo de PC ou de
impressora.
Já aqueles fornecedores de serviços padrão (baixo risco e baixo valor) são aqueles cujos servi-
ços podem ser facilmente terceirizados praticamente em qualquer lugar. Um exemplo bom para
esse tipo de fornecedor são aqueles fornecedores de papel ou de toner para impressoras. Caso
haja falhas por parte dos mesmos, basta que esse seja substituído por qualquer outro que con-
siga oferecer o serviço.
21
Commodity é um termo utilizado para designar serviços que são muitos comuns, sem valor agredado

3.6 Coordenação do Desenho
Propósito:
O propósito do processo é garantir que as metas e objetivos do estágio sejam atingidas, ofere-
cendo e mantendo um ponto único de coordenação e controle para todas as atividades e pro-
cessos dentro desse estágio do ciclo de vida do serviço.
Objetivos:
 Garantir o desenho consistente dos serviços apropriados, sistemas de informação para o ge-
renciamento de serviço, arquiteturas, tecnologia, processos, informação e métricas para a-
tender os resultados e requisitos atuais e evolutivos do negócio;
 Coordenar todas as atividades de desenho pelos projetos, mudanças, fornecedores e equipes

de suporte, além de gerenciar os cronogramas, recursos e conflitos, quando necessário;
 Planejar e coordenar os recursos e capacidades requeridas para desenhar novos/alterados

serviços;
 Produzir Pacotes de Desenho de Serviço;
 Garantir que desenhos de serviços apropriados e/ou pacotes de desenho de serviço sejam
entregues à Transição de Serviço conforme acordado;
 Garantir que todos os modelos de serviço e desenhos de soluções de serviço se conformam

com requisitos estratégicos, requisitos contratuais, requisitos de governança e outros requi-
sitos corporativos;
 Melhorar a efetividade e eficiência das atividades e processos do estágio;
 Garantir que todas as partes adotem um framework comum de práticas de desenho comuns
e padronizadas, na forma de atividades, processos e sistemas de suporte, quando apropria-
do;
 Monitorar e melhorar o desempenho do estágio.
Escopo:
O escopo do processo inclui todas as atividades de desenho, particularmente todas as no-
vas/alteradas soluções de serviço que estão sendo desenhadas propostas para a transição em
ambiente de produção. Alguns esforços de desenho farão parte de um projeto, outros serão
gerenciados através do processo de mudança, sem que haja um projeto formalmente definido.
Por outro lado, alguns esforços de desenho serão extensos/complexos, outros serão simples/
rápidos. Nem toda atividade de desenho requer o mesmo nível de rigor (cada organização defi-
nirá o critério) para garantir o sucesso, logo, um número significante de esforços de desenho
irá requerer pouco ou nenhuma atenção do processo Coordenação de Desenho.
A maioria das atividades do processo irão focar-se nos esforços de desenho que são parte de
um projeto, como também aqueles associados com mudanças de tipos definidos. Geralmente,
as mudanças que requerem a atenção do processo são aquelas consideradas maiores, mas
qualquer uma que a organização acredita que poderia se beneficiar do processo poderá ser in-
cluída.

O processo inclui:
 Auxiliar e suportar cada projeto ou mudança através de todos os processos e atividades do

estágio;
 Manter políticas, orientações, padrões, orçamentos, modelos, recursos e capacidades para as

atividades e processos do estágio;
 Coordenar, priorizar e agendar todos os recursos do Desenho de Serviço para satisfazer

quaisquer demandas conflitantes de todos os projetos e mudanças;
 Planejar e prever os recursos necessários para a demanda futura das atividades do estágio;
 Revisar, medir e melhorar o desempenho de todas as atividades e processos do estágio;
 Garantir que todos os requisitos sejam apropriadamente endereçados nos desenhos de ser-
viço, particularmente os requisitos de utilidade e garantia;
 Garantir a produção de desenhos de serviço e/ou pacotes de desenho de serviço e sua “pas-
sagem” para o estágio seguinte.
3.7 Gerenciamento da Continuidade de Serviço de TI
Propósito:
O propósito do processo é suportar o processo geral de Gerenciamento da Continuidade do Ne-
gócio, garantindo que, gerenciando os riscos que poderiam afetar seriamente os serviços de TI,
o provedor de serviços de TI consiga sempre oferecer o mínimo dos níveis de serviço relaciona-
dos a continuidade de negócio acordados.
Para suportar e alinhar-se com o processo gerenciamento da continuidade de negócio, o Geren-

ciamento da Continuidade de Serviço de TI utiliza avaliações de risco formais e técnicas de ge-
renciamento para:
 Reduzir os riscos dos serviços de TI de forma a oferecer os níveis aceitáveis que foram acor-
dados;
 Planejar e preparar a recuperação dos serviços de TI.
Objetivos:
 Produzir e manter um conjunto de planos de continuidade de serviço de TI que suporte os
planos gerais de continuidade de negócio da organização;
 Completar os exercícios regulares de Análise de Impacto no Negócio para garantir que todos
os planos de continuidade ainda estejam em conformidade com os requisitos do negócio;
 Conduzir avaliação de riscos de maneira regular e exercícios de gestão para gerenciar os

serviços de TI dentro do acordado nível de risco de negócio, em conjunção com os processos
de Gerenciamento da Disponibilidade e Gerenciamento da Segurança da Informação.

 Oferecer conselho e orientações para todas as outras áreas do negócio e da TI sobre todos
os problemas relacionados a continuidade;
 Garantir que mecanismos apropriados de continuidade sejam colocados em prática para a-

tender ou exceder 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 mé-

todos de suporte/procedimentos;
 Garantir que medias proativas melhorar a disponibilidade dos serviços sejam implementadas,
caso seja justificado o custo;
 Negociar e acordar contratos com fornecedores para a provisão de capacidade de restaura-

ção necessária para suportar todos os planos de continuidade em conjunto com o processo
Gerenciamento de Fornecedor.
Escopo:
O processo foca-se nos eventos que o negócio considera significante o bastante para ser trata-
do como um “desastre”. Os menos significantes serão tratados como parte do processo de Ge-
renciamento de Incidente. Quem definirá o critério sobre o quê vem a ser um desastre é o ne-
gócio - a organização.
O impacto de uma perda de processo de negócio, como perda financeira, dano à reputação ou
questões regulatórias, são medidos através do exercício de Análise de Impacto do Negócio, que
determinará os mínimos requisitos críticos. O escopo do processo dentro da organização é de-
terminado pela estrutura organizacional, cultura e direção estratégica (ambos de negócio e tec-
nologia) em termos dos serviços oferecidos e como esses desenvolvem e modificam-se com o
tempo.
É importante entender que o processo geralmente não cobre riscos de longo prazo (ex: mudan-
ças na direção do negócio, reestruturação, diversificação, etc) e nem falhas técnicas menores
(ex: falha não-crítica em discos22).
O processo inclui:
 O acordo do escopo processo e as políticas adotadas;
 Realizar a análise de impacto do negócio, para quantificar o impacto da perda que um servi-
ço de TI poderia exercer sobre o negócio;
 Avaliação e gestão dos riscos – a identificação e avaliação do risco para identificar ameaças
potenciais para a continuidade e a probabilidade de se tornar realidade;
 Produção de uma estratégia de geral de Gerenciamento da Continuidade de serviços de TI,
alinhada ao gerenciamento da continuidade do negócio;
 Produção de um plano de Gerenciamento da Continuidade de serviços de TI que, claro, deve-
rá estar integrado aos planos de gerenciamento de continuidade do negócio. Além disso, os
planos deverão ser testados;
 Operação contínua e manutenção dos planos.
22
A menos que haja possibilidade desse impacto se tornar um impacto maior para o negócio.

Sendo assim, são preocupações do estágio desenvolver uma estratégia para a continuidade do
serviço, baseado na análise de impacto de negócio e ações de gerenciamento de riscos e que
estejam alinhadas a estratégia de continuidade de negócio.
Embora o plano do GCSTI ofereça um nível de garantia para que os processos críticos de negó-
cio possam ser recuperados em caso de evento catastrófico, é preferível que esses eventos nem
ocorram. A avaliação de riscos requer um compreendimento das prováveis ameaças e quão
vulnerável a organização encontra-se para elas.
O gerenciamento de riscos considera respostas (custo-justicáveis) para essas ameaças. O obje-

tivo é reduzir a vulnerabilidade ao risco, tornando-se menos suscetíveis a ocorrer (ou, pelo me-
nos, minimizar o seu impacto). A Avaliação de Riscos irá compilar uma lista de riscos avaliados.
As contramedidas deverão reduzir a probabilidade ou o impacto de uma ameaça, reduzindo sua
pontuação a níveis aceitáveis.
3.8 Gerenciamento da Capacidade
Propósito:
O propósito do Gerenciamento da Capacidade é garantir que a capacidade dos serviços de TI e
da infraestrutura de TI atenda aos requisitos relacionados ao desempenho e capacidade acor-
dados, de maneira custo-efetiva e a tempo.
O processo está preocupado em ir de encontro com as necessidades de desempenho atuais e

futuras do negócio. Entregar capacidade suficiente é um aspecto de garantia chave de um ser-
viço que precisa ser entregue se os benefícios do serviço devem ser realmente realizados.
Objetivos:
 Produzir e manter um plano de capacidade apropriado e atualizado. Esse deverá refletir as
necessidades atuais e futuras do negócio;
 Oferecer opiniões e orientações para todas as demais áreas do negócio e da TI sobre os pro-
blemas relacionados a desempenho e capacidade;
 Garantir que o desempenho dos serviços atende todas as metas acordadas, gerenciando o
desempenho e capacidade dos serviços e recursos;
 Auxiliar com o diagnóstico e resolução incidentes e problemas relacionados a desempenho e

capacidade;
 Avaliar o impacto de todas as mudanças no plano de capacidade, além do desempenho e

capacidade de todos os serviços e recursos;
 Garantir que medidas proativas para melhorar o desempenho dos serviços sejam implemen-
tadas (contanto que o custo seja justificável).

Escopo:
 Monitorar os Planos de Atividades de Negócio através do desempenho, utilização e taxa de
transferência dos serviços de TI e infraestrutura de suporte, ambiente, dados e componentes
de aplicações, além da produção relatórios regulares e ad hoc sobre a capacidade e desem-
penho de componentes e dos serviços;
 Empreender atividades de tuning23 para para fazer o uso mais eficiente dos recursos de TI
existentes;
 Entender as demandas atuais acordadas e futuras feitas pelos clientes pelos recursos de TI,
além de produzir previsões para requisitos futuros;
 Influenciar a demanda em conjunto com os processos de Gerenciamento Financeiro para

Serviços de TI e Gerenciamento da Demanda;
 Produzir um plano de capacidade que possibilite ao provedor de serviços continuar a oferecer

serviços de qualidade definidos nos Acordos de Nível de Serviço;
 Auxiliar na identificação e resolução de quaisquer incidentes e problemas associados com os

serviços ou capacidade/performance dos componentes;
 Oferecer melhorias proativas nos serviços ou desempenho dos componentes (contanto que
sejam justificáveis em termos de custo e que atendam as necessidades de negócio).
Como o processo é extremamente técnico, complexo e exigente, para obter resultados, ele re-
quer três sub-processos de apoio. Vejamos cada um deles:
 Gerenciamento da Capacidade de Negócio: esse sub-processo traduz as necessidades de

negócio e planos em requisitos para serviços e infraestrutura de TI, garantindo assim que os
requisitos de negócio futuros para os serviços de TI sejam quantificados, desenhados, plane-
jados e implementados em tempo hábil. Esses requisitos futuros vêm da Estratégia de Servi-
ço e do portfólio de serviços, detalhando novos processos e requisitos de serviço, mudanças,
melhorias e também o crescimento nos serviços existentes.
 Gerenciamento da Capacidade de Serviço: esse sub-processo foca-se no gerenciamento,

controle e predição do desempenho fim-a-fim e no uso e carga de trabalho da capacidade
dos serviços operacionais de TI. Ele irá garantir que o desempenho de todos os serviços seja
monitorados/medidos e que os dados coletados sejam gravados, analisados e reportados.
Quando necessário, ações proativas e reativas deverão ser instigadas, para garantir que o
desempenho de todos os serviços atende as metas de negócio acordadas. Isso tudo é reali-
zado pela equipe com conhecimento de todas as áreas de tecnologia usadas na entrega fim a
fim do serviço, como também envolve buscar opiniões de especialistas envolvidos no geren-
ciamento da capacidade de componente.
23
Atividade responsável por planejar mudanças de forma a fazer o uso mais eficiente possível dos recursos.

 Gerenciamento da Capacidade de Componente: esse sub-processo é o aspecto mais

técnico do Gerenciamento da Capacidade e, geralmente, é executado pela equipe técnica de
gerenciamento, com o monitoramento diário sendo de responsabilidade das funções de ge-
renciamento técnico e de operações. Foca-se no gerenciamento, controle e predição do de-
sempenho, utilização e capacidade dos componentes de tecnologia da TI individuais. Ele ga-
rante que todos os componentes dentro da infraestrutura de TI que possuam recursos finitos
sejam monitorados e medidos e que, além disso, os dados coletados sejam gravados, anali-
sados e reportados.
Citamos há pouco que um dos itens que faz parte do escopo do processo é o Plano de Capaci-
dade. Esse é uma importante saída do processo, já que captura os requisitos correntes e futu-
ros e propõe como esses poderão ser atingidos (geralmente cobre de 12 a 18 meses para fren-
te). Para elaborar o plano é necessário um relacionamento muito próximo com a fase de estra-
tégia, do ciclo de vida; a estratégia precisa ser baseada no firme compreendimento das capaci-
dades correntes e futuras da infraestrutura e, assim, os planejadores precisam de entradas das
discussões estratégicas para entender quais poderão ser os requisitos futuros.
O Plano de Capacidade é armazenado no Sistema de Informação para o Gerenciamento da Ca-

pacidade, juntamente com os relatórios de desempenho atuais e previsões de requisitos futu-
ros. Visualize abaixo os três subprocessos do gerenciamento da capacidade e como cada um
está envolvido em um ou mais passos do processo de revisar e melhorar a capacidade atual,
identificar mudanças nos requisitos de capacidade e oferecer novas capacidades:

Capítulo 04 – Transição de
No capitulo anterior, estu-
Serviço
damos bastante conceitos
chave e fundamentos bási- Objetivos do Capítulo
cos do longo estágio Dese- Ao final desse capítulo você deverá ser
nho de Serviço. Agora, ire- capaz de:
mos estudar o próximo es-
tágio do ciclo de vida do
serviço: Transição de Servi-  Explicar e definir conceitos básicos rela-
ço. cionados ao gerenciamento de serviço
de TI relacionados à Transição de Ser-
viço.
Ao todo, estudaremos 5  Entender os processos relacionados ao

processos – sendo 1 deles de estágio em questão, cobrados no exa-
maneira mais aprofundada. me ITIL® Foundation, edição 2011.
Não se trata de um estágio
muito extenso e complicado,
entretanto, é necessário Sumário do Capítulo
ficar sempre atento aos
conceitos elementares da 1 Tópicos do Exame _______________ 71
Transição de Serviço. Por- 2 Introdução ao estágio Transição de
tanto, ressaltamos mais
Serviço ____________________________ 72
uma vez: não tenha pressa.
Leia cada processo do está- 3 Processos ______________________ 74
gio pausadamente para que 3.1 Planejamento e Suporte à Transição 74
tudo fique claro para você.
Lembre-se: o ideal é que 3.2 Gerenciamento da Configuração e
você se prepare bem; assim, Ativo de Serviço _____________________ 76
3.2.1 Modelo de Configuração _________ 77
no dia do exame, você con-
siguirá uma pontuação! 3.3 Gerenciamento do Conhecimento _ 80
3.3.1 A Estrutura DICS ________________ 81
3.4 Gerenciamento de Mudança ______ 83
3.4.1 Os Tipos de Mudança____________ 84
3.4.2 Comitê Consultivo de Mudança ___ 86
3.4.3 Comitê Consultivo de Mudança
Emergencial ___________________________ 86
3.4.4 Atividades do Processo __________ 86
3.4.5 Interfaces com demais processos __ 87
3.5 Gerenciamento de Liberação e
Bons estudos! Implantação ________________________ 88

1 Tópicos do Exame
 (ITIL®FND02-7) ciência do propósito, objetivos e escopo da transição de serviço.
 (ITIL®FND02-8) explicar qual o valor entregue pela transição de serviço ao negócio.
 (ITIL®FND03-17) item de configuração
 (ITIL®FND03-20) mudança
 (ITIL®FND03-21) tipos de mudanças (padrão, emergencial e normal)
 (ITIL®FND03-35) política de liberação
 (ITIL®FND03-37) propostas de mudança
 (ITIL®FND05) sobre os processos:
 explicar o propósito, objetivos e escopo, conceitos básicos, atividades dos processos e

(ITIL®FND05-5)
interfaces para:
o (ITIL®FND05-51) gerenciamento de mudança
 (ITIL®FND05-5) explicar o propósito, objetivos e escopo para:
o (ITIL®FND05-61) gerenciamento de liberação e implantação.
o (ITIL®FND05-62) gerenciamento do conhecimento.
o (ITIL®FND05-63) gerenciamento da configuração e ativo de serviço.
o (ITIL®FND05-64) planejamento e suporte da transição.

2 Introdução ao estágio Transição de Serviço
Propósito:
Assegurar que serviços novos, modificados ou aposentados consigam atender às expectativas
do negócio, que já foram documentados nos estágios anteriores.
Objetivos:
 Planejar e gerenciar as mudanças nos serviços de maneira eficiente e efetiva;
 Gerenciar os riscos relacionados aos serviços (novos, alterados ou aposentados);
 Implantar com sucesso as liberações de serviço nos ambientes suportados;
 Definir corretamente as expectativas sobre desempenho e uso de serviços novos ou altera-

dos;
 Garantir que as mudanças nos serviços criem o valor de negócio esperado;
 Oferecer conhecimento e informações de qualidade sobre os serviços e ativos de serviço.

Para que tudo isso seja obtido com eficácia, muitas coisas precisarão ocorrer durante o estágio,
entre elas:
 Planejamento e gerenciamento de toda a capacidade e recursos necessários para gerenciar

as transições;
 Implementar uma rigorosa estrutura para avaliar as capacidades dos serviços e perfis de
risco (antes que novos/alterados serviços sejam implantados);
 Estabelecer e manter a integridade dos ativos de serviço;
 Oferecer mecanismos eficientes e repetíveis para construir, testar e implantar serviços e li-
berações;
 Garantir que os serviços possam ser gerenciados, operados e suportados de acordo com as
restrições especificadas durante o estágio Desenho de Serviço.
Escopo:
Fazem parte do escopo do estágio:
 Gerencia toda a complexidade associada às alterações nos serviços e processos do gerenci-

amento de serviço;
 Permite a inovação, enquanto minimiza as consequências não intencionadas ocasionadas por

alterações inapropriadas;
 Introdução de novos serviços;
 Mudanças em serviços existentes. Exemplos: expansão/redução da área de atuação dos ser-

viços (escopo), troca de fornecedores, etc;
 Descontinuação de serviços, aplicações ou outros componentes de serviço;
 Transferência de controle dos serviços de/para outros provedores de serviços.
O escopo também inclui a transição de mudanças nas capacidades de gerenciamento de serviço

do provedor de serviços que impactarão as formas de trabalho, organização como um todo,
pessoas, projetos e terceiros envolvidos no gerenciamento de serviço.

Valor entregue ao negócio:

 Volumes maiores de mudanças realizadas com sucesso;
 Reduzir atrasos ocasionados por confrontos inesperados e dependências;
 Reduzir o esforço gasto em gerenciar os ambientes de teste de transição de serviço (ambien-

tes pilotos);
 Permite que os ativos do estágio sejam compartilhados e reutilizados entre projetos e servi-
ços;
 Garante que serviços novos/alterados sejam sustentáveis, com boa relação custo-
efetividade;
 Possibilita aos projetos predizer os riscos, recursos, gastos e prazos.
3 Processos
3.1 Planejamento e Suporte à Transição
Propósito:
Oferecer o planejamento geral para as transições de serviço e coordenar os recursos necessá-
rios. O processo busca melhorar significantemente a habilidade do provedor de serviço em ma-
nipular grandes volumes de mudanças e liberações. Uma abordagem integrada ao planejamen-
to melhorará o alinhamento dos planos de transição de serviço com o cliente, fornecedor e os
planos de projeto de mudança de negócio.
O processo considera TODOS os aspectos de um desenho de serviço novo/alterado, realiza pla-

nos para a transição de um serviço em um ambiente de produção e coordena os recursos ne-
cessários. Na verdade, o processo age como uma “ponte”, garantindo que os requisitos do ser-
viço (formulados no plano de desenho de serviço) cheguem íntegros na Operação de Serviço.
Objetivos:
 Planejar e coordenar os recursos, de forma a garantir que os requisitos da Estratégia de Ser-
viço, que já foram codificadas no Desenho de Serviço, sejam realizadas com sucesso na ope-
ração de serviço;
 Coordenar as atividades pelos projetos, fornecedores e equipes de serviço quando necessá-

rio;
 Estabelecer novos/alterados serviços nos ambientes suportados, dentro do custo pré-

estabelecido, qualidade e dentro do prazo;
 Estabelecer novos/modificados sistemas de gerenciamento de informação e ferramentas,

tecnologias e arquiteturas de gerenciamento, processos de gerenciamento de serviço e mé-
todos de medição e métricas para atender aos requisitos estabelecidos durante o desenho de
serviço;

 Garantir que todas as partes adotem um framework comum de processos reutilizáveis pa-
drão, para melhorar a efetividade e eficiência das atividades do planejamento integrado e a-
tividades de coordenação
 Identificar, gerenciar e controlar riscos, para minimizar a chance de falha e interrupções pe-
las atividades da transição;
 Garantir que as questões relacionadas a transição de serviço, riscos e desvios sejam repor-
tadas para as partes interessadas apropriadas e tomadores de decisão;
 Monitorar e melhorar o desempenho do estágio como um todo.
Escopo:
 Manter políticas, padrões e modelos para as atividades e processos do estágio;
 Guiar cada mudança maior ou novos serviços por todos os processos do estágio;
 Coordenar os esforços necessários para habilitar que múltiplas transições sejam gerenciadas
ao mesmo tempo;
 Priorizar exigências conflitantes para os recursos da transição de serviço;
 Planejar o orçamento e recursos necessários para preencher os requisitos futuros para a

transição de serviço;
 Revisar e melhorar o desempenho das atividades;
 Garantir que a transição de serviço seja coordenada com as atividades do gerenciamento de

programa e projeto, desenho de serviço e Desenvolvimento de Serviço.
É importante destacar que o processo NÃO É responsável pelo planejamento

detalhado da construção, teste e implantação das mudanças ou liberações indi-
viduais; essas atividades são executadas como parte dos processos de Gerenci-
amento de Mudança e Gerenciamento de Liberação e Implantação.

3.2 Gerenciamento da Configuração e Ativo de Serviço
Propósito:
Garantir que os ativos necessários para a entrega dos serviços sejam controlados adequada-
mente. O processo também buscará garantir que as informações sobre esses ativos sejam pre-
cisas, confiáveis e disponíveis quando e onde forem necessárias.
Objetivos:
 Garantir que os ativos sob controle da organização de TI sejam identificados, controlados e
cuidados pelos seus ciclos de vida;
 Identificar, controlar, registrar, reportar, auditar e verificar serviços e outros itens de confi-
guração, incluindo versões, linhas de base, componentes constituintes, atributos e relacio-
namentos;
 Prestar contas, gerenciar e proteger a integridade dos itens de configuração pelo ciclo de
vida do serviço, trabalhando com o Gerenciamento de Mudança para garantir que somente
componentes autorizados sejam utilizados e somente mudanças autorizadas sejam realiza-
das;
 Garantir a integridade dos itens de configuração e das configurações necessárias para con-
trolar os serviços, estabelecendo o Sistema de Gerenciamento da Configuração;
 Manter informações precisas sobre o histórico dos serviços e outros itens de configuração,
além dos estados planejados e correntes;
 Apoiar os processos de gerenciamento de maneira eficiente e efetiva, oferendo informações

de configuração precisas para permitir que as pessoas tomem decisões na hora certa – por
exemplo, autorizar mudanças e liberações ou resolver incidentes e problemas.
Os ativos de serviço (qualquer recurso/capacidade que poderia contribuir para a entrega de

um serviço) que precisam ser gerenciados para que os serviços possam ser entregues são
chamados de Item de Configuração.
Estes possuem os seguintes status durante o seu ciclo de vida: Registrado, Aceito, Instalado e
Retirado. Outros ativos de serviço também podem ser necessários para a entrega dos serviços,
mas se não puderem ser gerenciados individualmente, não são considerados itens de configura-
ção. Importante não confundi-os com os registros de configuração.
Esses são um conjunto de atributos e relacionamentos a respeito de um determinado item de

configuração e armazenados no banco de dados do gerenciamento de configuração, gerenciado
por um sistema de gerenciamento da configuração.

Como existem uma variedade de itens de configuração, eles poderão ser categorizados da se-
guinte forma:
 Itens de configuração do ciclo de vida do serviço: incluem o caso de negócio, planos de

gerenciamento de serviço e o pacote de desenho de serviço. Esses são documentos que ofe-
recem informações sobre os planos e requisitos para os serviços, incluindo custos e benefí-
cios;
 Itens de configuração de serviço: incluem ativos da capacidade de serviço como o geren-

ciamento, processos e pessoas; ativos de recursos de serviço como capital financeiro, infra-
estrutura, pessoas; modelo de serviço; pacote de serviço; pacote de liberação e critério de
aceitação de serviço;
 Itens de configuração da organização: incluém documentações relacionadas às políticas

organizacionais ou padrões;
 Itens de configuração internos: aqueles entregues por projetos individuais, incluindo ati-
vos tangíveis (centro de dados) e intangíveis (como softwares), que são requeridos para en-
tregar e manter a infraestrutura e o serviço;
 Itens de configuração externos: requisitos e acordos de clientes externos;
 Itens de configuração de interface: Exemplos incluem a documentação relacionada a

provisão dos serviços fim a fim, através de distintos provedores de serviço.
Escopo:
Faz parte do escopo do processo o gerenciamento do ciclo de vida de TODOS os itens de confi-
guração. O processo, inclusive, vai buscar garantir que as liberações em ambientes controlados
e o uso operacional sejam feitos na base de uma autorização formal.
Além disso, também fazem parte do escopo do processo quaisquer interfaces com itens de con-
figuração internos e externos, como ativos compartilhados que fazem parte da provisão do ser-
viço. As informações de itens de configuração podem também ser gravadas em bancos de da-
dos menores, conhecidos como Banco de Dados de Gerenciamento da Configuração.
O Sistema de Gerenciamento da Configuração pode ser composto de vários Bancos de Dados de

Gerenciamento da Configuração.
3.2.1 Modelo de Configuração

O processo entrega um modelo dos serviços, ativos e infraestrutura, registrando os relaciona-
mentos entre todos os itens de configuração. Isso permite que outros processos acessem diver-
sas informações importantes, de forma a:
 Avaliar o impacto e causa dos incidentes e problemas;

 Avaliar o impacto de mudanças que são propostas;
 Planejar e desenhar novos serviços (ou alterados);
 Planejar atualizações de software e de tecnologia em geral;
 Planejar liberações e migrar ativos de serviço para localidades diferentes e centros de servi-
ço;
 Otimizar utilização dos ativos e custos.

Visualize abaixo um exemplo de modelo lógico de configuração:
É através do sistema de gerenciamento da configuração que é possível criar o

modelo lógico da infraestrutura. Até mesmo outros itens que compõe os servi-
ços, mas não são tradicionalmente capturados como ativos por outras partes da
organização (produtos de trabalho, como modelos da organização, documenta-
ção de processo, etc) podem ser classificados como itens de configuração no
sistema de gerenciamento da configuração.
Lembre-se que o sistema de gerenciamento da configuração é o sistema que permite gerenciar

o modelo de configuração e entregar a informação para aqueles que precisam. É nele que ficam
armazenadas TODAS as informações sobre os itens de configuração identificados pelo processo.
Observe a seguir a figura que ilustra o relacionamento entre os registros de configuração, os
itens de configuração e o sistema de gerenciamento do conhecimento de serviço:

SGCS: Sistema de Gerenciamento do Conhecimento de Serviço

SGC: Sistema de Gerenciamento da Configuração
ICs: Itens de Configuração
SLAs: Acordos de Nível de Serviço
BDGCs: Bancos de Dados do Gerenciamento da Configuração
Alguns aspectos dos serviços que são capturados como registros no sistema de gerenciamento
da configuração ou sistema de gerenciamento da configuração de serviço são, de fato, bibliote-
cas físicas. As bibliotecas permitem o gerenciamento desses elementos da infraestrutura ou
itens de configuração, para manter a integridade dos mesmos, fora do uso operacional.
Considere, por exemplo, o uso de software autorizado, comprado sob licença de terceiros. É
preciso manter a cópia mestre desse software e a documentação relacionada em um local segu-
ro para ser usado em situações de continuidade ou para manter uma versão “clean” para futu-
ras reinstalações.
Os registros desses itens de configuração devem ser capturados e gerenciados no sistema de

gerenciamento da configuração e, assim, é possível validar e controlar o uso das versões de
software no ambiente de produção.
O gerenciamento de uma biblioteca segura deve ser efetuado pelos controles do gerenciamento
da configuração e ativo de serviço através do gerenciamento de mudança. A Biblioteca de Mídia
Definitiva é gerenciada para garantir a integridade e segurança das versões autorizadas de
software para serem usadas no ambiente de produção. As políticas que controlam o gerencia-
mento da biblioteca de mídia definitiva formarão parte do sistema de gerenciamento da confi-
guração de serviço.

3.3 Gerenciamento do Conhecimento
Propósito:
Buscar a eficiência no que diz respeito ao compartilhamento do conhecimento. Por isso, tem
como propósito compartilhar perspectivas, ideias, experiência e informação, de forma a garantir
que estejam sempre disponíveis e para permitir a tomada de decisões de maneira informada.
Objetivos:
 Melhorar a qualidade do gerenciamento de tomada de decisões;
 Possibilitar mais eficiência e melhorar a qualidade dos serviços, aumentar a satisfação do

cliente e reduzir o custo do serviço, reduzindo a necessidade de redescoberta do conheci-
mento;
 Garantir que a equipe possua um claro compreendimento do valor que seus serviços ofere-
cem aos clientes, além das formas nos quais os benefícios são realizados e as formas que
os benefícios são obtidos;
 Manter o Sistema de Gerenciamento do Conhecimento de Serviço, de forma a oferecer a-

cesso controlado ao conhecimento, informações e dados apropriados para cada tipo de pú-
blico;
 Reunir, analisar, armazenar, compartilhar, usar e manter o conhecimento, as informações e

dados.
Escopo:
Ao comentarmos sobre o escopo do processo, algo interessante surge: o processo é relevante
para todos os estágios do ciclo de vida de um serviço! Não esqueça! Ele é referenciado por toda
a ITIL®, sob a perspectiva de cada publicação, evidentemente.
No caso da Transição de Serviço, o processo possui como escopo a gestão efetiva do conheci-
mento, bem como das informações e dados, a partir dos quais o conhecimento deriva.
Através da boa gestão dos dados, informações e do conhecimento, o processo entregará os

seguintes valores ao negócio:
 Conformidade com os requisitos, incluindo os Legais;
 Requisitos documentados para a retenção de cada categoria de dados, informação e conhe-

cimento;
 Formas definidas de dados, conhecimento e informação, podendo ser facilmente utilizada

por toda a organização;
 Dados, informações e conhecimentos que sejam atuais, completos, válidos e disponíveis

quando e onde cada público precisar;
 Disposição dos dados, informações e conhecimento conforme requerido.

3.3.1 A Estrutura DICS

O processo é, geralmente, melhor visualizado (consequentemente, entendido) dentro da estru-
tura conhecida como “Dados-para-Informação-para-Conhecimento-para-Sabedoria”. Vejamos
abaixo:
 Dados
 Conjunto discreto de fatos. As atividades-chave (relacionadas aos dados) para o
processo são a habilidade de:
 Capturar dados precisos e manter a integridade dos mesmos;
 Analisar, sintetizar e, em seguida, transformar os dados em informações;
 Identificar dados relevantes e concentrar recursos para a sua captura;
 Arquivar e eliminar dados, de forma a garantir o equilíbrio ótimo entre a

disponibilidade dos dados e utilização dos recursos.
 Informação
 É adquirida ao inserir os dados em contextos. Geralmente a informação é arma-

zenada de maneira semi-estruturada, como em documentos, email, etc. Ativida-
des-chave (em torno da Informação):
 Gerenciamento do conteúdo, de forma que se torne fácil capturar, consul-

tar, encontrar, reutilizar e aprender através de experiências passadas.
 Conhecimento
 Composto de experiências tácitas, ideias, introspecções, valores e julgamentos

das pessoas. Essas ganham conhecimento através de expertises próprias e da
troca de conhecimento entre si (além da análise das informações). Na Transição
de Serviço, o conhecimento não é somente baseado na transição em progresso,
mas também em transições anteriores.

 Sabedoria
 Faz uso do conhecimento para criar valor através de decisões corretas e bem in-
formadas. Envolve a conscientização de aplicação e de contexto, para oferecer
um julgamento de senso comum.
Uma parte muito importante do Sistema de Gerenciamento do Conhecimento de Serviço é o

Sistema de Gerenciamento da Configuração, já que o último descreve os atributos e relaciona-
mentos entre todos os Itens de Configuração – muitos dos quais são, por si mesmos, ativos de
conhecimento, de informação ou de dados. A figura a seguir é uma representação simplificada
do relacionamento entre os três níveis:
O Sistema de Gerenciamento do Conhecimento de Serviço pode conter muitos tipos diferentes

de dados, informações e conhecimento. Exemplos: Portfólio de serviço, Sistema de Gerencia-
mento do Conhecimento, Biblioca de mídia definitiva, Acordos de Nível de Serviço, Acordos de
Nível Operacional, política de segurança da informação, planos de negócio, modelos de custo,
plano de capacidade, relatórios de serviço, scripts de diagnóstico, informações pessoais de cli-
entes/usuários, etc.

3.4 Gerenciamento de Mudança
Propósito:
Controlar o ciclo de vida de todas as mudanças, habilitando que mudanças vantajosas sejam
feitas com o mínimo de interrupção aos serviços de TI. As mudanças que não são controladas
podem virar gatilhos ou ser causa de incidentes em toda a infraestrutura. O processo possui
tanta importância que, segundo o IT Service Management Forum, 80% de todos os incidentes
são causados por mudanças na infraestrutura de TI.
Objetivos:
 Responder aos requisitos de mudança do negócio do cliente, enquanto maximiza o valor e
reduz incidentes, interrupções e retrabalho;
 Responder às requisições de TI e do negócio por mudanças que irão alinhar os serviços com
as necessidades de negócio;
 Garantir que mudanças sejam registradas e avaliadas, e que mudanças autorizadas sejam
priorizadas, planejadas, testadas, implementadas, documentadas e revisadas de maneira
controlada;
 Garantir que todas as mudanças para os itens de configuração sejam gravadas no sistema
de gerenciamento da configuração;
 Otimizar o risco geral de negócio.
Escopo:
As mudanças podem ser definidas de inúmeras maneiras. A ITIL® define como sendo a adição,
modificação ou remoção de qualquer coisa que possua efeito sobre os serviços de TI. O escopo
deve incluir praticamente tudo em relação à TI: da arquitetura e infraestrutura aos processos,
documentação, métricas e ferramentas que suportam os serviços. Inclui também as mudanças
nos serviços de TI e itens de configuração.
O processo também cobre todas as mudanças relacionadas aos 5 aspectos do Desenho de Ser-
viço:
 Soluções de serviço para novos ou alterados serviços, incluindo todos os requisitos funcio-
nais;
 Gerenciamento dos sistemas de informação e ferramentas, especialmente o portfólio de ser-

viço;
 Arquiteturas tecnológicas e o gerenciamento sobre elas;
 Processos necessários para desenhar, transicionar, operar e melhorar os serviços;
 Sistemas de medição de performance, métodos e métricas para os serviços, seus componen-

tes e processos.

As mudanças estratégicas são trazidas via Estratégia de Serviço (processo Gerenciamento do

Portfólio de Serviço), na forma de mudanças propositais. As mudanças para um serviço são
trazidas via Desenho de Serviço, Melhoria Contínua de Serviço, etc. Mudanças corretivas, reso-
lução de erros encontrados nos serviços, serão iniciadas na Operação de Serviço e podem rote-
ar via suporte ou fornecedores externos, em uma formal Requisição de Mudança24.
Mudança: adição, modificação ou remoção de qualquer coisa que possua

efeito sobre os serviços de TI;
Requisição de Mudança: proposta formal para alterar um Item de Configu-

ração (registrada de maneira eletrônica ou manual);
Registro de Mudança: captura dos detalhes do ciclo de vida de uma mu-

dança. Surge em resposta a uma requisição de mudança. Os registros deve-
rão referenciar os itens de configuração afetados por uma mudança. Os re-
gistros de mudança são armazenados no sistema de gerenciamento da con-
figuração ou em alguma ferramenta de gerenciamento de serviço.
3.4.1 Os Tipos de Mudança

Existem muitos tipos diferentes de mudanças nos serviços e cada uma delas possui um proce-
dimento diferente para manipulá-las. Dessa forma, é possível adaptar a requisição de mudança
– de forma a atender aos requisitos individuais de cada tipo de mudança.
O primeiro tipo de mudança de serviço identificado pela ITIL® é a Mudança Padrão. Vejamos
algumas de suas características:
 Já existe um gatilho claramente definido para a iniciação da mudança, como uma exceção
gerada por uma ferramenta de gerenciamento de evento ou requisição via service desk;
 As ações são bem compreendidas e documentadas;
 Já possuem autorização para executá-las;
 O risco é baixo ou bem conhecido e entendido.
O segundo tipo de mudança é a Mudança Emergencial. Algumas características:
 Deverá ser implementada o mais breve possível;
 Podem (ou não) haver testes;
 Uma vez o registro de mudança tenha surgido, a documentação poderá ser completada pos-
teriormente.
24
Request For Change (RFC). Proposta formal para alteração de um IC, que poderá ser gravada eletronicamente ou não.
Inclui detalhes da mudança a ser completada.

A Mudança Normal é aquela que deverá seguir o processo inteiro do Gerenciamento de Mu-
dança e ainda serem categorizadas, de acordo com o risco e o impacto que exercerá sobre a
organização/negócio. Aquelas que forem categorizadas como médio ou alto, ainda deverão ser
revisadas pelo Comitê Consultivo de Mudanças25.
A ITIL® também informa sobre a possiblidade de predefinir modelos de mudança e aplica-los

apropriadamente na medida em que ocorrerem. Um Modelo de Mudança é uma forma de pré-
definir os passos que deverão ser executados para lidar com um tipo particular de mudança, de
maneira já acordada. As mudanças que requerem manuseio especializado podem ser tratadas
dessa forma, como mudanças emergenciais que possam ter autorizações diferentes, mudanças
no software do mainframe (que poderá precisar de sequências específicas de testes e imple-
mentação).
Aquelas mudanças maiores, que envolvem custo, risco ou impacto organizacional significativo,
geralmente serão inciadas pelo processo Gerenciamento do Portfólio de Serviço. Antes que o
serviço novo ou alterado seja contratado, é importante que a mudança seja revisada, buscando
visualizar o impacto sobre os demais serviços, por exemplo.
As propostas de mudanças (usada para comunicar uma descrição de alto nível da mudança)
são, então, submetidas ao gerenciamento de mudanças, para garantir que pontenciais conflitos
por recursos ou outros problemas sejam identificados. A autorização da proposta de mudança
não autoriza a implementação da mudança. Ela simplesmente permite que o serviço seja con-
tratado, então, assim, a atividade do desenho de serviço poderá ser iniciada. As propostas de
mudanças devem incluir:
 Descrição de alto nível do novo, alterado ou aposentado serviço;
 Caso de negócio completo, incluindo os riscos, problemas e alternativas, além das expectati-
vas financeiras/orçamento;
 Cronograma esquemático para o desenho e implementação da mudança.
Outro elemento muito importante é o Plano de Remediação. Nenhuma mudança poderá ser
autorizada se não houver explicitamente definido o quê fazer em caso de algum tipo de pro-
blema.
O Plano de Remediação deverá estar disponível para que, em caso de alguma delas vir a falhar,
a organização pode ser retornada ao seu estado normal, muitas vezes através do recarrega-
mento de um conjunto de itens de configuração de linha de base, especialmente software e
dados.
A remediação pode requerer uma revisitação da mudança propriamente dita (no evento da fa-
lha) ou poderá ser tão severa que precisará invocar o plano de continuidade de negócio da Or-
ganização.
25
Change Advisory Board (CAB). Corpo que existe para suportar a autorização de mudanças e auxiliar o processo na
avaliação, priorização e agendamento de mudanças.

3.4.2 Comitê Consultivo de Mudança

O Comitê Consultivo de Mudança (também conhecido como Comitê de Mudança) é um corpo
que existe para suportar a autorização de mudanças e auxiliar o Gerenciamento de Mudança na
avaliação, priorização e agendamento das mudanças.
Esse comitê se reúne regularmente para avaliar os impactos da mudança requisitada e planejar
a implementação da mudança, sob os pontos de vista do negócio e do cliente. Para fazerem
parte do comitê, as pessoas precisarão possuir um claro compreendimento das necessidades
das partes interessadas.
Alguns membros poderão ser permanentes, outros poderão ser convidados conforme necessá-
rio. Exemplos de participantes: Cliente, Gerente e representante dos usuários, Gerentes de re-
lacionamento de negócios, donos do serviço, especialistas técnicos, equipe de operações, forne-
cedores, etc. A composição das partes interessadas irá depender das mudanças que estão sen-
do consideradas.
3.4.3 Comitê Consultivo de Mudança Emergencial

Muitas vezes uma mudança emergencial surge e não há tempo para reunir o Comitê Consultivo
de Mudança inteiro. Dessa forma, é formado o Comitê Consultivo de Mudança Emergencial,
composto por menos pessoas, mas com autoridades para tomar decisões emergenciais.
É bom deixar claro que esse grupo possui as mesmas responsabilidades do anterior. A diferença
é a quantidade de pessoas envolvidas.
3.4.4 Atividades do Processo
 Planejamento e controle das mudanças;
 Agendamento da mudança e liberação (trabalhando com o processo Gerenciamento de Libe-

ração e Implantação, quando apropriado);
 Comunicações;
 Tomada de decisão e autorização de mudança;
 Garantir que planos de remediação estejam em vigor;
 Medição e controle;
 Relatórios de gestão;
 Entender o impacto da mudança;
 Melhoria contínua

Observe a seguir o ciclo de vida de uma Mudança Normal:
3.4.5 Interfaces com demais processos

Gerenciamento da Configuração e Ativo de Serviço: o sistema de gerenciamento da con-
figuração oferece acesso confiável, rápido e fácil à informações precisas de configuração. Isso
possibilita às partes interessadas e equipe, dentre outros benefícios, avaliar o impacto de mu-
danças propostas e registrar o fluxo de trabalho das mudanças.
Gerenciamento de Problema: outro processo importantíssimo, já que as mudanças são fre-

quentemente necessárias para implementar soluções de contorno e fixar erros conhecidos.
Gerenciamento da Continuidade de Serviço de TI: esse processo possui muitos planos e

procedimentos que devem ser atualizados via gerenciamento da mudança – para garantir que
sempre estejam precisos e atualizados. Assim, as partes interessadas estarão sempre alertas
sobre as mudanças.
Gerenciamento da Segurança da Informação: o gerenciamento de mudança realiza interfa-

ce com esse processo porque as mudanças requeridas pela segurança serão implementadas
através do gerenciamento de mudança – a segurança será um contribuinte chave para o Comi-
tê Consultivo de Mudança sobre os diversos serviços.
Gerenciamento da Capacidade: esse processo possui um papel importante em avaliar as

mudanças propostas – não somente as mudanças individuais mas o impacto total das mudan-
ças sobre a capacidade dos serviços.

Gerenciamento do Portfólio de Serviço: o processo prioriza as mudanças estratégicas e

submete as mudanças propostas para elas. Essas propostas de mudança serão entradas signifi-
cativas para o planejamento a longo prazo do cronograma de mudança e, também, será uma
entrada chave para ajudar o gerenciamento de mudança revisar e autorizar as requisições de
mudança relacionadas.
3.5 Gerenciamento de Liberação e Implantação
Propósito:
Planejar, agendar e controlar a construção, teste e implantação das liberações26, além de en-
tregar novas funcionalidades requeridas pelo negócio - protegendo a integridade dos serviços
existentes.
Objetivos:
 Definir e acordar sobre os planos de implantação com as partes interessadas da liberação;
 Criar e testar pacotes de liberação27; todos devem ser armazenados em uma Biblioteca de
Mídia Definitiva e registrados no Sistema de Gerenciamento do Conhecimento;
 Implantar os pacotes de liberação em ambiente de produção, seguindo o plano e cronograma

acordados;
 Garantir que todos os pacotes de liberação sejam registrados, instalados, testados, verifica-
dos e/ou desinstalados ou retirados, conforme o caso;
 Garantir que a mudança da Organização/Partes Interessadas seja gerenciada durante as

atividades do processo;
 Garantir que o serviço novo (ou alterado) atenda aos requisitos de utilidade e garantia;
 Registar quaisquer desvios, riscos e problemas relacionados aos serviços novos ou alterados,
além de tomar ações corretivas;
 Garantir que haja a transferência de conhecimento, de forma a permitir que clientes e usuá-
rios otimizem o uso dos serviços para suportar as suas atividades de negócio;
 Garantir que habilidades e conhecimentos sejam transferidos para as funções da Operação

de Serviço.
26
Itens de configuração (novos ou modificados), implantados no ambiente de produção como resultado de uma ou mais
mudanças.
27
Conjunto de ICs que será construído, testado e implantado ao mesmo tempo, como uma única liberação.

Escopo:
O escopo do Gerenciamento de Liberação e Implantação inclui os processos, sistemas e funções
para empacotar, construir, testar e implantar uma liberação em produção, estabelecer o serviço
no pacote de desenho de serviço e, formalmente, “passar a bola” para as funções da Operação
de Serviço. O escopo também inclui todos os itens de configuração que são necessários para
implementar a liberação.
O processo poderá gerar muito valor para a Organização, caso implantado corretamente. Entre
os benefícios, encontram-se: entrega de mudanças com menor risco e mais rápido, clientes e
usuários poderão utilizar os serviços certos de que suportam os objetivos de negócio, melhora a
consistência na implementação, etc.
O processo é composto por 4 fases. Vamos a elas:
 Planejamento da Liberação e Implantação: essa fase inicia com a autorização do Geren-

ciamento de Mudança para planejar uma liberação e finaliza com a autorização de mudança,
de forma a criar a liberação. Os planos para criação e implantação da liberação são criados
nessa fase.
 Liberação para construção e teste: durante essa fase, o pacote de liberação é construído,
testado e colocado na Biblioteca de Mídia Definitiva (se for software) ou simplesmente do-
cumentados. Essa fase irá ocorrer apenas uma vez durante qualquer liberação.
 Implantação: A fase inicia com a autorização de implantação do pacote de liberação, por

parte do Gerenciamento de Mudança, e finaliza com a “passagem do bastão” para as funções
da Operação de Serviço.
 Revisão e encerramento: a experiência obtida e todos os feedbacks são capturados, as

metas de performance e as conquistão são revisadas e, por fim, as lições são aprendidas. As
melhorias identificadas, tanto para o processo quanto da liberação, devem ser formalmente
capturadas e ações devem ser tomadas para ir de encontro a quaisquer problemas.
Um outro ponto importante sobre o processo são as Políticas de Liberação. Estas são indispen-
sáveis para o controle geral da liberação e implantação dentro do gerenciamento de serviço. Ao
especificar os requisitos que deverão ser gerenciados para qualquer liberação de serviço (ou
serviços), isso é colocado em documento que deverá ser controlado contra alterações e geren-
ciado como um ativo de serviço.

As políticas de liberação deverão ser definidas para cada serviço (ou grupo de serviços) e inclu-
em:
 Identificação única, descrição, convenções para os nomes e numerações para os diferentes

tipos de liberação;
 Os papéis e responsabilidades em cada estágio no processo;
 Requisitos de utilização dos softwares contidos na Biblioteca de Mídia Definitiva;
 A frequência esperada para cada tipo de liberação;
 A abordagem para aceitação e agrupamento das mudanças em liberações;
 Mecanismos para automatizar os processos de construção, instalação e distribuição da libe-

ração, para melhorar o reuso, repetibilidade e eficiência;
 Como a linha de base da configuração para a liberação será capturada e verificada contra os
conteúdos da liberação;
 Critério e autorização para ser entregue às funções de Operação de Serviço.
Importante entendermos que nem todas as mudanças irão precisar do gerenciamento de libe-
ração e implantação para as mesmas. Mudanças menores poderão ser gerenciadas pelo geren-
ciamento de mudança e atividades operacionais.
A liberação e implantação é usada para aquelas mudanças mais significativas e complexas e,

com isso, entrarão em cena as políticas contendo os requisitos que precisarão ser considerados
para que a implementação seja realizada com sucesso.

Capítulo 05 – Operação de
Entraremos agora em um
Serviço
dos principais estágios do
ciclo de vida do serviço: O- Objetivos do Capítulo
peração de Serviço (OS). Ao final desse capítulo você deverá ser
Após todo o trabalho reali- capaz de:
zado nos estágios anterio-
res, chega o momento em  Explicar e definir conceitos básicos rela-
que o cliente irá, de fato, cionados ao gerenciamento de serviço
perceber os benefícios do de TI relacionados à Operação de Ser-
viço.
serviço de TI contratado.
Então, nesse estágio, vere-  Entender os processos relacionados ao
mos questões relacionadas estágio em questão, cobrados no exa-
ao dia a dia do serviço – já me ITIL® Foundation, edição 2011.
em produção!
Sumário do Capítulo
Nesse capítulo iremos estu- 1 Tópicos do Exame _______________ 92

dar 05 processos do estágio
OS (sendo 02 deles de ma- 2 Introdução a Operação de Serviço __ 93
neira mais detalhada). As- 3 Funções________________________ 95
sim sendo, não custa nada
3.1 Gerenciamento Técnico: _________ 95
repetir: tudo aqui é impor-
tante e SERÁ cobrado no 3.2 Gerenciamento de Aplicações _____ 96
exame. Portanto, leia o capí- 3.3 Gerenciamento de Operações _____ 97
tulo, assista às vídeo-aulas
e, especialmente, faça resu- 3.4 Controle de Operações de TI ______ 97
mos com suas próprias pa- 3.5 Gerenciamento de Facilidades ____ 98
lavras. Assim, todo o conte-
3.6 Central de Serviços______________ 99
údo ficará mais claro para 3.6.1 Estruturas da Central de Serviços _ 100
você e, consequentemente, 3.6.1.1 Central de Serviços Local ______ 100
irá acertar todas as ques- 3.6.1.2 Central de Serviços Centralizada 101
tões referentes ao estágio 3.6.1.3 Central de Serviços Virtual_____ 102
no dia do exame. 4 Processos _____________________ 103
4.1 Gerenciamento de Incidente _____ 103
4.2 Gerenciamento de Problema_____ 107
Desejamos a todos bons es- 4.3 Gerenciamento de Evento _______ 111
tudos. 4.4 Cumprimento de Requisição _____ 112
4.5 Gerenciamento de Acesso _______ 113

1 Tópicos do Exame
 (ITIL®FND02-9) ciência do propósito, objetivos e escopo da operação de serviço.
 (ITIL®FND02-10) explicar qual o valor entregue pela operação de serviço ao negócio.
 (ITIL®FND03-24) evento.
 (ITIL®FND03-25) alerta.
 (ITIL®FND03-26) incidente.
 (ITIL®FND03-27) impacto, urgência e prioridade.
 (ITIL®FND03-28) requisição de serviço.
 (ITIL®FND03-29) problema.
 (ITIL®FND03-30) contorno.
 (ITIL®FND03-31) erro conhecido.
 (ITIL®FND03-32) banco de dados de erros conhecidos (BDEC).
 (ITIL®FND03-33) o papel da comunicação na operação de serviço.
 (ITIL®FND05) Processos
 explicar o propósito, objetivos, escopo, conceitos básicos, atividades de processo e

(ITIL®FND05-7)
interfaces para:
o (ITIL®FND05-71) gerenciamento de incidente.
o (ITIL®FND05-72) gerenciamento de problema.
 (ITIL®FND05-8) declarar o propósito, objetivos e escopo para:
o (ITIL®FND05-81) gerenciamento de evento.
o (ITIL®FND05-82) cumprimento de requisição.
o (ITIL®FND05-83) gerenciamento de acesso.
 (ITIL®FND06) Funções:
 (ITIL®FND06-1) explicar o papel, objetivos e estruturas organizacionais para:
o A função de central de serviços.
 (ITIL®FND06-2) declarar o papel e objetivos da:
o A função de gerenciamento técnico.

o A função de gerenciamento da aplicação com o desenvolmento de aplicação.
o A função de gerenciamento de operações de TI.

2 Introdução a Operação de Serviço
Propósito:
O propósito do estágio é coordenar e executar as atividades e processos necessários para en-
tregar e gerenciar os serviços nos níveis acordados com os usuários de negócio e clientes. O
estágio é também responsável pelo gerenciamento continuado da tecnologia que é usada para
entregar e suportar os serviços oferecidos.
Os processos que foram bem planejados e implementados serão inúteis caso a operação do dia
a dia não seja conduzida apropriadamente, controlada e gerenciada. Além disso, nem as melho-
rias nos serviços serão possíveis se não houverem atividades diárias para monitorar o desem-
penho, métricas de avaliação, etc.
A operação de serviço deve também garantir que o custo da entrega está dentro dos custos
operacionais que formaram parte caso de negócio original.
O próximo estágio do ciclo de vida do serviço, Melhoria Contínua de Serviço, dependerá das
informações que a OS ofererá, para que oportunidades de mudança possam ser identificadas,
linhas de base serem utilizadas e o sucesso de quaisquer melhorias poder ser medido.

Objetivos:
 Manter a satisfação e confiança do negócio para com a TI, através da entrega efetiva e efici-
ente e suporte aos serviços de TI acordados;
 Minimizar a quantidade e o impacto das interrupções nos serviços nas atividades diárias de
negócio;
 Controlar o acesso aos serviços de TI;
Escopo:
O escopo do estágio inclui “os processos, funções, organização e ferramentas” que são utiliza-
dos para entregar e suportar os serviços acordados. Dessa forma, a estágio inclui:
 Os serviços propriamente ditos: inclui todas as atividades necessárias para entregar os

serviços de maneira consistente, não importando se serão realizadas pelo provedor de servi-
ços, fornecedor externo ou usuário/cliente do serviço.
 Os processos de gerenciamento de serviço: o gerenciamento e execução contínuo dos

muitos processos de gerenciamento de serviço são realizados na operação de serviço. Inclui
todos os processos do estágio, ou seja, o estágio é responsável por executar as atividades
associadas com processos que se originaram em outros estágios.
 Tecnologia: todos os serviços possuirão uma coisa em comum: utilizam a tecnologia para
que possam ser entregues. Gerenciar a tecnologia não pode ser considerado como um pro-
blema separado, e sim parte integral do gerenciamento dos próprios serviços. Muito do que
estudaremos nesse estágio estará relacionado com o gerenciamento da infraestrutura onde
rodam os serviços.
 Pessoas: são as pessoas que direcionam a demanda para os serviços e produtos da organi-
zação e, além disso, são as pessoas quem decidem como isso será feito, além de gerenciar
todos os itens anteriores.
Ao selecionar e adotar as melhores práticas recomendadas pela Operação de Serviço resultará

em entrega de benefícios significativos para as organizações, como:
 Reduzir trabalhos não planejados e custos para ambos (negócio e TI), através manipulação
otimizada das interrupções de serviço. Isso permite ao negócio tomar vantagem do valor cri-
ado pelos serviços que estão recebendo.
 Oferecer resultados operacionais e dados que possam ser usados por outros processos da
ITIL® para melhorar a continuidade dos serviços e oferecer justificativa para o investimento
na melhoria contínua das atividades dos mesmos e tecnologias de suporte;
 Atender as metas e objetivos da política de segurança da organização, garantindo que os

serviços de TI serão acessados somente por aqueles autorizados;
 Oferecer rápido e efetivo acesso aos serviços padrão;
 Usar a tecnologia para automatizar tarefas rotineiras, reduzindo os custos e permitindo que
os recursos humanos sejam usados para trabalhos mais inovadores;
 Identificar melhorias e novas oportunidades.

3 Funções
No capítulo 1, estudamos que a ITIL® define “funções” como sendo um grupo de pessoas e ou-
tras ferramentas/recursos que são utilizados para executar um ou mais processos ou ativida-
des.
Agora veremos que a ITIL® descreve 4 funções principais, responsáveis por executar todos os
processos do ciclo de vida. As responsabilidades das funções que veremos devem ser atendi-
das, mas lembrando que a ITIL® não é prescritiva. Ou seja, cada organização terá a sua própria
estrutura e padrão com relação aos nomes.
3.1 Gerenciamento Técnico
Função necessária para gerenciar e desenvolver a infraestrutura de TI e suportar as operações

contínuas dos serviços de TI. A função cobre grupos ou equipes que, juntas, possuem a exper-
tise e conhecimentos necessários para garantir que a infraestrutura funcione eficientemente no
suporte aos serviços requeridos pelo negócio.
A função de Gerenciamento Técnico possui diversas responsabilidades:
 Gerenciar a infraestrutura de TI, incluindo garantir que os membros da equipe que estejam
realizando essa função possuam o conhecimento técnico necessário para o desenho, testes,
gestão e melhoria dos serviços de TI;
 Oferecer membros habilidosos para suportar o ciclo de vida inteiro de serviço, já que estarão
envolvidos no esboço da estratégia técnica e garantir que a infraestrutura consiga suportar a
estratégia geral de serviço.
 Uma vez o serviço em operação, a função oferece suporte técnico, resolução de incidentes,
investigação de problemas, resposta aos alertas28 e especificar quaisquer mudanças ou atua-
lizações requeridas para que o serviço opere eficientemente. A função trabalhará intensiva-
mente com o gerente de Melhoria Contínua de Serviço para desenhar, testar e implementar
melhorias nos serviços.
O gerente técnico deve decidir se é necessário empregar novos membros à equipe, com as ha-
bilidades necessárias, treinar os membros ou criar contratos de curto-prazo para atender um
requisito particular.
Lembre-se que a maioria das atividades de suporte operacionais do dia a dia serão tomadas
pelos membros de Operações (já estudaremos). Mas, é de responsabilidade do Gerenciamento
Técnico, como experts em tecnologia, guiar e suportar as operações dos membros da equipe.
28
A ITIL define “alerta” como sendo uma notificação de que um limiar foi atingido, algo ou falha ocorreram. Os alertas
são gerenciados pelo processo Gerenciamento de Evento.

Objetivos:
 Planejar, implementar e manter uma infraestrutura técnica estável para suportar os proces-
sos de negócio através:
1. Topologia técnica bem desenhada e altamente resiliente (não esquecendo do custo);
2. Uso adequado de habilidades técnicas para manter a infraestrutura técnica em condição

ótima;
3. Uso rápido de habilidades técnicas para diagnosticar e resolver quaisquer falhas técnicas
que possam ocorrer.
3.2 Gerenciamento de Aplicações
O Gerenciamento de Aplicações representa, para as aplicações de software, o que o Gerencia-

mento Técnico representa para a Infraestrutura. Importante destacar: O Gerenciamento de
Aplicações e o desenvolvimento de aplicações não são as mesmas coisas:

Objetivos:
 Identificar requisitos funcionais e de gerenciabilidade para as aplicações de software;
 Ajudar no desenho das aplicações;
 Auxiliar em seus desenvolvimentos;
 Suportar as aplicações no ambiente operacional;
 Identificar e implementar melhorias.
3.3 Gerenciamento de Operações
A finalidade da função Gerenciamento de Operações é executar as atividades do dia a dia que

são necessárias para entregar os serviços oferecidos. São as duas funções anteriores quem de-
finem quais atividades operacionais deverão ser tomadas, cada um em seu ramo. Assim sendo,
o Gerenciamento de Operações irá simplesmente executá-las.
O Gerenciamento de Operações também é responsável por garantir que os níveis de serviço

estabelecidos estejam sendo atingidos de maneira consistente. Embora o foco primário esteja
na estabilidade e disponibilidade, a função buscará continuamente a melhorá-las, implemen-
tando mudanças que ajudarão a proteger o serviço em operação ou reduzindo os custos e opor-
tunidades de erros humanos, implementando a automação de tarefas rotineiras.
Os objetivos do Gerenciamento de Operações de TI incluem oferecer serviços estáveis para que

o negócio possa obter os benefícios de negócio dos serviços. Enquanto isso, a função irá tam-
bém investigar possíveis melhorias, sempre com o intuito de oferecer os serviços da melhor
forma possível de custo-efetividade. A função poderá ser dividida em duas partes, as quais se-
rão estudadas a seguir.
3.4 Controle de Operações de TI
Supervisiona a infraestrutura de TI, através da execução das seguintes tarefas:
 Monitoramento centralizado e gerenciamento dos eventos de sistemas, algumas vezes cha-

mado de gerenciamento de console;
 Agendar e gerenciar os “batch Jobs” para executar tarefas de rotina, como atualizações nos
bancos de dados;
 Realizar backups dos dados e garantir que estes dados possam ser restaurados se e quando
for necessário;
 Controlar a distribuição de impressões de documentos (já que alguns documentos somente

poderão ser impressos em ambientes seguros por razões de confidencialidade, etc);
 Atividades de manutenção, sob orientação das funções de Gerenciamento Técnico e Gerenci-

amento de Aplicação. Inclui arquivar dados, atualizar os antivírus, etc.

3.5 Gerenciamento de Facilidades
Possui responsabilidade pelo ambiente físico da TI, ou seja, buscará:
 Garantir que a energia necessária esteja sendo oferecida (incluindo quaisquer requisitos para
sua qualidade, como prevenção contra quedas de energia);
 Operar e manter quaisquer nobreaks e geradores de energia. A função é responsável por

garantir que eles estejam disponíveis e garantir que irão funcionar conforme desenhados, no
caso de haver uma falha de energia;
 Garantir que a energia oferecida em qualquer lugar de recuperação de desastres possua a

proteção requerida contra falhas, garantindo a manutenção satisfatória de ar condiciona-
dos/resfriamento para as salas dos equipamentos de TI.

3.6 Central de Serviços
A Central de Serviços é uma unidade funcional que consiste de pessoas responsáveis por lidar
com uma variedade de atividades de serviço, geralmente realizada via chamadas telefônicas,
interface web ou através de eventos gerados automaticamente pela infraestrutura.
A função é aquela mais visível de todas, já que todos os dias realizam contato com os usuários
do negócio, em todos os níveis. Sua importância é tamanha que, caso haja uma Central de
Serviços ruim, isso poderá resultar em baixa impressão geral com o departamento de TI. Por
isso, a função deverá ser eficiente e focada no cliente.
Além do aspecto técnico, por lidar intensivamente com clientes, a equipe da Central de Serviços
deverá possuir habilidades apuradas de comunicação. Afinal de contas, quando os usuários li-
gam para a Central de Serviços eles esperam alguém apto a atender as suas necessidades. Por
isso, deve-se ter bastante atenção ao selecionar os indivíduos que farão parte da função.
O objetivo primário da função é oferecer um único ponto de contato para os usuários que preci-
sam de suporte. Dentre os serviços oferecidos, encontram-se:
 Manipulação de incidentes e buscando resolver o máximo possível dos mesmos, oferecendo

investigação e diagnóstico de primeira linha;
 Detém os incidentes que são escalados para outros grupos de suporte para a resolução;
 Relata os problemas para os membros da equipe de Gerenciamento de Problema;
 Manipula requisições de serviço (incluindo a verificação das requisições de software a serem

instaladas possuem licenças necessárias);
 Oferece informações aos usuários;
 Comunica-se com o negócio a respeito de incidentes maiores, próximas mudanças, etc;
 Gerencia requisições de mudança em nome do usuário, se necessário;
 Monitora incidentes e requisições de serviço em comparação com as metas no ANS e oferece

relatos da ferramenta de central de serviço para mostrar o nível atingido;
 Atualiza o sistema de gerenciamento da configuração, se necessário.
Entre os objetivos da função, encontram-se:
 Registrar todos os incidentes e requisições, com níveis apropriados de detalhes;
 Categorizar os incidentes e requisições para análises futuras;
 Acordar a prioridade com o usuário baseado no impacto e urgência;
 Investigar, diagnosticar e resolver incidentes sempre que possível;
 Decidir sobre o correto time de suporte para qual escalar o incidente quando a Central de
Serviços não puder resolver;
 Comunicar-se com os usuários;

 Confirmar o fechamento de incidentes resolvidos com os clientes;
 Executar pesquisas para verificar o nível de satisfação do usuário.
Uma boa Central de Serviços oferece diversos benefícios, entre eles:
 A percepção, satisfação e os serviços do cliente são melhorados;
 A acessibilidade é melhorada, através de um ponto único de contato, comunicação e infor-

mação;
 Melhor qualidade e eficiência com as requisições dos clientes e usuários;
 Impacto negativo com o negócio é reduzido;
 Melhor controle e gestão da infraestrutura;
 Informações de gerenciamento mais significativas para o apoio à decisão;
 Trabalho em equipe é aprimorado, além da questão da comunicação.
3.6.1 Estruturas da Central de Serviços

O tipo de estrutura dependerá do tamanho e da própria estrutura da organização. Muitas vezes
uma organização precisará implementar uma estrutura misturada dentre as disponíveis, de
forma a atender complementarmente às necessidades de negócio.
3.6.1.1 CENTRAL DE SERVIÇOS LOCAL
Nessa opção, a Central de Serviço é localizada junta com os usuários para os quais ela serve;
uma organização, por exemplo, com três escritórios, teria 3 Centrais de Serviços locais (em
cada escritório).
Como é local, a Central de Serviços entende as prioridades de negócio. Outro benefício é a me-
lhoria no quesito comunicação e o fator positivo tradicional: “a TI está por perto. Estamos segu-
ros!”. Aliás, como possui somente um ponto de contato, os usuários possuirão somente um
número para chamar (além de não estarem cientes de quaisquer outras Centrais que possam
existir).

Como desvantagem, podemos citar que essa estrutura é cara, já que cada novo escritório (no
nosso exemplo) requereria uma nova Central de Serviços. Isso também poderia levar a outra
desvantagem: em momentos mais calmos, os membros da equipe poderiam ficar muito ocio-
sos, esperando por chamadas (momento “rede social”).
3.6.1.2 CENTRAL DE SERVIÇOS CENTRALIZADA
A Central de Serviços Centralizada é a mais comum de todas, já que são mais custo-efetivas.
Nesse modelo, existe apenas uma Central de Serviços para toda a organização, independente
do número de localidades físicas que ela atende. Pode-se deduzir que, com essa estrutura, toda
a infraestrutura encontra-se em um local físico diferente da localização dos usuários dos servi-
ços.

3.6.1.3 CENTRAL DE SERVIÇOS VIRTUAL
Essa opção consiste de duas ou mais Centrais de Serviços operando como uma só. As chama-
das e emails são distribuídas pelos membros da equipe como se estivessem em uma localização
centralizada. Isso garante que carga de trabalho seja balanceada. A vantagem principal da Cen-
tral de Serviços Virtual é a resiliência: quando uma localização fica off-line por qualquer motivo,
o serviço continuará a rodar sem praticamente qualquer impacto.
Siga o Sol (Follow The Sun)
Empresas que possuem locais de atendimento espalhados pelo mundo podem oferecer suporte
24h por dia através desse tipo de estrutura29. Em vez da matriz (por exemplo) 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. É importante que todas as Centrais de Serviço trabalhem
segundo os mesmos processos e ferramentas (além de uma base única de informações).
29
Na verdade, a “Siga o Sol” é uma forma de central de serviços virtual; a diferença está na alocação de chamadas.
Nessa estrutura, as chamadas são alocadas conforme a hora do dia (ao contrário da alocação baseada na carga de tra-
balho).

4 Processos
4.1 Gerenciamento de Incidente
A ITIL® define “incidente” como uma interrupção não planejada nos serviços de TI, redução na
qualidade dos mesmos ou uma falha de um IC que ainda não impactou um serviço de TI.
Propósito:
Restaurar a operação normal de um serviço o mais rápido possível e minimizar o impacto des-
favorável sobre as operações do negócio e, ainda, garantir que os acordados níveis de qualida-
de de serviço sejam mantidos.
É importante notar que a resolução de um incidente não necessariamente inclui entender o

porquê de ter ocorrido tal falha ou prevenir a sua recorrência; veremos mais para a frente que
isso é responsabilidade do Gerenciamento de Problema.
Objetivos:
 Garantir que métodos padronizados e procedimentos sejam usados para obter respostas de
maneira e rápida, análises, documentações, gerenciamento contínuo e relatos de inciden-
tes;
 Aumentar a visibilidade e comunicação dos incidentes para o negócio e equipe de suporte

de TI;
 Melhorar a percepção do negócio para com a TI, através do uso de uma abordagem profis-
sional na rápida resolução e comunicação de incidentes;
 Alinhar as atividades de Gerenciamento de Incidente com aquelas do negócio;
 Manter a satisfação do usuário com a qualidade dos serviços de TI.
Escopo:
O escopo do processo engloba todos os eventos que interrompe (ou poderia interromper) um
serviço. Isso inclui também os eventos que são comunicados diretamente pelos usuários (tanto
pela Central de Serviços, ferramentas de gerenciamento de incidentes quanto por uma interface
pelo Gerenciamento de Evento).
Mas, vale destacar que nem todos os eventos são incidentes. Muitas classes de eventos não
estão relacionadas a interrupções, mas são indicadores de operação normal ou simplesmente
informacionais.
É importante ressaltar que todos os incidentes deverão ser resolvidos o mais rá-
pido possível. Mas, é claro, alguns incidentes podem ser mais sérios do que ou-
tros (exercendo maior impacto ao negócio). Esses são considerados como “inci-
dentes maiores”. Deverá ser acordado o que será caracterizado como tal.

Atividades:
 Identificação do incidente: O processo é reativo; não conseguimos iniciar a resolver um
incidente até que nós saibamos que o mesmo tenha ocorrido. Quando possível, deve-se tentar
descobrir que um incidente ocorreu antes mesmo do usuário notar ou, até que o mesmo ligue
para a Central de Serviços.
 Registro do incidente: O registro de incidente contém todas as informações relacionadas a

um incidente particular. Os detalhes dos sintomas e o equipamento afetado pode ser utiliza-
do pelo Gerenciamento de Problema, inclusive. Portanto podem ser incluídas diversas infor-
mações sobre para cada incidente, como a categorização do mesmo, sua urgência, impacto,
priorização, data/hora do registro, descrição dos sintomas, status do incidente, IC relaciona-
do, data/hora do fechamento, etc.
 Categorização do incidente: Os incidentes são categorizados durante a etapa de registro.

Isso pode ser muito útil para guiar o agente da Central de Serviços para a correta entrada de
erro conhecido ou equipe de suporte apropriado para a escalação. Um esquema multinível a-
tinge granularidade sem fazer com o que o agente da Central de Serviços se depare com
uma longa lista para escolher.
 Priorização do incidente: os incidentes precisam ser priorizados para garantir que aqueles
considerados mais críticos sejam resolvidos primeiro. Nas negociações dos níveis de serviço
serão definidos os critérios que deverão ser usados para decidir sobre a prioridade. A ITIL® re-
comenda que dois fatores sejam considerados: impacto no negócio e urgência.
 Diagnóstico inicial: refere-se às ações tomadas na Central de Serviços para diagnosticar a

falha e, quando possível, resolvê-la. Os agentes da Central de Serviços utilizarão o Banco de
Dados de Erros Conhecidos oferecidos pelo gerenciamento de problema, modelos de incidentes,
quaisquer outras ferramentas de diagnóstico e possíveis resoluções. Quando a Central de Servi-
ços não puder resolver o incidente, o diagnóstico inicial identificará a equipe de suporte apro-
priada para a escalação.
 Escalação do incidente: A ITIL® define dois tipos de escalação que poderá ocorrer dentro
do GI: Escalação Funcional e Escalação Hierarquica.

A escalação funcional acontece quando a Central de Serviços não consegue resolver o inciden-
te; isso poderá ser realizado imediatamente devido ao tipo do incidente ou devido ao agente da
Central de Serviços já ter passado o máximo de tempo permitido tentando resolver o incidente
sem sucesso.
Logo, deverá ser passado para outro grupo com nível maior de conhecimento. A Central de
Serviços deverá saber o grupo correto para escalar o incidente, para evitar atrasos desnecessá-
rios. Os acordos de nível operacional especificarão as responsabilidades de cada grupo.
Note que: o incidente ainda é de propriedade da Central de Serviços. Os incidentes podem ser
escalados, mas a Central de Serviços retém a propriedade dos mesmos, registrando o progres-
so, mantendo os usuários informados e obtendo o acordo do usuário para o seu eventual fe-
chamento.
A escalação hierárquica acontece na existência de incidentes maiores ou de alta prioridade. Es-

sa escalação consiste em informar o nível apropriado de gerenciamento sobre o incidente, para
que estejam cientes. Isso garante ao gerenciamento a propriedade de tomar decisões que são
necessárias com relação a priorização do trabalho, envolver fornecedores, etc.
 Investigação e Diagnóstico: Esse passo buscará tentar verificar o quê aconteceu e como o
incidente poderá ser resolvido. O registro de incidente deve ser atualizado para registar
quais ações foram tomadas, bem como deverá ser fornecida uma criteriosa descrição dos
sintomas – tudo com o intuito de evitar o retrabalho.
 Resolução e Recuperação: As resoluções de incidentes potenciais deverão ser testadas

para garantir que elas de fato resolvem o problema completamente (sem consequências não
intencionadas). Esse teste poderá até mesmo envolver o usuário. Outras ações de resolução
podem incluir que o agente da Central de Serviços ou técnico logue-se remotamente no e-
quipamento do usuário para implementar a resolução ou mostrar para o usuário o que fazer
no futuro. Uma vez resolvido, o incidente retorna para a Central de Serviços para ser fecha-
do.
 Fechamento do Incidente: Quando o incidente for resolvido e o serviço restaurado, a Cen-

tral de Serviços contactará o usuário para verificar se o incidente poderá ser fechado. Esse é
um passo importante, porque a falha pode parecer solucionada para o departamento de TI,
mas o usuário poderá ainda enfrentar dificuldades. A categoria associada ao incidente tam-
bém deverá ser revista.
Interfaces
Segue abaixo alguns exemplos de interfaces com o Gerenciamento de Incidente, para cada es-
tágio do ciclo de vida de um serviço:
 Desenho de Serviço
 Gerenciamento de Nível de Serviço – A habilidade de resolver incidentes em um tem-

po especificado é parte chave para entregar um nível de serviço acordado. O GI possibilita
ao GNS definir respostas mensuráveis às interrupções dos serviços. Além disso, oferece
relatos que possibilitam ao mesmo processo revisar os ANSs de maneira objetiva e regu-
lar.
 Gerenciamento de Segurança da Informação - O processo oferece informações dos

incidentes relacionados à segurança, conforme necessário para suportar as atividades do
desenho de serviço.

 Gerenciamento da Capacidade - O processo oferece um gatilho para o monitoramento

de desempenho onde parece ter um problema relacionado a desempenho. O gerencia-
mento da capacidade poderá desenvolver soluções de contorno30 para os incidentes.
 Gerenciamento da Disponibilidade - O gerenciamento da disponibilidade utilizará os

dados do gerenciamento de incidente para determinar a disponibilidade dos serviços de TI
e verificar o ciclo de vida do incidente, em busca de melhorias.
 Transição de Serviço
 Gerenciamento da Configuração e Ativo de Serviço – Esse processo oferece dados

usados para identificar e progredir com os incidentes. O gerenciamento de incidente tam-
bém poderá auxiliar esse processo em auditar a infraestrutura quando estiver trabalhando
para resolver um incidente.
 Gerenciamento de Mudança - Onde uma mudança é requerida para implementar uma

solução de contorno ou resolução, precisará estar registrado como uma requisição de mu-
dança e progredida pelo gerenciamento de mudança. Assim, o GI poderá detectar e resol-
ver incidentes que surgem de mudanças contendo falhas.
 Operação de Serviço
 Gerenciamento de Problema – Para alguns incidentes, será apropriado envolver o GP

para investigar e resolver a causa raiz, de forma a prevenir ou reduzir o impacto da recor-
rência. O GI fornece um ponto onde essas informações são reportadas. Por outro lado, o GP
oferece erros conhecidos para resolução mais rápida, através de soluções de contorno que
poderão ser usadas para restaurar o serviço.
 Gerenciamento de Acesso – Muitos incidentes surgem quando foram detectadas tentati-

vas de acesso não autorizados ou brechas de segurança são detectadas. Um histórico dos
incidentes deverá ser mantido para suportar atividades de investigação e resolução de vio-
lações de acesso.
30 Redução ou eliminação do impacto de um incidente ou problema para o qual uma resolução completa ainda não
está disponível

4.2 Gerenciamento de Problema
A ITIL® define “problema” como sendo a causa subjacente de um ou mais incidentes. Sendo
assim, o processo irá investigar a causa dos incidentes e, sempre que possível, implementar
uma solução permanente para prevenir a recorrência. Até que uma solução permanente não
seja aplicada, o processo também tentará oferecer uma solução de contorno para permitir que
os serviços sejam restaurados e o incidente seja resolvido.
Propósito:
O processo possui como propósito gerenciar o ciclo de vida de todos os problemas. O processo
busca minimizar o impacto adverso dos incidentes e problemas sobre o negócio que são causa-
dos por erros dentro da infraestrutura, além de prevenir a recorrência dos incidentes relaciona-
dos a tais erros. Logo, para que isso seja de fato uma realidade, o processo vai buscar a causa
raiz dos incidentes, documentar e comunicar os erros conhecidos e promover ações para me-
lhorar ou corrigir a situação.
Objetivos:
 Atuar na prevenção dos problemas e de incidentes resultantes;
 Buscará eliminar os incidentes recorrentes;
 Minimizar o impacto dos incidentes que não poderão ser prevenidos.
Escopo:
Fazem parte do escopo do processo todas as atividades necessárias para diagnosticar a causa
raiz dos incidentes e determinar a resolução para esses problemas. Além disso, o processo é
responsável para garantir que a resolução permanente seja implementada através de procedi-
mentos de controle apropriados. O gerenciamento de problema possui forte interface com o
gerenciamento do conhecimento, pois o primeiro manterá informações sobre problemas e suas
resoluções/soluções de contorno.
Ao contrário do Gerenciamento de Incidentes, o Gerenciamento de Problemas possui aspectos

proativos e reativos. As atividades de ambos buscam levantar problemas, gerenciá-los pelo
processo em questão, encontrar a causa raiz dos incidentes que estão associados e prevenir
recorrências futuras dos incidentes. A diferença entre ambos está em como o processo é dispa-
rado:
 Com o gerenciamento de problema reativo, as atividades do processo serão geralmente dis-

paradas em reação a um incidente que surgira. O Gerenciamento de Problema reativo com-
plementa as atividades do Gerenciamento de Incidente, focando-se na causa raiz de um in-
cidente para que o mesmo não torne a repetir, além de identificar soluções de contorno
quando apropriado;
 Com o gerenciamento de problema proativo, as atividades do processo são disparadas pelas

atividades que estão buscando melhorar os serviços. Um exemplo pode ser as atividades de
análise de tendências, que busca encontrar causas comuns de incidentes históricos, para
prevenir sua recorrência. O Gerenciamento de Problema proativo complementa as atividades
do estágio melhoria contínua de serviço, ajudando a identificar soluções de contorno e ações
de melhoria que poderão melhorar a qualidade do serviço.
Pode ser necessário também utilizar Modelos de Problema para manipular os problemas que
não foram (e não irão) ser resolvidos, devido ao custo ou risco ser muito grande ou porque a
tecnologia está prestes a mudar. Esses modelos são muito parecidos com os Modelos de Inci-
dentes que vimos a pouco, ou seja, lá irão conter os passos que deverão ser tomados.

Veja a seguir o fluxo do processo para manipular um problema conhecido:
 Detecção de problemas: o primeiro passo no processo é identificar que um problema exis-

te. Dessa forma, não há muitos detalhes a respeito disso.
 Registrar os problemas: tendo identificado a existência do problema, o segundo passo do

processo irá registrar o problema. O registro deve conter todas as informações relevantes ao
mesmo. Quando possível, a ferramenta de gerenciamento de serviço deve ser usada para
linkar os registros de problema com os registros de incidentes relacionados. Os detalhes do
incidente precisam ser copiados para o registro de problema.
 Categorização do problema: os problemas devem ser categorizados da mesma forma que

os incidentes. Para que o provedor de serviços consiga identificar as tendências nos inciden-
tes é indispensável que haja a precisa e consistente categorização dos incidentes. Se todo
analista da Central de Serviços categorizar a mesma falha de maneira diferente, será muito
difícil discernir uma tendência. Dessa forma, o gerente de problema deverá enfatizar a im-
portância da categorização correta.
 Priorização do problema: da mesma forma que os incidentes, a prioridade de um proble-

ma deve ser baseada no impacto oferecido pelo incidente ao negócio e a urgência que preci-
sará ser resolvido. O gerente de problema também precisa ficar atento sobre a frequência
dos incidentes. Por exemplo, uma tela “congelada” na máquina do usuário pode ser fácil de
ser resolvido – bastaria dar um “reboot” na máquina; mas, caso isso ocorra 100 vezes por
dia, o impacto ao negócio poderá ser cruel. Dessa forma, o problema precisará ser alocado
com alta prioridade.
 Investigação e diagnóstico do problema: o passo seguinte é investigar e diagnosticar o

problema. Poderá não haver recursos para se investigar cada problema, então, o nível de
prioridade irá estabelecer qual deles ganhará a necessária atenção. A ITIL® sugere algumas
técnicas para solução de problemas. O sistema de gerenciamento da configuração poderá ser
muito útil em oferecer informações sobre os itens de configuração para ajudar a identificar a
causa subjacente. Poderá ser muito vantajoso identificar o ponto de falha, onde vários inci-
dentes são reportados; o sistema de gerenciamento da configuração poderá identificar que
todos os itens de configuração afetados estão linkados a um mesmo item de configuração. O
banco de dados de erros conhecidos poderá também oferecer informações sobre problemas
similares anteriores e suas causas.
 Identificar uma solução de contorno: embora o objetivo do processo seja encontrar a

causa raiz, isso poderá levar tempo. Quando um usuário sofre um incidente, a primeira prio-
ridade é restaurar o serviço para que ele possa continuar trabalhando. Sendo assim, uma
prioridade do processo é oferecer uma solução de contorno para o problema, até que o
mesmo seja resolvido.
 Levantamento de um Registro de Erro Conhecido: quando o processo identificou e do-

cumentou a causa raiz e contorno, essa informação é disponibilizada para a equipe de supor-
te como um “erro conhecido31”. As informações sobre todos os erros conhecidos, incluindo o
registro de problema relacionados, são mantidas no Banco de Dados de Erro Conhecido. Ao
repetir o incidente, a equipe de suporte vai ao banco em busca da solução de contorno. Mui-
tas vezes a solução de contorno existe, mas a causa raiz ainda não. E, outras vezes, pode-se
conhecer a causa raiz, mas não a solução de contorno não – pois uma mudança, por exem-
plo, precisaria ser implantada para corrigir a falha.
31 Um problema que possui causa raiz e solução de contorno documentadas

 Resolução do problema: quando o processo identificou a solução do problema, essa deve-

rá ser implementada para resolver a falha e prevenir futuros incidentes. Implementar a reso-
lução poderá envolver um nível de risco, assim sendo, o processo Gerenciamento de Mudan-
ça garantirá que a avaliação do risco e impacto da requisição de mudança é satisfatória, an-
tes de permitir a mudança.
 Fechamento do problema: quando uma solução permanente tiver sido identificada, testa-
da e implementada através do processo Gerenciamento de Mudança, o registro de problema
pode ser atualizado e fechado. O banco de dados de erros conhecidos também deverá ser
atualizado.
 Revisão dos problemas maiores: cada organização deve definir o que constitui um pro-
blema maior. Uma vez um problema maior tenha sido resolvido, uma revisão deverá ser rea-
lizada para identificar quaisquer lições que possam ser aprendidas do que ocorrera.
O processo realiza interfaces com outros processos. Vejamos:
 Estratégia de Serviço
 Gerenciamento Financeiro para Serviços de TI: o Gerenciamento de Problema usa

esse processo para auxiliar o impacto financeiro das possíveis soluções ou soluções de
contorno. Com a informação em questão, pode-se decidir se a resolução permanente é
financeiramente justiçável.
 Desenho de Serviço
 Gerenciamento da Disponibilidade: as atividades proativas empreendidas pelo pro-

cesso são diretamente relacionadas com o gerenciamento de problema proativo; a dis-
ponibilidade tenta, de maneira proativa, identificar riscos que poderiam resultar em per-
da de um serviço e tomar ações preventivas. O gerenciamento de problema consegue
fornecer informações ao Gerenciamento da Disponibilidade sobre o sucesso de quaisquer
medidas tomadas.
 Gerenciamento da Capacidade: alguns problemas de desempenho podem ser causa-

dos por problemas de capacidade. O processo estará envolvido na resolução desses pro-
blemas e, também, tomando medidas proativas para prevenir problemas de capacidade.
O gerenciamento de problema poderá oferecer informações úteis sobre o sucesso das
medidas tomadas.
 Gerenciamento da Continuidade de Serviço de TI: quando um problema significante

está causando ou causará interrupção maior ao negócio, poderá ser necessário invocar o
plano de gerenciamento da continuidade de serviço de TI, até que a questão seja resol-
vida. O processo também tenta, proativamente, identificar riscos que poderiam resultar
em uma perda de serviço maior e tomar ações preventivas.
 Gerenciamento de Nível de Serviço: as ações do gerenciamento de problema pode-

rão ser reportadas nas revisões de serviço e, além disso, poderão formar parte do plano
de melhoria de serviço.

 Transição de Serviço
 Gerenciamento de Mudança: o gerenciamento de problema dependerá da informa-

ção do gerenciamento de mudança para saber se determinada mudança fora imple-
mentada com sucesso. Além disso, ambos os processos realizam interface quando
mudanças introduzem problemas ou causam incidentes.
 Gerenciamento da Configuração e Ativo de Serviço: O sistema de gerenciamento

da configuração oferece informações essenciais ao gerenciamento de problema: iden-
tificar os itens de configuração com falhas. Além disso, o sistema consegue identificar
o impacto de um problema, já que mostra as dependências para cada item de confi-
guração.
 Gerenciamento de Liberação e Implantação: quando uma mudança para resolver

uma falha é aprovada, o processo irá implementá-la no ambiente de produção. Assim,
o processo é responsável por garantir que quaisquer erros conhecidos entrem para o
Banco de Dados de Erros Conhecidos. Além disso, o processo possui interface com o
gerenciamento de problema quando liberações introduzem problemas ou causam in-
cidentes.
 Gerenciamento da Configuração: o Banco de Dados de Erros Conhecidos é uma

entrada essencial para a transferência do conhecimento; o Sistema de Gerenciamento
do Conhecimento de Serviço poderá armazenar os registros de problema e o banco de
dados de erros conhecidos.
 Melhoria Contínua de Serviço
 Processo de Melhoria de 7 Passos: ambos os processos buscam eliminar os erros

e melhorar a qualidade de serviço. As ações identificadas para resolver um problema
(ou preveni-lo) pode ser registrada no registro de melhoria contínua de serviço. O
Processo de Melhoria de 7 Passos pode ser usado pela melhoria contínua de serviço
ou pelo Gerenciamento de Problema para identificar e resolver problemas subjacen-
tes.

4.3 Gerenciamento de Evento
Propósito:
Gerenciar os eventos por todo o ciclo de vida dos mesmos. Esse ciclo de vida de atividades para
detectar eventos, entende-los e determinar a ação de controle apropriada é coordenada pelo
processo.
A ITIL® define “evento” como sendo qualquer mudança de estado que possua significado para o
gerenciamento de um item de configuração ou serviço de TI. Ou seja, de cara já percebemos
que se trata de uma coisa séria – não é qualquer coisa. Geralmente são reconhecidos através
de notificações criadas por um serviço de TI, item de configuração ou ferramenta de monitora-
mento. Fique ligado(a) para a diferença entre Evento e Alerta.
Enquanto o primeiro significa qualquer ocorrência que possa ser detectada e que possua signifi-
cado para a gerência da infraestrutura de TI ou para a entrega de serviço, o Alerta é um sub-
produto do evento, ou seja, deriva da monitoração dos eventos. Perceba pela imagem abaixo
que um Alerta poderá virar um incidente ou apenas um registro.
Objetivos:
 Detectar todas as mudanças de estado que possua significância para o gerenciamento de um
item de configuração ou serviço de TI;
 Determinar a ação de controle apropriada para os eventos e garantir que eles sejam comuni-
cados para as funções apropriadas;
 Oferecer o gatilho, ou ponto de entrada, para a execução de muitos processos da Operação

de Serviço e atividades do gerenciamento de operações;
 Oferecer meios para comparar o desempenho operacional de fato e comportamento contra

os padrões de desenho e Acordos de Nível de Serviço;

Escopo:
O processo pode ser aplicado a qualquer aspecto do gerenciamento de serviço que precise ser
controlado e que possa ser automatizado. Isso inclui:
 Itens de Configuração
 Alguns serão incluídos porque precisam permanecer em um estado constante (ex: de-
terminado switch na rede precisa estar sempre “on”. Dessa forma, as ferramentas de Ge-
renciamento de Eventos podem ser utilizadas para confirmar isso, monitorando através de
“pings”). Já outros serão incluídos porque seus status precisam ser alterados com fre-
quência e o processo pode ser usado para automatizar essa necessidade e, em seguida,
atualizar o Sistema de Gerenciamento da Configuração (ex: atualização de um um servi-
dor de arquivos);
 Condições ambientais (ex: detecção de fogo/fumaça);
 Monitoramento de licença de software para uso, de forma a garantir utilização e alocação

ótima/legal da licença;
 Segurança (ex: detecção de intrusão);
 Atividade normal (ex: registrar o uso de uma aplicação ou a performance de um servidor).
4.4 Cumprimento de Requisição
Propósito:
O propósito do processo é gerenciar o ciclo de vida todas as requisições de serviço dos usuá-
rios. Ou seja, o processo vai lidar com as requisições dos usuários (informações, conselhos,
mudança padrão, etc) em relação aos serviços de TI. O Cumprimento de Requisição foca-se em
oferecer um contorno para todas essas requisições (claro, tomando o cuidado de quaisquer ne-
cessidades de autorização). O intuito é atender aos desejos dos usuários com o mínimo de bu-
rocracia possível.
Objetivos:
 Manter a satisfação do usuário/cliente através da manipulação eficiente e profissional de to-
das as requisições de serviço;
 Oferecer um canal para que os usuários possam requisitar e receber serviços padrão, para os
quais uma autorização pré-definida e processo de qualificação já exista;
 Oferecer informações aos usuários/clientes sobre a disponibilidade dos serviços e os proce-

dimentos para obtê-los;
 Originar e entregar os componentes dos serviços padrão requisitados (ex: licenças e mídia
de software);
 Auxiliar com informações gerais, reclamações ou comentários.

Escopo:
O escopo do processo irá variar de organização para organização. Entretanto, a lógica sempre
será a mesma: cada requisição deve ser “quebrada” em atividades acordadas, com procedi-
mentos documentados. Algumas organizações utilizam o processo gerenciamento de incidente
para manipular as requisições (embora hoje isso seja menos comum).
Em organizações onde haja grandes volumes de requisições e onde as ações a serem tomadas
sejam muito variadas ou especializadas, pode ser interessante um processo completamente
separado para lidar com essa carga de trabalho – e, além disso, para registrar e gerenciá-las
como um tipo de registro separado. Isso fica a critério da organização.
4.5 Gerenciamento de Acesso
Propósito:
Oferecer direitos aos usuários, de forma a poder usar um serviço ou grupo de serviços. Ou seja,
o processo irá executar as políticas e ações que foram definidas no processo Gerenciamento da
Segurança da Informação. O processo pode ser iniciado por uma requisição de serviço e é exe-
cutado pelas funções gerenciamento técnico e gerenciamento de aplicação.
Objetivos:
 Gerenciar o acesso aos serviços, baseados nas políticas e ações definidas no Gerenciamento
da Segurança da Informação;
 Responder eficientemente às requisições para concessão de acesso aos serviços, alteração

dos direitos de acesso ou restrição de acesso. O intuito é garantir que os direitos sendo ofe-
recidos ou alterados sejam concedidos apropriadamente;
 Vigiar o acesso aos serviços e garantir que os direitos que estão sendo oferecidos não este-
jam sendo utilizados de maneira imprópria.
Dessa forma, fazem parte do escopo a execução daquilo que fora estabeleci-
do no Gerenciamento da Segurança da Informação, além de garantir que aos
usuários o direito de usar um serviço. Mas, é importante ressaltar: isso não
garante que esse acesso esteja disponível em todos os momentos acordados
– isso é assunto do Gerenciamento da Disponibilidade.
Escopo:
O escopo do processo está relacionado a execução eficiente das políticas do processo Gerenci-
amento da Segurança da Informação. Executando tais políticas, a confidencialidade, disponibili-
dade e integridade dos dados e a propriedade intelectual da organização estarão protegidos.
Confidencialidade aqui significa que somente usuários autorizados poderão ter acesso aos da-
dos (visualizá-los). Integridade significa que os dados não deverão estar corrompidos ou terem
sido alterados inapropriadamente.
O processo garantirá que o serviço se encontrará disponível para aqueles usuários considerados
autorizados; mas isso não garante que o serviço estará sempre disponível durante o período
estabelecido – isso é responsabilidade do processo Gerenciamento da Disponibilidade.

Capítulo 06 – Melhoria Con-

Chegamos ao último estágio tínua de Serviço
do ciclo de vida do serviço;
bem como ao último capítu-
Objetivos do Capítulo
lo do nosso curso. Agora
iremos estudar como a ITIL Ao final desse capítulo você deverá ser
busca lidar com as necessi- capaz de:
dades constantes de mu-
danças nos negócios. Aqui
veremos diversos tópicos  Explicar e definir conceitos básicos rela-
cionados ao gerenciamento de serviço
muito importantes que, cer- de TI relacionados à Melhoria Contínua
tamente, estarão (alguns) de Serviço.
incluídos no exame ITIL
Foundation que você, em  Entender os processos relacionados ao
breve, irá realizar. estágio em questão, cobrados no exa-
me ITIL® Foundation, edição 2011.
Nesse capítulo iremos estu-

dar apenas 1 processo – Sumário do Capítulo
sendo assim, o estudo não
será tão cansativo quanto
alguns estágios anteriores. 1 Tópicos do Exame ______________ 115
Após a leitura da apostila 2 Melhoria Contínua de Serviço _____ 116
(além da vídeo-aula), bus-
que efetuar um resumo da 3 O Ciclo de Deming ______________ 119
mesma, destacando os pon- 4 Indicador Chave de Performance e Fator
tos chave do estágio. Não Crítico de Sucesso __________________ 120
deixe de fazer os exercícios
pois eles serão o “termôme- 5 O Processo de Melhoria de 7 Passos 121
tro” que você utilizará de 6 Conclusão _____________________ 125
base para ver se está (ou
não) preparado para o e-
xame.
Desejamos a todos bons es-

tudos.

1 Tópicos do Exame
 (ITIL®FND02-11) ciência do propósito, objetivos e escopo da melhoria contínua de serviço.
 (ITIL®FND02-12) explicar qual o valor entregue pela melhoria contínua de serviço ao negócio.
 (ITIL®FND03-38) registro (registrador) de melhoria contínua de serviço.
 (ITIL®FND03-42) O ciclo de Deming.
 (ITIL®FND04) Princípios chave e modelos:
 (ITIL®FND04-9) explicar a abordagem de melhoria contínua de serviço.
 entender o papel da medição para a melhoria contínua de serviço e explicar os se-

(ITIL®FND04-10)
guintes elementos chave:
o Relacionamento entre fatores críticos de sucesso e indicadores chave de performance.
o Linhas de base.
o Tipos de métricas (tecnologia, processo e serviço).
 (ITIL®FND05) Processos:
 (ITIL®FND05-9) indicar o propósito, objetivos e escopo para:
o (ITIL®FND05-91) O processo de melhoria de 7 passos.

2 Melhoria Contínua de Serviço

Propósito:
O propósito da Melhoria Contínua de Serviço é alinhar os serviços de TI com as necessidades
constantes de mudança do negócio, identificando e implementando melhorias nos serviços de
TI que suportam os processos de negócio.
As atividades de melhoria suportam a abordagem em ciclo de vida, ou seja, é executada por

todos os estágios da ITIL®. O estágio está sempre em busca de melhorar efetividade dos servi-
ços, dos processos e do custo.
Objetivos:
 Revisar, analisar, priorizar e fazer recomendações sobre oportunidades de melhoria em
cada estágio do ciclo de vida de um serviço;
 Revisar e analisar as os níveis de serviço atingidos;
 Identificar e implementar atividades específicas para melhorar a qualidade dos serviços de

TI e, além disso, melhorar a eficiência e efetividade dos processos habilitadores;
 Melhorar a efetividade dos custos da entrega dos serviços de TI, sem sacrificar a satisfação
do cliente;
 Garantir que sejam utilizados métodos aplicáveis de gerenciamento da qualidade, para su-
portar as atividades de melhoria contínua;
 Garantir que processos possuam objetivos claros, bem definidos, além de medidas que le-
vam a melhorias acionáveis;
 Entender o quê medir, o porquê está sendo medido e qual o resultado está sendo esperado.
Escopo:
 Saúde geral do Gerenciamento de Serviços de TI, como uma disciplina;
 Alinhamento contínuo do portfólio de serviço com as necessidades atuais e futuras do ne-

gócio;
 Maturidade e capacidade da organização, gerenciamento, processos e pessoas utilizadas

pelos serviços;
 Melhoria contínua de todos os aspectos do serviço de TI e os ativos de serviço que os su-

portam.

Ao selecionar e adotar as melhores práticas do estágio, as organizações poderão entregar di-
versos benefícios significativos. O estágio não investiga somente os processos e os serviços que
esses suportam, como também analisa todos os elementos que permitem a entrega dos servi-
ços ao negócio. Isso inclui todos os recursos, parceiros, tecnologia, habilidades da equipe, trei-
namento e comunicação.
É importante ressaltar que tudo isso pode ser conseguido através do monitoramento e relatos
sobre desempenhos por todo o portfólio de serviço. Para que, daí, possam ser identificadas o-
portunidades de melhoria.

A figura a seguir mostra a abordagem geral para a melhoria contínua de serviço e ilustra o ciclo
contínuo de melhoria:
Como podemos perceber, o primeiro passo é identificar a visão que está direcionando a iniciati-
va de melhoria. Isso possibilita identificar os objetivos finais e de longo prazo para as melhori-
as. Uma vez definida a visão, o foco agora é avaliar o estado corrente, ou seja, realizar a captu-
ra de uma linha de base32 da organização em termos de negócio, pessoas, processos e tecnolo-
gia. Isso gerará uma “grande figura” da provisão atual dos serviços e suas qualidades.
Realizado a análise da linha de base, o próximo passo visa identificar uma meta atingível, ou
seja, aquela que gerará benefícios “rápidos” e que justificará a oportunidade de melhoria. Na
sequencia, será necessário identificar as ações que deverão ser tomadas para atingir as metas
que foram decididas.
É importante garantir que essas atividades sejam capturadas e gerenciadas como parte de um
programa geral de melhoria (é necessário monitoramento dessas atividades). Por último, é ne-
cessário medir a performance corrente (já em operação) com a que está sendo proposta. Metas
específicas na melhoria do processo podem ser medidas em termos de matriz de maturidade,
pela eficiência e efetividade do processo.
32
Podem ser usadas para oferecer um ponto inicial para qualquer atividade de melhoria. Tira-se uma “foto” da infraes-
trutura, serviços e processos em um dado momento e, em seguida, isso é comparado com o ambiente real, para ver se
ambos são idênticos. Em seguida, essa “foto” é declarada como uma linha de base oficial.

É necessário que haja gerenciamento das atividades de melhoria, ou seja, é preciso que haja
um mecanismo para capturar os programas de melhoria para garantir ao provedor de serviços
a alocação dos recursos e capacidades de maneira eficiente. A ITIL® recomenda o desenvolvi-
mento de um registro de melhoria contínua de serviço, onde todas as melhorias individuais
possam ser registradas. Logo, torna-se possível aplicar algum tipo de categorização e gerenci-
amento da abordagem de melhoria contínua de serviço. Veja a seguir um exemplo:
O registro por si próprio será classificado como um ativo de serviço e, como tal, deverá ser ge-
renciado como um item no sistema de gerenciamento do conhecimento de serviço. O gerente
de melhoria contínua de serviço prestará conta pelo gerenciamento e coordenação de todas as
atividades.

3 O Ciclo de Deming
O filósofo W. Edwards Deming, famoso por suas filosofias de gestão para melhoria da Qualida-
de, formulou 14 pontos de atenção para os gerentes. Para a melhoria da qualidade, ele propôs
o Ciclo de Deming, particularmente aplicável na melhoria contínua de serviço. Os 4 estágios do
ciclo são: Planejar (Plan), Fazer (Do), Verificar (Check) e Agir (Act). Por isso, o ciclo também é
conhecido como Ciclo PDCA33.
O ciclo é crítico em dois pontos do estágio: na implementação e aplicação da melhoria contínua

de serviço a todos os serviços e processos de gerenciamento de serviço. Na implementação, os
4 estágios do ciclo PDCA são utilizados. Na melhoria continuada, a melhoria contínua de serviço
foca-se nos estágios Check e Act para monitorar, medir, revisar e implementar as iniciativas.
No estágio “Planejar”, conforme é deixado claro, inicia-se o planejamento da atividade de me-

lhoria. Nos demais estágios, o provedor de serviços executa as atividades conforme fôra defini-
da e acordada no plano. Importante ressaltar que, no passo “Faça” (Do), o provedor de servi-
ços deve capturar a atividade e fazer atualizações no registro de melhoria contínua de serviço.
O passo seguinte, Check, é caracterizado por verificar se todas as atividades foram realizadas.
Em termos de melhoria continuada, esse passo e o próximo são usados para monitorar, medir,
revisar e implementar as atividades.
A melhoria contínua de serviço não conseguiria existir sem os resultados das medições, parte
integral de todos os processos. Para ser útil, as medições devem ser objetivas, ou seja, devem
avaliar o status corrente, identificar áreas de melhoria e medir as melhorias já realizadas. A
maioria das organizações irão medir a disponibilidade, confiabilidade e desempenho dos servi-
ços.
33
O ciclo PDCA é complementar a abordagem da MCS e o processo de melhoria de 7 passos.

4 Indicador Chave de Performance e Fator Crítico de Sucesso

Um Fator Crítico de Sucesso é alguma coisa que tem que acontecer para que um serviço de TI,
processo, plano ou qualquer outra atividade possa obter êxito. Por outro lado, os Indicadores
Chave de Performance são usados para medir cada acontecimento de fator crítico de suces-
so.
Estabelecer e mensurar o Fator Crítico de Sucesso para um processo permitirá melhor entendi-
mento do estado corrente do mesmo; ajudará a identificar quaisquer melhorias necessárias e
medirá a obtenção de qualquer melhoria feita.
O gerente de melhoria contínua de serviço será importantíssimo em auxiliar os donos dos pro-
cessos e gerentes a entender os fatores críticos de sucesso para cada processo, ajudar a identi-
ficar quaisquer melhorias necessárias e medir o atingimento de quaisquer melhorias feitas.
É recomendado que um serviço/processo possua entre 2 a 5 Fatores Críticos de Sucesso asso-

ciados em um dado momento. Também é recomendado que haja, para cada fator crítico de
sucesso, entre 2 a 5 indicadores chave de performance para medir o seu sucesso.
É importante ressaltar que os indicadores chave de performance podem ser quantitativos ou

qualitativos.
Em geral, uma métrica é uma escala de medição que

permite ao provedor de serviços definir o quê deverá
ser medido.
Há 3 tipos de métricas que uma organização preci-

sará coletar para suportar as atividades da melhoria
contínua de serviço e outros processos de gerencia-
mento de serviço:
 Métricas de tecnologia: geralmente são associ-

adas com componentes de gerenciamento, usando sistemas de monitoramento, como moni-
toramento da disponibilidade e de performance;
 Métricas de processo: capturadas em termos de fatores críticos de sucesso e Indicadores

Chave de Performance. As 4 áreas chave que os indicadores chave de performance conse-
guem auxiliar são: qualidade, desempenho, valor e conformidade.
 Métricas de serviço: oferecem a medida fim-a-fim de um serviço. Consistem de resultados

produzidos das métricas de tecnologia e de processo.

As linhas de base podem também ser usadas para oferecer um ponto inicial para qualquer ati-
vidade de melhoria. Por isso, é importante que, ao capturá-las, o provedor de serviços tenha
certeza que a mesma é precisa.
Tirar uma “fotografia” da infraestrutura, dos serviços e processos em um dado momento no

tempo é bastante importante, mas para usar isso como base para posterior comparação ou
como ponto inicial, a “fotografia” deve ser verificada contra o ambiente de fato - antes de ser
declarada como oficial.
É importante que sejam estabelecidas linhas de base em todos os níveis, incluindo metas e ob-
jetivos estratégicos, maturidade dos processos táticos, métricas operacionais e fatores críticos
de sucesso.
5 O Processo de Melhoria de 7 Passos

Propósito:
O processo de melhoria de 7 passos é uma parte importantíssima para o sucesso da melhoria
contínua de serviço. O propósito do processo é definir e gerenciar os passos necessários para
implementar (com sucesso) as melhorias.
Isso inclui identificar e definir as medições e métricas; as ações requeridas para reunir, proces-
sar e analisar os dados; como os resultados serão apresentados; e, finalmente, o gerenciamen-
to da implementação da melhoria.

Objetivos:
 Identificar oportunidades de melhoria para os serviços, processos, ferramentas, etc;
 Entregar redução nos custos na oferta dos serviços, enquanto mantém os níveis de serviço e
resultados que o negócio precisa;
 Identificar quais necessidades precisam ser medidas, analisadas e reportadas para que pos-
sam ser estabelecidas as oportunidades de melhoria;
 Alinhar continuamente e realinhar a provisão de serviço de TI com os resultados de negócio

requeridos, e monitorar o serviço para garantir que as realizações dos serviços atendem aos
requisitos de negócio;
 Entender o quê medir e porquê está sendo medido; definir o resultado de sucesso.
Escopo:
O processo não é desenhado para ser utilizado isoladamente, mas ser aplicado por todos os
aspectos da provisão dos serviços de TI, incluindo tecnologia, serviços, processos, organização
e parceiros.
O escopo deverá incluir uma análise da performance e capacidades de todos esses aspectos,
incluindo avaliação da maturidade dos processos que habilitam cada serviço. Incluirá também
fazer o melhor uso da tecnologia disponível, explorando os benefícios de qualquer nova tecno-
logia, onde o custo for justificável e ofereça benefícios de negócio mensuráveis.
Vamos entender os 7 passos:
Passo 1: Identificar a estratégia de melhoria
As questões levantadas aqui estão relacionadas com o estabelecimento geral da visão do negó-
cio. Será necessário revisar regularmente esse passo para garantir que o provedor de serviços
continua alinhado com o objetivo geral de negócio. Qualquer iniciativa que seja considerada
deverá ser registrada no registro de melhoria contínua de serviço.
Caso seja rejeitada (após revisão do caso de negócio ou justificativa), a informação poderá ser
arquivada. Gatilhos e entradas para o processo de melhoria podem incluir planos de negócio e
estratégia, encontros para revisão de serviços, declarações da visão e missão, registro de me-
lhoria contínua de serviço, controles de governança, objetivos corporativos, requisitos legais e
pesquisas de satisfação do cliente.
Passo 2: Determinar o quê será medido
Aqui é necessário definir o que o provedor de serviços deverá medir, definir e acordar sobre o
quê de fato pode ser medido para que, em seguida, após realizar análises, possa finalizar o
plano de medição das melhorias. Para ser efetivo, esse passo deve focar-se em algumas poucas
medições significativas que suportem avaliações de sucesso (qualitativas e quantitativas).
Definir exatamente o quê será medido e o valor que isso trará é algo imprescindível. Entradas
para esse passo incluem os requisitos de nível de serviço e metas, encontro para revisão de
serviço, portfólio e catálogo de serviço, ciclo de orçamento, resultados e relatos de medição,
pesquisas de satisfação, dados de benchmark, dados da linha de base e planos de avaliação e
mitigação de riscos.

Passo 3: Reunir os dados
Esse passo requer monitoramento. Para os dados da melhoria contínua de serviço o provedor
de serviços estará menos preocupado com o monitoramento em tempo real e mais interessado
nas exceções, resoluções e tendências associadas com os dados produzidos. Para o monitora-
mento de tecnologia, é possível empregar ferramentas para automatizar a atividade.
Vejamos as tarefas associadas com esse passo:
1. Definir os requisitos de monitoramento e coleta de dados;
2. Definir a frequência de monitoramento e coleta dos dados;
3. Determinar os requisitos de ferramentas para monitoramento e coleta dos dados;
4. Desenvolver procedimentos de monitoramento e coleta dos dados;
5. Desenvolver e comunicar o plano de monitoramento e coleta dos dados;
6. Atualizar os planos de disponibilidade e capacidade;
7. Iniciar o monitoramento e coleta dos dados.
Entradas para esse passo incluem requisitos de novos negócios, acordos de nível de serviço
existentes, ferramentas existentes e monitoramento da capacidade, relatórios de analise de
tendências, registro de melhoria de serviço contínua, relatórios de análise de gap (o que deve-
ria/pode medir) e pesquisa de satisfação.
Passo 4: Processar os dados
É nesse passo que permite ao provedor de serviços converter os dados para o formato requeri-
do a quem interessar. Ao processar os dados, é importante lembrar que os dados coletados de
entradas manuais podem precisar de maior esforço na verificação (embora quase todos os da-
dos capturados da melhoria de serviço contínua possam ser coletados pela automação).
Entradas para o passo incluem dados coletados através de monitoramento, acordos de nível de
serviço/acordos de nível operacional, catálogo de serviço, lista de métricas, indicadores chave
de performance, Fatores críticos de sucesso, objetivos e metas e frequência dos relató-
rios/template.
Passo 5: Analisar as informações e dados
Sem a análise e entendimento do contexto da informação, o provedor de serviços não consegue

tomar decisões informadas. É necessário estabelecer qual informação realmente importa para a
organização. Analisar os dados requer um alto de nível de habilidade do que capturar ou pro-
cessá-los.
É necessário entender o contexto da informação e compará-la com as metas acordadas. A aná-

lise deverá ser compartilhada com gerentes de TI e discutidas para que possam ser formulados
planos para oportunidades de melhoria. Essa saída poderá fazer parte da apresentação. Entra-
das para o passo incluem os resultados dos dados monitorados, indicadores chave de perfor-
mance e metas existentes e informações e percepções das pesquisas com os clientes.

Passo 6: Apresentar e usar as informações
Aqui o provedor de serviços apresenta o conhecimento, representado em relatórios, monitores,

planos de ação, revisões, avaliações e oportunidades para todos aqueles interessados34 (apre-
sentar no formato correto para cada público).
Os relatórios criados devem oferecer ênfase e destacar áreas para ação a ser tomada para im-
plementar as melhorias. Entradas para o passo incluem informações comparadas, detalhes dos
formatos (templates de relatórios, etc) e informações de contato das partes interessadas.
Passo 7: Implementar a melhoria
Nesse passo o provedor de serviços poderá utilizar o conhecimento apresentado no passo ante-
rior e combiná-lo com experiências prévia para tomar uma decisão informada sobre a iniciativa
de melhoria.
O processo de tomada de decisão deverá ser comunicado por toda a organização, permitindo
que a eventual melhoria seja implementada com sucesso e entendida por todas as partes inte-
ressadas e praticadores.
Entradas para esse passo incluem o conhecimento obtido da apresentação e uso da informação,
planos de implementação acordados e registros de melhoria contínua de serviço.
34
Clientes, Gerentes de TI seniores, TI interna e Fornecedores.

6 Conclusão
Parabéns, se você chegou até aqui é porque concluiu seus estudos!
Tenha certeza de que compreendeu todos os conceitos aqui mostrados. Dê uma repassada na
matéria e tome notas dos pontos que não entendeu muito bem.
Agradecemos pela sua confiança e para quem vai fazer o exame de certificação desejamos uma
boa sorte!
Equipe DlteC do Brasil
Sobre o E-book/Apostila
O conteúdo desse documento é uma adaptação

da matéria online de leitura do curso.
O presente material traz conteúdo teórico do cur-

so online, porém temos que deixar claro que não
é um curso e sim uma adaptação do nosso
material online para e-book/apostila. Portan-
to recursos como exercícios, simulados, tutoria
(tira dúvidas com professores) e vídeo aulas não
fazem parte desse e-book, pois são exclusivos
para alunos devidamente matriculados em nosso
site oficial.
Para maiores informações sobre nossos treinamento visite o site:
>>> http://www.dltec.com.br <<<

Ebook ITILv3 Foundation-115

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ebook ITILv3 Foundation-115

Загружено:

Авторское право:

Доступные форматы

tel (41) 3045.7810 - info@dltec.com.br - www.dltec.com.

Apostila Impressa do Curso de ITIL® Foundation

Apostila do Curso ITIL ® Foundation Página 1

O conteúdo desse documento é uma adaptação

O presente material traz conteúdo teórico do cur-

Para maiores informações sobre nossos treinamento visite o

>>> http://www.dltec.com.br <<<

Apostila do Curso ITIL ® Foundation Página 2

Esse material é de propriedade da DlteC do Brasil Ltda e é protegido

É expressamente proibida cópia física ou em meio digital, reprodução

Seu uso pessoal e intransferível é somente para o cliente que adquiriu o

A cópia e distribuição são expressamente proibidas e seu descumpri-

Apostila do Curso ITIL ® Foundation Página 3

Capítulo 01 - Gerenciamento de Serviço como uma Prática ............................................. 5

Apostila do Curso ITIL ® Foundation Página 4

Desejamos a todos bons es- 8.3 Quando Deverei Agendar o Exame? 22

Apostila do Curso ITIL ® Foundation Página 5

 (ITIL®FND01) Gerenciamento de Serviço como uma Prática:

 (ITIL®FND01-1) descrever o conceito de melhores práticas no domínio público.

 (ITIL®FND01-2) descrever e explicar o porquê da ITIL® ser bem-sucedida.

 (ITIL®FND01-3) definir e explicar o conceito de um serviço.

 (ITIL®FND01-6) definir e explicar o conceito de gerenciamento de serviço.

 (ITIL®FND01-7) definir e explicar o conceito de gerenciamento de serviço de TI.

 (ITIL®FND01-8) definir e explicar o conceito de partes interessadas no gerenciamento de serviço.

 (ITIL®FND01-9) definir processos e funções.

 (ITIL®FND01-10) explicar o modelo de processo e as características de processos.

 (ITIL®FND02) O ciclo de vida de serviço da ITIL:

 (ITIL®FND02-2) descrever a estrutura do ciclo de vida de serviço da ITIL.

 (ITIL®FND03) Conceitos Genéricos e Definições:

 (ITIL®FND03-2) Ativos, recursos e capacidades.

 (ITIL®FND03-8) Provedor de serviço.

 (ITIL®FND04) Princípios-chave e modelos:

 (ITIL®FND04-2) descrever a criação de valor através dos serviços.

 (ITIL®FND08) Tecnologia e arquitetura:

 entender como a automação de serviço auxilia na agilização dos processos de geren-

Apostila do Curso de ITIL® Página 6

A atual versão do framework é aquela lançada em julho de 2011. Trata-se, na verdade, de um

Apostila do Curso ITIL ® Foundation Página 7

Apostila do Curso ITIL ® Foundation Página 8

2.1 Estratégia de Serviço

No centro do ciclo de vida do serviço encontra-se a Estratégia de Serviço. A criação de valor

2.2 Desenho de Serviço

2.3 Transição de Serviço

Um dos mais importantes tópicos do estágio é o Sistema de Gerenciamento do Conhecimento

Apostila do Curso ITIL ® Foundation Página 9

2.4 Operação de Serviço

2.5 Melhoria Contínua de Serviço

O estágio oferece as melhores práticas para atingir melhorias incrementais e de larga-escala na

Os principais motivos que fizeram a ITIL® ser um sucesso são:

 Neutralidade: as práticas de gerenciamento de serviços de TI são aplicáveis a qualquer tipo

Apostila do Curso ITIL ® Foundation Página 10

Focando-se no resultado desejado pelo cliente e gerenciando os serviços apropriadamente, o

A ITIL® define serviços de TI como sendo qualquer serviço oferecido por

Apostila do Curso ITIL ® Foundation Página 11

O gerenciamento de serviços é um conjunto de capacidades organizacionais especializadas para

O principal propósito do gerenciamento de serviços é transformar capacidades

Apostila do Curso ITIL ® Foundation Página 12

Viu só a complexidade em relação ao valor de um serviço? Além da funcionalidade do serviço,

Apostila do Curso ITIL ® Foundation Página 13

A diferença negativa é a percepção do que o cliente perderia ao investir no serviço. A diferença

Vale ressaltar agora outros conceitos importantes:

Apostila do Curso ITIL ® Foundation Página 14

5 Tipos de Provedores de Serviços, Processos e Funções