¿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.

Índice del boletín

• Dato curioso

• Ultimas noticias

• Información en bolsa

• Mi opinión

• Tip ABAP( Técnico )

• SAP Funcional

• Función de la Semana

• Liderazgo y gestión

• Frase del Día

• Gracias por leer

🔍 Dato Curioso

Hay una idea bastante extendida entre consultores con experiencia:
la mayoría de los problemas en proyectos SAP no son técnicos.

De hecho, muchos análisis de implementaciones ERP muestran que los proyectos suelen fracasar o tener grandes problemas por razones como:

• mala definición de requisitos

• objetivos poco claros

• falta de implicación del negocio

• mala gestión del cambio

• o cambios constantes de alcance durante el proyecto.

Es decir, problemas organizativos y de gestión, no de tecnología.

Diversos análisis sobre implementaciones ERP señalan precisamente esto: los proyectos no se desvían tanto por el software en sí, sino por factores como expectativas irreales, mala planificación o falta de alineación entre negocio y tecnología. ()

Y esto explica algo que todos los consultores terminan descubriendo tarde o temprano.

Cuando un proyecto empieza a torcerse, casi nunca es porque el programa no funcione.

Normalmente es porque:

• el negocio no tenía claro lo que quería

• los requisitos cambiaron durante el desarrollo

• nadie tomó decisiones a tiempo

• o el alcance del proyecto empezó a crecer sin control.

De hecho, hay un concepto muy conocido en gestión de proyectos llamado scope creep, que describe exactamente esto: proyectos que comienzan con un objetivo claro pero que, poco a poco, empiezan a recibir nuevas funcionalidades, cambios y ajustes hasta convertirse en algo mucho más grande de lo que se había estimado inicialmente.

Y si has trabajado en proyectos SAP, probablemente ya sabes cómo termina eso.

Un desarrollo pequeño que iba a durar unas semanas… acaba convirtiéndose en un proyecto eterno.

Por eso muchos consultores experimentados dicen algo que al principio sorprende a los juniors:

El mayor riesgo de un proyecto SAP no está en el código.
Está en la definición del proyecto.

📰 Ultimas noticias

SAP ha anunciado recientemente una nueva actualización dentro de su estrategia de ERP en la nube privada: SAP Cloud ERP Private 2025 FPS01. Puede parecer simplemente otra actualización dentro del calendario habitual de SAP, pero en realidad refleja bastante bien hacia dónde se está moviendo el ecosistema ERP en los próximos años. La idea principal detrás de esta actualización es bastante clara: ofrecer innovación continua dentro del ERP, incorporando capacidades de inteligencia artificial, mejoras en el manejo de datos empresariales y nuevas herramientas que permitan a las organizaciones tomar decisiones más rápidas y mejor fundamentadas.

Durante muchos años, el ERP ha sido principalmente un sistema donde se registraban transacciones. Pedidos, facturas, movimientos de stock, contabilidad… todo pasaba por el ERP y quedaba almacenado en el sistema. Era el corazón operativo de la empresa, pero su papel se limitaba muchas veces a gestionar información y procesos administrativos. Con esta nueva evolución del ERP en la nube privada, SAP quiere cambiar ese enfoque y avanzar hacia un sistema que no solo registre datos, sino que también ayude activamente a interpretarlos y utilizarlos dentro de los procesos de negocio.

Uno de los puntos más importantes de esta actualización es la integración cada vez mayor de inteligencia artificial dentro del propio ERP. SAP está apostando por introducir asistentes inteligentes y agentes que puedan ayudar a analizar situaciones, proponer acciones y automatizar tareas que antes requerían intervención manual. Un ejemplo que se menciona en esta actualización es el nuevo agente de gestión de registros de cambios orientado a equipos de investigación y desarrollo. Este tipo de herramientas permite analizar cambios en productos o procesos, evaluar su impacto y ayudar a los equipos a decidir los siguientes pasos de forma más rápida. La intención es reducir tareas repetitivas y liberar tiempo para que los equipos puedan centrarse en actividades de mayor valor para la organización.

Otro aspecto importante de esta actualización tiene que ver con la forma en la que las empresas utilizan sus datos. SAP está reforzando el concepto de productos de datos preparados para el negocio, es decir, conjuntos de datos que ya están organizados y preparados para ser utilizados directamente en análisis o decisiones empresariales. En muchas compañías, aunque el ERP almacena una enorme cantidad de información, convertir esos datos en algo realmente útil requiere un gran trabajo previo de modelado, integración o preparación. La estrategia actual de SAP busca reducir esa complejidad y acercar más los datos al negocio, facilitando que las empresas puedan analizar información y tomar decisiones de forma más rápida.

La actualización también refuerza la idea de que los ERP modernos deben adaptarse a entornos empresariales cada vez más complejos. Muchas organizaciones operan en múltiples países, con normativas diferentes, mercados cambiantes y una enorme presión por reaccionar rápido a nuevas situaciones. En ese contexto, el ERP ya no puede ser solo un sistema que registre lo que ha ocurrido. Tiene que convertirse en una plataforma que ayude a entender lo que está pasando y que permita actuar con rapidez.

Además, esta actualización encaja dentro de un cambio más amplio en el modelo de evolución del software empresarial. Tradicionalmente, las grandes soluciones ERP se actualizaban mediante grandes proyectos cada varios años. Muchas empresas pasaban largos periodos sin actualizar su sistema porque cada actualización implicaba proyectos complejos y costosos. Con el modelo actual de SAP, especialmente en entornos cloud, la idea es entregar nuevas capacidades de forma progresiva mediante paquetes de funcionalidades que se incorporan de manera continua. De esta forma, las organizaciones pueden ir adoptando mejoras sin tener que enfrentarse a grandes proyectos de actualización cada cierto tiempo.

💹 Información en Bolsa

La acción de SAP SE ha vuelto a generar interés esta semana en los mercados financieros. Aunque las variaciones bursátiles dependen de muchos factores macroeconómicos, el mercado sigue valorando positivamente la transformación estratégica que la compañía alemana está llevando a cabo en los últimos años.

El principal motor de esta evolución es su transición hacia el modelo cloud. SAP está impulsando cada vez más sus soluciones en la nube, especialmente a través de SAP S/4HANA Cloud, que se está convirtiendo en el núcleo de los nuevos proyectos ERP, junto con la SAP Business Technology Platform, que permite integrar, extender y desarrollar aplicaciones alrededor del ecosistema SAP. Este modelo basado en suscripciones genera ingresos recurrentes y más previsibles, algo que los inversores suelen valorar positivamente.

A esto se suma la apuesta creciente de SAP por la inteligencia artificial dentro de sus soluciones empresariales. Con iniciativas como SAP Joule, la compañía busca integrar capacidades de IA directamente en los procesos de negocio, permitiendo analizar datos, automatizar tareas y ayudar a la toma de decisiones dentro del propio entorno SAP.

En conjunto, el mercado parece estar premiando una estrategia clara: cloud, plataformas tecnológicas y aplicaciones inteligentes. Más allá del comportamiento puntual de la bolsa, esta dirección también refleja hacia dónde se dirige el ecosistema SAP y qué áreas tendrán mayor relevancia para consultores y empresas en los próximos años.

🚀 Mi opinión

Y sí… por supuesto que existen proyectos tóxicos, igual que existen relaciones tóxicas.

Al final, un proyecto entre cliente y consultora se basa en dos cosas muy simples: confianza y continuidad en la relación. Es decir, que ambas partes quieran seguir trabajando juntas. No me voy a poner en plan consejero matrimonial 😅 pero sí voy a contaros algunas cosas con las que me he encontrado (y seguro que vosotros también) para que, si os pasa, sepáis detectarlas rápido.

Porque cuanto antes se detecta un proyecto tóxico… menos daño hace.

Muchas veces todo empieza con algo bastante normal: el presupuesto. Imaginemos un caso típico. Llega un cliente nuevo y necesita un desarrollo a medida en SAP. Se hace una primera reunión en la que tú le explicas cómo trabaja tu empresa, cómo gestionáis los desarrollos y cómo se suelen estimar los proyectos. Por su parte, el cliente explica su necesidad y el problema que quiere resolver.

Hasta aquí todo es bastante habitual. Incluso es bastante común que el cliente no tenga completamente claro lo que quiere. Muchas veces no hay un equipo técnico detrás que entienda bien el sistema o el proceso, y para eso precisamente contratan a una consultora: para ayudarles a definir la solución. Pero aun así conviene prestar atención.

Después de esa reunión suele aparecer la conversación sobre las tarifas. Se habla de precios, horas, estimaciones… y se llega a un acuerdo para preparar una estimación del desarrollo. En ese momento es bastante habitual escuchar algo como: “vuestra tarifa es un poco cara”, “¿no podéis rebajar un poco el presupuesto?”, o “otra consultora nos lo hace más barato”. CUIDADO. Esto también puede ser algo relativamente común y no necesariamente significa que el proyecto vaya a ser problemático. Negociar forma parte del juego. Pero cuando toda la conversación gira únicamente alrededor del precio, muchas veces es una pequeña señal de alerta.

