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

ITIL V3 – Coffee Break 2 – Feliz 2012!

Caros leitores, gostaria de agradecer a todos que acompanharam o nosso humilde blog durante esse ano de 2011!!! A todos vocês, um ano de 2012 cheio de paz, saúde e felicidade!!

Espero que no próximo ano possamos continuar disseminando o conhecimento em torno da gestão de TI e que vocês possam aproveitar ao máximo!!!

Ainda em tempo, gostaria de agradecer a Deus pelo ano que termina, com todas as suas alegrias e tristezas. Obrigado por me guiar todos os dias!!!

Para finalizar,

e...

Sigam-me os bons!!!!

ITIL V3 - Operação do Serviço - Conceitos e Definições – Solução de Contorno

Outro conceito muito interessante do ITIL diz respeito à Solução de Contorno. O Workaround, como é dito em inglês, representa uma forma não definitiva de superar alguma dificuldade ou algum incidente que está impactando a prestação de um determinado serviço de TI. Todavia, é importante salientar que o ITIL prevê soluções de contorno também para problemas e não apenas para incidentes, uma vez que, em determinadas ocasiões, o processo de Gerenciamento de Incidentes pode não ter achado uma solução de contorno e aí, quando o processo de Gerenciamento de Problemas o identifica, ele informa para que o serviço seja restaurado.

Dessa forma é possível entender que a solução de contorno busca reduzir ou até mesmo eliminar o impacto de um incidente, ou de um problema, enquanto a solução definitiva ainda não foi encontrada.

Fazendo uma analogia com a figura acima, poderíamos dizer, de forma bem humorada, que a pessoa achou uma solução de contorno capaz de restaurar o serviço (disponibilidade de água) mesmo sem ter uma solução definitiva para o incidente. É claro que nem sempre a solução de contorno pode ser encarada como uma “gambiarra” e em certas ocasiões ela até se torna a solução definitiva, mas, na maioria das vezes, nós da área de TI sabemos que a “gambiarra” é quem restaura de forma mais rápida o serviço, até que tenhamos a certeza em relação à solução definitiva a ser aplicada.

É bom deixar claro que não há nada de errado em se implementar Soluções de Contorno, desde que seja realmente temporária e que uma solução definitiva seja buscada incessantemente, com o risco de fazer com que uma “gambiarra” piore ou até danifique de forma significativa o serviço prestado.

Continuemos, na próxima postagem, com os nossos conceitos e definições...

Vamos juntos?

ITIL V3 – Operação do Serviço – Conceitos e Definições – Incidentes e Problemas

Para aqueles que estão habituados com o ITIL, as definições de Incidente e Problema já estão no sangue, mas como o nosso blog é bastante democrático, vejamos como o ITIL os definem:

• Incidentes - “Uma interrupção não planejada de um serviço de TI ou a redução na qualidade de um serviço de TI. Falha em um item de configuração que ainda não tenha impactado o serviço é também um incidente, como por exemplo a falha de um disco em um array de discos.”


• Problemas - “é a causa de um ou mais incidentes.”

Colocando em outras palavras, um Incidente tem uma relação muito íntima com o efeito que uma interrupção causa no serviço e um Problema tem uma relação íntima com a causa raiz que fez com que houvesse a interrupção de um determinado serviço de TI.

Em postagens posteriores trataremos dos processos que o ITIL preconiza para tratar Incidentes e Problemas. Nesta postagem, o nosso objetivo é identificar os conceitos e as diferenças entre os termos para que, ao estudarmos os processos, o entendimento seja fácil e sólido, ok?

Aproveitando a definição de incidente, é comum algumas pessoas que ainda não tiveram um contato mais profundo com a biblioteca ITIL, confundirem este conceito com o conceito de Requisição de Serviço (RdS). Este último é definido como qualquer demanda feita por usuários dos serviços para a área de TI que não afetam o fluxo natural da prestação do serviço e não significam interrupção ou degradação da qualidade do mesmo. Exemplos mais comuns de Requisições de Serviço são: pedidos de troca de senhas, solicitação de configuração de máquinas de novos usuários, etc.

Conceitos entendidos, podemos passar para outras definições que serão úteis para o entendimento dos processos da etapa de Operação do Serviço, dentro do ciclo de vida do serviço de TI preconizado pelo ITIL.

Vamos em frente que atrás vem gente!!!