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

Finalizando os processos da fase de Operação do Serviço do ciclo de vida de serviços de TI preconizado pelo ITIL V3, falaremos, nesta postagem, do Gerenciamento de Acesso. Este é um novo processo do ITIL V3 para velhos assuntos que existem desde os primórdios dos sistemas informatizados.

O Gerenciamento de Acesso trata, como o próprio nome sugere, dos acessos, perfis e direitos de usuários ou de grupo de usuários a um determinado serviço ou grupo de serviço de TI. Não há muito o que ser dito sobre esse processo, mas uma característica interessante é que o Gerenciamento de Acesso utiliza-se de outros processos como entrada e saída, uma vez que o fornecimento dos direitos e acessos dos clientes é feito por meio de Requisições de Serviço e as definições das políticas que são aplicadas por este processo proveem dos Gerenciamentos de Segurança e Disponibilidade da fase de Desenho do Serviço.

Vocês podem então estar se perguntando, para que ele existe afinal? Bem, na minha opinião particular, o ITIL tenta abranger todos os aspectos do serviço de TI e há, em relação ao Gerenciamento de Acesso, a nítida intenção de dar ao processo uma importância maior, destacando-a de outras requisições de serviços normais (dúvidas, elogios, pedido de algum serviço, etc). Acredito que problemas de acessos indevidos têm comedido muitas empresas que prestam serviços de TI e estes acessos indevidos certamente têm causado muitos danos a várias organizações.

Caro leitor, estamos nos aproximando do final da nossa viagem pelo ITIL V3. Ainda temos algumas coisas interessantes e novas dessa biblioteca, portanto, não deixem de acompanhar as próximas postagens...

… sigam-me os bons!!!

ITIL V3 – Operação do Serviço – Processos – Cumprimento de Requisitos

Nos processos de Operação do Serviço já passamos pelos incidentes, problemas e eventos, mas e as dúvidas e solicitações do dia a dia que não indicam falha ou perda de performance no serviço de TI? O ITIL, preocupado em abranger todos os aspectos do serviço de TI e levando em consideração o próprio conceito que ele criou para serviço (“meio para que a empresa tenha valor”), preparou um processo específico para tratar desse assunto, o Cumprimento de Requisição. Concordo que o nome do processo ficou meio fora do padrão utilizado pela própria biblioteca ITIL, mas o que ele se propõe a fazer, na verdade, é disponibilizar um canal para que usuários e clientes possam solicitar e utilizar serviços padronizados que tenham um processo pré-definido de qualificação e aprovação.

Para quem já tem um pouco de experiência, vai perceber que este processo utiliza-se das famosas RdS (Requisições de Serviço) para operacionalizar as entradas que são feitas pelos usuários, quase sempre pela Central de Serviço, outro elemento crítico para esse processo. Por falar na Central de Serviço, normalmente essa função terá a responsabilidade de receber, monitorar, executar, enviar e despachar as requisições que forem feitas pelos usuários.

Apesar de criar um processo específico para tratamento das RdS, o ITIL deixa muito claro que a automatização de certas rotinas é muito bem-vinda, especialmente se a prestadora do serviço de TI tiver total conhecimento sobre as mesmas. Além disso, o ITIL também deixa claro que práticas de autoatendimento também são muito valiosas, pois reduzem a fila de atendimento, o que permite maior agilidade para as RdS que de fato necessitam de uma interação mais aprofundada.

Por fim, não podemos nos esquecer que este processo também é o responsável por receber as reclamações, comentários e solicitações de informações gerais do serviço.

Na próxima postagem, trataremos do último processo da Operação do Serviço. Vocês saberiam me dizer qual é?...

… Sigam-me os bons!!!

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

Caros leitores do nosso humilde blog, nesta postagem estaremos falando de um novo processo do ITIL V3, o Gerenciamento de Eventos. Este processo vem preencher um gap deixado pelo ITIL V2 e tem como principal objetivo a detecção de todos os eventos que acontecem no serviço de TI, sua contextualização e a definição das medidas adequadas de controle que possam ser tomadas.

