Gerenciamento de mudanças de TI: Exemplos de mudanças normais da vida real

Onboarding process examples

O que há dentro do vídeo

 

Baixe uma cópia grátis da apresentação

 

Ao clicar em 'Obter PDF agora!', você concorda com o processamento de dados pessoais de acordo com a Política de Privacidade.

Transcrição de vídeo

Uma abordagem estruturada para implementar uma grande mudança de maneira efetiva

ITSM normal change examples

Agora, vamos passar para a segunda metade do nosso webinar, que aborda como construir uma abordagem estruturada para implementar uma grande mudança de maneira efetiva. Dessa forma, as organizações muitas vezes realizam grandes mudanças para fazer melhorias significativas nos seus produtos e serviços, mas é necessário muito planejamento, uma vez que é preciso trazer as partes interessadas certas para o processo e garantir que você esteja preparado para todos os tipos de contingências. Além disso, seus usuários finais devem aceitar a mudança. Caso contrário, a mudança poderá acabar prejudicando mais a organização do que alcançando os benefícios pretendidos. Então vamos ver isso, como você pode implementar uma mudança bem-sucedida com um cenário da vida real.

Estudo de caso: Como implementar uma mudança de maneira eficaz e ajudar sua empresa a adotá-la?

Normal IT change examples

Portanto, temos aqui esta PME que decidiu migrar sua infraestrutura local para a nuvem pelas vantagens óbvias de velocidade, confiabilidade e segurança.

Best example of a normal IT change

Então é isso que ela tem inicialmente.

ITSM normal change implementation process

A empresa tem seu Active Directory, seu ADFS, muitas aplicações, dados e servidores de email do Exchange armazenados no local. E é isso que ela pretende alcançar. A empresa decide fazer a transição para um Azure Active Directory e usar o Office 365 com suas aplicações SaaS. No entanto, como você pode ver, esta é uma tarefa muito grande pois envolve a movimentação de várias aplicações e muitas pessoas e dados. Porém, infelizmente, quando se trata de implementar mudanças tão importantes, a maioria das organizações adota esta abordagem,

Whose approval is required in normal change request

"Feche seus olhos e espere pelo melhor”. Dessa forma, o que as organizações fazem é simplesmente ficar às cegas, sem qualquer tipo de planejamento para diferentes contingências, com uma atitude de “just do it”.

Bem, este pode ser um slogan sofisticado para a Nike, mas não será suficiente se você deseja uma implementação bem-sucedida, pois se fizer isso, todas as coisas simplesmente desmoronarão.

ITSM normal change template

Começando com o fato de que você teria que acabar enfrentando diferentes tipos de mudanças com o mesmo processo de mudança, pois a abordagem única não ajuda neste caso e gera contratempos inesperados, como interrupções não planejadas e falta de recursos. E como essas interrupções não foram previstas antecipadamente, a falha em comunicá-las gera oposição entre os usuários finais. Além disso, a falta de um mecanismo de aprovação apenas aumenta o atraso no ciclo de vida da mudança.

ITSM normal change process flow diagram

E, novamente, venho enfatizando como o planejamento é fundamental para uma implementação bem-sucedida, correto? E em caso de falha na implementação da mudança, e digamos que você não tenha um plano de reversão, isso leva à perda de dados e ao caos total. Dessa forma, todos estes diferentes obstáculos criam pouca visibilidade e uma incapacidade de acompanhar a implementação da mudança ao seu encerramento bem-sucedido. Você iniciou esta grande mudança apenas para melhorar seus serviços e criou uma catástrofe.

A PME adota a mudança com o ServiceDesk Plus

ITSM normal change best practices

Porém, felizmente para esta PME, ela adota esta mudança com o ServiceDesk Plus, e isso permitiu que ela seguisse na direção correta acompanhando esse fluxo de trabalho de melhores práticas.

ITSM normal change process flow

Então, eles começaram definindo os vários tipos de mudanças com os quais iriam lidar. Em seguida, eles criaram diferentes tipos de mudanças, construíram fluxos de trabalho de mudanças sobre eles e definiram esses fluxos de trabalho dividindo-os em seis etapas personalizadas.

Stages of normal IT change

