10 erros de modernização de ERP a evitar

Os erros de modernização de ERP que mais machucam são estratégicos, não técnicos: tratar o go-live como linha de chegada, copiar os processos legados para o sistema novo, começar tarde o trabalho de dados e de mudança, construir tudo dentro do ERP e assinar licenças sem um modelo de cinco anos. Eles raramente aparecem em tempo real. Aparecem depois do go-live, quando os ganhos de eficiência prometidos não vêm e as soluções de contorno voltam.

Este texto é para CIOs, CFOs e diretores de programa que estão planejando ou resgatando uma modernização de S/4HANA ou de outro ERP. Cada erro abaixo vem com o que ele parece na prática e a correção, seguido de um checklist de alerta antecipado de uma página e do que as mudanças da SAP em 2026 significam.

Vi projetos bem financiados, com equipes experientes e um time completo de assessores, ainda assim ficarem aquém. A causa raramente é o sistema. São lacunas de responsabilidade, de planejamento de integração e de comunicação entre equipes que tomam decisões que dependem umas das outras.

1. Tratar o go-live como linha de chegada

Quando o sistema entra no ar, muitas equipes presumem que o trabalho pesado acabou. É aí que a pressão real começa: a operação diária, os requisitos que mudam e o comportamento real dos usuários pressionam o desenho.

Já vi projetos em que o comitê de direção é dissolvido logo após o go-live. Seis meses depois a adoção está estagnada e ninguém é dono do backlog.

A correção: financie um período de governança pós-go-live de 6 a 12 meses. Estenda o mandato do comitê de direção. Monitore a adoção dos processos, não só a disponibilidade do sistema. Defina quality gates pós-go-live com donos nomeados.

2. Migrar processos legados sem repensá-los

Já vi cadeias inteiras de aprovação reconstruídas exatamente como eram, mesmo quando metade das pessoas envolvidas não tinha nada a ver com o processo atual. Ninguém tinha perguntado se as etapas ainda eram necessárias. O resultado era um ERP moderno rodando fluxos antigos: uma versão mais cara do que eles já tinham.

A versão disso no S/4HANA: jobs batch customizados levados do ECC como estão, construídos sobre estruturas de tabelas que não existem mais. A migração é tecnicamente limpa. A lógica de negócio está quebrada.

A correção: redesenhe os processos antes da construção. Percorra cada fluxo junto com as equipes de operações, finanças e entrega e questione cada etapa.

Área legada	O que costuma dar errado	O que fazer em vez disso
Código customizado do ECC	Código customizado sem uso levado para o S/4HANA	Faça a análise de uso e as verificações de código customizado da SAP; elimine o código sem uso
Fluxos antigos	Fluxos de aprovação reconstruídos quando a automação já é possível	Revise com os donos do negócio; use apps Fiori padrão ou o SAP Build Process Automation
Dados mestre fora do padrão	Estruturas legadas flexíveis falham na validação do S/4HANA	Limpe e harmonize antes da migração, com o SAP MDG onde fizer sentido
Relatórios sobre tabelas legadas	O acesso direto a tabelas não combina com o modelo de dados do S/4HANA	Reconstrua sobre CDS views
Soluções de contorno manuais ocultas	Processos paralelos reaparecem depois do go-live	Use process mining antes da migração e digitalize as lacunas

3. Começar a migração de dados tarde demais

Levar dados ruins para um ERP novo é como mudar de casa sem jogar nada fora. A bagunça vai junto, e fica mais difícil de limpar depois que está dentro de um sistema estruturado.

Certa vez vi um go-live fracassar porque ninguém percebeu que um conjunto de dados central tinha registros de cinco unidades de negócio diferentes, cada uma com a sua própria lógica de codificação. A migração técnica estava correta. Os dados não eram utilizáveis. Os relatórios quebraram, os usuários perderam a confiança e a limpeza com o sistema em produção levou meses.

A correção: faça dos dados uma frente de trabalho com responsabilidade do negócio. Designe responsáveis pelos processos, não só consultores técnicos. Decida o que trazer, arquivar ou reconstruir antes de a migração começar. Faça pelo menos duas cargas simuladas completas, com um mapa de dependências para a sequência de carga e um rollback definido para cada carga. Meu texto sobre por que a migração de dados SAP falha aprofunda o assunto.

4. Tratar a gestão de mudanças como tarefa secundária

A versão de sempre: a gestão de mudanças “já está resolvida”, o que significa alguns slides, uma demonstração e uma sessão de treinamento antes do go-live.

As pessoas não resistem porque não gostam de mudança. Resistem quando ninguém explica por que as coisas estão mudando nem como isso as ajuda. Seguem o sistema apenas o suficiente para passar no checklist e depois voltam às planilhas.

O gatilho habitual é a pressão de cronograma: o treinamento é comprimido para recuperar tempo, os usuários ficam sobrecarregados no go-live e o hypercare extra custa mais do que o treinamento que foi cortado.

A correção: dê à gestão de mudanças um orçamento, um cronograma e um dono sênior próprios desde o início. Mapeie os papéis cedo, encontre defensores locais e acompanhe os KPIs de adoção junto com os marcos técnicos. Meu guia do plano de gestão de mudanças apresenta a estrutura.

5. Planejar em cima de roadmaps de fornecedores

Já vi equipes basearem a sua estratégia de integração em um release futuro de um fornecedor, só para vê-lo adiado em 12 meses. Nesse meio-tempo ficaram presas construindo soluções de contorno temporárias, e as soluções de contorno viraram permanentes.

Os fornecedores constroem roadmaps para grandes grupos de clientes. O seu negócio raramente é o centro desse desenho.

A correção: trate o roadmap como um insumo entre vários. Desenhe em torno do que está disponível em geral hoje, teste os novos recursos em um sandbox antes de planejar em cima deles e conte os benefícios do roadmap como ganho extra, não como orçamento.

6. Nenhum plano de desativação dos sistemas legados

Certa vez vi uma empresa pagando seis dígitos por ano para manter um sistema antigo rodando para seis usuários que precisavam extrair relatórios duas vezes por ano. Ninguém tinha feito um plano de desativação.

A correção: coloque a desativação no termo de abertura do projeto desde o primeiro dia, com jurídico, conformidade e governança de dados envolvidos, não só a TI. Acorde os prazos de retenção e uma abordagem de arquivamento antes do go-live, mapeie e desconecte cada interface com o sistema antigo e dê a uma equipe a tarefa de desligá-lo.

7. Subestimar a complexidade da integração

Quando a integração falha, o negócio percebe antes da TI, porque os fluxos param no meio do processo em produção, não em um sistema de teste.

O padrão comum: a TI e o negócio presumem, cada um, que o outro definiu os requisitos de integração. Nenhum definiu. Quando as lacunas aparecem nos testes, não há mais tempo para redesenhar.

A correção: comece o desenho da integração no blueprint. Defina cada cenário, o middleware, o mapeamento e os volumes de mensagens, e esclareça com o negócio tempo real versus lote para cada interface. Nomeie um dono de interface com um SLA antes do go-live. Para novos programas SAP, o middleware é o SAP Integration Suite; o SAP PI/PO sai da manutenção padrão no fim de 2027.

8. Presumir que o ERP dá conta de tudo

Trabalhei em projetos em que as equipes forçaram fluxos de serviço complexos (chamados de TI, solicitações de ativos, roteamento de escalonamentos) para dentro do ERP porque não queriam envolver sistemas externos como o ServiceNow. O resultado foram campos customizados por toda parte, soluções de contorno manuais e usuários presos a um processo que nunca coube.

O ERP é bom em processos estruturados, transacionais e ancorados em finanças. Plataformas dedicadas fazem melhor os chamados de serviço de TI, a orquestração de fluxos e a gestão do conhecimento.

A correção: decida de forma deliberada o que não construir no ERP. Use extensões side-by-side no SAP BTP para as exceções e o ServiceNow ou similar para a orquestração fora do núcleo transacional. Meu artigo sobre modernização de ERP com SAP e ServiceNow trata dessa divisão.

9. Subestimar o custo de licenciamento no longo prazo

Conheço uma equipe que dobrou o gasto com licenças no segundo ano porque precisou de um único recurso que ficava atrás de uma licença de nível superior. O business case tinha modelado apenas o custo até o go-live.

As licenças de ERP cobram por usuários, módulos, transações e uso de API, e o custo cresce com o negócio, você tenha planejado ou não. No SAP, o modelo de Digital Access significa que os documentos criados por sistemas de terceiros podem trazer custo de licença que não estava no modelo comercial original. No RISE e no SAP GROW, a contagem de Full User Equivalent (FUE) cresce com a adoção.

A correção: monte um modelo de licenças de três a cinco anos antes de assinar. Mapeie os papéis para os tipos de licença, modele o crescimento de FUE sobre uma curva de adoção realista, entenda o acesso indireto antes de conectar sistemas externos e audite os usuários inativos após o go-live.

10. Tratar o ERP como um projeto de TI

O padrão mais comum e mais danoso. O planejamento começa na TI, é liderado pela TI e resolve problemas da TI.

Já vi equipes cumprirem todos os marcos no papel enquanto o negócio ainda pergunta por que nada melhorou. Isso geralmente significa que o ERP foi construído para os processos de ontem, sem líderes de operações, finanças ou comercial no desenho.

A correção: coloque líderes de comercial, finanças e operações no comitê de direção desde o início. Escreva o alinhamento estratégico no termo de abertura, não só o escopo técnico. Teste os objetivos do programa contra os resultados esperados pelo conselho de administração antes de o desenho começar.

Use-o em cada reunião do comitê de direção. Se um sinal de alerta estiver presente, o dono nomeado reporta sobre ele até que desapareça.

1. Termo de aberturaResponsabilidade e custoSem líder de operações ou de finanças, sem modelo de licenças de cinco anos, sem data de desativação
2. BlueprintDesenho de processos e integraçãoO processo de hoje copiado, interfaces ainda sem desenho
3. Primeira carga simuladaDadosAinda sem relatório de qualidade de dados
4. Go-liveO que acontece depoisSem governança financiada para os 12 meses seguintes

Erro	Sinal de alerta antecipado	Dono
1. Go-live como linha de chegada	Nenhum plano de governança financiado para os 12 meses após o go-live	Patrocinador
2. Processos legados copiados	Os workshops de desenho partem de telas de “como fazemos hoje”	Responsáveis pelos processos
3. Trabalho de dados tardio	Nenhum relatório de qualidade de dados antes da primeira carga simulada	Líder de migração de dados
4. Mudança como tarefa secundária	O plano de mudança é um calendário de treinamentos	Líder de mudança
5. Dependência de roadmap	Uma decisão de desenho espera por um recurso que não foi lançado	Arquiteto de soluções
6. Nenhuma desativação	Nenhuma data de desativação para qualquer sistema legado no termo de abertura	PMO
7. Integração subestimada	Interfaces não desenhadas até o fim do blueprint	Líder de integração
8. ERP para tudo	Objetos customizados para fluxos não transacionais	Arquiteto corporativo
9. Licenciamento	Nenhum modelo de licenças de cinco anos no business case	CFO
10. Programa só de TI	O comitê de direção não tem líder de operações nem de finanças	Patrocinador

Implantação. Para novos programas SAP, o padrão é o RISE with SAP no SAP Cloud ERP Private ou o SAP GROW na edição pública (SAP Cloud ERP) para empresas de médio porte. Novas implantações on-premise são raras. Os clientes de ECC enfrentam o fim da manutenção padrão em 31 de dezembro de 2027, o que encurta o tempo disponível para corrigir os erros 2, 3 e 7.

