ITIL V3

Curso
ITIL - Information Technology Infrastructure Library

Formador: Carlos Domingues


• Enquadramento

• Âmbito do ITIL

• Operação de TI – Tecnologias de Informação

• Conceitos básicos de ITIL

• Os vários processos do ITIL
• Integração entre processos
• Próximos passos


Enquadramento
• Governação de TI
– Conceitos e boas práticas
• ITIL
– Estrutura, conceitos e processos
– Service Strategy, S. Design, S. Transition, S.Operation, CSI
• COBIT
– Estrutura, conceitos e processos
• CMMI, ISO 17799, PMBOK e outros modelos
– Visão geral
• Integração e aplicação dos modelos


Enquadramento – Governação de TIs

Alinhamento Alinhamento entre as TIs e o negócio (tanto no
estratégico planeamento como nas operações)

Agregação de Garantia de alcance dos benefícios, com otimização de
valor custos

Gestão de
Otimização dos investimentos e do uso dos recursos de TI
recursos

Incorporação do tratamento de riscos e da conformidade
Gestão de riscos
nos processos

Avaliação do
Uso do BSC para avaliar todas as dimensões das TIs
desempenho


Enquadramento - Desafios das TIs

Alinhamento Falta de visão sistémica sobre as TIs e falta
estratégico de conhecimento sobre o negócio

Supremacia da visão tecnológica sobre as
Agregação de valor
necessidades do negócio

Processos inexistentes ou com baixo nível de
Gestão de recursos
maturidade

Gestão de riscos Postura reativa (apagar incêndios)

Avaliação de
Indicadores com foco na tecnologia
desempenho


Enquadramento – Evolução Verificada

• Aumento da dependência da TI para alcance de objetivos
estratégicos das organizações

– Maior criticidade dos recursos de TI requer aumento da
confiabilidade, disponibilidade e capacidade desses recursos

• Aumento da complexidade e do custo da TI, com ciclos de
mudança cada vez mais rápidos

• Maior visibilidade do desempenho e, portanto, dos problemas da
área de TI


Enquadramento – A Solução Segundo o ITIL
• Tecnologia da Informação como serviço

– Requisito básico para operação do negócio

– Garantia de funcionamento dentro dos parâmetros
estabelecidos previamente

• Acordos de nível de serviço

– Confiabilidade do suporte ao negócio

– Qualidade (disponibilidade, desempenho)

– Custo

• Visão baseada em processos


Âmbito – TI como um serviço

Conjunto mensurável de resultados
– Que são providos por elementos de Tecnologia da
Informação e correlatos

– Que são compreendidos como um todo coerente pelo
usuário

– Que suportam processos de negócio


Operações de TI

Os Problemas:
Recursos limitados

Cultura de silos

Complexidade crescente

Administração do Legado

Falhas de Comunicação


Os processos
percorrem as
organizações
horizontalmen-te

As organizações estão
estruturadas verticalmente


Conceitos Básicos de ITIL
O que é ITIL?
O que é um processo?
Processo x Projeto de Revisão/Implementação
Melhoria Contínua(da)


O que é o ITIL

O ITIL (Information Technology Infraestructure Library) é a
abordagem mundialmente mais difundida e adotada para o
Gerenciamento de Serviços de TI (Service Management)

Constitui-se de uma descrição coerente e integrada de melhores
práticas de Gerenciamento de Serviços de TI.

Adaptável ao Negócio, Cultura, Estrutura, Ambiente, Processo


O que é um processo?
Uma série interligada de ações e atividades, realizadas com um objetivo
definido, através de algum tipo de recursos e em conformidade com
regras pré definidas:

Regras

Entrada Atividades Saída

Recursos


Relacionamento com Sub-Processos
Contrato Budget Orçamento

Solicitação
de Orçamento/
Orçamento
Contratação do
Aprovado
Serviço Solicitar
Orçamento

Obter
Aprovação

Relação de Serviços Contratados Atualizada
Aditar Notificação do Serviço Contratado
Contrato

Fornecedor Diretoria Jurídico


Actividades


Actividades

Atividade Atividade Atividade


Conceitos Básicos de ITIL

 Information Technology Infrastructure Library
(ITIL)

 Biblioteca de boas práticas

 É um conjunto de livros que busca promover a

gestão com foco no cliente e na qualidade dos

serviços de tecnologia da informação.


História do ITIL

Surgiu no final dos anos 80 na Inglaterra desenvolvido pela CCTA
(Central Computer and Telecommunications Agency).

No início dos anos 90 foram desenvolvidas as “Best Practices” do ITIL e
algumas grandes empresas e agências governamentais européias,
passam a utilizá-lo.

Em 2000 é criado o OGC - Office for Government Commerce para
regulamentar o uso do ITIL e a Microsoft passou a utiliza-lo para
desenhar o MOF – (Microsoft Operation Framework).

Em 2001 são criados o EXIM (European Examination Institute for
Information cience) e o ISEB (Information Systems Examination Board)
para certificar empresas e profissionais dentro do método ITIL.


História do ITIL
V1 1989- V2 2000-
1995 2004
•Desenvolver •Criado o itSMF (IT •Publicada
aplicações •Serviços e negócios Service •Publicações da 2ª da 3ª
•Atender Management versão pela OCG versão pela
•CCTA produz o ITIL Forum) OCG
necessidades para padronizar (antiga CCTA)
Até Anos compra de serviços 1991 itSMF V3 2007
70

Sucesso do ITIL:
– Não é proprietário: As melhores práticas são públicas
– Não prescritivo: Sugestões maduras e robustas
– Melhores práticas: Experiência de anos de utilização
– Orientado a processos: Com foco no cliente
– Justifica custos de TI: Eficaz em organizações de qualquer porte
– Aderente à qualidade: Independente de tecnologia/fornecedor


Foco no resultado

Resultado Esperado?

Resultado Alcançado?


Entidades Envolvidas

• OGC (Office of Government Commerce):
– Antiga CCTA (Central Communications and Telecommunications
Agency)
– Comitê gestor e proprietário do ITIL
• TSO (The Stationery Office):
– Responsável pelas publicações (Livros e CDs)
• itSMF (IT Service Management Forum):
– Associação mundial de profissionais
• EXIN, ISEB, Loyalist College:
– Coordenam treinamentos e certificações.


Tecnologia é só a ponta do Iceberg


ITIL V1

A primeira versão ou o denominado ITIL
original, durou de 1986 até 1999. Ela foi
desenvolvida pela CCTA e era denominada
“Government Information Technology
Infrastructure Management Methodology -
GITMM”. Ao longo de sua existência ela
chegou a ser composta por 31 livros.


ITIL V2

A segunda versão - ITIL V2 - durou de
1999 até 2007 e possui 8 livros. O
foco principal desta segunda revisão
foi à consolidação das publicações
anteriores em conjuntos lógicos que
agrupavam os processos relacionados
aos diferentes aspectos do
gerenciamento de TI, aplicações e
serviços.


ITIL V2 IT Service

security
Service Level Continuity
Management Management

