SAP Fiori vs SAP GUI: Qué cambia realmente para los usuarios
Para muchos usuarios de SAP, pasar de SAP GUI a SAP Fiori se siente como algo más que un rediseño. Cambia la forma en que las personas encuentran trabajo, abren aplicaciones y completan tareas.
Los usuarios experimentados de SAP GUI dependen de códigos de transacción, pantallas densas, hábitos de teclado, diseños guardados y años de memoria muscular. SAP Fiori organiza la experiencia de manera diferente: en torno al Fiori Launchpad, aplicaciones basadas en roles, mosaicos y una interfaz web moderna.
Para nuevos usuarios, escenarios móviles, aprobaciones y tareas de autoservicio, ese cambio suele ser una mejora. También crea fricción en casos reales: un usuario avanzado pierde velocidad, una transacción familiar se divide en varias aplicaciones, o una aplicación de Fiori simplemente no alcanza la profundidad funcional de la transacción de GUI que pretende reemplazar.
Así que la pregunta útil no es "interfaz antigua versus interfaz nueva". Es qué experiencia se adapta al usuario, la tarea, el dispositivo y el proceso de negocio.
SAP Fiori y SAP GUI en términos sencillos
SAP GUI es la interfaz con la que la mayoría de los usuarios de SAP han trabajado durante años. Está orientada a transacciones y es densa, y resulta eficiente para quienes ya saben adónde ir. Navegan mediante códigos de transacción, menús, accesos directos, variantes de diseño y pantallas que muestran mucha información a la vez.
SAP Fiori parte de una premisa diferente: el rol del usuario y la tarea en cuestión. Las personas acceden a las aplicaciones de Fiori a través del Launchpad, donde los mosaicos se organizan por roles, catálogos, espacios y permisos. El efecto práctico es un punto de entrada más enfocado — aprobar algo, crear una solicitud, consultar un KPI, revisar una lista — en lugar de “abrir esta transacción y averiguar el resto”.
Aquí es donde las reacciones divergen. Un empleado nuevo puede encontrar un Launchpad basado en roles mucho más fácil que aprender códigos de transacción. Un usuario avanzado puede encontrar la misma experiencia más lenta si elimina los accesos directos, la densidad y las opciones avanzadas que usa a diario. Y una única transacción de GUI no siempre se corresponde con una única aplicación de Fiori: a veces se corresponde con varias, a veces con un recorrido rediseñado y a veces con nada equivalente.
Entonces, la diferencia no es principalmente visual. SAP GUI está centrado en transacciones. SAP Fiori está centrado en roles y tareas. Ambos son útiles, pero se adaptan a usuarios diferentes y a distintos tipos de trabajo.
Lo que realmente cambia para los usuarios
El cambio más visible es cómo comienza el trabajo. En SAP GUI, escribes un código de transacción, llegas a la pantalla, aplicas tus filtros o variante, y continúas. Para los expertos, eso es rapidísimo porque el patrón está memorizado. En Fiori, empiezas desde el Launchpad y eliges entre las aplicaciones asignadas a tu rol: seleccionas una tarea en lugar de recordar dónde se encuentra.
Ese único cambio impulsa la mayoría de los demás:
El acceso se vuelve basado en roles. El Launchpad muestra lo que tu rol está destinado a hacer, lo que reduce el ruido y ayuda a los usuarios ocasionales. La contrapartida: no verás aplicaciones que no tengas asignadas, incluso cuando existan en el sistema.
El trabajo se vuelve orientado a tareas. Las aplicaciones Fiori suelen enfocarse en una actividad: aprobar una orden de compra, revisar un pedido de venta, crear una solicitud. Eso es excelente para el trabajo guiado y frustrante cuando antes gestionabas un flujo más amplio dentro de una sola transacción.
Las pantallas se vuelven más ligeras. GUI reúne muchos campos, pestañas y filtros en una sola pantalla, que es exactamente por eso que a los usuarios avanzados les gusta. Fiori reduce la complejidad visual, lo que ayuda a la comprensión, pero perjudica a quienes necesitan comparar muchos campos rápidamente.
La navegación cambia de forma. GUI recompensa los códigos de transacción, los atajos de teclado y las secuencias de pantallas conocidas. Fiori se apoya en la búsqueda del Launchpad, los informes de lista, las páginas de objeto y los enlaces entre objetos relacionados: más intuitivo para los recién llegados, menos directo para los expertos.
Se abren más dispositivos. GUI fue creado para el escritorio. Fiori fue creado para la web adaptable, lo que lo hace mucho más práctico en tabletas y teléfonos, para aprobaciones en movimiento, y para tareas de campo y de autoservicio.
En otras palabras, la transición redefine cómo los usuarios descubren el trabajo, cuánto ven a la vez y cuán estrechamente está vinculada la interfaz a los roles. Por eso el mismo cambio encanta a un grupo e irrita a otro.
Por qué algunos usuarios todavía prefieren SAP GUI
Muchas quejas sobre Fiori no son estéticas. Las personas comparan dos formas de trabajar, no dos diseños.
Para los usuarios experimentados, GUI se siente más rápido porque los códigos de transacción, las secuencias de pantallas, los atajos y las variantes ya los tienen interiorizados. No quieren una experiencia guiada: quieren velocidad y control. Esto es más evidente en usuarios avanzados, usuarios clave, consultores y personal técnico cuyo trabajo implica transacciones de alto volumen, verificaciones detalladas, resolución de problemas o configuración en muchos campos. Una pantalla GUI densa puede superar a una aplicación simplificada que oculta información detrás de clics adicionales.
La familiaridad refuerza esto. Alguien que ha usado la misma transacción durante años sabe qué campos importan, qué advertencias ignorar y qué variante ofrece la mejor vista. Reemplazar eso con una nueva aplicación reduce la productividad si la aplicación no coincide con el flujo de trabajo real.
Luego está la profundidad funcional. Fiori no siempre es un reemplazo uno a uno. Algunas aplicaciones son excelentes para tareas específicas, aprobaciones y trabajo móvil; algunas transacciones heredadas cubren escenarios operativos más amplios que la aplicación equivalente solo aborda parcialmente. Cuando una aplicación cubre solo parte de lo que los usuarios necesitan, lo interpretan como un paso atrás; y a veces la interfaz “más simple” en realidad es más lenta, porque eliminó precisamente los elementos que hacían eficiente el trabajo experto.
Por qué los nuevos usuarios suelen preferir SAP Fiori
Los recién llegados evalúan Fiori con criterios diferentes. Si no conoces los códigos de transacción ni la lógica de pantallas de SAP, la GUI resulta intimidante: ¿por dónde empiezas, qué transacción usas, qué campos son obligatorios?
Fiori elimina gran parte de esa fricción al organizar el trabajo en torno a aplicaciones, roles y tareas. En lugar de pedirte que recuerdes un código, el Launchpad presenta un conjunto seleccionado: aprobaciones, solicitudes, informes, acciones de autoservicio. Eso es especialmente valioso para los usuarios ocasionales. Alguien que solo actualiza datos personales, envía una solicitud o revisa un estado no necesita toda la profundidad de una transacción tradicional; una aplicación enfocada hace que la tarea sea fácil de encontrar y completar.
La movilidad también importa aquí. Gerentes que aprueban mientras viajan, empleados en aplicaciones de autoservicio, equipos de campo que actualizan registros desde una tableta: estas tareas funcionan mejor en una interfaz adaptable que en una pantalla limitada al escritorio. Para estos usuarios, el verdadero beneficio no es que Fiori se vea moderno; es que se ajusta estrechamente al trabajo: abrir la aplicación correcta, ver lo relevante, decidir y seguir adelante.
Elegir entre ellos, escenario por escenario
La decisión suele depender de la naturaleza del trabajo. Las tareas densas, repetitivas, técnicas o impulsadas por expertos siguen favoreciendo a GUI. Las tareas enfocadas, basadas en roles, móviles, analíticas o de autoservicio favorecen a Fiori.
| Escenario | Mejor opción |
|---|---|
| Trabajo operativo de alto volumen | SAP GUI |
| Usuarios expertos que dependen de códigos T y accesos directos | SAP GUI |
| Pantallas densas con muchos campos, filtros y variantes | SAP GUI |
| Administración técnica o configuración profunda | SAP GUI / herramientas especializadas |
| Transacciones heredadas sin cobertura completa de Fiori | SAP GUI o SAP GUI para HTML |
| Resolución frecuente de problemas por parte de usuarios clave o consultores | SAP GUI |
| Tareas de aprobación | SAP Fiori |
| Autoservicio de empleados y gerentes | SAP Fiori |
| Trabajo móvil o de campo | SAP Fiori |
| Monitoreo de KPI y visibilidad de excepciones | SAP Fiori |
| Tareas de negocio guiadas y uso ocasional | SAP Fiori |
| Flujos de trabajo de aprobación que involucran múltiples roles, reglas y excepciones | SAP Fiori + capa BPM* |
| Gestión de solicitudes con plazos, escalaciones y trazabilidad | SAP Fiori + capa BPM* |
| Procesos de extremo a extremo que van más allá de una sola transacción o aplicación de SAP | SAP Fiori + capa BPM* |
* En escenarios como estos, SAP Fiori puede proporcionar la experiencia orientada al usuario, mientras que una capa BPM puede gestionar la lógica del flujo de trabajo, las aprobaciones, los plazos, las escalaciones, las excepciones y la visibilidad operativa.
Nada de esto argumenta en contra de la adopción de Fiori. Argumenta en contra de tratar a Fiori como un reemplazo automático para cada escenario de GUI. Para algunos roles, la modernización más inteligente mantiene GUI donde sigue siendo eficiente y utiliza Fiori donde el acceso basado en roles, guiado o móvil crea un valor claro.
¿Está SAP Fiori reemplazando a SAP GUI?
SAP Fiori es la experiencia de usuario estratégica para el SAP moderno, especialmente S/4HANA. Eso no significa que GUI desaparezca de todas las empresas, roles y procesos en el mismo plazo.
Lo que Fiori realmente cambia es la dirección predeterminada del diseño de UX. Los nuevos escenarios se construyen cada vez más en torno a aplicaciones basadas en roles, acceso mediante Launchpad, tareas guiadas e interfaces responsivas. Pero muchas organizaciones todavía dependen de GUI para trabajo experto, transacciones heredadas, configuración y operaciones de alto volumen.
"Reemplazo" es una palabra engañosa porque la realidad es desigual. A veces, una aplicación Fiori reemplaza una transacción de forma clara. A veces cubre solo una parte de ella. A veces, la transacción GUI simplemente se expone a través del Launchpad, lo que brinda a los usuarios un punto de entrada central sin rediseñar la experiencia subyacente. Vale la pena saber esto: la SAP Fiori Apps Reference Library no solo cataloga aplicaciones Fiori. También ayuda a planificar aplicaciones clásicas de SAP GUI y Web Dynpro para su uso en el Launchpad, y la propia documentación de SAP señala que puedes comprobar si una transacción GUI puede ejecutarse en el Fiori Launchpad buscando su código de transacción en esa biblioteca.
La mejor pregunta no es si Fiori reemplaza a GUI. Es si la experiencia Fiori respalda el trabajo real tan bien como —o mejor que— la transacción que está reemplazando. Para responder a eso, valida el caso de uso real con las personas que hacen el trabajo: ¿la aplicación cubre los campos, filtros, variantes, acciones, excepciones, autorizaciones e informes de los que dependen? Y considera el perfil del usuario, porque un solicitante ocasional y un usuario avanzado esperan cosas completamente diferentes.
Para la mayoría de las empresas, el futuro realista es híbrido. Fiori se convierte en el punto de entrada preferido para usuarios de negocio, autoservicio, tareas móviles, aprobaciones y analítica. GUI sigue atendiendo a los usuarios y escenarios donde la densidad, la velocidad, la profundidad o el control técnico aún importan. Una transición exitosa no obliga a todos a usar una sola interfaz: asigna la experiencia adecuada a cada rol, tarea y proceso.
El problema oculto: una aplicación no es todo el proceso
Un error común en los proyectos de Fiori es asumir que una mejor aplicación produce automáticamente un mejor proceso.
Una aplicación puede mejorar la forma en que alguien realiza una tarea: facilitar una aprobación, simplificar una solicitud, mostrar un KPI. Pero sigue siendo una parte de un proceso más amplio que también incluye quién inicia el trabajo, qué datos se requieren, quién los valida, qué reglas aplican, qué sucede cuando falta información, quién aprueba, qué plazos existen, cómo se gestionan las excepciones y cómo se monitorea el resultado.
Por eso, un usuario puede tener una buena experiencia dentro de una aplicación y aun así enfrentarse a un proceso deficiente. Una aplicación de aprobación puede ser agradable de usar mientras el flujo de aprobación sigue siendo poco claro. Una aplicación de solicitud puede verse moderna mientras nadie sabe qué sucede después del envío. Un mosaico de KPI puede señalar una excepción para la que la organización no tiene ningún procedimiento de resolución.
Por lo tanto, evalúa las aplicaciones en función del proceso de extremo a extremo, no solo de la pantalla:
| Pregunta | Por qué importa |
|---|---|
| ¿Qué proceso de negocio admite esta aplicación? | Mantiene la selección de aplicaciones conectada con el trabajo real. |
| ¿Qué rol la utiliza y en qué punto del proceso? | Aclara responsabilidades y traspasos. |
| ¿Qué sucede antes y después de la tarea del usuario? | Evita recorridos fragmentados. |
| ¿Qué excepciones son comunes? | Muestra si la aplicación maneja la variación operativa real. |
| ¿Qué necesita el usuario para decidir o actuar? | Evita que las pantallas demasiado simplificadas eliminen contexto crítico. |
| ¿Cómo sabrán los usuarios en qué estado se encuentra el proceso? | Conecta la ejecución con la visibilidad y la responsabilidad. |
Esto es especialmente importante al reemplazar una transacción GUI. La transacción puede haber admitido un flujo amplio, mientras que la aplicación admite una tarea más limitada: adecuado cuando el objetivo es simplificar el trabajo para un rol, arriesgado cuando nadie mapea el proceso completo y cómo se conectan las piezas. Una aplicación moderna ayuda a un usuario a finalizar una tarea; un proceso bien diseñado ayuda a la organización a coordinar el trabajo entre roles, sistemas, reglas y plazos.
Una lista de verificación antes de reemplazar GUI por Fiori
No bases la decisión en si existe una aplicación Fiori; básala en si la aplicación admite suficientemente bien al usuario, la tarea y el proceso.
| Pregunta | Qué verificar |
|---|---|
| ¿La aplicación cubre el trabajo requerido? | Los campos, acciones, filtros, variantes, informes y excepciones de los que dependen los usuarios hoy. |
| ¿Quién usa la transacción actualmente? | Separa usuarios ocasionales, usuarios clave, consultores, usuarios técnicos y usuarios avanzados de alto volumen. |
| ¿Con qué frecuencia se realiza la tarea? | Las tareas ocasionales se benefician de la orientación; las tareas repetitivas de expertos necesitan velocidad y densidad. |
| ¿Cuánta información se necesita a la vez? | Si los usuarios comparan muchos campos, registros o excepciones, una aplicación simplificada puede quedarse corta. |
| ¿La tarea forma parte de un proceso más amplio? | Comprende qué ocurre antes y después de la aplicación. |
| ¿Existen rutas de excepción comunes? | Revisa el retrabajo, los datos faltantes, el rechazo, la escalación y los flujos alternativos. |
| ¿El diseño de roles coincide con el trabajo real? | Los usuarios deben ver las aplicaciones que necesitan sin un Launchpad lleno de mosaicos irrelevantes. |
| ¿Los usuarios seguirán necesitando GUI? | Decide entre reemplazo completo, reemplazo parcial o coexistencia. |
| ¿Se ha probado el rendimiento con datos reales? | Una aplicación con buen aspecto fracasa en la adopción si las cargas, los filtros o los servicios backend son lentos. |
| ¿Hay documentación y capacitación? | Los usuarios necesitan entender cómo encaja la aplicación en su proceso, no solo qué mosaico abrir. |
Aplica esto con usuarios reales, no solo durante la configuración técnica. Los usuarios clave sacan a la luz los detalles que son fáciles de pasar por alto: dependencias ocultas, variantes de diseño, verificaciones manuales, exportaciones a hojas de cálculo, rutinas de excepción. Y compara escenarios antes de decidir: una aplicación puede ser perfecta para un gerente que aprueba una solicitud, pero insuficiente para un especialista que procesa docenas de casos por hora. La misma organización puede necesitar legítimamente Fiori para un rol y GUI para otro.
Conclusión: diferentes problemas, diferentes herramientas
SAP Fiori y SAP GUI no son “moderno versus antiguo”. Resuelven diferentes problemas de experiencia de usuario.
Fiori es más sólido cuando los usuarios necesitan trabajo basado en roles, guiado, móvil, analítico o de autoservicio. Ayuda a las personas a encontrar tareas relevantes, elimina la necesidad de memorizar códigos de transacción y ofrece a las actividades de negocio un punto de entrada enfocado.
GUI sigue siendo valioso cuando los usuarios necesitan velocidad, densidad, familiaridad y un control operativo profundo. Para usuarios avanzados, consultores, personal técnico y roles de alto volumen, la experiencia tradicional todavía puede superar a una aplicación simplificada que oculta información o añade navegación.
En entornos reales, la respuesta rara vez es un reemplazo limpio. Algunos roles prosperan con Fiori como su principal punto de entrada; otros aún necesitan GUI para trabajo experto; algunos escenarios requieren un recorrido de Fiori rediseñado en lugar de una migración uno a uno; algunos procesos necesitan ambos, según quién participe.
La lección es sencilla: la adopción de Fiori no es una migración cosmética de transacciones a mosaicos. Es una decisión de diseño centrada en el usuario y en el proceso. Cuando la aplicación, el rol, el dispositivo, los datos y el proceso están alineados, Fiori hace que el trabajo en SAP sea más accesible y enfocado. Cuando no lo están, los usuarios pierden velocidad, visibilidad o profundidad. Los equipos de SAP más sólidos no solo preguntan: “¿Podemos reemplazar esta transacción con Fiori?”. Preguntan: “¿Qué experiencia ayuda a este usuario a hacer mejor este trabajo?”
Preguntas frecuentes
¿Se pueden usar SAP Fiori y SAP GUI juntos?
Sí. Muchos entornos SAP usan SAP Fiori y SAP GUI juntos.
SAP Fiori puede convertirse en el principal punto de entrada para aplicaciones basadas en roles, aprobaciones, autoservicio, paneles, tareas móviles y actividades de negocio guiadas. SAP GUI puede seguir estando disponible para transacciones expertas, trabajo técnico, configuración, resolución de problemas o escenarios heredados en los que los usuarios aún necesitan velocidad y profundidad funcional.
Este enfoque híbrido suele ser más realista que intentar reemplazar todas las transacciones de SAP GUI de una sola vez.
¿Una baldosa de Fiori es siempre una aplicación nativa de SAP Fiori?
No. Una baldosa en SAP Fiori Launchpad es un punto de entrada, no una garantía de que la aplicación subyacente sea una aplicación nativa de SAP Fiori.
Según la configuración, una baldosa puede abrir una aplicación nativa de Fiori, una transacción de SAP GUI a través del navegador, una aplicación Web Dynpro, una URL externa u otro tipo de aplicación configurada.
Esta es una de las razones por las que los usuarios pueden ver experiencias muy diferentes aunque sigan accediendo a todo desde el Launchpad.
¿Por qué SAP Fiori a veces parece más fragmentado que SAP GUI?
Las transacciones de SAP GUI suelen ser amplias y centradas en la transacción. Una sola transacción puede incluir acciones, campos, pestañas e informes usados por diferentes roles.
SAP Fiori suele seguir un modelo más basado en roles y orientado a tareas. En lugar de exponer una transacción amplia a todos, la experiencia puede dividirse en varias aplicaciones diseñadas para roles o actividades específicas.
Esto puede mejorar la claridad para los usuarios ocasionales, pero puede parecer fragmentado para los usuarios avanzados si el recorrido de extremo a extremo no está bien diseñado.
¿Qué deberían probar los equipos antes de mover a los usuarios de SAP GUI a Fiori?
Los equipos deberían probar escenarios de trabajo reales, no solo si la aplicación de Fiori existe.
Deberían verificar si la aplicación admite los campos, acciones, filtros, variantes, informes, excepciones, autorizaciones y expectativas de rendimiento en las que los usuarios confían hoy. También deberían probar el recorrido completo con usuarios clave y usuarios avanzados, porque pequeños detalles faltantes pueden tener un gran impacto en la productividad.
La mejor prueba no es...
¿Puede abrirse la aplicación?
... sino ...
¿Puede el usuario completar el trabajo de forma eficiente y correcta?
¿SAP Fiori reduce la necesidad de formación de usuarios?
No completamente.
SAP Fiori puede hacer que algunas tareas sean más fáciles de entender, especialmente para usuarios ocasionales, gerentes, aprobadores y escenarios de autoservicio. Pero los usuarios aún necesitan saber qué aplicaciones usar, cómo está organizado el Launchpad, qué permite su rol, qué cambió respecto a SAP GUI y cómo encaja cada aplicación en el proceso de negocio más amplio.
Una interfaz moderna puede reducir la fricción, pero no elimina la necesidad de incorporación, documentación y orientación de procesos.
¿Por qué algunos usuarios pierden visibilidad después de pasar a SAP Fiori?
SAP Fiori está basado en roles, por lo que los usuarios normalmente solo ven las aplicaciones asignadas a su rol. Esto mejora el enfoque y la seguridad, pero también puede reducir la capacidad de descubrimiento si los roles son demasiado estrechos o si los usuarios no saben qué aplicaciones existen.
Una buena gobernanza ayuda a evitar este problema. Los equipos deberían mantener definiciones claras de roles, catálogos internos de aplicaciones, documentación, materiales de formación y procesos de solicitud de acceso para que los usuarios puedan entender no solo a qué pueden acceder, sino también qué existe y por qué.
