Índice del boletín
🔍 Dato Curioso
Nadie, absolutamente nadie, se sabe SAP entero. Y los números explican por qué.
Vamos con un dato que pone en perspectiva por qué cada módulo cría su propia especie de consultor. SAP es tan grande que es literalmente imposible que una sola persona lo domine todo. Y no lo digo como frase hecha: lo dicen las cifras.
Entre SAP ECC y S/4HANA hay más de 20 módulos funcionales y técnicos reconocidos (FI, CO, MM, SD, PP, QM, PM, PS, WM/EWM, HR, TM, BW… y la lista sigue), cada uno con su propia lógica, sus propias tablas y su propio universo de Customizing. Y por encima de eso está la capa de transacciones: la cifra que circula en la comunidad habla de más de 100.000 transaction codes en un sistema SAP completo. Cien mil. Que conste que no es un número oficial de SAP, sino una estimación muy repetida entre consultores, pero aunque te quedes con una fracción de esa cifra, el mensaje es el mismo: aquí no cabe un cerebro que lo sepa todo.
Para que te hagas una idea: si dedicaras un minuto a cada transacción sin dormir, sin comer y sin ir al baño, tardarías más de dos meses seguidos solo en abrirlas una vez. Ya ni hablemos de entenderlas.
Por eso SAP no se divide en módulos por capricho organizativo. Se divide porque la mente humana tiene un límite, y ese límite es muy inferior a la superficie total del producto. De ahí que cada consultor acabe cavando su trinchera en una parcela concreta… y desarrollando, de paso, la personalidad que va con ella. Que es justo de lo que va el artículo de hoy
💹 Información en Bolsa
Semana de subidas suaves y de nervios pre-resultados. SAP cotizaba el 12 de octubre en torno a los 193,91 €, con una subida del +1,28% respecto al cierre de Xetra de 191,46 € del día 9. Verde, pero con el freno de mano puesto, porque todo el mundo mira ya al calendario.
El dato que pone las cosas en perspectiva: a pesar de la subida, la acción está todavía un 20,6% por debajo de su máximo de las últimas 52 semanas, que fue de 244,30 €. El mínimo del año anda por los 127,50 €, así que seguimos en ese rango amplísimo que esta acción lleva meses dibujando. Por el lado de los analistas, hay confianza moderada: UBS mantiene un precio objetivo de 201,00 €, ligeramente por encima de la cotización actual.
Y el gran catalizador tiene fecha de examen: los resultados del Q3 2026 se publican el 21 de octubre. A partir de ahí sabremos si el optimismo de las últimas semanas tenía fundamento o era solo ruido pre-resultados. El mercado llega con ganas; veremos si SAP le da la razón.
Traducido al idioma del consultor: hay expectación, hay un objetivo por encima del precio, y hay una fecha marcada en rojo. El 21 se despeja la incógnita.
⚠️ Sección puramente informativa. No constituye consejo de inversión.
Últimas noticias
SAP Security Patch Day de octubre: 22 vulnerabilidades, 4 críticas y una con la nota máxima. Al consultor de Seguridad del artículo de hoy se le acaba de llenar la agenda.
Qué puntería. Justo la semana en que el boletín describe al consultor de Seguridad como “el que todo el mundo necesita pero nadie invita a comer”, SAP publica su Security Patch Day de octubre (13 de octubre de 2026) y le llena la semana de trabajo. Si tienes a uno cerca, hoy no le pidas nada. Está ocupado.
Los números del parche de este mes son serios: 16 notas de seguridad nuevas, más cuatro avisos y dos actualizaciones de notas previas, que en conjunto cubren 22 CVEs. De esos, 4 son críticos. Y uno de ellos se lleva la matrícula de honor del terror: CVE-2026-89111, con un CVSS de 10.0 (el máximo posible), un SSRF en el SAP Cloud SDK for Python explotable por red, sin autenticación y sin interacción del usuario. El combo completo.
Los otros tres críticos tampoco son moco de pavo: un fallo de control de acceso en NetWeaver Visual Composer (9.9), una inyección de código en la funcionalidad de Reglas de Sustitución/Validación de S/4HANA (9.9) — sí, justo las sustituciones y validaciones de FI de las que ya hemos hablado por aquí — y un fallo de autorización en SAP Manufacturing Integration and Intelligence (9.1). La lista de productos afectados es larga: NetWeaver, S/4HANA, Commerce Cloud, el ABAP Platform, Web Dispatcher… casi un recorrido por el catálogo.
La buena noticia: el boletín de SAP indica que no hay explotación activa conocida ni exploits públicos. La mala: eso puede cambiar en cuanto los parches se hagan públicos y alguien los analice al revés. Por eso el patch day no es opcional.
Lo que esto recuerda, más allá de los CVEs, es algo que solemos olvidar: la seguridad en SAP no es una capa que se pone al final. Es un módulo con nombre y apellidos, y cuando no se le hace caso, aparece en los titulares. Hazle caso a tu consultor de Seguridad. Y oye, hoy invítale tú a comer.
🚀 Mi Opinión
La primera parte de esta guía os gustó más de lo que esperaba. Y lo que más me repetisteis fue siempre lo mismo: “¿y el de QM,PM,etc etc dónde está?”. Tenéis razón. SAP es tan enorme (ahí tenéis el Dato Curioso para demostrarlo) que en la primera entrega me dejé fuera a medio ecosistema. Así que hoy toca reparar la deuda. Mismo espíritu, misma broma cariñosa, y recordad, esto está hecho desde el respeto absoluto a todos los módulos… incluso a los que me dan miedo.
Vamos allá.
El de PM (Mantenimiento)
Vive entre avisos, órdenes de mantenimiento y ubicaciones técnicas. Mientras el resto del proyecto habla de ventas y facturación, él te habla de la bomba hidráulica número 47 que lleva tres años dando guerra. Entiende las máquinas mejor que a las personas, y tiene una relación casi sentimental con los planes de mantenimiento preventivo.
Perfil humano: el del PM es el que en su casa tiene documentado cuándo cambió por última vez el filtro de la campana extractora. Lleva un registro. En algún sitio. Y lo consulta.
El de QM (Calidad)
El guardián de que las cosas se hagan bien, no rápido. Habla de lotes de inspección, características de inspección y certificados de calidad con una seriedad litúrgica. Para el resto del proyecto es “el que frena todo”, y para él, el resto del proyecto es “los que quieren saltarse los controles”. Ambos tienen algo de razón.
Perfil humano: el del QM es el que lee las instrucciones del medicamento enteras antes de tomarse una pastilla. Y el que revisa la cuenta del restaurante línea por línea. No por desconfianza. Por principios.
El de PS (Proyectos / Project System)
El que conecte el mundo real de los proyectos con la contabilidad. Vive en un cruce imposible entre estructuras de desglose, grafos de red, hitos de facturación e imputación de costes. Es de los pocos que entiende de verdad cómo se enlaza PS con CO, con MM y con SD a la vez, y por eso suele tener cara de no haber dormido.
Perfil humano: el del PS es el que organiza las vacaciones familiares con un diagrama de Gantt. Con dependencias. Y con una línea base por si alguien se desvía del plan.
El de TM (Transporte)
Optimiza rutas, consolida envíos y calcula costes de flete mientras el resto no sabía ni que ese módulo existía. Habla de unidades de transporte y de etapas como si fuera obvio, y tiene opiniones sorprendentemente intensas sobre la logística de última milla.
Perfil humano: el del TM es el que en un viaje de carretera recalcula la ruta “para ahorrar doce minutos” aunque eso implique tres desvíos y un peaje. El trayecto es el objetivo, no el destino.
El de BW / Analytics (BW/4HANA, SAC, Datasphere)
El que convierte el caos de datos de todos los demás módulos en informes que la dirección sí entiende. Habla de InfoObjects, flujos de datos y modelos de SAC, y sufre en silencio cada vez que un funcional le dice “es que necesito un informito, una cosa sencilla”. No existe el informito sencillo. Nunca ha existido.
Perfil humano: el del BW es el que en una discusión familiar aparece con un gráfico. Literalmente ha hecho un Excel para demostrar que este año toca ir a casa de sus suegros en Navidad. Y los datos no mienten.
El de Integración (CPI / PI-PO / Integration Suite)
El puente entre SAP y el resto del universo. Vive de iFlows, mapeos, certificados y adaptadores, y es el primero en enterarse cuando algo externo deja de responder (normalmente un domingo a las tres de la mañana). Habla de IDocs y de APIs REST en la misma frase sin despeinarse.
Perfil humano: el de Integración es el que en casa tiene todos los dispositivos conectados entre sí, el enchufe inteligente hablando con la bombilla y la bombilla con el altavoz. Cuando funciona, es magia. Cuando falla, no hay cena hasta que lo arregla.
El de BTP (el arquitecto de la nube)
El que llegó a SAP por la puerta nueva y habla un idioma que los veteranos todavía están descifrando: subcuentas, espacios, servicios, Cloud Foundry, Kyma, destinos, CAP, extensiones side-by-side. Mientras unos defienden el Clean Core como una religión, él ya está montando la aplicación fuera del core porque “así no tocamos el estándar”. Mitad desarrollador, mitad arquitecto, mitad comercial de la visión cloud de SAP (sí, son tres mitades, él lo entiende).
Perfil humano: el de BTP es el que tiene cuatro suscripciones de prueba de cuatro plataformas distintas “para ir probando”, una cuenta en todos los servicios cloud habidos y por haber, y una fe casi conmovedora en que esta vez sí, la nube lo va a resolver todo. A veces tiene razón. A veces la factura dice otra cosa.
El de Seguridad y Autorizaciones (roles, perfiles, GRC)
El que decide quién puede hacer qué, y por tanto el que todo el mundo necesita pero nadie invita a comer. Vive de roles, objetos de autorización y segregación de funciones (SoD), y su respuesta por defecto a cualquier petición es un “no” que luego, a regañadientes, se convierte en “déjame ver”. Cuando algo peta por falta de autorización, aparece su nombre. Cuando todo va fino, nadie se acuerda de que existe.
Perfil humano: el de Seguridad es el que en casa tiene contraseñas distintas para cada cosa, doble factor en todo y una cierta desconfianza hacia cualquiera que diga “déjame tu móvil un momento”. No es paranoia. Es profesionalidad.
El de Fiori / UX (el del frontend)
El que se preocupa de que todo esto, después de décadas de pantallas grises, por fin se parezca a una aplicación del siglo XXI. Habla de launchpad, catálogos, grupos, tiles y de “la experiencia de usuario” mientras un ABAP-er de la vieja escuela le mira con sospecha. Es el traductor entre el poder bruto de SAP y la gente que solo quiere un botón que funcione.
Perfil humano: el de Fiori es el que reorganiza los iconos del móvil por color y por frecuencia de uso. El que no soporta una app mal diseñada y te lo va a decir. En voz alta. En mitad del restaurante que acaba de estrenar carta digital.
El de MDG / Datos Maestros
El que ha entendido algo que a los demás nos cuesta aceptar: que la mitad de los problemas de un proyecto SAP no son de proceso, son de datos maestros sucios. Vive peleando por la gobernanza del dato, los flujos de aprobación y que el material 4711 signifique lo mismo en las cinco sociedades. Es el único que se emociona de verdad hablando de calidad del dato.
Perfil humano: el de MDG es el que tiene la agenda de contactos del móvil impecable: sin duplicados, con los apellidos bien puestos y las empresas rellenas. Mientras el resto tenemos tres entradas distintas para el mismo fontanero, él tiene un único registro maestro. Validado.
El de VIM (Vendor Invoice Management)
Técnicamente no es un módulo de SAP, es un add-on de OpenText, pero decidle eso al que se dedica a ello y veréis. El de VIM vive en la tierra de nadie entre MM y FI: automatiza la entrada de facturas de proveedor, el OCR, los flujos de aprobación y el matching contra el pedido. Su día a día es un desfile de facturas que no casan, excepciones y el eterno “esta factura no tiene pedido asociado, ¿qué hago con ella?”.
Perfil humano: el de VIM es el que tiene la bandeja de entrada del correo a cero. A cero. Cada mensaje clasificado, respondido o archivado. Vive para que no se le acumule nada pendiente, y el concepto de “factura atascada” le produce un malestar casi físico.
El de Tesorería (TRM / FSCM / Cash Management)
El que sabe dónde está el dinero en cada momento, cuánto hay y cuándo llega. Habla de posición de liquidez, previsión de tesorería, instrumentos financieros, coberturas y comunicación bancaria con una tranquilidad que asusta, porque maneja cifras con muchos ceros sin inmutarse. Es finanzas, pero el ala de finanzas donde se mueve el dinero de verdad, no solo donde se contabiliza.
Perfil humano: el de Tesorería es el que tiene una hoja con sus finanzas personales proyectadas a cinco años. Sabe exactamente cuánto va a tener ahorrado en marzo de 2029. Y si le preguntas, te lo dice al euro.
El de Administración Pública (PSM / FM / GM)
El que trabaja en un SAP que juega con otras reglas. Mientras el resto del mundo piensa en centros de coste y beneficios, él piensa en presupuesto, fondos, posiciones presupuestarias y disponibilidad. En su universo no puedes gastar lo que no tienes asignado, literalmente el sistema te lo impide, y hay un control de fondos que vigila cada céntimo. Entender la lógica presupuestaria del sector público después de venir del mundo privado es como aprender a conducir por la izquierda.
Perfil humano: el de Administración Pública es el que en una comida de amigos reparte la cuenta según “lo que cada uno había presupuestado para hoy”. Tiene sobres mentales para cada cosa. Y si algo se sale del sobre, no se compra. Hay disponibilidad o no la hay.
El de RE-FX (Inmuebles / Real Estate)
El de un módulo que muchos consultores con años de experiencia no han visto jamás en vivo. Gestiona contratos de arrendamiento, objetos inmobiliarios, condiciones y liquidaciones de gastos con una soltura que al resto nos parece magia negra. Cuando dice que trabaja en SAP y luego explica qué hace exactamente, la cara del interlocutor es un poema: “¿pero eso también lo hace SAP?”. Sí. También.
Perfil humano: el de RE-FX es el que se ha leído entero el contrato de alquiler de su piso. Las cláusulas, los anexos, la letra pequeña y la actualización del IPC. Y conoce sus derechos mejor que su propio casero.
El de GTS (Global Trade Services)
El guardián de que la empresa no acabe en un titular por saltarse una normativa de comercio internacional. Vive de clasificación arancelaria, listas de sanciones, control de exportaciones y gestión aduanera. Es el que frena un envío porque “el destinatario está en una lista que no te conviene”, y aunque nadie le entiende en el momento, todos le agradecen después no haber tenido un problema legal de los gordos.
Perfil humano: el de GTS es el que lee los términos y condiciones antes de aceptar. De verdad. Enteros. Y el que en el aeropuerto sabe exactamente qué puede y qué no puede meter en la maleta, en qué cantidad y por qué.
El de VC / LO-VC (Configuración de Variantes)
El que habita el módulo más esotérico de todo SAP. Características, valores, dependencias, procedimientos… monta productos configurables con una lógica de reglas tan enrevesada que cuando la explica, medio proyecto asiente sin entender nada. Es el único capaz de hacer que un “coche con estas opciones sí, pero estas dos juntas no” funcione en el sistema. Un artista incomprendido.
Perfil humano: el de VC es el que al pedir en la hamburguesería monta una combinación imposible , “sin esto, doble de aquello, el pan del otro menú y la salsa aparte” El lote de inspección no aparece por arte de magia: si no activas el tipo de inspección, no hay nada que inspeccionar
Como hoy el boletín habla del consultor de QM, vamos con el concepto que más quebraderos de cabeza da en ese módulo: por qué a veces el sistema genera un lote de inspección y a veces no, aunque “esté todo configurado”.
El lote de inspección (inspection lot) es el documento que dispara el proceso de control de calidad: cuando entra material, cuando se fabrica, cuando se hace un traslado… QM puede generar un lote para que alguien lo inspeccione. Pero la clave que mucha gente olvida es que el lote no nace solo. Nace porque hay un tipo de inspección (inspection type) activado en la vista de calidad del maestro de materiales, y cada tipo está ligado a un origen de inspección distinto: el 01 para entradas de mercancía de pedido de compra, el 04 para entradas desde producción, el 03 para inspección durante el proceso, el 08 para traslados, y así.
El error clásico, el que vas a ver en el 90% de los “oye, QM no me funciona”: el material no tiene activado el tipo de inspección correspondiente en su maestro. El cliente hace una entrada de mercancía esperando que salte el control de calidad, y no pasa nada. No es que QM esté roto. Es que nadie le dijo a ese material que tenía que inspeccionarse en ese escenario concreto. Sin tipo de inspección activo, no hay lote, y sin lote, no hay control.
Y al final del proceso está la otra pieza que confunde: la decisión de empleo (usage decision, QA11/QA32). Es el momento en que alguien dice “este lote lo acepto / lo rechazo”, y esa decisión es la que mueve el stock (de inspección a libre utilización, a bloqueado, o a devolución). Mientras no haya decisión de empleo, el stock se queda atrapado en “inspección de calidad” y el de MM empieza a preguntar por qué no puede disponer del material. Clásico roce QM-MM.
La recomendación práctica: cuando un cliente te pida “activar la calidad” para unos materiales, lo primero no es tocar QM, es revisar qué tipos de inspección necesitan esos materiales según los escenarios reales (compras, producción, traslados) y activarlos en el maestro. El Customizing de QM puede estar perfecto, pero si el maestro de materiales no lo refleja, no pasa nada de nada.y se indigna sinceramente cuando el sistema de pedidos no le deja. Él lo habría parametrizado mejor.
Con estos ya sí que cubrimos hasta los rincones más oscuros del catálogo. Y aun así, seguro que me dejo alguno. Esto de SAP no se acaba nunca.
🧩 SAP Técnico
El concepto de paquetes: ese tabique que impide que tu código se convierta en un plato de espaguetis (y que el 90% de los proyectos ignora)
Abramos el melón de algo que casi nadie usa bien: los paquetes en ABAP no son carpetas. Lo repito porque duele: no son carpetas. La inmensa mayoría de los equipos los trata como cajones para ordenar objetos por capricho estético (“pongo aquí los programas Z de MM, aquí los de SD”) y se pierden la que es, de verdad, la herramienta de arquitectura más potente y más infrautilizada del Workbench.
Un paquete bien montado es un tabique: define qué puede usar quién. Y eso se consigue con tres piezas que mucha gente ni sabe que existen.
La primera es la jerarquía de paquetes. No todo es un saco plano. Tienes structure packages (el nivel más alto, que dibuja la arquitectura), main packages (que agrupan pero no contienen objetos directamente) y development packages (donde viven de verdad las clases, programas y CDS). Esa estructura no es decorativa: es la que te permite razonar sobre tu aplicación por capas.
La segunda es la interface de paquete (package interface). Por defecto, si marcas un paquete como encapsulado, lo de dentro es privado: nadie de fuera puede usarlo. La interface de paquete es la puerta por la que decides explícitamente qué objetos expones al resto del mundo. Igual que una clase tiene métodos públicos y privados, un paquete bien diseñado expone solo lo que quiere que otros consuman, y esconde la fontanería interna.
La tercera es el acceso de uso (use access). Si tu paquete quiere usar algo de otro, no basta con escribir el nombre de la clase: tu paquete tiene que declarar un acceso de uso contra la interface del paquete proveedor. Es un contrato explícito: “yo, paquete A, declaro que uso lo que el paquete B expone por su puerta”.
¿Y quién vigila que todo esto se respete? El Package Check, hoy integrado en el ATC (ABAP Test Cockpit). Cuando usas un objeto de otro paquete sin tener el acceso de uso, el ATC te lanza un hallazgo muy concreto:
USEM → "Missing use access": tu paquete usa un objeto de otro
paquete pero no has declarado el acceso de uso.
NVIS → "Not visible": el objeto que intentas usar ni siquiera
está expuesto por ninguna interface de paquete. Puerta cerrada.Y aquí está lo bonito: el USEM no se puede silenciar con un pragma ni un pseudocomentario. O arreglas la arquitectura, o el check te sigue chillando. Por una vez, SAP te obliga a hacerlo bien.
El caso de uso real donde esto se vuelve crítico es el Clean Core. Toda la filosofía de S/4HANA de “no toques el estándar, extiende de forma controlada” se apoya precisamente en este concepto: SAP expone APIs liberadas (released) a través de sus interfaces de paquete, y tu código solo debería consumir eso. El concepto de paquetes es, literalmente, el mecanismo técnico que hace cumplir el Clean Core.
El error clásico, el que vas a ver en el 90% de los sistemas: todo en $TMP mientras se desarrolla (objetos locales que nunca se transportan, sorpresa en el go-live), o un único paquete Z gigante con 4.000 objetos donde cualquier programa puede usar cualquier clase de cualquier otro sin ningún control. Eso no es una arquitectura. Es un plato de espaguetis esperando a enfriarse. Y cuando llega el día de separar un módulo, migrar algo a la nube o aislar una funcionalidad, descubres que todo depende de todo y no puedes mover una pieza sin romper diez.
🧩 SAP Funcional
El lote de inspección no aparece por arte de magia: si no activas el tipo de inspección, no hay nada que inspeccionar
Como hoy el boletín habla del consultor de QM, vamos con el concepto que más quebraderos de cabeza da en ese módulo: por qué a veces el sistema genera un lote de inspección y a veces no, aunque “esté todo configurado”.
El lote de inspección (inspection lot) es el documento que dispara el proceso de control de calidad: cuando entra material, cuando se fabrica, cuando se hace un traslado… QM puede generar un lote para que alguien lo inspeccione. Pero la clave que mucha gente olvida es que el lote no nace solo. Nace porque hay un tipo de inspección (inspection type) activado en la vista de calidad del maestro de materiales, y cada tipo está ligado a un origen de inspección distinto: el 01 para entradas de mercancía de pedido de compra, el 04 para entradas desde producción, el 03 para inspección durante el proceso, el 08 para traslados, y así.
El error clásico, el que vas a ver en el 90% de los “oye, QM no me funciona”: el material no tiene activado el tipo de inspección correspondiente en su maestro. El cliente hace una entrada de mercancía esperando que salte el control de calidad, y no pasa nada. No es que QM esté roto. Es que nadie le dijo a ese material que tenía que inspeccionarse en ese escenario concreto. Sin tipo de inspección activo, no hay lote, y sin lote, no hay control.
Y al final del proceso está la otra pieza que confunde: la decisión de empleo (usage decision, QA11/QA32). Es el momento en que alguien dice “este lote lo acepto / lo rechazo”, y esa decisión es la que mueve el stock (de inspección a libre utilización, a bloqueado, o a devolución). Mientras no haya decisión de empleo, el stock se queda atrapado en “inspección de calidad” y el de MM empieza a preguntar por qué no puede disponer del material. Clásico roce QM-MM.
La recomendación práctica: cuando un cliente te pida “activar la calidad” para unos materiales, lo primero no es tocar QM, es revisar qué tipos de inspección necesitan esos materiales según los escenarios reales (compras, producción, traslados) y activarlos en el maestro. El Customizing de QM puede estar perfecto, pero si el maestro de materiales no lo refleja, no pasa nada de nada.
🔎 Función de la Semana
CL_SYSTEM_UUID: deja de inventarte claves únicas con la hora y el usuario, SAP ya tiene su propio generador de UUID
Situación que todos hemos visto: alguien necesita una clave única para algo (un registro de log, un ID de correlación, una tabla sin un número de documento claro) y se monta un invento artesanal concatenando la fecha, la hora, el usuario y un contador. Funciona… hasta que dos procesos caen en el mismo milisegundo y se te duplican las claves en producción. Para eso existe desde hace años la clase CL_SYSTEM_UUID, que genera UUIDs (identificadores universalmente únicos) de verdad.
El uso básico no puede ser más directo:
" UUID en formato raw de 16 bytes (el más compacto para claves)
DATA(lv_uuid_x16) = cl_system_uuid=>create_uuid_x16_static( ).
" UUID en 32 caracteres (sin guiones)
DATA(lv_uuid_c32) = cl_system_uuid=>create_uuid_c32_static( ).
" UUID en 36 caracteres (el clásico con guiones: xxxx-xx-xx-...)
DATA(lv_uuid_c36) = cl_system_uuid=>create_uuid_c36_static( ).Tres formatos según lo que necesites: el x16 (raw de 16 bytes) es el ideal para claves de tabla porque ocupa poco y es el que usa RAP por debajo para las claves de los escenarios managed; el c32 y el c36 son versiones legibles para logs, interfaces o cuando tienes que enseñar el ID a un humano. Los métodos son estáticos, así que ni siquiera necesitas instanciar nada.
¿Dónde lo usas de verdad? En cualquier tabla propia que necesite una clave técnica sin depender de rangos de números; en IDs de correlación para trazar un mensaje a través de varias interfaces; en claves de objetos RAP; en logs de aplicación. Cada vez que te descubras pensando “necesito algo único aquí”, este es tu amigo.
Para quien está en ABAP Cloud / S/4HANA moderno, hay además la vía XCO, aún más limpia:
DATA(lv_uuid) = xco_cp=>uuid( )->value. " UUID de 36 caracteresEl matiz: un UUID es único, pero no es legible ni ordenable de forma natural como un número de documento secuencial. No sustituyas un número de pedido bonito por un churro de 36 caracteres solo porque puedes. Úsalo para claves técnicas internas, no para lo que el usuario tiene que leer o teclear.
👑 Liderazgo y gestión
Si algo deja claro el artículo de hoy es que un equipo de proyecto SAP no es un equipo: son varias subculturas conviviendo bajo el mismo Gantt. Y el error más común del que lidera es tratarlas a todas igual, como si el de Seguridad, el de BTP y el de QM se motivaran, comunicaran y trabajaran de la misma forma. No lo hacen. Y gestionarlas como si fueran intercambiables es la receta para que el proyecto se te llene de silos.
Hay un patrón que se repite en casi todos los proyectos: los módulos “ruidosos” (SD, los que están de cara al negocio, los que presentan en los comités) acaparan la atención y el diseño se construye alrededor de ellos. Mientras tanto, los módulos “silenciosos” (QM, PM, Seguridad, Datos Maestros) se quedan esperando, y cuando por fin levantan la mano ya es tarde: el diseño está cerrado y no encaja con lo que ellos necesitaban. Luego, en producción, revienta justo por ahí. Por donde nadie escuchó a tiempo.
El trabajo de quien lidera no es saber de todos los módulos (eso es imposible, ya lo hemos visto). Es asegurarse de que todas las tribus están en la conversación cuando toca, no después. Y eso se traduce en acciones muy concretas: en el taller de diseño, pregunta explícitamente al de Seguridad y al de Datos Maestros aunque “aún no toque” su parte, porque sus restricciones condicionan el diseño de los demás. Da voz al módulo callado antes de cerrar decisiones, no cuando ya están tomadas. Y traduce: cuando el de Integración dice “el middleware no soporta ese volumen”, tu trabajo es convertir eso en algo que el funcional de SD entienda y le importe.
Hay una acción que puedes implantar esta misma semana: en tu próxima reunión de diseño, haz una ronda rápida y obligatoria donde cada módulo diga una sola frase: “lo que estamos decidiendo aquí me afecta en… / no me afecta”. Treinta segundos por persona. Te sorprendería la de desastres que se evitan solo con dejar que el módulo silencioso diga en voz alta “oye, eso que vais a hacer me rompe a mí”.
El coste de no hacerlo no se ve en el momento. Se ve tres meses después, cuando el módulo al que nadie escuchó se convierte en el cuello de botella del go-live, y entonces ya nadie se acuerda de que tuvo la oportunidad de hablar y no se la dieron.
💬 Frase del Día
Ninguno de nosotros es tan inteligente como todos nosotros juntos
Viene clavada con el tema de hoy. El de MM no entiende a HR, el de BTP habla otro idioma que el de PM, y el de Seguridad le dice que no a todos. Y aun así, cuando esas diez tribus consiguen remar juntas, hacen algo que ninguna podría hacer sola: que un sistema del tamaño de SAP funcione de verdad. Ningún consultor se sabe SAP entero (ahí está el Dato Curioso para recordarlo), pero entre todos, sí. Esa es la gracia.
🙌 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.
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.