(This blog post has been co-authored by Mark Chalfen and Lindsay Stanger)
SAP Fiori and SAP S/4HANA have made significant impacts on the future direction of clients’ landscapes. The two products are heavily embedded as a number of SAP Fiori apps run exclusively on SAP S/4HANA.
There is a perception amongst the current SAP customer base that all the apps available on SAP ECC will be available on S/4HANA, or that all functionality on S/4HANA has an SAP Fiori user interface. This is not yet the case, but S/4HANA does have various new apps, some of which will replace legacy ECC transactions.
Not all of the thousands of the SAP ECC transaction codes are available via SAP Fiori screens in S/4HANA on-premise yet though, but the intention is that this will be the case in a future release of S/4HANA on-premise.
To make things even more confusing, the cloud-based version of SAP S/4HANA only uses SAP Fiori screens and that is where some of this confusion stems from. S/4HANA cloud edition currently has much less of the ECC functionality than its on-premise counterpart which is why SAP has been able to make all interfaces Fiori. This is not the case for on-premise S/4HANA. Although lots of transactions have been replaced by, or have alternative Fiori apps, not all do.
This post will focus on the “on-premise” edition of SAP S/4HANA.
The reason for the differences between SAP ECC and SAP S/4HANA can be broken into the following areas:
- SAP S/4HANA is still evolving and developing, more SAP Fiori screens will be available in later releases with the intention that at some stage transaction codes be deprecated and SAP Fiori be the sole user interface.
- Some of the traditional SAP ECC transaction codes have been replaced in SAP S/4HANA.
- Some of the traditional SAP ECC transaction codes will not be part of SAP S/4HANA.
Evolving and developing
There have been two major releases for the SAP S/4HANA on-premise version. The first version has been known as SAP S/4HANA Finance, or 1503. The second, 1511, is known as the S/4HANA Enterprise Management version.
Below is a table comparing the two major releases for S/4HANA on-premise:
SAP’s stated release strategy for the on-premise version of S/4HANA is a single major release once a year and any new developments to be made with SAP Fiori UI. It would be safe to assume that within the next major release the volume of available SAP Fiori apps for SAP S/4HANA will increase.
Replaced transaction codes
As the SAP S/4HANA product evolves, the functionality will grow with it. In order to simplify the journey for customers and to ensure the final product is consistent, SAP uses a process called “the principle of 1”. Put simply, where SAP had a number of modules to perform a common process, a review has been undertaken and only one of the modules will be available within SAP S/4HANA. This therefore means that clients who use the out of scope functionality would need to adopt the new functionality. This could be part of the new system build or performed prior to the move to SAP S/4HANA. An example would be SAP FI-AR Credit Management which has been replaced with SAP FSCM Credit Management.
Not in scope for SAP Fiori within SAP S/4HANA
It is worth noting some SAP transaction codes will never be moved to SAP Fiori.
- Some of the Transaction codes could relate to SAP reports which will be consumed by the embedded analytics content within SAP S/4HANA.
- Others will be SAP configuration tcodes that will not require access via SAP Fiori as well.
How to use this information
When you start your SAP S/4HANA implementation, you will need to consider your SAP users and how they will access the new system. It is worth noting that some users will be accessing SAP S/4HANA via the traditional route which may be a portal, SAP GUI or a tool like NWBC. Some user groups will be happy and confident using the user interface that they have previously used before and the change impact here will not be that significant.
Looking at the list of available SAP Fiori apps for SAP S/4HANA in isolation can cause an issue with the final solution.
In order to digest the impact SAP Fiori could have to the user base, you first need to understand the different business roles they have. Once you have that information, you need to review if any of the transactions that you had before have been removed in SAP S/4HANA. The removed transactions could either be replaced by other SAP GUI transactions or SAP Fiori apps.
Based on these findings, it is recommended that you group the user role as a SAP GUI role or an SAP Fiori role. If there are gaps in the SAP Fiori role, additional SAP Fiori apps may need to be created. The diagram below should help visualise the process you need to undertake.
Target SAP Fiori user identification
When transitioning to S/4HANA you need to identify who will become SAP Fiori users and who will remain SAP GUI/Web Dynpro users. This is somewhat dictated by what’s available in S/4HANA on-premise, as you’ll find some transactions are entirely replaced with SAP Fiori leaving the user no choice, where others have the choice of SAP Fiori or transactions.
Some SAP Fiori apps may be beneficially used by all users regardless of their user type categorisation (Fiori or GUI). For example, My Timesheets may be a Fiori app which everyone has access to, even if they perform the majority of their functions in SAP GUI. This is because there is a visible benefit to mobilising an app like this and enabling employees to perform this task wherever they are.
It is worth noting that whilst SAP S/4HANA uses SAP Fiori, not all processes currently have SAP Fiori apps. When looking to deploy SAP S/4HANA, you need to assign business users to be either SAP Fiori users or your current UI users. Informing users that they have to perform certain core transactions via the GUI and others by SAP Fiori will be confusing and may limit the users’ appetite to use the new functionality, or may cause issues where users begin to ask “well if I have that on Fiori, why can’t I have this”. SAP Fiori is focused on User Experience and, as such, should make the users more efficient, giving them a more enjoyable and simpler journey. However, asking users to mix and match with SAP GUI and SAP Fiori is likely to cause frustration and limit the benefit which could be gained. Only where tasks are truly independent should a mix of the two be considered. For example, an employee who works solely in SAP GUI may be required to enter timesheets and he would benefit for the mobile-accessible nature of the SAP Fiori My Timesheets app to complete this task away from his desk.