¿Tu gestión de gastos sigue dependiendo de procesos manuales entre
sistemas?
Con SAP Power Connector by GROUPmee conectas Captio y SAP de
forma nativa para que la información fluya automáticamente, sin
duplicidades ni integraciones complejas.
Digitaliza la gestión de los gastos de empleado, automatiza la
contabilización y mejora la visibilidad financiera en tiempo real, todo
desde tu entorno SAP
Índice del boletín
🔍 Dato Curioso
El verdadero desafío de SAP Fiori no es técnico, es de adopción
Muchos profesionales asocian el salto a Fiori exclusivamente con un cambio de interfaz. Sin embargo, existe una realidad que suele pasar desapercibida: es posible tener Fiori implementado y seguir trabajando exactamente igual que en ECC durante años, sin aprovechar su verdadero potencial.
SAP Fiori nació en 2013 como una nueva experiencia de usuario sobre Business Suite, con el objetivo de simplificar el acceso a procesos mediante aplicaciones más intuitivas. No obstante, no fue hasta el lanzamiento de SAP S/4HANA en 2015 cuando Fiori se consolidó como la interfaz estratégica recomendada, pasando de ser una capa opcional a convertirse en el estándar del sistema.
Aunque Fiori lleva más de una década en el mercado, en numerosos proyectos su adopción real sigue siendo limitada. Se implementa, se activa, se capacita a los usuarios en algunas aplicaciones… pero el día a día permanece prácticamente inalterado respecto a SAP GUI.
Esto ocurre porque muchas organizaciones utilizan únicamente apps transaccionales que replican funcionalidades clásicas. Cambian la apariencia de la pantalla, pero no transforman la forma de trabajar. Los usuarios continúan razonando en códigos de transacción, flujos lineales y ejecución pura de tareas.
Sin embargo, Fiori no fue diseñado solo para eso. Incorpora aplicaciones analíticas, navegación basada en roles, KPIs integrados, alertas proactivas y un modelo de interacción fundamentalmente distinto. El objetivo no es únicamente ejecutar procesos, sino comprender qué está ocurriendo en el negocio y tomar decisiones informadas con el contexto adecuado.
Existe un patrón recurrente en implementaciones reales: usuarios que son más rápidos operando en SAP GUI, pero que toman decisiones de menor calidad en comparación con aquellos que utilizan Fiori. No se trata de una cuestión de conocimiento técnico, sino de enfoque: GUI está optimizado para la ejecución, mientras que Fiori está diseñado para la contextualización. Esa diferencia, aunque sutil en la superficie, genera un impacto directo y medible en los resultados del negocio.
Implementar Fiori desde el punto de vista técnico es relativamente sencillo: activar aplicaciones, asignar roles, configurar el entorno. Lo complejo es lograr que los usuarios modifiquen su forma de trabajar.
Porque el verdadero cambio que propone Fiori no reside en la tecnología, sino en el hábito. Y eso no se transporta mediante una orden, ni se activa con customizing.
Se construye. Y requiere tiempo, acompañamiento y cambio de mentalidad.
📰 Ultimas noticias
e la Fórmula 1 a la gestión empresarial: lo que hay detrás del mensaje de David Coulthard en SAP Sapphire
En el último SAP Sapphire, uno de los nombres que más llamó la atención fue el de David Coulthard.
A primera vista puede parecer el típico recurso de evento: traer a alguien conocido, inspirar y generar impacto. Pero si te paras a analizar el mensaje, hay bastante más fondo del que parece.
Coulthard habló de algo muy concreto: la toma de decisiones en entornos de alta presión.
En Fórmula 1, las decisiones no son solo rápidas, son críticas. No hay margen para improvisar sin información, pero tampoco para esperar demasiado. Es un equilibrio constante entre datos, experiencia y contexto.
Y aquí es donde encaja perfectamente con el mundo SAP.
Muchas organizaciones tienen acceso a una cantidad enorme de datos.
Pero tener datos no significa tomar mejores decisiones.
El paralelismo que se plantea es bastante claro: igual que en la Fórmula 1, lo importante no es solo tener información, sino saber interpretarla en el momento adecuado y actuar en consecuencia.
Esto conecta directamente con todo lo que SAP lleva tiempo empujando:
analítica embebida
decisiones en tiempo real
integración de datos en los procesos
Pero aquí viene la parte interesante.
La tecnología ya está.
El problema, una vez más, está en cómo se utiliza.
Igual que comentábamos con Fiori, muchas empresas tienen herramientas avanzadas… pero siguen tomando decisiones como hace años.
reportes que no se usan
dashboards que no se consultan
datos que existen pero no se integran en el día a día
Es decir, tienen el “coche de Fórmula 1”… pero conducen como si fueran en ciudad.
El mensaje de fondo no va de velocidad.
Va de contexto.
En Fórmula 1 no gana el que más datos tiene, sino el que mejor los utiliza en el momento adecuado. Y en empresa pasa exactamente lo mismo.
Desde el punto de vista de consultoría, esto tiene una implicación bastante clara.
No se trata solo de implementar herramientas o modelos de datos.
Se trata de ayudar al cliente a cambiar cómo toma decisiones.
Porque si eso no cambia, todo lo demás se queda a medias.
💹 Información en Bolsa
La cotización de SAP esta semana refleja bastante bien el momento en el que se encuentra la compañía: resultados sólidos, pero con un mercado que sigue teniendo dudas.
Por un lado, los últimos resultados han sido positivos. El crecimiento del beneficio y el aumento de ingresos confirman que el negocio sigue funcionando bien, especialmente en la parte cloud. Este sigue siendo el punto clave, donde SAP está centrando toda su estrategia y donde realmente se está jugando su futuro.
El crecimiento en cloud continúa, y el volumen de contratos futuros también. Esto indica que la transición hacia este modelo no solo sigue en marcha, sino que está funcionando. Sin embargo, eso no significa que el mercado esté completamente convencido.
De hecho, el comportamiento en bolsa no ha sido lineal. Antes de la publicación de resultados hubo cierta presión a la baja, motivada principalmente por dudas sobre el ritmo de crecimiento y el impacto de nuevas tendencias como la inteligencia artificial. Tras los resultados, la acción reaccionó positivamente, pero sin recuperar completamente la confianza del mercado.
Y aquí está el punto importante.
El mercado no está cuestionando si SAP va bien, sino si está yendo lo suficientemente rápido.
Esa diferencia es clave. Porque no se trata solo de crecer, sino de transformar el modelo de negocio a la velocidad que el mercado espera. Y ahí es donde aparecen las dudas: el ritmo del cloud, la competencia en nuevas tecnologías y la capacidad de adaptación en un entorno que cambia muy rápido.
Esto, además, conecta directamente con lo que vemos en proyectos. Muchas empresas están en pleno proceso de cambio, pero no todas avanzan al mismo ritmo. Hay migraciones a S/4 que se alargan, decisiones que se posponen y una adopción desigual de nuevas capacidades.
Al final, lo que refleja la bolsa no es solo la situación de SAP, sino la de todo el ecosistema.
La tecnología está evolucionando rápido, pero la adopción real va a otro ritmo. Y ahí es donde está el verdadero desafío.
🚀 Mi opinión
El verdadero problema de Fiori: no es qué implementamos, sino cómo lo introducimos
Mi posición sobre este tema es clara: el problema no radica en Fiori como tecnología, sino en cómo lo estamos integrando en los proyectos.
Con frecuencia se presenta como una mejora casi cosmética, como si fuera simplemente "la nueva interfaz de SAP", cuando en realidad representa un cambio fundamental en la forma de interactuar con el sistema. Si el cliente percibe que todo es idéntico pero con otra apariencia, no modificará sus hábitos de trabajo. Continuará ejecutando los mismos procesos que antes, pero enfrentando mayor fricción inicial sin comprender el beneficio.
Este patrón se repite constantemente: el cliente solicita una funcionalidad, se le entrega en Fiori, se imparte una formación rápida… y se asume que con eso es suficiente. Sin embargo, nadie dedica tiempo a explicar qué aporta realmente la solución, cómo mejora su operativa diaria o por qué debería abandonar métodos que ya domina. Sin ese trabajo de contextualización, la adopción simplemente no ocurre.
Aquí es donde el rol del consultor funcional se vuelve fundamental. No se trata únicamente de enseñar a usar una aplicación, sino de traducir el cambio. De explicar qué proceso cubre, qué diferencias existen respecto al método anterior y cómo debería trabajar ahora el usuario. Si esta labor no se ejecuta correctamente, Fiori se percibe como una capa adicional de complejidad, no como una mejora sustancial.
Desde la perspectiva técnica sucede algo similar. No es solo cuestión de decidir entre GUI o Fiori; es fundamental comprender el contexto: quién utilizará la solución, cómo la utilizará y con qué frecuencia. Diseñar para un usuario experto que trabaja continuamente en SAP no es lo mismo que hacerlo para un usuario de negocio que accede puntualmente y necesita claridad inmediata.
En mi experiencia, la mayoría de proyectos en los que participo están sobre SAP S/4HANA on-premise, y esto añade un matiz relevante: aquí no es necesario elegir un único camino. Ambos mundos (GUI y Fiori) pueden coexistir.
Y esto, bien gestionado, representa una ventaja estratégica.
A menudo el cliente necesita una aplicación específica, una integración vía API o un monitor de información. Puedes resolverlo con un ALV clásico en GUI: rápido, eficaz y familiar para perfiles técnicos. O puedes plantearlo con Fiori (por ejemplo, mediante Fiori Elements), más orientado a negocio y con una experiencia de usuario superior.
Lo valioso es que ambas opciones no son excluyentes. Pueden convivir productivamente.
El problema surge cuando esta decisión no se toma con criterio técnico-funcional, sino por costumbre, inercia o presión de tiempos. Es ahí donde se erosiona el valor.
Porque no se trata de elegir una tecnología por principio, sino de seleccionar la adecuada según cada caso de uso.
También es importante ser honestos en el planteamiento. No todo debe ser Fiori, del mismo modo que no todo debería permanecer en GUI. Existen escenarios donde GUI sigue siendo más eficiente, y otros donde Fiori aporta valor diferencial significativo. El equilibrio reside en comprender estas diferencias y comunicarlas con transparencia.
Al final, esto no trata de tecnología, trata de acompañar al cliente en una transformación real. Puedes implementar Fiori técnicamente en poco tiempo, pero lograr que el cliente lo comprenda, lo adopte y lo utilice correctamente es un desafío de naturaleza completamente distinta.
Y ahí es donde realmente se distingue entre entregar un desarrollo… y construir una solución que funcione de verdad.
🧩 SAP Técnico
Por qué las Interfaces son tu mejor aliado en desarrollos SAP (y cómo usarlas bien)
¿Qué es una Interface en ABAP?
Una interface es un contrato técnico que define qué métodos debe implementar una clase, sin especificar cómo. Es como decir "cualquier clase que implemente esta interface debe tener estos métodos", pero cada clase decide cómo ejecutarlos.
INTERFACE zif_document_processor.
METHODS:
validate RETURNING VALUE(rv_valid) TYPE abap_bool,
process RETURNING VALUE(rv_result) TYPE string,
get_status RETURNING VALUE(rv_status) TYPE char10.
ENDINTERFACE.¿Por qué deberías usarlas?
1. Polimorfismo real Puedes trabajar con diferentes clases de forma uniforme:
DATA: lt_processors TYPE TABLE OF REF TO zif_document_processor.
" Puedes meter clases completamente diferentes
APPEND NEW zcl_invoice_processor( ) TO lt_processors.
APPEND NEW zcl_order_processor( ) TO lt_processors.
APPEND NEW zcl_delivery_processor( ) TO lt_processors.
" Y procesarlas todas igual
LOOP AT lt_processors INTO DATA(lo_proc).
IF lo_proc->validate( ).
lo_proc->process( ).
ENDIF.
ENDLOOP.2. Código preparado para cambios Si mañana necesitas un nuevo tipo de procesador, solo creas una clase que implemente la interface. El código que la usa no necesita cambiar.
3. Testing más sencillo Puedes crear mocks de prueba que implementen la misma interface:
CLASS zcl_mock_processor DEFINITION.
PUBLIC SECTION.
INTERFACES zif_document_processor.
ENDCLASS.
" En tus unit tests usas el mock en lugar de la clase real
DATA(lo_test) = NEW zcl_mock_processor( ).El caso de uso real:
Imagina que tienes diferentes formas de calcular precios (estándar, promocional, B2B, internacional). Sin interfaces:
CASE iv_type.
WHEN 'STD'.
lv_price = calculate_standard( ).
WHEN 'PROMO'.
lv_price = calculate_promo( ).
WHEN 'B2B'.
lv_price = calculate_b2b( ).
ENDCASE.Con interfaces:
" Código flexible y extensible
DATA(lo_calculator) = get_price_calculator( iv_type ).
lv_price = lo_calculator->calculate( ).
" Agregar un nuevo tipo = crear nueva clase
" No tocar el código existenteUsa interfaces cuando tengas múltiples implementaciones de un mismo concepto (procesadores, calculadores, validadores, exportadores, notificadores...).
No las uses para clases únicas o utilidades simples. No todo necesita ser una interface.
Señales de que necesitas una interface:
Tienes un CASE o IF largo eligiendo entre diferentes implementaciones
El comentario dice "aquí pueden agregarse más tipos en el futuro"
Estás duplicando la misma estructura de métodos en varias clases
Necesitas poder testear sustituyendo la implementación real
El resultado: Código más limpio, más flexible y más fácil de probar. Y cuando llegue el cambio (que siempre llega), tu arquitectura estará preparada.
🧩 SAP Funcional
El error silencioso del MRP - Por qué tus propuestas no aparecen (y cómo solucionarlo)
El problema:
Ejecutas el MRP (MD01/MD02/MD03), esperas propuestas de aprovisionamiento... y no aparece nada. O aparecen menos de las esperadas. El stock está bajo, hay demanda confirmada, pero el sistema no reacciona.
La causa oculta: el Indicador de MRP
Muchos funcionales configuran el Tipo de MRP (campo DISMM) pero olvidan validar el Indicador de MRP (campo DISPO) en el maestro de materiales (vista MRP 1).
¿Cuál es la diferencia?
Tipo de MRP (PD, VB, ND...): Define cómo planifica el sistema (reaprovisionamiento automático, planificación manual, basado en consumo...)
Indicador de MRP (1, 2, 3, 4...): Define cuándo se incluye el material en la ejecución del MRP
Los valores críticos:
Indicador | Significado | Impacto |
|---|---|---|
1 | Ejecución basada en planificación | MRP se ejecuta solo cuando lo lanzas manualmente |
2 | Ejecución basada en necesidades | MRP se ejecuta automáticamente cuando hay movimientos |
3 | Reaprovisionamiento automático y basado en necesidades | El sistema reacciona inmediatamente a cambios |
4 | Reaprovisionamiento automático sin basado en necesidades | MRP automático pero NO por movimientos |
El error común:
Material configurado con:
- Tipo MRP: PD (Planificación de necesidades)
- Indicador MRP: 1 (Solo manual)
- Resultado: No aparece en ejecuciones automáticas (MD01 job)La configuración correcta para la mayoría de casos:
Para materiales críticos de producción:
- Tipo MRP: PD
- Indicador MRP: 2 o 3
Para materiales de bajo movimiento:
- Tipo MRP: VB (Consumo)
- Indicador MRP: 1
El truco que pocos conocen:
Usa la transacción MD04 (Stock/Necesidades) para validar si el material está realmente siendo considerado por el MRP:
Ve a MD04 con tu material
Menú:
Pasar a > Lista MRPSi ves el mensaje "No existe lista MRP" pero tienes necesidades → problema de configuración de indicador
Caso real:
Cliente reporta: "El MRP no genera órdenes previsionales para componentes críticos"
Análisis:
Tipo MRP: PD (correcto)
Lote: Configurado
Estrategia: 40 (correcta)
Indicador MRP: 1 (solo manual)
Solución: Cambiar a indicador 2 ( El MRP comienza a generar propuestas automáticamente)
La regla de oro:
Si tu material debe reaccionar a cambios de demanda en tiempo real (pedidos de venta, necesidades dependientes, consumos) Indicador 2 o 3.
Solo quieres planificar manualmente en momentos específicos Indicador 1.
Tip adicional:
Combina esto con el Horizonte de Planificación (campo PLIFZ) en el maestro de materiales. Un horizonte demasiado corto puede hacer que el MRP ignore necesidades futuras aunque el indicador esté bien configurado.
🔎 Función de la Semana
BAPI_MATERIAL_AVAILABILITY - Consulta disponibilidad de material en tiempo real
¿Qué hace?
Te permite consultar la disponibilidad (ATP - Available to Promise) de un material en un centro específico, considerando stock, entradas previstas, salidas planificadas y reglas de verificación de disponibilidad.
Cómo usarla:
DATA: lt_availability TYPE TABLE OF bapi_material_availability.
CALL FUNCTION 'BAPI_MATERIAL_AVAILABILITY'
EXPORTING
material = '000000000000100000' " Material
plant = '1000' " Centro
unit = 'PC' " Unidad de medida
TABLES
wmdvsx = lt_availability
EXCEPTIONS
material_plant_not_found = 1.
" lt_availability contiene fechas y cantidades disponibles
LOOP AT lt_availability INTO DATA(ls_avail).
WRITE: / ls_avail-date, ls_avail-com_qty. " Fecha y cantidad disponible
ENDLOOP.¿Para qué sirve?
Validar si hay stock suficiente antes de crear un pedido
Mostrar fechas de disponibilidad en portales o apps custom
Crear reportes de disponibilidad sin acceder directamente a tablas
Integrar con sistemas externos que necesiten consultar ATP
Simular escenarios de planificación
Ejemplo práctico:
" Verificar si puedo comprometer 100 unidades hoy
CALL FUNCTION 'BAPI_MATERIAL_AVAILABILITY'
EXPORTING
material = lv_matnr
plant = lv_werks
unit = 'PC'
check_rule = 'A' " Regla de verificación
TABLES
wmdvsx = lt_availability.
READ TABLE lt_availability WITH KEY date = sy-datum INTO DATA(ls_today).
IF ls_today-com_qty >= 100.
" Hay disponibilidad suficiente
ELSE.
" Stock insuficiente, buscar próxima fecha disponible
ENDIF.Perfecta para desarrollos de disponibilidad, validaciones de pedidos o integraciones e-commerce.
👑 Liderazgo y gestión
Liderar un proyecto SAP no consiste en tomar decisiones técnicas, sino en lograr que el cambio sea comprendido y adoptado.
La transición a Fiori es un ejemplo paradigmático. No se trata de un desafío tecnológico ni de compatibilidad de versiones: es un desafío de adopción. Puedes tener Fiori disponible (ya sea en Business Suite o en SAP S/4HANA) y aun así no generar ningún impacto tangible si los usuarios continúan trabajando como siempre lo han hecho.
Desde la perspectiva del liderazgo, el error más frecuente es asumir que el trabajo concluye cuando la solución funciona. En realidad, ahí es donde comienza lo verdaderamente importante: garantizar que el cliente la utilice de manera efectiva.
Esto exige un cambio de enfoque en el equipo.
El consultor funcional no debe limitarse a enseñar una aplicación, sino explicar cómo transforma el proceso y por qué su uso aporta valor. El consultor técnico no debe centrarse únicamente en construir, sino en comprender quién consumirá esa solución y en qué contexto operativo se insertará.
Cuando el equipo adopta esta mentalidad, deja de entregar desarrollos y comienza a entregar soluciones que realmente se integran en el día a día.
Además, en entornos donde Fiori convive con SAP GUI (algo habitual en muchas implementaciones), el liderazgo cobra aún mayor relevancia. Porque no existe una única forma correcta de abordar cada situación.
Aquí es donde entra en juego el criterio.
Un buen líder no impulsa todo hacia Fiori de manera indiscriminada, ni se aferra a lo conocido por inercia. Ayuda al equipo a discernir cuándo tiene sentido cada enfoque, en función del perfil del usuario, la naturaleza del proceso y el valor diferencial que aporta cada opción.
Y, sobre todo, se asegura de que esas decisiones se comuniquen y fundamenten adecuadamente ante el cliente.
Porque, en última instancia, liderar no es decidir por el equipo: es elevar la calidad de las decisiones que el equipo toma.
Si logras eso, Fiori deja de ser "una nueva interfaz" y se convierte en lo que realmente es: una oportunidad para transformar la forma en que opera el negocio.
💬 Frase del Día
Lo difícil no es tomar decisiones, es asumirlas cuando dejan de ser cómodas.
En consultoría, muchas decisiones parecen claras en papel: elegir una solución, un enfoque técnico o una estrategia con el cliente. El problema viene después, cuando aparecen las consecuencias reales. Ahí es donde se nota la diferencia entre alguien que decide por inercia y alguien que asume la responsabilidad completa de lo que ha elegido. Crecer profesionalmente no va tanto de acertar siempre, sino de sostener tus decisiones cuando ya no son fáciles
🙌 Gracias por leer
Y hasta aquí el boletín de esta semana.
Hoy nos hemos metido en algo que todos conocemos… aunque no todos usamos como deberíamos: Fiori.
Porque al final, más allá de apps, catálogos y tiles bonitos, Fiori es mucho más que una interfaz nueva. Es una de esas cosas que está ahí, disponible, bien montada… mientras muchos usuarios siguen abriendo el SAP GUI casi por reflejo.
Lo curioso es que, aunque hablemos de experiencia de usuario, apps modernas y navegación por roles, al final siempre hay alguien que dice:
“sí, sí… pero yo con la transacción voy más rápido”.
Y ahí sigue el debate. Fiori avanzando… y los usuarios resistiendo. Como ese hábito que sabes que deberías cambiar, pero siempre acabas haciendo lo mismo.
Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta comunidad, donde no solo hablamos de SAP… sino también de esas pequeñas realidades del día a día que todos vemos, todos comentamos… y que siguen pasando en cada proyecto.
La semana que viene volveremos con más experiencias reales, algún tema interesante y seguramente otra de esas situaciones en las que piensas: “vale… esto también me ha pasado”.
Nos leemos en el próximo boletín.