With S/4HANA being a new product from SAP it can be confusing for existing users/customers to understand how much of their existing solution can be converted into the new world of S/4HANA. As you will see the answer to that question is “quite a lot…if you want to”.

This blog focuses on moving from On Premise ERP to the S/4HANA On Premise Edition – my next blog will cover moving to the S/4HANA Cloud Edition (much is the same but their are some key differences).

To give us a framework to work from, I have broken the solution down into the following layers :-

• User Interface
• Business Logic (SAP Delivered and Customer Modifications/Extensions)
• Database
• Interfaces

Below is a graphic that I have created to try to show the conversion impacts (grey boxes = change), and I will discuss these below.

User Interface

The biggest difference that a user will perceive when using an S/4HANA system (or seeing a demo) is the new user interface. In line with the SAP Fiori guidelines and the New-Renew-Enable User Interface Strategy, S/4HANA is accessed using the Fiori LaunchPad and has Fiori Apps for accessing both classic and new features (many new features are only available via Fiori Apps). The access is based on the concept of Business Roles, with each role having a number of Fiori Apps associated to it. In addition to the Fiori Apps, some features of the solution are available via the SAP WebGUI transaction codes, but these are accessed via Fiori LaunchPad so users have one place to access everything.

Technically you can also access these transactions directly or via SAPGUI for Windows (which could help with your initial change management efforts). However some transactions have been superseded so you can’t assume everything will work. You can review the list of superseded transaction codes in the simplification list via this link. A good example of supersede transactions are the Credit Management transaction from SD which are now replaced with the newer Finance Credit Management solution.

Owen Recommends: Start using Fiori as soon as possible in your current landscape as it will reduce the learning curve when adopting S/4HANA – see what you can use now in the Fiori App Library.

Business Logic

As you can see from the diagram SAP is doing a lot at the business logic layer of the solution, adding new features, optimizing old ones and removing features that are duplicated or redundant. To understand the impact this will have on your installation or options that you will have as you implement, you once again have to refer to the Simplification List, this will show you where things have changed and recommend what you need to do to adapt your systems. For more details from a functional perspective read this blog by Xavier Herce.

For your Custom Code, you need to understand if it will run in the S/4HANA system. To assist in this SAP has provided a Custom Code Checker that uses the Simplification List and an extract of your custom code to highlight where changes may be required. This blog give details of how this works.

In addition to remediating your existing code SAP offer a number of alternative ways to “extend” your S/4HANA system – this blog gives a good overview. The first is a new User Interface extension tool that allows fields to be moved / hidden and for new fields / logic to be added to the system (all the way to table / interface level). More complex User Interface Extensions can be achieved using the SAP HANA Cloud Platform (HCP) to extend the solution using Web-IDE, public APIs and the Fiori App extension frameworks. The HCP platform also offers a wide range of other services that can be used to develop custom business logic / apps e.g IoT framework, HANA as a Database Service, Cloud Portal, Mobile Services etc etc. Find out more about the HANA Cloud Platform at HCP.SAP.COM.

Owen Recommends: Use the Simplification List to understand the changes and try to adopt as many as you can before the switch. Examples being New general Ledger, Material Ledger and Business Partner – which are all mandatory in S/4HANA but optional in Business Suite.

Owen Recommends: Stop worrying about your custom code and start looking into what you have and separate the wheat from the chaf. Much of your code will not be run anymore, of the code left see how much is about custom transactions (which could be done via the In-app extension framework or HCP) and how much is reporting (which could be replaced with the Multi-dimensional reporting tools). Where you find key unique features, consider if they can be built-top using HCP especially if you want to use the cloud edition. Finally learn HANA Cloud Platform and understand the SAP HANA Cloud Connector – register at HCP.SAP.COM

Database

At the database level we have 2 big changes, the first is that S/4HANA only runs on SAP HANA, so if you are not a Suite on HANA customer yet, you will need to switch database platform. The second is the rethinking of the data model to remove aggregates and redundancies, that has the double impact of reducing the size of the database and increasing the simplicity of the model that helps with reporting. In what is an impressive feat of software engineering, SAP have replaced most of the aggregates / redundancies with “Compatibility Views” which are calculated on the fly at run-time, but means that most of the application code carries on running. I think this is a bit like changing the engines on a plane whilst it carries on flying !

Owen Recommends: Start to understand SAP HANA as soon as you can, if you understand the HANA Platform you will be able to do more with your S/4HANA system than those that don’t. I think a great way to do this is to get yourself a “small” 32Gb HANA instance on the HANA Cloud Platform.

Owen Recommends: Start to look at the quantity and quality of data in your existing system. Once you are on S/4HANA the quality of the data will become key to running in Real-time (straight through touch-less processing) and Future-time (predication) – look at tools like Information Steward Accelerator and Advanced Data Migration to help clean up your data and keep it clean. The size of the data stored will also be important in optimising the size of the HANA database – so look at archiving and start to consider how you might use data tiering (what needs to be in memory e.g 2-3 years) and what can be stored on disc.

Interfaces

For the on-premise version of S/4HANA the impact of the changes have been minimized with most of the integration points into and out of the system supporting compatible data structures and protocols. Some remote functions have been blacklisted and will not longer work – the Simplification List covers these. One area you will need to consider is the adoption of the 40 character Material Number as this will need to be adapted into upstream and downstream systems – if the impacts of this are large you can choose to continue to use the classic 18 character feature.

Owen Recommends: Understand the methods you are using for interfacing into and out of your system. Try to migrate these to real-time interfaces using non-blacklisted API’s. If you are not using SAP Process Orchestration for this task I recommend taking a look at the features available – this blog gives a good overview of the features available.

Conclusion

With the introduction of the new product S/4HANA (Business Suite for SAP HANA), SAP have leveraged 40 years of Enterprise Application expertise and taken the opportunity to simplify and optimize. The result being that you can convert much of your existing investment into the new S/4HANA product,  but I would strongly recommend that you take this once in a generation opportunity to do what SAP have done themselves and review what you do, how you do it and why you do it.

I will create a blog on what you need to do to transition to the S/4HANA Cloud Editions in the New Year.