¿Tu equipo trabaja en SAP Business One… pero sigue invirtiendo
tiempo en tareas manuales?

Con la integración de Dost, desarrollada por GROUPmee, automatizas
procesos clave de tu operativa financiera directamente dentro de SAP.
Captura e interpreta documentos con inteligencia artificial, concilia
automáticamente facturas, pedidos y albaranes, y gestiona
aprobaciones sin fricciones.

No es solo gestión documental: es automatización real de procesos,
con trazabilidad y control en tiempo real.

Menos tareas manuales. Más eficiencia. Más control.

Cuando una empresa decide migrar a S/4HANA, la parte técnica y funcional del proyecto es solo la mitad del trabajo. La otra mitad ( la que nadie presupuesta bien ) es la formación.

PepsiCo necesitó 14.000 horas de capacitación y obtuvo 136 certificaciones SAP para dar soporte a su transformación a S/4HANA y garantizar la excelencia operativa a largo plazo.

14.000 horas. De una sola empresa. Para un solo proyecto.

Y eso fue antes de que existiera SAP Business AI Platform, Joule Studio, el ABAP MCP Server y todo lo que SAP acaba de anunciar en Sapphire 2026. Ahora el catálogo de lo que hay que aprender es considerablemente más grande.

Pero hay otro dato que me parece igual de revelador. SAP ha migrado su modelo de certificaciones hacia un sistema por rol que permite mantenerlas siempre actualizadas, habilitando contenido requerido de forma continua. Es decir, certificarse en SAP ya no es un logro puntual. Es un proceso continuo. La certificación que sacas hoy puede quedarse obsoleta si no la mantienes actualizada con el nuevo contenido que SAP va añadiendo conforme evoluciona la plataforma.

Lo que esto significa en la práctica: en el ecosistema SAP de 2026, formarse una vez ya no es suficiente. El consultor que se certifica y se olvida tiene una vida útil cada vez más corta. El que hace de la formación continua un hábito tiene una ventaja competitiva que se acumula con el tiempo.

Una noticia que ha pasado algo desapercibida entre todo el ruido de Sapphire 2026 pero que merece atención, especialmente para los que trabajamos en proyectos de transformación y mejora de procesos.

SAP Signavio ha sido reconocida como líder en el recién creado Gartner Magic Quadrant para Plataformas de Inteligencia de Procesos ( una categoría nueva que amplía la anterior de Process Mining ) siendo evaluada entre 16 vendors en base a su capacidad de ejecución y completitud de visión. Es el cuarto año consecutivo que SAP Signavio obtiene este reconocimiento.

Este es el detalle más interesante de la noticia y el que menos se comenta. Gartner no ha mantenido el Magic Quadrant de Process Mining de siempre lo ha ampliado y renombrado como Process Intelligence Platforms. ¿Por qué? Porque el mercado ha evolucionado y ya no basta con minar procesos para encontrar ineficiencias.

La nueva categoría evalúa plataformas que unifican process mining, task mining, modelado, análisis, optimización, monitorización, descubrimiento de automatización y repositorios gobernados en un único entorno integrado.

Es decir, Gartner está reconociendo que las herramientas que solo hacen process mining ya no son suficientes. El mercado pide plataformas completas que no solo digan dónde están los problemas sino que ayuden a resolverlos, monitorizarlos y gobernarlos de forma continua. Y SAP Signavio cubre exactamente ese espectro completo.

Hay un elemento técnico en el reconocimiento de Gartner que merece atención especial porque conecta directamente con la estrategia de IA de SAP que hemos visto en Sapphire 2026.

SAP Signavio ha desarrollado el concepto de "process atoms" , una capa lista para IA que actúa como memoria de empresa, proporcionando a los agentes de IA el conocimiento preciso y contextual de procesos que necesitan para tomar decisiones informadas y actuar de forma autónoma.

Dicho de forma sencilla: los process atoms son la pieza que conecta lo que sabe SAP Signavio sobre cómo funciona el negocio de un cliente con los agentes de Joule que tienen que actuar sobre ese negocio. Sin ese conocimiento de proceso contextualizado, un agente de IA puede ejecutar acciones pero no puede entender si tienen sentido en el contexto real de la empresa. Esta es la diferencia entre IA genérica e IA empresarial de verdad.

SAP Signavio lleva tiempo siendo la herramienta que se usa en los proyectos para mapear y analizar procesos antes y durante una migración a S/4HANA. Ese rol no ha cambiado. Lo que sí está cambiando es su peso estratégico dentro del ecosistema SAP.

Con la integración de Joule en SAP Signavio ( disponible de forma general desde febrero de 2026 ) y el concepto de process atoms como base para la IA agéntica, Signavio deja de ser "la herramienta de consultoría de procesos" para convertirse en la capa de conocimiento de negocio que alimenta toda la estrategia de IA de SAP.

Para el consultor funcional o técnico que trabaja en proyectos de transformación, conocer SAP Signavio ya no es un extra interesante. Empieza a ser una competencia relevante.

SAP continúa bastante sólida en bolsa y esta semana ha mantenido una tendencia positiva apoyada, sobre todo, por todo lo relacionado con cloud e inteligencia artificial.

Para ponerlo un poco en contexto: hace aproximadamente dos semanas las acciones de SAP estaban moviéndose alrededor de los 245-248 € por acción.

Actualmente, SAP se está moviendo cerca de los 262-265 € por acción, dependiendo del cierre del día y del mercado.

Es decir:
📈 una subida cercana al 6%-7% en apenas dos semanas.

Y para una empresa del tamaño de SAP, eso es bastante movimiento.

Gran parte de esta subida sigue viniendo del crecimiento cloud. SAP continúa creciendo cerca de un 20% anual en ingresos cloud y eso al mercado le encanta porque significa ingresos recurrentes y más previsibles.

También está pesando mucho toda la narrativa de IA:

Y aunque muchas funcionalidades todavía están madurando, los inversores parecen comprar bastante bien la idea de que SAP quiere convertirse en mucho más que un ERP tradicional.

Además, SAP ya ronda una capitalización cercana a los 300.000 millones de euros, colocándose como una de las compañías software más potentes de Europa.

Eso sí, no todo es perfecto.

Siguen existiendo dudas alrededor de:

Pero aun así, la sensación del mercado ahora mismo es bastante positiva.

Hace unos años SAP era vista como “la empresa del ERP clásico”.

Hoy empieza a verse como una compañía cloud con foco en IA y automatización empresarial.

Y sinceramente… eso está cambiando mucho cómo la valora la bolsa.

Después de Sapphire 2026 hay una pregunta que está circulando por LinkedIn, por grupos de WhatsApp de consultores y por conversaciones de pasillo en las consultoras: ¿qué perfiles van a pedir ahora y qué tengo que aprender para no quedarme fuera?

Es una pregunta legítima. Y me voy a mojar con mi opinión, porque creo que hay mucho ruido y poca claridad sobre esto.

SAP ha anunciado un ecosistema de alianzas que es, objetivamente, el más ambicioso de su historia reciente. Anthropic ( con Claude como modelo base para los agentes de Joule ) AWS, Google Cloud, Microsoft, Mistral AI, Cohere, NVIDIA, Parloa y n8n, que proporciona orquestación visual de flujos de trabajo de IA dentro de Joule Studio.

La alianza con n8n es especialmente llamativa y merece atención especial. n8n se integrará de forma nativa en Joule Studio, el entorno de creación de agentes de SAP en SAP Business AI Platform, con disponibilidad general prevista para Q3 2026. Esto significa que los desarrolladores podrán construir flujos de automatización visuales conectando agentes SAP con más de mil integraciones externas, sin escribir código de integración personalizado.

Suena revolucionario. Y en parte lo es. Pero hay una trampa en el relato que quiero señalar.

Desde que se anunció la alianza con n8n he visto muchos comentarios del tipo: "Ahora los que saben n8n pueden trabajar con SAP." Y me parece importante matizar esto con mucho cuidado.

SAP customers building agents in Joule can use n8n to connect those agents to systems outside the SAP ecosystem without writing custom integration code. Es decir, n8n es la capa de orquestación visual que conecta lo que pasa dentro de SAP con lo que pasa fuera. La herramienta de flujo de trabajo. El pegamento entre sistemas.

Pero n8n no sabe qué es un centro de coste. No sabe qué es una sociedad FI. No sabe por qué una orden de compra tiene tres documentos asociados ni por qué el cierre de período en CO tiene que ejecutarse en un orden específico. No sabe qué es un IDoc, ni un BAPI, ni por qué una integración con SAP falla cuando el usuario técnico no tiene las autorizaciones correctas en S_RFC.

Dicho de forma directa: saber n8n te da acceso a la capa de orquestación. No te convierte en consultor SAP. Un perfil que solo sabe n8n y quiere trabajar en un proyecto SAP es como un fontanero que sabe muy bien cómo conectar tuberías pero no sabe qué hay dentro del edificio. Puede enchufar cosas. No puede diseñar el sistema.

Lo que sí es cierto es que un consultor SAP que además sabe n8n tiene un perfil diferencial enorme en este momento. Esa combinación sí tiene valor real y creciente.

Siendo honesto, el mercado SAP en 2026 tiene una dualidad muy clara que convive sin demasiada tensión por ahora pero que en dos o tres años va a ser mucho más evidente.

Por un lado, los perfiles clásicos siguen siendo los más demandados. Funcionales FI, MM, SD, PP con experiencia real en proyectos. ABAPers con conocimiento de S/4HANA. BASIS con experiencia en landscapes complejos. Eso no ha cambiado. El mercado laboral vinculado a SAP sigue mostrando fortaleza y las organizaciones necesitan talento preparado para afrontar migraciones y proyectos de transformación. El ECC se acaba y hay miles de empresas que tienen que migrar. Eso genera demanda de perfiles clásicos durante años.

Por otro lado, están apareciendo perfiles nuevos que hace dos años no existían o existían de forma muy marginal. Aquí es donde está la oportunidad y donde hay que poner el foco:

SAP BTP Developer / Architect. Los perfiles especializados en SAP BTP son cada vez más demandados por consultoras, partners tecnológicos y grandes compañías que están migrando hacia SAP S/4HANA Cloud y modelos de negocio basados en datos, automatización e inteligencia artificial. Saber Integration Suite, Event Mesh, CAP, extensibilidad cloud y cómo conectar todo eso con S/4HANA es uno de los perfiles más cotizados ahora mismo y los próximos años.

SAP AI Developer / Joule Studio Developer. Un perfil completamente nuevo que prácticamente no existía hace un año. Alguien que sabe construir agentes en Joule Studio, que entiende el SAP Knowledge Graph, que sabe orquestar flujos con n8n dentro de BTP y que entiende cómo los datos de SAP alimentan esos agentes. Este perfil escasea enormemente porque requiere conocimiento SAP real más conocimiento de IA agéntica. No es un perfil de IA que aprende SAP en tres semanas. Es un consultor SAP que aprende IA. La dirección importa.

SAP Data Architect / Business Data Cloud Specialist. Con las adquisiciones de Dremio y Prior Labs y la apuesta por SAP Business Data Cloud, alguien que entienda cómo fluyen los datos entre SAP y sistemas externos, cómo se modela el SAP Knowledge Graph y cómo se preparan los datos para que los agentes de IA funcionen bien en producción. Raro, muy demandado y muy bien pagado.

Consultor funcional con conocimiento de IA y prompting. Esto es quizás lo más interesante y lo que menos se comenta. El funcional que sabe su módulo de siempre ( FI, MM, SD ) pero además sabe cómo configurar agentes de Joule para ese módulo, cómo escribir prompts efectivos para procesos de negocio reales y cómo validar que lo que genera la IA es correcto en términos de negocio. Ese perfil es el que más va a crecer en los próximos dos años.

SAP tiene disponibles certificaciones como SAP Certified ( RISE with SAP Methodology and Experience, SAP Certified ) SAP Build Developer, SAP Certified , SAP BTP Administrator, entre otras que se están ampliando progresivamente al nuevo modelo.

Y en el horizonte inmediato van a aparecer certificaciones específicas de SAP Business AI Platform y Joule Studio. SAP ya ha anunciado que está trabajando en ellas. Si quieres estar en la primera ola, empieza a aprender ahora con el material de SAP Learning Hub antes de que la certificación esté disponible.

No abandones lo que sabes. Si eres un buen funcional FI o un buen ABAPER, ese conocimiento tiene valor y lo seguirá teniendo durante años. ECC se acaba pero S/4HANA ( en cualquiera de sus variantes ) necesita exactamente los mismos conocimientos de negocio y proceso que has acumulado.

Lo que sí tienes que hacer es añadir una capa encima. Si eres técnico, aprende BTP, aprende cómo funciona el ABAP MCP Server, entiende qué es un agente de IA y cómo se construye en Joule Studio. Si eres funcional, aprende cómo Joule puede automatizar los procesos de tu módulo y cómo validar que lo que genera la IA es correcto en términos de negocio. Si eres BASIS, empieza a entender Cloud ALM, BTP y la gestión de landscapes en entornos hybrid.

Lo que no tiene sentido es creer que aprendiendo n8n o cualquier otra herramienta de automatización puedes entrar al ecosistema SAP sin conocimiento real de SAP. Las integraciones que conectan n8n con Joule Studio van a necesitar que alguien entienda qué hay al otro lado. Y ese alguien tiene que saber de SAP de verdad.

SAP ha anunciado que formará a 12 millones de personas en habilidades de IA para 2030. Doce millones de personas con conocimientos de IA genérica. El valor diferencial no va a estar en saber IA. Va a estar en saber SAP más IA. Esa combinación es la que el mercado no tiene suficiente y la que más va a valer en los próximos años.

Uno de los cambios que más confusión genera cuando alguien empieza a trabajar en entornos S/4HANA con orientación Clean Core o directamente en ABAP Cloud es este: no puedes usar cualquier objeto estándar de SAP en tu código. Y el sistema no siempre te avisa de forma clara cuando estás cruzando esa línea.

En ABAP clásico podías llamar prácticamente cualquier función, clase o tabla del sistema estándar desde tu código Z. SAP no te lo impedía técnicamente aunque internamente esos objetos pudieran cambiar en cualquier actualización. El resultado era desarrollos que funcionaban perfectamente en una versión y rompían en la siguiente porque SAP había modificado algo interno sin previo aviso.

ABAP Cloud resuelve ese problema con un concepto claro: solo puedes usar objetos que SAP ha marcado explícitamente como released ,liberados para uso externo. Esos objetos tienen un contrato de estabilidad: SAP se compromete a mantener su interfaz compatible entre versiones. El resto son implementación interna de SAP y pueden cambiar sin que te deban nada.

La forma más directa es consultarlo en el SAP API Business Hub, donde están publicadas todas las APIs released de S/4HANA con su documentación, estado y versión.

Pero también puedes comprobarlo directamente en el sistema. En ADT (Eclipse) cuando intentas usar un objeto no released en un contexto ABAP Cloud, el sistema te muestra un warning o error indicando que el objeto no está liberado para ese uso. El nivel de restricción depende del ABAP language version configurado en el objeto de desarrollo:

Standard ABAP — sin restricciones. El ABAP clásico de siempre.

ABAP for Cloud Development , solo objetos released. La restricción máxima. Obligatorio en Public Cloud y recomendado si quieres alinearte con Clean Core en On-Premise.

Para consultar el estado de release de un objeto concreto puedes usar la vista ABAP Repository Object Properties en ADT o buscar directamente en la tabla TADIR con el campo CLOUD_RELEASE_STATE.

El error más habitual es este: un ABAPER con años de experiencia en ABAP clásico empieza a trabajar en un entorno S/4HANA con orientación Clean Core y sigue usando los mismos módulos de función, clases y tablas de siempre. Todo compila. Todo funciona en desarrollo. Y nadie detecta el problema hasta que aparece un aviso de upgrade o hasta que alguien hace una revisión de código.

Las categorías de objetos que más problemas dan porque parecen inofensivos pero no están released:

Tablas del diccionario ABAP de uso interno , muchas tablas que todo el mundo ha leído directamente durante años con SELECT no están released. La alternativa son las CDS Views públicas que SAP ha liberado para ese mismo dato.

Módulos de función clásicos, muchos FMs que llevan décadas usándose no tienen el estado released. La alternativa suele ser una clase ABAP o una OData API equivalente.

Clases de uso interno , clases del framework de SAP que no tienen contrato público de estabilidad. Fácil de detectar en ADT pero fácil de ignorar si no tienes el contexto.

El cambio de mentalidad que requiere ABAP Cloud es pasar de buscar "cómo hago esto que necesito" a buscar primero "qué API released de SAP me da este dato o esta funcionalidad". Ese orden importa.

El SAP API Business Hub, la documentación de S/4HANA en help.sap.com y las CDS Views released del sistema son el punto de partida. Si no existe una API released para lo que necesitas, la alternativa es construirlo tú mismo sobre los datos y objetos que sí están liberados , nunca saltarte la restricción usando objetos internos porque "funciona igual".

Hay configuraciones en SAP que parecen tan básicas que nadie las cuestiona en el taller de diseño. El ejercicio fiscal es una de ellas. Y precisamente por eso es una de las que más problemas genera cuando el cliente no es español o cuando hay varias sociedades de distintos países en el mismo sistema.

El ejercicio fiscal define el período contable de una sociedad, cuándo empieza y cuándo acaba su año contable. En SAP se configura a través de la variante de ejercicio, que se asigna a cada sociedad FI de forma individual.

La confusión más habitual es asumir que el ejercicio fiscal siempre coincide con el año natural ( enero a diciembre ) porque en España y en la mayoría de países europeos es así. Pero no es universal ni mucho menos.

Hay tres tipos de variantes de ejercicio que SAP maneja y que el funcional tiene que conocer bien:

Ejercicio igual al año natural ( enero a diciembre). El más habitual en Europa. 12 períodos contables que coinciden exactamente con los 12 meses del calendario. Configuración más sencilla y la que todo el mundo da por supuesta sin preguntar.

Ejercicio fiscal desplazado. El año contable no empieza en enero. Por ejemplo en el Reino Unido muchas empresas tienen ejercicio de abril a marzo. En Estados Unidos es habitual octubre a septiembre. En Japón abril a marzo. Si configuras la variante de ejercicio incorrecta para una sociedad con este modelo el sistema asigna los documentos al período incorrecto y el cierre mensual no cuadra con la realidad financiera del cliente.

Ejercicio con períodos especiales. SAP permite hasta 16 períodos en una variante de ejercicio ,12 normales más hasta 4 especiales para ajustes de cierre anual, auditoría o correcciones post-cierre. Cuántos períodos especiales necesita el cliente y cómo se gestiona su apertura y cierre es una decisión de diseño que hay que tomar desde el principio.

Copiar la variante de ejercicio de una sociedad española para todas las sociedades del grupo sin verificar si el ejercicio fiscal es el mismo en cada país. En un rollout internacional esto aparece siempre y cuando aparece ya hay documentos contabilizados en períodos incorrectos que hay que corregir.

La pregunta que hay que hacer en el taller de diseño para cada sociedad es muy concreta: ¿en qué fecha empieza y termina tu año contable legal? No des por supuesto que es enero-diciembre. Pregúntalo explícitamente al responsable financiero de cada país.

La variante de ejercicio también afecta directamente a CO . Los períodos contables de FI y los períodos de CO tienen que estar alineados. Si hay una sociedad con ejercicio desplazado y el controlling no está configurado correctamente para ese mismo ejercicio, las imputaciones de costes y los informes de rentabilidad no cuadran con la contabilidad financiera.

Y en sistemas con varias sociedades de distintos países, cada sociedad puede tener su propia variante de ejercicio asignada. SAP lo soporta sin problema, siempre que el diseño se haya hecho correctamente desde el principio.

Una de esas funciones pequeñas que cuando la descubres te das cuenta de cuántas veces has calculado días entre fechas de forma incorrecta o innecesariamente compleja.

Calcula la diferencia en días entre dos fechas teniendo en cuenta el calendario de fábrica del sistema — es decir, respetando festivos y días no laborables según el calendario configurado en SAP. No es lo mismo que restar dos variables de tipo DATE, que simplemente cuenta días naturales sin saber si el lunes es festivo en Alemania.

En desarrollos de logística para calcular plazos de entrega reales, en SD para calcular días de vencimiento de ofertas o contratos, en MM para validar plazos de entrega de proveedores y en cualquier desarrollo donde la diferencia entre días naturales y días laborables tiene impacto real en el negocio.

Hay una dinámica muy común en los equipos SAP cuando aparece una tecnología nueva: el responsable siente la presión de que su equipo "esté al día" y organiza una formación general para todos. Todo el mundo hace el mismo curso de BTP o el mismo módulo de Joule. Todo el mundo obtiene su badge digital. Y tres meses después, nadie aplica nada de lo aprendido porque no había un proyecto real donde usarlo.

Eso no es formación. Es gestión de la ansiedad del responsable disfrazada de plan de desarrollo. 😅

Antes de decidir a quién formas en qué, hay tres preguntas que tienes que responder:

¿Qué proyectos reales vienen en los próximos 12 meses? La formación que no tiene un proyecto detrás donde aplicarse tiene una vida media de tres semanas en la memoria. Forma a las personas en lo que van a usar, no en lo que está de moda.

¿Quién tiene la base adecuada para absorber cada conocimiento nuevo? No todo el mundo está igual de preparado para aprender BTP o IA agéntica. Un ABAPER con diez años de experiencia en S/4HANA puede absorber el ABAP MCP Server en semanas. Un perfil junior sin esa base necesita meses solo para entender el contexto. Invertir lo mismo en los dos no tiene sentido.

¿Qué perfil te falta que no puedes formar internamente? A veces la respuesta honesta es que el conocimiento que necesitas no está en tu equipo y no va a estar en el tiempo que necesitas. En ese caso la decisión no es de formación, es de contratación o de partnership. Un responsable que lo confunde pierde tiempo formando cuando debería estar buscando.

Y aquí viene el punto que menos se habla en las reuniones de equipo pero que más duele en la práctica: el consultor SAP que ya tiene conocimientos de IA y BTP encima de su base clásica es el perfil más escaso y más demandado del mercado ahora mismo.

Si tienes a alguien así en tu equipo, tienes que saber que el mercado lo sabe también. Y que esa persona recibe llamadas de LinkedIn con una frecuencia que hace dos años no tenía.

Retener ese perfil no es solo una cuestión de salario , aunque el salario importa y mucho. Es una cuestión de proyectos interesantes, de autonomía, de reconocimiento real y de darle visibilidad dentro de la organización. El talento escaso no se retiene con café gratis y teletrabajo.

Se retiene con retos que no puede encontrar en otro sitio.

En tecnología, en negocio y hasta en nuestra carrera profesional, muchas veces esperamos el momento perfecto para movernos.

Aprender algo nuevo.
Cambiar de proyecto.
Hablar con un cliente.
Lanzar una idea.

Pero la realidad es que el momento perfecto casi nunca existe.

Y mientras algunos esperan a “tenerlo todo claro”, otros avanzan aunque no tengan todas las respuestas.

En SAP esto se ve muchísimo.

La tecnología cambia, los modelos cambian y los perfiles evolucionan constantemente. Y muchas veces, quedarse quieto “por seguridad”… acaba siendo más arriesgado que dar el paso.

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 👋