¿Cuándo debería mantener SAP GUI en lugar de migrar a Fiori?

Si su organización está ejecutando un proyecto de S/4HANA, probablemente haya escuchado alguna versión del mismo mensaje: SAP Fiori es el futuro, SAP GUI es el pasado, y cada transacción debería convertirse eventualmente en un mosaico en el Launchpad.

La realidad dentro de la mayoría de los entornos SAP es más matizada. SAP Fiori es una mejora real para muchos escenarios: aprobaciones desde un teléfono, solicitudes de autoservicio, vistas analíticas generales, tareas guiadas para usuarios ocasionales. Pero tratar Fiori como un reemplazo automático de cada transacción de SAP GUI es una decisión de proyecto, no una decisión del usuario, y a menudo resulta contraproducente. Los equipos que imponen una migración completa sin evaluar cómo se realiza realmente el trabajo suelen observar los mismos síntomas: empleados de cuentas por pagar que discretamente piden recuperar su antigua transacción, supervisores de almacén que alternan entre tres aplicaciones para hacer lo que antes se hacía en una sola pantalla, mesas de ayuda saturadas de tickets de “¿dónde quedó mi transacción?” e informes de adopción que se ven peor tres meses después de la puesta en marcha que el primer día.

Este artículo no es una defensa de SAP GUI ni una crítica de SAP Fiori. Es una guía práctica para una pregunta que todo equipo de S/4HANA y de modernización de interfaces acaba enfrentando: para este usuario, proceso y tarea específicos, ¿qué interfaz encaja realmente?

SAP GUI y SAP Fiori resuelven problemas diferentes

Parte de la confusión surge al comparar ambos como si fueran versiones competidoras de lo mismo. No lo son.

SAP GUI está centrado en las transacciones. Fue creado en torno a la idea de que un usuario capacitado abre un código de transacción — VA01, ME21N, MIGO, FBL1N — y trabaja en una pantalla densa, orientada al teclado, que expone casi todo lo que puede hacer el objeto de negocio subyacente. Pestañas, teclas de función, cuadrículas ALV, variantes de diseño, entrada por lotes: el diseño presupone experiencia y la recompensa. Para alguien que ejecuta la misma transacción doscientas veces al día, esa densidad no es desorden. Es rendimiento.

SAP Fiori se basa en roles y está orientado a tareas. En lugar de preguntar "¿qué transacción necesito?", pregunta "¿qué necesita lograr este rol?" Una aplicación Fiori normalmente aísla una tarea — aprobar una solicitud de compra, crear una solicitud de ausencia, revisar facturas de proveedores — y la presenta en una interfaz moderna, adaptable y basada en navegador, que funciona en un equipo de escritorio, una tableta o un teléfono. Para alguien que usa SAP dos veces al mes, ese enfoque no es una limitación. Es lo que hace posible realizar la tarea sin capacitación.

Planteado de esta manera, la pregunta "¿Cuál es mejor?" no tiene una respuesta útil. La pregunta útil es: ¿cuál se ajusta a este usuario, este proceso y esta tarea? El resto de este artículo desglosa esa pregunta en criterios de decisión concretos.

Cuándo SAP GUI aún puede ser la mejor opción

Hay escenarios recurrentes en los que SAP GUI sigue siendo la opción más práctica, incluso en un entorno S/4HANA maduro:

