Cómo una empresa industrial eliminó el papel de sus aprobaciones de
compras en SAP

El documento sale de SAP MM, se exporta, se manda por correo,
alguien lo imprime, circula entre aprobadores… y en algún punto del
camino pierdes la trazabilidad.

En GROUPmee implantamos el Conector SAP Signaturit en una
compañía industrial que tenía ese problema con contratos, solicitudes
de compra y pedidos. Ahora el flujo de firma arranca solo desde SAP,
respeta las estrategias de liberación ya configuradas y actualiza el
estado automáticamente cuando está firmado.

Aquí está el caso completo

Antes de hablar de jornadas intensivas, guardias y atascos de las 15:00 en Madrid en julio, hay un dato histórico que muy poca gente conoce y que cambia completamente la perspectiva de todo esto.

En pleno siglo XVI, el rey Felipe II estableció a través de un Edicto Real una jornada de ocho horas de trabajo, firmando en 1593 la ley VI de Ordenanza de Instrucción en la que dictaba que los obreros trabajarían ocho horas al día, cuatro por la mañana y cuatro por la tarde, distribuyendo las horas según el tiempo más conveniente para evitar a los obreros el ardor del sol y permitirles el cuidado de su salud.

Léelo de nuevo. "Evitar a los obreros el ardor del sol." Felipe II, en 1593, ya estaba preocupado por el mismo problema que cualquier consultor SAP en Madrid en julio, que el calor no te mate antes de llegar a casa.

Eso no es exactamente la jornada intensiva moderna, pero es el primer antecedente documentado de adaptar el horario laboral al verano español. Y ocurrió durante la construcción del Monasterio de El Escorial, lo cual tiene su gracia: el monumento más grande del patrimonio histórico español se construyó con horario intensivo de verano.

Siglos después, el 3 de abril de 1919, tras una huelga de 44 días iniciada por el despido de varios trabajadores de una operadora eléctrica de Barcelona conocida como La Canadiense, el gobierno español firmó el decreto que fijaba la jornada laboral máxima de ocho horas diarias, convirtiéndose España en el primer país de Europa en establecerlo por ley.

Y de ahí hasta hoy: cien años después seguimos negociando cómo distribuir esas ocho horas para que el verano sea algo más llevadero. El problema del calor en España no ha cambiado demasiado desde Felipe II. Lo que ha cambiado es que ahora en lugar de construir monasterios hacemos tickets de SAP.

Hay casos de uso de IA en SAP que suenan bien en una presentación y casos que tienen números reales detrás. Este es de los segundos, y merece atención porque el patrón que describe es exactamente replicable para cualquier empresa que tenga S/4HANA.

Natura &Co, el grupo brasileño de cosmética e higiene personal detrás de marcas como Natura y Avon, ha construido junto a SAP y el partner Numen una aplicación de IA generativa embebida directamente en sus flujos financieros de S/4HANA para analizar en tiempo real qué factores de ingresos y costes están protegiendo o erosionando el margen bruto de la compañía en cada mercado y línea de producto.

El problema que resolvían era uno que cualquier controller reconocerá al instante: para entender en tiempo real qué factores de ingresos y costes estaban erosionando el margen bruto, el equipo financiero dependía de reporting manual, insights con retraso y tiempo del equipo dedicado a recopilar datos en lugar de analizarlos.

La arquitectura técnica que construyeron es lo más interesante para cualquier consultor técnico o funcional que esté leyendo esto. La aplicación conecta directamente con los datos de SAP S/4HANA a través de la capa SAP AI Core, integrando el análisis de márgenes con un modelo de lenguaje grande para proporcionar al equipo financiero insights automatizados y recomendaciones narrativas en tiempo real, sin necesidad de extracciones manuales de datos ni reporting offline.

Hay dos detalles del proyecto que me parecen especialmente relevantes y que no suelen aparecer en los comunicados de éxito habituales.

El primero es el origen. La solución derivó de un prototipo que el partner Numen creó a principios de 2024 en el Hack2Build global de SAP sobre IA de negocio. Es decir, empezó en un hackathon. No en un proyecto millonario con meses de planificación previa. Una prueba de concepto que alguien vio que funcionaba y que se convirtió en algo real.

El segundo es el plazo. El proyecto completo, desde la idea hasta producción, se completó en un sprint de co-innovación de seis meses y entró en funcionamiento en agosto de 2025. Seis meses. De prototipo a producción. En un entorno financiero de una multinacional con operaciones en varios países.

Y el tercer punto que merece atención, porque los consultores funcionales de FI y CO lo van a entender perfectamente: durante el proyecto se identificaron mejoras necesarias en la calidad de los datos maestros, especialmente en Incoterms. Lo de siempre. La IA no falla por los modelos. Falla por los datos. Y eso lo llevamos diciendo en este boletín desde que empezamos a hablar de inteligencia artificial.

Lo que viene después también merece mencionarse. Natura &Co ya está planificando la siguiente fase: integrar Joule Agents para automatizar la extracción de contenido analítico estándar y profundizar en la optimización de procesos financieros impulsada por IA.

El patrón que describe este caso es exactamente el que SAP lleva meses recomendando y que aquí se ve funcionando de verdad: empieza con un proceso de negocio concreto y bien definido, embebe la IA directamente en los flujos existentes, mantén supervisión humana desde el diseño y escala desde ahí. Sin grandes promesas. Sin proyectos faraónicos. Con seis meses y un equipo enfocado.

El mercado está en modo espera con SAP esta semana. Y cuando el mercado espera... normalmente es porque algo importante está a punto de pasar.

A día 8 de julio de 2026, la cotización de SAP en Fráncfort se sitúa en 140,66€, con un rango diario entre 140,65€ y 142,73€ y un rango de 52 semanas entre 130,62€ y 269,35€. La acción sigue moviéndose en la parte baja de su rango anual, muy lejos de los máximos que veíamos hace menos de un año.

El dato que más llama la atención esta semana no es el precio en sí. Es la fecha que todo el mundo tiene marcada en el calendario: SAP presenta su informe de resultados el 23 de julio de 2026. Y eso lo cambia todo en términos de comportamiento del mercado. Los inversores no quieren apostar fuerte en ninguna dirección antes de ver los números reales. De ahí la calma aparente.

¿Qué se espera para ese día? Las ganancias estimadas para el próximo trimestre son de 1,77 euros por acción, con una previsión de EPS para el ejercicio completo de 2026 de 8,35 dólares y un enfoque continuo en la expansión del cloud. Los fundamentales aguantan, el cloud crece, pero el mercado sigue sin perdonar el ritmo. Las acciones cotizan cerca de su mínimo de 52 semanas, con una caída del 41% en seis meses, aunque un PEG de 0,19 sugiere una potencial infravaloración según algunos analistas.

Traducido al cristiano: SAP está barata en términos históricos según los modelos de valoración. Pero el mercado no compra barato cuando hay incertidumbre. Y hay incertidumbre hasta que el 23 de julio alguien abra el sobre y lea los números reales.

El precio objetivo medio a 12 meses que los analistas dan a SAP es de 214€, con una estimación alta de 290€ y una estimación baja de 154,99€. El escenario más optimista multiplica por dos el precio actual. El más pesimista está prácticamente donde estamos ahora. Amplio abanico, lo cual dice bastante sobre el grado de consenso que hay en el mercado con SAP en este momento.

El 23 de julio va a ser un día interesante. Y si los resultados sorprenden al alza... puede que la acción recuerde que alguna vez cotizó a 269€ y decida que igual no estaba tan equivocada. O puede que no. Eso es la bolsa.

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

Llega julio. El sol aprieta. Y en los grupos de WhatsApp de trabajo empieza a circular el mensaje de rigor: "Recordad que desde mañana jornada intensiva."

Y aquí es donde el ecosistema SAP se divide en dos bandos perfectamente definidos: los que sonríen y los que no saben muy bien de qué están hablando los demás. Porque no todos los consultores tienen jornada intensiva en verano. Y los que la tienen, tampoco la tienen igual.

Vamos a hablar de esto con toda la honestidad del mundo.

La jornada intensiva es una reducción del horario laboral diario que se aplica durante un período concreto del año, habitualmente en verano, concentrando toda la jornada en las horas de la mañana. En la mayoría de las empresas esto significa entrar a las 8:00 o 9:00 y salir a las 15:00, sin pausa para comer o con una pausa mínima.

Y aquí viene el primer matiz importante que muy poca gente explica bien: la jornada intensiva no es un regalo de la empresa. Es un intercambio. Durante el resto del año trabajas algo más de lo que te correspondería en jornada normal para acumular esas horas que luego disfrutas en verano. Es tiempo tuyo que vas pagando poquito a poquito durante meses para luego cobrarlo de golpe en julio y agosto.

Así que cuando alguien dice "qué bien que tienes jornada intensiva" la respuesta correcta sería: "Sí, gracias, llevo desde octubre cargando con ello."

Y aquí es donde las cosas se ponen interesantes porque no hay un solo modelo. Ni mucho menos.

La jornada intensiva nivel funcionario

Esta es la modalidad que todo el mundo envidia. De 8:00 a 15:00 desde el 15 de junio hasta el 15 de septiembre. Tres meses prácticamente completos. El consultor que tiene esto llega a la oficina cuando los pájaros todavía están desayunando, resuelve tickets, atiende reuniones y a las 14:55 ya tiene el bolso en la mano.

La vida con este horario es maravillosa en teoría. En la práctica tiene sus matices. La reunión de las 14:30 que se alarga. El cliente que manda un email urgente a las 14:45. El compañero que dice "¿tienes un momento?" a las 14:50. Y el clásico: sales a las 15:05 con la sensación de haber saltado por la ventana y te metes en el atasco de Madrid a las 15:10.

Porque seamos honestos: en Madrid en agosto, salir a las 15:00 no significa llegar a casa a las 15:30. Significa llegar a casa a las 17:00, derretido, con el aire acondicionado del coche echando un aliento caliente los primeros cinco minutos y jurando que el año que viene te compras una bici. 😅

La jornada intensiva por guardias

Esta es la que conoce bien cualquier consultor que haya trabajado en mantenimiento. No hay horario reducido como tal, pero hay rotación. Una semana eres tú el que está de guardia y el teléfono puede sonar a cualquier hora. La siguiente semana es otro y tú respiras.

El sistema de guardias tiene su lógica y cuando está bien organizado funciona razonablemente bien. El problema es cuando no está bien organizado, que es más habitual de lo que debería. Cuando la guardia la lleva siempre el mismo porque es el que más sabe. Cuando el cliente llama a las 22:00 por algo que podría perfectamente esperar a mañana. O cuando hay una incidencia crítica en producción el viernes por la tarde y tú estabas literalmente a punto de salir por la puerta.

Todo el mundo que ha trabajado en mantenimiento tiene su historia de guardia. La incidencia del viernes a las 17:55. El sistema caído un domingo por la mañana. El usuario que no sabía que había guardia pero llamó igualmente porque "total, sois informáticos y siempre estáis conectados." 😅

La jornada intensiva de un mes

El modelo más habitual en muchas consultoras medianas. Te dan julio o agosto de jornada intensiva, que sobre el papel suena a un mes entero saliendo a las 15:00. En la práctica, entre las vacaciones que la mayoría coge en ese mes y los días sueltos que se van acumulando, el disfrute real es considerablemente menor de lo que parece.

Matemáticamente: si tienes jornada intensiva en agosto y te tomas tres semanas de vacaciones en agosto, la jornada intensiva real que disfrutas son aproximadamente cinco días laborables. Que tampoco está mal, la verdad. 😄

