Fiori-Fragen verständlich erklärt – nicht nur für Einsteiger

Wir möchten mit einigen falschen Vorstellungen in diesem aktualisierten Blog-Beitrag (Erstveröffentlichung 18.12.2014) aufräumen und die Gelegenheit nutzen, SAP Fiori möglichst verständlich und ohne umfassendes Spezialwissen vorauszusetzen in Form eines Fragen-Antwort-Dialogs zu erklären.

Inhaltsverzeichnis

• Was ist Fiori?
• Die Motivation seitens SAP, eine neue UI-Technologie einzuführen
• Die wichtigsten Grundsätze bei der Entwicklung von Apps mit einer guten UX
• Fiori Apps sind primär für meine mobilen Geräte gedacht
• Kosten
• Was der Mitarbeiter von Fiori sieht
• Für welche Funktionalität und Bereiche eignen sich die Apps?
• Anpassungsmöglichkeiten von Fiori Apps
• Müssen bereits bestehende Prozesse erneut in der App abgebildet werden?
• Kompatibilität zu bestehenden Systemen
• Aufwand der Umstellung
• Wie starte ich mit SAP Fiori?

Irrtümliche Aussagen zu SAP Fiori

Uns sind in den vergangenen Jahren in Gesprächen mit Kunden und Interessenten viele Aussagen zum Thema SAP Fiori begegnet:

Fiori ist eine reine Mobility-Technologie!

Mit Fiori kann ich doch nur ein paar Genehmigungen auf dem Smartphone vornehmen!

Für Fiori muss ich meine komplette Architektur umbauen!

Für Fiori brauche ich HANA!

Für Fiori benötige ich das neueste System!

Mit Fiori muss ich komplett neue Technologien abseits des SAP-Standards erlernen!

Eine App ist wie eine Transaktion!

Sie zeugen von vielen Missverständnissen und fehlenden Informationen, die wir in diesem Beitrag auflösen möchten.

Hinweis: Die im Text enthaltenen Links verweisen auf die entsprechenden Einträge in unserem Mobility-Glossar auf der CONET-Website.

Was ist SAP Fiori?

SAP Fiori ist eine relativ neue, circa viereinhalb Jahre alte UI-Technologie von SAP (Veröffentlichung von ersten Apps auf der SAPPHIRE 2013). UI steht dabei für die englische Bezeichnung User Interface, deutsch: Benutzeroberfläche. Fiori basiert auf den inzwischen nicht nur im Consumer-Bereich erfolgreichen Grundsätzen der App- und Oberflächenentwicklung. Dabei ist es nicht nur ein UI-Produkt neben vielen anderen, sondern das Herzstück für die zukünftige SAP-UI-Strategie! Das heißt, über kurz oder lang werden sich alle SAP-Nutzeroberflächen an Fiori orientieren beziehungsweise auf Fiori basieren – dies ist für S/4HANA-Systeme heute schon Standard.

Das neue UI und die dahinter liegende Strategie kamen so gut an, dass die SAP für Fiori 1.0 mit einem Red Dot Design Award ausgezeichnet wurde und auch für das weiterentwickelte Fiori 2.0 diesen Award erneut gewinnen konnte. Technisch werden für die Entwicklung der Oberflächen das SAPUI5 Framework – ein „Baukasten“ für HTML5 und JavaScript – und zur Kommunikation das OData-Protokoll verwendet. Beides sind verbreitete Standards im Internet (mehr dazu siehe auch weiter unten). Fiori ist kein Programm, das Sie auf einem Client (also ihrem Rechner oder Ihrem mobilen Gerät) installieren müssen – es läuft in jedem Browser, der HTML5-kompatibel ist, also nahezu allen aktuellen Browsern.

Aber was ist die Motivation seitens SAP, eine neue UI-Technologie einzuführen?

Immer noch verwenden die meisten SAP-Nutzer das traditionelle SAP GUI – die Nutzeroberfläche, die in der grundlegenden Funktionalität im letzten Jahrtausend veröffentlicht worden ist. SAP hat erkannt, dass sich Programme und die Ansprüche der Benutzer an die Bedienung vor allem seit der starken Verbreitung von Smartphones und Apps gewandelt haben: Durch den Siegeszug von Apps, nicht nur im privaten Bereich, haben die Nutzer gesehen, wie einfach und intuitiv sich Software bedienen lassen kann.

