5 dicas para a Gestão de Problemas Proativa

Tempo de leitura: menos de 1 minuto

Uma das principais atividades do processo da Gestão 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 disponibilidade 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 satisfatoriamente, 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 explicaçõ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.

 

21 Comentários


  1. 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 ?

    Responder

    1. 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!

      Responder

  2. 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?

    Responder

  3. 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!

    Responder

  4. 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?

    Responder

  5. Olá Rene,

    Parabéns pelo Post. Tenho uma dúvida. Trabalho em uma empresa que provém soluções de internet. Temos uma equipe de operações (dividida em vários nichos Windows, Linux, Banco de Dados, Redes, etc) essa equipe por sua vez responde por tudo que está em produção.

    Existe outra equipe que trabalha com desenvolvimento e engenharia dos produtos que são colocados em produção. Por convenção todas as atividades dessa segunda são de forma macro e eles não atendem pelo Ger. de Incidentes. Porém incidentes que são gerados dentro da operação (estão em produção), muitas vezes depende de um Workaround do lado deles para resolver. No entanto, diferente da operação, esse time não possui OLA, responsáveis operacionais ou quem acompanhe o Ger. de Problemas. A prioridade sempre passa a ser a entrega de novas features ao invês da correção na raiz de problemas que ocorreram por falta de QA, testes de capacidade e a passagem de bastão entre Tecnologia e Operação.

    Você já viu este cenário em outras empresas ? Vou começar a estruturar o Ger. de Problemas, porém minha experiência maior vem do Ger. de Incidentes, penso em seguir com:

    – Análise do modo operante da área.
    – Atribuição de papéis
    – Acordo entre gestores de tecnologia e POs (Product Owners) para que não ocorra conflitos entre entrega de novas features e entrega de correções que irão envolver uma RDM.
    – Fechar o Workflow na mesma ferramenta que utilizamos para o Ger. de Inc.
    – Proporcionar regras do tipo, X incidentes críticos, obrigam a criação de um problema para investigação.
    – Sugerir o Ger. de Problemas Pró Ativo para dentro da operação, ocasionando assim a descoberta de problemas de infra (engenharia de um produto) ou software (desenvolvimento de um produto) para que esse problema seja passado aos devidos donos e saia da operação.

    Estou no caminho certo ?

    Desculpe a exposição deste cenário, mas com sua experiência acredito que tenha visto algo similar pelo mercado e possa ajudar.

    Grato.

    Abs

    Responder

    1. Olá Diego, obrigado pelo seu feedback!

      Se lhe servir de consolo, eu diria que mais de 90% das empresas por onde passei têm o mesmo problema. Infelizmente fica um pouco difícil dissertar com tantos detalhes por aqui, mas acho que você está sim no caminho certo.

      Três dicas:

      -Não arrisque partir para gerenciamento de problemas enquanto não tiver o gerenciamento de incidentes bem maduro (registros confiáveis).
      -Trate as regras para “eleição” de um problema com bastante carinho.
      -Consulte a literatura ITIL (livro Service Operation) sobre as funções da Operação de Serviços. Acho que será um embasamento para definir melhor os papéis e responsabilidades, e melhorar o nível de relacionamento entre a equipe de operações e desenvolvimento. Achei uma pornografia absurdo o fato da equipe de desenvolvimento não ter um OLA definido. Como ficam os clientes?

      Abraços e boa sorte!

      Responder

  6. Renê,

    Eu que agradeço a rápida resposta, não pensava que seria tão rápido e pode ter certeza que me ajudou.

    Respondendo sua dúvida, mesmo sem a definição de um OLA (documentado, acordando o NS entre a gestão de Tecnologia e Operações) eles tem a preocupação de entregar produtos de qualidade aos clientes, mas a falta de dados (que seria dada se tivêssemos algum nível júnior se envolvendo com incidentes ou uma parcela da equipe se envolvendo com problemas) faz com que pensem que a qualidade do software está saindo muito bem e que a falha provocada pós publicação veio de mudanças mal planejadas de dentro da operação. Sintoma esse que pode até ocorrer, desde que seja investigado como um problema.

    No meio desse conflito entra a figura do PO, cobrança da gestão de atendimento e operações que mostram os problemas para os desenvolvedores. POs acabam priorizando o que precisa ser visto, porém tudo isso corre por fora de um processo estruturado (Ger. de Problemas) causando assim atraso, entrega de correções que não resolvem o problema 100%, entre outras coisas que você já conhece.

    Eu mesmo não admitiria trabalhar em uma empresa que colocasse o cliente em segundo plano, com processo, existente, falho ou inexistente a empresa trabalha em prol dessas pessoas que colocam o dinheiro no nosso bolso 🙂 e queremos fazer o melhor por elas.

    Abs

    Responder

  7. Excelente Diego! Agora ficou mais claro o contexto da sua empresa, e também uma necessidade bastante latente por algumas práticas de gerenciamento de problemas. 🙂

    Abraços!

    Responder


  8. Olá Renê!

    Bom, estou desenvolvendo o TCC para o curso de Pós Graduação em Engenharia de Software. Posso citar esse artigo no meu trabalho (Claro, citação direta e com referência)

    Abraço

    Luan M

    Responder

  9. Renê, boa tarde, estou fazendo uma produção temática afim de crescimento funcional e gostaria muito de sua ajuda. Resumidamente preciso responder 3 perguntas: Melhorar o desempenho das investigações de problemas concluídas em até 7 dias de 50% para 90%. Manter o desempenho de 95% de mudanças implantadas com sucesso (implantação no prazo planejado e sem causar incidentes). Reduzir o tempo médio mensal de resolução de incidentes de 5 horas para 2 horas. — Com essas 03 metas, apresentar um plano de trabalho pratico, contendo pelo menos as atividades que devem ser realizadas por você e sua equipe, os marcos e mecanismos de controle mensais.

    Responder

    1. Olá Pablo,

      Não sei como conseguiria te ajudar, exceto via um trabalho de consultoria. As três perguntas que você precisa responder são simples e objetivas, mas longe de terem respostas simples.

      Podemos sobre isso em pvt. Me manda um e-mail no rene @ itsmnapratica.com.br

      Abração!

      Responder

  10. Renê, ola! Trabalho (como SDM) em um grande companhia de TI que presta serviços de tecnologia para diversos clientes, estou focado em um desafio: fazer gestão de problemas de Infraestrutura de TI de forma proativa através da análise de relatórios do Gerenciamento de Eventos. Adquiri seu livro (ITIL na prática – Ger. Problemas de Infraestrutura e Serviços de TI) e gostaria de receber dicas de referências bibliográficas ou artigos com sugestões práticas para aprimorar o conhecimento e fazer funcionar na prática. Me ajuda com esta missão? Desde já, agradeço! Abraços!

    Responder

    1. Olá Marwin, tudo bem?

      Agradeço pela aquisição do livro e espero que tenha encontrado resposta para algumas dúvidas. Minha sugestão para você mergulhar de cabeça no tema gerenciamento de problemas é fazer o curso ITIL Intermediate OSA. Este é um curso que o torna um especialista nos processos de suporte à operações, dos quais inclui-se o gerenciamento de problemas.

      Na área de cursos aqui do site você vai poder conhecer melhor a proposta do curso ITIL OSA. Me avisa se tiver qualquer dúvida – https://www.itsmnapratica.com.br/cursos/

      Grande abraço e sucesso na sua missão!

      Responder

      1. Não encontrei seu livro (ITIL na prática – Ger. Problemas de Infraestrutura e Serviços de TI) para comprar. Como faço?

        Responder

  11. Boa Noite!!
    Renê, estou montando uma apresentação, que será discutida em uma aula da faculdade, sobre Gerencia de Capacidade. Você tem algum artigo onde explica sobre essa gerencia, poderia entrar em contato comigo para me ajudar com conteúdo? Afinal, estou com dificuldade de achar conteúdo, digamos, não tão superficial sobre o assunto. Desde já agradeço. Att, Alana Oliveira

    Responder

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *