SAP Fiori: ¿Por qué la UX sigue fallando y cómo los copilotos de IA lo solucionan?

Publicado en abril de 2026 · Por el equipo de PickGeniusLab

He dedicado la mayor parte de la última década a implementar, personalizar y solucionar problemas de SAP Fiori en plantas de fabricación, centros de servicios compartidos y redes logísticas globales. Me he sentado junto a empleados de cuentas por pagar que mascullaban por lo bajo cada vez que una búsqueda no arrojaba resultados. He visto a supervisores de almacén recurrir a una hoja de cálculo —sí, una hoja de cálculo— porque la aplicación Fiori en su tablet se caía por tercera vez en el turno. Y he tenido la incómoda conversación con un director de TI que acababa de pasar dieciocho meses implementando Fiori para cuatro mil usuarios, solo para descubrir que la adopción se había estancado en el treinta por ciento.

SAP Fiori se suponía que iba a solucionar la UX empresarial. En 2013, cuando SAP la presentó, la propuesta era convincente: una interfaz consistente, basada en roles y de nivel de consumidor que haría que el ERP se sintiera tan intuitivo como un smartphone. En 2026, esa promesa sigue luciendo muy bien en las presentaciones de ventas. La realidad en el día a día de una empresa es, amablemente, más complicada.

Este artículo no es un ataque a SAP. Respeto la ingeniería que se invierte en estos productos y el progreso genuino que la empresa ha logrado a lo largo de los años. Pero también creo que la honestidad es más útil para los consultores de SAP y los líderes de TI que el simple optimismo. Así que permítame explicarle exactamente dónde Fiori sigue decepcionando a los usuarios en 2026, por qué es tan difícil solucionarlo desde la propia plataforma y —lo más importante— cómo los copilotos de IA están empezando a llenar el vacío de maneras prácticas, medibles y desplegables hoy mismo.

La promesa vs. la realidad de SAP Fiori

Cuando SAP lanzó Fiori, la filosofía de diseño se basó en cinco principios: basado en roles, responsivo, simple, coherente y deleitable. Estos son buenos principios. Son los principios correctos. El problema es que el software empresarial no existe en un laboratorio, sino dentro de organizaciones con décadas de "deuda" de personalización, complejas jerarquías de autorización, limitaciones de rendimiento de hardware local y requisitos de integración que nunca se diseñaron pensando en una interfaz de usuario móvil primero.

En mi experiencia trabajando con más de treinta clientes empresariales de SAP en Europa y Medio Oriente, puedo contar con los dedos de una mano el número de implementaciones de Fiori en las que los usuarios describieron su experiencia diaria como genuinamente fluida. La mayoría de los usuarios describen Fiori de la misma manera que describen su viaje diario al trabajo: los lleva a donde necesitan ir, la mayoría de las veces, pero no es algo que esperen con ansia.

La brecha entre la narrativa de marketing de Fiori y la experiencia de usuario vivida se reduce a algunas tensiones estructurales que SAP nunca ha resuelto por completo:

• Fiori fue diseñado para la "pureza" de S/4HANA, pero la mayoría de las organizaciones no son puramente S/4HANA. Los paisajes híbridos —ECC junto con S/4HANA, la nube junto con sistemas locales— crean fisuras que la interfaz de usuario no puede ocultar con elegancia.
• La personalización rompe la coherencia. En el momento en que un cliente comienza a adaptar los mosaicos, flujos de trabajo y campos de Fiori para que coincidan con sus procesos de negocio, la experiencia "consistente" comienza a fragmentarse. Mantener esa coherencia a través de las actualizaciones es costoso y a menudo se le resta prioridad.
• El rendimiento de Fiori depende de una infraestructura en la que muchas organizaciones invierten poco. El servidor front-end, los servicios OData, el backend ABAP —cada capa puede introducir latencia, y esa latencia se acumula.

Nada de esto significa que Fiori sea un fracaso. Es, en la mayoría de las medidas, una mejora significativa sobre el SAP GUI que reemplazó para muchos tipos de transacciones. Pero una mejora significativa no es lo mismo que un problema resuelto, y en 2026 el listón para la UX empresarial ha subido drásticamente. Los usuarios ahora comparan su software de trabajo con herramientas como Notion, Slack y Copilot en Microsoft 365. Fiori, incluso en su mejor momento, no puede competir en esa dimensión sin una mejora externa.

Los 5 principales patrones de fallo de la UX de Fiori

Permítame ser específico. Las quejas vagas sobre una "mala UX" no ayudan a nadie. Aquí están los cinco patrones de fallo que encuentro con mayor frecuencia en las interacciones con clientes, con ejemplos concretos de cómo se manifiestan.

