¿Qué son las aplicaciones SAP Fiori? Tipos, ejemplos y casos de uso

Las aplicaciones SAP Fiori son aplicaciones basadas en roles que ofrecen a los usuarios de SAP una forma más moderna de completar tareas, analizar datos y trabajar con información de negocio.

Sin embargo, en entornos reales, el término "aplicación Fiori" causa mucha confusión. Un usuario hace clic en un mosaico en Fiori Launchpad y a veces obtiene una aplicación Fiori nativa, otras veces una transacción antigua de SAP GUI ejecutándose a través de Web GUI. Algunas aplicaciones gestionan transacciones, otras gestionan analíticas y otras permiten a las personas explorar objetos de negocio como clientes, proveedores, materiales, pedidos de compra o facturas.

Por eso, entender las aplicaciones Fiori requiere más que memorizar categorías. Necesitas saber para qué está pensado cada tipo, dónde funciona bien y cuándo se queda corto frente a un proceso de negocio real.

Una aplicación puede apoyar una sola tarea de forma excelente y aun así dejar la mayor parte del proceso sin cubrir: las aprobaciones, excepciones, traspasos, plazos, datos faltantes, integraciones y las responsabilidades divididas entre roles.

Este artículo repasa los principales tipos de aplicaciones Fiori, ejemplos típicos, casos de uso prácticos y cómo evaluar si una aplicación estándar es lo suficientemente buena para tu equipo.

¿Qué es una aplicación SAP Fiori?

Una aplicación SAP Fiori sigue los principios de diseño Fiori de SAP y normalmente se accede a ella a través de Fiori Launchpad. Ofrece a los usuarios una forma orientada a tareas de trabajar con datos de SAP, objetos de negocio, informes, aprobaciones o solicitudes. En lugar de pedirle a alguien que recuerde un código de transacción y se oriente en una pantalla saturada, una aplicación Fiori se construye en torno a un rol o una necesidad específicos.

Algunos ejemplos comunes son las aplicaciones que crean una solicitud de compra, aprueban un elemento de flujo de trabajo, revisan facturas abiertas, supervisan KPI de compras, verifican el estado de pedidos de venta, gestionan solicitudes de ausencia o muestran información de proveedores.

Esa orientación a tareas es lo principal que diferencia a Fiori del uso tradicional de SAP GUI. SAP GUI ofrece a los usuarios expertos transacciones densas repletas de opciones, campos, menús y variantes. Fiori reduce el alcance a una sola actividad, lo que ayuda especialmente a los usuarios ocasionales, gerentes, trabajadores móviles y escenarios de autoservicio.

El enfoque es realmente valioso, pero también significa que siempre debe comprobar una aplicación frente al trabajo real que se supone que debe respaldar. Una aplicación Fiori puede parecer más limpia que una transacción antigua, pero lo que importa es si proporciona al usuario suficiente información, acciones, filtros y contexto para completar el trabajo correctamente.

Un mosaico no siempre es una aplicación Fiori nativa

Una suposición muy extendida es que cada mosaico del Launchpad abre una aplicación Fiori nativa. No es así.

Un mosaico es solo un punto de entrada. Lo que se carga al hacer clic en él depende totalmente de cómo esté configurado el Launchpad: podría ser una aplicación Fiori nativa, una aplicación de Fiori elements, una aplicación SAPUI5 personalizada, una página analítica, una transacción clásica de SAP GUI renderizada mediante Web GUI u otra aplicación basada en URL.

La distinción importa porque la gente dirá "estamos usando Fiori" cuando la mitad de sus mosaicos en realidad inician transacciones antiguas en un navegador. Esa puede ser una estrategia de transición perfectamente razonable: centraliza el acceso en el Launchpad sin obligar a rediseñar todas las transacciones de una sola vez, pero nadie debería confundirlo con una experiencia completamente nativa de Fiori.

Para la adopción y la planificación, conviene ser preciso sobre lo que realmente abre cada mosaico: una aplicación Fiori nativa, una aplicación SAPUI5 personalizada, una aplicación de Fiori elements o una transacción clásica expuesta mediante Web GUI. Y más allá de la etiqueta, pregunte si la aplicación mejora la tarea o simplemente cambia el lugar donde el usuario hace clic para iniciarla.

Un Launchpad repleto de mosaicos no es automáticamente una experiencia moderna. El valor proviene de lo que abre cada mosaico y de qué tan bien se ajusta al rol y al proceso detrás de la tarea.

Principales tipos de aplicaciones SAP Fiori

Puedes agrupar las aplicaciones Fiori de varias maneras. Una división común orientada al negocio es entre aplicaciones transaccionales, aplicaciones analíticas y hojas informativas. En proyectos modernos también encontrarás patrones como páginas de resumen, informes de lista, páginas de objeto y páginas de lista analítica. Estos términos se solapan, pero describen cosas ligeramente diferentes: algunos nombran el propósito de una aplicación, otros nombran el patrón de interfaz utilizado para construirla.

En términos prácticos:

• Las aplicaciones transaccionales ayudan a los usuarios a completar una tarea.
• Las aplicaciones analíticas les ayudan a comprender el rendimiento, las tendencias y las excepciones.
• Las hojas informativas les permiten explorar un objeto de negocio.
• Las páginas de resumen resumen lo que importa para un rol o área.
• Los informes de lista ayudan a los usuarios a encontrar y trabajar con muchos registros.
• Las páginas de objeto permiten a los usuarios ver o mantener un registro específico.

El resto del artículo aborda cada uno de estos puntos por separado.

Aplicaciones transaccionales

Las aplicaciones transaccionales son donde se realizan las tareas de negocio en SAP: crear, modificar, aprobar, enviar, liberar, rechazar o contabilizar datos de negocio. Suelen estar más cerca del trabajo operativo diario.

Ejemplos típicos: crear una solicitud de compra, aprobar una orden de compra, contabilizar una entrada de mercancías, gestionar solicitudes de ausencia, liberar un documento de facturación o procesar una solicitud de servicio.

Destacan cuando la tarea es clara y específica para un rol, y no obliga al usuario a pasar por una transacción extensa llena de opciones no relacionadas. Un gerente que solo necesita aprobar solicitudes de compra, por ejemplo, no necesita la profundidad de una transacción completa de compras. Una aplicación de aprobación enfocada puede mostrar el solicitante, el importe, el proveedor, el centro de coste, la justificación, los adjuntos y la acción de aprobación, nada más.

Esto es Fiori en su mejor versión: trabajo guiado y específico para una tarea, dirigido a un rol definido.

Aun así, merece una revisión cuidadosa. Una aplicación simplificada puede ser ideal para usuarios ocasionales y gerentes, e inútil para usuarios avanzados que procesan grandes volúmenes y dependen de filtros avanzados, variantes, cambios masivos y tablas densas. La verdadera pregunta no es si existe una aplicación transaccional, sino si coincide con la forma en que el equipo trabaja realmente.

Aplicaciones analíticas

Las aplicaciones analíticas ayudan a los usuarios a supervisar el rendimiento, detectar excepciones y determinar qué necesita atención. En lugar de impulsar una única transacción, organizan los datos en KPI, gráficos, tablas y resúmenes visuales. Gerentes, analistas, controllers y responsables operativos que necesitan visibilidad a lo largo de un proceso dependen mucho de ellas.

Algunos ejemplos incluyen la supervisión de facturas vencidas, gasto de compras, rendimiento de proveedores, niveles de inventario, rendimiento de ventas, posición de caja o acumulación de solicitudes de servicio.

Una buena aplicación analítica ayuda a responder preguntas como qué elementos están retrasados, qué KPI se ha desviado del rango, qué proveedores, centros o equipos necesitan atención, y qué investigar primero.

Las mejores no se detienen en la visualización: llevan al usuario desde la información hasta la acción. Un gerente puede comenzar en una tarjeta de KPI, detectar un área problemática, abrir la lista de elementos afectados y saltar directamente al objeto o tarea relevante. Eso es lo que hace que las aplicaciones analíticas sean tan útiles para la gestión por excepción: se evita la revisión manual de cada transacción y se concentra la atención en los casos que se desvían.

Todo esto depende de la calidad de los datos, el rendimiento del servicio, el diseño de autorizaciones y KPI que realmente signifiquen algo. Los gráficos atractivos no salvarán métricas que no reflejan cómo funciona el negocio.

Hojas informativas

Las hojas informativas permiten a los usuarios explorar un objeto de negocio específico: un cliente, proveedor, material, orden de compra, pedido de ventas, factura, empleado, centro de coste o activo. En lugar de centrarse en una transacción o un KPI, una hoja informativa presenta el objeto y todo lo relacionado con él.

Una hoja informativa de proveedor podría mostrar los detalles del proveedor junto con órdenes de compra relacionadas, facturas abiertas, contactos, información de pago y enlaces a otras aplicaciones.

Esto importa porque el trabajo empresarial rara vez está aislado. Una orden de compra se vincula con un proveedor, un material, un contrato, una factura, una entrega, una aprobación y un centro de coste. Una hoja informativa expone esas relaciones para que los usuarios no salten a ciegas entre pantallas desconectadas. Son especialmente útiles cuando alguien necesita contexto antes de actuar: por ejemplo, un aprobador o analista que necesita comprender el historial de un objeto y los documentos relacionados antes de decidir qué viene después.

Pero no confundas una hoja informativa con visibilidad completa del proceso. Puede mostrar detalles enriquecidos sobre un objeto mientras el proceso circundante —las reglas, responsabilidades, plazos, excepciones y traspasos— queda fuera de la página.

Páginas de resumen

Las páginas de resumen ofrecen un resumen basado en roles de información, prioridades y acciones. En lugar de abrir varias aplicaciones e informes separados, el usuario ve tarjetas que reúnen lo que importa para su rol: KPI, listas, gráficos, alertas, enlaces rápidos y tareas pendientes.

Un gerente de compras puede querer aprobaciones pendientes, problemas con proveedores, solicitudes abiertas, vencimientos de contratos e indicadores de gasto en una sola pantalla. Un gerente financiero puede querer facturas vencidas, documentos bloqueados, indicadores de caja y colas de excepciones.

Qué tan bien funcione depende del diseño del rol. Mostrar demasiado lo convierte en ruido; mostrar demasiado poco hace que las personas vuelvan a otros informes, hojas de cálculo o SAP GUI. Una buena página de resumen responde una pregunta: ¿qué necesita saber o hacer primero este usuario? Y se gana esa relevancia al construirse en torno a responsabilidades reales, no alrededor de las tarjetas que casualmente estén disponibles.

Informes de lista y páginas de objeto

Los informes de lista y las páginas de objeto son los patrones fundamentales para manejar registros de negocio.

Un informe de lista permite a los usuarios buscar, filtrar, ordenar y revisar muchos registros a la vez; resulta útil cuando necesitan localizar el elemento correcto antes de actuar, ya sean solicitudes de compra abiertas, facturas bloqueadas, pedidos de ventas, avisos de mantenimiento o registros de clientes. Una página de objeto gestiona un único registro en profundidad, reuniendo sus secciones, campos, información relacionada, adjuntos, notas, estado y acciones disponibles en un solo lugar.

Normalmente funcionan como un par: el usuario empieza desde una lista, la reduce con filtros, elige un elemento, abre la página de objeto, revisa los detalles y actúa si está autorizado. Ese ritmo —encontrar el objeto, comprenderlo y actuar sobre él— es la razón por la que el patrón es tan común.

Encaja bien cuando el objeto de negocio está bien definido y el recorrido del usuario es bastante predecible. Encaja peor cuando el trabajo necesita mucha orientación, lógica de interacción inusual, varios roles o traspasos complejos entre departamentos. En esos casos, la aplicación da soporte al objeto sin dar soporte al proceso completo que lo rodea.

Aplicaciones Fiori nativas vs. HTML GUI / Web GUI

Una aplicación Fiori nativa está diseñada según los principios de Fiori: basada en roles, enfocada en tareas, adaptable y plenamente integrada en el Launchpad.

HTML GUI, normalmente llamado Web GUI, es algo diferente. Ejecuta transacciones clásicas de SAP GUI dentro de un navegador. El usuario puede acceder a la transacción desde un mosaico del Launchpad, pero la experiencia subyacente sigue siendo el modelo de transacción GUI más antiguo.

Esa diferencia determina tanto las expectativas de los usuarios como la planificación del proyecto. Una aplicación Fiori nativa ofrece una experiencia más limpia y guiada, adecuada para usuarios ocasionales, gerentes, aprobadores y trabajadores móviles. Una transacción Web GUI conserva la profundidad, la densidad y la familiaridad en las que confían los usuarios expertos.

Ambas coexisten cómodamente. Una empresa puede usar Fiori nativo para aprobaciones, analítica, autoservicio y movilidad, mientras sigue exponiendo transacciones clásicas para trabajo experto o para áreas donde no existe una aplicación Fiori adecuada.

Los problemas comienzan cuando a cada mosaico se le llama "aplicación Fiori". Los usuarios esperan algo moderno y, en su lugar, reciben una transacción antigua en un navegador. Un inventario más honesto — aplicación Fiori nativa, aplicación Fiori elements, aplicación SAPUI5 personalizada, aplicación analítica, transacción clásica a través de Web GUI, aplicación externa o basada en URL — facilita mucho la planificación de la formación, el soporte, la adopción y las hojas de ruta de modernización.

¿Qué es la biblioteca de referencia de aplicaciones SAP Fiori?

La biblioteca de referencia de aplicaciones SAP Fiori es el catálogo oficial de SAP para explorar las aplicaciones Fiori disponibles y el contenido relacionado de Launchpad. Los equipos la utilizan para buscar aplicaciones, conocer qué hacen y revisar detalles técnicos y de implementación. En la mayoría de los proyectos, es el primer lugar al que se recurre cuando alguien quiere saber si ya existe una aplicación estándar para una necesidad determinada.

Puedes investigar aplicaciones disponibles, roles de negocio, componentes de aplicación, productos y versiones requeridos, detalles de implementación, aplicaciones relacionadas e información de configuración.

La biblioteca es realmente útil, pero no sustituye la validación de negocio. Encontrar una aplicación allí no significa que se ajuste a tus usuarios; significa que la aplicación es una candidata que vale la pena evaluar. Antes de adoptar cualquier solución estándar, aún debes confirmar que sea compatible con el proceso requerido, el rol, los datos, el volumen, los campos personalizados, las autorizaciones, las expectativas de rendimiento y los escenarios de excepción.

La biblioteca responde a la primera pregunta: ¿existe una aplicación estándar? El negocio aún debe responder a la segunda: ¿es lo suficientemente buena para la forma en que nuestro equipo trabaja realmente?

Cómo saber si una aplicación estándar es suficientemente buena

Evalúa una aplicación estándar de Fiori frente al trabajo real, no frente a su nombre, descripción o pulido visual.

Empieza por la tarea. "Compras" es demasiado amplio para significar algo; "aprobar una solicitud de compra" o "revisar el desempeño de proveedores" es lo bastante específico para evaluarlo. Recuerda que una aplicación puede resolver muy bien una tarea y aun así ignorar el proceso que la rodea.

Luego pregunta para quién es. Un gerente, un solicitante, un analista, un agente de servicios compartidos, un trabajador de campo y un usuario avanzado llegan con expectativas diferentes. Algunos quieren orientación y simplicidad; otros quieren velocidad, filtros avanzados, acciones masivas, variantes y densidad de información.

A continuación, compárala con el alcance funcional que realmente necesitas: campos obligatorios y personalizados, archivos adjuntos, notas, aprobaciones, documentos relacionados, gestión de excepciones, reglas de autorización, informes y cumplimiento local. Aquí es donde la adopción muere silenciosamente. Una aplicación puede verse más limpia que la transacción antigua y aun así ser rechazada en cuanto los usuarios descubren que falta funcionalidad esencial.

Observa también el proceso, porque una aplicación no es un proceso de negocio. El proceso abarca quién inicia el trabajo, qué datos necesita, quién lo revisa, qué ocurre en caso de rechazo, qué plazos aplican y cómo se gestionan las excepciones.

Por último, revisa el rendimiento, la capacitación y la documentación. Una aplicación lenta, confusa o mal explicada no será adoptada por muy bien que se vea. Las personas necesitan saber no solo qué mosaico abrir, sino cuándo usar la aplicación, qué paso del proceso cubre y qué ocurre después de que actúan.

Una aplicación estándar valiosa no es una que simplemente aparece en el catálogo. Es una que se ajusta al rol, la tarea, el proceso, los datos y el contexto de trabajo lo bastante bien como para resistir el uso diario.

Reflexiones finales

Las aplicaciones Fiori pueden mejorar verdaderamente la forma en que las personas acceden a tareas, información, analíticas y objetos de negocio en SAP: más enfocadas, más basadas en roles y más fáciles de alcanzar a través del Launchpad. Pero todo se reduce al encaje.

Una aplicación transaccional se gana su lugar cuando cubre la tarea con suficiente profundidad. Una aplicación analítica se lo gana cuando revela problemas reales de rendimiento y excepciones. Una hoja de datos se lo gana cuando aporta un contexto significativo. Una página de resumen se lo gana cuando refleja las prioridades reales de un rol. Los informes de lista y las páginas de objeto se lo ganan cuando las personas pueden encontrar, comprender y actuar sobre los registros sin fricción.

