SAP Clean Core: qué significa, niveles A a D y gobernanza

SAP Clean Core significa mantener su sistema S/4HANA tan cerca del estándar de SAP como su negocio lo permita. Todo lo que añada se construye mediante interfaces que SAP ha liberado y se ha comprometido a mantener estables, para que los upgrades no lo rompan.

La respuesta corta: Clean Core es una disciplina sobre cómo extiende y gobierna SAP. La lógica a medida va on-stack con ABAP Cloud o side-by-side en SAP BTP, y SAP califica cada extensión desde el nivel A (la más limpia) hasta el nivel D (modificaciones que hay que eliminar). La recompensa son upgrades más rápidos: he visto empresas reducir así un 40 % los plazos de sus upgrades.

Si su sistema está lleno de modificaciones a objetos estándar de SAP, cada release se convierte en un proyecto de regresión. Si su lógica a medida está detrás de interfaces liberadas, los upgrades pasan a ser mantenimiento rutinario.

He visto empresas reducir un 40 % los plazos de sus upgrades aplicando los principios de Clean Core. Lo lograron reduciendo las personalizaciones al mínimo y gobernando las que conservaron.

En 2024 una empresa europea de bienes de consumo sustituyó su lógica de precios heredada por una app Fiori modular construida fuera del núcleo, en SAP BTP. Con eso eliminó por completo las pruebas de regresión de esa lógica.

Un ERP con Clean Core se puede seguir personalizando. La personalización tiene que usar interfaces que SAP ha liberado y se ha comprometido a mantener estables. SAP ofrece dos formas de hacerlo:

• On-stack, con ABAP Cloud. Las extensiones se ejecutan dentro de S/4HANA, pero solo usan APIs y puntos de extensión liberados.
• Side-by-side, en SAP BTP. Las extensiones se ejecutan como aplicaciones separadas y se comunican con S/4HANA mediante APIs o eventos.

SAP describe su enfoque como BTP-first, eligiendo según cada caso de uso. En mi experiencia, importa menos dónde se ejecuta el código que si el requisito necesita código en absoluto.

Un núcleo «sucio» le resultará familiar a cualquiera que haya operado ECC: programas estándar modificados, tablas Z en las que se escribe directamente, interfaces que leen los internos de SAP, ampliaciones implícitas que nadie documentó. Nada de eso estaba mal cuando se construyó. Simplemente no se construyó para un sistema que se actualiza cada uno o dos años.

También trato este tema en un vídeo de mi canal de YouTube (en inglés).

SAP organiza Clean Core en torno a cinco principios rectores. Así enmarca SAP cada uno, y esto es lo primero que miro:

Principio	Qué quiere decir SAP	Qué reviso primero
Procesos	Mantenerse lo más cerca posible del proceso estándar de SAP	Qué variantes de proceso existen solo porque «siempre lo hicimos así»
Extensibilidad	Extensiones desacopladas del núcleo mediante APIs liberadas, con gobernanza sobre qué opción se usa	Cuánto código a medida existe, cuánto se usa y en qué nivel está
Datos	Datos limpios y conformes, con un modelo de gobernanza establecido	Datos maestros duplicados e incompletos, campos a medida que nadie sabe explicar
Integraciones	Conexiones estandarizadas y seguras, basadas en tecnologías soportadas	Interfaces punto a punto que leen tablas directamente
Operaciones	Gobernanza, personas, procesos y herramientas que mantienen en pie los otros cuatro	Quién aprueba una extensión y qué impide la siguiente modificación

La mayoría de los equipos empieza y termina con la extensibilidad porque es lo más fácil de medir. En mi experiencia, los procesos y los datos causan más retrasos. El código a medida suele ser el síntoma, y el proceso que hay detrás, la causa.

En agosto de 2025 SAP sustituyó su anterior modelo de extensibilidad de tres niveles por el concepto de niveles de Clean Core. Cada extensión se califica según cómo está construida, cuánto está desacoplada del núcleo y con qué seguridad sobrevive a un upgrade. Si lee material antiguo de SAP que habla de tiers, esto es lo que lo sustituyó.

Nivel ANivel BNivel CNivel D

Qué usaNivel ASolo interfaces públicas liberadas y establesNivel BTambién las APIs clásicas de SAPNivel CObjetos internos de SAPNivel DModificaciones, escrituras en tablas SAP, ampliaciones implícitas

Riesgo en el upgradeNivel AEl más bajo, respaldado por contratos de estabilidadNivel BEn general estable ante upgradesNivel CHay que revisarlo en cada upgradeNivel DEl más alto

Qué decidirNivel ALa opción por defecto para todo lo nuevoNivel BAceptar, dejando registrado el motivoNivel CAceptar con un motivo y revisar en cada upgradeNivel DEliminar primero o llevarlo a B o C

Fuente: Concepto de niveles de Clean Core de SAP, SAP News, agosto de 2025

El nivel A usa solo interfaces públicas liberadas con contratos de estabilidad, construidas con SAP Build, ABAP Cloud o BTP. El nivel B añade las APIs clásicas de SAP. El nivel C toca objetos internos de SAP, y SAP prevé un registro de cambios para ellos que ayude a planificar los upgrades.

El nivel D son modificaciones, escrituras en tablas SAP, ampliaciones implícitas y otras técnicas que SAP no recomienda. Esto es más útil que el viejo debate de «limpio o no limpio», porque le permite fijar un objetivo por objeto. Llevar sus objetos de nivel D a B o C antes de un upgrade ya es una reducción real del riesgo.

ABAP Cloud es el modelo de desarrollo ABAP de SAP preparado para la nube. Los desarrolladores usan la versión de lenguaje «ABAP for Cloud Development» y solo pueden construir sobre objetos liberados, APIs públicas y puntos de extensión. Nació en el entorno ABAP de SAP BTP y hoy está disponible en todas las ediciones de S/4HANA (SAP ABAP Cloud FAQ).

S/4HANA Cloud le ofrece tres vías de extensión. La extensibilidad para usuarios clave cubre cambios sencillos de campos, lógica e interfaz sin tocar el código de SAP. La extensibilidad para desarrolladores con ABAP Cloud se ocupa de la lógica estrechamente acoplada, y las extensiones side-by-side en SAP BTP se ocupan de todo lo que deba quedar desacoplado.

La edición decide cuánto margen de elección tiene:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition y on-premise
Desarrollo ABAP	Solo ABAP Cloud, obligatorio para clientes nuevos desde la release 2208	ABAP Cloud recomendado desde 2022; ABAP clásico aún permitido
Cambios en el código de SAP	No es posible	Es posible, pero son nivel D
Extensiones de usuario clave y side-by-side en BTP	Disponibles	Disponibles
Quién impone Clean Core	El sistema	Su gobernanza

Mi regla para los clientes de Private Edition: trátela como si fuera Public Edition para todo lo nuevo. El ABAP clásico está permitido, pero cada objeto clásico que añada hoy es una decisión que alguien tendrá que defender en el siguiente upgrade.

Las decisiones de Clean Core deben estar en manos de una autoridad de diseño formada por negocio e IT. IT por sí sola aprobará todo lo que sea técnicamente posible. El negocio por sí solo pedirá que le devuelvan su proceso antiguo.

Así es como yo la montaría:

1. Nombre a los miembros. Los dueños de proceso de negocio de cada área principal, más el arquitecto de la solución y el desarrollador líder. Los dueños de negocio deciden si un requisito es real, e IT decide cómo se construye.
2. Acuerde el orden de preferencia antes de empezar a construir. Primero el proceso estándar, después la extensibilidad para usuarios clave, después el nivel A en ABAP Cloud o BTP. El nivel B o C necesita un motivo por escrito, y el nivel D, un plan de salida.
3. Exija que cada solicitud de extensión tenga un dueño y un motivo de negocio. Sin dueño, no se construye. La decisión y el nivel aceptado van a un único registro.
4. Ponga un control técnico delante de los transportes. Ejecute de forma programada las comprobaciones de Clean Core del ABAP test cockpit y detenga el nuevo código de nivel D antes de que llegue a producción.
5. Revise el registro antes de cada upgrade. Retire lo que ya nadie usa y suba de nivel todo lo que ahora pueda alcanzar uno superior.

La pregunta en esa mesa solía ser «¿por qué esto no puede vivir en BTP?». Hoy yo preguntaría «¿por qué esto no puede ser nivel A?». Si no puede, la siguiente pregunta es qué nivel está aceptando y por qué.

El mayor error de Clean Core que veo es intentar que SAP funcione como Oracle. Adopte los procesos estándar de SAP en lugar de reconstruir la lógica de otro sistema en código a medida. Si todavía está eligiendo entre los dos, los comparo en SAP vs Oracle.

Clean Core es un problema de gestión del cambio antes que un problema técnico. Cada objeto a medida existe porque alguien lo pidió. Eliminarlo significa convencer a esa persona de que el proceso estándar es suficientemente bueno.

Esa conversación va mejor cuando el negocio ve funcionar el nuevo proceso, no una diapositiva sobre él. También va mejor cuando pone a prueba la afirmación de que un proceso es único, porque a menudo no lo es (vea los pasos 4 y 5 más abajo).

Las competencias importan tanto como las herramientas. Un equipo ABAP que no ha trabajado con ABAP Cloud ni con BTP frenará el programa mientras aprende. Un fabricante con el que trabajé llevó a cabo un programa interno de BTP de tres meses antes de que empezara su proyecto S/4HANA, y eso se tradujo en menos sorpresas durante la construcción.

El cumplimiento de Clean Core es la parte de su sistema que cumple los criterios de SAP en los cinco principios. No puede gestionarlo sin cifras, y SAP le da tres lugares donde obtenerlas.

1. El ABAP test cockpit. La herramienta de SAP para comprobaciones a nivel de código. Muestra qué objetos a medida usan objetos no liberados, modificaciones o acceso directo a tablas.
2. El SAP Readiness Check. Viene incluido en su contrato de mantenimiento y muestra qué tocará un paso a S/4HANA antes de que se comprometa.
3. El RISE with SAP Methodology dashboard, también conocido como clean core dashboard. Se ejecuta en SAP Cloud ALM. Su vista de sistema comprueba su versión de S/4HANA, confirma que las herramientas de recopilación de datos están activas y revisa las extensiones antes de un upgrade, y su vista de operaciones sigue los KPI operativos.

Las cifras que yo pondría delante de la autoridad de diseño cada mes son sencillas. ¿Cuántos objetos a medida hay en cada nivel, y está bajando el nivel D? ¿Cuántas excepciones están abiertas, y tiene cada una un dueño?

Si me pidiera evaluar su sistema el mes que viene, este es el orden que seguiría.

1. Averigüe qué se usa. Ejecute el SAP Readiness Check y recopile datos de uso de su código a medida. En un programa, el análisis con smartShift nos llevó de 18.000 objetos a medida a 3.200, porque la mayor parte del resto simplemente no se usaba.
2. Clasifique lo que queda en los niveles A a D. Use el ABAP test cockpit para el código. Si está en RISE, el clean core dashboard lo sigue a partir de ahí.
3. Decida objeto por objeto. Retírelo, páselo a una interfaz liberada, reconstrúyalo en BTP o consérvelo con un motivo documentado. Empiece por el código que se ejecuta a diario, porque un informe que un equipo regional usa dos veces al año puede esperar.
4. Siente al negocio en la sala. Un responsable de finanzas con el que trabajé solo entendió su nueva app Fiori después de una demostración de 45 minutos. Esa sesión ahorró dos semanas de idas y vueltas en las pruebas UAT.
5. Cuestione el «nuestro proceso es diferente». En un taller con el equipo comercial de una empresa industrial europea en 2023, el proceso «único» resultó ser en un 80 % administración heredada redundante. El estándar de SAP mejoró la experiencia de sus clientes en cuanto desaparecieron los parches.
6. Empiece pronto con los datos. Un cliente minorista del CCG con el que trabajé en 2024 tenía más de 15.000 campos a medida que revisar. En mi experiencia, la migración de datos supone entre el 30 y el 40 % del esfuerzo de implementación, y mi guía de costos de implementación de SAP muestra dónde cae eso en el presupuesto.
7. Establezca la gobernanza antes del go-live. Ponga en marcha la autoridad de diseño descrita arriba y conviértala en la única vía para una nueva extensión.

Hay tres preguntas que surgen en casi todas las conversaciones que tengo sobre este tema.

¿Es obligatorio Clean Core con RISE with SAP?

No como regla general. En Public Edition lo impone el sistema, mientras que en Private Edition y on-premise todavía puede modificar el núcleo.

Ahí, Clean Core es una decisión de gobernanza que SAP sigue a través del RISE methodology dashboard. Si un integrador le dice que es contractual, pídale que le muestre la cláusula.

¿Cuánto tiempo me queda con ECC?

Para SAP ERP 6.0 con los paquetes de mejoras 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027. El mantenimiento extendido opcional llega hasta el 31 de diciembre de 2030, con un costo adicional.

