Transcript HANA2014_A_to_Z_Guide_Part_1

An A-to-Z Guide to
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
1
What We’ll 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
2
HANA Editions and Components
•
Area
Platform
Edition
Component ID
Component Name
While HANA is sold as an
appliance, there are many internal
components and the edition you
buy may contain different licenses
to these components.
BC-DB-HDB
SAP HANA database
BC-DB-HDB-ENG
SAP HANA database engine
BC-DB-HDB-PER
SAP HANA database persistence
BC-DB-HDB-SYS
SAP HANA database interface
BC-DB-HDB-DBA
SAP HANA database/DBA cockpit
BC-DB-HDB-POR
SAP HANA DB Porting
BC-DB-HDB-BAC
SAP HANA Backup and Recovery
BC-CCM-HAG
SAP Host agent
BC-DB-HDB-CCM
SAP HANA CCMS
BC-DB-HDB-CLI
SAP HANA Clients (JDBC/ODBC)
BC-DB-HDB-R
SAP HANA Integration with R
BC-DB-HDB-SCR
SAP HANA SQL scripts
BC-DB-HDB-MDX
MDX engine: Microsoft Excel client
BC-HAN-MOD
SAP HANA Studio - Information Modeler
BC-HAN-3DM
Information Composer
BC-HAN-SRC
SAP HANA UI toolkit
BC-DB-HDB-TXT
SAP HANA Text and Search features
BC-DB-HDB-DXC
SAP HANA Direct extraction connector
BI-BIP-CMC, BI-BIP
BI Platform
BC-DB-HDB-SEC
SAP HANA Security and User Mgmt
BI-RA-WBI
Web Intelligence
BC-DB-HDB-XS
SAP HANA Application Services
BI-RA-XL
Dashboard Designer
BC-DB-HDB-AFL
SAP HANA Advanced functions library
BI-RA-CR, BI-BIP-CRS
SAP Crystal reports
BC-DB-HDB-AFL-PAL SAP HANA Predictive analysis library
BI-RA-EXP
SAP BusinessObjects Explorer
BC-DB-HDB-AFL-SOP SAP HANA Sales & Operations Planning
BI-BIP-IDT
Information Design Tool (for universes)
BC-DB-HDB-PLE
BI-RA-AO-XLA
Microsoft Excel add-in
SAP HANA Planning Engine
Area
Lifecycle
Management
Component ID
BC-HAN-SL-STP
SAP HANA unified installer
BC-HAN-UPD
Software Update Manager
BC-DB-HDB-INS
SAP HANA database installation
BC-DB-HDB-UPG
SAP HANA database upgrade
BC-HAN-DXC
Enterprise Edition EIM-DS
BC-HAN-LOA
(also have platform
edition components) BC-HAN-LTR
BC-HAN-REP
End User Clients
Component Name
SAP HANA Direct Extractor Connection
SAP Data Services: ETL-based
SAP HANA Load Controller: log-based
SAP Landscape Transformation (SLT): trigger-based
Sybase Replication Server: log-based
3
HANA Release Strategy and Names
Source: SAP AG, SAP HANA Product Management, Dec 2013.
•
•
As of December 2013, SAP introduced the idea of “production
verified revisions” to provide in-depth testing of all service packs
for SAP HANA
Based on the planned releases over the next 24 months, customers
should adjust their plans for service packs accordingly
4
HANA Demo — SAP BusinessObjects on HANA
5
What We’ll 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
6
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
7
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
There is not a lot of qualified ERP migration consultants available (yet),
so plan on involving SAP in your project team as well.
8
SAP HANA Analytical Framework
•
You do not need SAP BW, nor ERP to benefit from HANA
•
Many organizations can benefit from the speed and simplicity of
SAP HANA even if they do not have SAP Business Suite (ERP) or
SAP BW (data warehouse)
The open nature of HANA
allows you to build your
own data warehouse and
analytical applications in
anyway you want, and you
can access the models
with most tools through a
variety of interfaces,
including ODBC.
9
Four Options for Migrating BW to HANA
•
There are basically four different
approaches to migrating your BW system
to SAP HANA. Each are slightly different.
They may be summarized as:
1.
2.
3.
4.
Standard BW to HANA migration without Optimization
BW to HANA migration with Optimization
BW to HANA migration as a Re-Implementation
Migrate a copy of BW to HANA
A major decision before you start is to determine which of these options
your want to pursue. We will now take a quick look at each of them
10
1. Standard BW to HANA migration without Optimization
•
In this approach you treat your BW move to HANA as a
database migration project.
•
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)
Functionally, you have the same system and this
approach is therefore the fastest and most common.
11
2. BW to HANA Migration with Optimization
•
In this approach, the migration also involves the optimization of
data structures to take advantage of the new capabilities in HANA.
This may include HANA optimized InfoCubes and HANA hints on
data transformations to make lookups go faster or LSA redesign.
•
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. 12
3. BW to HANA Migration as a Re-Implementation
•
Some organizations have decided to take the BW to HANA migration as a reimplementation 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 databasebased 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 area.13
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
•
It involves copying the production BW system and applying notes
or upgrades as required. Then reconciling the BW and the new
BW on HANA system from a functional standpoint (interfaces,
open hubs, reports, analytics, security, and data). When the tests
are done, the process chains are run and the data is reconciled
again.
We will look at the Direct Migration Option (DMO) and the features of
Post-Copy Automation PCA in Part 2 of the session
14
Summary of BW to HANA Migration Options
For many organizations, a migration of their BW systems to
HANA (technical migration), followed by a later functional
optimization is the most common approach (so far)
15
Summary: The Most Common HANA Scenarios
16
Pre-Steps — Analyze BW Readiness
SAP has a checklist tool for
SAP NetWeaver® BW powered
by HANA (thanks to Marc Bernard at SAP
Labs).
In this tool, SAP provided
automatic check programs for
both the 3.5 version and the 7.x
version of BW. These are found
in SAP Note: 1729988.
In the latest version of this tool,
hundreds of checks are done
automatically in the BW system.
This includes platform checks
There are even Basis checks for support packs, ABAP/JAVA
on database and application
stacks, Unicode, BW releases, and add-ons to your system
and system information.
17
Pre-Steps — Analyze BW Readiness (cont.)
Your should run this
program well in advance
of the actual migration
The tool is essential to
the planning phase to
understand the tasks
that are required for
migrating to SAP HANA
This tool does not replace the upgrade tasks in the ASU, which
we will examine in Part 2 of the session in more detail
18
Pre-Steps — Analyze BW Readiness (cont.)
The idea of the checklist tool
is that you run it several
times throughout the project
Once before you start, then
periodically as you resolve
issues and upgrade
requirements, and then
finally when the system has
been migrated to HANA
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
19
What We’ll 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
20
Some Hardware Options for HANA
There are many certified HANA
hardware vendors with over a
dozen different products.
Memory
Hardware
128GB
Cisco C260
X
Cisco C460
256GB
X
X
X
X+
X
Dell R910
X
X
X
Hitachi CB 2000
X
X
X
X
X
X
X
NEC Express 5800
Fujitsu RX 600 S5
X
Fujitsu RX 900 S2
HP DL 580 G7
X
X
X
HP DL 980 G7
X+
X+
X
X
X
X+
HP BL 680
X
X
X
IBM x3690 X5
X
X
X
X
X
IBM x3950 X5
1024GB
X
Cisco B440
Some boxes can be used as single nodes
with others are intended for scale-out, scale
up, solutions for large multi-node systems
512GB
X+
21
A HANA Hardware Example
In this box, we see
the inside of an
IBM x3950 HANA
system
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. 22
SAP QuickSizer for HANA
There are three versions of the tool for each version of SAP HANA
The QuickSizer for the
Business Suite allows you to
size for specific modules
The second
QuickSizer version
is for SAP HANA
on SAP NetWeaver
BW
The last is for those who want
to use SAP HANA as a
standalone platform for inmemory data (i.e., using SAP
Data Services to load data to)
SAP’s QuickSizer for SAP HANA is available at
http://service.sap.com/quicksizer.
23
SAP QuickSizer for New BW HANA Implementations
If you’re using planning in
SAP NetWeaver BW, enter
the info here. The fields
marked with * are
mandatory.
For H-PLAN-1, enter the
maximum concurrent users
in the USERS field. The S.T.
and E.T. fields are the start
and end times for the
processing.
Enter the estimated number of information consumers (H-BWINFO), business users (H-BW-BUSI.), and experts (H-BW-EXPER).
SAP suggests a ratio of 71%, 26%, and 3% for each user group,
but you can enter your own mix if you have better estimates.
By entering this type of
information, you’ll get
estimates of loads on the
SAP HANA system by time
periods at the end of the
sizing exercise.
24
SAP QuickSizer for New BW HANA Implementations
(cont.)
In SAP Note 1637145, SAP BW
on HANA: Sizing SAP In-Memory
Database, there are programs
you can run on SAP NetWeaver
BW to get good sizing numbers.
The shell script is located in the
file get_size.ZIP, which should
be extracted and executed along
with the file
load_RowStore_List.SQL for
size input to TABLE 4.
The exception to this approach
is the IBM DB2 database on the
z/OS. For this combination, there
is an ABAP program instead.
In TABLE 3, you estimate how many records will be
loaded to SAP NetWeaver BW periodically. In this
example, we’re estimating that 279,994,355 records
will be loaded each day between noon and 1pm.
NOTE: The QuickSizer should
only be used for new HANA
implementations and not for
migration of existing systems
25
SAP QuickSizer for New BW HANA Implementations
(cont.)
Enter the InfoCube and DSO
information. The max number
of dimensions (DIM) you can
enter for the InfoCube is 13.
The three fixed dimensions of
BW are already included, so
just enter the free
dimensions.
The field KEYF. refers to the
number of key figures in the
fact table of your InfoCube,
while the field COM. is the
estimated compression.
In the INITIAL LOAD field, you enter the number of records in
the existing InfoCube, and in the PERIOD. UPLD field, you enter
the number of records you estimate will be loaded periodically.
If you don’t have better
estimates, a rate of 5 may
serve for the initial sizing
before you refine the
estimates with your hardware
vendor.
26
SAP QuickSizer for HANA — Output
This SAP HANA
sizing example
calls for 1.6TB of
memory.
Because we’re
unlikely to get this
in a single server
node, we’ll have a
multi-node system.
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.
27
SAP BW on HANA Sizing Tool for Existing
BW Implementations
SAP has released an updated tool that
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).
To increase speed, you can suppress
analysis tables with less than 1 MB size.
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.
With 12 parallel processors and 10TB database,
it is not unusual to see 30-70 minutes runtime
28
SAP BW on HANA Automated Sizing Tool
Since timeouts are common when
running the sizing program, you can
temporarily change the parameter in
rdisp/max_wprun_time to 0 in BW
transaction RZ11. Finally, you estimate
the growth for the system as a
percentage, or as absolute growth.
The output is stored in the file you
specified and the file can now be
emailed to hardware vendors for sizing
input and hardware selection.
This program is referenced in SAP Notes 1909597 and 1736976 on the Service Marketplace29
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
•
The 50 GB is for HANA services and caches. The 1.5 is the
compression expected for rowstore tables and the 4 is the
compression expected for column store tables. The 2-factor refers to
the space needed for runtime objects and temporary result sets in
HANA. Finally, the term “existing DB compression” is to account for
any compression already done in your system (if any).
Remember, these are quick rules of thumb, so don’t rely
on it for finalized budgeting and hardware purchases
30
Rule of Thumb Approach to Sizing HANA — Disk
•
The next item you need is disk space, which can be estimated by the
following:
Disk for persistence layer = 4 Memory
Disk for the log = 1 Memory
•
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 (don’t
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 it’s
important not to underestimate this.
Remember, these are quick rules of thumb, so don’t rely
on it for finalized budgeting and hardware purchases
31
Rule-Of-Thumb Approach to Sizing HANA — CPU
•
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).
CPU = 0.2 CPU cores per active user
•
If you have a single node with 4 x 10 cores, you will have 40
cores and can handle 200 active users on that hardware node,
and quite a larger number of named users.
Remember, these are quick rules of thumb, so don’t rely
on it for finalized budgeting and hardware purchases
32
A T-Shirt Model for Sizing HANA on BW
A T-shirt model is a quick
way to get some basic ideas
on what a system may look
like
While very inaccurate for
sizing, it provides basic
information for those just
starting to consider SAP
HANA
Data Compress
ion (from)
Working
Memory
Processors
SAS/SSD
(for data)
Replication
Speed (per
hour)
Extra
Large
(XXL)
7000–100,000
GB
3072 GB
12+ Intel
E7 2.4 Ghz
10+ TB
20+ GB
Very
Large
(XL)
3500–7000GB
2048 GB
8+ Intel E7
2.4 Ghz
5 – 10 TB
20+ GB
Large (L)
2000–3500GB
1024GB
4 x Intel
E7 2.4 Ghz
4 - 5 TB
5–20GB
Medium
(M)
1250–
2000GB
512GB
4 x Intel
E7 2.0+
Ghz
2048GB
5–20 GB
Small (S)
500–
1250GB
256GB
2 x Intel
E7 2.0+
Ghz
1024GB
5GB
Extra
Small
(XS)
256–
500GB
128GB
2 x Intel
E7 2.0+
Ghz
1024GB
5GB
to 20+ TB
(multi node)
(multi node)
The number of processors are largely driven by the number of users and usage
patterns. Serious consideration should be made before buying hardware.
33
Summary of HANA Sizing Approaches
Approach
T-Shirt Sizing
Rule of Thumb
SAP QuickSizer
Sizing for BW program
•
Quality of Estimate
 Sort of “OK”
 Better
 Much better (new implementations only)
 Excellent (for existing BW systems)
Effort Required
Very Low
Low
High
Moderate/Low
Work with your preferred vendor before ordering your hardware or
finalizing your budgets
SAP Note 1736976 (ABAP report to help with BW on HANA Sizing)
SAP Note 1909597 (SAP NetWeaver BW Migration Cockpit for SAP HANA)
SAP Note 1729988 (SAP BW Checklist for Migration),
SAP Note 11855041 (Sizing the Master node)
34
What We’ll 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
35
Staffing a HANA Migration Project — Small Team
System Profile
Raw data size:
Complexity:
DataStores:
InfoCubes:
Queries:
Area
2.7 TB
Medium
87
63
409
Duration:
14 weeks
Environments: 4+1
Risk aversion: Medium
Other usage:
Integrated
Planning
Core
team
Test
team
Role
Staff area Jun
Company
50%
Company
75%
Consultant 100%
Consultant 100%
Consultant 100%
Project manager
BW Basis Support
HANA Basis Support
HANA Optimization developer
HANA Test & resolution lead
Functional Tester - Finance & COPA
Business
Functional Tester - Sales and Distribution Business
Functional Tester - MFG & Sourcing
Business
Jul
Aug
Sep
50%
75%
100%
100%
100%
25%
25%
25%
50%
100%
100%
100%
100%
50%
50%
50%
50%
75%
75%
50%
50%

The test team was dedicated for 9 weeks during the
migration of QA and Prod environments

The test team from the business was comprised of
experienced users of the BW system and needed minimal
training

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
36
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
Environments: 4
Risk aversion: HIGH
Other usage:
None
Area
Role
Project manager
Technical project manager
Core
Project Advisor
team
BW / HANA Basis Support
HANA Basis Support
BW Technical test lead
Test Team:
Finance
Functional Tester - Finance
HANA Test & resolution lead
Test Team:
SD & Commissions Functional Tester - Sales & Distribution
BW Technical tester
Test Team:
Other Areas
Functional Tester - Other areas
Staff area Jan
Company
25%
Consultant 100%
Consultant 20%
Company
75%
Consultant 100%
Company
Business
Consultant
Business
Company
Business
Feb
Mar
Apr
May
25% 25% 25% 25%
100% 100% 100% 100%
20% 20% 20% 20%
100% 100% 100% 75%
100% 100% 100%
75% 100% 100%
50% 50%
75% 100% 100%
50% 50%
75% 100% 100%
50% 50%

The testing of core queries in BEx and Web Intelligence
was done by the business

The data reconciliation and process chain testing were
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. 37
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
This assumed minimal
additional functional
optimization
Area
Role
Project manager
Technical project manager
BW Basis Support
Core
HANA Basis Support
team
Project Advisor
HANA Optimization developer
Support team Representative
BW Technical test lead
Test Team:
HANA Test & resolution lead
Finance and
Functional Tester - Finance
BPC
Functional Tester - BPC
BW Technical test lead
Test Team:
HANA Test & resolution lead
Sales and
Consultant Test team lead and Sales
Distribution
Functional Tester - Delivery
BW Technical test lead
Test Team: HANA Test & resolution lead
Manufacturing Consultant Test team lead and Sales
Functional Tester - Delivery
BW Technical test lead
Test Team:
HANA Test & resolution lead
Global
Functional Tester - PO and Spend
Sourcing
Functional Tester - AP and Performance
BW Technical test lead
Test Team:
HANA Test & resolution lead
HR and
Functional Tester - HR
Planning
Functional Tester - IP
Staff
Mar
Apr
May June July Aug
Company
Consultant
Company
Consultant
Consultant
Consultant
Company
Company
Consultant
Business
Business
Company
Consultant
Business
Business
Company
Consultant
Business
Business
Company
Consultant
Business
Business
Company
Consultant
Business
Business
100%
100%
75%
100%
20%
100%
50%
50%
100%
100%
100%
75%
100%
20%
100%
50%
50%
100%
100%
100%
50%
100%
20%
100%
50%
50%
100%
25%
25%
50%
100%
25%
25%
50%
100%
25%
25%
50%
100%
25%
25%
50%
100%
25%
25%
50% 50%
100% 100%
50% 50%
100% 100%
50% 50%
100% 100%
50% 50%
100% 100%
100%
100%
50%
100%
20%
100%
50%
100%
100%
25%
25%
100%
100%
25%
25%
100%
100%
25%
25%
100%
100%
25%
25%
100%
100%
25%
25%
100% 75%
100% 75%
100% 75%
100% 75%
20% 20%
100%
50% 100%
100%
100%
50%
50%
100%
100%
50%
50%
100%
100%
50%
50%
100%
100%
50%
50%
100%
100%
50%
50%
38
Budgeting a HANA Migration Project — Training
Remember to
budget for
HANA training
employees
before the
project starts
Class
schedules are
found at:
training.sap.com
On average, plan for $3,000 to $6,000 to train each team member
plus traveling costs if you don’t use e-learning
39
On-Going Support Tasks and Staff Required
•
Major on-going support tasks consists of:
 User and role maintenance
 Security maintenance
 Backup and disaster recovery
 Load balancing, monitoring, and hardware maintenance
 Software patches and notes for HANA, BW, and components
 Cleanup, NLS, archiving, and log deletions
 Transports, table copies, system copies, and data copies
 Periodic system upgrades
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 project.
40
On-Going Support Tasks and Staff Required
•
The staffing roles required are normally:
•
One basis resource for system admin and
monitoring for every 4-5 environments (Do you need 24-hour
support?)
•
One resource, part-time, for security, roles, and access
maintenance (depends on number of users)
•
One BW resource for monitoring loads, issues, and fixes (could be
part-time role in small and mid-sized organizations)
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.
41
HANA Demo — The SAP BusinessObjects
Front-End Tools on HANA
42
What We’ll 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
43
1. Lessons Learned: Buy Hardware Early
1.
The typical lead time for the basic HANA
appliances is as little as 4-8 weeks
2.
However, for large scale environments, or multinode environments, the lead times can sometimes
be as long as 10-14 weeks
3.
This is particularly true for virtualized systems
managed by a third-party who has to set them up,
configure backup, and learn the new technology
Get a small team on-site early for planning, budgeting, and
sizing; and hold off staffing all team members from the
business until you get a confirmed hardware delivery date
44
2. Lessons Learned: Get the Right Team Members
1.
While there are many with basic certifications in
HANA, the pool of qualified experienced
resources is limited
2.
Great HANA resources are most likely working on
another project already
3.
So, if you want the best, be prepared to give your
implementation partner several weeks lead time
Do you want “who is available” or “who should be
available” on your project? Be prepared to give your
implementation partner longer lead times than usual.
45
3. Lessons Learned: Include Training for your Staff
1.
There are a lot of “myths” and beliefs about HANA
that your have to address early
2.
Before you start the project, make sure your
implementation partner has a formal written
training plan on how they will provide knowledge
transfer
3.
Include your support staff and Basis people in all
project discussions from the first planning session
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.
46
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
2.
You should have a sizing estimate that includes
new projects, data growth, and data retention
policies, as well as periodic scheduled clean up
activities
Funding for hardware is sometimes easier in a project mode,
and many companies plan for 30-50% more capacity as part
of the initial rollout if they can afford it
47
5. Lessons Learned: “Master-Node” Size
1.
Some hardware vendors want to maximize the
number of processes available to the users. They
can do this by using multiple smaller nodes with
many processors in each.
2.
The drawback is that all of your row and master data
stores may not fit on the small node as you grow.
Pay very careful attention to the row-stores sizes and the
master data growth when buying hardware. You don’t
want to have to upgrade shortly after go-live.
48
6. Lessons Learned: Create an Ecosystem of Experts
1.
Having access to the best and brightest within
SAP, consulting firms, and industry experts is
key when issues or questions arise
2.
These people are very busy and are often
engaged on many projects as “supporters”
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.
49
7. Lessons Learned: Think BIG
1.
A HANA implementation should not be treated as
a replacement project. It is an enabler …
2.
Plan ahead on what you are going to do with the
new technology, e.g., mobile, forecasting,
planning, BI dashboards, customer and vendor
facing analytics, market basket analysis,
stratification, data visualization, etc.
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 …
50
8. Lessons Learned: Plan for Reporting and
System Consolidation
1.
2.
After go-live you should have planned for how
you are going to migrate all reporting and
management analytics on to HANA and away from
datamarts and standalone expensive systems that
are not integrated into the long-term vision
You will most likely have to do some “selling” to
your fellow employees and be prepared to give them
“free access” to your HANA system
HANA is not just for BW or Business Suite. It is an enterprise
platform for integrated analytical and data processing. You can give
developers access to your system and they can build their own Agile
marts inside HANA, even if they don’t want to use BW.
51
9. Lessons Learned: Near-Line Storage Can Save Millions
1.
Removing data that is not needed on a daily basis from
your system and placing it on near-line storage instead
of in-memory can save you millions.
2.
In one project a customer took his system from 112 TB
to 38 TB by simply moving data to near-line storage
(NLS)
3.
An Asian firm took a 3.8 TB BW system to “only” 900 GB
after cleanup and an NLS implementation
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.
52
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)
b)
c)
d)
e)
f)
g)
h)
i)
j)
SAP NetWeaver BW on SAP HANA
SAP Finance and Controlling Accelerator for the material ledger
ERP operational reporting with SAP HANA
SAP Finance and Controlling Accelerator: Production Cost Planning
SAP Rapid Marts
SAP COPA Accelerator
SAP Operational Process Intelligence
SAP Cash Forecasting
SAP Application Accelerator / Suite Accelerator
Smart Meter Analytics
In addition to custom developed datamarts, all items above can
run in an MCOD setup (see SAP Note 1666670 for more details)
53
What We’ll 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
54
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
55
Mid-Size Budgeting Example HW Quotes — HP
This example quote is for a
mid-sized 512 GB memory
box with 4 x 10 core CPUs
and 7 TB disks based on
Hewlett-Packard’s high-end
DL-980 Box
Including all services and
support agreements, this
quote is only $150,000
(1 box)
Certified HANA vendors such as HP, IBM, Dell, Cisco, NEC, Hitachi, and Fujitsu
have dedicated staff to help you get a detailed quote in a matter of days
56
Small Example HW Quotes — Dell
This example is a quote for a smaller 128
GB Memory Box with 2 x 10 cores and is
based on Dell’s R910 platform for a HANA
sidecar usage for less then $40,000
(including tax!)
Most of the smaller HANA systems from the
other vendors are similarly priced and
depend on the number of boxes you buy,
existing discount agreements, and the size
of the deals you are requesting
Expect competitive bids for larger systems and
similar vendor pricing for similar capabilities
57
Budgeting a HANA Migration Project — People
•
•
•
Experienced HANA consultants are in very high demand, so
budget $1,600 to $2,300 per day for these resources (US)
Testers with BW experience and some HANA training can be
found for more normal consulting rates
Solid hands-on migration experience with SP4, SP5, and higher is
key for SAP BW to HANA migrations. Don’t confuse this with a
HANA “sidecar” experience. It is very different.
When staffing your HANA project, don’t schedule
the start date before you get your staff. You want
the best resources, not whoever is available.
58
A Milestone Example
First we clean the BW
system, size the box, and
do a health check of the
overall system to finalize all
steps
Then we order hardware
and get the vendor to install
the hardware
Be prepared for 4-6 weeks
lead time for hardware
delivery
While waiting for hardware,
upgrade BW, apply SPS, and
execute training
59
A Milestone Example (cont.)
Start with refreshing the
sandbox from the
development environment
Migrate the Sandbox
carefully, and spend time
on testing
Do not rush this part of the
project, and document all
activities (create a
migration script of all
activities)
Plan “contingency” time for
any delays and do a cutover
on the weekend
ID
1.0
1.1
1.2
1.3
1.4
1.5
1.5
2.0
2.1
2.2
2.3
3.0
3.1
3.2
3.3
4.0
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
5.0
5.1
5.2
5.3
5.4
5.5
5.6
5.7
6.0
6.1
6.2
Task
BW Preparations
Clean BW system (12 steps)
Execute BW readiness check
Conduct hardware sizing
Obtain 2 quotes and select vendor
Finalize migration options (DMO) & upgrade steps required
Complete SP install and Upgrades required
HANA Install of Hardware
Vendor Install of Hardware
Install SAP BW software on HANA box
Conduct HANA health check
Onboarding
Execute training for HANA project team
Project charter, standards and procedures
Setup roles, security and access
HANA Migration
Copy BW to sandbox
Sandbox migration of database
Functional test of queries, security and interfaces
Test DTPs and loads
Checkpoint and lessons learned
BW Development box migration
Functional test of queries, security and interfaces
Test DTPs and loads
Copy Prod to QA box
BW QA box migration
Functional test of queries, security and interfaces
Test DTPs and loads
Backup Prod and contingency planning
BW Prod box migration
Functional validation of queries, security and interfaces
Validation of DTPs and loads
Contingency time
Project close
Lesson learned and issues review
Project close
Weeks (can be faster with larger teams, or smaller systems)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
60
What We’ll 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
61
Where to Find More Information
•
•
•
•
www.sap-press.com/products/SAP-HANA%3A-An-Introduction(2nd-Edition).html
 Bjarne Berg and Penny Silvia, SAP HANA: An introduction, SAP
Press; 2nd edition (May 1, 2013)
http://www.saphana.com/welcome
 SAP’s main page for all SAP HANA related information
http://www.saphana.com/community/try
 Powered by HANA demos
http://scn.sap.com/community/netweaver-bw-hana
 SAP NetWeaver BW Powered by SAP HANA Community
62
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
63
Your Turn!
How to contact me:
Dr. Berg
[email protected]
64
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.
65