Nos últimos meses, o conceito de clean core voltou ao centro das discussões no mundo SAP. A SAP reforçou diretrizes, ajustou definições e, como costuma acontecer, o mercado reagiu com mais perguntas do que respostas. Entre elas, uma aparece com frequência:
“Se eu estender o meu SAP, eu deixo de estar em clean core?”

Essa pergunta revela um problema maior. Não se trata de uma questão técnica, mas conceitual.

Criou-se um mito pernicioso de que clean core significa não mexer no sistema, não criar objetos Z, não estender processos. Como se qualquer personalização fosse, automaticamente, um erro. Isso simplesmente não é verdade.

O clean core não nasceu para impedir a evolução do negócio. Ele nasceu para viabilizá-la de forma sustentável.

O ponto central não é se você estende o SAP, mas como você faz isso. O problema nunca foi o objeto Z em si. O problema é misturar extensibilidade com core, criando dependências profundas que tornam atualizações longas, caras e arriscadas. Quando isso acontece, o S/4HANA perde o sentido, porque um ERP que não consegue ser atualizado com frequência deixa de entregar valor ao longo do tempo.

O verdadeiro conceito de clean core parte de uma separação clara: o core precisa permanecer estável, aderente aos padrões e preparado para atualizações constantes.
A extensibilidade precisa existir, porque o negócio muda, os processos evoluem e o software não é um produto estático. Mas ela precisa estar desacoplada, organizada e governada.

Quando isso acontece, algo importante muda. Atualizar deixa de ser um evento traumático e passa a ser um processo natural. A TI deixa de ser um gargalo e passa a ser um habilitador.

Existe ainda um segundo mito, menos visível, mas igualmente relevante: o de que eficiência em desenvolvimento depende apenas de pessoas muito boas escrevendo código. Pessoas excelentes são fundamentais, mas há um limite estrutural nesse modelo. Desenvolvimento artesanal, feito sempre do zero, cobra um preço alto ao longo do tempo. Não apenas em custo direto, mas em manutenção, retrabalho e velocidade de adaptação.

Inovação de verdade acontece quando um processo inteiro se torna mais eficiente, não quando apenas se executa o mesmo processo mais rápido.

É exatamente isso que caracteriza uma inovação, ou seja, torna um produto patenteável. Não é fazer mais passos, nem tornar o processo mais complexo. É reduzir drasticamente etapas, mantendo qualidade, governança e aderência a padrões reconhecidos.

Quando um método transforma um processo inteiro, trazendo ganhos claros para a comunidade e para o mercado, ele se torna patenteável. Então, deixa de ser a opinião do Rogerio de que o produto é inovador, ele ganha um reconhecimento formal de eficiência e inovação. Em outras palavras, ele recebe uma chancela, um selo que comprova que ele é realmente inovador: uma patente.

No desenvolvimento de software corporativo, isso significa sair do modelo “from scratch” eterno e caminhar para um modelo em que criação e evolução acontecem com a mesma fluidez. Onde o software acompanha o negócio ao longo de toda a sua vida útil, sem perder velocidade, sem aumentar exponencialmente o custo total de propriedade e sem comprometer o clean core.

No fim das contas, clean core não é um freio. Ele pode ser um acelerador, bastando que seja bem compreendido. Ele exige maturidade técnica, clareza conceitual e, principalmente, a disposição de abandonar mitos confortáveis.

O maior risco hoje não é estender o SAP. É deixar de evoluir por medo de fazê-lo da maneira errada.