El empleado medio dedica unas 11,3 horas a la semana a reuniones, y no todas ellas se consideran productivas. En la consultoría SAP ese número probablemente es más alto, no más bajo. Porque en un proyecto SAP hay reuniones para arrancar, reuniones para avanzar, reuniones para revisar lo que se hizo en la reunión anterior y reuniones para decidir cuándo es la próxima reunión.

Y los datos sobre lo que ocurre en esas reuniones son demoledores. El 92% de los empleados está de acuerdo en que las reuniones a menudo no son productivas, y hasta un 67% considera que más de la mitad de las reuniones a las que asisten son inútiles.

Pero lo que más me llama la atención no es ese porcentaje. Es esto: el tiempo perdido en reuniones improductivas se ha duplicado desde 2019 hasta alcanzar las 5 horas semanales. Cinco horas. En un proyecto de cuatro meses eso son ochenta horas de consultor sentado en reuniones que no llevan a ningún sitio. Ochenta horas que podrían haber sido desarrollo, documentación, formación a usuarios o simplemente trabajo real.

Y hay un dato más que define perfectamente la situación: el 48% afirma que su última reunión fue innecesaria, el 53% que fue una pérdida de tiempo y el 61% que se logró muy poco.

Nadie convoca una reunión pensando que va a ser inútil. Y sin embargo más de la mitad lo son. El problema no es la reunión como concepto. El problema es que en muchos proyectos la reunión se ha convertido en el sustituto de tomar decisiones, de documentar bien o de simplemente confiar en que el compañero va a hacer su parte sin que nadie le supervise en tiempo real.

Curioso que la herramienta diseñada para alinear equipos se haya convertido en la principal causa de desalineación del tiempo en los proyectos.

Todos hemos abierto un ticket de SAP Support en algún momento y hemos pensado lo mismo: ¿por dónde empiezo, qué canal uso, cómo escribo esto para que no me lo cierren sin resolver?

SAP acaba de publicar la edición 2026 de su curso de Support Accreditation, y esta vez vale la pena mencionarlo porque ha cambiado bastante respecto a versiones anteriores. El curso se ha rediseñado desde cero después de recoger feedback de más de 40.000 usuarios anteriores, y está disponible ahora mismo en la plataforma de aprendizaje de SAP de forma gratuita, bajo demanda y con una duración aproximada de 60 minutos.

¿Qué cubre exactamente? Joule en SAP for Me, búsqueda inteligente, soporte preventivo, matching automático de soluciones para incidencias, recomendadores de canal y predictores de prioridad para productos y funciones. Es decir, todo lo que ha cambiado en el soporte SAP con la llegada de la IA en los últimos dos años, explicado de forma práctica y orientada a resultados reales.

Lo que me parece más útil de este curso no es el badge digital que te llevas al terminar, aunque tampoco está mal para el perfil de LinkedIn. Es la parte de cómo escribir mejor los tickets para que el sistema de IA los enrute correctamente y las soluciones automáticas los resuelvan antes de que lleguen a un agente humano. Cualquier consultor que abra tickets de soporte con frecuencia sabe que la calidad de cómo se documenta el problema tiene un impacto enorme en la velocidad de resolución.

Sesenta minutos. Gratuito. Con badge. Para cualquier consultor, partner o cliente que trabaje con SAP Support de forma regular, parece un uso razonable de una mañana tranquila de agosto.

Semana muy diferente a todo lo que llevamos viendo en el año. A 11 de agosto de 2026, la cotización de SAP en Fráncfort se sitúa en 182,94€, con un rango diario entre 178,21€ y 183,27€ y un rango de 52 semanas entre 127,50€ y 248,35€.

El dato que más llama la atención esta semana es la velocidad de la recuperación. Las acciones de SAP han subido un 12,06% en comparación con la semana anterior y un 30,36% en el último mes. Treinta por ciento en un mes. Desde los mínimos de 127,50€ de hace unas semanas hasta los 183€ actuales hay una recuperación de más del 43%.

¿Qué ha pasado? La combinación de los resultados del Q2 mejor de lo esperado en términos de cloud, el rebote general de los mercados europeos de tecnología y el hecho de que la acción estaba claramente sobrecastigada respecto a sus fundamentales ha creado el caldo de cultivo perfecto para una recuperación rápida.

El precio objetivo medio a 12 meses de los analistas es de 201,49€, con una estimación alta de 290€ y una estimación baja de 154,99€. La próxima cita con los mercados es el 21 de octubre con los resultados del Q3. Hasta entonces, la pregunta es si esta recuperación tiene recorrido o si el mercado va a volver a dudar.

Lo que sí está claro es que quien compró en mínimos de 127€ tiene ahora una plusvalía del 43% en mes y medio. Y quien vendió en mínimos pensando que seguía bajando... bueno, esas historias también existen

