Há uma visão dogmática de que todo problema complexo de gerenciamento de serviços de TI tem uma única causa raiz, quando muitas vezes existem, na verdade, várias causas.

Quando 21 usinas de energia foram fechadas em apenas três minutos, causando blecautes de até 48 horas para 55 milhões de pessoas no Nordeste dos Estados Unidos e Canadá em 2003, a causa foi atribuída a uma estação de energia em Akron, Ohio. No entanto, uma investigação mais aprofundada revelou uma série de causas contributivas envolvendo pessoas, folhagens crescidas demais, tecnologia desatualizada e monitoramento defeituoso.

Então, por que problemas complexos são tão difíceis de resolver?

Não facilitamos para nós mesmos. Pelo contrário, muitas vezes, as organizações adotaram uma mentalidade (tola) e um SLA de concluir a análise da causa raiz de um problema complexo em 24 horas. Isso leva as pessoas a se concentrarem no “gatilho” (como a estação de energia de Ohio) e resolvê-lo enquanto – como olhar para a ponta de um iceberg – perdem tudo o que está acontecendo abaixo.

Essa abordagem está essencialmente resolvendo o gatilho, mas ignorando todos os problemas subjacentes que precisam ser explorados mais detalhadamente. Às vezes, esse foco na velocidade reflete uma atitude de provar que “não foi nossa culpa”, em vez de encontrar uma resolução de maior qualidade.

Então, para evitar o risco de as pessoas alocarem a culpa e justificarem suas ações, é necessária uma mudança na abordagem ao lidar com a resolução de problemas complexos. Os princípios orientadores da ITIL® 4 fornecem tal abordagem.

Empregando os sete princípios orientadores da ITIL 4

Os princípios orientadores da ITIL 4 combinam conceitos de uma série de melhores práticas – incluindo Agile, Lean e DevOps – e são baseados na realidade, pragmáticos e comprovados.

Existem cinco etapas para a resolução de problemas complexos onde os princípios fazem sentido:

Simplificando o foco

Você pode implantar uma correção mínima viável para resolver o problema, mas depois se concentrar em tornar a correção mais eficaz em uma data posterior? Ele usa os princípios de mantê-lo simples e prático e com foco no valor.

Decida a aparência de “consertado”

Nem sempre podemos “consertar” algo, especialmente se envolver software ou infraestrutura de terceiros. Portanto, pergunte-se se “consertado” é reduzir o risco de um problema acontecer, minimizando seu impacto ou facilitando sua localização antes que aconteça novamente. Este é um ótimo exemplo de como começar de onde você está.

Resolva problemas complexos em etapas

Divida o problema em suas partes componentes, em vez de tentar resolver um grande problema de uma vez. Trata-se de progredir iterativamente com feedback. Por exemplo, em um estabelecimento de varejo, um aplicativo que enviava atualizações de preços de produtos para lojas em lotes estava falhando. Testar as atualizações, enviando-as individualmente, mostrou o que funcionou e o que não funcionou. Assim, a divisão do problema nos ajudou a encontrar a causa subjacente e corrigi-lo.

Saiba que sua correção funcionará

Se você sabe de antemão o resultado que deseja, quais indicadores o ajudarão a garantir que a resolução do problema funcionará? Uma analogia é perder peso: em vez de esperar para entrar na balança, um indicador de atraso, peça à sua academia para ajudá-lo a medir o quanto você se exercita ou use um aplicativo para medir as calorias que você está comendo. Ambos são indicadores iniciais de sucesso! Assim, ao colaborar e promover visibilidade, você pode acessar métricas e feedback que ajudarão a avisar com antecedência sobre o sucesso na resolução de problemas.

Tentativa e erro

Muitas organizações são avessas ao risco, mas, às vezes, você precisa tentar uma resolução potencial para ver se funciona. Por exemplo, se a substituição de uma peça ou componente corrige um problema, você pode rastrear a partir daí para identificar as causas potenciais. Este é outro exemplo de progresso iterativo com feedback.

Reduzindo o risco antes da resolução do problema

Os problemas de TI em 2021 se mostram, comparativamente, muito mais complexos e envolventes do que há 20 anos – e as tecnologias de hoje se interligam demais com nossas atividades diárias.

Se a resolução do problema não for imediatamente visível, tente reduzir a chance de repetição do problema, limitar seu impacto ou tornar mais fácil localizá-lo na próxima vez. Por fim, pare de prometer análises de causa raiz em 24 horas!

Esse conteúdo foi traduzido/adaptado do artigo “Problem resolution with ITIL 4 guiding principles”, publicado pela AXELOS (parceira oficial da PMG Academy). Para ler o artigo em inglês, clique aqui.