Hay un estudio de 2025 (WalkMe, State of Digital Adoption Survey, más de 3.500 trabajadores del conocimiento en todo el mundo) que mide algo muy parecido a lo que cuenta el barómetro de Malt y ACISAP, pero fuera del mundo SAP. El 78% de los empleados usa herramientas de IA sin pasar por la aprobación de TI. El 58% accede a ellas desde dispositivos o cuentas personales, para quedar fuera del radar de la empresa. Y aquí está la parte que de verdad sorprende. Si la empresa prohibiera esas herramientas mañana mismo, un 46% dice que seguiría usándolas igual.

No es rebeldía porque sí. Es que la alternativa oficial, cuando existe, suele pedir más fricción de la que la gente está dispuesta a asumir para un trabajo que, al final, tiene que salir sí o sí. Suena familiar, ¿verdad? Es el mismo patrón que el 92% y el 13% del barómetro SAP. La gente no rechaza la herramienta corporativa porque desconfíe de ella. La rodea porque le pide más de lo que le da.

Lo curioso, y lo un poco incómodo, es que esto no es un problema de generación ni de cultura de empresa. Es un problema de diseño. Cuando una política dice "no" sin ofrecer un "sí" razonable al lado, la gente no deja de hacer el trabajo. Deja de contarte cómo lo hace.

Cada año, antes de que arranque SAP TechEd, SAP monta Devtoberfest, un mes de celebración abierta para developers que mezcla sesiones en directo, retos de código y comunidad, todo sin coste. La edición 2026 ya tiene calendario publicado en developers.sap.com, aunque el sitio bloquea el acceso automatizado a esa página, así que lo mejor es entrar tú mismo a mirar fechas y sesiones con detalle.

Lo que sí se mantiene edición tras edición es el formato, y con eso ya puedes hacerte una idea de qué esperar. Cada día de la semana tiene un tema fijo. Lunes va de ABAP y CAP, martes de SAP Build (low-code y no-code), miércoles de integración, jueves de datos, analítica e IA, y viernes de frontend. No son charlas de una hora sentado escuchando, son sesiones cortas pensadas para ir al grano, con ejercicios que puedes seguir en tu propio sistema de pruebas mientras avanzas.

Para participar no hace falta pagar nada ni pedir permiso a nadie. Solo hay que unirse al grupo de Devtoberfest dentro de SAP Community, desde donde se accede a las sesiones en directo y a las grabaciones para quien no llegue a tiempo. Como añadido, SAP suele repartir puntos por participar y sortear algún premio entre quienes completan más actividades, aunque lo que de verdad merece la pena es la excusa para ponerte al día antes de que llegue TechEd.

Lo que no aparece explícito en la web es que Devtoberfest funciona, en la práctica, como el repaso gratuito del año de hacia dónde va SAP. Si vas a ir a TechEd, o simplemente quieres saber qué está empujando SAP este año sin pagar un curso, es la vía más barata de enterarte de primera mano y en formato corto.

¿Le vas a dedicar aunque sea un rato a la semana este octubre, o se te va a quedar en la lista de "ya lo veré luego"?

La acción de SAP cerró el 14 de agosto en 180,14 euros, con una subida del 2,71% en el día. Suena bien hasta que miras el resto del año, porque sigue un 24% por debajo de donde estaba hace doce meses, y el máximo de las últimas 52 semanas (244,30 euros) queda ya bastante lejos en el retrovisor. El mínimo del año se quedó en 127,50 euros, así que tampoco hay que dramatizar del todo.

Lo que explica buena parte del bajón de 2026 no es que el negocio vaya mal. Los ingresos de nube crecieron un 26% interanual y el flujo de caja libre del año pasado rondó los 8.200 millones de euros. Lo que no gustó al mercado fue que el crecimiento del backlog de nube a corto plazo se frenó al 25%, por debajo de lo que esperaban los analistas, aunque el backlog total siga subiendo un 30% hasta los 77.000 millones. En bolsa a veces se castiga más la desaceleración de la desaceleración que el resultado en sí.

Los analistas, de momento, no han perdido la fe. El precio objetivo medio de 28 casas de análisis está en 203,22 euros, con 24 recomendaciones de compra por solo 4 de mantener y ninguna de venta. Si se cumpliera, sería un recorrido al alza de casi el 13% desde el precio actual.