Assim, após dividi-lo em partes menores, torna-se muito fácil, porque eles criam planos detalhados de implementação de impacto, comunicam o tempo de inatividade de maneira eficaz aos usuários finais e realizam a implementação com muito cuidado. E, finalmente, realizam uma revisão pós-implementação e melhorias contínuas nos serviços, analisando as métricas de mudança. Agora, isso pode parecer muito, mas vamos ver como a implementação é simples em uma ferramenta de service desk.

Então, novamente, voltamos ao portal do técnico, e permita-me avançar para as ações rápidas aqui. Clique em Mudança e crie um ticket de mudança. Então, o que você está vendo agora é um formulário da web similar ao que vimos em solicitações de serviço, mas com pequenas diferenças. Portanto, você tem este minicalendário do seu lado esquerdo, que mostra o número de mudanças que estão sendo agendadas. Como você pode ver, nenhuma outra mudança está agendada, o que ajuda a evitar colisões de mudanças. E como pode observar, alguns campos que são diferentes aqui são seus tipos de mudança.

Então, voltei a falar sobre como essa PME definiu diferentes tipos de mudanças, certo? Bem, todos eles são transportados para cá, como documentado, emergencial, principal, normal, padrão, e criaram diferentes fluxos de trabalho para lidar com esses diferentes tipos de mudanças. E aqui temos a solicitação de mudança ou o responsável por ela. Temos o início programado, os serviços afetados e o motivo da mudança.

Rolando para baixo, vemos que existe algo conhecido como funções. Então, quais são essas funções? As funções de mudança no ServiceDesk Plus ajuda-o a definir permissões de acesso para as diferentes partes interessadas envolvidas na implementação da sua mudança. Por exemplo, o implementador aqui conseguiria acessar a solicitação de mudança e modificá-la apenas durante a fase de implementação. Portanto, isso o ajuda a definir “silos” dentro dos quais as partes interessadas vão atuar, garantindo que nenhuma atividade não autorizada ocorra no seu ticket de mudança. Assim que preenchermos todos esses campos distintos, criaremos essa solicitação de mudança.

Portanto, mostrei como uma solicitação de mudança é realmente criada. Deixe-me apresentar rapidamente como é um fluxo de trabalho de mudança. Então aqui temos o nosso fluxo de trabalho de mudança. Permita-me clicar no fluxo de trabalho de emergência. Então, como você pode ver, temos diferentes etapas de mudança divididas em seis estágios, e com base nas ações realizadas no ticket de mudança dentro desses estágios, determinas transições ocorreriam.

Por exemplo, se o ticket de mudança for aceito na fase de envio, ele passará para a fase de implementação. Isso porque esta é uma mudança emergencial. E nesse processo, você poderá notificar funções de mudança específicas, como aprovador de mudanças e seu gerente de mudanças. Portanto, esses fluxos de trabalho garantem a criação de fluxos de trabalho distintos e exclusivos para cada tipo diferente de mudanças.

gora, vamos voltar ao nosso fluxo de trabalho que representa as melhores práticas. Como você pode ver, fizemos com que a PME criasse diferentes tipos de mudança, diferentes funções de mudança, e diferentes fluxos de trabalho de mudança. Ela reuniu todos esses blocos de construção com um modelo de mudança. Agora, tudo o que resta é dividir o processo de mudança em seis etapas e executar os planos detalhados de implementação de impacto. Deixe-me levá-lo ao ticket de mudança real criado por esta PME.

Aqui vamos nós. Como você pode ver, é assim que um ticket de mudança seria refletido após ser criado. Temos seis etapas diferentes, começando com o envio e terminando com o fechamento. Dessa forma, na fase de envio, o solicitante da mudança forneceria um motivo sólido para ela e poderia prosseguir e criar anexos e apresentar um motivo detalhado. Rolando a tela para baixo, vemos alguns detalhes da mudança e as funções associadas a esse ticket de mudança. Assim, uma vez que etapa de envio for preenchida, o aprovador da mudança dará seu consentimento para essa solicitação. Feito isso, o ticket de mudança passa para a fase de planejamento.

Portanto, é aqui que uma avaliação de impacto detalhada é realizada, seus planos de implementação são definidos e seus planos regressivos são definidos. Dessa forma, na fase de impacto, o impacto detalhado nos diferentes serviços críticos é exibido aqui. O plano de implementação descreve a implementação detalhadamente. E no caso de qualquer circunstância imprevista que leve a uma falha na implementação da mudança, você tem seu plano regressivo.

A lista de verificação de implementação ajuda a equipe de mudanças a garantir que não perca nenhum item essencial necessário para a mudança. E todo esse planejamento oferece algumas dicas sobre quais serviços ficarão inativos e você pode criar tempos de inatividade apropriados. Dessa forma, após criar esses tempos de inatividade, você também vai comunicá-los aos usuários finais a partir deste ticket de mudança. Assim, clicamos nas ações na parte superior e podemos optar por fazer um anúncio dentro do ticket de mudança e enviar notificações para partes interessadas específicas.

Agora, uma vez que o planejamento detalhado foi feito, o ticket de mudança passa por um processo de aprovação. Dessa maneira, na fase de aprovação, o seu conselho consultivo de mudanças se reúne e você pode adicionar diferentes conselhos similares e diferentes membros do CAB e garantir que eles se reúnam e revisem o planejamento. Após eles se reunirem e realizarem o planejamento, ficam realmente satisfeitos com o planejamento, seguem em frente e aprovam o ticket de mudança. Depois de fazer isso, eles mudam o status do ticket para a fase de implementação.

Então, como vocês podem ver, na fase de implementação temos projetos, tarefas e cargas de trabalho, além de agendamento do tempo de inatividade. Então, por que projetos? Se esta fosse uma pequena mudança, teríamos definido apenas as tarefas e registrado as cargas de trabalho. Porém, este é, como vimos anteriormente, um projeto o muito grande, que envolve muitas tarefas e técnicos diferentes. Dessa maneira, o que fazemos é criar projetos para acompanhar o progresso da implementação com eficiência. Para isso, definimos diferentes marcos e tarefas associadas a eles. Como você pode ver, são muitas tarefas. Portanto, você não pode gerenciá-las de maneira eficaz no ticket de mudança. Então você usa a forte integração com o módulo de gerenciamento de projetos.

Você pode trazer todos os diferentes membros. Essa é uma lista muito grande, como você pode ver. Assim, você pode reunir todos esses membros no projeto. O gráfico de Gantt ajuda-o a acompanhar a implementação das tarefas e dos marcos com eficiência. Portanto, você pode ter uma visão panorâmica do que está acontecendo em relação à implementação da mudança. Isso realmente facilita o processo de implementação da mudança e garante que ele prossiga de maneira transparente e seja concluído com sucesso.

Sendo assim, vamos voltar rapidamente ao nosso fluxo de trabalho de melhores práticas e ver até onde chegamos.

Stages of normal IT change

Como você pode ver, criamos um plano detalhado, comunicamos os tempos de inatividade previstos aos usuários finais e implementamos a mudança utilizando um projeto. Agora só falta realizar uma revisão pós-implementação para garantir que essa mudança foi realizada com sucesso. Então, para isso, vamos passar para a fase de revisão.

Portanto, na fase de revisão, adicionaremos nossos comandos relativos à revisão e cuidaremos de qualquer parte que precise ser realizada para esta mudança específica. Assim, uma vez implementada a mudança, passamos para o seu encerramento bem-sucedido. Como você pode ver, não houve absolutamente nenhum risco envolvido ou, permita-me reformular, garantimos que todos os riscos fossem evitados usando a capacidade correta. Assim é fácil fazer melhorias nos seus serviços utilizando uma ferramenta de ITSM adequada. Agora tudo o que resta é analisar a matriz de mudança para aplicar a melhoria contínua do serviço.

O processo de mudanças é eficaz?

Normal change metrics

Portanto, essas são as métricas essenciais que acreditamos que você deve mensurar, como o número de incidentes causados pela sua mudança, porcentagem de interrupções não planejadas e porcentagem de mudanças agrupadas. Isso o ajudará a fornecer um cenário da eficiência da sua estratégia de gerenciamento e se ela foi bem-sucedida ou não.

 
Resources for further reading

Recursos para leitura complementar