Hay un número que cuando lo lees en frío produce una mezcla de reconocimiento y vértigo,desde 2021 se han producido 219 operaciones de fusión y adquisición en el sector de la consultoría tecnológica en España. Doscientas diecinueve. En cinco años. En un sector que no es especialmente grande.

Y la tendencia no para.En el primer trimestre de 2026 se contabilizaron 21 operaciones en consultoría tecnológica, un incremento del 50% respecto al mismo periodo de 2025 y del 250% frente a 2023. Es decir, lo que antes era un movimiento puntual y llamativo se ha convertido en la norma. El mercado se está consolidando a una velocidad que hace diez años nadie habría predicho.

¿Quién compra? El capital privado intervino en el 57% de las transacciones, impulsando la consolidación mediante la integración de consultoras de nicho en grandes estructuras. No siempre es una consultora grande comiéndose a una pequeña. Cada vez más son fondos de inversión que compran para consolidar, escalar y vender más grande en cinco años.

Y entre las operaciones más recientes que suenan en el ecosistema SAP español, la compra de Altim por Telefónica Tech, con capacidades especializadas en implantación de SAP clave para la transformación de procesos core. Ejemplo perfecto de una consultora SAP especialista absorbida por una estructura mucho más grande con otros objetivos estratégicos.

Lo curioso de todo esto es que detrás de cada uno de esos 219 números hay cientos o miles de consultores que un día llegaron a la oficina con la misma sensación: algo está pasando y nadie me está contando exactamente qué.

Hay una palabra que aparece cada vez más en conversaciones sobre proyectos SAP y que merece que nos paremos a analizarla con calma: "deshoring". No es un typo. Es el concepto que Stuart Browne, CEO de Resulting IT, puso encima de la mesa en un webinar reciente recogido por SAP News y que básicamente propone lo siguiente: en lugar de preguntarte dónde pones el trabajo humano, pregúntate si ese trabajo humano tiene que existir.

Tras analizar aproximadamente 180 actividades típicas de una migración de SAP ECC a S/4HANA, la investigación de Browne concluye que la IA agéntica podría producir una reducción de costes de alrededor del 60% comprimiendo el esfuerzo y permitiendo que tareas que antes requerían perfiles muy experimentados sean realizadas por perfiles menos experimentados con IA como soporte.

Los casos de uso más concretos que se mencionan son escribir especificaciones funcionales y técnicas, realizar análisis fit-gap y analizar código custom. Tres actividades que cualquier consultor SAP reconoce como intensivas en tiempo y en perfil senior. En el análisis de código custom, la IA puede analizar toda la base de código, hacer ingeniería inversa de especificaciones funcionales y determinar si el mismo requisito de negocio puede cubrirse con funcionalidad estándar de SAP.

Pero hay una frase del artículo que me parece la más importante y la que menos titulares genera: "Lo que produce la IA no debería ser completamente confiado sin revisión." El modelo emergente no es transformación autónoma. Es acelerar el 80% del trabajo mientras se concentra la experiencia humana en el último tramo, que incluye juicio, validación, decisiones de diseño y actividades donde la experiencia añade más valor.

Dicho de otra forma: la IA hace el borrador. El consultor con criterio lo convierte en algo que funciona de verdad. Lo que cambia es cuántas horas necesita ese consultor para llegar al resultado final.

¿Eso es una amenaza para el consultor SAP o una oportunidad para los que sepan usarla antes que los demás? La respuesta, como casi siempre, depende de qué lado de la curva de aprendizaje estés.

Las acciones de SAP han subido un 4,96% en comparación con la semana anterior y un 43,51% en el último mes. Cuarenta y tres por ciento en un mes. Desde los mínimos de 127,50€ de hace unas semanas hasta los casi 188€ actuales hay una recuperación de casi el 47%. El mercado ha decidido que igual se pasó castigando.

¿Qué ha impulsado esta recuperación? Los resultados del Q2 del 23 de julio actuaron como catalizador aunque los números de EPS quedaron por debajo de estimaciones. Lo que el mercado leyó entre líneas fue suficiente para girar el sentimiento. A eso se suma que el contexto macro ha mejorado ligeramente y que los inversores empiezan a ver el nivel actual como una oportunidad frente a los máximos de 244€.

