Hay un número que cuando lo dices en voz alta produce una reacción muy concreta en cualquier consultor SAP: reconocimiento mezclado con algo parecido al orgullo. SAP tiene aproximadamente 425.000 clientes en todo el mundo en 2026. Y más del 90% de las empresas de la lista Fortune 500 usan soluciones SAP para gestionar sus procesos de negocio clave.

Pero los datos globales no son lo que más me llama la atención. Lo que más me llama la atención es lo cerca que está SAP de cualquier actividad normal de un día cualquiera en España.

Mercadona, la cadena de supermercados más grande de España, usa SAP para gestionar su cadena de suministro, su logística y su gestión financiera. Repsol usa SAP para gestionar sus operaciones de refinería, su red de gasolineras y su contabilidad. El Corte Inglés, Inditex, Telefónica, BBVA, Iberdrola, Renfe... la lista de empresas españolas con SAP como columna vertebral de sus operaciones es prácticamente un listado de las empresas con las que cualquier ciudadano interactúa a lo largo de una semana normal.

Y aquí está el dato que más me gusta de todos: se estima que SAP gestiona el 87% de las transacciones comerciales totales del mundo. No de las transacciones de sus clientes. Del mundo entero. Cada vez que pagas en un supermercado, cada vez que llenas el depósito, cada vez que reservas un vuelo o recibes un paquete... la probabilidad de que SAP esté procesando algo en algún punto de esa cadena es altísima.

Lo cual significa que tú, consultor SAP que estás leyendo esto, eres parcialmente responsable de que el mundo funcione como funciona. Aunque no lo parezca cuando estás debuggeando un dump un miércoles por la tarde.

En 1996 casi 1.000 profesionales obtuvieron la primera certificación SAP de la historia. Eran exámenes sobre SAP R/3, se hacían en centros de formación físicos y el badge era literalmente un papel. Treinta años después, SAP acaba de publicar un artículo celebrando ese aniversario que en realidad esconde un cambio mucho más relevante que la efeméride en sí.

El cambio es este: SAP está abandonando el modelo de examen de preguntas de opción múltiple para pasar a evaluaciones basadas en rendimiento real. Los candidatos navegan por desafíos reales en sistemas SAP en vivo. Y aquí viene el detalle que más me llama la atención: pueden usar herramientas de IA durante el examen por diseño, no como excepción.

Eso cambia completamente lo que mide una certificación SAP. Ya no mide si sabes la respuesta correcta de memoria. Mide si sabes resolver un problema real con las herramientas disponibles, incluyendo la IA. Que es exactamente lo que se hace en los proyectos reales desde hace tiempo.

Lo que no dice el comunicado pero se deduce claramente es que esto también hace el fraude más difícil. Memorizar respuestas de un brain dump no te sirve de nada cuando el examen te pone delante de un sistema real con un problema concreto que tienes que resolver.

El otro dato relevante: SAP se compromete a certificar a 12 millones de personas en habilidades de IA para 2030. Las certificaciones son una de las vías principales para conseguirlo. Y con el nuevo modelo de evaluación práctica, esas certificaciones van a decir algo más concreto sobre lo que sabe hacer un profesional.

¿Vale la pena certificarse con el nuevo modelo? Si el examen mide lo que dices que sabes hacer... la respuesta depende de si realmente sabes hacerlo.

Semana de consolidación para SAP en bolsa. A 12 de septiembre de 2026, la cotización de SAP en Fráncfort se sitúa en 189,88€, prácticamente sin variación respecto a la semana anterior con un rango diario entre 181,14€ y 190,80€ y un rango de 52 semanas entre 127,50€ y 244,30€.

Después del sprint de recuperación de las últimas semanas, la acción parece haber encontrado un nivel de espera cómodo alrededor de los 190€. El mercado no tiene grandes catalizadores esta semana y todos los ojos están puestos en el 21 de octubre, fecha en que SAP presenta los resultados del Q3.

Lo que sí hay de interesante esta semana viene de Morningstar, que sigue manteniendo a SAP entre las compañías europeas que cotizan con descuento significativo respecto a su valor razonable estimado. Y los indicadores técnicos siguen sugiriendo compra fuerte según el consenso de analistas.

El precio objetivo medio a 12 meses es de 207,19€, con estimación alta de 290€ y estimación baja de 130€ según las fuentes más recientes. Desde los 127,50€ de mínimos hasta los 190€ actuales hay una recuperación del 49% en pocas semanas. Desde los 244€ de máximos anuales todavía queda un 22% por recuperar.

El 21 de octubre va a ser el día más importante para la acción en lo que queda de año. Si los resultados del Q3 confirman la aceleración del cloud que el mercado quiere ver... igual los 244€ dejan de parecer tan lejanos. O igual no. Eso es la bolsa.

⚠️ Sección puramente informativa. No constituye consejo de inversión. Soy consultor SAP, no gestor de fondos.

Hay un momento en la carrera de todo consultor SAP que es difícil de describir a alguien de fuera. Un momento en que algo hace clic en tu cabeza y el mundo deja de ser el mismo.

No es el primer go-live. No es la primera vez que resuelves un problema complicado. Es el día en que estás haciendo la compra en el Mercadona, miras la caja registradora y piensas: "esto tiene SAP por debajo."

Y a partir de ese momento ya no puedes parar.

Pagas la gasolina en la Repsol. SAP. Recibes un paquete de Amazon. SAP en algún punto de la cadena logística. Coges el AVE. Renfe tiene SAP. Pagas la factura de la luz. Iberdrola tiene SAP. Vas al médico. Muchos hospitales públicos tienen SAP. Compras ropa en Zara. Inditex tiene SAP. El banco donde tienes la cuenta. SAP.

Hay una tarde entera de un día normal de cualquier persona en España donde prácticamente cada transacción, cada servicio, cada producto que consume ha pasado en algún momento por un sistema SAP. Sin que esa persona lo sepa. Sin que tenga por qué saberlo. Simplemente funciona. Y funciona porque hay equipos de consultores que han pasado meses configurando, testeando y parchando para que ese momento en la caja del supermercado sea tan aburrido y tan sin drama como tiene que ser.

Y entonces llegas a casa y te pones a jugar al juego más absurdo y más adictivo que existe para un consultor SAP: adivinar qué NO tiene SAP.

El bar de la esquina. Probablemente no. Aunque si tiene una cadena de suministro con varios proveedores y más de una decena de empleados... igual sí. El fontanero que vino a arreglar la caldera. No. La empresa de fontanería para la que trabaja ese fontanero si tiene veinte empleados o más... igual sí. La frutería del mercado. No. La cooperativa agrícola que le suministra la fruta... hay muchas posibilidades de que sí.

El juego es más difícil de lo que parece. Porque SAP no solo está en las grandes multinacionales. SAP Business One lleva años siendo la opción de las pymes. SAP S/4HANA está en empresas medianas que hace diez años no habrían podido permitírselo. Y con el cloud y los modelos de suscripción la barrera de entrada ha bajado considerablemente.

Hay algo que me parece especialmente significativo de esta situación y que muy pocas veces se dice en voz alta en el ecosistema SAP. El trabajo de un consultor SAP no es abstracto. No es código que vive en un servidor y nadie ve. Es infraestructura invisible de la vida cotidiana. Cuando configuras bien un proceso de pedido de compra en una empresa de distribución alimentaria, estás contribuyendo a que haya producto en las estanterías del supermercado donde compra tu familia. Cuando implementas bien la gestión de almacén en una empresa logística, estás contribuyendo a que los paquetes lleguen a tiempo. Cuando montas bien la contabilidad de una empresa de energía, estás contribuyendo a que las facturas de la luz sean correctas y lleguen cuando tienen que llegar.

Eso tiene más impacto real en la vida de las personas de lo que la mayoría de los consultores SAP reconoce. No porque sea glamuroso ni porque salga en ningún titular. Sino porque la infraestructura invisible que hace que las cosas funcionen sin que nadie piense en ella es exactamente el tipo de trabajo más valioso que existe.

La próxima vez que estés en la caja del Mercadona esperando a que el sistema procese el pago... recuérdalo. Alguien configuró eso. Alguien lo testeó. Alguien lo mantuvo funcionando. Y hay muchas probabilidades de que ese alguien tenga un perfil muy parecido al tuyo.

Hay una situación que aparece en casi todos los proyectos de integración modernos: necesitas llamar a un servicio externo desde ABAP. Puede ser una API de BTP, un servicio de terceros o cualquier endpoint REST que requiera autenticación. Y la solución clásica de hardcodear la URL y las credenciales en el código es exactamente lo que no hay que hacer.

La forma correcta en S/4HANA es usar un destino SM59 de tipo HTTP como punto de configuración centralizado, y desde el código ABAP usar CL_HTTP_CLIENT para crear el cliente HTTP apuntando a ese destino.

La ventaja de este patrón es que la URL, el puerto, la autenticación y los certificados SSL viven en la configuración del destino SM59, no en el código. Si cambia el endpoint de producción, lo cambias en SM59 sin tocar ni transportar nada de ABAP.

Para autenticación OAuth con BTP, el destino SM59 se configura con tipo de logon OAuth en la pestaña Logon & Security, y en la transacción OA2C_CONFIG se mantiene el cliente OAuth con el token endpoint, el client_id y el client_secret. El sistema gestiona automáticamente la obtención y renovación del token sin que tengas que implementar esa lógica en el código.

Para entornos ABAP Cloud la aproximación cambia ligeramente: hay que usar CL_HTTP_CLIENT_MANAGER como API released, y CL_OUTBOUND_PROVIDER_HTTP como wrapper para el destino SM59, ya que CL_OUTBOUND_PROVIDER_HTTP no está released directamente para ABAP Cloud y necesita una clase envolvente.

Hay una decisión de diseño en proyectos con módulo CO que parece menor al principio y que luego genera confusión en el cierre mensual: si la orden interna va a ser real o estadística. Los dos conceptos existen desde hace décadas en SAP pero en talleres de diseño rara vez se explican con la claridad que merecen.

Una orden interna es un objeto de controlling que actúa como colector temporal de costes para una tarea, proyecto o actividad específica. La idea es separar esos costes del flujo habitual del centro de coste, monitorizarlos de forma independiente y liquidarlos al receptor final cuando la tarea termina. Hasta ahí todo claro.

El matiz que marca la diferencia es el indicador de orden estadística. Una orden real recibe el coste de forma auténtica. Cuando se imputa un coste a esa orden, el coste vive en la orden y no en el centro de coste. Al liquidar la orden, ese coste se mueve al receptor que definas en la regla de liquidación: un centro de coste, un activo fijo, un elemento WBS o un segmento de rentabilidad en CO-PA.

Una orden estadística, en cambio, recibe el coste de forma paralela al centro de coste que tienes asignado en la imputación. El coste real sigue viviendo en el centro de coste. La orden estadística solo acumula una copia del coste para que puedas reportarlo de forma separada. Y aquí está el punto crítico: las órdenes estadísticas no se pueden liquidar. No tienen receptor. No transfieren costes. Solo sirven para reporting y seguimiento.

El error clásico en proyectos es crear una orden estadística cuando el cliente necesita liquidar esos costes a un activo fijo o a CO-PA al cierre del período. El funcionario de controlling ejecuta KO88 o KO8G para liquidar y el sistema no hace nada porque la orden es estadística y no hay nada que liquidar. Y entonces empieza la conversación difícil sobre por qué la orden no se diseñó correctamente desde el principio.

La regla práctica es sencilla: si necesitas que los costes se muevan al cierre — a un activo, a un centro de coste diferente, a CO-PA — la orden tiene que ser real. Si solo necesitas visibilidad y reporting adicional sin mover costes, la orden estadística es suficiente.

La ruta de configuración del tipo de orden y su indicador estadístico va por SPRO: Controlling → Controlling de costes generales → Órdenes internas → Funciones básicas → Tipos de orden → Definir tipos de orden (KOT2_OPA).

Hay una situación muy habitual en desarrollos ABAP propios: necesitas generar identificadores únicos para tus registros. Y la solución más habitual que veo en código legacy es una tabla Z con un contador que se incrementa manualmente, con su propio LOCK y su propio riesgo de colisión en entornos multiusuario.

