As Mudanças Organizacionais Bem Sucedidas

Por que quase todas as transformações empresariais falham

A maioria das empresas que tentam se reinventar não falha por falta de visão. Elas falham porque subestimam o trabalho real que é convencer pessoas a fazerem coisas diferentes do que faziam semana passada. Eu já vi orçamentos de mudança organizacional chegar a seis dígitos e ainda assim o resultado ser nada, porque o dinheiro era gasto em consultoria e plataformas, não em ajustar incentivos e estruturas de poder internas. Quando eu comecei a lidar com esse tipo de coisa há anos, achava que o padrão era seguir o modelo de Kotter com seus oito passos. Funciona no papel. Na prática, você percebe rápido que o passo 4 — formar uma coalizão dirigente — é onde tudo desanda. Você lista os nomes dos líderes que devem apoiar a mudança, mas esquece de mapear quem vai perder poder com ela. Eu aprendi isso na marra num projeto de migração de processos para um ERP novo numa empresa do setor de serviços. A diretoria tinha sido conversada, os gerentes médios tinham sido alinhados, mas os coordenadores de equipe — aqueles que controlavam o fluxo real do dia a dia — foram completamente ignorados. O resultado foi que o sistema novo entrou funcionando perfeitamente no plano e travou na semana 3 porque ninguém na operação queria passar as informações pelo novo canal. A solução que encontrei foi simples e chata: identificar esses coordenadores, dar a eles acesso antecipado ao sistema antes dos demais, e transformá-los em testadores oficiais com autoridade para cobrar adaptações. Em vez de impor a mudança de cima para baixo, usei eles como ponte. O prazo de implementação expandiu duas semanas, mas a taxa de adoção real saltou de 17% para 78% em oito semanas. O que poucos profissionais entendem é que a resistência à mudança raramente tem a ver com tecnologia ou processo. Tem a ver com identidade. Quando você muda a forma como alguém trabalha, está dizendo implicitamente que o jeito anterior era errado. Isso gera um desconforto que nenhum workshop de team building resolve. Um insight contraintuitivo que eu descobri é que, em muitos casos, as mudanças que mais avançam são aquelas que incluem uma fase deliberada de manutenção dos velhos processos enquanto os novos rodam em paralelo. Parece perda de tempo. Na realidade, dá às pessoas um espaço seguro para errar sem comprometer o core business.

Também vale notar algo que livros de gestão quase nunca mencionam: a velocidade importa menos do que a consistência. Eu já vi empresas que executaram transformações em onze meses com resultados devastadores porque a pressão por rapidez gerou decisões apressadas que depois precisaram ser desfeitas. Uma empresa do setor varejista que trabalhei fez isso em 2019. Queriam reduzir o headcount da área administrativa em 30% e redistribuir funções em quatro meses. O plano foi aprovado, mas a execução deixou buracos operacionais enormes. Em seis meses tiveram que contratar temporários para cobrir lacunas e o custo final saiu 40% acima do orçado. O aprendizado foi que reduzir pessoas sem redesenhar processos antes é só adiar o problema, não resolvê-lo.

Como estruturar uma mudança que de fato pega

Mapeamento político primeiro, comunicação depois. A grande maioria dos planos de mudança começa com um email institucional anunciando a nova direção. Isso é um erro. Antes de qualquer comunicado, você precisa mapear quem ganha, quem perde e quem fica indiferente com a mudança proposta. Faça isso com dados reais, não com suposições. Liste os cargos, os fluxos de informação e os pontos de decisão onde cada pessoa tem influência. A partir daí, construa um plano de engajamento diferenciado por grupo, não um discurso genérico para toda a empresa. Defina métricas de adoção, não apenas de resultado. Se a mudança é uma nova ferramenta, não acompanhe apenas se ela está sendo usada. Acompanhe se as pessoas estão usando da forma esperada, se estão contornando o sistema com planilhas paralelas, se estão voltando para os antigos processos em momentos de pressão. Eu costumo recomendar que se estableça pelo menos três indicadores de adoção: taxa de uso efetivo (não apenas login), taxa de abandono (usuários que param de usar após trinta dias) e taxa de uso paralelo (quantas pessoas mantêm o processo antigo ativo simultaneamente). Sem esses dados, você não sabe se a mudança está pegando ou só parecendo que está. Proteja os early adopters e dê espaço para os resistentes. Quem adota a mudança cedo merece reconhecimento visível e acesso a informações privilegiadas sobre a evolução do projeto. Quem resiste não precisa ser convocado a uma sessão de coerção. Precisa de uma saída digna. Eu já vi gente ser obrigada a fazer treinamento de domingo porque não conseguia se adequar ao novo processo durante a semana. O efeito foi o oposto do pretendido: o ressentimento corroeu a produtividade tanto quanto a mudança pretendia melhorar. O caminho mais eficiente foi permitir que aqueles que realmente não se adaptassem fossem realocados para áreas onde os processos antigos ainda faziam sentido, enquanto os demais evoluíam naturalmente.

Sustentação pós-implementação. A maioria dos planos de mudança termina quando a nova estrutura é comunicada oficialmente. Esse é o momento mais crítico. Os primeiros sessenta dias após o go-live definem se a mudança endurece ou volta atrás. Mantenha uma equipe de suporte dedicada, faça rodadas de feedback quinzenais e esteja preparado para ajustar processos que parecem bons no papel mas falham no chão de fábrica. Não tenha vergonha de admitir erros de planejamento publicamente. Isso constrói credibilidade mais rápido do que qualquer comunicação corporativa refinada. Tem também um ponto que costuma ser negligenciado e que pode fazer toda a diferença: o timing. Mudanças organizacionais impostas em períodos de alta pressão operacional — final de ano fiscal, temporada de vendas, fechamento trimestral — têm probabilidade significativamente maior de falhar não por defeito do projeto em si, mas porque as pessoas não têm banda cognitiva para absorver algo novo. Eu aprendi a sugerar que se deixe sempre uma janela de quatro a seis semanas entre o anúncio da mudança e sua implementação real, usando esse período exclusivamente para preparação, não para execução. Empresas que pulam essa etapa normalmente pagam o preço depois, com retrabalho e esgotamento das equipes. O que eu posso afirmar com segurança é que nenhum framework único funciona em todos os contextos. Modelos como ADKAR, McKinsey 7-S ou o próprio Kotter são úteis como referência, mas aplicar qualquer um deles de forma dogmática gera exatamente o mesmo problema que o planejamento excessivo: a desconexão com a realidade operacional. O que diferencia os projetos que dão certo dos que não dão é a capacidade de ler o terreno e ajustar a abordagem conforme os sinais aparecem, não antes deles aparecerem.