Cópia de Curso Itil Slmsla Vit0405-New

ITIL – SLM & SLA:
GESTÃO DE SERVIÇOS DE
TI GARANTINDO
RESULTADOS
LUIZ AUGUSTO DE ANGELO MUSA – 011-9980 8946

ITIL – SLM & SLA: GESTÃO DE SERVIÇOS
Luiz Augusto de Angelo Musa
 Consultor da FGVSP - GVconsult em Gestão e Uso Estratégico de

TI; Governança em ICT; Gestão de Serviços de TI e Gestão de
Ativos de TI;
 Há mais de 30 anos atuando no uso Estratégico de TI em empresas

como IBM BRASIL, RCG, BOUCINHAS, CSC BRASIL / REMEDY,
GARTNER GROUP; MRO SOFTWARE
 Participa na Vice Presidência de TELECOM da SUCESU-SP, como

Diretor GU – Gestão de Serviços em Telecom, coordenando
Palestras, Congressos e Cursos, desde 1993.
2 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

POSICIONAMENTO ESTRATÉGICO
Metodologias - Padrões de Mercado
ITIL
COBIT CMMi
BSC GESTÃO COSO
6SIGMA SAC
GAO
GAO

CobiT (ISACA)
A ISACA(Information Systems Audit and
Control Association) tem como proposta a
metodologia denominada CobiT (Control
objectives for information and related
Technology) que foi desenvolvida em 1996 e
com revisões posteriores, sendo destinada a
Auditores, Administradores de ICT e até a
usuários de sistemas informatizados, que
tenham como objetivo a efetividade e a
eficácia do controle de operações, a
confidencialidade e integridade das
informações e o fiel cumprimento dos
regulamentos e leis. É estruturada em um
framework e dá suporte a Governança de ICT.
Está baseada em quatro domínios e 34
Controles principais resultando em 302
controles secundários.
CobiT - continuação
 CobiT
 O que é: Um conjunto de diretrizes baseadas em auditoria para
processos, práticas e controles de ICT. Voltado para redução de
risco, enfoca integridade, confiabilidade e segurança. Aborda
quatro domínios: planejamento e organização, aquisição e
implementação, entrega, suporte e monitoração. Apresenta
seis níveis de maturidade, similares aos de CMM.
 Pontos fortes: Permite que ICT aborde riscos não endereçados
explicitamente por outros modelos e que seja aprovada em
auditorias. Funciona bem com outros modelos de qualidade,
principalmente ITIL.
 Limitações: Diz o que fazer, mas não como fazer. Não lida
diretamente com desenvolvimento de software ou serviços de
ICT. Não fornece um "road map" para aprimoramento contínuo
de processos.

BSC (Balance Score Card)

 Sistema de Comunicação,
Controle e Aprendizagem
estratégica, desenvolvido
pelos Profs. Kaplan e
Norton.
 O BSC é uma forma

integrada balanceada e
estratégica de medir os
processos atuais e mostrar
uma direção de futuro
convertendo Visão em Ação
por meio de quatro
perspectivas através das
quais podemos enxergar o
negocio.

BSC - continuação
 O que é: BSC(Balanced Scorecard) é uma sigla que, traduzida, significa
Indicadores Balanceados de Desempenho. Este é o nome de uma
metodologia voltada à gestão estratégica de empresas que foi criado pelos
professores da Harward Business School Robert Kaplan e David Norton,
divulgando suas idéias com a publicação de um artigo na Harward Business
Review em 1992. Hoje este conceito é consolidado, com muitas publicações
sobre o assunto e com o modelo em funcionamento pelo mundo.
 Pontos fortes: Balanced Scorecard é uma abordagem que permite a
operacionalização da estratégia, facilitando a comunicação e a compreensão
dos objetivos estratégicos aos vários níveis organizacionais. Através do
Balanced Scorecard a direção das empresas dispõe de uma visão integrada
do negócio e de um processo contínuo de monitoramento do desempenho.
Integra-se com facilidade a outras metodologias como CobiT e ITIL.
 Limitações: Não é uma metodologia de fácil entendimento e aplicação.
Seus conceitos podem ser aplicados de várias formas como parte de outras
metodologias. É bastante vaga quanto a controles para processos de ICT.

CMMi (Capability Maturity Model

Integration)
 O CMMI, padrão do
Software Engineering
Institute, é um modelo de
maturidade de processo
mais abrangente, que
combina CMM for software
com disciplinas mais
amplas nas áreas de
engenharia de sistemas e
desenvolvimento de
produtos. Futuramente, o
instituto vai parar de
suportar CMM para
software a favor do CMMI.
 O CMMI estende e combina
o capability maturity model
for software (SW-CMM), o
systems engineering
capability model e o
integrated product
development capability
maturity model.

CMMi - continuação
 Capability Maturity Model Integration (CMMI)
 Responsável: Software Engineering Institute, Carnegie Mellon
University
 O que é: SW-CMM é uma coleção de melhores práticas para
desenvolvimento e manutenção de software. Permite que as
empresas avaliem suas práticas e as comparem com as de outras
empresas. SW-CMM mede a maturidade do processo, que
progride em cinco níveis: 1 (inicial), 2 (gerenciado), 3 (definido), 4
(previsível) e 5 (otimização).
 Pontos fortes: Muito detalhado. Criado especificamente para
organizações de desenvolvimento de software. Enfoca o
aprimoramento contínuo, e não apenas a manutenção de uma
certificação. Pode ser usado para auto-avaliação.
 Limitações: Não aborda aspectos de operações de ICT como
gerenciamento de segurança, mudança e configuração,
planejamento de capacidade, diagnóstico e funções de help desk.
Estabelece metas, mas não diz como atingi-las.

GAO
GAO - General Accounting Office - USA
GAO é um organismo do
governo federal Norte
Americano que estabelece
padrões de controles internos
para atuação de profissionais
de Auditoria e Controler, e
suas publicações vem sendo
usadas como referencial para
aplicações práticas em muitas
organizações no mundo todo.

GAO (continuação)
 GAO - General Accounting Office
 Responsável: Governo Federal Norte Americano.
 O que é: O GAO apresenta publicações com recomendações de
melhores práticas para a produção de controles internos na área de ICT
que possam ser auditáveis através de seus processos. A visão
apresentada é ampla e cobre o planejamento estratégico, as
interferências do Negócio com as adequações práticas da área de ICT.
 Pontos fortes: Bastante detalhado e abrangente, conduz a produção
de controles internos inclusive com abordagem do ciclo de maturidade,
da valorização financeira e das aplicações em uso.
 Limitações: Como guia prático para auditores, não especifica como
implementar os controles, bem como não estabelece um framework que
possa ser implementado com facilidade. Muito específico para o
mercado norte americano.

Seis Sigma
 É um método desenvolvido pela

Motorola, de aprimoramento de
processo estatístico que enfoca a
qualidade do ponto de vista do cliente
ou do usuário. Define níveis de serviço e
mede variações em relação a estes
níveis. Os projetos percorrem cinco
fases: definir, medir, analisar, aprimorar
e controlar. A variante Design for Six
Sigma aplica os princípios deste método
à criação de produtos ou serviços sem
defeitos, e não ao aprimoramento dos
que já existem.

Seis Sigma - continuação

 Seis Sigma
 O que é: Um método de aprimoramento de processo estatístico

que enfoca a qualidade do ponto de vista do cliente ou do usuário.
Define níveis de serviço e mede variações em relação a estes
níveis. Voltado para processos de produção, também pode ser
adaptado para a gestão de processos de ICT.
 Pontos fortes: Uma abordagem orientada a dados para descobrir
a raiz de problemas de negócio e resolvê-los. Leva em conta os
custos e qualidade. Em ICT, é melhor aplicado em atividades
passíveis de repetição e relativamente homogêneas, como
operações de call center ou help desk. Design for Six Sigma pode
ajudar a desenvolver boas especificações de software.
 Limitações: Projetado originalmente para ambientes de
manufatura; pode ser difícil aplicá-lo em processos que ainda não
estão bem definidos e mensuráveis. Pode aprimorar o processo,
mas não diz se você tem o processo certo.

COSO
Internal Control - Integrated Framework
COSO- Committee of Sponsoring
Organizations of the Treadway
Guia de referencia publicado em 1992.
Sofreu diversas modificações, onde foram
estabelecidos critérios e recomendações
para gestão e como avaliar e implementar
sistemas de controles. Tem como objetivo
controlar efetividade e eficácia do
cumprimento das regras e regulamentações
sobre as informações financeiras de uma
organização. Estabelece bases para um
ambiente de controle que possibilita a
valorização dos riscos e a monitoração das
atividades de controle sobre as informações
e comunicações.
COSO - continuação
 O que é: COSO é o nome dado a metodologia do Comitê das Organizações
Patrocinadoras – USA, uma entidade, sem fins lucrativos, dedicada à melhoria dos
relatórios financeiros através da ética, efetividade dos controles internos e governança
corporativa.
Os patrocinadores são as principais associações de classe de profissionais ligados à área
financeira nos Estados Unidos: AICPA - Instituto Americano de Contadores Públicos
Certificados; AAA - Associação Americana de Contadores; FEI - Executivos Financeiros
Internacional; IIA - Instituto dos Auditores Internos dos EUA e o IMA - Instituto dos
Contadores Gerenciais.
 Pontos fortes: Na Metodologia COSO o controle interno é um processo
constituído de cinco elementos essenciais, denominados Ambiente de Controle, Avaliação
e Gerenciamento dos Riscos, Atividades de Controle, Informação e Comunicação e
Monitoramento, que se inter-relacionam. O controle interno, nessa visão, é um processo
desenvolvido para garantir, com razoável certeza, os objetivos da empresa, nas seguintes
categorias: eficiência e efetividade operacional, confiança nos registros
contábeis/financeiros e conformidade com leis e normas aplicáveis à entidade e sua área
de atuação. Muito usada no Brasil pelo setor financeiro.
 Limitações:Baixa aplicabilidade para Governança de ICT pois não prove controles
para as necessidades dessa área. Pode ser integrado com outras metodologias.

SAC (Systems Assurance and Control)
O Institute of Internal
Auditors Research
Foundation's criou o
SAC em 1977 e o
mantem atualizado.
O SAC é um Guia de
padrões e controles
para Auditores de
Sistemas de Informação
e tecnologia. Possui o
objetivo de controlar
com efetividade e
eficácia os processos, a
integridade das
informações financeiras
e o cumprimento de
Normas e regulamentos
do ambiente sobre
controle, seja de forma
manual ou
automatizada. O atual
modelo é denominado e-
SAC.

SAC - continuação
O que é: A metodologia SAC (Systems Auditability and Control)
do Institute of Internal Auditors foi publicada inicialmente
em 1977 pelo IIA e atualizada em 1991 e 1994 pelo IIA
Research Foundation. Atualmente o modelo evoluiu e é
denominado e- SAC (eletronic - Systems Auditability and
Control) e é fundamentado na linguagem e procedimentos
da metodologia COSO e estende controles e pontos de
auditagem com abrangência para o e-commerce.
Pontos fortes: É um modelo maduro e ampliado cobrindo a
maioria das necessidades empresarias e encontra-se muito
atualizado. Possui fácil integração com outras metodologias,
com CobiT, BSC, ITIL...
Limitações: Possui um foco voltado especialmente para auditoria,
especifica conceitos mas não orienta como implementá-los.

Cobit & ITIL

Conclusions
 Usar o COBIT para avaliação do situação atual do ambiente identificando processos e controles
insuficientes
 Utilizar o ITIL para implementar controles e processos de TI
 Utilizar ITIL para determinar tecnologia
 Utilizar Cobit para definir as métricas
 Pesquisar no ITIL as possíveis estruturas

Posicionamento ITIL POSICIONAMENTO ESTRATÉGICO
 sasas

ALINHANDO ICT AO NEGÓCIO
R
U R
VISÃO DO P A VISÃO DE
T C
NEGÓCIO U H TI
R A
A D
U
PESSOAS PROCESSOS
S PRODUTOS
R
A
GOVERNANÇA S GOVERNANÇA
CORPORATIVA DE TI
FRAMEWORK DE METODOLOGIAS

ITSM – IT Service Management

Gerenciamento Global dos Serviços de Tecnologia da Informação,
inspirado e direcionado pelas disciplinas de ITIL
ITIL – IT infrastruture Library by UK Agency OCG –

Office of Government Commerce
Estudo e Publicações de um Conjunto de Disciplinas que devem se
utilizar de Produtos, Serviços e Aplicações de Tecnologia da
Informação, para constituir modelos de Gerenciamento dos Recursos
de infra-estrutura de ICT, na exata perspectiva dinâmica do negócio
da corporação, com total segurança.

Áreas Chave dos Processos de ITSM
Service Support
Service Delivery
Adequado a cada Organização segundo:

O Negócio
A Cultura
A Estrutura
O Ambiente
Os Processos
A Filosofia ITSM contempla 3 principais objetivos:
Alinhar IT Services com as necessidades correntes e

futuras do negócio na corporação
Alavancar e Garantir a Qualidade dos Serviços

Entregues
Reduzir a Provisão de Custos de longo prazo dos

Serviços
Máxima de ITSM – reduzir consistente e oportunamente o TCO – Total
Cost of Ownership (Custo Total de Propriedade) com o uso eficiente e
efetivo dos 3 Ps = Pessoas, Processos e Produtos ( ferramentas e
tecnologia).

ITSM = Processos que usem as Pessoas e Produtos efetivamente,

gerando entregas eficientes de forma econômica e dinâmica, de alta
qualidade inovativa, alinhadas aos Processos do Negócio.
ITSM e as Melhores Práticas
Definí-los
OGC PADRÕES
Admití-los e
Adotá-los
e CÓDIGOS DE Gerenciamento
PRÁTICAS Geral
BSI = British ITIL Definições de
Standards Processos
Institutions PROCEDIMENTOS E Solução
PROCESSOS INTERNOS Disponibilizada
Importância dos processos

Considerando que:
-Processos de Negócio criam novos produtos e serviços
que irão satisfazer clientes e criam lucros para os
acionistas
-Empresas podem rastrear os resultados de seus
processos-chave
-Processos-chave impactam diretamente no resultado
( lucro ou perda )
Processo é Onde Se Faz Dinheiro.

Qual o valor do meu processo ?

ITIL – DUAS ÁREAS FUNDAMENTAIS

SERVICE SUPPORT SERVICE DELIVERY
Service Desk *
Ger. De Incidentes ** G. De Níveis de Serviços
Ger. De Problemas G. Financeiro para

Serviços de TI
Ger. De Configuração G. De Capacidade
Ger. De Mudanças G. De Continuidade de

Serviços de TI
Ger. De Liberações *** G. De Disponibilidade
*Service Desk – função e não processo

** incidente – eventual ou não; problema - contínuo e constante
*** sentido abrangente
Algumas características do ITIL:

•Adequado para todas as áreas;
•Independente de tecnologia e fornecedor;
•Baseado nas melhores práticas;
•Padronização de terminologias;
•Interdependência de processos;
•O que fazer e o que não fazer.
Vantagens de trabalhar orientado a processos:

•Faz com que as melhorias de qualidade possam ser medidas;
•Torna os processos de gerenciamento dos serviços de TI
mensuráveis;
•Fornece uma forma consistente de trabalho;
•Fornece uma terminologia padronizada;
•Aperfeiçoa os processos, inclusive de comunicação;
•Aumenta a satisfação do cliente ajustando corretamente suas
expectativas;
•Auxilia na obtenção da certificação ISO 9000.
Como utilizar o ITIL?
• É o ponto de partida, não o objetivo