Después, la opción de transición SAP ERP, private edition cubre de 2031 a 2033. Solo se aplica a sistemas grandes que ya se hayan trasladado a SAP ERP, private edition sobre SAP HANA antes de finales de 2030.

Trate 2033 como una vía de excepción, no como una fecha de planificación. Mi guía de migración de ECC a S/4HANA cubre las opciones de ruta.

¿Importa Clean Core para la AI?

Sí. Mantener el estándar de SAP ayuda a que la AI y Joule funcionen mejor, y los procesos muy modificados son donde más cuesta adoptarlas.

SAP construye sus funciones de AI, incluido Joule, sobre sus procesos estándar y su modelo de datos. Joule for developers genera código ABAP Cloud contra APIs liberadas. Explico cómo encajan la nube, la AI y Clean Core en modernización del ERP.

Los equipos que se saltan Clean Core no evitan el trabajo. Lo aplazan, y vuelve en forma de upgrades bloqueados, maratones de pruebas de regresión y código a medida que nadie entiende.

Antes de firmar un contrato de S/4HANA o de RISE, pida a su integrador que clasifique su código a medida actual en los niveles A a D. Si no puede presentarlo, eso le dice algo sobre la estimación. Reserve una llamada y revisamos su situación.

¿Qué es Clean Core en SAP?

Clean Core significa mantener S/4HANA cerca del estándar de SAP y construir extensiones solo mediante interfaces que SAP ha liberado y se ha comprometido a mantener estables. Las extensiones se ejecutan on-stack con ABAP Cloud o side-by-side en SAP BTP. El objetivo es que los upgrades no rompan su lógica a medida.

¿Cuáles son los cinco principios de SAP Clean Core?

Los cinco principios rectores de Clean Core de SAP son procesos, extensibilidad, datos, integraciones y operaciones. Los procesos se mantienen cerca del estándar, las extensiones usan APIs liberadas y los datos se mantienen limpios bajo un modelo de gobernanza. Las integraciones usan tecnologías soportadas, y las operaciones cubren la gobernanza, las personas y las herramientas que mantienen en pie los otros cuatro.

¿Qué son los niveles A, B, C y D de SAP Clean Core?

Desde agosto de 2025 SAP clasifica las extensiones en cuatro niveles. El nivel A usa solo interfaces públicas liberadas y estables, el nivel B usa además APIs clásicas de SAP y el nivel C accede a objetos internos de SAP. El nivel D abarca modificaciones, escrituras en tablas SAP y ampliaciones implícitas, y conlleva el mayor riesgo en los upgrades.

¿Es obligatorio Clean Core en RISE with SAP?

No como regla general. S/4HANA Cloud Public Edition solo permite ABAP Cloud e interfaces liberadas, así que impone Clean Core a nivel técnico. En Private Edition todavía puede modificar el núcleo, de modo que Clean Core es una decisión de gobernanza que SAP sigue a través del RISE with SAP Methodology dashboard.

¿Qué es ABAP Cloud?

ABAP Cloud es el modelo de desarrollo ABAP de SAP preparado para la nube. Solo permite objetos liberados, APIs públicas y puntos de extensión, lo que mantiene el código a medida estable ante upgrades. Es obligatorio en S/4HANA Cloud Public Edition para clientes nuevos desde la release 2208 y recomendado en Private Edition y on-premise desde 2022.

¿Cómo se mide Clean Core?

Use el ABAP test cockpit para las comprobaciones a nivel de código y clasifique los objetos a medida en los niveles A a D. Los clientes de RISE pueden seguir la adopción en el RISE with SAP Methodology dashboard, también llamado clean core dashboard, en SAP Cloud ALM. Yo sigo el número de objetos en cada nivel, la tendencia del nivel D y el número de excepciones abiertas con dueño.

¿Quién debe ser dueño de la gobernanza de SAP Clean Core?

Una autoridad de diseño formada por negocio e IT debe ser dueña de cada decisión de Clean Core. Los dueños de proceso de negocio deciden si un requisito es real, e IT decide cómo se construye y en qué nivel. Cada excepción se registra con un dueño y se revisa antes de cada upgrade.

¿Cuándo termina el soporte de SAP ECC?

Para SAP ERP 6.0 con los paquetes de mejoras 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027, con mantenimiento extendido opcional hasta el 31 de diciembre de 2030 a un costo adicional. La opción de transición SAP ERP, private edition llega hasta 2033 solo para sistemas grandes elegibles trasladados a SAP ERP, private edition sobre SAP HANA antes de finales de 2030.