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

Mit einigen falschen Vorstellungen möchten wir in unserem aktuellen Blog-Beitrag 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.

  • Fiori ist eine reine Mobility-Technologie!
  • Mit Fiori kann ich doch nur ein paar Genehmigungen auf dem Smart Phone vornehmen!
  • Für Fiori muss ich meine komplette Architektur umbauen!
  • Für Fiori brauche ich HANA!
  • Für Fiori benötige ich das neuste System!
  • Mit Fiori muss ich komplett neue Technologien abseits des SAP-Standards erlernen!
  • Eine App ist wie eine Transaktion!

Vieler dieser und ähnlicher Aussagen sind uns in den vergangenen Monaten in den Gesprächen mit Kunden und Interessenten begegnet – sie zeugen von vielen Missverständnissen und fehlenden Informationen.

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

Was ist Fiori?

SAP Fiori ist eine relativ neue, nun grob anderthalb Jahre alte UI-Technologie von SAP. 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. Fiori ist allerdings 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.
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 dem 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 vor mehr als 15 Jahren 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 lässt. 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, deutsch soviel 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 wirklich 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 natürlich 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 natürlich einerseits weniger Installationsaufwand, heißt aber auch, dass zur Nutzung immer eine aktive Online-Verbindung notwendig ist. (Eine Nutzung offline ist zwar auch möglich, aber mit Mehraufwand und der Verwendung der SAP Mobile Plattform [SMP] verbunden.)

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, sich auch 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 eine moderne UI 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 soweit ganz 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 beinah aller aktuellen Benutzeroberflächen – passend zu den eigenen Anforderungen und Aufgaben personalisieren.

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. Diese sind auf SAP-Systemen unabhängig von der eingesetzten Datenbank lauffähig (solange diese mit SAP kompatibel ist). 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.

Analytical Apps und Fact Sheets benötigen 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 mehr als 350 Fiori Apps (Fact Sheets, Transaktionale und Analytical Apps ) 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.

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 das zu befürchten ist, 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.

Dann muss ich meine bereits bestehenden Prozesse ja 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 bleiben weitestgehend im Backend.

Eine Fiori App besteht daher immer aus zwei Komponenten – der UI und einem Datenservice. Die 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 Gerä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 FuBAs oder BAPIs basieren oder auch komplett selbst implementiert werden. Der GW Service gibt aber nur 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“ (einer gesonderten Weiterentwicklung der SE 80, die sich für den Zugriff auf beinah alle SAP-Funktionen und Objekte eignet). 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 gemausert 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 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.

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 beinah 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 ja 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 Transaktionale Fiori Apps benötigen nicht das neuste 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.

Klingt spannend – aber ich habe jetzt das SAP GUI und ein Portal im Einsatz – das alles zu ersetzten 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 anders herum 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. Dies ist 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 liegt wie beschrieben weiterhin im Backend. Hier liegt bei neuen Fiori Apps auch der größte Entwicklungsaufwand, der aber weiterhin in der bekannten ABAP-Welt vonstatten geht. Lediglich für die Einbindung und Entwicklung im Frontend benötigen Sie neue Technologien, aber hierbei handelt es sich um ebenfalls weitgehend bekannte Standards der Web-Entwicklung, die zudem durch die von SAP bereitgestellten Baukästen wie das SAPUI5 Framework unterstützt werden. 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 ja 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 Fori-like Apps auf unserem Demosystem im Life-Einsatz zeigen.

 

Link-Tipp: Kennen Sie bereits unsere SAP Fiori Online Demo? Jetzt testen unter http://www.conet.de/mobility/fiori-demo

Dominik Alpers

Dominik Alpers

Dominik Alpers berät als Mobility & SAP Consultant bei der CONET Business Consultants GmbH die Kunden des SAP-Beratungshauses in allen Fragen rund um mobile Lösungen von der Mobility-Strategie und Prozessfragen über Infrastrukturaspekte bis hin zu mobilen Apps und deren Entwicklung.
Dominik Alpers

2 Kommentare

Antwort hinterlassen

Shares