Anda di halaman 1dari 54

Strategies for budgeting,

planning, and sizing your


SAP NetWeaver BW on SAP
HANA project

Dr. Bjarne Berg


COMERIT

© Copyright 2013
Wellesley Information Services, Inc.
All rights reserved.
In This Session …
• Strategies for budgeting, planning, and sizing your SAP NetWeaver BW on SAP
HANA project
• In this timely session, attendees will get expert recommendations for properly
sizing SAP NetWeaver BW on an SAP HANA system along with advice for staffing
and budgeting this complex project. Through real-life examples from five
companies, come away with a framework for:Sizing an SAP HANA system using
top-down techniques such as rule-of-thumb ratios and the t-shirt sizing model, as
well bottom-up sizing using Quick Sizer Budgeting for the hardware (based on five
different technologies), software, staff, and support resources necessary for
implementation and ongoing management
• The prerequisites for items such as Unicode, security, BW versions, and transport
requirements associated with moving an existing SAP NetWeaver BW system to
SAP HANA
• Take home a task-by-task milestone plan for SAP HANA implementation.

1 1
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required

• Wrap-Up

2
Introduction

• HANA is an in memory solution


that can take large volumes of
data, compress it, and store it
for extremely fast access by
thousands of users.

• It
is the ‘engine’ of the next
generation of computer systems
for analytics and transaction
processing

SAP HANA, as of 2013, can be used as the in-memory database


for BusinessSuite, BW and SAP’s BusinessOne Solution
3
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required

• Wrap-Up

4
SAP QuickSizer for HANA
There are three versions of the tool for each versions of SAP HANA.

The Quick Sizer for the


Rapid Deployment Solutions
(RDS) allows you to size for
specific tools.

The second Quick


Sizer version is for
The last is for those who want
SAP HANA on SAP
to use SAP HANA as a
NetWeaver BW
standalone platform for in-
memory data (i.e., using SAP
Data Services to load data to).

SAP’s Quick Sizer for SAP HANA, is available at


http://service.sap.com/quicksizer.
5
An Alternative SAP BW on HANA Sizing Tool

SAP has released a new ABAP based tool that generates a report significantly
better sizing fro SAP BW than using just the QuickSizer above. This program
takes into consideration existing database compression, different table types
and also include the effects of non-active data on the HANA system.

The higher precision


you run the estimate at
the longer the program To increase speed,
is going to run. you can also
suppress analysis
tables with less
than 1 MB size.
With 14 parallel
processors and 8Tb
data warehouse, it is
not unusual to see 45-
75 minutes run time.
6
SAP BW on HANA 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.

After you have downloaded and installed the program, and-selected the parameters
above, you can go to SE38 and run SDF/HANA_BW_SIZING as a background job.

The output is stored in the file you specified and the file can now be email emailed
to hardware vendors for sizing input and hardware selection.

This program is attached to SAP Note: 1736976 on SAP Marketplace


7
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 run-time 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.
8
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.5TB (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.
9
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.
10
A T-Shirt Model for Sizing HANA on BW

A T-shirt model is a quick


Data - Working Processors SAS/SSD Replication
Compress Memory (for data) Speed (per
ion (from) hour)
way to get some basic ideas Extra 7000–- 3072 GB 12+ Intel 10+ TB 20+ GB
on what a system may look Large
(XXL)
100,000
GB
to 20+ TB E7 2.4 Ghz

like.
(multi node)

Very 3500–- 2048 GB 8+ Intel E7 5 – 10 TB 20+ GB


Large 7000GB (multi node) 2.4 Ghz
(XL)

While very inaccurate for Large (L) 2000–-


3500GB
1024GB 4 x Intel
E7 2.4 Ghz
4 - 5 TB 5–20GB

sizing, it provides basic Medium 1250– 512GB 4 x Intel 2048GB 5–20 GB

information for those just


(M) 2000GB E7 2.0+
Ghz

staring considering SAP Small (S) 500–


1250GB
256GB 2 x Intel
E7 2.0+
1024GB 5GB

HANA Ghz

Extra 256– 128GB 2 x Intel 1024GB 5GB


Small 500GB E7 2.0+
(XS) Ghz

The number of processors are largely driven by the number of users and usage
patterns. Serious consideration should be made before buying hardware.
11
Summary of HANA Sizing Approaches

Approach Quality of Estimate Effort Required


T-Shirt Sizing  Sort of ‘OK” Very Low
Rule-of-Thumb  Better accuracy Low
SAP QuickSizer  Much better High
Sizing for BW program  Excellent Moderate

• Work with your preferred vendor before ordering your hardware or


finalizing your budgets.

SAP Note: 1514966 (SAP HANA: Sizing SAP HANA Database),


SAP Note 1637145 (SAP BW on HANA: Sizing SAP HANA Database),
SAP Note 1736976 (ABAP report to help with BW on HANA Sizing) .
12
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required

• Wrap-Up

13
Hardware Options for HANA
Hardware Memory
There are currently 7 different 128GB 256GB 512GB 1024GB

certified HANA hardware vendors Cisco C260 X X

with 13 different products. Cisco C460 X X

Cisco B440 X X+

Dell R910 X X X X

Hitachi CB 2000 X X X

NEC Express 5800 X X X+

Fujitsu RX 600 S5 X X X

Fujitsu RX 900 S2 X X+

HP DL 580 G7 X X X

HP DL 980 G7 X X

Some boxes can be used as single nodes HP BL 680 X X X X+

with others are intended for scale-out IBM x3690 X5 X X X

solutions for large multi-node systems IBM x3950 X5 X X X+


14
A HANA Hardware Example

In this box, we are


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 to a health check on your system
before handing it over to you. A 3-year service plan is also normally required.
15
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required

• Wrap-Up

16
Pre-Steps – Analyze BW Readiness
SAP has a checklist tool for
SAP NetWeaver BW powered by
HANA (thanks Marc Bernard).

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 version 2.x of this tool,


hundreds of checks are done
automatically in the BW system.
This includes platform checks
on database and application
and system information. There are even basis checks for support packs, ABAP/JAVA
stacks, Unicode, BW releases, and add-ons to your system.
17
Pre-Steps – Analyze BW Readiness

The idea of the checklist tool


from SAP 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..
18
New ABAP Check Program

19
New ABAP Check Program

20
New ABAP Check Program

21
New ABAP Check Program

22
New ABAP Check Program

23
New ABAP Check Program

24
Pre-Steps – Cleaning up your BW System

You can save significant amounts of work by doing a


cleanup effort before you start your HANA migration or
a BW upgrade project.

For example, a international company had a BW system with over 108


TB, with only 36TB in the production box and the remaining data on
their Near-Line Storage (NLS) solution.

This cleaned BW system saved them potentially millions of dollars in


hardware and HANA licensing costs.

It is not unusual to reduce a BW system size by


20-30% during a clean up effort.
25
12 Pre-Steps – Cleaning up your BW System

1. Clean the Persistent Staging Area (PSA) for data already loaded to DSOs
2. Delete the Aggregates (summary tables). They will not be needed again.
3. Compress the E and F tables in all InfoCubes. This will make InfoCubes
much smaller.
4. Remove data from the statistical cubes (they starts with the technical
name of 0CTC_xxx). These contain performance information for the BW
system running on the relational database. You can do this using the
transaction RSDDSTAT or the program RSDDSTAT_DATA_DELETE to
help you.
5. Look at log files, bookmarks and unused BEx queries and templates
(transaction RSZDELETE).
6. Remove as much as possible of the DTP temporary storage, DTP error
logs, and temporary database objects. Help and programs to do this
is found in SAP Notes 1139396 and 1106393.
26
12 Pre-Steps – Cleaning up your BW System

7) For write-optimized DSOs that push data to reportable


DSOs (LSA approach), remove data in the write-
optimized DSOs. It is already available in higher level
objects.

8) Migrate old data to Near-Line Storage (NLS) on a small server.


This will still provide access to the data for the few users who
infrequently need to see this old data. You will also be able to query
it when BW is on HANA, but it does not need to be in-memory.

7) Remove data in unused DSOs, InfoCubes and files used for staging
in the BW system. This include possible reorganization of
masterdata text and attributes using process type in RSPC

27
12 Pre-Steps – Cleaning up your BW System

10) You may also want to clean up background information stored in the table
RSBATCHDATA. This table can get very big if not managed. You should
also consider archiving any IDocs and clean the tRFC queues. All of this
will reduce size of the HANA system and help you fit the system tables on
the master node.

11) In SAP Note 706478, SAP provides some ideas on how to keep the basis
tables from growing too fast too fast in the future, and if you are on Service
Pack 23 on BW 7.0, or higher, you can also delete unwanted masterdata
directly (see SAP Note: 1370848).

12) Finally, you can use the program RSDDCVER_DIM_UNUSED to delete any
unused dimension entries in your InfoCubes to reduce the overall
system size.

28
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required

• Wrap-Up

29
Four Options for Migrating BW to HANA

 There are basically 4 different


approaches to migrating your BW
system to SAP HANA. Each are slightly
different. They may be summarized as:

1. Standard BW to HANA migration without Optimization


2. BW to HANA migration with Optimization
3. BW to HANA migration as a Re-implementation
4. 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
30
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 outlined above 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 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.
31
2. BW to HANA migration with Optimization

• In this approach the migration also involve the optimization of


data structures to take advantage of the new capabilities in HANA.
This may include HANA optimized Infocubes and DSOs, and ‘HANA
hints’ on data transformations to make lookups go faster.

• 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 DSOs.

How much additional optimization effort you are willing to undertake depends
on the resources available and how fast you have to complete the migration.
32
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 lo 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 area.
33
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, applying notes or upgrades required.


Then reconciling the BW and the new BW on HANA system from a functional
standpoint. (interfaces, openhubs, reports, analytics, security, and data)
• When the tests are done, the process chains are run and the data is reconciled again.
• To do this you need to plan carefully and run duplicated process chains to avoid
impacts to the ERP system. It requires load programs to load the data to both the BW
and the HANA system without impacting delta loads. But, it can be done.

After testing, you can switch the users over to the


new BW HANA box and de-commission the old BW.
34
Summary of BW to HANA Migration Options

Most
Approach Effort Risk Benefits
Common
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


(no optimization)

For many organization a migration of their BW systems to


HANA (technical migration), followed by a later functional
optimization is the most common approach (so far).
35
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required

• Wrap-Up

36
Staffing a HANA Migration Project – Small Team
Area Role Staff area Jun Jul Aug Sep
System Profile Project manager Company 50% 50% 50% 50%

Raw data size: 2.7 TB Core


BW Basis Support
HANA Basis Support
Company 75%
Consultant 100%
75%
100%
100%
100%
75%
75%
team
Complexity: Medium HANA Optimization developer Consultant 100% 100% 100% 50%
HANA Test & resolution lead Consultant 100% 100% 100% 50%
DataStores: 87 Test
Functional Tester - Finance & COPA Business 25% 50%
Functional Tester - Sales and Distribution Business 25% 50%
InfoCubes: 63 team
Functional Tester - MFG & Sourcing Business 25% 50%

Queries: 409
 This assumes that the test team is dedicated for 3 weeks
during the migration of QA and Prod environments
Duration: 14 weeks
Environments: 4+1  The test team from the business is already experienced
users of the BW system and need minimal training
Risk aversion: Medium
Other usage: IP  HANA Optimization of InfoCubes and DSOs are currently
for SD only for this organization.

This organization is using BWA and will be


retiring it as part of the HANA migration 37
Staffing a HANA Migration Project – Medium Team
Area Role Staff area Jan Feb Mar Apr May
System Profile Project manager Company 25% 25% 25% 25% 25%
Technical project manager Consultant 100% 100% 100% 100% 100%
Raw data size: 5.6 TB Core
team
Project Advisor Consultant 20% 20% 20% 20% 20%
BW / HANA Basis Support Company 75% 100% 100% 100% 75%
Complexity: Medium HANA Basis Support Consultant 100% 100% 100% 100%
Test Team: BW Technical test lead Company 75% 100% 100%
DataStores: 439 Finance Functional Tester - Finance Business 50% 50%
HANA Test & resolution lead Consultant 75% 100% 100%
InfoCubes: 603
Test Team:
SD & Commissions Functional Tester - Sales & Distribution Business 50% 50%
75% 100% 100%
Queries: 1,300+ Test Team: BW Technical tester Company
Other Areas Functional Tester - Other areas Business 50% 50%
(incl. BOBJ)

 This assumes testing of core queries in BEx and


Duration: 18 weeks WebIntelligence is done by the business
Environments: 4
 The data reconciliation and process chain testing is
Risk aversion: HIGH
done by dedicated resources in each team.
Other usage: None
 This team must be staffed with experienced resources.
HANA training for team members and hardware installs
must be in place prior to project start.
38
Staffing a HANA Migration Project – Very Large Team
System Profile Area Role Staff Mar Apr May June July Aug
Project manager Company 100% 100% 100% 100% 100% 75%
Raw data size: 38TB Technical project manager Consultant 100% 100% 100% 100% 100% 75%
BW Basis Support Company 75% 75% 50% 50% 100% 75%
Complexity: High Core
team
HANA Basis Support Consultant 100% 100% 100% 100% 100% 75%
Project Advisor Consultant 20% 20% 20% 20% 20% 20%
DataStores: 1,300+ HANA Optimization developer Consultant 100% 100% 100% 100% 100%
Support team Representative Company 50% 50% 50% 50% 50% 100%
InfoCubes: 1,720+ Test Team:
BW Technical test lead Company 50% 50% 50% 100% 100%
HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%
Queries: 2,200+ Finance and
BPC
Functional Tester - Finance Business 25% 25% 50%
Functional Tester - BPC Business 25% 25% 50%
BW Technical test lead Company 50% 50% 50% 100% 100%
Test Team:
HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%
Duration: 5 mos Sales and
Distribution
Consultant Test team lead and Sales Business 25% 25% 50%
Functional Tester - Delivery Business 25% 25% 50%
Environments: 4 BW Technical test lead Company 50% 50% 50% 100% 100%
Test Team: HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%
Risk aversion: HIGH Manufacturing Consultant Test team lead and Sales Business 25% 25% 50%
Functional Tester - Delivery Business 25% 25% 50%
Other usage: APO, IP, BW Technical test lead Company 50% 50% 50% 100% 100%
Test Team:
100% 100% 100% 100% 100%
BPC
HANA Test & resolution lead Consultant
Global
Functional Tester - PO and Spend Business 25% 25% 50%
Sourcing
Functional Tester - AP and Performance Business 25% 25% 50%

This assumes minimal Test Team:


BW Technical test lead
HANA Test & resolution lead
Company
Consultant
50% 50%
100% 100%
50%
100%
100%
100%
100%
100%
additional functional HR and
Planning
Functional Tester - HR Business 25% 25% 50%
Functional Tester - IP Business 25% 25% 50%
optimization 39
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration Four BW to HANA Migration
Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required
• Wrap-Up

40
Budgeting a HANA Migration Project - Systems
There are 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 include 3-years support in your purchase

• Upgrades
Plan and budget for any BW upgrades required before going to HANA (7.3)

Do the pre-steps BW cleanup we outlined earlier as soon as possible


and then the formal sizing effort, before requesting a hardware quote.
41
Small Example HW Quotes - Dell
This is example is a quote for a smaller
128 GB Memory Box with 2 x 10 cores 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 prices and
depends 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
42
Mid-Size Budgeting Example HW Quotes - HP

This example quote is for a


mid-sized 512 GB memory
box with 4 x 10 cores 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

Certified HANA vendors such as HP, IBM, Dell, Cisco, NEC, Hitachi and
Fujitsu has dedicated staff to help you get a detailed quote in matter of days.
43
Large Example HW Quotes - Fujitsu

This is example
is a quote for a
Large 1 TB
Memory Box for
only $105,000

44
Budgeting a HANA Migration Project - People

Remember to budget for


HANA training for your
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 on average
plus travelling costs. 45
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 and SP5 is key
for SAP BW to HANA migrations. Don’t confuse this with
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.
46
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required
• Wrap-Up

47
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, 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.
48
On-Going Support Tasks and Staff Required
The staffing roles required is normally:
- One basis resource for system admin and monitoring for every
4-5 environments (do you need 24-hours 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.
49
What We’ll Cover …

• Introduction
• Sizing Your HANA System
• HANA Hardware Options
• Pre-Steps for BW to HANA Migration
• Four BW to HANA Migration Options
• Staffing a HANA Migration Project
• Creating a Budget for your HANA Migration Project
• On-Going Support Tasks and Staff Required

• Wrap-Up

50
Where to Find More Information

• www.sap-press.com/products/SAP-HANA%3A-An-Introduction.html
• SAP HANA: An introduction. Book by Dr. Berg and Penny Silvia
published by SAP Press.

• http://www.saphana.com/welcome
• SAP’s Main page for all SAP HANA related information

• http://www.saphana.com/community/try
• BW Powered by HANA Demo

• http://scn.sap.com/community/netweaver-bw-hana
• SAP NetWeaver BW Powered by SAP HANA Community
51
7 Key Points to Take Home

• Cleaning your BW system (12 steps) will make your HANA system
smaller and less costly
• There are programs to do readiness checks for a BW system
• There are programs to do sizing of a BW system
• While one is more common, there are actually 4 possible
approaches to the HANA migration project
• There are 7 different certified HANA vendors and many options for
small, medium and large systems
• Budgeting should include HANA training, BW cleanup, BW 7.3
upgrade (SPS), as well as support staff required or reorganized
• Most HANA projects can be done in matter of weeks, only
extremely large systems may require 4-7 months.

52
Your Turn!

How to contact me:


Dr. Bjarne Berg
Bberg@Comerit.com
Please remember to complete your session evaluation

53