S as in "Simple" in SAP S/4 HANA – does this also apply to service procurement?

SAP S/4HANA is the real-time ERP suite of the fourth generation. 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. It has been announced that the current ERP system Central Component (ECC) will be replaced by S/4HANA in 2025. We shed light on what consequences the SAP S/4HANA strategy will have on the processing of construction and services.

Fiori and the user experience

What will change in SAP ECC and S/4HANA is outlined in the so-called "Simplification List". This central document shows the differences for transactions, tables, data structures and objects, i.e., whether something is no longer supported by S/4HANA, whether something has been simplified, i.e., can only be operated with a Fiori app, or whether it has been replaced by new options. As announced, the new version of Simplification List for SAP S/4HANA 1909 was released in September 2019

The new user interface design, which is being introduced with S/4HANA in the form of SAP Fiori or the further development Fiori 2.0, is much more than just a change in the graphical user interface. Instead of the current SAP GUI interface, the Fiori concept relies on consistent, role-based, personalized user guidance: Users only see the applications they need for their work in a tile-style launchpad. In the same way, users only see the functions necessary for their role in the application. This is an expression of the Principle of One approach, which aims to reduce the complexity that has grown over the years and to reduce redundancies, including on the part of the functions. Although the old SAP GUI will continue to be simultaneously supported in the on-premise edition of SAP S/4HANA, the end of this is also in sight.

Currently (as of October 2019), the Fiory Library lists 10,769 Fiori apps for S/4HANA. But with the constantly growing number of new apps, one should not overlook that not all GUI functions are transferred to a Fiori app. This has far-reaching consequences for service procurement in particular.

"Lean services" are supposed to fix it

The simplification also indirectly affects the MM-SRV application component, an extension of the Materials Management (MM) module, which among other things has so far been used to map multi-level item lists in the context of processing construction services. These multi-level item lists recorded in MM-SRV, each of which could be aggregated to the individual hierarchy levels, will no longer be displayable in this form via Fiori apps. Instead, as part of the simplification process, SAP wants to depict each type of service as "lean services" in the form of a single-level list analogous to today's SAP material lists and, among other things, is introducing a new material type SERV for this purpose (Simplification List, p. 124f). This new material type in the Lean Service procurement scenario contains a reduced set of usable data fields compared to the previously used material type DIEN. As a consequence, SAP's new user interface moves further and further away from the use of complex (construction) item lists, which are exchanged in Germany via the established GAEB format.

What role does MM-SRV play in the processing of construction services?

The question may come as a surprise, because despite the functional importance of MM-SRV for construction services, MM-SRV is rarely used in SAP. This is largely due to the inconvenient handling of ittem lists in SAP. The required usability in SAP is lacking here. The reason: SAP is geared for handling materials management and less so for the usage of complex item lists, which are common in the procurement of services, or more precisely, construction services. In addition, GAEB interfaces are not supported, which means that service specifications would have to be created manually – it is therefore not possible to speak of usability when using SAP in connection with item lists.

In today's practice, complex item lists are therefore created outside of SAP, namely in AVA programs (request, awarding, billing) and also used for requests outside of SAP. The order value resulting from the request is then only posted in SAP as an aggregated total value in a purchase order or purchase order item: Create 1 piece (SU) of production equipment, 1 million euros.

As a result, accurate controlling in real time is not possible in SAP because the required data and details are missing: Only the totals of the respective partial payments in SAP can be used to reduce the commitment – with no differentiated accounting of the service provided, which serves as the basis for reporting and control mechanisms. Consequently, this can only be done in an external system. This is usually the AVA program that was used to create the item list.

This means that what is maintained in the AVA program (e.g., measurements, progress payments, supplements) must be manually updated in SAP. There is redundant data and no clear data management. The potential for errors in the manual transfer of billing values to the SAP system remains high.

"S for Simple" does not work for construction services

Construction services and SAP have always been two different worlds. In Germany, construction services are inevitably linked to the creation and billing of item lists. The structure of item lists is defined by the GAEB format and standardized for exchange. This means that anyone who has to deal with item lists, whether in planning (preparation of item lists, cost estimation), purchasing (requests, ordering) or billing (measurement, service  entries), has to rely on the simple handling of item lists.

This is where SAP has been owing its users an answer for years. Several announcements to support the GAEB format have not been kept so far. Importing and exporting GAEB-based item lists is still not possible and will not be possible in the future. In addition, there is not only a lack of usability in SAP for this, but more importantly also a lack of possibilities to map the construction-specific processes at all.

While in the old SAP environment complex and multi-level item lists can at least be mapped via SAP MM-SRV and processed via the current ECC SAP GUI, this will no longer be possible in a similar form with the new S/4HANA-Fiori combination.

Bridges are required more than ever

The bridge to SAP that the cloud-based FUTURA solution already provides today, will therefore become even more important in the future. On the one hand, because it supports the GAEB format, which is standard in Germany and is used for the exchange of complex item lists, but which is not supported by SAP, and – much more importantly – because FUTURA has a deep integration into the SAP backend (ECC as well as S/4HANA). Technically analogous to Fiori apps, FUTURA accesses SAP function modules, among other things, and provides a simple user interface to continue operating the MM-SRV application component in the background. This means that construction services do not have to be forced into the corset of Lean Services – which ultimately does not work at all – nor do they have to be outsourced to an AVA program as an isolated solution

And there is another aspect that should not be underestimated: In order to be able to take advantage of the performance gains promised by the new database technology of the in-memory platform Hana, as well as the improved options for ad-hoc reporting, analyses and simulations, a corresponding data quality is also required in service procurement – a data quality that includes more than just the aggregated totals values in SAP that are common practice. FUTURA's depth of integration also provides the decisive basis for enabling differentiated evaluations, analyses and controlling measures in the SAP system – ECC as well as in S/4HANA.

Photo credit
© maxuser/Shutterstock.com