1. Tiempos de carga lentos que destruyen la productividad

La queja más universal que escucho de los usuarios de Fiori son los tiempos de carga. No son caídas catastróficas, solo lentitud. Un oficial de compras espera de cuatro a seis segundos para que se cargue la aplicación "Gestionar pedidos de compra". Un gerente espera tres segundos para que se cargue el mosaico "Mi bandeja de entrada" después de aprobar un documento. A lo largo de un día laboral completo, esto suma de quince a veinte minutos de espera pasiva, tiempo que erosiona tanto la productividad como la buena voluntad hacia el sistema.

Las causas raíz varían: servicios OData mal optimizados, índices faltantes en las vistas CDS, configuración de caché insuficiente en el SAP Web Dispatcher o simplemente un servidor de aplicaciones que está haciendo demasiado. La solución casi siempre está en el lado de la infraestructura o el backend, no en la capa de la interfaz de usuario, lo que significa que queda fuera del ámbito del equipo de Fiori y se le resta prioridad en el backlog de lanzamientos.

Una vez realicé una auditoría de rendimiento para un proveedor automotriz alemán y descubrí que su aplicación Fiori más utilizada —una pantalla personalizada de confirmación de entrada de mercancías— realizaba once llamadas OData separadas en la carga inicial. Los desarrolladores originales la habían construido de esa manera porque era el camino de menor resistencia en SAPUI5. Nadie la había revisado desde una perspectiva de red. Combinar esas llamadas en dos redujo el tiempo de carga de 5.2 segundos a 1.1 segundos. La solución tomó tres días. El problema había existido durante dos años.

2. Campos de entrada obligatorios que bloquean la búsqueda significativa

La búsqueda de Fiori —particularmente en aplicaciones transaccionales más antiguas— obliga a los usuarios a introducir valores de campo específicos antes de que el sistema devuelva resultados. Vaya a la aplicación "Visualizar pedido de compra" en muchos sistemas S/4HANA e intente buscar todos los pedidos de compra realizados en los últimos siete días sin conocer el número de proveedor o el número de documento de antemano. En muchas configuraciones estándar, la búsqueda no devuelve nada, o peor, lo obliga a volver a una pantalla de selección que se siente indistinguible de la transacción SAP GUI ME23N.

Esta es una falla de UX que está arraigada en la arquitectura. Los servicios OData subyacentes a menudo requieren que se rellenen ciertos campos porque los módulos de función ABAP a los que llaman fueron diseñados para búsquedas precisas, no para búsquedas exploratorias. Relajar esas restricciones sin reescribir la lógica del backend conlleva el riesgo de problemas de rendimiento a gran escala. Por lo tanto, la restricción persiste y los usuarios desarrollan soluciones alternativas, que generalmente implican a un colega que conoce los parámetros de búsqueda "mágicos" o un informe personalizado que omite Fiori por completo.

3. Búsqueda que no arroja resultados

Relacionado pero distinto: la funcionalidad de búsqueda de Fiori —tanto dentro de las aplicaciones como en la búsqueda global— es frágil de maneras que frustran a los usuarios a diario. Las coincidencias parciales a menudo fallan. Los errores tipográficos son imperdonables. Buscar "Müller" cuando el sistema almacena "Mueller" no devuelve nada. Buscar por un nombre de proveedor parcial en un sistema donde la búsqueda difusa no ha sido habilitada no devuelve nada. Buscar un socio comercial por su dirección de correo electrónico en una aplicación Fiori estándar no devuelve nada, porque el índice de búsqueda no se configuró para incluir ese campo.

He visto a usuarios desarrollar elaborados rituales de búsqueda personales: mantienen un marcador en el navegador para un informe personalizado, tienen una hoja de cálculo personal con números de proveedor, o le preguntan a un colega que "conoce el sistema" cada vez que necesitan encontrar un registro desconocido. Estas soluciones alternativas son invisibles para la dirección de TI, pero son profundamente costosas en conjunto.

4. Fallos de aplicaciones móviles y fallos sin conexión

SAP ha invertido mucho en su cartera móvil: SAP Mobile Start, SAP Fiori Client y varias aplicaciones nativas creadas sobre el stack de SAP BTP Mobile Services. En demostraciones controladas, estas funcionan bien. En entornos de producción, particularmente en industrias donde el uso móvil es crítico (logística, servicio de campo, manufactura), la experiencia es más inestable.

