Escolar Documentos
Profissional Documentos
Cultura Documentos
02
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 Proble-
mas e o desenvolvimento desta obra.
03
NDICE
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
Identificao 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 Afinidade 25
5 porqus 26
Teste de Hipteses 26
Posto de Observao Tcnica 27
Diagrama de Ishikawa (espinha de peixe) 27
Kepner-Tregoe 29
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 Identificao de Problemas 39
Base de Dados de Erros Conhecidos (BDEC) 40
Estruturas funcionais 41
Perfil do profissional de Gerenciamento de Problemas 42
Prazos (SLA) 43
Critrios de avaliao para ferramentas 43
Relatos de Servio e Melhoria Contnua 44
Desafios mais comuns 45
Riscos mais comuns 45
GLOSSRIO 46
SOBRE O AUTOR 47
Quantas vezes j nos deparamos com situaes (na maioria das vezes indesejveis) que cau-
sam 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 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 flexvel 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:
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 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 especficos. Entre esses modelos, faz-se necessrio destacar aqui, especificamen-
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 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 par-
grafo 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 dis-
ciplina de Gerenciamento de Servios, uma vez que engloba todo o contexto e o esprito de me-
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 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 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 profissionais 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.
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 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 profissionalizao 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, 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 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 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
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 profissionais especializados que lidam com o Gerenciamento de Problemas
na prtica. Alguns dos temas abordados raramente sero encontrados em outras literaturas.
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 gra-
ves. 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 con-
torno/temporria igual a um Erro Conhecido.
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 pro-
por 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.
Modelos de Problema
Muitos problemas podem realmente ter uma caracterstica bastante exclusiva, e por isso pre-
cisam 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 pro-
blemas 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 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;
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.
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 im-
portantssima, e um dos segredos de um processo bem sucedido de Gerenciamento de Problemas.
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 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 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)?
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 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 financeira. Esta avaliao deve ser posteriormente refinada durante a atividade
de investigao e diagnstico.
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 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 justificvel 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 confirmar a eficcia 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 verificado 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).
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
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 inves-
timentos 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 pro-
cessos, 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 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
Anlise Cronolgica
A anlise cronolgica indicada pra lidar com problemas complexos, onde pode haver relatos confli-
tantes sobre o que e quando exatamente aconteceu. Nestes casos, pode ser til documentar brevemente
a cronologia dos eventos. Com isso, possvel:
1. Identificar eventos que foram gerados por outros eventos;
2. Identificar fatores que contriburam com o impacto do problema;
3. Desconsiderar hipteses no justificveis 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.
Figura 4
Figura 5
Diagrama de Afinidade
O diagrama de afinidade de certa forma, uma extenso ou sequncia do resultado final 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 classificadas e organizadas para revi-
so e anlise.
O princpio bsico do diagrama de afinidade 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 fica 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 identificar as categorias ou agrupamentos.
A figura 6 representa de forma didtica o passo a passo na construo do diagrama de afinidade.
Figura 6
5 porqus
Apesar de ser uma tcnica relativamente simples, eficiente para a identificao 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. Eficaz. 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 sofisticadas.
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 eficcia 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 conflito 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.
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 filhas, as quais devero ser relacionadas atravs de uma seta
na horizontal, que direcione diagonal ligada a 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 filhas para alguma categoria, no h problema.
Podem existir tambm causas filhas de segundo nvel, as quais devem ser relacionadas s suas
causas filhas de primeiro nvel por meio de uma seta diagonal.
Por fim, 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 eficiente atribuir uma pontuao, de 0 a 10, para cada uma
das causa-filhas 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.
Kepner-Tregoe
Kepner-Tregoe uma tcnica muito til para investigar profundamente a causa de um proble-
ma. Ela possui os seguintes Estgios:
1. Definir o problema;
2. Descrever o problema;
3. Estabelecer as possveis causas;
4. Testar a causa mais provvel;
5. Verificar 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 Definir o Problema
A anlise do problema comea com a definio 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 definio de
um mesmo problema:
O servidor travou.
Essa certamente no a melhor definio de um problema. importante incluir mais informa-
es, que resultem em uma definio de fcil compreenso, e que no seja suscetvel a interpre-
taes erradas.
Uma definio 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 definio 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 definio 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 flip chart, um papel, ou mesmo o MS-Excel, como o caso des-
crito no exemplo.
A figura 8 descreve os quatro aspectos de qualquer problema:
a. O que ,
b. Onde ocorreu,
c. Quando ocorreu,
d. Na medida em que ela ocorreu.
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-
cficas 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.
Figura 9
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.
Figura 10
Figura 11
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 eficiente.
Apresento seguir um roteiro passo a passo sobre como realizar a anlise de Pareto:
1. Identificar 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 firmware das mquinas.
* Esta resposta uma pista importante para a identificao da causa raiz do problema.
Mapa de Aplicabilidade
Na figura 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
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 figura 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 .
Este ranking tambm pode ser criado utilizando outros critrios e filtros. O nico cuidado a ser
tomado utilizar critrios que realmente reflitam recorrncias. Quanto mais especfica for a cate-
gorizao, melhores so as chances de identificar as recorrncias reais, e no um agrupamento de
vrios incidentes distintos.
A figura 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 significncia para os servios de TI.
E, finalmente, a figura 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 figura 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.
Figura 16
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 justificar 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 definido 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.
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 classificao
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, definir 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.
Definio 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 definio de polticas, especialmente aquelas relacionadas identificao de problemas.
O hbito de reportar e analisar criticamente o desempenho do processo, periodicamente. Pode
no parecer to importante, mas faz toda a diferena.
simples. Esses erros so identificados 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 flag?
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-
cifico para o registro de problema, com o nome Erro Conhecido, ou atravs de um campo custo-
mizado (flag) dentro de um registro de Problema.
Validao dos Erros Conhecidos
Para garantir a confiabilidade 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 significa 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 finais.
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 figura 17 mostra uma viso de como normalmente os processos esto distribudos entre as
reas funcionais das organizaes de TI.
Figura 17
Por outro lado, o analista tcnico atual possui habilidades tcnicas avanadas e habilidades
superficiais em gerenciamento. Com isso, apesar deste profissional 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 perfil ideal de um bom profissional 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 significa 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 profissional 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 definir 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 definir prazos para o Gerenciamento de Problemas. Os principais benefcios
desta prtica so:
Maior percentual de problemas com causa identificada. A partir do momento que se define
um prazo limite pra identificao 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 profissionais.
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 eficincia das investigaes e diagnsticos devido
presso exercida por estes prazos.
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-
tificao 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 identificar 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.
Todos os termos, definies e acrnimos utilizados neste livro podem ser consultados na lti-
ma verso disponvel do glossrio oficial da biblioteca ITIL no endereo:
http://www.itil-officialsite.com/InternationalActivities/ITILGlossaries_2.aspx