Por que migrar o ERP para a nuvem não resolve seu problema de processos

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.