🔍 Dato Curioso

Cuando SAP R/3 empezó a expandirse en los años 90, los proyectos no tenían esa separación tan marcada entre consultor funcional y consultor técnico.

Los consultores eran auténticos “hombres/mujeres orquesta”: configuraban el customizing, entendían los procesos de negocio, y si hacía falta… también se metían a picar código ABAP. Eran consultores end-to-end, capaces de levantar un proceso de nómina o un flujo de ventas y, acto seguido, ajustar un módulo de funciones en el sistema.

Con el paso del tiempo, SAP fue creciendo en complejidad:

• Aparecieron más módulos (FI, CO, HR, SD, MM, etc.).

• Los programas en ABAP pasaron de ser simples ajustes a sistemas enteros con miles de líneas.

👉 Y ahí nació la división: por un lado, los funcionales, que entienden el negocio y traducen las necesidades; y por otro, los técnicos, que hacen realidad esas necesidades en el sistema.

Lo curioso es que esta separación trajo consigo también los típicos “choques” de proyecto:

• El funcional pide “solo un campito más”… y al técnico le toca reventar medio esquema.

• El técnico cambia algo “rápido en código” sin avisar… y al funcional le saltan errores en pruebas.

Al final, lo que nació como especialización para mejorar la calidad de los proyectos, acabó creando también la sensación de que funcional y técnico son “bandos distintos”.

😅 La realidad es que no son enemigos, sino dos piezas de un mismo engranaje. Y si alguno falla, el proyecto entero se tambalea.

📰 Ultimas noticias

SAP lanza modelo “On-Site” dentro de su Sovereign Cloud

¿Qué es? SAP ha presentado una expansión de su oferta de Sovereign Cloud con el modelo “On-Site”, que permite a los clientes alojar infraestructura gestionada por SAP directamente en sus propias instalaciones.

Esto representa un avance clave en términos de:

• Soberanía de datos: podrás controlar físicamente tus datos alojándolos en tu propio centro.

• Cumplimiento regulatorio: ideal para sectores altamente regulados (gobierno, salud, finanzas).

• Flexibilidad de despliegue: opciones SAP-hosted, en la nube pública o en local, combinadas con soporte operativo y técnico de SAP.

Este movimiento responde a la creciente demanda global de control total sobre los datos y se alinea con otras propuestas similares de Google Cloud, AWS o Microsoft.

💹 Información en Bolsa

Breve resumen sobre la cotización de SAP

• Rendimiento bursátil reciente: Las acciones de SAP cotizan alrededor de los 269 USD, lo que representa una ligera caída del –1,1 % en el día 

• Perspectiva de los analistas: Evalúan la acción con un rating “Buy”, y proyectan un potencial de subida de alrededor del 18 % en los próximos 12 meses, hasta unos 317 USD como precio objetivo

Contexto y factores clave

Un informe reciente de Barron’s destaca a SAP como el referente tecnológico europeo, equiparable a los gigantes del “Magnificent Seven” de EE. UU. Aunque la empresa sufrió un retroceso bursátil del 10 % tras sus resultados del segundo trimestre (Q2 2025) —debido a expectativas algo frustradas en ingresos en la nube—, esto ha sido interpretado como una oportunidad de compra para inversores .

Algunos de los puntos que refuerzan esta visión positiva son:

• SAP lidera el mercado global de ERP con un 17 % de cuota, por delante de competidores como Workday y Oracle.

• Cuenta con una alta recurrencia de ingresos (86 %) y una retención de clientes excepcional: 96 %.

• Su cartera de pedidos en la nube continúa expandiéndose, con un crecimiento del backlog del 28 % interanual.

Un análisis de Barron’s resalta que, pese a su elevada valoración, los múltiplos de SAP son razonables cuando se ajustan por flujo de caja libre y compensación basada en acciones; y, además, mantiene una sólida trayectoria en crecimiento desde su pivot a la nube y la IA .

🚀 Innovación IT

Durante años, los proyectos SAP han tenido esa “frontera” entre el consultor funcional y el técnico: uno pide cambios, el otro los ejecuta, y muchas veces parece que hablan idiomas distintos.

Con SAP Build Apps, parte de SAP BTP, esa frontera empieza a difuminarse.
👉 Los consultores funcionales pueden crear apps simples, formularios o prototipos sin necesidad de escribir código, mientras que los técnicos se centran en lo que realmente aporta valor: integraciones, performance, seguridad y desarrollos complejos.

