Las ventas de SAP: los grandes contra los pequeños


Existe una declaración muy antigua del exdirector financiero de SAP, Werner Brandt, en la que explica que no hay dos clientes actuales de SAP con el mismo contrato de licencia. Es una tradición arraigada en el departamento de ventas de SAP definir condiciones y normas específicas para cada cliente actual. Ni siquiera en esta era incipiente de la nube ha conseguido SAP armonizar y consolidar las estructuras contractuales. Mis compañeros y compañeras de la tertulia cuentan multitud de anécdotas sobre las negociaciones de licencias. Solo una estrategia parece ser siempre la misma: los grandes clientes actuales de SAP con nombres de renombre obtienen mejores condiciones. ¡Y además hay un millón de créditos BTP que no caducan al final del año!
Detrás de los relucientes folletos y las ponencias visionarias del director general de SAP, Christian Klein, se esconde, para los clientes actuales de SAP, un punto de inflexión en materia de licencias y gestión empresarial que, por un lado, introduce modernizaciones necesarias, pero, por otro, aprieta las cadenas de la dependencia con más fuerza que nunca. Un breve vistazo a la cartera actual de SAP muestra que el supuesto salto a la nube y a la era de la IA se caracteriza, en realidad, por una rígida política de aislamiento y por complejos modelos de licencia y desarrollo. Para no perder por completo su soberanía digital, tanto los pequeños como los grandes clientes actuales deben comprender en detalle los mecanismos técnicos y comerciales que se esconden tras conceptos como «Clean Core», «API Policy», «ABAP Cloud» y «Business Data Cloud».
Sin embargo, para nosotros, como gran empresa, la restricción de la libertad de los desarrolladores se plantea de forma muy diferente a como lo ven muchos de mis compañeros y compañeras de las pequeñas y medianas empresas: durante décadas, ABAP fue el terreno de juego de los desarrolladores internos y los socios. A través de las modificaciones Z se intervenía profundamente en el código estándar. Esta era de libertad sin límites ha llegado definitivamente a su fin en el marco del nuevo modelo de desarrollo ABAP en la nube, ¡lo que también tiene consecuencias duraderas en nuestra política de personal! SAP ha impuesto una medida formativa que se conoce con el nombre de «Clean Core». El objetivo principal es, sin duda, razonable: la separación de la lógica empresarial básica de las ampliaciones individuales. Que a SAP, a la hora de imponer el «Clean Core», no solo le preocupa la elegancia técnica, sino sobre todo el control estratégico del mercado, quedó patente a finales de abril de 2026 con la publicación de la nueva Política de API de SAP. Con el pretexto de minimizar los riesgos de seguridad y garantizar la estabilidad del sistema, SAP ha regulado drásticamente el acceso directo al sistema ERP —¡mi jefe del CCoE se quedó horrorizado!
Desde el punto de vista de los directores de mi CCoE, esta política supone un ataque directo a la interoperabilidad y a la capacidad de innovación de los clientes actuales de SAP. La política prohíbe, en la letra pequeña, las extracciones sistemáticas de datos a gran escala hacia almacenes de datos externos o lagos de datos, siempre que dicho caso de uso no haya sido documentado explícitamente por SAP. Y lo que es aún más preocupante: el uso de la API se restringe drásticamente para la interacción con sistemas de IA (semi)autónomos o generativos de terceros.
Nuestra DSAG se opone rotundamente a este dictado: advierte de los enormes riesgos que supone para los procesos «de extremo a extremo» existentes, de una destrucción progresiva de los modelos de negocio consolidados de los socios y de riesgos de costes incalculables en las renovaciones de contratos. SAP intenta establecer aquí un «closed shop» para impedir la salida directa de datos hacia las potentes plataformas de IA de los hiperescaladores.
La presión comercial que genera la política de API se integra a la perfección en la estrategia de datos de SAP. El que fuera el buque insignia de la gestión de datos, Data Warehouse Cloud, ha sido sustituido por Datasphere, que ahora actúa como capa semántica dentro del paquete de soluciones superior denominado Business Data Cloud (SAP BDC). Aunque Datasphere, en su calidad de Business Data Fabric, pretende permitir una federación y virtualización fluidas de datos de SAP y de otros proveedores, y presume de colaboraciones con empresas como Databricks o Snowflake, Sin embargo, la realidad de las licencias empaña este panorama. La comunidad global de SAP y nuestra propia DSAG se burlan de BDC llamándola «Business Data Complexity».
noname@e3mag.com



