Entendendo o processo de gerenciamento de mudanças do ITIL 4 (e como a automação pode aprimorar a TI)

O que é gerenciamento de mudança?

O Gerenciamento de Mudanças do ITIL 4 refere-se a um conjunto de diretrizes estabelecidas pela Fundação ITIL. Essas diretrizes ajudam as organizações a gerenciar mudanças em produtos digitais com atrito mínimo ou riscos.

O ITIL 4 é a quarta revisão dessas diretrizes, sendo a primeira versão publicada em 1989! Ao contrário do ITIL 3, que estabeleceu um conjunto de processos específicos a serem seguidos pelas organizações, o ITIL 4 visa fornecer orientações flexíveis. É importante ressaltar que as organizações podem adotar os processos específicos descritos pelo ITIL 3, mantendo-se totalmente compatíveis com as diretrizes do ITIL 4.

As recomendações de gerenciamento de mudanças do ITIL 4 fornecem principalmente definições específicas para conceitos e funções-chave que ocorrem nas operações de TI. Os conceitos descritos são generalizados para que possam ser aplicados universalmente, independentemente da estrutura real da empresa. A intenção é que as organizações desenvolvam seus próprios processos e práticas tendo em mente a estrutura de gerenciamento de mudanças estabelecida pelo ITIL 4.

Utilizando as recomendações do ITIL 4 em conjunto com análise de previsão de risco de mudança Pode acelerar significativamente a velocidade de lançamento, ao mesmo tempo que orienta as equipes de produto a começarem a implementar mudanças de menor risco no geral. Antecipe-se aos riscos com [nome da ferramenta/tecnologia]. Digital.ai Intelligence.

Por que usar o ITIL 4 para gerenciamento de mudanças?

As mudanças fazem parte das operações diárias de TI, independentemente da categoria em que se enquadrem. Décadas atrás, as mudanças eram relegadas a eventos raros de aplicação de patches ou atualizações de configuração que ocorriam apenas algumas vezes por ano, ou até menos. Mas agora, alguns dos aplicativos, serviços e plataformas mais populares do mundo recebem milhares de atualizações de mudanças em um único ano. O Google, por exemplo, relatou em 2018 que... A empresa fez mais de 3,000 alterações em seus algoritmos de mecanismo de busca somente naquele ano., com uma média de cerca de 9 por dia.

Com tantas mudanças ocorrendo em um ritmo tão acelerado, as organizações de TI precisam de uma maneira estruturada de integrar e implementar essas mudanças para minimizar os riscos de interrupções de serviço. Ao mesmo tempo, os líderes de operações de TI precisam remover quaisquer obstáculos que impeçam a velocidade das mudanças. Atrasos desnecessários ou barreiras de aprovação impedem a cadeia de valor.

Isso apresenta um paradoxo: devemos implementar mudanças em um safe muito mais rápido do que nunca.

O processo de gerenciamento de mudanças do ITIL, recentemente atualizado, busca solucionar esse dilema. O principal objetivo do gerenciamento de mudanças do ITIL 4 é remover todas as barreiras à implementação de mudanças, mantendo o controle eficiente sobre as métricas operacionais e outras metas de gerenciamento de riscos de mudança. Nesse sentido, o ITIL 4 propõe uma estrutura de habilitação de mudanças, em vez de definir rigidamente um conjunto prescritivo de processos de gerenciamento de mudanças.

Ao adotar os ideais do ITIL 4 e personalizá-los para melhor se adequarem ao ambiente organizacional em questão, as equipes de operações de TI podem acelerar o ritmo das mudanças, minimizando ineficiências — e ameaças disruptivas — ao longo do processo.

O ITIL 4 visa tornar o gerenciamento de mudanças menos complexo.

As versões originais do ITIL — a primeira publicada no final da década de 1980 — mapeavam rigidamente processos que poderiam trazer previsibilidade e estrutura às atividades de TI de uma organização. Essa orientação era vital para empresas cujos requisitos de TI eram desconhecidos ou levavam à imprevisibilidade. Era um produto de um mundo pouco familiarizado com tecnologias emergentes, e tanto empresas quanto organizações governamentais ansiavam por esse nível de orientação específica.

No entanto, uma grande mudança nas metodologias de desenvolvimento de software surgiu no início dos anos 2000: o Agile. Com o Agile, a rigidez “cascataOs processos de desenvolvimento foram eliminados. Isso deu às equipes de desenvolvimento individuais mais autonomia e controle sobre seus resultados finais, que puderam ser alcançados em um período de tempo significativamente menor.

