Vivimos en una industria que presume de ser la más moderna, la más abierta, la más meritocrática. Y sin embargo, es una de las que peor trata a los profesionales con experiencia. No lo digo yo, lo dicen los datos.

Según el informe de la EEOC estadounidense "High-Tech, Low Inclusion" (septiembre de 2024), la proporción de trabajadores mayores de 40 años en el sector tecnológico cayó del 55,9% en 2014 al 52,1% en 2022 , por debajo de la media nacional de todos los sectores. Mientras el resto del mercado laboral envejece (lógico, la gente vive y trabaja más años), el tech se hace más joven a propósito. Y la guinda, las denuncias por discriminación por edad representan casi el 20% de todas las quejas presentadas en el sector tecnológico, frente al 15% de media en el resto de industrias.

¿Por qué? El propio informe lo apunta sin rodeos, coste. Un perfil sénior puede cobrar el doble que uno junior por el mismo puesto sobre el papel. Y cuando llegan los recortes o se diseñan las plantillas, el que cobra 300.000 se convierte en el objetivo antes que el que cobra 150.000. No porque sea peor. Porque es más caro.

Y no es solo percepción, una encuesta de AARP de 2024 reveló que alrededor del 64% de los trabajadores mayores de 50 años han visto o vivido discriminación por edad en su puesto de trabajo. Dos de cada tres.

Lo paradójico es que en SAP, de todos los sitios, la experiencia debería valer oro. Un consultor que ha vivido tres migraciones, cinco cierres de año y un go-live que salió mal sabe cosas que no están en ninguna certificación. Y aun así, a veces esa persona es exactamente la que se queda fuera.

Curiosa coincidencia esta semana. SAP cotizaba el lunes 6 de octubre en torno a los 187,67 € (en operativa after-hours), con una subida del +1,18% respecto al cierre anterior de 185,49 €. Un verde discreto pero verde, en una semana con movimiento corporativo de fondo.

¿Y qué hay detrás del empujón? Entre otras cosas, el anuncio de la compra de TechWolf, una plataforma belga de inteligencia de datos sobre... habilidades y talento. Sí, lo has leído bien, justo la semana en la que el boletín habla de cómo el mercado desaprovecha el talento sénior, SAP se gasta un dineral en una IA para mapear capacidades de las personas. Que cada uno saque sus conclusiones sobre la ironía. La operación se espera cerrar en el Q4 de 2026, a falta de visto bueno regulatorio. Y en paralelo, SAP presentó en su evento SAP Connect de Las Vegas novedades como "Joule Work" y "SAP Pay".

Para el contexto habitual, el rango de las últimas 52 semanas sigue siendo amplio (del entorno de los ~127 € a los ~244 €), lo que recuerda que esta acción se mueve. Y el próximo gran catalizador tiene fecha, los resultados del Q3 2026 el 21 de octubre. Hasta entonces, el mercado irá reaccionando a golpe de titular corporativo, como esta semana.

Traducido al idioma del consultor, SAP sigue apostando fuerte por la IA aplicada a RRHH y al trabajo. Lo que decida la acción el 21 ya es otra historia.

Si todavía no sabes lo que es un SAP Inside Track, deja que te lo cuente, porque es de las cosas más sanas que tiene nuestra comunidad. Un SAP Inside Track (SIT) es un evento hecho por la comunidad y para la comunidad. No es un evento comercial de SAP, no te van a intentar vender licencias, no hay un keynote corporativo diciéndote lo maravilloso que es el último producto. Son consultores, desarrolladores y arquitectos de verdad compartiendo lo que saben con otros consultores. Gratis, cercano, y sin filtro de marketing.

El de Barcelona (SITBCN) es uno de los más veteranos de España, y este año es especial, celebra su décima edición el 13 de noviembre de 2026.

Un día entero de sesiones técnicas sobre lo que de verdad se está cociendo ahora mismo ( IA, SAP BTP, arquitectura, integración, desarrollo ) contadas por gente que las usa en proyectos reales. Habrá hasta una mesa redonda que resume perfectamente el espíritu del evento, "SAP, ayer, hoy… y lo que viene". Y como es el décimo aniversario, cierre con celebración incluida. El día antes, el 12, hay además una masterclass con Antonio Maradiaga, Developer Advocate de SAP.

¿Lo mejor? Lo organizan seis cracks de la comunidad poniendo su tiempo libre, con el apoyo de SAP Community, AUSAPE y un montón de partners. Nadie cobra por montar esto. Lo hacen porque creen en compartir conocimiento. Y eso, en una industria tan comercial como la nuestra, es oro puro.

Hace un tiempo leí un comentario que se me quedó clavado. No era sobre juniors ,de esos hablamos mucho, del eterno "pido tres años de experiencia para un puesto junior". Era sobre el otro extremo. Sobre esas personas que rondan los 55, los 58, los 60, que llevan toda la vida haciendo su trabajo bien, y que de repente se quedan fuera. No por malos. Por caros.

Y es que el edadismo en esta profesión tiene dos puertas, y las dos están igual de cerradas. Por abajo, al que empieza se le pide experiencia que no puede tener todavía. Por arriba, al que tiene toda la experiencia del mundo se le rechaza precisamente por tenerla. "Está sobrecualificado." "Se nos va de banda salarial." "No encaja en el perfil que buscamos." Traducción honesta, es muy bueno, pero no entra en la hoja de Excel del presupuesto.

Voy a ser directo con algo que nadie dice en voz alta, cuando una empresa rechaza a alguien "por exceso de experiencia", casi nunca es un problema de experiencia. Es un problema de precio y de cuotas. Hay márgenes que cumplir, hay una pirámide de perfiles que montar, y un sénior de verdad desajusta esa pirámide. Es más barato coger a dos personas con tres años cada una que a una con veinticinco, aunque esa persona con veinticinco resuelva en una tarde lo que a los otros dos les lleva una semana y un susto en producción.

¿Lo he visto? Lo he visto. He visto procesos de selección donde un perfil brutal se descartaba antes de la entrevista técnica porque "pedía mucho". He visto equipos sufrir meses un problema que un consultor veterano habría olido en diez minutos. Y he visto a esas personas, las que se quedan fuera, tener que elegir entre dos caminos igual de injustos, o bajan su tarifa y aceptan cobrar por debajo de lo que valen hasta que llega la jubilación, o se pasan meses buscando el mismo trabajo que llevan haciendo con solvencia dos décadas. Imagínate la sensación. Ser mejor que nunca en lo tuyo, y que el mercado te diga que ya no cabes.

Y aquí viene la parte que más me cuesta tragar, porque es la más absurda, en SAP esto es especialmente estúpido. Esto no es una industria de modas donde lo de ayer ya no sirve. Aquí el conocimiento se acumula. Un consultor que vivió la transición de R/3 a ECC, y de ECC a S/4HANA, tiene un mapa mental del producto que no se compra con un curso de Learning Hub. Sabe por qué una tabla está diseñada como está. Sabe qué se rompe cuando tocas according. Sabe distinguir un problema real de un drama inventado. Ese criterio es justo lo que falta en la mayoría de los proyectos que van mal. Y es justo lo que estamos descartando por "caro".

No me malinterpretéis. Entiendo las cuentas. Entiendo que un proyecto tiene un presupuesto y que alguien tiene que cuadrarlo. No estoy diciendo que haya que pagar cualquier cosa por un nombre con muchos años. Lo que digo es que estamos confundiendo coste con valor, y que esa confusión nos sale carísima, solo que la factura llega más tarde, cuando el proyecto descarrila y nadie sabe por qué.

También reconozco el otro lado, hay veteranos que se quedaron anclados, que no quisieron aprender nada nuevo desde 2010 y que usan la experiencia como excusa para no reciclarse. Esos existen, y el mercado tiene razón en penalizarlos. Pero no confundamos. Una cosa es el que no quiere evolucionar, y otra muy distinta es el que sabe muchísimo, sigue al día, y aun así se queda fuera por una cifra. Al primero el problema se lo ha buscado. Al segundo se lo hemos buscado nosotros.

La edad tope para trabajar en SAP no existe. Pero mientras sigamos tratando la experiencia como un pasivo en lugar de como un activo, vamos a seguir perdiendo a la gente que más sabe justo cuando más la necesitamos.

