Como montar um Fluxo de Processo de Gerenciamento de Incidente (Chamados) na ITIL 4 e v3

Você sabe como construir um bom fluxo de gerenciamento de incidentes? Se você começou a trabalhar com esse processo a partir da ITIL 4, talvez o seu fluxo possa se beneficiar da ITIL v3.

Isso porque o fluxo de gerenciamento de incidentes na ITIL 4 é uma versão simplificada do fluxo na ITIL v3. Característica recorrente em toda a atualização da última versão, trazendo maior flexibilidade e, também, a maior simplificação dos processos.

No entanto, a simplificação extrema do processo também tem seu lado negativo: a visualização para montar um fluxo completo e útil de gerenciamento de incidentes.

Para sanar essa deficiência, portanto, hoje voltaremos para a ITIL v3, faremos um diagnóstico dessa diferença e compreenderemos o que pode ser aproveitado de um fluxo mais detalhado, sem deixar que ele se torne prescritivo.

O Fluxo na ITIL 4:

Na ITIL 4, o fluxo é simples e só contém esses 6 passos. No entanto, as seguintes questões ficam sem resposta:

E se for uma requisição de serviços? Em que momento pode ser detectado se, na verdade, estamos tratando com uma requisição de serviços, ao invés de um incidente?

Para responder essa pergunta, é importante entender que a ITIL 4 não é prescritiva. Muitas coisas, inclusive a priorização de incidentes, não são nem mesmo etapas obrigatórias. No caso da priorização, por exemplo, só é necessário fazê-la quando a organização não dispõe de recursos suficientes para atender toda a fila de incidentes. Se não há falta de recursos, não há necessidade de priorização.

E se nosso incidente se tratar de um Major Incident (Incidente Grave)?

Essa etapa está presente na ITIL v3, mas não na ITIL 4.

Onde fica o tratamento inicial pela Central de Serviço?

Essa etapa também está presente apenas na ITIL v3. No processo, está apenas descrito a etapa de diagnóstico, mas por quem ele será feito? Pela Central de Serviços ou pelo primeiro, segundo ou terceiro nível de especialistas? Isso abre margem para várias perguntas sobre o fluxo.

Categorização é sinônimo de classificação?

Na ITIL v3, categorização é uma etapa descrita com a função de enviar o incidente para que ele seja tratado pela equipe especializada para tanto. Quando isso não é feito, o incidente pode ser jogado de uma equipe para a outra, atrapalhando o processo e a resolução.

Na ITIL 4, isso fica em aberto.

E o multinível de categorização?

Isso ocorre quando há uma recategorização de um chamado entre a abertura e o fechamento de um incidente, uma situação que pode acontecer em determinados contextos.

Onde e como priorizamos os incidentes?

Quando há a necessidade de priorização, como ocorre na maioria das organizações, em que momentos desse fluxo essa etapa será feita? E de que forma? Isso também é apenas descrito na ITIL v3.

Em que momento escalamos o incidente?

Quando não foi possível resolver a tempo e o incidente deve ser escalado, em que momento isso deve ser feito? Essa etapa, também essencial para o fluxo, é apenas descrita na ITIL v3.

Como avaliar o Incidente após sua conclusão

Na ITIL 4, esse processo é descrito, porém não com o mesmo detalhamento da ITIL v3, do qual podemos nos beneficiar não por seguir de forma rígida, mas para analisarmos nossos próprios processos com um conhecimento mais completo das possibilidades.

E, por último, uma questão que a ITIL 4 responde, mas não a ITIL v3, demonstrando o caráter complementar de ambas: e se o incidente for gerado por um evento?

Ou seja, como devemos proceder quando o incidente é aberto pelo gerenciamento de eventos, e não por um chamado de um usuário?

Dessa forma, veremos que, a partir da observação do fluxo da ITIL v3, muitas das etapas que respondem a essas perguntas são incluídas.

Fluxo de Incidentes na ITIL v3

O fluxo da ITIL v3, em comparação, é muito mais robusto, contém diversas outras etapas. A questão principal é que esse fluxo não é prescritivo, ele deve ser visto como uma sequência de etapas muito mais robusta que traz ferramentas úteis para analisarmos o nosso próprio processo, adotando o que nos for útil e descartando o que não for.

Em resumo, na ITIL v3, as etapas são as seguintes:

1. Identificação do Incidente

Primeiro, estabeleceremos o incidente que deve ser tratado.

2. Registro do Incidente (logging)

O registro é fundamental para a organização, consulta e análise dos incidentes.

3. Categorização do Incidente

A categorização serve para estabelecermos para qual equipe esse incidente deve ser enviado, de acordo com suas características.

4. Priorização do Incidente

A priorização depende do impacto que o incidente pode causar.

5. Diagnóstico Inicial

Se a central de serviços conseguir fazer o diagnóstico inicial e resolver o problema, ótimo.

6. Escalação do Incidente

No entanto, se não a etapa anterior não for possível, o incidente deve ser escalado para uma equipe mais especializada ou para os níveis superiores de gerência.

7. Investigação e Diagnóstico

Aqui, há um diagnóstico mais aprofundado mediante uma investigação mais detalhada do incidente.

8. Resolução e Recuperação

Então, o incidente é resolvido e ocorre a recuperação.

9 Fechamento do Incidente

O incidente é, por fim, fechado.

A expansão do ciclo de vida do incidente através do gerenciamento de disponibilidade

A prática de gerenciamento de disponibilidade pode ser usada para observarmos a expansão do ciclo de vida do incidente, com novas fases que podem ser úteis para o nosso processo:

Observe, por exemplo, as etapas de Reparação ( Repair ), Recuperação ( Recover ) e Restauração ( Restore ), para além do nosso fluxo de incidentes padrão, tanto na ITIL 4 quanto na ITIL v3.

Isso serve para que observemos como o processo de gerenciamento de incidentes pode ser expandido e analisado em seu ciclo de vida para além do estabelecido na ITIL v3 e, sem dúvidas, para muito além da ITIL 4.

Conclusão

Como vimos, há uma imensa diferença de detalhamento entre o fluxo de gerenciamento de incidentes da ITIL 4 e o fluxo da ITIL v3. Muito disso se deve ao fato de que a ITIL 4 busca uma abordagem muito menos engessada, prescritiva, almejando uma flexibilização maior de suas práticas para se adequar à flexibilidade das próprias organizações no mundo atual.

Porém, isso não significa que uma abordagem mais detalhada é necessariamente ruim. A ITIL v3 nos apresenta um número maior de etapas para o fluxo de incidentes, mas não devemos descartá-la ou apenas tomá-la como uma receita que deve ser seguida à risca.

Ao invés disso, uma compreensão mais detalhada sobre as possibilidades de um fluxo de incidentes robustos serve à nossa organização como um guia para que possamos adotar o que nos cabe e descartar o que não será útil, ou o que pode engessar o processo.

Assim, busque sempre todas as ferramentas possíveis, todo o conhecimento e as possibilidades para o seu processo são bem-vindos. O que se deve ter em mente é o senso crítico para decidir o que pode ser aproveitado e modificado para cada contexto individual.