¿Quieres gestionar los gastos de viaje son salir de SAP?

En GROUPmee hemos desarrollado SAP Power Connector, una solución que integra Captio directamente en tu entorno SAP para automatizar y simplificar la gestión de gastos y viajes corporativos.

Conecta ambos sistemas y elimina tareas manuales, duplicidades y errores en la contabilización, garantizando control financiero, trazabilidad y eficiencia operativa… sin salir de tu ERP

El ecosistema de SAP es mucho más grande de lo que parece… y las consultoras son una pieza clave de ese sistema.

A nivel global, SAP cuenta con más de 25.000 partners entre consultoras, integradores, proveedores de servicios y formación. Es decir, SAP no crece solo… crece apoyándose en una red enorme de empresas que implementan, mantienen y evolucionan sus soluciones.

Si lo bajamos a España, aunque no hay una cifra pública exacta y cerrada, se estima que hay varios cientos de consultoras SAP activas, desde grandes integradores hasta pequeñas empresas especializadas o incluso microconsultoras.

Y aquí viene lo interesante.

Entrar en el mundo SAP no es difícil.
Pero diferenciarse dentro de él… sí lo es.

Porque el mercado está muy maduro. Hay mucha oferta, muchos perfiles y muchas empresas haciendo cosas similares. Eso hace que competir solo por “hacer lo mismo que otros” sea complicado.

Por eso, muchas consultoras que destacan no lo hacen por ser más grandes… sino por ser más específicas:

Al final, el ecosistema SAP funciona casi como una economía propia, donde hay espacio para muchos… pero no todos juegan el mismo juego.

Y ahí es donde está la diferencia.

Si trabajas en SAP y te interesa lo que pasa más allá de los proyectos del día a día, hay un evento que merece la pena tener en el radar: SAP Inside Track Madrid.

Pero lo interesante de este evento no es solo el contenido… es el formato.

SAP Inside Track (SIT) es una iniciativa impulsada por la propia comunidad SAP, no por grandes consultoras ni por el propio SAP como tal. Es decir, está organizado por profesionales del ecosistema para otros profesionales. Y eso se nota.

Aquí no vas a encontrar presentaciones comerciales ni discursos preparados. Lo que hay son sesiones reales, contadas por gente que está trabajando en proyectos, compartiendo experiencias, aprendizajes y también errores.

En el caso de Madrid, el evento reúne a perfiles de todo tipo: desarrolladores, funcionales, BASIS, arquitectos, consultores… todos con algo en común: aprender y compartir.

El contenido suele ser bastante variado:

Pero más allá de las charlas, hay algo que hace especial a este tipo de eventos: el networking.

Es uno de esos espacios donde puedes hablar con gente que está en situaciones similares a la tuya, intercambiar puntos de vista, resolver dudas o incluso abrir puertas a oportunidades futuras.

Además, al ser un evento de comunidad, el ambiente es mucho más cercano. No hay tanta barrera entre quien presenta y quien asiste, lo que facilita mucho más las conversaciones.

Este año, el evento principal será el 17 de abril, pero además el 16 de abril habrá un CodeJam, que suele ser más práctico y técnico, ideal si te gusta trastear y aprender haciendo.

Si te interesa, puedes apuntarte aquí: https://sitmadrid.com/ ( Plazas limitadas )

Y bueno… yo el día 17 estaré por allí también, a ver qué se cuenta la gente 😄

En un entorno como SAP, donde muchas veces aprendemos a base de proyecto y experiencia, eventos como SAP Inside Track aportan algo diferente: conocimiento compartido de forma abierta.

Y eso, hoy en día, tiene mucho valor.

Esta semana, SAP ha mantenido un comportamiento bastante estable en bolsa, en línea con lo que viene mostrando en los últimos meses. No ha habido movimientos bruscos, pero sí una sensación de confianza sostenida por parte del mercado.

Uno de los puntos que sigue pesando positivamente es la evolución de su negocio cloud. Cada vez representa una parte mayor de sus ingresos, lo que aporta previsibilidad y encaja mejor con lo que buscan los inversores hoy en día: modelos recurrentes y escalables.

También influye el posicionamiento de SAP en áreas como inteligencia artificial y automatización, donde está reforzando su propuesta. Aunque estos movimientos todavía no siempre se reflejan de forma inmediata en el precio, sí consolidan una narrativa de crecimiento a medio y largo plazo.

Por otro lado, el contexto global sigue siendo un factor a tener en cuenta. La incertidumbre económica y geopolítica hace que muchos inversores actúen con cautela, lo que explica en parte por qué no vemos grandes subidas, pero tampoco caídas relevantes.

