Normalmente a estruturação/reestruturação da área de TI começa pela implantação doprocesso
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ência) 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 é
reestabelecer o serviço. São processos complementares mas diferentes.
Se você deseja saber mais da diferença, confira em http://www.governancadeti.com/2010/09/itil-gerenciamento-de-incidentes-x-gerenciamento-de-problemas/.
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 esta 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 em
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 uma 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ça para correção definitiva de um problema.
Esta mudança pode ser negada pelo comitê de mudanças caso o custo da
mudança 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
analisas 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.
Nenhum comentário:
Postar um comentário