¿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 algo que cualquier consultor con experiencia sabe y que pocas veces se dice en voz alta, los key users son los que realmente deciden si un proyecto SAP funciona o no en producción. No los consultores. No el jefe de proyecto. No el sponsor ejecutivo que firma el acta de inicio.

Son el puente entre el negocio y el sistema. El traductor. Los que convierten lo que hace el sistema en algo que el negocio realmente adopta. Sin un buen key user, el consultor más brillante puede implementar SAP a la perfección técnica... y que nadie lo use bien.

Y sin embargo son el perfil al que menos se forma en la planificación del proyecto, al que más se le exige cuando algo falla y al que nadie pregunta cuando el sistema lleva meses en producción y podría estar funcionando mucho mejor.

Curioso, ¿verdad?

La semana pasada Christian Klein, CEO de SAP, hizo una declaración que sacudió a todo el ecosistema tecnológico. En una entrevista para Financial Review dijo exactamente esto: "El desarrollo de software es la función más afectada por la IA, y existe la posibilidad de que en tres o cuatro años ya no haya nadie desarrollando software en SAP."

Treinta mil desarrolladores. Más del 27% de la plantilla total de SAP. Eso es lo que Klein está poniendo encima de la mesa.

Antes de que nadie se lleve las manos a la cabeza hay un matiz importante que conviene leer con calma: SAP no va a despedir a esos empleados, simplemente pasarán a desarrollar otros roles dentro de la empresa para cumplir con las nuevas necesidades. Klein no habla de una oleada de despidos. Habla de una reconversión masiva hacia lo que él llama la Empresa Autónoma. Los gestores de producto que antes apenas programaban pasarán a diseñar agentes de IA junto a expertos de distintos sectores. "Necesitamos gestores de producto que sepan leer el código y entiendan los negocios. Si bien la demanda de desarrolladores baja, necesitamos más científicos de datos."

El concepto detrás de todo esto es el vibe coding: la idea de que cualquier empleado pueda generar software a partir de instrucciones en lenguaje natural sin necesidad de conocimientos técnicos profundos. Klein ve en eso el principio del fin de los programadores tal como los conocemos. El papel del desarrollador ya no estaría vinculado a generar código, sino a supervisarlo.

Suena bien en teoría. Pero los datos de hoy cuentan otra historia. La confianza de los desarrolladores en el código que genera la IA cayó del 40% al 29% en un solo año, y el 45% del código generado contiene fallos de seguridad graves. Klein habla de un futuro sin programadores, pero los números actuales muestran que la supervisión humana sigue siendo la diferencia entre un producto fiable y uno con agujeros.

¿Y qué significa esto para el consultor SAP de a pie? Lo que se está produciendo no es la desaparición de los perfiles técnicos sino una evolución hacia perfiles híbridos capaces de comprender procesos de negocio y supervisar soluciones generadas por IA. Exactamente lo que llevamos meses comentando en este boletín. El que entiende SAP de verdad, no solo el que sabe escribir código, va a seguir siendo necesario. Y probablemente más que nunca.

Buenas noticias y malas noticias esta semana en la cotización de SAP. Las buenas: la acción ha recuperado algo de terreno respecto a las semanas anteriores. Las malas: el punto de partida era tan bajo que tampoco hay mucho que celebrar. 😅

A día de hoy, 7 de julio de 2026, la cotización de SAP en Fráncfort se sitúa en 140,66€, con un rango diario entre 140,65€ y 142,73€ y un rango de 52 semanas entre 130,62€ y 269,35€.

Sí, habéis leído bien. SAP ha llegado a cotizar a 269€ hace menos de un año y ahora está en 140€. Eso es una caída de casi el 48% desde máximos. Para ponerlo en contexto: si hubierais comprado en máximos, ahora tendríais la mitad. Y si hubierais comprado en mínimos hace unas semanas... bueno, todavía tendríais menos de lo que pagasteis igualmente.

¿Qué ha pasado esta semana concretamente? Pues que la declaración de Klein sobre el fin de los programadores no le ha sentado especialmente bien al mercado, que ya venía tocado de semanas anteriores. Las declaraciones del CEO generaron un fuerte debate en la industria y tuvieron repercusión inmediata en los mercados financieros, con desplomes puntuales de hasta un 7% en una sola sesión.

