Considering moving to SAP HANA?

After SAP’s Sapphire Now conference recently, many online delegates will have seen the showcased wonders of SAP HANA, with several organisations who have already undertaken the big change to HANA, promoted to share the benefits they enjoy. Around 10% of SAP customers apparently have made this change so far, according to UKISUG research at the end of last year. However, moving to HANA is a massive project that can take many months or even years and requires considerable planning, project resources, external SAP consultants as well as considerable investment.

Although Gartner do expect most companies to make this move over the next few years, there are already concerns reported that given the limited pool of capable resources today, when companies do make the move, the implementation costs could be driven up from a scarcity of skilled resources or the risks of recruiting less-experienced talent, that could result in unsuccessful implementation programs.

The reasons for delaying the move to HANA is shared by many medium sized organisations contemplating the next ten years of their business and their SAP needs. Gartner cite four main issues that end users face:

1.      Convincing business cases: many application leaders continue to struggle to identify the real business value and then build a compelling business case for adoption.

2.      Roadmap: the complexity of the SAP HANA roadmap, lack of clarity in industry-supported functions mean that customers must spend more time researching and selecting what is best for them

3.      Vertical functionality: although there are significant common functional capabilities between the older and newer products, moving to SAP HANA involves changes to vertical industry functionality and business processes.

4.      Deployment flexibility and complexity: SAP offers S/4HANA SaaS and private and public options as well as on-premises, however such large choice perpetuates the complexity and the significant resource and expertise considerations for running, managing and maintaining their system.

UK & Ireland SAP User Group chairman Paul Cooper* re-enforces this concern on the business case stating “Lots of people are struggling with the business case … when you go to see your CFO, it’s about the bottom line isn’t it and therefore, you’ve got to be able to put business case on the table because, you know, upgrades are not insignificant”. 

UKISUG published their user research on the reasons people are not moving to HANA yet. Cost, considerable change management and not seeing enough use cases were the top answers. However, two thirds of the respondents did acknowledge that they expected to move to HANA in 1 to 3 years-time and only a quarter expected it to be longer than 3 years. Very few did not expect to move to HANA at all.

Consequently, many organisations will carry on using their current pre-HANA SAP solutions and will delay their move to HANA. However, this approach if not taken carefully, can also cause other additional problems to arise.

Any current work on their existing landscapes could add further technical debt. For example, continuing to add customisations to the current older SAP landscape can further complicate any future migration approach and will certainly increase future project costs.

Users that delay their HANA software upgrade will also face issues for running their core system on old infrastructure nearing end of life. IT equipment is often purchased with an expected 5-year life and although users can take the decision to use the equipment beyond this, using old equipment beyond its natural life not only increases reliability concerns of unit failure, but also increases the maintenance costs. Break fix contracts from hardware vendors can be very expensive especially beyond five years and often is simply not cost effective when the vendor would prefer you to buy a new product not maintain the old one. Using old equipment beyond natural life, without break fix support in place, makes the whole system incredibly vulnerable to overall failure and users could endure long down-times if units fail without timely remedies in place.

One approach that offers a solution to both, is to delay the HANA upgrade, which is the more expensive and time consuming part of the SAP upgrade, but not delay the moving to cloud part of the project, to replace their tired and potentially unreliable infra-structure.

Users are not likely to purchase new equipment for an old system themselves, as it would be difficult to justify spending money on expensive equipment to run an old software solution that is likely to be upgraded anyway in the next few years and would become obsolete when that upgrade does occur. HANA systems require very high-performance SAP certified infra-structure and cannot run on non HANA equipment.

Instead a more sensible and cost effective approach is to move their old SAP system to a pay monthly cloud hosting provider that can address the risk of reliability from failing hardware and also allow the user more time to plan their move to HANA. This approach removes the worry of their old system failing to allow them more time to better understand their business needs and the potential benefits that can be gained and justified from a future SAP HANA system, when the time is right.

To learn about Opal Wave’s private and public cloud SAP Platform services, visit https://opalwave.com/sap-platform/. PaaS is ideal for users that want to manage their own HANA Apps without the costs and hassles of running the HANA middleware.

Ref: https://www.cbronline.com/news/s-4hana-adoption