Mein Prozess, meine App, mein Wettbewerbsvorteil

Die Welt sehnt sich nach einfachen Antworten! Da bildet die SAP-Community keine Ausnahme – insbesondere, wenn die Transformation auf S/4 diskutiert wird. Von interessierter Seite wird gerne argumentiert, dass S/4 alles beherrscht. Der Abbau des Wildwuchses von Abap-Modifikationen und Z-Programmen sowie die Rückkehr zum Standard gelten – um den Politikjargon zu bemühen – als alternativ-los. Und falls noch Funktionswünsche unerfüllt sind, hält die Community vielleicht eine passende Lösung in den öffentlichen App-„Läden“ bereit.

Zweifellos bietet S/4 einen reichhaltigen Funktionsumfang und interessante technische Innovationen. Unstrittig verfügen die Rückführung auf den Standard und das „Keep the Core Clean“-Paradigma über eine hohe Überzeugungskraft. Das gilt vorzugsweise für geplagte SAP-Verantwortliche in Unternehmen, die sich täglich mit dem gewachsenen Wildwuchs ihrer Anwendungslandschaft konfrontiert sehen. Wahr ist allerdings auch, dass S/4 Hana viel, aber nicht alles kann. Vor allen Dingen ist es ein Widerspruch in sich, mithilfe von Best Practices und Standard- Funktionsumfang Wettbewerbsvorteile generieren zu können.

Für Apps aus allgemein zugänglichen Verzeichnissen gilt Vergleichbares. Eine App aus dem SAP-Store wie beispielsweise BTC Facility Issue Report zur Schadensmeldung stellt in der täglichen Arbeit gewiss eine geschätzte Hilfe dar. Es bedarf allerdings großer Fantasie, einzigartige Wettbewerbsvorteile in Programmen aus allgemein zugänglichen Verzeichnissen zu vermuten. Überspitzt formuliert bilden die Apps das mobile Pendant zur Standardfunktionalität der Unternehmensanwendung im Backend.

In der Quintessenz muss sich jedes Unternehmen, das vor der S/4-Transformation steht, zwangsläufig der Diskussion zwischen Individual- und Standardsoftware stellen beziehungsweise mit der Ewigkeitsfrage der IT, „Make or buy?“, auseinandersetzen. Dabei – soviel sei hier schon einmal verraten – enthält die Frage im Kern bereits die Antwort. Das „or“ ist einfach durch ein „and“ zu ersetzen und das „make“ ist im Vergleich zum „buy“ eher kleinzuschreiben.

Letzteres darf durchaus wörtlich verstanden werden. Denn ein erfolgsversprechender Lösungsansatz kombiniert die konsequente Rückführung auf den SAP-Standard mit einer individuellen Entwicklung von Fiori-Apps, um wettbewerbsrelevante Funktionen zu realisieren. Von Vorteil ist, dass SAP die notwendigen Development-Tools, Erweiterungsumgebung (BTP Extension Suite, Enhancement Framework) und Betriebsumgebung (Fiori-Launch-pad) bereitstellt. Es lassen sich grundsätzlich modifikationsfreie Ergänzungen an Datenobjekten vornehmen oder individuelle Verarbeitungslogik ergänzen.

Eine neue App ist direkt im SAP-Berechtigungskonzept eingegliedert und funktioniert in allen einschlägigen Cloud- oder On-premises-Betriebsszenarien. Fiori-Apps tragen mit der „Mobile First“-Vorgabe der veränderten Nutzer-Experience Rechnung, unterstützen grundsätzlich aber auch den Einsatz auf dem Desktop.  

Must-have statt nice-to-have

Bevor man sich nun darauf stürzt, die individuellen Ergänzungen und Anpassungen des Altsystems eins zu eins nachzubilden, sind im Vorfeld der Transformation einige grundsätzliche Überlegungen zu treffen. Mit der gebotenen Sorgfalt sollte der individuelle Bedarf bestimmt werden, dessen Gebrauch Wettbewerbsvorteile gegenüber den Mitbewerbern zusichert. Dazu wird der von SAP standardmäßig bereitgestellte Funktionsumfang mit der von einem Unternehmen gewünschten, in der Regel im Altsystem schon genutzten Funktionalität verglichen.

