Você está na página 1de 28

Ren Abrileri Chiari

ITIL NA PRTICA: GERENCIANDO PROBLEMAS DE INFRAESTRUTURA E SERVIOS DE TI

Srie 1 de 3
Uma abordagem prtica para o planejamento, implementao, operao e melhoria contnua.

1 Edio So Paulo 2013

ITIL uma Marca Comercial Registrada do Cabinet Office no Reino Unido e em outros pases

Esta obra tem apenas como objetivo contribuir com a comunidade de profissionais de Gerenciamento de Servios de TI. Como apoio so usadas referncias de outros materiais sem infringir direitos autorais de terceiros.

Dedico este livro especialmente a minha esposa Renata e ao meu cachorro e fiel companheiro Tomas. Sem o apoio e a pacincia deles esta obra no teria sido possvel. Este livro tambm dedicado aos amigos e profissionais Andr Jacobucci, Andr Bernardo, Roberto Cohen, Vladimir Abreu, Eduardo Abrileri Chiari e tantos outros que, de uma forma ou de outra, contriburam com a minha motivao e amadurecimento sobre o tema Gerenciamento de Problemas e o desenvolvimento desta obra.

Prefcio
Quantas vezes j nos deparamos com situaes (na maioria das vezes indesejveis) que causam impactos significativos em nossas vidas, que nos do aquela sensao de dja vu (ou seja, que j aconteceram antes), e que no fazemos a menor ideia do motivo pelo qual ocorreram? Certamente, cada um de vocs que est iniciando a leitura deste livro agora perder a conta ao pesquisar a memria por alguns minutos... Situaes como estas so objetos de pesquisa e prtica h vrias dcadas em todo o mundo, e muitas foram as proposies para identificar formas de resolv-las. Fazendo uma leve retrospectiva at os anos aps a 2. Guerra Mundial, podemos ver o surgimento dos princpios da Qualidade Total na indstria, pelas mentes brilhantes de personagens tais como Deming, Juran e Feigenbaum, e que nos legaram, entre vrias tcnicas e ferramentas da qualidade, o famoso ciclo de melhoria contnua, mais conhecido como Ciclo PDCA. Esta ferramenta nos mostra que qualquer processo de melhoria deve ser permanente e ser executado em ciclos de planejamento de atividades, execuo dessas atividades, checagem dos resultados reais dessas atividades e atuao na correo dos desvios em relao aos resultados previstos. Algum tempo mais tarde, entre as dcadas de 80 e 90, vemos surgir uma estratgia para alcanar, maximizar a manter de forma sustentvel o sucesso de uma organizao, baseada em um sistema abrangente e flexvel envolvendo elementos como a compreenso precisa das necessidades (ou situaes) dos clientes, a utilizao criteriosa de fatos, dados e de anlises estatsticas, alm de um foco concentrado na gesto e na melhoria dos processos de negcio. Tal estratgia, denominada Seis Sigma, tem como linha mestra uma metodologia cclica composta por 5 etapas: Definir (os objetivos de melhoria), Medir (a situao atual), Analisar (as medies e identificar as reais causas da situao atual), Melhorar (ou seja, desenvolver ideias e aplicar solues para solucionar a situao) e Controlar (os resultados da soluo aplicada). Podemos notar aqui uma nova roupagem para o velho e bom Ciclo PDCA... Nos anos 90, podemos ver a aplicao de todos esses conceitos em uma rea particularmente interessante chamada Tecnologia da Informao (conhecida pela sigla TI), e o surgimento de uma multiplicidade de modelos de melhores prticas, aplicados TI como um todo ou a alguns de seus segmentos especficos. Entre esses modelos, faz-se necessrio destacar aqui, especificamente, a ITIL, ou Information Technology

Infrastructure Library, uma biblioteca de melhores prticas para a disciplina de Gerenciamento de Servios (de TI). Na ITIL, podemos identificar claramente uma conexo entre os cenrios que os princpios da Qualidade Total e do Seis Sigma identificavam como oportunidades de melhoria de processos, e aquelas situaes indesejveis, recorrentes e sem causa definida que mencionei no primeiro pargrafo deste prefcio. A essas situaes, a ITIL deu o nome de PROBLEMAS e definiu um processo especialmente destinado a gerenci-los. Segundo este processo, um problema deve ser devidamente detectado, classificado, ter seu impacto avaliado, priorizado, investigado at a descoberta de sua causa raiz e resolvido por meio de uma soluo de contorno ou (preferencialmente) definitiva, que certamente envolver uma mudana na infraestrutura que suporta os servios prestados por uma organizao. O processo de GERENCIAMENTO DE PROBLEMAS pode ser considerado um dos pilares da disciplina de Gerenciamento de Servios, uma vez que engloba todo o contexto e o esprito de melhoria contnua do Ciclo PDCA. Por outro lado, talvez seja um dos processos mais incompreendidos e, consequentemente, difcil de ser implementado nas organizaes. exatamente este processo o foco deste livro. Nele, Ren Chiari procura descrever o processo de forma clara, descontrada e recheada de dicas e exemplos prticos e reais, provenientes de sua experincia profissional como consultor especialista, e das riqussimas discusses estimuladas no seu blog ITSM na Prtica (que sucedeu o ITIL na Prtica, muito conhecido no mercado de TI nos ltimos anos). Conheci o Ren h alguns anos em um curso de ITIL Service Manager, e desde l temos participado conjuntamente de vrias iniciativas e compartilhado muitas ideias acerca da disciplina de Gerenciamento de Servios, de Governana de TI e das tendncias futuras para a aplicao de melhores prticas. Para mim, uma honra muito grande endossar esta iniciativa, que certamente uma bela contribuio para a formao dos profissionais de TI (ou melhor, de servios) no mercado brasileiro. Espero que todos vocs encontrem neste livro muitas respostas (e tambm mais perguntas) sobre como resolver e gerenciar os seus problemas no dia a dia. Vladimir Ferraz de Abreu

