O que é a prioridade de um incidente
A prioridade de um incidente determina a ordem em que os incidentes devem ser tratados pela equipa de suporte. No ITIL 4, a prioridade não é atribuída subjectivamente - resulta da combinação de dois factores objectivos: impacto e urgência.
"A prioridade de um incidente determina a ordem em que os incidentes devem ser tratados. No ITIL, a prioridade resulta da combinação de impacto e urgência."
A fórmula é simples:
Prioridade = Impacto × Urgência
Cada um destes factores tem um significado específico no contexto da gestão de incidentes:
- Impacto: quem e quanto é afectado pelo incidente. Pode ser um único utilizador sem acesso a uma pasta partilhada, ou toda a organização sem acesso ao sistema de email.
- Urgência: quão rapidamente a resolução é necessária. Um incidente que bloqueia o processamento de salários na véspera do pagamento tem urgência máxima, mesmo que afecte apenas um departamento.
A prioridade resultante determina dois aspectos fundamentais: os recursos alocados ao incidente e os tempos de resposta e resolução comprometidos no SLA. Um incidente P1 mobiliza imediatamente todos os recursos necessários; um P5 é agendado para resolução posterior.
Este modelo é usado pelo service desk e por todas as equipas de suporte que trabalham com o ITIL 4, integrando-se directamente com as práticas de gestão de serviços.
Níveis de impacto
O impacto mede o alcance do incidente na organização e nos seus serviços. Quanto mais utilizadores ou processos críticos forem afectados, maior o impacto. A maioria das organizações usa três níveis de impacto, embora algumas adoptem escalas de cinco níveis.
| Nível | Impacto | Descrição | Exemplo |
|---|---|---|---|
| 1 | Alto | Serviço crítico indisponível para grande parte dos utilizadores | Email corporativo em baixo para toda a empresa |
| 2 | Médio | Serviço degradado ou indisponível para um grupo de utilizadores | Impressora de um departamento avariada |
| 3 | Baixo | Serviço afectado para um ou poucos utilizadores com workaround disponível | Utilizador não consegue aceder a uma pasta partilhada |
Para classificar o impacto de forma consistente, o service desk deve responder a perguntas objectivas: quantos utilizadores estão afectados? Qual o impacto no negócio? Existe algum workaround que permita continuar o trabalho? A resposta a estas perguntas conduz a uma classificação objectiva, independente da percepção do utilizador.
O impacto é diferente da importância percebida pelo utilizador. Um utilizador pode considerar que o seu problema é de impacto alto, mas se afecta apenas o seu posto de trabalho e existe workaround, o impacto objectivo é baixo. A classificação deve seguir critérios pré-definidos, não a pressão exercida pelo utilizador.
Níveis de urgência
A urgência mede a rapidez com que a resolução é necessária. Um incidente pode ter impacto limitado mas urgência alta se existir um prazo crítico iminente. A urgência está relacionada com o tempo, não com o número de utilizadores afectados.
| Nível | Urgência | Descrição | Exemplo |
|---|---|---|---|
| 1 | Alta | Resolução imediata necessária. Sem workaround. Perdas financeiras activas. | Processamento de salários falhou na véspera do pagamento |
| 2 | Média | Resolução necessária em horas. Workaround parcial disponível. | Aplicação CRM lenta mas funcional |
| 3 | Baixa | Resolução pode esperar. Impacto mínimo na produtividade. | Actualização de software pendente |
A urgência deve ser avaliada em contexto. Um incidente que normalmente teria urgência baixa pode tornar-se urgente se existir um prazo de negócio iminente - por exemplo, uma falha de impressão às 23h antes de uma entrega obrigatória às 9h do dia seguinte. O service desk deve considerar o contexto de negócio, não apenas o estado técnico do serviço.
A urgência também pode ser escalada durante o ciclo de vida do incidente. Um incidente que começa como P3 pode ser reclassificado para P2 se o tempo de resolução se aproximar de um limite crítico de negócio.
A matriz de prioridade
A matriz de prioridade cruza os níveis de impacto e urgência para produzir um valor de prioridade entre P1 e P5. É uma tabela de decisão simples que elimina a subjectividade na classificação de incidentes.
| Urgência alta | Urgência média | Urgência baixa | |
|---|---|---|---|
| Impacto alto | P1 Crítico | P2 Alto | P3 Médio |
| Impacto médio | P2 Alto | P3 Médio | P4 Baixo |
| Impacto baixo | P3 Médio | P4 Baixo | P5 Planeado |
A lógica da matriz é intuitiva: quando impacto e urgência são ambos altos, o incidente é crítico (P1). Quando um dos factores é alto e o outro é médio, o resultado é P2. O P5 corresponde a situações de baixo impacto e baixa urgência, onde a resolução pode ser agendada.
A matriz deve estar documentada e acessível a toda a equipa de suporte. Deve também ser parte integrante da ferramenta de service desk utilizada, idealmente com cálculo automático da prioridade com base nos critérios seleccionados pelo agente.
O P5 (planeado) é usado para pedidos de melhoria, problemas cosméticos ou actualizações sem urgência. Em algumas organizações, os P5 são tratados como pedidos de serviço e não como incidentes. A distinção depende do modelo de gestão adoptado.
Tempos de resposta e resolução
Cada nível de prioridade tem tempos de resposta e de resolução definidos. O tempo de resposta é o período máximo até o incidente ser reconhecido e atribuído. O tempo de resolução é o período máximo até o serviço ser restaurado. Estes tempos são acordados no SLA entre o prestador de serviços e o cliente.
| Prioridade | Designação | Tempo de resposta | Tempo de resolução | Exemplo |
|---|---|---|---|---|
| P1 | Crítico | 15 minutos | 1 hora | Serviço core indisponível, impacto financeiro imediato |
| P2 | Alto | 30 minutos | 4 horas | Serviço importante degradado, múltiplos utilizadores afectados |
| P3 | Médio | 2 horas | 8 horas | Serviço afectado com workaround disponível |
| P4 | Baixo | 4 horas | 24 horas | Problema menor, um utilizador, workaround disponível |
| P5 | Planeado | 1 dia útil | 5 dias úteis | Pedido de melhoria ou problema cosmético |
Estes tempos são exemplos de referência. Cada organização define os seus tempos de resposta e resolução com base nos SLAs acordados com os clientes, na capacidade da equipa e no tipo de serviços prestados. Não existe uma escala universal obrigatória.
O incumprimento dos tempos de SLA para incidentes de alta prioridade deve despoletar escalonamento automático. Se um P1 se aproximar dos 45 minutos sem resolução, o sistema deve notificar automaticamente o gestor de incidentes e a liderança da equipa de TI. Para os KPIs ITIL, a percentagem de incidentes resolvidos dentro do SLA por prioridade é um indicador crítico de desempenho do service desk.
Boas práticas
Implementar a matriz de prioridade de forma eficaz requer mais do que definir os critérios - exige consistência, comunicação e maturidade de processo.
5 boas práticas para a matriz de prioridade
Definir critérios claros
Impacto e urgência devem ter critérios objectivos e documentados, não subjectivos. Evitar que o utilizador defina a prioridade - quem reporta o incidente tem um ponto de vista naturalmente enviesado sobre a sua importância.
Rever periodicamente
Os tempos de resposta e resolução devem ser revistos com base no desempenho real. Se a equipa resolve sistematicamente P3 em 4 horas, o SLA de 8 horas pode não reflectir a capacidade real. A revisão faz parte da melhoria contínua.
Comunicar as expectativas
Os utilizadores devem saber o que esperar para cada nível de prioridade. Publicar os tempos de SLA num portal de self-service reduz as chamadas de seguimento e melhora a satisfação, mesmo quando os tempos de resolução são longos.
Escalonamento automático
Configurar alertas automáticos quando os tempos de resolução se aproximam do limite. Um incidente P1 que não tem resolução prevista aos 30 minutos deve gerar notificação automática para o gestor de incidentes e para a liderança de TI.
Não tudo é P1
Se todos os incidentes são P1, nenhum é. Uma distribuição saudável é aproximadamente 5% P1, 15% P2, 40% P3, 30% P4 e 10% P5. Se os P1 representam mais de 20% do volume, os critérios de priorização precisam de ser revistos.
Perguntas frequentes
A matriz de prioridade de incidentes é uma ferramenta do ITIL que cruza o impacto e a urgência de um incidente para determinar a sua prioridade. O resultado define a ordem de tratamento e os tempos de resposta e resolução acordados em SLA. A matriz elimina a subjectividade na classificação de incidentes e garante consistência na resposta da equipa de suporte.
Um incidente P1 (crítico) resulta da combinação de impacto alto com urgência alta: serviço crítico indisponível para grande parte da organização, sem workaround, com impacto financeiro imediato. Um P2 (alto) ocorre quando o impacto é alto mas a urgência é média, ou quando o impacto é médio com urgência alta. O P1 exige resposta em 15 minutos e resolução em 1 hora; o P2 admite 30 minutos de resposta e 4 horas de resolução.
A prioridade deve ser definida pelo service desk com base em critérios objectivos predefinidos, não pelo utilizador que reporta o incidente. Deixar o utilizador definir a prioridade leva invariavelmente a inflação de prioridades, onde todos os incidentes se tornam P1. O agente do service desk aplica os critérios da matriz - número de utilizadores afectados, disponibilidade de workaround, impacto no negócio - para chegar a uma prioridade objectiva.
Cada nível de prioridade tem tempos de resposta e resolução definidos no SLA (Service Level Agreement). O SLA estabelece os compromissos de serviço para cada prioridade. Se um incidente P1 não for resolvido dentro do tempo acordado, está em incumprimento de SLA, o que pode ter implicações contratuais e financeiras. A prioridade é portanto o mecanismo que liga cada incidente individual às obrigações de serviço acordadas com o cliente.
O escalonamento ocorre quando um incidente não consegue ser resolvido dentro dos tempos definidos ou quando a sua prioridade aumenta. O escalonamento funcional transfere o incidente para um nível técnico superior (L2, L3, fornecedor). O escalonamento hierárquico notifica gestores ou directores quando o impacto é significativo. Deve ser automático quando os tempos de SLA se aproximam do limite sem resolução prevista.
Não existe uma distribuição universal, mas uma referência comum é: cerca de 5% P1, 15% P2, 40% P3, 30% P4 e 10% P5. Se uma organização regista muitos P1, pode indicar critérios de priorização incorrectos ou problemas sistémicos não resolvidos. Uma distribuição muito concentrada em P1 e P2 sugere que a escala de prioridades não está bem calibrada e que os critérios precisam de revisão.
Quer estruturar a gestão de incidentes?
Aprenda a aplicar a matriz de prioridade e todas as práticas de gestão de incidentes com a certificação ITIL 4.
Ver formação ITIL