¿Has transformado tu ERP con SAP S/4HANA… pero sigues realizando
procesos manuales?

Con la integración de Dost, desarrollada por GROUPmee, incorporas
una capa de automatización inteligente que optimiza la ejecución
operativa directamente sobre SAP S/4HANA.

Desde la captura y comprensión de documentos con IA hasta la
conciliación automática y la gestión avanzada de aprobaciones, Dost
reduce fricciones, elimina tareas manuales y aporta visibilidad en
tiempo real.

Una evolución natural para llevar la eficiencia de tus procesos al
nivel de tu ERP.

Más automatización. Más control. Más capacidad de decisión.

Cuando SAP presentó su asistente de inteligencia artificial en septiembre de 2023, le puso un nombre que no es un acrónimo ni una sigla. Joule hace referencia a la unidad de energía que en español llamamos julio ( la misma que aparece en los libros de física del colegio ) y que mide cantidad de energía, calor y trabajo.

¿Y de dónde viene esa unidad? Del físico, matemático y cervecero inglés del siglo XIX James Prescott Joule, uno de los científicos más importantes de su época, conocido por su trabajo en termodinámica y por establecer la primera ley de la conservación de la energía. Sí, cervecero. Hacía sus experimentos en el laboratorio que montó en casa de su padre, que era dueño de una fábrica de cerveza. Otro que empezó en un garaje, pero en versión victoriana.

La elección del nombre no es casual. La idea detrás de Joule es precisamente esa, que los usuarios de SAP gasten menos energía ( o joules ) aprovechando el copiloto para mejorar su eficiencia. Menos trabajo manual, más inteligencia aplicada. Bonita metáfora.

Lo curioso es que un nombre inspirado en un físico del siglo XIX que estudiaba cómo se transforma la energía... ahora es el nombre de la herramienta con la que SAP quiere transformar cómo trabajamos con el ERP más usado del mundo. Y como hemos visto en este número, ese Joule lleva años prometiendo mucho... y todavía le queda camino por recorrer.

La noticia más importante del ecosistema SAP en mayo de 2026 llegó el día 4: SAP anunció la adquisición de Dremio, una plataforma de data lakehouse diseñada para acelerar la IA agéntica y unificar datos SAP con datos de terceros, y de Prior Labs, comprometiendo más de 1.000 millones de euros en cuatro años para convertirla en un laboratorio de IA de referencia mundial.

Dos adquisiciones en el mismo día. Mucho dinero. Muchos titulares. Pero la pregunta que nadie está respondiendo en los comunicados de prensa es la que realmente importa a los que trabajamos en proyectos reales: ¿esto cambia algo para el consultor funcional o técnico hoy?

El CTO de SAP, Philipp Herzig, lo resumió con una frase que lo explica todo: "La IA empresarial no falla porque los modelos no sean suficientemente buenos. Falla porque los datos no están listos para los agentes de IA."

Ese es exactamente el problema que Dremio resuelve. La plataforma permite almacenar y analizar grandes volúmenes de datos empresariales basándose en Apache Iceberg, un formato abierto estándar del sector que permite que los datos de SAP y los de otros proveedores coexistan en una misma base sin necesidad de moverlos ni convertirlos. Dicho en cristiano: SAP podrá darle a sus agentes de IA acceso a datos que no son suyos ( de Salesforce, de Oracle, de cualquier sistema externo ) sin montar una integración compleja. Eso es enorme sobre el papel.

Prior Labs es una startup alemana fundada en 2024 especializada en modelos fundacionales tabulares ( los llamados TFM ) que están específicamente diseñados para procesar datos estructurados en filas y columnas, como registros financieros, inventarios o datos de cadena de suministro. Los modelos de lenguaje grandes como GPT no funcionan bien con ese tipo de datos. Los TFM sí.

En la práctica esto significa que SAP quiere una IA que no solo entienda texto sino que razone sobre los datos estructurados de negocio (facturas, pedidos, posiciones contables ) con la misma naturalidad. Ambicioso. Muy ambicioso.