La próxima cita importante es el informe del tercer trimestre, que si sigue el patrón de otros años debería llegar sobre mediados de octubre, aunque SAP todavía no ha confirmado fecha exacta.

Sección puramente informativa. No constituye consejo de inversión 😁

Todos hemos pasado por esto. Terminas el desarrollo (un report, un módulo de funciones, un RAP business object). Funciona, pasa pruebas, el cliente lo valida. Y entonces llega la parte que nadie quiere, la especificación técnica que el cliente espera como entregable. Abres Word. Copias el bloque de selección. Escribes "el programa recorre la tabla interna y…". Vuelves al código porque no recuerdas si eran catorce includes o doce. Referencias las líneas a mano. Ajustas la plantilla del cliente, que nunca es la misma que la del anterior. Una o dos horas por objeto que, si trabajas por tu cuenta, normalmente no facturas.

No es una queja nueva (ya circulaba algo parecido hace más de diez años), pero ahora tenemos IA de por medio. Según el VII Barómetro SAP de Malt con ACISAP (2025, muestra de España), el 92% de los consultores SAP quiere formarse en IA, mientras que solo el 13% usa la que ofrece SAP. Son cosas distintas (una es intención, la otra es uso de un producto concreto), pero apuntan al mismo sitio, y esa distancia merece que nos paremos a pensarla, porque no se explica por falta de interés. Ya lo comenté yo mismo hace unas semanas, hablando del freelance SAP. La gente quiere IA y la está usando, solo que por su cuenta y con herramientas genéricas. ChatGPT, Copilot, Claude.

Y no es desconfianza, son tres fricciones distintas. La primera es conectar al sistema. Casi toda herramienta seria pide acceso al SAP del cliente (RFC, credenciales) o al repositorio de código, y en un proyecto real eso significa permisos, comité y, con frecuencia, un no de seguridad. La herramienta no se rechaza porque sea mala. Se rechaza por lo que pide. La segunda es la confidencialidad. Pegar el código en un asistente genérico choca con la realidad contractual, porque en la mayoría de los NDA de proyecto SAP el código a medida es del cliente y no puede salir hacia un tercero que lo retenga o lo use para entrenar. Mucha gente lo hace igual. Pocos lo dirían en voz alta. Y la tercera es no fiarte del resultado. Un modelo generalista no conoce la estructura de un WRICEF, de un RAP business object ni de un iFlow, y rellena los huecos con prosa que suena impecable y a veces está sencillamente inventada. Firmar eso como entregable técnico es un riesgo que asumes tú, no el modelo.

Las dos primeras son fricciones de compras y de legal, y no las voy a resolver yo escribiendo esto. La tercera es la única que es un problema de ingeniería, así que es de la que me toca hablar.

Esto es lo que a mí me ha acabado funcionando. Una especificación técnica solo sirve si puedes fiarte de cada afirmación que contiene, así que cada afirmación lleva una referencia al objeto y la línea exacta que la respalda. El ancla cambia según el artefacto. En un report o una clase vale un número de línea. En un programa con varios includes hace falta una referencia cualificada, tipo OBJETO:línea, porque un número suelto no dice nada cuando la lógica está repartida entre un main y catorce includes. Y en iFlow o Fiori/UI5 no hay un fichero lineal al que apuntar, así que el ancla es el paso del proceso, el canal, la vista, el controlador.

Lo que hace el trabajo de verdad no es generar esas anclas, es validarlas. Primero se construye el catálogo de referencias legítimas a partir del fuente, y luego se comprueba que cada referencia que suelta el modelo existe en ese catálogo. Si apunta a algo que no está, se rechaza. No se publica con una nota al pie. También rechazo la salida que reproduce el fuente literalmente. Un modelo que copia código en vez de describirlo ha dejado de documentar. Y esto cambia la revisión de verdad. Antes leía la prosa y decidía si me la creía. Ahora salto a la línea citada y lo confirmo. Lo primero escala mal y erosiona la confianza en silencio. Lo segundo es rápido.

Para probarlo usé un caso real, ZBR_MAKT_UPDATE, un report ABAP open source con licencia MIT, de Richard Bäck. 1.081 líneas repartidas en 14 includes. Documentarlo a mano se lleva buena parte de una tarde, y lo tedioso no es escribir la prosa. Es resolver qué include contiene el programa principal, trazar el grafo de includes, deducir el rol de cada uno (TOP, forms, PBO, PAI, pantalla de selección) y mantener las referencias correctas mientras escribes. Eso es trabajo determinista, para un parser, no para una persona ni para un modelo de lenguaje. Se resuelve el grafo primero, se le entrega al modelo un fuente numerado y etiquetado, y se le restringe a referenciar solo lo que el resolver ya encontró. El modelo describe. La estructura y las referencias las pone el programa.

