Itil conceitos obtidos em blogs e sites

ITIL V3 – Introdução e Conceitos – Histórico do ITIL

Começamos a partir desta postagem uma grande viagem por uma das mais espetaculares bibliotecas
de melhores práticas para gerenciamento de serviços de TI!!! A biblioteca ITIL!!! Aliás, o correto, em
português, seria dizer a ITIL e não o ITIL, uma vez que a mesma é uma biblioteca, mas não vamos
ficar brigando com aqueles (inclusive eu mesmo) que tratam como o ITIL, como é mais utilizado pelo
mercado (alguns dizem que é o modelo de melhores práticas, o framework, etc,etc,etc).

O ITIL, ou a ITIL, nasceu há 20 anos na Inglaterra (oficialmente tem 20 anos de vida, mas as práticas
de gerenciamento existem a muito mais tempo). Na década de 80, a primeira ministra daquele país,
Margareth Thatcher, mais conhecida como a Dama de Ferro (pense numa mulher bruta...) iniciou uma
mudança na estrutura do governo inglês com a privatização de algumas empresas estatais, as
famosas British --alguma coisa-- (BP – British Pretolium, British Airways, etc). Para gerenciar o
funcionamento dos mercados que estavam sendo privatizados, foram criadas as agências reguladoras.
Uma delas, a CCTA (uma espécie de ANATEL britânica), reuniu empresas públicas, privadas,
fundações, entre outras organizações e poderes públicos para identificar quais seriam as melhores
práticas no gerenciamento de serviços de TI. Desta reunião saiu a versão 1 do ITIL, em 1990.
A biblioteca foi, aos poucos, conquistando o mercado europeu, especialmente a Alemanha, França e
Holanda. Apenas no final dos anos 90, o ITIL entrou nos Estados Unidos. Em 2000 foi lançada a versão
2 da biblioteca. Nesta versão foram feitos resumos e integrações dos vários processos descritos na
versão anterior. A versão 2 da ITIL ganhou o mundo e se popularizou como o framework de melhores
práticas no gerenciamento de entrega de serviços em TI mais utilizados pelas organizações (existem
muitas outras). A CCTA passou a se chamar OGC (Office of Govermment Commerce), cujo foco é

1

adotar práticas para a eficiência da gestão pública. A OGC é a detentora da marca ITIL, porém ela não
se interessa em montar cursos, fazer exames de certificação, implementar a ITIL mundo afora, etc. Isso
fica a cargo de uma estrutura que rodeia as decisões tomadas pela OGC
Em 2007 foi lançada a versão 3 do ITIL. Esta versão tem uma visão mais ampla de governança de TI,
já que, nas versões anteriores o foco principal era a parte de infraestrutura de TI. Como o tempo médio
de vida de uma versão do ITIL é de 7 a 10 anos, acredito que o estudo da V3, ao invés da V2 será
mais útil para os nossos leitores e para as empresas que pensam em gerenciar os serviços de TI com
base nos processos descritos no ITIL.
ITIL V3 – Introdução e Conceitos – O que é um serviço?

Para o ITIL, na sua terceira versão, a definição oficial de serviço é a seguinte:
“Um serviço é um meio de entregar valor ao cliente, facilitando a obtenção dos resultados que os
clientes querem alcançar sem que estes assumam a propriedade dos custos e riscos inerentes.”
Achou complicado? Não entendeu nada? Calma, calma... Vamos por partes. Esta definição possui uma
série de coisas importantes descritas de forma sucinta que precisamos nos atentar principalmente
quando fornecemos serviços de TI.
A primeira informação importante, destacada no texto, diz respeito a expressão “entregar valor”.
Entregar valor tem o sentido de fornecer um benefício que é compreendido pelo cliente, algo como o
serviço de telefonia fixa e celular, os correios, etc. Este benefício deve ajudar o cliente, segundo termo
em destaque, a alcançar um determinado objetivo definido por ele. O terceiro trecho destacado diz
respeito à propriedade dos custos e riscos inerentes ao serviço oferecido ao cliente. Quando
contratamos um serviço não nos importamos com os riscos e custos inerentes a ele, vamos
exemplificar para melhor explicar o que queremos dizer.
Os Correios oferecem dois serviços distintos, o SEDEX e o SEDEX 10. Consideremos, numa hipótese
fictícia, duas empresas que fazem vendas pela internet, uma vende livros e a outra medicamentos.
Ambas enxergam o correio como uma provedora de serviços e cada uma escolhe o benefício, ou
serviço, que irá ajudá-la a alcançar os seus objetivos da forma mais eficiente. A empresa que vende
medicamentos prefere utilizar o serviço de SEDEX 10, devido a natureza do produto que comercializa,
enquanto a empresa que vende livro prefere utilizar o SEDEX normal. Os riscos associados a logística
de entrega do SEDEX 10 provavelmente são diferentes dos riscos do SEDEX normal, mas isso não é
um problema das empresas que utilizam os serviços e sim dos Correios. Os custos para a produção do
serviço também são de responsabilidade dos Correios, que negocia um valor para as empresas que
avaliam as suas necessidades e escolhem pela alternativa que melhor os atenda.
Hoje em dia quase tudo é comercializado na forma de serviços. As pessoas contratam os níveis de
serviço e não o produto simplesmente, ou seja, você deseja as características de um determinado
produto e não uma caixa fechada.
Sacou quão longe o pessoal da OGC pensou? Essa é uma das razões do ITIL ter se tornado tão
conhecido mundialmente e tão utilizado pelas empresas de TI.
Na próxima postagem veremos os conceitos de boas práticas e gerenciamento de serviços. Sigam-me
os bons!!!!
ITIL V3 – Introdução e Conceitos – Boas Práticas e Gerenciamento de Serviço

2

Já vimos como o ITIL define um serviço de TI, agora vamos passar pelas definições de Boas Práticas e
de Gerenciamento de Serviço.
Boas Práticas
Prática, na visão do ITIL, é uma maneira de se trabalhar, ou melhor, uma forma como o trabalho deve
ser feito. As práticas incluem, normalmente, atividades, processos, funções, modelos e orientações.
Tendo esta definição em mente, podemos concluir que Boas Práticas são atividades ou processos
comprovados e utilizados com sucesso por diversas organizações. ITIL é um exemplo de Boa Prática.
Todavia, não podemos confundir Boa Prática com Norma. A Norma é algo obrigatório, as Boas Práticas
não. Na verdade, o uso de Boas Práticas garantem naturalmente a execução das Normas. O ITIL
define-se como sendo uma boa prática onde cada empresa deve adotar e adaptar à sua realidade no
que diz respeito a serviços de TI.
Gerenciamento de Serviço
Existem inúmeras definições no mercado para gerenciamento de serviço, porém na visão do ITIL,
Gerenciamento de Serviço é um conjunto de habilidades organizacionais especializadas (entenda-se
processos, conhecimento, etc) para prover valor aos clientes na forma de serviços.
O gerenciamento de serviços enfrenta quatro desafios, que na verdade são características dos
serviços, que influenciam de forma determinante como as empresas devem atuar para gerenciá-los.
Descrevemos abaixo estes quatro desafios do gerenciamento de serviços ou quatro características dos
serviços de TI:
Intangibilidade – Um serviço é mais difícil de medir, de definir fronteiras e de definir
expectativas do que produtos. Exemplo: Na compra de uma passagem aérea, a compra não é
da passagem (papel ou e-mail) e sim da viagem. Esta viagem possui várias variáveis, que
dependem não apenas na empresa, mas também de quem compra na hora de definir se
atendeu as expectativas, etc.
Inseparabilidade – Este termo refere-se a relação entre o consumo e a entrega de
um serviço. O momento da produção e do consumo do serviço não podem ser separados.
Diferente de um produto, onde há esta divisão clara (produção e consumo), um serviço, ao
mesmo tempo que está sendo produzido está sendo consumido. Tomemos como exemplo o
serviço de disponibilizar uma Rede. O serviço de rede ao mesmo tempo que está sendo
produzido, é consumido pelos usuários.
Variabilidade – O mesmo serviço pode ser entregue de formas diferentes. Voltemos
ao exemplo da viagem aérea. Dependendo do dia e do horário, uma mesma companhia pode
ter atraso ou não, pode ter fila ou não e vai atender suas expectativas de forma diferente cada
vez que o serviço for consumido.
Pericibilidade – Um serviço não pode ser estocado. No exemplo acima, após o
avião decolar aquele serviço de viagem não consegue ser reutilizado para o mesmo voo, caso um
passageiro não consiga embarcar. Será necessário um outro serviço de viagem para atender a sua
necessidade.
ITIL V3 – Introdução e Conceitos – Funções e Processos

3

Continuando o alinhamento dos conceitos iniciais do ITIL V3, veremos nesta postagem mais duas
definições importantes desta biblioteca de melhores práticas: funções e processos.
Funções
Na visão do ITIL, funções são “unidades da organização especializadas em executar determinados
tipos de trabalho e são responsáveis por resultados específicos”. Elas são independentes e autosuficientes em habilidades e recursos necessários para o seu desempenho. Estamos falando de um
conceito lógico, mais genérico, como as estruturas organizacionais dotadas de pessoas, conhecimento
e recurso para execução de uma tarefa.
Existe uma distinção importante entre Função, Grupos, Equipes, Departamentos, Divisões e Papéis. A
definição de Função já foi descrita no parágrafo anterior, já os Grupos referem-se a uma ou mais
pessoas que possuem um propósito comum, não obrigatoriamente da mesma área. Equipe é algo mais
formal do que o Grupo, pois tem responsabilidades mais estruturadas. Departamento e Divisões são
estruturas formais. Normalmente, uma Divisão possui um ou mais Departamentos. Por fim, Papéis, que
serão melhor aprofundado em outra postagem, são as atividades ou lista de atribuições de uma
determinada pessoa, grupo ou equipe. Para o ITIL, quem define os papéis são os processos.
Processos
Na visão clássica, também seguida pelo ITIL, processo é “um conjunto estruturado de atividades
destinadas a cumprir um objetivo específico” que recebem uma ou mais entradas definidas(os
chamados inputs) e as transformam em resultados definidos(os chamados outputs). Normalmente um
processo não existe sozinho. Na verdade, ele interage com uma série de outros processos.
No caso do ITIL, os processos são aplicados durante todo o Ciclo de Vida do Serviço (não se
apavorem com este termo, entraremos em mais detalhes em futuras postagens!). Sob este aspecto
faz-se necessário considerar o processo todo ou como um processo se encaixa em outro processo.
Tendo uma visão genérica sobre um modelo de processo do ITIL, todo processo deve ter um dono,
normas ou políticas bem definidas, objetivos (pelo menos um) para ser alcançado, ser documentado e
possuir indicadores que permitam medir seu desempenho. Além disso, para que possa ser executado,
um processo deve definir as suas atividades, procedimentos e instruções, suas métricas, seus papéis e
uma forma de identificar melhorias contínuas. Por fim, para que possam ser viabilizados, os processos
devem contar com recursos e habilidades ou capacidades para que funcionem adequadamente.
Neste modelo genérico de processo, o ITIL identifica quatro importante características de processos
que descrevemos abaixo:
Mensurável: Todo processo deve ser capaz de ser medido de forma relevante.
Entrega resultados específicos: Os processos devem entregar resultados
previsíveis, dentro do objetivo para o qual foi criado.
Entrega resultados primariamente para clientes ou stakeholders: Todo processo
deve ter o foco principal no cliente, que pode ser interno ou externo.
Responde a um evento específico: Todo processo possui um ou mais gatilhos ou
agentes que fazem com que o mesmo aconteça.
ITIL V3 – Introdução e Conceitos – Papéis e Matriz RACI

Nesta postagem estaremos finalizando a parte de introdução e conceitos iniciais do ITIL V3 com dois
assuntos muito importantes para esta biblioteca de melhores práticas: os papéis e a famosa Matriz

4

RACI.
Papéis

Cada processo do ITIL pode definir quantos papéis forem necessários para sua execução, mas existem
dois papéis, definidos como “papéis genéricos”, que são vitais para qualquer processo do ITIL: o papel
de Dono do Processo e o papel de Dono do Serviço. A seguir, vamos detalhar melhor cada um desses
papéis.
Dono do Processo
Cada processo deve ter apenas um dono. Este dono é responsável por garantir que seu processo
esteja sendo executado segundo o que foi acordado e documentado e está alcançando os objetivos
definidos no próprio processo. Existem tarefas que são de responsabilidade do dono do processo,
dentre elas podemos citar as seguintes: documentar e divulgar o processo, definir os Principais
Indicadores de Desempenho (PIDs ou KPIs), melhorar a eficiência e eficácia do processo, fornecer
entradas para o Plano de Melhoria do Serviço, garantir que toda a equipe tenha recebido o treinamento
necessário sobre o processo e garantir que o processo seja regularmente revisado e reexaminado.
No mundo real das organizações, o dono do processo tem que ter, no mínimo, uma certa influência
para que possa garantir que seu processo esteja sendo executado corretamente. Em outras palavras,
processos cujos donos são “oreias secas” (como se diz lá no cerrado) tendem a não conseguir com
que seus processos sejam executados dentro da organização.
Uma observação importante: Dono do Processo é diferente de Gerente do Processo. Este é um braço
operacional que fará com que aquele alcance os objetivos do processo.
Dono do Serviço
Cada serviço deve ter apenas um dono. Este é “o cara” em relação a um determinado serviço. Na
verdade, este papel é quem responde pela qualidade final do serviço e presta contas sobre o mesmo.
O Dono do Serviço enxerga o serviço como um todo e, assim como o Dono do Processo, possui uma
série de responsabilidades, como por exemplo: fornecer aos atributos do serviço (desempenho,
disponibilidade, etc.), ser o ponto de escalação para incidentes maiores, representar o serviço em
reuniões do Comitê Consultivo de Mudanças, participar em reuniões externas para revisões de
serviços com as áreas de negócio, etc.

5

É importante salientar que o Dono do Serviço não é, obrigatoriamente, quem faz o gerenciamento de
nível de serviço.
Matriz RACI
A matriz RACI é um modelo usado para ajudar a definir papéis e responsabilidades. RACI é um
acrônico para as quatro funções principais. Pera aí!!!! acrônico??? Essa eu fui longe não??? Mas
vamos seguir adiante... hehehe. Bom, como estávamos dizendo, as quatro funções principais são:
Responsável → Pessoa(s) responsável(eis) por fazer com que o trabalho seja feito.
São os que colocam a mão na massa!
Accountable → É quem presta conta pela atividade.
Consultado → Pessoas que são consultadas antes da execução da tarefa pois suas
opiniões são importantes para a execução da atividade.
Informado → Pessoas que se mantêm atualizadas constantemente. Normalmente
são informadas depois da execução da atividade.

Na Matriz RACI, representada na figura acima, podemos verificar que uma série de informações estão

6

dispostas em forma de tabela, o que facilita a identificação dos responsáveis por cada tarefa dentro de
cada processo do ITIL. Apesar disso, existem potenciais problemas relacionados ao modelo RACI que
devem ser tratados. Dentre eles podemos citar: ter mais de uma pessoa que presta conta
(Accountable) por um processo (na prática, processo com dois donos na verdade não tem nenhum),
delegação de responsabilidade ou prestação de contas sem autoridade necessária para tanto, foco na
correlação de processos e atividades com os departamentos, etc.
Finalizamos assim os conceitos iniciais, a partir das próximas postagens falaremos genericamente do
ciclo de vida do serviço para depois entrarmos com tudo em cada uma das etapas deste ciclo. Não
desanimem!!!!
ITIL V3 – Ciclo de Vida do Serviço

No retorno das férias, daremos início aos trabalhos do nosso blog com um tema que será utilizado
praticamente em todas as postagens referentes ao ITIL daqui por diante, o ciclo de vida do serviço
(representado na figura abaixo).

A biblioteca ITIL divide o ciclo de vida do serviço em dois componentes básicos:
Núcleo do ITIL: onde estão as orientações sobre as melhores práticas aplicáveis a
todos os tipos de organizações que prestam serviços ao negócio.
Guias complementares do ITIL: um conjunto complementar de publicações com
orientações específicas para setores da indústria, tipos de organização, modelos operacionais
e arquiteturas de tecnologia.

7

O Núcleo do ITIL é representado, na figura acima, por todas as fases que vão desde o centro até o
anel amarelo, ou seja, compreende as fases de Estratégia do Serviço (Service Strategy), Desenho do
Serviço (Service Design), Transição de Serviço (Service Transition), Operação de Serviço (Service
Operation) e Melhoria de Serviço Continuada (Continual Service Improvement). Cada uma das fases
do Núcleo do ITIL se tornou uma publicação dentro da biblioteca e será alvo de nossas futuras
interações. Por enquanto faremos uma contextualização de cada uma dessas fases para que
possamos aprofundar mais nas próximas postagens, mas antes disso é importante dizer que o outro
componente básico da biblioteca, os Guias Complementares, representados pelo anel cinza, são
divididos em publicações complementares, como livros, artigos, etc. e serviços de suporte web, como
portais, templates, etc.
Estratégia do Serviço – Nesta fase são fornecidas orientações úteis para o
desenvolvimento de políticas e objetivos de gerenciamento do serviço através do seu ciclo de
vida. Os processos desta fase ajudam a organização na implementação do gerenciamento do
serviço, na identificação do dono do serviço e dos donos dos processos além de verificar a
viabilidade e a importância da criação do serviço.
Desenho do Serviço – Possui processos que orientam o desenho e o
desenvolvimento do serviço assim como o desenho dos processos de gerenciamento do
mesmo. Ele inclui as alterações e melhorias necessárias para aumentar ou manter o valor do
serviço para os clientes, a sua continuidade, o atingimento de níveis de serviço e a
conformidade com as normas e regulamentos.
Transição do Serviço – Esta fase fornece orientações para o desenvolvimento e
melhorias das habilidades necessárias para fazer a transição de novos serviços ou serviços
alterados para a operação.
Operação do Serviço – Esta fase incorpora práticas ao gerenciamento de
operações de serviços. Ela inclui orientações para alcançar eficiência e eficácia na entrega e
suporte de serviços, assegurando assim o valor para o cliente e para o provedor de serviço.
Melhoria de Serviço Continuada – Possui processo que fornece orientações para a
criação e manutenção de valor aos clientes por meio da melhoria do desenho, implantação e operação
do serviço, além da revisão estratégica se o serviço é realmente importante ou não.
ITIL V3 – Estratégia do Serviço – Metas e Objetivos

8

