automation

SAP Fiori vs HTML GUI: Por qué no todos los mosaicos son una aplicación Fiori nativa

Ocurre en casi todos los proyectos de S/4HANA. Un usuario inicia sesión en el SAP Fiori Launchpad, ve una cuadrícula limpia de mosaicos, hace clic en uno y llega a una pantalla que se parece sospechosamente a la transacción de SAP GUI que ha usado durante quince años, solo que ejecutándose en una pestaña del navegador. La pregunta natural es: “Un momento, ¿esto es Fiori?”

La respuesta honesta es: no necesariamente. El SAP Fiori Launchpad es un punto de entrada, no una garantía tecnológica. Detrás de esos mosaicos uniformes pueden encontrarse aplicaciones muy diferentes: aplicaciones nativas de SAP Fiori creadas con SAPUI5 o Fiori Elements, desarrollos SAPUI5 freestyle, aplicaciones Web Dynpro ABAP, páginas analíticas o transacciones clásicas de SAP GUI renderizadas en el navegador mediante SAP GUI for HTML (también llamado Web GUI o HTML GUI).

Esta distinción no es académica. Afecta lo que los usuarios pueden esperar de manera realista en términos de experiencia, acceso móvil, rendimiento y formación. También afecta cómo los equipos de proyecto miden el progreso de la modernización. Este artículo explica la diferencia, cuándo tienen sentido los mosaicos de HTML GUI, dónde generan confusión y cómo saber qué abre realmente un mosaico antes de crear un plan de despliegue en torno a él.

¿Qué es una aplicación nativa de SAP Fiori?

Una aplicación nativa de SAP Fiori es una aplicación diseñada y creada de acuerdo con el sistema de diseño SAP Fiori: el conjunto de principios de SAP para experiencias de usuario coherentes, orientadas a tareas y basadas en roles.

En términos prácticos, una aplicación Fiori nativa suele tener estas características:

• Creada con tecnologías SAP Fiori. La mayoría de las aplicaciones nativas utilizan SAPUI5, ya sea como aplicaciones Fiori Elements (generadas a partir de servicios OData anotados mediante planos estándar como List Report u Object Page) o como aplicaciones SAPUI5 freestyle desarrolladas para patrones de interacción más específicos.
• Basada en roles y orientada a tareas. En lugar de una única transacción enorme que cubra decenas de escenarios, una aplicación Fiori se delimita a un rol de usuario específico y a una tarea concreta: aprobar una orden de compra, comprobar el estado de un proveedor, contabilizar un documento simple.
• Conectada a servicios backend modernos. Las aplicaciones nativas suelen consumir servicios OData, lo que habilita funciones como la gestión de borradores, la búsqueda y la navegación estructurada entre objetos relacionados.
• Diseñada para una experiencia moderna. Esto implica una navegación coherente, acciones contextuales y, según la aplicación, un comportamiento adaptable que se ajusta a distintos tamaños de pantalla.

Un modelo mental útil: una aplicación Fiori nativa fue diseñada como una aplicación Fiori desde el principio. No fue convertida, encapsulada ni renderizada como una.

¿Qué es SAP GUI para HTML (Web GUI / HTML GUI)?

SAP GUI para HTML es una tecnología que representa transacciones clásicas de SAP GUI en un navegador web. En lugar de instalar SAP GUI para Windows en una estación de trabajo, la generación de SAP Internet Transaction Server (ITS) dentro de la pila ABAP traduce las pantallas Dynpro clásicas a HTML, y el usuario interactúa con la transacción a través del navegador.

Los puntos importantes:

• La aplicación subyacente sigue siendo la transacción clásica. Cuando un mosaico inicia ME23N o VA03 a través de SAP GUI para HTML, la lógica de negocio, la secuencia de pantallas y la estructura de campos son las de la transacción Dynpro original.
• El navegador es solo la capa de presentación. Las pantallas se convierten a HTML sobre la marcha, por eso conservan el aspecto clásico —barras de menú, teclas de función, navegación basada en pantallas— con algunos temas visuales aplicados para suavizar la apariencia.
• Estas transacciones pueden iniciarse desde el Fiori Launchpad mediante mosaicos y asignaciones de destino, exactamente igual que las aplicaciones nativas. Esto es lo que hace que sea fácil confundirlas.
• El beneficio práctico es real: los usuarios obtienen acceso a transacciones sin una instalación local de SAP GUI, y los administradores obtienen acceso centralizado y basado en navegador a funcionalidades que aún no tienen un equivalente en Fiori.

