¿Cuántos procesos en SAP siguen terminando con un PDF enviado por
correo esperando una firma?

El problema con muchas integraciones de firma en SAP es que
ignoran las estrategias de liberación ya configuradas y montan una
lógica paralela.

El Conector SAP Signaturit que implantamos en GROUPmee lee
directamente las estrategias de liberación de SAP MM, extrae los
aprobadores en el orden correcto y lanza el flujo en Signaturit sin
duplicar configuración.

Si tienes un entorno SAP MM con este punto ciego, vale la pena leer
cómo lo resolvimos.

Hay un dato que circula por el mercado laboral SAP y que cuando lo ves escrito en frío produce una mezcla de sorpresa y reconocimiento, dos profesionales con el mismo módulo, los mismos años de experiencia y trabajando en la misma ciudad pueden tener una diferencia salarial de más de 25.000 euros anuales.

No es un caso extremo ni una excepción. La brecha entre ambos extremos puede superar los 25.000 euros anuales en el mismo módulo. Y la diferencia entre los dos perfiles rara vez está en lo que saben hacer. Está en lo que cobran por ello.

En Madrid, un Senior SAP Consultant gana alrededor de 49.000 €/año como promedio, con extremos entre ~41.000 y ~57.000 € dependiendo de experiencia y empresa. Pero eso es la media. El mercado real tiene picos mucho más altos para el que sabe dónde mirar y mucho más bajos para el que lleva años sin revisar lo que cobra.

Un consultor SAP FI/CO senior en España cobra entre 48.000 y 60.000 euros brutos al año, y un lead funcional supera los 60.000 con techo en 85.000. Y un consultor junior de FI/CO parte desde 26.000 euros. Es decir, el mismo ecosistema, el mismo módulo, va de 26.000 a 85.000 euros según el nivel y sobre todo según cómo se negocia.

Lo más curioso de todo, esa diferencia no siempre refleja una diferencia proporcional en conocimiento o en valor aportado. A veces refleja simplemente quién preguntó, quién investigó y quién negoció.

Hay algo que me llama la atención de esta noticia más allá de la tecnología que describe. SAP tiene un equipo interno llamado People Analytics que actúa como "customer zero" — el primer adoptante de sus propios productos antes de lanzarlos al mercado. Es decir, SAP se autoimpone como cliente de lo que vende. Y lo que cuenta este artículo es exactamente lo que descubrieron cuando intentaron escalar su propio sistema de analítica de RRHH.

El problema que tenían no es muy distinto al que tiene cualquier departamento de RRHH con SAP: demasiada demanda de datos, un modelo centralizado que no escala y un equipo de analítica permanentemente diciendo que no a peticiones porque la cola de pendientes no para de crecer. El dashboard estrella de SAP internamente era el MyTeam Dashboard, un informe de 360 grados con datos de plantilla disponible para todos los managers. Tan exitoso que se convirtió en el informe más usado de toda la compañía. Y tan exitoso que colapsó el modelo porque todo el mundo quería más de lo mismo pero diferente.

La solución por la que apostaron tiene un nombre: People Intelligence en SAP Business Data Cloud. Y la clave no es la herramienta en sí sino el cambio de enfoque que implica. En lugar de seguir construyendo dashboards a medida para cada petición, el equipo decidió gobernar y abrir la capa de datos que hay debajo de los dashboards. La idea es crear productos de datos reutilizables, gestionados y fiables que cualquier equipo pueda consumir directamente sin pasar por el cuello de botella del equipo de analítica.

El catálogo que ofrece People Intelligence incluye 69 productos de datos solo para el área de composición de plantilla, con cientos de joins ya resueltos, documentados y probados por SAP. Ese es el número que más me llama la atención del artículo. 69 productos de datos prebuilt. Para una empresa que tiene que construir algo similar desde cero, eso representa meses de trabajo de modelado, testing y documentación que ya viene hecho.

El resultado en la práctica: el contenido prebuilt actúa como punto de partida del 80% de las conversaciones con negocio, reemplazando los procesos de recogida de requisitos en blanco por discusiones más focalizadas. Los managers acceden a sus KPIs personalizados a través de MyMetrics, pueden pedir resúmenes a Joule en lenguaje natural y obtienen gráficos sin necesidad de abrir un ticket al equipo de analítica.

Hay dos detalles del artículo que merecen atención especial para cualquier consultor que trabaje con SuccessFactors o con proyectos de datos en SAP. El primero es la gestión de privacidad: el mismo producto de datos se ofrece en dos versiones, una con PII completo y otra con información anonimizada, lo que permite que los datos correctos lleguen al consumidor correcto cumpliendo con los requisitos del Comité de Empresa y la normativa de protección de datos. El segundo es el horizonte: SAP está construyendo agentes Joule que operarán directamente sobre estos productos de datos gobernados, con un People Intelligence Assistant previsto para noviembre de 2026.

Y la frase que resume todo el artículo, del responsable de plataforma y analítica de SAP, merece guardarse: "Invertir en una estrategia de producto de datos es el primer paso esencial. Es lo que habilita el acceso gobernado a los datos y produce modelos listos para IA como resultado."

Lo que SAP está diciendo con esto, usando su propio caso como ejemplo, es exactamente lo que llevamos meses repitiendo en este boletín: la IA no falla por los modelos. Falla por los datos. Y quien no invierte en gobernar sus datos primero va a tener agentes de IA muy potentes operando sobre un caos que simplemente se va a automatizar más rápido.

Si la semana pasada el mercado estaba en modo espera, esta semana está en modo espera pero con más nervios. La cotización de SAP en Fráncfort se sitúa esta semana en torno a los 140€, prácticamente sin moverse del rango en el que lleva instalada desde hace semanas. Un rango diario entre 130€ y 142€ y un mínimo de 52 semanas en 130,62€ que está incómodamente cerca del precio actual.

La inmovilidad no es casual. El mercado está literalmente aparcado esperando a que SAP publique sus resultados del segundo trimestre de 2026 el próximo 23 de julio. Hasta entonces, nadie quiere apostar fuerte en ninguna dirección. Los que creen que SAP está barata no compran porque esperan confirmar con los números. Los que creen que puede caer más tampoco venden con fuerza porque igual los resultados sorprenden al alza. El volumen de negociación está por debajo de la media de tres meses. Todos mirando el calendario.

¿Qué se espera para ese día? Las estimaciones de los analistas hablan de 1,77 euros por acción para el Q2, ligeramente por encima de lo que entregó el Q1. Los ingresos cloud siguen siendo la variable que más mira el mercado. Si SAP muestra que el ritmo de adopción cloud está acelerando, la acción tiene mucho recorrido al alza desde los niveles actuales. Si los números decepcionan de nuevo... bueno, el mínimo de 52 semanas está ahí mismo para recordarnos que hay suelo. O eso esperamos.

El precio objetivo medio a 12 meses que los analistas dan a SAP sigue siendo de 214€, con una estimación alta de 290€. Es decir, incluso la media de los analistas supone multiplicar por 1,5 el precio actual. Eso o los analistas están muy equivocados o el mercado está siendo muy severo con SAP. El 23 de julio empezaremos a saber cuál de los dos tiene razón.

Mientras tanto, el CEO dice que en cuatro años puede que no haya programadores, la empresa reorganiza su cúpula directiva alrededor de la IA y lanza People Analytics sobre Business Data Cloud. Mucho movimiento estratégico. Poca reacción en bolsa. Clásico.

Voy a hablar de algo que en este sector se susurra mucho y se dice en voz alta muy poco. Cuánto se cobra, cuánto se debería cobrar y por qué hay tanta diferencia entre los dos.

Y para hablar de esto con claridad hay que empezar por reconocer algo incómodo, en SAP hay mucha incultura salarial. No porque la gente sea ignorante, sino porque el mercado está fragmentado, la información no es transparente y nadie te enseña a negociar cuando entras al sector. Llevas años trabajando, crees que cobras razonablemente bien... y entonces te enteras de lo que cobra el compañero que entró hace seis meses. Y algo no cuadra.

Eso no es una conspiración. Es el resultado de un mercado donde cada empresa, cada proyecto y cada negociación es distinta, donde los rangos salariales varían enormemente según el módulo, la empresa, el tipo de cliente y si el proyecto es nacional o internacional, y donde la norma no escrita ha sido siempre no hablar de dinero. Y esa norma, más que a las empresas, les ha beneficiado a ellas. Porque el que no llora no mama. Y el que no pregunta no sabe lo que le falta.

La realidad del mercado en 2026 es esta, un consultor junior de SAP parte desde los 20.000-25.000 euros brutos anuales. Un perfil medio con dos o tres o cuatro años de proyecto real está en el rango de 35.000 a 45.000 euros. Un senior con cinco o más años en implantaciones completas está entre 46.000 y 55.000. Y un lead consultant o perfil de arquitectura puede superar los 60.000 y llegar a 85.000 según el módulo y el tipo de empresa. Eso es el mercado. El problema es que dentro de esas bandas hay un margen enorme que depende de factores que tienen poco que ver con lo que sabes y mucho con cómo lo vendes.

Porque el mercado SAP tiene una particularidad que muy poca gente nombra, las empresas destinan más dinero a contratar nuevo talento que a subir el sueldo del que ya tienen. No es malicia, es dinámica de mercado. Para contratar a alguien nuevo hay competencia, hay urgencia, hay que pagar lo que pide el mercado en ese momento. Para subir el sueldo de alguien que ya está... hay presupuesto aprobado el año anterior, hay procesos internos, hay que justificarlo ante dirección. El resultado es que alguien nuevo puede entrar cobrando más que alguien que lleva cinco años haciendo exactamente el mismo trabajo y haciéndolo bien. Y la única forma de corregir eso es preguntar, comparar y negociar. Lo cual requiere saber lo que vale uno, lo cual requiere información que nadie te da de forma espontánea.

Ahora la pregunta que realmente importa, ¿sabes lo que generas? ¿Sabes cuánto vales?

No hablo de lo que pone en tu contrato. Hablo de lo que factura la empresa con tu trabajo, de lo que te costaría a un cliente contratarte directamente, de lo que pagaría otra empresa por tu perfil en este momento. Esa información existe. Está en los portales de empleo, en LinkedIn, en las conversaciones que tienes con otros consultores, en los procesos de selección a los que te presentas aunque no vayas a cambiar de trabajo. La información salarial del mercado no está oculta. Está disponible para quien la busca. El que no la busca trabaja con los datos que le dan, que no siempre son los que le convienen.

Y luego está la variable que más diferencia hace y que menos se menciona, el inglés y el contexto internacional. Un consultor de MM y SD con inglés fluido trabajando en proyectos internacionales no cobra lo mismo que uno con el mismo módulo trabajando para un cliente nacional. No porque sepa más de SAP, sino porque el mercado al que accede es diferente y más amplio. Y ese mercado paga mejor porque compite globalmente por el talento, no solo con las empresas de tu ciudad.

¿Tiene sentido eso? Depende de cómo lo mires. Técnicamente, los dos consultores hacen el mismo trabajo en SAP. Pero el contexto importa. El cliente importa. La complejidad del proyecto importa. Y el idioma en el que puedes comunicarte con ese cliente importa. No es justo en términos absolutos, pero es la realidad del mercado. Y conocer esa realidad es el primer paso para decidir en qué lado quieres estar.

Lo que sí me parece claro es esto, si llevas más de dos años sin revisar tu salario, sin comparar lo que cobras con lo que paga el mercado ahora mismo, sin tener al menos una conversación con tu empresa sobre compensación... probablemente estés dejando dinero sobre la mesa. No porque seas mal consultor. Sino porque el mercado no sube los sueldos de forma automática. Los sube cuando alguien pregunta. Y ese alguien tienes que ser tú.

¿Cuándo fue la última vez que investigaste lo que cobra alguien con tu perfil en el mercado actual?

Uno de los síntomas más confusos para alguien que llega nuevo al mundo BASIS, el sistema responde lento, los usuarios se quejan, abres el monitor de infraestructura y el servidor está al 20% de CPU y al 30% de memoria. Todo parece bien. Y sin embargo el sistema va como si estuviera cargando Windows Vista en un ordenador del 2003. 😅

La respuesta casi siempre está en los Work Processes.

Un Work Process es la unidad de ejecución de SAP. Es el proceso del sistema operativo que realmente ejecuta el código ABAP cuando un usuario hace algo en el sistema. Y aquí está la clave, SAP tiene un número fijo y limitado de Work Processes configurados en el perfil de instancia. No importa cuánta CPU o memoria libre tenga el servidor. Si todos los Work Processes están ocupados, el siguiente usuario que intente hacer algo tiene que esperar a que uno quede libre.