Apresentao
Problemas. Ningum gosta. Ningum quer. Seja na vida pessoal ou no mundo corporativo. Em geral, os problemas so definidos como algo indesejvel. A convivncia frequente com problemas nos expe ao caminho oposto a uma vida saudvel. Seja como for, a convivncia contnua com problemas no estimulada em nossa cultura atual, que se idealiza em um mundo sem problemas. Um processo que se prope a gerenciar problemas aparentemente parece estar na contramo, visto que a sua razo de ser , basicamente, estimular os problemas atravs uma srie de atividades investigativas com o objetivo de evit-los e, consequentemente, equilibrar e estabilizar a infraestrutura e os Servios de TI. A lgica aparentemente contraditria entre as vises do mundo corporativo e da nossa vida pessoal, onde um estimula e o outro repudia, certamente est na sobreposio conceitual da palavra problema. Esta pode ser a causa de algumas resistncias na adoo das prticas de Gerenciamento de Problemas preconizadas pela ITIL. Em relao a outros processos de Gerenciamento de Servios de TI, as prticas de Gerenciamento de Problemas ainda so bastante subutilizadas, quanto aos benefcios que se prope a trazer e sua prpria profissionalizao no mercado de trabalho. A proposta deste livro esclarecer todos os conceitos envolvidos no processo de Gerenciamento de Problemas, destacar a importncia destas prticas dentro do contexto geral do Gerenciamento de Servios de TI, com exemplos prticos e vivncias pessoais do autor e, principalmente, influenciar o seu uso nas organizaes de TI. O contedo deste livro est dividido em quatro captulos, descritos a seguir:

Captulo 1 Introduo Trata-se de um capitulo introdutrio, onde ser feita a contextualizao ldica do processo de Gerenciamento de Problemas e os seus principais termos.

Alm disso, tambm traz informaes sobre as vantagens da adoo e tambm as consequncias por no adota-lo.

Captulo 2 Conceitos Bsicos Neste captulo, os conceitos fundamentais do Gerenciamento de Problemas so reforados, para garantir um claro entendimento do contedo presente nos captulos seguintes. Ser trazida a tona as diferenas entre Incidentes e Problemas, o processo de Gerenciamento de Problemas e a atividade de Anlise de Causa Raiz, Modelos de Problema e a Base de Dados de Erros Conhecidos (BEC).

Captulo 3 - Anatomia do Processo de Gerenciamento de Problemas Este captulo rene toda a teoria necessria para conhecer a fundo o processo de Gerenciamento de Problemas, tais como: propsito, escopo, atividades, principais papis e responsabilidades, mtricas e interfaces com outros processos de Gerenciamento de Servios. Ao final deste captulo, o leitor ter pleno conhecimento da estrutura do processo de Gerenciamento de Problemas, e ser capaz de diferenciar seus objetivos e termos quanto a outros processos de gerenciamento de servios, particularmente o Gerenciamento de Incidentes.

Captulo 4 - Tcnicas de Determinao de Problemas No basta saber o que fazer. Tambm preciso saber como. Este captulo aborda as diversas tcnicas de determinao de problemas disponveis e amplamente praticadas em diversos contextos de qualidade e melhoria contnua, das mais simples s mais complexas. Algumas incluem um roteiro passo a passo detalhado e um mapa de aplicabilidade das tcnicas apresentadas para cenrios conhecidos.

Captulo 5 Implementao do processo de Gerenciamento de Problemas no mundo real No ltimo captulo, so apresentadas as principais questes que devem ser consideradas para a implementao do processo de Gerenciamento de Problemas de forma bem realista. So apresentadas tambm as formas mais convencionais de realizao do processo no dia a dia, tanto as reativas quanto proativas.

Alguns temas j conhecidos sero rediscutidos, enquanto outros, menos populares, sero introduzidos, para que o leitor possa ter uma viso completa e todo o embasamento necessrio para implementar prticas de gerenciamento de servios de forma mais assertiva. O contedo deste captulo consolida tanto experincias pessoais quanto consensos gerais discutidos por profissionais especializados que lidam com o Gerenciamento de Problemas na prtica. Alguns dos temas abordados raramente sero encontrados em outras literaturas. Neste eBook Srie 1, voc ter acesso aos captulos 1 (Introduo), 2 (Conceitos Bsicos) e 3 (Anatomia do processo). Os demais captulos estaro disponveis na Srie 2 (Tcnicas) e na Srie 3 (Implementao).

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

Sumrio
Prefcio Apresentao Sumrio Captulo 1 Introduo Contextualizao Motivos para adotar o processo Consequncias por no adotar o processo Captulo 2 Conceitos Bsicos Incidentes X Problemas Gerenciamento de Problemas X Anlise de Causa Raiz Modelos de Problema Base de Dados de Erros Conhecidos (BEC) Captulo 3 - Anatomia do Processo de Gerenciamento de Problemas Propsito Escopo Atividades Identificao do Problema Registro do Problema Categorizao do Problema Priorizao do Problema Investigao e Diagnstico do Problema Desenvolvimento de Soluo de Contorno para o Problema Registro de Erro Conhecido Resoluo do Problema Fechamento do Problema Anlise Crtica de Problemas Graves Entradas e Sadas/Interfaces Papis e Responsabilidades Gestor de Problemas Analista de Problemas Mtricas Captulo 4 - Tcnicas de Determinao de Problemas Anlise Cronolgica

Anlise de Valor do Impacto Brainstorming (tempestade de ideias) Diagrama de Afinidade 5 porqus Teste de Hipteses Posto de Observao Tcnica Diagrama de Ishikawa (espinha de peixe) Kepner-Tregoe Anlise de Pareto Matriz do /NO Mapa de Aplicabilidade Captulo 5 - Implementao do processo de Gerenciamento de Problemas no mundo real Prticas de Gesto de Projetos: por que usar? Abordagens proativas e reativas O caminho natural da maturidade Implementao orgnica Requisitos mnimos Critrios de Identificao de Problemas Base de Dados de Erros Conhecidos (BDEC) Estruturas funcionais Perfil do profissional de Gerenciamento de Problemas Prazos (SLA) Critrios de avaliao para ferramentas Relatos de Servio e Melhoria Contnua Desafios mais comuns Riscos mais comuns Glossrio

Captulo 1 Introduo
Contextualizao
Para entender melhor o contexto do Gerenciamento de Problemas, vamos refletir sobre uma situao bem cotidiana: Quando contramos uma gripe, um resfriado ou alguma outra doena mais sria, ns sofremos reaes, como tosse, febre, vmito, dores de cabea, etc. So sintomas que apresentamos quando nosso organismo no est funcionando como deveria, e que podem prejudicar a nossa sade e as nossas atividades rotineiras de alguma forma. De acordo com a frequncia e a gravidade dos sintomas, muitas vezes necessrio buscar a sua causa, para assim poder combater a origem, evitar a recorrncia ou consequncias mais graves. Nestes casos, normalmente procuramos um mdico especialista e somos submetidos a uma srie de exames e diagnsticos. Quando finalmente a causa do(s) sintoma(s) identificada, temos duas possibilidades: 1. Tratar a causa de forma definitiva (antibitico, cirurgia, etc.); 2. Quando o tratamento definitivo da causa no possvel, como uma doena sem cura, ou mesmo quando o tratamento no seja vivel, os sintomas podem ser aliviados ou controlados atravs de solues temporrias (medicamentos, terapia, etc.) que so indicadas pelo mdico especialista. No contexto da infraestrutura e dos Servios de TI tambm funciona assim. A diferena que os sintomas so as falhas que ocorrem na operao normal de um servio de TI (ex.: uma aplicao apresentando erro, internet lenta, um e-mail que no sai da caixa de sada). Com isso, podemos chegar ao consenso de que um incidente nada mais do que um sintoma. causa no identificada de um ou vrios incidentes (sintomas, falhas), dse o nome de Problema. J causa conhecida de um problema e com ao menos uma soluo de contorno associada, d-se o nome de Erro Conhecido. Portanto, causa raiz conhecida associada a uma soluo de contorno/temporria igual a um Erro Conhecido.

Motivos para adotar o processo


Existem vrias possveis justificativas para se adotar o processo de Gerenciamento de Problemas, tais como: Maiores nveis de disponibilidade dos servios, ao reduzir o nmero e a durao dos incidentes. (e sabemos que a disponibilidade tem um reflexo direto na satisfao dos clientes). Aumento da produtividade das equipes de TI ao reduzir trabalhos no planejados causados por incidentes. Com isso as equipes de suporte aos servios vo poder alocar um tempo maior em projetos de melhoria, inovao, e outras aes que tragam mais benefcios ao negcio. Aumento da eficcia e da rapidez no tratamento dos incidentes ao manter uma base de problemas e Erros Conhecidos, assim como de suas respectivas solues de contorno. Com isso, tambm se evita o acionamento de grupos de suporte especializados (comumente conhecidos como suporte de segundo ou terceiro nvel) para o atendimento de casos simples, cuja soluo apropriada desconhecida pelo Service Desk (ou Central de Servios). Reduo dos gastos com solues de contorno ou correes ineficazes; uma vez que tais solues de contorno sero, na maior parte dos casos, desenvolvidas e, principalmente, validadas por especialistas. Reduo do custo e do esforo para tratar incidentes que se repetem.

Com a diminuio da quantidade de incidentes (que s acontece com um bom processo de Gerenciamento de Problemas), possvel sair do status de TI reativa - aquela focada em apagar incndios para uma TI proativa, focada em inovao e melhorias.

Consequncias por no adotar o processo


Olhando o outro lado da moeda: quais seriam as possveis consequncias de no adotar este processo? Seguem alguns exemplos: Potencializao da insatisfao dos clientes e usurios, uma vez que a recorrncia de incidentes causa mais insatisfao do que os prprios incidentes. Isto fato. Quando nos colocamos no papel de clientes de servios (de qualquer tipo de servio), uma falha causa certo incmodo, mas falhas consecutivas so inconcebveis.

Reduo da produtividade das equipes de suporte, o que aumenta os custos para a TI e para a empresa. As equipes tero retrabalho pra resolver os mesmos incidentes vrias vezes e sero envolvidas com maior frequncia devido falta de uma base de conhecimento consistente para o Service Desk. Tudo isso custo!

Aumento da indisponibilidade dos servios, uma vez que a causa raiz das indisponibilidades no investigada. Ou seja, vai acontecer de novo! Exposio da empresa aos riscos e falhas potenciais j conhecidas no mercado, impactando sua imagem.

Captulo 2 Conceitos Bsicos


Incidentes X Problemas
comum que o propsito do processo de Gerenciamento de Problemas seja confundido com o propsito do processo de Gerenciamento de Incidentes. O Gerenciamento de Incidentes se preocupa em resolver uma situao o mais rpido possvel, enquanto o Gerenciamento de Problemas se preocupa em identificar a causa fundamental e propor solues estruturadas para a situao. Veja a seguir a figura 1:

Figura 1

Ao lado direito da figura, a equipe de policiais est preocupada em resolver uma situao de perigo o mais rpido possvel para que no ocorra nenhuma perda significativa (vtimas). Eles no esto preocupados em saber quais as circunstncias da situao, nem quais os motivos. Ao lado esquerdo da figura, os peritos se preocupam em realizar uma srie de investigaes, atravs do uso de diferentes tcnicas, para que assim que a causa raiz for identificada as aes apropriadas sejam tomadas e novas ocorrncias sejam evitadas. Eles querem saber o que motivou a situao, e garantir que esta situao no ocorra novamente, j que foi no possvel evit-la. Recentemente houve um atentado terrorista durante uma maratona em Boston, nos Estados Unidos. Apesar dos esforos constantes do FBI e da CIA em prever atentados terroristas, no foi possvel evitar este atentado especfico. Desta forma, uma concluso qual podemos chegar que a proatividade no uma tarefa to simples, no importa o contexto.

Gerenciamento de Problemas X Anlise de Causa Raiz


importante esclarecer a diferena entre o processo popularmente conhecido como "Anlise de Causa Raiz" (RCA, ou Root Cause Analysis) e o processo referenciado pela ITIL como Gerenciamento de Problemas. O que os diferencia so os seus objetivos. Ambos os processos utilizam as tendncias e a anlise de dados relacionados a incidentes e mudanas mal sucedidas para determinar a causa raiz. Tambm est prevista nos dois processos a realizao de reunies com especialistas no assunto para discutir a provvel causa. E, alm disso, ambos tambm so responsveis por gerar um relatrio detalhado com base nas concluses e distribuir para as partes interessadas (stakeholders). neste ponto que o processo de anlise de causa raiz termina e o processo de Gerenciamento de Problemas continua. O objetivo do processo de analise de causa raiz entender o que deu errado e relatar com preciso o impacto do incidente ou da mudana mal sucedida para que os resultados sejam compreendidos e que um incidente semelhante possa ser evitado no futuro.

Outra caracterstica que, na maioria das organizaes, o processo de analise de causa raiz tem foco apenas nas questes realmente grandes e embaraosas. O Gerenciamento de Problemas, por outro lado, est interessado nas tendncias de problemas e Erros Conhecidos de tamanhos variados e no se contenta somente com a simples identificao da causa raiz de um incidente grave, mas tambm com a identificao de recorrncias sistmicas que podem no parecer to significativas quando vistas isoladamente, mas que, quando consideradas em conjunto - como um padro de repetio, por exemplo - representam um impacto considervel na disponibilidade e na confiabilidade do servio. Por fim, a diferena mais marcante entre o processo de analise de causa raiz e o Gerenciamento de Problemas que a Anlise de Causa Raiz (Root Cause Analysis) focada principalmente na identificao e elaborao de relatrios. Enquanto o Gerenciamento de Problemas tem como objetivo final a eliminao desses problemas sistmicos de uma vez por todas, com a finalidade de melhorar a disponibilidade e confiabilidade dos servios e do prprio gerenciamento de servios.