Auch komplizierte Funktionen lassen sich übersichtlich und „schick“ darstellen, allerdings muss hierfür beim Design der Software einiges beachtet werden und in der Entwicklung ein Umdenken einsetzen. Durch eine einfache und intuitive Bedienung kann eine bessere UX (User Experience, auf deutsch so viel wie „Anwender-Erlebnis“) erreicht werden. Werfen Sie hierzu auch einen Blick auf unser Video: Schlau und Schön – Design Thinking für SAP-Oberflächen.

Die wichtigsten Grundsätze bei der Entwicklung von Apps mit einer guten UX sind:

• Einheitliche UI-Sprache über alle Apps (vergleichbar mit den Designsprachen bei den mobilen Betriebssystemen iOS oder Android, bei denen auch alle Masken und Ansichten ähnlich aussehen und ähnliche Bedienungsoptionen haben)
• Fokussierung auf eine Zielgruppe
• Beschränkung auf das Benötigte

Eine weitere Herausforderung für SAP (und alle großen Anbieter von Business-Software) ist die Tatsache, dass es heute nicht länger nur Desktop-PCs als einheitliche Hardware gibt. Durch Smartphones, Tablets, Phablets, Smartwatches und hybride Geräte wie das Microsoft Surface – eine Mischung aus Notebook und Tablet – hat sich die Welt der benutzten Endgeräte stark gewandelt und erweitert. Und wer kann jetzt schon sagen, mit welchen Geräten uns die Hardware-Hersteller in den kommenden Jahren noch überraschen werden?

Alle diese Geräte sind inzwischen auch in den Unternehmen auf dem Vormarsch – folglich benötigt auch SAP für seine Anwendungen eine UI-Technologie, die ohne große Anpassungen auf möglichst vielen oder sogar allen Geräten sauber läuft. Auf diese Entwicklungen, die immer schneller voranschreiten, antwortet SAP mit Fiori.

Jetzt habe ich es verstanden – Fiori Apps sind primär für meine mobilen Geräte gedacht!

Nein – oder eigentlich Jein! Durch Fiori entsteht eine neue UX, die auf allen Geräten nutzbar ist – also Device-unabhängig. Fiori kann und soll sowohl auf dem Desktop als auch auf mobilen Geräten verwendet werden. Das hat auch große Vorteile für die SAP-nutzenden Organisationen und die Nutzer selbst: Eine UI für alle Plattformen bedeutet keine gesonderten Kosten für die Pflege verschiedener Versionen und der Mitarbeiter muss beim Wechsel zwischen Geräten bei der Bedienung nicht umdenken.

Wichtig ist es allerdings, dabei zu beachten, dass Fiori als Anwendung im Browser läuft und nicht gesondert installiert wird. Fiori können Sie im organisationseigenen Netz nutzen, aber auch über das Internet für Ihre Mitarbeiter von überall verfügbar machen – die Sicherheit ist dabei dennoch gewährleistet, denn Fiori nutzt aktuelle Sicherheitsmechanismen und basiert auf SAP-Standard-Architekturen.

Das bedeutet einerseits weniger Installationsaufwand, heißt aber auch, dass zur Nutzung immer eine aktive Online-Verbindung notwendig ist. Eine Nutzung ist auch offline möglich, aber mit Mehraufwand durch die gegebenenfalls benötigte lokale Datenhaltung auf dem Endgerät verbunden. Hierbei können die SAP Mobile Platform oder die SAP Cloud Platform Mobile Services zur Unterstützung verwendet werden. Für iOS-Geräte hat die SAP eine Partnerschaft mit Apple aufgebaut. Darüber können native Fiori Apps umgesetzt werden, wobei hier auch eine einfachere Offline-Unterstützung möglich ist.

Kosten sind ein gutes Stichwort – hört sich ja nett an, aber was bringt mir das als Unternehmen – und die Lizenzen sind doch bestimmt wieder sehr teuer?

Die neue UX hat diverse Vorteile für SAP-einsetzende Organisationen, die sich schnell rechnen können:

• geringere Schulungskosten
• weniger Installations- und Support-Aufwand
• höhere Produktivität und Zufriedenheit der Mitarbeiter
• erweiterte und verbesserte Möglichkeiten, Prozesse effizient zu unterstützen

Nicht zu unterschätzen ist dabei gerade der dritte Punkt: Für alle Mitarbeiter, die mit Fiori arbeiten, wird der Umgang mit SAP deutlich einfacher, schneller und „angenehmer“ im Sinne von übersichtlicher und eingängiger. Dies ist auch in Bezug auf das Image des Arbeitgebers (Stichwort Employer Branding / Arbeitgebermarke) wertvoll. Denn die aktuellen und kommenden Generationen der Arbeitnehmer bestehen verstärkt aus so genannten „Digital Natives“, die im wahrsten Sinne mit mobilen Technologien aufwachsen, ebenso wie den „Digital Immigrants“, die aktiv und begeistert mobile Endgeräte und Apps nutzen.

Sie alle haben ein zunehmend anderes Verständnis von Informationstechnologie und eine andere Erwartungshaltung, was den einfachen Umgang und die Benutzerfreundlichkeit von Anwendungen angeht. Wenn Arbeitgeber interessant und attraktiv bleiben wollen, sind moderne UIs und eine gute UX wichtige Abgrenzungsfaktoren. Und abschließend noch eine sehr gute Nachricht zum Thema Lizenzen: Fiori ist kostenlos! Es entstehen keine zusätzlichen Lizenzkosten für die Nutzung der Funktionalität, allenfalls durch die zentrale Bereitstellung der Dienste können zusätzliche Kosten für Hardware und Einrichtung anfallen.

Hört sich so weit gut an – was sieht denn der Mitarbeiter eigentlich von Fiori?

Fiori besteht aus dem Launchpad und einer stetig wachsenden Sammlung von Apps. Das Launchpad ist der zentrale Zugriffspunkt auf alle Apps, zu vergleichen mit dem Startbildschirm auf dem Smartphone. Und wie dieser Startbildschirm lässt sich auch das Fiori Launchpad – ebenso wie die Startoberflächen beinahe aller aktuellen Benutzeroberflächen – passend zu den eigenen Anforderungen und Aufgaben personalisieren. Mit Fiori 2.0 wurde das Design erneuert und darüber hinaus um Funktionen wie die Me Area, das Notification Center (u.a. zum schnellen Aufrufen häufig genutzter Apps) und dem CoPilot – einem KI-Assistenten – erweitert.

Die Anwendungen (Apps) des Benutzers erscheinen im Launchpad als Kacheln, die sich wie gewünscht anordnen lassen. Weitere Apps kann der Nutzer einfach aus einem Katalog auswählen, starten und dem Launchpad hinzufügen. Je nach App beinhaltet die Kachel auch schon eine Vorschau, etwa über wichtige KPIs oder abzuarbeitende Aufgaben.

Eine App ist allerdings nicht mit einer SAP-Transaktion gleichzusetzen! Eine Fiori App ist für eine bestimmte Rolle und spezielle Aufgaben oder Einsatzszenarien konzipiert. Außerdem beinhaltet eine App nur die jeweiligen Daten und Funktionen, die für die bestimmte Rolle oder Aufgabe tatsächlich notwendig sind. Daher kann eine App je nach Einsatzszenario (Use Case) bestimmte Teilfunktionen einer oder mehrerer SAP-Transaktionen beinhalten. Auch aus diesem Grund sollten die Anwender bei der Entwicklung einer Fiori App von Beginn an während des gesamten Projekts mit eingebunden sein.

Werden in Apps Funktionen ähnlich denen einer bestehenden SAP-Transaktionen abgebildet, werden diese als „Transaktionale Apps“ bezeichnet. Darüber hinaus gibt es auch noch Fact Sheet Apps – vergleichbar mit Berichten zu einem speziellen Thema, allerdings deutlich aussagekräftiger aufbereitet – und als dritte Gattung die so genannten Analytical Apps zur Analyse komplizierterer Sachverhalte und Daten. Mit Fiori 2.0 – der aktuellen Version von Fiori – verschmelzen die App-Typen und es gibt weitere Design-Ansätze.

