a -to-z guide to implementing sap hana

© Copyright 2014Wellesley Information Services, Inc.

All rights reserved.

An A-to-Z Guide to Implementing SAP HANA: Planning, Scoping, Staffing, Budgeting, and ExecutionBjarne BergComerit

2

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

3

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

4

HANA Editions and Components

Area Component ID Component NameBC-HAN-SL-STP SAP HANA unified installerBC-HAN-UPD Software Update ManagerBC-DB-HDB-INS SAP HANA database installationBC-DB-HDB-UPG SAP HANA database upgradeBC-HAN-DXC SAP HANA Direct Extractor ConnectionEIM-DS SAP Data Services: ETL-basedBC-HAN-LOA SAP HANA Load Controller: log-based BC-HAN-LTR SAP Landscape Transformation (SLT): trigger-basedBC-HAN-REP Sybase Replication Server: log-basedBI-BIP-CMC, BI-BIP BI PlatformBI-RA-WBI Web IntelligenceBI-RA-XL Dashboard DesignerBI-RA-CR, BI-BIP-CRS SAP Crystal reportsBI-RA-EXP SAP BusinessObjects ExplorerBI-BIP-IDT Information Design Tool (for universes)BI-RA-AO-XLA Microsoft Excel add-in

Lifecycle Management

End User Clients

Enterprise Edition

(also have platform edition components)

Area Component ID Component NameBC-DB-HDB SAP HANA databaseBC-DB-HDB-ENG SAP HANA database engineBC-DB-HDB-PER SAP HANA database persistenceBC-DB-HDB-SYS SAP HANA database interfaceBC-DB-HDB-DBA SAP HANA database/DBA cockpitBC-DB-HDB-POR SAP HANA DB PortingBC-DB-HDB-BAC SAP HANA Backup and RecoveryBC-CCM-HAG SAP Host agentBC-DB-HDB-CCM SAP HANA CCMS BC-DB-HDB-CLI SAP HANA Clients (JDBC/ODBC)BC-DB-HDB-R SAP HANA Integration with RBC-DB-HDB-SCR SAP HANA SQL scriptsBC-DB-HDB-MDX MDX engine: Microsoft Excel clientBC-HAN-MOD SAP HANA Studio - Information ModelerBC-HAN-3DM Information ComposerBC-HAN-SRC SAP HANA UI toolkitBC-DB-HDB-TXT SAP HANA Text and Search featuresBC-DB-HDB-DXC SAP HANA Direct extraction connectorBC-DB-HDB-SEC SAP HANA Security and User MgmtBC-DB-HDB-XS SAP HANA Application ServicesBC-DB-HDB-AFL SAP HANA Advanced functions libraryBC-DB-HDB-AFL-PAL SAP HANA Predictive analysis libraryBC-DB-HDB-AFL-SOP SAP HANA Sales & Operations PlanningBC-DB-HDB-PLE SAP HANA Planning Engine

Platform Edition

• While HANA is sold as an appliance, there are many internal components and the edition you buy may contain different licenses to these components.

5

HANA Release Strategy and Names

• 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

Source: SAP AG, SAP HANA Product Management, Dec 2013.

6

HANA Demo — SAP BusinessObjects on HANA

7

What We’ll Cover


8

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

9

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.

10

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.

11

Four Options for Migrating BW to HANA

1. Standard BW to HANA migration without Optimization2. BW to HANA migration with Optimization3. 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

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

12

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.

13

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.

14

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 area.

15

4. Migrate a Copy of BW to HANA

• This alternative approach can be used byorganizations 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

16

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)

17

Summary: The Most Common HANA Scenarios

18

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 on database and application and system information.

Pre-Steps — Analyze BW Readiness

There are even Basis checks for support packs, ABAP/JAVA stacks, Unicode, BW releases, and add-ons to your system

19

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

Pre-Steps — Analyze BW Readiness (cont.)

This tool does not replace the upgrade tasks in the ASU, which we will examine in Part 2 of the session in more detail

20

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

21

What We’ll Cover


22

Some Hardware Options for HANA

There are many certified HANA hardware vendors with over a dozen different products.

Some boxes can be used as single nodes with others are intended for scale-out, scale up, solutions for large multi-node systems

Hardware Memory

128GB 256GB 512GB 1024GB

Cisco C260 X X

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

HP BL 680 X X X X+

IBM x3690 X5 X X X

IBM x3950 X5 X X X+

23

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.

24

SAP QuickSizer for HANA

There are three versions of the tool for each version of SAP HANA

SAP’s QuickSizer for SAP HANA is available at http://service.sap.com/quicksizer.

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

The second QuickSizer version is for SAP HANA on SAP NetWeaver BW

The QuickSizer for the Business Suite allows you to size for specific modules

25

SAP QuickSizer for New BW HANA ImplementationsIf 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.

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.

Enter the estimated number of information consumers (H-BW-INFO), 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.

26

SAP QuickSizer for New BW HANA Implementations (cont.)

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.

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.

NOTE: The QuickSizer should only be used for new HANA implementations and not for migration of existing systems

27

SAP QuickSizer for New BW HANA Implementations (cont.)

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.

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.

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.

28

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.

SAP QuickSizer for HANA — Output

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.

29

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).

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.

To increase speed, you can suppress analysis tables with less than 1 MB size.

With 12 parallel processors and 10TB database, it is not unusual to see 30-70 minutes runtime

30

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.

This program is referenced in SAP Notes 1909597 and 1736976 on the Service Marketplace

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.

31

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

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

Memory = 50 GB + [ (rowstore tables footprint / 1.5) + (colstore tables footprint * 2 / 4) ] * Existing DB Compression

Remember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases

32

Rule of Thumb Approach to Sizing HANA — Disk• The next item you need is disk space, which can be estimated by the

following:

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

Disk for persistence layer = 4 MemoryDisk for the log = 1 Memory


33

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).

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

CPU = 0.2 CPU cores per active user


34

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 -Compression (from)

Working Memory

Processors SAS/SSD (for data)

Replication Speed (per hour)

Extra Large (XXL)

7000–-100,000 GB

3072 GB

to 20+ TB

(multi node)

12+ Intel E7 2.4 Ghz

10+ TB 20+ GB

Very Large (XL)

3500–-7000GB

2048 GB

(multi node)

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


1024GB 5GB

Extra Small (XS)

256–500GB


1024GB 5GB

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

35

Summary of HANA Sizing Approaches

Approach Quality of Estimate Effort RequiredT-Shirt Sizing Sort of “OK” Very LowRule of Thumb Better LowSAP QuickSizer Much better (new implementations only) HighSizing for BW program Excellent (for existing BW systems) 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)

36

What We’ll Cover


37

Staffing a HANA Migration Project — Small Team

System ProfileRaw data size: 2.7 TBComplexity: MediumDataStores: 87InfoCubes: 63Queries: 409

Duration: 14 weeksEnvironments: 4+1Risk aversion: MediumOther usage: Integrated

Planning

This organization was using BWA 7.0 and retired it as part of the HANA migration, thereby saving licensing costs for this platform

Jun Jul Aug SepProject manager Company 50% 50% 50% 50%BW Basis Support Company 75% 75% 100% 75%HANA Basis Support Consultant 100% 100% 100% 75%HANA Optimization developer Consultant 100% 100% 100% 50%HANA Test & resolution lead Consultant 100% 100% 100% 50%

Functional Tester - Finance & COPA Business 25% 50%Functional Tester - Sales and Distribution Business 25% 50%Functional Tester - MFG & Sourcing Business 25% 50%

Test team

Area Role Staff area

Core team

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

38

Staffing a HANA Migration Project — Medium Team

System ProfileRaw data size: 5.6 TBComplexity: MediumDataStores: 439InfoCubes: 603Queries: 1,300+(incl. BOBJ)

Duration: 18 weeksEnvironments: 4Risk aversion: HIGHOther usage: None

Jan Feb Mar Apr MayProject manager Company 25% 25% 25% 25% 25%Technical project manager Consultant 100% 100% 100% 100% 100%Project Advisor Consultant 20% 20% 20% 20% 20%BW / HANA Basis Support Company 75% 100% 100% 100% 75%HANA Basis Support Consultant 100% 100% 100% 100%

BW Technical test lead Company 75% 100% 100%Functional Tester - Finance Business 50% 50%

HANA Test & resolution lead Consultant 75% 100% 100%Functional Tester - Sales & Distribution Business 50% 50%

BW Technical tester Company 75% 100% 100%Functional Tester - Other areas Business 50% 50%

Test Team: Other Areas

Area Role Staff area

Core team

Test Team: Finance

Test Team: SD & Commissions

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.

39

Staffing a HANA Migration Project — Very Large Team

System ProfileRaw data size: 38TBComplexity: HighDataStores: 1,300+InfoCubes: 1,720+Queries: 2,600+

Duration: 5 mosEnvironments: 4Risk aversion: HIGHOther usage: APO, IP, BPC

This assumed minimal additional functional

optimization

Mar Apr May June July AugProject manager Company 100% 100% 100% 100% 100% 75%Technical project manager Consultant 100% 100% 100% 100% 100% 75%BW Basis Support Company 75% 75% 50% 50% 100% 75%HANA Basis Support Consultant 100% 100% 100% 100% 100% 75%Project Advisor Consultant 20% 20% 20% 20% 20% 20%HANA Optimization developer Consultant 100% 100% 100% 100% 100%

Support team Representative Company 50% 50% 50% 50% 50% 100%

BW Technical test lead Company 50% 50% 50% 100% 100%HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%Functional Tester - Finance Business 25% 25% 50%

Functional Tester - BPC Business 25% 25% 50%

BW Technical test lead Company 50% 50% 50% 100% 100%HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%Consultant Test team lead and Sales Business 25% 25% 50%Functional Tester - Delivery Business 25% 25% 50%

BW Technical test lead Company 50% 50% 50% 100% 100%HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%Consultant Test team lead and Sales Business 25% 25% 50%Functional Tester - Delivery Business 25% 25% 50%

BW Technical test lead Company 50% 50% 50% 100% 100%HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%Functional Tester - PO and Spend Business 25% 25% 50%

Functional Tester - AP and Performance Business 25% 25% 50%

BW Technical test lead Company 50% 50% 50% 100% 100%HANA Test & resolution lead Consultant 100% 100% 100% 100% 100%Functional Tester - HR Business 25% 25% 50%Functional Tester - IP Business 25% 25% 50%

Role Staff

Core team

Test Team: HR and

Planning

Test Team: Finance and

BPC

Test Team: Sales and

Distribution

Test Team: Manufacturing

Test Team: Global

Sourcing

Area

40

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

41

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.

42

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.

43

HANA Demo — The SAP BusinessObjects Front-End Tools on HANA

44

What We’ll Cover


45

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 multi-node 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

46

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.

47

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.

48

4. Lessons Learned: Hardware Sizing ShouldInclude 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

49

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.

50

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.

51

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 …

52

8. Lessons Learned: Plan for Reporting and System Consolidation

1. 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

2. 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.

53

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.

54

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 needa) SAP NetWeaver BW on SAP HANAb) SAP Finance and Controlling Accelerator for the material ledgerc) ERP operational reporting with SAP HANAd) SAP Finance and Controlling Accelerator: Production Cost Planninge) SAP Rapid Martsf) SAP COPA Acceleratorg) SAP Operational Process Intelligenceh) SAP Cash Forecastingi) SAP Application Accelerator / Suite Acceleratorj) 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)

55

What We’ll Cover


56

Budgeting a HANA Migration Project - Systems

• There is a set of items you need to budget for. From asystem 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

57

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

58

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

59

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.

60

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

61

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 181.0 BW Preparations1.1 Clean BW system (12 steps)1.2 Execute BW readiness check1.3 Conduct hardware sizing1.4 Obtain 2 quotes and select vendor1.5 Finalize migration options (DMO) & upgrade steps required1.5 Complete SP install and Upgrades required2.0 HANA Install of Hardware2.1 Vendor Install of Hardware2.2 Install SAP BW software on HANA box2.3 Conduct HANA health check3.0 Onboarding3.1 Execute training for HANA project team3.2 Project charter, standards and procedures3.3 Setup roles, security and access4.0 HANA Migration4.1 Copy BW to sandbox4.2 Sandbox migration of database4.3 Functional test of queries, security and interfaces4.4 Test DTPs and loads4.5 Checkpoint and lessons learned4.6 BW Development box migration4.7 Functional test of queries, security and interfaces4.8 Test DTPs and loads4.9 Copy Prod to QA box5.0 BW QA box migration5.1 Functional test of queries, security and interfaces5.2 Test DTPs and loads5.3 Backup Prod and contingency planning5.4 BW Prod box migration5.5 Functional validation of queries, security and interfaces5.6 Validation of DTPs and loads5.7 Contingency time6.0 Project close6.1 Lesson learned and issues review6.2 Project close

Weeks (can be faster with larger teams, or smaller systems)Task ID

62

What We’ll Cover


63

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

http://www.sap-press.com/products/SAP-HANA:-An-Introduction-(2nd-Edition).html

http://www.sap-press.com/products/SAP-HANA:-An-Introduction-(2nd-Edition).html

http://www.saphana.com/welcome

http://www.saphana.com/community/try

http://scn.sap.com/community/netweaver-bw-hana

64

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

65

Your Turn!

How to contact me:Dr. Berg

[email protected]

66

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.

a -to-z guide to implementing sap hana

Documents