A metodologia ágil popularizou a ideia de que aplicativos e plataformas tecnológicas poderiam evoluir continuamente, desde que houvesse esforço para garantir que cada nova mudança agregasse valor aos usuários finais.

Em resposta à ascensão da metodologia Agile (e DevOps Após isso), o ITIL foi forçado a se adaptar. O ITIL v3 baseou-se nos processos de mudança existentes do ITIL e desenvolveu um modelo para implementação contínua de mudanças que muitas organizações seguiram, seguindo os seguintes passos:

1. Criar uma solicitação de alteração (RFC)
2. Revisão do RFC
3. Ter um Conselho Consultivo de Mudanças (CAB) para avaliar e analisar a RFC (Solicitação de Propostas).
4. Autorizar alterações com base na RFC
5. Atualizações do plano
6. Implementação coordenada
7. Deploy/integrar novas alterações
8. Revise as alterações e feche o registro de alterações.

Essa versão do processo de gerenciamento de mudanças do ITIL era confiável, repetível e exercia um alto grau de controle sobre o resultado das propostas de mudança. No entanto, para algumas organizações, ainda era bastante complexa.

A necessidade de revisão constante pelo CAB atrasa as mudanças e pode introduzir ineficiências significativas. Como resultado, o valor gerado por cada mudança individual fica comprometido.

Em resposta a essas deficiências, a nova estrutura ITIL 4 sugeriu que o modelo rígido de mudança “proposta > aprovação > implementação > encerramento” fosse reservado para certas mudanças consideradas não padronizadas. Assim, embora a estrutura ITIL 4 preserve espaço para um processo de gerenciamento de mudanças “normal”, familiar das versões anteriores, ela incentiva os líderes de operações de TI a migrar o máximo possível de mudanças para uma categoria diferente: mudanças padronizadas.

Acelerar a velocidade de mudança usando os modelos de mudança padrão do ITIL

O ITIL v3 possuía uma categoria de mudanças propostas descritas como “mudanças padrão”. Estas eram consideradas de baixo risco e ocorreriam com frequência no ambiente de TI em questão. Exemplos oferecidos Isso incluiu alterações de senha, procedimentos para novos funcionários e a realocação de equipamentos físicos.

Com o ITIL 4, os líderes de ITSM reconhecem que as organizações podem almejar que as mudanças padronizadas se tornem a norma, e não uma exceção especial às "mudanças normais". A proposta é que, ao modelar categorias de mudanças ou tipos específicos de mudanças, a formalização do controle de acesso e a aprovação do CAB (Conselho Consultivo de Mudanças) não sejam mais necessárias em muitos contextos.

Identificar quais mudanças são de fato “normais” (ou seja, de “baixo risco”) pode, portanto, eliminar a maioria dos gargalos que impedem a agilidade. Quando mudanças de maior risco são introduzidas no processo formal de RFC (Solicitação de Mudança), os líderes de operações de TI também podem começar a trabalhar para aceitar, mitigar ou rejeitar o risco.

O processo de implementação de uma alteração comum agora pode ser amplamente automatizado, o que significa que, assim que a alteração é proposta pela equipe de desenvolvimento (frequentemente em resposta ao feedback de dados da área de operações de TI), ela pode ser testada, integrada e implantada no ambiente de produção e, em seguida, finalizada com pouca ou nenhuma intervenção humana.

Assim, embora as alterações padrão espelhem o processo normal de alteração, a RFC é revisada e autorizada por meio de um processo de baixa latência, em vez de uma revisão formal do CAB.

Adaptar o processo de gestão de mudanças do ITIL para acelerar as mudanças e, ao mesmo tempo, gerenciar os riscos.

Cada etapa do processo original de gerenciamento de mudanças do ITIL 3 pode ser preservada, em essência, sem sacrificar a velocidade ou a flexibilidade.

Propostas sugeridas pela estrutura atualizada do ITIL 4 Adaptar o processo de gestão de mudanças de uma organização inclui:

• Criando modelos de mudança para mudanças recorrentes.
• Descentralizar a aprovação de alterações para mudanças padrão.
• Dividir mudanças maiores em partes menores que apresentem menos riscos.
• Utilizando verificações, testes e implantação automatizados.

Eis como as adaptações podem ser refletidas em referência a cada etapa de um processo de gerenciamento de mudanças ITIL mais formal:

Pedido de alteração

As alterações "normais" propostas individualmente devem ser consideradas primeiramente em relação a um modelo de alteração padrão para verificar se a alteração pode, de fato, evitar o processo de aprovação. Alterações de "baixo risco" e que envolvam algumas características de alterações pré-modeladas podem ser divididas, de modo que apenas a proposta inovadora seja formalmente considerada, enquanto os componentes padrão sejam pré-autorizados.

Quando possível, as RFCs podem ser geradas automaticamente em resposta direta à necessidade de alteração, com base no feedback de dados das operações de TI. As RFCs geradas automaticamente podem então ser incorporadas ao portfólio de mudanças/funcionalidades proposto. A geração automática de RFCs reduz a necessidade de mudanças emergenciais, pois identifica proativamente os riscos e busca mitigá-los, preferencialmente seguindo o mais fielmente possível as mudanças padrão pré-modeladas.

Avaliação de mudanças
De acordo com o ITIL 4, as reuniões do CAB devem ser convocadas para tratar de circunstâncias especiais, em vez de serem agendadas em uma cadência predefinida ou como parte do procedimento padrão de mudança. Um único gestor de mudanças geralmente é suficiente para avaliar o risco ou o impacto de uma mudança, quando seu julgamento é complementado por outras avaliações. Análise com tecnologia de IAAs alterações padrão podem ser avaliadas, em sua maior parte ou totalmente, por meio de um processo automatizado, evitando o acúmulo de considerações e reduzindo significativamente a latência. Alterações comuns que exigem aprovação formal podem servir de base para um novo modelo de alteração padrão ou podem ajudar a atualizar modelos de alteração padrão existentes para abranger um escopo mais amplo.

Alterar autorização
Um dos principais objetivos da estrutura de habilitação de mudanças com foco em agilidade do ITIL 4 é reduzir ao máximo a necessidade de autorizações de mudança. A modelagem de mudanças permite que a autorização seja instantânea na maioria dos casos, e a utilização de análises para avaliar riscos de mudança Pode tornar a autorização de alterações normais guiada por humanos menos complexa e menos dependente de pesquisa.

Mudanças de plano
O agendamento de alterações e a autorização de builds podem ser drasticamente simplificados com o uso de análises de mudanças, chegando quase à automação completa. O agendamento manual e o planejamento de builds de mudanças devem ser reduzidos ao máximo. Novamente, a modelagem de mudanças pode eliminar a incerteza, isolando as mudanças que exigem atenção especial daquelas que podem ser planejadas e incorporadas rapidamente em uma futura versão de implantação.

DeployIntegrar novas alterações
Graças a Release Ferramentas de gerenciamentoA implementação e integração de mudanças foram amplamente automatizadas em muitas empresas. Mudanças "normais" de baixo risco devem ser priorizadas, o que significa que a maioria das mudanças não deve exigir implementação ou integração manual. Aquelas que exigem atenção podem ser monitoradas após a implementação, reduzindo a necessidade de supervisão humana direta para um pequeno subconjunto de mudanças de risco.

Revise as alterações e feche o registro de alterações.
A importância de fechamentos de mudanças abrangentes não deve ser negligenciada. Eles comprovadamente reduzem problemas e interrupções imprevistas. No entanto, esse princípio não significa que as organizações de TI precisem introduzir processos manuais de revisão complexos para garantir que cada mudança seja estável e esteja refletida com precisão na documentação necessária.

O encerramento de mudanças é uma das etapas do processo de gestão de mudanças mais propícias à automação, mesmo em organizações menores. Testes e revisões automatizados Desempenham um papel de "garantia de qualidade", enquanto as atualizações automatizadas do CMDB e outras tarefas de fechamento de alterações reduzem a necessidade de fechamento manual de alterações. Essas práticas garantem registros mais completos e reduzem o risco de que erros organizacionais possam afetar a integridade dos dados do CMDB e de outros sistemas de registro importantes.

Acelere a implementação de mudanças com a análise de TI em cada etapa do processo.

Os seres humanos são criativos e podem ser excelentes solucionadores de problemas, mas não são tão qualificados quanto os computadores para revisar rapidamente milhares de linhas de código ou milhões de entradas de dados. A análise de dados oferece essa funcionalidade e pode aumentar drasticamente a produtividade de TI, além de adicionar agilidade ao processo de revisão e implementação de mudanças.
A adição de modelos de IA e ML aprimora ainda mais as capacidades de TI, descobrindo automaticamente padrões nos dados que o olho humano pode não ser capaz de enxergar, como fatores de risco de mudança ou a probabilidade de uma determinada mudança produzir um efeito disruptivo no desempenho.

Essas funcionalidades ilustram o papel vital que a tecnologia desempenha em nos ajudar a gerenciar a tecnologia que criamos e modificamos diariamente. Embora a automação de mudanças não seja inerentemente necessária às práticas modernas de gerenciamento de mudanças, as diretrizes do ITIL a consideram uma prática recomendada, vital em um mundo onde a velocidade pode ser medida em milissegundos, e não em meses.