A partir desta postagem iremos tratar cada uma das fases do ciclo de vida do serviço, que na verdade
se transformaram em livros na biblioteca ITIL. Para melhor compreensão e devido a excelente didática,
iremos copiar a técnica utilizada no curso oficial do ITIL V3 que tive o prazer de fazer com a Rhino
Consulting. Esta técnica consiste em dividir os assuntos de cada livro ou fase do ciclo de vida do
serviço nos seguintes tópicos: Metas e Objetivos; Conceitos e Definições; Técnicas, Ferramentas e
Modelos; Processos e por fim Tecnologia e Arquitetura.
O primeiro livro que iremos explorar é o de Estratégia do Serviço (Service Strategy). Este livro pode
nos parecer um pouco mais difícil de entender uma vez que trata de assuntos que estão mais ligados
com a parte estratégica da organização, mas, na verdade, a Estratégia do Serviço é um livro muito
importante pois ele embasa todas as outras fases do ciclo de vida do serviço além de ser o
responsável pelo alinhamento entre o serviço prestado e os objetivos da empresa.
Conforme técnica de aprendizado mencionada acima, iremos “iniciar os trabalhos” tratando das Metas
e Objetivos da Estratégia do Serviço (Service Strategy). Sei que alguns podem estar se perguntando,
mas qual a diferença entre Meta e Objetivo? Então, para que tenhamos um conhecimento uniforme
passo abaixo a diferença entre os dois:
Meta - É o propósito para o qual um esforço é direcionado; Normalmente de longo
prazo; Não pode ser medido; intangível; Representa uma ação genérica. Como exemplo
podemos dizer que uma Meta seria o seguinte texto:”Eu quero obter sucesso no campo de
pesquisa genética e fazer o que ninguém nunca fez.”
Objetivo - É a coisa para a qual um esforço ou ação é pretendida a alcançar ou
realizar; normalmente de curto prazo; pode ser medido; tangível; representa uma ação
específica. Utilizando o mesmo exemplo da Meta, teríamos o seguinte texto:”Eu quero lhe dar
a tese em pesquisa genética em até um mês.”
Entendido a diferença entre os dois termos, podemos fazer a seguinte classificação de Metas e

9

Objetivos da Estratégia do Serviço descrita no ITIL.
Meta: Suportar provedores de serviço para desenvolver a habilidade de pensar e agir de maneira
estratégica. Em outras palavras, a meta da Estratégia do Serviço é fazer com que as pessoas ou
empresas que irão prover serviços em TI, saiam do mundinho apenas da TI e pensem de forma
estratégica, no negócio e como a TI pode suportar o negócio (alinhamento estratégico).
Objetivos: A partir da Meta, o ITIL lista uma série de objetivos para a Estratégia do Serviço, entre as
principais estão:
Definir o que os serviços devem oferecer e para quem.
Diferenciar-se das alternativas competitivas.
Criar Valor para os clientes e capturar Valor para as partes interessadas
(stakeholders).
Fazer um Caso de Negócio para investimentos estratégicos.
Definir como o gerenciamento financeiro pode promover visibilidade e controle sobre
a criação de valor.
Definir a qualidade do serviço.
Escolher entre diferentes caminhos para melhorar a qualidade do serviço.
Usar eficientemente a alocação de recursos através de um portfólio de serviços.
Resolver conflitos em demandas por recursos compartilhados.
Percebam que a partir dos objetivos, alguns conceitos devem ser explorados para que se tenha um
completo entendimento. Assim, surgem termos importantes como: que serviços oferecer; criar valor
para os clientes, retorno financeiro, qualidade (fazer o que foi combinado/requisitado) e alocação de
recursos. Trataremos deste assunto nas próximas postagens.
ITIL V3 – Estratégia do Serviço – Conceitos e Definições – Criação de Valor

Seguindo a didática proposta para explorar cada um dos livros do ITIL V3, iniciaremos a verificação dos
conceitos e definições que serão importantes para o entendimento dos processos da Estratégia do
Serviço. Nesta postagem vamos ver o conceito de Criação de Valor.
Segundo o ITIL, o valor do serviço não está apenas nos resultados de negócio do cliente, ele também
é altamente dependente da percepção pessoal do cliente. Esta percepção é influenciada diretamente
pela expectativa que o mesmo cria em relação ao serviço que será prestado. Mas como se faz para
entender e especialmente atender as expectativas de nossos clientes? O ITIL sugere que os gerentes
de TI tenham uma mentalidade de marketing. Isso mesmo! Uma mentalidade de marketing. Fácil!
Mas... o que é uma mentalidade de marketing? Segundo o ITIL, por meio de uma mentalidade de
marketing é possível entender os componentes de valor de acordo com as perspectivas do cliente, em
outras palavras, é necessário conhecer como é feito o serviço ou produto ofertado. Entender o seu
cliente, o que ele valoriza, qual é a sua necessidade e aspiração.
Como exemplo para melhor entender, o Gartner Group disse, em uma de suas pesquisas, que até
2014, 70% dos acessos à internet serão feitos por dispositivos móveis. Essa pesquisa mostra a
expectativa dos clientes em relação ao uso dos dispositivos móveis. As empresas que vendem
aplicações ou serviços na web devem estar preparadas para atender essa expectativa ou visão de
valor que o cliente gostaria de ver no serviço que ele consome.
Tendo isso em mente, podemos dizer que a composição do Valor, na visão do cliente, consiste em dois
elementos primários:

10

Utilidade (O que o usuário receberá): é percebida pelo cliente a partir dos atributos
que tem um efeito positivo no desempenho de tarefas que estão associadas às suas
necessidades ou redução/remoção de restrições no desempenho das tarefas que também
possuem um efeito positivo para o cliente. Como exemplo, podemos citar a criação dos sites
de Internet Banking. Essas aplicações melhoram o desempenho de tarefas e remove a
restrição de horário do funcionamento das agências.
Garantia (Como é entregue ao usuário): é derivado do efeito positivo de estar
disponível, quando necessário, com a capacidade suficiente e de forma confiável em termos
de continuidade e segurança. Utilizando o mesmo exemplo do Internet Banking, o uso dessa
ferramenta só é percebida como boa para o cliente devido à segurança, disponibilidade,
capacidade, etc.
Moral da história: Para se ter valor para o cliente, o serviço deve ter Utilidade para o mesmo e ter
Garantia que vai funcionar ou dar os resultados esperados.

A figura acima mostra uma versão gráfica de como se criar valor para o cliente. O que temos que ter
em mente é que Utilidade é o que o cliente adquire e garantia é como isso é entregue.
TIL V3 – Estratégia do Serviço – Conceitos e Definições –Ativos de Serviço

Dando continuidade aos conceitos e definições da Estratégia do Serviço, veremos nesta postagem
quais são, na visão do ITIL V3, os Ativos de Serviço.
O ITIL define Ativos de Serviço como sendo qualquer Habilidade ou Recurso, utilizado por um
provedor de serviço, que contribui para a entrega de um determinado serviço. Em outras palavras, as
organizações utilizam Habilidades e Recursos para criar valor em forma de bens e serviços.
Os Recursos são coisas tangíveis, como por exemplo: Capital Financeiro, Infraestrutura, Aplicativos,
Informação e Pessoas (no sentido de recurso humano). Já as Habilidades são coisas intangíveis e
representam competências organizacionais para coordenar, controlar e implementar recursos, ou seja,
as Habilidades são usadas para transformar os Recursos. Como exemplo de Habilidades, o ITIL
enumera as seguintes: Gerenciamento, Organização, Processos, Conhecimento e Pessoas. Pera aí!!!
Pessoas de novo? Sim, caro leitor, pessoas, no contexto de Habilidades, refere-se às habilidades
individuais das pessoas (os famosos skills), enquanto que pessoas como Recurso é apenas o material
humano (quantidade de pessoas alocadas), sacou a diferença?

11

ITIL V3 – Estratégia do Serviço – Conceitos e Definições – Provedor de Serviço

Fechando os conceitos e definições do livro de Estratégia do Serviço, veremos nesta postagem como o
ITIL trabalha a questão do provedor de serviço. A biblioteca define três arquétipos de modelos de
negócio de provedores de serviço, a saber: Tipo I, Tipo II e Tipo III. Como esta classificação não diz
absolutamente nada, descreveremos abaixo cada um deles:
Tipo I - Este tipo de provedor de serviço é conhecido como Provedor de Serviço
Interno. São tipicamente funções que fazem parte das unidades de negócio que pertencem.
Tipo II – Descrita como Unidade de Serviços Compartilhados, são áreas que podem
atender muitas unidades ou até empresas, como por exemplo: área de RH, contabilidade,
logística, etc.
Tipo III – Provedor de Serviço Externo. Eventualmente as estratégias de negócio
requerem habilidades prontamente disponíveis por provedor de serviço externo. Os
Fornecedores, como também são conhecidos, representam um terceiro responsável por
fornecer bens e serviços requeridos para entregar serviços de TI. Os fornecedores podem ser
de Hardware e Software, de Rede e Telecom e de organização de Outsourcing.
Bem, finalizamos os Conceitos e Definições da Estratégia do Serviço. Elas nos serão úteis no
prosseguir da nossa viagem por esse importante livro da biblioteca ITIL!!! Na próxima postagem,
conforme metodologia adotada, iremos ver as técnicas, ferramentas e modelos utilizados pela
Estratégia do Serviço, antes de entrarmos nos processos propriamente ditos.
ITIL V3 – Estratégia do Serviço – Técnicas, Ferramentas e Modelos – Portfólio de Serviço

Iniciando um novo tópico, falaremos nesta postagem sobre o Portfólio de Serviço. Existem algumas
vertentes que tratam de diferentes maneiras o termo Portfólio de Serviço. Como estamos passeando
pelo mundo ITIL, vamos nos restringir a verificar a visão sob os olhares desta biblioteca.
O Portfólio de Serviço é visto pelo ITIL como uma ferramenta para priorizar investimentos e melhorar a
alocação dos recursos. Em empresas privadas, os portfólios requerem uma certa disciplina financeira
com o intuito de evitar investimentos que não irão gerar valor. Já no mundo público, outras variáveis
também devem ser consideradas, como por exemplo: a política, o resultado social (que nem sempre é
o melhor resultado financeiro), etc.
Esta importante ferramenta é dividida em três fases: o Funil de Serviço, o Catálogo de Serviço e os
Serviços Obsoletos. A seguir detalharemos cada uma dessas fases, mas antes é interessante verificar
que o Catálogo de Serviço é, na verdade, apenas uma parte do Portfólio de Serviço (as pessoas
costumam confundir esses dois termos!). É importante lembrar, também, que o Portfólio de Serviço
ajuda os gestores a esclarecer algumas questões estratégicas, como por exemplo: Por que um cliente
compraria esse serviço? Por que eles comprariam de nós?, etc. Vocês podem estar se perguntando:
como o portfólio ajuda a esclarecer as questões estratégicas, certo? Não se preocupem que eu
respondo. Não podemos tirar das nossas mentes que o Portfólio de Serviço representa o
comprometimento e investimentos feitos por um provedor de serviços a todos os clientes e a todos os
espaços de mercado (Espaço de Mercado = oportunidade). Como o objetivo final do Portfólio de
Serviço é maximizar o valor minimizando os riscos e custos, então ele deve ser utilizado de forma
intensa para definições estratégicas...

12

Bem, voltando a definição das três fases do Portfólio de Serviços, na figura acima verificamos as fases
que compõem o Portfólio (detalhadas abaixo) e também podemos perceber que o mesmo é parte
integrante de um grande Sistema de Gerenciamento do Conhecimento do Serviço (SGCS).
Funil de Serviço - Consiste nos serviços que estão em desenvolvimento ou sendo
viabilizados para um determinado cliente ou espaço de mercado. O Funil reflete a extensão
com que os novos conceitos e ideias de qualificação dos serviços são levados adiante pela
Estratégia do Serviço, Desenho do Serviço e Qualificação Continuada do Serviço. Resumindo,
o Funil representa a visão estratégica de crescimento do provedor de serviços para o futuro.
Catálogo de Serviços - É uma base de dados ou documentos estruturados que
possuem as informações sobre todos os serviços de TI em operação ou em vias de entrar em
produção. O Catálogo de Serviço é a única parte do Portfólio de Serviço disponível para
visualização por parte do cliente. Além disso, ele é dividido em duas porções: uma mais
voltada para o cliente e outra mais voltada para as áreas técnicas.
Serviços Obsoletos - Alguns serviços no Catálogo ficam obsoletos ou são
aposentados. As informações desses serviços, apesar de estarem aposentados, podem ser de grande
valia para a tomada de decisão de investimento futuros (as famosas “Lições aprendidas” do PMBOK).
Normalmente, os serviços obsoletos não estão disponíveis para novos clientes ou novos contratos.

13

ITIL V3 – Estratégia do Serviço – Técnicas, Ferramentas e Modelos – Caso de Negócio

Após termos visto como funciona o Portfólio de Serviços, vamos ver nesta postagem uma outra
ferramenta utilizada na definição da Estratégia do Serviço, o Caso de Negócio. O Caso de Negócio
deve documentar o impacto de um determinado serviço para os negócios ou os benefícios que o
mesmo poderá trazer. Este documento é, exatamente, o insumo necessário para a análise que é
efetuada no Funil do Portfólio de Serviços (ver postagem anterior para mais detalhes sobre o Funil e o
Portfólio de Serviços).
Ao desenvolver um Caso de Negócio, o foco não deveria estar limitado apenas na possibilidade de
lucrabilidade e retorno do investimento (famoso ROI), mas também ao valor de negócio que uma
melhoria de um determinado serviço, ou um novo serviço, poderia trazer para o negócio e para seus
clientes.
Normalmente um Caso de Negócio tem a seguinte estrutura:
serviço.

Introdução – Apresenta os objetivos do negócio que devem ser atendidos pelo

Métodos e Hipóteses – Define os limites do Caso de Negócio, como tempo, custo e
benefícios.
Impacto de Negócio – É o estudo que mostra os resultados financeiros e não
financeiros (apelo político, sociais, etc.) do Caso de Negócio.
Riscos e Contingências – A probabilidade de desvios aparecerem com resultados
alternativos aos inicialmente esperados.
Recomendações – Ações específicas que devem ser recomendadas.
Seguiremos na próxima postagem com as definições das técnicas, ferramentas e modelos utilizados na
Estratégia de Serviços. Valendo um doce para quem acertar qual seria a próxima técnica a ser descrita
aqui no blog! Alguém se atreve a tentar descobrir? Uma dica... ...este tema é tratado por praticamente
todas as metodologias...
TIL V3 – Estratégia do Serviço – Técnicas, Ferramentas e Modelos – Riscos

Finalizando as técnicas, ferramentas e modelos da Estratégia do Serviço, veremos nesta postagem

14

uma técnica que é utilizada por praticamente todas as metodologias que conheço, a análise e o
gerenciamento de Riscos.
Risco, na visão do ITIL, é definido como a incerteza de um determinado resultado. Se é uma
oportunidade então o risco é positivo. Se é uma ameaça, então o risco é negativo. Gerenciar risco diz
respeito à identificação e ao controle da exposição de uma empresa ao risco.
É certo dizer que de alguma forma as empresas gerenciam os seus riscos, porém nem sempre de um
modo explícito, controlado e consistentemente aplicável para suportar as tomadas de decisão que irão
influenciar os negócios da organização. É por isso que devemos utilizar o gerenciamento de riscos, já
que, sua missão principal é garantir que a organização utilize um processo com um conjunto de passos
bem definidos, permitindo a melhor tomada de decisão possível após o entendimento dos riscos e de
seus impactos.
A OCG (“pai” do ITIL) criou a figura do MOR. O MOR é um guia que é destinado a ajudar empresas a
criar um framework efetivo para ajudar nas tomadas de decisões a respeito dos riscos que afetam seus
objetos por todas as atividades organizacionais. Nesta visão, risco é dividido em duas fases distintas: a
análise de riscos, responsável pela identificação, avaliação das ameaças e vulnerabilidades e o
gerenciamento de risco, que o ITIL não considera como processo da Estratégia do Serviço, mas que
envolve a monitoração dos riscos e do acesso às informações confiáveis e atualizadas sobre os
mesmos.
ITIL V3 – Estratégia do Serviço – Processos – Gerenciamento de Portfólio de Serviço

Começamos a partir desta postagem a ver os processos do ITIL V3 referentes à Estratégia do Serviço.
Oficialmente, o ITIL fala sobre quatro processos para este livro, a saber: Geração da Estratégia,
Gerenciamento de Portfólio de Serviço, Gerenciamento Financeiro e Gerenciamento de Demanda. A
Geração da Estratégia é um processo que nos remete ao BSC (Balanced Scorecard). Como não
estamos tratando do BSC neste momento, vamos pular este processo e passar para o Gerenciamento
de Portfólio de Serviço.
Já falamos em outra postagem sobre Portfólio de Serviço, assim, para não ficarmos com postagens
muito extensas, sugiro que, se alguém tiver alguma dúvida sobre esta ferramenta, leia a publicação
referente a este assunto antes de prosseguir com a leitura sobre o processo de Gerenciamento de
Portfólio de Serviço (postagem de sexta-feira, 11 de março de 2011, intitulada ITIL V3 – Estratégia do
Serviço – Técnicas, Ferramentas e Modelos – Portfólio de Serviço), mas para aqueles que já leram
e não querem navegar pelas postagens, lembro que um Portfólio de Serviço descreve os serviços de
um provedor em termos de valor ao negócio.
O Gerenciamento de Portfólio de Serviço é um processo dinâmico e continuado que deve seguir as
seguintes atividades:
Definir – Com base na Estratégia do Serviço, o gerenciamento de Portfólio de
Serviço deve conhecer o que se tem atualmente na empresa, deve montar os Casos de
Negócio e validar os dados do portfólio.
Analisar – A análise representa o Funil do Portfólio e deve ser feita com o objetivo de
maximizar o valor do portfólio. A análise também é responsável por alinhar, priorizar e
balancear oferta e demanda.
Aprovar – Esta atividade aprova o portfólio proposto, autorizando serviços e
recursos para sua implementação.

15

Contratar – Esta atividade significa a identificação que um Caso de Negócio saiu do
Funil e deve ir para a parte de Desenho do Serviço.
ITIL V3 – Estratégia do Serviço – Processos – Gerenciamento da Demanda

Vamos explorar o processo de Gerenciamento da Demanda do livro de Estratégia do Serviço do ITIL
V3? Vamos lá! Este processo trabalha junto com o gerenciamento do Portfólio de Serviço e tem os
objetivos claros de entender e, principalmente, influenciar a demanda de clientes para Serviços, além
de entender e também influenciar a capacidade ofertada para atender a essas demandas.
Para não ficar dúvida, este processo, na verdade, tem que entender quais são as características do
serviço na visão do negócio e tentar influenciar a demanda a fim de utilizar de forma mais otimizada os
seus recursos. Um exemplo de influência de demanda de serviço é a ideia implementada pelas
empresas aéreas no que diz respeito à oferta de voos à noite (ou tarde da noite) por preços mais
baratos. A equação é simples: avião no pátio é custo, no ar é lucro (ou menos prejuízo). Assim, as
empresas começaram a influenciar a demanda por voos domésticos, ofertando-os a noite, onde antes
não era tão comum, por um preço mais barato. A influência também pode ser negativa, ou seja, tentar
diminuir o consumo de um determinado serviço em um determinado horário, por exemplo,
sobretaxando o serviço naquele horário indesejado.
É importante deixar claro que o processo de Gerenciamento da Demanda é um aspecto crítico do
gerenciamento de serviços, especialmente porque se faz necessário o entendimento do processo de
negócio, o que pode se configurar como um verdadeiro desafio. Um Gerenciamento da Demanda mal
feito ou negligenciado é uma enorme fonte de riscos para o provedor de serviço de TI devido à
incerteza da demanda.
As técnicas de Gerenciamento da Demanda, tais como precificação reduzida, descontos por volume e
níveis de serviços diferenciados podem influenciar a demanda em padrões específicos, contudo
devemos lembrar que não é possível produzir e estocar serviço para demandas posteriores. Assim,
entender a capacidade, gerar insumo para o planejamento da mesma e saber entender as
necessidades do negócio são atividades primordiais para o Gerenciamento da Demanda.
ITIL V3 – Estratégia do Serviço – Processos – Gerenciamento Financeiro

