JUMP-START (Part 1): Proven best practices for an SAP HANA implementation or migration: A deep dive into how to plan, scope, budget, and execute a successful.

JUMP-START (Part 1): Proven best practices for an SAP HANA implementation or migration: A deep dive into how to plan, scope, budget, and execute a successful project Dr. Bjarne Berg PwC

What We’ll Cover Introductions
Sizing an SAP HANA environment for SAP BW 7.5 and ECC 6.0 HANA Live Reporting for Suite on HANA (ECC migrated to HANA) SAP HANA Environment Deployment Options Hardware Options Creating Staffing plans and Milestone Plans for Your HANA Migration Top-10 Lesson learned from HANA migrations Wrap-up

In This Session Part 2 of this session
Evaluate various deployment scenarios, and determine the best option based on your technical landscape Find out how to create a detailed SAP HANA hardware plan Budget your SAP HANA initiative appropriately based on the system size, complexity and team organizations Migration a BW system or a ECC system to SAP HANA Explore data load and front-end BI tools connectivity options Part 2 of this session

Data is growing everywhere
2030 2010s 2000s 1990s 1980s 1970s s

More Data is coming - The Internet of Things (IoT)
An History Lesson: Devices such as sensors, CCTV, TVs, cars, refrigerators, home security systems, dishwashers, Air- conditioners, power meters, toll road systems, facial recognition and much more is being connected through the IoT. Enormous amounts of data is collected by these devices Source: Syed Hoda, 2015

What is Holding us Back? 0.05 413.22 8264x 291,271x 0.02 5,825 216 264
Technology Focus 1990 2016 Improvement 0.05 MIPS/$ 413.22 MIPS/$ 8264x CPU 291,271x 0.02 MB/$ 5,825 MB/$ Memory 216 264 248x Addressable Memory 100 Mbps 200 Gbps 2,000 x Network Speed Hard Drives 5 MBPS 690 MBPS 138x Source: 1990 numbers SAP AG, 2016 numbers, Dr. Berg Source: BI Survey of 534 BI professionals, InformationWeek, Disk speed is growing slower than all other hardware components, while the need for speed is increasing

Number of SAP HANA Customers is Growing Fast
HANA is no longer bleeding-edge technology, it is on track to almost 10,000 installations in 2016

The Rate of Change – Disruptive Technologies
Moore’s Law in technology: Processing Speed will double every 18 month Paradigm shifts: SAP HANA reads are executed times faster than on traditional relational databases such as Oracle 12g The rate of change in Paradigm Shifts is much faster than the incremental changes and a much lower cost

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

Summary: The Most Common HANA Scenarios

HANA Sizing Tool for Existing BW Implementations
Using the BW Automated Sizing Tool in the Migration Cockpit

HANA Sizing Tool for Existing BW Implementations (cont.)
To increase speed, you can suppress analysis tables with less than 1MB size 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 databases, 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 8 parallel processors and a 10TB database, it is not unusual to see 4-5 hours runtime

SAP BW on HANA Automated Sizing Tool
Real Example 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 ed to hardware vendors for sizing input and hardware selection. This program is referenced in SAP Notes and on the SAP Service Marketplace

HANA Sizing for SAP ERP migrations - Example
SAP has a similar sizing program available for planning an ECC migration to HANA Real Example To access this program and also get more information on how to install and run it, please refer to SAP Note Suite on HANA memory sizing

Three Sizing Options for BW on HANA
QuickSizer – New implementation only, not migrations BW Automated Sizing Tool in the Migration Cockpit Rule of Thumb SAP’s QuickSizer for SAP HANA is available at: * Requires login credentials to the SAP Service Marketplace.

SAP QuickSizer for New BW on HANA Implementations
If you’re using planning in SAP BW, enter the info here. The fields marked with * are mandatory. For H-PLANN-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.

SAP QuickSizer for BW on HANA — Output
This SAP HANA sizing example calls for 1.6TB of memory In this case, SAP HANA for BW will deploy the master data, ABAP system tables, and most row store data on the master node. The other connected Index server node(s) will contain the InfoCubes and DSOs.

Rule-of-Thumb Approach to Sizing HANA — Memory
Memory = 50GB + [ (rowstore tables footprint / 1.5) + (colstore tables footprint * 2 / 4) ] * Existing DB Compression The 50GB 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 them for finalized budgeting and hardware purchases

Rule-of-Thumb Approach to Sizing HANA — Disk and CPU
The next item you need is disk space, which can be estimated by the following: 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. The CPUs are based on the number of cores that you include. For example, 18 core CPUs now exist (depending on when you bought your system). If you have a single node with 8 x 18 cores, you will have 144 cores and can handle about 720 active BW users on that hardware node, and quite a larger number of named users. Disk for persistence layer = 4 Memory Disk for the log = 1 Memory CPU = 0.2 CPU cores per active user Remember, these are quick rules of thumb, so don’t rely on them for finalized budgeting and hardware purchases

SAP HANA Live does NOT replace SAP BW
SAP HANA Live vs. SAP BW 7.5 SAP HANA Live is for real-time analytics, reporting, and applications SAP BW is for management reporting, forecasting, and trend analytics and functions as the enterprise data warehouse for historical data, summarized data BW supports time-dependent master data and is the corporate “repository” for the historical data for an organization SAP HANA Live does NOT replace SAP BW

The Virtual Data Models (VDMs)
VDMs take the foundational views of SAP HANA and categorize them into several view types including private views, reuse views, and query views Private views are the most basic view type that directly use SAP tables. Reuse views are those views created by combining private views and other composite tables. Finally, the query views are one or more reuse views joined together to report on various business scenarios. Normally, these query views are directly used for reporting. As of Jan 2016, there were 242 query views available for reporting straight out of the box when installing SAP HANA Live.

The SAP Live Extension Assistant
SAP offers a tool to assist with the view copying and extension process (available since mid-2014) called SAP Live Extension Assistant This tool automates much of the process, thereby reducing the effort required to add additional fields to your SAP HANA view Using this tool enables you to copy and extend reuse and query views within SAP HANA Live Copying the view in this way assures that you are not impacting others using the standard view, and also speeds up the development process. This way, you only have to focus on the additions you are making and do not have to know all the underlying complexity that may exist in the views (some have 8 to 10 nested views and custom joins).

Reporting on SAP HANA Live with SAP BusinessObjects
In general, reporting in the SAP BusinessObjects suite is done on top of a universe when consuming SAP HANA Live data. The universe layer provides a customizable semantic layer between the SAP HANA calculation views and the end-reporting tool. In order to use the real-time reporting capabilities of SAP HANA Live, the query views are used straight on top of the Business Suite and no data is moved to the EDW (like in BW) It is important to note that some of the newer SAP data visualization and reporting tools (such as SAP Lumira) have native connectivity to SAP HANA and can skip the need to connect through an SAP BusinessObjects universe, allowing you to connect directly to the views This direct connection to SAP HANA query views can allow for less latency in reporting, which means even faster front-end execution of reports and visualizations.

Historical Landscape Deployment Planning Options
Scenario Virtualization MCOS MCOD Technical Co-Deployment HANA DBs Multiple One DB Schema Availability Supported for DEV & QA systems Defined by: White List for BW White List for Suite Business Suite components SCM and/or SCM co-deployed with ERP

Save Money with MCOD and MCOS
You may not need separate hardware for sandbox and development environments Using Multiple Components One Database (MCOD) and/or Multiple Components One System (MCOS) you can simplify the number of hardware environments you need SAP 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 for more details)

MCOS Example from Real Company
Real Example Note that the QA and Production system are kept the same size so that performance tests are accurate and so that the QA system can be used as for disaster recovery

MDC became available with SP-9 of HANA in 2015
New Deployment Option – Multitenant Database Containers (MDC) Deployments APPLICATIONS A tenant database is a single database container You can save money by running multiple tenant databases on a single HANA system MDC is supported for production systems and you can backup for each tenant database You can manage resources such as memory and CPU for each of the tenant databases Application A Application B SAP HANA System Database Tenant Database Tenant Database MDC became available with SP-9 of HANA in 2015

MDC Deployments Details
MDC can be used in Platform & Enterprise Cloud For on-premise it can replace most MCOS deployments and many of the MCOD scenarios There is no virtualization overhead, and scale-out systems with standby nodes is supported You can use SQL to query across databases: I.e., SELECT * FROM schema1.Customers AS tab1, db2.schema2.Customers as tab2 WHERE tab2.column2 = ‘Johnson’ NOTE: Attribute and analytic views must be converted to calculation views to be used as remote tenant database objects Individual database backups and restores can be done from HANA Studio A new privilege “Database Admin” allows you to separate admin access to each database You can convert a HANA system to MDC, but it cannot be converted back (command: hdbnsutil –convertToMultiDB)

Migration BW to HANA: Select from two different 7.5 versions
For companies with BW 7.3 or 7.4 on HANA, or those who have not yet migrated to HANA, it makes sense to upgrade and migrate to BW 7.5 on HANA first, and then migrate to the new objects. For those staring with a new implementation, it makes sense to start directly with BW 7.5 Edition for HANA and only use the new simplified and faster objects

Hardware Options 2016 Onward
IBM Power 880

HANA Hardware Example – IBM 3850 X6

Key Hardware Options 2016 Onward
Note: All power8 servers from IBM are now also certified to run HANA

Key Cloud Options

Staffing a BW HANA Migration Project — Small Team
System Profile Raw data size: TB Complexity: Medium DataStores: InfoCubes: Queries: Duration: weeks Environments: Risk aversion: Medium Other usage: Integrated Planning 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

Staffing a BW HANA Migration Project — Medium Team
System Profile Raw data size: TB Complexity: Medium DataStores: InfoCubes: Queries: ,300+ (incl. BOBJ) Duration: weeks Environments: Risk aversion: HIGH Other usage: None 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.

Staffing a BW HANA Migration Project — Very Large Team
System Profile Raw data size: TB Complexity: High DataStores: ,300+ InfoCubes: ,720+ Queries: ,600+ Duration: mos Environments: 4 Risk aversion: HIGH Other usage: APO, IP, BPC This assumed minimal additional functional optimization

Example - Staffing a ECC to HANA Migration Project
System Profile Raw data size: TB Complexity: High Modules: FI-CO, SD, MM, HR Users: 873 Duration: months Environments: 4 Risk aversion: HIGH This assumed minimal additional functional optimization and ABAP remediation where required

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

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

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

1. Lessons Learned: Buy Hardware Early
The typical lead time for the basic HANA appliances is as little as 4-8 weeks However, for large scale environments, or multi-node environments, the lead times can sometimes be as long as weeks 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

2. Lessons Learned: Get the Right Team Members
While there are many with basic certifications in HANA, the pool of qualified experienced resources is limited Great HANA resources are most likely working on another project already 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.

3. Lessons Learned: Include Training for your Staff
There are a lot of “myths” and beliefs about HANA that your have to address early Before you start the project, make sure your implementation partner has a formal written training plan on how they will provide knowledge transfer 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.

4. Lessons Learned: Hardware Sizing Should Include Growth
Some customers forget that sizing would be for 3 years out and not based on current system size alone 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

5. Lessons Learned: “Master-Node” Size
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. 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.

6. Lessons Learned: Create an Ecosystem of Experts
Having access to the best and brightest within SAP, consulting firms, and industry experts is key when issues or questions arise 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.

7. Lessons Learned: Think BIG
A HANA implementation should not be treated as a replacement project. It is an enabler … 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 …

8. Lessons Learned: Plan for Reporting and System Consolidation
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.

9. Lessons Learned: Near-Line Storage Can Save Millions
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. In one project a customer took his system from 112 TB to 38 TB by simply moving data to near-line storage (NLS) 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.

10. Lessons Learned: Save Money with MCOD and MCOS
You may not need separate hardware for sandbox and development environments Using Multiple Components One Database (MCOD) and/ or Multiple components One System (MCOS) you can simplify the number of hardware environments you need 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 for more details) Seriously consider MDC as an alternative to save on hardware costs

Where to Find More Information
Bjarne Berg and Penny Silvia, SAP HANA: An introduction, SAP Press; 3rd edition  Select SAP Business Warehouse SAP BW 7.5 SAP Core help website SAP HANA consolidated web site from SAP Michaela Pastor, “SAP Business Warehouse 7.5” (SCN, September 2015).

7 Key Points to Take Home SAP has pre-check programs for both BW, SoH and S/4 that you should use early in your planning phase Scale-up HANA systems are easier to manage Sizing programs for existing BW and ECC systems are very accurate HANA is no-longer something on the ‘bleeding-edge’ is a mainstream technology Most customers should plan and execute their migrations to HANA in 2016 The skill set of the different hardware vendors varies by geography, but dozens of options exists Training should be planned for both developers and basis as part of your HANA project

Please remember to complete your session evaluation
Your Turn! How to contact me: Dr. Bjarne Berg Please remember to complete your session evaluation

JUMP-START (Part 1): Proven best practices for an SAP HANA implementation or migration: A deep dive into how to plan, scope, budget, and execute a successful.

Similar presentations

Presentation on theme: "JUMP-START (Part 1): Proven best practices for an SAP HANA implementation or migration: A deep dive into how to plan, scope, budget, and execute a successful."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

JUMP-START (Part 1): Proven best practices for an SAP HANA implementation or migration: A deep dive into how to plan, scope, budget, and execute a successful.

Similar presentations

Presentation on theme: "JUMP-START (Part 1): Proven best practices for an SAP HANA implementation or migration: A deep dive into how to plan, scope, budget, and execute a successful."— Presentation transcript:

Similar presentations

About project

Feedback