A source told me that one of the largest SAP customers in the (ANZ) region is moving from HANA Enterprise Cloud (HEC) back to an on-premise infrastructure model. Well, this was not surprising for me as I already knew some customers in Europe also moved from HEC to on-premise or other cloud offerings, due to unexpected and unforeseen issues with the HEC model.
I am aware that the majority of the businesses still can’t simply justify the business case for HEC, and it is disappointing to see that some existing customers don’t get the expected business benefits from this model.
As a side note, a recent study showed that on average, project go-lives are delayed by around 25%, resulting in higher project costs and delayed benefits. SAP implementations have the largest gap between planned and actual delivery date. Also, only 21% of SAP projects achieve 50% or more of expected business benefits according to the same study. That means 79% of businesses do not get the VALUE they expected from their SAP investment.
With almost 10 years of hands-on experience in numerous end-to-end SAP implementations, upgrades and OS/DB migrations in both medium and large-scale landscapes I've experienced the same issues affecting businesses:
- Not having a clear strategic roadmap
- Poor project planning
- Insufficient or not clearly documented testing procedures
- Lack of expertise
- Wrong solution / technical architecture, which eventually causes delayed projects and therefore reduced ROI.
I think while the context in any particular business may be unique, the issues that plague the projects are not.
HEC, on the other hand, certainly addresses some of the priorities of a business like continuous innovation, fast deployment, agility and elasticity with a (relatively) low risk.
However, HEC comes with its own particular points-to-consider as well.
For instance, based on the HEC support model; datacentre, infrastructure, operating system and database (HANA) maintenance is delivered as part of SAP’s standard responsibility with HEC. This is probably the main reason for most businesses to move to HEC but its maintenance policy requires the scheduled maintenance activities (including database and OS updates) quite frequently.
You might think it is good to keep your systems up-to-date whenever a new update is released (it usually is) however if you are running multiple projects in a large-scale landscape, you would need to test the projects over an extended period of time. That is why you need to carefully schedule your testing cycles so they don’t conflict with the HEC maintenance policy.
This is certainly a challenge to organise and there is a risk that you may not be able to test your projects in the same environment from underlying database and infrastructure point of view. I believe HEC should be offering more flexible maintenance policy for certain and especially large customers.
Another point you need to consider is change management. It is not unusual to have some lead time for any changes however when it comes to HEC, one of the most common complaints I hear is unreasonable lead times. We are in a new fast-changing business era and speed is a competitive and strategic weapon for businesses. Fast deployment and agility should be the main advantages of HEC, so having unreasonable lead times for every single change, causes delayed projects and therefore reduced ROI.
The offshore support model and resourcing issues could be the main reasons causing extended lead times and that is certainly something SAP can easily solve!
Monitoring and alerting are part of the standard HEC service and should be taken seriously when it comes to HEC. SAP is responsible for configuring and then monitoring and alerting, to meet your business requirements. However, in some cases monitoring objects and metrics might not be configured properly or with the correct monitoring metrics, which therefore leads to inadequate monitoring and missing alerts in the systems.
Therefore, if you are moving to HEC, I would strongly recommend to be actively involved in the initial monitoring configuration along with the HEC team and make sure that you have proper monitoring sets in place for every aspect of your landscape including application, database and host level.
If you have certain processes that need to be monitoring (e.g. BW process chains, disaster recovery configuration, specific jobs) you may also need to utilize certain business monitoring processes with correct metrics.
There are other points to consider like resource planning for HEC offshore support and communication between different support teams. Though these might be customer specific cases, it would be safer to make sure you have the same people working on the infrastructure and database changes through your landscape from Development to Production systems. At the very least, make sure your changes are documented and communicated properly between all support teams so they understand all the steps to perform the change successfully.
I believe all these issues can be solved by establishing a strong engagement model, led by SAP, to ensure optimal collaboration from all parties. When customers, vendors and subcontractors are aligned and focused to deliver value, project success is a natural consequence and HEC is no exception!
What is your experience with HEC? Leave a comment below.
- SAP Managed Tags:
1 Comment