Ejemplo rápido

Un funcional de RRHH quiere una app para gestionar vacaciones:

• Con Build Apps monta en 1 día un prototipo con pantallas básicas.

• El técnico después lo toma, añade servicios OData, lógica de negocio y despliegue seguro.

⏱️ Resultado: lo que antes podía tardar 2 meses de idas y venidas, ahora se convierte en 2 semanas de trabajo conjunto.

🔎 Mi opinión personal

Aunque la idea de low-code/no-code es una innovación potente y abre puertas a los funcionales, considero que todavía está muy verde.

• Sí, es útil para prototipos y pruebas rápidas.

• Pero cuando se requiere un desarrollo más complejo, escalable y seguro… al final siempre se necesita el apoyo de un técnico.

En otras palabras: Build no reemplaza la colaboración entre roles, sino que la hace todavía más necesaria.

🧠 Tip ABAP

Escena típica:

• El funcional trae un requerimiento: “Necesito un nuevo reporte con ciertos campos y filtros”.

• El técnico piensa: “Fácil, me monto un SELECT gigante con LOOPs y lo saco todo con WRITE”.

Pero aquí está el detalle:
👉 A veces funcional no sabe que esos datos están disponibles en una vista estándar de SAP o incluso en una transacción existente.
Ejemplo real → Reporte de materiales por centro y proveedor.

• El funcional ya sabe que en SPRO → MM → Información de proveedor está todo el customizing hecho.

• Con una vista CDS o explotando una SQVI / Query bien diseñada, el resultado se consigue más rápido y estándar, sin necesidad de un Z-programa eterno.

💡 TIP Técnico

Antes de lanzarte a picar código:

1. Pregunta al funcional si el dato ya existe en customizing o en tablas estándar.

2. Revisa primero herramientas estándar (ALV preconfigurados, Queries, CDS Views, Fiori Apps).

3. Evita programar “desde cero” si el negocio lo puede resolver con lo que SAP ya trae.

✅ A veces la mejor optimización técnica no es un READ TABLE ni un SELECT mejorado… es escuchar al funcional.
Te ahorras tiempo, evitas duplicar lógica y el cliente recibe algo estándar, mantenible y más fácil de justificar en auditoría.

🧩 SAP Funcional

Seguro que más de un técnico y funcional ha vivido esta escena:

• El funcional dice: “Oye, necesito solo un campito nuevo en la pantalla de nómina/ventas/compras. Es una chorrada, nada complicado”.

• El técnico sonríe con desconfianza… porque sabe que esa frase es el inicio de una historia de terror.

Ejemplo real → Gestión de pedidos de compras (MM):
SPRO → Gestión de materiales → Compras → Solicitud de pedido → Campos de cliente en la pantalla de solicitud de pedido.

👉 El funcional piensa: “Bah, activo un campo en customizing y listo”.
Pero en realidad:

• Ese campo afecta al diseño de la pantalla de ME21N/ME22N.

• Requiere un append en la estructura de la BADI ME_PROCESS_PO_CUST.

• Hay que ajustar formularios (Smartforms / Adobe) que imprimen el pedido.

• Y, por si fuera poco, se toca también la integración con FI porque el campo influye en contabilización.

💡 TIP Funcional

Cuando necesites “un campito más”:

1. Revisa la SPRO y documenta el customizing exacto.

2. Valida si hay BAdIs o User-Exits asociados al objeto que quieres ampliar.

3. Incluye en la especificación técnica:

   • Transacciones afectadas (ej. ME21N, ME22N, ME23N).

   • Formularios/reportes relacionados.

   • Integraciones posibles (FI, SD, HR, etc.).

Así el técnico no descubre a mitad del desarrollo que el cambio era mucho más profundo de lo que parecía.

✅En SAP, no existen los “campos inocentes”.
Un buen análisis funcional en la SPRO = menos horas de ABAP, menos reprocesos y menos cara de odio del técnico 😉.

🔎 Función de la Semana

RZL_SLEEP

Sí, existe una función en SAP… para que el programa “duerma” unos segundos.
Se suele usar en escenarios donde:

• Lanzas procesos en background y necesitas esperar a que otro job termine.

