1. OBJETIVO DO PROCESSO

Um incidente de TIC consiste em qualquer interrupção nos serviços de TIC de uma instituição, seja afetando um único usuário ou todas as suas áreas.

Diante isso, segundo a ITIL®, o objetivo do processo de gerenciamento de incidentes é o de restabelecer a operação normal dos serviços de TIC o mais breve possível, visando a diminuir e mitigar o impacto para as áreas de negócio e usuários desses serviços, permitindo, dessa forma, a manutenção dos níveis de qualidade acordados.

2. ATIVIDADES DO PROCESSO

De acordo com a ITIL®, as atividades básicas consistem em:

• Identificar e registrar o incidente;
• Categorizar o incidente;
• Priorizar o incidente;
• Diagnosticar inicialmente o incidente;
• Escalar o incidente;
• Investigar o incidente;
• Resolver o incidente;
• Fechar o incidente.

3. TERMOS TÉCNICOS UTILIZADOS

As definições abaixo foram transcritas ou baseadas diretamente do glossário ITIL® de Português do Brasil:

• Acordo de Nível de Serviço (ANS): um acordo entre um provedor de serviço de TI e um cliente. O acordo de nível de serviço descreve o serviço de TI, documenta metas de nível de serviço e especifica as responsabilidades do provedor de serviço de TI e do cliente;
• Base de conhecimento: um banco de dados lógico contendo dados e informações usadas pelo sistema de gerenciamento de conhecimento de serviço;
• Cliente: alguém que compra produtos ou serviços. O cliente de um provedor de serviço de TI é a pessoa ou grupo que define e faz acordo das metas de nível de serviço;
• Dono de Processo: a pessoa que é responsável por garantir que um processo é adequado para um propósito. As responsabilidades do dono de processo incluem patrocínio, desenho e gerenciamento de mudança e melhoria contínua do processo e das suas métricas. Esse papel é frequentemente atribuído à mesma pessoa que executa o papel de gerente de processo, mas os dois papéis podem estar separados em organizações maiores;
• Dono de Serviço: um papel responsável por gerenciar um ou mais serviços através de todo o seu ciclo de vida. Os donos de serviço são fundamentais para o desenvolvimento de estratégia de serviço e são responsáveis pelo conteúdo do portfólio de serviço;
• Dono do Processo Gerenciamento de Incidente: responsável pelo Processo Gerenciamento de Incidente;
• Gerente de Processo: um papel responsável pelo gerenciamento operacional de um processo. As responsabilidades de um gerente de processo incluem o planejamento e coordenação de todas as atividades necessárias para executar, monitorar e relatar informações do processo. Pode haver vários gerentes de processo para um processo, por exemplo, gerentes de mudança regionais ou gerentes da continuidade do serviço de TI para cada centro de dados. O papel de gerente de processo é frequentemente atribuído à mesma pessoa que executa o papel de dono de processo, mas os dois papéis podem estar separados em organizações maiores;
• Gerente do Processo Gerenciamento de Incidente: papel responsável pelo gerenciamento operacional do Processo Gerenciamento de Incidente;
• Incidente: interrupção não esperada ou planejada de um serviço de TI, ou a redução de sua qualidade, conforme os Acordos de Níveis de Serviço (ANS) estabelecidos;
• Item de Configuração: Qualquer componente que precisa ser gerenciado a fim de entregar um serviço de TI;
• Serviço de TIC: um serviço de TIC é composto de uma combinação de tecnologia da informação, pessoas e processos, e serviços de TIC voltados para clientes suportam diretamente os processos de negócio de um ou mais clientes e convém que as suas metas de nível de serviço sejam definidas em um acordo de nível de serviço;
• Usuário: uma pessoa que usa o serviço de TI no dia-a-dia. Usuários são diferentes de clientes, pois alguns clientes não usam o serviço de TI diretamente;

4. PROCESSOS ASSOCIADOS

Os processos que possuem relacionamento com o de Gerenciamento de Incidente são:

• Atender nova solicitação;
• Atender solicitação existente;
• Monitorar chamados pendentes;
• Gerenciar mudança.

5. DIAGRAMAS DO PROCESSO

Abaixo são apresentados os 2 (dois) diagramas que compõem o processo em questão, e salienta-se que os mesmos utilizam a Business Process Model And Notation™ (BPMN™).

Processo Gerenciar Incidente

