21. Our recommendation based on our experience: “Hands off the HEC STE of SAP!”

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 take back this decision, based on the experience of the last few months, when we went into SAP’s HEC STE (Single Tenant Edition) with our on-premise client in the development system.

Caution with the HEC STE of SAP

The bottom line from my point of view is that SAP Pre-Sales probably doesn’t even know what the customer will get once he has signed the contract for HEC. My current customer, who, as part of his Cloud First strategy, has been supported by one of the world’s leading IT consulting firms in choosing the future operating model for his S/4HANA environment, has concluded that SAP’s HEC STE is the best thing he can do. SAP’s service promises were great and expectations were high for the large SAP, which is certainly best able to operate the environment for its own developed software.

When I was asked as project manager of the S/4HANA implementation what I expected from HEC STE, I only said that I would expect that our development client would be transferred to HEC STE with all our work and that my team would be able to continue working without any problems from max. day 3 of the transition in HEC STE as in the current on-prem system. This was by no means the case. 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 the same amateurish way), had to spend days explaining to the SAP team that we did not want to have any Industry Solutions or Model Companies installed (the team called in by SAP in this context sometimes comprised up to 10 people due to the strong division of labour on the SAP side, which made communication and internal coordination on the SAP side unbearably slow and tough at times).

We then began to compare the installed SAP software components between our On-Prem DEV and the HEC STE DEV, and had the missing components 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 at some point transfer our work from the On-Prem DEV to the HEC STE and continue working there – this took about and 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 some add-ons were not executable there; these teams are still working in the On-Prem system today and we hope to be able to transfer their work to the HEC STE at some point – today we are talking about day 80 after the handover of the HEC STE to us.

 

The deficits

The following extract e-mail, which I sent to some of the managers involved on the SAP side at the request of some of the involved managers about one month ago (day 50 after the handover of the HEC STE to us), may illustrate the essential deficits:

“…asked for a list of the deficits in the delivery and operation of the systems in HEC STE that have been identified to date:
Below is my email from last night, after the HEC STE Ticket-Factory completely paralyzed our system for the day before yesterday evening.

The previous points I am referring to in this reference are (without claiming to be complete):

1. Insufficient leadership & cooperation on the part of SAP in the initial deployment of the systems.

• Lack of clarification of the required status of the initially provided systems, both in terms of SW components to be installed and existing system contents to be taken over from OnPrem
• Missing clarification of IP ranges to be enabled for smooth access to the HEC STE by users and third party systems to be connected
• Lack of clarification of required business functions; instead, two weeks of irritation of all parties involved to find out that we do not need any
• Lack of clarification of the necessary future planned development of the follow-up systems QAS and PRD from DEV

2. in the course of our cooperation so far, we have identified the following deficits which have hindered or still hinder us massively in our project work.

• During the subsequent installation of missing SAP software components, we neglected to ensure that the DEV, QAS and PRD systems were kept in a synchronous state; this would have been done by each Basis team in the project without requiring a separate note; in the case of the support within the framework of the factory approaches used by SAP, this kind of thinking, which should be assumed to be normal, is obviously not the case; this alone has now brought 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 it ourselves
• ERP internal eWM communication not configured, although component was in use; we had to do it ourselves
• FIORI apps not configured and still not executable in the HEC STE environment; we thought FIORI was a part of the S/4 HANA also for SAAS; here we are still working with our own resources
• The Adobe Document Server for the printing of the forms is not yet installed in HEC STE, so we are not able to print, which is very hindering for the development; here we are still working with our own resources
• No support in taking over the configuration documentation of the previous project in the IMG; we are still working on this with our own resources. We also took over this task because SAP could not provide a valid solution
• None of the SAP add-ons we need have been installed in our systems in HEC STE from the beginning – and even worse: none of them has been ge-whitelisted for use in HEC STE; we still have the situation that a large part of the add-ons we need are not whitelisted and are still in this obviously SAP-internally very tough process
• And as we have found out, SAP uses tools for processing standard tasks that are insufficiently stable and tested and yesterday just put our entire project team on disability (see below)”.

