Plano de gestão de mudanças: corrija a resistência antes que ela comece

Um plano de gestão de mudanças para um programa de ERP define como as pessoas vão passar da forma como trabalham hoje para a forma como o novo sistema exige que trabalhem, e quem é responsável por levá-las até lá. Ele começa na mobilização, não no treinamento. Tem sete partes, cada uma com um responsável nomeado, e fica ligado ao termo de abertura, aos workshops de design e aos quality gates, em vez de correr como uma frente paralela.

A maior parte da resistência não surge do nada. Ela cresce devagar, bem antes do kickoff. Você a ouve em comentários indiretos nas primeiras reuniões. Percebe que líderes de negócio importantes ficam calados. Quando um plano formal de mudança é redigido, boa parte do estrago já está feito.

Quase sempre ela começa em alguns lugares previsíveis:

1. Usuários-chave deixados de fora do design inicial.
2. Gestores de área surpreendidos por impactos que ninguém discutiu com eles.
3. Comunicação vaga, que convida a pôr tudo em dúvida.
4. Projetos fracassados do passado, que deixaram uma desconfiança silenciosa.

São problemas estruturais, não apenas de comunicação. Se o comitê de direção é passivo, espere atrito. Se o termo de abertura do projeto não diz nada sobre adoção, você já perdeu uma alavanca.

1. 01MobilizaçãoMapeie a influência e colete o histórico informal
2. 02DesignDefina os KPIs de adoção, com os power users como coautores
3. 03TestesOs usuários de negócio testam os próprios processos
4. 04TreinamentoPor função, com dados reais, em horários em que as pessoas possam participar
5. 05Gate de go-liveLimites de adoção, não só aprovação funcional
6. 06Primeiros 90 diasAcompanhe logins, erros, chamados e soluções de contorno

Soluções de contorno detectadas antes de virarem hábito

Um plano de mudança não é um calendário de comunicação. Estes são os sete componentes e quem deve ser responsável por cada um.

Componente	Finalidade	Responsável
Mapeamento de papéis e influência	Todos os afetados, com a influência que têm, não só o cargo	Líder de mudança
Avaliação de impacto da mudança	Como mudam os papéis, processos e ferramentas de cada grupo	Donos de processo, com a equipe de mudança
Plano de comunicação	Públicos, mensagens, canais e momento, com ciclos de feedback	Líder de comunicação
Treinamento e capacitação	Currículo por função, prática, verificações de prontidão	Gerente de treinamento
Engajamento da liderança	Líderes alinhados, informados e apoiando a mudança de forma visível	Patrocinador executivo, com o líder de mudança
KPIs de adoção	Medidas de comportamento definidas no design e acompanhadas após o go-live	Líder de mudança
Monitoramento da resistência	Sinais precoces de alerta associados a cada equipe	Todos os líderes de frente de trabalho

Na maioria dos planos de mudança, comunicação significa boletins, e-mails e town halls. Não é isso que move as pessoas.

Lembro de uma implantação em que comunicamos tudo no prazo, mas ninguém sabia explicar por que o processo estava mudando. Tínhamos volume, mas não tínhamos clareza.

Adapte ao público. A alta gestão quer saber primeiro o impacto no negócio. Os usuários finais precisam ouvir do próprio gestor, não de um líder de programa que nunca viram. Os líderes funcionais reagem melhor quando são donos de parte da mensagem.

Crie canais de retorno. Comunicação só de mão única é meio plano. Trabalhei com uma equipe em que as chamadas semanais de perguntas e respostas tiveram mais efeito do que qualquer e-mail. Ligue o que você ouve ao registro de riscos, para que os pontos fracos apareçam antes de chegar ao público.

Acerte o momento. Cedo demais gera confusão. Tarde demais soa forçado. Em uma implantação, os usuários achavam que seus empregos seriam substituídos. Ninguém disse isso. Mas o silêncio preencheu as lacunas. Enfrente o medo de forma direta e cedo, antes que outra pessoa o faça por você.

Não reaproveite o mapa de pessoas do último projeto. A influência muda de um programa para outro. Monte o mapa do zero e atualize-o todo mês.

Para cada pessoa, acompanhe três coisas: o quanto a mudança a afeta, onde ela está hoje (favorável, neutra ou resistente) e quanta influência tem sobre os outros. Um gerente intermediário resistente, com uma equipe que o segue, pesa mais do que um usuário individual resistente.

Colete também o histórico informal. Projetos fracassados do passado moldam o comportamento de maneiras que os documentos de lições aprendidas nunca registram. Algumas horas ouvindo o que as pessoas lembram mostram com o que você realmente está lidando. Meu guia de gestão de partes interessadas trata do mapeamento com mais detalhes.

O treinamento é uma parte da gestão de mudanças, não o todo. A falha comum é um treinamento que chega tarde, no formato errado e termina antes de as pessoas se sentirem seguras. Um curso de um dia, duas semanas antes do go-live, não é prontidão.

O que funciona:

1. Conteúdo por função. Ensine a cada grupo o que ele precisa para o próprio trabalho, não um tour pelo sistema.
2. Prática com dados reais. Use os dados e as transações da própria empresa, não cenários de demonstração.
3. Power users como instrutores. As pessoas aprendem melhor com colegas em quem confiam. Trate os power users como coautores do design, não só como testadores.
4. Treinamento na hora certa. Uma equipe de finanças com a qual trabalhei faltava às sessões porque elas estavam marcadas no horário errado. Mudar o horário resolveu.
5. Suporte depois do go-live. A confiança cai depois do go-live, não antes. Coloque no hypercare pessoas que saibam responder rápido a perguntas reais.

O teste de aceitação do usuário (UAT) também faz parte da adoção. Lembro de uma sessão de UAT em que um pequeno erro na lógica de preços teria causado faturamento incorreto. Um líder de equipe percebeu. Ninguém mais tinha visto. Essa única descoberta evitou semanas de retrabalho, e aconteceu porque um usuário de negócio sentia que o sistema era em parte dele.

Coloque limites de adoção nos seus quality gates. “O sistema funciona” é uma aprovação funcional. “Os usuários estão prontos para trabalhar nele” é outra, e a maioria dos programas só pede a primeira. Meu guia sobre estratégias de treinamento em SAP aprofunda o plano de treinamento.

KPIs de adoção a definir antes do go-live

Defina-os durante o design, para ter uma linha de base de comparação:

1. Taxas de login por grupo de usuários nos primeiros 90 dias.
2. Taxas de erro nas transações-chave em comparação com a linha de base do sistema legado.
3. Chamados de suporte por volume e categoria.
4. Frequência de soluções de contorno: exportações para planilhas, registros paralelos, aprovações manuais fora do sistema.
5. Confiança relatada pelos gestores, a partir de pesquisas rápidas de pulso.

A janela é estreita. Já vi usuários voltarem em silêncio para as planilhas em poucas semanas, não porque o sistema estivesse com defeito, mas porque ninguém os ajudou a atravessar a mudança. Poucos meses depois do go-live, as soluções de contorno viram hábito.

Ferramentas de adoção digital

A SAP concluiu a aquisição da WalkMe em setembro de 2024, por um equity value de cerca de US$ 1,5 bilhão. Na ocasião, a SAP afirmou que os recursos de IA da WalkMe acrescentariam ajuda contextual ao Joule nos diversos fluxos de trabalho. Isso significa que a SAP agora é dona de duas ferramentas de adoção, com pontos fortes diferentes:

• SAP Enable Now serve para conteúdo de treinamento estruturado: grave um processo uma vez e gere a partir dele documentação, simulações e roteiros de teste.
• WalkMe serve para orientação dentro do aplicativo no momento do uso, e pode abranger aplicativos SAP e não SAP.

Avalie as duas em conjunto. A Whatfix é a principal alternativa independente, se você quer uma ferramenta de adoção que não esteja atrelada à SAP. Nenhuma dessas ferramentas substitui um gestor explicando por que a mudança importa.

Mesmo com boa preparação, surgem novos atritos. Controlá-los demais costuma sair pela culatra. O objetivo é enxergá-los cedo.

Os sinais de alerta são workshops perdidos, silêncio nas reuniões, feedback vago nos testes e usuários-chave criando soluções de contorno não oficiais. Associe cada sinal à equipe de onde ele vem, para agir antes que ele chegue ao comitê de direção.

Uma prática que funciona: alterne os líderes de mudança por fase. Uma única pessoa responsável pela mudança ao longo de um programa de dois anos costuma se esgotar e perder a perspectiva. À medida que a natureza da resistência muda, as pessoas que lidam com ela também devem mudar.

Acima de tudo, mantenha a gestão de mudanças dentro da estrutura do programa. Os resultados de comportamento pertencem ao termo de abertura do projeto. Os riscos com pessoas, como a sobrecarga das equipes e a desconfiança deixada por projetos anteriores, pertencem ao registro de riscos, ao lado dos técnicos. Quando a gestão de mudanças se reduz a um item do relatório genérico do PMO, vira apenas uma caixinha a ser marcada.

O que um plano de gestão de mudanças deve incluir?

Sete partes: mapeamento de influência, avaliação de impacto da mudança, plano de comunicação com ciclos de feedback, treinamento por função, engajamento da liderança, KPIs de adoção e monitoramento da resistência. Cada uma precisa de um responsável nomeado, e o plano deve estar ligado ao termo de abertura, aos workshops de design e aos quality gates.

Quais são os 5 Cs da gestão de mudanças?

Existem várias versões. A que eu uso é: clareza (as pessoas sabem o que muda para elas), consistência (os líderes dizem a mesma coisa), comprometimento (o patrocinador continua visível), comunicação (relevante, oportuna e de mão dupla) e capacidade (treinamento, suporte e tempo para se adaptar). Se qualquer uma faltar, as pessoas voltam aos velhos hábitos.

Quais são os 7 Rs da gestão de mudanças?

Vêm do gerenciamento de serviços de TI e servem para avaliar uma requisição de mudança antes de agir sobre ela. Quem a solicitou, a razão, o retorno esperado, os riscos, os recursos necessários, quem é o responsável e a relação com outras mudanças. Aplicam-se ao controle técnico de mudanças, e não ao lado humano de um programa.

Qual é a diferença entre a gestão de mudanças organizacional e a técnica?

A gestão de mudanças organizacional prepara as pessoas: comunicação, treinamento e suporte durante uma mudança na forma como elas trabalham. A gestão técnica de mudanças controla o que entra no sistema SAP, por meio de transportes, aprovações, testes e rollback. Os programas de ERP costumam gerir bem o lado técnico; as falhas de adoção vêm do lado organizacional. Meu guia sobre ferramentas de gestão técnica de mudanças em SAP trata do lado técnico.

Devo usar WalkMe ou SAP Enable Now?

Muitas vezes, os dois. O SAP Enable Now é mais forte para criar conteúdo de treinamento estruturado antes do go-live. O WalkMe é mais forte para orientação dentro do aplicativo depois do go-live, principalmente quando os usuários circulam entre o SAP e outros aplicativos. Como a SAP é dona dos dois, avalie-os em conjunto. A Whatfix é a principal alternativa independente.

Quando a gestão de mudanças deve começar em um projeto de ERP?

Na mobilização, antes do primeiro workshop de design. As ações iniciais que mais importam são mapear a influência, coletar o histórico informal de projetos anteriores, colocar os resultados de comportamento no termo de abertura e definir o ritmo de comunicação do patrocinador.