SAP tiene esto resuelto de forma nativa desde siempre con los rangos de numeración y la función NUMBER_GET_NEXT.

El proceso tiene dos partes. Primero creas el objeto de rango de numeración en la transacción SNRO: le das un nombre, defines el intervalo de números (del 0000000001 al 9999999999 por ejemplo) y configuras si el buffer está activo y cuántos números se pre-asignan en memoria. Segundo, en tu código ABAP llamas a NUMBER_GET_NEXT para obtener el siguiente número disponible:

El sistema gestiona automáticamente la concurrencia. No tienes que preocuparte por bloqueos, por colisiones entre usuarios o por qué pasa si dos procesos piden el número al mismo tiempo. El mecanismo de buffer de SAP gestiona todo eso de forma transparente.

Hay dos matices importantes que conviene conocer antes de usarla. El primero: si el buffer está activo, los números se pre-asignan en memoria y en caso de rollback o error esos números se pierden. Es el comportamiento esperado y documentado, no un fallo. El segundo: el parámetro NR_RANGE_NR es el identificador del intervalo dentro del objeto, no el propio objeto. En SNRO cuando defines los intervalos aparece una columna "No." con valor típicamente "01". Ese valor es el que va en NR_RANGE_NR.

Hay algo que los responsables de equipo en proyectos SAP hacen poco y que tiene un impacto desproporcionado en la motivación de las personas: conectar el trabajo técnico del día a día con el impacto real que tiene en la vida de personas concretas.

Es muy fácil perderse en los tickets, en los transportes, en los dumps y en los go-lives y perder de vista por qué todo eso importa. Un ABAPER que lleva semanas depurando un proceso de facturación puede no tener claro que ese proceso de facturación afecta a cientos de proveedores que cobran gracias a que ese proceso funciona bien. Un funcional que configura la gestión de almacén puede no tener claro que esa configuración determina si los productos llegan a tiempo a las tiendas o no.

Esa conexión no es obvia. Y en la mayoría de los equipos nadie la hace explícita porque se da por supuesta. Pero no lo es. Y cuando alguien la hace explícita, cuando un responsable dedica cinco minutos de una reunión a explicar "lo que estamos construyendo esta semana va a afectar a X personas de esta forma concreta"... el efecto en la motivación del equipo es inmediato y real.

Esto es especialmente importante en los momentos más duros del proyecto. En las semanas previas al go-live cuando todo el mundo está agotado y nadie recuerda muy bien por qué empezaron. En los períodos de mantenimiento donde los tickets se acumulan y el trabajo parece repetitivo. En los momentos donde la presión del cliente hace que el equipo pierda perspectiva de lo que está consiguiendo.

El consultor que sabe que su trabajo tiene impacto real en la vida de personas reales trabaja diferente al que cree que está configurando transacciones en un sistema que solo ve el cliente. No trabaja más horas. Trabaja con más criterio. Con más cuidado. Con más orgullo profesional.

Y el responsable que sabe crear esa conexión entre el trabajo técnico y el impacto real tiene un equipo mucho más resiliente que el que solo gestiona tareas y plazos.

La próxima vez que tu equipo esté en un momento difícil, antes de hablar de plazos y de recursos... explícales qué va a pasar en el mundo real cuando lo que están construyendo funcione. Quién lo va a usar. Cómo va a cambiar su día a día. Por qué importa que salga bien.

Eso no arregla los problemas técnicos. Pero sí cambia la disposición con la que el equipo va a resolverlos.

Perfecta para la semana en que SAP celebra 30 años de certificaciones y anuncia que los nuevos exámenes se hacen en sistemas reales resolviendo problemas reales.

Franklin lo explicó hace siglos y SAP acaba de aplicarlo a sus certificaciones en 2026. Memorizar respuestas para un examen de opción múltiple te hace pasar el examen. Resolver un problema real en un sistema real te hace consultor. La diferencia entre los dos siempre ha estado ahí. Por fin el examen también la mide.

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.

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.