Modelos de Problema
Muitos problemas podem realmente ter uma caracterstica bastante exclusiva, e por isso precisam ser tratados de uma maneira especifica, mas pertinente considerar que alguns incidentes possam reincidir devido a problemas, digamos, inativos (ou esquecidos) por muito tempo, ou problemas onde a soluo definitiva no justificvel em termos financeiros. Os modelos de problema podem facilitar o tratamento do problema, atravs de uma srie de passos predefinidos, padronizados e, eventualmente, automatizados. Contudo, os modelos de problema no traro respostas de como resolver um problema (nem de forma definitiva e nem paliativa). Quem traz essa informao o Erro Conhecido. A seguir, so relacionados alguns elementos que devem ser levados em considerao na criao de um modelo de problema: 1. 2. 3. 4. Os passos e a ordem cronolgica de execuo dos passos; As responsabilidades, ou seja, quem vai fazer o qu; Os prazos acordados; Os procedimentos de escalonamento (quando os prazos acordados forem atingidos, por exemplo);

5. As atividades de preservao de evidncias. Normalmente, as evidncias que podem ajudar a futura investigao da causa raiz so perdidas durante o tratamento do incidente; por este motivo a preservao de evidncias um elemento muito importante. Segue um exemplo clssico relativo ao uso desta boa prtica: em um servidor que precisa ser reiniciado, as equipes tcnicas normalmente no se preocupam em obter o arquivo de log antes de reiniciar o servidor. O que ocorre que, depois que estes arquivos de log so perdidos, fica mais difcil fazer o diagnstico e, consequentemente, identificar a causa raiz. Por isso, vale a pena gastar algum tempo a mais para preservar evidncias que sero preciosas em uma futura investigao e determinao do problema, e que consequentemente ajudaro na soluo definitiva do problema, concorda?

Base de Dados de Erros Conhecidos (BEC)


muito importante que os Erros Conhecidos sejam armazenados em uma Base de Dados de Erros Conhecidos, ou seja, uma base onde armazenado todo conhecimento prvio sobre incidentes e problemas. Normalmente, um registro de Erro Conhecido deve incluir: a descrio do erro, os sintomas, a soluo de contorno ou a resoluo definitiva. Dependendo da ferramenta utilizada, pode ser possvel associar os incidentes de forma mais prtica, criando um contador. Isso facilita o Gerenciamento de Problemas, pois possvel ter uma viso rpida e clara dos problemas que esto gerando o maior nmero de incidentes. Existem algumas outras questes importantes a serem esclarecidas quando o assunto Base de Dados de Erros Conhecidos. O primeiro erro comum confundir a Base de Dados de Erros Conhecidos com a Base de Conhecimento.

Base de Conhecimento X Base de Dados de Erro Conhecido

A Base de Conhecimento se refere a todo conhecimento da organizao, e vai muito alm das informaes de incidentes e problemas. A Base de Dados de Erros Conhecidos traz apenas conhecimento sobre incidentes e problemas. Em outras palavras, como se a Base de Dados de Erros Conhecidos fosse um pedao ou subconjunto da base de conhecimento da organizao.

Captulo 3 - Anatomia do Processo de Gerenciamento de Problemas


Propsito
O processo de Gerenciamento de Problemas se preocupa em gerenciar o ciclo de vida de todos os problemas, desde sua identificao inicial at sua eventual remoo, passando pela sua investigao e documentao. Ele tem trs objetivos muito importantes: 1. Evitar problemas e seus incidentes resultantes; 2. Eliminar ou reduzir a recorrncia de incidentes; 3. Minimizar o impacto dos incidentes que no podem ser evitados. Para atingir estes objetivos, o Gerenciamento de Problemas busca a causa raiz dos incidentes, documenta e comunica Erros Conhecidos e inicia aes para melhorar ou corrigir a situao.

Escopo
O escopo do Gerenciamento de Problemas focado em dois aspectos: 1. Problemas que esto causando ou j causaram incidentes (conhecido como gerenciamento reativo de problemas) 2. Problemas potenciais que podero causar impactos no, se no forem diagnosticados e tratados a tempo (conhecido como gerenciamento proativo de problemas). Nota: Tanto o processo de Gerenciamento de Problemas quanto suas tcnicas so perfeitamente aplicveis em problemas de qualquer natureza como apoio aos ciclos de melhoria contnua. Neste caso, haver outros possveis desencadeadores do processo. Por exemplo, dentro do contexto de um Sistema de Gerenciamento de Servios (conceito fundamentado em normas como a ISO/IEC20000), qualquer no conformidade em relao aos seus requisitos, como uma reclamao do usurio ou um nvel de servio no cumprido, poderia ser

tambm um desencadeador do processo de Gerenciamento de Problemas, alm dos tradicionais incidentes.

Atividades
Nas prximas sees sero apresentados os detalhes de cada uma das atividades propostas pelo processo de Gerenciamento de Problemas.

