Clean core é a ideia mais repetida e menos compreendida das conversas sobre S/4HANA. Ela costuma ser apresentada como uma regra moral — “não modifique o padrão” — e recebida como o que sempre foi na prática: uma recomendação que o projeto abandona na primeira exigência que o padrão não atende.

Vale trocar o enquadramento. Clean core não é pureza: é uma escolha de onde colocar a sua diferença. Toda empresa precisa de coisas que o padrão não faz. A pergunta é se isso vai morar dentro do núcleo, onde vai brigar com cada atualização pelos próximos dez anos, ou ao lado dele, ligado por pontos definidos que a fornecedora se compromete a manter.

Por que isso importa agora, e não antes

Durante muitos anos, modificar o núcleo era caro mas administrável: a empresa fazia o upgrade a cada quatro ou cinco anos, contratava um projeto, ajustava as modificações e seguia.

Duas coisas mudaram. A primeira é a cadência: em nuvem, atualização deixou de ser evento e virou rotina — o que era um projeto quadrienal passou a ser algo que acontece com frequência, e cada modificação no núcleo vira atrito recorrente. A segunda é que o custo se deslocou: antes ele aparecia num orçamento de upgrade, agora aparece diluído em manutenção, teste de regressão e adiamento de atualização — despesa que ninguém consegue apontar, mas que todo mundo paga.

Há um efeito colateral que aparece cedo: quem tem núcleo modificado adia atualização. E quem adia atualização não recebe o que vem nela — inclusive as adaptações de legislação e as funcionalidades novas que justificaram a mudança para o S/4.

As quatro camadas do clean core

Falar em “clean core” no singular confunde, porque são quatro disciplinas diferentes, com dificuldade e retorno diferentes.

Código. Sem modificação do padrão e sem leitura direta de tabela. Extensão acontece pelos pontos previstos e o acesso ao dado é por interface liberada, que tem compromisso de compatibilidade. É a camada mais visível e a que o time técnico entende primeiro.

Dados. Núcleo limpo também é núcleo que não carrega o que não precisa. Histórico infinito na base quente encarece licença, deixa a atualização mais lenta e o teste mais caro. É a mesma conversa de arquivamento e volume de dados.

Integrações. Sistema externo que lê tabela do ERP ou grava direto no banco cria um acoplamento invisível que quebra em atualização — e quebra sem aviso, porque ninguém registrou aquela dependência. Integração limpa passa por interface publicada e versionada.

Processos. A camada mais desconfortável. Parte do que se customiza existe porque o processo da empresa foi desenhado em volta de uma limitação que já não existe. Rever o processo às vezes elimina a customização inteira — e essa conversa é de negócio, não de TI.

Como chegar lá, sem parar a empresa

Ninguém migra para clean core num salto. O caminho que funciona tem seis passos e a ordem importa mais que a velocidade.

1. Inventariar o que existe. Modificações, extensões, desenvolvimentos e integrações, com dado de uso ao lado. Sem isso, todo o resto é conversa. É o trabalho que descrevemos em inventário de WRICEF com IA.
2. Cortar pelo uso. O que ninguém executa não precisa ser convertido em nada — precisa de aposentadoria. Costuma ser a maior redução de escopo disponível.
3. Perguntar se o padrão já resolve. Muita customização antiga existe porque, na época, o padrão não atendia. Boa parte já é coberta hoje. Verificar antes de reescrever evita reescrever à toa.
4. Classificar o que sobra por dificuldade. Extensão que cabe nas ferramentas de configuração assistida é uma coisa; extensão que exige desenvolvimento ao lado do núcleo é outra; e o que só funciona modificando o padrão precisa de decisão consciente, com prazo para sair.
5. Mover em ondas, com medição. Uma área por vez, com indicador antes e depois: quantas modificações restam, quantas integrações passaram a usar interface publicada, quanto tempo leva o teste de regressão.
6. Fechar a porta. A parte que quase todo projeto esquece. Sem regra de arquitetura e sem alguém que a aplique na aprovação de cada demanda nova, o núcleo volta a sujar em dois anos — e a limpeza terá sido um gasto sem legado.

Como saber se está funcionando

Clean core precisa de indicador, senão vira discurso. Quatro medidas dizem quase tudo:

• Modificações no padrão que ainda existem, e o processo que cada uma atende.
• Objetos que leem tabela direto em vez de usar interface liberada.
• Integrações fora do padrão publicado — as que vão quebrar sem avisar.
• Tempo e custo do teste de regressão a cada atualização. Este é o indicador honesto: se o clean core está avançando, este número cai.

O último é o mais útil justamente porque é o mais difícil de maquiar. Núcleo limpo se traduz em atualização que passa com menos gente e menos noite.

O que muda quando o núcleo está limpo

Atualizar deixa de ser projeto. É a promessa toda: receber melhoria e adaptação legal na cadência da fornecedora, sem negociar prazo interno cada vez.

O custo fica visível. A diferença passa a morar em componentes identificáveis, com dono e ciclo de vida próprios, em vez de diluída dentro do núcleo onde ninguém sabe medir.

A empresa recupera a opção de mudar. Processo que vive fora do núcleo pode ser alterado sem tocar no ERP — e essa flexibilidade é o argumento de negócio que sustenta o investimento, muito mais que qualquer conversa técnica.

O limite honesto: clean core não é de graça e não se conquista de uma vez. Exige decisão de arquitetura, disciplina de aprovação e disposição para rever processo — três coisas que dependem de gente, não de ferramenta. O que a tecnologia faz é mostrar o tamanho do problema e reduzir o custo de cada passo.

Se a sua conversão ainda está sendo desenhada, a decisão de abordagem vem antes: o guia de brownfield, greenfield e bluefield na Inove Academy mostra o que cada caminho exige — e a abordagem seletiva é justamente a que permite chegar ao S/4 já com o núcleo mais limpo do que ele estava. Para a parte de dados dessa mesma decisão, veja saneamento de dados mestres.