De la firma en papel a la aprobación digital: un caso real en SAP MM
Una empresa industrial tenía un problema habitual en SAP MM: contratos, solicitudes y pedidos que necesitaban aprobación interna acababan saliendo del sistema para circular por correo o en papel, con todo el retraso y la falta de control que eso implica
Con la implantación del Conector SAP Signaturit de GROUPmee, ese flujo pasó a ser completamente digital y automático.
Índice del boletín
🔍 Dato Curioso
Hoy quiero empezar con un dato curioso que conecta directamente con el tema de este número.
En 1972, cinco ex empleados de IBM fundaron una pequeña empresa en Mannheim, Alemania, sin financiación externa, sin un gran plan de negocio y sin ninguna garantía de que aquello fuera a funcionar. ( Esto ya lo sabemos todos )
Tenían un trabajo de día. Y por las noches y los fines de semana se reunían a escribir el software que con el tiempo se convertiría en el ERP más usado del mundo.
Ellos mismos se autodenominaban "búhos nocturnos". Porque la constancia no llegó con un gran lanzamiento ni con un golpe de suerte. Llegó programando línea a línea, sesión a sesión, durante meses, sin saber todavía si aquello iba a salir bien.
Cuando llevaban dos años y medio en el mercado tenían más de 40 clientes. Hoy, más de cincuenta años después, SAP es la mayor empresa de software de Europa. Y todo empezó con cinco personas constantes, trabajando de noche, sin certezas, solo con la disciplina de seguir apareciendo.
No hubo un golpe de suerte que convirtiera a SAP en lo que es hoy. Hubo cincuenta años de constancia, de pequeñas decisiones acumuladas y de seguir construyendo incluso cuando el resultado no era visible todavía.
Creo que ese dato resume mejor que cualquier discurso lo que quiero contaros hoy.
📰 Ultimas noticias
Hay noticias de IA que se quedan en el comunicado de prensa y noticias de IA con números reales detrás. Esta es de las segundas.
Lemvigh‑Müller, uno de los mayores mayoristas de acero, fontanería, calefacción y material eléctrico de Dinamarca, ha desplegado varios agentes de IA orquestados en un único flujo de trabajo sobre SAP Business AI para automatizar la confirmación de pedidos de proveedores. Una tarea que cualquiera que haya trabajado en compras conoce bien: cuando los proveedores envían confirmaciones de pedido en PDF, hasta una mínima discrepancia en precio, cantidad o fecha de entrega dispara un esfuerzo manual considerable en el departamento de compras.
Lo interesante no es solo el resultado. Es el camino para llegar ahí. El director de IT de la compañía reconoce abiertamente que ya habían probado RPA y automatización tradicional sin conseguir el efecto deseado. La diferencia esta vez fue dividir la tarea en varios agentes de IA independientes, cada uno responsable de una parte específica del proceso.
Tres agentes trabajando en cadena: uno que recibe y clasifica los emails de proveedores, otro que extrae y estructura los datos de los PDF, y un tercero que compara esa información extraída contra los pedidos de compra existentes en SAP para determinar si hay coincidencia o desviación
El dato que más llama la atención: todo el proyecto, desde la idea inicial hasta producción, llevó solo 10 semanas. Y nació, como tantas buenas ideas, de la forma menos protocolaria posible: un project manager hizo una prueba con ChatGPT para hacer matching entre una confirmación de pedido y un pedido de compra, y al ver que funcionaba se lo planteó al director de IT.
¿El impacto? La empresa gestiona unas 175.000 órdenes de compra al año con más de 2.000 proveedores, y alrededor del 60% de las confirmaciones llegan como documentos no estructurados. Con la solución en marcha, esperan liberar recursos equivalentes a entre tres y cuatro empleados a tiempo completo.
Y aquí va la frase que más me ha gustado de toda la noticia, porque desmonta el discurso fácil del "la IA viene a quitar puestos": "El objetivo no es reducir plantilla, sino usar mejor nuestro conocimiento. Los agentes se ocupan de las tareas rutinarias para que los compradores se centren en los casos donde su experiencia realmente importa."
💹 Información en Bolsa
A día de hoy, 29 de junio de 2026, la cotización de SAP se sitúa en 136,70€, con un rango diario entre 136,70€ y 137,90€ y un rango de 52 semanas entre 130,62€ y 269,35€.
La acción sigue moviéndose cerca de sus mínimos anuales. Comparada con la semana anterior la acción ha bajado un 4,19%, un 12,85% en el último mes y un 46,43% en el último año. Datos duros para una compañía que sigue creciendo en ingresos.
¿Qué ha pesado esta semana en concreto? SAP cayó más de un 4% después de que su rival Oracle revelara sus planes de gasto de capital, y también sufrió una caída adicional cuando Goldman Sachs rebajó su precio objetivo. El mercado sigue leyendo cada movimiento de la competencia y cada revisión de analista como una señal sobre el ritmo real del crecimiento cloud de SAP.
Pero hay un matiz que vale la pena destacar: SAP reportó un Q3 sólido, con un crecimiento del 7% interanual en ingresos hasta los 9.100 millones de euros, aunque con señales mixtas en cloud. Los fundamentales no están mal. Lo que el mercado está penalizando es la velocidad, no el destino.
El precio objetivo medio a 12 meses para SAP es de 214€, con una estimación alta de 290€ y una baja de 154,99€. Incluso el escenario más pesimista de los analistas sigue por encima del precio actual de cotización. Y SAP presentará su próximo informe de resultados el 23 de julio de 2026, fecha que va a marcar bastante el sentimiento del mercado para el resto del verano.
Como siempre: esto no es consejo de inversión, soy consultor SAP, no gestor de fondos. 😄
🚀 Mi Opinión
Hoy no vengo a hablar de RISE, de Joule ni de ningún Magic Quadrant. Hace un año le di al botón de publicar por primera vez sin tener ni idea de en qué me estaba metiendo. Hoy es el número 79. Sin fallar ninguno. Y me apetece contaros lo que hay detrás de esa cifra. 😏
Lo único que no ha cambiado en un año donde ha cambiado todo
Hemos pasado de hablar del fin del ECC a hablar de agentes autónomos. De RISE a MCP. De Sapphire a adquisiciones que nadie vio venir. Lo que sabía hace doce meses es la mitad de lo que sé ahora.
Y sin embargo lo único que se ha mantenido exactamente igual ha sido aparecer cada semana. Eso me ha hecho pensar que en este mundo da igual lo rápido que cambie la tecnología, el consultor que se presenta, entrega y sigue aprendiendo sigue siendo relevante aunque SAP le cambie el roadmap entero cada seis meses.
El síndrome del impostor no se cura. Se le ignora con cariño
Voy a confesarlo: ni un solo número de los 79 lo he publicado sin pensar "esta semana no doy la talla". Y aquí va el dato que más me sorprendió por el camino, hablé con consultores con veinte años de carrera y sienten exactamente lo mismo antes de una reunión importante.
Así que no, no se va. Lo que cambia es que dejas de esperar a que se vaya para hacer las cosas. Publicas con la duda dentro. Entras a la reunión con la duda dentro. Y resulta que la duda nunca ha sido un buen indicador de si vas a hacerlo bien o mal.
Las metas pequeñas le ganan siempre a los propósitos enormes
Nunca me planteé "voy a hacer la mejor newsletter SAP en español". Me planteé "esta semana saco un número". Y la siguiente semana, lo mismo otra vez.
79 boletines después, todas esas metas diminutas suman algo que desde aquí parece bastante más grande de lo que cualquiera de ellas aparentaba por separado. Si estás arrancando algo ahora (lo que sea) no mires la cima. Mira solo el siguiente número. Las cosas grandes casi nunca se construyen de un salto.
Salir de la zona de confort no es opcional. Es la cuota de entrada.
Cada semana me ha tocado escribir de algo que no controlaba del todo, o defender una opinión sabiendo que iba a generar debate. Esa incomodidad inicial, con el tiempo, se ha convertido en el motor real de todo lo que he aprendido este año. No he crecido por casualidad. He crecido porque cada boletín me obligaba a salir de lo cómodo.
En SAP pasa lo mismo. El día que decides que ya sabes suficiente es el día exacto en que dejas de crecer.
Gracias, en serio
A quien lee esto desde el número uno. A quien comenta, corrige y a veces me dice "esto no era así, Guille" (y tiene razón). A quien simplemente abre el correo cada semana sin decir nada. Sois la razón de que esto siga teniendo sentido después de 79 entregas.
Este año ha sido aprender a ser constante. El siguiente espero que sea mejor todavía. Y si algo me llevo es que no hace falta saber a dónde vas para empezar a caminar. Solo hace falta seguir presentándote, aunque la voz de dentro diga que no toca esta semana.
Esa voz nunca tiene la última palabra. La tiene la constancia.
🧩 SAP Técnico
Hay un patrón que se repite en integraciones SAP mal diseñadas: algo falla en un iFlow, el sistema externo recibe un "Internal Server Error" sin más contexto, y el equipo de soporte tiene que entrar al monitor de Integration Suite a adivinar qué pasó. Las excepciones no capturadas en scripts Groovy que llaman a servicios externos o parsean entradas no confiables aparecen como errores genéricos de PROCESSING_FAILED, muy difíciles de diagnosticar.
El patrón correcto: capturar y enriquecer el error con contexto del negocio
La técnica que mejor funciona en proyectos reales no es solo capturar la excepción genérica de Java. Es enriquecerla con el dato del negocio que estaba procesando en ese momento. La idea es imprimir el elemento clave del mensaje que provocó el error, para que el equipo de soporte no tenga que abrir el payload completo para saber a qué registro corresponde el fallo.
import com.sap.gateway.ip.core.customdev.util.Message
def Message processData(Message message) {
try {
def body = message.getBody(String) as String
def headers = message.getHeaders()
// Lógica de negocio que puede fallar
def resultado = procesarPedido(body)
message.setBody(resultado)
} catch (Exception e) {
def pedido = message.getHeaders().get('PedidoId') ?: 'desconocido'
def errorEnriquecido = "Fallo procesando el pedido ${pedido}: ${e.message}"
throw new Exception(errorEnriquecido)
}
return message
}Lo que hay que saber sobre cómo se propaga ese error
Aquí viene el matiz técnico más importante y el que más confusión genera. Si tu iFlow termina con un evento de error o escalation, no es posible establecer un mensaje de respuesta personalizado ni un código HTTP personalizado mediante Content Modifier o Groovy script, siempre devuelve 500 con un mensaje estándar.
La única forma de devolver una respuesta de error personalizada de verdad es terminar el subproceso de excepción con un evento de fin de mensaje normal, no con un evento de error. Solo cuando finalizas con un paso de "éxito" puedes establecer una respuesta de error personalizada y un código HTTP personalizado.
Eso es contraintuitivo la primera vez que lo descubres, pero es exactamente cómo funciona Integration Suite. Si quieres que el sistema emisor reciba un mensaje claro tipo "el pedido 4521 no se pudo procesar porque falta el código de cliente", tienes que estructurar tu subproceso de excepción con un Content Modifier seguido de un End Message Event, no con un Error End.
Para integraciones complejas: error handling centralizado
En lugar de duplicar la lógica de manejo de errores en cada iFlow, una buena práctica es centralizar la captura en un subproceso de excepción que envía los detalles del error vía adaptador ProcessDirect a un iFlow dedicado de logging centralizado, reutilizable across múltiples flujos de negocio. Esto evita reescribir la misma lógica de notificación, registro y formato de error en cada integración nueva que construyes.
🧩 SAP Funcional
El indicador de borrado en pedidos de compra: por qué "eliminar" una posición nunca elimina realmente nada
Hay una pregunta que aparece en cualquier proyecto MM más temprano que tarde: un usuario "borra" una posición de un pedido en ME22N... ¿y ese registro desaparece del sistema? La respuesta sorprende a más de un funcional nuevo en el módulo: no, nunca desaparece. Solo se marca.
Lo que pasa realmente al "eliminar" una posición
El campo LOEKZ actúa como indicador de borrado tanto a nivel de cabecera como de posición del pedido, pero su alcance es distinto según el nivel donde se aplique. Cuando un usuario marca una posición para eliminar en ME22N, el sistema no la borra físicamente de la base de datos. Lo que hace es activar este indicador en la posición correspondiente de la tabla EKPO. Eso significa que esa posición concreta ya no debe procesarse más adelante ( no se debe contabilizar entrada de mercancía ni factura contra ella ) pero el resto del pedido puede seguir perfectamente activo
Y aquí está el matiz importante que diferencia un borrado de un bloqueo. SAP distingue entre marcar una posición como eliminada y marcarla simplemente como bloqueada , dos estados distintos con comportamientos distintos, aunque visualmente el icono que ve el usuario en ME23N pueda parecerse. Una posición bloqueada puede desbloquearse y seguir su curso con normalidad. Una posición marcada para eliminación está pensada para quedar fuera del flujo de forma definitiva.
¿Y a nivel de cabecera completa?
El indicador a nivel de cabecera del pedido en la tabla EKKO se usa específicamente durante el proceso de archivado. Primero todas las posiciones reciben el indicador de borrado, y después el pedido se archiva. Es un proceso de varios pasos: primero se escriben los datos en el archivo, y en un paso posterior ese archivo se verifica y los datos se eliminan finalmente de las tablas activas. Hasta entonces, el registro sigue ahí, consultable, aunque ya no operable.
Esto significa que un pedido "eliminado" hace tres años probablemente sigue vivo en tu base de datos productiva, simplemente fuera del flujo operativo normal hasta que pase por el proceso formal de archivado.
Por qué esto importa para informes y conciliaciones
Un pedido se considera totalmente activo y procesable solo si el indicador de cabecera no está marcado Y el indicador específico de esa posición tampoco lo está. Si no filtras correctamente por estos dos campos en un informe o desarrollo custom, vas a contar posiciones que el negocio considera "eliminadas" como si siguieran activas.
Este es uno de los errores más habituales en desarrollos Z de reporting de compras: alguien construye un informe que suma valores de pedidos sin excluir las posiciones marcadas para borrado, y el resultado no cuadra con lo que ve el comprador en pantalla. El comprador ve la posición tachada y fuera de juego. El informe la sigue sumando porque nadie filtró por LOEKZ.
La recomendación práctica para cualquier desarrollo o consulta sobre compras
Antes de construir cualquier reporte o consulta directa sobre tablas de compras, siempre hay que tener en cuenta el indicador de borrado tanto en cabecera como en posición para filtrar correctamente los pedidos activos. Y siempre que sea posible, apoyarse en las transacciones estándar de SAP ( ME23N, ME2L, ME2M ) antes de ir directo a tabla, porque ya gestionan correctamente esta lógica sin que tengas que replicarla a mano.
🔎 Función de la Semana
CL_ABAP_STRING_UTILITIES
la clase pequeña que resuelve problemas de strings que casi nadie sabe que tiene resueltos
Hay una clase estándar de SAP que vive en el catálogo desde hace años y que la mayoría de ABAPers nunca ha abierto en SE24. Y sin embargo resuelve operaciones de strings que mucha gente sigue escribiendo a mano cada vez que las necesita
CL_ABAP_STRING_UTILITIES incluye métodos como C2STR_PRESERVING_BLANKS para copiar campos tipo C conservando los espacios finales, DEL_TRAILING_BLANKS para eliminar espacios al final de un string, y EDIT_DISTANCE para calcular la distancia de edición entre dos cadenas.
El método EDIT_DISTANCE es probablemente el más infravalorado de toda la clase. Calcula cuántas operaciones de inserción, eliminación o sustitución hacen falta para convertir un string en otro. Es exactamente el algoritmo que se usa para detectar errores tipográficos, comparar nombres de cliente escritos de forma ligeramente distinta entre dos sistemas, o construir un buscador con tolerancia a errores sin tener que programar el algoritmo de Levenshtein desde cero.
La compañera de viaje: CL_ABAP_CHAR_UTILITIES
Muy relacionada y que conviene conocer junto a esta. Esta clase ofrece atributos como NEWLINE, HORIZONTAL_TAB y CR_LF que representan caracteres de control y que se pueden usar directamente dentro de string templates.
Muy útil cuando construyes ficheros de texto plano, exportaciones CSV o cualquier salida donde necesitas controlar exactamente los saltos de línea y tabulaciones sin recurrir a caracteres especiales escritos a mano que dependen de la codificación del sistema.
👑 Liderazgo y gestión
La estimación que nadie quiere hacer bien
Hay un momento en cada proyecto SAP que decide gran parte de lo que va a pasar después. Y no es el go-live. Es mucho antes, cuando alguien estima cuánto va a durar y cuánta gente hace falta. Y en la mayoría de los proyectos que he visto ese momento se hace mal, no por falta de capacidad técnica sino por presión comercial, optimismo forzado y miedo a decir la verdad incómoda en una propuesta.
El problema de raíz es que muchas estimaciones no responden a "¿cuánto necesita esto de verdad?" sino a "¿qué número nos hace ganar este contrato frente a la competencia?" Son preguntas distintas, y cuando gana la segunda el proyecto nace con una deuda que alguien va a pagar. Normalmente el equipo, en horas extra que nadie reconoce. O el cliente, cuando llegan retrasos que nadie le explicó desde el principio. Como responsable no tienes que ser el más optimista en la reunión comercial. Tienes que ser el que defiende una estimación realista aunque eso incomode a quien solo quiere cerrar la venta.
Otro error muy típico es coger lo que duró un proyecto parecido y aplicarlo tal cual al nuevo: "el último cliente de este tamaño tardó cuatro meses, este también." Pero cada cliente tiene su propia deuda técnica, su propia madurez de datos, su equipo interno más o menos disponible y su capacidad de tomar decisiones más o menos rápido. Dos clientes "del mismo tamaño" pueden necesitar tiempos completamente distintos según cuánto tarden en aprobar algo o cuánta limpieza de datos arrastren. Estimar bien es preguntar antes de calcular, no al revés.
Y luego está el tema de los recursos, que mucha gente trata como si fueran intercambiables sin más. Una hora de un ABAPER senior resolviendo algo crítico no equivale a dos horas de un junior aprendiendo sobre la marcha, por mucho que la hoja de estimación los meta en la misma celda como "persona-hora". Tu trabajo como líder es defender que el proyecto necesita el perfil correcto en el momento correcto, no simplemente "más gente" cuando algo va mal. Meter cinco juniors en la última semana de un proyecto descarrilado no arregla nada, solo reparte el caos entre más personas.
Lo que sí funciona es el colchón honesto. Una buena estimación no es la que promete el camino perfecto sin imprevistos, sino la que incluye un margen razonable y lo explica con transparencia en vez de esconderlo para que el número quede más bonito. Decirle al cliente "esto puede llevar entre diez y doce semanas según cómo avancen vuestras decisiones" no es debilidad, es profesionalidad. Y un cliente que conoce ese margen desde el principio digiere mucho mejor un pequeño retraso que uno al que le prometiste una fecha cerrada sin ningún respiro.
Al final, una buena estimación no es la que gana el proyecto. Es la que se puede cumplir sin quemar al equipo ni mentir al cliente. Y ahí está tu valor real como líder: no en decir que sí a todo lo que pide la propuesta comercial, sino en poner el número que el proyecto necesita de verdad, aunque cueste defenderlo en la sala.
💬 Frase del Día
No cuentes los días, haz que los días cuenten.
En el mundo SAP esto se traduce de una forma muy concreta. No es la semana en la que el proyecto sale perfecto la que define a un equipo. Es lo que ese equipo hace cuando la semana viene torcida: el ticket que se resuelve aunque sea viernes a las seis, el dato que se valida una vez más aunque ya estés cansado de revisarlo, la llamada al cliente que nadie quería hacer pero que había que hacer.
La diferencia entre un proyecto que funciona y uno que se arrastra no suele estar en los días buenos. Está en lo que se hace en los días que nadie quiere contar.
🙌 Gracias por leer
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.