Deixa eu te contar uma cena que já vi se repetir mais vezes do que gostaria.
A empresa passa meses avaliando sistemas, meses negociando contrato, meses implementando. No go-live, os usuários usam o sistema por duas semanas, depois voltam para as planilhas. O projeto é oficialmente declarado "completo". Internamente, todo mundo sabe que não funcionou. E a culpa vai para o sistema.
"O Salesforce é complicado demais."
"O sistema não foi feito para o nosso negócio."
"A consultoria não entendeu o que precisávamos."
Às vezes essas críticas são justas. Mas na maioria das vezes, o que falhou não foi o sistema — foi o que aconteceu antes do projeto começar.
Os números que ninguém gosta de citar
A McKinsey estima que 70% das transformações de larga escala falham. Pesquisas mais recentes chegam a 87% quando o critério é entregar os resultados de negócio prometidos. A Bain, em estudo de 2024, encontrou que 88% das transformações não atingem as ambições originais.
Esses números costumam causar desconforto em reuniões de kickoff. Mas eles existem, são robustos e precisam ser levados a sério — especialmente porque revelam o padrão: as falhas raramente acontecem na execução técnica. Elas acontecem antes.
A McKinsey identificou que cultura — não tecnologia — é o principal obstáculo para transformações digitais. Empresas que investem em mudança cultural têm taxa de sucesso 5,3 vezes maior do que as que focam apenas na implementação técnica.
Isso muda completamente o que precisa acontecer antes de qualquer projeto começar.
Por que o sistema recebe a culpa que não é dele
Quando uma implementação falha, o sistema é o bode expiatório mais conveniente. Ele não se defende, não tem voz no post-mortem e já foi pago — então não tem mais defensor ativo no projeto.
Mas o sistema só pode fazer o que foi configurado para fazer. E ele foi configurado com base em processos que foram descritos às pressas, em reuniões com stakeholders que tinham outras prioridades, por usuários que não participaram do design e não se identificam com o resultado.
A tecnologia potencializa o que já existe. Se o que existe são processos inconsistentes, dados ruins e falta de alinhamento interno, o sistema vai digitalizar tudo isso com muito mais eficiência.
Os 5 erros que eu vejo antes do projeto começar
Depois de acompanhar dezenas de implementações — algumas muito bem-sucedidas, algumas que não chegaram a lugar nenhum — os fatores de falha se repetem de forma previsível.
1. Processos não mapeados, ou mapeados errado
Implementar um sistema novo sem ter os processos documentados e validados é como contratar um arquiteto para reformar uma casa sem nunca ter entrado nela. O sistema vai refletir a realidade que foi descrita — e se essa realidade estava incompleta ou idealizada, o resultado também vai ser.
O problema mais comum: o mapeamento de processos é feito pela equipe de TI ou pela consultoria, sem participação real das áreas operacionais. O resultado é um processo "oficial" que ninguém segue na prática, digitalisado com perfeição técnica.
2. Patrocínio executivo ausente ou passivo
Transformações digitais que não têm patrocínio ativo da liderança — não apenas aprovação no e-mail de kickoff, mas presença real nas decisões difíceis — tendem a morrer no médio prazo.
Aqui tem uma nuance importante: patrocínio ativo não é o CEO assistindo à apresentação de kickoff e nunca mais aparecendo. É o C-level sinalizando para a organização que isso é prioridade, desempatando conflitos entre áreas, liberando tempo dos usuários-chave e sendo o primeiro a cobrar adoção.
Sem esse sinal claro vindo de cima, a equipe operacional entende rapidamente que o projeto é mais uma iniciativa de TI — importante para quem vende, opcional para quem executa.
3. Usuários finais de fora do design
Os usuários finais são os mais impactados pela mudança e, historicamente, os menos consultados no design da solução. O argumento costuma ser de eficiência: envolvê-los demora, tem conflitos, é mais fácil definir o escopo com os gerentes e depois treinar.
O problema é que gerentes descrevem como o processo deveria funcionar. Usuários descrevem como ele realmente funciona. São descrições muito diferentes, e ignorar a segunda é uma receita para rejeição.
O sinal mais claro de que isso aconteceu: no treinamento pré-go-live, os usuários ficam perguntando "mas e quando acontece X?" e a resposta é "isso não estava no escopo".
4. Expectativas sem calibração de realidade
"Depois que implementarmos o Salesforce, vai resolver o problema de vendas." Já ouvi variações dessa frase muitas vezes. E entendo de onde vem — demos de produto são impressionantes, os cases de sucesso são reais, e existe uma pressão genuína por resultados.
O sistema não vai resolver o problema de vendas se o problema de vendas é que os vendedores não seguem o processo, não documentam as interações e não atualizam o funil. O sistema vai tornar mais visível que isso está acontecendo — o que é útil — mas não vai resolver a causa raiz.
Tecnologia potencializa bons processos. Não conserta processos ruins.
5. Change management tratado como opcional
Gestão de mudanças é frequentemente o primeiro item cortado quando o orçamento aperta. É vista como "soft", como coisa de RH, como algo que acontece junto com o treinamento na semana do go-live.
Na prática, change management é o conjunto de atividades que determina se as pessoas vão realmente adotar o que foi implementado — ou se vão usar por obrigação por três meses e depois encontrar uma forma de contornar.
Isso inclui comunicação desde o início sobre o porquê da mudança, envolvimento de influenciadores internos (não necessariamente os mais seniores, mas os mais respeitados na operação), gestão de resistências antes que virem sabotagem passiva, e métricas de adoção que vão além de "quantos usuários fizeram login".
O que precisa acontecer antes de qualquer configuração
A preparação que realmente faz diferença não é técnica. É estratégica.
Mapeie os processos com quem os executa. Não com quem os gerencia — com quem os executa. Essa distinção é crítica. Reserve tempo para isso antes de definir escopo.
Defina KPIs de sucesso antes do projeto começar. "Aumentar a eficiência da equipe comercial" não é um KPI. "Reduzir o ciclo de vendas de 45 para 30 dias em 6 meses" é. A diferença importa porque define se o projeto teve sucesso — ou se vai ser avaliado por critérios que ninguém concordou antes.
Identifique os resistentes antes do go-live. Em toda organização existe alguém que vai questionar a mudança, atrasar a adoção ou encontrar argumentos para continuar no processo antigo. Identificar essas pessoas cedo e entender as motivações delas transforma potenciais sabotadores em aliados — ou pelo menos em oposição declarada, que é mais fácil de gerenciar.
Faça um piloto antes de escalar. Implementar para toda a empresa de uma vez é o caminho mais arriscado. Um piloto com um time pequeno e representativo permite identificar o que não foi previsto antes de o problema afetar toda a organização.
Governe o projeto com papéis claros. Quem tem autoridade para aprovar mudanças de escopo? Quem decide quando algo que não estava previsto entra ou sai? Sem governança definida, toda decisão vira uma reunião, e toda reunião vira um atraso.
Como saber se você está pronto para implementar
Três perguntas simples que revelam bastante:
Você consegue descrever o processo que quer digitalizar em menos de 10 minutos, com uma pessoa de qualquer área da empresa entendendo? Se não, o processo precisa ser clarificado antes de ser configurado.
Os usuários que vão usar o sistema sabem por que ele está sendo implementado — não "porque a diretoria decidiu", mas qual o benefício real para o trabalho deles? Se não, a comunicação de change management ainda não começou.
Existe alguém com autoridade e comprometimento para resolver conflitos entre áreas durante o projeto? Se não, cada impasse vai virar um atraso, e os impasses sempre aparecem.
Resposta "não" para qualquer uma dessas perguntas não significa que o projeto deve ser cancelado. Significa que há trabalho a fazer antes de começar — e que fazer esse trabalho vai aumentar significativamente as chances de sucesso.
Perguntas frequentes sobre preparação para transformação digital
Por que a maioria das transformações digitais falha?
A McKinsey estima que 70% das transformações de larga escala falham, principalmente por fatores humanos e culturais — não técnicos. Processos mal mapeados, ausência de patrocínio executivo real e falta de gestão de mudanças são as causas mais comuns. O sistema raramente é o culpado.
Quanto tempo de preparação é necessário antes de implementar um CRM ou ERP?
Depende da complexidade da operação, mas projetos bem-sucedidos tipicamente dedicam de 4 a 12 semanas à fase de discovery e preparação — mapeamento de processos, definição de KPIs, alinhamento de stakeholders — antes de qualquer configuração começar.
O que é change management e por que é importante em implementações?
Change management é o conjunto estruturado de atividades que aumenta a probabilidade de as pessoas adotarem uma mudança: comunicação clara sobre o porquê, envolvimento de influenciadores internos, gestão de resistências e acompanhamento de adoção. Sem isso, implementações tecnicamente perfeitas morrem na falta de uso.
Como envolver os usuários finais sem atrasar o projeto?
O envolvimento não precisa ser de todos os usuários — precisa ser de pessoas representativas de cada perfil de uso. Sessões de discovery de 2 a 4 horas com 3 a 5 usuários por área costumam revelar mais do que meses de documentação top-down.
Qual a diferença entre patrocínio executivo ativo e passivo?
Patrocínio passivo é aprovar o projeto e aparecer no kickoff. Patrocínio ativo é desempatar conflitos entre áreas, cobrar adoção nas reuniões de gestão, liberar tempo dos usuários-chave para participar do projeto e comunicar para a organização que a mudança é real e tem prioridade.