Ninguna de las dos capacidades está disponible en producción hoy. Ambas transacciones están pendientes de aprobación regulatoria y se esperan cerrar en el tercer trimestre de 2026. La integración real de Dremio en SAP Business Data Cloud llevará tiempo adicional después del cierre.

Y hay algo más que los analistas apuntan sin mucho ruido: las empresas que SAP adquiere ( Reltio, Dremio y en cierta medida Prior Labs ) comercialmente no estaban en su mejor momento comparado con su pasado más brillante. No significa que los activos tecnológicos no valgan la pena, pero conviene tenerlo en cuenta antes de dejarse llevar por el hype.

Para el consultor funcional o técnico que trabaja hoy en proyectos reales, la respuesta honesta es que esto no cambia nada a corto plazo. Ni la SPRO, ni la SE37, ni la SM37, ni los procesos de cierre de Controlling, ni las órdenes de transporte van a cambiar por estas adquisiciones en los próximos meses.

Lo que sí cambia es la dirección estratégica de SAP con más claridad que nunca: SAP quiere ser la plataforma de datos de referencia para la IA empresarial, no solo el ERP. Y eso sí tiene implicaciones para los proyectos de los próximos años.

Esta semana SAP ha vuelto a dejar números bastante sólidos, sobre todo en todo lo relacionado con cloud e inteligencia artificial.

Los ingresos totales han rondado los 9,5 billones de euros y, de todo eso, prácticamente 6 billones ya vienen del negocio cloud. Lo interesante no es solo la cifra, sino el crecimiento: alrededor de un 19% más respecto al año pasado.

Y eso, para una empresa del tamaño de SAP, es muchísimo.

Además, el beneficio operativo también ha subido bastante, situándose cerca de los 2,9 billones de euros. El mercado ha reaccionado bien y las acciones llegaron a subir alrededor de un 5% después de los resultados.

Al final, lo que están valorando los inversores es bastante claro:
SAP cada vez depende menos del modelo clásico de licencias y mantenimiento de toda la vida… y más de suscripciones cloud, automatización e IA.

Y ahí es donde está ahora mismo el dinero.

También sigue creciendo bastante el famoso “cloud backlog”, que básicamente son contratos ya cerrados pero que todavía no se han ejecutado completamente. Ahora mismo está cerca de los 22 billones de euros, lo cual da bastante tranquilidad al mercado porque significa ingresos futuros prácticamente asegurados.

Además, SAP está empujando muchísimo toda la parte de IA con Joule, automatización y herramientas integradas con hyperscalers como AWS, Microsoft o Google Cloud. Y aunque muchas cosas todavía están “verdes”, la sensación general es que SAP quiere posicionarse como algo más que un ERP.

Eso sí, tampoco todo es perfecto.

La compañía sigue hablando de incertidumbre económica y posibles impactos geopolíticos. Y no hace tanto vimos cómo el mercado castigó bastante a SAP cuando algunas previsiones no convencieron del todo.

Pero ahora mismo la sensación general parece bastante positiva.

Hace unos años mucha gente veía SAP como “la empresa gigante del ERP tradicional”.

Hoy el mercado empieza a verla más como una compañía cloud con foco en IA y automatización empresarial.

Esta semana SAP ha anunciado en su Sapphire 2026 en Orlando algo que hace tres años era impensable: que los clientes que siguen en ECC o en S/4HANA On-Premise podrán acceder a Joule, su asistente de IA. Un cambio de postura que parece generoso... hasta que lees los detalles. Y como siempre en SAP, los detalles lo cambian todo.

Porque antes no había urgencia. Durante años SAP mantuvo una postura muy clara: en julio de 2023, el CEO Christian Klein declaró públicamente a inversores que las nuevas innovaciones de SAP no estarían disponibles para clientes on-premise. Solo en cloud, solo vía RISE. El mensaje era nítido: si quieres lo nuevo, migra.

Pero esa estrategia tiene un problema que SAP no puede ignorar indefinidamente: más de 20.000 clientes SAP siguen "atascados" en sistemas ECC legacy debido a customizaciones profundas, y muchos de ellos no van a migrar en el corto plazo. Y mientras SAP les decía que sin cloud no había IA, los competidores empezaban a ofrecer IA que funciona perfectamente sobre ECC sin necesidad de migrar nada.

La urgencia que ha forzado a SAP a repensar su política ha sido precisamente esa: evitar que las empresas de IA externas les quiten cuota de mercado entre sus propios clientes. No es generosidad. Es defensa de territorio.

Aquí viene lo importante y lo que mucha gente no está leyendo bien. SAP ofrecerá acceso limitado a Joule en entornos on-premise, pero solo si el cliente compromete al menos el 50% de su gasto de mantenimiento al cloud antes de que Joule se active localmente.

Léelo de nuevo: el 50% del mantenimiento al cloud. No es acceso gratuito a la IA mientras sigues en ECC tranquilamente. Es: empieza a pagar cloud, y mientras migras te dejamos usar algo de Joule en tu sistema de siempre.

El propio COO de SAP, Sebastian Steinhaeuser, lo dejó claro en la rueda de prensa post-Sapphire: "Joule está diseñado para el cloud. Ahí es donde funcionará. Pero queremos acompañar a nuestros clientes en su viaje de transformación."

Viaje de transformación. No acceso permanente. El matiz importa muchísimo.

Las dos cosas. Y no son incompatibles.

Es un caramelo porque Joule cobra por SAP AI Units ( el paquete mínimo son 100 unidades a 7 euros la unidad, 700 euros al año ) y los contratos RISE incluyen una dotación base que habitualmente es insuficiente para un despliegue real en producción, con cargos de exceso al 150-200% de la tarifa contratada. Es decir, te dejo probar, te acostumbras, y cuando quieres más... pagas más.

Pero también es una estrategia real porque SAP sabe perfectamente que aproximadamente el 40% de los clientes SAP seguirán en ECC en 2030 según estimaciones de consultoras especializadas. Esos clientes no van a desaparecer. Y si SAP no les da nada, buscarán la IA en otro sitio. El dato que más duele en Walldorf es que el 77% de las empresas SAP que usan IA en producción lo hacen con herramientas ajenas a SAP, como Microsoft Copilot. Eso es perder el ecosistema por la puerta de atrás.

Si eres un cliente en ECC o S/4HANA On-Premise, este anuncio no te da IA gratis. Te da la posibilidad de acceder a ella si empiezas a comprometerte con el cloud. Es un paso intermedio, un puente, no un destino.

Y hay algo más que tener en cuenta: los propios ingenieros de SAP reconocen que conectar Joule a sistemas on-premise con años de customizaciones Z requiere un esfuerzo de ingeniería considerable, porque los agentes cloud necesitan endpoints de datos predecibles que los sistemas legacy simplemente no tienen en ese formato. Técnicamente no es enchufar y ya está. Ni de lejos.

Mientras tanto, hay partners como MyWave que ya ofrecen agentes de IA nativos sobre ECC sin necesidad de comprometerse con nada de cloud. Su CEO, ex presidenta de SAP, lo resume bien: "Nunca es migrar y luego transformar, primero transformas y luego migras." Una filosofía que le da la vuelta al discurso oficial de SAP.

SAP lleva años usando la innovación como zanahoria para empujar al cloud. Primero fue Fiori. Luego fue S/4HANA. Ahora es Joule y la IA agéntica. El patrón es el mismo: lo nuevo solo está en el cloud, si quieres quedarte atrás es tu problema.

Lo que ha cambiado esta vez es que la presión competitiva es real. Microsoft Copilot funciona sobre cualquier sistema. Las soluciones de IA de terceros no necesitan que migres nada. Y SAP se ha dado cuenta de que si sigue cerrando la puerta de la innovación a sus clientes más complejos, esos clientes buscarán la innovación en otro proveedor... y en ese momento la migración futura a S/4HANA también está en riesgo.

