Cms Files 2206 1394648288EBOOK+ +GPRO

02
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 profssionais de Gerenciamento de Ser-
vios de TI. Como apoio so usadas referncias de outros
materiais sem infringir direitos autorais de terceiros.
03
Dedico este livro especialmente a minha esposa Renata
e ao meu cachorro e fel companheiro Tomas. Sem o apoio e
a pacincia deles esta obra no teria sido possvel.
Este livro tambm dedicado aos amigos e profssionais
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 Proble-
mas e o desenvolvimento desta obra.
04
I TI L
NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

PREFCIO 06
APRESENTAO 08
CAPTULO 1
INTRODUO 10
Contextualizao 10
Motivos para adotar o processo 10
Consequncias por no adotar o processo 11
CAPTULO 2
CONCEITOS BSICOS 12
Incidentes X Problemas 12
Gerenciamento de Problemas X Anlise de Causa Raiz 12
Modelos de Problema 13
Base de Dados de Erros Conhecidos (BDEC) 14
CAPTULO 3
ANATOMIA DO PROCESSO DE GERENCIAMENTO DE PROBLEMAS 15
Propsito 15
Escopo 15
Atividades 15
Identifcao do Problema 15
Registro do Problema 16
Categorizao do Problema 16
Priorizao do Problema 16
Investigao e Diagnstico do Problema 17
Desenvolvimento de Soluo de Contorno para o Problema 17
Registro de Erro Conhecido 18
Resoluo do Problema 18
Fechamento do Problema 18
Anlise Crtica de Problemas Graves 18
Entradas e Sadas/Interfaces 19
Papis e Responsabilidades 20
Gestor de Problemas 20
Analista de Problemas 20
Mtricas 21
CAPTULO 4
TCNICAS DE DETERMINAO DE PROBLEMAS 22
Anlise Cronolgica 22
Anlise de Valor do Impacto 22
Brainstorming (tempestade de ideias) 23
Diagrama de Afnidade 25
5 porqus 26
Teste de Hipteses 26
Posto de Observao Tcnica 27
Diagrama de Ishikawa (espinha de peixe) 27
Kepner-Tregoe 29
NDICE
05
I TI L

CAPTULO 5
IMPLEMENTAO DO PROCESSO
DE GERENCIAMENTO DE PROBLEMAS NO MUNDO REAL 34
Prticas de Gesto de Projetos: por que usar? 34
Abordagens proativas e reativas 34
O caminho natural da maturidade 37
Implementao orgnica 38
Requisitos mnimos 39
Critrios de Identifcao de Problemas 39
Base de Dados de Erros Conhecidos (BDEC) 40
Estruturas funcionais 41
Perfl do profssional de Gerenciamento de Problemas 42
Prazos (SLA) 43
Critrios de avaliao para ferramentas 43
Relatos de Servio e Melhoria Contnua 44
Desafos mais comuns 45
Riscos mais comuns 45
GLOSSRIO 46
SOBRE O AUTOR 47
NDICE
06
I TI L

