SAP Clean Core: o que significa, níveis A a D e governança

Clean Core da SAP significa manter o seu sistema S/4HANA tão próximo do padrão SAP quanto o seu negócio permitir. Tudo o que você acrescenta é construído por interfaces que a SAP liberou e se comprometeu a manter estáveis, para que os upgrades não quebrem nada.

Resposta curta: Clean Core é uma disciplina sobre como você estende e governa o SAP. A lógica customizada fica on-stack com ABAP Cloud ou side-by-side na SAP BTP, e a SAP classifica cada extensão do nível A (o mais limpo) ao nível D (modificações a remover). O ganho são upgrades mais rápidos: já vi empresas reduzirem em 40% o prazo dos seus upgrades dessa forma.

Se o seu sistema está cheio de modificações em objetos padrão da SAP, cada release vira um projeto de regressão. Se a sua lógica customizada fica atrás de interfaces liberadas, os upgrades viram manutenção de rotina.

Já vi empresas reduzirem em 40% o prazo dos upgrades aplicando os princípios de Clean Core. Elas conseguiram isso mantendo as customizações no mínimo e governando as que mantiveram.

Em 2024, uma empresa europeia de bens de consumo substituiu sua lógica de preços legada por um app Fiori modular construído fora do core, na SAP BTP. Isso eliminou por completo os testes de regressão dessa lógica.

Você ainda pode customizar um ERP com Clean Core. A customização precisa usar interfaces que a SAP liberou e se comprometeu a manter estáveis. A SAP oferece duas formas de fazer isso:

• On-stack, com ABAP Cloud. As extensões rodam dentro do S/4HANA, mas usam apenas APIs e pontos de extensão liberados.
• Side-by-side, na SAP BTP. As extensões rodam como aplicações separadas e se comunicam com o S/4HANA por APIs ou eventos.

A SAP descreve sua abordagem como BTP-first, escolhendo caso a caso. Na minha experiência, onde o código roda importa menos do que saber se o requisito precisa mesmo de código.

Um core sujo é familiar para quem operou ECC: programas padrão modificados, tabelas Z gravadas diretamente, interfaces que leem as estruturas internas da SAP, ampliações implícitas que ninguém documentou. Nada disso estava errado quando foi construído. Só não foi construído para um sistema que recebe upgrade a cada um ou dois anos.

Também falo sobre este tema em um vídeo no meu canal do YouTube (em inglês).

A SAP organiza o Clean Core em torno de cinco princípios orientadores. É assim que a SAP enquadra cada um, e é isso que eu olho primeiro:

Princípio	O que a SAP quer dizer	O que eu verifico primeiro
Processos	Ficar o mais próximo possível do processo padrão SAP	Quais variantes de processo existem só porque «sempre fizemos assim»
Extensibilidade	Extensões desacopladas do core por APIs liberadas, com governança sobre qual opção é usada	Quanto código customizado existe, quanto é usado e em que nível está
Dados	Dados limpos e em conformidade, com um modelo de governança estabelecido	Dados mestre duplicados e incompletos, campos customizados que ninguém sabe explicar
Integrações	Conexões padronizadas e seguras, construídas sobre tecnologias suportadas	Interfaces ponto a ponto que leem tabelas diretamente
Operações	Governança, pessoas, processos e ferramentas que mantêm os outros quatro no lugar	Quem aprova uma extensão, e o que impede a próxima modificação

A maioria das equipes começa e termina pela extensibilidade, porque é a mais fácil de medir. Na minha experiência, processos e dados causam mais atraso. O código customizado costuma ser o sintoma, e o processo por trás dele é a causa.

Em agosto de 2025, a SAP substituiu o seu modelo anterior de extensibilidade em três camadas pelo conceito de níveis de Clean Core. Cada extensão é avaliada pela forma como é construída, pelo grau de desacoplamento do core e pela segurança com que sobrevive a um upgrade. Se você ler material antigo da SAP que fala em camadas, foi isso que o substituiu.

Nível ANível BNível CNível D

O que utilizaNível AApenas interfaces públicas liberadas e estáveisNível BTambém as APIs clássicas da SAPNível CObjetos internos da SAPNível DModificações, gravações em tabelas SAP, ampliações implícitas

Risco de upgradeNível AO mais baixo, garantido por contratos de estabilidadeNível BEm geral estável em upgradesNível CExige verificação a cada upgradeNível DO mais alto

