Clean core

Clean core no es una moda de SAP; es el marco con el que SAP está empujando implementación, extensibilidad, integración, gobierno y adopción de innovación en Cloud ERP. SAP lo define como un conjunto de principios para diseñar ERPs ágiles, eficientes e “innovation-ready”, manteniendo el sistema lo más cercano posible al estándar y permitiendo extensiones desacopladas y estables.

Qué es clean core, en palabras simples

La idea base es esta: mantener el núcleo de SAP limpio, estable y actualizable, evitando meter lógica custom, modificaciones o integraciones frágiles dentro del core que luego bloqueen upgrades, compliquen soporte y generen deuda técnica. SAP resume esto, especialmente para extensibilidad, como separar estrictamente las extensiones del aplicativo SAP y acceder a objetos de negocio solo mediante interfaces bien definidas y estables para upgrades.

Dicho más aterrizado:
clean core significa que no construyes “parches” encima de SAP cada vez que el negocio pide algo. Primero cuestionas si el estándar ya lo resuelve; luego, si de verdad necesitas diferenciarte, extiendes de una manera moderna, desacoplada y gobernada.

Por qué SAP insiste tanto en esto

SAP conecta clean core con cuatro beneficios grandes: reducir complejidad histórica, acelerar innovación, aprovechar datos confiables e IA, y sostener la transformación con gobierno y KPIs. También lo presenta como clave para mantener sistemas críticos ágiles, costo-efectivos y listos para adoptar innovación.

En la práctica, clean core busca evitar esto:

• upgrades lentos o dolorosos,

• proyectos donde cada cambio rompe algo,

• custom code que nadie quiere tocar,

• integraciones punto a punto difíciles de mantener,

• datos pobres que frenan analítica e IA.

Los 5 principios de clean core

SAP ya lo está estructurando alrededor de cinco principios guía: procesos, extensibilidad, datos, integraciones y operaciones.

1) Procesos

La lógica aquí es: usar procesos estándar siempre que sea posible. Clean core en procesos significa acercarte al estándar SAP y evitar rediseñar como “custom” algo que SAP ya resuelve razonablemente. SAP lo presenta como base para simplificar el core y apoyarse en procesos estándar antes de pensar en extensiones.

Esto pega directo en implementaciones S/4: muchas veces el problema no es que SAP “no pueda”, sino que la empresa quiere arrastrar una forma histórica de operar que ya no conviene replicar.

2) Extensibilidad

Este es el tema más visible. SAP habla de clean core extensibility como un enfoque donde las extensiones quedan separadas del sistema estándar y consumen APIs o puntos de extensión estables. Para SAP S/4HANA Cloud, el objetivo es permitir que el cliente extienda cuando lo necesite, sin perder actualizabilidad ni estabilidad.

Aquí el mantra es muy claro: separar las extensiones del estándar.

3) Datos

SAP mete datos dentro del clean core porque no basta con “no modificar código”. Un core limpio también requiere master data confiable, volumen de datos eficiente y gobierno de datos. SAP Learning describe clean core como un sistema cercano al estándar, con datos maestros de alta calidad y diseño óptimo de procesos; además, el framework de medición usa KPIs y gobierno para monitorear progreso.

4) Integraciones

En integración, clean core significa usar escenarios estándar y tecnologías modernas expuestas por SAP, como APIs, OData, SOAP o eventos, en lugar de acoplamientos frágiles. SAP Integration Suite aparece como habilitador importante para una integración limpia, segura, escalable y preparada para futuro.

5) Operaciones

La quinta pata es operación: monitoreo, gobierno, medición, disciplina operativa y capacidad de sostener el modelo en el tiempo. SAP lo conecta con frameworks de medición, KPIs, governance & maturity y con Cloud ALM / RISE Methodology para dar seguimiento continuo.

Clean core no significa “cero custom”

Este punto es importantísimo. Clean core no significa renunciar a diferenciarte. SAP explícitamente plantea el balance entre estandarización y diferenciación: adoptar estándar donde conviene y extender estratégicamente donde sí genera valor. También promueve dos grandes modelos de extensión: side-by-side en SAP BTP y on-stack con ABAP Cloud, dependiendo del caso de uso.

La diferencia no es “extender o no extender”, sino cómo lo haces:

• mal: modificando estándar, metiendo Zs acoplados, accediendo objetos internos sin control;

• bien: usando APIs públicas, extension points liberados, ABAP Cloud, SAP Build o side-by-side en BTP.

Qué herramientas y enfoques encajan con clean core

SAP está empujando varias piezas como parte del enfoque:

• SAP BTP para side-by-side extensibility y automatización desacoplada.

• ABAP Cloud para extensiones upgrade-stable dentro del ERP, usando APIs públicas y modelo cloud-compliant.