Fechando os processos da Estratégia do Serviço, falaremos nesta postagem do Gerenciamento
Financeiro. Este importante processo tem o objetivo de prover ao negócio e à área de TI a
quantificação, em termos monetários, dos serviços a serem prestados, ou seja, tem o objetivo de
estimar quanto custa o serviço de TI a ser ofertado. Além disso, este processo é responsável por
gerenciar os requisitos necessários para orçar o serviço, gerenciar a contabilidade dos gastos e a
cobrança propriamente dita.
Existem alguns mecanismos/metodologias e conceitos utilizados pelo Gerenciamento Financeiro na
identificação do orçamento, na contabilização dos custos e na cobrança dos provedores de serviços de
TI que facilitam o trabalho desta gerência. A seguir detalharemos estes mecanismos e conceitos:
Custo – Conceito que significa o montante de dinheiro gasto em uma atividade
específica, em uma unidade de negócio ou em um serviço de TI.
CTP – Custo Total de Propriedade (famoso TCO em inglês – Total Cost of
Ownership) – Este conceito permite avaliar todo o ciclo de vida do custo de propriedade de

16

um item de configuração. Para aqueles que nunca ouviram falar em TCO, ou TCP na língua
pátria, poderíamos dizer que a identificação do TCO vai além do valor produto ou serviço
propriamente dito, ele contabiliza as coisas que não são tangíveis e conseguem avaliar o
quanto o mesmo vale em todo seu período de vida útil.
CTU – Custo Total de Utilização (TCU in English – Total Cost of Utilization) – Avalia
todo o Ciclo de Vida do Custo da utilização do serviço de TI pelo cliente. É importante notar
que, para que se tenha o CTU, é necessário se ter um histórico do uso do serviço que está
sendo medido.
RDI – Retorno do Investimento (ROI para os íntimos – Return of Investment) – É uma
medição que relata o benefício esperado de um determinado investimento, ou melhor, mede o
tempo que demora para recuperar o investimento feito em algum serviço ou produto.
A partir do uso desses conceitos, a Gerência Financeira consegue fazer o orçamento, controlar a
contabilidade e efetuar a cobrança dos provedores de serviços de TI. Algumas coisas interessantes
saltam aos olhos quando olhamos para esses conceitos. Se percebemos bem, devemos fazer sempre
antes o CTP e só depois o CTU, uma vez que o primeiro é uma metodologia utilizada para ajudar na
tomada de decisão sobre investimento, enquanto que a segunda é uma metodologia utilizada para
ajudar na tomada de decisão sobre investimento e “sourcing” do serviço.
Se pudéssemos simplificar as coisas e ler tudo em uma única respirada, eu diria que a interação entre
os processos vistos até o momento seria da seguinte maneira (pausa para respirar fundo e começar a
leitura, sem gaguejar, por favor) : a necessidade do cliente são internalizadas por meio de requisitos
que estarão sendo gerenciados pelo Gerenciamento do Portfólio de Serviços. Esta gerência verifica
junto ao Gerenciamento de Demandas como isso poderá ser ofertado. A Gerência de Demandas
retorna os insumos para que a Gerência de Portfólios de Serviços possa colocar o novo serviço dentro
do funil do portfólio. Além disso esta gerência envia para o Gerenciamento Financeiro solicitando a
análise, utilizando os conceitos e mecanismos descritos acima, para identificar em termos monetários o
que significa a requisição feita pelo cliente. A gerência Financeira responde ao Gerenciamento de
Portfólios de Serviços que verifica se continua ou não com a construção do serviço de TI (OK ou NOK
– não OK)... ufa!!!! sacaram... simples e eficiente (nem tanto)...
Finalizamos aqui os processos do livro Estratégia dos Serviços. Lembrem-se que dentro do ciclo de
vida do serviço, aqueles que forem passar pelo Funil do Portfólio serão encaminhados para a próxima
fase, o Desenho do Serviço... Não percam as cenas dos próximos capítulos.
ITIL V3 – Estratégia do Serviço – Tecnologia eArquitetura –Automação do Serviço

Antes de entrarmos no Desenho do Serviço, ficou faltando, conforme metodologia proposta para o
tema ITIL V3, falarmos sobre a tecnologia e arquitetura da Estratégia do Serviço.
Para este livro em específico é mais difícil elencarmos tecnologias e arquiteturas, pois o propósito aqui
seria entender como a automação do serviço suportaria a integração entre os processos de
gerenciamento do serviço e a Estratégia do Serviço. Sob esta ótica ficaria claro dizer que primeiro se
faz necessário a definição de processos e depois das ferramentas para automação, pois, desta forma o
alinhamento estratégico estaria mais protegido e garantido.
De qualquer maneira, a automação deve sempre ser considerada a fim de melhorar a utilidade e a
garantia dos serviços (rever postagem sobre utilidade e garantia para maiores informações). Algumas
áreas do gerenciamento de serviços que poderiam se beneficiar com a automação seriam:

17

Catálogo de Serviços.
Classificação, priorização e encaminhamento dos requisitos.
Desenho e modelagem dos requisitos e dos processos, etc.
Bem pessoal, com esta postagem finalizamos a fase de Estratégia do Serviço dentro do ciclo de vida
do serviço proposta pelo ITIL V3. A partir da próxima postagem entraremos no livro Desenho do
Serviço com tudo!!! Não percam!!!
ITIL V3 – Desenho do Serviço – Metas e Objetivos

Caros leitores, sejam bem-vindos ao estágio do ciclo de vida do Serviço denominado de Desenho do
Serviço (Service Design) do ITIL V3. Assim como fizemos na Estratégia do Serviço, estaremos fazendo
uma viagem por este estágio verificando as Metas e Objetivos, os Conceitos e Definições, as
Técnicas/Ferramentas e Modelos, os Processos e finalmente a Tecnologia e Arquitetura.
Nesta postagem estaremos tratando das Metas e Objetivos deste importante livro da biblioteca ITIL. O
Desenho do Serviço tem como meta principal, como o próprio nome do estágio deixa transparecer, o
desenho de serviços novos ou de grandes alterações em serviços para a implementação em ambiente
de produção. Prestem bem atenção, pois no caso de alterações em serviços, este estágio tratará
exatamente daquelas que sejam significativas para o funcionamento do serviço, ou seja, aquelas que
precisam “voltar à prancheta” (sei que este termo nos dias atuais pode parecer vazio, mas não me
ocorreu nenhum outro jargão que pudesse exemplificar melhor a idéia que quero passar) e não das
mudanças que são corriqueiras tratadas em outro estágio do ciclo de vida do Serviço.
Os serviços que vieram da Estratégia do Serviço para este estágio do ciclo de vida são trabalhados por
uma série de processos que, no fim das contas, possuem os seguintes objetivos:

18

Desenhar o serviço de forma que atenda os objetivos de negócio.
Desenhar o serviço para que seja desenvolvido da forma mais fácil e eficiente
possível dentro de prazos e custos apropriados.
Desenhar processos eficientes e efetivos não apenas para a fase de Desenho do
Serviço, mas também para a transição, operação e qualificação de serviços de TI de alta
qualidade.
Identificar e gerenciar riscos para que os mesmos possam ser tratados antes da
implantação do Serviço. É bom lembrar que este trabalho começa a ser feito lá na Estratégia
do Serviço quando da verificação da viabilidade do serviço em termos financeiros e de
negócio.
Desenhar a infraestrutura de TI, ambientes, aplicativos e dados/informações seguras
e eficientes que possam atender as necessidades atuais e futuras do negócio.
Desenhar a forma de medir (métodos e métricas) a fim de avaliar a efetividade e a
eficiência do desenho do processo e seus entregáveis.
Produzir e manter os planos de TI, processos, políticas, arquiteturas, estruturas e
documentos.
Desenvolver perfil e habilidade dentro da TI, transformando atividades de estratégia e
desenho em atividades operacionais.
Contribuir para a qualificação geral do serviço de TI dentro das restrições de desenho
impostas.
Resumindo a ópera, podemos dizer que este estágio é responsável pelo desenho da arquitetura do
serviço no seu sentido mais amplo, ou seja, tratará de tudo o que o serviço precisa para que possa
atender as necessidades do negócio hoje e no futuro.
ITIL V3 – Desenho do Serviço – Conceitos e Definições – Quatro P's

O conceito que vamos abordar nesta postagem, em uma olhada mais superficial, pode parecer sem
importância ou apenas algo que é colocado nas metodologias para “encher linguiça”. Na verdade os
quatro P's do gerenciamento de serviços foram definidos porque os projetos, na vida real, falham por
falta de planejamento e gerenciamento. Tendo isso em mente, o gerenciamento de serviço deve tratar
da preparação para usar os 4p's descritos abaixo:
Pessoas – Definir e gerenciar quem vai participar da geração do serviço.

19

Processos – Planejar quais processos serão utilizados na confecção do serviço
Produtos – Entende-se como produtos, os serviços, tecnologias e ferramentas a
serem utilizadas na confecção do serviço.
Parceiros – Definir quem serão os parceiros na confecção do serviço.
Não precisamos dizer que os 4 P's são abordados por outras metodologias como o PMBOK, por
exemplo. Isso apenas corrobora a ideia de que não se deve nunca perder de vista a importância
desses aspectos do gerenciamento do serviço para o sucesso do empreendimento.
ITIL V3 – Desenho do Serviço – Conceitos e Definições – CincoAspectos do Desenho do Serviço

Se na postagem anterior verificamos os 4 P's do gerenciamento do serviço, nesta postagem veremos
os Cinco aspectos que devem ser considerados na fase de Desenho de Serviço. São eles:
Definição dos requisitos de serviço – Este aspecto detalha aquilo que foi colocado
na Estratégia do Serviço por meio dos PNS. Esta definição resulta na criação de RNS, ou
seja, os requisitos de nível de serviço, instrumento que antecede os acordos de níveis de
serviço – ANS. A fonte de busca de informações sobre os requisitos de um novo serviço ou da
alteração de serviços são encontrados no Portfólio de Serviço.
Sistemas e ferramentas de gerenciamento de serviço – Definição das
ferramentas a serem utilizadas na configuração, monitoração, incidentes, mudanças, testes e
guarda de informações do serviço no catálogo.
Desenho da tecnologia e da arquitetura – Trata da definição da infraestrutura e
dos padrões que irão suportar os serviços. Neste caso estamos falando de ferramentas de TI
e não de ferramentas de gerenciamento (definido no item anterior). Como exemplo da
definição da tecnologia e da arquitetura podemos citar a definição dos sistemas, do banco de
dados, da linguagem a ser utilizada, da arquitetura de rede e de infraestrutura necessária, etc.
Desenho do processo – Definir os processos referentes ao gerenciamento de
serviços de TI que devem ser utilizados, o workflow, etc. É importante salientar que neste
momento os processos são mais genéricos, sendo aprofundados mais nas outras fases do
ciclo de vida do serviço.
Desenho da medição – Como só é possível gerenciar o que se consegue medir, é
importantíssimo que na fase de Desenho do Serviço sejam definidos que tipo de métricas
serão produzidos para a medição do serviço, de que forma as informações serão
apresentadas, como serão obtidas e quais pessoas que devem acessá-las.
Tendo em vista estes cinco aspectos, o estágio do Desenho do Serviço inicia o seu trabalho com o
conjunto de requisitos para o novo serviço, ou a a alteração de serviço existente, e termina com o
desenvolvimento de uma solução de serviço desenhado para atender as necessidades documentadas
do negócio. Esta solução desenvolvida, conjuntamente com o seu Pacote de Desenho do Serviço
(PDS) é passada para a fase de Transição do Serviço para que a mesma possa avaliar, construir,
testar e instalar o novo serviço ou um serviço alterado. Sacaram?
Na próxima postagem, introduziremos um conceito bastante utilizado pelo ITIL. Com certeza a maioria
das pessoas já ouviu falar dele... Alguém tem algum palpite?
ITIL V3 – Desenho do Serviço – Conceitos e Definições –ANS

20

Caros leitores, nesta postagem estaremos falando um dos temas mais famosos do ITIL V3, o Acordo
de Nível de Serviço – ANS ou o SLA para os mais íntimos (Service Level Agreement).
Basicamente, um ANS é um acordo entre um provedor de serviço de TI e um cliente. Neste documento
deve estar descrito o serviço de TI que será prestado, as metas a serem cumpridas e as
responsabilidades tanto do provedor de serviço de TI quanto do cliente.
É importante salientar que um ANS pode cobrir vários serviços de TI ou vários clientes. Assim sendo,
cada organização deve achar a melhor forma de estruturar os seus ANS a fim de que os mesmos
garantam que todos os serviços estejam cobertos de acordo com a necessidade do negócio.
O ITIL V3 reconhece três diferentes tipos de ANS, a saber:
ANS baseado em Serviço – Este tipo de ANS acontece quando o provedor de
serviço de TI possui um padrão de ANS para um determinado serviço que será utilizado para
todos os clientes que tiverem aquele serviço.
ANS baseado em Cliente ou em Unidades de Negócio – Este tipo de ANS
acontece quando os níveis de serviço são agrupados por cliente ou por unidade de negócio,
embutindo neste todos os serviços que foram negociados para um determinado cliente ou
unidade de negócio.
ANS Multinível – Como o próprio nome sugere, este tipo de ANS é um híbrido entre
várias formas, como por exemplo: Acordo de Nível Corporativo, cobrindo todos os acordos
genéricos do gerenciamento de nível de serviço apropriados para cada cliente através da
organização (menos volátil); nível de cliente e nível de serviço, conforme descrito nos itens
anteriores.
Com toda a explicação dada acima surge a seguinte pergunta na cabeça dos leitores atentos e
questionadores: será que tendo um ANS bem montadinho é certeza de que a empresa estará
prestando um bom serviço de TI? E aí nobres leitores, como vocês responderiam esta pergunta, hein?
ITIL V3 – Conceitos e Definições –ANO e Contratos Subjacentes

21

Finalizamos a postagem anterior com a seguinte pergunta: ter um ANS bem montadinho é certeza de
que a empresa estará prestando um bom serviço de TI? Para responder esta pergunta precisamos
antes de mais nada olharmos para dentro de nossas organizações e verificarmos como estamos
estruturados a fim de atender as necessidades do negócio e especialmente honrar, da melhor forma
possível, o que foi acordado com o cliente quando da contratação de um serviço de TI.
Como diz minha mãe: “o combinado não sai caro”. Acho que foi pensando nesta pequena lei social que
o ITIL criou, com o intuito de garantir a entrega do serviço com os níveis contratados, o conceito do
Acordo de Níveis Operacinal (ANO), também conhecido como OLA (Operational Level Agreement) e os
contratos subjacentes ou Underpinnig Contracts (UI).
Por definição, um ANO é um acordo interno entre o provedor de serviço de TI e uma outra parte da
mesma organização que será responsável por apoiar a entrega do todo ou de parte do serviço de TI
vendido a um cliente externo. Com essa definição podemos inferir que o ANO foca nos requisitos
operacionais que os serviços precisam atender. Assim, respondendo a pergunta colocada no início
desta postagem, o fato de se ter um ANS que não esteja “coberto” pelo ANO representa um altíssimo
risco do ANS não ser cumprido, ocasionando multas e até secção do contrato.
Mas e quando a operação de um serviço de TI vendido a um cliente depende de entregas de parceiros
ou fornecedores de mercado e não apenas das áreas internas do próprio provedor do serviço de TI?
Para esses casos, extremamente comum nos dias de hoje, o ITIL prevê o uso dos contratos
subjacentes. Contrato, em sua definição, é um acordo legal que vincula duas ou mais partes, atribuindo
a cada um suas obrigações, direitos e deveres. Portanto, os contratos adjacentes são utilizados como
base para acordos com fornecedores externos, sempre que um compromisso obrigatório se faz
necessário.
Para finalizarmos esta postagem podemos dizer, então, que ter um ANS bem montado não é garantia
de entrega de serviço dentro dos parâmetros acordados. Para que isso aconteça faz-se necessário a
existência de acordos internos ou com fornecedores externos que permitam cobrar, formalmente, a
responsabilidade assumida por cada parte integrante na entrega do serviço.
ITIL V3 – Desenho do Serviço – Conceitos e Definições – Disponibilidade

Finalizando os conceitos do livro do ITIL que versa sobre o Desenho do Serviço, falaremos um pouco
nesta postagem sobre o termo Disponibilidade. Para início de conversa, o ITIL considera
Disponibilidade como sendo a competência de um serviço, componente ou item de configuração em

22

executar a função acordada quando requerida. Vejam que o grande lance aqui é perceber que a
Disponibilidade só deve ser calculada em relação ao que foi acordado e não em relação ao serviço
como um todo. Assim, podemos considerar que, geralmente, a Disponibilidade é medida e reportada
como porcentagem conforme a seguinte regra matemática:
Disponibilidade (%) = [(Tempo de Serviço Acordado (TSA) – Inatividade) / Tempo de Serviço
Acordado (TSA)] x 100%
onde.: Inatividade → Falhas sazonais, mudanças não planejadas ou mal planejadas, erros de
operacionalização, etc.
Contudo, não podemos esquecer que a Disponibilidade, mais do que um simples cálculo matemático, é
determinada por outros fatores que também devem ser considerados. São eles:
Confiabilidade→ Medição sobre quanto tempo um serviço, componente ou IC pode
executar sua função acordada sem interrupção. É medido e relatado como Tempo Médio entre
Incidentes de Serviço (TMEIS) ou Tempo Médio Entre Falhas (TMEF)
Sustentabilidade→ Medição de quão rápido um serviço, componente ou IC pode
ser recuperado ao estado normal depois de uma falha. É medido e relatado como Tempo
Médio de Recuperação do Serviço (TMRS)
Funcionalidade→ Medição sobre a competência de um fornecedor externo em
atender os termos do Contrato. Normalmente existem contratos subjacentes com os níveis a
serem atendidos.
Desempenho→ Medição das interrupções causadas por desempenho ou
capacidade. Medido por processos que tratam a capacidade do serviço.
Segurança→ Medição das interrupções causadas por incidentes de segurança.
Medido por processos que tratam da segurança da informação.
Para cada fator colocado acima também temos fórmulas matemáticas para identificá-los. Seguem
abaixo algumas dessas fórmulas:
Confiabilidade (TMEIS em horas) = Tempo de Disponibilidade em Horas / Número de Quebras
Confiabilidade (TMEF em horas) = (Tempo de Disp. Em horas – Tempo Total de parada em horas) /
Número de quebras
Sustentabilidade (TMRS em horas) = Tempo Total de Paradas em horas / Número de Quebras do
Serviço
Esses são os itens mais importantes para serem olhados quando estamos tratando de Disponibilidade
de um serviço de TI, porém pode ser que não sejam os únicos. Cada empresa pode considerar uma
gama maior de indicadores ou fatores que comporão a definição de Disponibilidade do serviço.
Bem, finalizados os conceitos vamos partir para as técnicas, ferramentas e modelos da fase de
Desenho do Serviço!
ITIL V3 – Desenho do Serviço – Técnicas, Ferramentas e Modelos – Catálogo de Serviços