Este movimiento no es un giro estratégico. Es una corrección táctica. SAP no ha cambiado de objetivo ( quiere a todos sus clientes en el cloud ) pero ha entendido que el camino tiene que ser más flexible o perderá gente por el camino.

¿Es bueno para el cliente? Sí, con matices. Más opciones siempre son mejor que menos. Pero antes de firmar nada, lee el contrato, calcula lo que ese 50% de mantenimiento al cloud implica en euros reales y pregúntate si el acceso a Joule justifica ese compromiso para tu empresa en este momento.

Porque SAP te abre la puerta. Pero la llave... esa te la cobra aparte.

Hay un concepto que está sonando mucho desde Sapphire 2026 y que todo técnico SAP debería entender bien antes de que llegue a su proyecto como propuesta: el servidor MCP.

MCP (Model Context Protocol ) es un estándar abierto que permite a los asistentes de IA conectarse directamente a sistemas externos. Es básicamente un traductor universal entre la IA y las aplicaciones empresariales.

Antes de MCP, la IA y SAP vivían en mundos separados. Tú describías el problema, la IA te daba una respuesta genérica y luego tú ibas al sistema a aplicarla manualmente. Con MCP, la IA puede conectarse directamente al sistema SAP, leer objetos reales, consultar datos en tiempo real y proponer o ejecutar acciones. El consultor deja de ser el intermediario entre dos mundos.

El servidor MCP actúa como una capa de seguridad y acceso en tres niveles: herramientas y APIs que permiten ejecutar acciones, consultas de metadatos que dan contexto del sistema, y control de acceso que garantiza que la IA solo ve lo que el usuario tiene autorizado ver.

Esto último es crítico y muy poco comentado: la IA hereda las autorizaciones SAP del usuario. No es un acceso paralelo que salta la seguridad. Es un acceso gobernado exactamente igual que cualquier otro acceso al sistema.

Ya existen servidores MCP oficiales de SAP para Fiori, CAP, UI5 y MDK, y una creciente lista de servidores de comunidad para ABAP, ADT, integración, Datasphere, OData y SAP GUI.

Sí. Ya existen soluciones que permiten a agentes de IA acceder a datos SAP en tiempo real y ejecutar transacciones tanto en cloud como en on-premise, con interfaces idénticas en ambos escenarios. El protocolo es agnóstico al modelo de despliegue. Lo que varía es cómo se configura la conectividad y la seguridad en cada entorno

Una de las decisiones más importantes en cualquier proyecto con módulo PP y que sin embargo se toma a veces demasiado rápido en el taller de diseño: ¿orden de fabricación u orden de proceso? Parecen lo mismo. No lo son. Y elegir mal al principio tiene consecuencias que se arrastran durante toda la vida del proyecto.

La orden de fabricación ( transaction CO01 ) es el modelo clásico de producción discreta. Fabricas unidades concretas, identificables e independientes. Un coche, una máquina, un componente electrónico. El proceso tiene un inicio y un fin claros, y el resultado es siempre una cantidad de unidades físicas perfectamente contables. La estructura de referencia es la lista de materiales y el plan de trabajo.

La orden de proceso ( transaction COR1 ) es el modelo para producción de proceso o industria de proceso. Fabricas por lotes, por campañas, por recetas. El resultado no siempre son unidades discretas — puede ser litros, kilos, metros. Piensa en alimentación, química, farmacéutica, cosmética. La estructura de referencia aquí no es un plan de trabajo sino una receta maestra, que incluye ingredientes, fases, instrucciones de proceso y parámetros de control de calidad integrados.

La receta vs el plan de trabajo. En órdenes de proceso la receta maestra es mucho más rica que un plan de trabajo clásico. Incluye fases de proceso con recursos, materiales asignados a cada fase, instrucciones detalladas y puntos de inspección de calidad integrados directamente. Si el cliente tiene procesos complejos con control de calidad en línea, la orden de proceso le da esa capacidad de forma nativa. La orden de fabricación no.

