ITIL V3 FOUNDATION

COMPLEMENTO PARTE 1

Omar Mussi
03/11/2009

Este documento foi criado como complemento ao material distribuído pela Trainning em seu curso de ITIL V3 Foundations. Ele não pode ser distribuído, pois
seu uso é restrito aos alunos das turmas que assistem às aulas com material comentado. É um documento que não fere direirts autorais, pois cita a sua fontes
sempre que necessário e é uma compilação de conclusões do autor baseada em diversas origens de informação.
SLIDE 20

Gerenciamento de Serviço é centrado em clientes e necessidades do negócio (alcance de metas –

cliente final – paga a conta).

Conforme a maturidade do Gerenciamento de Serviço aumenta, é possível entregar maiores níveis de

Utilidade e Garantia, sem o proporcional aumento nos custos.

SLIDE 24

 Processo

É um conjunto de atividades definidas que combinam recursos e capacidades (habilidades, competências)

para realizar um objetivo específico , e que direta ou indiretamente, cria valor para o cliente ou
stakeholder (disparado pelas necessidades dos cliente – Gatilho e com base em Regras - Políticas);

Um processo possui uma ou mais entradas e as transforma em saídas definidas (os controles usam
métricas - KPI para ver se chega no objetivo - KGI);

Feedbacks são usados para melhorar o processo.

SLIDE 31

VALOR: É O QUE SE PERCEBE PELO QUE SE PAGA PELO SERVIÇO

VALOR = UTILIDADE + GARANTIA

UTILIDADE (Utility): é relacionado a “o que é entregue”. Adequado ao PROPÓSITO (Eficácia)  AOS

REQUISITOS VOLTADOS PARA RESULTADOS (OUTCOME) DOS OBJETIVOS DO NEGÓCIO (BUSINESS GOALS)

GARANTIA (Warranty): é relacionado a “como é entregue”. Adequado ao USO (Eficiência)  AOS

REQUISITOS VOLTADOS PARA A FUNCIONALIDADE, USABILIDADE

** LEMBRE QUE QUEM CONTRATA UM SERVIÇO NÃO QUER TER A PROPRIEDADE DE SEUS RISCOS E
CUSTOS DE PRODUÇÃO.

** SE HÁ RISCO, A GARANTIA DE USABILIDADE É MENOR, LOGO O VALOR QUE SE PERCEBE PELO PREÇO
QUE SE PAGA, PARA CONTRATAR O SERVIÇO, ACABA SENDO MENOR!

SLIDE 38

Governança aprimorada (pilares vide cobit: alinhamento estratégico de TI com negócio, entrega de valor,
gerenciamento de riscos, gerenciamento de recursos, medição de performance);

SLIDE 42

O VALOR PARA O NEGÓCIO NA FASE DE TRANSIÇÃO: “Melhora a habilidade para alto volume de Mudanças e
Liberações, com resposta rápida para lançamento de serviços no mercado, com custos e riscos aceitáveis e
conformidade com Requisitos de Negócio e Governança”

SLIDE 61

Se a engrenagem do Serviço for menor que do Cliente, “GIRA MAIS LENTO” -> o desequilíbrio ATRASA!
SLIDE 67

 Prover ao Negócio e à TI a quantificação (OPEX atual), em termos financeiros, do valor dos Serviços de TI, do
valor dos ativos que sustentam o provisionamento destes serviços e a qualificação da previsão operacional
financeira (OPEX futuro com impactos de CAPEX) .

Documentar e acordar o valor dos serviços recebidos (para poder cobrar por Serviço);

Habilitar a modelagem e Gerenciamento da Demanda (para não desequilibrar o OPEX).

SLIDE 68

ANÁLISE DE INVESTIMENTO: (Valor serviço = Valor recebido\percebido – Custo incorrido)

Recomenda-se Modelos de Gerenciamento de Portfolio de Projetos aderentes ao BSC para Priorizar

os Investimentos (CAPEX) nas Demandas de Projetos (foco no ROI)

SLIDE 68

CONTABILIZAÇÃO: (ORÇAMENTO = Custos Atuais + Custos Previstos)

SLIDE 68

COBRANÇA:

Centro de Recuperação

 (cada CLIENTE PAGA a CONTA da DEMANDA de seu PAN)

Centro de Lucro

 (TI vira negócio -> pode virar empresa e ter outras Organizações como clientes)

SLIDE 72

BUSINESS CASE:

- SE APROVADO PELO BOARD, INJETA RECURSO $ EM TI

- OBJETIVOS DO NEGÓCIO de um Caso de Negócio viram DEMANDAS para TI

- TAMBÉM USADO NA MSC para Melhorar os SERVIÇOS

Planejamento e suporte à decisão que projeta as prováveis conseqüências de uma ação de Negócio. (COM FOCO
EM “VENDAS” ou Estratégia de um BSC)

 Estrutura de um Caso de Negócio (Business Case) (ANÁLOGO ao “TERMO DE ABERTURA” em

Projetos)