El precio objetivo medio a 12 meses para SAP es de 205,77€, con una estimación alta de 290€ y una estimación baja de 160€. La próxima cita con los inversores es el 21 de octubre de 2026 con los resultados del Q3.

Desde los 127€ de mínimos hasta los 205€ de precio objetivo medio hay todavía un recorrido del 9% desde los niveles actuales. No es una barbaridad pero tampoco es despreciable. Octubre dirá si el mercado sigue creyendo en el relato de la IA agéntica o si prefiere esperar a ver números reales. 😄

⚠️ Sección puramente informativa. No constituye consejo de inversión. Soy consultor SAP, no gestor de fondos.

Lo viví. Una vez, y con la distancia que da el tiempo puedo contarlo con más honestidad de la que probablemente tendría si lo estuviera viviendo ahora mismo.

Pero primero lo primero. Antes de hablar de lo que pasa después, hay que hablar de los tipos de absorción porque no todas son iguales ni tienen las mismas consecuencias para el trabajador de a pie.

Está la fusión entre dos consultoras que se unen para ser más grandes. En teoría nadie come a nadie, los dos son iguales, es una unión estratégica. En la práctica siempre hay una que tiene más peso que la otra y en seis meses todo el mundo sabe cuál manda realmente aunque nadie lo diga en los comunicados. Está la consultora grande que se come a la pequeña, que es el caso más clásico y el más reconocible. La pequeña tiene algo que la grande quiere: una cartera de clientes, un nicho de especialización, un equipo de perfiles escasos o simplemente presencia en un mercado donde la grande no llega bien. Y está el fondo de inversión que compra la consultora, que es el que más miedo da porque un fondo no compra para quedarse. Compra para rentabilizar y vender más grande en tres o cinco años. Y eso cambia completamente la lógica de todo lo que viene después.

Cada uno de estos tres escenarios tiene sus propias implicaciones para el trabajador. Pero los primeros meses, curiosamente, se parecen mucho en los tres.

Primero llegan los rumores. Siempre antes de que nadie confirme nada. Un comentario en el pasillo, algo que alguien vio en LinkedIn de forma críptica, una reunión a la que los de arriba llegaron tarde y salieron con cara rara. El rumor no tiene nombre ni fecha concreta. Solo existe como una incomodidad colectiva que nadie verbaliza en voz alta pero que todo el mundo siente. Y lo más curioso del rumor en estos casos es que normalmente tiene bastante razón. La gente no inventa estas cosas de la nada.

Luego se confirma. Y entonces pasa algo que a primera vista parece paradójico: nada cambia. Al menos de forma visible. Sigues en tu puesto, sigues en tus proyectos, sigues recibiendo tu nómina puntual el mismo día de siempre. Se hace un comunicado corporativo con palabras como "oportunidad estratégica", "sinergias", "crecimiento conjunto" y "equipo más fuerte". Y el lunes siguiente todo el mundo va a trabajar como si no hubiera pasado nada.

Pero algo ha cambiado de forma invisible. Y es que ahora la incertidumbre tiene nombre y apellidos. Y eso es mucho más difícil de gestionar que el rumor, porque con el rumor siempre podías pensar que igual no era para tanto.

Empieza lo que yo llamo los meses de nada. Y son los más duros de todo el proceso. No porque pase algo malo visible, sino precisamente porque no pasa nada visible. El trabajo sigue, los clientes siguen, las reuniones siguen. Pero por debajo está pasando un montón de cosas que tú no ves y que son exactamente las que van a determinar tu futuro en esa empresa.

Están pasando reuniones a las que no te invitan donde se decide qué estructuras se mantienen y cuáles desaparecen. Están pasando conversaciones entre directivos de las dos empresas donde se decide quién de los cargos intermedios sobra porque ahora hay dos personas haciendo lo mismo. Están pasando evaluaciones de la cartera de clientes para decidir cuáles son estratégicos y cuáles no. Y están pasando negociaciones con algunos perfiles clave para asegurarse de que no se van antes de que la integración esté estabilizada.

Todo eso pasa. Y tú ves tu pantalla, tus tickets y tus reuniones de proyecto como cualquier otro día.

La primera señal visible de que algo se está moviendo es que los compañeros empiezan a irse. No los peores. Los que tienen más opciones. Y aquí es donde la gente reacciona de formas muy distintas y muy interesantes.

Hay quien se va desde el minuto uno porque la incertidumbre le resulta insoportable. No porque sepa que le van a echar. Sino porque prefiere ser él quien decide cuándo y hacia dónde en lugar de esperar a que alguien decida por él. Ese perfil normalmente llega al mercado laboral con toda la calma del mundo, sin presión, sin el peso de haber sido despedido, con tiempo para negociar bien. Y generalmente consigue algo mejor de lo que tenía porque llegó antes de que el mercado supiera que había un montón de consultores de esa empresa disponibles.

Hay quien espera porque genuinamente cree que todo va a salir bien o porque sus circunstancias personales en ese momento no le permiten asumir el riesgo de moverse. Una hipoteca reciente, una familia que mantener, un momento de vida donde la estabilidad vale más que la oportunidad. Perfectamente válido y perfectamente comprensible. Algunos de los que esperan salen muy bien parados. Otros no tanto. Pero la decisión de quedarse no es necesariamente una decisión equivocada.

Y hay quien se queda porque su perfil es tan específico del cliente donde está que sabe que sea cual sea el resultado de la absorción, ese cliente va a necesitarle. Ese perfil tiene más tranquilidad que el resto porque su valor no depende tanto de la empresa en la que figura en la nómina sino de la relación directa con el cliente.

Yo me fui antes. No porque supiera que me iban a echar ni porque tuviera información privilegiada sobre lo que iba a pasar. Me llegó una oportunidad interesante justo en ese momento y la aproveché. La situación de la absorción me dio el empujón que quizás en condiciones normales no hubiera sido suficiente para moverme, porque cuando tienes cierta comodidad en un sitio el umbral para cambiar sube. La incertidumbre bajó ese umbral y la oportunidad apareció en el momento exacto. No fue planificado. Fue suerte y buen ojo. O las dos cosas a la vez.

Tengo familiares cercanos que se quedaron hasta el final. Y lo que cuentan de esos meses es muy revelador. El ambiente en la empresa cambia de una forma sutil pero constante. No hay gritos ni dramas. Hay ausencias. El compañero que llevaba cinco años sentado a tu lado un día ya no está y nadie hace una reunión para despedirle. Hay proyectos que se paralizan sin explicación clara. Hay conversaciones que se cortan cuando llegas a la sala. Y hay una sensación generalizada de que la información que recibes es siempre incompleta, siempre un poco tarde y siempre más optimista de lo que la realidad parece indicar.

Esa sensación, mantenerla durante meses, tiene un coste psicológico real que muy poca gente habla públicamente. Porque en el sector tecnológico hay una presión implícita a parecer siempre bien, siempre adaptable, siempre capaz de gestionar cualquier situación con profesionalidad. Y vivir una absorción mal gestionada desde dentro mientras tienes que mantener esa fachada hacia el cliente y hacia el equipo es agotador de una forma que no siempre se puede explicar bien a quien no lo ha vivido.

Y luego están los clientes. Que son en realidad la variable más importante de toda la operación aunque sea la que menos se comenta hacia los trabajadores. Porque los clientes de una consultora SAP especializada no contratan a una empresa. Contratan a un equipo que conoce sus procesos, su sistema, su historia. Cuando ese equipo está en incertidumbre, cuando empiezan a irse personas que el cliente conoce y en las que confía, el cliente lo nota. Y empieza a hacerse preguntas. Y dependiendo de cómo gestione la empresa compradora esa transición, el cliente se queda o se va. Y si se va, hay menos trabajo. Y si hay menos trabajo, hay menos necesidad de tanta gente. Y ahí es donde los meses de nada dejan de ser de nada.

