¿Tu equipo trabaja en SAP Business One… pero sigue invirtiendo
tiempo en tareas manuales?

Con la integración de Dost, desarrollada por GROUPmee, automatizas
procesos clave de tu operativa financiera directamente dentro de SAP.
Captura e interpreta documentos con inteligencia artificial, concilia
automáticamente facturas, pedidos y albaranes, y gestiona
aprobaciones sin fricciones.

No es solo gestión documental: es automatización real de procesos,
con trazabilidad y control en tiempo real.

Menos tareas manuales. Más eficiencia. Más control.

Cuando una consultora o un partner desarrolla y certifica un producto propio en SAP, la pregunta que viene inmediatamente después es: ¿cómo lo vendo y cómo lo cobro?

Y aquí es donde mucha gente se sorprende, porque no hay una única respuesta.

Pago único + desarrollos adicionales El cliente paga una vez por la licencia del producto base y a partir de ahí cualquier adaptación específica a su negocio se presupuesta aparte. Es el modelo más tradicional y el que más control da al partner sobre el margen. El problema: una vez cobrada la licencia, el cliente siente que ya ha pagado todo... y las peticiones de cambio llegan sin presupuesto previsto. Hay que dejar muy claro desde el principio qué está incluido y qué no.

Suscripción anual El cliente paga una cuota anual que incluye el uso del producto, las actualizaciones y generalmente un nivel básico de soporte. SAP ha pivotado completamente hacia este modelo en sus propios productos y el ecosistema de partners lo está siguiendo, porque genera ingresos recurrentes y predecibles frente a la incertidumbre del pago único. La ventaja para el cliente es que siempre tiene el producto actualizado. La desventaja: si no renueva, se queda sin acceso. Y aquí está la clave , si el producto está bien integrado en sus procesos, no renovar no es una opción real. El partner lo sabe. El cliente lo aprende.

Lo cierras y punto La tercera opción es la que nadie menciona pero que existe: si el cliente no renueva, no paga o la relación no funciona, el partner puede simplemente cerrar el acceso al producto. En un desarrollo Z sin namespace esto es complicado ,el código ya vive en el sistema del cliente y no puedes hacer gran cosa. Pero con un producto correctamente protegido bajo namespace propio, con sus claves de desarrollo y sus repair keys bien gestionadas, el control sigue siendo tuyo.

El concepto de agentic AI empieza a sonar cada vez más… pero lo interesante no es el término, es lo que implica.

Según SAP, este tipo de inteligencia artificial no se limita a responder preguntas o generar contenido, sino que es capaz de ejecutar acciones dentro de los procesos. Es decir, pasar de “asistir” a “actuar”.

Y aquí es donde cambia el juego.

Hasta ahora, la mayoría de herramientas de IA en el entorno SAP han sido de apoyo: ayudan a analizar datos, generar textos o sugerir decisiones. Pero siempre con una persona en medio validando y ejecutando.

El enfoque de agentic AI va un paso más allá.

La idea es que ciertos procesos puedan iniciarse, gestionarse o incluso completarse automáticamente en base a reglas, contexto y datos en tiempo real. No solo recomienda qué hacer, sino que lo hace.

A primera vista suena potente. Y lo es.

Pero también abre muchas preguntas.

Porque en un entorno como SAP, donde los procesos impactan directamente en negocio, finanzas o logística, automatizar decisiones no es trivial. No es solo una cuestión técnica, es una cuestión de control, trazabilidad y confianza.

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

Muchas empresas todavía están en fases bastante iniciales de automatización. Hay procesos manuales, decisiones que dependen de usuarios clave y flujos que no están completamente estandarizados.

En ese contexto, hablar de agentes autónomos puede parecer adelantado.

Pero no lo es tanto.

Lo que probablemente veremos no es una automatización total de golpe, sino una evolución progresiva. Primero asistentes que sugieren, luego que ejecutan bajo ciertas condiciones, y poco a poco, procesos más autónomos.

Desde el punto de vista de consultoría, esto cambia bastante el enfoque.

Ya no se trata solo de diseñar procesos o desarrollos, sino de definir:

Porque automatizar sin criterio puede generar más problemas que beneficios.

Al final, la tecnología va a estar.

La diferencia va a estar en cómo se utiliza.

La semana en bolsa de SAP ha sido relativamente estable, pero con un trasfondo bastante interesante.

La acción se ha movido sin grandes sobresaltos, reflejando un momento de transición más que de euforia o caída. El mercado sigue reconociendo la solidez de SAP, especialmente en su negocio cloud, pero al mismo tiempo mantiene cierta cautela.

Y esa cautela tiene sentido.

Los inversores no están cuestionando si SAP funciona, sino si está evolucionando al ritmo esperado. El foco sigue estando en el crecimiento del cloud, la adopción de nuevas tecnologías como la inteligencia artificial y la capacidad de la compañía para mantener su posición frente a la competencia.

Es un escenario curioso.

SAP está en una posición fuerte, con una base muy consolidada, pero al mismo tiempo está en pleno proceso de cambio. Y ese tipo de momentos suelen generar movimientos más contenidos en bolsa.

Al final, lo que estamos viendo no es duda sobre el presente, sino sobre la velocidad del futuro.

Y eso, en cierto modo, refleja bastante bien lo que también vemos en muchos proyectos SAP hoy en día.

Guía Integral: La Certificación de Productos en el Ecosistema SAP

Certificar un software para que funcione dentro de SAP no es solo un trámite administrativo; es una decisión estratégica que transforma la percepción del producto en el mercado. A continuación, se desglosan los pilares de este proceso basándose en la experiencia técnica y comercial.

1. El Valor Estratégico: Confianza y Ventas

El principal beneficio de la certificación es la generación de confianza inmediata en el proceso de venta. Para un cliente final, saber que un producto cuenta con el sello oficial de SAP elimina barreras críticas:

2. El Proceso de Certificación (El "Laberinto")

El camino hacia el sello oficial es supervisado por el SAP ICC (Integration and Certification Center), el organismo responsable de validar que las soluciones de terceros funcionen correctamente. Los pasos clave incluyen:

3. Inversión y Costes Asociados

Certificar un producto requiere una inversión financiera y de infraestructura considerable:

4. Implementación Técnica: Instalación y Seguridad

Desde el punto de vista técnico, un producto certificado debe comportarse como un componente estándar del sistema:

5. Claridad sobre la Funcionalidad

Es vital entender que SAP no evalúa si tu producto es útil o si su lógica de negocio es perfecta. El ICC certifica exclusivamente la viabilidad técnica: que el código no destruye el sistema, que las conexiones son seguras y que el software se puede instalar y desinstalar correctamente. La responsabilidad de la funcionalidad recae enteramente en el proveedor del software.

6. El Futuro: De ABAP Clásico a BTP

El modelo tradicional basado en el Add-on Assembly Kit está evolucionando hacia el modelo de Clean Core. SAP busca que el código no resida dentro de su núcleo (Core), impulsando soluciones alineadas con BTP (Business Technology Platform). Se estima que estos nuevos procesos podrían ser más económicos (alrededor de 3.000 €), aunque la filosofía sigue siendo la misma: garantizar que las extensiones no comprometan la estabilidad del sistema estándar.

Hay dos situaciones que todo técnico que trabaja con la SNOTE ha vivido alguna vez. La primera: aplicas una nota, el sistema dice que está aplicada... y el error sigue ahí. La segunda: abres una nota para aplicarla y descubres que necesita otras cinco debajo. Aquí va cómo gestionar las dos.

Antes de aplicar cualquier nota, lo primero que tienes que hacer es revisar la pestaña "Notas de corrección prerrequisito" dentro de la propia SNOTE. Ahí SAP lista todas las notas que deben estar aplicadas previamente para que la tuya funcione correctamente.

El error clásico es ignorar esa pestaña, aplicar la nota directamente y luego preguntarse por qué el sistema se comporta de forma inesperada. O peor: la nota se aplica sin errores aparentes pero la corrección no tiene efecto porque falta una dependencia debajo.

Lo que hay que hacer antes de empezar:

Abre la nota en SNOTE, revisa los prerequisitos, entra en cada uno de ellos y comprueba si están aplicados en tu sistema. Si alguno no lo está, empieza por ahí. Y ojo , ese prerequisito puede tener a su vez otros prerequisitos. En notas complejas de seguridad o de funcionalidad crítica es habitual encontrarse con cadenas de tres o cuatro niveles. Paciencia y orden. 😅

Un truco útil: la SNOTE tiene la opción "Descargar con prerequisitos" que intenta resolver automáticamente toda la cadena de dependencias y descargártelas de una vez desde el SAP Support Portal. No siempre funciona perfectamente pero te ahorra bastante trabajo manual en cadenas largas.

Esta es la situación más frustrante y más habitual. El sistema muestra la nota en estado "completamente implementada" y sin embargo el problema persiste. ¿Qué está pasando?

Primera comprobación: el estado real de los objetos. Dentro de la nota en SNOTE, entra en la pestaña de objetos modificados y revisa uno a uno. A veces la nota está marcada como aplicada pero algún objeto concreto tiene un estado diferente — modificado manualmente, en conflicto con otro desarrollo Z, o simplemente no activado correctamente. Un objeto sin activar después de aplicar la nota es suficiente para que la corrección no tenga efecto.

Segunda comprobación: ¿hay un desarrollo Z encima? Este es el caso más habitual y el más silencioso. La nota modifica un objeto estándar de SAP, pero ese mismo objeto tiene una modificación Z o un enhancement encima que está sobreescribiendo el comportamiento corregido. El sistema aplica la nota correctamente sobre el estándar, pero tu Z gana por encima. Resultado: el error sigue ahí y nadie entiende por qué. Hay que revisar si el objeto afectado por la nota tiene modificaciones activas en el sistema y si es así valorar si son compatibles con la corrección.

Tercera comprobación: ¿la nota aplica a tu versión exacta? Las notas SAP tienen validez para rangos de versiones y Support Packages concretos. Antes de aplicar, comprueba siempre que tu nivel de SP está dentro del rango soportado por la nota. Una nota aplicada fuera de su rango puede dar falsa sensación de éxito sin haber cambiado nada relevante.

Si hay una transacción en Controlling que marca la diferencia entre un funcional básico y uno que realmente aporta valor al negocio, esa es la KE30. Y sin embargo es una de las menos trabajadas en los proyectos.

La KE30 es el punto de entrada a los informes del módulo CO-PA (Controlling — Análisis de Rentabilidad). Su función es responder la pregunta que todo director financiero o comercial tiene en la cabeza: ¿cuánto estamos ganando realmente y con qué?

No con qué centro de coste, no con qué orden interna. Sino con qué cliente, con qué producto, con qué canal de distribución o con qué zona geográfica. CO-PA es el único módulo de SAP que permite analizar la rentabilidad desde una perspectiva de negocio real, no solo contable.

CO-PA trabaja con características y ratios de valor. Las características son las dimensiones por las que quieres analizar( cliente, material, división, región, canal ) y los ratios son los importes que quieres ver: ingresos, descuentos, coste de ventas, margen de contribución.

Cuando en SD se contabiliza una factura, CO-PA recibe automáticamente esa información y la desglosa según las características configuradas. El resultado es que puedes ver, por ejemplo, cuánto margen genera un cliente concreto comprando un producto específico a través de un canal determinado. Ese nivel de detalle no existe en FI ni en ningún otro módulo de SAP.

La KE30 es donde defines, ejecutas y visualizas esos informes. Puedes crear informes propios adaptados exactamente a lo que el cliente necesita ver, con las características y ratios que más le aporten.

CO-PA tiene dos variantes y no son iguales. La variante contable y la variante basada en costes. La diferencia es importante: la variante contable está alineada con FI y usa los mismos principios de valoración. La basada en costes usa su propia lógica de imputación y puede dar cifras distintas. Antes de configurar un informe en KE30 hay que tener muy claro cuál de las dos está activa en el sistema del cliente y por qué.

Los datos son tan buenos como la configuración que hay detrás. Si las condiciones de precio en SD no están bien mapeadas a CO-PA, si los costes de fabricación no fluyen correctamente desde CO-PC, o si la estructura de características no refleja cómo el negocio quiere analizar su rentabilidad... el informe en KE30 será bonito pero inútil. El funcional que no entiende ese flujo de datos acaba entregando informes que el cliente no puede usar.

Configurar CO-PA en el diseño inicial del proyecto sin involucrar al área comercial y financiera desde el principio. CO-PA no es un módulo técnico, es un módulo de negocio. Las características que necesita ver un director comercial no son las mismas que las que pide el controller. Y si no se recogen bien esas necesidades antes de parametrizar, luego cambiar la estructura de CO-PA es costoso y doloroso. 😅

Una de esas funciones que vive en la sombra hasta que la necesitas. Y cuando la necesitas, te alegras mucho de conocerla.

SYSTEM_RESET_RFC_SERVER libera todos los recursos asociados a un servidor RFC, limpiando las conexiones colgadas sin necesidad de reiniciar ningún servicio ni instancia. Es decir, cuando tienes conexiones RFC que se han quedado abiertas sin cerrarse correctamente — y el sistema empieza a acumularlas hasta que no puede abrir más — esta función las limpia de forma controlada.

En sistemas con muchas integraciones es más habitual de lo que parece. Una aplicación externa abre conexiones RFC para consumir servicios SAP y no las cierra correctamente al terminar. Con el tiempo el número de conexiones activas crece, el gateway empieza a saturarse y los procesos de integración comienzan a fallar con errores de comunicación sin que nadie entienda muy bien por qué. El workaround habitual es reiniciar el servidor. Lo cual funciona, pero es un martillo para clavar una chincheta.

Sin parámetros. Sin excepciones complejas. Se llama y limpia. Lo que hay que tener claro es que el usuario técnico que ejecuta esta función necesita autorización explícita sobre ella — sin ese permiso SAP devuelve RFC_ERROR_CANCELLED y la llamada falla silenciosamente. Es el primer sitio donde mirar si no funciona como se espera.

A partir de SAP JCo versión 3.0.19, esta función es llamada internamente por JCo en cada invocación RFC entrante, incluyendo las llamadas para obtener esquemas de IDoc, BAPI o RFC. Esto significa que si tienes integraciones Java con SAP y el usuario técnico no tiene autorización sobre esta función, las integraciones pueden fallar de forma intermitente y difícil de diagnosticar. Un detalle pequeño con consecuencias grandes.

Liderar el desarrollo y la certificación de un producto en el entorno SAP no es solo un reto técnico o de cumplimiento; es, ante todo, un desafío de gestión de personas y procesos. Para que un producto sea robusto y confiable, el líder debe actuar como el arquitecto de un ecosistema interno donde la comunicación y el sentido de pertenencia sean los pilares fundamentales.

A continuación, se detallan las pautas de actuación para un líder según las mejores prácticas de gestión:

1. Construir y Respaldar un Equipo Sólido

Un líder entiende que la calidad de un producto es un reflejo directo del equipo que hay detrás. La recomendación fundamental es contar con un equipo bien montado que sea capaz de dar soluciones rápidas a las incidencias. Desde el liderazgo, esto implica no solo contratar talento, sino asegurar que el equipo tenga los recursos para responder de manera global: si aparece un fallo, la solución debe ser proactiva y traducirse en una nueva versión que beneficie a toda la base de clientes.

2. Fomentar la "Propiedad" del Producto (Ownership)

Uno de los puntos más críticos para un líder es lograr que cada miembro de la organización sienta el producto como algo propio. El liderazgo efectivo debe:

3. La Escucha Activa como Estrategia de Innovación

El líder no decide las nuevas funcionalidades en el vacío. La gestión debe estar orientada a recoger el feedback constante. Esto requiere organizar el equipo de manera que existan roles claros para:

4. Excelencia en la Comunicación y Documentación

Desde el punto de vista del liderazgo, la comunicación no es un "extra", es una herramienta de mitigación de riesgos. Un líder debe asegurar que exista una comunicación constante con el cliente para evitar ofrecer soluciones inadecuadas en momentos críticos.

Asimismo, la gestión debe priorizar una documentación técnica impecable. Un líder estratégico sabe que muchos clientes no actualizarán a la última versión si la suya funciona; por tanto, el equipo debe tener el control total sobre qué incidencia se solucionó en qué versión para guiar al cliente de manera precisa: "Si te vas a esta versión nueva, aquí ya lo tendrás solucionado".

5. Visión de Calidad y Confianza

Finalmente, actuar como líder en este ámbito significa entender que la certificación y la gestión rigurosa son, en esencia, un ejercicio de generación de confianza. El líder debe transmitir al equipo que cada proceso de calidad, cada auditoría de código y cada mejora en la instalación no son meros trámites, sino la garantía de que el producto no "romperá" el sistema del cliente y que podrá ser desinstalado sin dejar rastro, manteniendo la integridad del entorno SAP.

En resumen, ser un líder en la gestión de productos SAP significa empoderar al equipo, sistematizar el feedback y mantener un compromiso inquebrantable con la robustez técnica, transformando un simple software en un sello de confianza para el mercado.

En desarrollo y en consultoría, la diferencia no suele estar en saber más, sino en saber preguntar mejor. Las soluciones realmente buenas no aparecen por arte de magia, salen de cuestionar lo que otros dan por hecho, de darle una vuelta más al problema y de no conformarse con la primera respuesta. Ahí es donde empieza la creatividad de verdad.

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

Hoy hemos hablado de algo que todos hacemos… pero que no siempre tratamos como deberíamos: el desarrollo de producto en SAP.

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

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

Ahí es donde está la diferencia.

Entre desarrollar algo que simplemente funciona… y desarrollar algo que realmente se utiliza.

Antes de cerrar, agradecer especialmente a Gerard Lagalina por su aporte en este boletín, aportando una visión muy útil y práctica sobre este tema.

Puedes seguir su contenido aquí: Linkedin Gerard Lagalina

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.