Los tipos principales que hay que conocer son los Dialog Work Processes, que atienden las peticiones interactivas de los usuarios, los Background Work Processes, que ejecutan los jobs en background, los Update Work Processes, que procesan las actualizaciones de base de datos de forma asíncrona, y los Spool Work Processes, que gestionan la impresión.

La transacción para ver el estado en tiempo real de todos los Work Processes del sistema es SM50 para la instancia local y SM66 para todas las instancias del landscape de golpe. Lo que hay que buscar cuando el sistema va lento son Work Processes en estado Running con un tiempo de ejecución anormalmente alto que no avanzan, Work Processes en estado PRIV que han consumido toda la memoria extendida disponible y están bloqueando al resto, y Work Processes en estado Stopped que indican un problema más grave de configuración o de recursos.

El número de Work Processes de cada tipo se configura en el perfil de instancia con los parámetros rdisp/wp_no_dia para Dialog, rdisp/wp_no_btc para Background y rdisp/wp_no_spo para Spool. Cambiar estos valores requiere reiniciar la instancia y es una decisión que hay que tomar con criterio porque aumentar los Dialog Work Processes consume más memoria compartida.

En cualquier empresa con stock gestionado hay una pregunta que alguien tiene que responder constantemente, ¿cuándo hay que pedir más? Si lo hace un comprador mirando el almacén cada día, es tiempo que se podría dedicar a otra cosa. Si lo hace SAP de forma automática... es lo que se llama planificación con punto de pedido.

El punto de pedido es un nivel de stock configurado en el maestro de materiales a partir del cual SAP genera automáticamente una propuesta de aprovisionamiento. Cuando el stock disponible cae por debajo de ese nivel, el sistema lo detecta durante la siguiente ejecución del MRP o del planning run y crea una solicitud de pedido sin que nadie tenga que intervenir.

El valor del punto de pedido no es arbitrario. Tiene que estar calculado para cubrir el consumo que se va a producir durante el tiempo de reaprovisionamiento, es decir el tiempo que tarda en llegar la mercancía desde que se lanza el pedido hasta que está disponible en el almacén. Si el plazo de entrega de un proveedor es de dos semanas y el consumo medio es de 50 unidades por semana, el punto de pedido debería ser como mínimo 100 unidades más un stock de seguridad adicional para absorber variaciones.

Y aquí está el error más habitual, configurar el punto de pedido una vez durante el proyecto y no revisarlo nunca más. El consumo cambia, los plazos de entrega de los proveedores cambian, la estacionalidad del negocio cambia. Un punto de pedido que tenía sentido cuando se implementó el sistema puede estar completamente desactualizado dos años después, generando roturas de stock o excesos de inventario que nadie relaciona con una parametrización obsoleta.

La cobertura de stock es el concepto complementario. Indica cuántos días de consumo cubre el stock actual y es la forma más visual de entender si el nivel de inventario es adecuado o no. SAP la calcula en los informes de stock y permite configurar alertas cuando la cobertura cae por debajo de un umbral definido.

Hay desarrollos que necesitan comportarse de forma diferente según el entorno en el que se ejecutan. Mostrar un aviso al usuario cuando está en desarrollo, activar un modo debug en QAS, deshabilitar el envío de emails reales en entornos no productivos... La solución habitual es hardcodear el nombre del sistema en una constante o en una tabla Z. Funciona hasta que alguien cambia el nombre del sistema o lo copia a otro entorno y se olvida de actualizar la constante.

GET_SYSTEM_NAME resuelve esto de forma limpia. Devuelve el nombre técnico del sistema SAP en el que se está ejecutando el programa en ese momento, leyéndolo directamente de los parámetros del sistema sin depender de ninguna configuración manual.

Una alternativa igualmente válida y más directa es usar la variable de sistema SY-SYSID, que contiene el mismo valor sin necesidad de llamar a ninguna función. Pero la función es útil cuando necesitas pasarla como parámetro a un módulo o cuando trabajas en un contexto donde la variable de sistema no está directamente accesible.

Hay una conversación que los departamentos de RRHH de media España llevan meses evitando. La que tienen que tener con sus responsables de equipo cuando les expliquen que a partir de ahora los candidatos van a saber el rango salarial antes de sentarse en la entrevista. Y que sus propios empleados van a poder pedir información sobre lo que cobran sus compañeros en puestos similares.

