Voltar ao Diário
Transformação DigitalNº 00803 de julho de 20267 min

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.

Referências
  1. 01Harvard Business Review — The Hard Side of Change Management (Sirkin, Keenan & Jackson)
  2. 02OMG — Business Process Model and Notation (BPMN) 2.0
  3. 03Gartner Glossary — Enterprise Resource Planning (ERP)
Também:
Apps MobileNº 007

Quanto custa mesmo lançar uma app nativa nas duas stores em 2026

As taxas das stores são a parte barata. O custo real está no que ninguém te mostra na fatura: manutenção, revisões rejeitadas e o segundo sistema operativo.

Performance & SEONº 006

O que o LCP de 4 segundos faz à taxa de conversão do teu checkout

Quatro segundos parece pouco. No checkout, é o intervalo entre uma venda fechada e um carrinho abandonado.

Voltar ao Diário