Caros leitores, já havíamos falado do Catálogo de Serviços dentro do Portfólio de Serviço durante as
postagens referentes a etapa de Estratégia do Serviço, inclusive explicando por alto como o mesmo
funciona. Agora, vamos falar de uma forma mais aprofundada como esta ferramenta é utilizada pela
etapa do Desenho do Serviço.

23

O Catálogo de Serviços é um subconjunto do Portfólio de Serviço, que por sua vez, é membro
integrante do SGCS – Sistema de Gerenciamento do Conhecimento do Serviço. O Catálogo, na
verdade, é a única parte do Portfólio de Serviço da empresa prestadora de serviços de TI que fica
visível ao cliente.
Neste ponto, aqueles que já tiveram contato ou experiência com um Catálogo de Serviços podem estar
se perguntando: Será que todo o Catálogo fica visível ao cliente? Eu me lembro de coisas no Catálogo
que diziam respeito apenas a parte interna da empresa. Os clientes também viam essas informações?
Muito bem... muito bem! Na verdade, o Catálogo de Serviços possui dois aspectos fundamentais,
conforme explicação e figura a seguir.

Catálogo de Serviços de Negócio→ Esta parte do Catálogo é vista pelo cliente.
Ela facilita o entendimento do cliente em relação aos benefícios e valores, pois há a relação
do processo de negócio com o serviço oferecido.
Catálogo de Serviços Técnicos→ Esta parte do Catálogo é vista internamente pela
empresa prestadora de serviço de TI. Ajuda a identificar o que cada item de software ou
hardware contribui para a produção de um determinado serviço, ou seja, mostra como o
serviço é montado e o quê o compõe.
É interessante verificar que o Catálogo Técnico tem uma nítida função de suportar o Catálogo de
Negócio, além de ser uma importante ferramenta, como parte do Portfólio de Serviço, para a Estratégia
de Serviço, uma vez que é a projeção virtual das habilidades presentes no Provedor de Serviço de TI.

24

TIL V3 – Desenho do Serviço – Técnicas, Ferramentas e Modelos – PDS

Uma outra ferramenta utilizada pelo Desenho do Serviço, conforme prega o ITIL V3, é o famoso PDS
ou Pacote de Desenho de Serviço. Percebo que alguns leitores vão ler a frase anterior e dizer:
famoso? Hmmm, só se for para você Breno! Ok. Acho que exagerei um pouco. Na verdade, o PDS é
uma nova ferramenta implementada na versão 3 do ITIL.
O PDS não passa de um conjunto de documentos que define todos os aspectos de um serviço de TI e
seus requisitos. Ele agrupa todos as informações do Desenho do Serviço com todos os planos do
projeto e é utilizado através de cada estágio do ciclo de vida do serviço, ou seja, é passado e
consumido pelas outras fases do ciclo de vida.
Um PDS deve ser construído sempre que tivermos um novo serviço de TI que passará pela fase de
Desenho, mas não apenas para os novos serviços! Mudanças maiores em serviços já existentes
também devem ter PDS construídos.
Coloco abaixo o conteúdo do Pacote de Desenho de Serviço:
Categoria
Requisitos
Desenho de Serviços

Diagnóstico de Prontidão Organizacional
Plano de Ciclo de Vida de Serviço

Subcategoria
Requisitos de Negócio
Aplicabilidade de Serviço
Contatos de Serviço
Requisitos Funcionais de Serviço
Requisitos de Nível de Serviço
Requisitos de Gerenciamento Operacional de Serviço
Desenho de Serviços e Topologia
Diagnóstico de prontidão organizacional
Programa de Serviço
Plano de Transição de Serviços
Plano de Aceitação de Operação de Serviços
Critério de Aceitação de Serviço

A partir da próxima postagem, estaremos tratando dos processos da fase do Desenho do Serviço.
Vocês não perdem por esperar!!
ITIL V3 – Desenho do Serviço – Processos – Gerenciamento do Catálogo de Serviço

Amigos, a partir desta postagem entraremos no estudo dos processos do livro Desenho do Serviço do
ITIL V3. Nesta fase do ciclo de vida do serviço, são previstos os seguintes processos: gerenciamento
do Catálogo de Serviço, gerenciamento de Nível de Serviço, gerenciamento da disponibilidade,
gerenciamento da segurança da informação, gerenciamento de fornecedores, gerenciamento da
capacidade e o gerenciamento da continuidade de serviço de TI.
Vamos dar o pontapé inicial com o processo de gerenciamento do Catálogo de Serviço, certo? Como já
vimos em postagens anteriores, o Desenho de Serviço utiliza-se de forma constante do Catálogo de
Serviço, por isso, nada mais natural que esta fase do ciclo de vida do serviço tenha um processo
responsável por gerenciá-lo.
O objetivo principal do processo de gerenciamento do Catálogo de Serviço é, como o próprio nome já
diz, a gerência das informações existentes no Catálogo de Serviços. Na versão anterior do ITIL, esta

25

gerência era feita como uma atividade dentro do processo de gerenciamento do Nível de Serviço, mas
como o Catálogo ganhou um maior destaque na versão 3 do ITIL, uma vez que, em conjunto com o
banco de dados de configuração, se tornou uma ferramenta primordial para o gerenciamento do
serviço, passou a ter uma gerência própria.
O gerenciamento do Catálogo de Serviço busca garantir que o catálogo seja sempre acurado e reflita
os detalhes atuais, status, interfaces e dependências de todos os serviços que estão em operação ou
que estão sendo preparados para entrar em operação. Além disso, existem outras atividades dentro
deste processo, como por exemplo: acordo e documentação da definição de serviço com todas as
partes relevantes, manter relacionamento com o gerenciamento de Portfólio de Serviço para definir e
acertar o conteúdo do Portfólio de Serviço e do Catálogo de Serviço, entre outros.
ITIL V3 – Desenho do Serviço – Processos – Gerenciamento de Níveis de Serviço

Hoje falaremos sobre um dos mais importantes processos dentro da fase de Desenho do Serviço, o
Gerenciamento de Níveis de Serviço. O foco principal deste processo está no relacionamento e na
comunicação entre o provedor de serviço de TI e os clientes, ou seja, o processo de Gerenciamento de
Níveis de Serviço é responsável por garantir que a TI e os clientes tenham expectativas claras e
alinhadas sobre o nível de serviço a ser entregue.
Os principais instrumentos que são criados e gerenciados por este processo são os, já comentados em
outras postagens, Acordos de Nível de Serviço (ANS) e os Acordos de Níveis Operacionais (ANO).
É importante salientar que não faz parte do trabalho do Gerenciamento de Níveis de Serviço a gestão
dos contratos adjacentes. Ele se preocupará, apenas, com os níveis acordados em relação a um
serviço que necessita de fornecedores externos.
Não me recordo se já falei anteriormente aqui no blog, mas existe uma diferença vital que algumas
pessoas confundem quando o assunto refere-se à garantia de satisfação em relação a um determinado
serviço de TI. Pessoal! CLIENTE é diferente de USUÁRIO. Enquanto aquele refere-se à pessoa que
paga pelo serviço, este refere-se à pessoa que utiliza o serviço. Tendo isso em mente, podemos
afirmar que o Gerenciamento de Níveis de Serviço se preocupam em garantir a satisfação do CLIENTE
e não do usuário.
Além da criação dos ANSs e dos ANOs, o Gerenciamento de Níveis de Serviço é responsável pela
elaboração de outros produtos que são importantes para a gestão do serviço. Abaixo relaciono esses
produtos:
RNS (Requisitos de Nível de Serviço) – Esses requisitos fazem parte do PDS (ver
postagem sobre PDS). São baseados nos objetivos de negócio e usados para negociar
objetivos de Níveis de Serviço.
Tabela MANS (Monitoração de Acordos de Níveis de Serviço) – Esta tabela é
usada para monitorar um ANS e ajuda a identificar e reportar os resultados alcançados em
relação ao que foi acordado no ANS. É muito útil na gestão, uma vez que serve como
instrumento de cobrança em relação às áreas internas da empresa e instrumento de
comunicação e demonstração dos resultados com o cliente.
Finalizando este processo, precisamos falar que o Gerenciamento de Níveis de Serviço também
incentiva a criação de um PMS (Plano de Melhoria do Serviço). É papel deste processo, em conjunto
com a Melhoria de Serviço Continuada, que veremos mais para frente, instigar e provocar a criação de
um PMS, uma vez que tem visibilidade dos níveis acordados com os clientes, ou seja, as expectativas
definidas e o resultado prático da prestação do serviço contratado.

26

ITIL V3 – Desenho do Serviço – Processos – Gerenciamento de Disponibilidade

Continuando a nossa navegação pelos mares dos processos do Desenho do Serviço, convido-os a
conversarmos um pouco sobre o processo denominado de Gerenciamento de Disponibilidade. Este
processo tem os seguintes objetivos: fazer e manter atualizado um Plano de Disponibilidade, garantir
que o nível de disponibilidade entregues em todos os serviços atendam ou superem a necessidade de
negócio acordada, prover um ponto focal de gerenciamento para todas as ações relacionadas à
disponibilidade, ajudar no diagnóstico e na resolução da indisponibilidade relatada em incidentes e/ou
problemas e fazer com que medidas proativas sejam tomadas a fim de melhorar a disponibilidade dos
serviços, não se esquecendo, jamais, de verificar a viabilidade economica da solução.
Para auxiliar todo esse trabalho do Gerenciamento de Disponibilidade, o ITIL V3 criou a figura do SIGD
– Sistema de Informação do Gerenciamento de Disponibilidade. Este sistema não necessariamente
deve ser composto de uma única ferramenta. Na verdade, o que se pretende é ter uma suíte de
aplicações capaz de fornecer as seguintes informações relevantes para este gerenciamento: relatórios
de gerenciamento de disponibilidade, plano de disponibilidade, critérios de desenho da disponibilidade,
agenda de testes de disponibilidade, entre outros.
É importante salientar que o processo de Gerenciamento de Disponibilidade não trata da continuidade
do negócio e sim da disponibilidade dos serviços. Apesar de também pensar no futuro, o
Gerenciamento de Disponibilidade está preocupado mais com o dia-a-dia das organizações e na sua
capacidade de garantir a disponibilidade acordada com seus clientes.
Para clarificar melhor as atividades deste processo, o ITIL organizou-as em dois grandes grupos:
atividades reativas e atividades proativas. Vejamos a seguir as principais atividades desses dois
grupos:
Atividades reativas: monitoração da disponibilidade real entregue X metas
acordadas, definição de medidas de disponibilidade, validação com o negócio em relação às
metas de disponibilidade com a devida identificação de níveis de disponibilidade inaceitáveis e
os seus impactos sobre o negócio e qualificação contínua de atividades para otimizar a
disponibilidade.
Ações proativas: identificar as funções de negócio vitais, desenhar e pospectar a
disponibilidade e o plano de recuperação, entre outros.
As atividades relatadas acima podem suscitar uma dúvida. Monitoração é atividade reativa? Isso
mesmo meus caros amigos. Na verdade, a monitoração é reativa porque o ITIL considera que, ao
identificar um problema na monitoração, de fato, o problema ocorreu!
ITIL V3 – Desenho do Serviço – Processos – Gerenciamento da Segurança da Informação

27

Antes de falarmos desse processo propriamente dito, acho que vale a pena tratarmos um pouco do
assunto segurança da informação. O papo que informação é o ativo mais importante da empresa não é
novo e, apesar de ser realmente uma verdade, as empresas só entenderam a mensagem apenas de
alguns anos para cá. Ok, ok, sei que algumas empresas levam esse assunto a sério a algum tempo,
mas não é a realidade da maioria. Quer ver? Quem conhece alguma empresa onde os funcionários
deixam sobre suas mesas informações relevantes de reuniões realizadas, cópias de minutas de
contrato e outras coisas que possam ser utilizadas por outras pessoas de alguma forma? Pois é... isso
acontece lá no Japão e não aqui nas nossas empresas!!! (brincadeirinha...)
Tendo a nítida noção de que Segurança da Informação é assunto sério e relevante, o ITIL, na versão 3,
a promoveu a processo dentro do Ciclo de vida do Serviço. O processo de Gerenciamento da
Segurança da Informação possui, portanto, quatro grandes objetivos, a saber:
Disponibilidade: Garantir que a informação esteja disponível e utilizável quando
requerida
Confidencialidade: Garantir que a informação é observada e divulgada somente
àqueles que têm direitos de saber.
Integridade: Garantir que a informação esteja completa, acurada e protegida contra
modificações não autorizadas.
Autenticidade e não-repúdio: Garantir que a troca de informações comerciais entre
as empresas sejam confiáveis.
Vocês estão percebendo alguma semelhança do ITIL com as normas ISO (família 27000) que tratam
de segurança da informação? Pois é, o ITIL se baseou exatamente nessas normas para escrever o seu
processo. Assim sendo, não nos surpreende o ITIL ter adotado exatamente o mesmo ciclo PDCA
descrito nas referidas normas.

28

Para o ITIL, o processo de Gerenciamento da Segurança da Informação deveria ser o ponto focal para
todas as questões de segurança da informação e deveria, insistentemente, garantir que uma Política
de Segurança da Informação fosse criada, atualizada e que cobrisse todos os pontos de informações
de TI. Para isso criou o SGSI – Sistema de Gerenciamento de Segurança da Informação. Assim como
faz em outros processos, o ITIL não descreve o SGSI como uma ferramenta única, mas sim como um
grupo de instrumentos capazes de permitir o gerenciamento. Neste caso, o ITIL sugere que o SGSI
deva seguir o padrão da ISO 27001.
Já que falamos da Política de Segurança, acho legal dizermos que ela não pode ser muito genérica,
em que pese a possibilidade de ser inócua, nem pode ser muito densa, para evitar o engessamento da
organização. Além disso, não se faz Política de Segurança sem o patrocínio do alto escalão da
empresa e sem uma devida divulgação para todos, inclusive os clientes. Como sugestão, o ITIL aponta
que a Política de Segurança da Informação deveria estar referenciada em todos os RNS, ANS, ANO e
contratos adjacentes, além de ser revisada pelo menos uma vez ao ano.
TIL V3 – Desenho do Serviço – Processos – Gerenciamento de Fornecedores

O ITIL V3 especializou, como um processo a parte, as atividades relacionadas ao Gerenciamento de
Fornecedores. Na versão anterior, este processo era tratado dentro do processo de Gerenciamento de
Nível de Serviço, mas percebeu-se, com a maturidade do processo, que o relacionamento com
fornecedores deve ser algo mais abrangente do que simplesmente definir e monitorar os níveis de
serviços acordados.
Tendo isso em mente, o ITIL definiu os seguintes objetivos para esse processo: garantir que os
contratos adjacentes (underpinning contracts) com os fornecedores estejam alinhados com as
necessidades do negócio e que tenham desempenho satisfatório durante a sua vigência, gerenciar o
relacionamento com os fornecedores, criar e manter uma política de fornecimento e administrar uma
Base de Dados de Fornecedor e Contrato (BDFC).
Trocando em miúdos, este processo continua verificando se os níveis de serviço acordados com os
fornecedores estão sendo cumpridos, mas, além disso, ele também se preocupa com outros aspectos
do relacionamento com o fornecedor que vai desde a negociação do contrato, verificando se o contrato
condiz realmente com que o fornecedor estará de fato entregando, até um gerenciamento integrado de
todos os fornecedores baseado em um sistema e em uma política de fornecimento.
Como aconteceu em outros processos e como já dissemos acima, o ITIL sugeriu a criação de um
sistema chamado de BDFC – Base de Dados de Fornecedores e Contratos. Este sistema deve
documentar todas as informações de contratos e fornecedores com os principais atributos necessários
para garantir uma gestão dos contratos e dos fornecedores. Este sistema será parte integrante de um
outro sistema maior que falaremos em postagens futuras. Sei que algumas pessoas não aguentam de
curiosidade. Dessa forma, para não os matar de curiosidade, o sistema em questão, que o BDFC faz
parte é o SCGS – Sistema de Conhecimento de Gerenciamento de Serviço.
Gostaria de informar que estamos quase terminando os processos referentes ao Desenho do Serviço!
Nas próximas postagens estaremos verificando os dois últimos processos que faltam ser vistos, a
saber: o Gerenciamento de Capacidade e o Gerenciamento de Continuidade de Serviço de TI.
ITIL V3 – Desenho do Serviço – Processos – Gerenciamento da Capacidade

Falaremos nesta postagem do processo de Gerenciamento da Capacidade. Este processo parece ser
o grande calcanhar de aquiles de muitas organizações que prestam serviços de TI. Não é raro, no

29

mercado de serviços de TI, verificarmos empresas que vendem algo que sabem, ou pelo menos
deveriam saber, que não têm condições de entregar. Isso, na minha humilde opinião, é dar um tiro no
próprio pé! É claro, e não quero passar a impressão de ingenuidade, que existem outros fatores que
estão ligados a venda de serviços de TI, especialmente no que tange a venda de serviços para
governo, mas mesmo assim, vender algo que não se sabe se tem ou se terá capacidade de entregar é
algo no mínimo arriscado, em uma visão mais eufemista.
Para tentar minimizar esse problema, o ITIL disponibiliza o processo chamado de Gerenciamento da
Capacidade. Este processo tem como objetivo principal confeccionar e manter um Plano de
Capacidade e Desempenho adequado e atualizado, garantindo que uma capacidade de TI,
financeiramente justificada, será sempre provida a todas as áreas de TI a fim de atender as
necessidades do negócio (desempenho inclusive), atuais e futuras, que estejam acordadas.
Chamo atenção de vocês para duas expressões importantes utilizadas no parágrafo acima:
“financeiramente justificada”. Gerenciar capacidade resume-se essencialmente na
habilidade em balancear os custos e a necessidade de recursos para provimento de uma
determinada demanda de negócio. A capacidade tem que ser justificada financeiramente em
termos das necessidades de negócio e do uso mais eficiente dos recursos. Se isso não
acontecer, cairemos no erro que pode ser melhor explicado pelo trecho de uma música que
diz: “todo mundo quer ir para o céu, mas ninguém quer morrer”, ou seja, todo mundo quer o
que há de mais novo e moderno em termos de serviços de TI, mas poucos querem bancar por
essa modernidade.
“atuais e futuras”. O Gerenciamento de Capacidade não pode se ater apenas ao
que está sendo entregue hoje. É primordial que esse trabalho esteja também olhando para o
futuro e definindo a capacidade para o crescimento. Sob esse aspecto, entra outra habilidade
essencial do Gerenciamento da Capacidade, qual seja: o saber balancear o provimento do
serviço contra a demanda feita, ou seja, garantir que o provimento do serviço de TI atende as
demandas feitas pelo negócio, tanto agora como no futuro.
Fechando a ideia desse processo, o Gerenciamento de Capacidade deve ser o ponto central de
gerenciamento para todas as questões relacionadas a capacidade e desempenho. Além do Plano de
Capacidade, este processo é o responsável por fazer a gestão de três outros subprocessos: o
Gerenciamento da Capacidade do Negócio, que vai estudar e entender os requisitos futuros de
negócio; o Gerenciamento da Capacidade do Serviço, que trata do desempenho e da capacidade atual
e o Gerenciamento da Capacidade do Componente, que trata da capacidade, utilização e desempenho
dos itens de configuração.
TIL V3 – Desenho do Serviço – Processos – Gerenciamento da Continuidade de Serviço de TI

Amigos leitores, com essa postagem encerramos todos os processos da fase do Desenho do Serviço
dentro do ciclo de vida do serviço preconizado pelo ITIL. O processo que vamos tratar aqui necessita
de algumas premissas que temos que explorar. A primeira premissa é entender exatamente como o
ITIL entende a palavra desastre. Quando ouvimos falar em desastre, nossa mente automaticamente
faz associação com acontecimentos trágicos e de grandes proporções, como por exemplo: terremotos,
enchentes, vulcões, tsunamis, acidentes, terrorismo, etc. De fato, todos os exemplos citados são
considerados como desastres, porém, na visão do ITIL, o desastre pode ser qualquer acontecimento
que comprometa de forma inequívoca a prestação do serviço de TI. Assim sendo, fatos mais simples e
rotineiros como uma greve ou uma pane em um determinado sistema de comunicação podem ser
considerados desastres dentro da ideia do ITIL.
A segunda premissa que temos que ter em mente é que a continuidade do serviço de TI é uma parte

30

integrante da continuidade do negócio, mas as duas não podem ser confundidas, uma vez que aquela
é apenas um subset desta e que a continuidade de negócio englobará outros planos de continuidade
como o da área de RH, de logística, financeira, entre outros. Essa diferença fica mais difícil de se
entender quando o negócio da empresa é TI. Neste caso, a continuidade dos serviços de TI
provavelmente será o carro-chefe de todos os planos de continuidade do negócio, pois TI, neste caso,
é o negócio.
Entendido essas duas premissas podemos dizer que o processo de Gerenciamento da Continuidade
de Serviço de TI tem como principal objetivo manter um conjunto de Planos de Continuidade de
Serviços de TI e os planos de recuperação que suportam os planos de continuidades de negócio. Ah!
Já ia me esquecendo, mas não podemos deixar de dizer que Plano de Continuidade é diferente do
plano de recuperação. Enquanto este se preocupa em voltar a situação do serviço de TI ao ponto
anterior ao desastre, aquele se preocupa em fazer com que o serviço de TI continue, mesmo que
temporariamente, durante um desastre.
O processo de Gerenciamento da Continuidade de Serviço de TI, além do objetivo descrito acima,
possui uma série de outros objetivos, como por exemplo: atualizar regularmente um documento
chamado de AIN – Análise de Impacto no Negócio ou BIA para os mais íntimos (Business Impact
Analysis); conduzir regularmente exercícios de análise e gerenciamento de riscos; fornecer
aconselhamento e orientação para todas as outras áreas do negócio e de TI em todas as questões de
continuidade relacionadas com a recuperação, entre outros.
É bom lembrar, também, que o Gerenciamento da Continuidade de Serviço de TI é mais amplo do que
o Gerenciamento de Disponibilidade, uma vez que este se preocupa com a disponibilidade do serviço
no presente e no futuro, enquanto que o Gerenciamento da Continuidade de Serviço de TI tem o foco
na continuidade do serviço em caso de desastre.
Para terminar, gostaria de elencar as interfaces que interagem com o Gerenciamento da Continuidade
de Serviço de TI. Além do BIA, já comentado acima, existem ainda: PCN – Plano de Continuidade do
Negócio, que define os passos necessários para restaurar processos de negócio após um desastre;
GCN – Gerenciamento da Continuidade do Negócio, responsável por gerenciar os riscos que podem
afetar gravemente os negócios; Análise de Riscos, que dispensa explicações.
Terminados os processos, vamos entrar agora na parte da tecnologia e da arquitetura da fase do
Desenho do Serviço.
ITIL V3 – Desenho do Serviço – Tecnologia eArquitetura

Seguindo a estrutura de tópicos proposta quando começamos a falar do ITIL V3 e finalizado todos os
processos, falaremos nesta postagem da Tecnologia e da Arquitetura para a fase do Desenho do
Serviço no ciclo de vida do serviço.
Para esta fase, existem várias ferramentas e técnicas que podem ser utilizadas para que os processos
desta fase possam ser desempenhados com eficiência. Prestem bastante atenção no que dissemos na
sentença anterior! É importante se lembrar que as ferramentas devem suportar os processos e não o
contrário. Sendo assim, as ferramentas utilizadas no Desenho do Serviço devem ser capazes de
habilitar o desenho de hardware, o desenho de software, o desenho dos ambientes, o desenho dos
processos e o desenho dos dados.
Como dissemos, existem várias alternativas de ferramentas e técnicas que podem atender às
necessidades de cada empresa e, particularmente, acho que a escolha da melhor ferramenta depende
do negócio e das políticas existentes. Uma boa prática na escolha da ferramenta é não esperar que
100% dos requisitos sejam atendidos. Existe uma pesquisa, acho que é do Gartner group, mas não

31

tenho certeza, que diz o seguinte: "uma ferramenta adequada para atender a um propósito específico é
aquela que antede 80% ou mais dos requisitos do negócio". Cabe aqui uma pequena ressalva, é
importante salientar que dentro dos 80% dos requisitos atendidos, todos os requisitos mandatórios
devem estar contemplados. Parece óbvio, mas não é...
O ITIL preconiza que, seja qual for o tipo de ferramenta escolhida, o atendimento dos requisitos pode
ser diferenciado entre:
Padrão de Fábrica. Os benefícios que atendem aos requisitos vêm de fábrica.
Configuração. A ferramenta pode ser configurada para atender o requisito e esta
configuração será preservada para todas as atualizações do produto.
Customização. A ferramenta tem que ser alterada para atender o requisito. As
atualizações do produto podem ser alvos de outras customizações para não perder a
especificidade requerida.
Finalizamos a fase do Desenho do Serviço no ciclo de vida do serviço preconizado pelo ITIL V3. A
partir da próxima postagem, entraremos em uma nova fase, a Transição do Serviço.
ITIL V3 – Transição do Serviço – Metas e Objetivos

Nesta postagem damos início a uma nova fase do ciclo de vida do serviço segundo o ITIL V3,
conhecida como Transição de Serviço!!
A meta principal desta fase é assegurar que tudo aquilo que foi planejado seja executado de fato. É

32

claro que no mundo real, nem tudo o que é planejado consegue realmente ser executado, mas a
Transição do Serviço deve buscar que o planejamento se torne realidade e se materialize em um
serviço de TI. Essa meta ambiciosa, para que possa ser atingida, é dividida em outras metas que a
ajudam na caminhada, como por exemplo: definir, alinhar e validar as expectativas dos clientes sobre o
desempenho e a utilização dos novos serviços e também daqueles que foram alterados, diminuir ao
máximo as variações de desempenho na transição dentro da produção, minimizar erros conhecidos a
fim de controlar melhor os riscos da transição dentro da produção e garantir que o serviço possa ser
utilizado de acordo com os requisitos especificados.
Para atingir as metas, alguns objetivos foram definidos. Dentre eles, destaco os seguintes:
Planejar e gerenciar os recursos do serviço de TI, seja ele novo ou não, no ambiente
de produção.
Criar planos claros que permitam que mudanças no negócio ou no cliente alinhem
suas atividades com os planos de transição do serviço.

serviços.

Melhorar a satisfação do cliente, assim como o da equipe do gerenciamento de

Garantir que haja o mínimo impacto possível para os imprevistos que ocorram no
ambiente de produção (tarefa nada fácil em alguns casos!!).
Bem, tendo em mente as metas e objetivos da fase de Transição do Serviço, daremos continuidade
com os conceitos e definições importantes para que possamos entender os processos que compõem
esta importante fase do ciclo de vida do serviço...
ITIL V3 – Transição do Serviço – Conceitos e Definições – IC – Item de Configuração

33

Inciando os conceitos e definições referentes à Transição do Serviço, falaremos nesta postagem de um
conceito bem antigo do ITIL, o Item de Configuração (IC). Um Item de Configuração é qualquer
componente que necessite ser administrado para que um determinado Serviço de TI possa ser
entregue. Parece amplo, e é mesmo. A figura colocada nesta postagem faz uma analogia com o
conceito que acabamos de falar. Imagine que o Serviço a ser prestado seja alimentar uma família de
forma equilibrada. Neste exemplo, a geladeira, a comida, as bebidas, a energia, entre outros seriam os
Itens de Configuração do Serviço, sacaram?
Existe uma grande variedade de ICs que vão desde serviços de TI, hardware, software e ANS (acordos
de níveis de serviço) até pessoas, prédios, documentação formal, entre outros. Devido a esta grande
variedade, o ITIL classificou os ICs nas seguintes categorias:
ICs de Ciclo de Vida de Serviço – Esses ICs formam uma visão dos serviços
prestados pela empresa de serviços de TI, definem como são entregues, quais benefícios e
qual o custo de produção. Como exemplo, podemos citar: Planos de Gerenciamento de
Serviços, Casos de Negócio, Planos de Ciclo de Vida de Serviço, etc.
ICs de Serviço – Esses ICs podem ser subdivididos em Ativos de Competência do
Serviço (gerenciamento, organização, processos, conhecimentos, pessoas, etc) e em Ativos
de recurso do Serviço (capital financeiro, sistemas, aplicativos, dados, infraestrutura,
instalações, informações, pessoas – de novo -, etc).
ICs de Organização – Dizem respeito a alguma documentação que identifique as
características de um IC.
ICs Internos – São os IC usados em projetos individuais da prestadora de serviços
de TI, como por exemplo: data center (tangíveis) e softwares (intangíveis). São necessários
para entregar e manter um determinado serviço de TI.

34

ICs Externos – Como o próprio nome já diz, são os ICs que tratam de serviços
externos além dos acordos e requisitos do cliente.
ICs de Interface – São os ICs necessários para a entrega fim a fim dos serviços.
Apesar de ser amplo, os ICs não são “a casa da mãe Joana”. Não podemos nos esquecer que o
gerenciamento de itens de configuração será o responsável por definir o que deve entrar no escopo
deste gerenciamento e o que deve ser deixado de fora. Os ICs devem ser selecionados utilizando
critérios estabelecidos, agrupados, classificados e identificados de uma forma que permita a
rastreabilidade e a administração dos mesmos durante todo o ciclo de vida do serviço.
Além disso, é claro que os IC devem estar armazenados em um sistema, que falaremos com um pouco
mais de profundidade em outra postagem, chamado de SGC (Sistema de Gerenciamento de
Configuração).

ITIL V3 – Transição do Serviço – Técnicas e Ferramentas – Sistemas e mais sistemas...

O ITIL V3 descreveu uma série de sistemas e ferramentas para suportar os processos responsáveis
pela gestão dos serviços de TI. Dentro da fase de Transição do Serviço, o ITIL elencou as seguintes
ferramentas que falaremos nesta postagem: SGC (Sistema de Gerenciamento de Configuração),
BDGC (Banco de Dados do Gerenciamento da Configuração), BMD (Biblioteca de Mídia Definitiva) e o
SGCS (Sistema de Gerenciamento do Conhecimento do Serviço).
SGC (Sistema de Gerenciamento de Configuração)
O SGC é uma ampliação do famoso CMDB da versão 2.0 do ITIL. Sua principal função é criar e manter
os relacionamentos dos componentes (itens de configuração) que fazem parte de um determinado
serviço de TI ofertado. O SGC é composto do modelo lógico, que representa graficamente os vínculos
entre os mais diversos itens de configuração responsáveis por configurar um determinado serviço de
TI, e do BDGC, onde, a grosso modo, ficam registrados os atributos de cada item de configuração.
BDGC (Banco de Dados do Gerenciamento da Configuração)
Como dissemos acima, o BDGC registra os atributos de cada item de configuração responsável pela
montagem da árvore de relacionamento para identificação de cada serviço de TI. O BDGC conta
também com as bases onde estão guardados os bancos de dados de incidentes, problemas e
mudanças, uma vez que possui a responsabilidade de manter as informações de configuração de cada
item de configuração durante todo o ciclo de vida do serviço.
BMD (Biblioteca de Mídia Definitiva)
Esta biblioteca é responsável por manter a matriz de alguns sistemas. Entende-se matriz como sendo
a cópia original de Software de um determinado sistema. Prestem bastante atenção nisso, o BMD
preocupa-se com o software e não com o hardware necessário para o funcionamento do sistema. Sob
este aspecto, devemos considerar software como sendo, não apenas o programa propriamente dito,
mas também a parte de licenças de uso daquela aplicação.
Outro aspecto importante sobre o BMD é que a biblioteca não deve se preocupar apenas com os
softwares de serviços que estão em produção, mas sim com todos os softwares, inclusive aqueles que

35

não estão mais em produção, caso seja necessário restaurá-los em algum momento do tempo. Cabe
aqui uma pequena reflexão que o ITIL não trata. O que fazer caso o software guardado necessite de
uma infraestrutura que já não existe mais no mercado nem na organização? O que fazer? Bem, na
minha singela opinião, cada organização deve manter um programa de verificação anual para descarte
ou transformação de alguns softwares para manter uma certa compatibilidade com a infraestrutura
mínima disponível para sua execução. Essa é a minha opinião, pois o ITIL não trata este assunto de
forma direta.
SGCS (Sistema de Gerenciamento do Conhecimento do Serviço)
O SGCS é um grande sistema montado por várias outras ferramentas. Entre elas podemos citar o
próprio SGC e, como consequência, o BDGC, comentados acima. O objetivo principal deste sistema é
o de administrar o conhecimento e as informações dos serviços de TI da organização. Parece simples,
mas não é. Independentemente de qualquer sistema, manter o conhecimento é uma tarefa árdua, que
exige planejamento de treinamentos constantes e manutenção das informações relevantes para que
um serviço possa ser administrado e prestado com qualidade constante.
ITIL V3 – Transição do Serviço – Conceitos e Objetivos – DICS

O DICS, também conhecido como DIKW(em inglês), é a sigla utilizada para a seguinte definição: Dado
- Informação - Conhecimento - Sabedoria. Na verdade, retrata o processo evolutivo que faz com que
um dado se transforme em sabedoria. Vejamos como.
A evolução pode ser medida em termos do Contexto e do Entendimento. Se fizermos um Gráfico,
conforme a figura abaixo (colocada em Inglês), poderemos entender a evolução do conhecimento com
os seguintes conceitos:

Dado (Data): conjunto de fatos. O famoso dado cru.
Informação (Information): é o dado contextualizado. Permite julgamento de valor e
responde as perguntas: Quem? O quê? Quando? Onde?
Conhecimento (Knowledge): composto de experiências, sejam elas tácitas ou não.
É a informação acumulada sobre um determinado assunto. Permite identificar o “como” as

36

coisas são feitas.
Sabedoria (Wisdom): Representa o conjunto de conhecimentos e permite identificar
o “porquê” as coisas devem ser feitas.
Tenho nítida noção que este tipo de conceito se aproxima mais do campo filosófico do que da
informática, mas ele será primordial quando tratarmos do Gerenciamento do Conhecimento, processo
que trataremos mais tarde na fase de Transição do Serviço.

ITIL V3 – Transição do Serviço – Conceitos e Definições – Unidade de Liberação

Dando continuidade aos conceitos e definições que fazem parte da fase de Transição do Serviço,
falaremos nesta postagem da famosa Unidade de Liberação. Este nome, que pode parecer complicado
ao primeiro contato, significa, na verdade, um conjunto de componentes de um serviço de TI, incluindo
infraestrutura e software, que é, costumeiramente, liberado em conjunto, de acordo com uma política
definida pela organização.

Vamos tentar melhorar o entendimento, ok? Para facilitar, disponibilizei a figura acima. Imaginemos o
Sistema X que possui alguns módulos. A ideia aqui é identificar que uma Unidade de Liberação é
composta pelos produtos suficientes para desempenhar plenamente uma determinada função
(triângulos amarelo e verde). Assim, no exemplo utilizado, quando houver uma mudança no Módulo 1
do Sistema X, todo o triângulo amarelo deve ser avaliado antes da efetivação da mudança.
É importante salientar ainda que existem áreas de intersecção entre Unidades de Liberação, como
podemos ver na figura. Neste caso, a complexidade aumenta, uma vez que o trabalho de mudança
necessita verificar itens que podem impactar outros módulos que não estão sendo, inicialmente, alvo
da mudança.
Acho que não preciso mencionar, mas para não dizer que não falei de flores: é extremamente
necessário que haja um sistema de configuração bem montado para que os componentes que fazem

37

parte de uma determinada Unidade de Liberação possam ser identificados e mapeados.
Finalizando o assunto, para que se possa fazer um gerenciamento efetivo das mudanças ocorridas nas
Unidades de Liberação, faz-se necessário a criação de uma Linha de Base. A Linha de Base funciona
como uma referência que poderá ser usada como ponto de partida em futuras comparações. Além
disso, serve também como ponto de recuperação, caso uma Mudança ou Liberação falhar e como
ponto de identificação e rastreamento quando da alteração de um IC.
ITIL V3 – Transição do Serviço – Conceitos e Objetivos – Mudança de Serviço

Na visão do ITIL, uma mudança significa a adição, a modificação ou a remoção de um determinado
serviço de TI ou ainda de um componente de um determinado serviço de TI que tenha sido autorizada,
planejada ou suportada. Isso significa dizer que o escopo de uma mudança inclui todos os Serviços de
TI, os itens de configuração, os processos, as documentações, etc. Vocês podem estar se
perguntando: documentações? Processos? Siiimmmm caro leitor, uma mudança de um contrato, por
exemplo, pode ser encarada como uma mudança do serviço de TI.
Toda mudança deve ser feita por meio de uma RDM (requisição de mudança). Este documento é um
pedido formal e padronizado da mudança que se pretende fazer. Uma RDM deve conter os detalhes da
mudança e seguirá um rito processual de acordo com o tipo de mudança que está sendo proposto.
Para facilitar o entendimento de quais atividades devem ser efetuadas, o ITIL define três diferentes
tipos de mudança, a saber:
Normal: É o caminho comum da mudança, ou seja, são regras gerais que valem
para todas as mudanças.
Padrão: é aquela executada em um serviço ou na infraestrutura para a qual é
utilizada uma abordagem pré-autorizada. Normalmente acontece com mudanças de baixo
impacto que possuem atividades bem conhecidas e documentadas e cuja autorização é dada
antecipadamente.
Emergencial: está reservado para alterações que têm o objetivo de concertar um
erro em um serviço de TI que está impactando negativamente o negócio. Normalmente possuem um
critério par serem feitas, como por exemplo, a necessidade de aprovação.
ITIL V3 – Transição do Serviço – Técnicas e Ferramentas – Política de Liberação