La representación en un navegador no cambia la naturaleza de la aplicación. Un mosaico de HTML GUI es SAP GUI clásico entregado a través de un canal diferente, no una experiencia rediseñada.

Por qué los mosaicos pueden ser engañosos

El Launchpad de Fiori presenta deliberadamente una superficie unificada. Todos los mosaicos se ven similares: un título, quizá un número de KPI, un estilo visual coherente. Esa consistencia es buena para la navegación, pero oculta la diversidad técnica que hay debajo.

Un solo Launchpad puede contener mosaicos que abren, entre otros:

• Una aplicación nativa de SAP Fiori (por ejemplo, un List Report de Fiori Elements para gestionar pedidos de venta)
• Una aplicación SAPUI5 freestyle creada para un escenario personalizado
• Una transacción clásica de SAP GUI renderizada mediante Web GUI
• Una aplicación Web Dynpro ABAP, común en muchos escenarios de RR. HH. y finanzas
• Una aplicación web personalizada o de terceros incrustada mediante URL
• Una página o informe analítico, como un desglose de KPI de Smart Business

Para el usuario, todo esto son "mosaicos en Fiori". Para el equipo del proyecto, representan diferentes tecnologías con distintas capacidades, limitaciones y ciclos de vida. Tratarlos como intercambiables es donde comienzan los problemas de expectativas: un usuario que tuvo una gran experiencia con una aplicación de aprobación de Fiori Elements hará clic en el siguiente mosaico esperando lo mismo y, en su lugar, puede encontrarse con una transacción clásica densa con navegación mediante teclas de función.

SAP Fiori vs HTML GUI: Comparación práctica

La comparación no es "bueno vs malo". Es "experiencia rediseñada vs acceso preservado". Ambos tienen su lugar, pero deben etiquetarse con honestidad.

Por qué las organizaciones usan mosaicos de HTML GUI

Hay razones sólidas y defendibles por las que los mosaicos de HTML GUI aparecen en Launchpads reales:

• Brechas de cobertura. No todas las transacciones de SAP GUI tienen un equivalente nativo en Fiori. Incluso en las versiones actuales de S/4HANA, algunas áreas funcionales siguen siendo atendidas principalmente por transacciones clásicas.
• Profundidad funcional. Algunas aplicaciones Fiori cubren deliberadamente el 80% más común de un escenario. Los usuarios avanzados que necesitan el 20% restante — vistas especiales de stock, tipos de documentos poco habituales, funciones de modificación masiva — pueden seguir necesitando la transacción completa.
• Migración gradual. La adopción de S/4HANA rara vez es un cambio radical para la experiencia de usuario. Las empresas suelen trasladar roles a Fiori de forma incremental, y la HTML GUI mantiene todo accesible desde un único lugar mientras tanto.
• Un único punto de entrada. Colocar transacciones clásicas detrás de mosaicos del Launchpad ofrece a los usuarios una URL, una estructura de catálogo y un concepto de autorización únicos, en lugar de mantener el acceso a SAP GUI en paralelo para un subconjunto de usuarios.
• Alcance controlado del proyecto. Reconstruir una transacción poco utilizada como una aplicación SAPUI5 personalizada implica un esfuerzo real de desarrollo y mantenimiento. Si la transacción funciona y la usan cinco especialistas al mes, envolverla suele ser la opción racional.

Usados de forma consciente, los mosaicos de HTML GUI son una decisión arquitectónica legítima, no un atajo del que avergonzarse.

Los riesgos de llamar a todo "Fiori"

Los problemas no surgen de la HTML GUI en sí, sino de etiquetarla incorrectamente. Cuando todo en el Launchpad se comunica como "nuestra nueva experiencia Fiori", se acumulan varios riesgos:

• Expectativas de usuario incumplidas. Los usuarios a quienes se les prometió una experiencia moderna hacen clic en un mosaico y obtienen una transacción clásica. La decepción se asocia a todo el programa, incluidas las aplicaciones nativas que realmente son buenas.
• Planes móviles poco realistas. La dirección puede asumir que "ahora todo está en Fiori, así que todo funciona en tabletas". Las pantallas de HTML GUI en un teléfono son, en el mejor de los casos, utilizables en emergencias.
• Material de formación confuso. Si la formación trata todos los mosaicos de la misma manera, explicará en exceso las aplicaciones Fiori simples o explicará de menos las transacciones clásicas complejas. Los formadores necesitan saber cuál es cuál.
• Métricas de modernización infladas. "Tenemos 300 mosaicos en vivo" suena a progreso. Si 220 de ellos son contenedores de Web GUI, la modernización real de la UX es mucho menor de lo que sugiere la cifra, y las decisiones de hoja de ruta basadas en ese número serán incorrectas.
• Rediseño de procesos omitido. Envolver una transacción preserva el proceso antiguo exactamente como era. Los equipos pueden perder la oportunidad —y a veces la necesidad— de replantear el proceso que un rediseño de aplicación nativa habría obligado a revisar.
• Tickets de soporte mal dirigidos. Un problema de renderizado en ITS, un problema de rendimiento en un servicio OData y un error de pantalla Dynpro tienen causas raíz diferentes y responsables diferentes. Si el equipo de soporte no puede distinguir los tipos de aplicaciones, el triaje se ralentiza.

Por qué HTML GUI no siempre es malo

Vale la pena expresar explícitamente una visión equilibrada, porque HTML GUI a menudo se descarta injustamente en las conversaciones sobre modernización:

• Para los usuarios avanzados, la transacción completa suele ser mejor que una aplicación simplificada. Un especialista experimentado en MM que trabaja todo el día en ME21N pierde productividad en una interfaz reducida.
• Conserva la funcionalidad probada sin riesgo de redesarrollo. La transacción se comporta exactamente como se ha validado durante años de uso.
• Reduce la interrupción durante la transición. Los usuarios mantienen flujos de trabajo conocidos mientras la organización desarrolla capacidades de Fiori donde más importan.
• Gestiona la larga cola de transacciones: los cientos de funciones que se usan rara vez, pero que en ocasiones son esenciales y que nunca justificarán una reconstrucción.
• Admite la centralización del acceso: un solo Launchpad, un solo flujo de autenticación, sin instalaciones locales de GUI que gestionar para usuarios ocasionales.

Lo único que no hace es ofrecer una experiencia de usuario nativa de Fiori, y eso está bien, siempre que nadie afirme lo contrario.

Cómo identificar qué tipo de aplicación abre un mosaico

Para cualquiera que evalúe un Launchpad existente o planifique una implementación, estas comprobaciones revelan qué hay realmente detrás de un mosaico:

1. Consulte la SAP Fiori Apps Reference Library. Busque la aplicación por nombre o ID. La biblioteca enumera explícitamente el tipo de aplicación: SAP Fiori (SAPUI5), Web Dynpro o SAP GUI. También muestra los componentes backend requeridos y las versiones disponibles.
2. Observe el tipo de aplicación en los detalles técnicos. En la configuración de contenido del Launchpad (asignaciones de destino, o contenido del launchpad en herramientas más recientes), cada destino especifica si inicia un componente SAPUI5, una aplicación Web Dynpro o una transacción mediante SAP GUI para HTML.
3. Revise la asignación de destino y el objeto/acción semántica. La intención detrás del mosaico apunta a la configuración de inicio concreta, que indica la tecnología.
4. Inspeccione la URL en tiempo de ejecución. Las aplicaciones SAPUI5 suelen cargar un componente dentro del shell del Launchpad; las sesiones de Web GUI muestran patrones de URL de ITS característicos (como rutas que contienen /sap/bc/gui/sap/its/webgui).
5. Aplique la prueba de diseño. ¿La pantalla sigue patrones de Fiori: páginas de objeto, informes de lista, barras de acciones en el pie? ¿O muestra barras de menú clásicas, campos de código OK y sugerencias de teclas de función?
6. Pruebe en escritorio y móvil. Una aplicación nativa y adaptable se ajusta. Una pantalla de Web GUI en un teléfono hace que la diferencia sea obvia en cuestión de segundos.
7. Valide frente al rol y el proceso. Independientemente de la tecnología, confirme que la aplicación realmente admita las tareas que realiza el rol objetivo: una aplicación Fiori nativa que cubre solo parte del proceso aún puede necesitar una transacción clásica junto a ella.

