By now, just about everyone has probably heard of the topic, a few dare to go on the offensive, and many others wait skeptically. Why SAP S/4HANA is causing such skepticism, and how to tackle the issue.
(Disclaimer: the processes and considerations on the part of SAP regarding the database history are pure conjecture on my part, not that anyone gets the idea that these are official SAP statements).
Long, long time ago
Those who have been around in the SAP cosmos for a while will have come across it sooner or later: SAP’s database dilemma. SAP has been the market leader for enterprise software for a very long time. Starting with an unusual idea of some former IBM employees, it has developed over the decades into a global corporation with over 80,000 employees, embedded in an extensive partner network and a not inconsiderable turnover.
But like many other companies, SAP had to ask itself in the course of its triumphant march whether it would prefer to have certain parts of the value chain as core competencies in-house. In other words, SAP’s most popular database came from its biggest rival in the enterprise software market, Oracle.
So in 2003, the MySQL database, which was very popular on the open source market at the time, was purchased, renamed SAP MaxDB and given away to customers as the new SAP database platform. Gradually, a customer base was formed. Unfortunately, however, the low costs, good usability and simple administration were not the big issue for most customers. Apparently, stability and performance were what counted most, especially for medium to large customers, and these were still offered by Oracle (and IBM, but they were simply a bit too late). And so Oracle remained unchallenged at the top, with Microsoft, IBM and MaxDB sharing the remaining third of the pie.
SAP acted promptly and landed a surprisingly well-guarded coup in 2010 – they further developed established solutions such as TREX and MaxDB LiveCache and were suddenly functionally a big step ahead of Oracle: an in-memory database called SAP HANA was born. Customers saw it with interest, but the vast majority of customers could not score much on the performance side with the normal SAP ERP Business Suite on HANA without further optimization. Anything else would have involved development effort.
So on to the next stage, an application whose code specifically targets the column-oriented, in-memory benefits of SAP HANA, plus a new operating concept and some interesting SAP cloud services – S/4HANA was launched in 2015. Again, they started in the finance area with S/4HANA Finance 1503 (an ERP add-on for SAP HANA customers), but this strand will probably not be continued sooner or later. So customers can fully focus on their SAP S/4HANA transformation, because from SAP’s point of view, the good old SAP Business Suite will be taken out of mainstream maintenance by 2025 (in the meantime extended to 2027).
What the farmer doesn’t know
This sends a clear signal. After all, SAP S/4HANA is not just any follow-up release of ERP Business Suite either, even if the purely technical change feels exactly like that (SUM ahoy). A pure upgrade project can be completed in 6-12 months, depending on the initial situation and functional requirements. No, according to SAP, SAP S/4HANA is a completely new product, and functionally this is not only reflected in new functions as usual, but also in changed and eliminated functional areas (Principle of One).
The customer first has to see whether he can still find all his functions in the system after the change. And if not, where and how he can map them. If we assume a project duration of 3 years from evaluation to go-live, then the remaining time until 2025 suddenly doesn’t sound so long. It should also be taken into account that by then virtually the entire SAP customer base will have been migrated to a new product. The challenges of this change for customers, partners, consulting firms and SAP itself are gigantic. In the coming years, it will probably be very difficult to find free capacities.
SAP customers hang their hearts and their cycles on an external software vendor, and are naturally cautious when great new products are announced. This is even more the case when it is accompanied by the discontinuation of the previous product, and when suddenly concepts like cloud scenarios for core processes become very real. You want to know where you stand and what it means to switch.
Everything is different
First, something can be disarmed. Essentially, the new product is based on the old one, and has been reworked in meaningful areas of finance and logistics. Thus, the customer willing to switch will find a large part of its functions again. By integrating SRM, SLM, and other functions, the package is even partially thicker than before. It is definitely not the case, as is sometimes heard in customer circles, that S/4HANA with 1511 could not yet do logistics; the application suite was already complete even in the first release. Exceptions to this rule are described in detail in the respective current Simplification List.
And SAP is not making arbitrary cuts here, but is focusing on the Principle-Of-One and the simplification of data structures. Functions that used to exist several times have been integrated. Aggregate and index tables can be omitted because of the higher SAP HANA performance, which of course also invalidates direct accesses to the database. Those who follow the rules and use the SAP standard need not worry much about the data model thanks to adapted FuBas and BAPIs. In addition, there are compatibility views that simulate the old structures, at least for the time being, in order to keep the adaptation effort for SAP and customers low for the time being.
The topic of cloud is also exciting, because SAP S/4HANA can be housed as an ERP product in the public cloud. This means tight maintenance cycles (hotfixes every 14 days, release upgrades every 3 months) and little customizability, but no hosting worries, seamless integration with other SAP cloud services and subscription with variable terms. As a company, you become more flexible and can focus more on your own core processes. This is certainly primarily interesting for new customers, but may also be worth a look for existing ones, depending on their priorities.
Of course, SAP S/4HANA can also be operated as usual in the private cloud (previously: hosting) or on-premise (previously: in the company’s own data center). SAP provides complementary cloud services with the Ariba partner network and the SAP SuccessFactors HCM solution, among others.
But what does it mean to move to S/4HANA? Assuming you’ve checked the Simplification List, and now know exactly which of your current processes will still work tomorrow. That leaves a few considerations you should make in preparation for a conversion project.
Effort drivers for the S/4HANA conversion
Such a conversion can quickly grow from upgrade-related to a complete business process redesign project. Essentially, the effort here lies in the evaluation, assessment and definition of the future structure of the systems, processes and functions:
- Operating model: public cloud, private cloud or on-premise (SAP HANA needs experts).
- Transition model: conversion or new construction
- Consolidation: will SAP landscapes be merged or split?
- System environment: which third-party systems must be connected, which can be omitted
- Integration of external services (SAP Ariba, SAP SuccessFactors, SAP Fieldglass, SAP concur, SAP Hybris, etc.)
- End-user connection via SAP Fiori
- Migration scenarios (migration cockpit in standard and simple versus data services in customized and complex)
Last but not least, of course, you need to think about your actual processes (list not exhaustive):
- in the functional Business Blueprint you define how your processes will look like in the future; according to this you should record, evaluate and decide:
- FI Central Finance (central FI consolidation in a S/4HANA via SAP Landscape Transformation).
- FI NewGL (mandatory)
- FI Real Estate Management (on RE-FX mandatory)
- FI Asset Management (NAA mandatory)
- FI Credit Management (FIN_FSCM_CR mandatory)
- FI Budgeting (BCS mandatory)
- FI BW /-IP /-BPC (integrated and therefore external systems obsolete)
- FI Cash Management (has been fundamentally revised)
- LOG Customer Vendor Integration (mandatory)
- LOG SRM (integrated)
- LOG SLM (integrated)
- LOG MM Catalog Procurement (new procurement solution)
- LOG Material Number to 40 digits (optional)
- IS-U Separation of ERP and SD/FI-CA (dropped)
- IS-U CIC (dropped)
- IS-U UCES (dropped)
- ..
- in the technical Business Blueprint, you define how the processes are mapped in the systems; this means the following:
- ERP release status at minimum level ERP6 (upgrade may be necessary)
- ERP is Single ABAP Stack (split may be necessary)
- Unicode basis (mandatory)
- Gateway server available for SAP Fiori (strongly recommended)
- Database already on SAP HANA (mandatory)
- S/4HANA licenses available
- Database size influences conversion duration and hardware costs (archiving if necessary)
- Standard-compliant SAP repository (simplifies conversion enormously)
- Standard-compliant SAP processes (simplifies conversion enormously)
- Process coverage in SAP versus third-party tools (the higher the benefit)
These are key factors that will influence your S/4HANA conversion. As you can see, converting to S/4HANA is no small upgrade, and the well-known recommendations for project governance apply here as well. If you are thinking about making the switch, prepare well, take time to pilot the system, and take your time evaluating your options. Every day you invest up front will save you 10 days of corrective effort in the end, according to the ever-popular Rule Of Ten. Important to note – seek close contact with the business right from the start. S/4HANA is not an IT topic, but a business topic.
That’s how it should be understood and used as an opportunity for improvement. After all, if you have to turn everything around once anyway, you might as well start thinking about it properly in terms of processes. This also distinguishes S/4HANA from the typical upgrade projects, where you are simply happy afterwards when the old processes are running again.
Good luck with that,
