Abstract: The blog post clarifies that there is no clear SAP standard in S/4HANA and therefore recommends establishing an internal definition to avoid misunderstandings and create uniform processes. To define the SAP standard can help optimize business processes and facilitate the transition to S/4HANA.
As was made clear in the previous article on operating options, and as every IT manager is certainly very aware of today, the trend towards using IT solutions is moving more and more in the direction of usage-based payment, i.e. towards subscription systems. Infrastructure and computing power should no longer be kept “in stock” in one’s own computer centre. Rather, we want to pay only for the service we actually use, and the use/non-use of functions and quantity structures should be quickly scalable and adaptable as required. And this is precisely one of the primary benefits of cloud-based solutions – the so-called SAAS solutions (Software as a Service).
The subscription is in vogue
Even if many decision-makers believe that these do not yet have the level of maturity or offer the flexibility and security that is desired, this trend is certainly unstoppable. We can see this in a number of successful subscription-based business models, also outside of IT, which are replacing or overtaking established business models, sometimes at a rapid pace (see also the comments in “Subscribed” by Tien Tzuo/Gabe Weisert).
Equipped for the move to the cloud?
For our new introduction of S/4HANA, this means that we should design the system in such a way that it is open for later operation in the cloud and is not blocked by the solutions we have implemented. The standard objectives from the SAP R/3 projects “we implement SAP in the standard” or “we do not make any modifications” are therefore no longer sufficient, even if the term “modifications” is clearly specified in too much detail. A much finer distinction is necessary, and it should be determined at an early stage in the project whether the future S/4HANA solution should be ready for the move to the cloud – even if this step is not taken right now. And if so, for the Multi Tenant Edition or for the Single Tenant Edition. A corresponding classification of the various expansion options and the adjustments permitted in the respective solutions can be found in this presentation.
But beware:
Handle it restrictively! A single yellow classification of your extensions means that the solution can no longer be operated in the Multi Tenant Edition. And a single red classification of your enhancements means that the solution can no longer be operated in the Single Tenant Edition either – so ergo, at least with the current offering (with SAP as operator), is no longer cloud-ready.
However, the business area of SAAS solutions for S/4HANA is still comparatively young, and it is to be expected that there is still a lot to do. And perhaps the currently valid rules described here will be softened further at some point and thus the possibilities for adapting S/4HANA solutions operated in the cloud will be expanded. So let’s follow the development closely.