La lógica del mercado es curiosa: SAP anuncia que va a ser más eficiente gracias a la IA, que va a necesitar menos gente para hacer lo mismo... y los inversores se preocupan. Porque si una empresa de software dice que en cuatro años puede que no necesite a sus desarrolladores, la pregunta que Wall Street se hace es: ¿y qué vende exactamente entonces?

El precio objetivo medio a 12 meses que los analistas dan a SAP sigue siendo de 214€, con estimaciones que van desde 154,99€ en el caso más pesimista hasta 290€ en el más optimista. Es decir, los analistas siguen viendo recorrido. Pero los inversores, de momento, prefieren esperar a los resultados del 23 de julio antes de apostar fuerte.

Y como siempre, esto no es consejo de inversión, soy consultor SAP, no gestor de fondos. 😄

Llevas años siendo key user de SAP en tu empresa. Conoces el sistema. Conoces los procesos. Sabes exactamente cómo se hace una factura, un pedido, un cierre de período. Los usuarios te buscan cuando algo no cuadra. El consultor te llama cuando necesita entender cómo funciona el negocio. Y un día te haces una pregunta que nadie te había planteado antes, ¿esto es todo o puedo ir a más?

Es una buena pregunta. Y la respuesta honesta es que puedes ir a mucho más. Pero primero hay que entender exactamente desde dónde sales.

Un key user no es simplemente "el que más sabe de SAP en el departamento". Es el representante de un departamento o proceso, el enlace entre el equipo de implementación y el negocio que representa. En el día a día eso se traduce en validar que lo que el consultor ha configurado funciona como el negocio necesita, formar a los usuarios finales cuando llega el go-live, resolver dudas sin abrir un ticket al soporte externo cada vez y detectar cuando algo no funciona bien aunque técnicamente parezca correcto. Es un rol exigente, con mucha responsabilidad y generalmente poco reconocido. Y tiene una trampa enorme que muy poca gente nombra.

Llevas cinco años haciendo pedidos de ventas en SAP. Sabes hacerlos en tu empresa, con tus clientes, con tus condiciones de precio y tus flujos de aprobación. Pero si mañana cambias de empresa... ¿sabrías hacer un pedido de ventas estándar en SAP desde cero? ¿Entiendes por qué el sistema determina un precio u otro? ¿Sabes qué es una condición de descuento, cómo funciona el intercompany o qué implica que una posición esté bloqueada para entrega?

No es un juicio. Es una realidad estructural del rol. Un key user aprende SAP a través del negocio en el que trabaja. Eso le da un conocimiento muy profundo de ese contexto concreto y muy limitado de todo lo que hay alrededor. El key user de SD que solo hace pedidos y facturas pero nunca ha entendido cómo funciona la determinación de precios, nunca ha visto un flujo de devolución completo o nunca ha comprendido cómo la determinación de cuentas conecta SD con FI... ese key user sabe mucho de su empresa y poco del módulo. Y la diferencia entre los dos es exactamente la diferencia entre quedarte donde estás o poder ir a más.

Antes de pensar en convertirte en consultor, antes de hacer cursos de certificación, antes de actualizar el LinkedIn con nuevas habilidades... amplía tu conocimiento del módulo en el que ya estás. No horizontalmente hacia otros módulos. Verticalmente, hacia la profundidad del tuyo. Si eres key user de SD y solo has tocado pedidos estándar, aprende las devoluciones. Entiende cómo funciona la determinación de precios y qué es una secuencia de acceso. Comprende qué pasa cuando una entrega está incompleta. Todo eso ya lo tienes al alcance de la mano. No necesitas un curso nuevo. Necesitas curiosidad y quizás alguien que te explique lo que hay detrás de lo que ya haces todos los días.

Convertirse en consultor funcional SAP desde un rol de key user es perfectamente posible. De hecho los mejores consultores funcionales que he conocido vienen de haber sido key users durante años, porque entienden el negocio de una forma que alguien que viene directamente de la teoría no puede replicar fácilmente. Pero hay pasos intermedios que nadie dibuja con claridad.

