Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 

HANA Projects – What is so special?

What is so much buzz around topic of managing / running a HANA Project? Come on HANA is just another product in line with SAPs ERP product lines and innovations. We have tons of information and loads of examples around us on how to run an ERP project. SAP as an ERP is no new to market and till date innumerable implementations of various types /categories/sizes are all around.

It’s just a revolutionary database technology HANA at its core which brings in unmatched computation speed. Lift and shift existing implementation utilizing conventional Databases to latest SAP Application running on HANA and boom! it runs at blazing speed.Even going to extremes like S4HANA it’s more over same story with added advantage of convergence of multiple separate applications like CRM, Simple Finance etc. as plugin to single application and Database platform.

All mentioned before this sentence are the ignorance areas which create issues and at times crash HANA projects.

Remember HANA does not only talks about speeding up things using high capability Memory-To-CPU Architecture, but it moreover about:

a. Changing the way organizational processes are first simplified and reflected in design strategies

b. Come up with flavour of new age architecture models like Data Vault and Layered Scalable Architecture Plus to name few

c. To understand correctly the sizing aspects to avoid oversizing or under sizing and in turn affect performance

In short we can say the conventional way of ERP projects , especially for Business Warehouse projects where it use to be mostly data driven or were – Primarily Technical Implementation does not suits mood and meaning of a HANA implementation.

It’s not only the speed of calculation engines that pump in value but other factors like actual usability of solution, proper pivoting of data level architecture, aligned architecture and understanding how HANA actually works at engine level helps in a proper implementation and can decide a success or failure.

There are broadly two important factor areas:

1. Non-Technical Aspects like – Execution plan, proper resourcing and integration of Business core requirements in deliverables.

2. Technical Aspects like – Proper sizing, selection of Packaged or Tailored appliance, Architecture, Balance in solution to strike a balance between CPU Vs Memory consumption, wise choice of data provisioning.

Where is the world heading to?

In the current scenario where the businesses are heading to, has the key to how HANA projects to be handled.

It was a time back in history when it use to be enough to have ERP solution connecting all departments and being able to generate reports  to manage an organization and to some extent help in managing operations etc. was enough.

With time we gained more speed, covered more aspects, went into more complexity, gone ahead in time to include planning, CRM and SRM on top of core modules.

What expertise was required to handle this was unpacking bundled solutions or weave around customized solution over time and recursively built on top each other. Projects were running to configure and implement new reporting requirements, standard or custom.It’s more of a two dimensional project requirement running between these two aspects.

Optimization were towards:

a. Demonstrating expertise in building more similar solution for various customers and optimizing using tools to automate frequently done things

b. Create templates to implement stuff required almost by everyone with option of customizations

c. Reduce FTEs and time by using models like Factory model.

d. Delivering one report for every business user at times even out of temptations if not actual requirement

From customer perspective also the optimization, gaining most out of investment and execution of projects were limited to per department.

The reporting development in data warehouses were limited to smaller data sets and based on aggregation due to limitations in performance.

Where we are heading now makes a huge impact on usability of these solution and when means like HANA based solutions are available now.

We have overburdened systems running expensive ETLs, aggregations and huge data volume with at times valuable information as little as 1% as per researches.

Where we are heading is need to have powerful and real-time decision capabilities. We need not only information derived from systems in our network of OLTP boxes. But data flowing in from various other real time sources are as important. Organizations are growing in size and which translates into more complex systems. Planning on even a day old data is considered old fashioned or risky. Understanding sentiments of customer in minutes is necessity and predicting customer mood well in advance is core strategy. The definition of “what actual business an organization is in” has also changed with time. Shift has happened from being just a product based companies to service to customer by product has taken place. Now a car manufacturer cannot just focus on launching cars on mere gain in technology, they have to maintain, understand and focus on catering needs of existing customer by superlative communication is of importance.

Coming back to our discussion about differentiating factors in HANA project management. It is this scenario with customers going for these implementations have a wider implication on dynamics of HANA implementations.

A HANA implementation cannot be just a technical and department wise solution and report generating project. It’s a fusion of art of business understanding driven finer technologically supported initiative.

So what is different here – Fundamental Difference.

The best trained and run SAP implementing partners use to believe that if you are able to collect all aspects of data in OLTP systems and dump them all in smaller subsets in warehouse you have a successful implementation. So was the view of client CIO and CTO offices as well.

There are so many failed HANA implementations and the reason being they were executed with a mind-set as mentioned above.

The fundamental differences are:

a. HANA implementations should aim to greater goal of higher business usability  and enhanced simplicity in terms of design – it is strategic organizational goal

b. HANA is no magic wand. It returns good ROI if used properly else not.

SAP recommends to go with a Project execution to enable Increase in Quality value proposition to customer with decreased cost impact. The decreased cost enablement also has a factor of decreased time of execution attached.

Prevalent Challenges

There are some prevalent challenges to be kept in mind while executing or even going at initial stages of bidding for a HANA project. There are some concerns and cloud of doubt always around any new technology and at times it is the understanding difference between marketing and sales team & delivery team that should also be blamed.

Some of the common prevalent challenges are:

a. HANA is hot, getting right skill is hotter

b. To go with pre-packaged HANA appliance black box or utilize existing Hardware and to go for Tailor made HANA server

c. Cost of investment for HANA is high

d. Choice for proportion to go on premise and cloud and reasoning behind that

e. Will this actually help in reducing my TCO and tangible benefits in terms of ROI

f. What about existing Hardware

g. Customer’s belief that lift and shift is enough

h. Reports running faster, what else is the benefit?

Some common mistakes

There are some common mistakes when we talk about HANA projects:

a. As mentioned by Vishal Sikka. Beauty of HANA is, “you run a process in 100 seconds using one core, you run it on 100 core it runs in 1 second”. This aspect gives a lesson also about sizing. It should be noted if 100 concurrent user are running a report with runtime of 2 seconds, with 1000 users each of them will run for 10 seconds. So, concurrency should also be factored as one parameter with expected complexity and runtime of reports.

b. HANA engine does not create persistent cubes but generates metadata to pick up data at runtime, if CPU utilization is very low as compared to memory utilization that also is a design error and might end up screwing the sizing.

c. Too much of real time data reporting and unnecessary big data combination. Not considering strategic utility of big data at times end up into bottlenecked and memory overflowing systems with literally no meaningful information flowing out of it.

d. Scrap is not good for home, society and so for HANA implementations. Fail to shed unnecessary flabs (read unnecessary processes and reports) before moving to HANA

e. As-Is migrations to HANA

f. Wasting efforts on things which were never used

g. Long duration planning and execution projects. In ever changing market at times it is too late for a client when after spending little too much time it ends up seeing the strategic and competitive edge of new solution is already lost.

Best practices

There are some best practices to be followed and which if not followed may result into failed HANA project to different extent.

A. Focus of HANA implementations are normally not only to speed up functionalities and reports. They are to achieve a higher strategic goal of utilizing more of data towards generating time critical responses and monitoring for faster decision making. This also requires less flab to be generated in terms of having as much possible to have only what is required. This all also needs to be executed and delivered in shorter period of time for better ROI and Business Values. This translates into a project methodology with 200% more Business direct involvement and moulding architecture around this. A shift in mind-set and project execution is required from being data centric technical execution to business facing method.

B. As-Is and Lift and Shift are technical possibility towards non-disruptive migration of existing developments to new HANA environment.  These are purely technical terms and not most of the time result into much optimized migration result. SAP also recommends a lift and shift only after removing clutter from system as much possible. After lifting and shifting the HANA optimized design methodologies to be followed to get benefit out of HANA. This results into additional implementation cost and time as well.

C. Trying to sell to customer just lift and shift is as bad as spreading bad words about yourself in market

D. Continuing with point – A. Involve business and if possible field sales / market staff SPOCs also in workshops to understand strategic and customer-to-customer key areas. At times business sitting in corporate office is able to give 100% understanding of processes and utility for that. But customer-to-customer key areas are best understood by field staff and at time critical analytic inputs are disclosed.

E. As HANA implementations have a high level organization strategic value proposition expectation as well and is being viewed with microscope from every level of client organization ensure to understand the greater overall expectation from client. E.g. if a telecommunication client is executing a project to deliver reports on network data, just not go with standard reports  to present that data but understand its business value expected out of it. When you are delivering solutions like - stats of this data to show number of calls done region wise, types of caller type active region wise there mix, fraction of local and STD calls etc. client might be just interested to see call dropout rate rapidly to plan their client retention. Value proposition to client is shaken by excessive timelines and cost when focussed solutions are not done.

F. Sizing should be done carefully. HANA stores data in compressed format. It stays compressed and is decompressed only very quickly if required and only in CPU memory cache. So overall foot print of data is reduced significantly up to even 40%. With simple finance it has gone down more. But at the same time sizing should be enough to support resource distribution between multiple concurrent users.

G. Proper architectural guidelines should be implemented. E.g. LSA++ to reduce layers in Warehouse to get maximum of storing once and using multiple time benefits of HANA

H. In SAP BW HANA implementations, most of active inactive settings not utilized to be able to actively flush out data from memory to disc during bottleneck. At most 50% of memory size should be equal to all of hot data in system.

Other Challenges

There are some other challenges in running HANA projects as well. For first timers the BASIS at times is not ready for HANA and that becomes bit of issue. A heterogeneous environment at times with multiple SAP and Non-SAP systems becomes a challenge. Using correct data extracting solution, transforming data before bringing to HANA and de-normalization requirement of data are important challenges.

A very important aspect which moreover questions the knowledge level and maturity of project teams is suggesting or planning what goes to cloud and what remains on premise is also a challenge. There are customers who want to make use of both the worlds, but based on line of business, department and type of service provided by organization these should be considered.

At times customers fail to understand or not consulted well or due to financial constraint – the value of archival strategy and near line storage [NLS]. With huge volume of data input Archival and NLS plays a strategic role in data management. Especially with retail, pharma and telecommunication customers. The huge data accumulates in no time and performance is impacted and the new system loses its sheen and value.

At times due to negligent planning disruption of systems when moved to production, system outages and then time taken to fix this are also the reason why HANA project like any other project fails. HANA being new and with less expertise available at times lies in higher risk area for this.

Creating a Centre of Excellence in service provider and optionally in client organization is important. Primarily in absence of this at

service provider organization, knowledge remains scattered, improperly documented, at times remains with individuals and which hampers organizational maturity. The focus on quality control and metrics is missing mostly. While leveraging COEs helps to build up more of these capabilities and reach maturity with additional focus on tool and methodology build up.

Remember the expectation from customer towards HANA project is always extremely high. It is always a high focus project. Also, the target benefit of customer is strategic organizational upgrade as well and not only a technical upgrade. This makes it extremely important to create designs for implementations only with deep understanding of business processes and bigger goal expected.

On the other hand HANA being altogether a new kind of Database and application a sound understanding of technology and bringing on board right skill is extremely important.

At organization level, building up of COEs and competency development also not only helps in proper project execution. But also helps in quality focussed and mature strategic expertise build.

8 Comments
Labels in this area