Identificao do Problema Diferentemente do Gerenciamento de Incidentes, que busca restaurar a operao normal do servio o mais rpido possvel, o Gerenciamento de Problemas busca identificar os erros ou as condies que esto causando ou podem vir a causar incidentes, propondo solues para tais situaes. A deteco de problemas pode ocorrer de forma proativa, ou seja, antes que um incidente ocorra ou de forma reativa, quando um ou mais incidentes j ocorreram. Essa uma atividade importantssima, e um dos segredos de um processo bem sucedido de Gerenciamento de Problemas. Algumas possibilidades de identificao reativa de problemas podem ser: 1. Suspeita ou deteco pelo Service Desk 2. Anlise de um (ou mais) incidente(s) pelo grupo de suporte tcnico. Seja devido ao seu alto impacto no negcio ou na operao, ou sua taxa de recorrncia. E um problema tambm pode ser identificado antecipadamente, ou de forma proativa: 1. Atravs da deteco automatizada de um erro da infraestrutura ou aplicao (isso pode ser feito atravs de ferramentas de monitorao de eventos, por exemplo). 2. Pela notificao de um fornecedor. (um exemplo clssico so os hotfixes que a Microsoft disponibiliza via Windows Update. So problemas que a prpria Microsoft identifica, investiga, e tambm j disponibiliza a correo). 3. Atravs da anlise regular de tendncias, ou seja, da evoluo de algum determinado indicador de desempenho ao longo do tempo (srie histrica).

Registro do Problema Independentemente da forma de deteco (reativa ou proativa), todos os detalhes do problema devem ser registrados. Isto inclui: sintomas reportados, detalhes dos usurios, detalhes dos servios, detalhes dos equipamentos ou sistemas, detalhes das localidades, sequncia dos fatos, aes tomadas, etc. importante registrar todos os dados relevantes, que podero ser utilizados durante a investigao e diagnstico. Uma boa forma de registrar o histrico completo do problema fazendo referncias aos incidentes causados por ele A data e a hora tambm so importantes, para que seja possvel controlar a "idade" deste problema, e eventualmente usar o escalonamento para prioriz-lo.

Categorizao do Problema Para facilitar as anlises, as pesquisas e a comparao com os incidentes, os problemas podem ser categorizados usando o mesmo sistema de categorias usado para os incidentes. Isto ajuda a organizar a base de conhecimento e a relacionar os incidentes aos problemas. Alm disso, uma boa categorizao vai permitir o correto envolvimento dos grupos de suporte no tratamento do problema, e que dados confiveis sejam gerados para anlise estatstica e de tendncias de problemas. .

Priorizao do Problema O Gerenciamento de Problemas considera a priorizao da mesma forma que o Gerenciamento de Incidentes, ou seja, atravs da relao entre impacto e urgncia. Alm disso, o Gerenciamento de Problemas tambm pode considerar a severidade (na perspectiva da infraestrutura) como um ingrediente adicional na priorizao de um Problema. Algumas perguntas que podem determinar a severidade de um problema so: 1. O sistema pode ser recuperado, ou precisa ser substitudo? 2. Quanto ir custar? 3. Quantas pessoas, com quais competncias, sero necessrias para corrigir o problema? 4. Quanto tempo vai demorar a resolver o problema?

5. Qual a extenso do problema (ex. quantos componentes do servio foram afetados)? O impacto est relacionado extenso do dano potencial (no caso de deteco proativa) ou do dano real (no caso de deteco reativa) relacionado com o problema. O impacto pode estar associado, por exemplo: quantidade de usurios impactados Ao tipo e quantidade de servios impactados Ao nvel de indisponibilidade do servio ou do sistema; s perdas financeiras; Aos danos imagem da organizao; gravidade da violao a leis e regulamentos.

A urgncia est relacionada ao tempo que o usurio ou o negcio tolera esperar pela soluo do problema. Ela pode ser maior ou menor, dependendo do momento em que o problema foi detectado, e das pessoas que podero ser impactadas caso o problema cause um incidente. No momento da priorizao dos problemas, as equipes tambm podem fazer uma avaliao inicial da severidade do problema, ou seja, da extenso ou complexidade do problema nas perspectivas tcnica e financeira. Esta avaliao deve ser posteriormente refinada durante a atividade de investigao e diagnstico.

Investigao e Diagnstico do Problema A atividade de investigao e diagnstico do problema consiste em diagnosticar a causa raiz do problema e propor uma soluo. Existem vrias tcnicas que podem ser usadas para diagnosticar e resolver problemas, e que sero apresentadas com detalhes mais adiante, em um captulo especfico. Durante a atividade de investigao e diagnstico, as informaes de configurao devem ser utilizadas para avaliar de forma mais profunda o impacto e a severidade do problema. As informaes de Erros Conhecidos devem ser pesquisadas para verificar se o problema j ocorreu anteriormente e, caso positivo, qual foi a soluo. Tambm pode ser necessrio tentar recriar o problema em um ambiente de laboratrio, ou testar vrias solues para encontrar a mais apropriada ou econmica.