Die benötigten Systemvoraussetzungen lassen sich für Apps über die SAP Fiori Apps Reference Library herausfinden. Analytical Apps und Fact Sheets benötigen fast ausnahmslos (aktuell drei Apps in diesem Bereich ohne HANA) SAP-Systeme mit HANA als Datenbank. Da HANA zwar immer öfter, aber zurzeit noch keinesfalls flächendeckend im Einsatz ist, gehen wir in diesem Beitrag hauptsächlich auf transaktionale Apps ein, wobei viele der Aussagen auch für die anderen App-Gattungen korrekt sind.

Okay, es gibt Apps – aber für welche Funktionalität und für welche Bereiche?

Inzwischen hat SAP bereits fast 10.000 Fiori Apps (Stand 12/2017) veröffentlicht und die Zahl steigt kontinuierlich weiter stark an. Hierbei werden alle SAP-Bereiche und Systeme von ERP bis CRM abgedeckt – wobei Funktionen, die sehr häufig verwendet werden, naturgemäß im Fokus stehen. Vor allem für die S/4HANA-Systeme stehen sehr viele Fiori Apps zur Auswahl.

Allerdings sind nicht alle Apps für alle Systeme verfügbar. Ein Großteil der Apps ist nur für HANA und im speziellen für S/4HANA-Systeme verfügbar. Ein Großteil der Apps (> 8000) sind auch keine „echten“ Fiori Apps, sondern eigentlich WebDynpros bzw. SAPGUI-Transaktionen, die von der SAP mit einem speziell auf Fiori abgestimmten Theme ausgeliefert werden. Dies beinhaltet zum Beispiel die Fiori-Farbgebung und die Anordnung von Buttons wie „Speichern“ und „Abbrechen“ im Footer. Momentan werden diese auch in einem neuen Browser-Tab geöffnet (soll 2018 zum Teil angepasst werden).

Aber was mache ich, wenn die Apps für mich nicht passen oder noch gar nicht verfügbar sind?

SAP Fiori ist „offen“. Das heißt auch, dass es sehr einfach möglich ist, Apps anzupassen, zu erweitern und neue Apps zu implementieren (auch Release-sicher, also ohne die Befürchtung, dass bei zukünftigen Versionen etwaige Anpassungsaufwände erneut notwendig sind). Somit können Sie die Apps passgenau auf Ihr SAP-System und Ihre Prozesse ausrichten.

Eine weitere Möglichkeit zur Anpassung bestehender Transaktionen hin zu einer besseren UX (auch ohne HANA) wäre die Verwendung von Screen Personas zur Optimierung Ihrer UIs – mehr dazu finden Sie hier. Auch diese können auf dem Launchpad eingebunden werden, wobei eine Mischung beider Technologien möglich ist.

Dann muss ich meine bereits bestehenden Prozesse nochmals in einer App abbilden?

Nein. Um zu verstehen warum, und wie SAP Fiori aufgebaut ist, müssen wir an dieser Stelle allerdings doch etwas tiefer in die Technik einsteigen: Zu den zentralen Grundsätzen von Fiori gehören die Trennung von Nutzeroberfläche (UI) und Daten sowie die Verwendung von offen verfügbaren und im Internet erprobten Standards. Fiori ist wie schon gesagt eine UI-Technologie – es ist also im Grunde lediglich eine neue – allerdings deutlich verbesserte – „Ansicht“, um Daten anzuzeigen und zu bearbeiten. Unabhängig von diesem Frontend bleiben die Logik, die eigentliche Arbeit der Anwendung selbst, und die Berechtigungen weitestgehend im Backend.

Eine Fiori App besteht daher immer aus zwei Komponenten – dem UI und einem Datenservice. Das UI ist der „Rahmen“ für die Daten. Der Datenservice (SAP NetWeaver Gateway Service, oder kurz GW Service) versorgt die App mit den zugehörigen Daten und schreibt Informationen auch wieder in das Backend-System zurück. Durch diesen Aufbau wird die Trennung von UI und Daten erreicht.

Die UI wird in SAPUI5 entwickelt – einem Framework, also einem Entwicklungs- und Implementierungsbaukasten, der die grafischen Elemente und weitere benötigte Funktionen als fertig verwendbare Bausteine zur Verfügung stellt. SAPUI5 basiert auf HTML5, CSS3 und JavaScript, den gängigen Standards für die Entwicklung von Oberflächen im Internet. Der durch SAP für die einzelnen Apps bereitgestellte SAPUI5-Code kann beliebig bearbeitet werden. Je nach Umfang der Bearbeitung ist dies auch Release-sicher möglich, das heißt auch zukünftig können die SAP-Updates für diese Apps genutzt werden.

