Estrategia SAP Clean Core: qué significa y cómo aplicarla

Clean Core decide si una actualización de S/4HANA lleva seis semanas o seis meses. Si su sistema está lleno de modificaciones a objetos estándar de SAP, cada versión se convierte en un proyecto de regresión. Si su lógica a medida está detrás de interfaces publicadas, las actualizaciones pasan a ser mantenimiento rutinario.

He visto empresas que redujeron un 40 % los plazos de actualización aplicando los principios de Clean Core antes de que empezara su programa de S/4HANA. Una empresa de bienes de consumo sustituyó una lógica de precios heredada por una aplicación Fiori modular construida fuera del core, y sus actualizaciones dejaron de romper esa lógica.

Han cambiado muchas cosas desde que escribí esto por primera vez, en abril de 2025. SAP describe ahora Clean Core con cinco principios rectores y, desde agosto de 2025, clasifica cada extensión en uno de cuatro niveles. Las fechas límite de ECC también están más claras. Esta versión lo recoge.

Clean Core significa mantener su sistema S/4HANA tan cerca del estándar de SAP como su negocio permita y crear todo lo adicional de una forma que sobreviva a las actualizaciones.

Todavía puede personalizar. La personalización tiene que usar interfaces que SAP ha publicado 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 API y puntos de extensión publicados.
• Side-by-side, en SAP BTP. Las extensiones se ejecutan como aplicaciones independientes y se comunican con S/4HANA mediante API o eventos.

La propia guía de SAP es elegir según el caso de uso, con BTP en primer lugar. En mi experiencia, importa menos dónde se ejecuta el código que si el requisito necesita código siquiera.

Un core sucio le resultará familiar a cualquiera que haya trabajado con ECC: programas estándar modificados, tablas Z con escritura directa, interfaces que leen estructuras internas de SAP, mejoras implícitas que nadie documentó. Nada de eso era un error cuando se construyó. Simplemente no se construyó para un sistema que se actualiza cada año o cada dos.

SAP organiza Clean Core en torno a cinco principios rectores. La versión anterior de este artículo enumeraba otros encabezados. Estos son los que usa SAP, con lo que miro primero en cada uno:

Principio	Qué entiende SAP	Qué compruebo 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 core mediante API publicadas, con gobierno sobre qué opción se usa	Cuánto código a medida existe, cuánto se usa y en qué nivel se encuentra
Datos	Datos limpios y conformes, con un modelo de gobierno 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	Gobierno, personas, procesos y herramientas que mantienen en su sitio 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. La causa es el proceso que hay detrás.

En agosto de 2025 SAP sustituyó su modelo anterior de extensibilidad de tres niveles por el concepto de niveles de Clean Core. Cada extensión se evalúa según cómo está construida, cuán desacoplada está del core y con qué facilidad se puede actualizar.

Nivel	Descripción de SAP	Qué significa para su actualización
A	Extender con SAP Build. Solo interfaces estables publicadas oficialmente, on-stack con ABAP Cloud o side-by-side en BTP	Riesgo mínimo. SAP respalda estas interfaces con contratos de estabilidad
B	Usa además las API y tecnologías clásicas de SAP	Por lo general estable ante actualizaciones, pero fuera del modelo de desarrollo en la nube
C	Accede a objetos internos de SAP	Cumplimiento parcial. Cada actualización requiere revisión; SAP planea un registro de cambios para los objetos internos
D	No recomendado: modificaciones, escrituras en tablas de SAP, mejoras implícitas, objetos explícitamente no recomendados	La deuda técnica que hay que eliminar primero

Esto es más útil que el viejo debate de «limpio o no limpio». Le permite fijar un objetivo por objeto. No todo tiene que llegar al nivel A. Llevar sus objetos de nivel D a B o C antes de una actualización ya supone una reducción real del riesgo.

Nivel ANivel BNivel CNivel D

Qué usaNivel ASolo interfaces estables publicadas oficialmenteNivel BTambién las API clásicas de SAPNivel CObjetos internos de SAPNivel DModificaciones, escrituras en tablas de SAP, mejoras implícitas

Riesgo de actualizaciónNivel AEl más bajo, respaldado por contratos de estabilidadNivel BPor lo general estable ante actualizacionesNivel CRequiere revisión en cada actualizaciónNivel DEl más alto

Qué decidirNivel ALa opción por defecto para todo lo nuevoNivel BAceptar, dejando constancia del motivoNivel CAceptar con motivo y revisar en cada actualizaciónNivel DEliminar primero, o llevar a B o C

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

Si me pidieran 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, que viene incluido en su contrato de mantenimiento, y reúna 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. La mayor parte del resto simplemente no se usaba.
2. Clasifique lo que quede en niveles A a D. El ABAP test cockpit es la herramienta de SAP para las comprobaciones a nivel de código. Con RISE, el panel de RISE with SAP Methodology informa de la adopción de Clean Core.
3. Decida objeto por objeto. Retírelo, llévelo a una interfaz publicada, reconstrúyalo en BTP o consérvelo con un motivo documentado. Empiece por el código que se ejecuta a diario. Un informe que un solo equipo regional usa dos veces al año puede esperar.
4. Siente al negocio en la mesa. Un responsable de finanzas con quien trabajé solo entendió su nueva aplicación Fiori después de un recorrido de 45 minutos. Esa sesión ahorró dos semanas de idas y venidas en las UAT.
5. Ponga en duda el «nuestro proceso es diferente». En un taller con un equipo de ventas, el proceso «único» resultó ser en un 80 % trabajo administrativo heredado y redundante. El SAP estándar mejoró la experiencia de sus clientes en cuanto desaparecieron las soluciones provisionales.
6. Empiece pronto con los datos. Un cliente de retail tenía más de 15.000 campos a medida que revisar. En mi experiencia, la migración de datos consume entre el 30 y el 40 % del esfuerzo de implementación, y es la parte que más planes subestiman. Explico por qué en por qué fracasa la migración de datos en SAP.
7. Defina el gobierno antes del go-live. Una design authority debería revisar cada extensión nueva. La pregunta por defecto solía ser «¿por qué no puede esto vivir en BTP?». Hoy preguntaría «¿por qué no puede ser de nivel A y, si no puede, qué nivel aceptamos y por qué?».