Llega ese SELECT que necesita un resultado intermedio, primero sacas unos partners, luego cruzas esos partners con las facturas, y encima quieres agrupar por mes. La solución de toda la vida era una de estas tres, un SELECT dentro de otro dentro de otro (ilegible), varias tablas internas con LOOPs de por medio (lento y feo), o directamente tirar de HANA con una vista. Desde ABAP 7.51 hay una cuarta opción mucho más elegante, las Common Table Expressions, o CTEs.

Una CTE es un resultado intermedio con nombre que defines al principio de la sentencia con WITH, y que puedes reutilizar en pasos posteriores de la misma consulta. Los nombres de las CTEs llevan siempre el prefijo +, y cada una puede apoyarse en la anterior,

Fíjate en la lógica, la primera CTE (+partners_eu) saca los partners que me interesan; la segunda (+facturas_mes) usa el resultado de la primera; y el SELECT final trabaja sobre la segunda. Todo en una sola sentencia que se ejecuta en la base de datos (code pushdown real), sin bajar datos intermedios al servidor de aplicación. Esto en HANA es oro, el optimizador lo resuelve entero abajo, y tú lees el código de arriba a abajo como una receta, paso por paso.

El caso de uso donde más brilla es cualquier report o cálculo con lógica por fases, agregaciones sobre agregaciones, filtros que dependen de un subconjunto previo, informes de KPIs. Donde antes tenías tres tablas internas y dos LOOPs anidados, ahora tienes un WITH limpio.

El matiz importante, las CTEs viven solo dentro de su sentencia , no son vistas reutilizables entre programas, ni se guardan en ningún sitio. Son de usar y tirar. Y si lo que necesitas es reutilizar esa lógica en veinte sitios, entonces eso es una CDS View, no una CTE. Cada herramienta para lo suyo.

Situación clásica de proyecto, el cliente recibe un anticipo de un cliente antes de entregar nada, o paga él un anticipo a un proveedor antes de recibir mercancía. Y aquí viene la pregunta que descoloca a más de un funcional júnior, ¿ese dinero va a la misma cuenta de deudores/acreedores que una factura normal? La respuesta es no, y el mecanismo que lo evita se llama Indicador de Cuenta de Mayor Especial (CME), o Special G/L Indicator.

Un anticipo no es una venta ni una compra, contablemente es otra cosa. Por normativa no puede mezclarse con los saldos comerciales normales. El indicador CME es lo que le dice a SAP, "este apunte, aunque sea del cliente X, no va a su cuenta de reconciliación habitual, va a una cuenta de mayor alternativa". Así los anticipos aparecen separados del saldo comercial, y el balance refleja la realidad, ese dinero todavía no es una venta consolidada.

Los indicadores típicos que te vas a encontrar, A (anticipo recibido de cliente), F (solicitud de anticipo, que es solo una partida estadística / nota), F y A se usan juntos en el ciclo de anticipos de cliente, y en proveedores tienes sus equivalentes. La configuración vive en transacciones como OBXR (clientes) y OBYR (proveedores), donde vinculas cada indicador CME con su cuenta de mayor alternativa.

El error clásico , y lo vas a ver literalmente escrito en un dump o mensaje de error , es este, "Special G/L indicator F is not defined for down payments". Traducción, alguien intenta registrar un anticipo pero nadie configuró el indicador CME ni le asignó su cuenta alternativa. El proceso de negocio existe, la transacción existe, pero falta el puente de Customizing. Y hasta que no lo pones, el anticipo no se puede contabilizar.

La recomendación práctica, siempre que un cliente mencione "anticipos", "pagos a cuenta" o "down payments" en un taller de diseño, lo primero que tienes que preguntar es qué indicadores CME van a usar y a qué cuentas alternativas apuntan. Si eso no está claro desde el diseño, te lo vas a encontrar reventando en pruebas

Todavía hoy, en 2026, abres código heredado y te encuentras un WS_UPLOAD o un GUI_DOWNLOAD (el módulo de función, no el método) para leer o escribir un fichero en el PC del usuario. Esos módulos están obsoletos desde hace años, SAP los marca como deprecated, y sin embargo siguen vivos en medio mundo de instalaciones. El reemplazo oficial y limpio es la clase CL_GUI_FRONTEND_SERVICES, y conviene conocerla bien porque la vas a usar constantemente.

Es una clase de utilidad con métodos estáticos para todo lo que tenga que ver con el frontend del usuario, abrir el diálogo de selección de fichero, leer, escribir, comprobar si un fichero existe, listar directorios, obtener la ruta del escritorio... El patrón típico es, primero dejas que el usuario elija el fichero con FILE_OPEN_DIALOG, y luego lo lees con GUI_UPLOAD

Y para el camino inverso, GUI_DOWNLOAD te escribe una tabla interna a un fichero en el PC del usuario , ideal para exportar el resultado de un report a CSV, por ejemplo, o para dejarle al usuario el PDF que acabas de generar con Adobe Forms.

El matiz más importante, y el que mucha gente olvida, esta clase solo funciona en ejecución online, con un usuario delante (SAP GUI). En un job de fondo no hay frontend, así que CL_GUI_FRONTEND_SERVICES no sirve , ahí tienes que usar OPEN DATASET para trabajar contra el servidor de aplicación. Confundir ambos mundos es el error típico, código que funciona de maravilla en pruebas interactivas y revienta en cuanto se programa como job nocturno. Y ojo, en ABAP Cloud / RAP tampoco está disponible, el frontend ahí es Fiori, y la subida/bajada de ficheros se gestiona de otra forma.

Este va para quien tiene voz en una contratación o monta un equipo de proyecto. Porque el edadismo del que hablo en Mi Opinión no es una fuerza abstracta del mercado, se materializa en decisiones concretas que toman personas concretas. Muchas veces, líderes de equipo que ni siquiera son conscientes del sesgo que están aplicando.

La escena es siempre parecida. Llega un CV con veinte años de experiencia, una tarifa acorde, y casi por reflejo alguien dice "uf, este se nos va de precio" o "para este puesto está sobrado". Y lo descartáis sin darle una entrevista. El problema es que esa decisión, que parece prudente a nivel presupuestario, puede ser carísima a nivel de proyecto.

Te propongo un ejercicio incómodo la próxima vez que tengas uno de esos perfiles delante, en lugar de preguntarte "¿cuánto me cuesta esta persona?", pregúntate "¿cuánto me cuesta NO tenerla?". Cuánto cuesta un go-live retrasado tres meses. Cuánto cuesta un error de diseño que nadie vio venir porque en el equipo no había nadie que ya lo hubiera sufrido antes. Cuánto cuesta un cliente que pierde la confianza porque el equipo iba aprendiendo sobre su sistema en producción. Esos costes no aparecen en la banda salarial, pero son reales y suelen ser mucho mayores que la diferencia de tarifa.

Un sénior de verdad no te aporta solo sus horas. Te aporta las horas que te ahorra a ti y al resto del equipo. Te aporta el "espera, esto ya lo he visto y acaba mal". Te aporta un criterio que acorta reuniones, que evita rediseños y que forma, de paso, a los juniors que tienes al lado. Eso no es un gasto. Es la mejor inversión en gestión de riesgo que puedes hacer en un proyecto.

Y hay una acción concreta que puedes tomar esta misma semana, revisa el último proceso de selección en el que hayas participado y cuenta cuántos perfiles se cayeron por "demasiada experiencia" o "demasiado caro" antes de llegar a una entrevista. Si hay alguno, pregúntate con honestidad si lo descartaste por el candidato o por la casilla del presupuesto. Y si puedes, dale la oportunidad de sentarse a hablar. A veces esa persona ajusta expectativas, a veces te sorprende, y a veces te acabas de ahorrar el mayor dolor de cabeza del próximo año.

Lo difícil de todo esto es que el ahorro de contratar barato se ve hoy, en la hoja de cálculo, y el coste de no contratar experiencia se ve tarde, cuando ya es irreversible. Liderar bien es, muchas veces, defender la decisión cuyo beneficio no se nota en el trimestre pero salva el proyecto entero.

Me viene como anillo al dedo esta semana. Porque la "edad tope" en SAP no la marca tu DNI, la marca si sigues con ganas de aprender o no. He conocido juniors de 25 con mentalidad de jubilado y veteranos de 58 más al día que medio LinkedIn. El problema nunca han sido los años acumulados, sino dejar de sumar. Así que da igual en qué franja estés, sigue aprendiendo y seguirás siendo contratable. Lo demás son excusas de la hoja de Excel

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.