Who should “get” the HANA message? The forgotten ones.

[LeonardoAraujo]

We are about to start another edition of the SAPPHIRE conference in Orlando. It will be a pack filled week with sessions, announcements and meetings. But one thing is for certain, there will be (again) lots of talks about HANA. The SAP in-memory technology has for years moved dead center in the SAP strategy. While we’ve been hearing about it for years, it is now that the technology is really starting to reach customers. Being an acceleration enabler, a sophisticated application server, the foundation for BW or even the business suite, HANA today can be used in very different scenarios. Some are more cutting-edge than others but overall, what is not lacking is options.

From its deep technical roots (in-memory database running on very specialized appliances), the first people involved and/or exposed to the SAP HANA pitch where developers. HANA is crazy fast, we know that. It is proven. And we can build a lot on top of it, so it is natural developers needed to be enabled. But soon it became challenging to get HANA “bought” by companies as the Speed argument proved weak. Sure speed is great, but speed itself doesn’t bring much value. Well, that is at least the perception of customers. “It is nice that my reports now run super-fast, but is it worth the investment?”

So SAP noticed early on that selling HANA means selling the business value of speed. SAP worked on improving/rewriting some business functionalities to make them “optimized for HANA”. In this group you find CO-PA reporting, MRP, Fast Closing (FI), AR reporting, Customer order listing, etc. And so the sales pitch turned to the business (customers), on how this brings value to them.

What I’ve been seeing is still some resistance and challenge in the identification and recognition of HANA value by these business cases. I’ve heard multiple times, from different customers, that it is nice that MRP can be executed in a fraction of the time it was taking before, but since it was a batch process, they still were not seeing the compelling argument for adoption.

So the argument shifted from “How fast HANA is…” to “How fast your process can run”, but I still think this is wrong positioning…

“It is not about the speed itself, but about what it enables in terms of changes in business processes”

Subtle but immensely different message.

Technical value -> HANA is super-fast

SAP Business Value proposition -> HANA can make your MRP runs be processed is minutes. Almost declaring the end of batch processing…

The real HANA value -> Discussion with the business to see what type of transformations that enables in the way they run the business. Can I run MRP now during the day?…

Other examples

Treasury

Technical value -> HANA is super-fast

SAP Business Value proposition -> HANA can you process AR statements in minutes (instead of hours for very large customers)

The real HANA value -> almost online AR balances can allow a much better cash flow monitoring. Some customers may be able to better allocate funds during intra-day operations.

Custom code development

It is known that most of the SAP customer’s performance problems come from badly written (or maintained) ABAP code. Bad design, execution or both very often lead to solutions that don’t correctly implement the SAP data model. Queries are either wrong or bad performing. SAP delivers with HANA something called HANA Live (what used to be called the Analytical Foundation for Business Suite on HANA). Most SAP data models are modeled in DB procedures, allowing fast, easy and correct data queries. You can spend less on ABAP report development and when you do need to develop, you can rely on a more accurate framework. Both really reduce development cost and TCO.

SAP is hard at work on identifying the real business cases for HANA. But we are only scratching the surface. In the years to come, we will be creating new solutions, now under a new paradigm of DB design…

So, what is my point?

So this leads me to the main topic of this BLOG. The identification of these business cases cannot be done by SAP alone and, even most importantly, this is not a conversation between SAP and customers directly. HANA business cases as they have been identified so far may still not be very appealing to customers. What needs to happen is this healthy brainstorming and value identification between the customer and the application specialists. SAP represents only a very small number of application specialists on the field today. Partners have a very important role to play in this. The importance of HANA, its capabilities and what it may mean to the future of companies is a message that needs to be very well understood by the application specialists out there. These are also called the “functional guys”.

When a customer hires a FI-CO consultant, they expect this applications specialist to be completely aware of the capabilities of the software. This should include (but very often doesn’t) the enhancement capabilities and features available from enhancement packs (this is topic for another BLOG). So it is very important that this person knows the RDS’s available for Suite on HANA or other HANA accelerators. It is this person that should be able to explain the value of HANA Live. However, this public is often left behind. They are the forgotten ones.

It is not much of value to have developers enabled to work on HANA if the design of a solution comes from a person that didn’t even know that it could have been conceived differently in an in-memory reality… Developers don’t often design solutions, application specialists do.

Options

SAP has been in small part addressing this by the community driven HANA business case catalogue, where anyone can suggest HANA use-cases. Also, HANA Academy and the new “Open SAP” offer courses (many free) to promote early adoption. However, to properly address my point of the “forgotten ones” we need content targeting that group. Sessions like the ones below should be available to all, well communicated, included in the new training materials of functional academies and even taught at universities:

• How HANA can change the way you do business;
• Designing applications in an in-memory reality;
• The end of batch processing – what does it really mean?

Considering where we are now, I believe we are moving in the right direction. We could argue about the speed it happens, but we surely are no longer in the “This is a super-fast SQL statement” type of discussion. And that is important.