Preparas entonces la estimación, envías la PO con el presupuesto y normalmente adjuntas un documento donde se detallan los puntos acordados: qué se va a desarrollar, qué se va a modificar y una explicación general de la solución. Este documento existe por una razón muy simple: dejar claro qué se ha pedido y qué se va a hacer, para que más adelante no haya cambios constantes o interpretaciones diferentes.

Y ahora empieza la parte interesante.

Comienza el proyecto y el primer paso suele ser algo tan simple como pedir accesos al sistema para poder empezar a desarrollar. Y aquí aparece una señal que muchas veces pasa desapercibida: los accesos tardan muchísimo en llegar. Pero muchísimo. Semanas a veces. Esto suele ocurrir por dos motivos bastante claros. O el desarrollo no era tan urgente como parecía… o en realidad no tiene demasiado interés dentro de la organización. Incluso puede ocurrir que el cliente esté empezando a replantearse si realmente quiere hacer ese desarrollo.

Finalmente llegan los accesos y por fin se empieza a desarrollar. Todo avanza más o menos bien hasta que empiezan los ajustes con negocio. Y aparecen los famosos “pequeños cambios”. Cosas aparentemente mínimas: “oye, mejor llama a esta columna ‘presupuesto estimado’”, “hemos pensado que el cálculo debería hacerse de esta forma”, “¿podemos reunirnos con negocio para revisarlo?”. Esto es completamente normal en cualquier proyecto. Los cambios ocurren y no pasa absolutamente nada. El problema aparece cuando esos cambios dejan de ser ajustes y empiezan a convertirse en rediseños constantes.

Hay veces que negocio simplemente está reflexionando mejor sobre la solución mientras el proyecto avanza, y eso es lógico. Pero los cambios deben ser ajustes, no transformar completamente lo que se había acordado al principio.

El proyecto sigue avanzando, llegas prácticamente al final y empiezan las pruebas con negocio. Y aquí puede aparecer otro patrón curioso: tardan muchísimo en probar. En muchos casos ocurre porque negocio no tiene claro cómo probar el desarrollo. Por eso siempre es buena práctica acompañarles, dar ejemplos, explicar cómo validar el sistema o incluso preparar pequeños casos de prueba para facilitar el proceso. Pero aun así, a veces el tiempo pasa… y las pruebas no avanzan.

Cuando finalmente terminan las UATs, llega el momento de transportar el desarrollo a producción. Y aquí aparece otra situación bastante típica: no se fija una fecha clara de transporte. A veces por miedo, a veces por desconocimiento, a veces simplemente por falta de responsabilidad o prioridad dentro del cliente. El resultado es el mismo: el proyecto se queda en una especie de limbo durante semanas.

Finalmente el desarrollo se transporta, el proyecto se cierra, se factura… y todo parece haber terminado.

Hasta que, meses después, empiezan a aparecer los famosos “errores”.

Y aquí es donde la situación se vuelve realmente interesante.

Porque muchas veces esos errores no son errores de verdad. Si hay un error real, por supuesto se corrige sin ningún problema. Forma parte del trabajo. Pero en muchas ocasiones esos supuestos errores son en realidad pequeñas mejoras que el cliente quiere introducir en el desarrollo. Cambios, ajustes o nuevas funcionalidades que no estaban contempladas inicialmente… pero que intentan colar como si fueran fallos del sistema.

Y si no se gestiona bien esta situación, la relación puede convertirse rápidamente en un pozo sin fondo. Empiezas solucionando un pequeño “error”, luego otro, luego otro… hasta que, sin darte cuenta, estás dedicando horas y horas de trabajo gratuito a mejorar un producto que ya estaba terminado.

En ese punto hay que tomar una decisión clara. O se pone un límite, o esa dinámica va a continuar indefinidamente.

Lo más sano en estos casos es proponer alguna de estas soluciones: una bolsa de horas, un contrato de mantenimiento o una nueva estimación con su correspondiente factura para cubrir los cambios solicitados. Y si ninguna de esas opciones les convence… pues es lo que hay.

Porque al final, el tiempo que inviertes desarrollando, corrigiendo o mejorando cosas es dinero. Y si no se gestiona bien, un proyecto que parecía pequeño y sencillo puede acabar convirtiéndose en un agujero del que cuesta mucho salir.

🧠 Tip técnico

Atajos de teclado útiles en ABAP Development Tools (ADT) para Eclipse

Si trabajas con ADT en Eclipse, probablemente ya te hayas dado cuenta de que dominar algunos atajos de teclado puede ahorrarte muchísimo tiempo durante el desarrollo. Muchos desarrolladores ABAP que vienen del SAP GUI tardan un tiempo en acostumbrarse, pero una vez los integras en tu rutina, la productividad aumenta bastante.

Aquí tienes algunos de los atajos más útiles que merece la pena tener siempre a mano:

Ctrl + Shift + A
Permite buscar cualquier objeto del sistema (clases, programas, tablas, CDS, etc.). Es uno de los atajos más usados en ADT.

Ctrl + Shift + R
Abre rápidamente cualquier recurso dentro del workspace.

Ctrl + 1
Muestra las Quick Fix disponibles. Muy útil cuando Eclipse detecta un error o sugiere mejoras automáticas en el código.

F3
Permite navegar directamente a la definición del objeto o método sobre el que estás situado.

Alt + Shift + F
Formatea automáticamente el código ABAP para mantener una estructura limpia y consistente.

Ctrl + Space
Activa el autocompletado de código y sugerencias del editor.

Ctrl + Shift + O
Organiza automáticamente los imports o dependencias necesarias.

Alt + Shift + R
Permite renombrar variables, métodos o elementos en todo el código de forma segura.

Ctrl + Alt + Down / Ctrl + Alt + Up
Duplica la línea actual o mueve líneas de código arriba y abajo.

Ctrl + D
Elimina la línea actual de código.

Aprender y usar estos atajos de forma habitual puede parecer un detalle menor, pero a lo largo del día marcan una gran diferencia. Menos tiempo navegando por menús significa más tiempo centrado en lo que realmente importa: resolver el problema y escribir buen código.

🧩 SAP Funcional

Cosas de Fiori que merece la pena explicar al usuario

Cuando un usuario empieza a trabajar con SAP Fiori, muchas veces solo se le enseña qué apps tiene que utilizar para su trabajo diario. Sin embargo, dedicar unos minutos a explicar ciertas configuraciones y funcionalidades puede mejorar muchísimo su experiencia y evitar bastantes dudas más adelante.

Estas son algunas de las cosas que un consultor funcional debería enseñar o configurar con el usuario cuando empieza a trabajar con Fiori:

1. Personalizar el Launchpad
Los usuarios pueden reorganizar sus aplicaciones dentro de los grupos del Launchpad. Pueden mover apps, ordenarlas según su forma de trabajar o mantener más visibles las que utilizan con mayor frecuencia.

2. Añadir apps a favoritos
Las aplicaciones que se utilizan habitualmente pueden marcarse como favoritas para acceder a ellas más rápidamente sin tener que buscarlas cada vez.

3. Usar el buscador global de Fiori
En lugar de navegar por todos los grupos, el usuario puede buscar directamente una app escribiendo su nombre en el buscador del Launchpad.

4. Crear variantes de filtros
Muchas apps permiten guardar filtros o variantes personalizadas. Esto es muy útil cuando un usuario siempre trabaja con los mismos centros, sociedades o tipos de documento.

5. Personalizar columnas en listas
En muchas aplicaciones es posible añadir o quitar columnas en las tablas para mostrar solo la información que realmente necesita el usuario.

6. Guardar layouts personalizados
Algunas apps permiten guardar configuraciones de visualización para reutilizarlas posteriormente.

7. Navegación entre apps
Explicar que muchas apps permiten navegar a otras relacionadas simplemente haciendo clic sobre documentos, números o elementos del proceso.

8. Uso del historial de navegación
El Launchpad guarda un historial de aplicaciones abiertas recientemente que permite volver a ellas rápidamente.

9. Acceso al menú de usuario
Desde el perfil del usuario se pueden revisar configuraciones personales como idioma, preferencias o ajustes del sistema.

10. Diferencia entre acceso por app y acceso por proceso
Ayudar al usuario a entender que Fiori organiza las funcionalidades por tareas o procesos, no por códigos de transacción como ocurría en SAP GUI.

Explicar estos pequeños detalles no lleva mucho tiempo, pero ayuda muchísimo a que los usuarios se adapten antes a Fiori y trabajen de forma más cómoda dentro del sistema.

🔎 Función de la Semana

