Skip to Content

Following on from the previous blog, which sought to highlight the benefits from implementing Advanced Planning and Optimization (APO)on HANA, in this blog we will seek to explore the technical implications of this transition.

…………..

As an existing APO customer, under what circumstances should I choose to implement APO on HANA?

  • If you are upgrading to the release of SCM 7.0 Enhancement Pack 03
  • If you are seeking to implement the Supply Chain Info Center
  • If you are facing performance issues in the end-to-end DP, PP/DS, or Back Order Processing in gATP
  • If you are seeking to change your database vendor and move to an inMemory Platform

Are there any prerequisites for implementing APO on HANA?

  • SAP HANA runs natively only on Unicode. Unicode conversions can be done during the database migration but preparatory steps are required

Additionally, for the migration the following are also required/ recommended:

  • Custom Code Adjustment and Optimization (Required)
  • Data Volume Reduction (Recommended)
  • Evaluation of Restricted Add-Ons, Scenarios, and Processes (Required)
  • Dual-Stack Split (Required if Dual-Stack Source System)

Resource Requirements

  • Certified and Experienced Migration Specialist Required

How Should I Start?


Step 1: Implement APO on HANA PoC

PoC is a start smart into the HANA world. With APO-on-HANA PoC, you can establish a well-founded argument for a GoLive Decision as it enables users to experience the benefits of a HANA powered system landscape. In addition, as APO has less risky process in comparison ERP, users of APO-on-HANA can minimise risks and be prepared for the next steps.


Step 2: APO on HANA Go-Live Project

In this stage users can profit from the preparation and know how gained in the PoC stage as, due to the previous implementation of APO-on HANA PoC, the Go-Live stage will be smoother and less risky.


Step 3: ERP and Other SAP Modules Go-Live Project (Optional)

In this stage users can minimise risks on their further SuiteonHANA implementations. This is because they can utilize the HANA experience gained from the migration/ update and operations in the APOonHANA Go-Live stage. In addition, in this stage users businesses can benefit from having a faster interaction between their systems, can profit from HW cost savings, and can obtain a positive experience from the Go Live augmentation of ERP. Users can then add additional SAP modules on HANA Go Live.

……….


What is the typical time required for the APO on HANA Migration?

There is no fixed amount of time. Yet, in the past the previous customer projects have taken around 6 months. This time period has included preparation, technical upgrades, migration and functional stability testing and performance comparisons.

See below for a typical migration project plan for the implementation of APO on HANA.
APO 1.png


In addition, here’s an example of a project plan for implementing PoC SCM on HANA in a HEC environment:

APO 2.png

What is the hardware impact of the migration?

Switching to SAP has no impact on application servers or on front end. In addition, the transition has no impact on the data model or the custom extensions used. The only change, however, is the migration of database to SAP HANA Appliance which on the database server side needs special HANA Hardware.

APO 3.png

What is the sizing of SCM on HANA?

Use SAP Note 1793345- Sizing for Suite on HANA to understand sizing guidelines


HANA Appliance Memory

  • Expect a compression factor of 4 (compared to a standard AnyDB
  • Expect a compression factor of 2,5 (compared to a compressed AnyDB)
  • In addition factor 2 for temporary memory usage (e.g. for delta merges, intermediate results, in complex queries etc.)
  • (Source DB/4) x2= Needed HANA Appliance.  For example Source DB with 2 TB (tables plus indexes) (2/4) x 2=1 TB HANA Appliance

HANA Appliance CPU & Disks

  • The appliance is configured in such a way that CPU power and the I/O capacity is sufficient

What is the scaling of SCM on HANA?

– Scale-up (scale vertically)- Increases the size of the hardware (main memory, number of CPUs)

Ensure: Availability of suitable hardware (up to 4 TB cache)

– Scale-out (scale horizontally)- several nodes (servers) are switched together for one database and the data is distributed over the main memories of these different nodes

Ensure:

  • To avoid cross-node joins/ views as cross-node communication is expensive. Table distribution has to be customer/ usage pattern specific
  • Dynamic re-distribution must be allowed
  • Regarding availability of multi node scenarios (scale out) for Suite on HANA please refer to SAP note 1825774

With SAP HANA, there are both very small and very server clusters:

APO 4.png

How is the migration carried out for APO on HANA?

Below is an example of a one-step migration via database migration option. DMO is supported from SCM 7.0. to SCM 7.13 on HANA

APO 5.png

……….


Special thanks to Alexander Greb for sharing his key insights and providing this valuable information.

Feel free to contact Sujeet Acharya (email: sujeet.acharya@sap.com)  if you have any further questions on this topic.


To view the previous blog on the “benefits of implementing APO on HANA”, use the link below:


http://scn.sap.com/community/scm/blog/2015/08/25/why-now-is-the-right-time-for-apo-on-hana

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply