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

En GROUPmee hemos desarrollado un conector que integra Signaturit directamente en tu SAP Successfactors. Envía, firma y archiva contratos sin salir del sistema. Más rapidez, más trazabilidad. 100% validez legal.

Hay algo bastante curioso cuando hablamos de cuántos años se necesitan para ser senior en SAP.

En muchas empresas, el nivel senior no solo está ligado a la experiencia… también está ligado al sueldo.

Y ahí es donde aparece una situación bastante común en el sector.

Como los rangos salariales suelen estar asociados a categorías (junior, mid-level, senior), muchas veces ocurre algo curioso: puedes tener un nivel real más alto que el nivel que aparece “sobre el papel”.

Por ejemplo, no es raro encontrar consultores con sueldo de mid-level que, por los proyectos que han vivido y los problemas que han tenido que resolver, ya tienen más criterio que algunos perfiles considerados senior.

Y también ocurre al revés: consultores que todavía figuran como junior, pero que después de unos cuantos proyectos empiezan a tener ya una visión bastante amplia del sistema, de los procesos y de cómo se comporta SAP en situaciones reales.

Esto no significa que los años no importen. Al contrario. La experiencia y la madurez que tienen muchos seniors es tremendamente valiosa, porque normalmente han visto más situaciones, más clientes y más problemas reales a lo largo del tiempo.

Pero también demuestra algo interesante: muchas veces la seniority en consultoría no es solo una cuestión de años, sino también de cómo encaja esa experiencia dentro de las categorías profesionales… y dentro de las bandas salariales.

Por eso, cuando alguien pregunta cuántos años se necesitan realmente para ser senior en SAP, la respuesta no siempre está solo en el calendario.

A veces también está… en el Excel de salarios. 😄

SAP ha anunciado recientemente la llegada de la siguiente generación de su plataforma de procurement, conocida como Next-Gen SAP Ariba. La idea detrás de este anuncio es bastante clara: transformar la gestión de compras empresariales para que pase de ser un proceso principalmente operativo a convertirse en un proceso mucho más inteligente, automatizado y guiado por datos.

En esencia, SAP está reconstruyendo SAP Ariba sobre una nueva base tecnológica para adaptarla a la nueva etapa del software empresarial: la era del cloud, las plataformas y la inteligencia artificial.

La principal novedad de esta nueva generación es que SAP define Ariba como una plataforma “AI-native”, es decir, una solución donde la inteligencia artificial no es solo una funcionalidad añadida, sino parte central del diseño del sistema.

Esto significa que muchas tareas del proceso de compras —desde el análisis de ofertas de proveedores hasta la toma de decisiones sobre adjudicaciones— podrán apoyarse en algoritmos que analizan datos y sugieren acciones.

Una pieza clave dentro de esta estrategia es la integración con Joule, el copiloto de inteligencia artificial de SAP. Este asistente puede ayudar a los equipos de compras a automatizar tareas, analizar información o tomar decisiones con mayor contexto.

Por ejemplo, una de las capacidades anunciadas es un agente de análisis de ofertas, capaz de comparar automáticamente las propuestas de distintos proveedores y evaluar factores como el coste total o el riesgo asociado.

En otras palabras, el objetivo es que el sistema no solo registre procesos, sino que ayude activamente a tomar decisiones.

Otro cambio importante es la base tecnológica.

La nueva generación de SAP Ariba está construida sobre SAP Business Technology Platform (BTP), lo que permite una integración más profunda con otros sistemas SAP y con los nuevos ERP en la nube.

Esto facilita varias cosas:

En la práctica, SAP está alineando Ariba con su arquitectura cloud moderna, lo que permitirá evolucionar el producto con mayor rapidez.

Otro aspecto que SAP está abordando es la experiencia de usuario.

Las nuevas versiones incluyen una interfaz renovada y más coherente, con navegación simplificada y paneles personalizados que centralizan tareas, alertas y análisis en un único punto de entrada.

Esto puede parecer un detalle menor, pero en soluciones empresariales complejas la experiencia de usuario tiene un impacto enorme en la adopción por parte de los equipos.

La idea es que los profesionales de procurement puedan:

El objetivo final de esta evolución es cambiar la naturaleza del proceso de compras.

Tradicionalmente, el procurement ha sido un proceso bastante reactivo: recibir solicitudes, comparar proveedores, lanzar pedidos y gestionar contratos.

La nueva generación de Ariba busca convertir ese proceso en algo mucho más proactivo y automatizado, donde el sistema puede anticipar necesidades, identificar riesgos y sugerir acciones.

Esto encaja con una tendencia más amplia: en muchas empresas, los departamentos de compras están pasando de ser una función administrativa a convertirse en un área estratégica para controlar costes, gestionar riesgos de proveedores y mejorar la resiliencia de la cadena de suministro.

Más allá de la tecnología, este anuncio refleja algo importante en la estrategia de SAP.

La compañía está intentando llevar inteligencia artificial directamente a los procesos empresariales clave: finanzas, recursos humanos, logística… y ahora también compras.

Y en el caso del procurement, SAP está apostando claramente por tres pilares:

Las nuevas capacidades de Next-Gen SAP Ariba empezarán a desplegarse progresivamente a partir de 2026, lo que marcará una nueva etapa para las soluciones de gestión del gasto dentro del ecosistema SAP.

La acción de SAP SE ha tenido una semana relativamente tranquila en bolsa, con ligeras subidas y bajadas que reflejan un momento de cierta estabilidad, pero también de cautela por parte de los inversores.

Durante los últimos días, la acción ha oscilado aproximadamente entre los 165 € y los 173 € en el mercado alemán XETRA, con movimientos diarios bastante moderados. Por ejemplo, a comienzos de la semana llegó a situarse cerca de los 173 €, mientras que en otros momentos abrió la sesión con pequeñas caídas cercanas al 1 %, rondando los 165 € por acción.

Este tipo de movimientos relativamente contenidos suele indicar que el mercado está esperando nuevos catalizadores, como resultados trimestrales o anuncios estratégicos.

Otro factor que ha influido en el comportamiento de muchas acciones tecnológicas —incluida SAP— es el contexto global del mercado. En los últimos días, los principales índices bursátiles han mostrado cierta debilidad debido a tensiones geopolíticas y preocupaciones sobre la inflación, lo que ha generado más cautela entre los inversores.

Cuando el mercado entra en fases de mayor incertidumbre, incluso compañías sólidas como SAP suelen mostrar movimientos más limitados o periodos de consolidación.

Más allá de los movimientos semanales, lo interesante es en qué están fijándose realmente los analistas cuando analizan la acción de SAP.

Actualmente hay tres factores que concentran gran parte de la atención:

La estrategia de inteligencia artificial
SAP está integrando cada vez más capacidades de IA dentro de su ecosistema, especialmente en productos como S/4HANA y la Business Technology Platform. Los inversores ven esto como una posible fuente de crecimiento a medio plazo.

La evolución del negocio cloud
El crecimiento de los ingresos recurrentes en la nube sigue siendo uno de los indicadores más importantes para evaluar el futuro de la compañía.

Los próximos resultados financieros
El mercado también está pendiente del próximo anuncio de resultados, previsto para abril de 2026, que podría marcar la siguiente gran dirección del valor.

A pesar de estos movimientos moderados, SAP sigue siendo uno de los pesos pesados del mercado europeo. La compañía mantiene una capitalización cercana a 200 000 millones de euros y continúa siendo una de las empresas con mayor peso dentro del índice alemán DAX.

Esto significa que cualquier movimiento importante en SAP tiene un impacto directo en el propio índice.

Más allá de la volatilidad semanal, el mercado sigue viendo a SAP como una compañía con un posicionamiento fuerte en software empresarial, especialmente gracias a su transición hacia el cloud y su apuesta por la inteligencia artificial.

Por ahora, la acción parece estar en una fase de espera, donde los inversores están observando cómo evolucionan estos dos pilares antes de definir la próxima gran tendencia del valor.

Bueno…

Aquí como siempre tengo varias respuestas. Pero imagino que vosotros queréis saber la opinión clara y sincera de El Periódico del Consultor 😄

Porque esta es una de esas preguntas que todos los consultores se hacen en algún momento de su carrera.

¿Cuándo se pasa realmente de ser consultor a ser consultor senior?

Y la respuesta corta es: depende.

La respuesta larga es un poco más interesante.

Tradicionalmente, en consultoría SAP el nivel senior se ha medido por años de experiencia. Si preguntas en cualquier empresa o hablas con cualquier consultor del sector, lo normal es escuchar cifras bastante similares: alrededor de 8 a 10 años de experiencia para considerar a alguien senior.

Y en muchos casos es verdad. Después de tantos años trabajando en proyectos, lo normal es haber visto bastantes situaciones distintas, haber pasado por varios clientes y haber aprendido a resolver problemas con bastante autonomía.

Pero la realidad es que los años por sí solos no cuentan toda la historia.

También podemos medir la seniority por experiencia en proyectos.

Imagina que alguien te dice que ha trabajado en tres grandes proyectos de implantación de S/4HANA, que ha pasado por clientes complicados, que ha tenido que resolver problemas reales en producción y que ha trabajado con distintas tecnologías dentro del ecosistema SAP.

Si esa persona tiene 6 años de experiencia, ¿diríamos que no es senior solo porque no ha llegado todavía a los 8 o 10 años?

Probablemente muchos diríamos que sí lo es.

Porque los proyectos en los que participas marcan muchísimo tu crecimiento profesional. No es lo mismo pasar años haciendo tareas muy repetitivas que participar en proyectos complejos donde tienes que tomar decisiones, resolver problemas y adaptarte a situaciones reales de cliente.

Pero todavía hay una tercera forma de verlo que, personalmente, me parece aún más interesante.

La especialización.

Alguien puede no ser especialmente senior dentro del ecosistema SAP global, pero sí tener un conocimiento muy profundo en una especialización concreta.

Por ejemplo, algo que hemos comentado en otros boletines y en algunos SAPOCALYPSIS: TicketBAI o el SII.

Imagina un consultor que lleva 2 o 3 años trabajando exclusivamente en proyectos relacionados con SII, que ha participado en varias implantaciones, que entiende perfectamente cómo funciona el flujo de información, los puntos críticos del proceso y los problemas que suelen aparecer en este tipo de proyectos.

Ahora compáralo con un consultor con 10 años de experiencia general en SAP, pero que solo ha trabajado una vez con SII y de forma bastante superficial.

Si tuvieras que tomar una decisión sobre un proyecto relacionado con SII… ¿a quién escucharías antes?

Probablemente al profesional que ha trabajado intensamente en ese tema concreto, aunque tenga menos años de experiencia total.

Y esto nos lleva a una idea bastante importante: la seniority no siempre es global. Muchas veces es contextual.

Puedes ser un consultor muy experimentado en tu área concreta y seguir aprendiendo muchísimo en otras partes del ecosistema SAP.

Por eso, más que medir la seniority únicamente en años, quizá tenga más sentido pensar en tres cosas:

Al final, la seniority no se mide solo por el tiempo que llevas en SAP.

Se mide por las situaciones que has vivido, los problemas que has resuelto y la madurez profesional que has desarrollado en el camino.

Cuando generamos correos desde SAP ( por ejemplo usando CL_BCS o funciones clásicas de envío) muchas veces construimos el cuerpo del email concatenando textos. Algo como esto es muy habitual en código ABAP más antiguo:

Después ese texto se añade al cuerpo del email que se enviará y que luego podremos revisar en la transacción SOST.

El problema es que los correos en SAP no suelen trabajar con un único string, sino con tablas internas de líneas de texto (SOLI, SOLIX, etc.). Cuando concatenamos textos largos y los añadimos directamente, es bastante común encontrarse luego en SOST con cosas como:

Esto ocurre porque el sistema SAP maneja el cuerpo del correo en líneas con tamaño limitado.

En la mayoría de envíos estándar de SAP:

Por eso es recomendable construir el correo línea a línea desde el principio.

Por ejemplo:

De esta forma controlas exactamente cómo aparecerá el contenido del correo cuando el usuario lo reciba y cuando lo revises en SOST.

Otro detalle que a veces genera confusión es el tamaño del asunto del correo.

En la mayoría de implementaciones estándar:

Por eso, aunque SAP permita más longitud, lo recomendable es mantener el asunto claro y corto.

Por ejemplo:

Con ABAP moderno podemos hacerlo de una forma mucho más limpia usando string templates y expresiones modernas del lenguaje.

Por ejemplo:

Aquí estamos usando varias características modernas de ABAP:

El resultado es un cuerpo de email perfectamente estructurado que se verá correctamente cuando se envíe y cuando se consulte después en SOST.

Cuando generes correos desde SAP, intenta pensar siempre en líneas de texto en lugar de un único string gigante.

Si controlas el tamaño de cada línea (≈255 caracteres) y mantienes el asunto claro y conciso, evitarás muchos de los problemas típicos que aparecen cuando revisas los correos enviados en SOST.

En SAP hay una funcionalidad que muchas veces se ve como algo “simple”, pero que en realidad tiene muchísimo más potencial del que parece: los mensajes de salida.

En la mayoría de proyectos se utilizan para cosas bastante conocidas. Por ejemplo:

En muchos procesos estándar de SAP —sobre todo en módulos como SD, MM o FI— los mensajes de salida forman parte fundamental del flujo de comunicación con sistemas externos o con los propios usuarios.

Pero lo interesante es que, técnicamente, los mensajes de salida no se limitan a eso.

La razón es bastante simple: en el momento en que se ejecuta un mensaje de salida, SAP acaba llamando a un programa, una función o una rutina de procesamiento. Y en el momento en que hay código… las posibilidades se multiplican.

Por ejemplo, el caso más típico es el EDI. Cuando se genera un mensaje EDI, normalmente se ejecuta un programa que prepara los datos y los envía al sistema de integración correspondiente. Esto ya es bastante potente por sí mismo, porque permite integrar SAP con otros sistemas de forma automatizada.

Pero la realidad es que muchas implementaciones van bastante más allá.

Hay proyectos donde, en el momento de procesar un mensaje de salida, se ejecuta lógica adicional como por ejemplo:

Incluso en casos donde el mensaje genera simplemente un correo electrónico, el programa que se ejecuta puede hacer muchas más cosas antes o después del envío. Desde validar información adicional hasta lanzar procesos que no tienen nada que ver directamente con el correo.

Y aquí es donde aparece uno de los puntos más interesantes para consultores funcionales: cuando configuras un mensaje de salida, en realidad estás definiendo un punto de ejecución dentro del proceso de negocio.

Ese punto se dispara cuando ocurre algo muy concreto:

Y justo en ese momento SAP puede ejecutar lógica adicional.

En algunos proyectos esto se utiliza incluso para lanzar jobs o procesos posteriores, por ejemplo para iniciar integraciones externas, sincronizaciones con otras plataformas o tratamientos adicionales de datos.

Por eso, aunque muchas veces pensemos en los mensajes de salida simplemente como “el mecanismo que imprime formularios o envía EDI”, en realidad pueden convertirse en un punto de extensión muy potente dentro de los procesos de SAP.

Eso sí, como ocurre con cualquier funcionalidad potente, conviene utilizarlos con criterio. Cuando empiezan a acumular demasiada lógica dentro del programa de procesamiento, pueden convertirse en algo difícil de mantener.

Pero bien utilizados, los mensajes de salida son una herramienta extremadamente flexible que permite conectar procesos, sistemas e integraciones justo en el momento en el que ocurre algo relevante dentro de SAP.

Y esa es precisamente su principal cualidad: no solo comunican lo que ha pasado en el sistema… también pueden activar todo lo que tiene que pasar después.

Hay muchas situaciones en SAP donde trabajamos con datos binarios: archivos adjuntos, PDFs generados por formularios, documentos enviados por correo o incluso datos que vienen de integraciones externas.

En estos casos es bastante común encontrarse con diferentes tipos de datos como RAW, SOLIX, XSTRING o STRING, y tener que convertir entre ellos para poder procesarlos correctamente.

Una función muy útil para este tipo de escenarios es:

SCMS_BINARY_TO_XSTRING

Esta función permite convertir datos binarios almacenados en una tabla RAW (normalmente tipo SOLIX o RAW) a un XSTRING, que es un formato mucho más flexible para trabajar con archivos dentro de ABAP.

Un ejemplo sencillo sería algo así:

Después de esta conversión ya tienes el archivo completo dentro de una variable XSTRING.

Este tipo de conversiones aparecen constantemente cuando trabajas con:

Envío de correos desde SAP

Cuando envías un PDF por email usando CL_BCS, muchas veces el archivo se genera en formato binario y hay que convertirlo a XSTRING para adjuntarlo correctamente.

Formularios (SmartForms / Adobe Forms)

Cuando generas un PDF desde un formulario SAP, el resultado normalmente se maneja en formato XSTRING para poder guardarlo, enviarlo o adjuntarlo.

Integraciones con APIs

En muchas integraciones modernas los archivos se envían en Base64 o XSTRING, por lo que primero hay que convertir los datos binarios generados en SAP.

Gestión de documentos

Cuando trabajas con GOS, ArchiveLink o documentos adjuntos, muchas veces los archivos se manipulan internamente como XSTRING.

El tipo XSTRING es especialmente útil porque permite manejar datos binarios completos en memoria sin preocuparte por la estructura de las tablas RAW.

En otras palabras, puedes tratar un archivo completo (PDF, imagen, XML, etc.) como una sola variable.

Esto hace mucho más fácil:

En proyectos SAP modernos es bastante habitual ver flujos como este:

Por eso conocer funciones como SCMS_BINARY_TO_XSTRING (y su inversa SCMS_XSTRING_TO_BINARY) suele ahorrar bastante tiempo cuando trabajas con archivos o integraciones.

Porque tarde o temprano, en cualquier proyecto SAP, acabas teniendo que mover datos binarios de un formato a otro.

Cuando hablamos de seniority en SAP casi siempre terminamos en el mismo debate: los años de experiencia. Durante mucho tiempo ha sido la forma más sencilla de medir el nivel de un consultor. Si alguien lleva ocho o diez años trabajando en proyectos SAP, automáticamente tendemos a pensar que es un perfil senior. Pero cuando pasas a estar en una posición de liderazgo, gestionando personas, proyectos y salarios, te das cuenta bastante rápido de que la realidad es un poco más compleja que eso.

Porque cuando gestionas un equipo empiezas a ver algo que desde fuera no siempre es tan evidente: los años son solo una parte de la historia. Lo que realmente marca la diferencia son las capacidades que una persona ha desarrollado, los problemas que sabe resolver, las decisiones que es capaz de tomar y los proyectos que ha sacado adelante. En otras palabras, alguien no se vuelve más senior simplemente porque pase el tiempo, sino por todo lo que ha aprendido y ha conseguido durante ese tiempo.

Y aquí es donde entra una de las responsabilidades más importantes de cualquier persona que gestiona un equipo: saber ver ese crecimiento. En muchos equipos ocurre algo bastante habitual. Un consultor empieza como junior, aprende, participa en proyectos, empieza a resolver problemas por su cuenta y poco a poco va ganando autonomía. Con el tiempo empieza también a ayudar a otros compañeros, a entender mejor los procesos de negocio o a tomar pequeñas decisiones técnicas o funcionales. En la práctica, ya no está trabajando como un junior. Pero sobre el papel sigue siéndolo.

Este es uno de los errores más comunes en la gestión de equipos: gestionar a las personas por etiqueta en lugar de por capacidad real. Porque llega un momento en el que alguien ya está aportando mucho más valor del que corresponde a su categoría o a su salario. Esa persona probablemente ya resuelve problemas complejos, entiende mejor el sistema y empieza a ser una referencia dentro del equipo. Sin embargo, su posición dentro de la organización no ha cambiado todavía.

Lo que ocurre después suele ser bastante predecible. Esa persona empieza a recibir ofertas del mercado. Y lo curioso es que esas ofertas no suelen decir algo como “te pagamos más porque tienes más años de experiencia”. En realidad dicen algo mucho más simple: “te pagamos más por hacer lo mismo que ya estás haciendo ahora”. Y claro, si alguien te ofrece mejores condiciones por el mismo trabajo que ya haces cada día, la decisión suele ser bastante sencilla.

Desde el punto de vista del empleado es algo completamente lógico. No se va por tener más años de experiencia, se va porque su valor real en el mercado ya es mayor que el que tiene dentro de la empresa. El mercado está reconociendo algo que quizá dentro del equipo todavía no se ha reconocido del todo.

Para el responsable del equipo, sin embargo, el impacto suele ser mayor de lo que parece. Porque cuando esa persona se va no solo pierdes a alguien que estaba en la plantilla. Pierdes a alguien que ya estaba formado, que conocía el cliente, que entendía el sistema y que sabía cómo resolver ciertos problemas. Y entonces empieza un proceso que cualquier responsable conoce bien: volver a contratar, volver a formar, volver a acompañar a alguien durante meses hasta que alcance ese mismo nivel.

Todo esto muchas veces se podría haber evitado simplemente estando atento. Hay señales bastante claras que ayudan a identificar cuándo alguien está creciendo dentro del equipo. Por ejemplo, cuando empieza a resolver problemas difíciles con autonomía, cuando otros compañeros empiezan a preguntarle dudas o cuando empieza a entender el impacto de sus decisiones dentro de un proyecto. Ese tipo de comportamientos suelen indicar que alguien está avanzando en su madurez profesional.

Existe una frase que todos hemos escuchado muchas veces: nadie es imprescindible. Y es verdad. Pero eso no significa que todos aportemos el mismo valor en cada momento. En todos los equipos hay personas que desbloquean situaciones complicadas, que ayudan a otros compañeros o que entienden mejor lo que necesita el cliente. Cuando alguien así se va por no haber ajustado sus condiciones a tiempo, el impacto suele ser bastante mayor que cuando se pierde a alguien que todavía está empezando.

Por eso, una de las habilidades más importantes para cualquier líder en consultoría es aprender a mirar más allá de los años de experiencia y evaluar realmente qué está aportando cada persona al equipo. No todos los consultores evolucionan al mismo ritmo. Hay personas que en tres años viven experiencias equivalentes a cinco o seis, simplemente porque han estado en proyectos más complejos o han tenido que enfrentarse a situaciones más exigentes.

Al final, el liderazgo no consiste solo en repartir tareas o en hacer seguimiento de los proyectos. También consiste en saber identificar el talento que tienes delante antes de que el mercado lo haga por ti. Porque cuando alguien ya no está haciendo trabajo de junior pero sigue teniendo condiciones de junior, el desenlace suele ser bastante predecible.

Y cuando eso ocurre, normalmente no es culpa del empleado. Es simplemente que el mercado está dispuesto a pagar por lo que esa persona ya sabe hacer. Por eso, uno de los grandes retos para cualquier responsable es entender en qué punto real de su carrera está cada persona de su equipo y actuar en consecuencia. Porque si sabes verlo a tiempo, puedes hacer algo al respecto. Y si no lo ves, lo más probable es que el mercado sí lo vea.

En muchos proyectos (especialmente en entornos complejos como SAP) hay situaciones que todo el mundo prefiere evitar: errores difíciles de reproducir, procesos mal documentados, desarrollos antiguos que nadie quiere tocar o integraciones que “si funcionan mejor no tocarlas”.

Pero curiosamente, es precisamente en esos puntos donde más se aprende.

Cuando alguien decide investigar ese problema que nadie quiere mirar, entender cómo funciona realmente un proceso o analizar un comportamiento extraño del sistema, está haciendo algo mucho más valioso que simplemente completar una tarea: está ampliando su conocimiento del sistema y del negocio.

Con el tiempo, esos momentos se acumulan. Y son precisamente los que hacen que una persona pase de ejecutar tareas a entender realmente cómo funcionan las cosas.

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 👋