Os números que a indústria de implementação SAP tem produzido nos últimos anos deveriam ser lidos com mais atenção por quem está planejando a migração para o S/4HANA. Um estudo da Horváth Partners com mais de 200 executivos envolvidos em projetos de migração revelou que 65% não atingiram as metas de qualidade estabelecidas, 60% sofreram atrasos médios de 30% além do cronograma original e 55% ultrapassaram o orçamento previsto. Apenas 8% das empresas concluíram o projeto no prazo.
A migração para o S/4HANA é, por natureza, uma ruptura arquitetural. O banco de dados in-memory HANA elimina camadas de agregação que existiam no ECC, simplifica o modelo de dados e permite processamento em tempo real que antes demandava rotinas noturnas. O problema é que boa parte das empresas chegou ao S/4HANA com ambientes altamente customizados, ou seja, processos desenhados ao longo de anos para compensar as limitações do sistema anterior ou para atender particularidades operacionais que nunca foram questionadas de frente.
Quando esses processos são migrados sem revisão, o que acontece é uma espécie de tradução literal: o fluxo antigo é recodificado no novo ambiente com ajustes pontuais para funcionar na nova plataforma. O resultado é um sistema tecnicamente mais moderno, mas operacionalmente idêntico ao anterior. As automações que o S/4HANA permite ficam represadas atrás de workflows que não foram concebidos para aproveitá-las.
Essa questão, inclusive, foi refletida em uma pesquisa da SAPinsider, que apontou que o principal motivador declarado pelas empresas para migrar ao S/4HANA é justamente a oportunidade de corrigir processos mal configurados em implementações anteriores do ECC, o que indica que o problema é amplamente reconhecido, mesmo que raramente enfrentado na prática.
A metodologia SAP Activate, adotada como referência para implementações de S/4HANA, parte de um princípio que muitas empresas resistem a aceitar: o chamado fit-to-standard. A ideia é que, antes de customizar, a empresa deveria questionar se seus processos precisam mesmo ser diferentes do padrão SAP, ou se essa diferença existe apenas por inércia histórica. No Brasil, onde a cultura de customização de ERP é profunda, esse questionamento costuma gerar atrito. Mas é exatamente nesse atrito que mora a oportunidade.
A armadilha da customização acumulada
Ao longo de uma ou duas décadas de uso do ECC, empresas constroem camadas de desenvolvimentos específicos – Z-reports, enhancements, BAdIs – para resolver problemas que o sistema padrão não endereçava naquele momento.
Com o tempo, esses desenvolvimentos se tornam uma espécie de “patrimônio invisível da operação”: ninguém sabe exatamente o que cada um faz, mas ninguém tem coragem de desligar nenhum deles. A migração para o S/4HANA é a oportunidade, talvez única em uma geração, de questionar cada uma dessas camadas.
O levantamento técnico que precede qualquer migração bem conduzida deveria incluir uma auditoria funcional dessas customizações, não apenas para verificar compatibilidade técnica com o novo ambiente, mas para avaliar se elas ainda fazem sentido. Em muitos casos, o que o desenvolvimento Z resolvia em implementações anteriores já está coberto nativamente pelo S/4HANA atual. Em outros, o processo que aquele desenvolvimento sustentava simplesmente deixou de ser relevante. Mantê-lo na nova plataforma significa pagar para conservar ineficiência.
Outro dado que contextualiza bem esse problema vem de uma pesquisa da Syniti com organizações britânicas e irlandesas em processo de migração: 77% relataram que a gestão de dados representou um desafio significativo na transição do ECC para o S/4HANA, e apenas 12% afirmaram ter uma estratégia de dados cobrindo toda a organização. Esse número revela algo mais profundo do que um problema técnico de migração de dados; aponta que os processos que geravam e consumiam esses dados nunca foram suficientemente mapeados ou governados.
O argumento financeiro para o redesenho de processos durante a migração é direto: o custo marginal de revisar um fluxo dentro do projeto é significativamente menor do que fazê-lo após o go-live, quando o sistema já está em produção e qualquer mudança gera impacto operacional. A janela de maior abertura organizacional para mudança é exatamente o período de transição. Depois que o novo ERP entra em operação, a tendência é de estabilização, e com ela, a resistência a qualquer nova alteração.
O Instituto Prosci, referência global em gestão de mudanças organizacionais, identificou que entre 75% e 80% dos projetos de transformação não entregam os benefícios esperados por falhas de change management, o que na prática significa planejamento inadequado, comunicação insuficiente ou falta de engajamento das partes envolvidas.
No contexto de uma migração de ERP, isso se traduz em processos implantados sem adoção real, usuários que contornam o sistema e fluxos que voltam a ser executados em planilhas paralelas, exatamente como acontecia antes.
O papel do outsourcing na transformação contínua
Um equívoco comum na narrativa sobre migração de ERP é tratá-la como um projeto com começo, meio e fim. O go-live é, na prática, o início de uma nova fase, e não o encerramento de um ciclo. O S/4HANA é uma plataforma viva, com atualizações frequentes, novas funcionalidades e integrações que evoluem continuamente.
Dados da associação alemã de usuários SAP (DSAG) mostram que 48% dos usuários já aderiram ou planejavam aderir ao modelo RISE with SAP em 2025, ante apenas 16% no ano anterior, o que sinaliza uma aceleração expressiva no ritmo de adoção e na demanda por suporte contínuo à plataforma.
Manter uma equipe interna capaz de acompanhar esse ritmo de evolução é economicamente inviável para a maioria das organizações. É nesse ponto que o outsourcing de TI se reposiciona como elemento estratégico, não como suporte reativo, mas como governança contínua da plataforma.
Empresas que encaram a migração para o S/4HANA como uma janela para repensar como operam saem do processo com um ativo muito mais valioso do que um ERP atualizado. Saem com processos mais enxutos, equipes mais capacitadas e uma plataforma configurada para apoiar decisões — não apenas registrá-las. Esse é o retorno real do investimento. E ele depende de uma decisão que precisa ser tomada antes do primeiro dia de projeto: a de que essa migração não vai ser só tecnológica.
*Por Claudio Costa, Head da Selbetti Business Consulting.
