Professional Documents
Culture Documents
Implementing SAP
HANA: Planning,
Scoping, Staffing,
Budgeting, and
Execution
Bjarne Berg
Comerit
Copyright 2014
Wellesley Information Services, Inc.
All rights reserved.
In Part 1 of the Session
In Part 1 one of this 2-part session we will look at how to plan for,
staff, budget, and prepare for a HANA implementation
We will see two demos of SAP HANA and discuss the different
implementation scenarios
You will learn about your hardware options and see real price
examples
We will explore a milestone plan and look at three different
staffing models from real implementations
At the end of this session you will know how to start the project
planning for your implementation or migration
In the second part of this presentation we will look at how to execute a HANA
install and HANA migration project, and see how to do development in HANA
2
What Well Cover
Background and HANA demo
HANA implementation options
Hardware sizing and planning
HANA project staffing, roles, and responsibilities
Top 10 lessons learned from SAP HANA implementations
Creating realistic budgets and project plans
Wrap-up
3
HANA Editions and Components
While HANA is sold as an
appliance, there are many internal
components and the edition you
buy may contain different licenses
to these components.
4
HANA Release Strategy and Names
6
What Well Cover
Background and HANA demo
HANA implementation options
Hardware sizing and planning
HANA project staffing, roles, and responsibilities
Top 10 lessons learned from SAP HANA implementations
Creating realistic budgets and project plans
Wrap-up
7
SAP Business Suite on HANA
As of January 17, 2013, SAP has supported SAP Business Suite
on HANA
This means that you can install a new ERP system on HANA, or
migrate your existing system to HANA to take advantage of the
simpler architecture as well as the significant performance
benefits of HANA
In 2013, several companies installed or moved their ERP systems
to HANA, and it is becoming increasingly common
To see what is supported from an ERP standpoint, take a look at SAP Note
1774566 (SAP Business Suite Powered by SAP HANA - Restrictions); a list
of pre-checks and more details are available at http://tinyurl.com/pm82orw
8
SAP Business Suite on HANA (cont.)
SAP has created many
sites for helping
customers navigating
the ERP migration
The best tactical
step-by-step site is
found at
http://tinyurl.com/ngfk2wx
More general
information can be
found at SAP HANA
http://tinyurl.com/q796yxr
This means that you start with the BW system, complete the cleanup and
preparations and migrate the database over to SAP HANA, but leave the application
logic and data models the same.
After the migration you will have your database system as HANA, but there are no
model changes to your system and there will be no impact to your queries, link to
NLS, interfaces, or data loads except for substantially faster performance and some
internal changes on how HANA processes at the database level (i.e., data activation
and compression)
This migration approach is a technical and functional upgrade at the same time.
While the impact is minimal, significant additional performance in data loads and
query performance can be achieved.
For very large BW systems, this approach can be very time consuming and require
more testing. To reduce this, you can limit the optimization to slow performing areas
that need this extra boost, or do the standard upgrade first and then optimize as part
of future development efforts, or when enhancing InfoCubes and data loads.
How much additional optimization effort you are willing to undertake depends
on the resources available and how fast you have to complete the migration. 13
3. BW to HANA Migration as a Re-Implementation
Some organizations have decided to take the BW to HANA migration as a re-
implementation approach to also clean up old designs and retire no longer used
InfoCubes, InfoObjects, DTPs, reports, queries, and other elements.
The steps involve setting up a new BW system on HANA parallel to the current BW
system running on a relational database. Then, for key areas, the InfoCubes and DSOs
are transported to the HANA box and the data loads are switched over to the new
system as part of smaller projects.
Meanwhile, other InfoCubes and DSOs are running on the old BW relational database-
based system. Basically, you are running two BW systems at the same time without
duplicating the loads to InfoProviders in both systems.
While more costly, this approach allows you to keep the old system around
and minimize risks of the HANA migration. The outage required is also
minimal and can be done over a weekend, functional area by functional 14
4. Migrate a Copy of BW to HANA
This alternative approach can be used by
organizations with very low risk tolerance and
those who have lots of time to migrate BW
to HANA
We will look at the Direct Migration Option (DMO) and the features of
Post-Copy Automation PCA in Part 2 of the session 15
Summary of BW to HANA Migration Options
17
Pre-Steps Analyze BW Readiness
SAP has a checklist tool for
SAP NetWeaver BW powered
by HANA (thanks to Marc Bernard at SAP
Labs).
This tool does not replace the upgrade tasks in the ASU,
which we will examine in Part 2 of the session in more detail 19
Pre-Steps Analyze BW Readiness (cont.)
The checklist tool also has specific checks for the HANA system that can help
you identify any issues before turning over the system to end users 20
What Well Cover
Background and HANA demo
HANA implementation options
Hardware sizing and planning
HANA project staffing, roles, and responsibilities
Top 10 lessons learned from SAP HANA implementations
Creating realistic budgets and project plans
Wrap-up
21
Some Hardware Options for HANA
The system
basically consists
of memory, disk,
processors and
network cards
The hardware vendor will install, connect, and do a health check on your system
before handing it over to you. A 3-year service plan is also normally required. 23
SAP QuickSizer for HANA
There are three versions of the tool for each version of SAP HANA
The second
QuickSizer version
The last is for those who want
is for SAP HANA
to use SAP HANA as a
on SAP NetWeaver
standalone platform for in-
BW
memory data (i.e., using SAP
Data Services to load data to)
In this case, SAP HANA for BW will deploy the master data, ABAP
system tables, and row store data on the master node. The other
connected server node(s) will contain the InfoCubes and DSOs.
28
SAP BW on HANA Sizing Tool for Existing
BW Implementations
To increase speed, you can suppress
SAP has released an updated tool that analysis tables with less than 1 MB size.
generates a report significantly better
for sizing SAP BW than using the
QuickSizer. This tool should be used by
all existing BW implementations for
sizing (QuickSizer is only for new
implementations).
This program takes into consideration
existing database, table types, and
includes the effects of non-active data
on the HANA system.
The higher precision you run the estimate
at, the longer the program is going to run.
This program is referenced in SAP Notes 1909597 and 1736976 on the Service Marketplace30
Rule Of Thumb Approach to Sizing HANA Memory
Memory can be estimated by taking the current system size and
running the programs in get_size.zip in SAP Note 1637145 to get
row and column store sizes for your system
Memory = 50 GB +
[ (rowstore tables footprint / 1.5) +
(colstore tables footprint * 2 / 4) ] * Existing DB Compression
In this example, you need 4 x 710 GB disk for the persistence layer
and about 710 GB for the logs. This equals around 3.5 TB (dont
worry, disk space of this size is now almost cheap).
The persistence layer is the disk that keeps the system secure and
provides for redundancy if there are any memory failures, so its
important not to underestimate this.
The CPUs are based on the number of cores that you include.
For example, 10 core CPUs now exist (depending on when you
bought your system).
The number of processors are largely driven by the number of users and usage
patterns. Serious consideration should be made before buying hardware. 34
Summary of HANA Sizing Approaches
36
Staffing a HANA Migration Project Small Team
System Profile
Raw data size: 2.7 TB
Complexity: Medium
DataStores: 87
InfoCubes: 63
Queries: 409
The test team was dedicated for 9 weeks during the
migration of QA and Prod environments
Duration: 14 weeks
Environments: 4+1 The test team from the business was comprised of
Risk aversion: Medium experienced users of the BW system and needed minimal
Other usage: Integrated training
Planning HANA Optimization of InfoCubes was done for SD reports
only in this migration
This organization was using BWA 7.0 and retired it as part of the HANA
migration, thereby saving licensing costs for this platform 37
Staffing a HANA Migration Project Medium Team
System Profile
Raw data size: 5.6 TB
Complexity: Medium
DataStores: 439
InfoCubes: 603
Queries: 1,300+
(incl. BOBJ)
Duration: 18 weeks The testing of core queries in BEx and Web Intelligence
Environments: 4 was done by the business
Risk aversion: HIGH The data reconciliation and process chain testing were
Other usage: None done by dedicated resources in each team
The team must be staffed with experienced resources. HANA training for
team members and hardware installs should be in place prior to project start.38
Staffing a HANA Migration Project Very Large Team
System Profile
Raw data size: 38TB
Complexity: High
DataStores: 1,300+
InfoCubes: 1,720+
Queries: 2,600+
Duration: 5 mos
Environments: 4
Risk aversion: HIGH
Other usage: APO, IP,
BPC
Remember to
budget for
HANA training
employees
before the
project starts
Class
schedules are
found at:
training.sap.com
While most tasks are similar to the old relational database systems, the way
we do this is quite different. Make sure your HANA support staff is
onboarded early and trained before cut over to production of your migration
41
On-Going Support Tasks and Staff Required
The support of HANA is actually easier than the traditional Basis support.
Most functions are done in a single interface and many of the tasks are
significantly simplified due to the inherent performance of HANA. 42
HANA Demo The SAP BusinessObjects
Front-End Tools on HANA
43
What Well Cover
Background and HANA demo
HANA implementation options
Hardware sizing and planning
HANA project staffing, roles, and responsibilities
Top 10 lessons learned from SAP HANA implementations
Creating realistic budgets and project plans
Wrap-up
44
1. Lessons Learned: Buy Hardware Early
Many are fearful of a new technology and are unsure how this will change their
work. You should provide real demos and workshops early so that everyone
knows what is happening and how HANA will change their day-to-day jobs.
47
4. Lessons Learned: Hardware Sizing Should
Include Growth
1. Some customers forget that sizing would be for 3
years out and not based on current system size
alone
Formally assign a team of 2-3 experts to come in and meet with your
team a few times during the project planning and execution. Make sure
these project advisors are hands-on and that they can act as technical
go-to resources for your team if questions arise.
50
7. Lessons Learned: Think BIG
Early in the project create a 2-3 year strategic plan that demonstrates
to the leadership what you are going to do with this new technology.
Present it as new capabilities not just how fast it is
51
8. Lessons Learned: Plan for Reporting and
System Consolidation
There are many NLS solutions available that can save you big bucks by
reducing the need for multi-node, multi-terabyte HANA systems. Take a serious
look at SAP IQ solution for NLS. It is tightly linked with HANA already.
53
10. Lessons Learned: Save Money with MCOD and MCOS
1. You may not need separate hardware for sandbox and development
environments
2. Using Multiple Components One Database (MCOD) and/ or Multiple
components One System (MCOS) you can simplify the number of hardware
environments you need
a) SAP NetWeaver BW on SAP HANA
b) SAP Finance and Controlling Accelerator for the material ledger
c) ERP operational reporting with SAP HANA
d) SAP Finance and Controlling Accelerator: Production Cost Planning
e) SAP Rapid Marts
f) SAP COPA Accelerator
g) SAP Operational Process Intelligence
h) SAP Cash Forecasting
i) SAP Application Accelerator / Suite Accelerator
j) Smart Meter Analytics
55
Budgeting a HANA Migration Project - Systems
There is a set of items you need to budget for. From a
system perspective, you will need to consider:
Hardware quotes
Give at least two vendors your sizing estimate
and ask for quotes
Vendor Support
Make sure your hardware vendor includes 3 years of support
in your purchase
Upgrades
Plan and budget for any BW upgrades required before going
to HANA (7.4)
Do the pre-steps BW cleanup we outlined earlier as soon as possible
and then the formal sizing effort before requesting a hardware quote
56
Mid-Size Budgeting Example HW Quotes HP
62
Where to Find More Information
www.sap-press.com/products/SAP-HANA%3A-An-Introduction-(2nd
-Edition).html
63
7 Key Points to Take Home
There are programs to do pre-readiness checks for an ERP and BW
system for migration to HANA
A BW Migration Cockpit is now available to assist in the tasks
While one is more common, there are actually four possible approaches
to the HANA migration project
There are currently seven different certified HANA vendors and many
options for small, medium, and large systems Make sure you get a
competitive bid
Budgeting should include HANA training and system cleanup, as well as
support staff required or reorganized
Most HANA projects can be done in a matter of weeks.
Only extremely large systems may require 4-7 months
In the next session we will look at the project tasks for executing a HANA
migration, an install, and demo the most common HANA development work steps 64
Your Turn!
65
Disclaimer
SAP, R/3, mySAP, mySAP.com, SAP NetWeaver, Duet, PartnerEdge, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product
and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by
SAP.
66