Olá caro leitor,
o título deste post resume na minha opinião qual o objetivo do processo de gerenciamento de mudanças. Como se diz dentro da TI, a única constante é a mudança . A necessidade de habilitar novas funcionalidades nos sistemas, novos arranjos na #Infraestrutura e projetos que lançam novos produtos requisitam mudanças na infraestrutura, e dada à urgência que estas alterações precisam ser feitas, corre-se um risco enorme de mudanças não corretamente planejadas (e feitas na pressa) gerarem indisponibilidade nos serviços disponibilizados.
O ITIL detalha muito bem o processo para realizar uma mudança, mas este deve ser implementado de acordo com a necessidade da organização. A principal definição a ser feita para começar a implementar o processo é o escopo . A pergunta é: Quais ICs preciso/desejo controlar? A resposta desta pergunta delimita o que deve passar pela gestão de mudança antes de ser alterado. Outras decisões importantes são: definir o dono do processo, o escopo da mudança padrão, normal e emergencial, o comitê de mudança e quem irá conduzir as reuniões.
As atividades comuns neste processo são:
- Abertura da requisição de mudança
- Validação
- Análise
- Aprovação/Rejeição
- Programação
- Execução
- Revisão pós-implementação
Uma mudança não deveria ser aprovada sem um plano de rollback, o famoso plano B.
Uma pergunta que geralmente me fazem é: durante a execução de um projeto, é preciso gerenciar as mudanças na infraestrutura? A minha resposta é: Se há o risco de algum manuseio inadequado gerar riscos para a infraestrutura em produção sim. Caso não gere risco, não é necessário, mas antes de entrar em produção é necessário mapear a configuração dos ICs.
A maior parte dos incidentes na infraestrutura são causadas por alguma mudança. Gerenciar a mudança é proteger o ambiente de produção, gerando valor para o negócio e garantindo a satisfação dos usuários.
Um grande abraço e até a próxima!
