La nube: innovación técnica, presión por la transformación empresarial y soberanía digital

En el centro de este cambio de era impulsado por la computación en la nube se encuentra el cambio de paradigma que pasa de la compra clásica de software al acceso, mediante suscripción, a funcionalidades informáticas a través de infraestructuras en la nube. Sin embargo, para la cartera mundial de clientes del líder mundial del mercado de ERP, SAP, esta evolución no supone en absoluto solo un cambio generacional técnico, sino una reorganización comercial, jurídica y organizativa.

Impulsada por las expectativas de los mercados internacionales de capitales, que exigen ingresos por suscripción recurrentes y predecibles, la dirección del grupo SAP ha abandonado de hecho la estrategia de venta exclusiva de software. Al fijar el fin del servicio de mantenimiento para la consolidada SAP Business Suite 7 y el sistema central SAP ERP 6.0 a finales de 2027 —acompañado de una prórroga opcional de pago opcional de pago hasta finales de 2030—, se ejerce una inmensa presión de transformación tanto sobre las pymes como sobre los grandes grupos empresariales.

Esta situación apremiante exige a los responsables de los departamentos de TI, de la dirección y de los Centros de Experiencia para Clientes (CCoE) un análisis sobrio y crítico: Las tentaciones de la retórica del marketing de la nube prometen procesos empresariales más ágiles, un acceso sin complicaciones a la inteligencia artificial y una reducción drástica de los costes operativos. Sin embargo, la realidad empresarial en los países de habla alemana y en todo el mundo revela un alto grado de escepticismo y desilusión en cuanto a la arquitectura. Una parte considerable de los clientes actuales de SAP se resiste a la y precipitada transición hacia arquitecturas de nube pública y busca formas de garantizar su propia soberanía digital, el control sin interferencias sobre los activos críticos para el negocio y la conservación del valor de las lógicas de procesos desarrolladas a lo largo del tiempo, como las modificaciones de ABAP.

En este contexto, el tema del «cloud computing» pasa de ser una mera decisión técnica sobre infraestructura a convertirse en una cuestión vital relacionada con la libertad de actuación estratégica. La diferenciación teórica de la computación en la nube se divide tradicionalmente en los tres modelos de servicio conocidos: Infraestructura como servicio (IaaS), Plataforma como servicio (PaaS) y Software como servicio (SaaS).

IaaS, PaaS y SaaS

Mientras que IaaS se limita a proporcionar potencia de cálculo puramente virtual, soportes de almacenamiento y capacidades de red, PaaS ofrece a los clientes actuales de SAP entornos de ejecución estructurados, bases de datos y servicios de aplicaciones. El modelo SaaS, por su parte, supone la eliminación total de la gestión interna de la infraestructura de TI, ya que se pone a disposición de los usuarios de ERP, a través de Internet y «llave en mano», la aplicación de software lista para su uso, incluidas todas las tareas de mantenimiento y funcionamiento.

Sin embargo, en la realidad práctica de las empresas industriales complejas se ha puesto de manifiesto que los enfoques SaaS rígidos y monolíticos rara vez satisfacen los requisitos altamente diferenciados de las cadenas de valor modernas. Se necesitan, más bien, arquitecturas de nube híbridas y flexibles que coordinen a la perfección los centros de datos locales, las instancias de nube privada dedicadas y las capacidades escalables de los hiperescaladores.

En este contexto, Red Hat, especialista en código abierto, desempeña un papel clave para todo el ecosistema de SAP. Mientras que Linux lleva muchos años siendo el sistema operativo estándar indiscutible para SAP HANA, la base de la base de datos en memoria, el sistema operativo Red Hat Enterprise Linux (RHEL) se ha convertido en la columna vertebral preferida y la base estándar tanto para los entornos de TI internos de SAP como para toda la cartera de clientes de SAP Enterprise Cloud Services. La colaboración entre SAP y Red Hat garantiza que las exigentes cargas de trabajo de SAP puedan ejecutarse en una infraestructura reforzada, certificada y a prueba de fallos, independientemente de si esto tiene lugar en un centro de datos local propio o en las infraestructuras de hiperescaladores globales.

Kubernetes para empresas

