Buscar

A07Gerenciamento de Problemas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 3 páginas

Prévia do material em texto

O Autor Marcos André dos Santos Freitas em seu livro Fundamentos do Gerenciamento de 
Serviços de TI – editora Brasport – pág. 283 a 286, descreve as seguintes atividades para 
o Gerenciamento de Problemas: 
 
• (1) Detecção do Problema: detecção de Incidentes recorrentes ou 
Incidentes para os quais foi aplicada Solução de Contorno, porém não foi 
identificada a causa pela Central de Serviços ou pelo Gerenciamento de 
Incidentes. Ou detecção de Problemas pela análise de Incidentes como 
parte do Gerenciamento Proativo de Problemas 
 
• (2) Registro do Problema: de acordo com o método de detecção, os 
Registros de Problemas devem possuir informações relevantes para o 
atendimento do Problema. Quando um Registro de Problema é aberto a 
partir de um Registro de Incidentes, o Problema pode herdar as 
informações relevantes do Registro de Incidentes como todo o histórico 
anterior. Em resumo, um Registro de Problemas deve conter Modelos 
parecidos com o Incidente como informações de: 
 
o Número de identificação único para o Problema. 
o Categoria do Problema. 
o Urgência do Problema. 
o Impacto do Problema. 
o Priorização do Problema. 
o Datas de abertura e de cada atualização. 
o Identificação do técnico e grupo de suporte que está atendendo o 
Problema. 
o Descrição dos sintomas. 
o Status do Problema (aberto, aguardando em fila, sendo atendido, 
fechado, cancelado, etc.). 
o Item de Configuração relacionado. 
o Atividades realizadas para resolver o Problema. 
o Resolução aplicada. 
 
• (3) Categorização do Problema: problemas devem ser categorizados da 
mesma maneira que os Incidentes. 
 
• (4) Priorização do Problema: problemas devem ser priorizados da mesma 
maneira que os Incidentes. 
 
• (5) Investigação e Diagnóstico: investigações devem ser conduzidas para 
identificação da Causa Raiz dos Problemas. A identificação da Causa Raiz 
pode ser feita através da consulta da Base de Dados de Erros Conhecidos, 
através da tentativa de recriação da falha para entendimento das situações 
que podem originar o Problema e de outras técnicas de diagnóstico como: 
 
o Análise Cronológica: documentar todos os eventos em ordem de 
acontecimento para identificar uma sequência de eventos que 
levaram ao Problema. 
o Análise de Valor do Impacto: identificar o Impacto no negócio através 
do cálculo do valor do impacto baseado na abrangência do impacto, 
 
 
na duração da indisponibilidade e no custo para o negócio. Esta 
abordagem demonstra quais Problemas ou Incidentes causam maior 
impacto no negócio e devem ser priorizados. 
o Análise de Kepner e Tregoe: analisar a Causa Raiz de um problema 
baseado nas perguntas: o que, onde, quando e qual o tamanho. 
o Possíveis causas para o problema são propostas e cada uma das causas 
é testada para verificar a causa mais provável. 
o Brainstorm: pessoas discutem ideias sobre potenciais causas e 
propõem ações para resolução do Problema. Essa abordagem pode ser 
muito construtiva se bem conduzida e se utilizada em conjunto com a 
Análise de Kepner e Tregoe para documentar as sessões de 
Brainstorm. 
o Diagrama de Ishikawa ou Diagrama Espinha de Peixe: é representado 
através de um diagrama em formato de espinha de peixe onde na 
"cabeça do peixe" é colocada a descrição do Problema e,através de 
uma sessão de Brainstorm, são identificadas possíveis causas 
representadas nas extremidades das "espinhas do peixe". Essa 
abordagem permite a visualização das possíveis causas que estão 
contribuindo para a existência do Problema. 
o Análise de Pareto: representação das causas prováveis e suas 
frequências de ocorrência. São ordenadas as causas em ordem 
decrescente de importância. Através da criação de um gráfico de 
barras é identificada a causa mais provável de contribuição para o 
Problema. 
 
• (6) Soluções de Contorno: enquanto a causa raiz do Problema é 
identificada, podem ser encontradas Soluções de Contorno para os 
Incidentes. Essas Soluções de Contorno podem ser aplicadas imediatamente 
para resolver o Incidente, porém o Registro de Problema continua aberto 
até que a Solução Definitiva seja encontrada. 
 
• (7) Registro de Erro Conhecido: assim que uma Solução for encontrada, um 
Erro Conhecido deve ser registrado na Base de Dados de Erros Conhecidos 
para permitir às equipes de Gerenciamento de Incidentes o uso da Solução 
assim que novos Incidentes forem abertos, para minimizar o impacto dos 
Incidentes nos Serviços de TI. 
 
• (8) Resolução do Problema: se a solução do Problema pode ser aplicada 
imediatamente, as equipes do Gerenciamento de Problemas aplicam a 
Solução, porém, se a Solução alterar as configurações de um Serviço, deve 
ser criada uma Requisição de Mudança para planejamento, aprovação, 
construção e liberação da Mudança em produção. 
 
• (9) Fechamento do Problema: quando a Solução foi aplicada e a RDM 
fechada, o Registro de Problema é fechado, assim como os Registros de 
Incidente relacionados ao Problema. São verificadas se as informações 
relevantes dos Registros de Problemas estão devidamente preenchidas e se 
a Solução foi cadastrada na Base de Dados de Erros Conhecidos. 
 
 
 
• (10) Revisão de Problemas Graves: se o Problema for categorizado como 
Problema Grave, deve ser conduzida uma revisão mais específica para 
analisar se as atividades foram conduzidas apropriadamente e que pontos 
podem ser melhorados no futuro. Também é verificado como a recorrência 
desse Problema pode ser prevenida. Essas informações devem ser 
documentadas e disponibilizadas no Sistema de Gerenciamento de 
Conhecimento de Serviço. 
• (11) Erros Detectados no Ambiente de Desenvolvimento: informações sobre 
Erros detectados ainda no Gerenciamento de Liberações e Implantação de 
novos Serviços de TI, assim como as Soluções de Contorno e Soluções 
Definitivas encontradas devem ser cadastradas na Base de Dados de Erros 
Conhecidos, assim como experiências e informações relevantes no Sistema 
de Gerenciamento do Conhecimento dos Serviços para informação e 
consulta dos processos da Operação de Serviços.

Outros materiais