• Trabajo operativo de alto volumen. Los roles que procesan grandes colas de documentos — verificación de facturas con MIRO, movimientos de mercancías con MIGO, entrada de pedidos de venta con VA01 — dependen de la repetición, la memoria muscular y el mínimo de clics por documento. Un rediseño de pantalla que añada incluso dos segundos por documento cuesta horas por semana a gran escala.
• Usuarios que trabajan mediante códigos de transacción y accesos directos. Los usuarios experimentados navegan por SAP escribiendo /n y un código T, encadenando pantallas con teclas de función y saltando entre sesiones. Sustituir eso por navegación con mosaicos y búsqueda elimina un método de trabajo que han optimizado durante años.
• Tareas que necesitan muchos campos, pestañas, filtros o cuadrículas de datos. Algunos objetos de negocio son simplemente complejos. Una orden de producción, un elemento WBS o un maestro de materiales completo (MM02 con sus decenas de vistas) no se vuelve más simple porque la pantalla sea más sencilla; la complejidad simplemente se divide en más pasos.
• Procesos con transacciones GUI maduras y sin una aplicación Fiori equivalente. El catálogo Fiori de SAP es amplio, pero no completo, y la cobertura varía según el módulo y la versión. Cuando la transacción clásica es la única opción con todas las funciones, mantenerla no es resistencia al cambio; es la única forma de realizar el trabajo.
• Transacciones altamente personalizadas. Las transacciones Z, las salidas de pantalla, los campos personalizados y los procesos con muchas ampliaciones a menudo no tienen ningún equivalente en Fiori, y reconstruirlos como aplicaciones Fiori personalizadas es un proyecto de desarrollo, no una tarea de configuración.
• Trabajo técnico y administrativo. Las actividades de Basis, ABAP y soporte — SE38, SM37, ST22, SU01, SPRO — encajan de forma natural en SAP GUI. Hay poco valor práctico en trasladar la supervisión de jobs o la depuración a un mosaico de navegador.
• Situaciones en las que la velocidad y la densidad pesan más que la simplicidad visual. Cuando la medida del éxito son los documentos por hora en lugar de la facilidad del primer uso, la interfaz más densa suele ganar.

Cuándo SAP Fiori puede ser la mejor opción

La misma lógica funciona en la dirección opuesta. Hay escenarios en los que SAP GUI es claramente la herramienta equivocada y Fiori aporta valor real y medible:

• Uso en móviles y tabletas. SAP GUI nunca fue diseñado para un teléfono. Fiori sí.
• Operaciones de campo. Los técnicos que confirman órdenes de mantenimiento, los conductores que registran entregas o los inspectores que capturan resultados en sitio se benefician directamente de aplicaciones responsivas y aptas para el uso táctil.
• Usuarios ocasionales. Un empleado que presenta un informe de gastos al mes nunca debería necesitar aprender un código de transacción.
• Aprobaciones de gerentes. Aprobar solicitudes de compra, solicitudes de vacaciones u hojas de horas desde una aplicación de bandeja de entrada —a menudo en segundos, desde cualquier lugar— es uno de los casos de uso más sólidos de Fiori.
• Escenarios de autoservicio. El autoservicio de RR. HH., las solicitudes de compras y la gestión de viajes funcionan mejor como recorridos guiados que como transacciones para expertos.
• Acceso basado en roles. Presentar a cada rol solo los mosaicos que necesita reduce el ruido y simplifica la incorporación en comparación con un campo de comandos vacío de la GUI.
• Tareas enfocadas y de propósito único. Cuando una tarea tiene un inicio y un final claros, una aplicación dedicada es más fácil de aprender y más difícil de usar incorrectamente.
• Vistas generales analíticas. Las páginas de resumen, los mosaicos de KPI y la analítica integrada ofrecen a gerentes y usuarios clave una visión rápida que las transacciones clásicas nunca proporcionaron.
• Recorridos de usuario simplificados. Los procesos rediseñados en torno a menos pasos —gestión de situaciones, flujos de trabajo guiados— pueden reducir verdaderamente el esfuerzo, no solo repintar la pantalla.
• Nuevos usuarios. Las personas que se incorporan a la organización sin historial en SAP aprenden el modelo basado en tareas de Fiori mucho más rápido que los códigos de transacción.

Una estrategia de interfaz creíble reconoce ambas listas. El error es aplicar cualquiera de ellas de forma universal.

Cobertura funcional: ¿La aplicación Fiori realmente reemplaza la transacción GUI?

El error más común —y más costoso— en las implementaciones de Fiori es asumir que una aplicación con el mismo propósito que una transacción tiene la misma funcionalidad. Antes de retirar cualquier transacción GUI, los equipos deben validar la cobertura punto por punto:

• Campos requeridos: ¿Están disponibles en la aplicación todos los campos que el negocio utiliza realmente, incluidos los que se agregaron a lo largo de los años?
• Acciones requeridas: ¿Pueden los usuarios realizar todas las operaciones, no solo crear y visualizar, sino también anular, bloquear, liberar, reasignar y modificar en masa?
• Variantes: ¿Los usuarios dependen de variantes de selección o variantes de diseño que la aplicación no puede reproducir?
• Filtros: ¿Pueden los usuarios filtrar y ordenar como lo hacen hoy, especialmente en conjuntos de resultados grandes?
• Exportaciones: ¿Está disponible la exportación a hoja de cálculo, es completa y tiene un formato utilizable?
• Adjuntos: ¿Los adjuntos de documentos son visibles y los usuarios pueden agregarlos?
• Aprobaciones: ¿La aplicación se integra con el mismo flujo de trabajo, agentes y reglas de escalamiento?
• Excepciones: ¿Pueden los usuarios manejar los casos no ideales: entregas parciales, diferencias de precio, documentos bloqueados?
• Campos personalizados: ¿Aparecen los campos específicos del cliente y son editables cuando es necesario?
• Informes: ¿Los informes posteriores y las transacciones de seguimiento siguen conectándose de forma natural?
• Comportamiento de autorización: Fiori utiliza catálogos, grupos y servicios OData sobre los objetos de autorización clásicos: ¿el acceso efectivo coincide con el que tienen los usuarios hoy?
• Pasos del proceso circundantes: ¿Puede el usuario navegar al siguiente paso del proceso, o la aplicación termina en un punto muerto que obliga a volver a cambiar a GUI de todos modos?

Una aplicación Fiori que cubre el 85% de una transacción parece estar cerca. En la realidad operativa, el 15% faltante suele contener precisamente el manejo de excepciones con el que los usuarios experimentados tratan a diario. Si los usuarios deben abrir SAP GUI para terminar lo que la aplicación inició, la migración ha agregado un paso en lugar de eliminar uno.

Perfil de usuario: ¿usuario ocasional, usuario clave o usuario avanzado?

Las interfaces no se evalúan en abstracto; las evalúan personas con relaciones muy diferentes con el sistema.

Un usuario ocasional mide una interfaz según si puede completar la tarea sin ayuda. Un gerente la mide según la rapidez con la que puede actuar sobre lo que tiene pendiente, a menudo desde un teléfono entre reuniones. Un usuario clave necesita suficiente visibilidad para responder preguntas de su equipo y detectar problemas en el proceso. Un consultor o analista de soporte necesita navegar en profundidad por documentos, tablas y registros para diagnosticar problemas. Un usuario avanzado mide la interfaz en pulsaciones de teclas y segundos, porque su jornada está compuesta por miles de ambas cosas.

La implicación práctica: las decisiones sobre la interfaz tomadas por rol y tarea superarán a las decisiones tomadas por transacción. El mismo proceso de orden de compra puede ser Fiori para el solicitante, Fiori para el aprobador y GUI para el comprador que procesa cincuenta órdenes al día.

Frecuencia de las tareas y densidad de los datos

Dos dimensiones predicen el ajuste de una interfaz mejor que casi cualquier otra cosa: con qué frecuencia se realiza la tarea y cuántos datos implica.

La frecuencia cambia lo que significa "usable". Una tarea realizada una vez al mes puede tolerar —e incluso beneficiarse de— orientación, pasos adicionales de confirmación y pantallas explicativas. El usuario ha olvidado los detalles desde la última vez. Una tarea realizada cientos de veces a la semana no puede tolerar nada de eso. Cada paso guiado que ayuda al usuario mensual es fricción para el usuario diario.

La densidad cambia lo que significa "simple". Las grandes cuadrículas ALV en SAP GUI permiten a los usuarios revisar cientos de partidas, ordenar, subtotalizar, filtrar y editar directamente. Las pantallas de listas simplificadas que muestran menos columnas y paginan los resultados pueden convertir una revisión de dos minutos en un desplazamiento de quince minutos. Cuando el trabajo consiste fundamentalmente en recorrer muchos registros —compensar partidas abiertas, revisar resultados de MRP, conciliar diferencias de stock— una pantalla optimizada para la legibilidad de un solo registro va en contra de la tarea.

Ninguno de estos puntos es un argumento contra Fiori en general. Los informes de lista de Fiori con tablas inteligentes manejan volúmenes de datos considerables, y algunos escenarios son dramáticamente mejores en Fiori. El punto es que la frecuencia y la densidad deben medirse para la tarea real antes de decidir, no asumirse a partir de una demostración con diez registros de muestra.

Rendimiento y productividad

Las discusiones sobre el rendimiento en torno a Fiori suelen permanecer en el plano teórico hasta la puesta en marcha, y entonces se vuelven muy concretas. Los equipos deben evaluar de forma realista:

• Tiempo de carga del Launchpad, especialmente la primera carga del día y después de la invalidación de la caché.
• Número de roles y aplicaciones asignados a un usuario: los Launchpads muy cargados, con cientos de mosaicos, cargan más lentamente y son más difíciles de navegar.
• Comportamiento del navegador, incluidas las políticas corporativas del navegador, las extensiones y los límites de memoria en equipos cliente antiguos.
• Condiciones de red: Fiori genera más tráfico conversacional en la red que el protocolo optimizado de GUI, lo cual importa para plantas remotas, usuarios de VPN y sitios con poco ancho de banda.
• Rendimiento del backend y de los servicios OData, ya que una aplicación bien diseñada sobre una compuerta lenta sigue siendo una aplicación lenta.
• La brecha entre pruebas y producción: una aplicación probada con 50 documentos se comporta de manera diferente con 50.000.
• Velocidad percibida frente a disponibilidad técnica: un sistema puede estar “activo” y aun así sentirse lento, y los usuarios juzgan la sensación, no el panel de monitoreo.

El rendimiento merece atención porque no es solo una métrica de TI. Es una variable de adopción. Los usuarios que experimentan un Launchpad lento en su primera semana se forman una opinión que la capacitación no podrá deshacer, y encontrarán la forma de volver a GUI, oficialmente o no. Si la experiencia de Fiori no puede hacerse receptiva bajo condiciones reales para una tarea determinada, esa es una razón legítima para mantener la transacción de GUI hasta que pueda lograrse.

Personalización y procesos heredados

La mayoría de los entornos SAP con más de unos pocos años no son estándar. Incluyen user exits, BAdIs, pantallas personalizadas, campos Z, lógica de validación y transacciones Z completas construidas en torno a cómo funciona realmente el negocio. Esta base instalada cambia significativamente la ecuación de migración. Antes de mover un proceso personalizado a Fiori, los equipos deben evaluar:

• ¿El proceso sigue los supuestos estándar de SAP? Las aplicaciones Fiori están creadas para procesos estándar. Cuanto más se haya alejado un proceso del estándar, menos probable será que la aplicación encaje sin modificaciones.
• ¿La aplicación admite los tipos de documentos, campos, validaciones o pantallas personalizados en uso? Algunas extensiones se trasladan mediante la extensibilidad dentro de la aplicación o campos de usuario clave; la lógica de pantalla profundamente integrada normalmente no.
• ¿La transacción tiene mejoras locales de las que dependen los usuarios? Un botón personalizado que automatiza una corrección de cinco pasos puede ser invisible en la documentación, pero esencial en el trabajo diario.
• ¿Vale la pena el esfuerzo de reconstruir la experiencia? Recrear una transacción muy personalizada como una aplicación Fiori personalizada es desarrollo real: diseño, servicios OData, trabajo con UI5 o elementos Fiori, pruebas y mantenimiento continuo.
• ¿Mantener SAP GUI es simplemente más práctico para este caso? A veces la respuesta honesta es sí, al menos para el horizonte de planificación actual.

También existe una versión estratégica de esta pregunta: si un proceso está tan personalizado que ninguna aplicación estándar encaja, la decisión correcta a largo plazo puede ser rediseñar el proceso hacia el estándar en lugar de reconstruir la personalización en una nueva interfaz. Pero esa es una decisión de proceso que merece su propio proyecto, no un efecto secundario de una migración de interfaz de usuario.

La movilidad no siempre es el factor decisivo

"Fiori es móvil" es cierto, y es uno de los argumentos más sólidos para su adopción — para los escenarios que realmente son móviles. Confirmaciones de servicio en campo, tareas de almacén en dispositivos portátiles, aprobaciones en teléfonos, rondas de mantenimiento de planta: estos son casos reales y de alto valor en los que la movilidad cambia la forma en que se realiza el trabajo.

Pero una gran parte del trabajo en SAP es, y seguirá siendo, trabajo de escritorio. Un contador financiero cerrando el mes, un planificador de materiales revisando excepciones de MRP, un agente de atención al cliente con auriculares ingresando pedidos: estos usuarios trabajan sentados en escritorios con monitores grandes y teclados completos. Para ellos, "también funciona en un teléfono" no aporta ningún beneficio, y las decisiones de diseño mobile-first (objetivos táctiles más grandes, menos campos visibles, diseños verticales) pueden restar valor a la experiencia de escritorio.

La prueba es sencilla: ¿alguien realiza realmente esta tarea lejos de un escritorio, o lo haría si pudiera? Si la respuesta es sí, la movilidad es un argumento sólido a favor de Fiori. Si la respuesta es no, la decisión debería basarse en los otros criterios de este artículo — cobertura, densidad, rendimiento, perfil de usuario — con la movilidad ponderada en cero en lugar de asumirse como un beneficio.

Capacitación y gestión del cambio

Incluso cuando Fiori es claramente el destino correcto, la transición fracasa sin una gestión del cambio deliberada. Hay varias realidades que deben planificarse, no descubrirse:

No se debe obligar a los usuarios a pasar a Fiori sin comprender el nuevo recorrido. El cambio no es cosmético. Cambian la lógica de navegación, la terminología y la forma del trabajo.

Una transacción puede convertirse en varias aplicaciones. Lo que antes era una sola pantalla con pestañas — mostrar proveedor, modificar proveedor, ver partidas abiertas — ahora puede ser tres o cuatro mosaicos. Los usuarios deben saber que esto es intencional y dónde quedó cada parte.

Los usuarios necesitan un mapeo de lo antiguo a lo nuevo. "¿Qué mosaico reemplaza a VA02?" es la pregunta más común en un despliegue de Fiori. Un mapeo publicado de transacciones a aplicaciones, mantenido actualizado, evita miles de tickets de soporte.

Los usuarios clave necesitan una ruta de soporte clara. Cuando a una aplicación le falta una función o se comporta de forma inesperada, los usuarios clave necesitan saber si se trata de un error, una brecha de capacitación, una autorización faltante o una limitación conocida, y a quién consultar.

La capacitación debe explicar el proceso, no solo la pantalla. Mostrar a los usuarios dónde se movieron los botones genera cumplimiento. Explicar cómo fluye ahora el proceso de extremo a extremo — y por qué — genera adopción. Esto es especialmente cierto cuando el despliegue de Fiori coincide con cambios reales de proceso en S/4HANA, como suele ocurrir.

Una lista de verificación práctica para la toma de decisiones

Lista de verificación para decidir entre SAP GUI y SAP Fiori

Evalúa cada transacción o tarea importante con estas preguntas antes de decidir:

1. ¿Quién realiza esta tarea? ¿Usuario ocasional, gerente, usuario clave, soporte o usuario avanzado?
2. ¿Con qué frecuencia se realiza? ¿Mensualmente, a diario o cientos de veces por semana?
3. ¿La tarea es móvil o está basada en escritorio? ¿Alguien necesita realizarla lejos de un escritorio?
4. ¿La aplicación Fiori cubre toda la funcionalidad requerida? ¿Campos, acciones, variantes, filtros, exportaciones, archivos adjuntos, excepciones?
5. ¿Hay campos personalizados o mejoras? ¿Se trasladan a la aplicación?
6. ¿El usuario necesita una alta densidad de datos? ¿Grandes cuadrículas, procesamiento masivo, edición en el lugar?
7. ¿La aplicación Fiori es lo suficientemente rápida en condiciones reales? ¿Volúmenes de datos reales, red real, equipos cliente reales?
8. ¿El usuario depende de códigos de transacción o atajos de teclado? ¿Eliminarlos ralentizaría el trabajo?
9. ¿El proceso requiere varias aplicaciones relacionadas? ¿Una transacción se convertiría en un recorrido de múltiples mosaicos?
10. ¿Es esta una transición temporal o una experiencia objetivo a largo plazo? ¿Se espera una aplicación mejor en una versión futura?
11. ¿Qué capacitación y documentación necesitarán los usuarios? ¿Quién las producirá y mantendrá?
12. ¿Cuál es el costo de forzar la migración? En productividad, carga de soporte y confianza del usuario, frente al beneficio obtenido.

Si las respuestas apuntan claramente en una dirección, la decisión es fácil. Si entran en conflicto —una necesidad móvil pero cobertura incompleta, un usuario avanzado pero una aplicación analítica sólida—, el conflicto en sí mismo es el hallazgo: esa tarea puede necesitar ambas interfaces, o un rediseño, en lugar de una elección forzada.

Estrategia híbrida recomendada

Para la mayoría de las organizaciones, el objetivo realista y defendible no es usar solo GUI o solo Fiori. Es un enfoque híbrido deliberado:

• SAP Fiori para autoservicio, aprobaciones, escenarios móviles y de campo, analíticas y páginas de resumen, y tareas enfocadas realizadas por usuarios ocasionales: los escenarios en los que el diseño de Fiori realmente se ajusta al trabajo.
• SAP GUI para usuarios expertos que realizan trabajo operativo intensivo, tareas técnicas y administrativas, transacciones altamente personalizadas y procesos para los que aún no existe una aplicación Fiori adecuada.
• El Fiori Launchpad como punto de entrada común cuando corresponda, incluido el lanzamiento de transacciones GUI clásicas (mediante SAP GUI for HTML o mosaicos WebGUI integrados) junto con aplicaciones nativas, para que los usuarios tengan un único lugar desde donde empezar incluso cuando la tecnología subyacente sea diferente.
• Documentación interna que haga explícita la división. Los usuarios nunca deberían tener que adivinar qué interfaz usar para un proceso determinado. La ambigüedad es donde crecen los hábitos paralelos y el trabajo duplicado.

Una estrategia híbrida no es una concesión ni una señal de modernización incompleta. Es lo que significa estar “orientado al proceso” en la práctica. La composición de la combinación cambiará con el tiempo a medida que aumente la cobertura de Fiori, las aplicaciones maduren y los procesos se rediseñen; precisamente por eso, la estrategia debe documentarse y revisarse, no decidirse una sola vez y quedar congelada.

Qué deben documentar los equipos

La diferencia entre un panorama híbrido gestionado y uno accidental es la documentación. Los equipos deben mantener un catálogo interno de interfaces —un documento vivo, con un responsable— que incluya al menos:

• Proceso de negocio (p. ej., procesamiento de facturas de proveedores)
• Transacción de SAP GUI (p. ej., MIRO, FBL1N)
• Aplicación o mosaico de Fiori (nombre e ID de la aplicación, p. ej., "Crear factura de proveedor", F0859)
• Tipo de aplicación (SAPUI5 freestyle, Fiori elements, aplicación clásica en WebGUI, Web Dynpro)
• Usuarios / roles objetivo (quién se espera que use qué interfaz)
• Limitaciones conocidas (brechas funcionales frente a la transacción de GUI, con detalles específicos)
• Preparación para móviles (probado en qué dispositivos, para qué pasos)
• Notas de rendimiento (tiempos de carga reales, cuellos de botella conocidos, límites de volumen de datos)
• Material de capacitación (enlace a la guía, video o ayuda de trabajo para cada interfaz)
• Responsable (quién decide y quién responde preguntas)
• Decisión de migración: mantener GUI, pasar a Fiori, usar ambos o rediseñar el proceso

Este catálogo se amortiza rápidamente. Convierte "¿por qué seguimos usando GUI para esto?" de un debate recurrente en una decisión documentada con motivos declarados y una fecha de revisión. Proporciona a los equipos de capacitación una única fuente de verdad. Y hace que el movimiento eventual y gradual hacia Fiori sea medible en lugar de anecdótico.

Respuesta final

Mantenga SAP GUI cuando la tarea requiera velocidad, profundidad, alta densidad de datos, funcionalidad transaccional madura, control técnico o comportamiento personalizado que la aplicación Fiori disponible no admita bien. Migra a SAP Fiori cuando el trabajo se beneficie del acceso basado en roles, la interacción guiada, el acceso móvil, el autoservicio, la analítica o una experiencia de usuario simplificada, y la aplicación cubra realmente la tarea.

La mejor estrategia de interfaz de SAP no es solo GUI ni solo Fiori. Tiene en cuenta el proceso, los roles y se basa en cómo se realiza realmente el trabajo. Los equipos que evalúan cada tarea por sus propios méritos —perfil de usuario, frecuencia, densidad, cobertura, personalización, rendimiento y movilidad— terminan con una mayor adopción, menores costos de soporte y usuarios que confían en las interfaces que recibieron, porque esas interfaces fueron elegidas para ellos, no impuestas.

Preguntas frecuentes

¿SAP Fiori está reemplazando a SAP GUI?

SAP Fiori es la experiencia de usuario estratégica de SAP para S/4HANA, y cada vez más funcionalidades nuevas se entregan como aplicaciones Fiori. Sin embargo, SAP GUI sigue estando totalmente soportado y se utiliza ampliamente, y muchas transacciones no tienen un equivalente completo en Fiori. En la práctica, Fiori se está expandiendo en lugar de reemplazar instantáneamente a SAP GUI, y la mayoría de los clientes de S/4HANA utilizan ambos.