Los modos de fallo comunes que he documentado en los sitios de clientes incluyen: la aplicación SAP Fiori Client se bloquea al cambiar entre múltiples sistemas de back-end; las capacidades sin conexión no se sincronizan correctamente cuando el dispositivo se vuelve a conectar a la red; las notificaciones push para aprobaciones de flujo de trabajo llegan horas después de que la aprobación ya fue completada por otra persona; y el diseño móvil de algunas aplicaciones Fiori simplemente se renderiza mal en tamaños de pantalla no estándar porque los puntos de interrupción responsivos nunca se probaron en dispositivos reales utilizados en el campo.

Un cliente de logística mío en los Países Bajos implementó Fiori móvil para sus supervisores de almacén en 2024. En tres meses, dos tercios de los supervisores habían vuelto a los procesos en papel para las entradas de mercancías porque la aplicación era "poco confiable". Eso no es una falla tecnológica en abstracto, es un problema de continuidad del negocio con un costo medible.

5. Caos en la visibilidad de los mosaicos basada en roles

El launchpad de Fiori se supone que muestra a los usuarios exactamente los mosaicos relevantes para su rol. En teoría, esto es elegante: un empleado de compras ve aplicaciones de compras, un gerente de finanzas ve aplicaciones de finanzas y nadie ve nada que no deba ver. En la práctica, el acceso basado en roles en la mayoría de los sistemas SAP empresariales es un desorden heredado que se ha acumulado durante años de cambios organizacionales, adiciones de proyectos y autorizaciones de solución.

Lo que normalmente veo: usuarios con quince o veinte mosaicos en su launchpad, de los cuales usan tres regularmente. Usuarios que no pueden encontrar una aplicación que necesitan porque se asignó a un nombre de rol ligeramente diferente. Usuarios a quienes se les ha otorgado acceso temporal a un mosaico durante un proyecto y ahora no pueden eliminarlo sin una solicitud formal de cambio de TI. Usuarios en roles compartidos que ven mosaicos que solo son relevantes para un subconjunto de sus colegas, lo que genera confusión sobre lo que se supone que deben hacer con ellos.

La sobrecarga administrativa de gestionar las asignaciones de roles de Fiori —particularmente en grandes poblaciones de usuarios con jerarquías de roles complejas— es sustancial, y la mayoría de las organizaciones carecen de las herramientas para hacerlo de manera inteligente a escala.

¿Por qué SAP tiene dificultades para solucionar esto internamente?

Quiero ser justo aquí, porque los desafíos que enfrenta SAP para mejorar la UX de Fiori son genuinamente difíciles. No se trata de indiferencia corporativa, sino de restricciones arquitectónicas que no tienen soluciones simples.

La lógica de negocio central de SAP reside en ABAP, un lenguaje y entorno de ejecución extraordinariamente capaz de procesar grandes volúmenes de transacciones comerciales de manera confiable, pero que fue diseñado en una época en la que la interfaz de usuario era una ocurrencia tardía. Los servicios OData de los que depende Fiori son, en la mayoría de los casos, envoltorios alrededor de módulos de función ABAP y BAPIs que nunca fueron diseñados para soportar el tipo de interacciones flexibles, exploratorias y de baja latencia que exige la UX moderna.

Reescribir esos servicios desde cero —reemplazándolos con APIs nativas de la nube construidas sobre SAP BTP, por ejemplo— es exactamente lo que SAP está haciendo con S/4HANA Cloud y su estrategia de Clean Core. Pero esa transición llevará años para la mayoría de las organizaciones, y mientras tanto, las restricciones heredadas persisten. La personalización añade otra capa de complejidad: cada modificación del cliente a una aplicación Fiori crea una carga de mantenimiento que hace que las actualizaciones sean más riesgosas y ralentiza la adopción de las propias mejoras de UX de SAP.

El resultado es una plataforma que mejora al ritmo de un gran proveedor de software empresarial —medido, cuidadoso, compatible con versiones anteriores— mientras que las expectativas de los usuarios avanzan al ritmo de la tecnología de consumo. La brecha es estructural y no se cerrará solo con lanzamientos incrementales de la plataforma.

Cómo los copilotos de IA abordan cada patrón de fallo

Aquí es donde las cosas se ponen realmente interesantes. Los copilotos de IA —ya sea Joule de SAP, agentes LLM personalizados integrados a través de SAP BTP, o soluciones híbridas que combinan ChatGPT o Gemini con APIs de SAP— pueden abordar los fallos de la UX de Fiori de maneras que no requieren reescribir la arquitectura subyacente. Trabajan alrededor de las limitaciones añadiendo una capa inteligente por encima.

Resolviendo tiempos de carga lentos con precarga predictiva

Los copilotos de IA con acceso a datos de comportamiento del usuario pueden predecir qué aplicaciones es probable que abra un usuario y precargar los datos relevantes antes de que el usuario navegue allí. Si un oficial de compras abre la aplicación "Gestionar órdenes de compra" todas las mañanas a las 8:15 y filtra por un grupo de compras específico, un agente predictivo puede activar esa llamada OData en segundo plano a las 8:10, para que los datos estén en caché y listos cuando el usuario llegue.

Esta no es una capacidad hipotética; es un patrón que se ha implementado utilizando el Application Router de SAP BTP combinado con un modelo ligero de ML entrenado con registros de sesiones de usuario. La implementación se ve aproximadamente así:

// BTP Application Router: middleware de precarga predictiva
app.use('/sap/opu/odata/', async (req, res, next) => {
  const userId = req.user?.id;
  const currentHour = new Date().getHours();

  // Consultar modelo de predicción para la próxima navegación probable
  const prediction = await prefetchModel.predict({
    userId,
    currentHour,
    lastVisitedApp: sessionStore.get(userId)?.lastApp
  });

  if (prediction.confidence > 0.75) {
    // Calentar la caché OData para la próxima aplicación predicha
    prefetchCache.warmAsync(prediction.entitySetUrl, userId);
  }

  next();
});

En una implementación que revisé en una empresa manufacturera holandesa, este enfoque redujo el tiempo de carga percibido para las tres aplicaciones más utilizadas en un promedio de 2.8 segundos, no haciendo las aplicaciones más rápidas, sino haciendo la espera invisible.

Solucionando restricciones de campos obligatorios con completado de formularios asistido por IA

Cuando una búsqueda requiere un número de proveedor y el usuario no lo conoce, un copiloto de IA puede resolver la restricción de forma conversacional. En lugar de que el usuario llegue a un callejón sin salida, escribe "mostrarme órdenes de compra de Siemens la semana pasada" y el copiloto resuelve "Siemens" al número de proveedor, infiere el rango de fechas, rellena los campos obligatorios y envía la búsqueda en nombre del usuario.

SAP Joule hace exactamente esto para un conjunto creciente de aplicaciones estándar. Para aplicaciones personalizadas, el mismo patrón se puede implementar utilizando un LLM con capacidad de llamada a funciones al que se le ha dado acceso a un conjunto de APIs de SAP:

# Ejemplo: definición de función LLM para búsqueda de proveedores
functions = [
  {
    "name": "resolve_vendor",
    "description": "Resuelve un nombre de proveedor o nombre parcial a un número de proveedor de SAP",
    "parameters": {
      "type": "object",
      "properties": {
        "vendor_name": {
          "type": "string",
          "description": "El nombre del proveedor o nombre parcial proporcionado por el usuario"
        },
        "company_code": {
          "type": "string",
          "description": "Código de empresa opcional para reducir la búsqueda"
        }
      },
      "required": ["vendor_name"]
    }
  }
]

# El LLM resuelve la intención del usuario, llama a la función,
# luego rellena los campos de búsqueda de Fiori programáticamente
# a través de la API de SAP UI5 o un agente de automatización del lado de BTP

Resolviendo la búsqueda sin resultados con coincidencia semántica y difusa

Las capas de búsqueda impulsadas por IA pueden colocarse delante de la búsqueda nativa de Fiori y traducir las consultas de los usuarios en búsquedas estructuradas que realmente devuelvan resultados. Un usuario que busca "facturas de Mueller por más de 50.000" obtiene resultados porque la capa de IA gestiona la resolución de variantes de nombres ("Mueller" / "Müller"), entiende el filtro de cantidad como una restricción numérica y mapea "facturas" al tipo de documento apropiado en SAP.

La Búsqueda Empresarial de SAP y la interfaz de lenguaje natural de Joule avanzan en esta dirección para el contenido estándar. Para las organizaciones que necesitan extender esto a objetos personalizados y tablas Z, construir una capa de búsqueda semántica en BTP utilizando incrustaciones vectoriales de datos maestros de SAP —indexadas diariamente desde S/4HANA— es un enfoque práctico que varios de mis clientes están ejecutando actualmente en producción.

Solucionando fallas móviles con agentes de IA "offline-first"

Los fallos de Fiori móvil suelen ser fallos de sincronización: la aplicación no sabe qué hacer cuando pierde la conectividad, o hace suposiciones incorrectas sobre el estado de los datos cuando se reconecta. Los agentes de IA pueden gestionar esto de forma más inteligente manteniendo un modelo de estado local, encolando acciones realizadas sin conexión con lógica de resolución de conflictos, y alertando proactivamente a los usuarios cuando un problema de sincronización requiere juicio humano en lugar de fallar silenciosamente.