– Impactos no Negócio: os resultados financeiros e não financeiros para o Negócio (VALOR

e EFETIVIDADE);

– Recomendações: ações recomendadas (Demandas para TI: corriqueiras ou de Projetos).

SLIDE 77

 Envolve 5 aspectos principais do DESENHO DO SERVIÇO:

(entregar SOLUÇÃO para requisitos do negócio)

... especialmente o Portfolio de Serviço (tem os requisitos do serviço);

arquitetura tecnológica (x arquitetura do negócio);

(suportar processos de negócios. Com CONTROLES+PROCESSO+ATIVOS);

(medir o real VALOR).

 O Desenho do Serviço Novo ou Alterações em Serviços  “RECOMENDA-SE UM PLANO DE PROJETO (modelo

PMI)”

SLIDE 80

ARQUITETURA EMPRESARIAL = Arquiteturas do Negócio + Arquiteturas Tecnológicas (Sistemas + Infra-Estrutura)

ARQUITETURA DO NEGÓCIO = modelos de negócio, processos de negócio e desenho organizacional, componentes

estruturais e funcionais da organização, seus relacionamentos , funções e atividades de negócio e da Governança
Corporativa e seus requisitos.

ARQUITETURA TECNOLÓGICA = Produtos + Pessoas + Processos + Parceiros  Entrega de Valor nos serviços de TI
 Ambiente com: Serviços, Aplicações, Dados/Informação que satisfazem as necessidades correntes e futuras do
negócio.

ARQUITETURA DE APLICAÇÕES, ARQUITETURA DE DADOS/INFORMAÇÃO: são LÓGICAS e suportam os negócios e

os relacionamentos entre elas.

ARQUITETURA DE INFRA-ESTRUTURA DE TI = modelo FÍSICO tecnológico, que suporta o LÓGICO com os

componentes (IC´s a Ativos) seus relacionamentos, tecnologias, interfaces, protocolos, etc.

Arquitetura Organizacional/de Negócio, Arquiteturas de Sistemas de Informação (Serviços, Aplicação, Dados) e

Arquitetura de Infra-estrutura de TI costumam ser separadas.

SLIDE 83

FONTE TI EXAMES
SLIDE 90-92

 DA ESTRATÉGIA tem-se os seguintes Objetivos que irão definir Requisito para os Serviços na Fase de
Desenho (não é foco do ITIL V3):

Objetivo de Negócio (ON) Requisito do Negócio (RN),

Objetivo de TI (OTI)  Requisito do Serviço (RS)

 Requisito de Nível de Serviço (RNS) – (Service Level Requirements – SLR) – (documento)

É um requisito (necessidade) do cliente para aspectos de entrega de um Serviço de TI;

Os SLR são baseados nos objetivos do Negócio (que determinam os “RN” ou requisitos de negócio) e
são utilizados para se negociar e acordar as Metas de Nível de Serviço (MNS).

(LOGO: “ON” “RN”

 RNS  “OTI” “RS”)

 Meta de Nível de Serviço (MNS) – (Service Level Targets – SLT)

É um compromisso que é documentado em um Acordo de Nível de Serviço (SLA);

As SLT são baseadas nas Requisições de Nível de Serviço (SLR);

As SLT são necessárias para garantir que o projeto do Serviço de TI está adequado ao seu propósito;

As SLT devem ser declaradas em formato SMART

(eSpecífico, Mensurável, Alcançável, Relevante e Temporal) e são usualmente baseadas em indicadores

de desempenho (KPI) (IPD – Indicador Principal (ou chave) de Desempenho) .

(LOGO: RNS -> MNS)

 Definição de Requisitos – (Statement of requirements - SOR)

É um documento que contém todos os requisitos necessários para a compra de um produto, um

novo Serviço de TI ou para alteração de um Serviço de TI. (RNS -> DDR)

É o Requisito do Serviço para TI desenhar o Serviço novo ou alterado (PROJETO). Também conhecido
como Termo de Referência

(o SOR vai até o nível técnico: tem a configuração dos componentes do Serviço)

(LOGO: “RN”-> RNS-> DDR)

  Acordo de Nível de Serviço – (Service Level Agreement – SLA)

É um acordo formal, realizado entre o Provedor de Serviços de TI e o Cliente; (RNS -> ANS)

O SLA descreve o Serviço de TI, documenta as Metas de Nível de Serviço acordadas e especifica as
responsabilidades do Provedor de Serviço de TI e do Cliente.

(LOGO: RNS -> ANS)

 Tipos de Acordos de Nível de Serviço

ANS baseado em Serviço;

ANS baseado em Cliente;

ANS Multi-Nível.

 Acordo de Nível Operacional

– (Operational Level Agreement – OLA)

 Contrato de Apoio
– (Underpinning Contract – UC)

(LOGO: ANS -> OLA/UC)

CRIAÇÃO DOS SERVIÇOS A PARTIR DA ESTRATÉGIA E MELHORIA

CONTÍNUA COM SLA´s, MNS´s, KPI´s ORGANIZADOS EM UM SIP.

“ON”  “RN”
 RNS  “OTI”  “RS”

RNS  MNS  KPI SIP

“RN”  RNS  DDR

RNS  ANS

ANS  OLA/UC  KPI SIP

SLIDE 104 – ESTRUTURA DO SLA USANDO O CATÁLOGO:

FONTE ITSM traduzido pela Trainning

a) Utilizar o Catálogo de Serviços. Criar templates.

b) Catálogo de Serviço pronto e a estrutura de SLAs acordada, o primeiro desenho do SLR pode ser feito. É
recomendável que o cliente participe desde o início e que se inicie com um esboço apresentando os
objetivos de desempenho e os requisitos de gerenciamento e operacionais, como ponto de partida. SLRs
devem
vem ser uma parte integral dos critérios do Desenho de Serviço.

c) Nada deve ser incluído num SLA se não puder ser monitorado e medido.

d) Sentimento do cliente devem ser monitorados por pesquisas de satisfação. Há casos em que, mesmo
diante de incidentes recorrentes
correntes o cliente demonstra satisfação, porque as ações apropriadas estão sendo
adotadas para melhorar a situação e ele está sendo devidamente comunicado. Por outro lado, o cliente
pode estar insatisfeito, embora não tenha havido quebra de SLA. SATISFAÇÃO=PERCEPÇÃO
SATISFAÇÃO=PERCEPÇÃO – EXPECTATIVA
(negativo é cliente insatisfeito)

e) Acordos e Contratos mantidos atualizados

f) Envolver clientes e stakeholders;

stakeholders

g) Gerar relatórios com KPIs e MNS acordados;

h) Conduzir a revisão dos Serviços acordados e estimular melhorias através de um

um Plano de Melhorias do
Serviço (SIP);

Obs: Contrato é feito pelo Gerenciamento de Fornecedor auxiliando o SLM com o nível de serviço dos terceiros.
SLIDE 105

KPI

 Estas métricas devem ser desenvolvidas através da perspectiva do próprio serviço, do cliente e do Negócio
(tal como as perspectivas do BSC – Cliente, Financeira, Processos Internos e Aprendizado e Crescimento);

SLIDE 121

(AMIS) – (contém o Plano para manter a Disponibilidade dos Serviços e seus Componentes).

SLIDE 122

(Ex: Planejada: “24x7” com 1 parada por mês de 4 horas .

Horas ano=8760, parada=48, DISP=(8760-48)/8760=99,45%)

SLIDE 123

(Confiabilidade) geralmente é medida como:

 Tempo Médio entre Falhas – (Mean Time Between Failures - MTBF) – (UP TIME =
DISPONIBILIDADE);

(INICIO INCIDENTE 3 – FIM INCIDENTE 2).

 Tempo Médio entre Incidentes de Serviço –(Mean Time Between Service Incidents - MTBSI)

(INÍCIO INCIDENTE 2 – INÍCIO INCIDENTE 1).

SLIDE 124

Sustentabilidade é frequentemente medida e reportada como:

 Tempo Médio para Recuperar Serviço (Mean Time to Restore Service – MTRS).

(FIM DO INCIDENTE – INICIO DO INCIDENTE)

SLIDE 125

Oficiosidade = Disponibilidade + Confiabilidade + Sustentabilidade

SLIDE 126

(SLAs contém acordos sobre os requisitos de disponibilidade dos serviços A, B e C)

SLIDE 134

(CMIS) - (armazena o Plano de Capacidade dos Serviços e seus componentes e ativos relacionados).

SLIDE 135

Pode ser alcançado pelo uso dos dados existentes na utilização atual de recursos (PAN), para analisar
as tendências, previsões e modelos sobre necessidades futuras dos Serviços de TI.

PENSA NO NEGÓCIO PARA PENSAR NO SERVIÇO

SLIDE 136

PENSA NO SERVIÇO EM PRODUÇÃO PARA ENTREGAR SLA e ATENDER SLR PARA O NEGÓCIO

SLIDE 137

PENSA NO COMPONENTE QUE SUPORTA O SERVIÇO!

SLIDE 139

O GERENTE DE CAPACIDADE NÃO PRECISA FAZER O CÁLCULO DA CAPACIDADE, POIS REQUER ESPECIALIDADE (ele é o
“A” da matriz RACI)

SLIDE 140

O Gerente de Capacidade confronta o SLA com a falta de Capacidade registrada nos Incidentes e Problemas.

FIM PARTE 1 – OMAR MUSSI – 03/11/2009