Ren Abrileri Chiari

ITIL NA PRTICA: GERENCIANDO PROBLEMAS DE

INFRAESTRUTURA E SERVIOS DE TI

Srie 1 de 3

Uma abordagem prtica para o planejamento, implementao,

operao e melhoria contnua.

1 Edio

So Paulo

2013

ITIL uma Marca Comercial Registrada do Cabinet Office no Reino Unido

e em outros pases

Esta obra tem apenas como objetivo contribuir com a comunidade de

profissionais de Gerenciamento de Servios de TI. Como apoio so usadas

referncias de outros materiais sem infringir direitos autorais de terceiros.

Dedico este livro especialmente a minha esposa Renata e ao meu cachorro e

fiel companheiro Tomas. Sem o apoio e a pacincia deles esta obra no teria

sido possvel.

Este livro tambm dedicado aos amigos e profissionais Andr Jacobucci,

Andr Bernardo, Roberto Cohen, Vladimir Abreu, Eduardo Abrileri Chiari e

tantos outros que, de uma forma ou de outra, contriburam com a minha

motivao e amadurecimento sobre o tema Gerenciamento de Problemas e

o desenvolvimento desta obra.

Prefcio

Quantas vezes j nos deparamos com situaes (na maioria das vezes

indesejveis) que causam impactos significativos em nossas vidas, que nos

do aquela sensao de dja vu (ou seja, que j aconteceram antes), e

que no fazemos a menor ideia do motivo pelo qual ocorreram?

Certamente, cada um de vocs que est iniciando a leitura deste livro agora

perder a conta ao pesquisar a memria por alguns minutos...

Situaes como estas so objetos de pesquisa e prtica h vrias dcadas

em todo o mundo, e muitas foram as proposies para identificar formas de

resolv-las.

Fazendo uma leve retrospectiva at os anos aps a 2. Guerra Mundial,

podemos ver o surgimento dos princpios da Qualidade Total na indstria,

pelas mentes brilhantes de personagens tais como Deming, Juran e

Feigenbaum, e que nos legaram, entre vrias tcnicas e ferramentas da

qualidade, o famoso ciclo de melhoria contnua, mais conhecido como Ciclo

PDCA. Esta ferramenta nos mostra que qualquer processo de melhoria

deve ser permanente e ser executado em ciclos de planejamento de

atividades, execuo dessas atividades, checagem dos resultados reais

dessas atividades e atuao na correo dos desvios em relao aos

resultados previstos.

Algum tempo mais tarde, entre as dcadas de 80 e 90, vemos surgir uma

estratgia para alcanar, maximizar a manter de forma sustentvel o

sucesso de uma organizao, baseada em um sistema abrangente e flexvel

envolvendo elementos como a compreenso precisa das necessidades (ou

situaes) dos clientes, a utilizao criteriosa de fatos, dados e de anlises

estatsticas, alm de um foco concentrado na gesto e na melhoria dos

processos de negcio. Tal estratgia, denominada Seis Sigma, tem como

linha mestra uma metodologia cclica composta por 5 etapas: Definir (os

objetivos de melhoria), Medir (a situao atual), Analisar (as medies e

identificar as reais causas da situao atual), Melhorar (ou seja,

desenvolver ideias e aplicar solues para solucionar a situao) e Controlar

(os resultados da soluo aplicada). Podemos notar aqui uma nova

roupagem para o velho e bom Ciclo PDCA...

Nos anos 90, podemos ver a aplicao de todos esses conceitos em uma

rea particularmente interessante chamada Tecnologia da Informao

(conhecida pela sigla TI), e o surgimento de uma multiplicidade de

modelos de melhores prticas, aplicados TI como um todo ou a alguns de

seus segmentos especficos. Entre esses modelos, faz-se necessrio

destacar aqui, especificamente, a ITIL, ou Information Technology

Infrastructure Library, uma biblioteca de melhores prticas para a disciplina

de Gerenciamento de Servios (de TI).

Na ITIL, podemos identificar claramente uma conexo entre os cenrios

que os princpios da Qualidade Total e do Seis Sigma identificavam como

oportunidades de melhoria de processos, e aquelas situaes indesejveis,

recorrentes e sem causa definida que mencionei no primeiro pargrafo

deste prefcio.

A essas situaes, a ITIL deu o nome de PROBLEMAS e definiu um

processo especialmente destinado a gerenci-los. Segundo este processo,

um problema deve ser devidamente detectado, classificado, ter seu impacto

avaliado, priorizado, investigado at a descoberta de sua causa raiz e

resolvido por meio de uma soluo de contorno ou (preferencialmente)

definitiva, que certamente envolver uma mudana na infraestrutura que

suporta os servios prestados por uma organizao.

O processo de GERENCIAMENTO DE PROBLEMAS pode ser considerado um

dos pilares da disciplina de Gerenciamento de Servios, uma vez que

engloba todo o contexto e o esprito de melhoria contnua do Ciclo PDCA.

Por outro lado, talvez seja um dos processos mais incompreendidos e,

consequentemente, difcil de ser implementado nas organizaes.

exatamente este processo o foco deste livro. Nele, Ren Chiari procura

descrever o processo de forma clara, descontrada e recheada de dicas e

exemplos prticos e reais, provenientes de sua experincia profissional