Las competencias importan tanto como las herramientas. Un equipo ABAP que no ha trabajado con ABAP Cloud o 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 de S/4HANA, y valió la pena: hubo menos sorpresas durante la construcción.

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

¿Es obligatorio Clean Core con RISE with SAP? No como regla general. En S/4HANA Cloud Public Edition solo se puede extender mediante interfaces publicadas, así que el propio sistema lo impone. En Private Edition y on-premise todavía se puede modificar el core. Allí Clean Core es una decisión de gobierno, y SAP le hace seguimiento a través del panel de la metodología RISE. Si un integrador de sistemas (SI) le dice que es contractual, pídale que le muestre la cláusula.

¿Cuánto tiempo tengo en ECC? Para SAP ERP 6.0 con paquetes de mejoras 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027. El mantenimiento ampliado opcional llega hasta el 31 de diciembre de 2030 con un costo adicional, y SAP pide a los clientes que lo contraten antes del tercer trimestre de 2027. Los paquetes de mejoras anteriores dejaron el mantenimiento estándar a finales de 2025. Después de 2030, la opción de transición de SAP ERP, private edition cubre de 2031 a 2033. Solo se aplica a sistemas grandes que ya hayan pasado a SAP ERP, private edition, sobre SAP HANA antes de finales de 2030, y solo con el plan max success de SAP. Trate 2033 como una vía excepcional, no como una fecha de planificación. Mi guía de migración de ECC a S/4HANA explica las opciones de ruta.

¿Importa Clean Core para la IA? SAP construye sus funciones de IA, incluido Joule, sobre sus procesos estándar y su modelo de datos. Joule for developers genera código ABAP Cloud contra API publicadas. Mi opinión de trabajo es simple: cuanto más cerca estén sus procesos y datos del estándar, menos adaptación necesitará antes de que esas funciones le sirvan. Los procesos muy modificados son donde más cuesta adoptar las funciones de IA.

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

Si está a punto de firmar un contrato de S/4HANA o de RISE, pida a su SI una clasificación de su código a medida actual por niveles A a D antes de acordar el alcance. Si no puede aportarla, eso le dice algo sobre la estimación. Puede probar sus opciones de migración con mi evaluación de migración de ECC a S/4HANA, o reserve una llamada y revisamos su situación.

¿Qué es SAP Clean Core?

Clean Core significa mantener S/4HANA cerca del estándar de SAP y crear extensiones solo mediante interfaces que SAP ha publicado 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 las actualizaciones no rompan su lógica a medida.

¿Cuáles son las cinco dimensiones de SAP Clean Core?

SAP las llama los cinco principios rectores de Clean Core: procesos, extensibilidad, datos, integraciones y operaciones. Los procesos se mantienen cerca del estándar. Las extensiones usan API publicadas. Los datos se mantienen limpios bajo un modelo de gobierno. Las integraciones usan tecnologías estandarizadas y soportadas. Las operaciones abarcan el gobierno, las personas y las herramientas que mantienen en su sitio los otros cuatro.

¿Cuáles 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 estables publicadas oficialmente. El nivel B usa además las API clásicas de SAP. El nivel C accede a objetos internos de SAP y requiere revisión en cada actualización. El nivel D abarca modificaciones, escrituras en tablas de SAP, mejoras implícitas y otras técnicas no recomendadas, y representa el riesgo más alto.

¿Es obligatorio Clean Core con RISE with SAP?

No como regla general. S/4HANA Cloud Public Edition solo permite extensiones mediante interfaces publicadas, por lo que impone Clean Core técnicamente. En Private Edition todavía se puede modificar el core, así que Clean Core es una decisión de gobierno. SAP informa de la adopción de Clean Core a través del panel de RISE with SAP Methodology.

¿Cuándo termina el soporte de SAP ECC?

Para SAP ERP 6.0 con paquetes de mejoras 6 a 8, el mantenimiento estándar termina el 31 de diciembre de 2027, con mantenimiento ampliado opcional hasta el 31 de diciembre de 2030 con un costo adicional. Los paquetes de mejoras anteriores dejaron el mantenimiento estándar a finales de 2025. La opción de transición de SAP ERP, private edition, se extiende hasta 2033 solo para sistemas grandes que reúnan los requisitos y hayan pasado a SAP ERP, private edition, sobre SAP HANA antes de finales de 2030.

¿Cómo evalúo la preparación de mi sistema SAP para Clean Core?

Empiece con el SAP Readiness Check y los datos de uso de su código a medida. Clasifique lo que aún se usa en niveles A a D, con el ABAP test cockpit para las comprobaciones a nivel de código. Después decida por objeto si lo retira, lo lleva a una interfaz publicada, lo reconstruye en SAP BTP o lo conserva con un motivo documentado. Revise al mismo tiempo los procesos y los datos, porque suelen explicar por qué existe el código.

¿Qué papel desempeña SAP BTP en una estrategia Clean Core?

SAP BTP es donde se ejecutan las extensiones side-by-side. Las aplicaciones en BTP se conectan a S/4HANA mediante API y eventos, de modo que el core no se toca. SAP recomienda un enfoque BTP-first, con extensiones on-stack de ABAP Cloud cuando la lógica necesita estar cerca de los datos o de la transacción.