Profissionais TI - Pra quem respira informação

Normalmente a estruturação/reestruturação da área de TI começa pela implantação do processo de gerenciamento de incidentes, a função service desk e uma ferramenta (livre ou até paga) para registrar os incidentes.

Com o passar do tempo, os resultados começam a aparecer, e as oportunidades (e exigências) de melhorias também. Você resolve os incidentes rapidamente, mas eles se repetem e muito. E agora? É uma ótima oportunidade para você rodar seu PDCA novamente e dar um novo passo: O processo de gerenciamento de problemas.

 

Este processo tem o objetivo de analisar a causa dos incidentes ocorridos na infraestrutura de TI, fornecendo soluções paliativas e definitivas, evitando a recorrência destes, minimizando impacto (ou evitando) dos incidentes. Na prática, a gestão de problemas não dá resultados tão rápidos e não é tão visível quanto a gestão de incidentes, mas a médio prazo você vai verificar que vai te ajudar e muito a reduzir chamadas no service desk e melhorar a credibilidade da área de TI. O foco do gerenciamento de problemas é resolver a causa dos incidentes, enquanto o gerenciamento de incidentes é restabelecer o serviço. São processos complementares, mas diferentes. Se você deseja saber mais da diferença, confira aqui.

Alguns conceitos do processo:

• Problema: A causa desconhecida de um ou mais incidentes.
• Solução de contorno: Uma solução que permite reestabelecer o nível de serviço.
• Erro conhecido: Uma falha que se conhece a causa raiz e existe uma solução paliativa.
• Base de dados de erros conhecidos: É o local aonde você documenta os erros já corrigidos e as soluções paliativas. É a base de conhecimento.

As atividades são muito similares a gestão de incidentes, por isso, não entrarei em detalhes:

• Identificação
• Registro
• Classificação
• Priorização
• Investigação e Diagnóstico
• Identificação de Erros Conhecidos
• Resolução de Problema
• Encerramento
• Revisão de Problema Grave

Importante: Um incidente nunca vira um problema, mas pode estar relacionado a um problema. Isso quer dizer que na sua ferramenta de chamados, Excel, papel de controle, incidentes e problemas terão um ID diferente.

Dentro do processo, existem 2 sub-processos:

Gestão de problemas reativo

Faz a análise da causa dos principais incidentes ocorridos, procurando resolver sua causa, evitando a recorrência. Ex.: Após reiniciar o servidor para resolver o incidente de travamento, verificar nos logs o que causou isto.

Gestão de problemas proativo

Através da análise de informações dos ICs, procura por oportunidades de melhoria. Pode gerar entradas para o Plano de Melhoria do Serviço. Ex.: Na análise mensal dos gráficos de uso de recursos dos servidores, verificar que em 3 meses o disco C: vai encher.

O ITIL sugere uma série de métodos para análise e solução de problemas que são utilizados na área de qualidade em geral. Cada um dos métodos tem um propósito em específico. No próximo post vamos falar em detalhes sobre cada uma delas.

• Análise Cronológica
• Análise de “dor”
• Kepner e Tregoe
• Brainstorm
• Mapeamento por afinidade
• 5 porquês
• Isolamento da falha
• Teste por hipótese
• Observação
• Diagrama de Ishikawa ou espinha de peixe
• Pareto
• Masp (O ITIL não sugere este, mas iremos explicar no próximo post também)

Uma das principais saídas do processo são as solicitações de mudanças para correção definitiva de um problema. Esta mudança pode ser negada pelo comitê de mudanças caso o custo da mesma seja mais alto do que o gerenciamento e o impacto dela para o negócio. Aqui percebemos que para a gestão de problemas ser mais efetiva, é importante ter um processo de gestão de mudança implementado.

Na minha visão, implantar o processo de gestão de problemas em si não é a parte mais difícil, mas sim, ter métodos estruturados para solução de problemas. Estes precisam ser entendidos e efetivamente utilizados pela equipe. Nem todo problema precisa utilizar o método, mas problemas de média e alta complexidade deveriam. É necessário criar uma cultura dentro da equipe para que haja efetividade. Um ponto importante é treinar a equipe sobre a importância e os ganhos de se utilizar o método.

Normalmente se utiliza a mesma equipe que trata os incidentes para gerenciar os problemas. Na prática, os analistas de nível 2 e 3 fazem este papel. Grandes empresas tem equipes específicas para tratar problemas. O ITIL sugere que se a mesma equipe trata incidentes e problemas, que gaste 80% do tempo na gestão dos incidentes e 20% na gestão de problemas.

No próximo post detalharemos cada método de solução de problemas sugerida pelo ITIL.

Obrigado e até mais!