Von Classic (MM-SRV) zu New (Lean) Services – die neue Sicht von SAP

Dass mit dem Sprung zu S/4HANA nicht jede GUI-Transaktion in einer Fiori App überführt wird, liegt nicht nur an den neuen Fiori-Design-Prinzipien. Der Wechsel von MM-SRV auf das Konzept der Lean Services ist ebenso das Ergebnis bewusst gesetzter strategischer Grenzen, die als Vorteil für die SAP-Kunden verkauft werden. Ganz besonders sind diejenigen Kunden betroffen, die im Einkauf und der Beschaffung auf Dienstleistungen setzen.

Adé MM-SRV?

Viele Unternehmen, die heute S/4HANA einführen, wollen in diesem Zusammenhang auch das Bedienkonzept überdenken und die allgemeine User Experience bei der Anwendung von SAP verbessern. Dafür stellt SAP mit den Fiori Apps eine probate Möglichkeit zur Verfügung, nämlich das SAP Backend-System über eine einfachere Oberfläche zu bedienen und sich nicht durch die SAP-Transaktionen durchbewegen zu müssen.

So weit so gut. Der Funktionsumfang der Fiori Apps hat jedoch seine Grenzen: Nicht jede GUI-Transaktion wird in eine Fiori App überführt. Dies liegt nicht nur an den anderen Fiori-Design-Prinzipien, sondern ist ebenso Ergebnis strategischer Entscheidungen, die als Vorteil für die SAP-Kunden verkauft werden. Eine solche Grenze wird für die Kunden gezogen, die im Einkauf und der Beschaffung auf Dienstleistungen setzen.

Der bisherige Pos.-Typ „D“ im Modul MM-SRV wird – obwohl diese Funktion nach wie vor in S/4HANA implementiert ist – von den Fiori Apps nicht unterstützt. Mittels MM-SRV können im SAP-Backend (S/4HANA) z. B. mehrstufige Leistungsverzeichnisse zum Pos.-Typ „D“ abgebildet werden (an diese Stelle treten die „Lean Services“, auf die wir bereits in einem älteren Blogbeitrag eingegangen sind). Die Bezeichnung dient bereits als Verkaufsargument mit neuem Einkaufserlebnis für die Dienstleistungsbeschaffung, denn schlank ist heute ein Prinzip: „The Terms ´Lean´ signifies that the new Service Procurement focuses on the concepts of lean management principles thereby avoiding waste and in-efficient way of data processing , and bring the value to customers.“(aus: SAP Service Procurement – Transforming from Complex to Collaborative user experience, Februar 2022)

Neues Datenmodell für S/4HANA

Grundlage für die Transformation der Dienstleistungsbeschaffung ist die Änderung des Stammdatenkonzepts in SAP S/4HANA, das bereits 2017 mit dem Release 1708 eingeführt wurde: Material- und die neuen Services basieren nun auf dergleichen Datenstruktur. Diese Architektur unterscheidet sich grundlegend von der MM-SRV-basierten Dienstleistungsbeschaffung, in der Leistungsstammdaten unabhängig vom Materialstammkonzept sind. SAP hat dafür den Begriff „Lean Service Procurement“ geprägt:

Das heißt: „Service“ in der Fiori-Welt ist also nicht mehr gleich „Service“ in der ERP-Welt: 
In einem aktuellen SAP-Blogbeitrag vom März 2022 zum S/4 HANA Service Procurement wird die Krux des Wechsels vom alten zum neuen Datenmodell, „Product Services“ genannt, deutlich: „The old data model, meaning the service master from SAP ERP, is not available. The SAP Fiori apps have been developed with the focus on the new data model. The old data model is not supported. This means when you see “service” on an SAP Fiori screen, only the new data model can be used. […] It is a challenge for customers wanting to use the old services data model with SAP Fiori Apps.“

„Schlank“ planen auf Raten

Nun haben viele Kunden gefragt, wie es um die mehrstufigen Leistungsverzeichnisse mit dem Pos.-Typ „D“ in SAP steht, die im SAP Modul MM-SRV abgebildet werden. Die SAP ließ diese Kunden lange im Unklaren und streute zwischendurch auch, dass MM-SRV im Umfeld von S/4HANA nicht mehr unterstützt werden würde.

Die Kunden waren verunsichert, schließlich kann man den Planungs- und Ingenieurbüros nicht mitteilen, dass sie ab sofort auch „schlank“ planen sollen, weil SAP dies für die Zukunft so vorsieht. Nach wie vor und auch in der Zukunft gibt es bei der Nutzung von S/4HANA Kunden, die den Bedarf haben, den Pos.-Typ „D“ für z. B. GAEB-LVs zu verwenden. Aus Sicht der Kunden wäre es ein riesengroßer Rückschritt und ein Zurück von der Digitalisierung des Einkaufs, wenn diese Transparenz in SAP verlorenginge und man wieder zu 1 LE Produktionsgebäude, Windkraftanlage etc. zurückkehren müsste.

SAP fing an zurückzurudern. Das Modul MM-SRV wird weiterhin in S/4HANA unterstützt, und zwar auch nach 2025, dem vorher kommunizierten Enddatum des Compatibility Scopes. Doch die strategische Ausrichtung bleibt: Kunden, die einen Greenfieldansatz verfolgen, wird empfohlen, auf das neue Datenmodell umzusteigen, um die Experience-Strategie mit dem Wechsel zu SAP Fiori nutzen zu können.  

S/4HANA Release 2022 – ready for Multi-levels bzw. Complex Services?

Einen entscheidenden Schritt von Single-level-Services (Lean) zu Multi-levels Service (Complex) macht nun das Release SAP S/4HANA 2022. Während erstere nur einstufig abgebildet werden, sollen Multi-Levels-Services mehrstufige, d. h. hierarchisch strukturierte Dienstleistungsbündel mit abdecken. Diese sollen nun als adäquates Pendant zu MM-SRV dienen: „SAP ECC customers in asset intensive, maintenance and construction industries, had been using the SAP ECC MM-SRV based Service Hierarchies. These SAP ECC customers transforming to SAP S/4HANA can use the new item hierarchies.“ (aus: SAP Service Procurement – Transforming from Complex to Collaborative user experience, Februar 2022)

Doch ein genauer Blick auf diese Positionshierarchien zeigt: Hier zündet SAP eine Nebelkerze, die den Anschein wecken soll, dass damit mehrstufige Leistungsverzeichnisse abgebildet werden können, die analog zu MM-SRV GAEB-konform sind. Dies wird allerdings nicht der Fall sein, denn Mehrstufigkeit alleine macht noch lange kein GAEB. Ein GAEB-LV ist gekennzeichnet mit einer OZ (Ordnungszahl), die im Grunde das DNA eines GAEB-LVs darstellt. Des Weiteren haben die Positionen (im SAP-Sprachgebrauch: Leistungszeilen) einen bestimmten Aufbau und zudem gibt es verschiedene Positionstypen und -arten, um nur einen ganz kleinen Ausschnitt aus dem GAEB aufzuzeigen.  

„Fiori first“ – ja, aber nicht für alle Anwendungsfälle

Die Vision von SAP für die Einführung des neuen Datenmodells besteht darin, die Komplexität in der Dienstleistungsbeschaffung zu reduzieren und zu beseitigen und vermeintliche Integrationslücken zu schließen. Doch ist der wahre Grund, weshalb SAP zu einem neuen Datenmodell im Zusammenhang mit Dienstleistungen drängt, nicht darin zu suchen, dass schlicht und ergreifend SAP Ariba den Pos.-Typ „D“ und somit GAEB-LVs nicht verarbeiten kann?

Ariba ist die Einkaufslösung der SAP. Und insofern ist es kaum im Interesse von SAP, dass in S/4HANA Bedarfe erstellt werden, die nachfolgend in Ariba nicht weiterverarbeitet werden können. Letztlich ist es für die SAP eine Zwickmühle. Das einmal geprägte und entwickelte Modul MM-SRV ist nicht wegzubekommen, da dieses Modul einen Standard unterstützt, nämlich GAEB, der weit verbreitet ist und für den das neue Datenmodell keine adäquate Antwort bzw. Lösung liefert.

FUTURA für S/4HANA

FUTURA-Apps, die als Ergänzung und neben den Fiori Apps über das SAP Launchpad aufgerufen werden können, können hier Abhilfe schaffen.

Über FUTURA Apps bearbeiten Sie nicht nur den Pos.-Typ „D“ in SAP. Sie lesen darüber ebenso Ihre zu beschaffenden BANFen aus – und zugleich sind die FUTURA-Apps das Tor zum Supplier über FUTURA. So arbeiten Einkäufer nahtlos in SAP und überführen ihre Bedarfe im selben Zuge in eine Ausschreibung – egal ob Dienstleistungen oder Material. Und dies  schlank und einfach mit homogenen Prozessabläufen. Am Ende des Ausschreibungsprozesses über die FUTURA legen Sie Bestellungen oder Kontrakte an, und dies auch für den Pos.-Typ „D“, also Dienstleistungsbestellung oder Dienstleistungskontrakte mit einem jeweils mehrstufigen LV in MM-SRV.

Apropos MM-SRV: Mit SAP S/4HANA on Premise sowie SAP S/4HANA Cloud Extended Edition wird das Modul MM-SRV uneingeschränkt unterstützt. Das unterstreicht auch die offizielle SAP-Zertifizierung von FUTURA für S/4HANA im Juni 2022. Die Zertifizierung von FUTURA bürgt dafür, dass das Integrationsszenario durch SAP getestet wurde, und unterstreicht gleichzeitig, dass die Beschaffung von Complex Services, d. h. Bau- und Dienstleistungen, im Zusammenspiel mit S/4HANA nahtlos digital mit SAP als Digital Core abgebildet werden kann.

Bildnachweis
© Andrey_Popov/Shutterstock.com