2.1 Neue Benutzererfahrung

Wenn wir die klassische Benutzeroberfläche SAP GUI betrachten, stellen wir fest, dass die Bildschirminhalte sehr komplex sind. Denn anfangs wurden Anwendungen mit Blick auf den Geschäftsnutzen und nicht nach den Bedürfnissen des Anwenders konzipiert. Zudem war es häufig der Wunsch des Programmierers, so viele Funktionen wie möglich in einem einzigen Bildschirm – einem sogenannten dynamischen Programmbild (Dynpro) – unterzubringen.

Fiori spricht auch Benutzergruppen an, die eine SAP-Anwendung eher selten und zudem ausschließlich auf mobilen Endgeräten ausführen. In der Folge etablierte sich neben den Experten, die bereits viele Jahre mit dem GUI arbeiteten, und den Entwicklern, die die SAP-Anwendung eher Backend-orientiert nutzten, die Gruppe der Gelegenheitsnutzer. Diese Gruppe möchte schnell, einfach, intuitiv und am liebsten browserbasiert nur wenige Funktionen im SAP-System ausführen. Abbildung 2.1 stellt die drei unterschiedlichen Nutzertypen gegenüber.

Abbildung 2.1: Unterschiedliche Nutzertypen

Die GUI-Anwendung bietet anhand von Transaktionen einen klar funktionsbasierten, dem Geschäftsnutzen entsprechenden Einstieg in die SAP-Anwendung – und dies für mehrere Rollen ohne Rücksicht auf Nutzertypen.

Mit der Einführung von Fiori wurden diese Transaktionen, dem Erfahrungshorizont des jeweiligen Nutzertyps folgend, in mehrere rollenbasierte Applikationen (Apps) zerlegt. Auf diese Weise ist es möglich, die Pflege eines Kundenauftrags statt mit nur einer Transaktion in Fiori mit mindestens drei unterschiedlichen Apps – je nach Rolle und Nutzertyp – zu erledigen. Darüber hinaus sorgen Fiori-Designvorgaben für eine einheitliche und konsistente Optik in jeder SAP-Anwendung.

Das SAP Fiori Launchpad ist nun der zentrale, rollenbasierte Einstiegspunkt für den Zugriff auf alle Apps, auch Kacheln genannt, sowie auf Links und auf die Suchfunktion – die sogenannte Enterprise Search. Das Designkonzept wird mithilfe des SAPUI5-Frameworks umgesetzt und ist kompatibel mit sämtlichen S/4HANA-Anwendungen.

Bei den Fiori-Apps unterscheidet man drei grundlegende Typen, wie in Abbildung 2.2 dargestellt:

• transaktionale Apps
• analytische Apps
• Fact Sheet/Infoblatt-Apps

Abbildung 2.2: Arten von Fiori-Apps

Eine transaktionale App ermöglicht es dem Anwender, Prozesse in einer vereinfachten GUI-Ansicht durchzuführen. Jede Aktivität, die mit der Erstellung, Änderung oder Löschung von Daten einhergeht, lässt sich als transaktionale App umsetzen. Das Konzept der zerlegten Transaktion ist hier nicht umgesetzt, da die App der klassischen GUI-Transaktion eins zu eins nachempfunden und lediglich webfähig gestaltet ist. Die Frontend-Komponenten haben über eine vertrauenswürdige Remote-Function-Call(RFC)-Verbindung Zugriff auf den Advanced-Business-Application-Programming(ABAP)-Backend-Server, auf dem sich die Geschäftslogik befindet.

Die analytische App gewährt dem Nutzer Einblick in bestimmte Kennzahlen. Sie bietet Echtzeitinformationen aus großen Datenmengen in einer komprimierten Ansicht, meist grafisch aufbereitet. Die Wiedergabe der Informationen in Echtzeit garantiert eine schnelle und flexible Reaktion auf veränderte Marktbedingungen. Inhaltlichen Mehrwert erhalten diese Apps durch die Darstellung des Business Content – geclustert nach vordefinierbaren Kennzahlen (Key Performance Indicators, KPIs). Eine analytische App kann nur in Kombination mit einer SAP-HANA-Datenbank und einem SAP NetWeaver Application Server (ABAP-Stack) verwendet werden.

Die Fact Sheet App, Infoblatt-App genannt, stellt die benötigten Informationen auf einem einzigen Bildschirmbild zur Verfügung. Mit entsprechenden Navigationsknöpfen bewegt sich der Anwender auf dieser Seite von Punkt zu Punkt. Das Konzept orientiert sich an den sogenannten Onepager-Websites, die Oberfläche ist intuitiv gestaltet. Einzelne Infoblätter innerhalb der Applikationen besitzen Verknüpfungen zu weiteren Infoblättern und ermöglichen damit eine schnelle, unkomplizierte Navigation von Infoblatt zu Infoblatt. Infoblatt-Applikationen benötigen ebenfalls eine SAP-HANA-Datenbank im Backend und einen SAP NetWeaver Application Server (ABAP-Stack).