Voy a decir algo que sé que va a generar debate: el problema de las reuniones en los proyectos SAP no es que haya demasiadas. Es que muy pocas de ellas tienen claro para qué sirven realmente.

He estado en proyectos donde el calendario estaba tan lleno que literalmente no había hueco para trabajar. Y he estado en proyectos donde las reuniones eran pocas, cortas y concretas, y el trabajo avanzaba el doble de rápido. La diferencia no estaba en el tamaño del proyecto ni en la complejidad del sistema. Estaba en si alguien había pensado qué tipo de reunión necesitaba cada momento del proyecto.

Porque en un proyecto SAP hay tipos de reunión muy distintos y cada uno tiene su lógica, su duración razonable y sus síntomas de cuando se está haciendo mal.

El kick-off es la reunión más importante del proyecto y la que más se infravalora. Es donde se alinean expectativas, se presentan los equipos, se explica el alcance y se establece cómo se va a trabajar. Cuando el kick-off es solo una presentación de PowerPoint donde el jefe de proyecto habla noventa minutos y nadie hace preguntas porque no hay espacio para ello... el proyecto ya tiene un problema antes de haber empezado. Un buen kick-off debería generar conversación real, no aplausos educados al final de las diapositivas.

Los talleres de diseño son el corazón técnico y funcional del proyecto. Ahí se toman las decisiones que van a definir cómo funciona el sistema durante años. Y por eso son también las reuniones donde más fácilmente se pierde el control. Una reunión que empieza como "vamos a definir el proceso de facturación" y dos horas después está debatiendo si el campo de referencia debe ser obligatorio o opcional en un caso de uso que afecta a cuatro pedidos al año... eso es un taller que no tiene facilitador. El consultor que sabe llevar un taller de diseño vale su peso en oro. El que deja que el taller derive hacia cualquier dirección que tome el cliente más vocal de la sala... va a tener muchos problemas en el diseño del sistema.

El steering committee es la reunión más formal y paradójicamente la que menos información real suele contener. El estado del proyecto en verde aunque no lo esté, los riesgos listados pero no gestionados, los hitos confirmados aunque el equipo sepa que la fecha es optimista. Cuando el steering committee es un teatro donde se muestra lo que el sponsor quiere ver en lugar de lo que está pasando de verdad, deja de ser útil y se convierte en un problema porque posterga conversaciones difíciles que luego estallan en el peor momento.

Las dailies o seguimientos de equipo son las reuniones más necesarias y las que más fácilmente se convierten en un ritual vacío. Una daily bien hecha dura quince minutos, identifica bloqueos reales y sirve para que el equipo se alinee. Una daily mal hecha es cada persona contando lo que hizo ayer mientras los demás miran el móvil esperando que acabe para volver a trabajar. La diferencia está en si hay alguien que escucha activamente lo que se dice y actúa cuando algo está bloqueado, o si es simplemente marcar el checkbox de "hemos hecho la daily".

Las reuniones de avance con usuario clave son donde más valor puede aportar un buen consultor funcional y donde más fácilmente se generan malentendidos. El usuario clave ve una pantalla y dice "esto no es lo que pedimos." El consultor sabe que sí es lo que se documentó. Y si esa conversación no se gestiona bien, con el acta en mano y con paciencia real, genera una tensión que contamina el resto del proyecto.

Y luego están las reuniones que nadie debería convocar pero que existen en todos los proyectos: la reunión para decidir cuándo es la próxima reunión. La reunión de "puesta al día" donde no hay nada concreto que decidir pero alguien necesita sentir que está al control. La reunión convocada por correo sin agenda donde todos llegan sin saber exactamente de qué va a ir. Y la clásica: la reunión de una hora que podría haber sido un correo de cinco líneas pero alguien prefiere "alinearse en persona."

No todas las reuniones son inútiles. Las hay absolutamente necesarias e irremplazables. Pero la diferencia entre un proyecto que avanza y uno que se arrastra suele estar en si las reuniones tienen dueño, tienen agenda, tienen duración razonable y terminan con decisiones o con acciones claras asignadas a personas concretas. Sin eso, son tiempo disfrazado de trabajo.

¿Cuál es la reunión más inútil que has tenido en un proyecto SAP? Sin nombres, claro.

Hay algo que confunde bastante a los ABAPers que vienen del mundo clásico cuando empiezan a trabajar con objetos: en la SE24 aparecen tanto clases como interfaces, tienen una estructura similar, las dos empiezan por CL_ o IF_ según la convención de nombres... y sin embargo son cosas fundamentalmente distintas.

Vamos a dejarlo claro de una vez.

Una clase es un objeto completo. Tiene definición y tiene implementación. Puedes instanciarla con CREATE OBJECT o con el operador NEW, sus métodos tienen código dentro y ese código hace algo concreto. Una clase existe por sí sola.

Una interfaz, en cambio, no tiene instancias. No se puede instanciar. No contiene implementación de ningún tipo. Solo contiene declaraciones: métodos con su firma (parámetros de entrada, salida, excepciones) pero sin una sola línea de código dentro. La interfaz es un contrato, no una implementación.

La pregunta natural es: ¿para qué sirve entonces? Para dos cosas muy concretas.

Primero, para garantizar que varias clases distintas exponen la misma firma pública. Si tienes clases que no están relacionadas por herencia pero que deben proporcionar los mismos servicios a sus consumidores, defines esos servicios en una interfaz. Así el programa que las usa tiene una única forma de llamar a esas funciones independientemente de qué clase está usando en cada momento. Es la base del polimorfismo en ABAP.

Segundo, para permitir herencia múltiple. En ABAP una clase solo puede heredar de una única clase padre. Pero puede implementar varias interfaces. Eso permite que una clase se comporte como varias "cosas" distintas dependiendo de qué interfaz está usando el consumidor en ese `pmomento.

La sintaxis es directa. Defines la interfaz con INTERFACE

Y cualquier clase que quiera "ser notificable" la implementa con INTERFACES en la sección pública y proporciona el código en la implementación:

El acceso a los componentes de la interfaz desde dentro de la clase usa la tilde: if_notificable~notificar. Eso es lo que indica que el método pertenece a la interfaz y no a la clase directamente.

¿Y cuándo lo ves en proyectos SAP reales? Constantemente. Interfaces como IF_SALV_EVENTS_ACTIONS para eventos del ALV, IF_BADI_INTERFACE como base de todos los BAdIs, IF_ABAP_BEHV como interfaz de comportamiento en RAP... En ABAP moderno las interfaces están en todas partes porque son la forma estándar de definir contratos entre componentes sin acoplarlos a implementaciones concretas.

La regla práctica para saber si estás ante una clase o una interfaz sin mirar el código: si empieza por CL_ es una clase, si empieza por IF_ es una interfaz. No hay excepciones en el catálogo estándar de SAP.

En SAP WM hay dos documentos que mucha gente confunde porque suenan parecido y están relacionados pero tienen roles completamente distintos: el requisito de traslado (Transfer Requirement, TR) y la orden de traslado (Transfer Order, TO). Entender bien la diferencia entre los dos y cuándo aparece cada uno es fundamental para diseñar bien el flujo de almacén.

El requisito de traslado es la señal de que algo tiene que moverse en el almacén. Es un documento que el sistema genera automáticamente cuando ocurre un movimiento de mercancía relevante para WM: una entrada de mercancía de un pedido de compra, una salida para una entrega de ventas, una transferencia entre almacenes. El TR dice qué hay que mover, de dónde y a dónde debería ir. Pero no ejecuta nada. No le dice a ningún operario que vaya a buscar nada. Es solo la necesidad expresada en el sistema.

La orden de traslado es el documento ejecutivo. Es lo que el operario recibe (en papel, en handheld o en pantalla) con las instrucciones concretas de dónde ir, qué coger y dónde dejarlo. La TO puede crearse de forma manual con la transacción LT01, de forma automática con referencia al TR, o de forma masiva para un grupo de entregas. Cuando el operario confirma la TO con LT12, el sistema actualiza el stock en las ubicaciones correspondientes.

El error clásico en proyectos WM: configurar el sistema para que genere los TRs automáticamente (lo cual es correcto) pero no configurar la creación automática de TOs. El resultado es que los TRs se acumulan sin que nadie los convierta en órdenes de traslado porque el equipo de almacén no sabe que tiene que entrar a LT0A para convertirlos. Los operarios siguen buscando papel porque el sistema "no les dice nada". Y el almacén funciona, pero funciona al margen de WM.

La ruta SPRO para configurar la creación automática de TOs es Logística → Ejecución de Logística → Gestión de Almacenes → Interfaces → Gestión de Inventario → Definir tipos de movimiento → Control de creación de TO. Ahí se define si la TO se crea automáticamente al contabilizar el movimiento de mercancía, de forma manual posterior o en diferido.

Hay una situación que todo ABAPER conoce. Un programa que procesa miles de registros, el usuario lo lanza y se queda mirando la pantalla sin que pase nada visible durante varios minutos. Llama al soporte. Dice que el sistema se ha colgado. No se ha colgado. Está trabajando. Pero nadie se lo ha dicho.

CL_PROGRESS_INDICATOR resuelve exactamente eso. Muestra en la barra de status de SAP GUI un mensaje de texto con el progreso actual, un porcentaje de completado y un indicador de reloj de arena que le dice al usuario que el sistema está vivo y procesando.

La ventaja de CL_PROGRESS_INDICATOR respecto al módulo de función clásico SAPGUI_PROGRESS_INDICATOR es que tiene integrado un control de frecuencia. Por defecto actualiza la barra máximo una vez cada diez segundos, evitando que las llamadas al indicador ralenticen el proceso más que el propio procesamiento. Con el parámetro I_OUTPUT_IMMEDIATELY puedes forzar la actualización inmediata cuando necesites más control.

El parámetro I_PROCESSED e I_TOTAL calculan automáticamente el porcentaje y muestran la barra de progreso proporcional. Si solo pasas I_TEXT sin los valores numéricos, muestra el texto sin barra de porcentaje, lo cual es útil cuando no conoces de antemano cuántos registros vas a procesar.

Una limitación importante: esta clase solo funciona en modo dialog, no en background. En jobs de background el indicador no tiene pantalla donde mostrarse. Para procesos en background la alternativa es escribir mensajes al job log con la función BAL_LOG o simplemente contar con que el usuario no va a ver el progreso.

Hay una habilidad que los buenos responsables de proyecto en SAP desarrollan con el tiempo y que casi nadie enseña explícitamente: saber cuándo no convocar una reunión.

Parece obvio. No lo es. Porque en los proyectos SAP hay una presión constante hacia la reunión como mecanismo de gestión. Cuando algo no avanza, se convoca una reunión. Cuando hay una duda, se convoca una reunión. Cuando el cliente está nervioso, se convoca una reunión. Y muchas veces esa reunión no resuelve el problema, lo aplaza con la sensación de que al menos "lo hemos puesto en común."

El test más sencillo antes de convocar cualquier reunión es responder tres preguntas en treinta segundos. Qué decisión o acción tiene que salir de esta reunión. Quién tiene que estar porque sin esa persona la reunión no puede terminar con esa decisión. Y cuánto tiempo necesito realmente para llegar a ese resultado. Si no puedes responder las tres preguntas, no tienes una reunión. Tienes una conversación que puede ser un email, un mensaje o un comentario en el ticket.

Cuando sí tienes claras las respuestas, la reunión tiene una estructura muy diferente a la habitual. Empieza con el objetivo explícito, no con "bueno, nos hemos reunido para..." sino con "al final de esta reunión necesitamos haber decidido X." Tiene una agenda con tiempos asignados a cada punto. Y termina con un acta de dos párrafos donde queda claro qué se ha decidido, quién hace qué y para cuándo. No el acta de diez páginas que nadie lee. Los dos párrafos que cualquiera puede consultar en dos minutos.

Hay dos tipos de reuniones en proyectos SAP donde los responsables suelen fallar de forma sistemática y que merecen mención especial.

La primera es el taller de diseño que se alarga sin control. Un taller que empieza a las nueve de la mañana y a las tres de la tarde todavía está debatiendo el tercer punto de los doce que había en la agenda no es un taller productivo, es un proyecto dentro del proyecto. El responsable que no sabe cortar esa dinámica, aparcar los puntos que no se pueden resolver en ese momento y cerrar con los acuerdos que sí se han alcanzado está desperdiciando el tiempo de todos los que están en la sala y generando fatiga de decisión que afecta a la calidad de lo que se decide en las últimas horas.

La segunda es el steering committee que se convierte en un teatro. Cuando el estado real del proyecto es amarillo o rojo y el steering se prepara para que parezca verde, el responsable está comprando tiempo a costa de credibilidad. La conversación difícil que no se tiene en el steering de marzo se tiene en el steering de mayo con mucho menos margen de maniobra. Un sponsor bien informado, aunque las noticias no sean buenas, puede ayudar. Un sponsor sorprendido por un problema que ya tenía semanas de antigüedad... no perdona eso fácilmente.

El liderazgo en las reuniones no consiste en hablar más que los demás. Consiste en hacer que en el tiempo acordado ocurra lo que tiene que ocurrir y que todos salgan sabiendo exactamente qué hacer a continuación. Eso es más difícil de lo que parece. Y es exactamente lo que diferencia a un project manager que gestiona reuniones de uno que gestiona proyectos.

Esta frase describe con una precisión quirúrgica lo que ocurre en al menos la mitad de las reuniones de cualquier proyecto SAP. El acta se redacta con detalle. Los participantes salen sin saber muy bien qué ha cambiado respecto a antes de entrar.

La buena noticia es que la reunión mala no es inevitable. Es una elección, la mayoría de las veces inconsciente, de no preparar, no facilitar y no cerrar con decisiones reales. Y eso, a diferencia de muchas cosas en los proyectos SAP, sí está en nuestra mano cambiarlo.

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.