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

Hay una parte del ecosistema SAP que poca gente del mundo de la consultoría privada conoce de cerca pero que lleva décadas funcionando en silencio y es la administración pública española.

SAP se implantó en las empresas privadas desde sus inicios y posteriormente, a principios de los años 2000 en la administración pública. Y desde entonces ha ido creciendo de forma discreta pero sólida. El Ayuntamiento de Madrid, la Generalitat de Catalunya y el Ministerio de Justicia son tres de las administraciones que utilizan SAP en España.

Docenas de oficinas, despachos judiciales, ministeriales, registrales y de funcionariado público en general gestionan sus encargos mediante este sistema. Los trabajadores y funcionarios administrativos españoles se capacitan periódicamente en el uso y manejo del sistema para desempeñar sus roles.

Y aquí viene el dato que más me llama la atención: la administración pública no busca rentabilidad económica. No hay un CFO mirando el P&L cada trimestre. No hay un accionista exigiendo resultados. El objetivo es prestar un servicio al ciudadano con el dinero de todos, cumpliendo con una regulación que no existe en ninguna empresa privada y con unos tiempos de decisión que harían enloquecer a cualquier project manager acostumbrado al sector privado.

Y sin embargo SAP funciona ahí. Con sus módulos, sus transportes, sus órdenes de transporte, sus transacciones y sus tickets. Exactamente igual que en una fábrica de Tarragona o en una multinacional de Madrid. La herramienta es la misma. El contexto es completamente distinto.

Curioso, ¿verdad? Uno de los sistemas más potentes del mundo empresarial lleva más de veinte años gestionando el dinero público de los españoles. Y la mayoría de los consultores SAP nunca han trabajado en ese entorno.

Hay una parte del ecosistema SAP que los que trabajamos en proyectos de back-office tendemos a ignorar bastante: la capa de punto de venta. SAP Customer Checkout lleva años siendo la solución de SAP para retail, hostelería y distribución en el punto de venta físico. Y esta semana acaba de anunciar una alianza con Viva que tiene más implicaciones de las que parece a primera vista.

Viva.com es el primer banco tecnológico europeo para empresas, activo en 29 países, con una propuesta centrada en pagos omnicanal integrados con servicios bancarios en una única plataforma. Lo que han construido juntos con SAP Customer Checkout es una integración que convierte cualquier dispositivo Android — terminales fijos, móviles, cajas de autoservicio, handheld — o iPhone en un terminal de pago seguro. Sin hardware dedicado. Sin contrato con un proveedor de datáfonos separado. Sin fricción entre el sistema de caja y el sistema de cobro.

La tecnología que hace posible esto es lo que Viva llama Tap on Any Device: el cliente paga tocando su tarjeta o su móvil directamente sobre el dispositivo del comerciante. Soporta más de 40 métodos de pago, pagos offline para cuando la conexión falla, DCC para transacciones en moneda extranjera y liquidación en tiempo real los 365 días del año. Para un comercio que hoy tiene un sistema de caja por un lado y un datáfono de otro banco por otro, con dos contratos distintos y una conciliación manual al cierre del día, esto simplifica bastante el día a día.

Lo que técnicamente hace posible la integración son las Open API de SAP Customer Checkout combinadas con el Terminal Integration Hub de Viva.com. La comunicación entre el POS y el terminal de pago va cifrada por HTTPS, con un plugin dedicado que simplifica la conexión y elimina la necesidad de desarrollo custom. Tres opciones de integración distintas según las necesidades del comercio, lo que da flexibilidad para adaptarse a distintos tamaños y configuraciones de tienda.

Hay un detalle en el artículo que me parece relevante para cualquier consultor o partner que trabaje con clientes en retail, consumo o hostelería: SAP Customer Checkout está diseñado para ser independiente del hardware desde el principio. Eso hace que alianzas como esta sean relativamente rápidas de implementar y fáciles de extender a nuevos países. Los 29 mercados europeos en los que opera Viva.com dan un alcance considerable para cualquier cliente de SAP con operaciones multinacionales en retail.

