Making the Move to HANA

Posted by Hari Guleria on February 23, 2012

More by this author

“I get a lot of energy being out in the field and talking to information consumers and feel what it is like to be in their shoes. It’s an amazing feeling and some of it is, quite frankly embarrassing just to be honest about it, but then you go back and fix it. No matter how good one thinks they are, we can always turn over a rock and find newer ways to enhance the process once more. This is all very exciting, as our aim should not be to only keep pace with the technologies but to set the pace. Technology by itself is not going to be the differentiator. Where companies need to excel is by keeping their focus on the customer – their information consumers, and by executing and delivering what the customers expects better than anyone else”

When discussing strategies for migrating data warehouses the CFO group often has the following questions. “OK, I see the advantages of HANA but tell me the following. How long with the HANA Project take? What is my ‘0-Risk’ and safest deployment option? What are the Risks? What about obsolescence? What benefits should I expect to get from this investment, as I already have a BW Accelerator? Is it really worth the effort?

At the same time we see a different set of questions from the business stakeholders had their own unique questions. How will this differ from our BW and BWA implementations? How will you ensure this will meet our expectations? Will it be different from our last two BI implementations; as we are still struggling getting value from those? What is your recommended best practice methodology? What should we expect this time? How can we assist make this a better implementation?

These are common concerns with over 50% of BI implementations. Current BI projects are not exactly meeting business expectations, this is independent of the platform. IT keeps coming in with every newer technology as a method of meeting expectations. The result is that both business and IT have become skeptical about BVA (Business Value Attainment) in their BI alternatives. This is a common situation for many organizations today. Both new and BI migration projects are high-priority items on most IT agendas as older data warehouses either start to burst at the seams, or are viewed as hindering the growth of their companies. Over time, legacy BI system architectures will unpredict­ably break. We see many situations like this, with workloads exceeding 80% to 90% of capacity, causing query times to explode from seconds to too many minutes and sometimes hours.

Despite sounding critical simple BI migration projects are firstly not very simple unless planned with business in mind and optimizing the technical capabilities of the new technology are part-and-parcel of the migration roadmap. Many companies have successfully migrated from Oracle to BW, BW to Teradata, and vice versa, but a lot of these migrations did not reach the Promised Land from a business perspective – they still failed to meet business expectations as expected before the deployment. Some call it the ‘IT Success, but a business failure’ type of project. So we must ask ourselves the question as to whether it is the platform or the process that is truly at fault in failed migrations. In order to finds the truth we will focus on failure as that is what we all need to avoid. Also, everyone tells us about success, and we then drive into the BI project only knowing about the success factors and continue to make the same mistakes as the failed projects made. Final result = Still another failed BI initiative.

So Why Do Some BI Projects Fail, While Others Succeed?

The primary reason can often be attributed to – too much focus on CFO metrics, i.e. cost, time and tasks – so 98% of BI projects meet all these deliverables; and too little focus on Project management for BI At the same time we see little, or no, focus on meeting business expectations – we try to find this only after go live. Look at any BI projects periodic reports. We routinely find cost, time and tasks graphs. Now try and look for a BVA graph and you should not be surprised in finding that this simply does not exist in our current project management portfolio. In HANA this factor is a necessity. Business participation is essential for the overall business success of the project. However, if the intention is to just deploy a technical solution, without meeting business expectations, then this may not be necessary.

Tangible Cost Reduction with Intangible Stability

Driving down cost must become the critical requirement for all BI projects. The only way to achieve this consistently is by applying the scientific BI principles and enhancing existing PM methodologies with two new factors. In laymans term this translates to ‘Do it Right the First Time’. The first is redefining what constitutes BI Success, i.e. meeting business expectations in BI. The second is installing an internal ‘Business Value Owner’ role – i.e. someone who tracks ‘Meet Business Expectations’ on a weekly basis with regular reports such as we currently do with cost, tasks and time reports. The third is in finding your ‘BI Business Value Architect’ a platinum level consultant that understands business and treats technology as a means of achieving business expectations. Any BI project, including a BI migration project should generate tangible cost reductions while also providing stable performance and flexibility for changing business and technical requirements. It must align all tactical developments to strategic business goals, not assumed goals nor technocratic assumptions of what business goals are but with direct participation of business stakeholders.

As more BVA driven resources go into the data warehouse, its capabilities increase pre­dictably, until eventually a tipping point is reached. Modern BI technologies have dramatically enhanced information delivery capabilities and promise altered cost tends. HANA is no exception. However, one must not forget one of Gartner’s statements when deploying the HANA alternative, that ‘Less than 50% of BI initiatives actually succeed’ – the ones that fail have been analyzed to follow the old technocratic principles of BI deployment, the ones that succeed leverage the scientific methodology of BVA. Migrating to HANA can offer strategic cost reductions but only if it is approached in a professional and planned manner.