Sin embargo, la verdadera liberación arquitectónica de los clientes actuales de SAP respecto a las ataduras a soluciones propietarias solo se consigue mediante el uso de la plataforma Enterprise Kubernetes Red Hat OpenShift. OpenShift actúa como una capa universal de abstracción e integración que, al ser independiente del proveedor, se superpone a las infraestructuras tradicionales locales, a los entornos de alojamiento privados y a las plataformas públicas de Microsoft Azure, Amazon Web Services y Google Cloud. Gracias a esta abstracción independiente de la nube, OpenShift protege al usuario frente a un bloqueo progresivo por parte del proveedor de la nube correspondiente. Los desarrolladores de ERP y los arquitectos de TI ganan libertad estratégica para diseñar las aplicaciones una sola vez y ejecutarlas de forma flexible en cualquier lugar: «¡Desarrolla una vez, implementa en cualquier lugar!»

La combinación de OpenShift con la Red Hat Ansible Automation Platform permite, además, la automatización completa de extremo a extremo de entornos de sistemas complejos, procesos de implementación, políticas de seguridad y tareas operativas diarias de TI. Un ejemplo destacado de la integración de código abierto y la arquitectura SAP en el ámbito de las tecnologías de la información es la SAP Edge Integration Cell (EIC), que actúa como sucesora moderna y contenedorizada de los sistemas clásicos de orquestación de procesos.

„Garantizamos la seguridad en la nube con agentes de IA mediante
”la creación de un entorno de ejecución junto con nuestro socio tecnológico Nvidia».”

Thomas Pfiester,
Responsable de Compromiso y Adopción de Clientes a Nivel Global,
SAP, (Ponente principal en el congreso anual de la DSAG)

Edge Integration Cell requiere un entorno de ejecución de Kubernetes a prueba de fallos y ha sido homologado oficialmente para Red Hat OpenShift, lo que permite a las empresas gestionar puntos finales de API e integraciones de datos críticos para el negocio de forma local, en sus propias instalaciones o en una nube privada, al tiempo que se garantiza la conexión con la Business Technology Platform (SAP BTP). También en el marco de las infraestructuras de Microsoft, el Azure Center for SAP Solutions se basa en el SAP Deployment Automation Framework (SDAF), desarrollado conjuntamente, y utiliza componentes de Red Hat para la implementación automatizada de la infraestructura. El código abierto y las plataformas híbridas de contenedores demuestran así ser el escudo indispensable para salvaguardar la soberanía digital del sector industrial europeo en la nube.

Un análisis de la cartera de productos de SAP revela una amplia gama de opciones operativas y de licencia que difieren drásticamente entre sí en cuanto a su alcance funcional, su flexibilidad de configuración y sus obligaciones comerciales. En el extremo tradicional de este espectro se encuentra el modelo clásico «on-prem». En este caso, la empresa usuaria adquiere o alquila las licencias de software y gestiona el sistema S/4 en su propio centro de datos o mediante un servicio de alojamiento dedicado prestado por un proveedor. La ventaja inestimable de esta variante radica en el control ilimitado del sistema, la total libertad de configuración en el backend y la gestión de versiones y parches sin restricciones temporales. La empresa conserva la soberanía absoluta sobre los datos y no se ve obligada a seguir los rígidos ciclos de actualización del fabricante.

Sin embargo, la grave desventaja radica en la total responsabilidad de la empresa en lo que respecta al hardware, las copias de seguridad de las bases de datos, la fiabilidad frente a fallos y la necesidad de contar con personal informático altamente especializado. Además, SAP excluye cada vez más a los clientes actuales con instalaciones exclusivamente locales de ampliaciones innovadoras, como escenarios de IA nativos o funciones específicas de BTP, con el fin de aumentar artificialmente la presión para migrar.

Ascender y crecer con SAP

SAP promueve el paquete integral «Rise with SAP» como la vía principal de transformación para la cartera de clientes actual. El núcleo de este programa lo constituye S/4 Hana Cloud Private Edition. Desde el punto de vista técnico, la nube privada es un sistema dedicado de un único inquilino que se ejecuta en la infraestructura de SAP o de hiperescaladores seleccionados y se ofrece como servicio gestionado.

A diferencia de la nube pública, la Private Edition ofrece prácticamente el mismo conjunto de funciones empresariales, así como la amplia cobertura sectorial de la versión on-prem. Con la Edición Privada, los clientes actuales pueden seguir utilizando la interfaz gráfica de usuario (GUI) de SAP a la que están acostumbrados, realizar personalizaciones exhaustivas y continuar con los desarrollos Z existentes, mientras que el funcionamiento básico de la infraestructura, la aplicación de parches de seguridad y los servicios técnicos definidos se transfieren a SAP. No obstante, incluso dentro de la Edición Privada, SAP aumenta continuamente la presión sobre los clientes para que cumplan el principio «Clean Core» y trasladen gradualmente las ampliaciones específicas de cada cliente a la Business Technology Platform o a estructuras desacopladas.

El polo opuesto lo representa el paquete comercial «Grow with SAP», dirigido específicamente a nuevos clientes, empresas medianas con procesos muy estandarizados o filiales independientes. La base de «Grow» es la S/4 Hana Cloud Public Edition, un auténtico producto SaaS multitenant con capacidad para múltiples clientes.

En la nube pública, varios clientes comparten la infraestructura física y las funciones básicas del software, mientras que los datos permanecen estrictamente separados a nivel lógico. Este modelo promete tiempos de implementación cortos, innovaciones funcionales continuas y la aplicación totalmente automática de actualizaciones del sistema directamente por parte de SAP. Sin embargo, esta aparente comodidad conlleva importantes limitaciones: queda categóricamente excluido el acceso directo al código backend de ABAP o a la capa clásica de la base de datos. Las adaptaciones solo son posibles a través de extensiones predefinidas dentro de la aplicación o mediante extensiones externas «side-by-side» en la BTP. El cliente de SAP Cloud debe estar dispuesto a subordinar radicalmente sus procesos operativos a las mejores prácticas predefinidas por SAP.

La migración de un entorno tradicional on-premise al mundo en la nube de Rise o Grow conlleva una necesaria reorganización de las condiciones contractuales y contables. En el entorno histórico de R/3 o ECC, las empresas adquirían licencias perpetuas (Perpetual Licenses), que se contabilizaban en el balance como activos fijos (CapEx). A ello se sumaba una cuota de mantenimiento anual, normalmente del 22 %, que cubría el soporte técnico y el derecho a recibir actualizaciones de software.

Al suscribir un contrato de suscripción en la nube, esta estructura se transforma por completo en gastos operativos corrientes (OpEx). La propiedad del software sigue siendo del fabricante; el cliente solo adquiere un derecho de uso temporal en forma de alquiler. Si la empresa deja de pagar las cuotas mensuales o anuales, se pierde por completo el acceso al sistema ERP en la nube.

Métrica de licencias en la nube

El instrumento de control fundamental de esta transformación de las licencias es la métrica del «Full Use Equivalent» (FUE). En lugar de adquirir, como antes, un número exacto de tipos específicos de licencias de usuario (como «Professional», «Functional» o «Productivity User»), la empresa se suscribe a un saldo variable de puntos FUE. La conversión de los distintos tipos de uso de S/4 Cloud se realiza mediante factores de equivalencia fijos: Un FUE equivale exactamente a un «S/4 for Advanced Use» (comparable con el antiguo «Professional User»), a cinco «S/4 for Core Use» (comparables con el «Functional User») o a treinta «S/4 for Self-Service Use».

Para el acceso de desarrolladores (Developer Access), SAP exige en la clave FUE una proporción de dos FUE por desarrollador. Mientras que SAP promociona el modelo FUE como una solución flexible que permite reasignar capacidades según las necesidades dentro de los tramos de usuarios contratados sin necesidad de largas renegociaciones contractuales, los expertos independientes en licencias advierten de drásticos aumentos de precios ocultos.

El principal factor de coste del modelo FUE radica en el cambio administrativo de una medición del sistema basada en el uso (Did-Do) a otra basada en los permisos (Could-Do). Mientras que en el antiguo entorno ECC se medía qué transacciones había realizado realmente un empleado en la práctica, en las ediciones S/4 Cloud, SAP concede licencias de forma rigurosa en función de las autorizaciones y los roles asignados en el sistema.

Si un empleado, debido a „perfiles gigantescos“ acumulados a lo largo del tiempo y sin depurar, o a asignaciones generales de perfiles del sistema, tiene, en teoría, la autorización para acceder a funciones avanzadas de logística o finanzas, la herramienta de verificación del fabricante (el servicio STAR o S/4 Trusted Authorization Review) lo clasifica automáticamente en la categoría de licencia más cara (Advanced Use), incluso aunque nunca utilice estas funciones en su trabajo diario. Sin una revisión exhaustiva de las estructuras de autorizaciones antes de la transición a un contrato en la nube, los clientes actuales corren el riesgo de sufrir un aumento de los costes de entre el 20 % y el 50 % con respecto a sus cuotas de mantenimiento locales anteriores.

Además de las suscripciones FUE, los modelos de facturación basados en el consumo (Consumption Models) en la Business Technology Platform y dentro de la Business Data Cloud (SAP BDC) aumentan el riesgo comercial. A través de las unidades de capacidad de la BTP, los créditos de nube o las unidades de IA en función del consumo, el cliente paga por el uso real de la potencia de cálculo, los volúmenes de datos o los tokens de IA.

Facturas sorpresa por servicios en la nube

El reto contractual radica aquí en una lógica de caducidad: los contingentes de crédito pagados por adelantado (como en el marco de un contrato CPEA o BTPEA) caducan al final del año contractual correspondiente sin posibilidad de sustitución si no se han consumido por falta de casos de uso productivos. Por el contrario, si durante el funcionamiento se producen picos de carga imprevistos o consultas de datos incontroladas, SAP factura inmediatamente el consumo adicional a los precios de catálogo, significativamente más elevados, lo que suele provocar las temidas «sorpresas en la factura de la nube».

Esta estricta monetización va acompañada del modelo de licencia basado en documentos «Digital Access», así como de la cuarta versión de la Política de API de SAP, promulgada en abril de 2026. Con la Política de API, Walldorf ha erigido una barrera arancelaria digital que regula la extracción directa y sin licencia de datos masivos, así como el acceso de agentes de IA externos al sistema ERP.

Quien exporte datos críticos para el negocio a sistemas de terceros sin pagar la costosa «tasa BTP» se verá obligado a abonar tasas por uso indirecto o licencias basadas en el volumen de datos. Las asociaciones europeas de usuarios, como la DSAG y la asociación de la nube CISPE, condenan enérgicamente esta práctica, calificándola de intento, cuestionable desde el punto de vista de la legislación antimonopolio, de imponer un mercado cerrado y de encadenar implacablemente a los usuarios al ecosistema propietario de BTP.

La comparación directa de los tres modelos operativos principales pone de manifiesto profundas diferencias estructurales que van mucho más allá de las meras cuestiones de alojamiento. En el ámbito de la gobernanza del sistema y la flexibilidad operativa, el modelo clásico «on-prem» sigue siendo el punto de referencia para las empresas industriales de alta complejidad: El usuario conserva el control absoluto sobre el momento en que se realizan las actualizaciones del sistema, los paquetes de funciones y los parches de la base de datos. No existen ventanas de mantenimiento obligatorias predefinidas y los desarrollos personalizados para cada cliente en el espacio de nombres ABAP pueden ejecutarse sin restricciones. No obstante, la empresa debe organizar por su cuenta o mediante contratos con proveedores de servicios independientes todas las tareas relacionadas con el dimensionamiento del hardware, la gestión del sistema operativo, la administración de la base de datos y el cumplimiento de las complejas normas de cumplimiento normativo y seguridad informática.

La S/4 Cloud Private Edition (en el marco de Rise with SAP) pretende combinar la completitud funcional del sistema on-prem con la comodidad de un entorno de nube gestionado. Desde un punto de vista técnico, se trata de una instancia aislada de un único inquilino, en la que el alojamiento recae en SAP, pero el cliente actual conserva amplios derechos de participación en la toma de decisiones respecto al hiperescalador específico (Azure, AWS, Google Cloud o proveedores europeos) y de la ubicación geográfica concreta del centro de datos.

Nube privada frente a infraestructura local

El conjunto de funciones de Cloud Private Edition incluye las 31 soluciones sectoriales y las 39 versiones lingüísticas del entorno on-prem. Aunque los clientes actuales de SAP disfrutan de una estrategia de actualización mucho más flexible que en la nube pública y pueden aplazar las actualizaciones del sistema dentro del periodo de mantenimiento habitual, siguen estando sujetos a los requisitos de infraestructura de SAP. El dimensionamiento del almacenamiento de la base de datos HANA y de los servidores de aplicaciones está directamente vinculado al volumen de FUE contratado; si un sistema necesita memoria adicional debido a análisis complejos en memoria sin que aumente el número de usuarios, es necesario adquirir licencias adicionales para costosos complementos de infraestructura.

Por el contrario, la S/4 Cloud Public Edition (en el marco de «Grow with SAP») representa el concepto de nube más radical. Al tratarse de un auténtico modelo SaaS multitenant, ofrece los costes operativos específicos más bajos para la infraestructura de TI, ya que las actualizaciones de software, los parches de seguridad y el escalado de la infraestructura se gestionan de forma totalmente automática por parte de SAP en segundo plano. El núcleo funcional crece automáticamente con las versiones semestrales de SAP.

