Por Qué SAP Fiori Todavía Falla a los Usuarios (Y Cómo los Copilotos IA lo Resuelven)

He pasado gran parte de la última década desplegando, personalizando y solucionando problemas de SAP Fiori en plantas de fabricación, centros de servicios compartidos y redes logísticas globales. He estado junto a contables de cuentas por pagar que murmuraban entre dientes cada vez que una búsqueda devolvía cero resultados. He visto a supervisores de almacén sacar una hoja de cálculo —sí, una hoja de cálculo— porque la app de Fiori en su tablet había colgado por tercera vez en ese turno. Y he tenido la incómoda conversación con un director de IT que acababa de invertir dieciocho meses implantando Fiori en cuatro mil usuarios, solo para descubrir que la adopción se había estancado en el treinta por ciento.

SAP Fiori iba a resolver la UX empresarial. En 2013, cuando SAP lo presentó, el pitch era convincente: una interfaz consistente, basada en roles y de nivel consumer que haría que el ERP se sintiera tan intuitivo como un smartphone. En 2026, esa promesa sigue aterrizando perfectamente en los argumentarios de venta. La realidad en el taller de producción es, si se quiere ser educado, algo más complicada.

Este artículo no es un ataque a SAP. Respeto la ingeniería que hay detrás de estos productos y el progreso genuino que la empresa ha hecho a lo largo de los años. Pero también creo que la honestidad sirve mejor a los consultores SAP y a los líderes de IT que el entusiasmo acrítico. Así que déjame explicarte exactamente dónde Fiori sigue fallando a los usuarios en 2026, por qué es tan difícil arreglarlo desde dentro de la plataforma y —lo más importante— cómo los copilotos IA están empezando a llenar ese hueco de formas 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 construyó sobre cinco principios: basado en roles, responsivo, simple, coherente y satisfactorio. 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, jerarquías de autorización complejas, restricciones de rendimiento de hardware on-premise e integraciones que nunca se diseñaron pensando en una UI mobile-first.

En mi experiencia trabajando con más de treinta clientes empresariales SAP en Europa y Oriente Medio, puedo contar con una mano los despliegues de Fiori donde los usuarios describieron su experiencia diaria como genuinamente fluida. La mayoría describe Fiori igual que su trayecto al trabajo: les lleva adonde necesitan ir, la mayor parte del tiempo, pero no es algo que esperen con ilusión.

La brecha entre el discurso de marketing de Fiori y la experiencia real del usuario se reduce a unas pocas tensiones estructurales que SAP nunca ha resuelto del todo:

• Fiori fue diseñado para la pureza de S/4HANA, pero la mayoría de las organizaciones no son puramente S/4HANA. Los landscapes híbridos —ECC junto a S/4HANA, cloud junto a on-premise— crean costuras que la UI no puede ocultar con elegancia.
• La personalización rompe la coherencia. En el momento en que un cliente empieza a adaptar los tiles, workflows y campos de Fiori a 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 deprioritiza.
• El rendimiento de Fiori depende de una infraestructura en la que muchas organizaciones invierten insuficientemente. El servidor frontend, 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, por la mayoría de métricas, una mejora significativa respecto al SAP GUI que reemplazó para muchos tipos de transacciones. Pero mejora significativa no es lo mismo que problema resuelto, y en 2026 el listón de la UX empresarial ha subido considerablemente. Los usuarios comparan ahora su software de trabajo con herramientas como Notion, Slack y Copilot en Microsoft 365. Fiori, incluso en su mejor versión, no puede competir en esa dimensión sin aumentación externa.

Los 5 Patrones de Fallo de UX de Fiori

Seamos específicos. Las quejas vagas sobre "mala UX" no ayudan a nadie. Estos son los cinco patrones de fallo que encuentro de forma más consistente a lo largo de los proyectos 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 es el tiempo de carga. No caídas catastróficas, sino lentitud. Un responsable de compras espera entre cuatro y seis segundos a que se renderice la app Gestionar Pedidos de Compra. Un manager espera tres segundos a que cargue el tile Mi Bandeja de Entrada tras aprobar un documento. A lo largo de un día completo de trabajo, esto suma entre quince y 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 ajustados, índices faltantes en las CDS views, configuración de caché insuficiente en el SAP Web Dispatcher, o simplemente un servidor de aplicaciones sobrecargado. La solución está casi siempre en la infraestructura o en el lado del backend, no en la capa de UI, lo que significa que cae fuera del ámbito del equipo de Fiori y se deprioritiza en el backlog de versiones.

Una vez realicé una auditoría de rendimiento para un fabricante de automoción alemán y descubrí que su app de Fiori más utilizada —una pantalla de confirmación de entrada de mercancías personalizada— hacía once llamadas OData separadas en la carga inicial. Los desarrolladores originales la habían construido así 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 corrección tardó tres días. El problema llevaba dos años existiendo.

2. Campos Obligatorios que Bloquean la Búsqueda Significativa

La búsqueda en Fiori —especialmente en las apps transaccionales más antiguas— obliga a los usuarios a introducir valores de campo específicos antes de que el sistema devuelva resultados. Ve a la app Visualizar Pedido de Compra en muchos sistemas S/4HANA e intenta buscar todos los pedidos creados en los últimos siete días sin saber de antemano el número de proveedor o el número de documento. En muchas configuraciones estándar, la búsqueda no devuelve nada, o peor aún, te fuerza de vuelta a una pantalla de selección que resulta indistinguible de la transacción ME23N del SAP GUI.

Este es un fallo de UX integrado en la arquitectura. Los servicios OData subyacentes a menudo requieren que ciertos campos estén rellenos 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 arriesga problemas de rendimiento a escala. Así que la restricción persiste y los usuarios desarrollan alternativas —habitualmente un colega que conoce los parámetros de búsqueda mágicos, o un informe personalizado que bypasea Fiori por completo.

3. Búsqueda que Devuelve Cero Resultados

Relacionado pero distinto: la funcionalidad de búsqueda de Fiori —tanto dentro de las apps como en la búsqueda global— es frágil de formas que frustran a los usuarios diariamente. 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 no se ha habilitado la búsqueda difusa no devuelve nada. Buscar un business partner por su dirección de correo electrónico en una app estándar de Fiori no devuelve nada, porque el índice de búsqueda no estaba configurado para incluir ese campo.

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

4. Caídas de la App Móvil y Fallos Offline

SAP ha invertido mucho en su portfolio móvil —SAP Mobile Start, el SAP Fiori Client y diversas apps nativas construidas sobre el stack SAP BTP Mobile Services. En demostraciones controladas funcionan bien. En entornos de producción, especialmente en sectores donde el uso móvil es crítico (logística, servicio de campo, fabricación), la experiencia es más inestable.

Los modos de fallo comunes que he documentado en sitios de clientes incluyen: la app SAP Fiori Client que se cuelga al cambiar entre múltiples sistemas backend; las capacidades offline que no sincronizan correctamente cuando el dispositivo se reconecta a la red; las notificaciones push para aprobaciones de workflow que llegan horas después de que otra persona ya completó la aprobación; y el diseño móvil de algunas apps de Fiori que simplemente se renderiza mal en tamaños de pantalla no estándar porque los breakpoints responsivos nunca se probaron en los dispositivos reales usados en el campo.

Un cliente logístico mío en los Países Bajos desplegó 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 basados en papel para las entradas de mercancías porque la app era "poco fiable". Eso no es un fallo tecnológico en abstracto: es un problema de continuidad de negocio con un coste medible.

5. Caos de Visibilidad de Tiles por Roles

El launchpad de Fiori supuestamente muestra a los usuarios exactamente los tiles relevantes para su rol. En teoría, es elegante: un administrativo de compras ve las apps de compras, un manager de finanzas ve las apps de finanzas, y nadie ve lo que no debería 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 ido acumulando durante años de cambios organizativos, adiciones de proyectos y autorizaciones de emergencia.

Lo que típicamente encuentro: usuarios con quince a veinte tiles en su launchpad, de los cuales usan tres habitualmente. Usuarios que no pueden encontrar una app que necesitan porque fue asignada a un nombre de rol ligeramente diferente. Usuarios que recibieron acceso temporal a un tile durante un proyecto y ahora no pueden quitarlo sin una solicitud formal de cambio a IT. Usuarios en roles compartidos que ven tiles que solo son relevantes para un subconjunto de sus compañeros, generando confusión sobre qué se supone que deben hacer con ellos.

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

Por Qué SAP Tiene Dificultades para Resolver Esto Desde Dentro

Quiero ser justo aquí, porque los retos que SAP enfrenta para mejorar la UX de Fiori son genuinamente difíciles. No es un caso de indiferencia corporativa, sino de restricciones arquitectónicas que no tienen soluciones sencillas.

La lógica de negocio principal de SAP vive en ABAP —un lenguaje y runtime extraordinariamente capaz para procesar grandes volúmenes de transacciones de negocio de forma fiable, pero diseñado en una época en que la UI era una ocurrencia de último momento. Los servicios OData de los que depende Fiori son, en la mayoría de los casos, wrappers 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 —reemplazarlos con APIs cloud-native construidas sobre SAP BTP, por ejemplo— es exactamente lo que SAP está haciendo con S/4HANA Cloud y su estrategia Clean Core. Pero esa transición llevará años para la mayoría de las organizaciones, y mientras tanto las restricciones heredadas permanecen. La personalización añade otra capa de complejidad: cada modificación de un cliente a una app de Fiori crea una carga de mantenimiento que hace que las actualizaciones sean más arriesgadas 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 las expectativas de los usuarios avanzan al ritmo de la tecnología de consumo. La brecha es estructural y no se cerrará solo mediante versiones incrementales de la plataforma.

Cómo los Copilotos IA Abordan Cada Patrón de Fallo

Aquí es donde las cosas se vuelven genuinamente interesantes. Los copilotos IA —ya sea el propio Joule de SAP, agentes LLM personalizados integrados vía SAP BTP, o soluciones híbridas que combinan ChatGPT o Gemini con APIs SAP— pueden abordar los fallos de UX de Fiori de formas que no requieren reescribir la arquitectura subyacente. Trabajan en torno a las restricciones añadiendo una capa inteligente por encima.

Resolver Tiempos de Carga Lentos con Prefetch Predictivo

Los copilotos IA con acceso a datos de comportamiento del usuario pueden predecir qué apps es probable que abra un usuario y precargar los datos relevantes antes de que el usuario navegue allí. Si un responsable de compras abre la app Gestionar Pedidos de Compra cada mañana a las 8:15 y filtra por un grupo de compras específico, un agente predictivo puede disparar esa llamada OData en segundo plano a las 8:10, de modo que los datos estén en caché y listos cuando el usuario llegue.

