Existe un test de personalidad laboral que se llama DISC — también conocido como "el test de los colores" — y que muchos departamentos de RRHH usan en procesos de selección, dinámicas de equipo y desarrollo de liderazgo. La idea es clasificar los patrones de comportamiento en cuatro colores, y cada color tiene su propia forma de ver el mundo, de trabajar y de volverse loco a los demás en una reunión.

🔴 Rojo (Dominancia). Resultados, acción, decisiones rápidas. El rojo quiere ir al grano, no le interesa el proceso si puede saltárselo, y su frase favorita en cualquier reunión es "¿y cuándo está?" Lideran proyectos, empujan equipos... y a veces atropellan a la gente sin darse cuenta.

🟡 Amarillo (Influencia). El más social de los cuatro. Le encanta trabajar con gente, convencer, conectar. Brillante en presentaciones y horriblemente impuntual con los entregables. Su superpoder es que todo el mundo le cae bien. Su kryptonita es quedarse sin foco a los diez minutos de empezar una tarea larga.

🟢 Verde (Estabilidad). Leal, metódico, fiable. El verde es el que lleva el mismo proceso durante diez años porque funciona, gracias. No le gusta el cambio por el cambio, prefiere hacerlo bien que hacerlo rápido, y es la persona en la que más confías cuando hay que entregar algo con calidad real.

🔵 Azul (Cumplimiento). Analítico, preciso, orientado al detalle. El azul necesita los datos antes de opinar. Pregunta el porqué de todo. Es el que detecta el fallo en el documento que nadie más había leído. Y sí, a veces se queda paralizado analizando opciones cuando ya habría que haber decidido hace dos días.

Lo interesante del modelo es que nadie es un solo color — todos tenemos los cuatro en distintas proporciones, y esa combinación es la que define cómo te comportas bajo presión, cómo tomas decisiones y cómo te relacionas con tu equipo.

Yo, por ejemplo, soy principalmente azul y verde , análisis y método, por encima de todo. Luego tengo buena dosis de rojo cuando hay que empujar y entregar. Y algo de amarillo cuando me pongo a escribir esto cada semana y me doy cuenta de que me gusta bastante que la gente lo lea.

Poco que contar esta semana, y a veces eso también es una noticia. SAP cerraba la sesión del lunes 28 de septiembre en torno a los 184,78 € en Xetra, con una caída suave del 0,60% en el día. Si lo comparas con los 184,83 € de hace justo una semana, la conclusión es clara, la acción no se ha movido prácticamente nada. Plana. En modo ahorro de energía.

Y tiene su lógica. Estamos en esa fase rara del calendario en la que el mercado ya ha descontado casi todo lo que había que descontar y espera el siguiente catalizador de verdad, que llega el 21 de octubre con los resultados del Q3 2026. Hasta entonces, movimientos laterales y poco entusiasmo.

El rango de las últimas 52 semanas sigue siendo amplio ,entre los ~127 € de mínimo y los ~244 € de máximo , lo que recuerda que esta acción sabe moverse cuando quiere, aunque esta semana haya decidido tomarse un respiro. En el consenso de analistas la cosa sigue en tono optimista, recomendación mayoritaria de compra (16 analistas, rating "Buy" según S&P Global) y precios objetivo claramente por encima de la cotización actual.

Traducido al idioma del consultor, los que analizan estas cosas siguen pensando que la nube y el backlog de SAP dan para más. Pero como siempre, entre el PowerPoint del analista y lo que hace la acción en octubre puede haber un mundo. El 21 salimos de dudas.

⚠️ Sección puramente informativa. No constituye consejo de inversión.

Esta semana no traigo un comunicado de prensa de SAP con lenguaje de departamento de marketing. Traigo algo mucho mejor, un proyecto hecho por uno de los nuestros. Se llama SAP // TRIVIAL, lo ha construido alguien que firma como "Consultor en Sentido Común" ( creo que todos sabemos quien es jajajaja ) y es exactamente lo que suena, un juego de preguntas tipo test para poner a prueba lo que de verdad sabes de SAP.

El funcionamiento es sencillo y adictivo. Eliges un módulo, te lanza 10 preguntas aleatorias, y a partir de ahí es entre tú y tu ego. Puedes moverte adelante y atrás entre preguntas, pero no cambiar de módulo a mitad de partida , nada de escaquearse de FI corriendo a ABAP cuando la cosa se pone fea. Al final te cuenta aciertos, fallos, mejor racha y tiempo. Y sí, hay un ranking top 10 por módulo, porque no hay nada que motive más a un consultor que ver su nombre por encima del de otro.

Lo que le da valor es la cobertura, 13 categorías que van desde los clásicos FI, MM, SD y HR hasta BTP, BW, PM, QM, WM, ABAP, Fiori y hasta Joule. O sea, cubre tanto al funcional de toda la vida como al que está metido de lleno en la parte cloud y de IA. Hay para todos.

Y aquí va lo que me parece más interesante, más allá del juego en sí, esto es un ejemplo perfecto de lo que ya se puede hacer cuando un consultor con conocimiento de negocio se sienta con una IA y decide construir algo.

No un proyecto de empresa, no un presupuesto aprobado por tres comités. Un rato, una idea, y una herramienta que funciona y que le sirve a la comunidad. Que es justamente hacia donde va esto.

Yo ya lo he probado. No diré mi resultado en HR. Dejémoslo ahí.

Échale un vistazo y mídete. Es gratis, es rápido, y te va a decir con bastante honestidad en qué módulos vas sobrado y en cuáles llevas años diciendo que "controlas".

Voy a hacer algo que nadie se atreve a hacer en una consultoría SAP, decir en voz alto lo que todos pensamos cuando nos presentan a un consultor nuevo y nos dicen en qué módulo está especializado.

Que conste que esto es una broma. Una broma muy documentada basada en años de observación de campo, pero una broma. Y que lo de RRHH va con todo el cariño del mundo, aunque ese módulo y yo tengamos una relación... complicada.

El de MM (Gestión de Materiales)

Habla de proveedores, órdenes de compra y MRP como si fueran lo más emocionante del mundo. Tiene una opinión muy formada sobre la diferencia entre un pedido abierto y un contrato marco, y si le das la oportunidad te la explica. Entera. En el descanso del café.

Si le preguntas por algo de FI te mira con la misma cara que pone un gato cuando escucha un ruido raro. Muy fiable. Muy metódico. Un punto obsesionado con el stock de seguridad hasta el punto de que en su casa personal seguramente tiene un armario lleno de papel de cocina "por si acaso."

Perfil humano, el del MM es el que llega puntual a todas las reuniones, tiene los correos organizados en carpetas, y nunca, nunca, se le olvida hacer seguimiento. Lo odias un poco por eso.

El de SD (Ventas y Distribución)

Cercano, comunicativo, siempre con una historia de cliente. Le encanta hablar de "la experiencia del cliente final" y de cómo la ruta de expedición impacta al margen. Tiene energía de comercial aunque sea consultor técnico-funcional, y sabe perfectamente cómo vender su propio trabajo dentro del proyecto.

El problema es que cuando hay que configurar algo en FI para cerrar el ciclo de facturación, de repente tiene una llamada urgente. Y cuando hay que documentar la integración SD-FI, también. Y cuando hay que revisar los casos de prueba de FI, curiosamente está en otra reunión.

Perfil humano, el del SD es el más simpático de la sala, el que propone el plan del viernes por la noche, el que conoce al camarero por su nombre. Y el que en las retrospectivas del proyecto siempre tiene una anécdota que hace reír a todo el mundo y distrae de que todavía hay tres puntos abiertos de su módulo.

El de FI (Finanzas)

Serio. Muy serio. Tiene una hoja de Excel para todo, incluso para las cosas para las que no necesita Excel. Cuando hay un descuadre en el libro mayor se activa un modo detective que no para hasta encontrar el apunte incorrecto aunque esté enterrado en cuarenta documentos de compensación de hace tres meses.

Es el que en el taller de diseño pregunta "¿y eso genera un documento contable?" a absolutamente todo lo que se propone. Todo. La configuración de un almacén. La parametrización de una ruta. La definición de un campo Z. Todo genera un documento contable, aparentemente.

Perfil humano, el del FI es el que en una cena de equipo calcula mentalmente cuánto le toca pagar a cada uno antes de que llegue la cuenta. Lo hace sin que le pidan. Lo hace bien. Y lo hace con una expresión que indica que no entiende por qué los demás no lo hacen igual.

El de CO (Controlling)

El primo analítico de FI, pero con menos apego emocional al apunte contable y más fascinación por los informes. Habla de centros de coste, órdenes internas y KE30 con una fluidez que intimida. Si le preguntas algo de CO-PA, bloquea tu agenda porque esto va para largo.

No siempre tiene razón, pero siempre tiene datos. Y cuando presenta esos datos, los presenta con tres decimales aunque no hagan falta. La precisión no es para él una virtud, es un estado natural.

Perfil humano, el del CO es el que en una conversación informal sobre cualquier tema acaba sacando una estadística. "¿Que si la peli estuvo bien? Pues mira, el 73% de las reseñas en Rotten Tomatoes dicen que sí, aunque si ponderamos por el score de los críticos especializados..." Y así. Así todo.

El de PP (Producción)

Vive en un mundo propio con su propio idioma. Habla de puestos de trabajo, operaciones, versiones de fabricación y centros de trabajo como si el resto de mortales supiéramos de qué va. Su mayor trauma existencial es un MRP que propone órdenes que no tienen ningún sentido, y puede hablar de ese trauma durante semanas.

Completamente perdido si le pides que configure algo en SD. No es que no quiera , es que literalmente no encuentra la relación entre lo que le estás pidiendo y su modelo mental de cómo funciona el mundo.

Perfil humano, el del PP es el que tiene el escritorio perfectamente organizado por procesos. No por tema, no por proyecto, por procesos. Hay una lógica ahí dentro que solo él entiende y que, curiosamente, funciona a la perfección. Es el tipo de persona que cuando monta muebles de Ikea, lee el manual de principio a fin antes de sacar ninguna pieza de la caja.

El de WM / EWM (Almacén)

El más subestimado de todos, con diferencia. Todo el mundo piensa que almacén es fácil hasta que llegan las estrategias de entrada y salida, los tipos de almacén, las órdenes de transferencia, los inventarios y la integración con MM y PP. Entonces llaman al de WM con cara de "oye, ¿puedes echar un vistazo?" y él aparece, soluciona todo en dos horas, y se va sin hacer ruido.

Es el fontanero de SAP. Cuando las cañerías funcionan, nadie piensa en él. Cuando hay una inundación, es el primero al que llaman.

Perfil humano, el del WM no necesita reconocimiento porque ya sabe lo que vale. Es el más tranquilo de la sala, el que no entra en debates de ego, el que cuando alguien dice "esto es imposible" simplemente abre el sistema y lo resuelve. Tiene una paciencia inquietante. Probablemente porque lleva años siendo subestimado y ya le da igual.

El de Basis

No configura módulos. Configura el sistema en el que los demás configuran módulos, lo cual le da un punto de superioridad moral que ejerce con mucha discreción... o no tanta, dependiendo del día y de cuántas veces le hayan pedido lo mismo en la última semana.

Cuando hay un problema de rendimiento en producción, todo el mundo le llama desesperado. Cuando todo va bien, nadie sabe que existe. Es el árbitro de fútbol de la consultoría, solo te acuerdas de él cuando algo sale mal.

Perfil humano, el de Basis tiene siempre la respuesta de "eso es un tema de infraestructura" lista para cualquier problema, sea de infraestructura o no. Es el más probable de todos de usar Linux en casa por elección propia. Y el más probable de tener una opinión muy formada sobre configuraciones de red que nadie le ha preguntado.

El de ABAP

Mi gente. Somos los que llegamos cuando "eso no se puede hacer en estándar" y lo hacemos igualmente, aunque a veces deberíamos haber configurado antes de ponernos a programar. Escribimos funciones de módulo que siguen corriendo diez años después porque nadie se atreve a tocarlas. Y sí, alguna la escribimos nosotros mismos y ya no recordamos exactamente por qué hace lo que hace, pero funciona, y con eso es suficiente.

Tenemos una relación amor-odio con el Clean Core que todavía estamos procesando.

Perfil humano, el ABAP-er es el que en una conversación sobre cualquier problema, ya sea técnico, logístico o de recursos humanos, piensa automáticamente en cómo lo automatizaría. "Sí, sí, entiendo lo que me estás diciendo, pero ¿y si hacemos un programa que..." No. A veces la solución no es un programa. A veces. Pocas.

El de HR / HCM / SuccessFactors

Y llegamos aquí. Y aquí me toca hacer lo mismo que hice con todos los demás, que es describir la personalidad con honestidad aunque me cueste.

El consultor de HR es, sin exagerar, una persona con una paciencia extraordinaria. Porque gestiona nóminas, infotipos, evaluaciones de desempeño, estructura organizativa, vacaciones, bajas, contrataciones y desvinculaciones... y lo hace en un módulo que tiene su propia lógica paralela que no comparte absolutamente nada con el resto de SAP. Es como si alguien hubiera diseñado HCM en otro edificio, en otro país, en otro siglo, y luego lo hubieran enchufado al sistema estándar con un adaptador de dudosa calidad.

Encima trata con el departamento de RRHH del cliente, que tiene sus propios procesos, sus propias excepciones, sus propios convenios colectivos y su propia idea de cómo deberían funcionar las cosas. Si MM es complicado, HR es MM más gestión de personas más legislación laboral más infotipos que no entiendes de dónde salen.

Perfil humano, el del HR tiene una empatía natural que el resto de módulos no necesita. Habla con todo el mundo, entiende los procesos de negocio desde el punto de vista humano, y tiene una capacidad para navegar la política interna del cliente que al ABAP-er le resulta directamente sobrenatural. Es el más diplomático de la sala, el que nunca se pone nervioso en una reunión tensa y el que siempre sabe exactamente qué decir cuando hay un conflicto.

¿Qué yo no entiendo su módulo? Completamente cierto. ¿Qué eso dice más de mí que de él? Probablemente también.

La realidad es que cada módulo tiene su propia cultura, su propio vocabulario y su propia forma de ver los proyectos. Y la magia (y el caos) de SAP es que todos esos mundos tienen que convivir en el mismo sistema. Lo cual explica por qué los proyectos son como son.

Todo consultor técnico llega tarde o temprano al mundo de los formularios. Y la evolución es conocida, primero fue SAPScript (que Dios lo tenga en su gloria), luego SmartForms, y desde hace años el estándar para formularios nuevos es SAP Interactive Forms by Adobe, o Adobe Forms para los amigos. PDFs bonitos, con layout profesional, rellenables si hace falta. Todo genial. Hasta que descubres la otra mitad de la ecuación.

Un Adobe Form tiene dos piezas que se construyen en la transacción SFP (Form Builder), una Interface (que define los datos que entran al formulario) y el Form propiamente dicho (el layout, diseñado con Adobe LiveCycle Designer). Cuando activas el formulario, SAP genera automáticamente un módulo de función por debajo. Y ese es el que llamas desde tu programa de impresión.

El patrón de llamada es siempre el mismo cuarteto,

Fíjate en un detalle que es puro oficio, nunca hardcodees el nombre del módulo de función generado. Ese nombre puede cambiar entre sistemas (desarrollo, calidad, producción) porque se regenera al transportar. Por eso siempre se obtiene en runtime con FP_FUNCTION_MODULE_NAME. El que hardcodea el /1BCDWB/SM000... de turno acaba con un dump en producción y una tarde muy larga.

Y ahora el verdadero protagonista, ADS (Adobe Document Services). Es el motor que renderiza el PDF, y no vive en tu stack ABAP. Tradicionalmente corría sobre un stack Java (AS Java) aparte; en S/4HANA on-premise existe la opción de ADS local, y en la nube tienes ADS como servicio en BTP. El formulario puede estar perfecto, tu programa impecable, y aun así no imprimir nada porque la conexión con ADS no está configurada o el destino RFC ADS está caído. El 90% de las incidencias de Adobe Forms en un proyecto nuevo no son del formulario, son de infraestructura de ADS. Avisado quedas.

Este es de esos conceptos que separan al funcional que "sabe hacer clics en SPRO" del que de verdad entiende cómo fluye un documento en SAP. Y es de los que más silenciosamente rompen un proyecto cuando están mal configurados.

El Copy Control (control de copia) es lo que gobierna cómo un documento de ventas se convierte en el siguiente de la cadena, la oferta en pedido, el pedido en entrega, la entrega en factura. Se configura en transacciones como VTAA (pedido a pedido), VTLA (pedido a entrega) y VTFL (entrega a factura). Y cada una define qué datos se copian, cómo y bajo qué condiciones.

Lo que casi nadie mira con detenimiento son las rutinas de copia (copying requirements) y las rutinas de transferencia de datos. Son pequeños programas VOFM que se ejecutan en el momento de la copia y deciden cosas críticas, si se permite o no copiar, qué cantidad pasa al documento siguiente, cómo se actualiza el flujo de documentos.

El error clásico, alguien crea un tipo de pedido Z copiando uno estándar, se olvida de configurar el Copy Control para ese nuevo tipo, y de repente los usuarios no pueden crear la entrega. "Es que SAP no me deja." No es que SAP no te deje — es que no le has dicho a SAP que ese pedido Z puede convertirse en entrega. El sistema hace exactamente lo que le configuraste, nada.

Otro clásico más sutil, la rutina de copia a nivel de posición controla la cantidad. Si eliges la rutina equivocada, puedes acabar facturando cantidades que no se han entregado, o duplicando cantidades en facturas parciales. Y ese descuadre no lo ves en el momento — lo ves tres semanas después cuando el cliente reclama.

La recomendación de oro, cada vez que creas un tipo de documento Z en SD, revisa siempre su Copy Control desde y hacia los documentos con los que se relaciona. No lo des por hecho aunque hayas copiado de un estándar, porque el copiado del Customizing no siempre arrastra bien todas las asignaciones.

Situación clásica, estás montando un report con una pantalla de selección, y hay un parámetro que necesita una ayuda de búsqueda (el F4 de toda la vida) con valores que solo existen en tu lógica. No hay una search help estándar que valga, y crear una en el diccionario (SE11) para algo que solo usa este programa es matar moscas a cañonazos. La mayoría de la gente, ante esto, o se resigna a no poner F4, o se monta un search help object que luego nadie vuelve a tocar.

Hay una forma mucho más elegante, F4IF_INT_TABLE_VALUE_REQUEST. Le pasas una tabla interna con tus valores y él te monta el popup de ayuda de búsqueda al vuelo, sin crear nada en el diccionario. Se llama dentro del evento AT SELECTION-SCREEN ON VALUE-REQUEST

Las cuatro claves para que funcione, retfield dice qué columna de tu tabla es el valor que se devuelve; dynpprogr/dynpnr/dynprofield le dicen a SAP a qué campo de pantalla tiene que escribir el valor elegido; value_org = 'S' indica que le pasas una tabla estructurada (con varias columnas, no una lista plana); y return_tab te devuelve la selección para que la leas tú por si quieres hacer algo más.

Lo bonito es que el usuario ve un popup idéntico al de cualquier ayuda de búsqueda estándar — con sus columnas, su filtro, su doble clic — pero tú no has creado absolutamente nada en el diccionario. Todo vive en tu programa. Ideal para reports, para valores calculados en runtime, o para ofrecer una lista que depende de otro parámetro de la misma pantalla.

El matiz, si necesitas que esa ayuda de búsqueda la reutilicen veinte programas distintos, entonces sí, créala como objeto en el diccionario. Pero para el F4 puntual de un report concreto, esta función te ahorra el objeto, el transporte y el mantenimiento.

Hay una habilidad que nadie te enseña en ningún curso de SAP y que sin embargo marca una diferencia brutal en los proyectos, entender suficiente del módulo del consultor que tienes al lado como para hablar con él sin que la conversación se convierta en un partido de tenis con términos técnicos que ninguno de los dos comprende del otro.

No hablo de dominarlo. Hablo de entender su lógica. Entender que cuando el de SD dice que "la condición de precio no determina", el problema puede estar en FI. Que cuando el de MM dice que "el MRP propone fechas locas", igual hay algo en PP que no está configurado bien. Que cuando el de Basis dice que "el sistema va lento", antes de culpar al ABAP hay que mirar el buffer y los work processes.

Los mejores consultores que he conocido no son necesariamente los que más saben de su módulo. Son los que tienen suficiente curiosidad para asomarse al módulo de al lado y entender cómo encaja con el suyo. Esa curiosidad es la que convierte a alguien en un consultor de referencia en un proyecto.

Y si además consigues que el cliente lo perciba ( que ven que puedes hablar tanto con el de FI como con el de SD sin perder el hilo ) tu valor en ese proyecto sube de una forma que ningún certificado de SAP te va a dar.

El color azul analiza. El verde conecta. El rojo entrega. Pero el consultor que triunfa en proyectos complejos es el que sabe cuándo ser cada uno.

Los griegos no tenían SAP, pero tenían clara una cosa, la mitad del trabajo es saber quién eres. Y en consultoría pasa igual. El consultor que sabe que es azul y verde, que domina el análisis pero le cuesta la parte comercial, o el que reconoce que HR se le atasca y no pasa nada por decirlo, es un consultor que sabe con quién juntarse para cubrir sus puntos ciegos. El que cree que lo domina todo por igual es, casi siempre, el que menos se conoce. Sé de qué color eres. Es más útil que cualquier certificación.

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.