Get Immediate Payoffs with Long-Term Evolution

This HANA trade-off is quite logical among most BI projects—’fast, technocratic and sloppy’ versus ‘slow, BVA driven and meeting business expectations’. A HANA BI project should be managed to produce short-term payoffs to business users while following a long-term strategy for the company. Both can and should be pursued concurrently. Some of the short term benefits could be by firstly deploying a standalone HANA with delivered ‘Business Content’ available in HANA. The first step could be ‘COPA’ analytics for finance, ‘SMA’ or Smart Meter Analytics for Utilities; ‘SWP’ Strategic Workforce Planning for HR and so on. The second step, after realizing the benefits, could be the enhancement of the installed content. The third step could be replacing your existing BW Accelerator with HANA. SAP calls it the side-car approach we call it the ‘Safe-Passage HANA Deployment’ – the aim of both is a ‘0-Risk’ option. The fourth Step, still in the future, is to totally eliminate the BW database and keep all the ECC and BW data on one single database – the harmonized HANA approach. Each customer implementing HANA must always keep this strategic goal in mind so that each development done today complies with a global standard and towards this projected future.

Business Improvement & Infrastructure Maturity

At the end of the day it is business that is the customer for all BI initiatives. Business is not only the customer they are also the judge and the jury in all BI initiatives. It is important in all BI projects to involve business owners early, and then consistently, i.e. once a week, in a controlled manner. In one recent BI project we scored an unusually high project score of 102% – by following the BVA principles. Most business stakeholders what to see specific improvements from the data warehouses, most of these expectations are often outdated. Current executives often come with a mindset of either ‘Deliver me these reports’ or “If it’s not broken, don’t try and fix it’. However, new technology advances like HANA and the Accelerated explorer require executive mindset upgrades. This can be accomplished with a brief BVA training of executives that makes them into modern BI executives understanding new technology capabilities and limitations as never before. Changing from BW ETL to database transformations is a major leap and executives must understand these simple changes in technologies in order to leverage the new technologies efficiently.

A Globally Integrated View – SPOT Analytics

SPOT is ‘Single Point of Truth’. In global analytics this can make or break an enterprise. We recently conducted a globally integration audit for a global manufacturing giant with 4 BW’s, 16 BusinessObjects, 3 Oracle DW’s and viewed them from a global information delivery perspective. This was a very different approach from their traditional DW centric approach they were used to. In the DW approach each data warehouse is treated as separate machinery. In the FEDW (Federated Data Warehouse) all existing data warehouses are approached with a global perception of information consumption – i.e. business focused. Each data warehouse thus becomes a cog in a complex BI mechanism. In our example above we were able to merge the 4 BW’s into a single FEDW instance, the 16 business objects into two, one for very high security R&D and recipes and the other for all business processes and with business objects as the single semantic layer for all analytics across the global enterprise. The company has reached their proverbial ‘One Company, One Truth’ paradigm with this first step, now they want to speed their queries to maintain their global competitiveness. The company recently launched their HANA deployment and is focusing first on financials, with COPA being the first step.

An Actionable Roadmap to HANA Deployment

HANA, like all BI projects, requires a joint vision definition with business and IT, with business taking a larger role in vision definition. Quite often we have walked into a client who pre-decided requirement and within a few days of discussion we have been able to isolate true business value for a HANA deployment. Pre-decided requirements are like a legacy customer wanting all their legacy reports in ECC exactly as they are in their legacy systems- we soon realized that was a waste. Pre-decided then proceeded with R/3 users wanting all their ABAP reports copied exactly in the BW environment which again was realized to be a mistake. In HANA we recommend customers do not make the same mistake once again. The reason for this pre-decision is that the key stakeholders did not evolve their perception from reports, to Analytics and now to Informatics, they did not evolve or understand the new BI technologies, their capabilities or limitations. The name of the game is not in delivering reports but in enhancing decision capabilities with the right information at the right time at the right speed. This is the goal of HANA- only this time much faster.

With HANA we take our first step into the domain of Information Consumption Management and not in building a data warehouse. Business participation is critical for this success. Just a reminder as to what Gartner said in 2010 ‘Without business in business intelligence, BI id dead’. HANA is more about business ownership and accountability than any past information delivery application.

VN:F [1.9.22_1171]
Average User Rating
Rating: 5.0/5 (2 votes cast)
Making the Move to HANA, 5.0 out of 5 based on 2 ratings