Lo que más subestimé es que el paisaje es mixto. Un cliente en S/4HANA y BTP no es solo ABAP clásico. Hay RAP, hay Cloud Integration, hay Fiori/UI5, y cada uno necesita un resolver distinto y un modelo de anclas distinto. Un prompt genérico para todos produce una salida muy segura de sí misma y sin ninguna estructura real detrás. El conocimiento del dominio es la parte difícil. Llamar a la IA es la parte fácil.

Tengo curiosidad por saber cómo lo estáis resolviendo los demás, porque sospecho que la mayoría no lo tenéis resuelto. ¿Cuántas horas al mes se os van en documentar, y las facturáis? Y si habéis probado IA para esto, ¿qué os frenó, la conexión al sistema, el NDA o no fiaros del resultado?

Os dejo al final una herramienta que ha creado Adrián, espero que os guste

Hay un momento en casi todo proyecto MM donde el cliente pide algo del tipo "que no se pueda grabar el pedido si falta este dato" o "que este campo se rellene solo según el proveedor". La respuesta rápida suele ser meter la validación donde se pueda, muchas veces en un user-exit clásico. El problema es que eso cubre ME21N pero se olvida de que el mismo pedido se puede crear o cambiar por BAPI, y ahí la validación no salta.

ME_PROCESS_PO_CUST resuelve justo eso. Implementa la interfaz IF_EX_ME_PROCESS_PO_CUST, y afecta por igual a las transacciones ME21N, ME22N, ME23N y ME29N y a las APIs BAPI_PO_CREATE1 y BAPI_PO_CHANGE. Como corre en el mismo sitio del framework independientemente del canal que se use para tocar el pedido, la validación es consistente se cree el pedido desde pantalla o desde una interfaz.

Los métodos que más se usan en la práctica son PROCESS_HEADER para validar datos de cabecera, PROCESS_ITEM para las líneas, PROCESS_SCHEDULE para las fechas de entrega, y PROCESS_ACCOUNT para la asignación contable. CHECK se dispara justo antes de grabar y es donde suele ir la validación final que bloquea el guardado si algo no cuadra, mientras que POST se ejecuta después de grabar, útil para procesar algo propio una vez el documento ya existe.

No viene activo por defecto, hay que crear la implementación en SE18/SE19 y pide manejo real de ABAP orientado a objetos, no es un user-exit de rellenar cuatro líneas. Pero a cambio cubre el pedido completo, sin agujeros según por dónde entre el dato.

Un cliente lleva años pagando puntual, y de repente un pedido en VA01 se queda bloqueado por crédito. El equipo comercial se enfada, alguien dice "el crédito está mal configurado" y nadie sabe explicar por qué, porque en teoría OVA8 "ya estaba bien".

El origen casi siempre está en confundir el chequeo estático con el dinámico, o en dejar mal calibrado el horizonte del segundo. El chequeo estático compara la exposición total (pedidos abiertos, más entregas abiertas, más facturas pendientes de cobro) contra el límite de crédito, sin distinguir antigüedad. Es simple, pero puede castigar a un cliente cuya deuda ya está prácticamente resuelta solo porque el documento sigue técnicamente abierto en el sistema. El chequeo dinámico añade un horizonte de revisión, un periodo configurable (típico 60 días) fuera del cual las partidas dejan de contar para la exposición. Un cliente con buen historial de pago sale mejor parado con dinámico, porque la deuda antigua ya liquidada no pesa contra él.

El error clásico en proyectos es aplicar el mismo tipo de chequeo a todas las categorías de riesgo por igual, cuando el sentido de tener categorías es precisamente distinguir a quién le exiges un control más estricto. Y dentro del dinámico, el fallo más habitual es dejar el horizonte con un valor por defecto que no tiene nada que ver con el ciclo de pago real del cliente, así que sigue bloqueando pedidos que, dado cómo paga ese cliente en la práctica, no deberían bloquearse nunca. En OVA8 basta con un checkbox mal marcado para dejar un pedido grande parado varios días sin que nadie entienda por qué.