Qué deben documentar los equipos de SAP

La mayor parte de la confusión en Launchpad se puede prevenir con un catálogo interno simple de aplicaciones. Para cada mosaico dentro del alcance, registre:

• Nombre del mosaico y asignación de catálogo/espacio
• Rol de negocio que lo utiliza
• Proceso compatible (vinculado a su documentación de procesos)
• Tipo de aplicación — Fiori Elements, SAPUI5 freestyle, Web Dynpro, SAP GUI para HTML, URL externa
• Clasificación: Fiori nativo o contenedor de HTML GUI
• Transacción SAP GUI relacionada (para transacciones encapsuladas o parcialmente reemplazadas)
• Propietario — funcional y técnico
• Compatibilidad móvil — probada, no asumida
• Limitaciones conocidas en comparación con la transacción clásica o el alcance esperado
• Notas de capacitación — lo que los usuarios deben aprender, qué cambia respecto a antes
• Hoja de ruta de reemplazo, si el mosaico es un contenedor transitorio programado para un sucesor nativo

Este catálogo se convierte en la referencia compartida para los equipos de capacitación, soporte, pruebas y planificación de la hoja de ruta, y hace que el progreso de modernización sea medible en lugar de anecdótico.

Implicaciones para los despliegues de SAP Fiori

Saber qué mosaicos son nativos y cuáles son envoltorios cambia la forma en que ejecutas el despliegue en sí:

• Adopción por parte de los usuarios: Comunica con honestidad. Presenta las aplicaciones nativas como la nueva experiencia y los mosaicos de HTML GUI como un acceso cómodo desde el navegador a transacciones conocidas. Los usuarios perdonan una pantalla clásica; no perdonan que se les diga que es algo que no es.
• Formación: Separa los materiales por tipo de aplicación. Las aplicaciones nativas necesitan una introducción a nuevos patrones de interacción; los mosaicos de Web GUI necesitan, como mucho, una nota indicando que la transacción conocida ahora se abre en el navegador.
• Diseño de roles: Los catálogos y espacios deben reflejar lo que un rol realmente necesita, lo que a menudo implica una mezcla deliberada de aplicaciones nativas para tareas frecuentes y transacciones encapsuladas para trabajo experto.
• Documentación de procesos: Cuando una aplicación nativa reemplazó una transacción, los pasos documentados del proceso suelen cambiar. Cuando se utiliza un envoltorio, normalmente no cambian. Documéntalo en consecuencia.
• Pruebas: Las aplicaciones nativas requieren pruebas de servicios OData y de interfaz de usuario; los mosaicos de Web GUI requieren pruebas de transacciones además de comprobaciones de renderizado en el navegador. Distintos planes de prueba, distintos defectos.
• Expectativas de rendimiento: Establécelas por tipo de aplicación. Los recorridos pantalla por pantalla en Web GUI se comportan de manera diferente a las aplicaciones Fiori respaldadas por OData, especialmente a través de VPN o conexiones de alta latencia.
• Gestión del cambio: Secuencia la comunicación en torno a las experiencias verdaderamente nuevas. Un anuncio de lanzamiento basado en transacciones encapsuladas promete demasiado y socava la credibilidad para las oleadas posteriores.
• Hoja de ruta de modernización: Usa el catálogo de aplicaciones para hacer seguimiento de la conversión real —cuántas tareas de alta frecuencia pasaron a aplicaciones nativas— en lugar de contar mosaicos.

Respuesta final

Un mosaico en el SAP Fiori Launchpad es solo un punto de acceso. No garantiza que la aplicación detrás de él sea una aplicación nativa de SAP Fiori. Las aplicaciones nativas de Fiori, las aplicaciones de Fiori Elements, las aplicaciones SAPUI5 freestyle, las aplicaciones Web Dynpro y las transacciones clásicas de SAP GUI renderizadas mediante SAP GUI for HTML pueden estar todas detrás de mosaicos visualmente idénticos.

Eso no es una falla del Launchpad; así es como se supone que debe funcionar una plataforma pensada para facilitar la transición. El problema comienza solo cuando los equipos dejan de distinguir entre ambas cosas. Antes de tomar decisiones sobre adopción, capacitación, uso móvil, rendimiento o avance de la modernización, identifique qué abre realmente cada mosaico. La tecnología detrás del mosaico, no el mosaico en sí, determina lo que experimentarán los usuarios.

Preguntas frecuentes

¿Cada mosaico de SAP Fiori Launchpad es una aplicación Fiori nativa?

No. Fiori Launchpad puede iniciar aplicaciones nativas de SAPUI5/Fiori Elements, aplicaciones Web Dynpro, transacciones clásicas de SAP GUI mediante SAP GUI for HTML e incluso aplicaciones web externas. El mosaico es solo el punto de entrada; la tecnología detrás de él varía.

¿Cuál es la diferencia entre SAP Fiori y SAP GUI for HTML?

Las aplicaciones SAP Fiori son aplicaciones diseñadas y creadas de acuerdo con los principios de diseño de SAP Fiori, normalmente con SAPUI5 o Fiori Elements y servicios OData. SAP GUI for HTML representa transacciones clásicas existentes de SAP GUI en un navegador sin cambiar su diseño, lógica ni patrones de interacción.

¿HTML GUI es lo mismo que Web GUI?

Sí. "HTML GUI", "Web GUI" y "SAP GUI for HTML" se refieren a la misma tecnología: la representación basada en navegador de transacciones clásicas de SAP GUI a través de Internet Transaction Server (ITS) integrado en la pila ABAP.

¿Se pueden iniciar transacciones de SAP GUI desde Fiori Launchpad?

Sí. A través de asignaciones de destino, las transacciones clásicas pueden iniciarse como mosaicos y abrirse en el navegador mediante SAP GUI for HTML. Esta es una configuración común y compatible, especialmente durante las transiciones a S/4HANA.

¿Por qué algunos mosaicos de Fiori parecen pantallas antiguas de SAP GUI?

Porque son pantallas antiguas de SAP GUI: transacciones Dynpro clásicas representadas como HTML. El mosaico inicia la transacción original a través de Web GUI, por lo que el diseño de pantalla, los menús y la navegación siguen siendo los de SAP GUI clásico, con solo una ligera tematización visual.

¿SAP GUI for HTML es malo?

No. Es una forma práctica de preservar el acceso a transacciones que no tienen un equivalente nativo en Fiori, dar soporte a usuarios avanzados que necesitan toda la profundidad de la transacción y evitar desarrollos innecesarios. Solo se convierte en un problema cuando se presenta como una experiencia Fiori moderna, creando falsas expectativas.

¿Cómo puedo saber si un mosaico es una aplicación Fiori nativa?

Compruebe la aplicación en SAP Fiori Apps Reference Library, inspeccione la asignación de destino o la configuración de contenido del launchpad para ver el tipo de aplicación, observe la URL de ejecución (las sesiones de Web GUI usan rutas ITS características) y aplique la prueba de diseño: las aplicaciones nativas siguen patrones Fiori, mientras que Web GUI muestra menús clásicos y campos de código OK.

¿Deben las empresas reemplazar todos los mosaicos HTML GUI por aplicaciones Fiori nativas?

No necesariamente. Las tareas de alta frecuencia utilizadas por muchos usuarios ocasionales o móviles se benefician más de las aplicaciones nativas. Las transacciones de expertos que se usan rara vez pueden no justificar un nuevo desarrollo y pueden permanecer como mosaicos de Web GUI. El enfoque correcto es una hoja de ruta priorizada basada en el uso, los roles de usuario y el valor de negocio.

¿Un mosaico de Launchpad significa que el proceso se ha modernizado?

No. Un mosaico que encapsula una transacción clásica conserva el proceso existente exactamente como era. La modernización genuina suele implicar rediseñar la experiencia de la aplicación —y a menudo el proceso que hay detrás—, no solo cambiar la forma en que se accede a la transacción.

¿Cómo deben documentar los equipos de SAP los mosaicos de Launchpad?

Mantenga un catálogo interno de aplicaciones que enumere el nombre de cada mosaico, el rol de negocio, el proceso compatible, el tipo de aplicación (Fiori Elements, SAPUI5, Web Dynpro, SAP GUI for HTML), la transacción clásica relacionada, el propietario, el soporte móvil, las limitaciones conocidas, las notas de formación y la hoja de ruta de reemplazo cuando corresponda.

---