De la firma en papel a la aprobación digital: un caso real en SAP MM
Una empresa industrial tenía un problema habitual en SAP MM: contratos, solicitudes y pedidos que necesitaban aprobación interna acababan saliendo del sistema para circular por correo o en papel, con todo el retraso y la falta de control que eso implica.
Con la implantación del Conector SAP Signaturit de GROUPmee, ese flujo pasó a ser completamente digital y automático.
Índice del boletín
🔍 Dato Curioso
El miedo a la IA está afectando la salud mental de los profesionales tecnológicos. Y nadie lo dice en voz alta.
Investigadores advierten que el miedo constante a la automatización y a la sustitución por inteligencia artificial está generando ansiedad, pérdida de identidad profesional y nuevas tensiones en el entorno laboral.
No es un miedo menor ni irracional. Es un miedo real que está afectando a millones de profesionales tecnológicos en todo el mundo. Y en el ecosistema SAP ( donde llevamos meses hablando de Joule, de agentes autónomos y de la Empresa Autónoma ) ese miedo tiene nombre y apellidos concretos.
Pero hay un dato que me parece más revelador que cualquier otro: el 67% de los ejecutivos está de acuerdo en que los agentes de IA transformarán drásticamente los roles existentes en los próximos 12 meses. Sin embargo el 48% de esos mismos ejecutivos dice que probablemente aumentará el headcount debido a los cambios que la IA traerá.
Léelo de nuevo. Más de la mitad de los que creen que la IA va a transformar los roles... también creen que van a necesitar más personas. No menos.
Además los expertos advierten de un efecto más sutil: el uso prolongado de herramientas de IA puede erosionar la confianza en las propias habilidades o generar lo que llaman "atrofia de competencias", al delegar funciones clave en sistemas automatizados.
El peligro real no es que la IA te quite el trabajo. Es que dejes de confiar en lo que sabes hacer porque tienes una herramienta que lo hace por ti.
)
📰 Ultimas noticias
SAP apuesta por reinventar la selección de personal con IA
SAP ha publicado esta semana un caso interesante sobre cómo está transformando sus procesos de contratación utilizando la plataforma SmartRecruiters, una compañía especializada en selección de talento que SAP adquirió recientemente.
La idea es sencilla: reducir al máximo las tareas administrativas que consumen tiempo a los equipos de Recursos Humanos y permitir que se centren más en evaluar personas que en gestionar procesos.
Para ello, SAP está integrando inteligencia artificial en diferentes fases del reclutamiento. Desde el filtrado inicial de candidatos hasta la programación de entrevistas o la identificación de perfiles que encajan mejor con una vacante determinada.
Lo interesante es que la estrategia de SAP no consiste únicamente en añadir IA a una herramienta de selección, sino en conectar todo el ecosistema de datos de empleados, competencias y necesidades de negocio para tomar decisiones más rápidas y fundamentadas.
¿La lectura entre líneas?
Que la IA no viene necesariamente a sustituir a los reclutadores, sino a eliminar gran parte del trabajo repetitivo que tradicionalmente ocupaba buena parte de su jornada.
Y esto no afecta solo a Recursos Humanos.
Es otro ejemplo más de hacia dónde se está moviendo SAP: automatizar tareas operativas para que las personas puedan dedicar más tiempo a actividades de mayor valor añadido.
Una tendencia que probablemente veremos cada vez más en otros módulos y procesos del ecosistema SAP durante los próximos años.
💹 Información en Bolsa
Las acciones de SAP han cerrado la semana moviéndose en la zona de los 158-160 € por acción, después de varias semanas bastante positivas para el valor.
Si lo comparamos con hace dos semanas, cuando rondaba los 150-152 €, SAP acumula una subida cercana al 5%.
La principal razón sigue siendo la misma: el mercado continúa valorando muy positivamente el crecimiento del negocio cloud y las expectativas alrededor de la inteligencia artificial.
Además, SAP sigue manteniendo una capitalización superior a los 190.000 millones de euros, consolidándose como una de las compañías tecnológicas más valiosas de Europa.
Por ahora, los inversores parecen confiar en que la apuesta por cloud, BTP y herramientas como Joule seguirá impulsando el crecimiento durante los próximos años.
🚀 Mi Opinión
Voy a escribir algo que no suelo escribir en este boletín.
Algo personal. Algo que no está en ninguna presentación de SAP, en ningún grupo de WhatsApp de consultores ni en ninguna conversación de pasillo en un proyecto. Algo que he pensado muchas veces solo y que creo que muchos de vosotros habéis pensado también... pero que nadie dice en voz alta porque en LinkedIn no queda bien admitir que tienes miedo.
Pues yo lo digo.
Tengo miedo.
Bueno. Miedo miedo... tampoco. 😅
No es el miedo de quien no sabe qué va a pasar con su trabajo. No es el miedo del que no entiende lo que está cambiando. No es el miedo de quien se queda en blanco cuando le preguntan qué es un agente de IA o cómo funciona Joule.
Es más bien una incomodidad. Una pregunta que aparece a veces a las 11 de la noche con el portátil abierto. Una sensación que no tiene nombre técnico ni entrada en el SAP Help Portal.
Y precisamente porque sé lo que está pasando , porque lo veo en los proyectos, porque lo estudio cada semana, porque soy de los que defiende SAP incluso cuando da motivos para no hacerlo, ese runrún molesta más que si viniera de la ignorancia.
Así que voy a contároslo. Con la misma honestidad con la que os cuento todo lo demás en este boletín.
El miedo que nadie nombra
Cuando llevas años en SAP , construyes algo que va más allá del conocimiento técnico. Construyes una identidad profesional. Sabes cómo leer un sistema, cómo hablar con un cliente, cómo diagnosticar un problema en treinta segundos. Sabes lo que nadie te ha enseñado porque lo has vivido.
Y entonces llega la IA. Y hace en segundos cosas que a ti te costaron años aprender.
No digo que lo haga mejor. No digo que lo haga con el criterio que da la experiencia. Pero lo hace rápido. Y lo hace de forma visible. Y hay clientes que miran eso y se preguntan en voz baja si realmente necesitan a alguien que lleva años acumulando ese conocimiento.
Ese es el miedo real. No "¿me va a quitar el trabajo la IA?" Sino algo más profundo: ¿sigue valiendo lo que sé?
La respuesta honesta que me doy a mí mismo
Sí. Pero con algún que otro punto que matizar.
Lo que sé hacer no lo hace ninguna IA. No porque la IA no sea capaz técnicamente ( en muchos casos lo es ) sino porque lo que realmente vale en un proyecto SAP no es ejecutar una tarea. Es entender por qué esa tarea importa, para qué negocio, en qué contexto, con qué consecuencias si algo sale mal.
El propio CEO de SAP lo reconoció en Sapphire: "En los negocios un 80% de precisión no es suficiente cuando se trata de gestionar nóminas, flujos financieros o planificar la demanda."
La IA puede llegar al 80%. El criterio, la experiencia y la responsabilidad de saber cuándo ese 80% no es suficiente... eso lo pone el consultor. Todavía. Y espero que durante mucho tiempo.
Pero la parte que más me inquieta no es la técnica. Es el coste.
El tema de los tokens
Hay una conversación que está empezando a ocurrir en proyectos reales y que en los próximos años va a ser mucho más frecuente: el coste de la IA en producción.
Joule, los agentes de SAP, BTP, Integration Suite con IA integrada... todo eso consume tokens. Y los tokens cuestan dinero. Y ese dinero lo paga el cliente.
Ahora mismo muchos clientes no lo ven porque están en períodos gratuitos, porque los volúmenes son bajos o porque el coste está diluido en contratos más grandes. Pero cuando los agentes lleven un año en producción, cuando los volúmenes crezcan, cuando empiecen a llegar las facturas reales de consumo de AI Units...
Esa conversación va a ser muy incómoda. Y el consultor que esté en esa reunión va a necesitar tener muy claro qué valor justifica ese coste. Porque "es que la IA lo hace automático" no va a ser suficiente respuesta cuando el cliente vea que le cuesta más de lo que ahorra.
( Cosa que ya esta pasando… )
Lo de que nadie es imprescindible
Esto también lo pienso. Y creo que es sano pensarlo.
Nadie es imprescindible. Ni yo. Ni el ABAPER más senior del proyecto. Ni el funcional con veinte años de FI. Ni el BASIS que conoce el landscape de memoria.
Pero hay una diferencia enorme entre no ser imprescindible y no ser valioso. Lo primero es una realidad universal, ninguna empresa debería depender de una sola persona para funcionar. Lo segundo es una elección, decides cada día si lo que aportas justifica tu presencia o no.
El consultor que cree que es imprescindible por lo que sabe va a tener un problema. El que sabe que no es imprescindible pero trabaja cada día para ser genuinamente valioso... ese tiene el modelo correcto.
La IA no cambia eso. Lo acelera. Lo hace más visible. Lo pone a prueba más rápido. Pero el principio es el mismo que siempre.
Por qué sigo aquí a pesar del “miedo”
Porque me gusta lo que hago. Porque me gusta SAP a pesar de sus defectos. Porque me gusta hablar con clientes y entender su negocio.
Porque me gusta cuando algo que diseñé bien funciona en producción sin incidencias. Porque me gusta enseñar lo que sé y ver cómo otros crecen con ello.
Ningún agente de IA va a querer hacer eso. Porque los agentes no quieren nada. Ejecutan.
Y hay algo en querer hacer bien tu trabajo ( en que te importe de verdad ) que no se automatiza. Al menos de momento….
🧩 SAP Técnico
Application Jobs: el SUBMIT ya no existe en ABAP Cloud y esto es lo que lo reemplaza
Hay un momento muy concreto en el que todo ABAPER con experiencia clásica que llega a ABAP Cloud se detiene y mira la pantalla con cara de confusión.
"¿Cómo programo un job en background aquí?"
La SM36 no existe. El SUBMIT en background no existe. El JOB_OPEN / JOB_SUBMIT / JOB_CLOSE tampoco.
Bienvenido al mundo de los Application Jobs. 😄
¿Qué son y por qué existen?
En los sistemas ECC clásicos los desarrolladores usaban SUBMIT o los módulos de función JOB_OPEN, JOB_SUBMIT y JOB_CLOSE para programar jobs en background. Con la evolución a S/4HANA Cloud y BTP ABAP Environment ese mecanismo ha cambiado significativamente. El nuevo paradigma gira en torno a los Application Job Templates y el Application Job Framework.
La idea detrás es desacoplar la lógica de negocio de la programación del job. En lugar de un programa ABAP que se ejecuta en background, tienes una clase ABAP con interfaces específicas que el framework ejecuta de forma controlada, con log integrado, con parámetros configurables desde Fiori y con visibilidad completa del estado en tiempo real.
¿Cómo funciona en la práctica?
El proceso tiene tres pasos: primero creas la clase ABAP implementando las interfaces IF_APJ_DT_EXEC_OBJECT para los metadatos del job y IF_APJ_RT_RUN para la lógica de ejecución. Luego creas un Job Catalog Entry y un Job Template asociados a esa clase. Finalmente el job se programa desde la app Fiori "Schedule Application Jobs" del Launchpad.
CLASS zcl_mi_application_job DEFINITION PUBLIC.
PUBLIC SECTION.
INTERFACES if_apj_dt_exec_object.
INTERFACES if_apj_rt_run.
ENDCLASS.
CLASS zcl_mi_application_job IMPLEMENTATION.
METHOD if_apj_rt_run~execute.
"Tu lógica de negocio aquí
"Usar CL_BALI_LOG para logging
DATA(lo_log) = cl_bali_log=>create_with_header(
header = cl_bali_header_setter=>create(
object = 'ZMI_JOB'
subobject = 'EXECUTE' ) ).
"Añadir mensajes al log
cl_bali_log_db=>get_instance( )->save_log( lo_log ).
ENDMETHOD.
ENDCLASS.Lo que cambia respecto al mundo clásico
Hay tres diferencias fundamentales que todo ABAPER tiene que interiorizar:
El log es obligatorio y estructurado. La clase CL_BALI_LOG reemplaza al log de aplicación clásico SLG1 en entornos cloud, con una API orientada a objetos que escribe mensajes estructurados visibles directamente desde la app Fiori del job. No hay excusa para un job sin log en ABAP Cloud.
Los parámetros van en la clase, no en variantes. Las variantes de selección clásicas no existen aquí. Los parámetros se definen en la interfaz de diseño del job y se configuran en el template de Fiori.
La programación la hace el usuario desde Fiori. El técnico no entra a SM36. El usuario de negocio programa el job desde su Launchpad con los parámetros que necesita. Más autonomía para el negocio, menos dependencia del BASIS para cada cambio de planificación.
🧩 SAP Funcional
Aviso vs Orden de Mantenimiento en SAP PM: la diferencia que define cómo funciona tu departamento de mantenimiento
Hay una confusión que aparece en casi todos los proyectos de SAP PM y que si no se resuelve bien desde el principio acaba generando un historial técnico inútil y unos KPIs que no reflejan la realidad del taller.
¿Cuándo usas un aviso? ¿Cuándo creas una orden? ¿O siempre las dos?
El aviso: la señal de que algo pasa
Los avisos se utilizan para describir la condición técnica excepcional de un objeto, efectuar una solicitud al departamento de mantenimiento o informar sobre un trabajo ya realizado.
El aviso es el punto de entrada. Es donde el operario, el técnico o el propio sistema registra que algo ha ocurrido o que algo necesita atención. Una avería, una anomalía detectada en una ronda de inspección, una solicitud de intervención... todo eso entra como aviso.
Lo importante es que el aviso no ejecuta nada. Solo registra y solicita. Y eso tiene un valor enorme para el historial técnico del equipo ( si se usa bien ).
La orden: donde ocurre el trabajo real
La orden de mantenimiento es el objeto técnico que indica los trabajos y los costes utilizados por cada actividad ( mano de obra interna, externa, materiales, repuestos, servicios propios o de terceros ).
La orden es donde se planifica el trabajo, se asignan recursos, se registran tiempos y se imputan costes. Sin orden no hay imputación de costes. Sin imputación de costes no sabes cuánto te cuesta mantener cada equipo. Y sin saber cuánto te cuesta... tomar decisiones sobre reemplazar o reparar es prácticamente imposible.
¿Siempre van juntos?
No. Y aquí está el matiz que más se suele ignorar en el diseño.
Existen rutinas de mantenimiento simples ( una inspección visual, una revisión rápida ) que no necesariamente requieren una orden. Para esos casos es suficiente un aviso. Para el mantenimiento preventivo planificado, en cambio, es recomendable usar órdenes porque permiten añadir operaciones con todas las especificaciones de tareas, tiempos y recursos.
La regla práctica es sencilla: si el trabajo tiene coste asociado ( horas de mano de obra, materiales, servicios externos ) necesita una orden. Si solo es un registro de lo que se ha visto o comprobado... un aviso es suficiente.
El error clásico en proyectos PM
Diseñar el proceso de mantenimiento sin tener claro qué información necesita el responsable de mantenimiento para tomar decisiones. El usuario final debe estar bien educado sobre los tipos de órdenes y saber cuándo usar cada uno para garantizar una mejor fiabilidad y documentación. De lo contrario el análisis de datos quedará distorsionado.
Si todo el mundo crea avisos pero nadie los convierte en órdenes... tienes un buzón de sugerencias, no un sistema de mantenimiento. Y si todo el mundo crea órdenes directamente sin avisos previos... pierdes el historial de incidencias que es el oro del departamento de mantenimiento.
🔎 Función de la Semana
FINB_BAPIRET2_DISPLAY: muestra todos los mensajes de una BAPI en un popup con una sola línea
FINB_BAPIRET2_DISPLAY es un módulo de función estándar de SAP del grupo FINB_ALV_REPORTING que acepta una tabla interna de tipo BAPIRET2 y la muestra en un popup al usuario con sus iconos de error, warning y success automáticamente
CALL FUNCTION 'FINB_BAPIRET2_DISPLAY'
EXPORTING
it_message = lt_return. "Tabla TYPE TABLE OF BAPIRET2Una línea. Sin construir ningún popup propio, sin bucles para leer mensajes, sin formatear iconos manualmente. El sistema muestra todos los mensajes de la tabla RETURN con el mismo estilo visual que transacciones estándar como MIGO , iconos rojos, amarillos y verdes perfectamente formateados.
La comunidad SAP lleva años recomendándola como la forma más rápida y limpia de mostrar mensajes BAPIRET2 al usuario, precisamente porque es compatible directamente con el tipo estándar BAPIRET2 sin necesidad de conversión previa.
¿Cuándo usarla?
En cualquier desarrollo que llame a BAPIs y necesite mostrar el resultado al usuario , creación de documentos FI, pedidos de venta, materiales maestros, cualquier proceso batch con feedback al usuario. También es perfecta en programas de carga masiva donde quieres mostrar un resumen completo de todos los mensajes generados.
Un matiz importante:
Esta función no está marcada como released para ABAP Cloud. Es perfectamente válida en desarrollos clásicos sobre ECC y S/4HANA On-Premise, pero si estás en un entorno ABAP Cloud con restricciones Clean Core tendrás que usar el Application Log con CL_BALI_LOG como alternativa
👑 Liderazgo y gestión
Lo que haces cuando tienes miedo dice más de ti que lo que haces cuando todo va bien
Este tip de liderazgo no va de SAP. Va de algo más importante.
Va de qué haces con el miedo cuando aparece.
Porque el miedo en el ecosistema SAP ahora mismo es real. Lo he descrito en el artículo de este número. Y si eres responsable de un equipo ( o simplemente alguien que lidera aunque sea sin título ) la forma en que gestionas ese miedo, el tuyo y el de los que están contigo, define el tipo de profesional que eres.
El líder que esconde el miedo
Hay un tipo de líder que cree que admitir incertidumbre es una señal de debilidad. Que si no tiene todas las respuestas no puede mostrarlo. Que el equipo necesita ver seguridad aunque por dentro haya dudas.
Ese líder genera un ambiente donde nadie puede admitir que tampoco sabe. Donde las preguntas incómodas no se hacen porque parece que todos deberían tener ya las respuestas. Donde el miedo existe pero se disfraza de entusiasmo forzado cada vez que alguien menciona la IA o el cloud.
Y ese ambiente es exactamente el peor para adaptarse a lo que está cambiando. Porque adaptarse requiere honestidad. Requiere poder decir "no sé esto todavía" sin que eso sea un problema.
Lo que hace un buen líder con el miedo
Lo nombra.
No para derrumbarse. No para contagiar la angustia al equipo. Sino porque nombrar el miedo es el primer paso para gestionarlo con criterio en lugar de reaccionar desde la ansiedad.
Una conversación honesta con tu equipo sobre lo que está cambiando en el ecosistema SAP, sobre qué partes de vuestro trabajo van a evolucionar y sobre qué necesitáis aprender juntos... vale más que diez presentaciones de PowerPoint sobre la estrategia de IA de la compañía.
La conversación sobre la IA ya no es solo de expertos tecnológicos. El empleo, la capacitación, el futuro laboral y la identidad profesional aparecen hoy entre las principales preocupaciones vinculadas al avance de la IA. Tu equipo lo está pensando aunque no lo diga. Y si tú no abres esa conversación, alguien más la va a abrir. En LinkedIn. En una entrevista con otra empresa. O en silencio.
El único antídoto real contra el miedo tecnológico
No es la formación. No es la certificación. No es el roadmap de aprendizaje.
Es la acción.
Empezar a usar las herramientas que dan miedo. Equivocarse con ellas en entornos seguros. Aprender no porque haya un examen sino porque hay un problema real que resolver.
El miedo a la IA desaparece la primera vez que usas la IA para resolver algo concreto y ves que el resultado es útil pero imperfecto. Que necesita tu criterio para ser bueno. Que sin tu contexto es solo texto bien formateado.
Ese momento cuando la IA deja de ser una amenaza abstracta y se convierte en una herramienta con limitaciones reales, es el momento en que el miedo se convierte en algo mucho más útil: curiosidad.
💬 Frase del Día
Haz cada día una cosa que te dé miedo
El miedo suele tener mala fama.
Intentamos evitarlo, esquivarlo o esperar a que desaparezca antes de actuar.
Pero muchas veces ocurre justo lo contrario.
Las oportunidades más importantes suelen estar al otro lado de una conversación incómoda, de una responsabilidad nueva o de un reto para el que no nos sentimos completamente preparados.
Presentar delante de un cliente, liderar un equipo, asumir un proyecto complicado o salir de nuestra zona de confort da vértigo. Y es normal.
Lo curioso es que, cuando miramos atrás, los mayores avances de nuestra carrera rara vez nacieron de momentos cómodos.
Casi siempre nacieron de situaciones que al principio daban un poco de miedo.
Porque el miedo no siempre es una señal para detenerse.
A veces es una señal de que estás creciendo.
🙌 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 👋
Envíame un correo sobre un tema que quieras que salga en la newsletter a [email protected] o contesta a este email.