Lições e exemplos de melhores práticas de ITSM:
Revisão da gestão de mudanças em um banco

Ver PDF

(Para baixar, clique com o botão direito do mouse e salve)

Cenário

Um banco de médio porte na Índia decidiu gerenciar suas operações de infraestrutura e desenvolvimento de aplicações implementando o gerenciamento de serviços de TI (ITSM). Dessa forma, a equipe de TI do banco adotou uma abordagem em fases e se concentrou em três processos de ITSM: gerenciamento de incidentes, atendimento de solicitações e gestão de mudanças. Primeiramente, a equipe de TI projetou uma abordagem de melhores práticas com base na estrutura de ITSM para os três processos, treinou outros funcionários, documentou um RACI e uma matriz para os processos e chegou aos indicadores-chave de desempenho (KPIs) acordados para monitorar o desempenho. Em seguida, o banco adquiriu uma ferramenta de gerenciamento de serviços para seguir fluxos de trabalho ou processos baseados nas melhores práticas incorporadas na ferramenta de ITSM.

Nos três meses seguintes, a ferramenta trouxe uma grande diferença para a organização. O chefe de processos e conformidade revisou as métricas e KPIs e indicou que os incidentes e solicitações de serviço foram bem tratados, mas não as solicitações de mudança.

Aqui estão os prints das mudanças registradas no período de três meses

Conforme mostrado na Fig. A, houve poucas mudanças padrão, enquanto as mudanças normais e emergenciais continuaram aumentando. Além disso, houve várias mudanças malsucedidas e a empresa começou a perder a esperança na TI.

A equipe principal adota a abordagem correta de gestão de mudanças

Uma equipe central composta pelo chefe de infraestrutura, chefe de desenvolvimento de aplicações, gerente de mudanças e gerente de service desk foi formada para corrigir a situação. Ela entrevistou as equipes de suporte e desenvolvimento, analisou os dados para entender os motivos das mudanças malsucedidas, realizou uma análise de gaps e sugeriu soluções práticas.

O que causou tantas mudanças malsucedidas?

As equipes de infraestrutura e aplicações estavam sob pressão para melhorar o desempenho, atualizar servidores e reduzir o tempo de resposta de todas as mudanças que passavam para produção. Elas não tinham visibilidade do relacionamento a montante e jusante dos componentes que estavam passando por mudanças. Por exemplo, quando um Exchange Server estava inativo, a equipe de infraestrutura não conseguia localizar as informações na Ferramenta de ITSM. A equipe teve que recorrer a especialistas no assunto (SMEs) ou à equipe do Exchange Server. Além disso, quando os SMEs não estavam disponíveis, a equipe prosseguia com as mudanças usando procedimentos autônomos. Como resultado, as mudanças não foram analisadas e a equipe de revisão de mudanças não pôde prever o seu impacto de maneira conclusiva.

Como a equipe principal abordou isso?

A equipe principal entendeu a necessidade de construir um sistema de gerenciamento de configuração (CMS) para capturar a infraestrutura completa e topologia da aplicação com atributos e relacionamentos.

A equipe listou serviços de negócio críticos e construiu uma estrutura de árvore de serviços incorporando atributos para vários dispositivos, juntamente com os relacionamentos pai e filho associados, conforme mostrado na Fig. D. Ela também identificou a topologia completa e obteve a assinatura dos SMEs de servidor, armazenamento e rede, importando-a para a ferramenta de gerenciamento de serviços.

Além disso, as equipes não tinham visibilidade das mudanças planejadas, programadas e implantadas. Não havia um mecanismo adequado para publicar o cronograma futuro de mudanças ou rastrear as mudanças planejadas e suas datas de lançamento.

O que a equipe principal fez para otimizar o fluxo de trabalho de mudanças e garantir visibilidade?

A equipe principal descobriu que as mudanças eram frequentemente enviadas de última hora, sem tempo suficiente para avaliá-las e executá-las. Isso ocorria devido à falta de disciplina e governança adequadas para abordar o recebimento e execução de mudanças.

Definição de normas e padrões de gestão de mudanças

Para evitar mudanças de última hora, eles comunicaram as implicações, justificativa e impacto comercial aos chefes de negócios e obtiveram aprovação obrigatória nas seguintes condições:

• Todas as mudanças normais devem entrar em produção uma vez a cada 15 dias.
• Todas as mudanças devem ser agrupadas com o lançamento uma vez a cada 15 dias, sem exceção para mudanças normais.
• Todas as solicitações de mudança (RFCs) devem ser enviadas com pelo menos duas semanas de antecedência. Qualquer RFC que for necessária dentro de uma semana será rejeitada com o gerente do solicitante sendo informado.
• Qualquer solicitação para agilizar mudanças normais, mesmo em casos extremos, tinha que passar por três níveis de aprovação da gerência. As aprovações foram rastreadas pela equipe de TI para controlar as mudanças que estavam sendo realizadas.
• Mudanças de emergência só seriam consideradas em dois cenários:
• Para resolver uma inatividade não planejada, grande interrupção ou incidente.
• Uma versão completa não implantada devido a razões inevitáveis.

Definição dos diferentes tipos de mudança

Mudança padrão e mudança normal

Mudanças padrão são aquelas de baixo risco, pré-aprovadas, que acontecem com frequência e têm um tempo de resposta rápido. As mudanças padrão podem ser implementadas rapidamente e ajudam a gerenciar riscos

Exemplos de uma mudança padrão:

• Movimentação de equipamentos de mesa ou autônomos.
• Um patch padrão que é aplicado aos servidores uma vez por mês durante a janela de manutenção acordada

O que é uma mudança padrão?

Quando uma mudança normal é implementada com sucesso algumas vezes, os processos associados, como planejamento, programação e implementação, são estabelecidos e se tornam previsíveis e controlados. Em outras palavras, a mudança torna-se uma tarefa rotineira e, portanto, padrão.

Alguns exemplos de mudanças normais:

• Atualização do Exchange Server ou qualquer outro hardware
• Configuração de alta disponibilidade ou cluster para funções de negócio vitais (VBF)
• Implementação de uma nova versão para enfrentar os problemas reportados

Agilizar ou acelerar as mudanças

Mudanças rápidas são geradas devido a uma necessidade urgente, como uma exigência legal ou comercial. Essas mudanças não estão relacionadas à restauração de um serviço.

Mudança de emergência vs mudança acelerada

O Conselho Consultivo de Mudanças (CAB) definiu regras e regulamentos claros para qualificar mudanças emergenciais e rápidas e comunicou essas regras em toda a organização.

Alterar calendário para obter uma melhor visibilidade

A equipe principal usou o calendário de mudanças na ferramenta de gerenciamento de serviços para reportar manutenções planejadas, mudanças e atualizações, e para garantir melhor visibilidade para as equipes envolvidas.

Definir os Indicadores-chave de Desempenho

Para assimilar a eficiência e eficácia do processo de gestão de mudanças, a equipe principal identificou os seguintes KPIs.

• Número e porcentagem de mudanças com falha para mudanças padrão, normais e de emergência
• Número de incidentes e tempo de inatividade do serviço causados por mudanças normais e emergenciais
• Número ou porcentagem de mudanças não planejadas ou emergenciais
• Tempo médio para implementar mudanças
• Número e porcentagem de mudanças rejeitadas pelo CAB
• Número e porcentagem de mudanças não autorizadas

Os quatro primeiros KPIs foram retirados da ferramenta de gerenciamento de serviços, enquanto o quinto e o sexto exigiram intervenção de especialistas.

Conselho Consultivo de Mudanças garante revisões de mudanças melhores

A equipe principal garantiu que o CAB se reunisse uma vez por semana, às quintas-feiras, entre 19:00 e 21:00, horário local. Representantes das equipes de infraestrutura, aplicações, service desk e gerenciamento de atualizações revisaram todas as mudanças planejadas. No entanto, o gerente de mudanças era a autoridade para decisão final.

O CAB rejeitou as mudanças principalmente devido à não conformidade com as etapas e protocolos esperados de avaliação, revisão e BIA (Análise de Impacto nos Negócios). Os responsáveis pela mudança foram responsabilizados pela falha. A equipe principal foi forçada a adotar medidas rigorosas para evitar essas ocorrências no futuro. As mudanças foram avaliadas em todos os cenários possíveis antes da reunião do CAB.

Lidar com mudanças não autorizadas

Durante a discussão com as partes interessadas, a equipe principal observou que cerca de 20% das mudanças foram concluídas sem autorização, principalmente porque a equipe de infraestrutura estava sob pressão para fazê-las rapidamente. Consequentemente, muitas mudanças foram feitas sem uma solicitação de mudança ou sem passar pelos processos de revisão e aprovação.

Para enfrentar essa situação, foram nomeados gatekeepers de etapas para equipes de infraestrutura, aplicações e banco de dados visando garantir que as etapas não fossem ignoradas quando uma mudança fosse realizada. Eles tinham uma lista de preparação que incluía os resultados dos testes, aprovações, assinaturas de todas as equipes envolvidas e um plano de retirada. Em caso de violação, os gatekeepers da etapa assumiam a responsabilidade que afetava suas medidas de avaliação e desempenho.

Outro motivo para as mudanças não autorizadas foi que as equipes de aplicação atualizaram o CMDB or CMS após o lançamento da atualização.

A equipe principal garantiu que auditorias fossem realizadas semanalmente para comparar a situação atual do CMS com o RFC associado e qualquer desvio fosse destacado ao proprietário do IC e ao proprietário do serviço para ação imediata. Por sua vez, o proprietário do serviço fechou o ciclo e tomou medidas firmes. Esse processo durou de quatro a seis semanas, e a equipe criou o hábito de seguir a regra sem exceções.

Implementação e treinamento de comunicação

Depois que a equipe principal implementou os controles apropriados, o processo de comunicação foi simplificado para que as equipes envolvidas pudessem ser notificadas sobre a nova mudança. Em seguida, os chefes de negócios lançaram o processo de gestão de mudanças formal, que foi seguido por sessões de conscientização e programas de treinamento.

A execução no período de três meses seguinte apresentou melhorias visíveis, conforme mostrado na Fig. F.

Lições aprendidas (CSI)

• A equipe de TI do banco entendeu que construir um sistema de gerenciamento de configuração robusto com informações atualizadas de todos os componentes de TI é fundamental para uma mudança bem-sucedida e processo de gerenciamento de atualizações.
• O cronograma futuro de mudanças, janela de manutenção planejada e planos de atualização são essenciais para gerenciar o volume e duração das mudanças e garantir uma implantação tranquila.
• A aplicação de uma política exige praticidade, diligência e adesão. Havia menos políticas, mas elas eram importantes para o sucesso do processo de gestão de mudanças (por exemplo: CAB, mudanças não autorizadas e PIR).
• KPIs relevantes e práticos ajudam as equipes a se tornarem eficientes e eficazes.
• Processos e ferramentas precisam trabalhar em conjunto e a ausência de um ou de outro afetará severamente a melhoria contínua do serviço (CSI).
• A revisão pós-implementação das principais mudanças e implicações forneceu insights valiosos sobre possíveis áreas para melhorá-las e controlá-las.

Conclusão:

O banco melhorou sua eficiência e eficácia geral do processo de gestão de mudanças garantindo boa governança, implementando alinhamento de processos e ferramentas e oferecendo uma liderança forte.

Este estudo de caso fornece as ferramentas necessárias para estruturar, implementar e executar mudanças organizacionais sem problemas. Caso você tiver uma experiência interessante com o processo de gestão de mudanças, compartilhe-a conosco na seção de comentários.