Golden Rules for SAP Suite on HANA & S/4HANA Migrations

SAP S/4HANA is a creative next-generation ERP suite of SAP, which is explicitly designed for in-memory computing. It provides an adapted, consumer-grade user experience with SAP FIORI without any concern about the industry or business size. It also helps to drive immediate value to the business across all lines. With the help of SAP HANA in-memory platform, the SAP developers have prudently personalized the solution to meet the requirements and challenges of the digital economy. Along with the innovative processes, the companies can improve the existing methods to declare their advantage in the digital struggle.

Learn  SAP S/4HANA Simple Finance from Industry Experts

Depending on the needs of the individuals, SAP S/4HANA can be deployed either on the cloud platform or in the on-premise platform. The on-premise deployment option, provide you with a significant amount of flexibility and control, whereas with the help of a cloud platform you can deploy with a lower total cost of ownership quickly. SAP S/4HANA has been developed to empower your business to transform.  In SAP S/4HANA the processes can run more quickly, with the help of real-time analytics the businesses can take more accurate and better decisions, and also it offers an enhanced user experience for your team. On the other hand, the SAP HANA database provides you unbeatable speed and performance, that allows jobs and transactions to run in an adequate time frame. The predictive engine of SAP HANA offers the businesses the different ways to work by automating various multifaceted calculations and enhancing the accuracy around the decision making. When these critical areas of the process are combined, it provides the organization with the relevant benefits.

Since the last year, the number of customers who are adopting suite on HANA is increasing. There has been some skills transfer-ability from BW to SAP Suite migrations, and also there are specific differences. This article presents some excellent rules and guidelines for migration toward the SAP HANA and S/4HANA.

1. Define the scope of the project: 

It is required to define the project’s scope to migrate towards the SAP S/4HANA or suite on HANA. Most of the clients are looking for a technical migration initially on SAP S/4HANA or HANA suite. Then perform the code alterations and start S/4HANA extensions. The necessary technical migration activities have to be covered. If it is required, then the customer will move towards the Unicode conversion and upgrade to ECC 6.0.

 2. Build the Integrated schedule:

This activity is imperative for any project; likewise, it is essential with a suite on HANA. There are different types of associated systems such as forecasting systems like BPC, Supply Chain Management, reporting systems like BW, third-party interfaces, and integration. Also, there are many front-end tools, for example, SAP GUI, Portals, Web stores, etc. for the integration of cloud to the SuccessFactors or Ariba or Salesforce. It is required to involve teams from Basis, Architecture, Infrastructure, Networking, Custom Development, Test Management, Finance, HCM, etc. and also the entire business. An integrated schedule is developed that defines the project in a manner which can be presented on a single monitor screen so that everyone should know about the happening of the event and as well as its time. It has to make sure that the integrated schedule should also include a reference to further issues or projects which will run simultaneously so that they can be tracked easily. It is equally important in an integrated schedule, to ask the teams for the accurate estimations about the time taken by a task to complete I,t instead of asking them to pay their times. Then, as a project manager, a possibility would be added, which let some slippage for the resolution of different problems.

3. Have a stakeholder map and communication plan:

It is required to decide that who, when and how the communication should take place on a regular basis, as from different places everyone will have an eye on the suite on HANA project. The senior leaders and CIOs frequently require a short update on a weekly basis, which should be understandable and clear with one swipe on a smartphone. If the communication with the stakeholders takes place regularly, the probabilities of scattering misinformation and triggering interruption to the project may decrease.

4. Develop mid-level and comprehensive plans:

It is required to build the three levels of plans for a migration project.
The very first is the integrated schedule that defines the project on a weekly basis.

Secondly, there is a detailed plan, which is created at the task-time-resource stage. As this plan is complicated to understand and read, only the experienced project managers can work with the detailed plan and interpret them. It includes the development of a Gantt chart with multifaceted dependencies, resource costing, WBS and allowing burndown charts and computation of grossed value. Usually, only the PMO can utilized this detailed plan.

