Clean Core es la doctrina arquitectónica que prohíbe modificar el código estándar de SAP y obliga a que toda lógica propia se construya sobre interfaces liberadas: APIs públicas, eventos y puntos de extensión oficiales. Enl a práctica se materializa por dos vías. La extensibilidad In-App, que vive dentro de S/4HANA con ABAP Cloud y el modelo RAP, para lógica que necesita proximidad transaccional. Y la extensibilidad Side-by-Side, que se ejecuta fuera del ERP sobre SAP BTP con el modelo CAP y lenguajes abiertos como Node.js, Java oPython, comunicándose por APIs OData y eventos asíncronos. La diferencia no es estética: con un núcleolimpio, las actualizaciones trimestrales de S/4HANA Cloud son un evento rutinario; con el núcleo modificado,cada una es un proyecto con riesgo operativo.

El Z que funciona es el que te bloquea

Durante veinte años, la respuesta a cualquier requisito que el estándar no cubría fue la misma: un desarrollo a medida acoplado a las tablas y transacciones de SAP. Funcionaba. Y mientras el sistema no se movía, nadie tenía motivo para revisarlo. El problema aparece cuando el ERP deja de ser estático.

S/4HANA Cloud entrega innovación en ciclos trimestrales. Ese ritmo, que es la principal ventaja de la plataforma, se convierte en una amenaza cuando la lógica de negocio está incrustada en el estándar: cada actualización exige pruebas de regresión, ventanas de parada y presupuesto. Las organizaciones que no resuelven esto acaban atrapadas en versiones antiguas de su propio software y, con ellas, fuera del alcance de todo lo que viene después —IA generativa, analítica predictiva, hiperautomatización—.

El dato de adopción explica por qué esto ya no es una discusión teórica: aproximadamente la mitad de los clientes de SAP utiliza activamente servicios de BTP, y en torno a una cuarta parte adicional está en fases iniciales. El mercado ya decidió que la extensión vive fuera del core. La pregunta pendiente es qué hacer con lo que quedó dentro.

Los cuatro niveles: Pon nombre a tu deuda antes de presupuestarla.

SAP sustituyó su antiguo esquema de tres capas por un modelo de madurez de cuatro niveles, integrado en las metodologías de despliegue de RISE with SAP. Su utilidad práctica es que convierte una intuición («tenemos mucho Z») en un inventario clasificable y, por tanto, presupuestable:

Modelo de madurez de extensibilidad · qué implica cada nivel en la próxima actualización

Para que ese inventario no se degrade con el tiempo, la disciplina se sostiene con instrumentación: SAP Cloud ALM ofrece métricas continuas de cumplimiento —porcentaje de Clean Core, puntuación de deuda técnica, ratio de código sin uso— que permiten discutir arquitectura con cifras en lugar de con opiniones. Y conviene decirlo: una parte del código que aparece en ese inventario no hay que migrarlo ni refactorizarlo, hay que retirarlo. No lo usa nadie.

In-App o Side-by-Side: La decisión que define el proyecto

Clean Core no significa «todo fuera». Significa que cada extensión se coloca donde corresponde, con criterio y no por inercia. Ambos vectores son legítimos y resuelven problemas distintos.

Los dos vectores de extensibilidad

La arquitectura resultante es sencilla de dibujar, que es justo la señal de que está bien planteada:

Sobre esa base, BTP deja de ser un gasto de plataforma y empieza a devolver valor en tres frentes que ya están maduros:

  • Dato sin duplicar. SAP Datasphere habilita una arquitectura de business data fabric: los modelos analíticos consultan la información en su origen mediante federación «zero-copy», preservando la semántica de negocio de las aplicaciones SAP. Se acaban las copias no gobernadas y el coste de almacenarlas. Con Seamless Planning, los modelos de planificación de SAP Analytics Cloud se almacenan sobre esa misma capa semántica y se alimentan de datos transaccionales vivos.
  • Automatización con evidencia, no con intuición. SAP Signavio Process Insights se conecta al core por API OData y compara el proceso real con el diseñado: expone cuellos de botella, retrabajo manual y desviaciones de ciclo. Lo que se automatiza después en SAP Build Process Automation sale de ese diagnóstico, no de una reunión.
  • IA gobernada. El Generative AI Hub centraliza el consumo de modelos, el control de tokens y los filtros de privacidad, con la garantía de que los datos de S/4HANA no acaban entrenando modelos públicos. Es la condición previa para que agentes como SAP Joule pasen de responder preguntas a resolver flujos —conciliar discrepancias entre factura, pedido y albarán, o proponer proveedores de contingencia— bajo tolerancias definidas por la organización.

Lo que casi nadie presupuesta: El gobierno del gasto

BTP es un entorno amplio, y esa amplitud tiene factura. El control de costes rara vez falla por un error de cálculo: falla por ausencia de responsables. Cuatro medidas resuelven la mayor parte del problema y conviene tomarlas antes del primer despliegue, no después del primer sobresalto:

  • Subcuentas como contenedores de coste. El error habitual es replicar el organigrama. Deben articularse por dominio de rendición de cuentas y por entorno de ciclo de vida (desarrollo, calidad, producción), con etiquetas obligatorias que permitan atribuir el gasto a su centro de coste.
  • Dimensionado por entorno. Replicar en desarrollo la capacidad de producción es el desperdicio más común y el más fácil de evitar.
  • Auditoría de desmantelamiento. Una revisión mensual breve basta para apagar servicios inactivos, aplicaciones abandonadas e instancias experimentales que siguen consumiendo créditos.
  • Alertas de consumo. Avisan antes de agotar el saldo prepagado y, sobre todo, delatan configuraciones defectuosas y bucles que se detectan tarde.

La elección del modelo comercial acompaña esa disciplina: pago por uso para validaciones y cargas volátiles, acuerdo de créditos empresariales (CPEA) cuando conviven varios servicios y hace falta gobierno centralizado, y suscripción cerrada para producción estable y predecible.

Quién se queda cuando el modelo hay que sostenerlo

Un proyecto Clean Core no termina en el go-live. Termina —si termina— cuando la organización es capaz de absorber una actualización sin convocar un comité. Eso exige criterio arquitectónico sostenido y un interlocutor que conozca a la vez el estándar de SAP y la operativa real de la casa.

En DESIC llevamos desde 1997 haciendo exactamente eso, con un equipo propio de más de 200 profesionales y una trayectoria construida sobre sistemas que no se pueden caer: Gobierno de Canarias, Servicio Canario de la Salud y operadoras de transporte, entre otros. Nuestras garantías están auditadas, no declaradas: certificaciones AENOR en Esquema Nacional de Seguridad (ENS), ISO 9001, ISO 14001 e ISO/IEC 27001.

Ese criterio es el que aplicamos también a nuestras soluciones sobre BTP, todas construidas sin tocar el estándar: EUDR Compliance para trazabilidad y diligencia debida dentro de S/4HANA, Tesorería Avanzada para conciliación bancaria automática y previsión de liquidez, y la suite de e-Invoicing y e-Reporting —con Valira como capa orquestadora— para SII, IGIC, Verifactu, Facturae y el mandato B2B de la Ley Crea y Crece. Ninguna de ellas añade un punto de deuda técnica al núcleo. Es la prueba de que el modelo funciona en producción y no solo en un diagrama.

Si necesita saber en qué nivel está hoy su ERP —qué extensiones son inmunes al upgrade, cuáles exigen auditoría y cuáles hay que retirar—, solicite un diagnóstico gratuito de arquitectura Clean Core con nuestro equipo técnico en https://www.desic-sl.com/consultoria-sap