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)
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.
In addition, here's an example of a project plan for implementing PoC SCM on HANA in a HEC environment:
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.
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
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:
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
Special thanks to Alexander Greb for sharing his key insights and providing this valuable information.
Feel free to contact Sujeet Acharya (email: email@example.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: