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

O Gerenciamento de Nível de Serviços é o processo que forma o vínculo entre o departamento de TI e os clientes. Para implementar este processo com sucesso é necessário que os outros processos da ITIL já tenham sido implementados.

O foco principal deste processo é assegurar a qualidade dos Serviços em TI que são fornecidos, ao um custo aceitável ao negócio.

Mas a questão que permanece é: quando este acordo tem de ser revisto? Até que ponto sua redação e entendimento atendem as necessidades da empresa do ponto de vista do negócio e financeiro? E mais, quem são os responsáveis por entregar idéias para seu aprimoramento?

Ser Gerente Comercial tem uma característica que me agrada muito: conhecer pessoas de diversas corporações, normalmente da área de TI, que expõem suas dificuldades e conquistas na gestão de serviços de TI. Essas trocas de experiências são fundamentais já que que ambos se beneficiam do conhecimento que partilham.

Bem, numa dessas ocasiões, visitando uma grande corporação nacional me deparei com um caos bastante interessante, que partilho nesse post.

A Coporação X (sim, o nome é fictício mesmo) o Sr. CIO (acrônimo do nome para preservar sua identidade) relatou que ainda que sua corporação dispusesse de um SLA muito bem definido, e que atendia boa parte das necessidades das partes envovlidas, o acordo havia criado uma situação bastante capciosa, explicando:

Sr. CIO: Marco, meu SLA é bastante claro para todos os envolvidos e rege a disponibilidade dos serviços dentro das minhas necessidades financeiras (custos). Porém, há momentos em que eu penso que o rigor que ele propiciou me deixa em situações complicadas.

Eu: Desta forma assertiva que expõens, parece que realmente o SLA cumpre seu papel, mas o que lhe incomoda?

Sr. CIO: Olha, desde que o serviço não necessite de melhorias (aprimoramentos no sistema) tudo funciona muito bem.

Eu: Me explique melhor.

Sr. CIO: Veja o caso de meu sistema de telefonia. Mantê-lo em funcionamento é mandatório para meu negócio, e realmente o sistema se mantêm muito estável já optamos por uma plataforma aberta (Asterisk). Todavia, quando ocorre uma mudança física, por exemplo, alguém muda-se de lugar, preciso mudar o comportamento do sistema a fim de efetivar logicamente a mudança e isto é tratado como uma melhoria.

Eu: Entendo, mas, onde está o problema? Parece-me que realmente trata-se de uma melhoria que deve precisar do apoio do CAB (Change Advisory Board)*, correto?

Sr. CIO: Pois é isto mesmo. E é aí que sinto que temos de dar muito atenção para melhorarmos. Veja, o CAB reune-se mensalmente para aprovar (ou reprovar) quais mudanças devem ser implementadas. No caso de comentei contigo veja o paradoxo que criamos: pense que quando uma nova pessoa entrar na área de contato com cliente (Comercial, por exemplo) ela terá de aguardar a reunião para que possamos modificar nosso sistema de telefonia para contemplar a entrada desta pessoa. Este trabalho, modificar o sistema de telefonia, não leva mais do que 10 minutos para ser executado. E fica a questão: por quê esperar até um mês para executar uma situação crítica sendo que em minutos ela se resolverá?

Eu: Entendi, mas porque simplesmente não muda-se a forma como as atividades foram priorizadas? Digo, porque não tratam estas ocorrências como rotineiras já que a mudança de lugar físico parece fazer parte da rotina da empresa?

Sr. CIO: Porque simplesmente nosso SLA foi constituído desta forma e até o momento não temos como modificá-lo em tempo de voo.

Eu: Entendo… (preferi não continuar o assunto já que ele parecia ficar cada vez mais irritado com o fato ocorrer mesmo após ter empregado muito fosfato para empreender o melhor para a corporação).

Resumindo: não há mágica para encontrar a melhor solução, a experiência é fundamental (e a agilidade também).

Até a próxima, Marco Aurélio.

* Change Advisory Board pode ser definido como um grupo de pessoas que aconselha a mudança, priorização e agendamento. Este conselho é normalmente constituído por representantes de todas as áreas, incluindo fornecedores.

O processo de Gerenciamento de Mudanças é responsável por decidir e coordenar as mudanças na área de TI, ou seja, controlar as mudanças para que elas sejam implantadas de forma eficiente, eficaz e assegurar que a infra-estrutura e TI permaneça alinhada aos requisitos do negócio, com o menor risco possível.

Para realizar uma análise de riscos adequada é importante o uso de uma Base de Gerenciamento da Configuração (também conhecida como CMDB – Configuration Management Database) que forneça todos os serviços e recursos relacionados ao item de configuração (CI – Configuration Item) que sofrerá a mudança.

Os principais objetivos deste gerenciamento são:

• Assegurar que os métodos padronizados estão sendo usados para o tratamento eficiente de todas as mudanças, reduzindo seus riscos e impactos;
• Minimizar incidentes relacionados com mudanças;
• Balanço entre necessidade e impacto.

Pode-se implementar esse processo isoladamente, mas é importante o apoio do Gerenciamento de Configuração para dar suporte à avaliação de impacto, indicando os itens de configuração envolvidos na mudança. Também vale ressaltar que o controle das liberações (implantação da mudança) não é de responsabilidade do Gerenciamento de Mudanças, mas sim do Gerenciamento de Liberações.

Sueli Marowski Goldacker

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