SAP ERP's Future on HANA

[NathanGenez]

I was invited as part of the SAP Mentors program to SAP's press release in Palo Alto last week.  As has been covered in multiple news articles since then, SAP announced the availability of the Business Suite on HANA. 

I had heard of HANA many times in the past few years but it's always been related to non-SAP applications.  More recently, BW stories have started to pop up and most everyone was predicting that it would eventually be available for other SAP applications.

I was under the impression that HANA's main advantage was speed; fast access to data.  While there is always risk in new technology, the promised benefits of HANA seemed appropriate to an OLAP system such as BW.  But no matter how important it is to a customer's SAP solution, BW is primarily a reporting tool.  Migrating a transactional OLTP system such as ERP to HANA that happens to be your financial system of record?  Well, that is a much more critical system to migrate, manage and support.  As such, this announcement got my attention.  At the same time, it represents a much greater benefit.

What Was Said

First some technical items.  The Business Suite (ERP, CRM, PLM, SCM, BW, et al.) is available on HANA but my focus and concern was mostly on ERP.  In order to run ERP on HANA, you have to be on ERP 6.0, EhP6.  SAP plans to have all of the industry solutions supported on HANA by year end.

The approach to switching to HANA is done in two steps.  First, a DB migration has to be done which SAP expects will only take a few weeks at most.  At this point of the process, you immediately get access to HANA analytics on your transaction data.  Transaction processing and reporting are also drastically improved. After this is completed there is some potential business re-transformation as you start to review your processes in new ways now that speed is no longer a limiting factor.

Design Time

It was at this point that SAP made a repeated reference to Design Thinking.  While HANA enables tremendous increases in reporting (read) speeds, it's biggest benefit isn't technical so much as it is functional.  By removing speed as a barrier, SAP customers will have to re-think their business processes.  For instance, what can be done with CO allocations now that performance and run-time are no longer a concern?  Are there certain costs that you would like to allocate but didn't want to add more runtime to your allocation process?  The key message is that it's not the speed of HANA that is used to justify its ROI, it's the benefit that it provides the business to better manage it's data and make quicker and more accurate decisions.

Who is going to deliver this new Design Thinking?  There was some discussion in Palo Alto and on Twitter about whether or not the consulting groups would have the chops to deliver this type of consulting.  Most everyone seemed to be skeptical about it in spite of the large numbers being published from SAP that have gone through their HANA certification.  I tend to agree with this viewpoint because the dominant changes to the SAP consulting market in the last 5 years have been around the topics of 1) low cost and 2) offshoring. 

What SAP is encouraging is a review of a customer's key processes with an eye for increased efficiencies.  To design effective business processes for an SAP system, you need several items.  First and foremost, you need expertise about the process in question and the solution that will support it.  Given the high degree of integration that ERP has, you also have to carefully manage the final process across multiple groups that often have competing objectives.  These types of sessions (I usually think of them more more as negotiations than workshops) have to be done together in an intimate and collaborative manner.  You just can't design a business process via MS Word or a project collaboration tool, much less re-design one that negatively impacts purchasing at the benefit of finance.

The SAP consulting market has been more akin to a SAP contracting market these past few years.  Maybe HANA will help reposition how customers use their consulting talent.  We will see.

Disruption

SAP continually mentioned that implementing this solution for existing customers would be non-disruptive. My main concern with the 'non-disruption' comment is that most people think SAP has a poor track record here.  We all know how complex an ERP project is and how an upgrade can be equally challenging.  SAP has reacted to this with it's Enhancement Package (EhP) strategy and promised both quicker roll outs of new functionality as well as more isolated functional activations onsite.  The more precise we can be in activating a single new business function, the less time has to be spent implementing it.  I agree with this and how EhPs are delivered as well as the limited time it takes to install, activate, test and rollout a new solution...  but I'm clearly in the minority.  From what I've seen in the market, customers view EhPs as significant undertakings even if they're not activating a single business function. Now SAP is going to these same customers and promising that they can switch their core transaction system to a new revolutionary DB and it won't disrupt their business processes.  This may be true but I doubt customers will view it that way.

Usage

Even though an ERP system's DB can be migrated to HANA, the entire system does not have to actually use it.  The activation of HANA can be done at a very low level.  It's not by client, module or even by submodule.  Instead, you can activate individual functions or BAPIS to use HANA or to not.  So, it's not an all-or-nothing approach.  This further strengthens SAP's argument that Suite on HANA will be non-disruptive and should make it easier for customers to try out HANA by prioritizing an individual area or function in ERP without exposing the entire system to this new technology.

BW

Once an application such as ERP is on HANA and faster reporting is available directly in the source system, is BW still a necessary application for reporting purposes?  There are two thoughts on this.  On the one hand, there are many different use cases that still support BW.  If you have requirements around multiple source systems, unstructured data, data harmonization and quality, mobile data, complicated cross application reporting, etc., then the case for BW is still strong.  However, now that the source transaction reporting is so fast, why burden yourself with the additional cost, overhead, data latency, timing, and data administration of BW when you can report out of ERP directly?  This could represent some real savings to certain SAP customers that are either not heavy BW users, or those that want to scale back their usage of it.

Of the two viewpoints, I think BW could actually get stronger as part of a customer's SAP solution.  Since the native reporting out of ERP will be so fast, the operative reporting requirements that have been forced onto the BW community will hopefully be alleviated.  By doing so, BW teams will be able to better direct their efforts around more strategic, analytical, and mobile reporting requirements instead of the column-and-row based reports that most BW projects seem to fall prey to.  BW teams have been saying for years that operative reporting should be done in the OLTP system but they have a high failure rate given BW's high performance capabilities and easier report construction and delivery.  With HANA, some of those benefits are now on both sides of the RFC fence.

Final Thoughts

If you've been following SAP closely over the past year it was easy to predict that this day would one day come.  SAP has been touting the benefits of HANA aggressively and it was only a matter of time before they enabled it for their most critical applications.  SAP has delivered on their vision of a reinvigorated database and hopes to have 1,000 customers by year end with at least some small part of a Business Suite application live on HANA.

NOTE: SAP paid for some of my travel expenses to attend the press release.