Atualmente quando o suporte se encontra num momento de alta demanda é extremamente complicado conciliar o fluxo de mudança o gestor de problemas hoje tem a  tarefa de mapear desde a abertura de um problema até o fechamento deste por meio da liberação da RFC (Request for Change).

É de suma importância mapear a origem desta RFC que pode ser:

• Incidente
• Problema
• Incidente gerado a partir de monitoramento
• Mudança externa (aumento de preço, regras fiscais etc…)
• Projeto (pacote de melhorias fechado em determinado projeto)

Garantir o conhecimento da origem da RFC também fecha o fluxo da mudança que vai desde a elaboração da RFC até o encerramento do registro da mudança.

A gestão de mudanças está intimamente ligada a vários outros processos, porém vamos nos ater aos processos de gestão de incidentes e problemas que são os processos mais críticos considerando um Service Desk em alta demanda conforme comentamos anteriormente.

Tomando a definição de problema que é ‘causa desconhecida de um ou mais incidentes’ para que o gestor de problemas possa fazer um gestão ideal de problemas a classificação de incidentes é primordial, pois é esta etapa da gestão de incidentes que irá definir a origem de uma possível RFC.

Hoje no suporte temos constantes envios de RFC, melhorias do cliente, melhorias externas, fornecedores enviam changes para nossa validação e envio de correções que não passaram por nosso Service Desk tornando-se um caos mapear qual verdadeira origem da RFC, é importante esta associação de uma mudança a um problema  para que nas reuniões possamos justificar ao nosso cliente que determinado problema teve sua incidência de chamados diminuída por um mudança ocorrida.

Através do ciclo PDCA (ver.: livro Melhoria de Serviço Continua)  temos uma ampla visão de quais problemas tem maior incidência e quais tiveram sua incidência reduzida, mas para o PDCA ser bem alimentado este precisa de informações exatas, uma forma de garantir isso é entendendo a importância deste processo desde a classificação do incidente até o fechamento do problema a partir do registro da RFC.

Mostrar o controle destes processos passa ao cliente uma sensação de organização e segurança de que está valendo a pena contratar o Service Desk para manter o serviço disponível.

O WordPress.com que oferece um serviço gratuito de hospedagem teve uma pane e saiu do ar por algumas horas no dia 18/02, e deixando 10,2 milhões de blog fora ar. Mas o que isso tem haver com Itil? … Tudo!

Aproveitei a notícia apenas para ilustar alguns aspectos desse fato no mundo do Itil, tentando evidenciar na prática alguns processos dessa biblioteca de boas práticas.

O primeiro e mais evidente deles, o serviço saiu do ar, o que caracteriza um incidente, e que precisar ser resolvido no tempo mais rápido possível. Dessa forma foi contornado (work around) através de uma identificação superficial de onde estava o problema. A prioridade era restabelecer o serviço, colocando as páginas no ar novamente.

Após isso a WordPress afirma que irá investigar a fundo a causa do incidente, ou seja gerencia de problemas irá entrar em ação para identificar a causa raiz do problema ocasionou a parada no serviço.

Um terceiro aspecto é uma mudança não prevista em um roteador importante no DataCenter parceiro, quem ou qual processo fez a liberação dessa mudança no ambiente de produção? O serviço ficou fora por 110 minutos (dowtime). A partir dai já se pode pensar também em nível de serviço, e é bem provavel que existia um acordo de nível de serviço, para estipular o tempo para restabelecer um serviço em caso de incidente com prioridade crítica.

Existem mecanismos de de redundância, mas na hora “H” não funcionaram (disponibilidade e continuidade), talvez por falta de testes adequados, enfim.

A idéia não é encontrar o culpado, e sim identificar as lacunas em cada processo e aperfeiçoa-lo, é um ciclo constante por melhoras. Provavelmente além desses existem outros aspectos que possam ser abordados, caso alguém enxergue algum outro, por favor, comentem.

Um abraço!

Alexsander Oliveira

Existe um livro da versão três (V3) do Itil (Continual Service Improvement, 2007) que trata exclusivamente desse tema. É intitulado como um guia prático em avaliação e aperfeiçoamento da qualidade dos serviços, e é indicado para pessoas ligadas as boas práticas de gerenciamento dos serviços de TI que, pretendem compreendê-las e melhorá-las continuamente. Baseado no ciclo de Deming conhecido como Plan, Do, Check and Act, o famoso PDCA.

São definidos 7 passos para o processo de melhora continua.