como consultor especialista, e das riqussimas discusses estimuladas no

seu blog ITSM na Prtica (que sucedeu o ITIL na Prtica, muito

conhecido no mercado de TI nos ltimos anos).

Conheci o Ren h alguns anos em um curso de ITIL Service Manager, e

desde l temos participado conjuntamente de vrias iniciativas e

compartilhado muitas ideias acerca da disciplina de Gerenciamento de

Servios, de Governana de TI e das tendncias futuras para a aplicao de

melhores prticas. Para mim, uma honra muito grande endossar esta

iniciativa, que certamente uma bela contribuio para a formao dos

profissionais de TI (ou melhor, de servios) no mercado brasileiro. Espero

que todos vocs encontrem neste livro muitas respostas (e tambm mais

perguntas) sobre como resolver e gerenciar os seus problemas no dia a dia.

Vladimir Ferraz de Abreu

Apresentao

Problemas. Ningum gosta. Ningum quer. Seja na vida pessoal ou no

mundo corporativo.

Em geral, os problemas so definidos como algo indesejvel. A convivncia

frequente com problemas nos expe ao caminho oposto a uma vida

saudvel. Seja como for, a convivncia contnua com problemas no

estimulada em nossa cultura atual, que se idealiza em um mundo sem

problemas.

Um processo que se prope a gerenciar problemas aparentemente parece

estar na contramo, visto que a sua razo de ser , basicamente, estimular

os problemas atravs uma srie de atividades investigativas com o objetivo

de evit-los e, consequentemente, equilibrar e estabilizar a infraestrutura e

os Servios de TI.

A lgica aparentemente contraditria entre as vises do mundo corporativo

e da nossa vida pessoal, onde um estimula e o outro repudia, certamente

est na sobreposio conceitual da palavra problema.

Esta pode ser a causa de algumas resistncias na adoo das prticas de

Gerenciamento de Problemas preconizadas pela ITIL. Em relao a outros

processos de Gerenciamento de Servios de TI, as prticas de

Gerenciamento de Problemas ainda so bastante subutilizadas, quanto aos

benefcios que se prope a trazer e sua prpria profissionalizao no

mercado de trabalho.

A proposta deste livro esclarecer todos os conceitos envolvidos no

processo de Gerenciamento de Problemas, destacar a importncia destas

prticas dentro do contexto geral do Gerenciamento de Servios de TI, com

exemplos prticos e vivncias pessoais do autor e, principalmente,

influenciar o seu uso nas organizaes de TI.

O contedo deste livro est dividido em quatro captulos, descritos a seguir:

Captulo 1 Introduo

Trata-se de um capitulo introdutrio, onde ser feita a contextualizao ldica

do processo de Gerenciamento de Problemas e os seus principais termos.

Alm disso, tambm traz informaes sobre as vantagens da adoo e

tambm as consequncias por no adota-lo.

Captulo 2 Conceitos Bsicos

Neste captulo, os conceitos fundamentais do Gerenciamento de Problemas

so reforados, para garantir um claro entendimento do contedo presente

nos captulos seguintes.

Ser trazida a tona as diferenas entre Incidentes e Problemas, o processo

de Gerenciamento de Problemas e a atividade de Anlise de Causa Raiz,

Modelos de Problema e a Base de Dados de Erros Conhecidos (BEC).

Captulo 3 - Anatomia do Processo de Gerenciamento de Problemas

Este captulo rene toda a teoria necessria para conhecer a fundo o processo

de Gerenciamento de Problemas, tais como: propsito, escopo, atividades,

principais papis e responsabilidades, mtricas e interfaces com outros

processos de Gerenciamento de Servios.

Ao final deste captulo, o leitor ter pleno conhecimento da estrutura do

processo de Gerenciamento de Problemas, e ser capaz de diferenciar seus

objetivos e termos quanto a outros processos de gerenciamento de servios,

particularmente o Gerenciamento de Incidentes.

Captulo 4 - Tcnicas de Determinao de Problemas

No basta saber o que fazer. Tambm preciso saber como.

Este captulo aborda as diversas tcnicas de determinao de problemas

disponveis e amplamente praticadas em diversos contextos de qualidade e

melhoria contnua, das mais simples s mais complexas. Algumas incluem

um roteiro passo a passo detalhado e um mapa de aplicabilidade das tcnicas

apresentadas para cenrios conhecidos.

Captulo 5 Implementao do processo de Gerenciamento de Problemas no

mundo real

No ltimo captulo, so apresentadas as principais questes que devem ser

consideradas para a implementao do processo de Gerenciamento de

Problemas de forma bem realista.

So apresentadas tambm as formas mais convencionais de realizao do

processo no dia a dia, tanto as reativas quanto proativas.

Alguns temas j conhecidos sero rediscutidos, enquanto outros, menos

populares, sero introduzidos, para que o leitor possa ter uma viso completa

e todo o embasamento necessrio para implementar prticas de

gerenciamento de servios de forma mais assertiva.

O contedo deste captulo consolida tanto experincias pessoais quanto

consensos gerais discutidos por profissionais especializados que lidam com

o Gerenciamento de Problemas na prtica. Alguns dos temas abordados

raramente sero encontrados em outras literaturas.

Neste eBook Srie 1, voc ter acesso aos captulos 1 (Introduo), 2

(Conceitos Bsicos) e 3 (Anatomia do processo). Os demais captulos

estaro disponveis na Srie 2 (Tcnicas) e na Srie 3 (Implementao).

Fique tranquilo, voc tambm receber a srie 2 e a srie 3

gratuitamente

Sumrio Prefcio

Apresentao

Sumrio

Captulo 1 Introduo

Contextualizao

Motivos para adotar o processo

Consequncias por no adotar o processo

Captulo 2 Conceitos Bsicos

Incidentes X Problemas

Gerenciamento de Problemas X Anlise de Causa Raiz

Modelos de Problema

Base de Dados de Erros Conhecidos (BEC)

Captulo 3 - Anatomia do Processo de Gerenciamento de Problemas

Propsito

Escopo

Atividades

Identificao do Problema

Registro do Problema

Categorizao do Problema

Priorizao do Problema

Investigao e Diagnstico do Problema

Desenvolvimento de Soluo de Contorno para o Problema

Registro de Erro Conhecido

Resoluo do Problema

Fechamento do Problema

Anlise Crtica de Problemas Graves

Entradas e Sadas/Interfaces

Papis e Responsabilidades

Gestor de Problemas

Analista de Problemas

Mtricas

Captulo 4 - Tcnicas de Determinao de Problemas

Anlise Cronolgica

Anlise de Valor do Impacto

Brainstorming (tempestade de ideias)

Diagrama de Afinidade

5 porqus

Teste de Hipteses

Posto de Observao Tcnica

Diagrama de Ishikawa (espinha de peixe)

Kepner-Tregoe

Anlise de Pareto

Matriz do /NO

Mapa de Aplicabilidade

Captulo 5 - Implementao do processo de Gerenciamento de Problemas no

mundo real

Prticas de Gesto de Projetos: por que usar?

Abordagens proativas e reativas

O caminho natural da maturidade

Implementao orgnica

Requisitos mnimos

Critrios de Identificao de Problemas

Base de Dados de Erros Conhecidos (BDEC)

Estruturas funcionais

Perfil do profissional de Gerenciamento de Problemas

Prazos (SLA)

Critrios de avaliao para ferramentas

Relatos de Servio e Melhoria Contnua

Desafios mais comuns

Riscos mais comuns

Glossrio

Captulo 1 Introduo

Contextualizao

Para entender melhor o contexto do Gerenciamento de Problemas, vamos

refletir sobre uma situao bem cotidiana:

Quando contramos uma gripe, um resfriado ou alguma outra doena mais

sria, ns sofremos reaes, como tosse, febre, vmito, dores de cabea, etc.

So sintomas que apresentamos quando nosso organismo no est

funcionando como deveria, e que podem prejudicar a nossa sade e as nossas

atividades rotineiras de alguma forma.

De acordo com a frequncia e a gravidade dos sintomas, muitas vezes

necessrio buscar a sua causa, para assim poder combater a origem, evitar

a recorrncia ou consequncias mais graves. Nestes casos, normalmente

procuramos um mdico especialista e somos submetidos a uma srie de

exames e diagnsticos.

Quando finalmente a causa do(s) sintoma(s) identificada, temos duas

possibilidades:

1. Tratar a causa de forma definitiva (antibitico, cirurgia, etc.);

2. Quando o tratamento definitivo da causa no possvel, como uma

doena sem cura, ou mesmo quando o tratamento no seja vivel, os

sintomas podem ser aliviados ou controlados atravs de solues

temporrias (medicamentos, terapia, etc.) que so indicadas pelo

mdico especialista.

No contexto da infraestrutura e dos Servios de TI tambm funciona assim.

A diferena que os sintomas so as falhas que ocorrem na operao normal

de um servio de TI (ex.: uma aplicao apresentando erro, internet lenta,

um e-mail que no sai da caixa de sada). Com isso, podemos chegar ao

consenso de que um incidente nada mais do que um sintoma.

causa no identificada de um ou vrios incidentes (sintomas, falhas), d-

se o nome de Problema.

J causa conhecida de um problema e com ao menos uma soluo de

contorno associada, d-se o nome de Erro Conhecido. Portanto, causa raiz

conhecida associada a uma soluo de contorno/temporria igual a um Erro

Conhecido.

Motivos para adotar o processo

Existem vrias possveis justificativas para se adotar o processo de

Gerenciamento de Problemas, tais como:

Maiores nveis de disponibilidade dos servios, ao reduzir o nmero e

a durao dos incidentes. (e sabemos que a disponibilidade tem um

reflexo direto na satisfao dos clientes).

Aumento da produtividade das equipes de TI ao reduzir trabalhos no

planejados causados por incidentes. Com isso as equipes de suporte

aos servios vo poder alocar um tempo maior em projetos de

melhoria, inovao, e outras aes que tragam mais benefcios ao

negcio.

Aumento da eficcia e da rapidez no tratamento dos incidentes ao

manter uma base de problemas e Erros Conhecidos, assim como de

suas respectivas solues de contorno. Com isso, tambm se evita o

acionamento de grupos de suporte especializados (comumente

conhecidos como suporte de segundo ou terceiro nvel) para o

