O que define a necessidade de uma Mudança?

Uma discussão interessante que vez e outra ouço no mundo do Gerenciamento de Serviços de TI, é relacionada à justificativa para registro ou não de uma mudança, dependendo do cenário em questão.

Este tema foi trazido à tona em Setembro de 2015. Revisitei o artigo e coloquei mais informações, para fomentar ainda mais a discussão sobre o tema.

Sabemos que na teoria (ITIL), o que define a necessidade ou não de uma mudança é basicamente a inclusão, alteração ou remoção de um item de configuração.

Entende-se por item de configuração, “qualquer componente ou outro ativo de serviço que precise ser gerenciado de forma a entregar um serviço de TI”.

Adicionalmente, e ainda segundo o glossário oficial da ITIL, “As informações sobre cada item de configuração são registradas em um registro de configuração no sistema de gerenciamento de configuração e é mantido por todo o seu ciclo de vida pelo gerenciamento de configuração e ativo de serviço. Os itens de configuração estão sob o controle do gerenciamento de mudança. Eles incluem tipicamente hardware, software, prédios, pessoas e documentos formais tais como documentação de processos e acordos de nível de serviço.”

Dada a definição acima, fica fácil identificar o íntimo relacionamento entre os processos de gerenciamento da configuração e ativo de serviço e gerenciamento de mudança, conhecidos como processos de controle na biblioteca ITIL.

O gerenciamento de configuração e ativo de serviço é “o processo responsável por garantir que os ativos requeridos para entregar serviços sejam devidamente controlados e que informações precisas e confiáveis sobre esses ativos estejam disponíveis quando e onde forem necessárias. Essas informações incluem detalhes sobre como os ativos foram configurados e os relacionamentos entre os ativos”.

Para garantir tal confiabilidade de informações, necessitamos, obviamente, de um outro importante processo de controle, o gerenciamento de mudança. É este processo que garante que qualquer item de configuração que entrar, sair ou for alterado no ambiente produtivo, seja devidamente atualizado juntamente ao processo de gerenciamento de configuração e ativo de serviço.

Então, até aqui, o resumo é o seguinte: Se for necessário adicionar, remover ou alterar itens de configuração, para que seja possível manter uma base de informações atualizadas acerca destes itens, é preciso controlar estas modificações com um registro de mudança. Do contrário, o resultado será, fatalmente, uma base de configuração desatualizada, imprecisa e não confiável.

Isto se aplica muito bem na maioria dos cenários, sob “condições normais de temperatura e pressão”. No entanto, é sabido que nos cenários dinâmicos atuais – com metodologias ágeis, clientes ávidos por resultados de qualidade, com janelas de execução reduzidas, otimizadas e com eficiência de recursos – nem sempre conseguimos controlar totalmente o que está ocorrendo no ambiente produtivo.

Portanto, como executar mudanças de forma emergencial, garantindo tal nível de controle?

Um exemplo: Qual seria a prática mais recomendável no caso de um incidente grave (conhecido em algumas organizações como major incident ou crise)?

Faço esta pergunta devido a já ter passado por inúmeros inconvenientes do tipo: “Mas para isso não é necessária uma Mudança, pois mexi no ambiente durante o atendimento do incidente!”

O fato de “mexer no ambiente durante o incidente”, faz com que não seja necessário o atualizar o que foi alterado? Desse modo, como fica a base de configuração (a mesma acabamos de citar acima, que é quem mantém as informações atualizadas e precisas)?

De um lado temos uma emergência, que deve ser tratada como tal, respeitando as prioridades do cliente. Por outro lado, é imprescindível que nos resguardemos quanto a:

  • Registros confiáveis de intervenções ocorridas no ambiente – para fins históricos e investigação futura, é conveniente termos informações assertivas quanto ao que ocorreu com nosso ambiente. Com registros de mudança precisos e confiáveis, qualquer identificação de causa raiz ou similar fica mais fácil e efetiva com este tipo de informação disponível.
  • Informações corretas e precisas no banco de dados do gerenciamento da configuração (BDGC ou CMDB) – É fato conhecido que muitos grandes provedores de serviços de TI, mantém bases de dados isoladas, conhecidas apenas por membros das equipes técnicas. Isto gera uma grande dependência do conhecimento de profissionais específicos, e não de um processo claramente definido. É imprescindível, portanto, que para manter o controle do ambiente produtivo tenhamos uma base de dados única com informações relevantes sobre nossa infraestrutura de serviços. Segundo as boas práticas preconizadas pela ITIL, é conveniente que tais informações sejam controladas através do gerenciamento de configuração e ativo de serviço.
  • Possibilidade de análise de impacto a partir dos relacionamentos entre itens de configuração – O CMDB, desde que devidamente desenvolvido e maturado, além de manter informações acerca dos itens de configuração, mantém os relacionamentos entre estes itens. Um CMDB neste nível, facilita a análise de impacto no negócio de clientes, a partir das mudanças que venham a ocorrer.
  • Auditorias de certificação e reverificação – Além dos benefícios acima, atualmente grande parte de licitações, RFPs e órgãos regulamentadores, exigem das organizações de TI a conformidade com as estruturas (frameworks) de boas práticas atuais, como ITIL e CObIT. O atendimento à estas boas práticas, certifica que estas organizações de TI, seguem práticas maduras de governança e gerenciamento de serviços de TI, dando maior visibilidade de mercado à estas empresas.

Adicionalmente, temos também que nos preocupar com o valor gerado aos clientes pela correta execução prática de processos de Gerenciamento de Serviços de TI orientados às boas práticas da ITIL.

Voltando ao caso de incidentes graves – aqueles que eu tenha que mover metade do mundo para solucioná-los no menor tempo possível, para que não sofra grandes e negativos impactos no meu negócio.

Para a grande maioria dos casos, normalmente a prática recomenda a utilização de Mudanças Emergenciais. Porém, quais são os limites? Quais são as definições mais apuradas? O que é considerado ou não como “inclusão, alteração ou remoção de um item de configuração”?

O conceito correto de mudanças emergenciais é sua utilização para evitar ou corrigir um incidente grave. Ocorre que atualmente, utilizam-se mudanças emergenciais para tudo:

  • Falta de planejamento das equipes operacionais – Quando questionado pela necessidade da emergencialidade, o requisitante da mudança responde: “porque o cliente pediu”. Mas pediu quando? Normalmente há um mês atrás, no entanto, o referido requisitante, estando atolado de atividades, trabalhando horas e horas extras em projetos compartilhados, não conseguiu solicitar a mudança em tempo. Ou simplesmente, não se planejou adequadamente…
  • Necessidade de negócio do cliente – Da mesma forma que existem casos onde o planejamento e o agendamento da mudança foi falho por conta de times operacionais, existem casos de emergencialidades reais solicitadas pelos clientes. Em treinamentos de certificação, sempre cito, como exemplo, eventuais promoções de concorrentes. Exemplo: Companhia aérea X lança uma promoção em seu website de passagens aéreas com 50% de desconto. A companhia aérea Y (nossa cliente), para poder competir em vendas, nos solicita – emergencialmente – que seu site seja alterado, para que possa fazer frente com sua concorrente.
  • Projetos – Infelizmente não tem sido exceção, mudanças emergenciais para o atendimento de projetos mal planejados e mal implementados.

De qualquer forma, sempre que ocorre uma mudança emergencial, não temos o tempo adequado para nos planejar e mitigar o risco e impacto advindo desta mudança. Portanto, é necessário cuidado com mudanças emergenciais. O ideal é que estas sejam exceções, não regras.

Um processo de mudança já maduro, tende a implementar o conceito de mudança padrão, suprimindo a necessidade de aprovação e discussão em comitês nestes casos:

Mudança padrão: “Uma mudança pré-autorizada que apresenta baixo risco, é relativamente comum e segue um procedimento ou instrução de trabalho, por exemplo, uma redefinição de senha ou fornecimento de equipamento padrão para um novo funcionário.”

Em alguns provedores em que trabalhei, o status do item de configuração (IC) era considerado como um atributo do mesmo. Neste caso, simplesmente ao alterar este status de ON para OFF, estávamos alterando um atributo, portanto alterando o CI. Entretanto, surge mais uma vez o questionamento: Não é muito exagero pedir uma Mudança para um simples reboot de um servidor? Isto não seria muito burocrático?

Normalmente o que julgo coerente de ser utilizado, é o seguinte:

  • Mudanças padrão para toda e qualquer intervenção mais cotidiana, com riscos conhecidos, desde que esta classificação esteja alinhada com o cliente.
  • Mudanças emergenciais podendo ser registradas posteriormente à sua execução, desde que previamente aprovadas, seja por membros do gerenciamento de mudanças ou por quaisquer convenções adotadas pela companhia.

No caso de um incidente grave, haveria de ser estabelecido um comitê emergencial, para avaliar a mudança antes de qualquer intervenção no ambiente.Tal comitê é conhecido como Emergency Change Advisory Board (ECAB) ou Comitê Consultivo de Mudança emergencial (CCME).

CCME – “Um subgrupo do comitê consultivo de mudança que toma decisões sobre mudanças emergenciais. Os membros podem ser nomeados no momento da convocação da reunião e depende da natureza da mudança emergencial.”

É necessário se avaliar as atuais características de seu Comitê Consultivo de Mudança Emergenciais (CCME).

Uma das características deste comitê, pode ser a execução de uma avaliação de impacto / negócio por conferência telefônica (ou ainda quaisquer outros meios de comunicação disponíveis). Esta conferência visa propiciar a integração de um time multidisciplinar para que a avaliação da mudança seja possível.

É dever do comitê, com o apoio do gerente de mudança ou um de seus delegados, avaliar, aprovar e autorizar a execução da referida intervenção no ambiente. Conforme dito anteriormente, pode-se convencionar, mesmo durante esta reunião, que o registro da mudança seja feito posteriormente. No entanto, é imprescindível que exista previamente a aprovação deste comitê, para que a informação possa ser devidamente comunicada a todas as partes interessadas, bem como, no futuro, os registros da configuração sejam mantidos atualizados e precisos.

Desta forma, teríamos uma ideia do que seria executado no ambiente (mesmo não tendo ainda o registro em quaisquer mídias).

Outra sugestão interessante, que também pode auxiliar na rastreabilidade quando da confecção do registro, é a gravação desta conferência e armazenamento na forma de áudio-ata. Isto ajuda, pelo menos a:

  • Garantir a consulta do que fora discutido no CCM-E;
  • Dirimir eventuais dúvidas;
  • Solucionar discussões futuras;
  • Servir de insumo para a melhoria contínua do serviço e do processo.

Outro ponto muito importante que a meu ver pode auxiliá-lo, seria o controle de KPIs apropriados para o uso de mudanças emergenciais. É comum atualmente (e infelizmente), mudanças serem categorizadas e gerenciadas como emergenciais, simplesmente devido à falta de priorização do tema. Neste caso, o comprometimento da alta gestão é imprescindível.

Se os sistemas são críticos e têm mudanças emergenciais constantes, às vezes pode ser necessário o registro de um problema pró-ativo para mitigar esta recorrência.

Por outro lado, pode-se também alinhar com o cliente os tempos mínimos necessários para aprovação deste tipo de mudança (respeitando é claro, intervenções realmente emergenciais que, de fato, não possam aguardar o próximo comitê planejado).

O que normalmente deixa o cliente insatisfeito é a falta de controle. Com as boas práticas atuais, pode-se contornar isso de várias formas. De qualquer maneira, é importante analisar o contexto em que você esteja inserido (política, cultura organizacional, restrições), para se tomar uma decisão mais acertada (e negociada).

Acredito que o mesmo (ou algo parecido) ocorra nas empresas onde trabalham.

Gostaria de ouvir de vocês o que acham do artigo acima. Para tanto, abro aqui a discussão.

Carlos F Ferreira, ITIL Expert

Carlos F Ferreira, ITIL Expert

2 comentários em: “O que define a necessidade de uma Mudança?

  1. O tema realmente é muito questionado pela maioria dos clientes que desejam implementar melhores práticas na GSTI. Vivemos atualmente uma situação em um cliente que cabe aqui compartilhar para fomentar o assunto:
    Atualmente passamos por um cenário onde o cliente quer “evoluir” as análises das mudanças do parque tecnológico, onde possui muitos sistemas críticos sensíveis e com alta velocidade de insatisfação do cliente final em caso de eventuais indisponibilidades. Diante disto, o cliente passou a exigir que as Mudanças Emergenciais apresentassem um planejamento no CCM-E, pois ele julga que ao menos uma idéia do que vai ser executado deve ser apresentado aos executivos do negócio visando avaliação de eventuais impactos correlacionados. Nosso posicionamento é similiar ao apresentado acima, ou seja, Mudanças Emergenciais poderiam ser executadas para restaurar as operações normais de serviço (caso onde estão relacionadas a paradas do ambiente) ou visando melhora na performance iminente no parque tecnológico (também relacionado a uma necessidade do negócio) e posteriormente documentada.
    A discussão ainda se estende, gostaria de saber o que acham também do cenário acima, visando primordialmente atender o negócio e as expectativas do cliente, alinhado com as melhores práticas ITIL.

    1. Bom dia Jefferson. Realmente o assunto é bem polêmico. Minha opinião é que neste caso, primeiramente é necessário se avaliar as atuais características de seu Comitê Consultivo de Mudanças Emergenciais (CCM-E).

      Uma das características deste comitê, pode ser a execução de uma avaliação de impacto / negócio por conferência telefônica (ou ainda quaisquer outros meios de comunicação disponíveis). Esta conferência visa propiciar a integração de um time multidisciplinar para que a avaliação da mudança seja possível.

      Desta forma, teríamos uma ideia do que seria executado no ambiente (mesmo não tendo ainda o registro em quaisquer mídias).

      Outra sugestão interessante, que também pode auxiliar na rastreabilidade quando da confecção do registro, é a gravação desta conferência e armazenamento na forma de áudio-ata. Isto ajuda, pelo menos a:
      Garantir a consulta do que fora discutido no CCM-E;
      Dirimir eventuais dúvidas;
      Solucionar discussões futuras;
      Servir de insumo para a melhoria contínua do serviço e do processo.

      Outro ponto muito importante que a meu ver pode auxiliá-lo, seria o controle de KPIs apropriados para o uso de mudanças emergenciais. É comum atualmente (e infelizmente), mudanças serem categorizadas e gerenciadas como emergenciais, simplesmente devido à falta de priorização do tema. Neste caso, o comprometimento da alta gestão é imprescindível.

      Se os sistemas são críticos e têm mudanças emergenciais constantes, às vezes pode ser necessário o registro de um problema pró-ativo para mitigar esta recorrência.

      Por outro lado, pode-se também alinhar com o cliente os tempos mínimos necessários para aprovação deste tipo de mudança (respeitando é claro, intervenções realmente emergenciais que, de fato, não possam aguardar o próximo comitê planejado).

      O que normalmente deixa o cliente insatisfeito é a falta de controle. Com as boas práticas atuais, pode-se contornar isso de várias formas. De qualquer maneira, é importante analisar o contexto em que você esteja inserido (política, cultura organizacional, restrições), para se tomar uma decisão mais acertada (e negociada).

      Espero ter ajudado.

Comentários estão desabilitados no momento.