S wie „Simple“ in SAP S/4 HANA – auch für die Beschaffung von Bau- und Dienstleistungen?

Fiori und die User Experience

Was sich bei SAP ECC und S/4HANA verändern wird, ist in der sogenannten „Simplification List“ aufgeführt. Dieses zentrale Dokument zeigt die Unterschiede für Transaktionen, Tabellen, Datenstrukturen und Objekte auf, also ob etwas mit S/4HANA nicht mehr unterstützt wird, etwas vereinfacht, d. h. nur mit einer Fiori-App zu bedienen ist, oder durch neue Möglichkeiten ersetzt wurde. Wie angekündigt ist im September 2019 die neue Fassung Simplification List for SAP S/4HANA 1909 erschienen.

Hinter dem neuen Bediendesign, das in Form von SAP Fiori bzw. die Weiterentwicklung Fiori 2.0 mit S/4HANA Einzug hält, verbirgt sich weit mehr als ein reiner Wechsel der grafischen Benutzeroberfläche. Anstelle des aktuellen SAP GUI-Interfaces setzt das Fiori-Konzept auf eine konsequente rollenbasierte, personalisierte Benutzerführung: Anwendern werden in einem Launchpad in Kacheloptik ausschließlich die Applikationen angezeigt, die sie für ihre Tätigkeit benötigen. Genauso sehen Anwender auch in der Applikation nur noch 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 Abbau von Redundanzen auch seitens der Funktionen abzielt. Zwar wird – in der On-Premise-Edition von SAP S/4HANA – das alte SAP GUI parallel weiterhin unterstützt, jedoch ist auch dafür das Ende absehbar.

Aktuell (Stand Oktober 2019) verzeichnet die Fiory Library 10.769 Fiori-Apps für S/4HANA. 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 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 (Simplification List, S. 124f). Dieser neue Materialtyp im Szenario des Lean Service Procurement beinhaltet im Vergleich zum bislang verwendeten Materialtyp DIEN einen reduzierten Satz an nutzbaren Datenfeldern. In der Konsequenz entfernt sich SAP mit der neuen Benutzeroberfläche immer weiter von der Verwendung komplexer (Bau-)Leistungsverzeichnisse, die in Deutschland über das etablierte GAEB-Format ausgetauscht werden.

Welche Rolle spielt MM-SRV 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. Dazu 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.

Komplexe Leistungsverzeichnisse werden in der heutigen Praxis daher außerhalb von SAP, und zwar in 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 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 Abschlagzahlungen 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. 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“ funktioniert 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.

Während in der alten SAP Welt über SAP 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/4HANA-Fiori-Kombination in dieser Form nicht mehr möglich sein.

Brücken sind mehr denn je gefragt

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, das zum Austausch von komplexen Leistungsverzeichnissen genutzt wird, unterstützt und – viel wichtiger -, weil FUTURA über eine tiefe Integration in das SAP-Backend (ECC wie auch S/4HANA) verfügt. 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 schließlich überhaupt nicht funktioniert – 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 ausnutzen 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 – ECC wie in S/4HANA – überhaupt zu ermöglichen.