Modificaciones Abap

Sin embargo, la nube pública exige una sumisión absoluta al dictado de «Clean Core». Los desarrollos clásicos en Z, las modificaciones de objetos estándar de SAP o el acceso directo de escritura a las tablas de la base de datos son técnicamente imposibles. Las empresas con procesos de fabricación especializados, soluciones específicas desarrolladas a lo largo del tiempo o integraciones complejas con sistemas de terceros se topan rápidamente con barreras insuperables en la edición pública. Esto explica por qué, según los informes de inversión de DSAG, una abrumadora mayoría de los clientes actuales consolidados de la región DACH sigue rechazando la nube pública para su núcleo central de ERP y opta, en su lugar, por escenarios on-prem o de nube privada controlada.

Se ha producido un cambio notable en la comunicación estratégica de la dirección del grupo SAP: en la conferencia internacional de clientes Sapphire 2026, celebrada en Orlando, se enterró poco a poco la arquitectura North Star de la clásica SAP Business Suite 7, tan alabada durante años. En su lugar, ha surgido la espectacular visión de futuro de la „SAP Autonomous Enterprise“. Desde esta nueva perspectiva centrada en la inteligencia artificial, S/4 HANA no resulta en absoluto el punto final de la evolución del ERP, sino simplemente la base de datos transaccional necesaria y una etapa de transición imprescindible. El núcleo clásico del ERP queda relegado a un mero «sistema de registro» que actúa en segundo plano como un servidor de contabilización fiable, mientras que la gestión real de los procesos y la interacción con el usuario se trasladan a capas de inteligencia superiores.

La interfaz de usuario Joule Work, en combinación con SAP Autonomous Suite, constituye la cara operativa de esta nueva era. En lugar de que los empleados tengan que abrir cientos de mosaicos de Fiori o introducir códigos de transacción complejos, describen sus intenciones empresariales en lenguaje natural. En segundo plano, más de 50 asistentes de Joule específicos para cada ámbito y más de 200 agentes de IA especializados coordinan procesos autónomos de principio a fin en las áreas de finanzas, compras, cadena de suministro y recursos humanos. Un asistente autónomo como el „Autonomous Close Assistant“ se encarga del análisis autónomo de las desviaciones, la conciliación de cuentas y la preparación del cierre mensual, mientras que la persona, en el marco del concepto „Human in the Loop“, solo interviene en situaciones excepcionales que no pueden resolverse de otro modo.

Para que estos agentes de IA puedan comprender el complejo modelo de datos históricos de SAP (basado en SQL Server), compuesto por más de siete millones de campos de datos y decenas de miles de tablas, el SAP Knowledge Graph actúa como un cerebro semántico indispensable. El Knowledge Graph traduce automáticamente las tablas de bases de datos relacionales en ontologías legibles por máquina y en un modelo de red formado por nodos y aristas. Proporciona a los modelos de lenguaje y a los agentes de IA el contexto empresarial exacto —por ejemplo, qué significan las redes de relaciones entre los pedidos de los clientes, los datos maestros de materiales, las facturas y las órdenes de entrega— para suprimir de forma eficaz las alucinaciones estocásticas en el libro mayor, que es fundamental para el negocio.

Gráfico de conocimientos SAP

Sin embargo, la afirmación de que los agentes de IA y el SAP Knowledge Graph podrían hacer que un sistema ERP clásico resultara totalmente innecesario en el futuro no resiste un análisis riguroso: Un sistema ERP sigue siendo insustituible, ya que las funciones empresariales fundamentales, como la contabilidad financiera, el cumplimiento de la normativa fiscal, la contabilidad de costes y la elaboración de balances con seguridad jurídica, exigen una exactitud absoluta y determinista.

Los modelos lingüísticos se basan en cálculos probabilísticos; las leyes fundamentales de la teoría de la información demuestran que una IA estocástica nunca puede garantizar una precisión del cien por cien. Si un agente de IA probabilística actuara sin la lógica basada en reglas de un núcleo ERP determinista, incluso las desviaciones más mínimas darían lugar a contabilizaciones legalmente inadmisibles o a autorizaciones de producción erróneas. Por lo tanto, S/4 Hana y el ERP en la nube siguen siendo la base matemática indispensable sobre la que se asienta la autonomía cognitiva de los agentes de IA como capa de control.

