¿Quieres enviar a firmar contratos y documentos de RRHH sin tener que salir de SAP?

En GROUPmee hemos desarrollado un conector que integra Signaturit directamente en tu SAP Successfactors. Envía, firma y archiva contratos sin salir del sistema. Más rapidez, más trazabilidad. 100% validez legal.

Cuando desarrollas en SAP, todos los objetos que creas empiezan por Z o por Y. Esos son los rangos que SAP reserva para el cliente. Pero hay algo que muy poca gente sabe: puedes solicitar a SAP un namespace propio y exclusivo, con la forma /TUNOMBRE/, y ese namespace es tuyo en todo el ecosistema SAP mundial.

Lo curioso es que registrar ese namespace no tiene coste económico directo. SAP lo gestiona, lo valida y te lo asigna. Sin pagar nada.

¿Y para qué sirve? Un namespace propio garantiza que los objetos que desarrollas sean de tu exclusiva propiedad dentro del ecosistema SAP, elimina cualquier riesgo de conflicto de nombres con otros desarrollos, y protege tu código frente a modificaciones no autorizadas por parte del cliente que lo recibe. Es decir, si distribuyes tu producto a cien clientes, ninguno puede tocar tu código salvo que tú les des explícitamente permiso para ello a través de una repair key.

El namespace tiene un máximo de 10 caracteres incluyendo las dos barras ( por ejemplo /MIEMPRS/ ) lo que significa que cuanto más corto, mejor, porque esos caracteres se descuentan del nombre total disponible para cada objeto.

La diferencia entre un desarrollo Z y un producto con namespace propio es exactamente esa: uno lo puede modificar cualquiera, el otro solo tú.

SAP vuelve a posicionarse como líder, esta vez en un terreno que cada vez va a ser más relevante en proyectos: la gestión del carbono.

Según el último informe de IDC MarketScape, SAP ha sido reconocida como líder en aplicaciones de carbon accounting and management. Es decir, soluciones orientadas a medir, gestionar y reportar las emisiones de carbono dentro de las empresas.

A primera vista puede parecer un tema lejano para muchos equipos SAP. Pero no lo es tanto.

Cada vez más empresas están obligadas a reportar información sobre sostenibilidad, emisiones y cumplimiento normativo. Y aquí es donde SAP está posicionando su estrategia: integrar estos datos directamente dentro de los procesos de negocio.

Lo interesante no es solo la herramienta, es el enfoque.

No se trata de tener un sistema paralelo que calcule emisiones. Se trata de integrar esa información dentro del ERP, vinculándola a compras, logística, producción o finanzas. Es decir, convertir la sostenibilidad en un dato más del proceso, no en algo externo.

Y esto cambia bastante el paradigma.

Porque igual que hoy analizas costes o márgenes, mañana tendrás que analizar impacto ambiental con el mismo nivel de detalle.

Desde el punto de vista de consultoría, esto abre un escenario bastante claro.

Van a aparecer nuevos requisitos en proyectos:

Y esto no va a ser solo cosa de un módulo concreto. Va a afectar a MM, SD, PP, FI… prácticamente a todo.

Lo interesante es que SAP ya está moviendo ficha aquí, posicionándose como plataforma central también para este tipo de información.

Pero, como pasa siempre, la tecnología no es el reto principal.

El reto va a estar en cómo las empresas integran estos datos en su operativa real.

La semana en bolsa de SAP vuelve a dejar una sensación bastante conocida: buenos fundamentos, pero con un mercado que sigue mirando con lupa cada movimiento.

La acción ha mostrado cierta estabilidad con ligeras oscilaciones, en un contexto donde los inversores están especialmente sensibles a cualquier señal sobre crecimiento en cloud y evolución del negocio a medio plazo. No estamos viendo grandes caídas ni subidas explosivas, pero sí un comportamiento que refleja cautela.

Y esto tiene bastante sentido.

SAP sigue avanzando en su transición hacia el cloud, y los datos en general acompañan. El negocio es sólido, los ingresos son consistentes y la compañía mantiene una posición fuerte dentro del software empresarial.

Pero el mercado no está mirando solo eso.

Lo que realmente está valorando ahora mismo es la velocidad de esa transformación. No basta con que el cloud crezca, la pregunta es si crece lo suficientemente rápido como para justificar las expectativas.

Además, hay otro factor que está pesando: la competencia en torno a la inteligencia artificial y cómo se posicionan las grandes compañías tecnológicas en este nuevo escenario. SAP está moviéndose en esta dirección, pero el mercado quiere ver resultados más tangibles.

