SAP S/4HANA 15/11 – Are you ready?
I have just come back from three full days in Walldorf taking a deep dive into the new SAP S/4HANA product. It was a no-holds barred approach with SAP happy to show the solution as it currently is, as well as providing insight into the future direction. A big thank you must go to Sven Denecken for arranging the event – and a slightly larger one to the team that supported us throughout our journey.
Let’s start at the beginning
If you did not already know SAP S/4HANA is a new product. It is new in many senses of the word new. New as in the latest ERP offering, the go-to version for SAP. New as in brand-new in terms of the content and the way the solution has been assembled. Therefore the first key take-away to share is there is no Upgrade to move to SAP S/4HANA. System conversion, or landscape transformation are the processes you will need to follow to move from your current SAP ERP landscape. SAP ERP customers’ have been spoilt with endless upgrades to consume new functionality via Enhancement Packages. The concept of an upgrade is to take your full ERP solution, and add the latest functionality and support packs. There is little effort aimed at cleaning up the current ERP solution and removing redundant code or processes. Moving to SAP S/4HANA will enable customers to stop and consider the state of their current landscape and create a cleansed ERP environment moving forward.
New tool with a new UI
There has been a real fanfare around SAP Fiori and the benefits it provides. SAP S/4HANA has a Fiori front end and significant investment has gone into this. Assuming we are talking about the On-Premise version of SAP S/4HANA (I will cover off cloud later) it is worth highlighting that currently the full solution cannot be consumed solely by SAP Fiori. From the engagements I have had with customers who are moving to SAP S/4HANA there is a real requirement to keep the SAP Gui screens (for the short term). This is primarily down to the change management impact of moving tens of thousands of users to a new way of working. Some of the Fiori tiles within the Launchpad are not actual Fiori apps, but take the user to the Browser version of the Gui. Again this to me is not a big issue. The real benefit of Fiori is to simplify processes. It is worth noting that, SAP Fiori is not a new way to consume SAP transaction codes, Fiori provides the user a simplified user experience to perform their key tasks. The beautiful UI paired with the reduction of key strokes is what makes the full solution stand out. Where SAP exceeds expectations is the way Fiori tiles consume embedded analytics. Keeping the user in a single place and providing the user with all of the relevant information to make the right decision is worlds apart from the current status quo, of moving from spreadsheets, reporting tools and various SAP ERP transaction codes. Over time the full user base will naturally migrate to a full SAP Fiori front end, however the current solution provided by SAP will provide the ability to move users into SAP Fiori at the pace the customer sets.
New methodology – Activate
SAP has released a new methodology to implement SAP S/4HANA. The core concepts are based on successfully implementing true Cloud products. SAP has focused on best practices to perform the initial configuration set up. The tools beneath the methodology are slick and easy to use. Where customers want to review the full scope of SAP S/4HANA running a proof of concept with best practice configuration for defined business processes will provide a good overview of the capabilities of the system (and restrictions). The use of guided configuration will speed up implementations, and there is the ability to make additional changes after the initial build. For those functional consultants who have spent large chunks of their career within the SAP IMG – don’t fear it has not disappeared (within the On premise version) the new tools update the core steps within the IMG, and you have the ability to update it with your own values. One first impression the tools are great and will be a real help to net new customers (customers who are starting from a clean S/4HANA environment) who are moving into SAP S/4HANA. Customers who are moving to SAP S/4HANA via a system conversion will not be able to make use of some of these tools and the associated methodologies. It feels like some current SAP ERP customers will look to re-implement to SAP S/4HANA to benefit from the new functionality and the ability to remove redundant code and configuration.
It is a Cloud tool
It is worth noting that there are two SAP S/4HANA version, the On-Premise version and the Cloud edition (there are three deployment options here which actually means there are three cloud editions). Whilst they are both called SAP S/4HANA there are some significant differences. Not all of the On-Premise functionality is available in the cloud version. The cloud version does not have any SAP Gui screens whereas the On-premise version does. Keeping with SAP’s Cloud first strategy, new functionality is released in the Cloud first and then to the On-premise version. The Cloud will have quarterly releases, and the On-premise version will have annual releases (there are feature support packs that will be released during the year for the On-premise version). The Cloud version does not use ABAP, whereas the On-premise version does. The ability to customise is heavily restricted (although still possible) in the Cloud edition whereas there are no restrictions within the On-Premise version.
Where to start
SAP has created a number of tools to help you review SAP S/4HANA 1511 so you can understand what you would need to do to fully benefit from the new product. The Maintenance Planner tool will enable you to see if there are some restrictions for you, and the Simplification items list will provide a list of items that need to either be activated prior to moving to SAP S/4HANA or data conversions will be required.custom code extractor will check your current custom code and show what needs to be changed to run on SAP S/4HANA. There are free trials of the solution so you can explore the new functionality in your own time.
The SAP S/4HANA tool has significantly grown from its first version (Simple Finance which is now SAP S/4HANA Finance). The functionality has rapidly grown and has expanded. SAP has provided a number of new tools to help customers understand the new tool and understand the best approach to deploy the solution at the right time with the right scope. The interest from customers feels like it is at an unprecedented level. The product is far from complete, but my key takeaway from my time is that the team are fully focused to make this a massive success for SAP’s customers and in turn for SAP.
Excellent blog Mark, been some time since you were able find time for blog 🙂 🙂
Your point on Activate and what it means for existing customer migrating to S/4 is thought provoking.
Question is what would justify re-implementation ( and use methodology tool + activate) or just migrate and use the new features where applicable.
I think re-implementations will be more popular that pepole initially think.
The ability to cleanse an environment and remove unrequired code, configuration and data.
Within Activate there is content lifecycle management. This can only be used/ achieved if the full processes within Activate are achieved. If a client sees the move to S/4HANA as a 10-15 investment then a clean start will be more attractive.
Having spend the days in Walldorf too and hearing SAPs vision, I fully agree with Mark. In effect, both customers I work for have decided to go for a green field.
Customers are sick and tired of dragging along custom code and no single customization (think 10s of order types doing the same thing, a multitude of double/triple vendor numbers, the scars of an SLO project or two, well you name it).
In my opinion, there is one downside though and that is that the adoptation of S/4 by the market will not be as fast as hoped for by SAP. By far not every customer is ready to rigurlously and agressively clean house imo.
Thanks for the feedback and the kudos to the team. One quick correction though: We have ONE codeline, but two deployment models - on prem and cloud and yes they differ.
Fact - we develop from one (Infinity) codeline, from there we "package" every quarter into the cloud editions, every 9-12 months as on prem.
This is actually enabling us to decide flexibly what feature/function we want to offer in cloud - as there on prem is always the superset and has more functionality. And again, restriciton is as in THE CLOUD you accept standardization, so we do so to enable even faster innovation as in on prem.
Changes made. - thanks again
one correction from my side. You wrote: "The Cloud version does not use ABAP ".
This is not true. You can also create ABAP based extensions in the cloud.
Find more information in our extensibility white paper:
S/4HANA Extensibility – The new White Paper
Thanks for sharing Mark, nice 3 day journey by the sound of it.
Agree that regardless of whether the endpoint transaction is a SAP Fiori, SAP WebDynpro, Lumira or other it is a beneficial user experience to have them all available from the launchpad.
With regard to "the current solution provided by SAP will provide the ability to move users into SAP Fiori at the pace the customer sets", no so clear cut.
The sheer development effort it will take to break down traditional GUI based transactions into more persona targeted, smaller Fiori processes is huge, plus that of denormalising data models to really take advantage of the power of HANA, I think this pace is very much set by how quickly SAP can achieve this.
As attractive as a greenfield site is, many clients cannot throw away custom code, the business would be up in arms about loss of functionality brought about by many business requirements over the years.
Moving to an S/4 core will probably not bring performance benefit for SAP WebDynpro transactions due to the way these floorplans buffer data, but its a great platform for the future I have no doubt.
I'm looking forward to hands-on myself in performing migrations, to validate the migration documents against the truth.
Roll on simplified data models and more Fiori apps!
Hi John Paul
My view is that some customers might want to jump full into SAP Fiori and with a smaller user base. Others might want a slower journey to a fiori based solution. Some might have users who "Love" SAPGui.
In terms of the custom code - not all custom code is bad, some will be exceptional. The concept is to remove the unwanted code to make it easier to use in the future, upgrades and so on.
You say in no uncertain terms at the start of your blog that there is no upgrade path from ECC 6.0 to S/4 HANA. This message must be being broadcast far and wide from assorted sources as I have had many people asking me what this means.
When people hear that (no upgrade path) they presume that the only way to move from an existing implementation to S/4 HANA is a greenfield implementation i.e. start again just as if you were doing an ERP implementation for the first time. Please correct me if I am wrong but I don't think this is the case. Rightly or wrongly that is the impression that phrase gives people.
If you "upgrade" by means of a 'system conversion" or some other term, then I think many people will struggle to understand the difference between an upgrade - where programs and data elements and the like are added, changed and deleted, and the database tables exported and imported back in a different form - with a system conversion which presumably does the same sort of thing.
I also chuckle at the idea that SAP customers have been "spoilt" with the current upgrade process (and enhancement pack installation is an upgrade in that it takes just as much time and effort, whatever SAP may say in it's marketing). I have seen upgrade projects take a year from inception to completion, even if the actual technical bit can be done over a long weekend.
To paraphrase Monty Python it is like saying "your previous upgrades have been like living in shoebox in middle of road. Luxury! Form now on when you want to upgrade your SAP service delivery manager will murder you in cold blood and dance around on your grave singing Hallelujah!".
I am all too aware of the fact that 60% to 80% of custom code is unused and can well do with getting removed, but no-one ever has the time. The idea is fine, wonderful in fact, but even if you were forced to do this when moving to S/4 HANA on premise (I gather you cannot migrate your 20 years of custom ABAP development objects to the cloud version) what is to stop the exact same thing happening again in the new system i.e. gradual build up of unused objects?
I have been waiting to hear from a company that has made the move to S/4 HANA - specifically I am interested in how they approached all the Z objects that every single SAP customer has.
Even more interesting would be an existing customer that moved to the cloud version and ditched all their Z objects. As of about three months ago some high up in SAP noted that thus far 100% of existing customer migrations to S/4 HANA had been to the on-premise version, and none to the cloud version as at that time.
I wonder if in the interim one or two companies have broken the mould and converted from an on-premise ECC 6.0 system to a cloud based (code wise) S/4 HANA system?
Happy New Year to you.
You have spotted the under tone around this point. SAP S/4HANA is a different product compared to SAP Business Suite and therefore there is no upgrade as you are technically moving to a new product line.
The system conversion will have the same attributes as your traditional upgrade as well as the database conversion to SAP HANA.
In terms of moving from ECC 4.7 to ECC 6 - yes some of these projects can take some time - however the reason for the extra time will be the complexity of the base solution.
I am sure there will be some customers who will keep their redudant custom code whilst moving to SAP S/4HANA.
What is interesting is that out of the early adopters to S/4HANA more customers are performing clean installs rather than the system conversion route.
I will let SAP respond with some figures around their Cloud version .
Regarding the terms:
Regarding Custom Code
Independent of that our impression is that even the big customers are currently re-considering their custom code. The willingness to adapt (remove not used parts, going to released interfaces …) is higher than the years before.
First of all, many thanks for getting back to me.
I am very happy to hear that customers are getting around to analysing and removing unused custom code. I went to a speech on that subject at TECHED and SAP gives some wonderful tools, the process is actually very easy, but as I said, traditionally many companies have been "too busy" to get around to this, notwithstanding that it costs them more time in the long run to leave unused code in place. Penny wise, pounds foolish, as we say in the UK.
Of course, now someone from SAP has responded, I have bucket loads more questions for you to answer, if you would be so kind.
I mentioned some months back someone fairly high up in SAP said in an interview that thus far 100% of S/4 HANA conversions (not new customers but existing customers moving from ECC 6.0) had chosen the on-premise version. Do you know if this is still the case, or have any existing customers migrated to the non-on-premise cloudy version of S/4 HANA with the quarterly updates?
Lastly just to be 100% sure - support ends for the Business Suite in 2025. Is the idea that by, say, 2035, all existing customers have migrated to S/4 HANA, either on-premise or in the cloud?
That may sound a silly question as the answer is obviously yes (I presume) but I need to be sure. There are some things you just need to keep saying until people get the message.
Does this also mean that by 2023 not only ECC but all it's business suite friends like CRM, SRM and the like, will be living in the last days of the dinosaurs?
That is, after 2025 there will be no new functionality to any of these products, they will all have reached end of life, and join the likes of 4.7 and 4.6C? All that previous functionality will henceforth be handled by the S/4 HANA enterprise management or whatever the official name of the replacement product for the business suite is.
Does BW count as part of the business suite? Will that reach end of life in 2025 also? I would presume so based on the idea that under HANA you can have analytics in the same system as transactions with no adverse effects.
I will let the team from SAP confirm this - but the 2025 does not mean after that the world ends.
The 2025 was a date far in the future to provide current Business Suite customers confidence in their product. Historically there was a 5 + 2 support agreement for SAP products - so this is well beyond that.
BW is not part of the business suite - and will continue, there will always be the need to have no SAP data brought into a data warehouse
I´m not from the marketing department and not someone fairly high up in SAP, but my two cents regarding S4 adoption.
My impression is that S/4HANA is really well-received and that the move to S/4HANA is for the vast majority of the current SAP Business Suite customers a strategic topic they are thinking about. The customers where I was involved in (German, European customers - the big ones) have detailed plans about the S/4HANA on-premise edition. But even within these group of customers the move to the cloud is a strategic topic (then as step 2 or three).
Yes there are customer going into the S4 Cloud. I´m currently not so deeply involved in this area, but I assume that there will be references published in the S4 SCN soon.
Hi Joachim Rees,
I have installed m Net weaver 7.5 ABAP system on HANA base,after this, how to convert to S4HANA, which add-on i need to install in SAP or HANA database.I got below SPS in Net weaver 7.5 ABAP system,
I am not able to see S4CORE component in the list and not able to find the add-on in service marketplace, we have a license for S4HANA also.
Please guide me for this installation.
Thank you in advance.
S4 on hana works only on erp. what you have installed is netweaver.