7 Tips on How To Deliver the Highest Quality at the Lowest Cost SAP HANA platform

‘Some of the most unhappy customers have been our greatest source of learning’, and 'the success of any new technology can only be measured by the business benefits it enables’

Are you planning to migrate to SAP HANA? Here are a few tips that come from real life experience or what we term to state as VOE (Voice of Experience). By following some of these and combining them with the tips by Zora Caklovic in her blog you can come up with a solid technical and business solution that is sound both tactically and strategically. For net new customers tip#3 is most critical with a slight flavor of all the other tips for consideration.

Tip #1:  HANA is a strategic business solution and not just another technical install

A lot of customer, with recommendations of their triad partners, have treated the SAP HANA migration as just another upgrade or migration.  In this methodology the SAP applications are migrated ’As-Is’ to HANA without much clean up or optimization.  This unfortunately is a tragic mistake due to which customer routinely pay far more and get a lot less.

Recommendation: Treat HANA as a strategic business benefit solution. Ask for a HANA BVA workshop for your business owners and key stakeholders so they are aligned to the business benefit aspects of migrating to SAP HANA.

Tip #2: Re-Size your current environment before you plan to migrate to HANA

Optimizing your current database prior to migrating is professionally a very critical decision for every customer. As a customer if you do not review the TCO and ROI impact of optimizing your database prior to migration then you are probably wasting more enterprise funds than what you will end up paying for the HANA migration.

Proper optimizing is very important. If you do not optimize you will end up paying 40% to 60% initially and the same ratio on an annual basis for support. Over a period of five years this can be more than your initial investment in the full HANA migration.

Recommendation: By undertaking some very simple steps we have been able to reduce TCO by an average of 50% with one workshop of 6 hours with 3 customers. In one of the world’s largest HANA migration we managed to reduce the TCO by 68%. This represented a 68% reduction in initial HW & SW costs. It also represented a decrease of annual support costs by 68%. You do the math.

Tip #3: What got you here will not get you there

Firstly understand what here stands for. Anyone who has read my communications from2009 has probably read this before. However, despite my shouting this for the last 4 years very few people seem to be listening. Here is how we validate what the aboe headline with a statement, my translation and my validation question ask of you

a.    2003 Gartner Statement ‘Fewer than 50% of BI projects will meet business expectations. Translation: over 50% of reports in your production system are not being used, or will never be used, by your business users’. Question: Is this true in your DW or BW environment

b.    2013 Author’s statement: ‘Someone tell me the business-benefit of taking a 700 second report and accelerating it to under 1 second if business will never use it. Translation: According to Gartner’s 2003 feedback 50% of your reports meet this criteria. Question: Do you really want to approve moving this 50% of dead objects to HANA

c.     2012 Gartner Statement: ‘Fewer than 30% of BI projects will meet business expectations. Translation: over 70% of reports in your production system are not being used, or will never be used, by your business users’. Question: Without planned intervention your dead data volume is growing faster than what you use. Finding all this manually will take years-use our automation tool and finish in days.

d.    Understand who got you to this here position: Statement: If you agree to the above reports from Gartner and out surveys then it is critical to identify who got you to this ‘Here’ status. Your existing partner. Translation: according to Gartner recommendation we have to rethink our architecture (FEDW), models (automated), resources (new) and our partners who continue to walk the old talk. Question: What is the probability your old partner, their experts and resources will continue to drive the new HANA platform on their old standards and methodologies.
 

HANA is a net new platform. HANA is a new database type. HANA requires net new Architecture, modeling, transformation, basis support, security and new standards and processes for optimal success.  We have been called to many post migration customers where things did not going accordance to customer expectations. Does this mean HANA did not meet their expectations? In every case the answer is a solid No. In every case the migration team used resources that were familiar with how things used to be and assumed that those rules could be cloned in HANA. In one case we were faced with reports on HANA that took 700 seconds to run. A solution was provided in 3 days that enabled the same report to run in under 3 seconds.

