Porque migrar o ERP para a cloud não resolve o teu problema de processos
Pôr o caos numa máquina mais rápida só te dá caos mais rápido. O ERP na cloud é infraestrutura, não cura para processos partidos.
Há uma promessa repetida em todas as reuniões de migração de ERP. "Quando estivermos na cloud, isto vai ficar tudo mais simples." Não vai. A cloud muda onde o software corre, não como a tua empresa trabalha.
Se o pedido de compra hoje passa por três aprovações em e-mail, uma folha de Excel paralela e um telefonema, vai continuar a passar pelo mesmo depois da migração. Só que agora corre em servidores de Frankfurt em vez de uma máquina na cave.
A cloud é um sítio, não uma decisão de processo
Migrar para a cloud resolve problemas reais. Deixas de gerir hardware. Tens backups geridos, escala elástica, atualizações sem parar a operação. Isso vale o investimento. Mas é um problema de infraestrutura.
O teu problema, quase sempre, é outro. É o vendedor que aprova crédito por instinto. É o stock que diverge do sistema porque ninguém regista as devoluções no momento certo. É o fecho de mês que demora duas semanas porque metade dos lançamentos vive em folhas soltas.
Nenhuma destas coisas melhora por mudar de servidor. O ERP — local ou cloud — é o espelho dos teus processos. Se o processo é confuso, o espelho devolve confusão com melhor uptime.
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 já tens significa codificar décadas de exceções, atalhos e "é assim que sempre fizemos" 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 retalhista trabalhou anos num novo sistema de gestão de stock 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 standard. O software dobrou-se até partir.
Vinte anos antes, a Hershey fez o caminho oposto e falhou pela pressa. Pôs ERP, CRM e gestão de cadeia de abastecimento a entrar em produção em simultâneo, mesmo antes do Halloween, sem tempo para estabilizar os processos. Não conseguiu despachar encomendas que tinha em armazém. A migração estava tecnicamente feita; a operação parou na mesma.
O que tens de fazer antes de tocar na cloud
A ordem certa é desconfortável porque é mais lenta no início. Primeiro entendes os processos. Depois decides quais valem a pena, quais cortas e quais alinhas ao standard do software. Só então migras.
- Mapeia 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 ao telefone.
- Para cada exceção customizada, pergunta porquê. Metade das vezes a resposta é uma regra que já ninguém precisa.
- Decide o que adaptas ao standard. Customização cara hoje é dívida técnica que te prende a um fornecedor amanhã.
- Limpa os dados antes de migrar. Dados sujos num sistema novo são dados sujos, ponto final.
- Define quem é dono de cada processo. Sem dono, ninguém defende a mudança quando a equipa 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 manuais. 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 neste 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 isto bem no trabalho de Sirkin, Keenan e Jackson sobre os fatores duros da mudança.
Imagina o cenário típico: o responsável de armazém recebe um sistema novo que o obriga a registar cada movimento no momento, em vez de no fim do turno. Para ele, o sistema novo é mais trabalho, não menos. Se não lhe mostras o porquê e não ajustas o processo à realidade do chão de fábrica, ele volta à folha de Excel paralela. E o teu ERP na cloud passa a ser um arquivo morto e caro.
Então e a cloud, vale a pena?
Vale. Mas pelos motivos certos. Migra para a cloud para deixares de gerir infraestrutura, para teres elasticidade e para integrares mais facilmente com o resto do teu stack digital. Não migres à espera que a mudança de servidor reorganize a tua operação.
A sequência que funciona é simples de dizer e dura de fazer. Arruma o processo. Limpa os dados. Alinha as pessoas. Depois liga a cloud. Quem inverte esta ordem paga duas vezes: uma na migração e outra a desfazer a migração.
Software bom não conserta operação má. Só a torna mais rápida a partir-se. A pergunta certa nunca foi "cloud ou local". Foi "os nossos processos merecem ser automatizados como estão?". Na maioria dos casos, a resposta honesta é não — e é aí que o projeto começa de verdade.