Processo de

Gerenciamento
de Problemas
 Processo de Gerenciamento de Problemas
1. Objetivo
O objetivo do Processo de Gerenciamento de Problemas é coordenar o ciclo de vida de todos os
problemas. O gerenciamento de problemas procura minimizar o impacto adverso de incidentes e
problemas no negócio que são causados por erros na infraestrutura de TI e, de forma proativa,
prevenir a recorrência de incidentes relacionados com estes erros. O gerenciamento de problemas
procura chegar à causa raiz de incidentes, documentar e comunicar erros conhecidos e iniciar ações
para melhorar ou corrigir a situação. Tais como:

● Evitar problemas e seus incidentes resultantes.

● Eliminar incidentes recorrentes.
● Minimizar o impacto de incidentes que não podem ser evitados.

2. Justificativa
O gerenciamento de problemas colabora com o Processo de Gerenciamento de Incidentes e de
Gerenciamento de Mudanças para conseguir melhorias na disponibilidade e qualidade da provisão de
serviços de TI. Cada vez que o problema é resolvido é registrada uma informação sobre a sua solução.
As informações dos incidentes são usadas para identificar soluções definitivas e reduzir o tempo dos
incidentes e problemas.

3. Abrangência
Este processo é aplicável a todos os colaboradores envolvidos nas atividades de gestão de serviços de
TI mantidos pela operação.

4. Papéis e Responsabilidades
A tabela abaixo representa os papéis e responsabilidades relacionados ao Processo de Gerenciamento
de Problemas:

Responsável pelo Processo (Owner): Gerência de Serviços Compartilhados - GSC

Demais Responsabilidades:
envolvidos: Conhecer Utilizar Disseminar Elaborar Manter Revisar Patrocinar Auditar Divulgar/
/ Aprovar Treinar
Governança x x x x
Diretoria x
Gerentes das x x x x
Áreas
ADM/FIN x x x
Comercial x x x
Comunicação x x x x x
GPC x x x x x
GSC x x x
Operação x x x x
GGO x x
Dono do processo:

● O dono do processo é representado pelo Gerente da Área de Gerência de Serviços

Compartilhados. Geralmente não existem atividades diretas no processo relacionadas a esse
papel;
● Responsável por garantir a sustentabilidade do processo no âmbito dos serviços de TI
gerenciados pela Operação Hepta que são escopo desse documento;
● Responsável por deliberar acerca da visão e os objetivos de negócio do processo;
● Deliberar acerca da alocação de recursos no processo;
● Deliberar acerca de mudanças substanciais no processo.

Gerente de Problema:

● O gerente do processo é representado por um membro da Coordenação da Área de Gerência

de Serviços Compartilhados;
● Responsável em manter uma reunião recorrente com os especialistas das áreas para a
verificação da eficácia da causa raiz e andamento das ações dos problemas
● Responsável por gerenciar todo o ciclo de vida da execução do processo;
● Responsável por monitorar a execução do processo;
● Responsável por aferir os indicadores de desempenho do processo;
● Responsável por elaborar e divulgar relatórios de desempenho da execução do processo.

Equipe de Sustentação:

● Responsável pela resolução de Problemas de acordo com os Procedimentos criados ou não;

● Responsável pela criação de artigos e procedimentos operacionais na base de conhecimento
para todas os Problemas atendidos;
● Responsável pela consulta e notificação à liderança acerca da necessidade de abertura de
tickets de Mudanças.

5. Entradas
● Incidente (s) com causa raiz desconhecida;
● Incidente Grave com causa raiz desconhecida;
● Análise proativa do ambiente de TI.
6. Fluxo de Atividades
7. Descrição das Atividades

7.1. Termos
Erro Conhecido: É um problema que teve documentada a causa raiz e sua respectiva ação corretiva.
Erros conhecidos podem também ser identificados pelo time de desenvolvimento e/ou fornecedores.
Todo erro conhecido é registrado na base de conhecimento podendo ser utilizado nas soluções de
incidentes no futuro.

Base de Conhecimento - é uma espécie de biblioteca digital (diretório) com materiais para embasar
soluções de problemas recorrentes ou não.

Problema: existência de um erro que possui a causa desconhecida, e o seu objetivo principal é
identificar a causa raiz dos incidentes a fim de eliminá-los da infraestrutura, para que não haja
recorrência, otimizando o cumprimento dos níveis de serviço, ou seja, quanto menos incidentes, maior
a disponibilidade.

Solução de Contorno: ação visando recuperar o serviço que apresenta falhas independentemente de
resolver a causa do mesmo.

Solução Definitiva: ação que visa solucionar o problema de forma definitiva, identificada com base
na causa raiz.

Observação: Ao identificar que a solução definitiva não é aplicável do ponto de vista do negócio, como
por exemplo, quando o impacto do problema é limitado, mas o custo de sua solução é muito alto, as
evidências desta conclusão devem ser anexadas ao chamado.

7.2. Registro do Problema

Os campos obrigatórios para registro de um problema, são:

● ID (número do chamado);
● Nome Cliente (interno ou externo);
● Categoria (Classificação incluindo serviço);
● Prioridade (impacto e urgência);
● Descrição (sintomas reportados);
● Histórico (sequência dos fatos, ações tomadas);
● Componente (IC - item de configuração);
● Incidente (s) associado (s);
● Equipe Técnica (Área de atuação);

7.3. Status do Registro de Problema

Status Descrição
Novo Problema em fase inicial (coleta de informações)
Em Atendimento A causa raiz está sendo investigada
Causa Raiz Encontrada A causa raiz foi encontrada
Pendente Mudança Aguardando execução da mudança para eliminar a causa raiz do problema
Pendente Fornecedor Aguardando análise pelo fornecedor
Aguardando Validação A validação precisa ser feita para evitar que o problema aconteça
novamente
Encerrado As ações que foram aplicadas para eliminar a causa raiz
 7.4. Prioridade
É a indicação da sequência em que os Problemas devem ser tratados, baseada no cruzamento dos
valores de impacto e urgência:

Impacto

Alto Médio Baixo

Alta 1 2 3
Urgência
Média 2 3 4

Baixa 3 4 5

ID Prioridade Descrição SLA de Atendimento

● Atenção Imediata; Impacto já é percebido; 8 horas úteis

1e2 Alto ● Escalonamento Hierárquico é necessário;
● Usuário incapaz de trabalhar.

● Não imediato, porém o impacto será 16 horas úteis

percebido em breve;
3 Médio ● Usuário necessita de restauração o mais
rápido possível;
● Usuário consegue trabalhar, tendo ou não
uma solução de contorno.

● Impacto previsto em um maior espaço de 24 horas úteis

tempo;
4e5 Baixo ● Usuários podem ser incomodados, mas
existe uma solução de contorno disponível
permitindo que ele continue a trabalhar.

