ITIL e o Gerenciamento de Problemas: Métodos de Solução de Problemas

Olá Caro leitor,

Dando continuidade no assunto gerenciamento de problemas, que pode ser visto aqui, vamos trazer hoje alguns métodos que o ITIL indica para utilizar neste processo.

Muitos dos métodos descritos abaixo já utilizamos no dia-a-dia, mas só não sabemos o nome. Algumas ferramentas de service desk trazem junto no módulo de gestão de problemas alguns deles.

É importante entender o método antes de “sair usando”, pois no dia-a-dia a tendência é não usarmos em função da correria, demorando muito mais para resolver problemas em função da desorganização e falta de foco.

gestao-itil-solucao-problemas-governanca-ti

Imagem via Shutterstock

Para resolver um problema, é preciso primeiro clarificar “qual o problema”. Isto parece óbvio, mas muitas vezes saímos resolvendo sem saber exatamente qual o problema.

Então vamos lá:

Análise cronológica

Procura colocar os fatos em ordem de tempo para identificar o tempo e a sequência dos eventos. No caso de muitos problemas, vários fatos ocorrem antes e durante a ocorrência do problema. Colocar os fatos em ordem pode ajudar e muito na identificação da causa.

Análise de dor

Quantifica o impacto e urgência dos incidentes ou problemas (ex.: qtd usuários afetados, duração do downtime e custo para o negócio). Isto ajuda a priorizar ações de solução e/ou melhoria. A fórmula básica é:

Valor = (No. Incidentes) * (duração) * (severidade) * (peso)

pain_value_analysis-300x245

Kepner e Tregoe

Técnica para solução de problemas dividida em 5 estágios:

  • Definir o problema
  • Descrever o problema em termos de identidade, local, tempo e tamanho
  • Estabelecer as possíveis causas
  • Testar a causa mais provável
  • Verificar a verdadeira causa

Brainstorming

Pessoas trocam idéias juntas. No brainstorm não se julgam idéias, apenas se registra. Pode ser feito presencial, via e-mail, com flipchart entre outros.

5 porquês

Buscar encontrar a causa do problema sempre questionando a causa anterior. Ex.:

  • Meu carro parou de funcionar. Por quê?
  • Porque faltou gasolina. Por quê?
  • Porque não consegui colocar hoje. Por que?
  • Porque hoje é feriado e não tem nenhum posto aberto. Por que?
  • Porque não me planejei corretamente para a viagem. A causa é a falta de planejamento da viagem.

images_5_whys

Isolamento da falha

Acontece na reexecução das rotinas para identificar aonde está o problema e aonde não está o problema. Começa-se pela execução da transação do primeiro CI, partindo para o segundo e assim em diante.

Mapa de afinidade

Organiza uma grande quantidade de informações por assunto. Executada após um brainstorm inicial.

Teste de Hipóteses

O método é utilizado para uma lista de possíveis causas de problemas com base no conhecimento. Informações do registro de problemas e incidentes são utilizadas.

Observação técnica

Há problemas que ocorrem de forma intermitente. Este método Junta uma equipe técnica com especialistas de vários assuntos relacionados para focar na solução do problema. O objetivo é monitorar eventos em tempo real e situações específicas.

Ishikawa

Também conhecido como espinha de peixe, é uma forma de organizar idéias. É utilizado para organizar o brainstorm em tópicos. Facilita a visualização, análise e a discussão das possíveis causas do problema.

diagrama01_peixe-300x170

Pareto

Tem o objetivo de separar as causas mais possíveis das mais triviais, utilizando a proporção 80/20. Desta forma você consegue atacar as causas que mais geram problemas. Tendo em mãos as possíveis causas, é preciso medir cada uma para verificar a quantidade de ocorrências. O método sugere atacar as 20% das causas que resolvem 80% dos problemas. Isto ajuda a priorizar os problemas a serem resolvidos primeiro.

Pareto-300x225

MASP

Este método não é descrito pelo ITIL, mas é bastante utilizado. A sigla quer dizer “Método de Análise e Solução de Problemas”. Este trabalha em 8 passos:

  1. Identificação do problema: Qual é o problema que quero resolver?
  2. Observação: Verificar as características do problema, quando ocorre e etc.
  3. Análise: Determinar as principais causas do problema. Identificar as hipóteses e testar as mais prováveis.
  4. Plano de Ação: Se for o caso é necessário criar um plano de ação com as ações a serem realizadas para resolver o problema.
  5. Ação: É colocar em prática o plano.
  6. Verificação: Verificar se o problema foi resolvido de fato ou se novas ações precisam ser feitas para solução.
  7. Padronização: Uma vez resolvido o problema, pode ser necessário alterar algum procedimento, processo e etc.
  8. Conclusão: Revisão do processo e planejamento futuro.

Mais informações sobre este método: http://bit.ly/1aAcxf7

Concluindo

Existe uma série de cursos e treinamentos no mercado sobre os métodos descritos acima. É muito interessante conhecê-los para ser mais assertivo no dia-a-dia.

E você, utiliza algum método? Caso positivo, compartilhe suas experiências conosco!

Espero ter ajudado. Até a próxima!

Emerson Dorow

Mais artigos deste autor »

Experiência de 10 anos na área de TI. Coordenador de suporte de serviços de infraestrutura e cloud computing. Mantenedor do site http://www.governancadeti.com.

Certificado em ITILv3 Intermediate, Cobit v4.1 Foundation, HDI-SCM, Linux Professional Institute (LPI) Nível 1 e IBM Tivoli Monitoring Deployment V6.2 Professional. É graduado em Sistemas de Informação pela Uniasselvi Blumenau e pós-graduando em Governança de TI pelo Senac Florianópolis e MBA em gestão de TI pelo INPG.

Entusiasta de assuntos relacionados a gestão de serviços em TI, governança de TI, Gestão de Projetos, liderança, gestão de equipes e negócios.


1 Comentários

Wilson Junior
1

Parabéns pela forma como abordou o assunto. Direto e de fácil compreensão. Tenho acompanhado os artigos aqui no site mas não encontro um que me ajude a entender uma situação dentro da gerência de problemas que é: quando uma investigação esgota as possibilidades de ações do Suporte para resolver incidentes relacionados a capacidade de disco, como isto deve ser tratado, pois algumas vezes depende de uma revisão da arquitetura (desenho mal dimensionado) ou mesmo da compra de um disco maior. Neste caso o ticket de problema deve ser fechado? Quem passa a acompanhar a questão?

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!