Tem uma promessa que se repete em toda reunião de migração de ERP. "Quando a gente estiver na nuvem, vai ficar tudo mais simples." Não vai. A nuvem muda onde o software roda, não como a sua empresa trabalha.
Se o pedido de compra hoje passa por três aprovações no e-mail, uma planilha de Excel paralela e um telefonema, vai continuar passando pelo mesmo caminho depois da migração. Só que agora roda em servidores de Frankfurt em vez de uma máquina no porão.
A nuvem é um lugar, não uma decisão de processo
Migrar para a nuvem resolve problemas reais. Você para de gerenciar hardware. Tem backups gerenciados, escala elástica, atualizações sem parar a operação. Isso vale o investimento. Mas é um problema de infraestrutura.
O seu problema, quase sempre, é outro. É o vendedor que aprova crédito por instinto. É o estoque que diverge do sistema porque ninguém registra as devoluções na hora certa. É o fechamento do mês que demora duas semanas porque metade dos lançamentos vive em planilhas soltas.
Nenhuma dessas coisas melhora ao trocar de servidor. O ERP — local ou nuvem — é o espelho dos seus processos. Se o processo é confuso, o espelho devolve confusão com uptime melhor.
O erro do levantamento "as-is" preguiçoso
A migração típica começa com um levantamento dos processos atuais. O objetivo declarado é "replicar o que já temos". É aqui que o projeto morre antes de começar.
Replicar o que você já tem significa codificar décadas de exceções, atalhos e "sempre foi assim" num sistema novo e caro. O resultado é um Frankenstein customizado que ninguém consegue atualizar depois.
O caso da Lidl é o exemplo público mais citado. A varejista trabalhou anos num novo sistema de gestão de estoque baseado em SAP. O projeto foi cancelado em 2018 depois de centenas de milhões investidos. Um dos motivos relatados: a Lidl insistiu em adaptar o software ao seu modelo de inventário a custo de aquisição, em vez de adaptar o processo ao padrão. O software se dobrou até quebrar.
Vinte anos antes, a Hershey fez o caminho oposto e falhou pela pressa. Colocou ERP, CRM e gestão de cadeia de suprimentos para entrar em produção ao mesmo tempo, bem antes do Halloween, sem tempo para estabilizar os processos. Não conseguiu despachar pedidos que tinha em estoque. A migração estava tecnicamente feita; a operação parou do mesmo jeito.
O que você precisa fazer antes de tocar na nuvem
A ordem certa é desconfortável porque é mais lenta no começo. Primeiro você entende os processos. Depois decide quais valem a pena, quais corta e quais alinha ao padrão do software. Só então migra.
- Mapeie os processos reais, não os que estão no manual. O processo real é o que as pessoas fazem às 17h de uma sexta com um cliente irritado no telefone.
- Para cada exceção customizada, pergunte por quê. Metade das vezes a resposta é uma regra que ninguém precisa mais.
- Decida o que você alinha ao padrão. Customização cara hoje é dívida técnica que te prende a um fornecedor amanhã.
- Limpe os dados antes de migrar. Dado sujo num sistema novo é dado sujo, ponto final.
- Defina quem é dono de cada processo. Sem dono, ninguém defende a mudança quando a equipe resiste.
A resistência interna é o verdadeiro projeto
A parte técnica de uma migração é a mais previsível. APIs, integrações, janelas de cutover — tudo isso tem manual. O que não tem manual são as pessoas que fizeram o processo antigo durante quinze anos e o conhecem melhor do que qualquer consultor.
Estudos clássicos de gestão da mudança são consistentes nesse ponto. A maioria dos programas de transformação não falha por tecnologia. Falha por execução, alinhamento e adesão das pessoas. A HBR resume isso bem no trabalho de Sirkin, Keenan e Jackson sobre os fatores duros da mudança.
Imagine o cenário típico: o responsável pelo almoxarifado recebe um sistema novo que o obriga a registrar cada movimentação na hora, em vez de no fim do turno. Para ele, o sistema novo é mais trabalho, não menos. Se você não mostra o porquê e não ajusta o processo à realidade do chão de fábrica, ele volta para a planilha de Excel paralela. E o seu ERP na nuvem vira um arquivo morto e caro.
E a nuvem, vale a pena então?
Vale. Mas pelos motivos certos. Migre para a nuvem para parar de gerenciar infraestrutura, para ter elasticidade e para integrar mais fácil com o resto do seu stack digital. Não migre esperando que a troca de servidor reorganize a sua operação.
A sequência que funciona é simples de falar e dura de fazer. Arrume o processo. Limpe os dados. Alinhe as pessoas. Depois ligue a nuvem. Quem inverte essa ordem paga duas vezes: uma na migração e outra para desfazer a migração.
Software bom não conserta operação ruim. Só a deixa mais rápida na hora de quebrar. A pergunta certa nunca foi "nuvem ou local". Foi "os nossos processos merecem ser automatizados do jeito que estão?". Na maioria dos casos, a resposta honesta é não — e é aí que o projeto começa de verdade.