Processo ITSM Alinhado com ITIL

Gestão de incidentes

Processo end-to-end com workflow, actividades, RACI e métricas

Âmbito e objectivos

Objectivo

Restaurar a operação normal do serviço o mais rapidamente possível, minimizando o impacto no negócio e garantindo conformidade com os SLAs acordados.

Trigger

Detecção de uma interrupção ou degradação de serviço, originada por utilizador, monitorização automatizada ou alerta de evento.

Âmbito

Desde a detecção ou reporte do incidente até ao encerramento e validação pelo utilizador afectado.

Fora do âmbito

Investigação de causa-raiz (gestão de problemas) e implementação de correcções permanentes que exijam uma mudança (change enablement).

Output

Serviço restaurado, registo de incidente documentado com cronologia completa, comunicação ao utilizador confirmada e, quando aplicável, registo de problema criado para investigação de causa-raiz.

Diagrama do processo

Diagrama BPMN simplificado do processo de gestão de incidentes (3 swimlanes). Percorra horizontalmente em dispositivos móveis.

Actividades macro

#	Actividade	Responsável	Input	Output
1	Detecção e reporte	Utilizador / Monitorização	Interrupção ou degradação de serviço	Notificação de incidente
2	Registo e classificação	Service desk	Notificação de incidente	Registo de incidente (categoria, impacto, urgência, prioridade)
3	Investigação e diagnóstico L1	Service desk	Registo de incidente, base de conhecimento	Diagnóstico inicial, possível resolução
4	Escalação funcional	Service desk	Incidente não resolvido em L1	Incidente atribuído a equipa técnica L2/L3
5	Investigação e diagnóstico L2/L3	Equipa técnica	Incidente escalado, informação de diagnóstico	Causa identificada, plano de resolução
6	Resolução e recuperação	Equipa técnica / Service desk	Plano de resolução	Serviço restaurado
7	Comunicação ao utilizador	Service desk	Resolução aplicada	Utilizador informado
8	Validação e encerramento	Service desk / Utilizador	Confirmação de resolução	Incidente encerrado, registo actualizado

Descrição detalhada das actividades

1 Detecção e reporte

O processo inicia quando uma interrupção ou degradação de serviço é detectada, seja pelo próprio utilizador, por alertas de monitorização automatizada ou por correlação de eventos. O canal de reporte mais comum é o portal de auto-serviço, seguido de telefone ou email para o service desk.

Passos chave

Identificar o serviço afectado e a natureza da falha
Reunir informação básica: utilizador, sistema, mensagem de erro, hora de início
Escolher o canal de reporte adequado (portal, telefone, email)
Verificar se existe incidente conhecido activo para o mesmo serviço

Critério de saída: notificação de incidente enviada ao service desk com informação suficiente para registo inicial.

2 Registo e classificação

O service desk cria o registo formal do incidente na ferramenta ITSM e atribui os atributos de classificação. A correcta categorização determina o encaminhamento automático para a equipa certa e o SLA aplicável.

Passos chave

Criar ticket com referência única e data/hora de reporte
Atribuir categoria (tipo de serviço, componente afectado)
Determinar impacto (número de utilizadores, criticidade do serviço)
Determinar urgência (sensibilidade temporal do negócio)
Calcular prioridade com base na matriz impacto x urgência
Identificar o CI afectado na CMDB

Critério de saída: registo criado com categoria, impacto, urgência e prioridade definidos; utilizador notificado com número de ticket e tempo de resposta esperado.

3 Investigação e diagnóstico L1

O service desk realiza a análise de primeiro nível, procurando resolver o incidente com os recursos disponíveis: base de conhecimento, scripts de diagnóstico e acesso remoto. O objectivo é resolver pelo menos 70% dos incidentes sem escalação.

Passos chave

Pesquisar incidentes semelhantes na base de conhecimento
Verificar erros conhecidos na base de erros conhecidos (KEDB)
Recolher informação de diagnóstico adicional junto do utilizador
Aplicar workaround ou resolução documentada se disponível
Documentar todos os passos de diagnóstico no ticket

Critério de saída: incidente resolvido em L1 ou decisão documentada de escalação com toda a informação de diagnóstico registada.

4 Escalação funcional

Quando o service desk não consegue resolver o incidente dentro do tempo definido para L1 ou não possui competência técnica suficiente, o incidente é escalado funcionalmente para a equipa técnica especializada. A escalação hierárquica ocorre quando o incidente tem impacto significativo e requer visibilidade de gestão.

Passos chave

Verificar se o tempo de resolução em L1 foi excedido
Seleccionar a equipa ou especialista correcto com base na categoria do incidente
Actualizar o ticket com toda a informação de diagnóstico recolhida
Notificar a equipa receptora com contexto completo
Informar o utilizador da escalação e novo prazo estimado

Critério de saída: incidente atribuído à equipa técnica correcta com toda a informação necessária; utilizador informado.

5 Investigação e diagnóstico L2/L3

A equipa técnica especializada aprofunda o diagnóstico utilizando ferramentas avançadas, acesso a logs, análise de infraestrutura e, se necessário, envolvimento de fornecedores externos. O foco mantém-se na restauração do serviço, não na identificação da causa raiz.

Passos chave

Analisar logs, métricas e eventos do período afectado
Verificar alterações recentes no ambiente (mudanças, deploys, patches)
Testar hipóteses de forma controlada
Envolver fornecedores externos quando o componente afectado é externo
Documentar progressos e actualizar estimativa de resolução

Critério de saída: causa identificada e plano de resolução definido, com confirmação de que a solução não introduz risco adicional.

6 Resolução e recuperação

A resolução técnica é implementada e o serviço verificado como restaurado. Quando a correção definitiva requer uma mudança formal, aplica-se um workaround e cria-se o registo de mudança correspondente para implementação posterior.

Passos chave

Implementar a solução ou workaround documentado
Verificar o restabelecimento do serviço com testes funcionais
Confirmar que o incidente não voltou a ocorrer após a resolução
Actualizar o ticket com a solução aplicada
Se aplicável, criar registo de problema para investigação de causa raiz

Critério de saída: serviço confirmado como restaurado e a funcionar dentro dos parâmetros normais; resolução documentada no ticket.

7 Comunicação ao utilizador

O service desk contacta o utilizador para informar que o serviço foi restaurado, descrever a resolução aplicada e solicitar validação. A comunicação deve ser clara, sem jargão técnico excessivo, e incluir passos que o utilizador deve executar para confirmar o funcionamento.

Passos chave

Contactar o utilizador pelo canal preferido (email, telefone, portal)
Descrever a resolução de forma compreensível
Indicar os passos para validação pelo utilizador
Definir prazo para confirmação antes do encerramento automático

Critério de saída: utilizador notificado com confirmação de entrega; prazo de resposta definido no ticket.

8 Validação e encerramento

O incidente é formalmente encerrado após confirmação pelo utilizador ou decorrido o prazo de resposta sem objecções. O registo é actualizado com toda a cronologia, a solução definitiva documentada e, se necessário, um artigo de conhecimento criado para referência futura.

Passos chave

Confirmar com o utilizador que o serviço está a funcionar correctamente
Actualizar o ticket com a causa e solução final
Registar tempo de resolução para cálculo de métricas
Criar ou actualizar artigo na base de conhecimento se a solução for reutilizável
Fechar o ticket e enviar inquérito de satisfação

Critério de saída: ticket encerrado com estado "resolvido" ou "encerrado", registo completo e utilizador satisfeito.

Modelo RACI

Actividade	Utilizador (Uti)	Service desk L1 (SD)	Eq. técnica L2/L3 (ET)	Incident manager (IM)	Service owner (SO)
Detecção e reporte	R	I	-	A	-
Registo e classificação	I	R	-	A	-
Investigação L1	-	R	C	A	-
Escalação funcional	-	R	I	A	I
Investigação L2/L3	-	C	R	A	I
Resolução e recuperação	-	C	R	A	I
Comunicação ao utilizador	I	R	-	A	I
Validação e encerramento	C	R	-	A	I

R Responsible - executa a actividade A Accountable - responde pelo resultado C Consulted - é consultado I Informed - é informado

Métricas e KPIs

Métrica	Descrição	Target sugerido
MTTR	Tempo médio desde o reporte até à resolução completa do incidente	<4h (P1) <8h (P2) <24h (P3)
Taxa de resolução L1	Percentagem de incidentes resolvidos pelo service desk sem escalação para equipas técnicas	> 70%
Cumprimento de SLA	Percentagem de incidentes resolvidos dentro do tempo de resolução acordado em SLA	> 95%
Taxa de reaberturas	Percentagem de incidentes encerrados que foram reabertos por não resolução efectiva	< 5%
Incidentes por prioridade	Distribuição percentual de incidentes por nível de prioridade (P1 a P4)	P1 < 5% do total
Satisfação do utilizador	Classificação média dada pelo utilizador no inquérito pós-resolução	> 4,0/5,0

Interfaces com outros processos

Saida

Gestão de problemas

Incidentes recorrentes ou de elevado impacto geram registos de problema para investigação de causa raiz.

Saida

Change enablement

Quando a resolução definitiva implica uma alteração ao ambiente, é criado um registo de mudança para implementação formal.

Saida

Gestão do conhecimento

Resoluções documentadas e workarounds eficazes alimentam a base de conhecimento para uso futuro pelo service desk.

Saida / Entrada

Service desk

Ponto de contacto único para reporte, comunicação ao utilizador e coordenação das escalações ao longo do ciclo de vida do incidente.

Saida

CMDB

O registo do incidente referencia o CI afectado na CMDB, permitindo análise de impacto e histórico por componente.

Entrada

Monitorização e eventos

Alertas gerados pela ferramenta de monitorização criam incidentes automaticamente, sem necessidade de reporte manual pelo utilizador.

Descarregar o pack completo

Inclui o processo documentado, formulário de registo de incidentes, modelo RACI em Excel e templates de comunicação.

Descarregar pack completo Precisa de ajuda a implementar? Fale connosco