Recommendation:  Review what all needs to be re-tooled. Just because you have worked with your current SI and HW partner does not translate that they are your ideal partner moving forward.  Start from your existing methodology documents and convert them to the new global SAP HANA Methodology that includes HANA specific standards and processes that mostly are similar to your old application methodology, but in certain areas is very different from anything you have done in the past. Review your current partner, their advisors, their resources and methodologies for having adapted to HANA.

Tip #4:  Plan with the SAP HANA roadmap then align it to your strategic business goals and user expectations

HANA is a not only a net new platform, but it also has many options as we travel to the future.

The FIRST set of selections are

1.    Stand Alone: Also referred to as Side-Car. This is probably the premium HANA option with the maximum performance potential. It also comes with a bunch of SAP RDS (Rapid Deployment Solutions) options that can be deployed out-of-the-box. It is also the ideal place to build custom RBS® (Rapid Business Solutions).

2.    BoH: or BW on HANA. In BoH option 1 your typical BW database is migrated from your legacy db to SAP HANA. In this option transformation continue only in the application layer, as before. This option does not allow native HANA database transformations from HANA Studio. BoH option 2 is the Enterprise edition where we can roll-in the Stand Alone HANA under the BW umbrella and get all the true HANA functionalities incorporated under our BW. Data can be merged from Enterprise and BoH on HANA for Analytics.

3.    SoH: or Suite on HANA. This includes SAP ERP (ECC), CRM and SCM. Once again this is the typical SAP application where the database in initially migrated from your legacy db to SAP HANA. SoH on HANA comes with many reporting options, prebuilt reporting views and HANA Live for real-time operational reporting. In Option 1 your typical ERP database is migrated from legacy to SAP HANA. This database is entirely separate from your SAP BW HANA database for example. Operational data is still stored in ERP for HANA and analytics still run from BW on HANA. In Option 2, phase 1 we can drive BW analytics from the same HANA database under the ERP via leveraging HANA live as a datasource from our HANA ERP. In Phase 2 we merge the two application layers on a single HANA database under the ERP.

It is most critical to plan for the data merger in the near or distant future from today in order to avoid future database merge whenever that happens.
Recommendation:  No matter where you start, Stand Alone or BoH, there is a critical need to analyze where you plan to be in 5-8 years. Companies will save millions of dollars with proactive planning and future-proofing their environment. Without this critical exercise these unplanned migrations will need to be totally deconstructed sometime in the future as systems and databases start to merge. A stitch in time will truly save nine in this case.

The SECOND set of selections are

1.    Scale-Up: This is a single node where we keep adding memory. Until recently a scale-up was needed for any SoH installation or migration. However, recent functionalities where a common database may be possible, or where SP9 now provided multi-tenancy option this option is becoming a strong consideration.

2.    Scale-Out: This is a multi-node option where we keep adding additional appliances. Until recently a scale-out was recommended for BW implementations that might exceed around 1TB in size. However, recent functionalities that allow SoH installation on 3+1 scale-out models change the capabilities of how we may, or may not, leverage scale-out options.
Recommendation:  Different enterprises that are suited for the Scale-up and others for the Scale-Out. Different business needs are suited for one of the other. Companies needs a business and IT review of needs vs. options with a business value architect in order to undertake professional decisions based on empirical practices.

The THIRD set of selections are

1.    Appliance Model: These are traditional HANA builds that most customers have got used to. The appliance model was first introduced in 2005with the BW Accelerator, and I still remember a comment by a data-center manager at a large Pharmaceutical customer where I was the PMO for a BWA installation. Their datacenter was located in South San-Francisco and he would not allow the BWA to enter his data center as an appliance. SAP and the HW vendor would not deconstruct the appliance. His reason was that in accordance to his data-centers governance all servers had to be on a earth-quake proof box. The HW vendor had nothing like that. To cut the story short in one of the meeting he stated “Your technology must be pretty unstable that you have to certify to the degree that you do. Is your solution so immature that you cannot even allow re-racking of the servers or a different power plug on the appliance..”. This statement has stuck in my mind and the appliance still is that same. The appliance is a ‘Black-Box’ that cannot be touched by the customer. It comes with comes with a stiff annual support charge of varying options and most of the components in the appliance are from the HW supplier own solution, i.e. they cannot be the best-world-class option today. In this option customers are locked into the contractual whims and fancies of a single provider. See my paper on ‘Is TDI going to make the HANA appliance model obsolete’

2.    TDI: As the SAP HANA has matured it has also stabilized. It has today stabilized to a point where SAP currently allows customers to choose the HW to their preference and selection. My datacenter manager in the Pharma company can today chose the box separate from the compute and still separate from the storage. He can choose the best of best in each category, provided the company has a SAP certified component. For example he can chose the Cisco UCS as the world’s best Compute for HANA, then chose EMC as the world’s best storage and so on and so forth. What he now ends is a best-in-class configuration that is higher in quality than any appliance, is lower in cost and strategically aligned to their future of IoT and IoE network device integration needs. The only con is finding a partner that can certify the combination and support the platform –which is what we do as part of our daily operational support services.

3.    Virtual: With VMWare now providing virtual options it will be a short time before we also have virtual production HANA servers. A lot of companies are already leveraging virtual environments for their non-Production systems. It is only a matter of time before virtual technology is approved for production environments

Recommendation:  I personally strongly recommend undertaking an executive workshop of two to four hours with business and IT stakeholders. Reviewing the enterprise and business expectations and then taking this key decision in a professional and planned manner. There are companies that are suited for the appliance model and other that must chose the TDI platform. The future is clearly the TDI model.

The FOURTH set of selections are

1.    Customer Data Center: A number of large companies have their own data-centers where they keep and host their infrastructure and servers. Some of these data centers are maintained by the enterprise while others are outsourced to external vendors. These datacenters are designed for installing bare-metal severs that are either owned by the enterprise or leased from their HW providers for fixed contractual time periods.

2.    Hosted: Hosting is undertaken either in your HW partners data centers, or in third party datacenters. For example SAP,IBM and HP have their own data-centers where they will install your HW and maintain it in accordance to their contractual SLA’s.

3.    Hybrid: A number of customers that are planning to move to the cloud but not ready yet for a full blown cloud move. Currently they are moving their non-production environments to hosted/cloud environments and keeping their production environments in their own data-centers.

4.    Cloud: We see a big potential and an upcoming swell for moving applications and appliances to the cloud. Clouds too come in different flavors and locations. Private-clouds, hybrid-clouds and public-clouds.
Recommendation:  I personally strongly recommend taking the hybrid approach as a starter for SAP HANA. The future is looking like a migration to the cloud for now as all large providers are building more and more petabyte cloud options. At current rates of expansion there is a remote possibility that supply will soon exceed demand and the customers will gain in moving to the cloud. However, the larger question is the inter-connections between all these public, hybrid and private clouds for seamless access to real-time data and decision support. So while SAP,IBM, HP, Amazon are all racing to building ever lower cost cloud options, Cisco is focusing on building the Intercloud fabric – a secure networked solution that links all these various clouds securely in a seamless manner. Decision has to be based on business goals and then aligned to available options.

Tip #5:  Fully comprehend every available option for reducing the HANA TCO

According to all surveys one of the barriers for moving to SAP HANA is the sticker shock. However the bigger questions are [1] Is it is really so; [2] Can we reduce the cost without compromising the quality

1.    Is it really so: It depends totally on who one speaks to and their experience, clubbed with deployment methodology.

a.    According to SAP and Forester:  By moving to HANA in a planned way- SW costs can be decreased by 70%; HW costs by 15%; and admin / development costs by 20%. Forester interviewed various customers and then came up with an average manufacturing company of 40,000 employees. Over a period of 3 years TCO across modified scenarios was 37%.Total cost with HANA came to $19,663,124 and without HANA it came to 31,324, 017.  This represents a clear TCO reduction of $11,660,893 as visualized in figure 6 below.

 

b.    According to Cisco & IDC Report:  By moving to SAP HANA on a Cisco UCS platform. By leveraging the unified computing fabric and single pane fabric for administration-   companies reduced server support expenses by 68%; server deployment times by 84% and reduced productive employee downtime due to HW downtime by 96%. Over a 5 year period ROI was 368%, Business benefits achieved $4.79 million payback period was a low 10 months.

c.     Actual facts on the field:  One of the immediate questions that bubbles forth is – this is all conjecture- what represents real-life experience in the field with actual customers and real HANA installations. I’ll give you three of my personal BoH (BW on HANA) migration examples based on a matrix of the Good, the Bad and the Ugly.

c.1 The Good: Customer 1 is one of the world’s largest CPG companies wanting to migrate their BW environment to HANA. Their corporate BW was currently between 93 to 107TB uncompressed and an 82 blade BW Accelerator that was bursting at the seams. They had 3 additional regional BW’s totaling around 200TB. Our HANA solutioning was done along with SAP. The standard consensus was to migrate all BW environments as-is. Looking at the sticker-price the customer decided to review moving to HANA in 2016-17. We proposed a pilot and prove that we could-[1] Reduce their global BW costs by 68%; [2] Their NRR (New Run Rate-post HANA monthly support cost) would below their CRR (Current run Rate) by 22%; [3] we could merge their 3 global BW environments into a single BW on HANA; [4] By using our proprietary cube cleaning SW we identified potential cubes for cleanup in the global environment and remodeled 10% of the cubes in the regional merge-thus reducing 15% of their BW footprint. Overall we reduced TCO by 68% for their HANA migration due to which the customer commenced to move to HANA in 2014 itself. This converted to an initial saving of 68% and an annual decrease of support costs by around 70%.

 c.2. The Bad: Customer 2 is one of the top 5 CPG companies that decided to move their BW environment to HANA. Their BW was around 52TB and the sticker-shock was hindering a rapid decision. We requested a workshop during where in 4 hours we along with SAP experts prove to them that we could reduce their BW footprint from 52TB to 27TB. The decision was made to move to HANA with our achieving around 50% reduction. Based on advice from their incumbent experts, this customer did not opt for further cleaning and automated optimization and went live on a BoH that could have been further slimmed by an additional 25-20%. After go-live we were brought in for various tasks including further post-migration cleanup and enhancing some of the performance in data loads and query performance.  This customer stopped optimization discussions the moment we achieved some threshold in their forecasts.

c.3. The Ugly: Customer 3 is a large manufacturing companies that migrated to BoH on an advised ‘As-Is’ basis. The customer has 5 year binding contract with one of the big-known companies. They had an 18TB BW with a BW Accelerator. Post migration - performance enhancements promised to the customer were not achieved, the queries ran approximately as fast as they did before migration. The project installed a new Business Objects 4.xOLAP where some of the queries were taking 300 to 700 seconds to execute, where customer expectations were for sub-second executions. Their production environment had crashed twice adding to the user experience dilemma. We are currently working with the customer. In week one we identified the reason for their BOBJ query failure, being that they had retooled their existing BW resources with internal training for BOBJ which was the root of all problems as they continued to think BW while developing on WebI and Crystal Reports. Within the week we identified 3 reports and increased performance of the BOBJ queries from 500-700 to under 3 seconds. We found that the reasons for the production crash was that their partner basis support did not have SAP HANA skills and did some steps that were logical in the old BW but not recommended in the new SAP HANA platform. The customer has now given their HANA basis oversight to our more mature SAP HANA team. The customer has now reached a point where they need to order around 30% additional memory due to  data growth- our recommendation to increase data quality and decrease database by 40% has been accepted and we are currently providing proposals that could reduce BW size by 50% to 70%.The probability of our achieving this target 0.9.
Recommendation:  The sticker-shock for HANA has many options that business and IT stakeholders need to fully comprehend. We provide an executive SAP HANA workshop of4hours to understand. I personally strongly recommend taking the IQDCT (Increase Quality, Decrease Cost and Time) approach where our proven methodology provides higher quality while at the same time reducing costs. We used the same scientific principles in each and every of the above projects. In addition to this when budgeting for the HANA migration think of the total landscape with the production pipeline, DR, HA, Backup, projects pipeline and then work with HANA Solution experts that can scientifically provide optimal solutions.