Desenvolvimento de Soluo de Contorno para o Problema Em alguns casos necessrio (e possvel) encontrar uma soluo de contorno para os incidentes causados por um problema. Geralmente so solues temporrias ou alternativas que no resolvem o problema, mas minimizam o impacto dos incidentes ou ajudam os usurios a superarem as dificuldades. Em muitos casos, tais solues so encontradas pelo processo de Gerenciamento de Incidentes na sua tentativa de restaurar o servio o mais rpido possvel. Quando isto acontece, o processo de Gerenciamento de Problemas responsvel por testar e validar tais solues de contorno, documentando-as no registro do problema ou no registro do Erro Conhecido. Esta validao importante, pois algumas solues de contorno podem ter efeitos colaterais mais nocivos do que o impacto do prprio incidente e, portanto, no devem ser aplicadas. A existncia de solues de contorno diminui a urgncia na soluo do problema - seja reduzindo a probabilidade de ocorrncia de novos incidentes relacionados, seja aumentando a velocidade do tratamento desses incidentes. Quando uma nova soluo de contorno desenvolvida ou validada, recomendvel que ela seja imediatamente documentada no registro de problema e disponibilizada para o Service Desk e para o processo de Gerenciamento de Incidentes.

Registro de Erro Conhecido Os Erros Conhecidos permitem que futuros incidentes e problemas sejam identificados e tratados de forma mais rpida. Por esta razo, os Erros Conhecidos devem ser imediatamente documentados e disponibilizados para o Service Desk e para o processo de Gerenciamento de Incidentes. bom lembrar que um Erro Conhecido somente pode ser caracterizado como tal quando o diagnstico for concludo e uma soluo de contorno for encontrada.

Resoluo do Problema Quando a soluo envolve a adio, modificao ou remoo de qualquer coisa que possa ter um efeito nos servios de TI, sua aplicao s pode ser feita aps a aprovao de uma Requisio de Mudana pelo processo de

Gerenciamento de Mudanas. Nos casos em que a soluo do problema deve ser imediata, deve-se seguir o processo de Mudana Emergencial. Nos casos em que a soluo proposta no for autorizada pelo Gerenciamento de Mudanas, o problema deve ser novamente priorizado e uma nova soluo deve ser buscada. Entretanto, h casos em que a soluo do problema no justificvel na perspectiva do negcio (por exemplo, quando o impacto do problema limitado, mas o custo de sua soluo muito alto). Nestes casos, o registro do problema deve ser mantido aberto. Porem, tais casos no devem ser contabilizados contra o desempenho do processo de Gerenciamento de Problemas e o registro do problema deve permanecer aberto apenas para evitar um possvel retrabalho sobre o mesmo problema.

Fechamento do Problema Quando a soluo do problema aplicada, necessrio confirmar a eficcia da soluo, podendo-se consultar o Service Desk, os grupos de suporte e os usurios do servio. Neste momento o registro do problema tambm deve ser verificado e, se necessrio, atualizado, para garantir que todo o histrico do problema tenha sido documentado. Os incidentes relacionados ao problema tambm j podem ser fechados (algumas ferramentas fazem isto automaticamente).

Anlise Crtica de Problemas Graves Aps a soluo de um problema Grave, altamente recomendvel promover uma reunio com pessoas chave do Service Desk e grupos de suporte para realizar uma anlise crtica e reviso do problema e para documentar lies aprendidas. A discusso pode incluir: 1. 2. 3. 4. 5. 6. As aes que foram feitas corretamente As aes que no deram certo O que poderia ser feito melhor no futuro Como prevenir recorrncia Se houve responsabilizao de terceiros Se h necessidade de aes de acompanhamento

O propsito desta reunio no buscar culpados, mas sim aproveitar ao mximo possvel a experincia adquirida durante o diagnstico e soluo do problema. As lies aprendidas devem servir como base para a criao ou

atualizao de processos, procedimentos, polticas, instrues de trabalho ou registros de Erros Conhecidos, etc. Esta reunio tambm pode ser fonte para a deteco proativa de problemas. Os resultados desta reviso podem ser comunicados a pessoas chave da empresa como forma de demonstrar que os incidentes e problemas graves esto sendo tratados de forma responsvel e a TI est ativamente trabalhando para prevenir futuras recorrncias.

Entradas e Sadas/Interfaces A figura 2 mostra as principais interfaces do processo de Gerenciamento de Problemas com outros processos de Gerenciamento de Servios

Figura 2

Os itens que esto mais prximos do processo de Gerenciamento de Problemas so as entradas para o processo. Os itens que esto mais prximos dos outros processos so as sadas (produtos, entregveis) do processo.

Papis e Responsabilidades
A seguir, uma lista com as principais responsabilidades do Gestor e do Analista de Problemas.

Este assunto ser incrementado nos prximos captulos do livro, com consideraes adicionais sobre o perfil atual e desejvel dos profissionais envolvidos com o Gerenciamento de Problemas.

