Según un estudio de Michael Page, el 49% de los empleados ha considerado dejar su empresa tras su primer día de trabajo. Casi la mitad. Y la causa más habitual no es el salario ni las condiciones. Es la sensación de haber llegado a un sitio donde nadie te esperaba de verdad.

Las empresas tienen una ventana media de 44 días para influir en la retención a largo plazo, siendo la primera semana el período más crítico para la decisión de quedarse. 44 días. Menos de dos meses. En ese tiempo se decide si alguien va a comprometerse con la empresa o va a estar mirando otras ofertas desde la semana cinco.

Y aquí viene el dato que más me llama la atención en el contexto de la consultoría SAP: hasta el 20% de la rotación de personal ocurre dentro de los primeros 45 días de empleo. Uno de cada cinco que se van, se van antes de cumplir dos meses. No porque el trabajo no encajara. Sino porque nadie les integró bien.

En el mundo SAP esto tiene una dimensión particular. No llegas a una empresa con un proceso de onboarding estructurado, con un manual y con un compañero asignado para tus primeras semanas. Llegas a un proyecto en marcha, con su propia dinámica, sus propias guerras internas y su propio sistema que nadie te va a explicar completo porque todos están demasiado ocupados con sus propias cosas. Y tienes que integrarte rápido. Muy rápido. Porque el cliente no entiende de períodos de adaptación y el proyecto no para porque tú acabes de llegar.

Curioso que algo tan crítico para la retención de talento se deje casi siempre al azar en los proyectos SAP.

Gartner acaba de publicar su primer Magic Quadrant específico para plataformas de Digital Twin of an Organization (DTO), una categoría que no existía como tal hasta ahora, y SAP ha entrado directamente como líder. Evaluados 18 vendors. Primera edición. Liderazgo desde el arranque.

Pero lo más interesante de esta noticia no es el galardón. Es lo que dice sobre hacia dónde está apuntando SAP con toda su estrategia.

Un gemelo digital de organización es exactamente lo que suena: una réplica virtual de cómo funciona una empresa, sus procesos, sus personas, sus aplicaciones y sus datos. No para simular escenarios de fabricación como el gemelo digital industrial clásico, sino para entender qué pasa cuando cambias algo en la organización antes de cambiarlo de verdad. Quieres reorganizar un departamento, rediseñar un proceso de ventas o introducir agentes de IA en la gestión de pedidos... el DTO te dice qué va a pasar antes de que pase.

SAP llega a esta categoría con una combinación que ningún otro vendor tiene igual de integrada: SAP Signavio para inteligencia y modelado de procesos, SAP LeanIX para arquitectura empresarial, WalkMe para adopción digital, SAP BTP para automatización y Joule como capa de IA, todo unido dentro de la SAP Business AI Platform.

Lo que no dice el comunicado pero se deduce claramente: SAP está construyendo la infraestructura de conocimiento que va a necesitar para que sus agentes de IA funcionen de verdad en producción. Un agente autónomo que no entiende cómo está organizada la empresa, qué procesos existen y cómo se relacionan entre sí no puede tomar buenas decisiones. El DTO es exactamente ese mapa. Y SAP lo está construyendo como ventaja competitiva a largo plazo.

Para el consultor SAP esto tiene una implicación concreta: SAP Signavio y SAP LeanIX van a tener cada vez más peso en los proyectos. No solo como herramientas de consultoría de procesos, sino como la capa de conocimiento que alimenta la IA. Quien los conoce bien tiene ventaja.

Semana muy diferente a las anteriores. A 30 de julio de 2026, la cotización de SAP en Fráncfort se sitúa en 155,92€, con un rango diario entre 155,20€ y 163,16€ y un rango de 52 semanas entre 127,50€ y 258,70€.

El cambio respecto a semanas anteriores es notable. Las acciones de SAP han subido un 15,61% en comparación con la semana anterior y un 20,29% en el último mes. Después de meses instalada cerca de mínimos anuales, la acción ha pegado un tirón considerable.

¿Qué ha pasado? Los resultados del Q2 del 23 de julio llegaron y el mercado los procesó. Las ganancias por acción del último trimestre fueron de 1,59€ frente a una estimación de 1,75€, lo que supone un -9,39% por debajo de lo esperado. Curioso: los números decepcionaron en EPS... y aun así la acción subió. Lo que el mercado leyó entre líneas debió de gustarle más que el dato puro.

La próxima cita con los inversores es el 21 de octubre de 2026 con los resultados del Q3. El precio objetivo medio a 12 meses de los analistas es de 201,55€, con una estimación alta de 290€ y una baja de 154,99€.

Desde los mínimos de 127,50€ hasta los 155€ actuales hay una recuperación de casi el 23%. Desde los máximos de 258€ todavía queda un -40% por recuperar. El mercado ha decidido que SAP no estaba tan mal como parecía hace unas semanas. Si eso se mantiene o no... eso ya es cosa de los analistas, no mía.

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

El primer día en una empresa o proyecto nuevo tiene algo de salto al vacío controlado. Sabes que vas a caer, no sabes exactamente dónde. Y en la consultoría SAP ese salto tiene sus propias particularidades que no aparecen en ningún proceso de selección ni en ningún contrato.

Voy a contarte lo que yo he aprendido llegando a sitios nuevos. No la versión bonita de LinkedIn donde todo el mundo da la bienvenida y el primer día es maravilloso. La versión real.

Lo primero que pasa cuando llegas a un proyecto SAP en marcha es que todo el mundo está ocupado. El compañero que se supone que te va a introducir tiene una reunión en diez minutos. El responsable del proyecto está gestionando una incidencia. El funcional de referencia está de viaje esa semana. Y tú te quedas con el portátil recién configurado, un acceso al sistema que igual todavía no funciona del todo, y la sensación de que has interrumpido algo importante con tu sola presencia.

Eso es normal. No es que nadie te quiera. Es que un proyecto SAP en marcha no para porque hayas llegado tú. Y cuanto antes lo asumes, antes empiezas a moverte de forma útil.

Lo segundo que pasa, y esto es lo que más cuesta reconocer, es que los primeros días hay que aguantar el impulso de demostrar lo que sabes. Es muy humano querer dejar claro desde el primer día que eres bueno, que tienes experiencia y que has llegado a aportar. Y ese impulso, bien gestionado, es positivo. Mal gestionado, te lleva a opinar de cosas que no conoces todavía, a proponer cambios sin entender el contexto y a ganarte la desconfianza del equipo antes de haber construido ninguna credibilidad.

Los primeros días son de escucha activa. De hacer preguntas más que de dar respuestas. De entender quién manda de verdad, no solo en el organigrama sino en la práctica. De saber quién tiene el conocimiento real del sistema aunque no tenga el título más llamativo. De identificar las dinámicas del equipo antes de meterte en ninguna de ellas.

Hay una cosa que hago siempre cuando llego a un sistema SAP nuevo y que me ha ahorrado mucho tiempo, antes de preguntar cómo están configuradas las cosas, intento entender por qué están configuradas así. Detrás de cada parametrización rara, de cada desarrollo Z que parece una chapuza y de cada proceso que no tiene ningún sentido aparente, hay una historia. A veces es una mala decisión de diseño. A veces es una restricción del negocio que nadie documentó. A veces es la huella de alguien que ya no está y que nadie se atrevió a cambiar. Entender esas historias antes de proponer nada es la diferencia entre alguien que aporta desde el día uno y alguien que genera resistencia sin querer.

Lo tercero, y esto es para el que llega a una empresa nueva y no solo a un proyecto, las primeras semanas son el mejor momento para preguntar cosas que después ya no puedes preguntar sin quedar mal. Nadie espera que sepas todo el segundo día. Pero sí esperan que después de tres meses domines lo básico. Aprovecha esa ventana. Pregunta sin vergüenza. Documenta todo lo que aprendes. Y construye relaciones con las personas que van a ser tus aliados a largo plazo, no solo con las que tienen más visibilidad.

Y una última cosa que nadie menciona, el sistema SAP de un cliente nuevo siempre es más complejo de lo que parece en el primer vistazo. Siempre. Hay capas, hay desarrollos Z que no están en ningún sitio documentados, hay procesos que funcionan de una forma en la transacción y de otra en la práctica porque alguien lo ajustó hace años y nadie actualizó la documentación. No te frustres cuando descubras que lo que parecía sencillo no lo es tanto. Eso no es que el sistema esté mal. Es que lleva años de vida encima y tú acabas de llegar

Hay un escenario que aparece en casi todas las integraciones SAP con sistemas externos y que muy poca gente diseña correctamente desde el principio: ¿qué pasa cuando el mismo mensaje llega dos veces?

Un sistema externo envía un pedido a SAP a través de Integration Suite. SAP lo procesa y confirma. Pero por un problema de red, el sistema emisor no recibe la confirmación. Reintenta el envío. Y ahora el mismo pedido llega dos veces. Si el iFlow no está preparado para esto, SAP crea dos pedidos idénticos. El cliente llama. El caos empieza.

El Idempotent Process Call es el mecanismo de Integration Suite para garantizar que un mensaje con el mismo identificador único solo se procesa una vez, aunque llegue varias veces al iFlow. La segunda y siguientes llegadas del mismo mensaje se detectan como duplicados y se ignoran o se responde con el resultado del primer procesamiento, sin volver a ejecutar la lógica de negocio.

El concepto es sencillo: el paso almacena el identificador único del mensaje en un repositorio idempotente. Cuando llega un mensaje nuevo, comprueba primero si ese identificador ya existe. Si existe, lo trata como duplicado. Si no existe, lo procesa normalmente y guarda el identificador.

En la práctica, la configuración en el iFlow tiene tres partes. Primero defines qué campo del mensaje actúa como identificador único — el número de pedido, el ID de transacción, lo que tenga sentido para ese proceso de negocio. Segundo, envuelves la lógica de negocio principal en un Local Integration Process al que llamas mediante el paso Idempotent Process Call. Tercero, configuras ese paso con el identificador único y el tiempo de retención en el repositorio.

Hay un matiz importante que la documentación no destaca suficientemente: si el fallo ocurre en el primer intento, el identificador no se guarda en el repositorio porque el commit no se llega a ejecutar. Eso significa que un reintento del mismo mensaje tras un fallo no se trata como duplicado, que es el comportamiento correcto. Solo se considera duplicado si el primer procesamiento fue exitoso.

La diferencia entre un iFlow con y sin este mecanismo no se nota el día del go-live. Se nota tres meses después cuando un proveedor llama diciendo que tiene el doble de entregas de las que pidió.

Hay una conversación que ocurre en todos los proyectos SD con clientes que venden a crédito y que si no se tiene bien pronto genera confusión durante meses: ¿cómo funciona la gestión de crédito en SAP y quién la controla realmente?

La gestión de crédito en SAP SD bloquea automáticamente pedidos de venta o entregas cuando un cliente supera su límite de crédito. Suena sencillo. En la práctica tiene capas que el funcional tiene que entender bien antes de ponerse a configurar nada.

El primer concepto que hay que tener claro es el área de control de crédito. Es la unidad organizativa que agrupa clientes bajo las mismas reglas de crédito. Una empresa puede tener varias, por ejemplo una por región o una por línea de negocio. Y aquí está el primer error clásico en proyectos: diseñar el área de control de crédito sin preguntar al departamento financiero cómo quieren segmentar el riesgo. Porque la respuesta de ventas y la respuesta de finanzas sobre cómo agrupar clientes para el control de crédito no siempre coinciden.

El segundo concepto es la diferencia entre control de crédito estático y dinámico. El estático suma todo lo que el cliente tiene abierto ( pedidos, entregas, facturas y partidas abiertas ) y lo compara con el límite. El dinámico hace lo mismo pero excluye los pedidos cuya fecha de entrega supera el horizonte temporal configurado, para no bloquear pedidos de largo plazo por compromisos futuros que todavía no son deuda real. Cuál usar depende del tipo de negocio del cliente y de cómo quiere gestionar el riesgo el departamento de crédito.

Y aquí viene el matiz que más confunde en proyectos de S/4HANA: en ECC la gestión de crédito se mantiene en FD32 con la transacción clásica. En S/4HANA ha sido reemplazada por Advanced Credit Management con la transacción UKM_BP integrada en el Business Partner. La transacción VKM1 para liberar documentos bloqueados sigue funcionando en modo de compatibilidad, pero el flujo recomendado es UKM_CASE con gestión de casos y flujos de aprobación configurables.

Esto significa que si estás implementando S/4HANA y configuras la gestión de crédito como en ECC, técnicamente funciona pero no estás aprovechando las capacidades del nuevo modelo. Y si el consultor funcional no sabe la diferencia, el cliente acaba con un sistema que usa la transacción FD32 en S/4HANA porque "siempre lo hemos hecho así".

La ruta de configuración clásica va por OVA8 ( Define Automatic Credit Control ) donde se configura qué tipo de verificación se hace, en qué momento del flujo de ventas se ejecuta y qué bloqueo genera cuando se supera el límite. Esa configuración se combina con el límite y la categoría de riesgo del cliente en FD32 o UKM_BP según el sistema.

Hay una clase que lleva disponible desde SAP NetWeaver 2004 y que todavía hoy no está tan extendida como debería en los desarrollos ABAP del día a día: CL_SALV_TABLE. Si todavía estás usando REUSE_ALV_GRID_DISPLAY para mostrar informes, este tip es para ti.

La diferencia fundamental entre el ALV clásico de módulos de función y CL_SALV_TABLE es el modelo de diseño. Con los módulos de función clásicos tienes que construir el field catalog manualmente, gestionar el layout por separado y lidiar con una interfaz que mezcla configuración y presentación de forma bastante caótica. Con CL_SALV_TABLE tienes un modelo orientado a objetos donde cada aspecto del ALV — columnas, ordenación, filtros, funciones del toolbar — tiene su propio objeto con sus propios métodos.

CL_SALV_TABLE sigue siendo hoy la clase más usada para mostrar grids ALV bidimensionales simples en ABAP. Y la razón es que con diez líneas de código tienes un ALV completamente funcional:

Pero donde CL_SALV_TABLE se pone interesante de verdad es cuando necesitas personalizar columnas específicas sin tocar el resto:

Cada columna tiene su propio objeto con métodos para visibilidad, textos, tipos de dato, colores y mucho más. Sin montar un field catalog de cincuenta líneas. Sin estructuras auxiliares. Solo métodos encadenados sobre el objeto de la columna que necesitas modificar.

Un detalle importante para quien lo usa por primera vez: CL_SALV_TABLE no soporta celdas editables directamente. Si necesitas editar celdas en el ALV, necesitas CL_GUI_ALV_GRID que sí permite edición. CL_SALV_TABLE es para display de solo lectura pero con capacidad de ordenación, filtrado y exportación que el usuario puede usar desde el toolbar estándar.

Hay una responsabilidad que los responsables de equipo en proyectos SAP asumen muy pocas veces de forma consciente, la de integrar bien a quien acaba de llegar. No porque sean malas personas. Sino porque el proyecto sigue, los tickets no esperan y la incorporación de alguien nuevo siempre llega en un momento en que nadie tiene tiempo para nada extra.