La lección que conviene conservar: elegir aplicaciones Fiori no es un ejercicio técnico de catálogo. Una buena evaluación comienza con el proceso de negocio, el rol, los datos, las excepciones, las expectativas de rendimiento y el contexto de trabajo. Las aplicaciones Fiori tienen éxito cuando la aplicación, el rol, la tarea y el proceso están alineados.

Preguntas frecuentes

¿Las aplicaciones SAP Fiori son lo mismo que las transacciones SAP GUI?

No. Las aplicaciones SAP Fiori suelen estar diseñadas en torno a roles, tareas y experiencias de usuario específicas, mientras que las transacciones SAP GUI a menudo ofrecen pantallas más amplias y densas para usuarios expertos. Sin embargo, se puede acceder a algunas transacciones SAP GUI desde el SAP Fiori Launchpad a través de Web GUI, lo que significa que un mosaico del Launchpad no siempre representa una aplicación Fiori nativa.

¿Puede un mosaico de SAP Fiori abrir una transacción clásica de SAP GUI?

Sí. Un mosaico en el SAP Fiori Launchpad puede abrir diferentes tipos de contenido, incluidas aplicaciones Fiori nativas, aplicaciones SAPUI5 personalizadas, páginas analíticas, URL externas o transacciones clásicas de SAP GUI representadas mediante Web GUI. Por eso los equipos deben inventariar qué abre realmente cada mosaico antes de llamar a todo aplicación Fiori.

¿Cuál es la diferencia entre las aplicaciones SAP Fiori transaccionales y analíticas?

Las aplicaciones SAP Fiori transaccionales ayudan a los usuarios a completar tareas de negocio, como crear, aprobar, contabilizar o cambiar registros. Las aplicaciones analíticas ayudan a los usuarios a supervisar el rendimiento, revisar KPI, identificar excepciones y comprender tendencias. En términos simples, las aplicaciones transaccionales respaldan la acción, mientras que las aplicaciones analíticas respaldan la visibilidad y la toma de decisiones.

¿Son suficientes las aplicaciones SAP Fiori estándar para cada proceso de negocio?

No siempre. Una aplicación SAP Fiori estándar puede respaldar muy bien una tarea específica, pero el proceso más amplio puede implicar aprobaciones, excepciones, plazos, campos personalizados, integraciones, traspasos y reglas de negocio locales. Los equipos deben validar cada aplicación frente al proceso real antes de decidir que es suficiente.

¿Por qué algunos usuarios aún prefieren SAP GUI en lugar de SAP Fiori?

Algunos usuarios expertos prefieren SAP GUI porque puede ser más rápido para trabajos densos, repetitivos y de alto volumen. Pueden depender de códigos de transacción, diseños, variantes, filtros avanzados, acciones masivas y tablas compactas que ya les resultan familiares. SAP Fiori puede ser mejor para escenarios guiados, basados en roles, móviles, analíticos y de autoservicio, pero no es automáticamente mejor para cada usuario o tarea.

¿Cómo sé si una aplicación SAP Fiori es útil para mi equipo?

Comience comprobando si la aplicación respalda la tarea, el rol, los datos y el proceso específicos que necesita su equipo. Luego valide la cobertura funcional, los campos personalizados, las autorizaciones, el rendimiento, la usabilidad, las necesidades de formación y los escenarios de excepción. Una aplicación Fiori útil no es solo una que existe en el catálogo; debe ajustarse a la forma en que los usuarios trabajan realmente.

¿Para qué se utiliza la SAP Fiori Apps Reference Library?

La SAP Fiori Apps Reference Library se utiliza para buscar y evaluar las aplicaciones SAP Fiori disponibles y el contenido relacionado del Launchpad. Ayuda a los equipos a comprender el propósito de la aplicación, los roles de negocio, los productos SAP requeridos, los detalles de implementación y la información técnica. Es un punto de partida para la evaluación, no un sustituto de la validación del proceso de negocio.

¿Cuál es la diferencia entre una aplicación SAP Fiori y un proceso de negocio?

Una aplicación SAP Fiori respalda una tarea, pantalla, objeto, informe o interacción del usuario. Un proceso de negocio incluye todo el flujo de trabajo entre roles, decisiones, datos, aprobaciones, excepciones, plazos, sistemas y responsabilidades. Una aplicación Fiori puede mejorar una parte de un proceso, pero no define ni gobierna automáticamente todo el proceso.