La perspectiva a largo plazo de la computación en la nube en el entorno SAP se ve cada vez más dominada por cuestiones relacionadas con la resiliencia geopolítica, la seguridad jurídica y la necesidad de evitar una dependencia irreversible del fabricante. Mientras que SAP ejerce una enorme presión sobre sus clientes actuales para que adopten estructuras de nube propietarias, en los contratos oficiales sigue sin figurar una estrategia de salida de la nube que sea viable tanto desde el punto de vista técnico como comercial.

Salida del mercado de la nube y la IA

Quien haya convertido sus licencias de compra locales existentes en suscripciones en la nube en el marco de una conversión de contrato, destruye irremediablemente su activo fijo histórico. Al abandonar la nube de SAP, el cliente se queda con datos brutos sin valor alguno, ya que carecen de los algoritmos propios de la nube y de los entornos de ejecución.

Aún más dramática resulta la falta de una estrategia de salida en materia de IA: Dado que SAP no cuenta con competencias propias en el ámbito de los modelos cognitivos básicos y se basa principalmente en pioneros estadounidenses como Anthropic (con el modelo Claude), los usuarios europeos se vuelven extremadamente vulnerables ante las decisiones geopolíticas de gobiernos extranjeros.

En esta delicada situación, el marco jurídico de la Unión Europea —en concreto, la Ley de Datos de la UE, publicada en el Diario Oficial el 22 de diciembre de 2023— ofrece un importante rayo de esperanza para recuperar la soberanía digital. La Ley de Datos de la UE tiene por objeto facilitar el cambio entre distintos proveedores de servicios en la nube y prohibir por ley las barreras artificiales al cambio, las tarifas excesivas por la transferencia de datos y las cláusulas contractuales abusivas.

Aunque los modelos de contrato de la UE y las disposiciones técnicas de aplicación para entornos ERP complejos aún se encuentran en fase de elaboración, la legislación europea obliga cada vez más a proveedores como SAP a ofrecer interfaces abiertas y mecanismos estandarizados de portabilidad de datos. Esta evolución normativa viene acompañada de iniciativas de proveedores de infraestructura europeos como StackIT (el hiperescalador europeo del Grupo Schwarz), que ofrecen cargas de trabajo Rise basadas en la legislación europea y sin el riesgo que supone la Ley de la Nube de EE. UU. (Cloud Act).

Para diseñar de forma práctica una estrategia de salida de la nube y de desacoplamiento con garantía de futuro, las empresas usuarias deben apostar por estándares de arquitectura modernos e independientes del proveedor: En lugar de programar de forma rígida algoritmos específicos para cada cliente en la BTP propietaria o vincularse exclusivamente al SAP Knowledge Graph, se está imponiendo la creación de una „Enterprise Semantic Backbone“ independiente del proveedor.

A través de formatos estándar de código abierto del W3C, como el Resource Description Framework (RDF) y el lenguaje de consulta SPARQL, las empresas pueden modelar de forma autónoma sus ontologías específicas de negocio y sus relaciones entre datos en plataformas de código abierto soberanas (como SUSE Rancher, SUSE AI o Red Hat OpenShift).

Además, el Model Context Protocol (MCP), independiente del fabricante, desempeña un papel absolutamente clave para el funcionamiento desacoplado de los agentes de IA. Como estándar abierto —comparable a un conector USB-C universal para sistemas de IA—, el MCP establece una separación clara entre los modelos de lenguaje y el núcleo transaccional del ERP. A través de servidores MCP desacoplados (como los que ofrecen proveedores como Boomi, SUSE o las comunidades de código abierto), los agentes de IA pueden acceder a los datos de S/4 de forma segura, controlada y totalmente auditable, sin que el cliente actual de SAP caiga en la trampa de las licencias impredecibles de la Política de API de SAP.

Para el Centro de Excelencia para Clientes (CCoE) y la dirección de TI de un cliente actual de SAP, la conclusión de este análisis es la siguiente: „Aprovechen las ventajas técnicas de la nube y la inteligencia artificial allí donde aporten un verdadero valor añadido empresarial. Sin embargo, mantengan al mismo tiempo un control estricto sobre la arquitectura de sus sistemas. Al depurar sistemáticamente su núcleo con SAP Clean Core, optimizar sus licencias en cuanto a derechos de acceso antes de firmar cada contrato, apostar por bases de nube híbrida de código abierto como Red Hat y desacoplar sus estructuras de datos mediante estándares abiertos como MCP y RDF, se asegurará un futuro ERP sostenible, ágil y con soberanía digital, a la altura del fabricante“.“