¿Quieres enviar a firmar contratos y documentos de RRHH sin tener que salir de SAP?

En GROUPmee hemos creado un Conector que integra Signaturit en tu ERP SAP para acelerar los procesos de firma de documentos y contratos con una solución legal.

Hemos optimizado todo el proceso, para que el envío de documentos y contratos a empleados, se haga de forma automática y con un solo click.

Cuando alguien dice que SAP vende software… se queda muy, muy corto.

Porque en realidad, SAP gana dinero de muchas más formas de las que parece. Y lo más curioso es que muchas de ellas no tienen nada que ver con programar ni con ABAP. Si trabajas en este mundo, probablemente formas parte de ese sistema… sin darte cuenta.

SAP empezó con un modelo muy claro: vender licencias. Un pago inicial alto que permitía usar el sistema en local (on-premise). Este fue el origen de todo y durante años fue la base del negocio.

Pero donde realmente estaba el dinero no era en la venta inicial, sino en el mantenimiento. Un porcentaje anual sobre esas licencias que las empresas pagan religiosamente. Ingresos recurrentes, márgenes aceptables y una estabilidad brutal.

Hoy el foco ha cambiado. SAP empuja cada vez más hacia el cloud, donde ya no vendes licencias, sino suscripciones. S/4HANA Cloud, SuccessFactors, Ariba o BTP funcionan bajo este modelo. Pagos recurrentes, control total del entorno y mucha más previsibilidad para SAP.

Luego está una de las piezas más inteligentes del sistema: los partners. SAP no implementa la mayoría de proyectos, lo hacen consultoras de todos los tamaños y freelancers. Pero SAP gana igualmente a través de licencias, certificaciones y programas de partnership. Es una forma de escalar sin asumir todo el coste.

Otra vía importante es la formación. Certificaciones oficiales, plataformas como el Learning Hub y academias autorizadas. Cada nuevo consultor que entra en el ecosistema también genera ingresos.

También se monetiza el conocimiento. Libros técnicos, manuales, contenido especializado a través de SAP Press y otros canales. Incluso aprender SAP forma parte del propio modelo de negocio.

Los eventos son otra pieza interesante. SAP TechEd, Sapphire y otros encuentros no solo sirven para marketing. Generan ingresos a través de entradas, patrocinios y sobre todo, oportunidades de negocio que acaban en nuevos proyectos.

Además, SAP está construyendo una capa sobre la que quiere que todo ocurra: plataformas como BTP, marketplaces de aplicaciones e integraciones. No solo vende el sistema, quiere ser el lugar donde se construye todo lo demás.

A esto se suma la expansión a productos específicos como SuccessFactors, Ariba o Concur, que le permiten entrar en más áreas de la empresa y aumentar su presencia (y sus ingresos) dentro de cada cliente.

Y luego está el negocio que nunca se acaba: las migraciones. Pasos como ECC a S/4HANA generan proyectos enormes, nuevas licencias, consultoría y años de trabajo alrededor del mismo cliente.

Por último, hay algo que no se vende directamente pero lo sostiene todo: la dependencia. Sistemas críticos, procesos integrados y un coste de salida muy alto hacen que los clientes permanezcan durante años, incluso décadas.

SAP no es solo un software.

Es un sistema económico completo donde empresas, consultoras y consultores forman parte… y donde el dinero fluye en cada capa.

SAP sigue moviéndose rápido en una de las grandes batallas actuales: la inteligencia artificial dentro de las empresas. Y esta vez lo hace de la mano de NVIDIA, uno de los actores más importantes del mundo en infraestructura de IA.

Ambas compañías han reforzado su colaboración con un objetivo muy claro: llevar la inteligencia artificial directamente al corazón de los procesos de negocio. No hablamos de pruebas o casos aislados, sino de integrar la IA dentro de los sistemas que realmente hacen funcionar a las empresas. ()

Uno de los puntos más interesantes de este movimiento es que SAP apuesta por una arquitectura abierta y flexible. Esto significa que las empresas no están obligadas a usar un único modelo de IA, sino que pueden integrar diferentes modelos dentro de sus propios procesos, combinándolos con herramientas como SAP AI Core. ()

Pero aquí viene lo realmente importante.

La idea no es solo “usar IA”, sino construir lo que ya se empieza a llamar una empresa nativa en IA. Es decir, organizaciones donde los procesos no solo están digitalizados, sino que directamente funcionan con inteligencia incorporada: automatización avanzada, decisiones en tiempo real y workflows que prácticamente se ejecutan solos.

En este contexto, la colaboración con NVIDIA tiene todo el sentido. Mientras SAP aporta el conocimiento del negocio (finanzas, logística, RRHH…), NVIDIA aporta la potencia tecnológica necesaria para entrenar modelos, ejecutar agentes de IA y escalar todo esto a nivel empresarial.

De hecho, una de las líneas más interesantes es el uso de agentes de IA dentro del ecosistema SAP. No hablamos solo de chatbots, sino de sistemas capaces de ejecutar tareas completas dentro de procesos empresariales: desde analizar datos hasta tomar decisiones o lanzar acciones automáticamente. ()

Todo esto está muy ligado a otro movimiento clave que ya estamos viendo: la migración al cloud. Muchas empresas están modernizando sus sistemas SAP precisamente para poder aprovechar este tipo de capacidades de IA ya que es ahí donde realmente se desbloquea todo su potencial. ()

Y aquí es donde encaja todo con lo que venimos hablando en la newsletter.

SAP no solo está cambiando su tecnología. Está reforzando su modelo de negocio:

Porque si antes SAP era el sistema donde corría la empresa, ahora quiere ser el sistema que piensa y actúa dentro de la empresa.

Y eso cambia completamente las reglas del juego.

Lo interesante no es solo la tecnología.

Es entender hacia dónde va SAP… y cómo eso va a impactar directamente en el trabajo de todos los que estamos dentro de este mundo.

Esta semana, SAP ha mostrado un comportamiento bastante sólido en bolsa, manteniéndose estable dentro de un contexto donde muchas compañías tecnológicas están experimentando cierta volatilidad.

El mercado sigue valorando de forma positiva la estrategia de SAP, especialmente su transición hacia el cloud y el crecimiento de ingresos recurrentes. Este cambio, aunque en su momento generó dudas, ahora se percibe como una base mucho más predecible y escalable para el negocio.

Uno de los puntos clave que los inversores siguen de cerca es precisamente ese: el peso cada vez mayor de las suscripciones frente al modelo tradicional de licencias. Cuanto más crece esta parte del negocio, mayor confianza genera en el largo plazo.

Además, movimientos recientes como la apuesta por la inteligencia artificial y colaboraciones estratégicas refuerzan la idea de que SAP no solo está consolidando su posición, sino que está intentando liderar la siguiente etapa tecnológica dentro del entorno empresarial.

Desde mi punto de vista, todo esto es simplemente brillante. No encuentro otra palabra mejor para definirlo. Si te paras a analizarlo bien, ves que SAP tiene muchísimas fuentes de ingresos… y seguramente haya muchas más que ni siquiera conocemos o no se hacen tan evidentes.

Es increíble pensar que todo empezó como una idea que se materializó en un pequeño ERP financiero y que, con el tiempo, ha terminado convirtiéndose en el gigante que conocemos hoy, con presencia global en prácticamente todos los sectores.

Por supuesto, las principales fuentes de ingresos siguen siendo muy claras: las licencias y el mantenimiento. Ese modelo clásico ha sido durante años una auténtica máquina de generar dinero.

Pero hay más capas. Por ejemplo, los partners. Cada partner de SAP, ya sea de servicios o de formación, paga su cuota anual. Y créeme, hay muchísimos partners repartidos por todo el mundo, de todos los tamaños. Solo con eso ya tienes una fuente de ingresos enorme y constante.

Ahora bien, dentro de lo brillante… tampoco es perfecto (si no, diría “perfectamente brillante” 😄). También ha habido decisiones que no han salido tan bien y que, seguramente, le han costado dinero a SAP.

Un ejemplo claro es NEO. Para quien no lo conozca, fue el intento de SAP de competir directamente como proveedor cloud al estilo AWS. Y, si no me equivoco, ahí se dieron cuenta de que no era realmente su terreno. A día de hoy todavía queda un pequeño porcentaje de clientes usando NEO y SAP sigue gestionando esa infraestructura… algo que no parece especialmente rentable.

Aun así, más allá de estos detalles, el modelo de negocio sigue siendo muy sólido, especialmente en todo lo relacionado con licencias y la implantación del producto SAP. Eso sí, ahora estamos viendo una evolución clara hacia un modelo SaaS, basado en suscripciones. Algo así como Netflix… pero bastante más caro y con muchos más servicios detrás. Este cambio no solo es una nueva fuente de ingresos, sino también una evolución tecnológica importante.

También generan ingresos con manuales, certificaciones y eventos. Probablemente esto represente un porcentaje pequeño dentro del total, pero sigue siendo parte del ecosistema y del modelo global.

Y hay algo más que, en mi opinión, ha sido clave en su éxito: ese carácter “privado” o cerrado del sistema. Más caro, menos accesible, pero también más exclusivo y extremadamente adaptable a cada cliente. Esa combinación, junto con la evolución constante del producto, es lo que ha llevado a SAP a ser lo que es hoy.

Y te dejo una reflexión…

¿Qué habría pasado si SAP hubiera sido open source?

Piénsalo… porque hablaremos de este tema en el futuro..

Hay un error muy común cuando empiezas a trabajar en serio con CDS: intentar encontrar una lista completa con todas las anotaciones posibles para aprenderlas o tenerlas controladas.

Tiene sentido… pero no es el camino correcto.

La realidad es que no existe una “CDS definitiva” donde esté todo, porque muchas anotaciones pertenecen a contextos completamente distintos: UI, analítica, OData, RAP… y no están pensadas para usarse juntas. Intentar entender CDS como un listado cerrado de opciones es como intentar aprender un idioma memorizando el diccionario entero.

El enfoque que realmente marca la diferencia es otro.

En lugar de preguntarte “¿qué puedo usar aquí?”, la pregunta correcta es:
“¿qué tipo de CDS estoy construyendo?”

Porque no es lo mismo:

Y cada una tiene su propio conjunto de anotaciones relevantes.

Aquí es donde entra uno de los mejores hábitos que puedes desarrollar como desarrollador ABAP moderno: usar Eclipse (ADT) como guía. Cuando escribes @ y utilizas el autocompletado, no solo ves anotaciones, ves las que realmente aplican en ese contexto. Es como tener documentación viva mientras trabajas.

Pero el salto de nivel de verdad viene cuando empiezas a leer CDS estándar de SAP.

Ahí es donde entiendes cómo se usan las anotaciones en escenarios reales:

Porque los buenos desarrolladores no son los que se saben todas las anotaciones.

Son los que entienden cuándo usar cada una.

Así que la próxima vez que te encuentres buscando “todas las anotaciones CDS”, cambia el enfoque.

No intentes abarcarlo todo.

Define primero qué estás construyendo… y deja que eso te diga qué necesitas.

Si buscas en Eclipse DEMO_CDS_* veras que hay muchos ejemplos del uso de los CDS para las diferentes formas de usarlo que puedes hacer.

Si trabajas en SAP, tarde o temprano te vas a cruzar con el MRP. Y aunque muchas veces se explica como “la planificación de materiales”, la realidad es que es mucho más que eso.

El MRP (Material Requirements Planning) es el mecanismo que utiliza SAP para calcular qué necesita una empresa para operar: qué materiales hacen falta, en qué cantidad y en qué momento. Pero lo realmente interesante no es el cálculo en sí, sino todo lo que hay detrás.

Porque el MRP no funciona de forma aislada.

Funciona conectando prácticamente todos los módulos logísticos del sistema.

Por un lado, está directamente ligado a PP (Planificación de Producción). Aquí es donde se define cómo se fabrica un producto: listas de materiales (BOM), hojas de ruta, tiempos… Todo eso es la base sobre la que el MRP calcula necesidades.

Pero el MRP no se queda en producción. En cuanto detecta que faltan materiales, entra en juego MM (Material Management). Es aquí donde se generan propuestas de compra, solicitudes de pedido y aprovisionamiento externo.

Y si seguimos tirando del hilo, aparece SD (Sales and Distribution). ¿Por qué? Porque muchas de las necesidades que calcula el MRP vienen de pedidos de clientes o previsiones de demanda. Es decir, lo que vendes impacta directamente en lo que necesitas producir o comprar.

Además, también interviene FI/CO, aunque de forma más indirecta. Todo lo que planifica el MRP tiene un impacto en costes: compras, producción, almacenamiento… y eso acaba reflejándose en la contabilidad y el controlling.

Lo interesante es que el MRP actúa como un punto de unión.

Recoge información de distintos módulos, la procesa y devuelve decisiones que afectan a toda la cadena: compras, producción, logística y costes.

Por eso, cuando algo falla en MRP, rara vez es un problema “de MRP”.

Suele ser un problema de:

Y aquí está el verdadero tip.

Si quieres que el MRP funcione bien, no te centres solo en la transacción o en el cálculo. Asegúrate de que todo lo que lo alimenta está bien definido: materiales, tiempos, stock, demanda.

Porque el MRP no toma decisiones. Solo ejecuta, de forma perfecta, lo que el sistema le dice.

el METODO SEND_AND_RECEIVE que uso en mis integraciones.

Si hay algo que repito constantemente cuando trabajo con integraciones en SAP, es esto: no reinventar la rueda.

Cada vez que tengo que consumir una API, podría montar la lógica desde cero… pero con el tiempo te das cuenta de que hay partes que siempre son iguales. Y una de ellas es el envío y recepción de la petición HTTP.

Por eso, este método se ha convertido en uno de mis básicos. Lo reutilizo prácticamente en todas las integraciones.

La idea es muy simple: encapsular en un único método el proceso de enviar una petición y recoger la respuesta.