• São recomendações, não Regulamentações
• Seus usuários “adotam e adaptam” suas melhores
práticas
• São genéricas e independentes de plataforma
• São a fundação para um ambiente de TI mais
profissional e previsível
• Não utilize em crises !! Para resolver crises utilize
pessoas, forças tarefas etc

Fatores de Sucesso
Fatores de Sucesso:
1 ) Papel e responsabilidade definidos
2 ) Mapeamento dos pontos mais críticos
3 ) Divisão por etapas do processo
Riscos
Descrédito na Metodologia

Dependência do Sucesso
Os Três P´s
A organização da TI pode ser conseguida através da melhor utilização e
desempenho de: Pessoas, Processos e Produtos
Pessoas:
- Todos os envolvidos, ou seja Clientes, Equipe e Usuários
- Comunicação, Treinamento e papéis e responsabilidades
Processos:
Suporte a Serviços Entrega de Serviços
Gerenciamento de Incidentes Gerenciamento de SLA
Gerenciamento de Problemas Gerenciamento Financeira
Gerenciamento de Configuração Gerenciamento de Capacidade
Gerenciamento de Mudanças Gerenciamento de Disponibilidade
Gerenciamento de Liberações Gerenciamento de Continuidade
Ferramentas e Produtos desenvolvidos para suportar esta Metodologia

Gerência de Liberações Gerência de Disponibilidade
MODELO DE INCREMENTO NOS PROCESSOS
O que queremos ser? VISÃO DOS

OBJETIVOS DE
NEGÓCIO
O que somos agora? INFORMAÇÕES
Como chegaremos lá? INCREMENTO E RE-

ENGENHARIA DE
PROCESSOS
Como conhecer o que MÉTRICAS E MEDIDAS
acontece?

PEN X PET

PEN X PET

CONCEITOS DE S. SUPPORT E S. DELIVERY
PUBLICAÇÕES DE ITIL
T T
PLANING TO IMPLEMENT SERVICE MANAGEMENT
H
H
E
E
SERVICE MANEGEMENT
T
B THE
SERVICE SUPPORT
ICT
E
U BUSINESS INFRASTRUCTURE
C
PERSPECTIVE MANAGEMENT
S H
SECURITY
I SERVICE DELIVERYMANAGEMENT
N
N O
L
E
O
S G
APPLICATIONS MANAGEMENT
S Y
Fonte OGC

CONCEITOS DE S. SUPPORT E S. DELIVERY
Disciplinas
Suporte a Serviços (Service Support)
Concentra-se na execução do dia-a-dia e no suporte a serviços em TI
Service Desk
1. Gerenciamento de Configuração
2. Gerenciamento de Incidentes
3. Gerenciamento de Problemas
4. Gerenciamento de Mudanças
5. Gerenciamento de Liberações
Entrega de Serviços (Service Delivery)

Concentra-se no planejamento e melhoria dos serviços
6. Gerenciamento Financeiro para Serviços de TI
7. Gerenciamento da Continuidade dos Serviços de TI
8. Gerenciamento da Disponibilidade
9. Gerenciamento da Capacidade
10. Gerenciamento do Nível de Serviço

Gerenciamento
do
1
Relacionamento Gerenciamento da Capacidade
Compreender o negócio, a operação da
com o Cliente organização e a infra de TI, garantindo que
todos as necessidades de capacidade e
performance atuais e futuros do negócio
sejam fornecidas com efetividade de
Gerenciamento do Nível de Serviço custos.
Gerenciamento da Continuidade
Suportar todo o processo de gerenciamento
Manter e melhorar gradualmente a
qualidade do Serviço de TI através de da Continuidade do Negócio, garantindo a
constantes acordos, controles, produção recuperação dos instrumentos técnicos e de
de relatórios e revisão de níveis Serviços de TI dentro dos prazos acordados. 2
alcançados pelos Serviços de TI.
Gerenciamento da Disponibilidade
Otimizar a capacidade da infra de TI, apoiar a
organização na entrega de nível de disponi-
Gerenciamento Financeiro bilidade sustentada, num custo aceitável
Proporcionar uma administração correta dos satisfazendo as necessidades de negócio
ativos de TI e dos recursos financeiros
usados na prestação dos Serviços de TI Gerenciamento da Segurança
Garantir uso de métodos e procedimentos padrão,
tratamento eficiente e imediato de todas as questões
Entrega de Serviços de segurança, identificando e cumprindo qualquer
privilégio de acesso seguro da organização
Suporte a Serviços
Gerenciamento de Problemas
Gerenciamento de Liberações
Garantir que todos os aspectos de uma Minimizar o impacto adverso de
liberação, técnicos e não técnicos, sejam Incidentes e Problemas no negócio,
considerados em conjunto, através de uma causados por erros na infra-estrutura e
visão holística de uma Mudança em um evitar, de forma proativa a ocorrência de
Serviço de TI. Incidentes, problemas e erros.
1 Gerenciamento de Mudanças
Assegurar que sejam utilizados métodos e Gerenciamento de Incidentes
procedimentos padronizados para um Restabelecer a operação normal o mais
tratamento eficiente e rápido de todas as rapidamente possível com o mínimo de
mudanças. interrupção do negócio, assegurando que os
melhores níveis de disponibilidade e serviço
Gerenciamento da Configuração pretendidos sejam mantidos
Fornecer um modelo lógico da infra-estrutura
de TI através de identificação, controle,
manutenção e verificação das versões de
todos os itens de configuração existentes.
2
Central de
Serviços

Fluxo simplificado – Gerenciamento de Serviços de T

Service Desk Usuário Produção Cliente
5 Gerenciamento Liberações
2 Gerenciamento Incidentes Planejar, Implementar e Controlar
Registro, classificação, suporte inicial, liberação de novas versões Soft/Hard
investigação e diagnóstico, resolução
e recuperação, fechamento (Sistema de
Inventário)
(Sistema de Chamado)
1 Gerenciamento Configuração
Controle rígido sobre os bens (Itens de
Configuração)
(Sistema de
Encerra Inventário)
N 4 Gerenciamento Mudança 5 Gerenciamento Nível de

Gerou N Necessário Avaliar impacto e risco Serviço
S Gerenciar relações com o cliente sobre
problemas? Intervenção? Autorizar mudança
S os acordos feitos e ajustes nos
serviços requisitados
(Sistema de Monitoração)
4 Gerenciamento Capacidade
Monitorar e medir a capacidade dos 1 Gerenciamento Financeiro
3 Gerenciamento Problemas recursos, performance dos serviços e
Identificação, registro, classificação, planejar capacidade (sincronizado ao Desenvolver as políticas de Previsão
designação de recursos, investigação negócio) Orçamentária, Contabilidade de TI e
e diagnóstico, estabelecimento do Erro Cobrança
Conhecido (Sistema de Monitoração)
3 Gerenciamento Disponibilidade 2 Gerenciamento Continuidade
Planejar IC´s alternativos (individuais
Monitorar níveis de disponibilidade ou instalação inteira - desaster
para garantir que os ANS´s sejam recovery)
atingidos (Testar Plano de Contingência)
Fluxo Simplif. Sup. a Serviços 5 Gerenciamento de Liberações

 Armazenamento, liberação,
Produção  Distribuição e
 Implementação de software
Service Desk
autorizado
Usuário  Possuir hardware disponível
(Sistema de
Inventário)
2 Gerenciamento de Incidentes
 Restabelecer a operação normal
do serviço o mais rápido possível 1 Gerenciamento de Configuração
 Escalação funcional ou hierárquica  Prover um modelo lógico da infra-
 Manter comunicação contínua com estrutura, ou de um serviço,
o cliente/usuário através...
...da identificação, controle,
Encerra manutenção e verificação...
 ...dos Itens de Configuração (IC´s)
existentes
N (Sistema de
Inventário)
Gerou N Necessário S
problemas? Intervenção? 4 Gerenciamento de Mudanças
S  Garantir eficiência na execução
das mudanças...
...de forma a evitar ou minimizar
impactos nos serviços prestados...
3 Gerenciamento de Problemas  ...e os riscos nos negócios
 Minimizar o impacto,
 Prevenir a recorrência, (Sistema de Monitoração)
 Encontrar a causa raiz dos
incidentes
 Iniciar as ações para melhorar ou
corrigir a situação

S. DELIVERY – VISÃO GERAL
Fluxo simplificado - Entrega de Serviços
Cliente
5 Gerenciamento do Nível de Serviço

 Manter e melhorar gradualmente a
qualidade do Serviço de TI, através
Gerenciamento de Mudanças de um ciclo constante de:
 acordos
 monitoração
 relatórios
4 Gerenciamento da Capacidade 1 Gerenciamento Financeiro

 Monitorar e medir:  Desenvolver as políticas de
 a capacidade dos recursos, Previsão Orçamentária,
 a performance dos serviços e  Contabilidade de TI e
 planejar capacidade  Cobrança
(sincronizado ao negócio)
2 Gerenciamento da Continuidade
3 Gerenciamento da Disponibilidade
 Monitorar os níveis de  Planejar IC´s alternativos
disponibilidade para garantir que os (individuais ou instalação inteira -
ANS´s sejam atingidos desaster recovery)
 Testar Plano de Contingência

Central de Serviços

Central de Serviços - Service Desk

Como atender as necessidades de TI sem um ponto único de Contato?
Com a rápida evolução do negócio e a alta

Dependência da Tecnologia, em função de
Necessidade de disponibilidade, exigência do
usuário e informações padronizadas, a falta
de um único ponto de contato, pode tornar
os serviços de TI impossíveis de oferecerem
um atendimento de qualidade e com o devido
controle

Central de Serviços - Service Desk

Objetivos
 Cadastro das solicitações requisitadas
 Propiciar um ponto único de contato para usuários e clientes
 Fornecer informações padronizadas aos usuários
 Escalar os incidentes de acordo com os níveis de serviços acordados
 Geração de relatórios
 Agregar valor para a organização
Responsabilidades
 Recepcionar, registrar, priorizar e acompanhar os chamados de serviços
 Monitorar e acompanhar a situação de todos os chamados registrados
 Escalar e encaminhar para outras áreas da organização
 Prover informações e recomendações para melhoria da qualidade do serviço
 Fechar incidentes e confirmar com o cliente
 Manter os clientes informados sobre a situação e andamento das suas requisições (Follow up)
 Coordenar os grupos de suporte de Segundo Nível e Terceiros
 Fechamento dos incidentes e confirmação com o Cliente

Tipos de Centrais
Central de Atendimento (Call Center)

Voltado para grande volumes de chamados e transações por telefone, neste caso esta Central não atua sobre
as transações e encaminha para a área devida área dentro da organização.
Central de Suporte (Help Desk)

O principal objetivo é que nenhuma requisição seja perdida ou não atendida, mesmo depois de cadastrada,
tem também como função resolver e coordenar incidentes, propiciando a interface ( ou comunicação ) entre a
Gerência de Configuração.
Central de Serviços (Service Desk)

A característica principal é a abrangência dos serviços, pois o processo de negócio neste caso, esta integrado,
não sendo somente resolvidos incidentes e sim problemas, dúvidas e interfaceando com as requsições de
mudanças.

Estruturas de Atendimento
Em geral as empresas preferem manter centrais de atendimentos locais, ou seja por

regiões; isso ocorre devido ao regionalismo, porém esta forma de atendimento gera um
custo maior e um alto grau de risco para padronizações.
Existem três possíveis formas de realizar este atendimento: Local, Centralizado e Virtual,
sendo que cada uma dela possui suas considerações.
Local Centralizada
 Processos comuns
 Utilizar o mesmo formato  Redução de custos com
de escalada equipamentos
 Utilizar métricas comuns  Visão global única

para relatórios gerenciais  Facilidade na
 Manter a equipe comunicação e padrões
equalizada com o mesmo
grau de informações
 Melhor aproveitamento
dos recursos
 Utilizar uma mesma base
de conhecimento
Ferramentas
O sucesso de uma Central de Serviços, esta associado a qualidade das ferramentas

utilizadas para esta finalidade.
Sistemas integrados com a metodologia e que possam disponibilizar dados estatísticos,
controles de SLA, acesso a base de conhecimento entre outras funcionalidades, permitem
que o ambiente possa fornecer dados com maior agilidade e garantias de qualidade da
informação.
Outros pontos importantes;
- Sistemas de telefonia avançados
- Ferramentas de apoio configuradas
- Base de conhecimento
- Integração entre ferramentas de Controle de SLA e monitoração
FERRAMENTAS INADEQUADAS PODEM PREJUDICAR O SUCESSO !!!

Service Desk Centralizado

Possibilita:
- Implantação de Modelo de Gestão Usuário
- Gerenciamento de níveis de serviços Final
- Melhoria na qualidade de atendimento Follow up
- Atender mais chamados
- Diminuição/Extinção de Back Log
- Aumentar SLA Service Desk
- Satisfação do Usuário Final Centralizado
- Coberturas em Férias/Absenteísmos Classificação e suporte inicial
- Redução de Custos
Nível 1 Aplicações
de Negócios
Redes Control Desk SO ERP ... outros
Grupos Solucionadores - Nivel 2

Sistema 1
Sistemas
Departamentai Notes
s
Rede
Outros Sistemas
ERP
Sistema 2
Windows
DataBase
Células Especializadas
Field Service ou Atendimento Remoto

Gerenciamento da Configuração

GERENCIAMENTO DA CONFIGURAÇÃO
Banco de Dados do Biblioteca de SW

Gerenciamento Da Definitivo (BSD)
Configuração (BDGC)
Incidentes
Planejamento
Política de
Seleção, identificação e Padrões
Problemas catalogação dos ICs
Controle do registro e aceitação Relatórios de
Erros de ICs autorizados e Auditoria
identificáveis
Conhecidos
Histórico do Status dos ICs
Requisições de Verificação e auditoria
Mudanças(RDM)
Mudanças Gerenciamento Gerenciamento

Autorizadas de Mudanças da Configuração
Introdução
Gerenciamento de Configuração
Permite um controle mais efetivo e rígido nos ativos de TI, sejam eles, HW, SW,
documentação, serviços terceirizados, documentação de processos, e qualquer
outro item relacionado a Infra-estrutura de TI.
Objetivo
-Controle dos ativos utilizados no ambiente de TI
-Manter informações sobre versão, status dos itens de TI
-Possuir registros atualizados dos itens
-Manter itens atualizados para auditoria

Pontos de Controle
- Modelo Lógico da infra-estrutura, ou de um serviço através da
identificação dos ativos
- Implementação de um Banco de Dados do Gerenciamento de
Configuração, que deve conter os detalhes dos elementos que são
usados para prover e gerenciar os serviços. Este banco deve conter
informações relacionadas à manutenção e mudanças
Etapas da Configuração
Identificação
Especificação e identificação de todos os componentes de IT
Status
STATUS
É a gravação do estado de todos os itens de Configuração e a manutenção
dos dados
Controle
CONTROLE
Gerenciamento de cada item de Configuração, especificando quem esta
autorizado a trocar o seu estado
Verificação
VERIFICAÇÃO
Revisões e auditorias para assegurar a informação
Objetivos
 Prover informações sobre a Infra-estrutura de TI
 Permitir o controle da infra-estrutura pela monitoração e manutenção de informações
 Definição e documentação dos procedimentos e práticas de trabalho a serem
seguidos
 Identificação, rotulação e registro dos nomes e versões dos IC’s que compõem os
serviços em TI, a infra-estrutura e seus relacionamentos
 Descrição de todos os ativos e configurações de TI dentro da organização e seus