VIEW_MAINTENANCE_CALL

Si alguna vez has necesitado abrir el mantenimiento de una tabla desde un programa ABAP, probablemente te hayas preguntado si existe una forma de lanzar directamente la pantalla de la SM30. Y la respuesta es sí.

La función VIEW_MAINTENANCE_CALL permite abrir el mantenimiento de una vista o tabla exactamente igual que si el usuario hubiera entrado manualmente en SM30, pero directamente desde un programa ABAP.

Esto es muy útil cuando quieres facilitar al usuario el acceso a una tabla de customizing sin obligarle a navegar por la transacción.

Uno de los puntos más interesantes de esta función es que permite definir el modo en el que se abre el mantenimiento.

Por ejemplo:

• Modo visualización

• Modo edición / mantenimiento

Esto se controla a través del parámetro ACTION, donde normalmente se utilizan valores como:

• 'S' → Mostrar (Display)

• 'U' → Modificar (Update / Change)

Un ejemplo sencillo de uso sería abrir el mantenimiento de una tabla de customizing directamente desde un programa:

CALL FUNCTION 'VIEW_MAINTENANCE_CALL'
  EXPORTING
    action    = 'U'
    view_name = 'ZMI_TABLA'.

Con esto, el sistema abrirá directamente la pantalla de mantenimiento de esa tabla en modo edición.

Este tipo de función es muy útil cuando desarrollas herramientas internas, programas de administración o utilidades para consultores funcionales, ya que permite dar acceso rápido a tablas de configuración sin tener que explicar rutas o transacciones adicionales.

Además, si la tabla tiene correctamente configurado su Table Maintenance Generator, la experiencia para el usuario será exactamente la misma que entrando desde SM30.

Un pequeño detalle que puede ahorrar bastantes clics… y hacer que algunas utilidades ABAP sean mucho más cómodas de usar.

👑 Liderazgo y gestión

Cuando un proyecto empieza a desviarse, muchas veces el primer error que cometen los responsables de equipo es intentar aguantar la situación demasiado tiempo esperando que se resuelva sola.

El funcional intenta adaptarse, el técnico intenta encajar los cambios, se hacen reuniones adicionales… y el proyecto sigue avanzando, pero cada vez con más fricción.

Aquí es donde entra una de las habilidades más importantes de liderazgo en consultoría: saber cuándo escalar una conversación.

Un líder de equipo debe entender que ni el funcional ni el desarrollador están para gestionar tensiones con el cliente ni para tomar decisiones de alcance o presupuesto. Si el cliente empieza a introducir cambios constantes, retrasar decisiones o generar situaciones que bloquean el avance del proyecto, el responsable debe intervenir y asumir esa conversación.

Y no se trata de confrontar, sino de ordenar el proyecto desde una perspectiva de servicio.

El líder es quien debe hablar con el cliente para clarificar prioridades, redefinir el ritmo del proyecto o plantear nuevas formas de gestionar las peticiones que están apareciendo. Esto permite liberar al equipo de esa presión y devolver el foco a lo que realmente aporta valor: construir la solución.

Una de las señales más claras de madurez en liderazgo técnico es entender que no todo se resuelve trabajando más horas o intentando encajar más cambios, sino tomando decisiones sobre cómo se gestiona el proyecto.

Porque cuando el responsable interviene en el momento adecuado, el equipo puede seguir avanzando con claridad. Y cuando no lo hace, el riesgo es que el proyecto acabe desgastando a las personas que están intentando sacarlo adelante.

💬 Frase del Día

En el mundo SAP muchas veces parece que el crecimiento llega de golpe: un nuevo rol, un proyecto grande o una promoción. Pero en realidad todo suele ser el resultado de muchos pequeños avances acumulados: entender mejor un proceso, aprender una nueva herramienta, ayudar a un compañero o asumir más responsabilidad en un proyecto. La constancia diaria suele ser lo que, con el tiempo, termina construyendo una carrera sólida.

🙌 Gracias por leer

Y con esto cerramos por hoy.

En este boletín hay tips, herramientas y dilemas técnicos… pero también hay algo más importante: curiosidad, experiencia compartida y ganas de seguir aprendiendo. Porque al final, por encima del ERP, estamos nosotros, intentando hacerlo un poco mejor cada día.

Gracias por estar al otro lado una semana más.

Nos leemos el martes que viene, con nuevos enfoques, más temas del día a día… y, si sale bien, alguna idea que se quede dando vueltas.

Un saludo grande 👋