1. OBJETIVO DO PROCESSO

O objetivo do processo Gerenciamento de Problema consiste em descobrir a Causa Raiz de um Problema e delinear sua solução definitiva, a fim de evitar a recorrência de Incidentes.

Para uma melhor compreensão do propósito desse processo, é imprescindível salientar que Incidentes são interrupções não planejadas nos serviços de TIC, e Problemas são a Causa Raiz de um ou mais Incidentes recorrentes ou que geram impactos significativos no negócio.

Assim sendo, registros de Incidentes são distintos de registros de Problemas, visto que um Incidente não se transforma em um Problema. Entretanto, sua recorrência e nível de impacto incorrem na abertura de um registro de Problema. Dessarte, Incidentes e Problemas são atendidos sob atividades distintas, com ciclos de vida distintos e propósitos distintos.

2. ATIVIDADES DO PROCESSO

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

• Detecção do Problema;
• Registro do Problema;
• Categorização do Problema;
• Priorização do Problema;
• Investigação e Diagnóstico;
• Soluções de Contorno;
• Buscar Erro Conhecido;
• Resolução do Problema;
• Fechamento do Problema;
• Revisão de Problemas Graves.

3. TERMOS TÉCNICOS UTILIZADOS

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

• Base de Conhecimento: base de dados lógica que contém dados e informações usadas pelo Sistema de Gerenciamento de Conhecimento de Serviço;
• Base de Dados de Erros Conhecidos: base de dados que contém todos os registros de Erros Conhecidos;
• Causa Raiz: causa desconhecida ou original de um Incidente ou Problema;
• 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, 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 Problema: responsável pelo Processo Gerenciamento de Problema;
• Erro Conhecido: um Problema o qual possui Causa Raiz e Solução de Contorno documentados;
• Gerente de Problemas: coordenador da equipe responsável pelo serviço de TIC/IC que possui um Problema;
• 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 TIC para cada centro de dados;
• Gerente do Processo Gerenciamento de Problema: papel responsável pelo gerenciamento operacional do Processo Gerenciamento de Problema;
• Grupo Solucionador: membros da equipe responsável pelo serviço de TIC/IC que possui um Problema;
• Incidente: interrupção não esperada ou planejada de um serviço de TIC, ou a redução de sua qualidade, conforme os Acordos de Níveis de Serviço (ANS) estabelecidos;
• Item de Configuração (IC): qualquer componente que precisa ser gerenciado a fim de entregar um serviço de TIC;
• Registro de Erro Conhecido: o registro que contém os detalhes sobre um Erro Conhecido. Cada registro de Erro Conhecido documenta o ciclo de vida de um Erro Conhecido, incluindo seu status, Causa Raiz e Solução de Contorno;
• Serviço de TIC: um serviço de TIC é composto de uma combinação de tecnologia da informação, pessoas e processos. 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 ANS;
• Solução de Contorno: solução que reduz ou elimina o impacto de um Incidente ou Problema que ainda não possui uma resolução completa.

4. RELACIONAMENTOS DO GERENCIAMENTO DE PROBLEMA COM OUTROS PROCESSOS

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

• Gerenciamento de Incidente;
• Gerenciamento de Configuração e Ativo de Serviço;
• Gerenciamento de Nível de Serviço;
• Gerenciamento de Catálogo de Serviço;
• Gerenciamento de Mudança;
• Gerenciamento de Liberação e Implantação;
• Gerenciamento de Conhecimento.

As entradas associadas ao processo Gerenciamento de Problema são:

• Registros de Problemas oriundos do processo Gerenciamento de Incidente;
• Informações sobre Incidentes relacionados com os Problemas do Gerenciamento de Incidente;
• Informações sobre histórico e tendência de Incidentes do Gerenciamento de Incidente;
• Informações sobre os ICs do Gerenciamento de Configuração e Ativo de Serviço;
• Informações sobre os níveis de serviço do Gerenciamento de Nível de Serviço;
• Informações sobre os serviços do Gerenciamento de Catálogo de Serviço;
• Informações sobre Mudanças do Gerenciamento de Mudança;
• Informações sobre Liberações do Gerenciamento de Liberação e Implantação;
• Informações do Sistema de Gerenciamento de Conhecimento dos Serviços do Gerenciamento de Conhecimento.

As saídas associadas ao processo Gerenciamento de Problema são:

• Informações sobre Problemas para todos os outros processos;
• Requisições de Mudança para o processo Gerenciamento de Mudança;
• Informações de Soluções de Contorno e Erros Conhecidos para o Gerenciamento de Incidente e Gerenciamento de Conhecimento;
• Recomendações de melhoria para o ciclo de Melhoria Contínua de Serviço.

5. DIAGRAMA DO PROCESSO

Abaixo é apresentado o diagrama que compõe o processo em questão, e salienta-se que o mesmo utiliza a Business Process Model and Notation™ (BPMN™).

5.1. DESCRIÇÃO DAS TAREFAS DO DIAGRAMA GERENCIAR PROBLEMA