No todas las absorciones acaban mal para los trabajadores. Las hay que se gestionan bien, donde la integración es ordenada, donde los equipos se respetan y donde dos años después la gente reconoce que el cambio fue a mejor. Pero esas historias de éxito casi siempre tienen en común que alguien en algún momento tuvo la honestidad de decirle a los trabajadores lo que sabía, lo que no sabía y lo que estaba haciendo para que la transición fuera lo menos traumática posible. No un comunicado corporativo. Una conversación real.

¿Tú has vivido una absorción? ¿Fuiste de los que se fueron antes, de los que esperaron o de los que aguantaron hasta el final? Me encantaría leer vuestras historias porque sé que hay mucha gente que las ha vivido y que muy pocas veces se habla de esto con esta honestidad.

El testing en ABAP es la gran asignatura pendiente de la mayoría de los equipos. No porque nadie sepa que debería hacerse, sino porque durante décadas no había una forma elegante de hacerlo integrada en el propio entorno de desarrollo. CL_ABAP_UNIT_ASSERT es la clase que cambia eso.

Es la clase central del framework ABAP Unit Testing. Sus métodos estáticos son las aserciones que usas dentro de los métodos de test para verificar que tu código hace lo que tiene que hacer. No se instancia , todos sus métodos son estáticos y se llaman directamente.

CL_ABAP_UNIT_ASSERT proporciona métodos como assert_equals para comparar dos valores, assert_bound para verificar que una referencia está enlazada, assert_not_initial para verificar que un valor no es inicial, assert_true y assert_false para verificar condiciones booleanas, y fail para reportar un error incondicional cuando se llega a un punto que no debería alcanzarse.

La clase de test se define con las adiciones FOR TESTING, DURATION y RISK LEVEL. RISK LEVEL indica el riesgo del test de harmless a critical, y DURATION define el tiempo máximo de ejecución antes de que el framework cancele el proceso.Para tests unitarios puros el estándar es DURATION SHORT y RISK LEVEL HARMLESS.

Los tests se ejecutan desde Eclipse con Ctrl+Shift+F10 sobre la clase, o desde SE24 con el menú Clase → Ejecutar → Unit Tests. El resultado aparece en una vista de árbol donde ves exactamente qué tests han pasado, cuáles han fallado y el mensaje de error definido en el parámetro msg.

Lo que más cuesta adoptar cuando empiezas con ABAP Unit no es la sintaxis. Es el cambio de mentalidad de escribir el test antes o al mismo tiempo que el código en lugar de después. Pero una vez que tienes una suite de tests que se ejecuta en segundos y te dice exactamente qué has roto cuando cambias algo, es muy difícil volver a desarrollar sin ellos.

Hay una pregunta que aparece en casi todos los proyectos con módulo FI cuando el equipo de cuentas a pagar empieza a trabajar con el sistema y los pagos no salen en las fechas que esperaban: ¿por qué el sistema calcula una fecha de vencimiento diferente a la que el proveedor indica en la factura?

La respuesta casi siempre está en que alguien configuró las condiciones de pago sin entender bien cómo interactúan la fecha base, el plazo de descuento y la fecha de vencimiento neta.

Las condiciones de pago en SAP FI, que se configuran en la transacción OBB8, definen tres cosas relacionadas pero distintas. La fecha base es el punto de partida desde el que el sistema calcula todo lo demás. Puede ser la fecha del documento, la fecha de contabilización, la fecha de entrada o incluso una fecha fija del mes. Esa elección parece menor pero tiene consecuencias enormes en cómo se calculan los vencimientos reales.

A partir de la fecha base, SAP calcula la fecha de descuento por pronto pago: si el cliente o proveedor paga antes de X días desde la fecha base obtiene un porcentaje de descuento. La fecha base para el pago es la fecha a partir de la cual se aplican las condiciones de pago. Es la base que usa el sistema para determinar el descuento por pronto pago tomado del proveedor o concedido al cliente.

Y por último calcula la fecha de vencimiento neta: el día límite para pagar sin penalización si no se ha aprovechado el descuento.

El error clásico en proyectos es configurar la fecha base como "fecha de documento" cuando el proceso real del cliente trabaja con la fecha de contabilización, o viceversa. El resultado es que el sistema calcula vencimientos que no coinciden con lo que el proveedor esperaba y el departamento de tesorería no entiende por qué los pagos automáticos salen en fechas que nadie pidió.

Las condiciones de pago se copian en los maestros de proveedor y cliente, en los documentos de compra y venta, y en los documentos contables. Durante el registro de la factura, SAP usa la condición de pago, la fecha base y los días de descuento para calcular cuándo vence la factura y si se puede aplicar un descuento.

Hay un caso especialmente confuso que aparece en muchos sistemas heredados: la configuración donde en lugar de definir la fecha de vencimiento en los campos de condición de pago se mueve la fecha base a un día fijo del mes siguiente, haciendo que la factura venza "inmediatamente" desde esa nueva fecha base. Es técnicamente correcto pero genera confusión porque la fecha base que se muestra en el documento no es la fecha del documento original sino la fecha calculada, lo que hace difícil auditar por qué el sistema calcula esa fecha de vencimiento.

La ruta SPRO para configurar condiciones de pago es: Contabilidad Financiera → Deudores y Acreedores → Operaciones Comerciales → Facturas Entrantes → Definir Condiciones de Pago (OBB8).

Hay un momento que todo técnico SAP teme más de lo que debería admitir en público: el import de un transporte en producción que falla con return code 8. El sistema se para, el cliente llama, todo el mundo mira al BASIS y la pregunta inevitable es "¿no se podía haber comprobado antes?"

La respuesta es sí. Y la herramienta que lo hace posible es /SDF/TRCHECK.

/SDF/TRCHECK, o su equivalente el report /SDF/CMO_TR_CHECK, proporciona verificaciones proactivas sobre los objetos de las órdenes de transporte y predice errores relacionados con transportes antes de que se importen en el sistema destino. No es magia. Es análisis. La transacción compara lo que hay en la orden de transporte con el estado actual del sistema destino y alerta si algo puede salir mal.

Los casos de uso más habituales son dos. El desarrollador que revisa su transporte en el sistema de desarrollo antes de liberarlo hacia QAS. Y el transport manager que revisa un conjunto de transportes en QAS antes de importarlos en PRD. En los dos casos el objetivo es el mismo: saber antes de actuar.

¿Qué comprueba exactamente? Hay cuatro verificaciones principales que merecen atención.

La verificación de referencias cruzadas comprueba si los objetos de un transporte tienen dependencias con objetos en otros transportes que todavía no se han importado en el sistema destino. Si esas dependencias no se resuelven antes de importar, el transporte puede fallar o generar comportamientos inesperados. Es el check más potente y el menos conocido. Porque en proyectos con muchos desarrollos paralelos es muy habitual que alguien transporte un programa que llama a una función que otro compañero modificó en otro transporte que todavía no llegó a QAS.

La verificación de secuencia comprueba si hay otras órdenes de transporte con objetos idénticos que se han liberado en el período de análisis pero que todavía no se han importado en el sistema destino. Esto detecta los conflictos de versión antes de que generen un downgrade silencioso. Cuando dos transportes modifican el mismo objeto y se importan en el orden incorrecto, el resultado en producción puede ser que una corrección reciente quede sobreescrita por una versión anterior sin que nadie lo detecte hasta que el error aparece.

La verificación de objetos críticos requiere preparación previa pero es especialmente valiosa para go-lives y ventanas de cambio grandes. En el sistema destino se mantiene una tabla /SDF/OI_CRITOBJ con SM30 donde se definen los objetos que se consideran críticos para las operaciones en vivo, como índices de tablas grandes o extensiones de tabla que fuerzan recompilación masiva. Si algún transporte contiene esos objetos, la transacción lo alerta antes de importar.

Y por último la estimación de tiempo de import, que suma los tiempos de import de cada transporte en el sistema origen para dar una indicación aproximada del tiempo que tardará en el destino. Muy útil para planificar ventanas de mantenimiento.

Para ejecutarla necesitas dos conexiones RFC: una al sistema origen donde están los transportes y otra al sistema destino donde se van a importar.Un truco práctico es crear dos variantes del programa: una para el import de calidad con origen en desarrollo y destino en QAS, y otra para el import de producción con origen en QAS y destino en PRD. Así cualquier BASIS puede lanzarla rápidamente sin tener que rellenar los parámetros cada vez.

La transacción está disponible a partir del componente ST-PI y funciona tanto desde el propio sistema como desde SAP Solution Manager. En entornos con ChaRM activo puede integrarse en el proceso de change management para ejecutarse automáticamente durante la liberación de transportes.

Hay una posición especialmente incómoda en una absorción de consultoras que muy poco se habla: la del mando intermedio. El responsable de equipo, el jefe de proyecto, el lead que tiene personas a su cargo y que sabe más de lo que puede contar pero menos de lo que su equipo necesita saber.

Ese perfil está en tierra de nadie. Por arriba le piden discreción y que mantenga la normalidad operativa. Por abajo tiene personas que le preguntan qué va a pasar y que esperan de él una honestidad que en ese momento no puede dar del todo. Es una posición incómoda que requiere más habilidad de comunicación que cualquier reunión de steering que hayas gestionado en tu vida.

Lo primero que hay que entender es que en una absorción los cargos intermedios son estadísticamente los más vulnerables. Los perfiles muy técnicos y especializados son difíciles de reemplazar y los clientes los conocen. Los directivos tienen contratos con cláusulas de permanencia o salidas negociadas. El mando intermedio es el que queda en el medio sin ninguna de esas protecciones. Saberlo no es para entrar en pánico. Es para actuar con inteligencia.

¿Qué significa actuar con inteligencia en esa situación? Significa tres cosas concretas que muy pocos responsables de equipo hacen y que marcan una diferencia enorme en cómo se vive ese período.

La primera es ser lo más transparente posible con tu equipo dentro de lo que puedes serlo. No tienes que contarles todo. No puedes contarles todo. Pero hay una diferencia enorme entre decirle a tu equipo "no sé exactamente qué va a pasar pero os mantendré informados de todo lo que pueda" y hacer como si no pasara nada mientras ellos ven cómo compañeros de otras áreas empiezan a irse. La primera opción genera confianza aunque la incertidumbre sea la misma. La segunda genera desconfianza aunque el mensaje corporativo sea optimista.

La segunda es cuidar especialmente a los perfiles clave del equipo. En los meses de incertidumbre post-absorción, el mercado laboral sabe exactamente quién está en situación vulnerable y los recruiters lo aprovechan. El consultor bueno de tu equipo va a recibir llamadas. Si no le das ninguna razón para quedarse, se va. Y en ese momento perder a alguien clave no es solo un problema de recursos humanos, es un problema de continuidad de servicio para el cliente que puede desencadenar exactamente lo que más temes.

La tercera, y la más difícil, es tomar una decisión sobre tu propio futuro con la cabeza fría y sin esperar demasiado. Los responsables de equipo que esperan pasivamente a ver qué decide la empresa sobre ellos casi siempre llegan tarde a cualquier conversación, tanto interna como externa. Los que evalúan sus opciones de forma activa desde el principio llegan a esas conversaciones con mucho más poder de negociación, independientemente de si al final se quedan o se van.

Una absorción no es el fin del mundo. Muchas de ellas salen bien para los empleados, o al menos razonablemente bien. Pero las que salen bien casi nunca son casualidad. Son el resultado de personas que gestionaron la incertidumbre con cabeza, que cuidaron a su equipo durante los meses difíciles y que tomaron decisiones sobre su propio futuro antes de que alguien las tomara por ellas.

Llevamos meses hablando de lo que la IA puede o no puede hacer en proyectos SAP. Especificaciones, análisis de código, fit-gap, testing... la lista de lo que los agentes prometen hacer crece cada semana. Pero la pregunta de Skinner, aunque tiene décadas, sigue siendo la más relevante de todas.

Porque al final el consultor SAP que más va a valer en los próximos años no es el que mejor sepa usar la IA. Es el que mejor sepa pensar sobre lo que la IA produce. Y eso, a diferencia del acceso a las herramientas, no se democratiza de la noche a la mañana.

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.