Baixe o app para aproveitar ainda mais
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.
Compartilhar