Nesta postagem vamos explorar uma técnica, que no final de sua utilização se torna uma ferramenta
importantíssima para a administração dos ambientes de serviço de TI: a Política de Liberação. Esta
política materializa-se em um documento formal que tem o papel principal de organizar a forma de
liberação das versões e das distribuições dos serviços de TI.
A Política de Liberação deve conter algumas informações básicas, como por exemplo: papéis e
responsáveis, identificação das liberações, convenções de nomenclatura dos diferentes tipos de
liberação, definição da janela a ser utilizada para liberações de versões e definição dos tipos de
liberações existentes na organização.
Trocando em miúdos, como dizia o meu avô, a Política de Liberação deve tratar as regras gerais para a
operação dos ambientes, não apenas daqueles que estão em produção, mas também os ambientes de
homologação, treinamento, desenvolvimento, testes, etc.

38

Um aspecto importante da Política de Liberação é a estratégia para implantação de determinadas
versões. Existem algumas alternativas, como por exemplo: a estratégia de implantação Faseada, onde
a liberação de versões ocorre para um grupo de máquinas específico que será atualizado em um
determinado momento. Nesta estratégia, novas máquinas aguardarão a próxima fase da implantação
para receberem, também, as atualizações. Outra estratégia é conhecida como “Big bang”. Nesta
estratégia, todas as máquinas aptas a receber a nova versão são atualizadas. A partir daí, a cada nova
máquina há uma atualização individual. Existem outras estratégias que são menos importantes, mas o
entendimento que queremos passar é o da importância de cada serviço ter a sua estratégia, assim
sendo, cada organização deve analisar a melhor forma de fazer as liberações e as distribuições para
os seus serviços de TI.
A partir da próxima postagem, entraremos nos processos da fase de Transição do Serviço!

ITIL V3 – Transição do Serviço – Processos – Gerenciamento de Mudanças

Nessa postagem falaremos de um dos processos mais testados, discutidos, aplicados e importantes da
fase de Transição do Serviço: o famosíssimo Gerenciamento de Mudanças. No ITIL V3, o
Gerenciamento de Mudanças é o responsável por atender aos requisitos das mudanças que
acontecem nos serviços e no negócio dos clientes sem perder de vista a busca pela maximização do
valor e pela redução de incidentes, paradas não programadas e/ou retrabalhos.
De certa forma, o Gerenciamento de Mudanças materializa os requisitos que estão vindo da fase de
Desenho do Serviço, mas é importante salientar que não é responsabilidade do Gerenciamento de
Mudanças implementar a mudança (“botar a mão na massa”). O seu papel se baseia mais na
coordenação, gestão e acompanhamento do processo. Assim sendo, podemos dizer que o

39

Gerenciamento de Mudanças visa garantir que métodos e procedimentos padronizados sejam
utilizados para que as mudanças possam atingir seus objetivos. Trocando em miúdos, o
Gerenciamento de Mudança zela para que as mudanças possam seguir um rito formal, mas ágil
quando necessário, que vai desde o registro da mudança até a sua implementação, passando pelo
planejamento, pela avaliação, pela autorização (quando necessário) e pela documentação.
Não é nossa intenção descrever cada atividade do Gerenciamento de Mudanças aqui no nosso
humilde blog, mas existem informações que valem a pena serem colocadas. A primeira informação que
julgo relevante diz respeito ao fato de que a mudança pode ser qualquer coisa que possa ser
classificada e altere um estado de um item de configuração. Isso que dizer que uma mudança pode ser
de um projeto, assim como pode ser de um serviço de TI. Desta forma podemos dizer que todas as
outras fases do ciclo de vida do serviço podem utilizar-se do processo de Gerenciamento de Mudança.
Outra informação relevante é a de que uma mudança pode ser classificada de diferentes formas. Cada
classificação indicará a forma como o processo de mudanças será conduzido. Mudanças Padrões, por
exemplo, são mudanças que tem um risco baixo, são pré-aprovadas e são mais comuns do dia a dia.
Mudanças mais complexas podem necessitar de análise mais profunda, criação de planos de
recuperação e necessidade de validação por parte de alguns comitês. Por falar em comitês, o ITIL V3
fala dos seguintes comitês de aprovação de mudanças:
CCM (Comitê Consultivo de Mudanças). Comitê composto por pessoas do negócio e
pessoas da área técnica. Tem a função de aconselhar como uma determinada mudança
deverá ocorrer em termos de avaliação, agendamento e priorização
CCME (Comitê Consultivo de Mudanças Emergenciais). Este comitê é um
subconjunto do CCM e é responsável por decidir sobre mudanças de alto impacto que sejam
emergenciais.
ITIL V3 – Transição do Serviço – Processos - Gerenciamento de Configuração eAtivos do Serviço

Continuando a nossa viagem pelos processos da fase de Transição do Serviço do ciclo de vida dos
serviços preconizado pelo ITIL V3, falaremos nesta postagem sobre o Gerenciamento de
Configurações e Ativos do Serviço. Se pudéssemos resumir os objetivos desse processo em uma única
palavra, essa palavra seria, sem sobra de dúvidas, CONTROLE. O Gerenciamento de Configuração é
um processo base que suporta outros processos de Gerenciamento de Serviços a fim de que os
Controles sobre os serviços de TI e seus ativos estejam disponíveis para os diversos processos.
Apesar de parecer óbvio, é bom lembrar que o Gerenciamento de Configuração tem que ser muito bem
conduzido para que ele possa prover informações sobre as configurações dos serviços de TI de forma
precisa, diminuindo ao máximo problemas de qualidade e conformidade na entrega dos serviços por
causa de configurações falhas dos ativos e dos próprios serviços. Sobre esse aspecto, devemos
lembrar que o Gerenciamento de Configuração é muito mais complexo do que um inventário, uma vez
que um inventário simples traria muita informação que não faria sentido para o serviço de TI e o
Gerenciamento de Configuração tem o papel de elencar e relacionar todos os ativos, serviços e
infraestrutura de forma a encadear todas as dependências entre os itens de configuração que afetam
um determinado serviço de TI . Além disso, um item de configuração pode ser qualquer coisa que
impacte na prestação do serviço, incluindo aí, além dos ativos mais óbvios de infraestrutura, ativos
como ANS, ANO, Serviços Técnicos, Serviços de Apoio, Softwares, etc.
Outra informação importante diz respeito a algumas atividades desse processo. O Gerenciamento de
Configuração deve definir o escopo do que será gerenciado de forma a uniformizar o processo de
gerência sobre os itens de configuração dos serviços. Mudanças que porventura venham a acontecer
em uma determinada configuração de um serviço deve ser feita por meio do Gerenciamento de

40

Mudança (ver postagem anterior para mais informações sobre esse importante processo) e finalmente,
o processo de controle e aperfeiçoamento dos mecanismos deve sermpre ser melhorado, com o
aumento da maturidade neste processo.
ITIL V3 – Transição do Serviço – Processos – Gerenciamento de Liberação e Implantação

O processo de Gerenciamento de Liberação e Implantação é o responsável por executar a instalação
de pacotes de liberação. Na verdade, este processo, além de instalar, é responsável também por
construir, testar e implantar os pacotes de liberação. Vocês podem estar se perguntando, mas o que é
um pacote de liberação? Segundo o ITIL, um pacote de liberação é composto de todos os itens
necessários para que uma determinada mudança de um serviço ou a implantação de um novo serviço
possa ser feito de forma completa, ou seja, estamos falando não apenas do serviço propriamente dito,
em relação a software e hardware, mas também de documentos, correlacionamentos entre serviços,
etc.
Pelo o que podemos perceber, a palavra chave desse processo é planejamento. O processo de
Gerenciamento de Liberação e Implantação deve garantir a confecção e manutenção de planos
suficientemente claros e abrangentes para que as mudanças ou implantações de novos serviços
possam acontecer sem grandes impactos. Por ser um processo que “mete a mão na massa”, ele
interage com uma série de outros processos do ITIL, especialmente os processos de Gerenciamento
de Mudança e o Gerenciamento de Configuração.
Outro ponto importante em relação ao Gerenciamento de Liberação e Implantação que não pode ser
negligenciado, é o Suporte para Período de Funcionamento Experimental (SPFE). Este suporte faz, na
verdade, uma operação assistida, por um determinado período tempo até que haja a estabilização do
serviço que foi implementado ou que foi alterado.
ITIL V3 – Transição do Serviço – Processos - Gerenciamento do Conhecimento

Nesta postagem finalizamos os processos da etapa de Transição do Serviço do ITIL V3 com o
processo chamado de Gerenciamento do Conhecimento. Este processo trata de um assunto onde 100
em cada 100 empresas entendem que é de suma importância para a prestação de serviço com
qualidade e eficiência, mas muitas empresas continuam tendo muita dificuldade em fazer, na prática,
com que seja de fato implementado. Quem nunca falou com uma empresa onde, dependendo da
pessoa ou da área que te atende, a informação chega a ser oposta àquela dada por uma outra área da
mesma empresa? Este tipo de problema expõe o prestador de serviço de forma extremamente
negativa e tira a confiança dos clientes quanto ao serviço prestado.
Por ser um processo utilizado por todos os outros processos do ITIL, o Gerenciamento do
Conhecimento tem como meta principal certificar-se que a informação certa (confiável e integra) é
entregue a pessoa correta (desde o atendente até o presidente) e no tempo hábil (tempestivamente)
para que a mesma possa tomar decisões. Parece simples e bastante óbvio, mas na prática, a história é
outra. O segredo para que a coisa toda funcione está na criação de métodos e ferramentas
automatizadas de forma que a informação possa ser disseminada de forma eficiente. Existem uma
série de ferramentas que prometem o paraíso, no que diz respeito à disseminação de informação, mas
atentem-se que inundar a organização com informações irrelevantes pode ser tão nocivo quanto não
disseminar informação alguma. Assim, os processos e responsabilidades devem estar bem descritos,
para que a ferramenta possa agir de acordo com a política da empresa e seus processos e não o
contrário.
Segundo o ITIL, algumas informações seriam básicas para que os processos possam tomar decisões

41

sobre um determinado serviço, entre elas podemos citar: qual o serviço, quem o está utilizando, o
estado atual, as dificuldades, restrições e impactos no serviço, etc.
Queridos leitores, finalizamos a fase de Transição do Serviço. A partir das próximas postagens
entraremos na fase de Operações de Serviço, dentro do ciclo de vida do serviço preconizado pelo ITIL
V3. Esta fase possui os processos mais maduros que vieram das versões anteriores do ITIL e acredito
que grande parte dos leitores desse blog já se familiarizaram com alguns dos processos. O desafio é
trazer informações novas e que sejam relevantes para uma gestão inteligente de TI... Vamos juntos?

ITIL V3 – Operação do Serviço – Metas e Objetivos

Iniciamos nesta postagem a falar de uma nova etapa do ciclo de vida do serviço, a Operação do
Serviço. Após todo o trabalho realizado nas outras etapas (estratégia, desenho e transição), chega o
momento em que o cliente, de fato, irá perceber os benefícios do serviço de TI contratado por ele.
Nesta etapa do ciclo de vida, espera-se que um novo serviço ou um serviço que tenha sido alterado
esteja pronto para encarar a “batalha” do dia a dia.
Diante desse desafio, o ITIL definiu como metas da Operação do Serviço, a coordenação e a execução
de processos e/ou atividades necessárias para que o serviço de TI contratado seja entregue e possa
funcionar de acordo com os níveis de serviços acordados. Além disso, a Operação do Serviço não
deve deixar de fazer a gestão da tecnologia utilizada pelos seus processos e atividades a fim de que a
entrega e o suporte ao serviço sejam garantidos. Essa gestão é necessária uma vez que há um uso
intensivo de ferramentas nessa etapa do ciclo de vida, já que, as mudanças no funcionamento dos
serviços podem ser facilmente percebidas pelo cliente, o que torna as ações dessa etapa algo muito

42

sensível.
Além das metas descritas acima, o ITIL também definiu alguns objetivos para a fase da Operação do
Serviço. Listamos abaixo alguns que julgamos mais relevantes:
Monitorar Desempenho. Esse objetivo pode ser entendido como avaliar as
métricas, coletar dados continuamente e confrontá-los com os níveis acordados. É bom
lembrar que a Operação do Serviço é a fase responsável pela coleta de dados que irão
subsidiar o trabalho do Gerenciamento do Conhecimento (transformação de dado em
informação e depois em conhecimento e sabedoria, lembram?).
Projetar processos para a operação do dia a dia. Parece bem óbvio, mas é
importante que esteja definido por escrito que essa responsabilidade cabe a alguém dentro da
fase de Operação do Serviço.
Gerenciar a Disponibilidade do Serviço.
Corrigir problemas.
Restabelecer o funcionamento normal dos serviços que estejam com alguma
falha.
Gerenciar a demanda.
Passaremos a trabalhar com os conceitos, técnicas, processos e ferramentas utilizadas pela Operação
do Serviço a partir das próximas postagens. Vocês não perdem por esperar!!!
TIL V3 - Operação do Serviço - Conceitos e Definições - Evento eAlerta

Queridos leitores, antes de adentrarmos pelo mundo da Operação do Serviço, precisamos equacionar
alguns conceitos que geram dúvidas nas cabeças de muitas pessoas que estão iniciando na utilização
do ITIL, especialmente na versão 3. Um desses conceitos diz respeito a diferença entre Evento e
Alerta. Segundo o ITIL, “um evento pode ser definido como qualquer ocorrência que possa ser
detectada e que tenha um significado para a gerencia da infraestrutura de TI ou para a entrega do
serviço”. Percebam que não é qualquer coisa e sim algo que tenha importância para o serviço. A partir
de um evento é que se pode, ou não, gerar alertas que deverão ser tratados. Assim sendo, o alerta é
um subproduto do evento, ou seja, deriva da monitoração de eventos, sacaram?

43

Se pudéssemos colocar de uma forma mais simplificada, diríamos que, conforme figura acima, um
evento pode gerar um registro informativo ou um alerta. O alerta pode virar um incidente, a ser tratado
pelo processo de Gerenciamento de Incidentes ou pode necessitar de uma verificação de alguma área
técnica, de forma proativa, a fim de evitar que o evento venha a se tornar um incidente de fato. A partir
da análise técnica, pode ser que um determinado alerta acabe se transformando em um incidente
também.
É importante salientar que os eventos podem ser criados de forma eletrônica ou de forma manual, e
normalmente são identificados por meio de ferramentas de monitoração. O ITIL define dois tipos de
ferramentas de monitoração, a saber:
Ferramentas de monitoração ativas. São ferramentas que identificam os Itens de
Configuração de um determinado serviço e verificam sua disponibilidade e seu status, a fim de
determinar se o seu comportamento está fugindo daquilo que é considerado normal para um
determinado serviço de TI.
Ferramentas de monitoração passivas. São ferramentas que detectam e
correlacionam alertas ou comunicações gerados pelos itens de configuração de um
determinado serviço de TI.
Apenas para finalizar, consideremos que alertas identificam que um limite de algum item de
configuração foi atingido ou que algo diferente do seu funcionamento normal foi alterado ou ainda, no
pior caso, que uma falha ocorreu. Neste último caso, provavelmente o alerta evoluirá para um
incidente.
Por falar em incidente, vamos, na próxima postagem, definir o que o ITIL entende como incidente,
antes mesmo de adentrarmos no processo de Gerenciamento de Incidentes propriamente dito.

ITIL V3 – Operação do Serviço – Conceitos e Definições – Incidentes e Problemas

44

Para aqueles que estão habituados com o ITIL, as definições de Incidente e Problema já estão no
sangue, mas como o nosso blog é bastante democrático, vejamos como o ITIL os definem:
Incidentes - “Uma interrupção não planejada de um serviço de TI ou a redução na
qualidade de um serviço de TI. Falha em um item de configuração que ainda não tenha
impactado o serviço é também um incidente, como por exemplo a falha de um disco em um
array de discos.”
Problemas - “é a causa de um ou mais incidentes.”
Colocando em outras palavras, um Incidente tem uma relação muito íntima com o efeito que uma
interrupção causa no serviço e um Problema tem uma relação íntima com a causa raiz que fez com
que houvesse a interrupção de um determinado serviço de TI.
Em postagens posteriores trataremos dos processos que o ITIL preconiza para tratar Incidentes e
Problemas. Nesta postagem, o nosso objetivo é identificar os conceitos e as diferenças entre os termos
para que, ao estudarmos os processos, o entendimento seja fácil e sólido, ok?
Aproveitando a definição de incidente, é comum algumas pessoas que ainda não tiveram um contato
mais profundo com a biblioteca ITIL, confundirem este conceito com o conceito de Requisição de
Serviço (RdS). Este último é definido como qualquer demanda feita por usuários dos serviços para a
área de TI que não afetam o fluxo natural da prestação do serviço e não significam interrupção ou
degradação da qualidade do mesmo. Exemplos mais comuns de Requisições de Serviço são: pedidos
de troca de senhas, solicitação de configuração de máquinas de novos usuários, etc.
Conceitos entendidos, podemos passar para outras definições que serão úteis para o entendimento
dos processos da etapa de Operação do Serviço, dentro do ciclo de vida do serviço de TI preconizado
pelo ITIL.

ITIL V3 - Operação do Serviço - Conceitos e Definições – Solução de Contorno

45

Outro conceito muito interessante do ITIL diz respeito à Solução de Contorno. O Workaround, como é
dito em inglês, representa uma forma não definitiva de superar alguma dificuldade ou algum incidente
que está impactando a prestação de um determinado serviço de TI. Todavia, é importante salientar que
o ITIL prevê soluções de contorno também para problemas e não apenas para incidentes, uma vez
que, em determinadas ocasiões, o processo de Gerenciamento de Incidentes pode não ter achado
uma solução de contorno e aí, quando o processo de Gerenciamento de Problemas o identifica, ele
informa para que o serviço seja restaurado.
Dessa forma é possível entender que a solução de contorno busca reduzir ou até mesmo eliminar o
impacto de um incidente, ou de um problema, enquanto a solução definitiva ainda não foi encontrada.

Fazendo uma analogia com a figura acima, poderíamos dizer, de forma bem humorada, que a pessoa
achou uma solução de contorno capaz de restaurar o serviço (disponibilidade de água) mesmo sem ter
uma solução definitiva para o incidente. É claro que nem sempre a solução de contorno pode ser
encarada como uma “gambiarra” e em certas ocasiões ela até se torna a solução definitiva, mas, na
maioria das vezes, nós da área de TI sabemos que a “gambiarra” é quem restaura de forma mais
rápida o serviço, até que tenhamos a certeza em relação à solução definitiva a ser aplicada.
É bom deixar claro que não há nada de errado em se implementar Soluções de Contorno, desde que
seja realmente temporária e que uma solução definitiva seja buscada incessantemente, com o risco de
fazer com que uma “gambiarra” piore ou até danifique de forma significativa o serviço prestado.

46

ITIL V3 – Operação do Serviço – Conceitos e Definições – Erro Conhecido

Depois de passarmos por vários conceitos, prometo que esta postagem trará o último conceito que
precisamos ter em mente para entendermos os processos da fase de Operação do Serviço, ok? O que
trataremos aqui é o conceito de Erro Conhecido. Para os menos avisados, pode até parecer ofensa
perguntar o que é um Erro Conhecido. Como assim? Não sabe falar português? Qual a dificuldade em
se entender o que quer dizer um erro conhecido? Calma! Muita calma nessa hora... Antes que alguém
faça as perguntas (desaforadas) acima é importante saber que para o ITIL, um Erro Conhecido referese a um Problema (ver postagem que fala sobre Incidentes e Problemas) que tem uma causa raiz
identificada e documentada, além de uma solução de contorno igualmente identificada e documentada.
Se fossemos colocar a definição de Erro Conhecido em uma equação matemática, ela seria mais ou
menos assim:
Erro Conhecido = Problema + Identificação da Causa Raiz + Solução de Contorno.
Nunca é demais falar que, obviamente, os Erros Conhecidos devem estar registrados em uma base de
dados e o responsável por armazenar e atualizar essas informações é o processo de Gerenciamento
de Problemas que será visto em postagens posteriores.
É importante lembrar que uma Solução de Contorno, como visto na postagem anterior, pode não ser
ainda a solução definitiva para o problema, porém saber que um determinado erro é conhecido, dá
uma segurança maior para o usuário, pois sabe-se que há uma solução de contorno pronta para ser
aplicada caso o problema ocorra. Vocês acham que isso é pouco? A Microsoft, por exemplo, costuma
lançar alguns softwares com Erros Conhecidos, por motivos de competição ou momento de mercado.
Coisas que se fossem esperar para serem definitivamente resolvidas poderiam representar a perda de
alguns milhões de dólares. Assim, a Microsoft tem a solução de contorno já pronta para aplicar, caso
seja necessário.
Passado pelos conceitos, vamos verificar algumas técnicas e ferramentas e entrar nos processos da
Operação do Serviço.
ITIL V3 – Operação do Serviço – Técnicas e Ferramentas – Priorização de Incidentes e Problemas

O ITIL indica uma regra para que os Incidentes sejam priorizados, assim como a tratativa dos
problemas. É óbvio que essa indicação é apenas um guia e cada empresa pode, e deve, definir os
seus critérios de priorização. Para aqueles que não pensaram nisso, a ideia criada pelo ITIL é a
seguinte: a prioridade de um incidente ou de um problema é identificada por meio do produto de dois
fatores importantes, o Impacto e a Urgência, ou seja, estes dois fatores determinarão o quão prioritário
um incidente e/ou um problema é.

47

E como o ITIL define Impacto e Urgência? As metodologias tratam esse assunto de forma parecida,
mas cada uma tem um viés, dependendo do foco de cada uma. No ITIL, a Urgência resume-se a
identificar a quantidade de tempo que um incidente pode ter até que exista um significativo impacto no
negócio. Perceba que a definição de Urgência, refere-se ao Impacto que por sua vez significa saber a
que ponto os Níveis de Serviço estão sendo afetados pelo incidente ou pelo problema. Assim, para
ilustrarmos melhor, poderíamos dizer que na figura acima, o Impacto representa o tamanho da bomba
e a Urgência representa o tamanho do pavio.
Resumindo o assunto, podemos dizer que o ITIL faz a priorização dos incidentes e dos problemas por
meio da seguinte equação matemática:
P = I * U,
onde P é a Prioridade, I é o Impacto e U é a Urgência.
A partir da definição da prioridade, cada resultado de P deve ter atrelado a ele, um tempo máximo
estabelecido para resolução e uma descrição (Crítico, Alto, Médio, Baixo, etc). Nesse ponto temos que
ter cuidado na classificação para que não aconteça o que já vi acontecer em várias empresas que
acabam descrevendo a prioridade como Altíssima, ou Super Alta, ou Mega Super Alta e assim por
diante. Essa falta de cuidado em determinar corretamente a prioridade pode levar ao descrédito em
relação ao tratamento dos incidentes e problemas.
ITIL V3 – Operação do Serviço – Técnicas e Ferramentas – BDEC

Além da técnica de priorização de incidentes e problemas, o ITIL V3 oferece uma ferramenta para ser
utilizada pela Operação do Serviço, o BDEC. Já deu para perceber que o ITIL V3 abusou das siglas
para representar seus Bancos de Dados e sistemas que auxiliam os processos, certo? Pois bem,
BDEC significa Base de Dados de Erro Conhecido.
Não é algo novo na biblioteca ITIL, nem no imaginário de todos nós que os Erros Conhecidos devam
estar em uma base de dados capaz de suportar os processos, caso contrário não seriam “conhecidos”,
concordam? O BDEC é mais um membro do SGCS (Sistema de Gerenciamento do Conhecimento do

48

Serviço) e deve ser montado pelo Gerenciamento de Problemas, mas será consumido também, e por
motivos óbvios, pelo Gerenciamento de Incidentes.
Dito isso, acredito que a partir da próxima postagem entraremos nos Processos da Operação do
Serviço.
ITIL V3 – Operação do Serviço – Processos – Gerenciamento de Incidentes

Como dizia o velho provérbio, “panela velha é que faz comida boa”. No ITIL V3, um processo que não
sofreu alteração na passagem da versão dois para a versão três foi o processo de Gerenciamento de
Incidentes. Este processo é considerado o mais expansivo dentro da organização e tem como objetivo
principal, para aqueles que ainda não tiveram contato com nenhuma versão do ITIL, o
restabelecimento do funcionamento normal do serviço, o mais rápido possível. Aqui cabem duas
análises: a primeira diz respeito ao termo “funcionamento normal”. O que essa expressão quer dizer?
Alguém se arrisca? … Bem, se considerarmos o que já vimos até agora, fica fácil dizer que para o ITIL,
o funcionamento normal de um serviço é alcançado quando estamos atendendo os Níveis Acordados
(ANS), mas também não podemos esquecer que, do ponto de vista interno, os ANOs também devem
ser respeitados. A segunda análise diz respeito a expressão “o mais rápido possível”. A intenção aqui é
minimizar o impacto negativo sobre o negócio, assegurando que os melhores níveis possíveis sejam
mantidos. Falamos em melhores níveis possíveis porque em muitos casos aplica-se soluções de
contorno que não resolvem a situação definitivamente.
O Gerenciamento de Incidentes deve lidar com todos os tipos de incidentes, que podem vir a partir dos
usuários, geralmente por meio da Central de Serviços, das equipes técnicas ou automaticamente, por
meio de ferramentas de monitoração. Aliás, é inadmissível, em algumas organizações que um
incidente seja de seu conhecimento apenas quando o usuário o reporta.
Por ser um processo muito utilizado pelas organizações, passaremos abaixo pelas atividades que o
compõe com uma breve descrição:
Identificação do Incidente. Conforme dito acima, a identificação deve ser feita
preferencialmente por ferramentas de monitoração dos serviços e não pelo usuário para evitar
o “mico”. Apesar disso, o usuário pode reportar um problema que deve ser verificado se de
fato é um problema ou é apenas falta de informação, por exemplo, o que não caracteriza um
incidente.
Registro do Incidente. Como tudo no ITIL, mas especialmente aqui, o registro do
incidente deve ser bem detalhado, para possibilitar uma resposta mais tempestiva ao
problema.
Categorização do Incidente. Importante para o uso de outros processos, como por
exemplo o Gerenciamento de Problemas.
Priorização de Incidentes. Já falamos sobre essa técnica em postagens anteriores.
Essa priorização é importantíssima, levando em consideração que existem recursos finitos
nas organizações.
Diagnóstico Inicial. Se o Incidente foi aberto por meio da Central de Serviços, há a
necessidade da existência de scripts para que os atendentes possam executar ações básicas
que tentam resolver o incidente, baseado nos erros conhecidos e em uma base de
conhecimento. Caso não consiga resolver, haverá a escalação do incidente.
Escalação do Incidente. Existem dois tipos de escalação, a saber: escalação
funcional (horizontal), que trata da passagem do incidente que não foi resolvido pelo
atendente em 1º nível para equipes especializadas, baseada na categorização do mesmo.
Escalação Hierárquica (vertical), para casos de incidentes graves que fazem com que as
gerências sejam notificadas para agilizar o seu tratamento ou conversar com o Cliente de

49

forma a passar alguma satisfação. A Escalação ocorre também nas duas atividades seguintes,
descritas abaixo.
Investigação e Diagnóstico. Investigação de um determinado incidente na busca de
uma solução de contorno, que pode, em alguns casos, até ser a solução definitiva.
Resolução e Recuperação. Identificando uma solução em potencial, esta deve ser
aplicada e testada. O grupo de solução, quando acha uma solução, deve passar as
informações à Central de Serviços para que essa possa comunicar ao usuário.
Fechamento do Incidente. Registrar de forma detalhada o que foi feito e a
resolução encontrada para que possa servir de base para futuros incidentes com a mesma
natureza.
Passado pelo processo de Gerenciamento de Incidentes, veremos na próxima postagem outro
processo bem consolidado desde a versão 2.0 do ITIL, o Gerenciamento de Problemas. Vocês não
perdem por esperar!!!!

ITIL V3 – Operação do Serviço – Processos – Gerenciamento de Problemas

Como havíamos falado na postagem anterior, falaremos neste momento de outro processo bastante
maduro dentro da biblioteca ITIL, mas que nem todas as empresas o implementam da forma como
deveria. Estamos falando do famoso processo de Gerenciamento de Problemas. Este processo tem o
objetivo principal de identificar a causa raiz de incidentes e definir a solução definitiva para os mesmos
a fim de que os incidentes recorrentes sejam eliminados e o impacto daqueles que não podem ser
evitados seja reduzido.
Identificar a causa raiz dos incidentes significa dizer que, para o Gerenciamento de Problemas, o mais
importante é descobrir o porquê das coisas estarem acontecendo fora do que foi acordado nos SLAs. É
legal notar que este processo não deve ser apenas reativo, uma vez que, a partir de uma análise dos
incidentes registrados, pode-se iniciar, proativamente, as atividades para resolver definitivamente
aqueles que acontecem de forma recorrente.
Dentro desse processo existem uma série de atividades que sugiro fortemente que sejam
aprofundadas para quem tem o interesse em se certificar em ITIL, porém para o nosso humilde blog,
nos restringiremos a identificar atividades que possam trazer informações mais relevantes ao
entendimento do processo.
Após a detecção do Problema, do seu registro, da categorização e da priorização, temos a atividade de
investigação e diagnóstico. Esta atividade diz respeito à análise de causa raiz, que pode ser tanto
reativo quanto proativo, como dito anteriormente. O fato principal aqui é que o Gerenciamento de
Problemas pode encontrar não uma solução definitiva, no primeiro momento, mas soluções de
contorno, que seriam uma forma temporária de superar as dificuldades que porventura um serviço
possa estar passando. Neste caso, o registro do problema continua aberto e as investigações também
devem continuar, uma vez que, conforme dissemos, o Gerenciamento de Problemas tem como objetivo
principal a identificação da causa raiz e a solução definitiva de um grupo de incidentes, ou de um
incidente que tenha se tornado um problema grave.
Outra questão interessante sobre a descoberta da solução de um problema está na definição de
quando se aplicar esta correção. As vezes não é possível aplicar a solução definitiva no momento em
que a mesma é identificada. Assim, o Gerenciamento de Problemas, que trata de todo o ciclo de vida
do Problema, deve se preocupar, também, com a abertura de requisições de mudanças para que os
processos que tratam de mudanças possam agir de forma ordenada e controlada.

50

ITIL V3 – Operação do Serviço – Processos – Gerenciamento de Eventos

Caros leitores do nosso humilde blog, nesta postagem estaremos falando de um novo processo do ITIL
V3, o Gerenciamento de Eventos. Este processo vem preencher um gap deixado pelo ITIL V2 e tem
como principal objetivo a detecção de todos os eventos que acontecem no serviço de TI, sua
contextualização e a definição das medidas adequadas de controle que possam ser tomadas.
Quando falamos de todos os eventos, pode parecer algo utópico, mas para entendemos a afirmativa
anterior, temos que saber o que o ITIL chama de “evento”. Assim sendo, Evento, na visão do ITIL,
representa qualquer ocorrência detectável ou percebida que tenha relevância para o gerenciamento do
serviço de TI. Atenção para o termo “relevância”. Não é qualquer coisa que aconteça, mas sim todas as
coisas relevantes para o serviço. Estas sim devem ser capturadas pelo Gerenciamento de Eventos.
É importante perceber, como consequência do objetivo desse processo, que o Gerenciamento de
Eventos se torna a base para a monitoração operacional do serviço e seu controle.
O ITIL V3 coloca alguns exemplos de eventos, listados abaixo, mas é bom deixar claro que os eventos
não se restringem a apenas aos colocados aqui.
Eventos que significam operações regulares. Exemplo: identificação que um
usuário logou em um sistema, um e-mail chegou ao seu destino final ou ainda a notificação
que um job agendado foi executado.
Eventos que significam uma exceção. Exemplo: Um servidor está acima da faixa
aceitável de utilização, uma situação não usual ocorreu em um processo de negócio, etc.
Eventos que significam uma operação não usual, mas sem ser excepcional.
Exemplo: A memória de um servidor está a 5% do máximo permitido, o tempo de finalização
de uma transação está 10% maior do que o acordado, etc.
Para finalizar, podemos dizer que o Gerenciamento de Eventos é uma das entradas para uma série de
outros processos da Operação do Serviço, como por exemplo o Gerenciamento de Incidentes e o
Gerenciamento de Problemas.
Na próxima postagem, continuaremos na nossa viagem pelos processos da fase de Operação do
Serviço do ciclo de vida proposto pelo ITIL.

ITIL V3 – Operação do Serviço – Processos – Cumprimento de Requisitos

Nos processos de Operação do Serviço já passamos pelos incidentes, problemas e eventos, mas e as
dúvidas e solicitações do dia a dia que não indicam falha ou perda de performance no serviço de TI? O
ITIL, preocupado em abranger todos os aspectos do serviço de TI e levando em consideração o próprio
conceito que ele criou para serviço (“meio para que a empresa tenha valor”), preparou um processo
específico para tratar desse assunto, o Cumprimento de Requisição. Concordo que o nome do
processo ficou meio fora do padrão utilizado pela própria biblioteca ITIL, mas o que ele se propõe a
fazer, na verdade, é disponibilizar um canal para que usuários e clientes possam solicitar e utilizar

51

serviços padronizados que tenham um processo pré-definido de qualificação e aprovação.
Para quem já tem um pouco de experiência, vai perceber que este processo utiliza-se das famosas
RdS (Requisições de Serviço) para operacionalizar as entradas que são feitas pelos usuários, quase
sempre pela Central de Serviço, outro elemento crítico para esse processo. Por falar na Central de
Serviço, normalmente essa função terá a responsabilidade de receber, monitorar, executar, enviar e
despachar as requisições que forem feitas pelos usuários.
Apesar de criar um processo específico para tratamento das RdS, o ITIL deixa muito claro que a
automatização de certas rotinas é muito bem-vinda, especialmente se a prestadora do serviço de TI
tiver total conhecimento sobre as mesmas. Além disso, o ITIL também deixa claro que práticas de
autoatendimento também são muito valiosas, pois reduzem a fila de atendimento, o que permite maior
agilidade para as RdS que de fato necessitam de uma interação mais aprofundada.
Por fim, não podemos nos esquecer que este processo também é o responsável por receber as
reclamações, comentários e solicitações de informações gerais do serviço.
Na próxima postagem, trataremos do último processo da Operação do Serviço. Vocês saberiam me
dizer qual é?...
ITIL V3 – Operação do Serviço – Processos – Gerenciamento deAcesso

Finalizando os processos da fase de Operação do Serviço do ciclo de vida de serviços de TI
preconizado pelo ITIL V3, falaremos, nesta postagem, do Gerenciamento de Acesso. Este é um novo
processo do ITIL V3 para velhos assuntos que existem desde os primórdios dos sistemas
informatizados.
O Gerenciamento de Acesso trata, como o próprio nome sugere, dos acessos, perfis e direitos de
usuários ou de grupo de usuários a um determinado serviço ou grupo de serviço de TI. Não há muito o
que ser dito sobre esse processo, mas uma característica interessante é que o Gerenciamento de
Acesso utiliza-se de outros processos como entrada e saída, uma vez que o fornecimento dos direitos
e acessos dos clientes é feito por meio de Requisições de Serviço e as definições das políticas que são
aplicadas por este processo proveem dos Gerenciamentos de Segurança e Disponibilidade da fase de
Desenho do Serviço.
Vocês podem então estar se perguntando, para que ele existe afinal? Bem, na minha opinião particular,
o ITIL tenta abranger todos os aspectos do serviço de TI e há, em relação ao Gerenciamento de
Acesso, a nítida intenção de dar ao processo uma importância maior, destacando-a de outras
requisições de serviços normais (dúvidas, elogios, pedido de algum serviço, etc). Acredito que
problemas de acessos indevidos têm comedido muitas empresas que prestam serviços de TI e estes
acessos indevidos certamente têm causado muitos danos a várias organizações.
Caro leitor, estamos nos aproximando do final da nossa viagem pelo ITIL V3. Ainda temos algumas
coisas interessantes e novas dessa biblioteca, portanto, não deixem de acompanhar as próximas
postagens...

ITIL V3 – Operação do Serviço – Funções – Central de Serviço

Caros leitores, finalizados os processos da Operação do Serviço, falaremos nesta postagem, e na

52

próxima também, sobre as Funções descritas pelo ITIL. Antes de mais nada, temos que deixar claro
que o ITIL considera Funções como “estruturas funcionais” que deveriam existir no provedor de serviço
de TI. Na versão 2 da biblioteca ITIL, existia apenas a Função de Central de Serviço, que veremos
nesta postagem com mais detalhes. Já na versão 3, o ITIL descreve três novas Funções, que iremos
descrever na próxima postagem, mas que podemos elencá-las agora para matar a curiosidade de
alguns. São elas: Gerenciamento Técnico, Gerenciamento de Aplicativos e Gerenciamento de
Operações de TI.
A Central de Serviços é descrita pelo ITIL como uma unidade funcional que tem o intuito de ser o ponto
único de contato para os usuários de TI. Dessa afirmação podemos imaginar que esta função exerce
um papel fundamental na organização de um Departamento de TI, uma vez que contará com um
número dedicado de pessoas que terão como atribuições principais: receber e internalizar uma série de
eventos de diferentes naturezas, como visto nos processos descritos nas postagens anteriores
(incidente, evento, acesso, dúvida, etc.), além de cuidar para que o serviço volte a sua normalidade o
mais rápido possível.
Existem certas dúvidas sobre a Central de Serviço que devemos esclarecer para que se tenha o maior
proveito de suas atribuições.
Central de Serviço não é help desk! Um help desk tem como característica natural o
fato de ser reativo, ou seja, agir quando provocado ou acionado. Não é esse o caso da
Central de Serviço. Os sistemas/monitorações podem e devem interagir com a Central para
que esta internalize, entre outros, os incidentes e as requisições de serviço de forma proativa,
antes que o serviço de TI venha a ser degradado e esta degradação seja percebida pelo
cliente.
A Central de Serviço não recebe apenas ligações telefônicas! A Central de Serviço
deve estar preparada para receber acionamentos por vários canais, a fim de permitir que de
fato seja o ponto único de contato.
Para finalizarmos o assunto, o ITIL classifica uma Central de Serviço em três tipos distintos, a saber:
Central de Serviço Local. É a Central que se encontra fisicamente próxima dos
usuários que a acionam. Tem como objetivo principal atender usuários VIPS, dirimir
dificuldades referentes a língua ou a diferenças políticas e culturais e atender grupo de
usuários especializados. A figura abaixo mostra um exemplo de uma Central de Serviço Local.

53

Central de Serviço Centralizada. É a Central onde toda equipe da Central de
Serviço encontra-se em uma estrutura centralizada. A figura abaixo mostra um exemplo desse
tipo de Central. Normalmente, este tipo de Central é mais eficiente e com melhor custobenefício e, relação a Central de Serviço Local.
TIL V3 – Operação do Serviço – Funções – Outras Funções

Finalizando as Funções descritas pelo ITIL V3, já que falamos da Central de Serviço na postagem
anterior, vamos ver, nesta postagem, três novas Funções que foram incorporadas nesta versão da
biblioteca ITIL. São elas: Gerenciamento Técnico, Gerenciamento de Aplicativos e Gerenciamento de
Operações de TI. Vale lembrar que o ITIL considera Função como sendo uma estrutura organizacional
que as empresas prestadoras de serviços de TI deveriam ter.
Gerenciamento Técnico – Esta estrutura deve possuir profissionais capazes de ajudar no
planejamento, na implementação e na manutenção da infraestrutura de um determinado serviço de TI.
Na fase de Desenho do Serviço, esta equipe é acionada para especificar os requisitos técnicos de
infraestrutura. Já na fase de Transição do Serviço, essa equipe auxilia na avaliação e aprovação de
mudanças na infraestrutura do serviço, além da própria implementação de mudanças aprovadas. Por
fim, na fase de Operação do Serviço, esta equipe auxilia na resolução dos incidentes (2º ou 3º nível de
recorrência, dependendo do serviço e da empresa) e dos problemas, entre outros.
Gerenciamento de Aplicativos – Esta equipe pode ser traduzida como a equipe de desenvolvimento
de software da prestadora de serviço. Deve ser criada, especialmente, para ajudar os processos de
negócio da empresa no que tange a identificação de requisitos funcionais e gerenciamento do
software, na fase de Desenho do Serviço; o auxílio na implantação do software desenvolvido na fase
de Transição e o suporte e indicação de melhoria dos aplicativos nas fases de Operação do Serviço e
de Melhoria de Serviço Continuada.
Gerenciamento de Operações de TI – Esta estrutura organizacional deve ter como objetivos
principais: a manutenção do patamar acordado em termos de estabilidade dos processos e das
atividades do dia a dia da empresa, exame rotineiro para identificar melhorias nos processos
operacionais - especialmente os que reduzem custos - e capacidade operacional de diagnosticar e
intervir de forma tempestiva para resolver falhas em seus ambientes de operação.

54

Caro leitor, com esta postagem finalizamos a fase de Operação do Serviço, a partir da próxima
postagem entraremos na fase de Melhoria de Serviço Continuada.

Central de Serviço Virtual. É uma Central que por meio da tecnologia tem o seu
sistema centralizado, mas várias equipes distribuídas em diferentes regiões geográficas. Uma
especialização deste tipo de estrutura é conhecida como Central de Serviço Follow the Sun.
Nesta especialização, duas ou mais centrais dispersas sobre o globo acessam uma base de
dados compartilhada e um mesmo sistema de forma a ter sempre pessoas trabalhando em
horários comerciais para diminuir custos trabalhistas.

É claro que o assunto Central de Serviço daria para umas dez postagens, mas para não ficarmos
enfadonhos acho que as informações aqui postadas dão uma boa noção sobre essa importante
Função do ITIL. Seguiremos falando das outras Funções na próxima postagem...

55

ITIL V3 – Melhoria de Serviço Continuada – Metas e Objetivos

Caros leitores, iniciamos nesta postagem a última fase do ciclo de vida do serviço conforme preconiza
o ITIL V3. A fase de Melhoria de Serviço Continuada, na verdade, retroalimenta todo o ciclo de vida,
uma vez que busca alinhar e realinhar incessantemente os serviços de TI às necessidades do negócio,
fazendo com que a prestação do serviço de TI sempre melhore tendo em mente dois aspectos
importantes: agregação de valor e maior efetividade nos custos da entrega do serviço. Quando falamos
em agregar valor queremos dizer que as necessidades do negócio são as principais direcionadoras da
melhoria continuada, apesar de não serem as únicas. Já em relação à efetividade ou à eficiência nos
custos, queremos dizer que o prestador de serviço deve sempre tentar fazer mais com menos, ou seja,
deve estar sempre fazendo um refactoring do serviço (analogia com o Refactory do XP), tornando-o
cada vez mais simples, não na qualidade, mas sim na forma de administrá-lo e produzi-lo (processos,
operações, etc.), ressalvado, obviamente, aqueles que possuem restrições contratuais ou que já
estejam em sua forma mais “simples”.
Dada a explicação acima, não é difícil de imaginar os principais objetivos desta fase do ciclo de vida do
serviço. São eles:
Revisar, analisar e sugerir melhorias em todas as fases do ciclo de vida do projeto.
Validar os resultados alcançados em relação aos níveis de serviços acordados e
verificar possibilidades de melhorias.
Melhorar a eficiência em relação aos custos.

56

Garantir que os métodos de gerenciamento da qualidade são aplicáveis.
Para cumprir estes objetivos, o ITIL relacionou apenas três processos que serão vistos nas próximas
postagens, mas antes teremos, como de costume, que pontuar alguns conceitos que irão facilitar o
entendimento dos processos. Vamos juntos?

ITIL V3 – Melhoria de Serviço Continuada – Definição e Conceitos – Diversos

Alguns conceitos são fundamentais para que possamos entender o papel da Melhoria de Serviço
Continuada. A primeira coisa que temos que ter em mente é a máxima do planejamento estratégico
que diz o seguinte: “Você não pode gerenciar o que não pode controlar. Da mesma forma, não
podemos controlar o que não podemos medir e não podemos medir o que não conseguimos definir”.
Frase de efeito essa, não? Na verdade o que ela quer dizer, nos meandros, é que a TI deve estar
pronta para medir um determinado serviço de ponta a ponta, ou seja, lá na fase de Desenho do serviço
tenho que ser capaz de identificar os indicadores que vão verificar o serviço como um todo e não
apenas itens individuais, como um servidor ou um ativo de rede ou ainda uma aplicação isolada.
Mas medir por medir não quer dizer muita coisa, é necessário se ter uma Linha de Base (segundo
conceito importante!!), ou seja, uma referência inicial onde é possível ser feita uma comparação
visando o futuro do serviço medido.
Outro conceito importante é o de Métrica. Para medir algo preciso definir o indicador que me mostrará
o desempenho de um determinado serviço. Esse indicador é formado por métricas, ou seja, por valores
que são factíveis de serem reconhecidos, capturados e armazenados. O ITIL define três tipos
diferentes de Métricas a saber:
Métricas de Tecnologia – Métricas que estão relacionadas aos componentes e
aplicativos. Normalmente medem desempenho e disponibilidade.
Métricas de Processo – Métricas que ajudam a identificar a saúde geral de um
processo.
Métricas de Serviço – Métricas que são resultantes das medições do serviço ponta a ponta.
ITIL V3 – Melhoria de Serviço Continuada – Técnicas e Ferramentas – Ciclo de Deming

Antes de entrarmos nos processos da fase de Melhoria de Serviço Continuada do ITIL V3, vamos
explorar duas técnicas e ferramentas que o ITIL utiliza para embasar esses processos. Uma delas
veremos nesta postagem, a outra, para aumentar o suspense, deixaremos para a próxima postagem.
A técnica que vamos explorar nesta postagem é o famoso Ciclo de Deming. Vocês não conhecem?
Tenho certeza que já ouviram falar, mas talvez com um outro nome... … que tal ciclo PDCA? Agora
SIM!!! Pois é pessoal, o Ciclo de Deming ou o Ciclo PDCA (Plan, Do, Check, Act) é um ciclo composto
por quatro fases que deve ser utilizado para a melhoria contínua. Este ciclo tem como base a gestão
de processos, mas pode ser utilizada praticamente em qualquer ramo de atividade. O primeiro trabalho
neste sentido foi atribuído a W. Edward Deming, daí o nome: Ciclo de Deming.

57

Conforme figura acima, é possível verificar as quatro etapas do ciclo. Cada uma delas tem uma função
específica na busca da melhoria contínua (abaixo listamos cada uma em particular). Além disso, é
importante verificar que um determinado processo vai adquirindo maturidade cada vez que as quatro
fases são executadas. Dessa forma, a cada passagem pelo ciclo, o processo consolida um nível de
maturidade alcançado, representado pelo triângulo na figura. Parece algo simples e de fácil execução,
mas aplicá-lo não é tão simples assim. Para que isso funcionasse dentro do ITIL, o pessoal da OGC
criou o modelo MSC que veremos na próxima postagem. Por enquanto vamos focar nas fases do Ciclo
PDCA.
Plan (Planejar) – Desenhar ou revisar os processos que suportam os serviços de TI.
Do (Fazer) – Executar o que foi planejado e gerenciar o processo.
Check (Verificar) – Medir e comparar os processos e os serviços de TI em relação
aos objetivos.

TI.

Act (Agir) – Implementar as mudanças para melhorar os processos e os serviços de

Vamos complementar as técnicas e ferramentas da fase de Melhoria de Serviço Continuada na
próxima postagem...
ITIL V3 – Melhoria de Serviço Continuada – Técnicas e Ferramentas – Modelo MSC

Fechando as técnicas e ferramentas da fase de Melhoria de Serviço Continuada do ITIL V3, vamos
explorar, conforme prometido na postagem anterior, o Modelo MSC. Este modelo foi criado pelo ITIL V3
baseado em um outro modelo famoso de mercado, utilizado pela metodologia Six Sigma: o DMAIC Definir, Medir, Analisar, Melhorar(improve) e Controlar.

58

Conforme figura acima, o Modelo MSC é composto de 6 etapas que levam a organização,
ciclicamente, a promover a melhoria contínua de seus processos. A seguir destacaremos cada uma
das etapas.
What is the Vision? (Qual é a Visão?) – Nesta etapa é identificada a visão no
entendimento do negócio para que seja possível alinhar as estratégias de TI.
Where are we now? (Onde estamos agora?) - É a etapa de define um baseline para
que seja possível fazer análises e comparações em relação ao posicionamento atual da
organização em termos de negócio, pessoas, tecnologia, etc.
Where do we want to be? (Onde queremos estar?) - É a etapa que define alvos
mensuráveis para que sejam alcançados.
How do we get there? (Como chegamos lá?) - Esta etapa define as melhorias
necessárias para alcançar o alvo que se quer em termos de processos e serviços.
Did we get there? (Chegamos lá?) - Etapa responsável por avaliar as métricas e
medições realizadas para garantir que os marcos definidos foram alcançados.
How do we keep the momentum going? (Como mantemos o ritmo?) - É a etapa que
garante que a melhoria da qualidade continue, fechando o ciclo e reiniciando da primeira
etapa.
Bom pessoal, vimos as duas técnicas que são utilizadas pelos processos da fase de Melhoria de
Serviço Continuada. A partir da próxima postagem, entraremos nos processos desta fase, o que
significa dizer que estamos chegando ao final desta longa caminhada pelo ITIL V3, mas não fiquem
tristes não, pois teremos muita coisa boa pela frente ainda, já que uma Gestão de TI inteligente não se
faz aplicando apenas uma ou outra metodologia ou melhores práticas, e sim combinando uma grande
variedade delas tendo o foco sempre no negócio e no cliente...
ITIL V3 – Melhoria de Serviço Continuada – Processos – 7 Passos da Melhoria

59

Iniciamos nesta postagem os processos da fase de Melhoria de Serviço Continuada. Antes de mais
nada, precisamos deixar claro que há algumas divergências em relação à quantidade de processos
desta fase. Alguns autores consideram que há apenas um processo, exatamente o que vamos falar
nesta postagem, mas para outros e de acordo com a documentação oficial do ITIL V3, existem outros
dois processos a saber: Medição do Serviço e Relatório do Serviço. A celeuma está no fato de alguns
autores considerarem esses dois outros processos como técnicas ou no máximo subprocessos e não
como processos do ITIL, mas para sermos o mais fiel possível à documentação oficial, vamos de três
processos mesmo, combinado?
O processo dos 7 Passos da Melhoria começa com um passo que não está contabilizado entre os 7.
Quer dizer então que seriam 8 passos? Isso mesmo, mas este passo adicional é apenas a “fonte
inspiradora” dos outros passos e o ITIL resolveu não colocá-lo na contagem (Quem somos nós para
discutir com os caras...) Ficou complicado? vou explicar. Lembrando o modelo MSC (ver postagem
anterior), as perguntas que são feitas nesta técnica buscam identificar a visão e a estratégia da
organização e, como consequência, as metas táticas e operacionais. Essas informações são
importantes para orientar as etapas do processo dos 7 Passos da Melhoria que são vistos na figura
abaixo e que iremos descrever um a um.

Passo 1 – Definir o que você deveria medir – Este passo, baseado no MSC, identifica
o que deveria ser medido no sentido do serviço estar em uma situação ideal para o negócio e
para a TI.
Passo 2 – Definir o que você pode medir – Se o passo anterior visa a situação ideal
para o negócio e para TI, este passo delimita, dentro da realidade da empresa, o que de fato
pode ser medido em relação ao que foi definido no passo 1.
Passo 3 – Coletar os dados – Este passo define os meios que a organização utilizará
para conseguir coletar as informações que serão utilizados para medir e comparar os
resultados.
Passo 4 – Processar os dados – Este passo significa colocar os dados em um
formato que permita uma perspectiva fim a fim do serviço e uma visão geral da performance

60

alcançada pelo mesmo. São relatórios executivos, condensados a partir dos dados coletados
no passo anterior.
Passo 5 – Analisar os dados – Este passo visa transformar a informação coletada e
processada em conhecimento no que diz respeito à organização e seus serviços. Permitem
identificar as tendências, as ações corretivas, as relações internas e externas entre outros.
Passo 6 – Apresentar e usar a informação, avaliação, sumário e planos de ação –
Este passo significa pegar o conhecimento adquirido no passo anterior e transformá-lo em
sabedoria, por meio da utilização de relatórios, planos de ação, revisões, avaliações e
definição de oportunidades a serem exploradas, ou seja, é definir o que deve ser melhorado
em relação ao serviço.
Passo 7 – Implementar as ações corretivas – As ações corretivas identificadas são
apresentadas em formas de soluções para serem implementadas pela organização. Após este
passo, um novo ciclo reinicia-se.
Nas próximas postagens continuaremos tratando dos processos da última fase do ITIL V3...

ITIL V3 – Melhoria de Serviço Continuada – Processos - Relatório de Serviço

Como já dissemos na postagem anterior, existe uma pequena dúvida em relação à quantidade de
processos que fazem parte da fase de Melhoria de Serviço Continuada. Levando-se em consideração
que na documentação oficial do ITIL existe um tópico que trata do Relatório de Serviço como se este
fosse um processo, decidimos, por fidelidade, seguir o que a documentação oficial, apesar de respeitar
as opiniões contrárias.
É fato que um determinado serviço de TI é capaz de produzir uma quantidade enorme de dados que
são coletados e armazenados, porém apenas um pequeno grupo dessas informações tem uma
importância significativa para o negócio. Os outros dados também têm sua importância, mas para a
gestão do dia a dia do serviço.
O ITIL preconiza que para se ter uma abordagem correta na elaboração dos relatórios de serviço é
necessário que se crie regras e políticas que definam, entre outras coisas:
O público-alvo dos relatórios e as visões de negócio que estejam relacionadas ao
serviço de TI.
O que medir e o que estará presente no relatório.
Os termos utilizados e as fronteiras dos relatórios.
As regras de cálculos que o relatório possa vir a apresentar.
O calendário de elaboração e envio dos relatórios.
Os períodos de revisão do relatório.
A forma de acesso e o meio a ser disponibilizado.
Na próxima postagem, trataremos da Medição do Serviço, último processo do ITIL a ser abordado pelo
nosso blog. Vocês não perdem por esperar!!!
ITIL V3 – Melhoria de Serviço Continuada – Processos – Medição de Serviço

61

Finalizando os processos da fase de Melhoria de Serviço Continuada, do ciclo de vida de serviço
preconizado pela biblioteca ITIL V3, vamos falar sobre a “Medição de Serviço”. Já falamos em várias
postagens da importância da medição do serviço para que possamos aferir seu desempenho,
gerenciá-lo com eficiência e agregar mais valor ao mesmo, certo? Pois bem, o ITIL coloca que para os
serviços de TI não bastam, simplesmente, medirmos o desempenho de itens isolados, sejam eles de
infraestrutura, como um servidor de banco de dados por exemplo, ou sejam de aplicativos em
operação. Na verdade, a medição de serviço deve ser capaz de medir e reportar um determinado
serviço de TI de ponta a ponta, ou seja, todo o serviço e seu ciclo de vida. Mas como fazer isso?
Para resolver essa equação, que não é simples, o ITIL sugere que se crie uma estrutura de medição de
serviços, onde a combinação de métricas consideradas importantes para o serviço proveem uma
perspectiva acurada e balanceada sobre o serviço.
Assim sendo, o primeiro passo para a criação dessa estrutura de medição é entender e assimilar os
processos de negócio e, a partir deles, identificar aqueles que mais contribuem para entregar valor ao
negócio. A partir daí, a combinação de que falamos no parágrafo anterior refere-se a identificar, dentre
as opções a seguir, quais necessidades devem ser medidas para identificar a “saúde” de um
determinado serviço: serviços, componentes e processo de gerenciamento do serviço.
Caros leitores do nosso humilde blog, com essa postagem finalizamos a extensa, mas interessante
viagem pela biblioteca ITIL. Espero que tenha contribuído para disseminar o conhecimento sobre esse
importante capítulo na nossa busca por uma Gestão de TI Inteligente. Vamos entrar em um novo
assunto a partir da próxima postagem. Espero que seja tão interessante como foi este.

62

Itil conceitos obtidos em blogs e sites

Mais conteúdo relacionado

Semelhante a Itil conceitos obtidos em blogs e sites (20)

Último (20)

Itil conceitos obtidos em blogs e sites