En resumen, SAP no está en una fase de “subidón”, pero sí en una posición bastante sólida: crecimiento progresivo, apuesta clara por el cloud y una estrategia alineada con hacia dónde va el mercado.

Y en bolsa, muchas veces eso vale más que cualquier movimiento puntual.

Cuando hablamos de consultoría SAP muchas veces pensamos en “proyectos” y ya está. Pero la realidad es bastante más compleja. Dentro del ecosistema SAP hay distintos modelos de negocio conviviendo, cada uno con su lógica, su nivel de riesgo y su forma de generar ingresos.

Entender esto no solo te da una visión más completa del mercado, también te ayuda a entender por qué las empresas actúan como actúan… y, si algún día te planteas montar algo, te da una base muy clara de por dónde empezar.

Si nos vamos al modelo más clásico, tenemos las consultoras de proyectos. Son las que implementan SAP desde cero o hacen migraciones grandes como S/4HANA. Aquí es donde se mueve mucho dinero, pero también donde hay más presión. Se venden proyectos cerrados o bolsas grandes de horas, con equipos completos detrás: funcionales, técnicos, BASIS, managers… Todo tiene que encajar.

El problema es que este tipo de negocio tiene un riesgo alto. Las estimaciones rara vez se cumplen al 100%, los cambios de alcance son constantes y el cliente suele apretar mucho. Si gestionas bien, puedes tener buenos márgenes. Si no… puedes perder dinero fácilmente. Es un modelo potente, pero no es sencillo.

Después están las consultoras de mantenimiento, el famoso AMS. Este modelo es mucho más estable. Aquí no se trata de grandes implementaciones, sino de mantener lo que ya existe: incidencias, pequeños evolutivos, soporte diario. Se venden contratos mensuales o bolsas de horas.

No es tan vistoso como un proyecto grande, pero tiene algo muy valioso: recurrencia. Ingresos más predecibles, menos picos de estrés y una relación más continua con el cliente. Eso sí, los márgenes suelen ser más ajustados y es más difícil diferenciarse si no aportas algo más que “horas”.

Otro modelo muy interesante es el de la consultoría independiente o asesoría. Aquí hablamos de perfiles muy senior que no venden horas técnicas, sino criterio. Auditorías, decisiones estratégicas, revisión de arquitecturas… Este modelo tiene márgenes muy altos porque vendes conocimiento puro.

El problema es que depende completamente de la persona. No es fácil escalarlo y necesitas una reputación fuerte para que funcione. Pero bien llevado, es uno de los modelos más rentables que hay.

Luego está el famoso outsourcing o bodyshopping, que aunque a veces tenga mala fama, es uno de los modelos más utilizados. Básicamente consiste en “colocar” perfiles en clientes o en otras consultoras. No vendes un proyecto, vendes personas.

Es fácil de arrancar porque no necesitas una gran estructura ni asumir riesgos técnicos. Pero también es un mercado muy competitivo, con márgenes más bajos y donde la diferenciación es complicada. Aquí gana quien tiene mejor red de contactos y capacidad de mover talento rápido.

En los últimos años ha crecido mucho otro modelo: las consultoras especializadas en integración y servicios cloud, sobre todo alrededor de SAP BTP, APIs y arquitecturas modernas. Aquí ya no se trata tanto de desarrollar dentro de SAP, sino de conectar sistemas, diseñar soluciones y trabajar con servicios.

Este modelo tiene bastante futuro porque cada vez hay más sistemas y más necesidad de integrarlos. Además, los márgenes suelen ser buenos porque el expertise es más escaso. El reto es encontrar talento y mantenerse actualizado.

También tenemos el negocio de la formación. Academias, cursos, certificaciones… Puede parecer secundario, pero mueve bastante dinero. Sobre todo si consigues escalarlo con contenido online. Aquí el conocimiento se convierte en producto.

No es un modelo inmediato, necesitas visibilidad y credibilidad, pero a medio plazo puede ser muy interesante.

Otro modelo más estructurado es el de partners que venden licencias de SAP junto con implementación. Aquí ya entras en una liga diferente. Necesitas certificaciones, relación directa con SAP y una estructura comercial sólida. Es un negocio grande, pero con barreras de entrada altas y bastante dependencia del propio SAP.

Y luego está el modelo más ambicioso: crear producto propio sobre SAP. Add-ons, soluciones específicas, aplicaciones… Aquí ya no vendes horas, vendes software. Si aciertas, es el modelo más escalable y rentable. Pero también el más arriesgado, porque necesitas inversión, tiempo y encontrar un hueco real en el mercado.