Para informações detalhadas sobre o fluxo do processo, clique na figura acima.

5.1. Descrição das Tarefas do Diagrama Gerenciar Incidente

A seguir, são apresentadas as descrições de cada uma de suas tarefas.

5.1.1. Efetuar análise para identificação do incidente

O fluxo do processo não sendo correspondente à retomada de atendimento, o atendente da Central de Serviços efetuará uma análise preliminar do chamado em questão a fim de averiguar se o mesmo realmente se trata de um incidente e, em caso positivo, identificá-lo.

5.1.2. Associar o chamado ao 1º chamado aberto

Constatada a existência de um outro chamado já tratando o incidente em questão, o atendente deverá:

• informar no histórico do chamado que está atendendo que já há outro tratando o incidente reportado;
• adicionar o número do 1º chamado.

5.1.3. Selecionar a resposta de auto fechamento de incidente

O atendente deverá inserir a resposta de auto fechamento relativa a incidente no SGC e, certificando-se de que a devida categorização foi selecionada, deverá cancelar o chamado.

5.1.4. Complementar as informações sobre o incidente

A fim de auxiliar o diagnóstico e a resolução do incidente, o atendente deverá solicitar ao usuário quando necessário o envio do máximo de informações relativas ao incidente caso não tenham sido inseridas na abertura do chamado.

As informações podem ser as seguintes: 

• mensagem/print do erro/indisponibilidade;
• data e hora estimados do início do erro/indisponibilidade;
• sistemas, ICs afetados;
• impacto (setores atingidos).

5.1.5. Categorizar o serviço associado ao incidente

Ciente de qual serviço o incidente é pertinente, o atendente da Central de Serviços deverá categorizá-lo adequadamente.

5.1.6. Priorizar o incidente

De acordo com parâmetros pré-definidos, o Sistema de Gerenciamento de Chamados priorizará os incidentes.

5.1.7. Bloquear o chamado

Sendo o chamado pertinente ao nível que se encontra, o atendente deverá bloqueá-lo a fim de se tornar o proprietário do mesmo e para prosseguir com o seu atendimento. Se o estado do chamado estiver como Novo, assim que o bloqueio ocorrer, o sistema automaticamente enviará a mensagem de 1ª interação do proprietário do chamado.

5.1.8. Alterar o estado do(s) sistema(s)/IC(s) afetado(s) no BDGC

Nesta atividade, o atendente da Central de Serviços deverá alterar no Banco de Dados de Gerenciamento de Configuração (BDGC) o estado do(s) sistema(s)/IC(s) que foi(ram) impactado(s), a fim de indicar que os mesmos possuem um incidente associado.

Para tal, o atendente deverá:

• no menu principal do OTRS, clicar em CMDB;
• selecionar o(s) sistema(s)/IC(s) relacionados ao incidente;
• no menu, clicar em Editar;
• no campo Estado de Incidente, escolher a opção Incidente. 

Em se tratando de um equipamento, e quando esse necessitar de uma ação corretiva ou preventiva, o campo Estado de Implantação deverá ser alterado para Manutenção.

5.1.9. Registrar o incidente no Painel de Incidentes do SUAP

O atendente do chamado em questão deverá acionar seu coordenador para que esse registre, no Painel de Incidentes do SUAP, o texto a seguir com as devidas substituições:

A nome_da_equipe vem informar que o serviço nome_do_serviço encontra-se indisponível ou com sua qualidade reduzida neste momento e que a equipe responsável já está trabalhando para restabelecê-lo. A previsão de normalização é de xy horas e até o fim desse período não há a necessidade de criar novos chamados pois o incidente em questão já vem sendo tratado no ticket nº_do_chamado.

5.1.10. Analisar o histórico do chamado

Quando se tratar de retomada de atendimento e o chamado estiver na equipe correta, o histórico do mesmo deverá ser analisado antes de se prosseguir com a resolução do incidente.

5.1.11. Efetuar o diagnóstico inicial do incidente

Utilizando-se dos procedimentos descritos na Base de Conhecimento, o atendente da Central de Serviços efetuará o diagnóstico inicial do incidente. Caso o procedimento não exista, o atendente deverá criá-lo imediatamente após o fechamento do incidente.

Salienta-se que as principais ações executadas durante o atendimento devem ser registradas no histórico do chamado.

Nesta tarefa, o atendente deverá também avaliar se será necessário:

• acionar o fornecedor do serviço/IC relacionado ao incidente;
• abrir uma demanda interna;
• seguir o fluxo do processo de Gerenciamento de Mudança.

5.1.12. Acionar o fornecedor

Se o incidente em questão depender da ação de um fornecedor, o mesmo deverá ser contactado.

5.1.13. Validar a solução apresentada

De acordo com as atividades executadas pelo fornecedor, o atendente deverá se certificar se tais atividades atendem ao que lhe foi solicitado.

5.1.14. Executar demanda interna

A abertura de uma demanda interna, direcionada a um membro da equipe de TIC do próprio campus, ocorrerá quando for necessária a realização de alguma atividade complementar para que o incidente em questão seja plenamente resolvido.

5.1.15. Proceder com a resolução do incidente

A depender das 3 possibilidades que o fluxo do processo pode prosseguir desde a tarefa Efetuar o diagnóstico inicial do incidente, nesta o atendente dará continuidade à resolução do incidente.

5.1.16. Revisar a categorização

Com o atendimento técnico finalizado, o proprietário do chamado deverá revisar a categorização do serviço para se certificar de que a mesma foi corretamente definida. Destaca-se que essa é uma tarefa relevante para o processo em questão pois pode impactar diretamente na análise dos relatórios de incidentes atendidos.

5.1.17. Informar a solução adotada e selecionar a resposta de auto fechamento padrão

Nesta atividade, o atendente deverá inserir no histórico do chamado a solução final do atendimento técnico e selecionar a resposta de auto fechamento padrão.

5.1.18. Restaurar o estado do(s) sistema(s)/IC(s) afetado(s) no BDGC

Nesta atividade, o atendente da Central de Serviços deverá retornar no BDGC o estado do(s) sistema(s)/IC(s) que foi(ram) impactado(s), a fim de indicar que os mesmos encontram-se operacionais novamente.

Para tal, o atendente deverá:

• no menu principal do OTRS clicar em CMDB;
• selecionar o(s) sistema(s)/IC(s) relacionados ao incidente;
• no menu, clicar em Editar;
• no campo Estado de Incidente escolher a opção Operacional.

Em se tratando de um equipamento, e quando esse tiver passado por uma ação corretiva ou preventiva, o campo Estado de Implantação deverá ser alterado para Produção.

5.1.19. Fechar o incidente no Painel de Incidentes do SUAP

O atendente do chamado em questão deverá acionar seu coordenador para que esse finalize, no Painel de Incidentes do SUAP, o registro do incidente.

5.1.20. Alterar/manter o estado do chamado como pendente

Caso o atendente não finalize a resolução do incidente devido a não conseguir contactar o usuário ou a um pedido de agendamento de atendimento, o mesmo deverá mudar ou preservar seu estado como pendente - usuário.

5.1.21. Escalar o incidente

Quando o incidente vier designado de uma outra equipe, o responsável da mesa ou o coordenador de um setor deverá encaminhá-lo para a equipe propícia.

5.1.22. Efetuar análise

O atendente da Central de Serviços de 2º ou 3º níveis efetuará uma análise preliminar do incidente em questão a fim de averiguar se o mesmo pertence à sua equipe.

5.1.23. Escalar o incidente para a equipe pertinente

Estando na equipe incorreta, o incidente será reenviado à mesa para que ocorra o devido direcionamento.

5.1.24. Analisar o histórico do chamado

Quando se tratar de retomada de atendimento e o chamado estiver na equipe correta, o histórico do mesmo deverá ser analisado antes de se prosseguir com a resolução do incidente.

5.1.25. Bloquear o chamado

Sendo o chamado pertinente ao nível que se encontra, o atendente deverá bloqueá-lo a fim de se tornar o proprietário do mesmo e para prosseguir com o seu atendimento. Se o estado do chamado estiver como Novo, assim que o bloqueio ocorrer, o sistema automaticamente enviará a mensagem de 1ª interação do proprietário do chamado.

5.1.26. Alterar o estado do(s) sistema(s)/IC(s) afetado(s) no BDGC

Nesta atividade, o atendente da Central de Serviços deverá alterar no Banco de Dados de Gerenciamento de Configuração (BDGC) o estado do(s) sistema(s)/IC(s) que foi(ram) impactado(s), a fim de indicar que os mesmos possuem um incidente associado.

Para tal, o atendente deverá:

• no menu principal do OTRS, clicar em CMDB;
• selecionar o(s) sistema(s)/IC(s) relacionados ao incidente;
• no menu, clicar em Editar;
• no campo Estado de Incidente, escolher a opção Incidente.

Em se tratando de um equipamento, e quando esse necessitar de uma ação corretiva ou preventiva, o campo Estado de Implantação deverá ser alterado para Manutenção.

5.1.27. Registrar o incidente no Painel de Incidentes do SUAP

O atendente do chamado em questão deverá acionar seu coordenador para que esse registre, no Painel de Incidentes do SUAP, o texto a seguir com as devidas substituições:

A nome_da_equipe vem informar que o serviço nome_do_serviço encontra-se indisponível ou com sua qualidade reduzida neste momento e que a equipe responsável já está trabalhando para restabelecê-lo. A previsão de normalização é de xy horas e até o fim desse período não há a necessidade de criar novos chamados pois o incidente em questão já vem sendo tratado no ticket nº_do_chamado.

5.1.28. Investigar e diagnosticar o incidente

Utilizando-se dos procedimentos descritos na Base de Conhecimento, o atendente da Central de Serviços efetuará o atendimento do incidente. Caso o procedimento não exista, o atendente deverá criá-lo imediatamente após o fechamento do incidente.

Salienta-se que as principais ações executadas durante o atendimento devem ser registradas no histórico do chamado.

Nesta tarefa, o atendente deverá também avaliar se será necessário:

• acionar o fornecedor do serviço/IC relacionado ao incidente.
• abrir uma demanda interna;
• seguir o fluxo do processo de Gerenciamento de Mudança.

5.1.29. Acionar o fornecedor

Se o incidente em questão depender da ação de um fornecedor, o mesmo deverá ser contactado.

5.1.30. Validar a solução apresentada

De acordo com as atividades executadas pelo fornecedor, o atendente deverá se certificar se tais atividades atendem ao que lhe foi solicitado.

5.1.31. Executar demanda interna

A abertura de uma demanda interna, direcionada a um membro da equipe de TIC do próprio campus, ocorrerá quando for necessária a realização de alguma atividade complementar para que o incidente em questão seja plenamente resolvido.

5.1.32. Proceder com a resolução do incidente

A depender das 3 possibilidades que o fluxo do processo pode prosseguir desde a tarefa Investigar e diagnosticar o incidente, nesta o atendente dará continuidade à resolução do incidente.

5.1.33. Revisar a categorização

Com o atendimento técnico finalizado, o proprietário do chamado deverá revisar a categorização do serviço para se certificar de que a mesma foi corretamente definida. Destaca-se que essa é uma tarefa relevante para o processo em questão pois pode impactar diretamente na análise dos relatórios de incidentes atendidos.

5.1.34. Informar a solução adotada e selecionar a resposta de auto fechamento padrão

Nesta atividade, o atendente deverá inserir no histórico do chamado a solução final do atendimento técnico e selecionar a resposta de auto fechamento padrão.

5.1.35. Restaurar o estado do(s) sistema(s)/IC(s) afetado(s) no BDGC

Nesta atividade, o atendente da Central de Serviços deverá retornar no BDGC o estado do(s) sistema(s)/IC(s) que foi(ram) impactado(s), a fim de indicar que os mesmos encontram-se operacionais novamente.

Para tal, o atendente deverá:

• no menu principal do OTRS clicar em CMDB;
• selecionar o(s) sistema(s)/IC(s) relacionados ao incidente;
• no menu, clicar em Editar;
• no campo Estado de Incidente escolher a opção Operacional.

Em se tratando de um equipamento, e quando esse tiver passado por uma ação corretiva ou preventiva, o campo Estado de Implantação deverá ser alterado para Produção.

5.1.36. Fechar o incidente no Painel de Incidentes do SUAP

O atendente do chamado em questão deverá acionar seu coordenador para que esse finalize, no Painel de Incidentes do SUAP, o registro do incidente.

5.1.37. Alterar/manter o estado do chamado como pendente

Caso o atendente não finalize a resolução do incidente devido a não conseguir contactar o usuário ou a um pedido de agendamento de atendimento, o mesmo deverá mudar ou preservar seu estado como pendente - usuário.

Subprocesso Executar Demanda Interna

Para informações detalhadas sobre o fluxo do processo, clique na figura acima.

5.2. Descrição das Tarefas do Diagrama Executar Demanda Interna