El rendimiento y los co-productos. En producción de proceso es muy habitual que de un mismo proceso salgan varios productos , el producto principal y uno o varios co-productos o subproductos. La orden de proceso gestiona esto de forma nativa. En una orden de fabricación clásica este escenario es mucho más complicado de modelar.

La trazabilidad por lote. Si el cliente necesita trazabilidad completa de lote ( saber exactamente qué ingredientes, de qué proveedor, en qué proporción y en qué momento entraron en cada lote producido ) la orden de proceso con gestión de lotes es la herramienta adecuada. Crítico en farmacéutica y alimentación.

El módulo que se activa. Orden de fabricación vive en PP estándar. Orden de proceso requiere PP-PI ( Production Planning for Process Industries ) que es un submódulo adicional con su propia configuración, sus propias transacciones y su propia curva de aprendizaje para el equipo funcional y para los usuarios.

Elegir orden de fabricación porque "es lo que siempre hemos usado" en un cliente que realmente tiene producción de proceso. El resultado: meses después aparecen requisitos de trazabilidad de lote, co-productos o control de calidad integrado que la orden de fabricación no cubre bien... y el rediseño a esas alturas del proyecto es doloroso y caro.

La pregunta que hay que hacer en el taller de diseño antes de decidir nada es muy concreta: ¿el cliente fabrica unidades discretas e identificables individualmente o fabrica por lotes, campañas o recetas donde el resultado es una cantidad de producto homogéneo? Si la respuesta es lo segundo, la conversación sobre PP-PI tiene que estar sobre la mesa desde el día uno.

Una de esas funciones que cuando la descubres te preguntas cuántas horas has perdido buscando alternativas más complicadas.

Convierte un trabajo de spool de SAP directamente a formato PDF desde ABAP, sin herramientas externas, sin Adobe Document Services y sin salir del sistema. El resultado es un XSTRING con el PDF listo para enviarse por email, guardarse en el servidor o adjuntarse a un objeto de negocio.

El caso más habitual: tienes un formulario SAP (un smartform, un Adobe Form, un SAPscript ) que genera un spool cuando se imprime. En lugar de mandarlo a la impresora, capturas el spool ID, lo conviertes a PDF con esta función y lo envías automáticamente por email al cliente o al proveedor. Sin intervención manual, sin descargas, sin pasos intermedios.

Muy habitual en automatización de envío de facturas, pedidos, albaranes y cualquier documento que antes se imprimía y ahora va por email.

El spool tiene que existir y estar accesible para el usuario técnico que ejecuta la función. Si el spool ya fue borrado por la gestión automática del sistema ( cosa habitual si nadie ha configurado bien la retención ) la función devuelve ERR_NO_SPOOLJOB y no hay nada que hacer. Por eso en desarrollos que usan esta función es importante controlar el timing entre la generación del spool y su conversión.

Mientras lees esto, hay una probabilidad muy alta de que algún miembro de tu equipo técnico ya esté experimentando con Joule, con GitHub Copilot conectado via MCP a vuestro sistema, o con algún agente de IA que promete automatizar desarrollos ABAP. No porque sean imprudentes. Sino porque la tecnología está disponible, es atractiva y en muchos casos tiene un período gratuito hasta septiembre de 2026.

El problema no es que experimenten. El problema es cuando esa experimentación llega a producción sin que nadie haya pensado en las implicaciones.

Porque llegará. Y cuando llegue, si no tienes las respuestas preparadas, tomarás la decisión con el tiempo en contra y con el entusiasmo del equipo como único criterio.