Si alguien se plantea montar una consultora desde cero, la realidad es que no tiene sentido empezar por los modelos más complejos. Lo habitual (y lo más inteligente) es empezar por algo más ligero: outsourcing o pequeños servicios. Te permite generar ingresos rápido, entender el mercado y crear una red de contactos.

A partir de ahí, puedes evolucionar hacia mantenimiento (para ganar estabilidad) o especializarte en algo concreto (para diferenciarte). Y ya con cierta base, plantearte proyectos más grandes o incluso producto propio.

Al final, hay una idea que resume bastante bien todo esto.

En SAP, el dinero no está solo en el código.

Está en cómo te posicionas, en el tipo de problema que resuelves y en el nivel de valor que aportas.

Y eso es lo que realmente define qué tipo de consultora eres… y hasta dónde puedes llegar.

Cuando empiezas a trabajar en RAP, hay varios conceptos en CDS que parecen pequeños detalles… pero que en cuanto te equivocas, empiezan los errores raros y la frustración.

Uno de los más típicos es el uso de $projection. Cuando defines asociaciones, no puedes tirar directamente del campo “tal cual” porque el sistema no siempre sabe si te refieres al campo original de la tabla o al alias que tú has definido en la vista. Ahí es donde entra $projection, que básicamente le dice al sistema: “usa el campo tal y como yo lo he expuesto en esta vista”. Es una forma de evitar ambigüedades y, aunque al principio cuesta verlo, en cuanto haces un par de asociaciones complejas, se vuelve imprescindible.

Otro punto que suele aparecer más adelante es $parameters. Esto ya es cuando tus CDS empiezan a parecerse más a funciones que a simples vistas. Puedes definir parámetros de entrada (por ejemplo, fechas) y usarlos directamente en el WHERE. No siempre se usa en escenarios básicos de RAP, pero en cuanto necesitas filtrar de forma dinámica, es una herramienta muy potente. Eso sí, en cuanto defines parámetros, quien consuma esa vista está obligado a pasarlos.

Luego está un clásico: los cálculos. Aquí mucha gente cae en usar operaciones simples como si estuviera en ABAP… y en CDS no funciona igual. Por ejemplo, para calcular un porcentaje, usar directamente una división puede darte resultados truncados. La función division() está precisamente para evitar eso y controlar los decimales. Y normalmente la verás combinada con un cast, porque si no defines bien el tipo de salida, el sistema no siempre sabe cómo tratar el resultado. Es de esas cosas que no parecen importantes… hasta que empiezan a fallar.

Y si hay un error típico en CDS, sobre todo cuando empiezas, es el de los campos de tipo importe (CURR). En SAP, un importe nunca va solo, siempre necesita su moneda asociada. Si sacas un price sin más, el sistema se queja porque no sabe en qué moneda está. La solución es usar la anotación @Semantics.amount.currencyCode, que básicamente enlaza ese importe con su campo de moneda dentro de la misma vista. Es un patrón que vas a repetir constantemente.

Al final, cuando trabajas en RAP, te das cuenta de que CDS no es solo “definir vistas”. Estás modelando datos con reglas bastante estrictas, y estos pequeños detalles marcan la diferencia entre algo que compila… y algo que realmente funciona bien.

Y lo curioso es que la mayoría de errores no vienen de cosas complejas.

Vienen de no controlar bien estos básicos.

Cuando trabajas en SAP SD, hay una regla que con el tiempo acabas aprendiendo sí o sí: siempre que puedas, copia antes de crear desde cero.

A la hora de crear una Sales Organization, que es el nivel más alto dentro de la estructura de ventas, mucha gente tiende a ir directamente a crearla nueva… pero en la práctica, lo más recomendable es utilizar una ya existente como referencia. Esto te permite heredar configuraciones que ya funcionan, evitar errores típicos y, sobre todo, mantener coherencia dentro del sistema. Al final, no se trata de reinventar nada, sino de aprovechar lo que ya está probado.

La creación o copia se hace desde la siguiente ruta:

La Sales Organization representa básicamente la unidad que vende: puede ser una empresa, un país o una unidad de negocio, y es responsable de toda la parte comercial (ventas, precios, facturación, etc.). Todo en SD gira alrededor de ella.

Pero lo importante no es solo crearla, sino entender cómo encaja dentro de la estructura de negocio. En SAP no estás creando objetos técnicos, estás modelando cómo vende el cliente. Y esa estructura se basa en una jerarquía bastante clara:

Esa combinación final, la Sales Area, es la que realmente define cómo se realizan las ventas en el sistema.

Por eso, antes de crear cualquier Sales Organization, lo importante es entender el negocio: cómo vende el cliente, si tiene diferentes canales, distintas líneas de producto o presencia en varios países. Si esto no está claro, la estructura en SAP tampoco lo estará.