Im zweiten Schritt werden die zwingend benötigten Funktionen erfasst, die im Standard keine Entsprechung finden. Das entscheidende Wort in diesem Kontext heißt „zwingend“. Angesichts des hohen Ressourcen- und Zeitaufwandes, den eine S/4-Transformation per se schon bedeutet, mutet es kontraproduktiv an, jede maßgeschneiderte Ausprägung oder individuelle Designvorliebe noch einmal als App zu realisieren. Die Investitionen sollten ausschließlich auf Funktionen und Prozesse konzentriert werden, die realen Mehrwert versprechen. Zur Identifikation bietet sich ein simpel klingendes, dafür zuverlässig arbeitendes Vorgehen an. Jede Antwort auf die Frage: „Bei welcher Funktion sind wir froh, dass sie nicht Teil vom Standard ist oder unser Wettbewerb sie hat?“, stellt einen geeigneten Must-
have-Kandidaten für die Realisierung dar. Denn die Eigeneinschätzung weist darauf hin, dass die Funktion einen nennenswerten Beitrag zum Unternehmenserfolg leistet.

Wettbewerbsvorteil

Da die Realisierung der Funktion als schlanke Fiori-App angestrebt wird, verbietet es sich schon aus Aufwands- und Kostengründen, eine Methode mit Management-Overhead wie Scrum, Kanban oder andere zu wählen. Es liegt in der Natur der Sache beziehungsweise – besser formuliert – in der Natur der Aufgabe, die Entwicklung durch eine ebenso schlanke Vorgehensweise zu begleiten. Um in kurzer Zeit die Belastbarkeit eines Funktionsvorschlags zu testen, bietet sich der Design Sprint als geeignetes Verfahren an – eine bei Start-ups beliebte, ursprünglich von Google Ventures stammende Methode. Mit Design Sprint ist die Vorstellung verknüpft, binnen weniger Tage im Schnelldurchlauf Produktideen zu validieren, Prototypen zu realisieren und von Nutzern testen zu lassen, um am Ende die Erfolgsaussichten einer vollständigen Umsetzung bewerten zu können.

Ein solcher Fiori-Sprint setzt sich aus vier unterschiedlichen, im Idealfall einen Tag beanspruchenden Episoden zusammen. Zu Beginn gilt es, die Anforderungen zu identifizieren, beispielsweise nach dem im vorausgegangenen Absatz beschriebenen Ansatz. Im zweiten Schritt werden gemeinsam Details für die User Experience einer App erarbeitet. Der im Anschluss erstellte Prototyp vermittelt Nutzern erste Erfahrungen mit der Umsetzung der Funktion als App auf einem Smartphone, Tablet oder PC. Die Verantwortlichen erhalten nach dem erfolgreichen Test von den unterstützenden Beratern eine belastbare Kalkulationsgrundlage für die Entwicklung der funktionstüchtigen App und können deren Realisierung im Rahmen der S/4-Einführung passend priorisieren.

Fazit

Mit dem skizzierten Lösungsansatz erhalten die Unternehmen eine erstklassige Chance, individuelle Prozessstärken weiterhin auszuspielen, ohne das „Keep the Core Clean“-Paradigma im SAP-Standard zu gefährden. Im Prinzip wird eine Art Z-Datenraum nachgebildet für die Realisierung maßgeschneiderter Funktionen als App. Dieser ermöglicht es Unternehmen, ihr zum Teil langjährig gepflegtes intellektuelles Eigentum und Wissen über optimierte Prozesse und Funktionen in die neue SAP-Welt zu retten – auf neuer Basis und zu einem Bruchteil des finanziellen und des personellen Aufwandes.