Zudem bietet SAP auch Templates an, die als Basisvorlagen zur Entwicklung eigener Apps dienen. Somit muss die Erstellung nicht bei null beginnen. Der Entwicklung sind dabei kaum Grenzen gesetzt, es lassen sich also auch Elemente einbauen, die nicht im Rahmen von SAPUI5 angeboten werden. Zur Implementierung stellt SAP das Browser-basierte Entwicklungswerkzeug Web IDE zur Unterstützung bereit – es kann aber auch ein beliebiges anderes Entwicklungs-Tool verwendet werden

Die Kommunikation zwischen dem Endgerät (Client), auf dem die Fiori App verwendet wird, und dem SAP Backend System leistet das so genannte SAP NetWeaver Gateway (SAP GW) über entsprechende Webservices. Der GW Service kann auf bestehenden CDS Views, FuBAs oder BAPIs basieren oder auch komplett selbst implementiert werden. Der GW Service gibt ausschließlich die für die Fiori App relevanten Elemente weiter, es werden also nur wirklich benötigte Daten übertragen. Der Aufruf erfolgt mit der Gateway Service Builder Transaktion „SEGW” Diese Transaktion bietet alle Funktionen zur Erstellung und Registrierung von GW Services. Die Transaktion „SE80“ kann in diesem Zusammenhang auch verwendet werden, jedoch mit geringerem Komfort. Wir befinden uns hier in also in der bekannten ABAP-Welt von SAP.

Der GW Service kommuniziert dabei über das Open Data Protocol (OData), ein von einem Konsortium diverser Firmen wie Microsoft, IBM und SAP entwickeltes HTTP-Protokoll, dessen zentraler Vorteil die Tatsache ist, dass es von unterschiedlichsten Frontend-Technologien und Betriebssystemen konsumiert und verarbeitet werden kann und sich so zu einem erprobten und weit verbreiteten Standard im Internet entwickelt hat. Der GW Service ist zudem nicht an die einzelne App gebunden, sondern kann auch für andere UI-Technologien verwendet werden und ist damit zukunftssicher.

Und das geht alles auf meinen bisherigen Systemen?

Auch hier lautet die klare Antwort: Jein. Damit SAP GW Services verwendet werden können, wird ein SAP NetWeaver Gateway System (inzwischen von der SAP auch Frontend Server genannt) benötigt. Dies kann entweder als Add-on auf bestehenden Systemen (als Embedded Installation) oder als Stand-Alone-Lösung (als Hub Installation) eingerichtet werden. Es können auch verschiedene Backend-Systeme an ein GW-System angeschlossen werden – Lizenzkosten werden dadurch nicht fällig, lediglich gegebenenfalls zusätzliche Hardware-Kosten.

Das GW-System hat wie oben beschrieben zum einen die Aufgabe, die GW Services in OData zu übersetzen. Außerdem liegen auf dem GW-System die UI-Ressourcen für die Fiori-Anwendung – vergleichbar mit einem Web-Server, auf dem die Designelemente einer Homepage liegen. Sollen zusätzliche Hardwarekosten für ein SAP NetWeaver Gateway System vermieden werden, bietet die SAP auch Cloud-Lösungen mit Anbindung bestehender On-Premise-Systeme an.

Oje – dann wird mein Admin gleich abwinken…noch ein unbekanntes System und bestimmt wieder ganz viel Neues?

Kein Grund zur Panik – das GW-System ist ein standardisiertes SAP NetWeaver System, das auf dem ABAP-Stack basiert, und dieser ist sicherlich für jeden SAP-Administrator beinahe so etwas wie ein alter Freund. Der grundlegende Aufbau, alle Verschlüsselungen und sämtliche Authentifizierungstechniken entsprechen dem bekannten SAP-Standard. Ein Erlernen neuer Techniken ist also nicht vonnöten.

Hört sich nicht schlecht an – aber meine Systeme sind nicht ganz up-to-date – also werde ich noch Jahre brauchen, um die Technik zu nutzen?