Gestor de Problemas As atividades e responsabilidades mais comuns do Gestor de Problemas so: Desenvolver fluxos de problema. Trabalhar com outros gestores de processo para assegurar uma abordagem integrada. Planejar, gerenciar e dar suporte ao processo e ferramentas de apoio ao processo. Coordenar interfaces com outros processos de gerenciamento de servio. Manter contato com todos os grupos de resoluo de problemas para assegurar uma rpida resoluo de problemas dentro das metas estabelecidas em acordos de nvel de servio (SLA). Ser responsvel pela Base de Dados de Erro Conhecido. Garantir o fechamento adequado de todos os registros de problemas. Manter contato com fornecedores, contratantes, etc. para assegurar que terceiros cumpram suas obrigaes contratuais, especialmente com relao a resolver problemas e prover informaes e dados relacionados a problemas. Arranjar, executar, documentar e acompanhar atividades relacionadas anlise crtica de problemas Graves.

Analista de Problemas As atividades e responsabilidades mais comuns do Analista de Problemas so: Resolver problemas Analisar problemas para correta priorizao e classificao Investigar problemas at a resoluo ou causa raiz Coordenar aes de outros (se necessrio) para auxiliar a anlise e resoluo de problemas e Erros Conhecidos. Registrar Requisies de Mudanas para resolver problemas. Monitorar o progresso da resoluo de Erros Conhecidos aconselhando a equipe de gerenciamento de incidentes sobre as melhores solues de contorno disponveis. Atualizar a Base de Dados de Erro Conhecido Auxiliar o tratamento de incidentes graves e identificar as suas causas.

natural que em um primeiro momento as organizaes no queiram fazer grandes investimentos em uma equipe exclusiva para lidar com o processo de Gerenciamento de Problemas, principalmente a figura do Gestor de Problemas. Uma das possibilidades neste caso trabalhar com equipes multidisciplinares. Por exemplo, um recurso da rea de qualidade poderia assumir tambm o papel de Gestor de Problemas, pois h uma grande similaridade entre as atividades (desenho e modelagem de processos, controle de qualidade, tcnicas de melhoria contnua, etc.).

Mtricas
importante que as mtricas sejam desenvolvidas para atender a um proposito, uma meta, um Fator Crtico de Sucesso. Em outras palavras, Fator Crtico de Sucesso (FCS) algo que deve acontecer num Processo, Projeto, Plano ou Servio de TI para que o mesmo tenha sucesso. Os Indicadores de Desempenhos so usados para medir se os Fatores Crticos de Sucesso foram alcanados. A Figura 3 mostra quais resultados so importantes para que o processo de Gerenciamento de Problemas seja bem sucedido (FCS) e quais so os indicadores que iro demonstrar se estes resultados esto sendo atingidos (Indicadores de Desempenho). Cuidado com os exageros. Em um processo de implementao inicial do Gerenciamento de Problemas recomendvel utilizar no mximo trs indicadores. Tambm vale lembrar que nenhum indicador tem relevncia se no houver uma meta associada a ele (Ex.: 90% dos problemas registrados no perodo devem ser resolvidos em at X dias/horas).

Figura 3

Concluso
Na prxima srie, voc conhecer as principais ferramentas utilizadas para determinao de problemas e como utiliza-las.

Glossrio
Todos os termos, definies e acrnimos utilizados neste livro podem ser consultados na ltima verso disponvel do glossrio oficial da biblioteca ITIL no endereo: http://www.itil-officialsite.com/InternationalActivities/ITILGlossaries_2.aspx

Sobre a COMMUNIT
A COMMUNIT uma empresa de treinamentos em TI e Gesto com mtodos de ensino que aumentam o engajamento e a absoro de contedo. Acreditamos que todas as pessoas so capazes do que quiserem fazer e tem total potencial para isso. Nosso maior objetivo provocar mudanas positivas na vida dos nossos clientes atravs da capacitao, estimulando-os a liberarem todo seu potencial. Para ns, tudo uma questo de prtica.

Para acessar mais materiais gratuitos ou saber mais sobre a COMMUNIT, acesse o site: www.communit.com.br

Sobre o Autor

Ren Chiari formado em Gesto de Ambiente Internet e Redes de Computadores, possui as certificaes ITIL Service Manager, ITIL Expert, ISO/IEC 20000 Associate/Consultant e COBIT 4.1.

Trabalha h mais de treze anos na rea de TI, sendo os ltimos oito anos com Gerenciamento de Servios de TI. Ao longo de sua carreira profissional, passou por grandes corporaes do ramo de Tecnologia de da Informao e consultorias especializadas, atuando como consultor e instrutor em dezenas de projetos. Entusiasta do assunto Gerenciamento de Servios de TI, um dos fundadores do ITSM na Prtica (antigamente conhecido como ITIL na Prtica), considerada como uma das maiores referncias sobre a temtica no Brasil. Publicou mais de 50 artigos, alguns deles sendo republicados em outros veculos de comunicao, como os portais iMasters, ITweb e Administradores. Alm disso, o autor mantm um grupo de discusso ITSM na Prtica na rede Linkedin, que j assumiu destaque como o maior grupo sobre o tema em lngua portuguesa da rede. O currculo completo do autor pode ser consultado pelo Linkedin no endereo br.linkedin.com/in/renechiari

Você também pode gostar