A seguir, são apresentadas as descrições de cada uma de suas tarefas.

5.2.1. Abrir a demanda interna

Havendo a necessidade, o atendente do incidente abrirá uma demanda interna a fim de prosseguir com a resolução da mesma.

5.2.2. Alterar o estado do chamado original para pendente - demanda interna

Após a abertura da demanda interna, o proprietário do incidente alterará o estado do chamado para pendente - demanda interna e o manterá até que o mesmo seja resolvido.

5.2.3. Efetuar a análise inicial

O atendente da Central de Serviços efetuará uma análise preliminar da demanda interna em questão a fim de averiguar qual serviço a mesma é atinente.

5.2.4. Categorizar o serviço associado à demanda interna

Ciente de qual serviço a demanda interna é pertinente, o atendente da Central de Serviços deverá categorizá-la adequadamente.

5.2.5. Bloquear a demanda interna

Sendo a demanda interna pertinente ao nível que se encontra, o atendente deverá bloqueá-la a fim de se tornar o proprietário da mesma e para prosseguir com o seu atendimento.

5.2.6. Proceder com o atendimento técnico

Utilizando-se dos procedimentos descritos na base de conhecimento, o atendente da Central de Serviços efetuará o atendimento da demanda interna. Caso o procedimento não exista, o atendente deverá criá-lo imediatamente após a finalização do atendimento.

5.2.7. Revisar a categorização

Com o atendimento técnico finalizado, o proprietário da demanda interna deverá revisar a categorização inicial para se certificar de que a mesma foi corretamente definida.

5.2.8. Fechar a demanda interna com êxito

Nesta atividade, o atendente deverá inserir no histórico da demanda interna a solução final do atendimento técnico para garantir a devida validação por parte do solicitante e selecionar a opção de fechar o chamado com êxito.

5.2.9. Alterar o estado do chamado original para aberto

Após o atendimento da demanda interna, o proprietário do incidente alterará o estado do chamado para aberto e prosseguirá com a sua resolução.

5.2.10. Alterar o estado da demanda interna para pendente

Caso o atendente não finalize a resolução da demanda interna, o mesmo deverá mudar ou preservar seu estado como pendente - a executar.

6. MATRIZ RACI

A Matriz RACI consiste numa tabela que descreve e apresenta claramente os papéis e responsabilidades de pessoas envolvidas num processo ou projeto.

Na estrutura da matriz apresentada abaixo, a coluna mais à esquerda indica as atividades do processo em questão e as demais colunas as denominações dos participantes bem como o que lhes é pertinente.

A sigla RACI é oriunda da língua inglesa e suas letras significam:

• R → Responsible: responsável pela execução de uma atividade;
• A → Accountable: responsável pela aprovação de uma atividade. Geralmente, o aprovador acompanha a realização do processo, permite que o mesmo seja iniciado (em alguns casos) ou atesta o resultado e as entregas;
• C → Consulted: pessoa ou grupo de pessoas que devem ser consultadas para a realização de uma atividade;
• I → Informed: pessoa ou grupo de pessoas que devem ser informadas de resultado(s) ou ação(ões) tomada(s) mas que não precisam estar envolvidas no processo de tomada de decisão. 

7. INDICADORES DE DESEMPENHO

8. REFERÊNCIAS

Axelos. Glossário e abreviações ITIL. 2012. Disponível em: <https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_BR-PT-v1-0.pdf>. Acesso em: 26 mai. 2021.

Axelos. ITIL® 4 Glossaries of Terms. 2022. Disponível em: <https://www.axelos.com/resource-hub/glossary/ITIL-4-glossaries-of-terms>. Acesso em: 19 ago. 2022.

Cabinet Office. ITIL® – Service Design. [S.I.]: The Stationery Office, 2011.

FREITAS, M. A. S. Fundamentos do gerenciamento de serviços de TI. 2. ed. Tijuca: BRASPORT, 2013. 424p.

TRIBUNAL REGIONAL DO TRABALHO – 18ª REGIÃO. Anexo_II_Fluxos_do_processo_de_gerenciamento_de_incidentes 2.0. 2021. Disponível em: <https://www.trt18.jus.br/portal/arquivos/2021/09/Anexo_II_Fluxos_do_processo_de_gerenciamento_de_incidentes-2.0-1.pdf>. Acesso em: 12 ago. 2022.