A seguir é apresentado o respectivo diagrama, e para visualizar de forma mais detalhada as informações que nele constam, clique na figura abaixo.

5.1.1. Registrar possível ocorrência de Problema

O atendente da Central de Serviços deverá registrar no Sistema de Gerenciamento de Chamados o provável Problema para que o mesmo venha a ser analisado pelo Gerente de Problemas.

As informações mínimas que deverão constar no chamado para análise do provável Problema são:

• Mensagem de erro, caso exista;
• Descrição do(s) "sintoma(s)" do possível Problema;
• Indicação se o possível Problema ocorreu uma vez ou se é recorrente;
• Serviço(s) de TIC associado(s) ao possível Problema;
• IC(s) associado(s) ao possível Problema;
• Impacto;
• Urgência.

Visto que Problemas podem ser identificados de maneira reativa ou proativa, as técnicas comumente utilizadas para detecção de Problemas de forma reativa podem ser:

• Suspeita ou detecção de um ou mais Incidentes;
• Análise de impacto de Incidentes pelas equipes da Central de Serviços;
• Detecção automática de eventos que se caracterizem como um Problema;
• Notificação da existência de um Problema por um Fornecedor.

Já as técnicas de detecção de Problemas de forma proativa podem ser:

• Análise de Incidentes iminentes que venham a gerar impactos no negócio ou análise de tendência histórica de Incidentes;
• Atividades de melhoria contínua de serviços de TIC.

5.1.2. Analisar possível ocorrência de Problema

O Gerente de Problemas deverá analisar as informações registradas para confirmar se a suspeita da ocorrência de um Problema é procedente ou não.

Em caso positivo, o Gerente de Problemas deverá constatar se há algum Problema similar em atendimento e/ou se existem Incidentes sendo tratados que porventura estejam associados ao Problema em questão. Sendo esse o caso, todos os chamados inerentes ao(s) serviço(s) de TIC/IC impactado(s) deverão ser associados ao chamado que trata o Problema identificado.

O Gerente de Problemas deverá, também, verificar e complementar se necessário as informações mínimas inseridas pelo responsável da abertura do chamado para oportunizar a devida análise do Problema.

5.1.3. Informar à Central de Serviços a inexistência de Problema

Após a análise efetuada, o Gerente de Problemas constatando que não há a ocorrência de um Problema, o mesmo deverá comunicar à Central de Serviços esse fato.

5.1.4. Cancelar chamado com possível ocorrência de Problema

Após comunicar a Central de Serviços, o Gerente de Problemas deverá cancelar o chamado no Sistema de Gerenciamento de Chamados e informar no seu histórico uma breve descrição da análise realizada.

5.1.5. Categorizar e priorizar o Problema

Acatada a sugestão de ocorrência de Problema, o Gerente de Problemas deverá classificá-lo e priorizá-lo, considerando a severidade e impacto do mesmo, bem como a quantidade de serviços de TIC, ICs e áreas de negócio afetadas.

5.1.6. Encaminhar chamado para Grupo Solucionador

Para dar continuidade ao tratamento do Problema identificado, o Gerente de Problemas deverá encaminhar o chamado para o Grupo Solucionador pertinente.

5.1.7. Investigar e diagnosticar o Problema

Observando todas as informações inseridas no chamado, o Grupo Solucionador deverá investigar e diagnosticar o Problema existente, sempre objetivando identificar a Causa Raiz do Problema.

Para tal, deverão ser feitas consultas à Base de Dados existente e a determinadas técnicas, tais como:

• Tentativa de recriação da(s) falha(s) resultante(s) no Problema;
• Realização de análise cronológica, a fim de observar a ordem de ocorrência de determinados eventos para estabelecer uma relação lógica entre eles, e que porventura tenham gerado o Problema;
• Isolamento da falha, a fim de reexecutar a operação ou o evento resultante no Problema por meio de testes de cada IC associado ao Problema, até que o IC causador seja identificado;
• Testes de hipótese, para elencar possíveis causas e determinar por meio de informações operacionais ou de Incidentes os cenários a serem verificados.

5.1.8. Acionar Fornecedor

Se o Problema em questão for de responsabilidade ou depender da ação de um Fornecedor, o mesmo deverá ser contactado.

5.1.9. Validar solução apresentada

De acordo com o exposto pelo Fornecedor, o atendente deverá se certificar se o que cabe ao mesmo foi de fato executado e solucionado.

5.1.10. Elaborar relatório com ações realizadas (fluxo com Causa Raiz/Solução de Contorno não encontradas)

Caso após as tarefas de investigação e diagnóstico o Grupo Solucionador não encontre a Causa Raiz, todas as verificações realizadas deverão ser registradas e encaminhadas para a apreciação do Gerente de Problemas.

5.1.11. Analisar relatório com ações realizadas (fluxo com Causa Raiz/Solução de Contorno não encontradas)

Após receber a documentação elaborada pelo Grupo Solucionador indicando que a Causa Raiz não foi encontrada, o Gerente de Problemas deverá analisá-la a fim de aprová-la ou não.

Caso seja aprovada, deverá informar às Partes Interessadas sobre esse fato, e caso seja reprovada o fluxo do processo retornará ao Grupo Solucionador para que efetuem uma nova investigação e diagnóstico.

5.1.12. Informar Partes Interessadas (fluxo com Causa Raiz/Solução de Contorno não encontradas)

Aprovando a documentação elaborada pelo Grupo Solucionador, o Gerente de Problemas deverá informar a todas as Partes Interessadas que não foram encontradas a Causa Raiz ou Solução de Contorno para o Problema em questão.

5.1.13. Registrar Causa Raiz e solução definitiva (fluxo com Causa Raiz encontrada)

Identificadas a Causa Raiz do Problema e a solução definitiva para solucioná-la, o Grupo Solucionador deverá registrá-las no histórico do chamado que trata do Problema em aberto.

5.1.14. Criar registro de Erro Conhecido com Causa Raiz e solução definitiva encontradas (fluxo com Causa Raiz encontrada)

Após os registros da Causa Raiz e de sua solução definitiva, o Grupo Solucionador deverá inseri-las também na Base de Dados de Erros Conhecidos.

5.1.15. Obter aprovação para aplicação da solução definitiva do Problema (fluxo com Causa Raiz encontrada)

Após determinar a solução definitiva para o Problema sob investigação, o Grupo Solucionador deverá contactar o Gerente de Problemas para obter aprovação quanto à implementação da solução encontrada.

5.1.16. Aprovar aplicação da solução definitiva (fluxo com Causa Raiz encontrada)

Com base na proposição do Grupo Solucionador para a resolução do Problema, o Gerente de Problemas deverá analisá-la para aprová-la ou não.

Caso a proposta do Grupo Solucionador seja aprovada, tal grupo deverá proceder com a implementação da solução definitiva elaborada. Caso contrário, o Grupo Solucionador deverá realizar uma nova investigação e diagnóstico.

5.1.17. Aplicar solução definitiva do Problema (fluxo com Causa Raiz encontrada)

Não necessitando da implementação de uma mudança e após a aprovação do Gerente de Problemas, o Grupo Solucionador deverá efetivamente aplicar a solução definitiva proposta.

5.1.18. Revisar registro de Erro Conhecido (fluxo com Causa Raiz encontrada)

Implementada a solução proposta, e se o Problema for resolvido definitivamente, o Grupo Solucionador deverá atualizar o Registro de Erro Conhecido e encaminhar o chamado para que o Gerente de Problemas possa fechá-lo com êxito.

5.1.19. Registrar Solução de Contorno no chamado (fluxo com Solução de Contorno encontrada)

Se uma Solução de Contorno for encontrada anteriormente à Causa Raiz do Problema, o Grupo Solucionador deverá registrá-la no chamado referente ao Problema sob investigação. Entretanto, ressalta-se que o chamado deverá permanecer aberto até que uma solução definitiva seja encontrada.

5.1.20. Criar registro de Erro Conhecido com Solução de Contorno (fluxo com Solução de Contorno encontrada)

Após o registro da Solução de Contorno, o Grupo Solucionador deverá inseri-la também na Base de Dados de Erros Conhecidos.

5.1.21. Reportar Solução de Contorno à Central de Serviços (fluxo com Solução de Contorno encontrada)

Executadas as tarefas anteriores, o Grupo Solucionador deverá divulgar a Solução de Contorno à Central de Serviços para que os seus atendentes possam implementá-la na resolução de Incidentes associados ao Problema, enquanto uma solução definitiva não é descoberta.

5.1.22. Prosseguir com investigação e diagnóstico (fluxo com Solução de Contorno encontrada)

Nesta tarefa, o Grupo Solucionador deverá prosseguir com a investigação/diagnóstico do Problema.

5.1.23. Fechar chamado com registro de Problema

Com o Problema plenamente resolvido, o Gerente de Problemas deverá encerrar o respectivo chamado, e solicitar aos atendentes da Central de Serviços que finalizem também os registros de Incidentes relacionados ao Problema.

5.1.24. Revisar Problemas graves

Caso o problema tratado tenha sido categorizado como grave, o Gerente de Problemas deve efetuar uma revisão mais detalhada para assegurar que as atividades foram conduzidas apropriadamente e elencar possíveis pontos de melhoria. As informações coletadas devem ser documentadas e inseridas na Base de Conhecimento.

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. ITIL v3 Glossaries of Terms. 2012. Disponível em: <https://www.axelos.com/resource-hub/glossary/itil-v3-glossaries-of-terms>. Acesso em: 30 jul. 2024.

Cabinet Office. ITIL® – Service Operation. [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 DA 18ª REGIÃO. Gerenciamento de Problema. 2021. Disponível em: <https://www.trt18.jus.br/portal/institucional/governanca-e-estrategia/tecnologia/portfolio-de-tic/processos-de-negocio-de-tic/gerenciamento-de-problema/>. Acesso em: 1 ago. 2024.