La Directiva Europea 2023/970 de Transparencia Retributiva tenía como fecha límite de transposición el 7 de junio de 2026. España, con su habitual puntualidad, todavía no ha publicado la ley de transposición en el BOE. Pero eso no cambia lo esencial, las obligaciones están definidas, el calendario existe y las empresas que esperaban a tener la norma española en papel antes de moverse se están quedando sin margen de preparación.

¿Qué cambia exactamente? Primero, las ofertas de empleo tendrán que incluir el rango salarial del puesto antes de la primera entrevista. No es opcional ni negociable. El candidato tiene que saber cuánto puede ganar antes de poner un pie en la sala. Segundo, queda prohibido preguntar a los candidatos cuánto cobraban en su trabajo anterior. El objetivo es evitar que una posible desigualdad salarial previa se arrastre al nuevo puesto. Tercero, cualquier empleado podrá solicitar información sobre los salarios medios de quienes realizan el mismo trabajo o un trabajo de igual valor, desglosados por sexo. No el salario individual de otro compañero, pero sí los datos agregados que permitan detectar si hay una diferencia injustificada. Y si esa diferencia supera el 5%, la empresa tendrá que justificarla o corregirla.

¿Qué no cambia? Que si tu empresa tiene la estructura retributiva bien ordenada, los criterios de progresión documentados y los registros actualizados, esta ley no te va a generar ningún trauma. Las empresas que tengan sus datos ordenados van a cumplir con la Directiva sin problema. Las que no, van a improvisar. Y en un contexto donde cualquier empleado puede pedir información salarial en cualquier momento y donde la carga de la prueba recae sobre la empresa, improvisar sale caro.

Para los responsables de equipo en el ecosistema SAP, esto tiene implicaciones muy concretas. La primera es que ya no vas a poder contratar a alguien sin publicar el rango salarial. Lo cual significa que si tienes a alguien del equipo haciendo el mismo trabajo que la persona que acabas de contratar y cobrando menos, esa persona lo va a saber. Probablemente antes de lo que crees.

La segunda es que la conversación sobre compensación que muchos managers han estado evitando durante años se va a volver inevitable. No porque la ley obligue a tenerla directamente, sino porque el contexto que crea hace que el silencio resulte mucho más costoso que la transparencia.

Y la tercera, que es la más incómoda de todas: si en tu equipo hay diferencias salariales que no se sostienen ante un análisis objetivo de responsabilidades y valor aportado, tienes un problema que esta ley va a hacer visible antes o después. Y es mejor que lo resuelvas tú proactivamente que esperar a que un empleado te lo plante encima de la mesa con datos en la mano.

El mayor error que puede cometer un responsable ante esta ley es tratarla como un trámite de RRHH que no va con él. Va con él. Porque las decisiones de compensación de su equipo, los criterios con los que ha gestionado las subidas, las diferencias que ha permitido que se acumulen... todo eso va a tener mucha más visibilidad a partir de ahora. Y conviene llegar a ese momento con las respuestas preparadas, no improvisando en una conversación incómoda un lunes por la mañana. 😏

¿Tu empresa ya ha empezado a prepararse para esto o todavía está en modo "esperemos a ver qué dice la ley española"?

En el mundo de la consultoría SAP esta frase tiene una aplicación muy concreta. Hay consultores que negocian su sueldo partiendo de lo que les cuesta vivir. Y hay consultores que negocian partiendo de lo que generan, de lo que vale su perfil en el mercado y de lo que pagaría otra empresa por ellos mañana.

Los primeros siempre van a salir perdiendo. Porque una empresa no calcula lo que te va a pagar en función de tu hipoteca o tu alquiler. Lo calcula en función de lo que el mercado paga por tu perfil y de cuánto le cuesta encontrar a alguien que haga lo mismo que tú.

La única forma de pedir lo que mereces es saber lo que mereces. Y para eso hace falta información, comparación y una cantidad mínima de incomodidad al tener esa conversación. Que nadie dijo que fuera fácil. Pero tampoco es tan difícil como la mayoría cree antes de intentarlo.

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 👋

Envíame un correo sobre un tema que quieras que salga en la newsletter a [email protected] o contesta a este email.