Esto no es una capacidad hipotética —es un patrón que se ha implementado usando el Application Router de SAP BTP combinado con un modelo ML ligero entrenado con logs de sesiones de usuario. La implementación se parece aproximadamente a esto:

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

  // Query prediction model for likely next navigation
  const prediction = await prefetchModel.predict({
    userId,
    currentHour,
    lastVisitedApp: sessionStore.get(userId)?.lastApp
  });

  if (prediction.confidence > 0.75) {
    // Warm the OData cache for the predicted next app
    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 apps más utilizadas en un promedio de 2,8 segundos: no haciendo las apps más rápidas, sino haciendo invisible la espera.

Resolver 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 IA puede resolver la restricción de forma conversacional. En lugar de que el usuario llegue a un callejón sin salida, escribe "muéstrame pedidos 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 apps estándar. Para las apps personalizadas, el mismo patrón puede implementarse usando un LLM con function calling que ha recibido acceso a un conjunto de APIs SAP:

# Example: LLM function definition for vendor lookup
functions = [
  {
    "name": "resolve_vendor",
    "description": "Resolve a vendor name or partial name to an SAP vendor number",
    "parameters": {
      "type": "object",
      "properties": {
        "vendor_name": {
          "type": "string",
          "description": "The vendor name or partial name provided by the user"
        },
        "company_code": {
          "type": "string",
          "description": "Optional company code to narrow the search"
        }
      },
      "required": ["vendor_name"]
    }
  }
]

# The LLM resolves user intent, calls the function,
# then populates the Fiori search fields programmatically
# via the SAP UI5 API or a BTP-side automation agent

Resolver la Búsqueda sin Resultados con Matching Semántico y Difuso

Las capas de búsqueda impulsadas por IA pueden situarse delante de la búsqueda nativa de Fiori y traducir las consultas de usuario en búsquedas estructuradas que realmente devuelven resultados. Un usuario que busca "facturas de Mueller más de 50k" obtiene resultados porque la capa IA gestiona la resolución de variantes de nombre ("Mueller" / "Müller"), entiende el filtro de importe como restricción numérica y mapea "facturas" al tipo de documento correspondiente en SAP.

La propia Enterprise Search de SAP y la interfaz de lenguaje natural de Joule avanzan en esta dirección para el contenido estándar. Para organizaciones que necesitan extender esto a objetos personalizados y tablas Z, construir una capa de búsqueda semántica en BTP usando embeddings vectoriales de datos maestros SAP —indexados nocturnamente desde S/4HANA— es un enfoque práctico que varios de mis clientes ya tienen en producción.

Resolver Fallos Móviles con Agentes IA Offline-First

Los fallos de Fiori móvil son a menudo fallos de sincronización: la app no sabe qué hacer cuando pierde conectividad, o hace suposiciones incorrectas sobre el estado de los datos cuando se reconecta. Los agentes IA pueden gestionar esto de forma más inteligente manteniendo un modelo de estado local, poniendo en cola las acciones realizadas offline 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 BTP Mobile Services de SAP ahora incluyen hooks de resolución de conflictos que pueden extenderse con lógica personalizada. Una capa IA puede clasificar los conflictos —"este parte de entrada fue registrado por un compañero mientras estabas offline; ¿quieres cancelar el tuyo o escalarlo?"— en lugar de dejar al usuario con un mensaje de error críptico.

Resolver el Caos de Tiles con Recomendaciones de Roles por 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 frente a los que se les han asignado. La IA puede ayudar analizando los patrones de uso reales —qué tiles abre cada usuario, con qué frecuencia y en qué contexto— y generando recomendaciones tanto para usuarios como para administradores.

Para los usuarios, esto parece un launchpad personalizado que muestra las tres apps que es más probable que necesiten ahora mismo, basándose en la hora del día, la carga de trabajo actual y el comportamiento histórico. Para los administradores, parece un panel de detección de anomalías que señala usuarios con roles asignados que nunca han usado (candidatos potenciales para desprovisionamiento) y usuarios que frecuentemente navegan fuera de Fiori para realizar tareas que sugieren una asignación de tile faltante.

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

El Caso del Cierre Mensual: De 40 Clics a 3 Prompts

El ejemplo más ilustrativo que puedo dar de lo que un copiloto IA hace realmente a la UX de Fiori viene de una controller con la que trabajé en una empresa manufacturera de tamaño medio en Alemania —1.400 millones de EUR de facturación anual, S/4HANA on-premise, tres códigos de empresa que gestionar.

Su rutina de cierre mensual era una ilustración manual de los fallos de Fiori a escala. La secuencia específica que cronometré: verificar acumulaciones abiertas, comprobar que todas las cuentas de compensación EM/RF estaban conciliadas e identificar cualquier partida grande sin contabilizar antes de que se bloqueara el período.

En Fiori, esto implicaba navegar por cuatro apps separadas: Visión General de Informes Financieros, un tile de acumulaciones personalizado, Análisis de Compensación EM/RF y el Monitor de Cierre de Período. Cada app requería su propia configuración de filtros, y cada una exigí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 —realizado dos veces al día durante los últimos tres días laborables de cada mes.

Son 6 horas al mes de tiempo de un profesional financiero senior dedicadas a hacer clic en la navegación de aplicaciones. No analizando, no decidiendo, no comunicándose con el negocio. Haciendo clic.

La Implementación del Copiloto IA

La capa del copiloto tardó tres semanas en construirse: un middleware Python que llamaba a APIs OData para acumulaciones (vía servicio OData personalizado), partidas EM/RF (API_PURCHASING_DOCUMENT_SRV) y estado del período abierto (wrapper BAPI personalizado). El LLM recibió un prompt de sistema específico de finanzas y los esquemas de función para cada API. Esta es la interacción que reemplazó 66 minutos de navegación en Fiori:

User: "Run my month-end close check for company codes 1000, 2000, 3000"

[Copilot calls 4 OData endpoints sequentially, ~12 seconds total]

Response:
------------------------------------------------------------------
MONTH-END STATUS | 2026-03-28 | 3 days to period close

COMPANY 1000 (DE): ACTION REQUIRED
  Unconfirmed accruals: 3 items (largest: EUR 340,000 — Vendor 100234)
  GR/IR uncleared: 12 items, EUR 89,450 (oldest: 45 days)
  --> Review accrual 900001234 before cutoff

COMPANY 2000 (AT): OK
  GR/IR uncleared: 4 items, EUR 12,300 (within tolerance)
  No accruals requiring action

COMPANY 3000 (CH): OK
  1 accrual pending (EUR 15,000) — low risk

Next step: Show accrual detail for Company 1000, or export full GR/IR list?
------------------------------------------------------------------

User: "Show accrual detail for 1000"

[One more API call, 3 seconds]

Response: Accrual 900001234 | EUR 340,000 | Service PO 4500089234
  Vendor: Logistics Partner AG | Posted: 2026-03-01
  Confirmation deadline: 2026-03-29 (tomorrow)
  Contact: buyer.name@company.com
  Suggested action: Email buyer to confirm or reverse by EOD tomorrow
------------------------------------------------------------------

Tres entradas del usuario. Menos de dos minutos. La controller revisó la misma información que antes le llevaba 66 minutos de navegación en Fiori, y lo hizo con mayor confianza porque el resumen destacaba la excepción que requería acción en lugar de exigirle que la encontrara por sí misma a través de cuatro pantallas de aplicación separadas.

Anualizado, esto recuperó aproximadamente 72 horas de tiempo de profesional financiero senior al año para este único proceso —a 110 EUR por hora con coste total, son 7.920 EUR en tiempo productivo recuperado anualmente. La capa del copiloto costó aproximadamente 15.000 EUR construirla y 2.400 EUR al año operarla en costes 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 coste adicional de construcción.

Por Qué 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 IA gestiona la recuperación de datos y el reconocimiento de patrones; el humano toma cada decisión y realiza cada acción. El copiloto no contabiliza acumulaciones, no compensa partidas EM/RF, no bloquea el período. Muestra las excepciones que requieren atención humana y las presenta en un formato que reduce la carga cognitiva de encontrarlas.

Este es el encuadre correcto para los copilotos IA en entornos SAP. No automatización del juicio. Automatización de la navegación que siempre ha sido el coste adicional del juicio.

Implementación Real: Antes y Después con Métricas

Quiero compartir un caso de estudio compuesto basado en trabajo en el que he participado durante los últimos dieciocho meses —detalles anonimizados 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 torno al 38% de su población de usuarios prevista. El resto utilizaba una combinación de transacciones SAP GUI, informes personalizados y alternativas. La dirección de IT había identificado tres causas raíz: frustración con la búsqueda, rendimiento lento en las apps de pedidos de compra y confusión sobre el launchpad para usuarios cuyos roles habían cambiado recientemente durante una reorganización.

Fase 1: Capa de Búsqueda Impulsada por IA (T1 2025)

Desplegamos una capa de búsqueda semántica construida sobre SAP BTP, usando embeddings vectoriales indexados nocturnamente de datos maestros de proveedores, materiales y clientes. La UI de búsqueda se mostró como un tile personalizado de Fiori en el launchpad —un único cuadro de búsqueda, sin campos obligatorios, con soporte para consultas en lenguaje natural.

Antes: Sesión de búsqueda media que resultaba en un registro encontrado con éxito: 3 minutos y 40 segundos. Los usuarios reportaban una media de 2,1 búsquedas fallidas al día.

Después (90 días post-despliegue): Sesión de búsqueda exitosa media: 48 segundos. Búsquedas fallidas por usuario al día: 0,4. Tickets de soporte relacionados con "no encuentro proveedor/material/cliente": bajaron un 62%.

Fase 2: Prefetch Predictivo para las 10 Apps Más Usadas (T2 2025)

Instrumentamos el Application Router de SAP BTP para registrar eventos de navegación anonimizados y entrenamos un modelo ligero de gradient boosting (actualizado semanalmente) para predecir la siguiente app a la que navegaría un usuario, dado su rol, hora actual y los últimos tres pasos de navegación. El prefetch se disparaba para predicciones con una confianza superior al 70%.

Antes: Tiempo de carga medio para las cinco apps más usadas: 4,1 segundos.

Después: Tiempo de carga percibido (tiempo desde el clic hasta la interactividad): 1,3 segundos para cargas precargadas, que representaron el 67% de todas las navegaciones. Tiempo medio de carga percibido general: 1,9 segundos.

Fase 3: Personalización del Launchpad Impulsada por IA (T3 2025)

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

Antes: Número medio de clics para llegar a la app correcta desde el launchpad: 3,2 (incluidos tiles incorrectos pulsados y navegación hacia atrás).

Después: 1,4 clics de media. Puntuación de satisfacción del usuario con el launchpad (escala 1–5, medida mediante micro-encuestas integradas): de 2,1 a 3,8.

Impacto Combinado Tras 12 Meses

La adopción de Fiori en toda la población de usuarios aumentó del 38% al 71%. El equipo de IT estimó que esto representaba aproximadamente 1,2 millones de EUR en recuperación anual de productividad —basado en el tiempo anteriormente dedicado a alternativas y búsquedas fallidas, valorado a costes de personal totalmente cargados. Las tres capas de IA costaron aproximadamente 180.000 EUR para construir y desplegar a lo largo del período de doce meses, más 40.000 EUR al año en infraestructura BTP y mantenimiento continuos. El cálculo del ROI fue tan directo que el CFO aprobó un roadmap de Fase 2 en treinta días desde que vio 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 IA en 2026, porque el ruido de marketing es considerable y las capacidades reales difieren significativamente.

SAP Joule es el copiloto IA generativo nativo de SAP, integrado en S/4HANA Cloud, SuccessFactors, Ariba y otros productos cloud de SAP. Su ventaja clave es la integración nativa y estrecha con los datos y procesos SAP —entiende el modelo de datos de SAP, respeta las autorizaciones de SAP y puede realizar acciones dentro de los workflows de SAP sin requerir código de integración 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 muy específicos del sector. También requiere licencias de SAP Business AI además de tu suscripción SAP existente.

Las integraciones ChatGPT-SAP (y patrones equivalentes usando Claude, Gemini o LLMs de código abierto) ofrecen mucha más flexibilidad en lo que puedes hacer, pero requieren significativamente más trabajo de integración. Tú construyes el pegamento: APIs SAP, middleware BTP, autenticación, controles de privacidad de datos y la propia interfaz conversacional. La ventaja es que puedes adaptar el comportamiento de la IA con precisión a los procesos y al modelo de datos de tu organización. El riesgo es que eres propietario del mantenimiento de una pila de integración personalizada en un panorama de proveedores que está evolucionando rápidamente.

Los agentes LLM personalizados en BTP —un patrón cada vez más común entre los grandes clientes SAP— se sitúan entre estos dos extremos. Alojas el LLM en SAP BTP (o llamas a una API LLM externa desde BTP), lo envuelves con los servicios de seguridad y conectividad de BTP y construyes integraciones de function calling contra tus servicios OData de S/4HANA. Esto te da la profundidad de integración de Joule con la flexibilidad de un LLM personalizado. El coste operativo es mayor que usar Joule, pero para organizaciones con requisitos complejos o específicos del sector, suele ser la decisión correcta.

Qué Buscar al Evaluar Extensiones IA para Fiori en 2026

Si estás evaluando soluciones de copiloto IA para tu entorno Fiori ahora mismo, estos son los criterios que uso con los clientes. No son teóricos: vienen de haber estado en demostraciones de proveedores, ejecutado pruebas de concepto y visto lo que importa cuando llega el momento de la verdad en producción.

1. Conciencia de Autorizaciones

Cualquier capa IA que interactúe con datos SAP debe respetar el modelo de autorización de SAP. Esto parece obvio, pero es fácil construir una capa de búsqueda IA que bypasea la seguridad a nivel de fila porque la IA consulta un almacén de datos replicado en lugar del sistema SAP live. Pregunta específicamente a los proveedores: ¿cómo gestiona tu solución los objetos de autorización SAP? ¿Puede un usuario consultar la IA y recibir datos para los que no tiene autorización en la app nativa de Fiori? Si la respuesta es vaga, trátala como una señal de alarma.

2. Explicabilidad

Cuando un copiloto IA realiza una acción —envía un formulario, resuelve un nombre de proveedor, navega a una app— los usuarios y los auditores necesitan entender qué ocurrió. Las buenas extensiones IA de Fiori muestran su razonamiento: "Busqué al proveedor 100234 (Siemens AG) basándome en tu consulta 'Siemens'" y "Prerellené el campo de código de empresa con 1000 basándome en tu perfil de usuario". Esto no es solo un detalle de UX, es un requisito de auditoría en muchos sectores regulados.

3. Degradación Elegante

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

4. Residencia y Privacidad de Datos

Si tu copiloto IA envía datos SAP —incluso metadatos o cadenas de consulta— a una API LLM externa, tienes una pregunta de residencia de datos que responder. Esto es especialmente crítico para organizaciones que operan bajo el RGPD, regulaciones específicas del sector o normas de contratación pública gubernamentales. Entiende exactamente qué datos salen de tu entorno SAP, a dónde van y cuáles son las políticas de retención y procesamiento de datos del proveedor.

5. Baseline Medible y Marco de KPIs

Antes de desplegar cualquier extensión IA, establece una línea base. Mide las tasas actuales de éxito de búsqueda, los tiempos de carga medios, los volúmenes de tickets de soporte relacionados con problemas de UX y las tasas de adopción de usuarios. Sin una línea base, no puedes demostrar el ROI —y sin ROI demostrado, tu inversión en IA para Fiori tendrá dificultades para asegurar financiación continuada. Los mejores proveedores te ayudarán a establecer esta línea base como parte del proceso de venta. Si un proveedor no está interesado en ayudarte a medir resultados, eso te dice algo sobre su confianza en el producto.

6. Compatibilidad con Actualizaciones

SAP actualiza las apps de Fiori, actualiza las versiones de los servicios OData y lanza nuevas capacidades de launchpad en una cadencia regular. Pregunta a cualquier proveedor de extensiones IA para Fiori cómo gestionan las actualizaciones de SAP. ¿Se rompen sus integraciones cuando SAP lanza una nueva versión de una app? ¿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. Con todas sus frustraciones, es la base de 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 continúa invirtiendo en él —Clean Core, ABAP Cloud, la evolución de Joule— y la trayectoria es positiva, aunque el ritmo de mejora rara vez coincide con las expectativas de los usuarios.

Lo que ha cambiado en 2026 es que las herramientas IA necesarias para augmentar Fiori se han vuelto genuinamente accesibles. Hace tres años, construir una capa de búsqueda semántica sobre datos maestros 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 comunidad creciente de desarrolladores SAP que lo han hecho antes y han publicado su enfoque.

Mi recomendación práctica: no esperes a que SAP resuelva los problemas de UX de Fiori de forma nativa. Identifica los dos o tres patrones de fallo que causan más fricción en tu organización específica —ya sea la frustración con la búsqueda, el tiempo de carga, la fiabilidad móvil o el caos de roles— y construye una capa IA dirigida para abordar esos problemas específicos. Empieza con una prueba de concepto limitada a un grupo de usuarios o a un conjunto de apps. Mide rigurosamente. Después escala lo que funciona.

Las organizaciones que veo triunfar con Fiori en 2026 no son las que esperan que la próxima versión de SAP solucione la UX. Son las que tratan 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 del setenta y uno por ciento. Y en IT empresarial, esa diferencia vale millones.

¿Tienes un problema de UX en Fiori que resiste las soluciones estándar? Me interesa conocer lo que estás viendo en tu organización — contacta a través de la página de contacto o conéctate en LinkedIn.