Los servicios móviles de SAP BTP ahora incluyen "hooks" de resolución de conflictos que se pueden extender con lógica personalizada. Una capa de IA puede clasificar los conflictos —"este recibo de mercancías fue contabilizado por un colega mientras usted estaba desconectado; ¿desea cancelar el suyo o escalar?"— en lugar de dejar al usuario con un mensaje de error críptico.

Resolviendo el caos de visibilidad de mosaicos con recomendaciones de roles de IA

La gestión de roles en Fiori es fundamentalmente un problema de datos: la mayoría de las organizaciones no tienen datos limpios y actualizados sobre qué roles necesitan realmente los usuarios versus qué roles se les han asignado. La IA puede ayudar analizando los patrones de uso reales —qué mosaicos abre cada usuario, con qué frecuencia y en qué contexto— y mostrando recomendaciones tanto a los usuarios como a los administradores.

Para los usuarios, esto se ve como un launchpad personalizado que muestra las tres aplicaciones que es más probable que necesiten en este momento, según la hora del día, la carga de trabajo actual y el comportamiento histórico. Para los administradores, se ve como un panel de detección de anomalías que señala a los usuarios con roles asignados que nunca han utilizado (posibles candidatos a desaprovisionamiento) y a los usuarios que con frecuencia se alejan de Fiori para realizar tareas que sugieren una asignación de mosaico faltante.

Fallas de UX de Fiori vs. Solución de Copiloto de IA: Una Comparación

El caso del cierre de mes: de 40 clics a 3 indicaciones

El ejemplo más instructivo que puedo dar de lo que un copiloto de IA realmente le hace a la UX de Fiori proviene de una controller con la que trabajé en una empresa manufacturera de tamaño mediano en Alemania: 1.400 millones de euros en ingresos anuales, S/4HANA local, tres códigos de empresa para gestionar.

Su rutina de cierre de mes era una ilustración de libro de texto del fracaso de Fiori a escala. La secuencia específica que cronometré: verificar los devengos abiertos, verificar que todas las cuentas de compensación GR/IR estuvieran conciliadas e identificar cualquier partida grande no contabilizada antes de que se bloqueara el período.

En Fiori, esto significaba navegar a través de cuatro aplicaciones separadas: Resumen de informes financieros, un mosaico de devengos personalizado, Análisis de compensación GR/IR y el Monitor de cierre de período. Cada aplicación requería su propia configuración de filtro, y cada una requería que la controller llevara manualmente el contexto de una a la siguiente. Conté 22 minutos por código de empresa, 66 minutos para los tres, realizados dos veces al día durante los últimos tres días hábiles de cada mes.

Eso equivale a 6 horas al mes de tiempo de un profesional financiero senior dedicado a hacer clic en la navegación de la aplicación. No analizando, no decidiendo, no comunicándose con el negocio. Simplemente haciendo clic.

La implementación del copiloto de IA

La capa de copiloto tardó tres semanas en construirse: un middleware de Python que llamaba a APIs OData para devengos (a través de un servicio OData personalizado), partidas GR/IR (API_PURCHASING_DOCUMENT_SRV) y estado de período abierto (envoltorio BAPI personalizado). El LLM recibió un prompt de sistema específico para finanzas y los esquemas de funciones para cada API. Aquí está la interacción que reemplazó 66 minutos de navegación en Fiori:

Usuario: "Ejecutar mi verificación de cierre de mes para los códigos de empresa 1000, 2000, 3000"

[El copiloto llama a 4 puntos finales OData secuencialmente, ~12 segundos en total]

Respuesta:
------------------------------------------------------------------
ESTADO DE CIERRE DE MES | 28-03-2026 | Faltan 3 días para el cierre del período

EMPRESA 1000 (DE): ACCIÓN REQUERIDA
  Devengos no confirmados: 3 partidas (la mayor: EUR 340,000 — Proveedor 100234)
  GR/IR sin compensar: 12 partidas, EUR 89,450 (más antigua: 45 días)
  --> Revisar devengo 900001234 antes de la fecha límite

EMPRESA 2000 (AT): OK
  GR/IR sin compensar: 4 partidas, EUR 12,300 (dentro de la tolerancia)
  Ningún devengo que requiera acción

EMPRESA 3000 (CH): OK
  1 devengo pendiente (EUR 15,000) — bajo riesgo

Siguiente paso: ¿Mostrar detalle de devengos para la Empresa 1000, o exportar la lista completa de GR/IR?
------------------------------------------------------------------

Usuario: "Mostrar detalle de devengos para 1000"

[Una llamada API más, 3 segundos]

Respuesta: Devengo 900001234 | EUR 340,000 | Pedido de servicio 4500089234
  Proveedor: Logistics Partner AG | Contabilizado: 01-03-2026
  Fecha límite de confirmación: 29-03-2026 (mañana)
  Contacto: buyer.name@company.com
  Acción sugerida: Enviar correo electrónico al comprador para confirmar o revertir antes del final del día de mañana
------------------------------------------------------------------

Tres entradas de usuario. Menos de dos minutos. La controller revisó la misma información que antes le tomaba 66 minutos de navegación en Fiori, y lo hizo con mayor confianza porque el resumen resaltaba la excepción que requería acción en lugar de requerirle que la encontrara ella misma en cuatro pantallas de aplicación separadas.

Anualmente, esto recuperó aproximadamente 72 horas de tiempo de un profesional financiero senior por año para este único proceso; a USD 110 por hora con todos los costos incluidos, eso equivale a USD 7,920 en tiempo productivo recuperado anualmente. La capa de copiloto costó aproximadamente USD 15,000 construirla y USD 2,400 por año para operarla en costos de API LLM y hosting. El retorno de la inversión fue positivo en 26 meses para este único caso de uso, con la misma infraestructura disponible para otros procesos sin costo de construcción adicional.

Por qué esto funciona: El principio de diseño

La razón por la que este caso de estudio es replicable es el principio de diseño subyacente: el copiloto de IA maneja la recuperación de datos y el reconocimiento de patrones; el humano toma cada juicio y realiza cada acción. El copiloto no contabiliza acumulados, no compensa partidas GR/IR, no bloquea el período. Destaca las excepciones que requieren atención humana y las presenta en un formato que reduce la carga cognitiva de encontrarlas.

Este es el marco adecuado para los copilotos de IA en entornos SAP. No la automatización del juicio. La automatización de la navegación que siempre ha sido el impuesto indirecto sobre el juicio.

Implementación real: Antes y después con métricas

Quiero compartir un caso de estudio compuesto basado en el trabajo en el que he estado involucrado durante los últimos dieciocho meses: los detalles son anónimos, pero los números son reales.

El cliente es un grupo manufacturero paneuropeo con aproximadamente 4,200 usuarios de Fiori en compras, finanzas y logística. Habían completado su migración a S/4HANA en 2023 y estaban frustrados porque la adopción de Fiori se había estancado en alrededor del 38% de su población de usuarios prevista. El resto utilizaba una combinación de transacciones de SAP GUI, informes personalizados y soluciones alternativas. La dirección de TI había identificado tres causas raíz: frustración con la búsqueda, rendimiento lento en las aplicaciones de pedidos de compra y confusión sobre el launchpad para los usuarios cuyos roles habían cambiado recientemente durante una reorganización.

Fase 1: Capa de búsqueda impulsada por IA (primer trimestre de 2025)

Desplegamos una capa de búsqueda semántica construida sobre SAP BTP, utilizando incrustaciones vectoriales indexadas diariamente de datos maestros de proveedores, materiales y clientes. La interfaz de usuario de búsqueda se presentó como un mosaico Fiori personalizado en el launchpad, una única caja de búsqueda, sin campos obligatorios, compatible con consultas en lenguaje natural.

Antes: Sesión de búsqueda promedio que resultaba en un hallazgo de registro exitoso: 3 minutos 40 segundos. Los usuarios reportaron un promedio de 2.1 búsquedas fallidas por día.

Después (90 días después de la implementación): Sesión de búsqueda exitosa promedio: 48 segundos. Búsquedas fallidas por usuario por día: 0.4. Tickets de soporte relacionados con "no puedo encontrar proveedor/material/cliente": reducción del 62%.

Fase 2: Precarga predictiva para las 10 aplicaciones principales (segundo trimestre de 2025)

Instrumentamos el SAP BTP Application Router para registrar eventos de navegación anónimos y entrenamos un modelo ligero de "gradient boosting" (actualizado semanalmente) para predecir la próxima aplicación a la que un usuario navegaría, dado su rol, la hora actual y los últimos tres pasos de navegación. La precarga se activó para predicciones con una confianza superior al 70%.

Antes: Tiempo de carga promedio para las cinco aplicaciones más utilizadas: 4.1 segundos.

Después: Tiempo de carga percibido (tiempo desde el clic hasta la interactividad): 1.3 segundos para cargas precargadas, lo que representó el 67% de todas las navegaciones. Tiempo de carga percibido promedio general: 1.9 segundos.

Fase 3: Personalización del launchpad impulsada por IA (tercer trimestre de 2025)

Desplegamos un motor de personalización que analizó 90 días de historial de uso para cada usuario y reordenó sus mosaicos del launchpad por relevancia predicha, mostrando una sección de "Acceso Rápido" con las tres aplicaciones más relevantes contextualmente en la parte superior del launchpad. Los usuarios podían anular las recomendaciones con un solo clic.