• SAP Build para extensiones low-code/no-code y automatización con el nivel más alto de cumplimiento dentro del modelo de niveles.

• SAP Integration Suite para integración limpia y gobernada.

• SAP Cloud ALM / RISE Methodology dashboard para seguimiento de KPIs, gobierno y madurez de clean core.

El nuevo modelo de niveles A-B-C-D

Aquí hay una actualización importante de 2025. SAP evolucionó su madurez de extensibilidad a un modelo de cuatro niveles: A, B, C y D, para clasificar extensiones según su integridad arquitectónica, seguridad frente a upgrades y alineación con clean core.

A grandes rasgos:

• Nivel A: extensiones totalmente alineadas, usando interfaces públicas y estables; SAP menciona aquí SAP Build y extensiones con APIs públicas / ABAP Cloud.

• Nivel B: todavía aceptable y gobernable, usando APIs o mecanismos clásicos soportados. SAP incluso aclaró que ciertos escenarios como IDocs pueden entrar aquí.

• Nivel C: cuando la realidad del negocio exige usar objetos internos o enfoques legacy; aumenta el riesgo y la deuda técnica.

• Nivel D: no clean core; aquí caen modificaciones o extensiones que no siguen las guías de SAP y comprometen mantenibilidad y upgradeability.

Esto es importante porque SAP ya no deja el tema en “sí/no”; ahora lo convierte en una conversación de madurez y riesgo técnico.

Cómo medir si de verdad tienes clean core

SAP no lo plantea como slogan, sino como algo medible. El clean core measurement framework usa KPIs y se combina con governance & maturity para crear un ciclo de mejora continua. Además, SAP ya anunció KPIs de extensibilidad en el dashboard de RISE with SAP, incluyendo indicadores agregados de deuda técnica de objetos custom.

Traducido a operación real, deberías vigilar cosas como:

• cuánto custom code tienes y de qué tipo,

• cuántas extensiones usan APIs públicas vs objetos internos,

• cuántas integraciones son estándar vs punto a punto,

• cuántas desviaciones funcionales al estándar sigues cargando,

• cuánto te cuesta probar y actualizar.

Lo que clean core sí exige a una empresa

No es solo tema de Basis, ABAP o arquitectura. Implica decisiones de negocio.

1. Aceptar estandarización donde sí conviene

No todo proceso merece ser “único”. SAP insiste en priorizar estándar para mantener agilidad y costo-efectividad.

2. Gobernar excepciones

Cuando sí hay diferenciación real, debes justificar por qué extiendes, con qué patrón, en qué capa y con qué riesgo. El framework de governance & maturity va justo por ahí.

3. Mover el mindset técnico

Pasar de “modifico SAP” a “extiendo SAP sin romperlo”. SAP lo aterriza con ABAP Cloud, SAP Build, APIs públicas y BTP-first strategy.

4. Tratar datos e integración como parte del core

No basta con tener poco Z. Si tus datos son malos o tus integraciones son frágiles, tampoco tienes clean core.

Qué NO es clean core

No es:

• “quitar todos los desarrollos Z de un día para otro”;

• “prohibir extensiones”;

• “hacer cloud por moda”;

• “forzar estándar aunque destruya una ventaja competitiva real”.

SAP lo presenta más bien como una estrategia para elegir conscientemente dónde estandarizas y dónde diferencias, con arquitectura moderna y reglas claras.

Mi lectura práctica como consultora SAP

Lo más valioso de clean core es que cambia la pregunta. Antes la conversación era:
“¿Podemos hacer este desarrollo?”

Ahora debería ser:
“¿Esto debe vivir en el core? ¿Existe estándar? ¿Se puede resolver con extensión limpia? ¿Qué riesgo de upgrade deja? ¿Qué valor real aporta?”

Ese cambio de pregunta es enorme.

Porque el problema histórico de muchos landscapes SAP no es falta de funcionalidad. Es exceso de decisiones técnicas tomadas sin gobierno, que después vuelven carísima la evolución del sistema. Esa es exactamente la complejidad que SAP dice querer reducir con clean core.

En una sola frase

Clean core es mantener SAP lo más estándar posible, extender solo donde realmente agrega valor, y hacerlo con mecanismos desacoplados, medibles y upgrade-stable.

Si quieres platicar más sobre el tema, envíanos un mensaje.

Ing. Iziz Rosales

Práctica SAP

Con más de 20 años de experiencia optimizando procesos empresariales mediante soluciones tecnológicas innovadoras. Es cofundadora de Solution Factory, una empresa de 12 años que brinda servicios profesionales en SAP y tecnologías afines. Tiene amplia experiencia en gestión de proyectos de TI e implementación de ERP, y ha trabajado con empresas de diversos sectores para mejorar la eficiencia operativa. Su enfoque combina experiencia técnica, visión estratégica y compromiso con los resultados del cliente.