The Journey to SAP S/4HANA: Technical Perspectives
We are often asked by our clients to assist them interpret the various roadmap materials that describe the options available to realise the journey to SAP S/4HANA. Each company has their own starting position on that journey and each company will make that journey at their own pace and, metaphorically speaking, with their own waypoints along the way.
For some companies the journey from SAP ERP to SAP S/4HANA may take place in one step, for others it will be a series of steps undertaken over a period of years. That journey for each company will be influenced by perceived benefit, budget, appetite for change, business need and wider IT strategies.
There are many considerations that need to be factored into the business case for embarking on that journey to SAP S/4HANA. From a business perspective some of those key topics are:
- What new functionality could we make use of?
- What custom functionality could we retire?
- What is the impact on our end users with a move to the Fiori user interface?
- Could we consolidate some of the systems in our SAP estate?
- How would we extract the maximum value from the investment in the S/4 HANA platform?
- How far along the journey to S/4HANA would we need to travel to meet our business needs for the short to medium term?
From an IT perspective some of those key topics are, as you might expect, more of a more technical nature:
- What deployment option is right for us? On-premise or a cloud variant?
- What are the considerations from a hardware perspective?
- What restrictions would we need to navigate around to convert our existing system from its current state to SAP S/4HANA?
In this blog we will focus on the IT perspective which I hope will give you a sense of the main general technical considerations for the journey to SAP S/4HANA.
The last few years have seen a pronounced shift to a cloud hosted Infrastructure, Platform or Software ‘as-a-Service’ model. As a result we commonly see our clients consider the implications for their business for moving from the traditional on-premise hosting model to one of these alternatives. Common themes that arise when we assist during this strategic roadmapping activity are:
- What does the customer’s general IT strategy for cloud adoption mean for SAP? Is there a strategic goal to move away from an on-premise deployment model for all applications or should certain enterprise applications, such as SAP, be ring-fenced and remain deployed in an on-premise model?
- Does the customer want to invest in their own data centres and application support or do they want to subscribe to an Infrastructure-as-a-Service, Platform-as-a-Service or Software-as-a-Service model where they outsource the management of the hardware, software and potentially also the application to a third party?
- Are there internal security policies that would prevent the storage of certain data in third party data centres?
- What are the costs associated with a cloud hosted model and how do these compare to an on-premise model? Do the potential benefits of a fixed price managed service approach outweigh those associated with an on-premise model?
- What would be the impact for the customer’s non-SAP systems if they migrated their SAP estate to a cloud hosted model? What happens to the interfaces between the SAP systems and the non-SAP systems?
As we assist with the evaluation of these points we also need to consider the various deployment options that are available for SAP S/4HANA and the characteristics associated with each of those options. Here we provide those key characteristics for the four deployment options:
The various deployment options for SAP S/4HANA need to be evaluated against the customers own IT strategy, budget constraints and configuration requirements. As a consultancy we are spending increasing amounts of our time providing a viewpoint from a trusted third-party to our customers as they look to firm up on their future path to deploying SAP S/4HANA.
For those customers who plan to migrate to an Infrastructure-as-a-Service, Platform-as-a-Service or Software-as-a-Service offering the question of which hardware to provision for SAP S/4HANA sits with the third party providing that service. As such the design, deployment and management of the infrastructure will likely be invisible to the customer and the management of the service will be driven by various service level agreements with the infrastructure, platform or software service provider.
For those customers that are considering remaining with an on-premise deployment model the opening question is almost always the same: What hardware do I need to operate SAP HANA?
SAP offer two distinct approaches to providing hardware for the SAP HANA platform. The first is to engage with a hardware partner to specify and deploy hardware appliances that consist of pre-configured hardware and pre-installed software. The appliances consist of CPU, RAM, storage, networking components and pre-installed SAP HANA platform software which are all certified to meet the standards required for providing an environment on which to operate the SAP HANA platform. The pre-configured nature of the appliances and the support provided by SAP and the various hardware partners is an advantage of this delivery model but it comes with limitations of flexibility and may require that you adapt some established IT operation practices.
An alternative, and increasingly popular method, is to use the Tailored Data Centre Integration, (TDI), approach which allows for additional flexibility within the Data Centre at the cost of some increased complexity in installing and configuring the SAP HANA platform software. You don’t have free reign under the TDI approach but you do have options to use your own preferred hardware within certain limitations.
For example, rather than utilising a single vendor approach as you may do with an appliance model you can combine a certified HANA server model from one vendor with a certified HANA Enterprise Storage solution from another vendor. It’s also possible to utilise existing network components and infrastructure and to use certified Intel Xeon E5 series CPU based servers for entry level workloads as opposed to the higher specification, and higher priced, Intel Xeon E7 or IBM Power Systems based servers. This flexibility could allow you to adopt a best of breed approach when assembling infrastructure components or it could allow you to make efficiency savings by using components already deployed in the data centre.
Deploying SAP HANA on hardware under the Tailored Data Centre Integration can be summarised as follows:
The decision to utilise pre-configured appliances or to deploy SAP HANA using the TDI approach is down to individual company requirements. Two factors that may influence the decision making are whether the organisation has continued to invest in their data centres to keep their technology current and their appetite for taking on some of the configuration and installation tasks themselves with support from their partners. SAP are making HANA more and more affordable though by offering alternative deployment options and we expect this to accelerate the uptake of SAP HANA in the short to medium term.
When we talk about the journey to SAP S/4HANA the first thing we need to consider is the starting point for that journey; i.e. what SAP ERP release, Enhancement Package and database platform are the SAP ERP systems in question currently running on. Next we should consider the strategy, are we aiming to realise a conversion to SAP S/4HANA in the short to medium term? Alternatively, do we have a longer term strategy where the intention is to lay the ground work for a future conversion at a later date? The extended length of the support window for SAP ERP 6.0 and the various Enhancement Packages means that it is in the latter position where many customers find themselves at present. Finally we also need to consider what is technically possible. A one-step approach may be desired but not technically possible, conversely, a one-step approach may be technically possible but not desired!
The journey to SAP S/4HANA therefore takes various forms. For some customers it can be considered a one-step migration and conversion process. For others, it may be a case planning preparatory activities such as converting to Unicode, splitting out a Java add-in or deploying the latest SAP ERP 6.0 Enhancement Package. It could also mean migrating the SAP ERP 6.0 application to the HANA platform to operate with a Business Suite on HANA configuration as an interim step. A further option could be converting to SAP S/4HANA Finance only and leaving the logistics modules in the SAP ERP configuration at present.
To help illustrate the various paths available we have put the following diagram together to layout the options available for realising the journey to SAP S/4HANA.
When reviewing the diagram please bear in mind the following points:
- Non-Unicode SAP ERP 6.0 systems must be converted to Unicode prior to updating to SAP ERP 6.0 Enhancement Package 8. This is due to the lack of non-Unicode support in SAP NetWeaver 7.50 on which SAP ERP 6.0 Enhancement Package 8 is based. The conversion to Unicode cannot be executed during the Enhancement Package 8 installation, it must take place prior to this.
- SAP HANA runs natively on Unicode only. The conversion to Unicode can take place during the migration to the HANA platform for Suite on HANA configurations. The conversion to Unicode must take place prior to the conversion to S/4HANA however; it is not possible to convert a non-Unicode system to Unicode during the migration and conversion to S/4HANA. This is due to the lack of non-Unicode support in SAP NetWeaver 7.50 on which SAP S/4HANA is based.
- Java Add-in systems within dual stack ABAP+Java SAP ERP 6.0 systems must be split into their own dedicated Java stack prior to updating to SAP ERP 6.0 Enhancement Package 7. SAP provide the Java stack split tool to support the process of exporting an existing Java add-in and importing the data to a new dedicated Java stack. The tool also provides functionality to remove the Java add-in from the source system once the migration to a dedicated Java stack is complete.
- SAP NetWeaver hub systems that interoperate with SAP Business Suite systems should be upgraded to a minimum of SAP NetWeaver 7.30 prior to upgrading the SAP Business Suite applications to the versions defined in Business Suite 7i2013. The definition of Business Suite 7i2013 includes SAP ERP 6 Enhancement Package 7, SAP SRM 7 Enhancement Package 3 and SAP CRM 7 Enhancement Package 3.
- SAP ERP 6.0 with Enhancement Package 6 is the minimum release on which you can run the SAP ERP element of SAP Business Suite on the HANA platform. SAP recommend SAP ERP 6.0 Enhancement Package 8 as a minimum release for operating SAP Suite on HANA.
- SAP ERP Releases prior to SAP ERP 6.0 cannot be converted to SAP S/4HANA in one step. An intermediate upgrade to SAP ERP 6.0 with an optional Enhancement Package installation must be executed as a first step and it may also be necessary to convert to Unicode for any system that are SAP R/3 4.6C or older.
- Data model conversion and data migration activities to move the data to the new simplified structures are required after the technical process of converting the Finance applications to SAP S/4HANA Finance.
- Data model conversion and data migration activities to move the data to the new simplified structures are required after the technical process of converting SAP ERP 6.0 to SAP S/4HANA.
With an extended support window in place for SAP ERP 6.0 many SAP customers find themselves in a position where they are contemplating their journey to SAP S/4HANA without the pressure of a looming end-of-life date for their existing SAP ERP applications. Many customers are working to establish how far along that journey they need to travel to realise their objectives in the short to medium term and at what point the leap to the SAP S/4HANA platform should be made.
The performance benefits of the SAP HANA platform are well documented and it’s clear that S/4HANA is going to be the focus of innovation for SAP in the years ahead. Coupling those facts to the continually increasing performance and value for money of IT infrastructure and we expect to see increasing number of customers begin to seriously evaluate the case for converting to S/4HANA.
I hope this blog gives some useful pointers to some of the technical considerations when considering that journey to S/4HANA. If you’d like to know more, please get in touch.