A mensagem que saiu do Sapphire 2026 e vem sendo repetida em toda a base SAP é curta: valor de IA depende de readiness, dado e Clean Core. Dita assim, soa como mais uma boa prática de arquitetura — daquelas que todo mundo concorda e ninguém prioriza.
A tradução técnica é bem menos elegante. Os agentes padrão do S/4HANA — Cash Management, Dispute Resolution e a linha que vem atrás deles — só operam sobre fluxos clean-core-compliant. Se o processo foi customizado dentro do core, o agente padrão simplesmente não se aplica àquele processo. Ele não roda pior: ele não roda.
E no Brasil, entre fiscal, tributário e logística, o processo quase sempre foi customizado dentro do core. É por isso que a conversa sobre Clean Core deixou de ser sobre elegância de código e virou sobre uma pergunta bem mais concreta: a sua arquitetura permite ligar a IA que você acabou de comprar?
O que é Clean Core, em uma frase
Clean Core significa manter o núcleo do ERP aderente ao padrão e mover toda extensão para fora dele — via APIs públicas liberadas pela SAP, eventos e serviços rodando em plataforma separada (o BTP, ou qualquer camada side-by-side de sua escolha). O core executa o processo padrão; a especificidade da sua empresa vive fora, integrada.
O que Clean Core não significa: zero customização. Nenhuma operação real roda sem especificidade — e o Brasil, com sua complexidade fiscal, é caso extremo. A questão não é se você customiza, é onde. Dentro do core, a customização trava upgrade, trava agente e infla o custo de manutenção. Fora do core, ela é um serviço com ciclo de vida próprio, que evolui sem congelar o ERP.
Por que virou pré-requisito de IA: agentes padrão só operam em fluxos padrão
A razão é estrutural, não comercial. Um agente pré-construído pela SAP é treinado e validado contra um processo específico: a tabela padrão, o campo padrão, a máquina de estados padrão, a API padrão. É assim que ele consegue agir com alguma garantia — porque o fornecedor sabe exatamente o que existe do outro lado da chamada.
Quando o seu processo de cobrança tem um campo Z, uma tabela Z e uma user exit que altera a regra de baixa, o agente de Cash Management encontra um mundo que ele não conhece. Ele não tem como saber que o status "liberado" na sua empresa depende de uma validação escrita em ABAP em 2014, dentro do core, sem documentação. O resultado é binário: ou o agente é inaplicável, ou você desenvolve um agente sob medida — o que significa que a promessa de "IA pronta, incluída na licença" virou, silenciosamente, um projeto de desenvolvimento.
Vale a nota de neutralidade: isso não é uma peculiaridade da SAP. Todo fornecedor que embarca agente em produto — Salesforce, Oracle, Microsoft — assume o processo padrão do próprio produto. Padronização é o preço de entrada da IA embarcada, em qualquer plataforma. A SAP só é o caso mais visível porque a base instalada dela é a mais customizada do mercado corporativo.
O caso brasileiro: fiscal, tributário e logística moram no Z-code
Se em qualquer país a base SAP é customizada, no Brasil ela é customizada por necessidade. ICMS-ST, difal, regimes especiais por estado, substituição tributária, nota fiscal eletrônica com layout que muda, CFOP que depende de operação e de destino, obrigações acessórias que se reinventam a cada ano. Nada disso é caprichoso: são anos de camadas fiscais implementadas sob prazo legal — e, na urgência, quase sempre dentro do core, porque era o caminho mais curto.
Some a logística: regras de expedição por CD, roteirização, integração com transportadora, cross-docking, janela de corte. É o segundo bolsão de Z-code da maioria das operações.
O resultado é o retrato conhecido: um core que ninguém tem coragem de atualizar, porque ninguém sabe exatamente o que vai quebrar. A dívida técnica virou dívida operacional — e agora, com a chegada dos agentes, virou também dívida de roadmap: os recursos de IA que você está pagando na licença não alcançam os processos que de fato rodam a empresa.
A conta que o mercado já fez
Os números que circulam nas discussões pós-Sapphire (SAP Community, integradores como SAVIC, materiais de AWS for SAP) apontam para uma faixa consistente:
25% a 35% menos custo anual de AMS para landscapes clean-core-compliant. A razão é simples: menos código proprietário significa menos regressão, menos teste manual, menos consultor especialista em código que só existe na sua empresa.
Onboarding de nova subsidiária em 3 a 6 meses, contra 12 a 18 meses em landscapes cheias de custom code. Esse número é o que costuma mudar a conversa no board, porque ele deixa de ser TI e vira velocidade de M&A e de expansão. Uma empresa que integra uma aquisição em 4 meses compra ativos que uma empresa de 15 meses não consegue disputar.
Como sempre, são faixas de mercado, não garantia contratual — dependem do volume de customização, da qualidade do inventário e da disciplina do projeto. Mas a direção é inequívoca: custom code dentro do core tem preço recorrente, e ele agora inclui o preço de não conseguir ligar a IA.
As 3 saídas para cada customização
Clean Core não é um projeto de "limpar tudo". É uma decisão tomada uma vez por customização, e existem exatamente três saídas:
1. Eliminar — o padrão já faz. É a descoberta mais frequente e a mais barata. Uma parcela relevante do Z-code de qualquer base foi escrita para suprir uma lacuna que o produto padrão já cobre há anos — às vezes desde a versão seguinte àquela em que a customização foi feita. Ninguém voltou para checar. O primeiro entregável de um diagnóstico honesto costuma ser uma lista de customizações que podem simplesmente ser desligadas, com o processo migrando para o fluxo padrão.
2. Mover para fora — extensão side-by-side. A regra é de negócio, é legítima, e precisa continuar existindo — mas não precisa morar dentro do core. Ela vira um serviço externo (BTP ou outra plataforma), consumindo APIs liberadas e reagindo a eventos publicados pelo ERP. O core volta a ser padrão; a regra continua rodando; e agora ela tem deploy próprio, teste próprio e ciclo de vida próprio. É aqui que a arquitetura event-driven entra: o ERP publica o evento (pedido criado, fatura emitida, estoque movimentado), o serviço externo reage, com idempotência e retry — e a operação não depende de leitura direta de tabela nem de um RFC que ninguém pode mexer.
3. Manter e assumir o custo. Saída legítima, desde que consciente. Algumas customizações são vantagem competitiva real, ou o custo de mover é maior que o benefício no horizonte de decisão. O erro não é manter — é manter por omissão, sem saber que aquela decisão custa AMS mais caro, upgrade mais lento e agente que não roda. Manter deve ser uma escolha registrada, com preço na planilha.
A soma dessas três decisões, feita customização por customização, é o roadmap de Clean Core. Não existe atalho, e não existe big bang: existe um inventário e uma fila.
Como a CCX faz: diagnóstico de custom code + extensão fora do core
A CCX trabalha na intersecção exata desse problema: integração SAP ↔ e-commerce com expertise em OData, iDocs e RFC, e arquitetura event-driven com Kafka e RabbitMQ para mover a customização do core para uma camada de serviços integrada — sem parar a operação.
O começo é sempre o mesmo, e não é código: é inventário. Quais customizações existem no core, quais processos elas alteram, quais delas o padrão já cobre hoje, quais precisam virar extensão side-by-side, e quais ficam. Esse diagnóstico (Consultoria em Tecnologia) entrega o mapa, o TCO comparativo e a fila de execução — normalmente em duas a quatro semanas, dependendo do tamanho da landscape.
A execução vai para squads dedicadas com onboarding em 48h e engenheiros sêniores (média de 10+ anos), rodando a metodologia de 6 fases: discovery, arquitetura-alvo, sprints incrementais, QA e testes de carga, go-live assistido com suporte dedicado, evolução contínua. É a mesma trilha que aplicamos em migrações com zero downtime — porque a operação não pode parar enquanto o core é destravado.
Antes de contratar IA para o seu ERP, descubra quanto do seu processo mora fora do padrão. Peça um diagnóstico de integrações SAP com a CCX →
FAQ
O que é Clean Core na prática?
Manter o núcleo do ERP aderente ao padrão e mover as extensões para fora dele — consumindo APIs públicas e reagindo a eventos, em uma camada side-by-side. Na prática, é decidir, customização por customização, se ela é eliminada, movida ou mantida com custo assumido.
Preciso estar no S/4HANA para começar?
Não. O inventário de custom code e o desacoplamento das integrações podem — e idealmente devem — começar antes da migração do core. Feito nessa ordem, o projeto de migração fica menor, mais barato e menos arriscado, porque você não carrega a bagunça para o destino.
Clean Core significa zero customização?
Não. Significa zero customização dentro do core. A especificidade da sua empresa continua existindo — ela só passa a viver como serviço integrado, com deploy e ciclo de vida próprios.
Quanto isso reduz de AMS?
As faixas de mercado discutidas pós-Sapphire apontam 25% a 35% de redução no custo anual de AMS para landscapes clean-core-compliant, além de onboarding de subsidiária em 3–6 meses contra 12–18. São referências de mercado; o número real depende do volume de custom code e da disciplina do projeto.
Dá para fazer sem parar a operação?
Sim — e é justamente por isso que a saída "mover para fora" funciona. A extensão sobe em paralelo, consumindo evento, é validada contra o comportamento atual, e só então a customização do core é desligada. É migração incremental, customização por customização, sem cutover big bang.