Abstract: This blog post cautions against using S/4HANA Extended Cloud (formerly “Single Tenant Edition – STE”) due to negative experiences and emphasizes the importance of careful consideration before making this decision.
In BLOG “17th What is the difference between the available operating options – public cloud, single tenant cloud, on-premise system?” I took up the cudgels for SAP’s HEC (HANA Enterprise Cloud). Today, I have to formally revise and retract this due to experiences in which we have moved with the development client in our on-premise SAP system to SAP’s HEC STE (Single Tenant Edition) – now renamed S/4 HANA Extended Cloud.
Caution with the HEC STE of SAP!
The bottom line from my perspective is that SAP pre-sales probably doesn’t even know what the customer will face once they sign the contract for HEC. My customer at the time, who had one of the world’s leading IT consulting firms help him choose the future operating model for his S/4HANA environment as part of his cloud-first strategy, concluded that SAP’s HEC STE was the best he could do. SAP’s service promises were great and expectations were high for the big SAP, which, after all, is certainly best placed to run the environment for its own developed software.
When I was asked as the project manager of the S/4HANA implementation what I expected from the HEC STE, I only said that I would expect that our development client with all our work is transferred to the HEC STE and my team can continue to work in the HEC STE as in the current on-prem system without any problems from max. day 3 of the transition. This was by no means the case. On the contrary, on the day of the handover, we were handed over a rudimentarily initially installed SAP system (after all, all three instances DEV, QAS and PRD were prepared in a similarly amateurish manner). We had to spend days explaining to the SAP team that we did not want to have any Industry Solutions or Model Companies installed (due to the strong division of labor on the part of SAP, the team called in by SAP in this context at times comprised up to 10 people, which at times made communication and internal coordination on the part of SAP unbearably tough and slow).
We subsequently started with a comparison of the installed SAP SW components between our on-prem DEV and the HEC STE DEV and had the missing ones installed in the HEC STE with the help of service requests to the SAP Service Factory (I’ll come to that later), so that we could eventually transfer our work from the on-prem DEV to the HEC STE and continue working there. That took about two weeks. Later, we had to realize that not all teams could continue working in the HEC STE because basic functions of the S/4HANA system and as well as some add-ons were not executable there. As of today, these teams are still working in the on-prem system and we hope to be able to transfer their work to HEC STE at some point. Today we are talking about day 80 after the HEC STE was handed over to us.
The deficits
The following excerpt from an email that I sent (on day 50 after the HEC STE was handed over to us) on request to some of the managers involved on the SAP side may clarify the main deficits:
” … asked for a list of the deficits identified to date in the delivery and operation of the systems in the HEC STE.
Below is my eMail from last night, after the HEC STE ticket factory completely shut down our system since the night before yesterday for yesterday’s day.
The previous points I refer to in this are (not intended to be exhaustive):
1. insufficient leadership & cooperation on the part of SAP during the initial provisioning of the systems.
- Lack of clarification of the required state of the initially deployed systems, both in terms of SW components to be installed and existing system content to be transferred from OnPrem.
- Lack of clarification of IP ranges to be enabled for smooth access to the HEC STE by users and third-party systems to be connected.
- Missing clarification of required business functions; instead, two-week irritation of all parties involved to determine that we do not need any
- Missing clarification of the necessary future planned emergence of the follow-on systems QAS and PRD from DEV
2. In the course of our cooperation so far, we have discovered the following deficits, which have massively hindered us in our project work, or are still hindering us:
- During the post-installation of missing SAP SW components, it was neglected to pay attention to keeping the DEV, QAS and PRD systems in a synchronous state; this would have been done by each separate Basis team in the project without requiring a separate note; in the support within the framework of the factory approaches used by SAP, such thinking along, which should be assumed as normal, is obviously not the case; this alone has meanwhile caused us a delay in the project of at least three weeks
- PPDS live-cache not set up, although component in use; we had to do this ourselves
- ERP internal eWM communication not configured, although component was in use; had to do it ourselves
- FIORI apps not configured and still not running in HEC STE environment; we thought FIORI was part of S/4 HANA also at SAAS; we are still on this with our own resources
- The Adobe Document Server for printing forms is still not installed in the HEC STE environment, so we are not able to print, which is a big hindrance for the development; we are still working on this with our own resources
- No support in taking over the configuration documentation of the previous project in the IMG; here we are still at it with our own resources. We have also taken over this task, because SAP could not show a valid solution.
- None of the SAP add-ons we needed were installed in our systems in the HEC STE from the beginning – and even worse: none of them were whitelisted for use in the HEC STE; we still have the situation that a large part of the add-ons we needed are not whitelisted until today and are still in this obviously SAP internally very tough process.
- And as we found out, SAP uses tools for the processing of standard tasks, which are insufficiently stable and tested and yesterday just put our entire project team into incapacitation (see below)”.
Some of these grievances had not been resolved six months later. In particular, the disparity of the systems caused by the lack of synchronous installation of the SW components in DEV, QAS and PRD of the HEC STE continuously creates problems and SAP does not offer a HEC STE-compliant procedure to build the QAS and PRD system client or system copy from DEV. This procedure of cross-system client copy, which has been used in on-prem systems for decades and by means of a standard transaction that SAP has just revised and relaunched ((Remote client copy: SCC9 -> SCC9N), is not supported by SAP in the HEC with reference to risks mentioned in an OSS Note from 2002. Functioning alternatives are also not offered.
A few quotes from my customer’s IT managers based on their experience with SAP’s HEC STE actually sum up the experience well:
- “The SAP organization is not mature enough in the area of HEC operations to reliably run such a model”
- “If this condition continues, the decision to go into SAP’s HEC STE was the biggest bad decision we ever made”
Why is that?
From my perception and point of view, the shortcomings are mainly due to the following:
- SAP’s HEC STE team does not have any SAP (Basis) competence (statement of the responsible SAP manager)
-> here you would probably be better off with any other provider of such an (AZURE-) cloud based operating model, because there you get an SLA based one-stop service, which is obviously not necessary at SAP due to the structures and also cannot be compensated by a service manager of SAP, no matter how dedicated. - In the HEC STE, SAP provides the customer with pure computing power (i.e., only the sheet metal); the customer must take care of everything else himself and can select the individual basic tasks from a confusing catalog of approximately 1,200 service requests, many of which, for inexplicable reasons, cannot be performed by the customer himself, but must be ordered from the SAP Ticket Factory for a fee. However, one should not assume that the person who executes this service request on the SAP side somewhere in the world has so much know-how that he thinks along with the solution in the sense of a functioning solution. On the contrary, the majority of service requests are first returned with a nonsensical query (as is known from OSS) and time is wasted unnecessarily during processing. In addition, SAP obviously has no secure management and monitoring processes for these service requests. For example, service requests that were critical for us were simply left unprocessed for three weeks because we had assigned the wrong team to the SAP Service Factory once we entered them. Any ticket organization would have noticed and solved this within a day – but not the SAP Ticket Factory.
-> In this point, too, you would certainly be better off with another provider of a cloud-based solution, because most of them use competent and thinking resources while processing tickets. - The SAP organization as such is not agile, homogeneous, responsive and permeable enough to offer such a service to the satisfaction of the customer. After we initially had huge problems right away, we were assigned a service manager from SAP at short notice, who unquestionably did a great and dedicated job from the beginning, but was repeatedly confronted with and thwarted by the limitations of the SAP organization. Internally requested information was often quickly classified as consulting and was only to be processed after a corresponding order had been received. Thus, for many critical issues, he had to apologize for weeks in status meetings that he had not received any feedback from the responsible internal SAP department despite escalation, and often asked us to escalate the issue on the customer side so that we could move forward together. In my opinion, such an approach speaks volumes for the maturity level of the SAP organization in dealing with each other and here specifically to present itself as a homogeneous organization to its HEC customers.
-> In this point, too, one would certainly feel better off with another provider of a cloud-based solution, because many of the smaller organizations simply function better and present themselves to their customers as a homogeneous organization.
Admittedly, our own organization was also not sufficiently prepared for the step into HEC STE – but we also didn’t know what to expect in detail. And my expectation would be that the provider would take the customer by the hand in preparation for this and not just start acting albeit the horse already left the barn days ago.
CONCLUSION:
The move to SAP’s HEC STE cost us several additional man-weeks of our most qualified consultants to compensate or clean up what SAP did not deliver. Furthermore, the move caused a delay in the project schedule of several months – not to mention the frustrations for all team members. At last we still did not have a fully functional HEC STE environment for our project. For most of us it was unimaginable to go live in such a service environment!
Therefore my recommendation:
“Think very carefully about moving to S/4 HANA Extended Cloud!”
And as I said, I’m convinced that other providers can do it better.