Quando falamos de todos os eventos, pode parecer algo utópico, mas para entendemos a afirmativa anterior, temos que saber o que o ITIL chama de “evento”. Assim sendo, Evento, na visão do ITIL, representa qualquer ocorrência detectável ou percebida que tenha relevância para o gerenciamento do serviço de TI. Atenção para o termo “relevância”. Não é qualquer coisa que aconteça, mas sim todas as coisas relevantes para o serviço. Estas sim devem ser capturadas pelo Gerenciamento de Eventos.

É importante perceber, como consequência do objetivo desse processo, que o Gerenciamento de Eventos se torna a base para a monitoração operacional do serviço e seu controle.

O ITIL V3 coloca alguns exemplos de eventos, listados abaixo, mas é bom deixar claro que os eventos não se restringem a apenas aos colocados aqui.

• Eventos que significam operações regulares. Exemplo: identificação que um usuário logou em um sistema, um e-mail chegou ao seu destino final ou ainda a notificação que um job agendado foi executado.


• Eventos que significam uma exceção. Exemplo: Um servidor está acima da faixa aceitável de utilização, uma situação não usual ocorreu em um processo de negócio, etc.


• Eventos que significam uma operação não usual, mas sem ser excepcional. Exemplo: A memória de um servidor está a 5% do máximo permitido, o tempo de finalização de uma transação está 10% maior do que o acordado, etc.

Para finalizar, podemos dizer que o Gerenciamento de Eventos é uma das entradas para uma série de outros processos da Operação do Serviço, como por exemplo o Gerenciamento de Incidentes e o Gerenciamento de Problemas.

Na próxima postagem, continuaremos na nossa viagem pelos processos da fase de Operação do Serviço do ciclo de vida proposto pelo ITIL.

Vocês não perdem por esperar!!!

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

Como havíamos falado na postagem anterior, falaremos neste momento de outro processo bastante maduro dentro da biblioteca ITIL, mas que nem todas as empresas o implementam da forma como deveria. Estamos falando do famoso processo de Gerenciamento de Problemas. Este processo tem o objetivo principal de identificar a causa raiz de incidentes e definir a solução definitiva para os mesmos a fim de que os incidentes recorrentes sejam eliminados e o impacto daqueles que não podem ser evitados seja reduzido.

Identificar a causa raiz dos incidentes significa dizer que, para o Gerenciamento de Problemas, o mais importante é descobrir o porquê das coisas estarem acontecendo fora do que foi acordado nos SLAs. É legal notar que este processo não deve ser apenas reativo, uma vez que, a partir de uma análise dos incidentes registrados, pode-se iniciar, proativamente, as atividades para resolver definitivamente aqueles que acontecem de forma recorrente.

Dentro desse processo existem uma série de atividades que sugiro fortemente que sejam aprofundadas para quem tem o interesse em se certificar em ITIL, porém para o nosso humilde blog, nos restringiremos a identificar atividades que possam trazer informações mais relevantes ao entendimento do processo.

Após a detecção do Problema, do seu registro, da categorização e da priorização, temos a atividade de investigação e diagnóstico. Esta atividade diz respeito à análise de causa raiz, que pode ser tanto reativo quanto proativo, como dito anteriormente. O fato principal aqui é que o Gerenciamento de Problemas pode encontrar não uma solução definitiva, no primeiro momento, mas soluções de contorno, que seriam uma forma temporária de superar as dificuldades que porventura um serviço possa estar passando. Neste caso, o registro do problema continua aberto e as investigações também devem continuar, uma vez que, conforme dissemos, o Gerenciamento de Problemas tem como objetivo principal a identificação da causa raiz e a solução definitiva de um grupo de incidentes, ou de um incidente que tenha se tornado um problema grave.

Outra questão interessante sobre a descoberta da solução de um problema está na definição de quando se aplicar esta correção. As vezes não é possível aplicar a solução definitiva no momento em que a mesma é identificada. Assim, o Gerenciamento de Problemas, que trata de todo o ciclo de vida do Problema, deve se preocupar, também, com a abertura de requisições de mudanças para que os processos que tratam de mudanças possam agir de forma ordenada e controlada.

Na próxima postagem, continuaremos com os processos da etapa de Operação do Serviço do ciclo de vida do Serviço definida pelo ITIL V3...

… Sigam-me os bons!!!

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