The third level of the plan is the mid-level plan, which is created at the task-day-team level. The mid-level-plan permits you to elucidate to the project team every day about their work, that is what work they have to do and at what time, daily. With the help of the mid-level-plan, you can squeeze the plan, and the smaller projects will have improved time to value and lower cost.

 5. Have a production-sized sandbox and prototype:

It will entirely depend on the organization, landscape, and complexity that how this will going to take place, however, once you have arrived in the main development system, you will have a change freeze. The change freeze can be kept short, the best way to perform this is to be ready, and this can’t be prepared unless there is an earlier completed production-sized migration. To carry out this it is required to have a system copy of the production integration environment such as BW or ECC etc. and then we can migrate from the ECC system to HANA. It can be done two to three times by the basis team, before its release to the technical and functional teams so that they can enhance their process. Also, this can carry out early, before purchasing all the hardware. If this can be done, you can easily validate the sizing so that there is a confidence in you for your bill of material and to perform the other activities like archiving to reduce the hardware requirements.

 6. Consider having some skin in the game from SAP:

There is a system called ONE support, which will combine the SAP’s Active, Global Support and Professional Services Organizations i.e. PSO. You can contract them so that they can be included in the planning and support of the project, irrespective of whether you are of maximum consideration, active entrenched or Enterprise support customer. In general, there is a service catalog available  which contains a service for planning and custom code management. Even there are free services available for Pre and post-go-live checks which can be booked within six weeks. With the help of SAP architecture, it is easy to size and plan, as this service is a huge bonus and also a good quality of resources are available to carry out this work. Also, there is a HANA Ambassador program which can be accessible in North America; this program delivers a resource which reports into the Global customer office at SAP. By utilizing this program, your project can gain the required attention.

7. Join the customer advisory council:

A customer advisory council exist for a HANA run by Scott Feldman which meets occasionally. This service is available without any charge for senior IT people and project sponsors so that they can talk to other customer and can hear about the on-going changes in the ground and acquire some extra confidence.

 8. Make Numerous change, Test Once:

There is an excellent tool provided for HANA migration called DMO, which will upgrade, cover and carry out a Unicode conversion and can migrate to HANA in a single step, without touching the source system. It may increase the amount of effort in root cause analysis of a problem; however, it gives a unique test landscape.  If enough testing is not performed in the project, this may lead to a major risk.  The test management activity is crucial and has to be revised, i.e. test automation, strategies, coverage has to be reviewed.

9. Solution Manager is your friend:

During HANA migration, the solution manager is your friend. There is a solution manager, web page which contains a lot of useful pages, including the tools for the HANA migration. This involves a Custom Code Management Cockpit i. e. CDMC which tells about the customized code and will break down, Usage and Procedure Logging i.e. UPL, which specifies that what code is used and the last one is the Clonefinder, which specify about duplicating the transactions to the custom and how much they are modified. These codes can be utilized in combination with testing and process prioritization by business users.

10. Carry out enough testing:

It is required to have a conversation with the test manager and confirms that you have developed a good test strategy. There are few questions like:  Is there any separate phases for unit, integration and performance testing? Is there any tool are used for test automation like HP quality center? How broad is the test coverage? Include some effort in custom code recompense. Though HANA is a wonderful database, it is a columnar database some custom code may not run effectively if not written correctly. The row-based databases are more lenient as compared to columnar databases.

 11. Develop an integrated cut over plan:

 It is required to develop an integrated cutover plan, which is utilized by many teams. It involves all the teams and their activities. The plan should be numbered properly, which can be aligned with the cut over document.

Register Now for Live webinar on  SAP S/4HANA Simple Finance

Conclusion:

These are the few rules which can be followed for migration of SAP HANA  and S/4HANA. The Business Suite on HANA migrations is strictly a technical exercise, in most of the cases. It is not similar to S/4HANA where there will be a modification within the method such as a new UX. It is required to perform an excellent job of planning, testing and execution, however, it is attainable to move quickly.