Clean Core. A SAP agora classifica as extensões em quatro níveis de Clean Core, de A (somente APIs liberadas, side by side no BTP ou dentro do próprio sistema com ABAP Cloud) a D (não limpo). A edição pública só permite o nível A, o que força a conversa por trás do erro 2. A edição privada ainda permite extensões clássicas, então a disciplina precisa vir da governança. O código customizado clássico é o que faz de cada atualização um projeto. Meu texto sobre a estratégia de Clean Core vai mais fundo.

IA nas ferramentas de entrega. O Joule agora está no SAP Cloud ALM e no SAP Activate Roadmap Viewer, e o SAP Build Code usa o Joule no desenvolvimento de extensões. Pergunte aos parceiros como as ferramentas de IA aparecem na tabela de valores deles. Se não aparecem, ou o preço está alto ou a economia está indo para a margem deles.

Ferramentas de ciclo de vida. O SAP Cloud ALM é a ferramenta de gestão do ciclo de vida para programas em nuvem. O Solution Manager 7.2 sai da manutenção padrão no fim de 2027, então os ambientes que rodam os dois precisam de um plano para a transição.

Os dez erros não mudaram. O custo de cometê-los, sim. Em um programa RISE, a decisão sobre Clean Core, o modelo de implantação e o modelo de FUE são todos definidos nas primeiras semanas de mobilização. A janela para influenciá-los é curta.

Por que os esforços de modernização de ERP ficam aquém depois do go-live?

A maioria das equipes planeja até o go-live e para. Ninguém é dono das melhorias, do feedback, das correções de processo nem do backlog. A dissolução do comitê de direção no go-live é o sinal de problema mais confiável. Financie de 6 a 12 meses de governança pós-go-live desde o primeiro dia.

Qual é o risco de copiar processos legados para um ERP novo?

O sistema novo herda as ineficiências antigas a um custo maior. Especificamente nas migrações para S/4HANA, o código customizado e os jobs batch construídos para as tabelas do ECC muitas vezes não funcionam, de modo que a migração pode ser tecnicamente limpa enquanto a lógica de negócio está quebrada.

Como a má qualidade dos dados prejudica uma modernização de ERP?

Fornecedores duplicados, dados mestre inconsistentes, códigos legados e registros incompletos passam todos para o sistema novo, a menos que alguém os limpe antes. Os relatórios quebram, os usuários deixam de confiar nos números e a limpeza com o sistema em produção leva meses.

Por que a gestão de mudanças é tão frequentemente subestimada em projetos de ERP?

Porque ela não aparece em um plano de projeto como a configuração aparece. Os executivos presumem que algumas sessões de treinamento bastam. Gestão de mudanças é preparar as pessoas para o que realmente vai mudar no trabalho diário delas, antes do go-live. Ferramentas de adoção digital como o WalkMe, hoje da SAP, ajudam com a orientação dentro do aplicativo, mas não substituem a explicação do porquê.

Por que os sistemas legados continuam rodando anos depois do go-live do ERP?

Porque ninguém planejou desligá-los. Todos estão focados em colocar o novo ERP no ar, e os sistemas antigos continuam ligados por conformidade, por consulta ou por comodidade. A desativação precisa estar no escopo desde o primeiro dia, com o jurídico e a conformidade envolvidos.

Como o RISE with SAP e o Clean Core mudam esses erros?

Na edição pública, as regras de Clean Core tornam impossível uma customização profunda, o que força a conversa de processo por trás do erro 2. Na edição privada, as extensões clássicas ainda são permitidas, então o Clean Core depende de governança. A integração passa para o SAP Integration Suite à medida que a manutenção do PI/PO termina. O licenciamento vira uma questão de crescimento de FUE. A desativação fica mais urgente porque manter sistemas legados em paralelo soma custo a uma assinatura plurianual.