serviços
 Fornecimento, a todos que trabalham no Gerenciamento de Serviços e no suporte, de
informações corretas e precisas sobre a configuração atual com as suas
especificações físicas e funcionais
 Garantia de que todas as mudanças nos IC’s sejam registradas assim que possível
 Provisão de uma base segura para os processos de Gerenciamento de Incidentes,
Problemas, Mudanças e Liberações
 Relatórios das métricas sobre IC’s, mudanças e liberações
 Relatórios da situação atual e histórica de todos os itens da infra-estrutura de TI
 Educação e treinamento da organização nos processos de controle
 Rastreamento e conciliação da situação atual da infra-estrutura de TI em relação aos
registros e dados da configuração autorizada
 Auditoria e relatórios de exceção dos padrões da infra-estrutura e dos procedimentos
do Gerenciamento da Configuração
Responsabilidades
 Planejamento
 Planejamento e definição do propósito, escopo, objetivos, políticas, procedimentos e dos contextos
organizacionais e técnicos para o Gerenciamento da Configuração
 Identificação e denominação
 Seleção e identificação das estruturas de configuração para todos os IC´s da infra-estrutura,
incluindo seus “donos”, seus inter-relacionamentos e documentação da configuração. Inclui a
atribuição de identificadores e números de versão para os IC’s, rotulação de cada item e inserção
no BDGC
 Controle
 Garantia de que apenas IC´s autorizados e identificáveis sejam aceitos e registrados, da recepção
ao descarte. Isso assegura que nenhum IC seja adicionado, modificado, substituído ou removido
sem a documentação de controle apropriada (por exemplo, sem uma requisição de mudança
aprovada e uma especificação atualizada)
 Descrição da Situação
 Relatório de todos os dados atuais e históricos relacionados a cada IC durante todo o seu ciclo de
vida. Isso permite a localização das mudanças e registros sobre os IC’s (por exemplo,
acompanhamento do estado de um IC à medida que ele muda de uma situação para outra como:
“em desenvolvimento”, “em teste”, “em produção”, ou “desativado”
 Verificação e auditoria
 Revisões e Controles para verificar a existência física dos IC’s e, se estão corretamente registrados
no BDGC e nas bibliotecas controladas. Inclui a verificação da liberação (release) e da
documentação da configuração antes das mudanças no ambiente de produção
Item de Configuração ( IC )
 É um elemento documentado da Infra-estrutura de TI, como hardware, software, acomodações, pessoas,
documentação
 Um IC possui:
 Uma categoria, Relacionamentos, Status e Atributos
 O registro de um IC contém características (atributos) como:
 Nome do IC - nome único pelo qual esse tipo de IC é conhecido
 Número de Cópia ou de série - para software e hardware respectivamente
 Categoria - classificação de um IC (por exemplo, hardware, software, documentação, etc.)
 Tipo - descrição do tipo do IC, ampliando a informação de “categoria” (por exemplo, configuração de hardware,
pacote de software, dispositivo de hardware ou módulo de programa)
 Número de Modelo - (por exemplo, Compaq modelo 111)
 Número de Versão - número de versão do IC
 Data da Garantia - data da expiração da garantia dada pelo fornecedor
 Local - localização do IC (por exemplo, a biblioteca ou meio onde reside o IC de software, o prédio/sala onde um
serviço esta alocado)
 Responsável / Dono - nome e/ou designação do proprietário, responsável pelo IC
 Data de propriedade - data em que o dono acima tornou-se responsável pelo IC
 Origem / Fornecedor - origem do IC (por exemplo, desenvolvido internamente, adquirido da empresa XXXXX, etc.)
 Licença - número da licença ou referência ao contrato de licença
 Data de Aquisição - data de aquisição / fornecimento do IC para a organização
 Data de aprovação - data do aceite do IC pela organização, como testado de forma satisfatória
 Situação (atual) - situação (status) corrente do IC:
 Planejado, Solicitado, Em desenvolvimento, Em teste, Em estoque, Em produção, Em manutenção, Arquivado
 Situação (programada) - próximo estado agendado para o IC (com uma data ou indicação do evento que irá
provocar a mudança de situação)
 Comentários - campo de texto (por exemplo, descrição de no quê essa versão do IC difere do anterior)

Escopo e Detalhe
 Considerações
 O fator primordial na decisão tanto do escopo quanto do detalhe é a informação que se faz
necessária para a gerência do serviço, independentemente do custo ou da dificuldade para a
obtenção e manutenção desses dados
 Escopo
 Pode ser conseguido:
 Através de uma análise dos serviços e suas contribuições e impactos nas atividades de
negócio dos clientes
 Também pela determinação de um Acordo de Nível de Serviço
 Granularidade
 São criados níveis. Considerar os principais IC´s e em quantos níveis esses itens devem ser
detalhados. O nível mais alto é a própria infra-estrutura de TI. O nível mais baixo é aquele sobre o
qual ainda é possível e interessante se ter controle, e a informação associada a ele seja útil para
outros processos ITIL
Regras para a o estabelecimento da hierarquia de um BDGC


 Quanto mais níveis, mais informações podem ser mantidas. Isso envolve mais trabalho de
manutenção e gera um BDGC maior
 Quanto menos níveis, menor o controle e a quantidade de informações sobre a infra-estrutura
de TI
 Quando um BDGC não tem profundidade suficiente, as mudanças nos componentes de nível
mais baixo não podem ser controladas corretamente
 Cada ajuste em componentes de um IC “pai” resultará em uma versão alternativa do IC
“pai”; um PC que aparece com dois tipos de unidades de disco terá uma versão A e uma
B. Se existirem muitos ajustes nos componentes “filhos” a variação da numeração
55 ABR/2005 Luiz poderá, eventualmente, ser nebulosa e difícil de preservar.
Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390
Denominação
1 ) Cada item de um inventário deve receber, para melhor controle um número, e esta denominação
deve ser simples e clara, para a rápida identificação.
2 ) Durante o período de existência deste item, esta identificação não pode ser alterada, permanecendo
sempre a mesma.
3 ) Cuidado com a implementação de nomes e referências complexas ou longas, visto que o acesso
torna-se complicado.
 Problemas/
Erros  Incidentes

s
Mudança

Problemas com o Relacionamento

O Relacionamento entre os itens de configuração é imprescindível para o processo de implantação desta
disciplina pois toda a base dos serviços se relaciona com a Gerência de Configuração.
Em geral toda empresa possui no mínimo um documento ( ou vários ) com algum tipo de configuração,
que muitas vezes fica em poder do próprio analista para a solução dos seus problemas diários.
Importância:
- Utilizado pela Gerência de SLA para a definição dos objetivos

- Diagnósticos de problemas técnicos
- Agilidade na identificação do equipamento para o primeiro atendimento
- Investigação de incidentes anteriores com o Item
- Auxilio a Gerência de Disponibilidade na identificação dos itens necessários para uma certa
disponibilidade de um serviço
-Avaliação de impacto de uma mudança, assim fica fácil verificar qual o impacto a mudança irá causar
Tipos de Relacionamentos
- Pai e filho: um módulo de SW é parte de um programa
- Uma cópia de: cópia de um modelo padrão
- Relacionado a: uma área usuária
- Relaciona-se com: um equipamento conectado em um rede
- É usado por: utilizados por um determinado serviço

Gerenciamento de Incidentes

GERENCIAMENTO DE INCIDENTES
Banco de Dados do Base de Dados

Gerenciamento Da de Erros e
Configuração (BDGC) Problemas
Requisição
de Serviço Detecção e Registro de
Incidentes
Relatórios
Suporte inicial e classificação do Serviço
de todos os Incidentes
Investigação e Diagnóstico Estatísticas
Incidentes de Incidentes
Resolução e Recuperação
Fechamento de Incidentes Requisição
de Mudança
Propriedade, Monitoração,
Requisições de (RDM)
Rastreamento e Comunicação
Mudanças(RDM)
Gerenciamento
Gerenciamento Gerenciamento Gerenciamento
de Nivel de
de Mudanças da Configuração de Problemas
Serviço
Ponto Principal
A Gerência de Incidentes tem como principal objetivo colocar o
serviço do usuário on-line o mais rápido possível minimizando
impactos na operação do negócio, Dentro dos níveis de SLA
(Service Level Agreement) estabelecidos.
“In ITIL terminology, an 'Incident' is defined as:
any event which is not part of the standard operation of a service and which
causes, or may cause, an interruption to, or a reduction in, the quality of that
service.”
Conceitos
O Service Desk é responsável por monitorar o processo de resolução de todos
os incidentes registrados. O Service Desk é o owner de todos os Incidentes.
Os Incidentes que não podem ser resolvidos imediatamente pelo Service Desk
devem ser direcionados para grupos especializados.
A solução ou o trabalho em torno do problema deve ser iniciado assim que
possível, de forma a restabelecer o serviço o mais rápido possível ao usuário.
Após a resolução o Incidente pode ser fechado.
Podemos ter os seguintes status:
- Novo- Aceito- Agendado - Em trabalho- Em espera- Fechado

Definições
 Incidente: qualquer evento que não faz parte da operação padrão de um
serviço e que causa, ou pode causar, uma interrupção do serviço ou uma
redução da sua qualidade
 Solução de Contorno: método de “desvio” de um incidente ou problema,
através de um ajuste temporário ou de uma técnica
 Requisição de Serviço: incidente que não representa uma falha na infra-
estrutura de TI
Responsabilidades
 Produzir informações Gerenciais
 Gerenciar o Incidente enquanto estiver com os níveis especializados
 Registrar o Incidente
 Monitorar o Incidente, incluindo os IC que estão envolvidos
 Manter os usuários informados em relação ao andamento do Incidente
 Executar o escalation se necessário
 Resolução dos Incidentes que não foram escalados para a equipe de
especialistas
Ciclo de Vida do Incidente
Registro
Classificação e
Suporte Inicial
Requisição de Requisição de
Serviço? S Serviço
Investigação e
Diagnóstico
Resolução e
Recuperação
Fechamento

Ciclo de Vida do Incidente Fechamento

Classificação
Resolução
Investigação
do incidente:
ede
Recuperação:
e Serviço
Registro:Inicial
Requisição
Suporte Diagnóstico
 Após o serviço restaurado, o
 Categorização:
Execução
Análise
Registrar
Seguir
Avaliar do das
odetalhesações
incidente
procedimento
os detalhes para
na restauração
busca
do aincidente
básicos rápida
apropriado
edo
buscar -
de
para
solucionador avisa Central de Serviços
solução
uma
incidente de
solução
Requisições
soluções contorno
rápidas
 Hardware ou
permanente permanente
ou de contorno
(executadas geralmente pelo 2º ou 3º
A  Software
Central
níveis) de Serviços contacta o
Registro
 Usuário/Cliente
 Requisição
Registrar
para verificar se a
os eventos (acontecimentos)
solução oferecida restaurou o serviço e
ações executadas
 Segurança
dentro do esperado
Classificação e
Suporte Inicial Priorização
 Se este for o(baseado nos ANS):pode ser
caso, o incidente
fechado
 Impacto (efeito sobre o negócio)
 Osregistros
Urgênciaserão sempre
(rapidez comutilizados
que o
como históricos
incidente deve ser resolvido)
Requisição de Requisição de
Serviço? S Serviço
Investigação e
Diagnóstico
Resolução e
Recuperação
Fechamento

 Incidentes, Problemas e Mudanças...
Incidentes x Problemas
 São entidades separadas. Um incidente nunca se transforma em um problema. As três
entidades podem estar ativas simultaneamente
 Início: Apenas um incidente

 O processo de Gerenciamento de incidentes tentará resolvê-lo o mais breve possível. Caso a
solução não seja encontrada na fase de investigação do incidente, a ajuda do Gerenciamento
de Problemas será solicitada, visando a determinação da causa raiz do incidente
 Investigado e Escalado: Incidente e Problema existem simultaneamente

 O Gerenciamento de Problemas registra, categoriza, prioriza e designa os recursos que
diagnosticam o problema e encontram a causa raiz subjacente ao incidente
 Diagnosticado: Incidente, Problema e Erro conhecido existem simultaneamente

 Um erro conhecido é definido e, depois de se descobrir como solucioná-lo, é gerada uma
RdM, para que o Gerenciamento de Mudanças resolva a situação.
 Mudança em andamento: Incidente, Problema, Erro Conhecido e Mudança existem

simultaneamente
 A mudança é implementada com sucesso. A revisão de Pós-implementação mostra que a
mudança realmente eliminou o erro conhecido com sucesso. Confirmado que o incidente foi
resolvido, tanto incidente como o problema, aberto pela mesma razão, podem ser fechados.
 Final: Incidente resolvido; mudança, problema e erro conhecido fechados
 Observação:
 Durante a fase de diagnóstico, se o time de problemas encontra uma solução de contorno, o
incidente pode ser fechado (com a aprovação do Cliente). O problema pode ter, então, o seu
status alterado de, por exemplo, “urgente” para “não urgente”. O processo de Problemas
decide
64 ABR/2005 se Augusto
Luiz os recursos prosseguem,
de A. nesse momento, com
Musa lamusa@fgvsp.br o diagnóstico
011-9980 8946 do problema,
011-3281 ou se
3390
Incidente x Problemas x Erros Conhecidos
Incidente é o resultado de falhas ou erros dentro da Infra-estrutura de TI, e este incidente pode
ser resolvido sem a necessidade de investigação.
Um Problema, pode resultar de vários Incidentes, e um problema pode não ter sido diagnos-
ticado , enquanto ocorrem vários Incidentes. Trabalhar em um problema é diferente de trabalhar
em um Incidente.
Incidente Problema Erro Conhec. RFC

Erro na Infra Estrutura Adequada.
“ProblemThe unknown underlying cause of one or more Incidents.

Known ErrorA Problem that is successfully diagnosed and for which a Work-around is known.
RFCA Request For Change to any component of an IT Infrastructure or to any aspect of IT
services”

Gerenciamento de Problemas

GERENCIAMENTO DE PROBLEMAS
Banco de Dados do Base de Dados

Gerenciamento Da de Erros e
Configuração (BDGC) Problemas
Incidentes
Graves Controle de Problemas
Suporte inicial e classificação Controle de
Erros
Apoio no tratamento de incidentes graves Requisição
de Mudança
Prevenção Proativa de Problemas
(RDM)
Obtenção de informações gerenciais a
Incidentes partir dos dados de Problemas
correlaciona-
Apoio na revisão dos principais
dos
Problemas

de Mudanças da Configuração de Liberações
Ponto Principal
A Gerência de Problemas tem como principal objetivo minimizar o
impacto de Incidentes e Problemas no negócio, prevenindo a
ocorrência de Incidentes, relatando os erros encontrados
Conceitos Básicos
Um problema pode causar um ou mais Incidentes e um Erro Conhecido
é um problema que foi diagnosticado, com a devido trabalho realizado
em relação ao Problema
Áreas de Foco:
Controle de Problemas: Chegar a causa raiz dos Incidentes
- Identificando, classificando e investigando
Controle de Erros: Corrigir problemas, informações gerenciais relacionadas

aos problemas, e erros conhecidos
- Implementar e monitorar

Objetivos
 Minimizar o impacto
 Prevenir a recorrência
 Encontrar a causa raiz dos incidentes
 Iniciar as ações para melhorar ou corrigir a situação
Aspectos Pró-ativos: Identificação, solução de problemas, erros
conhecidos antes que os Incidentes ocorram
Aspectos Reativos: Solução de Prob. responde um ou mais Incidentes
Definições
 Problema: é uma falha na infra-estrutura de TI, cuja causa é desconhecida e
que resulta na ocorrência de incidentes. Se a causa do problema ou
incidente é conhecida ele é chamado de erro conhecido até ser sanado
através de uma mudança
 Erro: Um incidente ou problema cuja causa raiz é conhecida
 Erro conhecido: Um incidente ou problema cuja causa raiz é conhecida e
para a qual foi identificada uma solução de contorno ou permanente
Responsabilidades
 Controle de Problemas:
 Identificar, registrar e classificar os problemas
 Alocar suporte adequado para a análise da causa raiz, para encontrar solução permanente
 Controle de erros conhecidos:

 Gerar as RdM´s para que Ge. de Mudanças possa remover erros conhecidos da infra-estrutura
 Manter as bases de dados de conhecimento e erros conhecidos / soluções de contorno
 Publicar erros conhecidos para que o Processo de Incidentes seja ágil na solução de incidentes
 Investigar se os problemas e/ou erros conhecidos que estejam ou não presentes em outras
partes da estrutura controlada
 Assistência no tratamento de incidentes graves:

 Organizar reunião formal com a equipe de suporte adequada à situação, quando notificado pela
Central de Serviços da ocorrência de incidentes que causam impacto na comunidade de Usuários
 Prevenção Pró-Ativa:
 Prevenir a ocorrência de novos incidentes/problemas. Por exemplo: manutenção preventiva,
comunicação com departamentos como desenvolvimento de software e análise de tendências
 Identificação de tendências: Estatisticamente monitora os incidentes para identificar problemas.
Especialização pessoal pode ser determinante se a tendência realmente leva a um problema.
 Revisões de conclusão dos principais problemas:

 Verificar através da RPI (Revisão de Pós-Implementação) se uma alteração executada pela G. de
Mudanças alcançou o objetivo esperado por Ger. de Problemas: redução/eliminação de incidentes
 Informações Gerenciais:
 Criar/disponibilizar relatórios sobre a efetividade e desempenho do Gerenciamento de Problemas
Controle de Problemas
O Gerenciamento de Problemas deve achar a causa do Incidente e sua subseqüente resolução e a
prevenção
 A investigação do problema pode tomar algum tempo, porém e pode causar
a demora na volta dos serviços, porém previne a recorrência
Problemas x Incidentes
 Identificação: As formas de se identificar um problema são:
 Registro imediato de problema (pelo responsável da gerência de problemas) na ocorrência de um incidente
com impacto considerável e que precisa ser resolvido; iniciar uma investigação para se encontrar a causa raiz
 Durante a análise de tendências, podem ser descobertos vários incidentes com sintomas similares
 Alguém descobre uma fonte potencial de problemas
 Se um incidente for fechado com o código “solução de contorno”
 Se um problema foi enviado por um outro setor
 Classificação: Coleta de dados a fim de categorizar e priorizar o problema
 Qual(is) é (são):
 IC´s envolvidos; incidentes relacionados; sintomas; causas; soluções/contornos; mudanças relacionadas a
esses IC´s; níveis de serviço relacionados; perigos; clientes envolvidos; tempo necessário (assim esperamos)
para encontrar uma resposta (tanto em esforço quanto em tempo); urgência da resolução; dimensão do
possível benefício da resolução do problema (impacto)?
 Designação de recursos
 Investigação e diagnóstico
 Objetiva detectar a causa subjacente de um ou mais incidentes, utilizando as bases de dados de incidentes
(soluções de contorno), registros de mudanças recentes e históricos dos IC´s
 Estabelecimento de Erro Conhecido
 O passo anterior estabelece o erro conhecido. Registrar esse erro conhecido e encaminhá-lo para o
processo de controle de erros
 Observação
 Durante todo o processo, o responsável tem a responsabilidade de rastrear e monitorar o andamento e a
qualidade, bem como de fornecer os relatórios necessários
Controle de Erros
 Responsabilidades
 Registrar, monitorar e tratar todos os erros conhecidos, desde o início (identificação) até a implementação,
com sucesso, da mudança que eliminou a causa raiz
 Identificação e registro do erro
 Um erro é identificado quando se detecta uma “falha” em um IC. Quando encontrada a causa raiz do
problema, o status de Erro Conhecido é estabelecido
 Existem duas fontes de erros conhecidos, uma é o Controle de Problemas do ambiente de produção, e a
outra do ambiente de desenvolvimento
 Avaliação do Erro
 Executar a avaliação inicial dos meios para se resolver o erro, em colaboração com a equipe especializada
 Registro da solução do erro

 Registrar no Sistema de Gerenciamento de Problemas o procedimento de resolução
 Preencher uma RdM de acordo com os procedimentos do Gerenciamento de Mudanças
 A prioridade da RdM é determinada pela urgência e impacto do erro no negócio.
 O identificador (ID) da RdM deve ser incluído no registro do Erro Conhecido e vice-versa, ligando os dois
registros (exemplo: para auditoria)
 Obs: É vital que o registro de cada Erro Conhecido:

 Seja incluído na base de dados de Erros Conhecidos, para consulta na comparação de incidentes, sendo
assim um guia para investigações futuras e fornecendo informações gerenciais
 Contenha: os dados sobre os IC´s, sintomas, solução / ações de contorno
 Os estágios finais da resolução de um erro estão sob o controle do Gerenciamento de Mudanças:
 análise do impacto
 avaliação detalhada da ação para a solução
 acerto do item com erro
 teste da mudança

Fluxo simplificado - Entrega de Serviços
Cliente
5 Gerenciamento do Nível de Serviço

 Manter e melhorar gradualmente a
qualidade do Serviço de TI, através
Gerenciamento de Mudanças de um ciclo constante de:
 acordos
 monitoração
 relatórios
4 Gerenciamento da Capacidade 1 Gerenciamento Financeiro

 Monitorar e medir:  Desenvolver as políticas de
 a capacidade dos recursos, Previsão Orçamentária,
 a performance dos serviços e  Contabilidade de TI e
 planejar capacidade  Cobrança
(sincronizado ao negócio)
2 Gerenciamento da Continuidade
3 Gerenciamento da Disponibilidade
 Monitorar os níveis de  Planejar IC´s alternativos
disponibilidade para garantir que os (individuais ou instalação inteira -
ANS´s sejam atingidos desaster recovery)
 Testar Plano de Contingência

Gerenciamento de Mudanças

Gerenciamento de Mudanças
BCO de DADOS do
Gerenciamento da
Requisições de Configuração (BDGC)
Mudanças Programação
(RDMs) futura de
Avaliação e Registro das Mudanças
Mudanças(PFM)
Análise do impacto, custo, benefícios e
riscos associados Requisições de
Mudança
Justificativa e aprovação das Mudanças (RDMs)
Controle das Mudanças e do Processo de Atas de
Mudança reunião do
Programação
Futura de Instauração do comitê de Controle de CCM e Ações
Mudanças (PFM) Mudanças (CCM) e do Comitê de
Emergência (CCM/CE) Relatórios do
Gerenciamento
de Mudanças

da Capacidade da de Liberações
Configuração
Ponto Principal
O Gerenciamento de Mudanças tem como principal
objetivo verificar se métodos e procedimentos
padronizados estão sendo utilizados em Mudanças.
Devemos levar em consideração a necessidade da

Mudança em relação ao impacto que poderá
ocasionar.
BEST PRACTICE: Implementar o Gerenciamento de

Configuração junto com o Gerenciamento de
Mudanças!!!!

Conceitos Básicos
Definição de mudança
 Adição, modificação ou remoção de hardware, software,
rede, aplicação, ambiente, sistema, microcomputadores e
documentação associada, que são aprovados, suportados ou
de referência.
O Gerenciamento de Configuração deverá

disponibilizar as Informações necessárias, para
que possa ser avaliado o Impacto respectivo

Escopo
Importante !!!!
O Gerenciamento de Mudança não é responsável
por identificar componentes afetados por uma
mudança, ou gravar a versão;
Isso é responsabilidade do Gerenciamento de
Liberações

Mudanças x Projetos

Solicitante preenche Enviar para Gerência
p lo Formulário de SM de Mudança
xem
E Solicitação é discutida
no Comitê
N
Mudança Feedback à área
Aprovada? solicitante
SM discutida na
reunião de análise de
impacto
N
Mudança Feedback à área
Aprovada? solicitante
Desenvolvimento B

Homologação A

79
- Boundaries between Change Management and program
ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br
management
011-9980 8946 011-3281 3390
Processo Padrão
Gerência de Projeto
Mudanças
RdM Registro e Monitoração e
Classificação Planejamento
Recusa
Aprovação Construção
Recusa Autorização e
Teste
implementação
Avaliação (RPI) Implementação

Backout

Planejando e Implementando
Construa um bom alinhamento entre TI e Negócio
Divida as informações de Mudanças entre a área de TI e do Negócio
Avalie o risco
Lembre-se que a Mudança pode impactar no SLA
A formação de grupos de Avaliação pode custar mais caro, porém o sucesso
da Mudança paga este risco
Realize também reuniões de Impacto
Construa um time de aprovação de Mudanças emergenciais
Sempre peça autorização para efetuar Mudanças
Implementar Mudanças sem um efetiva Gerencia de Configuração pode ser
desastroso
A quantidade de RFC rejeitados ou impactos da Mudanças são ótimos
norteadores dos serviços
Responsabilidades
 Comunicação
 Receber e registrar as Requisições de Mudança (RdM)
 Avaliar as implicações, custos, benefícios e riscos das
mudanças propostas
 Planejamento das Mudanças
 Justificação e aprovação da Mudança
 Coordenar e controlar a implementação
 Monitoração e Relatórios
 Revisão de Pós-Implementação e Fechamento das RdM
 Instaurar o Conselho de Controle de Mudanças/Comitê de
Emergência (CCM/CE)

Como é a formação?
Conselho de Controle de Mudanças (CCM)
Change Advisory Board (CAB)
 Freqüência das reuniões
 Deve se reunir regularmente; as reuniões também podem ocorrer algumas vezes por semana, com
convocações especiais para reunião a qualquer hora. Alguns membros participam regularmente;
outros são convidados dependendo da RdM a ser discutida
 Função
 Aprovar a maioria das mudanças e auxiliar o Gerenciamento de Mudanças na avaliação e
priorização, com visão tanto técnica como de negócios. Por isso, precisa incluir pessoas com uma
clara compreensão das necessidades do negócio do Cliente e da comunidade Usuária, bem como
das funções do desenvolvimento técnico e de suporte
 Os membros podem ser:
 O Gerente de Mudanças
 Cliente(s)
 Gerente(s) Usuário(s)
 Representante(s) de Grupo de Usuários
 Pessoal de desenvolvimento/manutenção de aplicações (quando apropriado)
 Consultores especialistas/técnicos
 Equipe de serviços (se necessário)
 Equipe de serviços administrativos (quando as mudanças afetam as instalações)
 Representantes dos contratantes ou de terceiros (se necessário - por exemplo, em situações de
outsourcing)
 CCM/CE (Comitê de Emergência)
 Quando surgem problemas mais graves, pode não haver tempo para se criar um CCM completo e
é, portanto, necessário identificar uma configuração menor com autoridade para tomar decisões
emergenciais.
Relacionamento
Gerenciamento de Gerenciamento de Gerenciamento de
Mudanças Mudanças Liberações
Avalia o Autoriza a Controla a

impacto mudança liberação de
novas versões
de software ou
hardware se
necessário para
implementar a
Mudança
Gerenciamento da Gerenciamento da Gerenciamento da

Capacidade Configuração Configuração
Avalia o Identifica áreas Atualiza
impacto no afetadas registros
Negócio e na
Performance da
TI


BCO de DADOS do Biblioteca de Software

Gerenciamento da Definitivo (BSD)
Configuração (BDGC)
Programação
das Liberações
Política de Liberação
Plano de Liberação Estatística das
Mudanças
Aprovadas Projeto, desenvolvimento, pedido ou Liberações
compra de software
Construção e configuração da Liberação Revisão das
Liberações
Adequação para fins de testes
Aceite da Liberação Biblioteca de
Liberações
Plano de rool-out
Comunicação, preparação e treinamento Padrões para
testes
Distribuição e instalação
Relatórios de
Auditoria
Gerenciamento
das Mudanças

O Gerenciamento de Liberações é responsável pelo armazenamento do software

controlado e autorizado, pela liberação do software no ambiente de produção,
pela distribuição do software para locais remotos, pela implementação do
software necessário ao serviço e manter hardware disponível, para que os
incidentes e instalações possam ser tratados rapidamente.
Fatores como:
-crescente número de Itens de Configuração (IC's) de software interdependentes,
-potencial introdução de vírus,
-complexas estratégias de licenciamento para minimizar os custos das licenças,
-garantir que o software esteja disponível onde é necessário,
Sugerem o valor de um investimento imediato na implementação
de uma rigorosa disciplina.
O Gerenciamento de Liberações trabalha muito próxima a Gerência de

Mudanças e Configuração, para se ter a certeza que a CMDB esta com as
alterações de Releases implementadas corretamente.
O Termo Release é utilizado para descrever uma coleção de

Mudanças autorizadas em um ambiente de TI!!

Objetivo
1 - Planejar e administrar um rollout bem sucedido do software e hardware relacionado.
2 - Projetar e implementar procedimentos eficientes para a distribuição e instalação de
mudanças nos sistemas.
3 - Garantir que o hardware e o software, que está sendo alterado, possa ser localizado e
protegido, e assegurar que, apenas versões corretas, autorizadas e testadas sejam
instaladas.
4 - Comunicar e gerenciar as expectativas do cliente durante o planejamento e rollout de
novas liberações.
5 - Acordar o conteúdo exato e o plano de rollout da liberação, através de associação com
gerenciamento de mudanças.
6 - Implementar novas liberações de software ou hardware no ambiente operacional,
utilizando os processos de controle do gerenciamento de configuração e mudanças -uma
liberação deve estar sob o gerenciamento de mudanças e pode consistir de qualquer
combinação de IC's de hardware, software, firmware e documentação.
7 - Garantir que as cópias originais de todos os softwares estão seguras em uma
biblioteca de software definitiva -BSD e que o banco de dados do gerenciamento de
configuração (BDGC) esteja atualizado.
8 - Garantir que todo hardware a ser implantado ou alterado esteja protegido e é
localizável, utilizando os serviços do gerenciamento da configuração.
Responsabilidades
 Planejamento e Política da Liberação

 Construção, projeto e configuração da liberação
 Aceite e Planejamento do Rollout
 Armazenamento do software autorizado pela direção (desenvolvido
internamente, adquirido ou licenciado, software utilitário, etc.),
 Liberação do software no ambiente de produção
 Distribuição do software para locais remotos
 Implementação do software necessário ao serviço
 Possuir hardware disponível, para que os incidentes e instalações possam
ser tratados rapidamente

BSD X BDGC
90 ABR/2005

DSL and CMDB relationship

Luiz Augusto de A. Musa

lamusa@fgvsp.br 011-9980 8946 011-3281 3390
Ciclo de Vida
Durante o ciclo de vida de um programa ocorrem os seguintes passos:
1 - O processo se inicia com a aquisição do software ou na atribuição da tarefa para o seu
desenvolvimento. U A entrega do software deverá ser seguida de uma verificação de qualidade.
2 - Na verificação da qualidade, o software é aceito para inclusão na BSD. Examina-se, por
exemplo, se é realmente o software que foi requisitado, se novas versões foram desenvolvidas a
partir da origem correta, se todos os acertos estão autorizados pelo Gerenciamento de Mudanças
e se todos os itens estão registrados no BDGC.
3 - Uma vez aceito o software, é feita uma salva (backup) da BSD depois da qual o software será
inserido na BSD. Essas salvas devem ocorrer com freqüência para que, em caso de desastre, a
última versão correta possa ser ativada rapidamente.
4 - A compilação e o momento de cada liberação são decididos, com antecedência, pelo
Gerenciamento de Mudanças; é criado um "Registro de Liberação" no BDGC, e todos os detalhes
são registrados.
5 – Quando todos os componentes do software estiverem prontos, o pacote pode ser efetivado
em uma área de teste
6 – Quando o Software for aprovado, ele será liberado para utilização e esta versão será então
liberada para uso.

Utilização
As cópias podem ficar disponíveis para:

- Desenvolvimento: uma nova versão pode ter origem de
uma anterior
- Teste: em uma área de teste elas podem ser testadas
- Utilização: área real de produção, a partir de onde o
Software está disponível para os usuários

Update BDGC e DHD

BDGC: O banco de Gerenciamento de Configuração, é utilizado pela
Gerenciamento de Liberações e deve conter os seguintes dados:
 Definição dos Releases planejados, incluindo o HW e SW planejados para
serem utilizados
 Itens de Configuração afetados por Releases antigas e novas
 Localização física dos componentes, ex: a máquina e o drive que recebeu a
atualização
DHG: Depósito de Hardware Definitivo
 Deve ser separada uma área para armazenamento de HW

 Registrar o componente e sua localização no BDGC
 Se necessário eles podem ser utilizados, e retornados ao BDGC, ou
substituídos

Gerenciamento de Capacidade

DELIVERY – CAPACITY MANAGEMENT
OBJETIVO
Entender os requerimentos futuros de Negócio ( que vão requerer entrega de
serviços) as operações da organização ( a entrega de serviços corrente), a
Infra-estrutura de TI (os meios de entrega de serviços), e garantir que todos
os aspectos da capacidade corrente e futura dos requerimentos de negócio
sejam sejam providas com custos eficientes.
PORQUE
Monitorar a performance, vazão e eficiência dos Serviços e suportar os
componentes de TI
Ajustar atividades que tornem efetivo o uso de recursos
Entender a demanda corrente para recursos de TI e derivar previsões para
futuros requerimentos
Influir na demanda por recursos, junto com outros processos de Gestão
Produzir um Plano de Capacidade preditivo dos recursos necessários de TI
alinhados com os Níveis de Acordo de Serviços

Gerenciamento da Capacidade
Requisições de Relatórios de
Nível de Serviço, Capacidade
catálogo de BCO de DADOS de
serviço e ANSs CAPACIDADE (BDC) Plano de
Capacidade
Estratégia e Planos
de Negócios e de TI Prever, modelar, prototipar, dimensionar e Programação
documentar requisitos futuros do negócio futura de
Volumes e Mudanças(PFM)
Controlar, analisar, ajustar e reportar o
requisitos de
desempenho dos serviços, estabelecer
negócios Plano
referências e perfis de uso dos serviços
Operacional
Orçamentos e gerenciar a demanda por serviços
Revisado
planos Controlar, analisar, ajustar e reportar a
financeiros utilização de componentes, estabelecer Configuração
Quebras de ANSs referências e perfis de utilização dos de Referência e
Rev. de Serv. componentes Perfil
Incidentes e Probl Recomendaçõe
s sobre custos
Planos opera - e cobrança
cionais e planos de
implementação Limites e
Alarmes
Gerenciamento Gerenciamento Gerenciamento Gerenciamento Gerenciamento

Financeiro da da da de Incidentes
Continuidade Disponibilidade Configuração
Ponto Principal
Garantir a existência da Capacidade de TI, com
custos justificáveis satisfazendo as necessidades
do negócio.
Este Gerenciamento determina as demandas do

negócio,as cargas de TI, e Executa o planejamento
dos recursos de TI.
Principal atribuição: Plano de Capacidade

documentado!!

Conceitos Básicos
O Gerenciamento da Capacidade fornece as
informações necessárias referente a utilização dos
componentes, permitindo que a organização decidir
quais componentes devem sofre upgrades.
Este Gerenciamento tem o objetivo de fornecer

a visão de Quando e Quais componentes
devem ser realizados os upgrades e qual o
Custo!!!

Objetivos S. DELIVERY – VISÃO GERAL
Este Gerenciamento é responsável pela garantia de que a capacidade de

processamento e armazenamento, ou seja os recursos de TI acompanhem o
crescimento das demandas do negócio.
Este processo envolve:
Monitorar a performance e produtividade dos serviços e componentes de TI
Tornar os recursos de TI mais eficientes através de ajustes no ambiente
Produção de um Plano de Capacidade que permitirá fornecer serviços na
qualidade definida no SLA
Capacidade é um ato de equilíbrio entre:
 Custo e capacidade: justificar o custo através das necessidades do negócio
 Oferta contra demanda: oferta do processamento disponível se equipare as
demandas do negócio existente

A Capacidade e o Negócio
“However the driving force for Capacity Management should be the business requirements of the
organisation”
- Capacity Management and the business
O que levar em consideração?

The Capacity Management process

Processo de análise

Iterative activities in Capacity Management
É possível que a organização já possua alguma ferramenta ou avaliação da Capacidade do

Ambiente, entretanto precisamos estabelecer detalhes para os procedimentos e
ferramentas já existentes.
- Avaliar de quem é a responsabilidade pela definição e avaliação da Capacidade

- As ferramentas que já são utilizadas
- Definições de SLA
- Custos disponíveis
Quando o levantamento estiver pronto devemos produzir:
- O levantamento da situação atual

- As lacunas encontradas no processo
- E um projeto de Implantação
Responsabilidades
- Assegurar ´que a monitoração dos recursos e

performance dos sistema estejam sendo gravados no
CDB
- Produzir o Pano de Capacidade em linha com o plano da
Organização
- Produzir regularmente um documento com as
informações dos recursos utilizados
- Teste de Performance de novos sistemas
- Recomendações de Tuning dos sistemas
Por que Gerenciamento de Capacidade?
 Por quê?
Capacidade dos servidores é feito reativamente, o que pode gerar um stress para a
organização
Diminuição de custos no upgrade de PC para utilizar determinada aplicação
Providencia a necessária informação para o plano de utilização individual de cada
componente
 Dependências das outras Gerencias:

Como o Gerenciamento de Mudanças pode avaliar o impacto que a Mudança implica
na Capacidade, se não existe um plano de Capacidade?
Quando um serviço é implementado, como pode o SLA determinar se o SLR
implementado não impactará o SLA já estabelecido?
Como o Gerenciamento de Problemas irá detectar a causa de Incidentes gerados por
performance?
Um bom Gerenciamento de Capacidade garante que não haja

SURPRESAS!!!
Implementando novas solicitações

How new requirements for Capacity drive the
Business
Você precisará de uma ferramenta de monitoração
Você precisará de um banco de dados para armazenar
o histórico
Ferramentas de performance devem ser consideradas
Recursos com experiência suficiente no ambiente
A implementação correta, diminui o risco do ambiente
O negócio tentará implementar Sistemas sem negociar
upgrade do ambiente, mostre a eles o que pode
acontecer!!!
Gerenciamento de Disponibilidade
DELIVERY – AVAILABILITY MANAGEMENT
OBJETIVO
Otimizar a Capacidade da Infra-estrutura de TI e suportar a organização na
entrega, por custos efetivos e em níveis sustentáveis de disponibilidade, as
ferramentas que o Negócio necessita para satisfazer seus objetivos.
PORQUE
Ajustar às Demandas de Negócio
Definir e Prover Custo requerido para executá-las
Definir e Prover a Configuração e a complexidade da Infra-estrutura de TI,
incluindo, níveis de redundância, a efetividade de infra-estrutura e de seus
componentes e os níveis de manutenção da infra-estrutura
Definir e Prover Processos e Procedimentos usados pelos Serviços de TI
Definir e Avaliar Fatores Humanos e eventos externos.
Requisitos de Negó- Gerenciamento da Disponibilidade
cio relacionados c/ Critérios para pro-
a disponibilidade Otimizar a disponibilidade, monitorando e jeto de disponib. E
informando sobre todos os elementos-chave da de recuperação
Avaliação do disponibilidade.
impacto no Resiliência e
negócio Determinar requisitos de disponibilidade em avaliação da infra-
termos de negócio estrutura de TI
Requisitos de dis-
ponibilidade, confia- Elaborar o Plano de Disponibilidade Objetivos acor-
bilidade e sustent. dados p/ disponib.
Coletar, analisar e manter os dados de
Dados de Proble- Confiab., sustentab.
disponibilidade e elaborar relatórios sobre
mas e incidentes
estes dados.
Relatórios sobre
Garantir que os Níveis de Serviço sejam confiab., disponib.,
Dados de configu- atingidos pela monitoração da disponibilidade sustentab. obtidas
ração e monitorados serviços em relação aos ANSs, dos
ção objetivos dos ANOs e dos feitos relacionados
Monitoração da
com a capacidade de serviço dos fornecedores
disponibilidade
Níveis de Serviço externos.
alcançados
Rever e melhorar continuamente a Plano de
disponibilidade melhoria da
disponibilidade
Gerenciamento Gerenciamento Gerenciamento Gerenciamento Gerenciamento

da de Mudanças da Capacidade da de Incidentes
Configuração Configuração
Ponto Principal
Um efetivo Gerenciamento de Disponibilidade,
influencia na satisfação do cliente e determina a
reputação do negócio. A área de IT deve ter
certeza que a Infra-estrutura entrega a
disponibilidade vital necessária ao Negócio.
Principal atribuição: O processo de

Gerenciamento de Disponibilidade é otimizar a
capacidade de Infra-estrutura de Serviço de TI,
suportando o delivery da organização a um custo
efetivo e que satisfaça os objetivos do negócio !!!
Conceitos Básicos
As organizações têm se tornado cada vez mais dependentes

da TI, e a disponibilidade dos serviços se torna
imprescindível para as organizações!!
Pontos Importantes:
- GC e GM bem estruturadas
- Ferramentas de última tecnologia
- testes regulares
OBJETIVO
Os objetivos do Processo de Gerenciamento da Disponibilidade

são:
- Assegurar que os Serviços de TI que estão determinados
para Disponibilidade são suficientes para atender o Negócio
- Otimizar a Disponibilidade dos recursos de Infra-estrutura de
TI, a um custo que permita benefícios tangíveis para o
negócio e para os usuários
- Adquirir após um período de tempo a redução na freqüência
e duração de Incidentes que afetam a Disponibilidade
- Criar e manter a um Plano de Disponibilidade
INFLUÊNCIAS
A Disponibilidade dos Componentes de Infra-estrutura de TI que entregam os
Serviços de TI para o negócio e seus usuários são influenciados por:
- Complexidade da Infra-estrutura e o desenho dos serviços

- Capacidade da organização do Suporte de TI para manter e suportar a
Infra-estrutura
- Níveis e qualidade da manutenção fornecida pelos parceiros
A TI precisa prover formalmente um acordo com cada fornecedor de Infra-

estrutura e manter uma condição apropriada e os controles necessários para que o
SLA seja realizado
UM BOM GERENCIAMENTO DE DISPONIBILIDADE PODE FAZER A

DIFERENÇA!!
CONSIDERAÇÕES
O Gerenciamento da Disponibilidade precisa considerar a Disponibilidade

do Serviços de TI e dos componentes!!!
Key Inputs:
- A Disponibilidade requerida para o negócio para um novo Serviços de TI
- Uma verificação do Impacto no negócio para cada função vital
- Informações sobre Serviços de TI, falhas dos componentes, usualmente
encontrados no Incidentes e Problemas
- Dados da configuração e monitoração
- Dados dos SLA acordados e cumpridos
Key Outputs:
- Critérios de recovery e Disponibilidade para cada Serviço de TI

- Detalhes da Disponibilidade necessária
- Requerimentos da monitoração dos componentes
- Plano de Disponibilidade
Objetivo
Devemos verificar se os serviços estão sendo suportados, em todos os
níveis, por suficientes Itens de configuração, confiáveis e corretamente
mantidos
Itensde Configuração, não são suportados pela equipe, devem possuir
acordos contratuais apropriados com fornecedores terceiros
Mudanças devem ser propostas para prevenir futura perda de serviço
Apenas desta forma, as organizações de TI podem estar certas de atender

os níveis de disponibilidades acordados com os cliente !!!!
Responsabilidades
1 - Determinação das necessidades empresariais de disponibilidade para um serviço em
TI, novo ou ampliado, e formulação do critério para a disponibilidade e para o projeto
de recuperação da infra-estrutura de TI.
2 - Determinação, em conjunto com o GCSTI, das funções de negócio vitais e do impacto
causado por falhas nos componentes da TI.
3 - Definição dos objetivos de Disponibilidade, Confiabilidade e Sustentabilidade para os
componentes da infra-estrutura de TI que sustentam o serviço, para permitir que
sejam documentados e acordados nos ANS's, ANO's e contratos.
4 - Estabelecimento de medidas e relatórios sobre Disponibilidade, Confiabilidade e
Sustentabilidade que reflitam as perspectivas do negócio, do usuário e da
organização de suporte de TI.
5 - Monitoração e análise das tendências dos componentes da Disponibilidade,
Confiabilidade e Sustentabilidade. Revisão do Serviço em TI e da disponibilidade dos
componentes, identificando os níveis inaceitáveis. Investigação das razões
subjacentes de uma disponibilidade inaceitável.
6 - Produção e manutenção de um Plano de Disponibilidade que priorize e planeje
melhorias na disponibilidade da TI. .
Terminologia
Disponibilidade (Availability): Habilidade de um componente ou serviço executar
a função esperada, em um determinado instante ou por um determinado período
de tempo.
Confiabilidade (Reliability): Habilidade do componente em oferecer a

funcionalidade desejada em um determinado período de tempo ou sob certas
circunstâncias.
Sustentabilidade (Maintainability): Capacidade de um componente ou serviço

retornar a um estado no qual a funcionalidade desejada poderá ser novamente
oferecida.
Resiliência (resilience): Capacidade de um componente ou serviço continuar

funcionando, mesmo quando um ou mais componentes falharem.
Valores a serem considerados
Os seguintes valores são os mais comuns no Gerenciamento de
Disponibilidade:
- Tempo Médio Para Reparo – TMPR

- Tempo médio entre a ocorrência do problema técnico e a sua
reparação, também chamado de fora de serviço
- Tempo Médio entre as Falhas – TMEF

- Tempo médio entre a reparação de um incidente e a
notificação do próximo incidente, também chamado de uptime,
ou tempo em serviço
- Tempo Médio Entre Incidentes de Sistema – TMEIS

– Tempo médio entre a notificação de dois incidentes
ocorridos em seqüência, ou seja todas de TMPR mais TMEF,
mede confiabilidade
Estabeleça Regras Claras
Estabeleça Regras e Metas claras !!!!
Perguntas importantes:
Quando um serviço é considerado disponível?

Quando o serviço é necessário?
Quando o sistema é considerado rápido?
Quando está considerado lento?
Serviço Disponível
Disponibilidade = Tempo de Serviço Acordado – Tempo Fora Real durante o Tempo acordado de Serviço
---------------------------------------------------------------------------------------------------------------------------
Tempo Acordado de Serviço
Um serviço, mesmo atendendo um SLA, pode ser

percebido como não disponível; muitas vezes um
funcionário precisa acabar um serviço e, neste
momento, ele está em backup !!
Serviços de Rede
Disponibilidade Disponibilidade
Componentes esperada alcançada
Gerenciamento Gerenciamento Servidores Unix
de de Nível de BRSVP230 99,50% 100%
...
Disponibilidade Serviços
Avaliação do Impacto Autorização da Disponibilidade Disponibilidade
Mudança Servidores W2K esperada alcançada
BRSVNTPCM0028 99,50% 98,53%
...
Gerenciamento Sistemas
SITEF 99,50% 99,95%
de Gerenciamento RMS - CTZ 98,00% 96,90%
Implementação de Problemas ...
Avaliação do Identificação das
áreas impactadas Disponibilidade Disponibilidade
Impacto de
Banco de Dados esperada alcançada
performance
Sites Críticos
Sites não Críticos
Rede WAN esperada alcançada
Loja BSN 99,90% 99,58%
Loja OSC 99,90% 97,22%
...
Rede LAN esperada alcançada
Roteadores
CRFR_Central_SPO 99,80% 99,98%
Matriz de Disponibilidade S. DELIVERY – VISÃO GERAL
Serviço 2
Serviço 3
Serviço 4
Serviço 5
Serviço 1
Serviço
Componente
...
Disponibilidade: 98,3% 97,8% 97,7% 98,3% 99,6% 99,1%
Nobreak 99,9% 99,9% 99,9% 99,9% 99,9% 99,9%
Retificador 99,9% 99,9% 99,9% 99,9% 99,9% 99,9%
Gerador 99,9% 99,9% 99,9% 99,9% 99,9% 99,9%
Dac Nortel 99,9%
Dac A Avaya 99,9% 99,9% 99,9%
Dac B Avaya 99,9% 99,9% 99,9%
Serv. CMS A
Serv. CMS B
Serv. CTI A 99,5% 99,5% 99,5%
Serv CTI B 99,5% 99,5%
Serv QRF 99,5% 99,5%
Serv Dados PopBar 99,8% 99,8% 99,8%
Serv. Bdados Discador 99,6
BHNT03
Discador Cob 99,6
TALKER_1 99,8% 99,8% 99,8%
TALKER_10 99,8% 99,8% 99,8%
TALKER_11 99,8% 99,8% 99,8%
Gerenciamento de Continuidade
DELIVERY – IT SERVICE CONTINUITY
MANAGEMENT
OBJETIVO
Suportar os processos gerais de Gestão de Continuidade do Negócio pela
garantia de que os requerimentos técnicos e facilidades de Serviços de TI
possam ser cobertos sempre que solicitados e acordados nos tempos
adequados às escalas de negócio.
PORQUE
Garantir Negócios nascentes pela redução de impacto de um desastre ou falha
maior
Reduzir a vulnerabilidade e risco para o Negócio por uma efetiva análise de risco
e gestão de risco
Prevenir a perda de Cliente e da Confidencialidade do Usuário
Produzir a recuperação de Planos de TI que sejam integrados com um pleno
suporte do Plano Geral da Organização de Continuidade do Negócio
Gerenciamento da Continuidade
Planos de
Continuidade
Plano de de TI
Continuidade
do negócio Análise de Impacto no Negócio
Avaliação de Risco
Estratégia de Continuidade do Serviço Análise de
ANSs Atividades de Prevenção Impacto no
Negócio AIN
Planos de Recuperação
Testes de Contingência
Limites e Contratos de
alarmes Recuperação
de Desastres
Configuração
de Referência
e Perfil
Gerenciamento Gerenciamento Gerenciamento Gerenciamento

de Mudanças da Capacidade da de Incidentes
Configuração
Ponto Principal
O Processo de Gerenciamento da Continuidade

deve assegurar que as facilidades técnicas e
serviços ( Computador,rede, aplicações, e
outras ) podem ser re-estabelecido dentro de um
prazo acordado.
O Gerenciamento da Continuidade tem foco nos

Serviços de TI requisitados para Suportar os
processos críticos do negócio. Uma avaliação de
Impacto no negócio mostra quais são os
requerimentos mínimos para a Continuidade do
Negócio.
Conceitos Básicos
As organizações dependente da tecnologia, que é o core de

muitos processos de negócio, a Disponibilidade dos
Serviços é crítica para a sobrevivência. Esta
disponibilidade e minimizada se introduzimos medidas de
redução de risco. O sucesso da implantação do
Gerenciamento de Continuidade pode somente ser
alcançado com uma visão de um comitê senior e o suporte
de vários membros da organização.
- Uma rigorosa G. Config e Mudanças e revisar
sempre os processos
- Educar a organização sobre as regras de
continuidade
- Utilizar tecnologia e ferramentas de suporte
- Treinamento para a equipe envolvida no processo
- Testes regulares
Visão Geral
 Analisar o Impacto no Negócio
 Avaliar riscos
 Definir estratégias de continuidade do Negócio
 Reduzir tempo e custo para recuperação
 Recuperar os recursos de TI dentro dos prazos de negócio
 Implemente um BCM ( Business Continuity Management )
“Business Continuity Management (BCM) is concerned with managing risks to ensure

that at all times an organisation can continue operating to, at least, a pre-determined
minimum level. The BCM process involves reducing the risk to an acceptable level and
planning for the recovery of business processes should a risk materialise and a
disruption to the business occur.
ITSCM must be a part of the overall BCM process and is dependent upon information
derived through this process. ITSCM is focused on the Continuity of IT Services to the
business. BCM is concerned with the management of Business Continuity that
incorporates all services upon which the business depends, one of which is IT .”
Relação com outros gerenciamentos
 Gerenciamento de de Continuidade interage com as seguintes

disponibilidades:
 SLM – entendendo quais são as obrigações assumidas
 Disponibilidade – fornecendo as possíveis reduções de risco
 Configuração – Definindo a estrutura do Core da organização
 Capacidade – verificando se os requerimentos do negócio
estão sendo suportados para manter o negócio
 Incidentes 0 utilizando os dados históricos ( estatísticas )
BIA ( Avaliação de Impacto no Negócio )

Graphical representation of business impacts
O BIA identifica menor requerimento crítico para suportar o negócio !!!

Plano de Continuidade
Devemos avaliar níveis de ameaças:
- Probabilidade, motivação, capacidade e recursos

- Avaliar perda de serviços acidentais
- Avaliar ponto único de falhas
Após avaliar o risco, é importante avaliar contramedidas

para os riscos encontrados, ou seja reduzir a um nível adequado
O que deve conter o plano?
Alguns pontos não podem faltar no plano:
- Administração
- Infra de TI
- Pessoal
- Contingência
- Segurança
- Local de Contingência
- Retorno ao Normal
SLM/SLA – G. ACORDOS
Gerenciamento de Nível de Serviço
DELIVERY – SERVICE LEVEL MANAGEMENT
OBJETIVO
Incrementar o Negócio, alinhado à Qualidade dos Serviços, com um constante ciclo de
comprometimento, monitoração, informação e revisão do crescimento e desenvolvimento
dos Serviços de TI e com ações instigantes para erradicar níveis inaceitáveis de serviço.
PORQUE
Service Level Management gerencia e Implementa Acordos de Níveis de Serviços entre
duas partes: O PROVEDOR, que deve ser departamento de serviços interno (engenharia,
departamento de computação, serviços de edifício) ou uma empresa externa
de outsourcing ou ainda uma terceira parte fornecedora
O RECEPTOR do serviço, ou seja, o Cliente que
paga a conta
RESPONSABILIDADES
Negociar e contratar requerimentos e características do serviço esperado, com o cliente
Medir e informar SLA Atual x Metas, recursos Requeridos e Provisão de Custos do serviço
Incrementar o Nível de Serviço em linha com os Processos de Negócio
Coordenar outras funções de Suporte e Gestão de Serviços, incluindo fornecedores,
Revisar SLAs para atender necessidades de Mudanças de Negócio, produzir, rever e manter
135
Catálogo de Serviços
ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390
Gerenciamento de Nível de Serviço

Catálogo de
Serviços
Requisitos de
Nível de Negociação e acordo sobre os níveis de Requisitos de
Serviço (RNSs) serviço esperados pelo Cliente Nível de
Métricas e relatório dos Níveis de Serviço (RNSs)
Serviço, recursos e custo da prestação do
Ficha de
serviço
Especificação
Registros de Melhoria contínua dos Níveis de Serviço do Serviço
Incidentes em sintonia com os processos de negócio
mediante os Programas de Melhoria de Contratos de
Serviços (PMS) Apoio
Coordenação de outros processos de
Registros de Gerenciamento de Serviços e das
Problemas ANSs e ANOs
funções de suporte, incluindo terceiros
Programa de
Melhoria do
Serviço (PMS)
Gerenciamento Gerenciamento Gerenciamento Gerenciamento Gerenciamento Gerenciamento

Financeiro da da da Capacidade da de Incidentes
Continuidade Disponibilidade Configuração
Ponto Principal
Esta disciplina é responsável por administrar a qualidade

e a quantidade de serviços fornecidos ao clientes de
Serviços de TI.
O Ponto principal desta disciplina são os acordos de nível

de serviço, estes acordos indicam o que deverá ser
fornecido, incluindo qualidade e quantidade, assim como
desempenho e disponibilidade desses serviços.
Conceitos Básicos
Manter e melhorar sempre e gradualmente, a

qualidade dos Serviços fornecidos por TI.
São suas responsabilidades:

- Catálogo de Serviços
- Acordo de Nível de Serviço
- Requisição de Nível de Serviço
- Ficha de Especificação do Serviço
- Monitoração, Revisão e Relatórios
Objetivo do SLM
O objetivo do Service Level Management é manter e melhorar
a qualidade do serviço de IT pelo ciclo contínuo de:
 Fazer acordos
 Monitorar os processos
 Reportar resultados
 Iniciar ações corretivas onde for necessário
Um SLA é um acordo formal entre um

provedor de serviços e um cliente de TI,
definindo objetivos e responsabilidades dos
dois lados. A ênfase sempre deve ser o
acordo com o intuito de criar uma parceria.
O processo é contínuo...
Início do
SLM
Planejar
Implementar SLAs
Desenhar o
Fehar SLA
UCs/OLAs
Catalogar
Gerenciar o processo
Negociar
Serviços
Revisar
acordo
contínuo
Monitorar
Reportar
Revisar
Revisões
Periódicas
Revisar o
Processo
Revisar
SLAs
Planejar
Atividades iniciais
 Definir ou contratar o gerente de nível de serviço (Service Level Manager)
 Definir a missão - onde queremos chegar
 Definir os objetivos e o escopo
 Fazer campanha interna para ganhar suporte, informando os envolvidos quando
e o que pode mudar
 Definir papéis, tarefas e responsabilidades
 Quantificar atividades, recursos e custos
 Identificar riscos
 Planejar o catálogo de serviços e a estrutura dos SLAs
 Desenhar um SLA ‘Piloto’ (SLO)
 Identificar ferramentas de monitoração
 Definir níveis de prioridade e fluxos de escalonamento
Implementar
Criar o catálogo de serviços
Gerenciar expectativas
Definir a estrutura do SLA
Estabelecer o Níveis de Serviços Requeridos SLRs
Escrever o SLA
Fechar o acordo
Estabelecer capacidade de Monitoração
Definir relatórios e procedimentos
Divulgar a existência dos SLAs
Criar o Catálogo de Serviços SLM/SLA – G. ACORDOS
Para ter uma visão correta de todos os serviços, é importante criar o

Catálogo de Serviços, registrando:
 A descrição do serviço
 Sistemas / componentes que afetam o serviço, com peso por item
 Os clientes que usam o serviço
Mas o que é um “serviço”?
Definimos o “serviço” assim:

Um conjunto de um ou mais sistemas de TI
que possibilitam um processo na empresa.
Gerenciar expectativas
 Criar expectativas corretas no início da implementação do

SLA
 Usuários podem pedir o que for possível justificar dentro
dos limites do escopo / orçamento
Um SLA é um documento que em si não

altera a qualidade do serviço, mas pode
mudar a ‘cultura’.
Satisfação é o resultado da expectativa e a
percepção!
Definir a estrutura do SLA
As três formas mais comuns para organizar os SLAs são:
 SLAs baseados em serviços:
 Um SLA cobre todos os usuários de um serviço
 SLAs baseados em grupos de usuários:
 Um SLA cobre todos os serviços de um grupo de usuários
 SLAs multi-nível:
 Um SLA corporativo cobre os assuntos genéricos
 Um SLA por grupo de usuários, independente do serviço
 Um SLA por serviço do grupo específico de usuários
Nível corporativo
Nível de usuários
Nível de serviços
Estabelecer os Níveis de Serviço Requeridos (SLRs)
Pré-
Catálogo de Serviços SLR
Requisitos
Definir os níveis requeridos pode ser

difícil se não existir a cultura de SLAs no
cliente. Níveis requeridos podem mudar
quando o custo envolvido ficar claro.
Escrever o SLA
 O texto do SLA tem de ser claro e não deixar espaço para várias
interpretações
 Não há necessidade de sobrecarregar o texto com termos jurídicos,
 O SLA é um acordo, não um contrato
É boa prática pedir a uma pessoa não

envolvida no processo para ler o texto a fim
de descobrir possíveis dificuldades e
ambigüidades.
Estabelecer capacidade de Monitoração
 Níveis que não podem ser monitorados não podem ser garantidos
 A capacidade existente de monitorar tem de ser revista / adequada
 Monitoração deve reflitir a percepção do usuário.
 Para a lentidão, um acordo pode ser feito sobre o número máximo de
reclamações durante um período.
É uma boa prática também preparar pesquisas periódicas de

satisfação.
Implementar
Fechar o acordo
 Disponibilização do Draft
 Negociações
 Definição das responsabilidades
 Formalização do compromisso
Definir relatórios e procedimentos
 Os mecanismos de reportar, a periodicidade e o formato dos

relatórios têm de ser definidos e acordados com o cliente.
 Também precisa ser estabelecida a freqüência de reuniões com o
cliente para avaliar o processo e discutir os relatórios.
 Os SLAs devem ficar sob controle da Gerência de Mudanças para
refletir corretamente o Inventário e o Catálogo de Serviços.
Os SLAs têm de ser reavaliados

regularmente para verificar a relevância e a
aplicabilidade.
Divulgar a existência dos SLAs

 Os acordos finais fechados têm de ser divulgados nas áreas de
suporte envolvidos com detalhes sobre o momento em que entram em
vigor
 A publicação dos resultados intermediários e dos pontos de risco pode
resultar em mais atenção nos momentos importantes
 Divulgar os SLAs entre os usuários pode desenvolver a
conscientização do que eles podem esperar e em que momento podem
começar expressar a sua insatisfação
O processo contínuo
Monitorar e reportar
A partir do momento em que o acordo for fechado, a monitoração e
produção de relatórios devem começar.
Relatórios operacionais têm de ser produzidos pelo menos diariamente, e
relatórios de metas não alcançadas imediatamente.
Um nível de serviço que não pode ser

monitorado nunca pode fazer parte de um
SLA!
O processo contínuo
Programa de Melhoramento de Serviço
O processo de Service Level Management leva ao Programa de

Melhoramento de Serviço através do sistema de revisão dos resultados
 Neste programa a Gerência de Nível de Serviços trabalha em conjunto
com a Gerência de Problemas para identificar causas e definir ações
 Essa prática deve ser incentivada para aumentar a pró-atividade
 Uma parte do orçamento deve ser reservada para custear os programas
SLM
Indicadores de Atendimento
 Número de PAs
 Número máximo de chamados abandonados
 Tempo de espera de atendimento
 Porcentagem dos chamados resolvidos no primeiro nível
 Em caso de necessidade de segundo nível: tempo até o primeiro
atendimento
 Tempo de resolução do chamado
 Tamanho máximo do ‘backlog’
SLM Contrato por SLA
 Regime Contratação
 Cobertura
 Criticidade
 Complexidade do Ambiente
 Quantidade Servidores
 Quantidade de PAs
 Quantidade Serviços
 Serviços com recursos
dedicados
 Localidades
 Escopo dos serviços
SLM Catálogo de Serviços
Serviço 4
Serviço
Serviço 3
Calypso.
SITEF
RMS.
...
Componente
Nobreak 100% 100% 100% 100% 0% 100%
Retificador 100% 100% 100% 100% 100% 100% Cada ‘componente’
Gerador 100% 100% 100% 100% 100% 100% tem seu ‘peso’ na
Dac Nortel 0% 0% 50% 0% 0% 0% indisponibilidade de
Dac A Avaya 100% 100% 50% 0% 0% 0% um serviço.
Dac B Avaya 0% 0% 0% 100% 100% 100%
Serv. CMS A 0% 0% 0% 0% 0% 0% Por exemplo, há
Serv. CMS B 0% 0% 0% 0% 0% 0% serviços que podem
Serv. CTI A 100% 100% 50% 0% 0% 0% continuar funcionando
Serv CTI B 0% 0% 0% 100% 0% 100% sem gravação, outros
Serv QRF 0% 100% 100% 0% 0% 0% não.
Serv Dados PopBar 100% 100% 50% 0% 0% 0%
Serv. Bdados Discador 0% 0% 0% 100% 0% 0%
BHNT03 0% 0% 0% 0% 0% 0%
Discador Cob 0% 0% 0% 100% 0% 0%
TALKER_1 10% 10% 10% 0% 0% 0%
TALKER_10 10% 10% 10% 0% 0% 0%
TALKER_11 10% 10% 10% 0% 0% 0%
Exemplo de Relatórios
Total de Ocorrências por Tempo de Solução
p lo 20
x em
E
19 15
10
5
6 5 3 1
0
Percentual de Disponibilidade por Componente
100,0% 99,9% 100,0% 99,9%

100,0% 99,7%
99,5% 99,2%
99,1%
99,0% 98,8% 98,7% 98,6%
98,5% 98,3%
98,0%
97,5%
97,0%
96,5% 96,3%
96,0%
95,5%
A
DB
S
UN
AP
ER
IT Y
XY
K
Y
LE
L
MK
IC A
A
S
UR
IBM
R
N
P
00
´S
BU
00
AL
WA
GM
WA
. II
RB
HL
ISU
ISD
RS
RO
RV
AC
PA
F IN
NE
NE
40
UT
-G
08
BL
RV
EW
ET
CO
AIX
A-
AS
TE
-N
E
I
.P
OR
O
IDO
TR
CT
DE
PÚ
SE
SS
UR
.N
FIR
HP
GA
PH
PH
IP
RV
ES
lo
RV
RV
DN
CT
SY
SY
SE
p
RA
SE
SE
EA
EA
em
INF
Ex
SLM - Catálogo de Serviços
Serviço 2
Serviço 3
Serviço 4
Serviço 5
Serviço 1
Serviço
...
Componente
Retificador      
Gerador      
Dac Nortel 
Dac A Avaya   
Dac B Avaya   
Serv. CMS A
Serv. CMS B
Serv. CTI A   
Serv CTI B  
Serv QRF  
Serv Dados PopBar   
Serv. Bdados Discador 
BHNT03
Discador Cob 
TALKER_1   
Matriz de relacionamento dos serviços e componentes
Cada ‘componente’
Serviço 2
Serviço 3
Serviço 4
Serviço 5
Serviço 1
Serviço tem seu ‘peso’ na
indisponibilidade de
Componente um serviço.
...
Nobreak 100% 100% 100% 100% 0% 100% Por exemplo, há
Retificador 100% 100% 100% 100% 100% 100% serviços que podem
Gerador 100% 100% 100% 100% 100% 100% continuar funcionando
Dac Nortel 0% 0% 50% 0% 0% 0% sem gravação, outros
Dac A Avaya 100% 100% 50% 0% 0% 0% não.
Dac B Avaya 0% 0% 0% 100% 100% 100%
Serv. CMS A 0% 0% 0% 0% 0% 0%
Serv. CMS B 0% 0% 0% 0% 0% 0%
Serv. CTI A 100% 100% 50% 0% 0% 0%
Serv CTI B 0% 0% 0% 100% 0% 100%
Serv QRF 0% 100% 100% 0% 0% 0%
Serv Dados PopBar 100% 100% 50% 0% 0% 0%
Serv. Bdados Discador 0% 0% 0% 100% 0% 0%
BHNT03 0% 0% 0% 0% 0% 0%
Discador Cob 0% 0% 0% 100% 0% 0%
TALKER_1 10% 10% 10% 0% 0% 0%
TALKER_10 10% 10% 10% 0% 0% 0%
TALKER_11 10% 10% 10% 0% 0% 0%
GERENCIAMENTO FINANCEIRO
Gerenciamento Financeiro
DELIVERY – FINANCE MANAGEMENT IT SERVICES
OBJETIVO
Prover o controle Efetivo dos custos dos Ativos de TI e os recursos financeiros para
prover os Serviços de TI
PORQUE
Assistir o Gerenciamento e Redução de todos os Custos de Longo Termo
Identificar o Custo Atual dos Serviços e suas provisões financeiras
Prover acurada e vital informação financeira para assistir Tomadas de Decisão
Identificar qual a Adição de Valor de TI ao Negócio do Cliente
Viabilizar cálculo de TCO e ROI
Cientificar o Cliente do custo atual dos serviços a ele pertinentes
Suportar a recuperação de custos para os Clientes pertinentes de maneira apropriada
Medir o valor investido e dar incentivos por serviços de qualidade alinhados ao negócio
Tornar benéfica a influência do Cliente, induzindo-o a usar recursos não críticos
Incentivar o uso eficiente de recursos, prover o controle de contratos externos e de
fornecedores e assistir informações financeiras na Gestão de Mudanças
Gerenciamento Financeiro
Necessidades Plano
de TI para o Financeiro
negócio Permitir que a organização contabilize os
custos com os serviços de TI e atribua
esses gastos aos serviços prestados aos
Plano Clientes da organização
Operacional
de TI Apoiar as decisões gerenciais sobre os Orçamentos e
investimentos em TI, dando suporte a Previsões
“business cases” detalhados de mudanças
nos serviços de TI
Orçamento
de TI Controlar e Gerenciar o orçamento total de
TI e permitir uma justa e eqüitativa Custos e
recuperação de custos (através de Cobranças
cobrança) pela prestação dos Serviços de TI
Contabilidade
de TI
Relatórios de
Auditoria
Objetivos
Financeiros

da da Capacidade de Nível de
configuração Serviço
GESTÃO FINANCEIRA
Visão Geral
O Gerenciamento Financeiro para Serviços
em TI, identifica, calcula e gerência o
custo da prestação ou entrega de
serviços em TI. Este Gerenciamento
Financeiro influencia o comportamento
do usuário, através da divulgação e
conscientização dos custos ou cobrança,
e fornece dados de previsão
orçamentária para a direção.
A contabilidade de Custos objetiva a justa
alocação dos custos compartilhados e
cobrança pelos serviços de TI.
GESTÃO FINANCEIRA
Ponto Principal
Previsão Orçamentária:
- Limites para gastos
- Carga de Trabalho
- Orientações de como o orçamento deve ser
gasto
- Limite de despesas
- Garantir que as quantias corretas sejam
provisionadas
GESTÃO FINANCEIRA
Como pode ajudar?

Auxiliar o Gerente de Serviços à:
- Ajudar os clientes a entender os custos da
operação
- Embasar as decisões
- Planejar e orçar com segurança
- Tomar decisões baseados em custos
- Criar um relacionamento mais comercia e
profissional
- O cliente que é cobrado pode solicitar um
serviço melhor
ESTÁGIO DE TI NA CORPORAÇÃO EM RELAÇÃO A ITIL
ESTÁGIO NÍVEL DE GERENCIAMENTO PROCESSOS ITIL MATURIDADE
CAÓTICO [0]G. de Incidentes. Nenhuma referência Inexistência de processos chave; padrões mínimos.
SENSÍVEL [1]G. de Infra-estrutura só com Informações mínimas Alguns processos instalados e padrões verificados;
G. de Incidentes e sobre modelo de refe- Conseguem a repetição de serviços com qualidade;
G. de Versões. rência ITIL Mínima G. de Configuração.
CONSCIENTE [2]G. de Sistemas. G. de Mudanças. Alguns processos padronizados permitem

G. de Problemas. Mínima Gestão de Entrega de Serviços.
G. de Disponibilidade.
ESTIMULANTE [3]Gerenciamento de Serviços. G. de Continuidade. Desempenho e qualidade verificados com métricas;

G. de Capacidade. Mínima Gestão de Riscos.
G. de Nível de Serviço. Serviços prestados com Contratos SLA.
G. Financeira. Alguma Gestão de TCO.
PROVOCANTE [4]G. de TI c/ Métricas de Negócio. Todos contidos em Processos e Serviços constantemente e

Service Support e dinamicamente alinhados ao negócio atual e futuro.
Service Delivery, Muito bem definida e comprometida a componente
planejados estratégica e financeira de TI em cada linha de negócio atual e
dinamicamente de forma planejada.
pró-ativa ao negócio.
QUESTÕES PARA POSICIONAMENTO ITIL, DO CONSUMIDOR DE TI

1) Sua corporação estuda o uso do Modelo de referência ITIL?
Sim [] Não [] Nunca ouvi falar []
2) Sua corporação já se baseia nas referências de melhores práticas do ITIL? Não [];
Sim [] ; Em quais disciplinas? Help Desk []; G. de Incidentes []; G. de Problemas
[]; G. de Mudanças []; G. de Disponibilidade []; ...
3) TI, em sua corporação, executa serviços com: G. de Nível de Serviços []; G. de
Continuidade []; G.de Capacidade [].
4) Na sua Corporação os Serviços de TI : são medidos de acordo com os riscos de
negócios por eles suportados []; são medidos de acordo com os impactos
financeiros nos negócios por eles suportados []; passam por um comitê que avalia
o custo benefício de cada um em relação ao negócio? Sim[]; Não [] .Você
consegue avaliar o impacto de cada componente do serviço de TI nos processos de
negócio por ele suportado? Sim[]; Não [].
5) Você tem dificuldades em definir claramente quais os recursos de HW, SW e de rede
estão em uso na sua Organização? Sim []; Não [];
PERGUNTAS DE POSICIONAMENTO ITIL DO CONSUMIDOR DE TI
GESTÃO DE NEGÓCIO
6) Você controla o uso dos recursos de HW de forma centralizada [] ou

por localidade [], ou por outra forma []. Qual? [ ].
7) Você controla o uso dos recursos de SW de forma centralizada [], ou
por localidade [] ou por outra forma []. Qual ? [ ].
8) Você controla o uso dos recursos de rede e telecom de forma centralizada [], por
localidade [] ou por departamento [] ou por outra forma []. Qual? [ ].
9) Você consegue definir exatamente quanto dos recursos de HW, SW e Redes de
Telecom são utilizados? Por Serviço []; Por Linha de Negócio []; Por usuário []; Por
departamento []; Por local []
10) Se sua Organização usa recursos de computação móvel: notebooks []; lap-tops [] ;
PDAs []; Coletores []; Outros [], Quais [ ], quem
define quantidade, configuração e recursos financeiros para os mesmos? TI [], ou
Departamento Usuário; ou TI e Departamento Usuário []; ou ainda outra Entidade [].
Qual?[ ]
COMENTÁRIOS SOBRE AS PERGUNTAS

1) ITIL (InformationTechnology Infra-structure Library) é um conjunto de disciplinas e melhores práticas para Serviços de TI, referência
mundial desenvolvido na Inglaterra e usado/atualizado no mundo todo, inclusive no Brasil. Com esta pergunta queremos avaliar se sua
empresa já está adotando alguma postura ITIL no suporte e entrega dos Serviços de TI para os “clientes”.
2) Se sua empresa já começou a estudar o modelo de referência ITIL, estamos querendo saber em que estágio ela se encontra com relação à
seu efetiva aplicação.
3) Com esta pergunta estamos querendo saber até que ponto os negócios de sua empresa não sofrerão descontinuidade, eventual ou não, por
falta de eficaz suporte dos serviços de TI ora prestados, inclusive por falta de capacidade de recursos de TI.
4) Com esta pergunta queremos saber se são feitos efetivos estudos financeiros no atendimento das necessidades de negócio com serviços de
TI. Se são aportados à eles o efetivo valor que têm para o negócio. Se são avaliados os impactos financeiros destes serviços no suporte às
linhas de negócio pertinentes. Enfim se existem correlação de valores entre os serviços de TI é o negócio suportado por eles.
5) Com esta pergunta queremos determinar qual é o grau de conhecimento que o Gestor de TI tem do efetivo inventário de ativos de TI
espalhados pela Corporação, no nível de detalhamento de sw por hw, etc..
6) Sua empresa pode ter infra-estrutura de TI espalhada por vários sites de administração, por vários escritórios regionais, por várias filiais,
por várias plantas fabrís, etc.. Queremos saber se a Gestão destes ativos é feita de forma centralizada ou em algum lugar central e alguns
lugares regionais. Sabemos que quando temos uma visão globalizada do que pretendemos controlar este controle poderá ser mais efetivo e
eficaz, tanto nos aspectos operacionais como financeiros e de logística.
7) O objetivo da pergunta é o mesmo só que especificamente para sw.
8) O objetivo da pergunta é o mesmo só que especificamente para recursos de telecomunicações de voz, dados e imagem.
9) Esta pergunta investiga melhor se os recursos de TI estão “amarrados” operacionalmente e, por conseguinte, financeiramente, à realização
dos negócios da corporação, nos seus vários aspectos funcionais como produção, comercialização, distribuição, etc..
10) Esta pergunta procura investigar se os aspectos de mobilidade de TI são importantes para o negócio da corporação. Se é uma demanda
natural do negócio ou uma facilidade para o controle dos mesmos. Normalmente o ambiente de computação móvel requer uma
administração ao mesmo tempo flexível, ágil, porém com controles mais acurados tanto para a disponibilização dos recursos como na sua
manutenção. Seus custos diretos e indiretos muitas vezes são maiores, a vida útil menor, etc..
ESTÁGIO DO PROVEDOR EM RELAÇÃO A ITIL
ESTÁGIO NÍVEL DE PRESTAÇÃO DE SERVIÇO PROCESSOS ITIL SOBREVIVÊNCIA NO MERCADO
EXCLUÍDO [0]Box e Tradicional Nenhuma referência Nenhuma, prestes a desaparecer e só é visto pelo
Cliente do Estágio [0[
PASSIVO [1] Estudos para Aderência e Informações mínimas Boas condições de Sobrevivência se conseguir
Certificação de profissionais, sobre modelo de refe- se transformar e transformar seus produtos e
Processos, Serviços e Ferramentas rência ITIL serviços de forma visível e assimilável pelo
mercado. Passa a ser considerado pelo Cliente do
Estágio [1]
ATIVO [2] Postura Consultiva G. de Mudanças. Alguma condições de Deslocar a Concorrência
Profissionais Certificados G. de Problemas Forte Penetração em Clientes do Estágio [1]
Usa ferramentas certificadas G. de Disponibilidade. Boa Penetração em Clientes do Estágio [2]
G. de Nível de Serviço
PRÓ-ATIVO [3] Formador de Opinião G. de Continuidade. Forte condição de deslocar concorrência
Soluções Totalmente Aderentes à G. de Capacidade. Forte Penetração em Clientes do Estágio [2] e [3]
Gestão e Governança Corporativa e SLAs com Métricas
à Gestão e Governança de ICT do Negócio.
EM FUNÇÃO DA CHEGADA AO BRASIL DO itSMF (Information Technology

Service Management Forum), DO HDI (Help Desk Institute), EMPRESAS
CERTIFICADORAS DE PRODUTOS E PROFISSIONAIS, O MERCADO
CONSUMIDOR PASSA A EXIGIR PROVEDORES DE TI POSICIONADOS
NO ESTÁGIO [2] , OU NO MÍNIMO [1].
OUTSOURCING - Mudança Organizacional

 Outsourcing muda a maneira como uma organização e’ gerenciada.
Para o sucesso as partes envolvidas devem reconhecer e aceitar esta MUDANÇA e

desafios dos novos papeis ..
 Provedor : deve entregar :
 Serviços através de processos, pessoas com skills e competência, medições

transparentes e periódicas e com o nível de tecnologia necessária.
 E’ o Implementador e responsável pelo processo operacional
 Cliente: deve ter:
 Responsabilidade de ter um grupo de Gestão eficiente que esteja compromissado

com o modelo e tenha habilidade de comunicação com toda a organização.Isto
requer conhecimento do negócio, da cultura e dos diversos relacionamentos internos e
externos
 E’ o Facilitador , negociador e gerente do contrato

Relacionamentos de ‘sourcing’
Outsourcing
Tradicional Provedor de Serviços Cliente
Provedor de Serviços
Co-sourcing Cliente
Cliente
Multi-sourcing
Cliente
Aliança
Cliente
In-sourcing Cliente / Provedor de Serviços
Quais seriam as 3 primeiras razões
para Out..Sourcing ?
 Melhorar foco da empresa
 Ter acesso a capacitação de nível internacional

 Acelerar os ganhos da re-engenharia efetuada
 Transferência de riscos
 Transferência de ‘assets`
 Liberar recursos para outros projetos Cada empresa
 Tornar disponível capital adicional tem sua prioridade
 Infusão de capital ou motivadores
 Reduzir tempo de ‘go-to-market`
 Reduzir e controlar custos operacionais
 Obtenção de recursos nao disponíveis internamente
 Operação difícil de ser gerenciada ou fora de controle
 Crescimento dos negócios
OUTSOURCING
Por que Optar por Outsourcing
Facilitar a Execução de
Implementar Mudança uma Política de Fusões
Tecnológica e de e Aquisições
Negócio em Grande 6%. Redução de
Escala Custo
14% 21%
Mudança
Legislativa /
Privatização
5%
Acesso a novos
Skill Sets
Melhorar 13%
Qualidade
dos Serviços
11%
Facilitar Speed-
To-Market Liberar Capital no Curto
5% Implementar Prazo
Controles e 12%
Processos
11%
Fonte: “Outsourcing in the FTSE 100 – The definitive study”, por Morgan Chambers, 2001
OUTSOURCING
 Direcionadores do Outsourcing
EXTERNOS
Sistemas
Menor Custo da Ineficiências Novas
As empresas Legados
Mão de Obra Internas Tecnologias
enfrentam um Obsoletos
conjunto de
fatores internos e Mudanças no Mudança de Crescente
externos, que Necessidade de
Relacionamento Estratégia Importância do
promovem uma Parcerias de
Cliente / Funcional e de Serviço ao
solução de Negócio
Fornecedor Negócios Cliente Interno
Outsourcing.
Mudar a Necessidade de
Fusão ou Spin- Mudanças no
Estrutura e Centralizar e
off de Unidades Ambiente
Conduta Padronizar
de Negócio Legislativo
Organizacional Processos
INTERNOS
“MINAS” - ofensores do processo de

Outsourcing
Cliente: Provedor:
na na
Negociaçào Negociação
• Buscou ‘ Mais-com-menos’
• Forçou itens – modelo ‘ganhador’ • Foco em Ganhar o negócio
• SLAs não condizentes com a base • Aceitou intens finais sem

atual – ou objetivos de negócio análise de riscos
• Expectativas de curto prazo • Lucratividade a ser obtida

durante a entrega
• Transferência de pessoal ‘problema’
• Pretende otimizar estruturas
• Gerência do contrato ‘participou’ com as já existentes
não compromissou com o modelo
• Expectativas do cliente
• Agenda política – conveniência OFENSORES passadas verbalmente
Outsourcing -
Fatôres Críticos de sucesso
 Serviços Gerenciados de ICT, opção: Outsourcing , constituem-se em um
modêlo Saudável e Sustentável que deve ser explorado em seus
fundamentos básicos:
 Estratégico;
 Redução de custos operacionais;
 Agilidade;
 Melhorias de Qualidade ;
 A Gestão da Mudança Organizacional para absorver Outsourcing e’

processo chave e deve receber atenção especial ;
 Níveis de Serviço e Acordos de Níveis de Serviço devem ser estabelecidos

e revistos periódicamente sob a ótica dos objetivos de negócios e suas
eventuais flutuações.
 O modelo exigirá PARCERIA entre os Times e lideranças (Cliente e

Provedor) nomeados para conduzir o Projeto ..e’ um relacionamento 24 x 7.
Motivação e diferencial
estratégico
 Motivação
 Conhecimento dos modelos de Serviços Gerenciados , opçao:
Outsourcing globais;
 Capacidade de analisar localmente os conceitos e padrões
internacionais utilizados;
 Competência em disciplinas e processos de Mudanças
Organizacionais
 Habilidades e domínio de Gerência de conflitos
 Diferencial estratégico
 Utilização de Consultores e Especialistas com comprovada
experiência nas diversas Fases de Serviços de Outsourcing;
 Reconhecimento e aproveitamento das boas iniciativas já realizadas;
 Capacitação da Estrutura Técnico / Gerencial do cliente
Objetivos da Gestão de
Out..sourcing de ICT
 Contribuir para que o projeto seja concebido em Planejamento

Estratégico abrangente e compromissado pela organização em seus
diversos níveis.
 Elaborar uma adequada identificação dos motivadores e abrangência
do projeto visando os objetivos de negócio.
 Suportar a Mudança, inerente ao processo de Outsourcing, em todas
a sua amplitude para minimizar os inibidores de sucesso do modelo
 Efetuar verificações Operacionais de Processos referenciais ,
Métricas e Tecnologias utilizadas, com transparência e foco nos
objetivos de negócio estabelecidos
 Ajudar no desenvolvimento dos papéis, Técnicos e Gerenciais,
necessários para o sucesso do projeto durante seu ciclo de vida
 Suportar e capacitar o Time envolvido no processo
Benefícios
• Garantir que o modelo de adoção de Serviços de Outsourcing
como estratégica de TI esteja fundamentado em benefícios para os
negócios
• Assegurar que o modelo estratégico originalmente definido se mantenha

dentro dos objetivos
• Identificar e propor alternativas para interferências pessoais detectadas

junto aos times Gestores (clientes e provedor) não alinhadas com a
estratégia
• Obtenção de uma análise contextual do cenário de Níveis de Serviços e

Qualidade
• Identificação de itens que gerem economia no contrato em regime, ou

elaboração de itens que enderecem indicadores de produtividade
para os novos contratos.
• Garantir um controle eficaz dos serviços que estão sendo realizados

NOVO PROFISSIONAL
IMPORTÂNCIA DA COMUNICAÇÃO
A HABILIDADE PARA OUVIR, INFLUENCIAR, NEGOCIAR E

ACORDAR É VITAL
DURANTE EXERCÍCIOS REVISONAIS NA ORGANIZAÇÃO, NO

DEPARTAMENTO OU NO GRUPO DE TRABALHO,
COMUNICAÇÃO
É O TÓPICO MAIS COMUMENTE MENCIONADO PELAS
PESSOAS COMO MAIOR NECESSIDADE A SER
INCREMENTADO.
ARQUITETURA FUNCIONAL - ITSM NOVO PROFISSIONAL
HR/ERP
Funcionários Inventário Contratos
Centros de Custos
Service
Localização Help Desk
Departamentos Problemas
Compras Help Desk Mudanças
Orçamentost
Compliance Finanças
Procurement Finance
Depreciações
Compras Distribuição de Custos
E-Procurement Outsourcing
Autorizado
“O que deveríamos ter”
A N
PROCESSOS Regras de Reconciliação DO NEGÓCIO G A
n e e t
á g s d i
d
l ó Físico t e v
e
i c “O que temos ” ã o
s i o s
e o SMS, LAN Desk,
NetCensus, Asset Tracker
CA AMO, Tivoli
Desafios da Gestão Ativos TI - ITSM NOVO PROFISSIONAL

VISÃO DO NEGÓCIO
Quando devo renovar Quais centros de custo/projetos

O que temos no inventário que serão debitados por este serviço ?
o leasing ? pode ser reaproveitado ?
Temos taxas sobre
o inventário ? Recebemos exatamente o que foi pedido ? Temos verba para
Licenças extras ?
Esta peça quebrada está Nós aproveitamos os O help desk retorna Eu estou
coberta pela manutenção ? descontos contratados ? itens devolvidos ? “compliance” ?
CONTRATAÇÃO
RECEBIMENTO
DESATIVAÇÃO
INVENTÁRIO
HELP DESK
AUDITORIA
FINANÇAS
COMPRAS
ENTREGA
USUÁRIO
SETUP
RH
CICLO DE VIDA DO ATIVO

Percepção sobre os
profissionais de TI
 1- Considerar que o negócio não está sob seu foco.
 2- Subestimar a necessidade de capacitar profissionais ou de

envolvimento com as áreas.
 3- Não atualizar ou inovar na comunicação com os demais

setores.
 4- Ser reativo.
 5- Pouca integração com os demais setores da empresa.
Gestão Técnica Econômica
I. Aspectos culturais envolvidos.
II. Performance e utilização da Tecnologia e da

Informação.
III. Avaliação dos Custos diretos e indiretos.
IV. Processos e Comunicação interna.
“O conhecimento de uma empresa não

necessariamente se aplica à outra. A cultura e
o ambiente existente podem não permitir.”
Roger Burlton
Não Se Pode Obter

Resultados Diferentes
Fazendo As Mesmas
Coisas.
Gestão da Informação
1. A Empresa precisa saber quais são as informações necessárias para o seu
negócio. É do gerenciamento eficaz da informação que depende uma boa estratégia.
2. A informação precisa fluir de maneira satisfatória dentro da Empresa.
3. O acesso à informação precisa ser democratizado e compartilhado.
4. A chave do sucesso da Gestão da informação não está na Tecnologia. Está nas

pessoas. Elas que decidem e são elas as responsáveis pela circulação das
Informações.
5. É preciso treinar e motivar as pessoas para utilizarem os meios disponíveis.
6. Pensar e agir como um INFOMANAGER é saber gerenciar a informação utilizando-

a como matéria-prima, transformando-a em conhecimento produtivo a fim de
concretizar os melhores negócios.
Gestão da Informação
•Gap nas comunicações com o mercado – empresa não tangibiliza seus diferenciais
em suas ações de marketing/ vendas ou não orienta devidamente sua base de
clientes.
•Gap Gerencial- Gerencia não administra e nem trabalha as informações levantadas

pelas equipes junto ao mercado. Quem determina as ações de marketing/vendas,
não necessariamente envolve as equipes da linha de frente. Gestores de áreas não
costumam ter a política de troca de informações.
•Gap na entrega dos serviços ou produtos- equipes de vendas super dimensionam o

serviço final, se isolam no atendimento; Equipes de atendimento não estão
comprometidas. As demais áreas não se envolvem, não se comunicam ou não são
motivadas.
Constatações na Empresa
 Falta de Atualização ou inovação.

 Muitas iniciativas, poucas “acabativas”.
 Funcionários Post Its.
 Falta de Envolvimento ou de Interêsse da Equipe.
 Não dar ouvidos ao mercado.
 Feudos Internos - “isso não é comigo”.
 Ações de curto prazo.
 Falta da cultura de planejamento.
Constatações na Empresa
 Uma pesquisa da consultoria Ernest & Young mostra que 80% da

produção intelectual das empresas não é sistematicamente aplicada
em processos de negócios.
 Cerca de metade de todos os projetos de gestão da Informação fracassa

na etapa de implementação.
 A causa é a impotência das empresas diante da necessidade de
substituição de uma cultura individualista por outra colaborativa.
Revista Exame
REFERENCIAS
itSMF – The IT Service Management Forum - January 2003

www.itsmf.com www.itsmf.org www.itsmf.on.ca
www.itsmf.com.br
www.exin-exams.com
OGC – Office of Government Commerce – www.ogc.gov.uk
ITIL – I T Infrastructure Library - www.itil.co.uk
BSI – Britsh Standards Institutions – www.bsi-global.com
Gartner, Inc. - Patricia Adams – Senior Research Analyst-

www.gartner.com
SUCESU-SP – www.sucesusp.com.br
SUCESU-ES – www.sucesues.com.br
CMAGNANI SERVIÇOS – www.cmagnani.com.br

Cópia de Curso Itil Slmsla Vit0405-New

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cópia de Curso Itil Slmsla Vit0405-New

Enviado por

Direitos autorais:

Formatos disponíveis

ITIL – SLM & SLA:

LUIZ AUGUSTO DE ANGELO MUSA – 011-9980 8946

Luiz Augusto de Angelo Musa

 Consultor da FGVSP - GVconsult em Gestão e Uso Estratégico de

 Há mais de 30 anos atuando no uso Estratégico de TI em empresas

 Participa na Vice Presidência de TELECOM da SUCESU-SP, como

2 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

BSC GESTÃO COSO

3 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

5 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

BSC (Balance Score Card)

 O BSC é uma forma

6 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

7 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

CMMi (Capability Maturity Model

8 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

9 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

GAO - General Accounting Office - USA

10 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

11 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

 É um método desenvolvido pela

12 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

Seis Sigma - continuação

 O que é: Um método de aprimoramento de processo estatístico

13 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

15 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

SAC (Systems Assurance and Control)

16 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

17 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

Cobit & ITIL

 Utilizar o ITIL para implementar controles e processos de TI

 Utilizar ITIL para determinar tecnologia

 Utilizar Cobit para definir as métricas

 Pesquisar no ITIL as possíveis estruturas

18 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

Posicionamento ITIL POSICIONAMENTO ESTRATÉGICO

19 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

ALINHANDO ICT AO NEGÓCIO

20 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

ITSM – IT Service Management

ITIL – IT infrastruture Library by UK Agency OCG –

21 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

Áreas Chave dos Processos de ITSM

Adequado a cada Organização segundo:

A Filosofia ITSM contempla 3 principais objetivos:

Alinhar IT Services com as necessidades correntes e

Alavancar e Garantir a Qualidade dos Serviços

Reduzir a Provisão de Custos de longo prazo dos

23 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

ITSM = Processos que usem as Pessoas e Produtos efetivamente,

ITSM e as Melhores Práticas

Importância dos processos

Processo é Onde Se Faz Dinheiro.

25 ABR/2005 Luiz Augusto de A. Musa lamusa@fgvsp.br 011-9980 8946 011-3281 3390

ITIL – DUAS ÁREAS FUNDAMENTAIS

Ger. De Incidentes ** G. De Níveis de Serviços

Ger. De Problemas G. Financeiro para

Ger. De Mudanças G. De Continuidade de

*Service Desk – função e não processo

Algumas características do ITIL:

Vantagens de trabalhar orientado a processos:

Como utilizar o ITIL?

• É o ponto de partida, não o objetivo