Antes: Número promedio de clics para llegar a la aplicación correcta desde el launchpad: 3.2 (incluyendo mosaicos incorrectos clicados y navegación hacia atrás).

Después: 1.4 clics en promedio. Puntuación de satisfacción del usuario para el launchpad (escala de 1 a 5, medida a través de microencuestas integradas): de 2.1 a 3.8.

Impacto combinado después de 12 meses

La adopción de Fiori en la población de usuarios aumentó del 38% al 71%. El equipo de TI estimó que esto representaba aproximadamente €1.2 millones en recuperación anual de productividad, basado en el tiempo previamente dedicado a soluciones alternativas y búsquedas fallidas, valorado a los costos de personal totalmente cargados. Las tres capas de IA costaron aproximadamente €180,000 construirlas y desplegarlas durante el período de doce meses, más €40,000 por año en infraestructura y mantenimiento continuos de BTP. El cálculo del ROI fue lo suficientemente sencillo como para que el CFO aprobara una hoja de ruta de la Fase 2 en treinta días después de ver los números de doce meses.

Joule, integraciones ChatGPT-SAP y agentes LLM personalizados: ¿Qué es realmente diferente?

Vale la pena ser preciso sobre el panorama de herramientas de IA en 2026, porque el ruido de marketing es considerable y las capacidades reales difieren significativamente.

SAP Joule es el copiloto de IA generativa nativo de SAP, integrado en S/4HANA Cloud, SuccessFactors, Ariba y otros productos de la nube de SAP. Su ventaja clave es la integración estrecha y nativa con los datos y procesos de SAP: comprende el modelo de datos de SAP, respeta las autorizaciones de SAP y puede realizar acciones dentro de los flujos de trabajo de SAP sin requerir código de pegamento de API personalizado. Su limitación es el alcance: en 2026, las capacidades de lenguaje natural de Joule son excelentes para un conjunto definido de escenarios estándar y más débiles para objetos personalizados, transacciones Z y procesos altamente específicos de la industria. También requiere licencias de SAP Business AI además de su suscripción de SAP existente.

Las integraciones de ChatGPT-SAP (y patrones equivalentes usando Claude, Gemini o LLMs de código abierto) le dan mucha más flexibilidad en lo que puede hacer, pero requieren un trabajo de integración significativamente mayor. Usted está construyendo el "pegamento": APIs de SAP, middleware de BTP, autenticación, controles de privacidad de datos y la propia interfaz conversacional. La ventaja es que puede adaptar el comportamiento de la IA precisamente a los procesos y al modelo de datos de su organización. El riesgo es que usted es el propietario del mantenimiento de una pila de integración personalizada en un panorama de proveedores que evoluciona rápidamente.

Los agentes LLM personalizados en BTP —un patrón cada vez más común entre los grandes clientes de SAP— se sitúan entre estos dos extremos. Usted aloja el LLM en SAP BTP (o llama a una API LLM externa desde BTP), lo envuelve con los servicios de seguridad y conectividad de BTP, y construye integraciones de llamada a funciones contra sus servicios OData de S/4HANA. Esto le da una profundidad de integración similar a la de Joule con la flexibilidad de un LLM personalizado. El costo operativo es más alto que el uso de Joule, pero para organizaciones con requisitos complejos o específicos de la industria, a menudo es la opción correcta.

Qué buscar al evaluar extensiones de IA para Fiori en 2026

Si está evaluando soluciones de copiloto de IA para su entorno Fiori en este momento, aquí están los criterios que uso con los clientes. Estos no son teóricos, provienen de haber estado en demostraciones de proveedores, haber realizado pruebas de concepto y haber visto lo que importa cuando la teoría se encuentra con la práctica en producción.

1. Conciencia de la autorización

Cualquier capa de IA que interactúe con datos de SAP debe respetar el modelo de autorización de SAP. Esto suena obvio, pero es fácil construir una capa de búsqueda de IA que omita la seguridad a nivel de fila porque la IA consulta un almacén de datos replicado en lugar del sistema SAP en vivo. Pregunte específicamente a los proveedores: ¿cómo maneja su solución los objetos de autorización de SAP? ¿Puede un usuario consultar la IA y recibir datos que no tiene autorización para ver en la aplicación Fiori nativa? Si la respuesta es vaga, considérelo una señal de alerta.

2. Explicabilidad

Cuando un copiloto de IA realiza una acción —enviar un formulario, resolver un nombre de proveedor, navegar a una aplicación—, los usuarios y los auditores necesitan entender qué sucedió. Las buenas extensiones de IA para Fiori muestran su razonamiento: "Busqué al proveedor 100234 (Siemens AG) basándome en su consulta 'Siemens'" y "Precargué el campo del código de empresa con 1000 basándome en su perfil de usuario". Esto no es solo una cortesía de UX, es un requisito de auditoría en muchas industrias reguladas.

3. Degradación elegante

Los sistemas de IA fallan. La API de LLM se cae. El modelo de predicción devuelve resultados de baja confianza. El índice de búsqueda semántica está obsoleto. Una buena extensión de IA para Fiori se degrada elegantemente cuando su componente de IA no está disponible, volviendo al comportamiento estándar de Fiori en lugar de presentar a los usuarios una interfaz rota. Pruebe esto explícitamente en su prueba de concepto desconectando deliberadamente el componente de IA y observando qué sucede.

4. Residencia y privacidad de los datos

Si su copiloto de IA envía datos de SAP —incluso metadatos o cadenas de consulta— a una API LLM externa, tiene una pregunta de residencia de datos que responder. Esto es particularmente agudo para las organizaciones que operan bajo GDPR, regulaciones específicas de la industria o reglas de contratación gubernamental. Comprenda exactamente qué datos salen de su entorno SAP, a dónde van y cuáles son las políticas de retención y procesamiento de datos del proveedor.

5. Línea base medible y marco de KPI

Antes de implementar cualquier extensión de IA, establezca una línea de base. Mida las tasas actuales de éxito de búsqueda, los tiempos de carga promedio, los volúmenes de tickets de soporte relacionados con problemas de UX y las tasas de adopción de usuarios. Sin una línea de base, no puede demostrar el ROI, y sin un ROI demostrado, su inversión en IA Fiori tendrá dificultades para asegurar financiación continua. Los mejores proveedores lo ayudarán a establecer esta línea de base como parte del proceso de ventas. Si un proveedor no está interesado en ayudarlo a medir los resultados, eso le dice algo sobre su confianza en el producto.

6. Compatibilidad con actualizaciones

SAP actualiza las aplicaciones Fiori, actualiza las versiones de los servicios OData y lanza nuevas capacidades de launchpad con una cadencia regular. Pregunte a cualquier proveedor de extensiones de IA para Fiori cómo manejan las actualizaciones de SAP. ¿Se rompen sus integraciones cuando SAP lanza una nueva versión de una aplicación? ¿Con qué rapidez certifican la compatibilidad? ¿Cuál es la responsabilidad del cliente frente a la del proveedor cuando una actualización causa un fallo de integración? Esta pregunta separa a los proveedores con productos maduros de aquellos con demostraciones impresionantes.

El camino a seguir

SAP Fiori no va a desaparecer. A pesar de todas sus frustraciones, es la base de la UX para el ecosistema de software empresarial más grande del mundo, y para la mayoría de las grandes organizaciones seguirá siendo central en cómo los empleados interactúan con el ERP en el futuro previsible. SAP sigue invirtiendo en él —Clean Core, ABAP Cloud, la evolución de Joule— y la trayectoria es positiva, incluso si el ritmo de mejora rara vez coincide con las expectativas de los usuarios.

Lo que ha cambiado en 2026 es que las herramientas de IA necesarias para mejorar Fiori se han vuelto realmente accesibles. Hace tres años, construir una capa de búsqueda semántica sobre los datos maestros de SAP era un proyecto de ingeniería significativo que requería habilidades especializadas. Hoy es un patrón bien documentado con componentes disponibles en SAP BTP, APIs LLM maduras y una creciente comunidad de desarrolladores de SAP que lo han hecho antes y han publicado su enfoque.

Mi recomendación práctica: no espere a que SAP resuelva los problemas de UX de Fiori de forma nativa. Identifique los dos o tres patrones de fallo que causan más fricción en su organización específica —ya sea frustración con la búsqueda, tiempo de carga, fiabilidad móvil o caos de roles— y construya una capa de IA dirigida para abordar esos problemas específicos. Comience con una prueba de concepto limitada a un grupo de usuarios o un conjunto de aplicaciones. Mida rigurosamente. Luego, escale lo que funciona.

Las organizaciones que veo triunfar con Fiori en 2026 no son las que esperan el próximo lanzamiento de SAP para arreglar la UX. Son las que tratan a Fiori como una base sobre la que construir, no como un producto terminado que aceptar.

Ese es el cambio de mentalidad que convierte una tasa de adopción del treinta y ocho por ciento en una tasa de adopción del setenta y uno por ciento. Y en TI empresarial, esa diferencia vale millones de dólares.

¿Tiene un problema de UX en Fiori que se resiste a las soluciones estándar? Me interesa saber qué está viendo en su organización; contácteme a través de la página de contacto o conéctese en LinkedIn.