Quantas vezes j nos deparamos com situaes (na maioria das vezes indesejveis) que cau-
sam impactos signifcativos 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 identifcar formas de resolv-las.
Fazendo uma leve retrospectiva at os anos aps a 2 Guerra Mundial, podemos ver o surgi-
mento 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 ferra-
menta 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 al-
canar, maximizar a manter de forma sustentvel o sucesso de uma organizao, baseada em um
sistema abrangente e fexvel envolvendo elementos como a compreenso precisa das necessi-
dades (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:
Defnir (os objetivos de melhoria), Medir (a situao atual), Analisar (as medies e identifcar as
reais causas da situao atual), Melhorar (ou seja, desenvolver ideias e aplicar solues para solu-
cionar 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 especfcos. Entre esses modelos, faz-se necessrio destacar aqui, especifcamen-
te, a ITIL
, ou Information Technology Infrastructure Library, uma biblioteca de melhores prticas

para a disciplina de Gerenciamento de Servios (de TI).
Na ITIL
, podemos identifcar claramente uma conexo entre os cenrios que os princpios da

Qualidade Total e do Seis Sigma identifcavam como oportunidades de melhoria de processos, e
aquelas situaes indesejveis, recorrentes e sem causa defnida que mencionei no primeiro par-
grafo deste prefcio.
A essas situaes, a ITIL
deu o nome de PROBLEMAS e defniu um processo especialmente

destinado a gerenci-los. Segundo este processo, um problema deve ser devidamente detectado,
classifcado, ter seu impacto avaliado, priorizado, investigado at a descoberta de sua causa raiz e
resolvido por meio de uma soluo de contorno ou (preferencialmente) defnitiva, 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 dis-
ciplina de Gerenciamento de Servios, uma vez que engloba todo o contexto e o esprito de me-
PREFCIO
07
I TI L

lhoria 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 profssional 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 par-

ticipado 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 profssionais de TI (ou melhor, de servios) no mer-
cado 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
PREFCIO
08
I TI L

Problemas. Ningum gosta. Ningum quer. Seja na vida pessoal ou no mundo corporativo.
Em geral, os problemas so defnidos como algo indesejvel. A convivncia frequente com
problemas nos expe ao caminho oposto a uma vida saudvel. Seja como for, a convivncia cont-
nua 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 ativi-
dades 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 pa-
lavra 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 profssionalizao no mercado de trabalho.
A proposta deste livro esclarecer todos os conceitos envolvidos no processo de Gerencia-
mento de Problemas, destacar a importncia destas prticas dentro do contexto geral do Geren-
ciamento de Servios de TI, com exemplos prticos e vivncias pessoais do autor e, principalmen-
te, infuenciar 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 adot-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 fnal 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.
APRESENTAO
09
I TI L

Captulo 4 - Tcnicas
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 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 profssionais especializados que lidam com o Gerenciamento de Problemas
na prtica. Alguns dos temas abordados raramente sero encontrados em outras literaturas.
APRESENTAO
10
I TI L

INTRODUO
Contextualizao
Para entender melhor o contexto do Gerenciamento de Problemas, vamos refetir 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 gra-
ves. Nestes casos, normalmente procuramos um mdico especialista e somos submetidos a uma
srie de exames e diagnsticos.
Quando fnalmente a causa do(s) sintoma(s) identifcada, temos duas possibilidades:
1. Tratar a causa de forma defnitiva (antibitico, cirurgia, etc.);
2. Quando o tratamento defnitivo 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 identifcada 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 con-
torno/temporria igual a um Erro Conhecido.
Motivos para adotar o processo
Existem vrias possveis justifcativas para se adotar o processo de Gerenciamento de Proble-
mas, tais como:
Maiores nveis de disponibilidade dos servios, ao reduzir o nmero e a durao dos incidentes
(e sabemos que a disponibilidade tem um refexo 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.
CAPTULO 1
11
I TI L

Aumento da efccia 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 inefcazes; 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 1
12
I TI L

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 identifcar a causa fundamental e pro-
por solues estruturadas para a situao.
Veja a seguir a fgura 1:
CAPTULO 2
Figura 1
Ao lado direito da fgura, a equipe de policiais est preocupada em resolver uma situao de
perigo o mais rpido possvel para que no ocorra nenhuma perda signifcativa (vtimas). Eles no
esto preocupados em saber quais as circunstncias da situao, nem quais os motivos.
Ao lado esquerdo da fgura, os peritos se preocupam em realizar uma srie de investigaes,
atravs do uso de diferentes tcnicas, para que assim que a causa raiz for identifcada 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 especfco.
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 Gerencia-
mento de Problemas. O que os diferencia so os seus objetivos.
13
I TI L

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 dis-
tribuir 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 com-
preendidos 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 identifcao
da causa raiz de um incidente grave, mas tambm com a identifcao de recorrncias sistmicas
que podem no parecer to signifcativas quando vistas isoladamente, mas que, quando consi-
deradas em conjunto - como um padro de repetio, por exemplo - representam um impacto
considervel na disponibilidade e na confabilidade do servio.
Por fm, a diferena mais marcante entre o processo de analise de causa raiz e o Gerenciamen-
to de Problemas que a Anlise de Causa Raiz (Root Cause Analysis) focada principalmente na
identifcao e elaborao de relatrios. Enquanto o Gerenciamento de Problemas tem como ob-
jetivo fnal a eliminao desses problemas sistmicos de uma vez por todas, com a fnalidade de
melhorar a disponibilidade e confabilidade dos servios e do prprio gerenciamento de servios.
Modelos de Problema
Muitos problemas podem realmente ter uma caracterstica bastante exclusiva, e por isso pre-
cisam ser tratados de uma maneira especifca, mas pertinente considerar que alguns incidentes
possam reincidir devido a problemas, digamos, inativos (ou esquecidos) por muito tempo, ou pro-
blemas onde a soluo defnitiva no justifcvel em termos fnanceiros.
Os modelos de problema podem facilitar o tratamento do problema, atravs de uma srie de
passos predefnidos, padronizados e, eventualmente, automatizados.
Contudo, os modelos de problema no traro respostas de como resolver um problema (nem
de forma defnitiva e nem paliativa). Quem traz essa informao o Erro Conhecido.
A seguir, so relacionados alguns elementos que devem ser levados em considerao na cria-
o 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;
CAPTULO 2
14
I TI L

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 per-
didas durante o tratamento do incidente; por este motivo a preservao de evidncias um ele-
mento 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, fca mais difcil fazer o diag-
nstico e, consequentemente, identifcar 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 defnitiva do problema, concorda?
Base de Dados de Erros Conhecidos (BDEC)
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 inci-
dentes e problemas.
Normalmente, um registro de Erro Conhecido deve incluir: a descrio do erro, os sintomas, a
soluo de contorno ou a resoluo defnitiva.
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 Co-
nhecidos 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 conhe-
cimento 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 2
15
I TI L

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 identifcao inicial at sua eventual remoo, passando pela sua investi-
gao 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 fun-
damentado 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.
Identifcao do Problema
Diferentemente do Gerenciamento de Incidentes, que busca restaurar a operao normal do
servio o mais rpido possvel, o Gerenciamento de Problemas busca identifcar 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 im-
portantssima, e um dos segredos de um processo bem sucedido de Gerenciamento de Problemas.
16
I TI L

Algumas possibilidades de identifcao 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 identifcado 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 notifcao de um fornecedor. (um exemplo clssico so os hotfxes que a Microsoft
disponibiliza via Windows Update. So problemas que a prpria Microsoft identifca,
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 proble-
ma 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 investi-
gao e diagnstico. Uma boa forma de registrar o histrico completo do problema fazendo refe-
rncias aos incidentes causados por ele A data e a hora tambm so importantes, para que seja pos-
svel 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 confveis 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 Gerenciamen-
to de Incidentes, ou seja, atravs da relao entre impacto e urgncia. Alm disso, o Gerenciamen-
to 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)?
CAPTULO 3
17
I TI L

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 fnanceiras;
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 de-
tectado, 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 pers-
pectivas tcnica e fnanceira. Esta avaliao deve ser posteriormente refnada 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 diagnos-
ticar e resolver problemas, e que sero apresentadas com detalhes mais adiante, em um captulo
especfco.
Durante a atividade de investigao e diagnstico, as informaes de confgurao devem ser
utilizadas para avaliar de forma mais profunda o impacto e a severidade do problema. As informa-
es de Erros Conhecidos devem ser pesquisadas para verifcar se o problema j ocorreu anterior-
mente 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 inciden-
tes causados por um problema. Geralmente so solues temporrias ou alternativas que no re-
solvem o problema, mas minimizam o impacto dos incidentes ou ajudam os usurios a superarem
as difculdades.
Em muitos casos, tais solues so encontradas pelo processo de Gerenciamento de Inciden-
tes na sua tentativa de restaurar o servio o mais rpido possvel. Quando isto acontece, o proces-
so 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.
CAPTULO 3
18
I TI L

A existncia de solues de contorno diminui a urgncia na soluo do problema - seja redu-
zindo a probabilidade de ocorrncia de novos incidentes relacionados, seja aumentando a veloci-
dade 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 identifcados e trata-
dos de forma mais rpida. Por esta razo, os Erros Conhecidos devem ser imediatamente documen-
tados 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, modifcao 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 pro-
blema 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 justifcvel na perspectiva do neg-
cio (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 confrmar a efccia da soluo, po-
dendo-se consultar o Service Desk, os grupos de suporte e os usurios do servio.
Neste momento o registro do problema tambm deve ser verifcado e, se necessrio, atua-
lizado, 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 auto-
maticamente).
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
CAPTULO 3
19
I TI L

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 fgura 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 entra-
das para o processo. Os itens que esto mais prximos dos outros processos so as sadas (produ-
tos, entregveis) do processo.
CAPTULO 3
20
I TI L

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 perfl atual e desejvel dos profssionais envolvidos com o Gerenciamento de Problemas.
Gestor de Problemas
As atividades e responsabilidades mais comuns do Gestor de Problemas so:
Desenvolver fuxos 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 classifcao
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 identifcar as suas causas.
natural que em um primeiro momento as organizaes no queiram fazer grandes inves-
timentos em uma equipe exclusiva para lidar com o processo de Gerenciamento de Problemas,
principalmente a fgura 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 pro-
cessos, controle de qualidade, tcnicas de melhoria contnua, etc.).
CAPTULO 3
21
I TI L

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 resul-
tados 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 ne-
nhum 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
CAPTULO 3
22
I TI L

CAPTULO 4
TCNICAS DE DETERMINAO DE PROBLEMAS
Neste captulo, sero apresentadas as vrias tcnicas existentes para a realizao do Gerenciamento
de Problemas, destacando exemplos e formas de aplicao para as principais delas.
Anlise Cronolgica
A anlise cronolgica indicada pra lidar com problemas complexos, onde pode haver relatos confi-
tantes sobre o que e quando exatamente aconteceu. Nestes casos, pode ser til documentar brevemente
a cronologia dos eventos. Com isso, possvel:
1. Identifcar eventos que foram gerados por outros eventos;
2. Identifcar fatores que contriburam com o impacto do problema;
3. Desconsiderar hipteses no justifcveis pela sequncia de eventos.
Uma boa referncia para a anlise cronolgica o histrico dos incidentes, mas isso depende da ma-
turidade do processo de Gerenciamento de Incidentes. Vejo muitas organizaes que no levam to a
srio a questo de atualizao de incidentes. Isso pode comprometer todo o trabalho de determinao
de problemas ou, no mnimo, aumentar o tempo (e consequentemente o custo) da determinao de
problemas, uma vez que as equipes precisaro fazer o levantamento dos fatos cronolgicos com todas
as equipes que participaram da resoluo do incidente.
Para reforar um pouco mais esta necessidade, na norma ISO/IEC20000, que preconiza o estabeleci-
mento de um Sistema de Gerenciamento de Servios de TI, a atualizao dos incidentes um dos requi-
sitos para o processo de Gerenciamento de Incidentes.
Anlise de Valor do Impacto
A tcnica de anlise de valor do impacto usada para ajudar a identifcar o impacto de um ou mais
problemas no negcio. Pode ser utilizada como critrio de identifcao de um problema ou para priori-
zar o tratamento de problemas j registrados.
Basicamente, esta tcnica consiste em usar uma frmula pra calcular o Valor do Impacto no negocio,
com base nos seguintes itens:
1. Nmero de usurios afetados;
2. Durao da Indisponibilidade;
3. Custo para o Negcio (se conhecido), que pode ser considerado em termos tangveis (como custo
fnanceiro) ou intangveis (como a credibilidade e a imagem da empresa).
Veja um exemplo prtico de aplicao desta tcnica nas fguras 4 e 5, a seguir:
23
I TI L

Figura 4
Figura 5
No exemplo apresentado, as categorias Internet e Sistema 3 so destacadas com alto valor
de impacto, porm atravs de critrios distintos.
No caso da categoria Internet, a quantidade de usurios impactados (400) e o perodo de in-
disponibilidade (120 minutos) foram os maiores infuenciadores no valor de impacto.
Por outro lado, os critrios que infuenciaram o alto valor de impacto da categoria Sistema 3
foram a quantidade de incidentes ou problemas relacionados (150) e o custo para o negcio (5).
Brainstorming (tempestade de ideias)
O Brainstorming uma tcnica valiosa para obteno de palpites sobre a potencial causa e
as aes para resolver o problema. Preferencialmente, ela deve envolver pessoas relevantes para
o assunto em questo (tcnicos especialistas e gestores de problemas), caso contrrio a discusso
pode fcar muito superfcial.
CAPTULO 4
24
I TI L

Esta tcnica pode ser utilizada para:
1. Identifcao de problemas;
2. Identifcao de causas;
3. Identifcao de solues.
Segue um exemplo real de uso desta tcnica: em uma organizao havia uma reunio diria
com um representante de cada rea de suporte para discutir os principais incidentes do dia anterior.
Nem sempre a reunio se encerrava com a clara determinao do problema, mas j havia v-
rios argumentos para embasar uma anlise mais profunda, ou pelo menos reportar algo mais con-
sistente para os executivos e os clientes. Pelo fato da reunio contar com a presena de tcnicos
de diferentes especialidades, surgiam fatos relevantes que no eram detectados durante o acom-
panhamento do incidente.
Outra vantagem desta tcnica o uso de diversas ferramentas, das mais simples, como um blo-
co de notas, um Diagrama de Ishikawa ou um quadro com post-its, at outras mais sofsticadas
como softwares de mapa mental.
Apresento a seguir um roteiro passo a passo sugerido sobre como conduzir uma sesso
de brainstorming:
1. O grupo deve reunir-se numa sala onde as possibilidades de distrao sejam mnimas.
2. O grupo deve eleger um facilitador que conduzir a tcnica de Brainstorming, anotando as
opinies, coordenando a fala dos participantes e motivando-os a participar.
3. O facilitador deve explicar o objetivo da Tcnica de Brainstorming.
4. O facilitador deve dar tempo para que os participantes refitam sobre o objetivo de
Brainstorming.
5. O facilitador convida todos os participantes e apresentarem suas opinies durante quinze
minutos, relembrando e exigindo o cumprimento das regras (nada de discusses! prxima
opinio).
6. O grupo l as opinies e combina as que forem semelhantes.
7. O grupo prioriza as opinies atravs de discusso.
Obviamente, depois de algumas, no necessrio seguir todos estes passos risca, devido ao
aumento do grau de maturidade na aplicao da tcnica.
Para concluir o assunto, importante que:
A reunio tenha um perodo determinado (uma hora est de bom tamanho, se durar mais
do que isso a reunio se dispersa).
Participem pessoas capacitadas tecnicamente, com algum conhecimento prvio sobre o
que ser discutido na reunio.
Exista a fgura do moderador. No caso, o gestor de problemas a pessoa mais indicada.
CAPTULO 4
25
I TI L

Diagrama de Afinidade
O diagrama de afnidade de certa forma, uma extenso ou sequncia do resultado fnal de
uma sesso de brainstorming. Este mtodo surgiu na dcada de 60 para permitir que as vrias
ideias oriundas de uma sesso de brainstorming possam ser classifcadas e organizadas para revi-
so e anlise.
O princpio bsico do diagrama de afnidade consiste em coletar todas as ideias anotadas em
uma sesso de brainstorming e agrup-las em categorias ou grupos. Assim, conseguimos de ime-
diato perceber os relacionamentos existentes entre as vrias ideias, detectar inconsistncias entre
ideias contraditrias, e enxergar prioridades ou direcionamentos nas ideias coletadas que no so
visveis quando as ideias so tomadas no seu total, sem nenhuma organizao.
A maneira mais tradicional de se agrupar as ideias , primeiramente, anotar as ideias usando
post-its. Assim fca mais fcil colar os papis em diferentes posies na segunda etapa.
Depois, pode-se ou escrever os agrupamentos em um quadro e colar os post-its no prprio
quadro, ou ento usar post-its de cores diferentes para identifcar as categorias ou agrupamentos.
A fgura 6 representa de forma didtica o passo a passo na construo do diagrama de afnidade.
Figura 6
CAPTULO 4
26
I TI L

5 porqus
Apesar de ser uma tcnica relativamente simples, efciente para a identifcao da causa raiz
de problemas.
Tudo comea com uma descrio do evento ocorrido, seguida repetidamente pela pergunta:
Por que isto aconteceu?. Normalmente a resposta do quinto porque a mais prxima da causa
raiz, mas isso no uma regra.
Eventualmente, possvel se chegar a causa raiz antes, ou depois dos cinco porqus.
Algumas vantagens desta tcnica:
1. Simples, ou seja, pode ser aplicada no dia a dia, principalmente se houver um nmero
razovel de problemas.
2. Efcaz. Se aplicada da forma correta, ou seja, focando na causa raiz e no nas causas
aparentes, os resultados podem ser bastante satisfatrios.
3. Abrangente, pois pode ser aplicada em diversos contextos.
4. Flexvel, pode ser facilmente adaptada.
5. Envolvente e barata, pois no exige ferramentas sofsticadas.
Veja a seguir um exemplo de aplicao desta tcnica em uma situao real:
Descrio do Problema: Sistema de Contas a Pagar indisponvel
Por que (o sistema de Contas a Pagar fcou indisponvel)?
_Porque o servidor travou.
Por que (o servidor travou)?
_Porque estava faltando uma DLL do Sistema Operacional.
Por que (estava faltando uma DDL do Sistema Operacional)?
_Porque a DLL foi excluda.
Por que (a DLL foi excluda)?
_Durante uma mudana, estava prevista a excluso do arquivo X, e por engano a DLL Y foi
excluda.
Por que (a DLL foi excluda por engano)?
_O recurso alocado no seguiu o script de execuo da mudana (provvel causa!).
Teste de Hipteses
A tcnica de teste de hipteses pode ser usada para gerar uma lista de possveis causas, visan-
do determinar quais hipteses so verdadeiras ou falsas atravs da avaliao e testes de diferentes
equipes tcnicas.
uma tcnica relativamente simples, mas a sua efccia depende bastante da existncia de um
ambiente de teste similar ao de produo. Por isso, nem sempre possvel utiliz-la. Alm disso,
existe a questo de que os testes precisam ser agendados, e pode haver um confito na hora de
priorizar este tipo de teste em ambientes compartilhados entre o pessoal de desenvolvimento e o
pessoal de suporte, as equipes de desenvolvimento tm prioridade.
CAPTULO 4
27
I TI L

Posto de Observao Tcnica
O posto de observao tcnica utilizado em casos de problemas intermitentes, por exemplo,
aqueles casos bem comuns de links de comunicao que fcam indisponveis, e, para os quais,
quando o tcnico vai fazer o diagnstico percebe que j voltou a responder.
Esta tcnica consiste na observao previamente planejada de eventos em tempo real, com o
objetivo de capturar e identifcar situaes especfcas e as provveis causas de um problema, a
observao feita por equipes com especialidades distintas.
recomendvel que esta tcnica seja utilizada em problemas de alto impacto, pois ela exige
mobilizao e foco de vrios tcnicos para o ambiente em tempo real. Nem sempre o custo de
disponibilizar estes tcnicos em tempo integral pode ser justifcvel.
Apresento a seguir um roteiro passo a passo sobre como utilizar esta tcnica:
1. Identifcar o problema atravs de observao ou reclamaes dos usurios.
2. Identifcar um especialista para cada assunto tcnico relacionado ao problema (ex.: redes,
sistemas operacionais, storage, etc.).
3. Disponibilizar aos especialistas uma sala dedicada, com sistemas de acesso e ferramentas
sufcientes para poderem examinar o servio de TI em tempo real.
4. Capturar todas as observaes e recomendaes da equipe envolvida.
5. Criar um plano de ao.
A recomendao mais importante para o uso desta tcnica que o grupo que ir participar
tenha um espao reservado e sem interferncia de outros assuntos.
Existe uma expresso comum chamada de war room. Normalmente uma sala alocada tem-
porariamente para um grupo de especialistas atuarem em tempo integral monitorando o ambien-
te, obtendo evidncias de erros e trabalhando para identifcar as causas. O war room nada mais
do que um posto de observao tcnica.
Diagrama de Ishikawa (espinha de peixe)
O diagrama de Ishikawa uma tcnica que permite estruturar hierarquicamente as causas po-
tenciais de um determinado problema. uma das tcnicas mais efcazes e mais utilizadas, mas, em
relao a algumas outras tcnicas, pode ser considerada um pouco mais trabalhosa.
A elaborao de um Diagrama de Ishikawa relativamente simples. A parte mais difcil est em
comear; isso porque recomendvel reunir uma equipe, com profssionais de diferentes especia-
lidades, mas que estejam de alguma forma envolvidos no problema.
A ideia obter diferentes pontos de vista a respeito de um mesmo assunto, podendo verifcar
uma grande gama de possveis causas. Tendo a equipe reunida e o problema (bem defnido) para
o qual se busca uma soluo, pode-se iniciar a estruturao do Diagrama de Ishikawa.
CAPTULO 4
28
I TI L

Figura 7
Inicialmente, deve-se traar uma reta horizontal e em uma de suas extremidades e descrever o
problema (efeito) em que se baseia o estudo.
Feito isso, deve-se criar linhas diagonais que interceptem a linha anterior (efeito), para que
essas representem categorias de possveis causas principais para o efeito. Basicamente, tais linhas
seriam as causas me.
As causas me podero ter causas flhas, as quais devero ser relacionadas atravs de uma seta
na horizontal, que direcione diagonal ligada sua causa me.
Essas causas podem ser levantadas por meio de brainstorming, que deve contar com a partici-
pao de toda a equipe, com o objetivo de alcanar os melhores resultados possveis.
Toda possvel causa levantada deve ser considerada e no pode haver represlias no grupo,
para que no ocorra acanhamento por parte de nenhum dos membros envolvidos. Caso no exis-
tam causas flhas para alguma categoria, no h problema.
Podem existir tambm causas flhas de segundo nvel, as quais devem ser relacionadas s suas
causas flhas de primeiro nvel por meio de uma seta diagonal.
Por fm, quando todas as possveis causas estiverem esgotadas, devero ser estabelecidos os
focos do trabalho; isso porque podero ser encontradas inmeras causas e nem todas podero ser
solucionadas inicialmente. Por esse motivo, necessrio estabelecer um mtodo para selecionar
quais das causas encontradas devero ser atacadas com critrio de urgncia.
Um mtodo bastante simples e efciente atribuir uma pontuao, de 0 a 10, para cada uma
das causa-flhas de segundo nvel encontradas. Esses valores devem ser estabelecidos por meio da
participao de todos os integrantes do grupo de trabalho.
Terminada essa etapa, o Diagrama de Ishikawa estar concludo e, a partir da, pode-se priori-
zar a soluo dos itens com maiores pontuaes.
CAPTULO 4
29
I TI L

Kepner-Tregoe
Kepner-Tregoe uma tcnica muito til para investigar profundamente a causa de um proble-
ma. Ela possui os seguintes Estgios:
1. Defnir o problema;
2. Descrever o problema;
3. Estabelecer as possveis causas;
4. Testar a causa mais provvel;
5. Verifcar a verdadeira causa.
Dependendo do tempo e das informaes disponveis, estas fases podem ser realizadas com
maior ou menor extenso. Mesmo em situaes em que apenas uma quantidade limitada de in-
formao est disponvel, ou a presso do tempo alta, vale a pena adotar uma abordagem estru-
turada para a anlise de problemas para melhorar as chances de sucesso.
Estgio 1 Defnir o Problema
A anlise do problema comea com a defnio do problema. A falha ao entender exatamente
qual o problema muitas vezes resulta em perda de tempo. Ento, considerar esta etapa como
esforo intil um erro.
Uma vez que a resoluo de problemas naturalmente um exerccio em equipe, importante
ter uma completa compreenso do problema. Veja os dois exemplos abaixo sobre a defnio de
um mesmo problema:
O servidor travou.
Essa certamente no a melhor defnio de um problema. importante incluir mais informa-
es, que resultem em uma defnio de fcil compreenso, e que no seja suscetvel a interpre-
taes erradas.
Uma defnio mais adequada poderia ser:
O sistema de e-mail caiu aps o analista do terceiro turno do suporte aplicar o patch XYZ no
servidor Exchange XPTO.
Ao desenvolver uma defnio do problema, recomendvel utilizar a tcnica dos Cinco Por-
qus para chegar ao ponto em que no haja uma explicao para o problema. O uso dos cinco
porqus acelera o processo.
Estgio 2 Descrever o Problema
Com uma defnio clara do problema, o prximo passo descrever o problema detalhada-
mente. A tabela a seguir fornece um bom modelo para essa atividade. possvel execut-la usan-
do diferentes ferramentas, seja um fip chart, um papel, ou mesmo o MS-Excel, como o caso des-
crito no exemplo.
A fgura 8 descreve os quatro aspectos de qualquer problema:
a. O que ,
b. Onde ocorreu,
c. Quando ocorreu,
d. Na medida em que ela ocorreu.
CAPTULO 4 CAPTULO 4
30
I TI L

Figura 8
A segunda coluna, cujo ttulo , fornece um espao para descrever detalhes sobre o problema
o que o problema.
A terceira coluna, intitulada poderia ser, mas no fornece espao para listar questes espe-
cfcas com relao situao, mas excludas - ou seja, o que o problema poderia ser, mas no .
Estas duas colunas ajudam na eliminao de suposies incorretas sobre o problema.
Com as colunas dois e trs concludas, a quarta coluna fornece espao para detalhar as diferen-
as entre o que e o que PODERIA SER, MAS NO .
Estas diferenas formam a base da resoluo de problemas.
A ltima coluna fornece espao para listar todas as alteraes feitas que possam explicar as
diferenas.
Estgio 3 Estabelecer as Possveis Causas
A experincia (e tambm as boas praticas) nos mostra que a causa raiz do problema normal-
mente devida a alguma mudana recente. O problema que podem acontecer muitas mudanas
em um mesmo perodo, o que complica um pouco as coisas.
Este estgio pode ajudar descrevendo qual o problema e o que o problema poderia ser, mas
no . Por exemplo:
Com base no problema descrito anteriormente e ao olhar a fgura 9, algumas causas se tornam
mais aparentes.
Figura 9
CAPTULO 4
31
I TI L

Fica claro que a causa mais provvel relacionada ao processo, devido ao fato do fornecedor
no ter aplicado os patches, e sim passado o procedimento para que a prpria empresa aplica-se.
Estgio 4 Testar a Causa Mais Provvel
Com uma pequena lista das potenciais causas, o prximo passo verifcar a causa mais provvel.
Cada possvel causa precisa de ser avaliada para determinar se poderia ser a causa de todos os
sintomas do problema.
Figura 10
Estgio 5 Verifcar a Verdadeira Causa
O passo seguinte consiste em comparar as possveis causas contra a descrio do problema.
A ideia aqui eliminar as possveis causas que no podem explicar a situao e focar os itens
restantes. Depois que for constatada a verdadeira causa, deve-se propor a ao necessria para
resolver o problema.
Figura 11
CAPTULO 4
32
I TI L

Anlise de Pareto
A Anlise de Pareto uma tcnica simples para priorizar a resoluo de problemas. Ela basea-
da no Princpio de Pareto (tambm conhecido como a regra 80/20 - ou seja, a ideia de que 80%
dos problemas podem ser causados por 20% de suas causas).
Com isso, o Diagrama de Pareto ir proporcionar as informaes necessrias para priorizar o
esforo, utilizando o tempo onde obter o resultado mais efciente.
Apresento seguir um roteiro passo a passo sobre como realizar a anlise de Pareto:
1. Identifcar e listar os problemas e as suas causas.
2. Marcar cada problema e agrup-los por causa.
3. Adicionar a pontuao para cada grupo (de causas).
4. Trabalhar para encontrar uma soluo para o grupo de causa com a maior a maior pontuao.
Cabe ainda lembrar que o foco aqui atacar a categoria de causa que gera a maior quantidade
de problemas.
Matriz do /NO
A matriz do /NO consiste em uma anlise baseada em comparao de fatos, situaes,
ambientes, sistemas ou equipamentos similares, onde um apresenta problema e o outro no.
Na diferena entre eles, pode estar a causa ou uma pista importante para sua descoberta.
Veja a seguir um exemplo de aplicao da matriz do / no :
Descrio do problema: Internet Banking indisponvel.
Desencadeador do problema (trigger): Travamento do servidor.
Pergunta : Qual o servidor afetado?
_Servidor X.
Pergunta No : Existe algum servidor idntico ao afetado no ambiente que no esteja
apresentando travamentos?
_ Servidor Y.
Pergunta de Comparao de Fatos: Qual a diferena entre o servidor X e Y?
_*Verso do frmware das mquinas.
* Esta resposta uma pista importante para a identifcao da causa raiz do problema.
CAPTULO 4
33
I TI L

Mapa de Aplicabilidade
Na fgura 12 h um mapa de aplicabilidade das tcnicas de determinao de problemas. Este
mapa pode ser utilizado como uma referncia para futuras consultas, de acordo com as situaes
cotidianas de uma organizao de TI.
Figura 12
CAPTULO 4
34
I TI L

IMPLEMENTAO DO PROCESSO DE GERENCIAMENTO
DE PROBLEMAS NO MUNDO REAL
Neste captulo sero apresentadas algumas questes importantes sobre a implementao do
processo de Gerenciamento de Problemas.
importante ressaltar que grande parte do contedo deste captulo provm de experincias
pessoais do autor, alm de discusses e artigos da comunidade ITSM na Prtica.
Prticas de Gesto de Projetos: por que usar?
Quando ns falamos em implementar um ou mais processos de gerenciamento de servios de
TI, uma das perguntas se existe a necessidade de tratar essa implementao como um projeto.
Existem algumas vantagens de usar prticas de gesto de projetos para implementar proces-
sos, por exemplo:
Os benefcios do projeto vo ser defnidos e acordados de forma clara; com isso evita-se a
criao de falsas expectativas em relao ao resultado esperado.
A visibilidade das contribuies das equipes envolvidas na implementao ser maior,
pois as prticas de gesto de projetos garantem a comunicao dos objetivos e resultados
atingidos.
Poderiam ser citados outros bons motivos que justifcam o uso de prticas de gesto de pro-
jetos. A prpria ITIL
sugere essa abordagem pra implementao de processos de gerenciamento

de servios.
Uma questo importantssima que, assim como projetos de qualquer outra natureza, um
projeto de implementao de processos tambm exige uma justifcativa de negcio, que geral-
mente realizada atravs do desenvolvimento de um business case (caso de negcio). Esta prtica
altamente recomendvel sempre que for identifcada a necessidade de implementar um ou mais
processos de gerenciamento de servios.
Abordagens proativas e reativas
Anlise crtica de Incidentes Graves
Incidente grave um incidente de altssimo impacto para a organizao e que precisa ser trata-
do imediatamente. Quando no resolvido dentro do prazo, este tipo de incidente pode disparar
o plano de continuidade de servios de TI. Esse um daqueles incidentes que esperamos que
nunca acontea.
A Anlise Crtica de Incidentes Graves uma atividade post-mortem, ou seja, normalmente
ocorre aps o restabelecimento de um incidente grave. Portanto, ela uma atividade reativa, cujo
foco evitar a recorrncia deste incidente.
CAPTULO 5
35
I TI L

Essa uma abordagem comum em organizaes que esto comeando a adotar prticas de
gerenciamento de servios, justamente porque no requer uma periodicidade de anlise, sendo
disparada somente a partir de um incidente grave.
Uma poltica comum para esta abordagem registrar um problema pra cada incidente grave.
Anlise de tendncias
Uma segunda possvel abordagem para o Gerenciamento de Problemas a Anlise de Ten-
dncias dos servios e da infraestrutura de TI.
A Anlise de Tendncias de Incidentes Recorrentes, por exemplo, busca evitar que uma si-
tuao ocorra novamente, enquanto a Anlise de Eventos e Comportamentos busca evitar que a
situao ocorra.
O uso da Anlise de Tendncias normalmente o segundo passo para uma organizao de TI
que j possui um processo de Gerenciamento de Problemas em estgio inicial, pois possui carac-
tersticas proativas.
Veja a seguir na fgura 13 um exemplo de anlise de tendncias de incidentes recorrentes:
Figura 13
Esta anlise tem um foco reativo e busca reduzir o numero de incidentes recorrentes com maior
grau de ocorrncia (normalmente so os TOP 5, por categoria), e tambm orientada a melhorar
a satisfao do cliente. Como j comentado anteriormente, as recorrncias geram um mal estar
muito grande nos usurios.
O ranking aponta duas categorias de incidentes com maior recorrncia: Links e Protocolos e
Monitoramento .
CAPTULO 5
36
I TI L

Este ranking tambm pode ser criado utilizando outros critrios e fltros. O nico cuidado a ser
tomado utilizar critrios que realmente refitam recorrncias. Quanto mais especfca for a cate-
gorizao, melhores so as chances de identifcar as recorrncias reais, e no um agrupamento de
vrios incidentes distintos.
A fgura 14 um exemplo de anlise de eventos.
Figura 14
Esta anlise tem foco proativo, ou seja, visa antecipar os problemas e os seus incidentes resul-
tantes. Ela exige interface com o processo de Gerenciamento de Eventos, pra que o trabalho seja
focado em eventos que realmente tenham alguma signifcncia para os servios de TI.
E, fnalmente, a fgura 15 mostra um exemplo de anlise de comportamento:
Figura 15
Esta analise tambm tem foco proativo, visando antecipar os problemas e seus incidentes re-
sultantes, exige interface com outro processo, o Gerenciamento da Capacidade, no que se refere
ao uso de informaes de thresholds e padres de comportamento.
Veja, na fgura 5, que em um determinado perodo h um pico de utilizao de banda. Este
pode ser ou no um comportamento padro. Se for um comportamento normal, j previsto, no
faz sentido fazer uma investigao da causa raiz. Por este motivo, o envolvimento do processo de
Gerenciamento da Capacidade importante, pois cabe a ele responder sobre os padres de com-
portamento dos servios e da infraestrutura de TI.
CAPTULO 5
37
I TI L

O caminho natural da maturidade
A fgura 16 mostra a evoluo natural da maturidade do processo de Gerenciamento de Pro-
blemas. H uma escala de tempo e maturidade. Quanto maior o tempo de aprendizagem, maior
o nvel de maturidade que o processo pode atingir.
Figura 16
Uma das primeiras prticas tradicionalmente associadas com o processo de Gerenciamento de
Problemas que as organizaes implantam a Anlise Crtica de Incidente Graves.
A premissa desta atividade analisar os incidentes de alto impacto para determinar a causa
raiz e implantar medidas para evitar a sua recorrncia.
Esta prtica geralmente implantada como parte da atividade de resoluo de incidentes e
muitas vezes conduzida por um coordenador ou lder de Service Desk. Neste caso, ocorre o Geren-
ciamento de Problemas reativo.
O prximo nvel de maturidade a percepo de que o Gerenciamento de Problemas um
processo distinto que possui seus prprios modelos de processos, polticas e recursos e apoiado
por relatrios e tendncias de incidentes.
Embora possa ser considerado que, neste estgio, o processo tem um nvel de maturidade
com algumas vantagens signifcativas, a maioria das atividades ainda est focada na identifcao
e eliminao reativa de problemas.
O terceiro nvel da implementao do Gerenciamento de Problemas normalmente inclui ques-
tes proativas com o propsito explcito de evitar os incidentes.
Um exemplo disto que o gerenciamento de patches comea a ser compreendido como parte
do processo de Gerenciamento de Problemas.
Quando um fornecedor sinaliza que uma vulnerabilidade de segurana ou uma defcincia foi
encontrada em seu produto, um registro de Erro Conhecido aberto com a fnalidade de analisar
o seu impacto antes que algum incidente ocorra.
CAPTULO 5
38
I TI L

Se o Erro Conhecido for relevante, e for possvel aplicar um patch pra sua correo, os proces-
sos de Gerenciamento de Mudanas e Gerenciamento de Liberaes so acionados para validar,
testar, aprovar e implantar o patch no ambiente de produo.
Implementao orgnica
O conceito de implementao orgnica parte do principio de que, em alguns casos, possvel
aproveitar os momentos oportunos a vida real da organizao para justifcar a implementao
de prticas de gerenciamento de servios.
Por exemplo, se uma organizao vem tendo um nmero excessivo de reincidncias que aca-
bam causando um impacto muito alto para o negcio, esta pode ser uma boa oportunidade para
se implantar a abordagem de anlise de reincidncias.
Neste caso utilizado um motivo real e atual para iniciar a adoo de uma ou mais prticas de
gerenciamento de servios.
Outra abordagem dentro do conceito de implementao orgnica a de documentar as pr-
ticas em andamento, em vez de tentar praticar o que est defnido em uma documentao ou em
um processo.
No uma sugesto de ir contramo de conceitos fundamentais de qualidade e melhoria
contnua, como o PDCA, que prev o planejamento (Plan) antes da execuo (Do). O que sugeri-
do nesta abordagem que o planejamento seja mais realista, simples e objetivo.
Muitas organizaes usam um modelo de processo do mercado e resolvem seguir este mode-
lo risca.
Contudo, cada organizao tem a sua peculiaridade, suas questes culturais, suas limitaes
tecnolgicas, recursos humanos, etc. Por isso, praticamente impossvel querer que uma imple-
mentao baseada em uma ferramenta ou processo padronizado pelo mercado seja totalmente
aplicvel em qualquer organizao.
Pode-se obter bons resultados saindo de uma reunio com uma simples ata onde, combinadas
algumas atividades e responsveis, imediatamente elas passam a ser praticadas no dia a dia, e pos-
teriormente so documentadas em processos e procedimentos formais.
recomendvel evitar o estabelecimento um processo muito complexo de um dia para o ou-
tro. Um bom caminho dar pequenos passos, ampliar o escopo do processo gradativamente, ga-
rantindo que o que foi estabelecido no se perca no meio do caminho.
Obviamente, tambm preciso se preocupar em agregar ganhos rpidos ao longo do percur-
so de implementao.
Em um projeto de implementao do Gerenciamento de Problemas com previso de trs me-
ses, planejar a criao de uma Base de Dados de Erro Conhecido somente para o terceiro ms
certamente um mau caminho.
Neste caso recomendvel prever a criao de uma Base de Dados de Erro Conhecido inicial
logo no incio do projeto, e considerar o seu amadurecimento ao longo do projeto.
CAPTULO 5
39
I TI L

Requisitos mnimos
Antes de decidir implantar o processo de Gerenciamento de Problemas, altamente recomen-
dvel considerar os seguintes requisitos:
A existncia de um processo maduro de gerenciamento de incidentes. A boa classifcao
de incidentes um dos fatores crticos de sucesso para o Gerenciamento de Problemas.
Um patrocinador da iniciativa. Nenhuma iniciativa vai pra frente sem um bom patrocnio, de
preferncia top-down.
Engajamento dos envolvidos. preciso, no mnimo, defnir quem sero os personagens, ou
as pessoas que iro atuar no processo, e com que periodicidade. A recomendao da ITIL

que sejam dedicados 20% do tempo no tratamento de problemas, e 80% no tratamento de
incidentes.
Defnio de polticas. preciso estar claro para a organizao quais so as regras do jogo.
Algumas iniciativas de adotar o Gerenciamento de Problemas vo por agua abaixo devido
m defnio de polticas, especialmente aquelas relacionadas identifcao de problemas.
O hbito de reportar e analisar criticamente o desempenho do processo, periodicamente. Pode
no parecer to importante, mas faz toda a diferena.
Critrios de Identificao de Problemas
Como comentado logo nos primeiros captulos deste livro, o critrio de identifcao de pro-
blemas um dos segredos de um processo bem sucedido de Gerenciamento de Problemas.
Sabemos que a teoria defne um problema como sendo a causa desconhecida de um ou mais
incidentes. Isso no signifca que todos os problemas precisam ser tratados.
A no ser que a organizao tenha uma equipe dedicada a isso (o que parece bastante im-
provvel) ser preciso criar alguns critrios para absorver e tratar apenas os problemas mais rele-
vantes (que tragam os resultados mais expressivos para o negcio). A forma de determinar isto
atravs da defnio de critrios de identifcao de problemas.
Um critrio bem comum e j citado anteriormente registrar um problema para cada inciden-
te grave. Esse critrio visa evitar que o mesmo incidente grave ocorra novamente
Outro critrio poderia ser registrar um problema a cada cinco incidentes recorrentes do mes-
mo tipo, na mesma semana ou perodo de 7 dias consecutivo. Esse critrio procura diminuir a
quantidade de incidentes recorrentes, independentemente do grau de impacto destes incidentes.
Em um terceiro critrio, poderia ser considerado o registro de um problema para cada inciden-
te que foi direcionado para o grupo de suporte de terceiro nvel. Este critrio tem foco em evitar
que os especialistas sejam acionados para tratar o mesmo caso novamente. Nestes casos, a equipe
de terceiro nvel deve alimentar a Base de Dados de Erro Conhecido para que as equipes de primei-
ro e segundo nvel possam resolver incidentes por conta prpria.
O ideal comear com critrios mais simples, que possam ser revistos se o esforo alocado
para o processo estiver abaixo do que foi previsto.
CAPTULO 5
40
I TI L

Nem tudo crtico!
Muito cuidado para no criar gargalos. Os principais motivos dos gargalos esto relacionados
defnio inefciente de incidentes crticos (nem tudo crtico!).
Se no estiver seguro de que os critrios para defnio de um incidente crtico (que so esta-
belecidos no processo de gerenciamento de incidentes) so adequados, evite us-los como crit-
rio para identifcao de problemas.
Caso real: uma organizao onde a cada dez incidentes, cinco eram crticos. E no porque eles
eram realmente crticos, mas porque os critrios de categorizao no estavam bem delineados.
Com isso, gerava-se um nmero exorbitante de problemas, que na verdade no eram to
relevantes.
Este evento mesmo um problema?
O uso de critrios de identifcao de problemas a partir de eventos da infraestrutura uma
boa ideia e uma prtica totalmente proativa.
Contudo, se estes eventos no estiverem sendo bem categorizados em relao a sua signif-
cncia para os servios de TI, provvel que se perca tempo analisando muitos problemas, dos
quais a maioria seja irrelevante.
Base de Dados de Erros Conhecidos (BDEC)
Como visto nos captulos anteriores, a Base de Dados de Erros Conhecidos um dos produtos
mais importantes gerados pelo processo de Gerenciamento de Problemas. Alm de ser uma fonte
de consulta para resoluo mais rpida e assertiva de incidentes e problemas, ela tambm contri-
bui com a uniformidade do atendimento.
Em uma situao cotidiana, imagine que um usurio liga para o Service Desk pedindo para falar
com um analista especfco, porque ele o cara que resolve.
Isso acontece porque, na falta de uma Base de Dados de Erros Conhecidos, o modelo de atua-
o cada um por si. A resoluo dos incidentes fca por conta do conhecimento individual de
cada analista do Service Desk.
Defnitivamente, este no um bom caminho.
Identifcao de Erros Conhecidos durante o Desenho do Servio
Os Erros Conhecidos normalmente so criados e gerenciados pelo processo de Gerenciamento
de Problemas, e podem ser identifcados, inclusive, durante o desenvolvimento de novos servios
ou por fornecedores.
Usando a Microsoft como exemplo:
Simultaneamente ao lanamento de uma nova verso do Windows, disponibilizada uma Base
de Dados de Erros Conhecidos relacionada nova verso.
Como eles conseguem, em to pouco tempo, disponibilizar essa base?
CAPTULO 5
41
I TI L

simples. Esses erros so identifcados ainda na fase de desenvolvimento do produto. Por uma
questo estratgica, ou pelo simples consenso de que nunca existir uma verso totalmente livre
de erros, o produto lanado no mercado. A histria nos mostra que esta uma prtica que cos-
tuma funcionar (ao menos para a Microsoft).
A inteno deste exemplo reforar o entendimento de que os Erros Conhecidos no nascem
somente a partir de servios em operao. Eles podem surgir quando o servio ainda est no es-
tgio de Desenho.
Erro Conhecido: um registro, um status ou uma fag?
O que prevalece na deciso sobre a forma de criar um Erro Conhecido so as funcionalidades
da ferramenta de gesto.
Existem ferramentas que permitem a criao de um registro de Erro Conhecido e associe-o a
um registro de problema. Quando a ferramenta no permitir isso, pode-se utilizar um status espe-
cifco para o registro de problema, com o nome Erro Conhecido, ou atravs de um campo custo-
mizado (fag) dentro de um registro de Problema.
Validao dos Erros Conhecidos
Para garantir a confabilidade das solues propostas na Base de Dados de Erros Conhecidos,
todos os Erros Conhecidos precisam ser validados pelo Gerenciamento de Problemas antes de
serem publicados.
Protecionismo da informao
O conhecimento da organizao, e no de equipes ou indivduos. Isto signifca que a Base de
Dados de Erros Conhecidos deve ser disponibilizada para todos os recursos relevantes (por exem-
plo, o Service Desk) e, em alguns casos, conforme a maturidade, at para os usurios fnais.
H casos reais em que as equipes de suporte de terceiro nvel no disponibilizam o conheci-
mento para o Service Desk.
O que dizer sobre isso? No faz o menor sentido.
O Service Desk a vitrine da TI frente ao Cliente, por isso no uma boa deix-los a ver navios.
Estruturas funcionais
A fgura 17 mostra uma viso de como normalmente os processos esto distribudos entre as
reas funcionais das organizaes de TI.
CAPTULO 5
42
I TI L

Figura 17
Na fgura, so consideradas as funes preconizadas pela ITIL
, que provavelmente so prxi-

mas forma como a maioria das organizaes de TI esto estruturadas.
O processo de Gerenciamento de Problemas executado principalmente pelas equipes de ge-
renciamento tcnico e gerenciamento de aplicaes (que incluem grupos de suporte especfcos,
tais como servidores, rede, storage, banco de dados, middleware, desenvolvimento e suporte de
aplicaes, etc.). Estas equipes costumam ser consideradas como equipes de segundo e terceiro
nvel.
Perfil do profissional de Gerenciamento de Problemas
Um dos papeis envolvidos no processo o do gestor de problemas, que, nas grandes organi-
zaes, uma funo desempenhada em tempo integral, e nas organizaes menores um papel
assumido por algum do Service Desk, da rea de qualidade da empresa, ou at mesmo de algu-
ma rea tcnica.
O outro papel envolvido do analista de problemas (ou o analista tcnico).
Cenrio Atual
O que ocorre atualmente, na esmagadora maioria dos casos, que o gestor de problemas cos-
tuma ter habilidades avanadas em gerenciamento de servios, porm habilidades tcnicas muito
superfciais.
Isto no bom. Por mais que esse profssional conhea o processo e as tcnicas de determi-
nao de problemas, em vrios momentos ele poderia fcar travado por falta de conhecimento
tcnico, ou ser facilmente convencido pelas equipes tcnicas a concluir problemas apenas com
as suas causas aparentes.
CAPTULO 5
43
I TI L

Por outro lado, o analista tcnico atual possui habilidades tcnicas avanadas e habilidades
superfciais em gerenciamento. Com isso, apesar deste profssional ter plena condio tcnica para
encontrar a causa raiz de um problema, ele ainda no compreende os benefcios e a importncia
em fazer isso no dia a dia.
Diante deste cenrio, o perfl ideal de um bom profssional que trabalha ou quer trabalhar com
Gerenciamento de Problemas o seguinte:
_se atua como analista tcnico interessante que ele tenha, alm do pleno conhecimento tc-
nico, um bom conhecimento em gerenciamento de servios.
_se atua como gestor de problemas, precisa ter, alm do pleno conhecimento em gerencia-
mento de servios, um bom conhecimento tcnico em diversas tecnologias. No signifca ser um
especialista em redes, em banco de dados ou sistemas operacionais. Mas necessrio ter certa
segurana, saber ao menos como funciona cada uma das tecnologias que suportam os servios de
TI e as possveis relaes entre essas tecnologias.
Obviamente, este profssional ainda raro no mercado de trabalho.
Prazos (SLA)
Este um tema polemico a respeito do Gerenciamento de Problemas, que j rendeu algumas
discusses no grupo ITSM na Prtica do LinkedIN e tambm alguns artigos no site ITSM na Prtica:
Vale a pena defnir prazos para o Gerenciamento de Problemas?
Com base na participao da comunidade em relao a esta discusso, h um consenso geral
de que vale a pena defnir prazos para o Gerenciamento de Problemas. Os principais benefcios
desta prtica so:
Maior percentual de problemas com causa identifcada. A partir do momento que se defne
um prazo limite pra identifcao da causa raiz, as chances de perda das evidncias (como
por exemplo, logs de sistema) so menores.
Maior comprometimento das equipes de resoluo de problemas. Os prazos passam a
ser relacionados aos processos de escalonamento e, em alguns casos, at como parte da
avaliao do desempenho individual dos profssionais.
Clientes mais satisfeitos. Uma maior quantidade de problemas ser tratada de forma
consistente, evitando futuros incidentes e problemas que impactam os clientes.
As desvantagens
Uma das desvantagens que pode haver uma sobreposio de objetivos, ou seja, o Gerencia-
mento de Problemas passa a ser confundido com o gerenciamento de incidentes, com prazos mui-
to agressivos, que acabam comprometendo a efcincia das investigaes e diagnsticos devido
presso exercida por estes prazos.
CAPTULO 5
44
I TI L

Critrios de avaliao para ferramentas
Ao fazer uma avaliao de ferramentas para o Gerenciamento de Problemas, importante con-
siderar alguns critrios.
Um deles a capacidade de integrao de processos, principalmente com o gerenciamento de
incidentes, o gerenciamento de mudanas e o gerenciamento da confgurao.
Essa ferramenta precisa ser capaz de:
Fazer distino entre incidentes e problemas, ou seja, permitir que incidentes e problemas
sejam registros diferentes.
Permitir a correlao entre problemas e incidentes;
Permitir a correlao de mltiplos incidentes a um mesmo registro de problema;
Correlacionar registros de problemas com componentes da infraestrutura e servios
impactados (itens de confgurao);
Permitir que registros de requisies, eventos, incidentes e problemas sejam relacionados a
uma requisio de mudana que tenha causado um problema;
Permitir a criao de uma requisio de mudana a partir de uma anlise de causa raiz, por
exemplo.
Ter uma boa Base de Dados de Erros Conhecidos integrada, na qual o armazenamento e
acesso dos registros de Erros Conhecidos sejam os mais simples e fceis quanto possveis;
Ter bons recursos para gerao de relatrios.
Existem muitas ferramentas de mercado, inclusive algumas ferramentas open source (cdigo
aberto) que atendem estas caractersticas.
Para facilitar o trabalho, podem ser consultadas ferramentas com o selo Pink Verify. Este selo
foi criado pela consultoria Pink Elephant para avaliar a conformidade das ferramentas do mercado
com os requisitos preconizados pela ITIL
.
No site do Pink Verify, h uma lista de ferramentas que atendem desde um conjunto pequeno
de processos at todos os processos de gerenciamento de servios defnidos na ITIL
.
Entretanto, a busca por uma ferramenta no deve se restringir apenas a esta lista. Existem di-
versas ferramentas disponveis que no esto na lista, mas que podem ser to efcientes e adequa-
das quanto elas.
Relatos de Servio e Melhoria Contnua
Todo mundo conhece a mxima de um dos papas da administrao, Peter Drucker, que diz que
no se pode gerenciar o que no se pode medir.
Atualmente, se o desempenho dos processos no medido e gerenciado, a organizao de TI
perde a oportunidade de se tornar um parceiro estratgico do negcio.
A norma ISO/IEC20000, que, em linhas gerais, uma norma que atesta que a empresa adota a
ITIL
, tem como objetivo avaliar a conformidade de uma organizao com o planejamento, estabe-
lecimento, implementao, operao, monitorao, anlise crtica, manuteno e melhoria de um
sistema de gesto de servios.
CAPTULO 5
45
I TI L

Se a organizao no consegue comprovar que realiza o ciclo PDCA em seu sistema de gesto
(ou seja, nos processos de gerenciamento de servio), ela no obtm a recomendao para a cer-
tifcao ISO/IEC20000.
Atualmente, existem muitas organizaes onde o planejamento e implementao das prti-
cas de gerenciamento ocorrem, mas essas prticas no so analisadas criticamente em uma base
regular para identifcar desvios e oportunidades de melhoria, ou seja, o ciclo PDCA nunca feito
por completo.
Com isso, tais organizaes no conseguem compreender o estado de sade atual dos pro-
cessos e nem tomar decises assertivas, simplesmente porque no tm a menor noo de como
andam os processos.
Desafios mais comuns
Integrao
Uma boa integrao com o processo de gerenciamento de incidentes depende de ferramentas
que possam correlacionar incidentes e problemas, manter uma Base de Dados de Erros Conheci-
dos, ter uma interface com a BDGC (em ingls, CMDB), entre outras.
Equipe
No fcil criar uma boa sinergia entre as equipes de segundo e terceiro nvel e a esquipe do
Service Desk (primeiro nvel).
Os confitos e a falta de comunicao entre estas equipes so uma tradio. Alm disso, as
mesmas equipes que atuam no Gerenciamento de Problemas tambm atuam no gerenciamento
de incidentes. E apagar os incndios sempre vai ser a prioridade nmero um.
Riscos mais comuns
Sobreposio de papis confitantes
Em um cenrio onde o gestor de incidentes assume tambm o papel de gestor de problemas,
natural que seja priorizado o gerenciamento de incidentes, e isso coloca em risco o sucesso do
processo de Gerenciamento de Problemas.
Gargalos
Outro possvel risco so os gargalos gerados por critrios de identifcao inadequados. Este
assunto j foi bastante comentado em outros captulos e sees deste livro.
Resistncia mudana
Este um desafo comum em qualquer iniciativa para estabelecer uma nova forma de se fazer
as coisas.
Falta de apoio gerencial
A cultura de seguir um processo sem um patrocinador de peso sempre vai ser mais difcil.
CAPTULO 5
46
I TI L

Todos os termos, defnies e acrnimos utilizados neste livro podem ser consultados na lti-
ma verso disponvel do glossrio ofcial da biblioteca ITIL
no endereo:
http://www.itil-ofcialsite.com/InternationalActivities/ITILGlossaries_2.aspx
GLOSSRIO
47
I TI L

Ren Chiari formado em Gesto de Ambiente Internet e Redes de Computadores, possui as
certifcaes 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 profssional, 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 Prti-
ca (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:
http://br.linkedin.com/in/renechiari
SOBRE O AUTOR

Cms Files 2206 1394648288EBOOK+ +GPRO

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cms Files 2206 1394648288EBOOK+ +GPRO

Uploaded by

Copyright:

Available Formats

02

uma Marca Comercial Registrada do Cabinet

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

, ou Information Technology Infrastructure Library, uma biblioteca de melhores prticas

, podemos identifcar claramente uma conexo entre os cenrios que os princpios da

deu o nome de PROBLEMAS e defniu um processo especialmente

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

na Prtica, muito conhecido no mercado de TI nos

Service Manager, e desde l temos par-

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

. Em relao a outros processos de Gerenciamento de Servios

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

sugere essa abordagem pra implementao de processos de gerenciamento

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

, que provavelmente so prxi-

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

NA PRTI CA GERENCI ANDO PROBLEMAS DE I NFRAESTRUTURA E SERVI OS DE TI

You might also like