Procedimentos técnicos do PoP-BA

PR-076 - Procedimento para Registro e Tratamento de Problemas
Data Criação:
Data Revisão:

1. Objetivo

Descrever os passos a serem seguidos para registro e tratamento de problemas envolvendo o ambiente do PoP-BA

2. Definições

F-GPR -XXX – Formulário Gestão de Problema, onde:

XXX – É a sequencia numérica do formulário;

RT – Sigla para “Request Tracker”, ferramenta web para abertura de tíckets de serviços e acompanhamento dos casos;

3. Descrição das Etapas

3.1. Identificação:

O primeiro evento na gestão de problemas é a identificação do problema, consequência de um incidente ocorrido no ambiente. Importante destacar que nem todo incidente irá trazer associado um problema. Os problemas figuram como uma das causas da recorrência de incidentes similares. Por essa razão a gestão de problemas mostra-se tão importante, na medida em que é possível tratar a causa da reincidência de forma pró-ativa e otimizando os esforços na busca de um ambiente controlado e seguro. Uma vez identificado o problema, surge a necessidade de registro e, posteriormente, o tratamento do mesmo

3.2. Criação de tícket para Problema:

O registro de problema é realizado utilizando a ferramenta RT. Deverá ser criado um novo tícket na fila "GestaoDeProblema". Ao definir o tipo do tícket campos específicos para a gestão de problemas serão exibidos para o preenchimento. É de grande importancia que todos os campos sejam preenchidos, dessa forma a gestão poderá ser otimizada com a possibilidade de criação de gráficos de análise.

O tícket não tem a pretenção de substituir o formulário de problema (F-GPR-XXX), por esse motivo é nitidamente mais resumido no que diz respeito às informações. Esta etapa inicial de criação do tícket será seguida de outra que irá preencher um formulário de problema, este sim, contemplando todos os detalhes do problema em questão. Os campos presentes em um tícket de gestão de problema são os seguintes:

  • Assunto: Título descritivo do problema;
  • NivelUrgencia: Deverá ser escolhida uma opção dentre as três opções:
    • Baixo: Indica que o problema apresenta nível de urgência baixo;
    • Médio: Indica que o problema apresenta nível de urgência médio;
    • Alto: Indica que o problema apresenta nível de urgência alto;
  • Impacto:Deverá ser escolhida uma opção dentre as três opções:
    • Baixo: Indica que o problema apresenta impacto no ambiente baixo;
    • Médio: Indica que o problema apresenta impacto no ambiente médio;
    • Alto: Indica que o problema apresenta impacto no ambientealto;
  • Solicitante: Pessoa responsável pela gestão de problemas e solicitante do tratamento do problema;
  • NumeroFormulario: Código do formulário de problema (F-GPR-XXX) de cadastrado obrigatório na intranet;
  • FormularioMudancaAssociado: Código do formulário de mudança associado ao tratamento do problema;
  • Descrição: Detalhamento do problema.

3.3. Registro de Formulário de Problema:

Após o registro no RT, a próxima etapa consiste em detalhar o problema no formulário especifico, denominado "Formulário de Gestão de Problema (F-GPR)". O cadastro de um novo problema através do preenchimento do formulário poderá ser feito no tópico de problemas, disponível em:

https://www.pop-ba.rnp.br/IntranetPOPBA/GestaoDeProblemas

O objetivo do formulário é o desenvolvimento de um registro detalhado do problema incluindo informações mais precisas e que irão fazer parte da base de conhecimentos do PoP-BA. O registro na base de conhecimentos será fundamental para que as soluções das reincidências possam ser rapidamente identificadas e utilizadas nos novos problemas.

Os seguintes campos deverão ser preenchidos pelo usuário:

Informações de Registro
  • Tícket no RT: Valor único que identifica o tícket criado na etapa 1.1.2;
  • Data de Abertura: Data em que o tícket da etapa 1.1.2 foi criado;
  • Data de Encerramento: Data em que o problema obteve a sua solução final;
  • Status: Deverá ser escolhida uma opção dentre as opções:
    • Aberto: Indica que o problema ainda não obteve a sua solução final;
    • Concluido: Indica que o problema já possui uma solução final e compõe a base de conhecimento;
  • Nível de Urgência: Deverá ser escolhida uma opção dentre as opções:
    • Baixo: Indica que o problema apresenta nível de urgência baixo;
    • Médio: Indica que o problema apresenta nível de urgência médio;
    • Alto: Indica que o problema apresenta nível de urgência alto;
  • Nível de Impacto: Deverá ser escolhida uma opção dentre as opções:
    • Baixo: Indica que o problema apresenta impacto no ambiente baixo;
    • Médio: Indica que o problema apresenta impacto no ambiente médio;
    • Alto: Indica que o problema apresenta impacto no ambientealto;
  • Prazo para Execução (dias): Deverá ser escolhida uma opção dentre as opções:
    • 1: O problema deverá ser resolvido dentro do intervalo de 1 dia;
    • 3: O problema deverá ser resolvido dentro do intervalo de 3 dia;
    • 7: O problema deverá ser resolvido dentro do intervalo de 7 dia;
  • Solicitante: Pessoa responsável pela gestão de problemas e solicitante do tratamento do problema;
  • E-mail Solicitante: E-mail do solicitante;
  • Executor: Pessoa responsável em solucionar o problema;
  • E-mail Executor: E-mail do executor;
  • Título descritivo para o Problema: Título que descreva de forma sucinta o problema;
  • Lista dos Ativos Relacionados: Relação de equipamentos que estão sofrendo impacto com o problema ainda não solucionado;
  • *Lista de Serviços Impactados *: Relação de serviços os quais o problema está, direta ou indiretamente, impactando;
  • FGM relacionado (código): Código do formulário da mudança associada ao problema;