¿Las empresas todavía pueden usar SAP GUI con S/4HANA?

Sí. SAP GUI funciona con S/4HANA (ediciones locales y de nube privada), y miles de transacciones clásicas siguen estando disponibles. Algunas transacciones fueron eliminadas o reemplazadas en la simplificación de S/4HANA, pero SAP GUI en sí es un método de acceso soportado, y las transacciones clásicas incluso pueden iniciarse como mosaicos desde el Fiori Launchpad.

¿Cuándo es SAP GUI mejor que SAP Fiori?

SAP GUI tiende a ser mejor para el trabajo operativo de alto volumen, usuarios avanzados que dependen de códigos de transacción y atajos de teclado, tareas con cuadrículas de datos densas y muchos campos, transacciones muy personalizadas, actividades técnicas y administrativas, y cualquier proceso en el que la aplicación Fiori disponible no cubra toda la funcionalidad de la transacción clásica.

¿Cuándo es SAP Fiori mejor que SAP GUI?

SAP Fiori es mejor para escenarios móviles y de campo, aprobaciones de gerentes, tareas de autoservicio, usuarios ocasionales que no conocen códigos de transacción, acceso basado en roles, vistas generales analíticas y tareas enfocadas de propósito único. En estos escenarios, Fiori normalmente ofrece una finalización más rápida, menor esfuerzo de capacitación y mayor satisfacción del usuario que SAP GUI.

¿Por qué los usuarios avanzados suelen preferir SAP GUI?

Los usuarios avanzados optimizan el rendimiento: los códigos de transacción, las teclas de función, las sesiones múltiples, las variantes de diseño y las cuadrículas ALV densas les permiten procesar grandes volúmenes con un mínimo de clics. Las interfaces simplificadas y guiadas eliminan precisamente la densidad y el control mediante teclado que hacen que su trabajo sea rápido, por lo que una pantalla que ayuda a un usuario ocasional puede ralentizar a un experto.

¿Debería reemplazarse cada transacción de SAP GUI por una aplicación Fiori?

No. Cada transacción debe evaluarse según el perfil del usuario, la frecuencia de la tarea, la densidad de datos, la cobertura funcional, la personalización, el rendimiento y la necesidad móvil. Algunas transacciones se asignan claramente a mejores aplicaciones Fiori; otras no tienen un equivalente adecuado, o sirven a usuarios cuyo trabajo es más rápido en GUI. Forzar un reemplazo completo generalmente perjudica la productividad y la adopción.

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

Sí. Las transacciones clásicas pueden exponerse como mosaicos del Launchpad usando SAP GUI para HTML (WebGUI), de modo que los usuarios tengan un único punto de entrada incluso cuando la pantalla subyacente sea una transacción clásica. Esta es una técnica común en estrategias híbridas, aunque los equipos deberían verificar que la transacción específica funcione bien en WebGUI antes de depender de ella.

¿Cómo deberían decidir los equipos entre SAP GUI y SAP Fiori?

Evalúe cada tarea, no la tecnología: identifique quién la realiza y con qué frecuencia, si es de escritorio o móvil, si la aplicación Fiori cubre todos los campos, acciones y excepciones requeridos, si las personalizaciones se mantienen, y si el rendimiento se sostiene con volúmenes de datos y condiciones de red reales. Documente la decisión por proceso y revísela a medida que mejore la cobertura de Fiori.

¿Es aceptable una estrategia híbrida de SAP GUI y Fiori?

Sí; para la mayoría de las organizaciones es el enfoque recomendado, no un compromiso. Un híbrido bien gestionado utiliza Fiori para autoservicio, aprobaciones, movilidad y analítica, mantiene SAP GUI para trabajo experto, denso, técnico o personalizado, y documenta claramente qué interfaz se aplica a cada proceso. La combinación evoluciona entonces a medida que las aplicaciones maduran.

¿Qué debería documentarse antes de trasladar usuarios de SAP GUI a Fiori?

Los equipos deberían mantener un catálogo que asigne cada proceso de negocio a su transacción GUI y aplicación Fiori, incluyendo el tipo de aplicación, los usuarios objetivo, las brechas funcionales conocidas, la preparación para móviles, notas de rendimiento, material de capacitación, un responsable y la decisión de migración (mantener GUI, pasar a Fiori, usar ambos o rediseñar). Este mapeo evita la sobrecarga de soporte y hace que la transición sea medible.