ITIL para pequenas empresas - Dicas para adotar o gerenciamento de problemas da ITIL em pequenas organizações
Pequenas empresas
Neste artigo, descrevo uma sugestão de como adotar o processo de Gerenciamento de Problemas em organizações pequenas e/ou que possuem uma pequena estrutura para o departamento de TI.Para entender com clareza as dicas que que descrevo, disponibilizo também uma breve introdução / revisão ao a este processo.
Gerenciamento de Problemas
É o processo da operação de serviços que tem como principal objetivo identificar e propor soluções para a causa raiz de um ou mais incidentes.É um processo que tem natureza tanto reativa como - principalmente - proativa, enquanto a gestão de incidentes mantém o foco apenas em reagir o mais rápido possível quando incidentes ocorrem.
Se você tem alguma dúvida entre a distinção entre gestão de incidentes e problemas, recomendo a leitura deste artigo.
Problema: é definido pela ITIL como a causa raiz desconhecida de um ou mais incidentes.
Para uma introdução / revisão aprofundada, basta ler capítulo de Gerenciamento de Problemas neste Ebook elaborado pela Escola Superior de Redes: Ebook Gratuito de ITIL.
Realizada esta pequena revisão, seguem algumas dicas de como adotar o processo de gerenciamento de problemas em organizações pequenas.
Passo 01 - Crie categorias bem definidas para os incidentes
Escolha uma lista de categorias que ajude na identificação de tendências entre os registros dos incidentes (na verdade a expressão mais adequada seria "árvore de categorias", uma vez que categorias precisam ser decompostas em subníveis).
Caso exista um Catálogo de Serviços, ótimo: dele devem ser extraídas as categorias dos incidentes.
Caso contrário , garanta que existe uma árvore de categorias bem definida para incidentes antes de partir para a Gestão de Problemas. Pode ser uma oportunidade para construção dos seus catálogos de serviços e TI: Técnico e de Negócio.
O registro de incidentes bem categorizado assim como os relatórios de gestão de incidentes precisos são insumos indispensáveis para que consiga trabalhar bem com a Gestão de Problemas.
Passo 02 - Guarde uma referência da situação atual para a gestão de incidentes.
Para comparação futura, para justificar, para validar e, enfim, dirigir suas ações, você precisará de uma referência da situação atual do seu processo de gestão de incidentes.
Formalize uma visão atual para os indicadores de incidentes e a relação da performance destes indicadores com o impacto impacto para o negócio. Relacionamento da performance com os acordos de níveis de serviços será essencialmente adequada quando estes estão presentes na gestão de TI de seu departamento.
O que sugiro neste passo nada mais é do que a aplicação do conceito denominado em ITIL como Configuração de Referência (uma baseline).
Na prática, Configuração de referência pode ser resumida como um diagnóstico para escopo específico. O cenário formalmente reconhecido da sua situação atual irá inclusive justificar a intervenção através da implementação de um novo processo.
Na falta de ferramentas robustas (que geralmente só as grandes empresas têm oportunidade de adquirir), utilize indicadores simples para registrar sua configuração de referência:
- Indicador 01 - Soma do tempo total de incidentes graves ocorridos nos 06 últimos meses
- Indicador 02 - Número incidentes graves ocorridos nos 06 últimos meses
- Indicador 03 - Número erros ocorridos por categoria: sistemas, operações, gerenciamento técnico, nos últimos 06 meses (erro = causa raiz dos incidentes)
- Indicador 04 - percentual de incidentes resolvidos por soluções de contorno previamente registradas na base de erros conhecidos, nos últimos 06 meses (se você não tem ainda uma base formalmente implementada, este número pode ser considerado zero).
Passo 03 - Crie Metas
Com base nas estatísticas colhidas no passo anterior, estipule o quanto pretende melhorar após um prazo de implementação da Gestão de Problemas, conforme exemplo a seguir.
- Indicador 01 - Meta: reduzi-lo em 25%
- Indicador 02 - Meta: reduzi -lo em 30%
- Indicador 03 - Meta: reduzi -lo em 30% para categoria Sistemas e 20% para demais categorias
- Indicador 04 - Meta: aumentá -lo em 30%
Passo 04 - Defina as responsabilidades
Delegue a uma pessoa o papel de garantir a execução melhoria contínua da Gestão de Problemas de maneira geral.
A gestão dos problemas específicos deve ser realizada por responsáveis diretos por cada área: sistemas, gerenciamento técnico, gerenciamento de operações, etc.
Se você faz parte de um departamento de TI mínimo, que não está subdividido, aplique a mesma sugestão utilizando especialistas/analistas disponíveis. Cada líder / especialista responderá por problemas relacionados aos seus serviços.
Passo 05 - A equipe / profissional deve analisar as reincidências de falhas e incidentes graves
Cada especialista que foi responsabilizado por cuidar das atividades do dia a dia para determinada categoria deverá garantir que as iniciativas a seguir 1) e 2), serão realizados sempre que as situações a) e b), descritas também a seguir, ocorram:
Iniciativas:
1) a causa raiz de incidentes será diagnosticada
2) soluções / soluções de contorno serão implementadas
Situações:
a) incidentes que se repetem (ou possam a vir se repetir)
b) incidentes graves.
Passo 06 - O líder/profissional deve reunir sua equipe semanalmente, e o Dono do Processo deve conduzir reuniões mensais.
Neste passo, está a principal dica deste artigo! Eu a interpreto como principal por um simples motivo: este passo é consideravelmente diferente quando se trata de departamentos de TI de pequeno porte.
Se não há equipe para trabalhar com gestão de problemas cotidianamente, você pode trabalhar com as atividades deste processo de forma ocasional.
Passo 07 - Registre e delegue as ações e definições de cada equipe/profissional
Os papéis envolvidos com atividades de gestão de problemas, definidos no passo anterior, irão cuidar das atividades do dia a dia para gestão de problemas: aspectos técnicos.
Por sua vez, o profissional que foi responsabilizado para assumir o papel de Dono deste Processo irá conduzir reuniões mensais, nas quais:
- avaliará os indicadores gerais do processo
- cobrará evidências de que as atividades de gestão de problemas estão sendo conduzidas pelos gestores
- e se responsabilizará por propor melhorias para o processo
- revisará os indicadores e metas, propondo mudanças quando adequado
- fará sugestões para tratamento de problemas porventura tenham sido ignorados pelos responsáveis técnicos de cada área
- compartilhará com a equipe a evolução do processo e suas métricas
As opções escolhidas pela equipe para eliminar a causa raiz de incidentes devem ser registradas e aprovadas por todos os envolvidos.
Guarde tais informações em uma Base de Dados independente daquela qual guarda o registro de incidentes. Se você entende o quanto é importante realizar esta separação, ótimo; senão, recomendo uma reflexão que descrevo neste artigo: Diferença entre Incidentes e Problemas.
Passo 08 - Centralize a gestão da Base de Dados de Erros Conhecidos (BDEC)
Erros Conhecidos com respectivas soluções / soluções de contorno devem ser registrados em uma base única que deverá ser administrada pelo Dono do Processo de Gestão de Problemas.
A gestão centralizada, eficiente e eficaz desta base é crucial para que você obtenha retorno para todo o investimento que fez neste processo. Pouca atenção com este requisito é um risco para seu sucesso.
Passo 09 - Reporte os resultados.
O gestor do Processo deverá usar os indicadores e metas (estabelecidas no passo 02 e 03) para monitorar a eficácia e eficiência do seu processo.
Uma opção interessante é estabelecer duas visões de reporte: um reporte com visão interna e outro com visão externa para divulgar a desempenho do processo.
9.1. Reporte Interno
Este relatório deve explorar impactos do desempenho do processo na visão da própria equipe de TI.
Vejamos alguns exemplos (hipotéticos):
- A equipe de primeiro nível está tendo seu trabalho facilitado, graças ao incremento de incidentes solucionados a partir de soluções de contorno pré estabelecidas.
- Especialistas técnicos estão sendo interrompidos em menor frequência, já que o número de incidentes encaminhados para estes processionais reduziu em 50% (obs.: isto é possível graças ao desempenho positivo descrito no exemplo anterior)
9.2. Reporte Externo
Este será o relatório principal, onde os impactos positivos para o negócio devem ser refletidos.
Exemplos (também Hipotéticos):
- O tempo médio de atendimento a usuários foi reduzido em 30%, graças ao número maior de incidentes resolvidos no primeiro nível (já que o percentual de incidentes solucionados por soluções previstas na base de erros conhecidos foi incrementado).
- Houve uma melhoria de 40% na disponibilidade geral dos serviços de TI (graças a redução de número de incidentes graves e redução geral do número de incidentes).
