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

An A-to-Z Guide to Implementing SAP HANA: Planning, Scoping, Staffing, Budgeting, and Execution
Bjarne Berg Comerit

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

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

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.

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.

HANA Demo — SAP BusinessObjects on HANA

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

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.

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.

Four Options for Migrating BW to HANA 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 There are basically four different approaches to migrating your BW system to SAP HANA. Each are slightly different. They may be summarized as: 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

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.

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.

3. BW to HANA Migration as a Re-Implementation Some organizations have decided to take the BW to HANA migration as a re-implementation approachto 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 InfoProvidersin 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.

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

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)

Summary: The Most Common HANA Scenarios

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

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

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

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

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.

SAP QuickSizer for HANA There are three versions of the tool for each version of SAP HANA The QuickSizerfor the Business Suite allows you to size for specific modules The second QuickSizerversion is for SAP HANA on SAP NetWeaver BW 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) SAP’s QuickSizerfor SAP HANA is available at http://service.sap.com/quicksizer.

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

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

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

SAP BW on HANA Sizing Tool for ExistingBW Implementations To increase speed, you can suppress analysis tables with less than 1 MB 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 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

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 Marketplace

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

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 Memory Disk for the log = 1 Memory Remember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases

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 Remember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases

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 The number of processors are largely driven by the number of users and usage patterns. Serious consideration should be made before buying hardware.

Summary of HANA Sizing Approaches Approach Quality of Estimate Effort Required T-Shirt Sizing  Sort of “OK” Very Low Rule of Thumb  Better Low SAP QuickSizer  Much better (new implementations only) High Sizing 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)

Staffing a HANA Migration Project — Small Team System Profile Raw data size: 2.7 TB Complexity: Medium DataStores: 87 InfoCubes: 63 Queries: 409 Duration: 14 weeks Environments: 4+1 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 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 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 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

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

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.

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.

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

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 10-14 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 ShouldInclude 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 1666670 for more details)

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

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

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

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.

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

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

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

Your Turn! How to contact me: Dr. Berg bberg@comerit.com

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.

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