Quando o gerenciamento de incidentes embola com o gerenciamento de problemas

Esses dias recebi uma consulta de um sobrinho estudioso.

No dicionário Coheniano, “sobrinho” significa:

Substantivo de dois gêneros que representa pessoa que já realizou curso com Roberto Cohen e tem acesso preferencial e prioritário ao Whatsapp dele.

OK, vamos à dúvida:

Boa tarde, tio…

Estava lendo sobre Gerenciamento de Problemas e sua correlação com os outros processos e gostaria de perguntar sua opinião sobre esse trecho:

Activities from these two practices are closely related and may complement each other (e.g. identifying the causes of an incident is a problem management activity that may lead to incident resolution), but they may also conflict (e.g. investigating the cause of an incident may delay actions needed to restore service).

Qual uma boa estratégia pra evitar esse conflito?

Até onde a equipe de N2 deve ir na investigação da causa, antes de registrar um problema e acionar o N3?

Amei a dúvida.

Trata-se de uma passagem do livro de ITIL.

Antecipo a todos que não sou especialista no assunto, nem mesmo tenho qualquer certificação a respeito.

Por outro lado, isso não me impede de pensar, refletir sobre. E emitir opinião e colocá-la na vitrine para julgamento de terceiros.

Sim, não há problema com crí­ticas. São desses conflitos de pontos de vista que formamos massa crí­tica e deixamos de ser “carneirinhos”.

O alerta do trecho, de forma reduzida e prática, é que se o Gerenciamento de Incidentes se enrolar demais com um chamado, pode atrasar a solução do mesmo e com isso prejudicar o negócio. Seria melhor passar “a bola” de forma rápida para o time de Gerenciamento de Problemas.

Fato

Poucas empresas têm Gerenciamento de Problemas. Infelizmente.

Os motivos são vários:

  1. Desconhecem a diferenciação “Incidentes e Problemas” e jogam tudo no saco chamado “Suporte Técnico”.
  2. Existem aquelas que compreendem a diferença, mas não têm pessoas suficientes para tal.
  3. Ou… As variáveis são muitas. Não importa.

O que é importante e onde o bicho pega são naquelas que já possuem as duas áreas estabelecidas e onde realmente o problema apontado pelo livro pode acontecer.

Primeiro, o ideal

O ideal é o ambiente onde existem os OLAs (Operational Level Agreement ou, aportuguesando, Acordos de Ní­vel Operacional).

Ou seja, as combinações sobre como vamos, dentro de casa, lidar com as situações.

O primeiro time de atendimento para incidentes de tal tipo tem até 1 hora para reestabelecer o serviço. Se não conseguir, passa para o próximo ní­vel que possui sua própria delimitação de tempo e assim por diante.

Mas todos esses ní­veis de atendimento estão tentando reestabelecer o serviço e não propriamente resolver a sua causa.

Exemplos simplórios:

  • “Desligar-e-ligar” é algo que funciona bem no celular da minha esposa quando o som do toque desaparece, apesar de todas as configurações estarem adequadas. O motivo disso? Sei lá!
  • “Substituir a impressora do PDV” é sugestão que também cai bem quando o frente de caixa está sofrendo para imprimir o cupom fiscal no equipamento do supermercado. A razão pela qual surgiu esse problema? Hummm… Deixa pro pessoal de Gerenciamento de Problemas. Eles ganham mais, que padeçam atrás disso.

Ortodoxos do ITIL, estou indo bem? Caso contrário, joguem as granadas. Mas com ternura.

Mas fato é que as melhores práticas permitem isso com seu “adote e adapte”.

E se não temos o ideal?

Aí­ fica até mais simples: cada empresa determinada a maneira com que lida com a situação.

A forma mais comum é promover o jogo de empurra-empurra.

ÓTICA DO SUPORTE: Passei pro Desenvolvimento, mas ele não me deu retorno ainda. E nem vai dar por que na visão dele isso não é prioritário. E a visão do negócio? Bem, isso não importa muito.

ÓTICA DO DESENVOLVIMENTO: Olha como recebi isso daqui? Não tem metade das coisas que preciso para examinar! Vou precisar ligar para o usuário, perguntar isso e ainda tenho um backlog gigantesco de implementações. Quando eles vão começar a resolver alguma coisa lá no suporte?

Ops, Cohen…

Quem sabe voltamos ao Gerenciamento de Problemas?

Mas aí­ é que está: nessas situações não existe Gerenciamento de Problemas.

Quando N1, N2 e N3 são confusamente misturados como pertencendo a Incidentes e Problemas, isso produz falhas conceituais.

Na minha opinião, estes três ní­veis – podem existir mais, cada um faz como quer – pertencem à Gestão de Incidentes.

Cabe a eles botar o usuário a trabalhar o mais rápido possí­vel via gambiarra, solução de contorno ou qualquer outro nome elegante para uma solução meia-boca. A qual não é horrí­vel.

Horrí­vel é o usuário ficar parado e o negócio ser impactado.

Retornando ao trecho em inglês

Do trecho que nos interessa:

“…mas eles também podem entrar em conflito (por exemplo, investigar a causa de um incidente pode atrasar as ações necessárias para restaurar o serviço).”

Bom, minha tí­pica sugestão é que:

  1. Algum prazo precisa ser estabelecido para o Gerenciamento de Incidentes lidar com a situação. Em especial se o impacto ao negócio for severo.
  2. Que o Gerenciamento de Problemas não resmungue que faltam subsí­dios para resolver a questão e que deveriam ter sido coletados preliminarmente pelo Gerenciamento de Incidentes. Estamos falando do negócio parado ou prejudicado. Não se trata mais de cada um cuidar do seu pedaço da pizza, mas impedir que a pizza toda apodreça (TI ou a empresa de tecnologia).

Estude Atendimento de Suporte Técnico

Estudar, seja de que forma for, sempre o coloca em posição melhor do que o seu concorrente, seja ele um colega analista que compete pela mesma vaga, seja uma empresa que diz oferecer um atendimento superior à sua empresa.

Eu tenho três recomendações para você:

  • https://4hd.space – treine todo o seu time em todos os cursos existentes por uma mensalidade única.
  • https://vokyus.com – escolha o curso onde você deseja se aprimorar mais e mande ver.
  • Gestão de Serviços para Help Desk e Service Desk – o tradicional evento onde o tio aqui compartilha três dias com seus futuros sobrinhos conversando sobre como aperfeiçoar os centros de suporte. Próxima edição em 09-10-11 de dezembro de 2020.

Abrazon a todos,

EL CO

2 comentários em “Quando o gerenciamento de incidentes embola com o gerenciamento de problemas”

  1. Muito bom Cohen, minha sugestão é só diferenciar adicionar ao artigo a diferença de incidente e problema.

Deixe um comentário

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