PORTAL DA
TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO
Processo Gerenciamento de Incidente
Histórico de Revisões do Processo | ||
---|---|---|
Descrição | Autor(a) | Data |
Publicação | Anderson Sales | 09/06/2021 |
Atualização dos diagramas do processo | Anderson Sales | 24/08/2022 |
Inserção de elementos textuais na página do processo | Anderson Sales | 20/09/2022 |
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.
Matriz RACI | |||||
---|---|---|---|---|---|
Atendente da Central de Serviços | Dono de Serviço | Dono do Processo Gerenciamento de Incidente | Gerente do Processo Gerenciamento de Incidente | Mesa/Coordenador de Equipe | |
Assegurar que a Central de Serviços seja o único ponto de contato entre as equipes de TIC, clientes e usuários quando houver um incidente | R | - | - | - | - |
Auditar periodicamente o processo a fim de assegurar que o mesmo seja pertinente à sua finalidade e/ou melhorado continuamente | - | - | R | C | - |
Coordenar as interfaces entre o processo em questão e os demais a ele relacionados | - | - | - | R | - |
Divulgar às partes interessadas as alterações realizadas no processo | - | - | R | I | - |
Executar as atividades do processo conforme as mesmas foram definidas | R | - | - | - | - |
Garantir a execução das atividades do processo a fim de assegurar que o mesmo seja executado conforme especificado | - | - | - | R | - |
Garantir que toda a documentação do processo seja íntegra e esteja atualizada e acessível a todas as partes interessadas | - | - | R | I | - |
Produzir e analisar relatórios sobre os indicadores de desempenho | - | - | - | R | - |
Promover o treinamento das partes interessadas do processo a fim de assegurar que o mesmo seja executado conforme especificado | - | - | R | C | - |
Reportar ao Dono do Processo sugestões de melhoria no processo | - | I | A | R | - |
7. INDICADORES DE DESEMPENHO
7.1. Número de incidentes por macrosserviço, serviço e fila | |
---|---|
Objetivo | Obter a quantidade de todos os incidentes abertos para realizar as análises pertinentes |
Periodicidade de mensuração | Semestral |
Cálculo | Número de incidentes por macrosserviço, serviço e fila |
Meta admissível | Não se aplica |
Meta desafiadora | Não se aplica |
Resultados do indicador | Disponível em: |
7.2. Percentual de incidentes solucionados em consonância com o respectivo Acordo de Nível de Serviço | |
---|---|
Objetivo | Aferir o percentual de incidentes resolvidos segundo os ANS estabelecidos |
Periodicidade de mensuração | Anual |
Cálculo | Quantidade de incidentes resolvidos segundo o ANS / total de incidentes resolvidos |
Meta admissível | 70% |
Meta desafiadora | 85% |
Resultados do indicador | Disponível em: |
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.