ITIL problem management techniques

Uma boa ferramenta de service desk facilita o processo de gerenciamento de problemas, mas as técnicas utilizadas para investigação e diagnóstico devem variar de acordo com a organização. Recomenda-se que as técnicas de investigação sejam flexíveis e baseadas nas necessidades da organização, em vez de serem excessivamente prescritivas.

Como os problemas podem surgir de várias formas e dimensões, é impossível se ater a uma única técnica para encontrar uma solução em todas as situações. Em vez disso, a combinação de técnicas proporcionará os resultados melhores. Um simples problema de conectividade de LAN pode ser resolvido com uma rápida sessão de brainstorming, mas um problema de rede ou VoIP pode exigir uma análise mais aprofundada.

Aqui estão várias técnicas que você pode empregar no processo de gerenciamento de problemas de sua organização.

Brainstorming

Ao estabelecer um diálogo entre os departamentos, você obtém várias perspectivas e novas informações que geram muitas soluções em potencial.

Para ter uma sessão produtiva de brainstorming, você precisa de um moderador que é responsável por:

• Conduzir a direção da reunião
• Documentar as ideias obtidas
• Destacar as medidas a serem tomadas
• Monitorar os itens discutidos
• Evitar que a sessão demore muito

As sessões de brainstorming são mais produtivas quando forem usadas técnicas colaborativas de solução de problemas, como a análise de Ishikawa e o método dos cinco porquês. Essas técnicas serão discutidas mais adiante nesta seção.

Método Kepner-Tregoe   

O método Kepner-Tregoe (K-T) é uma técnica de resolução de problemas e de tomada de decisões utilizada em diversas áreas devido à sua abordagem passo a passo para resolver problemas de forma lógica. Ele é bem adequado para resolver problemas complexos no gerenciamento proativo e reativo de problemas.

O método segue quatro processos:

• Avaliação da situação: avaliação e esclarecimento do cenário
• Análise do problema: conexão da causa com o efeito
• Análise de decisão: ponderação das opções alternativas
• Análise de problemas potenciais: antecipação do futuro

No entanto, a análise de problemas é a única parte relacionada ao gerenciamento de problemas de TI e consiste em cinco etapas.

Defina o problema   

Identificar qual é realmente o problema pode ser um problema em si. Como o gerenciamento de problemas é, por natureza, um esforço colaborativo, ter uma definição abrangente do problema elimina noções preconcebidas que qualquer membro participante possa ter, economizando um tempo considerável.

Por exemplo, se houver uma falha no backup automático de dados de uma organização em um servidor, o problema pode ser definido como:

Falha de backup no servidor

Essa definição realmente descreve a divergência da situação normal, mas exige mais perguntas e informações. Um bom modelo de definição deve ser claro e de fácil compreensão.

Para eliminar a ambiguidade, a definição acima pode ser atualizada para:

Falha no backup de dados em 15 de novembro no servidor nº 34-C

Essa definição oferece maior clareza e poupa os funcionários de perguntas redundantes. No entanto, essa definição pode ser ainda melhor. Suponha que a causa da falha no backup de dados possa ser atribuída a um evento, como a aplicação de um novo patch; então, a análise inicial do problema certamente levaria a esse evento.

Para economizar tempo e esforço, vamos atualizar a definição para:

O backup de dados em 15 de novembro falhou no servidor #34-C após a aplicação do patch 3.124 pelo engenheiro Noah

Essa definição detalhada não deixa margem para perguntas redundantes e fornece uma boa quantidade de informações sobre onde o problema pode estar. Esses minutos extras gastos na definição inicial economizam tempo e esforço valiosos, fornecem um senso lógico de direção para a análise e eliminam quaisquer noções preconcebidas sobre o problema.

Descreva o problema   

O próximo passo é apresentar uma descrição detalhada do problema. O método K-T fornece as perguntas que precisam ser feitas sobre qualquer problema para ajudar a identificar as possíveis causas.

As perguntas abaixo ajudam a descrever quatro partes de qualquer problema:

• Qual é o problema?
• Onde o problema ocorreu?
• Quando o problema ocorreu?
• Qual é a extensão do problema?

Cada uma dessas perguntas exige dois tipos de respostas:

É: Como em, "Qual é o problema?" ou "Onde está o problema?"

e

PODERIA SER, mas NÃO É: Como em, “Onde pode estar o problema, mas não está?”

Esse exercício ajuda a comparar e destacar o que, onde, quando e como está ocorrendo o desvio do desempenho normal nos processos de negócios.

Estabeleça possíveis causas   

A comparação entre o desempenho normal e o desempenho problemático feita na etapa anterior ajuda a selecionar as possíveis causas do problema. Criar uma tabela com todas as informações em um único lugar pode ajudar a fazer a comparação.

Novas causas possíveis se tornam evidentes quando você coloca as informações juntas. Para o nosso problema de exemplo, a causa principal pode ser limitada a:

Erro de procedimento causado pela transferência inadequada de conhecimento pelos engenheiros de Nível 3

Independentemente do problema, uma análise sólida das possíveis causas pode ser feita com base em comparações relevantes.

Teste a causa mais provável   

A penúltima etapa é fazer uma pequena lista das causas prováveis e testá-las antes de chegar à conclusão. Cada causa provável deve seguir esta pergunta:

Se _______ for a causa raiz deste problema, isso explica o que o problema É e o que o problema PODERIA SER, mas NÃO É?

Novamente, é vantajoso preencher todas as informações em uma tabela.

Verifique a verdadeira causa   

A etapa final é eliminar todas as causas improváveis e fornecer evidências para as causas mais prováveis. Com essa verificação, é hora de propor uma solução para o problema. Sem evidências da possível causa raiz, a solução não deve ser tentada.

Análise de Ishikawa ou análise de diagrama espinha de peixe   

A análise de Ishikawa usa a estrutura de espinha de peixe para enumerar as causas e os efeitos de um problema e pode ser usada junto com sessões de brainstorming e com o método dos cinco porquês. A simplicidade na execução de RCA usando um diagrama de Ishikawa não deve iludi-lo quanto à sua capacidade de lidar com problemas complexos.

Para iniciar a análise, defina o problema e use-o como a cabeça da espinha de peixe. Desenhe a espinha e adicione as categorias de onde pode estar a origem de problema como ramificações da espinha de peixe.

Em geral, é mais fácil iniciar as categorias com as quatro dimensões do gerenciamento de serviços: parceiros, processos, pessoas e tecnologia. No entanto, essas categorias podem ser algo relevante para seu problema, ambiente, organização ou setor.

Uma vez que essas categorias formem as ramificações da espinha de peixe, comece a associar as possíveis causas a cada categoria. Cada possível causa também pode se ramificar para detalhar o motivo da ocorrência. Isso pode levar a um diagrama complexo de quatro a cinco níveis de causas e efeitos que, posteriormente, se aprofundará na causa raiz do problema.

Recomenda-se dividir as ramificações maiores em ramificações adicionais, conforme necessário. Alternativamente, fundir ramificações vazias com outras ramificações adequadas mantém a espinha de peixe limpa e fácil de ler. Além disso, você deve garantir que as ramificações sejam preenchidas com causas, e não apenas com sintomas do problema.

Esta análise é novamente um esforço colaborativo e requer um moderador para direcionar as sessões de brainstorming de maneira eficiente. Todos os participantes têm a oportunidade de se envolver, proporcionando uma visão abrangente do problema.

Análise de Pareto   

O princípio de Pareto é uma observação de que quase 80% dos efeitos são provenientes de aproximadamente 20% das causas. Essa observação se aplica a uma ampla gama de assuntos, incluindo o gerenciamento de problemas.

Ao tentar reduzir o número de incidentes que ocorrem em uma organização, é altamente eficiente aplicar a análise de Pareto antes de começar a resolver os problemas. A análise de Pareto prioriza as causas dos incidentes e ajuda a gerenciar os problemas com base em seu impacto e probabilidade.

Essa análise é realizada com a geração de um gráfico de Pareto a partir de uma tabela de Pareto. Uma tabela de Pareto consiste na contagem cumulativa da classificação de todos os problemas. Um gráfico de Pareto é um gráfico de barras que mostra a porcentagem cumulativa da frequência de várias classificações de problemas.

Para criar um gráfico de Pareto, siga as etapas abaixo:

• Colete dados de tickets de problemas a partir da sua ferramenta de service desk.
• Reestruture os dados em categorias com base em diversos atributos.
• Crie uma tabela de Pareto para encontrar a frequência dos problemas em cada classificação em um determinado período.
• Calcule a frequência de ocorrências de problemas em cada categoria.
• Gere a porcentagem de frequência cumulativa em ordem decrescente.
• Demarque os dados em um gráfico para criar um gráfico de Pareto.

A etapa mais importante é reestruturar os dados em um conjunto contável de classificações e atributos.

Esse gráfico ajuda a identificar os problemas que devem ser resolvidos primeiro para reduzir significativamente a interrupção do serviço. Essa análise complementa os métodos Ishikawa e Kepner-Tregoe, fornecendo uma maneira de priorizar a categoria de problemas, enquanto os outros métodos analisam a causa raiz.

É importante lembrar que a regra 80/20 sugere causas prováveis e, às vezes, pode estar incorreta.

Técnica dos cinco porquês   

Cinco porquês é uma técnica simples para RCA porque ela define uma declaração de problema e, em seguida, pergunta "por que?" repetidamente até que a causa raiz subjacente do problema seja descoberta. A quantidade de porquês não precisa ser limitado a cinco e pode ser ajustado conforme o problema e a situação.

A técnica dos cinco porquês complementa muitas outras técnicas de resolução de problemas, como o método de Ishikawa, a análise de Pareto e o método K-T.

Usando o exemplo anterior de falha no backup de dados em um servidor, vamos aplicar a técnica dos cinco porquês.

O processo iterativo acima revela a ausência de um formato padronizado, o que causou a falha no backup de dados.

Para nossos propósitos, o exemplo acima é uma execução simples do método. Em uma situação real, a próxima pergunta depende da resposta à pergunta anterior, portanto, é obrigatório colaborar com as partes interessadas que tenham bom conhecimento do domínio em que o problema se encontra.

Ao adotar partes do método K-T juntamente com a técnica dos cinco porquês, como fornecer evidências para cada resposta antes de validá-la com uma pergunta de retorno, você pode garantir uma análise precisa durante as sessões de resolução de problemas.

Outras técnicas   

Além das cinco técnicas principais, ainda existem várias outras, cada uma com seus pontos fortes únicos. Em geral, a investigação do problema é realizada usando uma combinação de técnicas adequadas à situação. Algumas outras técnicas predominantes na comunidade de gerenciamento de problemas incluem testes cronológicos, análise de árvore de falhas, método de isolamento de falhas, testes de hipóteses e análise de nível de dor. Vale a pena dedicar tempo para aprender muitas técnicas à medida que o processo de gerenciamento de problemas de sua organização amadurece.