Y sin embargo lo que ocurre en los primeros días de alguien en tu equipo tiene más impacto en su rendimiento a largo plazo que cualquier formación o revisión de desempeño posterior. No es una impresión. Las empresas tienen una ventana media de 44 días para influir en la retención a largo plazo, siendo la primera semana el período más crítico. Lo que esa persona experimenta en sus primeros días decide en gran medida si va a comprometerse con el equipo o va a estar mirando hacia fuera desde el principio.

El error más habitual que veo en proyectos SAP cuando alguien nuevo se incorpora es darle accesos al sistema, asignarle los primeros tickets y esperar a que se integre solo. Eso funciona con perfiles muy senior que han pasado por muchos proyectos y saben moverse solos. Con el resto, genera una sensación de abandono que a veces se disimula pero que afecta directamente a la motivación y al tiempo que tarda esa persona en ser productiva de verdad.

Lo que sí funciona no requiere mucho tiempo. Requiere intención. Una conversación de media hora el primer día donde explicas no solo qué hace el proyecto sino cómo funciona el equipo, quién sabe de qué, cuáles son las dinámicas no escritas y qué esperas de esa persona en sus primeras semanas. No el manual de bienvenida corporativo. La versión real y directa de cómo funcionan las cosas aquí.

Asignar un compañero de referencia para las primeras semanas, no como mentor formal sino como "la persona a quien puedes preguntar lo que sea sin sentirte mal por no saberlo todavía", marca una diferencia enorme. Especialmente en proyectos SAP donde el contexto específico del sistema, del cliente y del equipo tarda semanas en asimilarse y donde hacer preguntas básicas delante de todos puede generar inseguridad innecesaria.

Y hay algo más que muy pocos responsables hacen y que tiene un impacto desproporcionado: revisar con la persona nueva al final de la primera semana cómo ha ido. No una evaluación formal. Una conversación corta y honesta. ¿Qué ha entendido? ¿Qué no tiene claro todavía? ¿Qué necesita para avanzar? Esa conversación no solo le da información útil a la persona nueva. También te da a ti información sobre lo que estás asumiendo que está claro y no lo está.

El consultor que se integra bien en las primeras semanas empieza a aportar valor antes. Y el que no se integra bien tarda más, genera más fricción y a veces se va antes de que hayas recuperado la inversión de haberle traído al proyecto.

Quince minutos el primer día y una conversación al final de la primera semana. No es mucho. Pero marca la diferencia entre alguien que siente que ha llegado a un equipo y alguien que siente que ha llegado a un proyecto donde nadie le esperaba

En consultoría SAP esto tiene una aplicación muy concreta. Dos consultores pueden mirar el mismo sistema, el mismo proceso, el mismo problema del cliente... y ver cosas completamente distintas. Uno ve una configuración incorrecta. El otro ve por qué alguien tomó esa decisión hace años y qué necesidades del negocio había detrás.

La diferencia no está en la experiencia técnica. Está en la capacidad de ir más allá de lo que hay en pantalla y entender el contexto real. Eso es lo que convierte un diagnóstico en una solución que funciona de verdad.

Y hasta aquí el boletín de esta semana.

Hoy hemos hablado de algo que muchas veces vemos todos los días… pero que no siempre analizamos con calma: cómo funciona realmente el ecosistema de consultoría alrededor de SAP.

Porque al final, detrás de cada proyecto, cada desarrollo o cada incidencia, también hay modelos de negocio, decisiones, estrategias y formas muy distintas de entender este mundo.

Y cuanto más tiempo pasas en él, más te das cuenta de que SAP no va solo de tecnología.

Va de personas, de procesos, de negocio… y muchas veces de saber adaptarse constantemente a cómo cambia todo.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta pequeña comunidad donde intentamos hablar de SAP de una forma un poco más cercana y real.

La semana que viene volveremos con más historias de proyectos, algún tema interesante y seguramente otra de esas situaciones que todos hemos vivido alguna vez trabajando en este ecosistema.

Nos leemos en el próximo boletín 👋

Envíame un correo sobre un tema que quieras que salga en la newsletter a [email protected] o contesta a este email.