Konsequenzen der S/4-Hana-Einführung am Beispiel Baubranche

S wie „Simple“ funktioniert nicht immer

Die Echtzeit-ERP-Suite S/4 Hana ist die vierte Generation der ERP-Systeme von SAP. Das S steht für „Simple“, vor allem für die Vereinfachung der gesamten Datenarchitektur. Die bringt zwar größere Zugriffsgeschwindigkeiten und mit der Fiori-Oberfläche mehr Benutzerfreundlichkeit, aber auch Einschränkungen.

Hubert Schröder, Leiter Vertrieb & Marketing der Wiesbadener Futura Solutions GmbH, beleuchtet, welche Konsequenzen diese Vereinfachung auf die Abwicklung von Bau- und Dienstleistungen hat. Dabei legt er die sogenannte „Simplification List“ zugrunde, in der SAP aufführt, was sich beim Umstieg von ECC auf S/4 Hana verändert.

Dieses Dokument zeigt auf über 1.000 Seiten die Unterschiede bei Transaktionen, Tabellen, Datenstrukturen und Objekten auf – also ob etwas mit S/4 Hana nicht mehr unterstützt wird, ob etwas vereinfacht wird (d. h. nur mit einer Fiori-App zu bedienen ist) oder ob etwas durch neue Möglichkeiten ersetzt wird. Erst ist im September 2019 ist die neue Fassung der Liste für das jüngste Release S/4 Hana 1909 erschienen.

Fiori und die „User Experience“

Hinter dem neuen Bediendesign, das in Form von Fiori bzw. der Weiterentwicklung Fiori 2.0 mit S/4 Hana Einzug hält, verbirgt sich laut Schröder weit mehr als nur ein Wechsel der grafischen Benutzeroberfläche. Anstelle des bisherigen SAP-GUI setzt das Fiori-Konzept auf eine konsequent rollenbasierte, personalisierte Benutzerführung: Den Anwendern werden in ihrem Launchpad in Kacheloptik ausschließlich diejenigen Applikationen angezeigt, die sie für ihre Tätigkeit benötigen.

Genauso sehen Anwender auch in der Applikation einzig und allein die für ihre Rolle notwendigen Funktionen. Das ist Ausdruck des Principle-of-One-Ansatzes, der auf die Reduzierung der über die Jahre gewachsenen Komplexität und den Abbau von Redundanzen auch seitens der Funktionen abzielt. Zwar wird – in der On-Premise-Edition von S/4 Hana – das alte SAP GUI noch parallel unterstützt, jedoch ist auch dafür das Ende absehbar.

Aktuell (Stand Oktober 2019) verzeichnet die „Fiory Library“ insgesamt 10.769 Fiori-Apps für S/4 Hana. Doch bei der stetig wachsenden Zahl neuer Apps darf nicht übersehen werden, dass nicht alle GUI-Funktionen in eine Fiori-App überführt werden. Insbesondere für die Dienstleistungsbeschaffung hat dies weitreichende Folgen.

Lean Services“ sollen es richten

Von der Simplifizierung betroffen ist indirekt auch die Anwendungskomponente MM-SRV, eine Erweiterung des „Moduls Materialwirtschaft“ (MM), das bislang u. a. im Rahmen der Abwicklung von Bauleistungen zur Abbildung von mehrstufigen Leistungsverzeichnissen dient. Diese in der Einkaufskomponente MM-Dienstleistung (MM-SRV) erfassten mehrstufigen Leistungsverzeichnisse, die jeweils auf die einzelnen Hierachiestufen aggregiert werden konnten, werden in dieser Form über Fiori-Apps nicht mehr darstellbar sein. Stattdessen will SAP jede Art von Dienstleistungen im Rahmen der Simplifizierung als „Lean Services“, sprich schlanke Dienstleistungen, in Form einer einstufigen Liste analog zu heutigen SAP-Materiallisten abbilden – und führt dazu unter anderem einen neue Materialtyp SERV ein (siehe Simplification List, S. 124f).

Dieser neue Materialtyp im Szenario des „Lean Service Procurement“ beinhaltet im Vergleich zum bislang verwendeten Standardmaterialart „DIEN“ einen reduzierten Satz an nutzbaren Datenfeldern. In der Konsequenz entfernt sich SAP mit der neuen Benutzeroberfläche also immer weiter von der Verwendung komplexer (Bau-)Leistungsverzeichnisse, die in Deutschland über das etablierte GAEB-Format ausgetauscht werden.

Abschied von den Standards der (Bau-)Leistungsverzeichnisse

Stellt sich also die Frage: Welche Rolle spielt MM-SRV überhaupt in der Abwicklung von Bauleistungen? Die Frage mag überraschen, denn so funktional wichtig MM-SRV für die Bauleistungen ist, so selten wird letztlich in SAP mit MM-SRV gearbeitet.

Dies ist zu großen Teilen auf das umständliche Handling von Leistungsverzeichnissen in SAP zurückzuführen. Hier fehlt die erforderliche Benutzerfreundlichkeit in SAP. Der Grund: SAP ist für das Handling in der Materialwirtschaft konditioniert, jedoch weniger für den Gebrauch von komplexen Leistungsverzeichnissen; die Anwender haben hierbei eine andere Erwartungshaltung.

Hinzu kommt, dass die GAEB-Schnittstellen nicht unterstützt werden, wodurch Leistungsverzeichnisse manuell angelegt werden müssten – von einem anwenderfreundlichen Arbeiten mit SAP im Zusammenhang mit Leistungsverzeichnissen ist also nicht zu sprechen.

Umweg über AVA-Programme

Komplexe Leistungsverzeichnisse werden daher in der heutigen Praxis außerhalb von SAP, und zwar in sogenannten AVA-Programmen (Ausschreibung, Vergabe, Abrechnung) erstellt und ebenfalls außerhalb von SAP zur Ausschreibung gebracht. Der Auftragswert, der aus der Ausschreibung resultiert, wird dann in SAP nur als aggregierter Summenwert in einer Bestellung bzw. Bestellposition gebucht: 1 Stück (LE) Fertigungsanlage erstellen, 1 Mio. Euro.

Ein genaues Controlling (und das erst recht nicht in Echtzeit) ist infolgedessen so in SAP nicht möglich, da die erforderlichen Daten und Details fehlen: Zum Abbau des Obligos können lediglich die Summenwerte der jeweiligen Abschlagszahlungen in SAP-System herangezogen werden – ganz zu schweigen von einer differenzierten Abrechnung der erbrachten Leistung, die als Grundlage für Reportings und Kontrollmechanismen dient. Das kann folglich nur in einem externen System erfolgen. In der Regel ist dies wiederum das AVA-Programm, in dem auch das Leistungsverzeichnis erstellt wurde.

Das bedeutet: Was im AVA-Programm gepflegt wird (z. B. Aufmaße, Abschlagzahlungen, Nachträge), muss in SAP händisch nachgezogen werden. Die logische Folge: Es gibt redundante Daten und keine eindeutige Datenhaltung. Das Fehlerpotenzial bei der manuellen Übertragung der Abrechnungswerte in das SAP-System bleibt hoch.

S wie Simple“ – nicht für Bauleistungen

Bauleistungen und SAP, das waren immer schon zwei Welten. Denn Bauleistungen sind in Deutschland unweigerlich mit der Erstellung und Abrechnung von Leistungsverzeichnissen gekoppelt. Aufbau und Struktur der Leistungsverzeichnisse sind über das GAEB-Format definiert und zum Austausch standardisiert. D. h. jeder, der mit Leistungsverzeichnissen zu tun hat, sei es in der Planung (LV-Erstellung, Kostenschätzung), dem Einkauf (Ausschreibung, Bestellung) oder der Abrechnung (Aufmaß, Leistungserfassung), ist auf eine einfache Handhabung von Leistungsverzeichnissen angewiesen.

An dieser Stelle bleibt SAP seinen Anwendern seit Jahren eine Antwort schuldig. Mehrere Ankündigungen, das GAEB-Format zu unterstützen, sind bislang nicht eingehalten worden. Ein Im- und Export von GAEB-Leistungsverzeichnissen ist nach wie vor nicht möglich und wird auch in Zukunft nicht möglich sein. Zudem fehlt es dafür nicht nur an der Anwenderfreundlichkeit in SAP, sondern vielmehr auch an den Möglichkeiten, die bauspezifischen Prozesse überhaupt abzubilden.

Brücken mehr denn je gefragt

Während in der alten SAP-Welt über MM-SRV zumindest komplexe und mehrstufige Leistungsverzeichnisse abgebildet und über das derzeitige ECC SAP-GUI bearbeitet werden können, wird dies in der neuen S/4 Hana/Fiori-Kombination in dieser Form nicht mehr möglich sein.

Die Brücke, die heute bereits die Cloud-basierte Futura-Lösung zu SAP schafft, wird in Zukunft daher noch wichtiger werden. Zum einen weil sie das in Deutschland etablierte, jedoch von SAP nicht unterstützte GAEB-Format zum Austausch von komplexen Leistungsverzeichnissen unterstützt und – viel wichtiger -, weil Futura über eine tiefe Integration in das SAP-Backend (sowohl ECC wie auch S/4 Hana) verfügt. Seit 1997 entwickelt und betreibt Futura Solutions Software für die digitale Transformation in der Dienstleistungsbeschaffung, mit der heute weltweit branchenübergreifend mehr als 60.000 Anwender arbeiten.

Technisch analog zu den Fiori-Apps greift Futura unter anderem auf die SAP-Funktionsbausteine zu und bietet eine einfache Bedienoberfläche, um die Anwendungskomponente MM-SRV im Hintergrund weiterhin zu bedienen. So müssen Bauleistungen weder in das Korsett der „Lean Services“ gezwängt (was letztendlich überhaupt nicht funktionieren würde) – noch in ein AVA-Programm als Insellösung ausgelagert werden.

Und noch ein Aspekt darf nicht unterschätzt werden: Um die mit der neuen Datenbanktechnologie der In-memory-Plattform Hana versprochenen Performance-Steigerungen sowie bessere Möglichkeiten für Ad-hoc-Reporting, Analysen und Simulationen überhaupt nutzen zu können, braucht es eine entsprechende Datenqualität auch in der Dienstleistungsbeschaffung – eine Datenqualität, die mehr beinhaltet als nur die in der Praxis üblichen aggregierten Summenwerte in SAP. Auch an dieser Stelle sorgt Futura durch die Integrationstiefe für die entscheidende Basis, um differenzierte Auswertungen, Analysen und Controlling Maßnahmen im SAP-System überhaupt zu ermöglichen.

Kurze ERP-Geschichte der SAP

Angekündigt 2015, soll das aktuelle Produkt S/4 Hana das aktuelle SAP-System „ERP Central Component“ (ECC) ablösen. Bis Dezember 2003 wurde dieses Produkt noch unter dem Namen R/3 vermarktet, bis 2007 als Mysap ERP. ECC unterscheidet sich von R/3 vor allem dadurch, dass es auf der Middleware Netweaver aufbaut.

Wurde mit dem 1993 eingeführten Client/Server-System R/3 die dritte ERP-Generation in Walldorf eingeläutet, war dessen ab 1979 eingesetzter Vorgänger R/2 noch für den Betrieb auf Mainframes konzipiert. Dessen Vorgänger wiederum, die Mainframe-Systeme R1 und RF (steht für „Real-Time Financial“), wurden ab der Firmengründung 1972 entwickelt. Man sieht am Produktnamen: Auf die Echtzeit-Fähigkeit hatte SAP schon von Anbeginn großen Wert gelegt – zumindest im Marketing.

Bildquelle: Futura Solutions GmbH

©2019Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok