SAP Clean Core con código abierto: jabón de base

SAP ABAP Test Cockpit (ATC)

Mientras SAP no deja de insistir en que el núcleo digital de un S/4 HANA debe permanecer intacto, los clientes actuales se enfrentan a una montaña de código personalizado (desarrollos «Z») acumulado a lo largo del tiempo, que no se puede eliminar simplemente con un clic del ratón. La herramienta de pruebas estándar ATC (ABAP Test Cockpit) suele revelarse en la práctica como un juez implacable y rígido. Inunda a los desarrolladores con una avalancha de advertencias en cuanto estos acceden a objetos internos de SAP para los que la propia SAP no ofrece garantía de estabilidad, incluso cuando dichos accesos llevan décadas funcionando de forma estable y no son en absoluto críticos para los procesos de negocio del cliente.

Ante este dilema arquitectónico, SAP ha publicado una herramienta cuyo nombre roza la sátira: el proyecto „Kernseife“. Desde una perspectiva crítica, esta herramienta supone el reconocimiento oficial por parte de SAP de que sus propios métodos de medición estándar para el «Clean Core» son demasiado imprecisos, demasiado burocráticos y, sencillamente, inviables para los proyectos reales de los clientes. SAP ha desarrollado aquí, en el sentido más literal de la palabra, «jabón para el núcleo sucio», con el fin de que el enorme problema de la deuda técnica heredada sea, en primer lugar, medible y manejable.

Código abierto: jabón de Marsella en GitHub

Desde el punto de vista técnico, el proyecto «Kernseife» es una herramienta de código abierto publicada en mayo de 2025, que se pone a disposición de los clientes actuales de SAP de forma gratuita a través de la plataforma de desarrollo GitHub (en github.com/SAP/project-kernseife).

El objetivo de este proyecto es mejorar la medición y el control de las directrices de Clean Core y hacer que resulten viables para los equipos de desarrollo, especialmente en lo que respecta a la extensibilidad dentro de los sistemas S/4 Private Cloud y on-prem.

Esta herramienta subsana una carencia funcional del ABAP Test Cockpit estándar, al ampliar el rígido protocolo de pruebas de SAP con un sistema de clasificación definido por el usuario (Custom Classification). El proyecto «Kernseife» consta esencialmente de dos componentes: una ejecución de pruebas ATC adaptada, basada en las pruebas oficiales «SAP Clean Core», y una matriz de evaluación flexible que permite a los desarrolladores definir sus propias clasificaciones para los objetos ABAP.

Autonomía de ABAP y Clean Core

La ventaja decisiva para los clientes actuales de SAP radica en que recuperan el control sobre la evaluación de su código: si ATC marca de forma predeterminada el acceso a un objeto interno de SAP como una infracción grave (lo que provoca una avalancha de alertas), pero la propia SAP no proporciona información detallada sobre dicho objeto, la empresa puede definir a través del proyecto «Kernseife» que, en su contexto empresarial específico, dicho acceso es estable y está permitido. En este caso, la herramienta anula la advertencia general de SAP y evita así que los desarrolladores se vean abrumados por un sinfín de falsas alarmas (falsos positivos).

Gobernanza y orquestación «Clean Core» con jabón de Marsella

El jabón de Kern no repara el código, solo hace que la suciedad sea manejable: sería un error fatal creer que el uso del proyecto «Jabón de Kern» limpia automáticamente el sistema. La herramienta es un mero instrumento de medición y gobernanza. Se limita a mostrar a los usuarios de ECC con mayor precisión el grado de suciedad real del núcleo y dónde se encuentran los riesgos reales que lo bloquean (modificaciones de nivel D), mientras que las deudas antiguas que no suponen ningún problema quedan ocultas. Los equipos de desarrolladores de ABAP siguen teniendo que realizar manualmente, o mediante plataformas de IA de terceros como Nova Intelligence o West Trax, el costoso trabajo de limpieza del código y refactorización.

La implementación del proyecto «Kernseife» requiere un Centro de Experiencia para el Cliente (CCoE) operativo o una sólida estructura de gobernanza interna. Dado que la herramienta se basa en clasificaciones específicas para cada cliente, es imprescindible definir quién tiene derecho dentro de la empresa a tolerar de forma permanente una alerta de SAP. Sin un proceso de autorización claro y sin responsables cualificados de la herramienta, el proyecto «Kernseife» corre el riesgo de convertirse en una excusa con la que los desarrolladores eludan los requisitos de «Clean Core» —dolorosos, pero necesarios— simplemente silenciando los hallazgos críticos mediante entradas personalizadas.

El paso a la nube de SAP

La promesa de una transición sin complicaciones a la nube de SAP se ha convertido, en las altas esferas de las empresas alemanas, en uno de los mitos más costosos de la historia moderna de los sistemas ERP. Bajo el llamativo eslogan «Rise with SAP», el grupo de software promociona su S/4 Cloud Private Edition como el paso intermedio sin riesgos para todos aquellos clientes actuales que deseen combinar la profundidad técnica de una solución on-premise con las supuestas ventajas de la computación en la nube.

Sin embargo, existe una red meticulosamente tejida de obstáculos comerciales y medidas coercitivas que convierten muy rápidamente esa nube tan tentadora en una trampa de costes que pone en peligro la propia existencia. Desde el punto de vista de la comunidad SAP, es imprescindible desmontar los mecanismos de esta trampa de la nube privada, para que los clientes actuales de S/4 no caigan a ciegas en la dependencia financiera.

El punto de ruptura arquitectónico de esta transformación comienza ya en la base comercial: la transición de un gasto de inversión único (CapEx) a unos costes operativos recurrentes a largo plazo (OpEx). En el entorno tradicional «on-prem», el cliente existente adquiría la propiedad indefinida de sus licencias de software. Incluso si una empresa decidía rescindir el costoso contrato de mantenimiento con SAP, el derecho legítimo de uso del núcleo del ERP permanecía asegurado para siempre en la caja fuerte de la empresa.

Ascender con SAP

Sin embargo, al incorporarse al programa Rise y con la conversión contractual que ello conlleva, el cliente cede de forma irrevocable este valioso bien a Himmelspforte. Pasa de ser un orgulloso propietario a un inquilino indefenso, cuyos derechos de uso expiran de forma repentina al finalizar la vigencia del contrato. Si algún día la empresa ya no pudiera o no quisiera pagar las tarifas de suscripción a la nube, que aumentan vertiginosamente, se corre el riesgo de perder por completo el control: al finalizar el contrato, al cliente solo le quedarán los datos brutos, sin estructurar, en el disco duro. Sin los algoritmos de SAP correspondientes, que permanecen en la nube, estos datos carecen por completo de valor para las consultas empresariales y el funcionamiento diario. SAP simplemente no prevé una salida de la nube.

Este nuevo contrato de alquiler se rige por la métrica poco transparente de los «Full Use Equivalents» (FUE). A SAP le gusta presentar este modelo como una solución flexible y liberadora que permite a las empresas transferir dinámicamente las licencias, dentro de un conjunto de valores predefinido, entre diferentes tipos de usuarios, como los usuarios «Core» o «Advanced». Sin embargo, ¡la devastadora trampa de costes se esconde en el nuevo método de medición!

Métricas en la nube, STAR y TCO

Mientras que en el entorno clásico de ECC las licencias se basaban en el uso real y cuantificable del software, en el entorno S/4 Cloud de SAP el cálculo se realiza exclusivamente en función de los permisos asignados en el sistema. Dado que, en entornos de TI que han crecido de forma orgánica, los derechos de acceso se han concedido de forma generosa y sin control a lo largo de décadas, este análisis basado en los derechos de acceso da lugar a un exceso de licencias masivo si la migración no se prepara adecuadamente. Expertos independientes advierten con insistencia de que esta nueva métrica en la nube puede disparar los costes de licencia en un alarmante porcentaje de entre el 50 % y el 150 %, ya que incluso los usuarios meramente ocasionales deben abonar costosas licencias «Professional» o «Advanced», simplemente porque el sistema les ha asignado roles de amplio alcance.

El servicio STAR que ofrece SAP (S/4 Trusted Authorization Review) no resulta ser en absoluto una herramienta de optimización neutral, sino una herramienta de clasificación automática que asigna a los usuarios sin clasificar directamente al tipo de licencia más caro y, por lo tanto, sirve como palanca para la adquisición de costosas licencias adicionales.

Otra restricción comercial es la dinámica de precios establecida contractualmente. Las calculadoras de TCO que ofrece SAP sugieren una estructura de costes estable a largo plazo, pero ocultan en la letra pequeña el incremento automático anual de las tarifas de un 3,3 % fijo, que se indica en el formulario de pedido siguiendo el principio de un alquiler escalonado.

A lo largo de un contrato de cinco años, habitual en el mercado, este recargo aparentemente pequeño se traduce en un enorme aumento de los costes de casi el 18 %. Sin embargo, el incremento financiero alcanza su punto álgido cuando se trata de la disponibilidad de los sistemas críticos para el negocio.

Acuerdo de nivel de servicio

Si al cliente actual de S/4 no le basta con el acuerdo de nivel de servicio (SLA) del 99,7 % incluido en el estándar de SAP —por ejemplo, porque en una producción global «justoen la que cada minuto de interrupción del sistema cuesta millones—, y solicitan un aumento hasta el 99,9 % habitual en el sector, SAP responde sin piedad. Por este aumento mínimo del 0,2 %, el grupo exige un recargo astronómico del 50 % sobre el total de la cuota contractual neta anual recurrente de todos los productos afectados. En el caso de un entorno de sistemas moderado con un valor anual de las licencias de Rise de un millón de euros, esto supone unos costes adicionales recurrentes de nada menos que medio millón de euros al año: una relación calidad-precio que no tiene parangón en todo el sector de las tecnologías de la información.

La situación se vuelve especialmente dramática cuando el cliente actual de Rise se plantea los riesgos que conlleva una migración a S/4: ¡En este caso, SAP obliga a sus clientes a realizar un doble pago muy arriesgado! El cliente tiene que pagar tanto por el servicio de conversión como por la suscripción a la nube en curso. Si durante el proyecto surgen complicaciones imprevistas, una grave escasez de personal cualificado o incluso una paralización total del proyecto, se pone de manifiesto la implacable dureza del contrato de la nube.

Aunque SAP pueda mostrarse flexible y renunciar a parte de los costes de los servicios de conversión en caso de que se cancele un proyecto, el cliente sigue estando obligado contractualmente, sin excepción, a abonar íntegramente la suscripción mensual a la nube correspondiente a los sistemas no utilizados. En este escenario, el cliente actual se encuentra ante las ruinas de su infraestructura informática: El camino de vuelta al entorno local está cortado, ya que las licencias ya se han convertido y eliminado, y el camino hacia la nube está bloqueado debido al fracaso del proyecto de migración, mientras que las cuotas mensuales de alquiler siguen acumulándose inexorablemente.

Nueva tecnología con viejos problemas

Este sistema viene acompañado de la obligación incondicional de utilizar la base de datos HANA. Los clientes que durante décadas han gestionado sus sistemas ERP de forma rentable y estable en bases de datos de terceros, como Oracle o DB2, se enfrentan a una expropiación en toda regla al pasar a la nube privada: SAP no reconoce el valor de las licencias de base de datos anteriores, que caducan sin compensación alguna, mientras que, al mismo tiempo, se aplica un considerable recargo, que suele ser del 15 %, por la base de datos Hana Runtime.

Además, quien intente conectar de forma flexible sus flujos de datos, dentro de una cadena de suministro interconectada, a sistemas de terceros o a modernas plataformas de IA, se encontrará de inmediato con el siguiente peaje, denominado «Digital Access». Dado que este uso indirecto no suele estar incluido en Rise Private Cloud, cada documento creado a través de interfaces debe obtener una licencia adicional. Quien quiera evitarlo se verá obligado a recurrir a la Business Technology Platform (SAP BTP) y a la Business Data Cloud (SAP BDC). Sin embargo, allí les esperan créditos poco transparentes que deben pagarse por adelantado y que caducan al final del año contractual si no se utilizan, mientras que cualquier exceso se factura implacablemente a los costosos precios de catálogo.

Desde el punto de vista empresarial, SAP afirma que el paquete Rise en la nube privada puede reducir el coste total de propiedad (TCO) hasta un 20 % en comparación con una instalación local clásica. Sin embargo, esta afirmación rara vez resiste un análisis detallado, ya que suele basarse en supuestos poco realistas sobre los costes ineficientes de los centros de datos propios. En realidad, el cambio a la nube privada supone una transformación contable en la que los activos fijos (CapEx) se convierten en gastos operativos recurrentes y permanentes (OpEx). Este proceso es, de hecho, irreversible para los clientes actuales de SAP. Al firmar el contrato de la nube, el usuario del ERP renuncia a sus valiosos derechos de uso «on-prem» de duración ilimitada y los canjea por un contrato de alquiler volátil en el que, en el peor de los casos, tras una rescisión, se queda con datos brutos inútiles sin los algoritmos de interpretación de SAP. El camino hacia la S/4 Private Cloud Edition resulta, por tanto, un campo minado desde el punto de vista empresarial en casi todos los niveles. Quien confíe en las promesas de los comerciales de SAP sin una estrategia de TI bien fundamentada, sin asesoramiento jurídico especializado, sin herramientas independientes de medición de licencias y sin un análisis riguroso, no solo renuncia a su soberanía digital, sino que se arriesga a una explosión incontrolable del coste total de propiedad durante años.