7.5. Atividades
Atividades Responsáveis
Registrar Problema Gerente de Problema
O Gerente de Problema deve acessar as informações contidas no
Incidente (Ferramenta ITSM) e criar o registro do novo Problema ou
criar o Problema diretamente a partir de dados resultantes de uma
análise proativa do ambiente de TI.
Análise Proativa do Ambiente Equipe de Sustentação
O agente da Equipe de Sustentação durante sua rotina de trabalho,
deve analisar todas as informações possíveis no ambiente que
possam resultar em algum erro nos hardwares, softwares,
componentes de rede (voz/vídeo/dados) que fazem parte dos
serviços de TI.
Esses erros podem ocasionar, futuramente, incidentes nos serviços
de TI. Por isso, já é recomendado o registro de um Problema para
que se corrija e evite o incidente.
Vincular Incidente(s) ao Problema Gerente de Problema
O Gerente de Problema deve relacionar/vincular o (s) Incidente (s) ao
novo Problema.
Vincular ao Problema IC(s) afetado Gerente de Problema
O Gerente de Problema deve vincular o Item de Configuração (IC)
principal que ocorreu o erro ou falha que resultou no (s) Incidente (s)
ou que a análise proativa tenha mostrado uma possível ocorrência
de erro ou falha que possa ser tratada antes que o Incidente ocorra.
Priorizar o Problema Gerente de Problema
O Gerente de Problema deve escolher as mesmas informações de
Impacto e Urgência presentes no Incidente originador ou, caso seja
originado por análise proativa deve-se escolher os valores de acordo
com a criticidade do serviço suportado pelo IC que será objeto da
investigação.
Escalonar Problema Gerente de Problema
O Gerente de Problemas deve encaminhar o novo Problema a um
grupo solucionador que detenha o conhecimento técnico ideal para
iniciar a sua investigação. Nesse momento o Problema passa a ter o
status “Novo”.
Consultar Base de Conhecimento Equipe de Sustentação
O Agente deve tomar posse do problema, que passa a ter o status
‘Em Atendimento”. Em seguida, deve pesquisar na base de
soluções/conhecimento se já existe alguma solução de contorno que
tenha sido aplicada ao Incidente originador do Problema.
Analisar Solução dada ao Incidente Equipe de Sustentação
O Agente deve analisar a solução aplicada ao Incidente a fim de
comprovar se é uma solução válida e coerente. Deve-se também
analisar se essa solução de contorno pode ser na verdade uma
solução definitiva que possa, inclusive, já solucionar o Problema.
Diagnosticar Causa Raiz Equipe de Sustentação
O Analista deve realizar as atividades necessárias para prover um
diagnóstico eficaz da causa raiz.
Documentar Causa Raiz Equipe de Sustentação
O Agente deve documentar no registro do Problema qual a causa raiz
identificada.
Determinar Solução Equipe de Sustentação
O Agente deve, em posse da causa raiz identificada, prover a melhor
solução definitiva para a remoção do erro/falha que esteja causando
o (s) Incidente (s). Deve-se considerar a melhor solução em termos
de custo, benefício e tempo necessário para implementação.
Implementar Solução Equipe de Sustentação
O Agente deve realizar as atividades previstas como solução do
erro/falha, obedecendo ao planejamento contido da Requisição de
Mudança (RDM), quando for o caso. Se não for necessária aprovação
do Gerenciamento de Mudanças, o planejamento das ações (o quê,
quem, quando...) deve constar nos registros do Problema.
Alterar Status do Problema Equipe de Sustentação
O Agente deve alterar o status do Problema para ‘Aguardando
Validação’, tendo o cuidado de conferir se todos os dados estão
corretamente registrados de forma coerente, lógica e completa.
Validar Problema Gerente de Problema
O Gerente de Problemas deve acessar a solução que foi criada na
base de conhecimento, analisar os dados contidos na solução,
validando quanto à completeza, coerência e clareza das informações,
bem como analisar sobre a correta escrita obedecendo às regras
gramaticais.
Disponibilizar Solução Gerente de Problema
 Considerando que a solução é válida, o Gerente de Problemas deve
disponibilizá-la para uso na base de conhecimento (SharePoint).
Encerrar Problema Gerente de Problema
Considerando que a solução é válida e após disponibilizar solução
em Base de Conhecimento, o Gerente de Problemas deve alterar o
status da solução para ‘Encerrado’ (Ferramenta ITSM).
Adicionalmente antes do encerramento do problema, o Gerente de
Problemas deve analisar a eficácia da solução dentro de um intervalo
planejado para cada tipo de Problema.

8. Saídas
● Requisição de Mudanças para resolução do Problema;
● Detalhes do Problema atualizado;
● Base de conhecimento atualizada;
● Problema solucionado e fechado;
● Informações gerenciais.

9. Indicador
● Total de Problemas Atendidos dentro do Prazo

Objetivo Demonstrar o total de Problemas atendidos dentro do prazo

Fonte Banco de Dados da Ferramenta da ITSM
Periodicidade Mensal
Cálculo Sobre o total de Problemas registrados no mês sem violações do SLA acordado.
Meta >= 50% dos problemas devem ser atendidos dentro do prazo
Responsável Gerente de Problema
pela Coleta

10. Considerações Finais

Quaisquer exceções, dúvidas ou dificuldades com relação a este processo deverão ser esclarecidas
com a Gerência de Serviços Compartilhados – GSC.

Para cada cliente, conforme TR (Termo de Referência), teremos variações na execução do Processo de
Gerenciamento de Problemas.

Controle da Informação Documentada

Título: Processo de Gerenciamento de Problemas
Classificação: Interno
Versão: 1.0
Histórico de Revisões: Versão Inicial
Autor: Gerência de Serviços Compartilhados - GSC
Revisor: Governança
Aprovador: Gerência Geral de Operações - GGO
Data de publicação: 12/11/2021