Pregunta uno: ¿están nuestros datos preparados para la IA? Esta es la pregunta que nadie hace y la que más condiciona el resultado. Un agente de IA conectado a un sistema SAP con años de desarrollos Z no documentados, datos inconsistentes y procesos sin limpiar no va a generar valor. Va a generar respuestas incorrectas con mucha confianza. Y eso es peor que no tener IA. Antes de evaluar cualquier herramienta, evalúa el estado real de tus datos y tu sistema.

Pregunta dos: ¿quién valida lo que hace la IA? MCP permite que un agente de IA lea tu sistema SAP, proponga modificaciones y en algunos casos las ejecute. Eso es potente. Y también es una responsabilidad enorme. ¿Tienes un proceso de aprobación para lo que genera la IA antes de que llegue a producción? ¿Hay un humano en el bucle que valida cada acción crítica? Si la respuesta es no, tienes un problema de gobierno antes de tener un problema de tecnología.

Pregunta tres: ¿quién es responsable cuando algo falla? Y algo fallará. No porque la IA sea mala — sino porque todos los sistemas fallan en algún momento. Cuando un agente ejecuta algo incorrecto en producción, ¿quién asume la responsabilidad? ¿El proveedor de la herramienta? ¿El consultor que la configuró? ¿El responsable que firmó la aprobación? Eso tiene que estar definido en papel antes del go-live, no después del incidente.

Hay algo que el artículo de opinión de este número no dice explícitamente y que como responsable te interesa mucho: SAP ha extendido el período promocional gratuito de Joule for Developers hasta septiembre de 2026.

Eso son cuatro meses de margen para aprender sin coste, hacer pruebas en entornos no productivos y definir tu modelo de gobierno antes de comprometerte con un contrato de AI Units. Un responsable inteligente no usa ese tiempo para vender la herramienta internamente. Lo usa para entender exactamente qué puede hacer, qué no puede hacer y qué necesita tu organización para adoptarla de forma segura.

Cuatro meses. Es tiempo suficiente para hacer las preguntas correctas. No para tomar la decisión final, sino para llegar a esa decisión con criterio propio en lugar de depender del criterio del proveedor.

Este es quizás el punto más importante y el menos discutido en las reuniones de proyecto. La IA generativa es la primera tecnología en la historia del software empresarial que un desarrollador individual puede adoptar sin que el responsable lo sepa. No necesita una licencia corporativa, no necesita infraestructura especial, no necesita aprobación de compras. Se registra, conecta su IDE y empieza a usarla.

Eso significa que el debate de "¿adoptamos IA o no?" es en muchos equipos una conversación que llega tarde. La IA ya está en el flujo de trabajo de varios miembros del equipo. La pregunta real no es si adoptarla. Es si lo vas a gobernar tú o lo va a gobernar la inercia.

En tecnología, y especialmente en SAP, es muy fácil caer en la rutina de “hacer las cosas como siempre se han hecho”.

Pero los perfiles que realmente terminan marcando la diferencia no son los que más repiten procesos…

Son los que se atreven a mejorarlos.

A veces innovar no significa crear algo revolucionario.

Puede ser simplemente:

Porque al final, el mercado cambia muy rápido. Y muchas veces, quedarse quieto también es quedarse atrás.

Y hasta aquí el boletín de esta semana.

Hoy hemos hablado de algo que muchas veces vemos todos los días… pero que no siempre analizamos con calma: cómo funciona realmente el ecosistema de consultoría alrededor de SAP.

Porque al final, detrás de cada proyecto, cada desarrollo o cada incidencia, también hay modelos de negocio, decisiones, estrategias y formas muy distintas de entender este mundo.

Y cuanto más tiempo pasas en él, más te das cuenta de que SAP no va solo de tecnología.

Va de personas, de procesos, de negocio… y muchas veces de saber adaptarse constantemente a cómo cambia todo.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta pequeña comunidad donde intentamos hablar de SAP de una forma un poco más cercana y real.

La semana que viene volveremos con más historias de proyectos, algún tema interesante y seguramente otra de esas situaciones que todos hemos vivido alguna vez trabajando en este ecosistema.

Nos leemos en el próximo boletín 👋