1 – Definir o que você deve medir.
Converse com as pessoas do negócio, clientes, gerencia de TI. Utilize o catalogo de serviços como ponto inicial bem como os requisitos de níveis de serviço de diferentes clientes. No cenário ideal, o que deveria ser medido?O que é importante para o negócio?
Faça uma lista do que você entende que deveria ser medido, mas não uma lista complexa, seja objetivo.

2 – Definir o que você pode medir.
As organizações podem encontrar limitações no que ela está medindo, o fato é que, se você não pode medir, não deve nem aparecer no acordo de nível de serviço.
Identifique as ferramentas que você usa atualmente para isso. Essas ferramentas incluem softwares de gerenciamento, monitoramentos, relatórios, investigação, entre outros. Nessa etapa é possível inclusive identificar oportunidades.

3 – Coleta de dados.
Os dados coletados devem estar baseados nas metas e objetivos. Essa coleta pode ser feita por ferramentas de gerenciamento de monitoramento. Nesse ponto a informação que vem é bruta, ainda não está transformada e trabalhada, porém é importante que esteja estruturada de padronizada.

4 – Processamento de dados.
Nessa etapa os dados são processados de acordo com os anseios da melhora continuada do serviço e com os indicadores de desempenho. Ou seja, os dados serão processados de acordo com os objetivos de seu gerenciamento. As origens desses dados podem ser, por exemplo, de ferramentas de monitoração, relatórios, etc.

5 – Análise dos dados.
É nesse ponto que os dados são transformados em informação para identificar as lacunas nos serviços, tendências e impactos sobre os serviços.
Essa análise de dados transforma a informação em conhecimento e trás habilidades para organização.

6 – Apresentar e usar a informação.
As perguntas sobre o porquê de determinada informação foi pega e trabalhada são respondidas aqui. A idéia é apresentar exatamente os resultados que seriam obtidos com as melhorias.

7 – Implementar as ações corretivas.
O conhecimento aprendido é usado para aperfeiçoar, melhoras e corrigiradequar os serviços. O pessoal normalmente identifica os problemas e as soluções, entretanto é necessário controlaracompanhar esse processo de melhoria. As ações corretivas precisam ser tomadas para prover as melhorias necessárias ao negócio. Dessa forma cria-se uma baseline e novos ciclos são iniciados.

A melhora continuada dos serviços, trás diversas oportunidades a organização. Baseado em suas metas, objetivos e tipos de serviços prestados, você pode priorizar as atividades e iniciativas de melhorias.

Cada uma dessas etapas, integradas foram um ciclo, conforme a OGC no livro Continual Service Improvement, elas constituem uma espiral do conhecimento. Nas práticas atuais, conhecimento acumulado e sabedoria derivam desse conhecimento.

Alexsander Oliveira

No que tange à área de Service Suport estabelecida nas boas práticas da ITIL, tais serviços, quando mapeados e representados na forma de Incidentes, IC’s (Itens de Configuração), Problemas, Mudanças, Versões, etc.., possuem uma natureza sistêmica pelo fato de se relacionarem conceitualmente, facilitando assim a modelagem e desenvolvimento de ferramentas no intuito específico de tornar fácil e viável o gerenciamento e uso estratégico da informação.

Por exemplo, segundo as boas práticas da ITIL, sabemos que um Incidente está intimamente associado a um Problema, que por sua vez pode estar relacionado a um ou mais Itens de Configuração. O Problema também poderá culminar em uma Mudança, que necessitará de uma nova Versão. Conforme foi mencionado, entende-se que esta associação conceitual pode ser transcrita para uma modelagem de software, culminando na construção de uma nova ferramenta de apoio.

Porém, devido às características mutáveis assim como as necessidades específicas de cada organização e serviço prestado, existirão, sem dúvidas, desafios a serem encarados na concepção destes novos sistemas, sendo que um destes desafios diz respeito à disciplina de Gerenciamento de Problemas.

Ao desenvolver um sistema que visa suprir as principais práticas apresentadas por tal disciplina, se faz necessário primeiramente controlar de forma detalhada as etapas necessárias para concluir o Ciclo de Vida do Problema, ou seja, desde a identificação de suas características fundamentais, definição do work around (contorno), investigação detalhada da causa, até a elaboração do plano de ação.

Além do detalhamento das etapas do Ciclo de Vida, é importante que a ferramenta demonstre de forma sintética a situação atual do Problema (status), ou seja, se o mesmo está em investigação, se a causa foi identificada, o plano de ação sugerido ou aplicado, etc.

Outro importante aspecto a ser considerado é a existência de uma funcionalidade destinada a relacionar imagens, mídias, e-mails e outros tipos de arquivos, anexando assim complementos que permitirão uma melhor compreensão do Problema. O ideal é que todas as informações estejam associadas a uma Base de Conhecimento, permitindo o acesso para rápida busca. Esta característica poderá se tornar extremamente importante para os técnicos do Primeiro Nível de Service/Help Desk, pois trará a funcionalidade de realizar buscas por procedimentos para solução e contorno dos Problemas (scripts), visando facilitar o tratamento eficiente e adequado dos Incidentes abertos.

Possibilitar uma integração flexível com um CMDB (Configuration Management DataBase), é sem dúvida uma outra necessidade para garantir a devida coesão entre as gerências de Problema e Configuração, permitindo a associação do Problema com os respectivos IC’s afetados.

O Sistema deve prover, acima de tudo, a autonomia necessária para que o Segundo ou Terceiro Nível, possa atuar de acordo com a prioridade real necessária a cada Problema. Deve para isso disponibilizar um prático e funcional controle visando identificar quais Problemas estão pendentes para análise, e quais etapas necessitam ainda ser realizadas para finalização de seus Ciclos de Vida.

Não existindo um controle prático e funcional nem uma priorização adequada dos Problemas, certamente a ferramenta poderá ser caracterizada como deficiente, pois não estará de acordo com seu principal objetivo: disponibilizar a informação de forma gerencial e estratégica, oferecendo recursos para correta tomada de decisão, tanto pelos técnicos do Segundo e Terceiro Nível, quanto pelos responsáveis pela gestão e governança de TI.

Afinal, se não se sabe quais são os inimigos (quais Problemas estão pendentes e quais são suas prioridades), nem quais seus pontos fracos (quais etapas do Ciclo de Vida de cada Problema devem ser analisadas), como poderíamos arquitetar uma “estratégia de combate” eficiente? Citamos aqui apenas algumas características consideradas importantes, sendo certo que existem muitos outros requisitos que devemos levar em conta na construção deste tipo de ferramenta.

Para finalizar, é essencial que esta ferramenta possua integração com outros sistemas correspondentes às demais disciplinas da ITIL, conforme foi citado anteriormente em relação à gerência de Configuração e o CMDB. Só assim conseguiremos rastrear todo Ciclo de Vida do Problema, desde sua origem (em um Incidente, uma Ação Pró-ativa, etc..), até sua solução definitiva, com provável realização de uma Mudança e/ou implantação de uma nova Versão.

Pablo dos Santos Alves

Problema é a causa de um ou mais incidentes. É interessante lembrar que um incidente deve ter um problema associado, toda via um problema não necessariamente deve estar associado a um incidente, já que a origem de um problema será em função de uma atividade pro-ativa ou reativa.

Como já deve ser de conhecimento, o dia-a-dia de muitas equipes de suporte é bem corrido e usualmente muitas delas trabalham apagando incêndios. Felizmente a realidade das equipes de suporte da Teclógica é diferente.

Em nossa “linha de frente” do atendimento está o primeiro nível (Service Desk), que é responsável pelo primeiro contato com o usuário, em muitos casos é até um ponto único de contato. Nesse nível são feitas análises dos incidentes registrados, coletando dados, fazendo investigações em itens de configuração, consultando base de conhecimentos, erros conhecidos e investigações para contorno. Veja, o foco está em resolver o incidente, fazendo o contorno, diminuindo o tempo de interrupção do serviço ao usuário.

Caso o primeiro nível consiga fazer o contorno resolvendo o incidente e já exista algum problema que defina a causa do incidente, o segundo nível não é acionado, se não conseguir ou for um incidente grave ou ainda conseguir contornar e não identificar a causa raiz, o segundo nível é acionado. Onde a analise poderá ser feita sem interrupções de usuário. Esse processo conhecido como escalonamento funcional.

Nesse estagio é feito um levantamento mais a fundo do problema, para descobrir a causa raiz. São feitas analises podendo envolver técnicas de resolução de problemas como: analise de Kepner e Tregoe, Brainstorming, Diagrama de Ishikawa e analise de Pareto, conforme sugestão na versão três do Itil. Após entender qual é o problema será necessário desenvolver uma solução de contorno (work around) e em seguida é direcionado para o gerenciamento de mudanças fazer a alteração necessária (Modificar fontes de sistemas, troca de servidor, etc) para que seja aplicada uma solução definitiva. O fluxo abaixo ilustra bem o inicio e fim do processo.

Incidente -> Problema -> Erro Conhecido -> Solicitação de Mudança

Após aprovada a mudança é o gerenciamento de liberações que faz a liberação para o ambiente produção e dispara um evento informando a gerencia de configuração que um determinado item de configuração foi atualizado. Mas a tarefa do gerenciamento de problemas ainda não terminou. Deve ser verificado se o problema realmente foi erradicado do ambiente de produção.

Desse modo que se percebe que existe um ciclo de vida para o problema e toda uma complexidade em gerenciá-lo. De fato, não é uma tarefa fácil, mas não é difícil perceber os excelentes resultados obtidos com essas praticas.

Alexsander Oliveira

Alguns posts a respeito são enfáticos em dizer que um CMDB não pode ser construído conforme a ITIL preconiza. Não quero concordar nem discordar. Apenas relatar que uma iniciativa que pretende contruir uma base de dados relevante e ágil realmente pode consumir muito investimento (e talvez não alcançar os benefícios esperados).

A Wikipedia no artigo referente a CMDB tenta resumir uma definição a respeito em apenas duas porções: Introdução e propósito e na verdade não consegue. Mas então? Como eu posso resumir um CMDB?

Para responder a este questionamento vou tomar como base um material criado pela Evergreen entitulado “Nine Steps to Implement a Successful CMDB Project” que disponibilizo aqui para download.

Considere uma boa definição de um CMDB os seguintes itens:

1. Trata-se de uma aplicação de suporte que propicie a visualização sobre o que há e como (se?) ocorrem interações entre os elementos de um parque tecnológico
2. Deve monitorar e reportar os eventos de configuração
3. Deve padronizar os componentes atribuindo uma identidade, propriedade e estruturação
4. Deve reconhecer diversos tipos de componentes (CIs – Configuration Items) e seus relacionamentos a exemplo de: redes, servidores, softwares, arquivos etc.

Parece fazer bastante sentido o exposto acima? A mim ainda não. Então tentemos seguir por um jeito mais pragmático: exclusão de possibilidades.

O que um CMDB NÃO É:

• Uma base de dados complexa ou especialmente desenvolvida para esta finalidade
• Uma aplicação orientada a processo como Mudanças ou Liberações
• Apenas uma aplicação de monitoramento, apesar de incluir o gerenciamento de alguns tipos de eventos (isto me lembra Nagios, por que será?)
• Um software para controle de versão
• Um Catálogo de Serviços (apesar de que ambos devem usar a mesma estrutura de CI)

Ainda parece confusa a definição de um CMDB? Se sim, avalie a figura abaixo:

Figura 1: Resumindo a relação do CMDB na ITIL

Parece ser claro que o CMDB deve fornecer informações às diversas disciplinas da ITIL com intuito lógico de municiar todas com dados que direcionem seus esforços no alcance de suas atribuições.

Antes de continuar, deixe-me comentar um pouco sobre o que é um CI (Configuration Items). A melhor definição de um CI em si é muito simples: “Determinado objeto ou elemento no ambiente de TI que seja gerenciável.” Um CI, por definição, está sob a Gerência de Mudanças. Um ciclo de vida de um CI pode ter vários estágios, e muito frequentemente é indefinida, em termos de tempo – ao contrário de um projeto ou incidentes, que são geridos principalmente em termos de progresso através da sua vida e último encerramento.

Assim exposto, faz sentido pensarmos em CI como uma vasta gama de possibilidades abrangendo desde o mais óbvio (desktop) até o nem tão óbvio (processador de uma máquina) não esquecendo é claro de impressoras, switches, aplicações (sim softwares) e afins.

Bem, a intenção deste post é despertar o interesse sobre esta função da Biblioteca ITIL e recomendar a avaliação de pelo menos uma ferramenta de mercado que pode ser utilizada de forma gratuíta por até um ano: o CMDB Discovery.

O CMDB Discovery tem uma concepção interessante já que ele foi desenvolvido a partir de duas iniciativas:

1. Das necessidades que a Teclógica tinha em montar uma base de dados consistente sobre sua própria infra-estrutura de TI e de seus clientes
2. Da minha necessidade em estudar a função e desenvolver uma monografia que pudesse ser implementada e transformada em algo palpável

Desta primeira iniciativa só tenho a recomendar: avalie o software e entenda como o CMDB pode auxiliar.

Da segunda, faça o download da minha monografia em Engenharia de Sistemas e saiba mais sobre a ITIL e a função CMDB.

Por fim, agradeço os feedbacks.

Marco Aurélio Neuwiem