Change enablement
Processo end-to-end com workflow, actividades, RACI e métricas
Descarregar pack completoÂmbito e objectivos
Maximizar o número de mudanças bem-sucedidas, garantindo que os riscos são avaliados adequadamente, autorizando as mudanças e gerindo o calendário de mudanças.
Submissão de um pedido de mudança (RFC) por qualquer área da organização com necessidade de alteração ao ambiente de produção.
Desde a submissão do RFC até à revisão pós-implementação. Cobre mudanças standard, normais e de emergência em todos os serviços e componentes de infraestrutura.
Execução técnica da mudança (responsabilidade da equipa técnica). Gestão de releases e deployments (processo separado).
Mudança autorizada, implementada e revista. Calendário de mudanças actualizado. RFC encerrado com resultado documentado e lições aprendidas registadas.
Tipos de mudança
O ITIL distingue três tipos de mudança com fluxos de autorização distintos, calibrados em função do risco e urgência. A correcta classificação é determinada pelo change manager no momento do registo do RFC.
Pré-autorizada, de baixo risco e com procedimento documentado e aprovado. Não requer aprovação do CAB nem avaliação individual de risco. É executada seguindo o modelo definido.
Ex.: reset de password, instalação de software aprovado, criação de conta de utilizador.
Segue o fluxo completo de avaliação: submissão de RFC, análise de impacto e risco pelo change manager, aprovação pelo CAB e implementação agendada.
Ex.: upgrade de sistema operativo, alteração de configuração de firewall, migração de base de dados.
Urgente, necessária para resolver um incidente crítico ou responder a uma ameaça imediata. A autorização é acelerada pelo ECAB (Emergency CAB) e a documentação completa é realizada após a implementação.
Ex.: aplicação de patch de segurança crítico, rollback de deploy com impacto em produção.
Diagrama do processo
Diagrama BPMN simplificado do processo de change enablement (4 swimlanes). O caminho standard ignora o CAB. Percorra horizontalmente em dispositivos móveis.
Actividades macro
| # | Actividade | Responsável | Input | Output |
|---|---|---|---|---|
| 1 | Submissão do RFC | Iniciador da mudança | Necessidade de alteração | RFC submetido |
| 2 | Registo e classificação | Change manager | RFC submetido | RFC classificado (standard/normal/emergência) |
| 3 | Avaliação de impacto e risco | Change manager | RFC classificado | Análise de impacto e risco documentada |
| 4 | Autorização (CAB/ECAB) | CAB ou ECAB | Análise de impacto e risco | Mudança autorizada ou rejeitada |
| 5 | Planeamento da implementação | Equipa técnica / Change manager | Mudança autorizada | Plano de implementação e rollback |
| 6 | Comunicação e agendamento | Change manager | Plano aprovado | Calendário de mudanças actualizado, stakeholders notificados |
| 7 | Implementação | Equipa técnica | Plano de implementação | Mudança implementada |
| 8 | Teste e validação | Equipa técnica | Mudança implementada | Resultado dos testes documentado |
| 9 | Revisão pós-implementação (PIR) | Change manager | Resultado da implementação | Relatório de PIR, lições aprendidas |
| 10 | Encerramento | Change manager | PIR concluída | RFC encerrado, calendário actualizado |
Descrição detalhada das actividades
Qualquer colaborador ou equipa pode submeter um RFC quando identifica a necessidade de alterar um serviço, componente ou processo. O RFC deve conter informação suficiente para permitir a avaliação inicial: descrição da mudança, justificação, impacto esperado e urgência.
Passos chave
- Descrever claramente o que se pretende alterar e porquê
- Indicar o serviço ou componente afectado
- Estimar o impacto no negócio e nos utilizadores
- Propor data ou janela de implementação pretendida
- Anexar documentação de suporte (especificações, testes prévios)
O change manager analisa o RFC submetido e determina o tipo de mudança. A classificação correcta define o fluxo de aprovação a seguir e os recursos necessários. Uma classificação errada pode resultar em mudanças de alto risco sem autorização adequada ou em atrasos desnecessários para mudanças simples.
Passos chave
- Verificar se a mudança cumpre os critérios de um modelo standard existente
- Avaliar o risco intrínseco e o impacto potencial
- Classificar como standard, normal ou emergência
- Atribuir prioridade ao RFC
- Notificar o iniciador da classificação atribuída
Para mudanças normais, o change manager realiza uma análise detalhada de impacto, consultando a CMDB para identificar dependências e o service owner para avaliar o impacto no negócio. Esta análise fundamenta a decisão do CAB.
Passos chave
- Consultar a CMDB para mapear CIs afectados e suas dependências
- Identificar serviços relacionados que possam ser impactados
- Estimar probabilidade de falha e impacto se falhar
- Definir plano de rollback em caso de falha
- Propor janela de implementação com menor impacto
- Documentar os resultados na análise de impacto
O CAB (Change Advisory Board) reúne periodicamente para rever os RFCs pendentes e tomar decisões de autorização. O ECAB actua de forma ágil para mudanças de emergência. O CAB inclui representantes das áreas técnicas, negócio e gestão de serviços.
Passos chave
- Apresentar o RFC com análise de impacto ao CAB
- Discutir riscos, alternativas e janela proposta
- Votar: autorizar, rejeitar ou devolver para revisão
- Registar a decisão na acta da reunião
- Para emergências: convocar ECAB por email/telefone e obter autorização acelerada
Após autorização, a equipa técnica elabora o plano detalhado de implementação, incluindo passos sequenciais, responsabilidades, critérios de sucesso e procedimento de rollback. Um bom plano reduz significativamente o risco de falha durante a janela de implementação.
Passos chave
- Definir todos os passos técnicos de implementação em sequência
- Estimar duração de cada passo e duração total
- Confirmar disponibilidade dos recursos e acessos necessários
- Documentar critérios de sucesso (go/no-go)
- Detalhar procedimento de rollback com pontos de decisão
O change manager actualiza o calendário de mudanças (Forward Schedule of Changes) e notifica todos os stakeholders afectados. Uma comunicação atempada permite que utilizadores e negócio se preparem para possíveis interrupções de serviço.
Passos chave
- Registar a mudança no calendário de mudanças com data e janela
- Verificar conflitos com outras mudanças ou eventos de negócio
- Enviar notificação aos utilizadores afectados com antecedência adequada
- Confirmar disponibilidade da equipa técnica na janela definida
A equipa técnica executa o plano de implementação durante a janela aprovada. Qualquer desvio significativo ao plano deve ser comunicado de imediato ao change manager, que decide se continua ou activa o rollback.
Passos chave
- Confirmar pré-requisitos antes de iniciar (go/no-go check)
- Executar cada passo do plano e registar resultado
- Monitorizar o ambiente durante e após a implementação
- Comunicar desvios ao change manager em tempo real
- Activar rollback se os critérios de falha forem atingidos
Após a implementação, a equipa técnica executa testes para confirmar que o serviço funciona conforme esperado e que a mudança não introduziu problemas inesperados. O service owner valida o impacto no negócio.
Passos chave
- Executar testes funcionais definidos no plano
- Verificar que serviços dependentes continuam a funcionar
- Confirmar que os critérios de sucesso foram atingidos
- Documentar resultados dos testes no RFC
- Notificar o change manager para verificação
A revisão pós-implementação avalia se a mudança atingiu os objectivos, identifica lições aprendidas e documenta problemas que possam ter surgido. Para mudanças de maior impacto, a PIR é realizada em reunião formal; para mudanças standard, pode ser feita de forma simplificada.
Passos chave
- Confirmar que os objectivos da mudança foram alcançados
- Verificar se surgiram incidentes relacionados com a mudança
- Documentar o que correu bem e o que pode ser melhorado
- Registar lições aprendidas para futuras mudanças semelhantes
- Atualizar o modelo standard se aplicável
O change manager encerra formalmente o RFC, actualizando o estado e garantindo que toda a documentação está completa. O calendário de mudanças é actualizado e os registos de configuração na CMDB reflectem o novo estado do ambiente.
Passos chave
- Verificar que toda a documentação está completa no RFC
- Actualizar o estado do RFC para "encerrado"
- Garantir que a CMDB reflecte as alterações efectuadas
- Actualizar o calendário de mudanças
- Notificar o iniciador do encerramento
Modelo RACI
| Actividade | Iniciador (IN) |
Change manager (CM) |
CAB (CAB) |
Eq. técnica (ET) |
Service owner (SO) |
|---|---|---|---|---|---|
| Submissão RFC | R | A | - | - | - |
| Registo e classificação | R | A | - | - | I |
| Avaliação impacto e risco | R | A | - | C | I |
| Autorização | I | A | R | - | C |
| Planeamento | C | A | - | R | I |
| Comunicação e agendamento | R | A | I | I | I |
| Implementação | I | A | - | R | I |
| Teste e validação | - | A | - | R | C |
| Revisão pós-implementação | R | A | I | C | I |
| Encerramento | R | A | - | - | I |
Métricas e KPIs
| Métrica | Descrição | Target sugerido |
|---|---|---|
| Taxa de sucesso | Percentagem de mudanças implementadas sem incidentes associados | > 95% |
| Mudanças de emergência | Percentagem de mudanças classificadas como emergência em relação ao total | < 10% |
| Lead time | Tempo médio desde a submissão do RFC até à implementação | < 5 dias (normal) < 2h (emergência) |
| Mudanças falhadas | Percentagem de mudanças que necessitaram de rollback ou causaram incidentes | < 5% |
| Backlog de RFCs | Número de RFCs pendentes de autorização aguardando decisão do CAB | Tendência decrescente |
| Cumprimento do calendário | Percentagem de mudanças implementadas na data e janela planeadas | > 90% |
| Mudanças não autorizadas | Mudanças detectadas no ambiente sem RFC correspondente | 0 |
| Disponibilidade do CAB | Percentagem de reuniões CAB realizadas conforme planeado sem cancelamentos | > 95% |
Interfaces com outros processos
Gestão de incidentes
Incidentes causados por mudanças falhadas são reportados; incidentes graves podem gerar RFCs de emergência para correção urgente.
Gestão de problemas
Soluções permanentes identificadas pela gestão de problemas requerem um RFC para implementação formal no ambiente de produção.
Gestão de releases
Mudanças autorizadas alimentam o planeamento de releases; o processo de release gere a entrega coordenada de múltiplas mudanças.
CMDB
A avaliação de impacto consulta as relações entre CIs na CMDB; após a mudança, os registos de configuração são actualizados.
Calendário de mudanças
Todas as mudanças agendadas são visíveis no calendário de mudanças, permitindo coordenação e identificação de conflitos.
Service request management
Pedidos de serviço que requerem alterações ao ambiente são escalados para change enablement como mudanças standard ou normais.
Descarregar o pack completo
Inclui o processo documentado, formulários RFC, acta CAB, revisão pós-implementação, calendário de mudanças, RACI em Excel e métricas.