Pero claro, la idea es montártelo bien, si te vas en agosto de vacaciones, amig@… píllate la jornada intensiva en Julio y así vas relajadito a tus vacaciones de Agosto y si lo haces al revés.. pues ya sabes, no tengo mucho que explicarte

Y luego están ellos. Los que en julio siguen entrando a las 9:00 y saliendo a las 18:00 o las 19:00 como cualquier otro mes del año. Sin reducción de horario, sin salidas tempranas, sin ese momento de las 15:00 en que el sol todavía pega fuerte pero al menos tú ya estás en la calle.

¿Por qué pasa esto? Hay varias razones y ninguna especialmente satisfactoria.

La más habitual en consultoría SAP es el cliente. Si el cliente no tiene jornada intensiva, muchas veces el consultor tampoco la tiene aunque su empresa sí la contemple. La dinámica de estar en las instalaciones del cliente o de tener que estar disponible en su horario puede complicar mucho aplicar un horario reducido aunque contractualmente te corresponda.

Otra razón es el tipo de proyecto. Si estás en la fase caliente de un go-live que está planificado para septiembre, la jornada intensiva de agosto existe en el papel y no existe en la práctica. Porque alguien, en algún momento de la planificación del proyecto, decidió que septiembre era una fecha razonable para el go-live sin pensar demasiado en que el equipo lleva meses acumulando horas y agosto iba a ser la última oportunidad de respirar.

Y luego está el caso del consultor en una empresa cliente, no en una consultora, cuya empresa tiene sus propias normas. Si trabajas en una fábrica que cierra en agosto, tú te vas de vacaciones en agosto y el resto del año trabajas como siempre. Sin guardias, sin clientes, sin tickets urgentes. Que tampoco está tan mal.

La respuesta honesta es: depende de cuánto estás dispuesto a pagar por ella durante el resto del año.

Porque la jornada intensiva tiene un coste que no siempre se ve en el contrato. Son esos días en que sales veinte minutos más tarde de lo que te corresponde. Son las tardes en que el cliente tiene una reunión a las 17:30 y vas aunque no toca. Son los viernes que se alargan media hora porque hay algo urgente. Ese tiempo se acumula y es el que luego se convierte en la jornada intensiva de julio.

Hay consultores que tienen claro que ese intercambio les renta. Salir a las 15:00 en verano, llegar a casa con sol, tener las tardes libres durante dos meses... para muchas personas eso vale perfectamente lo que cuesta durante el año.

Y hay consultores que prefieren otro modelo. Trabajar sus horas exactas durante todo el año, sin acumular nada, sin dar más de lo que toca, y en verano seguir en el mismo horario de siempre sin el beneficio del horario reducido pero también sin la deuda de horas previa.

Ninguno de los dos está equivocado. Depende de cómo vives el trabajo, de qué valoras más y de cuánto calor hace en tu ciudad en agosto. Porque si trabajas desde casa con aire acondicionado y en agosto tampoco tienes planes especiales... la jornada intensiva pierde bastante atractivo. 😄

Y si trabajas en Madrid y sales a las 15:00 para meterte en el atasco de la A-6 con treinta y ocho grados... bueno, al menos llegas a casa con el día por delante. O eso te dices para consolarte mientras esperas que el coche se enfríe.

Hay desarrollos donde necesitas saber el valor máximo o mínimo que puede tener un tipo numérico, ya sea para inicializar acumuladores, para detectar desbordamientos o para validar rangos. Y la solución más habitual que se ve en el código es hardcodear ese valor directamente. Algo del estilo de lv_max = 9999999999. Que funciona hasta que el tipo cambia, o hasta que alguien lo usa en un contexto diferente y el valor hardcodeado ya no es correcto.

CL_ABAP_EXCEPTIONAL_VALUES resuelve exactamente eso. Devuelve los valores límite de cualquier tipo numérico ABAP de forma dinámica, sin hardcodear nada, en tiempo de ejecución.

El resultado es el valor máximo y mínimo exacto del tipo I de ABAP, calculado en tiempo de ejecución sin que tú tengas que saber ni escribir el número.

Funciona con cualquier tipo numérico: I, INT8, F, DECFLOAT16, DECFLOAT34... Lo que necesites. Y al combinarlo con CL_ABAP_TYPEDESCR para obtener el descriptor del tipo puedes construir validaciones genéricas que funcionen independientemente del tipo concreto con el que estés trabajando en cada momento.

Hay una conversación que ocurre en casi todos los proyectos con módulo FI en los primeros cierres mensuales. El controller abre la lista de partidas abiertas y ve docenas de posiciones que deberían estar compensadas pero no lo están. El equipo de contabilidad lleva días compensando manualmente. Y alguien pregunta: ¿no puede hacer esto SAP solo?

La respuesta es sí. Pero requiere que alguien lo haya configurado bien antes.

En SAP FI hay dos formas de compensar partidas abiertas. La compensación manual, que hace el usuario partida a partida o en grupo a través de transacciones como F-32 para clientes o F-44 para proveedores, y la compensación automática, que ejecuta el sistema a través de la transacción F.13 usando reglas previamente definidas que determinan qué partidas se pueden compensar entre sí de forma automática.

Las reglas de compensación automática son el núcleo de todo esto. Se configuran por tipo de cuenta y por cuenta contable, y definen qué campos tienen que coincidir entre las partidas para que el sistema las considere compensables. Por ejemplo para cuentas de clientes puedes definir que el sistema compense automáticamente todas las partidas que tengan el mismo número de referencia, o el mismo número de factura, o la misma asignación. Si los campos coinciden, F.13 las agrupa y las compensa sin intervención humana.

El error más habitual en proyectos es no configurar esas reglas antes del go-live o configurarlas de forma demasiado genérica. Si el criterio de compensación no está alineado con cómo el equipo de contabilidad identifica realmente qué facturas corresponden a qué pagos, la compensación automática no funciona o compensa partidas incorrectas, lo que es peor que no compensar nada. Y cuando llega el cierre mensual con cientos o miles de partidas abiertas acumuladas... el trabajo manual que genera es enorme.

Pequeña, discreta y muy útil en contextos específicos. STRING_CENTER toma una cadena de texto y la centra dentro de un campo de longitud fija rellenando con espacios a izquierda y derecha de forma automática.

Puede parecer trivial. Y para la mayoría de desarrollos modernos donde el formato lo gestiona Fiori o un framework de presentación, lo es. Pero en contextos donde todavía se trabaja con salidas de texto plano, impresión de etiquetas, generación de ficheros con formato fijo para intercambio con sistemas legacy o desarrollos de SAPscript clásico, centrar texto manualmente implica calcular la longitud del string, restar, dividir entre dos y rellenar con espacios. Exactamente lo que hace esta función en una sola llamada.

Una alternativa en ABAP moderno para casos sencillos es usar string templates con padding, pero STRING_CENTER sigue siendo la opción más directa cuando necesitas el resultado en una variable de longitud fija específica y no quieres gestionar el cálculo de espacios tú mismo.

Hay una conversación que ocurre en todos los equipos SAP cada año, sin excepción, aproximadamente en la segunda semana de junio. Alguien pregunta cuándo empieza la jornada intensiva, alguien más pregunta quién cubre las guardias en agosto, y el responsable del equipo se da cuenta de que no ha pensado en nada de esto todavía.

Y ahí es donde empieza el problema. Porque la gestión del verano en un equipo de consultoría SAP no es un trámite administrativo de RRHH. Es una decisión de liderazgo que afecta directamente al rendimiento del equipo, a la calidad del servicio al cliente y al estado de ánimo de personas que llevan meses trabajando duro y que necesitan desconectar de verdad.

Muchos responsables de equipo gestionan las vacaciones de verano como un puzzle. Quién puede irse cuándo, quién cubre a quién, cómo se garantiza que siempre haya alguien disponible. Y ese enfoque, aunque tiene su lógica operativa, pierde de vista algo importante: las vacaciones no son un problema que hay que resolver. Son un derecho que hay que facilitar.