El primero ya lo tienes, dominar tu módulo de verdad, no solo la parte que usas en tu empresa.

El segundo es aprender a pensar en términos de configuración, no solo de uso. La diferencia entre un key user y un consultor no es solo de conocimiento, es de perspectiva. El key user pregunta "¿cómo hago esto?" El consultor pregunta "¿por qué el sistema está diseñado así y cómo se puede cambiar?" Ese cambio no se consigue de golpe. Se trabaja.

El tercero es exponerte a proyectos. Si en tu empresa hay una migración o una nueva implantación de funcionalidad, pide participar no como usuario que valida sino como alguien que quiere entender qué está haciendo el consultor y por qué.

El cuarto es la documentación y la comunicación, porque un consultor tiene que saber explicar cosas complejas de forma sencilla y facilitar reuniones donde el cliente no sabe exactamente lo que quiere.

Y el quinto(opcional), donde la mayoría se precipita , es la certificación. Útil sí, necesaria en algún momento sí, pero no es el primer paso. Es la consecuencia de haber construido una base sólida, no el atajo para construirla.

Si te reconoces en lo que he descrito, llevas años en SAP, conoces tu empresa mejor que nadie pero sientes que hay un techo invisible que no sabes cómo superar, la buena noticia es que ese techo no existe. Existe una brecha de conocimiento que se puede cerrar de forma sistemática si sabes dónde mirar. Empieza por hacerte una pregunta honesta: ¿entiendo mi módulo o entiendo cómo lo usa mi empresa? Si la respuesta es la segunda, ya sabes cuál es el primer paso.

¿Eres key user o lo has sido? ¿Qué fue lo que más te costó entender cuando intentaste profundizar más allá de lo que usabas en el día a día?

Me encantaría leer vuestras historias.

Hay una característica de ABAP moderno que existe desde la versión 7.40 y que prácticamente nadie usa porque nadie la explica bien. Se llama MESH y resuelve un problema muy concreto, navegar entre tablas internas que tienen una relación entre sí sin tener que hacer bucles de búsqueda manuales.

La idea es simple. Defines un tipo MESH que agrupa varias tablas internas y declara las asociaciones entre ellas, como si fuera un modelo de datos miniatura en memoria. A partir de ahí puedes navegar entre las tablas usando esas asociaciones directamente en el código, igual que navegarías por una vista de base de datos.

Sin LOOP AT. Sin READ TABLE por cada posición. Sin lógica de búsqueda manual. Las posiciones del pedido se obtienen directamente navegando por la asociación definida.

Cuándo tiene sentido usarlo: cuando tienes dos o más tablas internas relacionadas y necesitas navegar entre ellas de forma repetida a lo largo del programa. Si solo vas a hacer una búsqueda puntual, un simple READ TABLE es más que suficiente. Pero si tienes lógica que recorre pedidos y necesita acceder a sus posiciones constantemente, MESH elimina un nivel entero de complejidad.

Hay una configuración en SD que se ignora en muchos proyectos y que luego genera una de las quejas más habituales en el post go-live: el cliente confirma una fecha de entrega que el sistema calcula automáticamente... y el pedido llega tarde. Siempre. Sin excepción. Y nadie sabe por qué.

La respuesta casi siempre está en la ruta de expedición o en su ausencia.

La ruta de expedición es la combinación de todos los medios de transporte necesarios para entregar la mercancía desde el centro de expedición hasta el destinatario. En SAP, a partir de esa ruta el sistema calcula automáticamente los plazos de tránsito y los añade al cálculo de disponibilidad para determinar cuándo puede comprometerse una entrega al cliente. Sin esa ruta configurada correctamente, el sistema no tiene ni idea de cuánto tarda realmente la mercancía en llegar y calcula fechas que suenan bien en pantalla pero no tienen ninguna relación con la realidad logística.

La determinación automática de rutas en SAP usa cuatro factores: el país y la zona de transporte del punto de expedición, el país y la zona de transporte de la dirección de entrega del cliente, las condiciones de expedición del cliente y el grupo de mercancías de la posición del pedido. Si cualquiera de esos cuatro factores no está correctamente configurado, la ruta no se determina o se determina mal y los plazos de tránsito que calcula el sistema no corresponden a la operativa real.

El error clásico en proyectos es configurar los materiales y los clientes pero olvidar completamente la tabla de determinación de rutas o rellenarla con plazos de tránsito genéricos que no reflejan la realidad de cada zona. Un cliente en Canarias no tiene el mismo plazo que uno en Madrid. Y el sistema no lo sabe si nadie se lo ha dicho.

Hay un problema pequeño pero recurrente en desarrollos de reporting y formularios: necesitas mostrar el nombre de un mes en formato texto. Enero, febrero, marzo... o January, February, March si el usuario tiene el sistema en inglés. Y la solución habitual es un CASE con doce líneas hardcodeando los nombres en un idioma concreto que luego resulta que no es el que necesita el cliente de otro país.

MONTH_NAMES_GET devuelve los nombres de todos los meses del año en el idioma que tú le indiques, usando las traducciones que ya tiene el sistema SAP internamente. Sin hardcodear nada. Sin tablas Z de traducción. Sin condicionales por idioma.

El resultado son doce líneas con el número del mes, el nombre largo y el nombre corto, todo en el idioma que hayas pasado como parámetro. Si pasas SY-LANGU obtienes automáticamente el idioma del usuario que está ejecutando el programa en ese momento.

Muy útil en formularios Smart Forms o Adobe Forms que se generan en el idioma del cliente, en informes con cabeceras de fecha legibles y en cualquier desarrollo donde necesites presentar fechas de forma amigable para el usuario final.

En los proyectos SAP hay una dinámica que se repite demasiado y que merece nombrarse. El key user brillante que lleva años haciendo su trabajo de forma excelente, que todo el mundo da por descontado, que resuelve problemas sin que nadie se los asigne y que nunca ha recibido una conversación honesta sobre hacia dónde puede ir desde ahí.

Ese perfil es uno de los activos más valiosos que puede tener un equipo. Y también uno de los que más se desperdician. No porque nadie lo valore, sino porque el sistema tiene un incentivo perverso, cuanto mejor hace su trabajo actual, más imprescindible parece donde está y menos urgente parece moverle. Y la conversación sobre desarrollo profesional en proyectos SAP casi siempre ocurre demasiado tarde, cuando el key user ya ha decidido que busca algo diferente en otro sitio.

Tu trabajo como líder no es solo extraer el valor que ese key user aporta hoy. Es ayudarle a ver el camino que puede seguir desde ahí. No tienes que ser su mentor de forma formal ni montarle un plan de carrera de veinte páginas. A veces es tan sencillo como hacerle las preguntas correctas, ¿sabes que lo que haces tiene un nombre en el mercado y que hay demanda para ello? ¿Has pensado en profundizar en la parte del módulo que todavía no conoces bien? ¿Te gustaría participar en el próximo proyecto de implementación desde otro ángulo?

Esas preguntas, en el momento correcto, pueden cambiar completamente la trayectoria de alguien. Y cuestan exactamente cero euros y quince minutos de una conversación honesta.

El key user que crece contigo vale infinitamente más que el que se va a buscar ese crecimiento en otro sitio. Y generalmente se va porque nadie le preguntó a tiempo.

En el contexto de este boletín esta frase no podría ser más oportuna. Klein acaba de decir que el perfil de desarrollador tal como lo conocemos va a cambiar radicalmente. El mercado SAP lleva meses pidiendo perfiles que combinen negocio con tecnología. Y los key users de los que hablábamos antes se preguntan cómo dar el siguiente paso.

La respuesta a todo eso está en esta frase. No se trata de saber más de lo mismo. Se trata de estar dispuesto a soltar lo que ya sabes para aprender lo que viene, sin drama y sin nostalgia. El consultor que hace eso tiene futuro garantizado en este ecosistema pase lo que pase con los agentes de IA. El que se aferra a lo que ya domina porque "siempre ha funcionado"... ya sabemos cómo acaba esa historia.

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.