O que decidirNível AO padrão para tudo o que for novoNível BAceitar, com o motivo registradoNível CAceitar com um motivo e reavaliar a cada upgradeNível DRemover primeiro, ou levar para B ou C

Fonte: Conceito de níveis de Clean Core da SAP, SAP News, agosto de 2025

O nível A usa apenas interfaces publicamente liberadas com contratos de estabilidade, construídas com SAP Build, ABAP Cloud ou BTP. O nível B acrescenta as APIs clássicas da SAP. O nível C acessa objetos internos da SAP, e a SAP planeja um changelog para eles que ajude no planejamento de upgrades.

O nível D reúne modificações, gravações em tabelas SAP, ampliações implícitas e outras técnicas que a SAP não recomenda. Isso é mais útil do que o velho debate «limpo ou não limpo», porque permite definir uma meta por objeto. Levar os seus objetos de nível D para B ou C antes de um upgrade já é uma redução real de risco.

ABAP Cloud é o modelo de desenvolvimento ABAP da SAP preparado para a nuvem. Os desenvolvedores usam a versão de linguagem «ABAP for Cloud Development» e só podem construir sobre objetos liberados, APIs públicas e pontos de extensão. Ele nasceu no ambiente ABAP da SAP BTP e hoje está disponível em todas as edições do S/4HANA (FAQ do ABAP Cloud da SAP).

O S/4HANA Cloud oferece três caminhos de extensão. A extensibilidade para key users cobre alterações simples de campos, lógica e interface sem tocar no código SAP. A extensibilidade para desenvolvedores com ABAP Cloud trata da lógica fortemente acoplada, e as extensões side-by-side na SAP BTP tratam de tudo o que deve ficar desacoplado.

A edição define quanta liberdade de escolha você tem:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition e on-premise
Desenvolvimento ABAP	Apenas ABAP Cloud, obrigatório para novos clientes desde o release 2208	ABAP Cloud recomendado desde 2022; ABAP clássico ainda permitido
Alterações no código SAP	Não são possíveis	Possíveis, mas são nível D
Extensões de key user e side-by-side na BTP	Disponíveis	Disponíveis
Quem impõe o Clean Core	O sistema	A sua governança

A minha regra para clientes da Private Edition: trate-a como se fosse Public Edition para tudo o que for novo. O ABAP clássico é permitido, mas cada objeto clássico que você acrescenta hoje é uma decisão que alguém terá de defender no próximo upgrade.

As decisões de Clean Core devem pertencer a uma autoridade de design formada por negócio e TI. A TI sozinha aprovará tudo o que for tecnicamente possível. O negócio sozinho pedirá o seu processo antigo de volta.

É assim que eu montaria essa estrutura:

1. Defina os membros. Os donos de processo de negócio de cada área principal, mais o arquiteto de soluções e o desenvolvedor líder. Os donos de negócio decidem se um requisito é real, e a TI decide como ele será construído.
2. Combine a ordem de preferência antes do início da construção. Primeiro o processo padrão, depois a extensibilidade para key users, depois o nível A em ABAP Cloud ou BTP. O nível B ou C exige uma justificativa por escrito, e o nível D exige um plano de saída.
3. Faça cada pedido de extensão ter um dono e um motivo de negócio. Sem dono, nada é construído. A decisão e o nível aceito vão para um único registro.
4. Coloque uma barreira técnica antes dos transportes. Execute as verificações de Clean Core do ABAP test cockpit de forma programada e barre novo código de nível D antes que chegue à produção.
5. Revise o registro antes de cada upgrade. Aposente o que ninguém usa mais e leve para um nível mais alto tudo o que agora puder chegar lá.

A pergunta nessa mesa costumava ser «por que isso não pode ficar na BTP?». Hoje eu perguntaria «por que isso não pode ser nível A?». Se não puder, a próxima pergunta é qual nível você está aceitando e por quê.

O maior erro de Clean Core que eu vejo é tentar fazer o SAP funcionar como o Oracle. Adote os processos padrão da SAP em vez de reconstruir a lógica de outro sistema em código customizado. Se você ainda está escolhendo entre os dois, eu os comparo em SAP vs Oracle.

Clean Core é um problema de gestão de mudanças antes de ser um problema técnico. Cada objeto customizado existe porque alguém pediu. Removê-lo significa convencer essa pessoa de que o processo padrão é bom o suficiente.

Essa conversa flui melhor quando o negócio vê o novo processo funcionando, e não um slide sobre ele. Também flui melhor quando você testa a afirmação de que um processo é único, porque muitas vezes não é (veja os passos 4 e 5 abaixo).

As competências importam tanto quanto as ferramentas. Uma equipe ABAP que nunca trabalhou com ABAP Cloud ou BTP vai atrasar o programa enquanto aprende. Um fabricante com quem trabalhei fez um programa interno de BTP de três meses antes de começar o seu projeto S/4HANA, e isso valeu a pena em menos surpresas durante a construção.

A conformidade com o Clean Core é o quanto do seu sistema atende aos critérios da SAP nos cinco princípios. Não dá para gerenciá-la sem números, e a SAP oferece três lugares para obtê-los.

1. O ABAP test cockpit. A ferramenta da SAP para verificações no nível do código. Ela mostra quais objetos customizados usam objetos não liberados, modificações ou acesso direto a tabelas.
2. O SAP Readiness Check. Vem com o seu contrato de manutenção e mostra o que uma migração para o S/4HANA vai afetar antes de você se comprometer.
3. O painel da RISE with SAP Methodology, também conhecido como painel de Clean Core. Ele roda no SAP Cloud ALM. A sua visão de sistema verifica a versão do S/4HANA, confirma que as ferramentas de coleta de dados estão ativas e revisa as extensões antes de um upgrade, e a sua visão de operações acompanha KPIs operacionais.

Os números que eu levaria à autoridade de design todo mês são simples. Quantos objetos customizados estão em cada nível, e o nível D está caindo? Quantas exceções estão abertas, e cada uma tem um dono?

Se você me pedisse para avaliar o seu sistema no mês que vem, esta é a ordem que eu seguiria.

1. Descubra o que é usado. Execute o SAP Readiness Check e colete dados de uso do seu código customizado. Em um programa, a análise com a smartShift nos levou de 18.000 objetos customizados para 3.200, porque a maior parte do restante simplesmente não era usada.
2. Classifique o que sobrou nos níveis A a D. Use o ABAP test cockpit para o código. Se você está na RISE, o painel de Clean Core acompanha a partir daí.
3. Decida objeto por objeto. Aposente, leve para uma interface liberada, reconstrua na BTP ou mantenha com uma justificativa documentada. Comece pelo código que roda todos os dias, porque um relatório usado duas vezes por ano por uma equipe regional pode esperar.
4. Traga o negócio para a sala. Uma líder de finanças com quem trabalhei só entendeu o seu novo app Fiori depois de uma demonstração de 45 minutos. Essa sessão poupou duas semanas de idas e vindas no UAT.
5. Questione o «nosso processo é diferente». Em um workshop com a equipe de vendas de uma empresa industrial europeia em 2023, o processo «único» se revelou 80% de administração legada redundante. O SAP padrão melhorou a experiência dos clientes deles assim que as soluções de contorno saíram.
6. Comece cedo o trabalho com dados. Um cliente de varejo do GCC com quem trabalhei em 2024 tinha mais de 15.000 campos customizados para analisar. Na minha experiência, a migração de dados consome de 30 a 40% do esforço de implementação, e o meu guia de custos de implementação SAP mostra onde isso cai no orçamento.
7. Defina a governança antes do go-live. Monte a autoridade de design descrita acima e faça dela o único caminho para uma nova extensão.

Três perguntas aparecem em quase toda conversa que tenho sobre o tema.

O Clean Core é obrigatório na RISE with SAP?

Não como regra geral. Na Public Edition o sistema o impõe, enquanto na Private Edition e on-premise você ainda pode modificar o core.

Nesses casos, o Clean Core é uma escolha de governança que a SAP acompanha pelo painel da metodologia RISE. Se um SI disser que é contratual, peça que mostre a cláusula.

Quanto tempo ainda tenho no ECC?

Para o SAP ERP 6.0 com enhancement packages 6 a 8, a manutenção principal termina em 31 de dezembro de 2027. A manutenção estendida opcional vai até 31 de dezembro de 2030, com custo adicional.

Depois disso, a opção de transição SAP ERP, private edition cobre de 2031 a 2033. Ela se aplica apenas a sistemas grandes já migrados para o SAP ERP, private edition sobre SAP HANA antes do fim de 2030.

Trate 2033 como uma rota de exceção, não como uma data de planejamento. O meu guia de migração do ECC para o S/4HANA aborda as opções de rota.

O Clean Core importa para a AI?

Sim. Manter o padrão SAP ajuda a AI e o Joule a funcionarem melhor, e processos muito modificados são onde eles são mais difíceis de adotar.

A SAP constrói os seus recursos de AI, incluindo o Joule, sobre os seus processos padrão e o seu modelo de dados. O Joule para desenvolvedores gera código ABAP Cloud com base em APIs liberadas. Eu explico como nuvem, AI e Clean Core se encaixam em modernização de ERP.

As equipes que pulam o Clean Core não evitam o trabalho. Apenas o adiam, e ele volta como upgrades bloqueados, maratonas de testes de regressão e código customizado que ninguém entende.

Antes de assinar um contrato de S/4HANA ou RISE, peça ao seu SI que classifique o seu código customizado atual nos níveis A a D. Se ele não conseguir apresentar essa classificação, isso diz algo sobre a estimativa. Agende uma conversa e podemos analisar a sua situação.

O que é Clean Core no SAP?

Clean Core significa manter o S/4HANA próximo do padrão SAP e criar extensões apenas por interfaces que a SAP liberou e se comprometeu a manter estáveis. As extensões rodam on-stack com ABAP Cloud ou side-by-side na SAP BTP. O objetivo é que os upgrades não quebrem a sua lógica customizada.

Quais são os cinco princípios do Clean Core da SAP?

Os cinco princípios orientadores de Clean Core da SAP são processos, extensibilidade, dados, integrações e operações. Os processos ficam próximos do padrão, as extensões usam APIs liberadas e os dados são mantidos limpos sob um modelo de governança. As integrações usam tecnologias suportadas, e as operações cobrem a governança, as pessoas e as ferramentas que mantêm os outros quatro no lugar.

O que são os níveis A, B, C e D do Clean Core da SAP?

Desde agosto de 2025 a SAP classifica as extensões em quatro níveis. O nível A usa apenas interfaces publicamente liberadas e estáveis, o nível B usa também as APIs clássicas da SAP e o nível C acessa objetos internos da SAP. O nível D abrange modificações, gravações em tabelas SAP e ampliações implícitas, e traz o maior risco de upgrade.

O Clean Core é obrigatório na RISE with SAP?

Não como regra geral. O S/4HANA Cloud Public Edition só permite ABAP Cloud e interfaces liberadas, então impõe o Clean Core tecnicamente. Na Private Edition você ainda pode modificar o core, então o Clean Core é uma decisão de governança que a SAP acompanha pelo painel da RISE with SAP Methodology.

O que é ABAP Cloud?

ABAP Cloud é o modelo de desenvolvimento ABAP da SAP preparado para a nuvem. Ele permite apenas objetos liberados, APIs públicas e pontos de extensão, o que mantém o código customizado estável nos upgrades. É obrigatório no S/4HANA Cloud Public Edition para novos clientes desde o release 2208 e recomendado na Private Edition e on-premise desde 2022.

Como medir o Clean Core?

Use o ABAP test cockpit para verificações no nível do código e classifique os objetos customizados nos níveis A a D. Clientes RISE podem acompanhar a adoção no painel da RISE with SAP Methodology, também chamado de painel de Clean Core, no SAP Cloud ALM. Eu acompanho a quantidade de objetos em cada nível, a tendência do nível D e o número de exceções abertas com um dono.

Quem deve ser dono da governança de Clean Core da SAP?

Uma autoridade de design formada por negócio e TI deve ser dona de cada decisão de Clean Core. Os donos de processo de negócio decidem se um requisito é real, e a TI decide como ele é construído e em que nível. Cada exceção é registrada com um dono e revisada antes de cada upgrade.

Quando termina o suporte ao SAP ECC?

Para o SAP ERP 6.0 com enhancement packages 6 a 8, a manutenção principal termina em 31 de dezembro de 2027, com manutenção estendida opcional até 31 de dezembro de 2030, com custo adicional. A opção de transição SAP ERP, private edition vai até 2033 apenas para sistemas grandes elegíveis migrados para o SAP ERP, private edition sobre SAP HANA antes do fim de 2030.