La diferencia entre los dos enfoques es sutil pero tiene consecuencias muy reales. Un equipo donde las vacaciones se gestionan como un problema logístico acaba con personas que se van de vacaciones sintiéndose culpables, que revisan el correo desde la playa porque nadie les ha dicho explícitamente que no tienen que hacerlo, y que vuelven en septiembre tan cansados como cuando se fueron.

Un equipo donde las vacaciones se gestionan como un derecho a facilitar tiene cobertura planificada con tiempo, acuerdos claros sobre quién atiende qué en ausencia de cada persona y una cultura donde desconectar de verdad está permitido y es esperado.

La guardia de verano es la parte más delicada de gestionar en equipos de mantenimiento SAP. Cuando hay sistemas en producción que no se detienen porque sea agosto, alguien tiene que estar disponible. Eso es inevitable. Pero cómo se organiza esa disponibilidad dice mucho del tipo de líder que eres.

Lo mínimo que tiene que estar claro antes de que empiece el verano es quién cubre qué semanas, cuál es el canal de contacto real en caso de incidencia crítica y qué nivel de respuesta se espera según la criticidad del problema. No es lo mismo una incidencia que para la facturación de un cliente que un aviso de un informe que puede esperar al lunes.

Sin eso definido por escrito, lo que ocurre invariablemente es que la guardia informal la acaba llevando siempre la misma persona, que es la que más sabe, que es la que menos puede permitirse estar desconectada, que es exactamente la que más necesita descansar. Y esa persona llega a septiembre quemada, resentida y actualizando el perfil de LinkedIn.

Hay algo que muchos responsables dan por supuesto y que no debería darse por supuesto: que todo el equipo tiene las mismas condiciones de jornada intensiva. Y como hemos visto, eso no es así. Hay personas con jornada intensiva larga, personas con un mes, personas con guardias y personas sin ningún tipo de reducción de horario.

Cuando esas diferencias existen dentro del mismo equipo y no se hablan abiertamente, generan tensión silenciosa. El que sale a las 15:00 siente que los que se quedan le juzgan. El que se queda hasta las 18:00 siente que le están tratando de forma injusta aunque la diferencia venga de sus propias condiciones contractuales. Y el responsable que no ha tenido esa conversación se pregunta por qué el ambiente del equipo en verano siempre es raro.

La solución es más sencilla de lo que parece: hablar de ello con normalidad. Explicar qué condiciones tiene cada persona, por qué son distintas si lo son y qué implica eso en términos de disponibilidad y cobertura. Sin misterios ni suposiciones.

No es el que monta el cuadrante de guardias más elaborado de la historia. Es el que consigue que su equipo llegue a septiembre habiendo descansado de verdad, sin incidentes graves sin atender y sin resentimientos acumulados por una distribución de carga que alguien sintió como injusta.

Eso requiere planificación con tiempo, conversaciones directas y una cosa que cuesta más de lo que parece: confiar en que el equipo va a responder cuando haga falta sin necesidad de estar todos disponibles todo el tiempo.

El verano es la prueba de fuego de la cultura de un equipo. Los que han construido confianza durante el año llegan a agosto con todo organizado y descansando bien. Los que no la han construido llegan a agosto con el teléfono encendido y la sensación de que si se desconectan cinco minutos algo va a explotar.

Y casi nunca explota nada. Casi nunca.

Y no lo digo solo como consejo de bienestar. Lo digo porque en la consultoría SAP hay una tendencia muy arraigada a confundir estar disponible con estar rindiendo. El consultor que no desconecta en verano no es más comprometido. Es el que va a llegar a septiembre con medio cerebro funcionando y el otro medio pensando en la playa que no pisó.

Descansa de verdad cuando puedas. El sistema productivo va a seguir ahí cuando vuelvas. Y los tickets también, por desgracia.

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.