• Sincronizas llamadas a sistemas externos.

• O simplemente para pruebas de rendimiento/debug.

Ejemplo práctico:

DATA lv_seconds TYPE i VALUE 5.

WRITE: / 'Empieza el proceso a las:', sy-uzeit.

" Dormimos 5 segundos
CALL FUNCTION 'RZL_SLEEP'
  EXPORTING
    seconds = lv_seconds.

WRITE: / 'Terminó el proceso a las:', sy-uzeit.

👉 Resultado: El programa se queda “parado” durante 5 segundos antes de continuar.

💡 ¿Por qué es interesante?

• Porque es de esas funciones que casi nadie conoce, pero en escenarios de testing o integraciones puede salvarte.

• Evita tener que inventarte bucles infinitos para forzar tiempos de espera (que consumen CPU innecesariamente).

• Te da control fino sobre esperas controladas sin ensuciar tu código.

✅ A veces no se trata de correr más rápido… sino de saber cuándo parar un rato 😉.

👑 Liderazgo y Gestión

🧠 Tip de Liderazgo: Del choque al equipo, cómo gestionar la eterna batalla Técnico vs Funcional

En cualquier proyecto SAP, tarde o temprano aparece la tensión:

• El funcional dice: “Esto es solo un campo nuevo, nada complicado”.

• El técnico responde: “Sí, claro… pero ese campo toca tres BAdIs, dos interfaces y un Smartform”.

• Y ahí empieza el tira y afloja.

👉 Como líderes, el error más común es dejar que esa tensión se enquiste. Si técnico y funcional se ven como enemigos, los proyectos se llenan de reprocesos, retrasos y frustración.

💡 ¿Qué hacer como líder?

1. Crea un espacio común de entendimiento
   No todo el mundo tiene que saber programar ni dominar la SPRO, pero sí entender la lógica de impacto de cada decisión.

   • Haz workshops cruzados: técnicos explican a funcionales qué significa “un loop mal puesto” y funcionales muestran cómo un “simple cambio” puede reventar la nómina o un cierre contable.

2. Fomenta la documentación como puente, no como burocracia
   La especificación funcional no es “papel mojado”: es la base para que el técnico sepa dimensionar el esfuerzo.
   Enseña a tu equipo que documentar bien ahorra tiempo y evita reprocesos infinitos.

3. Recompensa el trabajo colaborativo, no el individual
   Un técnico que optimiza código en silencio sin validar con el funcional puede estar tirando horas a la basura.
   Un funcional que presiona por fechas sin escuchar la complejidad técnica puede generar un “parche” que mañana explota.
   👉 Recompensa cuando trabajan juntos y entregan soluciones estables.

4. Sé mediador, no árbitro
   No se trata de decir quién tiene razón, sino de alinear el objetivo común: que el cliente/negocio tenga un proceso estable, rápido y mantenible.

El choque técnico vs funcional no es un problema, es una oportunidad de complementariedad.
El líder que logra que ambos se entiendan, construye equipos sólidos, con menos retrabajos y con más confianza mutua.

👉 Mi consejo final: la próxima vez que veas a un técnico y un funcional discutir, no intentes cortar la discusión… facilítala. Muchas veces, de esas conversaciones tensas salen las mejores soluciones.

💬 Frase del Día

📌Esta frase nos recuerda que la percepción es más poderosa que la simple observación. Dos personas pueden estar frente a la misma situación, pero interpretarla de maneras completamente distintas según su perspectiva, experiencia y actitud. En la práctica, significa que enfocarnos en lo positivo y en las oportunidades, en lugar de solo en los problemas, puede cambiar radicalmente nuestra vida y decisiones.

🙌 Gracias por leer

Y hasta aquí llega nuestro boletín de hoy.

!Gracias por leer hasta aquí! Nos vemos la semana que viene. No dudéis en enviarme recomendaciones por correo: las leo y contesto todas, y si no, también por LinkedIn son más que bienvenidas.

Hasta el martes que viene, y recordad: Los técnicos y los funcionales son como hermanos que siempre se chinchan. Uno dice “sin mi código no avanzamos” y el otro responde “sin mi configuración ni existes”, pero al final, siempre se ayudan… aunque sea con cara de pocos amigos 😄.

Hasta el martes que viene,

Un fuerte abrazo,