Primero se lanza el send, que es donde realmente se ejecuta la llamada al servicio externo. Aquí ya puedes encontrarte errores de comunicación, estados inválidos o fallos en el procesamiento.

Después viene el receive, que es donde recoges la respuesta del servidor. Y aquí es donde empieza lo interesante.

Si todo va bien, obtienes dos cosas clave: el código de respuesta HTTP (por ejemplo, 200, 404, 500…) y el contenido que devuelve la API, normalmente en formato JSON o XML.

Ese contenido lo guardo directamente en una estructura (en este caso gs_rest), lo que me permite luego procesarlo de forma separada, sin mezclar lógica de comunicación con lógica de negocio.

Y aquí está el punto importante del enfoque.

Este método no hace más de lo que debe:

Solo hace una cosa: comunicarse con la API.

Gracias a esto, consigo varias ventajas muy claras.

La primera es reutilización. Este mismo método me sirve para distintas APIs, distintos endpoints y distintos proyectos.

La segunda es claridad. Cuando algo falla, sé exactamente si es un problema de comunicación o de lógica posterior.

Y la tercera, que para mí es la más importante, es la separación de responsabilidades. La integración se divide en capas: una capa que habla con el exterior y otra que interpreta lo que recibe.

Con el tiempo, este tipo de pequeños patrones son los que realmente te hacen más eficiente como desarrollador.

Porque no se trata de escribir más código.

Se trata de escribir menos… pero mejor pensado.

Si hay algo que los directivos de SAP han demostrado a lo largo del tiempo es una capacidad muy poco común: tomar decisiones estratégicas incómodas incluso cuando el modelo actual seguía funcionando.

El mejor ejemplo es el paso de licencias tradicionales al modelo cloud. Durante años, SAP tenía un negocio extremadamente rentable basado en licencias y mantenimiento. Era predecible, con márgenes altos y clientes muy fidelizados. Desde fuera, no había una necesidad urgente de cambiar.

Y aun así, decidieron hacerlo.

¿Por qué? Porque entendieron algo clave: que el mayor riesgo no era cambiar… sino no hacerlo. Sabían que el mercado iba hacia el SaaS, hacia modelos de suscripción, hacia mayor flexibilidad. Y prefirieron asumir el coste de transformarse antes de que el mercado les obligara a hacerlo tarde y mal.

Ese movimiento implicaba riesgos reales:

Y aun así, apostaron por ello.

Aquí es donde está el aprendizaje de liderazgo.

Como líder, especialmente en entornos pequeños o equipos en crecimiento, es muy fácil caer en la trampa de proteger lo que ya funciona. Lo conocido da seguridad, resultados y cierta sensación de control. Pero esa misma comodidad puede ser el mayor freno a largo plazo.

El verdadero liderazgo no consiste solo en optimizar el presente, sino en cuestionarlo constantemente.

Significa ser capaz de hacerte preguntas incómodas como:

Y lo más importante: actuar en base a esas respuestas.

Porque anticiparse al cambio no es solo una ventaja competitiva. Es una forma de proteger lo que estás construyendo.

En formato más pequeño, esto se traduce en decisiones muy concretas:

No se trata de cambiar por cambiar. Se trata de entender hacia dónde va el entorno y moverte antes de que sea demasiado tarde.

Porque crecer no es hacer mejor lo mismo.

Es tener el criterio (y el coraje) de dejar atrás lo que hoy funciona para poder construir lo que funcionará mañana.

Muchas veces nos aferramos a lo que ya dominamos porque nos da seguridad: una tecnología, una forma de trabajar, incluso un rol dentro del equipo. Y no hay nada malo en eso… hasta que deja de evolucionar.

El problema es que el crecimiento no suele venir de hacer mejor lo que ya sabes, sino de atreverte a salir de ahí antes de que sea obligatorio.

La diferencia entre estancarse o avanzar casi nunca está en el talento, sino en la capacidad de cuestionar lo cómodo.

Y eso, aunque no siempre se note en el corto plazo, marca toda la diferencia en el largo.

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

Entre tips, reflexiones y alguna que otra historia de proyectos, siempre hay algo en común: la intención de entender un poco mejor cómo funciona todo esto que llamamos ecosistema SAP. Porque más allá de las transacciones, los desarrollos o las integraciones, lo interesante siempre acaba siendo lo mismo: las personas que están detrás intentando que las cosas funcionen.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta pequeña comunidad de consultores curiosos.

La semana que viene volveremos con más historias del día a día en proyectos, alguna reflexión que nos haga pensar… y, con suerte, algún truco que nos ahorre un buen rato de debugging.

Nos leemos en el próximo boletín.

Un abrazo 👋