05 Segredos da Gestão de Mudanças que Não te Contaram em Seu Curso de ITIL Foundation
1) O Nível de Detalhe Adequado Para Registrar Mudanças
O nível de detalhe exigido para o registro de cada mudança irá variar sobretudo proporcionalmente ao tamanho e impacto da mudança.
Não significa que deveremos ignorar completamente outros aspectos e atributos da mudança no momento de decidir o nível de detalhamento até porque atributos como tipo e categoria irão influenciar o próprio impacto. Mas estas duas serão as variáveis fins para definição do modelo que traz o nível de detalhes adequado: tamanho e impacto.
O Registro da Mudança deverá conter todo o histórico do Ciclo de Vida da Mudança , abrangendo também a Requisição de Mudança (RDM) .
A documentação necessária para o registro, assim como as possibilidades de como cadastrá-las são aspectos que devem ser definidos durante o Desenho e Planejamento do próprio Processo de Gestão de Mudanças . Uma vez desenhado, você terá disponível dois instrumentos que cito a seguir.
A Política de Gestão de Mudanças (ou "Políticas", no plural) auxilia definindo diretrizes, regras e o Modelo de Mudança mais adequado para tratar a mudança que está sendo registrada.
Se você está estudando estes detalhes pela primeira vez, espero que tenha dado atenção ao parágrafo anterior, pois os dois "elementos mágicos" para o desempenho adequado de registro e classificação de mudanças acabaram de ser citados: Política(s) e Modelo(s) de Mudanças.
Em vez de investir tempo em reuniões intermináveis a cada novo episódio, que tal dedicar seu esforço para construir Política e Modelos eficazes, consistentes, atualizados? Fazendo isso, você terá em mãos um verdadeiro "framework de Gestão de Mudanças" para escolha adequada de informações à cada mudança.
2) Quando Registrar Cada Informação
Normalmente, quando temos dúvidas neste ponto significa que estamos confundindo os conceitos de Registro de Mudança com Requisição de Mudança .
O Registro da Mudança, é como um Registro de Incidente , que será aberto, atualizado e fechado, passando por todo um ciclo de vida. Requisição é o que o nome diz.
Exemplos de informações cadastradas na RDM são: solicitante, benefícios da mudança e efeito de não implementar a mudança; já o Caso de Negócio (quando aplicável) e/ou Relatório de Avaliação de Impacto provavelmente serão anexados ao Registro da Mudança após o decorrer das primeiras atividades de condução do processo.
Demais informações sobre o andamento podem ser atualizadas dentro do próprio Registro da Mudança, assim como é realizado para qualquer outro registro: de eventos, incidentes ou problemas.
Precisamos tomar cuidado para não sobrecarregar o registro da RDM com atributos a serem preenchidos precocemente , e ao mesmo tempo garantir a atualização das informações ao longo do ciclo de vida da mudança.
3) Considerações Sobre Automação
Cada organização deve escolher os meios pelos quais mudanças serão registradas e gerenciadas de acordo com sua realidade.
Depois desse discurso "chato" das duas linhas anteriores que nunca convence ninguém que está querendo aprender, vamos ao que interessa: para 99% dos casos, uma ferramenta web é a melhor (ou pelo menos mais comum) opção a para conduzir as atividades de um processo que "transborda" relacionamentos como é o caso da Gestão de Mudanças. Isso não significa que você já deva começar com um processo automatizado, mas que provavelmente você vai querer chegar lá.
Os registros de mudança devem ter interface sobretudo com o Sistema de Gerenciamento de Configuração (SGC) e os Registros de Liberação .
Em nível de prioridade, após estas duas, as integrações mais relevantes seriam com a Gestão de Problemas e Incidentes , e logo após com os Processos de Desenho de Serviços .*
*Obs.: o "ideal", conforme as boas práticas da ITIL sugerem, seria que todos estes registros (de incidentes, problemas, IC´s e registros das próprias mudanças) se relacionassem através do Sistema de Gestão de Conhecimento , mas não entrarei neste mérito para não sobrecarregar demais o artigo.
No mais, basta acrescentar que quaisquer outros relacionamentos com outros - quaisquer - processos de Gestão de Serviços de TI seriam úteis, embora menos prioritários.
Antes que eu esqueça de mencionar, não há nada de errado em utilizar instrumentos básicos para conduzir o processo, contanto que se adéquem ao seu cenário: através de e-mail ou Formulários em papel. Na maioria dos casos, é até mais adequado que se inicie assim. Mas, independente do seu cenário, com o passar do tempo, aumentar o nível de automação não o fará mal algum à saúde do seu processo.
Para que seja mantido um histórico, todas as informações da Requisição de Mudança e Registros devem ser atualizadas pelo Sistema de Gerenciamento de Configuração (SGC) para os Itens de Configuração relacionados. Caso esta ação não esteja automatizada, isto deve ser realizado manualmente.
4) Como Tirar Maior Proveito da Automação
No processo de mudanças, você pode usar automações para disparar Ordens de Serviço assim que mudanças são registradas por completo.
Alguns exemplos:
- Uma Ordem de Serviço pode ser emitida para indivíduos ou equipes para que seja realizada uma Avaliação de Impacto .
- Uma Ordem de Serviço é disparada para a equipe de Gestão de Configuração para que seja gerado um relatório com informações sobre Itens de Configuração envolvidos com a Requisição registrada.
Mais uma vez, perceba que as regras precisam estar pré definidas por Políticas e Modelos de Mudança antes que você decida por automatizá-las.
5) Acesso aos Registros de Mudanças
Uma última sugestão é tomar cuidado com o acesso ao registro das mudanças: uma vez que abrangem informações que variam da estratégia a operação, você deve cuidar para que cada profissional acesse apenas o essencial, de acordo com sua função.
Pode parecer uma preocupação secundária para quem está animado para implantar o processo, mas acredite: planejar-se para este aspecto irá reduzir seus riscos com segurança da informação ou no mínimo manter a equipe focada.
Registros de mudanças não documentam apenas informações técnicas, elas documentam absolutamente tudo que ocorre dentro dentro e fora de TI, incluindo o relacionamento com o cliente , fornecedores , dentre outros possíveis stakeholders .
Procedimentos devem especificar os níveis de acesso aos Registros de Mudança e quais papéis devem ter Acesso a estes Registros. Se você está bem estrutura em sua Gestão de Segurança da Informação , então esses documentos irão derivar da Política de Segurança da Informação .
Qualquer pessoa autorizada pode criar uma mudança, sejam estes clientes , profissionais de TI, ou demais partes interessadas. Deve haver regras documentadas para esclarecer estes níveis de autorização de acordo com o Tipo e Categoria de cada Mudança.
Permissões para visualizar e editar mudanças devem ser estabelecidas de modo adequado, igualmente com base em o que dizem as Políticas para cada tipo e categoria de mudança.
Já o fechamento da Mudança deve ser realizado apenas por membros da equipe interna de TI delegada para tal papel dentro do processo (com devido aceite de solicitante(s) / partes interessadas).
Continue estudando Gestão de Mudanças no Portal GSTI:
- Vídeo: Gestão de Mudanças da ITIL na prática
- Os quick wins da Gestão de Mudanças
- Exemplo de um Relatório de Mudanças
- Gerenciamento de Mudanças: você está fazendo isso errado
- Gerenciamento de Mudanças x Gerenciamento de Liberação x Gerenciamento de Configuração
- Modelo de Mudança na Prática
- Requisição de Mudança x Registro de Mudança
- Vídeo: Cloud Computing e Gestão de Mudanças ITIL
Links Externos:
