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 2027. We shed light on what consequences the SAP S/4HANA strategy will have on the processing of construction and services.
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, it should not be overlooked that not all GUI functions are transferred to a Fiori app. This has far-reaching consequences especially for service procurement.
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 service specifications in the context of processing construction services. These multi-level service specifications 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) service specifications, which are exchanged in Germany via the established GAEB format.
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 service specifications 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 service specifications, 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 service specifications.
In today’s practice, complex service specifications are therefore created outside of SAP, namely in AVA (tendering, awarding, billing) programs, and are also put out to tender outside of SAP. The order value resulting from the tender is then only posted in SAP as an aggregated total value in a purchase order or purchase order item: Create 1 piece (SU) of manufacturing plant, 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 service specifications.
This means, what is maintained in the AVA program (e. g. measurements, partial 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.
Construction services and SAP have always been two different worlds. In Germany, construction services are inevitably linked to the creation and billing of service specifications. The structure of service specifications is defined by the GAEB format and standardized for exchange. This means that anyone who has to deal with service specifications, whether in planning (preparation of specifications, cost estimation), purchasing ( tendering, ordering) or billing (measurement, recording of services), has to rely on the simple handling of service specifications.
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 service specifications 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 service specifications 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.
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 service specifications, 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.
Picture credit
© maxuser/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.
88 percent of companies expect higher data quality as a result of the introduction of S/4HANA, according to the current Lünendonk Study 2021. How can procurement around Complex Services under S/4HANA in particular meet this expectation? In a webinar, we will show you how to put an end to workarounds.
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?