En resumen: copia siempre que puedas, piensa primero en el negocio y luego en la configuración, y evita complicar la estructura más de lo necesario. Ahí es donde se nota de verdad la experiencia en SD.

Hay algo que pasa mucho en ABAP: cuando necesitamos convertir fechas, tiramos directamente de las funciones de siempre (CONVERT_DATE_TO_EXTERNAL, CONVERT_DATE_TO_INTERNAL, etc.).

Funcionan, sí.

Pero si estás trabajando en entornos más modernos (RAP, ABAP Cloud o simplemente código limpio), hay una alternativa bastante mejor:

la clase CL_ABAP_DATFM

Y una vez empiezas a usarla, no vuelves atrás.

En lugar de hacer un CALL FUNCTION, puedes trabajar directamente con métodos estáticos mucho más claros y legibles. Por ejemplo, convertir una fecha interna a formato externo es tan simple como:

Y al revés, si recibes una fecha en formato externo (por ejemplo, desde una API o un fichero), puedes convertirla así:

Sin estructuras auxiliares, sin parámetros de import/export… directo y limpio.

Además, esta clase tiene algo importante: respeta automáticamente la configuración del usuario (SU01). Es decir, no tienes que preocuparte por si el formato es DD.MM.YYYY, MM/DD/YYYY o cualquier otro. SAP ya se encarga.

Esto es especialmente útil en:

Porque evita errores típicos de interpretación (día/mes invertido, formatos inconsistentes, etc.).

Otro punto interesante es que este enfoque está mucho más alineado con ABAP moderno. Cada vez se busca más evitar funciones clásicas y trabajar con clases, métodos y expresiones más limpias.

Y si lo combinas con string templates, puedes incluso formatear fechas de forma muy cómoda para salida:

Al final, no es solo una cuestión de “modernizar por modernizar”.

Es que el código queda:

Hay un momento en consultoría SAP en el que te das cuenta de algo importante: el negocio no va realmente de vender horas.

Va de confianza.

Y esto, aunque suene típico, en el día a día no se ve tanto. Muchas veces estamos más pendientes de la imputación, de que el equipo esté ocupado o de cerrar más facturación… que de cómo está percibiendo el cliente el trabajo.

Y ahí es donde se empieza a torcer todo.

Porque un cliente no se queda contigo porque trabajes muchas horas. Se queda cuando siente que puede estar tranquilo. Cuando no tiene que estar detrás, cuando no duda de lo que le dices y cuando sabe que, si hay un problema, se lo vas a contar.

Como responsable, aquí tienes bastante más impacto del que parece.

No es solo que el equipo entregue. Es cómo entrega.

En muchos proyectos SAP pasa lo mismo: se intenta aguantar, parchear o evitar el conflicto… hasta que ya no se puede.

Y cuando eso explota, el problema no es técnico.

Es que el cliente deja de confiar.

Y eso es lo complicado de recuperar.

Al final puedes equivocarte en una estimación, en un desarrollo o en una decisión. Eso entra dentro del juego. Pero cuando se rompe la confianza, el proyecto cambia completamente.

Por eso, más allá de entregar bien, hay algo que deberías tener siempre en mente:

No se trata solo de hacer bien el trabajo.

Se trata de que el cliente no tenga motivos para dudar de ti.

En el mundo SAP (y en la consultoría en general), siempre va a haber alguien más barato.

Siempre.

Si tu única forma de competir es el precio, entras en una guerra que no tiene fin… y que además desgasta muchísimo el negocio.

Las consultoras que realmente funcionan a largo plazo no son las más baratas, son las que aportan algo diferente:

Porque cuando el cliente percibe valor, deja de comparar solo precios.

Y ahí es donde cambian las reglas del juego.

No se trata de ser más barato. Se trata de que no tenga sentido compararte.

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

Hoy hemos salido un poco del código y nos hemos metido en algo igual de importante: cómo funciona realmente el negocio alrededor de SAP. Porque más allá de desarrollos, proyectos o incidencias, hay todo un ecosistema de consultoras, servicios y modelos que muchas veces no vemos… pero en el que todos participamos.

Entender esto cambia bastante la perspectiva. Ya no ves solo tareas o proyectos, empiezas a ver cómo se genera el valor, dónde está el margen y por qué las decisiones se toman como se toman.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta comunidad que no solo quiere hacer SAP… sino entenderlo.

La semana que viene volveremos con más experiencias reales, algún que otro tip y, seguramente, otra reflexión que nos haga ver este mundo desde otro ángulo.

Nos leemos en el próximo boletín.

Un abrazo 👋