Uma das principais atividades do processo de Gerência de Problemas é identificar tendências, através do sub processo de gestão proativa de Problemas.
No dia a dia, esse conceito acaba se perdendo, pois a gestão de problemas acaba sempre demandando quase 100% de seu tempo a identificar a causa raiz dos problemas relacionados a incidentes críticos (super reativos!). Isso se dá de forma desesperada e sob forte pressão. A alta administração exige que as causas e soluções de contorno sejam identificadas rapidamente e isso muitas vezes ocasionam respostas ineficazes, de um processo onde tempo está diretamente relacionado a qualidade da investigação e solução proposta.
Ou seja, não sobra tempo para analisar tendências de capacidade , de disponibilidade e de incidentes recorrentes. Fica quase impossível iniciar planos de melhorias e avaliar se a forma como estamos tratando os problemas maiores está sendo conduzida de maneira adequada.
Os ganhos em realizar uma análise de problemas proativa podem ser:
- Operacionais: ao analisar a tendência de incidentes e identificar que a solução de incidentes recorrentes irá beneficia o Service Desk e áreas de suporte especializados, solucionando incidentes repetitivos. Isso tratá menos carga de trabalho e maior tempo para ser dedicado em melhorias (parar de apagar incêndio).
O detalhe é que isso acaba sendo um beneficio indireto para o negócio também. Por exemplo: Imaginem que o Service Desk gasta aproximadamente 10% de seu tempo, em uma pequena empresa, resolvendo incidentes em primeiro nível de senha bloqueada. A gerencia de problemas poderá investigar a causa raiz desses incidentes e resolve-los definitivamente. Com isso sobra mais tempo para o Service Desk atender ligações, maior disponibilidade para o usuário, aumento da eficiência e reflexo na satisfação do usuário e do negócio.
- Negócio: quando uma análise de tendências inibem e previnem incidentes que poderiam vir a acontecer e trazer impacto direto ao negócio. Por exemplo: junto com a disciplina de gerenciamento de capacidade, utilizar ferramentas para a identificação de tendências e atuar para evitar que incidentes relacionados a capacidade ocorram.
A seguir, listo algumas sugestões para implementar esta atividade:
1 - Não é simples fazer uma análise proativa de problemas. Identifique as disciplinas parceiras:
- Incidentes poderá apresentar tendencia de incidentes recorrentes que deverão ser investigados pela gestão de problemas.
- Disponibilidade poderá identificar tendências de issues relacionados a disponiblidade e atuar em conjunto com o gerenciamento de problemas para solucioná-los.
- Capacidade também possui técnicas para que issues de capacidade sejam identificados e poderá contar com a gerencia de problemas para tratá-los.
Lembre-se : a gerencia de problemas sozinha não é nada. É um processo extremamente dependente dos outros.
2 - Defina os papeis e responsabilidades. Escolha sempre os técnicos mais experientes, que conheçam muito bem tanto o ambiente quanto o negócio da empresa. Nem preciso comentar que o Gestor de Problemas é o dono disso tudo, né? Documente as principais tarefas, e seus respectivos donos. Você pode usar uma matriz RACI para facilitar. Temos um modelo em nossa área de Downloads.
3 - Defina o que você quer fazer (e o que já consegue imediatamente) , a metodologia e periodicidade. Fará uma análise de incidentes recorrentes? Uma análise de tendências de relatórios de capacidade? Uma análise de issues de disponibilidade? Será aplicada alguma técnica ou metodologia específica? Serão feitas reuniões com as equipes técnicas para discutir os problemas? Quantas vezes? Qual será o meio de comunicação?
4 - Definir quais serão os controles de performance e resultados desta atividade. Defina alguns controles para saber se as atividades estão sendo desempenhadas satisfatóriamente, e se os resultados esperados estão sendo atingidos. Ex: % de redução de incidentes recorrentes , # de incidentes evitados através da investigação e solução definitiva de problemas.
5- A quinta e principal dica é: Não acelere o processo e defina equipes separadas para a gestão proativa e reativa de problemas. A gestão proativa de problemas precisa de tempo para investigar, analisar cada variável envolvida no processo. A gestão reativa sofre pressões para explicacões e soluções , sejam elas de contorno ou definitivas. O tempo da gestão de problemas reativa é mais curto, infelizmente. Se as duas equipes tiverem o mesmo papel dentro de uma organização, a gestão de problema proativa simplesmente ficará em segundo plano e deixará de ser feita.
Disponibilizei na seção de downloads em nosso War Room um arquivo em excel para auxilía-los em uma pequena parte. O arquivo é um exemplo de como organizar uma análise de incidentes recorrentes (reincidências). Modifiquem, utilizem e nos contem como foi a experiêcia dentro da sua organização.
[ratings]
um mouse que não funciona perfeitamente, ou seja, um dia funciona outro não. E o usuário reclama para o Service Desk. Este tipo de reclamação é considerado um incidente ou um problema? Porque ?
Olá Ines!
Vai depender muito do impacto que o não funcionamento deste mouse exerce sobre o negócio, alguns exemplos:
- o fechamento do mês pode ser impactado pelo não funcionamento do mouse (no caso de o usuário ser o responsável por essa atividade)?
- o mouse pertence a algum executivo senior, que deixa realizar atividades importantíssimas pelo não funcionamento do mouse?
- o trabalho de arrumar todo dia uma solução de contorno impacta o rendimento da equipe de ti?
Se uma das respostas for SIM, muito provavelmente vc deva considerá-lo como um problema. Existem N outros exemplos. O que é importante saber é que você precisa de critérios pré-estabelecidos e validados para eleição de um problema, senão tudo acaba virando problema, e não é esse o objetivo. Capisce?
Abraços e obrigado por nos acompanhar!
Olá… tenho algumas duvidas quanto a gestao de problemas….. O caso do mouse acima… Nesse caso o mouse nao pertence a nenhum diretor e muito menos a alguem do negocio mas, está atrapalnado um usuário… No caso de uma solução de contorno, colocaríamos um mouse BKP mas, para enviar o mouse atual, precisariamos abrir uma GMUD para a substituição desse item de configuração? Impressora parou de funcionar e muitos usuários estão parados…. O incidente é aberto e a solução de contorno ´´e enviar para outra impressora… Nesse caso o Incidente é finalizado e aberto um como problema? No caso de gestao de problemas identificar que precisa substituir a impressora, é gerado uma GMUD?
Olá Flávio!
Faz mais sentido, e é bem mais comum, considerar apenas componentes mais críticos como itens de configuração. Um mouse dificilmente vai ser considerado como um IC(acho que o exemplo dado com um mouse não foi muito feliz rs).
Quando você elege um componente como item de configuração, esse item passa a ser de dominio da gestão de configuração, e portanto todas as mudanças neste componente devem ser controladas. Quanto maior a abrangência do seu banco de dados de configuração, maior a complexidade em controla-lo.
Quanto ao exemplo da impressora, você está certo quanto a finalização de um incidente, ele deve ser fechado quando o serviço retornou ao seu estado normal de funcionamento. Mas não é necessário aguardar a finalização de um incidente para registrar um problema. Eles podem inclusive andar em paralelo (são registros distintos e cada um tem o seu próprio ciclo de vida).
Sim, após identificar uma solução estruturada, ela deve ser aplicada através de uma mudança.
Abraços e obrigado por nos acompanhar!
Grande Renê, excelente post. Primeiramente gostaria de parabenizar toda equipe do ITIL na Prática pelo excelente conteúdo postado. É a primeira vez que visito o site e sem sombra de dúvidas me tornarei um leitor assíduo.
Bom, diante do ambiente exposto pelo Fávio, me surgiu uma dúvida. falou-se em finalizar o incidente e gerar um novo quando o processo de Ger. de Problemas é acionado. O incidente é mesmo finalizado ou apenas tem sua “responsabilidade transferida”. No meu entendimento seria: Service Desk identifica o problema e aplica as atividades pertinentes, caso não seja resolvido há a escalada funcional para áreas do Ger. de Problemas, onde esse processo identifica a causa raiz, gera um erro conhecido e sua solução de contorno e registra do BDGC, levando em consideração a não necessidade de envolver outras áreas. Neste ponto, o Ger. de Problema gera uma saída que servirá de entrada novamente ao Ger. de Incidentes informando a atualização das informações no BDGC, capacitando assim a central de serviços para determinado evento. Este meu entendimento é incorreto?