ITIL V3 – Operação do Serviço – Processos – Gerenciamento de Incidentes

Como dizia o velho provérbio, “panela velha é que faz comida boa”. No ITIL V3, um processo que não sofreu alteração na passagem da versão dois para a versão três foi o processo de Gerenciamento de Incidentes. Este processo é considerado o mais expansivo dentro da organização e tem como objetivo principal, para aqueles que ainda não tiveram contato com nenhuma versão do ITIL, o restabelecimento do funcionamento normal do serviço, o mais rápido possível. Aqui cabem duas análises: a primeira diz respeito ao termo “funcionamento normal”. O que essa expressão quer dizer? Alguém se arrisca? … Bem, se considerarmos o que já vimos até agora, fica fácil dizer que para o ITIL, o funcionamento normal de um serviço é alcançado quando estamos atendendo os Níveis Acordados (ANS), mas também não podemos esquecer que, do ponto de vista interno, os ANOs também devem ser respeitados. A segunda análise diz respeito a expressão “o mais rápido possível”. A intenção aqui é minimizar o impacto negativo sobre o negócio, assegurando que os melhores níveis possíveis sejam mantidos. Falamos em melhores níveis possíveis porque em muitos casos aplica-se soluções de contorno que não resolvem a situação definitivamente.

O Gerenciamento de Incidentes deve lidar com todos os tipos de incidentes, que podem vir a partir dos usuários, geralmente por meio da Central de Serviços, das equipes técnicas ou automaticamente, por meio de ferramentas de monitoração. Aliás, é inadmissível, em algumas organizações que um incidente seja de seu conhecimento apenas quando o usuário o reporta.

Por ser um processo muito utilizado pelas organizações, passaremos abaixo pelas atividades que o compõe com uma breve descrição:

• Identificação do Incidente. Conforme dito acima, a identificação deve ser feita preferencialmente por ferramentas de monitoração dos serviços e não pelo usuário para evitar o “mico”. Apesar disso, o usuário pode reportar um problema que deve ser verificado se de fato é um problema ou é apenas falta de informação, por exemplo, o que não caracteriza um incidente.
• Registro do Incidente. Como tudo no ITIL, mas especialmente aqui, o registro do incidente deve ser bem detalhado, para possibilitar uma resposta mais tempestiva ao problema.
• Categorização do Incidente. Importante para o uso de outros processos, como por exemplo o Gerenciamento de Problemas.
• Priorização de Incidentes. Já falamos sobre essa técnica em postagens anteriores. Essa priorização é importantíssima, levando em consideração que existem recursos finitos nas organizações.
• Diagnóstico Inicial. Se o Incidente foi aberto por meio da Central de Serviços, há a necessidade da existência de scripts para que os atendentes possam executar ações básicas que tentam resolver o incidente, baseado nos erros conhecidos e em uma base de conhecimento. Caso não consiga resolver, haverá a escalação do incidente.
• Escalação do Incidente. Existem dois tipos de escalação, a saber: escalação funcional (horizontal), que trata da passagem do incidente que não foi resolvido pelo atendente em 1º nível para equipes especializadas, baseada na categorização do mesmo. Escalação Hierárquica (vertical), para casos de incidentes graves que fazem com que as gerências sejam notificadas para agilizar o seu tratamento ou conversar com o Cliente de forma a passar alguma satisfação. A Escalação ocorre também nas duas atividades seguintes, descritas abaixo.
• Investigação e Diagnóstico. Investigação de um determinado incidente na busca de uma solução de contorno, que pode, em alguns casos, até ser a solução definitiva.
• Resolução e Recuperação. Identificando uma solução em potencial, esta deve ser aplicada e testada. O grupo de solução, quando acha uma solução, deve passar as informações à Central de Serviços para que essa possa comunicar ao usuário.
• Fechamento do Incidente. Registrar de forma detalhada o que foi feito e a resolução encontrada para que possa servir de base para futuros incidentes com a mesma natureza.

Passado pelo processo de Gerenciamento de Incidentes, veremos na próxima postagem outro processo bem consolidado desde a versão 2.0 do ITIL, o Gerenciamento de Problemas. Vocês não perdem por esperar!!!!

ITIL V3 – Operação do Serviço – Técnicas e Ferramentas – BDEC

Além da técnica de priorização de incidentes e problemas, o ITIL V3 oferece uma ferramenta para ser utilizada pela Operação do Serviço, o BDEC. Já deu para perceber que o ITIL V3 abusou das siglas para representar seus Bancos de Dados e sistemas que auxiliam os processos, certo? Pois bem, BDEC significa Base de Dados de Erro Conhecido.