No es la noticia más llamativa de la semana en el ecosistema SAP. Pero para quien tiene clientes con punto de venta físico, es exactamente el tipo de integración que reduce fricción operativa sin requerir un proyecto de meses para implementarlo

Quedan dos semanas para que SAP publique sus resultados del segundo trimestre de 2026 y el mercado lleva instalado en modo espera desde hace más tiempo del que debería. La cotización de SAP en Fráncfort se mueve esta semana en torno a los 135-140€, con un rango de 52 semanas entre 130,62€ y 269,35€ que dice mucho sobre lo que ha sido este año para la acción.

El dato más llamativo sigue siendo ese. SAP ha caído un 46,43% en el último año. La empresa más grande de software de Europa, que sigue ganando dinero, que sigue creciendo en cloud, que acaba de cerrar Sapphire 2026 con anuncios potentes... ha perdido prácticamente la mitad de su valor bursátil en doce meses. Cuando lo dices así, de golpe, suena a catástrofe. Cuando miras los fundamentales, suena más a mercado siendo mercado.

¿Qué está pasando exactamente? Tres factores principalmente. El primero es el ritmo de transición al cloud, que no está siendo tan explosivo como los inversores esperaban cuando la acción cotizaba a 269€. El segundo es la investigación antimonopolio de la UE, que genera incertidumbre regulatoria aunque SAP ya haya ofrecido concesiones. Y el tercero es el contexto macro: cuando los flujos de capital se van hacia las grandes tecnológicas americanas de IA, el software empresarial europeo sufre aunque los fundamentales aguanten.

Y sin embargo los analistas siguen viendo la acción como oportunidad. El precio objetivo medio a 12 meses para SAP es de 214,81€, con una estimación alta de 290€. Eso supone multiplicar por 1,5 el precio actual en el escenario medio. El PER actual de 21 es razonable para una empresa de su perfil. Y las ganancias por acción del último trimestre superaron las estimaciones en un 4,66%.

Todo eso se va a poner a prueba el 23 de julio. Si los resultados del Q2 muestran aceleración en cloud y la guía para el resto del año es positiva, el mercado tiene mucho margen de recuperación desde estos niveles. Si decepcionan de nuevo... el mínimo de 52 semanas en 130,62€ va a parecer menos suelo y más escalón.

Dos semanas. Mientras tanto, SAP sigue cerrando alianzas, lanzando productos y diciendo que en cuatro años no habrá programadores. El mercado escucha y no termina de decidir si eso es bueno o malo. Clásico. 😄

⚠️ Puramente informativo. No es consejo de inversión. Soy consultor SAP, no gestor de fondos.

Voy a ser completamente transparente desde el principio como siempre jejejeje, no he trabajado directamente en proyectos SAP para la administración pública. Mi día a día son clientes privados, S/4HANA On-Premise, ABAP y las transacciones de siempre. Así que este artículo no va a ser el de alguien que ha vivido desde dentro lo que supone implementar SAP en un ayuntamiento o en un ministerio.

Pero sí he hablado con gente que lo ha hecho. Y lo que cuentan es suficientemente interesante como para dedicarle un boletín entero.

Lo primero que llama la atención cuando hablas con consultores que han trabajado en el sector público es que siempre usan la misma palabra para describir la experiencia, diferente. No mejor ni peor. Diferente. Y la diferencia no está en la tecnología. SAP es SAP. Los módulos son los mismos, las transacciones son las mismas, los transportes funcionan igual. Lo que cambia es absolutamente todo lo que rodea a la tecnología.

En una empresa privada, si el cliente necesita tomar una decisión de diseño, convocas una reunión, el responsable decide y sigues. En la administración pública esa misma decisión puede requerir un informe técnico, una aprobación por comité, una consulta jurídica para ver si la solución cumple con la normativa de contratación pública y a veces una resolución formal que tarda semanas. No porque nadie quiera hacerlo mal. Sino porque el dinero que se está gastando es público y la responsabilidad que conlleva gastarlo tiene un marco legal muy estricto que no existe en el sector privado.

La Ley de Contratos del Sector Público es probablemente la primera cosa que choca a un consultor SAP que llega de la empresa privada. En el sector privado, si el cliente quiere cambiar el alcance del proyecto, negocias un addendum y sigues. En el sector público, cambiar el alcance de un contrato que ya está licitado puede ser jurídicamente complicado o directamente imposible sin pasar por un proceso de modificación formal que tiene sus propios plazos y sus propias aprobaciones. Eso hace que el diseño inicial del proyecto tenga una importancia enorme. Porque lo que no se pensó bien al principio puede ser muy difícil de corregir después sin armar un lío burocrático considerable.

Y luego están los usuarios. En una empresa privada los usuarios son empleados de una organización que tiene una dirección que puede decirles que el sistema cambia y que hay que adaptarse. En la administración pública hay funcionarios con antigüedad, con derechos reconocidos, con una forma de trabajar que lleva décadas establecida y con una resistencia al cambio que es perfectamente legítima pero que hace la gestión del cambio mucho más compleja. No puedes simplemente decirle a un funcionario que lleva veinte años haciendo algo de una forma que a partir del lunes lo hace diferente porque el sistema nuevo lo requiere así. Hay que involucrar a los representantes sindicales, hay que dar plazos razonables, hay que justificar cada cambio. Y tiene su lógica, porque ese funcionario también tiene derechos.

Lo que más me sorprende cuando hablo con consultores que vienen del sector público es la sensación que tienen de trabajar con más restricciones pero también con más estabilidad. Los proyectos en la administración pública tienen plazos más largos, presupuestos más rígidos y procesos de aprobación más lentos. Pero también tienen una continuidad que en el sector privado no siempre existe. Un ministerio no cierra. Un ayuntamiento no desaparece. Y el sistema SAP que implementas va a estar ahí durante décadas, lo que da una perspectiva de largo plazo que pocos proyectos privados tienen.

¿Querría yo trabajar en ello? No lo sé. Nunca lo he hecho y sería injusto opinar como si lo supiera. Pero sí tengo claro que los consultores que dominan el sector público tienen un perfil muy específico, muy valioso y muy difícil de encontrar. Porque no basta con saber SAP. Hay que saber SAP y entender el marco publico, los tiempos administrativos, la gestión del cambio en organizaciones funcionariales y la lógica de un cliente cuyo objetivo no es ganar dinero sino prestar un servicio. Eso no lo aprende cualquiera en un proyecto.

¿Tú has trabajado en proyectos SAP en el sector público? ¿Cómo fue la experiencia comparada con el sector privado? Me encantaría leer vuestras historias porque es un mundo del que hay muy poco escrito con honestidad

Cuando empezaste a usar COND# y VALUE# para escribir código más limpio y compacto, probablemente te encontraste con una situación frustrante: necesitas calcular algo intermedio dentro de la expresión pero no quieres declarar una variable extra fuera de ella solo para ese uso puntual. Eso es exactamente lo que resuelve el operador LET.

LET permite declarar variables temporales dentro del propio contexto de una expresión COND#, VALUE# o SWITCH#. Esas variables solo existen dentro de esa expresión y no contaminan el scope del programa.

La diferencia no es solo estética. Al declarar la variable dentro del LET garantizas que ese valor intermedio no puede ser usado accidentalmente en otra parte del código. El scope está delimitado de forma explícita. Y el código comunica mejor su intención porque el cálculo intermedio vive exactamente donde se usa.

LET funciona dentro de COND#, VALUE#, SWITCH# y REDUCE#. En combinación con FOR también puedes usarlo para calcular valores derivados dentro de la construcción de una tabla interna.

En SAP PM hay dos grandes mundos que conviven en el mismo módulo y que tienen flujos, documentos y lógicas de planificación completamente distintos. Confundirlos en el diseño del proyecto genera un sistema que técnicamente funciona pero que el departamento de mantenimiento no usa como debería.

El mantenimiento correctivo es reactivo. Algo se rompe, alguien lo reporta, se genera un aviso, ese aviso se convierte en una orden de mantenimiento y se ejecuta el trabajo de reparación. La secuencia es aviso, orden, planificación de recursos, ejecución, confirmación de tiempos y materiales, cierre. Es el flujo más intuitivo y el que todo el mundo entiende desde el primer día.

El mantenimiento preventivo es completamente distinto porque es planificado. SAP genera las órdenes de mantenimiento de forma automática basándose en planes de mantenimiento configurados previamente, ya sea por tiempo, por contador o por una combinación de ambos. Un plan de mantenimiento por tiempo puede generar una orden cada tres meses para revisar un equipo. Un plan por contador puede generar una orden cada 1.000 horas de funcionamiento de una máquina. El sistema lleva el control de cuándo toca la siguiente intervención y genera la orden sin que nadie tenga que recordarlo.

Y aquí está el problema que veo más frecuentemente en proyectos de PM: el cliente tiene planes de mantenimiento preventivo configurados en SAP pero nadie los usa de verdad. Las órdenes se generan automáticamente y se cierran sin ejecutar porque el equipo de mantenimiento sigue usando su hoja de Excel de toda la vida para planificar las revisiones. ¿Por qué? Porque nadie se sentó con ellos a explicarles qué hace el sistema ni a adaptar los planes a la realidad de sus equipos y sus rutinas de trabajo.

La implementación técnica de PM puede ser perfecta y completamente inútil si el equipo de mantenimiento no adopta el flujo. Y esa adopción no se consigue con formación de dos horas en el go-live. Se consigue involucrando al equipo de mantenimiento desde el diseño, ajustando los planes preventivos a sus rutinas reales y demostrándoles que SAP les facilita el trabajo en lugar de complicárselo.

Hay desarrollos donde necesitas saber si el usuario que está ejecutando el programa tiene autorización para acceder a una transacción concreta, ya sea para mostrarle u ocultarle opciones de menú, para validar antes de lanzar una acción o para construir lógica de seguridad personalizada. La solución manual sería llamar a AUTHORITY-CHECK directamente con el objeto de autorización S_TCODE, pero hay una forma más directa y específica para transacciones.

La función devuelve 0 en SUBRC si el usuario tiene autorización para ejecutar esa transacción y un valor distinto de 0 si no la tiene. Sin necesidad de conocer los objetos de autorización específicos de cada transacción ni de construir la llamada a AUTHORITY-CHECK con todos sus parámetros.

Muy útil en desarrollos de menús dinámicos donde los botones o las opciones que ve el usuario dependen de sus autorizaciones reales, en programas que lanzan transacciones vía CALL TRANSACTION y quieren validar primero si el usuario puede ejecutarlas, y en desarrollos de auditoría donde necesitas registrar qué usuarios intentan acceder a funcionalidades para las que no tienen permiso.

Un matiz importante: esta función comprueba la autorización de objeto S_TCODE, que controla el acceso a la transacción como tal. Si la transacción tiene además controles de autorización adicionales dentro de su propia lógica, esos no los valida esta función. Es una validación del primer nivel de acceso, no una validación completa de todo lo que puede hacer el usuario dentro de esa transacción.

Hay una parte del catálogo de SAP que la mayoría de los consultores que trabajamos en el sector privado nunca hemos tocado y que sin embargo lleva décadas funcionando en ayuntamientos, ministerios y administraciones autonómicas de toda España. No son módulos de nicho ni desarrollos raros. Son soluciones específicas que SAP construyó precisamente porque la lógica financiera y presupuestaria del sector público no tiene nada que ver con la de una empresa privada.

El más importante y el que más aparece en proyectos de administración pública española es SAP PSM-FM: Public Sector Management - Funds Management. También conocido como SAP FM o SAP FI-FM, es técnicamente un submódulo de FI que viene desactivado por defecto y que hay que activar explícitamente. Su función es el control presupuestario: garantizar que ninguna unidad administrativa gasta más dinero del que tiene presupuestado para ese ejercicio. No es lo mismo que el CO clásico. Mientras que CO gestiona costes y rentabilidad desde una perspectiva de negocio, FM gestiona la ejecución del presupuesto público con una lógica completamente distinta: fondos, áreas funcionales, programas financiados y compromisos que tienen que cuadrar con lo que el Parlamento o el Pleno aprobaron para ese año.

Cuando en una administración pública alguien emite una orden de compra, FM verifica en tiempo real si hay presupuesto disponible antes de permitir la operación. Si no lo hay, la bloquea. No hay margen, no hay aproximación, no hay "ya lo regularizamos al cierre". El control puede ser estricto, blando o ausente según la parametrización, pero el concepto de que el gasto público tiene que estar autorizado antes de ejecutarse es la esencia de todo el módulo. Para un consultor FI acostumbrado al sector privado, donde la contabilización es principalmente registro de lo que ya ha ocurrido, esto supone un cambio de mentalidad considerable.

Dentro de PSM hay otros componentes que también merecen conocerse. SAP GM: Grants Management gestiona el ciclo de vida completo de las subvenciones y fondos externos, algo crítico para administraciones que reciben financiación europea o estatal condicionada a objetivos concretos. Datos maestros del otorgante, elegibilidad de cobertura, integración con FM para controlar que el gasto de cada subvención no supera lo que el otorgante ha aprobado para cada concepto y facturación al patrocinador. Un mundo completamente aparte del SD clásico aunque el concepto de facturar a alguien sea el mismo.

Y luego están los desarrollos específicos para España que SAP tiene certificados para el sector público español: el Grupo 0 del Plan General de Contabilidad Pública, la integración con la IGAE (Intervención General de la Administración del Estado), los formatos de firma electrónica para procesos económicos críticos y la gestión de estructuras orgánicas con Puestos de Trabajo, Vacantes y Escalafón que no tienen equivalente en el HCM clásico del sector privado.

¿Por qué importa esto para un consultor o un líder de proyecto? Porque si alguna vez tienes que diseñar o gestionar un proyecto en una administración pública y no sabes que PSM-FM existe, vas a intentar resolver la gestión presupuestaria con CO y desarrollos Z. Y eso, en palabras de los consultores que lo han vivido, es "comprarse problemas para el futuro". SAP tiene la herramienta. El problema es que muy poca gente del sector privado sabe que existe.

El consultor especializado en PSM-FM en España es un perfil escaso, muy demandado y con poca competencia. Si estás pensando en dónde diferenciarte dentro del ecosistema SAP... ahí hay un hueco que la mayoría no ha visto todavía.

En el contexto de este boletín, donde hemos hablado de salarios, de lo que cobra el que pregunta vs el que no pregunta y de lo que vale realmente un consultor SAP, esta frase tiene una aplicación muy concreta.

Trabajar duro en SAP es relativamente fácil. Hay siempre un ticket más, un desarrollo más, una reunión más. El que trabaja más horas no siempre es el que más vale ni el que más cobra.

Trabajar inteligentemente en SAP es otra historia. Es saber cuándo decir no. Es documentar bien para no explicar lo mismo dos veces. Es aprender las herramientas que multiplican tu productividad en lugar de hacer a mano lo que el sistema ya puede hacer solo. Es conocer tu valor en el mercado y negociarlo en lugar de esperar a que alguien lo descubra por ti.

Y hacer las dos cosas a la vez, trabajar duro Y trabajar inteligentemente, es exactamente el perfil que el mercado SAP sigue sin tener suficiente.

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.