Why Organizations need a SAP HANA & Big Data Strategy

It is important 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 mandate for optimization for the future where the Internet of Everything is today a reality providing solid competitive differentiation.

While most IT units are anxious to deploy big-data and SAP HANA one of the most pressing questions business stakeholders are asking worldwide is ‘show me the business benefits’ and ‘how are we going to assure we meet business expectations’. More than one enterprise is in a dilemma as to how to answer this very question. We have been encouraging business stakeholders to ask this very question and have developed global methodologies to meet these very objectives in a scientific and planned methodology. The roadmap to both above questions is only about understanding, defining, developing, documenting and communicating a global SAP HANA strategy that is led by a documented global methodology.

So what is a global SAP HANA Strategy? It is a part of the global Business Decision enablement Methodology with rules and regulations for all developments therein.

·       SAP HANA is a business solution. It is not simply another technical upgrade or installation.

·       The SAP HANA methodology has to be built from the ground up for this new platform to leverage its capabilities. It is not simply taking your old partners, resources and methodologies into the new platform.

·       The SAP HANA methodology mandates optimization prior to installation and/or migration. It is not simply taking your current SAP-BW, ERP, CRM or SCM and migrating it to HANA ‘As-Is’

·       The SAP HANA methodology starts with global standards, processes, data architecture with clean guidelines. It is not making broad-stroke statements like ‘Data is an enterprise asset’ or ‘IT will deliver reports based on their experience’

·       Strategy is all about ‘meeting business expectations’ and ‘enhancing business benefits’. It is not about producing a technocratic laundry list of technology installations and when they will be deployed.

·       Strategy is a clear roadmap of aligning tactical deliverables aligned to technology owner and business goals in the coming years. It is not laundry list of technical trends that might somehow influence decisions in the future without any need for business inputs.

·       Strategy is a decision with business stakeholder inclusion and benefit case acceptance. It includes business participation at every step for it to be successful. It is not just a triad-vendor vision, shoved to the enterprise with protocol top-down instructions, or led by IT technical goals that still do not comprehend the capabilities or limitations of the technology, with little or no business inclusion in the whole decision process.

So with the above let us define what your SAP HANA Enterprise Strategy really should look like:

Your SAP HANA Enterprise Strategy is the comprehensive business value-chain vision aligned to an actionable technology roadmap for an organization to align all technical developments towards a global strategic vision of enhanced decision capabilities.  It fall under the umbrella of Master Data Management, Business Intelligence, Big Data, data governance and so forth.

Thus a SAP HANA Enterprise Strategy is:

·       Documented, accessible and communicated.

·       Pre-qualification read for all developments across the enterprise

·       Becomes the backbone for Governance.

·       It must be actionable, relevant (e.g. contextual to the organization, not generic), dynamic (e.g. it is expected to change/evolve on a regular basis; communicated / Integrated - with everything that comes after it or from it)

Once we agree what an enterprise SAP HANA Strategy is we need to discuss why it is critical to have one. .Here are some the main reasons: - 

1.    A global methodology ensures that no matter where development is undertaken it conforms to a global methodology of architecture, design, definition and change management. Without a global / centralized methodology each part, region- application or developer, will traverse on a subjective path of what they perceive to be their truth. This inevitably leads to redundancies, duplicates and dead objects. It also leads to multiple versions of truth in the same application and much worse globally. Most importantly it slows SLA’s and drives up costs.

2.    A global methodology ensures the enterprise goal of ‘One version of truth’ is achieved. . Without a global methodology each developer can create newKPI’s, change KPI’s and create data flows at will without any form of checks and balances.  

3.    A global methodology clearly defines the hand-off points from business to IT with clear start and end points for every delivery. Without a centralized methodology business and IT get themselves into independent silos, with each blaming the other for lack of adequate information.

4.    A global methodology clearly defines global, regional and individual metrics and KPI’s. Without a centralized methodology there can be no global ownership of metrics and KPI’s and thus no single version of truth.

5.    A global methodology clearly defines periodic checks and balances, optimization audits and guidelines. Without a centralized methodology databases can go out of control, DW instances can get filled with redundant and dead objects all making SLA’s impossible to maintain.  

Sample components for a SAP HANA Strategy

So a typical SAP HANA Strategy should include:

·       Full documentation for the new SAP HANA platform. It must not solely rely on the old standards and processes. Gartner said it quite perfectly ‘What got us here will not get you there’

·       A full inventory of source systems, types of application and database servers, along with ownership and accountabilities. You can never model a data pipeline until you fully comprehend the underlying datasets and their relationship to your enterprise

·       A documented global methodology of critical areas for governance. How can governance teams govern without a documented methodology or rules and regulations?

·       Global definitions of corporate, global, regional and SBU level metrics and KPI’s. There is no way towards a ‘single version of truth’ without clear definitions of individual metrics and KPI’s. 

·       Global organization structure with Center of Excellence ownership. Clear definitions of data ownership and change management. Without clear ownership and accountabilities one can very easily drive straight into a world of unplanned, and subjective, spaghetti data architecture.

·       Global guidelines of reports, analytics and informatics architecture roll-up with self-correcting and audit processes built into the design and architecture. Without a global FEDW guidelines one can run into layers of data quality governance and information quality audits that can become a daily nightmare.

·       Global standards for enterprise value-chain IoT and IoE devices, data management, flows and security enablement. Dive into Big Data and HANA without strategic IoT and IoE considerations and you are short selling your strategic capabilities and the potential of your assets.

·       Global standards for sub-strategies for ERP,MDM, CRM,SCM, Single database platforms with clear instructions as to how the methodology fits into the future states contemplated.

·       Dynamic global Risk Register and Key Decision process documentation.

With this in place we are now ready for the three critical roles for strategic HANA success. Roles 1& 2 can be combined with the right resource, role 3 must be a direct employee of the customer

1.    Enterprise SAP HANA Solution Architect

2.    Enterprise SAP HANA Business Value Architect

3.    Enterprise SPA HANA Business Value Owner

The SAP Solution Architect are typically strong technical resources. They are experienced specialists in SAP application platforms from an architecture and technical solution point of view. Solution architects make excellent candidates for strategic designs and solutions they help companies define enterprise data and BI strategies. They must be charged with defining short-term, mid-term and long-term technical objectives from a system capabilities and optimization point of view. Solution architects have a good deal of experience designing global Infrastructure and working with an IT perspective of optimal utilization of resource distribution.

The SAP Business Value Architect are typically strong technical resources but with a stronger business benefit focus. They typically come from a strong business background and have adequate experience leading SAP projects from a customer point of view. Business Value Architects have just one deliverable –to ensure that all the project designs, plans, resourcing and development with deliver business value/ benefit. Their sole measure of success is ‘Meet Business Expectations’. They must be charged as the trusted, right hand advisor for project owners. Business Value architects must have a proven track record of consistently delivering projects with high user satisfaction scores.

The Business Value Owner is typically a customer employees only. They must not be representative of a person available at that point of time but a careful selection of a super user and a business user.  They typically come from a hands-on business background and understand the enterprise needs and expectations.  Business Value Owners have just one deliverable –to ensure that all the project designs, plans, resourcing and development deliver business value/ benefit. Their sole measure of success is ‘Meet Business Expectations’. They work as the internal business value expert in conjunction with the Business Value architect. While the Business Value architect is more technology and business facing, the Business Value owner is mostly internal facing with protocol access to business stakeholders and enterprise business users.  They must be charged as the trusted, right hand advisor for project owners with as a team for Business Value deliverables.. Business Value Owners must have a proven track record of consistently understanding internal business needs and situations along with org structures and key decision stakeholders.

Powerful methodologies dropping SAP HANA migration costs by over 40% Revealed by IQDCT

 New research is now providing evidence that the HANA IQDCT (Increase Quality, Decrease Cost and Time) methodology is indeed working towards delivering its promise. The investments made into SAP BW health analysis and optimizing cures is finally saving millions of dollars for SAP HANA customers. Hari and his team call these SAP HANA companies patients –in need of desperate scientific medicines to make their lives healthier at lower costs.  Recently Hari presented results from their findings based on  a new empirical  study conducted on BW-on-HANA Initiatives.  The study,  conducted at major global HANA clients,  clearly demonstrates that it is not only possible to increase the data quality of existing BW platforms, but simultaneously to decrease the cost and time for data migration from a current BW to BW-on-HANA.  Even though cost and business benefit were the core drivers at the start of the projects there remained an underlying baseline for improvement in quality at the same time.

In  pilot programs including two of the world’s largest CPG companies the IQDCT methodology clearly established that it can deliver two distinct cures for prospective BW-on-HANA migrants.