Não é algo novo na biblioteca ITIL, nem no imaginário de todos nós que os Erros Conhecidos devam estar em uma base de dados capaz de suportar os processos, caso contrário não seriam “conhecidos”, concordam? O BDEC é mais um membro do SGCS (Sistema de Gerenciamento do Conhecimento do Serviço) e deve ser montado pelo Gerenciamento de Problemas, mas será consumido também, e por motivos óbvios, pelo Gerenciamento de Incidentes.

Dito isso, acredito que a partir da próxima postagem entraremos nos Processos da Operação do Serviço.

Vocês não perdem por esperar!!

ITIL V3 – Operação do Serviço – Técnicas e Ferramentas – Priorização de Incidentes e Problemas

O ITIL indica uma regra para que os Incidentes sejam priorizados, assim como a tratativa dos problemas. É óbvio que essa indicação é apenas um guia e cada empresa pode, e deve, definir os seus critérios de priorização. Para aqueles que não pensaram nisso, a ideia criada pelo ITIL é a seguinte: a prioridade de um incidente ou de um problema é identificada por meio do produto de dois fatores importantes, o Impacto e a Urgência, ou seja, estes dois fatores determinarão o quão prioritário um incidente e/ou um problema é.

E como o ITIL define Impacto e Urgência? As metodologias tratam esse assunto de forma parecida, mas cada uma tem um viés, dependendo do foco de cada uma. No ITIL, a Urgência resume-se a identificar a quantidade de tempo que um incidente pode ter até que exista um significativo impacto no negócio. Perceba que a definição de Urgência, refere-se ao Impacto que por sua vez significa saber a que ponto os Níveis de Serviço estão sendo afetados pelo incidente ou pelo problema. Assim, para ilustrarmos melhor, poderíamos dizer que na figura acima, o Impacto representa o tamanho da bomba e a Urgência representa o tamanho do pavio.

Resumindo o assunto, podemos dizer que o ITIL faz a priorização dos incidentes e dos problemas por meio da seguinte equação matemática:

P = I * U,

onde P é a Prioridade, I é o Impacto e U é a Urgência.

A partir da definição da prioridade, cada resultado de P deve ter atrelado a ele, um tempo máximo estabelecido para resolução e uma descrição (Crítico, Alto, Médio, Baixo, etc). Nesse ponto temos que ter cuidado na classificação para que não aconteça o que já vi acontecer em várias empresas que acabam descrevendo a prioridade como Altíssima, ou Super Alta, ou Mega Super Alta e assim por diante. Essa falta de cuidado em determinar corretamente a prioridade pode levar ao descrédito em relação ao tratamento dos incidentes e problemas.

Sigam-me os bons!!!

ITIL V3 – Operação do Serviço – Conceitos e Definições – Erro Conhecido

Depois de passarmos por vários conceitos, prometo que esta postagem trará o último conceito que precisamos ter em mente para entendermos os processos da fase de Operação do Serviço, ok? O que trataremos aqui é o conceito de Erro Conhecido. Para os menos avisados, pode até parecer ofensa perguntar o que é um Erro Conhecido. Como assim? Não sabe falar português? Qual a dificuldade em se entender o que quer dizer um erro conhecido? Calma! Muita calma nessa hora... Antes que alguém faça as perguntas (desaforadas) acima é importante saber que para o ITIL, um Erro Conhecido refere-se a um Problema (ver postagem que fala sobre Incidentes e Problemas) que tem uma causa raiz identificada e documentada, além de uma solução de contorno igualmente identificada e documentada.

Se fossemos colocar a definição de Erro Conhecido em uma equação matemática, ela seria mais ou menos assim:

Erro Conhecido = Problema + Identificação da Causa Raiz + Solução de Contorno.

Nunca é demais falar que, obviamente, os Erros Conhecidos devem estar registrados em uma base de dados e o responsável por armazenar e atualizar essas informações é o processo de Gerenciamento de Problemas que será visto em postagens posteriores.

É importante lembrar que uma Solução de Contorno, como visto na postagem anterior, pode não ser ainda a solução definitiva para o problema, porém saber que um determinado erro é conhecido, dá uma segurança maior para o usuário, pois sabe-se que há uma solução de contorno pronta para ser aplicada caso o problema ocorra. Vocês acham que isso é pouco? A Microsoft, por exemplo, costuma lançar alguns softwares com Erros Conhecidos, por motivos de competição ou momento de mercado. Coisas que se fossem esperar para serem definitivamente resolvidas poderiam representar a perda de alguns milhões de dólares. Assim, a Microsoft tem a solução de contorno já pronta para aplicar, caso seja necessário.

Passado pelos conceitos, vamos verificar algumas técnicas e ferramentas e entrar nos processos da Operação do Serviço.

Sigam-me os bons!!!