La recomendación real es revisar el horizonte según el ciclo de pago de cada categoría de riesgo, no dejar el mismo número para todas, y repasar esas categorías con cierta periodicidad según el comportamiento de pago real, no solo en el alta del cliente.

Convierte un valor del formato externo, el que escribe o ve el usuario, al formato interno con ceros a la izquierda que SAP guarda realmente en la tabla. Su contraria, CONVERSION_EXIT_ALPHA_OUTPUT, hace justo lo inverso, quita esos ceros para mostrar el dato legible. El ejemplo clásico es un proveedor con código "300014" que internamente se guarda como "0000300014".

Se usa en cualquier campo cuyo dominio lleve asignado el conversion exit ALPHA, lo típico son número de proveedor (LIFNR), número de material y código de centro, aunque no es exclusivo de esos tres. Antes de dar por hecho que aplica a un campo concreto, merece la pena mirar el dominio en SE11, porque no todos los campos numéricos lo llevan.

El caso de uso real más habitual es cuando comparas o buscas un valor que viene de fuera, un fichero, una pantalla de selección, una llamada externa, contra una tabla estándar. Si comparas el valor tal cual, sin pasar por ALPHA_INPUT antes, la comparación falla en silencio porque el formato no coincide, aunque a simple vista el número "sea el mismo". Es el motivo por el que alguien hace un SELECT que debería devolver un registro y le devuelve la tabla vacía sin ningún error que lo explique.

Lo contrario también falla en silencio. Sacar un valor de la tabla y mostrarlo directamente sin pasar por ALPHA_OUTPUT hace que el usuario vea "0000300014" en pantalla en vez de "300014", y hay reports enteros ahí fuera con esa pinta porque a nadie se le ocurrió mirarlo antes de pasar a producción.

En casi todos los equipos que he visto hay el mismo patrón. Dos o tres personas ya usan IA para casi todo, sin hacer ruido. El resto ni siquiera sabe muy bien qué se puede hacer con ella más allá de pedirle que resuma un correo. Y como responsable de proyecto ahí tienes un problema silencioso, la mitad del equipo trabaja con una herramienta más y la otra mitad sigue haciéndolo todo a mano, sin que nadie se lo haya explicado nunca de verdad.

Lo que a mí me funciona no es mandar un enlace a un curso ni un mensaje de "probad la IA cuando podáis". Eso no cambia nada. Lo que cambia algo es enseñar, en directo, un caso real resuelto delante del equipo. Coger un problema que todos reconocen (documentar un objeto, montar un caso de prueba, resumir un log de errores) y hacerlo con IA mientras miran, con lo que tengáis a mano, desde Joule o los asistentes que ya trae SAP hasta ChatGPT, Copilot o Claude para lo que no es específico de SAP. Ver cómo se hace de verdad convence mucho más que cualquier charla sobre el potencial de la IA.

Hay que ser honesto con dos cosas. La primera es que esto lleva tiempo que nadie te ha reservado en el plan del proyecto, así que toca robarlo de alguna reunión que ya exista, no esperar a que aparezca una nueva. La segunda es que como líder no tienes que saberlo todo. Enseñar también es preguntar en voz alta "esto lo he probado así, ¿alguien ha encontrado algo mejor?", porque seguramente alguien de tu equipo ya ha resuelto algo parecido por su cuenta y nunca te lo ha contado.

El tip resumido es este.: La gente no adopta una herramienta porque se lo digas, la adopta cuando ve a alguien de confianza resolver con ella un problema que reconoce como propio.

Y es lo mismo que pasa con la IA, no aprendes a usarla bien leyendo un manual a solas, aprendes viendo cómo la usa alguien de tu equipo en un problema real. La comunidad SAP lleva años demostrando que ir acompañado sigue siendo la vía más rápida, aunque al principio parezca la más lenta.

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. De hecho, esta semana hemos visto un ejemplo muy concreto con Dokcraft — Generador de especificaciones técnicas SAP, la herramienta que Adrián Quintanilla ( consultor ABAP en Monterrey (México) y desarrolla Dokcraft ) ha creado para facilitar la creación de documentación técnica.

Tambeien teneis el Linkedin de Adrian: https://www.linkedin.com/in/adrianquintanillam/

Os dejo también el contacto para la herramienta Dokcraft: [email protected]

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.