Auch an dieser Stelle besteht erst einmal kein Anlass zur Verzweiflung: Das SAP NetWeaver Gateway (SAP GW) ist stark rückwärtskompatibel und auch viele Fiori Apps benötigen nicht das neueste System. Dies hängt allerdings schon von der jeweiligen App ab, insofern ist es empfehlenswert, sich vor dem Start über die jeweiligen Anforderungen zu informieren. Mehr zum SAP Gateway finden Sie hier.

Klingt spannend – aber ich habe jetzt das SAP GUI und ein Portal im Einsatz – das alles zu ersetzen wäre ja ein riesiger Aufwand.

Eine komplette Umstellung in einem einzigen massiven Schritt ist gar nicht notwendig. Beim Start mit SAP Fiori können Sie zunächst – auch unbefristet – mit einem gesunden Miteinander beginnen. Es ist beispielsweise möglich, bestehende Portale als eigene Kachel auf dem Launchpad – also für den User gefühlt als App – zu integrieren, wenn gewünscht auch mit Single-Sign-On (SSO), also ohne gesondert notwendige Anmeldung.

Auch andersherum können Sie einzelne Fiori Apps und/oder das komplette Fiori Launchpad in Ihr Portal integrieren. Zudem ist es auch denkbar, aus der Fiori-Oberfläche zurück in Ihr bestehendes SAP GUI zu wechseln, was beispielsweise für nur sehr selten benötigte Transaktionen sinnvoll sein kann, für die sich die Entwicklung einer eigenen Fiori App nicht lohnt. Oder aber Sie binden benötigte Transaktionen direkt ins Launchpad ein und passen diese mit Screen Personas im Look-and-feel an die Fiori Design Guidelines an. So ebnen Sie den Weg für Ihre Anwender hin zu einem konsistenten User Interface. Dies ist bislang allerdings nur auf dem Desktop möglich.

Aber ein Problem sehe ich doch noch – ich habe gar nicht die Kompetenzen für dieses OData und SAPUI5 im Haus?

Auch kein Problem! Die Anwendungslogik und die eigentliche Bearbeitung liegen wie beschrieben weiterhin im Backend. Hier liegt bei neuen Fiori Apps auch der größte Entwicklungsaufwand, der aber immer noch in der bekannten ABAP-Welt vonstattengeht. Lediglich für die Einbindung und Entwicklung im Frontend benötigen Sie neue Technologien, aber hierbei handelt es sich ebenfalls um weitgehend bekannte Standards der Web-Entwicklung, die zudem durch die von SAP bereitgestellten Baukästen wie das SAPUI5 Framework unterstützt werden.

Durch Fiori Elements ist es auch möglich, das Aussehen einer App aus dem Backend zu steuern und auch dynamisch anzupassen. So kann zum Beispiel der Aufbau einer Tabelle inklusive Filter und Suchmöglichkeit komplett über den OData-Service gesteuert werden. Dies vereinfacht die Entwicklung stark, allerdings nur für Apps und Komponenten, die von der SAP dafür vorgesehen sind (Tendenz steigend).

Sind Sie dennoch wider Erwarten irgendwann mit Ihrem Entwicklungs-Latein am Ende, helfen wir Ihnen gerne, die passenden Ressourcen zu finden oder aufzubauen. Natürlich übernehmen wir bei Bedarf auch gerne die komplette Anpassung und Entwicklung Ihrer Fiori Apps.

Fiori hört sich für mich immer interessanter an … aber wie starte ich jetzt?

Probieren geht bekanntlich über studieren – und da kommt CONET als Ihr zuverlässiger Berater und Partner ins Spiel. Gerne diskutieren wir mit Ihnen, für welche Ihrer Prozesse sich Fiori bestens eignet und wie ein idealer Einstieg für Sie aussehen könnte. Wir stellen Ihnen Fiori natürlich auch persönlich vor – sowohl funktional als auch technisch. Außerdem können wir Ihnen verfügbare SAP Fiori Apps und die von uns selbst entwickelten Fiori-like Apps auf unserem Demosystem im Life-Einsatz zeigen.

• Setzen Sie Fioritäten – kostenfreie Fiori-like Apps von CONET
• Leichter Einstieg in die Fiori-Welt – mit den Fiori-Workshops von CONET
• Schicken Sie Ihre Fragen per E-Mail an DAlpers@conet.de

Link-Tipp: Kennen Sie bereits die SAP Fiori 1.0 Online Demo? Jetzt hier testen!