
Índice
A modernização de ERP em 2026 significa três decisões tomadas em ordem: o que o seu ERP deve parar de fazer, quão limpo você vai manter o core e se os seus dados são bons o bastante para a IA ser útil. Para os clientes SAP, há uma data firme por trás das três: a manutenção padrão do ECC termina em 31 de dezembro de 2027, com manutenção estendida paga até o fim de 2030.
Este texto é para CIOs, CFOs e arquitetos corporativos que terminaram a análise e agora precisam executar. Ele cobre as forças que impulsionam a ação, a arquitetura de espinha dorsal com satélites, o clean core, a lacuna de governança, a prontidão para IA e uma tabela de riscos para os próximos 18 meses.
Em 2024, a maioria dos líderes ainda ganhava tempo: estudava os prazos do ECC, debatia híbrido versus migração completa, rodava testes em sandbox sem se comprometer. Essa janela se fechou. A dívida técnica nos ambientes ECC e Oracle E-Business Suite deixou de ser teórica. Ela aparece em testes de regressão que falham depois de atualizações, em apontamentos de auditoria sobre código customizado que ninguém assume e em dados que levam 12 horas para ir do sistema de planejamento ao de execução.
O prazo. Depois de 2027, os clientes de ECC podem comprar manutenção estendida até o fim de 2030, por um valor mais alto. Além disso, a SAP oferece uma opção de transição para o ERP private edition entre 2031 e 2033, mas só pelo RISE, e a SAP deixa claro que é uma oferta de transição paga, não uma extensão de manutenção. Enquanto isso, uma pesquisa do Gartner divulgada pelo The Register constatou que, no fim de 2024, apenas cerca de 39% dos aproximadamente 35.000 clientes de ECC da SAP haviam comprado ou assinado licenças do S/4HANA. Licenciado não é o mesmo que migrado. O mercado de parceiros ficará apertado.
O modelo de orçamento. O ERP em nuvem desloca o gasto de licenças em capex para assinaturas. Isso parece mais limpo. Na prática, os CFOs acham os custos de nuvem menos previsíveis: no RISE with SAP e no SAP GROW, o crescimento de Full User Equivalent (FUE), os serviços adicionais e o custo extra de integração somam valores que não estavam no business case original.
Fragmentação em finanças e supply chain. As equipes financeiras usam IA em contas a pagar e a receber enquanto os processos de auditoria ainda seguem modelos criados para outra época. As cadeias de suprimentos estão parcialmente modernizadas: SAP IBP para planejamento, um gerenciamento de armazém antigo para execução, Ariba para compras, mas recebimentos de mercadorias manuais. O gargalo não é a tecnologia. São as junções entre os sistemas.
O ERP é uma camada, não a pilha inteira. O ServiceNow conduz a orquestração de processos em muitas empresas, o Salesforce conduz os fluxos de clientes, o Workday ou o SuccessFactors conduz o ciclo de vida de RH. O ERP virou a espinha dorsal financeira, não o hub único de processos que foi vendido como tal nos anos 1990.
O modelo com que a maioria dos arquitetos corporativos trabalha hoje é uma espinha dorsal financeira (SAP S/4HANA ou Oracle Fusion) cercada por plataformas especializadas.
| Camada | O que fica aqui | O que não fica |
|---|---|---|
| Espinha dorsal financeira | Razão geral, controladoria, compras, estoque, execução da manufatura, fechamento legal | Aprovações de workflow, CRM, gestão da força de trabalho, análises |
| Workflow | ServiceNow para processos de TI e de operações, aprovações, gestão de mudanças | Registro transacional |
| Engajamento do cliente | Salesforce ou SAP Sales and Service Cloud | Processamento financeiro |
| Força de trabalho | Workday ou SAP SuccessFactors | Transações operacionais |
| Análises | SAP Business Data Cloud, SAP Analytics Cloud, Power BI, Snowflake | O sistema de registro |
A separação é deliberada. Forçar tudo de volta para o SAP aumenta o atrito, atrasa as atualizações e confunde a responsabilidade. Enfiar CRM, workflow, análises e EHS em um único sistema foi o que tornou os programas anteriores tão penosos.
A pergunta a fazer: pelo que o ERP não deve mais responder? Se você a pular, vai reconstruir o mesmo monolito em uma licença mais nova. Meu texto sobre modernização de ERP com SAP e ServiceNow mostra uma versão dessa divisão.
Em agosto de 2025, a SAP substituiu seu modelo de extensibilidade de três camadas por quatro níveis de clean core. O nível A usa apenas APIs liberadas e estáveis, side-by-side no SAP BTP ou dentro do sistema com ABAP Cloud. O nível B usa APIs e tecnologias clássicas que a SAP ainda considera limpas. O nível C alcança objetos internos e exige medidas especiais. O nível D não é limpo.
A edição pública (SAP Cloud ERP, vendida como SAP GROW) só permite o nível A, de modo que a plataforma impõe o clean core e absorve dois grandes releases por ano. A edição privada (SAP Cloud ERP Private, no RISE) e o on-premise ainda permitem extensões clássicas, então ali o clean core depende de governança. Em qualquer caso, um sistema muito customizado transforma cada upgrade em um projeto e cada teste de regressão em uma crise.
O que o clean core exige de você:
- Tire do core o código customizado sem uso. Todo programa customizado que você mantém é algo a testar em cada upgrade.
- Construa novas extensões no nível A sempre que puder: no SAP BTP, com o SAP Build ou dentro do sistema com ABAP Cloud.
- Use processos padrão onde quer que a SAP os entregue e customize apenas onde a regulação ou uma diferença competitiva real exigir.
A resistência é cultural, não técnica. Líderes de negócio que dependeram de código customizado por 15 anos ainda esperam que ele seja “simplesmente reimplementado”. Essa expectativa é de 2012.
Um ambiente ECC típico carrega de 1.500 a 3.000 objetos customizados, com base nas avaliações que conduzi em manufatura e serviços, e só cerca de um quarto mostra uso ativo no negócio. O resto é peso histórico que infla o custo da migração e cria exposição em auditoria.
A medida prática: rode agora uma varredura de uso. Descontinue o que está inativo. Publique uma lista de cortes antes de o desenho começar. As equipes que planejam o clean core desde a primeira semana têm experiências de upgrade muito melhores do que as que o tratam como uma restrição a contornar. Meu artigo sobre estratégia de clean core detalha o método.
Com o ERP como uma camada entre várias, as questões de responsabilidade se tornam críticas. Quem é dono de:
- A API entre o Salesforce e o ERP?
- Um workflow que atravessa o SAP e o ServiceNow?
- Prioridades de mudança conflitantes quando os dois sistemas precisam de atualização ao mesmo tempo?
Já vi isso atrasar go-lives em meses. As equipes não percebem que estão travadas até que o teste de integração exponha a sobreposição.
Em um caso, cinco sistemas mexiam no mesmo registro mestre de fornecedor. Cinco. Ninguém tinha um documento de responsabilidade sobre os dados mestre, e ninguém havia definido quem podia alterar o quê, em qual sistema. Isso não é uma falha de tecnologia. É uma falha de governança que a tecnologia expôs.
Modernização não é sobre ferramentas brilhantes. É sobre subtração estratégica. Decidir pelo que o ERP não deve mais responder e ser honesto sobre quem é dono das fronteiras.
O valor da IA no ERP é real, mas depende da qualidade dos dados e de uma arquitetura limpa. O Joule agora abrange o S/4HANA, o SuccessFactors, o Ariba e outros produtos SAP, e os agentes da SAP rodam sob assistentes Joule. Os casos de uso com agentes no SAP BTP estão entrando em produção, não são slideware. Todos dependem de dados limpos, consistentes e estruturados.
Se os seus dados estão duplicados, com codificação inconsistente ou em tabelas customizadas que o S/4HANA não reconhece, a IA não tem nada confiável com que trabalhar. As equipes financeiras que aplicam IA em contas a pagar descobrem isso rápido, quando faturas são associadas ao fornecedor errado porque o cadastro mestre de fornecedores nunca foi limpo.
A sequência que funciona: primeiro o clean core, depois a governança de dados, em seguida as análises e por último a IA. Pular etapas não acelera nada. Só empurra o problema para mais tarde.
- Definir a fronteiraDecidir o que o ERP deve parar de fazer
- Limpar o coreAposentar o código sem uso, construir o novo no nível A
- Governar os dadosUm dono por objeto de dados
- Construir as análisesSAP Business Data Cloud, SAC ou Power BI sobre dados governados
- Adicionar IAJoule e agentes sobre uma base confiável
IA com algo confiável com que trabalhar
| Risco | Sinal | Resposta prática |
|---|---|---|
| Pressão do prazo do ECC | A manutenção padrão termina em dezembro de 2027; a maioria dos clientes de ECC não havia licenciado o S/4HANA até o fim de 2024 | Feche agora os planos de recursos com parceiros; as diárias sêniores nos EUA já ficam entre US$ 1.800 e US$ 3.500 |
| Dívida de código customizado | De 1.500 a 3.000 objetos customizados, cerca de um quarto em uso ativo | Rode varreduras de uso, publique uma lista de cortes, inicie sprints de aposentadoria |
| Disrupção de releases | Os releases colidem com o fechamento financeiro e com os picos da cadeia de suprimentos | Defina janelas de release longe do fechamento; automatize os testes de regressão |
| Risco de migração de dados | A harmonização tardia gera defeitos que as equipes rotulam como bugs | Dimensionamento antecipado; verificações de dados bancários, fiscais e de compliance antes do congelamento do desenho |
| Lacunas de responsabilidade na integração | Cinco ou mais sistemas mexendo em dados mestre compartilhados | Publique uma matriz de autoridade; um dono por objeto de dados |
| Duas ferramentas de ciclo de vida | Ambientes híbridos rodam Solution Manager e SAP Cloud ALM em paralelo | O Cloud ALM como padrão para programas em nuvem; a manutenção padrão do Solution Manager 7.2 termina no fim de 2027 |
Para a versão desses riscos no nível da entrega, veja dez erros de modernização de ERP a evitar e, para os próprios caminhos de migração, o guia de migração do ECC para o S/4HANA.
O que é clean core no SAP S/4HANA?
Manter o S/4HANA o mais próximo possível do padrão e colocar as extensões onde os upgrades não consigam quebrá-las. Desde agosto de 2025, a SAP classifica as extensões do nível A (apenas APIs liberadas, no SAP BTP ou dentro do sistema com ABAP Cloud) ao nível D (não limpo). A razão de negócio é a proteção dos upgrades: um sistema limpo absorve releases em dias, enquanto um sistema muito customizado transforma cada um em um projeto.
O que é a arquitetura de espinha dorsal com satélites para o ERP?
O ERP (SAP S/4HANA ou Oracle Fusion) cuida do que foi feito para cuidar: registros financeiros, estoque, compras, transações de manufatura e relatórios legais. Plataformas especializadas cuidam do resto: ServiceNow para workflow, Salesforce para engajamento do cliente, Workday ou SuccessFactors para RH e plataformas de análise para os insights. Forçar tudo isso para dentro do ERP cria um monolito que atualiza devagar e exige muita customização.
Como as empresas devem encarar o prazo de 2027 do SAP ECC?
Comece com o SAP Readiness Check. Ele mostra o volume de código customizado, as dependências de add-ons e o dimensionamento dos dados, os três fatores que decidem se você vai de brownfield, greenfield ou abordagem seletiva. Migrações corporativas complexas costumam levar de 18 a 24 meses da avaliação ao go-live; por isso, se você ainda não escolheu uma abordagem e não começou as conversas com parceiros, um go-live em 2027 já é apertado. A manutenção estendida até 2030 custa mais e compra tempo, não inovação.
Quando a IA é valiosa na modernização de ERP e quando não é?
Quando os dados são limpos, consistentes e estruturados e o processo tem regras claras: automação de contas a pagar, previsão de demanda e detecção de anomalias em transações financeiras são casos comprovados. A IA não é um atalho para contornar dados ruins ou lacunas de governança. Decisões tomadas sobre entradas ruins são mais difíceis de detectar do que erros manuais. Clean core, governança de dados e processos estáveis vêm primeiro.
Quais são os maiores erros que as empresas cometem na modernização de ERP?
Tratá-la como um projeto de tecnologia, de modo que o debate sobre clean core está perdido antes de os líderes de negócio entrarem na sala. Começar a governança de dados depois do desenho, quando decisões tomadas na primeira semana teriam poupado meses de testes. Não definir o que o ERP deve parar de fazer, e assim o escopo do core cresce por padrão, que é como o último monolito foi construído.
Quanto custa a modernização de ERP?
Uma conversão brownfield de ECC para S/4HANA em uma empresa de médio porte costuma custar de US$ 2 milhões a US$ 8 milhões em implementação, além da assinatura contínua. Programas corporativos de escopo global, com muita customização e muitas entidades, podem custar de US$ 20 milhões a mais de US$ 100 milhões. Modele também a integração, os testes e o suporte operacional, além das licenças, e, no RISE e no SAP GROW, modele o crescimento de FUE ao longo do prazo do contrato.
Próximo passo
Está conduzindo um programa de ERP agora?
Se este artigo tocou num programa em que você está envolvido agora, uma conversa de 30 minutos costuma render mais do que outra semana de análise interna.