atendimento de casos simples, cuja soluo apropriada desconhecida

pelo Service Desk (ou Central de Servios).

Reduo dos gastos com solues de contorno ou correes ineficazes;

uma vez que tais solues de contorno sero, na maior parte dos

casos, desenvolvidas e, principalmente, validadas por especialistas.

Reduo do custo e do esforo para tratar incidentes que se repetem.

Com a diminuio da quantidade de incidentes (que s acontece com um bom

processo de Gerenciamento de Problemas), possvel sair do status de TI

reativa - aquela focada em apagar incndios para uma TI proativa, focada

em inovao e melhorias.

Consequncias por no adotar o processo

Olhando o outro lado da moeda: quais seriam as possveis consequncias de

no adotar este processo? Seguem alguns exemplos:

Potencializao da insatisfao dos clientes e usurios, uma vez que a

recorrncia de incidentes causa mais insatisfao do que os prprios

incidentes.

Isto fato. Quando nos colocamos no papel de clientes de servios (de

qualquer tipo de servio), uma falha causa certo incmodo, mas falhas

consecutivas so inconcebveis.

Reduo da produtividade das equipes de suporte, o que aumenta os

custos para a TI e para a empresa.

As equipes tero retrabalho pra resolver os mesmos incidentes vrias

vezes e sero envolvidas com maior frequncia devido falta de uma

base de conhecimento consistente para o Service Desk. Tudo isso

custo!

Aumento da indisponibilidade dos servios, uma vez que a causa raiz

das indisponibilidades no investigada. Ou seja, vai acontecer de

novo!

Exposio da empresa aos riscos e falhas potenciais j conhecidas no

mercado, impactando sua imagem.

Captulo 2 Conceitos Bsicos

Incidentes X Problemas

comum que o propsito do processo de Gerenciamento de Problemas seja

confundido com o propsito do processo de Gerenciamento de Incidentes.

O Gerenciamento de Incidentes se preocupa em resolver uma situao o mais

rpido possvel, enquanto o Gerenciamento de Problemas se preocupa em

identificar a causa fundamental e propor solues estruturadas para a

situao.

Veja a seguir a figura 1:

Figura 1

Ao lado direito da figura, a equipe de policiais est preocupada em resolver

uma situao de perigo o mais rpido possvel para que no ocorra nenhuma

perda significativa (vtimas). Eles no esto preocupados em saber quais as

circunstncias da situao, nem quais os motivos.

Ao lado esquerdo da figura, os peritos se preocupam em realizar uma srie

de investigaes, atravs do uso de diferentes tcnicas, para que assim que

a causa raiz for identificada as aes apropriadas sejam tomadas e novas

ocorrncias sejam evitadas. Eles querem saber o que motivou a situao, e

garantir que esta situao no ocorra novamente, j que foi no possvel

evit-la.

Recentemente houve um atentado terrorista durante uma maratona em

Boston, nos Estados Unidos. Apesar dos esforos constantes do FBI e da CIA

em prever atentados terroristas, no foi possvel evitar este atentado

especfico.

Desta forma, uma concluso qual podemos chegar que a proatividade no

uma tarefa to simples, no importa o contexto.

Gerenciamento de Problemas X Anlise de Causa Raiz

importante esclarecer a diferena entre o processo popularmente conhecido

como "Anlise de Causa Raiz" (RCA, ou Root Cause Analysis) e o processo

referenciado pela ITIL como Gerenciamento de Problemas. O que os

diferencia so os seus objetivos.

Ambos os processos utilizam as tendncias e a anlise de dados relacionados

a incidentes e mudanas mal sucedidas para determinar a causa raiz.

Tambm est prevista nos dois processos a realizao de reunies com

especialistas no assunto para discutir a provvel causa. E, alm disso, ambos

tambm so responsveis por gerar um relatrio detalhado com base nas

concluses e distribuir para as partes interessadas (stakeholders).

neste ponto que o processo de anlise de causa raiz termina e o processo

de Gerenciamento de Problemas continua.

O objetivo do processo de analise de causa raiz entender o que deu errado

e relatar com preciso o impacto do incidente ou da mudana mal sucedida

para que os resultados sejam compreendidos e que um incidente semelhante

possa ser evitado no futuro.

Outra caracterstica que, na maioria das organizaes, o processo de analise

de causa raiz tem foco apenas nas questes realmente grandes e

embaraosas.

O Gerenciamento de Problemas, por outro lado, est interessado nas

tendncias de problemas e Erros Conhecidos de tamanhos variados e no se

contenta somente com a simples identificao da causa raiz de um incidente

grave, mas tambm com a identificao de recorrncias sistmicas que

podem no parecer to significativas quando vistas isoladamente, mas que,

quando consideradas em conjunto - como um padro de repetio, por

exemplo - representam um impacto considervel na disponibilidade e na

confiabilidade do servio.

Por fim, a diferena mais marcante entre o processo de analise de causa raiz

e o Gerenciamento de Problemas que a Anlise de Causa Raiz (Root Cause

Analysis) focada principalmente na identificao e elaborao de relatrios.

Enquanto o Gerenciamento de Problemas tem como objetivo final a

eliminao desses problemas sistmicos de uma vez por todas, com a

finalidade de melhorar a disponibilidade e confiabilidade dos servios e do

