The fact that not every GUI transaction is transferred to a Fiori app with the switch to S/4HANA, is not only due to the new Fiori design principles. It is also the result of strategic limits deliberately set by SAP, which are sold as an advantage for SAP customers. Customers who focus on services in purchasing and procurement are particularly affected.
Many companies that are implementing S/4HANA today also want to rethink the operating concept in this context and improve the general user experience when using SAP. For this purpose, SAP provides a proven option with the Fiori Apps, namely to operate the SAP backend system via a simpler interface instead of having to navigate through the SAP transactions.
So far so good. However, the functional scope of Fiori apps is limited: Not every GUI transaction is converted into a Fiori app. This is not only due to the different Fiori design principles but is equally the result of strategic decisions that are sold as an advantage for SAP customers. One such boundary is drawn for customers who focus on services in purchasing and procurement.
The previous item type “Service” in the MM-SRV module is not supported by the Fiori Apps, even though this function is still implemented in S/4HANA. MM-SRV can be used in the SAP backend (S/4HANA), to map multi-level service specifications with item type “Service”, for example. Instead, SAP propagates “Lean Services”, which we have already discussed in an older blog post. The term already serves as a selling point with a new purchasing experience for service procurement, because lean is now a principle: “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.”(from: SAP Service Procurement – Transforming from Complex to Collaborative user experience, February 2022)
The basis for the transformation of service procurement is the change in the master data concept in SAP S/4HANA, which was introduced back in 2017 with Release 1708: Material and the new services are now based on the same data structure. This architecture is fundamentally different from MM-SRV-based service procurement, in which service master data is independent of the material master concept. SAP has coined the term “Lean Service Procurement” for this: “The new service procurement in S/4HANA is named ‘Lean Services Procurement’ to distinguish itself from the ECC classic service procurement (MM-SRV) . The architecture of ‘Lean Services Procurement’ differs significantly from the MM-SRV based services procurement.”
Hence, “service” in the Fiori environment is no longer the same as “service” in the ERP environment:
A recent SAP blog post on S/4 HANA Service Procurement published in March 2022 highlights the crux of the change from the old data model to the new one, called “Product Services”: “The old data model, i.e., the service master from SAP ERP, is not available. The SAP Fiori apps have been developed with a focus on the new data model. The old data model is not supported. This means that when you see “Service” on an SAP Fiori screen, you can only use the new data model. […] It’s a challenge for customers who want to use the old service data model with SAP Fiori Apps.”
Many customers are now asking about the status of multi-level service specifications with the item type “Service” in SAP, which are mapped in the SAP module MM-SRV. SAP kept these customers in the dark for a long time and in between also spread the word that MM-SRV would no longer be supported in the S/4HANA environment.
Customers were unsure, after all, you cannot tell planning and engineering offices that they must plan “lean” from now on because SAP plans to do so in the future. As before and also in the future, when using S/4HANA, there are customers who need to use the item type “Service” for GAEB-based service specifications, for example. From the customer’s point of view, it would be a huge step backwards and a step away from the digitalization of purchasing if this transparency were lost in SAP and one had to go back to 1 SU manufacturing building, wind turbine, etc.
SAP started to row back. The MM-SRV module will continue to be supported in S/4HANA, even after 2025, the previously announced end date of the compatibility scope. But the strategic direction remains: Customers taking a greenfield approach are advised to switch to the new data model to take advantage of the experience strategy with the move to SAP Fiori.
The SAP S/4HANA 2022 release now takes a decisive step from single-level services (Lean) to multi-level services (Complex). While the former are only mapped as single-level services, multi-level services shall cover multi-level, i.e. hierarchically structured service bundles. These are intended to serve as an adequate counterpart to MM-SRV: “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.” (From: SAP Service Procurement – Transforming from Complex to Collaborative user experience, February 2022)
But a closer look at these item hierarchies shows: SAP puts up a smokescreen here to create the impression that it can be used to map multi-level service specifications that are GAEB-compliant in the same way as MM-SRV. However, this will not be the case, because multi-level alone does not constitute GAEB standard. A GAEB-based service specification is marked with reference numbers that represent the DNA of a GAEB service specification. Furthermore, the items (in SAP language: service lines) have a certain structure and there are also different item types and categories. This is just a very small excerpt from the GAEB conventions.
SAP’s vision behind the introduction of the new data model is to reduce and eliminate complexity in service procurement and to close supposed integration gaps. But isn’t the real reason why SAP is pushing for a new data model in connection with services that SAP Ariba simply cannot process item type “Service” and thus GAEB-based service specifications?
Ariba is SAP’s purchasing solution. And in this respect, SAP cannot allow the creation of requisitions in S/4HANA that cannot subsequently be processed in Ariba. Ultimately, it is a vicious circle for SAP. The once coined and developed module MM-SRV cannot be eliminated, because this module supports a standard, namely GAEB, which is widely used and the new data model does not provide an adequate answer or solution. For other cases, FUTURA Apps are available, which can be called via the SAP Launchpad as a supplement and in addition to the Fiori Apps. In this way, the SAP Launchpad becomes the central purchasing hub for all product groups, including services.
Via FUTURA Apps you do not only process the item type “Service” in SAP. You also read out the purchase requisitions – and at the same time the FUTURA Apps are the gateway to the supplier via the FUTURA Cloud. In this way, purchasers work seamlessly in SAP and transfer their requisitions to a tender as part of the same process – regardless of whether services or materials are involved. And all this in a lean and simple way with homogeneous process flows.
At the end of the tendering process via FUTURA Cloud, you create purchase orders or contracts, even for item type “Service”, i.e., purchase orders for services or service contracts, each with a multi-level service specification in MM-SRV. Speaking of MM-SRV: With SAP S/4HANA on Premise as well as SAP S/4HANA Cloud Extended Edition, the MM-SRV module is fully supported. This is also underlined by the official SAP certification of FUTURA Cloud and its interfaces for S/4HANA in June 2022. The certification of FUTURA Cloud vouches for the fact that the integration scenario has been tested by SAP and at the same time underlines that the procurement of Complex Services, i.e., construction and services, can be seamlessly mapped digitally with SAP as Digital Core in interaction with S/4HANA.
Picture credit:
© Andrey_Popov/Shutterstock.com
"From digital building model to workflow engine"
Architect, pacesetter, founder and CEO of Futura Solutions. A consistent process approach is his driving force and at the same time the focus of his blog posts: Networking, collaboration and process optimization in service procurement.
S stands for "Simple", a simplification of the entire data architecture. While this offers faster access times and improved usability with the Fiori interface, it also implies restrictions due to the simplification. We shed light on what consequences the SAP S/4HANA strategy will have on the processing of construction and services.
SAP's "Transform SRM" program specifically supports the move to the cloud. Looking at service purchasing. What does the SRM follow-up solution have in store for the purchasing of services?