Todo esto genera un contexto curioso.

Por un lado, SAP es una compañía estable, con una base muy sólida y un ecosistema enorme. Por otro, está en pleno proceso de cambio, y eso siempre genera incertidumbre.

Y aquí es donde esto conecta directamente con lo que vemos en proyectos.

Muchas empresas están en esa misma situación: sistemas funcionando bien, pero con la necesidad de evolucionar. Migraciones a S/4, adopción de cloud, nuevas capacidades… pero todo avanzando a un ritmo más lento del que, en teoría, se esperaba.

Al final, la bolsa está reflejando algo que vivimos en el día a día.

Llevo tiempo queriendo hablar de esto porque es algo que vivo de cerca y que creo que mucha gente del ecosistema SAP tiene en la cabeza pero no termina de dar el paso.

¿Puedo convertir lo que sé hacer en un producto? ¿Puedo empaquetar ese desarrollo que he repetido en tres clientes distintos y venderlo como algo propio? La respuesta es sí. Y merece la pena. Pero hay que entender bien lo que implica antes de lanzarse.

La mayoría de consultores y partners que conozco desarrollan en Z. Y es perfectamente válido para un proyecto puntual de un cliente concreto. Pero si quieres que algo sea un producto real ( algo que puedas distribuir, proteger y mantener con garantías ) necesitas un namespace propio.

Y aquí viene algo que me parece increíble y que muy poca gente sabe: registrar ese namespace no cuesta dinero. SAP te lo asigna de forma gratuita. Lo que cuesta es el tiempo, la burocracia del proceso y, sobre todo, tener claro para qué lo vas a usar. Pero la barrera económica no existe. Así que si llevas tiempo pensando en dar ese paso... esa excusa ya no vale. 😏

La diferencia entre un desarrollo Z y un producto con namespace propio es enorme: el Z lo puede tocar cualquier cliente con acceso al sistema. El producto con namespace propio solo lo puede modificar quien tú decidas, y solo si les das explícitamente una repair key para ello. Eso es control real sobre lo que has construido.

Esto es lo que más veo que se ignora y lo que más problemas da después. No es lo mismo desarrollar un producto para un cliente con ECC, para un S/4HANA On-Premise, para una Private Cloud o para una Public Cloud. Son mundos distintos con restricciones completamente diferentes.

En ECC y S/4HANA On-Premise tienes libertad total. ABAP clásico, desarrollos Z, tablas custom, todo lo que conocemos de siempre. En entornos cloud las restricciones crecen y en Public Cloud directamente no hay ABAP custom. Si tu producto vive en ABAP clásico y tu cliente está en Public Cloud... hay un problema serio.

Por eso antes de empezar hay que responder una pregunta muy concreta: ¿cuál es mi cliente objetivo y qué versión de SAP tiene? Esa respuesta condiciona absolutamente todo lo demás. La arquitectura, las herramientas, las restricciones y el modelo de distribución. Quien no lo tiene claro desde el principio lo descubre durante el proyecto, y eso siempre es más caro.

Y esto es algo que he vivido de primera mano trabajando con productos de partner instalados en clientes. La instalación es el día uno. Lo que viene después es donde realmente está el trabajo de verdad.

Porque instalar un producto SAP no es enchufar un cable y listo. Es un proyecto. Con su planificación, su análisis previo, su gestión del entorno del cliente, su coordinación con el equipo técnico y funcional, y su fase de post-instalación que en muchos casos es igual de larga que la instalación en sí.

El customizing específico del cliente, las adaptaciones particulares que siempre aparecen, la formación a usuarios, el soporte posterior... todo eso hay que tenerlo planificado y pactado desde el principio. Si no está claro desde el día uno quién hace qué y cómo se gestiona lo que viene después de la instalación, el proyecto acaba siendo un problema para los dos lados. Para el que entrega y para el que recibe.

Y el precio del producto nunca puede ser solo el precio de la instalación. Tiene que reflejar todo lo que viene después.

Sí. Sin duda. Crear un producto propio dentro del ecosistema SAP, con su namespace, bien empaquetado y bien documentado, es una de las formas más sólidas de construir algo con valor real y diferencial en este mundo. No es rápido, no es trivial y requiere planificación. Pero la recompensa de tener algo que puedes distribuir, proteger y evolucionar de forma controlada es enorme.

Lo que sí tengo claro es que hay que hacerlo bien desde el principio. Con el namespace correcto, pensando en el cliente objetivo desde el primer momento, planificando la instalación como lo que es (un proyecto ) y teniendo muy claro qué pasa después de que el producto está en producción.

Porque lo más fácil de todo este proceso es desarrollar. Lo más complicado es todo lo demás. 😏

Una de las preguntas que más se repite cuando hay que integrar un producto externo con SAP es: ¿cómo me conecto? Y la respuesta depende completamente de en qué sistema estás. Aquí va el mapa completo, de lo más antiguo a lo más moderno.

Compatible con: R/3, ECC, S/4HANA On-Premise

RFC es el protocolo propietario de SAP para comunicación síncrona entre sistemas. Las BAPIs son RFCs estandarizadas que dan acceso a objetos de negocio SAP. Llevan aquí desde los tiempos del R/3 y siguen funcionando. Si tienes un sistema antiguo y necesitas que algo externo llame a SAP de forma síncrona, RFC sigue siendo una opción válida. El problema: es un protocolo propietario, necesita librerías específicas como JCo para Java o NCo para .NET, y en entornos cloud directamente no existe. SAP recomienda activamente reemplazar RFCs e IDocs por OData, REST y SOAP en los proyectos modernos.

Compatible con: R/3, ECC, S/4HANA On-Premise, S/4HANA Private Cloud

El IDoc es el mecanismo de integración asíncrona estándar de SAP, diseñado para intercambio de datos de alto volumen entre SAP y sistemas externos. Muy habitual en escenarios B2B: pedidos, facturas, albaranes. Sigue siendo el estándar en muchos sistemas en producción. En cloud su uso está limitado y SAP empuja a sustituirlo por APIs más modernas.

Compatible con: ECC, S/4HANA On-Premise, S/4HANA Private Cloud, S/4HANA Public Cloud

Con la integración de servidores web en la capa de aplicación de SAP, la comunicación vía HTTP/HTTPS se hizo posible y SOAP reemplazó rápidamente a RFC como protocolo preferido para integraciones de sistema. Basado en XML, con contrato definido por WSDL, síncrono. Es el formato que muchos proveedores externos usan todavía y que SAP soporta en prácticamente todos sus sistemas. No es el más moderno pero es el más universal en entornos empresariales con cierto legado.

Compatible con: S/4HANA On-Premise, S/4HANA Private Cloud, S/4HANA Public Cloud

OData se está convirtiendo en el centro de las APIs de SAP. El propio SAP Fiori usa OData como base de todas sus comunicaciones con el backend. Es REST sobre HTTP, formato JSON o XML, y es lo que encontrarás en el SAP API Business Hub para la mayoría de APIs de S/4HANA. Si estás integrando un producto externo con un S/4HANA moderno, OData es probablemente tu mejor opción. Tiene versionado, está bien documentado y SAP lo mantiene activamente.

Compatible con: S/4HANA Private Cloud, S/4HANA Public Cloud, BTP

En S/4HANA Cloud únicamente están soportados OData, SOAP y REST. RFC e IDoc son protocolos propietarios que no existen en este entorno. En cloud la autenticación va por OAuth2, las integraciones se gestionan a través de SAP Integration Suite con sus iFlows, y el Cloud Connector es la pieza que conecta lo que está en on-premise con lo que vive en BTP. Es el modelo más moderno, más seguro y más escalable... y también el que más arquitectura requiere para montarlo bien.

Uno de los conceptos que más confusión genera en los proyectos con WM clásico y que sin embargo es fundamental para que el almacén funcione bien desde el día uno: las estrategias de entrada y salida de stock.

Cuando en SAP WM entra una mercancía al almacén, el sistema tiene que decidir automáticamente dónde la coloca. Y cuando sale, tiene que decidir de dónde la coge. Esa decisión no es aleatoria, la toma el sistema siguiendo unas reglas que tú configuras. Esas reglas son las estrategias.

Sin estrategias bien configuradas, el almacén funciona pero funciona mal. Los operarios deciden manualmente dónde poner cada cosa, el sistema no optimiza nada y en poco tiempo tienes un almacén caótico donde nadie sabe bien qué hay ni dónde.

Hueco fijo — Cada material tiene asignada siempre la misma ubicación. Simple, predecible y muy habitual en almacenes pequeños o con poco movimiento. El problema es que desaprovecha espacio cuando esa ubicación está vacía.

Hueco vacío — El sistema busca la primera ubicación libre disponible y coloca ahí la mercancía. Optimiza el espacio pero puede dispersar el mismo material por ubicaciones distintas, lo que complica el picking.

Adición al stock existente — El sistema intenta colocar la mercancía en una ubicación donde ya hay stock del mismo material. Muy útil para consolidar y facilitar el conteo de inventario. Requiere que las ubicaciones tengan capacidad configurada correctamente.

Estrategia por sección o tipo de almacén — Defines reglas por zonas del almacén. Por ejemplo, los materiales de alta rotación van siempre a la zona más cercana a los muelles de salida. Los de baja rotación van al fondo. Esto es donde WM empieza a aportar valor logístico real.

FIFO — First In First Out — Sale primero lo que entró antes. Fundamental para productos con fecha de caducidad o para cualquier empresa que necesite gestionar antigüedad de stock. En SAP WM el FIFO se basa en la fecha de entrada en la ubicación.

LIFO — Last In First Out — Sale primero lo que entró último. Menos habitual pero existe en ciertos sectores.

Ubicación fija — El picking siempre se hace desde la misma ubicación asignada al material. Muy habitual en almacenes de picking rápido donde la velocidad es prioritaria sobre la optimización de espacio.

Cantidad más próxima — El sistema busca la ubicación que tenga la cantidad más cercana a la que necesitas para minimizar las ubicaciones que quedan con stock residual. Reduce la fragmentación del almacén.

En ECC la configuración de estrategias vive en la SPRO bajo la ruta:

Las estrategias se asignan a nivel de tipo de almacén dentro de cada número de almacén. Esto significa que puedes tener estrategias diferentes para distintas zonas del mismo almacén , por ejemplo FIFO en la zona de frescos y hueco vacío en la zona de paletería general.

Configurar una única estrategia para todo el almacén sin analizar previamente las necesidades reales de cada zona. El almacén de un cliente no es homogéneo. Tiene zonas de alta rotación, zonas de producto pesado, zonas refrigeradas, zonas de picking unitario... y cada una puede necesitar una estrategia diferente.

El funcional que no hace ese análisis antes de parametrizar acaba con un sistema que técnicamente funciona pero que operativamente no encaja con la realidad del almacén. Y eso lo descubres en el go-live, cuando los operarios empiezan a saltarse las órdenes de transporte porque el sistema les manda a sitios que no tienen sentido. 😅

WM clásico sigue siendo perfectamente válido para almacenes de complejidad media. Si el cliente tiene procesos de entrada, ubicación, picking y salida estándar sin automatización avanzada, WM clásico cubre perfectamente sus necesidades y con un equipo que lo conoce bien es rápido de implementar.

EWM entra en juego cuando el almacén tiene automatización, conveyors, gestión de recursos avanzada o procesos muy específicos por industria. Pero eso ya da para otro tip. 😏

Función poco conocida y muy útil que permite cambiar la contraseña de cualquier usuario SAP de forma programática, sin tocar la SU01 y sin intervención manual.

matización de onboarding de usuarios, resets masivos de contraseñas tras auditorías de seguridad o sincronización con sistemas externos de gestión de identidades. En todos esos casos evita horas de trabajo manual en SU01.

Autorizaciones. El usuario técnico que la ejecuta necesita permisos sobre S_USER_GRP. Sin ellos falla aunque el código sea perfecto — el error más habitual la primera vez. 😅

Política de contraseñas. SAP valida longitud, caracteres especiales e historial. Si la contraseña no cumple, devuelve PASSWORD_NOT_ALLOWED.

Control de acceso. Es una función con mucho poder. El programa que la llama tiene que estar muy controlado. Lo que no se registra en un log de auditoría no existe.

Hay una situación que cada vez es más habitual en los proyectos SAP y de la que se habla poco: tienes delante un proveedor con un producto interesante, con sus APIs, con su tecnología propia... y tu trabajo no es desarrollar desde cero sino hacer que eso funcione dentro de SAP. Integrarlo. Conectarlo. Y colaborar activamente con ellos durante todo el proceso.

Suena bien. Y puede serlo. Pero hay cosas que aprender antes de meterte en ese proyecto.

Un buen proveedor con el que merece la pena trabajar tiene varias características que se notan rápido:

Sus APIs están bien documentadas y son estables. No significa que sean perfectas desde el día uno — eso es raro — pero sí que tienen versionado, que los cambios se comunican con tiempo y que no te encuentras un lunes por la mañana con que han cambiado un endpoint sin avisar y tu integración está caída en producción.

Tiene un interlocutor técnico real. No un comercial que te dice que "todo es posible". Un técnico que entiende lo que le estás preguntando, que sabe cómo funciona su producto por dentro y que puede tomar decisiones cuando aparece un problema. Sin ese perfil, cada incidencia se convierte en un partido de tenis de emails que no lleva a ningún sitio.

Entiende que el ritmo de SAP no es el ritmo de una startup. En SAP hay landscapes, hay ventanas de mantenimiento, hay procesos de aprobación para transportes, hay usuarios que no pueden permitirse que el sistema esté caído. Un buen proveedor lo respeta. Uno que no lo entiende te presionará para hacer cambios en producción sin pasar por DEV y QAS porque "es un cambio pequeño". Eso es una señal de alarma enorme.

Cuando algo falla, busca la solución contigo. No el culpable. Esta es quizás la más importante. En una integración entre dos sistemas siempre hay una zona gris donde no está claro de qué lado está el problema. El proveedor con el que merece la pena trabajar se mete en esa zona gris contigo. El que no merece la pena te manda la documentación de su API y dice que su parte funciona correctamente.

El modelo de autenticación y seguridad. Cómo se autentican las llamadas entre SAP y el sistema del proveedor, dónde viven las credenciales, cómo se renuevan los tokens, qué pasa si caducan en producción a las 3 de la mañana. Esto hay que tenerlo resuelto en papel antes de escribir una línea de código de integración.

El modelo de errores. ¿Qué pasa cuando la API del proveedor no responde? ¿Hay reintentos? ¿Se guarda el mensaje para reprocesar? ¿Se le avisa al usuario o se pierde silenciosamente? Una integración sin estrategia de error no es una integración. Es una bomba de relojería.

Quién es responsable de qué en producción. Cuando algo falla a las 3 de la mañana — y en algún momento fallará — tiene que estar clarísimo quién llama a quién, quién tiene acceso a qué logs y quién toma la decisión de parar o continuar. Si eso no está definido antes del go-live, lo defines en el peor momento posible.

Las versiones y la compatibilidad. Si el proveedor actualiza su API, ¿cuánto tiempo tienes para adaptar la integración en SAP? ¿Hay versiones en paralelo o el cambio es inmediato? En SAP un cambio de integración pasa por DEV, QAS y PRD. Eso tiene un tiempo mínimo. El proveedor tiene que entenderlo y respetarlo.

Cuando funciona bien, colaborar con un proveedor externo para integrar su producto con SAP es una de las formas más inteligentes de crear valor. No estás reinventando la rueda. Estás cogiendo algo que ya existe, que ya funciona, que ya tiene usuarios reales... y lo estás poniendo a trabajar dentro del ecosistema SAP de tu cliente. Eso es eficiencia real.

Pero para que funcione bien, el responsable del proyecto tiene que actuar como traductor entre dos mundos. El mundo del proveedor, que tiene su producto, su roadmap y su forma de trabajar. Y el mundo SAP, con su landscape, sus procesos y sus tiempos. Esa figura de traducción es fundamental y muchas veces invisible. Hasta que falta.

En consultoría todos pasamos por problemas, errores y decisiones complicadas. Eso es inevitable. La diferencia está en cómo reaccionas. Hay quien repite los mismos fallos una y otra vez y quien aprende, ajusta y mejora. La experiencia real no viene del tiempo, viene de la capacidad de sacar conclusiones y aplicarlas en el siguiente proyecto.

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

Hoy hemos hablado de algo que todos hacemos… pero no siempre pensamos cómo lo estamos haciendo: el desarrollo de producto en SAP.

Porque al final, más allá de código, funcionalidades y entregables, desarrollar no es solo construir. Es decidir cómo se va a usar, quién lo va a usar y qué problema estás resolviendo realmente.

Y lo curioso es que muchas veces el desarrollo funciona… pero no encaja del todo. Cumple, pero no termina de aportar valor. No porque esté mal hecho, sino porque no se pensó como producto.

Ahí es donde está la diferencia.

Entre desarrollar algo que funciona… y desarrollar algo que realmente se usa.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta comunidad, donde no solo hablamos de SAP… sino también de cómo mejorar lo que hacemos en el día a día.

La semana que viene volveremos con más experiencias reales, algún tema interesante y seguramente otra de esas situaciones en las que piensas: “vale… esto me ha pasado”.

Nos leemos en el próximo boletín.