The first is a decrease in cost for the initial HANA migration. This test significantly beat a similar control group that proceeded on their pilot without any planned optimization. The initial cost reduction achieved impacted the initial HANA investment by 52%, i.e. dropped the initial TCO by 52%. However, this process also decreased their annual support costs by a similar percentage. Thus, saving the customer millions of dollars initially and over the next five years. This was achieved without post HANA optimization and without using the HANA Cold options.

The Second was that with the scientific optimizations the methodology was able to decrease the NRR (New Run Rate on HANA) below their current CRR (Current Run Rate on Oracle).

Researchers on the two projects concluded that IQDCT can deliver considerable budgetary relief. Study customers experienced significant reduction in their TCO during all phases of the project. With one customer the TCO reduction was as high as 68%, i.e. their initial investment for moving to HANA was reduced by 68% (based on their original estimates).With the other customer the initial optimization of their landscape reduced TCO by 52% within three weeks of effort.

For those with badly designed InfoCubes, what the Pilot team referred to as ’monster cubes’ there were opportunities too firstly redesign these cubes via automation, and secondly to clean them up considerably while redesigning them automatically. The study also concluded that the IQDCT methodology is safe to use, has no adverse or side effects to the SAP HANA Migration initiative.

The proprietary IQDCT methodology includes landscape optimization, automated Cube cleanup and redesign, HANA Cold planning, Standard SAP Housekeeping, Migration and post migration upgrades.

This methodology helps to:

·      Significantly reduce TCO and budget allocations for HANA

·      Improve data quality and decrease migration costs

·      Remodel the BW Objects for the future HANA Platform

My perspective on the recent HANA ASUG report

 

• • http://www.zdnet.com/sap-hana-users-are-struggling-to-see-the-business-case-7000032548/

  A recent report on SAP HANA reports very interesting details clearly visible between the lines. 1st is listen to other customers and second that this is exactly what I have been publishing for the last five years and stating for over 9 years.

  Some interesting facts of the report  that require leveling the playing field before we review the report itself are:-

  Baseline: There are over 150,000 SAP customers and over 70,000 SAP BI customers. Out of these 3,500 have migrated to SAP HANA as of (April Sapphire report from SAP)

  Fact 1:
• a. If we just take ERP customers we find that only 2.33% of potential customers have currently migrated to SAP HANA. Critical to note that 97.66% of SAP customers have not yet moved to HANA.
• b. The respondents represented the full spectrum of SAP users (150,000+ 70,000 x users in each of these implementations).
• The ASUG questionnaire was answered by the full spectrum of SAP customers, who may be answering based on hearsay or their assumptions - our ene3my #1 in most BI analytics design thus also this one.
• So getting answers from a 2.33% quorum, from folks who barely understands HANA might deliver skewed results. I state barely know BI based on the 2012 Gartner report that clearly states that less that 30% of BI projects will actually meet business expectations. A 30% return on Investment for me represents barely the right methodologies being currently followed or followed. I published this in 2010 but few listened.
• Recommendation: Listen to the customers who have actually migrated to HANA and hear from respondents who have opted for the HANA real time Decision enablement.

  Fact 2- Path to HANA:  SAP HANA customers fall into three types: 

  The first customer type treat HANA migration like any other SAP upgrades or migrations-    90% of customers.      I call this the technical approach. Recall that most BI instances globally had over 50% redundant data in 2003 which increased to over 70% by 2012. (how to verify this Gartner interpretation- My Statement: There is a high probability that over 50% of the reports in your BW PRD (or any other DW) system are either not being used by your business users or never will. If this is correct then it validates this statement. If you don't know ask us for automation and we can schedule your answer by next Monday. This category of customer simply takes their current BW and proceeds with the migration to HANA- not recommended. BVA (Business Value Attainment)  score = 30%
• The second customer type, under 5%, are the ones that treat BoH migration with a scientific process of TCO reduction and RIO acceleration. In my last three projects this has resulted in a TCO reduction in one case of over 68% and in the second over 50% with simple automated cleaning tools. This translates into 50% reduction in initial costs and 50% reduction in annual support costs. BVA Score >70%

  The third type is very interesting, as they leave their existing apps as they are and start with defining business value, identifying business benefits and then deploying a stand-alone solution for real time business benefits- This customer group has seen the maximum business benefits from their HNA investments. This is the area I am focusing one today to assure extremely high business value. BVA Score >95%

  Recommendation: Focus on partners who are themselves focus on Business Value, Business benefits and the future of Internet of Things. Cautionary note for partners that treat the HANA migration simply as a technical upgrade.

  Fact 3- Price is a barrier to a rapid movement to SAP HANA

  No matter how we look at HANA price needs a tactical and strategic review. However, as I have discovered and proven many times with some of the worlds largest HANA migrations --> price is highly a highly alterable input only if we follow scientific BVA and IQDCT methodologies. BVA stands for Business Value Attainment; IQDCT is our own Increase Quality, Decrease Cost and Migration Time) using which we have reduced costs anywhere from 40% to over 70%. So next time you ask for HANA HW or Migration ask your SI if they can reduce costs by 40% or more. If they say you are crazy or that it is not possible ask the next one. When you reach the end of the line and still find no clear answer - look us up. (PS this must not include standard BW housekeeping- that is extras). These examples are TCO reduction we have achieved multiple times with various customers some of the worlds largest SAP BW customers on the planet. Customers need to think and demand out of the traditional box solutions. Get free from the myths of SAP HANA. This is pure business value enhancement, i.e. get more for less with zero impact on quality.

  Myth 1: HANA Price is fixed and cannot be changed:

  See fact 3 above. We have routinely achieved a minimum of 40% target price reduction for BoH migrations via leveraging automated tools and scientific principles for HANA migration. In our last case we lowered the HANA Initial HW and SW cost by over 68% Recommendation: Demand 40% reduction in TCO from your migration partner

  Myth 2: Move your BW 'As-Is' to HANA 

  ...and you will pay anywhere from 40% to 70% more.  No more to say on this                                                  Recommendation: Demand a minimum of 40% reduction in TCO from your migration partner. Demand System mergers if you have more than 1 BW. Demand Landscape optimization. demand Automated InfoCube remodeling and reduction for HANA. Remember that 50 t0 70% of your BW is filled with redundant and dead data. Clean this and save millions.
• Myth 3: Use your current partner, processes, resources when moving to HANA 

  Gartner very clearly states that as you move to this big data environment you need to rethink everything. Rethink architecture and choose FEDW architecture. rethink models and opt for automated modeling. rethink cost structure's and understand the strategic roadmap of HANA, and align your current tactical deliverables to your and SAP strategic roadmaps                                                                                                                                 Recommendation: Remember that 'What got you here, will not get you there. This is validated by Gartner's 2012 BI report that 'Fewer than 30% of BI projects will meet business expectations". So why do you want to use the methodology and processes that got you  to your current state. In fact why use the same standards, processes or even the partners that have led you to this current state. Ask yourself : Should your current methodology be used to migrate you to this hyper drive of a platform.
• Critical Recommendation: Ask for our 2 hour HANA Executive workshop that provides checklists and steering committee guidelines on Do's and Don'ts for HANA migrations- focus Business Benefit ideation. This is build with over 8 years of Gartner recommendations and global CIO inputs. You will gain from our lessons learned over the last four years (this is as long as HANA has been there) and save yourself millions of dollars, and achieve true business benefits or at-least understand how it can be achieved.

   Statement A: 75% of the customers have not been able to find the business case for justifying the HANA option

  This is a dilemma we are seeing across the entire landscape as traditional triad partners, HW , SI and SAP, have traditionally focused on Speed and not the Feed. Speed is critical but  someone tell me the business benefit of taking a 715 second report and accelerating it to sub second if business will never use it. Speed in selling is nowhere as good as slowing down to 'plan your work before you work your plan', i.e.  identify CLEAR business benefits + proven methodologies for  lowering the overall TCO by a minimum of 40% as the baseline deliverables- This is pre-qualification 101.

   Recommendation: There are generic business benefits that are good for reference. POC’s are not required any more and in no way represent your future business value. So customers [1] head straight for partners that help define a business benefit case – sometimes where none exist. [2] Then ask for designing and delivering it on agile principles. [3] Involve business stakeholder through the process if you plan to extract business benefits. If your partner recommends in keeping business stakeholders outside the HANA project door- show them your door. My experience: we have routinely build brand new custom RBS (Rapid Business Solutions) in 18-24 weeks and each time returned with close to 100% user satisfaction. In one we scored 102% 25 weeks after go live. Find partners who are business value focused and not in it only for the migration ride.

  Statement B: The media is reporting that 3 years into the HANA option there still is a lack of referenceable business cases

  B.1 The reason for this can be three folds.
• The first is that this HANA is as disruptive a technology as the word implies and thus exceptionally new. It is so new and innovative that after Hasso's 2009 keynote, Larry Ellison CEO of Oracle is reported to have stated that (this is not verbatim accurate but carries the just from my recollections ".. I wonder what kind of coffee joints Hasso Plattner is visiting and what he was smoking there- to recommend the HANA database". It becomes more interesting as within the next six months Larry announced in Oracle-world that Oracle was going to develop a database like HANA. Disruptive technologies cannot ride an existing wave but have to either create their own wave, or crash t=right through the current technologies. All disruptive technologies start slow and then reach a 'Tipping-Point' that frankly I think HANA just reached by early 2014.  It cant be all that bad if every BI provider on the planet is right this moment emulating HANA.

  The second is that exceptional business case, i.e. ones that are extremely successful, are being kept very close to the heart of the customer and the delivering partner. Disruptive technologies routinely face secrecy as they develop new solutions that both the customer and the partner do no want to share openly. So unless you have implemented HANA you will probably hear of few stellar custom solutions other than the ones provided below and one of Kingfisher where I was involved and the customer agreed to share it at Sapphire.

  The third is that most of the traditional SI’s and HW partners are still taking their legacy route of technical upgrade when migrating to HANA. This simply enables speed but many not enhance and need.

  B.2 Lets compare HANA growth to  BW Accelerator: BWA was a new ideation for accelerating BW queries and was launched in 2006. By 2012 when HANA made BWA redundant,  I can track around 2,000 customers. This is 2,000 customers in 7 years, which translates to an average of 286 customers per annum. When we look at HANA, It was launched (GA) in Jan 2011 and today we can track 3,500 customers. This today translates into an average of 1,000 customers per annum. this is 350% faster growth than BWA.
• Competitive positioning: It is important to note that Oracles Exalytics is BWA for Oracle Essbase, so Exalytics today is more similar to BWA than it is to HANA.
• Recommendation: No matter how we look at it our experience is that HANA adoption is extremely high and from where I sit it is accelerating at a faster rate every month. POC's are no longer required as it is a mature technology despite being only 3.5 years old.  Avoid rapid migration based on technical reasons and is  like a leap-of-faith into technical assumptive nirvana. DEMAND optimization, Business Value, business benefits and then demand reduction of TCO by 40%. 

   Statement C: Shortage of skills

  This is a fact, nut kind of, and there is a very good reason for it.
• HANA came up for Ramp-up around Mid 2010 and GA was around early 2011. Early projects were mainly done by and with SAP for one simple reason that SAP could not afford failures in a net new disruptive technology.
• From 2011 I have been advising, via my HANA group and blog,  to go and get HANA certified. This was soon followed by questions like- now that I am certified what about a job. My recommendation was to hang-on and keep in touch as SAP would run out of resources. Currently my estimate is that there are over 16,000 HANA certified resources. However, [1] quite a few of them do not have adequate experience, [2] most of them are still thinking the old ways of how things are done, and [3] very few have the skills of a planned business value approach, TCO & ROI optimization, FEDW architecture, automated re-modeling all with a singular focus of Business Benefits.
• What this results in is legacy technical regurgitation  of old ideas with 'experts' hoping that their old (and familiar) methodology will fit into the new HANA platform. I would like to use Gartner that said it perfectly in 2013 “This is a time of accelerating change, where your current IT architecture will be rendered obsolete. You must lead through this change, selectively destroy low impact systems, and aggressively change your IT cost structure. This is the New World of the (big-data), the next age of computing.” Mr. Sondergaard, Gartner Sr. Analyst, said.
• Recommendation: The skills are all there but o lot of them are legacy and technocratic based. Make a note of all the bold highlighted items in Gartner's 2013 comment, then keep your eyes laser focused on the strategic ball = business benefits. Find resources and a ‘HANA Business Value Architect'. Define roles and then build skill maps that fit your roles. Avoid running with legacy infrastructure, HW partners, SI's, architecture, methodologies, models as that will only migrate all your inefficiencies, redundancies and dead objects from your current BW to BW on HANA. Demand Business Value Attainment and clearly define business expectations- then measure deliverables against business driven excellence.

  Statement D: BW on HANA is going to be an easy win

  Easier said than done. Also this is rather true if we look at the distribution of the 3,500 customers that have already migrated to HANA. This is due to the reason that the HANA evolution started on the analytics side and it took almost a year and a half for it to open into Suite on HANA for ERP, CRM and SCM. If we look at the 3,500 customers by April 2014 we see that over 90% of them are customers looking for a BI solution, or analytics customers. So BI is the sure path towards HANA adoption. Most customers start with BI or BW-on-HANA also referred to as BoH. But believe me it is not an easy win - not if you plan to do it right, the first time.

  Recommendation:  HANA has all the capabilities to deliver Real-Time Decision capabilities. It is the only solution for ‘Time to Information’. However if it is deployed wrong who can we blame. this is discussed in detail in my book BI Valuenomics- the story of meeting business expectations in BI. All parties concerned – unfortunately. Speed should not be the driver, neither should a technical migration become on. It should focus on pure business benefits, real-time informatics and ‘Time to Decision’ factors. My best implementations were where we started with business, identified their business needs, then focused on business benefits and only then proceeded to deliver a solution. In three of these cases the ROI was achieved in under 8 months, i.e. the total investment of the HANA initiative broke-even in under 12 months.

  The survey is an honest feedback by our customers and we all need to listen, review and then base our future plans in accordance to current lessons learned and out findings. Do not under any condition disregard what our customers are saying.  

  Customers: As a customer you need to focus more and more on Business Benefits and reduction of ROI. Find partners that do not belong to these triad but their whole focus and deliverable is [1] Business Value and [2] Making your SAP BW and HANA better. do not forget on asking the strategic implications of your HW, SW and Design when you need to model your HANA for IoT. What I am calling HANA4IoT considerations. along with possible TDI alternative analysis.

  SAP: As SAP they need to focus more on business benefits and more industry specific actual business benefit business cases. They need to create a track that defines, audits and delivers business benefit assurances - what I term as Business Value Attainment.

  HANA System Integrators: SAP and HANA SI's  need to move away from [1] treating HANA just as another upgrade or migration. [2] Continuing with the same architecture and models into HANA; [3] Taking the current BW 'As-Is' to HANA without exceptional cleanup and TCO reduction. SI's need to  look at HANA migration as a re-platform initiative with huge potentials for enhancing ‘Time to decision’ - an absolute game changer for the enterprise of the future.

  Overall SAP customers are smart customers and I almost insist that no customer should simply move to HANA because some or all triad partners are kind of forcing a technical migration without truly identifying a Business Benefit case.  Our of the 33 HANA prospects I have dealt with over 50% of them only decided to move ahead with HANA on two critical deciding factors.
• [1] With the first set of customers, normally very large customers, we took my IQDCT approach that delivers ‘Increase in Quality, Decrease in Cost and decrease in Time’ with a target of 40% for each. With one of the world’s largest BW customer we achieved two critical benchmarks. First: Our plans ensured that their NRR (New Run Rate) was lower than their CRR (Current Run Rate), i.e. with a scientific approach maintaining their BW on HANA is going to cost them less that their current Run Rate. Second: We reduced their landscape by over 40% and then further reduced their BW footprint using automated tools by another 28%. Total reduction in initial cost reduced by 68%.
• [2] Customers who simply want to move to HANA in the fastest way possible without planning, listening or any semblance to business benefits or a true business case. - Nothing more to say here

So keep your focus on

1. Business Benefits, become business inclusive as proposed in my BI Valuenomics published in 2010. There is every reason to read this story today so you can be successful tomorrow with HANA 
2. HANA4IoT: start thinking HANA4IoT as that is a hurdle very few mature customers are just now starting to face. Basically we all took the HANA step so we could go outside our firewalls and collect data from upstream and downstream devices and blogospheres. However, no one out there, except us, are planning that infrastructure, devices, network and most importantly the security. Plan that today so you are safe tomorrow. That is part of strategic business value.
3. Only hire business focused HANA4IoT: advisors. as they will save you over 40% today. They will save your over 40% on annual support costs and many times more as you mature in your HANA environment.  Demand how your partner plans to deliver this or find experts who can.  Learn from experience, on board business focused experts and extract pure business value from your HANA investments.

Some URL's on this topic

http://www.saphana.com/community/learn/customer-stories/

http://www.saphana.com/community.learn/solutions