Tip #6: Think strategic Big-Data business benefits and technical connections

For SAP customers it is critical to realize that most customers are taking the SAP HANA leap for one of two, or both, maturity reasons. The first is to increase the performance of existing analytics and reports and to be able to view more decision relevant information in Real-time.  The second, normally after the first is realized, is to find the diamonds in big data consisting of streaming, networked device and customer emotion data- the true big-data endeavors from outside your enterprise firewall. It is most critical to remember this as strategic planning for optimization for the future where the Internet of Everything is today a reality providing solid competitive differentiation. For example currently there are around 4,200 HANA customers- how many of them have [1] actually conducted a strategic workshop to align strategic business goals with technology roadmaps; [2] Reviewed their HW and SI partners through the strategic IoT and IoE lens of shared network devices and connected communications capabilities; [3] reviewed how to maximize business benefits, data quality and decision capabilities as the lowest cost (TCO). From my personal experience of having visited over 42 HANA implementations less than 5%.

Recommendation:  Ultimately the success of deploying any technology or new platform can only be measured by the business benefits it enables. It’s impact on the bottom line. Just as an example we routinely build our custom HANA RBS® solutions that start from the ground up with business stakeholder with an aim to identifying business needs and then delivering them in an 18-24 week time frame to production quality level. Our last RBS solution realized its ROI in 10 months. With another customer we are using HANA for analyzing deep sea video for real-time alerts to leaks hundreds of feet under water. With still another customer we are building a Smart building solution for managing building security and operations with real-time alerts and decision assistance support.

Tip #7: Focus on what is important to your company, users and industry

Identify the focus of your business owners, users, company, enterprise and industry competitive positioning. Keep a close tab of what the global CIO priorities are. For example the 2014 Gartner symposium projects that the top 4 areas for the next 5 year enterprise spend are digital marketing, e-commerce, customer experience management and business analytics. Have worked with 2 pharmaceutical companies where each of them had different strategic charters. The top priority for the first was ‘Shareholder value’, for the second it was ‘number of FDA approval elements in pipeline'. While for the third telecom company it was ‘digital revenue generation’. Identify what decisions are most critical for your business stakeholders, even if some of them are not available. Then review each of them through two filters of competitive differentiation and business benefit. Attached below is that the global CIO community is indicating as their priority in IT spending is going to be over the next 5 years

Recommendation:  There is an old saying that ‘No wind is a good wind if the captain knows not their destination’. Some of the highest benefits we have realized in our HANA projects is with 100% custom business solutions that were identified, designed, tested and validated with actual business stakeholders and users. My personal recommendation is to ‘0-baseline’your business benefits sans your existing IT environments and with your current knowledge of business. Your competitive differentiators are unique and can easily be further catalyzed with high-performance and real-time analytics. Plan your work before you work any plan. Plan it with business owners and stakeholders

Conclusion Tip:  Think business-benefits from the start to the end and beyond go-live

Some of my favorite books tend to start and end with the same point of reference as does this blog. Business stakeholders are the judge and jury of all our HANA initiatives – once they give a thumbs-down we usually witness project teams running around like headless chickens and getting into unplanned project approvals that are both costly and unproductive as they tend to be even less planned than the prior one that failed. All this comes not from a bad technology, or platform, but bad system integration, planning and lack of strategic business alignment. My book BI Valuenomics deals with this specific problem and draws an actionable roadmap out of this dilemma. So before your commence your SAP HANA project- please go and set your user expectations and only then proceed to leverage some of these above tips. Then proceed to build your own world-class highest quality and lowest cost HANA platform that work better than your prior environment with an aim to exceed user expectations.