Availability
Management Release
Management
Capacity
Management
IT
Change
Financial Infrastructure Management
Management
for IT services Configuration
Management
Incident
Management Problem Management


ITIL V3

A ITIL V3, disponibilizada em 30 de
Maio de 2007 reduziu o número de
livros e alterou o foco da ITIL.
Presentemente é vista como o ciclo de
vida dos serviços. O conteúdo foi
condensado em cinco volumes.


ITIL V3

 Melhorar práticas sobre
processos que devem ser
realizados na organização
visando gerenciar e operar a
infra-estrutura de TI e promover
serviços ótimos para o cliente
com custos justificáveis.


ITIL V3
Introdução – Ciclo de Vida de Serviços
– Service Lifecycle
• 1. Estratégia de Serviços
– Service Strategy
• 2. Projeto de Serviços
– Service Design
• 3. Transição de Serviços
– Service Transition
• 4. Operação de Serviços
– Service Operation
• 5. Melhoria de Serviços
– Service Improvement


Versões do ITIL

Versão 3

Versão 2
Ciclo de vida de serviços

Maturidade em

Versão 1
processos

Melhores práticas


Mudança do ITIL v2 para ITIL v3
• As mudanças entre as versões são
substanciais, a abordagem dos
processos e o modo de pensar em
ITIL com certeza mudou. Na nova
versão, os processos estão
agrupados por “módulos” e seguem
uma sequência lógica para o
entendimento das boas práticas. A
grande mudança foi separar os
processos através de um ciclo de
vida: Estratégia, Desenho,
Transição, Operação e Melhoria de
serviço continuada.


Mudança do ITIL v2 para ITIL v3

O que escolher?


O ITIL v3 substitui o ITIL v2?
• A resposta é SIM. Mas todos os
processos, ferramentas, políticas e
cultura já assimiladas da ITIL v2 vão
facilitar e agilizar a implementação ou
migração de uma para uma nova
versão posteriormente. Naturalmente,
a v3 irá seduzir com as novas
oportunidades para melhorar as suas
práticas de gestão de serviços, mas é
aconselhável ser diligente e certificar-
se de que esta transição ocorra com
facilidade e com tempo.


O ITIL v3 substitui o ITIL v3
Processo ITIL 2 Localização no ITIL 3 • Novos Processos:
Gestão de Incidentes Operação de Serviços – Geração da Estratégia
Incident Management Service Operation
– Aspectos do Projeto de
Gestão de Problemas Operação de Serviços Serviços
Problem Management Service Operation
Gestão de Configuração Transição de Serviços
– Gestão de Fornecedores
Configuration Management Service Transition – Modelos de Outsourcing
Gestão de Mudanças Transição de Serviços – Sistema de Gestão do
Change Management Service Transition
Conhecimento de Serviços
Gestão de Liberações Transição de Serviços
Release Management Service Transition – Projeto e Gestão de
Gestão do Nível de Serviços Melhoria Contínua de Serviços Aplicações
Service Level Management Continual Service Improvement – Projeto e Gestão de
Gestão de Disponibilidade Projeto de Serviços Arquitetura de Tecnologia
Availability Management Service Design
– Mensuração de Serviços
Gestão de Capacidade Projeto de Serviços
Capacity Management Service Design – Gestão de Eventos
Gestão Financeira Estratégia de Serviços – Requisição de
Financial Management Service Strategy
Aprovisionamento
Gestão de Continuidade Projeto de Serviços
IT Service Continuity Management Service Design


Ciclo de Vida de Serviços - Resumo

Service Strategy

• Guia para o desenvolvimento de modelos e estratégias baseadas
em serviços
• Mostra como transformar gestão de serviços em bens /activos
estratégicos.
• Garante que as várias fases do ciclo de serviço está focado no
negócio / actividade.
• Definição de princípios da gestão de serviços, como base para
decisões, políticas e processos do ciclo de vida

Processos
– Business Relationship Management
– Financial Management
– Service Portfolio Management
– Demand Management
– Organization Development
– Sourcing Management

Service Strategy
Service Strategy Align Business and IT
Ensure IT Stays Focused on Business requirement
Through out the service lifecycle
Stategy Generation
Define Market
Develop Offerings
Financial Management
Develop Strategic Assets
Prepare for execution
Service Portfolio
Management
Financial Compliance and control
Quantify Assets and Services in Financial terms
Demand Management

Achieve Optimal levels of ROI and Risks
Seek efficient portfolio that will effectively use the
limited resources

Minimize Uncertainty in demand
 Provide reliable planning based on the demands
Avoid excess and insufficient capacity

Service Strategy

Na entrega de serviços ao cliente, qual é o seu conceito de valor? (VALUE)

VALOR Serviço = Utilidade + Garantia

Evita Custos e Riscos Desnecessários O Serviço está disponível quando necessário
Elimina constrangimentos e dificuldades Evita quebras de produção
Aumenta performance e eficiência Garante continuidade no negócio
(Availability/Capacity/Continuity/Security)

Service Strategy
Isto, porque …

Service Strategy
Avalilability – disponibilidade de serviço
MTBF ("Mean Time Between Failures") ou período médio entre falhas é um
valor atribuído a um determinado dispositivo ou aparelho para descrever a
sua disponibilidade.

Service Strategy
Avalilability – disponibilidade de serviço
MTTR ("Mean time to repair”) é uma medida básica para quantificar o
tempo de reparação de um equipamento ou a reposição de um serviço.
Representa a média de tempo necessária à reparação de avaria de
equipamento e/ou à reposição de um serviço.

Availability= MTBF/(MTBF+MTTR)

if we are using equipment which has mean time between failure (MTBF)
of 81.5 years and mean time to recovery (MTTR) of 1 hour:
MTBF in hours = 81.5*365*24=713940
Availability= MTBF/(MTBF+MTTR) = 713940/713941 =99.999859%
Unavailability = 0.000141%

Service Strategy
Capacity– Capacidade de serviço
Capacidade é uma garantia de que o serviço irá suportar uma quantidade
de actividade ou procura por parte dos clientes, mantendo uma
determinada qualidade. Ou seja, variações na procura ou na utilização do
serviço não condicionam a utilidade e garantia do mesmo.

A rever mais adiante

Service Strategy
Continuity– Continuidade do serviço
A Continuidade do serviço assegura que este continua disponível, mesmo
após falhas pontuais (no conjunto ou nas suas componentes), ou eventos
disruptivos.

Conceitos relacionados:
• Alta disponibilidade
• Redundância
• Disaster Recovery
• Plano Contingência
• Gestão do Risco

etc..

Service Strategy
Security– segurança do serviço
O ITIL garante que a segurança dos serviços e da informação é gerido tanto
a nível estartégico, como tático e operacional.

A segurança da informação deve ser considerada tanto no controle, no
planeamento, na implementaçãio,na avaliação e na manutenção.

O ITIL divide a segurança da informação e dos serviços em Políticas:
objetivos gerais que a organização deve atingir.
Processos – o que deve ser feito para atingir os objectivos.
Procedimentos – quem e quando se devem desenvolver determinadas
actividades
Instruções de Trabalho- Como é que de devem fazer determinados
procedimentos


Service Strategy

Service Strategy
Assets == Activo
Ativo é um termo básico utilizado para expressar o conjunto de bens, valores,
créditos, direitos e
assemelhados que
forma o património
de uma pessoa,
singular ou coletiva,
num determinado
momento .(Wikipedia)

Service Strategy
Assets == Activo

Service Strategy
Configuration Items
Em ITIL, Configuration Items são Assets (Bens) activos, que eu pretendo controlar ao
longo do ciclo de vida do serviço.

Service Strategy
Configuration Items
Any Component that needs to be managed in
order to deliver an IT Service. Information
about each CI is recorded in a Configuration
Record within the Configuration Management
System and is maintained throughout its
Lifecycle by Configuration Management. CIs
are under the control of Change Management.
CIs typically include IT Services, hardware,
software, buildings, people and formal
documentation such as Process documentation
and SLAs.

Exercício
Foi consultado por uma empresa de desenvolvimento de SW, que desenvolveu
recentemente um produto para a prescrição electrónica de medicamentos. Essa
empresa pretende introduzir o seu produto em todo o mercado nacional (continente
e ilhas).

É-lhe solicitada uma abordagem global para verificar se a estratégia da empresa
está de acordo com as boas práticas ITIL.

Alguns pontos a verificar:
• caracterizar valor do serviço (utilidade e garantia)
• caracterizar formas de garantia de disponibilidade de serviço, capacidade, continuidade, segurança
• caracterizar os assets e CIs

Service Strategy

PROCESSOS


Objetivos:
Definir Estratégias de Serviços e definir cenários de
crescimento
Prioritização de Investimentos
Estabelecer requisitos para fases seguintes

Sub-Processos:
Definir o Mercado (oportunidades/necessidades/requisitos/relações)
Desenvolver Oferta (definir área de mercado – geográfica/etária/…)
Desenvolver “assets” estratégicos (serão eles a chave do sucesso)
Preparar a execução (Definir portfólio/ requisitos do SD, ST, SO )

Técnicas:
 Análises SWOT (Força, Fraqueza, Oportunidades, Ameaças)
4 Ps – Perpective, Position, Plan (As-Is / To-Be) , Pattern


Objetivos:
Alcançar níveis ótimos de ROI e Risco
Procurar contruir portfólio eficiente com recursos limitados

Elementos:
 Proposta de Valor
 Business Case (sustentação/ justificação do investimento no novo serviço.
Previsão de Resultados e benefícios)
 Prioridades
 Riscos
 Custos e Preços

O Service Portfolio está dividido em três secções:
1. Service Pipeline
2. Service Catalogue
3. Removed Services


Resultados possíveis de produtos em Catálogo
(Ativos)

6Rs

1. Retain (manter)
2. Replace (substituir)
3. Rationalize (racioanlizar)
4. Refactor (reformular)–ex. integrar com outros serviços Core
5. Renew (renovar) – ex. serviços tecnologicamente obsoletos
6. Retire (retirar)


Objetivos:
 Minimizar incerteza na procura
 Garantir planeamento eficiente, com
Base na procura
Evitar excesso ou falta de capacidade

Conceitos:
Activity Based Demand Management
(planeamento da procura é feita com base no negócio do cliente. O que é que o
cliente precisa?)

Business activity patterns and user profiles
(planeamento da procura é feito com base em padrões ou perfis de clientes. O
que é que o cliente procura?)

 Service Packages
(serviços e soluções são empacotados de acordo com a necessidade mais global
do cliente)


Objetivos:
Garantir controlo e conformidade financeira
Quantificar (finaceiramente) quanto valem os Assets e os
Serviços da organização
Conceitos:
Service Valuation (medida que representa o custo total de entrega do
serviço, assim como o valor que o serviço representa para a organização)
 Demand Modeling (identificação do custo de utilização de um serviço, e
a previsão de encargos da sua utilização no futuro)
 Service Provisioning Optimizaton (avalia formas alternativas de
provisão de serviços, que sejam mais custo/efetivos.
 Planning Confidence (Cumprimento de regras legais e alcance da
confiança do cliente)
Service Investment Analysis (Custo Total do Serviço em todo o ciclo)
 Accounting (Permite perceber a relação service provisioning/ consumption)
Variable Costs Dinamics –VCD (analise multi variável do custo do
serviço)


Conceitos:
 TCO – Total Cost of Ownership ou custo total da posse, é
uma estimativa financeira projetada para consumidores e
gerentes de empresas a avaliar os custos diretos e indiretos
relacionados à compra de todo o investimento importante,
tal como softwares e hardwares, além do gasto inerente de
tais produtos para mantê-los em funcionamento, ou seja, os
gastos para que se continue proprietário daquilo que foi
adquirido.


Conceitos:
 TCU – Total Cost of Utilization ou custo total da utilização
de um serviço, por parte de um cliente, em todo o seu ciclo
de vida.

 ROI - Retorno sobre investimento (em inglês, return on
investment), também chamado taxa de retorno é a relação
entre o dinheiro ganho ou perdido através de um
investimento, e o montante de dinheiro investido.

Service Strategy
Business Case

Um business case especifica e
documenta os fatores racionais para
iniciar um projeto ou tarefa. É
quase sempre apresentado num
documento escrito bem
estruturado. A lógica do caso de
negócio é que, sempre que os
recursos, como dinheiro ou esforço
são investidos, devem ser avaliadas
as alternativas e estimado o retorno
desse investimento.

http://www.businesscase.com.br

Service Strategy
Business Case - Conceitos
IRR (Internal Rate of Return) –A Taxa Interna de Retorno (TIR), em inglês
IRR (Internal Rate of Return), é a taxa necessária para igualar o valor de um
investimento (valor presente) com os seus respectivos retornos futuros ou saldos de
caixa. Sendo usada em análise de investimentos significa a taxa de retorno de um
projeto.

Payback - Payback é o tempo decorrido entre o investimento inicial e o
momento no qual o lucro líquido acumulado se iguala ao valor desse
investimento. O payback pode ser nominal, se calculado com base no fluxo
de caixa com valores nominais, e presente líquido, se calculado com base no
fluxo de caixa com valores trazidos ao valor presente líquido.

NPV (Net Present Value) - O valor presente líquido (VPL), também
conhecido como valor actual líquido (VAL) ou método do valor atual, é a
fórmula matemático-financeira capaz de determinar o valor presente de
pagamentos futuros descontados a uma taxa de juros apropriada, menos o
custo do investimento inicial. Basicamente, é o calculo de quanto os futuros
pagamentos somados a um custo inicial estariam valendo atualmente

Service Strategy
Elaboração de um Business Case
Desenvolvimento de SW de Prescrição Eletrónica de Medicamentos

• Matriz RACI (Responsible Accountable Consulted Informed )
• Stakeolders
• Tipo Investimento (CAPEX, OPEX)
• Prioridade
• Complexidade
• Ganhos /beneficios
• Aprovação

• AS IS
• TO BE
• RISCOS
• Oportunidades
• Indicadores /Metas – Custos
• Infraestrutura
• Proposta de Valor
• Restrições e Requisitos


Próximo capítulo

Service DESIGN


OBJETIVOS

1. Desenhar/Estruturar novos serviços ou alteração a
serviços existentes
2. Desenvolver serviços alinhados com estratégia
definida no capítulo anterior : Service Strategy
3. Considerar/Prever impacto no “todo”, durante a
fase de desenho do “individual”.
4. Analisar todos os aspetos individuais das fases
funcionais, gestão e operacionais, no momento de
desenho do serviço.
5. Reduzir TCO e Aumentar / Melhorar IT Governance


Âmbito

• Desenhar (ou reformular) serviços inovadores, com
arquiteturas apropriadas, processos estruturados,
políticas consistentes, documentação abrangente,
que cumpram as exigências e requisitos da
organização (atuais e futuros)

• Desenhar serviços que satisfaçam objetivos e
requisitos do negócio / atividade, baseados em altos
padrões de qualidade, de conformidade, risco e
segurança.


Modelo – 4 Ps

• Pessoas, com os seus papeis (roles) e responsabilidades
• Processos, onde o ITIL aparece com uma cobertura
global.
• Produtos e tecnologias, sem os quais as organizações já
não subsistem.
• Parceiros ou fornecedores, cuja gestão/articulação é
mandatória para fornecimento de serviços de qualidade.


Service Catalog Management, é um subset do Service
Portfolio que incluir o conjunto de serviços
disponibilizados aos clientes. Inclui um conjunto de
detalhes sobre os novos serviços (ou a alteração de
serviços existentes).

Service Design Package – documento que define um
conjunto de requisitos do serviço. Define ainda o
âmbito do mesmo, balizando a solução apresentada,
incluindo os seus constrangimentos técnicos ou
funcionais.


Business Serv ice Catalog : A customer friendly document (not techinical jargon)
used to show the relationship between IT services and the business
Technical Service Catalog: A technical document used by IT to define and
communicate the relationship between IT services and any supporting services,
components or CIs.


Objetivos:
Assegurar que os níveis de serviço assumidos são
cumpridos.
 Implementar e melhorar métricas de medida dos níveis de
serviço.
 Definir, documentar, acordar, moitorizar, medir, reportar e
rever o nível de serviço fornecido.
 Disponibilizar e melhorar a(s) forma(s) de comunicação
com o cliente
 Assegurar que estão definidas todas as medidas
necessárias para a demonstração do cumprimento dos níveis
de serviço.
Monitorizar e melhorar a satisfação do cliente

KPIs: Satisfação Clientes, Níveis Cumprimento Alcançados,
Atualização SLAs, Peridiocidade Relatórios, Severidade das
Falhas, et..


Âmbito

OLA - Operational Level Agreements
SLA – Service Level Agreements
UC - Underpinning agreements


SIP

SLR – Serv ice Level Requirement
SIP – Serv ice Improvement Program


Capacity Management é o processo que trata de:

The right capacity
The right location
The right moment
For the right customer
Against the right costs

Com o objetivo de ir ao encontro da procura atual e
futura de um determinado serviço por parte do
cliente.


Availability Management é o processo que trata de:

• Otimizar a capacidade da infraestrutura
• Definir plano de disponibilidade
• Garantir SLAs sem desvio
• Recomendar e liderar melhorias que garantam
aumento da disponibilidade a custos justificáveis


Service Continuity:

• Processo responsável por definir planos de
contingência e recuperação de serviço

BIA (Business Impact Analysis) – Analisa o impacto que a
indisponibilidade das Tis têm no negócio

Risk Analysis – Avalia os Activos, Ameaças e
Vulnerabilidades

Business Continuity Plan – Plano de continuidade de
Negócio


Business Continuity Plan – O que deve conter:
Plano de Ação / Lista de Tarefas
a) Como é que o Plano é ativado;
b) Quais as pessoas responsáveis por ativar esse plano
c) Procedimentos que essas pessoas devem adotar ao
tomar a decisão de ativar o plano;
d) Pessoas que devem ser consultadas antes desta
decisão ser tomada;
e) Pessoas que devem ser informadas quando a decisão
for tomada;
f) Quem vai para onde e quando;
g) Quais os serviços que estão disponíveis, onde e
quando, incluindo como é que a organização
mobilizará seus recursos externos e de terceiros;



h) Como e quando esta informação será comunicada.
i) Procedimentos detalhados para soluções manuais,
recuperação dos sistemas etc.

Os planos devem referenciar as pessoas, instalações,
tecnologia, informação e todas as partes
interessadas identificados na fase de estratégias.
Devem ser incluídas premissas claras e
detalhamentos sobre quaisquer recursos necessários
para implementar os planos. Caso a falta de um
serviço ou recurso torne os objetivos desse plano
inalcançáveis, um procedimento claro deve ser
definido para que o problema seja escalado a um
nível mais alto.


Recursos necessários
Convém que os recursos necessários para a continuidade
e recuperação dos negócios sejam identificados em
diferentes pontos no tempo. Estes podem incluir:
a) pessoas:
- segurança,
- logística de transporte,
- necessidades de bem-estar e gastos de emergência;
b) instalações;
c) tecnologia, incluindo comunicações;
d) informações, o que pode incluir:
- detalhes financeiros
- documentos legais
- outros documentos de serviços
e) gestão das partes interessadas e da comunicação com
estas.



Responsáveis
Convém que a organização identifique e designe um
responsável para coordenar as fases da continuidade e da
recuperação dos negócios que ocorrem após uma interrupção
de serviços

O plano pode incluir também formulários para armazenar
dados administrativos, como, por exemplo, os recursos
usados, material para controle de despesas, mapas,
desenhos e plantas do local e do escritório, especialmente
aqueles relacionados a instalações alternativas, tais como
áreas de recuperação do local de trabalho e de
armazenagem.


perfis ¶

ISMS - Information Security Management System ¶


ISMS - Information Security Management System ¶


Matriz de Segurança Ativa


Supplier Management

Tem como principais objetivos:

• Garantir que os recursos financeiros são utilizados
da forma eficaz, com parceiros custo/efectivos.

• Ajustar o âmbito jurídico dos contratos em
conformidade com as necessidades do negócio
• Gerir o relacionamento e a performance dos
fornecedores

Ótica Win-Win


Supplier Management

Devem ser consideradas:

• Políticas de inclusão e manutenção dos fornecedores
• Centralização (base de dados) para os contratos
• Categorização dos fornecedores e o risco de
investimento
• Avaliação de Contratos
• Negociação e Aprovação de Contratos
• Revisão, Renovação e Término dos Contratos

http://www.mitsm.de/itil-wiki/process-descriptions-english/supplier-
management


FERRAMENTAS de Suporte ao Design
- Software e Hardware
- Processos
- Ambiente / Meio envolvente
- Dados
- Otimização
- Validação
- Standards
- Modelação
- Simulação e Prototipagem


METODOLOGIAS de Suporte ao Design
- Insourcing
- Outsourcing
- Co-sourcing
- Multisourcing
- Partnership
- Business Process, Knowledge Process

Service Design


Próximo capítulo

Service Transition

Service Transition

O objetivo do ITIL Service Transition é colocar em produção serviços de IT.
Service Transition garante que os novos serviços e a as alterações aos
serviços em produção são desenvolvidos e coordenadas de forma integrada.

Transição de serviços, como descrito pelo volume de Service Transition, diz
respeito à prestação de serviços exigida por um negócio em Business as
usual.

Lista de processos ITIL de Service Transition (ST):

• Transition planning and support
• Change management
• Service asset and configuration management
• Release and deployment management
• Service validation and testing
• Change evaluation
• Knowledge management

Service Transition


Conceitos ITIL
Service Knowledge Management System (SKMS)

O Sistema de Gestão do Conhecimento (SKMS) é um
repositório de informação e conhecimento centralizado.
O seu objetivo é armazenar, analisar e disponibilizar à
organização um conjunto de dados, informação e
conhecimento necessários á operação das tecnologias e
dos sistemas. O SKMS não é necessariamente um único
sistema. Na maioria dos casos, será um sistema integrado
suportado em varias fontes de dados.

Data - from metrics are turned into quality information
Information - combining this with context, experience and
interpretation becomes knowledge
Knowledge - having the above enables correct decisions to be made
which in turn is perceived as wisdom
Wisdom - the culmination of all of the above


O objetivo da gestão da mudança neste contexto é garantir
que os métodos e procedimentos padronizados são
usados para o tratamento rápido e eficiente de todas as
alterações para controlar a infraestrutura, a fim de
minimizar o número e o impacto de eventuais incidentes
relacionados ao serviço.

Gestão da Mudanças pode garantir métodos padronizados,
processos e procedimentos que são utilizados para todas
as mudanças, facilitar o manuseio rápido e eficiente de
todas as mudanças e manter o equilíbrio adequado entre
a necessidade de mudança e o impacto potencial
negativo de mudanças.

Redução Risco


CAB – Change Advisor Board
•Gestor da Mudança (Coord.)
•Utilizadores
•Clientes
•Especialistas
• Programadores
• Técnicos
• Outros

ECAB
ECAB – Emergency CAB


Um change request deve incluir:
Unique ID
Date of submission
Change Owner
Initiator of the RFC (if not identical with Change Owner)
Proposed Change priority (e.g. "Very High (Emergency Change)",
"High", "Normal", "Low" - may be overruled by Change
Management during Change assessment)
Description of the Change being applied for
Summary description
Business case
Reason for the Change to be implemented
Costs
Benefits
Consequences if the Change is not implemented
References (e.g. to a Problem Record triggering this RFC)
Business areas on the client-side affected by the Change
Services affected by the Change
IT infrastructure components (CIs) affected by the Change

RFC- Request for Change


Technology aspects (is a new technology being introduced?)
Risks during the implementation of the Change
Identified risks
Counter-measures (e.g. reversion procedure)
Back-out strategy for the case of a failed Change
implementation
Predicted/suggested time schedule for the implementation
Estimate of resources for the implementation
Required personnel resources (from which areas?)
Estimated work effort for the required personnel resources
Cost estimate (itemized for bigger Changes)
Statement as to whether a budget is allocated and cleared for this
Change
If applicable, index of additional supporting documents (e.g. the
Service Design Package for major additions or modifications to
services)


Approval or rejection
Date
Person/ body in charge of the approval (Change Manager/ CAB/
ECAB)
Change reviewers
Priority assigned by Change Management
Restrictions
If applicable, reasons for rejecting the RFC


Estratégia

Change
Mgment

Tatica Operacional


Tático
Avalia Prioritiza Autoriza Planeia

Operacional
Testa Implementa Documenta Mantem

7 Rs das Mudança
Raised
Reason Resources
Return Relationship
Risks Responsible

ITIL KPIs Change Management

Key Performance Indicator
Definition
(KPI)
Number of major changes assessed by the CAB
Number of Major Changes
(Change Advisory Board)
Number of CAB Meetings Number of CAB (Change Advisory Board) meetings

Average time from registering an RFC with Change
Time for Change Approval/
Management until a decision on the RFC is reached
Rejection
(i.e. until it is either approved or rejected)

Change Acceptance Rate Number of accepted vs. rejected RFCs

Number of Emergency Number of Emergency Changes assessed by the
Changes ECAB (Emergency Change Advisory Board)


Objetivos

Definir e controlar os Configuration Items
Proteger a integridade dos Assets e Cis
Garantir informação actual e fidedigna de assets e CIs


Um CI deve, normalmente, ter:

Unique identifier
Name
Description
CI owner/ person in charge
CI type, for example
Main Type (e.g. Service, Hardware, Software,
Document, Staff ...)
Sub-type (e.g. Server, Printer, ... - refinement of the
classification into categories)
Reporting, auditing and verification requirements
Manufacturer information
Manufacturer name
Serial number



License number/ reference to license contract
Version
Modification history of the CI Record
Date of creation
Modifications
Description of modification
Date
Person in charge
Location
Physical location, if applicable
Logical location, if applicable (e.g. fileserver directory)



Status history (description of the life cycle of a CI with
status values, as for example „Undergoing Test“, ...,
„Active“, ..., „Undergoing Maintenance“, ..., „Out of
Operation“, ...)
Present status and version
Status and version history (historical Changes to the
status of the CI or Changes planned for the future)
Status change
Description
Time and date of the Change in status
Relationships to IT services



Relationships to other CIs, e.g.
Is a component of
Is associated with
Uses
Is a characteristic of
Is a new version of
Will be replaced by
Relationships to other data objects within Service
Management
Incident Records
Problem Records
Known Errors
Change Records
License details



Document references
Applicable policies and guidelines
Contractual documentation
Operating documentation
User documentation
Emergency-relevant documentation
Other documentation

Ex. http://www.onecmdb.org

ITIL KPIs Service Asset and Configuration Management

Key Performance
Definition
Indicator (KPI)
Frequency of physical verifications of CMS
Verification Frequency
contents
Number of Incidents reported where the
Number of Incidents
underlying cause of the Incident is the result of
owing to inaccurate CMS
inaccurate configuration management
Information
information
Effort for CMS Average work effort for physical verifications of
Verifications the CMS contents
Percentage of configuration components for
CMS Coverage
which data is kept in the CMS
Number of unauthorized Number of unauthorized changes identified as a
Changes detected result of audits performed using automatic
automatically configuration update software
Number of errors found in the CMS as a result of
Number of CMS Errors
an audit


Development Work Order
A Work Order for the development or customization of an
application or system, typically issued from Release
Management.

Installation Work Order
A Work Order for the installation of an application, system
or infrastructure component, typically issued from
Release Management.

Release Policy
A set of rules for deploying releases into the live
operational environment, defining different approaches
for releases depending on their urgency and impact.


Release
A Release (also referred to as a Release Package) consists
of a single Release Unit or a structured set of Release
Units.

Release Record
A Release Record contains all details of a Release,
documenting the history of the Release from the first
planning stages to closure.

Release Unit
A Release Unit is a set of new, changed and/or unchanged
Configuration Items, which are tested and introduced
into the live environment together to implement one or
several approved Changes.


Post Implementation Reviews

ITIL KPIs Release and Deployment Management

Key Performance
Definition
Indicator (KPI)
Number of releases rolled out into the
Number of Releases productive environment, grouped into Major and
Minor Releases
Duration of Major Average duration of major deployments from
Deployments clearance until completion
Number of Release
Number of releases which had to be reversed
Backouts
Proportion of automatic Proportion of new releases distributed
Release Distribution automatically


Planeamento da transição e de apoio: o planeamento e
coordenação necessárias para uma correta introdução da
funcionalidade especificada no projeto.

Nesta fase define-se a estratégia de transição, prepara-se a
transição de serviços, desenvolve-se o plano de transição
de serviços e de suporte às partes interessadas.


Project Initiation
To define stakeholders, responsibilities and resources available to the project,
as well as documenting risks, constraints and assumptions affecting the
project.

Project Planning and Coordination
To make sure service transitions projects are planned in accordance with the
organization's Project Management guidelines, and to coordinate activities
and resources across projects. This process is not responsible for detailed
planning of project phases but triggers planning activities performed by
other processes.

Project Control
To monitor project progress and resource consumption, to expedite progress
when required and to initiate corrective action if required.

Project Reporting and Communication
To provide an overall summary of all planned or ongoing Service Transition
projects as an information for customers and other Service Management
processes.

ITIL KPIs Project Management (Transition Planning and Support)

Key Performance
Definition
Indicator (KPI)
Number of major release rollouts under the
Number of Projects
control of Project Management

Percentage of Projects Percentage of projects which are started with
with Project Charters a signed Project Charter in place

Number of Changes to Number of changes to the Project Charter
Project Charter after project start
Adherence to Project Actual vs. planned consumption of financial
Budget and personnel resources

Project Delays Actual vs. planned project completion dates


Serviço de validação e testes

São processos responsáveis p ela criação e execução de
planos de teste que validar se os requisitos foram
cumpridos.

Isso inclui o a confirmação dos níveis de serviço que vão ser
disponibilizados, de forma a garantir os níveis adequados
de disponibilidade, capacidade, segurança e
continuidade (também referidos como "garantia ").

ITIL KPIs Service Validation and Testing

Key Performance
Definition
Indicator (KPI)
Percentage of failed
Percentage of release components which fail to
Release Component
pass acceptance tests
Acceptance Tests
Number of identified •Number of identified errors during release
Errors testing per release
Time until re-submission of fixed release
Time for Error Fixing
components
Incidents caused by New Number of Incidents attributable to new
Releases releases

Percentage of failed Percentage of Service Acceptance Tests which
Service Acceptance Tests fail to obtain the customer’s sign-off


Avaliação

Este processo pode ser usado genericamente de forma
independente para verificar se um processo atende aos
requisitos definidos.
Essencialmente, o processo cria um plano de teste e avalia
formalmente os resultados previstos e os resultados
reais.
A saída é, então, analisada com as partes interessadas que
deverão tomar decisões de gestão adequadas.

A validação e testes garantem que o resultado está de
acordo com o planeado.

A Avaliação garante que o resultado está de acordo com as
necessidades do negócio.


Complaints Management
Process Objective: To assess customer complaints and to
instigate corrective action if required.

Customer Satisfaction Survey
Process Objective: To plan, carry out and evaluate regular
customer satisfaction surveys. The principal aim of this
process is to learn about areas where customer
expectations are not being met before customers are lost
to alternative service providers.

Service Review
Process Objective: To review business services and
infrastructure services on a regular basis. The aim of this
process is to improve service quality where necessary,
and to identify more economical ways of providing a
service where possible.


Service Transition

Transição de Serviço irá garantir a qualidade dos serviços
prestados aos clientes e partes interessadas. Irá garantir
que requisitos funcionais, técnicos e de desempenho são
cumpridos (definidos durante a fase de Desenho de
Serviço).

Os OUTPUTS do Service Transition servirão de entrada à fase
de Operação de Serviço.


Próximo capítulo

Service Operation

ITIL V3 – Service Operation

• Foco na entrega dos serviços de acordo com as estratégias
definidas

• Processos
– Event Management
– Incident Management
– Problem Management
– Request Fulfillment
– Access Management

• Funções
– Service Desk
– Technical Management
– IT Operations Management
– Application Management

Service Operation

Serviço de Operação (SO) tem como objetivo proporcionar melhores práticas para
alcançar os níveis acordados de entrega de serviços, tanto para os utilizadores finais
como os clientes ("clientes" refere-se aos indivíduos/empresas que pagam pelo serviço e
negoceiam os SLAs ). Operação do serviço, é a componente do ciclo de vida onde os

serviços e o valor são realmente entregues. As funções operacionais incluem a
gestão técnica, gestão aplicacional, gestão de operações e logistica, atendimento e
resolução de problemas, bem como as responsabilidades de coordenação com as
restantes processos do ITIL. Processos do SO (Service Operation)
1. Gestão de Incidentes
2. Gestão de Problemas
3. Gestão de Eventos
4. Gestão de Pedidos
5. Gestão de Acessos
6. Gestão Operações

Service Operation


Objetivo processo: Gerir o ciclo de vida de todos os
incidentes. O objetivo principal da Gestão de
Incidentes é devolver aos utilizadores o serviço de
TI o mais rapidamente possível.


Urgência


Impacto


Urgência vs Impacto


A Gestão de Incidentes deve corrigir o serviço em
questão o mais rápido possível sem o problema que
se estenda para outras áreas da organização ou do
negócio. O down-time de um serviço de IT pode
condicionar a atividade da organização e fazer com
que o haja perdas económicas. A equipa de Gestão
de Incidentes deve estar sempre pronta a intervir (a
qualquer hora, a qualquer momento, em qualquer
lugar).

Exemplo: Problema de impressão



Quando um funcionário comunica uma situação de
impossibilidade de impressão, pode haver várias razões
pelas quais ele é incapaz de imprimir. O pessoal de serviço
tem de fazer as perguntas certas para perceber e prioritizar
o incidente. Aqui estão algumas possibilidades.

• A Impressora para onde pretende imprimir está configurada
na sua máquina? (ou, já alguma vez conseguiu imprimir para
essa impressora)
• Qual é o nome da impressora?
• Existe alguma mensagem de erro ou aviso na impressora
(ex. Toner vazio)
• A impressora tem papel?
• Existe algum atolamento de papel, dentro da impressora



Após as questões gerais relativas ao incidente, devem ser
registadas as questões relativas ao detalhe:

• Detalhe do requisitante
• Localização exata
• Identificação do ponto de rede
• Identificação do PC (eventual. Hardware e software
instalado)



Toda a informação é registada e o pessoal de apoio técnico deve
responder ao requisitante com soluções alternativas para
imprimir:

• Direcionar o pedido de impressão para outra impressora que
esteja devidamente funcional
• Reconfigurar ou Re-Instalar Drivers de Impressão no PC
• Configurar corretamente a impressora
• Reparar ou substituir a impressora


An Incident Record typically contains the following
information:

Unique ID of the Incident (usually allocated automatically
by the system)
Date and time of recording
Service Desk agent responsible for the registration
Method of notification
Caller/ user data
Callback method
Description of symptoms
Affected users/ business areas
Affected service(s)


information:

Prioritization, a function of the following components:
Urgency (available time until the resolution of the
Incident), e.g.
Up to 0.5 hrs
Up to 2.0 hrs
Up to 6.0 hrs
Impact (damage caused or potential damage to the
business), e.g.
"High" (interruption to critical business processes)
"Normal" (interruption to the work of individual
employees)
"Low" (hindrance to the work of individual
employees, continuation of work possible by means of a
circumventive solution)


information:

Priority (for example in stages 1, 2 and 3): The result
from the combination of urgency and impact
Major Incident flag (to indicate that the Incident is
treated as a Major Incident)
Relationships to CIs
Product category, usually selected from a category-tree
according to the following example:
Client PC
Standard configuration 1
...
Printer
Manufacturer 1
...


information:

Incident category, usually selected from a category-tree
Hardware error
Server A
Server B
...
Software error
System A
System B
...
Links to related Incident Records (if a similar outstanding
Incident exists, to which the new Incident is able to be
attributed)


information:

Links to related Problem Records (if any outstanding
Problems exist, to which the new Incident is able to
be attributed)
Activity log/ resolution history
Date and time
Person in charge
Description of activities
New Incident status (if the activity results in a change
of status)


information:

Closure data
Closure categories (if required, revised product
and Incident categorizations)
Problems raised (if the Incident is likely to recur
and preventive action is necessary)
Resolution type (elimination of the root cause vs.
application of a Workaround; if the Incident was
resolved by applying a Workaround: indication of
applied Workaround)
Customer feedback (is the Incident resolved from
the customer’s/ user’s point of view?)


Um incidente é um evento que não faz parte da
normal operação das TIs.

Um incidente interrompe ou reduz a qualidade do
serviço de TI.

Incident Management concentrates on restoring the
service to users as quickly as possible, in order to
minimize business impact.


Um problema é a causa desconhecida de um ou mais
incidentes

Objetivo processo: Os principais objetivos deste
processo é evitar incidentes e minimizar o impacto
dos mesmos. De forma pró-ativa analisa registos de
incidentes, e utiliza os dados recolhidos por outros
processos de IT Service Management para identificar
tendências ou problemas que possam acontecer.

Metas e Objetivos

• Prevenir problemas e incidentes resultantes
• Eliminar incidentes recorrentes
• Minimizar o impacto dos incidentes que não podem
ser impedidos


Um problema é uma condição, muitas vezes
identificado como um resultado de vários incidentes
que exibem sintomas comuns.

Problemas também podem ser identificados a partir de
um único incidente significativo, indicativo de um
único erro, cuja causa é desconhecida, mas para o
qual o impacto é significativo.

Known Error
Um erro conhecido é uma condição identificada por um
diagnóstico que identificou claramente a causa de
um problema. Um erro conhecido deve ter o
subsequente desenvolvimento de uma solução
alternativa e de um Change Request.


O processo de gestão de problema destina-se a reduzir
o número e a gravidade dos incidentes e deve
elaborar a documentação necessária para que as
primeiras e segundas linhas do helpdesk possam
ajudar a ultrapassar as situações de interrupção de
serviço.

O processo de Gestão de Problemas deve pautar pela
pró-atividade, se possível identificando e resolvendo
os problemas antes que os incidentes sejam
detetados. Tais processos incluem:

• Análise de tendências;
• Segmentação e ações de apoio mais direcionadas;
• Fornecimento de informações para a organização
(ex. necessidade de investimentos)



Neste caso, dois utilizadores queixam-se dos mesmos
sintomas (impossibilidade de impressão). Quando o
segundo incidente é comunicado, e havendo
correspondência semelhante entre os incidentes
individuais, podemos apontar para um ponto único
de falha (SPOF). Isso já pode ser classificado como
um problema, uma vez que pode afetar
adversamente a atividade de um grupo de
funcionários.
A equipe de suporte deve resolver a situação para
restaurar a Qualidade de Serviço (QoS).
Concluindo que há um mau funcionamento da
impressora e que esse problema está a causar os
incidentes, a impressora deve ser substituída (ou
reparada, dentro dos prazos do SLA)


Ex. Árvore de Decisão – Prioridade Problema


Gestão de Problemas é semelhante à Gestão de
Incidentes, uma vez que permite à organização ou
empresa descobrir qual é o problema e
restabelecer o serviço em questão o mais rápido
possível. No entanto, Gestão de Problemas é
pensado para soluções mais definitivas e constantes
do que a Gestão de Incidentes.
Gestão de Incidentes – colocar o serviço a funcionar
novamente, o mais rapidamente possível

Gestão de Problemas - descobrir exatamente o que
provocou os incidentes e como evitar que esse
problema nunca mais volte a acontecer.

Ambos devem ser usados para garantir que o seu
serviço está a ser executado e fornecido
corretamente.


A Problem Record typically contains the following
information:

Unique ID of the Problem (usually allocated automatically
by the system)
Date and time of detection
Problem owner
Description of symptoms
Affected users/ business areas
Affected service(s)
Prioritization, a function of the following components:
Urgency (available time until the resolution of the
Problem), e.g.
Up to 5 working days
Up to 2 weeks
Up to 4 weeks


information:

Degree of severity (damage caused to the business), e.g.
"High" (interruption to critical business processes)
"Normal" (interruption to the work of individual
employees)
"Low" (hindrance to the work of individual
employees, continuation of work possible by means of a
circumventive solution)
Priority (for example in stages 1, 2 and 3): The result
from the combination of urgency and the degree of
severity
Relationships to CIs


information:

Product category, usually selected from a category-tree
Client PC
Standard configuration 1
...
Printer
Manufacturer 1
...
Problem category, usually selected from a category-tree
Hardware error
Software error
...


information:

Links to related Problem Records (if there are other
outstanding Problems related to this one)
Links to related Incident Records (if outstanding Incidents
exist, whose solution depends on the solution of this
Problem)
Links to Known Errors and Workarounds (if Known Errors
and Workarounds related to the Problem have been
identified)
Activity log/ resolution history
Date and time
Person in charge
Description of activities
New Problem status (if the activity results in a change
of status)


“Problem Management involves root-cause analysis to
determine and resolve the cause of events and incidents,
proactive activities to detect and prevent future
problems/incidents and a Known Error sub-process to
allow quicker diagnosis and resolution if further incidents
do occur.”


Objetivo processo: Detetar eventos, dar-lhes sentido e
determinar a adequada ação de controle. Gestão de
eventos é, portanto, uma base de Acompanhamento
e Controle Operacional.

Um evento pode ser definido como qualquer ocorrência
detetável ou percetível que tem importância para a
gestão da infraestrutura de TI ou para a entrega do
Serviço de TI.
A avaliação do impacto de um evento é fundamental
para perceber o desvio que pode causar aos
serviços.


Uma eficaz Operação de Serviço precisa de conhecer o
estado da infraestrutura e detetar qualquer desvio
da operação, face ao normal ou ao esperado.
Esta monitorização de estado pode ser baseado em dois
tipos de ferramentas:

• Ferramentas ativas de monitorização
Existe uma pro-atividade na verificação do estado dos
CIs mais importantes para determinar o seu estado
e disponibilidade. As exceções irão gerar alertas.

• Ferramentas de monitorização Passiva
que detetam e correlacionam alertas e eventos
operacionais ou comunicações geradas pelos CIs (ex.
notificações de S.O)


A Gestão de eventos é o ponto de entrada para a
execução de muitos processos e atividades de
operação.

Fornece formas de comparação do desempenho real e
do comportamento em relação aos padrões de
desenho de SLAs.

Gestão de eventos fornece também uma base para a
Garantia de Serviço e Relatórios de Melhoria de
Serviço (coberto em detalhes no CSI)


“Event Management is the process that monitors all
events that occur through the IT Infrastructure to
allow for normal operation and also to detect and
escalate exception conditions.”


Objetivo processo: Para cumprir solicitações de serviços
(na maioria dos casos alterações menores -
standard)

O processo em si é bastante simples:
• fornecer ao cliente/utilizador um "menu de
serviços" que ele possa escolher, aplicando critérios
de qualificação (custos, prioridades, arquitetura,
etc.). Caso esses critérios resultem em "go", dar
seguimento à solicitação.

(exemplo: pedidos de alteração de passwords ou
pedidos de informação).


Incidente


Algumas vezes conhecido como Rights Management ou
Gestão de Identidades

Objetivos e Metas

Tem como principal objetivo garantir que os
utilizadores têm um nível de acesso às aplicações e
informação, adequado às suas necessidades.
Conceder aos utilizadores autorizados o direito de
utilizar um serviço, enquanto impedindo o acesso a
usuários não-autorizados.

Deve garantir a execução de políticas e ações definidas
no Serviço “Information Security Management” e
“Availability Management”


Access Management: Este é o processo de concessão de
direitos de utilização de um serviço, e restringindo
o acesso a utilizadores não-autorizados. Baseia-se
na capacidade de identificar com precisão os
utilizadores autorizados e gerir os acesso aos
serviços necessários durante as diferentes
fases/funções dos seus recursos humanos (RH).


Sub-processos e objetivos de processo:

Manutenção do Catálogo de Funções/ Perfil de Acesso
dos Utilizadores
Objetivo processo: Certificar-se que o catálogo de
funções/perfis de acesso de utilizadores está
apropriado para os serviços fornecidos.

Processamento de pedidos de acessos de utilizadores
Objetivo processo: Processar pedidos para adicionar,
alterar ou revogar direitos de acesso. Certificar que
só os utilizadores autorizados têm o direito de
utilizar um serviço.


Direitos de acesso
Pedido de Direitos de Acesso
Registro de Identidade do Utilizador
Pedido de identidade do Utilizador
Papel Utilizador
Perfil de acesso /Função
Papel Requisitos Utilizador


Identity Lifecycle Management


Unidade funcional com um conjunto de colaboradores
dedicados e responsáveis por lidar com uma
variedade de eventos de serviço, atuando como o
ponto único de contato para utilizadores de SIs e TIs


O service desk é uma das quatro funções ITIL e está
principalmente associada com a fase do ciclo de
vida Serviço de Operação. As tarefas incluem
manipulação de incidentes e solicitações, e fornecer
uma interface para outros processos ITSM. As
características incluem:

• único ponto de contato (SPOC) -não necessariamente o
primeiro ponto de contato (FPOC)
• único ponto de entrada
• único ponto de saída
• fácil para os clientes e utilizadores
• garantia de integridade dos dados
• canal de comunicação simplificada


Principais propósitos do Service Desk incluem:

• controle incidente: a gestão do ciclo de vida de todas as
solicitações de serviço
• comunicação: manter um cliente informado do progresso
e consultoria sobre soluções alternativas

A função de service desk pode ter vários nomes, tais como:

Call center : grandes volumes de chamadas telefónicas e
é baseado em fornecimento de informações e registo de
solicitações
Help desk : gerir, coordenar e resolver incidentes o mais
rápido possível no nível de suporte principal
Service desk: não apenas lida com os incidentes,
problemas e perguntas, mas também fornece uma
interface para as outras atividades.


Service Desk trata de:
pedidos de mudança, contratos de manutenção, licenças de
software, gestão de nível de serviço, gestão de
configuração, gestão de disponibilidade, gestão
financeira e gestão de continuidade de serviços

Service Desk pode ser (ao nível de estrutura)
Local: para atender às necessidades de empresas locais -
prática somente até vários locais que requerem serviços
de apoio estão envolvidas
Central: para organizações com vários locais - reduz os
custos operacionais e melhora a utilização dos recursos
disponíveis
Virtual: para entidades multinacionais onde o atendimento
poder ser feito em qualquer lugar do mundo, através de
tecnologias de comunicação globais


Gestão de Aplicações será responsável por gerir as
aplicações em todo o seu ciclo de vida.


Requisitos

Trabalhar com as unidades de negócio para identificar
os requisitos do processo funcional e de negócio
para a alteração ou desenvolvimento de nova
aplicação.

Durante este processo, serão identificado os requisitos
iniciais do nível de serviço.


Projeto/Design

A equipe de análise traduz os requisitos para uma
solução técnica. Neste ponto, é realizado um
business case de forma a calcular o Custo Total de
Propriedade (TCO)

Em muitos casos, decorre um processo de negociação
interno, onde os requisitos e níveis de serviço são
afinados, com o objetivo de ajustar os custos ao
nível que a empresa pode pagar.


Construir

Esta é fase de aplicação real de programação e testes
de processo.
Todos os componentes são desenvolvidos e testados
individualmente e sistemicamente para descobrir
eventuais falhas funcionais e processo. Assim que o
teste de qualidade final foi concluída, far-se-á o
sign-off para permitir a introdução no ambiente de
produção.


Implementar

Este sub-processo abrange a implementação da nova
aplicação.
Para além da inclusão da circulação de módulos em
produção, inclui-se também a formação necessária
para efetivamente usar as novas funcionalidades.


Operar

Esta etapa do processo cobre o dia-a-dia "cuidados e
gestão" da nova aplicação. Mudanças em requisitos
regulatórios ou legislativos seriam abordados nesta
etapa. Se os utilizadores finais descobrirem falhas
na aplicação, eles são abordados nesta etapa.

Os níveis de serviço são monitorados e o desempenho
da aplicação é avaliado e documentado.

O objetivo deste subprocesso é minimizar os impactos
sobre o negócio de questões relacionadas com a
utilização normal da aplicação.


Otimizar

Este é o último passo no ciclo de Gestão de Aplicações.
A otimização de desempenho técnico e funcional
são abordados nesta etapa. As equipas de gestão de
desempenho analisam os relatórios e a informação
existente para identificar eventuais oportunidades
de melhoria de desempenho.

ITIL V3

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (12)

Similaire à ITIL V3

Similaire à ITIL V3 (20)

Dernier

Dernier (8)

ITIL V3