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
Top Related