Some of these shortcomings have still not been resolved, in particular that the inequality of the systems caused by the lack of synchronous installation of the SW components in DEV, QAS and PRD of the HEC STE constantly creates problems and that SAP still does not offer a HEC STE-supported procedure to build the QAS and PRD system using a copy of our Golden Client from DEV. This procedure, the cross-system client copy, which has been used for years in on-prem systems 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 HEC, with reference to risks mentioned in an OSS Note from 2002 – but functioning alternatives are not offered either.

A few quotes from my customer’s IT managers based on their experiences with SAP’s HEC STE summarize the experience well:

1. “The SAP organization is not mature enough in the area of HEC operations to reliably operate such a model”.
2. “if this state of affairs continues, the decision to go to SAP’s HEC STE was the biggest wrong decision we ever made”.

 

Why is that?

From my perception and point of view, the shortcomings are essentially due to the following:

• The HEC STE team of SAP has no 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 cannot be compensated by any dedicated service manager of SAP
• At HEC STE, SAP provides the customer with pure computing power (i.e. only the sheet metal); the customer has to take care of everything else himself and can select the individual basic tasks from a confusing catalogue of approx. 1,400 service requests, many of which, for inexplicable reasons, cannot be carried out by the customer himself but have to be ordered from SAP Ticket Factory for a fee. However, it is not possible to assume that the person who executes this service request from SAP anywhere in the world has enough know-how to be able to think along with the customer to create a functioning solution. In fact, the majority of service requests are first returned with a nonsensical query (as we know it from OSS) and unnecessary time is wasted in processing. In addition, SAP obviously does not have any secure management and monitoring processes for these service requests – for example, critical service requests for us simply fell through for three weeks because we had assigned the wrong team to the SAP Service Factory when they were entered – any in-house ticket organization would probably have noticed and resolved this within a day – not so the SAP Ticket Factory.
  -> In this point, too, you would be in better hands with another provider of a cloud based solution, because most of them use competent and thoughtful resources to process tickets
• The SAP organization as such is not agile, homogeneous, responsive and permeable enough to provide such a service to the satisfaction of the customer. After we immediately had huge problems in the beginning, we were assigned a service manager from SAP at short notice, who undoubtedly did a great and dedicated job from the very beginning, but who was always confronted with the limits of the SAP organization and was slowed down by them – information requested internally was often quickly classified as consulting and should only be processed after a corresponding order had been placed. For weeks he had to apologize in status meetings for many critical issues by saying that he had not received any feedback from the responsible internal department of SAP despite the escalation and often asked us to escalate the issue on the customer side so that we could move forward together – such a procedure speaks volumes in my opinion for the maturity of the SAP organization in dealing with each other and especially in presenting itself as a homogeneous organization to its HEC customers.
  -> In this respect, too, you would certainly feel more at home 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.

We have just decided that, in view of our planned go-live in early 2021, it is too late for us to change the operating model again now and remain in SAP’s HEC STE. However, SAP will still have to change a great deal so that the project management can confidently recommend this operating model as suitable for productive operation – currently perhaps our greatest go-live risk. Admittedly, our own organization was not sufficiently prepared for the step into HEC STE – however, we did not know what to expect in detail, and my expectation is that the provider will take the customer by the hand in preparation for this and will not start to act only when the horse already left the barn days ago.

 

CONCLUSION:

The step into SAP’s HEC STE has cost us several additional man-days of our most qualified consultants to compensate for what SAP did not do, or to clean up. Furthermore, a delay in the project plan of several weeks, not to mention the frustrations for all team members. As of today, we still do not have a fully functional HEC STE environment for our project, nor any idea how to securely build the subsequent systems … and we get the cold horror of the thought of going productive in such a service environment!

Therefore my recommendation:

“Hands off the HEC STE of SAP!”

And as I said, I am convinced that other providers can do this better, even if not as SAAS (Software As A Service), on which SAP has a quasi monopoly in this case, but as IAAS (Infrastructure As A Service), where the SAP licensing issue still has to be solved separately … and after all that, The additional charges that SAP has to make because of the situation, because you’re on the drip, I’m not sure whether an IAAS solution with a competent and agile partner would not also lead to a lower TCO (Total Cost of Ownership).

PS: the inclined reader of this blog may now also understand what has kept me from continuing to write this blog in the past months … and unfortunately it is still not completely solved.