Informações de Diagnóstico
  • Função do objeto/serviço onde o problema foi identificado: Função o ativo ou serviço aonde o problema foi identificado provê dentro da instituição;
  • Desvio (sintoma) apresentado pelo objeto/serviço: Efeito do problema no ativo ou serviço. O comportamento atípico que chamou a atenção como causador do incidente;
  • Solução de Contorno: Solução emergencial a ser executada de maneira que os impactos do problema possam ser temporariamente mitigados ou resolvidos;
  • Plano de Retorno (Em caso de Falha): Lista de ações que deverão ser executadas para retorno do ativo/serviço para o estado existente antes da solução de contorno fracassada;
Informações sobre Causa(s) Relacionada(s)
  • Prováveis ( Especulações realizadas antes da solução ) : Indica os possíveis motivos causadores do problema. Essas especulações baseiam-se nos serviços e ativos relacionados e nas experiências do executor;
  • Raiz ( Identificada após a solução ): Indica a causa do problema, descoberta após a análise do executor;
Informações de Investigação
  • Abordagens: Indica as ações que o executor irá tomar em busca da solução final. Devem ser definidas em ordem sequencial e esta ordem deverá ser seguida pelo executor;
  • Necessidade de reunião técnica: Deverá ser escolhida uma opção dentre as opções:
    • Não: Opção escolhida na hipótese em que a reunião técnica não se mostrou necessária;
    • Sim: Opção escolhida quando existe a necessidade de uma reunião técnica para discutir assuntos relativoss ao problema;
  • Link da súmula da reunião (Quando aplicar-se): Link para o documento informativo sobre os assuntos abordados na reunião técnica, quando solicitada;
Informações de Solução
  • Solução final: Descrição da solução para o problema raiz;
  • O Problema foi solucionado?: Deverá ser escolhida uma opção dentre as opções:
    • Não: Hipótese em que o probelma ainda não foi solucionado;
    • Sim: Hipótese em que o problema já foi solucionado;
  • Necessidade de Reagendamento: Deverá ser escolhida uma opção dentre as opções:
    • Não: Situação em que o problema foi resolvido sem a necessidade de um reagendamento da execução das medidas;
    • Sim: Situação em que motivos diversos impossibilitaram a solução do problema. Nesse ambiente deverá ser realizado um reagendamento para a reexecução ou finalização das medidas;
  • Data do Reagendamento (Quando se aplicar-se): Data em que as medidas visando a solução do problema deverão ser finalizadas ou reexecutadas;
  • Motivo do Reagendamento: Razão que motivou a não solução do problema durante a primeira janela de tempo;
  • Abordagens que não deram certo: Diversas medidas executadas que não surtiram efeito para solução do problema;
  • Lições Aprendidas: Conhecimentos adquiridos durante as tentativas de solução do problema, dignos de nota, e que sirvam como experiência para situações futuras;

3.4 Abertura de Mudança:

Todo problema deverá gerar uma mudança para que a solução encontrada possa ser efetivada. Dessa maneira. Deverá ser executado o procedimento PR-GM-009

Após a criação do formulário de mudança (uma das etapas do PR-GM-009) o código do mesmo deverá ser informado no formulário de gestão de problemas, descrito no etapa 3.3 deste procedimento.

A solução encontrada para o problema somente poderá ser executada após aprovação da mudança. Uma vez aprovada, a solução deverá ser implantada e o problema deverá ser solucionado. Caso o problema não seja resolvido, os campos "Necessidade de Reagendamento", "Data do Reagendamento" e "Motivo do Reagendamento" deverão ser preenchidos. Na data definida, os procedimentos adicionais deverão ser executados. Caso, ainda assim, o problema não seja definitivamente solucionado, deverá ser reagendada nova intervenção.

Na hipótese do problema ser definitivamente solucionado, os campos "Solução final", "Abordagens que não deram certo" e "Lições Aprendidas" devem ser preenchidos. Além disso, o tícket criado no etapa 3.2 deste procedimento deverá ser preenchido com as informações restantes e finalizado.

4. Referências Externas

Nenhum documento referenciado.