¿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.
Índice del boletín
🔍 Dato Curioso
¿Conoces alguna empresa grande que haya salido de SAP? Exacto. Casi nadie.
Hay un ejercicio mental muy revelador que te propongo.
Piensa en una empresa grande ( más de 1.000 empleados, operaciones en varios países, años de historia ) que haya salido de SAP y migrado a otro ERP con éxito. Tómate tu tiempo.
Difícil, ¿verdad?
No es casualidad. En más de veinte años de ecosistema SAP los casos documentados y públicos de empresas grandes que hayan salido de SAP son prácticamente inexistentes. No porque nadie lo haya intentado. Sino porque el coste y la complejidad de hacerlo son tan enormes que la mayoría lo descarta antes de empezar.
Los únicos casos reales que he visto de empresas que han conseguido salir de SAP tienen algo en común: eran empresas relativamente jóvenes, con poco tiempo en SAP, con procesos aún no demasiado complejos y sobre todo... con pocos o ningún desarrollo Z. Sin esa deuda técnica acumulada el sistema de destino puede replicar lo que SAP hacía sin demasiado drama. Con ella... la historia es completamente diferente.
Y aquí está el dato curioso real: cuanto más tiempo llevas en SAP y más desarrollos Z tienes... más imposible es salir. Cada línea de código Z que se añade al sistema es un ladrillo más en la pared que te separa de cualquier alternativa. No intencionadamente. Simplemente porque el negocio crece, las necesidades crecen y SAP crece con ellas.
El coste de adaptar un ERP genérico a las particularidades de cada negocio resulta ser mucho mayor de lo esperado, y la rigidez de los procesos predefinidos acaba frenando la operación en lugar de mejorarla. Eso vale para SAP pero también para cualquier sistema al que quieras migrar desde SAP.
Al final el coste de salir siempre supera al coste de quedarse. Y SAP lo sabe.
📰 Ultimas noticias
ADT ya está disponible en VS Code: el IDE que los ABAPers llevaban años pidiendo
Una noticia que llevaba mucho tiempo en el radar de la comunidad técnica SAP y que por fin es oficial.
ABAP Development Tools para Visual Studio Code está disponible con carácter general en Q2 2026. Es decir, ahora mismo. Ya puedes instalar la extensión oficial de SAP en VS Code y desarrollar ABAP desde el IDE más usado del mundo.
¿Por qué importa tanto esto? Porque durante años los usuarios pidieron traer las herramientas ABAP a entornos adicionales más allá de SAP GUI y Eclipse, y VS Code era el más solicitado en las encuestas de 2023 y 2025. SAP lo escuchó y tardó lo que tardó ( que no fue poco ) pero lo entregó.
Lo que trae esta primera versión es una base sólida: navegación de objetos ABAP, creación de código, comprobación de sintaxis y ejecución de tests. Además incluye integración nativa con Joule para desarrolladores ( completado de código con IA, explicación de objetos en lenguaje natural ) y el ABAP MCP Server bajo el capó, lo que significa que sus capacidades irán creciendo con cada release del servidor MCP.
¿Llegará al nivel de Eclipse ADT en funcionalidades? SAP reconoce que tardaron 16 años en llegar al nivel actual de Eclipse y que la extensión de VS Code irá alcanzando ese nivel gradualmente, un release a la vez. No es enchufar y tener todo el día uno. Pero el camino ya empezó.
Si eres ABAPER y aún no lo has probado... este fin de semana tienes plan. 😄
💹 Información en Bolsa
Semana movida para la acción de SAP en los mercados. A día de hoy 1 de junio de 2026, la cotización de SAP en Fráncfort se sitúa en 166,10€, con un rango diario entre 157,53€ y 168,80€ y un rango de 52 semanas entre 135,44€ y 273,55€.
El dato más llamativo: SAP cotiza muy por debajo de sus máximos anuales. Y hay contexto detrás de eso.
SAP recibió un fuerte castigo en bolsa de un 16,21% tras presentar sus resultados del cuarto trimestre y ejercicio 2025, pese a haber ganado 7.176 millones de euros ( un 36% más ) y anunciar una recompra de acciones de hasta 10.000 millones de euros. El mercado penalizó que la compañía anticipara cierta moderación en el ritmo de nuevos pedidos.
Dicho de otra forma: SAP ganó más dinero que nunca, anunció que iba a recomprar sus propias acciones a lo grande... y la bolsa le castigó de todas formas porque los inversores esperaban más aceleración en el cloud.
Sapphire 2026 llegó con anuncios potentes ( Dremio, Prior Labs, Joule para on-premise, ADT en VS Code ) pero el precio objetivo medio a 12 meses que los analistas dan a SAP es de 214,81€, con estimaciones que van desde 155€ en el caso más pesimista hasta 290€ en el más optimista. Es decir, hay quien cree que está barata ahora mismo y quien cree que el ajuste aún no ha terminado.
Los indicadores técnicos actuales sugieren que SAP es una opción de compra fuerte según el consenso de analistas. Aunque ya sabéis que esto no es consejo de inversión ( soy consultor SAP, no gestor de fondos ) 😄
Lo que sí es interesante observar desde dentro del ecosistema: el mercado penaliza a SAP cuando modera el crecimiento cloud pero los datos reales muestran que el 42% de las empresas sigue apostando por S/4HANA On-Premise. Esa tensión entre lo que SAP vende al mercado financiero y lo que realmente ocurre en los proyectos es uno de los debates más interesantes del ecosistema ahora mismo.
🚀 Mi Opinión
La relación tóxica entre SAP y sus clientes: por qué nadie se va aunque quiera
Soy fan de SAP. Fan de verdad. No de los que lo dicen en LinkedIn para quedar bien con los recruiters. De los que trabajan con él cada día, ven sus defectos de cerca y aun así reconocen que lo que han construido durante más de cincuenta años no tiene parangón en el mundo del software empresarial.
Y precisamente por eso quiero hablar de algo que todo el mundo comenta en voz baja pero casi nadie dice en público: una vez que entras en SAP, salir es prácticamente imposible. No porque SAP te lo impida. Sino porque lo que han construido es tan completo y tan integrado con tu negocio que desmantelarlo tiene un coste que ninguna empresa quiere asumir.
¿Es eso “monopolio”? No se... Pero ese supuesto “monopolio” se lo han ganado a pulso. Y ahora te explico por qué.
Cincuenta años construyendo lo mismo. Y se nota.
SAP nació en 1972. Cincuenta y cuatro años añadiendo módulos, industrias, países, regulaciones e integraciones. Cada versión más profunda que la anterior. Y ese tiempo se nota en cada rincón del sistema.
Nadie más tiene cincuenta años de procesos de negocio codificados, de mejores prácticas de industria integradas en el estándar y de regulaciones fiscales de más de 80 países resueltas dentro del propio sistema. SAP es compatible con las regulaciones fiscales de más de 80 países y está disponible en 26 idiomas.
Eso no se replica con una ronda de financiación y un equipo motivado. Está en décadas de proyectos reales en todos los sectores del mundo. Y copiar ni tan siquiera un módulo de SAP es extraordinariamente difícil. No por la tecnología. Sino por todo el conocimiento de negocio que hay detrás de cada campo, de cada tabla y de cada proceso. Eso no está en ningún manual.
La competencia existe. Pero no llega ni a la suela.
Seré justo: hay alternativas. Y algunas son buenas para determinados contextos.
Oracle ERP Cloud es el competidor más serio en el segmento enterprise. Potente y con una propuesta cloud sólida. Pero lleva décadas intentando comerse la cuota de SAP en grandes empresas y el resultado habla por sí solo.
Microsoft Dynamics 365 es una opción muy válida para medianas empresas integradas en el ecosistema Microsoft. Dynamics 365 F&O encaja bien para empresas de entre 100 y 1.000 usuarios. Pero cuando los procesos se complican, cuando necesitas gestionar una cadena de suministro global con trazabilidad completa y regulaciones de múltiples países... empieza a mostrar sus límites.
Odoo es el disruptor de moda. Open source, modular y barato de entrada. Perfecto para una pyme que empieza. Pero SAP procesa datos en tiempo real con una capacidad que Odoo no puede igualar en su versión Community. Y cuando la empresa crece... o paga las licencias enterprise que ya no son tan baratas o mira hacia SAP de todas formas.
La realidad en 2026 es que SAP no tiene un competidor real a su nivel en el segmento enterprise. Tiene alternativas para nichos específicos. Pero un competidor capaz de sustituirlo en una multinacional con operaciones en veinte países y cadena de suministro global... no existe.
¿Y entonces por qué nadie se va?
Porque salirse de SAP no es cambiar de herramienta. Es desmantelar el sistema nervioso de tu empresa.
Una empresa que lleva quince años en SAP tiene sus procesos modelados en SAP, años de datos históricos en SAP, su equipo formado en SAP y todas sus integraciones construidas sobre SAP. Migrar todo eso no es un proyecto de seis meses. Es varios años, un coste brutal y un riesgo operativo enorme. Y al final del camino tienes un sistema nuevo que tiene que replicar todo lo que SAP ya hacía.
El coste de salida es tan alto que para la mayoría de las grandes empresas simplemente no tiene sentido económico. No porque SAP sea perfecto ( que no lo es ) sino porque lo que tienes construido encima tiene un valor que ninguna propuesta comercial de la competencia puede compensar de forma realista.
El “monopolio” que se han ganado a pulso
Sí, SAP tiene una posición dominante. Sí, la Unión Europea les investiga por prácticas anticompetitivas. Sí, su modelo de licencias no siempre es el más transparente del mundo.
Pero ese “monopolio” no se construyó con trampas.
Monta tú una empresa así. Con un ERP que cubra manufactura, logística, finanzas, recursos humanos, cadena de suministro y ahora inteligencia artificial. Con soporte para 80 países y 26 idiomas. Con cincuenta años de mejores prácticas integradas en el estándar. Con una comunidad global de millones de consultores, partners y clientes que no tiene equivalente en el mundo del software empresarial.
La IA no va a cambiar esto de la noche a la mañana. Ninguna startup va a construir en tres años lo que SAP ha construido en cinco décadas. Y eso, con todos sus defectos y todas sus decisiones comerciales cuestionables... merece respeto.
💬 ¿Tú también eres fan de SAP a pesar de todo? ¿O has vivido algún proyecto donde habrías preferido estar en cualquier otro sistema?
🧩 SAP Técnico
Hay una pregunta que aparece cada vez más en proyectos S/4HANA cuando hay procesos con volúmenes de datos grandes y el rendimiento empieza a ser un problema.
"¿Por qué no metemos esto directamente en HANA?"
Y la respuesta correcta no es ni sí ni no. Es depende. Y aquí está el criterio para decidirlo bien.
¿Qué es AMDP exactamente?
Un AMDP ( ABAP Managed Database Procedure ) es una clase ABAP que permite escribir lógica compleja directamente en la base de datos SAP HANA usando SQLScript, en lugar de procesarlo todo en la capa de aplicación ABAP.
La diferencia fundamental respecto al ABAP clásico es dónde se ejecuta la lógica. En ABAP normal subes los datos al servidor de aplicación, los procesas ahí y bajas el resultado. Con AMDP la lógica vive y se ejecuta directamente en HANA, donde están los datos. Sin movimiento de datos entre capas. Sin latencia entre base de datos y aplicación.
CLASS zcl_mi_amdp DEFINITION PUBLIC.
PUBLIC SECTION.
INTERFACES if_amdp_marker_hdb.
CLASS-METHODS get_ventas_alto_valor
IMPORTING VALUE(iv_importe) TYPE mara-brgew
EXPORTING VALUE(et_result) TYPE tt_ventas.
ENDCLASS.
CLASS zcl_mi_amdp IMPLEMENTATION.
METHOD get_ventas_alto_valor
BY DATABASE PROCEDURE
FOR HDB
LANGUAGE SQLSCRIPT
USING vbak vbap.
et_result = SELECT v.vbeln, v.kunnr, p.matnr, p.netwr
FROM :vbak AS v
INNER JOIN :vbap AS p ON v.vbeln = p.vbeln
WHERE p.netwr > :iv_importe;
ENDMETHOD.
ENDCLASS.¿Cuándo tiene sentido usarlo?
Cuando tienes lógica que procesa volúmenes masivos de datos y necesitas rendimiento máximo. Cálculos agregados complejos sobre millones de registros, transformaciones de datos que en ABAP generarían bucles enormes, lógica estadística o matemática avanzada que HANA resuelve en milisegundos gracias a su arquitectura in-memory.
AMDP reduce la latencia al procesar los datos cerca de donde viven, minimizando la transferencia entre la base de datos y la capa de aplicación.
¿Y cuándo NO usarlo?
Aquí viene lo que mucha gente ignora. La propia documentación oficial de SAP es clara: el uso de AMDP no se recomienda si la misma tarea puede resolverse con ABAP SQL o CDS Views. Un acceso mal programado en ABAP SQL a menudo puede optimizarse sin necesidad de recurrir a AMDP.
Dicho de otra forma: antes de meter SQLScript en una clase ABAP, asegúrate de que no hay una CDS View o una consulta ABAP SQL bien escrita que resuelva el mismo problema. Porque AMDP tiene un coste: está acoplado a HANA, es más difícil de testear, más difícil de debuggear y menos portable. Si puedes evitarlo con buenas prácticas de ABAP SQL... evítalo.
🧩 SAP Funcional
Hay un escenario en proyectos SD que parece sencillo cuando el cliente lo describe... y que tiene más implicaciones de las que parecen cuando lo llevas a SAP.
"A veces vendemos productos que no tenemos en stock. El proveedor se lo manda directamente al cliente."
Perfecto. Eso en SAP se llama proceso de terceros. Y no es lo mismo que una orden de venta estándar. Ni de lejos.
La orden de venta estándar: el flujo que todos conocen
Cliente hace un pedido → SAP crea la orden de venta → se genera la entrega desde tu almacén → sale la mercancía → se factura al cliente.
Tú tienes el stock. Tú lo envías. Tú facturas. Simple, claro y conocido.
El proceso de terceros: cuando el proveedor envía directamente al cliente
Aquí el flujo cambia completamente. En el proceso de terceros estándar de SAP, al crear la orden de venta con la categoría de ítem TAS se genera automáticamente una solicitud de compra que hay que convertir en orden de compra. El proveedor envía directamente al cliente y tú facturas al cliente basándote en la confirmación de recepción del proveedor.
El flujo real es: orden de venta → solicitud de compra automática → orden de compra al proveedor → proveedor envía al cliente → recibes la factura del proveedor → facturas tú al cliente.
Dos documentos de facturación. Dos flujos. Sin entrega desde tu almacén. Sin movimiento de stock en tu sistema.
¿Por qué confundirlos en el diseño genera problemas?
Porque tienen implicaciones completamente distintas en logística, en contabilidad y en la integración entre SD y MM.
En la orden estándar tienes entrega, picking, packing y salida de mercancías. En terceros no hay entrega — el sistema no genera un documento de entrega porque la mercancía no pasa por tu almacén. Si alguien configura una orden de venta estándar para un proceso de terceros el sistema intentará generar una entrega que nunca va a tener stock. Y ahí empieza el caos. 😅
En contabilidad, la categoría de línea de programación CS es la responsable de activar la solicitud de compra automática y tiene relevancia de facturación F, lo que significa que la factura al cliente solo es posible cuando se registra la entrada de la factura del proveedor. Si no está bien configurado, el departamento de ventas no puede facturar aunque el cliente ya haya recibido la mercancía.
La pregunta que tienes que hacer en el taller de diseño
Antes de configurar el tipo de orden, hay que entender bien el proceso físico:
¿La mercancía pasa por tu almacén o va directamente del proveedor al cliente? ¿Facturas al cliente antes o después de recibir la factura del proveedor? ¿Necesitas visibilidad del stock de ese material en tu sistema?
Con esas tres respuestas sabes exactamente qué tipo de proceso necesitas. Sin ellas... estás configurando a ciegas.
🔎 Función de la Semana
CURRENCY_CONVERTING_FACTOR: conversión de monedas en SAP sin inventar nada
Cuántas veces has visto desarrollos ABAP que hacen conversiones de moneda con lógica propia ( tablas hardcodeadas, factores manuales, divisiones y multiplicaciones a mano ) cuando SAP ya tiene esto resuelto de forma nativa.
DATA: lv_factor TYPE p DECIMALS 9,
lv_factor2 TYPE p DECIMALS 9.
CALL FUNCTION 'CURRENCY_CONVERTING_FACTOR'
EXPORTING
client = sy-mandt
currency = 'USD'
IMPORTING
factor = lv_factor
EXCEPTIONS
not_found = 1
OTHERS = 2.La función devuelve el factor de conversión configurado en SAP para esa moneda , el mismo que usa el sistema internamente para todos sus cálculos financieros. Sin inventar nada. Sin tablas propias. Sin riesgo de que el factor esté desactualizado porque lo mantiene el equipo de tesorería en la configuración estándar.
Se usa junto a CONVERT_TO_LOCAL_CURRENCY cuando necesitas convertir importes entre monedas en desarrollos financieros, informes de controlling multidivisa o integraciones con sistemas externos que trabajan en moneda diferente a la del sistema.
👑 Liderazgo y gestión
El día que un cliente me preguntó si podía salir de SAP
No voy a decir quién era. Pero sí voy a decir lo que me preguntó.
"Guille, sinceramente... ¿merece la pena seguir en SAP o nos buscamos algo más barato?"
Llevaba años en SAP. Tenía su sistema lleno de desarrollos Z, sus procesos modelados, su equipo formado. Y estaba harto de las licencias, de los precios y de sentirse atado.
Me podría haber puesto a venderle SAP. A hablarle de Joule, de BTP, de la hoja de ruta hasta 2040. Habría sido lo cómodo.
En cambio le hice una pregunta.
"¿Cuántos desarrollos Z tienes en el sistema?"
Silencio.
"Muchos."
"¿Tienes documentados todos los procesos que dependen de ellos?"
Más silencio.
Ahí estaba la respuesta real. No en ningún PowerPoint de SAP ni en ninguna propuesta de la competencia.
Y aquí viene el tip que quiero compartir. No sobre SAP. Sobre liderazgo.
El mejor consejo que puedes darle a un cliente no siempre es el que quiere escuchar. Pero sí el que necesita.
Un cliente frustrado con SAP no necesita que le vendas SAP. Necesita que alguien le ayude a entender exactamente en qué situación está, qué le costaría realmente cambiar y si eso tiene sentido para su negocio en este momento.
A veces la respuesta es que sí. Que el sistema se les ha quedado grande, que tienen poco legado y que hay alternativas que encajan mejor con lo que son ahora. He visto esos casos. Son los menos, pero existen.
Pero la mayoría de las veces la respuesta es que no. Que el coste de salir es mayor que el coste de quedarse. Que lo que sienten como una atadura es en realidad años de valor acumulado que no se ve hasta que intentas replicarlo en otro sistema.
Y decir eso ( aunque signifique perder una oportunidad de vender un proyecto de migración ) es exactamente lo que distingue a un consultor de confianza de un vendedor con buena presentación.
Los clientes que duran décadas no son los que te eligieron porque eras el más barato o el que mejor PowerPoint tenía.
Son los que se quedaron porque cuando tuvieron una duda importante... les dijiste la verdad. 😏
💬 Frase del Día
La vida es aquello que te va sucediendo mientras estás ocupado haciendo otros planes.
Vivimos rodeados de objetivos, plazos y planes para el futuro. Sin embargo, muchas veces olvidamos prestar atención al presente: las conversaciones inesperadas, los aprendizajes cotidianos, las personas que nos acompañan y los momentos que no estaban en nuestra agenda.
Esta frase nos recuerda que la vida no empieza cuando alcancemos la próxima meta. Está ocurriendo ahora mismo. Y, en ocasiones, los recuerdos más valiosos nacen precisamente de aquello que nunca planeamos.
🙌 Gracias por leer
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 👋