prprio gerenciamento de servios.

Modelos de Problema

Muitos problemas podem realmente ter uma caracterstica bastante

exclusiva, e por isso precisam ser tratados de uma maneira especifica, mas

pertinente considerar que alguns incidentes possam reincidir devido a

problemas, digamos, inativos (ou esquecidos) por muito tempo, ou

problemas onde a soluo definitiva no justificvel em termos financeiros.

Os modelos de problema podem facilitar o tratamento do problema, atravs

de uma srie de passos predefinidos, padronizados e, eventualmente,

automatizados.

Contudo, os modelos de problema no traro respostas de como resolver um

problema (nem de forma definitiva e nem paliativa). Quem traz essa

informao o Erro Conhecido.

A seguir, so relacionados alguns elementos que devem ser levados em

considerao na criao de um modelo de problema:

1. Os passos e a ordem cronolgica de execuo dos passos;

2. As responsabilidades, ou seja, quem vai fazer o qu;

3. Os prazos acordados;

4. Os procedimentos de escalonamento (quando os prazos acordados

forem atingidos, por exemplo);

5. As atividades de preservao de evidncias.

Normalmente, as evidncias que podem ajudar a futura investigao da causa

raiz so perdidas durante o tratamento do incidente; por este motivo a

preservao de evidncias um elemento muito importante.

Segue um exemplo clssico relativo ao uso desta boa prtica: em um servidor

que precisa ser reiniciado, as equipes tcnicas normalmente no se

preocupam em obter o arquivo de log antes de reiniciar o servidor.

O que ocorre que, depois que estes arquivos de log so perdidos, fica mais

difcil fazer o diagnstico e, consequentemente, identificar a causa raiz. Por

isso, vale a pena gastar algum tempo a mais para preservar evidncias que

sero preciosas em uma futura investigao e determinao do problema, e

que consequentemente ajudaro na soluo definitiva do problema,

concorda?

Base de Dados de Erros Conhecidos (BEC)

muito importante que os Erros Conhecidos sejam armazenados em uma

Base de Dados de Erros Conhecidos, ou seja, uma base onde armazenado

todo conhecimento prvio sobre incidentes e problemas.

Normalmente, um registro de Erro Conhecido deve incluir: a descrio do

erro, os sintomas, a soluo de contorno ou a resoluo definitiva.

Dependendo da ferramenta utilizada, pode ser possvel associar os incidentes

de forma mais prtica, criando um contador. Isso facilita o Gerenciamento de

Problemas, pois possvel ter uma viso rpida e clara dos problemas que

esto gerando o maior nmero de incidentes.

Existem algumas outras questes importantes a serem esclarecidas quando

o assunto Base de Dados de Erros Conhecidos. O primeiro erro comum

confundir a Base de Dados de Erros Conhecidos com a Base de Conhecimento.

Base de Conhecimento X Base de Dados de Erro Conhecido

A Base de Conhecimento se refere a todo conhecimento da organizao, e vai

muito alm das informaes de incidentes e problemas. A Base de Dados de

Erros Conhecidos traz apenas conhecimento sobre incidentes e problemas.

Em outras palavras, como se a Base de Dados de Erros Conhecidos fosse

um pedao ou subconjunto da base de conhecimento da organizao.

Captulo 3 - Anatomia do Processo de Gerenciamento

de Problemas

Propsito

O processo de Gerenciamento de Problemas se preocupa em gerenciar o ciclo

de vida de todos os problemas, desde sua identificao inicial at sua

eventual remoo, passando pela sua investigao e documentao. Ele tem

trs objetivos muito importantes:

1. Evitar problemas e seus incidentes resultantes;

2. Eliminar ou reduzir a recorrncia de incidentes;

3. Minimizar o impacto dos incidentes que no podem ser evitados.

Para atingir estes objetivos, o Gerenciamento de Problemas busca a causa

raiz dos incidentes, documenta e comunica Erros Conhecidos e inicia aes

para melhorar ou corrigir a situao.

Escopo

O escopo do Gerenciamento de Problemas focado em dois aspectos:

1. Problemas que esto causando ou j causaram incidentes (conhecido

como gerenciamento reativo de problemas)

2. Problemas potenciais que podero causar impactos no, se no forem

diagnosticados e tratados a tempo (conhecido como gerenciamento

proativo de problemas).

Nota:

Tanto o processo de Gerenciamento de Problemas quanto suas tcnicas so

perfeitamente aplicveis em problemas de qualquer natureza como apoio aos

ciclos de melhoria contnua. Neste caso, haver outros possveis

desencadeadores do processo.

Por exemplo, dentro do contexto de um Sistema de Gerenciamento de

Servios (conceito fundamentado em normas como a ISO/IEC20000),

qualquer no conformidade em relao aos seus requisitos, como uma

reclamao do usurio ou um nvel de servio no cumprido, poderia ser

tambm um desencadeador do processo de Gerenciamento de Problemas,

alm dos tradicionais incidentes.

Atividades

Nas prximas sees sero apresentados os detalhes de cada uma das

atividades propostas pelo processo de Gerenciamento de Problemas.

Identificao do Problema

Diferentemente do Gerenciamento de Incidentes, que busca restaurar a

operao normal do servio o mais rpido possvel, o Gerenciamento de

Problemas busca identificar os erros ou as condies que esto causando ou

podem vir a causar incidentes, propondo solues para tais situaes.

A deteco de problemas pode ocorrer de forma proativa, ou seja, antes que

um incidente ocorra ou de forma reativa, quando um ou mais incidentes j

ocorreram. Essa uma atividade importantssima, e um dos segredos de um

processo bem sucedido de Gerenciamento de Problemas.

Algumas possibilidades de identificao reativa de problemas podem ser:

1. Suspeita ou deteco pelo Service Desk

2. Anlise de um (ou mais) incidente(s) pelo grupo de suporte tcnico.

Seja devido ao seu alto impacto no negcio ou na operao, ou

sua taxa de recorrncia.

E um problema tambm pode ser identificado antecipadamente, ou de forma

proativa:

1. Atravs da deteco automatizada de um erro da infraestrutura ou

aplicao (isso pode ser feito atravs de ferramentas de

monitorao de eventos, por exemplo).

2. Pela notificao de um fornecedor. (um exemplo clssico so os

hotfixes que a Microsoft disponibiliza via Windows Update. So

problemas que a prpria Microsoft identifica, investiga, e tambm j

disponibiliza a correo).

3. Atravs da anlise regular de tendncias, ou seja, da evoluo de

algum determinado indicador de desempenho ao longo do tempo

(srie histrica).

Registro do Problema

Independentemente da forma de deteco (reativa ou proativa), todos os

detalhes do problema devem ser registrados. Isto inclui: sintomas

reportados, detalhes dos usurios, detalhes dos servios, detalhes dos

equipamentos ou sistemas, detalhes das localidades, sequncia dos fatos,

aes tomadas, etc.

importante registrar todos os dados relevantes, que podero ser utilizados

durante a investigao e diagnstico. Uma boa forma de registrar o histrico

completo do problema fazendo referncias aos incidentes causados por ele

A data e a hora tambm so importantes, para que seja possvel controlar a

"idade" deste problema, e eventualmente usar o escalonamento para

prioriz-lo.

Categorizao do Problema

Para facilitar as anlises, as pesquisas e a comparao com os incidentes, os

problemas podem ser categorizados usando o mesmo sistema de categorias

usado para os incidentes. Isto ajuda a organizar a base de conhecimento e a

relacionar os incidentes aos problemas.

Alm disso, uma boa categorizao vai permitir o correto envolvimento dos

grupos de suporte no tratamento do problema, e que dados confiveis sejam

gerados para anlise estatstica e de tendncias de problemas. .

Priorizao do Problema

O Gerenciamento de Problemas considera a priorizao da mesma forma que

o Gerenciamento de Incidentes, ou seja, atravs da relao entre impacto e

urgncia. Alm disso, o Gerenciamento de Problemas tambm pode

considerar a severidade (na perspectiva da infraestrutura) como um

ingrediente adicional na priorizao de um Problema.

Algumas perguntas que podem determinar a severidade de um problema so:

1. O sistema pode ser recuperado, ou precisa ser substitudo?

2. Quanto ir custar?

3. Quantas pessoas, com quais competncias, sero necessrias para

corrigir o problema?

4. Quanto tempo vai demorar a resolver o problema?

5. Qual a extenso do problema (ex. quantos componentes do

servio foram afetados)?

O impacto est relacionado extenso do dano potencial (no caso de

deteco proativa) ou do dano real (no caso de deteco reativa) relacionado

com o problema. O impacto pode estar associado, por exemplo:

quantidade de usurios impactados

Ao tipo e quantidade de servios impactados

Ao nvel de indisponibilidade do servio ou do sistema;

s perdas financeiras;

Aos danos imagem da organizao;

gravidade da violao a leis e regulamentos.

A urgncia est relacionada ao tempo que o usurio ou o negcio tolera

esperar pela soluo do problema. Ela pode ser maior ou menor, dependendo

do momento em que o problema foi detectado, e das pessoas que podero

ser impactadas caso o problema cause um incidente.

No momento da priorizao dos problemas, as equipes tambm podem fazer

uma avaliao inicial da severidade do problema, ou seja, da extenso ou

complexidade do problema nas perspectivas tcnica e financeira. Esta

avaliao deve ser posteriormente refinada durante a atividade de

investigao e diagnstico.

Investigao e Diagnstico do Problema

A atividade de investigao e diagnstico do problema consiste em

diagnosticar a causa raiz do problema e propor uma soluo. Existem vrias

tcnicas que podem ser usadas para diagnosticar e resolver problemas, e que

sero apresentadas com detalhes mais adiante, em um captulo especfico.

Durante a atividade de investigao e diagnstico, as informaes de

configurao devem ser utilizadas para avaliar de forma mais profunda o

impacto e a severidade do problema. As informaes de Erros Conhecidos

devem ser pesquisadas para verificar se o problema j ocorreu anteriormente

e, caso positivo, qual foi a soluo.

Tambm pode ser necessrio tentar recriar o problema em um ambiente de

laboratrio, ou testar vrias solues para encontrar a mais apropriada ou

econmica.

Desenvolvimento de Soluo de Contorno para o Problema

Em alguns casos necessrio (e possvel) encontrar uma soluo de contorno

para os incidentes causados por um problema. Geralmente so solues

temporrias ou alternativas que no resolvem o problema, mas minimizam o

impacto dos incidentes ou ajudam os usurios a superarem as dificuldades.

Em muitos casos, tais solues so encontradas pelo processo de

Gerenciamento de Incidentes na sua tentativa de restaurar o servio o mais

rpido possvel. Quando isto acontece, o processo de Gerenciamento de

Problemas responsvel por testar e validar tais solues de contorno,

documentando-as no registro do problema ou no registro do Erro Conhecido.

Esta validao importante, pois algumas solues de contorno podem ter

efeitos colaterais mais nocivos do que o impacto do prprio incidente e,

portanto, no devem ser aplicadas.

A existncia de solues de contorno diminui a urgncia na soluo do

problema - seja reduzindo a probabilidade de ocorrncia de novos incidentes

relacionados, seja aumentando a velocidade do tratamento desses

incidentes.

Quando uma nova soluo de contorno desenvolvida ou validada,

recomendvel que ela seja imediatamente documentada no registro de

problema e disponibilizada para o Service Desk e para o processo de

Gerenciamento de Incidentes.

Registro de Erro Conhecido

Os Erros Conhecidos permitem que futuros incidentes e problemas sejam

identificados e tratados de forma mais rpida. Por esta razo, os Erros

Conhecidos devem ser imediatamente documentados e disponibilizados para

o Service Desk e para o processo de Gerenciamento de Incidentes.

bom lembrar que um Erro Conhecido somente pode ser caracterizado como

tal quando o diagnstico for concludo e uma soluo de contorno for

encontrada.

Resoluo do Problema

Quando a soluo envolve a adio, modificao ou remoo de qualquer

coisa que possa ter um efeito nos servios de TI, sua aplicao s pode ser

feita aps a aprovao de uma Requisio de Mudana pelo processo de

Gerenciamento de Mudanas. Nos casos em que a soluo do problema deve

ser imediata, deve-se seguir o processo de Mudana Emergencial. Nos casos

em que a soluo proposta no for autorizada pelo Gerenciamento de

Mudanas, o problema deve ser novamente priorizado e uma nova soluo

deve ser buscada.

Entretanto, h casos em que a soluo do problema no justificvel na

perspectiva do negcio (por exemplo, quando o impacto do problema

limitado, mas o custo de sua soluo muito alto). Nestes casos, o registro

do problema deve ser mantido aberto. Porem, tais casos no devem ser

contabilizados contra o desempenho do processo de Gerenciamento de

Problemas e o registro do problema deve permanecer aberto apenas para

evitar um possvel retrabalho sobre o mesmo problema.

Fechamento do Problema

Quando a soluo do problema aplicada, necessrio confirmar a eficcia

da soluo, podendo-se consultar o Service Desk, os grupos de suporte e os

usurios do servio.

Neste momento o registro do problema tambm deve ser verificado e, se

necessrio, atualizado, para garantir que todo o histrico do problema tenha

sido documentado. Os incidentes relacionados ao problema tambm j

podem ser fechados (algumas ferramentas fazem isto automaticamente).

Anlise Crtica de Problemas Graves

Aps a soluo de um problema Grave, altamente recomendvel promover

uma reunio com pessoas chave do Service Desk e grupos de suporte para

realizar uma anlise crtica e reviso do problema e para documentar lies

aprendidas. A discusso pode incluir:

1. As aes que foram feitas corretamente

2. As aes que no deram certo

3. O que poderia ser feito melhor no futuro

4. Como prevenir recorrncia

5. Se houve responsabilizao de terceiros

6. Se h necessidade de aes de acompanhamento

O propsito desta reunio no buscar culpados, mas sim aproveitar ao

mximo possvel a experincia adquirida durante o diagnstico e soluo do

problema. As lies aprendidas devem servir como base para a criao ou

atualizao de processos, procedimentos, polticas, instrues de trabalho ou

registros de Erros Conhecidos, etc.

Esta reunio tambm pode ser fonte para a deteco proativa de problemas.

Os resultados desta reviso podem ser comunicados a pessoas chave da

empresa como forma de demonstrar que os incidentes e problemas graves

esto sendo tratados de forma responsvel e a TI est ativamente

trabalhando para prevenir futuras recorrncias.

Entradas e Sadas/Interfaces

A figura 2 mostra as principais interfaces do processo de Gerenciamento de

Problemas com outros processos de Gerenciamento de Servios

Figura 2

Os itens que esto mais prximos do processo de Gerenciamento de

Problemas so as entradas para o processo. Os itens que esto mais prximos

dos outros processos so as sadas (produtos, entregveis) do processo.

Papis e Responsabilidades

A seguir, uma lista com as principais responsabilidades do Gestor e do

Analista de Problemas.

Este assunto ser incrementado nos prximos captulos do livro, com

consideraes adicionais sobre o perfil atual e desejvel dos profissionais

envolvidos com o Gerenciamento de Problemas.

Gestor de Problemas

As atividades e responsabilidades mais comuns do Gestor de Problemas so:

Desenvolver fluxos de problema.

Trabalhar com outros gestores de processo para assegurar uma

abordagem integrada.

Planejar, gerenciar e dar suporte ao processo e ferramentas de apoio

ao processo.

Coordenar interfaces com outros processos de gerenciamento de

servio.

Manter contato com todos os grupos de resoluo de problemas para

assegurar uma rpida resoluo de problemas dentro das metas

estabelecidas em acordos de nvel de servio (SLA).

Ser responsvel pela Base de Dados de Erro Conhecido.

Garantir o fechamento adequado de todos os registros de problemas.

Manter contato com fornecedores, contratantes, etc. para assegurar

que terceiros cumpram suas obrigaes contratuais, especialmente

com relao a resolver problemas e prover informaes e dados

relacionados a problemas. Arranjar, executar, documentar e

acompanhar atividades relacionadas anlise crtica de problemas

Graves.

Analista de Problemas

As atividades e responsabilidades mais comuns do Analista de Problemas so:

Resolver problemas

Analisar problemas para correta priorizao e classificao

Investigar problemas at a resoluo ou causa raiz

Coordenar aes de outros (se necessrio) para auxiliar a anlise e

resoluo de problemas e Erros Conhecidos.

Registrar Requisies de Mudanas para resolver problemas.

Monitorar o progresso da resoluo de Erros Conhecidos aconselhando

a equipe de gerenciamento de incidentes sobre as melhores solues

de contorno disponveis.

Atualizar a Base de Dados de Erro Conhecido

Auxiliar o tratamento de incidentes graves e identificar as suas causas.

natural que em um primeiro momento as organizaes no queiram fazer

grandes investimentos em uma equipe exclusiva para lidar com o processo

de Gerenciamento de Problemas, principalmente a figura do Gestor de

Problemas. Uma das possibilidades neste caso trabalhar com equipes

multidisciplinares.

Por exemplo, um recurso da rea de qualidade poderia assumir tambm o

papel de Gestor de Problemas, pois h uma grande similaridade entre as

atividades (desenho e modelagem de processos, controle de qualidade,

tcnicas de melhoria contnua, etc.).

Mtricas

importante que as mtricas sejam desenvolvidas para atender a um

proposito, uma meta, um Fator Crtico de Sucesso.

Em outras palavras, Fator Crtico de Sucesso (FCS) algo que deve acontecer

num Processo, Projeto, Plano ou Servio de TI para que o mesmo tenha

sucesso. Os Indicadores de Desempenhos so usados para medir se os

Fatores Crticos de Sucesso foram alcanados.

A Figura 3 mostra quais resultados so importantes para que o processo de

Gerenciamento de Problemas seja bem sucedido (FCS) e quais so os

indicadores que iro demonstrar se estes resultados esto sendo atingidos

(Indicadores de Desempenho).

Cuidado com os exageros. Em um processo de implementao inicial do

Gerenciamento de Problemas recomendvel utilizar no mximo trs

indicadores. Tambm vale lembrar que nenhum indicador tem relevncia se

no houver uma meta associada a ele (Ex.: 90% dos problemas registrados

no perodo devem ser resolvidos em at X dias/horas).

Figura 3

Concluso

Na prxima srie, voc conhecer as principais ferramentas utilizadas para

determinao de problemas e como utiliza-las.

Glossrio

Todos os termos, definies e acrnimos utilizados neste livro podem ser

consultados na ltima verso disponvel do glossrio oficial da biblioteca ITIL

no endereo:

http://www.itil-officialsite.com/InternationalActivities/ITILGlossaries_2.aspx

Sobre a COMMUNIT

A COMMUNIT uma empresa de treinamentos em TI e Gesto com mtodos de ensino que

aumentam o engajamento e a absoro de contedo.

Acreditamos que todas as pessoas so capazes do que quiserem fazer e tem total potencial para

isso. Nosso maior objetivo provocar mudanas positivas na vida dos nossos clientes atravs

da capacitao, estimulando-os a liberarem todo seu potencial. Para ns, tudo uma questo

de prtica.

Para acessar mais materiais gratuitos ou saber mais sobre a COMMUNIT, acesse o site:

www.communit.com.br

Sobre o Autor

Ren Chiari formado em Gesto de Ambiente Internet e Redes de

Computadores, possui as certificaes ITIL Service Manager, ITIL Expert,

ISO/IEC 20000 Associate/Consultant e COBIT 4.1.

Trabalha h mais de treze anos na rea de TI, sendo os ltimos oito anos

com Gerenciamento de Servios de TI. Ao longo de sua carreira profissional,

passou por grandes corporaes do ramo de Tecnologia de da Informao e

consultorias especializadas, atuando como consultor e instrutor em dezenas

de projetos.

Entusiasta do assunto Gerenciamento de Servios de TI, um dos fundadores

do ITSM na Prtica (antigamente conhecido como ITIL na Prtica),

considerada como uma das maiores referncias sobre a temtica no Brasil.

Publicou mais de 50 artigos, alguns deles sendo republicados em outros

veculos de comunicao, como os portais iMasters, ITweb e Administradores.

Alm disso, o autor mantm um grupo de discusso ITSM na Prtica na rede

Linkedin, que j assumiu destaque como o maior grupo sobre o tema em

lngua portuguesa da rede.

O currculo completo do autor pode ser consultado pelo Linkedin no endereo

br.linkedin.com/in/renechiari